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:08 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 C56691A888C for <aqm@ietfa.amsl.com>; Fri, 27 Mar 2015 12:08:58 -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 RtAQioSTQyMG for <aqm@ietfa.amsl.com>; Fri, 27 Mar 2015 12:08:57 -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 4AD4D1A8793 for <aqm@ietf.org>; Fri, 27 Mar 2015 12:08:57 -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 t2RJ8pXd030028; Fri, 27 Mar 2015 11:08:51 -0800
Date: Fri, 27 Mar 2015 12:08:51 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: "Scheffenegger, Richard" <rs@netapp.com>
In-Reply-To: <5d58d2e21400449280173aa63069bf7a@hioexcmbx05-prd.hq.netapp.com>
Message-ID: <alpine.DEB.2.02.1503271203080.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>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/MmQAbndMhPNWxBg6DVmJEwE2vH8>
Cc: "De Schepper, Koen \(Koen\)" <koen.de_schepper@alcatel-lucent.com>, "aqm@ietf.org" <aqm@ietf.org>, Michael Welzl <michawe@ifi.uio.no>, "davecb@spamcop.net" <davecb@spamcop.net>
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:08:58 -0000

On Fri, 27 Mar 2015, Scheffenegger, Richard wrote:

> Hi David,
>
>
>>> - low latency AND high throughput (compared to low latency OR high
>>> throughput for drop based congestion controllers)
>>
>> I think that you are overstating things when you say that without ECN you
>> are forced to choose between low latency OR high throughput. that doesn't
>> match what people are reporting when they use simple fq_codel without ECN
>
>
> I disagree. At the least when you are using TCP, a drop will cause head-of-line blocking on the receiver, for at least 1 RTT; Agreed, there are ways to mitigate this (FEC-encoded transports).
>
> But the "OR" is exactly the correct description here: FEC has inheritent overhead thus reduced bandwidth, and loss-recovery suffers from head-of-line blocking, thus higher latency (to the application, where it actually matters).
>
> FQ-Codel runs with high bandwidth, but the drops induce latency in the end-hosts nevertheless...
> Thus FQ-Codel with ECN would still be more effective than without ECN.

The key thing is that we are talking about different scales here.

You are talking about a 1RTT latency that will happen if the congestion gets bad 
enough, while I'm looking at the effects of overbuffering that causes the 
effective utilization of links to be well below 50% in practice. In such a case, 
doing something like fq_codel without ECN will get you 90%+ of the theoretical 
best case and is such a massive improvement that the vast majority of the users 
are not going to notice any improvement from ECN marking instead of dropping.

But the discussions here have explicitly said that ECN marking happens at the 
same time that drops happen, so it's not a case of doing ECN instead of 
dropping. While ECN could be used that way, that's not what's being advocated 
(and marking independently of dropping does raise all the fairness issues that 
we discussed a week or so ago)

David Lang