optimal web service (Re: BGP announcements and small providers )
Joseph C. Pistritto
jcp at pointcast.com
Wed Feb 26 23:38:36 UTC 1997
>Defining "better" when all you have to work with is BGP, is pretty hard. It
>turns out that, as in DNS, round robin is better than any definable static
You can say that again!
Actually, one of the critical performance criteria for our network is how
fast we can get rid of packets going to end users, so path "goodness" is
pretty serious issue for us.
I sure wish there were some way (better than BGP I mean) for routing
packets in a multi-homed environment. However the technique we use is
1) we've built into our product the ability to load balance on a failure
(or a really bad delay situation), away from a serious problem either in a
server, or conceivably in the path. This happens under the covers and
we're only dimly aware of it, unless there's a big problem somewhere. The
usual reason this occurs is a reachability problem through one ISP or
another, or running out of bandwidth into an ISP.
2) we observe the gross characteristics of our ISPs as seen from our end,
and "push" more traffic towards networks with better delay and reliability
characteristics. Unfortunately, this is a somewhat manual process. We are
looking for "more automatic" ways of doing this, if people know of pointers
to good "network quality measurement" stuff, point me at 'em. Our ISPs
seem to do a fair to reasonable job of preventing their networks from
cracking up, however we often can take load off an ISP while they fix a
problem that crops up in their network (and usually do to improve quality
of service to our end users, if we have the bandwidth to spare).
I'd love to know if there are other multihomed sites out there that have
successfully gotten full BGP information from multiple providers and used
it to balance outgoing load, and had positive experiences as a result.
Given all the problems of using BGP for this purpose (for which it really
wasn't designed), we've wondered how hard we should push our providers to
do this. (Some will, some won't, although I suspect we could get them all
to if we really wanted).
More information about the NANOG