[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
fred at cisco.com
Wed Sep 27 16:48:49 PDT 2006
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.
More information about the end2end-interest