"Does TCP Need an Overhaul?" (internetevolution, via slashdot)

David Andersen dga at cs.cmu.edu
Sat Apr 5 16:05:34 UTC 2008

On Apr 5, 2008, at 9:40 AM, Kevin Day wrote:
>> in answer to your question about SACK, it looks like they simulate  
>> a slower
>> link speed for all TCP sessions that they guess are in the same  
>> flow-bundle.
>> thus, all sessions in that flow-bundle see a single shared  
>> contributed
>> bandwidth-delay product from any link served by one of their boxes.
> Yeah, I guess the point I was trying to make is that once you throw  
> SACK into the equation you lose the assumption that if you drop TCP  
> packets, TCP slows down. Before New Reno, fast-retransmit and SACK  
> this was true and very easy to model. Now you can drop a  
> considerable number of packets and TCP doesn't slow down very much,  
> if at all. If you're worried about data that your clients

That's only partially correct:  TCP doesn't _time out_, but it still  
cuts its sending window in half (ergo, it cuts the rate at which it  
sends in half).  The TCP sending rate computations are unchanged by  
either NewReno or SACK;  the difference is that NR and SACK are much  
more efficient at getting back on their feet after the loss and:
  a)  Are less likely to retransmit packets they've already sent
  b)  Are less likely to go into a huge timeout and therefore back to  

You can force TCP into basically whatever sending rate you want by  
dropping the right packets.

> are downloading you're either throwing away data from the server  
> (which is wasting bandwidth getting all the way to you) or throwing  
> away your clients' ACKs. Lost ACKs do almost nothing to slow down  
> TCP unless you've thrown them *all* away.

You're definitely tossing useful data.  One can argue that you're  
going to do that anyway at the bottleneck link, but I'm not sure I've  
had enough espresso to make that argument yet. :)

> I'm not saying all of this is completely useless, but it's relying a  
> lot on the fact that the people you're trying to rate limit are  
> going to be playing by the same rules you intended. This makes me  
> really wish that something like ECN had taken off - any router  
> between the two end-points can say "slow this connection down" and  
> (if both ends are playing by the rules) they do so without wasting  
> time on retransmits.



More information about the NANOG mailing list