ietf
[Top] [All Lists]

Re: 13 Root Server Limitation

2004-05-17 16:37:34
On Mon, 17 May 2004, Iljitsch van Beijnum wrote:

On 17-mei-04, at 19:36, Dean Anderson wrote:

It is conceptually very simple:  Setup 2 anycast servers (S1 and S2)
on several paths (AS-A and AS-Y, different AS numbers)  Have an ISP
connect to both of those paths, and then have that ISP do fine grained
load balancing to prefixes available over those paths. Packets will go
to each anycast server.  This will not cause a problem with UDP, since
the entire connection transaction is in one packet. But TCP will have
a minumim of 3 packets.  2 packets will go to server S1, and one
packet will go to server S2.  Neither S1 nor S2 will have a complete
TCP connection, and so both will fail.

As I've said before, this isn't how things work in practice, as actual 
load sharing towards a destination over two different AS paths doesn't 
happen, and when load sharing is done, it's almost always in a way that 
keeps packets belonging to a single TCP session together. (You really 
don't want to see what happens to TCP performance with 100% out of 
order packets.)

You are describing Cisco load balancing. The cisco behavior is due to the
effects of its route cache, which uses cache flow data to keep flows
together (but only when cef is turned on). This is not a feature of its
BGP handling, but a "feature" of its packet routing engine. Cisco is not
the only router vendor, and certainly not the only one interested in
fine-grained load balancing.  Most people interested in load balancing
consider this cisco behavior undesirable, and leaving a lot to be desired.

Also, as long as the out-of-sequence packets arrive within the window
frame, there is no degradation in performance (this is one benefit of
segment windows), even if they are 100% non-sequential. I think you are
referring to some pathological out of order cases: If the frame were to
get full before the next-up packet were received (ie complete reverse
order), then there would be a problem. But just because every *pair* or so
of packets arrives out of order doesn't mean there will be any degradation
in performance. That would still be 100% out of order, but not
pathologically so.

And even if this happened it would very likely be non-fatal, as at some 
point retransmissions will make it trough so the TCP session works. As 
most data is going from the server to the client, and ACKs work 
cumulative, the performance hit is probably not too catastrophic.

Possibly.  Or you might just get a RST from the other server. I think
retransmissions just makes the problem intermittent, and slow, and consume
more connection resources on the nameserver(s). 



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


<Prev in Thread] Current Thread [Next in Thread>