Re: [Ecn-in-quic] ECN in QUIC update and questions
"Roni Even (A)" <roni.even@huawei.com> Mon, 08 January 2018 12:54 UTC
Return-Path: <roni.even@huawei.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 5413C126C19 for <ecn-in-quic@ietfa.amsl.com>; Mon, 8 Jan 2018 04:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01] 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 HCTT64dEU_GD for <ecn-in-quic@ietfa.amsl.com>; Mon, 8 Jan 2018 04:54:19 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 19AB01242F5 for <ecn-in-quic@ietf.org>; Mon, 8 Jan 2018 04:54:19 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6F618E03D44F5; Mon, 8 Jan 2018 12:54:15 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 8 Jan 2018 12:54:16 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Mon, 8 Jan 2018 20:54:10 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "ecn-in-quic@ietf.org" <ecn-in-quic@ietf.org>
Thread-Topic: ECN in QUIC update and questions
Thread-Index: AdOIZnQBD0hOX0sQSLyS4r+GfAJf8wAC53rAAABaAiAAAbf0gAAAf4OwAACi1fA=
Date: Mon, 08 Jan 2018 12:54:10 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD85D54E@DGGEMM506-MBX.china.huawei.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>
In-Reply-To: <VI1PR0701MB2126FA6D40DEC3CEDF2D50B2B9130@VI1PR0701MB2126.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.69]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD85D54EDGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecn-in-quic/e0EK7giJlraWDt7QSMlzuQfU9Ug>
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, 08 Jan 2018 12:54:22 -0000
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 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 ==================================
- [Ecn-in-quic] ECN in QUIC update and questions Ingemar Johansson S
- Re: [Ecn-in-quic] ECN in QUIC update and questions Roni Even (A)
- Re: [Ecn-in-quic] ECN in QUIC update and questions Ingemar Johansson S
- Re: [Ecn-in-quic] ECN in QUIC update and questions Roni Even (A)
- Re: [Ecn-in-quic] ECN in QUIC update and questions Ingemar Johansson S
- Re: [Ecn-in-quic] ECN in QUIC update and questions Roni Even (A)
- Re: [Ecn-in-quic] ECN in QUIC update and questions De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [Ecn-in-quic] ECN in QUIC update and questions Roni Even (A)
- Re: [Ecn-in-quic] ECN in QUIC update and questions De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [Ecn-in-quic] ECN in QUIC update and questions Ingemar Johansson S
- Re: [Ecn-in-quic] ECN in QUIC update and questions Ingemar Johansson S
- Re: [Ecn-in-quic] ECN in QUIC update and questions Ingemar Johansson S