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

[David P. Reed]

The point of Little's Lemma is that the tradeoff for using the full 
bottleneck bandwidth is asymptotically infinite delay, delay variance, 
and other statistics.

If you value utilization but not response time, of course you can fill 
the pipes.
But end users value response time almost always much higher than  twice 
the throughput.

And of course you can give delay-free service to a small percentage of 
traffic by prioritization, but all that does is make the asymptotic 
growth of delay and delay variance for the rest of the traffic even worse.


Fred Baker wrote:
>
> 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.
>