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

John Leslie <> Fri, 27 March 2015 18:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B18F91A8948 for <>; Fri, 27 Mar 2015 11:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6gaN4s2XoK7A for <>; Fri, 27 Mar 2015 11:37:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B5A161A8793 for <>; Fri, 27 Mar 2015 11:37:12 -0700 (PDT)
Received: by (Postfix, from userid 104) id CF306C94BF; Fri, 27 Mar 2015 14:36:59 -0400 (EDT)
Date: Fri, 27 Mar 2015 14:36:59 -0400
From: John Leslie <>
To: "Scheffenegger, Richard" <>
Message-ID: <20150327183659.GI39886@verdi>
References: <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Archived-At: <>
Subject: Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Mar 2015 18:37:14 -0000

Scheffenegger, Richard <> 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;


   This is a trade-off: many folks believe that a good AQM has enough
benefits for typical TCP flows to overcome that. (YMMV)

> Agreed, there are ways to mitigate this (FEC-encoded transports).


   And this is happening. I haven't heard of it happening in TCP itself;
but I wouldn't be surprised to hear of implementations which advertise
themselves as TCP doing this...

   FEC does _not_ have to be particularly expensive in bandwidth (though
the implementations we hear about mosty are...).

> But the "OR" is exactly the correct description here: FEC has inherent
> overhead thus reduced bandwidth, and loss-recovery suffers from
> head-of-line blocking,

   Yes. (though there are possible mitigations)...

> thus higher latency (to the application, where it actually matters).

   It depends upon the application, at least partly.

   The bulk of TCP transport today, we believe, is trying to optimize
for quick transport of medium-sized files. We already see "optimizations"
which send whole files before looking for feedback. These optimizations
seem to be working pretty well...

> FQ-Codel runs with high bandwidth, but the drops induce latency in the
> end-hosts nevertheless...


   But this isn't causing folks to demand their outgoing routers disable
FQ-CoDel, etc...

> Thus FQ-Codel with ECN would still be more effective than without ECN.


   And that is where we want to go!

John Leslie <>