[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?

[Fred Baker]

On Sep 27, 2006, at 3:34 PM, Detlef Bosau wrote:

> Wouldn´t this suggest (and I had a short glance at Fred´s answer  
> and perhaps he might contradict here) that we intendedly drop the  
> goal of achieving a full load in favour of a "load dependend ECN"  
> mechanism, i.e. when the load of a link exceeds a certain limit,  
> say 50 % of the bandwidth,  any passing packets are stamped with a  
> forward congestion notification. Thus, we would keep the throughput  
> on a limit we cannot exceed anyway, but limit the incomming traffic  
> that way that queues can fullfill their purpose, i.e. interleave  
> the flows and buffer out asynchronous traffic.

I certainly encouraged Sally et al to publish RFC 3168, and yes I  
would agree that something other than a loss-triggered approach has  
real value, especially at STM-n speeds where the difference between  
"nominal delay due to queuing" and "loss" is pretty sharp. I don't  
think I would pick "50%"; it would be at a higher rate.

But that actually says about the same thing. Change the mechanism for  
detecting when the application isn't going to get a whole lot more  
bandwidth even if it jumps the window up by an order of magnitude,  
but allow it to maximize throughput and minimize loss in a way that s  
responsive to signals from the network.