From nobody Thu Aug 1 01:51:04 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C0D1200C5; Thu, 1 Aug 2019 01:50:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <156464945486.19191.12879029242943579270@ietfa.amsl.com> Date: Thu, 01 Aug 2019 01:50:54 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 08:50:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Benjamin Hesmans Filename : draft-ietf-tcpm-converters-10.txt Pages : 48 Date : 2019-08-01 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-10 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 1 01:57:40 2019 Return-Path: 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 3A8441200CE; Thu, 1 Aug 2019 01:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 Oc8Niq0pd2K3; Thu, 1 Aug 2019 01:57:34 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3E81200B1; Thu, 1 Aug 2019 01:57:34 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 45zkhD3vMXz106v; Thu, 1 Aug 2019 10:57:32 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 45zkhD31T1zFpXJ; Thu, 1 Aug 2019 10:57:32 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 1 Aug 2019 10:57:32 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09? Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llAALWUTAA== Date: Thu, 1 Aug 2019 08:57:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 08:57:38 -0000 Phil,=20 I prepared an updated version with the following changes to address your re= maining comments:=20 * Position Figure 1 right after the text about upstream/downstream connecti= ons to avoid the confusion about the direction. * Delete "(1)" from Figure 5 caption * Add text to clarify why "eventually" is used in the text. Rearranged the = text about address preservation/sharing modes, accordingly.=20 * Section 3.2: remove the text about inserting Convert TLVs in "subsequent = messages".=20 * Section 3.3: add finally a side not to remind that RST does not close an = MPTCP connection, and hence is not reflected by the converter on the TCP co= nnection.=20 * Section 4 (Introduction): Clarified that both control and data messages a= re sent over a relayed connection. I hesitated to add the NEW text you prop= osed about relaying connections, but finally discarded it because the behav= ior is already described in many places in the documents. No need to be red= undant. =20 * Update Figures 11/19 * Add an appendix to record the design considerations from the changes log. I also made some other edits to fix some nits.=20 You may check the full diff at: https://www.ietf.org/rfcdiff?url1=3Ddraft-i= etf-tcpm-converters-09&url2=3Ddraft-ietf-tcpm-converters-10=20 Thank you for the review.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: mercredi 31 juillet 2019 14:22 > =C0=A0: philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; tcpm@ietf.= org > Cc=A0: tcpm-chairs@ietf.org > Objet=A0: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converter= s- > 09? >=20 > Hi Phil, >=20 > Thank you for double checking. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > > philip.eardley@bt.com > > Envoy=E9=A0: mercredi 31 juillet 2019 12:26 > > =C0=A0: Michael.Scharf@hs-esslingen.de; tcpm@ietf.org > > Cc=A0: tcpm-chairs@ietf.org > > Objet=A0: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm- > converters- > > 09? > > > > I think most of my comments are addressed. Here are some things I think > > could still be clarified, plus a couple of extra questions that occurre= d > > to me when I was checking the latest version. > > > > Section 3.1 > > < > assumes outgoing connections as default.>> > > > > This sentence seems to contradict itself (can something be both assumed > > and have to be explicitly stated?). >=20 > [Med] Yes. Consider for example the following text: >=20 > "By default, the Transport Converter listens on TCP port number TBA > for Convert protocol (Convert, for short) messages from Clients. >=20 > Clients send packets that are eligible to the conversion service to > the provisioned Transport Converter using TBA as destination port > number. Additional information is supplied by Clients to the > Transport Converter by means of Convert messages as detailed in the > following sub-sections." >=20 > It applies only for the outgoing connections. >=20 > Maybe:- > > In general this document assumes that the client initiates the > connection > > (in other words, it is an outgoing connection); the scenario with an > > incoming connection is discussed in a couple of places [references]. >=20 > [Med] I can use this wording if you think it is better. >=20 > > > > In Figure 1 I find the 'upstream' and 'downstream' labels a bit > confusing > > (especially as the lines have arrowheads in both directions), and it is > > shown as the link between client and converter etc. I think it would be > > better to move lower down (ie separate from the actual link), something > > like: > > -------> upstream direction (outgoing connections) > > <------ downstream direction (incoming connections) > > >=20 > [Med] Actually, upsteram and downstream are defined as follows: >=20 > o the upstream connection is the one between the Client and the > Transport Converter. >=20 > o the downstream connection is between the Transport Converter and > the Server. >=20 > This is independent of the connection direction. >=20 > > Figure 5 caption has a stray "(1)" that can be deleted >=20 > [Med] Fixed. >=20 > > > > Above Figure 6 > > < > > > >=20 > [Med] "eventually" is justified: cover the case of a converter configured > in an address preservation mode (e.g., IPv6). The destination IP address > won't be rewritten in such case. >=20 >=20 > > Section 3.2 / 3.3 > > There are two paragraphs at the end of 3.2 and a bit more in 3.3 > > discussing what happens when a connection ends with FIN and TCP RST etc= . > I > > think you should write a bit more about the MPTCP case - since there ar= e > > subflow TCP RST and MP_FASTCLOSE cases to consider. A TCP RST on one > MPTCP > > subflow presumably shouldn't trigger the Converter to close the TCP > > connection on its other interface. >=20 > [Med] Section 3.2 covers the generic TCP case. Hence, there is no need to > discuss MPTCP specifics in that section. >=20 > I guess you are referring to this text in Section 3.3: >=20 > Note that, if the TCP connection fails for some reason, the Converter > tears down the Multipath TCP connection by transmitting a > MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with > the transmission of DATA_FINs, the Converter terminates the TCP > connection by using FIN segments. >=20 > The text covers exclusively the cases that lead to the termination of the > upstream/downstream connection. >=20 > Given that MPTCP spec says: >=20 > "With MPTCP, the RST only has the scope of the > subflow and will only close the concerned subflow but not affect the > remaining subflows. MPTCP's connection will stay alive at the data > level, in order to permit break-before-make handover between > subflows." >=20 > the subflow RST is not covered (as it does not terminate the MPTCP leg). >=20 > > > > Section 4 intro > > > > << This section describes the messages that are exchanged between a > > Client and a Transport Converter. > > > > By default, the Transport Converter listens on TCP port number TBA > > for Convert protocol (Convert, for short) messages from Clients. > > > > Clients send packets that are eligible to the conversion service to > > the provisioned Transport Converter using TBA as destination port > > number. Additional information is supplied by Clients to the > > Transport Converter by means of Convert messages as detailed in the > > following sub-sections. > > > > Convert messages may appear only in a SYN, SYN+ACK, or ACK. > > > > Convert messages MUST be included as the first bytes of the > > bytestream. A Convert message starts with a 32 bits long fixed > > header (Section 4.1) followed by one or more Convert TLVs (Type, > > Length, Value) (Section 4.2). > > >> > > > > Some comments: > > The Client also listens on TCP port TBA (not just the converter) >=20 > [Med] The client will listen on the internal port number that it indicate= d > when creating a mapping in the converter to allow for incoming > connections. This is needed to demux services hosted on the same client. >=20 > This is covered in this text: >=20 > The Converter accepts the request by creating a TCP > mapping (internal IP address, internal port number, external IP > address, external port number). The external IP address and external > port number will be then advertised using an out-of-band mechanism so > that remote hosts can initiate TCP connections to the Client via the > Converter. Note that the external and internal information may be > the same. >=20 > > Stress that ALL convert msgs start with the same header. > > I think the "Clients send packets..." para is better re-arranged. > > > > Question: there seems to be a contradiction. The text here says "Conver= t > > messages may appear only in syn, syn-ack, ack". But then in S3.2 it say= s > > "This information is sent at the beginning of the bytestream, either > > directly in the SYN+ACK or in a subsequent packet." (this information i= s > > "about the TCP options that were negotiated with the Server.") > > (Incidentally, in S3.2 essentially the same sentence is repeated two > > sentences later.) is the idea that SYN / syn-ack /ack is the 'normal' > > case, but can be in later pkts? >=20 > [Med] Good catch. >=20 > OLD: > The Client sends a SYN destined to the Transport Converter. The > payload of this SYN contains the address and port number of the > Server. The Transport Converter does not reply immediately to this > SYN. It first tries to create a TCP connection towards the target > Server. If this upstream connection succeeds, the Transport > Converter confirms the establishment of the connection to the Client > by returning a SYN+ACK and the first bytes of the bytestream contain > information about the TCP options that were negotiated with the > Server. This information is sent at the beginning of the bytestream, > either directly in the SYN+ACK or in a subsequent packet. For > graphical reasons, the figures in this section show that the > Transport Converter returns this information in the SYN+ACK packet. > An implementation could also place this information in a packet that > it sent shortly after the SYN+ACK. >=20 > NEW: > The Client sends a SYN destined to the Transport Converter. The > payload of this SYN contains the address and port number of the > Server. The Transport Converter does not reply immediately to this > SYN. It first tries to create a TCP connection towards the target > Server. If this upstream connection succeeds, the Transport > Converter confirms the establishment of the connection to the Client > by returning a SYN+ACK and the first bytes of the bytestream contain > information about the TCP options that were negotiated with the > Server. >=20 >=20 > > > > Question: the text says "Clients send packets that are eligible to the > > conversion service to the provisioned Transport Converter using TBA as > > destination port number." Is this referring to the exchange of Convert > > protocol messages? Or is this referring to subsequent data that is > > actually sent to the TBA port number? I think the text implies the > latter, > > which I assume is not correct. >=20 > [Med] This applies to all messages that cross the converter. >=20 > > > > > > Suggested text:- > > > > << > > This section defines the Convert protocol (Convert, for short) > messages > > that are exchanged between a Client and a Transport Converter. > > > > Convert messages MUST be sent to TCP destination port TBA. Therefore= , > a > > Transport Converter and a Client listen on this TCP port for Convert > > messages. >=20 > [Med] The initial wording is correct. >=20 > > Convert messages MAY appear in a SYN, SYN+ACK, or ACK or MAY appear > in > > a subsequent packet. >=20 > [Med] The initial wording is correct. >=20 > > Convert messages MUST be included as the first bytes of the bytestream. > > All Convert messages start with a common 32 bits long header (Section > > 4.1), followed by one or more Convert TLVs (Type, Length, Value) > (Section > > 4.2). > > After a successful exchange of Convert messages, a TCP connection with > TCP > > extension(s) is established between the Client and Transport Converter > > (for instance, Multipath TCP), and a (normal) TCP connection is > > established between the Transport Converter and other end host, with th= e > > Transport Converter acting as an explicit proxy between the two > > connections (for instance, between MPTCP and TCP). >=20 > [Med] No problem (even if the last sentence is already stated in previous > sections). >=20 > > >> > > > > > > Section 4.0, 4.2.6 etc > > Various places say things like "the Unassigned field MUST be set to zer= o > > by the transmitter and > > ignored by the receiver. These bits are available for future use > > [RFC8126]." > > Comment: I heard in ietf-105 about problems for extensibility of variou= s > > protocols because implementations insist on all zeroes for fields, > > otherwise discard packets. The suggestion is to grease (which I think > > means that the senders set to random values and receivers MUST ignore) >=20 > [Med] I don't see the value for doing this. >=20 > > Also, 'sender' rather than 'transmitter' >=20 > [Med] Fixed. Thanks. >=20 > > > > Figure 11 > > In the figure you have Value being optional in bits 16-31 and compulsor= y > > in bits 32+. I think this should be the other way round. >=20 > [Med] OK. >=20 > > > > Section 4.2.8 > > "This TLV has a variable length. It appears after the Convert fixed- > > header in the bytestream returned by the Transport Converter." > > Figure 19 doesn't show variable length. Must its length be a multiple o= f > > 32 bytes (padded if needed)? (I assume so, to be consistent with > > elsewhere.) >=20 > [Med] Agree. Fixed the figure. >=20 > Padding is mentioned in the error description (when appropriate), e.g.,: >=20 > "The > list of unsupported TCP options MUST be padded with zeros to end > on a 32 bits boundary. " >=20 > > The second sentence could be deleted, since elsewhere text says the > TLV(s) > > must be at the start of the bytestream. But if you keep the sentence I > > suggest you say "appears _immediately_ after" > > >=20 > [Med] Deleted that sentence. No need to be redundant. >=20 > > S6 > > "The case of a middlebox that removes the payload of SYN+ACKs (but the > > payload of SYN) can be detected by a Client." > > Do you mean: but _not_ the payload of SYN? >=20 > [Med] Yes. >=20 > > > > < > This section to be removed before publication.>> > > It would be really nice if somehow the material here that explains the > > design rationale, and development from earlier approaches, could be > kept. > > It's useful info, I think. >=20 > [Med] OK, added a new appendix to cover the key points. >=20 > > > > Best wishes, > > phil > > > > -----Original Message----- > > From: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > > Sent: 22 July 2019 09:01 > > To: Eardley,PL,Philip,TUD1 R > > Cc: tcpm-chairs@ietf.org > > Subject: WGLC comments addressed in draft-ietf-tcpm-converters-09? > > > > Hi Phil, > > > > Could you please have a look at -09 and let me know if your WGLC > comments > > are addressed? > > > > If not, please follow-up on the mailing list. > > > > Thanks > > > > Michael > > > > -----Original Message----- > > From: tcpm On Behalf Of internet-drafts@ietf.or= g > > Sent: Monday, July 22, 2019 8:04 AM > > To: i-d-announce@ietf.org > > Cc: tcpm@ietf.org > > Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the TCP Maintenance and Minor Extensions W= G > > of the IETF. > > > > Title : 0-RTT TCP Convert Protocol > > Authors : Olivier Bonaventure > > Mohamed Boucadair > > Sri Gundavelli > > SungHoon Seo > > Benjamin Hesmans > > Filename : draft-ietf-tcpm-converters-09.txt > > Pages : 47 > > Date : 2019-07-21 > > > > Abstract: > > This document specifies an application proxy, called Transport > > Converter, to assist the deployment of TCP extensions such as > > Multipath TCP. This proxy is designed to avoid inducing extra delay > > when involved in a network-assisted connection (that is, 0-RTT). > > > > This specification assumes an explicit model, where the proxy is > > explicitly configured on hosts. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tcpm-converters-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-09 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-09 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Aug 1 07:20:33 2019 Return-Path: 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 938A3120193 for ; Thu, 1 Aug 2019 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 4gJPnKJrfGWs for ; Thu, 1 Aug 2019 07:20:28 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C4BB51200CC for ; Thu, 1 Aug 2019 07:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uWkIIcGyVTeMBJhcumYX8Kq2SOnkS0Gbmb5WmnNdd2Y=; b=Gx3xsFvCKwl1HxBsdG/vxL8dB nCAHSVHVUqCeIVBCAsFbJ8alEv4a+63VEiLR0YFVEDa9OkLyXVgAK/8DW5cdYB7xOGxdRrFb3oF+h 3Si5ER6rA19iTuaS075JbYG6uFjdlyC+3GZFXHwqdvL4Fil/GaEs5aOPJpDa2dSTH11y9GooPspEo g5jP2voX6kIwOCFIIzso207V9GAVzEbeCse1pYQ5K3JEYDAlr62xmSxNx3v4BzTX4QEehNp0jlMCy 9wYzvSID6sUhr074mPPwLK/M7Sje9DIBq9ojj9bxpkNXVkV5qUKK/pfngH3jGloy3Rq/AVkQhdS5E Xgo7hSPVA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52156 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1htBwN-00106D-QQ; Thu, 01 Aug 2019 10:20:28 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_80D3DFC7-03B4-4E1B-BCFC-2B0C668B6E24" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312F7CAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 1 Aug 2019 07:20:20 -0700 Cc: "tcpm@ietf.org" Message-Id: <9D52173A-CA9B-47DA-9EA4-46B4823DD2A9@strayalpha.com> References: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312F7CAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 14:20:32 -0000 --Apple-Mail=_80D3DFC7-03B4-4E1B-BCFC-2B0C668B6E24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Med,=20 See below=E2=80=A6 Joe > On Jul 31, 2019, at 10:38 PM, mohamed.boucadair@orange.com wrote: >=20 > ... > =20 > [Med] What I had in mind is to import the option layout and key = information into 793bis. I don=E2=80=99t think it=E2=80=99s particularly useful to duplicate = information this way - esp. for experimental options. > What I=E2=80=99m hoping with this change is to avoid having discussion = similar to = https://mailarchive.ietf.org/arch/msg/tcpinc/fVCnrvMouTdeIuwTytoBRNmztHU = = (end of the message) each time a new option is discussed. =20 We=E2=80=99re going to have that discussion every time anyway - that is = about=20 a) whether a new option under development should be treated as = experimental or standards-track from the start b) whether to endorse squatting on assigned code points Defiance is not ignorance. No amount of text avoids the former. > =20 > - these are not details needed for standards-compliant operation > =20 > [Med] I=E2=80=99m not sure to parse this comment. RFC6994 is a = standard track RFC. > =20 > (esp. because they shouldn't be used for final standards-track = options). The sentence is explained in the note I put below it - although the = method is standards-track (as is congestion control, FWIW), the details = are not critical to a minimal, standards-compliant implementation for a = few reasons: - standards-compliant implementations shouldn=E2=80=99t be deployed = publicly with use of experimental options at all (at best, disabled by = default) - 6994 explains how others will interpret the fields of those code = points anyway, so if you ignore them you=E2=80=99re just risking = overlapping use with others. the length of the EdIDs (esp longer values) = makes that sufficiently unlikely anyway ----= --Apple-Mail=_80D3DFC7-03B4-4E1B-BCFC-2B0C668B6E24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Med, 

See = below=E2=80=A6

Joe

On Jul 31, 2019, at 10:38 PM, = mohamed.boucadair@orange.com wrote:

...
 
[Med] What I had in = mind is to import the option layout and key information into 793bis. =

I don=E2=80=99t think it=E2=80=99s particularly = useful to duplicate information this way - esp. for experimental = options.

What I=E2=80=99m hoping with this change is to = avoid having discussion similar to https://mailarchive.ietf.org/arch/msg/tcpinc/fVCnrvMouTdeIuwTyt= oBRNmztHU (end of = the message) each time a new option is discussed. =    
<= br class=3D"">
We=E2=80=99re going to have that discussion = every time anyway - that is about 
a) whether a new = option under development should be treated as experimental or = standards-track from the start
b) whether to endorse squatting = on assigned code points

Defiance is = not ignorance. No amount of text avoids the former.

 
- these are not = details needed for standards-compliant operation
 
[Med] I=E2=80=99m not = sure to parse this comment. RFC6994 is a standard track RFC.
 
(esp. because they = shouldn't be used for final standards-track = options).

The sentence is explained in the note I put = below it - although the method is standards-track (as is congestion = control, FWIW), the details are not critical to a minimal, = standards-compliant implementation for a few reasons:

- standards-compliant implementations shouldn=E2=80=99= t be deployed publicly with use of experimental options at all (at best, = disabled by default)
- 6994 explains how others will interpret = the fields of those code points anyway, so if you ignore them you=E2=80=99= re just risking overlapping use with others. the length of the EdIDs = (esp longer values) makes that sufficiently unlikely = anyway

----
= --Apple-Mail=_80D3DFC7-03B4-4E1B-BCFC-2B0C668B6E24-- From nobody Thu Aug 1 13:58:11 2019 Return-Path: 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 3E84812022E; Thu, 1 Aug 2019 13:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de 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 25RmXuhdHSXt; Thu, 1 Aug 2019 13:58:08 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C348C12011D; Thu, 1 Aug 2019 13:58:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0BFD825A24; Thu, 1 Aug 2019 22:58:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1564693086; bh=Bt2iv9sLhPbd9+tghMXatmmtpCLuejzDOrijU9G3vTI=; h=From:To:CC:Subject:Date:From; b=jER/+npj7zfRaKOH7KDAVWRoF7sey0ILgdAqZ3bAXOUACho1EOVdV4G5g2Uoad+cO KzqP4rhYDsz/wHc4HZxsYk+nKvYrFSzub5uC/cSXahxRx+pv1jpGA6OSAx9ZoKBZPp 2Twpsyg5/UVU/mtO0aevPI22A0uIhGQU/f+BTdwc= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFmmJVFy4XXr; Thu, 1 Aug 2019 22:58:05 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 1 Aug 2019 22:58:05 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 1 Aug 2019 22:58:04 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: DRAFT minutes for IETF 105 Thread-Index: AdVIq4pSC1NAtjukQ2e8eXY0uviGXA== Date: Thu, 1 Aug 2019 20:58:03 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3D5EA2@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] DRAFT minutes for IETF 105 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 20:58:10 -0000 Hi all, Draft minutes for the TCPM session in Montreal have been uploaded:=20 https://datatracker.ietf.org/meeting/105/materials/minutes-105-tcpm-00 As usually, please let us know if anything is broken therein. Thanks a lot to Richard for his excellent notes! Michael From nobody Fri Aug 2 01:29:41 2019 Return-Path: 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 13D9E120025; Fri, 2 Aug 2019 01:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 4RZ0ZfGeqaW2; Fri, 2 Aug 2019 01:29:37 -0700 (PDT) Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 AC51412000F; Fri, 2 Aug 2019 01:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564734575; x=1596270575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kbCBAiZTa1DBX0O6bOQWzhWBSI1kRuuUT/+iio1pwoU=; b=YYH2wPbNv+3PVOsEy6wemAllVyRFVfbfmPiOKNfvAd7VtnBLvz9zeoEb 3hBlstYPhzHwQcdGWeoD7BSmoC/hljl1oNDCZCo7EOfms5/99JEJyGguw qYBKcb3u4n/BbyjizeUGQsTzPRB3ZMXrmOL0A9SAYzXwd0J/hL98JlzPp s2c9NLka/pKA857u2VpiBxzzrejVq/TBbQIPfXQudPzq6oj85y3R1oTab ecS7DhCvYLwmUPPjZ7pRT7Roe1oDwcGxgy3sVJlK140E0dkqY2jpvClVv NGFGk1EO2PulsOXlwUNqb5dF+AQHT/eji0ChEevC/GG+GexKaZeIady52 A==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2019 10:29:32 +0200 X-IronPort-AV: E=Sophos;i="5.64,337,1559512800"; d="scan'208";a="471894858" X-MGA-submission: =?us-ascii?q?MDHNxomqfot6fntjWtUYuFbIHqZZw+qxQCtgWx?= =?us-ascii?q?E+Q47jHoZs9FStjmx6JDnW70s8TKdQIaQ7DClZo5dLDHTOvsaWzSyJNk?= =?us-ascii?q?7sENOniNmXxlokb9CfPsuS5h2yriHnUULGmPvKVvy/gbTd7iH0ME8WEK?= =?us-ascii?q?ib9ZuWo+ZoCggLwGzOwNqvVQ=3D=3D?= Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 02 Aug 2019 10:29:33 +0200 Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 10:29:33 +0200 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 2 Aug 2019 10:29:33 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 10:29:30 +0200 Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.26) by FRXPR01MB0582.DEUPRD01.PROD.OUTLOOK.DE (10.158.153.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Fri, 2 Aug 2019 08:29:32 +0000 Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1]) by FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1%5]) with mapi id 15.20.2115.005; Fri, 2 Aug 2019 08:29:32 +0000 From: To: CC: , , Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTw Date: Fri, 2 Aug 2019 08:29:32 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec9e52cc-9016-4cb2-e613-08d717238b5c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRXPR01MB0582; x-ms-traffictypediagnostic: FRXPR01MB0582: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 011787B9DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(136003)(346002)(366004)(199004)(189003)(71200400001)(71190400001)(446003)(6916009)(9686003)(3846002)(6116002)(76176011)(52396003)(256004)(55016002)(186003)(7696005)(4326008)(33656002)(8676002)(53546011)(102836004)(53936002)(316002)(26005)(66066001)(7736002)(66574012)(1411001)(2906002)(305945005)(66946007)(76116006)(476003)(81166006)(66556008)(64756008)(66446008)(81156014)(14454004)(66476007)(14444005)(11346002)(5660300002)(45776006)(86362001)(8936002)(54906003)(68736007)(486006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0582; H:FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 87gu36q1vu6kzb0u/dvjVqkmsZDP3kZzWix3Ea512ZF5f57ceQZmiSd/IGc2931mzdOjfYXYFldsYtwpnUG2ceqZwicxy5d07KQAkCfhTqfYvJ1ujY59neYBan6W+9SwH+PMkkH57NB74ZiO4IvQ7kQsB8zrX/Xi4TbL/7ekHzDK4trLJEv8QtRgByAKTcRL7bAY/kOofrKhyBA1JDi2W1Dp17u0lq4SikKWqtOLRK/BTNHlHCKRC6YuuXtcxnsMBJ8M9oEwNdvLuqvMxnpnLUXOqqzxMO6ux5LOmqQOkymSRIO+PLrIc5qKqVNDnMs4C3zi9U4DSDPW7EcE8oXg9B4R6TI+aMxjc6/Pn5oSV9qrnWWFFq6g5MJnCbrVcTumXxFRVzzb5TBqSDSWLP2SM4cQWTz3WneAgAlTYe6T2AI= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ec9e52cc-9016-4cb2-e613-08d717238b5c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2019 08:29:32.4540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0582 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 08:29:39 -0000 Hi Jonathan, could you provide a real world example of links which are consecutively nar= rower than sender access links? I could figure out a small campus network which has a bottleneck at the Int= ernet access and a second one connecting the terminal equipment. But in a s= mall campus network, the individual terminal could very well have a higher = LAN access bandwidth, than the campus - Internet connection (and then there= 's only one bottleneck again). There may be a tradeoff between simplicity and general applicability. Aware= ness of that tradeoff is important. To me, simplicity is the design aim.=20 Regards, Ruediger=20 -----Urspr=FCngliche Nachricht----- Von: tsvwg Im Auftrag von Jonathan Morton Gesendet: Dienstag, 9. Juli 2019 17:41 An: Bob Briscoe Cc: tcpm IETF list ; ecn-sane@lists.bufferbloat.net; tsvwg I= ETF list Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classifi= ed as L4S > On 13 Jun, 2019, at 7:48 pm, Bob Briscoe wrote: >=20 > 1. It is quite unusual to experience queuing at more than one > bottleneck on the same path (the available capacities have to > be identical). Following up on David Black's comments, I'd just like to note that the abov= e is not the true criterion for multiple sequential queuing. Many existing TCP senders are unpaced (aside from ack-clocking), including = FreeBSD, resulting in potentially large line-rate bursts at the origin - es= pecially during slow-start. Even in congestion avoidance, each ack will tr= igger a closely spaced packet pair (or sometimes a triplet). It is then ea= sy to imagine, or to build a testbed containing, an arbitrarily long sequen= ce of consecutively narrower links; upon entering each, the burst of packet= s will briefly collect in a queue and then be paced out at the new rate. TCP pacing does largely eliminate these bursts when implemented correctly. = However, Linux' pacing and IW is specifically (and apparently deliberately= ) set up to issue a 10-packet line-rate burst on startup. This effect has = shown up in SCE tests to the point where we had to patch this behaviour out= of the sending kernel to prevent an instant exit from slow-start. - Jonathan Morton From nobody Fri Aug 2 02:47:15 2019 Return-Path: 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 9E7A812007C; Fri, 2 Aug 2019 02:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KTBaRaJQNsyY; Fri, 2 Aug 2019 02:47:11 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F241412004E; Fri, 2 Aug 2019 02:47:10 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id u25so55377174wmc.4; Fri, 02 Aug 2019 02:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2bNlBJG7BPKPCc0Bkg+mHeGfatut4ewrSZR9mqXgnzo=; b=p6kD7vvAyLaEztIRPRGWhrHu6uH5r1PN4dsPPATlO3oFTvUIdTBj14mWHMR0yPRbQs 91/sNw1p1we9QmXjJjQcE4zi2AwtUvh9FcYGG4gp39RKYR/jf9dDfaFHOP2eJVwB77cd B1gX+1uTIQ2WW8533+yWQ6PIO5UU+eOG0sfOuWR3+ZD5TpAvp1Ld+Pn5PTayhTvV9zdC Ju4vb9j5kGHGrhcqOPl+feomUzauGlPg9vbMpLaQ9Yym57f2nzggZf/OOz69c66Pc2I7 jLXDfszdUGrRdDc4xIdHudCWFge8wH5azv7t2K2oVTKdxXeUcg57ESHluIrh6Kqn2yH6 pUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2bNlBJG7BPKPCc0Bkg+mHeGfatut4ewrSZR9mqXgnzo=; b=pjS8V7StPx/t8ANYcyg74wDCIUhKu2WEtnesTnhxkJ8yLAWSSlol1ki57hfciBe3M/ WTJzt0TaKStfiW059KPQ+3NHS1TIkbw+MJ+TSaAyF0oLXScdnphPMY0wyUb9hj5LzZRG lUfd1XA+ahxaFp8MPg9HMMEfztyS+IB3I620iwEcd2NpJ5pt0qc9UVRB2lHNh7TFWv9a ah5+E/jhf1jSJUIZVN8JfN3kkx07F6c/2sY/TVduE7pVv6fTLvhjdZpqZwqurVgOPrhq VXtgA+HifHkQrKlowRxsX0Qkm9k+eJ6KTmJbs7BkHiE53SeeuxYdOUnPu/AAye1m1+vA Hkqg== X-Gm-Message-State: APjAAAWsDIgiwGOzFYvgKNVWFk1hQ/Yxe73ExNhb78+ztevKWWrr4TGa 1LUCku1x3+1rMfQMGih9V3o= X-Google-Smtp-Source: APXvYqwu4RXOzQ7LFFDoP/0Hcz/SjulHkJmfSX4btD5ZDtIA13+YWjLjHSm5GysXGrCAobunqza+yQ== X-Received: by 2002:a7b:cae9:: with SMTP id t9mr3740479wml.126.1564739229409; Fri, 02 Aug 2019 02:47:09 -0700 (PDT) Received: from [192.168.1.9] (host-2-100-232-204.as13285.net. [2.100.232.204]) by smtp.gmail.com with ESMTPSA id w67sm104132142wma.24.2019.08.02.02.47.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 02:47:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Fri, 2 Aug 2019 10:47:06 +0100 Cc: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 09:47:13 -0000 > On 2 Aug, 2019, at 9:29 am, = wrote: >=20 > Hi Jonathan, >=20 > could you provide a real world example of links which are = consecutively narrower than sender access links? >=20 > I could figure out a small campus network which has a bottleneck at = the Internet access and a second one connecting the terminal equipment. = But in a small campus network, the individual terminal could very well = have a higher LAN access bandwidth, than the campus - Internet = connection (and then there's only one bottleneck again). >=20 > There may be a tradeoff between simplicity and general applicability. = Awareness of that tradeoff is important. To me, simplicity is the design = aim.=20 A progressive narrowing of effective link capacity is very common in = consumer Internet access. Theoretically you can set up a chain of = almost unlimited length of consecutively narrowing bottlenecks, such = that a line-rate burst injected at the wide end will experience queuing = at every intermediate node. In practice you can expect typically three = or more potentially narrowing points: 1: Core to Access network peering. Most responsible ISPs regularly = upgrade these links to minimise congestion, subject to cost = effectiveness. Some consumer ISPs however are less responsible, and = permit regular congestion here, often on a daily and/or weekly cycle = according to demand. Even the responsible ones may experience = short-term congestion here due to exceptional events. Even if the = originating server's NIC is slower than the peering link, queuing may = occur here if the link is congested overall due to statistical = multiplexing. 2: Access to Backhaul provisioning shaper. Many ISPs have a = provisioning shaper to handle "poverty tariffs" with deliberately = limited capacity. It may also be used to impose a sanity check on = inbound traffic bursts, to limit backhaul network traffic to that = actually deliverable to the customer (especially when the backhaul = network is itself subcontracted on a gigabytes-carried basis, as is = common in the UK). In the ADSL context it's often called a BRAS. 3: Backhaul to head-end device. Generally the backhaul network is sized = to support many head-end devices, each of which serves some number of = consumer last-mile links. I'm being deliberately generic here; it could = be a CMTS on a cable network, a DSLAM in a phone exchange, a cell tower, = or a long-range wifi hub. In many cases the head-end device shares = several subscribers' lines over a common last-mile medium, so there is = still some statistical multiplexing. In the particular case of a cell = tower, the subscriber usually gets less link capacity (due to = propagation conditions) than his tariff limit. 4: CPE bufferbloat mitigation shaper. This is *post-last-mile* ingress = shaping, with AQM and FQ, to reduce the effects of the still-ubiquitous = dumb FIFOs on the above bottlenecks, especially the head-end device. = The IQrouter is a ready-made CPE device which does this. 5: LAN, wifi, or powerline link. Most people now have GigE, but = 100base-TX is still in use in cheaper CPE and some low-end computers, = and this will be a further bottleneck in cases where the last mile is = faster. For example, the Raspberry Pi has only just upgraded to GigE in = its latest versions, and used 100base-TX before. Wifi is also a likely = bottleneck, especially if the mobile station is on the opposite side of = the house from the base CPE, and is additionally a "bursty MAC" with = heavy aggregation. Some CPE now runs airtime-fairness and FQ-AQM on = wifi to help manage that. I think the above collection is not at all exotic. Not all of these = will apply in every case, or at all times in any given case, but it is = certainly possible for all five to apply consecutively. - Jonathan Morton= From nobody Fri Aug 2 04:10:29 2019 Return-Path: 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 560DD120096; Fri, 2 Aug 2019 04:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mUozj34FynlC; Fri, 2 Aug 2019 04:10:25 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052D912004A; Fri, 2 Aug 2019 04:10:25 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id e20so18332795iob.9; Fri, 02 Aug 2019 04:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pVJGExsKLlIOof1pxpFUuxa1/KESzXQPi99nbi+PJoo=; b=hf1kwvGn4qv1rBZrN1oFMNPLKeVZ/v1Yu7YV1IsuVP0nzZuDVxU8HC/xlTojv++tbC YV8FgiGK4Vib7Wwe9tAWf5W4xoekOSeH02hdEIccs3tMTbWnF8Gg3rB/Ep2Uz+NrjHHm KXDo5pKH2TlAhTmEkonQoLJj5luniWTEr4Tb9EGiVBEUFiLb6gsi3o6jPx/DxkhOO+T5 OzgF2iN2sKIc/ccs883xaL43ySLg9ot2Fsz84InNNgG6Tc6NFhkPYW/C57IBBjTOgvzY lid5rp1TQ8qIQt/cIJg35HLSwG+Fd0IuIi3ufKgL0Z8OzzgngOTihNHDVfQRZ7PnEQdu 514w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pVJGExsKLlIOof1pxpFUuxa1/KESzXQPi99nbi+PJoo=; b=DXBnxkaFsPG2EiookrY1hZT4tvFLWSMVvpfR6yd/KcBzX+ACkT1GQ0EgubtlwvXFQ3 PeSLoGN68UwjN5sd/tjS5IZCSCgiF8557vXYKP+0Kt4ueWFKJbbWZIaeZ6OS1yioSBIH YTT0RBRA2MD00Pn9+vM33s/NWeKEkvPOcpzGXMUJZwKqwYur9U4e+DEUuJX15rIGHe07 cZ5KCszNvVtcml8hp6W9B4SiiDoynsH94n1qm5ROrdTujqdc0sTBl23T54QEg33LOciU u5hb3CNkPX7SWtW0LVrU8SP9CRQ5+lHQ4txqteDBf9gYJX8UfwFPC5OAs+WW5KjauZn+ PdDw== X-Gm-Message-State: APjAAAU+Ie+mpSwCed/WaTd1qxN/vuipXCFLcdoxAp9EEgb6/xfryKch UxdRNnPu7qoN0xHvHO187sYULQkczZ1AF1penUQ= X-Google-Smtp-Source: APXvYqwC8Unfs0cpHNUpmeYz3BbReJq3nJ7hrDl8xFxROTHOCDoOYaMJmbwhCSWr1AqvvWuduZOfk1PEpzfDiXM/nNQ= X-Received: by 2002:a5d:9d42:: with SMTP id k2mr11577004iok.45.1564744224165; Fri, 02 Aug 2019 04:10:24 -0700 (PDT) MIME-Version: 1.0 References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> In-Reply-To: <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> From: Dave Taht Date: Fri, 2 Aug 2019 04:10:11 -0700 Message-ID: To: Jonathan Morton Cc: Ruediger.Geib@telekom.de, tcpm IETF list , ECN-Sane , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 11:10:27 -0000 On Fri, Aug 2, 2019 at 2:47 AM Jonathan Morton wrot= e: > > > On 2 Aug, 2019, at 9:29 am, wrote: > > > > Hi Jonathan, > > > > could you provide a real world example of links which are consecutively= narrower than sender access links? > > > > I could figure out a small campus network which has a bottleneck at the= Internet access and a second one connecting the terminal equipment. But in= a small campus network, the individual terminal could very well have a hig= her LAN access bandwidth, than the campus - Internet connection (and then t= here's only one bottleneck again). > > > > There may be a tradeoff between simplicity and general applicability. A= wareness of that tradeoff is important. To me, simplicity is the design aim= . > > A progressive narrowing of effective link capacity is very common in cons= umer Internet access. Theoretically you can set up a chain of almost unlim= ited length of consecutively narrowing bottlenecks, such that a line-rate b= urst injected at the wide end will experience queuing at every intermediate= node. In practice you can expect typically three or more potentially narr= owing points: 0: Container and vm users are frequently using htb + something to keep their bandwidths under control. 0.5: Cloudy providers use "something" to also rate limit traffic. Policers and shapers, I assume. > 1: Core to Access network peering. Most responsible ISPs regularly upgra= de these links to minimise congestion, subject to cost effectiveness. Some= consumer ISPs however are less responsible, and permit regular congestion = here, often on a daily and/or weekly cycle according to demand. Even the r= esponsible ones may experience short-term congestion here due to exceptiona= l events. Even if the originating server's NIC is slower than the peering = link, queuing may occur here if the link is congested overall due to statis= tical multiplexing. > > 2: Access to Backhaul provisioning shaper. Many ISPs have a provisioning= shaper to handle "poverty tariffs" with deliberately limited capacity. It= may also be used to impose a sanity check on inbound traffic bursts, to li= mit backhaul network traffic to that actually deliverable to the customer (= especially when the backhaul network is itself subcontracted on a gigabytes= -carried basis, as is common in the UK). In the ADSL context it's often ca= lled a BRAS. > > 3: Backhaul to head-end device. Generally the backhaul network is sized = to support many head-end devices, each of which serves some number of consu= mer last-mile links. I'm being deliberately generic here; it could be a CM= TS on a cable network, a DSLAM in a phone exchange, a cell tower, or a long= -range wifi hub. In many cases the head-end device shares several subscrib= ers' lines over a common last-mile medium, so there is still some statistic= al multiplexing. In the particular case of a cell tower, the subscriber us= ually gets less link capacity (due to propagation conditions) than his tari= ff limit. > > 4: CPE bufferbloat mitigation shaper. This is *post-last-mile* ingress s= haping, with AQM and FQ, to reduce the effects of the still-ubiquitous dumb= FIFOs on the above bottlenecks, especially the head-end device. The IQrou= ter is a ready-made CPE device which does this. > > 5: LAN, wifi, or powerline link. Most people now have GigE, but 100base-= TX is still in use in cheaper CPE and some low-end computers, and this will= be a further bottleneck in cases where the last mile is faster. For examp= le, the Raspberry Pi has only just upgraded to GigE in its latest versions,= and used 100base-TX before. Wifi is also a likely bottleneck, especially = if the mobile station is on the opposite side of the house from the base CP= E, and is additionally a "bursty MAC" with heavy aggregation. Some CPE now= runs airtime-fairness and FQ-AQM on wifi to help manage that. > > I think the above collection is not at all exotic. Not all of these will= apply in every case, or at all times in any given case, but it is certainl= y possible for all five to apply consecutively. > > - Jonathan Morton > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri Aug 2 05:05:22 2019 Return-Path: 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 6C3F5120033; Fri, 2 Aug 2019 05:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V3Qx1XViRT0y; Fri, 2 Aug 2019 05:05:18 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59BB120098; Fri, 2 Aug 2019 05:05:17 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id z3so10456131iog.0; Fri, 02 Aug 2019 05:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uSL4TGlvuu4pKXyLhZOhuwiD3IgXXnsXPdrn5o2a5N8=; b=kOYGilnjtR5yWw+zdIctZoG0wdotYtW200UaZglETVVoyDBfPwC5lr2zcpDFMRoORM t4mJmWrP5U46YAlqC7auym6qrDGCwfTsCdKTKBggRbVMcCCqr1ObDeJMDWVQZJscMyHu 8KlPJcl847yN7BAufL5zBLwv0Y4Yr/GeOnJOV81V7C9ckHTwyB2E2fbnBCM4JojRpURe hZA7kTHYIc6gzSEPXTpeeP6sR8jv1oF89LlRPmaZ2bwGaHx4dNngokUB8lP9GKD1lBVL zvuj503ard8J1ZSRE/R+ilhJUn9xAkMVAOQBuIQUNh270apaFd+Lsx7oRgMtruktsvzF uhsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uSL4TGlvuu4pKXyLhZOhuwiD3IgXXnsXPdrn5o2a5N8=; b=tpfVmFkhT2sTsu8BjG2MDPh+vi36Bjj2nZ4cOeBkHoELCDlC9jbasCgsb3FlYkZ3U2 e7VDHuEmYzLS80glvTX7p2QLmbtxDzg4FOXSWelF7Lz5j+RtZJdc4tF7JcOxonQcbEPq gbC0C9MdjuZ8uTG8AWxGHAATNNsENaiMCozWv12ssIkc6UZp4SA/sSk4d0mT5Ptv6sKj h5qrOUqDdt7gJCpn18tluy9hzqYov38JnKZrp3OvcD3UB/NuXjFOamceDusbUs5atvC5 7ixR831rkUv8/Ohx38nLowdoRK41ys8DE8ukB0I3NEaMvOUxbRfgoRDztJT28SCii/qU J5qQ== X-Gm-Message-State: APjAAAUs6pMpbXKNujjIOeJ6Xd8MVO9As8rs5otMI+671v86nIeIjeLE rLM1gyAvcRLkifTT4elcEBNwl+8lHOyKFUVgmqs= X-Google-Smtp-Source: APXvYqy9TMUMgMZE7E1PHijIhKB201vaKmndpJX0y4Ca/agrKHG6jmXYQNdA7HEgEAIaVJsNFB2JqVQKZN/yRHNccYE= X-Received: by 2002:a6b:790a:: with SMTP id i10mr24038762iop.150.1564747516991; Fri, 02 Aug 2019 05:05:16 -0700 (PDT) MIME-Version: 1.0 References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> In-Reply-To: From: Dave Taht Date: Fri, 2 Aug 2019 05:05:04 -0700 Message-ID: To: Jonathan Morton Cc: Ruediger.Geib@telekom.de, tcpm IETF list , ECN-Sane , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 12:05:20 -0000 On Fri, Aug 2, 2019 at 4:10 AM Dave Taht wrote: > > On Fri, Aug 2, 2019 at 2:47 AM Jonathan Morton wr= ote: > > > > > On 2 Aug, 2019, at 9:29 am, wrote: > > > > > > Hi Jonathan, > > > > > > could you provide a real world example of links which are consecutive= ly narrower than sender access links? > > > > > > I could figure out a small campus network which has a bottleneck at t= he Internet access and a second one connecting the terminal equipment. But = in a small campus network, the individual terminal could very well have a h= igher LAN access bandwidth, than the campus - Internet connection (and then= there's only one bottleneck again). > > > > > > There may be a tradeoff between simplicity and general applicability.= Awareness of that tradeoff is important. To me, simplicity is the design a= im. > > > > A progressive narrowing of effective link capacity is very common in co= nsumer Internet access. Theoretically you can set up a chain of almost unl= imited length of consecutively narrowing bottlenecks, such that a line-rate= burst injected at the wide end will experience queuing at every intermedia= te node. In practice you can expect typically three or more potentially na= rrowing points: > > 0: Container and vm users are frequently using htb + something to keep > their bandwidths under control. > > 0.5: Cloudy providers use "something" to also rate limit traffic. > Policers and shapers, I assume. Stuff in the cloud thus far is looking quite jittery; sub-ms marking thresholds do not look feasible. I have no idea what sorts of software jitter and burstyness exist in NFV and ddpk based implementatons. > > > 1: Core to Access network peering. Most responsible ISPs regularly upg= rade these links to minimise congestion, subject to cost effectiveness. So= me consumer ISPs however are less responsible, and permit regular congestio= n here, often on a daily and/or weekly cycle according to demand. Even the= responsible ones may experience short-term congestion here due to exceptio= nal events. Even if the originating server's NIC is slower than the peerin= g link, queuing may occur here if the link is congested overall due to stat= istical multiplexing. > > > > 2: Access to Backhaul provisioning shaper. Many ISPs have a provisioni= ng shaper to handle "poverty tariffs" with deliberately limited capacity. = It may also be used to impose a sanity check on inbound traffic bursts, to = limit backhaul network traffic to that actually deliverable to the customer= (especially when the backhaul network is itself subcontracted on a gigabyt= es-carried basis, as is common in the UK). In the ADSL context it's often = called a BRAS. > > > > 3: Backhaul to head-end device. Generally the backhaul network is size= d to support many head-end devices, each of which serves some number of con= sumer last-mile links. I'm being deliberately generic here; it could be a = CMTS on a cable network, a DSLAM in a phone exchange, a cell tower, or a lo= ng-range wifi hub. In many cases the head-end device shares several subscr= ibers' lines over a common last-mile medium, so there is still some statist= ical multiplexing. In the particular case of a cell tower, the subscriber = usually gets less link capacity (due to propagation conditions) than his ta= riff limit. There are also bursts here from the vpn crypto engine. > > 4: CPE bufferbloat mitigation shaper. This is *post-last-mile* ingress= shaping, with AQM and FQ, to reduce the effects of the still-ubiquitous du= mb FIFOs on the above bottlenecks, especially the head-end device. The IQr= outer is a ready-made CPE device which does this. I would say "inbound shaper" to be clear. And its far, far wider than just that commercial product, Nearly everyone using this stuff shapes both in and outbound - be it untangle, netduma, asus "adaptive qos", edgerouter's or eero's sqm implemention, all of openwrt, dd-wrt, and deratives, bsd-based pfsense and opfsense, preseem does a bump in the wire for WISPs, streamboost, I think the list of off the shelf home router qos systems that shape inbound is well above 80-90%, and users have been trained to turn it on in both directions and off only when they run out of cpu. We see new product sales driven by the cpu cost of having to shape inbound, too. Policers have become quite useless in the past decade. > > > > 5: LAN, wifi, or powerline link. Most people now have GigE, but 100bas= e-TX is still in use in cheaper CPE and some low-end I'd so love to see powerline gain fq and AQM. I see it used a lot in busy apt buildings to drag stuff from room to room. It can be *awful* >computers, and this will be a further bottleneck in cases where the last m= ile is faster. For example, the Raspberry Pi has only just upgraded to Gig= E in its latest versions, and used 100base-TX before. Wifi is also a likel= y bottleneck, especially if the mobile station is on the opposite side of t= he house from the base CPE, and is additionally a "bursty MAC" with heavy a= ggregation. Some CPE now runs airtime-fairness and FQ-AQM on wifi to help = manage that. "some" includes most of qca's ath9k or ath10k products. (40% of the AP market?) Prominently known fq-codel for wifi users are ~3m chromebook users and ~3m google wifi, ( http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20fo= r%20FQ_CoDel%20in%20wireless%20interface.pdf ) and nearly everyone else in the 802.11s meshy market... meraki is a known sfq + codel user... starting in 2014... A large number of wifi APs and p2p links oft have a faster wifi speed than their 100base-tx link, and thus use the ethernet (with either a short fifo or fq_codel) to smooth the bursts out. I can point to a few ubnt products that I know a bit too much about. There's also some 802.11ad and ay.... there is a quite remarkable amount of 100base-tx gear still being deployed. If it helps any to those here doing simulation, long ago I put a "slot" and statistical distribution of busty mac delay feature into netem. I can say now that that was used to help guide the development of google "stadia", and certainly "slotting" is a MAJOR tool that I'd plug into the SCE work to better emulate the real orld behaviors of bursty macs. google has collected WAY more examples characterizing real world micro(bursts) than I could ever deal with, and I hope they publish that data someday for others to use. > > > > I think the above collection is not at all exotic. Not all of these wi= ll apply in every case, or at all times in any given case, but it is certai= nly possible for all five to apply consecutively. For bursty. > > - Jonathan Morton > > _______________________________________________ > > Ecn-sane mailing list > > Ecn-sane@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/ecn-sane > > > > -- > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri Aug 2 06:15:40 2019 Return-Path: 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 4BE2B1200DB; Fri, 2 Aug 2019 06:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 abF0A_vM1GTM; Fri, 2 Aug 2019 06:15:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA251200CD; Fri, 2 Aug 2019 06:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564751726; bh=ugUBSujZuKIGXPHRqQ4v/2lEkJOKLnlRX2iF5ZGTGbQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=O894eUXy95vo7VUQ2yHP/ML5KIiVO7p6WrlZ0ypxLTHfMcqBZT0SJXHobJG6ZTMeC z4t12PXp6TxBTshD7mMDP4bnUNI1nTw2as3oeDtAmM1mmx9t4frek/7qMK+HmtWEQ+ N3xWww4WsOIBnX3Re+ZSaO5Avf97rqTmrENcErg4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LjZn2-1iV58w0lqq-00bXpz; Fri, 02 Aug 2019 15:15:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 2 Aug 2019 15:15:23 +0200 Cc: Jonathan Morton , tcpm@ietf.org, ECN-Sane , tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:6XHtP07waXiolpH/2jXVlCbpP1vT9X1zFgvFyqTpj7OtlxGi626 37sAbLEu3/s/iftInsG0fKwoKx3og88lAUSI1LdF3Jixg/k+f5T2eeyR1lXDPOtSUpQGBUX tIqn33x4DjcMw8Od3kcD2//WM4oeX5Vs3Wt4aG11xxMU+Han7EKSDZF6bx75atervwIz8E/ cGxpiTQw98xJM4dWxTnZQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:YqH0/9ThHVQ=:3pUbOKbFr67gK0m/1tdivo +TVOwRbgLzp3Zmv+bUX8TbZ0QzsY4XvkLf64AtUVTNOeUAL8U1gOO87ofozwx2CAg0eVYlgIL JmDY5+4ekArsLOe9c3CAGjCUjrXiA7WXRuxenOQlkDIDxvlDcRq1FVbdarprw1g/wIuCERuDK V1UfAYKXVbWKpRxc3upF0HoCRF9l91tqZD7gmi7v4kRME8dvrWMb04GmKajN9J6UG13Nwj/bK o7v4yAogCCfqgl8kKKxew4FwA3xw4zAIrboZMsAhe3PDEJnTxaL8I4CUT5qftQzwiz9g0lkmz 2fBESRa4VFGu/JxRHS+8GlobDpPfKUiYY2oYvomC0PB2yz/0fZ8YnZnHJt8DKUrdTG/cWomhT JWgdaEY+VXsV1YiSDjorqjFD+4c9rNeK7zFtWvvVmjiz2Bp/aeVozKBSrXfwSsmvcDpbppjU7 XMepC/PSkg1fjqOK/5xvrGCm/Vrmj9vhYXPPbMl0L69gTTPBkf/QFhRgCtKfBhblNsdL3xY58 jkxpjg6hL/6rCchz8VArzMV/tIk2KhU9fzvtjptoWab957HGnZ/ojvXrWFhgXMLhKCUUa5geH 8ogzrOvQafNJO1WKcjJ8380JhBEaG7LFPXEOSH6C+CV1sWooeBIiAulOvJbPew76egc4CGrK9 mJ/v6IZYz5fKeebkOhWRtaZsJkngcdGr6dv1YeYi2Jm6oy1F3F4eLx9FRcBFWErz+8/2RHmbt laD928QXC+wPUrcFOLjg7c4JIc5KIwKAR3M4IIw1P4IrpOt+plxH0WdEfnVeVMeQbFEufVSBK 1cMnszF2JU1TFj14VfHcknhFMZLZP7e++5Q7HaGLaZTh+dvm3KoViymbyOKpgqtLtlmi1SOFU BRHPygV7hznJ7y4p43cH0/FNccpsVu3mbZyUswQFSJWgurP50aqxP12JXJjZivbhwUb5ct4qQ mW7xxq0glwkHfyKh6CTUBrbMijZaPANcP0449c2BcL8JdBmVOS+yhB8AmtFSbwT4glbCOVZ1R K6V54Yp9Iwv55Zp3SdR7ViLzQlEeutkYnQAtWimLiG9YPh6ORT12e3iqaJTNN6vrBInejRtqX piz/wy22VdYpbJg33L5VSo7g2PsatQdk9rpLV0R0Sja83SIgbgW6jsY0GfjEMB8iIk+hYWE5/ P3DjU= Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 13:15:38 -0000 Hi Ruediger, > On Aug 2, 2019, at 10:29, = wrote: >=20 > Hi Jonathan, >=20 > could you provide a real world example of links which are = consecutively narrower than sender access links? Just an example from a network you might be comfortable with, in = DTAGs internet access network there typically are traffic limiting = elements at the BNGs (or at the BRAS for the legacy network), I am not = 100% sure whether these are implemented as policers or shapers, but they = tended to come with >=3D 300ms buffering. Since recently, the BNG/BRAS = traffic shaper's use the message field of the PPPoE Auth ACK to transfer = information about the TCP/IPv4 Goodput endusers can expect on their link = as a consequence of the BNG/BRAS"s traffic limiter. In DOCSIS and GPON = networks the traffic shaper seems mandated by the standards, in DSL = networks it seems optional (but there even without a shaper the limited = bandwidth of the access link would be a natural traffic choke point). Fritzbox home router's now use this information to automatically set = egress (and I believe also) ingress traffic shaping on the CPE to reduce = the bufferbloat users experience. I have no insight in what Telekom's = own Speedport routers do, but I would not be surprised if they would do = the same (at least for egress).=20 As Jonathan and Dave mentioned, quite a number of end-users, = especially the latency sensitive ones, employ their own ingress and = egress traffic shapers at their home routers as the 300ms buffers of the = BNG's are just not acceptable for any real-timish uses (VoIP, on-line = twitch gaming, even for interactive sessions like ssh 300ms delay are = undesirable). E.g. personally, I use an OpenWrt router with an FQ AQM = for both ingress and egress (based on Jonathan's excellent cake qdisc) = that allows a family of 5 to happily share a 50/10 connection between = video streaming and interactive use with very little interference = between the users, the same link with out the FQ-AQM active makes = interactive applications feel like submerged in molasses once the link = gets saturated... As far as I can tell there is a number of different solutions = that offer home-router based bi-directional traffic shaping to solve = bufferbloat" from home (well, not fully solve it, but remedy its = consequences), including commercial options like evenroute's iqrouter, = and open-source options like OpenWrt (with sqm-scripts as shaper = packet).=20 It is exactly this use case and the fact that latency-sensitive = users often opt for this solution, that causes me to ask the L4S crowd = to actually measure the effect of L4S on RFC3168-FQ-AQMs in the exact = configuration it is actually used today, to remedy the same issue L4S = wants to tackle. Best Regards Sebastian >=20 > I could figure out a small campus network which has a bottleneck at = the Internet access and a second one connecting the terminal equipment. = But in a small campus network, the individual terminal could very well = have a higher LAN access bandwidth, than the campus - Internet = connection (and then there's only one bottleneck again). >=20 > There may be a tradeoff between simplicity and general applicability. = Awareness of that tradeoff is important. To me, simplicity is the design = aim.=20 >=20 > Regards, >=20 > Ruediger=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: tsvwg Im Auftrag von Jonathan Morton > Gesendet: Dienstag, 9. Juli 2019 17:41 > An: Bob Briscoe > Cc: tcpm IETF list ; ecn-sane@lists.bufferbloat.net; = tsvwg IETF list > Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly = classified as L4S >=20 >> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe wrote: >>=20 >> 1. It is quite unusual to experience queuing at more than one >> bottleneck on the same path (the available capacities have = to >> be identical). >=20 > Following up on David Black's comments, I'd just like to note that the = above is not the true criterion for multiple sequential queuing. >=20 > Many existing TCP senders are unpaced (aside from ack-clocking), = including FreeBSD, resulting in potentially large line-rate bursts at = the origin - especially during slow-start. Even in congestion = avoidance, each ack will trigger a closely spaced packet pair (or = sometimes a triplet). It is then easy to imagine, or to build a testbed = containing, an arbitrarily long sequence of consecutively narrower = links; upon entering each, the burst of packets will briefly collect in = a queue and then be paced out at the new rate. >=20 > TCP pacing does largely eliminate these bursts when implemented = correctly. However, Linux' pacing and IW is specifically (and = apparently deliberately) set up to issue a 10-packet line-rate burst on = startup. This effect has shown up in SCE tests to the point where we = had to patch this behaviour out of the sending kernel to prevent an = instant exit from slow-start. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane From nobody Mon Aug 5 00:27:36 2019 Return-Path: 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 CD854120157; Mon, 5 Aug 2019 00:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 03xdyYORROR5; Mon, 5 Aug 2019 00:27:24 -0700 (PDT) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 7134A12002F; Mon, 5 Aug 2019 00:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564990039; x=1596526039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=v1XHRfeW+AgkDaZXaMyS4nOGDkJEkR3IIXX1nOOMosg=; b=jOGKnojCiKNSON1wE2gW5GUAvQTUO03BXqjtTXvCRLeeANyHLMe7MCTo 5TrDRNJ6uDwLq/7GXdJ0KkLM7Sno923rdaPOPAJK87q7rP4tfoHhZQTRb mr4AqvWXjXOsWd6B4AoelyPogcbklL9Yo0xf2T+l5KOv/ATzMfxOIZwTS SBE0NQPRWGj01e6LprDufIteOAHGlk4k3dRgaBNo2SpVTJf2DzBsmUiCL OFioGkdtfnYfVjxXRvW6eMIjnDfp8g74h7RzYj5fVutAF4/ncdvkyC5GE GBJtH+LTb3AEdJOUK27wq0ByU8geKzlMArcJ9pbGKnUVqM7/ow2GBkxnh A==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 09:27:17 +0200 X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473098187" X-MGA-submission: =?us-ascii?q?MDEcXczYCT1lJf1F0nyQb/oHt4/Y5SKgzWumaW?= =?us-ascii?q?hcnM2luH/81TQJI0JYC4ToMziCQdMwNpoXfK6JzIkO6/7V6sKr8Jr+fN?= =?us-ascii?q?KXn7OtL8zKxLKxjAeC7JKSFNgfNNC4ZohAlfSiKDaNTyLOuf1bjrpH5U?= =?us-ascii?q?dAH4uDo35o+btvihzY37LqFw=3D=3D?= Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Aug 2019 09:27:14 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 09:26:52 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 09:26:52 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 09:26:53 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0735.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 07:26:51 +0000 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 07:26:51 +0000 From: To: CC: , , Thread-Topic: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVSTRkPkpydBILe0SaPVsimE5Fu6bsIA6Q Date: Mon, 5 Aug 2019 07:26:51 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> In-Reply-To: <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b100635-6932-490d-09ed-08d71976490c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LEXPR01MB0735; x-ms-traffictypediagnostic: LEXPR01MB0735: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(396003)(39860400002)(189003)(199004)(102836004)(966005)(66066001)(85202003)(71190400001)(76176011)(81156014)(68736007)(81166006)(86362001)(66574012)(71200400001)(53546011)(3846002)(11346002)(446003)(6116002)(508600001)(305945005)(7736002)(64756008)(66556008)(66476007)(66446008)(5660300002)(2906002)(26005)(186003)(486006)(8676002)(8936002)(52396003)(53936002)(85182001)(6916009)(66946007)(33656002)(4326008)(14454004)(476003)(256004)(14444005)(6306002)(9686003)(55016002)(54906003)(7696005)(76116006)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0735; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EZtEwq/gRehR+pw1oMAGCRMGaAHmhgUb02+1X2q9ywj/vI40YUy37pL+rq++B3FW1wwQ+HlYKBZQqPMptGVoRfV2qGugNnFsa5Dr0CZRI36s2Be5hQdKKN20OE1VEMV+a5RecffgIJvBmjaxTI5LcwwKGGfAuyP3uCecm5wY9Vv4SjmyudXVxAHVJWrK/kGznTXDK18kuivZmkb6S0hJ2TdyKMzWXaQoGCrkOaTayZ55UINw/IT1eo6WQbfaI9NOycWxV3dG+l+AYAtmwpVBQaUwhc6HbypW+Z2nRFnznIP6nc/S5C7m/xbLILXjBaTrzi1N/lOZqmBK4bmOn7dOWZoFJib4QA+kf7tbMEILvciUMGb2x0s9RVNeP+px8LVszo7A9EjOPJ+1bQJiwvwWA+slJ1zhc7Za1rgcKmNulc4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8b100635-6932-490d-09ed-08d71976490c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 07:26:51.8125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0735 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 07:27:27 -0000 SGkgU2ViYXN0aWFuLA0KDQp0aGUgYWNjZXNzIGxpbmsgaXMgdGhlIGJvdHRsZW5lY2ssIHRoYXQn cyB3aGF0J3MgdG8gYmUgZXhwZWN0ZWQuIEFzIGZhciBhcyBJIGtub3csIGluIHRoZSBvcGVyYXRv ciB3b3JsZCBzaGFwZXJzIGhlcmUgYnkgYW5kIGxhcmdlIHJlbW92ZWQgcG9saWNlcnMuDQoNCkEg Y29uc2VjdXRpdmUgY2hhaW4gb2YgbmFycm93ZXIgbGlua3MgcmVzdWx0cywgaWYgdGhlIEhvbWUg R2F0ZXdheSBydW5zIHdpdGggYW4gYWRkaXRpb25hbCBpbmdyZXNzIG9yIGVncmVzcyBzaGFwZXIg b3BlcmF0aW5nIGJlbG93IHRoZSBhY2Nlc3MgYmFuZHdpZHRoLCBpZiBJIGdldCB5b3UgcmlnaHQu IA0KDQpJIHVuZGVyc3RhbmQgdGhhdCB5b3UgYXJlbid0IGludGVyZXN0ZWQgaW4gaGF2aW5nIDMw MG1zIGJ1ZmZlciBkZWxheSBhbmQgbWF5IGJlIHNvbWUgaml0dGVyIGZvciBhIHBob25lIGNvbnZl cnNhdGlvbiB1c2luZyBiZXN0IGVmZm9ydCB0cmFuc3BvcnQuIEEgbWFpbiBkcml2ZXIgZm9yIGNo YW5nZXMgaW4gY29uc3VtZXIgSVAgYWNjZXNzIGZlYXR1cmVzIGluIEdlcm1hbnkgYXJlIHB1Ymxp Y2F0aW9ucyBvZiBqb3VybmFscyBhbmQgcmVndWxhdG9ycyBjb21wYXJpbmcgSVAgYWNjZXNzIHBl cmZvcm1hbmNlIG9mIGRpZmZlcmVudCBwcm92aWRlcnMuIFNob3VsZCBvbmUgcHJvdmlkZXIgaGF2 ZSBhbiBhZHZhbnRhZ2Ugb3ZlciB0aGUgb3RoZXJzIGJ5IGRlcGxveWluZyBhIHNvbHV0aW9uIGFz IHlvdSAoYW5kIEJvYidzIHRlYW0pIHdvcmsgb24sIGl0IGxpa2VseSB3aWxsIGJlIGdlbmVyYWxs eSBkZXBsb3llZC4NCg0KQXMgZmFyIGFzIEkgY2FuIHNlZSwgbGF0ZW5jeSBhd2FyZSBjb25zdW1l cnMgc3RpbGwgYXJlIGEgbWlub3JpdHkgYW5kIGdhbWVycyBzZWVtIHRvIGJlIGEgYmlnIGdyb3Vw IGJlbG9uZ2luZyBoZXJlLiBJbnRlcmVzdCBpbiB3ZWxsIHBlcmZvcm1pbmcgZ2FtaW5nIHNlZW1z IHRvIGJlIGdyb3dpbmcsIEkgZ3Vlc3MgKGZvciBtZSBhdCBsZWFzdCBpdCdzIGFuIGltcHJlc3Np b24gcmF0aGVyIHRoYW4gYSBjbGVhciB0cmVuZCkuDQoNCkknZCBwZXJzb25hbGx5IHByZWZlciBh biBlYXN5IHRvIGRlcGxveSBhbmQgb3BlcmF0ZSBzdGFuZGFyZCBzb2x1dGlvbiBvZmZlcmluZyBC ZXN0IEVmZm9ydCBiYXNlZCB0cmFuc3BvcnQgYmVpbmcgVENQIGZyaWVuZGx5IGFuZCBhdCB0aGUg c2FtZSB0aW1lIGNvbmdlc3Rpb24gZnJlZSBmb3Igb3RoZXIgZmxvd3MgYXQgYSBCTkcgZm9yIHRy YWZmaWMgaW4gYWNjZXNzIGRpcmVjdGlvbiAoYW5kIGZvciBzaW1pbGFyIGRldmljZXMgaW4gb3Ro ZXIgYXJjaGl0ZWN0dXJlcyBvZiBjb3Vyc2UpLiANCg0KRmlnaHRpbmcgYnVmZmVyYmxvYXQgaW4g dGhlIHVwc3RyZWFtIGRpcmVjdGlvbiB0aGUgd2F5IHlvdSBkZXNjcmliZSBpdCBkb2Vzbid0IGNv bnN0cnVjdCBhIGNoYWluIG9mIGxpbmtzIHdoaWNoIGFyZSBjb25zZWN1dGl2ZWx5IG5hcnJvd2Vy IHRoYW4gdGhlIGJvdHRsZW5lY2sgbGluaywgSSB0aGluay4NCg0KUmVnYXJkcywNCg0KUnVlZGln ZXINCg0KIA0KDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBT ZWJhc3RpYW4gTW9lbGxlciA8bW9lbGxlcjBAZ214LmRlPiANCkdlc2VuZGV0OiBGcmVpdGFnLCAy LiBBdWd1c3QgMjAxOSAxNToxNQ0KQW46IEdlaWIsIFLDvGRpZ2VyIDxSdWVkaWdlci5HZWliQHRl bGVrb20uZGU+DQpDYzogSm9uYXRoYW4gTW9ydG9uIDxjaHJvbWF0aXg5OUBnbWFpbC5jb20+OyB0 Y3BtQGlldGYub3JnOyBFQ04tU2FuZSA8ZWNuLXNhbmVAbGlzdHMuYnVmZmVyYmxvYXQubmV0Pjsg dHN2d2dAaWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbRWNuLXNhbmVdIFt0c3Z3Z10gRUNOIENFIHRo YXQgd2FzIEVDVCgwKSBpbmNvcnJlY3RseSBjbGFzc2lmaWVkIGFzIEw0Uw0KDQpIaSBSdWVkaWdl ciwNCg0KDQoNCj4gT24gQXVnIDIsIDIwMTksIGF0IDEwOjI5LCA8UnVlZGlnZXIuR2VpYkB0ZWxl a29tLmRlPiA8UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPiB3cm90ZToNCj4gDQo+IEhpIEpvbmF0 aGFuLA0KPiANCj4gY291bGQgeW91IHByb3ZpZGUgYSByZWFsIHdvcmxkIGV4YW1wbGUgb2YgbGlu a3Mgd2hpY2ggYXJlIGNvbnNlY3V0aXZlbHkgbmFycm93ZXIgdGhhbiBzZW5kZXIgYWNjZXNzIGxp bmtzPw0KDQoJSnVzdCBhbiBleGFtcGxlIGZyb20gYSBuZXR3b3JrIHlvdSBtaWdodCBiZSBjb21m b3J0YWJsZSB3aXRoLCBpbiBEVEFHcyBpbnRlcm5ldCBhY2Nlc3MgbmV0d29yayB0aGVyZSB0eXBp Y2FsbHkgYXJlIHRyYWZmaWMgbGltaXRpbmcgZWxlbWVudHMgYXQgdGhlIEJOR3MgKG9yIGF0IHRo ZSBCUkFTIGZvciB0aGUgbGVnYWN5IG5ldHdvcmspLCBJIGFtIG5vdCAxMDAlIHN1cmUgd2hldGhl ciB0aGVzZSBhcmUgaW1wbGVtZW50ZWQgYXMgcG9saWNlcnMgb3Igc2hhcGVycywgYnV0IHRoZXkg dGVuZGVkIHRvIGNvbWUgd2l0aCA+PSAzMDBtcyBidWZmZXJpbmcuIFNpbmNlIHJlY2VudGx5LCB0 aGUgQk5HL0JSQVMgdHJhZmZpYyBzaGFwZXIncyB1c2UgdGhlIG1lc3NhZ2UgZmllbGQgb2YgdGhl IFBQUG9FIEF1dGggQUNLIHRvIHRyYW5zZmVyIGluZm9ybWF0aW9uIGFib3V0IHRoZSBUQ1AvSVB2 NCBHb29kcHV0IGVuZHVzZXJzIGNhbiBleHBlY3Qgb24gdGhlaXIgbGluayBhcyBhIGNvbnNlcXVl bmNlIG9mIHRoZSBCTkcvQlJBUyJzIHRyYWZmaWMgbGltaXRlci4gSW4gRE9DU0lTIGFuZCBHUE9O IG5ldHdvcmtzIHRoZSB0cmFmZmljIHNoYXBlciBzZWVtcyBtYW5kYXRlZCBieSB0aGUgc3RhbmRh cmRzLCBpbiBEU0wgbmV0d29ya3MgaXQgc2VlbXMgb3B0aW9uYWwgKGJ1dCB0aGVyZSBldmVuIHdp dGhvdXQgYSBzaGFwZXIgdGhlIGxpbWl0ZWQgYmFuZHdpZHRoIG9mIHRoZSBhY2Nlc3MgbGluayB3 b3VsZCBiZSBhIG5hdHVyYWwgdHJhZmZpYyBjaG9rZSBwb2ludCkuDQogRnJpdHpib3ggaG9tZSBy b3V0ZXIncyBub3cgdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYXV0b21hdGljYWxseSBzZXQgZWdy ZXNzIChhbmQgSSBiZWxpZXZlIGFsc28pIGluZ3Jlc3MgdHJhZmZpYyBzaGFwaW5nIG9uIHRoZSBD UEUgdG8gcmVkdWNlIHRoZSBidWZmZXJibG9hdCB1c2VycyBleHBlcmllbmNlLiBJIGhhdmUgbm8g aW5zaWdodCBpbiB3aGF0IFRlbGVrb20ncyBvd24gU3BlZWRwb3J0IHJvdXRlcnMgZG8sIGJ1dCBJ IHdvdWxkIG5vdCBiZSBzdXJwcmlzZWQgaWYgdGhleSB3b3VsZCBkbyB0aGUgc2FtZSAoYXQgbGVh c3QgZm9yIGVncmVzcykuIA0KCUFzIEpvbmF0aGFuIGFuZCBEYXZlIG1lbnRpb25lZCwgcXVpdGUg YSBudW1iZXIgb2YgZW5kLXVzZXJzLCBlc3BlY2lhbGx5IHRoZSBsYXRlbmN5IHNlbnNpdGl2ZSBv bmVzLCBlbXBsb3kgdGhlaXIgb3duIGluZ3Jlc3MgYW5kIGVncmVzcyB0cmFmZmljIHNoYXBlcnMg YXQgdGhlaXIgaG9tZSByb3V0ZXJzIGFzIHRoZSAzMDBtcyBidWZmZXJzIG9mIHRoZSBCTkcncyBh cmUganVzdCBub3QgYWNjZXB0YWJsZSBmb3IgYW55IHJlYWwtdGltaXNoIHVzZXMgKFZvSVAsIG9u LWxpbmUgdHdpdGNoIGdhbWluZywgZXZlbiBmb3IgaW50ZXJhY3RpdmUgc2Vzc2lvbnMgbGlrZSBz c2ggMzAwbXMgZGVsYXkgYXJlIHVuZGVzaXJhYmxlKS4gRS5nLiBwZXJzb25hbGx5LCBJIHVzZSBh biBPcGVuV3J0IHJvdXRlciB3aXRoIGFuIEZRIEFRTSBmb3IgYm90aCBpbmdyZXNzIGFuZCBlZ3Jl c3MgKGJhc2VkIG9uIEpvbmF0aGFuJ3MgZXhjZWxsZW50IGNha2UgcWRpc2MpIHRoYXQgYWxsb3dz IGEgZmFtaWx5IG9mIDUgdG8gaGFwcGlseSBzaGFyZSBhIDUwLzEwIGNvbm5lY3Rpb24gYmV0d2Vl biB2aWRlbyBzdHJlYW1pbmcgYW5kIGludGVyYWN0aXZlIHVzZSB3aXRoIHZlcnkgbGl0dGxlIGlu dGVyZmVyZW5jZSBiZXR3ZWVuIHRoZSB1c2VycywgdGhlIHNhbWUgbGluayB3aXRoIG91dCB0aGUg RlEtQVFNIGFjdGl2ZSBtYWtlcyBpbnRlcmFjdGl2ZSBhcHBsaWNhdGlvbnMgZmVlbCBsaWtlIHN1 Ym1lcmdlZCBpbiBtb2xhc3NlcyBvbmNlIHRoZSBsaW5rIGdldHMgc2F0dXJhdGVkLi4uDQoJQXMg ZmFyIGFzIEkgY2FuIHRlbGwgdGhlcmUgaXMgYSBudW1iZXIgb2YgZGlmZmVyZW50IHNvbHV0aW9u cyB0aGF0IG9mZmVyIGhvbWUtcm91dGVyIGJhc2VkIGJpLWRpcmVjdGlvbmFsIHRyYWZmaWMgc2hh cGluZyB0byBzb2x2ZSBidWZmZXJibG9hdCIgZnJvbSBob21lICh3ZWxsLCBub3QgZnVsbHkgc29s dmUgaXQsIGJ1dCByZW1lZHkgaXRzIGNvbnNlcXVlbmNlcyksIGluY2x1ZGluZyBjb21tZXJjaWFs IG9wdGlvbnMgbGlrZSBldmVucm91dGUncyBpcXJvdXRlciwgYW5kIG9wZW4tc291cmNlIG9wdGlv bnMgbGlrZSBPcGVuV3J0ICh3aXRoIHNxbS1zY3JpcHRzIGFzIHNoYXBlciBwYWNrZXQpLiANCglJ dCBpcyBleGFjdGx5IHRoaXMgdXNlIGNhc2UgYW5kIHRoZSBmYWN0IHRoYXQgbGF0ZW5jeS1zZW5z aXRpdmUgdXNlcnMgb2Z0ZW4gb3B0IGZvciB0aGlzIHNvbHV0aW9uLCB0aGF0IGNhdXNlcyBtZSB0 byBhc2sgdGhlIEw0UyBjcm93ZCB0byBhY3R1YWxseSBtZWFzdXJlIHRoZSBlZmZlY3Qgb2YgTDRT IG9uIFJGQzMxNjgtRlEtQVFNcyBpbiB0aGUgZXhhY3QgY29uZmlndXJhdGlvbiBpdCBpcyBhY3R1 YWxseSB1c2VkIHRvZGF5LCB0byByZW1lZHkgdGhlIHNhbWUgaXNzdWUgTDRTIHdhbnRzIHRvIHRh Y2tsZS4NCg0KQmVzdCBSZWdhcmRzDQoJU2ViYXN0aWFuDQoNCg0KPiANCj4gSSBjb3VsZCBmaWd1 cmUgb3V0IGEgc21hbGwgY2FtcHVzIG5ldHdvcmsgd2hpY2ggaGFzIGEgYm90dGxlbmVjayBhdCB0 aGUgSW50ZXJuZXQgYWNjZXNzIGFuZCBhIHNlY29uZCBvbmUgY29ubmVjdGluZyB0aGUgdGVybWlu YWwgZXF1aXBtZW50LiBCdXQgaW4gYSBzbWFsbCBjYW1wdXMgbmV0d29yaywgdGhlIGluZGl2aWR1 YWwgdGVybWluYWwgY291bGQgdmVyeSB3ZWxsIGhhdmUgYSBoaWdoZXIgTEFOIGFjY2VzcyBiYW5k d2lkdGgsIHRoYW4gdGhlIGNhbXB1cyAtIEludGVybmV0IGNvbm5lY3Rpb24gKGFuZCB0aGVuIHRo ZXJlJ3Mgb25seSBvbmUgYm90dGxlbmVjayBhZ2FpbikuDQo+IA0KPiBUaGVyZSBtYXkgYmUgYSB0 cmFkZW9mZiBiZXR3ZWVuIHNpbXBsaWNpdHkgYW5kIGdlbmVyYWwgYXBwbGljYWJpbGl0eS4gQXdh cmVuZXNzIG9mIHRoYXQgdHJhZGVvZmYgaXMgaW1wb3J0YW50LiBUbyBtZSwgc2ltcGxpY2l0eSBp cyB0aGUgZGVzaWduIGFpbS4gDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gUnVlZGlnZXIgDQo+IA0K PiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogdHN2d2cgPHRzdndn LWJvdW5jZXNAaWV0Zi5vcmc+IEltIEF1ZnRyYWcgdm9uIEpvbmF0aGFuIE1vcnRvbg0KPiBHZXNl bmRldDogRGllbnN0YWcsIDkuIEp1bGkgMjAxOSAxNzo0MQ0KPiBBbjogQm9iIEJyaXNjb2UgPGll dGZAYm9iYnJpc2NvZS5uZXQ+DQo+IENjOiB0Y3BtIElFVEYgbGlzdCA8dGNwbUBpZXRmLm9yZz47 IGVjbi1zYW5lQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldDsgdHN2d2cgSUVURiBsaXN0IDx0c3Z3Z0Bp ZXRmLm9yZz4NCj4gQmV0cmVmZjogUmU6IFt0c3Z3Z10gW0Vjbi1zYW5lXSBFQ04gQ0UgdGhhdCB3 YXMgRUNUKDApIGluY29ycmVjdGx5IGNsYXNzaWZpZWQgYXMgTDRTDQo+IA0KPj4gT24gMTMgSnVu LCAyMDE5LCBhdCA3OjQ4IHBtLCBCb2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD4gd3Jv dGU6DQo+PiANCj4+ICAgICAgMS4gIEl0IGlzIHF1aXRlIHVudXN1YWwgdG8gZXhwZXJpZW5jZSBx dWV1aW5nIGF0IG1vcmUgdGhhbiBvbmUNCj4+ICAgICAgICAgIGJvdHRsZW5lY2sgb24gdGhlIHNh bWUgcGF0aCAodGhlIGF2YWlsYWJsZSBjYXBhY2l0aWVzIGhhdmUgdG8NCj4+ICAgICAgICAgIGJl IGlkZW50aWNhbCkuDQo+IA0KPiBGb2xsb3dpbmcgdXAgb24gRGF2aWQgQmxhY2sncyBjb21tZW50 cywgSSdkIGp1c3QgbGlrZSB0byBub3RlIHRoYXQgdGhlIGFib3ZlIGlzIG5vdCB0aGUgdHJ1ZSBj cml0ZXJpb24gZm9yIG11bHRpcGxlIHNlcXVlbnRpYWwgcXVldWluZy4NCj4gDQo+IE1hbnkgZXhp c3RpbmcgVENQIHNlbmRlcnMgYXJlIHVucGFjZWQgKGFzaWRlIGZyb20gYWNrLWNsb2NraW5nKSwg aW5jbHVkaW5nIEZyZWVCU0QsIHJlc3VsdGluZyBpbiBwb3RlbnRpYWxseSBsYXJnZSBsaW5lLXJh dGUgYnVyc3RzIGF0IHRoZSBvcmlnaW4gLSBlc3BlY2lhbGx5IGR1cmluZyBzbG93LXN0YXJ0LiAg RXZlbiBpbiBjb25nZXN0aW9uIGF2b2lkYW5jZSwgZWFjaCBhY2sgd2lsbCB0cmlnZ2VyIGEgY2xv c2VseSBzcGFjZWQgcGFja2V0IHBhaXIgKG9yIHNvbWV0aW1lcyBhIHRyaXBsZXQpLiAgSXQgaXMg dGhlbiBlYXN5IHRvIGltYWdpbmUsIG9yIHRvIGJ1aWxkIGEgdGVzdGJlZCBjb250YWluaW5nLCBh biBhcmJpdHJhcmlseSBsb25nIHNlcXVlbmNlIG9mIGNvbnNlY3V0aXZlbHkgbmFycm93ZXIgbGlu a3M7IHVwb24gZW50ZXJpbmcgZWFjaCwgdGhlIGJ1cnN0IG9mIHBhY2tldHMgd2lsbCBicmllZmx5 IGNvbGxlY3QgaW4gYSBxdWV1ZSBhbmQgdGhlbiBiZSBwYWNlZCBvdXQgYXQgdGhlIG5ldyByYXRl Lg0KPiANCj4gVENQIHBhY2luZyBkb2VzIGxhcmdlbHkgZWxpbWluYXRlIHRoZXNlIGJ1cnN0cyB3 aGVuIGltcGxlbWVudGVkIGNvcnJlY3RseS4gIEhvd2V2ZXIsIExpbnV4JyBwYWNpbmcgYW5kIElX IGlzIHNwZWNpZmljYWxseSAoYW5kIGFwcGFyZW50bHkgZGVsaWJlcmF0ZWx5KSBzZXQgdXAgdG8g aXNzdWUgYSAxMC1wYWNrZXQgbGluZS1yYXRlIGJ1cnN0IG9uIHN0YXJ0dXAuICBUaGlzIGVmZmVj dCBoYXMgc2hvd24gdXAgaW4gU0NFIHRlc3RzIHRvIHRoZSBwb2ludCB3aGVyZSB3ZSBoYWQgdG8g cGF0Y2ggdGhpcyBiZWhhdmlvdXIgb3V0IG9mIHRoZSBzZW5kaW5nIGtlcm5lbCB0byBwcmV2ZW50 IGFuIGluc3RhbnQgZXhpdCBmcm9tIHNsb3ctc3RhcnQuDQo+IA0KPiAtIEpvbmF0aGFuIE1vcnRv bg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gRWNuLXNhbmUgbWFpbGluZyBsaXN0DQo+IEVjbi1zYW5lQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5l dA0KPiBodHRwczovL2xpc3RzLmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9lY24tc2FuZQ0KDQo= From nobody Mon Aug 5 02:36:19 2019 Return-Path: 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 CF6E51200A1; Mon, 5 Aug 2019 02:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 b-6DHvHFnFqJ; Mon, 5 Aug 2019 02:36:15 -0700 (PDT) Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 16984120077; Mon, 5 Aug 2019 02:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564997773; x=1596533773; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l/4mNRY0uV54zDSWa3jtWjkQX8wWqLKLHRjKKRp2+Zo=; b=ANwdeR/5+U62zd1zeEfHy4ycHWjKLyQvOywoyo1G1IrYyuboOUzx0qny GQFgYGfl5wiCpUEpIGb2A0BJ9TXxDvqyrS4U3eXQcOaXKQcRZXa8pgRjK BlmSSKNsNiuteizRE3OxdImgMEqxYYkyOJ+fDsIH9yF9MM4K1jnfVqfK1 rFFtKUx4EnJSqdVh6pV1bj8wtR5NTnthTZnpD/oKyRlqCoTjBD+U3ay2s UJTb/DzJpN/pUm2nHlGHS3kozGzHhmGNo9qF4/bwnuPd6IQqjpMkfmd6z WRieN2UavzRgGA1IXfGkZcx5iT4o29pKzhXN0z7AnQmEssQvFzEnB44X6 A==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 11:36:10 +0200 X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473241958" X-MGA-submission: =?us-ascii?q?MDHu/OrjxSTIOQ7vYWxJVNNCuGIam3y9Pe11F1?= =?us-ascii?q?xzpBSI0KTTWdl8eUVQYkaKHlfxSS9PYj1n8/MqhndJHm+/gdEjBoDBpF?= =?us-ascii?q?5q8j/upl8WFAe8IWg2LIHc2ekIeUhQh1zBFTQYSscQlWsDFJm8oWwbIz?= =?us-ascii?q?iLQLxziF7pFGwLxzZhPAeGSw=3D=3D?= Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Aug 2019 11:35:59 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 11:35:49 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 11:35:49 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.19) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 11:35:49 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0205.DEUPRD01.PROD.OUTLOOK.DE (10.158.164.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 09:35:48 +0000 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 09:35:48 +0000 From: To: CC: , , Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTwgAAbvwCABKfngA== Date: Mon, 5 Aug 2019 09:35:48 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> In-Reply-To: <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 177602fa-43b6-4d01-0e07-08d719884c5b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB0205; x-ms-traffictypediagnostic: LEXPR01MB0205: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(136003)(39850400004)(189003)(199004)(6116002)(3846002)(6306002)(256004)(2906002)(71200400001)(45776006)(81166006)(81156014)(14444005)(64756008)(76116006)(66446008)(66476007)(66946007)(66556008)(71190400001)(8676002)(8936002)(14454004)(966005)(76176011)(53936002)(66574012)(52396003)(7696005)(53546011)(102836004)(508600001)(476003)(66066001)(305945005)(7736002)(11346002)(446003)(9686003)(486006)(86362001)(5660300002)(6916009)(68736007)(186003)(4326008)(1411001)(26005)(54906003)(55016002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0205; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /dQaiOKs/xhlzbl2AlncrX01e+7FOFm+W4rbrBjAG6PlRbgdYcyuPTWoWIOjUr2i2C4vqorHFaSeMq3z3hgqq0/TmvhWu7+kPpaxMXJYO3DGVXZp4HylxoKrgyqO119v4fA5lCnmx9rzRYynZ+maNM5S66HU3V1z2m/3uGCBE0EWrH3TRQdD/fFqJaPwnvtLQLHxK73CvClcNseFjYtj1PnSozUuc545TITe47XR17mR7C0Zx5mvBRE58NyvKmGQBdSB6jrEZhnsdplT1fM9nci739Be11P+RZFVz+gxOLWfQ+58IIq3a53ofNJ5efJoC+I9X8VkbornAzANTKkGvBy8My2w+T2Edbad4htdl4Ux1138gVFX1h+laDzzXxO1GTo3wLOA/dAzXjbqaV5X0q5CDB4oKilqUWHTZx4xISk= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 177602fa-43b6-4d01-0e07-08d719884c5b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 09:35:48.3067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0205 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 09:36:18 -0000 Jonathan Morton marked [JM] below, Ruediger Geib [RG]. > On 2 Aug, 2019, at 9:29 am, wrote: >=20 > Hi Jonathan, >=20 > could you provide a real world example of links which are consecutively n= arrower than sender access links? >=20 > I could figure out a small campus network which has a bottleneck at the I= nternet access and a second one connecting the terminal equipment. But in a= small campus network, the individual terminal could very well have a highe= r LAN access bandwidth, than the campus - Internet connection (and then the= re's only one bottleneck again). >=20 > There may be a tradeoff between simplicity and general applicability. Awa= reness of that tradeoff is important. To me, simplicity is the design aim.= =20 [JM] A progressive narrowing of effective link capacity is very common in c= onsumer Internet access. Theoretically you can set up a chain of almost un= limited length of consecutively narrowing bottlenecks, such that a line-rat= e burst injected at the wide end will experience queuing at every intermedi= ate node. In practice you can expect typically three or more potentially n= arrowing points: [RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , firs= t two sentences. That's a sound starting point, and I don't think much has = changed since 2005.=20 [RG] About the bursts to expect, it's probably worth noting that today's mo= st popular application generating traffic bursts is watching video clips st= reamed over the Internet. Viewers dislike the movies to stall. My impressio= n is, all major CDNs are aware of that and try their best to avoid this sit= uation. In particular, I don't expect streaming bursts to overwhelm access = link shaper buffers by design. And that, I think, limits burst sizes of the= majority of traffic. [RG] Other people use their equipment to communicate and play games (that's= what I see when I use commuters). Unless gaming pictures are rendered on a= server or live pictures of communicating persons are streamed, there shoul= d be no bursts. Still I miss the consecutively narrowing bottlenecks with q= ueues being built at each instance with a likelihood justifying major engin= eering and deployment efforts. Any solution for Best Effort service which i= s TCP friendly and support scommunication expecting no congestion at the sa= me time should be easy to deploy and come with obvious benefits.=20 [RG] I found Sebastian's response sound. I think, there are people interest= ed in avoiding congestion at their access. [RG] I'd like to repeat again what's important to me: no corner case engine= ering. Is there something to be added to Sebastian's scenario? =20 From nobody Mon Aug 5 03:59:56 2019 Return-Path: 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 7E81412017F; Mon, 5 Aug 2019 03:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XlLtaJ8QpE6i; Mon, 5 Aug 2019 03:59:52 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D5D12017E; Mon, 5 Aug 2019 03:59:51 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id v16so3717304lfg.11; Mon, 05 Aug 2019 03:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=67873c6Ujww9PpG0/vpmOnnCffRtzd0TlT7xDJ/LIrw=; b=COoKF5Yw8XY792TSRXj15/IIKxTJMYR8KRTg3Gz37UiyaYzbhtxjTFiqHNx4EAsLDJ PV1uVhJC5TDg75/yS7HiXO2+imKm1KIQpA59uJ9yrha49XTNxtRU5YR1E3yklW/AUPmx xSO826+T4WzBi8mkUlDkFZ/IKxLgaLUG/UQjqLj/1qETpxoSSnUz3uirthvgbfDj+2eB tCxFlU+S78Ks83kdsv7eukK1ZzSRap3IaxlkTVS2PVpGlvMyi/J39bYwlU8lW9bdDklu fpL2qPjdLYh0DGTeGyQusTu+fnYnPMw0OhIfSpSpHIC5O3UlWt3AgmmxJmFQfA/3kEtH K4TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=67873c6Ujww9PpG0/vpmOnnCffRtzd0TlT7xDJ/LIrw=; b=QQLG0VlT9j0RRpGkoQ+dGxAbtZd5CqzYfQD35SNtt8/wijomjUJUMQtxpXJbR6P/G6 0OSgXmzOdlD1/oWvAM2xrks7EtsayD1JLXzuBFp0vH5A2gbFc8vXpYxMwJXPlPg86wwd dvhg75x+oPUQtS2CkLOai6RDMQjUsi81pS1e+3haR0REjYRzflG5AxuJnCAf6lCclqlb 2NdxLA92s0OFNDHdwrqhMeLSdzG1jR3WdZyAfDOJCSD+OtxTrXbXZADhsb/vt7DvGP1y SOEZqe21DdgEuzBrAIsQMvb76d2XdGGMEe1piEkIq2UY0tOwcxLXXO5CevbMStssbzNn SKLw== X-Gm-Message-State: APjAAAV5Mu4eE4uFFYt3i94ajvp4rlLZDUsxSSNWYw85JVLOfKr+WNow N6380ZINq+zd+Hg8rV4hYkk= X-Google-Smtp-Source: APXvYqwXymIPt5q0xWlprL0MchC5E6FJNcIS3kSTv7gxM3VUKR1j1o5kk0KMcp4vuHIG7f66muXL9g== X-Received: by 2002:ac2:4201:: with SMTP id y1mr8735611lfh.127.1565002789993; Mon, 05 Aug 2019 03:59:49 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-193-nat-p.elisa-mobile.fi. [83.245.237.193]) by smtp.gmail.com with ESMTPSA id d16sm2059625lfn.36.2019.08.05.03.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 03:59:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Mon, 5 Aug 2019 13:59:47 +0300 Cc: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@gmail.com> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 10:59:54 -0000 > [JM] A progressive narrowing of effective link capacity is very common = in consumer Internet access. Theoretically you can set up a chain of = almost unlimited length of consecutively narrowing bottlenecks, such = that a line-rate burst injected at the wide end will experience queuing = at every intermediate node. In practice you can expect typically three = or more potentially narrowing points: >=20 > [RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , = first two sentences. That's a sound starting point, and I don't think = much has changed since 2005.=20 As I said, that reference is *usually* true for *responsible* ISPs. Not = all ISPs, however, are responsible vis a vis their subscribers, as = opposed to their shareholders. There have been some high-profile = incidents of *deliberately* inadequate peering arrangements in the USA = (often involving Netflix vs major cable networks, for example), and = consumer ISPs in the UK *typically* have diurnal cycles of general = congestion due to under-investment in the high-speed segments of their = network. To say nothing of what goes on in Asia Minor and Africa, where demand = routinely far outstrips supply. In those areas, solutions to make the = best use of limited capacity would doubtless be welcomed. > [RG] About the bursts to expect, it's probably worth noting that = today's most popular application generating traffic bursts is watching = video clips streamed over the Internet. Viewers dislike the movies to = stall. My impression is, all major CDNs are aware of that and try their = best to avoid this situation. In particular, I don't expect streaming = bursts to overwhelm access link shaper buffers by design. And that, I = think, limits burst sizes of the majority of traffic. In my personal experience with YouTube, to pick a major video streaming = service not-at-all at random, the bursts last several seconds and are = essentially ack-clocked. It's just a high/low watermark system in the = receiving client's buffer; when it's full, it tells the server to stop = sending, and after it drains a bit it tells the server to start again. = When traffic is flowing, it's no different from any other bulk flow = (aside from the use of BBR instead of CUBIC or Reno) and can be managed = in the same way. The timescale I'm talking about, on the other hand, is sub-RTT. Packet = intervals may be counted in microseconds at origin, then gradually = spaced out into the millisecond range as they traverse the successive = bottlenecks en route. As I mentioned, there are several circumstances = when today's servers emit line-rate bursts of traffic; these can also = result from aggregation in certain link types (particularly wifi), and = hardware offload engines which try to treat multiple physical packets = from the same flow as one. This then results in transient queuing = delays as the next bottleneck spaces them out again. When several such bursts coincide at a single bottleneck, moreover, the = queuing required to accommodate them may be as much as their sum. This = "incast effect" is particularly relevant in datacentres, which routinely = produce synchronised bursts of traffic as responses to distributed = queries, but can also occur in ordinary web traffic when multiple = servers are involved in a single page load. IW10 does not mean you only = need 10 packets of buffer space, and many CDNs are in fact using even = larger IWs as well. These effects really do exist; we have measured them in the real world, = reproduced them in lab conditions, and designed qdiscs to accommodate = them as cleanly as possible. The question is to what extent they are = relevant to the design of a particular technology or deployment; some = will be much more sensitive than others. The only way to be sure of the = answer is to be aware, and do the appropriate maths. > [RG] Other people use their equipment to communicate and play games These are examples of traffic that would be sensitive to the delay from = transient queuing caused by other traffic. The most robust answer here = is to implement FQ at each such queue. Other solutions may also exist. > Any solution for Best Effort service which is TCP friendly and support = scommunication expecting no congestion at the same time should be easy = to deploy and come with obvious benefits.=20 Well, obviously. Although not everyone remembers this at design time. > [RG] I found Sebastian's response sound. I think, there are people = interested in avoiding congestion at their access. > the access link is the bottleneck, that's what's to be expected. It is typically *a* bottleneck, but there can be more than one from the = viewpoint of a line-rate burst. > [RG] I'd like to repeat again what's important to me: no corner case = engineering. Is there something to be added to Sebastian's scenario? He makes an essentially similar point to mine, from a different = perspective. Hopefully the additional context provided above is = enlightening. - Jonathan Morton= From nobody Mon Aug 5 04:00:50 2019 Return-Path: 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 983481201C3; Mon, 5 Aug 2019 04:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=gmx.net 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 IDS1YvSsj_Bj; Mon, 5 Aug 2019 04:00:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35D212018B; Mon, 5 Aug 2019 04:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1565002829; bh=WK+5nuAvvUIPlf6JYWCBbP4ifWzdsu5X02hwSqegQDM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=aEWCeGRVBFdE/7+BWikT9t1IwIMMsgda/3JqS9QKK6pLQ6BM4AqnyigAHvJO34Mti EXj72VwM0dg24mM15xRcUIUwyhtF8p1rGheHB0MpeP+Ad+pNc77YKZnDRfnX6WK+JY e0ARxkICAOSWzzXRaXxWUJC6HHeDW5wiydHKIKpw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LsTjw-1iJ1RF0hHU-011xDw; Mon, 05 Aug 2019 13:00:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 5 Aug 2019 13:00:26 +0200 Cc: tcpm@ietf.org, ECN-Sane , tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:xWMMx0W/HvsBTzzIiG4OGVaTsydN2TG24hNRMVQUDxFYJ2BeTVR 7fhAiEDivOQdev62PHYXpAEcPUD0J9KUMJY7HKQK8fZPywFDweT+re4IFaSCwMNCe5GlbA7 UoiUsR/ur5qNBJU8GDPhxowZoXZosLwDnW6PBbBOIkdhoe046Si5Z64LdgrsmNEJBAreoS4 B96mUYy2vMXgmSJ5ix1SQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:hAwhl4ZQ5UE=:JdM/WDNfGd1tRR4CDeilLk gy2lyhydztKSlKdUSTED15N3syUGGcQBzL4yjggeQCXU7PDvxFWUjy7ld2ZmyRRCLs9MVet7P OrwMIWhVEoRccA7kuVV0V7pwXyrmKPo7AY+NPSyoZN6ybcKknYBR0frqpmzekmL6pqhyVxu8k 6cQmUCVe0S+Q5eFrRtMB3weurYaba8JDFXv9lEQbhwHw023VT7RUHufdYeuPD6IgabBXqLyAl ACscMHWNuR0XmlrHisnIysB/ayHfCh7VGjOyPysa+LZk7qtaTAR3gcXteX2gsJcG3uHpm8a4D nWfF5ha7e44QpXYrtBOvggs2E3qlUUZ1LzBu34hHSw1tVtLvL5mv9qYudEJl6sCiA6unxvVox HCDQl3ZdseZvePSEehy+bUq2fKCj8LlKj0EsnIKHVxQ+qULdsFOH5tVAf4YRyq0hN2HzQCWbP TFe0yv06G0Ny2YIuy/SSjrzj/4xjj1sv/Ptda7rV/C879YPGjEw1KygYZWLzQqPLBDwI5qKUJ DjJJ3+Xsr2wgItyvAMv/R5QZOxA+Bv/LhRiXDuBhKj3t2tvGTsmW+toMWwvyZWU2pLY6iwYAr GouR1RbxjiQrJe0d02UBy1ZePilJ/5+uqZW3OiOe4HmijLd6ewxPhvX5rNG/0kTUxIArtlxuu ZUZiq+1xbcVfVBmI/k9mdOFLw5sBloAFYxEK3DQSPyDhzjSAbp7rbN7VaebW9uq6JthHeSE4z kGUxaxIKx+i9JIkyaHUUT3oGhxOaB2fgfNV+7KjSCtDac/D7RnulX2cKA8GY+mxqkgdx71oRR T2vWe6qC0+pzO3F5G15FTEXd2XUCvxGPnZgSpW+FYRLsBMynREkdVVTZpdrjOI/jLvZp3S0Lr S3Xbbi1jEYlPtdY3K3QYSaLY1fY4EVCnCQEr7C5zIXfqTWjav4qmXLsOKShoxflrN+e6XTmyF pLBZmrnYGCe4p1PZWC0vnsCdpWH6D3a5uy/OkrM16P10kmoKtCGYbNCdCwqh5a7J0aask5TLF y6gPGhIgS08t4yYj/x3P1sUjUgWZhYkCnwfCklqz8GeUrrMfLpfokx2Ip6PF6YGPkyF7RakKW cvRF2lasG7qPlaUBs7WmxyEKnAEWQlhM8G5jMoOTFExAlx4onlN2lJlH7tQhMZDfhfPxjCMVZ /v01Y= Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 11:00:41 -0000 Hi Ruediger, > On Aug 5, 2019, at 09:26, = wrote: >=20 > Hi Sebastian, >=20 > the access link is the bottleneck, that's what's to be expected. Mostly, then again there are situations with 1Gbps Plans where = it is not the actual access link, but rather the CPEs Gigabit ethernet = LAN ports that are the true bottleneck, but that does not substantially = change the issue, it is still the upstream shaper/policer that needs to = be worked around. > As far as I know, in the operator world shapers here by and large = removed policers. Good to know, shapers are somewhat nicer to user traffic than = hard policers, at least that is my interpretation. >=20 > A consecutive chain of narrower links results, if the Home Gateway = runs with an additional ingress or egress shaper operating below the = access bandwidth, if I get you right.=20 Yes, as you state below, this only is true for the ingress = direction, egress shaping works reliably and is typically not suffering = from this. That said, if the egress link bandwidth is larger than a = servers connection this issue can appear also for the egress direction. = For example overly hot peering/transit links can cause downstream = bottlenecks considerably narrower than the internet access link's upload = direction, but that, while unfortunate, is not at the core of my issue. >=20 > I understand that you aren't interested in having 300ms buffer delay = and may be some jitter for a phone conversation using best effort = transport. +1 > A main driver for changes in consumer IP access features in Germany = are publications of journals and regulators comparing IP access = performance of different providers. Good to know, > Should one provider have an advantage over the others by deploying a = solution as you (and Bob's team) work on, it likely will be generally = deployed. I do not believe that these mechanisms are actually in play in = the German market, as an example for roughly a decade the DOCSIS-ISPs = offer higher bandwidth for same or less money than the incumbent telco = and yet only managed to get 30% of the customers of their ~75% of = possible customers, so only 75*0.3 =3D 22.5 % market share, with the = incumbent only reaching 250/40 for the masses while the DOCSIS ISPs = offer 1000/50. And unlike latency, bandwidth (or rather rate) is the = number that consumers understand intuitively. If anything will expedite the roll-out of L4S style AQMs it is = the capability to use those to implement the "special services" that the = EU net neutrality regulation explicitly allows, as that is a product = that can be actually sold to customers, but I might be too pessimistic = here. >=20 > As far as I can see, latency aware consumers still are a minority and = gamers seem to be a big group belonging here. Interest in well = performing gaming seems to be growing, I guess (for me at least it's an = impression rather than a clear trend). Put that way, I see a way for ISPs to distinguish themselves = from the rest by being gaming friendly, but unless this results in = gamers paying more I fail to see the business case that management = probably needs before green-lighting the funds required to implement = this. This is where cablelabs approach to mandate this in the specs is = brilliant.=20 >=20 > I'd personally prefer an easy to deploy and operate standard solution = offering Best Effort based transport being TCP friendly and at the same = time congestion free for other flows at a BNG for traffic in access = direction (and for similar devices in other architectures of course).=20 >=20 > Fighting bufferbloat in the upstream direction the way you describe it = doesn't construct a chain of links which are consecutively narrower than = the bottleneck link, I think. Yes, fully agreed, that said, and ISPs CPE should implement an = AQM to really solve the latency issues for end-users. The initial L4S = paper side-stepped that requirement by making sure the uplinks were not = saturated during the test, and state that that needs a real solution for = proper roll-out. In theory the ISP could do the uplink shaping on its = end (and to constrain users to their contracted rates, ISPs do this = already) but as in the downstream case, running an AQM in front of a = bottleneck as opposed to behind it makes everything much easier. Also = with uplinks typically << downlinks, the typically weak CPE CPUs will = still be able to AQM the uplink, nicely distributing that computation = load away from the BNG/BRAS big iron .... Best Regards Sebastian >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Sebastian Moeller =20 > Gesendet: Freitag, 2. August 2019 15:15 > An: Geib, R=C3=BCdiger > Cc: Jonathan Morton ; tcpm@ietf.org; ECN-Sane = ; tsvwg@ietf.org > Betreff: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly = classified as L4S >=20 > Hi Ruediger, >=20 >=20 >=20 >> On Aug 2, 2019, at 10:29, = wrote: >>=20 >> Hi Jonathan, >>=20 >> could you provide a real world example of links which are = consecutively narrower than sender access links? >=20 > Just an example from a network you might be comfortable with, in = DTAGs internet access network there typically are traffic limiting = elements at the BNGs (or at the BRAS for the legacy network), I am not = 100% sure whether these are implemented as policers or shapers, but they = tended to come with >=3D 300ms buffering. Since recently, the BNG/BRAS = traffic shaper's use the message field of the PPPoE Auth ACK to transfer = information about the TCP/IPv4 Goodput endusers can expect on their link = as a consequence of the BNG/BRAS"s traffic limiter. In DOCSIS and GPON = networks the traffic shaper seems mandated by the standards, in DSL = networks it seems optional (but there even without a shaper the limited = bandwidth of the access link would be a natural traffic choke point). > Fritzbox home router's now use this information to automatically set = egress (and I believe also) ingress traffic shaping on the CPE to reduce = the bufferbloat users experience. I have no insight in what Telekom's = own Speedport routers do, but I would not be surprised if they would do = the same (at least for egress).=20 > As Jonathan and Dave mentioned, quite a number of end-users, = especially the latency sensitive ones, employ their own ingress and = egress traffic shapers at their home routers as the 300ms buffers of the = BNG's are just not acceptable for any real-timish uses (VoIP, on-line = twitch gaming, even for interactive sessions like ssh 300ms delay are = undesirable). E.g. personally, I use an OpenWrt router with an FQ AQM = for both ingress and egress (based on Jonathan's excellent cake qdisc) = that allows a family of 5 to happily share a 50/10 connection between = video streaming and interactive use with very little interference = between the users, the same link with out the FQ-AQM active makes = interactive applications feel like submerged in molasses once the link = gets saturated... > As far as I can tell there is a number of different solutions = that offer home-router based bi-directional traffic shaping to solve = bufferbloat" from home (well, not fully solve it, but remedy its = consequences), including commercial options like evenroute's iqrouter, = and open-source options like OpenWrt (with sqm-scripts as shaper = packet).=20 > It is exactly this use case and the fact that latency-sensitive = users often opt for this solution, that causes me to ask the L4S crowd = to actually measure the effect of L4S on RFC3168-FQ-AQMs in the exact = configuration it is actually used today, to remedy the same issue L4S = wants to tackle. >=20 > Best Regards > Sebastian >=20 >=20 >>=20 >> I could figure out a small campus network which has a bottleneck at = the Internet access and a second one connecting the terminal equipment. = But in a small campus network, the individual terminal could very well = have a higher LAN access bandwidth, than the campus - Internet = connection (and then there's only one bottleneck again). >>=20 >> There may be a tradeoff between simplicity and general applicability. = Awareness of that tradeoff is important. To me, simplicity is the design = aim.=20 >>=20 >> Regards, >>=20 >> Ruediger=20 >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: tsvwg Im Auftrag von Jonathan Morton >> Gesendet: Dienstag, 9. Juli 2019 17:41 >> An: Bob Briscoe >> Cc: tcpm IETF list ; ecn-sane@lists.bufferbloat.net; = tsvwg IETF list >> Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly = classified as L4S >>=20 >>> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe = wrote: >>>=20 >>> 1. It is quite unusual to experience queuing at more than one >>> bottleneck on the same path (the available capacities have = to >>> be identical). >>=20 >> Following up on David Black's comments, I'd just like to note that = the above is not the true criterion for multiple sequential queuing. >>=20 >> Many existing TCP senders are unpaced (aside from ack-clocking), = including FreeBSD, resulting in potentially large line-rate bursts at = the origin - especially during slow-start. Even in congestion = avoidance, each ack will trigger a closely spaced packet pair (or = sometimes a triplet). It is then easy to imagine, or to build a testbed = containing, an arbitrarily long sequence of consecutively narrower = links; upon entering each, the burst of packets will briefly collect in = a queue and then be paced out at the new rate. >>=20 >> TCP pacing does largely eliminate these bursts when implemented = correctly. However, Linux' pacing and IW is specifically (and = apparently deliberately) set up to issue a 10-packet line-rate burst on = startup. This effect has shown up in SCE tests to the point where we = had to patch this behaviour out of the sending kernel to prevent an = instant exit from slow-start. >>=20 >> - Jonathan Morton >>=20 >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane >=20 From nobody Mon Aug 5 04:48:15 2019 Return-Path: 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 608B312019B; Mon, 5 Aug 2019 04:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 hwo6QsD6LkJQ; Mon, 5 Aug 2019 04:48:10 -0700 (PDT) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 987EE12018E; Mon, 5 Aug 2019 04:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1565005685; x=1596541685; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X6ZZsmI77bD/J+6eTRsByHmcwSSnkdcviBRM6Hwpcyg=; b=AX5j/f6sRDBNeWPYpttB0ysBJi2obfslvEdhR6X/qLf2eiTHP9WZmV0Q A0d2ovTHxaZC2jMG2htDT1weBU9jM5ozl77tVM/wE9Q2UWMsyWH6iLCna H76ocHXZJ/wLwQwWKeEVgThIIqSxqdVKeYb8DZ2H/m2FTpkuyF9lyZZAW 9GUi4BKFHpC4uIgWpd0dbyc3ash/HTxaeHA0d3BGIrnCy3gD1OqibFNgO 1TYWGL7WJaCng71c++rdM18Zj4y86OT1Z+0WKR1ggj+bKzzV3yjOHtkTZ Jn5Fj14gpI08lNpao3wQCZk1JyH5S6CTh/ZhCvjQ3sbefMCGGjAfwMohs g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 13:47:48 +0200 X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="595219611" X-MGA-submission: =?us-ascii?q?MDEDgLTgvgPdWgggKVXhCld/4yGisUMPlhPSO2?= =?us-ascii?q?aNOIOqolfcMDLqhFWok74laEReIwAWJPtmEzujG6eZyr9llhLAhcWZYs?= =?us-ascii?q?v+2PTbEP8R3XnWbDb171/29zxA+pkOjh1hsZN5vMI0dOjG29ocR7e2NP?= =?us-ascii?q?vGagPVpefQUwBgYaVaVlmc+g=3D=3D?= Received: from he105865.emea1.cds.t-internal.com ([10.169.119.42]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Aug 2019 13:47:52 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105865.emea1.cds.t-internal.com (10.169.119.42) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 13:47:52 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 13:47:52 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 13:47:51 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0461.DEUPRD01.PROD.OUTLOOK.DE (10.158.165.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 11:47:51 +0000 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 11:47:51 +0000 From: To: CC: , , Thread-Topic: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVSTRkPkpydBILe0SaPVsimE5Fu6bsIA6QgABHggCAAAbSQA== Date: Mon, 5 Aug 2019 11:47:51 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> In-Reply-To: <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b775f31e-0cf3-4632-73d4-08d7199abebf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB0461; x-ms-traffictypediagnostic: LEXPR01MB0461: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(396003)(346002)(376002)(199004)(189003)(53546011)(26005)(14444005)(6916009)(7736002)(53936002)(85182001)(305945005)(478600001)(5660300002)(476003)(446003)(7696005)(256004)(11346002)(76176011)(102836004)(4326008)(486006)(52396003)(66066001)(85202003)(71190400001)(8676002)(54906003)(9686003)(30864003)(2906002)(81166006)(64756008)(68736007)(66946007)(71200400001)(66574012)(81156014)(66556008)(66446008)(966005)(14454004)(6306002)(316002)(8936002)(76116006)(86362001)(6116002)(33656002)(3846002)(66476007)(55016002)(186003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0461; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xyWUFVu1ftiRBFOU4U8bjl8NNqDoAUTVo5nIKv3la9IedQ9TVw4hhhppA+ogqWbPuRnlBGX7UScXKAK2pLcMOYtP1fIZNgCx22KdsUw0fvh/JjgZZ6O5696e6rC5v7ikxM1wXVFIX4PsRT2xtN9DJ/MkQUxJEO/sti6TdbtWJFePv4PcO1Zh696eLNFGAWZ4xsaQwlp1+aScbGUpx/Cpube2OBF81P8hqE2CmiSQx94p2e1BRYFOxXy3+7eKTDmd0KESLvkwJA85r/TyOfWcPUKl3o0AsDQNn/tPIcF8qs7hNKq/9QzBB83LuY3SwdJh0Ph/0J6rxYNx+wXeDrcA9TA98pqofoAgI6oP4WEyDEo8EgdykRK6Zs51LdIZs6rxDV9g8IMgUjVOWlMm/kmUcvAVsS1iyKEcz18a5Vax5y0= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b775f31e-0cf3-4632-73d4-08d7199abebf X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 11:47:51.1440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0461 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 11:48:14 -0000 SGkgU2ViYXN0aWFuLA0KDQp0aGFua3MuIFRocmVlIG1vcmUgcmVtYXJrczoNCg0KSSdtIGhhcHB5 IGZvciBhbnkgQVFNIGRlc2lnbiB3aGljaCBjb21lcyBhdCBsb3cgaW1wbGVtZW50YXRpb24gY29z dCBhbmQgYWxsb3dzIG1lIHRvIGFkZCB2YWx1ZSB0byBuZXR3b3JrIG9wZXJhdGlvbiAoYmUgaXQg c2F2aW5nIGNvc3QsIGJlIGl0IGVuYWJsaW5nIHZhbHVlIGFkZGVkIHNlcnZpY2VzKS4gQW5kIEkg dGhpbmsgdGhlIHJlcHJlc2VudGF0aXZlcyBvZiBvdGhlciBvcGVyYXRvcnMgYXJlIHNvIHRvby4N Cg0KRm9yIG1vc3QgY29uc3VtZXJzLCBzdHJlYW1pbmcgaXMgdGhlIG1vc3QgYmFuZHdpZHRoIGh1 bmdyeSBhcHBsaWNhdGlvbi4gSSB0aGluayBzb21lb25lIG5vdyB3b3JraW5nIGZvciBHb29nbGUg cHVibGlzaGVkIHJlc2VhcmNoLCB0aGF0IGF0IHRoZSB0aW1lIHdoZW4gSW50ZXJuZXQgYWNjZXNz IGJhbmR3aWR0aCBubyBsb25nZXIgaGFkIGFuIGltcGFjdCBvbiB0aGUgc3RyZWFtaW5nIHF1YWxp dHksIGNvbnN1bWVycyBzdGFydGVkIHRvIGxvc2UgaW50ZXJlc3QgaW4gImFjY2VzcyBzcGVlZCIg YXMgYW4gaW1wb3J0YW50IG1lYXN1cmUgb2YgcXVhbGl0eSBvZiB0aGVpciBJbnRlcm5ldCBhY2Nl c3MuIEkgdGhpbmsgaXQgdGFrZXMgYSB3aGlsZSB1bnRpbCBKb2huIERvZSByZXF1aXJlcyBhIG4q MTAwIE1iaXQvcyBJbnRlcm5ldCBhY2Nlc3MsIGJlY2F1c2UgYW55IGFjY2VzcyBiZWxvdyAxMDAg TWJpdC9zIGNhdXNlcyBjb25nZXN0aW9uIGZvciB0aGUgc2VydmljZXMgY29uc3VtZWQgYnkgSm9o bi4gDQoNCkkgc2VlIG1hbnkgcGVvcGxlIGFyb3VuZCBtZSBjb252ZW5pZW50bHkgdXNlIHRoZWly IHNtYXJ0cGhvbmUgdG8gYWNjZXNzIHRoZSBJbnRlcm5ldC4gQSBoYW5kaGVsZCBkaXNwbGF5IGxp a2VseSByZXF1aXJlcyBsZXNzIGJhbmR3aWR0aCBmb3IgYW4gYWNjZXB0YWJsZSBkaXNwbGF5IHF1 YWxpdHksIHRoYW4gYSBsYXJnZSBzY3JlZW4uIFRoYXQgZG9lc24ndCBzYXksIHRoZSBsYXR0ZXIg ZGlzYXBwZWFyLiBCdXQgbWF5YmUgb25seSBvbmUgb3IgdHdvIG9mIHRoZW0gbmVlZCB0byBiZSBz ZXJ2ZWQgcGVyIGNvbnN1bWVyIGFjY2Vzcy4gVGhhdCB3aWxsIHdvcmsgd2l0aCAxMDAgTWJpdC9z IG9yIGxlc3MgZm9yIGEgd2hpbGUgKG90aGVyIGJhbmR3aWR0aCBodW5ncnkgYXBwbGljYXRpb25z IHdpbGwgYXJyaXZlIHNvbWUgZGF5OyBJIHByZWZlciB0aGUgY29wcGVyIGFjY2VzcyBsaW5lcyBp biB0aGUgZ3JvdW5kIHRvIGJlIHJlcGxhY2VkIGJ5IGZpYmVyIG9uZXMpLg0KIA0KUmVnYXJkcywg UnVlZGlnZXINCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBTZWJh c3RpYW4gTW9lbGxlciA8bW9lbGxlcjBAZ214LmRlPiANCkdlc2VuZGV0OiBNb250YWcsIDUuIEF1 Z3VzdCAyMDE5IDEzOjAwDQpBbjogR2VpYiwgUsO8ZGlnZXIgPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZT4NCkNjOiB0Y3BtQGlldGYub3JnOyBFQ04tU2FuZSA8ZWNuLXNhbmVAbGlzdHMuYnVmZmVy YmxvYXQubmV0PjsgdHN2d2dAaWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbRWNuLXNhbmVdIFt0c3Z3 Z10gRUNOIENFIHRoYXQgd2FzIEVDVCgwKSBpbmNvcnJlY3RseSBjbGFzc2lmaWVkIGFzIEw0Uw0K DQpIaSBSdWVkaWdlciwNCg0KDQo+IE9uIEF1ZyA1LCAyMDE5LCBhdCAwOToyNiwgPFJ1ZWRpZ2Vy LkdlaWJAdGVsZWtvbS5kZT4gPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4gd3JvdGU6DQo+IA0K PiBIaSBTZWJhc3RpYW4sDQo+IA0KPiB0aGUgYWNjZXNzIGxpbmsgaXMgdGhlIGJvdHRsZW5lY2ss IHRoYXQncyB3aGF0J3MgdG8gYmUgZXhwZWN0ZWQuDQoNCglNb3N0bHksIHRoZW4gYWdhaW4gdGhl cmUgYXJlIHNpdHVhdGlvbnMgd2l0aCAxR2JwcyBQbGFucyB3aGVyZSBpdCBpcyBub3QgdGhlIGFj dHVhbCBhY2Nlc3MgbGluaywgYnV0IHJhdGhlciB0aGUgQ1BFcyBHaWdhYml0IGV0aGVybmV0IExB TiBwb3J0cyB0aGF0IGFyZSB0aGUgdHJ1ZSBib3R0bGVuZWNrLCBidXQgdGhhdCBkb2VzIG5vdCBz dWJzdGFudGlhbGx5IGNoYW5nZSB0aGUgaXNzdWUsIGl0IGlzIHN0aWxsIHRoZSB1cHN0cmVhbSBz aGFwZXIvcG9saWNlciB0aGF0IG5lZWRzIHRvIGJlIHdvcmtlZCBhcm91bmQuDQoNCj4gQXMgZmFy IGFzIEkga25vdywgaW4gdGhlIG9wZXJhdG9yIHdvcmxkIHNoYXBlcnMgaGVyZSBieSBhbmQgbGFy Z2UgcmVtb3ZlZCBwb2xpY2Vycy4NCg0KCUdvb2QgdG8ga25vdywgc2hhcGVycyBhcmUgc29tZXdo YXQgbmljZXIgdG8gdXNlciB0cmFmZmljIHRoYW4gaGFyZCBwb2xpY2VycywgYXQgbGVhc3QgdGhh dCBpcyBteSBpbnRlcnByZXRhdGlvbi4NCg0KPiANCj4gQSBjb25zZWN1dGl2ZSBjaGFpbiBvZiBu YXJyb3dlciBsaW5rcyByZXN1bHRzLCBpZiB0aGUgSG9tZSBHYXRld2F5IHJ1bnMgd2l0aCBhbiBh ZGRpdGlvbmFsIGluZ3Jlc3Mgb3IgZWdyZXNzIHNoYXBlciBvcGVyYXRpbmcgYmVsb3cgdGhlIGFj Y2VzcyBiYW5kd2lkdGgsIGlmIEkgZ2V0IHlvdSByaWdodC4gDQoNCglZZXMsIGFzIHlvdSBzdGF0 ZSBiZWxvdywgdGhpcyBvbmx5IGlzIHRydWUgZm9yIHRoZSBpbmdyZXNzIGRpcmVjdGlvbiwgZWdy ZXNzIHNoYXBpbmcgd29ya3MgcmVsaWFibHkgYW5kIGlzIHR5cGljYWxseSBub3Qgc3VmZmVyaW5n IGZyb20gdGhpcy4gVGhhdCBzYWlkLCBpZiB0aGUgZWdyZXNzIGxpbmsgYmFuZHdpZHRoIGlzIGxh cmdlciB0aGFuIGEgc2VydmVycyBjb25uZWN0aW9uIHRoaXMgaXNzdWUgY2FuIGFwcGVhciBhbHNv IGZvciB0aGUgZWdyZXNzIGRpcmVjdGlvbi4gRm9yIGV4YW1wbGUgb3Zlcmx5IGhvdCBwZWVyaW5n L3RyYW5zaXQgbGlua3MgY2FuIGNhdXNlIGRvd25zdHJlYW0gYm90dGxlbmVja3MgY29uc2lkZXJh Ymx5IG5hcnJvd2VyIHRoYW4gdGhlIGludGVybmV0IGFjY2VzcyBsaW5rJ3MgdXBsb2FkIGRpcmVj dGlvbiwgYnV0IHRoYXQsIHdoaWxlIHVuZm9ydHVuYXRlLCBpcyBub3QgYXQgdGhlIGNvcmUgb2Yg bXkgaXNzdWUuDQoNCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmVuJ3QgaW50ZXJlc3Rl ZCBpbiBoYXZpbmcgMzAwbXMgYnVmZmVyIGRlbGF5IGFuZCBtYXkgYmUgc29tZSBqaXR0ZXIgZm9y IGEgcGhvbmUgY29udmVyc2F0aW9uIHVzaW5nIGJlc3QgZWZmb3J0IHRyYW5zcG9ydC4NCg0KCSsx DQoNCj4gQSBtYWluIGRyaXZlciBmb3IgY2hhbmdlcyBpbiBjb25zdW1lciBJUCBhY2Nlc3MgZmVh dHVyZXMgaW4gR2VybWFueSBhcmUgcHVibGljYXRpb25zIG9mIGpvdXJuYWxzIGFuZCByZWd1bGF0 b3JzIGNvbXBhcmluZyBJUCBhY2Nlc3MgcGVyZm9ybWFuY2Ugb2YgZGlmZmVyZW50IHByb3ZpZGVy cy4NCg0KCUdvb2QgdG8ga25vdywNCg0KPiBTaG91bGQgb25lIHByb3ZpZGVyIGhhdmUgYW4gYWR2 YW50YWdlIG92ZXIgdGhlIG90aGVycyBieSBkZXBsb3lpbmcgYSBzb2x1dGlvbiBhcyB5b3UgKGFu ZCBCb2IncyB0ZWFtKSB3b3JrIG9uLCBpdCBsaWtlbHkgd2lsbCBiZSBnZW5lcmFsbHkgZGVwbG95 ZWQuDQoNCglJIGRvIG5vdCBiZWxpZXZlIHRoYXQgdGhlc2UgbWVjaGFuaXNtcyBhcmUgYWN0dWFs bHkgaW4gcGxheSBpbiB0aGUgR2VybWFuIG1hcmtldCwgYXMgYW4gZXhhbXBsZSBmb3Igcm91Z2hs eSBhIGRlY2FkZSB0aGUgRE9DU0lTLUlTUHMgb2ZmZXIgaGlnaGVyIGJhbmR3aWR0aCBmb3Igc2Ft ZSBvciBsZXNzIG1vbmV5IHRoYW4gdGhlIGluY3VtYmVudCB0ZWxjbyBhbmQgeWV0IG9ubHkgbWFu YWdlZCB0byBnZXQgMzAlIG9mIHRoZSBjdXN0b21lcnMgb2YgdGhlaXIgfjc1JSBvZiBwb3NzaWJs ZSBjdXN0b21lcnMsIHNvIG9ubHkgNzUqMC4zID0gMjIuNSAlIG1hcmtldCBzaGFyZSwgd2l0aCB0 aGUgaW5jdW1iZW50IG9ubHkgcmVhY2hpbmcgMjUwLzQwIGZvciB0aGUgbWFzc2VzIHdoaWxlIHRo ZSBET0NTSVMgSVNQcyBvZmZlciAxMDAwLzUwLiBBbmQgdW5saWtlIGxhdGVuY3ksIGJhbmR3aWR0 aCAob3IgcmF0aGVyIHJhdGUpIGlzIHRoZSBudW1iZXIgdGhhdCBjb25zdW1lcnMgdW5kZXJzdGFu ZCBpbnR1aXRpdmVseS4NCglJZiBhbnl0aGluZyB3aWxsIGV4cGVkaXRlIHRoZSByb2xsLW91dCBv ZiBMNFMgc3R5bGUgQVFNcyBpdCBpcyB0aGUgY2FwYWJpbGl0eSB0byB1c2UgdGhvc2UgdG8gaW1w bGVtZW50IHRoZSAic3BlY2lhbCBzZXJ2aWNlcyIgdGhhdCB0aGUgRVUgbmV0IG5ldXRyYWxpdHkg cmVndWxhdGlvbiBleHBsaWNpdGx5IGFsbG93cywgYXMgdGhhdCBpcyBhIHByb2R1Y3QgdGhhdCBj YW4gYmUgYWN0dWFsbHkgc29sZCB0byBjdXN0b21lcnMsIGJ1dCBJIG1pZ2h0IGJlIHRvbyBwZXNz aW1pc3RpYyBoZXJlLg0KDQo+IA0KPiBBcyBmYXIgYXMgSSBjYW4gc2VlLCBsYXRlbmN5IGF3YXJl IGNvbnN1bWVycyBzdGlsbCBhcmUgYSBtaW5vcml0eSBhbmQgZ2FtZXJzIHNlZW0gdG8gYmUgYSBi aWcgZ3JvdXAgYmVsb25naW5nIGhlcmUuIEludGVyZXN0IGluIHdlbGwgcGVyZm9ybWluZyBnYW1p bmcgc2VlbXMgdG8gYmUgZ3Jvd2luZywgSSBndWVzcyAoZm9yIG1lIGF0IGxlYXN0IGl0J3MgYW4g aW1wcmVzc2lvbiByYXRoZXIgdGhhbiBhIGNsZWFyIHRyZW5kKS4NCg0KCVB1dCB0aGF0IHdheSwg SSBzZWUgYSB3YXkgZm9yIElTUHMgdG8gZGlzdGluZ3Vpc2ggdGhlbXNlbHZlcyBmcm9tIHRoZSBy ZXN0IGJ5IGJlaW5nIGdhbWluZyBmcmllbmRseSwgYnV0IHVubGVzcyB0aGlzIHJlc3VsdHMgaW4g Z2FtZXJzIHBheWluZyBtb3JlIEkgZmFpbCB0byBzZWUgdGhlIGJ1c2luZXNzIGNhc2UgdGhhdCBt YW5hZ2VtZW50IHByb2JhYmx5IG5lZWRzIGJlZm9yZSBncmVlbi1saWdodGluZyB0aGUgZnVuZHMg cmVxdWlyZWQgdG8gaW1wbGVtZW50IHRoaXMuIFRoaXMgaXMgd2hlcmUgY2FibGVsYWJzIGFwcHJv YWNoIHRvIG1hbmRhdGUgdGhpcyBpbiB0aGUgc3BlY3MgaXMgYnJpbGxpYW50LiANCg0KPiANCj4g SSdkIHBlcnNvbmFsbHkgcHJlZmVyIGFuIGVhc3kgdG8gZGVwbG95IGFuZCBvcGVyYXRlIHN0YW5k YXJkIHNvbHV0aW9uIG9mZmVyaW5nIEJlc3QgRWZmb3J0IGJhc2VkIHRyYW5zcG9ydCBiZWluZyBU Q1AgZnJpZW5kbHkgYW5kIGF0IHRoZSBzYW1lIHRpbWUgY29uZ2VzdGlvbiBmcmVlIGZvciBvdGhl ciBmbG93cyBhdCBhIEJORyBmb3IgdHJhZmZpYyBpbiBhY2Nlc3MgZGlyZWN0aW9uIChhbmQgZm9y IHNpbWlsYXIgZGV2aWNlcyBpbiBvdGhlciBhcmNoaXRlY3R1cmVzIG9mIGNvdXJzZSkuIA0KPiAN Cj4gRmlnaHRpbmcgYnVmZmVyYmxvYXQgaW4gdGhlIHVwc3RyZWFtIGRpcmVjdGlvbiB0aGUgd2F5 IHlvdSBkZXNjcmliZSBpdCBkb2Vzbid0IGNvbnN0cnVjdCBhIGNoYWluIG9mIGxpbmtzIHdoaWNo IGFyZSBjb25zZWN1dGl2ZWx5IG5hcnJvd2VyIHRoYW4gdGhlIGJvdHRsZW5lY2sgbGluaywgSSB0 aGluay4NCg0KCVllcywgZnVsbHkgYWdyZWVkLCB0aGF0IHNhaWQsIGFuZCBJU1BzIENQRSBzaG91 bGQgaW1wbGVtZW50IGFuIEFRTSB0byByZWFsbHkgc29sdmUgdGhlIGxhdGVuY3kgaXNzdWVzIGZv ciBlbmQtdXNlcnMuIFRoZSBpbml0aWFsIEw0UyBwYXBlciBzaWRlLXN0ZXBwZWQgdGhhdCByZXF1 aXJlbWVudCBieSBtYWtpbmcgc3VyZSB0aGUgdXBsaW5rcyB3ZXJlIG5vdCBzYXR1cmF0ZWQgZHVy aW5nIHRoZSB0ZXN0LCBhbmQgc3RhdGUgdGhhdCB0aGF0IG5lZWRzIGEgcmVhbCBzb2x1dGlvbiBm b3IgcHJvcGVyIHJvbGwtb3V0LiBJbiB0aGVvcnkgdGhlIElTUCBjb3VsZCBkbyB0aGUgdXBsaW5r IHNoYXBpbmcgb24gaXRzIGVuZCAoYW5kIHRvIGNvbnN0cmFpbiB1c2VycyB0byB0aGVpciBjb250 cmFjdGVkIHJhdGVzLCBJU1BzIGRvIHRoaXMgYWxyZWFkeSkgYnV0IGFzIGluIHRoZSBkb3duc3Ry ZWFtIGNhc2UsIHJ1bm5pbmcgYW4gQVFNIGluIGZyb250IG9mIGEgYm90dGxlbmVjayBhcyBvcHBv c2VkIHRvIGJlaGluZCBpdCBtYWtlcyBldmVyeXRoaW5nIG11Y2ggZWFzaWVyLiBBbHNvIHdpdGgg dXBsaW5rcyB0eXBpY2FsbHkgPDwgZG93bmxpbmtzLCB0aGUgdHlwaWNhbGx5IHdlYWsgQ1BFIENQ VXMgd2lsbCBzdGlsbCBiZSBhYmxlIHRvIEFRTSB0aGUgdXBsaW5rLCBuaWNlbHkgZGlzdHJpYnV0 aW5nIHRoYXQgY29tcHV0YXRpb24gbG9hZCBhd2F5IGZyb20gdGhlIEJORy9CUkFTIGJpZyBpcm9u IC4uLi4NCg0KDQpCZXN0IFJlZ2FyZHMNCglTZWJhc3RpYW4NCg0KPiANCj4gUmVnYXJkcywNCj4g DQo+IFJ1ZWRpZ2VyDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBO YWNocmljaHQtLS0tLQ0KPiBWb246IFNlYmFzdGlhbiBNb2VsbGVyIDxtb2VsbGVyMEBnbXguZGU+ IA0KPiBHZXNlbmRldDogRnJlaXRhZywgMi4gQXVndXN0IDIwMTkgMTU6MTUNCj4gQW46IEdlaWIs IFLDvGRpZ2VyIDxSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+DQo+IENjOiBKb25hdGhhbiBNb3J0 b24gPGNocm9tYXRpeDk5QGdtYWlsLmNvbT47IHRjcG1AaWV0Zi5vcmc7IEVDTi1TYW5lIDxlY24t c2FuZUBsaXN0cy5idWZmZXJibG9hdC5uZXQ+OyB0c3Z3Z0BpZXRmLm9yZw0KPiBCZXRyZWZmOiBS ZTogW0Vjbi1zYW5lXSBbdHN2d2ddIEVDTiBDRSB0aGF0IHdhcyBFQ1QoMCkgaW5jb3JyZWN0bHkg Y2xhc3NpZmllZCBhcyBMNFMNCj4gDQo+IEhpIFJ1ZWRpZ2VyLA0KPiANCj4gDQo+IA0KPj4gT24g QXVnIDIsIDIwMTksIGF0IDEwOjI5LCA8UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPiA8UnVlZGln ZXIuR2VpYkB0ZWxla29tLmRlPiB3cm90ZToNCj4+IA0KPj4gSGkgSm9uYXRoYW4sDQo+PiANCj4+ IGNvdWxkIHlvdSBwcm92aWRlIGEgcmVhbCB3b3JsZCBleGFtcGxlIG9mIGxpbmtzIHdoaWNoIGFy ZSBjb25zZWN1dGl2ZWx5IG5hcnJvd2VyIHRoYW4gc2VuZGVyIGFjY2VzcyBsaW5rcz8NCj4gDQo+ IAlKdXN0IGFuIGV4YW1wbGUgZnJvbSBhIG5ldHdvcmsgeW91IG1pZ2h0IGJlIGNvbWZvcnRhYmxl IHdpdGgsIGluIERUQUdzIGludGVybmV0IGFjY2VzcyBuZXR3b3JrIHRoZXJlIHR5cGljYWxseSBh cmUgdHJhZmZpYyBsaW1pdGluZyBlbGVtZW50cyBhdCB0aGUgQk5HcyAob3IgYXQgdGhlIEJSQVMg Zm9yIHRoZSBsZWdhY3kgbmV0d29yayksIEkgYW0gbm90IDEwMCUgc3VyZSB3aGV0aGVyIHRoZXNl IGFyZSBpbXBsZW1lbnRlZCBhcyBwb2xpY2VycyBvciBzaGFwZXJzLCBidXQgdGhleSB0ZW5kZWQg dG8gY29tZSB3aXRoID49IDMwMG1zIGJ1ZmZlcmluZy4gU2luY2UgcmVjZW50bHksIHRoZSBCTkcv QlJBUyB0cmFmZmljIHNoYXBlcidzIHVzZSB0aGUgbWVzc2FnZSBmaWVsZCBvZiB0aGUgUFBQb0Ug QXV0aCBBQ0sgdG8gdHJhbnNmZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFRDUC9JUHY0IEdvb2Rw dXQgZW5kdXNlcnMgY2FuIGV4cGVjdCBvbiB0aGVpciBsaW5rIGFzIGEgY29uc2VxdWVuY2Ugb2Yg dGhlIEJORy9CUkFTInMgdHJhZmZpYyBsaW1pdGVyLiBJbiBET0NTSVMgYW5kIEdQT04gbmV0d29y a3MgdGhlIHRyYWZmaWMgc2hhcGVyIHNlZW1zIG1hbmRhdGVkIGJ5IHRoZSBzdGFuZGFyZHMsIGlu IERTTCBuZXR3b3JrcyBpdCBzZWVtcyBvcHRpb25hbCAoYnV0IHRoZXJlIGV2ZW4gd2l0aG91dCBh IHNoYXBlciB0aGUgbGltaXRlZCBiYW5kd2lkdGggb2YgdGhlIGFjY2VzcyBsaW5rIHdvdWxkIGJl IGEgbmF0dXJhbCB0cmFmZmljIGNob2tlIHBvaW50KS4NCj4gRnJpdHpib3ggaG9tZSByb3V0ZXIn cyBub3cgdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYXV0b21hdGljYWxseSBzZXQgZWdyZXNzIChh bmQgSSBiZWxpZXZlIGFsc28pIGluZ3Jlc3MgdHJhZmZpYyBzaGFwaW5nIG9uIHRoZSBDUEUgdG8g cmVkdWNlIHRoZSBidWZmZXJibG9hdCB1c2VycyBleHBlcmllbmNlLiBJIGhhdmUgbm8gaW5zaWdo dCBpbiB3aGF0IFRlbGVrb20ncyBvd24gU3BlZWRwb3J0IHJvdXRlcnMgZG8sIGJ1dCBJIHdvdWxk IG5vdCBiZSBzdXJwcmlzZWQgaWYgdGhleSB3b3VsZCBkbyB0aGUgc2FtZSAoYXQgbGVhc3QgZm9y IGVncmVzcykuIA0KPiAJQXMgSm9uYXRoYW4gYW5kIERhdmUgbWVudGlvbmVkLCBxdWl0ZSBhIG51 bWJlciBvZiBlbmQtdXNlcnMsIGVzcGVjaWFsbHkgdGhlIGxhdGVuY3kgc2Vuc2l0aXZlIG9uZXMs IGVtcGxveSB0aGVpciBvd24gaW5ncmVzcyBhbmQgZWdyZXNzIHRyYWZmaWMgc2hhcGVycyBhdCB0 aGVpciBob21lIHJvdXRlcnMgYXMgdGhlIDMwMG1zIGJ1ZmZlcnMgb2YgdGhlIEJORydzIGFyZSBq dXN0IG5vdCBhY2NlcHRhYmxlIGZvciBhbnkgcmVhbC10aW1pc2ggdXNlcyAoVm9JUCwgb24tbGlu ZSB0d2l0Y2ggZ2FtaW5nLCBldmVuIGZvciBpbnRlcmFjdGl2ZSBzZXNzaW9ucyBsaWtlIHNzaCAz MDBtcyBkZWxheSBhcmUgdW5kZXNpcmFibGUpLiBFLmcuIHBlcnNvbmFsbHksIEkgdXNlIGFuIE9w ZW5XcnQgcm91dGVyIHdpdGggYW4gRlEgQVFNIGZvciBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcyAo YmFzZWQgb24gSm9uYXRoYW4ncyBleGNlbGxlbnQgY2FrZSBxZGlzYykgdGhhdCBhbGxvd3MgYSBm YW1pbHkgb2YgNSB0byBoYXBwaWx5IHNoYXJlIGEgNTAvMTAgY29ubmVjdGlvbiBiZXR3ZWVuIHZp ZGVvIHN0cmVhbWluZyBhbmQgaW50ZXJhY3RpdmUgdXNlIHdpdGggdmVyeSBsaXR0bGUgaW50ZXJm ZXJlbmNlIGJldHdlZW4gdGhlIHVzZXJzLCB0aGUgc2FtZSBsaW5rIHdpdGggb3V0IHRoZSBGUS1B UU0gYWN0aXZlIG1ha2VzIGludGVyYWN0aXZlIGFwcGxpY2F0aW9ucyBmZWVsIGxpa2Ugc3VibWVy Z2VkIGluIG1vbGFzc2VzIG9uY2UgdGhlIGxpbmsgZ2V0cyBzYXR1cmF0ZWQuLi4NCj4gCUFzIGZh ciBhcyBJIGNhbiB0ZWxsIHRoZXJlIGlzIGEgbnVtYmVyIG9mIGRpZmZlcmVudCBzb2x1dGlvbnMg dGhhdCBvZmZlciBob21lLXJvdXRlciBiYXNlZCBiaS1kaXJlY3Rpb25hbCB0cmFmZmljIHNoYXBp bmcgdG8gc29sdmUgYnVmZmVyYmxvYXQiIGZyb20gaG9tZSAod2VsbCwgbm90IGZ1bGx5IHNvbHZl IGl0LCBidXQgcmVtZWR5IGl0cyBjb25zZXF1ZW5jZXMpLCBpbmNsdWRpbmcgY29tbWVyY2lhbCBv cHRpb25zIGxpa2UgZXZlbnJvdXRlJ3MgaXFyb3V0ZXIsIGFuZCBvcGVuLXNvdXJjZSBvcHRpb25z IGxpa2UgT3BlbldydCAod2l0aCBzcW0tc2NyaXB0cyBhcyBzaGFwZXIgcGFja2V0KS4gDQo+IAlJ dCBpcyBleGFjdGx5IHRoaXMgdXNlIGNhc2UgYW5kIHRoZSBmYWN0IHRoYXQgbGF0ZW5jeS1zZW5z aXRpdmUgdXNlcnMgb2Z0ZW4gb3B0IGZvciB0aGlzIHNvbHV0aW9uLCB0aGF0IGNhdXNlcyBtZSB0 byBhc2sgdGhlIEw0UyBjcm93ZCB0byBhY3R1YWxseSBtZWFzdXJlIHRoZSBlZmZlY3Qgb2YgTDRT IG9uIFJGQzMxNjgtRlEtQVFNcyBpbiB0aGUgZXhhY3QgY29uZmlndXJhdGlvbiBpdCBpcyBhY3R1 YWxseSB1c2VkIHRvZGF5LCB0byByZW1lZHkgdGhlIHNhbWUgaXNzdWUgTDRTIHdhbnRzIHRvIHRh Y2tsZS4NCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiAJU2ViYXN0aWFuDQo+IA0KPiANCj4+IA0KPj4g SSBjb3VsZCBmaWd1cmUgb3V0IGEgc21hbGwgY2FtcHVzIG5ldHdvcmsgd2hpY2ggaGFzIGEgYm90 dGxlbmVjayBhdCB0aGUgSW50ZXJuZXQgYWNjZXNzIGFuZCBhIHNlY29uZCBvbmUgY29ubmVjdGlu ZyB0aGUgdGVybWluYWwgZXF1aXBtZW50LiBCdXQgaW4gYSBzbWFsbCBjYW1wdXMgbmV0d29yaywg dGhlIGluZGl2aWR1YWwgdGVybWluYWwgY291bGQgdmVyeSB3ZWxsIGhhdmUgYSBoaWdoZXIgTEFO IGFjY2VzcyBiYW5kd2lkdGgsIHRoYW4gdGhlIGNhbXB1cyAtIEludGVybmV0IGNvbm5lY3Rpb24g KGFuZCB0aGVuIHRoZXJlJ3Mgb25seSBvbmUgYm90dGxlbmVjayBhZ2FpbikuDQo+PiANCj4+IFRo ZXJlIG1heSBiZSBhIHRyYWRlb2ZmIGJldHdlZW4gc2ltcGxpY2l0eSBhbmQgZ2VuZXJhbCBhcHBs aWNhYmlsaXR5LiBBd2FyZW5lc3Mgb2YgdGhhdCB0cmFkZW9mZiBpcyBpbXBvcnRhbnQuIFRvIG1l LCBzaW1wbGljaXR5IGlzIHRoZSBkZXNpZ24gYWltLiANCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0K Pj4gUnVlZGlnZXIgDQo+PiANCj4+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0N Cj4+IFZvbjogdHN2d2cgPHRzdndnLWJvdW5jZXNAaWV0Zi5vcmc+IEltIEF1ZnRyYWcgdm9uIEpv bmF0aGFuIE1vcnRvbg0KPj4gR2VzZW5kZXQ6IERpZW5zdGFnLCA5LiBKdWxpIDIwMTkgMTc6NDEN Cj4+IEFuOiBCb2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD4NCj4+IENjOiB0Y3BtIElF VEYgbGlzdCA8dGNwbUBpZXRmLm9yZz47IGVjbi1zYW5lQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldDsg dHN2d2cgSUVURiBsaXN0IDx0c3Z3Z0BpZXRmLm9yZz4NCj4+IEJldHJlZmY6IFJlOiBbdHN2d2dd IFtFY24tc2FuZV0gRUNOIENFIHRoYXQgd2FzIEVDVCgwKSBpbmNvcnJlY3RseSBjbGFzc2lmaWVk IGFzIEw0Uw0KPj4gDQo+Pj4gT24gMTMgSnVuLCAyMDE5LCBhdCA3OjQ4IHBtLCBCb2IgQnJpc2Nv ZSA8aWV0ZkBib2JicmlzY29lLm5ldD4gd3JvdGU6DQo+Pj4gDQo+Pj4gICAgIDEuICBJdCBpcyBx dWl0ZSB1bnVzdWFsIHRvIGV4cGVyaWVuY2UgcXVldWluZyBhdCBtb3JlIHRoYW4gb25lDQo+Pj4g ICAgICAgICBib3R0bGVuZWNrIG9uIHRoZSBzYW1lIHBhdGggKHRoZSBhdmFpbGFibGUgY2FwYWNp dGllcyBoYXZlIHRvDQo+Pj4gICAgICAgICBiZSBpZGVudGljYWwpLg0KPj4gDQo+PiBGb2xsb3dp bmcgdXAgb24gRGF2aWQgQmxhY2sncyBjb21tZW50cywgSSdkIGp1c3QgbGlrZSB0byBub3RlIHRo YXQgdGhlIGFib3ZlIGlzIG5vdCB0aGUgdHJ1ZSBjcml0ZXJpb24gZm9yIG11bHRpcGxlIHNlcXVl bnRpYWwgcXVldWluZy4NCj4+IA0KPj4gTWFueSBleGlzdGluZyBUQ1Agc2VuZGVycyBhcmUgdW5w YWNlZCAoYXNpZGUgZnJvbSBhY2stY2xvY2tpbmcpLCBpbmNsdWRpbmcgRnJlZUJTRCwgcmVzdWx0 aW5nIGluIHBvdGVudGlhbGx5IGxhcmdlIGxpbmUtcmF0ZSBidXJzdHMgYXQgdGhlIG9yaWdpbiAt IGVzcGVjaWFsbHkgZHVyaW5nIHNsb3ctc3RhcnQuICBFdmVuIGluIGNvbmdlc3Rpb24gYXZvaWRh bmNlLCBlYWNoIGFjayB3aWxsIHRyaWdnZXIgYSBjbG9zZWx5IHNwYWNlZCBwYWNrZXQgcGFpciAo b3Igc29tZXRpbWVzIGEgdHJpcGxldCkuICBJdCBpcyB0aGVuIGVhc3kgdG8gaW1hZ2luZSwgb3Ig dG8gYnVpbGQgYSB0ZXN0YmVkIGNvbnRhaW5pbmcsIGFuIGFyYml0cmFyaWx5IGxvbmcgc2VxdWVu Y2Ugb2YgY29uc2VjdXRpdmVseSBuYXJyb3dlciBsaW5rczsgdXBvbiBlbnRlcmluZyBlYWNoLCB0 aGUgYnVyc3Qgb2YgcGFja2V0cyB3aWxsIGJyaWVmbHkgY29sbGVjdCBpbiBhIHF1ZXVlIGFuZCB0 aGVuIGJlIHBhY2VkIG91dCBhdCB0aGUgbmV3IHJhdGUuDQo+PiANCj4+IFRDUCBwYWNpbmcgZG9l cyBsYXJnZWx5IGVsaW1pbmF0ZSB0aGVzZSBidXJzdHMgd2hlbiBpbXBsZW1lbnRlZCBjb3JyZWN0 bHkuICBIb3dldmVyLCBMaW51eCcgcGFjaW5nIGFuZCBJVyBpcyBzcGVjaWZpY2FsbHkgKGFuZCBh cHBhcmVudGx5IGRlbGliZXJhdGVseSkgc2V0IHVwIHRvIGlzc3VlIGEgMTAtcGFja2V0IGxpbmUt cmF0ZSBidXJzdCBvbiBzdGFydHVwLiAgVGhpcyBlZmZlY3QgaGFzIHNob3duIHVwIGluIFNDRSB0 ZXN0cyB0byB0aGUgcG9pbnQgd2hlcmUgd2UgaGFkIHRvIHBhdGNoIHRoaXMgYmVoYXZpb3VyIG91 dCBvZiB0aGUgc2VuZGluZyBrZXJuZWwgdG8gcHJldmVudCBhbiBpbnN0YW50IGV4aXQgZnJvbSBz bG93LXN0YXJ0Lg0KPj4gDQo+PiAtIEpvbmF0aGFuIE1vcnRvbg0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRWNuLXNhbmUgbWFpbGlu ZyBsaXN0DQo+PiBFY24tc2FuZUBsaXN0cy5idWZmZXJibG9hdC5uZXQNCj4+IGh0dHBzOi8vbGlz dHMuYnVmZmVyYmxvYXQubmV0L2xpc3RpbmZvL2Vjbi1zYW5lDQo+IA0KDQo= From nobody Mon Aug 5 05:17:14 2019 Return-Path: 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 1FACD1201E3; Mon, 5 Aug 2019 05:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 WjyzheC-YPFa; Mon, 5 Aug 2019 05:16:59 -0700 (PDT) Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 74E611201DE; Mon, 5 Aug 2019 05:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1565007417; x=1596543417; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1p6NBs9VlTWdj9etn3VEV2k3YHMRtK/2N+TK3g6b3gY=; b=ZSjDotI3Nh2EV/wylyk+YjFJniO5pg5cKJWf++0I+vIUoibY+Hhg+e0f ab3/EOyNhY/nkpfelLtE42Wv+ly3f2lwwZYUAXhXvO07lNhhkF+wX2YV0 5aXWyI6F2Sq9vcDqkn60pa/+ZfguO/J38MgpsoU2GLU291YmWiu6tDW+T iBIcPBUD7VHrke0wFmWqbjeqVyCjs6mx8pF62Ul5sAMjqUMmmJY8M35sr 3QssS1Kkj7k2ui9osGM9k9XrHbFLP0w2kRDVoaFANZbsXYsM4WETqeK2h NI5Q548islDj5cqDUhbJSs8fJnRlMr+yF/MlV6w9iFI9ewVurvYqyX8nW w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 14:16:54 +0200 X-IronPort-AV: E=Sophos;i="5.64,349,1559512800"; d="scan'208";a="473401192" X-MGA-submission: =?us-ascii?q?MDHMV5cBsQt9ixhT7iyFOImqe0l1nwqEyAPAC7?= =?us-ascii?q?tRa7eTZ0zbCQ12mZJ5uJK6j1fDkNdZ5X94IyUzSO9HFXFtS++NCRqcuQ?= =?us-ascii?q?SISZy5tee3WBDJl4TGES0259sVpHjb+hOoCLi+xkNMYCYhnT7Z06db85?= =?us-ascii?q?WS0whcOUMhmNqU7QtDqPVf4w=3D=3D?= Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Aug 2019 14:16:49 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 14:16:38 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 14:16:38 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.16) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 14:16:37 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB1247.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 12:16:37 +0000 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 12:16:37 +0000 From: To: CC: , , Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTwgAAbvwCABKfngIAAI2aAgAABO+A= Date: Mon, 5 Aug 2019 12:16:37 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@gmail.com> In-Reply-To: <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 810bba89-af6e-4f1c-87fb-08d7199ec3cb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB1247; x-ms-traffictypediagnostic: LEXPR01MB1247: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(366004)(136003)(189003)(199004)(5660300002)(186003)(26005)(8936002)(8676002)(486006)(6916009)(53936002)(52396003)(305945005)(508600001)(7736002)(3846002)(66946007)(6116002)(446003)(11346002)(66446008)(66476007)(66556008)(64756008)(9686003)(476003)(54906003)(76116006)(6306002)(55016002)(33656002)(2906002)(4326008)(7696005)(256004)(14454004)(14444005)(71190400001)(45776006)(76176011)(102836004)(966005)(66066001)(86362001)(66574012)(81166006)(71200400001)(81156014)(1411001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB1247; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: H5HJeX2IabJzpN5DMxaAo3k8DHXi51HvSGgKbUVgcK25yK3eEOFs/xGaNmORlTGG5UHqjor8jaDfjbjqtUE5Ab+eD0YQ6M1FkLIOBPF/j68t8Xr+HBDpQdBtFbJ6PzjI7qGYnYo6VdoRbERzzGl7HcSIh7yhfjSuMiboQNefT4oWwYEU4PuMvwingoXTtmWkFDhtNbs9viNUD8bPQsERX6vJKAvXFGruMsSw+pDi7w/egJWAybmDL0TtkENHUxyQgB3A7ZCs7TlV3zP5tVPqdpqBwXIVvYff+gEyI8vSPPxfRJ5s7zjTW8Js5NU47kr067ENAC3WOeyPX/L263Fm928Fgbtu7VKNr7pEnu3rlOlVTel3fHuiGyAy7rWPDMvB24t3owPizzpanQSxwkqu4tFFbLyth1jXACSQLBgx2CQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 810bba89-af6e-4f1c-87fb-08d7199ec3cb X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 12:16:37.5847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB1247 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 12:17:12 -0000 As I said, no corner-case engineering. On my vacation site abroad, Netflix = worked as well as it does at home. Germany is often criticised as a laggard= in developing a competitive broadband access market. My interest in IETF w= ork being set up to work around commercial problems between ISPs and ISPs o= r CDNs in a rich country like the UK or US is low.=20 If your technical standardization activities help to make using the Interne= t more convenient in African countries without raising extra cost or requir= ing extra skills, I'm sure that's a fair market. I know that these countrie= s are struggling to improve the services operated in their networks. Condit= ions there (and some Asian countries) differ strongly from those in many ot= her parts of the world. It might be a good thing to clarify under which scenarios the problem solut= ions you work on create the most significant benefit. In the market that I am aware of, there's a single regular bottleneck, whic= h is the consumer access or terminal. -----Urspr=FCngliche Nachricht----- Von: Jonathan Morton =20 Gesendet: Montag, 5. August 2019 13:00 An: Geib, R=FCdiger Cc: tcpm@ietf.org; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classifi= ed as L4S > [JM] A progressive narrowing of effective link capacity is very common in= consumer Internet access. Theoretically you can set up a chain of almost = unlimited length of consecutively narrowing bottlenecks, such that a line-r= ate burst injected at the wide end will experience queuing at every interme= diate node. In practice you can expect typically three or more potentially= narrowing points: >=20 > [RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , fi= rst two sentences. That's a sound starting point, and I don't think much ha= s changed since 2005.=20 As I said, that reference is *usually* true for *responsible* ISPs. Not al= l ISPs, however, are responsible vis a vis their subscribers, as opposed to= their shareholders. There have been some high-profile incidents of *delib= erately* inadequate peering arrangements in the USA (often involving Netfli= x vs major cable networks, for example), and consumer ISPs in the UK *typic= ally* have diurnal cycles of general congestion due to under-investment in = the high-speed segments of their network. To say nothing of what goes on in Asia Minor and Africa, where demand routi= nely far outstrips supply. In those areas, solutions to make the best use = of limited capacity would doubtless be welcomed. > [RG] About the bursts to expect, it's probably worth noting that today's = most popular application generating traffic bursts is watching video clips = streamed over the Internet. Viewers dislike the movies to stall. My impress= ion is, all major CDNs are aware of that and try their best to avoid this s= ituation. In particular, I don't expect streaming bursts to overwhelm acces= s link shaper buffers by design. And that, I think, limits burst sizes of t= he majority of traffic. In my personal experience with YouTube, to pick a major video streaming ser= vice not-at-all at random, the bursts last several seconds and are essentia= lly ack-clocked. It's just a high/low watermark system in the receiving cl= ient's buffer; when it's full, it tells the server to stop sending, and aft= er it drains a bit it tells the server to start again. When traffic is flo= wing, it's no different from any other bulk flow (aside from the use of BBR= instead of CUBIC or Reno) and can be managed in the same way. The timescale I'm talking about, on the other hand, is sub-RTT. Packet int= ervals may be counted in microseconds at origin, then gradually spaced out = into the millisecond range as they traverse the successive bottlenecks en r= oute. As I mentioned, there are several circumstances when today's servers= emit line-rate bursts of traffic; these can also result from aggregation i= n certain link types (particularly wifi), and hardware offload engines whic= h try to treat multiple physical packets from the same flow as one. This t= hen results in transient queuing delays as the next bottleneck spaces them = out again. When several such bursts coincide at a single bottleneck, moreover, the que= uing required to accommodate them may be as much as their sum. This "incas= t effect" is particularly relevant in datacentres, which routinely produce = synchronised bursts of traffic as responses to distributed queries, but can= also occur in ordinary web traffic when multiple servers are involved in a= single page load. IW10 does not mean you only need 10 packets of buffer s= pace, and many CDNs are in fact using even larger IWs as well. These effects really do exist; we have measured them in the real world, rep= roduced them in lab conditions, and designed qdiscs to accommodate them as = cleanly as possible. The question is to what extent they are relevant to t= he design of a particular technology or deployment; some will be much more = sensitive than others. The only way to be sure of the answer is to be awar= e, and do the appropriate maths. > [RG] Other people use their equipment to communicate and play games These are examples of traffic that would be sensitive to the delay from tra= nsient queuing caused by other traffic. The most robust answer here is to = implement FQ at each such queue. Other solutions may also exist. > Any solution for Best Effort service which is TCP friendly and support sc= ommunication expecting no congestion at the same time should be easy to dep= loy and come with obvious benefits.=20 Well, obviously. Although not everyone remembers this at design time. > [RG] I found Sebastian's response sound. I think, there are people intere= sted in avoiding congestion at their access. > the access link is the bottleneck, that's what's to be expected. It is typically *a* bottleneck, but there can be more than one from the vie= wpoint of a line-rate burst. > [RG] I'd like to repeat again what's important to me: no corner case engi= neering. Is there something to be added to Sebastian's scenario? He makes an essentially similar point to mine, from a different perspective= . Hopefully the additional context provided above is enlightening. - Jonathan Morton From nobody Mon Aug 5 06:47:54 2019 Return-Path: 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 C74131201F3; Mon, 5 Aug 2019 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 hq2wHVhz_js0; Mon, 5 Aug 2019 06:47:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B863A120227; Mon, 5 Aug 2019 06:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1565012856; bh=o6t7BgCdCnSYF4kly+Z/yNZ/qFTJOSD4YiASeDYUoVQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=c9u8TdK3/WBI4aTkfbLd6rh1A4ZMVlbu/LjxEEjfwXlG5cNDREF+nBfBols2mRjP2 dAiSV5u5sr7TghaT/X0ylJ3PSM18wpvxnJD4ixMhi6gIftzQFE3A8NT9HRCsXEH8Hp g4fXpRcQgxV1LKsYe24sDPXmi2svsdvRPwNYDyY0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MO77c-1i07Vk29rg-005bjZ; Mon, 05 Aug 2019 15:47:36 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 5 Aug 2019 15:47:34 +0200 Cc: tcpm@ietf.org, ECN-Sane , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:9L3mStFB73YgVB16QIgBohXJ50AsLLsJgxRiCxQ4DsO0n5Vlchh +IL5KSffv+4yCfpM86Vt5mdSwjSYgA3GlydqrXa7liDBZ5uWF/u8dhTVEHtnv+hrYfsmbcr p+Hbj6VGCRo+Q6FUJDwuexN18Tf59Ghlx01mXXQ95YTWRLnQPG0grVwLTAccKN5A8/ZVZzT g8oX8K92H9iDnffIq+Xbw== X-UI-Out-Filterresults: notjunk:1;V03:K0:hbsuy9QPSOk=:LaVYq5UK5FfrF46OSJUU/r oxObUNlh/rqbetp/CQmXImgJDbTrwGwvFTfGEYci3bFcXfQJI1GgDxJNlLO0pBSZzkil0cmOz T5LL8WakwGFh7DEWIvnFFhwVsB1+CrkndrmO/+FZqlqlCD5zaW9l0Lz2pLPJBeeVsL4eArrHg dYD/rRXBLM7fhUQDQvazEw45jgFxDY9jCKW5m4IP+HY143ziPDqM0pfgv6QknEkUz+cFqm9Qw 8k6prX7TCkaHC4q6IE5h08oMZRHC7f1zyVXJRVfMPlh1pSG9/cu+DAIuC9J20J86vQ0K+yDH5 KkkdygQXlhTDkhLNINxCR7VV/1Cypjpf34/B6MUF1UKf6E12k3oCGq3jl494lqRW0/f3QCd+z GkeyV38YdVgb+eiRWr0jZFnZDRCNA6aZRaLbc9TMCzhxTHiXcPiAdLsbRHyGpjESZd/5gSk8f ZPJyAAlSH+3hhea7SN7/EInNOhwe+SXN8o4T6DfIThj8Wzc/QjkldeAnBeYHYPESRBhM9nf0j o5mUVPMn4RRioN21fwf9p6PiYbhhupKNL52MOlAWZFa1JEi64Lz/2RR3IK/023nSSPLoLCZAR kJK4/o1GplrhhuG5QjY/uCPyhtbdItPYGMG75Y3uSZffNhwVt3sjgKOBEb99nSPT9W8BYg+t9 OavSd1yyntW0pFfkOxEwf5KxdW1+3nOBB6bE/KPmb/UFPXaJAu9eEFzjowBRDlOxJS2pVE2bK CI67Vz/gem2E9P71OcxTgzW2u+Th4w3jyrvg5c32cxe8iEvJsb3pJwR+zEQZ7UuoJ0lh7gOb9 AnQJtb1mtIr8NoJPHKCFn35Vt1HyD8XJn3OGNbw0+zI8O//dpAoRK/RbGVryX8kLmJP5cyeHd JpAsbQheSAFcvwIBawH6rgBgkZCwJb+sxayZSt/B554soi8lO00MSkzLFKYRzG/mS8DhwbrEB rmmQ8xcQYYv+/xYrleAZ45gBRzKXHD0MaKg8dmop6+vrSE25HTronrYtWzno9KkT0SD0L/9sR vjoCZRCYoiPIsV7T/SYXCVtiZszfmpoxdxjXl546nuh7twY51fhDS7XAy9Berdo/g2P1cBl/X oYFfLDq2Kilstk593Pb7XBLSeOjhAEs0X9YU3Izes9gDXLVh+AyfnRvzB6HKuVDmZr46xmy7Q UU5NY= Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 13:47:45 -0000 Hello Ruediger, > On Aug 5, 2019, at 13:47, = wrote: >=20 > Hi Sebastian, >=20 > thanks. Three more remarks: >=20 > I'm happy for any AQM design which comes at low implementation cost = and allows me to add value to network operation (be it saving cost, be = it enabling value added services). And I think the representatives of = other operators are so too. Yes, that is my premise too. The only cost saving opportunity I = can see in both proposals would be if they allowed to run a fully = saturated network without the adverse effects on latency and loss. Value = added services, sure for the few users sensitive to latency under load. = Maybe with the PR the 5G roll-out is getting in regards to low-latency = it might be possible to convince more consumers that this is actually = valuable? >=20 > For most consumers, streaming is the most bandwidth hungry = application. I have no statistical numbers on this topic, but on the list of = things that cause issues for latency sensitive home networks the = following items come up repeatedly: A) Streaming in (Youtube, Netflix, Amazon, ...)=20 B) Streamin out (aka twitch and friends) C) File sharing with bittorrent (a slight challenge for FQ-AQMs die to = lots of parallel flows and a misdesigned back-off mechanism (react to = 100ms induced latency under load?)) D) OS updates, (especially windows update when lveraging P2P technolgy = from a close by CDN was/is notorious for being a tad too aggressive) How these stack up proportionally to each other, I have no clue. = Typically the reports are that perceived interactivity in FPS games goes = down the drain if and combination of A-D are concurrently active. > I think someone now working for Google published research, that at the = time when Internet access bandwidth no longer had an impact on the = streaming quality, consumers started to lose interest in "access speed" = as an important measure of quality of their Internet access. I think it = takes a while until John Doe requires a n*100 Mbit/s Internet access, = because any access below 100 Mbit/s causes congestion for the services = consumed by John.=20 That is a good question, as far as I see it, ISPs in Germany = still seem to leverage access-rates as their main attraction (giga this = and giga that), even though as you note higher rates have diminishing = returns for most use-cases. >=20 > I see many people around me conveniently use their smartphone to = access the Internet. So do I, but I realize how laggy this feels even for "simple" = browsing duty (but I accept that for the ease of use and immediacy)... = And it is not guaranteed that the smartphone uses the mobile network, it = might just as well use wifi. But the latency/bottleneck issue also = exists with smartphones, where the variable bandwidth nature of the = radios and the opaqueness of 2-4G modems makes things even less = enjoyable than on fixed networks (I see multi second stalls when = browsing on a phone, versus 300ms on the fixed line without my AQM. > A handheld display likely requires less bandwidth for an acceptable = display quality, than a large screen. For browsing, I am not sure that is a real point, given that = smartphone display resolution crossed from high to ridiculous some years = ago (at least without glasses). > That doesn't say, the latter disappear. But maybe only one or two of = them need to be served per consumer access. That will work with 100 = Mbit/s or less for a while I agree, I run a family of 5 on a 50/10 link including = concurrent streaming (in SD) and thanks to employing a competent FQ-AQM = on my router (ingress & egress) this works quite well even with = interactive sessions. But without that AQM system the link feels = noticeably worse... (and this is the reason why I want to see data, that = L4S senders will not invalidate the effectiveness of my setup) Best Regards Sebastian > (other bandwidth hungry applications will arrive some day; I prefer = the copper access lines in the ground to be replaced by fiber ones) >=20 > Regards, Ruediger >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Sebastian Moeller =20 > Gesendet: Montag, 5. August 2019 13:00 > An: Geib, R=C3=BCdiger > Cc: tcpm@ietf.org; ECN-Sane ; = tsvwg@ietf.org > Betreff: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly = classified as L4S >=20 > Hi Ruediger, >=20 >=20 >> On Aug 5, 2019, at 09:26, = wrote: >>=20 >> Hi Sebastian, >>=20 >> the access link is the bottleneck, that's what's to be expected. >=20 > Mostly, then again there are situations with 1Gbps Plans where = it is not the actual access link, but rather the CPEs Gigabit ethernet = LAN ports that are the true bottleneck, but that does not substantially = change the issue, it is still the upstream shaper/policer that needs to = be worked around. >=20 >> As far as I know, in the operator world shapers here by and large = removed policers. >=20 > Good to know, shapers are somewhat nicer to user traffic than = hard policers, at least that is my interpretation. >=20 >>=20 >> A consecutive chain of narrower links results, if the Home Gateway = runs with an additional ingress or egress shaper operating below the = access bandwidth, if I get you right.=20 >=20 > Yes, as you state below, this only is true for the ingress = direction, egress shaping works reliably and is typically not suffering = from this. That said, if the egress link bandwidth is larger than a = servers connection this issue can appear also for the egress direction. = For example overly hot peering/transit links can cause downstream = bottlenecks considerably narrower than the internet access link's upload = direction, but that, while unfortunate, is not at the core of my issue. >=20 >>=20 >> I understand that you aren't interested in having 300ms buffer delay = and may be some jitter for a phone conversation using best effort = transport. >=20 > +1 >=20 >> A main driver for changes in consumer IP access features in Germany = are publications of journals and regulators comparing IP access = performance of different providers. >=20 > Good to know, >=20 >> Should one provider have an advantage over the others by deploying a = solution as you (and Bob's team) work on, it likely will be generally = deployed. >=20 > I do not believe that these mechanisms are actually in play in = the German market, as an example for roughly a decade the DOCSIS-ISPs = offer higher bandwidth for same or less money than the incumbent telco = and yet only managed to get 30% of the customers of their ~75% of = possible customers, so only 75*0.3 =3D 22.5 % market share, with the = incumbent only reaching 250/40 for the masses while the DOCSIS ISPs = offer 1000/50. And unlike latency, bandwidth (or rather rate) is the = number that consumers understand intuitively. > If anything will expedite the roll-out of L4S style AQMs it is = the capability to use those to implement the "special services" that the = EU net neutrality regulation explicitly allows, as that is a product = that can be actually sold to customers, but I might be too pessimistic = here. >=20 >>=20 >> As far as I can see, latency aware consumers still are a minority and = gamers seem to be a big group belonging here. Interest in well = performing gaming seems to be growing, I guess (for me at least it's an = impression rather than a clear trend). >=20 > Put that way, I see a way for ISPs to distinguish themselves = from the rest by being gaming friendly, but unless this results in = gamers paying more I fail to see the business case that management = probably needs before green-lighting the funds required to implement = this. This is where cablelabs approach to mandate this in the specs is = brilliant.=20 >=20 >>=20 >> I'd personally prefer an easy to deploy and operate standard solution = offering Best Effort based transport being TCP friendly and at the same = time congestion free for other flows at a BNG for traffic in access = direction (and for similar devices in other architectures of course).=20 >>=20 >> Fighting bufferbloat in the upstream direction the way you describe = it doesn't construct a chain of links which are consecutively narrower = than the bottleneck link, I think. >=20 > Yes, fully agreed, that said, and ISPs CPE should implement an = AQM to really solve the latency issues for end-users. The initial L4S = paper side-stepped that requirement by making sure the uplinks were not = saturated during the test, and state that that needs a real solution for = proper roll-out. In theory the ISP could do the uplink shaping on its = end (and to constrain users to their contracted rates, ISPs do this = already) but as in the downstream case, running an AQM in front of a = bottleneck as opposed to behind it makes everything much easier. Also = with uplinks typically << downlinks, the typically weak CPE CPUs will = still be able to AQM the uplink, nicely distributing that computation = load away from the BNG/BRAS big iron .... >=20 >=20 > Best Regards > Sebastian >=20 >>=20 >> Regards, >>=20 >> Ruediger >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Sebastian Moeller =20 >> Gesendet: Freitag, 2. August 2019 15:15 >> An: Geib, R=C3=BCdiger >> Cc: Jonathan Morton ; tcpm@ietf.org; ECN-Sane = ; tsvwg@ietf.org >> Betreff: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly = classified as L4S >>=20 >> Hi Ruediger, >>=20 >>=20 >>=20 >>> On Aug 2, 2019, at 10:29, = wrote: >>>=20 >>> Hi Jonathan, >>>=20 >>> could you provide a real world example of links which are = consecutively narrower than sender access links? >>=20 >> Just an example from a network you might be comfortable with, in = DTAGs internet access network there typically are traffic limiting = elements at the BNGs (or at the BRAS for the legacy network), I am not = 100% sure whether these are implemented as policers or shapers, but they = tended to come with >=3D 300ms buffering. Since recently, the BNG/BRAS = traffic shaper's use the message field of the PPPoE Auth ACK to transfer = information about the TCP/IPv4 Goodput endusers can expect on their link = as a consequence of the BNG/BRAS"s traffic limiter. In DOCSIS and GPON = networks the traffic shaper seems mandated by the standards, in DSL = networks it seems optional (but there even without a shaper the limited = bandwidth of the access link would be a natural traffic choke point). >> Fritzbox home router's now use this information to automatically set = egress (and I believe also) ingress traffic shaping on the CPE to reduce = the bufferbloat users experience. I have no insight in what Telekom's = own Speedport routers do, but I would not be surprised if they would do = the same (at least for egress).=20 >> As Jonathan and Dave mentioned, quite a number of end-users, = especially the latency sensitive ones, employ their own ingress and = egress traffic shapers at their home routers as the 300ms buffers of the = BNG's are just not acceptable for any real-timish uses (VoIP, on-line = twitch gaming, even for interactive sessions like ssh 300ms delay are = undesirable). E.g. personally, I use an OpenWrt router with an FQ AQM = for both ingress and egress (based on Jonathan's excellent cake qdisc) = that allows a family of 5 to happily share a 50/10 connection between = video streaming and interactive use with very little interference = between the users, the same link with out the FQ-AQM active makes = interactive applications feel like submerged in molasses once the link = gets saturated... >> As far as I can tell there is a number of different solutions = that offer home-router based bi-directional traffic shaping to solve = bufferbloat" from home (well, not fully solve it, but remedy its = consequences), including commercial options like evenroute's iqrouter, = and open-source options like OpenWrt (with sqm-scripts as shaper = packet).=20 >> It is exactly this use case and the fact that latency-sensitive = users often opt for this solution, that causes me to ask the L4S crowd = to actually measure the effect of L4S on RFC3168-FQ-AQMs in the exact = configuration it is actually used today, to remedy the same issue L4S = wants to tackle. >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>>=20 >>> I could figure out a small campus network which has a bottleneck at = the Internet access and a second one connecting the terminal equipment. = But in a small campus network, the individual terminal could very well = have a higher LAN access bandwidth, than the campus - Internet = connection (and then there's only one bottleneck again). >>>=20 >>> There may be a tradeoff between simplicity and general = applicability. Awareness of that tradeoff is important. To me, = simplicity is the design aim.=20 >>>=20 >>> Regards, >>>=20 >>> Ruediger=20 >>>=20 >>> -----Urspr=C3=BCngliche Nachricht----- >>> Von: tsvwg Im Auftrag von Jonathan Morton >>> Gesendet: Dienstag, 9. Juli 2019 17:41 >>> An: Bob Briscoe >>> Cc: tcpm IETF list ; ecn-sane@lists.bufferbloat.net; = tsvwg IETF list >>> Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly = classified as L4S >>>=20 >>>> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe = wrote: >>>>=20 >>>> 1. It is quite unusual to experience queuing at more than one >>>> bottleneck on the same path (the available capacities have = to >>>> be identical). >>>=20 >>> Following up on David Black's comments, I'd just like to note that = the above is not the true criterion for multiple sequential queuing. >>>=20 >>> Many existing TCP senders are unpaced (aside from ack-clocking), = including FreeBSD, resulting in potentially large line-rate bursts at = the origin - especially during slow-start. Even in congestion = avoidance, each ack will trigger a closely spaced packet pair (or = sometimes a triplet). It is then easy to imagine, or to build a testbed = containing, an arbitrarily long sequence of consecutively narrower = links; upon entering each, the burst of packets will briefly collect in = a queue and then be paced out at the new rate. >>>=20 >>> TCP pacing does largely eliminate these bursts when implemented = correctly. However, Linux' pacing and IW is specifically (and = apparently deliberately) set up to issue a 10-packet line-rate burst on = startup. This effect has shown up in SCE tests to the point where we = had to patch this behaviour out of the sending kernel to prevent an = instant exit from slow-start. >>>=20 >>> - Jonathan Morton >>>=20 >>> _______________________________________________ >>> Ecn-sane mailing list >>> Ecn-sane@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/ecn-sane >>=20 >=20 From nobody Mon Aug 5 08:56:17 2019 Return-Path: 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 A2584120192; Mon, 5 Aug 2019 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UOe-0T31UnE4; Mon, 5 Aug 2019 08:56:13 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24A4120162; Mon, 5 Aug 2019 08:56:12 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id z28so25499958ljn.4; Mon, 05 Aug 2019 08:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rCj3KubLzhyBvmt3m5sij9iCGDCmzKAOYbcx3Ijy/UE=; b=AuIcf2wP+i/uHF5LelV+I/CBg3bGbnkbEvCMFzmJ6yvBCevWde6CIgC9GV/1bAWbqN BjSMZUiFQphluXFLgS5i68BB/QYpSx1DPOu6n4KDNsT54DCtSAqPUPh2m3k+HTOMPo7V T5YBugS6ZuL/EOdeS6yMQrk+S1MPAGg+na8O4hDM9M5Q3PcoePWAv6OwVapiAnUD0Bh4 AxspfGoVmC/JpGYvPL+7XZt2leN4ivqHY1Ufyi6939CrUpiEGB9jmPeL/r6BCugJvszK IhyqXhffkA1aYI0IkvGLCbKx1m1EBHc8M0eLe8FPNvs52Slsc/brvSxtsEHnn5VBvwmZ iZsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rCj3KubLzhyBvmt3m5sij9iCGDCmzKAOYbcx3Ijy/UE=; b=jKpaSfUDDny24zx7yOqZufOZjN2opm7RID1N4RLhefIW5izMUX8lyp2MmEZPuMnsg8 BYuhJAg6kwVVwpfqAm066ZAAohIDp6P4Jgu085swH7C5kbI8q0l/Cyg7ZLwhxuEoi4Cr pfIiPXP95LgH8DK2ZrCORwPv4nkOD8gPdc4ciAUVa3iMEIoSv5qPFj4NeBKCZZAql/4I Ec6jl8bvNFED+R3JDsQqn/Keu8vY+Av7GNRuGTwSWxpky69s+lthYHzKmp/fPHLORjZY bbUpcODzkZ/Dc0qVNFKJgTWYYAqjc2FvTVGenitKquqNEM+wMmvtIyYe1mzc380hc5se M4/w== X-Gm-Message-State: APjAAAXt35lOzHu25ZqfIDaUaTsKtiHaidjs6dyh2L6v0KZl8y3pWDxM GsHL25zRD3MNhDdnOXm/Sy8= X-Google-Smtp-Source: APXvYqxQ0VHCvqunvmjjNc+SKehKFC0fho1tzHhaRQRnsPvpvdeEd2JYVTER9d3b1NKKdpo9NgDGfA== X-Received: by 2002:a2e:9a13:: with SMTP id o19mr80649345lji.102.1565020570932; Mon, 05 Aug 2019 08:56:10 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-193-nat-p.elisa-mobile.fi. [83.245.237.193]) by smtp.gmail.com with ESMTPSA id g12sm868113lfc.96.2019.08.05.08.55.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 08:56:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Mon, 5 Aug 2019 18:55:36 +0300 Cc: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9D57C401-36FE-4D33-9C04-730BCD4A0122@gmail.com> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@gmail.com> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 15:56:15 -0000 > On 5 Aug, 2019, at 3:16 pm, = wrote: >=20 > As I said, no corner-case engineering. > In the market that I am aware of, there's a single regular bottleneck, = which is the consumer access or terminal. Let me explain one more time: this is *not* a corner case. This is = normal operation on today's Internet; faster core networks feed into = larger numbers of slower edge networks in several stages. If you = haven't noticed it yourself, that's fortunate for you - but that "single = regular bottleneck" is an illusory simplification, which only applies at = relatively long timescales. However, high-fidelity ECN markers *will* notice the difference, and the = resulting congestion signals will appear at the receiver and be fed back = to the sender. That represents an engineering problem for which either = a solution must be devised, or the fact that it is not a problem must be = established. At present, we're still working through the maths to = determine the boundaries of acceptable operation. It's even possible that conventional RFC-3168 AQMs notice it as well, = depending on their design. Codel, for example, is specifically designed = to ignore transient queuing (if it persists for less than one = 'interval', which is taken as an estimate of the RTT) and only act when = a persistent standing queue exists. And it's actually a very important problem when a dumb FIFO bottleneck = is immediately followed by a slightly narrower AQM bottleneck. In this = case the dumb FIFO dilutes the benefit of the AQM significantly, because = the AQM can't see that most of the queue exists in the upstream FIFO, = and even if it could, it cannot apply any intelligence to it. This is = the scenario Sebastian is most concerned about, and for which I have = tried to compensate in Cake with "ingress mode" shaping - because Cake = is specifically designed to be deployed into that topology. Most of the problem would go away if that dumb FIFO were merely replaced = by a simple AQM. This is a straightforward & deployable engineering = solution that has been known for many years, and yet almost nobody has = actually deployed it. I would urge you to do what you can on that = front; judging by your e-mail address, you probably have more influence = where it counts than I do. I repeat: this is normal operation on today's Internet. > If your technical standardization activities help to make using the = Internet more convenient in African countries without raising extra cost = or requiring extra skills, I'm sure that's a fair market. I know that = these countries are struggling to improve the services operated in their = networks. May I refer you to some useful work already done and widely deployed? = This is now the default in most Linux and Apple devices, and is also = available in FreeBSD. It is used by some of the better CPE devices as = part of "Advanced QoS" and "Airtime Fairness", eg. in the Netgear R7000. https://tools.ietf.org/html/rfc8289 https://tools.ietf.org/html/rfc8290 The problem is that it's not deployed at most of the actual bottlenecks, = which mainly exist in ISPs' equipment if the core networks are indeed = overprovisioned. If it was deployed, congestion on the Internet would = be a much easier problem than it is today. And this should be = especially applicable to less-developed areas of the Internet. All it takes is enough ISPs manning up, talking to their hardware = vendors, and saying: "We expect to have congestion = occasionally/frequently (delete as applicable). What AQM does your = hardware support, and how do we turn it on?" And if the answer is = negative, being prepared to take business to a competitor who does. The = technology exists; money talks. In the less developed parts of the world, one could easily jury rig an = AQM router together using a Raspberry Pi and a couple of USB Ethernet = dongles. With the latest Raspberry Pi 4, that would work for up to a = gigabit link; with older models, you can still handle 100Mbps. These = things are cheap enough to practically be disposable, and consume very = little power. If there's demand for that sort of thing, I and my = colleagues could probably arrange for a ready-made SD card image to be = built and published. Or you could standardise on a consumer CPE router and build a no-knobs = mesh-networking image for that. There's a bunch of groups who regularly = attend Battlemesh, who could help with that. Be prepared to change = models every few years as the old ones go out of production. - Jonathan Morton From nobody Tue Aug 6 02:50:12 2019 Return-Path: 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 6DC9712014F; Tue, 6 Aug 2019 02:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 8p0L-Y3UKegM; Tue, 6 Aug 2019 02:50:00 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 BBB9312006F; Tue, 6 Aug 2019 02:49:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0630CB4; Tue, 6 Aug 2019 11:49:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1565084995; bh=y0fuyQrLNRv9gf9yaBA7qN5XkZ6xUEBmw/SvXDZlp7M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=T1EUT0ZMwE5wW0lw0rhkKWBsczEpu2nN8T2S+kFJ3lKzUeUhwNg4YrBFQnK5gcrMP v5xkyrP+GXZ724sTn8JF+6a3NP7VNrtI8Re/Cb8zv+aDUIGjAWZB82T529ks/cHBUc qdCJcfW1TbJLE3hqGLUP9skjAf6y8Cd7WDVyZCHQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0259CB1; Tue, 6 Aug 2019 11:49:55 +0200 (CEST) Date: Tue, 6 Aug 2019 11:49:54 +0200 (CEST) From: Mikael Abrahamsson To: Sebastian Moeller cc: Ruediger.Geib@telekom.de, tcpm@ietf.org, ECN-Sane , tsvwg IETF list In-Reply-To: <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 09:50:03 -0000 On Mon, 5 Aug 2019, Sebastian Moeller wrote: > That is a good question, as far as I see it, ISPs in Germany still > seem to leverage access-rates as their main attraction (giga this and > giga that), even though as you note higher rates have diminishing > returns for most use-cases. It's great marketing. Same way as car manufacturers make prototypes and high end cars ("halo cars") to sell their high-volume mainstream cars. It's brand building. So don't judge the customer interest for actual product sales, by the marketing you see. They might not correlate directly. There is also one more thing that people nowadays do that wasn't directly on your list. Software downloads. Either on game console or on a PC, these downloads can easily be in tens of gigabytes. I personally have a 250/100 connection at home, and download of a large modern game can take 30-60 minutes, because it's 50 GB. I do not know what congestion avoidance algorithms are used, but it seems to me that at least some of these software download services do not actually create congestion. They do very slow ramp-ups and from what I can see they typically keep the utilisation of my Internet connection below congestion (as in perhaps averaging at 80% of capacity). Personally I frequently see several potential congestion points between user device and what it's communicating with. There is the ISP-CDN or ISP-ISP interconnect point. There might be congestion on the core-core links. There is the uplink to the BNG or whatever. There is the user-unique shaper There is the L2 aggregation network (DOCSIS/*PON/ETTH) There is the in-house wifi network. So even if the ISP does a great job, we might have the user-unique shaper and the wifi both congesting and the wifi might be slower than the user-access link. This is the case in my home sometimes. Even with a great wifi setup (multiple 5GHz APs) I frequently get congestion there resulting in lower speeds than my 250 megabit/s Internet access speed. So this means traffic might encounter half of the time my 250 megabit/s ISP shaper as the bottleneck, then sporadically it encounters my wifi lowering the speed even more, and then returning to my ISP shaper being the slowest point. So I think your suggestion of what we should test is useful. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 6 07:35:05 2019 Return-Path: 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 23C751201C5; Tue, 6 Aug 2019 07:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 9yHQHzJXeiMS; Tue, 6 Aug 2019 07:35:02 -0700 (PDT) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 8655A1201B8; Tue, 6 Aug 2019 07:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1565102098; x=1596638098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ViIkvC0ULuMaAUHmOEp90+unDSBdRr2XXU1OygATFY8=; b=5QmAGy4l39cuuuaKKYfjovD5c9lSbQ/AYj87EWEzVQK0OxH8lJUTd6/u 6D6+d10QnTWXMe2K8ehVEzGmtnOKgo8tM0oBwl6ZP0WNkFmRKeD+qiKXF SNdBIEeCm3toYobP+R4WDhrIkvE976m/ZAA/ig2AK2msDpz+o6sb+CCV2 lMqs17fqNp5S08t4opdPRkk474LpGiiJt4A+dZZA3V2ldse8gpRAMtSIe rGCgxgg0fZahbOBAt2sA7HAAf94hvq6AVsUvKmTY6gOtIpkyKjbtF+eFX yv/w7exhtW77lX5VkNgI/MdumaBpJDOFV1ZLxQ8/ozs4Zsb5HCyPdsOIb g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Aug 2019 16:34:56 +0200 X-IronPort-AV: E=Sophos;i="5.64,353,1559512800"; d="scan'208";a="596517677" X-MGA-submission: =?us-ascii?q?MDGiKHy7rC2oLTIXsypVclHddABSxxKWQNcWlA?= =?us-ascii?q?JfCavaS6K5LElICy2u0biGolH8vCieepOcpdVkmNeYJCYreyoLqbhWCd?= =?us-ascii?q?Z/aOMnVvE1MVHquPD7W6V3sw4Cuo2EPf7Dg9YIFhlzA8EOmTfDUgqEjc?= =?us-ascii?q?UAOIGJ20beo78JOjC1mOH2ZQ=3D=3D?= Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 06 Aug 2019 16:34:59 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 16:34:58 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 6 Aug 2019 16:34:58 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.21) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 16:34:59 +0200 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0319.DEUPRD01.PROD.OUTLOOK.DE (10.158.165.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Tue, 6 Aug 2019 14:34:57 +0000 Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2136.018; Tue, 6 Aug 2019 14:34:57 +0000 From: To: CC: , , Thread-Topic: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVSTRkPkpydBILe0SaPVsimE5Fu6bsIA6QgABHggCAAAbSQIAAJ+AAgAFP7QCAAEGLwA== Date: Tue, 6 Aug 2019 14:34:57 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.157] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e93e490-8e66-4325-b4bd-08d71a7b416d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB0319; x-ms-traffictypediagnostic: LEXPR01MB0319: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(366004)(39860400002)(396003)(199004)(189003)(81166006)(66556008)(64756008)(4326008)(66476007)(6116002)(76116006)(3846002)(8676002)(53936002)(66066001)(68736007)(45776006)(5660300002)(478600001)(9686003)(81156014)(66946007)(8936002)(14454004)(11346002)(14444005)(71200400001)(71190400001)(476003)(2906002)(305945005)(66574012)(7736002)(66446008)(55016002)(446003)(33656002)(486006)(316002)(7696005)(54906003)(26005)(256004)(76176011)(86362001)(6916009)(52396003)(102836004)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0319; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rnyne1jNHcjuS+KhP3NDNilwF8fH3n+Q0EieM7Hefz79C4j9v8SPHfmKXKB+COGgA8W/x7RVg12cOl0+EK/Ss9PBulgXqSj3bJiQSqLyekB5AVVxOZ/iIkv3X5UPw81HkRQT0NOYIjgF76rtuzNcYSNhdD+IQo/xuLy0NzxUaK+9dqbHM3ySym+xM0EJY0lop9RqdO1d4gEeimhJHFqW4sgEH9huDugZzxkdDBbT4I6KjhrTpIzsCS1qn4JdpFel5ccK/owAFJU0Dvi8y6knJy7Ckf/ObBQWU+EwHMbgqzP1hFH1eTLnDdhv8Dmsfd8Gnvh881E67V/D3D+B/Zxa3MnLWSukPUiREN5T2rCMo/61uTYwtoOQr/hJ+YfmUKvWi8K4YeDOA1A3qMO90HY4OZTOe0xwJepUYQBNkIZREEw= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3e93e490-8e66-4325-b4bd-08d71a7b416d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 14:34:57.6473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0319 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 14:35:04 -0000 I'd like to sort Mikael's list a little.... -----Urspr=FCngliche Nachricht----- Von: Mikael Abrahamsson =20 Of course congestion occurs. But the probability of it matters (the less li= kely it is, the less likely are efforts to work around it)=20 Congestion is not probable in a well dimensioned backbone and at paid peeri= ngs. I think the effort put into congestion avoidance by engineering is hig= h at these locations and whether protocol design to deal with congestion th= ere (and make a gain as compared to todays transport performance under cong= estion there) is worth a larger effort. Bulk transport optimisation makes s= ense there, that includes suitable AQM. Public peerings and not well dimensioned networks may suffer from regular c= ongestion. I'm not sure to which extent technical standards can significant= ly improve service quality in that situation. IP transport must work as goo= d as possible also in such a situation, of course.=20 The following are access issues: There is the uplink to the BNG or whatever. There is the user-unique shaper There is the L2 aggregation network (DOCSIS/*PON/ETTH) There is the in-h= ouse wifi network. Maybe one can add LTE and 5G, these are layer 2 standards missing above. Sh= ared L2 may result in annoying performance. To me, L3 protocol design impro= ving IP performance over one or more L2 protocols standardised by other SDO= s sounds good. I wonder to which extent that's feasible. =20 As you know, the user-unique (BNG or the like) shaper is my favourite site = where I'd appreciate improvements.=20 Home Gateways are a mass market product. I'm not familiar with ways to impa= ct the vendors of that segment (but agree that it's worth trying). Also wir= eless scheduling of IP traffic certainly is an interesting topic. I'm not s= ure whether IETF has sufficient impact to push for improved packet transpor= t performance there (again, it's worth trying). From nobody Tue Aug 6 08:28:04 2019 Return-Path: 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 0A4151203A4; Tue, 6 Aug 2019 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 J4aK3rpH9GwZ; Tue, 6 Aug 2019 08:28:01 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADAD120398; Tue, 6 Aug 2019 08:28:01 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id x25so82660773ljh.2; Tue, 06 Aug 2019 08:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LDVNk5CIszTLYhXZlWoUlmNKVSzg0p4CiHpvy4vDb24=; b=GMYDW3D10wwq0MOkCrjYXwK7xeV0eKa0TDUSjtcTpZoOVTaluXkgqRqjgrmqwr2gW7 U5p/+3ztaUmyVUmAZU9pI08mXDaQJFUjYxSBMFN+4KS6qtXTf+lDMBworKxeYEYaYpvj t+UQnWFxeRXaUfYk6N3c/oOOxA0CofBC1dUsGLLtLwY88O41M+z0n5Dsq5k8CXdEg1T8 UjfpABgj3wFEMJfTV0fcOjh+9KtFn1v2b9l8Q8sPxmTUu+sem9tIUFbHvCyYn8kGHqzB DayZ4aRXFHwf0gb/BUxbzuqCeTGrM5TX19mDFoyyVVFBfYXHG9fHpkxfrllGJ4l5Q4RN eGpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LDVNk5CIszTLYhXZlWoUlmNKVSzg0p4CiHpvy4vDb24=; b=PVPfOkOGv3oVq4dzv0Simaf5onvHYIc7DlpiW8WSuXscIWx5cpdtVv4L9eQh5eFuuI 2HVj1DyHiajF1CeY76a/Z+6CAGC5VPBASgQxOn9FXp5AXccvBEgXyR/gpBCnxwJjfKxS 6qegdWUJQNygP4SUF7hbgTXQah4c4ZvV22FaPtRJ60XhMqg9HBI+TqivPzYAs9da0wRM O+rCLZI8AJVcRCAJSWVfs11K6SjmRZUFMWe1lg0Ids/rx74UL7SUfk6ZqhdShDg9ki/b o9aGTV1zoNN+P2B2yc8A+5bjWRPq6U27/MkyofRyxDKNdPRYZeRWYcDXAZdx/Y9+sTWb 9ohA== X-Gm-Message-State: APjAAAWWU0XYF2qZE9cFvVCcQfXAg9E9m8s4VQ4mATUstAsNX9SMXq34 6zlUamd+srmvUJBjXIOz3As= X-Google-Smtp-Source: APXvYqz7++ILXp7EDkOZAC9Vu/eq+WI0NLYJ3CThuouLYgu/U/lS7XorfZBUYBpLWJyUiU/HtBN61g== X-Received: by 2002:a2e:2993:: with SMTP id p19mr2037147ljp.202.1565105279816; Tue, 06 Aug 2019 08:27:59 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-193-nat-p.elisa-mobile.fi. [83.245.237.193]) by smtp.gmail.com with ESMTPSA id 189sm17589130lfa.0.2019.08.06.08.27.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 08:27:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Tue, 6 Aug 2019 18:27:57 +0300 Cc: swmike@swm.pp.se, tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:28:03 -0000 > On 6 Aug, 2019, at 5:34 pm, = wrote: >=20 > Public peerings and not well dimensioned networks may suffer from = regular congestion. I'm not sure to which extent technical standards can = significantly improve service quality in that situation. IP transport = must work as good as possible also in such a situation, of course.=20 Obviously the application of AQM will not magically improve total = throughput. What it can do, however, is reduce latency and packet loss, = and thereby improve perceived reliability of the service. It may even = improve goodput for the same throughput - an increase in efficiency. This is especially true under emergency overload conditions, which is = when people most desperately want a functioning network, but it is most = likely to collapse under the strain. Often a disaster will incidentally = knock out some proportion of network infrastructure in the area, turning = a previously well-proportioned network into an under-proportioned one, = simultaneously with a sharp increase in demand as people try to find out = what is going on or communicate with friends and relatives, and = emergency response teams also try to coordinate their essential work. So IMO networks should be designed to work well when congested, even = when they are also designed to never *be* congested. Technical = specifications already exist and are well tested for this purpose. = Having them built in and turned on from the factory would be a great = step forward. - Jonathan Morton= From nobody Tue Aug 6 08:36:21 2019 Return-Path: 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 8F1161200B8; Tue, 6 Aug 2019 08:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PyWovfKecPKG; Tue, 6 Aug 2019 08:36:09 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD7412003E; Tue, 6 Aug 2019 08:36:09 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id a127so67140452oii.2; Tue, 06 Aug 2019 08:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HZxIUso5tTWxDEm1otnDpiERUu/1tjvmsPyHllCK21E=; b=b8Y+cK6oBr2jcosO6jhELRSrOmjklYQsi66/+RvohaQvPghRxVy1BIOQGQNy8C0Iu1 IXTIGrRVQ0vo3E3x2Wrn0ug4K5j9qT4fcY3m07N/6jv9xmPUG+BD8FwjZnt3hz1XBZCo tx2taTiSkC3GiLTpO4dAkPLtsaZlywagYaRAie8sIUTLNqw94Fah9T0Tr8NxqA/Ol82w KoHFbmcLjjayhr5FoEGSpuMid4AqdNhoUXv9iVS56Buw48peV3VRQsXLOYh2irsoBSel hqPKXMYT96mX52rfilibUju84R90DYv2O/q1sI/KzxrPicYS5aJw6McPtWQ2ExZxW2vu sP9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HZxIUso5tTWxDEm1otnDpiERUu/1tjvmsPyHllCK21E=; b=fSvHP7Qte8rnnDEjuSbLfWMCnU0UCsnBF+mhPz5nzSu/+hh68Hm471yQFYX3dj+7ad uQE87ZKUVzfRQbCMdd4qOPcjPUdlJcq7kAM6NIZ/QBAmjtIBJV2i+3GB049jwVuX/YaB +8sO9hL/s7e3KYea8r4jW1FIuA87bPI4JdVeIl6RAFx+wD+vEaqdWHPFQh7PFg09OwyQ diwLdTWkCliOae8SbS1pMtMaXIGuxpQ9li0hogbQc6yE9Q+K3Wwhr3nvkW/TnPmxDlzu JsOMIS5nphdyM8v8ydaETVgvGus9hDhGsrgTX/a4pXl5YOQPLj8CE87OZoBk5RmzzuJL qKUQ== X-Gm-Message-State: APjAAAU5I8ZG0lldFHnzs2vMBHpmRwWAa24XgcdMT02K5FFjlEOfaMte pmcfqzXuIkgMw932T0T9VSuoIdIbBDb90I0C+uY= X-Google-Smtp-Source: APXvYqxHAVznyy9i3poEkx4BHaT8kTU6lYMOXF2lAmQtV+Vhu8WGoyrCSjtBCElDXDswZM8j1ME3use+g+hPYC+kQ2I= X-Received: by 2002:a02:3093:: with SMTP id q141mr4835966jaq.128.1565105768541; Tue, 06 Aug 2019 08:36:08 -0700 (PDT) MIME-Version: 1.0 References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> In-Reply-To: From: Dave Taht Date: Tue, 6 Aug 2019 08:35:56 -0700 Message-ID: To: Jonathan Morton Cc: Ruediger.Geib@telekom.de, tcpm IETF list , ECN-Sane , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:36:12 -0000 On Tue, Aug 6, 2019 at 8:28 AM Jonathan Morton wrot= e: > > > On 6 Aug, 2019, at 5:34 pm, wrote: > > > > Public peerings and not well dimensioned networks may suffer from regul= ar congestion. I'm not sure to which extent technical standards can signifi= cantly improve service quality in that situation. IP transport must work as= good as possible also in such a situation, of course. > > Obviously the application of AQM will not magically improve total through= put. What it can do, however, is reduce latency and packet loss, and there= by improve perceived reliability of the service. It may even improve goodp= ut for the same throughput - an increase in efficiency. > > This is especially true under emergency overload conditions, which is whe= n people most desperately want a functioning network, but it is most likely= to collapse under the strain. Often a disaster will incidentally knock ou= t some proportion of network infrastructure in the area, turning a previous= ly well-proportioned network into an under-proportioned one, simultaneously= with a sharp increase in demand as people try to find out what is going on= or communicate with friends and relatives, and emergency response teams al= so try to coordinate their essential work. Overbuffering, the silent killer: http://blog.cerowrt.org/post/bufferbloat_on_the_backbone/ > So IMO networks should be designed to work well when congested, even when= they are also designed to never *be* congested. Technical specifications = already exist and are well tested for this purpose. Having them built in a= nd turned on from the factory would be a great step forward. I live in california, where I kind of expect the network to collapse in the next Big One. > > - Jonathan Morton > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Sun Aug 18 20:51:45 2019 Return-Path: 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 05B571201E3 for ; Sun, 18 Aug 2019 20:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 aJeriQRwiM_P for ; Sun, 18 Aug 2019 20:51:41 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 32618120133 for ; Sun, 18 Aug 2019 20:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1YJzVzpF6gWEMC5/cdNrGj+duK4pAL9SDWdnPSms6ho=; b=wWRyGbxp7O9B0WP7Lt9YvArQC uVLmFb2IfeDiDLEsmyUECB7FN5LZP+y/CJTqL+V9+wiPzpnL6i6NtuLs2pHf6ZPRaW6CxYZkNn3jM we3XVM3LViqPeBWAvKjVXppVJIb32sJ0Ft3jFV23bOjLWqryzXkIWZkEWSu5ZWfrqOUf7Ilqd50aj To6r/zyTfxNt1Ks5l+lSjKqSddF5NPFT8SuqzNx+0zzvAxvTFVg6iR4Ue5ED4KxPF8GAJqhOqXjyL TrnEKubjBarNawNF0UXBnwgj7UKcLsZ3wNwpP6xm21YL6CWac5jrKf9FYL7dwqinhm1O9q+y/TDyK yJON41rzg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51993 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hzYhj-000Zuy-Ea; Sun, 18 Aug 2019 23:51:40 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A97714ED-A8CC-4B66-A270-C9EFA0A08273" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312EB6CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Sun, 18 Aug 2019 20:51:34 -0700 Cc: Wes Eddy , tcpm IETF list Message-Id: References: <156450882804.14172.17458284787319017749.idtracker@ietfa.amsl.com> <10a8eba2-0d55-bd5d-ad22-4884f485a3de@mti-systems.com> <787AE7BB302AE849A7480A190F8B9330312EB6CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 03:51:43 -0000 --Apple-Mail=_A97714ED-A8CC-4B66-A270-C9EFA0A08273 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, RESERVED !=3D UNASSIGNED Unassigned means not currently assigned but that there=E2=80=99s a = process in place for assignment, IMO. Reserved means that they would be defined only by a change to the = protocol spec itself, not merely by an assignment mechanism. I would strongly suggest sticking with RESERVED, per the original doc. I = don=E2=80=99t think we=E2=80=99re in the business in this doc of = changing the specs per se. Joe > On Jul 30, 2019, at 10:42 PM, mohamed.boucadair@orange.com wrote: >=20 > Hi Wes, > =20 > Your suggestion on reserved bits works for me. Thanks. > =20 > As we are there are, I suggest to add a second action asking IANA to = move the (orphan) TCP flag registry to be a sub-registry under the = global =E2=80=9CTransmission Control Protocol (TCP) Parameters=E2=80=9D = (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml = ). > =20 > Also, add to the draft a reminder that =E2=80=9Creserved bits=E2=80=9D = are assigned following Standard Action as per Section 9.2 of RFC 2780. > =20 > Cheers, > Med > =20 > De : tcpm [mailto:tcpm-bounces@ietf.org = ] De la part de Wesley Eddy > Envoy=C3=A9 : mardi 30 juillet 2019 19:57 > =C3=80 : tcpm IETF list > Objet : [tcpm] Fwd: New Version Notification for = draft-ietf-tcpm-rfc793bis-14.txt > =20 > Hello, this incorporates some small cleanups that accumulated prior to = the IETF meeting, as well as some of the feedback received since then on = the mailing list. >=20 > A couple specific things not yet done (because it doesn't look like we = converged on the list yet): >=20 > - Did not yet change reserved bits to "unassigned" (nor indicate them = in the IANA considerations section). Rod Grimes has a good point about = these being very commonly referred to as "the reserved bits" in other = places. I'm thinking we could add a note to say that in IANA terms = they're "Unassigned" to add the clarity that Mohamed is advocating, but = not change the name? >=20 > - Did not yet move section 2.1. >=20 > - Did not yet remove the note about my confusion on MUST vs SHOULD = regarding reporting of excessive retransmissions in RFC 1122 (will = confirm on the mailing list the "no change" proposal that was suggested = at the meeting) >=20 >=20 >=20 > -------- Forwarded Message --------=20 > Subject:=20 > New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt > Date:=20 > Tue, 30 Jul 2019 10:47:08 -0700 > From:=20 > internet-drafts@ietf.org > To:=20 > Wesley M. Eddy , = Wesley Eddy >=20 >=20 >=20 > A new version of I-D, draft-ietf-tcpm-rfc793bis-14.txt > has been successfully submitted by Wesley M. Eddy and posted to the > IETF repository. >=20 > Name: draft-ietf-tcpm-rfc793bis > Revision: 14 > Title: Transmission Control Protocol Specification > Document date: 2019-07-30 > Group: tcpm > Pages: 104 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc793bis-14.txt = > Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ = > Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis = > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-14 = >=20 > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, > 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, > and should be considered as a replacement for the portions of that > document dealing with TCP requirements. It updates RFC 5961 due to a > small clarification in reset handling while in the SYN-RECEIVED > state. >=20 > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_A97714ED-A8CC-4B66-A270-C9EFA0A08273 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

RESERVED !=3D = UNASSIGNED

Unassigned means not currently assigned but that there=E2=80=99= s a process in place for assignment, IMO.

Reserved means that they would be = defined only by a change to the protocol spec itself, not merely by an = assignment mechanism.

I would strongly suggest sticking with RESERVED, per the = original doc. I don=E2=80=99t think we=E2=80=99re in the business in = this doc of changing the specs per se.

Joe

On Jul = 30, 2019, at 10:42 PM, mohamed.boucadair@orange.com wrote:

Hi Wes,
 
Your suggestion on reserved bits works for me. Thanks.
 
As we are there are, I = suggest to add a second action asking IANA to move the (orphan) TCP flag = registry to be a sub-registry under the global =E2=80=9CTransmission = Control Protocol (TCP) Parameters=E2=80=9D (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.= xhtml).
 
Also, add to the draft = a reminder that =E2=80=9Creserved bits=E2=80=9D are assigned following = Standard Action as per Section 9.2 of RFC 2780.
 
Cheers,
Med
 
De : tcpm [mailto:tcpm-bounces@ietf.org] De la part = de Wesley Eddy
Envoy=C3=A9 : mardi 30 juillet 2019 = 19:57
=C3=80 : tcpm IETF list
Objet : [tcpm] Fwd: New Version = Notification for draft-ietf-tcpm-rfc793bis-14.txt
 

Hello, this = incorporates some small cleanups that accumulated prior to the IETF = meeting, as well as some of the feedback received since then on the = mailing list.

A couple specific things not yet done = (because it doesn't look like we converged on the list yet):

- Did not yet change reserved bits to "unassigned" (nor = indicate them in the IANA considerations section).  Rod Grimes has = a good point about these being very commonly referred to as "the = reserved bits" in other places.  I'm thinking we could add a note = to say that in IANA terms they're "Unassigned" to add the clarity that = Mohamed is advocating, but not change the name?

- Did not yet move section 2.1.

- Did not = yet remove the note about my confusion on MUST vs SHOULD regarding = reporting of excessive retransmissions in RFC 1122 (will confirm on the = mailing list the "no change" proposal that was suggested at the = meeting)



-------- = Forwarded Message -------- 
Subject: 
New Version = Notification for draft-ietf-tcpm-rfc793bis-14.txt
Date: 
Tue, 30 Jul = 2019 10:47:08 -0700
From: 
internet-drafts@ietf.org
To: 
Wesley M. = Eddy <wes@mti-systems.com>, = Wesley Eddy <wes@mti-systems.com>




A = new version of I-D, draft-ietf-tcpm-rfc793bis-14.txt
has = been successfully submitted by Wesley M. Eddy and posted to the
IETF repository.

Name: = draft-ietf-tcpm-rfc793bis
Revision: 14
Title: = Transmission Control Protocol Specification
Document date: = 2019-07-30
Group: tcpm
Pages: 104
URL: https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc793bis-= 14.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/=
Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis=
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-1= 4

Abstract:
This document = specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the = Internet
stack, and has continuously evolved over decades = of use and growth of
the Internet. Over this time, a = number of changes have been made to
TCP as it was = specified in RFC 793, though these have only been
documented= in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from = RFC 793.
This document obsoletes RFC 793, as well as 879, = 2873, 6093, 6429,
6528, and 6691 that updated parts of RFC = 793. It updates RFC 1122,
and should be considered as a = replacement for the portions of that
document dealing with = TCP requirements. It updates RFC 5961 due to a
small = clarification in reset handling while in the SYN-RECEIVED
state.

RFC EDITOR NOTE: If = approved for publication as an RFC, this should
be marked = additionally as "STD: 7" and replace RFC 793 in that role.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_A97714ED-A8CC-4B66-A270-C9EFA0A08273-- From nobody Wed Aug 21 06:56:01 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA09120052; Wed, 21 Aug 2019 06:55:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: michael.scharf@hs-esslingen.de, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156639575883.25752.4839898330111637833.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 06:55:58 -0700 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 106 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:55:59 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: mptcp Technology Overlap: tsvwg quic taps tsvarea iccrg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: Please avoid the last slot on Thursday afternoon/evening --------------------------------------------------------- From nobody Wed Aug 21 09:19:42 2019 Return-Path: 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 C5DEE120BE4; Wed, 21 Aug 2019 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=bt.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 z8e9vr12_UvL; Wed, 21 Aug 2019 09:19:35 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0B5120BDB; Wed, 21 Aug 2019 09:19:34 -0700 (PDT) Received: from tpw09926dag12h.domain1.systemhost.net (10.9.212.36) by BWP09926078.bt.com (10.36.82.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 21 Aug 2019 17:19:30 +0100 Received: from tpw09926dag15g.domain1.systemhost.net (10.9.212.31) by tpw09926dag12h.domain1.systemhost.net (10.9.212.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 21 Aug 2019 17:19:30 +0100 Received: from bwp09926077.bt.com (10.36.82.108) by tpw09926dag15g.domain1.systemhost.net (10.9.212.31) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 21 Aug 2019 17:19:30 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.53) by smtpe1.intersmtp.com (10.36.82.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 21 Aug 2019 17:19:28 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kVovDn7DA/ZsTwpy9OxEyvUtvmN3MKr5zKWlmo25MaCEpDzofAZFKnqoIpslNKd48NBCO/lHExYDwZNutPeiIESFHZ1GdrZD3jNjzosFL1OUrppaTphlRkXG0FiFhh3QZySiUDyRIPUWEICXJsQlJY2zjdVWq5D9Eca5Rv7+7brIt3ARmqXk/QYvm2RFY4sxamet1GEtvC19RR0Kqd4Y2Ta5b/Fs1A2y/JoXGSDTfyzP6kW3yvbjs7b3JJFMg3YKua4abDjTgKtERGiiLZ4514QuUxR7FBxC/6PHj69YKyLCjAxFtYkHuf9gO8/DEdvZWWOoAYo5SGrcta8ms7zdBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FTCHDwpAyxGsj/6/QkEKHZuLxgeYCwvbd4XB0/UlDDI=; b=E6mILAw1DyKFtN5H0NdfiS65ldexYFS+KKADacGG0zmpKepttnOyMZ4DyifkaBJcXK0QFghjGE3nyG2WgTNEqGtUB0O5o0AoI1bMTv1WIgE8RgkU17bj+e1NKGOLqKRdIFF2XwCQ+8MuRdd4ZYavXyJcWhE9qS8COl6JjhaXQHlwBueguVG+2O0U0XJwrvNW9hdWnRpTF1YLwfKtHC1xeN8TdBg+B6iOEgqXIeAVJGG7qPZwyCbNoH18jmQX6+GTT1kEcGQ++rT1nR9n/DJtj8yGgqymZvCKrAZv/Wuggkv1TG5pwgq7N84gjxVsa/qwqhcUx6piaMRSu/NJcJZZ3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FTCHDwpAyxGsj/6/QkEKHZuLxgeYCwvbd4XB0/UlDDI=; b=qrDrwZg9q9PZKllEThhqMtX83swdvXh6ZtyftJpkSSUSsfuCKmrPGkp3iOeoD/wYRMy/jCWCx8bZ1G2afPOPXQ+4HaJbqFaPPLX8m98bTKWQlphKtIN+vlzOUbqY3SZMOu8j0rdMqaOHOAKKbGtkEPeeoHlrArF0lu4elQKK1xM= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB1801.GBRP123.PROD.OUTLOOK.COM (20.176.159.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 16:19:29 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::4fc:dcd0:dba3:89d3]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::4fc:dcd0:dba3:89d3%5]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 16:19:29 +0000 From: To: , , CC: Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09? Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llAALWUTAAP9U2QA Date: Wed, 21 Aug 2019 16:19:28 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86422aa3-c3a6-4f8e-ce8f-08d7265357a3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1801; x-ms-traffictypediagnostic: LNXP123MB1801: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(396003)(376002)(39860400002)(13464003)(51914003)(199004)(189003)(76116006)(486006)(476003)(52536014)(81156014)(8676002)(66946007)(2501003)(66574012)(6246003)(99286004)(33656002)(30864003)(446003)(11346002)(66446008)(64756008)(66556008)(66476007)(53946003)(7736002)(305945005)(74316002)(81166006)(26005)(2201001)(102836004)(5660300002)(53546011)(6506007)(8936002)(186003)(86362001)(53936002)(25786009)(6436002)(110136005)(3846002)(2906002)(6116002)(55016002)(4326008)(229853002)(6306002)(316002)(9686003)(14454004)(966005)(71190400001)(71200400001)(14444005)(256004)(66066001)(76176011)(7696005)(478600001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1801; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1cZpuiJKL8fMWyAzRQhur/E06tgRSurJdQmm/bY5D0MaiAFxofdEyIBy9y+eI5X64sL6wbDot95aShr9WsQhNuvAScx9ebQJ5gIVXnDSQWb5DWsi7J/9tMUoWJ6GAkA4qX+pa9B7mVyWP3DnhLdZwMLFGBBdDXxwpZpiqWtEp77AdJ5wa7FZ/tBcObXqEFcK8tBzZzk5PxkQN+PzTZZpaOSd4pOcpp5uONHcdxjOJqNp2jzI6Y5fyOXPHe1gMcxtnCOwW4iJ7Oa0nexN7NDP243rjlz/76hwNMiFV/Qjh8F2WUArpjrhXZoM6HNbaHYFaRt2KK37vLolRM3Q3bqXMC3ppkihYeNCRAzs70kcQ34JZioSKlhPbAgjqXaeaQz/P6FqJDa0RqMiri0agNdnzdv1izAvZaC8k50JCkZRdqA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 86422aa3-c3a6-4f8e-ce8f-08d7265357a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 16:19:28.8819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8UIilnSCEajf/0/+uhCrMVzRxhpfTIgApIuA3KTcpVraNLCDUwXvhxsLW2KJUa7sYZevbqhKPIMh5r1o3EubwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1801 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6617 X-NAI-Spam-Version: 2.2.0.9309 : core <6617> : inlines <7138> : streams <1830744> : uri <2887443> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 16:19:40 -0000 Med, Coming back to this after hols... Thanks for the updates. In-line.=20 phil > -----Message d'origine----- > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9 : jeudi 1 ao=FBt 2019 10:58 =C0 :=20 > philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; tcpm@ietf.org=20 > Cc : tcpm-chairs@ietf.org Objet : Re: [tcpm] WGLC comments addressed=20 > in draft-ietf-tcpm-converters- 09? >=20 > Phil, >=20 > I prepared an updated version with the following changes to address=20 > your remaining comments: >=20 > * Position Figure 1 right after the text about upstream/downstream=20 > connections to avoid the confusion about the direction. [phil] thanks, this certainly helps. It's a shame that the two bullets that= actually define upstream / downstream connection are several pages later a= t the bottom of page 9 (can it be moved?). One could also be pedantic about Figure 1 ("upstream" should be "upstream c= onnection"; there's a missing space to the left of "Server" ; the two inter= faces are kind of below the Converter - Fig 1 seems to be a physical boxes = picture rather than a protocol pic). I know what you mean and asci art is t= ricky, and maybe it's ok or the rfc editor will have suggestions. > * Delete "(1)" from Figure 5 caption > * Add text to clarify why "eventually" is used in the text. Rearranged=20 > the text about address preservation/sharing modes, accordingly. I like that you moved the para about address preservation /sharing, so that= it appears a bit earlier.=20 The sentence about "eventually" is, for me, no clearer - sorry. Can't you j= ust explain the two address modes one at a time? > * Section 3.2: remove the text about inserting Convert TLVs in=20 > "subsequent messages". > * Section 3.3: add finally a side not to remind that RST does not=20 > close an MPTCP connection, and hence is not reflected by the converter=20 > on the TCP connection. Thanks > * Section 4 (Introduction): Clarified that both control and data=20 > messages are sent over a relayed connection. I hesitated to add the=20 > NEW text you proposed about relaying connections, but finally=20 > discarded it because the behavior is already described in many places=20 > in the documents. No need to be redundant. I still think that the actual basic operation of the converter for data pac= kets is weakly described (assuming the description is just in this document= and not somewhere else) S3.2 Theory of operation says " Any user data received by the Transport Con= verter over the upstream (or downstream) connection is relayed over the dow= nstream (or upstream) connection." This is fine as a high level summary. S4 is really about the control protocol messages, not the data plane. But i= t does say: " By default, the Transport Converter listens on TCP port numbe= r TBA for Convert messages from Clients. Clients send packets bound to co= nnections eligible to the conversion service to the provisioned Transport C= onverter using TBA as destination port number. This applies for both contr= ol and data messages." As far as I can see, you don't actually say what the converter does with th= e data packets. Perhaps it is obvious, but it surely should be stated. The = behaviour for the other direction should be stated. And some statement abou= t the behaviour in the address preservation /sharing modes. Also, what is d= one (MUST /SHOULD /MAY) if there's no 'conversion entry' for this client. P= erhaps this can be partially done with a reference to a proxy RFC (presumab= ly that would be an extra Normative ref). On minor points, I'd describe the data plane operation in its own sub-secti= on. I'd say "data" rather than "data messages". > * Update Figures 11/19 > * Add an appendix to record the design considerations from the changes=20 > log. Thanks phil >=20 > I also made some other edits to fix some nits. >=20 > You may check the full diff at:=20 > https://www.ietf.org/rfcdiff?url1=3Ddraft- > ietf-tcpm-converters-09&url2=3Ddraft-ietf-tcpm-converters-10 >=20 > Thank you for the review. >=20 > Cheers, > Med > -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 01 August 2019 09:58 To: Eardley,PL,Philip,TUD1 R ; Michael.Scharf@hs-ess= lingen.de; tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09? Phil,=20 I prepared an updated version with the following changes to address your re= maining comments:=20 * Position Figure 1 right after the text about upstream/downstream connecti= ons to avoid the confusion about the direction. * Delete "(1)" from Figure 5 caption * Add text to clarify why "eventually" is used in the text. Rearranged the = text about address preservation/sharing modes, accordingly.=20 * Section 3.2: remove the text about inserting Convert TLVs in "subsequent = messages".=20 * Section 3.3: add finally a side not to remind that RST does not close an = MPTCP connection, and hence is not reflected by the converter on the TCP co= nnection.=20 * Section 4 (Introduction): Clarified that both control and data messages a= re sent over a relayed connection. I hesitated to add the NEW text you prop= osed about relaying connections, but finally discarded it because the behav= ior is already described in many places in the documents. No need to be red= undant. =20 * Update Figures 11/19 * Add an appendix to record the design considerations from the changes log. I also made some other edits to fix some nits.=20 You may check the full diff at: https://www.ietf.org/rfcdiff?url1=3Ddraft-i= etf-tcpm-converters-09&url2=3Ddraft-ietf-tcpm-converters-10=20 Thank you for the review.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9=A0: mercredi 31 juillet 2019 14:22 = =C0=A0 > : philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; tcpm@ietf.org=20 > Cc=A0: tcpm-chairs@ietf.org Objet=A0: Re: [tcpm] WGLC comments addressed= =20 > in draft-ietf-tcpm-converters- 09? >=20 > Hi Phil, >=20 > Thank you for double checking. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de=20 > > philip.eardley@bt.com Envoy=E9=A0: mercredi 31 juillet 2019 12:26 =C0= =A0:=20 > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0:=20 > > tcpm-chairs@ietf.org Objet=A0: Re: [tcpm] WGLC comments addressed in=20 > > draft-ietf-tcpm- > converters- > > 09? > > > > I think most of my comments are addressed. Here are some things I=20 > > think could still be clarified, plus a couple of extra questions=20 > > that occurred to me when I was checking the latest version. > > > > Section 3.1 > > < > description assumes outgoing connections as default.>> > > > > This sentence seems to contradict itself (can something be both=20 > > assumed and have to be explicitly stated?). >=20 > [Med] Yes. Consider for example the following text: >=20 > "By default, the Transport Converter listens on TCP port number TBA > for Convert protocol (Convert, for short) messages from Clients. >=20 > Clients send packets that are eligible to the conversion service to > the provisioned Transport Converter using TBA as destination port > number. Additional information is supplied by Clients to the > Transport Converter by means of Convert messages as detailed in the > following sub-sections." >=20 > It applies only for the outgoing connections. >=20 > Maybe:- > > In general this document assumes that the client initiates the > connection > > (in other words, it is an outgoing connection); the scenario with an=20 > > incoming connection is discussed in a couple of places [references]. >=20 > [Med] I can use this wording if you think it is better. >=20 > > > > In Figure 1 I find the 'upstream' and 'downstream' labels a bit > confusing > > (especially as the lines have arrowheads in both directions), and it=20 > > is shown as the link between client and converter etc. I think it=20 > > would be better to move lower down (ie separate from the actual=20 > > link), something > > like: > > -------> upstream direction (outgoing connections) > > <------ downstream direction (incoming connections) > > >=20 > [Med] Actually, upsteram and downstream are defined as follows: >=20 > o the upstream connection is the one between the Client and the > Transport Converter. >=20 > o the downstream connection is between the Transport Converter and > the Server. >=20 > This is independent of the connection direction. >=20 > > Figure 5 caption has a stray "(1)" that can be deleted >=20 > [Med] Fixed. >=20 > > > > Above Figure 6 > > < > > > >=20 > [Med] "eventually" is justified: cover the case of a converter=20 > configured in an address preservation mode (e.g., IPv6). The=20 > destination IP address won't be rewritten in such case. >=20 >=20 > > Section 3.2 / 3.3 > > There are two paragraphs at the end of 3.2 and a bit more in 3.3=20 > > discussing what happens when a connection ends with FIN and TCP RST etc= . > I > > think you should write a bit more about the MPTCP case - since there=20 > > are subflow TCP RST and MP_FASTCLOSE cases to consider. A TCP RST on=20 > > one > MPTCP > > subflow presumably shouldn't trigger the Converter to close the TCP=20 > > connection on its other interface. >=20 > [Med] Section 3.2 covers the generic TCP case. Hence, there is no need=20 > to discuss MPTCP specifics in that section. >=20 > I guess you are referring to this text in Section 3.3: >=20 > Note that, if the TCP connection fails for some reason, the Converter > tears down the Multipath TCP connection by transmitting a > MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with > the transmission of DATA_FINs, the Converter terminates the TCP > connection by using FIN segments. >=20 > The text covers exclusively the cases that lead to the termination of=20 > the upstream/downstream connection. >=20 > Given that MPTCP spec says: >=20 > "With MPTCP, the RST only has the scope of the > subflow and will only close the concerned subflow but not affect the > remaining subflows. MPTCP's connection will stay alive at the data > level, in order to permit break-before-make handover between > subflows." >=20 > the subflow RST is not covered (as it does not terminate the MPTCP leg). >=20 > > > > Section 4 intro > > > > << This section describes the messages that are exchanged between a > > Client and a Transport Converter. > > > > By default, the Transport Converter listens on TCP port number TBA > > for Convert protocol (Convert, for short) messages from Clients. > > > > Clients send packets that are eligible to the conversion service to > > the provisioned Transport Converter using TBA as destination port > > number. Additional information is supplied by Clients to the > > Transport Converter by means of Convert messages as detailed in the > > following sub-sections. > > > > Convert messages may appear only in a SYN, SYN+ACK, or ACK. > > > > Convert messages MUST be included as the first bytes of the > > bytestream. A Convert message starts with a 32 bits long fixed > > header (Section 4.1) followed by one or more Convert TLVs (Type, > > Length, Value) (Section 4.2). > > >> > > > > Some comments: > > The Client also listens on TCP port TBA (not just the converter) >=20 > [Med] The client will listen on the internal port number that it=20 > indicated when creating a mapping in the converter to allow for=20 > incoming connections. This is needed to demux services hosted on the same= client. >=20 > This is covered in this text: >=20 > The Converter accepts the request by creating a TCP > mapping (internal IP address, internal port number, external IP > address, external port number). The external IP address and external > port number will be then advertised using an out-of-band mechanism so > that remote hosts can initiate TCP connections to the Client via the > Converter. Note that the external and internal information may be > the same. >=20 > > Stress that ALL convert msgs start with the same header. > > I think the "Clients send packets..." para is better re-arranged. > > > > Question: there seems to be a contradiction. The text here says=20 > > "Convert messages may appear only in syn, syn-ack, ack". But then in=20 > > S3.2 it says "This information is sent at the beginning of the=20 > > bytestream, either directly in the SYN+ACK or in a subsequent=20 > > packet." (this information is "about the TCP options that were=20 > > negotiated with the Server.") (Incidentally, in S3.2 essentially the=20 > > same sentence is repeated two sentences later.) is the idea that SYN /= syn-ack /ack is the 'normal' > > case, but can be in later pkts? >=20 > [Med] Good catch. >=20 > OLD: > The Client sends a SYN destined to the Transport Converter. The > payload of this SYN contains the address and port number of the > Server. The Transport Converter does not reply immediately to this > SYN. It first tries to create a TCP connection towards the target > Server. If this upstream connection succeeds, the Transport > Converter confirms the establishment of the connection to the Client > by returning a SYN+ACK and the first bytes of the bytestream contain > information about the TCP options that were negotiated with the > Server. This information is sent at the beginning of the bytestream, > either directly in the SYN+ACK or in a subsequent packet. For > graphical reasons, the figures in this section show that the > Transport Converter returns this information in the SYN+ACK packet. > An implementation could also place this information in a packet that > it sent shortly after the SYN+ACK. >=20 > NEW: > The Client sends a SYN destined to the Transport Converter. The > payload of this SYN contains the address and port number of the > Server. The Transport Converter does not reply immediately to this > SYN. It first tries to create a TCP connection towards the target > Server. If this upstream connection succeeds, the Transport > Converter confirms the establishment of the connection to the Client > by returning a SYN+ACK and the first bytes of the bytestream contain > information about the TCP options that were negotiated with the > Server. >=20 >=20 > > > > Question: the text says "Clients send packets that are eligible to=20 > > the conversion service to the provisioned Transport Converter using=20 > > TBA as destination port number." Is this referring to the exchange=20 > > of Convert protocol messages? Or is this referring to subsequent=20 > > data that is actually sent to the TBA port number? I think the text=20 > > implies the > latter, > > which I assume is not correct. >=20 > [Med] This applies to all messages that cross the converter. >=20 > > > > > > Suggested text:- > > > > << > > This section defines the Convert protocol (Convert, for short) > messages > > that are exchanged between a Client and a Transport Converter. > > > > Convert messages MUST be sent to TCP destination port TBA.=20 > > Therefore, > a > > Transport Converter and a Client listen on this TCP port for Convert=20 > > messages. >=20 > [Med] The initial wording is correct. >=20 > > Convert messages MAY appear in a SYN, SYN+ACK, or ACK or MAY=20 > > appear > in > > a subsequent packet. >=20 > [Med] The initial wording is correct. >=20 > > Convert messages MUST be included as the first bytes of the bytestream. > > All Convert messages start with a common 32 bits long header=20 > > (Section 4.1), followed by one or more Convert TLVs (Type, Length,=20 > > Value) > (Section > > 4.2). > > After a successful exchange of Convert messages, a TCP connection=20 > > with > TCP > > extension(s) is established between the Client and Transport=20 > > Converter (for instance, Multipath TCP), and a (normal) TCP=20 > > connection is established between the Transport Converter and other=20 > > end host, with the Transport Converter acting as an explicit proxy=20 > > between the two connections (for instance, between MPTCP and TCP). >=20 > [Med] No problem (even if the last sentence is already stated in=20 > previous sections). >=20 > > >> > > > > > > Section 4.0, 4.2.6 etc > > Various places say things like "the Unassigned field MUST be set to=20 > > zero by the transmitter and > > ignored by the receiver. These bits are available for future use > > [RFC8126]." > > Comment: I heard in ietf-105 about problems for extensibility of=20 > > various protocols because implementations insist on all zeroes for=20 > > fields, otherwise discard packets. The suggestion is to grease=20 > > (which I think means that the senders set to random values and=20 > > receivers MUST ignore) >=20 > [Med] I don't see the value for doing this. >=20 > > Also, 'sender' rather than 'transmitter' >=20 > [Med] Fixed. Thanks. >=20 > > > > Figure 11 > > In the figure you have Value being optional in bits 16-31 and=20 > > compulsory in bits 32+. I think this should be the other way round. >=20 > [Med] OK. >=20 > > > > Section 4.2.8 > > "This TLV has a variable length. It appears after the Convert fixed- > > header in the bytestream returned by the Transport Converter." > > Figure 19 doesn't show variable length. Must its length be a=20 > > multiple of > > 32 bytes (padded if needed)? (I assume so, to be consistent with > > elsewhere.) >=20 > [Med] Agree. Fixed the figure. >=20 > Padding is mentioned in the error description (when appropriate), e.g.,: >=20 > "The > list of unsupported TCP options MUST be padded with zeros to end > on a 32 bits boundary. " >=20 > > The second sentence could be deleted, since elsewhere text says the > TLV(s) > > must be at the start of the bytestream. But if you keep the sentence=20 > > I suggest you say "appears _immediately_ after" > > >=20 > [Med] Deleted that sentence. No need to be redundant. >=20 > > S6 > > "The case of a middlebox that removes the payload of SYN+ACKs (but the > > payload of SYN) can be detected by a Client." > > Do you mean: but _not_ the payload of SYN? >=20 > [Med] Yes. >=20 > > > > < > This section to be removed before publication.>> It would be=20 > > really nice if somehow the material here that explains the design=20 > > rationale, and development from earlier approaches, could be > kept. > > It's useful info, I think. >=20 > [Med] OK, added a new appendix to cover the key points. >=20 > > > > Best wishes, > > phil > > > > -----Original Message----- > > From: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > > Sent: 22 July 2019 09:01 > > To: Eardley,PL,Philip,TUD1 R > > Cc: tcpm-chairs@ietf.org > > Subject: WGLC comments addressed in draft-ietf-tcpm-converters-09? > > > > Hi Phil, > > > > Could you please have a look at -09 and let me know if your WGLC > comments > > are addressed? > > > > If not, please follow-up on the mailing list. > > > > Thanks > > > > Michael > > > > -----Original Message----- > > From: tcpm On Behalf Of=20 > > internet-drafts@ietf.org > > Sent: Monday, July 22, 2019 8:04 AM > > To: i-d-announce@ietf.org > > Cc: tcpm@ietf.org > > Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the TCP Maintenance and Minor=20 > > Extensions WG of the IETF. > > > > Title : 0-RTT TCP Convert Protocol > > Authors : Olivier Bonaventure > > Mohamed Boucadair > > Sri Gundavelli > > SungHoon Seo > > Benjamin Hesmans > > Filename : draft-ietf-tcpm-converters-09.txt > > Pages : 47 > > Date : 2019-07-21 > > > > Abstract: > > This document specifies an application proxy, called Transport > > Converter, to assist the deployment of TCP extensions such as > > Multipath TCP. This proxy is designed to avoid inducing extra delay > > when involved in a network-assisted connection (that is, 0-RTT). > > > > This specification assumes an explicit model, where the proxy is > > explicitly configured on hosts. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tcpm-converters-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-09 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-09 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at=20 > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Aug 23 07:01:30 2019 Return-Path: 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 700861200F8; Fri, 23 Aug 2019 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de 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 1m39thTPw8qu; Fri, 23 Aug 2019 07:01:19 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413F11200E9; Fri, 23 Aug 2019 07:01:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 43C7C25A52; Fri, 23 Aug 2019 16:01:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1566568877; bh=r8j39YYQYxoopsOeMXO12A1/xiBHLbfIrgJybLR1p+4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=NYKnG2Dq7cGP/mxb2/dcPWgFeP4cs2S0xYMSESaNFsLYts8kaTO0kPSVJE9/rOVFY MnzxifdWs5RkT0XS6egYSl1o6zJOIFQr6lOgdqAYRSTeN4evuvS0eaAEii2i4yhW6x jnl1Ke5IlbS2V6eJBMFiV7tadTuWCV6/dGffLuDs= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0cS2nsnjAtS; Fri, 23 Aug 2019 16:01:16 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 23 Aug 2019 16:01:16 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.19]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 23 Aug 2019 16:01:15 +0200 From: "Scharf, Michael" To: Wesley Eddy , "tsvwg@ietf.org" CC: "tcpm@ietf.org" Thread-Topic: [tsvwg] L4S status tracking Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+N Date: Fri, 23 Aug 2019 14:01:15 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de> References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> In-Reply-To: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D40EB7Erznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] L4S status tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 14:01:21 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D40EB7Erznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Wes, I=92d like to add a smaller item that is mostly editorial and can hopefully= be sorted just out by re-wording, albeit it may require a careful analysis= of all documents. As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDv= WO3I5MudwpNkKyHY , I object to the terms =84traditional TCP=93 and also =84= classic TCP=93 or =84legacy=93 TCP when referring to a TCP implementation a= ccording to IETF standards-track RFCs. To me as a non-native native speaker, all these terms have a negative conno= tation. I also think this language is typical to marketing material. My prefered term when referring to TCP according to standards-track specifi= cation is =84standard TCP=93. I would also be fine with other terms as long= as they are neutral and make clear that experiments do not replace, deprec= ate, or outperform standards. Similarly, I think that term such as =84classic=93 is not appropriate for t= he TCP standard congestion control (=84Reno=93). As of today, this is the T= CP congestion control algorithm on standards track that has IETF consensus.= The term in the TCPM charter is =84TCP standard congestion control=93. I a= lso think that terms such as =84Reno-compatible=93 or the like would be neu= tral. Note that I do not object to the terms =84classic ECN=93, =84legacy ECN=93,= =84legacy AQM=93 or the like, i.e., if the context is ECN and not specific= ally TCP or the TCP congestion control. I believe it is up to the TSVWG do = decide if this term shall be used for compliance to RFC 3168. I have no str= ong opinion on that. As far as I can see, most use of the term =84classic= =93 is in this context and I don=92t ask for changes in those cases. Some use of the term =84Classic Service=93 may also require careful review = to clearly separate it from TCP Standard behavior. Note that some use of the term =84Classic TCP=93 would probably also apply = to =84Classic QUIC=93 once the QUIC standard is finished. To me as a non-na= tive speaker, it would be really strange to use the term =84classic=93 in t= he context of a brand-new transport protocol. IMHO in that case the term = =84classic=93 would be even more confusing. I also add the TCPM list in CC to ensure consistency. Thanks Michael (with no hat) Von: Wesley Eddy Gesendet: Sonntag, 11. August 2019 07:08 An: tsvwg@ietf.org Betreff: [tsvwg] L4S status tracking I created tickets in the TSVWG "trac" tool in order to help keep track of the individual things that look like they should be addressed in progressing L4S document set: https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&page=3D1 I'll try to update these based on the ongoing discussions, updates, etc., but it will make it very easy if you happen to mention the ticket numbers or some key words in threads and messages, when significant. --_000_6EC6417807D9754DA64F3087E2E2E03E2D40EB7Erznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Wes,

 

I=92d like to add a smaller item that is mostly ed= itorial and can hopefully be sorted just out by re-wording, albeit it may r= equire a careful analysis of all documents.

 

As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY= , I object to the terms =84traditional TCP=93 and also =84classic TCP=93 o= r =84legacy=93 TCP when referring to a TCP implementation according to IETF= standards-track RFCs.

 

To me as a non-native native speaker, all these te= rms have a negative connotation. I also think this language is typical to m= arketing material.

 

My prefered term when referring to TCP according t= o standards-track specification is =84standard TCP=93. I would also be fine= with other terms as long as they are neutral and make clear that experimen= ts do not replace, deprecate, or outperform standards.

 

Similarly, I think that term such as =84classic=93= is not appropriate for the TCP standard congestion control (=84Reno=93). A= s of today, this is the TCP congestion control algorithm on standards track= that has IETF consensus. The term in the TCPM charter is =84TCP standard congestion control=93. I also think that t= erms such as =84Reno-compatible=93 or the like would be neutral.

 

Note that I do not object to the terms =84classic = ECN=93, =84legacy ECN=93, =84legacy AQM=93 or the like, i.e., if the contex= t is ECN and not specifically TCP or the TCP congestion control. I believe = it is up to the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong opinion on that. As f= ar as I can see, most use of the term =84classic=93 is in this context and = I don=92t ask for changes in those cases.

 

Some use of the term =84Classic Service=93 may als= o require careful review to clearly separate it from TCP Standard behavior.=

 

Note that some use of the term =84Classic TCP=93 w= ould probably also apply to =84Classic QUIC=93 once the QUIC standard is fi= nished. To me as a non-native speaker, it would be really strange to use th= e term =84classic=93 in the context of a brand-new transport protocol. IMHO in that case the term =84classic=93 would be even= more confusing.

 

I also add the TCPM list in CC to ensure consisten= cy.

 

Thanks

 

Michael (with no hat)

 

 

Von: Wesley Eddy
Gesendet: Sonntag, 11. August 2019 07:08
An: tsvwg@ietf.org
Betreff: [tsvwg] L4S status tracking

 

I created tickets in the TSVWG "trac" to= ol in order to help keep track
of the individual things that look like they should be addressed in
progressing L4S document set:

https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&= amp;asc=3D1&page=3D1

I'll try to update these based on the ongoing discussions, updates,
etc., but it will make it very easy if you happen to mention the ticket numbers or some key words in threads and messages, when significant.


 --_000_6EC6417807D9754DA64F3087E2E2E03E2D40EB7Erznt8114rzntrzd_-- From nobody Fri Aug 23 07:24:59 2019 Return-Path: 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 90C4B1200CE; Fri, 23 Aug 2019 07:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=F+SuD6uw; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=UOqrwSrz 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 43rcF9d5xKqF; Fri, 23 Aug 2019 07:24:47 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 CC2C01200C1; Fri, 23 Aug 2019 07:24:47 -0700 (PDT) Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7NEK5Wf020256; Fri, 23 Aug 2019 10:24:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=NokOdWYuFUFwZ8b+26EesZY1ufyPCkK9VMPekrQng/s=; b=F+SuD6uwqSvXMaWKAsEkABlUsAQTs9IYM68lkqUbO8Q5EOvJ7vHWulydjTLtnlMNJN68 v3sqVYwT+3+CuJxCsQHeBtNmsIYB6Y5IvxeDuT42SG9VKHHlxXkMTvORMNdsXcb/mg51 aGPrNMfY7wW4bYSDMWgBBUm2yIMbfJAMx+uzlP5PU42maXYlAkc0ZfFwUVO2cH3Plnp0 akPG8j7D7Vxxmt1IjvCuUG/WrxkkBpS/N1V9CWAOqm6TFR4sEBbcMC1xFkNqZu/SWHUf sQ8V0n/tXZwj23kJsaI3rBQ0FzHq5sB8fWCF8cOFWGfCm099gJfxt6bBzC6xJxqIuSTZ YQ== Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2uj2883f35-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 10:24:41 -0400 Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7NEN4gs081102; Fri, 23 Aug 2019 10:24:29 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2ujgrqs4xw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 23 Aug 2019 10:24:29 -0400 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x7NEO2Gi007093 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Aug 2019 10:24:28 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x7NEO2Gi007093 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1566570268; bh=A6wF1IwxoanagANzzqoM+0Kr7pA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=UOqrwSrzsoGShxkLKCn/NdUv48YeNWgXrQuuv4pJf1PsRD0V8nhRtPWu9ZE4CmRnt DKooNrhPl0D9c9AVbCsRlxO5J8xzyN/O4voG5Ln+ACJTqLNZheXvgsMM7jzzBcP3hw dhYlNfDXaT3Bs5BfslHVVbUd0hjFEMepSG23A3vc= Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 23 Aug 2019 10:23:13 -0400 Received: from MXHUB311.corp.emc.com (MXHUB311.corp.emc.com [10.146.3.89]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x7NENFow014475 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 23 Aug 2019 10:23:15 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB311.corp.emc.com ([10.146.3.89]) with mapi id 14.03.0439.000; Fri, 23 Aug 2019 10:23:15 -0400 From: "Black, David" To: "Scharf, Michael" , Wesley Eddy , "tsvwg@ietf.org" CC: "tcpm@ietf.org" , "Black, David" Thread-Topic: [tsvwg] L4S status tracking Thread-Index: AQHVUALCgTMTYGQiSken9mWnC5q35qcJGX2A///CdDA= Date: Fri, 23 Aug 2019 14:23:14 +0000 Message-ID: References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-08-23T14:23:13.7219103Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.238.21.131] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363069B90DMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-23_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908230149 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908230149 Archived-At: Subject: Re: [tcpm] [tsvwg] L4S status tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 14:24:50 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363069B90DMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Note that I do not object to the terms "classic ECN", "legacy ECN", "lega= cy AQM" or the like, i.e., > if the context is ECN and not specifically TCP or the TCP congestion cont= rol. I believe it is up to > the TSVWG do decide if this term shall be used for compliance to RFC 3168= . I have no strong opinion on that. > As far as I can see, most use of the term "classic" is in this context an= d I don't ask for changes in those cases. "RFC 3168 ECN" is the more precise term, whose use I would encourage. Use = of "classic ECN" seems ok, as long as the draft makes it clear that "classi= c" means "RFC 3168" in this context. Thanks, --David (as an author of RFC 3168) From: tsvwg On Behalf Of Scharf, Michael Sent: Friday, August 23, 2019 10:01 AM To: Wesley Eddy; tsvwg@ietf.org Cc: tcpm@ietf.org Subject: Re: [tsvwg] L4S status tracking [EXTERNAL EMAIL] Hi Wes, I'd like to add a smaller item that is mostly editorial and can hopefully b= e sorted just out by re-wording, albeit it may require a careful analysis o= f all documents. As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDv= WO3I5MudwpNkKyHY , I object to the terms "traditional TCP" and also "classic= TCP" or "legacy" TCP when referring to a TCP implementation according to I= ETF standards-track RFCs. To me as a non-native native speaker, all these terms have a negative conno= tation. I also think this language is typical to marketing material. My prefered term when referring to TCP according to standards-track specifi= cation is "standard TCP". I would also be fine with other terms as long as = they are neutral and make clear that experiments do not replace, deprecate,= or outperform standards. Similarly, I think that term such as "classic" is not appropriate for the T= CP standard congestion control ("Reno"). As of today, this is the TCP conge= stion control algorithm on standards track that has IETF consensus. The ter= m in the TCPM charter is "TCP standard congestion control". I also think th= at terms such as "Reno-compatible" or the like would be neutral. Note that I do not object to the terms "classic ECN", "legacy ECN", "legacy= AQM" or the like, i.e., if the context is ECN and not specifically TCP or = the TCP congestion control. I believe it is up to the TSVWG do decide if th= is term shall be used for compliance to RFC 3168. I have no strong opinion = on that. As far as I can see, most use of the term "classic" is in this con= text and I don't ask for changes in those cases. Some use of the term "Classic Service" may also require careful review to c= learly separate it from TCP Standard behavior. Note that some use of the term "Classic TCP" would probably also apply to "= Classic QUIC" once the QUIC standard is finished. To me as a non-native spe= aker, it would be really strange to use the term "classic" in the context o= f a brand-new transport protocol. IMHO in that case the term "classic" woul= d be even more confusing. I also add the TCPM list in CC to ensure consistency. Thanks Michael (with no hat) Von: Wesley Eddy Gesendet: Sonntag, 11. August 2019 07:08 An: tsvwg@ietf.org Betreff: [tsvwg] L4S status tracking I created tickets in the TSVWG "trac" tool in order to help keep track of the individual things that look like they should be addressed in progressing L4S document set: https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&page=3D1 I'll try to update these based on the ongoing discussions, updates, etc., but it will make it very easy if you happen to mention the ticket numbers or some key words in threads and messages, when significant. --_000_CE03DB3D7B45C245BCA0D243277949363069B90DMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Note that I do not object to= the terms „classic ECN“, „legacy ECN“, „lega= cy AQM“ or the like, i.e.,

> if the context is ECN and no= t specifically TCP or the TCP congestion control. I believe it is up to

> the TSVWG do decide if this = term shall be used for compliance to RFC 3168. I have no strong opinion on = that.

> As far as I can see, most us= e of the term „classic“ is in this context and I don’t as= k for changes in those cases.

 

“RFC 3168 ECN= 221; is the more precise term, whose use I would encourage.  Use of &#= 8220;classic ECN” seems ok, as long as the draft makes it clear that = “classic” means “RFC 3168” in this context.

 

Thanks, --David (as an= author of RFC 3168)

 

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Scharf, Michael
Sent: Friday, August 23, 2019 10:01 AM
To: Wesley Eddy; tsvwg@ietf.org
Cc: tcpm@ietf.org
Subject: Re: [tsvwg] L4S status tracking

 

[EXTERNAL EMAIL]

Hi Wes,

 

I’d like to add a smaller i= tem that is mostly editorial and can hopefully be sorted just out by re-wor= ding, albeit it may require a careful analysis of all documents.=

 

As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY= , I object to the terms „traditional TCP“ and also „clas= sic TCP“ or „legacy“ TCP when referring to a TCP implemen= tation according to IETF standards-track RFCs.

 

To me as a non-native native spea= ker, all these terms have a negative connotation. I also think this languag= e is typical to marketing material.

 

My prefered term when referring t= o TCP according to standards-track specification is „standard TCPR= 20;. I would also be fine with other terms as long as they are neutral and = make clear that experiments do not replace, deprecate, or outperform standards.

 

Similarly, I think that term such= as „classic“ is not appropriate for the TCP standard congestio= n control („Reno“). As of today, this is the TCP congestion con= trol algorithm on standards track that has IETF consensus. The term in the TCPM charter is „TCP standard congestion control“.= I also think that terms such as „Reno-compatible“ or the like = would be neutral.

 

Note that I do not object to the = terms „classic ECN“, „legacy ECN“, „legacy AQ= M“ or the like, i.e., if the context is ECN and not specifically TCP = or the TCP congestion control. I believe it is up to the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong op= inion on that. As far as I can see, most use of the term „classicR= 20; is in this context and I don’t ask for changes in those cases.

 

Some use of the term „Class= ic Service“ may also require careful review to clearly separate it fr= om TCP Standard behavior.

 

Note that some use of the term &#= 8222;Classic TCP“ would probably also apply to „Classic QUIC= 220; once the QUIC standard is finished. To me as a non-native speaker, it = would be really strange to use the term „classic“ in the contex= t of a brand-new transport protocol. IMHO in that case the term „class= ic“ would be even more confusing.

 

I also add the TCPM list in CC to= ensure consistency.

 

Thanks

 

Michael (with no hat)<= /span>

 

 

Von: Wesley Eddy
Gesendet: Sonntag, 11. August 2019 07:08
An: tsvwg@ietf.org
Betreff: [tsvwg] L4S status tracking

 

I created tickets in the TSVWG "trac" tool in order t= o help keep track
of the individual things that look like they should be addressed in
progressing L4S document set:

https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&= amp;asc=3D1&page=3D1

I'll try to update these based on the ongoing discussions, updates,
etc., but it will make it very easy if you happen to mention the ticket numbers or some key words in threads and messages, when significant.

--_000_CE03DB3D7B45C245BCA0D243277949363069B90DMX307CL04corpem_-- From nobody Fri Aug 23 08:32:20 2019 Return-Path: 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 082F3120105; Fri, 23 Aug 2019 08:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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.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 cqyV7C_2x_HR; Fri, 23 Aug 2019 08:32:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) (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 232D212004D; Fri, 23 Aug 2019 08:32:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mfd3L66dmH+9OyQe3Uoe9LsswYZofTNyFvq09/t1hzfi/8dQH8/rtkx/kqDaP0RjdtG+f7eqAtSOHgWn6aplTrbLOY/ReMi3686F/Ekk/QojCx+MtYdbDlIz1wF0Y9uPR+RVs6CJKqbweUL3AthjZFE4+CqrxDzKb/yTD+Pz3qQFLvPwC/5gFpYCTN5MtuYyJGC7IqRggLXRUPE6jeAnPsYLkxtLu5LuyGlMhDc1XVoAINcxoFxcKFAmnmxs0LyPVdaGsoimgufEzeYk12dhVsm8Lxkf2icc3J8TY+tUszvkMP3miQJb6HXdI8xaDU8LV8lipQIl1qQjGuqyPN3Gqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmRDvM7jPkwc/vI+nkBhlpMp3vH9MieKEMA7NZdmduc=; b=WTIi+hPEzlUdB7SjOCq0pMW8XUO9EsC4EtYkQ0GqgigZxJQP/cNfh+bC8l1A3d6pvx0+l9qpkmRfqSA8KOWds9XKy+hv+2jYCy8Y2XPoKxm40w4L8iNIfvGDXHUEEQ/vruXcfq8A7lyJSxV97F/DO3/jRrfgQ1SEhfjlOyEp1pmGVnAGHTjYaA2e2GUqDSsoUy8ainhpf8uLs9Pwa8ZhRWCzJ7k/iv7YsAWA6g2OlO76g4jsOFUMjpYYIXJ4TqIb5V+XPcJKbOb6vwaCI/6UuKqU3++STn8Df3ZddkWsP7TWdgyvDaz7cbqSk7GOeClJT1KsZLVP5IOTZPvC/cswuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmRDvM7jPkwc/vI+nkBhlpMp3vH9MieKEMA7NZdmduc=; b=oMO3fTfHXXCVfisheYlhgrFQUEvFJ5n3pfUrlTyQIylNdsgrMgncz6IpBT9Ux+HB8J6CwcTaV5m+9IAYYIuU0OWWa4+LAlOAq4/zfY7RKhnXEzjjBWvOrp4Pr9qdlUGzMWEXnR3q9Bh1S4hMM45rRTQK4gLt4yDnI6lfFoN/PmY= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2347.eurprd07.prod.outlook.com (10.168.127.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.10; Fri, 23 Aug 2019 15:32:06 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::e4a6:7d44:ffe2:7e60]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::e4a6:7d44:ffe2:7e60%12]) with mapi id 15.20.2199.015; Fri, 23 Aug 2019 15:32:06 +0000 From: Mohit Sethi M To: Carles Gomez Montenegro , =?utf-8?B?SWxwbyBKw6RydmluZW4=?= CC: "lwip@ietf.org" , "tcpm@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "kojo@cs.helsinki.fi" Thread-Topic: [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04 Thread-Index: AQHVWcfriFFnLvgljku5nKaIaXNJdA== Date: Fri, 23 Aug 2019 15:32:06 +0000 Message-ID: References: <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu> In-Reply-To: <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [85.131.109.128] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d36715d-c945-4078-6e11-08d727df0e16 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2347; x-ms-traffictypediagnostic: HE1PR0701MB2347: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0138CD935C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(199004)(189003)(14454004)(478600001)(5660300002)(966005)(4326008)(76176011)(476003)(446003)(11346002)(6246003)(2171002)(6116002)(53936002)(31686004)(3846002)(71200400001)(71190400001)(6306002)(2906002)(2616005)(486006)(6512007)(25786009)(36756003)(26005)(53546011)(102836004)(305945005)(6506007)(7736002)(99286004)(186003)(66446008)(86362001)(31696002)(76116006)(66556008)(66946007)(66476007)(64756008)(316002)(110136005)(229853002)(54906003)(65806001)(65956001)(66066001)(6436002)(8676002)(81156014)(6486002)(81166006)(8936002)(14444005)(256004)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2347; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wr9/V/c6qdUgI04f6WxWn6qjLPX9LkaB4a7W7T3bVFW+yRZeKOivm7lfkRVinNK2/TXm3SkNsL56xIMKxkqPZWobXYHjZG55ecuZUAbCU4yIc0eBgJ2IXASSyQgEcTu8Y5KWDN7229b4Yczj2rhi8I2vVAiLVwyQfqLU9A5srlhZA5hWQADex/ytDnCdtjTo3K+XOAvODZX7KW8Uz3rdPp5Yaw49Ap0YCor4c+DY3zJnL5xqW/oNAY/VjgRo1P6YRp1VbjPvjshGI9KUqyHeKBu6FlgDaUUBTuPoM0wRZ/KIXJCTEmUSCgAx+3Hg/Zqm8X7LR8QkEGl8bKZ/Dhwjx8plzyl/rdu7WpJBK5DbzMu59juhobeurjACGhzlpDuamOu7iiN4hZfv7oX6G6wxBeAylJzNxz2LAzP40T9cVX4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0A1C4EF5092F404D986B763A56B3944F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d36715d-c945-4078-6e11-08d727df0e16 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 15:32:06.2936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RHVBkiZsRyWVwfcZq9aMgILc5tyDQFrok+sTL+nyb/873mOy4SgH7zSz94L09PrjiJV/CT9feC4BTis5db80dcWnsMqm66NUUffA6sWge34= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2347 Archived-At: Subject: Re: [tcpm] [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 15:32:13 -0000 SGkgSWxwbyBhbmQgTWFya2t1LA0KDQpDb3VsZCB5b3UgY29uZmlybSB0aGF0IC0wOCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBhZGRyZXNzZXMgYWxsIHlvdXIgDQpjb25jZXJucy4gV2Ugd2lsbCB0aGVu IHNlbmQgaXQgdG8gdGhlIElFU0cgZm9yIHJldmlldy4NCg0KWmhlbiBhbmQgTW9oaXQNCg0KT24g Ni81LzE5IDExOjU4IEFNLCBDYXJsZXMgR29tZXogTW9udGVuZWdybyB3cm90ZToNCj4gSGkgSWxw bywNCj4NCj4gKENDJ2luZyBhbHNvIFRDUE0uKQ0KPg0KPiBGaXJzdCBvZiBhbGwsIHNvcnJ5IGZv ciB0aGUgZGVsYXkgaW4gb3VyIHJlc3BvbnNlLg0KPg0KPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZv ciByZXZpZXdpbmcgdGhlIGRyYWZ0IGFnYWluLCBhbmQgZm9yIGFuc3dlcmluZyBvdXINCj4gcXVl c3Rpb25zLiBZb3VyIGNvbW1lbnRzIGhhdmUgYmVlbiB2ZXJ5IHVzZWZ1bCB0byBpbXByb3ZlIHRo ZSBxdWFsaXR5IG9mDQo+IHRoZSBkb2N1bWVudC4gT3VyIHVwZGF0ZXMgY2FuIGJlIGZvdW5kIGlu IHJldmlzaW9uIC0wOC4NCj4NCj4gUGxlYXNlIGZpbmQgYmVsb3cgb3VyIGlubGluZSByZXNwb25z ZXMgdG8geW91ciBjb21tZW50cy4NCj4NCj4+IE9uIFN1biwgMTAgTWFyIDIwMTksIENhcmxlcyBH b21leiBNb250ZW5lZ3JvIHdyb3RlOg0KPj4NCj4+Pj4gR2VuZXJhbCBDb21tZW50cyAvIFN0cnVj dHVyZQ0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJJ3ZlIHJlYWQgdGhl IGRvY3VtZW50ICgtMDcpIHRocm91Z2ggb25jZSBhZ2FpbiwgYW5kIGluIGdlbmVyYWwgSSBnb3QN Cj4+IGEgZmVlbGluZyB0aGF0IGl0IGhhcyBpbXByb3ZlZCBzdWJzdGFuY2lhbGx5IQ0KPiBUaGFu ayB5b3UhDQo+DQo+Pj4gSW4gdGhlIG5ldyBkcmFmdCB2ZXJzaW9uLCBpbiBzb21lIGNhc2VzLCB3 ZSBoYXZlIHRyaWVkIHRvIGJlIG1vcmUNCj4+PiBzcGVjaWZpYw0KPj4+IChlLmcuID9tZXNzYWdl IG92ZXJoZWFkPywgP21lbW9yeSBvdmVyaGVhZD8sIGV0Yy4pLiBIb3dldmVyLCBpbiBzb21lDQo+ Pj4gb3RoZXINCj4+PiBjYXNlcyB0aGUgY29udGV4dCBtYXkgaGVscCB0byBiZXR0ZXIgZGV0ZXJt aW5lIHRoZSBzY29wZSBvZiA/b3ZlcmhlYWQ/LA0KPj4+IG9yDQo+Pj4gP292ZXJoZWFkPyByZWxh dGVzIHdpdGggYWxsIHRoZSBkaW1lbnNpb25zIHlvdSBsaXN0ZWQgKGFuZCBmb3INCj4+PiBzaW1w bGljaXR5LA0KPj4+IHdlIHByZWZlciB0byBrZWVwIGp1c3QgP292ZXJoZWFkPykuDQo+PiBJIGRp ZG4ndCBmaW5kIHVucXVhbGlmaWVkICJvdmVyaGVhZHMiIGEgcHJvYmxlbSBhbnltb3JlIGVpdGhl ciAodGhhdCBpcywNCj4+IGluIGNhc2UgdGhlcmUgd2VyZSBzb21lIGFzIEkgZGlkbid0IGV2ZW4g bm90aWNlIHRoZW0gYW55bW9yZSkuDQo+IFRoYW5rcyBmb3IgeW91ciBjb25maXJtYXRpb24uDQo+ DQo+Pj4+IFNtYWxsIFBvaW50cw0KPj4+PiAtLS0tLS0tLS0tLS0NCj4+Pj4NCj4+Pj4gU2VjIDMu MiBVc2FnZSBTY2VuYXJpb3MsIDNyZCBwYXJhOiBJIGZhaWwgdG8gZ2V0IHRoZSBwb2ludCBvZiB0 aGlzDQo+Pj4+IHBhcmFncmFwaC4gVGhlcmUgYXJlIHR3byBkaXN0aW5jdCBwb2ludHMgYWJvdXQg dGhlIGVudmlyb25tZW50Og0KPj4+PiBtaWRkbGVib3hlcyBvbiBwYXRoIGFuZCBhc3ltbWV0cnkg aW4gZW5kIHBvaW50IGNhcGFiaWxpdGllcy4gTm8NCj4+Pj4gaW1wbGljYXRpb25zIGFib3V0IGJy aW5naW5nIHRoZXNlIHR3byBpbiBwYXJ0aWN1bGFyIHVwIGluIHRoZSBzYW1lDQo+Pj4+IHBhcmFn cmFwaCBhcmUgbWVudGlvbmVkLiBUaGF0IGlzLCB3aHkgSSBtdXN0IG5vdGUgdGhlIGFzeW1tZXRy eSB3aGVuDQo+Pj4+IHRoZXJlJ3MgYSBtaWRkbGVib3g/DQo+Pj4gQmVjYXVzZSB0aGUgbWlkZGxl Ym94IHdpbGwgb2Z0ZW4gYmUgdHJhbnNwYXJlbnQgdG8gVENQIChidXQgbm90IHRvIG90aGVyDQo+ Pj4gcHJvdG9jb2xzKS4gQmFzaWNhbGx5LCB0aGUgcHJlc2VuY2Ugb2Ygc3VjaCBtaWRkbGVib3hl cyBpcyBhIG1ham9yDQo+Pj4gbW90aXZhdGlvbiBmb3IgdXNlIG9mIFRDUCBpbiBJb1QgZW52aXJv bm1lbnRzIChlLmcuIFJGQyA4MzIzKS4NCj4+IEkgc3RpbGwgZG9uJ3Qgc2VlIHRoZSBjb25uZWN0 aW9uIGJldHdlZW4gYSBtaWRkbGVib3ggcmVxdWlyaW5nIHVzZSBvZg0KPj4gVENQIGFuZCB0aGF0 IEkgbXVzdCBub3RlIGFzeW1tZXRyeSBpbiB0aGUgc2NlbmFyaW8uIEJ1dCB0aGlzIG5vdCBhbGwg dGhhdA0KPj4gaW1wb3J0YW50IHBhcnQgb2YgdGhlIHRleHQgYW55d2F5IHNvIEkgZ3Vlc3MgaXQg Y291bGQgYmUgbGVmdCBsaWtlIHRoYXQuDQo+Pg0KPj4gVGhlcmUncywgaG93ZXZlciwgZHVwbGlj YXRpb24gYmV0d2VlbiB0aGUgMXN0IGFuZCB0aGUgbGFzdCBwYXJhZ3JhcGhzDQo+PiAoYW5kIGFs c28gc29tZXdoYXQgd2l0aCB0aGlzIDNyZCBwYXJhZ3JhcGggdGV4dCBub3cgdGhhdCBJIGxvb2sp Lg0KPiBJbiAtMDgsIHdlIGhhdmUgbWVyZ2VkIHBhcnQgb2YgdGhlIGZpcnN0IGFuZCB0aGUgdGhp cmQgcGFyYWdyYXBoLCB3aGljaA0KPiBoZWxwZWQgcmVkdWNlIHJlZHVuZGFuY3kuIEFmdGVyIHRo aXMgY2hhbmdlLCB3ZSBiZWxpZXZlIHRoYXQgdGhlIGZpcnN0IGFuZA0KPiB0aGUgbGFzdCBwYXJh Z3JhcGhzIChvZiBzZWN0aW9uIDMuMikgZG8gbm90IGNvbnRhaW4gZHVwbGljYXRlZCBjb250ZW50 Lg0KPg0KPj4+PiA0LjMuMiBTQUNLDQo+Pj4+DQo+Pj4+IElNSE8sIFNBQ0sgc2hvdWxkIGJlIHN1 YnNlY3Rpb24gb2YgbG9zcyByZWNvdmVyeSBvciA0LjMuMQ0KPj4+PiBzaG91bGQgYmUgcmV0aXRs ZWQgdG8gb25seSBGUi9GUi4NCj4+PiBZZXMsIHdlIGFncmVlIHdpdGggdGhlIHN1Z2dlc3Rpb24s IGFuZCBwcmVmZXIgdG8gbWFrZSBTQUNLIGEgc3Vic2VjdGlvbg0KPj4+IG9mDQo+Pj4gNC4zLjEu DQo+Pj4NCj4+Pj4gT3V0LW9mLW9yZGVyIHF1ZXVlIGhhbmRsaW5nIGlzIHVucmVsYXRlZCB0byBT QUNLLCBzaG91bGQgYmUNCj4+Pj4gY292ZXJlZCBzb21ld2hlcmUgZWxzZT8gVGhlcmUgaXMgaW1w bGljaXQgY29tcGxleGl0eSAmIFRDQg0KPj4+PiBpbXBhY3Qgd2hlbiB0aGUgZmxvdyBtYXkgaGF2 ZSA+MSBNU1Mgd25kLCBtYXliZSBncm91cCBhbGwgdGhlc2UNCj4+Pj4gKHdoZW4gbm90IHJlbGF0 ZWQgdG8gYSBwYXJ0aWN1bGFyIG1lY2hhbmlzbSB0aGF0IGhhcyBpdHMgb3duDQo+Pj4+IGRpc2N1 c3Npb24gc29tZXdoZXJlKSB1bmRlciBhIHNpbmdsZSBzZWN0aW9uKS4NCj4+PiBOb3Qgc3VyZSBp ZiB0aGUgY3VycmVudCB3b3JkaW5nIG1heSBsZWFkIHRvIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5n cywNCj4+PiBidXQNCj4+PiBvdXQtb2Ytb3JkZXIgaXMgbWVudGlvbmVkIGhlcmUgdG8gZGVub3Rl IHRoZSBmYWN0IHRoYXQgYSBmZXcgc2VnbWVudHMNCj4+PiBtYXkNCj4+PiBiZSBsb3N0IGFuZCB0 aGUgcmVjZWl2ZXIgd2lsbCBuZWVkIHRvIGluZm9ybSBhYm91dCB0aGUgZGF0YSBibG9ja3MNCj4+ PiBhY3R1YWxseSByZWNlaXZlZC4NCj4+ICJUaGUgcmVjZWl2ZXIgc3VwcG9ydGluZyBTQUNLIHdp bGwgbmVlZCB0byBtYW5hZ2VkIHRoZSByZWNlcHRpb24gb2YNCj4+IHBvc3NpYmxlIG91dC1vZi1v cmRlciByZWNlaXZlZCBzZWdtZW50cywgcmVxdWlyaW5nIHN1ZmZpY2llbnQgYnVmZmVyDQo+PiBz cGFjZS4iDQo+Pg0KPj4gVGhpcyB0ZXh0IHNlZW1zIHRvIGltcGx5IHRoYXQgYmVjYXVzZSBvZiBT QUNLLCBtYW5hZ2luZyBvZm8gc2VnbWVudHMgaXMNCj4+IG5lY2Vzc2FyeSBidXQgaXQgaXMgYSBm ZWF0dXJlIHRoYXQgaXMgbmVlZGVkIGFsc28gdy9vIFNBQ0sgd2hlbiBUQ1ANCj4+IHN1cHBvcnRz IG11bHRpLXNlZ21lbnQgd2luZG93LiBTbyBhbnkgbG9zcyByZWNvdmVyeSByZWdhcmRsZXNzIG9m IFNBQ0sNCj4+IHdpbGwgbmVlZCB0byBkZWFsIHdpdGggdGhhdC4gV2hhdCBTQUNLIGFkZHMgdG8g dGhhdCBvbiB0aGUgcmVjZWl2ZXINCj4+IHNpZGUsIGlzIGtlZXBpbmcgdHJhY2sgb2YgdGhlIFNB Q0sgYmxvY2tzIHRvIHNlbmQgYmFjay4NCj4gVGhlIHRleHQgKGFmdGVyIHJlbW92aW5nIHRoZSBT QUNLIG1lbnRpb24pIGlzIG5vdyBiZWZvcmUgdGhlIFNBQ0sNCj4gc3Vic2VjdGlvbi4gV2UgaGF2 ZSBhbHNvIGFkZGVkIHlvdXIgcG9pbnQgb24gdGhlIFNBQ0stc3BlY2lmaWMgdGFza3MgdG8gYmUN Cj4gZG9uZSBieSBhIHJlY2VpdmVyIHN1cHBvcnRpbmcgU0FDSy4NCj4NCj4+Pj4gTm8gc2VuZGVy LXNpZGUgU0FDSyBhc3BlY3QgY292ZXJlZD8NCj4+PiBXZSBjdXJyZW50bHkgaGF2ZToNCj4+PiA/ YSBzZW5kZXIgKGhhdmluZyBwcmV2aW91c2x5IHNlbnQgdGhlIFNBQ0stUGVybWl0dGVkDQo+Pj4g ICAgIG9wdGlvbikgY2FuIGF2b2lkIHBlcmZvcm1pbmcgdW5uZWNlc3NhcnkgcmV0cmFuc21pc3Np b25zLCBzYXZpbmcNCj4+PiAgICAgZW5lcmd5IGFuZCBiYW5kd2lkdGgsIGFzIHdlbGwgYXMgcmVk dWNpbmcgbGF0ZW5jeS4/DQo+Pj4gSXMgdGhlcmUgYW55IHBhcnRpY3VsYXIgYXNwZWN0IHlvdSB0 aGluayBzaG91bGQgYmUgYWRkZWQgPw0KPj4gV2hlbiB0aGUgc2VuZGVyIGdldCBTQUNLIGJsb2Nr cyBmcm9tIHRoZSByZWNlaXZlciBpbiBBQ0tzLCBpdCBuZWVkIHRvDQo+PiBib29ra2VlcCB0aGUg cGVyIHNlcS9zZWdtZW50IHN0YXRlIHRvIGF2b2lkIHNlbmRpbmcgdGhlIHBhcnRpY3VsYXINCj4+ IGRhdGEvc2VnbWVudHMgYWdhaW4gZHVyaW5nIHRoZSByZWNvdmVyeS4NCj4+DQo+PiBCdXQgcGVy aGFwcyB0aGVyZSBqdXN0IGlzbid0IGEgY29udmluY2luZyBJb1Qgc2NlbmFyaW8gZm9yIHRoZSBk ZXZpY2UgdG8NCj4+IGJlIHNlbmRpbmcgZW5vdWdoIGRhdGEgdG8gYmVuZWZpdCBmcm9tIHRoZSBz ZW5kaW5nIHNpZGUgU0FDSyBpbiB0aGUgZmlyc3QNCj4+IHBsYWNlPw0KPiBXZWxsLCBwZXJoYXBz IGluIHNvbWUgY2FzZXMgYSBkZXZpY2UgbWlnaHQga2VlcCBhIHJlbGF0aXZlbHkgbGFyZ2UgZmls ZQ0KPiAoZS5nLiBjb250YWluaW5nIHNlbnNvciByZWFkaW5ncyB0YWtlbiBvdmVyIGEgcmVsYXRp dmVseSBsb25nIHRpbWUNCj4gaW50ZXJ2YWwpLiBGb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNz LCB3ZSBoYXZlIGFkZGVkIHlvdXIgcG9pbnQgb24gdGhlDQo+IHNlbmRlciBuZWVkaW5nIHRvIGJv b2trZWVwIHRoZSBuZWNlc3Nhcnkgc3RhdGUgZm9yIHJlc2VuZGluZyBvbmx5IHRoZQ0KPiBuZWVk ZWQgZGF0YS4NCj4NCj4+Pj4gSW4gZ2VuZXJhbCwgdGhlcmUncyBvY2Nhc3Npb25hbGx5IGNvbmZ1 c2lvbiB3aXRoaW4gdGhlIGRvY3VtZW50DQo+Pj4+IHdoZXRoZXIgc29tZSBhZHZpY2UvZGVzY3Jp cHRpb24gaXMgZm9yIHRoZSByZWNlaXZpbmcgb3Igc2VuZGluZw0KPj4+PiBzaWRlICh0aGlzIGlz IG9mIGNvdXJzZSBzY2VuYXJpbyBkZXBlbmRhbnQgd2hpY2ggdGhlIGltcGxlbWVudGVyDQo+Pj4+ IHNob3VsZCBjb25zaWRlciBpbiBoaXMvaGVyIG93biBjYXNlIGJ1dCB0aGUgZG9jdW1lbnQgc2hv dWxkIGNvdmVyDQo+Pj4+IGJvdGggY2FzZXMgd2hlcmUgYXBwbGljYWJsZSkuDQo+Pj4gV2U/ZCB3 ZWxjb21lIHNwZWNpZmljIHN1Z2dlc3Rpb25zIG9mIGRvY3VtZW50IHNlY3Rpb25zIHdoZXJlIHlv dXINCj4+PiBjb21tZW50DQo+Pj4gYXBwbGllcy4NCj4+IFNvbWVob3csIEkgZGlkbid0IGdldCBh IHNpbWlsYXIgZmVlbGluZyBhbnltb3JlIHNvIEkgZ3Vlc3Mgc29tZSBvZg0KPj4gZWRpdHMgaGF2 ZSBkb25lIGVub3VnaCB0byByZXNvbHZlIHNlbmRlci9yZWNlaXZlciBhbWJpZ3VpdHkgYmVsb3cN Cj4+IG5vdGljYWJsZSBsZXZlbCENCj4gVGhhbmtzIGZvciB5b3VyIGNvbmZpcm1hdGlvbi4NCj4N Cj4+IEhlcmUgYXJlIHNvbWUgYWRkaXRpb25hbCBjb21tZW50cyB0aGF0IEkgbm90ZWQgd2hpbGUg cmVhZGluZyBpdCB0aHJvdWdoDQo+PiBmb3IgdGhlIHNlY29uZCB0aW1lOg0KPj4NCj4+IDQuMS4y IEVDTg0KPj4NCj4+IDNyZCBwYXJhLiBUaGVyZSBpcyBhbiB1bnJlc29sdmVkIGNvbnRyYWRpdGlv biByZWxhdGVkIHRvICJ0aHJvdWdocHV0Ig0KPj4gaW4gdGhlIHBhcmFncmFwaCAobm9uZSBvZiB0 aGUgdGV4dCBpcyAid3JvbmciIHBlciBzZSBidXQgdGhlIGRvdHMganVzdA0KPj4gZG9uJ3Qgc2Vl bSB0byBjb25uZWN0IHdlbGwgZW5vdWdoIHRvIG1ha2Ugc2Vuc2UpLiBFQ04gd2l0aCAxIHNlZ21l bnQgaXMNCj4+IHNhaWQgdG8gInJlc3VsdCBpbiB2ZXJ5IGxvdyB0aHJvdWdocHV0IiBhbmQgaW4g dGhlIHZlcnkgbmV4dCBzZW50ZW5jZSBpdA0KPj4gaXMgc2FpZCAiSW4gYWRkaXRpb24gdG8gYmV0 dGVyIHRocm91Z2h0cHV0Li4uIi4gTmVpdGhlciBpcyBpbmNvcnJlY3QgYnV0DQo+PiBJIHdvdWxk bid0IHB1dCB0aG9zZSBzdGF0ZW1lbnRzIG5leHQgdG8gZWFjaCBvdGhlciB0byBhdm9pZCBjb25m dXNpb24NCj4+IGl0IGVhc2lseSBjYXVzZXMuDQo+IFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBv dXQuIE1hcmtrdSBwcm9wb3NlZCBuZXcgdGV4dCB0aGF0IHNvbHZlcyB0aGUNCj4gcHJvYmxlbS4g VGhhdCB0ZXh0IGlzIG5vdyBpbmNsdWRlZCBpbiAtMDguDQo+DQo+PiBTZWN0aW9uIDQuMg0KPj4N Cj4+ICJzaW5nbGUtTVNTIiwgSSdkIHVzZSAic2luZ2xlIHNlZ21lbnQiIChsaWtlIHRoZSBjaGFu Z2UgeW91IG1hZGUgaW50bw0KPj4gdGhlIGFubmV4IHRhYmxlKSB0aHJvdWdob3V0IHRoZSBkb2N1 bWVudC4NCj4gRG9uZS4NCj4NCj4+IFRoZSB1c2Ugb2YgInN0YWNrIiBpbiB0aGUgNC4yIGFuZCBp dHMgc3Vic2VjdGlvbnMgd291bGQgYmUgYmV0dGVyIGFzDQo+PiAid2luZG93IiBiZWNhdXNlIHNv bWUgb2YgdGhlIHRleHQgYXBwbGllcyBhbHNvIHRvIHRoZSB1bmNvbnN0cmFpbmVkDQo+PiBlbmQg b2YgdGhlIGNvbm5lY3Rpb24gdGhhdCBpcyBub3QgYSBzaW5nbGUgbXNzL3NlZ21lbnQgc3RhY2sN Cj4+IGJ1dCBpcyBvbmx5IGNvbW11bmljYXRpbmcgd2l0aCBzdWNoIGEgc3RhY2suDQo+IFdlIHNl ZSB5b3VyIHBvaW50IGFuZCB3ZSBoYXZlIHJlcGxhY2VkIOKAnHN0YWNr4oCdIHdpdGgg4oCcd2lu ZG934oCdIGluIHNvbWUNCj4gaW5zdGFuY2VzLiBIb3dldmVyLCBpbiBzb21lIGNhc2VzIOKAnHN0 YWNr4oCdIHdhcyBhY3R1YWxseSBpbnRlbmRlZCBhcw0KPiDigJxpbXBsZW1lbnRhdGlvbuKAnSwg dGhlcmVmb3JlIGluIHRob3NlIGNhc2VzIHdlIGhhdmUgbGVmdCDigJxzdGFja+KAnQ0KPiB1bm1v ZGlmaWVkLg0KPg0KPj4gU2VjdGlvbiA0LjIuNA0KPj4NCj4+IDJuZCBwYXJhLiAiY2Fubm90IHVz ZSIgLT4gImNhbm5vdCBiZW5lZml0IGZyb20iLiBJdCBpcyBwb3NzaWJsZQ0KPj4gdG8gInVzZSIg YnV0IG5vIGJlbmVmaXRzIGNhbiBiZSBnYWluZWQuIEl0J3MgcmVsZXZhbnQgaW4gcGFydGljdWxh cg0KPj4gd2hlbiB0aGUgY29ubmVjdGlvbiBpcyBvbmUgc2VnbWVudCBidXQgdGhlIHNlbmRlciBp cyB1bmNvbnN0cmFpbmVkLA0KPj4gdGhlIHRleHQgbm93IGV4Y2x1ZGVzIHRoaXMgdmFsaWQgc2Nl bmFyaW8gYnkgYWRkaW5nICJ0aGFuIGZvciBhIG1vcmUNCj4+IHBvd2VyZnVsIFRDUCBzdGFjayIg YnV0IGl0IHNob3VsZG4ndCwgSU1ITy4NCj4gQWdyZWVkLg0KPg0KPj4gTml0czoNCj4+DQo+PiBJ biB0aGUgcGRmIHZlcnNpb24sIHRoZSAiU3Vic2VjdGlvbiB4LngueCIgbWV0YSBsaW5rYWdlIGRv ZXMgYmVnaW4NCj4+IG9ubHkgZnJvbSAic2VjdGlvbiIuDQo+IFBlcmhhcHMgdGhpcyBpcyBzb21l dGhpbmcgdGhhdCBtaWdodCBiZSBzb2x2ZWQgYXQgdGhlIFJGQyBlZGl0b3Igc3RhZ2UuLi4NCj4N Cj4+IFNlY3Rpb24gNS4yIDJuZCBwYXJhOiBjb21zdW1pbmcgLT4gY29uc3VtaW5nDQo+IERvbmUu DQo+DQo+IE9uY2UgYWdhaW4sIHRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIGFsbCB5b3VyIGZlZWRi YWNrIQ0KPg0KPiBDaGVlcnMsDQo+DQo+IENhcmxlcyAob24gYmVoYWxmIG9mIGFsbCBjb2F1dGhv cnMpDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEx3aXAgbWFpbGluZyBsaXN0DQo+IEx3aXBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sd2lwDQoNCg== From nobody Wed Aug 28 02:55:30 2019 Return-Path: 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 821E51200B4; Wed, 28 Aug 2019 02:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.helsinki.fi 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 QTPdqpzyMpJL; Wed, 28 Aug 2019 02:55:26 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CC2120096; Wed, 28 Aug 2019 02:55:25 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 28 Aug 2019 12:55:16 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=5gwaDTTYrx1qgHnZf 6DH4HY93jUOHbWeMwf0BmpKEtY=; b=ATdBwHgiPoZhBtz8nFDx2L0VBKL33VWv1 N1/7Y0b3+8rqNfDQJTAR7hk04u3n73NjIRrdMl6lqCR3xB4nFARA9A5UAZyNZvmt gnvuzU9lAVPqim/lGbSKyP2zXlEn9F1LlGm+grnE9t6rFxYGOxjbXTuSdDi+nh/h l5uWMKcZJc= Received: from dx6-cs-02.pc.helsinki.fi (dx6-cs-02.pc.helsinki.fi [193.167.160.58]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Wed, 28 Aug 2019 12:55:16 +0300 id 00000000005A0146.000000005D664F84.000047AC Date: Wed, 28 Aug 2019 12:55:16 +0300 (EEST) From: Markku Kojo X-X-Sender: kojo@dx6-cs-02.pc.helsinki.fi To: Mohit Sethi M cc: Carles Gomez Montenegro , "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" , "lwip@ietf.org" , "tcpm@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" In-Reply-To: Message-ID: References: <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-18416-1566986116-0001-2" Archived-At: Subject: Re: [tcpm] [Lwip] Review ofdraft-ietf-lwig-tcp-constrained-node-networks-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 09:55:30 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-18416-1566986116-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mohit, all, I've missed this reply, sorry. I'll have a look at it this week. Thanks, /Markku On Fri, 23 Aug 2019, Mohit Sethi M wrote: > Hi Ilpo and Markku, > > Could you confirm that -08 version of the draft addresses all your > concerns. We will then send it to the IESG for review. > > Zhen and Mohit > > On 6/5/19 11:58 AM, Carles Gomez Montenegro wrote: >> Hi Ilpo, >> >> (CC'ing also TCPM.) >> >> First of all, sorry for the delay in our response. >> >> Thank you very much for reviewing the draft again, and for answering o= ur >> questions. Your comments have been very useful to improve the quality = of >> the document. Our updates can be found in revision -08. >> >> Please find below our inline responses to your comments. >> >>> On Sun, 10 Mar 2019, Carles Gomez Montenegro wrote: >>> >>>>> General Comments / Structure >>>>> ---------------------------- >>> I've read the document (-07) through once again, and in general I got >>> a feeling that it has improved substancially! >> Thank you! >> >>>> In the new draft version, in some cases, we have tried to be more >>>> specific >>>> (e.g. ?message overhead?, ?memory overhead?, etc.). However, in some >>>> other >>>> cases the context may help to better determine the scope of ?overhea= d?, >>>> or >>>> ?overhead? relates with all the dimensions you listed (and for >>>> simplicity, >>>> we prefer to keep just ?overhead?). >>> I didn't find unqualified "overheads" a problem anymore either (that = is, >>> in case there were some as I didn't even notice them anymore). >> Thanks for your confirmation. >> >>>>> Small Points >>>>> ------------ >>>>> >>>>> Sec 3.2 Usage Scenarios, 3rd para: I fail to get the point of this >>>>> paragraph. There are two distinct points about the environment: >>>>> middleboxes on path and asymmetry in end point capabilities. No >>>>> implications about bringing these two in particular up in the same >>>>> paragraph are mentioned. That is, why I must note the asymmetry whe= n >>>>> there's a middlebox? >>>> Because the middlebox will often be transparent to TCP (but not to o= ther >>>> protocols). Basically, the presence of such middleboxes is a major >>>> motivation for use of TCP in IoT environments (e.g. RFC 8323). >>> I still don't see the connection between a middlebox requiring use of >>> TCP and that I must note asymmetry in the scenario. But this not all = that >>> important part of the text anyway so I guess it could be left like th= at. >>> >>> There's, however, duplication between the 1st and the last paragraphs >>> (and also somewhat with this 3rd paragraph text now that I look). >> In -08, we have merged part of the first and the third paragraph, whic= h >> helped reduce redundancy. After this change, we believe that the first = and >> the last paragraphs (of section 3.2) do not contain duplicated content= . >> >>>>> 4.3.2 SACK >>>>> >>>>> IMHO, SACK should be subsection of loss recovery or 4.3.1 >>>>> should be retitled to only FR/FR. >>>> Yes, we agree with the suggestion, and prefer to make SACK a subsect= ion >>>> of >>>> 4.3.1. >>>> >>>>> Out-of-order queue handling is unrelated to SACK, should be >>>>> covered somewhere else? There is implicit complexity & TCB >>>>> impact when the flow may have >1 MSS wnd, maybe group all these >>>>> (when not related to a particular mechanism that has its own >>>>> discussion somewhere) under a single section). >>>> Not sure if the current wording may lead to different understandings= , >>>> but >>>> out-of-order is mentioned here to denote the fact that a few segment= s >>>> may >>>> be lost and the receiver will need to inform about the data blocks >>>> actually received. >>> "The receiver supporting SACK will need to managed the reception of >>> possible out-of-order received segments, requiring sufficient buffer >>> space." >>> >>> This text seems to imply that because of SACK, managing ofo segments = is >>> necessary but it is a feature that is needed also w/o SACK when TCP >>> supports multi-segment window. So any loss recovery regardless of SAC= K >>> will need to deal with that. What SACK adds to that on the receiver >>> side, is keeping track of the SACK blocks to send back. >> The text (after removing the SACK mention) is now before the SACK >> subsection. We have also added your point on the SACK-specific tasks t= o be >> done by a receiver supporting SACK. >> >>>>> No sender-side SACK aspect covered? >>>> We currently have: >>>> ?a sender (having previously sent the SACK-Permitted >>>> option) can avoid performing unnecessary retransmissions, saving >>>> energy and bandwidth, as well as reducing latency.? >>>> Is there any particular aspect you think should be added ? >>> When the sender get SACK blocks from the receiver in ACKs, it need to >>> bookkeep the per seq/segment state to avoid sending the particular >>> data/segments again during the recovery. >>> >>> But perhaps there just isn't a convincing IoT scenario for the device = to >>> be sending enough data to benefit from the sending side SACK in the f= irst >>> place? >> Well, perhaps in some cases a device might keep a relatively large fil= e >> (e.g. containing sensor readings taken over a relatively long time >> interval). For the sake of completeness, we have added your point on t= he >> sender needing to bookkeep the necessary state for resending only the >> needed data. >> >>>>> In general, there's occassionally confusion within the document >>>>> whether some advice/description is for the receiving or sending >>>>> side (this is of course scenario dependant which the implementer >>>>> should consider in his/her own case but the document should cover >>>>> both cases where applicable). >>>> We?d welcome specific suggestions of document sections where your >>>> comment >>>> applies. >>> Somehow, I didn't get a similar feeling anymore so I guess some of >>> edits have done enough to resolve sender/receiver ambiguity below >>> noticable level! >> Thanks for your confirmation. >> >>> Here are some additional comments that I noted while reading it throu= gh >>> for the second time: >>> >>> 4.1.2 ECN >>> >>> 3rd para. There is an unresolved contradition related to "throughput" >>> in the paragraph (none of the text is "wrong" per se but the dots jus= t >>> don't seem to connect well enough to make sense). ECN with 1 segment = is >>> said to "result in very low throughput" and in the very next sentence = it >>> is said "In addition to better throughtput...". Neither is incorrect = but >>> I wouldn't put those statements next to each other to avoid confusion >>> it easily causes. >> Thanks for pointing this out. Markku proposed new text that solves the >> problem. That text is now included in -08. >> >>> Section 4.2 >>> >>> "single-MSS", I'd use "single segment" (like the change you made into >>> the annex table) throughout the document. >> Done. >> >>> The use of "stack" in the 4.2 and its subsections would be better as >>> "window" because some of the text applies also to the unconstrained >>> end of the connection that is not a single mss/segment stack >>> but is only communicating with such a stack. >> We see your point and we have replaced =E2=80=9Cstack=E2=80=9D with =E2= =80=9Cwindow=E2=80=9D in some >> instances. However, in some cases =E2=80=9Cstack=E2=80=9D was actually = intended as >> =E2=80=9Cimplementation=E2=80=9D, therefore in those cases we have lef= t =E2=80=9Cstack=E2=80=9D >> unmodified. >> >>> Section 4.2.4 >>> >>> 2nd para. "cannot use" -> "cannot benefit from". It is possible >>> to "use" but no benefits can be gained. It's relevant in particular >>> when the connection is one segment but the sender is unconstrained, >>> the text now excludes this valid scenario by adding "than for a more >>> powerful TCP stack" but it shouldn't, IMHO. >> Agreed. >> >>> Nits: >>> >>> In the pdf version, the "Subsection x.x.x" meta linkage does begin >>> only from "section". >> Perhaps this is something that might be solved at the RFC editor stage= ... >> >>> Section 5.2 2nd para: comsuming -> consuming >> Done. >> >> Once again, thank you very much for all your feedback! >> >> Cheers, >> >> Carles (on behalf of all coauthors) >> >> _______________________________________________ >> Lwip mailing list >> Lwip@ietf.org >> https://www.ietf.org/mailman/listinfo/lwip > > --=_script-18416-1566986116-0001-2-- From nobody Wed Aug 28 04:53:59 2019 Return-Path: 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 7DFDD12011D; Wed, 28 Aug 2019 04:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 CMMqu8R7GXXl; Wed, 28 Aug 2019 04:53:49 -0700 (PDT) Received: from smtp-rs2-vallila1.fe.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) (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 17D89120114; Wed, 28 Aug 2019 04:53:48 -0700 (PDT) Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) by smtp-rs2.it.helsinki.fi (8.14.7/8.14.7) with ESMTP id x7SBrb6r035546; Wed, 28 Aug 2019 14:53:37 +0300 Received: by whs-18.cs.helsinki.fi (Postfix, from userid 1070048) id 2587336013E; Wed, 28 Aug 2019 14:53:37 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by whs-18.cs.helsinki.fi (Postfix) with ESMTP id 1F36636007C; Wed, 28 Aug 2019 14:53:37 +0300 (EEST) Date: Wed, 28 Aug 2019 14:53:37 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Mohit Sethi M cc: Carles Gomez Montenegro , "lwip@ietf.org" , "tcpm@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "kojo@cs.helsinki.fi" In-Reply-To: Message-ID: References: <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 11:53:52 -0000 On Fri, 23 Aug 2019, Mohit Sethi M wrote: > Hi Ilpo and Markku, > > Could you confirm that -08 version of the draft addresses all your > concerns. We will then send it to the IESG for review. For me, no major concerns remaining. A few minor points from the text edited in -08. The "pure ACK" might be better to write open, e.g., "ACK without payload". The current text in FR/FR scenario with 1-6 segment might confuse as the sixth segment is only sent out on the first (duplicate) ACK. The current wording makes it to sound as if 1-6 would be outstanding right at the beginning (instead of first 1-5 and then 2-6 after the ACK). "plus two additional segments for each one of the first two duplicate ACKs." I think this might be misinterpreted to mean 2*2 segments. -- i. From nobody Wed Aug 28 08:21:08 2019 Return-Path: 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 BB74F120043 for ; Wed, 28 Aug 2019 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 BM0bgp_7OKDn for ; Wed, 28 Aug 2019 08:21:04 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6E12000F for ; Wed, 28 Aug 2019 08:21:03 -0700 (PDT) Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8AC601B000A3; Wed, 28 Aug 2019 16:20:58 +0100 (BST) Message-ID: <5D669BDA.3000506@erg.abdn.ac.uk> Date: Wed, 28 Aug 2019 16:20:58 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:21:07 -0000 I promised to provide review comments for rev 14 of RFC 793 bis. This review comes in two parts, the first (this) contains what I think are mostly editorial issues and questions about document style for a document to be published in 2020. best wishes, Gorry --- Document Style Parts of this document still has a quant old-fashioned style, somnetimes degenerating into weirdness. I think more needs to be done to bring this document into the current century. See comments below: --- I was amused at the frequent reference to "crash" or "crashing". I'm not sure that presents the correct view of the IETf about the stability of the TCP stack and certainly is not what IO would expect in an RFC that could be promoted to full standard. I think this needs to be changed. e.g. "TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing;" could I suggest be: "TCP MUST be prepared to handle an illegal option length (e.g., zero);" and this "even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. " could be: "even if a TCP implementation loses knowledge of the sequence numbers it has been using." etc --- OLD: on some machines - if still relevant, I suggest: NEW: in some implementation architectures --- OLD: foreign socket NEW: remote socket - e.g. (a) general information about a connection (e.g., interrupts, remote close, binding of unspecified foreign socket). - what is a foreign socket in modern language - is that a remote peer? - there are other examples, but also later: OLD: If no foreign socket was specified in the OPEN, but the connection is established (e.g., because a LISTENing connection has become specific due to a foreign segment arriving for the local socket), then the designated buffer is sent to the implied foreign socket. Users who make use of OPEN with an unspecified foreign socket can make use of SEND without ever explicitly knowing the foreign socket address. - what is a foreign segment? - and I'm not entirely sure what is mean by a foreign socket address. --- The security-related text "IP security level and compartment of the connection" Appendix - OLD: there has been discussion about ammending the TCP specification to prevent connections from being aborted due to non-matching IP security compartment and DiffServ codepoint values. - Is this statement correct? I'm not aware of the Diffserv discussion being current, and thought (although could be corrected if someone provides refs) that the current proactive was not to verify the DSCP? - This adds unnecessary and unusual terminology to reading the document. In 3.2.1 it's a spurious example and this and it's cross reference could be omitted to increase clarity. I'd also suggest removal from the core of the document the related text in section 3.4, etc. This could all be consolidated in appendix A1 - if this is required for other Specs. The para in section 3.6 starting: The IP security option (IPSO) and compartment defined in [1] was refined in RFC 1038 that was later obsoleted by RFC 1108. - This also appears in pseudo code on page 70 (weird) - I suggest all text (if retained) belongs to this appendix. +++++++++++++++++++++++++++++++++++++++++++++ Editorial comments on the remaining text: --- OLD: A number of enhancements has NEW: The number of enhancements has --- OLD: TCP reliability consists of detecting packet losses (via sequence numbers) and errors (via per-segment checksums), as well as correction of losses and errors via retransmission. - I think this makes it appears that errors are somehow different to loss, and they are not. I suggest we just say "loss". ---- OLD: Data flow is supported bidirectionally over TCP connections, though applications are free to flow data only unidirectionally, - "flow data only" reads weird, can we say send payload data or something? --- OLD: If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. - Punctuation? NEW: If the ACK control bit is set, this field contains the value of the next sequence number that the sender of the segment is expecting to receive. Once a connection is established, this is always sent. --- multiple OLD: " which" - in all cases I found this is not the correct word, should it be " that", or ", which". --- multiple OLD: "remote TCP" - I found that a little odd, and does not expand the acconym, could we replace by "remote TCP endpoint" or "remote TCP peer". --- multiple OLD: "TCPs" and "a TCP" - This use of a "TCP" as an entity read as very ugly to me. I had to read the sentences several times to parse them, could we explain that we mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually this seems to mean implementation). --- OLD: When simultaneous attempt occurs, - I think the current term is simultaneous open. NEW: When simultaneous open occurs, --- OLD: An "XXX" indicates a segment which is lost or rejected. - rejected seems odd here. NEW: An "XXX" indicates a segment that is lost (not processed by the receiving TCP endpoint). --- OLD: has been devised. - weird word? NEW: is specified. --- OLD: SYN (pun intended) - I didn't see the pun, can this be explained or omitted? --- OLD: procedure is mildy involved - weird, or explain NEW: procedure is triggered. --- Section 3.5 OLD: until he is NEW: until the TCP receiver is --- Section 3.5 OLD: the other side NEW: the remote TCP peer --- OLD: Avoiding sending segments larger than the smallest MTU within an IP network path, because this results in either packet loss or fragmentation. NEW: Avoiding sending a TCP segment that would result in an I{P datagram larger than the smallest MTU along an IP network path, because this results in either packet loss or packet fragmentation. --- Section 3.8 OLD: retransmission (after a timeout) - move timeout, since this is no longer the norm. NEW: retransmission --- OLD: In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes. - not numbered as a MUST. --- (seventh step) OLD: an push flag NEW: a push flag --- OLD: IF our FIN NEW: If the FIN segment --- OLD: port The portion of a socket that specifies which logical input or output channel of a process is associated with the data. - The definition of "port" appears to be in terms of "socket" which it should not be. - What is a channel etc. This needs redefined in modern language. --- OLD: internet address A source or destination address specific to the host level. NEW: internet address The network layer address. --- OLD: Source Address The source address, usually the network and host identifiers. NEW: Source Address The network layer address of the sending endpoint. --- OLD: Destination Address The destination address, usually the network and host identifiers. NEW: Destination Address The network layer address of the remote endpoint. --- OLD (TOS): containing the Differentiated Services Code Point (DSCP) value and two unused bits. NEW: containing the Differentiated Services Code Point (DSCP) value and the 2-bit ECN codepoint [RFC3168]. --- OLD: The "tcpcrypt" [45]Experimental - insert space OLD: The "tcpcrypt" [45] Experimental --- OLD: like Appropriate Byte Counting (ABC) - Please Insert reference to ABC - RFC3465. --- OLD: * Urgent pointer advance (see Section 3.8.5) (MUST-32). - This is no requirement here. --- OLD: Error responses are given as character strings. - What does that mean? and how are these strings specified - unicode, ascii? - I suspect the present intention is that: NEW: Error responses in this document are identified by character strings. +++++++++++++++++++++++++ From nobody Wed Aug 28 08:39:57 2019 Return-Path: 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 766D61200E6 for ; Wed, 28 Aug 2019 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 cDGCKGoGvXWs for ; Wed, 28 Aug 2019 08:39:52 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 411FC12000F for ; Wed, 28 Aug 2019 08:39:52 -0700 (PDT) Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E15531B00067; Wed, 28 Aug 2019 16:39:48 +0100 (BST) Message-ID: <5D66A044.3060904@erg.abdn.ac.uk> Date: Wed, 28 Aug 2019 16:39:48 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk CC: "tcpm@ietf.org" References: <5D669BDA.3000506@erg.abdn.ac.uk> In-Reply-To: <5D669BDA.3000506@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:39:56 -0000 I promised to provide review comments for rev 14 of RFC 793 bis. This review comes in two parts, the second (this) contains what I think are issues and questions about how to express the document intention. best wishes, Gorry --- Technical Issues. --- Section 2 - OLD: Anycast applications exist that successfully use TCP without modifications, though there is some risk of instability due to rerouting. - Why "rerouting" rather than any other "change of forwarding behaviour", I'd have expected this for instance after an ECMP rehash, or any L2 policy change. --- Section 3 - OLD: Reserved for future use. Must be zero in generated segments and must be ignored in received segments, if corresponding future features are unimplemented by the sending or receiving host. - why is this not an RFC2119 requirement to set and check the reserve fields, this would seem much more normal and the receiver behaviour at least is required? --- Section 3 - OLD: If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. - why is this not an RFC2119 requirement to insert the padding, this seems required for correctness? --- OLD: This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. - this seems like a RFC2119 "MAY", since it specifies permission to include this. --- OLD: There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary. - this seems like a RFC2119 "MUSR", since it specifies requirement to process this. --- Section 3.1- OLD (on MSS): This field may be sent in the initial connection request (i.e., in segments with the SYN control bit set) and must not be sent in other segments. -this seems like a RFC2119 "MUST NOT", since it specifies this as illegal. --- OLD: However, even when the receive window is zero, a TCP must process the RST and URG fields of all incoming segments. -- arguably a RFC2119 "MUST", since it specifies a requirement. NEW: A TCP receiver MUST process the RST and URG fields of all incoming segments, even when the receive window is zero. --- OLD, Section: " Initial Sequence Number Selection" - This I think needs to refer to "Defending against Sequence Number Attacks" in RFC 6528, which formally updated RFC793. I question - if the RFC793 text is safe and correct. - In reviewing this, please also fix "cryptographic has of the concatenation" --- OLD, Section: " The TCP Quiet Time Concept" - Found this section quite amusing. Is this concept widely implemented in stacks? - The examples given need updated, for instance one example starts "At 2 megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line of thinking becomes problematic. - There is an odd sentence that states: "In the absence of knowledge about the sequence numbers used on a particular connection, the TCP specification recommends that the source delay for MSL seconds before emitting segments on the connection, to allow time for segments from the earlier connection incarnation to drain from the system." - how would the "source" know the MSL rather than use the Internet default? - To me, this section raises many questions about whether this is best current practice. --- OLD: As a general rule, reset (RST) must be sent whenever... - I can't fathom what was intended, isn't this a RFC2119 SHOULD? --- OLD: SYNs addressed to a non-existent connection are rejected by this means. - Is that a complicated way of saying an RST is sent, or is it something else, please clarify, is the word "addressed" correct here? Could this be rewritten as a "SYN segment that does not match an existing connection..." - This then leads me to ask why this does not refer to SYN cookies? --- OLD: any unacceptable segment (out of window sequence number or unacceptable acknowledgment number) must elicit only an empty acknowledgment segment containing - what does "elicit" mean here and what is an empty ACK segment? --- OLD: We assume that the TCP will signal a user, even if no RECEIVEs are outstanding, that the other side has closed, so the user can terminate his side gracefully. - what is this about? - is the language of single user appropriate? and what does gracefully actually mean? --- OLD: Users must keep reading connections they close for sending until the TCP says no more data. - Is that specifying application behaviour? and how does it "say", please rephrase. --- OLD: The MSS value to be sent in an MSS option must be less than or equal to: - is this a RFC2119 requirement? --- OLD: As a result, when the effective MTU of an interface varies, TCP SHOULD use the smallest effective MTU of the interface to calculate the value to advertise in the MSS option (SHLD-6). - what does "varies" mean here? The MSS is computed when the SYN is exchanged is this actually just: NEW: When multiple IP interfaces have different effective MTUs, TCP SHOULD use the smallest effective MTU of the interface to calculate the value to advertise in the MSS option (SHLD-6). --- OLD: 3.7.5. IPv6 Jumbograms In order to support TCP over IPv6 jumbograms, implementations need to be able to send TCP segments larger than the 64KB limit that the MSS option can convey. RFC 2675 [6] defines that an MSS value of 65,535 bytes is to be treated as infinity, and Path MTU Discovery [3] is used to determine the actual MSS. - This was discussed in the 6Man WG in Montreal, and while there was no consensus reached to obsolete jumbograms, there was encouragement to ensure that specs describe jumbo grams appropriate, rather than suggesting support is required. In this sense, I recommend adding something like: NEW: The Jumbo Payload option need not be implemented or understood by IPv6 nodes that do not support attachment to links with a MTU greater than 65,575 [RFC2675], and the present IPv6 Node Requirements does not include support for Jumbograms [RFC8504]. --- Section 3.8.1 OLD: If a retransmitted packet is identical to the original packet (which implies not only that the data boundaries have not changed, but also that the window and acknowledgment fields of the header have not changed), then the same IP Identification field MAY be used (see Section 3.2.1.5 of RFC 1122) (MAY-4). - What is this MAY about? Is it about the IPv4 IPID field and is that really important for a TCP spec? --- Section 3.8.3 OLD: pass negative advice (see [14] Section 3.3.1.4) to the IP layer, to trigger dead-gateway diagnosis. - Is this still best current practice? - If so please explain and cite RFCs. --- OLD: (e) TCP SHOULD inform the application of the delivery problem (unless such information has been disabled by the application; see Asynchronous Reports section), when R1 is reached and before R2 (SHLD-9). This will allow a remote login (User Telnet) application program to inform the user, for example. - Is this still best current practice? - If so please is there a ref?. --- OLD: (e) TCP SHOULD inform the application of the delivery problem (unless such information has been disabled by the application; see Asynchronous Reports section), when R1 is reached and before R2 (SHLD-9). This will allow a remote login (User Telnet) application program to inform the user, for example. - Is this still best current practice? --- OLD: The value of R1 SHOULD correspond to at least 3 retransmissions, at the current RTO (SHLD-10). The value of R2 SHOULD correspond to at least 100 seconds (SHLD-11). - Is this still best current practice? --- Section 3.8.6.3 Delayed ACK. OLD: and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment (SHLD-19). - Delayed ACK is specified in RFC1122 as: "...and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment." Although correct, this does not specify a behaviour when segments are not "full-sized". When asked by people, I have think this should be something like: NEW: "the receiver SHOULD send an ACK when the data needing acknowledgment corresponds to no more than two full-sized (MSS) segments." --- Section 3.9 - Section 3.1 of RFC8303 also identifies primitives provided by TCP and could be used as a an additional reference to the primitives outside of the stylised version presented in RFC793. --- OLD: We assume that the local TCP is aware of the identity of the processes it serves and will check the authority of the process to use the connection specified.... These considerations are the result of concern about security, to the extent that no TCP be able to masquerade as another one, and so on. Similarly, no process can masquerade as another without the collusion of the TCP. - Is this still meaningful. What does "aware of the identity" mean? and what does the stack will "check the authority" mean? - I don't6 have a clue what "no TCP be able to masquerade as another one" means. - Please supply text of remove this. --- OLD: set includes experimental options that can be extended to support multiple concurrent uses [34]. and OLD: A TCP that supports multiple concurrent users MUST provide an OPEN call that will functionally allow an application to LISTEN on a port while a connection block with the same local port is in SYN-SENT or SYN-RECEIVED state (MUST-42). - what does this mean in today's process architecture with off-loading, multiple cores etc? - I think the requirement remains, but the text needs changed. --- OLD: Any other control or text-bearing segment (not containing SYN) must have an ACK and thus would be discarded by the ACK processing. An incoming RST segment could not be valid, since it could not have been sent in response to anything sent by this incarnation of the connection. So you are unlikely to get here, but if you do, drop the segment, and return. - what is a text bearing segment? - "So you are unlikely to get here, but if you do," ... sounds like a source code comment rather than a spec in 2020! ---