North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Paul A Vixie
  • Date: Wed Feb 26 15:26:00 1997

> > > As it is, if the interface-defaulted squid machine was dual-homed to
> > > providers X and Y that don't peer, a customer of X could get the A
> > > record for the interface in Y's space.  The client would then have to
> > > take the transit path between X and Y, which for many X's and Y's,
> > > sucks.

Yes.  But there are a lot of other reasons for specific paths to suck, and
I don't consider this one to be detectable, or even representative.

> > You could take in all the BGP data from your providers (read-only as it
> > were) then link that into your DNS server so that it returns an IP
> > address according to the 'best' (however you define that...) route
> > that you have back to them...? 

No.  DNS does not guarantee meaningful ordering of RRs within RRsets, and
except in the case of MX or SRV which have explicit priorities, clients are
free to sort or randomize or even subset the A RRset they get back.  Also,
consider caches that are used directly or indirectly by clients whose
addresses may not be ideal for the original ordering, even if ordering were
preserved.  Server ordering of A RRsets is just not a useful approach.

> I think the whole purpose t Paul V's madness in creating this solution was
> to avoid doing just that.

My approach avoids the use of BGP, but not for the above stated reasons.  As
I said at the SF NANOG, it is hard to get transit providers to send a full
BGP table, it is hard to accept it, and it would take a modified GateD that
randomized destinations in order to keep BGP's path selection from leading
90% of your routes down 1/Nth of your transit providers.  BGP was the wrong
answer.

> Also I seem to remember something in Paul's take that took care of this
> situation. Maybe he can elaborate.

Just as DNS Round Robin is suboptimal but better than nothing, so it is that
first hop path symmetry is not a complete solution but far better than a
single static default when buying transit from N providers.  At some point I
will revisit the interface default logic and add round robin selection for
outbound TCP sessions -- obviously the first hop path symmetry trick only
works for inbound sessions.  None of this will ever lead to optimality but
it's more robust than a single connection from any provider I know of, and
it's better than randomizing BGP or depending on stable ordering in DNS.

The next step after outbound round robin is teaching Squid to keep track of
connection quality from clients, and to send back HTTP redirects if a client
comes in on the "wrong" interface.  This is the only way to fix the MSIE
and NSN brain damage whereby only the first A RR of a response is used, and
when I get this part done it will be a product rather than a giveaway like
the interface default stuff.  (Yes, I have enough investors and customers for
this, thanks for your interest.)
- - - - - - - - - - - - - - - - -