|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Slashdot: Providers Ignoring DNS TTL?
On Sun, 24 Apr 2005, Steve Gibbard wrote: > > On Sun, 24 Apr 2005, Robert M. Enger wrote: > > > Steinar: > > > > There is a large body of work from competent and well known researchers > > that assert the claim. I certainly lack standing to question their > > results. > > > > Empirically, download speeds to home are nearly cut in half (18Mbps) > > from sources that are subjected to packet reordering along the path. > > I'm trying to sort out the various claims here, since I think right now > this is a case of people talking past each other, and arguing completely > different points. > > First of all, let's ditch the term "PPLB." The usual alternative to per > packet load balancing (what's been being talked about here) is per prefix > load balancing, which would also be "PPLB." The abbreviation is therefore > more confusing than anything else. > > Now, onto the argument that's going on here. > > Dean says "per packet load balancing is coming," and then goes on to > assume it's going to be used in such a way that it will cause packets to > route through widely divergent paths. > > Several others have responded that that would cause packet reordering and > break TCP. > > Robert says that even used correctly (on identical circuits between the > same set of routers), per packet load balancing can cause packet > reordering. > > Steiner says that when used correctly, per packet load balancing causes > packet reordering only rarely, and speeds things up enough when it doesn't > that the slowdowns caused by occasional packet reordering may be worth > putting up with. > > Robert says well known researchers say that packet reordering is bad. > > So, as far as I can tell, everybody except perhaps Dean agrees that: > > - Used incorrectly (on divergent paths), per packet load balancing can > cause packet reordering. > > - Used correctly (on non-diverging paths), packet reordering doesn't > happen often. > > - Packet reordering is bad, and should be avoided. > > I'm less clear on Dean's position, but I think it's something along the > lines of: > > "Per packet load balancing over divergent paths is coming, by fiat from > marketing departments even if engineers don't like it, and anything that > doesn't play well with it needs fixing." While Dean focuses on anycast, > that would presumably extend to TCP and to anything jitter sensitive, such > as streaming audio or video. > > Anything that's being missed here, or does this sum it all up? I think thats a fair summary. So agreeing for a second with Dean that indeed this behaviour would appear to be prohibited or at least inconsistent with the RFCs, the fact is anycast is widely deployed and is proven to be stable. Perhaps a solution to this is to look at what would be the best consistent view and to write an RFC to clarify this and obsolete the old ones that produce the inconsistency. I'm not sure what that would look like but that would appear to be a way to eliminate the theoretical problem.. Steve
|