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

John Leslie <john@jlc.net> Tue, 14 April 2015 00:25 UTC

Return-Path: <john@jlc.net>
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 158241B2B6B for <aqm@ietfa.amsl.com>; Mon, 13 Apr 2015 17:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 4XTQfRzsFUJ6 for <aqm@ietfa.amsl.com>; Mon, 13 Apr 2015 17:25:29 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A74F41B2B66 for <aqm@ietf.org>; Mon, 13 Apr 2015 17:25:29 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 0B1A1C94BF; Mon, 13 Apr 2015 20:25:16 -0400 (EDT)
Date: Mon, 13 Apr 2015 20:25:16 -0400
From: John Leslie <john@jlc.net>
To: David Lang <david@lang.hm>
Message-ID: <20150414002515.GD63465@verdi>
References: <5d58d2e21400449280173aa63069bf7a@hioexcmbx05-prd.hq.netapp.com> <20150327183659.GI39886@verdi> <72C12F6B-9DDE-4483-81F2-2D9A0F2D3A48@cs.columbia.edu> <alpine.DEB.2.02.1503271211200.19390@nftneq.ynat.uz> <D13AFCE7.46BC%kk@cs.ucr.edu> <alpine.DEB.2.02.1503271257230.19390@nftneq.ynat.uz> <AE342093-DE05-4D93-96DA-EB07E221F1D9@netapp.com> <alpine.DEB.2.02.1503291923300.26044@nftneq.ynat.uz> <201504131511.t3DFBG3R002270@bagheera.jungle.bt.co.uk> <alpine.DEB.2.02.1504131441190.11469@nftneq.ynat.uz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1504131441190.11469@nftneq.ynat.uz>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/JYiVdFvuqR0DXfvwKcR0hiEixo0>
Cc: 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: Tue, 14 Apr 2015 00:25:32 -0000

David Lang <david@lang.hm> wrote:
> On Mon, 13 Apr 2015, Bob Briscoe wrote:
> 
>> I think your conception of how ECN works is incorrect. You describe ECN as 
>> if the AQM marks one packet when it drops another packet. You say that the 
>> ECN-mark speeds up the retransmission of the dropped packet. On the 
>> contrary, the idea of classic ECN [RFC3168] is that the ECN marks replace 
>> the drops. In all known testing (except pathological cases), classic ECN 
>> effectively eliminates drops for all ECN-capable packets.
> 
> That's what I thought, and if that was the case,

   What does "that" refer to -- I honestly can't tell from your text.

   (We have an awful lot of talking past each other when we talk ECN:
it would really help to be as clear as possible.)

> then marking packets as ECN-capable would mean that they would have an
> advantage over non-ECN packets (by not getting dropped, so getting a
> higher share of bandwidth)

   I wish I could go back in time an excise every phrase saying "same as
a packet drop" from the ECN RFCs.

> that's what the gaming ECN thread was about, and if I understood the 
> responses, I was being told that marking packets as ECN-capable, but not 
> slowing down (actually responding to ECN) would not let an application get 
> any advantage because the packets would just end up getting dropped anyway, 
> since marking and dropping happen at the same level, even on ECN-capable 
> flows.

   No, I don't think any of us were saying that.

   A few of us _were_ saying that abuse like that is a small percentage
of the abuse where the sender simply doesn't reduce the sending rate if
packet loss is detected.

   And several folks _did_ say that it was important to have the marking
and dropping threshholds the same _and_ the reaction to marking the same
as the reaction to dropping be the same "so that neither would suffer in
comparison to the other".

   (They are wrong, BTW, but most of us just let this canard die down.)

> If the packets are just marked, but not dropped, then the ECN-capable flows 
> will occupy a disproportinate share of the available buffer space, since 
> they just get marked instead of dropped.

   True.

   But so what?

   What do you want to do about it? (That's my trademark question, BTW.)

   If you are the node experiencing congestion, and your buffer is full,
you absolutely should drop the marked packet. No disagreement there.

   (This can happen, BTW, in PIE, which marks packets as the enter the
buffer; and the buffer may fill before they can be sent.)

   But if your buffer isn't even close to full, what's wrong with ECN
capable packets using a larger share of the buffer? If they go to a
responsive flow, the reaction will be quicker than if they were dropped.

   Of course, if they go to a non-responsive flow, they would get a
slight advantage, but why is that _your_ concern? And there's really
nothing you can do to counter the advantage that doesn't break the ECN
paradigm for responsive flows.

   If instead, you are a node later on the path, there's nothing wrong
with dropping ECN packets with Congestion-Experienced marks _when_ you
need to drop packets. But there's no reason to "punish" them for having
occupied a "disproportionate share" of somebody else's buffer.

   It would be much better if we could think in terms of ECN-marking
_well_before_ there is any need to drop packets because the buffer is
full; and treating any "advantage" this might give them an an incentive
for more flows to enable ECN.

   One of the things I'm quite sure Bob Briscoe is thinking -- but not
writing -- is that he believes ECN can solve a lot of the problems he
named _if_ the ECN marking occurs at a lower threshhold than packet drop.
We are _not_ chartered to "fix ECN" in this WG: so that discussion doesn't
really belong in this thread; but you and Bob are unlikely to communicate
fully if you ignore that possibility.

   Hope this helps...

--
John Leslie <john@jlc.net>