optimal web service (Re: BGP announcements and small providers )

Wed Feb 26 23:59:48 UTC 1997

"Joseph C. Pistritto" wrote :
|-> >
|-> >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
|-> >ordering.
|-> >
|-> 
|-> 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
|-> twofold:
|-> 	1) we've built into our product the ability to load balance on a failur
|-> e
|-> (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.  

It's possible that QOSR-WG or similar will come up with something, of 
course....

|-> 	2) we observe the gross characteristics of our ISPs as seen from our en
|-> d,
|-> 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).
|-> 

 One way to help would be to automate the process of sending packets 
to the downstream sites of your multiple providers (e.g. what they 
would announce in a peering, rather than transit BGP session)

 This wouldn't go far enough, but assuming you had three *big* 
providers, it would sure help. Perhaps going through the IRR and 
working out which ASes/networks are _customers_ of your providers, on 
the (fairly reasonable) assumption that they will be the best path to 
their own customer, and then weighting them locally to be preferred.

 Alternatively, you could have your "favourite" provider advertise a 
default to you, and ask the other provider(s) to only advertise as if 
you were a peer. Saves all that automation aggro ;)

 This would have the added advantage that the routing in these 
instances should be symmetric, which is another aggro involved in BGP 
load balancing.

 This gets mathematically nicer as num-of-providers rises too ;-)

|-> 	I'd love to know if there are other multihomed sites out there that hav
|-> e
|-> 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).
|-> 
|-> 	Best regards,
|-> 	-jcp-
|-> 

Lyndon Levesley
Xara Networks

I've had a wonderful time...
...but this wasn't it.