Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02

[KK <[e-mail]>]

The discussion about adding buffers and the impact of buffers should be
considered relative to the time scales when congestion occurs and when it
is relieved by the dynamics of the end-system protocols. The reason we
have buffering is to handle transients at the points where there is a
mismatch in available bandwidth. We don¹t look to just throw buffers in
front of a bottleneck for Œlong run¹ overload.

While active queue management undoubtedly seeks to keep the backlog
build-up at a manageable level so as to not allow latency to grow and
still keep the links busy to the extent possible, the complement that ECN
provides is to mitigate the impact of the drop that AQM uses to signal
end-points to react to the transient congestion. ECN has the benefit when
you have flows that have small windows, where the impact of loss is more
significant. 

As you say, "when a packet is lost it causes a 'large' amount of latency
as the sender times out and retransmits, but if this is only happening
every few thousand packets, it's a minor effect.². But this is the case
for flows that are long-lived. If the flows are short-lived (and I believe
empirical evidence suggests that they are a significant portion of the
flows), then it is not a minor effect any more.

Thanks,
-- 
K. K. Ramakrishnan
Professor
Dept. of Computer Science and Engineering
University of California, Riverside
Rm. 332, Winston Chung Hall
Tel: [phone]
Web Page: http://www.cs.ucr.edu/~kk/




On 3/27/15, 12:18 PM, "David Lang" <[e-mail]> wrote:

>If your link is the bottleneck, adding buffers (allowing latency to
>increase) 
>doesn't decrease loss over the long run, it just hides it in the short
>run.
>
>If you don't have the bandwidth to send the packets, nothing you do with
>buffers 
>or latency will let you get more packets through.
>
>If you push too hard to decrease latency, then you run into times when
>the link 
>is idle, so throughput can suffer a little bit.
>
>But right now, real-world buffers commonly get into tens of seconds worth
>of 
>traffic. Far beyond what's needed or reasonable to keep the links busy.
>Using 
>active queue management to keep the links busy without letting the
>backlong 
>build up results in both increased throughput for users, and decreases of
>latency of a couple orders of magnatude.
>
>by comparison, ECN on a network that's operating without excessive
>buffering and 
>has a large number of flows, is going to only have a small effect on
>latency and 
>througput overall.
>
>Yes, when a packet is lost it causes a 'large' amount of latency as the
>sender 
>times out and retransmits, but if this is only happening every few
>thousand 
>packets, it's a minor effect.
>
>David Lang
>
>On Fri, 27 Mar 2015, Vishal Misra wrote:
>
>> If you reduce latency, the dynamics of TCP are such that it will
>>necessarily 
>> increase loss rate. On a bottlenecked link, the relationship of
>>throughput to 
>> the RTT and loss rate of TCP is roughly the following (happy stop
>>supply link 
>> to papers):
>>
>> throughput = K/(RTT*sqrt(p))
>>
>> where K is some constant, p is the loss rate and RTT is the round trip
>>time. If you reduce latencies, to maintain the same throughput (that of
>>the bottlenecked link), the loss rate has to necessarily go up.
>> So reducing latencies has the impact of increasing loss rates which
>>affects things in bad ways as has been pointed out.
>>
>> With ECN, it is the _marking_ rate that goes up and TCP follows the
>>same dynamics. Nothing is dropped, no harm done.
>> That¹s why ECN widely adopted is a win-win.
>>
>> -Vishal
>> --
>> http://www.cs.columbia.edu/~misra/
>>
>>
>>> On Mar 27, 2015, at 2:36 PM, John Leslie <[e-mail]> wrote:
>>>
>>> Scheffenegger, Richard <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>> ... At the least when you are using TCP, a drop will cause
>>>>head-of-line
>>>> blocking on the receiver, for at least 1 RTT;
>>>
>>>   Yes.
>>>
>>>   This is a trade-off: many folks believe that a good AQM has enough
>>> benefits for typical TCP flows to overcome that. (YMMV)
>>
>>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm