Re: [tcpm] Review of draft-ietf-tcpm-alternativebackoff-ecn-05
"Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com> Wed, 14 February 2018 09:46 UTC
Return-Path: <michael.scharf@nokia.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCECD128961; Wed, 14 Feb 2018 01:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 bUxl1Rf95f-z; Wed, 14 Feb 2018 01:46:11 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0121.outbound.protection.outlook.com [104.47.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6A6128954; Wed, 14 Feb 2018 01:46:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OW0QgDSv/EVnBN14yucYGQSQawC3Gpe808mlP4jsmRM=; b=HY/RM23Jl7Ix94+b51aCsmZMVtzQQ/0cevf6Ave0VqfIf1bE8fyhTRJkX0fjPYivS61LRekLLHvhiGgvVh3uZnVsSbr+v9gV6J9PGa/efo7AdOYOQNaTnFm2CcMct+qYbfZ2A5/CQ2p+7Mtiw2moHoAPcWfiYzh4vKM4FpYjFHE=
Received: from VI1PR0701MB2558.eurprd07.prod.outlook.com (10.173.85.11) by VI1PR0701MB1933.eurprd07.prod.outlook.com (10.167.209.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Wed, 14 Feb 2018 09:46:07 +0000
Received: from VI1PR0701MB2558.eurprd07.prod.outlook.com ([fe80::9825:195f:7649:8008]) by VI1PR0701MB2558.eurprd07.prod.outlook.com ([fe80::9825:195f:7649:8008%17]) with mapi id 15.20.0506.011; Wed, 14 Feb 2018 09:46:07 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
To: Naeem Khademi <naeemk@ifi.uio.no>
CC: "draft-ietf-tcpm-alternativebackoff-ecn@ietf.org" <draft-ietf-tcpm-alternativebackoff-ecn@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: Review of draft-ietf-tcpm-alternativebackoff-ecn-05
Thread-Index: AdOHRCmk6LmPog6RT5iBs2Z7tL2zGQeJ9z6AAAL1oKA=
Date: Wed, 14 Feb 2018 09:46:07 +0000
Message-ID: <VI1PR0701MB255867D97B074F69A020342F93F50@VI1PR0701MB2558.eurprd07.prod.outlook.com>
References: <AM5PR0701MB25477DB68DEEDCADECDF4C5D931D0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <8EC5BA0C-61E0-4304-860F-E3D5D135A031@ifi.uio.no>
In-Reply-To: <8EC5BA0C-61E0-4304-860F-E3D5D135A031@ifi.uio.no>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [92.203.128.126]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB1933; 7:juGsk5qLtaV8Z43FONcTPeEch8CSKiWpKXcRhRlEMSaIpah2VI7K/gKN9eQ+e1Sum/q6bLL4CwzfaJVxGcbv9QdIZaLiyoos7jpUZDeMjSBvifXGAyJ8ExM6QiGfbQr3Ppvjx1mO5UR6LA5kVCoxWkjs+ChBd+ZIVFyKqHvWj8NzQ/nQXw1Kecqxuh1pqdNki+ISjhybQDVfrwqpZ0AcljqRWgDIeHFBZUgdKrovXB9mRDuUhjSYmmf2UUEf7q6B
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 2350660c-b6fe-4196-2aee-08d5738fc57f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR0701MB1933;
x-ms-traffictypediagnostic: VI1PR0701MB1933:
x-microsoft-antispam-prvs: <VI1PR0701MB1933C72A6ADDF1E19DA6EAAC93F50@VI1PR0701MB1933.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(82608151540597)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(11241501184)(806099)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041288)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0701MB1933; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB1933;
x-forefront-prvs: 0583A86C08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(376002)(39380400002)(189003)(199004)(186003)(59450400001)(6916009)(106356001)(74316002)(7736002)(81156014)(66066001)(81166006)(606006)(26005)(6346003)(8936002)(316002)(5660300001)(97736004)(53936002)(790700001)(6116002)(53546011)(6506007)(76176011)(102836004)(2950100002)(6246003)(2906002)(3846002)(55016002)(99286004)(229853002)(2900100001)(54896002)(5250100002)(236005)(9686003)(6306002)(6436002)(3660700001)(54906003)(86362001)(25786009)(68736007)(14454004)(33656002)(105586002)(19609705001)(4326008)(3280700002)(7696005)(8676002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB1933; H:VI1PR0701MB2558.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com;
x-microsoft-antispam-message-info: reSZv/UAzzJJuKC5S+ZY37rX5tpcPvpH/62OFkU8KuTJQsWfdVTJsluErU7wlujYUMGCDfyyvQns/ZgbpSEcP9EHjr5HyW2vwAtIYpPp1uK5lrMcSfEcHRRFGvtXiGfj
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB255867D97B074F69A020342F93F50VI1PR0701MB2558_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2350660c-b6fe-4196-2aee-08d5738fc57f
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 09:46:07.1881 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1933
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_ySb3AM_5rX8yA6hutO_mBbVGi4>
Subject: Re: [tcpm] Review of draft-ietf-tcpm-alternativebackoff-ecn-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2018 09:46:15 -0000
Thanks a lot, the changes work for me. As an individual contributor to TCPM I believe the doc is ready for WGLC. Michael From: Naeem Khademi [mailto:naeemk@ifi.uio.no] Sent: Wednesday, February 14, 2018 10:16 AM To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com> Cc: draft-ietf-tcpm-alternativebackoff-ecn@ietf.org; tcpm@ietf.org Subject: Re: Review of draft-ietf-tcpm-alternativebackoff-ecn-05 Hi Michael Thanks a lot for the feedback. We have submitted the -06 version based on your reviews (https://www.ietf.org/internet-drafts/draft-ietf-tcpm-alternativebackoff-ecn-06.txt). Here are some inline responses to your comments: On Jan 7, 2018, at 12:18 AM, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>> wrote: Authors, all, I have read draft-ietf-tcpm-alternativebackoff-ecn-05. I found some minor issues that should be easy to fix; in many cases the issues are editorial. Yet, I believe a document update would be useful. See below [ms]. Thanks Michael (with no hat on) ******************************* Abstract Recent Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. [ms] Nit: I am not sure if the term “recent” is really needed. IMHO any AQM, including old vanilla RED, can have this property, if it is properly configured. As a result, I think the sentence would also be correct without the word “recent”. This would somewhat avoid the question (in particular in the abstract) how to handle bottlenecks that use e.g. vanilla RED instead of a “recent” AQM. NKH: fixed. 1. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. [ms] Nit: Maybe the new wording in RFC8174 could be used. As an editorial nit, Section 1 and 2 could be swapped, but the order may be a matter of taste. NKH: done. 4.1. Why Use ECN to Vary the Degree of Backoff? When packet loss is inferred using the retransmission timer and the given packet has not yet been resent by way of the retransmission timer (regarded as a notification of congestion), Standard TCP sets the ssthresh to the maximum of half of the FlightSize and 2*SMSS [RFC5681], which causes the TCP congestion control to go back to allowing only a BDP of packets in flight -- just sufficient to maintain 100% utilisation of the bottleneck on the network path. [ms] This reference of RFC5681 and eq. (4) therein only mentions the reaction to RTO (Section 3.1 in RFC5681) but omits the use in Fast Retransmit/Fast Recovery (Section 3.2 in RFC5681). Thus, the reference is a bit misleading, since this section actually seems to be about Fast Retransmit/Fast Recovery. And, as a purely editorial remark, I think the sentence is long and hard to parse. I think an alternative wording would be possible along the lines of: <ms> According to [RFC5681], when a TCP sender detects segment loss using the retransmission timer and the given segment has not yet been resent by way of the retransmission timer, the value of ssthresh must be set to no more of the maximum of half of the FlightSize and 2*SMSS. The same equation is also used during Fast Retransmit/Fast Recovery [RFC5681]. As a result, the TCP congestion control only allows one BDP of packets in flight. This is just sufficient to maintain 100% utilisation of the bottleneck on the network path. </ms> NKH: used the proposed wording. 4.2. Focus on ECN as Defined in RFC3168 Some transport protocol mechanisms rely on ECN semantics that differ from the original ECN definition [RFC3168] -- for example, Congestion Exposure (ConEx) [RFC7713] and Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] need more accurate ECN information than that offered by the original feedback method. Other mechanisms (e.g., [I-D.ietf-tcpm-accurate-ecn]) allow the sender to adjust the rate more frequently than once each path RTT. Use of these mechanisms is out of scope for this document. [ms] I think [I-D.ietf-tcpm-accurate-ecn] specifies a scheme to provide more than one feedback signal per RTT. It is not exactly clear to me what is meant by “adjusting the rate more frequently”. Editorial nits: DCTCP is published as RFC 8257. And I think the subsection title could be repeated in the main text (“This specification focuses on…”). NKH: the block of text reads as the following now: Some transport protocol mechanisms rely on ECN semantics that differ from the original ECN definition [RFC3168]. For instance, Accurate ECN [I-D.ietf-tcpm-accurate-ecn] permits more frequent and detailed feedback. Use of mechanisms (such as Accurate ECN, Datacenter TCP (DCTCP) [RFC8257], or Congestion Exposure (ConEx) [RFC7713]) is out of scope for this document. This specification focuses on ECN as defined in [RFC3168]. 4.3. Choice of ABE Multiplier ABE decouples the reaction of a TCP sender to inferred packet loss and ECN-signalled congestion when in the congestion avoidance phase by differentiating the scaling factor used in Equation 4 in Section 3.1 of [RFC5681]. [ms] Editorial nit: This sentence seems somewhat broken (“when”?). Maybe an alternative would be: <ms> ABE decouples the reaction of a TCP sender to inferred packet loss and ECN-signalled congestion in the congestion avoidance phase. To achieve this, ABE uses different the scaling factor in Equation 4 in Section 3.1 of [RFC5681]. </ms> NKH: fixed based on the suggested text. beta_{ecn} depends on how the response of a TCP connection to shallow AQM marking thresholds is optimised. beta_{loss} reflects the preferred response of each congestion control algorithm when faced with exhaustion of buffers (of unknown depth) signalled by packet loss. Consequently, for any given TCP congestion control algorithm the choice of beta_{ecn} is likely to be algorithm-specific, rather than a constant multiple of the algorithm's existing beta_{loss}. The recommended beta_{ecn} value in this document is only applicable for Standard TCP congestion control. [ms] In this section one has to reverse-engineer what “recommended beta_{ecn} value in this document” means. Why not make this explicit? In addition, with some editorial reordering this section could be easier to read, e.g., as follows: <ms> The recommendation in Section 3 in this document corresponds to a value of beta_{ecn}=0.8. This recommended beta_{ecn} value is only applicable for the standard TCP congestion control [RFC5681]. The selection of beta_{ecn} enables tuning the response of a TCP connection to shallow AQM marking thresholds. beta_{loss} characterizes the response of a congestion control algorithm to packet loss, i.e., exhaustion of buffers (of unknown depth). Different values for beta_{loss} have been suggested for TCP congestion control algorithms. Consequently, beta_{ecn} is likely to be an algorithm-specific parameter rather than a constant multiple of the algorithm's existing beta_{loss}. </ms> NKH: inserted the proposed text. 5. ABE Requirements [ms] Edorial nit: An alternative title would maybe “ABE Deployment Requirements”. NKH: done. If the method is only deployed by some senders, and not by others, the senders that use this method can gain some advantage, possibly at the expense of other flows that do not use this updated method. Because this advantage applies only to ECN-marked packets and not to packet loss indications, in the worst case (e.g., an ABE-compliant TCP sender using beta_{ecn} = 1.0) the ECN-Capable bottleneck will still fall back to dropping packets, and the result is no different than if the TCP sender was using traditional loss-based congestion control. [ms] beta_{ecn} = 1.0 can imply that a TCP sender does not react *at all* to ECN marks, right? If so, I would suggest to reword this section in order to avoid the expression “ABE-compliant” for the case beta_{ecn} = 1.0. For instance, the second sentence could be reworded to something like “Because this advantage applies only to ECN-marked packets and not to packet loss indications, an ECN-Capable bottleneck will still fall back to dropping packets if an TCP sender using ABE is too aggressive, and the result is no different…” NKH: changed to the proposed text. ABE also makes one congestion-response each RTT that congestion is signalled, and therefore there is no response to loss within the same round-trip time, since ABE has already made a reduction of the congestion window. ABE will however respond for each round-trip time that congestion continues to be signaled. [ms] Editorial nit: These sentences are hard to parse. NKH: changed it to the following. Hope it reads better now: ABE also responds to congestion once per RTT, and therefore it does not respond to further loss within the same RTT, since ABE has already reduced the congestion window. If congestion persists after such reduction, ABE continues to reduce the congestion window in each consecutive RTT. The result of this Internet experiment will include an investigation of cases such as the ones listed above, and be reported by presentation to the TCPM WG (or IESG) or an implementation report at the end of the experiment. [ms] I am not sure if we really need this paragraph on process details, e.g., whether there will be a presentation. To me, it would be sufficient just to identify what cases and issues need to be investigated as part of the experiment. For what it is worth, as individual contributor, I think a TCPM presentation summarizing the outcome of the experiment would be sufficient for such a short document. But unless e.g. the IESG insists in such wording, I don’t see a need to specify the process inside the document. NKH: changed the text to the following: The result of this Internet experiment ought to include an investigation of the implications of experiencing an ECN-CE mark followed by loss within the same RTT. At the end of the experiment, this will be reported to the TCPM WG (or IESG). Cheers, Naeem
- [tcpm] Review of draft-ietf-tcpm-alternativebacko… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] Review of draft-ietf-tcpm-alternativeb… Naeem Khademi
- Re: [tcpm] Review of draft-ietf-tcpm-alternativeb… Scharf, Michael (Nokia - DE/Stuttgart)