IETF Logo Mail Archive

Re: [aqm] adoption call: draft-welzl-ecn-benefits

"Scheffenegger, Richard" <rs@netapp.com> Fri, 29 August 2014 13:17 UTC

Return-Path: <rs@netapp.com>
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 084AF1A02ED for <aqm@ietfa.amsl.com>; Fri, 29 Aug 2014 06:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 ls6V22EJQSwU for <aqm@ietfa.amsl.com>; Fri, 29 Aug 2014 06:17:42 -0700 (PDT)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63081A030F for <aqm@ietf.org>; Fri, 29 Aug 2014 06:17:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,424,1406617200"; d="scan'208";a="143002041"
Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 29 Aug 2014 06:17:42 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 29 Aug 2014 06:17:11 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 29 Aug 2014 06:17:10 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com ([fe80::f0a5:80a1:86de:fa66]) by hioexcmbx05-prd.hq.netapp.com ([fe80::f0a5:80a1:86de:fa66%21]) with mapi id 15.00.0913.011; Fri, 29 Aug 2014 06:16:58 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: [aqm] adoption call: draft-welzl-ecn-benefits
Thread-Index: AQHPtXNH7fyT7fWkOEa/SOO/NTHNxZvMLA8AgABZOYCAAKjkAIAAC2GAgBpxuOA=
Date: Fri, 29 Aug 2014 13:16:58 +0000
Message-ID: <16141ccda1c843ab8f03fb5f478db010@hioexcmbx05-prd.hq.netapp.com>
References: <53E8D7B0.9040007@mti-systems.com> <CAA93jw7ufoEdfGexKMwkSOGLj7LMYBq-nGVPGJt+5G+OHx+ayA@mail.gmail.com> <20140811233857.GL45982@verdi> <201408120943.s7C9hRvV024419@bagheera.jungle.bt.co.uk> <53E9EB49.9040509@erg.abdn.ac.uk>
In-Reply-To: <53E9EB49.9040509@erg.abdn.ac.uk>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.122.56.79]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/snbopPe00BJc190vGAEev8fA9BU
Subject: Re: [aqm] adoption call: draft-welzl-ecn-benefits
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, 29 Aug 2014 13:17:46 -0000

Hi Gorry,

> > Given QUIC includes FEC to hide losses, I guess it is a good example to
> > consider whether ECN still offers sufficient benefits over and above
> > just removing losses.
> >
> GF: And then, isn't the implication of AQM to significantly increase the
> number of "losses" unless we use ECN?
> 
> Indeed, I have the impression we are confusing many on these points -
> ECN could change the reaction to congestion signal, and FEC (even
> opportunistic CC-friendly FEC) can also change the way things react to
> congestion signals.

I don't think that an AQM's implication is automatically to increase the number of losses; that may happen to specific flows (in particular, unresponsive ones), but for responsive (non-ECN) ones, the expectation would be to de-correlate the losses, and for TCP, to only have around 1 loss per window when necessary - instead of a burst loss of one window and the expensive recovery...

Perhaps it's that perception that also poses an obstacle to AQM deployment, because of the believe that a dynamic but lower mark/drop threshold will cause more losses?

Regards,
  Richard

v2.23.0 | Report a Bug | By Email