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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf