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

David Lang <david@lang.hm> Fri, 27 March 2015 19:18 UTC

Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A131A92AD for <aqm@ietfa.amsl.com>; Fri, 27 Mar 2015 12:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q9TEfR1PABh for <aqm@ietfa.amsl.com>; Fri, 27 Mar 2015 12:18:40 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A83A1A90FE for <aqm@ietf.org>; Fri, 27 Mar 2015 12:18:37 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t2RJIJdn030099; Fri, 27 Mar 2015 11:18:19 -0800
Date: Fri, 27 Mar 2015 12:18:19 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Vishal Misra <misra@cs.columbia.edu>
In-Reply-To: <72C12F6B-9DDE-4483-81F2-2D9A0F2D3A48@cs.columbia.edu>
Message-ID: <alpine.DEB.2.02.1503271211200.19390@nftneq.ynat.uz>
References: <23AFEFE3-4D93-4DD9-A22B-952C63DB9FE3@cisco.com> <BF6B00CC65FD2D45A326E74492B2C19FB75BAA82@FR711WXCHMBA05.zeu.alcatel-lucent.com> <72EE366B-05E6-454C-9E53-5054E6F9E3E3@ifi.uio.no> <55146DB9.7050501@rogers.com> <08C34E4A-DFB7-4816-92AE-2ED161799488@ifi.uio.no> <BF6B00CC65FD2D45A326E74492B2C19FB75BAFA0@FR711WXCHMBA05.zeu.alcatel-lucent.com> <alpine.DEB.2.02.1503271024550.2416@nftneq.ynat.uz> <5d58d2e21400449280173aa63069bf7a@hioexcmbx05-prd.hq.netapp.com> <20150327183659.GI39886@verdi> <72C12F6B-9DDE-4483-81F2-2D9A0F2D3A48@cs.columbia.edu>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY="===============2828522717377632183=="
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/P4oQVUm-yEY6IZx5OOMkOndzWgE>
Cc: "Scheffenegger, Richard" <rs@netapp.com>, John Leslie <john@jlc.net>, aqm@ietf.org
Subject: Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2015 19:18:46 -0000

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 <john@jlc.net> wrote:
>>
>> Scheffenegger, Richard <rs@netapp.com <mailto:rs@netapp.com>> 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)
>
>