Re: [Ecn-in-quic] ECN in QUIC update and questions

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Mon, 15 January 2018 14:11 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: ecn-in-quic@ietfa.amsl.com
Delivered-To: ecn-in-quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDF12D7E2 for <ecn-in-quic@ietfa.amsl.com>; Mon, 15 Jan 2018 06:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 NxZ9VJQANrYv for <ecn-in-quic@ietfa.amsl.com>; Mon, 15 Jan 2018 06:11:46 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E6E128959 for <ecn-in-quic@ietf.org>; Mon, 15 Jan 2018 06:11:44 -0800 (PST)
X-AuditID: c1b4fb25-48bff7000000341b-7e-5a5cb69e9367
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 27.4B.13339.E96BC5A5; Mon, 15 Jan 2018 15:11:42 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 15 Jan 2018 15:11:41 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GyiYoYOnYsTZiEf3p2quLu7hHGVBvwfq3dUy/OLTeKE=; b=DLuSyzkOor1JThVihgS8lhEKWillyjwIDGII9x2QPChxOAhwW79BH32IfsMnQlD5xmPV+CtFxadeycfINdrWE36ZzSw26R9cgdV1HftQG74gK9l/tD9yR/efAfmuEje4KPFLenXtDUd2tNXe0P4d937h1wR79FoGyuedLPfakJ4=
Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3803.eurprd07.prod.outlook.com (52.133.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Mon, 15 Jan 2018 14:11:39 +0000
Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c%13]) with mapi id 15.20.0428.014; Mon, 15 Jan 2018 14:11:39 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "Roni Even (A)" <roni.even@huawei.com>, "ecn-in-quic@ietf.org" <ecn-in-quic@ietf.org>
Thread-Topic: ECN in QUIC update and questions
Thread-Index: AdOIZnQBD0hOX0sQSLyS4r+GfAJf8wAC53rAAABaAiAAAbf0gAAAf4OwAACi1fAAAITN4ABYTiCAAEZ0dhAAw5UA4A==
Date: Mon, 15 Jan 2018 14:11:39 +0000
Message-ID: <HE1PR0702MB36255BE3FFD891378DED42C2C2EB0@HE1PR0702MB3625.eurprd07.prod.outlook.com>
References: <HE1PR0702MB3625DEC891E57DB02480621AC2130@HE1PR0702MB3625.eurprd07.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD85D4BA@DGGEMM506-MBX.china.huawei.com> <HE1PR0702MB36253CFEDE82F8A6675D41D6C2130@HE1PR0702MB3625.eurprd07.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD85D4FB@DGGEMM506-MBX.china.huawei.com> <VI1PR0701MB2126FA6D40DEC3CEDF2D50B2B9130@VI1PR0701MB2126.eurprd07.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD85D54E@DGGEMM506-MBX.china.huawei.com> <VI1PR0701MB212668423226579CA196E7B9B9130@VI1PR0701MB2126.eurprd07.prod.outlook.com> <HE1PR0702MB362545B06411DDA074B15C0AC2110@HE1PR0702MB3625.eurprd07.prod.outlook.com> <HE1PR0702MB3625B8ADB75B09691D140812C2160@HE1PR0702MB3625.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0702MB3625B8ADB75B09691D140812C2160@HE1PR0702MB3625.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3803; 7:npE+7GyB7HDlwFmNRXjR+V+fd9rBGL/Od75lY7WsNgksfX0bwQopUZ51sn1kewdm8hJTbJFKVVPAcCfjhp/naxEkePLsqHcOw0phYq3qf6L9GWypzwnpHh6Ic/svHD1ZYgVmZz7umLS+1kp+rMCfrlr1QlH4kEW8eb5PqRmhxTqTXlkuk3rsCat7lCk2J11YlMQRQby0zlnTvEWvXZabTnkvT+LlwJaTdwXsBf9AeYYkEossN+9Evcfo0PWSGmUd
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39380400002)(366004)(39860400002)(57704003)(55674003)(199004)(189003)(93886005)(99286004)(59450400001)(53546011)(76176011)(7696005)(478600001)(561944003)(6506007)(5250100002)(102836004)(110136005)(25786009)(2900100001)(2950100002)(229853002)(316002)(2501003)(5660300001)(68736007)(106356001)(105586002)(55016002)(236005)(14454004)(9686003)(54896002)(53936002)(6436002)(6306002)(33656002)(6246003)(53946003)(8676002)(81156014)(606006)(81166006)(8936002)(966005)(2906002)(10710500007)(3280700002)(3660700001)(7110500001)(7736002)(66066001)(74316002)(2420400007)(3846002)(6116002)(15650500001)(97736004)(790700001)(19609705001)(86362001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3803; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 5af06c12-ad5f-41ff-6888-08d55c21e55f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3803;
x-ms-traffictypediagnostic: HE1PR0702MB3803:
x-microsoft-antispam-prvs: <HE1PR0702MB3803FD8ADEB46E4A01B4BB84C2EB0@HE1PR0702MB3803.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(131327999870524)(50582790962513)(202460600054446)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(944501161)(10201501046)(3002001)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:HE1PR0702MB3803; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0702MB3803;
x-forefront-prvs: 0553CBB77A
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: N23Cm8mpFzOvLGLH5K9ozbp2/KQBLY2yjH+z2TZRBF5kc0l1RnfC4iTSpURg4X460raX8jYy8bHX0Oy/a0Qc6Q==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36255BE3FFD891378DED42C2C2EB0HE1PR0702MB3625_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5af06c12-ad5f-41ff-6888-08d55c21e55f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2018 14:11:39.4079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3803
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGObt3d3er4WlqvvhRsZDAmpkWWVhYUSghJf6hiZRTbzq/pptJ RoGWZmiayjQ1S9NNUlZSyCoxwxmmGK00QhNz5ayZKTlw4ie53Qn+93ue53047zkcmhC95rrT svQsRpEuTRVTArIm6uUeySNdTLSf9f32wLzCVl5gr1XDCbT0GshgIiT/3Qw3RK1e5ITctDZS 54loQVACkyrLZhT7j8cKkoqnDGRG1wfi6lhTD5mLClREEaJpwAdBqz1ahAS0CPcgeGCu4bGi D8GUccwuSFxCQNN8A8EmVRwoX8zjsOI3giXD5Lrg0xQOghb9ArIFLtiM4O2/Zq4tcMYSyF+2 EDZ2wb7wRveEy3IyjDbfo2xMYm8wLeWSNhbiWGh8aqLYE+a4MD2kshf4WApz2h92RtgLxhe+ 2wsEdoNvpnr7FoAxqDsNBMuuMDWx5piPB8tICZf1d8HK4E+KZS8YrC+2bw1Yx4E6U6djKACK yjbYTEHF6mGWw+DuaA+PLVQhKJnRk2ywD76ozY4t5FBYPuQYeojA0KJ1HNFGQPvkR0fDE9r0 VZwyJKnddA2W5VBqtHBr7e+xDfprTCTr+8JwpYpieS80P54mWJZA9Zqe3Ow3IF4rclUyyri0 RP8AX0Yhi1cq5em+6UzWC7T+obrbl71foaG/J/QI00i8VdheFxMt4kqzlTlpegQ0IXYR5kWs W8IEac41RiG/pLiSyij1yIMmxW7C/lBhtAgnSrOYFIbJYBQbKYfmu+eiO881O06tnMzRGI1h 7omm7s7w4WPBwtB84uxp/5WdW2Qw69clvHh5wKm3271gemLeKdLDvz+zwufCGUWHZuD+rWcV uyPjIipXP5XEWXl+yV3VZtQy+0v3eaTRM6/+j9zsrItCaPw2eeNcad9XKiKzYzyls001cT2c bz4SEXOoX0wqk6QHfAiFUvofJZWU70wDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecn-in-quic/mgLk5Zcim8hQgphwfR_LO4QbikY>
Subject: Re: [Ecn-in-quic] ECN in QUIC update and questions
X-BeenThere: ecn-in-quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "ECN in the QUIC protocol discussion list." <ecn-in-quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecn-in-quic>, <mailto:ecn-in-quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecn-in-quic/>
List-Post: <mailto:ecn-in-quic@ietf.org>
List-Help: <mailto:ecn-in-quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecn-in-quic>, <mailto:ecn-in-quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 14:11:49 -0000

Gentlepeople!

I have now written up the suggested draft text in
https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#suggested-additions-to-to-become-rfcs

Currently it covers:

  *   ACK_ECN frame format (transport draft)
  *   Capability exchange (transport draft)
  *   Connection migration (transport draft)
  *   ECN reaction (recovery draft)

In addition I have asked for a presentation slot at the interim.

/Ingemar

From: Ecn-in-quic [mailto:ecn-in-quic-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: den 11 januari 2018 17:51
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>; Roni Even (A) <roni.even@huawei.com>; ecn-in-quic@ietf.org
Subject: Re: [Ecn-in-quic] ECN in QUIC update and questions

Hi
I wrote up a section that describes the suggested addition to section 8.16++ in the transport draft. I was in a bit of a hurry so there are a few potential grammatical/spelling errors.
https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#suggested-additions-to-to-become-rfcs

/Ingemar

From: Ingemar Johansson S
Sent: den 10 januari 2018 10:18
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com<mailto:koen.de_schepper@nokia-bell-labs.com>>; Roni Even (A) <roni.even@huawei.com<mailto:roni.even@huawei.com>>; ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>>
Subject: RE: ECN in QUIC update and questions

Hi

My thoughts...
Frame format:
As I understand things from earlier discussion, the idea is that we create a new frame type, that we can call "ACK_ECN". This frame will contain all the possible elements of the ACK frame, with the ECN block appended at the end.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Largest Acknowledged (i)                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ACK Delay (i)                      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ACK Block Count (i)                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ACK Blocks (*)                     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ECN Block                         ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 7: ACK_ECN Frame Format
This would mean that we create a new section "8.16++" for this in the transport draft
The ECN block is then presented in section "8.16++.1"

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# ECT(0) marked packets (i)                                 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# ECT(1) marked packets (i)                                 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# ECN-CE marked packets (i)                                 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description of ECN capability check:
I believe that this should go into section 7.6 in the transport draft.

ECN counters and how the ECN Block data is filled in:
I don't seem to find any section that describes the reception of packets in the transport and recovery drafts. For lack of better alternatives I then think that a description of this should be in a section "8.16++.2" in the transport draft.

Response to ECN-CE:
This should go into the recovery draft, preferably a new section "4.7.6++" On Packets Marked with appropriate pseudo code. It is for now sufficient that it describes the "classic" behavior (ECT(0)). L4S behavior can be left to later, with a reference to the ECN experiment draft.


/Ingemar


From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:koen.de_schepper@nokia-bell-labs.com]
Sent: den 8 januari 2018 14:41
To: Roni Even (A) <roni.even@huawei.com<mailto:roni.even@huawei.com>>; Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>>; ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Subject: RE: ECN in QUIC update and questions

Ah yes, you are right. It will be spread over different sections and even drafts... We must make sure that the ECN spec does not become too fragmented, either.

Indeed the Chairs have to decide, but it would be good if we would have a proposal or an initial idea. I don't have a good view on the QUIC drafts structure, but I think some other people in our design team have.
Agreed that the frame format could go in the transport draft ACK section 8.16. As for ACK-Blocks the section has (next to the format spec) also some semantics and usage (procedural) explanations, so we could have similar sections there. It could give an overview how and under which conditions ECN is used. The relevant detailed functionality can be collocated near topics that are related. I'll give it a go:

  *   I think the ECN capability check should be collocated with where is described how new connections are set-up.
  *   We might need some description of receiver ECN counters located with text that describe where packets are received per connection (and probable where already ACK sequence counters/state is handled).
  *   Also how these counters are used to fill in the ECN fields in the ACK packet, near where ACK packets are send per connection.
  *   How the counters are used (for congestion control) when the sender receives ACKs is probably what you mentioned for the recovery draft? And where the ECT(0)/ECT(1) text should end up? I guess this is where QUIC congestion window and control is handled (currently only reno?), right?

Anyone who has an idea which drafts/sections these would be? Some of these topics might even end up close to each other, after all?

Koen.


From: Roni Even (A) [mailto:roni.even@huawei.com]
Sent: Monday, January 8, 2018 1:54 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com<mailto:koen.de_schepper@nokia-bell-labs.com>>; Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>>; ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Subject: RE: ECN in QUIC update and questions

Hi Koen,
I have no preference but I agree that it can be in the current drafts, this is something to discuss with the WG chairs. Drafts, because the frame format should be in the transport  (if with ack then in section 8.16) for the receiver report on ECN. The procedures should be in the  recovery but I am not so sure about the part about ECN capability negotiation where it belongs.
At the moment we can have the proposed solution in the wiki and add there some text about ECT(1)

Roni

From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:koen.de_schepper@nokia-bell-labs.com]
Sent: Monday, January 08, 2018 2:45 PM
To: Roni Even (A); Ingemar Johansson S; ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Subject: RE: ECN in QUIC update and questions

Hi Roni,

As appropriate ECN congestion response is not only related to QUIC, it should be defined according to your second option: "have some reference".

I think it is important that the ECN-Echo feedback protocol is in place. For now the sender can use ECT(0) with a reno compatible congestion response according to the standards. Additionally, the QUIC ECN-Echo mechanism should support experiments with ECT(1), which I think is the case in the current proposal. It is in line with the Accurate ECN feedback draft, which also supports ECN experimentation. Any experiments that will be defined for ECT(1) (and also ECT(0)) are applicable.

I saw some of your mails too in the meantime. I agree that we should clarify this.

Related to the question of a draft or wiki, this is also my question. Will this finally become a separate draft, or should we organize the wiki as a chapter of an existing QUIC draft that we target? I think it will be the second option here, right? Which draft and chapter should this be?

Koen.



From: Roni Even (A) [mailto:roni.even@huawei.com]
Sent: Monday, January 8, 2018 1:21 PM
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>>; ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com<mailto:koen.de_schepper@nokia-bell-labs.com>>
Subject: RE: ECN in QUIC update and questions

Hi,

My understanding from ECN experiments draft  "It is essential that any such change in ECN congestion marking behavior be counterbalanced by use of a different IETF-approved congestion response to CE marks at the sender"

is that there must be different congestion response for ECT(0) and ECT(1) and it is not specified in ECN experiments draft.

So currently we will not have consistent congestion handling for the two ECT until we specify the congestion handling in QUIC or have some reference.

Roni

From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
Sent: Monday, January 08, 2018 1:30 PM
To: Roni Even (A); ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Cc: De Schepper, Koen (Nokia - BE/Antwerp)
Subject: RE: ECN in QUIC update and questions

Hi

Thanks, I corrected the bytes-packet error. The document will not talk about congestion handling in this version, this is left was a later exercise and the intention is that ECT(0) and ECT(1) should be handled as per the recommendations in the  ECN experiments draft (soon RFC). The use of ECT(0) or ECT(1) will be a sender decision as the congestion control is on the sender side.

/Ingemar


From: Roni Even (A) [mailto:roni.even@huawei.com]
Sent: den 8 januari 2018 12:23
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>>; ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com<mailto:koen.de_schepper@nokia-bell-labs.com>>
Subject: RE: ECN in QUIC update and questions

Hi,

I noticed that there are still places where bytes are used instead of packets "sufficient with a report of accumulated number of bytes " and "number of ECT marked bytes(or packets) ".

Are you going to say something about when to use ECT(0) and when ECT(1). Is this a sender decision and how is it made?

I understand that the document will not talk about congestion handling, so is a different congestion handling for ECT(0) and ECT(1) will be discussed in the QUIC recovery draft or do we need another document?

Roni Even

From: Ecn-in-quic [mailto:ecn-in-quic-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: Monday, January 08, 2018 11:53 AM
To: ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org>
Cc: Ingemar Johansson S; De Schepper, Koen (Nokia - BE/Antwerp)
Subject: [Ecn-in-quic] ECN in QUIC update and questions

Hi

Hope that you have started the new year with lots of new energy.
We (me and Koen) have updated https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC . The main changes are that a lot of superfluous text is removed, for instance there is now only 1 alternative for the ACK+ECN frame. In addition all the extra text that discussed the timestamps is now gone. The ECN capability check is also clarified. Furthermore it is made possible to set ECT also after the ECN capability check.

There are some questions

  1.  I have added some text that outlines how the overhead can be reduced, this text is somewhat speculative and needs more details to qualify as specification text. Should we have this text in the first draft version or do you prefer that it is removed ?.
  2.  Given that this work is presented at the interim, is it necessary to write up a draft or is it sufficient to present the wiki ?


/Ingemar

==================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson Research
Network Protocols & E2E Performance
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>
www.ericsson.com

The world is full of magical things patiently
    waiting for our wits to grow sharper
               Bertrand Russell
==================================