IETF Logo Mail Archive

Re: ECN in QUIC

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 25 September 2017 11:31 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95031332DA for <quic@ietfa.amsl.com>; Mon, 25 Sep 2017 04:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 tOs3El-9uRB3 for <quic@ietfa.amsl.com>; Mon, 25 Sep 2017 04:31:41 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 95C5613420E for <quic@ietf.org>; Mon, 25 Sep 2017 04:31:39 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 094181B001A7; Mon, 25 Sep 2017 12:31:13 +0100 (BST)
Message-ID: <59C8E900.20409@erg.abdn.ac.uk>
Date: Mon, 25 Sep 2017 12:31:12 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
CC: Christian Huitema <huitema@huitema.net>, quic@ietf.org
Subject: Re: ECN in QUIC
References: <AM3PR07MB34048E916A7B18695313171C2820@AM3PR07MB340.eurprd07.prod.outlook.com> <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> <DB4PR07MB348F7E2CFAF1574F838ED8CC2610@DB4PR07MB348.eurprd07.prod.outlook.com> <CAKcm_gMbxEMcq4UaQ9R_iGgXSpKJHzA67VMg2ZXDg2K1OhdUNA@mail.gmail.com> <DB4PR07MB348D95672E48A338758E32DC2610@DB4PR07MB348.eurprd07.prod.outlook.com> <CAD3dRjoz7XNPZB3HY2tHL6iJvqKf=0EgVCmc20nFkB0F914jkA@mail.gmail.com> <59C27B81.2020609@erg.abdn.ac.uk> <DB4PR07MB348D2FAD4DCE09BA3E2166AC2610@DB4PR07MB348.eurprd07.prod.outlook.com> <61205221-b042-b0ef-7fb0-dac655b43ff2@huitema.net> <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch>
In-Reply-To: <88460A72-DFEF-4CD8-8A41-C8684EC65C09@tik.ee.ethz.ch>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mdcr5YyY9NiPxXtvmsGf5L-j0lE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2017 11:31:44 -0000

+1

DCTP is not IETF standard - it's documenting a solution that is deployed 
in data centres - as it says - my hope is QUIC receives wider deployment.

I suggest you start from AccECN, or examine the feedback discussed in 
RMCAT - which I think strove for equivalence to this.

Gorry

On 25/09/2017, 12:26, Mirja Kühlewind wrote:
> There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm that changes the feedback defined in RFC3168 because we believe more accurate information in needed in future.
>
> Mirja
>
>
>> Am 20.09.2017 um 21:02 schrieb Christian Huitema<huitema@huitema.net>:
>>
>>
>>
>> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
>>> Detailed info about which packets are ECN marked can be useful but are not stricktly necessary. One alternative, that is presented in the ECN-QUIC draft is to count number of marked bytes.
>>> That said, some like the detailed packet-level information type better. I have not yet been convinced that that this level of detail is necessary though.
>> The problem is whether you can define a one size fit all ECN processing,
>> that if possible should be compatible with ACK compression. There are at
>> least two:
>>
>> * RFC 3168 says, echo ECN=1 if at least one of the acked packets had ECN
>> set.
>>
>> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction of
>> packet acked with ECN in 1RTT is the same as the fraction of packets
>> with ECN set.
>>
>> So, which one?
>>
>> --Christian Huitema
>>

v2.23.0 | Report a Bug | By Email