Slashdot: Providers Ignoring DNS TTL?

Sun Apr 24 22:09:08 UTC 2005

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?

-Steve