From nobody Fri Nov 1 16:39:46 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 94153120074; Fri, 1 Nov 2019 16:39:36 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157265157653.31860.1480050311768258768@ietfa.amsl.com> Date: Fri, 01 Nov 2019 16:39:36 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-06.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: Fri, 01 Nov 2019 23:39:37 -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 : RACK: a time-based fast loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-06.txt Pages : 29 Date : 2019-11-01 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-06 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-06 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 Fri Nov 1 16:55:55 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 D6DAA12012A for ; Fri, 1 Nov 2019 16:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SyCc12u9Z2gW for ; Fri, 1 Nov 2019 16:55:52 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 58E5C12007C for ; Fri, 1 Nov 2019 16:55:49 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id k15so7449241vsp.2 for ; Fri, 01 Nov 2019 16:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8z5O0Oou81cR1WdVvgibzMJPVCS7bZxPwgBSYnKT16s=; b=l1CnI1ZT3W+sEb7M7fF/tHHuN+U7PDXDSZCYe43YA2hrEsRvO+GKAAd+GFDv/P1T2P VLjWYpefsyBvfRlUwzlvNtKu73nAV5OBZjHI3fdCFWQ7jA7sGQQee7U2sWtKWkXtQEij oj9e7J2lPtibsCODk00n1S1bJHi3VKKOtdTuiL3NgjjabO/l8uv2FDQR2D0EpZN884WA Lstqt2ONFKTrT9JwZI9OnEbthD7eyMdN/1g41benM9atR5IpYlt8X4lsHO7GuXwg9sh1 qGnFUl6Dvt13dW9NHsGSHNjiAzhXM/TcemdWc4I7WbXiWwcpz2oLcyQ0nNTSgpEmttAg 4now== 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; bh=8z5O0Oou81cR1WdVvgibzMJPVCS7bZxPwgBSYnKT16s=; b=jlUjnuHy9s0x43Ys4iMXwUfCdPFw1usCZ9EvgYxzdxvPxK7Ml+65/Rof7EqLXKTe4F XVn0sRV81+lZxH9Em21fHILGIU0iqiIOz/2Sw6T/JftoefOKv2+QkvnbpIOhcOli905L NGopksaQo1U7M+zt0u3XY+hYW3BzxsawhrwLs1otGo3vADLfXm2LVmE8Yhfu4C2Rc7/k nxV/qucQqfukyW7ZNrY9N0h7wiMT4xC/zxqq9NcinCJs0kBD7YXl8dMKmlIlntauU13p YrtS1RemRNqJEk/FZPIhbZ3QvkoMo4w6lfQ3820eaB6h4EIbjbyuiQV0T1hnJXvlSP5Y KumA== X-Gm-Message-State: APjAAAWlHwUxEQBidcMNJTNtQOmpI3pAqZCX1zqDl3qujKj8hYqwnTfz ahWHJQN1pFaK5nt3VhMy1tv3wygxv5hleFyF568OOQJr X-Google-Smtp-Source: APXvYqyj1rpppTT3nL84zTA0UKTEf1n17QarrHojr9PqTjZvzrTWMnhYhf2t8hWt1UsuuOzLYkBH8Q0d2mvMbsqTcF4= X-Received: by 2002:a67:f24d:: with SMTP id y13mr7312092vsm.123.1572652547692; Fri, 01 Nov 2019 16:55:47 -0700 (PDT) MIME-Version: 1.0 References: <157265157653.31860.1480050311768258768@ietfa.amsl.com> In-Reply-To: <157265157653.31860.1480050311768258768@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 1 Nov 2019 16:55:11 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rack-06.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: Fri, 01 Nov 2019 23:55:54 -0000 On Fri, Nov 1, 2019 at 4:40 PM wrote: > > > 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 : RACK: a time-based fast loss detection algorithm for TCP > Authors : Yuchung Cheng > Neal Cardwell > Nandita Dukkipati > Priyaranjan Jha > Filename : draft-ietf-tcpm-rack-06.txt This revision primarily addresses the questions raised this year e.g. RACK.RTT definition by Martin Duke, TLP RTO re-arming by Yi Huang, and a new reference on Sprout's similar reo_wnd design by Keith Winstein. Thank you for the reviews. From nobody Sat Nov 2 14:25:15 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> 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 63E9C120046 for ; Sat, 2 Nov 2019 14:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 MnLbKSV3ZND7 for ; Sat, 2 Nov 2019 14:25:12 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1172212006A for ; Sat, 2 Nov 2019 14:25:09 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA2LP37e093161; Sat, 2 Nov 2019 14:25:03 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA2LP0N0093157; Sat, 2 Nov 2019 14:25:00 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201911022125.xA2LP0N0093157@gndrsh.dnsmgr.net> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" Date: Sat, 2 Nov 2019 14:25:00 -0700 (PDT) CC: "tcpm@ietf.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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: Sat, 02 Nov 2019 21:25:13 -0000 Reviving this thread, > Hi all, > > Disclaimer: I write this note as individual contributor to TCPM. It is possible that I end up in the rough part of the TCPM consensus in this case. That would be unusual, but it is not impossible. If so, this e-mail documents my concerns (again). Reasonable people can reasonably disagree, and that does not prevent the working group from moving forward. I'd also like to announce that I would prefer not to serve as shepherd for a document if consensus has to be declared against me, in order to avoid any bias. > > Given that we need to finish draft-ietf-tcpm-accurate-ecn, and given other recent TCPM discussions on reserved TCP header bits, I have thought about the IANA considerations of allocating a reserved header bit. This e-mail is not about the question of _whether_ to allocate a bit. It is about the _how_. > > That question was discussed in the past for draft-ietf-tcpm-accurate-ecn already quite a bit, e.g. during IETF 99. During that discussion, I have raised concerns against allocating a bit in the main TCP to an experiment without backing by a standards track RFC. I may have been in the rough part of the consensus in the room when that discussion took place. But I have not changed my mind. > > The statement in RFC 2780 is: "The reserved bits in the TCP header are assigned following a Standards Action process." > > RFC 8126 explains: "For the Standards Action policy, values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream." > > And I think that requirement in RFC 2780 is correct. I probably don't have to expand on why IETF rules make sense to me. RFC 2780 and RFC 8126 don't leave much room for interpretation, as far as I understand them. > > It is well-known that bit 7 requested by draft-ietf-tcpm-accurate-ecn has previously been allocated to an experimental RFC (RFC 3540). That happened before I have joined IETF mailing lists, and I am not familiar with the corresponding discussions, most notably regarding compliance with RFC 2780. In any case, given that RFC 3540 is now historic and the bit is has status "reserved", the current IANA registration of TCP header flags is apparently compliant to RFC 2780. > > In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules. > > And actually I believe it would not be hard to do so. For instance, TCPM could publish a short standards track RFC that allocates e.g. bit 7 for experiments. That could solve the allocation needed by draft-ietf-tcpm-accurate-ecn. Similar to RFC 8311, a standards track document could precisely define what experimentation is allowed with that bit. It would be a short document that could be finished on fast track, possibly even in parallel to draft-ietf-tcpm-accurate-ecn, provided that there is consensus on allocating e.g. bit 7 to a well-defined area of experimentation. It has been pointed out in the past that such as standards track document would result in overhead. I believe that the overhead would be small and worth the effort. > > In any case, I feel uncomfortable with creating a precedent for IETF process violation regarding any of the reserved bits in the TCP header. I have reviewed the above, and am in full agreement. As author of draft-grimes-tcpm-tcpsce, which is also requesting use of a TCP bit for experimental purpose, ask what the next steps are? -- Rod Grimes rgrimes@freebsd.org From nobody Sat Nov 2 16:26:37 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> 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 02E3D1200B5; Sat, 2 Nov 2019 16:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2wdnO7nVPWlW; Sat, 2 Nov 2019 16:26:24 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039B1200CD; Sat, 2 Nov 2019 16:26:24 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA2NQJkX093619; Sat, 2 Nov 2019 16:26:19 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA2NQIYm093618; Sat, 2 Nov 2019 16:26:18 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> In-Reply-To: <1468777263.2671021.1563730029999@mail.yahoo.com> To: "alex.burr@ealdwulf.org.uk" Date: Sat, 2 Nov 2019 16:26:18 -0700 (PDT) CC: Jonathan Morton , "\"Rodney W. Grimes\"" , "\"tcpm@ietf.org\"" , "\"tsvwg@ietf.org\"" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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: Sat, 02 Nov 2019 23:26:30 -0000 Rod Grimes rgrimes@freebsd.org Alex, With respect to draft-ietf-tcpm-accurate-ecn and draft-grimes-tcpm-tcpsce compatibility: When accurate ecn (AccECN) fails to negotiate an AccECN capable session it falls back to RFC3168 conformance, leaving a state that is fully compatible with SCE, hence they are compatible. I am currently working on a revision to draft-grimes-tcpm-tcpsce and hopefully can cover this "compatible" situation in the draft itself. With respect to "There are no IANA considerations": You are correct, reworking that in several respects, hope to remove references to the NS bit for most parts and simply state that this draft for "IANA considerations" is requesting a bit, with the former NS bit prefered. Regards, Rod > Rod, Jonathan, > ?I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn,it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record. > > Also, presumably it is incorrect that "There are no IANA considerations", since IANA would need to change the NS bit. > > Regards, > Alex > > Rodney W. Grimes" wrote: > > > Rod, > > > > > > This draft appears to be focused on obtaining a TCP header bit for SCE. > > > > Yes, that is correct. > > > > > As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. > > > > I specifically did not do what Accurate Ecn attempts as that requires > > a TCP option negotiation at connection establishment to negotiate the > > overloading of other TCP header bits.? SCE only needs 1 new bit, and > > does not alter the behavior of any current bits. > > > > This proposal (TCPSCE) does not in any way effect the current use of > > any of the other bits, and use of the NS bit should be fully backwards > > compatible and ignored by pre SCE implementations and does not require > > a TCP option negotiation. > > > > I have to get additional data but have been lead to understand that > > adding a tcp option and doing that negotiation is going to cause a > > great deal of pain in the ability to deploy accurate ecn as it is > > currently designed due to middle box inspection and handling. > > > > Regards, > > Rod > > > > > Thanks, --David > > > > > > > -- Rod Grimes rgrimes@freebsd.org From nobody Sun Nov 3 01:46: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 BF6A2120108; Sun, 3 Nov 2019 01:46:22 -0800 (PST) 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 919rlcGffY4Y; Sun, 3 Nov 2019 01:46:19 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF33120104; Sun, 3 Nov 2019 01:46:19 -0800 (PST) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 00D0F1B00280; Sun, 3 Nov 2019 09:46:11 +0000 (GMT) Message-ID: <5DBEA1E3.9020009@erg.abdn.ac.uk> Date: Sun, 03 Nov 2019 09:46:11 +0000 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: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: "alex.burr@ealdwulf.org.uk" , "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> In-Reply-To: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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: Sun, 03 Nov 2019 09:46:23 -0000 See in-line. On 02/11/2019, 23:26, Rodney W. Grimes wrote: > Rod Grimes rgrimes@freebsd.org > Alex, > With respect to draft-ietf-tcpm-accurate-ecn and > draft-grimes-tcpm-tcpsce compatibility: > When accurate ecn (AccECN) fails to negotiate an AccECN capable session > it falls back to RFC3168 conformance, leaving a state that is fully > compatible with SCE, hence they are compatible. I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN? Gorry > I am currently working on a revision to draft-grimes-tcpm-tcpsce and > hopefully can cover this "compatible" situation in the draft itself. > > With respect to "There are no IANA considerations": > You are correct, reworking that in several respects, hope to remove > references to the NS bit for most parts and simply state that this > draft for "IANA considerations" is requesting a bit, with the former > NS bit prefered. > > Regards, > Rod > >> Rod, Jonathan, >> ?I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn,it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record. >> >> Also, presumably it is incorrect that "There are no IANA considerations", since IANA would need to change the NS bit. >> >> Regards, >> Alex >> >> Rodney W. Grimes" wrote: >>>> Rod, >>>> >>>> This draft appears to be focused on obtaining a TCP header bit for SCE. >>> Yes, that is correct. >>> >>>> As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. >>> I specifically did not do what Accurate Ecn attempts as that requires >>> a TCP option negotiation at connection establishment to negotiate the >>> overloading of other TCP header bits.? SCE only needs 1 new bit, and >>> does not alter the behavior of any current bits. >>> >>> This proposal (TCPSCE) does not in any way effect the current use of >>> any of the other bits, and use of the NS bit should be fully backwards >>> compatible and ignored by pre SCE implementations and does not require >>> a TCP option negotiation. >>> >>> I have to get additional data but have been lead to understand that >>> adding a tcp option and doing that negotiation is going to cause a >>> great deal of pain in the ability to deploy accurate ecn as it is >>> currently designed due to middle box inspection and handling. >>> >>> Regards, >>> Rod >>> >>>> Thanks, --David >>>> >> >> >> From nobody Sun Nov 3 05:09:02 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 6B0F51200A4; Sun, 3 Nov 2019 05:09:00 -0800 (PST) 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 ZcKF2L6tgijy; Sun, 3 Nov 2019 05:08:59 -0800 (PST) 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 04EA4120089; Sun, 3 Nov 2019 05:08:58 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id t5so14744138ljk.0; Sun, 03 Nov 2019 05:08:58 -0800 (PST) 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=LpFMRNBBKU8Fj85yU+5j/qqNn9lT6iLz0kpFi8ylyDg=; b=YMuM5/XllR1aEO6eXhVNIJR65/AolRv31NMn893q8zuw/p/t6SdZ6oFc2lJldWpmZE 479XZbiwtVLMcvuptjK5fK0FlFpV8gSsuhQsT1byBi0Adbmk0m6hbl5qpPMtdnLv7vGP JaigPEUYCG+avaR5gd0PzZMxI3ksaHZq6ZS0hQ36HHpoRxpZJLh0inxYkpT8RcpUzN68 3F49k5JKqASjj6Uml7faafxj0ca3g1MI4qS30ujNCYd5fSFM/6frugvHYJ9u2lM6W5K3 kRjNCPmA97JeBj6wWB+ZALErPTEr31zSZdSGH+P/uokeOUdQvt87c7OCe6WR9z3LEZo/ tsGw== 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=LpFMRNBBKU8Fj85yU+5j/qqNn9lT6iLz0kpFi8ylyDg=; b=q0JToX7MYvwworo/W+O2FN6ljgBbmV1CnEicFHCAQR0U08De8RnVXyUP/IciAVB81M FmzzaEfemfu0nwzBuNCEFE7J7TFEYHomVwp7tU9uE190C81KJMf28+L25yR6fhnQs+FW o97QgnUsc9MuhcPZnWBJW5eShVR2fGCCLt+Rvx2HEaaSNTQM5IVh68g1l+0OFrlszAYo Lwf50rY8ry62iFUQXhPJeQk/7wiY3KKk+xCA3P0EEpmPemikJv9POtnerwyrOu0WAYx4 lcPKkken9TnRX/O4hMV7I7FYSnI8umZ4QxKiiJ/QTP1Thpck/iumxxfY0MB+e/2oXSe9 XGdA== X-Gm-Message-State: APjAAAU6ky1zxXWDg4+BO/bBqaXVdhfByEAka/J2v2em8Y7+C42uDBl+ c4ne2jo/Zcmg6tTEb1OjNPptT+xt X-Google-Smtp-Source: APXvYqxe4F4pN1YSHqmz55gFGe20119vgL08al9jv0ZHSfuHbCsExWX/vQ7rFN8oG5vBOHGRsmVCrw== X-Received: by 2002:a2e:9802:: with SMTP id a2mr2687944ljj.254.1572786537172; Sun, 03 Nov 2019 05:08:57 -0800 (PST) Received: from jonathartonsmbp.lan (85-76-23-24-nat.elisa-mobile.fi. [85.76.23.24]) by smtp.gmail.com with ESMTPSA id z20sm5967424ljj.85.2019.11.03.05.08.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Nov 2019 05:08:56 -0800 (PST) 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: <5DBEA1E3.9020009@erg.abdn.ac.uk> Date: Sun, 3 Nov 2019 15:08:54 +0200 Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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: Sun, 03 Nov 2019 13:09:00 -0000 > On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst = wrote: >=20 >> With respect to draft-ietf-tcpm-accurate-ecn and >> draft-grimes-tcpm-tcpsce compatibility: >> When accurate ecn (AccECN) fails to negotiate an AccECN capable = session >> it falls back to RFC3168 conformance, leaving a state that is fully >> compatible with SCE, hence they are compatible. > I was expecting this to fall-back to RFC8511, treatment at the = endpointrs, since that is the most recent spec. Does that make any = difference to your thoughts abiout what you expect an endpoint to do = when it receives ECN-marking without Accurate ECN? RFC-8511 doesn't change the signalling on the wire relative to RFC-3168. = That was the sense intended here. - Jonathan Morton= From nobody Sun Nov 3 06:51:34 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 EBA3D120059 for ; Sun, 3 Nov 2019 06:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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] 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 CQSVPBIAzwsQ for ; Sun, 3 Nov 2019 06:51:31 -0800 (PST) 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 F16EA120033 for ; Sun, 3 Nov 2019 06:51:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 75A1125A17; Sun, 3 Nov 2019 15:51:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572792689; bh=NCOU6gCCSR/43fdgJrqKbI46s69PWuntMZWwkCGebEs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=zccDS9VEvHmRh9+GuQuJXjIH8PAKKtLye2oacRkoejafHlBe47GcRWoeFm1Ny9l/n PYDa6MeJpPwRRYtIw1FiYJn00VBxxuSj3wKVXtCcrKhvhb3omh6C27vjThhOEshWrm ImWYqVmVP05Xf5UQAkgT3WBWbW0AR5/O0wzGkYPs= 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 o2dBGGoheZv1; Sun, 3 Nov 2019 15:51:28 +0100 (CET) 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; Sun, 3 Nov 2019 15:51:28 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Sun, 3 Nov 2019 15:51:28 +0100 From: "Scharf, Michael" To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: "tcpm@ietf.org" Thread-Topic: [tcpm] On allocating reserved bits in the TCP header Thread-Index: AdVmj1xabgQDGeLVSb628zuZMsyT0ArLD1IAACWg15A= Date: Sun, 3 Nov 2019 14:51:27 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4D8D80@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <201911022125.xA2LP0N0093157@gndrsh.dnsmgr.net> In-Reply-To: <201911022125.xA2LP0N0093157@gndrsh.dnsmgr.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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: Sun, 03 Nov 2019 14:51:33 -0000 > As author of draft-grimes-tcpm-tcpsce, which is also requesting use of a = TCP bit > for experimental purpose, ask what the next steps are? The usual dos and don'ts apply: Socialize the idea, get feedback, consider = the feedback, update the document, convince the working group, etc. We have 4 reserved bits left in the TCP header. There has been a past and c= ompleted experiments with bit 7. The past use could be considered a precede= nt when publishing a standards track document that allows new experiments w= ith reserved bits. The precedent only exist for bit 7. I am aware of at least 4 different ideas that have been posted recently to = this list regarding use of a reserved bit. If the TCPM working group (well,= actually the IETF) reached consensus that more than one experiment was use= ful, we may have to think about a way of negotiating what experiment is in = use on a connection. Or find another solution. As an individual contributor to TCPM, my current thinking is that one bit (= i.e., bit 7) would be enough for experimentation - for the time being. This is my personal view. The last change to the main TCP header was done i= n 2001. It is hard to predict what the IETF consensus would be these days. Michael From nobody Sun Nov 3 12:44:47 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 84E2D120073 for ; Sun, 3 Nov 2019 12:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 fgKgPQSamfdZ for ; Sun, 3 Nov 2019 12:44:44 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1085612002E for ; Sun, 3 Nov 2019 12:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=VO1T2v8gGK74dDj4GODGLBrpWegzwUO7GZp5QB8bBZU=; b=Bt0y9EFrc9ry7k4TzR+etKoY7T cboKDwPh142YqrKukFTFbbRt1kvT5TDtaRvpYOTEmjIBtVEzjCsKybcLq7jLVl66BPC5gwhE5qrK0 8xz162BahGQ2m1ndHFWTSCD+3gY/To0+tq6W8FGhdJQngvDDuj0cAcdNmHKFTF1/JO3pzy84XK4wX cGrh5pv4OuzMUD0O7axr4LCnl0ZuB9C751ulu8lQPTfO4Hh4hgui2VPpVSg6dz2uGNcLheYwfmTrq MMu6Ebxx1gOfOjpGUMeXWXv+UXvk1GcQnPV00k/fIG/xeFmHd4E3TQ7MvWBBWYA4O2RFdaiBCCGOA ZTPEgH5w==; Received: from [31.185.128.31] (port=34430 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iRMjo-0005f6-G2; Sun, 03 Nov 2019 20:44:40 +0000 To: Yuchung Cheng , "tcpm@ietf.org Extensions" References: <157265157653.31860.1480050311768258768@ietfa.amsl.com> From: Bob Briscoe Message-ID: <61ee8c89-c4ab-349a-5d7c-404976217486@bobbriscoe.net> Date: Sun, 3 Nov 2019 20:44:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rack-06.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: Sun, 03 Nov 2019 20:44:47 -0000 Yuchung, Thx for this. All the deltas make sense (to me). FWIW, a couple of nits in the deltas: s/wether/whether/ s/The [Sprout] congestion control also independently designed/  /The [Sprout] congestion control was also independently designed/ Cheers Bob On 01/11/2019 23:55, Yuchung Cheng wrote: > On Fri, Nov 1, 2019 at 4:40 PM wrote: >> >> 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 : RACK: a time-based fast loss detection algorithm for TCP >> Authors : Yuchung Cheng >> Neal Cardwell >> Nandita Dukkipati >> Priyaranjan Jha >> Filename : draft-ietf-tcpm-rack-06.txt > This revision primarily addresses the questions raised this year e.g. > RACK.RTT definition by Martin Duke, TLP RTO re-arming by Yi Huang, and > a new reference on Sprout's similar reo_wnd design by Keith Winstein. > Thank you for the reviews. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Sun Nov 3 14:04:23 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 A26991200F7 for ; Sun, 3 Nov 2019 14:04:20 -0800 (PST) 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, HTML_MESSAGE=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=bobbriscoe.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 Lud74ka8nEjU for ; Sun, 3 Nov 2019 14:04:18 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1613F1200C1 for ; Sun, 3 Nov 2019 14:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=DyN1FJDqptHIEVNKYxmo328Z7QLGfSprxjEXJtjFi+M=; b=lySBBfOsXYSrh2Nu55i7PaIt/ zCgUDs+MJXKjKPihgLuEYaqyXCPzGRWsF0iwxcuaojsCCaogJ3HvSdcKBLUYSt4cWs8dpoAFdvYkC 7Uu5XV9skM5RFYSo9ylmTPgri4eiaJ1jaiP5Xd6+QMwBwiU4t5I59a0C63Xtmb/BsXJCfR9xPY3xq D898B3PEASyiFYWjQbi+D1rAj3lsz/OqLfzMK2zmbA8N3aqby5yzYeJkgQVcduHZlvdmrBhw8r8h6 Apkq8QbnzpsgHVYPD6tDcLx3ro7kdHsWPCTeXPl7JpKLt8c1rSNInICFWhgYx9rGxIgtrXSg5dAfB Zf1tK/L/g==; Received: from [31.185.128.31] (port=34872 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iRNyq-0002Wy-67; Sun, 03 Nov 2019 22:04:16 +0000 To: "Scharf, Michael" Cc: "tcpm@ietf.org" , Mirja Kuehlewind , Richard Scheffenegger References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> From: Bob Briscoe Message-ID: <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> Date: Sun, 3 Nov 2019 22:04:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> Content-Type: multipart/alternative; boundary="------------480D087E8E98C4C469349A13" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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: Sun, 03 Nov 2019 22:04:21 -0000 This is a multi-part message in MIME format. --------------480D087E8E98C4C469349A13 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Michael, On 03/10/2019 12:31, Lars Eggert wrote: > On 2019-9-10, at 13:50, Scharf, Michael wrote: >> In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules. > Agreed. > > Lars > If asked this question in isolation, I would go for a quick RFC. But this is not in isolation. The decision on what process to use has already been made - in Jul 2017 at IETF-99 (it was for the IESG to be asked to make a process exception). This is just a choice between processes. There's no difference to the technical outcome. Please can we just do it the way we already decided to. Altho I'm a Brit, I am not a fan of people trying to re-run a referendum decision 'cos they didn't get what they wanted in the previous one. Background This issue was extensively discussed already. After a long offlist thread with the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Jul 17: https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM This thread ends by deferring to a meeting arranged at IETF-99 during AD Office Hours, at which the tcpm chairs were represented. The outcome of that meeting was to expect the AccECN draft to rename bit 7 and assign it to itself, which would need the IESG to agree a process exception. That outcome was recorded on this slide for discussion in the subsequent tcpm WG meeting: https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7 The tcpm minutes here: https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 record that "There is strong but not unanimous consensus in the room for assigning the codepoint." and the process proposal remained unchanged: that the IESG would be asked to make a process exception. I didn't like that decision either, but this is just process. Can we move on please. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------480D087E8E98C4C469349A13 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.

Agreed.

Lars


If asked this question in isolation, I would go for a quick RFC. But this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 at IETF-99 (it was for the IESG to be asked to make a process exception). This is just a choice between processes. There's no difference to the technical outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum decision 'cos they didn't get what they wanted in the previous one.


Background
This issue was extensively discussed already. After a long offlist thread with the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Jul 17:
https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
This thread ends by deferring to a meeting arranged at IETF-99 during AD Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 7 and assign it to itself, which would need the IESG to agree a process exception. That outcome was recorded on this slide for discussion in the subsequent tcpm WG meeting:
https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7
The tcpm minutes here:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00
record that "There is strong but not unanimous consensus in the room for assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be asked to make a process exception.

I didn't like that decision either, but this is just process. Can we move on please.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------480D087E8E98C4C469349A13-- From nobody Sun Nov 3 14:30:06 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 6A14E12000F; Sun, 3 Nov 2019 14:29:55 -0800 (PST) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157282019531.13498.13606058087743663738@ietfa.amsl.com> Date: Sun, 03 Nov 2019 14:29:55 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-05.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: Sun, 03 Nov 2019 22:29:56 -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 : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-05.txt Pages : 46 Date : 2019-11-03 Abstract: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-05 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 Sun Nov 3 18:00: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 73FB612086B for ; Sun, 3 Nov 2019 18:00:16 -0800 (PST) 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 lHdXfrWsMlbn for ; Sun, 3 Nov 2019 18:00:12 -0800 (PST) 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 4D52B120020 for ; Sun, 3 Nov 2019 18:00:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A51C625A19; Mon, 4 Nov 2019 03:00:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572832810; bh=4QkS36t4Yl76cL2A4eHVyMlwhJEgDV1tnvibm60ulb4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qNTdHgHgsAKXb1EMvHcoUymIq/ne644klSyvlPbIb7blWPJMdU5j5fj6vPOlB+j78 d2GyYeVsZOIxtEMKqo8YSODAim0WLNYve7b8//PxPSoH8QZf05i5ujd96Q3jQ1BG4v Bi8TQqWduIuM0eKfZ0nVwc96qWW/RpWWiWwKObSg= 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 EBg64hGeeb8g; Mon, 4 Nov 2019 03:00:09 +0100 (CET) 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; Mon, 4 Nov 2019 03:00:09 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 03:00:08 +0100 From: "Scharf, Michael" To: Bob Briscoe CC: "tcpm@ietf.org" , Mirja Kuehlewind , Richard Scheffenegger Thread-Topic: [tcpm] On allocating reserved bits in the TCP header Thread-Index: AdVmj1xabgQDGeLVSb628zuZMsyT0ATPfeIABi860QAAClWnwg== Date: Mon, 4 Nov 2019 02:00:09 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org>, <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> In-Reply-To: <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4D9D3Brznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 02:00:17 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4D9D3Brznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bob, With chair hat on: There was a discussion =84in the room=93 during IETF 99 = and the outcome of a hum =84in the room=93 is documented in the minutes. In= TCPM, consensus is confirmed on the list so that all contributors can comm= ent. Please don=92t refer to room discussions as working group =84decisions= =93. With chair hat off, I believe there was never a formal consensus decision i= n TCPM to explicitly violate RFCs. And, anyway, the working group could cha= nge past decisions, at least prior to completing a WGLC. In this specific c= ase, as individual contributor, I explicitly and very strongly disagree to = move forward with an invalid IANA considerations section. Thanks Michael Von: Bob Briscoe Gesendet: Sonntag, 3. November 2019 23:04 An: Scharf, Michael Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard Scheffenegger Betreff: Re: [tcpm] On allocating reserved bits in the TCP header Michael, On 03/10/2019 12:31, Lars Eggert wrote: On 2019-9-10, at 13:50, Scharf, Michael wrote: In my reading of RFC 2780 and RFC 8126, it would be a policy violation to a= llocate a bit in the main TCP header to an experiment without a proper stan= dards track document allowing this experimentation. I am convinced that for= bits in the main TCP header the IETF should just follow its own rules. Agreed. Lars If asked this question in isolation, I would go for a quick RFC. But this i= s not in isolation. The decision on what process to use has already been made - in Jul 2017 at = IETF-99 (it was for the IESG to be asked to make a process exception). This= is just a choice between processes. There's no difference to the technical= outcome. Please can we just do it the way we already decided to. Altho I'm a Brit, I am not a fan of people trying to re-run a referendum de= cision 'cos they didn't get what they wanted in the previous one. Background This issue was extensively discussed already. After a long offlist thread w= ith the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Ju= l 17: https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM This thread ends by deferring to a meeting arranged at IETF-99 during AD Of= fice Hours, at which the tcpm chairs were represented. The outcome of that meeting was to expect the AccECN draft to rename bit 7 = and assign it to itself, which would need the IESG to agree a process excep= tion. That outcome was recorded on this slide for discussion in the subsequ= ent tcpm WG meeting: https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-a= ccurate-ecn-feedback-in-tcp-02#page=3D7 The tcpm minutes here: https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 record that "There is strong but not unanimous consensus in the room for as= signing the codepoint." and the process proposal remained unchanged: that the IESG would be asked t= o make a process exception. I didn't like that decision either, but this is just process. Can we move o= n please. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_6EC6417807D9754DA64F3087E2E2E03E2D4D9D3Brznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Bob,

 

With chair hat on: There was a discussion =84in the = room=93 during IETF 99 and the outcome of a hum =84in the room=93 is docume= nted in the minutes. In TCPM, consensus is confirmed on the list so that al= l contributors can comment. Please don=92t refer to room discussions as working group =84decisions=93.

 

With chair hat off, I believe there was never a form= al consensus decision in TCPM to explicitly violate RFCs. And, anyway, the = working group could change past decisions, at least prior to completing a W= GLC. In this specific case, as individual contributor, I explicitly and very strongly disagree to move forward with = an invalid IANA considerations section.

 

Thanks

 

Michael

 <= /span>

 

Von: Bob Briscoe
Gesendet: Sonntag, 3. November 2019 23:04
An: Scharf, Michae= l
Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard Scheffenegg= er
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

 

Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

In my reading of RFC 2780 and RFC 8126, it wou=
ld be a policy violation to allocate a bit in the main TCP header to an exp=
eriment without a proper standards track document allowing this experimenta=
tion. I am convinced that for bits in the main TCP header the IETF should j=
ust follow its own rules.

Agreed.

Lars


If asked this question in isolation, I would go for a quick RFC. But this i= s not in isolation.

The decision on what process to use has already been made - in Jul 2017 at = IETF-99 (it was for the IESG to be asked to make a process exception). This= is just a choice between processes. There's no difference to the technical= outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a refer= endum decision 'cos they didn't get what they wanted in the previo= us one.


Background
This issue was extensively discussed already. After a long offlist thread w= ith the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Ju= l 17:
    https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM=
This thread ends by deferring to a meeting arranged at IETF-99 during AD Of= fice Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 7 = and assign it to itself, which would need the IESG to agree a process excep= tion. That outcome was recorded on this slide for discussion in the subsequ= ent tcpm WG meeting:
    https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accur= ate-ecn-feedback-in-tcp-02#page=3D7
The tcpm minutes here:
    https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 record that "There is strong but not unanimous consensus in the room f= or assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be asked t= o make a process exception.

I didn't like that decision either, but this is just process. Can we move o= n please.


Bob

--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--_000_6EC6417807D9754DA64F3087E2E2E03E2D4D9D3Brznt8114rzntrzd_-- From nobody Sun Nov 3 19:08: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 9DBC312091B for ; Sun, 3 Nov 2019 19:08:43 -0800 (PST) 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 c5qDIOqS-vtI for ; Sun, 3 Nov 2019 19:08:41 -0800 (PST) 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 9633D12095B for ; Sun, 3 Nov 2019 19:08:41 -0800 (PST) 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=xMuolm5aPgth05O0tKnW9y2lxr5sfpbcSpDkdXHHO2U=; b=XsaeFgjBvfnwAiPJXPAkAwsmR HNu+PnWWJMBVFTCEmgYYkfKWPFDELHzDazQiRAbnzCWIanNcPcIL6oGB3ZgoQs+KwjrGXKupmysWB ZuBUrkvQjtB5xK/LmvczaAgrEvtkAmtLq983gjo7iPoOKP3P0580YCXkvQsK/wj+ISSTl5md4rNXs kEg1PF8X8F9fPUwxqQnYZik+fPZjJp5JqQogT4uFUoxepuo5vzxMMQoMluASmRMSsN9uCxcZKKTKy c9wtkzGhCYpJ2Mpj33BmK0F38I86AgGeWDdQsksQapuNOB0UpMKasBPDdYfScMq7zn3MoET7ibeVt t8GOVF++w==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52357 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 1iRSjL-00122Y-OK; Sun, 03 Nov 2019 22:08:40 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_A5038606-CF71-4712-B367-F31B465D490C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Sun, 3 Nov 2019 19:08:34 -0800 Cc: Bob Briscoe , Richard Scheffenegger , "tcpm@ietf.org" , Mirja Kuehlewind Message-Id: References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" 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] On allocating reserved bits in the TCP header 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, 04 Nov 2019 03:08:49 -0000 --Apple-Mail=_A5038606-CF71-4712-B367-F31B465D490C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Why do we need this process exception? We have 793bis in process. If we need to assign a bit in the header - to = any specific use or as experimental - that seems like the appropriate = venue in which to do so. Joe > On Nov 3, 2019, at 6:00 PM, Scharf, Michael = wrote: >=20 > Bob, > =20 > With chair hat on: There was a discussion =E2=80=9Ein the room=E2=80=9C = during IETF 99 and the outcome of a hum =E2=80=9Ein the room=E2=80=9C is = documented in the minutes. In TCPM, consensus is confirmed on the list = so that all contributors can comment. Please don=E2=80=99t refer to room = discussions as working group =E2=80=9Edecisions=E2=80=9C. > =20 > With chair hat off, I believe there was never a formal consensus = decision in TCPM to explicitly violate RFCs. And, anyway, the working = group could change past decisions, at least prior to completing a WGLC. = In this specific case, as individual contributor, I explicitly and very = strongly disagree to move forward with an invalid IANA considerations = section. > =20 > Thanks > =20 > Michael > =20 > =20 > Von: Bob Briscoe > Gesendet: Sonntag, 3. November 2019 23:04 > An: Scharf, Michael > Cc: tcpm@ietf.org ; Mirja Kuehlewind = ; Richard Scheffenegger = > Betreff: Re: [tcpm] On allocating reserved bits in the TCP header > =20 > Michael, >=20 > On 03/10/2019 12:31, Lars Eggert wrote: >> On 2019-9-10, at 13:50, Scharf, Michael = = wrote: >>> In my reading of RFC 2780 and RFC 8126, it would be a policy = violation to allocate a bit in the main TCP header to an experiment = without a proper standards track document allowing this experimentation. = I am convinced that for bits in the main TCP header the IETF should just = follow its own rules. >> Agreed. >>=20 >> Lars >>=20 >=20 > If asked this question in isolation, I would go for a quick RFC. But = this is not in isolation. >=20 > The decision on what process to use has already been made - in Jul = 2017 at IETF-99 (it was for the IESG to be asked to make a process = exception). This is just a choice between processes. There's no = difference to the technical outcome. Please can we just do it the way we = already decided to. >=20 > Altho I'm a Brit, I am not a fan of people trying to re-run a = referendum decision 'cos they didn't get what they wanted in the = previous one. >=20 >=20 > Background > This issue was extensively discussed already. After a long offlist = thread with the author of RFC8311 and others, a thread on tsvwg ran betw = 3 to 12 Jul 17: > = https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM = > This thread ends by deferring to a meeting arranged at IETF-99 during = AD Office Hours, at which the tcpm chairs were represented.=20 > The outcome of that meeting was to expect the AccECN draft to rename = bit 7 and assign it to itself, which would need the IESG to agree a = process exception. That outcome was recorded on this slide for = discussion in the subsequent tcpm WG meeting: > = https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accu= rate-ecn-feedback-in-tcp-02#page=3D7 = > The tcpm minutes here: > = https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 = > record that "There is strong but not unanimous consensus in the room = for assigning the codepoint." > and the process proposal remained unchanged: that the IESG would be = asked to make a process exception. >=20 > I didn't like that decision either, but this is just process. Can we = move on please. >=20 >=20 > Bob >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ = _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_A5038606-CF71-4712-B367-F31B465D490C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Why = do we need this process exception?

We have 793bis in process. If we need = to assign a bit in the header - to any specific use or as experimental - = that seems like the appropriate venue in which to do so.

Joe
On Nov = 3, 2019, at 6:00 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Bob,

 

With chair hat on: There was a discussion =E2=80=9Ein = the room=E2=80=9C during IETF 99 and the outcome of a hum =E2=80=9Ein = the room=E2=80=9C is documented in the minutes. In TCPM, consensus is = confirmed on the list so that all contributors can comment. Please = don=E2=80=99t refer to room discussions as working group =E2=80=9Edecisions=E2=80=9C.

 

With chair hat off, I believe there was never a = formal consensus decision in TCPM to explicitly violate RFCs. And, = anyway, the working group could change past decisions, at least prior to = completing a WGLC. In this specific case, as individual contributor, I explicitly and very strongly disagree to move forward = with an invalid IANA considerations section.

 

Thanks

 

Michael

 
 

Von: Bob Briscoe
Gesendet: Sonntag, 3. November 2019 23:04
= An: Scharf, Michael
Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard= Scheffenegger
Betreff: Re: [tcpm] On allocating reserved bits in the = TCP header

 
Michael,

On 03/10/2019 12:31, Lars Eggert = wrote:
On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-essli=
ngen.de> wrote:

In my reading of RFC 2780 and RFC 8126, it =
would be a policy violation to allocate a bit in the main TCP header to =
an experiment without a proper standards track document allowing this =
experimentation. I am convinced that for bits in the main TCP header the =
IETF should just follow its own rules.

Agreed.

Lars


If asked this question in isolation, I would go for a quick RFC. But = this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 = at IETF-99 (it was for the IESG to be asked to make a process = exception). This is just a choice between processes. There's no = difference to the technical outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum decision 'cos they didn't get what they = wanted in the previous one.


Background
This issue was extensively discussed already. After a long offlist = thread with the author of RFC8311 and others, a thread on tsvwg ran betw = 3 to 12 Jul 17:
    = https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
This thread ends by deferring to a meeting arranged at IETF-99 during AD = Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit = 7 and assign it to itself, which would need the IESG to agree a process = exception. That outcome was recorded on this slide for discussion in the = subsequent tcpm WG meeting:
    = https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accu= rate-ecn-feedback-in-tcp-02#page=3D7
The tcpm minutes here:
    = https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 record that "There is strong but not unanimous consensus in the room for = assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be = asked to make a process exception.

I didn't like that decision either, but this is just process. Can we = move on please.


Bob

--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_A5038606-CF71-4712-B367-F31B465D490C-- From nobody Sun Nov 3 23:11:58 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 0DB27120255; Sun, 3 Nov 2019 23:11:52 -0800 (PST) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157285151195.13544.13953318909699894852@ietfa.amsl.com> Date: Sun, 03 Nov 2019 23:11:52 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-14.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: Mon, 04 Nov 2019 07:11:57 -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-14.txt Pages : 52 Date : 2019-11-03 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. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-14 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 Sun Nov 3 23:55:58 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 78ED81200B4 for ; Sun, 3 Nov 2019 23:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 w4smlq4f-MGR for ; Sun, 3 Nov 2019 23:55:54 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618D712006D for ; Sun, 3 Nov 2019 23:55:54 -0800 (PST) Received: from eggert.org (unknown [62.248.255.8]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 0757C40082; Mon, 4 Nov 2019 09:55:51 +0200 (EET) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 4765361F90F; Mon, 4 Nov 2019 09:55:15 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Lars Eggert In-Reply-To: Date: Mon, 4 Nov 2019 09:55:14 +0200 Cc: "Scharf, Michael" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "tcpm@ietf.org" , Richard Scheffenegger , Bob Briscoe Content-Transfer-Encoding: quoted-printable Message-Id: <8B6C0F6F-2812-49C1-9DBF-070E00E1D391@eggert.org> References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> To: Joe Touch X-MailScanner-ID: 4765361F90F.A2880 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 07:55:57 -0000 On 2019-11-4, at 5:08, Joe Touch wrote: > Why do we need this process exception? >=20 > We have 793bis in process. If we need to assign a bit in the header - = to any specific use or as experimental - that seems like the appropriate = venue in which to do so. If the timelines align, that would be the obvious place to stick that = assignment, agreed. But I'm not sure the timelines do align. 793bis seems to progress at a = slow-but-steady pace (I'll point out it was supposed to be done two = years ago...) but it seems likely that experiments want to happen = sooner. Lars From nobody Mon Nov 4 00:11: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 D43F41200E6 for ; Mon, 4 Nov 2019 00:11:52 -0800 (PST) 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 0iq49AodMpm9 for ; Mon, 4 Nov 2019 00:11:51 -0800 (PST) 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 C8FC51200D8 for ; Mon, 4 Nov 2019 00:11:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E96DF25A1F; Mon, 4 Nov 2019 09:11:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572855108; bh=6x6biZzyytyGe3zTkpJwwsDC8JNtBkLy6nRWVDaKcD8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=vI8GzRmC0L+snl6Mwix6w4u3kzC8VrN1tI3lfyw+9dcT0K0xoVwvk1xjWoWFZqGBg skYa8aXb1k0xtgFvcgTlB1fvrmYy/N9Jk6IwioDKpq8aqw6Szv/duz4ozZozSihz/P ZXs2UNTQ8EfKEuCYkJwY5Slq622S9S4ekBq19t2E= 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 f9bcHLpSygP3; Mon, 4 Nov 2019 09:11:48 +0100 (CET) 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; Mon, 4 Nov 2019 09:11:48 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 09:11:47 +0100 From: "Scharf, Michael" To: Lars Eggert , Joe Touch CC: =?Windows-1252?Q?Mirja_K=FChlewind?= , "tcpm@ietf.org" , Richard Scheffenegger , "Bob Briscoe" Thread-Topic: [tcpm] On allocating reserved bits in the TCP header Thread-Index: AdVmj1xabgQDGeLVSb628zuZMsyT0ATPfeIABi860QAAClWnwgAAS00AAAoDAAAAAqxcwg== Date: Mon, 4 Nov 2019 08:11:46 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DA42D@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> , <8B6C0F6F-2812-49C1-9DBF-070E00E1D391@eggert.org> In-Reply-To: <8B6C0F6F-2812-49C1-9DBF-070E00E1D391@eggert.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4DA42Drznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 08:11:53 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DA42Drznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I believe that 793bis gets more and more mature. We will need further revie= ws in the next months. Given that this is a -bis for an Internet Standard, = there are unknowns=85 The tentative plan is a WGLC early 2020. A short PS focusing just on the assignment could perhaps be finished faster= than 793bis. And that approach would also not change the scope of 793bis, = i.e., 793bis would only include changes with IETF consensus. Because of that, I would slightly prefer a short dedicated PS. But 793bis w= ould also work for me. Any formally correct solution is better than a proce= ss violation. Michael Von: Lars Eggert Gesendet: Montag, 4. November 2019 08:55 An: Joe Touch Cc: Scharf, Michael; Mirja K=FChlewi= nd; tcpm@ietf.org; Richar= d Scheffenegger; Bob Briscoe Betreff: Re: [tcpm] On allocating reserved bits in the TCP header On 2019-11-4, at 5:08, Joe Touch wrote: > Why do we need this process exception? > > We have 793bis in process. If we need to assign a bit in the header - to = any specific use or as experimental - that seems like the appropriate venue= in which to do so. If the timelines align, that would be the obvious place to stick that assig= nment, agreed. But I'm not sure the timelines do align. 793bis seems to progress at a slow= -but-steady pace (I'll point out it was supposed to be done two years ago..= .) but it seems likely that experiments want to happen sooner. Lars --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DA42Drznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I believe that 793bis gets more and more mature. W= e will need further reviews in the next months. Given that this is a -bis f= or an Internet Standard, there are unknowns=85 The tentative plan is a WGLC= early 2020.

 

A short PS focusing just on the assignment could p= erhaps be finished faster than 793bis. And that approach would also not cha= nge the scope of 793bis, i.e., 793bis would only include changes with IETF = consensus.

 

Because of that, I would slightly prefer a short d= edicated PS. But 793bis would also work for me. Any formally correct soluti= on is better than a process violation.

 

Michael

 = ;

 

Von: Lars Eggert
Gesendet: Montag, 4. November 2019 08:55
An: Joe Touch
Cc: Scharf, Michae= l; Mirja K=FChlewind; tcpm@ietf.org; = Richard Scheffenegger; Bob Briscoe=
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

 

On 2019-11-4, at 5:08, Joe Touch <touch@strayal= pha.com> wrote:
> Why do we need this process exception?
>
> We have 793bis in process. If we need to assign a bit in the header - = to any specific use or as experimental - that seems like the appropriate ve= nue in which to do so.

If the timelines align, that would be the obvious place to stick that assig= nment, agreed.

But I'm not sure the timelines do align. 793bis seems to progress at a slow= -but-steady pace (I'll point out it was supposed to be done two years ago..= .) but it seems likely that experiments want to happen sooner.

Lars

 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DA42Drznt8114rzntrzd_-- From nobody Mon Nov 4 00:20:23 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 D373B1208E6; Mon, 4 Nov 2019 00:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 un9dMO5rQV2U; Mon, 4 Nov 2019 00:19:58 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93A69120894; Mon, 4 Nov 2019 00:19:58 -0800 (PST) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 535B31B00064; Mon, 4 Nov 2019 08:19:51 +0000 (GMT) Message-ID: <5DBFDF26.5080101@erg.abdn.ac.uk> Date: Mon, 04 Nov 2019 08:19:50 +0000 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: Jonathan Morton CC: "Rodney W. Grimes" , "tcpm@ietf.org" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> In-Reply-To: <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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, 04 Nov 2019 08:20:01 -0000 On 03/11/2019, 13:08, Jonathan Morton wrote: >> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst wrote: >> >>> With respect to draft-ietf-tcpm-accurate-ecn and >>> draft-grimes-tcpm-tcpsce compatibility: >>> When accurate ecn (AccECN) fails to negotiate an AccECN capable session >>> it falls back to RFC3168 conformance, leaving a state that is fully >>> compatible with SCE, hence they are compatible. >> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN? > RFC-8511 doesn't change the signalling on the wire relative to RFC-3168. That was the sense intended here. > > - Jonathan Morton RFC3168 describes both endpoint behaviour and network functions. To me, this sentence is about how you receive indications of incipent congestion, the sender can change from using only CE to using CE plus the accurate information -or fall back to using just CE - ultimately it falls back to just detecting congestion (loss,delay). So yes, the CE signal could be regarded as input to SCE. The endpoint behaviour, I think, should fall back to RFC8511. Gorry From nobody Mon Nov 4 01:17: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 3B7BD120D84; Mon, 4 Nov 2019 01:17:13 -0800 (PST) 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, 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 r_S9pAi9Mi7R; Mon, 4 Nov 2019 01:17:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8A098120D7F; Mon, 4 Nov 2019 01:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572859027; bh=ggfCHP2vO/4u7p8XCIxUft6yagnvIa8LHf1DRuUolFI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=At61n2JVwHHm7m33E1xtzxsg3t8UVOa9auGi1hiUtUQNSoNWFHr8CScWZYtyI3pxH rDgykQez5gx97fzNir0KMdpoKEfqO7xomz0zu8b4TIhpg7BhGJel2eAWewdQ2Brgip KIEu0GfKWt4ltsvc66oHGK+6Cp1RJSPUbf1D2+go= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MsHns-1i6zLY0RI2-00tgnF; Mon, 04 Nov 2019 10:11:50 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: <5DBFDF26.5080101@erg.abdn.ac.uk> Date: Mon, 4 Nov 2019 10:11:48 +0100 Cc: Jonathan Morton , "Rodney W. Grimes" , "tcpm@ietf.org" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> <5DBFDF26.5080101@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:9tWeAfb/Ri2alT9BXCk75cYpBQGVBuhMUEhOUFUnlpS+w5scAal DEf6Tj85kb2FHt+HlaNRJlA6K8whCvOG2/pu410iBCTHTTBL91sLG4PpHwNqXVQn66KbSgJ fpV/HDAMk1bLEakef6WJTOsw5uR8lxBSOO47mkJSDjPPmgHfhI6nMee7BCf+ingx0Kya1Vt 1eRtMR/4nM7NuHkoLnlmg== X-UI-Out-Filterresults: notjunk:1;V03:K0:15J04BmW1/E=:u7/gHhYpC2jMEk0XsLtoDS KYcQ9QUVSg/G9pCc3XnpuwVpItgkEfoJmFG+ZKQXdTFfkbW4+O3dzjeG49i9y4GEuJ/o0BD4w /komWx2mOju7bCzhiOLGVi0zjWl87CxKbV3YmelYFHqpHavICBVf5cOE3FHyqKBwifmOtxTRv AS5/jE4y/+KlDcjmSopcvYpCegxXELFJ1tIYxofSy5GIx9qK63pqzp7/m2xGe5wfqQx/PU5FF xaEwcKKXIJpk9JDYp5EhVeI+f2Sgk34AHPEQE03Y/HpdsXn/wclzDhb2j2Yz+MGOwKzNFImZu R0vgPji3HGA6emZGbWkt4HKcZiBOOYKEpCKACUuF7YE6Gk5a+sfmUQ5YbjS6SCoNFxm905IM2 BrZGKxiaU7ZtGC1i37wR4GJBucmQxjnZRYNG04zShPqpqbCnYezk3NelyZoFyNza8FqXH4Kml logr3JJLVF9i/L2J/t9ctQ8ChwWkIkRlg5OOacIW7gD8n5iBNjg73B7SW9oRxwsrHyLcim1uL Bk6push3usRQjpNxu/0cei8AyhUYqwhae2Qz6cyUrGkJspNVY7TSQ9q72/RlOpQiuuKtrDBAI 8SRa6d+DkndLafyr7fLhWcGgMXLuEpiwkRvZDMokStBN3JY0TMbAdQFADhDtoDj2aVQbKJKa8 WrF9Jzjo94jSz4Y7DWuMQC2dam4rYwmUNK2MUPTM+TGVptMB9nRYj3u7Hzb1zZu5/Js5/dFQm mXMTQ7WmqOiwXimCWOeZg13LkI9lPl9nF3uEl4hwl6NKNlq03QWlWhkcwl3LNTIrNHoLcbwOe 2m/COt2NZ/fY6fzZeiqw7PzNO03jbYvofSZfEJzkrw9vE+wFDgznWKX2YNjU7gnZFwO8xQ6mf 59DdB9nya6ITuHl9F687zLiYfVcdqIyJzhuI53eZh65j09VRfyMYjvjaGD0ldjs7cUrYcoH3w tMrQrYn9A815VSgDZWf1odEjMVYEOZgS2QTT2EVb8pxMHez9ggBmAX9m2/Lrjwjr4NxHTTHOC KPikF/7qvR+Tfqus9OLvBy9cJc9K0HClcsgiW/VRAdvZNYeP/VtVGO8dLhoqTY6K6DRWUU+Vn Q7MSQj88K9LeQhEiDhMHyiM7SheOjb6ULXd1cpSqk82KKeR2Ju7qn0BgX1vMY8meRyVtW99KX Xg2zzEcJ9yUJSGHT29Oa2MUT7kVJEUhzp4X+Uqz+/maArnp2USJV9k3/GLnDDPUqTYtDQJ8sf d0U3sIQdS7DksZVnK76mJ+9pIY4aTH2KqTC51MQJ894iI46rPESLCB+JPnpg= Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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, 04 Nov 2019 09:17:13 -0000 > On Nov 4, 2019, at 09:19, Gorry Fairhurst = wrote: >=20 > On 03/11/2019, 13:08, Jonathan Morton wrote: >>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst = wrote: >>>=20 >>>> With respect to draft-ietf-tcpm-accurate-ecn and >>>> draft-grimes-tcpm-tcpsce compatibility: >>>> When accurate ecn (AccECN) fails to negotiate an AccECN capable = session >>>> it falls back to RFC3168 conformance, leaving a state that is = fully >>>> compatible with SCE, hence they are compatible. >>> I was expecting this to fall-back to RFC8511, treatment at the = endpointrs, since that is the most recent spec. Does that make any = difference to your thoughts abiout what you expect an endpoint to do = when it receives ECN-marking without Accurate ECN? >> RFC-8511 doesn't change the signalling on the wire relative to = RFC-3168. That was the sense intended here. >>=20 >> - Jonathan Morton > RFC3168 describes both endpoint behaviour and network functions. To = me, this sentence is about > how you receive indications of incipent congestion, the sender can = change from using only CE to using CE plus > the accurate information -or fall back to using just CE - ultimately = it falls back to just detecting congestion (loss,delay). > So yes, the CE signal could be regarded as input to SCE. >=20 > The endpoint behaviour, I think, should fall back to RFC8511. >=20 > Gorry >=20 Question: Since the ABE RFC is marked experimental while RFC3168 is a = proposed standard, why should tcpsce fall-back to RFC8511 instead of = RFC3168?=20 I ask as in the discussion of L4S it was (IMHO rightfully) argued that = including a requirement on another experimental RFC (RACK in that case) = was problematic as it would link basically independent experiments (and = introduce undesired fate-sharing). Sebastian From nobody Mon Nov 4 01:41:38 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 51AE212008D; Mon, 4 Nov 2019 01:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 S8o7YCa63kol; Mon, 4 Nov 2019 01:41:34 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1BCA12002E; Mon, 4 Nov 2019 01:41:33 -0800 (PST) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0FB251B000A3; Mon, 4 Nov 2019 09:41:25 +0000 (GMT) Message-ID: <5DBFF245.1040300@erg.abdn.ac.uk> Date: Mon, 04 Nov 2019 09:41:25 +0000 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: Sebastian Moeller CC: Jonathan Morton , "Rodney W. Grimes" , "tcpm@ietf.org" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> <5DBFDF26.5080101@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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, 04 Nov 2019 09:41:36 -0000 On 04/11/2019, 09:11, Sebastian Moeller wrote: > >> On Nov 4, 2019, at 09:19, Gorry Fairhurst wrote: >> >> On 03/11/2019, 13:08, Jonathan Morton wrote: >>>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst wrote: >>>> >>>>> With respect to draft-ietf-tcpm-accurate-ecn and >>>>> draft-grimes-tcpm-tcpsce compatibility: >>>>> When accurate ecn (AccECN) fails to negotiate an AccECN capable session >>>>> it falls back to RFC3168 conformance, leaving a state that is fully >>>>> compatible with SCE, hence they are compatible. >>>> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN? >>> RFC-8511 doesn't change the signalling on the wire relative to RFC-3168. That was the sense intended here. >>> >>> - Jonathan Morton >> RFC3168 describes both endpoint behaviour and network functions. To me, this sentence is about >> how you receive indications of incipent congestion, the sender can change from using only CE to using CE plus >> the accurate information -or fall back to using just CE - ultimately it falls back to just detecting congestion (loss,delay). >> So yes, the CE signal could be regarded as input to SCE. >> >> The endpoint behaviour, I think, should fall back to RFC8511. >> >> Gorry >> > Question: Since the ABE RFC is marked experimental while RFC3168 is a proposed standard, why should tcpsce fall-back to RFC8511 instead of RFC3168? Because, that is why the WG publishes EXP RFCs. My own understanding, is that to publish a PS update to TCP, it is good to have deployment experience. To get there, you need to alreday have completed detailed experiments in labs, etc, and show safety there and then have a proposal that has been accepted by the WG and developed into an RFC - The EXP RFC. Next comes the deployment, and decision about what to do next - many TCP RFC's remain EXP. In this case, the purpose of the RFC8511 experiment is to "collect experience with the deployment of ABE and confirm acceptable safety in deployed networks that use this update to TCP congestion control" and then to "propose it as a Standards-Track document in the future". (Section 6). > I ask as in the discussion of L4S it was (IMHO rightfully) argued that including a requirement on another experimental RFC (RACK in that case) was problematic as it would link basically independent experiments (and introduce undesired fate-sharing). That can indeed be an issue, if a new proposal comes along that depends on one of the existing experiments. That needs careful thought. > Sebastian Gorry From nobody Mon Nov 4 02:11:43 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 AF79412010E; Mon, 4 Nov 2019 02:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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] 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 qgDVKvYdZw9c; Mon, 4 Nov 2019 02:11:40 -0800 (PST) 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 157FE1200F6; Mon, 4 Nov 2019 02:11:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AEC2A25A28; Mon, 4 Nov 2019 11:11:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572862298; bh=sLBLDSWPKfvwcsVlqPvlAWYgYqCo8RfCWZcf7cjN22w=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ePIgQhst3xSKmykl2Dbue/SublFCwpBc5VuERciNYbw/Ydv6Eejat7zLgMl7SPNNL YX9TA7n9feRd3z7yfKn63Lr3g3W9nLutlLNXr7fSyHRyLQDo14CfFsDiIZKVkGzWZz PBr0XqjhgL1rAWFtIm3TDo3J7zxJ3yFO2EYcuUqI= 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 xNDiP7z60Cpq; Mon, 4 Nov 2019 11:11:38 +0100 (CET) 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; Mon, 4 Nov 2019 11:11:38 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 11:11:26 +0100 From: "Scharf, Michael" To: "gorry@erg.abdn.ac.uk" , Sebastian Moeller CC: "Rodney W. Grimes" , Jonathan Morton , "tcpm@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt Thread-Index: AQHVkujPHAgC8VHHbkilSp+8bjFG+ad6qTAAgAAIR4CAABVRMA== Date: Mon, 4 Nov 2019 10:11:25 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DAB93@rznt8114.rznt.rzdir.fht-esslingen.de> References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> <5DBFDF26.5080101@erg.abdn.ac.uk> <5DBFF245.1040300@erg.abdn.ac.uk> In-Reply-To: <5DBFF245.1040300@erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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, 04 Nov 2019 10:11:42 -0000 > Because, that is why the WG publishes EXP RFCs. >=20 > My own understanding, is that to publish a PS update to TCP, it is good > to have deployment experience. In this context, it makes sense to read the exact wording of RFC 7127: A Proposed Standard specification is stable, has resolved known design choices, has received significant community review, and appears to enjoy enough community interest to be considered valuable. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard will have no known technical omissions with respect to the requirements placed upon it. Proposed Standards are of such quality that implementations can be deployed in the Internet. However, as with all technical specifications, Proposed Standards may be revised if problems are found or better solutions are identified, when experiences with deploying implementations of such technologies at scale is gathered. In general, there is no strict formal requirement for implementation or ope= rational experience for a PS. But TCP is a core Internet protocol, i.e., th= e third quoted paragraph may apply. The TCPM working group has in several c= ases concluded that running an experiment first would be reasonable. In some of these cases, there is now implementation and operational experie= nce. In those cases, doing the PS is mostly a matter of WG energy... Michael From nobody Mon Nov 4 02:23:26 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 C09D3120CEE for ; Mon, 4 Nov 2019 02:23:24 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=it.uc3m.es 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 nljqJ0EzUyUu for ; Mon, 4 Nov 2019 02:23:20 -0800 (PST) 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 D077612096E for ; Mon, 4 Nov 2019 02:23:19 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id n21so3306955ljg.12 for ; Mon, 04 Nov 2019 02:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=i7uUqWBLG3hMsW1LV1SRrHqUl/czWWPukTh7r/nP2q4=; b=EKP8k/wugDRkNrXjMbUeMgWMsTqrEo+9PwZpOX8GybS9OoYV3S1bSLo5P270X0Pmie mIAWmT1bmh8BUthRq3i0j7NJovL/ZrhdjpQMyknFOthPYCDR1AjjvLSxJX6tt9lv6eGk VLmt/rhSudo0RTmak2l/Cm+2ccRTrAmWooFcSs9bUR/s3ntqRwtWG3sQ0W+WS4Ops020 XQJS9p/XnYXVC7JiMmB65fdpp1vo29b24dlodCyxLGMREcoHlO8IKxjkRB9DUQk+L7uP IE+04VkOfYW7Rm9rHY/dzNSaLVzljO22MYSPVJsCVcA9dFyYqRYsaApgVqzeRPAyTlbz RrNA== 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:content-transfer-encoding; bh=i7uUqWBLG3hMsW1LV1SRrHqUl/czWWPukTh7r/nP2q4=; b=aSryOeEYMqZPDGlUICfXACE+prdhrQOiRwbUW5/lrBkG9mOSVR6Y3OfwxLRLaBsHGu PW2Vi0g39X0fh/NrWFN9tGOTqAkwglJq0+y57lZ97NcX2myFAXIU8S6XghJ1/fPm/AjJ bqu/ltp4LSbZXvfVOCXG8Eb71vlxNzPwwRehoRptLl2vcn4j1IfScHmw0YvPopbYuCYw xg+sL+pW2nTI+pXmVn6uimi3t5j83iRC0JivSx+uTMtX8GdIz4jWZh7rE9q+fYrJIEOx 8pl0aXc78ZO5s+l8dsddaBE7lG8r94ZuRHlRUGBhzewXwxZb36/EYUBgpEpdddpHv7nf MX1g== X-Gm-Message-State: APjAAAX4T0GJTMYjs8G9ge7VaYqmyuZlNBfa6P4CekBgSCAkBnBor4xg n0xgENUxx9hXLL5bG7d+4r/pPixjB26hLaopzWdXY0KPbgE= X-Google-Smtp-Source: APXvYqyywYzcNLzUO2mFpwwv+F0bYwbSWOxDlE8cQfcMvJ/oPW5ZrvMfNmRMVHKhTyLzrcbZoi5xvj3pBLgyTtdBszo= X-Received: by 2002:a2e:8118:: with SMTP id d24mr17173397ljg.111.1572862996605; Mon, 04 Nov 2019 02:23:16 -0800 (PST) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D4379D8@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: From: MARCELO GABRIEL BAGNULO BRAUN Date: Mon, 4 Nov 2019 11:23:04 +0100 Message-ID: To: tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-generalized-ecn-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: Mon, 04 Nov 2019 10:23:25 -0000 Hi Michael, Thank you very much for the detailed review. This is indeed very helpful to converge. I also apologize for the delay in replying. We have quite a bit of back and forth with Bob crafting this reply, so please refer to the 05 version submitted for the final text. I have tried to capture the reply to each comment below. Replies below. El mar., 10 sept. 2019 a las 13:00, Scharf, Michael () escribi=C3=B3: > > Marcelo, Bob, > > Please find below review of draft-ietf-tcpm-generalized-ecn-04, without a= ny hat. The context is my review of draft-ietf-tcpm-accurate-ecn that is po= sted separately. > > Macroscopic feedback: While the document provides a lot of excellent reas= oning for why it is appropriate to set ECT on most control segments, the tw= o cases in which this document mandates use of draft-ietf-tcpm-accurate-ecn= , as well as several algorithmic design choices, are IMHO not well enough m= otivated. My last TCP implementation experience is many years ago, and mayb= e my knowledge is simply too outdated to be relevant today. But when I read= the document, I repeatedly run into the question "why should I indeed impl= ement that this way if I had to do so?". I will provide specific details be= low. I guess my main high-level message is that the text should introduce e= arly in the document that all mechanisms have been defined conservatively a= nd with safety in mind, possibly at the cost of performance and efficiency. I have added at the end of the second paragraph of the introduction, the following sentence: The mechanisms proposed in this document have been defined conservatively and with safety in min= d possibly in some cases incurring additional cost in terms of performa= nce efficiency. > > This is reasonable for an IETF document. But in a real-world Internet, fo= r instance with initial congestion windows bigger than 10 being accepted by= (some) implementers, I believe very careful and conservative design choice= s must be well explained. Otherwise there is a significant risk of just bei= ng ignored. Personally, I believe that also less conservative design choice= s would also work in an experiment, but I cannot proof that by data, i.e., = it is speculation only. > I will address each of the cases you mention below. > > Major issues (not ordered by priority): > > * Section 1. Introduction > > "Nonetheless, if the client does not > implement AccECN, it cannot use ECN++ on the one packet that offers > most benefit from it - the initial SYN." > > I don't fully agree to this (see below). But, putting this aside, I thi= nk it should be explained at least with some words early in the document wh= y the SYN is challenging, in particular since SYN segments would benefit mo= st. A reference to the later details would work, but actually I would try t= o provide the high-level rationale early to those who don't read the docume= nt to the every end... The explanation why ECN marking in the SYN is critical is described in section 1.1, literally, the paragraph after the next one, so I pointed out in the text that the reason why this is critical is explained in the following subsection. I have modified the text as follows: Using ECN on initial SYN packets provides significant benefits, as we describe in the next subsection. However, only AccECN provides a way to feed back whether the SYN was CE marked, and RFC 3168 does not. Therefore, implementers of ECN++ are RECOMMENDED to also implement AccECN. Conversely, if AccECN (or an equivalent safety mechanism) is not implemented with ECN++, this specification rules out ECN on the SYN. (the reference to further safety mechanisms is related to the concern you expressed below, please see below) > > * Section 1.1 > > "Finally, there are ongoing experimental efforts to promote the > adoption of a slightly modified variant of DCTCP (and similar > congestion controls) over the Internet to achieve low latency, low > loss and scalable throughput (L4S) for all communications > [I-D.ietf-tsvwg-l4s-arch]. In such an approach, L4S packets identify > themselves using an ECN codepoint [I-D.ietf-tsvwg-ecn-l4s-id]. With > L4S, preventing TCP control packets from obtaining the benefits of > ECN would not only expose them to the prevailing level of congestion > loss, but it would also classify them into a different queue. Then > only L4S data packets would enjoy ultra-low latency forwarding, while > the packets controlling and retransmitting these data packets would > still get stuck behind the queue induced by legacy ('Classic') TCP > traffic." > > I fail to understand why this document must present L4S in such detail.= As L4S has been mentioned and references already earlier in the introducti= on, this text could just be removed, IMHO. If the authors prefer to keep th= is section, I ask to reconsider the wording: > 1/ The wording "only L4S data packets would enjoy ultra-low latency f= orwarding" should be phrased using neutral statements , such as "only L4S p= ackets would be classified into the L4S queue that may have lower latency" I have adapted your text as follows: only L4S packets would be classified into the L4S queue that is expected to have lower latency I guess we would agree that this is the case. > > 2/ The term "legacy ('Classic') TCP" should be replaced by a term wit= hout negative connotation, such as "standard TCP", "non-L4S-enabled TCP", o= r the like. As I have mentioned on the TSVWG list, I disagree with using te= rms such as "Legacy TCP", "Classic TCP", etc. when referring to a modern TC= P implementation compliant to the standards published by TCPM. Note that I = am fine with the terms "Classic ECN" or "Classic ECN feedback" if these ter= ms have consensus in TSVWG. > I have changed it to non-L4S-enabled TCP. Actually, this appeared only once in whole document. > * Section 3.2 > > "It can be seen that the sender cannot set ECT on the SYN if it is not > requesting AccECN feedback." > > As mentioned before, I think this is one of the cases in which reasonin= g is needed as it is not trivial to understand the root cause. A reference = to a later section could work. So, the reason why we (as WG) decided against supporting ECN marking of the SYN packets when AccECN is not supported is to prevent the consumption of reserved bits in the TCP header for this purpose. I mean, as currently defined, we need to be able to identify 3 types of servers, namely, non-ECN servers, classic ECN servers and AccECN servers (which already defined the encoding of the CE mark in the SYN packet). If we were to also support classic ECN servers that support ECN++, this would be a new type of server that would then require an additional codepoint in the TCP header. We deemed this was wasteful (considering that there are very few bits reserved available) and especially considering that when we asked the WG (in several occasions) no-one expressed any interest in the support of a classic ECN server that supported ECN++. In any case, we changed the text as follows: s/ It can be seen that the sender cannot set ECT on the SYN if it is not requesting AccECN feedback. / t can be seen that we recommend against the sender setting ECT on the SYN if it is not requesting AccECN feedback. / > > Having said this, I'd like to raise a question related to the type of I= oT scenarios discussed in draft-ietf-lwig-tcp-constrained-node-networks: Wh= y would a TCP sender that sends at most one MSS of data per RTT (e.g. CWND= =3D1 MSS fixed at least during the first two RTTs) have to implement AccECN= to be allowed to set ECT on SYN? Note that the document explains in Sectio= n 3.2.1.3 why a back-off of the RTO is not needed. Also, note that RFC 8085= basically explains (for UDP) that one packet per RTT may be OK in today's = Internet. Of course, such a sender would not make much use of any ECN conge= stion feedback in any circumstances. But if there is an environment in whic= h packets market by ECT get better service than non-ECT packet, why should = this narrow-band server with small code footprint not leverage the benefits= of setting ECT in SYNs without the complexity of AccECN? > > > * Section 3.2 > > "Therefore it is RECOMMENDED that the > experimental AccECN specification [I-D.ietf-tcpm-accurate-ecn] is > implemented (as well as the present specification)" > > I have repeatedly mentioned the downsides of creating dependencies betw= een documents. In this case, the risk is that the AccECN experiment fails (= e.g., the IETF has to obsolete it in some years because another alternative= has been found). The same applies if a standards-track RFC of AccECN would= not be backward-compatible for whatever reason. His would be a pity since = significant parts of the document are entirely independent of AccECN. This = risk could be reduced by not mandating a particular specification, but mand= ating functional requirements. > > For instance, I believe that ECT on SYNs can always be set if there is = a mechanism that reliably echos CE marks on SYNs back to the sender. AccECN= is a solution to this, and the only solution we currently have, but we are= dealing with experiments, not standards, so who knows what will happen in = some years from now? To me, a better wording would be along the lines of (n= eglecting the previously mentioned exception): "ECT on SYNs can only be set= if there is a corresponding feedback scheme. The experimental AccECN speci= fication [I-D.ietf-tcpm-accurate-ecn] provides this feedback. It is RECOMME= NDED to implement an accurate feedback scheme as well as the present specif= ication." I merely show this as an example that would not be impossible to = better decouple documents. As long as I am the only person who brings up th= is point, I don't ask for this specific change to be implemented. I just li= ke to record my concern including potential solutions (e.g., for a document= shepherd). > I agree with this approach. I have modified the document in several parts to provide guidance about how to enable ECN++ in future ECN feedback mechanisms to be defined. However, as of today, there are only two ECN feedback mechanisms for TCP defined, standard ECN and AccECN. We have also been asked to ensure this draft is concrete and clear, so we want to describe in detail what ECN++ should do in both cases as the document does. So, my proposal is to 1) keep all the guidance and reccomendations regarding legacy ECN and AccECN feedback and 2) provide guidance on the ECN++ support for future ECN feedback mechanisms, based on the funcitonality required, as you suggest. To achieve that I have modified the following subsections: In the Introduction, I have included: ECN++ uses a sender-only deployment model. It works whether the tw= o ends of the TCP connection use classic ECN feedback or experimental Accurate ECN feedback (AccECN ), the only two ECN feedback mechanisms for TCP standardised at the time of this writing. Nonetheless, if the client does not implement AccECN, it cannot use ECN++ the initial SYN packet. Using ECN in the SYN packets provides significant benefits, as we des= cribe in the next subsection. However, unlike RFC 3168 feedback, AccECN pro= vides a way for a TCP server to feed back whether a SYN arrived marked CE. = So, if the client does not implement AccECN, it could be unsafe to use EC= N++ on the initial SYN packet. Therefore, implementers of ECN++ are RECOMMENDED to also implement AccECN. In this document, we also provide guidance regarding the ECN++ support for future ECN feedback mechanisms for TCP based on the the functionality requir= ed to enable ECN marking of the different packets. Then in section 3.2 I modified the following paragraph as follows: Nonetheless, this specification also caters for the case where a= n ECN++ TCP sender is not using AccECN. This could be because it does not support AccECN or because the other end of the TCP connection d= oes not (AccECN can only be used for a connection if both ends support it). Also, section 3.2.1.1. was modified as follows: With classic ECN feedback, the SY= N was not expected to be ECN-capable, so the flag provided to feed ba= ck congestion was put to another use (it is used in combination wi= th other flags to indicate that the responder supports ECN). In contrast, Accurate ECN (AccECN) feedback provides a codepoint in= the SYN-ACK for the responder to feed back whether the SYN arrived marked CE. Therefore the setting of the IP/ECN field on the SYN= is specified separately for each case in the following two subsections. If in the future, additional ECN feedback mechanisms are defined for TCP, it would only be possible to enable the ECT ma= rking of the SYN packets as long as the new ECN feedback mechanism provides the means to feed back the CE marking of the SYN back to the TC= P initiator. If this is the case, the new ECN feedback mechanism should follow the same recommendation described below for AccECN regar= ding the processing of the SYN packets. > > * Section 3.2.1.1.2 > > "A TCP initiator MUST NOT set ECT on a SYN if it does not also attempt= to negotiate Accurate ECN feedback in the same SYN." > > See above. This should have been addressed by the replies to the previous comments. > > If CWND is kept at one MSS during the beginning of the connection, I don'= t understand the rationale for the MUST. I understand that most TCP senders today use an IW larger than one. I understand you mean that it would be possible to ECT mark the SYN as long as the IW is kept to 1MSS. But this is a significant performance penalty for most TCP senders. In order to enable this possibility I have added the following text: 3.2.1.1.2. ECN++ TCP Client does not Support AccECN If the SYN sent by a TCP initiator does not attempt to negotiate Accurate ECN feedback, or does not use an equivalent safety mechanism, it MUST still comply with RFC 3168, which says that a TCP initiator "MUST NOT set ECT on a SYN". The only envisaged examples of "equivalent safety mechanisms" are: a) some future TCP ECN feedback protocol, perhaps evolved from AccECN, that feeds back CE marking on a SYN; b) setting the initial window to 1 SMSS. IW=3D1 is NOT RECOMMENDED because it could degrade performance, but might be appropriate for certain lightweight TCP implementations. See Section 4.2 for discussion and rationale. If the TCP initiator does not set ECT on the SYN, the rest of Section 3.2.1 does not apply. > > > * Section 3.2.1.2. Caching where to use ECT on SYNs > > I think it could be useful to reference RFC 2140 / 2140bis (non-normati= vely) and possibly adapt to the terminology therein. The same may apply to = later sections discussing caching. I added a reference to 2140 (i didnt used 2140 bis as it is still a draft and i is expired) > > > * Section 3.2.1.3. SYN Congestion Response > > "If the SYN-ACK returned to the TCP initiator confirms that the server > supports AccECN, it will also indicate whether or not the SYN was CE- > marked. If the SYN was CE-marked, the initiator MUST reduce its > Initial Window (IW) and SHOULD reduce it to 1 SMSS (sender maximum > segment size)." > > Regarding the MUST: How can a sender meet the MUST requirement if IW wa= s 1 MSS? > Rephrased as If the SYN is CE-marked, if the initial window was greater than 1 MSS, then, the initiator MUST reduce its Initial Window (IW) and SHOULD reduce it to 1 SMSS (sender maximum segment size). > > Regarding the SHOULD: This is one example for which the draft picks a v= ery conservative approach. Being conservative is not wrong but should be we= ll explained (see below). The motivation for this is described later in the draft, I have included a forward reference to section 4 where this is justified. > > > * Section 3.2.1.3. SYN Congestion Response > > "If the initiator has set ECT on the SYN and if the SYN-ACK shows that > the server does not support AccECN, the TCP initiator MUST > conservatively reduce its Initial Window and SHOULD reduce it to 1 > SMSS. A reduction to greater than 1 SMSS MAY be appropriate (see > Section 4.2.1). Conservatism is necessary because a non-AccECN SYN- > ACK cannot show whether the SYN was CE-marked." > > Regarding the MUST, I have the same question like in the previous commen= t, i.e., the guidance when IW is already 1 MSS . > rephrased as If the initiator has set ECT on the SYN and if the SYN-ACK shows that the server does not support AccECN and if the initia= l congestion window of the initiator is greater than 1 MSS, then the TCP initiator MUST conservatively reduce its Initial Window and SHOULD reduce= it to 1 SMSS. > > The SHOULD is one of the cases that really need backing. Unfortunately, = as explained below, I have doubts that the current wording in Section 4.2.1= sufficiently explains this SHOULD. As a result, I either believe that the = explanation in Section 4.2.1 needs to be improved, or, if that is not possi= ble, this guidance could have to be reviewed (e.g., "MAY reduce it to 1 SMS= S"). The justification is what is currently written in the draft. I mean, the sender is unable to know if the SYN was marked, so it should assume the worst case, i.e. it was CE marked. Besides, the sentence right after the one you copied above states: "A reduction to greater than 1 SMSS MAY be appropriate", so the draft already allows the implementer to reduce to a larger value than 1 MSS! > > BTW, if I had to implement the protocol, this is one of the cases where I= would consider violating the spec from day one, given the potential harm o= n TCP performance. By reducing the IW to a value larger than 1 MSS, you wouldnt be violating the spec, as it is already supported in the current text. > > Luckily, I am not an implementer... Anyway, this brings me to another poi= nt: Are there no "MEASURMENTS NEEDED" in Section 3.2.1.3, e.g., regarding p= otential impact on application-layer performance, performance/robustness co= mparison of different strategies, and the like? I think there are needed many more measurements than the ones explicitly spelled out in the document. I guess for each subsection, there are several relevant measurements that would allow to understand the experiment. I am unconvinced it would be useful to spell them all out. It may be better to eliminate the current ones, as they will always be an incomplete list of measurements. what do you think? In the spirit of keeping the current ones as representative of some relevant measurements needed, we've added EXPERIMENTATION NEEDED (not just MEASUREMENTS NEEDED) bullets in the 2 places within the rationale section where response to congestion on a SYN or SYN-ACK is discussed. And referred to these from 1.2. > > > * Section 3.3.2 SYN (Receive) > > "Some implementations of TCP servers (e.g. current Linux) assume that, > if a host receives a SYN with a non-zero IP/ECN field, it must be due > to network mangling, and they disable ECN for the rest of the > connection. Section 4.2.2.2 finds that this type of network mangling > seems to be virtually non-existent so it would be preferable to > report any such mangling so it can be fixed." > > The term "current Linux" is not specific. To a reader of the RFC in som= e years from now, it will not be clear to what this refers to. So, at minim= um this draft would have to be specific about kernel versions etc. And oper= ating systems change. But, more importantly, I do not believe that discussi= ng implementation choices belongs into the normative part of the specificat= ion at all. Thus, I think that at minimum "(e.g., current Linux)" should be= removed in the normative part of the document. Ok, I removed the current linux part. > > > * Section 4.2.1 Argument 1a: Unregognized CE on the SYN > > "Happily, the appropriate conservative congestion response is to > reduce the initial window, and it is extremely rare for a TCP client > to send more than one packet as its initial request anyway. Any > clients that do frequently use a larger initial window for their > first message to the server can cache which servers will not > understand ECT on a SYN (see Section 4.2.3 below)." > > I disagree with the entire first sentence. First, I fail to understand = why "it is extremely rare for a TCP client to send more than one packet as = its initial request". For instance, I believe that FTP is a counter-example= . There is a huge amount of application protocols running on top of TCP. An= d which protocols are "rare" depend _a_ lot on what traffic mix one looks a= t. What data backs this claim for _all_ protocols using TCP in all IP netwo= rks? > > I agree that this statement may be true for Web browsing. HTTP is an ex= tremely relevant protocol for TCP (well, still), but by far not the only TC= P protocol, there are probably even HTTP use cases with huge POST/PUT reque= sts. So, this statement must either be backed for all TCP-based application= or be removed. > > Second, I disagree with the term "appropriate" unless sufficient data i= s provided regarding the first point. And unless this is fixed, this docume= nt IMHO lacks an explanation of why the particular design choice is indeed = "appropriate". I don't know how to easily fix this; potential solutions cou= ld e.g. include relaxing the requirements to less conservative guidance, op= enly state that the algorithm is just a conservative design choice, ... or = provide data from running code backing the claim. > > I also believe that the follow-up sentence "Any clients that do frequen= tly use a larger initial window for their first message to the server can c= ache which servers will not understand ECT on a SYN" needs backing that exp= lains why this indeed works for "any" client. For instance, what may work f= or me would be a worst-case analysis of the number of peers (tens of thousa= nds, or even more?) that a given client may have, experience from running c= ode, or some reference to a scientific study. But I do believe that some fo= rm of backing is needed that this works for "any" client. If that is not po= ssible, both the tone of the text and possible the normative guidance would= have to be adapted to make clear that there is uncertainty whether this in= deed works well in "any" case. > I have rephrased the paragraph scoping it to http. the wording is as follows The recommeded conservative congestion response is to reduce the initial window, which does not affect the performance = of very popular protocols such as HTTP, since it is extremely rare for an HTTP client to send more than one packet as its initial re= quest anyway (for data on HTTP/1 & HTTP/2 request sizes see ). > > 4.2.3. Caching Strategies for ECT on SYNs > > "For instance, if a user's Internet access bottleneck supported L4S EC= N > but not Classic ECN, strategy (S2A) would make most sense and there > would be no point trying to avoid the 'over-strict' test and > negotiate Classic ECN. [and several following paragraphs]" > > I believe this discussion could take place in an L4S document, e.g., su= bmitted to TSVWG, since it contains L4S-specific assumptions. A reader may = not understand this without reading the L4S specifications. To me, this is = a non-starter for a document in TCPM. > Ok, we have made the following changes: Created an L4S subsection under section 5, which discusses interactions with other experimental protocols. And move this example to there, referring forward from this caching section= . > > 4.3.2. Response to Congestion on a SYN-ACK > > [After a pretty detailed discussion...] > "Therefore, TCP's response to a CE-marked SYN-ACK can be similar to > its response to the loss of _any_ packet, rather than backing off as > if the special _initial_ packet of a flow has been lost." > > This section contains some good and reasonable discussion. It concludes= with a very conservative design (Slow-Start from IW1). I agree that the de= sign choice sounds safe. I was probably save in the Internet 20 years ago, = and is therefore still safe today. But, well, the response to "loss of _any= _ packet" in TCP congestion control is more or less having the rate (and ma= ny stack may do less without running into issues), and TCPM has started the= ABE experiment that even allows a smaller reduction for CE. Are we really = convinced that we must experiment with one of the most conservative possibl= e protocol designs? I really wonder if implementers would implement ECN++ w= ith those parameters in a production deployment and see a performance benef= it in doing so. > In this case, the reduction to 1 MSS is a SHOULD, not a must, so implementers and other parties forming part of the experiment can use different values if they understand the implications. This is why we included all these rationale and motivation sections. > > * 4.4.2. Summary: Enabling ECN on Pure ACKs > > "During review of this specification, it was decided that allowing > hosts to set ECT on Pure ACKs without a feasible response mechanism > would set an undesirable precedent. It would certainly improve the > flow's own performance, but it would slightly increase potential harm > to others. Therefore, Section 3.2.3 allows ECT on Pure ACKs if > AccECN feedback has been negotiated, but not with classic RFC 3168 > ECN feedback." > > To me, "slightly increase potential harm" is a weak justification. Do w= e have any data on how relevant this problem may be, e.g., from running cod= e? Personally, I am not convinced by what is written here (but, like elsewh= ere, I am perfectly fine with being in the rough part of the consensus). Un= fortunately, I can't offer data to proof my opinion. At minimum, what I wou= ld suggest is to rephrase this paragraph to something like: > > "This specification uses a safe approach. Allowing hosts to set ECT on= Pure ACKs without a feasible response mechanism could result in risk. It = would certainly improve the flow's own performance, but it would slightly i= ncrease potential harm to others. Therefore, Section 3.2.3 allows ECT on Pu= re ACKs if AccECN feedback has been negotiated, but not with classic RFC 31= 68 ECN feedback." > ok, i replaced the current text by your proposed text, slightly modified to include the precendet argument, that I think it should be preserved. This specification uses a safe approach. Allowing hosts to set ECT on Pure ACKs without a feasible response mechanism could resu= lt in risk. It would certainly improve the flow's own performance, b= ut it would slightly increase potential harm to others. Morevoer, if would set an undesirable precedent regading the lack of response to congestion signals. Therefore, allows ECT on Pure ACKs if AccECN feedbac= k has been negotiated, but not with classic RFC 3168 ECN feedback. > > * Section 5.1. IW10 > > "As specified in Section 3.2.1.1, a TCP initiator can only set ECT on > the SYN if it requests AccECN support. If, however, the SYN-ACK > tells the initiator that the responder does not support AccECN, > Section 3.2.1.1 advises the initiator to conservatively reduce its > initial window to 1 SMSS because, if the SYN was CE-marked, the SYN- > ACK has no way to feed that back. > > If the initiator implements IW10, it seems rather over-conservative > to reduce IW from 10 to 1 just in case a congestion marking was > missed. Nonetheless, the reduction to 1 SMSS will rarely harm > performance, because: > > o as long as the initiator is caching failures to negotiate AccECN, > subsequent attempts to access the same server will not use ECT on > the SYN anyway, so there will no longer be any need to > conservatively reduce IW; > > o currently, at least for web sessions, it is extremely rare for a > TCP initiator (client) to have more than one data segment to send > at the start of a TCP connection [28; Fig 3] - IW10 is primarily > exploited by TCP servers." > > See my previous questions. I do not understand why there is no deployed= TCP-based application with some reasonable share of traffic that sends mor= e than one segment at the beginning of the TCP connection. This document de= als with all TCP usage; it is not written only for the communication betwee= n Web browsers and Web servers. For instance, why would the TCP client in a= n FTP session not use IW10? I disagree that one can generalize from HTTP to= all TCP-based application protocols. And there is also no evidence that ca= ching will work for any TCP protocol. For that, the worst-case scenario wou= ld be end-systems that maintain TCP connections to _many_ peers (at least t= ens of thousands of peers, maybe even more). How well will caching work in = such cases? If those statements are not backed better, the text already exp= lains what a reader could conclude: "it seems rather over-conservative to r= educe IW from 10 to 1 just in case a congestion marking was missed." Yes, i= ndeed, unless proven otherwise. There are several aspects to this comment: First, section 3.3.1.3 recommends to reduce the IW to 1 MSS, but it allows for the initiator to use a greater window. So, an implementer can decide whether to follow the recommendation or not. This section serves the purpose of informing the implementors when deciding whether they will follow the recommendation or not. I believe that it is useful for them to provide information about the impact in web traffic, as it does account for a large set of the traffic. If the implementaros have a different applications use case in mind, she shouldnt take this into account. Similarly for caching. Keep in mind that caching is relevant in clients. I would assume that a very large majority of clients would work well with a smaller cache than your worst case. If an implementor expects that several tens of thousands of outgoing connections will be the usual case, she should not consider this argument neither. Again, this is a non normative part of the specification. Keeping these arguments here, allow the implementors to not follow the recommendation if the arguments here are not convincing. > > > * Section 5.1. IW10 > > If a responder receives feedback that the SYN-ACK was CE-marked, > Section 3.2.2.2 mandates that it reduces its initial window to 1 > SMSS. When the responder also implements IW10, it is particularly > important to adhere to this requirement in order to avoid overflowing > a queue that is clearly already congested. > > Here the document is internally consistent. In Section 3.2.2.2. it argu= es that "the ECN feedback proves that the network is delivering packets suc= cessfully and is not severely overloaded." And in this section it argues th= at the queue is clearly congested. Please ensure that the document is consi= stent. I reworded as: When the responder also implements IW10, it is particularly important to adhere to this requirement in order= to avoid overflowing a queue that has clearly already been building up= . > > > For what it is worth, I personally believe a "clearly congested" queue = would drop packets instead of marking them. Of course, a reduction to IW 1 = is safe according to all what we have learnt in the last 20 years in the In= ternet. But to me it is very conservative compared to, well, some of the co= ngestion control algorithms running in today's Internet. I personally would= speculate that we have some more head-room before running into Internet co= ngestion collapse. Yet, of course, the usual trade-offs for congestion cont= rol apply. To me, his sounds like a good area for which further data is nee= ded from experimentation. I'd like to record that I am personally not convi= nced by the reasoning in the document. But, I don't have data. And, I am al= ways willing to learn from running code. > > * References > > I am somewhat surprised to see RFC 793 as an informative reference only= . Some other references could also be normative. > I moved 793 to normative > > > Minor comments: > > * Section 1.1 > > "Non-ECN control packets particularly harm performance in environments > where the ECN marking level is high." > > Is my understanding correct that this means "Not using ECN on control p= ackets can be particularly detrimental to performance in environments where= the ECN marking level is high"? I am not sure if the control packets indee= d cause "harm". ok, used your wording > > > * Section 2 > > Better would be the wording in RFC 8174 added > > > * Section 2 > > "Optionally, it could mean ECT(1), which is in the process of being red= efined for use by L4S experiments [RFC8311] [I-D.ietf-tsvwg-ecn-l4s-id]." > > I don't understand why this matters here given that section 1 already e= xplains that this document is compatible with L4S. but it makes sense to mention it here, since we provide some justification why by default is ECt(0) and what about ECT(1). > > > > > * 3.3.3. Pure ACK (Receive) > > "Currently AccECN feedback is required to count CE marking of any cont= rol packet including pure ACKs." > > Why "currently"? Removed the currently > > > * Section 4.9. General Fall-back for any Control Packet > > "And particularly given that > unnecessarily removing ECT from other control packets could lead to > performance problems, e.g. by directing them into an inferior queue > [I-D.ietf-tsvwg-ecn-l4s-id] or over a different path, because some > broken multipath equipment (erroneously) routes based on all 8 bits > of the Diffserv field." > > I think "inferior" has to be replaced by a neutral term, e.g., "another= " queue. I don't think that the queue would always be "inferior", e.g., if = DiffServ was used. And, yes, this quite directly runs into L4S-specific que= stions and that are entirely out-of-scope of this document... All that coul= d be avoided by reducing the references to L4S. > changed inferior with another queue. > > * 5.3. TCP Derivatives > > "Experience from experiments on adding ECN support to all TCP packets > ought to be directly transferable between TCP and derivatives of TCP, > like SCTP or QUIC." > > I would suggest to use at least another term instead of "TCP Derivates"= , such as "other Internet transport protocols". And I think this section co= uld actually either be removed or moved to an appendix. > I changed it to other transport protocols. Regards, marcelo > > > Thanks > > Michael -- MARCELO GABRIEL BAGNULO BRAUN Universidad Carlos III de Madrid -- MARCELO GABRIEL BAGNULO BRAUN Universidad Carlos III de Madrid --=20 MARCELO GABRIEL BAGNULO BRAUN Universidad Carlos III de Madrid From nobody Mon Nov 4 06:06: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 C0A65120099 for ; Mon, 4 Nov 2019 06:06:14 -0800 (PST) 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 aMvrNMZ5-2Gh for ; Mon, 4 Nov 2019 06:06:13 -0800 (PST) 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 0B4C51200E7 for ; Mon, 4 Nov 2019 06:06:13 -0800 (PST) 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=44xiZtNP+4YV7Y4/ZJ4aG474hO0Gfyn9oezvINet7L0=; b=TGRlncZH+w2U8aeA/79Fs0idV 3IQsCqwziDI9cUaYNk/khPV9fW60H7OSPqZVqGgxfpSGwNlSFlHhT09t3rLrMg+0rRSc1qKAsJMJL 0E/7QyouxST//Ywc+pXBPGbqGOBG4HNqBQxDp4dH2xHDf7PH7XUVktOG0WwjTaQDTiGx+EuCyBQzs GsxMRKt/TS/hD7IWQPY43wCxfNIiGmqREAdMQBrVSrtDf4yLSHaC0ilDhmy14z2IlHaRSSZ3T7MZ8 4w6ktYRYtUVlyHF/qWsNT1LykWjJys3VXN/E2T2mYlyxcvhBnLySqoILLtwjIm/RRl0/iVY+ejBro xJOxQbqaQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55615 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 1iRczf-0033V8-5x; Mon, 04 Nov 2019 09:06:11 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_3014191C-FFB6-42B1-A764-6932096AADAB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4DA42D@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Mon, 4 Nov 2019 06:06:04 -0800 Cc: Lars Eggert , Richard Scheffenegger , "tcpm@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Bob Briscoe Message-Id: References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> <8B6C0F6F-2812-49C1-9DBF-070E00E1D391@eggert.org> <6EC6417807D9754DA64F3087E2E2E03E2D4DA42D@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" 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] On allocating reserved bits in the TCP header 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, 04 Nov 2019 14:06:15 -0000 --Apple-Mail=_3014191C-FFB6-42B1-A764-6932096AADAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Slow but steady is the only way we should be modifying TCP.=20 I don=E2=80=99t expect this =E2=80=9Cshort PS=E2=80=9D to get through = faster than 793bis anyway. I.e., it=E2=80=99s a big leap from agreeing = on process to agreeing on the solution. Joe > On Nov 4, 2019, at 12:11 AM, Scharf, Michael = wrote: >=20 > I believe that 793bis gets more and more mature. We will need further = reviews in the next months. Given that this is a -bis for an Internet = Standard, there are unknowns=E2=80=A6 The tentative plan is a WGLC early = 2020. > =20 > A short PS focusing just on the assignment could perhaps be finished = faster than 793bis. And that approach would also not change the scope of = 793bis, i.e., 793bis would only include changes with IETF consensus. > =20 > Because of that, I would slightly prefer a short dedicated PS. But = 793bis would also work for me. Any formally correct solution is better = than a process violation. > =20 > Michael > =20 > =20 > Von: Lars Eggert > Gesendet: Montag, 4. November 2019 08:55 > An: Joe Touch > Cc: Scharf, Michael ; Mirja = K=C3=BChlewind ; tcpm@ietf.org = ; Richard Scheffenegger ; = Bob Briscoe > Betreff: Re: [tcpm] On allocating reserved bits in the TCP header > =20 > On 2019-11-4, at 5:08, Joe Touch > wrote: > > Why do we need this process exception? > >=20 > > We have 793bis in process. If we need to assign a bit in the header = - to any specific use or as experimental - that seems like the = appropriate venue in which to do so. >=20 > If the timelines align, that would be the obvious place to stick that = assignment, agreed. >=20 > But I'm not sure the timelines do align. 793bis seems to progress at a = slow-but-steady pace (I'll point out it was supposed to be done two = years ago....) but it seems likely that experiments want to happen = sooner. >=20 > Lars >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_3014191C-FFB6-42B1-A764-6932096AADAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Slow = but steady is the only way we should be modifying TCP. 

I don=E2=80=99t expect = this =E2=80=9Cshort PS=E2=80=9D to get through faster than 793bis = anyway. I.e., it=E2=80=99s a big leap from agreeing on process to = agreeing on the solution.

Joe

On Nov 4, 2019, at 12:11 AM, Scharf, Michael = <Michael.Scharf@hs-esslingen.de> wrote:

I believe that 793bis gets more and = more mature. We will need further reviews in the next months. Given that = this is a -bis for an Internet Standard, there are unknowns=E2=80=A6 The = tentative plan is a WGLC early 2020.

 

A short = PS focusing just on the assignment could perhaps be finished faster than = 793bis. And that approach would also not change the scope of 793bis, = i.e., 793bis would only include changes with IETF consensus.

 

Because of that, I would slightly prefer a short dedicated = PS. But 793bis would also work for me. Any formally correct solution is = better than a process violation.

 

Michael

 

 

Von: Lars Eggert
Gesendet: Montag, 4. November = 2019 08:55
An: Joe Touch
Cc: Scharf, = Michael; Mirja = K=C3=BChlewind; tcpm@ietf.org; Richard = Scheffenegger; Bob Briscoe
Betreff: Re: [tcpm] On = allocating reserved bits in the TCP header

 

On = 2019-11-4, at 5:08, Joe Touch <touch@strayalpha.com> wrote:
> Why do = we need this process exception?
> 
> We have = 793bis in process. If we need to assign a bit in the header - to any = specific use or as experimental - that seems like the appropriate venue = in which to do so.

If the timelines align, = that would be the obvious place to stick that assignment, agreed.

But I'm not sure the timelines do align. = 793bis seems to progress at a slow-but-steady pace (I'll point out it = was supposed to be done two years ago....) but it seems likely that = experiments want to happen sooner.

Lars

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

= --Apple-Mail=_3014191C-FFB6-42B1-A764-6932096AADAB-- From nobody Mon Nov 4 06:10:23 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 E46E41200E7 for ; Mon, 4 Nov 2019 06:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 ZPeKa8Sxc4r6 for ; Mon, 4 Nov 2019 06:10:17 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6025B120099 for ; Mon, 4 Nov 2019 06:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=fU6DuzkxkcsF6kUqyJX+VKGSkd/nE+qDMkae3fyzMrI=; b=62PsAfmLY1xtKmQaueoWIBagT iuPAl3vf2ecfHSGqswMFNpWYpZKlIPP1anv4fVHgKcZx8kq2PfjcleTpc1X5SXfX1xARrcdj4czIa LeFvzvATHcyYpkg1uf/3jkyu0HYzOajP5/+gXFTqVKN8kG0Z1Eo4DncSFzZbihZB2j9G4JsOAHcAc vkPqMfRhnuUprPAwJsMcnXkkQBufipRAhZHRrSYxZDoeTRxKpPY7xwYWqMMipMYiS6UGs5rSCAmul fDdBcvNbOCsk+FWNRHx0kYXCKFQZ+ZSuBz03h9mOg8bn5mbVdhi7uNxSMxUY9Yg5XQ3SPvVDP5g1M cnxXen0XQ==; Received: from [31.185.128.31] (port=46420 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iRd3f-0006vi-6t; Mon, 04 Nov 2019 14:10:15 +0000 To: "Scharf, Michael" Cc: Richard Scheffenegger , "tcpm@ietf.org" , Mirja Kuehlewind References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <9df28a2e-d902-dd4c-b87d-df0fec38813c@bobbriscoe.net> Date: Mon, 4 Nov 2019 14:10:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------1CF86F3A5BA7C2124C4771B1" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 14:10:21 -0000 This is a multi-part message in MIME format. --------------1CF86F3A5BA7C2124C4771B1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Michael, At the time, I had collected a list of possible process options, collected from the preceding ML discussions. I preferred including the AccECN assignment in RFC8311 (which was ending WGLC at that time). I do not recall you agreeing with me, although you are now arguing for the same process, but with a new PS RFC. Was the decision questioned at the time on the mailing list (2 years ago) when it would have been timely to do so? One then has to ask what new situation has arisen that makes this decision need to be revisited. Bob On 04/11/2019 02:00, Scharf, Michael wrote: > > Bob, > > With chair hat on: There was a discussion in the room during IETF 99 > and the outcome of a hum in the room is documented in the minutes. > In TCPM, consensus is confirmed on the list so that all contributors > can comment. Please dont refer to room discussions as working group > decisions. > > With chair hat off, I believe there was never a formal consensus > decision in TCPM to explicitly violate RFCs. And, anyway, the working > group could change past decisions, at least prior to completing a > WGLC. In this specific case, as individual contributor, I explicitly > and very strongly disagree to move forward with an invalid IANA > considerations section. > > Thanks > > Michael > > *Von: *Bob Briscoe > *Gesendet: *Sonntag, 3. November 2019 23:04 > *An: *Scharf, Michael > *Cc: *tcpm@ietf.org ; Mirja Kuehlewind > ; Richard Scheffenegger > > *Betreff: *Re: [tcpm] On allocating reserved bits in the TCP header > > Michael, > > On 03/10/2019 12:31, Lars Eggert wrote: >> On 2019-9-10, at 13:50, Scharf, Michael wrote: >>> In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules. >> Agreed. >> >> Lars >> > > If asked this question in isolation, I would go for a quick RFC. But > this is not in isolation. > > The decision on what process to use has already been made - in Jul > 2017 at IETF-99 (it was for the IESG to be asked to make a process > exception). This is just a choice between processes. There's no > difference to the technical outcome. Please can we just do it the way > we already decided to. > > Altho I'm a Brit, I am not a fan of people trying to re-run a > referendum decision 'cos they didn't get what they wanted in the > previous one. > > > Background > This issue was extensively discussed already. After a long offlist > thread with the author of RFC8311 and others, a thread on tsvwg ran > betw 3 to 12 Jul 17: > https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM > This thread ends by deferring to a meeting arranged at IETF-99 during > AD Office Hours, at which the tcpm chairs were represented. > The outcome of that meeting was to expect the AccECN draft to rename > bit 7 and assign it to itself, which would need the IESG to agree a > process exception. That outcome was recorded on this slide for > discussion in the subsequent tcpm WG meeting: > https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7 > The tcpm minutes here: > https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 > record that "There is strong but not unanimous consensus in the room > for assigning the codepoint." > and the process proposal remained unchanged: that the IESG would be > asked to make a process exception. > > I didn't like that decision either, but this is just process. Can we > move on please. > > > Bob > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------1CF86F3A5BA7C2124C4771B1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael,

At the time, I had collected a list of possible process options, collected from the preceding ML discussions. I preferred including the AccECN assignment in RFC8311 (which was ending WGLC at that time). I do not recall you agreeing with me, although you are now arguing for the same process, but with a new PS RFC.

Was the decision questioned at the time on the mailing list (2 years ago) when it would have been timely to do so?

One then has to ask what new situation has arisen that makes this decision need to be revisited.



Bob

On 04/11/2019 02:00, Scharf, Michael wrote:

Bob,

With chair hat on: There was a discussion in the room during IETF 99 and the outcome of a hum in the room is documented in the minutes. In TCPM, consensus is confirmed on the list so that all contributors can comment. Please dont refer to room discussions as working group decisions.

With chair hat off, I believe there was never a formal consensus decision in TCPM to explicitly violate RFCs. And, anyway, the working group could change past decisions, at least prior to completing a WGLC. In this specific case, as individual contributor, I explicitly and very strongly disagree to move forward with an invalid IANA considerations section.

Thanks

Michael

Von: Bob Briscoe
Gesendet: Sonntag, 3. November 2019 23:04
An: Scharf, Michael
Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard Scheffenegger
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.

Agreed.

Lars


If asked this question in isolation, I would go for a quick RFC. But this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 at IETF-99 (it was for the IESG to be asked to make a process exception). This is just a choice between processes. There's no difference to the technical outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum decision 'cos they didn't get what they wanted in the previous one.


Background
This issue was extensively discussed already. After a long offlist thread with the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Jul 17:
https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
This thread ends by deferring to a meeting arranged at IETF-99 during AD Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 7 and assign it to itself, which would need the IESG to agree a process exception. That outcome was recorded on this slide for discussion in the subsequent tcpm WG meeting:
https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7
The tcpm minutes here:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00
record that "There is strong but not unanimous consensus in the room for assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be asked to make a process exception.

I didn't like that decision either, but this is just process. Can we move on please.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------1CF86F3A5BA7C2124C4771B1-- From nobody Mon Nov 4 07:27:32 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 E7B1A120A8F; Mon, 4 Nov 2019 07:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 32TKIU1HNmCe; Mon, 4 Nov 2019 07:27:04 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 37301120A35; Mon, 4 Nov 2019 07:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=D3uNgk5YEqkUTWHJyhutKneYVtHQiCUxBmxSm1UOw20=; b=b42yhpL/AprCugsFDXjRbjdwy /TgCszv7AeS/bocwdyRI/IkZxzzH18B/43e/Rk85fq8EiETZ6tjESe8SI35E31FftdUCUj4OjRF+x 26hlVYehnULSg975bUZrIbPB3ygfpV3mBeNzpts5YgoWRuWDH7lVWuj2iRnQxcznu/WZui6JpXcOH oqklg44EzcD7LZxgSk8MQOTKxESXMfT0m6Q/e73OEnGUcrbR44R/tnkb9sXbKAigdKhoUj47R5+Lc UelIKFKNRl6RqoUyMp5H+AoWnTm/bI1cLBqbaqz9bvo35VxlZsCeXDAJ1Xnny0i0jry+ArJum+Lzh wEJngWIJw==; Received: from [31.185.128.31] (port=46678 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iReFt-0001M4-SP; Mon, 04 Nov 2019 15:26:59 +0000 To: "Scharf, Michael" , "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net> Date: Mon, 4 Nov 2019 15:26:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------BA91E393F4763088F771707F" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id 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, 04 Nov 2019 15:27:12 -0000 This is a multi-part message in MIME format. --------------BA91E393F4763088F771707F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, Thank you for pointing this out, many months ago now. There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on AccECN, as explained below. For any transport protocol to comply with ecn-l4s-id, it needs sufficiently accurate feedback of the extent of CE marking on the forward path. You pointing this out has made me realize that there is a 'needs' that should be a 'MUST' in the spec: 4.2.  Prerequisite Transport Feedback CURRENT: In general, a scalable congestion control, needs feedback of the extent of CE marking on the forward path. PROPOSED: In general,for a transport protocol to provide scalable congestion control, it MUST provide feedback of the extent of CE marking on the forward path. However, ecn-l4s-id only specifies the requirements that any L4S transport protocol would have to satisfy. It does not define a transport protocol itself. So AccECN is not a normative ref. So I am also altering the text a little further down, where it refers to AccECN, as follows: CURRENT: TCP: Support for accurate ECN feedback (AccECN [I-D.ietf-tcpm-accurate-ecn ]) by both ends is a prerequisite for scalable congestion control. PROPOSED: TCP: Support for accurate ECN feedback (such as AccECN [I-D.ietf-tcpm-accurate-ecn ]) by both ends is a prerequisite for scalable congestion control. Thanks again for pointing this out. Dependencies between Experiments The case of TCP Prague provides a counter-argument: TCP Prague could be specified in one monolithic experimental spec. Or it could be broken down into experimental components, and a top level experimental spec that pulls them all together. The latter option would create multiple dependencies of one experiment on others. But IMHO such modularity is preferable to a monolithic spec. Especially if some of the components might have other uses outside of TCP Prague (which is exactly the case with TCP Prague, e.g. AccECN, ECN++, RACK are all potentially parts of the base TCP stack, and paced-chirping is potentially usable by any other congestion control - these are all experimental component parts). As another example, BBR was written up as an experimental draft, and the Linux implementation uses RACK (although not mentioned in the draft) which is enabled by default in Linux. Such modularity is good. Bob On 24/03/2019 19:15, Scharf, Michael wrote: > I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence: > > TCP: Support for accurate ECN feedback (AccECN > [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for > scalable congestion control. Therefore, the presence of ECT(1) in > the IP headers even in one direction of a TCP connection will > imply that both ends support AccECN. However, the converse does > not apply. So even if both ends support AccECN, either of the two > ends can choose not to use a scalable congestion control, whatever > the other end's choice. > > Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn? > > If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing. > > As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind. > > Michael (as individual) > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------BA91E393F4763088F771707F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

Thank you for pointing this out, many months ago now.

There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on AccECN, as explained below.

For any transport protocol to comply with ecn-l4s-id, it needs sufficiently accurate feedback of the extent of CE marking on the forward path. You pointing this out has made me realize that there is a 'needs' that should be a 'MUST' in the spec:

4.2.  Prerequisite Transport Feedback

CURRENT:
   In general, a scalable congestion control, needs feedback of the
   extent of CE marking on the forward path.
PROPOSED:
   In general, for a transport protocol to provide scalable congestion control, 
   it MUST provide feedback of the
   extent of CE marking on the forward path.

However, ecn-l4s-id only specifies the requirements that any L4S transport protocol would have to satisfy. It does not define a transport protocol itself. So AccECN is not a normative ref. So I am also altering the text a little further down, where it refers to AccECN, as follows:

CURRENT:
  TCP:  Support for accurate ECN feedback (AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.
PROPOSED:
  TCP:  Support for accurate ECN feedback (such as AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.
Thanks again for pointing this out.

Dependencies between Experiments


The case of TCP Prague provides a counter-argument:

TCP Prague could be specified in one monolithic experimental spec.
Or it could be broken down into experimental components, and a top level experimental spec that pulls them all together.

The latter option would create multiple dependencies of one experiment on others. But IMHO such modularity is preferable to a monolithic spec. Especially if some of the components might have other uses outside of TCP Prague (which is exactly the case with TCP Prague, e.g. AccECN, ECN++, RACK are all potentially parts of the base TCP stack, and paced-chirping is potentially usable by any other congestion control - these are all experimental component parts).

As another example, BBR was written up as an experimental draft, and the Linux implementation uses RACK (although not mentioned in the draft) which is enabled by default in Linux.

Such modularity is good.


Bob


On 24/03/2019 19:15, Scharf, Michael wrote:
I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence:

TCP:  Support for accurate ECN feedback (AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.  Therefore, the presence of ECT(1) in
      the IP headers even in one direction of a TCP connection will
      imply that both ends support AccECN.  However, the converse does
      not apply.  So even if both ends support AccECN, either of the two
      ends can choose not to use a scalable congestion control, whatever
      the other end's choice.

Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn?

If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing.

As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind.

Michael (as individual)




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------BA91E393F4763088F771707F-- From nobody Mon Nov 4 08:39:23 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 776611208BC for ; Mon, 4 Nov 2019 08:39:13 -0800 (PST) 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 4J-z91cUeqex for ; Mon, 4 Nov 2019 08:39:09 -0800 (PST) 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 1B198120851 for ; Mon, 4 Nov 2019 08:39:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 149A625A20; Mon, 4 Nov 2019 17:39:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572885547; bh=9WSd37NKQxdqo839X8kOIhfTS/wC0wM1Z6FZdWLliqk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=N8NDrDfq7+28Sc9AhREQ60SaSj/Day9HXmGM3+gzsAIKwMGStENqUCWyZz8H71Dke b4jstR98hOLkqN+nMeCKljqgvGT1XkX4E161HDKmluFcojeuKgbbc/T2yNGXG2gegb bzs7octKwWwaFgdVsL8WGhk7440lGto/7ODGbkko= 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 e910aeoCXpc4; Mon, 4 Nov 2019 17:39:05 +0100 (CET) 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; Mon, 4 Nov 2019 17:39:05 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 17:39:05 +0100 From: "Scharf, Michael" To: Bob Briscoe CC: Richard Scheffenegger , "tcpm@ietf.org" , Mirja Kuehlewind Thread-Topic: [tcpm] On allocating reserved bits in the TCP header Thread-Index: AdVmj1xabgQDGeLVSb628zuZMsyT0ATPfeIABi860QAAClWnwgAXZw8AAAdLNf4= Date: Mon, 4 Nov 2019 16:39:04 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de>, <9df28a2e-d902-dd4c-b87d-df0fec38813c@bobbriscoe.net> In-Reply-To: <9df28a2e-d902-dd4c-b87d-df0fec38813c@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 16:39:22 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8rznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bob, The IETF consensus for RFC 8311 was to return the status of the bit to =84r= eserved=93 and this RFC was published by TSVWG, not by TCPM. I was not much= in the loop, but I have agreed to the approach taken by RFC 8311 for the b= it. The formal implications of the =84reserved=93 status according to RFC 8= 311 follow from RFC 2780, which does not foresee an IESG allocation. I have already argued during IETF 99 for a standards track solution. By tha= t time, this would have implied a new small PS document, not RFC8311. The o= ther variant of using 793bis proposed by Joe has not really been realistic = 2 years ago. BTW, given the potential solution via 793bis, we are in a different situati= on now, no? At the end of the day, we need to find a solution that has strong TCPM con= sensus, or, better, even unanimous consensus. And, to me it sounds like a b= ad idea to have an IETF last call discussion about process violations for a= document with possibly rather rough WG consensus, most notably regarding a= change of the main TCP header that affects every single Internet device. I= really suggest to think about alternatives. Best regards Michael Von: Bob Briscoe Gesendet: Montag, 4. November 2019 15:10 An: Scharf, Michael Cc: Richard Scheffenegger; tcpm@ietf.org; Mirja Kuehlewind Betreff: Re: [tcpm] On allocating reserved bits in the TCP header Michael, At the time, I had collected a list of possible process options, collected = from the preceding ML discussions. I preferred including the AccECN assignm= ent in RFC8311 (which was ending WGLC at that time). I do not recall you ag= reeing with me, although you are now arguing for the same process, but with= a new PS RFC. Was the decision questioned at the time on the mailing list (2 years ago) w= hen it would have been timely to do so? One then has to ask what new situation has arisen that makes this decision = need to be revisited. Bob On 04/11/2019 02:00, Scharf, Michael wrote: Bob, With chair hat on: There was a discussion =84in the room=93 during IETF 99 = and the outcome of a hum =84in the room=93 is documented in the minutes. In= TCPM, consensus is confirmed on the list so that all contributors can comm= ent. Please don=92t refer to room discussions as working group =84decisions= =93. With chair hat off, I believe there was never a formal consensus decision i= n TCPM to explicitly violate RFCs. And, anyway, the working group could cha= nge past decisions, at least prior to completing a WGLC. In this specific c= ase, as individual contributor, I explicitly and very strongly disagree to = move forward with an invalid IANA considerations section. Thanks Michael Von: Bob Briscoe Gesendet: Sonntag, 3. November 2019 23:04 An: Scharf, Michael Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard Scheffenegger Betreff: Re: [tcpm] On allocating reserved bits in the TCP header Michael, On 03/10/2019 12:31, Lars Eggert wrote: On 2019-9-10, at 13:50, Scharf, Michael wrote: In my reading of RFC 2780 and RFC 8126, it would be a policy violation to a= llocate a bit in the main TCP header to an experiment without a proper stan= dards track document allowing this experimentation. I am convinced that for= bits in the main TCP header the IETF should just follow its own rules. Agreed. Lars If asked this question in isolation, I would go for a quick RFC. But this i= s not in isolation. The decision on what process to use has already been made - in Jul 2017 at = IETF-99 (it was for the IESG to be asked to make a process exception). This= is just a choice between processes. There's no difference to the technical= outcome. Please can we just do it the way we already decided to. Altho I'm a Brit, I am not a fan of people trying to re-run a referendum de= cision 'cos they didn't get what they wanted in the previous one. Background This issue was extensively discussed already. After a long offlist thread w= ith the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Ju= l 17: https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM This thread ends by deferring to a meeting arranged at IETF-99 during AD Of= fice Hours, at which the tcpm chairs were represented. The outcome of that meeting was to expect the AccECN draft to rename bit 7 = and assign it to itself, which would need the IESG to agree a process excep= tion. That outcome was recorded on this slide for discussion in the subsequ= ent tcpm WG meeting: https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-a= ccurate-ecn-feedback-in-tcp-02#page=3D7 The tcpm minutes here: https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 record that "There is strong but not unanimous consensus in the room for as= signing the codepoint." and the process proposal remained unchanged: that the IESG would be asked t= o make a process exception. I didn't like that decision either, but this is just process. Can we move o= n please. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8rznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Bob,

 

The IETF consensus for RFC 8311 was to return the st= atus of the bit to =84reserved=93 and this RFC was published by TSVWG, not = by TCPM. I was not much in the loop, but I have agreed to the approach take= n by RFC 8311 for the bit. The formal implications of the =84reserved=93 status according to RFC 8311 follow fro= m RFC 2780, which does not foresee an IESG allocation.

 

I have already argued during IETF 99 for a standards= track solution. By that time, this would have implied a new small PS docum= ent, not RFC8311. The other variant of using 793bis proposed by Joe has not= really been realistic 2 years ago.

 

BTW, given the potential solution via 793bis, we are= in a different situation now, no?

 

At the end of the day,  we need to find a solut= ion that has strong TCPM consensus, or, better, even unanimous consensus. A= nd, to me it sounds like a bad idea to have an IETF last call discussion ab= out process violations for a document with possibly rather rough WG consensus, most notably regarding a change of the= main TCP header that affects every single Internet device. I really sugges= t to think about alternatives.

 

Best regards

 

Michael

 

 <= /span>

 

 

Michael,

At the time, I had collected a list of possible process options, collected = from the preceding ML discussions. I preferred including the AccECN assignm= ent in RFC8311 (which was ending WGLC at that time). I do not recall you ag= reeing with me, although you are now arguing for the same process, but with a new PS RFC.

Was the decision questioned at the time on the mailing list (2 years ago) w= hen it would have been timely to do so?

One then has to ask what new situation has arisen that makes this decision = need to be revisited.



Bob

On 04/11/2019 02:00, Scharf, Michael wrote:<= br>

Bob,

 

With chair hat on: There was a discussion =84in the = room=93 during IETF 99 and the outcome of a hum =84in the room=93 is docume= nted in the minutes. In TCPM, consensus is confirmed on the list so that al= l contributors can comment. Please don=92t refer to room discussions as working group =84decisions=93.

 

With chair hat off, I believe there was never a form= al consensus decision in TCPM to explicitly violate RFCs. And, anyway, the = working group could change past decisions, at least prior to completing a W= GLC. In this specific case, as individual contributor, I explicitly and very strongly disagree to move forward with = an invalid IANA considerations section.

 

Thanks

 

Michael

 <= /span>

 

Von: Bob Briscoe
Gesendet: Sonntag, 3. November 2019 23:04
An: Scharf, Michae= l
Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard Scheffenegg= er
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

 

Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

In my reading of RFC 2780 and RFC 8126, it wou=
ld be a policy violation to allocate a bit in the main TCP header to an exp=
eriment without a proper standards track document allowing this experimenta=
tion. I am convinced that for bits in the main TCP header the IETF should j=
ust follow its own rules.

Agreed.

Lars


If asked this question in isolation, I would go for a quick RFC. But this i= s not in isolation.

The decision on what process to use has already been made - in Jul 2017 at = IETF-99 (it was for the IESG to be asked to make a process exception). This= is just a choice between processes. There's no difference to the technical= outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a refer= endum decision 'cos they didn't get what they wanted in the previo= us one.


Background
This issue was extensively discussed already. After a long offlist thread w= ith the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Ju= l 17:
    https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM=
This thread ends by deferring to a meeting arranged at IETF-99 during AD Of= fice Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 7 = and assign it to itself, which would need the IESG to agree a process excep= tion. That outcome was recorded on this slide for discussion in the subsequ= ent tcpm WG meeting:
    https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accur= ate-ecn-feedback-in-tcp-02#page=3D7
The tcpm minutes here:
    https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 record that "There is strong but not unanimous consensus in the room f= or assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be asked t= o make a process exception.

I didn't like that decision either, but this is just process. Can we move o= n please.


Bob

--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

______________________________________________=
_
tcpm mailing list
tcpm@ie=
tf.org
https://www.ietf.org/mailman/listinfo/tcpm


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--_000_6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8rznt8114rzntrzd_-- From nobody Mon Nov 4 08:58:50 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> 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 C9C5D12011F; Mon, 4 Nov 2019 08:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ppYgd8luQWNn; Mon, 4 Nov 2019 08:58:47 -0800 (PST) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D34120843; Mon, 4 Nov 2019 08:58:46 -0800 (PST) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA4Gwdpn001606; Mon, 4 Nov 2019 08:58:39 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA4GwckY001605; Mon, 4 Nov 2019 08:58:38 -0800 (PST) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201911041658.xA4GwckY001605@gndrsh.dnsmgr.net> In-Reply-To: <5DBFDF26.5080101@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Date: Mon, 4 Nov 2019 08:58:38 -0800 (PST) CC: Jonathan Morton , "Rodney W. Grimes" , "tcpm@ietf.org" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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, 04 Nov 2019 16:58:49 -0000 > On 03/11/2019, 13:08, Jonathan Morton wrote: > >> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst wrote: > >> > >>> With respect to draft-ietf-tcpm-accurate-ecn and > >>> draft-grimes-tcpm-tcpsce compatibility: > >>> When accurate ecn (AccECN) fails to negotiate an AccECN capable session > >>> it falls back to RFC3168 conformance, leaving a state that is fully > >>> compatible with SCE, hence they are compatible. > >> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN? > > RFC-8511 doesn't change the signalling on the wire relative to RFC-3168. That was the sense intended here. > > > > - Jonathan Morton > RFC3168 describes both endpoint behaviour and network functions. To me, > this sentence is about > how you receive indications of incipent congestion, the sender can > change from using only CE to using CE plus > the accurate information -or fall back to using just CE - ultimately it > falls back to just detecting congestion (loss,delay). > So yes, the CE signal could be regarded as input to SCE. > > The endpoint behaviour, I think, should fall back to RFC8511. The response to CE of an SCE capable end-point is unaltered by the fact that SCE is in use. If RFC8511 is enabled on the end node the response shall be that of the ABE parameters, if RC8511 is not enabled then the response should be that of RFC3168. IE, the 2 experiments co-exist without any special considerations, and SCE plays nicely with either response to CE. Explicitly stating in this draft that behavior should fall-back to RFC8511 would complicate implementation details as then an implementor may be required to implement RFC8511 if it did not exist, and also to some how "know" that a connection was SCE capable, somethng a sender is unaware of until the first ESCE mark is recieved, and something that can change as paths over the internet change during the life of the connection. Further more stating RFC8511 as a fallback position would more or less mandate that RFC8511 be used if SCE is used, something that may not be desireable. In summary. tcpsce does not alter CE generation, feedback or response, leaving all existing RFC's intact as they are written with respect to the CE and ECE bits. Tcpsce does not alter the response to loss either. This is by design. > Gorry -- Rod Grimes rgrimes@freebsd.org From nobody Mon Nov 4 10:08: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 86182120C41 for ; Mon, 4 Nov 2019 10:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 z4mHGFC865Qv for ; Mon, 4 Nov 2019 10:08:06 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 95694120C3B for ; Mon, 4 Nov 2019 10:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=XPndH8fkXJ2iaTHFh5gqT/Joz58ejTvSj2tQIhPUhwk=; b=L2fPYtJjFZEWWVi5Dll+hwXW5 LRaxP9t7v4Bd8YeL9Lh08LJu2MREN+vTTc9PGq68xuaWkIspAsTHKlxWokXR7Zy77NsqSWUlLxGcF 69/oQPJKxlsOhV+ektp6grSff6EA3bprP9CvZCHH0EEZtTxqCJofiUlY952Se/VOL4nxoCzhEm5xX NXYR1WcF5egEoIui44lsGlCnyiFFgYocqWuGoUBNeZnlo06s62KYYeMiiVd4FPMEo/uXGR0kIvBYm SMUdbrUDLR0Dr2Lhb6ccGhy/PBz9R/IFxXFuPAqKqIRgUsM11yXA8J5BXqiInHJnANsANp2jiCCuw 76AjkW7fA==; Received: from [31.185.128.31] (port=47426 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iRgln-0007X5-I6; Mon, 04 Nov 2019 18:08:03 +0000 To: "Scharf, Michael" Cc: Richard Scheffenegger , "tcpm@ietf.org" , Mirja Kuehlewind References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> <9df28a2e-d902-dd4c-b87d-df0fec38813c@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <3fb7e1e0-f9d9-8471-7661-7b1579de20d9@bobbriscoe.net> Date: Mon, 4 Nov 2019 18:08:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------3FD48B6388ACFC430A26B7F0" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 18:08:10 -0000 This is a multi-part message in MIME format. --------------3FD48B6388ACFC430A26B7F0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Michael, You said decisions are finalized on the ML. Then when I asked whether the decision had been questioned on the ML at the time 2 yrs ago, you didn't answer. That begs an answer to my other question: > One then has to ask what new situation has arisen that makes this > decision need to be revisited. Bob On 04/11/2019 16:39, Scharf, Michael wrote: > > Bob, > > The IETF consensus for RFC 8311 was to return the status of the bit to > reserved and this RFC was published by TSVWG, not by TCPM. I was not > much in the loop, but I have agreed to the approach taken by RFC 8311 > for the bit. The formal implications of the reserved status > according to RFC 8311 follow from RFC 2780, which does not foresee an > IESG allocation. > > I have already argued during IETF 99 for a standards track solution. > By that time, this would have implied a new small PS document, not > RFC8311. The other variant of using 793bis proposed by Joe has not > really been realistic 2 years ago. > > BTW, given the potential solution via 793bis, we are in a different > situation now, no? > > At the end of the day, we need to find a solution that has strong > TCPM consensus, or, better, even unanimous consensus. And, to me it > sounds like a bad idea to have an IETF last call discussion about > process violations for a document with possibly rather rough WG > consensus, most notably regarding a change of the main TCP header that > affects every single Internet device. I really suggest to think about > alternatives. > > Best regards > > Michael > > *Von: *Bob Briscoe > *Gesendet: *Montag, 4. November 2019 15:10 > *An: *Scharf, Michael > *Cc: *Richard Scheffenegger ; tcpm@ietf.org > ; Mirja Kuehlewind > *Betreff: *Re: [tcpm] On allocating reserved bits in the TCP header > > Michael, > > At the time, I had collected a list of possible process options, > collected from the preceding ML discussions. I preferred including the > AccECN assignment in RFC8311 (which was ending WGLC at that time). I > do not recall you agreeing with me, although you are now arguing for > the same process, but with a new PS RFC. > > Was the decision questioned at the time on the mailing list (2 years > ago) when it would have been timely to do so? > > One then has to ask what new situation has arisen that makes this > decision need to be revisited. > > > > Bob > > On 04/11/2019 02:00, Scharf, Michael wrote: >> >> Bob, >> >> With chair hat on: There was a discussion in the room during IETF >> 99 and the outcome of a hum in the room is documented in the >> minutes. In TCPM, consensus is confirmed on the list so that all >> contributors can comment. Please dont refer to room discussions as >> working group decisions. >> >> With chair hat off, I believe there was never a formal consensus >> decision in TCPM to explicitly violate RFCs. And, anyway, the working >> group could change past decisions, at least prior to completing a >> WGLC. In this specific case, as individual contributor, I explicitly >> and very strongly disagree to move forward with an invalid IANA >> considerations section. >> >> Thanks >> >> Michael >> >> *Von: *Bob Briscoe >> *Gesendet: *Sonntag, 3. November 2019 23:04 >> *An: *Scharf, Michael >> *Cc: *tcpm@ietf.org ; Mirja Kuehlewind >> ; Richard Scheffenegger >> >> *Betreff: *Re: [tcpm] On allocating reserved bits in the TCP header >> >> Michael, >> >> On 03/10/2019 12:31, Lars Eggert wrote: >>> On 2019-9-10, at 13:50, Scharf, Michael wrote: >>>> In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules. >>> Agreed. >>> >>> Lars >>> >> >> If asked this question in isolation, I would go for a quick RFC. But >> this is not in isolation. >> >> The decision on what process to use has already been made - in Jul >> 2017 at IETF-99 (it was for the IESG to be asked to make a process >> exception). This is just a choice between processes. There's no >> difference to the technical outcome. Please can we just do it the way >> we already decided to. >> >> Altho I'm a Brit, I am not a fan of people trying to re-run a >> referendum decision 'cos they didn't get what they wanted in the >> previous one. >> >> >> Background >> This issue was extensively discussed already. After a long offlist >> thread with the author of RFC8311 and others, a thread on tsvwg ran >> betw 3 to 12 Jul 17: >> https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM >> This thread ends by deferring to a meeting arranged at IETF-99 during >> AD Office Hours, at which the tcpm chairs were represented. >> The outcome of that meeting was to expect the AccECN draft to rename >> bit 7 and assign it to itself, which would need the IESG to agree a >> process exception. That outcome was recorded on this slide for >> discussion in the subsequent tcpm WG meeting: >> https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7 >> The tcpm minutes here: >> https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 >> record that "There is strong but not unanimous consensus in the room >> for assigning the codepoint." >> and the process proposal remained unchanged: that the IESG would be >> asked to make a process exception. >> >> I didn't like that decision either, but this is just process. Can we >> move on please. >> >> >> Bob >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------3FD48B6388ACFC430A26B7F0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael,

You said decisions are finalized on the ML. Then when I asked whether the decision had been questioned on the ML at the time 2 yrs ago, you didn't answer.

That begs an answer to my other question:
One then has to ask what new situation has arisen that makes this decision need to be revisited.


Bob

On 04/11/2019 16:39, Scharf, Michael wrote:

Bob,

The IETF consensus for RFC 8311 was to return the status of the bit to reserved and this RFC was published by TSVWG, not by TCPM. I was not much in the loop, but I have agreed to the approach taken by RFC 8311 for the bit. The formal implications of the reserved status according to RFC 8311 follow from RFC 2780, which does not foresee an IESG allocation.

I have already argued during IETF 99 for a standards track solution. By that time, this would have implied a new small PS document, not RFC8311. The other variant of using 793bis proposed by Joe has not really been realistic 2 years ago.

BTW, given the potential solution via 793bis, we are in a different situation now, no?

At the end of the day, we need to find a solution that has strong TCPM consensus, or, better, even unanimous consensus. And, to me it sounds like a bad idea to have an IETF last call discussion about process violations for a document with possibly rather rough WG consensus, most notably regarding a change of the main TCP header that affects every single Internet device. I really suggest to think about alternatives.

Best regards

Michael

Von: Bob Briscoe
Gesendet: Montag, 4. November 2019 15:10
An: Scharf, Michael
Cc: Richard Scheffenegger; tcpm@ietf.org; Mirja Kuehlewind
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Michael,

At the time, I had collected a list of possible process options, collected from the preceding ML discussions. I preferred including the AccECN assignment in RFC8311 (which was ending WGLC at that time). I do not recall you agreeing with me, although you are now arguing for the same process, but with a new PS RFC.

Was the decision questioned at the time on the mailing list (2 years ago) when it would have been timely to do so?

One then has to ask what new situation has arisen that makes this decision need to be revisited.



Bob

On 04/11/2019 02:00, Scharf, Michael wrote:

Bob,

With chair hat on: There was a discussion in the room during IETF 99 and the outcome of a hum in the room is documented in the minutes. In TCPM, consensus is confirmed on the list so that all contributors can comment. Please dont refer to room discussions as working group decisions.

With chair hat off, I believe there was never a formal consensus decision in TCPM to explicitly violate RFCs. And, anyway, the working group could change past decisions, at least prior to completing a WGLC. In this specific case, as individual contributor, I explicitly and very strongly disagree to move forward with an invalid IANA considerations section.

Thanks

Michael

Von: Bob Briscoe
Gesendet: Sonntag, 3. November 2019 23:04
An: Scharf, Michael
Cc: tcpm@ietf.org; Mirja Kuehlewind; Richard Scheffenegger
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.

Agreed.

Lars


If asked this question in isolation, I would go for a quick RFC. But this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 at IETF-99 (it was for the IESG to be asked to make a process exception). This is just a choice between processes. There's no difference to the technical outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum decision 'cos they didn't get what they wanted in the previous one.


Background
This issue was extensively discussed already. After a long offlist thread with the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Jul 17:
https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
This thread ends by deferring to a meeting arranged at IETF-99 during AD Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 7 and assign it to itself, which would need the IESG to agree a process exception. That outcome was recorded on this slide for discussion in the subsequent tcpm WG meeting:
https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7
The tcpm minutes here:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00
record that "There is strong but not unanimous consensus in the room for assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be asked to make a process exception.

I didn't like that decision either, but this is just process. Can we move on please.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------3FD48B6388ACFC430A26B7F0-- From nobody Mon Nov 4 10:09:26 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 A675E120B02; Mon, 4 Nov 2019 10:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 HMYCAS5wjCNz; Mon, 4 Nov 2019 10:09:20 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 E5432120C34; Mon, 4 Nov 2019 10:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=FXqf3cpqWGAK64EqoH90W8G2x2ok72NS1+Mx2YQLqH0=; b=sfGUiLHgZfhe0cR1ho4I00Q3K TtnIsQQYb1NHb96QnAzWJ9JMAHnDLB86aVTXLR3RCWjIIaeP4uvrlxWTocJwOKDnn/4iNP4Whytcz thx70uVa+RKM8IrryW1X+alTBJwZuv4z5L8lLGIIspyalIjaix6eH0q73Df73FGt+SpbMSMS1o8jm tyMB+lTfSNOV9byjKIN60Cr+/YXl/9E0fPTne6jQ0JRO6RbyN6zaCYQFomIzrz3pCZ5MUjuhG0QaR WdgqkXmIvA0E/or2jz50YSIScFtBwmG7jS7PqYadMAp4Jld1Sov8XTOmNQpu6CHYosUmUW+UVIMHo Z6QHtHrzg==; Received: from [31.185.128.31] (port=47430 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iRgn0-0007ii-8r; Mon, 04 Nov 2019 18:09:18 +0000 To: "Scharf, Michael" , Wesley Eddy , "tsvwg@ietf.org" Cc: "tcpm@ietf.org" References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <9f59d918-1907-450c-6139-0fd17646a7dd@bobbriscoe.net> Date: Mon, 4 Nov 2019 18:09:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------A6B923E6A89160A36AAA7823" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net 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: Mon, 04 Nov 2019 18:09:24 -0000 This is a multi-part message in MIME format. --------------A6B923E6A89160A36AAA7823 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Michael, Previously, I have been told not to use the term standard for RFCs that are not standards. RFC5681 is 'only' a draft standard. This is why, in the IETF at least, I avoid using the term "standard TCP congestion control". I generally call it Reno when referring to the congestion control. I have never, to my knowledge, used the term classic TCP, or classic TCP congestion control. And I rarely use the term legacy, and if I do I'm happy to have alternatives suggested. I've checked the L4S drafts, and there is one phrase that I shall leave in ecn-l4s-id: "the traditional TCP Reno additive increase", because this is correctly used to mean the traditional increase (in numerous AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in an appendix that has just been deleted anyway. And in aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic traffic" now in my local copy, using the defined term in all the L4S drafts). l4s-arch is getting a complete make-over for terminology, so I will check that next. inline... On 23/08/2019 15:01, Scharf, Michael wrote: > > Hi Wes, > > Id 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-hDvWO3I5MudwpNkKyHY > > , I object to the terms traditional TCP and also classic TCP or > legacy TCP when referring to a TCP implementation according to IETF > standards-track RFCs. > > To me as a non-native native speaker, all these terms have a negative > connotation. I also think this language is typical to marketing material. > You're entitled to your opinion but, as a native speaker, I don't think 'classic' or 'traditional' are particularly pejorative, tho they can be when used in a context that intends them to be. They also mean "stood the test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad. This is an enduring problem when trying to improve on the good work that other people have done before you (which is the context of everything we are doing). We need a word that distinguishes the old from the new, but we don't want to completely trash the thing that has already been successful, but had its day. Nonetheless, it is also important not to be too precious about past work. We all recognize that Reno TCP is unscalable and has problems. IMO, it is OK to describe technologies that have had their time with negative connotations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control. I notice you haven't suggested an alternative term for "the thing(s) we are trying to improve on". Not surprising, because it's difficult. When we (the L4S developers) were first looking for a term for the non-L4S queue and the non-L4S service, we didn't want to use 'legacy' for the above reasons, but we did want to imply pre-existing, so we decided on 'classic', which we all felt had a generally neutral connotation, but said what we meant. Finally, I do not want this issue to take up any time that would detract from technical issues. Bob > My prefered term when referring to TCP according to standards-track > specification 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 TCP standard congestion control (Reno). As of today, this is the > TCP congestion control 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 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 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 and I dont ask for changes > in those cases. > > Some use of the term Classic Service may also require careful review > to clearly 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 speaker, it would be really strange to use the term > classic in the context of a brand-new transport protocol. IMHO in > that case the term classic 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=ticket&asc=1&page=1 > > 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. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------A6B923E6A89160A36AAA7823 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael,

Previously, I have been told not to use the term standard for RFCs that are not standards. RFC5681 is 'only' a draft standard. This is why, in the IETF at least, I avoid using the term "standard TCP congestion control". I generally call it Reno when referring to the congestion control.

I have never, to my knowledge, used the term classic TCP, or classic TCP congestion control.

And I rarely use the term legacy, and if I do I'm happy to have alternatives suggested.

I've checked the L4S drafts, and there is one phrase that I shall leave in ecn-l4s-id: "the traditional TCP Reno additive increase", because this is correctly used to mean the traditional increase (in numerous AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in an appendix that has just been deleted anyway. And in aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic traffic" now in my local copy, using the defined term in all the L4S drafts).

l4s-arch is getting a complete make-over for terminology, so I will check that next.

inline...


On 23/08/2019 15:01, Scharf, Michael wrote:

Hi Wes,

Id 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-hDvWO3I5MudwpNkKyHY , I object to the terms traditional TCP and also classic TCP or legacy TCP when referring to a TCP implementation according to IETF standards-track RFCs.

To me as a non-native native speaker, all these terms have a negative connotation. I also think this language is typical to marketing material.

You're entitled to your opinion but, as a native speaker, I don't think 'classic' or 'traditional' are particularly pejorative, tho they can be when used in a context that intends them to be. They also mean "stood the test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad.

This is an enduring problem when trying to improve on the good work that other people have done before you (which is the context of everything we are doing). We need a word that distinguishes the old from the new, but we don't want to completely trash the thing that has already been successful, but had its day.

Nonetheless, it is also important not to be too precious about past work. We all recognize that Reno TCP is unscalable and has problems. IMO, it is OK to describe technologies that have had their time with negative connotations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control.

I notice you haven't suggested an alternative term for "the thing(s) we are trying to improve on". Not surprising, because it's difficult.

When we (the L4S developers) were first looking for a term for the non-L4S queue and the non-L4S service, we didn't want to use 'legacy' for the above reasons, but we did want to imply pre-existing, so we decided on 'classic', which we all felt had a generally neutral connotation, but said what we meant.

Finally, I do not want this issue to take up any time that would detract from technical issues.



Bob

My prefered term when referring to TCP according to standards-track specification 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 TCP standard congestion control (Reno). As of today, this is the TCP congestion control 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 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 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 and I dont ask for changes in those cases.

Some use of the term Classic Service may also require careful review to clearly 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 speaker, it would be really strange to use the term classic in the context of a brand-new transport protocol. IMHO in that case the term classic 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=ticket&asc=1&page=1

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.


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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------A6B923E6A89160A36AAA7823-- From nobody Mon Nov 4 10:57:07 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 66106120120 for ; Mon, 4 Nov 2019 10:57:05 -0800 (PST) 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 3_D3REyrhTvy for ; Mon, 4 Nov 2019 10:57:03 -0800 (PST) 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 A13CE120019 for ; Mon, 4 Nov 2019 10:57:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1F77D25A2A; Mon, 4 Nov 2019 19:57:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572893821; bh=lBbcMUm1XcvG5FetfWwiAvd/pFmyfnbUZ0/nVqhMhng=; h=From:To:CC:Subject:Date:From; b=QHv6ommn8xQwOuxvooGW9TVinJKV5f47vIXFgJkYQCPz+C/pH00N7jbDz0Y23yoPK OmI/K46lhiBsm1n7lEj0C35tApWEavyD0wwNXZ38fHSIiA9bH0N/Dna8Sq65KYNdqA y6PuaQXOUN1jwaQFDBWzq/4cV80zND/xd0cjVLCA= 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 p6h6_DdyKLWp; Mon, 4 Nov 2019 19:56:59 +0100 (CET) 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; Mon, 4 Nov 2019 19:56:59 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 19:56:59 +0100 From: "Scharf, Michael" To: Bob Briscoe CC: Richard Scheffenegger , "tcpm@ietf.org" , Mirja Kuehlewind Thread-Topic: [tcpm] On allocating reserved bits in the TCP header Thread-Index: AdWTQaKubgQDGeLVSb628zuZMsyT0A== Content-Class: urn:content-classes:message Date: Mon, 4 Nov 2019 18:56:58 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DE45E@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE45Erznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header 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, 04 Nov 2019 18:57:06 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE45Erznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9iLA0KDQpXaGV0aGVyIHRoaXMgcXVlc3Rpb24gaGFzIGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBt YWlsaW5nIGxpc3QgaW4gdGhlIGxhc3QgMiB5ZWFycyBhbHNvIGRvZXMgbm90IG1hdHRlci4gVGhl IGFuc3dlciBtYXkgYmUgbm8sIGJ1dCB3aHkgd291bGQgdGhhdCBtYXR0ZXI/IFRoZSBpbnRlcmVz dCBpbiB0aGUgd29ya2luZyBncm91cCBpbiB0aGlzIGRvY3VtZW50IGhhcyBiZWVuIHJlbGF0aXZl bHkgbG93IGZvciBxdWl0ZSBzb21lIHRpbWUsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLiBBbmQgdGhl IGNvbnRlbnQgb2YgZG9jdW1lbnRzIGFuZCB0aGUgY29uc2Vuc3VzIGluIGEgd29ya2luZyBncm91 cCBjYW4gY2hhbmdlIG92ZXIgdGltZS4gQW5kIG5vdGUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgbm90 IGluIFdHTEMuDQoNCkkgaGF2ZSBhbHJlYWR5IG1lbnRpb25lZCB0aGF0IHRoZSBuZWFyaW5nIGNv bXBsZXRpb24gb2YgNzkzYmlzIGlzIGEgcGVyZmVjdCBleGFtcGxlIGZvciBhIG5ldyBzaXR1YXRp b24sIGJlY2F1c2UgaXQgYWxsb3dzIGFub3RoZXIgc29sdXRpb24gdGhhdCB3YXMgbm90IHJlYWxs eSByZWFsaXN0aWMgZWFybGllci4NCg0KQW5kIHRoZXJlIGFyZSBvdGhlciBuZXcgaWRlYXMgc3Vj aCBhcyBkcmFmdC1nb21lei10Y3BtLWFjay1wdWxsLCB3aGljaCBhcmUgcXVpdGUgcmVjZW50IGFu ZCBtYXliZSBub3QgcmVhbGx5IHdlbGwgdW5kZXJzdG9vZC4gSXMgdGhpcyBub3QgYSBuZXcgc2l0 dWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IHdoZW4gZGVjaWRpbmcg b24gYSBiaXQgYWxsb2NhdGlvbj8gVGhhdCBwcm9wb3NhbCB3YXMgbm90IGtub3duIGR1cmluZyBJ RVRGIDk5Lg0KDQpJIHN1Z2dlc3QgdG8gbG9vayBmb3J3YXJkIGluc3RlYWQgb2YgYmFja3dhcmQu DQoNCkJlc3QgcmVnYXJkcw0KDQpNaWNoYWVsDQoNCg0KVm9uOiBCb2IgQnJpc2NvZTxtYWlsdG86 aW5AYm9iYnJpc2NvZS5uZXQ+DQpHZXNlbmRldDogTW9udGFnLCA0LiBOb3ZlbWJlciAyMDE5IDE5 OjA4DQpBbjogU2NoYXJmLCBNaWNoYWVsPG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5n ZW4uZGU+DQpDYzogUmljaGFyZCBTY2hlZmZlbmVnZ2VyPG1haWx0bzpyc2NoZWZmQGdteC5hdD47 IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+OyBNaXJqYSBLdWVobGV3aW5kPG1h aWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Pg0KQmV0cmVmZjogUmU6IFt0Y3BtXSBPbiBhbGxvY2F0 aW5nIHJlc2VydmVkIGJpdHMgaW4gdGhlIFRDUCBoZWFkZXINCg0KTWljaGFlbCwNCg0KWW91IHNh aWQgZGVjaXNpb25zIGFyZSBmaW5hbGl6ZWQgb24gdGhlIE1MLiBUaGVuIHdoZW4gSSBhc2tlZCB3 aGV0aGVyIHRoZSBkZWNpc2lvbiBoYWQgYmVlbiBxdWVzdGlvbmVkIG9uIHRoZSBNTCBhdCB0aGUg dGltZSAyIHlycyBhZ28sIHlvdSBkaWRuJ3QgYW5zd2VyLg0KDQpUaGF0IGJlZ3MgYW4gYW5zd2Vy IHRvIG15IG90aGVyIHF1ZXN0aW9uOg0KDQpPbmUgdGhlbiBoYXMgdG8gYXNrIHdoYXQgbmV3IHNp dHVhdGlvbiBoYXMgYXJpc2VuIHRoYXQgbWFrZXMgdGhpcyBkZWNpc2lvbiBuZWVkIHRvIGJlIHJl dmlzaXRlZC4NCg0KDQpCb2INCk9uIDA0LzExLzIwMTkgMTY6MzksIFNjaGFyZiwgTWljaGFlbCB3 cm90ZToNCkJvYiwNCg0KVGhlIElFVEYgY29uc2Vuc3VzIGZvciBSRkMgODMxMSB3YXMgdG8gcmV0 dXJuIHRoZSBzdGF0dXMgb2YgdGhlIGJpdCB0byDigJ5yZXNlcnZlZOKAnCBhbmQgdGhpcyBSRkMg d2FzIHB1Ymxpc2hlZCBieSBUU1ZXRywgbm90IGJ5IFRDUE0uIEkgd2FzIG5vdCBtdWNoIGluIHRo ZSBsb29wLCBidXQgSSBoYXZlIGFncmVlZCB0byB0aGUgYXBwcm9hY2ggdGFrZW4gYnkgUkZDIDgz MTEgZm9yIHRoZSBiaXQuIFRoZSBmb3JtYWwgaW1wbGljYXRpb25zIG9mIHRoZSDigJ5yZXNlcnZl ZOKAnCBzdGF0dXMgYWNjb3JkaW5nIHRvIFJGQyA4MzExIGZvbGxvdyBmcm9tIFJGQyAyNzgwLCB3 aGljaCBkb2VzIG5vdCBmb3Jlc2VlIGFuIElFU0cgYWxsb2NhdGlvbi4NCg0KSSBoYXZlIGFscmVh ZHkgYXJndWVkIGR1cmluZyBJRVRGIDk5IGZvciBhIHN0YW5kYXJkcyB0cmFjayBzb2x1dGlvbi4g QnkgdGhhdCB0aW1lLCB0aGlzIHdvdWxkIGhhdmUgaW1wbGllZCBhIG5ldyBzbWFsbCBQUyBkb2N1 bWVudCwgbm90IFJGQzgzMTEuIFRoZSBvdGhlciB2YXJpYW50IG9mIHVzaW5nIDc5M2JpcyBwcm9w b3NlZCBieSBKb2UgaGFzIG5vdCByZWFsbHkgYmVlbiByZWFsaXN0aWMgMiB5ZWFycyBhZ28uDQoN CkJUVywgZ2l2ZW4gdGhlIHBvdGVudGlhbCBzb2x1dGlvbiB2aWEgNzkzYmlzLCB3ZSBhcmUgaW4g YSBkaWZmZXJlbnQgc2l0dWF0aW9uIG5vdywgbm8/DQoNCkF0IHRoZSBlbmQgb2YgdGhlIGRheSwg IHdlIG5lZWQgdG8gZmluZCBhIHNvbHV0aW9uIHRoYXQgaGFzIHN0cm9uZyBUQ1BNIGNvbnNlbnN1 cywgb3IsIGJldHRlciwgZXZlbiB1bmFuaW1vdXMgY29uc2Vuc3VzLiBBbmQsIHRvIG1lIGl0IHNv dW5kcyBsaWtlIGEgYmFkIGlkZWEgdG8gaGF2ZSBhbiBJRVRGIGxhc3QgY2FsbCBkaXNjdXNzaW9u IGFib3V0IHByb2Nlc3MgdmlvbGF0aW9ucyBmb3IgYSBkb2N1bWVudCB3aXRoIHBvc3NpYmx5IHJh dGhlciByb3VnaCBXRyBjb25zZW5zdXMsIG1vc3Qgbm90YWJseSByZWdhcmRpbmcgYSBjaGFuZ2Ug b2YgdGhlIG1haW4gVENQIGhlYWRlciB0aGF0IGFmZmVjdHMgZXZlcnkgc2luZ2xlIEludGVybmV0 IGRldmljZS4gSSByZWFsbHkgc3VnZ2VzdCB0byB0aGluayBhYm91dCBhbHRlcm5hdGl2ZXMuDQoN CkJlc3QgcmVnYXJkcw0KDQpNaWNoYWVsDQoNCg0KDQpWb246IEJvYiBCcmlzY29lPG1haWx0bzpp bkBib2JicmlzY29lLm5ldD4NCkdlc2VuZGV0OiBNb250YWcsIDQuIE5vdmVtYmVyIDIwMTkgMTU6 MTANCkFuOiBTY2hhcmYsIE1pY2hhZWw8bWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdl bi5kZT4NCkNjOiBSaWNoYXJkIFNjaGVmZmVuZWdnZXI8bWFpbHRvOnJzY2hlZmZAZ214LmF0Pjsg dGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz47IE1pcmphIEt1ZWhsZXdpbmQ8bWFp bHRvOmlldGZAa3VlaGxld2luZC5uZXQ+DQpCZXRyZWZmOiBSZTogW3RjcG1dIE9uIGFsbG9jYXRp bmcgcmVzZXJ2ZWQgYml0cyBpbiB0aGUgVENQIGhlYWRlcg0KDQpNaWNoYWVsLA0KDQpBdCB0aGUg dGltZSwgSSBoYWQgY29sbGVjdGVkIGEgbGlzdCBvZiBwb3NzaWJsZSBwcm9jZXNzIG9wdGlvbnMs IGNvbGxlY3RlZCBmcm9tIHRoZSBwcmVjZWRpbmcgTUwgZGlzY3Vzc2lvbnMuIEkgcHJlZmVycmVk IGluY2x1ZGluZyB0aGUgQWNjRUNOIGFzc2lnbm1lbnQgaW4gUkZDODMxMSAod2hpY2ggd2FzIGVu ZGluZyBXR0xDIGF0IHRoYXQgdGltZSkuIEkgZG8gbm90IHJlY2FsbCB5b3UgYWdyZWVpbmcgd2l0 aCBtZSwgYWx0aG91Z2ggeW91IGFyZSBub3cgYXJndWluZyBmb3IgdGhlIHNhbWUgcHJvY2Vzcywg YnV0IHdpdGggYSBuZXcgUFMgUkZDLg0KDQpXYXMgdGhlIGRlY2lzaW9uIHF1ZXN0aW9uZWQgYXQg dGhlIHRpbWUgb24gdGhlIG1haWxpbmcgbGlzdCAoMiB5ZWFycyBhZ28pIHdoZW4gaXQgd291bGQg aGF2ZSBiZWVuIHRpbWVseSB0byBkbyBzbz8NCg0KT25lIHRoZW4gaGFzIHRvIGFzayB3aGF0IG5l dyBzaXR1YXRpb24gaGFzIGFyaXNlbiB0aGF0IG1ha2VzIHRoaXMgZGVjaXNpb24gbmVlZCB0byBi ZSByZXZpc2l0ZWQuDQoNCg0KDQpCb2INCk9uIDA0LzExLzIwMTkgMDI6MDAsIFNjaGFyZiwgTWlj aGFlbCB3cm90ZToNCkJvYiwNCg0KV2l0aCBjaGFpciBoYXQgb246IFRoZXJlIHdhcyBhIGRpc2N1 c3Npb24g4oCeaW4gdGhlIHJvb23igJwgZHVyaW5nIElFVEYgOTkgYW5kIHRoZSBvdXRjb21lIG9m IGEgaHVtIOKAnmluIHRoZSByb29t4oCcIGlzIGRvY3VtZW50ZWQgaW4gdGhlIG1pbnV0ZXMuIElu IFRDUE0sIGNvbnNlbnN1cyBpcyBjb25maXJtZWQgb24gdGhlIGxpc3Qgc28gdGhhdCBhbGwgY29u dHJpYnV0b3JzIGNhbiBjb21tZW50LiBQbGVhc2UgZG9u4oCZdCByZWZlciB0byByb29tIGRpc2N1 c3Npb25zIGFzIHdvcmtpbmcgZ3JvdXAg4oCeZGVjaXNpb25z4oCcLg0KDQpXaXRoIGNoYWlyIGhh dCBvZmYsIEkgYmVsaWV2ZSB0aGVyZSB3YXMgbmV2ZXIgYSBmb3JtYWwgY29uc2Vuc3VzIGRlY2lz aW9uIGluIFRDUE0gdG8gZXhwbGljaXRseSB2aW9sYXRlIFJGQ3MuIEFuZCwgYW55d2F5LCB0aGUg d29ya2luZyBncm91cCBjb3VsZCBjaGFuZ2UgcGFzdCBkZWNpc2lvbnMsIGF0IGxlYXN0IHByaW9y IHRvIGNvbXBsZXRpbmcgYSBXR0xDLiBJbiB0aGlzIHNwZWNpZmljIGNhc2UsIGFzIGluZGl2aWR1 YWwgY29udHJpYnV0b3IsIEkgZXhwbGljaXRseSBhbmQgdmVyeSBzdHJvbmdseSBkaXNhZ3JlZSB0 byBtb3ZlIGZvcndhcmQgd2l0aCBhbiBpbnZhbGlkIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlv bi4NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0KDQpWb246IEJvYiBCcmlzY29lPG1haWx0bzppbkBi b2JicmlzY29lLm5ldD4NCkdlc2VuZGV0OiBTb25udGFnLCAzLiBOb3ZlbWJlciAyMDE5IDIzOjA0 DQpBbjogU2NoYXJmLCBNaWNoYWVsPG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4u ZGU+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz47IE1pcmphIEt1ZWhs ZXdpbmQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+OyBSaWNoYXJkIFNjaGVmZmVuZWdnZXI8 bWFpbHRvOnJzY2hlZmZAZ214LmF0Pg0KQmV0cmVmZjogUmU6IFt0Y3BtXSBPbiBhbGxvY2F0aW5n IHJlc2VydmVkIGJpdHMgaW4gdGhlIFRDUCBoZWFkZXINCg0KTWljaGFlbCwNCk9uIDAzLzEwLzIw MTkgMTI6MzEsIExhcnMgRWdnZXJ0IHdyb3RlOg0KDQpPbiAyMDE5LTktMTAsIGF0IDEzOjUwLCBT Y2hhcmYsIE1pY2hhZWwgPE1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT48bWFpbHRvOk1p Y2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT4gd3JvdGU6DQoNCkluIG15IHJlYWRpbmcgb2Yg UkZDIDI3ODAgYW5kIFJGQyA4MTI2LCBpdCB3b3VsZCBiZSBhIHBvbGljeSB2aW9sYXRpb24gdG8g YWxsb2NhdGUgYSBiaXQgaW4gdGhlIG1haW4gVENQIGhlYWRlciB0byBhbiBleHBlcmltZW50IHdp dGhvdXQgYSBwcm9wZXIgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50IGFsbG93aW5nIHRoaXMgZXhw ZXJpbWVudGF0aW9uLiBJIGFtIGNvbnZpbmNlZCB0aGF0IGZvciBiaXRzIGluIHRoZSBtYWluIFRD UCBoZWFkZXIgdGhlIElFVEYgc2hvdWxkIGp1c3QgZm9sbG93IGl0cyBvd24gcnVsZXMuDQoNCkFn cmVlZC4NCg0KDQoNCkxhcnMNCg0KDQpJZiBhc2tlZCB0aGlzIHF1ZXN0aW9uIGluIGlzb2xhdGlv biwgSSB3b3VsZCBnbyBmb3IgYSBxdWljayBSRkMuIEJ1dCB0aGlzIGlzIG5vdCBpbiBpc29sYXRp b24uDQoNClRoZSBkZWNpc2lvbiBvbiB3aGF0IHByb2Nlc3MgdG8gdXNlIGhhcyBhbHJlYWR5IGJl ZW4gbWFkZSAtIGluIEp1bCAyMDE3IGF0IElFVEYtOTkgKGl0IHdhcyBmb3IgdGhlIElFU0cgdG8g YmUgYXNrZWQgdG8gbWFrZSBhIHByb2Nlc3MgZXhjZXB0aW9uKS4gVGhpcyBpcyBqdXN0IGEgY2hv aWNlIGJldHdlZW4gcHJvY2Vzc2VzLiBUaGVyZSdzIG5vIGRpZmZlcmVuY2UgdG8gdGhlIHRlY2hu aWNhbCBvdXRjb21lLiBQbGVhc2UgY2FuIHdlIGp1c3QgZG8gaXQgdGhlIHdheSB3ZSBhbHJlYWR5 IGRlY2lkZWQgdG8uDQoNCkFsdGhvIEknbSBhIEJyaXQsIEkgYW0gbm90IGEgZmFuIG9mIHBlb3Bs ZSB0cnlpbmcgdG8gcmUtcnVuIGEgcmVmZXJlbmR1bSBkZWNpc2lvbiAnY29zIHRoZXkgZGlkbid0 IGdldCB3aGF0IHRoZXkgd2FudGVkIGluIHRoZSBwcmV2aW91cyBvbmUuDQoNCg0KQmFja2dyb3Vu ZA0KVGhpcyBpc3N1ZSB3YXMgZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkIGFscmVhZHkuIEFmdGVyIGEg bG9uZyBvZmZsaXN0IHRocmVhZCB3aXRoIHRoZSBhdXRob3Igb2YgUkZDODMxMSBhbmQgb3RoZXJz LCBhIHRocmVhZCBvbiB0c3Z3ZyByYW4gYmV0dyAzIHRvIDEyIEp1bCAxNzoNCiAgICBodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RzdndnL2tVWXdWSlFYUWZIenRRekt0ZzdG ZnBTRlNQTQ0KVGhpcyB0aHJlYWQgZW5kcyBieSBkZWZlcnJpbmcgdG8gYSBtZWV0aW5nIGFycmFu Z2VkIGF0IElFVEYtOTkgZHVyaW5nIEFEIE9mZmljZSBIb3VycywgYXQgd2hpY2ggdGhlIHRjcG0g Y2hhaXJzIHdlcmUgcmVwcmVzZW50ZWQuDQpUaGUgb3V0Y29tZSBvZiB0aGF0IG1lZXRpbmcgd2Fz IHRvIGV4cGVjdCB0aGUgQWNjRUNOIGRyYWZ0IHRvIHJlbmFtZSBiaXQgNyBhbmQgYXNzaWduIGl0 IHRvIGl0c2VsZiwgd2hpY2ggd291bGQgbmVlZCB0aGUgSUVTRyB0byBhZ3JlZSBhIHByb2Nlc3Mg ZXhjZXB0aW9uLiBUaGF0IG91dGNvbWUgd2FzIHJlY29yZGVkIG9uIHRoaXMgc2xpZGUgZm9yIGRp c2N1c3Npb24gaW4gdGhlIHN1YnNlcXVlbnQgdGNwbSBXRyBtZWV0aW5nOg0KICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9tYXRlcmlhbHMvc2xpZGVzLTk5LXRjcG0t bW9yZS1hY2N1cmF0ZS1lY24tZmVlZGJhY2staW4tdGNwLTAyI3BhZ2U9Nw0KVGhlIHRjcG0gbWlu dXRlcyBoZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9t YXRlcmlhbHMvbWludXRlcy05OS10Y3BtLTAwDQpyZWNvcmQgdGhhdCAiVGhlcmUgaXMgc3Ryb25n IGJ1dCBub3QgdW5hbmltb3VzIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSBmb3IgYXNzaWduaW5nIHRo ZSBjb2RlcG9pbnQuIg0KYW5kIHRoZSBwcm9jZXNzIHByb3Bvc2FsIHJlbWFpbmVkIHVuY2hhbmdl ZDogdGhhdCB0aGUgSUVTRyB3b3VsZCBiZSBhc2tlZCB0byBtYWtlIGEgcHJvY2VzcyBleGNlcHRp b24uDQoNCkkgZGlkbid0IGxpa2UgdGhhdCBkZWNpc2lvbiBlaXRoZXIsIGJ1dCB0aGlzIGlzIGp1 c3QgcHJvY2Vzcy4gQ2FuIHdlIG1vdmUgb24gcGxlYXNlLg0KDQoNCkJvYg0KDQoNCg0KLS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQp0Y3BtIG1haWxpbmcgbGlzdA0KDQp0Y3BtQGlldGYub3JnPG1h aWx0bzp0Y3BtQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RjcG0NCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQoNCg0KLS0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8v Ym9iYnJpc2NvZS5uZXQvDQoNCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE45Erznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZv cm1hdGllcnQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN TFZvcmZvcm1hdGllcnRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQg WmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZv cmZvcm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvYiw8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZXRoZXIg dGhpcyBxdWVzdGlvbiBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhlIG1haWxpbmcgbGlzdCBpbiB0 aGUgbGFzdCAyIHllYXJzIGFsc28gZG9lcyBub3QgbWF0dGVyLiBUaGUgYW5zd2VyIG1heSBiZSBu bywgYnV0IHdoeSB3b3VsZCB0aGF0IG1hdHRlcj8gVGhlIGludGVyZXN0IGluIHRoZSB3b3JraW5n IGdyb3VwIGluIHRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gcmVsYXRpdmVseSBsb3cgZm9yIHF1aXRl DQogc29tZSB0aW1lLCBhcyBmYXIgYXMgSSBjYW4gdGVsbC4gQW5kIHRoZSBjb250ZW50IG9mIGRv Y3VtZW50cyBhbmQgdGhlIGNvbnNlbnN1cyBpbiBhIHdvcmtpbmcgZ3JvdXAgY2FuIGNoYW5nZSBv dmVyIHRpbWUuIEFuZCBub3RlIHRoYXQgdGhlIGRvY3VtZW50IGlzIG5vdCBpbiBXR0xDLjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBoYXZlIGFscmVhZHkgbWVudGlvbmVkIHRoYXQgdGhlIG5lYXJpbmcgY29tcGxl dGlvbiBvZiA3OTNiaXMgaXMgYSBwZXJmZWN0IGV4YW1wbGUgZm9yIGEgbmV3IHNpdHVhdGlvbiwg YmVjYXVzZSBpdCBhbGxvd3MgYW5vdGhlciBzb2x1dGlvbiB0aGF0IHdhcyBub3QgcmVhbGx5IHJl YWxpc3RpYyBlYXJsaWVyLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoZXJlIGFyZSBvdGhlciBuZXcgaWRl YXMgc3VjaCBhcyBkcmFmdC1nb21lei10Y3BtLWFjay1wdWxsLCB3aGljaCBhcmUgcXVpdGUgcmVj ZW50IGFuZCBtYXliZSBub3QgcmVhbGx5IHdlbGwgdW5kZXJzdG9vZC4gSXMgdGhpcyBub3QgYSBu ZXcgc2l0dWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IHdoZW4gZGVj aWRpbmcgb24gYSBiaXQgYWxsb2NhdGlvbj8gVGhhdCBwcm9wb3NhbA0KIHdhcyBub3Qga25vd24g ZHVyaW5nIElFVEYgOTkuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1Z2dlc3QgdG8gbG9vayBmb3J3YXJkIGlu c3RlYWQgb2YgYmFja3dhcmQuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHM8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1pY2hhZWw8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxl bWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48Yj5Wb246IDwvYj48YSBocmVmPSJtYWls dG86aW5AYm9iYnJpc2NvZS5uZXQiPkJvYiBCcmlzY29lPC9hPjxicj4NCjxiPkdlc2VuZGV0OiA8 L2I+TW9udGFnLCA0LiBOb3ZlbWJlciAyMDE5IDE5OjA4PGJyPg0KPGI+QW46IDwvYj48YSBocmVm PSJtYWlsdG86TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlIj5TY2hhcmYsIE1pY2hhZWw8 L2E+PGJyPg0KPGI+Q2M6IDwvYj48YSBocmVmPSJtYWlsdG86cnNjaGVmZkBnbXguYXQiPlJpY2hh cmQgU2NoZWZmZW5lZ2dlcjwvYT47IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj4NCnRj cG1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldCI+TWly amEgS3VlaGxld2luZDwvYT48YnI+DQo8Yj5CZXRyZWZmOiA8L2I+UmU6IFt0Y3BtXSBPbiBhbGxv Y2F0aW5nIHJlc2VydmVkIGJpdHMgaW4gdGhlIFRDUCBoZWFkZXI8L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TWljaGFlbCw8YnI+DQo8YnI+DQpZb3Ugc2FpZCBkZWNpc2lvbnMgYXJlIGZpbmFsaXplZCBv biB0aGUgTUwuIFRoZW4gd2hlbiBJIGFza2VkIHdoZXRoZXIgdGhlIGRlY2lzaW9uIGhhZCBiZWVu IHF1ZXN0aW9uZWQgb24gdGhlIE1MIGF0IHRoZSB0aW1lIDIgeXJzIGFnbywgeW91IGRpZG4ndCBh bnN3ZXIuPGJyPg0KPGJyPg0KVGhhdCBiZWdzIGFuIGFuc3dlciB0byBteSBvdGhlciBxdWVzdGlv bjo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25l IHRoZW4gaGFzIHRvIGFzayB3aGF0IG5ldyBzaXR1YXRpb24gaGFzIGFyaXNlbiB0aGF0IG1ha2Vz IHRoaXMgZGVjaXNpb24gbmVlZCB0byBiZSByZXZpc2l0ZWQuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDA0LzExLzIwMTkgMTY6MzksIFNjaGFyZiwgTWljaGFlbCB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qm9iLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgSUVURiBjb25zZW5zdXMgZm9yIFJGQyA4MzExIHdhcyB0 byByZXR1cm4gdGhlIHN0YXR1cyBvZiB0aGUgYml0IHRvIOKAnnJlc2VydmVk4oCcIGFuZCB0aGlz IFJGQyB3YXMgcHVibGlzaGVkIGJ5IFRTVldHLCBub3QgYnkgVENQTS4gSSB3YXMgbm90IG11Y2gg aW4gdGhlIGxvb3AsIGJ1dCBJIGhhdmUgYWdyZWVkIHRvIHRoZSBhcHByb2FjaCB0YWtlbiBieSBS RkMgODMxMSBmb3IgdGhlIGJpdC4gVGhlIGZvcm1hbA0KIGltcGxpY2F0aW9ucyBvZiB0aGUg4oCe cmVzZXJ2ZWTigJwgc3RhdHVzIGFjY29yZGluZyB0byBSRkMgODMxMSBmb2xsb3cgZnJvbSBSRkMg Mjc4MCwgd2hpY2ggZG9lcyBub3QgZm9yZXNlZSBhbiBJRVNHIGFsbG9jYXRpb24uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhbHJlYWR5IGFyZ3VlZCBkdXJpbmcgSUVURiA5OSBmb3Ig YSBzdGFuZGFyZHMgdHJhY2sgc29sdXRpb24uIEJ5IHRoYXQgdGltZSwgdGhpcyB3b3VsZCBoYXZl IGltcGxpZWQgYSBuZXcgc21hbGwgUFMgZG9jdW1lbnQsIG5vdCBSRkM4MzExLiBUaGUgb3RoZXIg dmFyaWFudCBvZiB1c2luZyA3OTNiaXMgcHJvcG9zZWQgYnkgSm9lIGhhcyBub3QgcmVhbGx5IGJl ZW4gcmVhbGlzdGljIDIgeWVhcnMgYWdvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFcsIGdp dmVuIHRoZSBwb3RlbnRpYWwgc29sdXRpb24gdmlhIDc5M2Jpcywgd2UgYXJlIGluIGEgZGlmZmVy ZW50IHNpdHVhdGlvbiBub3csIG5vPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgZW5k IG9mIHRoZSBkYXksJm5ic3A7IHdlIG5lZWQgdG8gZmluZCBhIHNvbHV0aW9uIHRoYXQgaGFzIHN0 cm9uZyBUQ1BNIGNvbnNlbnN1cywgb3IsIGJldHRlciwgZXZlbiB1bmFuaW1vdXMgY29uc2Vuc3Vz LiBBbmQsIHRvIG1lIGl0IHNvdW5kcyBsaWtlIGEgYmFkIGlkZWEgdG8gaGF2ZSBhbiBJRVRGIGxh c3QgY2FsbCBkaXNjdXNzaW9uIGFib3V0IHByb2Nlc3MgdmlvbGF0aW9ucyBmb3IgYSBkb2N1bWVu dCB3aXRoDQogcG9zc2libHkgcmF0aGVyIHJvdWdoIFdHIGNvbnNlbnN1cywgbW9zdCBub3RhYmx5 IHJlZ2FyZGluZyBhIGNoYW5nZSBvZiB0aGUgbWFpbiBUQ1AgaGVhZGVyIHRoYXQgYWZmZWN0cyBl dmVyeSBzaW5nbGUgSW50ZXJuZXQgZGV2aWNlLiBJIHJlYWxseSBzdWdnZXN0IHRvIHRoaW5rIGFi b3V0IGFsdGVybmF0aXZlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlZvbjogPC9i PjxhIGhyZWY9Im1haWx0bzppbkBib2JicmlzY29lLm5ldCI+Qm9iIEJyaXNjb2U8L2E+PGJyPg0K PGI+R2VzZW5kZXQ6IDwvYj5Nb250YWcsIDQuIE5vdmVtYmVyIDIwMTkgMTU6MTA8YnI+DQo8Yj5B bjogPC9iPjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGUiPlNj aGFyZiwgTWljaGFlbDwvYT48YnI+DQo8Yj5DYzogPC9iPjxhIGhyZWY9Im1haWx0bzpyc2NoZWZm QGdteC5hdCI+UmljaGFyZCBTY2hlZmZlbmVnZ2VyPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRjcG1A aWV0Zi5vcmciPg0KdGNwbUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhs ZXdpbmQubmV0Ij5NaXJqYSBLdWVobGV3aW5kPC9hPjxicj4NCjxiPkJldHJlZmY6IDwvYj5SZTog W3RjcG1dIE9uIGFsbG9jYXRpbmcgcmVzZXJ2ZWQgYml0cyBpbiB0aGUgVENQIGhlYWRlcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+TWljaGFlbCw8YnI+DQo8YnI+DQpBdCB0aGUgdGltZSwgSSBoYWQgY29s bGVjdGVkIGEgbGlzdCBvZiBwb3NzaWJsZSBwcm9jZXNzIG9wdGlvbnMsIGNvbGxlY3RlZCBmcm9t IHRoZSBwcmVjZWRpbmcgTUwgZGlzY3Vzc2lvbnMuIEkgcHJlZmVycmVkIGluY2x1ZGluZyB0aGUg QWNjRUNOIGFzc2lnbm1lbnQgaW4gUkZDODMxMSAod2hpY2ggd2FzIGVuZGluZyBXR0xDIGF0IHRo YXQgdGltZSkuIEkgZG8gbm90IHJlY2FsbCB5b3UgYWdyZWVpbmcgd2l0aCBtZSwgYWx0aG91Z2gg eW91IGFyZQ0KIG5vdyBhcmd1aW5nIGZvciB0aGUgc2FtZSBwcm9jZXNzLCBidXQgd2l0aCBhIG5l dyBQUyBSRkMuPGJyPg0KPGJyPg0KV2FzIHRoZSBkZWNpc2lvbiBxdWVzdGlvbmVkIGF0IHRoZSB0 aW1lIG9uIHRoZSBtYWlsaW5nIGxpc3QgKDIgeWVhcnMgYWdvKSB3aGVuIGl0IHdvdWxkIGhhdmUg YmVlbiB0aW1lbHkgdG8gZG8gc28/PGJyPg0KPGJyPg0KT25lIHRoZW4gaGFzIHRvIGFzayB3aGF0 IG5ldyBzaXR1YXRpb24gaGFzIGFyaXNlbiB0aGF0IG1ha2VzIHRoaXMgZGVjaXNpb24gbmVlZCB0 byBiZSByZXZpc2l0ZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDQvMTEvMjAxOSAwMjowMCwgU2NoYXJm LCBNaWNoYWVsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Cb2IsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggY2hhaXIgaGF0 IG9uOiBUaGVyZSB3YXMgYSBkaXNjdXNzaW9uIOKAnmluIHRoZSByb29t4oCcIGR1cmluZyBJRVRG IDk5IGFuZCB0aGUgb3V0Y29tZSBvZiBhIGh1bSDigJ5pbiB0aGUgcm9vbeKAnCBpcyBkb2N1bWVu dGVkIGluIHRoZSBtaW51dGVzLiBJbiBUQ1BNLCBjb25zZW5zdXMgaXMgY29uZmlybWVkIG9uIHRo ZSBsaXN0IHNvIHRoYXQgYWxsIGNvbnRyaWJ1dG9ycyBjYW4gY29tbWVudC4gUGxlYXNlIGRvbuKA mXQgcmVmZXINCiB0byByb29tIGRpc2N1c3Npb25zIGFzIHdvcmtpbmcgZ3JvdXAg4oCeZGVjaXNp b25z4oCcLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIGNoYWlyIGhhdCBvZmYsIEkgYmVs aWV2ZSB0aGVyZSB3YXMgbmV2ZXIgYSBmb3JtYWwgY29uc2Vuc3VzIGRlY2lzaW9uIGluIFRDUE0g dG8gZXhwbGljaXRseSB2aW9sYXRlIFJGQ3MuIEFuZCwgYW55d2F5LCB0aGUgd29ya2luZyBncm91 cCBjb3VsZCBjaGFuZ2UgcGFzdCBkZWNpc2lvbnMsIGF0IGxlYXN0IHByaW9yIHRvIGNvbXBsZXRp bmcgYSBXR0xDLiBJbiB0aGlzIHNwZWNpZmljIGNhc2UsIGFzIGluZGl2aWR1YWwNCiBjb250cmli dXRvciwgSSBleHBsaWNpdGx5IGFuZCB2ZXJ5IHN0cm9uZ2x5IGRpc2FncmVlIHRvIG1vdmUgZm9y d2FyZCB3aXRoIGFuIGludmFsaWQgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Vm9uOiA8L2I+PGEgaHJlZj0ibWFpbHRv OmluQGJvYmJyaXNjb2UubmV0Ij5Cb2IgQnJpc2NvZTwvYT48YnI+DQo8Yj5HZXNlbmRldDogPC9i PlNvbm50YWcsIDMuIE5vdmVtYmVyIDIwMTkgMjM6MDQ8YnI+DQo8Yj5BbjogPC9iPjxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGUiPlNjaGFyZiwgTWljaGFlbDwv YT48YnI+DQo8Yj5DYzogPC9iPjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQiPg0KTWlyamEg S3VlaGxld2luZDwvYT47IDxhIGhyZWY9Im1haWx0bzpyc2NoZWZmQGdteC5hdCI+UmljaGFyZCBT Y2hlZmZlbmVnZ2VyPC9hPjxicj4NCjxiPkJldHJlZmY6IDwvYj5SZTogW3RjcG1dIE9uIGFsbG9j YXRpbmcgcmVzZXJ2ZWQgYml0cyBpbiB0aGUgVENQIGhlYWRlcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ TWljaGFlbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAw My8xMC8yMDE5IDEyOjMxLCBMYXJzIEVnZ2VydCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cHJlPk9uIDIwMTktOS0xMCwgYXQgMTM6NTAsIFNjaGFyZiwgTWljaGFlbCA8YSBocmVm PSJtYWlsdG86TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlIj4mbHQ7TWljaGFlbC5TY2hh cmZAaHMtZXNzbGluZ2VuLmRlJmd0OzwvYT4gd3JvdGU6PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SW4gbXkgcmVh ZGluZyBvZiBSRkMgMjc4MCBhbmQgUkZDIDgxMjYsIGl0IHdvdWxkIGJlIGEgcG9saWN5IHZpb2xh dGlvbiB0byBhbGxvY2F0ZSBhIGJpdCBpbiB0aGUgbWFpbiBUQ1AgaGVhZGVyIHRvIGFuIGV4cGVy aW1lbnQgd2l0aG91dCBhIHByb3BlciBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgYWxsb3dpbmcg dGhpcyBleHBlcmltZW50YXRpb24uIEkgYW0gY29udmluY2VkIHRoYXQgZm9yIGJpdHMgaW4gdGhl IG1haW4gVENQIGhlYWRlciB0aGUgSUVURiBzaG91bGQganVzdCBmb2xsb3cgaXRzIG93biBydWxl cy48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+QWdyZWVkLjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5MYXJzPC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCklmIGFza2VkIHRoaXMgcXVlc3Rpb24gaW4gaXNvbGF0aW9uLCBJIHdvdWxkIGdvIGZv ciBhIHF1aWNrIFJGQy4gQnV0IHRoaXMgaXMgbm90IGluIGlzb2xhdGlvbi48YnI+DQo8YnI+DQpU aGUgZGVjaXNpb24gb24gd2hhdCBwcm9jZXNzIHRvIHVzZSBoYXMgYWxyZWFkeSBiZWVuIG1hZGUg LSBpbiBKdWwgMjAxNyBhdCBJRVRGLTk5IChpdCB3YXMgZm9yIHRoZSBJRVNHIHRvIGJlIGFza2Vk IHRvIG1ha2UgYSBwcm9jZXNzIGV4Y2VwdGlvbikuIFRoaXMgaXMganVzdCBhIGNob2ljZSBiZXR3 ZWVuIHByb2Nlc3Nlcy4gVGhlcmUncyBubyBkaWZmZXJlbmNlIHRvIHRoZSB0ZWNobmljYWwgb3V0 Y29tZS4gUGxlYXNlIGNhbiB3ZSBqdXN0IGRvDQogaXQgdGhlIHdheSB3ZSBhbHJlYWR5IGRlY2lk ZWQgdG8uPGJyPg0KPGJyPg0KQWx0aG8gSSdtIGEgQnJpdCwgSSBhbSBub3QgYSBmYW4gb2YgcGVv cGxlIHRyeWluZyB0byByZS1ydW4gYSA8cz5yZWZlcmVuZHVtPC9zPiBkZWNpc2lvbiAnY29zIHRo ZXkgZGlkbid0IGdldCB3aGF0IHRoZXkgd2FudGVkIGluIHRoZSBwcmV2aW91cyBvbmUuPGJyPg0K PGJyPg0KPGJyPg0KQmFja2dyb3VuZDxicj4NClRoaXMgaXNzdWUgd2FzIGV4dGVuc2l2ZWx5IGRp c2N1c3NlZCBhbHJlYWR5LiBBZnRlciBhIGxvbmcgb2ZmbGlzdCB0aHJlYWQgd2l0aCB0aGUgYXV0 aG9yIG9mIFJGQzgzMTEgYW5kIG90aGVycywgYSB0aHJlYWQgb24gdHN2d2cgcmFuIGJldHcgMyB0 byAxMiBKdWwgMTc6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHN2d2cva1VZd1ZKUVhRZkh6dFF6S3RnN0ZmcFNG U1BNIiB0YXJnZXQ9Il9CTEFOSyI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL3RzdndnL2tVWXdWSlFYUWZIenRRekt0ZzdGZnBTRlNQTTwvYT48YnI+DQpUaGlzIHRocmVh ZCBlbmRzIGJ5IGRlZmVycmluZyB0byBhIG1lZXRpbmcgYXJyYW5nZWQgYXQgSUVURi05OSBkdXJp bmcgQUQgT2ZmaWNlIEhvdXJzLCBhdCB3aGljaCB0aGUgdGNwbSBjaGFpcnMgd2VyZSByZXByZXNl bnRlZC4NCjxicj4NClRoZSBvdXRjb21lIG9mIHRoYXQgbWVldGluZyB3YXMgdG8gZXhwZWN0IHRo ZSBBY2NFQ04gZHJhZnQgdG8gcmVuYW1lIGJpdCA3IGFuZCBhc3NpZ24gaXQgdG8gaXRzZWxmLCB3 aGljaCB3b3VsZCBuZWVkIHRoZSBJRVNHIHRvIGFncmVlIGEgcHJvY2VzcyBleGNlcHRpb24uIFRo YXQgb3V0Y29tZSB3YXMgcmVjb3JkZWQgb24gdGhpcyBzbGlkZSBmb3IgZGlzY3Vzc2lvbiBpbiB0 aGUgc3Vic2VxdWVudCB0Y3BtIFdHIG1lZXRpbmc6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9tYXRlcmlhbHMv c2xpZGVzLTk5LXRjcG0tbW9yZS1hY2N1cmF0ZS1lY24tZmVlZGJhY2staW4tdGNwLTAyI3BhZ2U9 NyIgdGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n Lzk5L21hdGVyaWFscy9zbGlkZXMtOTktdGNwbS1tb3JlLWFjY3VyYXRlLWVjbi1mZWVkYmFjay1p bi10Y3AtMDIjcGFnZT03PC9hPjxicj4NClRoZSB0Y3BtIG1pbnV0ZXMgaGVyZTo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0 aW5nLzk5L21hdGVyaWFscy9taW51dGVzLTk5LXRjcG0tMDAiIHRhcmdldD0iX0JMQU5LIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9tYXRlcmlhbHMvbWludXRlcy05 OS10Y3BtLTAwPC9hPjxicj4NCnJlY29yZCB0aGF0ICZxdW90O1RoZXJlIGlzIHN0cm9uZyBidXQg bm90IHVuYW5pbW91cyBjb25zZW5zdXMgaW4gdGhlIHJvb20gZm9yIGFzc2lnbmluZyB0aGUgY29k ZXBvaW50LiZxdW90Ozxicj4NCmFuZCB0aGUgcHJvY2VzcyBwcm9wb3NhbCByZW1haW5lZCB1bmNo YW5nZWQ6IHRoYXQgdGhlIElFU0cgd291bGQgYmUgYXNrZWQgdG8gbWFrZSBhIHByb2Nlc3MgZXhj ZXB0aW9uLjxicj4NCjxicj4NCkkgZGlkbid0IGxpa2UgdGhhdCBkZWNpc2lvbiBlaXRoZXIsIGJ1 dCB0aGlzIGlzIGp1c3QgcHJvY2Vzcy4gQ2FuIHdlIG1vdmUgb24gcGxlYXNlLjxicj4NCjxicj4N Cjxicj4NCkJvYjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8L3By ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cDovL2JvYmJyaXNj b2UubmV0LzwvYT48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9wcmU+DQo8cHJlPnRjcG0gbWFpbGluZyBsaXN0PC9wcmU+DQo8cHJl PjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0i IHRhcmdldD0iX0JMQU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rj cG08L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3ByZT4N CjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0 LyIgdGFyZ2V0PSJfQkxBTksiPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PC9wcmU+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHByZT4tLSA8L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcHJlPg0KPHByZT5Cb2Ig QnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIiB0YXJnZXQ9 Il9CTEFOSyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE45Erznt8114rzntrzd_-- From nobody Mon Nov 4 11:09: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 692CE1200F4; Mon, 4 Nov 2019 11:09:13 -0800 (PST) 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 EVxRX4HrHDVP; Mon, 4 Nov 2019 11:09:08 -0800 (PST) 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 05539120A0E; Mon, 4 Nov 2019 11:09:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 486A225A20; Mon, 4 Nov 2019 20:09:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572894544; bh=z03RdrKx/mGXK7sAOqWdqIm79842ViT0zqtV6VjC8o8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=dA9ODZ6qfmesBImVwUxccu0sDBzWrHflw3vd7M4BCuQDSvpkRaRVrFWGh9OZQNcqW mmRSB5FeMJch3oDEKzqXRFIhjX7dLCrRHQBUDNJ0x+ep5NQvbgRNoBojNXohgc2khE kBD6eCXIWQ2fUFplhUkVmJcsO9/s44U/L4XRtBik= 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 WV6RD5ma7-90; Mon, 4 Nov 2019 20:08:12 +0100 (CET) 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; Mon, 4 Nov 2019 20:08:12 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 20:08:11 +0100 From: "Scharf, Michael" To: Bob Briscoe , Wesley Eddy , "tsvwg@ietf.org" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] [tsvwg] L4S status tracking Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53g== Date: Mon, 4 Nov 2019 19:08:11 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de>, <9f59d918-1907-450c-6139-0fd17646a7dd@bobbriscoe.net> In-Reply-To: <9f59d918-1907-450c-6139-0fd17646a7dd@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE531rznt8114rzntrzd_" 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: Mon, 04 Nov 2019 19:09:14 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE531rznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You can e.g. use =84non-L4S-enabled TCP=93. Terminology does matter to me given that I strongly disagree to any use of = =84marketing language=93 when it comes to TCP. Michael Von: Bob Briscoe Gesendet: Montag, 4. November 2019 19:09 An: Scharf, Michael; Wesley Eddy; tsvwg@ietf.org Cc: tcpm@ietf.org Betreff: Re: [tcpm] [tsvwg] L4S status tracking Michael, Previously, I have been told not to use the term standard for RFCs that are= not standards. RFC5681 is 'only' a draft standard. This is why, in the IET= F at least, I avoid using the term "standard TCP congestion control". I gen= erally call it Reno when referring to the congestion control. I have never, to my knowledge, used the term classic TCP, or classic TCP co= ngestion control. And I rarely use the term legacy, and if I do I'm happy to have alternative= s suggested. I've checked the L4S drafts, and there is one phrase that I shall leave in = ecn-l4s-id: "the traditional TCP Reno additive increase", because this is c= orrectly used to mean the traditional increase (in numerous AIMD CCs), not = traditional TCP. There was one other occurrence of "traditional TCP senders= " in a whole para in an appendix that has just been deleted anyway. And in = aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic tra= ffic" now in my local copy, using the defined term in all the L4S drafts). l4s-arch is getting a complete make-over for terminology, so I will check t= hat next. inline... On 23/08/2019 15:01, Scharf, Michael wrote: 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 =84c= lassic TCP=93 or =84legacy=93 TCP when referring to a TCP implementation ac= cording 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. You're entitled to your opinion but, as a native speaker, I don't think 'cl= assic' or 'traditional' are particularly pejorative, tho they can be when u= sed in a context that intends them to be. They also mean "stood the test of= time". I find 'legacy' has a connotation of marketing-speak, but it's not = that bad. This is an enduring problem when trying to improve on the good work that ot= her people have done before you (which is the context of everything we are = doing). We need a word that distinguishes the old from the new, but we don'= t want to completely trash the thing that has already been successful, but = had its day. Nonetheless, it is also important not to be too precious about past work. W= e all recognize that Reno TCP is unscalable and has problems. IMO, it is OK= to describe technologies that have had their time with negative connotatio= ns. Indeed, you have been an author (with me) of an RFC on open issues in c= ongestion control. I notice you haven't suggested an alternative term for "the thing(s) we are= trying to improve on". Not surprising, because it's difficult. When we (the L4S developers) were first looking for a term for the non-L4S = queue and the non-L4S service, we didn't want to use 'legacy' for the above= reasons, but we did want to imply pre-existing, so we decided on 'classic'= , which we all felt had a generally neutral connotation, but said what we m= eant. Finally, I do not want this issue to take up any time that would detract fr= om technical issues. Bob 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. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE531rznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

You can e.g. use =84non-L4S-enabled TCP=93.

 

Terminology does matter to me given that I strongly = disagree to any use of =84marketing language=93 when it comes to TCP.

 

Michael

 

 <= /span>

 

Von: Bob Briscoe
Gesendet: Montag, 4. November 2019 19:09
An: Scharf, Michae= l; Wesley Eddy; tsvwg@ietf.org
Cc: tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

 

Michael,

Previously, I have been told not to use the term standard for RFCs that are= not standards. RFC5681 is 'only' a draft standard. This is why, in the IET= F at least, I avoid using the term "standard TCP congestion control&qu= ot;. I generally call it Reno when referring to the congestion control.

I have never, to my knowledge, used the term classic TCP, or classic TCP co= ngestion control.

And I rarely use the term legacy, and if I do I'm happy to have alternative= s suggested.

I've checked the L4S drafts, and there is one phrase that I shall leave in = ecn-l4s-id: "the traditional TCP Reno additive increase", because= this is correctly used to mean the traditional increase (in numerous AIMD = CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in an ap= pendix that has just been deleted anyway. And in aqm-dualq-coupled there wa= s one "legacy TCP flows" (changed to "Classic traffic" = now in my local copy, using the defined term in all the L4S drafts).

l4s-arch is getting a complete make-over for terminology, so I will check t= hat next.

inline...


On 23/08/2019 15:01, Scharf, Michael wrote:<= br>

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.

You're entitled to your opinion but, as a native speaker, I don't think 'cl= assic' or 'traditional' are particularly pejorative, tho they can be when u= sed in a context that intends them to be. They also mean "stood the te= st of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad.

This is an enduring problem when trying to improve on the good work that ot= her people have done before you (which is the context of everything we are = doing). We need a word that distinguishes the old from the new, but we don'= t want to completely trash the thing that has already been successful, but had its day.

Nonetheless, it is also important not to be too precious about past work. W= e all recognize that Reno TCP is unscalable and has problems. IMO, it is OK= to describe technologies that have had their time with negative connotatio= ns. Indeed, you have been an author (with me) of an RFC on open issues in congestion control.

I notice you haven't suggested an alternative term for "the thing(s) w= e are trying to improve on". Not surprising, because it's difficult.
When we (the L4S developers) were first looking for a term for the non-L4S = queue and the non-L4S service, we didn't want to use 'legacy' for the above= reasons, but we did want to imply pre-existing, so we decided on 'classic'= , which we all felt had a generally neutral connotation, but said what we meant.

Finally, I do not want this issue to take up any time that would detract fr= om technical issues.



Bob

 

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.



______________________________________________=
_
tcpm mailing list
tcpm@ie=
tf.org
https://www.ietf.org/mailman/listinfo/tcpm


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE531rznt8114rzntrzd_-- From nobody Mon Nov 4 11:18:04 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> 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 5F2F5120112; Mon, 4 Nov 2019 11:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 P4rv4fKnQOu1; Mon, 4 Nov 2019 11:17:54 -0800 (PST) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FEE120018; Mon, 4 Nov 2019 11:17:54 -0800 (PST) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA4JH2Qs002065; Mon, 4 Nov 2019 11:17:02 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA4JH2nX002064; Mon, 4 Nov 2019 11:17:02 -0800 (PST) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" Date: Mon, 4 Nov 2019 11:17:02 -0800 (PST) CC: Bob Briscoe , Wesley Eddy , "tsvwg@ietf.org" , "tcpm@ietf.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Mon, 04 Nov 2019 19:17:56 -0000 > You can e.g. use ?non-L4S-enabled TCP?. > > Terminology does matter to me given that I strongly disagree to any use of ?marketing language? when it comes to TCP. My concern here of use of terms like, legacy, classic, new, old is that they are pretty much all of the relative from and thus ambiguous over time. newReno is new only relative to Reno, that is fairly clear, but if I said newTCP or oldTCP with what frame should the reference be evaluated. I believe in the case of L4S the time invariant term would be, as Michael suggests above, "non-L4S". Note that enabled for me is a noise word in this context, and TCP may or may not be needed depending on context, but for literal replacement of Legacy or Classic "non-L4S" is invariant over time. Rod > Michael > > > Von: Bob Briscoe > Gesendet: Montag, 4. November 2019 19:09 > An: Scharf, Michael; Wesley Eddy; tsvwg@ietf.org > Cc: tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > Michael, > > Previously, I have been told not to use the term standard for RFCs that are not standards. RFC5681 is 'only' a draft standard. This is why, in the IETF at least, I avoid using the term "standard TCP congestion control". I generally call it Reno when referring to the congestion control. > > I have never, to my knowledge, used the term classic TCP, or classic TCP congestion control. > > And I rarely use the term legacy, and if I do I'm happy to have alternatives suggested. > > I've checked the L4S drafts, and there is one phrase that I shall leave in ecn-l4s-id: "the traditional TCP Reno additive increase", because this is correctly used to mean the traditional increase (in numerous AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in an appendix that has just been deleted anyway. And in aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic traffic" now in my local copy, using the defined term in all the L4S drafts). > > l4s-arch is getting a complete make-over for terminology, so I will check that next. > > inline... > > > On 23/08/2019 15:01, Scharf, Michael wrote: > > Hi Wes, > > > > I?d 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-hDvWO3I5MudwpNkKyHY , I object to the terms ?traditional TCP? and also ?classic TCP? or ?legacy? TCP when referring to a TCP implementation according to IETF standards-track RFCs. > > > > To me as a non-native native speaker, all these terms have a negative connotation. I also think this language is typical to marketing material. > > You're entitled to your opinion but, as a native speaker, I don't think 'classic' or 'traditional' are particularly pejorative, tho they can be when used in a context that intends them to be. They also mean "stood the test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad. > > This is an enduring problem when trying to improve on the good work that other people have done before you (which is the context of everything we are doing). We need a word that distinguishes the old from the new, but we don't want to completely trash the thing that has already been successful, but had its day. > > Nonetheless, it is also important not to be too precious about past work. We all recognize that Reno TCP is unscalable and has problems. IMO, it is OK to describe technologies that have had their time with negative connotations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control. > > I notice you haven't suggested an alternative term for "the thing(s) we are trying to improve on". Not surprising, because it's difficult. > > When we (the L4S developers) were first looking for a term for the non-L4S queue and the non-L4S service, we didn't want to use 'legacy' for the above reasons, but we did want to imply pre-existing, so we decided on 'classic', which we all felt had a generally neutral connotation, but said what we meant. > > Finally, I do not want this issue to take up any time that would detract from technical issues. > > > > Bob > > > > > My prefered term when referring to TCP according to standards-track specification 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 TCP standard congestion control (?Reno?). As of today, this is the TCP congestion control 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 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 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 and I don?t ask for changes in those cases. > > > > Some use of the term ?Classic Service? may also require careful review to clearly 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 speaker, it would be really strange to use the term ?classic? in the context of a brand-new transport protocol. IMHO in that case the term ?classic? 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=ticket&asc=1&page=1 > > 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. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.org From nobody Mon Nov 4 11:22: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 9C553120018; Mon, 4 Nov 2019 11:22:05 -0800 (PST) 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 TzErkFD5GpYE; Mon, 4 Nov 2019 11:22:03 -0800 (PST) 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 AEF26120115; Mon, 4 Nov 2019 11:22:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 5A63D25A20; Mon, 4 Nov 2019 20:22:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572895321; bh=g1KHKlEksR4DLG5MVatm54DfzMf73v7FF0EHvYRLRy8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=K0s4tjvWV/m1FYpS5ljSxu/a/Om2n4qF0tB0i3alEqAdVldHc1zZ/9UmAXoYDkXpq xBmNvnsz0YYCDFr5A6TOdRgaULtiuG5MXJWqcqXEhQL3Gcu+xW1SH0emxetNyLVgOu jxdM+A8V1XhwsbpHOHc9LHoefy6orwzvrRjYsN6k= 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 6CsZ0keuQEfy; Mon, 4 Nov 2019 20:21:59 +0100 (CET) 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; Mon, 4 Nov 2019 20:21:59 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 20:21:59 +0100 From: "Scharf, Michael" To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: Bob Briscoe , Wesley Eddy , "tsvwg@ietf.org" , "tcpm@ietf.org" Thread-Topic: [tcpm] [tsvwg] L4S status tracking Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53v//8bUAgAASJQ4= Date: Mon, 4 Nov 2019 19:21:59 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de>, <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> In-Reply-To: <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE88Erznt8114rzntrzd_" 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: Mon, 04 Nov 2019 19:22:06 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE88Erznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree. =84non-L4S=93 may be even better. Michael Von: Rodney W. Grimes Gesendet: Montag, 4. November 2019 20:17 An: Scharf, Michael Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org Betreff: Re: [tcpm] [tsvwg] L4S status tracking > You can e.g. use ?non-L4S-enabled TCP?. > > Terminology does matter to me given that I strongly disagree to any use o= f ?marketing language? when it comes to TCP. My concern here of use of terms like, legacy, classic, new, old is that they are pretty much all of the relative from and thus ambiguous over time. newReno is new only relative to Reno, that is fairly clear, but if I said newTCP or oldTCP with what frame should the reference be evaluated. I believe in the case of L4S the time invariant term would be, as Michael suggests above, "non-L4S". Note that enabled for me is a noise word in this context, and TCP may or may not be needed depending on context, but for literal replacement of Legacy or Classic "non-L4S" is invariant over time. Rod > Michael > > > Von: Bob Briscoe > Gesendet: Montag, 4. November 2019 19:09 > An: Scharf, Michael; Wesley Eddy; tsvwg@ietf.org > Cc: tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > Michael, > > Previously, I have been told not to use the term standard for RFCs that a= re not standards. RFC5681 is 'only' a draft standard. This is why, in the I= ETF at least, I avoid using the term "standard TCP congestion control". I g= enerally call it Reno when referring to the congestion control. > > I have never, to my knowledge, used the term classic TCP, or classic TCP = congestion control. > > And I rarely use the term legacy, and if I do I'm happy to have alternati= ves suggested. > > I've checked the L4S drafts, and there is one phrase that I shall leave i= n ecn-l4s-id: "the traditional TCP Reno additive increase", because this is= correctly used to mean the traditional increase (in numerous AIMD CCs), no= t traditional TCP. There was one other occurrence of "traditional TCP sende= rs" in a whole para in an appendix that has just been deleted anyway. And i= n aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic t= raffic" now in my local copy, using the defined term in all the L4S drafts)= . > > l4s-arch is getting a complete make-over for terminology, so I will check= that next. > > inline... > > > On 23/08/2019 15:01, Scharf, Michael wrote: > > Hi Wes, > > > > I?d 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-h= DvWO3I5MudwpNkKyHY , I object to the terms ?traditional TCP? and also ?class= ic TCP? or ?legacy? TCP when referring to a TCP implementation according to= IETF standards-track RFCs. > > > > To me as a non-native native speaker, all these terms have a negative con= notation. I also think this language is typical to marketing material. > > You're entitled to your opinion but, as a native speaker, I don't think '= classic' or 'traditional' are particularly pejorative, tho they can be when= used in a context that intends them to be. They also mean "stood the test = of time". I find 'legacy' has a connotation of marketing-speak, but it's no= t that bad. > > This is an enduring problem when trying to improve on the good work that = other people have done before you (which is the context of everything we ar= e doing). We need a word that distinguishes the old from the new, but we do= n't want to completely trash the thing that has already been successful, bu= t had its day. > > Nonetheless, it is also important not to be too precious about past work.= We all recognize that Reno TCP is unscalable and has problems. IMO, it is = OK to describe technologies that have had their time with negative connotat= ions. Indeed, you have been an author (with me) of an RFC on open issues in= congestion control. > > I notice you haven't suggested an alternative term for "the thing(s) we a= re trying to improve on". Not surprising, because it's difficult. > > When we (the L4S developers) were first looking for a term for the non-L4= S queue and the non-L4S service, we didn't want to use 'legacy' for the abo= ve reasons, but we did want to imply pre-existing, so we decided on 'classi= c', which we all felt had a generally neutral connotation, but said what we= meant. > > Finally, I do not want this issue to take up any time that would detract = from technical issues. > > > > Bob > > > > > My prefered term when referring to TCP according to standards-track speci= fication is ?standard TCP?. I would also be fine with other terms as long a= s they are neutral and make clear that experiments do not replace, deprecat= e, or outperform standards. > > > > Similarly, I think that term such as ?classic? is not appropriate for the= TCP standard congestion control (?Reno?). As of today, this is the TCP con= gestion control algorithm on standards track that has IETF consensus. The t= erm 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?, ?lega= cy AQM? or the like, i.e., if the context is ECN and not specifically TCP o= r 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 opinio= n on that. As far as I can see, most use of the term ?classic? is in this c= ontext and I don?t ask for changes in those cases. > > > > Some use of the term ?Classic Service? may also require careful review to= clearly 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 s= peaker, it would be really strange to use the term ?classic? in the context= of a brand-new transport protocol. IMHO in that case the term ?classic? wo= uld 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. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.= org --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE88Erznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I agree. =84non-L4S=93 may be even better.

 

Michael

 = ;

 

Von: Rodney W. Grimes
Gesendet: Montag, 4. November 2019 20:17
An: Scharf, Michae= l
Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

 

> You can e.g. use ?non-L4S-enabled TCP?.
>
> Terminology does matter to me given that I strongly disagree to any us= e of ?marketing language? when it comes to TCP.

My concern here of use of terms like, legacy, classic, new, old
is that they are pretty much all of the relative from and thus
ambiguous over time.

newReno is new only relative to Reno, that is fairly clear,
but if I said newTCP or oldTCP with what frame should the
reference be evaluated.

I believe in the case of L4S the time invariant term would be,
as Michael suggests above, "non-L4S".   Note that enabl= ed
for me is a noise word in this context, and TCP may or may
not be needed depending on context, but for literal replacement
of Legacy or Classic "non-L4S" is invariant over time.

Rod

> Michael
>
>
> Von: Bob Briscoe<mailto:ietf= @bobbriscoe.net>
> Gesendet: Montag, 4. November 2019 19:09
> An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley Eddy<mailto:wes@mti-systems.com>; tsvwg@ietf= .org<mailto:tsvwg@ietf.org>
> Cc: tcpm@ietf.org<mailto:tcpm@ietf= .org>
> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael,
>
> Previously, I have been told not to use the term standard for RFCs tha= t are not standards. RFC5681 is 'only' a draft standard. This is why, in th= e IETF at least, I avoid using the term "standard TCP congestion contr= ol". I generally call it Reno when referring to the congestion control.
>
> I have never, to my knowledge, used the term classic TCP, or classic T= CP congestion control.
>
> And I rarely use the term legacy, and if I do I'm happy to have altern= atives suggested.
>
> I've checked the L4S drafts, and there is one phrase that I shall leav= e in ecn-l4s-id: "the traditional TCP Reno additive increase", be= cause this is correctly used to mean the traditional increase (in numerous = AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in= an appendix that has just been deleted anyway. And in aqm-dualq-coupled th= ere was one "legacy TCP flows" (changed to "Classic traffic&= quot; now in my local copy, using the defined term in all the L4S drafts).
>
> l4s-arch is getting a complete make-over for terminology, so I will ch= eck that next.
>
> inline...
>
>
> On 23/08/2019 15:01, Scharf, Michael wrote:
>
> Hi Wes,
>
>
>
> I?d like to add a smaller item that is mostly editorial and can hopefu= lly be sorted just out by re-wording, albeit it may require a careful analy= sis of all documents.
>
>
>
> As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<= https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?classic TCP? or ?= legacy? TCP when referring to a TCP implementation according to IETF standards-track RFCs.
>
>
>
> To me as a non-native native speaker, all these terms have a negative = connotation. I also think this language is typical to marketing material. >
> You're entitled to your opinion but, as a native speaker, I don't thin= k 'classic' or 'traditional' are particularly pejorative, tho they can be w= hen used in a context that intends them to be. They also mean "stood t= he test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad.
>
> This is an enduring problem when trying to improve on the good work th= at other people have done before you (which is the context of everything we= are doing). We need a word that distinguishes the old from the new, but we= don't want to completely trash the thing that has already been successful, but had its day.
>
> Nonetheless, it is also important not to be too precious about past wo= rk. We all recognize that Reno TCP is unscalable and has problems. IMO, it = is OK to describe technologies that have had their time with negative conno= tations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control.
>
> I notice you haven't suggested an alternative term for "the thing= (s) we are trying to improve on". Not surprising, because it's difficu= lt.
>
> When we (the L4S developers) were first looking for a term for the non= -L4S queue and the non-L4S service, we didn't want to use 'legacy' for the = above reasons, but we did want to imply pre-existing, so we decided on 'cla= ssic', which we all felt had a generally neutral connotation, but said what we meant.
>
> Finally, I do not want this issue to take up any time that would detra= ct from technical issues.
>
>
>
> Bob
>
>
>
>
> My prefered term when referring to TCP according to standards-track sp= ecification is ?standard TCP?. I would also be fine with other terms as lon= g as they are neutral and make clear that experiments do not replace, depre= cate, or outperform standards.
>
>
>
> Similarly, I think that term such as ?classic? is not appropriate for = the TCP standard congestion control (?Reno?). As of today, this is the TCP = congestion control algorithm on standards track that has IETF consensus. Th= e term in the TCPM charter is ?TCP standard congestion control?. I also think that terms such as ?Reno-compat= ible? or the like would be neutral.
>
>
>
> Note that I do not object to the terms ?classic ECN?, ?legacy ECN?, ?l= egacy AQM? or the like, i.e., if the context is ECN and not specifically TC= P 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 u= se of the term ?classic? is in this context and I don?t ask for changes in = those cases.
>
>
>
> Some use of the term ?Classic Service? may also require careful review= to clearly 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-nativ= e speaker, it would be really strange to use the term ?classic? in the cont= ext of a brand-new transport protocol. IMHO in that case the term ?classic? would be even more confusing.
>
>
>
> I also add the TCPM list in CC to ensure consistency.
>
>
>
> Thanks
>
>
>
> Michael (with no hat)
>
>
>
>
>
> Von: Wesley Eddy<mailto:wes@= mti-systems.com>
> Gesendet: Sonntag, 11. August 2019 07:08
> An: tsvwg@ietf.org<mailto:tsvwg@i= etf.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=3Dtic= ket&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 ticke= t
> numbers or some key words in threads and messages, when significant. >
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org<mailto:tcpm@ietf.org= >
> https://www.iet= f.org/mailman/listinfo/tcpm
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe          = ;            &n= bsp;        http://bobbriscoe.net/

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

--
Rod Grimes           = ;            &n= bsp;            = ;             r= grimes@freebsd.org
 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE88Erznt8114rzntrzd_-- From nobody Mon Nov 4 14:04: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 A98B4120169; Mon, 4 Nov 2019 14:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 vtMN5HjYziMC; Mon, 4 Nov 2019 14:04:36 -0800 (PST) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D7F1200C4; Mon, 4 Nov 2019 14:04:36 -0800 (PST) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA4M4Zq9002800; Mon, 4 Nov 2019 14:04:35 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA4M4Zob002799; Mon, 4 Nov 2019 14:04:35 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net> In-Reply-To: <157290286794.13904.901718335997193791.idtracker@ietfa.amsl.com> To: tcpm@ietf.org Date: Mon, 4 Nov 2019 14:04:35 -0800 (PST) CC: tsvwg@ietf.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-01.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, 04 Nov 2019 22:04:38 -0000 All, Cross posting to tsvwg and tcpm due to overlap in areas covered, I have just posted an updated version of TCPSCE which hopefully addresses most of the feedback provided since the original publication. The document structure is unchanged, and the history tool works well to show what has been changed since the last revision. Thanks to those who have provided feedback, and assistance in updating this draft. Regards, Rod > > A new version of I-D, draft-grimes-tcpm-tcpsce-01.txt > has been successfully submitted by Rodney W. Grimes and posted to the > IETF repository. > > Name: draft-grimes-tcpm-tcpsce > Revision: 01 > Title: Some Congestion Experienced in TCP > Document date: 2019-11-04 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce-01.txt > Status: https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/ > Htmlized: https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-grimes-tcpm-tcpsce > Diff: https://www.ietf.org/rfcdiff?url2=draft-grimes-tcpm-tcpsce-01 > > Abstract: > This memo classifies a TCP code point ESCE ("Echo Some Congestion > Experienced") for use in feedback of IP code point SCE ("Some > Congestion Experienced"). > > > > -- Rod Grimes rgrimes@freebsd.org From nobody Mon Nov 4 20:41:32 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 73EB612003F; Mon, 4 Nov 2019 20:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 HBHVEFGqaIic; Mon, 4 Nov 2019 20:41:28 -0800 (PST) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 18C1012002F; Mon, 4 Nov 2019 20:41:27 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id w12so21120307iol.11; Mon, 04 Nov 2019 20:41:27 -0800 (PST) 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; bh=tSSS+8Iq+Bb4gojrhr9tIOlwcTpNPo7wlRsrvJZJ7xw=; b=G9LaiQ871AKCqDUq1ofaYcHl2PxwlAkWVDqkt0YGSnXXcgSIQ964Y2s8ZU9pJe1CPv EEaTzqinWEdEOoLmw8OWb5Vcg2GNCl0Ip2Vh4ZRyQ3FZg9iYjFPcgpa46yAg0a9OeiPV oZ42Of37UjEoNYNBMGcltebpandCVAg0SQHwPDy7CcnMGIMDfNzB5oc3EY8K+7svplNU nhFF+b5k1X6RvjsZMeUsEPlZCv6uDbNQwLsqegn1Vv9pfJsncEHnfm+UTW0gr3iTpPeZ FZ5XggiX3B2Q6WJc44FIGvg4bnQRYQk7CUlOZ1Wg4kmDuOij4G3xZzTq6FktUS29q+rG gH3A== 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; bh=tSSS+8Iq+Bb4gojrhr9tIOlwcTpNPo7wlRsrvJZJ7xw=; b=GD5bVEgCJ9pAKLI6OBUEwSVPiwkO7ArbCgRiCks6VI1Jg9arF4k1smjhbsNbrYTntg mZk0QfRjjynR33NSK8i32Gn3/KzRQbqe16k3/ut9wl+2hv1jKTcQsG6U3pmZ1MKzgqT6 PvWwjTqdWhb2lb5A1tgHjUX8PLsRYu/joRPkAtORqOiokM3fIH7ilnB1214Q5JOj48Z+ H2eoWsCWboIIaGfNJrH1qcGW/bjycfdznbD8Mc4P8UEiXPW5zlCo0Mo3bhLnbSnFYKAk BZYcrpazV6BrtQ2IDgFggxh/k5M5gwr2aV6mJ0fCuOCEfkh6BeYfdt5lnE9iipoIZ0Mz V+qw== X-Gm-Message-State: APjAAAVxbbrZheMbuJ+Gqnr2c2oapWK+XJXW+KDF/FSWyixRx/rxO6p0 fJMS3IuhBb5YgnReYHjCBQCf5Fpoz8GQOStTEAEcut9K X-Google-Smtp-Source: APXvYqzyUM3CjD1QkWpPABwKyXC1yY6mtGMSIv4o/rz6V/MRX+Xu3HefAh/CfY4ZEWmlxuKdDWTVoHBPbKqACvaKYKY= X-Received: by 2002:a6b:b988:: with SMTP id j130mr15182551iof.106.1572928887292; Mon, 04 Nov 2019 20:41:27 -0800 (PST) MIME-Version: 1.0 References: <5DBFDF26.5080101@erg.abdn.ac.uk> <201911041658.xA4GwckY001605@gndrsh.dnsmgr.net> In-Reply-To: <201911041658.xA4GwckY001605@gndrsh.dnsmgr.net> From: Loganaden Velvindron Date: Tue, 5 Nov 2019 08:41:15 +0400 Message-ID: To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Cc: gorry@erg.abdn.ac.uk, "Rodney W. Grimes" , Jonathan Morton , "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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: Tue, 05 Nov 2019 04:41:31 -0000 On Mon, Nov 4, 2019 at 8:59 PM Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> wrote: > > > On 03/11/2019, 13:08, Jonathan Morton wrote: > > >> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst wrote: > > >> > > >>> With respect to draft-ietf-tcpm-accurate-ecn and > > >>> draft-grimes-tcpm-tcpsce compatibility: > > >>> When accurate ecn (AccECN) fails to negotiate an AccECN capable session > > >>> it falls back to RFC3168 conformance, leaving a state that is fully > > >>> compatible with SCE, hence they are compatible. > > >> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN? > > > RFC-8511 doesn't change the signalling on the wire relative to RFC-3168. That was the sense intended here. > > > > > > - Jonathan Morton > > RFC3168 describes both endpoint behaviour and network functions. To me, > > this sentence is about > > how you receive indications of incipent congestion, the sender can > > change from using only CE to using CE plus > > the accurate information -or fall back to using just CE - ultimately it > > falls back to just detecting congestion (loss,delay). > > So yes, the CE signal could be regarded as input to SCE. > > > > The endpoint behaviour, I think, should fall back to RFC8511. > > The response to CE of an SCE capable end-point is unaltered by > the fact that SCE is in use. If RFC8511 is enabled on the > end node the response shall be that of the ABE parameters, if > RC8511 is not enabled then the response should be that of RFC3168. > > IE, the 2 experiments co-exist without any special considerations, > and SCE plays nicely with either response to CE. > > Explicitly stating in this draft that behavior should fall-back > to RFC8511 would complicate implementation details as then an > implementor may be required to implement RFC8511 if it did not > exist, and also to some how "know" that a connection was SCE > capable, somethng a sender is unaware of until the first ESCE > mark is recieved, and something that can change as paths over > the internet change during the life of the connection. > > Further more stating RFC8511 as a fallback position would more > or less mandate that RFC8511 be used if SCE is used, something > that may not be desireable. I agree with Rod here. > > In summary. tcpsce does not alter CE generation, feedback or > response, leaving all existing RFC's intact as they are written > with respect to the CE and ECE bits. Tcpsce does not alter the > response to loss either. This is by design. > > > Gorry > -- > Rod Grimes rgrimes@freebsd.org > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Nov 4 21:29:48 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 8D20E120096; Mon, 4 Nov 2019 21:29:43 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ZV4OIin7; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=apYGfnHF 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 Aa9AnXAfwslq; Mon, 4 Nov 2019 21:29:40 -0800 (PST) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 BA06F120046; Mon, 4 Nov 2019 21:29:40 -0800 (PST) Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA55KJGt013913; Tue, 5 Nov 2019 00:29:30 -0500 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 : content-transfer-encoding : mime-version; s=smtpout1; bh=nkB488e1Kn9W/OxhWQT3Cs+vgyU4QlVXLI46jbKsp3k=; b=ZV4OIin7BLrNYfZLmxt6WUFYO3ogRS7ODyXVm3CVCHfuPaOVpEEw0v4GY8Rk7NaNE5LT yzb80jUeM3+zm4klzQ2JtSaBo9S+0kt+CW3hVk3nuFQO+EevdHG1yZ76Vdn1nmaZrOuS +JHk6AVTI22yIoF5/6F/rKnKMiHFnDJbtarjUuAJMX25arQ1u7Xr9EefoVDpJTUQf7eJ XPnaONRYzp1xuJ9TvM8cXKzbQ4+8Mtwp5QH6JyD6CRLX/FgFESKHyzyFbDpvuhYU6uQO mO3rkFLgNsH8FK7eT7rvss364Ds0xEnfLtojvgHU6o5CFClW1NuadJ67iG+Zb4+wiAmb Lg== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2w15mxu9hc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Nov 2019 00:29:30 -0500 Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA55RmRh089229; Tue, 5 Nov 2019 00:29:29 -0500 Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2054.outbound.protection.outlook.com [104.47.46.54]) by mx0a-00154901.pphosted.com with ESMTP id 2w14ee1j8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 05 Nov 2019 00:29:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a8TttT9lnzLm3JQhekH+nVsmL3J2Cws38ANiH74wEm+pGRBjoC6htJe2rmuvdCOgsyJsGPlCGFvNlMbE6pL4IogCtBqkxZg44KS/vKp0HZXhaMB+pejcHM5SynVEA5/MyEd9mhg3H2t5tQd2ICXtsWPhBxezzTfeFlebKaOACnxfSGnDoy9MN2zlQzXHUAXv9TmcRRxYcSEb5XWtUPC59ggwtD+DF45qThswWYieMEM7HUlTInaHOoMFbnJdVhd6Qm+vIbu72Wq/3XnbB7hFyBF0MfxDMhA8cbpa/xsLGbFFqazDHL9bAf/tSl0vtjOM56qqGmuedmIkVnRVe46lGQ== 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=nkB488e1Kn9W/OxhWQT3Cs+vgyU4QlVXLI46jbKsp3k=; b=ErdFizyqZMaM9RwOE7iF4FryWm9qHq6i5KnsVUSuQnqFL7BbiwZ1IhR0Wy1wXGfWY4y++Re9o+9HJpULiorQ5n2be0iPKfIah3OnQJ8RYex4X/Qn932E2dXAtBZ4vjMXQvmL+1PVeZ8/EZ0EfmPWHshuBNHqsclwUYivYxxSWrkWlXhrCTB3iDLuJq3hAeV6hjkZsFFnlEKPH6GCAXnk2pO9YQ8dsieYY58t0WaJmZECymXrXlpuEMZW5i7Jk7ClgNhTDYcYszDYGTw6dgoeugXtiDtbSCfmDcBhHlxdOQXSItMjLGH4GlZOG8HPEYUGRu2KecwZx30d1ueh5/zQRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector2-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nkB488e1Kn9W/OxhWQT3Cs+vgyU4QlVXLI46jbKsp3k=; b=apYGfnHFg1nTKE6jFNcfnHZy7GQCbQqLIl4c03QObRARvbR0CR/op2GP4126fCPRaYQ9vdOzl0yF2n2R34RCErRM0GKS6GpH96ANzYuNmsGVn2ow8Jb225uoa9N8F29+BI9W72IdVTUZIeGM2w/j89Yxh/Hgdrmnv2dvFAw7800= Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3247.namprd19.prod.outlook.com (20.179.149.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 05:29:28 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019 05:29:28 +0000 From: "Black, David" To: Loganaden Velvindron , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: "gorry@erg.abdn.ac.uk" , "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" , "Black, David" Thread-Topic: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt Thread-Index: AQHVk5Nf68SHYnnnQEWcyP/pIXUm8qd8Cxbg Date: Tue, 5 Nov 2019 05:29:28 +0000 Message-ID: References: <5DBFDF26.5080101@erg.abdn.ac.uk> <201911041658.xA4GwckY001605@gndrsh.dnsmgr.net> In-Reply-To: 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-11-05T05:29:26.3784065Z; 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: [107.1.229.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 888098d9-1fac-45a0-0647-08d761b120d6 x-ms-traffictypediagnostic: MN2PR19MB3247: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(136003)(366004)(13464003)(199004)(189003)(7502003)(6506007)(110136005)(966005)(52536014)(9686003)(6306002)(66446008)(107886003)(4326008)(71200400001)(86362001)(71190400001)(6246003)(64756008)(66556008)(66476007)(76116006)(66946007)(54906003)(6436002)(478600001)(256004)(14444005)(66574012)(55016002)(66066001)(2906002)(15650500001)(476003)(305945005)(25786009)(74316002)(186003)(7696005)(76176011)(786003)(316002)(81166006)(81156014)(99286004)(486006)(33656002)(11346002)(14454004)(446003)(7736002)(229853002)(3846002)(5660300002)(6116002)(53546011)(102836004)(8936002)(8676002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3247; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pK7ODOz0zboV84EsnnXgHGxLu2UsnxDunDHkdWbx38AciVZs4W42shbD+jMZEY5izpblT5NF29p/P7juC2BMV/GTWI8dlaKia/4gbYtaEn0cJyeRuz/Qu2cpFTcM3fOkve4t2S/9bNzOThXB34afeHNaVqTCjSmxX/i5p+58/ey21q8hmAt0Aw1DC85mUeyb1YgCbBMYpfw7Kbuzeqi8BIyYLUZgPFfjQ3dl6d0PetnGZMvQ3rkdiGWQPW+XyzI0am2n+e2NgtzKKG2uwkQOO5au6V5C/GnTWUjfShZICNXV3MQlQ3QBIk1YCdQvzGD8hvPpP93oYKe8isiMQIlQGIWsPl91jDMd70b2SAT9pQongb+fSWqgECi7VlBv/eswUv9wuVztS/ZWCpaxaWrXUhubv4BDAWhVw8MAmfIO6hztBcr0lVLbLsYTqeHZIcsXvpub56L5qzblDPGTdTG0vUZwF/My1259P2ydYtSp4eE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 888098d9-1fac-45a0-0647-08d761b120d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 05:29:28.2455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wdKiVCASo65VKGUuR4aD1BgY8YtaouaJFdOvjSmaS3fKIFpOk/wIdEmpMv8ppRjbBA6C4ThCBRU2mFtKJxsxSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3247 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-05_01:2019-11-04,2019-11-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1911050042 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0 clxscore=1015 priorityscore=1501 mlxscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1911050041 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.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: Tue, 05 Nov 2019 05:29:45 -0000 VGhpcyBhcHBlYXJzIHRvIGJlIGEgdGVtcGVzdCBpbiBhIHRlYXBvdCwgYXMgSSBzZWUgdGhlIGZv bGxvd2luZyB0ZXh0IGluIFNlY3Rpb24gNSAoVENQIFNlbmRlcikgb2YgdGhlIC0wMSB2ZXJzaW9u IG9mIHRoaXMgZHJhZnQ6DQoNCiAgIFRoZXJlIGFyZSBubyBjaGFuZ2VzIHRvIHRoZSByZXNwb25z ZSBmdW5jdGlvbnMgd2l0aCByZXNwZWN0IHRvIENFIG9yDQogICBwYWNrZXQgbG9zcyBzcGVjaWZp Y2VkIGJ5IHRoaXMgZHJhZnQsIGhlbmNlIFtSRkMzMTY4XSBhbmQgW1JGQzg1MTFdDQogICBhcmUg c3RpbGwgYXBwbGljYWJsZQ0KDQpUaGUgbmV1dHJhbCAic3RpbGwgYXBwbGljYWJsZSIgbGFuZ3Vh Z2UgbmljZWx5IHNpZGVzdGVwcyB0aGUgRXhwZXJpbWVudGFsIHN0YXR1cyBvZiBSRkMgODUxMSAt IGluIHBhcnRpY3VsYXIsIGlmIFJGQyA4NTExIGlzIHJlcGxhY2VkIGJ5IGEgc3RhbmRhcmRzLXRy YWNrIFJGQyBpbiB0aGUgZnV0dXJlLCB0aGUgYWJvdmUgbGFuZ3VhZ2UgaGFzIHRoZSBkZXNpcmVk IGVmZmVjdCwgd2hlcmVhcyBsYW5ndWFnZSB0aGF0IGV4cGxpY2l0bHkgcmVmZXJyZWQgdG8gdGhl IEV4cGVyaW1lbnRhbCBzdGF0dXMgb2YgUkZDIDg1MTEgY291bGQgYmUgcHJvYmxlbWF0aWMgaW4g dGhhdCBzY2VuYXJpby4NCg0KVGhhbmtzLCAtLURhdmlkIChhcyBhbiBpbmRpdmlkdWFsLCBub3Qg YXMgYSBUU1ZXRyBjaGFpcikNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiB0c3Z3ZyA8dHN2d2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExvZ2FuYWRlbiBW ZWx2aW5kcm9uDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgNCwgMjAxOSAxMTo0MSBQTQ0KPiBU bzogUm9kbmV5IFcuIEdyaW1lcw0KPiBDYzogZ29ycnlAZXJnLmFiZG4uYWMudWs7IFJvZG5leSBX LiBHcmltZXM7IHRjcG1AaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb dHN2d2ddIFt0Y3BtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWdyaW1lcy10 Y3BtLQ0KPiB0Y3BzY2UtMDAudHh0DQo+IA0KPiANCj4gW0VYVEVSTkFMIEVNQUlMXQ0KPiANCj4g T24gTW9uLCBOb3YgNCwgMjAxOSBhdCA4OjU5IFBNIFJvZG5leSBXLiBHcmltZXMNCj4gPDRib25l QGduZHJzaC5kbnNtZ3IubmV0PiB3cm90ZToNCj4gPg0KPiA+ID4gT24gMDMvMTEvMjAxOSwgMTM6 MDgsIEpvbmF0aGFuIE1vcnRvbiB3cm90ZToNCj4gPiA+ID4+IE9uIDMgTm92LCAyMDE5LCBhdCAx MTo0NiBhbSwgR29ycnkgRmFpcmh1cnN0PGdvcnJ5QGVyZy5hYmRuLmFjLnVrPg0KPiB3cm90ZToN Cj4gPiA+ID4+DQo+ID4gPiA+Pj4gV2l0aCByZXNwZWN0IHRvIGRyYWZ0LWlldGYtdGNwbS1hY2N1 cmF0ZS1lY24gYW5kDQo+ID4gPiA+Pj4gZHJhZnQtZ3JpbWVzLXRjcG0tdGNwc2NlIGNvbXBhdGli aWxpdHk6DQo+ID4gPiA+Pj4gICAgV2hlbiBhY2N1cmF0ZSBlY24gKEFjY0VDTikgZmFpbHMgdG8g bmVnb3RpYXRlIGFuIEFjY0VDTiBjYXBhYmxlDQo+IHNlc3Npb24NCj4gPiA+ID4+PiAgICBpdCBm YWxscyBiYWNrIHRvIFJGQzMxNjggY29uZm9ybWFuY2UsIGxlYXZpbmcgYSBzdGF0ZSB0aGF0IGlz IGZ1bGx5DQo+ID4gPiA+Pj4gICAgY29tcGF0aWJsZSB3aXRoIFNDRSwgaGVuY2UgdGhleSBhcmUg Y29tcGF0aWJsZS4NCj4gPiA+ID4+IEkgd2FzIGV4cGVjdGluZyB0aGlzIHRvIGZhbGwtYmFjayB0 byBSRkM4NTExLCB0cmVhdG1lbnQgYXQgdGhlIGVuZHBvaW50cnMsDQo+IHNpbmNlIHRoYXQgaXMg dGhlIG1vc3QgcmVjZW50IHNwZWMuIERvZXMgdGhhdCBtYWtlIGFueSBkaWZmZXJlbmNlIHRvIHlv dXINCj4gdGhvdWdodHMgYWJpb3V0IHdoYXQgeW91IGV4cGVjdCBhbiBlbmRwb2ludCB0byBkbyB3 aGVuIGl0IHJlY2VpdmVzIEVDTi0NCj4gbWFya2luZyB3aXRob3V0IEFjY3VyYXRlIEVDTj8NCj4g PiA+ID4gUkZDLTg1MTEgZG9lc24ndCBjaGFuZ2UgdGhlIHNpZ25hbGxpbmcgb24gdGhlIHdpcmUg cmVsYXRpdmUgdG8gUkZDLTMxNjguDQo+IFRoYXQgd2FzIHRoZSBzZW5zZSBpbnRlbmRlZCBoZXJl Lg0KPiA+ID4gPg0KPiA+ID4gPiAgIC0gSm9uYXRoYW4gTW9ydG9uDQo+ID4gPiBSRkMzMTY4IGRl c2NyaWJlcyBib3RoIGVuZHBvaW50IGJlaGF2aW91ciBhbmQgbmV0d29yayBmdW5jdGlvbnMuIFRv IG1lLA0KPiA+ID4gdGhpcyBzZW50ZW5jZSBpcyBhYm91dA0KPiA+ID4gaG93IHlvdSByZWNlaXZl IGluZGljYXRpb25zIG9mIGluY2lwZW50IGNvbmdlc3Rpb24sIHRoZSBzZW5kZXIgY2FuDQo+ID4g PiBjaGFuZ2UgZnJvbSB1c2luZyBvbmx5IENFIHRvIHVzaW5nIENFIHBsdXMNCj4gPiA+IHRoZSBh Y2N1cmF0ZSBpbmZvcm1hdGlvbiAtb3IgZmFsbCBiYWNrIHRvIHVzaW5nIGp1c3QgQ0UgLSB1bHRp bWF0ZWx5IGl0DQo+ID4gPiBmYWxscyBiYWNrIHRvIGp1c3QgZGV0ZWN0aW5nIGNvbmdlc3Rpb24g KGxvc3MsZGVsYXkpLg0KPiA+ID4gU28geWVzLCB0aGUgQ0Ugc2lnbmFsIGNvdWxkIGJlIHJlZ2Fy ZGVkIGFzIGlucHV0IHRvIFNDRS4NCj4gPiA+DQo+ID4gPiBUaGUgZW5kcG9pbnQgYmVoYXZpb3Vy LCBJIHRoaW5rLCBzaG91bGQgZmFsbCBiYWNrIHRvIFJGQzg1MTEuDQo+ID4NCj4gPiBUaGUgcmVz cG9uc2UgdG8gQ0Ugb2YgYW4gU0NFIGNhcGFibGUgZW5kLXBvaW50IGlzIHVuYWx0ZXJlZCBieQ0K PiA+IHRoZSBmYWN0IHRoYXQgU0NFIGlzIGluIHVzZS4gIElmIFJGQzg1MTEgaXMgZW5hYmxlZCBv biB0aGUNCj4gPiBlbmQgbm9kZSB0aGUgcmVzcG9uc2Ugc2hhbGwgYmUgdGhhdCBvZiB0aGUgQUJF IHBhcmFtZXRlcnMsIGlmDQo+ID4gUkM4NTExIGlzIG5vdCBlbmFibGVkIHRoZW4gdGhlIHJlc3Bv bnNlIHNob3VsZCBiZSB0aGF0IG9mIFJGQzMxNjguDQo+ID4NCj4gPiBJRSwgdGhlIDIgZXhwZXJp bWVudHMgY28tZXhpc3Qgd2l0aG91dCBhbnkgc3BlY2lhbCBjb25zaWRlcmF0aW9ucywNCj4gPiBh bmQgU0NFIHBsYXlzIG5pY2VseSB3aXRoIGVpdGhlciByZXNwb25zZSB0byBDRS4NCj4gPg0KPiA+ IEV4cGxpY2l0bHkgc3RhdGluZyBpbiB0aGlzIGRyYWZ0IHRoYXQgYmVoYXZpb3Igc2hvdWxkIGZh bGwtYmFjaw0KPiA+IHRvIFJGQzg1MTEgd291bGQgY29tcGxpY2F0ZSBpbXBsZW1lbnRhdGlvbiBk ZXRhaWxzIGFzIHRoZW4gYW4NCj4gPiBpbXBsZW1lbnRvciBtYXkgYmUgcmVxdWlyZWQgdG8gaW1w bGVtZW50IFJGQzg1MTEgaWYgaXQgZGlkIG5vdA0KPiA+IGV4aXN0LCBhbmQgYWxzbyB0byBzb21l IGhvdyAia25vdyIgdGhhdCBhIGNvbm5lY3Rpb24gd2FzIFNDRQ0KPiA+IGNhcGFibGUsIHNvbWV0 aG5nIGEgc2VuZGVyIGlzIHVuYXdhcmUgb2YgdW50aWwgdGhlIGZpcnN0IEVTQ0UNCj4gPiBtYXJr IGlzIHJlY2lldmVkLCBhbmQgc29tZXRoaW5nIHRoYXQgY2FuIGNoYW5nZSBhcyBwYXRocyBvdmVy DQo+ID4gdGhlIGludGVybmV0IGNoYW5nZSBkdXJpbmcgdGhlIGxpZmUgb2YgdGhlIGNvbm5lY3Rp b24uDQo+ID4NCj4gPiBGdXJ0aGVyIG1vcmUgc3RhdGluZyBSRkM4NTExIGFzIGEgZmFsbGJhY2sg cG9zaXRpb24gd291bGQgbW9yZQ0KPiA+IG9yIGxlc3MgbWFuZGF0ZSB0aGF0IFJGQzg1MTEgYmUg dXNlZCBpZiBTQ0UgaXMgdXNlZCwgc29tZXRoaW5nDQo+ID4gdGhhdCBtYXkgbm90IGJlIGRlc2ly ZWFibGUuDQo+IA0KPiBJIGFncmVlIHdpdGggUm9kIGhlcmUuDQo+ID4NCj4gPiBJbiBzdW1tYXJ5 LiAgdGNwc2NlIGRvZXMgbm90IGFsdGVyIENFIGdlbmVyYXRpb24sIGZlZWRiYWNrIG9yDQo+ID4g cmVzcG9uc2UsIGxlYXZpbmcgYWxsIGV4aXN0aW5nIFJGQydzIGludGFjdCBhcyB0aGV5IGFyZSB3 cml0dGVuDQo+ID4gd2l0aCByZXNwZWN0IHRvIHRoZSBDRSBhbmQgRUNFIGJpdHMuICBUY3BzY2Ug ZG9lcyBub3QgYWx0ZXIgdGhlDQo+ID4gcmVzcG9uc2UgdG8gbG9zcyBlaXRoZXIuICBUaGlzIGlz IGJ5IGRlc2lnbi4NCj4gPg0KPiA+ID4gR29ycnkNCj4gPiAtLQ0KPiA+IFJvZCBHcmltZXMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdyaW1lc0BmcmVl YnNkLm9yZw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0K From nobody Mon Nov 4 23:48:07 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 8E68C120096; Mon, 4 Nov 2019 23:48:01 -0800 (PST) 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 4F2OZd-_KAha; Mon, 4 Nov 2019 23:47:58 -0800 (PST) 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 40FD312007C; Mon, 4 Nov 2019 23:47:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9FB8125A2A; Tue, 5 Nov 2019 08:47:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572940076; bh=7/Fj6GeEhYwshOjQhxyIg6vZnU1+eTPB8t2iApkirB4=; h=From:To:Subject:Date:References:In-Reply-To:From; b=gtf3jo/yIxRfmN13fkPR0w9SXsMD0q8nog/0vpyZEvnJMInIMgUKzG5utyHKYoXkz 8ljlt90qBoxZtFoCAdRUBQAMxikHopYhmASoSuOD0V9yS2MW5Y8iWOH7UMhBY+a18X s20jBn7lmnF1A/3qdUYtTfMkS70FS4qfjG8/2R98= 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 6SjdD3KeXsTm; Tue, 5 Nov 2019 08:47:55 +0100 (CET) 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; Tue, 5 Nov 2019 08:47:55 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 5 Nov 2019 08:47:54 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] [tcpm] L4S status tracking Thread-Index: AQHVk0UvfVwSTp/X5UyllWUfYXnYp6d8MhVA Date: Tue, 5 Nov 2019 07:47:54 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4E1627@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de>, <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@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.63.69] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4E1627rznt8114rzntrzd_" 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: Tue, 05 Nov 2019 07:48:02 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E1627rznt8114rzntrzd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just parse the abstract of draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an i= ncremental migration path so that existing 'Classic' TCP traffic will be no= worse off" This wording does not work for me, as explained already. I disagree to movi= ng forward with this terminology. Thanks Michael From: tsvwg On Behalf Of Scharf, Michael Sent: Monday, November 4, 2019 8:22 PM To: Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> Cc: tcpm@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] [tcpm] L4S status tracking I agree. "non-L4S" may be even better. Michael Von: Rodney W. Grimes Gesendet: Montag, 4. November 2019 20:17 An: Scharf, Michael Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org Betreff: Re: [tcpm] [tsvwg] L4S status tracking > You can e.g. use ?non-L4S-enabled TCP?. > > Terminology does matter to me given that I strongly disagree to any use o= f ?marketing language? when it comes to TCP. My concern here of use of terms like, legacy, classic, new, old is that they are pretty much all of the relative from and thus ambiguous over time. newReno is new only relative to Reno, that is fairly clear, but if I said newTCP or oldTCP with what frame should the reference be evaluated. I believe in the case of L4S the time invariant term would be, as Michael suggests above, "non-L4S". Note that enabled for me is a noise word in this context, and TCP may or may not be needed depending on context, but for literal replacement of Legacy or Classic "non-L4S" is invariant over time. Rod > Michael > > > Von: Bob Briscoe > Gesendet: Montag, 4. November 2019 19:09 > An: Scharf, Michael; Wesley Eddy; tsvwg@ietf..org > Cc: tcpm@ietf.org> > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > Michael, > > Previously, I have been told not to use the term standard for RFCs that a= re not standards. RFC5681 is 'only' a draft standard. This is why, in the I= ETF at least, I avoid using the term "standard TCP congestion control". I g= enerally call it Reno when referring to the congestion control. > > I have never, to my knowledge, used the term classic TCP, or classic TCP = congestion control. > > And I rarely use the term legacy, and if I do I'm happy to have alternati= ves suggested. > > I've checked the L4S drafts, and there is one phrase that I shall leave i= n ecn-l4s-id: "the traditional TCP Reno additive increase", because this is= correctly used to mean the traditional increase (in numerous AIMD CCs), no= t traditional TCP. There was one other occurrence of "traditional TCP sende= rs" in a whole para in an appendix that has just been deleted anyway. And i= n aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic t= raffic" now in my local copy, using the defined term in all the L4S drafts)= . > > l4s-arch is getting a complete make-over for terminology, so I will check= that next. > > inline... > > > On 23/08/2019 15:01, Scharf, Michael wrote: > > Hi Wes, > > > > I?d 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-h= DvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?classic = TCP? or ?legacy? TCP when referring to a TCP implementation according to IE= TF standards-track RFCs. > > > > To me as a non-native native speaker, all these terms have a negative con= notation. I also think this language is typical to marketing material. > > You're entitled to your opinion but, as a native speaker, I don't think '= classic' or 'traditional' are particularly pejorative, tho they can be when= used in a context that intends them to be. They also mean "stood the test = of time". I find 'legacy' has a connotation of marketing-speak, but it's no= t that bad. > > This is an enduring problem when trying to improve on the good work that = other people have done before you (which is the context of everything we ar= e doing). We need a word that distinguishes the old from the new, but we do= n't want to completely trash the thing that has already been successful, bu= t had its day. > > Nonetheless, it is also important not to be too precious about past work.= We all recognize that Reno TCP is unscalable and has problems. IMO, it is = OK to describe technologies that have had their time with negative connotat= ions. Indeed, you have been an author (with me) of an RFC on open issues in= congestion control. > > I notice you haven't suggested an alternative term for "the thing(s) we a= re trying to improve on". Not surprising, because it's difficult. > > When we (the L4S developers) were first looking for a term for the non-L4= S queue and the non-L4S service, we didn't want to use 'legacy' for the abo= ve reasons, but we did want to imply pre-existing, so we decided on 'classi= c', which we all felt had a generally neutral connotation, but said what we= meant. > > Finally, I do not want this issue to take up any time that would detract = from technical issues. > > > > Bob > > > > > My prefered term when referring to TCP according to standards-track speci= fication is ?standard TCP?. I would also be fine with other terms as long a= s they are neutral and make clear that experiments do not replace, deprecat= e, or outperform standards. > > > > Similarly, I think that term such as ?classic? is not appropriate for the= TCP standard congestion control (?Reno?). As of today, this is the TCP con= gestion control algorithm on standards track that has IETF consensus. The t= erm 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?, ?lega= cy AQM? or the like, i.e., if the context is ECN and not specifically TCP o= r 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 opinio= n on that. As far as I can see, most use of the term ?classic? is in this c= ontext and I don?t ask for changes in those cases. > > > > Some use of the term ?Classic Service? may also require careful review to= clearly 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 s= peaker, it would be really strange to use the term ?classic? in the context= of a brand-new transport protocol. IMHO in that case the term ?classic? wo= uld 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. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.= org --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E1627rznt8114rzntrzd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just parse the abstract of draft-ietf-tsvwg-ecn-l4s-id-08: “It= gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off“

 

This wording does not work for me, as explained already. I disagree to= moving forward with this terminology.

 

Thanks

 

Michael

 

 

From: tsvwg <tsvwg-bounces@ietf.o= rg> On Behalf Of Scharf, Michael
Sent: Monday, November 4, 2019 8:22 PM
To: Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] [tcpm] L4S status tracking

 

I agree. „non-L4S“ may be even better.<= o:p>

 

Michael

 =

 

Von: Rodney W. Grimes
Gesendet: Montag, 4. November 2019 20:17
An: Scharf, Michae= l
Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

 

> You can e.g. u= se ?non-L4S-enabled TCP?.
>
> Terminology does matter to me given that I strongly disagree to any us= e of ?marketing language? when it comes to TCP.

My concern here of use of terms like, legacy, classic, new, old
is that they are pretty much all of the relative from and thus
ambiguous over time.

newReno is new only relative to Reno, that is fairly clear,
but if I said newTCP or oldTCP with what frame should the
reference be evaluated.

I believe in the case of L4S the time invariant term would be,
as Michael suggests above, "non-L4S".   Note that enabl= ed
for me is a noise word in this context, and TCP may or may
not be needed depending on context, but for literal replacement
of Legacy or Classic "non-L4S" is invariant over time.

Rod

> Michael
>
>
> Von: Bob Briscoe<mailto:ietf= @bobbriscoe.net>
> Gesendet: Montag, 4. November 2019 19:09
> An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley Eddy<mailto:wes@mti-systems.com>; tsvwg@ietf= ..org<mailto:tsvwg@ietf.org> > Cc: tcpm@ietf.org<mailto:tcpm@ietf= ..org>
> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael,
>
> Previously, I have been told not to use the term standard for RFCs tha= t are not standards. RFC5681 is 'only' a draft standard. This is why, in th= e IETF at least, I avoid using the term "standard TCP congestion contr= ol". I generally call it Reno when referring to the congestion control.
>
> I have never, to my knowledge, used the term classic TCP, or classic T= CP congestion control.
>
> And I rarely use the term legacy, and if I do I'm happy to have altern= atives suggested.
>
> I've checked the L4S drafts, and there is one phrase that I shall leav= e in ecn-l4s-id: "the traditional TCP Reno additive increase", be= cause this is correctly used to mean the traditional increase (in numerous = AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in= an appendix that has just been deleted anyway. And in aqm-dualq-coupled th= ere was one "legacy TCP flows" (changed to "Classic traffic&= quot; now in my local copy, using the defined term in all the L4S drafts).
>
> l4s-arch is getting a complete make-over for terminology, so I will ch= eck that next.
>
> inline...
>
>
> On 23/08/2019 15:01, Scharf, Michael wrote:
>
> Hi Wes,
>
>
>
> I?d like to add a smaller item that is mostly editorial and can hopefu= lly be sorted just out by re-wording, albeit it may require a careful analy= sis of all documents.
>
>
>
> As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<= https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?classic TCP? or ?= legacy? TCP when referring to a TCP implementation according to IETF standards-track RFCs.
>
>
>
> To me as a non-native native speaker, all these terms have a negative = connotation. I also think this language is typical to marketing material. >
> You're entitled to your opinion but, as a native speaker, I don't thin= k 'classic' or 'traditional' are particularly pejorative, tho they can be w= hen used in a context that intends them to be. They also mean "stood t= he test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad.
>
> This is an enduring problem when trying to improve on the good work th= at other people have done before you (which is the context of everything we= are doing). We need a word that distinguishes the old from the new, but we= don't want to completely trash the thing that has already been successful, but had its day.
>
> Nonetheless, it is also important not to be too precious about past wo= rk. We all recognize that Reno TCP is unscalable and has problems. IMO, it = is OK to describe technologies that have had their time with negative conno= tations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control.
>
> I notice you haven't suggested an alternative term for "the thing= (s) we are trying to improve on". Not surprising, because it's difficu= lt.
>
> When we (the L4S developers) were first looking for a term for the non= -L4S queue and the non-L4S service, we didn't want to use 'legacy' for the = above reasons, but we did want to imply pre-existing, so we decided on 'cla= ssic', which we all felt had a generally neutral connotation, but said what we meant.
>
> Finally, I do not want this issue to take up any time that would detra= ct from technical issues.
>
>
>
> Bob
>
>
>
>
> My prefered term when referring to TCP according to standards-track sp= ecification is ?standard TCP?. I would also be fine with other terms as lon= g as they are neutral and make clear that experiments do not replace, depre= cate, or outperform standards.
>
>
>
> Similarly, I think that term such as ?classic? is not appropriate for = the TCP standard congestion control (?Reno?). As of today, this is the TCP = congestion control algorithm on standards track that has IETF consensus. Th= e term in the TCPM charter is ?TCP standard congestion control?. I also think that terms such as ?Reno-compat= ible? or the like would be neutral.
>
>
>
> Note that I do not object to the terms ?classic ECN?, ?legacy ECN?, ?l= egacy AQM? or the like, i.e., if the context is ECN and not specifically TC= P 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 u= se of the term ?classic? is in this context and I don?t ask for changes in = those cases.
>
>
>
> Some use of the term ?Classic Service? may also require careful review= to clearly 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-nativ= e speaker, it would be really strange to use the term ?classic? in the cont= ext of a brand-new transport protocol. IMHO in that case the term ?classic? would be even more confusing.
>
>
>
> I also add the TCPM list in CC to ensure consistency.
>
>
>
> Thanks
>
>
>
> Michael (with no hat)
>
>
>
>
>
> Von: Wesley Eddy<mailto:wes@= mti-systems.com>
> Gesendet: Sonntag, 11. August 2019 07:08
> An: tsvwg@ietf.org<mailto:tsvwg@i= etf.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=3Dtic= ket&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 ticke= t
> numbers or some key words in threads and messages, when significant. >
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org<mailto:tcpm@ietf.org= >
> https://www.iet= f.org/mailman/listinfo/tcpm
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe          = ;            &n= bsp;        http://bobbriscoe.net/

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

--
Rod Grimes           = ;            &n= bsp;            = ;             <= a href=3D"mailto:rgrimes@freebsd.org"> rgrimes@freebsd.org

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E1627rznt8114rzntrzd_-- From nobody Tue Nov 5 01:20: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 83B3312085F; Tue, 5 Nov 2019 01:20:47 -0800 (PST) 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 Cutel_8oh-1s; Tue, 5 Nov 2019 01:20:44 -0800 (PST) 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 1ABF712085E; Tue, 5 Nov 2019 01:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572945619; bh=zbkdDpqYsn5P55dD/n0UrZx+IRbzso67IUhx7cSHj9s=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=J2VPpGlhIH+v2BRuqiz4CtA4aT96Bj+4ynKPnvuCglDqs2mmDWqlzI4xBBi0O/ui4 0BXGV0CL2xuMQQfypbqxitwHamRguS++/7rIbxoNj8y8vlUrvmSolhfjb/jS5eHkV/ R+KOMardA3sd+73Jbb7PgZIsgNkHnM/dOEBKnvoo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MuUjC-1hbsZ23KR0-00rXWK; Tue, 05 Nov 2019 10:14:38 +0100 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: <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Tue, 5 Nov 2019 10:14:37 +0100 Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <00F3EB28-F841-4FA2-8E95-89866404402B@gmx.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:mLRGUBTcOipjN78RkEQJ7Uh0XYr1DGY5HYu2nurYR0cpcX3NcGa GcF9cTs7BUgWoKedjk6Xeb3GvKn92CFoaNSFhOWxWsDdI5n8qyJUh3KQJMwGodgaZlmtG1R 5vaWIHcivSxPyn+UlVUWJP6h6YEs3BbUTQ6S6nX3VMm6hq/FcQ1nkhQq8o9MjAX/gnH+dRS ZSLMVqgH70AMsukN8Smdg== X-UI-Out-Filterresults: notjunk:1;V03:K0:5GF0nGoOjlE=:6Xmrzz+awR7Aevep5usGMe TSmBs7jP2rQZNNUU77HMwMD9W5p2wA8BmCtwGugO8LCtwKlchPe03TXkmHkkb6WStf22jK51h SBJ+x3nXntwMziGLrPZN/4nh1Co1DtuHXffV6RSwys1/peHktsBDJo9/MQWu3WOieEOt8xaF0 XC7Y/3Bk7omPWNxXxPIEbX4RjW8WcsS64ZIpxNAeL/Qhihvc+BzVJHlaWNplIZ8txLYamDygx BaIEf+vTmTKVin30SgNTZ2OXCZWct4Jn3CBi9jEkPdbae2bxO4YTtW1bxMQ4q+JwdFOGZ/aK6 UYErDc4TepDfZztR5SHJMhXkIBvTfLJ4sLFhXbLqUygc3SA+lroYiyiqoB9c8am5f9aO7071Y AGDSvPYl3jBocHjLCEHGVkReyNaYqZeshHkxzNeK8JxjKbRXweywLA8wPyRsxS+01ZMC4TStH ZNmupm8xNDTEqyHzOcd6TclmkLpyohYYjCM05mmmC9Mjx2lzTPFCzKxMuAWqEOx/Ny79WjyXi nB7QT/P0I1StV8a+GXThhyzqV+dvvPXcPnzKaZGSKmPFGYGQVrzs+P0OCaFx98kRq/DGmE1zU LGSE+4XXcgdZqBeDgGne0wZOLDsA/JxG7y5rM823x7kmNyXH2QA+K1TtBR3qwq+T338zfcX5t 3vFNX3WsOmklwSUVAQDNSUMLGaOeqmfrj+31/SPyMilILsw+mXRVIcuuOpTSRIqbQaOON7pJt gxjWmJkS0b2of9hGddfZxFj4QtcBR3UjjPUzP2rGySVOC2v5IYH0LFif7RE4s7TEcPYiGeu/H NC+bgV8VAwF3Ldxv1BDNRwSn8+XguJiwTZze3SjOfTi4If9SBKyLtgKToJv6KCcCSPiQNIuTg +0y/u8vLltJOrUGvlAPGCEMJhJZJjOXtL1/tT9WrNYk5WEulea+7emcdJOtr3vtu/Y0ohgaRw atfrhV+Z+ptP3zAQyWekJdx95aCe8eXlhTr087rjTOSNFirebG/ZcfVMyFkNOk5cstuEZ5D/y M579DJ4KlRc1peQxBdslP+kYeb/PqyUQn3XI8VoksElIdX8sUfComLAJVU3w3zkOKF5xQC67J bZdBrrqhFpRK8dYmNOskniDxOPkLmpf/whnTeST+7erABIgtuz/yWcHJsG/D9erb/NOifqcsW qqtSrTkSZmMlP7l0qQLpHnD92ZaJG77LXKaDuXnFwe/EwMAswJ9EDDhRzEHiVQoIRdnGOF9RL LanRjkhTJcT2oK1lVypKqvCaUB1dhLC/1LeL/inCwQVlu4yS3mgdhHXoQqpo= 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: Tue, 05 Nov 2019 09:20:48 -0000 Hi Michael, > On Nov 4, 2019, at 20:21, Scharf, Michael = wrote: >=20 > I agree. =E2=80=9Enon-L4S=E2=80=9C may be even better. [SM] except that L4S, which expands to "Low Latency, Low Loss, = Scalable Throughput" (so it arguably should be LLLLST or L4ST) arguably that is also "marketing language", no? Sebastian > =20 > Michael > =20 > =20 > Von: Rodney W. Grimes > Gesendet: Montag, 4. November 2019 20:17 > An: Scharf, Michael > Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > =20 > > You can e.g. use ?non-L4S-enabled TCP?. > >=20 > > Terminology does matter to me given that I strongly disagree to any = use of ?marketing language? when it comes to TCP. >=20 > My concern here of use of terms like, legacy, classic, new, old > is that they are pretty much all of the relative from and thus > ambiguous over time. >=20 > newReno is new only relative to Reno, that is fairly clear, > but if I said newTCP or oldTCP with what frame should the > reference be evaluated. >=20 > I believe in the case of L4S the time invariant term would be, > as Michael suggests above, "non-L4S". Note that enabled > for me is a noise word in this context, and TCP may or may > not be needed depending on context, but for literal replacement > of Legacy or Classic "non-L4S" is invariant over time. >=20 > Rod >=20 > > Michael > >=20 > >=20 > > Von: Bob Briscoe > > Gesendet: Montag, 4. November 2019 19:09 > > An: Scharf, Michael; Wesley = Eddy; tsvwg@ietf..org > > Cc: tcpm@ietf.org > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > >=20 > > Michael, > >=20 > > Previously, I have been told not to use the term standard for RFCs = that are not standards. RFC5681 is 'only' a draft standard. This is why, = in the IETF at least, I avoid using the term "standard TCP congestion = control". I generally call it Reno when referring to the congestion = control. > >=20 > > I have never, to my knowledge, used the term classic TCP, or classic = TCP congestion control. > >=20 > > And I rarely use the term legacy, and if I do I'm happy to have = alternatives suggested. > >=20 > > I've checked the L4S drafts, and there is one phrase that I shall = leave in ecn-l4s-id: "the traditional TCP Reno additive increase", = because this is correctly used to mean the traditional increase (in = numerous AIMD CCs), not traditional TCP. There was one other occurrence = of "traditional TCP senders" in a whole para in an appendix that has = just been deleted anyway. And in aqm-dualq-coupled there was one "legacy = TCP flows" (changed to "Classic traffic" now in my local copy, using the = defined term in all the L4S drafts). > >=20 > > l4s-arch is getting a complete make-over for terminology, so I will = check that next. > >=20 > > inline... > >=20 > >=20 > > On 23/08/2019 15:01, Scharf, Michael wrote: > >=20 > > Hi Wes, > >=20 > >=20 > >=20 > > I?d 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. > >=20 > >=20 > >=20 > > As already noted in = https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY = , I object to the terms ?traditional TCP? and also ?classic TCP? or = ?legacy? TCP when referring to a TCP implementation according to IETF = standards-track RFCs. > >=20 > >=20 > >=20 > > To me as a non-native native speaker, all these terms have a = negative connotation. I also think this language is typical to marketing = material. > >=20 > > You're entitled to your opinion but, as a native speaker, I don't = think 'classic' or 'traditional' are particularly pejorative, tho they = can be when used in a context that intends them to be. They also mean = "stood the test of time". I find 'legacy' has a connotation of = marketing-speak, but it's not that bad. > >=20 > > This is an enduring problem when trying to improve on the good work = that other people have done before you (which is the context of = everything we are doing). We need a word that distinguishes the old from = the new, but we don't want to completely trash the thing that has = already been successful, but had its day. > >=20 > > Nonetheless, it is also important not to be too precious about past = work. We all recognize that Reno TCP is unscalable and has problems. = IMO, it is OK to describe technologies that have had their time with = negative connotations. Indeed, you have been an author (with me) of an = RFC on open issues in congestion control. > >=20 > > I notice you haven't suggested an alternative term for "the thing(s) = we are trying to improve on". Not surprising, because it's difficult. > >=20 > > When we (the L4S developers) were first looking for a term for the = non-L4S queue and the non-L4S service, we didn't want to use 'legacy' = for the above reasons, but we did want to imply pre-existing, so we = decided on 'classic', which we all felt had a generally neutral = connotation, but said what we meant. > >=20 > > Finally, I do not want this issue to take up any time that would = detract from technical issues. > >=20 > >=20 > >=20 > > Bob > >=20 > >=20 > >=20 > >=20 > > My prefered term when referring to TCP according to standards-track = specification 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. > >=20 > >=20 > >=20 > > Similarly, I think that term such as ?classic? is not appropriate = for the TCP standard congestion control (?Reno?). As of today, this is = the TCP congestion control 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. > >=20 > >=20 > >=20 > > 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 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 and I don?t ask for changes in = those cases. > >=20 > >=20 > >=20 > > Some use of the term ?Classic Service? may also require careful = review to clearly separate it from TCP Standard behavior. > >=20 > >=20 > >=20 > > 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 speaker, it would be really strange to use the term ?classic? = in the context of a brand-new transport protocol. IMHO in that case the = term ?classic? would be even more confusing. > >=20 > >=20 > >=20 > > I also add the TCPM list in CC to ensure consistency. > >=20 > >=20 > >=20 > > Thanks > >=20 > >=20 > >=20 > > Michael (with no hat) > >=20 > >=20 > >=20 > >=20 > >=20 > > Von: Wesley Eddy > > Gesendet: Sonntag, 11. August 2019 07:08 > > An: tsvwg@ietf.org > > Betreff: [tsvwg] L4S status tracking > >=20 > >=20 > >=20 > > 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: > >=20 > > https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&page=3D= 1 > >=20 > > 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. > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > >=20 > >=20 > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org From nobody Tue Nov 5 01:48: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 2FB3712086C; Tue, 5 Nov 2019 01:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 sCpEmAsIoOba; Tue, 5 Nov 2019 01:48:05 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 94FCC120869; Tue, 5 Nov 2019 01:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zFjyS4eEVmO9y8qelhLipOcnLcoBmA9xf+WdG8SKm58=; b=gXZ7Lykkw54aaTBduFLmFNqQ6j y8kfd0EPMqBM/1e+WqaPyku+VxLZ1EXQkrdwmdFHa01BB2JL+Qd0FvKTVWIJx5gQCZL1iEbeHMygg swCPLM5FV1iLSmDAtIQMPaqvQxDlun4rHnioGX5osUCCogPipcvt9DtjNVEhN+cXBOAsFr5so5mP7 QNkVHbRB3rHbzWYxy8I37mu4Q3K+a85s1tC3vSi3UfuYt2wNjanb42RygZBDoMDSIKo3l5hXYyYCR cbjcyuYcpNLCHJP2vkzinjHwYCxJZ3piLHNRutFF8VV99zi8eKzLvescBt7JroMndmlnCIhf2F2xM tLXyrL8w==; Received: from [31.185.128.31] (port=48216 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iRvRT-0002ro-1F; Tue, 05 Nov 2019 09:48:03 +0000 To: tsvwg IETF list , iccrg IRTF list , tcpm IETF list From: Bob Briscoe Message-ID: Date: Tue, 5 Nov 2019 09:48:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D256DA15BBBBD2D8C6BCD7A9" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] L4S Issue #16 Discussion Paper: Fall-back on Classic ECN AQM 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, 05 Nov 2019 09:48:07 -0000 This is a multi-part message in MIME format. --------------D256DA15BBBBD2D8C6BCD7A9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit tsvwg, iccrg and tcpm folks, I've published a discussion paper giving rationale and pseudocode for an algorithm we are implementing and evaluating in TCP Prague. TCP Prague Fall-back on Detection of a Classic ECN AQM I'd appreciate any immediate concerns with whether it looks feasible and/or any scenarios where you think it's likely not to work well. There's three main components: passive, active and base RTT adjustment. Only the first may be necessary, or possibly only the second. We'll publish evaluation results as soon as we have them. Apologies for not posting as an Internet Draft, but a) I find LaTeX quicker and more readable esp. for plots; b) many patent offices consider arXiv (but not Internet Drafts) as strong as journal publication For the avoidance of doubt, I have filed no IPR on this. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------D256DA15BBBBD2D8C6BCD7A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit tsvwg, iccrg and tcpm folks,

I've published a discussion paper giving rationale and pseudocode for an algorithm we are implementing and evaluating in TCP Prague.
    TCP Prague Fall-back on Detection of a Classic ECN AQM

I'd appreciate any immediate concerns with whether it looks feasible and/or any scenarios where you think it's likely not to work well.


There's three main components: passive, active and base RTT adjustment.
Only the first may be necessary, or possibly only the second.

We'll publish evaluation results as soon as we have them.

Apologies for not posting as an Internet Draft, but
a) I find LaTeX quicker and more readable esp. for plots;
b) many patent offices consider arXiv (but not Internet Drafts) as strong as journal publication

For the avoidance of doubt, I have filed no IPR on this.

Cheers



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------D256DA15BBBBD2D8C6BCD7A9-- From nobody Tue Nov 5 06:58:49 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 5771B1200B7; Tue, 5 Nov 2019 06:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 nub9cA31TMRr; Tue, 5 Nov 2019 06:58:42 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 2081D1200B4; Tue, 5 Nov 2019 06:58:42 -0800 (PST) Received: from 200116b82c014700a964b2bdeb9c5dad.dip.versatel-1u1.de ([2001:16b8:2c01:4700:a964:b2bd:eb9c:5dad]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iRzV4-000298-Jg; Tue, 05 Nov 2019 15:08:02 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D437955@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Tue, 5 Nov 2019 15:08:01 +0100 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-accurate-ecn@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8E7B2A65-6EED-458E-A98B-98B0550330BB@kuehlewind.net> References: <6EC6417807D9754DA64F3087E2E2E03E2D437955@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1572965922;6ec68d00; X-HE-SMSGID: 1iRzV4-000298-Jg Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-accurate-ecn-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: Tue, 05 Nov 2019 14:58:47 -0000 Hi Michael, Thanks for your feedback and an another review. Having considered it = carefully I believe your comment below are actually all editorial, even = inducing the first one (see below for further explanation). See proposed = changes here: https://github.com/bbriscoe/accecn/pull/1/files Please see below for replies! Thanks! Mirja > On 10. Sep 2019, at 12:51, Scharf, Michael = wrote: >=20 > Bob, Mirja, Richard, >=20 > I have read draft-ietf-tcpm-accurate-ecn (well, again). Please find = below my comments as individual contributor to TCPM. Some may have been = discussed already; I have re-read the document from scratch. I apologize = for any repetitions. >=20 > I have sent out a separate e-mail on whether the IANA considerations = in this document are formally correct. That discussion belongs into a = separate thread. >=20 > Major issues (not ordered by priority): >=20 > * Overall document >=20 > I am confused about whether it is required to _send_ TCP options. As = far as I recall past discussions, I thought that implementers asked to = make _sending_ TCP options optional. Or do I miss something? I also = think that there was less pushback on having a mandatory-to-implement = guidance regarding _receiving_ TCP options. As somebody who has worked = on sending sporadic TCP options a long time ago, I am concerned about = the complexity of any MUST statement that mandates sending TCP options. = The document seems inconsistent on that. For instance, Section 3.2.6 = states: " It is RECOMMENDED to implement both sending and receiving of = the AccECN Option." However, Section 3.2.8 mandates: "If an arriving = packet increments a different byte counter to that incremented by the = previous packet, the Data Receiver MUST immediately send an ACK with an = AccECN Option, ..." There is other unclear wording e.g. in Sections 2.1, = 2.3, and 5. Particularly confusing is also Section 7, which discusses = omitting the option as a security vulnerability. What is needed is a = clear statement on what is required regarding options at a prominent = place (e.g. also in the overview in Section 2). Then the whole document = has to be consistent to that. I personally believe that we should keep = the bar for implementers low. Sorry for the confusion here and thanks for flagging the issue in = section 3.2.8. However, this is really a wording issue. The MUST is = supposed to relate to the =E2=80=9Csend an ACK immediately=E2=80=9D and = was not supported to meant to say =E2=80=9CMUST send an option=E2=80=9D. = However, the wording is clearly confusing and we will fix that! The conclusion we arrived at of this general issue is that we RECOMMEND = to implement but there has never been any obligation to use the option. = I believe that it is clear throughout the document that the option is = and always has been actually optional (also because in some cases TCP = options might simply not useable) and we will make sure that we resolve = any confusion that the sentence in section 3.2.8 could otherwise cause. >=20 > * Overall document >=20 > This document contains some specification on caching. Given that we = now have a WG document (2140bis), I think the information therein could = be taken into account. For instance, a reference could be added and the = terminology could be reused (most of that terminology is established in = RFC 2140 already). I am a big fan of self-contained documents and = therefore the specific guidance on caching for AccECN belongs into = draft-ietf-tcpm-accurate-ecn. But that does not prevent referencing and = leveraging RFC 2140 and/or 2140bis terminology. Sure we can refer 2140bis informationally. >=20 > * Abstract/Introduction >=20 > draft-ietf-tcpm-accurate-ecn currently has at least two roles: It = allows echoing CE marks in SYN segments and therefore, in combination = with draft-ietf-tcpm-generalized-ecn, allows to set ECT on SYNs, and it = provides feedback more than once per RTT. I can think of scenarios in = which the former is more beneficial than the latter, i.e., in which = there is benefit of enabling ECT in SYNs, but feedback once per RTT is = enough. >=20 > One specific example (albeit it may not be the only one) is described = in draft-ietf-lwig-tcp-constrained-node-networks: A sender on embedded = devices with very small window (say, initially only one MSS) could = probably benefit from having CE marks instead of loss for SYNs, but = inherently there could only be one CE mark per RTT if there is at most = one segment outstanding, so RFC3168-style feedback seems good enough. = Being able to reflect more CE marks per RTT is not needed in that case = and the implementation overhead of doing this on an IoT device may be = questionable. This is an area very different e.g. from DCTCP, but TCP is = a general purpose protocol that also matters in IoT. I am not aware of = much current use of ECN in the IoT area, but there can be controlled = environments in this space as well, which, theoretically, may be able to = roll out ECN earlier than the public Internet. While I believe that the = handshake and the more-than-once-per-RTT feedback during a connection = are two separate items that could even be specified separately, I cannot = ask for such separation as I do not own running code. >=20 > But I believe it would at least make sense to better stress in the = abstract and introduction that more accurate ECN information is provided = during the handshake and for control segments. As I wrote, in some use = cases this may be the (only) relevant part of the protocol.. As specified in the requirements RFC the goal of accurate ECN is to = provide more accurate ECN feedback than once per RTT. Having feedback on = a per packet basis and well as per byte is the design the group settle = on which has the nice benefit that this also reflects marking of the = SYN. I think the goal of AccECN is clearly stated in the document. = However, if you have a concrete proposal for additional text, please = send it. >=20 > * Figure 1 >=20 > Figure 1 is outdated. I do not understand why this document draws a = picture with the "NS" flag, which is historic and has probably never = been used in widely deployed running code. Figure 1 should be removed. = Instead, what would make a lot of sense is to add a figure later in the = normative part of the document, e.g. in Section 3.1. That figure should = show the TCP header with "AE" flag as being used in SYN segments. As the section clearly states this section provides a recap of other = feedback mechanism in TCP and the picture shows "The (post-ECN Nonce) = definition of the TCP header flags=E2=80=9D as the title says. This is = to make clear what the relation to the NS bit is as we re-use a TCP = header flag for the first time. However, we could probably add another = such diagram with AE instead of NS in the next section. >=20 > * Section 2.4 (and elsewhere) >=20 > There is an (well, IMHO) unnecessary repetition of L4S and ConEx at = many places in the document. I am fine with introducing it in the = introduction. However, for instance, Section 2.4 states "If both are = present, the byte counter in the option will provide the more accurate = information needed for modern congestion control and policing schemes, = such as L4S, DCTCP or ConEx." It would be sufficient to state "If both = are present, the byte counter in the option will provide the more = accurate information". At least for DCTCP it is IMHO not proven that the = information in the _option_ is indeed needed, as implied by this = wording. As also explained already, some aspects of AccECN could also be = useful in quite different environments and it is unclear to me why only = L4S, DCTCP and ConEx are mentioned so repeatedly as (only) examples. Because these are the approaches that the IETF has specified, = documented, and is working on...? However, given it says =E2=80=9Cas = such=E2=80=9D it not supposed to exclude other future mechanisms. I = don=E2=80=99t really understand the concern here and would advocate for = referencing other existing work of the IETF where possible. >=20 > * Section 3.1.2. Forward Compatibility >=20 > "If a TCP server that implements AccECN receives a SYN with the = three > TCP header flags (AE, CWR and ECE) set to any combination other than > 000, 011 or 111, it MUST negotiate the use of AccECN as if they had > been set to 111. This ensures that future uses of the other > combinations on a SYN can rely on consistent behaviour from the > installed base of AccECN servers." >=20 > I have thought about the pros and cons of this forward compatibility = quite a bit and I am not entirely convinced of the benefits of this = rule, e.g., one could equally argue that fallback to RFC 3168 would be = quite reasonable as this is a standard that is safe to use. But I will = not further push back on this aspect if I am the only one person who = cares about it. >=20 > Having said this, what IMHO is missing is an addition to the first = sentence along the lines of "... unless the TCP server implements a TCP = extension that uses these codepoints". It is well understood that as of = today no such TCP extension exists. But the text of an RFC does not = change and if it contains forward-looking statements, these statements = should be written it in a way that the text stays valid also in future, = as far as this is possible I think this has be discussed extensively in the past. I also don=E2=80=99= t really see the different for the addition you proposed as of course = new RFCs may always add additional mechanism and there is nothing in the = text here that excludes that. From nobody Tue Nov 5 14:08: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 E30A9120C15 for ; Tue, 5 Nov 2019 14:08:14 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 7sTVpJQ_vMfx for ; Tue, 5 Nov 2019 14:08:13 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.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 2CFD0120C00 for ; Tue, 5 Nov 2019 14:08:13 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xA5LvAv3002380 for ; Tue, 5 Nov 2019 14:08:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=f5B4UHMfUqCsUAQT9HeLKM40PMd5aEgdwT473RH2Ghw=; b=ZtgWv1caYsY9mVwgJIVFj/RisO83JdI49SoBPuPwtbQW2xq3UioW/hzH7+uZleYJs7IT pJJoMgd31SWNfzx37XwuG8H02rXdwx78ZZpBEuuIZV3sOjel5nGw3cokKVhKtob4pV1X onlvvW1rivowrZswdvzlthxpS7lpFPwXlsQccThkbEbdZbJcoiPVi9gJtOOTdAyBGU/m jtyO3R/ZZ2ovVUHAf+8fb2Z16gM5sASM0oFKL7vIr2ZzL+oR8765qELOkdPYePv4nAB0 duzn3ZLKUpnXudV8uTJ0yYnwn8W6i8/+LBwVFdbH0JR4vUAUeErV5+onYUbxT/2w6DzZ aQ== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2w16cjs2pf-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 05 Nov 2019 14:08:12 -0800 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0I00229O5IQM90@ma1-mtap-s02.corp.apple.com> for tcpm@ietf.org; Tue, 05 Nov 2019 14:08:06 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0I00900O2E2R00@nwk-mmpp-sz13.apple.com> for tcpm@ietf.org; Tue, 05 Nov 2019 14:08:06 -0800 (PST) X-Va-A: X-Va-T-CD: 0dd5298a64b1f37164349b8f2c621797 X-Va-E-CD: 0615193077f65edcecfa897cfd1330b6 X-Va-R-CD: 461a6d9210f05d550542c9a09595375c X-Va-CD: 0 X-Va-ID: ec33c325-a65c-4fdf-8cd9-de1cf8969ed2 X-V-A: X-V-T-CD: 0dd5298a64b1f37164349b8f2c621797 X-V-E-CD: 0615193077f65edcecfa897cfd1330b6 X-V-R-CD: 461a6d9210f05d550542c9a09595375c X-V-CD: 0 X-V-ID: d8f36ce0-937c-40ae-bc2f-febfc1a4b571 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-05_08:,, signatures=0 Received: from vimac.scv.apple.com (vimac.scv.apple.com [17.192.171.33]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0I00CO4O5I1H00@nwk-mmpp-sz13.apple.com> for tcpm@ietf.org; Tue, 05 Nov 2019 14:08:06 -0800 (PST) Sender: vidhi_goel@apple.com From: Vidhi Goel Content-type: multipart/alternative; boundary="Apple-Mail=_482B5C72-A5D5-4E31-B7CD-8D447A4F5514" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Message-id: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> Date: Tue, 05 Nov 2019 14:08:06 -0800 To: tcpm@ietf.org X-Mailer: Apple Mail (2.3578.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-05_08:, , signatures=0 Archived-At: Subject: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= 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, 05 Nov 2019 22:08:19 -0000 --Apple-Mail=_482B5C72-A5D5-4E31-B7CD-8D447A4F5514 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, RFC 3465 suggests to increase the congestion window by the number of = previously unacknowledged bytes ACKed by each ACK limiting the increase = to L (L =3D 2MSS or 1MSS in certain conditions). The limiting factor L = helps to avoid the large bursts that could occur due to stretch ACKs, = ACK loss or compressed ACKs (GRO/GSO). But, when I looked at Linux source code, it implements one aspect of ABC = (byte counting to defend from ACK attacks) but doesn=E2=80=99t = =E2=80=9Ccap=E2=80=9D the increase to L.=20 https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_cong.c#L385 = This is a bit confusing. How should we address this discrepancy? Thanks, Vidhi= --Apple-Mail=_482B5C72-A5D5-4E31-B7CD-8D447A4F5514 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi All,

RFC 3465 suggests to increase the congestion window by the = number of previously unacknowledged bytes ACKed by each ACK limiting the = increase to L (L =3D 2MSS or 1MSS in certain conditions). The limiting = factor L helps to avoid the large bursts that could occur due to stretch = ACKs, ACK loss or compressed ACKs (GRO/GSO).

But, when I looked at Linux source code, it implements one = aspect of ABC (byte counting to defend from ACK attacks) but = doesn=E2=80=99t  =E2=80=9Ccap=E2=80=9D the increase to = L. 
 https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_cong= .c#L385

This is a bit confusing. How = should we address this discrepancy?


Thanks,
Vidhi
= --Apple-Mail=_482B5C72-A5D5-4E31-B7CD-8D447A4F5514-- From nobody Tue Nov 5 14:21: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 DE449120025; Tue, 5 Nov 2019 14:21:49 -0800 (PST) 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 9heacDC7nfqo; Tue, 5 Nov 2019 14:21:47 -0800 (PST) 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 52A661200CC; Tue, 5 Nov 2019 14:21:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9458825A24; Tue, 5 Nov 2019 23:21:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572992504; bh=J/xKWbPHUUfv75C8jZrXl7rmNmhh/6mLcA6lzJVo7Gs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ETH13Su84GPFaeDpjz1ImSfyilZs6Y+7LB1TZkjG3IV1N+XMKqf5x0uaGWisMWt6R MNAn90ScKzEXja3b3NUzV/hbmVmnLQmjP7dN/DQdRGiPaxAh/aJnP1RXUEleqHBJGP S2/jfOhcckQqkMJtUizryGKCW1upm4fbtICbRU28= 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 RqJOLGHseZrT; Tue, 5 Nov 2019 23:21:43 +0100 (CET) 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; Tue, 5 Nov 2019 23:21:43 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 5 Nov 2019 23:21:42 +0100 From: "Scharf, Michael" To: Sebastian Moeller CC: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] [tcpm] L4S status tracking Thread-Index: AQHVk7l10woiGkK3aEC+XZucFq6WNad9J1mC Date: Tue, 5 Nov 2019 22:21:42 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4E2FE0@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de>, <00F3EB28-F841-4FA2-8E95-89866404402B@gmx.de> In-Reply-To: <00F3EB28-F841-4FA2-8E95-89866404402B@gmx.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4E2FE0rznt8114rzntrzd_" 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: Tue, 05 Nov 2019 22:21:50 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E2FE0rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kLCB3ZWxsLCB0aGVyZSBhcmUgbm8gcHJlY2VkZW50cyBmb3IgdGhhdCBpbiB0aGUgSUVURj8N Cg0KDQoNCvCfmIkNCg0KDQoNCk1pY2hhZWwNCg0KDQoNClZvbjogU2ViYXN0aWFuIE1vZWxsZXI8 bWFpbHRvOm1vZWxsZXIwQGdteC5kZT4NCkdlc2VuZGV0OiBEaWVuc3RhZywgNS4gTm92ZW1iZXIg MjAxOSAxMDoxNA0KQW46IFNjaGFyZiwgTWljaGFlbDxtYWlsdG86TWljaGFlbC5TY2hhcmZAaHMt ZXNzbGluZ2VuLmRlPg0KQ2M6IFJvZG5leSBXLiBHcmltZXM8bWFpbHRvOjRib25lQGduZHJzaC5k bnNtZ3IubmV0PjsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz47IHRzdndnQGll dGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NCkJldHJlZmY6IFJlOiBbdHN2d2ddIFt0Y3Bt XSBMNFMgc3RhdHVzIHRyYWNraW5nDQoNCg0KDQpIaSBNaWNoYWVsLA0KDQoNCj4gT24gTm92IDQs IDIwMTksIGF0IDIwOjIxLCBTY2hhcmYsIE1pY2hhZWwgPE1pY2hhZWwuU2NoYXJmQGhzLWVzc2xp bmdlbi5kZT4gd3JvdGU6DQo+DQo+IEkgYWdyZWUuIOKAnm5vbi1MNFPigJwgbWF5IGJlIGV2ZW4g YmV0dGVyLg0KDQogICAgICAgIFtTTV0gZXhjZXB0IHRoYXQgTDRTLCB3aGljaCBleHBhbmRzIHRv ICJMb3cgTGF0ZW5jeSwgTG93IExvc3MsIFNjYWxhYmxlIFRocm91Z2hwdXQiIChzbyBpdCBhcmd1 YWJseSBzaG91bGQgYmUgTExMTFNUIG9yIEw0U1QpDQphcmd1YWJseSB0aGF0IGlzIGFsc28gIm1h cmtldGluZyBsYW5ndWFnZSIsIG5vPw0KDQpTZWJhc3RpYW4NCg0KDQo+DQo+IE1pY2hhZWwNCj4N Cj4NCj4gVm9uOiBSb2RuZXkgVy4gR3JpbWVzDQo+IEdlc2VuZGV0OiBNb250YWcsIDQuIE5vdmVt YmVyIDIwMTkgMjA6MTcNCj4gQW46IFNjaGFyZiwgTWljaGFlbA0KPiBDYzogQm9iIEJyaXNjb2U7 IFdlc2xleSBFZGR5OyB0c3Z3Z0BpZXRmLm9yZzsgdGNwbUBpZXRmLm9yZw0KPiBCZXRyZWZmOiBS ZTogW3RjcG1dIFt0c3Z3Z10gTDRTIHN0YXR1cyB0cmFja2luZw0KPg0KPiA+IFlvdSBjYW4gZS5n LiB1c2UgP25vbi1MNFMtZW5hYmxlZCBUQ1A/Lg0KPiA+DQo+ID4gVGVybWlub2xvZ3kgZG9lcyBt YXR0ZXIgdG8gbWUgZ2l2ZW4gdGhhdCBJIHN0cm9uZ2x5IGRpc2FncmVlIHRvIGFueSB1c2Ugb2Yg P21hcmtldGluZyBsYW5ndWFnZT8gd2hlbiBpdCBjb21lcyB0byBUQ1AuDQo+DQo+IE15IGNvbmNl cm4gaGVyZSBvZiB1c2Ugb2YgdGVybXMgbGlrZSwgbGVnYWN5LCBjbGFzc2ljLCBuZXcsIG9sZA0K PiBpcyB0aGF0IHRoZXkgYXJlIHByZXR0eSBtdWNoIGFsbCBvZiB0aGUgcmVsYXRpdmUgZnJvbSBh bmQgdGh1cw0KPiBhbWJpZ3VvdXMgb3ZlciB0aW1lLg0KPg0KPiBuZXdSZW5vIGlzIG5ldyBvbmx5 IHJlbGF0aXZlIHRvIFJlbm8sIHRoYXQgaXMgZmFpcmx5IGNsZWFyLA0KPiBidXQgaWYgSSBzYWlk IG5ld1RDUCBvciBvbGRUQ1Agd2l0aCB3aGF0IGZyYW1lIHNob3VsZCB0aGUNCj4gcmVmZXJlbmNl IGJlIGV2YWx1YXRlZC4NCj4NCj4gSSBiZWxpZXZlIGluIHRoZSBjYXNlIG9mIEw0UyB0aGUgdGlt ZSBpbnZhcmlhbnQgdGVybSB3b3VsZCBiZSwNCj4gYXMgTWljaGFlbCBzdWdnZXN0cyBhYm92ZSwg Im5vbi1MNFMiLiAgIE5vdGUgdGhhdCBlbmFibGVkDQo+IGZvciBtZSBpcyBhIG5vaXNlIHdvcmQg aW4gdGhpcyBjb250ZXh0LCBhbmQgVENQIG1heSBvciBtYXkNCj4gbm90IGJlIG5lZWRlZCBkZXBl bmRpbmcgb24gY29udGV4dCwgYnV0IGZvciBsaXRlcmFsIHJlcGxhY2VtZW50DQo+IG9mIExlZ2Fj eSBvciBDbGFzc2ljICJub24tTDRTIiBpcyBpbnZhcmlhbnQgb3ZlciB0aW1lLg0KPg0KPiBSb2QN Cj4NCj4gPiBNaWNoYWVsDQo+ID4NCj4gPg0KPiA+IFZvbjogQm9iIEJyaXNjb2U8bWFpbHRvOmll dGZAYm9iYnJpc2NvZS5uZXQ+DQo+ID4gR2VzZW5kZXQ6IE1vbnRhZywgNC4gTm92ZW1iZXIgMjAx OSAxOTowOQ0KPiA+IEFuOiBTY2hhcmYsIE1pY2hhZWw8bWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhz LWVzc2xpbmdlbi5kZT47IFdlc2xleSBFZGR5PG1haWx0bzp3ZXNAbXRpLXN5c3RlbXMuY29tPjsg dHN2d2dAaWV0Zi4ub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NCj4gPiBDYzogdGNwbUBpZXRm Lm9yZzxtYWlsdG86dGNwbUBpZXRmLi5vcmc+DQo+ID4gQmV0cmVmZjogUmU6IFt0Y3BtXSBbdHN2 d2ddIEw0UyBzdGF0dXMgdHJhY2tpbmcNCj4gPg0KPiA+IE1pY2hhZWwsDQo+ID4NCj4gPiBQcmV2 aW91c2x5LCBJIGhhdmUgYmVlbiB0b2xkIG5vdCB0byB1c2UgdGhlIHRlcm0gc3RhbmRhcmQgZm9y IFJGQ3MgdGhhdCBhcmUgbm90IHN0YW5kYXJkcy4gUkZDNTY4MSBpcyAnb25seScgYSBkcmFmdCBz dGFuZGFyZC4gVGhpcyBpcyB3aHksIGluIHRoZSBJRVRGIGF0IGxlYXN0LCBJIGF2b2lkIHVzaW5n IHRoZSB0ZXJtICJzdGFuZGFyZCBUQ1AgY29uZ2VzdGlvbiBjb250cm9sIi4gSSBnZW5lcmFsbHkg Y2FsbCBpdCBSZW5vIHdoZW4gcmVmZXJyaW5nIHRvIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wuDQo+ ID4NCj4gPiBJIGhhdmUgbmV2ZXIsIHRvIG15IGtub3dsZWRnZSwgdXNlZCB0aGUgdGVybSBjbGFz c2ljIFRDUCwgb3IgY2xhc3NpYyBUQ1AgY29uZ2VzdGlvbiBjb250cm9sLg0KPiA+DQo+ID4gQW5k IEkgcmFyZWx5IHVzZSB0aGUgdGVybSBsZWdhY3ksIGFuZCBpZiBJIGRvIEknbSBoYXBweSB0byBo YXZlIGFsdGVybmF0aXZlcyBzdWdnZXN0ZWQuDQo+ID4NCj4gPiBJJ3ZlIGNoZWNrZWQgdGhlIEw0 UyBkcmFmdHMsIGFuZCB0aGVyZSBpcyBvbmUgcGhyYXNlIHRoYXQgSSBzaGFsbCBsZWF2ZSBpbiBl Y24tbDRzLWlkOiAidGhlIHRyYWRpdGlvbmFsIFRDUCBSZW5vIGFkZGl0aXZlIGluY3JlYXNlIiwg YmVjYXVzZSB0aGlzIGlzIGNvcnJlY3RseSB1c2VkIHRvIG1lYW4gdGhlIHRyYWRpdGlvbmFsIGlu Y3JlYXNlIChpbiBudW1lcm91cyBBSU1EIENDcyksIG5vdCB0cmFkaXRpb25hbCBUQ1AuIFRoZXJl IHdhcyBvbmUgb3RoZXIgb2NjdXJyZW5jZSBvZiAidHJhZGl0aW9uYWwgVENQIHNlbmRlcnMiIGlu IGEgd2hvbGUgcGFyYSBpbiBhbiBhcHBlbmRpeCB0aGF0IGhhcyBqdXN0IGJlZW4gZGVsZXRlZCBh bnl3YXkuIEFuZCBpbiBhcW0tZHVhbHEtY291cGxlZCB0aGVyZSB3YXMgb25lICJsZWdhY3kgVENQ IGZsb3dzIiAoY2hhbmdlZCB0byAiQ2xhc3NpYyB0cmFmZmljIiBub3cgaW4gbXkgbG9jYWwgY29w eSwgdXNpbmcgdGhlIGRlZmluZWQgdGVybSBpbiBhbGwgdGhlIEw0UyBkcmFmdHMpLg0KPiA+DQo+ ID4gbDRzLWFyY2ggaXMgZ2V0dGluZyBhIGNvbXBsZXRlIG1ha2Utb3ZlciBmb3IgdGVybWlub2xv Z3ksIHNvIEkgd2lsbCBjaGVjayB0aGF0IG5leHQuDQo+ID4NCj4gPiBpbmxpbmUuLi4NCj4gPg0K PiA+DQo+ID4gT24gMjMvMDgvMjAxOSAxNTowMSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KPiA+ DQo+ID4gSGkgV2VzLA0KPiA+DQo+ID4NCj4gPg0KPiA+IEk/ZCBsaWtlIHRvIGFkZCBhIHNtYWxs ZXIgaXRlbSB0aGF0IGlzIG1vc3RseSBlZGl0b3JpYWwgYW5kIGNhbiBob3BlZnVsbHkgYmUgc29y dGVkIGp1c3Qgb3V0IGJ5IHJlLXdvcmRpbmcsIGFsYmVpdCBpdCBtYXkgcmVxdWlyZSBhIGNhcmVm dWwgYW5hbHlzaXMgb2YgYWxsIGRvY3VtZW50cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBcyBhbHJl YWR5IG5vdGVkIGluIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHN2d2cv elprWVpLRi1oRHZXTzNJNU11ZHdwTmtLeUhZPGh0dHBzOi8vbWFpbGFyY2hpdmUuLmlldGYub3Jn L2FyY2gvbXNnL3RzdndnL3paa1laS0YtaER2V08zSTVNdWR3cE5rS3lIWT4gLCBJIG9iamVjdCB0 byB0aGUgdGVybXMgP3RyYWRpdGlvbmFsIFRDUD8gYW5kIGFsc28gP2NsYXNzaWMgVENQPyBvciA/ bGVnYWN5PyBUQ1Agd2hlbiByZWZlcnJpbmcgdG8gYSBUQ1AgaW1wbGVtZW50YXRpb24gYWNjb3Jk aW5nIHRvIElFVEYgc3RhbmRhcmRzLXRyYWNrIFJGQ3MuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVG8g bWUgYXMgYSBub24tbmF0aXZlIG5hdGl2ZSBzcGVha2VyLCBhbGwgdGhlc2UgdGVybXMgaGF2ZSBh IG5lZ2F0aXZlIGNvbm5vdGF0aW9uLiBJIGFsc28gdGhpbmsgdGhpcyBsYW5ndWFnZSBpcyB0eXBp Y2FsIHRvIG1hcmtldGluZyBtYXRlcmlhbC4NCj4gPg0KPiA+IFlvdSdyZSBlbnRpdGxlZCB0byB5 b3VyIG9waW5pb24gYnV0LCBhcyBhIG5hdGl2ZSBzcGVha2VyLCBJIGRvbid0IHRoaW5rICdjbGFz c2ljJyBvciAndHJhZGl0aW9uYWwnIGFyZSBwYXJ0aWN1bGFybHkgcGVqb3JhdGl2ZSwgdGhvIHRo ZXkgY2FuIGJlIHdoZW4gdXNlZCBpbiBhIGNvbnRleHQgdGhhdCBpbnRlbmRzIHRoZW0gdG8gYmUu IFRoZXkgYWxzbyBtZWFuICJzdG9vZCB0aGUgdGVzdCBvZiB0aW1lIi4gSSBmaW5kICdsZWdhY3kn IGhhcyBhIGNvbm5vdGF0aW9uIG9mIG1hcmtldGluZy1zcGVhaywgYnV0IGl0J3Mgbm90IHRoYXQg YmFkLg0KPiA+DQo+ID4gVGhpcyBpcyBhbiBlbmR1cmluZyBwcm9ibGVtIHdoZW4gdHJ5aW5nIHRv IGltcHJvdmUgb24gdGhlIGdvb2Qgd29yayB0aGF0IG90aGVyIHBlb3BsZSBoYXZlIGRvbmUgYmVm b3JlIHlvdSAod2hpY2ggaXMgdGhlIGNvbnRleHQgb2YgZXZlcnl0aGluZyB3ZSBhcmUgZG9pbmcp LiBXZSBuZWVkIGEgd29yZCB0aGF0IGRpc3Rpbmd1aXNoZXMgdGhlIG9sZCBmcm9tIHRoZSBuZXcs IGJ1dCB3ZSBkb24ndCB3YW50IHRvIGNvbXBsZXRlbHkgdHJhc2ggdGhlIHRoaW5nIHRoYXQgaGFz IGFscmVhZHkgYmVlbiBzdWNjZXNzZnVsLCBidXQgaGFkIGl0cyBkYXkuDQo+ID4NCj4gPiBOb25l dGhlbGVzcywgaXQgaXMgYWxzbyBpbXBvcnRhbnQgbm90IHRvIGJlIHRvbyBwcmVjaW91cyBhYm91 dCBwYXN0IHdvcmsuIFdlIGFsbCByZWNvZ25pemUgdGhhdCBSZW5vIFRDUCBpcyB1bnNjYWxhYmxl IGFuZCBoYXMgcHJvYmxlbXMuIElNTywgaXQgaXMgT0sgdG8gZGVzY3JpYmUgdGVjaG5vbG9naWVz IHRoYXQgaGF2ZSBoYWQgdGhlaXIgdGltZSB3aXRoIG5lZ2F0aXZlIGNvbm5vdGF0aW9ucy4gSW5k ZWVkLCB5b3UgaGF2ZSBiZWVuIGFuIGF1dGhvciAod2l0aCBtZSkgb2YgYW4gUkZDIG9uIG9wZW4g aXNzdWVzIGluIGNvbmdlc3Rpb24gY29udHJvbC4NCj4gPg0KPiA+IEkgbm90aWNlIHlvdSBoYXZl bid0IHN1Z2dlc3RlZCBhbiBhbHRlcm5hdGl2ZSB0ZXJtIGZvciAidGhlIHRoaW5nKHMpIHdlIGFy ZSB0cnlpbmcgdG8gaW1wcm92ZSBvbiIuIE5vdCBzdXJwcmlzaW5nLCBiZWNhdXNlIGl0J3MgZGlm ZmljdWx0Lg0KPiA+DQo+ID4gV2hlbiB3ZSAodGhlIEw0UyBkZXZlbG9wZXJzKSB3ZXJlIGZpcnN0 IGxvb2tpbmcgZm9yIGEgdGVybSBmb3IgdGhlIG5vbi1MNFMgcXVldWUgYW5kIHRoZSBub24tTDRT IHNlcnZpY2UsIHdlIGRpZG4ndCB3YW50IHRvIHVzZSAnbGVnYWN5JyBmb3IgdGhlIGFib3ZlIHJl YXNvbnMsIGJ1dCB3ZSBkaWQgd2FudCB0byBpbXBseSBwcmUtZXhpc3RpbmcsIHNvIHdlIGRlY2lk ZWQgb24gJ2NsYXNzaWMnLCB3aGljaCB3ZSBhbGwgZmVsdCBoYWQgYSBnZW5lcmFsbHkgbmV1dHJh bCBjb25ub3RhdGlvbiwgYnV0IHNhaWQgd2hhdCB3ZSBtZWFudC4NCj4gPg0KPiA+IEZpbmFsbHks IEkgZG8gbm90IHdhbnQgdGhpcyBpc3N1ZSB0byB0YWtlIHVwIGFueSB0aW1lIHRoYXQgd291bGQg ZGV0cmFjdCBmcm9tIHRlY2huaWNhbCBpc3N1ZXMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gQm9iDQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBNeSBwcmVmZXJlZCB0ZXJtIHdoZW4gcmVmZXJyaW5nIHRv IFRDUCBhY2NvcmRpbmcgdG8gc3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb24gaXMgP3N0YW5k YXJkIFRDUD8uIEkgd291bGQgYWxzbyBiZSBmaW5lIHdpdGggb3RoZXIgdGVybXMgYXMgbG9uZyBh cyB0aGV5IGFyZSBuZXV0cmFsIGFuZCBtYWtlIGNsZWFyIHRoYXQgZXhwZXJpbWVudHMgZG8gbm90 IHJlcGxhY2UsIGRlcHJlY2F0ZSwgb3Igb3V0cGVyZm9ybSBzdGFuZGFyZHMuDQo+ID4NCj4gPg0K PiA+DQo+ID4gU2ltaWxhcmx5LCBJIHRoaW5rIHRoYXQgdGVybSBzdWNoIGFzID9jbGFzc2ljPyBp cyBub3QgYXBwcm9wcmlhdGUgZm9yIHRoZSBUQ1Agc3RhbmRhcmQgY29uZ2VzdGlvbiBjb250cm9s ICg/UmVubz8pLiBBcyBvZiB0b2RheSwgdGhpcyBpcyB0aGUgVENQIGNvbmdlc3Rpb24gY29udHJv bCBhbGdvcml0aG0gb24gc3RhbmRhcmRzIHRyYWNrIHRoYXQgaGFzIElFVEYgY29uc2Vuc3VzLiBU aGUgdGVybSBpbiB0aGUgVENQTSBjaGFydGVyIGlzID9UQ1Agc3RhbmRhcmQgY29uZ2VzdGlvbiBj b250cm9sPy4gSSBhbHNvIHRoaW5rIHRoYXQgdGVybXMgc3VjaCBhcyA/UmVuby1jb21wYXRpYmxl PyBvciB0aGUgbGlrZSB3b3VsZCBiZSBuZXV0cmFsLg0KPiA+DQo+ID4NCj4gPg0KPiA+IE5vdGUg dGhhdCBJIGRvIG5vdCBvYmplY3QgdG8gdGhlIHRlcm1zID9jbGFzc2ljIEVDTj8sID9sZWdhY3kg RUNOPywgP2xlZ2FjeSBBUU0/IG9yIHRoZSBsaWtlLCBpLmUuLCBpZiB0aGUgY29udGV4dCBpcyBF Q04gYW5kIG5vdCBzcGVjaWZpY2FsbHkgVENQIG9yIHRoZSBUQ1AgY29uZ2VzdGlvbiBjb250cm9s LiBJIGJlbGlldmUgaXQgaXMgdXAgdG8gdGhlIFRTVldHIGRvIGRlY2lkZSBpZiB0aGlzIHRlcm0g c2hhbGwgYmUgdXNlZCBmb3IgY29tcGxpYW5jZSB0byBSRkMgMzE2OC4gSSBoYXZlIG5vIHN0cm9u ZyBvcGluaW9uIG9uIHRoYXQuIEFzIGZhciBhcyBJIGNhbiBzZWUsIG1vc3QgdXNlIG9mIHRoZSB0 ZXJtID9jbGFzc2ljPyBpcyBpbiB0aGlzIGNvbnRleHQgYW5kIEkgZG9uP3QgYXNrIGZvciBjaGFu Z2VzIGluIHRob3NlIGNhc2VzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFNvbWUgdXNlIG9mIHRoZSB0 ZXJtID9DbGFzc2ljIFNlcnZpY2U/IG1heSBhbHNvIHJlcXVpcmUgY2FyZWZ1bCByZXZpZXcgdG8g Y2xlYXJseSBzZXBhcmF0ZSBpdCBmcm9tIFRDUCBTdGFuZGFyZCBiZWhhdmlvci4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBOb3RlIHRoYXQgc29tZSB1c2Ugb2YgdGhlIHRlcm0gP0NsYXNzaWMgVENQPyB3 b3VsZCBwcm9iYWJseSBhbHNvIGFwcGx5IHRvID9DbGFzc2ljIFFVSUM/IG9uY2UgdGhlIFFVSUMg c3RhbmRhcmQgaXMgZmluaXNoZWQuIFRvIG1lIGFzIGEgbm9uLW5hdGl2ZSBzcGVha2VyLCBpdCB3 b3VsZCBiZSByZWFsbHkgc3RyYW5nZSB0byB1c2UgdGhlIHRlcm0gP2NsYXNzaWM/IGluIHRoZSBj b250ZXh0IG9mIGEgYnJhbmQtbmV3IHRyYW5zcG9ydCBwcm90b2NvbC4gSU1ITyBpbiB0aGF0IGNh c2UgdGhlIHRlcm0gP2NsYXNzaWM/IHdvdWxkIGJlIGV2ZW4gbW9yZSBjb25mdXNpbmcuDQo+ID4N Cj4gPg0KPiA+DQo+ID4gSSBhbHNvIGFkZCB0aGUgVENQTSBsaXN0IGluIENDIHRvIGVuc3VyZSBj b25zaXN0ZW5jeS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MNCj4gPg0KPiA+DQo+ID4NCj4g PiBNaWNoYWVsICh3aXRoIG5vIGhhdCkNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gVm9u OiBXZXNsZXkgRWRkeTxtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbT4NCj4gPiBHZXNlbmRldDog U29ubnRhZywgMTEuIEF1Z3VzdCAyMDE5IDA3OjA4DQo+ID4gQW46IHRzdndnQGlldGYub3JnPG1h aWx0bzp0c3Z3Z0BpZXRmLm9yZz4NCj4gPiBCZXRyZWZmOiBbdHN2d2ddIEw0UyBzdGF0dXMgdHJh Y2tpbmcNCj4gPg0KPiA+DQo+ID4NCj4gPiBJIGNyZWF0ZWQgdGlja2V0cyBpbiB0aGUgVFNWV0cg InRyYWMiIHRvb2wgaW4gb3JkZXIgdG8gaGVscCBrZWVwIHRyYWNrDQo+ID4gb2YgdGhlIGluZGl2 aWR1YWwgdGhpbmdzIHRoYXQgbG9vayBsaWtlIHRoZXkgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbg0K PiA+IHByb2dyZXNzaW5nIEw0UyBkb2N1bWVudCBzZXQ6DQo+ID4NCj4gPiBodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy90c3Z3Zy9yZXBvcnQvMT9zb3J0PXRpY2tldCZhc2M9MSZwYWdlPTENCj4g Pg0KPiA+IEknbGwgdHJ5IHRvIHVwZGF0ZSB0aGVzZSBiYXNlZCBvbiB0aGUgb25nb2luZyBkaXNj dXNzaW9ucywgdXBkYXRlcywNCj4gPiBldGMuLCBidXQgaXQgd2lsbCBtYWtlIGl0IHZlcnkgZWFz eSBpZiB5b3UgaGFwcGVuIHRvIG1lbnRpb24gdGhlIHRpY2tldA0KPiA+IG51bWJlcnMgb3Igc29t ZSBrZXkgd29yZHMgaW4gdGhyZWFkcyBhbmQgbWVzc2FnZXMsIHdoZW4gc2lnbmlmaWNhbnQuDQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYu b3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGNwbQ0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IEJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2Jicmlz Y29lLm5ldC8NCj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gdGNwbUBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPg0KPiAtLQ0KPiBSb2Qg R3JpbWVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJn cmltZXNAZnJlZWJzZC5vcmcNCg0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E2FE0rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZT4NCjwhLS0NCnAueF9Nc29Ob3JtYWwsIGxpLnhfTXNvTm9y bWFsLCBkaXYueF9Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zn0NCnNwYW4ueF9Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lfQ0KLnhfTXNvQ2hwRGVmYXVsdA0KCXt9DQpkaXYueF9Xb3JkU2VjdGlvbjENCgl7 fQ0KLS0+DQo8L3N0eWxlPg0KPGRpdiBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0ieF9Xb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij5BbmQsIHdlbGwsIHRoZXJlIGFyZSBubyBwcmVjZWRlbnRzIGZvciB0aGF0IGluIHRoZSBJRVRG PzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVv dDssc2Fucy1zZXJpZiI+8J+YiTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+TWljaGFlbDxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+Jm5ic3A7PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTsgcGFkZGluZzowY20iPjxiPlZvbjog PC9iPjxhIGhyZWY9Im1haWx0bzptb2VsbGVyMEBnbXguZGUiPlNlYmFzdGlhbiBNb2VsbGVyPC9h Pjxicj4NCjxiPkdlc2VuZGV0OiA8L2I+RGllbnN0YWcsIDUuIE5vdmVtYmVyIDIwMTkgMTA6MTQ8 YnI+DQo8Yj5BbjogPC9iPjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5n ZW4uZGUiPlNjaGFyZiwgTWljaGFlbDwvYT48YnI+DQo8Yj5DYzogPC9iPjxhIGhyZWY9Im1haWx0 bzo0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldCI+Um9kbmV5IFcuIEdyaW1lczwvYT47IDxhIGhyZWY9 Im1haWx0bzp0Y3BtQGlldGYub3JnIj4NCnRjcG1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjxicj4NCjxiPkJldHJlZmY6IDwv Yj5SZTogW3RzdndnXSBbdGNwbV0gTDRTIHN0YXR1cyB0cmFja2luZzwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRl eHQiPkhpIE1pY2hhZWwsPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBPbiBOb3YgNCwgMjAxOSwgYXQg MjA6MjEsIFNjaGFyZiwgTWljaGFlbCAmbHQ7TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRl Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhZ3JlZS4g4oCebm9uLUw0U+KAnCBt YXkgYmUgZXZlbiBiZXR0ZXIuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFtTTV0gZXhjZXB0IHRoYXQgTDRTLCB3aGljaCBleHBhbmRzIHRvICZx dW90O0xvdyBMYXRlbmN5LCBMb3cgTG9zcywgU2NhbGFibGUgVGhyb3VnaHB1dCZxdW90OyAoc28g aXQgYXJndWFibHkgc2hvdWxkIGJlIExMTExTVCBvciBMNFNUKTxicj4NCmFyZ3VhYmx5IHRoYXQg aXMgYWxzbyAmcXVvdDttYXJrZXRpbmcgbGFuZ3VhZ2UmcXVvdDssIG5vPzxicj4NCjxicj4NClNl YmFzdGlhbjxicj4NCjxicj4NCjxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0OyBNaWNoYWVsPGJy Pg0KJmd0OyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDsgVm9uOiBSb2RuZXkgVy4g R3JpbWVzPGJyPg0KJmd0OyBHZXNlbmRldDogTW9udGFnLCA0LiBOb3ZlbWJlciAyMDE5IDIwOjE3 PGJyPg0KJmd0OyBBbjogU2NoYXJmLCBNaWNoYWVsPGJyPg0KJmd0OyBDYzogQm9iIEJyaXNjb2U7 IFdlc2xleSBFZGR5OyB0c3Z3Z0BpZXRmLm9yZzsgdGNwbUBpZXRmLm9yZzxicj4NCiZndDsgQmV0 cmVmZjogUmU6IFt0Y3BtXSBbdHN2d2ddIEw0UyBzdGF0dXMgdHJhY2tpbmc8YnI+DQomZ3Q7Jm5i c3A7IDxicj4NCiZndDsgJmd0OyBZb3UgY2FuIGUuZy4gdXNlID9ub24tTDRTLWVuYWJsZWQgVENQ Py48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRlcm1pbm9sb2d5IGRvZXMgbWF0dGVy IHRvIG1lIGdpdmVuIHRoYXQgSSBzdHJvbmdseSBkaXNhZ3JlZSB0byBhbnkgdXNlIG9mID9tYXJr ZXRpbmcgbGFuZ3VhZ2U/IHdoZW4gaXQgY29tZXMgdG8gVENQLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBNeSBjb25jZXJuIGhlcmUgb2YgdXNlIG9mIHRlcm1zIGxpa2UsIGxlZ2FjeSwgY2xhc3NpYywg bmV3LCBvbGQ8YnI+DQomZ3Q7IGlzIHRoYXQgdGhleSBhcmUgcHJldHR5IG11Y2ggYWxsIG9mIHRo ZSByZWxhdGl2ZSBmcm9tIGFuZCB0aHVzPGJyPg0KJmd0OyBhbWJpZ3VvdXMgb3ZlciB0aW1lLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBuZXdSZW5vIGlzIG5ldyBvbmx5IHJlbGF0aXZlIHRvIFJlbm8s IHRoYXQgaXMgZmFpcmx5IGNsZWFyLDxicj4NCiZndDsgYnV0IGlmIEkgc2FpZCBuZXdUQ1Agb3Ig b2xkVENQIHdpdGggd2hhdCBmcmFtZSBzaG91bGQgdGhlPGJyPg0KJmd0OyByZWZlcmVuY2UgYmUg ZXZhbHVhdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGJlbGlldmUgaW4gdGhlIGNhc2Ugb2Yg TDRTIHRoZSB0aW1lIGludmFyaWFudCB0ZXJtIHdvdWxkIGJlLDxicj4NCiZndDsgYXMgTWljaGFl bCBzdWdnZXN0cyBhYm92ZSwgJnF1b3Q7bm9uLUw0UyZxdW90Oy4mbmJzcDsmbmJzcDsgTm90ZSB0 aGF0IGVuYWJsZWQ8YnI+DQomZ3Q7IGZvciBtZSBpcyBhIG5vaXNlIHdvcmQgaW4gdGhpcyBjb250 ZXh0LCBhbmQgVENQIG1heSBvciBtYXk8YnI+DQomZ3Q7IG5vdCBiZSBuZWVkZWQgZGVwZW5kaW5n IG9uIGNvbnRleHQsIGJ1dCBmb3IgbGl0ZXJhbCByZXBsYWNlbWVudDxicj4NCiZndDsgb2YgTGVn YWN5IG9yIENsYXNzaWMgJnF1b3Q7bm9uLUw0UyZxdW90OyBpcyBpbnZhcmlhbnQgb3ZlciB0aW1l Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBSb2Q8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBNaWNo YWVsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVm9uOiBC b2IgQnJpc2NvZSZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCI+bWFpbHRv OmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBHZXNlbmRldDogTW9u dGFnLCA0LiBOb3ZlbWJlciAyMDE5IDE5OjA5PGJyPg0KJmd0OyAmZ3Q7IEFuOiBTY2hhcmYsIE1p Y2hhZWwmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSI+ bWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZTwvYT4mZ3Q7OyBXZXNsZXkgRWRk eSZsdDs8YSBocmVmPSJtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbSI+bWFpbHRvOndlc0BtdGkt c3lzdGVtcy5jb208L2E+Jmd0OzsgdHN2d2dAaWV0Zi4ub3JnJmx0OzxhIGhyZWY9Im1haWx0bzp0 c3Z3Z0BpZXRmLm9yZyI+bWFpbHRvOnRzdndnQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZn dDsgQ2M6IHRjcG1AaWV0Zi5vcmcmbHQ7PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi4ub3JnIj5t YWlsdG86dGNwbUBpZXRmLi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBCZXRyZWZmOiBSZTog W3RjcG1dIFt0c3Z3Z10gTDRTIHN0YXR1cyB0cmFja2luZzxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgTWljaGFlbCw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFByZXZpb3Vz bHksIEkgaGF2ZSBiZWVuIHRvbGQgbm90IHRvIHVzZSB0aGUgdGVybSBzdGFuZGFyZCBmb3IgUkZD cyB0aGF0IGFyZSBub3Qgc3RhbmRhcmRzLiBSRkM1NjgxIGlzICdvbmx5JyBhIGRyYWZ0IHN0YW5k YXJkLiBUaGlzIGlzIHdoeSwgaW4gdGhlIElFVEYgYXQgbGVhc3QsIEkgYXZvaWQgdXNpbmcgdGhl IHRlcm0gJnF1b3Q7c3RhbmRhcmQgVENQIGNvbmdlc3Rpb24gY29udHJvbCZxdW90Oy4gSSBnZW5l cmFsbHkgY2FsbCBpdCBSZW5vIHdoZW4gcmVmZXJyaW5nDQogdG8gdGhlIGNvbmdlc3Rpb24gY29u dHJvbC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBuZXZlciwgdG8gbXkg a25vd2xlZGdlLCB1c2VkIHRoZSB0ZXJtIGNsYXNzaWMgVENQLCBvciBjbGFzc2ljIFRDUCBjb25n ZXN0aW9uIGNvbnRyb2wuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmQgSSByYXJl bHkgdXNlIHRoZSB0ZXJtIGxlZ2FjeSwgYW5kIGlmIEkgZG8gSSdtIGhhcHB5IHRvIGhhdmUgYWx0 ZXJuYXRpdmVzIHN1Z2dlc3RlZC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkndmUg Y2hlY2tlZCB0aGUgTDRTIGRyYWZ0cywgYW5kIHRoZXJlIGlzIG9uZSBwaHJhc2UgdGhhdCBJIHNo YWxsIGxlYXZlIGluIGVjbi1sNHMtaWQ6ICZxdW90O3RoZSB0cmFkaXRpb25hbCBUQ1AgUmVubyBh ZGRpdGl2ZSBpbmNyZWFzZSZxdW90OywgYmVjYXVzZSB0aGlzIGlzIGNvcnJlY3RseSB1c2VkIHRv IG1lYW4gdGhlIHRyYWRpdGlvbmFsIGluY3JlYXNlIChpbiBudW1lcm91cyBBSU1EIENDcyksIG5v dCB0cmFkaXRpb25hbCBUQ1AuIFRoZXJlIHdhcyBvbmUNCiBvdGhlciBvY2N1cnJlbmNlIG9mICZx dW90O3RyYWRpdGlvbmFsIFRDUCBzZW5kZXJzJnF1b3Q7IGluIGEgd2hvbGUgcGFyYSBpbiBhbiBh cHBlbmRpeCB0aGF0IGhhcyBqdXN0IGJlZW4gZGVsZXRlZCBhbnl3YXkuIEFuZCBpbiBhcW0tZHVh bHEtY291cGxlZCB0aGVyZSB3YXMgb25lICZxdW90O2xlZ2FjeSBUQ1AgZmxvd3MmcXVvdDsgKGNo YW5nZWQgdG8gJnF1b3Q7Q2xhc3NpYyB0cmFmZmljJnF1b3Q7IG5vdyBpbiBteSBsb2NhbCBjb3B5 LCB1c2luZyB0aGUgZGVmaW5lZCB0ZXJtIGluIGFsbCB0aGUNCiBMNFMgZHJhZnRzKS48YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGw0cy1hcmNoIGlzIGdldHRpbmcgYSBjb21wbGV0ZSBt YWtlLW92ZXIgZm9yIHRlcm1pbm9sb2d5LCBzbyBJIHdpbGwgY2hlY2sgdGhhdCBuZXh0Ljxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgaW5saW5lLi4uPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gMjMvMDgvMjAxOSAxNTowMSwgU2NoYXJmLCBN aWNoYWVsIHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSGkgV2VzLDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBJP2QgbGlrZSB0byBhZGQgYSBzbWFsbGVyIGl0ZW0gdGhhdCBpcyBtb3N0bHkgZWRpdG9yaWFs IGFuZCBjYW4gaG9wZWZ1bGx5IGJlIHNvcnRlZCBqdXN0IG91dCBieSByZS13b3JkaW5nLCBhbGJl aXQgaXQgbWF5IHJlcXVpcmUgYSBjYXJlZnVsIGFuYWx5c2lzIG9mIGFsbCBkb2N1bWVudHMuPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IEFzIGFscmVhZHkgbm90ZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy90c3Z3Zy96WmtZWktGLWhEdldPM0k1TXVkd3BOa0t5SFkmbHQ7aHR0cHM6 Ly9tYWlsYXJjaGl2ZS4uaWV0Zi5vcmcvYXJjaC9tc2cvdHN2d2cvelprWVpLRi1oRHZXTzNJNU11 ZHdwTmtLeUhZIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHN2d2cv elprWVpLRi1oRHZXTzNJNU11ZHdwTmtLeUhZJmx0O2h0dHBzOi8vbWFpbGFyY2hpdmUuLmlldGYu b3JnL2FyY2gvbXNnL3RzdndnL3paa1laS0YtaER2V08zSTVNdWR3cE5rS3lIWTwvYT4mZ3Q7ICwg SSBvYmplY3QgdG8gdGhlIHRlcm1zID90cmFkaXRpb25hbCBUQ1A/IGFuZCBhbHNvID9jbGFzc2lj IFRDUD8gb3IgP2xlZ2FjeT8gVENQIHdoZW4gcmVmZXJyaW5nIHRvIGEgVENQIGltcGxlbWVudGF0 aW9uDQogYWNjb3JkaW5nIHRvIElFVEYgc3RhbmRhcmRzLXRyYWNrIFJGQ3MuPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvIG1l IGFzIGEgbm9uLW5hdGl2ZSBuYXRpdmUgc3BlYWtlciwgYWxsIHRoZXNlIHRlcm1zIGhhdmUgYSBu ZWdhdGl2ZSBjb25ub3RhdGlvbi4gSSBhbHNvIHRoaW5rIHRoaXMgbGFuZ3VhZ2UgaXMgdHlwaWNh bCB0byBtYXJrZXRpbmcgbWF0ZXJpYWwuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBZ b3UncmUgZW50aXRsZWQgdG8geW91ciBvcGluaW9uIGJ1dCwgYXMgYSBuYXRpdmUgc3BlYWtlciwg SSBkb24ndCB0aGluayAnY2xhc3NpYycgb3IgJ3RyYWRpdGlvbmFsJyBhcmUgcGFydGljdWxhcmx5 IHBlam9yYXRpdmUsIHRobyB0aGV5IGNhbiBiZSB3aGVuIHVzZWQgaW4gYSBjb250ZXh0IHRoYXQg aW50ZW5kcyB0aGVtIHRvIGJlLiBUaGV5IGFsc28gbWVhbiAmcXVvdDtzdG9vZCB0aGUgdGVzdCBv ZiB0aW1lJnF1b3Q7LiBJIGZpbmQgJ2xlZ2FjeScgaGFzDQogYSBjb25ub3RhdGlvbiBvZiBtYXJr ZXRpbmctc3BlYWssIGJ1dCBpdCdzIG5vdCB0aGF0IGJhZC48YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IFRoaXMgaXMgYW4gZW5kdXJpbmcgcHJvYmxlbSB3aGVuIHRyeWluZyB0byBpbXBy b3ZlIG9uIHRoZSBnb29kIHdvcmsgdGhhdCBvdGhlciBwZW9wbGUgaGF2ZSBkb25lIGJlZm9yZSB5 b3UgKHdoaWNoIGlzIHRoZSBjb250ZXh0IG9mIGV2ZXJ5dGhpbmcgd2UgYXJlIGRvaW5nKS4gV2Ug bmVlZCBhIHdvcmQgdGhhdCBkaXN0aW5ndWlzaGVzIHRoZSBvbGQgZnJvbSB0aGUgbmV3LCBidXQg d2UgZG9uJ3Qgd2FudCB0byBjb21wbGV0ZWx5IHRyYXNoIHRoZQ0KIHRoaW5nIHRoYXQgaGFzIGFs cmVhZHkgYmVlbiBzdWNjZXNzZnVsLCBidXQgaGFkIGl0cyBkYXkuPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBOb25ldGhlbGVzcywgaXQgaXMgYWxzbyBpbXBvcnRhbnQgbm90IHRvIGJl IHRvbyBwcmVjaW91cyBhYm91dCBwYXN0IHdvcmsuIFdlIGFsbCByZWNvZ25pemUgdGhhdCBSZW5v IFRDUCBpcyB1bnNjYWxhYmxlIGFuZCBoYXMgcHJvYmxlbXMuIElNTywgaXQgaXMgT0sgdG8gZGVz Y3JpYmUgdGVjaG5vbG9naWVzIHRoYXQgaGF2ZSBoYWQgdGhlaXIgdGltZSB3aXRoIG5lZ2F0aXZl IGNvbm5vdGF0aW9ucy4gSW5kZWVkLCB5b3UgaGF2ZSBiZWVuIGFuDQogYXV0aG9yICh3aXRoIG1l KSBvZiBhbiBSRkMgb24gb3BlbiBpc3N1ZXMgaW4gY29uZ2VzdGlvbiBjb250cm9sLjxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBub3RpY2UgeW91IGhhdmVuJ3Qgc3VnZ2VzdGVkIGFu IGFsdGVybmF0aXZlIHRlcm0gZm9yICZxdW90O3RoZSB0aGluZyhzKSB3ZSBhcmUgdHJ5aW5nIHRv IGltcHJvdmUgb24mcXVvdDsuIE5vdCBzdXJwcmlzaW5nLCBiZWNhdXNlIGl0J3MgZGlmZmljdWx0 Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hlbiB3ZSAodGhlIEw0UyBkZXZlbG9w ZXJzKSB3ZXJlIGZpcnN0IGxvb2tpbmcgZm9yIGEgdGVybSBmb3IgdGhlIG5vbi1MNFMgcXVldWUg YW5kIHRoZSBub24tTDRTIHNlcnZpY2UsIHdlIGRpZG4ndCB3YW50IHRvIHVzZSAnbGVnYWN5JyBm b3IgdGhlIGFib3ZlIHJlYXNvbnMsIGJ1dCB3ZSBkaWQgd2FudCB0byBpbXBseSBwcmUtZXhpc3Rp bmcsIHNvIHdlIGRlY2lkZWQgb24gJ2NsYXNzaWMnLCB3aGljaCB3ZSBhbGwgZmVsdCBoYWQgYSBn ZW5lcmFsbHkNCiBuZXV0cmFsIGNvbm5vdGF0aW9uLCBidXQgc2FpZCB3aGF0IHdlIG1lYW50Ljxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgRmluYWxseSwgSSBkbyBub3Qgd2FudCB0aGlz IGlzc3VlIHRvIHRha2UgdXAgYW55IHRpbWUgdGhhdCB3b3VsZCBkZXRyYWN0IGZyb20gdGVjaG5p Y2FsIGlzc3Vlcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgQm9iPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBNeSBwcmVmZXJlZCB0 ZXJtIHdoZW4gcmVmZXJyaW5nIHRvIFRDUCBhY2NvcmRpbmcgdG8gc3RhbmRhcmRzLXRyYWNrIHNw ZWNpZmljYXRpb24gaXMgP3N0YW5kYXJkIFRDUD8uIEkgd291bGQgYWxzbyBiZSBmaW5lIHdpdGgg b3RoZXIgdGVybXMgYXMgbG9uZyBhcyB0aGV5IGFyZSBuZXV0cmFsIGFuZCBtYWtlIGNsZWFyIHRo YXQgZXhwZXJpbWVudHMgZG8gbm90IHJlcGxhY2UsIGRlcHJlY2F0ZSwgb3Igb3V0cGVyZm9ybSBz dGFuZGFyZHMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IFNpbWlsYXJseSwgSSB0aGluayB0aGF0IHRlcm0gc3VjaCBhcyA/Y2xh c3NpYz8gaXMgbm90IGFwcHJvcHJpYXRlIGZvciB0aGUgVENQIHN0YW5kYXJkIGNvbmdlc3Rpb24g Y29udHJvbCAoP1Jlbm8/KS4gQXMgb2YgdG9kYXksIHRoaXMgaXMgdGhlIFRDUCBjb25nZXN0aW9u IGNvbnRyb2wgYWxnb3JpdGhtIG9uIHN0YW5kYXJkcyB0cmFjayB0aGF0IGhhcyBJRVRGIGNvbnNl bnN1cy4gVGhlIHRlcm0gaW4gdGhlIFRDUE0gY2hhcnRlciBpcyA/VENQDQogc3RhbmRhcmQgY29u Z2VzdGlvbiBjb250cm9sPy4gSSBhbHNvIHRoaW5rIHRoYXQgdGVybXMgc3VjaCBhcyA/UmVuby1j b21wYXRpYmxlPyBvciB0aGUgbGlrZSB3b3VsZCBiZSBuZXV0cmFsLjxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOb3RlIHRoYXQg SSBkbyBub3Qgb2JqZWN0IHRvIHRoZSB0ZXJtcyA/Y2xhc3NpYyBFQ04/LCA/bGVnYWN5IEVDTj8s ID9sZWdhY3kgQVFNPyBvciB0aGUgbGlrZSwgaS5lLiwgaWYgdGhlIGNvbnRleHQgaXMgRUNOIGFu ZCBub3Qgc3BlY2lmaWNhbGx5IFRDUCBvciB0aGUgVENQIGNvbmdlc3Rpb24gY29udHJvbC4gSSBi ZWxpZXZlIGl0IGlzIHVwIHRvIHRoZSBUU1ZXRyBkbyBkZWNpZGUgaWYgdGhpcyB0ZXJtIHNoYWxs IGJlIHVzZWQgZm9yIGNvbXBsaWFuY2UNCiB0byBSRkMgMzE2OC4gSSBoYXZlIG5vIHN0cm9uZyBv cGluaW9uIG9uIHRoYXQuIEFzIGZhciBhcyBJIGNhbiBzZWUsIG1vc3QgdXNlIG9mIHRoZSB0ZXJt ID9jbGFzc2ljPyBpcyBpbiB0aGlzIGNvbnRleHQgYW5kIEkgZG9uP3QgYXNrIGZvciBjaGFuZ2Vz IGluIHRob3NlIGNhc2VzLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTb21lIHVzZSBvZiB0aGUgdGVybSA/Q2xhc3NpYyBTZXJ2 aWNlPyBtYXkgYWxzbyByZXF1aXJlIGNhcmVmdWwgcmV2aWV3IHRvIGNsZWFybHkgc2VwYXJhdGUg aXQgZnJvbSBUQ1AgU3RhbmRhcmQgYmVoYXZpb3IuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5vdGUgdGhhdCBzb21lIHVzZSBv ZiB0aGUgdGVybSA/Q2xhc3NpYyBUQ1A/IHdvdWxkIHByb2JhYmx5IGFsc28gYXBwbHkgdG8gP0Ns YXNzaWMgUVVJQz8gb25jZSB0aGUgUVVJQyBzdGFuZGFyZCBpcyBmaW5pc2hlZC4gVG8gbWUgYXMg YSBub24tbmF0aXZlIHNwZWFrZXIsIGl0IHdvdWxkIGJlIHJlYWxseSBzdHJhbmdlIHRvIHVzZSB0 aGUgdGVybSA/Y2xhc3NpYz8gaW4gdGhlIGNvbnRleHQgb2YgYSBicmFuZC1uZXcgdHJhbnNwb3J0 IHByb3RvY29sLg0KIElNSE8gaW4gdGhhdCBjYXNlIHRoZSB0ZXJtID9jbGFzc2ljPyB3b3VsZCBi ZSBldmVuIG1vcmUgY29uZnVzaW5nLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGFsc28gYWRkIHRoZSBUQ1BNIGxpc3QgaW4g Q0MgdG8gZW5zdXJlIGNvbnNpc3RlbmN5Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3M8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTWljaGFlbCAod2l0 aCBubyBoYXQpPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVm9uOiBXZXNs ZXkgRWRkeSZsdDs8YSBocmVmPSJtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbSI+bWFpbHRvOndl c0BtdGktc3lzdGVtcy5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBHZXNlbmRldDogU29ubnRh ZywgMTEuIEF1Z3VzdCAyMDE5IDA3OjA4PGJyPg0KJmd0OyAmZ3Q7IEFuOiB0c3Z3Z0BpZXRmLm9y ZyZsdDs8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciPm1haWx0bzp0c3Z3Z0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJldHJlZmY6IFt0c3Z3Z10gTDRTIHN0YXR1cyB0cmFj a2luZzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBJIGNyZWF0ZWQgdGlja2V0cyBpbiB0aGUgVFNWV0cgJnF1b3Q7dHJhYyZxdW90 OyB0b29sIGluIG9yZGVyIHRvIGhlbHAga2VlcCB0cmFjazxicj4NCiZndDsgJmd0OyBvZiB0aGUg aW5kaXZpZHVhbCB0aGluZ3MgdGhhdCBsb29rIGxpa2UgdGhleSBzaG91bGQgYmUgYWRkcmVzc2Vk IGluPGJyPg0KJmd0OyAmZ3Q7IHByb2dyZXNzaW5nIEw0UyBkb2N1bWVudCBzZXQ6PGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy90c3Z3Zy9yZXBvcnQvMT9zb3J0PXRpY2tldCZhbXA7YXNjPTEmYW1wO3BhZ2U9MSI+DQpodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy90c3Z3Zy9yZXBvcnQvMT9zb3J0PXRpY2tldCZhbXA7YXNj PTEmYW1wO3BhZ2U9MTwvYT48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEknbGwgdHJ5 IHRvIHVwZGF0ZSB0aGVzZSBiYXNlZCBvbiB0aGUgb25nb2luZyBkaXNjdXNzaW9ucywgdXBkYXRl cyw8YnI+DQomZ3Q7ICZndDsgZXRjLiwgYnV0IGl0IHdpbGwgbWFrZSBpdCB2ZXJ5IGVhc3kgaWYg eW91IGhhcHBlbiB0byBtZW50aW9uIHRoZSB0aWNrZXQ8YnI+DQomZ3Q7ICZndDsgbnVtYmVycyBv ciBzb21lIGtleSB3b3JkcyBpbiB0aHJlYWRzIGFuZCBtZXNzYWdlcywgd2hlbiBzaWduaWZpY2Fu dC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyB0Y3BtIG1haWxp bmcgbGlzdDxicj4NCiZndDsgJmd0OyB0Y3BtQGlldGYub3JnJmx0OzxhIGhyZWY9Im1haWx0bzp0 Y3BtQGlldGYub3JnIj5tYWlsdG86dGNwbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLTxicj4N CiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IEJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgdGNwbSBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7ICZndDsgdGNwbUBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGNwbTwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0 OyBSb2QgR3JpbWVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJncmltZXNAZnJlZWJzZC5vcmc8YnI+DQo8YnI+DQo8L2Rpdj4NCjwv c3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E2FE0rznt8114rzntrzd_-- From nobody Tue Nov 5 15:14:02 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 B81E812008F for ; Tue, 5 Nov 2019 15:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 QgLkrqSYMP0c for ; Tue, 5 Nov 2019 15:13:58 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 72FF8120072 for ; Tue, 5 Nov 2019 15:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: To:Subject:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SZY6yZDTVSu3Ks3r5GOM38sadrv6fmEpDWhMh4Q+8aE=; b=MkUerPa2O5ZIGK0HNJB5Lx7t5k CJ2hye2B1QczuSps9eD1gDxeGv6iUU1AC1yHRT5g/DltdfosSPLs6PVgkclFwSgGSDLYq/RgUy+X8 O7jlGdbb7nh9d/x4p6DIMfN32ITQQBvuKtQBD77wMFCTj/Yo5els6F01o5Iz3zgfRJcyJDr6VvSmv px+MiUOAlHQuZ8I2K6IeKdEz+/gC0edEe1KjN3qaih0hj6ob3D0Phu7JL4TLuOKHkXgywceikZI7D fjmmgczBvqEzTsKxZKk8zi31cJs6rXy66sVafbFMX39scIWv12SzTsOfGw0HxsZNWWrw0A5yYxh9a jttpJycg==; Received: from [31.185.128.31] (port=36342 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iS81L-0004rG-M4; Tue, 05 Nov 2019 23:13:56 +0000 From: Bob Briscoe To: carlesgo@entel.upc.edu, "CROWCROFT, Jon" Cc: tcpm IETF list Message-ID: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> Date: Tue, 5 Nov 2019 23:13:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0C20B222F5F222CA80011BBF" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] More motivating scenarios for tcpm-ack-pull 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, 05 Nov 2019 23:14:01 -0000 This is a multi-part message in MIME format. --------------0C20B222F5F222CA80011BBF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Carles, Jon, (re-sending, this time without accidentally omitting tcpm, also see couple of addenda tagged [Bob adds:]) I'm generally supportive of a mechanism to suppress delayed ACKs from the receiver (in any transport protocol including TCP). So thank you. You might want to borrow at least some of the text for additional motivating scenarios for such a facility from the first two posts on a thread for a similar facility in QuiC: https://github.com/quicwg/base-drafts/issues/1978 Also pasted at the end. Some is not relevant to your specific ack-pull scheme, 'cos it's proposing a more general facility in QUIC for the sender to the receiver alters its ACK ratio. (theoretically there are more bits available in QUIC, but this particular request has been put on hold while someone goes and finds them ;) Another motivating example (rather niche) Coincidentally, Just this morning I published a tech report that had to use the hack of overlapping a byte from the previous segment to force a quick ack: TCP Prague Fall-back on Detection of a Classic ECN AQM (the link takes you to Fig 2, which illustrates the hack) I'd rather not have to do these sorts of hacks - it really messes with the segmentation code. Middlebox traversal of bit 6 I recall that someone did a study of traversal of each of the reserved flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bob adds: I mean traversal - not the study!]. A good search engine might find it ;) More alternative approaches: 1/ At one stage, we tried to include a bit for Delayed Ack control in another protocol called Accurate ECN. We were persuaded to take it out, because it was mission creep (outside the scope of the protocol we were working on): https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4 2/ Have you considered using the Urgent Pointer in a novel way? I.e. a non-zero Urgent Pointer field, even tho the URG flag is zero. [Bob adds:] From memory, traversal was pretty good - much better than bits 4-6. But I think Windows treated it as a potential attack. I believe Fernando Gont did a study on how 'invalid' TCP header fields are handled. You could assign, say, 3 bits of the urgent pointer for a variable ack_exp that is log base 2 of the ack ratio the sender would like. Then the sender can request the receiver uses ack_ratio` = 2^ack_exp, as in the QUIC proposal below, With ack_exp = 0, you get ack_ratio = 2^0 = 1, which has the same effect as ack-pull. But you also have a more general facility for high speed machines to widen out the ack ratio. If this works, you could open up a registry for the other 13 bits. So instead of using up a precious bit, you generate 13 more ;) See: https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=5 I think there were problems with some implementations and middleboxes (bound to be). I've checked the minutes of the IETF meeting where that slide was presented , but there's no push-back in there. I suggest you delve back into the archives of the tcpm mailing list around the time of that meeting to find out if there were any show-stoppers. Cheers Bob Paste from QUIC thread: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Problem/goals: 1. Getting up to speed fast without inducing much queue is one of the main areas where latency reductions are needed (for short and long flows). The sender needs frequent ACKing during this phase in many approaches (hystart, etc). A Linux TCP receiver starts with ack_ratio 1 and uses heuristics to identify the end of the sender's slow-start (or a re-start after idle). This has ossified a certain slow-start behaviour into all TCP senders (whether Linux or not). We are trying to new sender behaviours (paced chirping being an example), but we need a way for the sender to suppress delayed ACKs. 2. At the other end of the scale, for long-running flows, many current CC approaches (e.g. BBR) use pacing not ACK-clocking so they can use very few ACKs per RTT. And fewer means less cache ejections for GRO. But the receiver doesn't know what CC the sender is using, so it doesn't know how many or few is too many or too few. 3. Some middleboxes and the majority of link technologies (e.g. DOCSIS, LTE, Satellite) thin TCP ACKs when they detect the upstream is filled with TCP ACK stream(s), which are unresponsive. Otherwise the ACKs constrain downstream throughput (and any upstream data either in the flow itself, or in others). We don't want these links to attempt to guess which are the QUIC ACKs and try to thin them. QUIC can and should do this itself. QUIC has all the machinery for the sender CC to detect ACK congestion, but not the protocol to tell the receiver to do the thinning. This protocol addition would provide a sufficient hook for hosts to unilaterally add this to their CC behaviour. Some scenarios where the sender's preferred ack_ratio changes through the connection: 1. A sender CC that wants the receiver to turn off DelAcks during flow-start (e.g. it's using hybrid slow-start as in Cubic and wants to get delay measurements more frequently) sets ack_exp=0 during flow-start (ack_ratio=1), then increases ack_exp during congestion avoidance. If it goes idle, then re-starts, it would set ack_exp=0 again. Note on heuristics: A Linux TCP receiver currently uses a heuristic to determine when the sender has exited slow-start. However, heuristics -> ossification. A Linux receiver's heuristic only works with the current pattern of slow-start. In TCP, when we tried to improve the pattern on the sender (paced chirping), the heuristic on the receiver killed us. 2. Imagine a paced sender has hardware generic receive offload (GRO), so for a long-running flow it doesn't want a high rate of QUIC ACKs that are opaque to GRO. Let's say it would prefer at least 8 ACKs per RTT. Again, it starts with ack_exp=0, but in congestion avoidance it would use: ack_ratio <= cwnd_in_packets/8 Upshot: By remote controlling the receiver, the server offloads nearly all the ACKs from large downloads, but still focuses its ACK-receiving resources on getting each client up to speed. Note that calculation of ack_ratio lends itself to fast integer arithmetic. Bob -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------0C20B222F5F222CA80011BBF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Carles, Jon, (re-sending, this time without accidentally omitting tcpm, also see couple of addenda tagged [Bob adds:])

I'm generally supportive of a mechanism to suppress delayed ACKs from the receiver (in any transport protocol including TCP). So thank you.

You might want to borrow at least some of the text for additional motivating scenarios for such a facility from the first two posts on a thread for a similar facility in QuiC:
    https://github.com/quicwg/base-drafts/issues/1978

Also pasted at the end.

Some is not relevant to your specific ack-pull scheme, 'cos it's proposing a more general facility in QUIC for the sender to the receiver alters its ACK ratio. (theoretically there are more bits available in QUIC, but this particular request has been put on hold while someone goes and finds them ;)

Another motivating example (rather niche)

Coincidentally, Just this morning I published a tech report that had to use the hack of overlapping a byte from the previous segment to force a quick ack:
    TCP Prague Fall-back on Detection of a Classic ECN AQM (the link takes you to Fig 2, which illustrates the hack)
I'd rather not have to do these sorts of hacks - it really messes with the segmentation code.

Middlebox traversal of bit 6

I recall that someone did a study of traversal of each of the reserved flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bob adds: I mean traversal - not the study!].
A good search engine might find it ;)

More alternative approaches:

1/ At one stage, we tried to include a bit for Delayed Ack control in another protocol called Accurate ECN. We were persuaded to take it out, because it was mission creep (outside the scope of the protocol we were working on):
    https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4

2/ Have you considered using the Urgent Pointer in a novel way? I.e. a non-zero Urgent Pointer field, even tho the URG flag is zero.
[Bob adds:] From memory, traversal was pretty good - much better than bits 4-6. But I think Windows treated it as a potential attack. I believe Fernando Gont did a study on how 'invalid' TCP header fields are handled.

You could assign, say, 3 bits of the urgent pointer for a variable ack_exp that is log base 2 of the ack ratio the sender would like. Then the sender can request the receiver uses ack_ratio` = 2^ack_exp, as in the QUIC proposal below,
With ack_exp = 0, you get ack_ratio = 2^0 = 1, which has the same effect as ack-pull. But you also have a more general facility for high speed machines to widen out the ack ratio.

If this works, you could open up a registry for the other 13 bits. So instead of using up a precious bit, you generate 13 more ;)

See:
    https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=5

I think there were problems with some implementations and middleboxes (bound to be). I've checked the minutes of the IETF meeting where that slide was presented, but there's no push-back in there. I suggest you delve back into the archives of the tcpm mailing list around the time of that meeting to find out if there were any show-stoppers.

Cheers



Bob


Paste from QUIC thread:
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Problem/goals:

  1. Getting up to speed fast without inducing much queue is one of the main areas where latency reductions are needed (for short and long flows). The sender needs frequent ACKing during this phase in many approaches (hystart, etc). A Linux TCP receiver starts with ack_ratio 1 and uses heuristics to identify the end of the sender's slow-start (or a re-start after idle). This has ossified a certain slow-start behaviour into all TCP senders (whether Linux or not). We are trying to new sender behaviours (paced chirping being an example), but we need a way for the sender to suppress delayed ACKs.
  2. At the other end of the scale, for long-running flows, many current CC approaches (e.g. BBR) use pacing not ACK-clocking so they can use very few ACKs per RTT. And fewer means less cache ejections for GRO. But the receiver doesn't know what CC the sender is using, so it doesn't know how many or few is too many or too few.
  3. Some middleboxes and the majority of link technologies (e.g. DOCSIS, LTE, Satellite) thin TCP ACKs when they detect the upstream is filled with TCP ACK stream(s), which are unresponsive. Otherwise the ACKs constrain downstream throughput (and any upstream data either in the flow itself, or in others). We don't want these links to attempt to guess which are the QUIC ACKs and try to thin them. QUIC can and should do this itself. QUIC has all the machinery for the sender CC to detect ACK congestion, but not the protocol to tell the receiver to do the thinning. This protocol addition would provide a sufficient hook for hosts to unilaterally add this to their CC behaviour.

Some scenarios where the sender's preferred ack_ratio changes through the connection:

  1. A sender CC that wants the receiver to turn off DelAcks during flow-start (e.g. it's using hybrid slow-start as in Cubic and wants to get delay measurements more frequently) sets ack_exp=0 during flow-start (ack_ratio=1), then increases ack_exp during congestion avoidance. If it goes idle, then re-starts, it would set ack_exp=0 again.

    Note on heuristics: A Linux TCP receiver currently uses a heuristic to determine when the sender has exited slow-start. However, heuristics -> ossification. A Linux receiver's heuristic only works with the current pattern of slow-start. In TCP, when we tried to improve the pattern on the sender (paced chirping), the heuristic on the receiver killed us.

  2. Imagine a paced sender has hardware generic receive offload (GRO), so for a long-running flow it doesn't want a high rate of QUIC ACKs that are opaque to GRO. Let's say it would prefer at least 8 ACKs per RTT. Again, it starts with ack_exp=0, but in congestion avoidance it would use:

ack_ratio <= cwnd_in_packets/8

Upshot: By remote controlling the receiver, the server offloads nearly all the ACKs from large downloads, but still focuses its ACK-receiving resources on getting each client up to speed.

Note that calculation of ack_ratio lends itself to fast integer arithmetic.







Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------0C20B222F5F222CA80011BBF-- From nobody Tue Nov 5 15:25: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 2109E1200C3 for ; Tue, 5 Nov 2019 15:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2wMSmmkP0Y-s for ; Tue, 5 Nov 2019 15:25:19 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 22CE2120072 for ; Tue, 5 Nov 2019 15:25:19 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id l14so4883170oti.10 for ; Tue, 05 Nov 2019 15:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wnhc0Sw+K3OocbjQVUPBlw+a3bNjWuXfVvTXtXEDqOI=; b=SREZdllR+irReU2F2fUCOcYQsa2hzMpArFclFPk6dYwfSod/tFHAUYm3h0Xtmfa92q /2xRJgdiozKXpTegpDw+m6zhqezvFRX3f7Y1Bu+uuudkYBv1YuivII80ijdEl+yNzOYn 5T30DXLpbFkuZUqZYiGDimrRG+oOUUeQK16HdrpAteRsxRq3GS40L6IrykwoQ2d4e6u/ ONbCCELsiKN4TMQKHR2rAqR6Z4JcEDjUDdfdbJWov1VImqK4oi//nEa5AHvN5s4AVoyD +U/dvhtedzLn3LX85YDxbsuqWVHYWkgYlhQkDAiwmKOmBXIrqJsiDCF+hda95YGSGJzg cmwg== 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; bh=wnhc0Sw+K3OocbjQVUPBlw+a3bNjWuXfVvTXtXEDqOI=; b=U872P9PXEmTsVdRBN5WYJ2fnO6ZEIrgcvobRnMqs/Qkulf08DfVwBd9ngbTDwied0x H7BnO2wGYFuyXCL2jneJvW9WxpOg8WKa+w62ofAZZUSgiyhMi55/IGsVSJHYyieWmy6O Gn4RUdfEZAbvW6k3Oga55RPGE9Mvk2RKIseC/OuqC0oA3yMlgOE+cT1grKb/hSE0ldXb eVCzvwGisC5TDG0dR8uzNyoKczkineBkaWqu2n4s/MRo2rVbjoaOtcCYkX3iQW5a8mYv OvIRHzN1Xq6V5UKe1UFD6B6pyoqUhVZeRCbGytIixXRT2HMmgOiB+x6h/Q0uQwKOj8f5 dUDg== X-Gm-Message-State: APjAAAVrEWu6l+SXherbR86JhwYbf1m1Z/klPyFjPor5H//UdqcCJzQd rdydxvJj67YwPPvyJxLa5zAmyA5wM2NIBya8N2TSwAUuf1EsZA== X-Google-Smtp-Source: APXvYqy2ccl4L+KG6zCG/nvhZ+NhPpW3FJq9MQkZpJVmlaD7BGNfaAJPPtmGerfBG1Ou7Z5qCszDb/Xt8D4wXsUPxXQ= X-Received: by 2002:a9d:6214:: with SMTP id g20mr17626624otj.302.1572996317823; Tue, 05 Nov 2019 15:25:17 -0800 (PST) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> In-Reply-To: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> From: Neal Cardwell Date: Tue, 5 Nov 2019 18:25:01 -0500 Message-ID: To: Vidhi Goel Cc: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c24b130596a1be9f" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= 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, 05 Nov 2019 23:25:21 -0000 --000000000000c24b130596a1be9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2019 at 5:08 PM Vidhi Goel wrote: > Hi All, > > RFC 3465 suggests to increase the congestion window by the number of > previously unacknowledged bytes ACKed by each ACK limiting the increase t= o > L (L =3D 2MSS or 1MSS in certain conditions). The limiting factor L helps= to > avoid the large bursts that could occur due to stretch ACKs, ACK loss or > compressed ACKs (GRO/GSO). > > But, when I looked at Linux source code, it implements one aspect of ABC > (byte counting to defend from ACK attacks) but doesn=E2=80=99t =E2=80=9C= cap=E2=80=9D the increase > to L. > https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_cong..c#L385 > > > This is a bit confusing. How should we address this discrepancy? > The differences between the Linux code and the ABC RFC ( https://tools.ietf.org/html/rfc3465 ) are intentional. The Linux TCP code in this area is largely from: 9f9843a751d0 tcp: properly handle stretch acks in slow start 95224ac1801c Merge branch 'tcp_stretch_acks' d6b1a8a92a14 tcp: fix timing issue in CUBIC slope calculation 9cd981dcf174 tcp: fix stretch ACK bugs in CUBIC c22bdca94782 tcp: fix stretch ACK bugs in Reno 814d488c6126 tcp: fix the timid additive increase on stretch ACKs e73ebb0881ea tcp: stretch ACK fixes prep That code is based on experience at Google, both with internal traffic and google.com and YouTube traffic. Experience was showing that preventing the full use of ACKs in growing the cwnd in slow start and CUBIC's rapid growth phase causes anemic growth in real-world situations. The basic principle in the Linux code is that the sender should use the ACKs to learn about the capacity of the path (both in volumetric and rate dimensions), and should not ignore that information. This allows the sender to quickly grow and achieve high throughput, even in the presence of stretch ACKs, which are pervasive, due to TSO/GSO, GRO/LRO, etc. Considering bursts is important, but that can be tackled as an orthogonal issue. Bursts are avoided in the Linux TCP ecosystem by the combination of TSO autosizing, pacing, TSQ, and fair queueing. Here is a summary of the Linux TCP design in this area: https://netdevconf.info/1.2/papers/bbr-netdev-1.2.new.new.pdf best, neal --000000000000c24b130596a1be9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 5, 2019 at 5:08 PM Vidhi = Goel <vidhi_goel=3D40apple= .com@dmarc.ietf.org> wrote:
Hi All,

RFC 3465 suggests to increase the congestion window by= the number of previously unacknowledged bytes ACKed by each ACK limiting t= he increase to L (L =3D 2MSS or 1MSS in certain conditions). The limiting f= actor L helps to avoid the large bursts that could occur due to stretch ACK= s, ACK loss or compressed ACKs (GRO/GSO).

But, when I looked = at Linux source code, it implements one aspect of ABC (byte counting to def= end from ACK attacks) but doesn=E2=80=99t=C2=A0 =E2=80=9Ccap=E2=80=9D the i= ncrease to L.=C2=A0
=C2=A0https://g= ithub.com/torvalds/linux/blob/master/net/ipv4/tcp_cong..c#L385

This is a bit confusing. How should we address this discrepanc= y?

The differences between the = Linux code and the ABC RFC=C2=A0 (=C2=A0https://tools.ietf.org/html/rfc3465=C2=A0) are intentional= . The Linux TCP code in this area is largely from:

9f9843a751d0 tcp: properly handle stretch acks in slow start
95224ac1801c Merge branch 'tcp_stretch_acks'
d6b1a8a92a14 tcp: = fix timing issue in CUBIC slope calculation
9cd981dcf174 tcp: fix stretc= h ACK bugs in CUBIC
c22bdca94782 tcp: fix stretch ACK bugs in Reno
81= 4d488c6126 tcp: fix the timid additive increase on stretch ACKs
e73ebb08= 81ea tcp: stretch ACK fixes prep

That code is = based on experience at Google, both with internal traffic and google.com and YouTube traffic. Experience was showing= that preventing the full use of ACKs in growing the cwnd in slow start and= CUBIC's rapid growth phase causes anemic growth in real-world situatio= ns.

The basic principle in the Linux code is that = the sender should use the ACKs to learn about the capacity of the path (bot= h in volumetric and rate dimensions), and should not ignore that informatio= n. This allows the sender to quickly grow and achieve high throughput,=C2= =A0even in the presence of stretch ACKs, which are pervasive, due to TSO/GS= O, GRO/LRO, etc.

Considering bursts is important, = but that can be tackled as an orthogonal issue. Bursts are avoided in the L= inux TCP ecosystem by the combination of TSO autosizing, pacing, TSQ, and f= air queueing.

Here is a summary of the Linux TCP d= esign in this area:

best,
ne= al

--000000000000c24b130596a1be9f-- From nobody Tue Nov 5 16:22:53 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 9D0C91200E9; Tue, 5 Nov 2019 16:22:51 -0800 (PST) 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, HTML_MESSAGE=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=bobbriscoe.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 RR8HeAo2hQTA; Tue, 5 Nov 2019 16:22:48 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 8E0C91200C3; Tue, 5 Nov 2019 16:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=vmEYIMnGl6QDbyteDcwX7GZOGryuJ0Uc2f/tzl2WDVo=; b=ntEeLG+SvIiE5vUcxxiQybW9y PJqLJpfGP5+hzD+tE5pOmPVt2O4zsFjvD3ppVZiTAHhIi3w+vUdy+L3qzVg5cp4s4nNm/w1lro0XC gompwKrpsuz6K/MPhlEEFIpS2y+H3lKy3Tune8QvOmeJZpe770x1sX4jWvtisDymrmZsEkV18W4Lv WPAeLNEFX1k0MdVjKvMtNO2b3pVm7Wf1BnPDunIUgigqqnShehj4R0BOpDcbPIOXAw9lUOZUhflGl IJ6E58Cclm0XOeuuwVOWcu+JZZ1M4Dtk82NnU2EsifIyZWnpI5Hoq+O8+l8ux103mji6rDudbDw+d GUo2KDxyw==; Received: from [31.185.128.31] (port=36474 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iS95x-00062o-4v; Wed, 06 Nov 2019 00:22:45 +0000 To: "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Cc: Wesley Eddy , "tsvwg@ietf.org" , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> Date: Wed, 6 Nov 2019 00:22:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------42BB457D41C062F60709E495" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net 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: Wed, 06 Nov 2019 00:22:52 -0000 This is a multi-part message in MIME format. --------------42BB457D41C062F60709E495 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Michael, Rod, Altho non-L4S is a reasonable idea, I think it has more of a negative connotation than classic. For instance, consider describing Android phones as non-iPhones. Also, in the ecn-l4s-id draft, we introduce the possibility that some operators might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same queue as L4S traffic (and we say that in this case the queue would be called the Low Latency queue). This shows that the term non-L4S is not a good choice for a name, because the words it is made from already give it a meaning of its own that conflicts with the definition you want it to have in certain contexts. For example, if you did define the name "non-iPhone" to mean phones such as Android, Windows, etc, then you would expect the phrase "non-iPhone knock-off products" to mean "fake Android and Windows phones". However the constituent elements "non" and "iPhone" already have a meaning of their own, so in the context of this phrase, it means "fake iPhones", which is the opposite of what you wanted. The term Classic for the non-L4S service, its queue, its traffic, its congestion control, etc. is defined in the terminology section of the drafts, so I think it's best to live with this - it's not a significant problem. Indeed, it has become widely used and widely understood since 2015, and changing it to non-L4S now would cause unnecessary confusion. Bob On 04/11/2019 19:21, Scharf, Michael wrote: > > I agree. non-L4S may be even better. > > Michael > > *Von: *Rodney W. Grimes > *Gesendet: *Montag, 4. November 2019 20:17 > *An: *Scharf, Michael > *Cc: *Bob Briscoe ; Wesley Eddy > ; tsvwg@ietf.org ; > tcpm@ietf.org > *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking > > > You can e.g. use ?non-L4S-enabled TCP?. > > > > Terminology does matter to me given that I strongly disagree to any > use of ?marketing language? when it comes to TCP. > > My concern here of use of terms like, legacy, classic, new, old > is that they are pretty much all of the relative from and thus > ambiguous over time. > > newReno is new only relative to Reno, that is fairly clear, > but if I said newTCP or oldTCP with what frame should the > reference be evaluated. > > I believe in the case of L4S the time invariant term would be, > as Michael suggests above, "non-L4S". Note that enabled > for me is a noise word in this context, and TCP may or may > not be needed depending on context, but for literal replacement > of Legacy or Classic "non-L4S" is invariant over time. > > Rod > > > Michael > > > > > > Von: Bob Briscoe > > Gesendet: Montag, 4. November 2019 19:09 > > An: Scharf, Michael; Wesley > Eddy; tsvwg@ietf.org > > Cc: tcpm@ietf.org > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > > > Michael, > > > > Previously, I have been told not to use the term standard for RFCs > that are not standards. RFC5681 is 'only' a draft standard. This is > why, in the IETF at least, I avoid using the term "standard TCP > congestion control". I generally call it Reno when referring to the > congestion control. > > > > I have never, to my knowledge, used the term classic TCP, or classic > TCP congestion control. > > > > And I rarely use the term legacy, and if I do I'm happy to have > alternatives suggested. > > > > I've checked the L4S drafts, and there is one phrase that I shall > leave in ecn-l4s-id: "the traditional TCP Reno additive increase", > because this is correctly used to mean the traditional increase (in > numerous AIMD CCs), not traditional TCP. There was one other > occurrence of "traditional TCP senders" in a whole para in an appendix > that has just been deleted anyway. And in aqm-dualq-coupled there was > one "legacy TCP flows" (changed to "Classic traffic" now in my local > copy, using the defined term in all the L4S drafts). > > > > l4s-arch is getting a complete make-over for terminology, so I will > check that next. > > > > inline... > > > > > > On 23/08/2019 15:01, Scharf, Michael wrote: > > > > Hi Wes, > > > > > > > > I?d 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-hDvWO3I5MudwpNkKyHY > , I object to the terms ?traditional TCP? and also ?classic TCP? or > ?legacy? TCP when referring to a TCP implementation according to IETF > standards-track RFCs. > > > > > > > > To me as a non-native native speaker, all these terms have a > negative connotation. I also think this language is typical to > marketing material. > > > > You're entitled to your opinion but, as a native speaker, I don't > think 'classic' or 'traditional' are particularly pejorative, tho they > can be when used in a context that intends them to be. They also mean > "stood the test of time". I find 'legacy' has a connotation of > marketing-speak, but it's not that bad. > > > > This is an enduring problem when trying to improve on the good work > that other people have done before you (which is the context of > everything we are doing). We need a word that distinguishes the old > from the new, but we don't want to completely trash the thing that has > already been successful, but had its day. > > > > Nonetheless, it is also important not to be too precious about past > work. We all recognize that Reno TCP is unscalable and has problems. > IMO, it is OK to describe technologies that have had their time with > negative connotations. Indeed, you have been an author (with me) of an > RFC on open issues in congestion control. > > > > I notice you haven't suggested an alternative term for "the thing(s) > we are trying to improve on". Not surprising, because it's difficult. > > > > When we (the L4S developers) were first looking for a term for the > non-L4S queue and the non-L4S service, we didn't want to use 'legacy' > for the above reasons, but we did want to imply pre-existing, so we > decided on 'classic', which we all felt had a generally neutral > connotation, but said what we meant. > > > > Finally, I do not want this issue to take up any time that would > detract from technical issues. > > > > > > > > Bob > > > > > > > > > > My prefered term when referring to TCP according to standards-track > specification 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 TCP standard congestion control (?Reno?). As of today, this is > the TCP congestion control 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 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 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 and I don?t ask for changes > in those cases. > > > > > > > > Some use of the term ?Classic Service? may also require careful > review to clearly 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 speaker, it would be really strange to use the term > ?classic? in the context of a brand-new transport protocol. IMHO in > that case the term ?classic? 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=ticket&asc=1&page=1 > > > > 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. > > > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > -- > Rod Grimes rgrimes@freebsd.org -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------42BB457D41C062F60709E495 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael, Rod,

Altho non-L4S is a reasonable idea, I think it has more of a negative connotation than classic. For instance, consider describing Android phones as non-iPhones.

Also, in the ecn-l4s-id draft, we introduce the possibility that some operators might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same queue as L4S traffic (and we say that in this case the queue would be called the Low Latency queue). This shows that the term non-L4S is not a good choice for a name, because the words it is made from already give it a meaning of its own that conflicts with the definition you want it to have in certain contexts.

For example, if you did define the name "non-iPhone" to mean phones such as Android, Windows, etc, then you would expect the phrase "non-iPhone knock-off products" to mean "fake Android and Windows phones". However the constituent elements "non" and "iPhone" already have a meaning of their own, so in the context of this phrase, it means "fake iPhones", which is the opposite of what you wanted.

The term Classic for the non-L4S service, its queue, its traffic, its congestion control, etc. is defined in the terminology section of the drafts, so I think it's best to live with this - it's not a significant problem. Indeed, it has become widely used and widely understood since 2015, and changing it to non-L4S now would cause unnecessary confusion.



Bob



On 04/11/2019 19:21, Scharf, Michael wrote:

I agree. non-L4S may be even better.

Michael

Von: Rodney W. Grimes
Gesendet: Montag, 4. November 2019 20:17
An: Scharf, Michael
Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

> You can e.g. use ?non-L4S-enabled TCP?.
>
> Terminology does matter to me given that I strongly disagree to any use of ?marketing language? when it comes to TCP.

My concern here of use of terms like, legacy, classic, new, old
is that they are pretty much all of the relative from and thus
ambiguous over time.

newReno is new only relative to Reno, that is fairly clear,
but if I said newTCP or oldTCP with what frame should the
reference be evaluated.

I believe in the case of L4S the time invariant term would be,
as Michael suggests above, "non-L4S". Note that enabled
for me is a noise word in this context, and TCP may or may
not be needed depending on context, but for literal replacement
of Legacy or Classic "non-L4S" is invariant over time.

Rod

> Michael
>
>
> Von: Bob Briscoe<mailto:ietf@bobbriscoe.net>
> Gesendet: Montag, 4. November 2019 19:09
> An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley Eddy<mailto:wes@mti-systems.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
> Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael,
>
> Previously, I have been told not to use the term standard for RFCs that are not standards. RFC5681 is 'only' a draft standard. This is why, in the IETF at least, I avoid using the term "standard TCP congestion control". I generally call it Reno when referring to the congestion control.
>
> I have never, to my knowledge, used the term classic TCP, or classic TCP congestion control.
>
> And I rarely use the term legacy, and if I do I'm happy to have alternatives suggested.
>
> I've checked the L4S drafts, and there is one phrase that I shall leave in ecn-l4s-id: "the traditional TCP Reno additive increase", because this is correctly used to mean the traditional increase (in numerous AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in an appendix that has just been deleted anyway. And in aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic traffic" now in my local copy, using the defined term in all the L4S drafts).
>
> l4s-arch is getting a complete make-over for terminology, so I will check that next.
>
> inline...
>
>
> On 23/08/2019 15:01, Scharf, Michael wrote:
>
> Hi Wes,
>
>
>
> I?d 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-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?classic TCP? or ?legacy? TCP when referring to a TCP implementation according to IETF standards-track RFCs.
>
>
>
> To me as a non-native native speaker, all these terms have a negative connotation. I also think this language is typical to marketing material.
>
> You're entitled to your opinion but, as a native speaker, I don't think 'classic' or 'traditional' are particularly pejorative, tho they can be when used in a context that intends them to be. They also mean "stood the test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad.
>
> This is an enduring problem when trying to improve on the good work that other people have done before you (which is the context of everything we are doing). We need a word that distinguishes the old from the new, but we don't want to completely trash the thing that has already been successful, but had its day.
>
> Nonetheless, it is also important not to be too precious about past work. We all recognize that Reno TCP is unscalable and has problems. IMO, it is OK to describe technologies that have had their time with negative connotations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control.
>
> I notice you haven't suggested an alternative term for "the thing(s) we are trying to improve on". Not surprising, because it's difficult.
>
> When we (the L4S developers) were first looking for a term for the non-L4S queue and the non-L4S service, we didn't want to use 'legacy' for the above reasons, but we did want to imply pre-existing, so we decided on 'classic', which we all felt had a generally neutral connotation, but said what we meant.
>
> Finally, I do not want this issue to take up any time that would detract from technical issues.
>
>
>
> Bob
>
>
>
>
> My prefered term when referring to TCP according to standards-track specification 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 TCP standard congestion control (?Reno?). As of today, this is the TCP congestion control 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 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 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 and I don?t ask for changes in those cases.
>
>
>
> Some use of the term ?Classic Service? may also require careful review to clearly 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 speaker, it would be really strange to use the term ?classic? in the context of a brand-new transport protocol. IMHO in that case the term ?classic? would be even more confusing.
>
>
>
> I also add the TCPM list in CC to ensure consistency.
>
>
>
> Thanks
>
>
>
> Michael (with no hat)
>
>
>
>
>
> Von: Wesley Eddy<mailto:wes@mti-systems.com>
> Gesendet: Sonntag, 11. August 2019 07:08
> An: tsvwg@ietf.org<mailto: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=ticket&asc=1&page=1
>
> 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.
>
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org<mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe http://bobbriscoe.net/

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

--
Rod Grimes rgrimes@freebsd.org
 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------42BB457D41C062F60709E495-- From nobody Tue Nov 5 22:12:53 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 06E92120809; Tue, 5 Nov 2019 22:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 lGBObu3QLSdm; Tue, 5 Nov 2019 22:12:46 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140078.outbound.protection.outlook.com [40.107.14.78]) (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 6B87012002F; Tue, 5 Nov 2019 22:12:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KqKHDeB98DvRvVkLrMP9yW9ubkI5hfwvwm8MVcx9HZ2bgF0V0nwmFOnBhj+ugYOcK0KoyQuBYrHfC7liivPyTi1hRDhQRzHQweh3ZXXQT4WGuCMf4XPptXZPwqe/Rxw8Qkqwy4EjdHgWPp72tcFMzNLqcV4/EGymKxK+4gzum7sX/TOB/777tiWtBcFZ0kdL6Kz8ouSBX7YhBKdUKFUlSP1McpgKRzARE6wVttwSh9t9sNxDB3FM1tPXTpiOm7gEd6KkamlQ2XzaavjDC+zZeIRLKlBgbeluTmMnU2mTtk0+LB8jjav+m0hRJlKjW+zYwDnsacCIRlB6IYFnYLKELg== 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=IV3kJZ27Vsc8pdTxc0ENk6HDbt90+QUceBFa06NfgPg=; b=WgTUB+mvWBh+J+6D75ucpC3i0sedT5A+FTU16KjTgHOXa+fAMUHTsLYvlAgM+JPSZpjRxaOLskSXDm6EJO34nisYauAzfcWBd+ly7z3+beDQVNjC5B6jNO1hA9GQjMDMZ9PjAHo1/8BHK0/TmyZXYmxJT77dVFwNIU6aIfGo+BB9yqVnPnla1uuL8BKzmFBMZRuybx1fugOT7na4MOYnJRAvzD90egT/JVtxHp0fen7xm2T0YqBzEhceFm9PQQnXA6XMzSlNT2GAl1BZN0fhxYGf4wAzXbn34s+AqOFlxzyoOG5qspZvPqTNlPVvmt0kZBqAFc/RbCo6puSZipNBOA== 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=IV3kJZ27Vsc8pdTxc0ENk6HDbt90+QUceBFa06NfgPg=; b=L5PWmveEE7ne0RgSQ3eZNAikC8+5/HMGk0EQuncBj0G6M2TJ9DX3CauSaJX6BVIe7OVLje2sWD8XnjatVqEL1MHXjPzbE6ks2Jj6PRoetgvHgn7dK13xTu7O3klwnC2j+7F++iHltWI73zFDFxTgSBuO8SPZqH6XTYLzj5OU/ug= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB4427.eurprd07.prod.outlook.com (20.176.161.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 06:12:40 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 06:12:40 +0000 From: Ingemar Johansson S To: "Michael.Scharf@hs-esslingen.de" , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net> CC: "wes@mti-systems.com" , "tcpm@ietf.org" , "tsvwg@ietf.org" , Ingemar Johansson S Thread-Topic: [tcpm] [tsvwg] L4S status tracking Thread-Index: AdWUaDJcxBPbLfJiSNergXaonh87Bw== Date: Wed, 6 Nov 2019 06:12:39 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [88.131.223.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 95c11215-87d5-409b-61d3-08d762805402 x-ms-traffictypediagnostic: HE1PR07MB4427:|HE1PR07MB4427: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(39860400002)(396003)(366004)(199004)(51444003)(189003)(486006)(30864003)(66946007)(7736002)(81156014)(305945005)(81166006)(6436002)(8676002)(55016002)(66446008)(64756008)(8936002)(9686003)(6306002)(26005)(25786009)(76116006)(66066001)(66556008)(186003)(66476007)(66616009)(478600001)(966005)(99936001)(52536014)(5660300002)(14454004)(5024004)(6116002)(33656002)(19627235002)(229853002)(74316002)(3846002)(256004)(107886003)(53546011)(6246003)(54906003)(102836004)(2501003)(6506007)(316002)(110136005)(2906002)(4326008)(7696005)(71190400001)(71200400001)(86362001)(14444005)(99286004)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4427; H:HE1PR07MB4425.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: BCL:0; x-microsoft-antispam-message-info: pJlPefNxPYOxKY1ljZrsL4Kl1iBG3icnKYzIXga6cZmZQm326Y/ptpjhAwxkgEQ7/e6emB7tSu/nAoM9UO1Qha7BWDRIx+5CuiuKALdtO/TomZpmfNW8HQWwqsZ2KkaTrL7234DsanmnOLOihi4qcdNoKNqk2Iz1KQ7riHKuQXOJMIvAcnFTxU7A6nGrLcQlMjPgIZCSU9L6Ed4pCU6WOwvjeGWcPdvwLeg3+BIv2TWNqm575FJ7YwxtN4oYP+cLuFmiHl2/OUeMRN+k5dXvUvxVVx54H4zI2jocqvAyrdhJjyIzBj6I7iIUvOl5B8g0h5g/ismgAjzGRljkW2v2RHfrlpGb8uQRGv0cNowwguqwNXK9GcaT/bPnO2wDHAG2FzOiPsUUctHAtzgafxo53fkjurVR9JGYyHo7nAmCBmUQUsDsxOtQl4z+0oSc/lHy Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0109_01D59471.9227B9F0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95c11215-87d5-409b-61d3-08d762805402 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 06:12:39.9153 (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: oUl595c4kTk4nNRGKCYQ7ooHaNYnSC5UYhCWHCYurCFG+E8M73QsHRiwe9mJvRo0J5lKMlCc8gidYqaYU6pVca6dzCZKFjJdpoA3I5tnYQHPUgWsFcIcUI+yLC3dBr1q X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4427 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: Wed, 06 Nov 2019 06:12:51 -0000 ------=_NextPart_000_0109_01D59471.9227B9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi I would prefer that the term "Classic" is kept. L4S is not anymore an IETF only matter. Work is ongoing to get support for L4S in 3GPP for 5G and the input papers there use the term classic. It is of course too late for changing classic to something else, but then it is appreciated that It is something that the group can agree on and I don't see that we are there, therefore it is better to stick to "classic". And to me the term "classic" does not sound negative. /Ingemar > Message: 3 > Date: Wed, 6 Nov 2019 00:22:44 +0000 > From: Bob Briscoe > To: "Scharf, Michael" , "Rodney W. > Grimes" <4bone@gndrsh.dnsmgr.net> > Cc: Wesley Eddy , "tsvwg@ietf.org" > , "tcpm@ietf.org" > Subject: Re: [tcpm] [tsvwg] L4S status tracking > Message-ID: <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Michael, Rod, > > Altho non-L4S is a reasonable idea, I think it has more of a negative connotation > than classic. For instance, consider describing Android phones as non-iPhones. > > Also, in the ecn-l4s-id draft, we introduce the possibility that some operators > might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same queue as > L4S traffic (and we say that in this case the queue would be called the Low > Latency queue). This shows that the term non-L4S is not a good choice for a > name, because the words it is made from already give it a meaning of its own > that conflicts with the definition you want it to have in certain contexts. > > For example, if you did define the name "non-iPhone" to mean phones such as > Android, Windows, etc, then you would expect the phrase "non-iPhone knock- > off products" to mean "fake Android and Windows phones". However the > constituent elements "non" and "iPhone" already have a meaning of their own, > so in the context of this phrase, it means "fake iPhones", which is the opposite > of what you wanted. > > The term Classic for the non-L4S service, its queue, its traffic, its congestion > control, etc. is defined in the terminology section of the drafts, so I think it's > best to live with this - it's not a significant problem. Indeed, it has become widely > used and widely understood since 2015, and changing it to non-L4S now would > cause unnecessary confusion. > > > > Bob > > > > On 04/11/2019 19:21, Scharf, Michael wrote: > > > > I agree. ?non-L4S? may be even better. > > > > Michael > > > > *Von: *Rodney W. Grimes > > *Gesendet: *Montag, 4. November 2019 20:17 > > *An: *Scharf, Michael > > *Cc: *Bob Briscoe ; Wesley Eddy > > ; tsvwg@ietf.org ; > > tcpm@ietf.org > > *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking > > > > > You can e.g. use ?non-L4S-enabled TCP?. > > > > > > Terminology does matter to me given that I strongly disagree to any > > use of ?marketing language? when it comes to TCP. > > > > My concern here of use of terms like, legacy, classic, new, old is > > that they are pretty much all of the relative from and thus ambiguous > > over time. > > > > newReno is new only relative to Reno, that is fairly clear, but if I > > said newTCP or oldTCP with what frame should the reference be > > evaluated. > > > > I believe in the case of L4S the time invariant term would be, as > > Michael suggests above, "non-L4S".?? Note that enabled for me is a > > noise word in this context, and TCP may or may not be needed depending > > on context, but for literal replacement of Legacy or Classic "non-L4S" > > is invariant over time. > > > > Rod > > > > > Michael > > > > > > > > > Von: Bob Briscoe > > > Gesendet: Montag, 4. November 2019 19:09 > > > An: Scharf, Michael; Wesley > > Eddy; > > tsvwg@ietf.org > > > Cc: tcpm@ietf.org > > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > > > > > Michael, > > > > > > Previously, I have been told not to use the term standard for RFCs > > that are not standards. RFC5681 is 'only' a draft standard. This is > > why, in the IETF at least, I avoid using the term "standard TCP > > congestion control". I generally call it Reno when referring to the > > congestion control. > > > > > > I have never, to my knowledge, used the term classic TCP, or classic > > TCP congestion control. > > > > > > And I rarely use the term legacy, and if I do I'm happy to have > > alternatives suggested. > > > > > > I've checked the L4S drafts, and there is one phrase that I shall > > leave in ecn-l4s-id: "the traditional TCP Reno additive increase", > > because this is correctly used to mean the traditional increase (in > > numerous AIMD CCs), not traditional TCP. There was one other > > occurrence of "traditional TCP senders" in a whole para in an appendix > > that has just been deleted anyway. And in aqm-dualq-coupled there was > > one "legacy TCP flows" (changed to "Classic traffic" now in my local > > copy, using the defined term in all the L4S drafts). > > > > > > l4s-arch is getting a complete make-over for terminology, so I will > > check that next. > > > > > > inline... > > > > > > > > > On 23/08/2019 15:01, Scharf, Michael wrote: > > > > > > Hi Wes, > > > > > > > > > > > > I?d 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- > hDvWO3I5MudwpNkKyH > > Y > KyHY> , I object to the terms ?traditional TCP? and also ?classic TCP? > > or ?legacy? TCP when referring to a TCP implementation according to > > IETF standards-track RFCs. > > > > > > > > > > > > To me as a non-native native speaker, all these terms have a > > negative connotation. I also think this language is typical to > > marketing material. > > > > > > You're entitled to your opinion but, as a native speaker, I don't > > think 'classic' or 'traditional' are particularly pejorative, tho they > > can be when used in a context that intends them to be. They also mean > > "stood the test of time". I find 'legacy' has a connotation of > > marketing-speak, but it's not that bad. > > > > > > This is an enduring problem when trying to improve on the good work > > that other people have done before you (which is the context of > > everything we are doing). We need a word that distinguishes the old > > from the new, but we don't want to completely trash the thing that has > > already been successful, but had its day. > > > > > > Nonetheless, it is also important not to be too precious about past > > work. We all recognize that Reno TCP is unscalable and has problems. > > IMO, it is OK to describe technologies that have had their time with > > negative connotations. Indeed, you have been an author (with me) of an > > RFC on open issues in congestion control. > > > > > > I notice you haven't suggested an alternative term for "the thing(s) > > we are trying to improve on". Not surprising, because it's difficult. > > > > > > When we (the L4S developers) were first looking for a term for the > > non-L4S queue and the non-L4S service, we didn't want to use 'legacy' > > for the above reasons, but we did want to imply pre-existing, so we > > decided on 'classic', which we all felt had a generally neutral > > connotation, but said what we meant. > > > > > > Finally, I do not want this issue to take up any time that would > > detract from technical issues. > > > > > > > > > > > > Bob > > > > > > > > > > > > > > > My prefered term when referring to TCP according to standards-track > > specification 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 TCP standard congestion control (?Reno?). As of today, this is > > the TCP congestion control 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 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 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 and I don?t ask for changes > > in those cases. > > > > > > > > > > > > Some use of the term ?Classic Service? may also require careful > > review to clearly 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 speaker, it would be really strange to use the term > > ?classic? in the context of a brand-new transport protocol. IMHO in > > that case the term ?classic? 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=ticket&asc=1&page=1 > > > > > > 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. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > > > > > -- > > > > ________________________________________________________________ > > > Bob Briscoe > > > https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-864 > > > 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2- > 9ebedff802e > > > 0&u=http%3A%2F%2Fbobbriscoe.net%2F > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > > Rod Grimes rgrimes@freebsd.org > > -- > ________________________________________________________________ > Bob Briscoe https://protect2.fireeye.com/v1/url?k=861241a8- > dac64d59-86120133-864685b2085c-16120a27ab4a751a&q=1&e=bf49c0f0- > 380b-42d4-93a2-9ebedff802e0&u=http%3A%2F%2Fbobbriscoe.net%2F > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > fd1/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > ------------------------------ > > End of tcpm Digest, Vol 187, Issue 15 > ************************************* ------=_NextPart_000_0109_01D59471.9227B9F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTExMDYwNjEyMzhaMCMGCSqGSIb3DQEJBDEWBBSqxznsgTyhqHKVweJA SYvhKXz0rTBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAESFXf1mOn6GCP3eFluPxQbziu8ssn3dyqCnUsiI Jwt9+8NITovEtQbEPHBO1nl5B5D8E0ovf4xAR/JYzF0jfdKKxmglObbNVy6fC9QGkb0FNSEdOVnt u3i0ftVikadqNXYTZMo/ZSqNh5t0KXvumd0f6/5Y+TOtTk4W59ggiS1CLdT5zPdkwHY27LNX4Vlv HyDhKcUcgF8k2LzbS9gjl4whKptIXmKOeVgehRLOKJYNsMOYyMDFQGpOIhbnNAomhKKgIwYwLUh8 WqE8lT55gtPOBcchu4W/N85j7wej76UymWSpKaoaFE9+K98BAnZ3LgJ7fJGDhiEt4mdQaLGLv+8A AAAAAAA= ------=_NextPart_000_0109_01D59471.9227B9F0-- From nobody Tue Nov 5 23:08: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 D489E120BB1; Tue, 5 Nov 2019 23:08:16 -0800 (PST) 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=unavailable 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 gXaAER6Nm8tt; Tue, 5 Nov 2019 23:08:14 -0800 (PST) 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 32B8B120B96; Tue, 5 Nov 2019 23:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573024063; bh=MazvyFl9h/uhcv0wfQt6sCvLserVjR7k5YYQfuCxF7A=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=VZFDvqZXWPwwj7vYLzrQ2mziZlrwxWGITE6GUhCzXHGeb/eLyft0En9tzPFJOoIfN gvVujLkUc1PXDZQlvATl9TWG8HJmRCbpWCfpv4iaKC3Rn2DuXNohg+dYySN/SM+v63 Q2NnK62xl+2i24zhFlB4zRejLGQOkqh9XXm5dASI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.198.62.136] ([80.187.112.39]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N6KUT-1hr9Ne17iz-016h68; Wed, 06 Nov 2019 08:07:43 +0100 Date: Wed, 06 Nov 2019 08:07:30 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Ingemar Johansson S , "Michael.Scharf@hs-esslingen.de" , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net> CC: Ingemar Johansson S , "tcpm@ietf.org" , "tsvwg@ietf.org" From: Sebastian Moeller Message-ID: X-Provags-ID: V03:K1:OaFDic1dBzEfk6BRr6Pjki1IxoZdxcEISAlXT6fgBoOaDRJafu4 ICvNieaCNlKvU2W0go5Vi/RLjw8kmXC90Ux5IO+6RP8lNhfFOfO6Se49j19nVjClTH6YIIC R3x4ZlPxBXtJjMPNyVbM3nKyHD20UzK9g+c2cwOfkLeRMi2Kvwpdhx3PElL+ccpu53IZBV0 5WFdxz4PeilRMP/iuzqkA== X-UI-Out-Filterresults: notjunk:1;V03:K0:zivvCpTKBmQ=:X+oTnwGn9/eZ9mPAPMeVFo LuAiPrik4vWANgqga2gBTY2zJons6TQpF0VIsJOoZprJacnWFd5ucfdO6VY5iSYrmqSP5whfI EWixlduhrfwNoj7DqdOjDuOaDjCMUjk9LUE2TepKJ9mkh/BPw1K/UZaqDle8B5eP/tgpmsRiy I+9+x7RjCExe1qtWqBkYoDx8lDtT++IZAmhpieDo9vaHycHxbFOKlD9w0pTUsHvYEqhPnZP0J ydnuWG3KpWOqiajey33GZGtknjuy94OXWTijq3Gjf8O0Dc3Bgph6RZKPUgLsHCvQUnNyTS4Dd r0kIgixVy9oPbG5oNTokNfdnXivDsS7D82dRdl3Uh2+yyyjDomL+i5sEQTRcUscawJGrIYsnD ApTafmFskIESc/d0MuFstGc6s81FmLy4aenXFqgxqplpQwCso7UBIg7KShVdVee5EQKBzlwQw leXn0L4S6IVKi+lltf2llPcrBoCB2RrrK7JnyNi8tdoLuIFIpKxtr/nYOls/HcmFv1yNC0RpT RydismcCX9veS6OMq7OdKtIfhfxVjfGBEfzdGha8+DYlH5UYuqgBkah4U8+wk6KoATpeUrSVL C+vnXmyRJtA0Z0XNL4tz4VgBBEOARwvqdc7FhPoc/AJoU/0WM0WqfGuHTboTPwCOPqE4n3aZz 4xuwhrwNskizM49HLa+MFM11yGPyAmjqw2ufHqVZtm3QszZMY2TaRuHIgsDu/TNeulmEVKU+a Kr+md00hB9qZj4uAealsp8XMvj26io0krU4bs5pWJT7Q8KXdMfB3OfGKMXz6vXG2BYi9mFUW4 9Lqy1CWXAySQWrkjSAupHiwOfhvdN04JulJTC0xAKxBSK1ywTE7w/HtqwnRI9hTXzKQUmato+ 45Gx/lC7l1yQ0gZwaAGor25oXfjLDraLmXP7eU4OeDkEazBOpLiIz4Em0Mu6uzxLWXvgM8/9H AdgtLbFjR7q9qwZvGljphIBiBrGLpc6BtW5nXBY6jLXfudBBWko/LNHCLcBwvFWgba39JQP6g 8UV5R870Uwd9xUqB/IoPO/01rkmQvyDgLbefM3E6TqBD58zmvqohWDIxK20UWxXZjviJoRWgy vz+1+ur7fnBtoR8C2Gz7KpR2SPlgyvUgZvS7sq+gCg0+PfXU3abnRub3jwVIb28JIIjMbzH7L eA6BnzsHiJc1B9+8ytmYSpzJIn4IS/ecRyKNx+Q60yGAao4DVS/jK4D0tczGewHS8Vowmee9C uQ5puo/nz3kbZMqkB3e5m4fodmW2RXFoens9RuUkWT4t0kIS5r24VGzzjN1s= 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: Wed, 06 Nov 2019 07:08:17 -0000 Hi Ingmar, IMHO this is a slippery slope argument=2E Because if minor changes to the = naming are "impossible" how will changed to the underlying concepts and met= hods be acceptable to you=2E Because surely these other organizations alrea= dy committed to what is proposed to the IETF as an experiment? My gripe with the classic moniker is that this term is not outcome neutral= =2E What I mean is, that while in itself not necessarily negative, it impli= es that the new kid on the block is the way into the future, while the clas= sic version should head into it's well-deserved retirement=2E And on the fa= cts this simply is not settled or accepted in the case of L4S=2E IMHO the t= esting published by the L4S/RITE folks always tested conditions that are ve= ry favorable to L4S and completely ignored to reach out to the actual user = community interested in low latency under load=2E It might well be that the= L4S approach might also do well in a true stress test (bi-directiomal satu= ration on a asymmetric path with bursty cross traffic for starters), but I = would like to see numbers first=2E And the L4S sce back-off data posted to = this list in the path seems to indicate that L4S still has open ends that I= MHO need addressing (independent of whether 3GPP likes this or not)=2E=20 Best Regards Sebastian On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S wrote: >Hi > >I would prefer that the term "Classic" is kept=2E=20 >L4S is not anymore an IETF only matter=2E Work is ongoing to get support >for >L4S in 3GPP for 5G and the input papers there use the term classic=2E=20 >It is of course too late for changing classic to something else, but >then it >is appreciated that It is something that the group can agree on and I >don't >see that we are there, therefore it is better to stick to "classic"=2E >And to me the term "classic" does not sound negative=2E=20 > >/Ingemar > >> Message: 3 >> Date: Wed, 6 Nov 2019 00:22:44 +0000 >> From: Bob Briscoe >> To: "Scharf, Michael" , "Rodney W= =2E >> Grimes" <4bone@gndrsh=2Ednsmgr=2Enet> >> Cc: Wesley Eddy , "tsvwg@ietf=2Eorg" >> , "tcpm@ietf=2Eorg" >> Subject: Re: [tcpm] [tsvwg] L4S status tracking >> Message-ID: <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe=2Enet> >> Content-Type: text/plain; charset=3D"windows-1252"; Format=3D"flowed" >>=20 >> Michael, Rod, >>=20 >> Altho non-L4S is a reasonable idea, I think it has more of a negative >connotation >> than classic=2E For instance, consider describing Android phones as >non-iPhones=2E >>=20 >> Also, in the ecn-l4s-id draft, we introduce the possibility that some >operators >> might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the >same >queue as >> L4S traffic (and we say that in this case the queue would be called >the >Low >> Latency queue)=2E This shows that the term non-L4S is not a good choice >for >a >> name, because the words it is made from already give it a meaning of >its >own >> that conflicts with the definition you want it to have in certain >contexts=2E >>=20 >> For example, if you did define the name "non-iPhone" to mean phones >such >as >> Android, Windows, etc, then you would expect the phrase "non-iPhone >knock- >> off products" to mean "fake Android and Windows phones"=2E However the >> constituent elements "non" and "iPhone" already have a meaning of >their >own, >> so in the context of this phrase, it means "fake iPhones", which is >the >opposite >> of what you wanted=2E >>=20 >> The term Classic for the non-L4S service, its queue, its traffic, its >congestion >> control, etc=2E is defined in the terminology section of the drafts, so >I >think it's >> best to live with this - it's not a significant problem=2E Indeed, it >has >become widely >> used and widely understood since 2015, and changing it to non-L4S now >would >> cause unnecessary confusion=2E >>=20 >>=20 >>=20 >> Bob >>=20 >>=20 >>=20 >> On 04/11/2019 19:21, Scharf, Michael wrote: >> > >> > I agree=2E ?non-L4S? may be even better=2E >> > >> > Michael >> > >> > *Von: *Rodney W=2E Grimes >> > *Gesendet: *Montag, 4=2E November 2019 20:17 >> > *An: *Scharf, Michael >> > *Cc: *Bob Briscoe ; Wesley Eddy >> > ; tsvwg@ietf=2Eorg >; >> > tcpm@ietf=2Eorg >> > *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking >> > >> > > You can e=2Eg=2E use ?non-L4S-enabled TCP?=2E >> > > >> > > Terminology does matter to me given that I strongly disagree to >any >> > use of ?marketing language? when it comes to TCP=2E >> > >> > My concern here of use of terms like, legacy, classic, new, old is >> > that they are pretty much all of the relative from and thus >ambiguous >> > over time=2E >> > >> > newReno is new only relative to Reno, that is fairly clear, but if >I >> > said newTCP or oldTCP with what frame should the reference be >> > evaluated=2E >> > >> > I believe in the case of L4S the time invariant term would be, as >> > Michael suggests above, "non-L4S"=2E?? Note that enabled for me is a >> > noise word in this context, and TCP may or may not be needed >depending >> > on context, but for literal replacement of Legacy or Classic >"non-L4S" >> > is invariant over time=2E >> > >> > Rod >> > >> > > Michael >> > > >> > > >> > > Von: Bob Briscoe >> > > Gesendet: Montag, 4=2E November 2019 19:09 >> > > An: Scharf, Michael; >Wesley >> > Eddy; >> > tsvwg@ietf=2Eorg >> > > Cc: tcpm@ietf=2Eorg >> > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking >> > > >> > > Michael, >> > > >> > > Previously, I have been told not to use the term standard for >RFCs >> > that are not standards=2E RFC5681 is 'only' a draft standard=2E This = is >> > why, in the IETF at least, I avoid using the term "standard TCP >> > congestion control"=2E I generally call it Reno when referring to the >> > congestion control=2E >> > > >> > > I have never, to my knowledge, used the term classic TCP, or >classic >> > TCP congestion control=2E >> > > >> > > And I rarely use the term legacy, and if I do I'm happy to have >> > alternatives suggested=2E >> > > >> > > I've checked the L4S drafts, and there is one phrase that I shall >> > leave in ecn-l4s-id: "the traditional TCP Reno additive increase", >> > because this is correctly used to mean the traditional increase (in >> > numerous AIMD CCs), not traditional TCP=2E There was one other >> > occurrence of "traditional TCP senders" in a whole para in an >appendix >> > that has just been deleted anyway=2E And in aqm-dualq-coupled there >was >> > one "legacy TCP flows" (changed to "Classic traffic" now in my >local >> > copy, using the defined term in all the L4S drafts)=2E >> > > >> > > l4s-arch is getting a complete make-over for terminology, so I >will >> > check that next=2E >> > > >> > > inline=2E=2E=2E >> > > >> > > >> > > On 23/08/2019 15:01, Scharf, Michael wrote: >> > > >> > > Hi Wes, >> > > >> > > >> > > >> > > I?d 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=2E >> > > >> > > >> > > >> > > As already noted in >> > https://mailarchive=2Eietf=2Eorg/arch/msg/tsvwg/zZkYZKF- >> hDvWO3I5MudwpNkKyH >> > >Y> > KyHY> , I object to the terms ?traditional TCP? and also ?classic >TCP? >> > or ?legacy? TCP when referring to a TCP implementation according to >> > IETF standards-track RFCs=2E >> > > >> > > >> > > >> > > To me as a non-native native speaker, all these terms have a >> > negative connotation=2E I also think this language is typical to >> > marketing material=2E >> > > >> > > You're entitled to your opinion but, as a native speaker, I don't >> > think 'classic' or 'traditional' are particularly pejorative, tho >they >> > can be when used in a context that intends them to be=2E They also >mean >> > "stood the test of time"=2E I find 'legacy' has a connotation of >> > marketing-speak, but it's not that bad=2E >> > > >> > > This is an enduring problem when trying to improve on the good >work >> > that other people have done before you (which is the context of >> > everything we are doing)=2E We need a word that distinguishes the old >> > from the new, but we don't want to completely trash the thing that >has >> > already been successful, but had its day=2E >> > > >> > > Nonetheless, it is also important not to be too precious about >past >> > work=2E We all recognize that Reno TCP is unscalable and has >problems=2E >> > IMO, it is OK to describe technologies that have had their time >with >> > negative connotations=2E Indeed, you have been an author (with me) of >an >> > RFC on open issues in congestion control=2E >> > > >> > > I notice you haven't suggested an alternative term for "the >thing(s) >> > we are trying to improve on"=2E Not surprising, because it's >difficult=2E >> > > >> > > When we (the L4S developers) were first looking for a term for >the >> > non-L4S queue and the non-L4S service, we didn't want to use >'legacy' >> > for the above reasons, but we did want to imply pre-existing, so we >> > decided on 'classic', which we all felt had a generally neutral >> > connotation, but said what we meant=2E >> > > >> > > Finally, I do not want this issue to take up any time that would >> > detract from technical issues=2E >> > > >> > > >> > > >> > > Bob >> > > >> > > >> > > >> > > >> > > My prefered term when referring to TCP according to >standards-track >> > specification is ?standard TCP?=2E 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=2E >> > > >> > > >> > > >> > > Similarly, I think that term such as ?classic? is not appropriate >> > for the TCP standard congestion control (?Reno?)=2E As of today, this >is >> > the TCP congestion control algorithm on standards track that has >IETF >> > consensus=2E The term in the TCPM charter is ?TCP standard congestion >> > control?=2E I also think that terms such as ?Reno-compatible? or the >> > like would be neutral=2E >> > > >> > > >> > > >> > > Note that I do not object to the terms ?classic ECN?, ?legacy >ECN?, >> > ?legacy AQM? or the like, i=2Ee=2E, if the context is ECN and not >> > specifically TCP or the TCP congestion control=2E I believe it is up >to >> > the TSVWG do decide if this term shall be used for compliance to >RFC >> > 3168=2E I have no strong opinion on that=2E As far as I can see, most >use >> > of the term ?classic? is in this context and I don?t ask for >changes >> > in those cases=2E >> > > >> > > >> > > >> > > Some use of the term ?Classic Service? may also require careful >> > review to clearly separate it from TCP Standard behavior=2E >> > > >> > > >> > > >> > > Note that some use of the term ?Classic TCP? would probably also >> > apply to ?Classic QUIC? once the QUIC standard is finished=2E To me >as a >> > non-native speaker, it would be really strange to use the term >> > ?classic? in the context of a brand-new transport protocol=2E IMHO in >> > that case the term ?classic? would be even more confusing=2E >> > > >> > > >> > > >> > > I also add the TCPM list in CC to ensure consistency=2E >> > > >> > > >> > > >> > > Thanks >> > > >> > > >> > > >> > > Michael (with no hat) >> > > >> > > >> > > >> > > >> > > >> > > Von: Wesley Eddy >> > > Gesendet: Sonntag, 11=2E August 2019 07:08 >> > > An: tsvwg@ietf=2Eorg >> > > 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=2Eietf=2Eorg/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&page= =3D1 >> > > >> > > I'll try to update these based on the ongoing discussions, >updates, >> > > etc=2E, 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=2E >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > tcpm mailing list >> > > tcpm@ietf=2Eorg >> > > https://www=2Eietf=2Eorg/mailman/listinfo/tcpm >> > > >> > > >> > > >> > > -- >> > > >> ________________________________________________________________ >> > > Bob Briscoe >> > > >https://protect2=2Efireeye=2Ecom/v1/url?k=3D9e3cf770-c2e8fb81-9e3cb7eb-86= 4 >> > > 685b2085c-4ba6a1960c4f3e7a&q=3D1&e=3Dbf49c0f0-380b-42d4-93a2- >> 9ebedff802e >> > > 0&u=3Dhttp%3A%2F%2Fbobbriscoe=2Enet%2F >> > >> > > _______________________________________________ >> > > tcpm mailing list >> > > tcpm@ietf=2Eorg >> > > https://www=2Eietf=2Eorg/mailman/listinfo/tcpm >> > >> > -- >> > Rod Grimes rgrimes@freebsd=2Eorg >>=20 >> -- >> ________________________________________________________________ >> Bob Briscoe >https://protect2=2Efireeye=2Ecom/v1/url?k=3D861241a8- >> dac64d59-86120133-864685b2085c-16120a27ab4a751a&q=3D1&e=3Dbf49c0f0- >> 380b-42d4-93a2-9ebedff802e0&u=3Dhttp%3A%2F%2Fbobbriscoe=2Enet%2F >>=20 >> -------------- next part -------------- >> An HTML attachment was scrubbed=2E=2E=2E >> URL: >> >> fd1/attachment=2Ehtml> >>=20 >> ------------------------------ >>=20 >> Subject: Digest Footer >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/tcpm >>=20 >>=20 >> ------------------------------ >>=20 >> End of tcpm Digest, Vol 187, Issue 15 >> ************************************* --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From nobody Tue Nov 5 23:23:34 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 507D1120BC0; Tue, 5 Nov 2019 23:23:33 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 JIseWOBonR0z; Tue, 5 Nov 2019 23:23:30 -0800 (PST) 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 9B7E7120B96; Tue, 5 Nov 2019 23:23:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 17E9A25A20; Wed, 6 Nov 2019 08:23:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573025008; bh=uoug4D41r6XBgSCeR6qKZuzNZQeILinZN0ZvgR1Cg2U=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=K2LW0fc0wiY70NDYnX6tBLOnKx+NoinxDqIEhl3M4557ddOFa74GRIsIFYOWyBlYX JhOwk5IkXtx5SKNQI9XpganvJBiN7enLIAZ6JiA9QkQiEE/JOq6+6fJqXppfC20OO5 K02CuwrAqlsgnehChB2HE6+55EKHeCB06tUFPaWU= 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 GTUx0uod8g9R; Wed, 6 Nov 2019 08:23:26 +0100 (CET) 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; Wed, 6 Nov 2019 08:23:26 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 6 Nov 2019 08:23:25 +0100 From: "Scharf, Michael" To: Bob Briscoe , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: Wesley Eddy , "tsvwg@ietf.org" , "tcpm@ietf.org" Thread-Topic: [tcpm] [tsvwg] L4S status tracking Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53v//8bUAgAASJQ6AAdWZAIAAhk2s Date: Wed, 6 Nov 2019 07:23:24 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de>, <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> In-Reply-To: <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4E4829rznt8114rzntrzd_" 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: Wed, 06 Nov 2019 07:23:33 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E4829rznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bob, I am not convinced by any of your statements. There are more than 500.000 hits in Google for =84non-iPhone=93 and I see m= any that are not about fakes. Certainly, I don=92t insist in the term =84non-L4S=93. This is just an exam= ple. I already proposed =84non-L4S-enabled=93 as well. I fail to understand= how =84non-L4S-enabled TCP=93 could be confused with =84non-L4S traffic=93= . But, as outlined below, anyway there are other solutions. Also, I don=92t object to the term =84Classic=93 when referring to ECN and = other related concepts if that use of the term has strong TSVWG consensus. = For instance, "classic=93 ECN feedback, =84classic=93 queue, =84classic=93 = traffic would work for me in case TSVWG strongly supports that term. Thus, personally, I am not asking for any disruptive change. I don=92t ask = to avoid =84Classic=93 in general. What does *not* work for me is the term =84Classic=93 TCP, in particular wh= en refering to TCP as standardized by TCPM. I also don=92t agree to the ter= m =84classic=93 congestion Control for Reno, CUBIC, CTCP, i.e., work of the= TCPM working group. To me, the authors of this document do not have the ri= ght to tag work of the TCPM working group with a term such as =84classic=93= that is used in marketing language. And there are plenty of simple ways to avoid that problematic term =84Class= ic=93 TCP. Here are some more examples: * TCP without the L4S extension * TCP (senders/stacks/connections) not using L4S * TCP without support of L4S * TCP (senders/stacks/connections) lacking L4S support * TCP (senders/stacks/connections) not participating in the L4S experim= ent * =85 and more and also permutations thereof You can also try to reword text to just to avoid the term =84Classic=93 TCP= to work around the problem. Regarding congestion control, you can refer instead to * specific algorithms such as Reno or CUBIC * =84high-speed loss-based congestion control=93 * or any of the above terms, e.g., =84congestion control without L4S su= pport=93 and the like My ask is a simple editorial change that will IMHO only affect few occurenc= es of the term =84Classic=93. Can you please propose next steps that addess= my concern? Thanks Michael Von: Bob Briscoe Gesendet: Mittwoch, 6. November 2019 01:22 An: Scharf, Michael; Rodney W. Grime= s Cc: Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org Betreff: Re: [tcpm] [tsvwg] L4S status tracking Michael, Rod, Altho non-L4S is a reasonable idea, I think it has more of a negative conno= tation than classic. For instance, consider describing Android phones as no= n-iPhones. Also, in the ecn-l4s-id draft, we introduce the possibility that some opera= tors might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same= queue as L4S traffic (and we say that in this case the queue would be call= ed the Low Latency queue). This shows that the term non-L4S is not a good c= hoice for a name, because the words it is made from already give it a meani= ng of its own that conflicts with the definition you want it to have in cer= tain contexts. For example, if you did define the name "non-iPhone" to mean phones such as= Android, Windows, etc, then you would expect the phrase "non-iPhone knock-= off products" to mean "fake Android and Windows phones". However the consti= tuent elements "non" and "iPhone" already have a meaning of their own, so i= n the context of this phrase, it means "fake iPhones", which is the opposit= e of what you wanted. The term Classic for the non-L4S service, its queue, its traffic, its conge= stion control, etc. is defined in the terminology section of the drafts, so= I think it's best to live with this - it's not a significant problem. Inde= ed, it has become widely used and widely understood since 2015, and changin= g it to non-L4S now would cause unnecessary confusion. Bob On 04/11/2019 19:21, Scharf, Michael wrote: I agree. =84non-L4S=93 may be even better. Michael Von: Rodney W. Grimes Gesendet: Montag, 4. November 2019 20:17 An: Scharf, Michael Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org Betreff: Re: [tcpm] [tsvwg] L4S status tracking > You can e.g. use ?non-L4S-enabled TCP?. > > Terminology does matter to me given that I strongly disagree to any use o= f ?marketing language? when it comes to TCP. My concern here of use of terms like, legacy, classic, new, old is that they are pretty much all of the relative from and thus ambiguous over time. newReno is new only relative to Reno, that is fairly clear, but if I said newTCP or oldTCP with what frame should the reference be evaluated. I believe in the case of L4S the time invariant term would be, as Michael suggests above, "non-L4S". Note that enabled for me is a noise word in this context, and TCP may or may not be needed depending on context, but for literal replacement of Legacy or Classic "non-L4S" is invariant over time. Rod > Michael > > > Von: Bob Briscoe > Gesendet: Montag, 4. November 2019 19:09 > An: Scharf, Michael; Wesley Eddy; tsvwg@ietf.org > Cc: tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > Michael, > > Previously, I have been told not to use the term standard for RFCs that a= re not standards. RFC5681 is 'only' a draft standard. This is why, in the I= ETF at least, I avoid using the term "standard TCP congestion control". I g= enerally call it Reno when referring to the congestion control. > > I have never, to my knowledge, used the term classic TCP, or classic TCP = congestion control. > > And I rarely use the term legacy, and if I do I'm happy to have alternati= ves suggested. > > I've checked the L4S drafts, and there is one phrase that I shall leave i= n ecn-l4s-id: "the traditional TCP Reno additive increase", because this is= correctly used to mean the traditional increase (in numerous AIMD CCs), no= t traditional TCP. There was one other occurrence of "traditional TCP sende= rs" in a whole para in an appendix that has just been deleted anyway. And i= n aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic t= raffic" now in my local copy, using the defined term in all the L4S drafts)= . > > l4s-arch is getting a complete make-over for terminology, so I will check= that next. > > inline... > > > On 23/08/2019 15:01, Scharf, Michael wrote: > > Hi Wes, > > > > I?d 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-h= DvWO3I5MudwpNkKyHY , I object to the terms ?traditional TCP? and also ?class= ic TCP? or ?legacy? TCP when referring to a TCP implementation according to= IETF standards-track RFCs. > > > > To me as a non-native native speaker, all these terms have a negative con= notation. I also think this language is typical to marketing material. > > You're entitled to your opinion but, as a native speaker, I don't think '= classic' or 'traditional' are particularly pejorative, tho they can be when= used in a context that intends them to be. They also mean "stood the test = of time". I find 'legacy' has a connotation of marketing-speak, but it's no= t that bad. > > This is an enduring problem when trying to improve on the good work that = other people have done before you (which is the context of everything we ar= e doing). We need a word that distinguishes the old from the new, but we do= n't want to completely trash the thing that has already been successful, bu= t had its day. > > Nonetheless, it is also important not to be too precious about past work.= We all recognize that Reno TCP is unscalable and has problems. IMO, it is = OK to describe technologies that have had their time with negative connotat= ions. Indeed, you have been an author (with me) of an RFC on open issues in= congestion control. > > I notice you haven't suggested an alternative term for "the thing(s) we a= re trying to improve on". Not surprising, because it's difficult. > > When we (the L4S developers) were first looking for a term for the non-L4= S queue and the non-L4S service, we didn't want to use 'legacy' for the abo= ve reasons, but we did want to imply pre-existing, so we decided on 'classi= c', which we all felt had a generally neutral connotation, but said what we= meant. > > Finally, I do not want this issue to take up any time that would detract = from technical issues. > > > > Bob > > > > > My prefered term when referring to TCP according to standards-track speci= fication is ?standard TCP?. I would also be fine with other terms as long a= s they are neutral and make clear that experiments do not replace, deprecat= e, or outperform standards. > > > > Similarly, I think that term such as ?classic? is not appropriate for the= TCP standard congestion control (?Reno?). As of today, this is the TCP con= gestion control algorithm on standards track that has IETF consensus. The t= erm 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?, ?lega= cy AQM? or the like, i.e., if the context is ECN and not specifically TCP o= r 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 opinio= n on that. As far as I can see, most use of the term ?classic? is in this c= ontext and I don?t ask for changes in those cases. > > > > Some use of the term ?Classic Service? may also require careful review to= clearly 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 s= peaker, it would be really strange to use the term ?classic? in the context= of a brand-new transport protocol. IMHO in that case the term ?classic? wo= uld 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. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.= org -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_6EC6417807D9754DA64F3087E2E2E03E2D4E4829rznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Bob,

 

I am not convinced by any of your statements.

 

There are more than 500.000 hits in Google for =84no= n-iPhone=93 and I see many that are not about fakes.

 

Certainly, I don=92t insist in the term =84non-L4S= =93. This is just an example. I already proposed =84non-L4S-enabled=93 as w= ell. I fail to understand how =84non-L4S-enabled TCP=93 could be confused w= ith =84non-L4S traffic=93. But, as outlined below, anyway there are other solutions.

 

Also, I don=92t object to the term =84Classic=93 whe= n referring to ECN and other related concepts if that use of the term has s= trong TSVWG consensus. For instance, "classic=93 ECN feedback, =84clas= sic=93 queue, =84classic=93 traffic would work for me in case TSVWG strongly supports that term.

 

Thus, personally, I am not asking for any disruptive= change. I don=92t ask to avoid =84Classic=93 in general.

 

What does *not* work for me is the term =84Cl= assic=93 TCP, in particular when refering to TCP as standardized by TCPM. I= also don=92t agree to the term =84classic=93 congestion Control for Reno, = CUBIC, CTCP, i.e., work of the TCPM working group. To me, the authors of this document do not have the right to tag wo= rk of the TCPM working group with a term such as =84classic=93 that is used= in marketing language.

 

And there are plenty of simple ways to avoid that pr= oblematic term =84Classic=93 TCP. Here are some more examples:

  • TCP without the L4= S extension
  • TC= P (senders/stacks/connections) not using L4S
  • TCP without support of L4S
  • TCP (senders/stacks/connections= ) lacking L4S support
  • TCP (senders/stacks/connections) not participating in the L4S exper= iment
  • =85 and = more and also permutations thereof

 

You can also try to reword text to just to avoid the= term =84Classic=93 TCP to work around the problem.

 

Regarding congestion control, you can refer instead = to

  • specific algorithm= s such as Reno or CUBIC
  • =84high-speed= loss-based congestion control=93
  • or any of the above terms, e.g., =84congestion control= without L4S support=93 and the like

 

My ask is a simple editorial change that will IMHO o= nly affect few occurences of the term =84Classic=93. Can you please propose= next steps that addess my concern?

 

Thanks

 

Michael

 <= /span>

 

Von: Bob Briscoe
Gesendet: Mittwoch, 6. November 2019 01:22
An: Scharf, Michae= l; Rodney W. Grimes
Cc: Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

 

Michael, Rod,

Altho non-L4S is a reasonable idea, I think it has more of a negative conno= tation than classic. For instance, consider describing Android phones as no= n-iPhones.

Also, in the ecn-l4s-id draft, we introduce the possibility that some opera= tors might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same= queue as L4S traffic (and we say that in this case the queue would be call= ed the Low Latency queue). This shows that the term non-L4S is not a good choice for a name, because the w= ords it is made from already give it a meaning of its own that conflicts wi= th the definition you want it to have in certain contexts.

For example, if you did define the name "non-iPhone" to mean phon= es such as Android, Windows, etc, then you would expect the phrase "no= n-iPhone knock-off products" to mean "fake Android and Windows ph= ones". However the constituent elements "non" and "iPho= ne" already have a meaning of their own, so in the context of this phrase, it = means "fake iPhones", which is the opposite of what you wanted.
The term Classic for the non-L4S service, its queue, its traffic, its conge= stion control, etc. is defined in the terminology section of the drafts, so= I think it's best to live with this - it's not a significant problem. Inde= ed, it has become widely used and widely understood since 2015, and changing it to non-L4S now would cause u= nnecessary confusion.



Bob



On 04/11/2019 19:21, Scharf, Michael wrote:<= br>

I agree. =84non-L4S=93 may be even better.

 

Michael

 = ;

 

Von: Rodney W. Grimes
Gesendet: Montag, 4. November 2019 20:17
An: Scharf, Michae= l
Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

 

> You can e.g. use ?non-L4S-enabled TCP?.
>
> Terminology does matter to me given that I strongly disagree to any us= e of ?marketing language? when it comes to TCP.

My concern here of use of terms like, legacy, classic, new, old
is that they are pretty much all of the relative from and thus
ambiguous over time.

newReno is new only relative to Reno, that is fairly clear,
but if I said newTCP or oldTCP with what frame should the
reference be evaluated.

I believe in the case of L4S the time invariant term would be,
as Michael suggests above, "non-L4S".   Note that enabl= ed
for me is a noise word in this context, and TCP may or may
not be needed depending on context, but for literal replacement
of Legacy or Classic "non-L4S" is invariant over time.

Rod

> Michael
>
>
> Von: Bob Briscoe<mailto:ietf= @bobbriscoe.net>
> Gesendet: Montag, 4. November 2019 19:09
> An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley Eddy<mailto:wes@mti-systems.com>; tsvwg@= ietf.org<mailto:tsvwg@ietf.org= >
> Cc: tcpm@ietf.org<mailto:tcpm@ietf.or= g>
> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael,
>
> Previously, I have been told not to use the term standard for RFCs tha= t are not standards. RFC5681 is 'only' a draft standard. This is why, in th= e IETF at least, I avoid using the term "standard TCP congestion contr= ol". I generally call it Reno when referring to the congestion control.
>
> I have never, to my knowledge, used the term classic TCP, or classic T= CP congestion control.
>
> And I rarely use the term legacy, and if I do I'm happy to have altern= atives suggested.
>
> I've checked the L4S drafts, and there is one phrase that I shall leav= e in ecn-l4s-id: "the traditional TCP Reno additive increase", be= cause this is correctly used to mean the traditional increase (in numerous = AIMD CCs), not traditional TCP. There was one other occurrence of "traditional TCP senders" in a whole para in= an appendix that has just been deleted anyway. And in aqm-dualq-coupled th= ere was one "legacy TCP flows" (changed to "Classic traffic&= quot; now in my local copy, using the defined term in all the L4S drafts).
>
> l4s-arch is getting a complete make-over for terminology, so I will ch= eck that next.
>
> inline...
>
>
> On 23/08/2019 15:01, Scharf, Michael wrote:
>
> Hi Wes,
>
>
>
> I?d like to add a smaller item that is mostly editorial and can hopefu= lly be sorted just out by re-wording, albeit it may require a careful analy= sis of all documents.
>
>
>
> As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<= https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?classic TCP? or ?= legacy? TCP when referring to a TCP implementation according to IETF standards-track RFCs.
>
>
>
> To me as a non-native native speaker, all these terms have a negative = connotation. I also think this language is typical to marketing material. >
> You're entitled to your opinion but, as a native speaker, I don't thin= k 'classic' or 'traditional' are particularly pejorative, tho they can be w= hen used in a context that intends them to be. They also mean "stood t= he test of time". I find 'legacy' has a connotation of marketing-speak, but it's not that bad.
>
> This is an enduring problem when trying to improve on the good work th= at other people have done before you (which is the context of everything we= are doing). We need a word that distinguishes the old from the new, but we= don't want to completely trash the thing that has already been successful, but had its day.
>
> Nonetheless, it is also important not to be too precious about past wo= rk. We all recognize that Reno TCP is unscalable and has problems. IMO, it = is OK to describe technologies that have had their time with negative conno= tations. Indeed, you have been an author (with me) of an RFC on open issues in congestion control.
>
> I notice you haven't suggested an alternative term for "the thing= (s) we are trying to improve on". Not surprising, because it's difficu= lt.
>
> When we (the L4S developers) were first looking for a term for the non= -L4S queue and the non-L4S service, we didn't want to use 'legacy' for the = above reasons, but we did want to imply pre-existing, so we decided on 'cla= ssic', which we all felt had a generally neutral connotation, but said what we meant.
>
> Finally, I do not want this issue to take up any time that would detra= ct from technical issues.
>
>
>
> Bob
>
>
>
>
> My prefered term when referring to TCP according to standards-track sp= ecification is ?standard TCP?. I would also be fine with other terms as lon= g as they are neutral and make clear that experiments do not replace, depre= cate, or outperform standards.
>
>
>
> Similarly, I think that term such as ?classic? is not appropriate for = the TCP standard congestion control (?Reno?). As of today, this is the TCP = congestion control algorithm on standards track that has IETF consensus. Th= e term in the TCPM charter is ?TCP standard congestion control?. I also think that terms such as ?Reno-compat= ible? or the like would be neutral.
>
>
>
> Note that I do not object to the terms ?classic ECN?, ?legacy ECN?, ?l= egacy AQM? or the like, i.e., if the context is ECN and not specifically TC= P 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 u= se of the term ?classic? is in this context and I don?t ask for changes in = those cases.
>
>
>
> Some use of the term ?Classic Service? may also require careful review= to clearly 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-nativ= e speaker, it would be really strange to use the term ?classic? in the cont= ext of a brand-new transport protocol. IMHO in that case the term ?classic? would be even more confusing.
>
>
>
> I also add the TCPM list in CC to ensure consistency.
>
>
>
> Thanks
>
>
>
> Michael (with no hat)
>
>
>
>
>
> Von: Wesley Eddy<mailto:wes@= mti-systems.com>
> Gesendet: Sonntag, 11. August 2019 07:08
> An: tsvwg@ietf.org<mailto:tsvwg@iet= f.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=3Dtic= ket&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 ticke= t
> numbers or some key words in threads and messages, when significant. >
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tc= pm@ietf.org<mailto:tcpm@ietf.org>
> https://www.iet= f.org/mailman/listinfo/tcpm
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe          = ;            &n= bsp;        http://bobbriscoe.net/

> _______________________________________________
> tcpm mailing list
> tc= pm@ietf.org
> https://www.iet= f.org/mailman/listinfo/tcpm

--
Rod Grimes           = ;            &n= bsp;            = ;             <= a class=3D"moz-txt-link-abbreviated" href=3D"mailto:rgrimes@freebsd.org"> rgrimes@freebsd.org

--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E4829rznt8114rzntrzd_-- From nobody Tue Nov 5 23:25: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 4B8E7120BA0 for ; Tue, 5 Nov 2019 23:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 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] 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 vMsUSQQGeuRj for ; Tue, 5 Nov 2019 23:25:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 3BE99120B96 for ; Tue, 5 Nov 2019 23:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573025128; bh=mHdmVf0qohE/FU3qqBBXUuXja+YbQmiHrvLCfXKR754=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=cS56L3lS1vgz6lfR0X0qqGCOiPN86AGvGGu2fraWAgjeju7lJ/FG1JJNXn0wKZnjA HtfinIEt5PfE8isNKB3CUiigxawMo8znMXfZ33Sd/utbz2MzZ9pSBtcf2+XJiIvB3x gJoCHg5ZyA9fWW+cE/Jnt+LbFpPHc/raTCyK/At8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.198.62.136] ([80.187.112.39]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M2O2W-1iV0k72q9W-003v97; Wed, 06 Nov 2019 08:18:53 +0100 Date: Wed, 06 Nov 2019 08:18:46 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Bob Briscoe , "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: "tcpm@ietf.org" ,"tsvwg@ietf.org" From: Sebastian Moeller Message-ID: <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> X-Provags-ID: V03:K1:1il8+2cgrftYfrCneAIktk0KF1ibbJieKwa03PNaYjazvnZ7DDe ZCNOopWL6qLCf+T88Uo0sXuRCjUk7far3gXQVC/RU+fcKbKQjP3I9xs/vWGa+3bKQ8nHrrZ HmwJDngtqPYs7724lF8PaeEXeNO6l3SOAsHkeZvCCzxCQJBwvwrYQutMzycFmolIrK1zKgo TLe8bDmcUZf/xTiigNUgw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Mi6m7ijnryE=:vkPi373E3YeHX6gnCY9Plu C3r8njEM7czfAiUrerGmxQQDd0U7rbeszkYcujpr0QEYlA8cLz3zwZQ70HO69RU0pMnOjo15g lBJzdxhUZ+ixz//n6O1zOiQSqR66mveaWQ34gNu+hAtLoT+ksZc0gI5QcnqKnOQgX9BuhRRJJ SYUfgYLunyHV6PuUngFecGqUTzrgTxIFhqWgy5z1+uus+3k/s+szbyGVmILWEg7p/OiftD1Ww YYFs+FjAh8DPpRk5ld8wmIVk5y+vJyH2JABvuBiOsCPZXNsbRRTjSgQiPGe/YEOAROq2Hbc0z H+QMfTfaZBLwsTGsThBsu+fHBdu5D6xe11b+qNzrkWa1SdvqbHIJc8CUhsVHcV1npqNLajdCW 2kx0xdY+/FKkZzdokQ+aQ8EJjMJBL07Tk2BAomkbpX+fT0B2eYRMCEdgdvhGqG6tZK1+VbT/h JTU1IksEVZXHZ7EfFiV2yuvjENDlsguD4XnrXbJ2A71q2Ed48xBrc4OwVKD6gqh2J/emKBbND 6EDkBWv7VyTpSayAos300ZVMhVfumXcBnTyOrEqyHfGGN3cFFyk4qPlUylOddl1Plr+tBG4vm cyz0vfFcNh2m2j7JzSWIqMRCVpfO3QnGCHUjh3GFhJRP32cRbF9dAnECFrfqIUa5hIcv8g1Xn iLf7zkP0t6XiziOMRytRVRlNUbmaOo5PdDqlio/p4jzqgvoRUGb+9Vw0mQD3sOdoW+nwjXs1k NDuPYuviKwBuW3ysUZqNgf9qDeS2Oa12swlutNz3HdQPO3o68Ck9RUZ5JizZIFjFX191DjM2G ihHLvfnJeZ5V1e5iSEGyGR4FAHtzWFdPn7B8ZRrftPz81oYvdUbzEFwZLZXmYNA3rJXYl/Lb6 JKX/sti/+htwdIJyawKi2OwTSQZFfsnnf388mdNoGUVTgYXJTxiM/fFGFymEZ3Q3wN5TlH1U6 9EV1k4bgqgdBXGxv+WUf10WUM1vJujEs7Bd2J9QH6T/9E2skLDdg6CEiFnbC9pRC5zwFJmH4C lEZQsdY/ZhCY+hHLWaUvtjTfxQzrABvPF7sl4m1dv3QW4fu6DbZg5OvgBseJv2EdpDp7rax/J 2tohiFKY9tqaWsQbUvzDWo8ovcIGCa3nbYQ3dogt19wLggFqhg/jVxUzejo0Axvl90xLw6/C/ St/2ZByzw/yAO0oCW1fl9Am51J6JknQy10BkPLArooRt4VtG9OVMQQxjrk+6uFEW+spV+kLln lTaXpUWuFqJ1FFdsRrjQ/uhZ+D0H/wE2LtRmjXWrovNcYzbROWZuH5eATFAI= 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: Wed, 06 Nov 2019 07:25:34 -0000 Hi Bob, On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe wrote: >Michael, Rod, > >Altho non-L4S is a reasonable idea, I think it has more of a negative=20 >connotation than classic=2E=20 [SM] It does have the advantage though of being a testable, with c= lassic all we know is you are talking about something that came before=2E For instance, consider describing Android=20 >phones as non-iPhones=2E [SM] In a discussion of say the merits of iPhones versus the comp= etition that seems to be a decent description? > >Also, in the ecn-l4s-id draft, we introduce the possibility that some=20 >operators might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into > >the same queue as L4S traffic (and we say that in this case the queue=20 >would be called the Low Latency queue)=2E This shows that the term >non-L4S=20 >is not a good choice for a name, because the words it is made from=20 >already give it a meaning of its own that conflicts with the definition > >you want it to have in certain contexts=2E [SM] Well, that use does not seem to interfere much, but if it doe= s that would be another term to change, no? > >For example, if you did define the name "non-iPhone" to mean phones >such=20 >as Android, Windows, etc, then you would expect the phrase "non-iPhone=20 >knock-off products" to mean "fake Android and Windows phones"=2E However= =20 >the constituent elements "non" and "iPhone" already have a meaning of=20 >their own, so in the context of this phrase, it means "fake iPhones",=20 >which is the opposite of what you wanted=2E [SM] That is completely besides the point, it made me smile though= and think about that passage in Alice in Wonderland about the meaning of w= ords=2E > >The term Classic for the non-L4S service, its queue, its traffic, its=20 >congestion control, etc=2E is defined in the terminology section of the= =20 >drafts, so I think it's best to live with this - it's not a significant > >problem=2E=20 [SM] If it is not significant, then changing it surely is not a pr= oblem? Indeed, it has become widely used and widely understood since=20 >2015, and changing it to non-L4S now would cause unnecessary confusion=2E [SM] By that logic nothing in the L4S drafts should be changed? If= I recall correctly that is not how getting a draft past reviewers works=2E= =2E=2E=2E > > > >Bob > > > >On 04/11/2019 19:21, Scharf, Michael wrote: >> >> I agree=2E =E2=80=9Enon-L4S=E2=80=9C may be even better=2E >> >> Michael >> >> *Von: *Rodney W=2E Grimes >> *Gesendet: *Montag, 4=2E November 2019 20:17 >> *An: *Scharf, Michael >> *Cc: *Bob Briscoe ; Wesley Eddy=20 >> ; tsvwg@ietf=2Eorg ; > >> tcpm@ietf=2Eorg >> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking >> >> > You can e=2Eg=2E use ?non-L4S-enabled TCP?=2E >> > >> > Terminology does matter to me given that I strongly disagree to any > >> use of ?marketing language? when it comes to TCP=2E >> >> My concern here of use of terms like, legacy, classic, new, old >> is that they are pretty much all of the relative from and thus >> ambiguous over time=2E >> >> newReno is new only relative to Reno, that is fairly clear, >> but if I said newTCP or oldTCP with what frame should the >> reference be evaluated=2E >> >> I believe in the case of L4S the time invariant term would be, >> as Michael suggests above, "non-L4S"=2E=C2=A0=C2=A0 Note that enabled >> for me is a noise word in this context, and TCP may or may >> not be needed depending on context, but for literal replacement >> of Legacy or Classic "non-L4S" is invariant over time=2E >> >> Rod >> >> > Michael >> > >> > >> > Von: Bob Briscoe >> > Gesendet: Montag, 4=2E November 2019 19:09 >> > An: Scharf, Michael; Wesle= y=20 >> Eddy; >tsvwg@ietf=2Eorg >> > Cc: tcpm@ietf=2Eorg >> > Betreff: Re: [tcpm] [tsvwg] L4S status tracking >> > >> > Michael, >> > >> > Previously, I have been told not to use the term standard for RFCs=20 >> that are not standards=2E RFC5681 is 'only' a draft standard=2E This is= =20 >> why, in the IETF at least, I avoid using the term "standard TCP=20 >> congestion control"=2E I generally call it Reno when referring to the= =20 >> congestion control=2E >> > >> > I have never, to my knowledge, used the term classic TCP, or >classic=20 >> TCP congestion control=2E >> > >> > And I rarely use the term legacy, and if I do I'm happy to have=20 >> alternatives suggested=2E >> > >> > I've checked the L4S drafts, and there is one phrase that I shall=20 >> leave in ecn-l4s-id: "the traditional TCP Reno additive increase",=20 >> because this is correctly used to mean the traditional increase (in=20 >> numerous AIMD CCs), not traditional TCP=2E There was one other=20 >> occurrence of "traditional TCP senders" in a whole para in an >appendix=20 >> that has just been deleted anyway=2E And in aqm-dualq-coupled there was > >> one "legacy TCP flows" (changed to "Classic traffic" now in my local=20 >> copy, using the defined term in all the L4S drafts)=2E >> > >> > l4s-arch is getting a complete make-over for terminology, so I will > >> check that next=2E >> > >> > inline=2E=2E=2E >> > >> > >> > On 23/08/2019 15:01, Scharf, Michael wrote: >> > >> > Hi Wes, >> > >> > >> > >> > I?d like to add a smaller item that is mostly editorial and can=20 >> hopefully be sorted just out by re-wording, albeit it may require a=20 >> careful analysis of all documents=2E >> > >> > >> > >> > As already noted in=20 >> >https://mailarchive=2Eietf=2Eorg/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKy= HY > >> , I object to the terms ?traditional TCP? and also ?classic TCP? or=20 >> ?legacy? TCP when referring to a TCP implementation according to IETF > >> standards-track RFCs=2E >> > >> > >> > >> > To me as a non-native native speaker, all these terms have a=20 >> negative connotation=2E I also think this language is typical to=20 >> marketing material=2E >> > >> > You're entitled to your opinion but, as a native speaker, I don't=20 >> think 'classic' or 'traditional' are particularly pejorative, tho >they=20 >> can be when used in a context that intends them to be=2E They also mean > >> "stood the test of time"=2E I find 'legacy' has a connotation of=20 >> marketing-speak, but it's not that bad=2E >> > >> > This is an enduring problem when trying to improve on the good work > >> that other people have done before you (which is the context of=20 >> everything we are doing)=2E We need a word that distinguishes the old= =20 >> from the new, but we don't want to completely trash the thing that >has=20 >> already been successful, but had its day=2E >> > >> > Nonetheless, it is also important not to be too precious about past > >> work=2E We all recognize that Reno TCP is unscalable and has problems= =2E=20 >> IMO, it is OK to describe technologies that have had their time with=20 >> negative connotations=2E Indeed, you have been an author (with me) of >an=20 >> RFC on open issues in congestion control=2E >> > >> > I notice you haven't suggested an alternative term for "the >thing(s)=20 >> we are trying to improve on"=2E Not surprising, because it's difficult= =2E >> > >> > When we (the L4S developers) were first looking for a term for the=20 >> non-L4S queue and the non-L4S service, we didn't want to use 'legacy' > >> for the above reasons, but we did want to imply pre-existing, so we=20 >> decided on 'classic', which we all felt had a generally neutral=20 >> connotation, but said what we meant=2E >> > >> > Finally, I do not want this issue to take up any time that would=20 >> detract from technical issues=2E >> > >> > >> > >> > Bob >> > >> > >> > >> > >> > My prefered term when referring to TCP according to standards-track > >> specification is ?standard TCP?=2E I would also be fine with other >terms=20 >> as long as they are neutral and make clear that experiments do not=20 >> replace, deprecate, or outperform standards=2E >> > >> > >> > >> > Similarly, I think that term such as ?classic? is not appropriate=20 >> for the TCP standard congestion control (?Reno?)=2E As of today, this >is=20 >> the TCP congestion control algorithm on standards track that has IETF > >> consensus=2E The term in the TCPM charter is ?TCP standard congestion= =20 >> control?=2E I also think that terms such as ?Reno-compatible? or the=20 >> like would be neutral=2E >> > >> > >> > >> > Note that I do not object to the terms ?classic ECN?, ?legacy ECN?, > >> ?legacy AQM? or the like, i=2Ee=2E, if the context is ECN and not=20 >> specifically TCP or the TCP congestion control=2E I believe it is up to > >> the TSVWG do decide if this term shall be used for compliance to RFC=20 >> 3168=2E I have no strong opinion on that=2E As far as I can see, most u= se > >> of the term ?classic? is in this context and I don?t ask for changes=20 >> in those cases=2E >> > >> > >> > >> > Some use of the term ?Classic Service? may also require careful=20 >> review to clearly separate it from TCP Standard behavior=2E >> > >> > >> > >> > Note that some use of the term ?Classic TCP? would probably also=20 >> apply to ?Classic QUIC? once the QUIC standard is finished=2E To me as >a=20 >> non-native speaker, it would be really strange to use the term=20 >> ?classic? in the context of a brand-new transport protocol=2E IMHO in= =20 >> that case the term ?classic? would be even more confusing=2E >> > >> > >> > >> > I also add the TCPM list in CC to ensure consistency=2E >> > >> > >> > >> > Thanks >> > >> > >> > >> > Michael (with no hat) >> > >> > >> > >> > >> > >> > Von: Wesley Eddy >> > Gesendet: Sonntag, 11=2E August 2019 07:08 >> > An: tsvwg@ietf=2Eorg >> > 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=2Eietf=2Eorg/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&p= age=3D1 >> > >> > I'll try to update these based on the ongoing discussions, updates, >> > etc=2E, 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=2E >> > >> > >> > >> > >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf=2Eorg >> > https://www=2Eietf=2Eorg/mailman/listinfo/tcpm >> > >> > >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoe http://bobbriscoe=2Enet/ >> >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf=2Eorg >> > https://www=2Eietf=2Eorg/mailman/listinfo/tcpm >> >> --=20 >> Rod Grimes rgrimes@freebsd=2Eorg --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From nobody Tue Nov 5 23:36:27 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 C9D1612004F for ; Tue, 5 Nov 2019 23:36:25 -0800 (PST) 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 aEASV3Avgxzw for ; Tue, 5 Nov 2019 23:36:23 -0800 (PST) Received: from mta2.cl.cam.ac.uk (mta2.cl.cam.ac.uk [IPv6:2001:630:212:200::25:2]) (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 8F145120024 for ; Tue, 5 Nov 2019 23:36:23 -0800 (PST) Received: from ely.cl.cam.ac.uk ([2001:630:212:238:230:48ff:fefe:c314]) by mta2.cl.cam.ac.uk with esmtp (Exim 4.86_2) (envelope-from ) id 1iSFrW-0002mM-SV; Wed, 06 Nov 2019 07:36:18 +0000 From: Jon Crowcroft To: Bob Briscoe cc: carlesgo@entel.upc.edu, "CROWCROFT, Jon" , tcpm IETF list In-reply-to: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> Comments: In-reply-to Bob Briscoe message dated "Tue, 05 Nov 2019 23:13:54 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16279.1573025778.1@ely.cl.cam.ac.uk> Content-Transfer-Encoding: quoted-printable Date: Wed, 06 Nov 2019 07:36:18 +0000 Message-Id: Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull 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, 06 Nov 2019 07:36:26 -0000 thanks v. much - especially for more motivating cases/text we're strongly inclinded (due to context) to keep our particular approach = as simple as possible ...(but no simpler...) - that said, sharing common mechanism is also, of course, g= ood if it can be done... > Carles, Jon, (re-sending, this time without accidentally omitting tcpm, > also see couple of addenda tagged [Bob adds:]) > = > = > = > I'm generally supportive of a mechanism to suppress delayed ACKs from th= e > receiver (in any transport protocol including TCP). So thank you. > = > = > = > You might want to borrow at least some of the text for additional > motivating scenarios for such a facility from the first two posts on a > thread for a similar facility in QuiC: > = > https://github.com/quicwg/base-drafts/issues/1978 > = > Also pasted at the end. > = > = > Some is not relevant to your specific ack-pull scheme, 'cos it's proposi= ng > a more general facility in QUIC for the sender to the receiver alters it= s > ACK ratio. (theoretically there are more bits available in QUIC, but thi= s > particular request has been put on hold while someone goes and finds the= m > ;) > = > = > = > Another motivating example (rather niche) > = > = > Coincidentally, Just this morning I published a tech report that had to = > use > the hack of overlapping a byte from the previous segment to force a quic= k > ack: TCP Prague Fall-back on Detection of a Classic ECN AQM arxiv.org/pdf/1911.00710.pdf#page9> (the link takes you to Fig 2, which > illustrates the hack) I'd rather not have to do these sorts of hacks - i= t > really messes with the segmentation code. > = > = > = > Middlebox traversal of bit 6 > = > = > I recall that someone did a study of traversal of each of the reserved > flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bob adds= : = > I > mean traversal - not the study!]. > = > A good search engine might find it ;) > = > = > More alternative approaches: > = > = > 1/ At one stage, we tried to include a bit for Delayed Ack control in > another protocol called Accurate ECN. We were persuaded to take it out, > because it was mission creep (outside the scope of the protocol we were > working on): > = > https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#append= ix-B.4 > = > = > 2/ Have you considered using the Urgent Pointer in a novel way? I.e. a > non-zero Urgent Pointer field, even tho the URG flag is zero. [Bob adds:= ] > From memory, traversal was pretty good - much better than bits 4-6. But = I > think Windows treated it as a potential attack. I believe Fernando Gont = > did > a study on how 'invalid' TCP header fields are handled. > = > = > = > You could assign, say, 3 bits of the urgent pointer for a variable ack_e= xp > that is log base 2 of the ack ratio the sender would like. Then the send= er > can request the receiver uses ack_ratio` =3D 2^ack_exp, as in the QUIC > proposal below, With ack_exp =3D 0, you get ack_ratio =3D 2^0 =3D 1, whi= ch has > the same effect as ack-pull. But you also have a more general facility f= or > high speed machines to widen out the ack ratio. > = > = > = > If this works, you could open up a registry for the other 13 bits. So > instead of using up a precious bit, you generate 13 more ;) > = > = > See: > https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=3D5 > = > = > I think there were problems with some implementations and middleboxes > (bound to be). I've checked the minutes of the IETF meeting where that > slide was presented minutes-90-tcpm>, but there's no push-back in there. I suggest you delve > back into the archives of the tcpm mailing list around the time of that > meeting to find out if there were any show-stoppers. > = > = > Cheers > = > = > = > Bob > = > = > Paste from QUIC thread: > = > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\= /\/ > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > = > = > = > Problem/goals: > = > 1. Getting up to speed fast without inducing much queue is one of the > main areas where latency reductions are needed (for short and long > flows). The sender needs frequent ACKing during this phase in many > approaches (hystart, etc). A Linux TCP receiver starts with > ack_ratio 1 and uses heuristics to identify the end of the sender's > slow-start (or a re-start after idle). This has ossified a certain > slow-start behaviour into all TCP senders (whether Linux or not). We > are trying to new sender behaviours (paced chirping being an > example), but we need a way for the sender to suppress delayed ACKs. > 2. At the other end of the scale, for long-running flows, many current > CC approaches (e.g. BBR) use pacing not ACK-clocking so they can use > very few ACKs per RTT. And fewer means less cache ejections for GRO. > But the receiver doesn't know what CC the sender is using, so it > doesn't know how many or few is too many or too few. > 3. Some middleboxes and the majority of link technologies (e.g. DOCSIS, > LTE, Satellite) thin TCP ACKs when they detect the upstream is > filled with TCP ACK stream(s), which are unresponsive. Otherwise the > ACKs constrain downstream throughput (and any upstream data either > in the flow itself, or in others). We don't want these links to > attempt to guess which are the QUIC ACKs and try to thin them. QUIC > can and should do this itself. QUIC has all the machinery for the > sender CC to detect ACK congestion, but not the protocol to tell the > receiver to do the thinning. This protocol addition would provide a > sufficient hook for hosts to unilaterally add this to their CC > behaviour. > = > = > Some scenarios where the sender's preferred ack_ratio changes > through the connection: > = > 1. > = > A sender CC that wants the receiver to turn off DelAcks during > flow-start (e.g. it's using hybrid slow-start as in Cubic and wants > to get delay measurements more frequently) sets ack_exp=3D0 during > flow-start (ack_ratio=3D1), then increases ack_exp during congestion > avoidance. If it goes idle, then re-starts, it would set ack_exp=3D0 > again. > = > Note on heuristics: A Linux TCP receiver currently uses a heuristic > to determine when the sender has exited slow-start. However, > heuristics -> ossification. A Linux receiver's heuristic only works > with the current pattern of slow-start. In TCP, when we tried to > improve the pattern on the sender (paced chirping), the heuristic on > the receiver killed us. > = > 2. > = > Imagine a paced sender has hardware generic receive offload (GRO), > so for a long-running flow it doesn't want a high rate of QUIC ACKs > that are opaque to GRO. Let's say it would prefer at least 8 ACKs > per RTT. Again, it starts with ack_exp=3D0, but in congestion > avoidance it would use: > = > ack_ratio <=3D cwnd_in_packets/8 > = > = > Upshot: By remote controlling the receiver, the server offloads nearly a= ll > the ACKs from large downloads, but still focuses its ACK-receiving > resources on getting each client up to speed. > = > = > Note that calculation of ack_ratio lends itself to fast integer = > arithmetic. > = > = > = > = > = > = > = > Bob > = > = > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > = > = From nobody Wed Nov 6 01:18:48 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 5A466120129 for ; Wed, 6 Nov 2019 01:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 hcOmiafdX-uD for ; Wed, 6 Nov 2019 01:18:44 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 2F13D120125 for ; Wed, 6 Nov 2019 01:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=hXlgDE0NyUbN0ODA6oM/BG69LjYrA44/s4UGG1u/QHY=; b=OJzRTGLLgIGhcoYwDHOE/QFNLp 7Ml5BYm7LsHCxG0urRX8Iu9+HAfJZA4D2jSRyZQxhoM9U6Ob7Jz+V/pQ7mQJdRFHB7W2iRl9WKkg/ +7UXxhuGNHmMA4I0pbVD5CiOBYgKwQ50pGt23WlMBFBImCR2KSfSGTZGZJWgF0Z5luYVFyXJbT55x vRQ59DBdzFv57s8HWmUYrTHV4JzvfzI2S6anmSFV1NQJk+OkNWUpN7u3dPOWSYY4/Yfdc1H0cgzS4 HQMoE2xboIp4NlKztEWzhh6e14TG+vL4Vx8HWvmxalKoyfuW2vdZn4NTMAHuy3aczshkVU7lx+V2y nNUqCZ6w==; Received: from [31.185.128.31] (port=51366 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iSHSc-0006Ew-4q; Wed, 06 Nov 2019 09:18:42 +0000 To: Jon Crowcroft Cc: carlesgo@entel.upc.edu, tcpm IETF list References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> From: Bob Briscoe Message-ID: <70d1dc41-f2d8-5d98-c76c-e1a127eb0928@bobbriscoe.net> Date: Wed, 6 Nov 2019 09:18:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull 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, 06 Nov 2019 09:18:47 -0000 Jon, From the experience of recent years, I've changed my understanding of what is the appropriate level of 'simplicity' for each change to TCP. It takes a huge amount of effort over probably a decade for any change to become useful (in terms of both standardization effort, and subsequent network traversal effort by all the implementers). So it makes little sense to judge simplicity solely on  the simplicity of the design. Once you take the whole process into account, it becomes worth introducing something perhaps slightly more complex that will be more useful to more use-cases. IMHO. Bob On 06/11/2019 07:36, Jon Crowcroft wrote: > thanks v. much - especially for more motivating cases/text > > we're strongly inclinded (due to context) to keep our particular approach as simple as possible ...(but > no simpler...) - that said, sharing common mechanism is also, of course, good if it can be done... > >> Carles, Jon, (re-sending, this time without accidentally omitting tcpm, >> also see couple of addenda tagged [Bob adds:]) >> >> >> >> I'm generally supportive of a mechanism to suppress delayed ACKs from the >> receiver (in any transport protocol including TCP). So thank you. >> >> >> >> You might want to borrow at least some of the text for additional >> motivating scenarios for such a facility from the first two posts on a >> thread for a similar facility in QuiC: >> >> https://github.com/quicwg/base-drafts/issues/1978 >> >> Also pasted at the end. >> >> >> Some is not relevant to your specific ack-pull scheme, 'cos it's proposing >> a more general facility in QUIC for the sender to the receiver alters its >> ACK ratio. (theoretically there are more bits available in QUIC, but this >> particular request has been put on hold while someone goes and finds them >> ;) >> >> >> >> Another motivating example (rather niche) >> >> >> Coincidentally, Just this morning I published a tech report that had to >> use >> the hack of overlapping a byte from the previous segment to force a quick >> ack: TCP Prague Fall-back on Detection of a Classic ECN AQM > arxiv.org/pdf/1911.00710.pdf#page9> (the link takes you to Fig 2, which >> illustrates the hack) I'd rather not have to do these sorts of hacks - it >> really messes with the segmentation code. >> >> >> >> Middlebox traversal of bit 6 >> >> >> I recall that someone did a study of traversal of each of the reserved >> flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bob adds: >> I >> mean traversal - not the study!]. >> >> A good search engine might find it ;) >> >> >> More alternative approaches: >> >> >> 1/ At one stage, we tried to include a bit for Delayed Ack control in >> another protocol called Accurate ECN. We were persuaded to take it out, >> because it was mission creep (outside the scope of the protocol we were >> working on): >> >> https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4 >> >> >> 2/ Have you considered using the Urgent Pointer in a novel way? I.e. a >> non-zero Urgent Pointer field, even tho the URG flag is zero. [Bob adds:] >> From memory, traversal was pretty good - much better than bits 4-6. But I >> think Windows treated it as a potential attack. I believe Fernando Gont >> did >> a study on how 'invalid' TCP header fields are handled. >> >> >> >> You could assign, say, 3 bits of the urgent pointer for a variable ack_exp >> that is log base 2 of the ack ratio the sender would like. Then the sender >> can request the receiver uses ack_ratio` = 2^ack_exp, as in the QUIC >> proposal below, With ack_exp = 0, you get ack_ratio = 2^0 = 1, which has >> the same effect as ack-pull. But you also have a more general facility for >> high speed machines to widen out the ack ratio. >> >> >> >> If this works, you could open up a registry for the other 13 bits. So >> instead of using up a precious bit, you generate 13 more ;) >> >> >> See: >> https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=5 >> >> >> I think there were problems with some implementations and middleboxes >> (bound to be). I've checked the minutes of the IETF meeting where that >> slide was presented > minutes-90-tcpm>, but there's no push-back in there. I suggest you delve >> back into the archives of the tcpm mailing list around the time of that >> meeting to find out if there were any show-stoppers. >> >> >> Cheers >> >> >> >> Bob >> >> >> Paste from QUIC thread: >> >> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >> >> >> Problem/goals: >> >> 1. Getting up to speed fast without inducing much queue is one of the >> main areas where latency reductions are needed (for short and long >> flows). The sender needs frequent ACKing during this phase in many >> approaches (hystart, etc). A Linux TCP receiver starts with >> ack_ratio 1 and uses heuristics to identify the end of the sender's >> slow-start (or a re-start after idle). This has ossified a certain >> slow-start behaviour into all TCP senders (whether Linux or not). We >> are trying to new sender behaviours (paced chirping being an >> example), but we need a way for the sender to suppress delayed ACKs. >> 2. At the other end of the scale, for long-running flows, many current >> CC approaches (e.g. BBR) use pacing not ACK-clocking so they can use >> very few ACKs per RTT. And fewer means less cache ejections for GRO. >> But the receiver doesn't know what CC the sender is using, so it >> doesn't know how many or few is too many or too few. >> 3. Some middleboxes and the majority of link technologies (e.g. DOCSIS, >> LTE, Satellite) thin TCP ACKs when they detect the upstream is >> filled with TCP ACK stream(s), which are unresponsive. Otherwise the >> ACKs constrain downstream throughput (and any upstream data either >> in the flow itself, or in others). We don't want these links to >> attempt to guess which are the QUIC ACKs and try to thin them. QUIC >> can and should do this itself. QUIC has all the machinery for the >> sender CC to detect ACK congestion, but not the protocol to tell the >> receiver to do the thinning. This protocol addition would provide a >> sufficient hook for hosts to unilaterally add this to their CC >> behaviour. >> >> >> Some scenarios where the sender's preferred ack_ratio changes >> through the connection: >> >> 1. >> >> A sender CC that wants the receiver to turn off DelAcks during >> flow-start (e.g. it's using hybrid slow-start as in Cubic and wants >> to get delay measurements more frequently) sets ack_exp=0 during >> flow-start (ack_ratio=1), then increases ack_exp during congestion >> avoidance. If it goes idle, then re-starts, it would set ack_exp=0 >> again. >> >> Note on heuristics: A Linux TCP receiver currently uses a heuristic >> to determine when the sender has exited slow-start. However, >> heuristics -> ossification. A Linux receiver's heuristic only works >> with the current pattern of slow-start. In TCP, when we tried to >> improve the pattern on the sender (paced chirping), the heuristic on >> the receiver killed us. >> >> 2. >> >> Imagine a paced sender has hardware generic receive offload (GRO), >> so for a long-running flow it doesn't want a high rate of QUIC ACKs >> that are opaque to GRO. Let's say it would prefer at least 8 ACKs >> per RTT. Again, it starts with ack_exp=0, but in congestion >> avoidance it would use: >> >> ack_ratio <= cwnd_in_packets/8 >> >> >> Upshot: By remote controlling the receiver, the server offloads nearly all >> the ACKs from large downloads, but still focuses its ACK-receiving >> resources on getting each client up to speed. >> >> >> Note that calculation of ack_ratio lends itself to fast integer >> arithmetic. >> >> >> >> >> >> >> >> Bob >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Nov 6 07:49:52 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 3C6C212004C; Wed, 6 Nov 2019 07:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 32OWeAIe_uu4; Wed, 6 Nov 2019 07:49:45 -0800 (PST) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E68120072; Wed, 6 Nov 2019 07:49:43 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id A6C3721B1C; Wed, 6 Nov 2019 15:49:38 +0000 (UTC) From: Dave Taht To: "Scharf\, Michael" Cc: Bob Briscoe , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm\@ietf.org" , "tsvwg\@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Wed, 06 Nov 2019 07:49:25 -0800 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de> (Michael Scharf's message of "Wed, 6 Nov 2019 07:23:24 +0000") Message-ID: <87lfstgg3e.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 06 Nov 2019 15:49:49 -0000 "Scharf, Michael" writes: > Bob, > > I am not convinced by any of your statements. Me neither. Outside of this echo chamber no-one at any conference I've been to of late has heard of L4S.=20 I am recently back from the nanog+arin meetings in austin. (I'm not there on aqm related business, I'm trying to do something new in the NRO election [ https://www.youtube.com/playlist?list=3DPL726kQ53RX6imaiNabIZZKNZUmrBrT6pc ] ) ... but, being "mr bufferbloat", my self-selecting audience does come up to me and chat. I've enjoyed learning all the places where cake is penetrating in particular. I would think that the nanog folk in particular would have heard of l4s or SCE by now, but none had on this particular trip, and I find myself explaining it (in as neutral terms as I can muster), and the only thing that works is describing "classic" as "normal" traffic, and the l4s queue as dctcp-style, and even then, it's rare I don't have to burn 10s of minutes explaining any of it. I would vastly prefer that that the term normal, or RFC3168-compliant or -s= tyle be used instead of classic throughout these materials.=20 > > There are more than 500.000 hits in Google for =E2=80=9Enon-iPhone=E2=80= =9C and I see > many that are not about fakes. > > Certainly, I don=E2=80=99t insist in the term =E2=80=9Enon-L4S=E2=80=9C. = This is just an > example. I already proposed =E2=80=9Enon-L4S-enabled=E2=80=9C as well. I = fail to > understand how =E2=80=9Enon-L4S-enabled TCP=E2=80=9C could be confused wi= th =E2=80=9Enon-L4S > traffic=E2=80=9C. But, as outlined below, anyway there are other solution= s. > > Also, I don=E2=80=99t object to the term =E2=80=9EClassic=E2=80=9C when r= eferring to ECN and > other related concepts if that use of the term has strong TSVWG > consensus. For instance, "classic=E2=80=9C ECN feedback, =E2=80=9Eclassic= =E2=80=9C queue, > =E2=80=9Eclassic=E2=80=9C traffic would work for me in case TSVWG strongl= y supports > that term. > > Thus, personally, I am not asking for any disruptive change. I don=E2=80= =99t > ask to avoid =E2=80=9EClassic=E2=80=9C in general. > > What does *not* work for me is the term =E2=80=9EClassic=E2=80=9C TCP, in= particular > when refering to TCP as standardized by TCPM. I also don=E2=80=99t agree = to > the term =E2=80=9Eclassic=E2=80=9C congestion Control for Reno, CUBIC, CT= CP, i.e., > work of the TCPM working group. To me, the authors of this document do > not have the right to tag work of the TCPM working group with a term > such as =E2=80=9Eclassic=E2=80=9C that is used in marketing language. > > And there are plenty of simple ways to avoid that problematic term > =E2=80=9EClassic=E2=80=9C TCP. Here are some more examples: > > * TCP without the L4S extension > * TCP (senders/stacks/connections) not using L4S > * TCP without support of L4S > * TCP (senders/stacks/connections) lacking L4S support > * TCP (senders/stacks/connections) not participating in the L4S > experiment > * =E2=80=A6 and more and also permutations thereof > > You can also try to reword text to just to avoid the term =E2=80=9EClassi= c=E2=80=9C > TCP to work around the problem. > > Regarding congestion control, you can refer instead to > > * specific algorithms such as Reno or CUBIC=20 > * =E2=80=9Ehigh-speed loss-based congestion control=E2=80=9C > * or any of the above terms, e.g., =E2=80=9Econgestion control without L4S > support=E2=80=9C and the like > > My ask is a simple editorial change that will IMHO only affect few > occurences of the term =E2=80=9EClassic=E2=80=9C. Can you please propose = next steps > that addess my concern? > > Thanks > > Michael > > Von: Bob Briscoe > Gesendet: Mittwoch, 6. November 2019 01:22 > An: Scharf, Michael; Rodney W. Grimes > Cc: Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > Michael, Rod, > > Altho non-L4S is a reasonable idea, I think it has more of a negative > connotation than classic. For instance, consider describing Android > phones as non-iPhones. > > Also, in the ecn-l4s-id draft, we introduce the possibility that some > operators might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) > into the same queue as L4S traffic (and we say that in this case the > queue would be called the Low Latency queue). This shows that the term > non-L4S is not a good choice for a name, because the words it is made > from already give it a meaning of its own that conflicts with the > definition you want it to have in certain contexts. > > For example, if you did define the name "non-iPhone" to mean phones > such as Android, Windows, etc, then you would expect the phrase > "non-iPhone knock-off products" to mean "fake Android and Windows > phones". However the constituent elements "non" and "iPhone" already > have a meaning of their own, so in the context of this phrase, it > means "fake iPhones", which is the opposite of what you wanted. > > The term Classic for the non-L4S service, its queue, its traffic, its > congestion control, etc. is defined in the terminology section of the > drafts, so I think it's best to live with this - it's not a > significant problem. Indeed, it has become widely used and widely > understood since 2015, and changing it to non-L4S now would cause > unnecessary confusion. > > Bob > > On 04/11/2019 19:21, Scharf, Michael wrote: > >=20=20=20=20=20 > I agree. =E2=80=9Enon-L4S=E2=80=9C may be even better. > > Michael > >=20=20=20=20=20=20=20=20=20 > > Von: Rodney W. Grimes > Gesendet: Montag, 4. November 2019 20:17 > An: Scharf, Michael > Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > >=20=20=20=20=20 > > You can e.g. use ?non-L4S-enabled TCP?. > >=20 > > Terminology does matter to me given that I strongly disagree to > any use of ?marketing language? when it comes to TCP. >=20=20=20=20=20 > My concern here of use of terms like, legacy, classic, new, old > is that they are pretty much all of the relative from and thus > ambiguous over time. >=20=20=20=20=20 > newReno is new only relative to Reno, that is fairly clear, > but if I said newTCP or oldTCP with what frame should the > reference be evaluated. >=20=20=20=20=20 > I believe in the case of L4S the time invariant term would be, > as Michael suggests above, "non-L4S". Note that enabled > for me is a noise word in this context, and TCP may or may > not be needed depending on context, but for literal replacement > of Legacy or Classic "non-L4S" is invariant over time. >=20=20=20=20=20 > Rod >=20=20=20=20=20 > > Michael > >=20 > >=20 > > Von: Bob Briscoe > > Gesendet: Montag, 4. November 2019 19:09 > > An: Scharf, Michael; > Wesley Eddy; > tsvwg@ietf.org > > Cc: tcpm@ietf.org > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > >=20 > > Michael, > >=20 > > Previously, I have been told not to use the term standard for > RFCs that are not standards. RFC5681 is 'only' a draft standard. > This is why, in the IETF at least, I avoid using the term > "standard TCP congestion control". I generally call it Reno when > referring to the congestion control. > >=20 > > I have never, to my knowledge, used the term classic TCP, or > classic TCP congestion control. > >=20 > > And I rarely use the term legacy, and if I do I'm happy to have > alternatives suggested. > >=20 > > I've checked the L4S drafts, and there is one phrase that I > shall leave in ecn-l4s-id: "the traditional TCP Reno additive > increase", because this is correctly used to mean the traditional > increase (in numerous AIMD CCs), not traditional TCP. There was > one other occurrence of "traditional TCP senders" in a whole para > in an appendix that has just been deleted anyway. And in > aqm-dualq-coupled there was one "legacy TCP flows" (changed to > "Classic traffic" now in my local copy, using the defined term in > all the L4S drafts). > >=20 > > l4s-arch is getting a complete make-over for terminology, so I > will check that next. > >=20 > > inline... > >=20 > >=20 > > On 23/08/2019 15:01, Scharf, Michael wrote: > >=20 > > Hi Wes, > >=20 > >=20 > >=20 > > I?d 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. > >=20 > >=20 > >=20 > > As already noted in > https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKy= HY > , I object to the terms ?traditional TCP? and also ?classic TCP? > or ?legacy? TCP when referring to a TCP implementation according > to IETF standards-track RFCs. > >=20 > >=20 > >=20 > > To me as a non-native native speaker, all these terms have a > negative connotation. I also think this language is typical to > marketing material. > >=20 > > You're entitled to your opinion but, as a native speaker, I > don't think 'classic' or 'traditional' are particularly > pejorative, tho they can be when used in a context that intends > them to be. They also mean "stood the test of time". I find > 'legacy' has a connotation of marketing-speak, but it's not that > bad. > >=20 > > This is an enduring problem when trying to improve on the good > work that other people have done before you (which is the context > of everything we are doing). We need a word that distinguishes the > old from the new, but we don't want to completely trash the thing > that has already been successful, but had its day. > >=20 > > Nonetheless, it is also important not to be too precious about > past work. We all recognize that Reno TCP is unscalable and has > problems. IMO, it is OK to describe technologies that have had > their time with negative connotations. Indeed, you have been an > author (with me) of an RFC on open issues in congestion control. > >=20 > > I notice you haven't suggested an alternative term for "the > thing(s) we are trying to improve on". Not surprising, because > it's difficult. > >=20 > > When we (the L4S developers) were first looking for a term for > the non-L4S queue and the non-L4S service, we didn't want to use > 'legacy' for the above reasons, but we did want to imply > pre-existing, so we decided on 'classic', which we all felt had a > generally neutral connotation, but said what we meant. > >=20 > > Finally, I do not want this issue to take up any time that would > detract from technical issues. > >=20 > >=20 > >=20 > > Bob > >=20 > >=20 > >=20 > >=20 > > My prefered term when referring to TCP according to > standards-track specification 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. > >=20 > >=20 > >=20 > > Similarly, I think that term such as ?classic? is not > appropriate for the TCP standard congestion control (?Reno?). As > of today, this is the TCP congestion control 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. > >=20 > >=20 > >=20 > > 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 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 > and I don?t ask for changes in those cases. > >=20 > >=20 > >=20 > > Some use of the term ?Classic Service? may also require careful > review to clearly separate it from TCP Standard behavior. > >=20 > >=20 > >=20 > > 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 speaker, it would be really strange to use the > term ?classic? in the context of a brand-new transport protocol. > IMHO in that case the term ?classic? would be even more confusing. > >=20 > >=20 > >=20 > > I also add the TCPM list in CC to ensure consistency. > >=20 > >=20 > >=20 > > Thanks > >=20 > >=20 > >=20 > > Michael (with no hat) > >=20 > >=20 > >=20 > >=20 > >=20 > > Von: Wesley Eddy > > Gesendet: Sonntag, 11. August 2019 07:08 > > An: tsvwg@ietf.org > > Betreff: [tsvwg] L4S status tracking > >=20 > >=20 > >=20 > > 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: > >=20 > > > https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&page= =3D1 > >=20 > > 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. > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > >=20 > >=20 > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ >=20=20=20=20=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20=20=20=20=20 > --=20 > Rod Grimes rgrimes@freebsd.org From nobody Wed Nov 6 10:12: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 3BB31120147; Wed, 6 Nov 2019 10:12:40 -0800 (PST) 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, HTML_MESSAGE=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=bobbriscoe.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 w7tnxKdF8WfE; Wed, 6 Nov 2019 10:12:35 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1E51112011C; Wed, 6 Nov 2019 10:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=WB9fxRiN3br6wvpEyzAnr24w8m9+9dbE0Yo/xv8csAU=; b=k2hL83TkTCk2aGEwZU/IvZwRd 1n0+A162VyP9GrXMPmdp3V/VNRZZbjXSS1n94LYkuqPViBuDWzwe2Rzuq740QnDntqJ2ciDCTXE0o V6hwkvhA5B0HsPJ9XfH0pTnhw+qrPJ+3VmB8QqFKpj2l8cK6EjsYtkqWgN/vkFS8oyczXzcKqcC1Q yakdb24+KO2IIBu+F0UoGMvN6oFJK0zuUjwF1NxCh3sQ1fmQoicySEeKzAjms2CbXK8k5Oo+ioBtz SlvsfGZ+JU626z+AtWqJzxly8FS7Aeb4Ncikj0ZEx3C/d+N4I4Sv4V8xMfoLYwx1Fa3yKoGhpSvum RFv2mj/jQ==; Received: from [31.185.128.31] (port=39482 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iSPnD-0008JY-01; Wed, 06 Nov 2019 18:12:31 +0000 To: Sebastian Moeller , "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> From: Bob Briscoe Message-ID: <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net> Date: Wed, 6 Nov 2019 18:12:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> Content-Type: multipart/alternative; boundary="------------0B2118F2C69EDC6809CAED7E" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net 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: Wed, 06 Nov 2019 18:12:40 -0000 This is a multi-part message in MIME format. --------------0B2118F2C69EDC6809CAED7E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sebastien, On 06/11/2019 07:18, Sebastian Moeller wrote: > Hi Bob, > > On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe wrote: >> Michael, Rod, >> >> Altho non-L4S is a reasonable idea, I think it has more of a negative >> connotation than classic. > [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before. Which is a good starting point, because that's what is intended. Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2 > > For instance, consider describing Android >> phones as non-iPhones. > [SM] In a discussion of say the merits of iPhones versus the competition that seems to be a decent description? It is a decent description of the set of all phones that are not iPhones. But it has negative connotations when describing an instance, as in "Oh, you've got a non-iPhone" Just as it is fine to use the phrase 'non-white people' when publishing the results of a survey comparing privileges for white people versus everyone else. But it would be totally insulting to describe black people as non-white people. > >> For example, if you did define the name "non-iPhone" to mean phones >> such >> as Android, Windows, etc, then you would expect the phrase "non-iPhone >> knock-off products" to mean "fake Android and Windows phones". However >> the constituent elements "non" and "iPhone" already have a meaning of >> their own, so in the context of this phrase, it means "fake iPhones", >> which is the opposite of what you wanted. > [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words. [BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective). I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1. Then in this context, "Non-L4S" naturally means A - L1. However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1. So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context. It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean. >> The term Classic for the non-L4S service, its queue, its traffic, its >> congestion control, etc. is defined in the terminology section of the >> drafts, so I think it's best to live with this - it's not a significant >> >> problem. > [SM] If it is not significant, then changing it surely is not a problem? [BB] Changing it to a problematic name like non-L4S (as explained above) would be a problem. Leaving it as it is, is not a significant problem, particularly because we chose Classic because it had the least negative connotation of all the words the thesaurus could throw at us. So this is obviously quite a subtle dependence on the mindset of the individuals involved. > > Indeed, it has become widely used and widely understood since >> 2015, and changing it to non-L4S now would cause unnecessary confusion. > [SM] By that logic nothing in the L4S drafts should be changed? If I recall correctly that is not how getting a draft past reviewers works.... Not at all. The aim of review is to ensure a draft is clearer - you will see we've made literally hundreds of changes already in response to those sort of requests. A reviewer doesn't have an automatic right to have all their requests satisfied, if they are not considered useful by the draft editor (or WG consensus if nec.) I am resisting all the suggestions for a change of name so far, because "non-L4S" has the context-dependence problem I've already described. And all the other suggestions already have at best roughly equal negative connotations to Classic. Anyway, nearly any choice of name for "something intended to be superseded" will develop negative connotations as soon as it is defined, even if it was completely meaningless when first coined. A huge amount of care went into getting the names right, before we started. I remember quoting Dijkstra at my colleagues at the time (I can't find the quote right now, but it's about how choice of names is paramount in programming). This one is nearly as relevant: /"Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. "/ Edsger Dijkstra Bob > >> >> >> Bob >> >> >> >> On 04/11/2019 19:21, Scharf, Michael wrote: >>> I agree. „non-L4S“ may be even better. >>> >>> Michael >>> >>> *Von: *Rodney W. Grimes >>> *Gesendet: *Montag, 4. November 2019 20:17 >>> *An: *Scharf, Michael >>> *Cc: *Bob Briscoe ; Wesley Eddy >>> ; tsvwg@ietf.org ; >>> tcpm@ietf.org >>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking >>> >>>> You can e.g. use ?non-L4S-enabled TCP?. >>>> >>>> Terminology does matter to me given that I strongly disagree to any >>> use of ?marketing language? when it comes to TCP. >>> >>> My concern here of use of terms like, legacy, classic, new, old >>> is that they are pretty much all of the relative from and thus >>> ambiguous over time. >>> >>> newReno is new only relative to Reno, that is fairly clear, >>> but if I said newTCP or oldTCP with what frame should the >>> reference be evaluated. >>> >>> I believe in the case of L4S the time invariant term would be, >>> as Michael suggests above, "non-L4S".   Note that enabled >>> for me is a noise word in this context, and TCP may or may >>> not be needed depending on context, but for literal replacement >>> of Legacy or Classic "non-L4S" is invariant over time. >>> >>> Rod >>> >>>> Michael >>>> >>>> >>>> Von: Bob Briscoe >>>> Gesendet: Montag, 4. November 2019 19:09 >>>> An: Scharf, Michael; Wesley >>> Eddy; >> tsvwg@ietf.org >>>> Cc: tcpm@ietf.org >>>> Betreff: Re: [tcpm] [tsvwg] L4S status tracking >>>> >>>> Michael, >>>> >>>> Previously, I have been told not to use the term standard for RFCs >>> that are not standards. RFC5681 is 'only' a draft standard. This is >>> why, in the IETF at least, I avoid using the term "standard TCP >>> congestion control". I generally call it Reno when referring to the >>> congestion control. >>>> I have never, to my knowledge, used the term classic TCP, or >> classic >>> TCP congestion control. >>>> And I rarely use the term legacy, and if I do I'm happy to have >>> alternatives suggested. >>>> I've checked the L4S drafts, and there is one phrase that I shall >>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase", >>> because this is correctly used to mean the traditional increase (in >>> numerous AIMD CCs), not traditional TCP. There was one other >>> occurrence of "traditional TCP senders" in a whole para in an >> appendix >>> that has just been deleted anyway. And in aqm-dualq-coupled there was >>> one "legacy TCP flows" (changed to "Classic traffic" now in my local >>> copy, using the defined term in all the L4S drafts). >>>> l4s-arch is getting a complete make-over for terminology, so I will >>> check that next. >>>> inline... >>>> >>>> >>>> On 23/08/2019 15:01, Scharf, Michael wrote: >>>> >>>> Hi Wes, >>>> >>>> >>>> >>>> I?d 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-hDvWO3I5MudwpNkKyHY >> >>> , I object to the terms ?traditional TCP? and also ?classic TCP? or >>> ?legacy? TCP when referring to a TCP implementation according to IETF >>> standards-track RFCs. >>>> >>>> >>>> To me as a non-native native speaker, all these terms have a >>> negative connotation. I also think this language is typical to >>> marketing material. >>>> You're entitled to your opinion but, as a native speaker, I don't >>> think 'classic' or 'traditional' are particularly pejorative, tho >> they >>> can be when used in a context that intends them to be. They also mean >>> "stood the test of time". I find 'legacy' has a connotation of >>> marketing-speak, but it's not that bad. >>>> This is an enduring problem when trying to improve on the good work >>> that other people have done before you (which is the context of >>> everything we are doing). We need a word that distinguishes the old >>> from the new, but we don't want to completely trash the thing that >> has >>> already been successful, but had its day. >>>> Nonetheless, it is also important not to be too precious about past >>> work. We all recognize that Reno TCP is unscalable and has problems. >>> IMO, it is OK to describe technologies that have had their time with >>> negative connotations. Indeed, you have been an author (with me) of >> an >>> RFC on open issues in congestion control. >>>> I notice you haven't suggested an alternative term for "the >> thing(s) >>> we are trying to improve on". Not surprising, because it's difficult. >>>> When we (the L4S developers) were first looking for a term for the >>> non-L4S queue and the non-L4S service, we didn't want to use 'legacy' >>> for the above reasons, but we did want to imply pre-existing, so we >>> decided on 'classic', which we all felt had a generally neutral >>> connotation, but said what we meant. >>>> Finally, I do not want this issue to take up any time that would >>> detract from technical issues. >>>> >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> My prefered term when referring to TCP according to standards-track >>> specification 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 TCP standard congestion control (?Reno?). As of today, this >> is >>> the TCP congestion control 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 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 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 and I don?t ask for changes >>> in those cases. >>>> >>>> >>>> Some use of the term ?Classic Service? may also require careful >>> review to clearly 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 speaker, it would be really strange to use the term >>> ?classic? in the context of a brand-new transport protocol. IMHO in >>> that case the term ?classic? 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=ticket&asc=1&page=1 >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> >>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> -- >>> Rod Grimes rgrimes@freebsd.org -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------0B2118F2C69EDC6809CAED7E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sebastien,

On 06/11/2019 07:18, Sebastian Moeller wrote:
Hi Bob,

On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Michael, Rod,

Altho non-L4S is a reasonable idea, I think it has more of a negative 
connotation than classic. 

        [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
Which is a good starting point, because that's what is intended. Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2



For instance, consider describing Android 

phones as non-iPhones.

         [SM] In a discussion of say the merits of iPhones versus the competition that seems to be a decent description?
It is a decent description of the set of all phones that are not iPhones. But it has negative connotations when describing an instance, as in "Oh, you've got a non-iPhone"

Just as it is fine to use the phrase 'non-white people' when publishing the results of a survey comparing privileges for white people versus everyone else. But it would be totally insulting to describe black people as non-white people.


For example, if you did define the name "non-iPhone" to mean phones
such 
as Android, Windows, etc, then you would expect the phrase "non-iPhone 
knock-off products" to mean "fake Android and Windows phones". However 
the constituent elements "non" and "iPhone" already have a meaning of 
their own, so in the context of this phrase, it means "fake iPhones", 
which is the opposite of what you wanted.

        [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.
[BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective).

I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1.
Then in this context, "Non-L4S" naturally means A - L1.

However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1.

So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context.

It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean.


      

        
The term Classic for the non-L4S service, its queue, its traffic, its 
congestion control, etc. is defined in the terminology section of the 
drafts, so I think it's best to live with this - it's not a significant

problem. 


      

      
        [SM] If it is not significant, then changing it surely is not a problem?

    

    [BB] Changing it to a problematic name like non-L4S (as explained
    above) would be a problem. 

    

    Leaving it as it is, is not a significant problem, particularly
    because we chose Classic because it had the least negative
    connotation of all the words the thesaurus could throw at us. So
    this is obviously quite a subtle dependence on the mindset of the
    individuals involved.

    

    

    

      

Indeed, it has become widely used and widely understood since 


      

        
2015, and changing it to non-L4S now would cause unnecessary confusion.


      

      
        [SM] By that logic nothing in the L4S drafts should be changed? If I recall correctly that is not how getting a draft past reviewers works....

    

    Not at all. The aim of review is to ensure a draft is clearer - you
    will see we've made literally hundreds of changes already in
    response to those sort of requests. A reviewer doesn't have an
    automatic right to have all their requests satisfied, if they are
    not considered useful by the draft editor (or WG consensus if nec.)

    

    I am resisting all the suggestions for a change of name so far,
    because "non-L4S" has the context-dependence problem I've already
    described. And all the other suggestions already have at best
    roughly equal negative connotations to Classic.

    

    Anyway, nearly any choice of name for "something intended to be
    superseded" will develop negative connotations as soon as it is
    defined, even if it was completely meaningless when first coined. 

    

    A huge amount of care went into getting the names right, before we
    started. I remember quoting Dijkstra at my colleagues at the time (I
    can't find the quote right now, but it's about how choice of names
    is paramount in programming). This one is nearly as relevant: 

    

      "Besides a mathematical inclination, an exceptionally good
        mastery of one’s native tongue is the most vital asset of a
        competent programmer.
        " Edsger Dijkstra
    

    

    

    

    Bob

    

    

    

      



      

        


Bob



On 04/11/2019 19:21, Scharf, Michael wrote:


        

          
I agree. „non-L4S“ may be even better.

Michael

*Von: *Rodney W. Grimes <mailto:4bone@gndrsh.dnsmgr.net>
*Gesendet: *Montag, 4. November 2019 20:17
*An: *Scharf, Michael <mailto:Michael.Scharf@hs-esslingen.de>
*Cc: *Bob Briscoe <mailto:ietf@bobbriscoe.net>; Wesley Eddy 
<mailto:wes@mti-systems.com>; tsvwg@ietf.org <mailto:tsvwg@ietf.org>;


        

        

        

          
tcpm@ietf.org <mailto:tcpm@ietf.org>
*Betreff: *Re: [tcpm] [tsvwg] L4S status tracking



          

            
You can e.g. use ?non-L4S-enabled TCP?.

Terminology does matter to me given that I strongly disagree to any


          

        

        

        

          
use of ?marketing language? when it comes to TCP.

My concern here of use of terms like, legacy, classic, new, old
is that they are pretty much all of the relative from and thus
ambiguous over time.

newReno is new only relative to Reno, that is fairly clear,
but if I said newTCP or oldTCP with what frame should the
reference be evaluated.

I believe in the case of L4S the time invariant term would be,
as Michael suggests above, "non-L4S".   Note that enabled
for me is a noise word in this context, and TCP may or may
not be needed depending on context, but for literal replacement
of Legacy or Classic "non-L4S" is invariant over time.

Rod



          

            
Michael


Von: Bob Briscoe<mailto:ietf@bobbriscoe.net>
Gesendet: Montag, 4. November 2019 19:09
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley 


          

          
Eddy<mailto:wes@mti-systems.com>;


        

        
tsvwg@ietf.org<mailto:tsvwg@ietf.org>


        

          

            
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

Michael,

Previously, I have been told not to use the term standard for RFCs 


          

          
that are not standards. RFC5681 is 'only' a draft standard. This is 
why, in the IETF at least, I avoid using the term "standard TCP 
congestion control". I generally call it Reno when referring to the 
congestion control.


          

            
I have never, to my knowledge, used the term classic TCP, or


          

        

        
classic 


        

          
TCP congestion control.


          

            
And I rarely use the term legacy, and if I do I'm happy to have 


          

          
alternatives suggested.


          

            
I've checked the L4S drafts, and there is one phrase that I shall 


          

          
leave in ecn-l4s-id: "the traditional TCP Reno additive increase", 
because this is correctly used to mean the traditional increase (in 
numerous AIMD CCs), not traditional TCP. There was one other 
occurrence of "traditional TCP senders" in a whole para in an


        

        
appendix 


        

          
that has just been deleted anyway. And in aqm-dualq-coupled there was


        

        

        

          
one "legacy TCP flows" (changed to "Classic traffic" now in my local 
copy, using the defined term in all the L4S drafts).


          

            
l4s-arch is getting a complete make-over for terminology, so I will


          

        

        

        

          
check that next.


          

            
inline...


On 23/08/2019 15:01, Scharf, Michael wrote:

Hi Wes,



I?d 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-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY>



        

          
, I object to the terms ?traditional TCP? and also ?classic TCP? or 
?legacy? TCP when referring to a TCP implementation according to IETF


        

        

        

          
standards-track RFCs.


          

            


To me as a non-native native speaker, all these terms have a 


          

          
negative connotation. I also think this language is typical to 
marketing material.


          

            
You're entitled to your opinion but, as a native speaker, I don't 


          

          
think 'classic' or 'traditional' are particularly pejorative, tho


        

        
they 


        

          
can be when used in a context that intends them to be. They also mean


        

        

        

          
"stood the test of time". I find 'legacy' has a connotation of 
marketing-speak, but it's not that bad.


          

            
This is an enduring problem when trying to improve on the good work


          

        

        

        

          
that other people have done before you (which is the context of 
everything we are doing). We need a word that distinguishes the old 
from the new, but we don't want to completely trash the thing that


        

        
has 


        

          
already been successful, but had its day.


          

            
Nonetheless, it is also important not to be too precious about past


          

        

        

        

          
work. We all recognize that Reno TCP is unscalable and has problems. 
IMO, it is OK to describe technologies that have had their time with 
negative connotations. Indeed, you have been an author (with me) of


        

        
an 


        

          
RFC on open issues in congestion control.


          

            
I notice you haven't suggested an alternative term for "the


          

        

        
thing(s) 


        

          
we are trying to improve on". Not surprising, because it's difficult.


          

            
When we (the L4S developers) were first looking for a term for the 


          

          
non-L4S queue and the non-L4S service, we didn't want to use 'legacy'


        

        

        

          
for the above reasons, but we did want to imply pre-existing, so we 
decided on 'classic', which we all felt had a generally neutral 
connotation, but said what we meant.


          

            
Finally, I do not want this issue to take up any time that would 


          

          
detract from technical issues.


          

            


Bob




My prefered term when referring to TCP according to standards-track


          

        

        

        

          
specification 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 TCP standard congestion control (?Reno?). As of today, this


        

        
is 


        

          
the TCP congestion control 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 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 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 and I don?t ask for changes 
in those cases.


          

            


Some use of the term ?Classic Service? may also require careful 


          

          
review to clearly 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 speaker, it would be really strange to use the term 
?classic? in the context of a brand-new transport protocol. IMHO in 
that case the term ?classic? would be even more confusing.


          

            


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



Thanks



Michael (with no hat)





Von: Wesley Eddy<mailto:wes@mti-systems.com>
Gesendet: Sonntag, 11. August 2019 07:08
An: tsvwg@ietf.org<mailto: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=ticket&asc=1&page=1

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.


        

          

            




_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm



--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/


          

          

          

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


          

          
-- 
Rod Grimes rgrimes@freebsd.org


        

      

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------0B2118F2C69EDC6809CAED7E--


From nobody Wed Nov  6 10:36:48 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 E2D5312011C; Wed,  6 Nov 2019 10:36:45 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 CS_NdBtBxXEU; Wed,  6 Nov 2019 10:36:42 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 840111200F1; Wed,  6 Nov 2019 10:36:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=d5XXrySn0WiTqFbYB0jY9DUcnk9Cvt7MkaqI/Jv+PpM=; b=59rB5cwDJBGyc5nQZauGoJdGq dZlEXwaHqazHUpMBxxuOCpJa/k5t4S3Ysh+kIJ4Wkoj8JB+LEUPzEQSZrGxx21NybNK9vtzT1mhtU E9O9pWbVMGQf0VeLeWWUlU+7uMvQqXaJgzq4mgTgN+l2710Gu5lNE5Ia9CDmHDETtdYHfY7R/VnhK sFXKmhTAi1RRhCPrae+KiiKebnV5xHdAob/xiF0Q/Eekij3/a206PLu8mukwtDoMnvJIvmiss02Qa NvQ6V8kf3fjKKoWUeLNRQsAZs0LL86m0IVsR0ojcKDEKr9CnmASpvnLLRXz4hEfNbWyyyjbzPFZwj /nZtO8qtA==;
Received: from [31.185.128.31] (port=39542 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iSQAY-00047m-4g; Wed, 06 Nov 2019 18:36:38 +0000
To: "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: Wesley Eddy , "tsvwg@ietf.org" , "tcpm@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Bob Briscoe 
Message-ID: 
Date: Wed, 6 Nov 2019 18:36:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------55C4F94FFDD19FAEF04A8A6D"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Wed, 06 Nov 2019 18:36:46 -0000

This is a multi-part message in MIME format.
--------------55C4F94FFDD19FAEF04A8A6D
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Michael,

Regarding the only usage you say you do object to, I've already said...

On 04/11/2019 18:09, Bob Briscoe wrote:
> I have never, to my knowledge, used the term classic TCP, or classic 
> TCP congestion control.

...because Classic is intended as a a description of a set of congestion 
controls. The protocol is relatively irrelevant.

Pls see my response to Sebastien concerning the slightly positive 
connotation of the word 'classic'.
And how even a nonsense word coined for "something intended to be 
superseded" will develop a negative connotation as soon as it is defined.
This implies that the problem you've raised is impossible to solve 
without upsetting certain sensitive people.


Bob

On 06/11/2019 07:23, Scharf, Michael wrote:
>
> Bob,
>
> I am not convinced by any of your statements.
>
> There are more than 500.000 hits in Google for non-iPhone and I see 
> many that are not about fakes.
>
> Certainly, I dont insist in the term non-L4S. This is just an 
> example. I already proposed non-L4S-enabled as well. I fail to 
> understand how non-L4S-enabled TCP could be confused with non-L4S 
> traffic. But, as outlined below, anyway there are other solutions.
>
> Also, I dont object to the term Classic when referring to ECN and 
> other related concepts if that use of the term has strong TSVWG 
> consensus. For instance, "classic ECN feedback, classic queue, 
> classic traffic would work for me in case TSVWG strongly supports 
> that term.
>
> Thus, personally, I am not asking for any disruptive change. I dont 
> ask to avoid Classic in general.
>
> What does **not** work for me is the term Classic TCP, in particular 
> when refering to TCP as standardized by TCPM. I also dont agree to 
> the term classic congestion Control for Reno, CUBIC, CTCP, i.e., 
> work of the TCPM working group. To me, the authors of this document do 
> not have the right to tag work of the TCPM working group with a term 
> such as classic that is used in marketing language.
>
> And there are plenty of simple ways to avoid that problematic term 
> Classic TCP. Here are some more examples:
>
>   * TCP without the L4S extension
>   * TCP (senders/stacks/connections) not using L4S
>   * TCP without support of L4S
>   * TCP (senders/stacks/connections) lacking L4S support
>   * TCP (senders/stacks/connections) not participating in the L4S
>     experiment
>   *  and more and also permutations thereof
>
> You can also try to reword text to just to avoid the term Classic 
> TCP to work around the problem.
>
> Regarding congestion control, you can refer instead to
>
>   * specific algorithms such as Reno or CUBIC
>   * high-speed loss-based congestion control
>   * or any of the above terms, e.g., congestion control without L4S
>     support and the like
>
> My ask is a simple editorial change that will IMHO only affect few 
> occurences of the term Classic. Can you please propose next steps 
> that addess my concern?
>
> Thanks
>
> Michael
>
> *Von: *Bob Briscoe 
> *Gesendet: *Mittwoch, 6. November 2019 01:22
> *An: *Scharf, Michael ; Rodney 
> W. Grimes 
> *Cc: *Wesley Eddy ; tsvwg@ietf.org 
> ; tcpm@ietf.org 
> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael, Rod,
>
> Altho non-L4S is a reasonable idea, I think it has more of a negative 
> connotation than classic. For instance, consider describing Android 
> phones as non-iPhones.
>
> Also, in the ecn-l4s-id draft, we introduce the possibility that some 
> operators might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) 
> into the same queue as L4S traffic (and we say that in this case the 
> queue would be called the Low Latency queue). This shows that the term 
> non-L4S is not a good choice for a name, because the words it is made 
> from already give it a meaning of its own that conflicts with the 
> definition you want it to have in certain contexts.
>
> For example, if you did define the name "non-iPhone" to mean phones 
> such as Android, Windows, etc, then you would expect the phrase 
> "non-iPhone knock-off products" to mean "fake Android and Windows 
> phones". However the constituent elements "non" and "iPhone" already 
> have a meaning of their own, so in the context of this phrase, it 
> means "fake iPhones", which is the opposite of what you wanted.
>
> The term Classic for the non-L4S service, its queue, its traffic, its 
> congestion control, etc. is defined in the terminology section of the 
> drafts, so I think it's best to live with this - it's not a 
> significant problem. Indeed, it has become widely used and widely 
> understood since 2015, and changing it to non-L4S now would cause 
> unnecessary confusion.
>
>
>
> Bob
>
>
>
> On 04/11/2019 19:21, Scharf, Michael wrote:
>>
>> I agree. non-L4S may be even better.
>>
>> Michael
>>
>> *Von: *Rodney W. Grimes 
>> *Gesendet: *Montag, 4. November 2019 20:17
>> *An: *Scharf, Michael 
>> *Cc: *Bob Briscoe ; Wesley Eddy 
>> ; tsvwg@ietf.org ; 
>> tcpm@ietf.org 
>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>>
>> > You can e.g. use ?non-L4S-enabled TCP?.
>> >
>> > Terminology does matter to me given that I strongly disagree to any 
>> use of ?marketing language? when it comes to TCP.
>>
>> My concern here of use of terms like, legacy, classic, new, old
>> is that they are pretty much all of the relative from and thus
>> ambiguous over time.
>>
>> newReno is new only relative to Reno, that is fairly clear,
>> but if I said newTCP or oldTCP with what frame should the
>> reference be evaluated.
>>
>> I believe in the case of L4S the time invariant term would be,
>> as Michael suggests above, "non-L4S". Note that enabled
>> for me is a noise word in this context, and TCP may or may
>> not be needed depending on context, but for literal replacement
>> of Legacy or Classic "non-L4S" is invariant over time.
>>
>> Rod
>>
>> > Michael
>> >
>> >
>> > Von: Bob Briscoe
>> > Gesendet: Montag, 4. November 2019 19:09
>> > An: Scharf, Michael; Wesley 
>> Eddy; tsvwg@ietf.org
>> > Cc: tcpm@ietf.org
>> > Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>> >
>> > Michael,
>> >
>> > Previously, I have been told not to use the term standard for RFCs 
>> that are not standards. RFC5681 is 'only' a draft standard. This is 
>> why, in the IETF at least, I avoid using the term "standard TCP 
>> congestion control". I generally call it Reno when referring to the 
>> congestion control.
>> >
>> > I have never, to my knowledge, used the term classic TCP, or 
>> classic TCP congestion control.
>> >
>> > And I rarely use the term legacy, and if I do I'm happy to have 
>> alternatives suggested.
>> >
>> > I've checked the L4S drafts, and there is one phrase that I shall 
>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase", 
>> because this is correctly used to mean the traditional increase (in 
>> numerous AIMD CCs), not traditional TCP. There was one other 
>> occurrence of "traditional TCP senders" in a whole para in an 
>> appendix that has just been deleted anyway. And in aqm-dualq-coupled 
>> there was one "legacy TCP flows" (changed to "Classic traffic" now in 
>> my local copy, using the defined term in all the L4S drafts).
>> >
>> > l4s-arch is getting a complete make-over for terminology, so I will 
>> check that next.
>> >
>> > inline...
>> >
>> >
>> > On 23/08/2019 15:01, Scharf, Michael wrote:
>> >
>> > Hi Wes,
>> >
>> >
>> >
>> > I?d 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-hDvWO3I5MudwpNkKyHY 
>> , I object to the terms ?traditional TCP? and also ?classic TCP? or 
>> ?legacy? TCP when referring to a TCP implementation according to IETF 
>> standards-track RFCs.
>> >
>> >
>> >
>> > To me as a non-native native speaker, all these terms have a 
>> negative connotation. I also think this language is typical to 
>> marketing material.
>> >
>> > You're entitled to your opinion but, as a native speaker, I don't 
>> think 'classic' or 'traditional' are particularly pejorative, tho 
>> they can be when used in a context that intends them to be. They also 
>> mean "stood the test of time". I find 'legacy' has a connotation of 
>> marketing-speak, but it's not that bad.
>> >
>> > This is an enduring problem when trying to improve on the good work 
>> that other people have done before you (which is the context of 
>> everything we are doing). We need a word that distinguishes the old 
>> from the new, but we don't want to completely trash the thing that 
>> has already been successful, but had its day.
>> >
>> > Nonetheless, it is also important not to be too precious about past 
>> work. We all recognize that Reno TCP is unscalable and has problems. 
>> IMO, it is OK to describe technologies that have had their time with 
>> negative connotations. Indeed, you have been an author (with me) of 
>> an RFC on open issues in congestion control.
>> >
>> > I notice you haven't suggested an alternative term for "the 
>> thing(s) we are trying to improve on". Not surprising, because it's 
>> difficult.
>> >
>> > When we (the L4S developers) were first looking for a term for the 
>> non-L4S queue and the non-L4S service, we didn't want to use 'legacy' 
>> for the above reasons, but we did want to imply pre-existing, so we 
>> decided on 'classic', which we all felt had a generally neutral 
>> connotation, but said what we meant.
>> >
>> > Finally, I do not want this issue to take up any time that would 
>> detract from technical issues.
>> >
>> >
>> >
>> > Bob
>> >
>> >
>> >
>> >
>> > My prefered term when referring to TCP according to standards-track 
>> specification 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 TCP standard congestion control (?Reno?). As of today, this 
>> is the TCP congestion control 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 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 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 and I don?t ask for changes 
>> in those cases.
>> >
>> >
>> >
>> > Some use of the term ?Classic Service? may also require careful 
>> review to clearly 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 speaker, it would be really strange to use the term 
>> ?classic? in the context of a brand-new transport protocol. IMHO in 
>> that case the term ?classic? 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=ticket&asc=1&page=1
>> >
>> > 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.
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcpm
>> >
>> >
>> >
>> > --
>> > ________________________________________________________________
>> > Bob Briscoe http://bobbriscoe.net/
>>
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcpm
>>
>> -- 
>> Rod Grimes rgrimes@freebsd.org
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------55C4F94FFDD19FAEF04A8A6D
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    Regarding the only usage you say you do object to, I've already
    said...

    

    
On 04/11/2019 18:09, Bob Briscoe wrote:

    

    
I
      have never, to my knowledge, used the term classic TCP, or classic
      TCP congestion control.

    

    ...because Classic is intended as a a description of a set of
    congestion controls. The protocol is relatively irrelevant.

    

    Pls see my response to Sebastien concerning the slightly positive
    connotation of the word 'classic'. 

    And how even a nonsense word coined for "something intended to be
    superseded" will develop a negative connotation as soon as it is
    defined. 

    This implies that the problem you've raised is impossible to solve
    without upsetting certain sensitive people.

    

    

    Bob

    

    
On 06/11/2019 07:23, Scharf, Michael
      wrote:

    

    

      
      
      

        
Bob,

        

        
I am not convinced by any of your
          statements.

        

        
There are more than 500.000 hits in Google
          for non-iPhone and I see many that are not about fakes.

        

        
Certainly, I dont insist in the term
          non-L4S. This is just an example. I already proposed
          non-L4S-enabled as well. I fail to understand how
          non-L4S-enabled TCP could be confused with non-L4S
          traffic. But, as outlined below, anyway there are other
          solutions.

        

        
Also, I dont object to the term Classic
          when referring to ECN and other related concepts if that use
          of the term has strong TSVWG consensus. For instance,
          "classic ECN feedback, classic queue, classic traffic
          would work for me in case TSVWG strongly supports that term.

        

        
Thus, personally, I am not asking for any
          disruptive change. I dont ask to avoid Classic in general.

        

        
What does *not* work for me is the
          term Classic TCP, in particular when refering to TCP as
          standardized by TCPM. I also dont agree to the term classic
          congestion Control for Reno, CUBIC, CTCP, i.e., work of the
          TCPM working group. To me, the authors of this document do not
          have the right to tag work of the TCPM working group with a
          term such as classic that is used in marketing language.

        

        
And there are plenty of simple ways to
          avoid that problematic term Classic TCP. Here are some more
          examples:

        
    
          
  • TCP
            without the L4S extension
    • 
          
  • TCP
            (senders/stacks/connections) not using L4S
    • 
          
  • TCP
            without support of L4S
    • 
          
  • TCP
            (senders/stacks/connections) lacking L4S support
    • 
          
  • TCP
            (senders/stacks/connections) not participating in the L4S
            experiment
    • 
          
  •  and
            more and also permutations thereof
    • 
        

        

        
You can also try to reword text to just to
          avoid the term Classic TCP to work around the problem.

        

        
Regarding congestion control, you can refer
          instead to

        
    
          
  • specific
            algorithms such as Reno or CUBIC
          
    • 
          
  • high-speed
            loss-based congestion control
    • 
          
  • or any of
            the above terms, e.g., congestion control without L4S
            support and the like
    • 
        

        

        
My ask is a simple editorial change that
          will IMHO only affect few occurences of the term Classic.
          Can you please propose next steps that addess my concern?

        

        
Thanks

        

        
Michael

        

        

        

          
Von:
            Bob Briscoe

            Gesendet: Mittwoch, 6. November 2019 01:22

            An: Scharf, Michael; 
              Rodney W. Grimes

            Cc: Wesley Eddy; 
              tsvwg@ietf.org; tcpm@ietf.org

            Betreff: Re: [tcpm] [tsvwg] L4S status tracking

        

        

      

      
Michael, Rod,

        

        Altho non-L4S is a reasonable idea, I think it has more of a
        negative connotation than classic. For instance, consider
        describing Android phones as non-iPhones.

        

        Also, in the ecn-l4s-id draft, we introduce the possibility that
        some operators might classify non-L4S traffic (DNS, VoIP, EF,
        NQB, etc) into the same queue as L4S traffic (and we say that in
        this case the queue would be called the Low Latency queue). This
        shows that the term non-L4S is not a good choice for a name,
        because the words it is made from already give it a meaning of
        its own that conflicts with the definition you want it to have
        in certain contexts.

        

        For example, if you did define the name "non-iPhone" to mean
        phones such as Android, Windows, etc, then you would expect the
        phrase "non-iPhone knock-off products" to mean "fake Android and
        Windows phones". However the constituent elements "non" and
        "iPhone" already have a meaning of their own, so in the context
        of this phrase, it means "fake iPhones", which is the opposite
        of what you wanted.

        

        The term Classic for the non-L4S service, its queue, its
        traffic, its congestion control, etc. is defined in the
        terminology section of the drafts, so I think it's best to live
        with this - it's not a significant problem. Indeed, it has
        become widely used and widely understood since 2015, and
        changing it to non-L4S now would cause unnecessary confusion.

        

        

        

        Bob

        

        

        

        
On 04/11/2019 19:21, Scharf,
          Michael wrote:

        

        

          
          
          

            

              
I agree. non-L4S may be even
                better.

              

              
Michael

              

              

              

                
Von:
                  Rodney W. Grimes

                  Gesendet: Montag, 4. November 2019 20:17

                  An: Scharf, Michael

                  Cc: Bob Briscoe; 
                    Wesley Eddy; tsvwg@ietf.org; 
                    tcpm@ietf.org

                  Betreff: Re: [tcpm] [tsvwg] L4S status
                  tracking

              

              

            

          

          
              
> You can e.g. use
                ?non-L4S-enabled TCP?.

                > 

                > Terminology does matter to me given that I strongly
                disagree to any use of ?marketing language? when it
                comes to TCP.

                

                My concern here of use of terms like, legacy, classic,
                new, old

                is that they are pretty much all of the relative from
                and thus

                ambiguous over time.

                

                newReno is new only relative to Reno, that is fairly
                clear,

                but if I said newTCP or oldTCP with what frame should
                the

                reference be evaluated.

                

                I believe in the case of L4S the time invariant term
                would be,

                as Michael suggests above, "non-L4S". Note that
                enabled

                for me is a noise word in this context, and TCP may or
                may

                not be needed depending on context, but for literal
                replacement

                of Legacy or Classic "non-L4S" is invariant over time.

                

                Rod

                

                > Michael

                > 

                > 

                > Von: Bob Briscoe<mailto:ietf@bobbriscoe.net>

                > Gesendet: Montag, 4. November 2019 19:09

                > An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>;
                Wesley Eddy<mailto:wes@mti-systems.com>;
                tsvwg@ietf.org<mailto:tsvwg@ietf.org>

                > Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>

                > Betreff: Re: [tcpm] [tsvwg] L4S status tracking

                > 

                > Michael,

                > 

                > Previously, I have been told not to use the term
                standard for RFCs that are not standards. RFC5681 is
                'only' a draft standard. This is why, in the IETF at
                least, I avoid using the term "standard TCP congestion
                control". I generally call it Reno when referring to the
                congestion control.

                > 

                > I have never, to my knowledge, used the term
                classic TCP, or classic TCP congestion control.

                > 

                > And I rarely use the term legacy, and if I do I'm
                happy to have alternatives suggested.

                > 

                > I've checked the L4S drafts, and there is one
                phrase that I shall leave in ecn-l4s-id: "the
                traditional TCP Reno additive increase", because this is
                correctly used to mean the traditional increase (in
                numerous AIMD CCs), not traditional TCP. There was one
                other occurrence of "traditional TCP senders" in a whole
                para in an appendix that has just been deleted anyway.
                And in aqm-dualq-coupled there was one "legacy TCP
                flows" (changed to "Classic traffic" now in my local
                copy, using the defined term in all the L4S drafts).

                > 

                > l4s-arch is getting a complete make-over for
                terminology, so I will check that next.

                > 

                > inline...

                > 

                > 

                > On 23/08/2019 15:01, Scharf, Michael wrote:

                > 

                > Hi Wes,

                > 

                > 

                > 

                > I?d 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-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY>
                , I object to the terms ?traditional TCP? and also
                ?classic TCP? or ?legacy? TCP when referring to a TCP
                implementation according to IETF standards-track RFCs.

                > 

                > 

                > 

                > To me as a non-native native speaker, all these
                terms have a negative connotation. I also think this
                language is typical to marketing material.

                > 

                > You're entitled to your opinion but, as a native
                speaker, I don't think 'classic' or 'traditional' are
                particularly pejorative, tho they can be when used in a
                context that intends them to be. They also mean "stood
                the test of time". I find 'legacy' has a connotation of
                marketing-speak, but it's not that bad.

                > 

                > This is an enduring problem when trying to improve
                on the good work that other people have done before you
                (which is the context of everything we are doing). We
                need a word that distinguishes the old from the new, but
                we don't want to completely trash the thing that has
                already been successful, but had its day.

                > 

                > Nonetheless, it is also important not to be too
                precious about past work. We all recognize that Reno TCP
                is unscalable and has problems. IMO, it is OK to
                describe technologies that have had their time with
                negative connotations. Indeed, you have been an author
                (with me) of an RFC on open issues in congestion
                control.

                > 

                > I notice you haven't suggested an alternative term
                for "the thing(s) we are trying to improve on". Not
                surprising, because it's difficult.

                > 

                > When we (the L4S developers) were first looking for
                a term for the non-L4S queue and the non-L4S service, we
                didn't want to use 'legacy' for the above reasons, but
                we did want to imply pre-existing, so we decided on
                'classic', which we all felt had a generally neutral
                connotation, but said what we meant.

                > 

                > Finally, I do not want this issue to take up any
                time that would detract from technical issues.

                > 

                > 

                > 

                > Bob

                > 

                > 

                > 

                > 

                > My prefered term when referring to TCP according to
                standards-track specification 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 TCP standard congestion control
                (?Reno?). As of today, this is the TCP congestion
                control 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 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 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
                and I don?t ask for changes in those cases.

                > 

                > 

                > 

                > Some use of the term ?Classic Service? may also
                require careful review to clearly 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 speaker, it
                would be really strange to use the term ?classic? in the
                context of a brand-new transport protocol. IMHO in that
                case the term ?classic? would be even more confusing.

                > 

                > 

                > 

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

                > 

                > 

                > 

                > Thanks

                > 

                > 

                > 

                > Michael (with no hat)

                > 

                > 

                > 

                > 

                > 

                > Von: Wesley Eddy<mailto:wes@mti-systems.com>

                > Gesendet: Sonntag, 11. August 2019 07:08

                > An: tsvwg@ietf.org<mailto: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=ticket&asc=1&page=1

                > 

                > 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.

                > 

                > 

                > 

                > 

                > 

                > _______________________________________________

                > tcpm mailing list

                > tcpm@ietf.org<mailto:tcpm@ietf.org>

                > https://www.ietf.org/mailman/listinfo/tcpm

                > 

                > 

                > 

                > --

                >
                ________________________________________________________________

                > Bob Briscoe http://bobbriscoe.net/

                

                > _______________________________________________

                > tcpm mailing list

                > tcpm@ietf.org

                > https://www.ietf.org/mailman/listinfo/tcpm

                

                -- 

                Rod
                Grimes 
                  rgrimes@freebsd.org

              

            

        

        
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------55C4F94FFDD19FAEF04A8A6D--


From nobody Wed Nov  6 10:45: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 34544120104; Wed,  6 Nov 2019 10:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 NoYl0YDAOEGX; Wed,  6 Nov 2019 10:45:38 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FEC1200E5; Wed,  6 Nov 2019 10:45:37 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA6IihPq011325; Wed, 6 Nov 2019 10:44:43 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA6Iihtl011324; Wed, 6 Nov 2019 10:44:43 -0800 (PST) (envelope-from freebsd)
From: "Rodney W. Grimes" 
Message-Id: <201911061844.xA6Iihtl011324@gndrsh.dnsmgr.net>
In-Reply-To: <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net>
To: Bob Briscoe 
Date: Wed, 6 Nov 2019 10:44:43 -0800 (PST)
CC: Sebastian Moeller , "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Reply-To: rgrimes@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
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: Wed, 06 Nov 2019 18:45:40 -0000

Bob,
	Reply inline with quoted text from draft as to "why" I,
and probably others are having issues with Classic and your
terminology.  All IMHO, of cource.

Regards,
Rod

> Sebastien,
> 
> On 06/11/2019 07:18, Sebastian Moeller wrote:
> > Hi Bob,
> >
> > On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe  wrote:
> >> Michael, Rod,
> >>
> >> Altho non-L4S is a reasonable idea, I think it has more of a negative
> >> connotation than classic.
> >          [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
> Which is a good starting point, because that's what is intended. Plus it 
> already has a slightly positive natural meaning of "something robust 
> that has stood the test of time". Then it is defined precisely for the 
> context of each L4S doc, e.g.:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2

Quoting the whole section inline: (WIth some markers added)

   Classic service:  The 'Classic' service is intended for all the
   ^A
      behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
      Compound, SCTP, etc).

   Low-Latency, Low-Loss and Scalable (L4S) service:  The 'L4S' service
      is intended for traffic from scalable congestion control
      algorithms such as Data Center TCP.  But it is also more general--
      it allows the set of congestion controls with similar scaling
      properties to DCTCP to evolve (e.g.  Relentless TCP [Mathis09] and
      the L4S variant of SCREAM for real-time media [RFC8298].

      Both Classic and L4S services can cope with a proportion of
           ^B
      unresponsive or less-responsive traffic as well, as long as it
      does not build a queue (e.g.  DNS, VoIP, game sync datagrams,
      etc).

   Classic ECN:  The original Explicit Congestion Notification (ECN)
   ^A
      protocol [RFC3168].


Problem with these terminology definitions:

Classic is used in the names of 2 terms, marked A above, and then
used without any qualification in the definition of a third term,
marked as B.  I believe the inference at B is that of "Classic Service".

These terminology definintions are fuzzy, due to the use of words
like "current".  Which current is that?  The date the draft was
written, the date I am reading the draft?  This is a poor quality
term definition.

Since I can not put solid definitions of these terms in my mind
when I read the draft I am always asking myself exactly what is
"Classic" infering here?

My head spins when I try to parse the above "term" "L4S service",
and I can not build a solid model from the definition given.  It
is self referential (L4S is L4S variant of SCREAM).  It has wording
on what it can cope with.  For me this is not a definition of
a term.


Now, having said that, let me at least try to resolve one of
these terms.   There is actually no need to define "Classic ECN"
as its above definitions is "RFC3168 ECN", exactly 2 words, or
11 characters  in length as well, thus the term is not needed
and actually obfuscates the document.  I feel removeing all
references to "CLassic ECN" and replacing them with "RFC3168 ECN"
would make these drafts more understadable.

> >
> > For instance, consider describing Android
> >> phones as non-iPhones.
> >           [SM] In a discussion of say the merits of iPhones versus the competition that seems to be a decent description?
> It is a decent description of the set of all phones that are not 
> iPhones. But it has negative connotations when describing an instance, 
> as in "Oh, you've got a non-iPhone"
> 
> Just as it is fine to use the phrase 'non-white people' when publishing 
> the results of a survey comparing privileges for white people versus 
> everyone else. But it would be totally insulting to describe black 
> people as non-white people.
> 
> >
> >> For example, if you did define the name "non-iPhone" to mean phones
> >> such
> >> as Android, Windows, etc, then you would expect the phrase "non-iPhone
> >> knock-off products" to mean "fake Android and Windows phones". However
> >> the constituent elements "non" and "iPhone" already have a meaning of
> >> their own, so in the context of this phrase, it means "fake iPhones",
> >> which is the opposite of what you wanted.
> >          [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.
> [BB] Please try to understand why this is very much the critical issue 
> (more important than the negative connotation question, which is 
> subjective).
> 
> I believe you are thinking in the context of all traffic. Let's call 
> that set A. And let's call the set of all L4S traffic L1.
> Then in this context, "Non-L4S" naturally means A - L1.
> 
> However, consider another context, say the context of all Low Latency 
> traffic, that we'll call L2. This was the context of the example I found 
> in the draft. In that context, the term "Non-L4S" already naturally 
> means L2 - L1.
> 
> So the term "Non-L4S" already has the intended meaning of Classic, but 
> only in one context (A), and it has other meanings in every other context.
> 
> It's a very bad idea to choose a name that already has a natural meaning 
> that can be different to what you want to define the name to mean.
> 
> >> The term Classic for the non-L4S service, its queue, its traffic, its
> >> congestion control, etc. is defined in the terminology section of the
> >> drafts, so I think it's best to live with this - it's not a significant
> >>
> >> problem.
> >          [SM] If it is not significant, then changing it surely is not a problem?
> [BB] Changing it to a problematic name like non-L4S (as explained above) 
> would be a problem.
> 
> Leaving it as it is, is not a significant problem, particularly because 
> we chose Classic because it had the least negative connotation of all 
> the words the thesaurus could throw at us. So this is obviously quite a 
> subtle dependence on the mindset of the individuals involved.
> 
> 
> >
> > Indeed, it has become widely used and widely understood since
> >> 2015, and changing it to non-L4S now would cause unnecessary confusion.
> >          [SM] By that logic nothing in the L4S drafts should be changed? If I recall correctly that is not how getting a draft past reviewers works....
> Not at all. The aim of review is to ensure a draft is clearer - you will 
> see we've made literally hundreds of changes already in response to 
> those sort of requests. A reviewer doesn't have an automatic right to 
> have all their requests satisfied, if they are not considered useful by 
> the draft editor (or WG consensus if nec.)
> 
> I am resisting all the suggestions for a change of name so far, because 
> "non-L4S" has the context-dependence problem I've already described. And 
> all the other suggestions already have at best roughly equal negative 
> connotations to Classic.
> 
> Anyway, nearly any choice of name for "something intended to be 
> superseded" will develop negative connotations as soon as it is defined, 
> even if it was completely meaningless when first coined.
> 
> A huge amount of care went into getting the names right, before we 
> started. I remember quoting Dijkstra at my colleagues at the time (I 
> can't find the quote right now, but it's about how choice of names is 
> paramount in programming). This one is nearly as relevant:
> /"Besides a mathematical inclination, an exceptionally good mastery of 
> one?s native tongue is the most vital asset of a competent programmer. 
> "/ Edsger Dijkstra
> 
> 
> 
> Bob
> 
> 
> >
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >> On 04/11/2019 19:21, Scharf, Michael wrote:
> >>> I agree. ?non-L4S? may be even better.
> >>>
> >>> Michael
> >>>
> >>> *Von: *Rodney W. Grimes 
> >>> *Gesendet: *Montag, 4. November 2019 20:17
> >>> *An: *Scharf, Michael 
> >>> *Cc: *Bob Briscoe ; Wesley Eddy
> >>> ; tsvwg@ietf.org ;
> >>> tcpm@ietf.org 
> >>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
> >>>
> >>>> You can e.g. use ?non-L4S-enabled TCP?.
> >>>>
> >>>> Terminology does matter to me given that I strongly disagree to any
> >>> use of ?marketing language? when it comes to TCP.
> >>>
> >>> My concern here of use of terms like, legacy, classic, new, old
> >>> is that they are pretty much all of the relative from and thus
> >>> ambiguous over time.
> >>>
> >>> newReno is new only relative to Reno, that is fairly clear,
> >>> but if I said newTCP or oldTCP with what frame should the
> >>> reference be evaluated.
> >>>
> >>> I believe in the case of L4S the time invariant term would be,
> >>> as Michael suggests above, "non-L4S".?? Note that enabled
> >>> for me is a noise word in this context, and TCP may or may
> >>> not be needed depending on context, but for literal replacement
> >>> of Legacy or Classic "non-L4S" is invariant over time.
> >>>
> >>> Rod
> >>>
> >>>> Michael
> >>>>
> >>>>
> >>>> Von: Bob Briscoe
> >>>> Gesendet: Montag, 4. November 2019 19:09
> >>>> An: Scharf, Michael; Wesley
> >>> Eddy;
> >> tsvwg@ietf.org
> >>>> Cc: tcpm@ietf.org
> >>>> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
> >>>>
> >>>> Michael,
> >>>>
> >>>> Previously, I have been told not to use the term standard for RFCs
> >>> that are not standards. RFC5681 is 'only' a draft standard. This is
> >>> why, in the IETF at least, I avoid using the term "standard TCP
> >>> congestion control". I generally call it Reno when referring to the
> >>> congestion control.
> >>>> I have never, to my knowledge, used the term classic TCP, or
> >> classic
> >>> TCP congestion control.
> >>>> And I rarely use the term legacy, and if I do I'm happy to have
> >>> alternatives suggested.
> >>>> I've checked the L4S drafts, and there is one phrase that I shall
> >>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase",
> >>> because this is correctly used to mean the traditional increase (in
> >>> numerous AIMD CCs), not traditional TCP. There was one other
> >>> occurrence of "traditional TCP senders" in a whole para in an
> >> appendix
> >>> that has just been deleted anyway. And in aqm-dualq-coupled there was
> >>> one "legacy TCP flows" (changed to "Classic traffic" now in my local
> >>> copy, using the defined term in all the L4S drafts).
> >>>> l4s-arch is getting a complete make-over for terminology, so I will
> >>> check that next.
> >>>> inline...
> >>>>
> >>>>
> >>>> On 23/08/2019 15:01, Scharf, Michael wrote:
> >>>>
> >>>> Hi Wes,
> >>>>
> >>>>
> >>>>
> >>>> I?d 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-hDvWO3I5MudwpNkKyHY
> >>
> >>> , I object to the terms ?traditional TCP? and also ?classic TCP? or
> >>> ?legacy? TCP when referring to a TCP implementation according to IETF
> >>> standards-track RFCs.
> >>>>
> >>>>
> >>>> To me as a non-native native speaker, all these terms have a
> >>> negative connotation. I also think this language is typical to
> >>> marketing material.
> >>>> You're entitled to your opinion but, as a native speaker, I don't
> >>> think 'classic' or 'traditional' are particularly pejorative, tho
> >> they
> >>> can be when used in a context that intends them to be. They also mean
> >>> "stood the test of time". I find 'legacy' has a connotation of
> >>> marketing-speak, but it's not that bad.
> >>>> This is an enduring problem when trying to improve on the good work
> >>> that other people have done before you (which is the context of
> >>> everything we are doing). We need a word that distinguishes the old
> >>> from the new, but we don't want to completely trash the thing that
> >> has
> >>> already been successful, but had its day.
> >>>> Nonetheless, it is also important not to be too precious about past
> >>> work. We all recognize that Reno TCP is unscalable and has problems.
> >>> IMO, it is OK to describe technologies that have had their time with
> >>> negative connotations. Indeed, you have been an author (with me) of
> >> an
> >>> RFC on open issues in congestion control.
> >>>> I notice you haven't suggested an alternative term for "the
> >> thing(s)
> >>> we are trying to improve on". Not surprising, because it's difficult.
> >>>> When we (the L4S developers) were first looking for a term for the
> >>> non-L4S queue and the non-L4S service, we didn't want to use 'legacy'
> >>> for the above reasons, but we did want to imply pre-existing, so we
> >>> decided on 'classic', which we all felt had a generally neutral
> >>> connotation, but said what we meant.
> >>>> Finally, I do not want this issue to take up any time that would
> >>> detract from technical issues.
> >>>>
> >>>>
> >>>> Bob
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> My prefered term when referring to TCP according to standards-track
> >>> specification 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 TCP standard congestion control (?Reno?). As of today, this
> >> is
> >>> the TCP congestion control 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 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 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 and I don?t ask for changes
> >>> in those cases.
> >>>>
> >>>>
> >>>> Some use of the term ?Classic Service? may also require careful
> >>> review to clearly 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 speaker, it would be really strange to use the term
> >>> ?classic? in the context of a brand-new transport protocol. IMHO in
> >>> that case the term ?classic? 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=ticket&asc=1&page=1
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> tcpm mailing list
> >>>> tcpm@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/tcpm
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> ________________________________________________________________
> >>>> Bob Briscoe http://bobbriscoe.net/
> >>>> _______________________________________________
> >>>> tcpm mailing list
> >>>> tcpm@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/tcpm
> >>> -- 
> >>> Rod Grimes rgrimes@freebsd.org
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Wed Nov  6 10:58: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 6D268120104; Wed,  6 Nov 2019 10:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01] 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 lNmZMh4rsUW1; Wed,  6 Nov 2019 10:57:54 -0800 (PST)
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 B4F9012001A; Wed,  6 Nov 2019 10:57:53 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id BDA4E25A3E; Wed,  6 Nov 2019 19:57:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573066671; bh=8cNqMVQLKg4dnJguZUQ+4ytJE9au0LOy7+Jlb3AKIvQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=f/mOjMMKYf494ObTpLavHIANpqDrpLf44ulktu+iZ0tUv/i8I2kj1RuYka+KGvRIO JwBXqA+7bskbUJUQfqjXG81SJZ2CIPPRNSwUHA0NHFLhVT8WdLiii/9UMxznpRco7R boJkogjYph0G5Va744Cx8eId6WsdhMmYR9YMtAu4=
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 PkmcfaBqRu7d; Wed,  6 Nov 2019 19:57:49 +0100 (CET)
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; Wed,  6 Nov 2019 19:57:49 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 6 Nov 2019 19:57:49 +0100
From: "Scharf, Michael" 
To: Bob Briscoe , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: Wesley Eddy , "tsvwg@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] [tsvwg] L4S status tracking
Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53v//8bUAgAASJQ6AAdWZAIAAhk2sgACrVICAABElwA==
Date: Wed, 6 Nov 2019 18:57:48 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.63.28]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4E64F3rznt8114rzntrzd_"
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: Wed, 06 Nov 2019 18:58:00 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E64F3rznt8114rzntrzd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.

Michael




From: Bob Briscoe 
Sent: Wednesday, November 6, 2019 7:37 PM
To: Scharf, Michael ; Rodney W. Grimes <4bo=
ne@gndrsh.dnsmgr.net>
Cc: Wesley Eddy ; tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,

Regarding the only usage you say you do object to, I've already said...
On 04/11/2019 18:09, Bob Briscoe wrote:
I have never, to my knowledge, used the term classic TCP, or classic TCP co=
ngestion control.

...because Classic is intended as a a description of a set of congestion co=
ntrols. The protocol is relatively irrelevant.

Pls see my response to Sebastien concerning the slightly positive connotati=
on of the word 'classic'.
And how even a nonsense word coined for "something intended to be supersede=
d" will develop a negative connotation as soon as it is defined.
This implies that the problem you've raised is impossible to solve without =
upsetting certain sensitive people.


Bob
On 06/11/2019 07:23, Scharf, Michael wrote:
Bob,

I am not convinced by any of your statements.

There are more than 500.000 hits in Google for "non-iPhone" and I see many =
that are not about fakes.

Certainly, I don't insist in the term "non-L4S". This is just an example. I=
 already proposed "non-L4S-enabled" as well. I fail to understand how "non-=
L4S-enabled TCP" could be confused with "non-L4S traffic". But, as outlined=
 below, anyway there are other solutions.

Also, I don't object to the term "Classic" when referring to ECN and other =
related concepts if that use of the term has strong TSVWG consensus. For in=
stance, "classic" ECN feedback, "classic" queue, "classic" traffic would wo=
rk for me in case TSVWG strongly supports that term.

Thus, personally, I am not asking for any disruptive change. I don't ask to=
 avoid "Classic" in general.

What does *not* work for me is the term "Classic" TCP, in particular when r=
efering to TCP as standardized by TCPM. I also don't agree to the term "cla=
ssic" congestion Control for Reno, CUBIC, CTCP, i.e., work of the TCPM work=
ing group. To me, the authors of this document do not have the right to tag=
 work of the TCPM working group with a term such as "classic" that is used =
in marketing language.

And there are plenty of simple ways to avoid that problematic term "Classic=
" TCP. Here are some more examples:

  *   TCP without the L4S extension
  *   TCP (senders/stacks/connections) not using L4S
  *   TCP without support of L4S
  *   TCP (senders/stacks/connections) lacking L4S support
  *   TCP (senders/stacks/connections) not participating in the L4S experim=
ent
  *   ... and more and also permutations thereof

You can also try to reword text to just to avoid the term "Classic" TCP to =
work around the problem.

Regarding congestion control, you can refer instead to

  *   specific algorithms such as Reno or CUBIC
  *   "high-speed loss-based congestion control"
  *   or any of the above terms, e.g., "congestion control without L4S supp=
ort" and the like

My ask is a simple editorial change that will IMHO only affect few occurenc=
es of the term "Classic". Can you please propose next steps that addess my =
concern?

Thanks

Michael


Von: Bob Briscoe
Gesendet: Mittwoch, 6. November 2019 01:22
An: Scharf, Michael; Rodney W. Grime=
s
Cc: Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

Michael, Rod,

Altho non-L4S is a reasonable idea, I think it has more of a negative conno=
tation than classic. For instance, consider describing Android phones as no=
n-iPhones.

Also, in the ecn-l4s-id draft, we introduce the possibility that some opera=
tors might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same=
 queue as L4S traffic (and we say that in this case the queue would be call=
ed the Low Latency queue). This shows that the term non-L4S is not a good c=
hoice for a name, because the words it is made from already give it a meani=
ng of its own that conflicts with the definition you want it to have in cer=
tain contexts.

For example, if you did define the name "non-iPhone" to mean phones such as=
 Android, Windows, etc, then you would expect the phrase "non-iPhone knock-=
off products" to mean "fake Android and Windows phones". However the consti=
tuent elements "non" and "iPhone" already have a meaning of their own, so i=
n the context of this phrase, it means "fake iPhones", which is the opposit=
e of what you wanted.

The term Classic for the non-L4S service, its queue, its traffic, its conge=
stion control, etc. is defined in the terminology section of the drafts, so=
 I think it's best to live with this - it's not a significant problem. Inde=
ed, it has become widely used and widely understood since 2015, and changin=
g it to non-L4S now would cause unnecessary confusion.



Bob


On 04/11/2019 19:21, Scharf, Michael wrote:

I agree. "non-L4S" may be even better.



Michael





Von: Rodney W. Grimes
Gesendet: Montag, 4. November 2019 20:17
An: Scharf, Michael
Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org
Betreff: Re: [tcpm] [tsvwg] L4S status tracking


> You can e.g. use ?non-L4S-enabled TCP?.
>
> Terminology does matter to me given that I strongly disagree to any use o=
f ?marketing language? when it comes to TCP.

My concern here of use of terms like, legacy, classic, new, old
is that they are pretty much all of the relative from and thus
ambiguous over time.

newReno is new only relative to Reno, that is fairly clear,
but if I said newTCP or oldTCP with what frame should the
reference be evaluated.

I believe in the case of L4S the time invariant term would be,
as Michael suggests above, "non-L4S".   Note that enabled
for me is a noise word in this context, and TCP may or may
not be needed depending on context, but for literal replacement
of Legacy or Classic "non-L4S" is invariant over time.

Rod

> Michael
>
>
> Von: Bob Briscoe
> Gesendet: Montag, 4. November 2019 19:09
> An: Scharf, Michael; Wesley Eddy; tsvwg@ietf.org
> Cc: tcpm@ietf.org
> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael,
>
> Previously, I have been told not to use the term standard for RFCs that a=
re not standards. RFC5681 is 'only' a draft standard. This is why, in the I=
ETF at least, I avoid using the term "standard TCP congestion control". I g=
enerally call it Reno when referring to the congestion control.
>
> I have never, to my knowledge, used the term classic TCP, or classic TCP =
congestion control.
>
> And I rarely use the term legacy, and if I do I'm happy to have alternati=
ves suggested.
>
> I've checked the L4S drafts, and there is one phrase that I shall leave i=
n ecn-l4s-id: "the traditional TCP Reno additive increase", because this is=
 correctly used to mean the traditional increase (in numerous AIMD CCs), no=
t traditional TCP. There was one other occurrence of "traditional TCP sende=
rs" in a whole para in an appendix that has just been deleted anyway. And i=
n aqm-dualq-coupled there was one "legacy TCP flows" (changed to "Classic t=
raffic" now in my local copy, using the defined term in all the L4S drafts)=
.
>
> l4s-arch is getting a complete make-over for terminology, so I will check=
 that next.
>
> inline...
>
>
> On 23/08/2019 15:01, Scharf, Michael wrote:
>
> Hi Wes,
>
>
>
> I?d 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-h=
DvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?classic =
TCP? or ?legacy? TCP when referring to a TCP implementation according to IE=
TF standards-track RFCs.
>
>
>
> To me as a non-native native speaker, all these terms have a negative con=
notation. I also think this language is typical to marketing material.
>
> You're entitled to your opinion but, as a native speaker, I don't think '=
classic' or 'traditional' are particularly pejorative, tho they can be when=
 used in a context that intends them to be. They also mean "stood the test =
of time". I find 'legacy' has a connotation of marketing-speak, but it's no=
t that bad.
>
> This is an enduring problem when trying to improve on the good work that =
other people have done before you (which is the context of everything we ar=
e doing). We need a word that distinguishes the old from the new, but we do=
n't want to completely trash the thing that has already been successful, bu=
t had its day.
>
> Nonetheless, it is also important not to be too precious about past work.=
 We all recognize that Reno TCP is unscalable and has problems. IMO, it is =
OK to describe technologies that have had their time with negative connotat=
ions. Indeed, you have been an author (with me) of an RFC on open issues in=
 congestion control.
>
> I notice you haven't suggested an alternative term for "the thing(s) we a=
re trying to improve on". Not surprising, because it's difficult.
>
> When we (the L4S developers) were first looking for a term for the non-L4=
S queue and the non-L4S service, we didn't want to use 'legacy' for the abo=
ve reasons, but we did want to imply pre-existing, so we decided on 'classi=
c', which we all felt had a generally neutral connotation, but said what we=
 meant.
>
> Finally, I do not want this issue to take up any time that would detract =
from technical issues.
>
>
>
> Bob
>
>
>
>
> My prefered term when referring to TCP according to standards-track speci=
fication is ?standard TCP?. I would also be fine with other terms as long a=
s they are neutral and make clear that experiments do not replace, deprecat=
e, or outperform standards.
>
>
>
> Similarly, I think that term such as ?classic? is not appropriate for the=
 TCP standard congestion control (?Reno?). As of today, this is the TCP con=
gestion control algorithm on standards track that has IETF consensus. The t=
erm 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?, ?lega=
cy AQM? or the like, i.e., if the context is ECN and not specifically TCP o=
r 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 opinio=
n on that. As far as I can see, most use of the term ?classic? is in this c=
ontext and I don?t ask for changes in those cases.
>
>
>
> Some use of the term ?Classic Service? may also require careful review to=
 clearly 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 s=
peaker, it would be really strange to use the term ?classic? in the context=
 of a brand-new transport protocol. IMHO in that case the term ?classic? wo=
uld 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.
>
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/

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

--
Rod Grimes                                                 rgrimes@freebsd.=
org



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E64F3rznt8114rzntrzd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Bob,


 


From draft-ietf-tsvwg-ecn-l4s-id-08: “It gives an=
 incremental migration path so that existing 'Classic' TCP traffic will be =
no worse off”


 


You are proposing an experiment. Not more than that. I =
will be fine with the term “Classic” for TCP and TCPM-specified=
 congestion control when more than 50% of Internet
 traffic uses that new technology.


 


Until this happens, I insist that the word “Class=
ic” must be removed in all context of TCP and congestion control (as =
far as it is owned by TCPM), including the reference
 above. BTW, “normal” as suggested would also work for me. So, =
you have plenty of options for other terms.


 


Michael


 


 


 


 








F=
rom: Bob Briscoe=
 <ietf@bobbriscoe.net>


Sent: Wednesday, November 6, 2019 7:37 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Rodney W=
. Grimes <4bone@gndrsh.dnsmgr.net>

Cc: Wesley Eddy <wes@mti-systems.com>; tsvwg@ietf.org; tcpm@ie=
tf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 


Michael,



Regarding the only usage you say you do object to, I've already said...




On 04/11/2019 18:09, Bob Briscoe wrote:





I have never, to my knowledge, used the term classic=
 TCP, or classic TCP congestion control.






...because Classic is intended as a a description of a set of congestion co=
ntrols. The protocol is relatively irrelevant.



Pls see my response to Sebastien concerning the slightly positive connotati=
on of the word 'classic'.


And how even a nonsense word coined for "something intended to be supe=
rseded" will develop a negative connotation as soon as it is defined.


This implies that the problem you've raised is impossible to solve without =
upsetting certain sensitive people.





Bob




On 06/11/2019 07:23, Scharf, Michael wrote:








Bob,


 


I am not convinced by any of your statements.


 


There are more than 500.000 hits in Google for ̶=
2;non-iPhone“ and I see many that are not about fakes.


 


Certainly, I don’t insist in the term „n=
on-L4S“. This is just an example. I already proposed „non-L4S-e=
nabled“ as well. I fail to understand how „non-L4S-enabled TCP&=
#8220; could be confused with „non-L4S traffic“. But, as outlin=
ed below, anyway
 there are other solutions.


 


Also, I don’t object to the term „Classi=
c“ when referring to ECN and other related concepts if that use of th=
e term has strong TSVWG consensus. For instance, "classic“ ECN f=
eedback, „classic“ queue, „classic“ traffic would w=
ork for me in
 case TSVWG strongly supports that term.


 


Thus, personally, I am not asking for any disruptive=
 change. I don’t ask to avoid „Classic“ in general.<=
/o:p>


 


What does *not* work for me is the term ̶=
2;Classic“ TCP, in particular when refering to TCP as standardized by=
 TCPM. I also don’t agree to the term „classic“ congestio=
n Control for Reno, CUBIC, CTCP, i.e., work of the TCPM working
 group. To me, the authors of this document do not have the right to tag wo=
rk of the TCPM working group with a term such as „classic“ that=
 is used in marketing language.


 


And there are plenty of simple ways to avoid that pr=
oblematic term „Classic“ TCP. Here are some more examples:=



    

  • TCP without the L=
4S extension
  • TCP (senders/stacks/connections) not using L4S
    • TCP without support=
 of L4S
  • TCP (senders/stacks/connections) lacking L4S support
    • <=
li class=3D"MsoNormal" style=3D"mso-list:l0 level1 lfo1">TCP (senders/stack=
s/connections) not participating in the L4S experiment
  • … and more and a=
lso permutations thereof


 


You can also try to reword text to just to avoid the=
 term „Classic“ TCP to work around the problem.


 


Regarding congestion control, you can refer instead =
to


    

  • specific algorith=
ms such as Reno or CUBIC

  • &=
#8222;high-speed loss-based congestion control“
  • or any of the above ter=
ms, e.g., „congestion control without L4S support“ and the like=



 


My ask is a simple editorial change that will IMHO o=
nly affect few occurences of the term „Classic“. Can you please=
 propose next steps that addess my concern?


 


Thanks


 


Michael


 <=
/span>


 




Von: B=
ob Briscoe

Gesendet: Mittwoch, 6. November 2019 01:22

An: Scharf, Michae=
l; 
Rodney W. Grimes

Cc: Wesley Eddy; 
tsvwg@ietf.org; tcpm@ietf.org

Betreff: Re: [tcpm] [tsvwg] L4S status tracking




 






Michael, Rod,



Altho non-L4S is a reasonable idea, I think it has more of a negative conno=
tation than classic. For instance, consider describing Android phones as no=
n-iPhones.



Also, in the ecn-l4s-id draft, we introduce the possibility that some opera=
tors might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the same=
 queue as L4S traffic (and we say that in this case the queue would be call=
ed the Low Latency queue). This
 shows that the term non-L4S is not a good choice for a name, because the w=
ords it is made from already give it a meaning of its own that conflicts wi=
th the definition you want it to have in certain contexts.



For example, if you did define the name "non-iPhone" to mean phon=
es such as Android, Windows, etc, then you would expect the phrase "no=
n-iPhone knock-off products" to mean "fake Android and Windows ph=
ones". However the constituent elements "non" and "iPho=
ne"
 already have a meaning of their own, so in the context of this phrase, it =
means "fake iPhones", which is the opposite of what you wanted.


The term Classic for the non-L4S service, its queue, its traffic, its conge=
stion control, etc. is defined in the terminology section of the drafts, so=
 I think it's best to live with this - it's not a significant problem. Inde=
ed, it has become widely used and
 widely understood since 2015, and changing it to non-L4S now would cause u=
nnecessary confusion.







Bob










On 04/11/2019 19:21, Scharf, Michael wrote:=











I agree. „non-L4S“ may be even better.<=
o:p>


 


Michael


 =



 




Von: Rodney W. Grimes

Gesendet: Montag, 4. November 2019 20:17

An: Scharf, Michae=
l

Cc: Bob Briscoe; 
Wesley Eddy; tsvwg@ietf.org; 
tcpm@ietf.org

Betreff: Re: [tcpm] [tsvwg] L4S status tracking




 








> You can e.g. use ?non-L4S-enabled TCP?.

> 

> Terminology does matter to me given that I strongly disagree to any us=
e of ?marketing language? when it comes to TCP.



My concern here of use of terms like, legacy, classic, new, old

is that they are pretty much all of the relative from and thus

ambiguous over time.



newReno is new only relative to Reno, that is fairly clear,

but if I said newTCP or oldTCP with what frame should the

reference be evaluated.



I believe in the case of L4S the time invariant term would be,

as Michael suggests above, "non-L4S".   Note that enabl=
ed

for me is a noise word in this context, and TCP may or may

not be needed depending on context, but for literal replacement

of Legacy or Classic "non-L4S" is invariant over time.



Rod



> Michael

> 

> 

> Von: Bob Briscoe<mailto:ietf=
@bobbriscoe.net>

> Gesendet: Montag, 4. November 2019 19:09

> An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley Eddy<mailto:wes@mti-systems.com>;
tsvwg@ietf.org<mailto:tsvwg@ietf.org>

> Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>

> Betreff: Re: [tcpm] [tsvwg] L4S status tracking

> 

> Michael,

> 

> Previously, I have been told not to use the term standard for RFCs tha=
t are not standards. RFC5681 is 'only' a draft standard. This is why, in th=
e IETF at least, I avoid using the term "standard TCP congestion contr=
ol". I generally call it Reno when referring
 to the congestion control.

> 

> I have never, to my knowledge, used the term classic TCP, or classic T=
CP congestion control.

> 

> And I rarely use the term legacy, and if I do I'm happy to have altern=
atives suggested.

> 

> I've checked the L4S drafts, and there is one phrase that I shall leav=
e in ecn-l4s-id: "the traditional TCP Reno additive increase", be=
cause this is correctly used to mean the traditional increase (in numerous =
AIMD CCs), not traditional TCP. There was one
 other occurrence of "traditional TCP senders" in a whole para in=
 an appendix that has just been deleted anyway. And in aqm-dualq-coupled th=
ere was one "legacy TCP flows" (changed to "Classic traffic&=
quot; now in my local copy, using the defined term in all the
 L4S drafts).

> 

> l4s-arch is getting a complete make-over for terminology, so I will ch=
eck that next.

> 

> inline...

> 

> 

> On 23/08/2019 15:01, Scharf, Michael wrote:

> 

> Hi Wes,

> 

> 

> 

> I?d like to add a smaller item that is mostly editorial and can hopefu=
lly be sorted just out by re-wording, albeit it may require a careful analy=
sis of all documents.

> 

> 

> 

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

> 

> 

> 

> To me as a non-native native speaker, all these terms have a negative =
connotation. I also think this language is typical to marketing material.
> 

> You're entitled to your opinion but, as a native speaker, I don't thin=
k 'classic' or 'traditional' are particularly pejorative, tho they can be w=
hen used in a context that intends them to be. They also mean "stood t=
he test of time". I find 'legacy' has a
 connotation of marketing-speak, but it's not that bad.

> 

> This is an enduring problem when trying to improve on the good work th=
at other people have done before you (which is the context of everything we=
 are doing). We need a word that distinguishes the old from the new, but we=
 don't want to completely trash the
 thing that has already been successful, but had its day.

> 

> Nonetheless, it is also important not to be too precious about past wo=
rk. We all recognize that Reno TCP is unscalable and has problems. IMO, it =
is OK to describe technologies that have had their time with negative conno=
tations. Indeed, you have been an author
 (with me) of an RFC on open issues in congestion control.

> 

> I notice you haven't suggested an alternative term for "the thing=
(s) we are trying to improve on". Not surprising, because it's difficu=
lt.

> 

> When we (the L4S developers) were first looking for a term for the non=
-L4S queue and the non-L4S service, we didn't want to use 'legacy' for the =
above reasons, but we did want to imply pre-existing, so we decided on 'cla=
ssic', which we all felt had a generally
 neutral connotation, but said what we meant.

> 

> Finally, I do not want this issue to take up any time that would detra=
ct from technical issues.

> 

> 

> 

> Bob

> 

> 

> 

> 

> My prefered term when referring to TCP according to standards-track sp=
ecification is ?standard TCP?. I would also be fine with other terms as lon=
g as they are neutral and make clear that experiments do not replace, depre=
cate, or outperform standards.

> 

> 

> 

> Similarly, I think that term such as ?classic? is not appropriate for =
the TCP standard congestion control (?Reno?). As of today, this is the TCP =
congestion control algorithm on standards track that has IETF consensus. Th=
e term in the TCPM charter is ?TCP
 standard congestion control?. I also think that terms such as ?Reno-compat=
ible? or the like would be neutral.

> 

> 

> 

> Note that I do not object to the terms ?classic ECN?, ?legacy ECN?, ?l=
egacy AQM? or the like, i.e., if the context is ECN and not specifically TC=
P 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 u=
se of the term ?classic? is in this context and I don?t ask for changes in =
those cases.

> 

> 

> 

> Some use of the term ?Classic Service? may also require careful review=
 to clearly 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-nativ=
e speaker, it would be really strange to use the term ?classic? in the cont=
ext of a brand-new transport protocol.
 IMHO in that case the term ?classic? would be even more confusing.

> 

> 

> 

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

> 

> 

> 

> Thanks

> 

> 

> 

> Michael (with no hat)

> 

> 

> 

> 

> 

> Von: Wesley Eddy<mailto:wes@=
mti-systems.com>

> Gesendet: Sonntag, 11. August 2019 07:08

> An: tsvwg@ietf.org<mailto: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=3Dtic=
ket&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 ticke=
t

> numbers or some key words in threads and messages, when significant.
> 

> 

> 

> 

> 

> _______________________________________________

> tcpm mailing list

> tcpm@ietf.org<mailto:tcpm@ietf.org>

> https://www.iet=
f.org/mailman/listinfo/tcpm

> 

> 

> 

> --

> ________________________________________________________________

> Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/



> _______________________________________________

> tcpm mailing list

> tcpm@ietf.org

> https://www.iet=
f.org/mailman/listinfo/tcpm



-- 

Rod Grimes           =
;            &n=
bsp;            =
;             <=
a href=3D"mailto:rgrimes@freebsd.org">
rgrimes@freebsd.org













-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/













-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/








--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E64F3rznt8114rzntrzd_--



From nobody Wed Nov  6 11:55:01 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 A00D5120241 for ; Wed,  6 Nov 2019 11:54:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 eZgUbWfZuslJ for ; Wed,  6 Nov 2019 11:54:56 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 27FCC1207FC for ; Wed,  6 Nov 2019 11:54:54 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id y39so35109678qty.0 for ; Wed, 06 Nov 2019 11:54:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=oyrfaMCyOW/5bioUBJg2CMPZezekC2jcVwLQjcpRVjA=; b=wBqQK/+0uMVtzjvfjRYjCnnjypscRW7IZHrt3FLOZ992i4UQSElFsLhmUd9CP0jpPK yYKexmdBI+kpuP8ITGa2ETj/RNKBLqBZnwOI6HjgOySuouTZLbec02fxtGmyKeCPNRHU IySOf4Lv8GDs401jO83Q9aYQhfoPpns/apIM7sENJlYmRbkc3Mx5izOUgxU6vTcpHRV+ 0UP2cHIaXJXBHPTphIb5RUala845teeSuZ1DTB0IgR7+elwZ1MfPY976Mdp2IfiMmY4f kUZgaiUKWWRBgocMq9zRJDN5C1AIDQapvcAmrizTTuS5DnS9IkZ3r0lclt38MISGefub 7cLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=oyrfaMCyOW/5bioUBJg2CMPZezekC2jcVwLQjcpRVjA=; b=ivfQAry7iBlXVU/NNxlZNmInRq7jwXFB0rgv1c0uFW9ZXLZsKF+NTm3LgHQm0AjBPJ 6u8HFumQ5cwI+Fme9PIU+pCb2NQqTBonH7Jvj+6uy5JAsLsnZk4eOmyDyxE7jI8h1bX/ OnKUxFTFCK8/yQkcYS9QIqefcRz2TJ7PRAXpaLqiTn4ChMXvJfRh1p5NKbawkdTb3QLu Ou93BO1B+iJmmulhktm4PZkrUYiz/RXwQwbsH0sLqmtOAXLOuBRWLgR2okwgK+TPqcd/ 6tEYJtP1FVZUhJCXIfwOnSxc0FDagFzEtKmHXQi/+qnJIi1UqHQWbIdiDVRon11EsKvK UsHg==
X-Gm-Message-State: APjAAAUc9hNPczOD0qTAdnZ4AXzCuMN7Eyf6sAEax5gszHiGyfs6fBXU gIOdS3a5VPaKiaJ8pK/YwAumFebhWEo=
X-Google-Smtp-Source: APXvYqxg+6i0ZQQ7JDeatRxS3FX++LOItChn3dRA8PFFluNtavXzWvHn7J4DrSAu88QgvR3oztMsOg==
X-Received: by 2002:aed:37c9:: with SMTP id j67mr4309748qtb.291.1573070072320;  Wed, 06 Nov 2019 11:54:32 -0800 (PST)
Received: from [192.168.1.11] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id j7sm9406499qkd.46.2019.11.06.11.54.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 11:54:31 -0800 (PST)
To: "Scharf, Michael" , Bob Briscoe , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tsvwg@ietf.org" , "tcpm@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Wesley Eddy 
Message-ID: 
Date: Wed, 6 Nov 2019 14:54:27 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------A71BEBE07D033A1E69D5A15F"
Content-Language: en-US
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: Wed, 06 Nov 2019 19:55:00 -0000

This is a multi-part message in MIME format.
--------------A71BEBE07D033A1E69D5A15F
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
>
> Bob,
>
> From draft-ietf-tsvwg-ecn-l4s-id-08: It gives an incremental 
> migration path so that existing 'Classic' TCP traffic will be no worse 
> off
>
> You are proposing an experiment. Not more than that. I will be fine 
> with the term Classic for TCP and TCPM-specified congestion control 
> when more than 50% of Internet traffic uses that new technology.
>
> Until this happens, I insist that the word Classic must be removed 
> in all context of TCP and congestion control (as far as it is owned by 
> TCPM), including the reference above. BTW, normal as suggested would 
> also work for me. So, you have plenty of options for other terms.
>

If Dave+Michael's suggestion of replacing "classic" with "normal" is 
agreable to others, this seems like a good way forward to me. It should 
be easy enough to explain in other SDOs that classic and normal mean the 
same thing, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any 
negative connotations to it. However, for the sake of working group 
progress, I think we just need to pick something that seems the least 
terrible and agree to move on.)



--------------A71BEBE07D033A1E69D5A15F
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 11/6/2019 1:57 PM, Scharf, Michael
      wrote:

    

    

      
      
      
      

        
Bob,

        

        
From draft-ietf-tsvwg-ecn-l4s-id-08: It gives
            an incremental migration path so that existing 'Classic' TCP
            traffic will be no worse off

        

        
You are proposing an experiment. Not more than
            that. I will be fine with the term Classic for TCP and
            TCPM-specified congestion control when more than 50% of
            Internet traffic uses that new technology.

        

        
Until this happens, I insist that the word
            Classic must be removed in all context of TCP and
            congestion control (as far as it is owned by TCPM),
            including the reference above. BTW, normal as suggested
            would also work for me. So, you have plenty of options for
            other terms.

        

      

    

    


    

    
If Dave+Michael's suggestion of replacing "classic" with "normal"
      is agreable to others, this seems like a good way forward to me.
      It should be easy enough to explain in other SDOs that classic and
      normal mean the same thing, if this is a real issue.

    

    
(FWIW, I've never had a problem myself with "classic", nor read
      any negative connotations to it. However, for the sake of working
      group progress, I think we just need to pick something that seems
      the least terrible and agree to move on.)

    


    

  


--------------A71BEBE07D033A1E69D5A15F--


From nobody Wed Nov  6 15:05:23 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 B3C1A1201B7; Wed,  6 Nov 2019 15:05:21 -0800 (PST)
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 gvb6LKHGZAwD; Wed,  6 Nov 2019 15:05:18 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B1CBF120052; Wed,  6 Nov 2019 15:05:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573081456; bh=bX+aPxWCOdQKL3yGR727xkcIhdMC1mb6/Lk70IN/Lkg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=QaryS8uFGeCaSnsRRn6L2jn4uI1Igdt60zmOW7awQAfQw7/gatQjP65yKUI63Ebzp glpADKEdE4uwBlcHwgNtMfCy931valSYc6tzwmO3YzE6bX1B7xmYqTTxJYKdEWY3xe 6Zxk2bXoWNciqUi9p77HnpGDoH26UWbArR5iwrfc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([95.116.216.137]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mzyuc-1hghS72Td0-00x1IH; Thu, 07 Nov 2019 00:04:15 +0100
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: <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net>
Date: Thu, 7 Nov 2019 00:04:10 +0100
Cc: "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <985D623F-8B16-4DB0-A675-5A726EF6753F@gmx.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:qPvJFZuleSCGM6XBA+S/US5igqUSXw4PNOU1A5uu+/MBGy+bNHE +hXPtd7OPUE+vY1dkIQJSb0l1KoN4C47abXh6iUnnznvhIlxvdQv32908/fMjjsNkabjLcv W37YPtL9BRZ3I7X+e8eX7+pBdIX92ylD8o/UXfO7OFatxxYrzJP+pjijfFma4EfLOvoZCI6 9L5IWeHFNe7wGwBTblKXA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4FP6T5dW/Xk=:4DgNU0MJfA8QO78H5dT7mS EpGhbqB2gCuM5+RahdPDDYt4DOJa3/7j9Jj08oAzr0/o7Ew8YDokjy7PLVmJC6Ugl0N5DyCnS Hgq+ro1DZxbyLf+PaoJ2IOHmVsTz0SXam/cEOMyQujQubyBslyYFFLpfY3WaaQI9Wfl6TvMGI XRtLmLCpOsh2sztDOKelESV/HP5iV3WZJAjtv0UgwwgOhGuLMTPTPfotzBlxQ5MnBUziE7C8S BsfJ0fRpmqlBzKIQl7EwP2lyfprmxCUDuc/8KTC5aqUSgOGZdLcUNfw/g3gOdXZE4ZZnzZwNY ZSB7pBdzfA5Rbv0UmLFTpc91ZNr+oyQ1j86bPNJ5iEkIAbU4kB1p9+gwagQQZFRKb8t1LzAUQ 9GAVwHCCRBq4krn3cozw2CVTmrZPybeH5igX98JZl7qxiZ0p9YBcimjgzs3RYkyJ4E+E249Zr UaCNRNq9tHxKiGKT+ZaHtlTOpmeJ2e/ievqpWCRJM5Q9D27QZ8W1QMBkcC9kXWWr3rPR72AZa WAI6vvOG80kf8++4zdL7lOYBOH3cM+J8/drLeST8PqNKO7WgnxAJU7uMr0FghpUE9sxONPeqN 0azgRkDCJikcre0eCe7Fyf/ZAuZKjFgknWn73umX9WXwvbKwh26I/MWQz/3qK7L0A9CLYvytZ 2jkj1O48U5TPOJsDdlKmtDDJkTNxZc0o6EGFBs19DcMkzpShunDU0GTjWpU4BwFuu3ZLhn5Uv 8QrFWM5Nsf/ChaLxsdyGRihiDuwje94BpbvtA7EYIMzboHDcVcdPowtHpuh1uLphEASf7IfTJ 5+tKnvHT/OynOOZyP6laf7uVf9WwzwW2wPuA5gRRyB3VRSRgHtHTldjfff+X97IT0W4o+In+j iirXo6f5NMuVp68YcWZqrb5AX2vrwpCtUaCgPqdWVm1bUtVd/TxZXHdj12mfL9Pya4FWzHRIV cok5o6el2dy2YXfND2ay6FugVq4G7/Ms/7LH75b1ibBWygrqBj1s6f8hZrBHlBVikkMellAD2 TnE/VCAYSsUN+0YuIoOOggFC36Dsf6r+sCCZB4zP0AfEXQhBRWQ57jAv17u6wv9OklG7uUHk+ zqFDnJNm8L5hlSV61PpFp7srA8q9Bu79XWkMafq3dwETlZQvf5TcM2700sGVNbYVIDefWVOVc /M2WWDr80lOpCd0ToS866bO2i7meq2hEBogot2dtYix13s9sDvHCS3hi1nUrIkSO6tMqCIy/w MXplb+64+DqBqbXhG5bQYOQMDBsaXiPgOxoHNtotasDYkUA8eoIm9JZMcE8E=
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: Wed, 06 Nov 2019 23:05:22 -0000

Dear Bob,

> On Nov 6, 2019, at 19:12, Bob Briscoe  wrote:
>=20
> Sebastien,
>=20
> On 06/11/2019 07:18, Sebastian Moeller wrote:
>> Hi Bob,
>>=20
>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe=20
>> 
>>  wrote:
>>=20
>>> Michael, Rod,
>>>=20
>>> Altho non-L4S is a reasonable idea, I think it has more of a =
negative=20
>>> connotation than classic.=20
>>>=20
>>         [SM] It does have the advantage though of being a testable, =
with classic all we know is you are talking about something that came =
before.
> Which is a good starting point, because that's what is intended.=20

	[SM] I know that this is what you intend, but it is the test of =
time that makes classics classics, no amount of wishful thinking of the =
new-kid-on-the-block will relegate the reigning champion into classic =
mode, your solution really has to a) be better, and more importantly b) =
supersede that champion in the first place.


> Plus it already has a slightly positive natural meaning of "something =
robust that has stood the test of time". Then it is defined precisely =
for the context of each L4S doc, e.g.:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2

"Classic service:  The 'Classic' service is intended for all the
      behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
      Compound, SCTP, etc)."

Reading this implies that TCP Reno is not in the classic set, as you =
define that set as those co-existing with Reno and that is does not =
include Reno. But really =3Dyou can define what ever you want, but to =
have others accept your definition it better be useful.

>=20
>=20
>>=20
>> For instance, consider describing Android=20
>>=20
>>> phones as non-iPhones.
>>>=20
>>          [SM] In a discussion of say the merits of iPhones versus the =
competition that seems to be a decent description?
> It is a decent description of the set of all phones that are not =
iPhones. But it has negative connotations when describing an instance, =
as in "Oh, you've got a non-iPhone"
>=20
> Just as it is fine to use the phrase 'non-white people' when =
publishing the results of a survey comparing privileges for white people =
versus everyone else. But it would be totally insulting to describe =
black people as non-white people.

	[SM] Doing that will qualify you as a racist, but your =
description is precise; calling non-white people classic however might =
not be racist but also is not a useful dichotomy. I am totally capable =
of being oposed to both racism and sloppy ad-hoc definitions.


>=20
>>=20
>>> For example, if you did define the name "non-iPhone" to mean phones
>>> such=20
>>> as Android, Windows, etc, then you would expect the phrase =
"non-iPhone=20
>>> knock-off products" to mean "fake Android and Windows phones". =
However=20
>>> the constituent elements "non" and "iPhone" already have a meaning =
of=20
>>> their own, so in the context of this phrase, it means "fake =
iPhones",=20
>>> which is the opposite of what you wanted.
>>>=20
>>         [SM] That is completely besides the point, it made me smile =
though and think about that passage in Alice in Wonderland about the =
meaning of words.
> [BB] Please try to understand why this is very much the critical issue =
(more important than the negative connotation question, which is =
subjective).

	[SM] Your are debating me to score points here, are you? You =
sort all flows into two categories, those that show L4S-style response =
to ECN signals and those that do not. The first group is reasonably =
homogenous, the second is not. So calling the second set non-L4S-style =
seems totally reasonably to me, unless you find another PROPERTY that =
defines that set, and no "classic" is not a property. This is getting as =
ridiculous as your 17 year old car example....


>=20
> I believe you are thinking in the context of all traffic. Let's call =
that set A. And let's call the set of all L4S traffic L1.
> Then in this context, "Non-L4S" naturally means A - L1.
>=20
> However, consider another context, say the context of all Low Latency =
traffic, that we'll call L2. This was the context of the example I found =
in the draft. In that context, the term "Non-L4S" already naturally =
means L2 - L1.

	[SM] Well, for me L4S traffic is traffic that show a "linear" =
response to CE markings instead of a "multiplicative" (we can argue =
whether that is the correct definition, but it sure beats the what ever =
I feel is L4S definition you seem to propose) and in that sense the set =
theoretical observations boil down to your first formulation. The fact =
that the L4S draft allows for your second formulation is a defect in =
that draft. The other stuff is not L4S but rather LoW-Latency traffic =
(which might be qualified to share L4S low latency queue with true L4S =
traffic).

>=20
> So the term "Non-L4S" already has the intended meaning of Classic, but =
only in one context (A), and it has other meanings in every other =
context.

	[SM] If you insist on overloading definitions, be my guest to =
keep the pieces once things break.


>=20
> It's a very bad idea to choose a name that already has a natural =
meaning that can be different to what you want to define the name to =
mean.

	[SM] I apologize I was not thinking about "in Wonderland" but =
about Through the Looking Glass (https://sabian.org/looking_glass6.php) =
:
"'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I =
always pay it extra.'"
L4S has exactly zero natural meaning, so please stop pretending it does.

>=20
>>> The term Classic for the non-L4S service, its queue, its traffic, =
its=20
>>> congestion control, etc. is defined in the terminology section of =
the=20
>>> drafts, so I think it's best to live with this - it's not a =
significant
>>>=20
>>> problem.=20
>>>=20
>>         [SM] If it is not significant, then changing it surely is not =
a problem?
> [BB] Changing it to a problematic name like non-L4S (as explained =
above) would be a problem.=20
>=20
> Leaving it as it is, is not a significant problem, particularly =
because we chose Classic because it had the least negative connotation =
of all the words the thesaurus could throw at us. So this is obviously =
quite a subtle dependence on the mindset of the individuals involved.

	[SM] ??? Seems circular logic to me.


>=20
>=20
>>=20
>> Indeed, it has become widely used and widely understood since=20
>>=20
>>> 2015, and changing it to non-L4S now would cause unnecessary =
confusion.
>>>=20
>>         [SM] By that logic nothing in the L4S drafts should be =
changed? If I recall correctly that is not how getting a draft past =
reviewers works....
> Not at all. The aim of review is to ensure a draft is clearer - you =
will see we've made literally hundreds of changes already in response to =
those sort of requests. A reviewer doesn't have an automatic right to =
have all their requests satisfied, if they are not considered useful by =
the draft editor (or WG consensus if nec.)

	[SM] Sure, at the same time not every draft will be accepted.

>=20
> I am resisting all the suggestions for a change of name so far, =
because "non-L4S" has the context-dependence problem I've already =
described. And all the other suggestions already have at best roughly =
equal negative connotations to Classic.
>=20
> Anyway, nearly any choice of name for "something intended to be =
superseded" will develop negative connotations as soon as it is defined, =
even if it was completely meaningless when first coined.=20

	[SM] How about you first sufficiently demonstrate that your =
"usurper" actually has the chops to dethrone the current king? And then =
if L4S proves ot be superior and dominant you can start calling what was =
before classic or legacy, but until then this seems not helpful.

>=20
> A huge amount of care went into getting the names right, before we =
started.

	[SM] The head winds you encounter here (and I am not really =
counting myself here) seems to indicate that the magnitude might not =
have been sufficient...

SebastiAn


> I remember quoting Dijkstra at my colleagues at the time (I can't find =
the quote right now, but it's about how choice of names is paramount in =
programming). This one is nearly as relevant:=20
> "Besides a mathematical inclination, an exceptionally good mastery of =
one=E2=80=99s native tongue is the most vital asset of a competent =
programmer. " Edsger Dijkstra
>=20
>=20
>=20
> Bob
>=20
>=20
>>=20
>>>=20
>>>=20
>>> Bob
>>>=20
>>>=20
>>>=20
>>> On 04/11/2019 19:21, Scharf, Michael wrote:
>>>=20
>>>> I agree. =E2=80=9Enon-L4S=E2=80=9C may be even better.
>>>>=20
>>>> Michael
>>>>=20
>>>> *Von: *Rodney W. Grimes=20
>>>> 
>>>>=20
>>>> *Gesendet: *Montag, 4. November 2019 20:17
>>>> *An: *Scharf, Michael=20
>>>> 
>>>>=20
>>>> *Cc: *Bob Briscoe=20
>>>> 
>>>> ; Wesley Eddy=20
>>>>=20
>>>> ; tsvwg@ietf.org =

>>>> ;
>>>>=20
>>>> tcpm@ietf.org 
>>>>=20
>>>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>>>>=20
>>>>=20
>>>>> You can e.g. use ?non-L4S-enabled TCP?.
>>>>>=20
>>>>> Terminology does matter to me given that I strongly disagree to =
any
>>>>>=20
>>>> use of ?marketing language? when it comes to TCP.
>>>>=20
>>>> My concern here of use of terms like, legacy, classic, new, old
>>>> is that they are pretty much all of the relative from and thus
>>>> ambiguous over time.
>>>>=20
>>>> newReno is new only relative to Reno, that is fairly clear,
>>>> but if I said newTCP or oldTCP with what frame should the
>>>> reference be evaluated.
>>>>=20
>>>> I believe in the case of L4S the time invariant term would be,
>>>> as Michael suggests above, "non-L4S".   Note that enabled
>>>> for me is a noise word in this context, and TCP may or may
>>>> not be needed depending on context, but for literal replacement
>>>> of Legacy or Classic "non-L4S" is invariant over time.
>>>>=20
>>>> Rod
>>>>=20
>>>>=20
>>>>> Michael
>>>>>=20
>>>>>=20
>>>>> Von: Bob Briscoe
>>>>> 
>>>>>=20
>>>>> Gesendet: Montag, 4. November 2019 19:09
>>>>> An: Scharf, Michael
>>>>> 
>>>>> ; Wesley=20
>>>>>=20
>>>> Eddy
>>>> ;
>>>>=20
>>> tsvwg@ietf.org
>>>>> Cc: tcpm@ietf.org
>>>>>=20
>>>>> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>>>>>=20
>>>>> Michael,
>>>>>=20
>>>>> Previously, I have been told not to use the term standard for RFCs=20=

>>>>>=20
>>>> that are not standards. RFC5681 is 'only' a draft standard. This is=20=

>>>> why, in the IETF at least, I avoid using the term "standard TCP=20
>>>> congestion control". I generally call it Reno when referring to the=20=

>>>> congestion control.
>>>>=20
>>>>> I have never, to my knowledge, used the term classic TCP, or
>>>>>=20
>>> classic=20
>>>=20
>>>> TCP congestion control.
>>>>=20
>>>>> And I rarely use the term legacy, and if I do I'm happy to have=20
>>>>>=20
>>>> alternatives suggested.
>>>>=20
>>>>> I've checked the L4S drafts, and there is one phrase that I shall=20=

>>>>>=20
>>>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase",=20=

>>>> because this is correctly used to mean the traditional increase (in=20=

>>>> numerous AIMD CCs), not traditional TCP. There was one other=20
>>>> occurrence of "traditional TCP senders" in a whole para in an
>>>>=20
>>> appendix=20
>>>=20
>>>> that has just been deleted anyway. And in aqm-dualq-coupled there =
was
>>>>=20
>>>> one "legacy TCP flows" (changed to "Classic traffic" now in my =
local=20
>>>> copy, using the defined term in all the L4S drafts).
>>>>=20
>>>>> l4s-arch is getting a complete make-over for terminology, so I =
will
>>>>>=20
>>>> check that next.
>>>>=20
>>>>> inline...
>>>>>=20
>>>>>=20
>>>>> On 23/08/2019 15:01, Scharf, Michael wrote:
>>>>>=20
>>>>> Hi Wes,
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I?d like to add a smaller item that is mostly editorial and can=20
>>>>>=20
>>>> hopefully be sorted just out by re-wording, albeit it may require a=20=

>>>> careful analysis of all documents.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> As already noted in=20
>>>>>=20
>>> =
https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY
>>>=20
>>>=20
>>>=20
>>>> , I object to the terms ?traditional TCP? and also ?classic TCP? or=20=

>>>> ?legacy? TCP when referring to a TCP implementation according to =
IETF
>>>>=20
>>>> standards-track RFCs.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> To me as a non-native native speaker, all these terms have a=20
>>>>>=20
>>>> negative connotation. I also think this language is typical to=20
>>>> marketing material.
>>>>=20
>>>>> You're entitled to your opinion but, as a native speaker, I don't=20=

>>>>>=20
>>>> think 'classic' or 'traditional' are particularly pejorative, tho
>>>>=20
>>> they=20
>>>=20
>>>> can be when used in a context that intends them to be. They also =
mean
>>>>=20
>>>> "stood the test of time". I find 'legacy' has a connotation of=20
>>>> marketing-speak, but it's not that bad.
>>>>=20
>>>>> This is an enduring problem when trying to improve on the good =
work
>>>>>=20
>>>> that other people have done before you (which is the context of=20
>>>> everything we are doing). We need a word that distinguishes the old=20=

>>>> from the new, but we don't want to completely trash the thing that
>>>>=20
>>> has=20
>>>=20
>>>> already been successful, but had its day.
>>>>=20
>>>>> Nonetheless, it is also important not to be too precious about =
past
>>>>>=20
>>>> work. We all recognize that Reno TCP is unscalable and has =
problems.=20
>>>> IMO, it is OK to describe technologies that have had their time =
with=20
>>>> negative connotations. Indeed, you have been an author (with me) of
>>>>=20
>>> an=20
>>>=20
>>>> RFC on open issues in congestion control.
>>>>=20
>>>>> I notice you haven't suggested an alternative term for "the
>>>>>=20
>>> thing(s)=20
>>>=20
>>>> we are trying to improve on". Not surprising, because it's =
difficult.
>>>>=20
>>>>> When we (the L4S developers) were first looking for a term for the=20=

>>>>>=20
>>>> non-L4S queue and the non-L4S service, we didn't want to use =
'legacy'
>>>>=20
>>>> for the above reasons, but we did want to imply pre-existing, so we=20=

>>>> decided on 'classic', which we all felt had a generally neutral=20
>>>> connotation, but said what we meant.
>>>>=20
>>>>> Finally, I do not want this issue to take up any time that would=20=

>>>>>=20
>>>> detract from technical issues.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Bob
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> My prefered term when referring to TCP according to =
standards-track
>>>>>=20
>>>> specification is ?standard TCP?. I would also be fine with other
>>>>=20
>>> terms=20
>>>=20
>>>> as long as they are neutral and make clear that experiments do not=20=

>>>> replace, deprecate, or outperform standards.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Similarly, I think that term such as ?classic? is not appropriate=20=

>>>>>=20
>>>> for the TCP standard congestion control (?Reno?). As of today, this
>>>>=20
>>> is=20
>>>=20
>>>> the TCP congestion control algorithm on standards track that has =
IETF
>>>>=20
>>>> consensus. The term in the TCPM charter is ?TCP standard congestion=20=

>>>> control?. I also think that terms such as ?Reno-compatible? or the=20=

>>>> like would be neutral.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Note that I do not object to the terms ?classic ECN?, ?legacy =
ECN?,
>>>>>=20
>>>> ?legacy AQM? or the like, i.e., if the context is ECN and not=20
>>>> specifically TCP or the TCP congestion control. I believe it is up =
to
>>>>=20
>>>> the TSVWG do decide if this term shall be used for compliance to =
RFC=20
>>>> 3168. I have no strong opinion on that. As far as I can see, most =
use
>>>>=20
>>>> of the term ?classic? is in this context and I don?t ask for =
changes=20
>>>> in those cases.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Some use of the term ?Classic Service? may also require careful=20
>>>>>=20
>>>> review to clearly separate it from TCP Standard behavior.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Note that some use of the term ?Classic TCP? would probably also=20=

>>>>>=20
>>>> apply to ?Classic QUIC? once the QUIC standard is finished. To me =
as
>>>>=20
>>> a=20
>>>=20
>>>> non-native speaker, it would be really strange to use the term=20
>>>> ?classic? in the context of a brand-new transport protocol. IMHO in=20=

>>>> that case the term ?classic? would be even more confusing.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> I also add the TCPM list in CC to ensure consistency.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Michael (with no hat)
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Von: Wesley Eddy
>>>>> 
>>>>>=20
>>>>> Gesendet: Sonntag, 11. August 2019 07:08
>>>>> An:=20
>>>>> tsvwg@ietf.org
>>>>>=20
>>>>> Betreff: [tsvwg] L4S status tracking
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I created tickets in the TSVWG "trac" tool in order to help keep
>>>>>=20
>>> track
>>>=20
>>>>> of the individual things that look like they should be addressed =
in
>>>>> progressing L4S document set:
>>>>>=20
>>>>>=20
>>>>> https://trac.ietf.org/trac/tsvwg/report/1?sort=3Dticket&asc=3D1&page=
=3D1
>>>>>=20
>>>>>=20
>>>>> 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
>>>>>=20
>>> ticket
>>>=20
>>>>> numbers or some key words in threads and messages, when
>>>>>=20
>>> significant.
>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>>=20
>>>>> tcpm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> ________________________________________________________________
>>>>> Bob Briscoe=20
>>>>> http://bobbriscoe.net/
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>>=20
>>>>> tcpm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>> --=20
>>>> Rod Grimes=20
>>>> rgrimes@freebsd.org
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                              =20
> http://bobbriscoe.net/


From nobody Thu Nov  7 00:11: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 1B9B7120806; Thu,  7 Nov 2019 00:11:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level: 
X-Spam-Status: No, score=-1.986 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, T_KAM_HTML_FONT_INVALID=0.01, 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 Y2tREf2tbUx9; Thu,  7 Nov 2019 00:11:16 -0800 (PST)
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 DAD7A120123; Thu,  7 Nov 2019 00:11:15 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3715625A12; Thu,  7 Nov 2019 09:11:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573114274; bh=Hw390UANnLqeytxXjtDd4MASKJGcIxTxJTrm2ih56dk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=w3nrzanfBYWmS3h/SF3K9Oiw1VQPC3X76ML8JNn7rY6dxG0sVl12aROC/LydzWrsu yytUi5sdDatCyDiqqJRt9F0kWbVb/stnAJtcsfsUKBn/Qj/PgtuNlEdtdtWqHMvqvt FVVcFk6D2Y9de2Ddibm7Vr5/8cr90Fh201YVTL7I=
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 omnsQp8RF8eC; Thu,  7 Nov 2019 09:11:13 +0100 (CET)
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,  7 Nov 2019 09:11:13 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 7 Nov 2019 09:11:12 +0100
From: "Scharf, Michael" 
To: Wesley Eddy , Bob Briscoe , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: "tsvwg@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] [tsvwg] L4S status tracking
Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53v//8bUAgAASJQ6AAdWZAIAAhk2sgACrVICAABElwIAABJqAgADeR5A=
Date: Thu, 7 Nov 2019 08:11:11 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.63.31]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4E732Drznt8114rzntrzd_"
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: Thu, 07 Nov 2019 08:11:18 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E732Drznt8114rzntrzd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

... and just to show that _my_ concern would be trivial to address by small=
 editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an i=
ncremental migration path so that normal TCP traffic classified in the 'Cla=
ssic' service of L4S will be no worse off" would already work for me.  It j=
ust takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service cla=
ss (and, e.g., "normal" sounds better to me), but in the context of a servi=
ce class, "classic" could actually work for me, if TSVWG really wants that =
name with strong consensus. I don't care how about names for DiffSe^D^D^D^D=
^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whateve=
r else is done in the fast path of a router to implement low latency servic=
e.

I only object to specific terminology such as 'Classic' TCP or 'Classic' co=
ngestion control because I don't think that 'classic' is a proper character=
ization for TCPM standards or TCP/IP stack behavior not aligned with whatev=
er L4S believes the bright future shall be.

Whether such small rewording address fully the concerns from others may be =
a different question.

Michael



From: Wesley Eddy 
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael ; Bob Briscoe ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.




If Dave+Michael's suggestion of replacing "classic" with "normal" is agreab=
le to others, this seems like a good way forward to me.  It should be easy =
enough to explain in other SDOs that classic and normal mean the same thing=
, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negativ=
e connotations to it.  However, for the sake of working group progress, I t=
hink we just need to pick something that seems the least terrible and agree=
 to move on.)



--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E732Drznt8114rzntrzd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











… and just to show that _my_ concern would=
 be trivial to address by small editorial changes:


 


For the abstract of draft-ietf-tsvwg-ecn-l4s-id, th=
e wording
“It gives an incremental migration path so that normal TCP traffi=
c classified in the ‘Classic’ service of L4S will be no worse o=
ff” would already work for me.  It just takes a small
 editorial change to make me happy. This can’t be so hard.=



 


Personally, I wonder if “classic” is indeed=
 the best name for a service class (and, e.g., “normal” sounds =
better to me), but in the context of a service class, “classic”
 could actually work for me, if TSVWG really wants that name with strong co=
nsensus. I don’t care how about names for DiffSe^D^D^D^D^D^D traffic =
classifiers, traffic policers/shapers, AQM schemes, or whatever else is don=
e in the fast path of a router to implement
 low latency service.


 


I only object to specific terminology such as ‘Cl=
assic’ TCP or ‘Classic’ congestion control because I don&=
#8217;t think that ‘classic’ is a proper characterization for T=
CPM standards
 or TCP/IP stack behavior not aligned with whatever L4S believes the bright=
 future shall be.


 


Whether such small rewording address fully the concerns=
 from others may be a different question.


 


Michael


 


 


 








From:=
 Wesley Eddy <wes@mti-systems.com>


Sent: Wednesday, November 6, 2019 8:54 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Bob Bris=
coe <ietf@bobbriscoe.net>; Rodney W. Grimes <4bone@gndrsh.dnsmgr.n=
et>

Cc: tsvwg@ietf.org; tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 




On 11/6/2019 1:57 PM, Scharf, Michael wrote:






Bob,


 


From draft-ietf-tsvwg-ecn-l4s-id-08: “It gives an=
 incremental migration path so that existing 'Classic' TCP traffic will be =
no worse off”


 


You are proposing an experiment. Not more than that. I =
will be fine with the term “Classic” for TCP and TCPM-specified=
 congestion control when more than 50% of Internet
 traffic uses that new technology.


 


Until this happens, I insist that the word “Class=
ic” must be removed in all context of TCP and congestion control (as =
far as it is owned by TCPM), including the reference
 above. BTW, “normal” as suggested would also work for me. So, =
you have plenty of options for other terms.


 




 


If Dave+Michael's suggestion of replacing "classic" with &=
quot;normal" is agreable to others, this seems like a good way forward=
 to me.  It should be easy enough to explain in other SDOs that classi=
c and normal mean the same thing, if this is a real issue.


(FWIW, I've never had a problem myself with "classic", nor rea=
d any negative connotations to it.  However, for the sake of working g=
roup progress, I think we just need to pick something that seems the least =
terrible and agree to move on.)


 








--_000_6EC6417807D9754DA64F3087E2E2E03E2D4E732Drznt8114rzntrzd_--


From nobody Thu Nov  7 11:04:55 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 B2F5F120144 for ; Thu,  7 Nov 2019 11:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 YXLtmaQKDGWA for ; Thu,  7 Nov 2019 11:04:51 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 6BF0B1200EB for ; Thu,  7 Nov 2019 11:04:51 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id 8so3704629wmo.0 for ; Thu, 07 Nov 2019 11:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=sO/TS1CrMnDsqVfrVHRRaaEcYP1SW3pbbC2DwRd9Qo8=; b=ftvbaoyUFqDZVBswg1A8d3vpBfzaT170bRV8VTHxm+A2+sS4qEGleGzie6lLRN7KeM pgLyQ0YUWY7Y1RuZGkHt5VhYDoB9rABx4V+4So5ba69fpE4FextKYo8WVN+H86itbUL9 p1KNwvzchJqDhDAV0WJBy5I+oRv+TmAcp/7teiAxtZuLpKjDnU8Oa3t0PhqKzxrQepvL coaiNJ79+GekyM8hFGOMJFElQ9t+DpIcGE/ntqJhcM+PMf67IZKvkbKdcpv61PxxFjtx xre9M/cOQV4/WqyjGu87hkawaTl5vWWnDNQqOWH4/HeLwLvxJPdst0NUu7ZxGEaQAzXM /sJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sO/TS1CrMnDsqVfrVHRRaaEcYP1SW3pbbC2DwRd9Qo8=; b=ApMTEI3BjMS9swqbqIO3WLOgcgS2reLGG5f8iuMxU0gBA6RMGQx0A/JWh3yuvk/mrT L6X62Ur0ld6UOmUZoRDszglgA5p2TTXwOC/vZAhj/q8b3wTdyNcwJxgRks1nk87Ksoh4 ANqI/NblnhbOkxByI7j2J7cTecCAt734dzg17dK1OdVXI5tmuNL5+RNLKqUjZfRFLkeJ LzHpBTnsgFBfgCMUnrC8j6x52SxohhgcdyfL9PGR9XThqcs51XZkYpga+6TSCj65Fsbr swjE/WsEnowfT7WL26Lg5MOP57Lx2ZcFNWmVs2iUKUpRY5pniIVgd03D+hmOjZO0GPes +kbg==
X-Gm-Message-State: APjAAAVhoCS+handGPNn6VZtgo4gKBLICVbi8KO8p6XcSpRnNzwFtmD6 F+loCBI1rI9zLvFtsrUD6Z3RnQSG1DgYhN0Y0FMIug==
X-Google-Smtp-Source: APXvYqwObRS/W1CmFCUFoKWAc7B5Uh84eTs7JGhOMBIYYYTTvs3N5gGUsrcxxJTxQe+5NtzDLO/vB9Zo0IqCxHReWFI=
X-Received: by 2002:a05:600c:21d9:: with SMTP id x25mr4736545wmj.50.1573153489404;  Thu, 07 Nov 2019 11:04:49 -0800 (PST)
MIME-Version: 1.0
From: Yoshifumi Nishida 
Date: Thu, 7 Nov 2019 11:04:38 -0800
Message-ID: 
To: "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="000000000000e9c91f0596c65626"
Archived-At: 
Subject: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 07 Nov 2019 19:04:54 -0000

--000000000000e9c91f0596c65626
Content-Type: text/plain; charset="UTF-8"

Hi,
draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn have been
discussed for a while.
tcpm chairs are now thinking that they are getting matured and becoming
ready for WGLC .
However, we also think there are several points to be clarified beforehand.

In order to proceed the current situation, we would like to ask the
community to give some feedback on the following points.
We will highly appreciate your inputs.

A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn
   The draft requests the allocation for bit 7 in TCP header (ex NS bit)
for this proposal.
   However, the intended status of the draft is experimental, which may not
be well aligned with the description in RFC2780.

  The chairs would like to check the following points.
      A1: If we can have a consensus to allocate bit 7 for this
experimental draft. Or, if there is any other ways to allow the allocation
(e.g. using other documents)
      A2: if we decide to allocate the bit, what we should do when the
experiment fails.

B: Overlaps with some congestion experienced proposals
   It seems that some congestion experienced proposals
(draft-grimes-tcpm-tcpsce
and draft-morton-tsvwg-sce) have similarities with these drafts.

   The chairs would like to check the following points for this.
     B1: The two proposals won't conflict each other. We can discuss and
proceed these proposals separately without any potential risks.
     B2: it seems that SCE and L4S may have some conflicts, but this will
not affect the discussions for AccECN and ECN++.
     B3: if we allocate the bit 7 for AccECN, it is still allowed for SCE
proposals to use the bit or it will be prohibited.

   BTW, just in case. please avoid initiating technical discussions and try
to discuss how to proceed the drafts in this thread.
--
Yoshi on behalf of tcpm chairs

--000000000000e9c91f0596c65626
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,
draft-ietf-tcpm-accurate-ecn and draft-ietf-tcp=
m-generalized-ecn have been discussed for a while.
tcpm chairs ar=
e now thinking that they are getting matured and becoming ready for WGLC .=
=C2=A0
However, we also think there are several points to be clar=
ified beforehand.

In order to proceed the current =
situation, we would like to ask the community to give some feedback on the =
following points.=C2=A0
We will highly appreciate your inputs.

A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn=

=C2=A0 =C2=A0The draft requests the allocation for bit 7 in TCP =
header (ex NS bit) for this proposal.=C2=A0
=C2=A0 =C2=A0However,=
 the intended status of the draft is experimental, which may not be well al=
igned with the description=C2=A0in RFC2780.

=C2=A0=
 The chairs would like to check the following points.
=C2=A0 =C2=
=A0 =C2=A0 A1: If we can have a consensus to allocate bit 7 for this experi=
mental draft. Or, if there is any other ways to allow the allocation (e.g. =
using other documents)
=C2=A0 =C2=A0 =C2=A0 A2: if we decide to a=
llocate the bit, what we should do when the experiment fails.
B: Overlaps with some congestion experienced proposals
=C2=A0 =C2=A0It seems that some congestion experienced proposals (draft-grimes-tcpm-tcpsce and draft-morton-tsv=
wg-sce) have similarities with these drafts.

=C2=
=A0 =C2=A0The chairs would like to check the following points for this.=C2=
=A0
=C2=A0 =C2=A0 =C2=A0B1: The two proposals won'=
t conflict each other. We can discuss and proceed these proposals separatel=
y without any potential risks.
=C2=A0 =C2=A0 =C2=A0B2: it seems t=
hat SCE and L4S may have some conflicts, but this will not affect the discu=
ssions for AccECN and ECN++.=C2=A0
=C2=A0 =C2=A0 =C2=A0B3: if we =
allocate the bit 7 for AccECN, it is still allowed for SCE proposals to use=
 the bit or it will be prohibited.

=C2=A0 =C2=A0BT=
W, just in case. please avoid initiating technical discussions and try to d=
iscuss how to proceed the drafts in this thread.
--
Yos=
hi on behalf of tcpm chairs
=



--000000000000e9c91f0596c65626--


From nobody Thu Nov  7 11:32:38 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 6D54F120967 for ; Thu,  7 Nov 2019 11:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 YQc66o4fSWqP for ; Thu,  7 Nov 2019 11:32:33 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 BEFD2120A8C for ; Thu,  7 Nov 2019 11:32:33 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id q21so2103466vsg.3 for ; Thu, 07 Nov 2019 11:32:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IL9qHKPE/vM8TJsY0ObFjXu/yv02cDZTC5bs2Nnnfxc=; b=a95L9DgpUOewxz0LOh50HB89BpqrHHJlQQYqGV8kpQO6wGTWSAb7pzhBGDfkUFQZeG loW9SFrWcCeoeMuFFiGOknNQcMXCb7QgUHOMVOYFDPHXrkdgzB9R6Whb9rP4LHee1yk2 1WgCtOja4wNGqQb4ySCzxnzKen+YkNw0dmB18Sz4KDL1bFo5saI6fQuW2lLOXqkHT2Nf sU+Z34Yx4WoGJ07Ax3BslMjFPRX7vkfSdZJSIJQM6MDJ6sCjLVRzLE9zENrOgrhZm5Ao brm4xYvPWKXwcKsVhXSQq8seKq2hJVh95Kt11iu7q1bx0k9qo+XBldRa2Hp65mA4mG9r qJ6g==
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; bh=IL9qHKPE/vM8TJsY0ObFjXu/yv02cDZTC5bs2Nnnfxc=; b=syC0XTJMHru/7LP9QTT/6P/t8xBL13l3H4NzyucRqcEyIEsQFFPVgVqQdy6TpKxvqn c/ln61/jj0JjMTYOv+53U2HsLAkFertynOP3kWRvdLThkyOMPa9BEl5EaSEtCahPLm00 C5INjw2+1ExoZ9jkb2lwhOqSGbWstleloKTGB65pvLpGh9cRidOJ9Ryt5eOOxznFr0za enmJvTNhXx/RM37rwT8poi4SoSQGuYqxID5OHEJGynATl0GF1D6uldWCq0+srNgqdYHD SBa8MJAfupV7/1wm0oJ0vzjgSlhPLkd1alzi8Z4EscccCfazwHkBWtohlDT99FFVztpT OIHw==
X-Gm-Message-State: APjAAAVoMKMNKQqc38SuD8JB/8cdDJ16fgOC9DJHpkcnZbGP57a/ITIn HN3C+JcGH1IYiEQdVCKkjb0KPqujWT8qTnJAgLGH06xq
X-Google-Smtp-Source: APXvYqxdD5H9qYeZqtHEwWm2lwA5n3aCzmO8wjFZcBp5WBKezlcf6IfhJdiG7yXM9HZnigyhfoI0qaMFymKW7d/sHjo=
X-Received: by 2002:a05:6102:2323:: with SMTP id b3mr4337055vsa.184.1573155152274;  Thu, 07 Nov 2019 11:32:32 -0800 (PST)
MIME-Version: 1.0
References: <157265157653.31860.1480050311768258768@ietfa.amsl.com>  <61ee8c89-c4ab-349a-5d7c-404976217486@bobbriscoe.net>
In-Reply-To: <61ee8c89-c4ab-349a-5d7c-404976217486@bobbriscoe.net>
From: Yuchung Cheng 
Date: Thu, 7 Nov 2019 11:31:56 -0800
Message-ID: 
To: Bob Briscoe 
Cc: "tcpm@ietf.org Extensions" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rack-06.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: Thu, 07 Nov 2019 19:32:37 -0000

Thank you Bob. We'll queue these fix for next rev.

On Sun, Nov 3, 2019 at 12:44 PM Bob Briscoe  wrote:
>
> Yuchung,
>
> Thx for this.
>
> All the deltas make sense (to me).
>
> FWIW, a couple of nits in the deltas:
>
> s/wether/whether/
>
> s/The [Sprout] congestion control also independently designed/
>   /The [Sprout] congestion control was also independently designed/
>
> Cheers
>
>
>
> Bob
>
> On 01/11/2019 23:55, Yuchung Cheng wrote:
> > On Fri, Nov 1, 2019 at 4:40 PM  wrote:
> >>
> >> 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           : RACK: a time-based fast loss detection algorithm for TCP
> >>          Authors         : Yuchung Cheng
> >>                            Neal Cardwell
> >>                            Nandita Dukkipati
> >>                            Priyaranjan Jha
> >>          Filename        : draft-ietf-tcpm-rack-06.txt
> > This revision primarily addresses the questions raised this year e.g.
> > RACK.RTT definition by Martin Duke, TLP RTO re-arming by Yi Huang, and
> > a new reference on Sprout's similar reo_wnd design by Keith Winstein.
> > Thank you for the reviews.
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>


From nobody Fri Nov  8 00:22: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 1356A12009E for ; Fri,  8 Nov 2019 00:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.335
X-Spam-Level: *
X-Spam-Status: No, score=1.335 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, RCVD_IN_SBL_CSS=3.335, 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=heistp.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 IEJhDlZX3Eox for ; Fri,  8 Nov 2019 00:22:54 -0800 (PST)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 D4D1E12002E for ; Fri,  8 Nov 2019 00:22:53 -0800 (PST)
Received: by mail-wm1-x344.google.com with SMTP id q70so5212745wme.1 for ; Fri, 08 Nov 2019 00:22:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=57WqV2m5+XFgV0/Hp017uitaLN+uhynMJyzZOyrVDQY=; b=IrVomZeQ0jtWqxXXZCQoPBbGLXudJm9496XcItr6jn+bpA4rfEzN5lXwC9yS27W1Il Iaif/HPvWmUHtxT+CB2Tk3bqba5Xbl9fWscVB9W8b+C1cYUuvHfVm1IJnrouf1c6CUxI uISHCgmAilim7Tayzr9lnYkXvi5L414U2bG2mVv9Mb8Opa370f0he0w2DCW/3x2A95Nl Slis+22YgbGthug5Yd3htOsmhHczZKp47DCEsZ8yXXH06NC4RGbDA3bgTZr1yAylm76e aOsIF3rvfYPnMY5fWx8S1mpC6ccvK2LxpRDKiLGXNAuRFMfAdHPtGDNl8Wn+AbXU5m/v SxJw==
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=57WqV2m5+XFgV0/Hp017uitaLN+uhynMJyzZOyrVDQY=; b=N0/9faKTUUaGnpe1kKKHvkWN2YsddflM7PccCNqgoxcnFSIFKsAAJ52UrRu74QhHgM PuZHc7XX1Uq+5bQcnTcw+MRhVSUhkxvzD6ZNL2JgXvhCzeN3aur5K2008jRea9BBMD3r tshcFlLmGsrsG/tRhAmbu96x5WZmNpONrm2SmyZ2rYoX0qKGPOnqFsRNMB2XktL9zdwJ 2AmUIuOe2/ZsfSFOUGM49QHSVXWLaFYZpJFuaqRey+OkYwE5D13RPFkBpUrwZSBv5Q3u DKUHajvwjm4MlEKxrUiGOSqta/HwM4kmsjrp1/GcQLsdaFEfR1LdHznnpFk+iENNeWCd 2fGg==
X-Gm-Message-State: APjAAAVsq0pvVrGDLcU5Tgi/qtJm0zV7AzFp7c2QjV4e9GERkcSYpOGN CLCWfuAhoj3WiZmGMvygDHrzkg==
X-Google-Smtp-Source: APXvYqydTNQQ9oyIqu5GaLY25yQFFibfxOyADgeak7i1d8e/wG2MsNyXfy1wo5SbyNwNthI1xbDsnQ==
X-Received: by 2002:a1c:d8:: with SMTP id 207mr6808666wma.65.1573201372197; Fri, 08 Nov 2019 00:22:52 -0800 (PST)
Received: from [10.6.144.160] ([212.140.138.218]) by smtp.gmail.com with ESMTPSA id n23sm4471972wmc.18.2019.11.08.00.22.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2019 00:22:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist 
In-Reply-To: <201911072222.xA7MMYXb017371@gndrsh.dnsmgr.net>
Date: Fri, 8 Nov 2019 08:22:51 +0000
Cc: tcpm@ietf.org, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, Jonathan Morton 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201911072222.xA7MMYXb017371@gndrsh.dnsmgr.net>
To: nsd.ietf@gmail.com
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 08 Nov 2019 08:22:55 -0000

Hi,

Regarding points A1 and B overall, would it be possible to add to the =
AccECN draft some language such that when it falls back to RFC 3168 ECN, =
the NS bit is still available for other experiments? That way the bit =
could still be used by SCE, even if AccECN becomes a proposed standard.

> From: Yoshifumi Nishida 
> Date: Thu, 7 Nov 2019 11:04:38 -0800
>=20
> Hi,
> draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn have =
been
> discussed for a while.
> tcpm chairs are now thinking that they are getting matured and =
becoming
> ready for WGLC .
> However, we also think there are several points to be clarified =
beforehand.
>=20
> In order to proceed the current situation, we would like to ask the
> community to give some feedback on the following points.
> We will highly appreciate your inputs.
>=20
> A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn
>  The draft requests the allocation for bit 7 in TCP header (ex NS bit)
> for this proposal.
>  However, the intended status of the draft is experimental, which may =
not
> be well aligned with the description in RFC2780.
>=20
> The chairs would like to check the following points.
>     A1: If we can have a consensus to allocate bit 7 for this
> experimental draft. Or, if there is any other ways to allow the =
allocation
> (e.g. using other documents)
>     A2: if we decide to allocate the bit, what we should do when the
> experiment fails.
>=20
> B: Overlaps with some congestion experienced proposals
>  It seems that some congestion experienced proposals
> (draft-grimes-tcpm-tcpsce
> and draft-morton-tsvwg-sce) have similarities with these drafts.
>=20
>  The chairs would like to check the following points for this.
>    B1: The two proposals won't conflict each other. We can discuss and
> proceed these proposals separately without any potential risks.
>    B2: it seems that SCE and L4S may have some conflicts, but this =
will
> not affect the discussions for AccECN and ECN++.
>    B3: if we allocate the bit 7 for AccECN, it is still allowed for =
SCE
> proposals to use the bit or it will be prohibited.
>=20
>  BTW, just in case. please avoid initiating technical discussions and =
try
> to discuss how to proceed the drafts in this thread.
> --
> Yoshi on behalf of tcpm chairs


From nobody Fri Nov  8 09:04:31 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 48679120857; Fri,  8 Nov 2019 09:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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] autolearn=unavailable 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 UXpL1lYNN8D3; Fri,  8 Nov 2019 09:04:24 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150085.outbound.protection.outlook.com [40.107.15.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8B112083B; Fri,  8 Nov 2019 09:04:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MND3lvdHsDgyHbu2vNHNd1ZPjd3XxRdgG2bBU+mC/NULtHhpdm/GoXlQHsVGusF3DlvhzrYWz2viJgP1A6JNuqEEZnb2vlJVG/8sC4ydro5FT64x0b8OdmhoWyoDnqX6CrYfAq16jY54Tk9rKlWfL41A6HcSb9we6WV0K5Kw/PYcTlWw4XfjDoQ4ZTJ1z5SUICEmYX3FMeEUB8qAf/VPCqZ3yb1IqgjESDBHfmBL/jEKyN81mO95NQU8E1hl/82qxzxnirqobkFbOd7E69AczodJf0EkDXbdbR8FwpIiIh8TPI0nKWn7QqcyochQonYzTVAmq7YAeAfVp+jplsBUPA==
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=rVEiS5w2rtyj1BmWc6MNnDeNv5JVo5vag/r5qgg/+YY=; b=CSK1Ba+3oo96G8+89BzvHzePT2XcShBvTJml49t/wLstZTtdR5WqIE7rcVUUJDrmqopIlJF1vYDG4dwphgpW+uM8wG93wR70+3bWqfsXubUJxYGBZOVDAbsxvdNa0SpzUozpF7KQLmzv+SNL0/VNVflqeiXzECLIJjiJAWeYZK9s55VlBulHvCXzUYzj4LjfvTEYRZR7sUu3mgYbOZW0xpRDOQQSUA2g6EkV7DYywvVIQQr2lYPvus7+8k0eoEOVoO7FOjh2SL4jeaOSSWAqpx6ybfzCRrSXhR1jGmNdRzBbZce69SnEF4TBudiJdt9DdIS5U4hUZDc6/W/sf2mTxQ==
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=rVEiS5w2rtyj1BmWc6MNnDeNv5JVo5vag/r5qgg/+YY=; b=O4Csa9E0Kr2vVCevQ3SOM/PTSYQTJxiyc7qY0F91wlvkIzMJMCoJKaLFUGFI+P0l+pLJcbONYcX1XRQjMsZKCEksJLVFjE5QT/E45y4NODr7krjmgH2hKFt+zaJi2+fVA5Fs3JGTEPJgALfTprEff/WrIeGM0f1kemRkc6hUuZo=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3467.eurprd07.prod.outlook.com (10.170.241.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Fri, 8 Nov 2019 17:04:21 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.013; Fri, 8 Nov 2019 17:04:21 +0000
From: Ingemar Johansson S 
To: Sebastian Moeller , Ingemar Johansson S , "Michael.Scharf@hs-esslingen.de" , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , Ingemar Johansson S 
Thread-Topic: [tsvwg] [tcpm]  L4S status tracking
Thread-Index: AQHVlHDpO72yLQ1dAky9TO/zJYqoYqeBgjog
Date: Fri, 8 Nov 2019 17:04:20 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [192.36.80.8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c0abf80b-1449-4594-068f-08d7646db2dd
x-ms-traffictypediagnostic: HE1PR07MB3467:|HE1PR07MB3467:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:483;
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(376002)(366004)(346002)(51444003)(199004)(189003)(13464003)(478600001)(55016002)(81166006)(71190400001)(4326008)(52536014)(446003)(11346002)(8676002)(8936002)(14454004)(25786009)(76176011)(316002)(99286004)(7696005)(33656002)(486006)(6506007)(6116002)(305945005)(229853002)(7736002)(5660300002)(3846002)(30864003)(26005)(81156014)(186003)(53546011)(76116006)(966005)(66556008)(66616009)(6246003)(74316002)(54906003)(71200400001)(110136005)(107886003)(102836004)(66446008)(99936001)(9686003)(14444005)(19627235002)(256004)(6306002)(64756008)(66946007)(6436002)(66476007)(86362001)(5024004)(2501003)(476003)(66066001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3467; H:HE1PR07MB4425.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: BCL:0;
x-microsoft-antispam-message-info: yNtfTUDMOLhOQryt1Oy5yCA4vbhPLUWAwQCGBlmsU0BqnvvcxsnprNQ5ql0HcMvhfRMx004vEzuJpqDM1JHfpY2ZV9DmPx9tVp07a/5fUJ4BTIaH4KTNxZWklCd1yFgc8HbWzo80040IzHlMM/mBZOmJ2OnGVQBOI2mMYDz/oSYjlNvuTPCOhaH0M7myah1a5H3L5wr7QnJXrD6J3+HSaQZNyapKLjrp0aucYP/XqDO+dAi5b146R1bHZme9f6ZiQKZX0IVjKU5amEP/lQjZrKqG5t4iFbi/63whk0zRZjCNcg82MP7AkTWG02JL8o7Aj2XLLTlsbvwIQByvxLtRIeItxNsGL4fJ85blwd/pFkSQDe0WZGZR38cazFqEbI00VD88vqtA44kXAx2oluiA+lyn7tdX/d9gR7FHyihKU2OWObBkct+pShgMiuefFAka
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C7_01D5965E.F1A40C50"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0abf80b-1449-4594-068f-08d7646db2dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 17:04:20.9517 (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: o8qWRuxfSHEfDmObvV3BvvQv6U7LsBQyUwGRBC8AatPWXT023a6fmHbqbv5Q1+BoByM2KZe7Rz4fGs1fQObmc4QgsIvomzfqbHWSmR8w/d6IPYBIfVKaHMVagzoIjopo
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3467
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, 08 Nov 2019 17:04:29 -0000

------=_NextPart_000_00C7_01D5965E.F1A40C50
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sebastian

I clearly mentioned that I would prefer that the term "classic" is kept, =
the earth will likely continue to spin around its axis even if it is =
changed to something else =F0=9F=98=8A. But then it should be something =
that the group can agree on, I don't however see any consensus.=20

/Ingemar=20

> -----Original Message-----
> From: Sebastian Moeller 
> Sent: den 6 november 2019 08:08
> To: Ingemar Johansson S
> ; =
Michael.Scharf@hs-
> esslingen.de; 4bone@gndrsh.dnsmgr.net
> Cc: Ingemar Johansson S ; =
tcpm@ietf.org;
> tsvwg@ietf.org
> Subject: Re: [tsvwg] [tcpm] L4S status tracking
>=20
> Hi Ingmar,
>=20
> IMHO this is a slippery slope argument. Because if minor changes to =
the naming
> are "impossible" how will changed to the underlying concepts and =
methods be
> acceptable to you. Because surely these other organizations already =
committed
> to what is proposed to the IETF as an experiment?
> My gripe with the classic moniker is that this term is not outcome =
neutral. What
> I mean is, that while in itself not necessarily negative, it implies =
that the new kid
> on the block is the way into the future, while the classic version =
should head into
> it's well-deserved retirement. And on the facts this simply is not =
settled or
> accepted in the case of L4S. IMHO the testing published by the =
L4S/RITE folks
> always tested conditions that are very favorable to L4S and completely =
ignored
> to reach out to the actual user community interested in low latency =
under load.
> It might well be that the L4S approach might also do well in a true =
stress test (bi-
> directiomal saturation on a asymmetric path with bursty cross traffic =
for
> starters), but I would like to see numbers first. And the L4S sce =
back-off data
> posted to this list in the path seems to indicate that L4S still has =
open ends that
> IMHO need addressing (independent of whether 3GPP likes this or not).
>=20
> Best Regards
>         Sebastian
>=20
> On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S
>  wrote:
> >Hi
> >
> >I would prefer that the term "Classic" is kept.
> >L4S is not anymore an IETF only matter. Work is ongoing to get =
support
> >for L4S in 3GPP for 5G and the input papers there use the term =
classic.
> >It is of course too late for changing classic to something else, but
> >then it is appreciated that It is something that the group can agree =
on
> >and I don't see that we are there, therefore it is better to stick to
> >"classic".
> >And to me the term "classic" does not sound negative.
> >
> >/Ingemar
> >
> >> Message: 3
> >> Date: Wed, 6 Nov 2019 00:22:44 +0000
> >> From: Bob Briscoe 
> >> To: "Scharf, Michael" , "Rodney W.
> >> 	Grimes" <4bone@gndrsh.dnsmgr.net>
> >> Cc: Wesley Eddy , "tsvwg@ietf.org"
> >> 	, "tcpm@ietf.org" 
> >> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> >> Message-ID: <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net>
> >> Content-Type: text/plain; charset=3D"windows-1252"; =
Format=3D"flowed"
> >>
> >> Michael, Rod,
> >>
> >> Altho non-L4S is a reasonable idea, I think it has more of a =
negative
> >connotation
> >> than classic. For instance, consider describing Android phones as
> >non-iPhones.
> >>
> >> Also, in the ecn-l4s-id draft, we introduce the possibility that =
some
> >operators
> >> might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the
> >same
> >queue as
> >> L4S traffic (and we say that in this case the queue would be called
> >the
> >Low
> >> Latency queue). This shows that the term non-L4S is not a good =
choice
> >for
> >a
> >> name, because the words it is made from already give it a meaning =
of
> >its
> >own
> >> that conflicts with the definition you want it to have in certain
> >contexts.
> >>
> >> For example, if you did define the name "non-iPhone" to mean phones
> >such
> >as
> >> Android, Windows, etc, then you would expect the phrase "non-iPhone
> >knock-
> >> off products" to mean "fake Android and Windows phones". However =
the
> >> constituent elements "non" and "iPhone" already have a meaning of
> >their
> >own,
> >> so in the context of this phrase, it means "fake iPhones", which is
> >the
> >opposite
> >> of what you wanted.
> >>
> >> The term Classic for the non-L4S service, its queue, its traffic, =
its
> >congestion
> >> control, etc. is defined in the terminology section of the drafts, =
so
> >I
> >think it's
> >> best to live with this - it's not a significant problem. Indeed, it
> >has
> >become widely
> >> used and widely understood since 2015, and changing it to non-L4S =
now
> >would
> >> cause unnecessary confusion.
> >>
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >> On 04/11/2019 19:21, Scharf, Michael wrote:
> >> >
> >> > I agree. ?non-L4S? may be even better.
> >> >
> >> > Michael
> >> >
> >> > *Von: *Rodney W. Grimes 
> >> > *Gesendet: *Montag, 4. November 2019 20:17
> >> > *An: *Scharf, Michael 
> >> > *Cc: *Bob Briscoe ; Wesley Eddy
> >> > ; tsvwg@ietf.org
> >;
> >> > tcpm@ietf.org 
> >> > *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
> >> >
> >> > > You can e.g. use ?non-L4S-enabled TCP?.
> >> > >
> >> > > Terminology does matter to me given that I strongly disagree to
> >any
> >> > use of ?marketing language? when it comes to TCP.
> >> >
> >> > My concern here of use of terms like, legacy, classic, new, old =
is
> >> > that they are pretty much all of the relative from and thus
> >ambiguous
> >> > over time.
> >> >
> >> > newReno is new only relative to Reno, that is fairly clear, but =
if
> >I
> >> > said newTCP or oldTCP with what frame should the reference be
> >> > evaluated.
> >> >
> >> > I believe in the case of L4S the time invariant term would be, as
> >> > Michael suggests above, "non-L4S".?? Note that enabled for me is =
a
> >> > noise word in this context, and TCP may or may not be needed
> >depending
> >> > on context, but for literal replacement of Legacy or Classic
> >"non-L4S"
> >> > is invariant over time.
> >> >
> >> > Rod
> >> >
> >> > > Michael
> >> > >
> >> > >
> >> > > Von: Bob Briscoe
> >> > > Gesendet: Montag, 4. November 2019 19:09
> >> > > An: Scharf, Michael;
> >Wesley
> >> > Eddy;
> >> > tsvwg@ietf.org
> >> > > Cc: tcpm@ietf.org
> >> > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking
> >> > >
> >> > > Michael,
> >> > >
> >> > > Previously, I have been told not to use the term standard for
> >RFCs
> >> > that are not standards. RFC5681 is 'only' a draft standard. This =
is
> >> > why, in the IETF at least, I avoid using the term "standard TCP
> >> > congestion control". I generally call it Reno when referring to =
the
> >> > congestion control.
> >> > >
> >> > > I have never, to my knowledge, used the term classic TCP, or
> >classic
> >> > TCP congestion control.
> >> > >
> >> > > And I rarely use the term legacy, and if I do I'm happy to have
> >> > alternatives suggested.
> >> > >
> >> > > I've checked the L4S drafts, and there is one phrase that I =
shall
> >> > leave in ecn-l4s-id: "the traditional TCP Reno additive =
increase",
> >> > because this is correctly used to mean the traditional increase =
(in
> >> > numerous AIMD CCs), not traditional TCP. There was one other
> >> > occurrence of "traditional TCP senders" in a whole para in an
> >appendix
> >> > that has just been deleted anyway. And in aqm-dualq-coupled there
> >was
> >> > one "legacy TCP flows" (changed to "Classic traffic" now in my
> >local
> >> > copy, using the defined term in all the L4S drafts).
> >> > >
> >> > > l4s-arch is getting a complete make-over for terminology, so I
> >will
> >> > check that next.
> >> > >
> >> > > inline...
> >> > >
> >> > >
> >> > > On 23/08/2019 15:01, Scharf, Michael wrote:
> >> > >
> >> > > Hi Wes,
> >> > >
> >> > >
> >> > >
> >> > > I?d 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-
> >> hDvWO3I5MudwpNkKyH
> >> >
> =
>Y >> > KyHY> , I object to the terms ?traditional TCP? and also ?classic
> >TCP?
> >> > or ?legacy? TCP when referring to a TCP implementation according =
to
> >> > IETF standards-track RFCs.
> >> > >
> >> > >
> >> > >
> >> > > To me as a non-native native speaker, all these terms have a
> >> > negative connotation. I also think this language is typical to
> >> > marketing material.
> >> > >
> >> > > You're entitled to your opinion but, as a native speaker, I =
don't
> >> > think 'classic' or 'traditional' are particularly pejorative, tho
> >they
> >> > can be when used in a context that intends them to be. They also
> >mean
> >> > "stood the test of time". I find 'legacy' has a connotation of
> >> > marketing-speak, but it's not that bad.
> >> > >
> >> > > This is an enduring problem when trying to improve on the good
> >work
> >> > that other people have done before you (which is the context of
> >> > everything we are doing). We need a word that distinguishes the =
old
> >> > from the new, but we don't want to completely trash the thing =
that
> >has
> >> > already been successful, but had its day.
> >> > >
> >> > > Nonetheless, it is also important not to be too precious about
> >past
> >> > work. We all recognize that Reno TCP is unscalable and has
> >problems.
> >> > IMO, it is OK to describe technologies that have had their time
> >with
> >> > negative connotations. Indeed, you have been an author (with me) =
of
> >an
> >> > RFC on open issues in congestion control.
> >> > >
> >> > > I notice you haven't suggested an alternative term for "the
> >thing(s)
> >> > we are trying to improve on". Not surprising, because it's
> >difficult.
> >> > >
> >> > > When we (the L4S developers) were first looking for a term for
> >the
> >> > non-L4S queue and the non-L4S service, we didn't want to use
> >'legacy'
> >> > for the above reasons, but we did want to imply pre-existing, so =
we
> >> > decided on 'classic', which we all felt had a generally neutral
> >> > connotation, but said what we meant.
> >> > >
> >> > > Finally, I do not want this issue to take up any time that =
would
> >> > detract from technical issues.
> >> > >
> >> > >
> >> > >
> >> > > Bob
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > My prefered term when referring to TCP according to
> >standards-track
> >> > specification 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 TCP standard congestion control (?Reno?). As of today, =
this
> >is
> >> > the TCP congestion control 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 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 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 and I don?t ask for
> >changes
> >> > in those cases.
> >> > >
> >> > >
> >> > >
> >> > > Some use of the term ?Classic Service? may also require careful
> >> > review to clearly 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 speaker, it would be really strange to use the term
> >> > ?classic? in the context of a brand-new transport protocol. IMHO =
in
> >> > that case the term ?classic? 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.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > tcpm mailing list
> >> > > tcpm@ietf.org
> >> > > https://www.ietf.org/mailman/listinfo/tcpm
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > >
> >>
> ________________________________________________________________
> >> > > Bob Briscoe
> >> > >
> =
>https://protect2.fireeye.com/v1/url?k=3D9e3cf770-c2e8fb81-9e3cb7eb-864
> >> > > 685b2085c-4ba6a1960c4f3e7a&q=3D1&e=3Dbf49c0f0-380b-42d4-93a2-
> >> 9ebedff802e
> >> > > 0&u=3Dhttp%3A%2F%2Fbobbriscoe.net%2F
> >> >
> >> > > _______________________________________________
> >> > > tcpm mailing list
> >> > > tcpm@ietf.org
> >> > > https://www.ietf.org/mailman/listinfo/tcpm
> >> >
> >> > --
> >> > Rod Grimes rgrimes@freebsd.org
> >>
> >> --
> >>
> ________________________________________________________________
> >> Bob Briscoe
> >https://protect2.fireeye.com/v1/url?k=3D861241a8-
> >> dac64d59-86120133-864685b2085c-16120a27ab4a751a&q=3D1&e=3Dbf49c0f0-
> >> 380b-42d4-93a2-9ebedff802e0&u=3Dhttp%3A%2F%2Fbobbriscoe.net%2F
> >>
> >> -------------- next part -------------- An HTML attachment was
> >> scrubbed...
> >> URL:
> >>
> =
> >97
> >> fd1/attachment.html>
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >>
> >>
> >> ------------------------------
> >>
> >> End of tcpm Digest, Vol 187, Issue 15
> >> *************************************
>=20
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

------=_NextPart_000_00C7_01D5965E.F1A40C50
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMDgxNzA0MjBaMCMGCSqGSIb3DQEJBDEWBBRnQUKjdKSmlZ8+ns0W
cC+DyIwBeDBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAGt1wP8KR86xpeswenOxNWTlKFYPDijRQUzzlbb9
+XiBVDBtbxfdN3EZuTxFagXb7gj/nOKCr3tGgf4rTS/cCR/O5BYSZOgqCMmF707TTh2qtBhTWFAZ
fVGsFLJzsPdSQW+6nAsXNkZORva5f3+idXLG8HATM8MqBj5mYjRwZYzXE5NmRY33rIVq8zKfzeAN
iis5X9k7oElfCEkwaoiwlHq3gq6c4jIivFJCG64m9YsPt3msLrD4xjoY2x7wE6nlu3CC6xIZtB+x
mKjXtvjrqPt5vpWNpQc2SwHcaXhrqMvWrZd9RL1XdZD9r4n8x7CAOghUuqXhm/ax2HG8LnSyOhAA
AAAAAAA=

------=_NextPart_000_00C7_01D5965E.F1A40C50--


From nobody Fri Nov  8 09:19: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 AF2CC120861; Fri,  8 Nov 2019 09:19:48 -0800 (PST)
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=unavailable 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 D8Di9uakOZAl; Fri,  8 Nov 2019 09:19:44 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 68018120845; Fri,  8 Nov 2019 09:19:44 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9F0321B00064; Fri,  8 Nov 2019 17:19:34 +0000 (GMT)
Message-ID: <5DC5A3A6.8080406@erg.abdn.ac.uk>
Date: Fri, 08 Nov 2019 17:19:34 +0000
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: Ingemar Johansson S 
CC: Sebastian Moeller ,  "Michael.Scharf@hs-esslingen.de" , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>,  Ingemar Johansson S , "tcpm@ietf.org" , "tsvwg@ietf.org" 
References:   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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, 08 Nov 2019 17:19:49 -0000

I think we need to look to the TCPM working group chairs for advice on 
the naming of TCP varients that are specified in the RFC-series. I 
expect this question can be asked at the next TCPM meeting in Singapore 
- if there is no answer emerging from this thread.

Gorry

On 08/11/2019, 17:04, Ingemar Johansson S wrote:
> Hi Sebastian
>
> I clearly mentioned that I would prefer that the term "classic" is kept, the earth will likely continue to spin around its axis even if it is changed to something else 😊. But then it should be something that the group can agree on, I don't however see any consensus.
>
> /Ingemar
>
>> -----Original Message-----
>> From: Sebastian Moeller
>> Sent: den 6 november 2019 08:08
>> To: Ingemar Johansson S
>> ; Michael.Scharf@hs-
>> esslingen.de; 4bone@gndrsh.dnsmgr.net
>> Cc: Ingemar Johansson S; tcpm@ietf.org;
>> tsvwg@ietf.org
>> Subject: Re: [tsvwg] [tcpm] L4S status tracking
>>
>> Hi Ingmar,
>>
>> IMHO this is a slippery slope argument. Because if minor changes to the naming
>> are "impossible" how will changed to the underlying concepts and methods be
>> acceptable to you. Because surely these other organizations already committed
>> to what is proposed to the IETF as an experiment?
>> My gripe with the classic moniker is that this term is not outcome neutral. What
>> I mean is, that while in itself not necessarily negative, it implies that the new kid
>> on the block is the way into the future, while the classic version should head into
>> it's well-deserved retirement. And on the facts this simply is not settled or
>> accepted in the case of L4S. IMHO the testing published by the L4S/RITE folks
>> always tested conditions that are very favorable to L4S and completely ignored
>> to reach out to the actual user community interested in low latency under load.
>> It might well be that the L4S approach might also do well in a true stress test (bi-
>> directiomal saturation on a asymmetric path with bursty cross traffic for
>> starters), but I would like to see numbers first. And the L4S sce back-off data
>> posted to this list in the path seems to indicate that L4S still has open ends that
>> IMHO need addressing (independent of whether 3GPP likes this or not).
>>
>> Best Regards
>>          Sebastian
>>
>> On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S
>>   wrote:
>>> Hi
>>>
>>> I would prefer that the term "Classic" is kept.
>>> L4S is not anymore an IETF only matter. Work is ongoing to get support
>>> for L4S in 3GPP for 5G and the input papers there use the term classic.
>>> It is of course too late for changing classic to something else, but
>>> then it is appreciated that It is something that the group can agree on
>>> and I don't see that we are there, therefore it is better to stick to
>>> "classic".
>>> And to me the term "classic" does not sound negative.
>>>
>>> /Ingemar
>>>
>>>> Message: 3
>>>> Date: Wed, 6 Nov 2019 00:22:44 +0000
>>>> From: Bob Briscoe
>>>> To: "Scharf, Michael", "Rodney W.
>>>> 	Grimes"<4bone@gndrsh.dnsmgr.net>
>>>> Cc: Wesley Eddy, "tsvwg@ietf.org"
>>>> 	, "tcpm@ietf.org"
>>>> Subject: Re: [tcpm] [tsvwg] L4S status tracking
>>>> Message-ID:<7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net>
>>>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>>>
>>>> Michael, Rod,
>>>>
>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative
>>> connotation
>>>> than classic. For instance, consider describing Android phones as
>>> non-iPhones.
>>>> Also, in the ecn-l4s-id draft, we introduce the possibility that some
>>> operators
>>>> might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the
>>> same
>>> queue as
>>>> L4S traffic (and we say that in this case the queue would be called
>>> the
>>> Low
>>>> Latency queue). This shows that the term non-L4S is not a good choice
>>> for
>>> a
>>>> name, because the words it is made from already give it a meaning of
>>> its
>>> own
>>>> that conflicts with the definition you want it to have in certain
>>> contexts.
>>>> For example, if you did define the name "non-iPhone" to mean phones
>>> such
>>> as
>>>> Android, Windows, etc, then you would expect the phrase "non-iPhone
>>> knock-
>>>> off products" to mean "fake Android and Windows phones". However the
>>>> constituent elements "non" and "iPhone" already have a meaning of
>>> their
>>> own,
>>>> so in the context of this phrase, it means "fake iPhones", which is
>>> the
>>> opposite
>>>> of what you wanted.
>>>>
>>>> The term Classic for the non-L4S service, its queue, its traffic, its
>>> congestion
>>>> control, etc. is defined in the terminology section of the drafts, so
>>> I
>>> think it's
>>>> best to live with this - it's not a significant problem. Indeed, it
>>> has
>>> become widely
>>>> used and widely understood since 2015, and changing it to non-L4S now
>>> would
>>>> cause unnecessary confusion.
>>>>
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>> On 04/11/2019 19:21, Scharf, Michael wrote:
>>>>> I agree. ?non-L4S? may be even better.
>>>>>
>>>>> Michael
>>>>>
>>>>> *Von: *Rodney W. Grimes
>>>>> *Gesendet: *Montag, 4. November 2019 20:17
>>>>> *An: *Scharf, Michael
>>>>> *Cc: *Bob Briscoe; Wesley Eddy
>>>>> ; tsvwg@ietf.org
>>> ;
>>>>> tcpm@ietf.org
>>>>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>>>>>
>>>>>> You can e.g. use ?non-L4S-enabled TCP?.
>>>>>>
>>>>>> Terminology does matter to me given that I strongly disagree to
>>> any
>>>>> use of ?marketing language? when it comes to TCP.
>>>>>
>>>>> My concern here of use of terms like, legacy, classic, new, old is
>>>>> that they are pretty much all of the relative from and thus
>>> ambiguous
>>>>> over time.
>>>>>
>>>>> newReno is new only relative to Reno, that is fairly clear, but if
>>> I
>>>>> said newTCP or oldTCP with what frame should the reference be
>>>>> evaluated.
>>>>>
>>>>> I believe in the case of L4S the time invariant term would be, as
>>>>> Michael suggests above, "non-L4S".?? Note that enabled for me is a
>>>>> noise word in this context, and TCP may or may not be needed
>>> depending
>>>>> on context, but for literal replacement of Legacy or Classic
>>> "non-L4S"
>>>>> is invariant over time.
>>>>>
>>>>> Rod
>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Von: Bob Briscoe
>>>>>> Gesendet: Montag, 4. November 2019 19:09
>>>>>> An: Scharf, Michael;
>>> Wesley
>>>>> Eddy;
>>>>> tsvwg@ietf.org
>>>>>> Cc: tcpm@ietf.org
>>>>>> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>>>>>>
>>>>>> Michael,
>>>>>>
>>>>>> Previously, I have been told not to use the term standard for
>>> RFCs
>>>>> that are not standards. RFC5681 is 'only' a draft standard. This is
>>>>> why, in the IETF at least, I avoid using the term "standard TCP
>>>>> congestion control". I generally call it Reno when referring to the
>>>>> congestion control.
>>>>>> I have never, to my knowledge, used the term classic TCP, or
>>> classic
>>>>> TCP congestion control.
>>>>>> And I rarely use the term legacy, and if I do I'm happy to have
>>>>> alternatives suggested.
>>>>>> I've checked the L4S drafts, and there is one phrase that I shall
>>>>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase",
>>>>> because this is correctly used to mean the traditional increase (in
>>>>> numerous AIMD CCs), not traditional TCP. There was one other
>>>>> occurrence of "traditional TCP senders" in a whole para in an
>>> appendix
>>>>> that has just been deleted anyway. And in aqm-dualq-coupled there
>>> was
>>>>> one "legacy TCP flows" (changed to "Classic traffic" now in my
>>> local
>>>>> copy, using the defined term in all the L4S drafts).
>>>>>> l4s-arch is getting a complete make-over for terminology, so I
>>> will
>>>>> check that next.
>>>>>> inline...
>>>>>>
>>>>>>
>>>>>> On 23/08/2019 15:01, Scharf, Michael wrote:
>>>>>>
>>>>>> Hi Wes,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I?d 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-
>>>> hDvWO3I5MudwpNkKyH
>>> Y>>>> KyHY>  , I object to the terms ?traditional TCP? and also ?classic
>>> TCP?
>>>>> or ?legacy? TCP when referring to a TCP implementation according to
>>>>> IETF standards-track RFCs.
>>>>>>
>>>>>>
>>>>>> To me as a non-native native speaker, all these terms have a
>>>>> negative connotation. I also think this language is typical to
>>>>> marketing material.
>>>>>> You're entitled to your opinion but, as a native speaker, I don't
>>>>> think 'classic' or 'traditional' are particularly pejorative, tho
>>> they
>>>>> can be when used in a context that intends them to be. They also
>>> mean
>>>>> "stood the test of time". I find 'legacy' has a connotation of
>>>>> marketing-speak, but it's not that bad.
>>>>>> This is an enduring problem when trying to improve on the good
>>> work
>>>>> that other people have done before you (which is the context of
>>>>> everything we are doing). We need a word that distinguishes the old
>>>>> from the new, but we don't want to completely trash the thing that
>>> has
>>>>> already been successful, but had its day.
>>>>>> Nonetheless, it is also important not to be too precious about
>>> past
>>>>> work. We all recognize that Reno TCP is unscalable and has
>>> problems.
>>>>> IMO, it is OK to describe technologies that have had their time
>>> with
>>>>> negative connotations. Indeed, you have been an author (with me) of
>>> an
>>>>> RFC on open issues in congestion control.
>>>>>> I notice you haven't suggested an alternative term for "the
>>> thing(s)
>>>>> we are trying to improve on". Not surprising, because it's
>>> difficult.
>>>>>> When we (the L4S developers) were first looking for a term for
>>> the
>>>>> non-L4S queue and the non-L4S service, we didn't want to use
>>> 'legacy'
>>>>> for the above reasons, but we did want to imply pre-existing, so we
>>>>> decided on 'classic', which we all felt had a generally neutral
>>>>> connotation, but said what we meant.
>>>>>> Finally, I do not want this issue to take up any time that would
>>>>> detract from technical issues.
>>>>>>
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> My prefered term when referring to TCP according to
>>> standards-track
>>>>> specification 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 TCP standard congestion control (?Reno?). As of today, this
>>> is
>>>>> the TCP congestion control 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 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 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 and I don?t ask for
>>> changes
>>>>> in those cases.
>>>>>>
>>>>>>
>>>>>> Some use of the term ?Classic Service? may also require careful
>>>>> review to clearly 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 speaker, it would be really strange to use the term
>>>>> ?classic? in the context of a brand-new transport protocol. IMHO in
>>>>> that case the term ?classic? 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=ticket&asc=1&page=1
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> tcpm@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>> ________________________________________________________________
>>>>>> Bob Briscoe
>>>>>>
>>> https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-864
>>>>>> 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2-
>>>> 9ebedff802e
>>>>>> 0&u=http%3A%2F%2Fbobbriscoe.net%2F
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> tcpm@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>> --
>>>>> Rod Grimes rgrimes@freebsd.org
>>>> --
>>>>
>> ________________________________________________________________
>>>> Bob Briscoe
>>> https://protect2.fireeye.com/v1/url?k=861241a8-
>>>> dac64d59-86120133-864685b2085c-16120a27ab4a751a&q=1&e=bf49c0f0-
>>>> 380b-42d4-93a2-9ebedff802e0&u=http%3A%2F%2Fbobbriscoe.net%2F
>>>>
>>>> -------------- next part -------------- An HTML attachment was
>>>> scrubbed...
>>>> URL:
>>>>
>>> >> 97
>>>> fd1/attachment.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of tcpm Digest, Vol 187, Issue 15
>>>> *************************************
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Fri Nov  8 09:22: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 405B3120857; Fri,  8 Nov 2019 09:22:21 -0800 (PST)
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 RCWSDhT5PjHF; Fri,  8 Nov 2019 09:22:18 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5D9120845; Fri,  8 Nov 2019 09:22:18 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 78EFB1B0023F; Fri,  8 Nov 2019 17:22:12 +0000 (GMT)
Message-ID: <5DC5A444.1050002@erg.abdn.ac.uk>
Date: Fri, 08 Nov 2019 17:22:12 +0000
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-chairs@ietf.org" 
CC: "tsvwg-chairs@ietf.org" ,  "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>, Ingemar Johansson S ,  "tcpm@ietf.org" , "tsvwg@ietf.org" 
References:   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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, 08 Nov 2019 17:22:21 -0000

Going up one level. This is punted to you as chairs for a common decison 
- AFAIK, it is your protocol to maintain, please think and advise on 
what it is called.

Gorry

On 08/11/2019, 17:04, Ingemar Johansson S wrote:
> Hi Sebastian
>
> I clearly mentioned that I would prefer that the term "classic" is kept, the earth will likely continue to spin around its axis even if it is changed to something else 😊. But then it should be something that the group can agree on, I don't however see any consensus.
>
> /Ingemar
>
>> -----Original Message-----
>> From: Sebastian Moeller
>> Sent: den 6 november 2019 08:08
>> To: Ingemar Johansson S
>> ; Michael.Scharf@hs-
>> esslingen.de; 4bone@gndrsh.dnsmgr.net
>> Cc: Ingemar Johansson S; tcpm@ietf.org;
>> tsvwg@ietf.org
>> Subject: Re: [tsvwg] [tcpm] L4S status tracking
>>
>> Hi Ingmar,
>>
>> IMHO this is a slippery slope argument. Because if minor changes to the naming
>> are "impossible" how will changed to the underlying concepts and methods be
>> acceptable to you. Because surely these other organizations already committed
>> to what is proposed to the IETF as an experiment?
>> My gripe with the classic moniker is that this term is not outcome neutral. What
>> I mean is, that while in itself not necessarily negative, it implies that the new kid
>> on the block is the way into the future, while the classic version should head into
>> it's well-deserved retirement. And on the facts this simply is not settled or
>> accepted in the case of L4S. IMHO the testing published by the L4S/RITE folks
>> always tested conditions that are very favorable to L4S and completely ignored
>> to reach out to the actual user community interested in low latency under load.
>> It might well be that the L4S approach might also do well in a true stress test (bi-
>> directiomal saturation on a asymmetric path with bursty cross traffic for
>> starters), but I would like to see numbers first. And the L4S sce back-off data
>> posted to this list in the path seems to indicate that L4S still has open ends that
>> IMHO need addressing (independent of whether 3GPP likes this or not).
>>
>> Best Regards
>>          Sebastian
>>
>> On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S
>>   wrote:
>>> Hi
>>>
>>> I would prefer that the term "Classic" is kept.
>>> L4S is not anymore an IETF only matter. Work is ongoing to get support
>>> for L4S in 3GPP for 5G and the input papers there use the term classic.
>>> It is of course too late for changing classic to something else, but
>>> then it is appreciated that It is something that the group can agree on
>>> and I don't see that we are there, therefore it is better to stick to
>>> "classic".
>>> And to me the term "classic" does not sound negative.
>>>
>>> /Ingemar
>>>
>>>> Message: 3
>>>> Date: Wed, 6 Nov 2019 00:22:44 +0000
>>>> From: Bob Briscoe
>>>> To: "Scharf, Michael", "Rodney W.
>>>> 	Grimes"<4bone@gndrsh.dnsmgr.net>
>>>> Cc: Wesley Eddy, "tsvwg@ietf.org"
>>>> 	, "tcpm@ietf.org"
>>>> Subject: Re: [tcpm] [tsvwg] L4S status tracking
>>>> Message-ID:<7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net>
>>>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>>>
>>>> Michael, Rod,
>>>>
>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative
>>> connotation
>>>> than classic. For instance, consider describing Android phones as
>>> non-iPhones.
>>>> Also, in the ecn-l4s-id draft, we introduce the possibility that some
>>> operators
>>>> might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the
>>> same
>>> queue as
>>>> L4S traffic (and we say that in this case the queue would be called
>>> the
>>> Low
>>>> Latency queue). This shows that the term non-L4S is not a good choice
>>> for
>>> a
>>>> name, because the words it is made from already give it a meaning of
>>> its
>>> own
>>>> that conflicts with the definition you want it to have in certain
>>> contexts.
>>>> For example, if you did define the name "non-iPhone" to mean phones
>>> such
>>> as
>>>> Android, Windows, etc, then you would expect the phrase "non-iPhone
>>> knock-
>>>> off products" to mean "fake Android and Windows phones". However the
>>>> constituent elements "non" and "iPhone" already have a meaning of
>>> their
>>> own,
>>>> so in the context of this phrase, it means "fake iPhones", which is
>>> the
>>> opposite
>>>> of what you wanted.
>>>>
>>>> The term Classic for the non-L4S service, its queue, its traffic, its
>>> congestion
>>>> control, etc. is defined in the terminology section of the drafts, so
>>> I
>>> think it's
>>>> best to live with this - it's not a significant problem. Indeed, it
>>> has
>>> become widely
>>>> used and widely understood since 2015, and changing it to non-L4S now
>>> would
>>>> cause unnecessary confusion.
>>>>
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>> On 04/11/2019 19:21, Scharf, Michael wrote:
>>>>> I agree. ?non-L4S? may be even better.
>>>>>
>>>>> Michael
>>>>>
>>>>> *Von: *Rodney W. Grimes
>>>>> *Gesendet: *Montag, 4. November 2019 20:17
>>>>> *An: *Scharf, Michael
>>>>> *Cc: *Bob Briscoe; Wesley Eddy
>>>>> ; tsvwg@ietf.org
>>> ;
>>>>> tcpm@ietf.org
>>>>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>>>>>
>>>>>> You can e.g. use ?non-L4S-enabled TCP?.
>>>>>>
>>>>>> Terminology does matter to me given that I strongly disagree to
>>> any
>>>>> use of ?marketing language? when it comes to TCP.
>>>>>
>>>>> My concern here of use of terms like, legacy, classic, new, old is
>>>>> that they are pretty much all of the relative from and thus
>>> ambiguous
>>>>> over time.
>>>>>
>>>>> newReno is new only relative to Reno, that is fairly clear, but if
>>> I
>>>>> said newTCP or oldTCP with what frame should the reference be
>>>>> evaluated.
>>>>>
>>>>> I believe in the case of L4S the time invariant term would be, as
>>>>> Michael suggests above, "non-L4S".?? Note that enabled for me is a
>>>>> noise word in this context, and TCP may or may not be needed
>>> depending
>>>>> on context, but for literal replacement of Legacy or Classic
>>> "non-L4S"
>>>>> is invariant over time.
>>>>>
>>>>> Rod
>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Von: Bob Briscoe
>>>>>> Gesendet: Montag, 4. November 2019 19:09
>>>>>> An: Scharf, Michael;
>>> Wesley
>>>>> Eddy;
>>>>> tsvwg@ietf.org
>>>>>> Cc: tcpm@ietf.org
>>>>>> Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>>>>>>
>>>>>> Michael,
>>>>>>
>>>>>> Previously, I have been told not to use the term standard for
>>> RFCs
>>>>> that are not standards. RFC5681 is 'only' a draft standard. This is
>>>>> why, in the IETF at least, I avoid using the term "standard TCP
>>>>> congestion control". I generally call it Reno when referring to the
>>>>> congestion control.
>>>>>> I have never, to my knowledge, used the term classic TCP, or
>>> classic
>>>>> TCP congestion control.
>>>>>> And I rarely use the term legacy, and if I do I'm happy to have
>>>>> alternatives suggested.
>>>>>> I've checked the L4S drafts, and there is one phrase that I shall
>>>>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase",
>>>>> because this is correctly used to mean the traditional increase (in
>>>>> numerous AIMD CCs), not traditional TCP. There was one other
>>>>> occurrence of "traditional TCP senders" in a whole para in an
>>> appendix
>>>>> that has just been deleted anyway. And in aqm-dualq-coupled there
>>> was
>>>>> one "legacy TCP flows" (changed to "Classic traffic" now in my
>>> local
>>>>> copy, using the defined term in all the L4S drafts).
>>>>>> l4s-arch is getting a complete make-over for terminology, so I
>>> will
>>>>> check that next.
>>>>>> inline...
>>>>>>
>>>>>>
>>>>>> On 23/08/2019 15:01, Scharf, Michael wrote:
>>>>>>
>>>>>> Hi Wes,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I?d 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-
>>>> hDvWO3I5MudwpNkKyH
>>> Y>>>> KyHY>  , I object to the terms ?traditional TCP? and also ?classic
>>> TCP?
>>>>> or ?legacy? TCP when referring to a TCP implementation according to
>>>>> IETF standards-track RFCs.
>>>>>>
>>>>>>
>>>>>> To me as a non-native native speaker, all these terms have a
>>>>> negative connotation. I also think this language is typical to
>>>>> marketing material.
>>>>>> You're entitled to your opinion but, as a native speaker, I don't
>>>>> think 'classic' or 'traditional' are particularly pejorative, tho
>>> they
>>>>> can be when used in a context that intends them to be. They also
>>> mean
>>>>> "stood the test of time". I find 'legacy' has a connotation of
>>>>> marketing-speak, but it's not that bad.
>>>>>> This is an enduring problem when trying to improve on the good
>>> work
>>>>> that other people have done before you (which is the context of
>>>>> everything we are doing). We need a word that distinguishes the old
>>>>> from the new, but we don't want to completely trash the thing that
>>> has
>>>>> already been successful, but had its day.
>>>>>> Nonetheless, it is also important not to be too precious about
>>> past
>>>>> work. We all recognize that Reno TCP is unscalable and has
>>> problems.
>>>>> IMO, it is OK to describe technologies that have had their time
>>> with
>>>>> negative connotations. Indeed, you have been an author (with me) of
>>> an
>>>>> RFC on open issues in congestion control.
>>>>>> I notice you haven't suggested an alternative term for "the
>>> thing(s)
>>>>> we are trying to improve on". Not surprising, because it's
>>> difficult.
>>>>>> When we (the L4S developers) were first looking for a term for
>>> the
>>>>> non-L4S queue and the non-L4S service, we didn't want to use
>>> 'legacy'
>>>>> for the above reasons, but we did want to imply pre-existing, so we
>>>>> decided on 'classic', which we all felt had a generally neutral
>>>>> connotation, but said what we meant.
>>>>>> Finally, I do not want this issue to take up any time that would
>>>>> detract from technical issues.
>>>>>>
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> My prefered term when referring to TCP according to
>>> standards-track
>>>>> specification 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 TCP standard congestion control (?Reno?). As of today, this
>>> is
>>>>> the TCP congestion control 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 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 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 and I don?t ask for
>>> changes
>>>>> in those cases.
>>>>>>
>>>>>>
>>>>>> Some use of the term ?Classic Service? may also require careful
>>>>> review to clearly 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 speaker, it would be really strange to use the term
>>>>> ?classic? in the context of a brand-new transport protocol. IMHO in
>>>>> that case the term ?classic? 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=ticket&asc=1&page=1
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> tcpm@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>> ________________________________________________________________
>>>>>> Bob Briscoe
>>>>>>
>>> https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-864
>>>>>> 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2-
>>>> 9ebedff802e
>>>>>> 0&u=http%3A%2F%2Fbobbriscoe.net%2F
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> tcpm@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>> --
>>>>> Rod Grimes rgrimes@freebsd.org
>>>> --
>>>>
>> ________________________________________________________________
>>>> Bob Briscoe
>>> https://protect2.fireeye.com/v1/url?k=861241a8-
>>>> dac64d59-86120133-864685b2085c-16120a27ab4a751a&q=1&e=bf49c0f0-
>>>> 380b-42d4-93a2-9ebedff802e0&u=http%3A%2F%2Fbobbriscoe.net%2F
>>>>
>>>> -------------- next part -------------- An HTML attachment was
>>>> scrubbed...
>>>> URL:
>>>>
>>> >> 97
>>>> fd1/attachment.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of tcpm Digest, Vol 187, Issue 15
>>>> *************************************
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Fri Nov  8 10:41: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 C6B2D120089; Fri,  8 Nov 2019 10:41:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] autolearn=unavailable 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 CFbBNGHMVhT9; Fri,  8 Nov 2019 10:41:07 -0800 (PST)
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 1B73212094D; Fri,  8 Nov 2019 10:41:07 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9632725A12; Fri,  8 Nov 2019 19:41:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573238465; bh=o4UUCfrO8jGV7sYDpATshwTqHt8LsKTFCodM3QZNmbI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=zKHXc2/7BLGap3kOUmcJM8UQSKnlGyQcTn9pUJ6N/Nzyv3UpGBlzSvP3cF7KUXYZA xOI2ULB72YFq9A5GPrWWoIT7tTwG8KuckY2t6p2eSwMxvIICK2RdQ1lC56AMDtXyKy nNJ9rMZSg/Y4+OuZQXzkek24Lg2hoqIb469Ti0AA=
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 HSAinAyC661h; Fri,  8 Nov 2019 19:41:04 +0100 (CET)
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; Fri,  8 Nov 2019 19:41:04 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 8 Nov 2019 19:41:03 +0100
From: "Scharf, Michael" 
To: Ingemar Johansson S , Sebastian Moeller , Ingemar Johansson S , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] [tcpm]  L4S status tracking
Thread-Index: AQHVlHDo/QyQY/CFY0WIa8bThLkPwaeBc3oAgAAjRRA=
Date: Fri, 8 Nov 2019 18:41:02 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de>
References:   
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.63.11]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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, 08 Nov 2019 18:41:11 -0000

SGkgSW5nZW1hciwNCg0KQSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbiwgZ2l2ZW4gdGhhdCB0
aGUgdGVybSAiY2xhc3NpYyIgaXMgdXNlZCBmb3IgZGlmZmVyZW50IGFzcGVjdHMgaW4gTDRTOg0K
DQpEb2VzIHlvdXIgcHJlZmVyZW5jZSBpbmNsdWRlIHRoZSB0ZXJtcyAnQ2xhc3NpYycgVENQIGFu
ZCAnQ2xhc3NpYycgY29uZ2VzdGlvbiBjb250cm9sLCBzcGVjaWZpY2FsbHkgd2hlbiByZWZlcnJp
bmcgdG8gYSBzdGF0ZS1vZi10aGUtYXJ0IFRDUCBzdGFjayBhcyBjdXJyZW50bHkgc2hpcHBlZCBi
eSBtYWpvciBvcGVyYXRpbmcgc3lzdGVtcz8NCg0KSWYgc28sIGNhbiB5b3UgcHJvdmlkZSByZWZl
cmVuY2VzIGZvciB1c2Ugb2YgdGhlIHRlcm1zICdDbGFzc2ljJyBUQ1AgYW5kICdDbGFzc2ljJyBj
b25nZXN0aW9uIGNvbnRyb2wgZm9yIHdoYXQgaXMgY3VycmVudGx5IHdpZGVseSBkZXBsb3llZCBp
biB0aGUgSW50ZXJuZXQ/IA0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQoNCg0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMu
am9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciA4LCAyMDE5
IDY6MDQgUE0NCj4gVG86IFNlYmFzdGlhbiBNb2VsbGVyIDxtb2VsbGVyMEBnbXguZGU+OyBJbmdl
bWFyIEpvaGFuc3NvbiBTDQo+IDxpbmdlbWFyLnMuam9oYW5zc29uPTQwZXJpY3Nzb24uY29tQGRt
YXJjLmlldGYub3JnPjsgU2NoYXJmLCBNaWNoYWVsDQo+IDxNaWNoYWVsLlNjaGFyZkBocy1lc3Ns
aW5nZW4uZGU+OyA0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldA0KPiBDYzogdGNwbUBpZXRmLm9yZzsg
dHN2d2dAaWV0Zi5vcmc7IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPGluZ2VtYXIucy5qb2hhbnNz
b25AZXJpY3Nzb24uY29tPg0KPiBTdWJqZWN0OiBSRTogW3RzdndnXSBbdGNwbV0gTDRTIHN0YXR1
cyB0cmFja2luZw0KPiANCj4gSGkgU2ViYXN0aWFuDQo+IA0KPiBJIGNsZWFybHkgbWVudGlvbmVk
IHRoYXQgSSB3b3VsZCBwcmVmZXIgdGhhdCB0aGUgdGVybSAiY2xhc3NpYyIgaXMga2VwdCwgdGhl
IGVhcnRoDQo+IHdpbGwgbGlrZWx5IGNvbnRpbnVlIHRvIHNwaW4gYXJvdW5kIGl0cyBheGlzIGV2
ZW4gaWYgaXQgaXMgY2hhbmdlZCB0byBzb21ldGhpbmcgZWxzZQ0KPiDwn5iKLiBCdXQgdGhlbiBp
dCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgdGhlIGdyb3VwIGNhbiBhZ3JlZSBvbiwgSSBkb24n
dCBob3dldmVyDQo+IHNlZSBhbnkgY29uc2Vuc3VzLg0KPiANCj4gL0luZ2VtYXINCj4gDQo+ID4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTZWJhc3RpYW4gTW9lbGxlciA8
bW9lbGxlcjBAZ214LmRlPg0KPiA+IFNlbnQ6IGRlbiA2IG5vdmVtYmVyIDIwMTkgMDg6MDgNCj4g
PiBUbzogSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+IDxpbmdlbWFyLnMuam9oYW5zc29uPTQwZXJp
Y3Nzb24uY29tQGRtYXJjLmlldGYub3JnPjsgTWljaGFlbC5TY2hhcmZAaHMtDQo+ID4gZXNzbGlu
Z2VuLmRlOyA0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldA0KPiA+IENjOiBJbmdlbWFyIEpvaGFuc3Nv
biBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT47DQo+IHRjcG1AaWV0Zi5vcmc7
DQo+ID4gdHN2d2dAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3RzdndnXSBbdGNwbV0gTDRT
IHN0YXR1cyB0cmFja2luZw0KPiA+DQo+ID4gSGkgSW5nbWFyLA0KPiA+DQo+ID4gSU1ITyB0aGlz
IGlzIGEgc2xpcHBlcnkgc2xvcGUgYXJndW1lbnQuIEJlY2F1c2UgaWYgbWlub3IgY2hhbmdlcyB0
byB0aGUNCj4gbmFtaW5nDQo+ID4gYXJlICJpbXBvc3NpYmxlIiBob3cgd2lsbCBjaGFuZ2VkIHRv
IHRoZSB1bmRlcmx5aW5nIGNvbmNlcHRzIGFuZCBtZXRob2RzDQo+IGJlDQo+ID4gYWNjZXB0YWJs
ZSB0byB5b3UuIEJlY2F1c2Ugc3VyZWx5IHRoZXNlIG90aGVyIG9yZ2FuaXphdGlvbnMgYWxyZWFk
eQ0KPiBjb21taXR0ZWQNCj4gPiB0byB3aGF0IGlzIHByb3Bvc2VkIHRvIHRoZSBJRVRGIGFzIGFu
IGV4cGVyaW1lbnQ/DQo+ID4gTXkgZ3JpcGUgd2l0aCB0aGUgY2xhc3NpYyBtb25pa2VyIGlzIHRo
YXQgdGhpcyB0ZXJtIGlzIG5vdCBvdXRjb21lIG5ldXRyYWwuDQo+IFdoYXQNCj4gPiBJIG1lYW4g
aXMsIHRoYXQgd2hpbGUgaW4gaXRzZWxmIG5vdCBuZWNlc3NhcmlseSBuZWdhdGl2ZSwgaXQgaW1w
bGllcyB0aGF0IHRoZSBuZXcNCj4ga2lkDQo+ID4gb24gdGhlIGJsb2NrIGlzIHRoZSB3YXkgaW50
byB0aGUgZnV0dXJlLCB3aGlsZSB0aGUgY2xhc3NpYyB2ZXJzaW9uIHNob3VsZCBoZWFkDQo+IGlu
dG8NCj4gPiBpdCdzIHdlbGwtZGVzZXJ2ZWQgcmV0aXJlbWVudC4gQW5kIG9uIHRoZSBmYWN0cyB0
aGlzIHNpbXBseSBpcyBub3Qgc2V0dGxlZCBvcg0KPiA+IGFjY2VwdGVkIGluIHRoZSBjYXNlIG9m
IEw0Uy4gSU1ITyB0aGUgdGVzdGluZyBwdWJsaXNoZWQgYnkgdGhlIEw0Uy9SSVRFIGZvbGtzDQo+
ID4gYWx3YXlzIHRlc3RlZCBjb25kaXRpb25zIHRoYXQgYXJlIHZlcnkgZmF2b3JhYmxlIHRvIEw0
UyBhbmQgY29tcGxldGVseQ0KPiBpZ25vcmVkDQo+ID4gdG8gcmVhY2ggb3V0IHRvIHRoZSBhY3R1
YWwgdXNlciBjb21tdW5pdHkgaW50ZXJlc3RlZCBpbiBsb3cgbGF0ZW5jeSB1bmRlcg0KPiBsb2Fk
Lg0KPiA+IEl0IG1pZ2h0IHdlbGwgYmUgdGhhdCB0aGUgTDRTIGFwcHJvYWNoIG1pZ2h0IGFsc28g
ZG8gd2VsbCBpbiBhIHRydWUgc3RyZXNzIHRlc3QNCj4gKGJpLQ0KPiA+IGRpcmVjdGlvbWFsIHNh
dHVyYXRpb24gb24gYSBhc3ltbWV0cmljIHBhdGggd2l0aCBidXJzdHkgY3Jvc3MgdHJhZmZpYyBm
b3INCj4gPiBzdGFydGVycyksIGJ1dCBJIHdvdWxkIGxpa2UgdG8gc2VlIG51bWJlcnMgZmlyc3Qu
IEFuZCB0aGUgTDRTIHNjZSBiYWNrLW9mZiBkYXRhDQo+ID4gcG9zdGVkIHRvIHRoaXMgbGlzdCBp
biB0aGUgcGF0aCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IEw0UyBzdGlsbCBoYXMgb3BlbiBlbmRz
DQo+IHRoYXQNCj4gPiBJTUhPIG5lZWQgYWRkcmVzc2luZyAoaW5kZXBlbmRlbnQgb2Ygd2hldGhl
ciAzR1BQIGxpa2VzIHRoaXMgb3Igbm90KS4NCj4gPg0KPiA+IEJlc3QgUmVnYXJkcw0KPiA+ICAg
ICAgICAgU2ViYXN0aWFuDQo+ID4NCj4gPiBPbiBOb3ZlbWJlciA2LCAyMDE5IDc6MTI6MzkgQU0g
R01UKzAxOjAwLCBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+ID4gPGluZ2VtYXIucy5qb2hhbnNzb249
NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID5IaQ0KPiA+ID4NCj4g
PiA+SSB3b3VsZCBwcmVmZXIgdGhhdCB0aGUgdGVybSAiQ2xhc3NpYyIgaXMga2VwdC4NCj4gPiA+
TDRTIGlzIG5vdCBhbnltb3JlIGFuIElFVEYgb25seSBtYXR0ZXIuIFdvcmsgaXMgb25nb2luZyB0
byBnZXQgc3VwcG9ydA0KPiA+ID5mb3IgTDRTIGluIDNHUFAgZm9yIDVHIGFuZCB0aGUgaW5wdXQg
cGFwZXJzIHRoZXJlIHVzZSB0aGUgdGVybSBjbGFzc2ljLg0KPiA+ID5JdCBpcyBvZiBjb3Vyc2Ug
dG9vIGxhdGUgZm9yIGNoYW5naW5nIGNsYXNzaWMgdG8gc29tZXRoaW5nIGVsc2UsIGJ1dA0KPiA+
ID50aGVuIGl0IGlzIGFwcHJlY2lhdGVkIHRoYXQgSXQgaXMgc29tZXRoaW5nIHRoYXQgdGhlIGdy
b3VwIGNhbiBhZ3JlZSBvbg0KPiA+ID5hbmQgSSBkb24ndCBzZWUgdGhhdCB3ZSBhcmUgdGhlcmUs
IHRoZXJlZm9yZSBpdCBpcyBiZXR0ZXIgdG8gc3RpY2sgdG8NCj4gPiA+ImNsYXNzaWMiLg0KPiA+
ID5BbmQgdG8gbWUgdGhlIHRlcm0gImNsYXNzaWMiIGRvZXMgbm90IHNvdW5kIG5lZ2F0aXZlLg0K
PiA+ID4NCj4gPiA+L0luZ2VtYXINCj4gPiA+DQo+ID4gPj4gTWVzc2FnZTogMw0KPiA+ID4+IERh
dGU6IFdlZCwgNiBOb3YgMjAxOSAwMDoyMjo0NCArMDAwMA0KPiA+ID4+IEZyb206IEJvYiBCcmlz
Y29lIDxpZXRmQGJvYmJyaXNjb2UubmV0Pg0KPiA+ID4+IFRvOiAiU2NoYXJmLCBNaWNoYWVsIiA8
TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPiwgIlJvZG5leSBXLg0KPiA+ID4+IAlHcmlt
ZXMiIDw0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldD4NCj4gPiA+PiBDYzogV2VzbGV5IEVkZHkgPHdl
c0BtdGktc3lzdGVtcy5jb20+LCAidHN2d2dAaWV0Zi5vcmciDQo+ID4gPj4gCTx0c3Z3Z0BpZXRm
Lm9yZz4sICJ0Y3BtQGlldGYub3JnIiA8dGNwbUBpZXRmLm9yZz4NCj4gPiA+PiBTdWJqZWN0OiBS
ZTogW3RjcG1dIFt0c3Z3Z10gTDRTIHN0YXR1cyB0cmFja2luZw0KPiA+ID4+IE1lc3NhZ2UtSUQ6
IDw3ZjFhYTRhZS0wNWQ2LWIwN2MtNTBiMC1hYjg5OWM1YzMwYjdAYm9iYnJpc2NvZS5uZXQ+DQo+
ID4gPj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ3aW5kb3dzLTEyNTIiOyBG
b3JtYXQ9ImZsb3dlZCINCj4gPiA+Pg0KPiA+ID4+IE1pY2hhZWwsIFJvZCwNCj4gPiA+Pg0KPiA+
ID4+IEFsdGhvIG5vbi1MNFMgaXMgYSByZWFzb25hYmxlIGlkZWEsIEkgdGhpbmsgaXQgaGFzIG1v
cmUgb2YgYSBuZWdhdGl2ZQ0KPiA+ID5jb25ub3RhdGlvbg0KPiA+ID4+IHRoYW4gY2xhc3NpYy4g
Rm9yIGluc3RhbmNlLCBjb25zaWRlciBkZXNjcmliaW5nIEFuZHJvaWQgcGhvbmVzIGFzDQo+ID4g
Pm5vbi1pUGhvbmVzLg0KPiA+ID4+DQo+ID4gPj4gQWxzbywgaW4gdGhlIGVjbi1sNHMtaWQgZHJh
ZnQsIHdlIGludHJvZHVjZSB0aGUgcG9zc2liaWxpdHkgdGhhdCBzb21lDQo+ID4gPm9wZXJhdG9y
cw0KPiA+ID4+IG1pZ2h0IGNsYXNzaWZ5IG5vbi1MNFMgdHJhZmZpYyAoRE5TLCBWb0lQLCBFRiwg
TlFCLCBldGMpIGludG8gdGhlDQo+ID4gPnNhbWUNCj4gPiA+cXVldWUgYXMNCj4gPiA+PiBMNFMg
dHJhZmZpYyAoYW5kIHdlIHNheSB0aGF0IGluIHRoaXMgY2FzZSB0aGUgcXVldWUgd291bGQgYmUg
Y2FsbGVkDQo+ID4gPnRoZQ0KPiA+ID5Mb3cNCj4gPiA+PiBMYXRlbmN5IHF1ZXVlKS4gVGhpcyBz
aG93cyB0aGF0IHRoZSB0ZXJtIG5vbi1MNFMgaXMgbm90IGEgZ29vZCBjaG9pY2UNCj4gPiA+Zm9y
DQo+ID4gPmENCj4gPiA+PiBuYW1lLCBiZWNhdXNlIHRoZSB3b3JkcyBpdCBpcyBtYWRlIGZyb20g
YWxyZWFkeSBnaXZlIGl0IGEgbWVhbmluZyBvZg0KPiA+ID5pdHMNCj4gPiA+b3duDQo+ID4gPj4g
dGhhdCBjb25mbGljdHMgd2l0aCB0aGUgZGVmaW5pdGlvbiB5b3Ugd2FudCBpdCB0byBoYXZlIGlu
IGNlcnRhaW4NCj4gPiA+Y29udGV4dHMuDQo+ID4gPj4NCj4gPiA+PiBGb3IgZXhhbXBsZSwgaWYg
eW91IGRpZCBkZWZpbmUgdGhlIG5hbWUgIm5vbi1pUGhvbmUiIHRvIG1lYW4gcGhvbmVzDQo+ID4g
PnN1Y2gNCj4gPiA+YXMNCj4gPiA+PiBBbmRyb2lkLCBXaW5kb3dzLCBldGMsIHRoZW4geW91IHdv
dWxkIGV4cGVjdCB0aGUgcGhyYXNlICJub24taVBob25lDQo+ID4gPmtub2NrLQ0KPiA+ID4+IG9m
ZiBwcm9kdWN0cyIgdG8gbWVhbiAiZmFrZSBBbmRyb2lkIGFuZCBXaW5kb3dzIHBob25lcyIuIEhv
d2V2ZXIgdGhlDQo+ID4gPj4gY29uc3RpdHVlbnQgZWxlbWVudHMgIm5vbiIgYW5kICJpUGhvbmUi
IGFscmVhZHkgaGF2ZSBhIG1lYW5pbmcgb2YNCj4gPiA+dGhlaXINCj4gPiA+b3duLA0KPiA+ID4+
IHNvIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgcGhyYXNlLCBpdCBtZWFucyAiZmFrZSBpUGhvbmVz
Iiwgd2hpY2ggaXMNCj4gPiA+dGhlDQo+ID4gPm9wcG9zaXRlDQo+ID4gPj4gb2Ygd2hhdCB5b3Ug
d2FudGVkLg0KPiA+ID4+DQo+ID4gPj4gVGhlIHRlcm0gQ2xhc3NpYyBmb3IgdGhlIG5vbi1MNFMg
c2VydmljZSwgaXRzIHF1ZXVlLCBpdHMgdHJhZmZpYywgaXRzDQo+ID4gPmNvbmdlc3Rpb24NCj4g
PiA+PiBjb250cm9sLCBldGMuIGlzIGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24g
b2YgdGhlIGRyYWZ0cywgc28NCj4gPiA+SQ0KPiA+ID50aGluayBpdCdzDQo+ID4gPj4gYmVzdCB0
byBsaXZlIHdpdGggdGhpcyAtIGl0J3Mgbm90IGEgc2lnbmlmaWNhbnQgcHJvYmxlbS4gSW5kZWVk
LCBpdA0KPiA+ID5oYXMNCj4gPiA+YmVjb21lIHdpZGVseQ0KPiA+ID4+IHVzZWQgYW5kIHdpZGVs
eSB1bmRlcnN0b29kIHNpbmNlIDIwMTUsIGFuZCBjaGFuZ2luZyBpdCB0byBub24tTDRTIG5vdw0K
PiA+ID53b3VsZA0KPiA+ID4+IGNhdXNlIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbi4NCj4gPiA+Pg0K
PiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBCb2INCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+
PiBPbiAwNC8xMS8yMDE5IDE5OjIxLCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6DQo+ID4gPj4gPg0K
PiA+ID4+ID4gSSBhZ3JlZS4gP25vbi1MNFM/IG1heSBiZSBldmVuIGJldHRlci4NCj4gPiA+PiA+
DQo+ID4gPj4gPiBNaWNoYWVsDQo+ID4gPj4gPg0KPiA+ID4+ID4gKlZvbjogKlJvZG5leSBXLiBH
cmltZXMgPG1haWx0bzo0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldD4NCj4gPiA+PiA+ICpHZXNlbmRl
dDogKk1vbnRhZywgNC4gTm92ZW1iZXIgMjAxOSAyMDoxNw0KPiA+ID4+ID4gKkFuOiAqU2NoYXJm
LCBNaWNoYWVsIDxtYWlsdG86TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPg0KPiA+ID4+
ID4gKkNjOiAqQm9iIEJyaXNjb2UgPG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PjsgV2VzbGV5
IEVkZHkNCj4gPiA+PiA+IDxtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbT47IHRzdndnQGlldGYu
b3JnDQo+ID4gPjxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+Ow0KPiA+ID4+ID4gdGNwbUBpZXRmLm9y
ZyA8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQo+ID4gPj4gPiAqQmV0cmVmZjogKlJlOiBbdGNwbV0g
W3RzdndnXSBMNFMgc3RhdHVzIHRyYWNraW5nDQo+ID4gPj4gPg0KPiA+ID4+ID4gPiBZb3UgY2Fu
IGUuZy4gdXNlID9ub24tTDRTLWVuYWJsZWQgVENQPy4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4g
VGVybWlub2xvZ3kgZG9lcyBtYXR0ZXIgdG8gbWUgZ2l2ZW4gdGhhdCBJIHN0cm9uZ2x5IGRpc2Fn
cmVlIHRvDQo+ID4gPmFueQ0KPiA+ID4+ID4gdXNlIG9mID9tYXJrZXRpbmcgbGFuZ3VhZ2U/IHdo
ZW4gaXQgY29tZXMgdG8gVENQLg0KPiA+ID4+ID4NCj4gPiA+PiA+IE15IGNvbmNlcm4gaGVyZSBv
ZiB1c2Ugb2YgdGVybXMgbGlrZSwgbGVnYWN5LCBjbGFzc2ljLCBuZXcsIG9sZCBpcw0KPiA+ID4+
ID4gdGhhdCB0aGV5IGFyZSBwcmV0dHkgbXVjaCBhbGwgb2YgdGhlIHJlbGF0aXZlIGZyb20gYW5k
IHRodXMNCj4gPiA+YW1iaWd1b3VzDQo+ID4gPj4gPiBvdmVyIHRpbWUuDQo+ID4gPj4gPg0KPiA+
ID4+ID4gbmV3UmVubyBpcyBuZXcgb25seSByZWxhdGl2ZSB0byBSZW5vLCB0aGF0IGlzIGZhaXJs
eSBjbGVhciwgYnV0IGlmDQo+ID4gPkkNCj4gPiA+PiA+IHNhaWQgbmV3VENQIG9yIG9sZFRDUCB3
aXRoIHdoYXQgZnJhbWUgc2hvdWxkIHRoZSByZWZlcmVuY2UgYmUNCj4gPiA+PiA+IGV2YWx1YXRl
ZC4NCj4gPiA+PiA+DQo+ID4gPj4gPiBJIGJlbGlldmUgaW4gdGhlIGNhc2Ugb2YgTDRTIHRoZSB0
aW1lIGludmFyaWFudCB0ZXJtIHdvdWxkIGJlLCBhcw0KPiA+ID4+ID4gTWljaGFlbCBzdWdnZXN0
cyBhYm92ZSwgIm5vbi1MNFMiLj8/IE5vdGUgdGhhdCBlbmFibGVkIGZvciBtZSBpcyBhDQo+ID4g
Pj4gPiBub2lzZSB3b3JkIGluIHRoaXMgY29udGV4dCwgYW5kIFRDUCBtYXkgb3IgbWF5IG5vdCBi
ZSBuZWVkZWQNCj4gPiA+ZGVwZW5kaW5nDQo+ID4gPj4gPiBvbiBjb250ZXh0LCBidXQgZm9yIGxp
dGVyYWwgcmVwbGFjZW1lbnQgb2YgTGVnYWN5IG9yIENsYXNzaWMNCj4gPiA+Im5vbi1MNFMiDQo+
ID4gPj4gPiBpcyBpbnZhcmlhbnQgb3ZlciB0aW1lLg0KPiA+ID4+ID4NCj4gPiA+PiA+IFJvZA0K
PiA+ID4+ID4NCj4gPiA+PiA+ID4gTWljaGFlbA0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+
ID4+ID4gPiBWb246IEJvYiBCcmlzY29lPG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Pg0KPiA+
ID4+ID4gPiBHZXNlbmRldDogTW9udGFnLCA0LiBOb3ZlbWJlciAyMDE5IDE5OjA5DQo+ID4gPj4g
PiA+IEFuOiBTY2hhcmYsIE1pY2hhZWw8bWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdl
bi5kZT47DQo+ID4gPldlc2xleQ0KPiA+ID4+ID4gRWRkeTxtYWlsdG86d2VzQG10aS1zeXN0ZW1z
LmNvbT47DQo+ID4gPj4gPiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQo+
ID4gPj4gPiA+IENjOiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KPiA+ID4+
ID4gPiBCZXRyZWZmOiBSZTogW3RjcG1dIFt0c3Z3Z10gTDRTIHN0YXR1cyB0cmFja2luZw0KPiA+
ID4+ID4gPg0KPiA+ID4+ID4gPiBNaWNoYWVsLA0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPiBQcmV2
aW91c2x5LCBJIGhhdmUgYmVlbiB0b2xkIG5vdCB0byB1c2UgdGhlIHRlcm0gc3RhbmRhcmQgZm9y
DQo+ID4gPlJGQ3MNCj4gPiA+PiA+IHRoYXQgYXJlIG5vdCBzdGFuZGFyZHMuIFJGQzU2ODEgaXMg
J29ubHknIGEgZHJhZnQgc3RhbmRhcmQuIFRoaXMgaXMNCj4gPiA+PiA+IHdoeSwgaW4gdGhlIElF
VEYgYXQgbGVhc3QsIEkgYXZvaWQgdXNpbmcgdGhlIHRlcm0gInN0YW5kYXJkIFRDUA0KPiA+ID4+
ID4gY29uZ2VzdGlvbiBjb250cm9sIi4gSSBnZW5lcmFsbHkgY2FsbCBpdCBSZW5vIHdoZW4gcmVm
ZXJyaW5nIHRvIHRoZQ0KPiA+ID4+ID4gY29uZ2VzdGlvbiBjb250cm9sLg0KPiA+ID4+ID4gPg0K
PiA+ID4+ID4gPiBJIGhhdmUgbmV2ZXIsIHRvIG15IGtub3dsZWRnZSwgdXNlZCB0aGUgdGVybSBj
bGFzc2ljIFRDUCwgb3INCj4gPiA+Y2xhc3NpYw0KPiA+ID4+ID4gVENQIGNvbmdlc3Rpb24gY29u
dHJvbC4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gQW5kIEkgcmFyZWx5IHVzZSB0aGUgdGVybSBs
ZWdhY3ksIGFuZCBpZiBJIGRvIEknbSBoYXBweSB0byBoYXZlDQo+ID4gPj4gPiBhbHRlcm5hdGl2
ZXMgc3VnZ2VzdGVkLg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPiBJJ3ZlIGNoZWNrZWQgdGhlIEw0
UyBkcmFmdHMsIGFuZCB0aGVyZSBpcyBvbmUgcGhyYXNlIHRoYXQgSSBzaGFsbA0KPiA+ID4+ID4g
bGVhdmUgaW4gZWNuLWw0cy1pZDogInRoZSB0cmFkaXRpb25hbCBUQ1AgUmVubyBhZGRpdGl2ZSBp
bmNyZWFzZSIsDQo+ID4gPj4gPiBiZWNhdXNlIHRoaXMgaXMgY29ycmVjdGx5IHVzZWQgdG8gbWVh
biB0aGUgdHJhZGl0aW9uYWwgaW5jcmVhc2UgKGluDQo+ID4gPj4gPiBudW1lcm91cyBBSU1EIEND
cyksIG5vdCB0cmFkaXRpb25hbCBUQ1AuIFRoZXJlIHdhcyBvbmUgb3RoZXINCj4gPiA+PiA+IG9j
Y3VycmVuY2Ugb2YgInRyYWRpdGlvbmFsIFRDUCBzZW5kZXJzIiBpbiBhIHdob2xlIHBhcmEgaW4g
YW4NCj4gPiA+YXBwZW5kaXgNCj4gPiA+PiA+IHRoYXQgaGFzIGp1c3QgYmVlbiBkZWxldGVkIGFu
eXdheS4gQW5kIGluIGFxbS1kdWFscS1jb3VwbGVkIHRoZXJlDQo+ID4gPndhcw0KPiA+ID4+ID4g
b25lICJsZWdhY3kgVENQIGZsb3dzIiAoY2hhbmdlZCB0byAiQ2xhc3NpYyB0cmFmZmljIiBub3cg
aW4gbXkNCj4gPiA+bG9jYWwNCj4gPiA+PiA+IGNvcHksIHVzaW5nIHRoZSBkZWZpbmVkIHRlcm0g
aW4gYWxsIHRoZSBMNFMgZHJhZnRzKS4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gbDRzLWFyY2gg
aXMgZ2V0dGluZyBhIGNvbXBsZXRlIG1ha2Utb3ZlciBmb3IgdGVybWlub2xvZ3ksIHNvIEkNCj4g
PiA+d2lsbA0KPiA+ID4+ID4gY2hlY2sgdGhhdCBuZXh0Lg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4g
PiBpbmxpbmUuLi4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gT24gMjMvMDgv
MjAxOSAxNTowMSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4g
PiBIaSBXZXMsDQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+
IEk/ZCBsaWtlIHRvIGFkZCBhIHNtYWxsZXIgaXRlbSB0aGF0IGlzIG1vc3RseSBlZGl0b3JpYWwg
YW5kIGNhbg0KPiA+ID4+ID4gaG9wZWZ1bGx5IGJlIHNvcnRlZCBqdXN0IG91dCBieSByZS13b3Jk
aW5nLCBhbGJlaXQgaXQgbWF5IHJlcXVpcmUgYQ0KPiA+ID4+ID4gY2FyZWZ1bCBhbmFseXNpcyBv
ZiBhbGwgZG9jdW1lbnRzLg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+
ID4+ID4gPiBBcyBhbHJlYWR5IG5vdGVkIGluDQo+ID4gPj4gPiBodHRwczovL21haWxhcmNoaXZl
LmlldGYub3JnL2FyY2gvbXNnL3RzdndnL3paa1laS0YtDQo+ID4gPj4gaER2V08zSTVNdWR3cE5r
S3lIDQo+ID4gPj4gPg0KPiA+ID5ZPGh0dHBzOi8vbWFpbGFyY2hpdmUuLmlldGYub3JnL2FyY2gv
bXNnL3RzdndnL3paa1laS0YtDQo+IGhEdldPM0k1TXVkd3BOaw0KPiA+ID4+ID4gS3lIWT4gLCBJ
IG9iamVjdCB0byB0aGUgdGVybXMgP3RyYWRpdGlvbmFsIFRDUD8gYW5kIGFsc28gP2NsYXNzaWMN
Cj4gPiA+VENQPw0KPiA+ID4+ID4gb3IgP2xlZ2FjeT8gVENQIHdoZW4gcmVmZXJyaW5nIHRvIGEg
VENQIGltcGxlbWVudGF0aW9uIGFjY29yZGluZyB0bw0KPiA+ID4+ID4gSUVURiBzdGFuZGFyZHMt
dHJhY2sgUkZDcy4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+
ID4gVG8gbWUgYXMgYSBub24tbmF0aXZlIG5hdGl2ZSBzcGVha2VyLCBhbGwgdGhlc2UgdGVybXMg
aGF2ZSBhDQo+ID4gPj4gPiBuZWdhdGl2ZSBjb25ub3RhdGlvbi4gSSBhbHNvIHRoaW5rIHRoaXMg
bGFuZ3VhZ2UgaXMgdHlwaWNhbCB0bw0KPiA+ID4+ID4gbWFya2V0aW5nIG1hdGVyaWFsLg0KPiA+
ID4+ID4gPg0KPiA+ID4+ID4gPiBZb3UncmUgZW50aXRsZWQgdG8geW91ciBvcGluaW9uIGJ1dCwg
YXMgYSBuYXRpdmUgc3BlYWtlciwgSSBkb24ndA0KPiA+ID4+ID4gdGhpbmsgJ2NsYXNzaWMnIG9y
ICd0cmFkaXRpb25hbCcgYXJlIHBhcnRpY3VsYXJseSBwZWpvcmF0aXZlLCB0aG8NCj4gPiA+dGhl
eQ0KPiA+ID4+ID4gY2FuIGJlIHdoZW4gdXNlZCBpbiBhIGNvbnRleHQgdGhhdCBpbnRlbmRzIHRo
ZW0gdG8gYmUuIFRoZXkgYWxzbw0KPiA+ID5tZWFuDQo+ID4gPj4gPiAic3Rvb2QgdGhlIHRlc3Qg
b2YgdGltZSIuIEkgZmluZCAnbGVnYWN5JyBoYXMgYSBjb25ub3RhdGlvbiBvZg0KPiA+ID4+ID4g
bWFya2V0aW5nLXNwZWFrLCBidXQgaXQncyBub3QgdGhhdCBiYWQuDQo+ID4gPj4gPiA+DQo+ID4g
Pj4gPiA+IFRoaXMgaXMgYW4gZW5kdXJpbmcgcHJvYmxlbSB3aGVuIHRyeWluZyB0byBpbXByb3Zl
IG9uIHRoZSBnb29kDQo+ID4gPndvcmsNCj4gPiA+PiA+IHRoYXQgb3RoZXIgcGVvcGxlIGhhdmUg
ZG9uZSBiZWZvcmUgeW91ICh3aGljaCBpcyB0aGUgY29udGV4dCBvZg0KPiA+ID4+ID4gZXZlcnl0
aGluZyB3ZSBhcmUgZG9pbmcpLiBXZSBuZWVkIGEgd29yZCB0aGF0IGRpc3Rpbmd1aXNoZXMgdGhl
IG9sZA0KPiA+ID4+ID4gZnJvbSB0aGUgbmV3LCBidXQgd2UgZG9uJ3Qgd2FudCB0byBjb21wbGV0
ZWx5IHRyYXNoIHRoZSB0aGluZyB0aGF0DQo+ID4gPmhhcw0KPiA+ID4+ID4gYWxyZWFkeSBiZWVu
IHN1Y2Nlc3NmdWwsIGJ1dCBoYWQgaXRzIGRheS4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gTm9u
ZXRoZWxlc3MsIGl0IGlzIGFsc28gaW1wb3J0YW50IG5vdCB0byBiZSB0b28gcHJlY2lvdXMgYWJv
dXQNCj4gPiA+cGFzdA0KPiA+ID4+ID4gd29yay4gV2UgYWxsIHJlY29nbml6ZSB0aGF0IFJlbm8g
VENQIGlzIHVuc2NhbGFibGUgYW5kIGhhcw0KPiA+ID5wcm9ibGVtcy4NCj4gPiA+PiA+IElNTywg
aXQgaXMgT0sgdG8gZGVzY3JpYmUgdGVjaG5vbG9naWVzIHRoYXQgaGF2ZSBoYWQgdGhlaXIgdGlt
ZQ0KPiA+ID53aXRoDQo+ID4gPj4gPiBuZWdhdGl2ZSBjb25ub3RhdGlvbnMuIEluZGVlZCwgeW91
IGhhdmUgYmVlbiBhbiBhdXRob3IgKHdpdGggbWUpIG9mDQo+ID4gPmFuDQo+ID4gPj4gPiBSRkMg
b24gb3BlbiBpc3N1ZXMgaW4gY29uZ2VzdGlvbiBjb250cm9sLg0KPiA+ID4+ID4gPg0KPiA+ID4+
ID4gPiBJIG5vdGljZSB5b3UgaGF2ZW4ndCBzdWdnZXN0ZWQgYW4gYWx0ZXJuYXRpdmUgdGVybSBm
b3IgInRoZQ0KPiA+ID50aGluZyhzKQ0KPiA+ID4+ID4gd2UgYXJlIHRyeWluZyB0byBpbXByb3Zl
IG9uIi4gTm90IHN1cnByaXNpbmcsIGJlY2F1c2UgaXQncw0KPiA+ID5kaWZmaWN1bHQuDQo+ID4g
Pj4gPiA+DQo+ID4gPj4gPiA+IFdoZW4gd2UgKHRoZSBMNFMgZGV2ZWxvcGVycykgd2VyZSBmaXJz
dCBsb29raW5nIGZvciBhIHRlcm0gZm9yDQo+ID4gPnRoZQ0KPiA+ID4+ID4gbm9uLUw0UyBxdWV1
ZSBhbmQgdGhlIG5vbi1MNFMgc2VydmljZSwgd2UgZGlkbid0IHdhbnQgdG8gdXNlDQo+ID4gPids
ZWdhY3knDQo+ID4gPj4gPiBmb3IgdGhlIGFib3ZlIHJlYXNvbnMsIGJ1dCB3ZSBkaWQgd2FudCB0
byBpbXBseSBwcmUtZXhpc3RpbmcsIHNvIHdlDQo+ID4gPj4gPiBkZWNpZGVkIG9uICdjbGFzc2lj
Jywgd2hpY2ggd2UgYWxsIGZlbHQgaGFkIGEgZ2VuZXJhbGx5IG5ldXRyYWwNCj4gPiA+PiA+IGNv
bm5vdGF0aW9uLCBidXQgc2FpZCB3aGF0IHdlIG1lYW50Lg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4g
PiBGaW5hbGx5LCBJIGRvIG5vdCB3YW50IHRoaXMgaXNzdWUgdG8gdGFrZSB1cCBhbnkgdGltZSB0
aGF0IHdvdWxkDQo+ID4gPj4gPiBkZXRyYWN0IGZyb20gdGVjaG5pY2FsIGlzc3Vlcy4NCj4gPiA+
PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gQm9iDQo+ID4gPj4gPiA+
DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+IE15IHByZWZl
cmVkIHRlcm0gd2hlbiByZWZlcnJpbmcgdG8gVENQIGFjY29yZGluZyB0bw0KPiA+ID5zdGFuZGFy
ZHMtdHJhY2sNCj4gPiA+PiA+IHNwZWNpZmljYXRpb24gaXMgP3N0YW5kYXJkIFRDUD8uIEkgd291
bGQgYWxzbyBiZSBmaW5lIHdpdGggb3RoZXINCj4gPiA+dGVybXMNCj4gPiA+PiA+IGFzIGxvbmcg
YXMgdGhleSBhcmUgbmV1dHJhbCBhbmQgbWFrZSBjbGVhciB0aGF0IGV4cGVyaW1lbnRzIGRvIG5v
dA0KPiA+ID4+ID4gcmVwbGFjZSwgZGVwcmVjYXRlLCBvciBvdXRwZXJmb3JtIHN0YW5kYXJkcy4N
Cj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gU2ltaWxhcmx5
LCBJIHRoaW5rIHRoYXQgdGVybSBzdWNoIGFzID9jbGFzc2ljPyBpcyBub3QgYXBwcm9wcmlhdGUN
Cj4gPiA+PiA+IGZvciB0aGUgVENQIHN0YW5kYXJkIGNvbmdlc3Rpb24gY29udHJvbCAoP1Jlbm8/
KS4gQXMgb2YgdG9kYXksIHRoaXMNCj4gPiA+aXMNCj4gPiA+PiA+IHRoZSBUQ1AgY29uZ2VzdGlv
biBjb250cm9sIGFsZ29yaXRobSBvbiBzdGFuZGFyZHMgdHJhY2sgdGhhdCBoYXMNCj4gPiA+SUVU
Rg0KPiA+ID4+ID4gY29uc2Vuc3VzLiBUaGUgdGVybSBpbiB0aGUgVENQTSBjaGFydGVyIGlzID9U
Q1Agc3RhbmRhcmQgY29uZ2VzdGlvbg0KPiA+ID4+ID4gY29udHJvbD8uIEkgYWxzbyB0aGluayB0
aGF0IHRlcm1zIHN1Y2ggYXMgP1Jlbm8tY29tcGF0aWJsZT8gb3IgdGhlDQo+ID4gPj4gPiBsaWtl
IHdvdWxkIGJlIG5ldXRyYWwuDQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+
ID4gPj4gPiA+IE5vdGUgdGhhdCBJIGRvIG5vdCBvYmplY3QgdG8gdGhlIHRlcm1zID9jbGFzc2lj
IEVDTj8sID9sZWdhY3kNCj4gPiA+RUNOPywNCj4gPiA+PiA+ID9sZWdhY3kgQVFNPyBvciB0aGUg
bGlrZSwgaS5lLiwgaWYgdGhlIGNvbnRleHQgaXMgRUNOIGFuZCBub3QNCj4gPiA+PiA+IHNwZWNp
ZmljYWxseSBUQ1Agb3IgdGhlIFRDUCBjb25nZXN0aW9uIGNvbnRyb2wuIEkgYmVsaWV2ZSBpdCBp
cyB1cA0KPiA+ID50bw0KPiA+ID4+ID4gdGhlIFRTVldHIGRvIGRlY2lkZSBpZiB0aGlzIHRlcm0g
c2hhbGwgYmUgdXNlZCBmb3IgY29tcGxpYW5jZSB0bw0KPiA+ID5SRkMNCj4gPiA+PiA+IDMxNjgu
IEkgaGF2ZSBubyBzdHJvbmcgb3BpbmlvbiBvbiB0aGF0LiBBcyBmYXIgYXMgSSBjYW4gc2VlLCBt
b3N0DQo+ID4gPnVzZQ0KPiA+ID4+ID4gb2YgdGhlIHRlcm0gP2NsYXNzaWM/IGlzIGluIHRoaXMg
Y29udGV4dCBhbmQgSSBkb24/dCBhc2sgZm9yDQo+ID4gPmNoYW5nZXMNCj4gPiA+PiA+IGluIHRo
b3NlIGNhc2VzLg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4g
PiBTb21lIHVzZSBvZiB0aGUgdGVybSA/Q2xhc3NpYyBTZXJ2aWNlPyBtYXkgYWxzbyByZXF1aXJl
IGNhcmVmdWwNCj4gPiA+PiA+IHJldmlldyB0byBjbGVhcmx5IHNlcGFyYXRlIGl0IGZyb20gVENQ
IFN0YW5kYXJkIGJlaGF2aW9yLg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0K
PiA+ID4+ID4gPiBOb3RlIHRoYXQgc29tZSB1c2Ugb2YgdGhlIHRlcm0gP0NsYXNzaWMgVENQPyB3
b3VsZCBwcm9iYWJseSBhbHNvDQo+ID4gPj4gPiBhcHBseSB0byA/Q2xhc3NpYyBRVUlDPyBvbmNl
IHRoZSBRVUlDIHN0YW5kYXJkIGlzIGZpbmlzaGVkLiBUbyBtZQ0KPiA+ID5hcyBhDQo+ID4gPj4g
PiBub24tbmF0aXZlIHNwZWFrZXIsIGl0IHdvdWxkIGJlIHJlYWxseSBzdHJhbmdlIHRvIHVzZSB0
aGUgdGVybQ0KPiA+ID4+ID4gP2NsYXNzaWM/IGluIHRoZSBjb250ZXh0IG9mIGEgYnJhbmQtbmV3
IHRyYW5zcG9ydCBwcm90b2NvbC4gSU1ITyBpbg0KPiA+ID4+ID4gdGhhdCBjYXNlIHRoZSB0ZXJt
ID9jbGFzc2ljPyB3b3VsZCBiZSBldmVuIG1vcmUgY29uZnVzaW5nLg0KPiA+ID4+ID4gPg0KPiA+
ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPiBJIGFsc28gYWRkIHRoZSBUQ1BNIGxpc3Qg
aW4gQ0MgdG8gZW5zdXJlIGNvbnNpc3RlbmN5Lg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPg0KPiA+
ID4+ID4gPg0KPiA+ID4+ID4gPiBUaGFua3MNCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4NCj4gPiA+
PiA+ID4NCj4gPiA+PiA+ID4gTWljaGFlbCAod2l0aCBubyBoYXQpDQo+ID4gPj4gPiA+DQo+ID4g
Pj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+IFZv
bjogV2VzbGV5IEVkZHk8bWFpbHRvOndlc0BtdGktc3lzdGVtcy5jb20+DQo+ID4gPj4gPiA+IEdl
c2VuZGV0OiBTb25udGFnLCAxMS4gQXVndXN0IDIwMTkgMDc6MDgNCj4gPiA+PiA+ID4gQW46IHRz
dndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NCj4gPiA+PiA+ID4gQmV0cmVmZjog
W3RzdndnXSBMNFMgc3RhdHVzIHRyYWNraW5nDQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4g
Pj4gPiA+DQo+ID4gPj4gPiA+IEkgY3JlYXRlZCB0aWNrZXRzIGluIHRoZSBUU1ZXRyAidHJhYyIg
dG9vbCBpbiBvcmRlciB0byBoZWxwIGtlZXANCj4gPiA+PiA+ID4gdHJhY2sgb2YgdGhlIGluZGl2
aWR1YWwgdGhpbmdzIHRoYXQgbG9vayBsaWtlIHRoZXkgc2hvdWxkIGJlDQo+ID4gPj4gPiA+IGFk
ZHJlc3NlZCBpbiBwcm9ncmVzc2luZyBMNFMgZG9jdW1lbnQgc2V0Og0KPiA+ID4+ID4gPg0KPiA+
ID4+ID4gPg0KPiA+ID5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy90c3Z3Zy9yZXBvcnQvMT9z
b3J0PXRpY2tldCZhc2M9MSZwYWdlPTENCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gSSdsbCB0cnkg
dG8gdXBkYXRlIHRoZXNlIGJhc2VkIG9uIHRoZSBvbmdvaW5nIGRpc2N1c3Npb25zLA0KPiA+ID51
cGRhdGVzLA0KPiA+ID4+ID4gPiBldGMuLCBidXQgaXQgd2lsbCBtYWtlIGl0IHZlcnkgZWFzeSBp
ZiB5b3UgaGFwcGVuIHRvIG1lbnRpb24gdGhlDQo+ID4gPj4gPiA+IHRpY2tldCBudW1iZXJzIG9y
IHNvbWUga2V5IHdvcmRzIGluIHRocmVhZHMgYW5kIG1lc3NhZ2VzLCB3aGVuDQo+ID4gPj4gc2ln
bmlmaWNhbnQuDQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+
DQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gPj4gPiA+IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gPj4gPiA+
IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQo+ID4gPj4gPiA+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+ID4+ID4gPg0KPiA+ID4+ID4g
Pg0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPiAtLQ0KPiA+ID4+ID4gPg0KPiA+ID4+DQo+ID4NCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiA+ID4+ID4gPiBCb2IgQnJpc2NvZQ0KPiA+ID4+ID4gPg0KPiA+ID5odHRwczov
L3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTllM2NmNzcwLWMyZThmYjgxLTllM2NiN2Vi
LTg2NA0KPiA+ID4+ID4gPiA2ODViMjA4NWMtNGJhNmExOTYwYzRmM2U3YSZxPTEmZT1iZjQ5YzBm
MC0zODBiLTQyZDQtOTNhMi0NCj4gPiA+PiA5ZWJlZGZmODAyZQ0KPiA+ID4+ID4gPiAwJnU9aHR0
cCUzQSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGDQo+ID4gPj4gPg0KPiA+ID4+ID4gPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+ID4gPiB0Y3Bt
IG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gPiB0Y3BtQGlldGYub3JnDQo+ID4gPj4gPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+ID4+ID4NCj4gPiA+PiA+
IC0tDQo+ID4gPj4gPiBSb2QgR3JpbWVzIHJncmltZXNAZnJlZWJzZC5vcmcNCj4gPiA+Pg0KPiA+
ID4+IC0tDQo+ID4gPj4NCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gQm9iIEJyaXNjb2UNCj4gPiA+
aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az04NjEyNDFhOC0NCj4gPiA+PiBk
YWM2NGQ1OS04NjEyMDEzMy04NjQ2ODViMjA4NWMtDQo+IDE2MTIwYTI3YWI0YTc1MWEmcT0xJmU9
YmY0OWMwZjAtDQo+ID4gPj4gMzgwYi00MmQ0LTkzYTItOWViZWRmZjgwMmUwJnU9aHR0cCUzQSUy
RiUyRmJvYmJyaXNjb2UubmV0JTJGDQo+ID4gPj4NCj4gPiA+PiAtLS0tLS0tLS0tLS0tLSBuZXh0
IHBhcnQgLS0tLS0tLS0tLS0tLS0gQW4gSFRNTCBhdHRhY2htZW50IHdhcw0KPiA+ID4+IHNjcnVi
YmVkLi4uDQo+ID4gPj4gVVJMOg0KPiA+ID4+DQo+ID4gPjxodHRwczovL21haWxhcmNoaXZlLmll
dGYub3JnL2FyY2gvYnJvd3NlL3RjcG0vYXR0YWNobWVudHMvMjAxOTExMDYvZGU3DQo+ID4gPjk3
DQo+ID4gPj4gZmQxL2F0dGFjaG1lbnQuaHRtbD4NCj4gPiA+Pg0KPiA+ID4+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4+DQo+ID4gPj4gU3ViamVjdDogRGlnZXN0IEZvb3Rl
cg0KPiA+ID4+DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPiA+PiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+ID4+IHRjcG1AaWV0Zi5vcmcN
Cj4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gPiA+
Pg0KPiA+ID4+DQo+ID4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPj4N
Cj4gPiA+PiBFbmQgb2YgdGNwbSBEaWdlc3QsIFZvbCAxODcsIElzc3VlIDE1DQo+ID4gPj4gKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+DQo+ID4gLS0NCj4gPiBTZW50
IGZyb20gbXkgQW5kcm9pZCBkZXZpY2Ugd2l0aCBLLTkgTWFpbC4gUGxlYXNlIGV4Y3VzZSBteSBi
cmV2aXR5Lg0K


From nobody Fri Nov  8 12:49: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 A4C6112090D; Fri,  8 Nov 2019 12:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=aUWeQflh; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=cE8ZjsGt
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 xN6Nm-4xMPMc; Fri,  8 Nov 2019 12:48:57 -0800 (PST)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 770F6120908; Fri,  8 Nov 2019 12:48:57 -0800 (PST)
Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA8Kl0wF031573; Fri, 8 Nov 2019 15:48:48 -0500
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=XG+zSaq0UJKcv8J2Uc4n6Q9ymhn6lN0oTp6WL2QCEuU=; b=aUWeQflhQ23CHf8wp1OfRvdUqDK6szLXTewpsgSGiDCp+8g1RE9OyxWycu5xCKofX5ba eDceJEcxVA80URd+NVHrxqoBuUvmm2le3SgEC1HAZDkCgCoVwthaBGj9nkH74Z4vBMOY nKJ+HxX4VHaOa2brxipcQg9WPIHLxNxeGnTpqhLxPEK+fKeosJERMLURYfemGPaICt6k QrvNP4vgkhuHwczyiF+5QYJrrtLEdol7SHgbpdj9drBGwoMuG1X0Qmwd/UFbn51dhyZ5 VMUADzopmax84KpDFnbSvdki7BkHya50QjEOPUeBKePg5MQeSSRa8yCwcKeRaL/5JU4A qw== 
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2w41uwvc4t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Nov 2019 15:48:47 -0500
Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA8Kh7Vf020077; Fri, 8 Nov 2019 15:48:47 -0500
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2052.outbound.protection.outlook.com [104.47.41.52]) by mx0b-00154901.pphosted.com with ESMTP id 2w41wngn61-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 15:48:47 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a09Oq4fAKKMNYJiooBeW+yDLPNxAvG/o06qctrvNqEQ76+kiYMqWRSrN4xLwM90d2m5UyKuhh8H613DtGPU2SuT8jsaR1lU0D6a1v1dpErXHEiHQ1mrb9oo7PezjTwfC39ufM94bRhje8R7J1Tdt+6CAHLUi8TU+jDYjpbXZptlB4bONMgvUuWeG5RpDRn8b4dRl3u5gKxIkDHKXNU4N+1kEeCjGqFNO31d3DGOeRpA8foHv1QH/JnnuSYsmADHY8amNCxcKGZp7UchtDCKjN7XLZjwx18CeqzOJHPs/ak0crOCfAApvvLssqx/9nQPWPvR29isRZhl+6AInSElMpw==
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=XG+zSaq0UJKcv8J2Uc4n6Q9ymhn6lN0oTp6WL2QCEuU=; b=Ke4lcaCU+g2nqRPuZCFdrun9Ck1BRXz4V3uZXCBuFkvT/zYsxGtjP37IDevuylA6TO11PFP+oml9dfxUYst/jejKhppaTqxnRWu6lZ6oUIPwftrbRFDNtpu2zAu9Tcj4zcAagFltagMJDWr6tQLtSuOXdjNVZO5zqP7hiL/FxfB2qsnOuvLXwIVryEgDdTgolBU3r4ZdpsDoMh0ezC5n5G4AzPAix3W++U6J6/Dp8E5elCJRkkH8MsBKrjXuG2/nC9G49DJi/hpopMq5qOM8g3mlrXxCUB6uoQHa9mk63DqOtUCuyle3ywDLnmX2VpXk+Ot5ZJXs3xJImioSE45zTA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com;  s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XG+zSaq0UJKcv8J2Uc4n6Q9ymhn6lN0oTp6WL2QCEuU=; b=cE8ZjsGtIBBh8unbuNzPfD7enXaxGWcd1Roqtaf8XzgVARojZlNUUAB6qHgxMGyQQNkks5AvJZJ4cGu+oEbjczcXLoav10Rg7p/bLyrfGfcJHw5FFLIxenTp3G57aXD+TPNjlGurKaZdG98SAnFyop3LaDIzSYAqmoRkOGrwIoQ=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB2445.namprd19.prod.outlook.com (20.179.83.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Fri, 8 Nov 2019 20:48:45 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2430.023; Fri, 8 Nov 2019 20:48:45 +0000
From: "Black, David" 
To: "Scharf, Michael" 
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] [tcpm]  L4S status tracking
Thread-Index: AQHVkzsNys8itt0WdkerjoDylubqfqd7X/CAgAACeQCAAAFigIAB5lwAgAB1iQCAALwYgIAABesAgAAP1ICAAM3XgIACZC0Q
Date: Fri, 8 Nov 2019 20:48:45 +0000
Message-ID: 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@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-11-08T20:48:42.9589790Z; 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: [168.159.213.213]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 11dc873a-50a8-4ac3-e689-08d7648d0c87
x-ms-traffictypediagnostic: MN2PR19MB2445:
x-microsoft-antispam-prvs: 
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(366004)(396003)(54094003)(199004)(189003)(7502003)(102836004)(186003)(486006)(53546011)(256004)(66476007)(9686003)(3846002)(76116006)(236005)(14454004)(6246003)(66556008)(86362001)(66446008)(6506007)(26005)(6116002)(11346002)(446003)(74316002)(4326008)(476003)(55016002)(54896002)(6306002)(2906002)(52536014)(66946007)(81166006)(81156014)(8936002)(7696005)(25786009)(64756008)(33656002)(7736002)(66066001)(786003)(316002)(99286004)(5660300002)(790700001)(54906003)(6436002)(71190400001)(71200400001)(478600001)(229853002)(66574012)(6916009)(8676002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB2445; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FK25Eub9H4tGj/vwVQpErVBKFscNZU2ICvEmm0sEFeYqvhLf3ToneS6H6z5xiidyhJQuyoiKeHcfRO+MVwmkn2ZbWgtw6CRTx+6WXNVNLnAIMra4AjdReepQSo4iHbLKTzxulocVFpli/9Q+R6TtI1PML+lnbdCONg/hGFfDXvfc5/tpmmoeOM+16JPk4sxyLn3dM752CyiEdLTITPrY2nY9HhRENdNIg1MPtDD3u4qCUoGfLMidrJcJf4JbR79QilVVcVSp/s01oNgL5Czwbe2jvyrobqizB4oVMthClI63psRnU6JAQRiaBt0E9VES3MM2o82ziHRs8jXSG7goJ+RnaocwwsE3kQzglPgRJ5KvvOEv/lQOztqjyvkvJjq90+5AK1rKjdQjcbB7FV3hdrNNUfrX3UhY4IdGHAMYQzeXRTQ1+zaU0cOMjNhxv+Li
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB4045216D5E55A08FA8E04859837B0MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 11dc873a-50a8-4ac3-e689-08d7648d0c87
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 20:48:45.7114 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uWc2ew1357DuD2B44DEUm2yzDBVwUxy6K7eibcDNhQgdwMaU6jNiWIXE78dAJC1F664eE5IbqL4v43/ZB0czfA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2445
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-08_08:2019-11-08,2019-11-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 mlxscore=0 phishscore=0 clxscore=1011 spamscore=0 adultscore=0 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911080198
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 adultscore=0 suspectscore=0 malwarescore=0 impostorscore=0 phishscore=0 clxscore=1015 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911080200
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, 08 Nov 2019 20:49:01 -0000

--_000_MN2PR19MB4045216D5E55A08FA8E04859837B0MN2PR19MB4045namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hopefully not adding confusion, I'm in favor of Michael's suggestion (below=
), as I understand it:
                - L4S has a "Classic" service
                - Protocols and traffic that use the L4S "Classic" service =
are identified/named/described with terms other than "Classic".

For congestion control in particular, I've found myself referring to 1/p an=
d 1/sqrt(p) congestion response behaviors for technical clarity/precision i=
n discussion, but those terms don't exactly roll off the tip of the tongue =
... and assume that the reader is familiar enough with TCP throughput equat=
ions to know what the variable p stands for.

Thanks, --David

From: tsvwg  On Behalf Of Scharf, Michael
Sent: Thursday, November 7, 2019 3:11 AM
To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] [tcpm] L4S status tracking


[EXTERNAL EMAIL]
... and just to show that _my_ concern would be trivial to address by small=
 editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an i=
ncremental migration path so that normal TCP traffic classified in the 'Cla=
ssic' service of L4S will be no worse off" would already work for me.  It j=
ust takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service cla=
ss (and, e.g., "normal" sounds better to me), but in the context of a servi=
ce class, "classic" could actually work for me, if TSVWG really wants that =
name with strong consensus. I don't care how about names for DiffSe^D^D^D^D=
^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whateve=
r else is done in the fast path of a router to implement low latency servic=
e.

I only object to specific terminology such as 'Classic' TCP or 'Classic' co=
ngestion control because I don't think that 'classic' is a proper character=
ization for TCPM standards or TCP/IP stack behavior not aligned with whatev=
er L4S believes the bright future shall be.

Whether such small rewording address fully the concerns from others may be =
a different question.

Michael



From: Wesley Eddy >
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael >; Bob Briscoe >; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.




If Dave+Michael's suggestion of replacing "classic" with "normal" is agreab=
le to others, this seems like a good way forward to me.  It should be easy =
enough to explain in other SDOs that classic and normal mean the same thing=
, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negativ=
e connotations to it.  However, for the sake of working group progress, I t=
hink we just need to pick something that seems the least terrible and agree=
 to move on.)



--_000_MN2PR19MB4045216D5E55A08FA8E04859837B0MN2PR19MB4045namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hopefully not adding c=
onfusion, I’m in favor of Michael’s suggestion (below), as I un=
derstand it:


   &nbs=
p;            - L4S =
has a “Classic” service


   &nbs=
p;            - Prot=
ocols and traffic that use the L4S “Classic” service are identi=
fied/named/described with terms other than “Classic”.


 


For congestion control=
 in particular, I’ve found myself referring to 1/p and 1/sqrt(p) cong=
estion response behaviors for technical clarity/precision in discussion, bu=
t those terms don’t exactly roll off the tip
 of the tongue … and assume that the reader is familiar enough with T=
CP throughput equations to know what the variable p stands for.<=
/span>


 




Thanks, --David




 








From:=
 tsvwg <tsvwg-bounces@ietf.org>
On Behalf Of Scharf, Michael

Sent: Thursday, November 7, 2019 3:11 AM

To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes

Cc: tcpm@ietf.org; tsvwg@ietf.org

Subject: Re: [tsvwg] [tcpm] L4S status tracking





 




[EXTERNAL EMAIL] 




… and just to sh=
ow that _my_ concern would be trivial to address by small editorial =
changes:


 


For the abstract of dr=
aft-ietf-tsvwg-ecn-l4s-id, the wording “It gives an incremental migra=
tion path so that normal TCP traffic classified in the ‘Classic’=
; service of L4S will be no worse off” would already work
 for me.  It just takes a small editorial change to make me happy. Thi=
s can’t be so hard.


 


Personally, I wonder i=
f “classic” is indeed the best name for a service class (and, e=
.g., “normal” sounds better to me), but in the context of a ser=
vice class, “classic” could actually work for me, if TSVWG real=
ly
 wants that name with strong consensus. I don’t care how about names =
for DiffSe^D^D^D^D^D^D traffic classifiers, traffic policers/shapers, AQM s=
chemes, or whatever else is done in the fast path of a router to implement =
low latency service.


 


I only object to speci=
fic terminology such as ‘Classic’ TCP or ‘Classic’ =
congestion control because I don’t think that ‘classic’ i=
s a proper characterization for TCPM standards or TCP/IP stack behavior not=
 aligned
 with whatever L4S believes the bright future shall be.

 


Whether such small rew=
ording address fully the concerns from others may be a different question.<=
o:p>


 


Michael


 


 =
;


 =
;








From=
: Wesley Eddy <<=
a href=3D"mailto:wes@mti-systems.com">wes@mti-systems.com>


Sent: Wednesday, November 6, 2019 8:54 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Bob Briscoe <ietf@bobbriscoe.net>; Rodney W. Grimes <=
;4bone@gndrsh.dnsmgr.net>=


Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 




On 11/6/2019 1:57 PM, Scharf, Mich=
ael wrote:






Bob,


 


From draft-ietf-tsvwg-=
ecn-l4s-id-08: “It gives an incremental migration path so that existi=
ng 'Classic' TCP traffic will be no worse off”


 


You are proposing an e=
xperiment. Not more than that. I will be fine with the term “Classic&=
#8221; for TCP and TCPM-specified congestion control when more than 50% of =
Internet traffic uses that new technology.


 


Until this happens, I =
insist that the word “Classic” must be removed in all context o=
f TCP and congestion control (as far as it is owned by TCPM), including the=
 reference above. BTW, “normal” as suggested would
 also work for me. So, you have plenty of options for other terms.


 




 


If Dave+Michael's suggestion of replacing "cl=
assic" with "normal" is agreable to others, this seems like =
a good way forward to me.  It should be easy enough to explain in othe=
r SDOs that classic and normal mean the same thing, if this is
 a real issue.


(FWIW, I've never had a problem myself with "clas=
sic", nor read any negative connotations to it.  However, for the=
 sake of working group progress, I think we just need to pick something tha=
t seems the least terrible and agree to move on.)


 










--_000_MN2PR19MB4045216D5E55A08FA8E04859837B0MN2PR19MB4045namp_--


From nobody Fri Nov  8 13:03:31 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 12DDB12084D; Fri,  8 Nov 2019 13:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01] 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 C6A772JVN3iR; Fri,  8 Nov 2019 13:03:21 -0800 (PST)
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 AF03B120871; Fri,  8 Nov 2019 13:03:20 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id D6DF225A12; Fri,  8 Nov 2019 22:03:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573246998; bh=WwzBEWQlrAUstL2sT4DzzbVJH1lxFiSsqpUtBBzaiAQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ECiY5qEY2oyxUeDg6xXv8o5ncLwJjt8mhnuCut8XTOXozXAJVk0QlLK1Pa+qOCDeS LaTObLpVnEvX9U4vtoZkaP1WPFQwKiK2oO90D7EyVRKoQ5EZ+adclPxmzNUb8lfPFg w7gIbQ703jbZACssydV3Hq1HGUaPVfgqThoRuhbo=
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 2RUmVrnXf0Ha; Fri,  8 Nov 2019 22:03:17 +0100 (CET)
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,  8 Nov 2019 22:03:17 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 8 Nov 2019 22:03:17 +0100
From: "Scharf, Michael" 
To: "Black, David" 
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] [tcpm]  L4S status tracking
Thread-Index: AQHVlnXvmwgefRBDRUazKhBQq/SzcKeBv4mg
Date: Fri, 8 Nov 2019 21:03:16 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4EE402@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.63.11]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4EE402rznt8114rzntrzd_"
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, 08 Nov 2019 21:03:24 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4EE402rznt8114rzntrzd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yep, that is exactly what I would suggest.

Michael

From: Black, David 
Sent: Friday, November 8, 2019 9:49 PM
To: Scharf, Michael 
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: RE: [tsvwg] [tcpm] L4S status tracking

Hopefully not adding confusion, I'm in favor of Michael's suggestion (below=
), as I understand it:
                - L4S has a "Classic" service
                - Protocols and traffic that use the L4S "Classic" service =
are identified/named/described with terms other than "Classic".

For congestion control in particular, I've found myself referring to 1/p an=
d 1/sqrt(p) congestion response behaviors for technical clarity/precision i=
n discussion, but those terms don't exactly roll off the tip of the tongue =
... and assume that the reader is familiar enough with TCP throughput equat=
ions to know what the variable p stands for.

Thanks, --David

From: tsvwg > On Beha=
lf Of Scharf, Michael
Sent: Thursday, November 7, 2019 3:11 AM
To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] [tcpm] L4S status tracking


[EXTERNAL EMAIL]
... and just to show that _my_ concern would be trivial to address by small=
 editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an i=
ncremental migration path so that normal TCP traffic classified in the 'Cla=
ssic' service of L4S will be no worse off" would already work for me.  It j=
ust takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service cla=
ss (and, e.g., "normal" sounds better to me), but in the context of a servi=
ce class, "classic" could actually work for me, if TSVWG really wants that =
name with strong consensus. I don't care how about names for DiffSe^D^D^D^D=
^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whateve=
r else is done in the fast path of a router to implement low latency servic=
e.

I only object to specific terminology such as 'Classic' TCP or 'Classic' co=
ngestion control because I don't think that 'classic' is a proper character=
ization for TCPM standards or TCP/IP stack behavior not aligned with whatev=
er L4S believes the bright future shall be.

Whether such small rewording address fully the concerns from others may be =
a different question.

Michael



From: Wesley Eddy >
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael >; Bob Briscoe >; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.




If Dave+Michael's suggestion of replacing "classic" with "normal" is agreab=
le to others, this seems like a good way forward to me.  It should be easy =
enough to explain in other SDOs that classic and normal mean the same thing=
, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negativ=
e connotations to it.  However, for the sake of working group progress, I t=
hink we just need to pick something that seems the least terrible and agree=
 to move on.)



--_000_6EC6417807D9754DA64F3087E2E2E03E2D4EE402rznt8114rzntrzd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Yep, that is exactly what I would suggest.


 


Michael


 








F=
rom: Black, Davi=
d <David.Black@dell.com>


Sent: Friday, November 8, 2019 9:49 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>

Cc: tcpm@ietf.org; tsvwg@ietf.org

Subject: RE: [tsvwg] [tcpm] L4S status tracking





 


Hopeful=
ly not adding confusion, I’m in favor of Michael’s suggestion (=
below), as I understand it:


 &=
nbsp;           &nbs=
p;  - L4S has a “Classic” service


 &=
nbsp;           &nbs=
p;  - Protocols and traffic that use the L4S “Classic” ser=
vice are identified/named/described with terms other than “Classic=
221;.


&n=
bsp;


For con=
gestion control in particular, I’ve found myself referring to 1/p and=
 1/sqrt(p) congestion response behaviors for technical clarity/precision in=
 discussion, but those terms don’t exactly roll
 off the tip of the tongue … and assume that the reader is familiar e=
nough with TCP throughput equations to know what the variable p stands for.=



&n=
bsp;




Thanks,=
 --David




&n=
bsp;








F=
rom: tsvwg <<=
a href=3D"mailto:tsvwg-bounces@ietf.org">tsvwg-bounces@ietf.org>
On Behalf Of Scharf, Michael

Sent: Thursday, November 7, 2019 3:11 AM

To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes

Cc: tcpm@ietf.org; 
tsvwg@ietf.org

Subject: Re: [tsvwg] [tcpm] L4S status tracking





 




[EXTERNAL EMAIL] 




…=
 and just to show that _my_ concern would be trivial to address by s=
mall editorial changes:


&n=
bsp;


For the=
 abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording “It gives an in=
cremental migration path so that normal TCP traffic classified in the ̵=
6;Classic’ service of L4S will be no worse off” would
 already work for me.  It just takes a small editorial change to make =
me happy. This can’t be so hard.


&n=
bsp;


Persona=
lly, I wonder if “classic” is indeed the best name for a servic=
e class (and, e.g., “normal” sounds better to me), but in the c=
ontext of a service class, “classic” could actually work for me=
,
 if TSVWG really wants that name with strong consensus. I don’t care =
how about names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic policer=
s/shapers, AQM schemes, or whatever else is done in the fast path of a rout=
er to implement low latency service.


&n=
bsp;


I only =
object to specific terminology such as ‘Classic’ TCP or ‘=
Classic’ congestion control because I don’t think that ‘c=
lassic’ is a proper characterization for TCPM standards or TCP/IP sta=
ck behavior
 not aligned with whatever L4S believes the bright future shall be.


&n=
bsp;


Whether=
 such small rewording address fully the concerns from others may be a diffe=
rent question.


&n=
bsp;


Michael=



&n=
bsp;


 


 








From:=
 Wesley Eddy <wes@mti-systems.com>


Sent: Wednesday, November 6, 2019 8:54 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Bob Briscoe <ietf@bobbriscoe.net>; Rodney W. Grimes <=
;4bone@gndrsh.dnsmgr.net>=


Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 




On 11/6/2019 1:57 PM, Scharf, Michael wrote:






Bob,=



 


From dr=
aft-ietf-tsvwg-ecn-l4s-id-08: “It gives an incremental migration path=
 so that existing 'Classic' TCP traffic will be no worse off”<=
o:p>


 <=
/span>


You are=
 proposing an experiment. Not more than that. I will be fine with the term =
“Classic” for TCP and TCPM-specified congestion control when mo=
re than 50% of Internet traffic uses that new technology.=



 <=
/span>


Until t=
his happens, I insist that the word “Classic” must be removed i=
n all context of TCP and congestion control (as far as it is owned by TCPM)=
, including the reference above. BTW, “normal” as
 suggested would also work for me. So, you have plenty of options for other=
 terms.


 <=
/span>




 


If Dave+Michael's suggestion of replacing "classic" with &=
quot;normal" is agreable to others, this seems like a good way forward=
 to me.  It should be easy enough to explain in other SDOs that classi=
c and normal mean the same thing, if this is a real issue.


(FWIW, I've never had a problem myself with "classic", nor rea=
d any negative connotations to it.  However, for the sake of working g=
roup progress, I think we just need to pick something that seems the least =
terrible and agree to move on.)


 












--_000_6EC6417807D9754DA64F3087E2E2E03E2D4EE402rznt8114rzntrzd_--


From nobody Sat Nov  9 08:00:23 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 EA045120024; Sat,  9 Nov 2019 08:00:21 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 nCymB12-pOv0; Sat,  9 Nov 2019 08:00:17 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40046.outbound.protection.outlook.com [40.107.4.46]) (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 8CBDE120137; Sat,  9 Nov 2019 08:00:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SBzVYFon1jhuSpIEF+ZUeLunVvapXjsHONrbZVoq3LpuHw6OhplLVMis6bvb1vE1F7qMSOiPdsAMTvvnW/HuAtlFM2EYuqKHLjCaQzGQf1P/v+jakUjpTro620fTDrloU/gu8US28m268j05TbjOhmAjP6bksrgbsy5bc5aSDdSdHHNKv0tsVx/QWTKUq5R9zC8plhveBICPaYzJQcO13z+XTJOTfK2lvhZomwQHrBrlwbx79AB4/ExlFVGSqKkxaRuHS0QEgKeR8/wL167Hqi6Vm5/OvezC4p7/FU6uI6sZQ8cM8uXRWRfYk4vC9BMHE29dPDEaENiTH684hk+AXA==
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=GL9KVlCtKjnFKhWwDBtNQ+gMWs+6YrPmw019LICyHaw=; b=dkXIdiFx6veFh5RUNbZdVlInHkluouDc9OrF+f5Px3hwt2BZAKWCr7ADQ2Wcp+IeiFitvsPA2j9ZtvQGWmgYt9PGOBiK4354SriSglQO7fmo5w6/r5p2/blCShJWvDsuukz6SzRnLNwg8GpHdDvx31PbP1J5mL3bSrGET7RDRA9uHgOwJObbjc6KprRrXOa0rpbKq/YbIwCApYbmSqm8poQE+rYnl3CVwBphZDYuWfMzwtcDwhys4HLzsDaXshjeR9JG+uh3Y7zf4voSVMfEOrroWbfouYj643LQOyqrdqMez3WKZCLYD6cf1J7nFNn4GT9L+fs0QSDCvELuf3zk1g==
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=GL9KVlCtKjnFKhWwDBtNQ+gMWs+6YrPmw019LICyHaw=; b=Vp8xyA/KefEIXF8BRvav10Jqp7MKhdTKfZXvgLXBSp+UduGn8u5yS3M24XLprALPUJ4WwsjErJDVh4J5yF0VZPfBZ4HrkLLhg3Jg/DyAqMNS3vlkY1gEY/FoVafbZXiSsO7aA9YwRJX11lDW7IqvOe04L7ibYnMSWXkZlhAxpuc=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB4266.eurprd07.prod.outlook.com (20.176.167.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.16; Sat, 9 Nov 2019 16:00:12 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.013; Sat, 9 Nov 2019 16:00:11 +0000
From: Ingemar Johansson S 
To: "tsvwg@ietf.org" , "tcpm@ietf.org" , "'iccrg@irtf.org'" 
CC: "Bob Briscoe (ietf@bobbriscoe.net)" , "koen.de_schepper@nokia.com" , Ingemar Johansson S 
Thread-Topic: L4S related activity in 3GPP 
Thread-Index: AdWXFU/rHJiyQelDTIOgP97lGH/97g==
Date: Sat, 9 Nov 2019 16:00:11 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ee499b32-f927-42dc-ce51-08d7652de6f0
x-ms-traffictypediagnostic: HE1PR07MB4266:|HE1PR07MB4266:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:2958;
x-forefront-prvs: 021670B4D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39860400002)(396003)(346002)(189003)(199004)(4326008)(54906003)(66066001)(790700001)(6306002)(6436002)(5660300002)(25786009)(66556008)(66476007)(110136005)(54896002)(86362001)(2501003)(107886003)(26005)(64756008)(52536014)(66946007)(476003)(486006)(186003)(76116006)(66616009)(71200400001)(102836004)(6506007)(71190400001)(9686003)(4743002)(236005)(7696005)(66446008)(99936001)(256004)(99286004)(14454004)(2906002)(55016002)(316002)(7736002)(8676002)(33656002)(81166006)(81156014)(8936002)(74316002)(3846002)(6116002)(606006)(966005)(478600001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4266; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zxwV1e7lG14IYynS3PLgHIkrOJIqZ39gcQnBxb0rY8Ok2w+OuoCWR2IQQzLUFPUNf3+kbioFRmvGgzI6q94dbyxGmUTpRmrrBFxn9pX+POq9v2wUT8Y8FX2wvgDtuCK5pNbe+ANHEEwhsi6k2zzx5nGJabE8JK/b86IERqsMdEuq/tNG23jqqHPiHLOSfJ8h1+b4+Mg6ebxukQoKI8+mcgqgjpPflTswgSoGCHJASoKVIpLWwRGZfniQcjuMxWUOtkmniivle2b85mdI7Z0h2k263Q6VM2PfEIrC0LVvoI1X2PiO6O60D9CIGeJF37P+8uGX9/dnUEgBNQSY5B22T3PCZ2WiLFRkQv2EUjla1kfoBicdLZhpg9U9ou3R5uOJsPujA7swE7AB/i6y1oO8tIOLE6NDAwapwjDT95RUowPnXWJKOMy2mkd30wFPADao
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F4_01D5971F.25C33C70"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee499b32-f927-42dc-ce51-08d7652de6f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2019 16:00:11.7550 (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: GrD5nhKupAy38FGUkurKR2HaQRdN1e6oGhDP8F4X2SK0D7ett2zSnw/SdiSJ7SiYFetNRdydoNWqS4VlLXX7nAmuvGEDBSrKmcaHDvSddB2zhDqQmzGETsaQbW6lpsSx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4266
Archived-At: 
Subject: [tcpm] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 16:00:22 -0000

------=_NextPart_000_00F4_01D5971F.25C33C70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00F5_01D5971F.25C36380"


------=_NextPart_001_00F5_01D5971F.25C36380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Gentlepeople!

=20

This 3GPP SA2 contribution is recently submitted

https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911250.z=
ip

Title =935QI values for efficient handling of congestion control marked =
IP
packets=94

The contribution introduces L4S to the SA2 audience and explains where =
the
technology is useful. The contribution also proposes a method to bake =
L4S
into the 5G QoS framework.

If agenda time permits, it will be discussed at the SA WG2 meeting in =
Reno
on Nov 18-22, hopefully with good results.=20

=20

Also a RAN2 contribution was submitted and discussed at an earlier RAN2
meeting.

https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1913888.zip=


=20

Enjoy

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.=20

Master Researcher

=20

Ericsson Research

Network Protocols & E2E Performance

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

=20

      The best way to find out if you=20

  can trust somebody is to trust them              =20

              Ernest Hemingway

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

=20


------=_NextPart_001_00F5_01D5971F.25C36380
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Gentlepeople!
 
This 3GPP =
SA2 contribution is recently submitted
https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/=
S2-1911250.zip
Title “5QI =
values for efficient handling of congestion control marked IP =
packets”
The contribution =
introduces L4S to the SA2 audience and explains where the technology is =
useful. The contribution also proposes a method to bake L4S into the 5G =
QoS framework.
If agenda time =
permits, it will be discussed at the SA WG2 meeting in Reno on Nov =
18-22, hopefully with good results. 
 
Also a RAN2 =
contribution was submitted and discussed at an earlier RAN2 =
meeting.
https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1=
913888.zip
 
Enjoy
/Ingemar
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ingemar Johansson=A0 =
M.Sc. 
Master Researcher
 
Ericsson =
Research
Network Protocols & E2E =
Performance
Labratoriegr=E4nd 11
971 28, Lule=E5, =
Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 =
3289
ingemar.s.johansson@ericsson.com=

www.ericsson.com
 
=A0=A0=A0=A0=A0 The best =
way to find out if you 
=A0=A0can trust somebody is to trust =
them=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0E=
rnest Hemingway
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 

------=_NextPart_001_00F5_01D5971F.25C36380--

------=_NextPart_000_00F4_01D5971F.25C33C70
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMDkxNjAwMTFaMCMGCSqGSIb3DQEJBDEWBBTqyr7GJAeIGLStCNWT
5iecChUo8TBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBABlKSvof6I3EeF4dR/ZkyW6qI/FzUBVMAOcT0szb
WjK/GSp1bbfxQ0lz5P7qE7Vd76klX91vHfVL0aSGG+M9Xa24w+wZrTSeESkSnrwbMTcqRdqHZjte
SvH2mnCFpf67Ku2etL5W3V9HUOAbEPvmyF57VfiW+3kNnDFz/vI73rmyTBhEJqYca5N+/MSlxRgP
Vs3HW7aBc7HmkRTv3lgkZJTT3tyL60kbF5IIAii+X+jwfE2xunYETAlVdT6SdJY/V+6A0Zn543VX
0wQ6xTt0fi/QM99wQ0LQ2vtWg7cH1zvr/w7xL0To0m39FPAwTCijGvbSXp/YmRilabUvsKrQIfIA
AAAAAAA=

------=_NextPart_000_00F4_01D5971F.25C33C70--


From nobody Sat Nov  9 09:13:46 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 DE0A11200C5; Sat,  9 Nov 2019 09:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 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] 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 VRdNC_4GnYuw; Sat,  9 Nov 2019 09:13:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5A74E120137; Sat,  9 Nov 2019 09:13:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573319598; bh=v8UuJirJYqdSMbRhJluD+Tfl3uB+92e+1R5eUyqouRM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=EsLhnMtxSOMGnyBIuvSsXrjwUxZ6ndAferDW92cvY8pX7AId7QN90s7kmQhRECJCL EcS2l0ESa+j+79ODnVxA5gqHMhV9dwXPswhQvA2qRnlL5fK9KX/6SGAut02zvGXfFE c3Ri7ORF6UV/+2bqIejkpbgvbOqkx9JlzUE2PSMU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.10.100.216]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFbW0-1ihCCm2QzW-00H9pm; Sat, 09 Nov 2019 18:13:18 +0100
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: Sat, 9 Nov 2019 18:13:12 +0100
Cc: "tsvwg@ietf.org" , "tcpm@ietf.org" , "iccrg@irtf.org" , Ingemar Johansson S , "koen.de_schepper@nokia.com" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>
References: 
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:9Uq5TBBEIW+d23IvyGkJktdGse9NtX48Sg+WtW8OZEiNfa71l6/ cSV7Rl3lTNKrSO2x54OPo4wsp3GB0AXx+W/9LJZJaZ4ekcsH2lGEr7GZqQdYYm/iBAxSZiZ WctQdEhX+RXdZ6QsR4ISkadFys0zScl5ZxJbDmq4EewSTROmtu1SUku0daf6CwxXk9OEs1V IXu0yygcpxZvRQpDpLLmg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:/xBilaWombg=:iEcapDolwgBrICpHZxzFwG 9SXzFiCFEYTYUSyJKDIuoEWyc3W7NyaYtjYVwQJcU8VbX6WZ/RYVVHznDEtooTDXDgmLf1iDM na55K0T60wvqhbuExv0MdSr/7Sb0sQNc+nl+YhGxjzH+KzGXWymXZg0KaPyd1AILOJlvnCKg0 hG4rKlbBAYV5o/Y2c4AqWWSLW/AZOqoJv38+hLOjJcO3hKzpGZbfNS3VwhpdKRjn6mHAvzY+O MIeu45IT5YDOTYUiGb47YjNVBGlZ9tWSAxoU/K62kksPexxbIOonE6eLU5BjHj033haWzyIWc lZ+62cWTMisYeYAzXTSjpEpytcbngDQpty26DIGRS6LV2rQUKiwJ0actF1op7tmVgbbiRVGUe KVAbd8boqm4O9RuJOWHLzLb3WPtI455HgebAItEDNsunz6leXmyf8YsbuQ2ngHLOUi34L3F8t T00sKGUohIhZpZu/n7X+U2kzqiSP9rILbgFFHvB2P9bZMGRLGzLyqn2zRCpI10UdTkMdrthG4 9MyhAcDa690JmnlUaEz1b1kKvjHdh9IdOKmH5XhPL+cHbAWNJUiQU5NWJToz1CIrFJgpkBq4S LisX6uLDL4d/HVFicRy9+ggHx2qmA+FC1FcUIPU8q903LZ8U25+IW3MVYLgw8lHkiCuzGGR9/ W7b+mF19fzGdoZ2Uobv2RyMPOaP09A+7pt3Hyd+JZKuWKXTtnSkeTOvYS1cbTQoC928NMLude JE8MCN6SeZgiHiiDOiqlpFe13QbeBBqfXBXCK8OvwqnU84vmv9Dtaml+I1tPLYaBcL/i2Uzd7 JpC1hEB+fCktQ62eGEh4t67s0d/MW+csdzh0sgh1n/VvXgTUs8g6B6bEdZd+s8laXujmULUdH lPlDaZJRvp3j6PrNwvX5QKUnonQpGz50KrxHcKjqH6QgBmbTAwSEGeiGdioFYCfOoym8yh42V hp+ZnHI2DYmwg2gnHuh7Gk7INxCG1qbDQWy+FkCM0TysZr64mgXemFN1jAAZZlx1/+erCjC5X 4LioOIRAIpZFdNFzmp065INjMBQ7lTU8QfNULplE+o7Wzc7zDhVm6rOrbyH+l0ragpbJD4MJt 3fP2uzQ+CFZaglsgS9CXHUUrFstYbCrII70PZBBA6MbjN11VPdPZ6kofQA8jmO2JRgm/FJoVD 1oUN43gU6/9hMg8uVVrsbM59r6ehih/HfcNBStzS0CdXvxxYgqPQrRGPcf3DbnT70FW0HQ8Xt mySERvKDsz8oCrRjBX0fe9wZiU10pPCVuCSSMSilyayh5l2/qeL+yGIA6e2g=
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 17:13:33 -0000

Dear Ingemar,

thanks for posting this. I read "This document describes an Active Queue =
Management mechanism, =E2=80=98L4S=E2=80=99, that can support =
low-latency services in a way that does not degrade the performance of =
other traffic." and I wonder whether 3GPP has run any experiments to =
confirm/support this claim, that you are willing to share?

Sidenote: in the powerpoint file it says about L4s " Standardized in =
IETF [1]", which seems premature, in the process of being standardized =
seems a better description of the status quo...


I ask about test data from your side as the recent test data is quite =
sobering from a number of angles, including quality of isolation:

	Looking at the current L4S tests from the various testbeds I see =
severe breakdown of the promised isolation between bulk and the =
"low-latency" queue, apparently making the current implementation, if =
not the concept itself IMHO unfit for release into the wider internet, =
before these issues have been sufficiently addressed. Especially the =
observation that the weighted scheduler built in as a safety mechanism =
in the dualQ aqm seems to trigger considerably more often than =
expected/predicted from reading the dualQ draft (giving 1/16 of the =
bandwidth to on of two classes _might_ be justified as a temporary =
stop-gap measure in extremely unlikely cases, but this already triggers =
in a simple one-flow-per queue scenario at low RTTs). In short it =
currently looks like the "does not degrade performance of other traffic" =
part is not yet finished.=20

	To illustrate my criticism, here is a link to a test comparing =
the simplest functionality test imaginable, running one L4S-style and =
one non-L4S-style TCP connection through the L4S dual queue AQM at a =
intranet like RTT (nomnally 0ms, but in reality):
=
https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-pr=
ague-50Mbit-0ms_var.png
As can be seen the L4S flow (labeled prague) ends up very quickly taking =
~90% of the available bandwidth, leaving only 10% to the non-L4S flow =
(labeled cubic), wit increasing RTT this bias gets less extreme, but =
even at 80ms the prague flow still gets around 1.5 times the bandwidth =
of the cubic flow =
(https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-p=
rague-50Mbit-80ms_var.png), indicating an RTT dependent performance =
degradation for "other traffic". Test from another testbed confirm the =
break-down of fairness between L4S and non-L4S traffic at short RTTs =
(https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T04542=
7-r1/l4s-s1-2/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_fixed.png).



	Personally, I can not help thinking that it might be better to =
first make sure there is a complete, real-world tested implementation =
that reliably demonstrates that dualQ delivers the required isolation =
between the two traffic classes and that the L4S approach actually =
delivers the reported reliable low latency performance under adverse =
real-world conditions while not degrading the performance of other =
traffic, before trying to codify L4S into RFCs.


Best Regards
	Sebastian


> On Nov 9, 2019, at 17:00, Ingemar Johansson S =
 wrote:
>=20
> Gentlepeople!
> =20
> This 3GPP SA2 contribution is recently submitted
> =
https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911250.zi=
p
> Title =E2=80=9C5QI values for efficient handling of congestion control =
marked IP packets=E2=80=9D
> The contribution introduces L4S to the SA2 audience and explains where =
the technology is useful. The contribution also proposes a method to =
bake L4S into the 5G QoS framework.
> If agenda time permits, it will be discussed at the SA WG2 meeting in =
Reno on Nov 18-22, hopefully with good results.=20
> =20
> Also a RAN2 contribution was submitted and discussed at an earlier =
RAN2 meeting.
> =
https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1913888.zip
> =20
> Enjoy
> /Ingemar
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> Ingemar Johansson  M.Sc.=20
> Master Researcher
> =20
> Ericsson Research
> Network Protocols & E2E Performance
> Labratoriegr=C3=A4nd 11
> 971 28, Lule=C3=A5, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> ingemar.s.johansson@ericsson.com
> www.ericsson.com
> =20
>       The best way to find out if you=20
>   can trust somebody is to trust them              =20
>               Ernest Hemingway
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D


From nobody Sat Nov  9 10:04:42 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 64FBB120019; Sat,  9 Nov 2019 10:04:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 vK1TF7SaE57k; Sat,  9 Nov 2019 10:04:40 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81B112099C; Sat,  9 Nov 2019 10:04:09 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xA9I42O3025650; Sat, 9 Nov 2019 10:04:02 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xA9I41I2025649; Sat, 9 Nov 2019 10:04:01 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911091804.xA9I41I2025649@gndrsh.dnsmgr.net>
In-Reply-To: 
To: Ingemar Johansson S 
Date: Sat, 9 Nov 2019 10:04:01 -0800 (PST)
CC: "tsvwg@ietf.org" , "tcpm@ietf.org" , "'iccrg@irtf.org'" , Ingemar Johansson S , "koen.de_schepper@nokia.com" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 18:04:41 -0000

> Gentlepeople!
> 
>  
> 
> This 3GPP SA2 contribution is recently submitted
> 
> https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911250.zip
> 
> Title ?5QI values for efficient handling of congestion control marked IP
> packets?
> 
> The contribution introduces L4S to the SA2 audience and explains where the
> technology is useful. The contribution also proposes a method to bake L4S
> into the 5G QoS framework.
> 
> If agenda time permits, it will be discussed at the SA WG2 meeting in Reno
> on Nov 18-22, hopefully with good results. 
> 

Can you elaborate on the item "L4S adoption in the industry" from slide 2?
So far as I am aware there is not even a completed prototype
implementation of L4S.

And in slide 4 "Standardized in IETF [1]" is a premature statement
about the actual state of the L4S drafts.

In slide 5, the graphs, what are the blue line and the red line?
Are they simply 2 identical flow attempts?
Also no data on this graph about B or D values, though I can
speculate it is 250mb/s and 25 ms, but that falls out when
I look at the L4S forwad packet delay graph as the delay
there is below that of my 25mS derived D, which could not
occur.  Could you please provide a description of the tooling
data, and parameters so that we might independently validate
these graphs?

Regards,
Rod

> 
> Also a RAN2 contribution was submitted and discussed at an earlier RAN2
> meeting.
> 
> https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1913888.zip
> 
>  
> 
> Enjoy
> 
> /Ingemar
> 
> ================================
> 
> Ingemar Johansson  M.Sc. 
> 
> Master Researcher
> 
>  
> 
> Ericsson Research
> 
> Network Protocols & E2E Performance
> 
> Labratoriegr?nd 11
> 
> 971 28, Lule?, Sweden
> 
> Phone +46-1071 43042
> 
> SMS/MMS +46-73 078 3289
> 
> ingemar.s.johansson@ericsson.com
> 
> www.ericsson.com
> 
>  
> 
>       The best way to find out if you 
> 
>   can trust somebody is to trust them               
> 
>               Ernest Hemingway
> 
> =================================
> 
>  
> 

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

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Sat Nov  9 11:24: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 1A5611200CE; Sat,  9 Nov 2019 11:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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] 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 8dVaVwR0pvEM; Sat,  9 Nov 2019 11:24:26 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) (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 9C6CC12001A; Sat,  9 Nov 2019 11:24:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iaoc5bA4XD9/L5dyTuseVIHdoUb1fIEgqdUBaClOm3OS4P+apwNP01724YkWrZ7XymhAXXL88B5IrRRzXh1VVX4cZ1BKsaI5XZCv5ob226H27nTeQtx3EPI096N4XL6zjR5efsU9ck2R6YH38pYsaL5auU7ivvtNwKN0ODBJyWVGaJ5MQvzSAot1dReR+WTXuc5gTwopULTvgLwKaHsLemFiUxIfY93RVmIB7vIKXwayRVTYLx8RFMNeqTqWPBI3duxD2yABp7Is4o6y7vR9KSnohZObSfXYWIpCQHhGEBJfx9TX8Hxqb1q/V3R9Sk8464UezzcqKskn+ZwfsP0aqg==
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=RRjO85xQ71MqE46MvSakQCIQI9mmToGnbUBbFtAlAt0=; b=Zb9ZLOpqNu3avj/rXpwf3a4S/2l9sA6JZo4K+YpghM41ZRhQaKBzuDGuYQ5CtxM8O6OyFwCQMVJghoimvh2XxCyiroLFYlB4LyLEl1UVmA1nBYtwFnzTKlB31rjbEe8oUJDjlDjr0OhhlBryg1Zm/9+PR+CLrUwL1VyH26kcJMXbknUZF0v7mN7DksUdlB3mEHkOWx1+9rAEwxYWWBl95HO5usUcqbiYcrfZ6zK6UtqvtEPDfuPz+l2IErwQGymIYEBTEd9sNZUjgCSkjpLCxaLQFysh54VzGoqCTvn/riU9nIaOWWDRBPj3vq6NBAUBrOWyaYRHjdGlnIRZV7C8oA==
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=RRjO85xQ71MqE46MvSakQCIQI9mmToGnbUBbFtAlAt0=; b=UfODBtI07oFctDcQj4kW2o4n6y+vjxXB8hOPb7tKIzowgvEYI/WwWa8zPLmynLs0OXOluEmMG6lt6/do63zI82Mpf00/9gIL5qBWX0+honAomd867zCuxm/NIWEiUcAvMqs0xIN/CYhniDPAg/NlyW+fYtzmNRgbVEklxy8bUQc=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3417.eurprd07.prod.outlook.com (10.170.244.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.16; Sat, 9 Nov 2019 19:24:21 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.013; Sat, 9 Nov 2019 19:24:21 +0000
From: Ingemar Johansson S 
To: Sebastian Moeller , Ingemar Johansson S 
CC: "tsvwg@ietf.org" , "tcpm@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" , "Bob Briscoe (ietf@bobbriscoe.net)" , Ingemar Johansson S 
Thread-Topic: [tsvwg] L4S related activity in 3GPP
Thread-Index: AdWXFU/rHJiyQelDTIOgP97lGH/97gAC6dQAAAPywbA=
Date: Sat, 9 Nov 2019 19:24:21 +0000
Message-ID: 
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>
In-Reply-To: <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 50893be6-bb20-4038-29f3-08d7654a6c25
x-ms-traffictypediagnostic: HE1PR07MB3417:|HE1PR07MB3417:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 021670B4D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(13464003)(189003)(199004)(3846002)(8936002)(11346002)(476003)(8676002)(25786009)(14454004)(66066001)(81156014)(53546011)(6506007)(446003)(102836004)(966005)(6116002)(486006)(5660300002)(26005)(86362001)(305945005)(7736002)(74316002)(52536014)(66574012)(71200400001)(71190400001)(186003)(478600001)(2906002)(81166006)(7696005)(14444005)(76176011)(256004)(561944003)(15974865002)(6246003)(33656002)(99286004)(99936001)(110136005)(66446008)(66556008)(4326008)(316002)(107886003)(54906003)(66946007)(9686003)(66476007)(6436002)(6306002)(55016002)(229853002)(76116006)(64756008)(66616009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3417; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YFa3gIvLlLyYM5H7EmbgXFCpeAerz98KnD8uLhVfD6tgEeklbXyI9AaQpgOyBIv7/nGrRRw/ZC2/uoZ/RSm/6mOBh5GIZabLS1hTKAtf0zy+wAHk+JYbnthwZkL1KPxGau2KSjwuo1NSOIaiQeln6P4ynWP7bqW5BE3PZxAhbKn7HR7ORLcpWNJxLVY5+d5m2WSdyK3pixl3xflGOIJdWH6e6OdDJoN1XI/E/ac3Dh6cnzZ1XXa1fqhxgUzx6J89PXtBDjYY0evP/mCdaoomOIQrImK7tK3jmZ6cO2x0YQeNp8DQcSq37a2I0N3ySL+uT2mqAL4LnsgdVX2PHy+fHvQVAuxjtcV+hifZRTsbZvG1xHFTm73oJWhGeWGOc+cEJZPgY86+IF5mTE5Xfi7Rulj5Gru1RNkkSj/mf0PTTDxJ4P6HI61Dso3Iz4NtzIqK
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0108_01D5973B.AADE07C0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 50893be6-bb20-4038-29f3-08d7654a6c25
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2019 19:24:21.1055 (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: 0rvL4F9pMDR3JMuiaBDwmbcHEZw25d388xDjOsr8fkjKYQSfKN7w7nSDWQdaMJu3D9ecQApENHOxJZLtDbYaxRg9im2Ayw3XlLWp7+lsc9H+3OMAr2DqCe3RePN8HfWI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3417
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 19:24:31 -0000

------=_NextPart_000_0108_01D5973B.AADE07C0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sebastian=20

Please see inline below
/Ingemar

> -----Original Message-----
> From: Sebastian Moeller 
> Sent: den 9 november 2019 18:13
> To: Ingemar Johansson S
> 
> Cc: tsvwg@ietf.org; tcpm@ietf.org; iccrg@irtf.org; Ingemar Johansson S
> ; koen.de_schepper@nokia.com
> Subject: Re: [tsvwg] L4S related activity in 3GPP
>=20
> Dear Ingemar,
>=20
> thanks for posting this. I read "This document describes an Active =
Queue
> Management mechanism, =E2=80=98L4S=E2=80=99, that can support =
low-latency services in a way
> that does not degrade the performance of other traffic." and I wonder =
whether
> 3GPP has run any experiments to confirm/support this claim, that you =
are willing
> to share?

[IJ] We have done simulation studies with our proprietary 4G/5G system =
simulation tools but I can not disclose the results from these.
>=20
> Sidenote: in the powerpoint file it says about L4s " Standardized in =
IETF [1]",
> which seems premature, in the process of being standardized seems a =
better
> description of the status quo...

[IJ] Yes, you are right about this, it should have been "Subject to =
standardization..."

>=20
>=20
> I ask about test data from your side as the recent test data is quite =
sobering
> from a number of angles, including quality of isolation:

[IJ] First of all the outline of the proposal for L4S in 5G is to use =
separate radio bearers for L4S and classic (or normal or non-L4S) =
traffic. This means that it is the 5G QoS framework and the scheduling =
in the RAN (Radio Access Network) that dictates the fairness. But of =
course there are wireline transport link in the core network that may be =
using DualQ when that becomes commercially available. The bitrates over =
these links are however likely to be considerably higher than 50Mbps.

>=20
> 	Looking at the current L4S tests from the various testbeds I see =
severe
> breakdown of the promised isolation between bulk and the "low-latency" =
queue,
> apparently making the current implementation, if not the concept =
itself IMHO
> unfit for release into the wider internet, before these issues have =
been
> sufficiently addressed. Especially the observation that the weighted =
scheduler
> built in as a safety mechanism in the dualQ aqm seems to trigger =
considerably
> more often than expected/predicted from reading the dualQ draft =
(giving 1/16
> of the bandwidth to on of two classes _might_ be justified as a =
temporary stop-
> gap measure in extremely unlikely cases, but this already triggers in =
a simple
> one-flow-per queue scenario at low RTTs). In short it currently looks =
like the
> "does not degrade performance of other traffic" part is not yet =
finished.
>=20
> 	To illustrate my criticism, here is a link to a test comparing the =
simplest
> functionality test imaginable, running one L4S-style and one =
non-L4S-style TCP
> connection through the L4S dual queue AQM at a intranet like RTT =
(nomnally
> 0ms, but in reality):
> https://protect2.fireeye.com/v1/url?k=3Dfcd5c73d-a05c68f4-fcd587a6-
> 0cc47ad93e1c-6acfac650abe7f09&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png
> As can be seen the L4S flow (labeled prague) ends up very quickly =
taking ~90% of
> the available bandwidth, leaving only 10% to the non-L4S flow (labeled =
cubic),
> wit increasing RTT this bias gets less extreme, but even at 80ms the =
prague flow
> still gets around 1.5 times the bandwidth of the cubic flow
> (https://protect2.fireeye.com/v1/url?k=3D77272802-2bae87cb-77276899-
> 0cc47ad93e1c-56d0590db27309ef&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-80ms_var.png)=
,
> indicating an RTT dependent performance degradation for "other =
traffic". Test
> from another testbed confirm the break-down of fairness between L4S =
and non-
> L4S traffic at short RTTs =
(https://protect2.fireeye.com/v1/url?k=3D5710f0ef-
> 0b995f26-5710b074-0cc47ad93e1c-418920d155a62bf0&q=3D1&e=3D6cd6c372-
> b712-46be-8b10-
> 22955dec7b38&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-l4s-
> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s1-2%2Fbatch-l4s-s1-2-
> cubic-vs-prague-50Mbit-0ms_fixed.png).

[IJ] I understand that the 0 RTT results can be because the congestion =
window is only a few segments large (my guess is ~3 to 4 segments ?). I =
know that this is a problem with e.g. DCTCP.  The question is whether =
this is a permanent problem or something that will be solved over time?. =
What is more interesting to me and what makes L4S attractive for the use =
cases outlined in the 3GPP contributions, is the very low queue delay =
with L4S. There are other promising features with L4S. One being that it =
can enable congestion control algorithms to quickly grab free capacity. =
5G access can have large variations in link throughput for example =
related to dual connectivity and L4S can be helpful here as well.

>=20
> 	Personally, I can not help thinking that it might be better to first =
make
> sure there is a complete, real-world tested implementation that =
reliably
> demonstrates that dualQ delivers the required isolation between the =
two traffic
> classes and that the L4S approach actually delivers the reported =
reliable low
> latency performance under adverse real-world conditions while not =
degrading
> the performance of other traffic, before trying to codify L4S into =
RFCs.
>=20
>=20
> Best Regards
> 	Sebastian
>=20
>=20
> > On Nov 9, 2019, at 17:00, Ingemar Johansson S
>  wrote:
> >
> > Gentlepeople!
> >
> > This 3GPP SA2 contribution is recently submitted
> > =
https://protect2.fireeye.com/v1/url?k=3D803d870e-dcb428c7-803dc795-0cc47
> > ad93e1c-77a60175f8460bc6&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> 22955dec7b38&u=3D
> >
> https%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FWG2_Arch%2FTSGS2_136
> _Reno%
> > 2FDocs%2FS2-1911250.zip Title =E2=80=9C5QI values for efficient =
handling of
> > congestion control marked IP packets=E2=80=9D
> > The contribution introduces L4S to the SA2 audience and explains =
where the
> technology is useful. The contribution also proposes a method to bake =
L4S into
> the 5G QoS framework.
> > If agenda time permits, it will be discussed at the SA WG2 meeting =
in Reno on
> Nov 18-22, hopefully with good results.
> >
> > Also a RAN2 contribution was submitted and discussed at an earlier =
RAN2
> meeting.
> > =
https://protect2.fireeye.com/v1/url?k=3D06eb4ef7-5a62e13e-06eb0e6c-0cc47
> > ad93e1c-f387514c9f633599&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> 22955dec7b38&u=3D
> >
> https%3A%2F%2Fwww.3gpp.org%2Fftp%2FTSG_RAN%2FWG2_RL2%2FTSGR2_1
> 07bis%2F
> > Docs%2FR2-1913888.zip
> >
> > Enjoy
> > /Ingemar
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
> > Ingemar Johansson  M.Sc.
> > Master Researcher
> >
> > Ericsson Research
> > Network Protocols & E2E Performance
> > Labratoriegr=C3=A4nd 11
> > 971 28, Lule=C3=A5, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > ingemar.s.johansson@ericsson.com
> > www.ericsson.com
> >
> >       The best way to find out if you
> >   can trust somebody is to trust them
> >               Ernest Hemingway
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D


------=_NextPart_000_0108_01D5973B.AADE07C0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMDkxOTI0MjBaMCMGCSqGSIb3DQEJBDEWBBRlGcsQrcKNWzAga9EZ
ziWkCrehvjBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBADvIEUSuz95fRXor2tH9xqof1it+Yg0rV1CAlz1k
fpqYAnO41AkZyfJa4PGAT30dtqJXqXtqnbGc3rNs0+e1q9TBy9+Wrn7oWHfbso4RfOn3X/ZscFb5
36xouNk5Cm8dsJuWoMVY7WwxufTyiq15SgZqu7TpVyVWtNIqO8A51BPeEa3zBI9Rgnhhu/lQOr4h
ZdnntJc7EJ0I+YsdNWJ7zdxvbhsMSfM/qVUH8v7UNK1poeDqpRiZjP5a7268b7ooEI1Vfb2gR6kw
dzcK7KC+gWDB9SCx0x16coU584NojM4raM2OGWvNBhY2ot94lrhxNRiWa3J0AlrJfguP9UJyMRcA
AAAAAAA=

------=_NextPart_000_0108_01D5973B.AADE07C0--


From nobody Sat Nov  9 12:39:09 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 DE677120020; Sat,  9 Nov 2019 12:39:06 -0800 (PST)
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=unavailable 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 wCxr4AB6bwoI; Sat,  9 Nov 2019 12:39:03 -0800 (PST)
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 D5E22120048; Sat,  9 Nov 2019 12:39:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573331887; bh=2U/w55u84RuQGmIxjZnIgV2s/qNqxRR9+Q6d0OjEG6U=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=bRjAz3xk2h+KkyNCg4QOVcagEKh44Lu+PFHXZivyQfytyIt8CQJiSfrrc6F3HomKG ATvCdpvIwS9c/J6x4WOVya7tT8A9Z9b/Due4CXH500WYXizMfesJjrMjI54x10Kulv 21ECfDJS7WXRikNMuT8Fayv5wahpiMHa61fdUHT8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.10.100.216]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MKsj7-1iCqWJ331R-00LDLy; Sat, 09 Nov 2019 21:38:06 +0100
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: Sat, 9 Nov 2019 21:38:00 +0100
Cc: Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" , "Bob Briscoe (ietf@bobbriscoe.net)" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de> 
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:60qNxH7vhefk3AKYrGTUAIdVLRpIAdhATok3/4ZzxIwXT9HS76s XuymVyd+jXE+xs6MsM9iisvMNAUZGjzDAyfE+RB59ygP16QIV1A627vP99Tbvc5jsjYLQ7Q sd6nVTXYu7nThs3qDpbRQoKqE/3dsC3C8kRFxc513bJHdV+0w5X5SKQTQF0q8diSPAcc2Qv 9BXHjNQGVB+nAkrvzrBhA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vaY7kTDS1Fk=:mp2ZNySoQCAUFnd7qay86u FWqHSgr3MO9frIEDHVvJpbHVzgN0doQxwrIUCYu/sAzjb6I6rEeOKNDX4rs2GhHH93OLSVMOl khQBcHAhYSFUAwGfmjn/CnJQorEPq9OJwsfjWPzFz3JBJbD4Z3JNIQHK7LaW54uaEcK0Xl5gf eEo1mDxf9oQSeJ2lVEgq+eKE+OmPj2K7Bf5nx4B7M1V4zQrMQF9OTpxte16Q7NvbdKpY+Uxmp iMOBbAJXJgcpMcks0DpGmd5gfB/dW8hCd19H43TXV+7BaM3RKgdWnLS86oJTFuf14nqVJiAgu kjKJ5PfNAWmvQmtYDon5NhlCu0QBPIuPPMka85lqsIDI8u9yYbMvIYqmXXGoETwtY7WU97EYT +0lmPGO/lc8ySUNVcSfsqczVHdGmoKj5aNLoYqH+mYIPfctu1c/jDbxgunl2V7QicekQCjcRq o8cMDEDHW6Pf9PGi/6SGbKkz5ViH6rzUC/ni8tEPhTo7QoPxnh/7LJslkbtHBqeMJ9ED198GB 3X6tt94En1SDtgjPPtahcRIxYJs+lAphzX+DdYAipUqJBc/p/vClcw7aFQy7qxaZAfnEx2Ea6 6y++UzMTPAwXTyh7Cp0syKRa9z8EMRv75uTRVAnAvgyB0BW3bwDbKuezCoDlZiUcqht/DH4UN 0OlVlEbk1uXC2ZZP+AVwvZPvGtVrLQEIvmeoUBuWM8+wvQ4Hcix6Ze/K5ZKeC4TSGGwtprd+G Lk9pN8VDTvzBgjcsWKlWSWRV1HNRg5gD8G1AvuwiZuzy7OUBAbob//F7ZjdCpRlLfdRL/TWDw pmTqTp4F1x3ju2g1VpbdVKLBwShdFCOs44RD9vSB4aM8gTRkyQYF6G6P5gwpVlDWjZk85uZTf WLN1ja96SAmKF2drOzaISkSkcGQVhzc6376jhmt7EONzw6XYuWYeEdtsEMLGDOYutfUmMtTJk 0wjpb0h4+Q0VriRZmCVvXFHMhKhCUctEfe1K/myRaqh0clKlHaw6aarheExsmBzuTUSnrjs5c +kdWd+KhMSFHDyfYipBowjiOTtmZnbJlnqBrTrlW6Q9TQc7SRupw9LPuZPSAotjfINYnGH0Li 640l5M9Ol5igjySSJtcYdM3zQnWDQvojJrCF+IGnGNag3PDAtUY4QnN+wOaYlv2/WgQZFH4k/ isczskVzyyY/K8WkInuD4xUaejn7yKXoqjvB3o7pybRGpREiHyTtHlovDA8uhhL3dBeLTWGTG LgQZPfxRhjWv2Q1E3DBq+pPfdzUAl9HjccyPtTJRpk0aulJZsgTJrJHo+/4E=
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 20:39:07 -0000

Dear Ingemar,

more in-line below.

> On Nov 9, 2019, at 20:24, Ingemar Johansson S =
 wrote:
>=20
> Hi Sebastian=20
>=20
> Please see inline below
> /Ingemar
>=20
>> -----Original Message-----
>> From: Sebastian Moeller 
>> Sent: den 9 november 2019 18:13
>> To: Ingemar Johansson S
>> 
>> Cc: tsvwg@ietf.org; tcpm@ietf.org; iccrg@irtf.org; Ingemar Johansson =
S
>> ; koen.de_schepper@nokia.com
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>>=20
>> Dear Ingemar,
>>=20
>> thanks for posting this. I read "This document describes an Active =
Queue
>> Management mechanism, =E2=80=98L4S=E2=80=99, that can support =
low-latency services in a way
>> that does not degrade the performance of other traffic." and I wonder =
whether
>> 3GPP has run any experiments to confirm/support this claim, that you =
are willing
>> to share?
>=20
> [IJ] We have done simulation studies with our proprietary 4G/5G system =
simulation tools but I can not disclose the results from these.

	[SM] Ah, I see, not posting internal data is fine, but by all =
means, go and perform real-world measurements as well with all the parts =
you actually want to roll-out (in other words testing with dctcp for =
example is scientifically interesting, unless you expect your users to =
actually use dctcp on your links).


>>=20
>> Sidenote: in the powerpoint file it says about L4s " Standardized in =
IETF [1]",
>> which seems premature, in the process of being standardized seems a =
better
>> description of the status quo...
>=20
> [IJ] Yes, you are right about this, it should have been "Subject to =
standardization..."

	[SM] Fair enough, as much as I regret to say it, standardization =
is quite likely.

>=20
>>=20
>>=20
>> I ask about test data from your side as the recent test data is quite =
sobering
>> from a number of angles, including quality of isolation:
>=20
> [IJ] First of all the outline of the proposal for L4S in 5G is to use =
separate radio bearers for L4S and classic (or normal or non-L4S) =
traffic. This means that it is the 5G QoS framework and the scheduling =
in the RAN (Radio Access Network) that dictates the fairness.

	[SM] Sounds like a workable approach, that side steps the dualQ =
implementation/theory issues.


> But of course there are wireline transport link in the core network =
that may be using DualQ when that becomes commercially available. The =
bitrates over these links are however likely to be considerably higher =
than 50Mbps.

	That does not matter, the issue is not the limit of 50 Mbps, but =
the fact that dualQ, at last the current implementation in conjunction =
with the current TCP prague implementation, simply do not reliably and =
robustly do what the rfc draft claims. My fear is that dualQ, with its =
weak coupling vie marking probabilities, simply is a design, that only =
guarantees approximate fairness. In other words I doubt that dualQ works =
as a naive reading of the RFC implies. But if I  understood Bob correct, =
the only gurantee he is willing to give is L4S does not starve non-L4S =
traffic. Which IMHO is not sufficient to merit inflicting the L4S =
experiment on the wider internet. Now, that is not my call to make, but =
the IETF process allows me t voice my concerns, and I just use this =
opportunity in an attempt to minimize undesired side-effects on the =
"normal" internet.

>=20
>>=20
>> 	Looking at the current L4S tests from the various testbeds I see =
severe
>> breakdown of the promised isolation between bulk and the =
"low-latency" queue,
>> apparently making the current implementation, if not the concept =
itself IMHO
>> unfit for release into the wider internet, before these issues have =
been
>> sufficiently addressed. Especially the observation that the weighted =
scheduler
>> built in as a safety mechanism in the dualQ aqm seems to trigger =
considerably
>> more often than expected/predicted from reading the dualQ draft =
(giving 1/16
>> of the bandwidth to on of two classes _might_ be justified as a =
temporary stop-
>> gap measure in extremely unlikely cases, but this already triggers in =
a simple
>> one-flow-per queue scenario at low RTTs). In short it currently looks =
like the
>> "does not degrade performance of other traffic" part is not yet =
finished.
>>=20
>> 	To illustrate my criticism, here is a link to a test comparing =
the simplest
>> functionality test imaginable, running one L4S-style and one =
non-L4S-style TCP
>> connection through the L4S dual queue AQM at a intranet like RTT =
(nomnally
>> 0ms, but in reality):
>> https://protect2.fireeye.com/v1/url?k=3Dfcd5c73d-a05c68f4-fcd587a6-
>> 0cc47ad93e1c-6acfac650abe7f09&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png
>> As can be seen the L4S flow (labeled prague) ends up very quickly =
taking ~90% of
>> the available bandwidth, leaving only 10% to the non-L4S flow =
(labeled cubic),
>> wit increasing RTT this bias gets less extreme, but even at 80ms the =
prague flow
>> still gets around 1.5 times the bandwidth of the cubic flow
>> (https://protect2.fireeye.com/v1/url?k=3D77272802-2bae87cb-77276899-
>> 0cc47ad93e1c-56d0590db27309ef&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-80ms_var.png),=

>> indicating an RTT dependent performance degradation for "other =
traffic". Test
>> from another testbed confirm the break-down of fairness between L4S =
and non-
>> L4S traffic at short RTTs =
(https://protect2.fireeye.com/v1/url?k=3D5710f0ef-
>> 0b995f26-5710b074-0cc47ad93e1c-418920d155a62bf0&q=3D1&e=3D6cd6c372-
>> b712-46be-8b10-
>> 22955dec7b38&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-l4s-
>> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s1-2%2Fbatch-l4s-s1-2-
>> cubic-vs-prague-50Mbit-0ms_fixed.png).
>=20
> [IJ] I understand that the 0 RTT results can be because the congestion =
window is only a few segments large (my guess is ~3 to 4 segments ?). I =
know that this is a problem with e.g. DCTCP.  The question is whether =
this is a permanent problem or something that will be solved over time?.

	[SM] With DualQ, I assume it is a structural problem, instead of =
designing this as a robust system with two fair sharing queues it does =
its clever "indirect coupling" via marking/dropping probabilities. Have =
a look at =
https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T045427=
-r1/l4s-s2-2/batch-l4s-s2-2-cubic-vs-prague-50Mbit-10ms_fixed.png for =
how sharing in a FQ system looks. Even with the leaky ECT(1) as =
classifier abuse it shoukd be simple to fair queue between EXT(1) and =
not ECH(1) flows and have robust separation. This is not rocket science, =
and mostly, as far as I can tell a solved problem.

> What is more interesting to me and what makes L4S attractive for the =
use cases outlined in the 3GPP contributions, is the very low queue =
delay with L4S.

	[SM] Well, I believe low queueing delay can be achieved without =
dualQ and without abusing the ECT(1) codepoint as a classifier (the =
desired classifier requires one complete independent bit, ECT(1) is just =
1/2 of a bit, and hence has failure modes in separating L4S-style flows =
and non-L4S flows). The idea of using the finer-grained congestion =
signaling of DCTCP over the wider internet seems sane see the SCE draft =
proposal as an alternative that would/will allow dctcp-style ECN =
signaling over the internet in a truly backward compatible fashion...


> There are other promising features with L4S. One being that it can =
enable congestion control algorithms to quickly grab free capacity.

	[SM] When you say L4S, do you mean the congestion signaling? =
Then https://tools.ietf.org/html/draft-morton-taht-sce-00 should have =
you covered, without the nasty side-effects of the current L4S proposal. =
Or do you mean the actual congestion controller as implemented in TCP =
prague?=20


> 5G access can have large variations in link throughput for example =
related to dual connectivity and L4S can be helpful here as well.

	[SM] Dealing better with variable rate links is certainly =
desirable, but I am not sure that DualQ/TCP Prague really are the best =
or only tools for that purpose. At least not until all of the kinks are =
ironed out. Again, none of this is my call to make, so all I am voicing =
is my educated subjective assessments.


Best Regards
	Sebastian

>=20
>>=20
>> 	Personally, I can not help thinking that it might be better to =
first make
>> sure there is a complete, real-world tested implementation that =
reliably
>> demonstrates that dualQ delivers the required isolation between the =
two traffic
>> classes and that the L4S approach actually delivers the reported =
reliable low
>> latency performance under adverse real-world conditions while not =
degrading
>> the performance of other traffic, before trying to codify L4S into =
RFCs.
>>=20
>>=20
>> Best Regards
>> 	Sebastian
>>=20
>>=20
>>> On Nov 9, 2019, at 17:00, Ingemar Johansson S
>>  wrote:
>>>=20
>>> Gentlepeople!
>>>=20
>>> This 3GPP SA2 contribution is recently submitted
>>> =
https://protect2.fireeye.com/v1/url?k=3D803d870e-dcb428c7-803dc795-0cc47
>>> ad93e1c-77a60175f8460bc6&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>> 22955dec7b38&u=3D
>>>=20
>> https%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FWG2_Arch%2FTSGS2_136
>> _Reno%
>>> 2FDocs%2FS2-1911250.zip Title =E2=80=9C5QI values for efficient =
handling of
>>> congestion control marked IP packets=E2=80=9D
>>> The contribution introduces L4S to the SA2 audience and explains =
where the
>> technology is useful. The contribution also proposes a method to bake =
L4S into
>> the 5G QoS framework.
>>> If agenda time permits, it will be discussed at the SA WG2 meeting =
in Reno on
>> Nov 18-22, hopefully with good results.
>>>=20
>>> Also a RAN2 contribution was submitted and discussed at an earlier =
RAN2
>> meeting.
>>> =
https://protect2.fireeye.com/v1/url?k=3D06eb4ef7-5a62e13e-06eb0e6c-0cc47
>>> ad93e1c-f387514c9f633599&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>> 22955dec7b38&u=3D
>>>=20
>> https%3A%2F%2Fwww.3gpp.org%2Fftp%2FTSG_RAN%2FWG2_RL2%2FTSGR2_1
>> 07bis%2F
>>> Docs%2FR2-1913888.zip
>>>=20
>>> Enjoy
>>> /Ingemar
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>>> Ingemar Johansson  M.Sc.
>>> Master Researcher
>>>=20
>>> Ericsson Research
>>> Network Protocols & E2E Performance
>>> Labratoriegr=C3=A4nd 11
>>> 971 28, Lule=C3=A5, Sweden
>>> Phone +46-1071 43042
>>> SMS/MMS +46-73 078 3289
>>> ingemar.s.johansson@ericsson.com
>>> www.ericsson.com
>>>=20
>>>      The best way to find out if you
>>>  can trust somebody is to trust them
>>>              Ernest Hemingway
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20


From nobody Sat Nov  9 12:44:34 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 C0A26120048; Sat,  9 Nov 2019 12:44:16 -0800 (PST)
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 KD09rwCXnQfi; Sat,  9 Nov 2019 12:44:15 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 DAD3412008D; Sat,  9 Nov 2019 12:44:14 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id q28so7024976lfa.5; Sat, 09 Nov 2019 12:44:14 -0800 (PST)
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=sh2yQbNzj4HuD8f+eF/rGZTgQrRfp2sFos1Bfv/bf3k=; b=UnwJm5oHA82BbgSH953CbKK82E6ij8iqUkAfkOKAbgCrVsvssbU9gMHXrI6164lEHd P0KsagvV8tY19Ht/nx0hKcL2npwit/8Wf/1uXqj5bedoyjM9tJuT1gRBqr+8qI89O/19 fKzUPo49qk7f3k4Fcg9y7n0eVbcf9McOKStXBzdBhuzFwWgIZIpk/xFoXMrqkdFCb7E0 Gwrdti6Wz/TVXv/jpkNudiZaAhbNCpFdAw9jebZ++h78vLIsY+xKOoEjJ5lP5k17a77Z P6VyHohferYHnbPPoj1Rt9jq3vhrhb1+WShYJJP4ops1JoCd7bWAzyuFWD5t6DFyE7uW Heuw==
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=sh2yQbNzj4HuD8f+eF/rGZTgQrRfp2sFos1Bfv/bf3k=; b=l7sPzqDC5cUuCbifM+yJ/k1DhiItDwp2DL4ETAhJbpC1iGcfnMV/MhDlCayYkgO0/2 xSdiOvMqQelFSLSUxjiTKsfJwtaZiXqTIT8zqe+jLZgvLy/vc+nayTC+VTW0HY3iiJuP lsFeI/xJSWQfJmw2C7DAn3ygW9bOGWb2CH46m3DitFYoT8pSFJmaWVhEr8cogH666EAO 4EGuZHdEbC4pG1HzXIztk+ODSi1bGhf+Nhf9hR7iBuWIHUFUe/vqb6j39jHBIefaIr8z x38JZifldeXCz7GtxawL/SbEBmiIKyNajK+zERgXwPxLNMyb+zATJX+MubRl1lRYP+TV KjLA==
X-Gm-Message-State: APjAAAXpatbTHDhQ8UbUPsUoysQwvT24sZEyX8aZwmB9j5TAvJc4CFCo tiIu01PEAb/3lDXjoFMiths=
X-Google-Smtp-Source: APXvYqxTNm88RPgJDpvVohlGH+0fgJarePJcYoYH4lV/eUNpfRg0Ms5g5ti/0XscFJ7RRz1t9tqsFA==
X-Received: by 2002:ac2:51a3:: with SMTP id f3mr10858326lfk.38.1573332252630;  Sat, 09 Nov 2019 12:44:12 -0800 (PST)
Received: from jonathartonsmbp.lan (85-76-23-24-nat.elisa-mobile.fi. [85.76.23.24]) by smtp.gmail.com with ESMTPSA id g26sm4405628lfh.1.2019.11.09.12.44.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 12:44:12 -0800 (PST)
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: Sat, 9 Nov 2019 22:44:10 +0200
Cc: Ingemar Johansson S , "tcpm@ietf.org" , Ingemar Johansson S , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" , "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <96C87F7D-F4C5-422E-9836-79817F39C9CF@gmail.com>
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>  
To: Sebastian Moeller 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 20:44:17 -0000

> On 9 Nov, 2019, at 10:38 pm, Sebastian Moeller  =
wrote:
>=20
>> There are other promising features with L4S. One being that it can =
enable congestion control algorithms to quickly grab free capacity.
>=20
> 	[SM] When you say L4S, do you mean the congestion signaling? =
Then https://tools.ietf.org/html/draft-morton-taht-sce-00 should have =
you covered, without the nasty side-effects of the current L4S proposal. =
Or do you mean the actual congestion controller as implemented in TCP =
prague?=20

Nitpick: the correct reference is now =
https://tools.ietf.org/html/draft-morton-tsvwg-sce-01 and significantly =
updated relative to that old version.

 - Jonathan Morton


From nobody Sat Nov  9 14:45: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 C63601200E5; Sat,  9 Nov 2019 14:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 3tJ79KPgYKeu; Sat,  9 Nov 2019 14:45:10 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 C767A120058; Sat,  9 Nov 2019 14:45:10 -0800 (PST)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA9Mf8K9023040; Sat, 9 Nov 2019 22:44:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=f0O9DJsQkUu91qaxo6Qh8A/6tPqrPDoZg8Xqf3szttY=; b=GyhtiQyenPnTA/jOajyMz1lCwlXr8Mo7Wjh1yYHrWYyQyvwiE0ejzNxQQnVZgkoIMchC i5v0VkTQQiYHqwGSFkoxdhlG3CZFzL72gucJgsMt9e8qEonk4JtTm0enRAqszQySDpBR gRLGvsyfnB9l7hOTQ7HkaV1fd3FyWY+lttOGzYma3XPW27fBl7P5vfQ2uXdw03jf1OdG 66Y3g7Tmozobe/xCTH9fSzg9PIf8ew6TR75CNA0DS2A9gGNZ6wvvS1dyNwUzRuFtBSL5 D3fCcq5/hbHjAMOIlUHoxGiMeDrdrkMZXJn+FiHqui30V0J2ijPvbumDvfOU6V3zf1Yk Dg== 
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2w5p6djufw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 09 Nov 2019 22:44:57 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xA9MWjb1023915; Sat, 9 Nov 2019 17:44:56 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint4.akamai.com with ESMTP id 2w5sp2sjpv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 09 Nov 2019 17:44:56 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 14:44:55 -0800
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1473.005; Sat, 9 Nov 2019 16:44:55 -0600
From: "Holland, Jake" 
To: Ingemar Johansson S , Sebastian Moeller 
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , Ingemar Johansson S , "koen.de_schepper@nokia.com" 
Thread-Topic: [tsvwg] L4S related activity in 3GPP
Thread-Index: AQHVlyEOqflbeAGZskqQkrD3bd7kSaeDnOaA//+x64A=
Date: Sat, 9 Nov 2019 22:44:54 +0000
Message-ID: <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com>
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.80.233]
Content-Type: text/plain; charset="utf-8"
Content-ID: <46FEED6D1AD1464C949A3943206DFF0D@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-09_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=737 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911090231
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-09_09:2019-11-08,2019-11-09 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxscore=0 mlxlogscore=691 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911090232
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sat, 09 Nov 2019 22:45:12 -0000

T24gMjAxOS0xMS0wOSwgMTE6MjQsICJJbmdlbWFyIEpvaGFuc3NvbiBTIiA8aW5nZW1hci5zLmpv
aGFuc3Nvbj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+IE9uZSBiZWlu
ZyB0aGF0IGl0IGNhbiBlbmFibGUgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobXMgdG8NCj4g
cXVpY2tseSBncmFiIGZyZWUgY2FwYWNpdHkuIDVHIGFjY2VzcyBjYW4gaGF2ZSBsYXJnZSB2YXJp
YXRpb25zDQo+IGluIGxpbmsgdGhyb3VnaHB1dCBmb3IgZXhhbXBsZSByZWxhdGVkIHRvIGR1YWwg
Y29ubmVjdGl2aXR5IGFuZA0KPiBMNFMgY2FuIGJlIGhlbHBmdWwgaGVyZSBhcyB3ZWxsLg0KDQpI
aSBJbmdlbWFyLA0KDQpOb3Qgc3VyZSBob3cgY2xvc2VseSB5b3UndmUgYmVlbiBmb2xsb3dpbmcs
IGJ1dCB0aGUgTDRTIHRlYW0gcmVjZW50bHkNCnJlcG9ydGVkIGZpeGluZyBhIGJ1ZyBpbiB0aGVp
ciBpbXBsZW1lbnRhdGlvbiB0aGF0IG1pZ2h0IGNoYW5nZSB0aGlzDQpjb25jbHVzaW9uLCBhbmQg
eW91IHByb2JhYmx5IHNob3VsZCBiZSBhd2FyZSBvZiBpdCBpZiB0aGF0J3MgcGFydCBvZg0KdGhl
IGRyaXZlciBoZXJlLiAgU3BlY2lmaWNhbGx5IHRoZSBhbHBoYSB3YXMgc2V0IHRvIDEgaW5zdGVh
ZCBvZiAwLg0KaHR0cHM6Ly9sNHMuY2FibGVsYWJzLmNvbS8NCg0KQ2hhbmdpbmcgdGhpcyB0byBh
dm9pZCBzb21lIHByb2JsZW1hdGljIGJlaGF2aW9yIGFsc28gY2F1c2VzIGEgIG1vcmUNCmdyYWR1
YWwgdGhyb3VnaHB1dCByYW1wIGluc3RlYWQsIHNvIHlvdSBtaWdodCB3YW50IHRvIHJlLXRlc3Qg
eW91cg0KY29uY2x1c2lvbnMgYWJvdXQgaG93IGZhc3QgaXQgY2FuIGNvbnZlcmdlIG9uIHRoZSBm
bHVjdHVhdGluZyBjYXBhY2l0eQ0KYWZ0ZXIgdGhhdCBidWctZml4IGlzIGFwcGxpZWQuDQoNClRo
ZSBjaGFydHMgc2hvdyBzb21lIGV4YW1wbGUgZGlmZmVyZW5jZXMgb24gc3RhcnR1cCB0aHJvdWdo
cHV0IChhbG9uZw0Kd2l0aCB0aGUgcHJvYmxlbWF0aWMgUlRUIHJlc3BvbnNlIHRoYXQgd2FzIGZp
eGVkIGJ5IHRoaXMpLg0KDQpXaXRoIHRoZSBmaXg6DQpodHRwczovL2w0cy5jYWJsZWxhYnMuY29t
L2w0cy10ZXN0aW5nL2tleV9wbG90cy9iYXRjaC1sNHMtczYtMS1wcmFndWUtNTBNYml0LTgwbXNf
dmFyLnBuZw0KDQpXaXRob3V0IHRoZSBmaXg6DQpodHRwczovL2w0cy5jYWJsZWxhYnMuY29tL2w0
cy10ZXN0aW5nL2tleV9wbG90cy9iYXRjaC1sNHMtczYtcHJhZ3VlX2FscGhhLXByYWd1ZS01ME1i
aXQtODBtcy1hbHBoYTBfdmFyLnBuZw0KDQpDaGVlcnMgYW5kIEhUSCwNCkpha2UNCg0KDQo=


From nobody Sat Nov  9 15:06:09 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 5AC32120120; Sat,  9 Nov 2019 15:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 XLBG-XzxzgdU; Sat,  9 Nov 2019 15:06:00 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362D512006B; Sat,  9 Nov 2019 15:06:00 -0800 (PST)
Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 6314D21425; Sat,  9 Nov 2019 23:05:57 +0000 (UTC)
From: Dave Taht 
To: tsvwg IETF list , tcpm@ietf.org
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de>
Date: Sat, 09 Nov 2019 15:05:54 -0800
In-Reply-To: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> (Sebastian Moeller's message of "Sat, 9 Nov 2019 23:32:09 +0100")
Message-ID: <87mud4ejl9.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [tcpm] sce vs l4s comparison plots?
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: Sat, 09 Nov 2019 23:06:02 -0000

It is really wonderful to have these two groups using the
flent tool and producing comparable data on the same test suites in
a few cases now, and the testing so far found a couple bugs.

https://github.com/heistp/sce-l4s-bakeoff
https://l4s.cablelabs.com/

I do feel rather strongly that any major change to how the internet does
congestion control requires a maximum of publically repeatable
benchmarks using open, shared source code. [1]

I do keep hoping for a rrul test on a 15 to 20x1 asymmetric network
simulation like how most cablemodems and dsl boxes are configured, and
more of the rtt_fair_* tests, and what the heck - the tcp_square_wave
test, and any of a dozen others. tcp_nup with 32 flows... heck, hundreds
of flows... go to town! Burn some cycles!

A few packet caps would be nice to have also, to look
over relative mark rates in tcptrace and scetrace.

Anyway... l4steam....

In looking over the l4s.cablelabs site today though, I see the data is
only available as .png files, and that the associated flent.gz data
is not apparently being published.

.svgs help. Flent can also be run at a higher sample rate... but

There are a few things about having *.flent.gz files available that
would help us look at some things in more detail. Me, I tend to look at
comparison cdf plots more than anything else, and secondly bar plots,
and lacking that it's hard to make a distinction betwen a whole bunch of
tiny lines at the bottom about overall queue depths and latency
distributions, among other things, without squinting, and doing tricks
in photoshop to make the two or more datasets "line up".

(there's dozens of plot types in the flent tool, and comparison plots
are a snap)

By default (when run without -x) flent captures very little metadata
about the system it is run on (IP addresses, a couple sysctls, and
qdiscs) but it's helpful to have. One example that would be in that
metadata, is that I'm unsure if the ns3 data is using an IW4 or IW10?

It sounds like you are rate limiting with htb? (to what quantum?)

Another example, in more "native" environments running at a simulated
line rate, BQL is quite important to have in the simulation
also. there's been a couple papers published on BQL's benefits vs a raw
txring, thus far, there's a good plot of what it does in fig 6 of:

http://sci-hub.tw/10.1109/LANMAN.2019.8847054

Lastly...

So far as I know ns(X) does not correctly simulate GSO/TSO even when
run in DCE mode, but I could be out of date on that. TBF (and cake)
do break apart superpackets, htb (+ anything, like fq_codel or dualq)
do not.

I also have completely forgotten at this point, to what extent the
ns3 model of fq_codel matches the deployed reality. It was such a long
time ago.... as best as I recall ns3 didn't even have ecn support then!

I'm taking apart
https://gitlab.com/tomhend/modules/l4s-evaluation/blob/master/README.md
as I write.

thx for the data!

[1] If anyone hasn't read my related rant yet, it's here:
https://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf


From nobody Sat Nov  9 19:31:35 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 E361F1200FB; Sat,  9 Nov 2019 19:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7TZD8-1krbEI; Sat,  9 Nov 2019 19:31:26 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87DF1200F6; Sat,  9 Nov 2019 19:31:25 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAA3VNgZ027400; Sat, 9 Nov 2019 19:31:23 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAA3VNmp027399; Sat, 9 Nov 2019 19:31:23 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911100331.xAA3VNmp027399@gndrsh.dnsmgr.net>
In-Reply-To: <87mud4ejl9.fsf@taht.net>
To: Dave Taht 
Date: Sat, 9 Nov 2019 19:31:23 -0800 (PST)
CC: tsvwg IETF list , tcpm@ietf.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] sce vs l4s comparison plots?
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: Sun, 10 Nov 2019 03:31:28 -0000

Dave,
	Thank you for the links, some short responses inline.

Regards,
Rod

> 
> It is really wonderful to have these two groups using the
> flent tool and producing comparable data on the same test suites in
> a few cases now, and the testing so far found a couple bugs.
> 
> https://github.com/heistp/sce-l4s-bakeoff
> https://l4s.cablelabs.com/
> 
> I do feel rather strongly that any major change to how the internet does
> congestion control requires a maximum of publically repeatable
> benchmarks using open, shared source code. [1]
> 
> I do keep hoping for a rrul test on a 15 to 20x1 asymmetric network
> simulation like how most cablemodems and dsl boxes are configured, and
> more of the rtt_fair_* tests, and what the heck - the tcp_square_wave
> test, and any of a dozen others. tcp_nup with 32 flows... heck, hundreds
> of flows... go to town! Burn some cycles!

I believe Pete has some work scheduled for the (near?) future
in this area.

> 
> A few packet caps would be nice to have also, to look
> over relative mark rates in tcptrace and scetrace.
I do believe all you seek for Petes data is there,
https://github.com/heistp/sce-l4s-bakeoff/#test-output
specifically items:
*.flent.gz- standard Flent output file, may be used to view original data or re-generate plots
*.tcpdump_*.pcap.bz2- pcap file compressed with bzip2 -9

> 
> Anyway... l4steam....
> 
> In looking over the l4s.cablelabs site today though, I see the data is
> only available as .png files, and that the associated flent.gz data
> is not apparently being published.
> 
> ..svgs help. Flent can also be run at a higher sample rate... but
> 
> There are a few things about having *.flent.gz files available that
> would help us look at some things in more detail. Me, I tend to look at
> comparison cdf plots more than anything else, and secondly bar plots,
> and lacking that it's hard to make a distinction betwen a whole bunch of
> tiny lines at the bottom about overall queue depths and latency
> distributions, among other things, without squinting, and doing tricks
> in photoshop to make the two or more datasets "line up".
> 
> (there's dozens of plot types in the flent tool, and comparison plots
> are a snap)
> 
> By default (when run without -x) flent captures very little metadata
> about the system it is run on (IP addresses, a couple sysctls, and
> qdiscs) but it's helpful to have. One example that would be in that
> metadata, is that I'm unsure if the ns3 data is using an IW4 or IW10?
> 
> It sounds like you are rate limiting with htb? (to what quantum?)
> 
> Another example, in more "native" environments running at a simulated
> line rate, BQL is quite important to have in the simulation
> also. there's been a couple papers published on BQL's benefits vs a raw
> txring, thus far, there's a good plot of what it does in fig 6 of:
> 
> http://sci-hub.tw/10.1109/LANMAN.2019.8847054
> 
> Lastly...
> 
> So far as I know ns(X) does not correctly simulate GSO/TSO even when
> run in DCE mode, but I could be out of date on that. TBF (and cake)
> do break apart superpackets, htb (+ anything, like fq_codel or dualq)
> do not.
> 
> I also have completely forgotten at this point, to what extent the
> ns3 model of fq_codel matches the deployed reality. It was such a long
> time ago.... as best as I recall ns3 didn't even have ecn support then!

And apparently is still missing some ECN (RFC3168) support as your
following link contains some patches:
	6.  cd back one level to the top-level ns-3 directory,
	and patch the ns-3.30.1 release with a patch provided
	in the l4s-evaluation/patches/ directory. This patch
	adds support for ECE handling and DCTCP in the base
	TCP code, and adds ECN handling to CoDel and FqCoDel models.

> 
> I'm taking apart
> https://gitlab.com/tomhend/modules/l4s-evaluation/blob/master/README.md
> as I write.
> 
> thx for the data!
> 
> [1] If anyone hasn't read my related rant yet, it's here:
> https://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Sat Nov  9 20:50:13 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 820DE1200E9; Sat,  9 Nov 2019 20:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 jFWaoMZo0yYn; Sat,  9 Nov 2019 20:50:09 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08333120018; Sat,  9 Nov 2019 20:50:09 -0800 (PST)
Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 9CF6922275; Sun, 10 Nov 2019 04:50:05 +0000 (UTC)
From: Dave Taht 
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg IETF list ,  tcpm@ietf.org
References: <201911100331.xAA3VNmp027399@gndrsh.dnsmgr.net>
Date: Sat, 09 Nov 2019 20:50:02 -0800
In-Reply-To: <201911100331.xAA3VNmp027399@gndrsh.dnsmgr.net> (Rodney W. Grimes's message of "Sat, 9 Nov 2019 19:31:23 -0800 (PST)")
Message-ID: <87v9rs1gjp.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] sce vs l4s comparison plots?
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: Sun, 10 Nov 2019 04:50:11 -0000

"Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> writes:

> Dave,
> 	Thank you for the links, some short responses inline.

I did a bit more data review of the l4s data today.

https://l4s.cablelabs.com/results/6-dctcp-20191018-214743/6-dctcp_25_50Mbps_0.95_0ms.pdf

has an interesting growth line in the middle series of charts.

Two anecdotes: 1) arguably the internet is so messed up because everyone
has optimized for speedtest's 20s test run rather than a longer
period. 2) I lost much hair to this maddening one: http://blog.cerowrt.org/post/disabling_channel_scans/

It would be good to have a test that also ran for more than a minute,
say 5, or 10, so that a global trend be seen.


>
> Regards,
> Rod
>
>> 
>> It is really wonderful to have these two groups using the
>> flent tool and producing comparable data on the same test suites in
>> a few cases now, and the testing so far found a couple bugs.
>> 
>> https://github.com/heistp/sce-l4s-bakeoff
>> https://l4s.cablelabs.com/
>> 
>> I do feel rather strongly that any major change to how the internet does
>> congestion control requires a maximum of publically repeatable
>> benchmarks using open, shared source code. [1]
>> 
>> I do keep hoping for a rrul test on a 15 to 20x1 asymmetric network
>> simulation like how most cablemodems and dsl boxes are configured, and
>> more of the rtt_fair_* tests, and what the heck - the tcp_square_wave
>> test, and any of a dozen others. tcp_nup with 32 flows... heck, hundreds
>> of flows... go to town! Burn some cycles!
>
> I believe Pete has some work scheduled for the (near?) future
> in this area.

I will sleep so much better about both proposals once a rrul test
is run, and then from there accecn can be better evaluated.

thx everybody for your efforts on this!

>> 
>> A few packet caps would be nice to have also, to look
>> over relative mark rates in tcptrace and scetrace.
> I do believe all you seek for Petes data is there,
> https://github.com/heistp/sce-l4s-bakeoff/#test-output
> specifically items:
> *.flent.gz- standard Flent output file, may be used to view original data or re-generate plots
> *.tcpdump_*.pcap.bz2- pcap file compressed with bzip2 -9

Groovy. Don't stop doing that. ;)

>> 
>> Anyway... l4steam....
>> 
>> In looking over the l4s.cablelabs site today though, I see the data is
>> only available as .png files, and that the associated flent.gz data
>> is not apparently being published.
>> 
>> ..svgs help. Flent can also be run at a higher sample rate... but
>> 
>> There are a few things about having *.flent.gz files available that
>> would help us look at some things in more detail. Me, I tend to look at
>> comparison cdf plots more than anything else, and secondly bar plots,
>> and lacking that it's hard to make a distinction betwen a whole bunch of
>> tiny lines at the bottom about overall queue depths and latency
>> distributions, among other things, without squinting, and doing tricks
>> in photoshop to make the two or more datasets "line up".
>> 
>> (there's dozens of plot types in the flent tool, and comparison plots
>> are a snap)
>> 
>> By default (when run without -x) flent captures very little metadata
>> about the system it is run on (IP addresses, a couple sysctls, and
>> qdiscs) but it's helpful to have. One example that would be in that
>> metadata, is that I'm unsure if the ns3 data is using an IW4 or IW10?
>> 
>> It sounds like you are rate limiting with htb? (to what quantum?)

?

>> 
>> Another example, in more "native" environments running at a simulated
>> line rate, BQL is quite important to have in the simulation

?

>> also. there's been a couple papers published on BQL's benefits vs a raw
>> txring, thus far, there's a good plot of what it does in fig 6 of:

>> 
>> http://sci-hub.tw/10.1109/LANMAN.2019.8847054
>> 
>> Lastly...
>> 
>> So far as I know ns(X) does not correctly simulate GSO/TSO even when
>> run in DCE mode, but I could be out of date on that. TBF (and cake)

?

>> do break apart superpackets, htb (+ anything, like fq_codel or dualq)
>> do not.
>> 
>> I also have completely forgotten at this point, to what extent the
>> ns3 model of fq_codel matches the deployed reality. It was such a long
>> time ago.... as best as I recall ns3 didn't even have ecn support then!

I looked over the ns3 fq_codel implementation, and (by mark one eyeball)
it appears largely correct - nowadays we increase the codel count in the
bulk dropper, but unless there's a specific flooding test (?) in the
suite, we're not going to hit that. Might be able to fix that once I get
used to writing OOP again.

More important to verify is the actual endpoint setup in the experiment
to make sure a real 5 tuple is in use....

The ns3 codel code matches the linux implementation, also.

I'd still have to spin up the test suite to actually trust it, and
I was (2012) pretty sure the cubic implementation differed
significantly from linuxes. 

> And apparently is still missing some ECN (RFC3168) support as your
> following link contains some patches:
> 	6.  cd back one level to the top-level ns-3 directory,
> 	and patch the ns-3.30.1 release with a patch provided
> 	in the l4s-evaluation/patches/ directory. This patch
> 	adds support for ECE handling and DCTCP in the base
> 	TCP code, and adds ECN handling to CoDel and FqCoDel models.

Well, I am *happy* to see it was the current release of ns3 + a little
bit. That's a relief.

That said - oy - um, er - this being the first ever use of ECN in
ns3 requires quite a bit of validation. From a quick look at this patch,
simply off the top of my head - it doesn't follow rfc3168's
recommendation in section

6.1.5.  Retransmitted TCP packets

"This document specifies ECN-capable TCP implementations MUST NOT set
   either ECT codepoint (ECT(0) or ECT(1)) in the IP header for
   retransmitted data packets, and that the TCP data receiver SHOULD
   ignore the ECN field on arriving data packets that are outside of the
   receiver's current window.  "...

I think (need to look harder)

... as much as some folk here would like to obsolete that, linux does
actually follow this portion of the spec (I don't know about other OSes)
, and it has long been one of my concerns regarding l4s (and cake's)
interactions with loss and flipping between queues in general.


>
>> 
>> I'm taking apart
>> https://gitlab.com/tomhend/modules/l4s-evaluation/blob/master/README.md
>> as I write.
>> 
>> thx for the data!
>> 
>> [1] If anyone hasn't read my related rant yet, it's here:
>> https://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>> 


From nobody Sun Nov 10 02:02: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 971E81200BA; Sun, 10 Nov 2019 02:02:47 -0800 (PST)
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=unavailable 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 kRBvVo49o5fY; Sun, 10 Nov 2019 02:02:44 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20089.outbound.protection.outlook.com [40.107.2.89]) (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 7C25312004A; Sun, 10 Nov 2019 02:02:43 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IIJp37Svc393/RkEQM1MD53vKRTW9BtYt0oFwhm98iL0jHjKxuO/6UU60KAzrN69ZNHzzJy+he1RUhNzdUK/gSLasnTKeEHhBmWt3GliG4TAjttM2jJvy6Rz6C53N+XeYbvIl2WWFheD8cFQS2Nb0mZ8oMZX0n2lzkYK/k+6gK74a+tSf7xqWRq8mAW+rgeJ7Lz/wOhzEzZxyLEz1/z0/krnLHXlE5ZjRmZbWTfqtrpuzCk9ow879LKT6NyvIASDa/+UX47H4NLxbtESDsQentiNIU0JxxRj881CMqkyerlgH2NsxmAMgvlGZUdsGzVfDo9vKUoS08B/M22VF+NN+g==
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=C8EeGABfP3UYlS+R2o02syIxNp/MwE+7hduyDntyJGE=; b=P8lCF6zfYH0L2yN1eGYFTQEQv0lzEarCBvblcT4xGMoueJA866T0Oisa5cKfOqnioNXUV8ae03ClS8LmUW7GytwkRAeNyZWaEogfrDsWzBchwvo3E842IabltTkPNOQg5Iftr++SoLgf+JZzP29KuFSULColUXDvn41qaKzmdP0e7tgmk6NogxmU0HKlpjlhCJk7+joC+NyInDg6vAmHEh/iq1uPmkTvSgmkJxjMX5p7zHfjTfE5DCJm4qfwdfKbHnidAb7Rbs85AbSL2DHwHeq3jqaq0AOvGlavXV6otP2HxBQPcX3gmcM4+yjGKL5eBUUwtoMoqVN8LcAM+4sHLg==
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=C8EeGABfP3UYlS+R2o02syIxNp/MwE+7hduyDntyJGE=; b=l+rX+/lk8xg4NE6AzmqQL7QTBAHvL9enWdsxgflTpWwA37npE0V+ywcJ3cirvUDzvoKclUbX7C+H6Ew9oh8uEmvsQg8jn+WC4tPd9Ps0ulvK486KMgVCc62FlUiFqNIiw9/hD8shBvJl0df22tVb4/xiiIppLRPf0/UeYFlKKYI=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB4411.eurprd07.prod.outlook.com (20.176.166.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.16; Sun, 10 Nov 2019 10:02:40 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.018; Sun, 10 Nov 2019 10:02:40 +0000
From: Ingemar Johansson S 
To: "Holland, Jake" , Ingemar Johansson S , Sebastian Moeller 
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" , Ingemar Johansson S 
Thread-Topic: [tsvwg] L4S related activity in 3GPP
Thread-Index: AdWXFU/rHJiyQelDTIOgP97lGH/97gAC6dQAAAPywbAAB6LgAAAVekJg
Date: Sun, 10 Nov 2019 10:02:40 +0000
Message-ID: 
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>  <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com>
In-Reply-To: <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b2fbe34b-b331-4017-6dae-08d765c51f3a
x-ms-traffictypediagnostic: HE1PR07MB4411:|HE1PR07MB4411:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:3276;
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(376002)(366004)(13464003)(189003)(199004)(6116002)(3846002)(2906002)(6436002)(8936002)(81156014)(8676002)(81166006)(229853002)(66446008)(64756008)(99286004)(76116006)(316002)(110136005)(54906003)(107886003)(6246003)(66946007)(52536014)(5660300002)(99936001)(66556008)(66616009)(66476007)(33656002)(966005)(14454004)(478600001)(7696005)(76176011)(4326008)(66066001)(71200400001)(71190400001)(14444005)(256004)(25786009)(9686003)(11346002)(446003)(86362001)(6306002)(74316002)(305945005)(486006)(55016002)(476003)(7736002)(186003)(102836004)(26005)(6506007)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4411; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: DUlQYtRVlmptuGzLJvVLtzZQVJZ7bJ1/DJZl5Lj5nZVsp0Dk8F3zULkg2O1JzgUtfpxoIg+LLJPwux0dGq8TKtck4qSdwYCDeZGafT3Pm+XX9GbyqkSmPbylk0KmZuVIe4J4CiNamp1vP28yjfHSv7kUDiezpFmhgSd1OHVMuhQrb8KCtzH3lMEtpuljuycU1odBD8KmZN27TDyvM3Ihj7PTYsUIApyX4GbBK9YKOqoEyZMPDOPxvXcaYpiliZzx1fIZd5GFPiPo9wfzdAhGgGmPNt8hj9Xzd364JhAoNp99PCAPoaqLEPWK4QLrZt2BuklMdbRUNA3zqUQEapAkt2uVE5Ytsy2k1v1kc5JXZ3lUYq34qAK02aOWo4XaH3OkQLAwtNbqQWCSQENNBDAZfHosc3sqgjFZEFysjIs3NKUPMTv3VnSw2hUfXcKRmenF
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0111_01D597B6.5DBC20F0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b2fbe34b-b331-4017-6dae-08d765c51f3a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2019 10:02:40.2270 (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: mlnrzD1fFXcoT5Uk77xX2VbDga1WaGdbALUtfOljvITS0/BGosqzI7T+VXbLdTFLum8F4vXY9adg+Z7GeXLaXNoxymlODE1uaXTATqMfQNKTW/ca/VnVCW5Bm+WuIzse
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4411
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sun, 10 Nov 2019 10:02:48 -0000

------=_NextPart_000_0111_01D597B6.5DBC20F0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi Jake, please see inline

> -----Original Message-----
> From: Holland, Jake 
> Sent: den 9 november 2019 23:45
> To: Ingemar Johansson S
> ; Sebastian Moeller
> 
> Cc: tcpm@ietf.org; tsvwg@ietf.org; iccrg@irtf.org; Ingemar Johansson S
> ; koen.de_schepper@nokia.com
> Subject: Re: [tsvwg] L4S related activity in 3GPP
>
> On 2019-11-09, 11:24, "Ingemar Johansson S"
>  wrote:
> > One being that it can enable congestion control algorithms to quickly
> > grab free capacity. 5G access can have large variations in link
> > throughput for example related to dual connectivity and L4S can be
> > helpful here as well.
>
> Hi Ingemar,
>
> Not sure how closely you've been following, but the L4S team recently 
> reported
> fixing a bug in their implementation that might change this conclusion, and 
> you
> probably should be aware of it if that's part of the driver here. 
> Specifically the
> alpha was set to 1 instead of 0.
> https://protect2.fireeye.com/v1/url?k=5f1e4a97-03ca43f1-5f1e0a0c-
> 8610d8a762ca-aeefb3a777d636fc&q=1&e=e1f0f0ad-9613-4463-9a7f-
> a3b14a2b8481&u=https%3A%2F%2Fl4s.cablelabs.com%2F
>
[IJ] That is the initial alpha and AFAIK, alpha is used in a similar way to 
how it is used with DCTCP. i.e. dictates how much CWND is reduced on CE marks. 
It does therefore not affect the ramp-up when more capacity becomes available
https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c


> Changing this to avoid some problematic behavior also causes a  more gradual
> throughput ramp instead, so you might want to re-test your conclusions about
> how fast it can converge on the fluctuating capacity after that bug-fix is 
> applied.
>
> The charts show some example differences on startup throughput (along with
> the problematic RTT response that was fixed by this).
>
> With the fix:
> https://protect2.fireeye.com/v1/url?k=6f13dc09-33c7d56f-6f139c92-
> 8610d8a762ca-a748163f08dce827&q=1&e=e1f0f0ad-9613-4463-9a7f-
> a3b14a2b8481&u=https%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> testing%2Fkey_plots%2Fbatch-l4s-s6-1-prague-50Mbit-80ms_var.png
>
> Without the fix:
> https://protect2.fireeye.com/v1/url?k=5bfc2d0a-0728246c-5bfc6d91-
> 8610d8a762ca-05cd77703d5d8069&q=1&e=e1f0f0ad-9613-4463-9a7f-
> a3b14a2b8481&u=https%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> testing%2Fkey_plots%2Fbatch-l4s-s6-prague_alpha-prague-50Mbit-80ms-
> alpha0_var.png
[IJ] This looks like the normal exit from slowstart to me. With an initial 
alpha=1.0 the congestion window is reduced by 50%, whereas in the initial 
alpha=0.0 it takes a few round trips for alpha to increase sufficiently to 
reduce the congestion window. In the alpha=1.0 the congestion controls enter 
congestion avoidance and Additive Increase applies. I see that the current TCP 
Prague code does not implement the novel paced chirping (please correct) and 
that can change the behavior a lot.

>
> Cheers and HTH,
> Jake
>


------=_NextPart_000_0111_01D597B6.5DBC20F0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMTAxMDAyMzhaMCMGCSqGSIb3DQEJBDEWBBQjscl3g8D1+57wEgJD
F55E5BHkwjBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAFZIy05gMZtTiCII3tVDV/DNDOFFUgbAQPIG80vh
1cqHN4J46xIAqKXolIsBR33jIi+POhH5AC5h8O6eXTLVSj4TWfp0MFB3EXNprX9nvrZ5xBD9sIVu
ssB8+FGL8BUQPCOfmaqOk6LglYCTBJPc0UftOdFoeIqtL4dRGCvBQXBsv39aiZrmQj5x5LxjWR4I
fmoJQEMYWCqnRBp4vEtlOUPXTnOrPzJfbl6eNX0gGFI+F6O3Ubsyq1OBBdGfr1qJixihAvSvLqFg
5eyEywMz5U0Xlvkb+vr0iCK8VdvdXT+BLPhq/WGIFI3Zwu/A5/1KDEmFYQul+4jxdTjcjWIPivsA
AAAAAAA=

------=_NextPart_000_0111_01D597B6.5DBC20F0--


From nobody Sun Nov 10 02:20: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 BA1381200F3; Sun, 10 Nov 2019 02:20:19 -0800 (PST)
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=unavailable 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 S3l1bLx_kouE; Sun, 10 Nov 2019 02:20:15 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30052.outbound.protection.outlook.com [40.107.3.52]) (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 38D4F120074; Sun, 10 Nov 2019 02:20:14 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VrDfanPPKNDv/gE1uFgWKOW55xmyLMEfLquSC/29VJMPMoO/7vyyNmdYsZafqcuk6W5WynAlD1LFZyPVDpXM4rMAxtkqAiIXxENOk9WV85izO1vWxP9mgPWAzAT0oF0s73tFBl9J90RZYeOwA/v1jWStKqlWJvVYAXarIiwQhzGYFCRQWKMfC2AlBe9vVMKVQsNvIg+obSWTBQ/Nliiif9zMFB+ak9Vs2h7H+Z23VpckrahhXpQFP9EM9F5DssY5NXiTySgn5lwO2t71PRp+Zg7ry2z3ls48DEn5MWlrffPUmynx9GvHOhtvuglLJsNM/WB/btgLcJ+1QcR5dxnJDg==
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=yxN4samY/Z4yc6tVdiaZrdYHglIcl+8m0uAFs/ixGek=; b=TN6wB/T1BgYqXc1U1FDxsYFVh7yR+Mr1AAfq9FPLEkyaV2X0lnARTciGpj/gkwwd2uDfRRp9uNImz5h7mQSi+SKKpx75MMG0wQd0Hqd8kLvroBv994Z6YuuQ3KGL2TyMeZnh7CdUwxICakkUwV+lKnD0NvTOsclc01ledsqMujVnFZSD97ELpN8HAntpliRNeXUCXI15U7SlbXGyd0IUIieHmHGlFbrS1vzC5IzEI1WlrwBlpd1RuIVXjlrZArYJ264IWbpfIsnym+hVWsyoHpNk6iyj3kJvD7D2gKeWBbtLoVwLpoEJDCaCaQ666K2820qTEJbaZLbKFYBP0UT/lw==
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=yxN4samY/Z4yc6tVdiaZrdYHglIcl+8m0uAFs/ixGek=; b=I/pyXSDX1vkzHx8yAy1Dn/tAHmfrqzbRm0funLDqXERyKt56s+j132RrQMn4iYuW/0GhF0MgavF8RsF/EzMuCZP2WDGYSAc+gRk1s8b1g0xYm+coX89IMGpprplE/FIrwDFPC9jpBn1QMAIxUbDRMh1FRGr/V+HDFZzPrzryBIM=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3083.eurprd07.prod.outlook.com (10.170.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.16; Sun, 10 Nov 2019 10:20:12 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.018; Sun, 10 Nov 2019 10:20:12 +0000
From: Ingemar Johansson S 
To: Sebastian Moeller 
CC: Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" , "Bob Briscoe (ietf@bobbriscoe.net)" , Ingemar Johansson S 
Thread-Topic: [tsvwg] L4S related activity in 3GPP
Thread-Index: AdWXFU/rHJiyQelDTIOgP97lGH/97gAC6dQAAAPywbAAAzRNAAAcmkTA
Date: Sun, 10 Nov 2019 10:20:11 +0000
Message-ID: 
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8aa7e8b6-4eab-4247-91a1-08d765c79226
x-ms-traffictypediagnostic: HE1PR07MB3083:|HE1PR07MB3083:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(189003)(199004)(13464003)(66946007)(14444005)(64756008)(11346002)(66556008)(66616009)(66476007)(66446008)(6116002)(71200400001)(71190400001)(446003)(229853002)(256004)(55016002)(6436002)(476003)(30864003)(6306002)(478600001)(3846002)(4326008)(52536014)(76116006)(9686003)(86362001)(305945005)(25786009)(486006)(966005)(76176011)(316002)(7736002)(6916009)(81166006)(2906002)(107886003)(186003)(33656002)(81156014)(99936001)(74316002)(8936002)(66574012)(8676002)(15974865002)(54906003)(99286004)(102836004)(53546011)(6506007)(14454004)(5660300002)(6246003)(66066001)(561944003)(7696005)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3083; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: O9Lb11T/Jm2KdfBqwK1TYVgmZpmUC4D/1AGdXiSerUlLo+qOLzCQNqzmTfWcC8ltxG5PCdRkW7jWwm0yIYetPVZs7JytQsT+IiTFpVnXnxQNGoFz5vUYF5L5iKqPkfraZsX7IfPnx78fOxSpGWhNLiECafQ35gpsK7AIvg0O7IJeTfXfc+jy6VPTilaqef3yJ0pJI8dQWF6zL8/g1rTaK33+ZA7klgzFZvtSRt77BO8ZvUui91hCiwRqXiOjM7og1+wLTjgCnUcBrp2rsGyxGMXvmdpBOv8mobsKwFoaIxgy2XOnvVdgWWrzBwwCIA2DZDmDs2Xv8FyryvRelg37p6dJa3Dnf7Sl10+69N5Fce15bODbc6SewTi+IOhKt1hD8+yw5e6FJ+j5pgMi5uAICKSjefQTWQLvGxOhFMExWonT2P2UATB2WdTcp4NnQ5u3
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011A_01D597B8.D0AFB390"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8aa7e8b6-4eab-4247-91a1-08d765c79226
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2019 10:20:12.0083 (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: nMDEkez/G5XSLVZHMpY/zZqfY76s2a08ZLKIco/MBQRAn6I9ky8hira+M7wzfPaUZ+DCyRPVTdVtDgUgrWwQtuMQUTo8pAKLkErVzrhFztQzIrHsV20pEZ4/gZwvCq+P
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3083
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sun, 10 Nov 2019 10:20:20 -0000

------=_NextPart_000_011A_01D597B8.D0AFB390
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sebastian
Please see inline

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller 
> Sent: den 9 november 2019 21:38
> To: Ingemar Johansson S 
> Cc: Ingemar Johansson S
> ; tsvwg@ietf.org;
> tcpm@ietf.org; iccrg@irtf.org; koen.de_schepper@nokia.com; Bob Briscoe
> (ietf@bobbriscoe.net) 
> Subject: Re: [tsvwg] L4S related activity in 3GPP
>=20
> Dear Ingemar,
>=20
> more in-line below.
>=20
> > On Nov 9, 2019, at 20:24, Ingemar Johansson S
>  wrote:
> >
> > Hi Sebastian
> >
> > Please see inline below
> > /Ingemar
> >
> >> -----Original Message-----
> >> From: Sebastian Moeller 
> >> Sent: den 9 november 2019 18:13
> >> To: Ingemar Johansson S
> >> 
> >> Cc: tsvwg@ietf.org; tcpm@ietf.org; iccrg@irtf.org; Ingemar =
Johansson
> >> S ; koen.de_schepper@nokia.com
> >> Subject: Re: [tsvwg] L4S related activity in 3GPP
> >>
> >> Dear Ingemar,
> >>
> >> thanks for posting this. I read "This document describes an Active
> >> Queue Management mechanism, =E2=80=98L4S=E2=80=99, that can support =
low-latency
> >> services in a way that does not degrade the performance of other
> >> traffic." and I wonder whether 3GPP has run any experiments to
> >> confirm/support this claim, that you are willing to share?
> >
> > [IJ] We have done simulation studies with our proprietary 4G/5G =
system
> simulation tools but I can not disclose the results from these.
>=20
> 	[SM] Ah, I see, not posting internal data is fine, but by all means, =
go and
> perform real-world measurements as well with all the parts you =
actually want to
> roll-out (in other words testing with dctcp for example is =
scientifically
> interesting, unless you expect your users to actually use dctcp on =
your links).

[IJ] I hope to have data to show later on

>=20
>=20
> >>
> >> Sidenote: in the powerpoint file it says about L4s " Standardized =
in
> >> IETF [1]", which seems premature, in the process of being
> >> standardized seems a better description of the status quo...
> >
> > [IJ] Yes, you are right about this, it should have been "Subject to
> standardization..."
>=20
> 	[SM] Fair enough, as much as I regret to say it, standardization is =
quite
> likely.
>=20
> >
> >>
> >>
> >> I ask about test data from your side as the recent test data is =
quite
> >> sobering from a number of angles, including quality of isolation:
> >
> > [IJ] First of all the outline of the proposal for L4S in 5G is to =
use separate radio
> bearers for L4S and classic (or normal or non-L4S) traffic. This means =
that it is
> the 5G QoS framework and the scheduling in the RAN (Radio Access =
Network)
> that dictates the fairness.
>=20
> 	[SM] Sounds like a workable approach, that side steps the dualQ
> implementation/theory issues.

[IJ] The proposed approach for 5G is for practical reasons, we believe =
that it is more implementation and standardization friendly as it will =
utilize the existing QoS framework as much as possible.=20

>=20
>=20
> > But of course there are wireline transport link in the core network =
that may be
> using DualQ when that becomes commercially available. The bitrates =
over these
> links are however likely to be considerably higher than 50Mbps.
>=20
> 	That does not matter, the issue is not the limit of 50 Mbps, but the =
fact
> that dualQ, at last the current implementation in conjunction with the =
current
> TCP prague implementation, simply do not reliably and robustly do what =
the rfc
> draft claims. My fear is that dualQ, with its weak coupling vie =
marking
> probabilities, simply is a design, that only guarantees approximate =
fairness. In
> other words I doubt that dualQ works as a naive reading of the RFC =
implies. But
> if I  understood Bob correct, the only gurantee he is willing to give =
is L4S does
> not starve non-L4S traffic. Which IMHO is not sufficient to merit =
inflicting the
> L4S experiment on the wider internet. Now, that is not my call to =
make, but the
> IETF process allows me t voice my concerns, and I just use this =
opportunity in an
> attempt to minimize undesired side-effects on the "normal" internet.
>=20
> >
> >>
> >> 	Looking at the current L4S tests from the various testbeds I see
> >> severe breakdown of the promised isolation between bulk and the
> >> "low-latency" queue, apparently making the current implementation, =
if
> >> not the concept itself IMHO unfit for release into the wider
> >> internet, before these issues have been sufficiently addressed.
> >> Especially the observation that the weighted scheduler built in as =
a
> >> safety mechanism in the dualQ aqm seems to trigger considerably =
more
> >> often than expected/predicted from reading the dualQ draft (giving
> >> 1/16 of the bandwidth to on of two classes _might_ be justified as =
a
> >> temporary stop- gap measure in extremely unlikely cases, but this
> >> already triggers in a simple one-flow-per queue scenario at low =
RTTs). In
> short it currently looks like the "does not degrade performance of =
other traffic"
> part is not yet finished.
> >>
> >> 	To illustrate my criticism, here is a link to a test comparing the
> >> simplest functionality test imaginable, running one L4S-style and =
one
> >> non-L4S-style TCP connection through the L4S dual queue AQM at a
> >> intranet like RTT (nomnally 0ms, but in reality):
> >> https://protect2.fireeye.com/v1/url?k=3Dfcd5c73d-a05c68f4-fcd587a6-
> >> 0cc47ad93e1c-6acfac650abe7f09&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> >> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.p
> >> ng As can be seen the L4S flow (labeled prague) ends up very =
quickly
> >> taking ~90% of the available bandwidth, leaving only 10% to the
> >> non-L4S flow (labeled cubic), wit increasing RTT this bias gets =
less
> >> extreme, but even at 80ms the prague flow still gets around 1.5 =
times
> >> the bandwidth of the cubic flow
> >> =
(https://protect2.fireeye.com/v1/url?k=3D77272802-2bae87cb-77276899-
> >> 0cc47ad93e1c-56d0590db27309ef&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
> >> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-80ms_var.
> >> png), indicating an RTT dependent performance degradation for =
"other
> >> traffic". Test from another testbed confirm the break-down of
> >> fairness between L4S and non- L4S traffic at short RTTs
> >> (https://protect2.fireeye.com/v1/url?k=3D5710f0ef-
> >> 0b995f26-5710b074-0cc47ad93e1c-418920d155a62bf0&q=3D1&e=3D6cd6c372-
> >> b712-46be-8b10-
> >> 22955dec7b38&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-
> l4s-
> >> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s1-2%2Fbatch-l4s-s1-2-
> >> cubic-vs-prague-50Mbit-0ms_fixed.png).
> >
> > [IJ] I understand that the 0 RTT results can be because the =
congestion window
> is only a few segments large (my guess is ~3 to 4 segments ?). I know =
that this is
> a problem with e.g. DCTCP.  The question is whether this is a =
permanent
> problem or something that will be solved over time?.
>=20
> 	[SM] With DualQ, I assume it is a structural problem, instead of
> designing this as a robust system with two fair sharing queues it does =
its clever
> "indirect coupling" via marking/dropping probabilities. Have a look at
> https://protect2.fireeye.com/v1/url?k=3D53bd001b-0f37caa5-53bd4080-
> 869a17b5b21b-e4edb2934547a534&q=3D1&e=3D314d9ef9-5cc0-4c98-a599-
> 59f030e6cb2f&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-l4s-
> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s2-2%2Fbatch-l4s-s2-2-
> cubic-vs-prague-50Mbit-10ms_fixed.png for how sharing in a FQ system =
looks.
> Even with the leaky ECT(1) as classifier abuse it shoukd be simple to =
fair queue
> between EXT(1) and not ECH(1) flows and have robust separation. This =
is not
> rocket science, and mostly, as far as I can tell a solved problem.
>=20
> > What is more interesting to me and what makes L4S attractive for the =
use
> cases outlined in the 3GPP contributions, is the very low queue delay =
with L4S.
>=20
> 	[SM] Well, I believe low queueing delay can be achieved without dualQ
> and without abusing the ECT(1) codepoint as a classifier (the desired =
classifier
> requires one complete independent bit, ECT(1) is just 1/2 of a bit, =
and hence has
> failure modes in separating L4S-style flows and non-L4S flows). The =
idea of using
> the finer-grained congestion signaling of DCTCP over the wider =
internet seems
> sane see the SCE draft proposal as an alternative that would/will =
allow dctcp-
> style ECN signaling over the internet in a truly backward compatible =
fashion...
>=20
>=20
> > There are other promising features with L4S. One being that it can =
enable
> congestion control algorithms to quickly grab free capacity.
>=20
> 	[SM] When you say L4S, do you mean the congestion signaling? Then
> https://tools.ietf.org/html/draft-morton-taht-sce-00 should have you =
covered,
> without the nasty side-effects of the current L4S proposal. Or do you =
mean the
> actual congestion controller as implemented in TCP prague?
>=20
>=20
> > 5G access can have large variations in link throughput for example =
related to
> dual connectivity and L4S can be helpful here as well.
>=20
> 	[SM] Dealing better with variable rate links is certainly desirable, =
but I
> am not sure that DualQ/TCP Prague really are the best or only tools =
for that
> purpose. At least not until all of the kinks are ironed out. Again, =
none of this is
> my call to make, so all I am voicing is my educated subjective =
assessments.
>=20
>=20
> Best Regards
> 	Sebastian
>=20
> >
> >>
> >> 	Personally, I can not help thinking that it might be better to =
first
> >> make sure there is a complete, real-world tested implementation =
that
> >> reliably demonstrates that dualQ delivers the required isolation
> >> between the two traffic classes and that the L4S approach actually
> >> delivers the reported reliable low latency performance under =
adverse
> >> real-world conditions while not degrading the performance of other =
traffic,
> before trying to codify L4S into RFCs.
> >>
> >>
> >> Best Regards
> >> 	Sebastian
> >>
> >>
> >>> On Nov 9, 2019, at 17:00, Ingemar Johansson S
> >>  wrote:
> >>>
> >>> Gentlepeople!
> >>>
> >>> This 3GPP SA2 contribution is recently submitted
> >>> =
https://protect2.fireeye.com/v1/url?k=3D803d870e-dcb428c7-803dc795-0cc
> >>> 47
> >>> ad93e1c-77a60175f8460bc6&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3D
> >>>
> >>
> https%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FWG2_Arch%2FTSGS2_136
> >> _Reno%
> >>> 2FDocs%2FS2-1911250.zip Title =E2=80=9C5QI values for efficient =
handling of
> >>> congestion control marked IP packets=E2=80=9D
> >>> The contribution introduces L4S to the SA2 audience and explains
> >>> where the
> >> technology is useful. The contribution also proposes a method to =
bake
> >> L4S into the 5G QoS framework.
> >>> If agenda time permits, it will be discussed at the SA WG2 meeting
> >>> in Reno on
> >> Nov 18-22, hopefully with good results.
> >>>
> >>> Also a RAN2 contribution was submitted and discussed at an earlier
> >>> RAN2
> >> meeting.
> >>> =
https://protect2.fireeye.com/v1/url?k=3D06eb4ef7-5a62e13e-06eb0e6c-0cc
> >>> 47
> >>> ad93e1c-f387514c9f633599&q=3D1&e=3D6cd6c372-b712-46be-8b10-
> >> 22955dec7b38&u=3D
> >>>
> >>
> https%3A%2F%2Fwww.3gpp.org%2Fftp%2FTSG_RAN%2FWG2_RL2%2FTSGR2_1
> >> 07bis%2F
> >>> Docs%2FR2-1913888.zip
> >>>
> >>> Enjoy
> >>> /Ingemar
> >>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
> >>> Ingemar Johansson  M.Sc.
> >>> Master Researcher
> >>>
> >>> Ericsson Research
> >>> Network Protocols & E2E Performance
> >>> Labratoriegr=C3=A4nd 11
> >>> 971 28, Lule=C3=A5, Sweden
> >>> Phone +46-1071 43042
> >>> SMS/MMS +46-73 078 3289
> >>> ingemar.s.johansson@ericsson.com
> >>> www.ericsson.com
> >>>
> >>>      The best way to find out if you  can trust somebody is to =
trust
> >>> them
> >>>              Ernest Hemingway
> >>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> >


------=_NextPart_000_011A_01D597B8.D0AFB390
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMTAxMDIwMTBaMCMGCSqGSIb3DQEJBDEWBBQGiRuN/d7VXVOWUxWl
Bcr+rORrczBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAB6BoUaoETklirC9b6zQEDNPBVxkQfIqJUBbnVbQ
JE13USfkLv9r4IX/v1AoSOAYuv79zpP0eQrfDB+aoWUtmggaOiDzIq9nA4yZ0dyn3+lbKIqbZaHd
+GAcsUTFAhoEIsEmlxCw/EJqdHXxfcg3KKQe9fpuzmKGM28WktNDp1xYRHEVvN5oZSZCppkhSaYE
WOLvT0dF36KYQjNXcyxLDlcKRJyg2ZUlivXi5uo/46s0aS2xlzYcf25g1apwtGXIwsVTAA6eUX8v
H4AV+zeEw7t5XF9dcgF+WB0yPg3nJOatp90RnECmTQ2KwL8qNc9FNxVfM7gE1nb89gxaSURCZvIA
AAAAAAA=

------=_NextPart_000_011A_01D597B8.D0AFB390--


From nobody Sun Nov 10 02:46: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 CD3A612003E; Sun, 10 Nov 2019 02:46:13 -0800 (PST)
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 rLdUdDzIgJ4e; Sun, 10 Nov 2019 02:46:12 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 1BC3E1200BA; Sun, 10 Nov 2019 02:46:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573382757; bh=MQNXkE+7Erdo3+UgR8OuABz1iDI/SSmy65Re4hN/wHs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=LH3SkbI8UPS1ese4MLpYL54vmAReV8SrRu2Wno1xU+4A8fgBJ2nfYmFIp0s2KPmeM DMHFQ0t07PD1WZSDju6auZ5pVvgINm0Y7qNJBFZtY9NriKCfW3XqHECuPviPpd4/yS yNMBlyw8QBr9bheJVjGJSSkNc0AxbZoHeiYr7Wx4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.3.68.102]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MEm6L-1iiIec1Oah-00GLsH; Sun, 10 Nov 2019 11:45:57 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller 
In-Reply-To: 
Date: Sun, 10 Nov 2019 11:45:48 +0100
Cc: "Holland, Jake" , Ingemar Johansson S , "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <577095C3-EE27-40D6-9A8C-662DACEA1A5C@gmx.de>
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>  <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com> 
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:prLFeoF5c7/7T8S7lmCicN7UX3MjDpmGTOFYsZtQGxkh9HNAkSx l/JdH1P/EUQg6Du7/urSfm5eFhaoorW9cLzi6AOqrJeSdHuvTM60+o+HcgiqbrQxuJ4St8+ KtF6H+HVkEiOtIfpJB2lLL7gWVGe/xyEOXR3D76i3ksdFpYvu9PQHiz7qosj81gwPNSC1FO oRltcsejJuDipwBiLA9kw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:xl4psjJ1Ykw=:3s7R/CZRvhxM0bkjBARR/s 1P4pwJmIvmnCB4RcVgJaHOcEgtxrK26GjrrJid74sE5bgUJuf/F+CwZbY0GqcM46kKrbqKmn5 OsY86Za6Bm+wdzUNuA0Y8YBsLCmRNXwbqo+SAoww29kmx04roPd2ki7TmxPQ63GlFozCFYAP1 m9sQIXjxpoDtUD2QWFQE99HmGuep+WxHKa/1SPEjLNtiDm1JeoXGT1cUonHL7fxNCCCK6mz2L IRwp94sVwZdvCPQo36i+RiEuu4Zjf8DaKovxm913q0ovb4pz+pSi5P9NR6O7YImSgCgE8ow9G TAt5hiqJC1lmA3qNLg9ZHHPL4leo35asLd3rHBRRQH/LluFQHjGpHsEmJPWxKt2tAGMFVIYFV QF6wX9NNrIElf8tSZj2h8glV3s+HjY2ps9hpxTufucIP/FyUK/5LZQC+l9/QrVEwRsLVFrK8Q y2OiTCZTvAsSRKhrhlNvJ0wWHreMPuWuVCHI28MvKRsJBhyb3Ls6M81z7pyZe0WgZoQNoWmzw m7Xa05V8bvMWCXkCZxudTNtx0/2yYC23qx+e93At+jcVvq5Ssif2ATZ5NHxg8lvnfuo8uyt4S 7dpPILAHMFj5Qxr3w3ZfYmVyXHBUNqHtyGghi1/P0a1mvn00j5lPxrYm5KlK0ZXrn+aC6CaYu U/jd0rYKnf0jpdXdmWl6t6Yi0bgtwKaVIaw909jKmVsZT2WbRMq5l9W+yTOnPpppIfpNJyKjn TDFQAFb3dz9vZk5EeKXlvTxRdStKnFB25nuLAJL77yR9c7HDPAcmnmsERAvIm9ofeDKaIbEWD w8o/VeG4JpCtLox+GhOxJG4zgDxZngBtp3GCk0Ql0glPipxrBDh5Sl7LytuTMivOHXzuHQgQF 8bIe0lW6krEEMIkLz9DXxekWBj0z0WMDnMBktDVPnIBU3Xh85aeM//seadMANvY0oOTqQ2H8Q Ua0HXvwF2sXBR+4+v9AAPmXVG/7N7CgSj/vWOz2GWwV7hkDGdtErlZahyGapRwyEAMJHewxYP 3JHXbSHv7BrB8kjm+J1svbImTZWMboKY6DSe+MzkB0cGQIuFJUwBx9BPV7HaqNIm6n17F+ABn bnL9uQ8VXeSsJ3r/nhga1O3JXlDGyfm1lSvAhCKLwIcljsuCCf0RbUQAH2mvoJ2tUlxGorrq7 +t8ZcISQlLNe2k/Dq2iMhWauHbvVGJ00amr/PMXKfVRwLOAP2xSBUkuCFOjIVYakF4+m4+6Nm Yg1bnKxuu0CqGjxMBhBTIiuaLVkHK1Ugg+x5Ja1J4phb49ApgFJ3c++8CcNg=
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sun, 10 Nov 2019 10:46:14 -0000

> On Nov 10, 2019, at 11:02, Ingemar Johansson S =
 wrote:
>=20
> Hi Jake, please see inline
>=20
>> -----Original Message-----
>> From: Holland, Jake 
>> Sent: den 9 november 2019 23:45
>> To: Ingemar Johansson S
>> ; Sebastian =
Moeller
>> 
>> Cc: tcpm@ietf.org; tsvwg@ietf.org; iccrg@irtf.org; Ingemar Johansson =
S
>> ; koen.de_schepper@nokia.com
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>>=20
>> On 2019-11-09, 11:24, "Ingemar Johansson S"
>>  wrote:
>>> One being that it can enable congestion control algorithms to =
quickly
>>> grab free capacity. 5G access can have large variations in link
>>> throughput for example related to dual connectivity and L4S can be
>>> helpful here as well.
>>=20
>> Hi Ingemar,
>>=20
>> Not sure how closely you've been following, but the L4S team recently=20=

>> reported
>> fixing a bug in their implementation that might change this =
conclusion, and=20
>> you
>> probably should be aware of it if that's part of the driver here.=20
>> Specifically the
>> alpha was set to 1 instead of 0.
>> https://protect2.fireeye.com/v1/url?k=3D5f1e4a97-03ca43f1-5f1e0a0c-
>> 8610d8a762ca-aeefb3a777d636fc&q=3D1&e=3De1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2F
>>=20
> [IJ] That is the initial alpha and AFAIK, alpha is used in a similar =
way to=20
> how it is used with DCTCP. i.e. dictates how much CWND is reduced on =
CE marks.=20
> It does therefore not affect the ramp-up when more capacity becomes =
available
> https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c
>=20
>=20
>> Changing this to avoid some problematic behavior also causes a  more =
gradual
>> throughput ramp instead, so you might want to re-test your =
conclusions about
>> how fast it can converge on the fluctuating capacity after that =
bug-fix is=20
>> applied.
>>=20
>> The charts show some example differences on startup throughput (along =
with
>> the problematic RTT response that was fixed by this).
>>=20
>> With the fix:
>> https://protect2.fireeye.com/v1/url?k=3D6f13dc09-33c7d56f-6f139c92-
>> 8610d8a762ca-a748163f08dce827&q=3D1&e=3De1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> testing%2Fkey_plots%2Fbatch-l4s-s6-1-prague-50Mbit-80ms_var.png
>>=20
>> Without the fix:
>> https://protect2.fireeye.com/v1/url?k=3D5bfc2d0a-0728246c-5bfc6d91-
>> 8610d8a762ca-05cd77703d5d8069&q=3D1&e=3De1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> testing%2Fkey_plots%2Fbatch-l4s-s6-prague_alpha-prague-50Mbit-80ms-
>> alpha0_var.png
> [IJ] This looks like the normal exit from slowstart to me. With an =
initial=20
> alpha=3D1.0 the congestion window is reduced by 50%, whereas in the =
initial=20
> alpha=3D0.0 it takes a few round trips for alpha to increase =
sufficiently to=20
> reduce the congestion window. In the alpha=3D1.0 the congestion =
controls enter=20
> congestion avoidance and Additive Increase applies. I see that the =
current TCP=20
> Prague code does not implement the novel paced chirping (please =
correct) and=20
> that can change the behavior a lot.

	[SM] has any one actually tested paced chirping (PC) over =
real-life bonded links? As far as I can see PC pretty much relies on a) =
little to no re-ordering of packets (weird given that L4S also wants to =
allow larger re-ordering tolerance by recommending/mandating the use of =
RACK) and b) that the packet delivery time of each packet reflects a =
common path characteristic (which is less true for a bonded link).
	IMHO this just another piece of insufficiently tested technology =
thrown into the hodgepodge that is L4S. The way I see it, L4S combined a =
number of clever ideas, that might work out in reality, but might also =
be "too clever" for the internet.

Best Regards
	Sebastian


>=20
>>=20
>> Cheers and HTH,
>> Jake


From nobody Sun Nov 10 02:51:31 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 DECBD1200FA; Sun, 10 Nov 2019 02:51:21 -0800 (PST)
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 jFzr15uB0Fkq; Sun, 10 Nov 2019 02:51:19 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 3A5A01200E6; Sun, 10 Nov 2019 02:51:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573383030; bh=Gq4jc+TWm13sxAYCL8RBauEz+gpOlriIZZd6nKs5bok=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=BxjxlvWm7DcMoBHdttYHsUkVjYWDfuq8q4hy43anCQJBAPFFfK/N/LFGIguIH+rZm z8MDgGYfKqNf5AXdHkg1Cc72N05I2tlLYJ2BFR8TWMyzbBWVhOYZHNwzsYk3/ij7Sa F40CzJUb/9FltgCdFoR2YtGOS/sNtgentd5AL3yA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.3.68.102]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8XPn-1hpenE3lsv-014SBq; Sun, 10 Nov 2019 11:50:30 +0100
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: Sun, 10 Nov 2019 11:50:27 +0100
Cc: Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" , "Bob Briscoe (ietf@bobbriscoe.net)" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B7BF37B-18DB-429F-9B7E-1D87629B40C1@gmx.de>
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>   
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:rURuN/YPktGyBpt/9o+JHftR05B+ZCYItu0OsGXIPGb98cdMsKm 6hq6zcNu1e/l1v2+XGfNDSJuh6PJFy3tIXLNQmwLyPtbHjMkqsS3anRjH6y+SrNYrmZdMdf Wbs5La23TLsR7VtQzKUrGyQc1/Qzrt95FmQsSLxtuUjbW7Frk5SfOKt4QE6lKg1paEsouea ZTCOTc53ZraAtpstW7J3g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:qJFJDfFunLY=:7RhnYDVj3eRtyclsk4iPF+ WnrZYgfjSbALO58ak8IpcK8hloaFp876tYmbDt3FUj9ZHNywf7xIGw/A6srO2JM+4o6iIND+u W6kEYV7KxXL0ElQO/d+xtACfjX+Efiyv9QVMnZKOCcNZ+gAn1bbytT+PjzoAqBFgf+FLRVzxi kiAavZ8pigltiCi/6p5DBoRxqy4AhUBBbtBW+Aqa8CcigFx8WL/fpWG9LNxEfol79bLWPbKXO u4H65LxqD235G9by3sBUIBQv1WZeKxIL9Otsydvi+oTBT6wbk10PMwrgCjd8bSpUCNUla3XoL 6mTbtb1Fsy+Lwkle/TvorLMt2M4QU1LoFaLxntW3r+pvow6c4yIRJGWIUIhQrzcE/+ydo/jXA giDMof+S754DeTav66rLAT0FErR366aTj0md02e46TW68S4qJoyOQJhXoV8TMxgzReq6Tfe3U +pmhJOinbVSfg0/8vyiUr0GwProDZ1Ovmb8+YQ90k8VnDwFWo8d4hn2K/nlHGIsNtHMlr2o4P oHi9DPWCvRL1inQz9xzHJ4A+gEt5fuTTJQrBP1YLo5BbFUhgl2ga/hwp64xUzYMowV6WBP8at 7bzUKiZURatlQ6jNpjlDVYaQKHYD4YI1hxsLjukg43KFul2Dr6SOOyrLOKmv08mfRGdHA4sBD aGrgFTo+9Xxic5SDf+IfSmNU4/sz79lhEX8Eb/RTC22BBHKyBI5LJ1sGmM1xKkEXkIIUXwQ8t 4gZTAf9PT3EbJD1b82WcWBoZl3Ovp6TSjD9KymgFxChRzjn+BhTVAeSUqG5X1ZFEh+NBEINZk s6Sbq7VXCSfVQ3yP2Ub3iEgGfeap0JWontxxUsooqd2FJc4xwUz7PmAgfITOBvbf5OuHc725q rCXX0w1gio/zU7JfPJKtiBv5Tl3OclmdEQDoAx2UTtbqv2UUhFW2/NoKrza93QEHikPjcxrAo siIBwX83OBPDH4c88wgqidpPqBRSd7VdqjvcgIcm52S4jXzL8iXjZL7rMvtLsmYsa83AopTzW 6tHMTlANU+zSBewTws+6z3YvLHkVlFUsIZB+IGRx90bVKAopQjgddTPEF1+gSQa1N8SeArca7 DQMx2+WiMMzttzsFCKHOwp62pTN7vn9uIUuOb3DnaeY5Iz7ctPr31KjFmaKvAwP13LuIVqVP/ O3wt2+rkJYWfIcS3hjkIwsrGiOix2BBKGyGodkhaCViN1Aj8Z85jt0YzSsp/+Kqn/To3Ot/M8 s8BD/ebr0aYaJfhZo3hdtGed2NrRReJg9c3YEZg8kaiSsIcHgPpVwSS3n4dzE+Tv7nFDQMS8c B0b5Kt1fptrOEtpgPBfaIfIFauYm8DVA3OIeKfMyQ1hOjzaRQPJWhetTKjFdlWNxkIftoloof 1yIKRQfQ8I3zpDL0swhX3VPr9WxcmS7gaKYeWp+NcYHYI71xdAbowlwIm4ErEy76RgnUYczma oKUfNle9avLC+1+SkJyOICShtYRjkg48bZF+QfBJF8t7h+2k0owXn+lf4/XBiKyQ6rBSd384U dSQ==
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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: Sun, 10 Nov 2019 10:51:22 -0000

Hi Ingemar,


> On Nov 10, 2019, at 11:20, Ingemar Johansson S =
 wrote:
>=20
> Hi Sebastian
> Please see inline
>=20
> /Ingemar
>=20
>> -----Original Message-----
>> From: Sebastian Moeller 
>> Sent: den 9 november 2019 21:38
>> To: Ingemar Johansson S 
>> Cc: Ingemar Johansson S
>> ; =
tsvwg@ietf.org;
>> tcpm@ietf.org; iccrg@irtf.org; koen.de_schepper@nokia.com; Bob =
Briscoe
>> (ietf@bobbriscoe.net) 
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>>=20
>> Dear Ingemar,
>>=20
>> more in-line below.
>>=20
>>> On Nov 9, 2019, at 20:24, Ingemar Johansson S
>>  wrote:
>>>=20
>>> Hi Sebastian
>>>=20
>>> Please see inline below
>>> /Ingemar
>>>=20
>>>> -----Original Message-----
>>>> From: Sebastian Moeller 
>>>> Sent: den 9 november 2019 18:13
>>>> To: Ingemar Johansson S
>>>> 
>>>> Cc: tsvwg@ietf.org; tcpm@ietf.org; iccrg@irtf.org; Ingemar =
Johansson
>>>> S ; koen.de_schepper@nokia.com
>>>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>>>>=20
>>>> Dear Ingemar,
>>>>=20
>>>> thanks for posting this. I read "This document describes an Active
>>>> Queue Management mechanism, =E2=80=98L4S=E2=80=99, that can support =
low-latency
>>>> services in a way that does not degrade the performance of other
>>>> traffic." and I wonder whether 3GPP has run any experiments to
>>>> confirm/support this claim, that you are willing to share?
>>>=20
>>> [IJ] We have done simulation studies with our proprietary 4G/5G =
system
>> simulation tools but I can not disclose the results from these.
>>=20
>> 	[SM] Ah, I see, not posting internal data is fine, but by all =
means, go and
>> perform real-world measurements as well with all the parts you =
actually want to
>> roll-out (in other words testing with dctcp for example is =
scientifically
>> interesting, unless you expect your users to actually use dctcp on =
your links).
>=20
> [IJ] I hope to have data to show later on

	[SM] Excellent, looking forward to that.

>=20
>>=20
>>=20
>>>>=20
>>>> Sidenote: in the powerpoint file it says about L4s " Standardized =
in
>>>> IETF [1]", which seems premature, in the process of being
>>>> standardized seems a better description of the status quo...
>>>=20
>>> [IJ] Yes, you are right about this, it should have been "Subject to
>> standardization..."
>>=20
>> 	[SM] Fair enough, as much as I regret to say it, standardization =
is quite
>> likely.
>>=20
>>>=20
>>>>=20
>>>>=20
>>>> I ask about test data from your side as the recent test data is =
quite
>>>> sobering from a number of angles, including quality of isolation:
>>>=20
>>> [IJ] First of all the outline of the proposal for L4S in 5G is to =
use separate radio
>> bearers for L4S and classic (or normal or non-L4S) traffic. This =
means that it is
>> the 5G QoS framework and the scheduling in the RAN (Radio Access =
Network)
>> that dictates the fairness.
>>=20
>> 	[SM] Sounds like a workable approach, that side steps the dualQ
>> implementation/theory issues.
>=20
> [IJ] The proposed approach for 5G is for practical reasons, we believe =
that it is more implementation and standardization friendly as it will =
utilize the existing QoS framework as much as possible.=20

	[SM] Well, what ever the rationale, by avoiding the =
insufficiently isolating DualQ AQM you will save yourself from a number =
of headaches; I simply assume that you implement stricter airtime =
sharing between the two bearers than dualQ, and if you err you err on =
the side of conserving normal traffic (unlike DualQ's "L4S first" =
approach). But you still are saddled with L4S poor choice of ECT(1) as =
heuristic to separate L4S from non-L4S traffic. Calling that aETC(1) =
classifier seems plain wrong, as classifier implies strict separation.


Best Regards
	Sebastian


>=20
>>=20
>>=20
>>> But of course there are wireline transport link in the core network =
that may be
>> using DualQ when that becomes commercially available. The bitrates =
over these
>> links are however likely to be considerably higher than 50Mbps.
>>=20
>> 	That does not matter, the issue is not the limit of 50 Mbps, but =
the fact
>> that dualQ, at last the current implementation in conjunction with =
the current
>> TCP prague implementation, simply do not reliably and robustly do =
what the rfc
>> draft claims. My fear is that dualQ, with its weak coupling vie =
marking
>> probabilities, simply is a design, that only guarantees approximate =
fairness. In
>> other words I doubt that dualQ works as a naive reading of the RFC =
implies. But
>> if I  understood Bob correct, the only gurantee he is willing to give =
is L4S does
>> not starve non-L4S traffic. Which IMHO is not sufficient to merit =
inflicting the
>> L4S experiment on the wider internet. Now, that is not my call to =
make, but the
>> IETF process allows me t voice my concerns, and I just use this =
opportunity in an
>> attempt to minimize undesired side-effects on the "normal" internet.
>>=20
>>>=20
>>>>=20
>>>> 	Looking at the current L4S tests from the various testbeds I see
>>>> severe breakdown of the promised isolation between bulk and the
>>>> "low-latency" queue, apparently making the current implementation, =
if
>>>> not the concept itself IMHO unfit for release into the wider
>>>> internet, before these issues have been sufficiently addressed.
>>>> Especially the observation that the weighted scheduler built in as =
a
>>>> safety mechanism in the dualQ aqm seems to trigger considerably =
more
>>>> often than expected/predicted from reading the dualQ draft (giving
>>>> 1/16 of the bandwidth to on of two classes _might_ be justified as =
a
>>>> temporary stop- gap measure in extremely unlikely cases, but this
>>>> already triggers in a simple one-flow-per queue scenario at low =
RTTs). In
>> short it currently looks like the "does not degrade performance of =
other traffic"
>> part is not yet finished.
>>>>=20
>>>> 	To illustrate my criticism, here is a link to a test comparing =
the
>>>> simplest functionality test imaginable, running one L4S-style and =
one
>>>> non-L4S-style TCP connection through the L4S dual queue AQM at a
>>>> intranet like RTT (nomnally 0ms, but in reality):
>>>> https://protect2.fireeye.com/v1/url?k=3Dfcd5c73d-a05c68f4-fcd587a6-
>>>> 0cc47ad93e1c-6acfac650abe7f09&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>>>> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>>>> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.p
>>>> ng As can be seen the L4S flow (labeled prague) ends up very =
quickly
>>>> taking ~90% of the available bandwidth, leaving only 10% to the
>>>> non-L4S flow (labeled cubic), wit increasing RTT this bias gets =
less
>>>> extreme, but even at 80ms the prague flow still gets around 1.5 =
times
>>>> the bandwidth of the cubic flow
>>>> (https://protect2.fireeye.com/v1/url?k=3D77272802-2bae87cb-77276899-
>>>> 0cc47ad93e1c-56d0590db27309ef&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>>>> 22955dec7b38&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>>>> =
testing%2Fkey_plots%2Fbatch-l4s-s1-2-cubic-vs-prague-50Mbit-80ms_var.
>>>> png), indicating an RTT dependent performance degradation for =
"other
>>>> traffic". Test from another testbed confirm the break-down of
>>>> fairness between L4S and non- L4S traffic at short RTTs
>>>> (https://protect2.fireeye.com/v1/url?k=3D5710f0ef-
>>>> 0b995f26-5710b074-0cc47ad93e1c-418920d155a62bf0&q=3D1&e=3D6cd6c372-
>>>> b712-46be-8b10-
>>>> 22955dec7b38&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-
>> l4s-
>>>> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s1-2%2Fbatch-l4s-s1-2-
>>>> cubic-vs-prague-50Mbit-0ms_fixed.png).
>>>=20
>>> [IJ] I understand that the 0 RTT results can be because the =
congestion window
>> is only a few segments large (my guess is ~3 to 4 segments ?). I know =
that this is
>> a problem with e.g. DCTCP.  The question is whether this is a =
permanent
>> problem or something that will be solved over time?.
>>=20
>> 	[SM] With DualQ, I assume it is a structural problem, instead of
>> designing this as a robust system with two fair sharing queues it =
does its clever
>> "indirect coupling" via marking/dropping probabilities. Have a look =
at
>> https://protect2.fireeye.com/v1/url?k=3D53bd001b-0f37caa5-53bd4080-
>> 869a17b5b21b-e4edb2934547a534&q=3D1&e=3D314d9ef9-5cc0-4c98-a599-
>> 59f030e6cb2f&u=3Dhttps%3A%2F%2Fwww.heistp.net%2Fdownloads%2Fsce-l4s-
>> bakeoff%2Fbakeoff-2019-09-13T045427-r1%2Fl4s-s2-2%2Fbatch-l4s-s2-2-
>> cubic-vs-prague-50Mbit-10ms_fixed.png for how sharing in a FQ system =
looks.
>> Even with the leaky ECT(1) as classifier abuse it shoukd be simple to =
fair queue
>> between EXT(1) and not ECH(1) flows and have robust separation. This =
is not
>> rocket science, and mostly, as far as I can tell a solved problem.
>>=20
>>> What is more interesting to me and what makes L4S attractive for the =
use
>> cases outlined in the 3GPP contributions, is the very low queue delay =
with L4S.
>>=20
>> 	[SM] Well, I believe low queueing delay can be achieved without =
dualQ
>> and without abusing the ECT(1) codepoint as a classifier (the desired =
classifier
>> requires one complete independent bit, ECT(1) is just 1/2 of a bit, =
and hence has
>> failure modes in separating L4S-style flows and non-L4S flows). The =
idea of using
>> the finer-grained congestion signaling of DCTCP over the wider =
internet seems
>> sane see the SCE draft proposal as an alternative that would/will =
allow dctcp-
>> style ECN signaling over the internet in a truly backward compatible =
fashion...
>>=20
>>=20
>>> There are other promising features with L4S. One being that it can =
enable
>> congestion control algorithms to quickly grab free capacity.
>>=20
>> 	[SM] When you say L4S, do you mean the congestion signaling? =
Then
>> https://tools.ietf.org/html/draft-morton-taht-sce-00 should have you =
covered,
>> without the nasty side-effects of the current L4S proposal. Or do you =
mean the
>> actual congestion controller as implemented in TCP prague?
>>=20
>>=20
>>> 5G access can have large variations in link throughput for example =
related to
>> dual connectivity and L4S can be helpful here as well.
>>=20
>> 	[SM] Dealing better with variable rate links is certainly =
desirable, but I
>> am not sure that DualQ/TCP Prague really are the best or only tools =
for that
>> purpose. At least not until all of the kinks are ironed out. Again, =
none of this is
>> my call to make, so all I am voicing is my educated subjective =
assessments.
>>=20
>>=20
>> Best Regards
>> 	Sebastian
>>=20
>>>=20
>>>>=20
>>>> 	Personally, I can not help thinking that it might be better to =
first
>>>> make sure there is a complete, real-world tested implementation =
that
>>>> reliably demonstrates that dualQ delivers the required isolation
>>>> between the two traffic classes and that the L4S approach actually
>>>> delivers the reported reliable low latency performance under =
adverse
>>>> real-world conditions while not degrading the performance of other =
traffic,
>> before trying to codify L4S into RFCs.
>>>>=20
>>>>=20
>>>> Best Regards
>>>> 	Sebastian
>>>>=20
>>>>=20
>>>>> On Nov 9, 2019, at 17:00, Ingemar Johansson S
>>>>  wrote:
>>>>>=20
>>>>> Gentlepeople!
>>>>>=20
>>>>> This 3GPP SA2 contribution is recently submitted
>>>>> =
https://protect2.fireeye.com/v1/url?k=3D803d870e-dcb428c7-803dc795-0cc
>>>>> 47
>>>>> ad93e1c-77a60175f8460bc6&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>>>> 22955dec7b38&u=3D
>>>>>=20
>>>>=20
>> https%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FWG2_Arch%2FTSGS2_136
>>>> _Reno%
>>>>> 2FDocs%2FS2-1911250.zip Title =E2=80=9C5QI values for efficient =
handling of
>>>>> congestion control marked IP packets=E2=80=9D
>>>>> The contribution introduces L4S to the SA2 audience and explains
>>>>> where the
>>>> technology is useful. The contribution also proposes a method to =
bake
>>>> L4S into the 5G QoS framework.
>>>>> If agenda time permits, it will be discussed at the SA WG2 meeting
>>>>> in Reno on
>>>> Nov 18-22, hopefully with good results.
>>>>>=20
>>>>> Also a RAN2 contribution was submitted and discussed at an earlier
>>>>> RAN2
>>>> meeting.
>>>>> =
https://protect2.fireeye.com/v1/url?k=3D06eb4ef7-5a62e13e-06eb0e6c-0cc
>>>>> 47
>>>>> ad93e1c-f387514c9f633599&q=3D1&e=3D6cd6c372-b712-46be-8b10-
>>>> 22955dec7b38&u=3D
>>>>>=20
>>>>=20
>> https%3A%2F%2Fwww.3gpp.org%2Fftp%2FTSG_RAN%2FWG2_RL2%2FTSGR2_1
>>>> 07bis%2F
>>>>> Docs%2FR2-1913888.zip
>>>>>=20
>>>>> Enjoy
>>>>> /Ingemar
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>> Ingemar Johansson  M.Sc.
>>>>> Master Researcher
>>>>>=20
>>>>> Ericsson Research
>>>>> Network Protocols & E2E Performance
>>>>> Labratoriegr=C3=A4nd 11
>>>>> 971 28, Lule=C3=A5, Sweden
>>>>> Phone +46-1071 43042
>>>>> SMS/MMS +46-73 078 3289
>>>>> ingemar.s.johansson@ericsson.com
>>>>> www.ericsson.com
>>>>>=20
>>>>>     The best way to find out if you  can trust somebody is to =
trust
>>>>> them
>>>>>             Ernest Hemingway
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


From nobody Sun Nov 10 08:24: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 F15DF1200B6; Sun, 10 Nov 2019 06:26:46 -0800 (PST)
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 LhNbug5L97In; Sun, 10 Nov 2019 06:26:44 -0800 (PST)
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 921AE12004A; Sun, 10 Nov 2019 06:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573395957; bh=Mn7ie145d16Q8xEWBOkPL9bIHkiRYtGVsLlBaaqHlkk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:References:To; b=RK2vtE/MWJlbVx6UsSlAdJbEWifJzeiXjBiJDfl9qjjHJVG/l+29rVQQcpo5v3Gyc CdGwf8pKII99dqRQ0Ag/+IuyT28NjgUwMEVs2s/cgwTe50lDt1nHlug5xXmeq+iuec RExSIUXkjhfry1mj3/9dj6isAYGUmbLDecrWOpS8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.3.68.102]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MxUrx-1hffHY2MMz-00xqxH; Sun, 10 Nov 2019 15:25:57 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller 
In-Reply-To: 
Date: Sun, 10 Nov 2019 15:25:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:BCIgumjW74V2CXn223V57GW+rJv6pm5bLMjH/J5KbZ7ii2PFlsm 1Vj9roHg5f9DpCabqGfoyICR6tqMCK1BbtxWHrZbKPQqaC/gnc5UuXfIXjun2TXTOfxoqyf jPTsMR4uA5QRXGdsP/KXqK/eDX5kP5EQc9iONBrsvsgKMr/D07oAZhtH8CCwNw5B4yPzmQ1 oOLlS5bQTh4EGFuG8HYKA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:6ZwF6li4FZM=:c1sGdx6QCoXkbLOkui50+c cGHot7eaoLdjhDwTr7AqQGSAJNNResP36unTwxa8W7WFghy34TpoB4CrCcnNvo2SbdMwUtEoj /18KSBQGqZ2Hn+tIJX27f4U9ifvB15JooyThSQOgSGQuYBdysQd93MUphNm8BcYp6xVYS6ztF 5gDw4SLq2PKoUy+Bls+l+5AoLDlhr74LA2ybXtrapsffC/AsfC3kptPPP64DbK4VNpEj5ufmI RH8NS2vQvKqXT9V06B/H8FUl0riVEvUfOnr1MrH3sws04ytsYCAgO660KOybysTv0jwYkqlmM QWNstuR65MXcqGglHOKWPgZG+3kRA9IiWC4iMkDUrvI8XSh0kcTchzFqoYgxmE/WH0YLWkI+c t7XCBSbGwq5wF1O5r5CfXBPtR8Fk2pfwM6yzlKXVxGP3IArKkTKD2URyjHeEFnFfT38QL/wtJ DRdIphiN6x8iQ2MrhPhGjA02CLy7Oq4pI33tS7bwel371JzuuunLBH9QLpA1DJ0fWgKYWirKT BxHv9vZ+hFXwN9gY/zp9HVZiX0ewrhOqAC9PPPR1jWNx85NtlN/lvsZ3eNbfbA8skyYF+49TK kO2ISb6Wy+MyoS6gr8Nrq3rNSx0/o8HcK29E4Na7BiLjMmVY3IFAbtNZ3fHoKS4D6PQIzIWn3 nbGnfjIaujJpTwV0fv91PhEpXrPHJx1+5vDtkx053JhuM6uVlfwZclpaNeMOGGnpn4mZKcl2S Op+ZqgzIb8MuZqnlGtSP+KzN507ArKs6P9Sa230dzd9cHDNUrX2XmC8ciHVJ5NtMdIuL9I6e5 bj+ftXSYYhUD1Z8ixPhbE1StngBLtByuV/nc6R66ID670sMZMzgGdbEjGCQ8jcnwnW2/nN40e kS0xDhy4tf+QHaT70C4nz2qV8r4uI+DhnLmnlQIT4j+yXcZH0BLLj5zydYLpCng4mnGP+/Oz2 iOrTmJZm7SQ8C2MlCT2HdPiNyVkv7ZfgVgiwuSWrRmvvSG6yLUoIvmRZRzbnQGzR/nE0ZwnuH s5O1VV0L5gD5m64KmrYKlg0ieH7rdREdZeTB36fySgYABj/MNlCe3HL+wejWYjS6udSp1ngc5 DIuoHeW11CzxWp+y9N131H9eFBffZjSQoY1mWZR9G/IWrtrxKkkz5+J6aAs3pO2lqGL+X/6hL Cb0qIDQO/ou4LUexecY8otzD3Ifqsk4Zz2/Pn6JpMU2dofH96j42C+pDdpOzv0QVuPiDLXsg4 XC/0m8MsQHuFIZ9zcbI7GjOgPJXTz+MW1VkSzUgNQKlER/Wm45boMyB+WtkU=
Archived-At: 
X-Mailman-Approved-At: Sun, 10 Nov 2019 08:24:13 -0800
Subject: Re: [tcpm] [tsvwg] L4S Issue #16 Discussion Paper: Fall-back on Classic ECN AQM
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: Sun, 10 Nov 2019 14:26:47 -0000

Hi Bob,


firstly, thanks for finally starting on tackling this issue of teaching =
L4S-style senders to peacefully coexist with AQMs employing RFC3168 ECN =
marking.


Secondly, I reserve judgment until you post real data under adversarial =
to worst-case conditions, the core of issue #16 is not the lack of =
ideas, but the lack of a real-world implementation that has survived and =
done the right thing in a number of tests.


Thirdly, I really wonder wether the incentives are properly aligned on =
this. I would very much prefer if you, if only for the sake of =
developing your detector, switch from assuming L4S until RFC3168 is =
proven to assume RFC3168 and switch to L4S-style once enough evidence =
was accumulated to justify this step (from then on you reverse again and =
try to collect evidence for RFC3168 for a potential switch back).  As it =
stands you seem to aim for limiting false positive RFC3168 judgements, =
while on the principle of "first, do no harm" you should minimize false =
negatives as well.=20


A few more detailed comments:

"Any transition should be suppressed for a number of RTTs after the =
onset of CE marking, both to allow the connection to stabilize and =
because aggressive competition for bandwidth is not a great concern with =
short flows."

There is an obvious conflict here, to get a reliable estimate of whether =
a path seems limited by a RFC3168-compliant AQM or by a L4S style you =
require a fair number of data samples, but at the same time you also =
want to quickly correct ant AQM-type misjudgments to avoid the =
interference between the ECN response the AQM expects and the response =
the sender exhibits, to minimize the temporal effect on the AQMs queue.=20=


"Therefore, relative to overall convergence time, it will be =
insignificant if a flow takes a couple of dozen rounds to work out =
whether it should be converging to an L4S or to a classic target."

I could live with that IF all flows start RFC3168-compliant, then they =
can take as long as they want to switch to L4S style, in the reverse =
direction we are discussing here however that seems to be sub-optimal. =
As it stands this, you seem to give yourself leeway to mis classify a =
RFC3168-limited path for multiple seconds under congestion, this seems =
quite generous to L4S, too generous for my taste. Given that reasonably =
low latency networking is already possible with the existing internet =
and normal traffic I see very little slack to cut for L4S mis =
classifications (especially since all of this is rooted in L4S =
re-defining the meaning of CE, IMHO you can do this, but then you need =
to "eat" all the cost incurred by that decision).


"In that case, a large classic response to a CE-mark could under-utilize =
the link until cwnd returned. So a small scalable response would be more =
appropriate."

That seems misguided, unless TCP Prague operates on a L4S-limited path =
it should behave like a normal TCP flow, and that pretty much implies a =
multiplicative decrease on CE mark or drop.
I get it you want any advantage for L4S-style flows you can get, but =
honestly this looks like trying too hard to me.



There is quite some slack in this heuristic and I think this comes from =
a notion that the goal of that heuristic is to post-hoc "reluctantly" =
change from L4S-ECN response to RFC3168-ECN response. Personally I would =
be happier to see the test logic reversed, start in RFC3168-compliant =
mode and only enable the L4S-ECN response after an RFC3168-ECN has beed =
ruled out with sufficient certainty. Remember, you argue that dctcp =
style ECN response is too aggressive to be inflicted onto the internet =
without proper isolation and now you seem to argue that strict isolation =
can be replaced by a much looser heuristic.


Best Regards
	Sebastian



> On Nov 5, 2019, at 10:48, Bob Briscoe  wrote:
>=20
> tsvwg, iccrg and tcpm folks,
>=20
> I've published a discussion paper giving rationale and pseudocode for =
an algorithm we are implementing and evaluating in TCP Prague.
>     TCP Prague Fall-back on Detection of a Classic ECN AQM
>=20
> I'd appreciate any immediate concerns with whether it looks feasible =
and/or any scenarios where you think it's likely not to work well.
>=20
>=20
> There's three main components: passive, active and base RTT =
adjustment.=20
> Only the first may be necessary, or possibly only the second.
>=20
> We'll publish evaluation results as soon as we have them.
>=20
> Apologies for not posting as an Internet Draft, but=20
> a) I find LaTeX quicker and more readable esp. for plots;=20
> b) many patent offices consider arXiv (but not Internet Drafts) as =
strong as journal publication
>=20
> For the avoidance of doubt, I have filed no IPR on this.
>=20
> Cheers
>=20
>=20
>=20
> Bob
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                              =20
> http://bobbriscoe.net/


From nobody Sun Nov 10 10:47: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 CE72A120019; Sun, 10 Nov 2019 10:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] 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 CU3tWwkoJqg0; Sun, 10 Nov 2019 10:47:56 -0800 (PST)
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 34D8C12010D; Sun, 10 Nov 2019 10:47:56 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 89C5225A21; Sun, 10 Nov 2019 19:47:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573411674; bh=Bx2bdYDeILDf/+2TT71OwG1k8FFQqW/jmB3uUoUJlWQ=; h=From:To:CC:Subject:Date:From; b=OUsUCoJvGkTIPwCbcqsHwQlizm9AnkRWNEGRAEdCkg1QLcjVlYld5Hyk7y/7i5cM2 /UGMG85N98Mk+PGDiBfHIFA3pRGGhaO8L73BF/1ZfvU0dwl9pLeXNLOt2Ib3/doyuT 9e+b/gnD7vb/ZorBY6PaRsdxHscGZlPXFytGeNJs=
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 vy6VN7JGUgFH; Sun, 10 Nov 2019 19:47:54 +0100 (CET)
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; Sun, 10 Nov 2019 19:47:54 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Sun, 10 Nov 2019 19:47:53 +0100
From: "Scharf, Michael" 
To: "draft-ietf-tcpm-converters@ietf.org" 
CC: "tcpm-chairs@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: Running code for draft-ietf-tcpm-converters
Thread-Index: AdWX9wyUcY7oz7mWSfO1g6W8Rf+1TA==
Date: Sun, 10 Nov 2019 18:47:53 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4F87B6@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.48.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] Running code for draft-ietf-tcpm-converters
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: Sun, 10 Nov 2019 18:47:58 -0000

Hi all,

I work on the shepherd write-up for draft-ietf-tcpm-converters. The write-u=
p should list known implementations.=20

Could implementers of draft-ietf-tcpm-converters please drop me a note and =
confirm that there is running code?

If implementers are willing to share more information about the implementat=
ion, that would also be welcome, as it is useful context for the IESG.

An off-list reply is sufficient. Please also let me know whether it is OK t=
o list the implementation in the public write-up, or whether the preference=
 is to stay anonymous.

Thanks

Michael


From nobody Sun Nov 10 11:17:02 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 E778C120118 for ; Sun, 10 Nov 2019 11:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lmGntCKmoeCb for ; Sun, 10 Nov 2019 11:16:58 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EBB12010D for ; Sun, 10 Nov 2019 11:16:57 -0800 (PST)
Received: from mb.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id F14F572106C16 for ; Sun, 10 Nov 2019 20:16:53 +0100 (CET)
From: Michael Tuexen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Message-Id: <903982D2-36DE-428D-A7C5-D3C389C95E9A@lurchi.franken.de>
Date: Sun, 10 Nov 2019 20:16:52 +0100
To: "tcpm@ietf.org Extensions" 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: [tcpm] Intended status of draft-ietf-tcpm-rack
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: Sun, 10 Nov 2019 19:17:00 -0000

Dear all,

the current intended status of draft-ietf-tcpm-rack is experimental.

The authors have indicated that they think the ID is ready for WG LC.
Before starting that, I would like to bring up the question of the
intended status of draft-ietf-tcpm-rack.

Due to the fact that there are at least two independent implementations,
there has been substantial testing and also deployment, I would like
to ask the working group, if PS is a more appropriate intended status.

Any preferences or opinions?

Best regards
Michael


From nobody Sun Nov 10 15:59:27 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 C94C8120058; Sun, 10 Nov 2019 15:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VucjrSWvNShc; Sun, 10 Nov 2019 15:59:23 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80119.outbound.protection.outlook.com [40.107.8.119]) (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 5CB2412011B; Sun, 10 Nov 2019 15:59:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JEQM5HAnaiu/FPcUul6EfayrWM2EOLxuXKYVlFzCj/23O1TRxPzoFcFFnvqjuaeuQrn9jI05e66lwKXjO2saEBimlLraSpkryGMn7HDx+KYtVxE0GSHqu7LWGDkbe5eeyrdoKxrr1wWVqTPm5Pj3v1QGowqWlhWJc3brooZIbrzTNSL5GeJnYSm68sVmZ4NpMCk0Xve0QsPFKf8NJhI+tPMwFps4Jj/1jY9fbBvpeOxBp+nM2QXERck5hE7X4Q79Il1iO423pHhspwM4lRjN71jyi/oTebUSuEm9DsBpXOhoxUSwNMl8BsGZvJjac8ogeTE/AM42aqNCvtdQNuTrVA==
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=smk3b5cPUKnFwhX0UdliKBowIfDesEiF65aCi61QB2A=; b=OqOAyPBTDBmxd2yy3rbNyMvMLx/S9NjhUEB1zffIK7uQMpX4SbMe3l+lg8XfgAqcZfi4CJAC13JbNVhm6Axq2gV0T2uh7x04jPA5eFhSu6nVxuizzVpwKrJzcVz0SAPdulxbDY9Y0crk6K5NJInHyleqtrnSEPQra4FgtA1AEXi+mg1esdJ0RVMZeukmwb2T6OENUFxud4FZidfbr4XqmkqaocnHNGFWau7WsvNgykLo1xfNIgZq+fIUzu4u3Cci4q1vDl9tAFKtzDxGFN5QJj3Mz6/xciAMgOAyW78432ArtlO/MEZxr5xHjWD2CkMljwcVB3TdweHepBobqr78DQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=smk3b5cPUKnFwhX0UdliKBowIfDesEiF65aCi61QB2A=; b=n67JgkEqAKtSdWyJrWmOYdhb0qEB9Iv6lXjQXtaRDdxwKRANfvLlQSuHKM9wVsxZ78Mo4tDtg/QPJ/CazbhuHE88ir+I2Ngn2u4IKY3dsEE/w6jSXQDv95Fg+kHYDtW94OIWolVPIYCIFKO8TSiZVJqTCQ8Eon18IRn+dPnNP8E=
Received: from VI1PR07MB5981.eurprd07.prod.outlook.com (20.178.120.224) by VI1PR07MB5087.eurprd07.prod.outlook.com (20.177.202.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.17; Sun, 10 Nov 2019 23:59:21 +0000
Received: from VI1PR07MB5981.eurprd07.prod.outlook.com ([fe80::61e0:ae6b:e9c9:5f]) by VI1PR07MB5981.eurprd07.prod.outlook.com ([fe80::61e0:ae6b:e9c9:5f%3]) with mapi id 15.20.2451.018; Sun, 10 Nov 2019 23:59:21 +0000
From: "Tilmans, Olivier (Nokia - BE/Antwerp)" 
To: Dave Taht , tsvwg IETF list , "tcpm@ietf.org" 
Thread-Topic: [tsvwg] sce vs l4s comparison plots?
Thread-Index: AQHVl1JIiOXPJW54hUK6yHnlgBp2CKeFFfRw
Date: Sun, 10 Nov 2019 23:59:20 +0000
Message-ID: 
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net>
In-Reply-To: <87mud4ejl9.fsf@taht.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=olivier.tilmans@nokia-bell-labs.com; 
x-originating-ip: [2a02:1811:537e:6d00:c51c:7ee2:36fe:ed51]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a09011f5-6cd6-401b-0132-08d7663a012c
x-ms-traffictypediagnostic: VI1PR07MB5087:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(376002)(366004)(346002)(189003)(199004)(966005)(102836004)(66556008)(76116006)(64756008)(229853002)(7696005)(76176011)(4744005)(256004)(478600001)(316002)(99286004)(6306002)(9686003)(52536014)(55016002)(6246003)(6436002)(66446008)(2906002)(6506007)(66946007)(66476007)(5660300002)(6116002)(33656002)(186003)(8936002)(476003)(486006)(81156014)(81166006)(11346002)(446003)(46003)(25786009)(74316002)(71200400001)(71190400001)(14454004)(7736002)(305945005)(8676002)(86362001)(2501003)(110136005)(42413003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5087; H:VI1PR07MB5981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hmicUtFWMsqPxCvT7sDy2/hv9nTVmIG2DvwluTmzkPOTSFs6AR3rfAiXVykNYzactJO9mNjeQPDbkp9CYLJV0Fsjve+w/P5DEnWEy07r5Z3obEGAy/7AzD+dcLi1tyNca+cnWPIGRHr1YafIbV/ozhTYz2cXGWSFNcKHksjzNMLqBIYXiSQYnAf8JoeDGi5cuZTsSZTEz5YTRIvX+889WvFpR05IHWW0mso/YFZev0XOYcM0IHVvA0BjgVzPl2hrGyNl6YjMQLvQkGXw4XxfLRqhrPIUcCCJVFD8pJBtEEbKTmHtE+zitmX610HcGNM0bays8lfwrr77+0u4h4eZieT052K1CYUflcpvprIzPFw7K0cJaX8HOHe9lRTK2wlwJOoYpmDlqAB3phwbiMnQfqsjAmsZBYsQqJnOwl88iOpUmp9HS7Go+RXP89HdMqa5
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a09011f5-6cd6-401b-0132-08d7663a012c
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2019 23:59:20.9032 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: c7nFdcdkhVDATIpJ8a50UE50740AhfiH8TL2y/luRpRPyTU4tFj8IyLHDv3V65fUnU8VzyrGDa1Rr559Izm0Rh7h18U2ERbXSHcmdgSLK+E5Z6f2zi7xQpro2rdv4Ghi
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5087
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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: Sun, 10 Nov 2019 23:59:26 -0000

Hi Dave,

> In looking over the l4s.cablelabs site today though, I see the data is
> only available as .png files, and that the associated flent.gz data
> is not apparently being published.

If you follow the "full testbed results" link,
you end up on this page which links to the raw data generated with Pete's
tests in its 2nd sentence/=A7:
https://drive.google.com/open?id=3D1tbRBWkvxyEeDzT5u3EVynupXvEjG8MMb


Best,
Olivier


From nobody Sun Nov 10 16:18: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 720891200FE; Sun, 10 Nov 2019 16:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 ASxeD8MuJdsb; Sun, 10 Nov 2019 16:18:15 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00:e000:2d4:f00f:f00f:b33b:b33b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14319120058; Sun, 10 Nov 2019 16:18:15 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id C3BF221B46; Mon, 11 Nov 2019 00:18:11 +0000 (UTC)
From: Dave Taht 
To: Tom Henderson 
Cc: tsvwg IETF list ,  tcpm@ietf.org
In-Reply-To: <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> (Tom Henderson's message of "Sun, 10 Nov 2019 22:27:58 +0000 (UTC)")
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Date: Sun, 10 Nov 2019 16:17:59 -0800
Message-ID: <87a7931d1k.fsf@taht.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 11 Nov 2019 00:18:18 -0000

Tom Henderson  writes:

> Dave,
> I missed replying earlier to a few of your points below (inline).
>
> On 11/9/19 3:05 PM, Dave Taht wrote:
>
>>
>> By default (when run without -x) flent captures very little metadata
>> about the system it is run on (IP addresses, a couple sysctls, and
>> qdiscs) but it's helpful to have. One example that would be in that
>> metadata, is that I'm unsure if the ns3 data is using an IW4 or IW10?
>>
>> It sounds like you are rate limiting with htb? (to what quantum?)
>>
>> Another example, in more "native" environments running at a simulated
>> line rate, BQL is quite important to have in the simulation
>> also. there's been a couple papers published on BQL's benefits vs a raw
>> txring, thus far, there's a good plot of what it does in fig 6 of:
>>
>> http://sci-hub.tw/10.1109/LANMAN.2019.8847054
>
> in the ns-3 simulations posted, BQL is enabled on all links.

Cool. If only the dsl and cable worlds had adopted this! it allows for
much smarter handling of packet delivery higher in the stack at the cost
of one interrupt's worth of standing queue. Without BQL we wouldn't be
scaling linux past 10GigE today.

I keep hoping *switches* will start doing bql, also.

Note:

The AQL work (long in google wifi and a few other places) - "airtime
queue limits" - is finally entering linux mainline. This makes for a
similar savings to BQL at interrupt time on media with variable "line
rate" encodings, extremely useful for wifi and lte and possibly for
cable and ethernet over powerline devices.

Some details on how well it works are in the google document here:

http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf

Toke's current patchset: https://patchwork.kernel.org/cover/11206223/

>
>>
>> Lastly...
>>
>> So far as I know ns(X) does not correctly simulate GSO/TSO even when
>> run in DCE mode, but I could be out of date on that. TBF (and cake)
>> do break apart superpackets, htb (+ anything, like fq_codel or dualq)
>> do not.
>
> Correct, we do not have an ns-3 model for GSO/TSO.  Is it needed (in
> the simulation) if BQL is enabled with small device queues?

I don't know. Are you seeing GRO/GSO/TSO superpackets in the path on
this simulation? It isn't on for a variety of pseudo devices,
particularly in older releases of linux.

The 4.4 kernel (released 2016-01-10) you are leveraging predates some
major new network subsystem features, like better pacing, sch_etx, and
the switch to EDF scheduling (in linux 5.1). I'm sure there are dozens
more things that might matter, which is why we test. :) I imagine neal
is more up on all the changes since 4.4 that might matter.

In the field:

We started running into problems with GRO starting in 2014, where gige
line rate bursts of IW10,20,30,42 or more packets hit certain brands of
home router hardware, and were then released as a single superpacket. The
resulting load spike (stepping down, to, say, 5mbit) was quite noticible
when doing concurrent voip applications, and also codel tended to be late
in recogizing stuff past the "burp", it didn't matter how much FQ we had
in certain scenarios when dealing with superpackets.

back in 2015, we'd had to put in commit:
a5d28090405038ca1f40c13f38d6d4285456efee
to get GSO even remotely right.

Anyway...

After much gnashing of teeth and pulling of hair while trying to
selectively disable or split gso on various pieces of consumer hw,
in the end we made gso-splitting the default in cake, rather than
try to turn off GRO everywhere it was needed, or revise the htb shaper
so fq_codel could be used more effectively with GSO in place. (as I said
"tbf" does splitting, htb - which is what most sqm systems use - does not).

fq_codel_fast (which has sce support) also
splits GSO. I'd filed a bug on the L4S github site requesting that they
also implement GSO splitting and use memory, not packet limits, a while back.

Given how fine grained either SCE or L4S need to be on their signalling,
my assumption (needing testing!), is that GSO/GRO/TSO need to be
disabled to get an expected result, and with GSO/GRO/TSO on, especially
at lower rates, the results will be "interesting", and thus in the field
with the final delivered codebase(s), it needs to be handled properly by
the qdisc either way it goes.

Last year GSO went always on in linux kernels, which generally means
that locally sourced tcp packets are always 2 packets in size or larger.
the popular sch_fq scheduler has a 2 packet quantum also. This is
great, if you are targetting 40gige....


commit 0a6b2a1dc2a2105f178255fe495eb914b09cb37a
Author: Eric Dumazet 
Date:   Mon Feb 19 11:56:47 2018 -0800

    tcp: switch to GSO being always on
    
    Oleksandr Natalenko reported performance issues with BBR without FQ
    packet scheduler that were root caused to lack of SG and GSO/TSO on
    his configuration.
    
    In this mode, TCP internal pacing has to setup a high resolution timer
    for each MSS sent.
    
    We could implement in TCP a strategy similar to the one adopted
    in commit fefa569a9d4b ("net_sched: sch_fq: account for schedule/timers drifts")
    or decide to finally switch TCP stack to a GSO only mode.
    
    This has many benefits :
    
    1) Most TCP developments are done with TSO in mind.
    2) Less high-resolution timers needs to be armed for TCP-pacing
    3) GSO can benefit of xmit_more hint
    4) Receiver GRO is more effective (as if TSO was used for real on sender)
       -> Lower ACK traffic
    5) Write queues have less overhead (one skb holds about 64KB of payload)
    6) SACK coalescing just works.
    7) rtx rb-tree contains less packets, SACK is cheaper.
        This patch implements the minimum patch, but we can remove some legacy
    code as follow ups.
    
    Tested:
    
    On 40Gbit link, one netperf -t TCP_STREAM
    
    BBR+fq:
    sg on:  26 Gbits/sec
    sg off: 15.7 Gbits/sec   (was 2.3 Gbit before patch)
    
    BBR+pfifo_fast:
    sg on:  24.2 Gbits/sec
    sg off: 14.9 Gbits/sec  (was 0.66 Gbit before patch !!! )
    
    BBR+fq_codel:
    sg on:  24.4 Gbits/sec
    sg off: 15 Gbits/sec  (was 0.66 Gbit before patch !!! )
    
    Signed-off-by: Eric Dumazet 
    Reported-by: Oleksandr Natalenko 
    Signed-off-by: David S. Miller 


>
> - Tom


From nobody Sun Nov 10 16:49:26 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 AC0761200E5; Sun, 10 Nov 2019 16:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 479iUr6GiH5h; Sun, 10 Nov 2019 16:49:23 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D0012001A; Sun, 10 Nov 2019 16:49:23 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 3CD5321B46; Mon, 11 Nov 2019 00:49:20 +0000 (UTC)
From: Dave Taht 
To: "Tilmans\, Olivier \(Nokia - BE\/Antwerp\)" 
Cc: tsvwg IETF list ,  "tcpm\@ietf.org" 
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> 
Date: Sun, 10 Nov 2019 16:49:07 -0800
In-Reply-To:  (Olivier Tilmans's message of "Sun, 10 Nov 2019 23:59:20 +0000")
Message-ID: <875zjr1blo.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 11 Nov 2019 00:49:25 -0000

"Tilmans, Olivier (Nokia - BE/Antwerp)"
 writes:

> Hi Dave,
>
>> In looking over the l4s.cablelabs site today though, I see the data is
>> only available as .png files, and that the associated flent.gz data
>> is not apparently being published.
>
> If you follow the "full testbed results" link,
> you end up on this page which links to the raw data generated with Pete's
> tests in its 2nd sentence/=C2=A7:
> https://drive.google.com/open?id=3D1tbRBWkvxyEeDzT5u3EVynupXvEjG8MMb

Thanks! I missed that! I'm watching google take ages to attempt to zip
up the directory, and delighted to be able to use flent natively on the
result.

(if you can't tell, I haven't been paying much attention to this stuff,
 I popped up this weekend to catch up)

>
>
> Best,
> Olivier


From nobody Mon Nov 11 01:39:09 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 EF050120288; Mon, 11 Nov 2019 01:39:06 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 VFvwcJ8SYpHQ; Mon, 11 Nov 2019 01:39:03 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 8DB07120013; Mon, 11 Nov 2019 01:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From:Subject: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=o/LwOwvc32VTb8blb+blBCvCcFKCPUKuSXfqkDmdsx0=; b=xKzPT1mi/1iOHlHpUUzkp0qnY IOQ1KzW79n9j0kT60pPiLFiBf+RoQg7rjq1zwvWLmnBzdgI/SxA7Q/K6czFDiqRhKLaVks4zXwVpf iLj2xWmYrwLb0CYnRnruvIvY0AwKnbEOAC5gcl8scbevTFATvC3Zcw169+61OxZ8MCuZSiZuJowDo ypWNdMqEFXs8HfLjas1Nwaq9lJJDtE4l/BoH6CUrOVgGJGIu05c4FPqj0pNznTr86pJ/zGuKMjNLd JoZVk1DOkmuCRIlR8MHB87iL+c3sUudqNmusv6OKxYxkX8+39MbUXZLgXDtKxzPWBOsqWQLgV0nMZ h+NNjKrMg==;
Received: from [31.185.128.31] (port=35714 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iU6A1-0007pk-C9; Mon, 11 Nov 2019 09:39:01 +0000
From: Bob Briscoe 
To: "Scharf, Michael" , "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" 
Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net>
Message-ID: 
Date: Mon, 11 Nov 2019 09:39:00 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net>
Content-Type: multipart/alternative; boundary="------------F0E8646B1CE24840474C1F0D"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
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, 11 Nov 2019 09:39:07 -0000

This is a multi-part message in MIME format.
--------------F0E8646B1CE24840474C1F0D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Michael,

On a similar question of dependency between experiments, I think you 
also expressed concern that ecn-l4s-id depends on the RACK experiment. 
However, ecn-l4s-id only refers to RACK informatively, because it only 
uses the general idea behind RACK. Just as quic-recovery (stds track) 
uses the general idea behind RACK (expt track) by referring to it 
informatively.



Bob

On 04/11/2019 15:26, Bob Briscoe wrote:
> Michael,
>
> Thank you for pointing this out, many months ago now.
>
> There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on 
> AccECN, as explained below.
>
> For any transport protocol to comply with ecn-l4s-id, it needs 
> sufficiently accurate feedback of the extent of CE marking on the 
> forward path. You pointing this out has made me realize that there is 
> a 'needs' that should be a 'MUST' in the spec:
>
> 4.2.  Prerequisite Transport Feedback
>
> CURRENT:
>     In general, a scalable congestion control, needs feedback of the
>     extent of CE marking on the forward path.
> PROPOSED:
>     In general,for a transport protocol to provide  scalable congestion control,
>     it MUST provide  feedback of the
>     extent of CE marking on the forward path.
>
> However, ecn-l4s-id only specifies the requirements that any L4S 
> transport protocol would have to satisfy. It does not define a 
> transport protocol itself. So AccECN is not a normative ref. So I am 
> also altering the text a little further down, where it refers to 
> AccECN, as follows:
>
> CURRENT:
>    TCP:  Support for accurate ECN feedback (AccECN
>        [I-D.ietf-tcpm-accurate-ecn  ]) by both ends is a prerequisite for
>        scalable congestion control.
> PROPOSED:
>    TCP:  Support for accurate ECN feedback (such as AccECN
>        [I-D.ietf-tcpm-accurate-ecn  ]) by both ends is a prerequisite for
>        scalable congestion control.
> Thanks again for pointing this out.
>
>
>       Dependencies between Experiments
>
>
> The case of TCP Prague provides a counter-argument:
>
> TCP Prague could be specified in one monolithic experimental spec.
> Or it could be broken down into experimental components, and a top 
> level experimental spec that pulls them all together.
>
> The latter option would create multiple dependencies of one experiment 
> on others. But IMHO such modularity is preferable to a monolithic 
> spec. Especially if some of the components might have other uses 
> outside of TCP Prague (which is exactly the case with TCP Prague, e.g. 
> AccECN, ECN++, RACK are all potentially parts of the base TCP stack, 
> and paced-chirping is potentially usable by any other congestion 
> control - these are all experimental component parts).
>
> As another example, BBR was written up as an experimental draft, and 
> the Linux implementation uses RACK (although not mentioned in the 
> draft) which is enabled by default in Linux.
>
> Such modularity is good.
>
>
> Bob
>
>
> On 24/03/2019 19:15, Scharf, Michael wrote:
>> I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence:
>>
>> TCP:  Support for accurate ECN feedback (AccECN
>>        [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
>>        scalable congestion control.  Therefore, the presence of ECT(1) in
>>        the IP headers even in one direction of a TCP connection will
>>        imply that both ends support AccECN.  However, the converse does
>>        not apply.  So even if both ends support AccECN, either of the two
>>        ends can choose not to use a scalable congestion control, whatever
>>        the other end's choice.
>>
>> Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn?
>>
>> If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing.
>>
>> As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind.
>>
>> Michael (as individual)
>>
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------F0E8646B1CE24840474C1F0D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    On a similar question of dependency between experiments, I think you
    also expressed concern that ecn-l4s-id depends on the RACK
    experiment. However, ecn-l4s-id only refers to RACK informatively,
    because it only uses the general idea behind RACK. Just as
    quic-recovery (stds track) uses the general idea behind RACK (expt
    track) by referring to it informatively.

    

    

    

    Bob

    

    
On 04/11/2019 15:26, Bob Briscoe wrote:

    

    

      
      Michael,

      

      Thank you for pointing this out, many months ago now. 

      

      There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on
      AccECN, as explained below.

      

      For any transport protocol to comply with ecn-l4s-id, it needs
      sufficiently accurate feedback of the extent of CE marking on the
      forward path. You pointing this out has made me realize that there
      is a 'needs' that should be a 'MUST' in the spec:

      

      4.2.  Prerequisite Transport Feedback

      

      CURRENT:

      
   In general, a scalable congestion control, needs feedback of the
   extent of CE marking on the forward path.

      PROPOSED:

      
   In general, for a transport protocol to provide scalable congestion control, 
   it MUST provide feedback of the
   extent of CE marking on the forward path.

      

      However, ecn-l4s-id only specifies the requirements that any L4S
      transport protocol would have to satisfy. It does not define a
      transport protocol itself. So AccECN is not a normative ref. So I
      am also altering the text a little further down, where it refers
      to AccECN, as follows:

      

      CURRENT:

      
  TCP:  Support for accurate ECN feedback (AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.

      PROPOSED:

      
  TCP:  Support for accurate ECN feedback (such as AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.

      Thanks again for pointing this out.

      

      
Dependencies between Experiments

      

      

      The case of TCP Prague provides a counter-argument:

      

      TCP Prague could be specified in one monolithic experimental spec.
      

      Or it could be broken down into experimental components, and a top
      level experimental spec that pulls them all together.

      

      The latter option would create multiple dependencies of one
      experiment on others. But IMHO such modularity is preferable to a
      monolithic spec. Especially if some of the components might have
      other uses outside of TCP Prague (which is exactly the case with
      TCP Prague, e.g. AccECN, ECN++, RACK are all potentially parts of
      the base TCP stack, and paced-chirping is potentially usable by
      any other congestion control - these are all experimental
      component parts). 

      

      As another example, BBR was written up as an experimental draft,
      and the Linux implementation uses RACK (although not mentioned in
      the draft) which is enabled by default in Linux. 

      

      Such modularity is good.

      

      

      Bob

      

      

      
On 24/03/2019 19:15, Scharf, Michael
        wrote:

      

      

        
I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence:

TCP:  Support for accurate ECN feedback (AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.  Therefore, the presence of ECT(1) in
      the IP headers even in one direction of a TCP connection will
      imply that both ends support AccECN.  However, the converse does
      not apply.  So even if both ends support AccECN, either of the two
      ends can choose not to use a scalable congestion control, whatever
      the other end's choice.

Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn?

If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing.

As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind.

Michael (as individual)




      

      

      
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------F0E8646B1CE24840474C1F0D--


From nobody Mon Nov 11 01:44:31 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 A499712081E; Mon, 11 Nov 2019 01:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-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=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 RttWhoLgpZQ5; Mon, 11 Nov 2019 01:44:25 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30075.outbound.protection.outlook.com [40.107.3.75]) (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 4A7A012080B; Mon, 11 Nov 2019 01:44:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nzhZB8eAES4EFlOysOnbRxuwBfTSsUkM3Nvx13THxSVEyusjeQY1FMuERcvZH3sAlCZjBvrVeVDxih+Gxwrb5eDgKBxKVfL5eQU28gwERgE4nXc73JPKN0CwZfl8uXWTswAc6m6fIJV95ynVRNIs8kmFoczfNpZh6+s4lySvNyCwwfa3zqNBq95MIwO2vpPUZYBo3wadPnvscUJEOV1EPT0t9zV5pSEUeE0QM3Fs6Ef2gGd2466p8tIeKeudtJ7WBYLZVemjPpA1MUxhHLiMNNLfK9a9RaleThDkXZrd6/VTq06qHo7rgt79xTxHaUKdPJhIpYC/ADx4vrN1XYeAdQ==
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=dzzO9vflJcNzuV0GZmd37J88rvFiY2nhrzMdYfdfeSs=; b=nJ8zEcX1i5wemk9h9f0tGavS1/yqJb776r1IXZhC8hFfGYPPH42C4KyT0KNfynpdyepO1KKP19oAPvCG2VGyJNDP8w6zbLRVCFgkBxrbIV9pmhbHTrKquTicbAJ6VOpfDKxL0TCG5nqQwQUhpKv4wXyl3q/EC+4wwpcNEk94XrKqMxchwf5851ezUFxTUmbGOIt5X6+A8W5FCN7MiBfHvSWddJaxIDD7WVCINx7nN2O7BKrNT6n9pfvZrfeEUxQ4BxJr1SgkFm5CaXzXeqf3Uf3V3P6gIRIl1quja6+67ahVOQmiFBkAZ2VPIUf6eIQI1lytRAKS96zmGeQ1VcvZJg==
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=dzzO9vflJcNzuV0GZmd37J88rvFiY2nhrzMdYfdfeSs=; b=YoLjsRgteLQ5s1DYnndBwGYRxtNX5m64CLJeudbLnZYVXnjmp+AHLHLaIlwUxN2iqRvwuSqFbXVyd6/SEld3Mpg5zphlHvd2375yTIkLxAT3vprlihYXEzS6kTiKgqeCwM2U8SlNagKDmiRRApJ9SJf8acVE/mcjb0EYFuNejaU=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3481.eurprd07.prod.outlook.com (10.170.246.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.21; Mon, 11 Nov 2019 09:44:22 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.018; Mon, 11 Nov 2019 09:44:22 +0000
From: Ingemar Johansson S 
To: "Scharf, Michael" , Sebastian Moeller , Ingemar Johansson S , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , Ingemar Johansson S 
Thread-Topic: [tsvwg] [tcpm]  L4S status tracking
Thread-Index: AQHVlHDpO72yLQ1dAky9TO/zJYqoYqeBgjoggAAdCACABCA3IA==
Date: Mon, 11 Nov 2019 09:44:22 +0000
Message-ID: 
References:    <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [192.176.1.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 416937a8-d7f6-4b5d-5be3-08d7668bbb59
x-ms-traffictypediagnostic: HE1PR07MB3481:|HE1PR07MB3481:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:205;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(51444003)(189003)(199004)(13464003)(64756008)(86362001)(6436002)(66066001)(30864003)(99936001)(7736002)(8676002)(305945005)(81166006)(66574012)(55016002)(5660300002)(74316002)(52536014)(6246003)(81156014)(66476007)(66616009)(6306002)(9686003)(107886003)(66446008)(229853002)(66556008)(76116006)(476003)(25786009)(486006)(2501003)(33656002)(66946007)(446003)(4326008)(3846002)(102836004)(2906002)(478600001)(99286004)(26005)(186003)(966005)(19627235002)(7696005)(76176011)(53546011)(6506007)(14454004)(110136005)(256004)(54906003)(5024004)(14444005)(71200400001)(316002)(71190400001)(8936002)(11346002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3481; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1pNHTAVa7EhJ+qcIfhcczGzlvd+hieFZnBJlh2MImEgNcjqPGPxsKQ528tPPcAZCXE3lJLtLqBfKBOB3udrA1KgRRxdy/JK5KH8ZqJiiIXx4IVeBOqMpUs2aGFn0VOA1rI6UtgAe+3bvE3+h5482KKV7a4ZS7FQMv4k79CUO4wmA4YNWOEk/Grs4oMwG9C2EK5LOgm9T4z2wRbpmE6snAjLB79zMRU1aiByO4xmtsmtfc5LpnNDRx6C1fYGN8vfYEVyD6VHmgrpdCa0V2oZ4DEhCHPH7N4ttbaUzr8emF1T7h5Pd7aWL1h5mcqmlQFBadD9Gn9nAuMM/nVLZUdhgaccoRpUK0zFAh817bDDDO0pifzJWbyG9YdVhlpBmu8HcmSYoxe2aZzjXC8GUXhrcnG6+Ou6LQTeqvmFk/7hPO5xIRVjsCI8bagF/q1Qu4xwL
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01D5987C.F944A5D0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 416937a8-d7f6-4b5d-5be3-08d7668bbb59
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 09:44:22.5027 (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: heJzG3j75s1hdh5Xj9GtwJ8OZbhsVc/M80Hi6PauuQgNOaeuXTrskAZpoNcNrORlBTxmWl95SKAmmB7MrC3tjB+MFzsbymtpYbNURdc9NuQPnBP7SurBC0y19kkx1BEv
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3481
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: Mon, 11 Nov 2019 09:44:29 -0000

------=_NextPart_000_0014_01D5987C.F944A5D0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi
I believe that it is best that I leave this discussion for the time =
being, I guess that it will be brought up again in some organized =
fashion. Hopefully then it will not eat up all the meeting time :-|=20

/Ingemar

> -----Original Message-----
> From: Scharf, Michael 
> Sent: den 8 november 2019 19:41
> To: Ingemar Johansson S ; Sebastian
> Moeller ; Ingemar Johansson S
> ;
> 4bone@gndrsh.dnsmgr.net
> Cc: tcpm@ietf.org; tsvwg@ietf.org
> Subject: RE: [tsvwg] [tcpm] L4S status tracking
>=20
> Hi Ingemar,
>=20
> A question for clarification, given that the term "classic" is used =
for different
> aspects in L4S:
>=20
> Does your preference include the terms 'Classic' TCP and 'Classic' =
congestion
> control, specifically when referring to a state-of-the-art TCP stack =
as currently
> shipped by major operating systems?
>=20
> If so, can you provide references for use of the terms 'Classic' TCP =
and 'Classic'
> congestion control for what is currently widely deployed in the =
Internet?
>=20
> Thanks
>=20
> Michael
>=20
>=20
>=20
> > -----Original Message-----
> > From: Ingemar Johansson S 
> > Sent: Friday, November 8, 2019 6:04 PM
> > To: Sebastian Moeller ; Ingemar Johansson S
> > ; Scharf, =
Michael
> > ; 4bone@gndrsh.dnsmgr.net
> > Cc: tcpm@ietf.org; tsvwg@ietf.org; Ingemar Johansson S
> > 
> > Subject: RE: [tsvwg] [tcpm] L4S status tracking
> >
> > Hi Sebastian
> >
> > I clearly mentioned that I would prefer that the term "classic" is
> > kept, the earth will likely continue to spin around its axis even if
> > it is changed to something else
> > =F0=9F=98=8A. But then it should be something that the group can =
agree on, I
> > don't however see any consensus.
> >
> > /Ingemar
> >
> > > -----Original Message-----
> > > From: Sebastian Moeller 
> > > Sent: den 6 november 2019 08:08
> > > To: Ingemar Johansson S
> > > ;
> > > Michael.Scharf@hs- esslingen.de; 4bone@gndrsh.dnsmgr.net
> > > Cc: Ingemar Johansson S ;
> > tcpm@ietf.org;
> > > tsvwg@ietf.org
> > > Subject: Re: [tsvwg] [tcpm] L4S status tracking
> > >
> > > Hi Ingmar,
> > >
> > > IMHO this is a slippery slope argument. Because if minor changes =
to
> > > the
> > naming
> > > are "impossible" how will changed to the underlying concepts and
> > > methods
> > be
> > > acceptable to you. Because surely these other organizations =
already
> > committed
> > > to what is proposed to the IETF as an experiment?
> > > My gripe with the classic moniker is that this term is not outcome =
neutral.
> > What
> > > I mean is, that while in itself not necessarily negative, it =
implies
> > > that the new
> > kid
> > > on the block is the way into the future, while the classic version
> > > should head
> > into
> > > it's well-deserved retirement. And on the facts this simply is not
> > > settled or accepted in the case of L4S. IMHO the testing published
> > > by the L4S/RITE folks always tested conditions that are very
> > > favorable to L4S and completely
> > ignored
> > > to reach out to the actual user community interested in low =
latency
> > > under
> > load.
> > > It might well be that the L4S approach might also do well in a =
true
> > > stress test
> > (bi-
> > > directiomal saturation on a asymmetric path with bursty cross
> > > traffic for starters), but I would like to see numbers first. And
> > > the L4S sce back-off data posted to this list in the path seems to
> > > indicate that L4S still has open ends
> > that
> > > IMHO need addressing (independent of whether 3GPP likes this or =
not).
> > >
> > > Best Regards
> > >         Sebastian
> > >
> > > On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S
> > >  wrote:
> > > >Hi
> > > >
> > > >I would prefer that the term "Classic" is kept.
> > > >L4S is not anymore an IETF only matter. Work is ongoing to get
> > > >support for L4S in 3GPP for 5G and the input papers there use the =
term
> classic.
> > > >It is of course too late for changing classic to something else,
> > > >but then it is appreciated that It is something that the group =
can
> > > >agree on and I don't see that we are there, therefore it is =
better
> > > >to stick to "classic".
> > > >And to me the term "classic" does not sound negative.
> > > >
> > > >/Ingemar
> > > >
> > > >> Message: 3
> > > >> Date: Wed, 6 Nov 2019 00:22:44 +0000
> > > >> From: Bob Briscoe 
> > > >> To: "Scharf, Michael" , "Rodney =
W.
> > > >> 	Grimes" <4bone@gndrsh.dnsmgr.net>
> > > >> Cc: Wesley Eddy , "tsvwg@ietf.org"
> > > >> 	, "tcpm@ietf.org" 
> > > >> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> > > >> Message-ID: <7f1aa4ae-05d6-b07c-50b0-
> ab899c5c30b7@bobbriscoe.net>
> > > >> Content-Type: text/plain; charset=3D"windows-1252"; =
Format=3D"flowed"
> > > >>
> > > >> Michael, Rod,
> > > >>
> > > >> Altho non-L4S is a reasonable idea, I think it has more of a
> > > >> negative
> > > >connotation
> > > >> than classic. For instance, consider describing Android phones =
as
> > > >non-iPhones.
> > > >>
> > > >> Also, in the ecn-l4s-id draft, we introduce the possibility =
that
> > > >> some
> > > >operators
> > > >> might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into =
the
> > > >same
> > > >queue as
> > > >> L4S traffic (and we say that in this case the queue would be
> > > >> called
> > > >the
> > > >Low
> > > >> Latency queue). This shows that the term non-L4S is not a good
> > > >> choice
> > > >for
> > > >a
> > > >> name, because the words it is made from already give it a =
meaning
> > > >> of
> > > >its
> > > >own
> > > >> that conflicts with the definition you want it to have in =
certain
> > > >contexts.
> > > >>
> > > >> For example, if you did define the name "non-iPhone" to mean
> > > >> phones
> > > >such
> > > >as
> > > >> Android, Windows, etc, then you would expect the phrase
> > > >> "non-iPhone
> > > >knock-
> > > >> off products" to mean "fake Android and Windows phones". =
However
> > > >> the constituent elements "non" and "iPhone" already have a
> > > >> meaning of
> > > >their
> > > >own,
> > > >> so in the context of this phrase, it means "fake iPhones", =
which
> > > >> is
> > > >the
> > > >opposite
> > > >> of what you wanted.
> > > >>
> > > >> The term Classic for the non-L4S service, its queue, its =
traffic,
> > > >> its
> > > >congestion
> > > >> control, etc. is defined in the terminology section of the
> > > >> drafts, so
> > > >I
> > > >think it's
> > > >> best to live with this - it's not a significant problem. =
Indeed,
> > > >> it
> > > >has
> > > >become widely
> > > >> used and widely understood since 2015, and changing it to =
non-L4S
> > > >> now
> > > >would
> > > >> cause unnecessary confusion.
> > > >>
> > > >>
> > > >>
> > > >> Bob
> > > >>
> > > >>
> > > >>
> > > >> On 04/11/2019 19:21, Scharf, Michael wrote:
> > > >> >
> > > >> > I agree. ?non-L4S? may be even better.
> > > >> >
> > > >> > Michael
> > > >> >
> > > >> > *Von: *Rodney W. Grimes 
> > > >> > *Gesendet: *Montag, 4. November 2019 20:17
> > > >> > *An: *Scharf, Michael 
> > > >> > *Cc: *Bob Briscoe ; Wesley Eddy
> > > >> > ; tsvwg@ietf.org
> > > >;
> > > >> > tcpm@ietf.org 
> > > >> > *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
> > > >> >
> > > >> > > You can e.g. use ?non-L4S-enabled TCP?.
> > > >> > >
> > > >> > > Terminology does matter to me given that I strongly =
disagree
> > > >> > > to
> > > >any
> > > >> > use of ?marketing language? when it comes to TCP.
> > > >> >
> > > >> > My concern here of use of terms like, legacy, classic, new, =
old
> > > >> > is that they are pretty much all of the relative from and =
thus
> > > >ambiguous
> > > >> > over time.
> > > >> >
> > > >> > newReno is new only relative to Reno, that is fairly clear, =
but
> > > >> > if
> > > >I
> > > >> > said newTCP or oldTCP with what frame should the reference be
> > > >> > evaluated.
> > > >> >
> > > >> > I believe in the case of L4S the time invariant term would =
be,
> > > >> > as Michael suggests above, "non-L4S".?? Note that enabled for
> > > >> > me is a noise word in this context, and TCP may or may not be
> > > >> > needed
> > > >depending
> > > >> > on context, but for literal replacement of Legacy or Classic
> > > >"non-L4S"
> > > >> > is invariant over time.
> > > >> >
> > > >> > Rod
> > > >> >
> > > >> > > Michael
> > > >> > >
> > > >> > >
> > > >> > > Von: Bob Briscoe
> > > >> > > Gesendet: Montag, 4. November 2019 19:09
> > > >> > > An: Scharf, Michael;
> > > >Wesley
> > > >> > Eddy;
> > > >> > tsvwg@ietf.org
> > > >> > > Cc: tcpm@ietf.org
> > > >> > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking
> > > >> > >
> > > >> > > Michael,
> > > >> > >
> > > >> > > Previously, I have been told not to use the term standard =
for
> > > >RFCs
> > > >> > that are not standards. RFC5681 is 'only' a draft standard.
> > > >> > This is why, in the IETF at least, I avoid using the term
> > > >> > "standard TCP congestion control". I generally call it Reno
> > > >> > when referring to the congestion control.
> > > >> > >
> > > >> > > I have never, to my knowledge, used the term classic TCP, =
or
> > > >classic
> > > >> > TCP congestion control.
> > > >> > >
> > > >> > > And I rarely use the term legacy, and if I do I'm happy to
> > > >> > > have
> > > >> > alternatives suggested.
> > > >> > >
> > > >> > > I've checked the L4S drafts, and there is one phrase that I
> > > >> > > shall
> > > >> > leave in ecn-l4s-id: "the traditional TCP Reno additive
> > > >> > increase", because this is correctly used to mean the
> > > >> > traditional increase (in numerous AIMD CCs), not traditional
> > > >> > TCP. There was one other occurrence of "traditional TCP
> > > >> > senders" in a whole para in an
> > > >appendix
> > > >> > that has just been deleted anyway. And in aqm-dualq-coupled
> > > >> > there
> > > >was
> > > >> > one "legacy TCP flows" (changed to "Classic traffic" now in =
my
> > > >local
> > > >> > copy, using the defined term in all the L4S drafts).
> > > >> > >
> > > >> > > l4s-arch is getting a complete make-over for terminology, =
so
> > > >> > > I
> > > >will
> > > >> > check that next.
> > > >> > >
> > > >> > > inline...
> > > >> > >
> > > >> > >
> > > >> > > On 23/08/2019 15:01, Scharf, Michael wrote:
> > > >> > >
> > > >> > > Hi Wes,
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > I?d 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-
> > > >> hDvWO3I5MudwpNkKyH
> > > >> >
> > > >Y > hDvWO3I5MudwpNk
> > > >> > KyHY> , I object to the terms ?traditional TCP? and also
> > > >> > KyHY> ?classic
> > > >TCP?
> > > >> > or ?legacy? TCP when referring to a TCP implementation
> > > >> > according to IETF standards-track RFCs.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > To me as a non-native native speaker, all these terms have =
a
> > > >> > negative connotation. I also think this language is typical =
to
> > > >> > marketing material.
> > > >> > >
> > > >> > > You're entitled to your opinion but, as a native speaker, I
> > > >> > > don't
> > > >> > think 'classic' or 'traditional' are particularly pejorative,
> > > >> > tho
> > > >they
> > > >> > can be when used in a context that intends them to be. They
> > > >> > also
> > > >mean
> > > >> > "stood the test of time". I find 'legacy' has a connotation =
of
> > > >> > marketing-speak, but it's not that bad.
> > > >> > >
> > > >> > > This is an enduring problem when trying to improve on the
> > > >> > > good
> > > >work
> > > >> > that other people have done before you (which is the context =
of
> > > >> > everything we are doing). We need a word that distinguishes =
the
> > > >> > old from the new, but we don't want to completely trash the
> > > >> > thing that
> > > >has
> > > >> > already been successful, but had its day.
> > > >> > >
> > > >> > > Nonetheless, it is also important not to be too precious
> > > >> > > about
> > > >past
> > > >> > work. We all recognize that Reno TCP is unscalable and has
> > > >problems.
> > > >> > IMO, it is OK to describe technologies that have had their =
time
> > > >with
> > > >> > negative connotations. Indeed, you have been an author (with
> > > >> > me) of
> > > >an
> > > >> > RFC on open issues in congestion control.
> > > >> > >
> > > >> > > I notice you haven't suggested an alternative term for "the
> > > >thing(s)
> > > >> > we are trying to improve on". Not surprising, because it's
> > > >difficult.
> > > >> > >
> > > >> > > When we (the L4S developers) were first looking for a term
> > > >> > > for
> > > >the
> > > >> > non-L4S queue and the non-L4S service, we didn't want to use
> > > >'legacy'
> > > >> > for the above reasons, but we did want to imply pre-existing,
> > > >> > so we decided on 'classic', which we all felt had a generally
> > > >> > neutral connotation, but said what we meant.
> > > >> > >
> > > >> > > Finally, I do not want this issue to take up any time that
> > > >> > > would
> > > >> > detract from technical issues.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Bob
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > My prefered term when referring to TCP according to
> > > >standards-track
> > > >> > specification 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 TCP standard congestion control (?Reno?). As of =
today,
> > > >> > this
> > > >is
> > > >> > the TCP congestion control 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 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 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 and I don?t ask for
> > > >changes
> > > >> > in those cases.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Some use of the term ?Classic Service? may also require
> > > >> > > careful
> > > >> > review to clearly 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 speaker, it would be really strange to use the =
term
> > > >> > ?classic? in the context of a brand-new transport protocol.
> > > >> > IMHO in that case the term ?classic? 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.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > tcpm mailing list
> > > >> > > tcpm@ietf.org
> > > >> > > https://www.ietf.org/mailman/listinfo/tcpm
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >>
> > >
> >
> ________________________________________________________________
> > > >> > > Bob Briscoe
> > > >> > >
> > > =
>https://protect2.fireeye.com/v1/url?k=3D9e3cf770-c2e8fb81-9e3cb7eb-86
> > > >4
> > > >> > > =
685b2085c-4ba6a1960c4f3e7a&q=3D1&e=3Dbf49c0f0-380b-42d4-93a2-
> > > >> 9ebedff802e
> > > >> > > 0&u=3Dhttp%3A%2F%2Fbobbriscoe.net%2F
> > > >> >
> > > >> > > _______________________________________________
> > > >> > > tcpm mailing list
> > > >> > > tcpm@ietf.org
> > > >> > > https://www.ietf.org/mailman/listinfo/tcpm
> > > >> >
> > > >> > --
> > > >> > Rod Grimes rgrimes@freebsd.org
> > > >>
> > > >> --
> > > >>
> > >
> >
> ________________________________________________________________
> > > >> Bob Briscoe
> > > >https://protect2.fireeye.com/v1/url?k=3D861241a8-
> > > >> dac64d59-86120133-864685b2085c-
> > 16120a27ab4a751a&q=3D1&e=3Dbf49c0f0-
> > > >> 380b-42d4-93a2-9ebedff802e0&u=3Dhttp%3A%2F%2Fbobbriscoe.net%2F
> > > >>
> > > >> -------------- next part -------------- An HTML attachment was
> > > >> scrubbed...
> > > >> URL:
> > > >>
> > > =
> > > >/de7
> > > >97
> > > >> fd1/attachment.html>
> > > >>
> > > >> ------------------------------
> > > >>
> > > >> Subject: Digest Footer
> > > >>
> > > >> _______________________________________________
> > > >> tcpm mailing list
> > > >> tcpm@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/tcpm
> > > >>
> > > >>
> > > >> ------------------------------
> > > >>
> > > >> End of tcpm Digest, Vol 187, Issue 15
> > > >> *************************************
> > >
> > > --
> > > Sent from my Android device with K-9 Mail. Please excuse my =
brevity.

------=_NextPart_000_0014_01D5987C.F944A5D0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMTEwOTQ0MjBaMCMGCSqGSIb3DQEJBDEWBBThFWGEqKb5U7DGipJ/
RlN3pyHe2TBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAG8xsKtoTPnXdNMpGtuCJQuw7a5ZCYlz4jMdMkPD
NKQ3Whz7ycwhXl73asOqxfaqVpOSi1IKz1P8nK7d1piVBRm7Ef2acYPCwXM/PlJq5gFoOe6koJMz
lT3tgBz1SgBzMRD7SaYUVbXODUk/7/5FrPFi3HF31uhUr1GYqpsM1LzwghO2pt8GxgnwhcCSVVcq
Lw897O2RcVkuIzY7QctaYVpc3MzvsRymcZyVMKGXeplWkeYuPIoRAEzRBXPeYFMn+uGl0qJ6GqyW
wcsxfYMccbqkg7asG+ntcBUS3ZFX3rvpBVEnH+3WnDjMtHQZxK1mrs5+PB56PdGqhWbX3JpjWhoA
AAAAAAA=

------=_NextPart_000_0014_01D5987C.F944A5D0--


From nobody Mon Nov 11 02:16:39 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 2F8A0120059; Mon, 11 Nov 2019 02:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01] 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 cUh2qvBMZMPG; Mon, 11 Nov 2019 02:16:34 -0800 (PST)
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 6F01B120274; Mon, 11 Nov 2019 02:16:33 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 6FBC025A17; Mon, 11 Nov 2019 11:16:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573467391; bh=bkOEfOjNwCMh8wJtQrXwkCIPywIeEPZSiZwLEuPVgbs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=kb9a3rVfVhBumLkHPCo9W+ym3poauyZ5rn8GYIzHuguUJiXBtGqcLzFvuBImzCW42 yhRJCwWj0PSzstS0/QpWjB+9stj0uYDDE5MkAO6IDbA1vprP0kHig8GygHGxevziql QL4D+mB84AhF0F7Oxfk16caZ0iIy3AtHieZJUpgk=
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 L-1cUAKu72Mv; Mon, 11 Nov 2019 11:16:27 +0100 (CET)
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; Mon, 11 Nov 2019 11:16:27 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 11 Nov 2019 11:16:27 +0100
From: "Scharf, Michael" 
To: Bob Briscoe , "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" 
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
Thread-Index: AQHVkyRO0hfVTfCa3UGewND2kYjsB6eFsKUAgAAUAgA=
Date: Mon, 11 Nov 2019 10:16:26 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4FA28D@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4FA28Drznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
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, 11 Nov 2019 10:16:37 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4FA28Drznt8114rzntrzd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U28gY2FuIHlvdSBjb25maXJtIHRoYXQgYSBUQ1Agc2VuZGVyIGNhbiB1c2UgdGhlIEw0UyBzZXJ2
aWNlIHdpdGhvdXQgaW1wbGVtZW50aW5nIEFjY0VDTj8gSSBhbSBhc2tpbmcgYWdhaW4gc2luY2Ug
dGhlcmUgaGFzIGJlZW4gc29tZSByZWNlbnQgbGlzdCBkaXNjdXNzaW9uIG9uIHRoYXQsIGUuZy4s
IGdpdmVuIHRoZSBwb2ludHMgcmFpc2VkIGJ5IFNlYmFzdGlhbi4gSSBhbSBhIGJpdCBsb3N0IGhl
cmUgb24gd2hhdCB0aGUgZnV0dXJlIHBsYW4gaW4gTDRTIGFjdHVhbGx5IGlzLg0KDQpBbmQgSSBz
dGlsbCBmYWlsIHRvIHVuZGVyc3RhbmQgd2h5IGV2ZW4gdGhlIGdlbmVyYWwgaWRlYSBvZiBSQUNL
IG1hdHRlcnMgdG8gQVFNIGFsZ29yaXRobXMsIHRyYWZmaWMgY2xhc3NpZmllcnMsIG9yIHByaW9y
aXR5IHNjaGVkdWxlcnMgZm9yIHRyYWZmaWMgd2l0aCAxL3AgY29uZ2VzdGlvbiBjb250cm9sIGlu
IGEgcm91dGVyLiBSQUNLIGhhcyBsb3RzIG9mIG1lcml0cywgYnV0IG1vc3Qgb2YgdGhlbSBhcmUg
SU1ITyBlbnRpcmVseSB1bnJlbGF0ZWQgdG8gdGhlIHZpc2lvbiBvZiBMNFMuIEnigJlkIHN1Z2dl
c3QgdG8gZm9jdXMgTDRTIG9uIHNvbHZpbmcgdGhlIGtleSBwcm9ibGVtcyBmb3IgdHJhZmZpYyB3
aXRoIDEvcCBjb25nZXN0aW9uIGNvbnRyb2wuDQoNCk1pY2hhZWwgKHdpdGggbm8gaGF0KQ0KDQoN
Cg0KRnJvbTogQm9iIEJyaXNjb2UgPGluQGJvYmJyaXNjb2UubmV0Pg0KU2VudDogTW9uZGF5LCBO
b3ZlbWJlciAxMSwgMjAxOSAxMDozOSBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5T
Y2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkQGlldGYu
b3JnDQpDYzogdGNwbUBpZXRmLm9yZzsgdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHN2
d2ddIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZA0KDQpNaWNoYWVsLA0KDQpPbiBhIHNpbWls
YXIgcXVlc3Rpb24gb2YgZGVwZW5kZW5jeSBiZXR3ZWVuIGV4cGVyaW1lbnRzLCBJIHRoaW5rIHlv
dSBhbHNvIGV4cHJlc3NlZCBjb25jZXJuIHRoYXQgZWNuLWw0cy1pZCBkZXBlbmRzIG9uIHRoZSBS
QUNLIGV4cGVyaW1lbnQuIEhvd2V2ZXIsIGVjbi1sNHMtaWQgb25seSByZWZlcnMgdG8gUkFDSyBp
bmZvcm1hdGl2ZWx5LCBiZWNhdXNlIGl0IG9ubHkgdXNlcyB0aGUgZ2VuZXJhbCBpZGVhIGJlaGlu
ZCBSQUNLLiBKdXN0IGFzIHF1aWMtcmVjb3ZlcnkgKHN0ZHMgdHJhY2spIHVzZXMgdGhlIGdlbmVy
YWwgaWRlYSBiZWhpbmQgUkFDSyAoZXhwdCB0cmFjaykgYnkgcmVmZXJyaW5nIHRvIGl0IGluZm9y
bWF0aXZlbHkuDQoNCg0KDQpCb2INCk9uIDA0LzExLzIwMTkgMTU6MjYsIEJvYiBCcmlzY29lIHdy
b3RlOg0KTWljaGFlbCwNCg0KVGhhbmsgeW91IGZvciBwb2ludGluZyB0aGlzIG91dCwgbWFueSBt
b250aHMgYWdvIG5vdy4NCg0KVGhlcmUgaXMgbm8gZm9ybWFsIGRlcGVuZGVuY3kgb2YgZHJhZnQt
aWV0Zi10c3Z3Zy1lY24tbDRzLWlkIG9uIEFjY0VDTiwgYXMgZXhwbGFpbmVkIGJlbG93Lg0KDQpG
b3IgYW55IHRyYW5zcG9ydCBwcm90b2NvbCB0byBjb21wbHkgd2l0aCBlY24tbDRzLWlkLCBpdCBu
ZWVkcyBzdWZmaWNpZW50bHkgYWNjdXJhdGUgZmVlZGJhY2sgb2YgdGhlIGV4dGVudCBvZiBDRSBt
YXJraW5nIG9uIHRoZSBmb3J3YXJkIHBhdGguIFlvdSBwb2ludGluZyB0aGlzIG91dCBoYXMgbWFk
ZSBtZSByZWFsaXplIHRoYXQgdGhlcmUgaXMgYSAnbmVlZHMnIHRoYXQgc2hvdWxkIGJlIGEgJ01V
U1QnIGluIHRoZSBzcGVjOg0KDQo0LjIuICBQcmVyZXF1aXNpdGUgVHJhbnNwb3J0IEZlZWRiYWNr
DQoNCkNVUlJFTlQ6DQoNCiAgIEluIGdlbmVyYWwsIGEgc2NhbGFibGUgY29uZ2VzdGlvbiBjb250
cm9sLCBuZWVkcyBmZWVkYmFjayBvZiB0aGUNCg0KICAgZXh0ZW50IG9mIENFIG1hcmtpbmcgb24g
dGhlIGZvcndhcmQgcGF0aC4NClBST1BPU0VEOg0KDQogICBJbiBnZW5lcmFsLCBmb3IgYSB0cmFu
c3BvcnQgcHJvdG9jb2wgdG8gcHJvdmlkZSBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wsDQoN
CiAgIGl0IE1VU1QgcHJvdmlkZSBmZWVkYmFjayBvZiB0aGUNCg0KICAgZXh0ZW50IG9mIENFIG1h
cmtpbmcgb24gdGhlIGZvcndhcmQgcGF0aC4NCg0KSG93ZXZlciwgZWNuLWw0cy1pZCBvbmx5IHNw
ZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgYW55IEw0UyB0cmFuc3BvcnQgcHJvdG9jb2wg
d291bGQgaGF2ZSB0byBzYXRpc2Z5LiBJdCBkb2VzIG5vdCBkZWZpbmUgYSB0cmFuc3BvcnQgcHJv
dG9jb2wgaXRzZWxmLiBTbyBBY2NFQ04gaXMgbm90IGEgbm9ybWF0aXZlIHJlZi4gU28gSSBhbSBh
bHNvIGFsdGVyaW5nIHRoZSB0ZXh0IGEgbGl0dGxlIGZ1cnRoZXIgZG93biwgd2hlcmUgaXQgcmVm
ZXJzIHRvIEFjY0VDTiwgYXMgZm9sbG93czoNCg0KQ1VSUkVOVDoNCg0KICBUQ1A6ICBTdXBwb3J0
IGZvciBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sgKEFjY0VDTg0KDQogICAgICBbSS1ELmlldGYtdGNw
bS1hY2N1cmF0ZS1lY248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2
d2ctZWNuLWw0cy1pZC0wNyNyZWYtSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY24+XSkgYnkgYm90
aCBlbmRzIGlzIGEgcHJlcmVxdWlzaXRlIGZvcg0KDQogICAgICBzY2FsYWJsZSBjb25nZXN0aW9u
IGNvbnRyb2wuDQpQUk9QT1NFRDoNCg0KICBUQ1A6ICBTdXBwb3J0IGZvciBhY2N1cmF0ZSBFQ04g
ZmVlZGJhY2sgKHN1Y2ggYXMgQWNjRUNODQoNCiAgICAgIFtJLUQuaWV0Zi10Y3BtLWFjY3VyYXRl
LWVjbjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRz
LWlkLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbj5dKSBieSBib3RoIGVuZHMgaXMg
YSBwcmVyZXF1aXNpdGUgZm9yDQoNCiAgICAgIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbC4N
ClRoYW5rcyBhZ2FpbiBmb3IgcG9pbnRpbmcgdGhpcyBvdXQuDQpEZXBlbmRlbmNpZXMgYmV0d2Vl
biBFeHBlcmltZW50cw0KDQpUaGUgY2FzZSBvZiBUQ1AgUHJhZ3VlIHByb3ZpZGVzIGEgY291bnRl
ci1hcmd1bWVudDoNCg0KVENQIFByYWd1ZSBjb3VsZCBiZSBzcGVjaWZpZWQgaW4gb25lIG1vbm9s
aXRoaWMgZXhwZXJpbWVudGFsIHNwZWMuDQpPciBpdCBjb3VsZCBiZSBicm9rZW4gZG93biBpbnRv
IGV4cGVyaW1lbnRhbCBjb21wb25lbnRzLCBhbmQgYSB0b3AgbGV2ZWwgZXhwZXJpbWVudGFsIHNw
ZWMgdGhhdCBwdWxscyB0aGVtIGFsbCB0b2dldGhlci4NCg0KVGhlIGxhdHRlciBvcHRpb24gd291
bGQgY3JlYXRlIG11bHRpcGxlIGRlcGVuZGVuY2llcyBvZiBvbmUgZXhwZXJpbWVudCBvbiBvdGhl
cnMuIEJ1dCBJTUhPIHN1Y2ggbW9kdWxhcml0eSBpcyBwcmVmZXJhYmxlIHRvIGEgbW9ub2xpdGhp
YyBzcGVjLiBFc3BlY2lhbGx5IGlmIHNvbWUgb2YgdGhlIGNvbXBvbmVudHMgbWlnaHQgaGF2ZSBv
dGhlciB1c2VzIG91dHNpZGUgb2YgVENQIFByYWd1ZSAod2hpY2ggaXMgZXhhY3RseSB0aGUgY2Fz
ZSB3aXRoIFRDUCBQcmFndWUsIGUuZy4gQWNjRUNOLCBFQ04rKywgUkFDSyBhcmUgYWxsIHBvdGVu
dGlhbGx5IHBhcnRzIG9mIHRoZSBiYXNlIFRDUCBzdGFjaywgYW5kIHBhY2VkLWNoaXJwaW5nIGlz
IHBvdGVudGlhbGx5IHVzYWJsZSBieSBhbnkgb3RoZXIgY29uZ2VzdGlvbiBjb250cm9sIC0gdGhl
c2UgYXJlIGFsbCBleHBlcmltZW50YWwgY29tcG9uZW50IHBhcnRzKS4NCg0KQXMgYW5vdGhlciBl
eGFtcGxlLCBCQlIgd2FzIHdyaXR0ZW4gdXAgYXMgYW4gZXhwZXJpbWVudGFsIGRyYWZ0LCBhbmQg
dGhlIExpbnV4IGltcGxlbWVudGF0aW9uIHVzZXMgUkFDSyAoYWx0aG91Z2ggbm90IG1lbnRpb25l
ZCBpbiB0aGUgZHJhZnQpIHdoaWNoIGlzIGVuYWJsZWQgYnkgZGVmYXVsdCBpbiBMaW51eC4NCg0K
U3VjaCBtb2R1bGFyaXR5IGlzIGdvb2QuDQoNCg0KQm9iDQoNCk9uIDI0LzAzLzIwMTkgMTk6MTUs
IFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCg0KSSBoYXZlIGp1c3QgcGFyc2VkIHRocm91Z2ggZHJh
ZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA2IGFuZCBJIHJ1biBpbnRvIHRoZSBmb2xsb3dpbmcg
c2VudGVuY2U6DQoNCg0KDQpUQ1A6ICBTdXBwb3J0IGZvciBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sg
KEFjY0VDTg0KDQogICAgICBbSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY25dKSBieSBib3RoIGVu
ZHMgaXMgYSBwcmVyZXF1aXNpdGUgZm9yDQoNCiAgICAgIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29u
dHJvbC4gIFRoZXJlZm9yZSwgdGhlIHByZXNlbmNlIG9mIEVDVCgxKSBpbg0KDQogICAgICB0aGUg
SVAgaGVhZGVycyBldmVuIGluIG9uZSBkaXJlY3Rpb24gb2YgYSBUQ1AgY29ubmVjdGlvbiB3aWxs
DQoNCiAgICAgIGltcGx5IHRoYXQgYm90aCBlbmRzIHN1cHBvcnQgQWNjRUNOLiAgSG93ZXZlciwg
dGhlIGNvbnZlcnNlIGRvZXMNCg0KICAgICAgbm90IGFwcGx5LiAgU28gZXZlbiBpZiBib3RoIGVu
ZHMgc3VwcG9ydCBBY2NFQ04sIGVpdGhlciBvZiB0aGUgdHdvDQoNCiAgICAgIGVuZHMgY2FuIGNo
b29zZSBub3QgdG8gdXNlIGEgc2NhbGFibGUgY29uZ2VzdGlvbiBjb250cm9sLCB3aGF0ZXZlcg0K
DQogICAgICB0aGUgb3RoZXIgZW5kJ3MgY2hvaWNlLg0KDQoNCg0KQ2FuIHRoZSBhdXRob3JzIHBs
ZWFzZSBjbGFyaWZ5IHdoZXRoZXIgdGhlcmUgaXMgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBvZiBk
cmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQgb24gZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVj
bj8NCg0KDQoNCklmIHNvLCBJIHRoaW5rIHRoZSBmb3JtYWwgZGVwZW5kZW5jeSBvbiBpbXBsZW1l
bnRpbmcgQWNjRUNOIGhhcyB0byBiZSBzcGVsdCBvdXQgZXhwbGljaXRseS4gSW4gdGhhdCBjYXNl
LCBJIHdvdWxkIGJlIGxvb2tpbmcgZm9yIGEgc3RhdGVtZW50IG9mIHRoZSBzb3J0ICJNVVNUL1NI
T1VMRC9NQVkgaW1wbGVtZW50IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24iIHNvbWV3aGVy
ZS4gSWYgc3VjaCBhIHJlcXVpcmVtZW50IGRvZXMgbm90IGV4aXN0LCBJIHRoaW5rIHRoZSBhYm92
ZSBwYXJhZ3JhcGggaXMgY29uZnVzaW5nLg0KDQoNCg0KQXMgaW5kaXZpZHVhbCBjb250cmlidXRv
ciwgSSB3YW50IHRvIG5vdGUgdGhhdCBJIGRpc2FncmVlIHdpdGggbWFuZGF0b3J5IGRlcGVuZGVu
Y2llcyBiZXR3ZWVuIGV4cGVyaW1lbnRzLiBJIGhhdmUgbWVudGlvbmVkIGluIHRoZSBwYXN0IHRo
YXQgSSBiZWxpZXZlIHRoYXQgZGlmZmVyZW50IGV4cGVyaW1lbnRzIG11c3QgYmUgc3BlY2lmaWVk
IGluZGVwZW5kZW50bHkgb2YgZWFjaCBvdGhlciBhbmQgc2hvdWxkIGJlIGltcGxlbWVudGFibGUg
aW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyLCBzcGVjaWZpY2FsbHkgYWxzbyB0byBiZSBhYmxl
IHRvIGZhaWwgaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyLiBJdCBpcyBwb3NzaWJsZSB0aGF0
IEkgYW0gaW4gdGhlIHJvdWdoIHBhcnQgb2YgdGhlIGNvbnNlbnN1cy4gQnV0IEkgaGF2ZW4ndCBj
aGFuZ2VkIG15IG1pbmQuDQoNCg0KDQpNaWNoYWVsIChhcyBpbmRpdmlkdWFsKQ0KDQoNCg0KDQoN
Cg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9i
IEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2Uu
bmV0Lw0K

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4FA28Drznt8114rzntrzd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
Ow0KCW1zby1zdHlsZS1saW5rOiLDnGJlcnNjaHJpZnQgMyBaY2huIjsNCgltc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5N
c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s
bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltYXJnaW46MGNtOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5iZXJzY2hyaWZ0M1pjaG4NCgl7bXNv
LXN0eWxlLW5hbWU6IsOcYmVyc2NocmlmdCAzIFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5
Ow0KCW1zby1zdHlsZS1saW5rOiLDnGJlcnNjaHJpZnQgMyI7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNEQ3ODt9DQpzcGFuLkhUTUxWb3Jmb3Jt
YXRpZXJ0WmNobg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0K
CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRp
ZXJ0IjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJs
YWNrO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5
Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv
cj0id2hpdGUiIGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNv
IGNhbiB5b3UgY29uZmlybSB0aGF0IGEgVENQIHNlbmRlciBjYW4gdXNlIHRoZSBMNFMgc2Vydmlj
ZSB3aXRob3V0IGltcGxlbWVudGluZyBBY2NFQ04/IEkgYW0gYXNraW5nIGFnYWluIHNpbmNlIHRo
ZXJlDQogaGFzIGJlZW4gc29tZSByZWNlbnQgbGlzdCBkaXNjdXNzaW9uIG9uIHRoYXQsIGUuZy4s
IGdpdmVuIHRoZSBwb2ludHMgcmFpc2VkIGJ5IFNlYmFzdGlhbi4gSSBhbSBhIGJpdCBsb3N0IGhl
cmUgb24gd2hhdCB0aGUgZnV0dXJlIHBsYW4gaW4gTDRTIGFjdHVhbGx5IGlzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5B
bmQgSSBzdGlsbCBmYWlsIHRvIHVuZGVyc3RhbmQgd2h5IGV2ZW4gdGhlIGdlbmVyYWwgaWRlYSBv
ZiBSQUNLIG1hdHRlcnMgdG8gQVFNIGFsZ29yaXRobXMsIHRyYWZmaWMgY2xhc3NpZmllcnMsIG9y
IHByaW9yaXR5DQogc2NoZWR1bGVycyBmb3IgdHJhZmZpYyB3aXRoIDEvcCBjb25nZXN0aW9uIGNv
bnRyb2wgaW4gYSByb3V0ZXIuIFJBQ0sgaGFzIGxvdHMgb2YgbWVyaXRzLCBidXQgbW9zdCBvZiB0
aGVtIGFyZSBJTUhPIGVudGlyZWx5IHVucmVsYXRlZCB0byB0aGUgdmlzaW9uIG9mIEw0Uy4gSeKA
mWQgc3VnZ2VzdCB0byBmb2N1cyBMNFMgb24gc29sdmluZyB0aGUga2V5IHByb2JsZW1zIGZvciB0
cmFmZmljIHdpdGggMS9wIGNvbmdlc3Rpb24gY29udHJvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWljaGFlbCAod2l0
aCBubyBoYXQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk
aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSAmbHQ7aW5AYm9iYnJpc2NvZS5uZXQm
Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxOSAxMDozOSBB
TTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsICZsdDtNaWNoYWVsLlNjaGFyZkBocy1l
c3NsaW5nZW4uZGUmZ3Q7OyBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWRAaWV0Zi5vcmc8YnI+
DQo8Yj5DYzo8L2I+IHRjcG1AaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbdHN2d2ddIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TWlj
aGFlbCw8YnI+DQo8YnI+DQpPbiBhIHNpbWlsYXIgcXVlc3Rpb24gb2YgZGVwZW5kZW5jeSBiZXR3
ZWVuIGV4cGVyaW1lbnRzLCBJIHRoaW5rIHlvdSBhbHNvIGV4cHJlc3NlZCBjb25jZXJuIHRoYXQg
ZWNuLWw0cy1pZCBkZXBlbmRzIG9uIHRoZSBSQUNLIGV4cGVyaW1lbnQuIEhvd2V2ZXIsIGVjbi1s
NHMtaWQgb25seSByZWZlcnMgdG8gUkFDSyBpbmZvcm1hdGl2ZWx5LCBiZWNhdXNlIGl0IG9ubHkg
dXNlcyB0aGUgZ2VuZXJhbCBpZGVhIGJlaGluZCBSQUNLLiBKdXN0IGFzIHF1aWMtcmVjb3ZlcnkN
CiAoc3RkcyB0cmFjaykgdXNlcyB0aGUgZ2VuZXJhbCBpZGVhIGJlaGluZCBSQUNLIChleHB0IHRy
YWNrKSBieSByZWZlcnJpbmcgdG8gaXQgaW5mb3JtYXRpdmVseS48YnI+DQo8YnI+DQo8YnI+DQo8
YnI+DQpCb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDA0LzExLzIwMTkgMTU6MjYsIEJvYiBCcmlzY29lIHdy
b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+TWljaGFlbCw8YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHBv
aW50aW5nIHRoaXMgb3V0LCBtYW55IG1vbnRocyBhZ28gbm93LiA8YnI+DQo8YnI+DQpUaGVyZSBp
cyBubyBmb3JtYWwgZGVwZW5kZW5jeSBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQgb24g
QWNjRUNOLCBhcyBleHBsYWluZWQgYmVsb3cuPGJyPg0KPGJyPg0KRm9yIGFueSB0cmFuc3BvcnQg
cHJvdG9jb2wgdG8gY29tcGx5IHdpdGggZWNuLWw0cy1pZCwgaXQgbmVlZHMgc3VmZmljaWVudGx5
IGFjY3VyYXRlIGZlZWRiYWNrIG9mIHRoZSBleHRlbnQgb2YgQ0UgbWFya2luZyBvbiB0aGUgZm9y
d2FyZCBwYXRoLiBZb3UgcG9pbnRpbmcgdGhpcyBvdXQgaGFzIG1hZGUgbWUgcmVhbGl6ZSB0aGF0
IHRoZXJlIGlzIGEgJ25lZWRzJyB0aGF0IHNob3VsZCBiZSBhICdNVVNUJyBpbiB0aGUgc3BlYzo8
YnI+DQo8YnI+DQo0LjIuJm5ic3A7IFByZXJlcXVpc2l0ZSBUcmFuc3BvcnQgRmVlZGJhY2s8YnI+
DQo8YnI+DQpDVVJSRU5UOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0i
RU4tVVMiPiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFsLCBhIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29u
dHJvbCwgbmVlZHMgZmVlZGJhY2sgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgZXh0ZW50IG9mIENFIG1hcmtpbmcgb24g
dGhlIGZvcndhcmQgcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QUk9QT1NFRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgSW4gZ2VuZXJhbCw8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA5OTAwIj4gZm9yIGEgdHJhbnNwb3J0
IHByb3RvY29sIHRvIHByb3ZpZGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBzY2FsYWJsZSBj
b25nZXN0aW9uIGNvbnRyb2wsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6IzAwOTkwMCI+aXQgTVVTVCBwcm92aWRlPC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIj4gZmVlZGJhY2sgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgZXh0ZW50IG9mIENFIG1hcmtpbmcgb24gdGhlIGZv
cndhcmQgcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpIb3dldmVyLCBlY24tbDRzLWlkIG9ubHkgc3BlY2lm
aWVzIHRoZSByZXF1aXJlbWVudHMgdGhhdCBhbnkgTDRTIHRyYW5zcG9ydCBwcm90b2NvbCB3b3Vs
ZCBoYXZlIHRvIHNhdGlzZnkuIEl0IGRvZXMgbm90IGRlZmluZSBhIHRyYW5zcG9ydCBwcm90b2Nv
bCBpdHNlbGYuIFNvIEFjY0VDTiBpcyBub3QgYSBub3JtYXRpdmUgcmVmLiBTbyBJIGFtIGFsc28g
YWx0ZXJpbmcgdGhlIHRleHQgYSBsaXR0bGUgZnVydGhlciBkb3duLCB3aGVyZSBpdCByZWZlcnMN
CiB0byBBY2NFQ04sIGFzIGZvbGxvd3M6PGJyPg0KPGJyPg0KQ1VSUkVOVDo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgVENQOiZuYnNwOyBTdXBw
b3J0IGZvciBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sgKEFjY0VDTjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll
dGYtdHN2d2ctZWNuLWw0cy1pZC0wNyNyZWYtSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY24iIHRp
dGxlPSImcXVvdDtNb3JlIEFjY3VyYXRlIEVDTiBGZWVkYmFjayBpbiBUQ1AmcXVvdDsiPjxzcGFu
IGxhbmc9IkVOLVVTIj5JLUQuaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbjwvc3Bhbj48L2E+PHNwYW4g
bGFuZz0iRU4tVVMiPl0pIGJ5IGJvdGggZW5kcyBpcyBhIHByZXJlcXVpc2l0ZSBmb3I8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UFJP
UE9TRUQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i
c3A7IFRDUDombmJzcDsgU3VwcG9ydCBmb3IgYWNjdXJhdGUgRUNOIGZlZWRiYWNrICg8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA5OTAwIj5zdWNoIGFzIDwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+QWNjRUNOPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzwvc3Bhbj48
YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24t
bDRzLWlkLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbiIgdGl0bGU9IiZxdW90O01v
cmUgQWNjdXJhdGUgRUNOIEZlZWRiYWNrIGluIFRDUCZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMi
PkktRC5pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+
XSkgYnkgYm90aCBlbmRzIGlzIGEgcHJlcmVxdWlzaXRlIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g
bGFuZz0iRU4tVVMiPlRoYW5rcyBhZ2FpbiBmb3IgcG9pbnRpbmcgdGhpcyBvdXQuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPGgzPjxzcGFuIGxhbmc9IkVOLVVTIj5EZXBlbmRlbmNpZXMgYmV0d2Vl
biBFeHBlcmltZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvaDM+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpU
aGUgY2FzZSBvZiBUQ1AgUHJhZ3VlIHByb3ZpZGVzIGEgY291bnRlci1hcmd1bWVudDo8YnI+DQo8
YnI+DQpUQ1AgUHJhZ3VlIGNvdWxkIGJlIHNwZWNpZmllZCBpbiBvbmUgbW9ub2xpdGhpYyBleHBl
cmltZW50YWwgc3BlYy4gPGJyPg0KT3IgaXQgY291bGQgYmUgYnJva2VuIGRvd24gaW50byBleHBl
cmltZW50YWwgY29tcG9uZW50cywgYW5kIGEgdG9wIGxldmVsIGV4cGVyaW1lbnRhbCBzcGVjIHRo
YXQgcHVsbHMgdGhlbSBhbGwgdG9nZXRoZXIuPGJyPg0KPGJyPg0KVGhlIGxhdHRlciBvcHRpb24g
d291bGQgY3JlYXRlIG11bHRpcGxlIGRlcGVuZGVuY2llcyBvZiBvbmUgZXhwZXJpbWVudCBvbiBv
dGhlcnMuIEJ1dCBJTUhPIHN1Y2ggbW9kdWxhcml0eSBpcyBwcmVmZXJhYmxlIHRvIGEgbW9ub2xp
dGhpYyBzcGVjLiBFc3BlY2lhbGx5IGlmIHNvbWUgb2YgdGhlIGNvbXBvbmVudHMgbWlnaHQgaGF2
ZSBvdGhlciB1c2VzIG91dHNpZGUgb2YgVENQIFByYWd1ZSAod2hpY2ggaXMgZXhhY3RseSB0aGUg
Y2FzZSB3aXRoIFRDUA0KIFByYWd1ZSwgZS5nLiBBY2NFQ04sIEVDTiYjNDM7JiM0MzssIFJBQ0sg
YXJlIGFsbCBwb3RlbnRpYWxseSBwYXJ0cyBvZiB0aGUgYmFzZSBUQ1Agc3RhY2ssIGFuZCBwYWNl
ZC1jaGlycGluZyBpcyBwb3RlbnRpYWxseSB1c2FibGUgYnkgYW55IG90aGVyIGNvbmdlc3Rpb24g
Y29udHJvbCAtIHRoZXNlIGFyZSBhbGwgZXhwZXJpbWVudGFsIGNvbXBvbmVudCBwYXJ0cykuDQo8
YnI+DQo8YnI+DQpBcyBhbm90aGVyIGV4YW1wbGUsIEJCUiB3YXMgd3JpdHRlbiB1cCBhcyBhbiBl
eHBlcmltZW50YWwgZHJhZnQsIGFuZCB0aGUgTGludXggaW1wbGVtZW50YXRpb24gdXNlcyBSQUNL
IChhbHRob3VnaCBub3QgbWVudGlvbmVkIGluIHRoZSBkcmFmdCkgd2hpY2ggaXMgZW5hYmxlZCBi
eSBkZWZhdWx0IGluIExpbnV4Lg0KPGJyPg0KPGJyPg0KU3VjaCBtb2R1bGFyaXR5IGlzIGdvb2Qu
PGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAyNC8wMy8y
MDE5IDE5OjE1LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBqdXN0IHBhcnNlZCB0aHJv
dWdoIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNiBhbmQgSSBydW4gaW50byB0aGUgZm9s
bG93aW5nIHNlbnRlbmNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj5UQ1A6Jm5ic3A7IFN1cHBvcnQgZm9yIGFjY3VyYXRlIEVDTiBmZWVkYmFjayAoQWNj
RUNOPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW0ktRC5pZXRmLXRjcG0tYWNjdXJhdGUtZWNuXSkg
YnkgYm90aCBlbmRzIGlzIGEgcHJlcmVxdWlzaXRlIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbC4mbmJzcDsgVGhlcmVmb3JlLCB0aGUgcHJlc2Vu
Y2Ugb2YgRUNUKDEpIGluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIElQIGhlYWRlcnMgZXZl
biBpbiBvbmUgZGlyZWN0aW9uIG9mIGEgVENQIGNvbm5lY3Rpb24gd2lsbDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGltcGx5IHRoYXQgYm90aCBlbmRzIHN1cHBvcnQgQWNjRUNOLiZuYnNwOyBIb3dl
dmVyLCB0aGUgY29udmVyc2UgZG9lczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vdCBhcHBseS4m
bmJzcDsgU28gZXZlbiBpZiBib3RoIGVuZHMgc3VwcG9ydCBBY2NFQ04sIGVpdGhlciBvZiB0aGUg
dHdvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz
cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW5kcyBjYW4gY2hvb3NlIG5vdCB0byB1c2UgYSBz
Y2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wsIHdoYXRldmVyPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdGhlIG90aGVyIGVuZCdzIGNob2ljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+Q2FuIHRoZSBhdXRob3JzIHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIg
dGhlcmUgaXMgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1s
NHMtaWQgb24gZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbj88bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SWYgc28sIEkgdGhpbmsgdGhlIGZvcm1hbCBk
ZXBlbmRlbmN5IG9uIGltcGxlbWVudGluZyBBY2NFQ04gaGFzIHRvIGJlIHNwZWx0IG91dCBleHBs
aWNpdGx5LiBJbiB0aGF0IGNhc2UsIEkgd291bGQgYmUgbG9va2luZyBmb3IgYSBzdGF0ZW1lbnQg
b2YgdGhlIHNvcnQgJnF1b3Q7TVVTVC9TSE9VTEQvTUFZIGltcGxlbWVudCBkcmFmdC1pZXRmLXRj
cG0tYWNjdXJhdGUtZWNuJnF1b3Q7IHNvbWV3aGVyZS4gSWYgc3VjaCBhIHJlcXVpcmVtZW50IGRv
ZXMgbm90IGV4aXN0LCBJIHRoaW5rIHRoZSBhYm92ZSBwYXJhZ3JhcGggaXMgY29uZnVzaW5nLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBpbmRpdmlk
dWFsIGNvbnRyaWJ1dG9yLCBJIHdhbnQgdG8gbm90ZSB0aGF0IEkgZGlzYWdyZWUgd2l0aCBtYW5k
YXRvcnkgZGVwZW5kZW5jaWVzIGJldHdlZW4gZXhwZXJpbWVudHMuIEkgaGF2ZSBtZW50aW9uZWQg
aW4gdGhlIHBhc3QgdGhhdCBJIGJlbGlldmUgdGhhdCBkaWZmZXJlbnQgZXhwZXJpbWVudHMgbXVz
dCBiZSBzcGVjaWZpZWQgaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyIGFuZCBzaG91bGQgYmUg
aW1wbGVtZW50YWJsZSBpbmRlcGVuZGVudGx5IG9mIGVhY2ggb3RoZXIsIHNwZWNpZmljYWxseSBh
bHNvIHRvIGJlIGFibGUgdG8gZmFpbCBpbmRlcGVuZGVudGx5IG9mIGVhY2ggb3RoZXIuIEl0IGlz
IHBvc3NpYmxlIHRoYXQgSSBhbSBpbiB0aGUgcm91Z2ggcGFydCBvZiB0aGUgY29uc2Vuc3VzLiBC
dXQgSSBoYXZlbid0IGNoYW5nZWQgbXkgbWluZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJFTi1VUyI+TWljaGFlbCAoYXMgaW5kaXZpZHVhbCk8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBs
YW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2JvYmJy
aXNjb2UubmV0LyI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L3Nw
YW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8
YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9h
PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4FA28Drznt8114rzntrzd_--


From nobody Mon Nov 11 02:30:49 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 F19AA120059; Mon, 11 Nov 2019 02:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] autolearn=unavailable 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 b7eyNBMHKsFc; Mon, 11 Nov 2019 02:30:35 -0800 (PST)
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 84DCB12012E; Mon, 11 Nov 2019 02:30:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id BE97D25A17; Mon, 11 Nov 2019 11:30:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573468232; bh=mASq9UAZYkcUF20v7hPScn0RNy+B5Rx1eiBOoOZtg40=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mIvsCzDDZV0OeAYt+icNzIHk1uMqXBZPQW+l24jqMsTJbajTDyLrXDADc3AmlcbnG dtDu/7XqbpIl8iOHc4tmjW1jDRYweWYOvIm5C2e8cWSTqU6+48ATujtI0nfRIjetLQ iLTJkDV8glkZtB9BcaqQOKIl7qMR7thn/u7OnYFU=
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 oIP6_4w8tPl2; Mon, 11 Nov 2019 11:30:30 +0100 (CET)
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; Mon, 11 Nov 2019 11:30:30 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 11 Nov 2019 11:30:30 +0100
From: "Scharf, Michael" 
To: Ingemar Johansson S , Sebastian Moeller , Ingemar Johansson S , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] [tcpm]  L4S status tracking
Thread-Index: AQHVlHDo/QyQY/CFY0WIa8bThLkPwaeBc3oAgAAjRRCABBjMAIAAHI2Q
Date: Mon, 11 Nov 2019 10:30:29 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4FA3A2@rznt8114.rznt.rzdir.fht-esslingen.de>
References:    <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: Mon, 11 Nov 2019 10:30:39 -0000

SW5kZWVkLCB3ZSB3aWxsIGZpbmQgYSB3YXkgdG8gZmlndXJlIG91dCB3aGF0IHRoZSBjb25zZW5z
dXMgaXMuDQoNCkBhbGw6IElucHV0IHRvIHRoZSBUQ1BNIChhbmQgVFNWV0cpIGNoYWlycyBpcyB3
ZWxjb21lLCBzbyB0aGF0IHdlIGNhbiBwcmVwYXJlIGEgd2VsbC1zdHJ1Y3R1cmVkIGRpc2N1c3Np
b24gYW5kIGhvcGVmdWxseSBmaW5kIGEgc29sdXRpb24gdGhhdCB3b3JrcyByZWFzb25hYmx5IHdl
bGwgZm9yIGFsbC4NCg0KTWljaGFlbCANCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20+DQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTkgMTA6NDQgQU0NCj4g
VG86IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgU2Vi
YXN0aWFuIE1vZWxsZXINCj4gPG1vZWxsZXIwQGdteC5kZT47IEluZ2VtYXIgSm9oYW5zc29uIFMN
Cj4gPGluZ2VtYXIucy5qb2hhbnNzb249NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Ow0K
PiA0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldA0KPiBDYzogdGNwbUBpZXRmLm9yZzsgdHN2d2dAaWV0
Zi5vcmc7IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nz
b24uY29tPg0KPiBTdWJqZWN0OiBSRTogW3RzdndnXSBbdGNwbV0gTDRTIHN0YXR1cyB0cmFja2lu
Zw0KPiANCj4gSGkNCj4gSSBiZWxpZXZlIHRoYXQgaXQgaXMgYmVzdCB0aGF0IEkgbGVhdmUgdGhp
cyBkaXNjdXNzaW9uIGZvciB0aGUgdGltZSBiZWluZywgSSBndWVzcw0KPiB0aGF0IGl0IHdpbGwg
YmUgYnJvdWdodCB1cCBhZ2FpbiBpbiBzb21lIG9yZ2FuaXplZCBmYXNoaW9uLiBIb3BlZnVsbHkg
dGhlbiBpdCB3aWxsDQo+IG5vdCBlYXQgdXAgYWxsIHRoZSBtZWV0aW5nIHRpbWUgOi18DQo+IA0K
PiAvSW5nZW1hcg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPg0KPiA+IFNl
bnQ6IGRlbiA4IG5vdmVtYmVyIDIwMTkgMTk6NDENCj4gPiBUbzogSW5nZW1hciBKb2hhbnNzb24g
UyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyBTZWJhc3RpYW4NCj4gPiBNb2Vs
bGVyIDxtb2VsbGVyMEBnbXguZGU+OyBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+ID4gPGluZ2VtYXIu
cy5qb2hhbnNzb249NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Ow0KPiA+IDRib25lQGdu
ZHJzaC5kbnNtZ3IubmV0DQo+ID4gQ2M6IHRjcG1AaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQo+
ID4gU3ViamVjdDogUkU6IFt0c3Z3Z10gW3RjcG1dIEw0UyBzdGF0dXMgdHJhY2tpbmcNCj4gPg0K
PiA+IEhpIEluZ2VtYXIsDQo+ID4NCj4gPiBBIHF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9uLCBn
aXZlbiB0aGF0IHRoZSB0ZXJtICJjbGFzc2ljIiBpcyB1c2VkIGZvciBkaWZmZXJlbnQNCj4gPiBh
c3BlY3RzIGluIEw0UzoNCj4gPg0KPiA+IERvZXMgeW91ciBwcmVmZXJlbmNlIGluY2x1ZGUgdGhl
IHRlcm1zICdDbGFzc2ljJyBUQ1AgYW5kICdDbGFzc2ljJyBjb25nZXN0aW9uDQo+ID4gY29udHJv
bCwgc3BlY2lmaWNhbGx5IHdoZW4gcmVmZXJyaW5nIHRvIGEgc3RhdGUtb2YtdGhlLWFydCBUQ1Ag
c3RhY2sgYXMNCj4gY3VycmVudGx5DQo+ID4gc2hpcHBlZCBieSBtYWpvciBvcGVyYXRpbmcgc3lz
dGVtcz8NCj4gPg0KPiA+IElmIHNvLCBjYW4geW91IHByb3ZpZGUgcmVmZXJlbmNlcyBmb3IgdXNl
IG9mIHRoZSB0ZXJtcyAnQ2xhc3NpYycgVENQIGFuZA0KPiAnQ2xhc3NpYycNCj4gPiBjb25nZXN0
aW9uIGNvbnRyb2wgZm9yIHdoYXQgaXMgY3VycmVudGx5IHdpZGVseSBkZXBsb3llZCBpbiB0aGUg
SW50ZXJuZXQ/DQo+ID4NCj4gPiBUaGFua3MNCj4gPg0KPiA+IE1pY2hhZWwNCj4gPg0KPiA+DQo+
ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBJbmdlbWFy
IEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPiA+IFNl
bnQ6IEZyaWRheSwgTm92ZW1iZXIgOCwgMjAxOSA2OjA0IFBNDQo+ID4gPiBUbzogU2ViYXN0aWFu
IE1vZWxsZXIgPG1vZWxsZXIwQGdteC5kZT47IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPiA+IDxp
bmdlbWFyLnMuam9oYW5zc29uPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPjsgU2NoYXJm
LCBNaWNoYWVsDQo+ID4gPiA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgNGJvbmVA
Z25kcnNoLmRuc21nci5uZXQNCj4gPiA+IENjOiB0Y3BtQGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9y
ZzsgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+ID4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nz
b24uY29tPg0KPiA+ID4gU3ViamVjdDogUkU6IFt0c3Z3Z10gW3RjcG1dIEw0UyBzdGF0dXMgdHJh
Y2tpbmcNCj4gPiA+DQo+ID4gPiBIaSBTZWJhc3RpYW4NCj4gPiA+DQo+ID4gPiBJIGNsZWFybHkg
bWVudGlvbmVkIHRoYXQgSSB3b3VsZCBwcmVmZXIgdGhhdCB0aGUgdGVybSAiY2xhc3NpYyIgaXMN
Cj4gPiA+IGtlcHQsIHRoZSBlYXJ0aCB3aWxsIGxpa2VseSBjb250aW51ZSB0byBzcGluIGFyb3Vu
ZCBpdHMgYXhpcyBldmVuIGlmDQo+ID4gPiBpdCBpcyBjaGFuZ2VkIHRvIHNvbWV0aGluZyBlbHNl
DQo+ID4gPiDwn5iKLiBCdXQgdGhlbiBpdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgdGhlIGdy
b3VwIGNhbiBhZ3JlZSBvbiwgSQ0KPiA+ID4gZG9uJ3QgaG93ZXZlciBzZWUgYW55IGNvbnNlbnN1
cy4NCj4gPiA+DQo+ID4gPiAvSW5nZW1hcg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogU2ViYXN0aWFuIE1vZWxsZXIgPG1vZWxsZXIwQGdt
eC5kZT4NCj4gPiA+ID4gU2VudDogZGVuIDYgbm92ZW1iZXIgMjAxOSAwODowOA0KPiA+ID4gPiBU
bzogSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+ID4gPiA8aW5nZW1hci5zLmpvaGFuc3Nvbj00MGVy
aWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz47DQo+ID4gPiA+IE1pY2hhZWwuU2NoYXJmQGhzLSBl
c3NsaW5nZW4uZGU7IDRib25lQGduZHJzaC5kbnNtZ3IubmV0DQo+ID4gPiA+IENjOiBJbmdlbWFy
IEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT47DQo+ID4gPiB0
Y3BtQGlldGYub3JnOw0KPiA+ID4gPiB0c3Z3Z0BpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBS
ZTogW3RzdndnXSBbdGNwbV0gTDRTIHN0YXR1cyB0cmFja2luZw0KPiA+ID4gPg0KPiA+ID4gPiBI
aSBJbmdtYXIsDQo+ID4gPiA+DQo+ID4gPiA+IElNSE8gdGhpcyBpcyBhIHNsaXBwZXJ5IHNsb3Bl
IGFyZ3VtZW50LiBCZWNhdXNlIGlmIG1pbm9yIGNoYW5nZXMgdG8NCj4gPiA+ID4gdGhlDQo+ID4g
PiBuYW1pbmcNCj4gPiA+ID4gYXJlICJpbXBvc3NpYmxlIiBob3cgd2lsbCBjaGFuZ2VkIHRvIHRo
ZSB1bmRlcmx5aW5nIGNvbmNlcHRzIGFuZA0KPiA+ID4gPiBtZXRob2RzDQo+ID4gPiBiZQ0KPiA+
ID4gPiBhY2NlcHRhYmxlIHRvIHlvdS4gQmVjYXVzZSBzdXJlbHkgdGhlc2Ugb3RoZXIgb3JnYW5p
emF0aW9ucyBhbHJlYWR5DQo+ID4gPiBjb21taXR0ZWQNCj4gPiA+ID4gdG8gd2hhdCBpcyBwcm9w
b3NlZCB0byB0aGUgSUVURiBhcyBhbiBleHBlcmltZW50Pw0KPiA+ID4gPiBNeSBncmlwZSB3aXRo
IHRoZSBjbGFzc2ljIG1vbmlrZXIgaXMgdGhhdCB0aGlzIHRlcm0gaXMgbm90IG91dGNvbWUgbmV1
dHJhbC4NCj4gPiA+IFdoYXQNCj4gPiA+ID4gSSBtZWFuIGlzLCB0aGF0IHdoaWxlIGluIGl0c2Vs
ZiBub3QgbmVjZXNzYXJpbHkgbmVnYXRpdmUsIGl0IGltcGxpZXMNCj4gPiA+ID4gdGhhdCB0aGUg
bmV3DQo+ID4gPiBraWQNCj4gPiA+ID4gb24gdGhlIGJsb2NrIGlzIHRoZSB3YXkgaW50byB0aGUg
ZnV0dXJlLCB3aGlsZSB0aGUgY2xhc3NpYyB2ZXJzaW9uDQo+ID4gPiA+IHNob3VsZCBoZWFkDQo+
ID4gPiBpbnRvDQo+ID4gPiA+IGl0J3Mgd2VsbC1kZXNlcnZlZCByZXRpcmVtZW50LiBBbmQgb24g
dGhlIGZhY3RzIHRoaXMgc2ltcGx5IGlzIG5vdA0KPiA+ID4gPiBzZXR0bGVkIG9yIGFjY2VwdGVk
IGluIHRoZSBjYXNlIG9mIEw0Uy4gSU1ITyB0aGUgdGVzdGluZyBwdWJsaXNoZWQNCj4gPiA+ID4g
YnkgdGhlIEw0Uy9SSVRFIGZvbGtzIGFsd2F5cyB0ZXN0ZWQgY29uZGl0aW9ucyB0aGF0IGFyZSB2
ZXJ5DQo+ID4gPiA+IGZhdm9yYWJsZSB0byBMNFMgYW5kIGNvbXBsZXRlbHkNCj4gPiA+IGlnbm9y
ZWQNCj4gPiA+ID4gdG8gcmVhY2ggb3V0IHRvIHRoZSBhY3R1YWwgdXNlciBjb21tdW5pdHkgaW50
ZXJlc3RlZCBpbiBsb3cgbGF0ZW5jeQ0KPiA+ID4gPiB1bmRlcg0KPiA+ID4gbG9hZC4NCj4gPiA+
ID4gSXQgbWlnaHQgd2VsbCBiZSB0aGF0IHRoZSBMNFMgYXBwcm9hY2ggbWlnaHQgYWxzbyBkbyB3
ZWxsIGluIGEgdHJ1ZQ0KPiA+ID4gPiBzdHJlc3MgdGVzdA0KPiA+ID4gKGJpLQ0KPiA+ID4gPiBk
aXJlY3Rpb21hbCBzYXR1cmF0aW9uIG9uIGEgYXN5bW1ldHJpYyBwYXRoIHdpdGggYnVyc3R5IGNy
b3NzDQo+ID4gPiA+IHRyYWZmaWMgZm9yIHN0YXJ0ZXJzKSwgYnV0IEkgd291bGQgbGlrZSB0byBz
ZWUgbnVtYmVycyBmaXJzdC4gQW5kDQo+ID4gPiA+IHRoZSBMNFMgc2NlIGJhY2stb2ZmIGRhdGEg
cG9zdGVkIHRvIHRoaXMgbGlzdCBpbiB0aGUgcGF0aCBzZWVtcyB0bw0KPiA+ID4gPiBpbmRpY2F0
ZSB0aGF0IEw0UyBzdGlsbCBoYXMgb3BlbiBlbmRzDQo+ID4gPiB0aGF0DQo+ID4gPiA+IElNSE8g
bmVlZCBhZGRyZXNzaW5nIChpbmRlcGVuZGVudCBvZiB3aGV0aGVyIDNHUFAgbGlrZXMgdGhpcyBv
ciBub3QpLg0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0IFJlZ2FyZHMNCj4gPiA+ID4gICAgICAgICBT
ZWJhc3RpYW4NCj4gPiA+ID4NCj4gPiA+ID4gT24gTm92ZW1iZXIgNiwgMjAxOSA3OjEyOjM5IEFN
IEdNVCswMTowMCwgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+ID4gPiA8aW5nZW1hci5zLmpvaGFu
c3Nvbj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+ID4gPiA+ID5IaQ0K
PiA+ID4gPiA+DQo+ID4gPiA+ID5JIHdvdWxkIHByZWZlciB0aGF0IHRoZSB0ZXJtICJDbGFzc2lj
IiBpcyBrZXB0Lg0KPiA+ID4gPiA+TDRTIGlzIG5vdCBhbnltb3JlIGFuIElFVEYgb25seSBtYXR0
ZXIuIFdvcmsgaXMgb25nb2luZyB0byBnZXQNCj4gPiA+ID4gPnN1cHBvcnQgZm9yIEw0UyBpbiAz
R1BQIGZvciA1RyBhbmQgdGhlIGlucHV0IHBhcGVycyB0aGVyZSB1c2UgdGhlIHRlcm0NCj4gPiBj
bGFzc2ljLg0KPiA+ID4gPiA+SXQgaXMgb2YgY291cnNlIHRvbyBsYXRlIGZvciBjaGFuZ2luZyBj
bGFzc2ljIHRvIHNvbWV0aGluZyBlbHNlLA0KPiA+ID4gPiA+YnV0IHRoZW4gaXQgaXMgYXBwcmVj
aWF0ZWQgdGhhdCBJdCBpcyBzb21ldGhpbmcgdGhhdCB0aGUgZ3JvdXAgY2FuDQo+ID4gPiA+ID5h
Z3JlZSBvbiBhbmQgSSBkb24ndCBzZWUgdGhhdCB3ZSBhcmUgdGhlcmUsIHRoZXJlZm9yZSBpdCBp
cyBiZXR0ZXINCj4gPiA+ID4gPnRvIHN0aWNrIHRvICJjbGFzc2ljIi4NCj4gPiA+ID4gPkFuZCB0
byBtZSB0aGUgdGVybSAiY2xhc3NpYyIgZG9lcyBub3Qgc291bmQgbmVnYXRpdmUuDQo+ID4gPiA+
ID4NCj4gPiA+ID4gPi9JbmdlbWFyDQo+ID4gPiA+ID4NCj4gPiA+ID4gPj4gTWVzc2FnZTogMw0K
PiA+ID4gPiA+PiBEYXRlOiBXZWQsIDYgTm92IDIwMTkgMDA6MjI6NDQgKzAwMDANCj4gPiA+ID4g
Pj4gRnJvbTogQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5uZXQ+DQo+ID4gPiA+ID4+IFRv
OiAiU2NoYXJmLCBNaWNoYWVsIiA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPiwgIlJv
ZG5leSBXLg0KPiA+ID4gPiA+PiAJR3JpbWVzIiA8NGJvbmVAZ25kcnNoLmRuc21nci5uZXQ+DQo+
ID4gPiA+ID4+IENjOiBXZXNsZXkgRWRkeSA8d2VzQG10aS1zeXN0ZW1zLmNvbT4sICJ0c3Z3Z0Bp
ZXRmLm9yZyINCj4gPiA+ID4gPj4gCTx0c3Z3Z0BpZXRmLm9yZz4sICJ0Y3BtQGlldGYub3JnIiA8
dGNwbUBpZXRmLm9yZz4NCj4gPiA+ID4gPj4gU3ViamVjdDogUmU6IFt0Y3BtXSBbdHN2d2ddIEw0
UyBzdGF0dXMgdHJhY2tpbmcNCj4gPiA+ID4gPj4gTWVzc2FnZS1JRDogPDdmMWFhNGFlLTA1ZDYt
YjA3Yy01MGIwLQ0KPiA+IGFiODk5YzVjMzBiN0Bib2JicmlzY29lLm5ldD4NCj4gPiA+ID4gPj4g
Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ3aW5kb3dzLTEyNTIiOyBGb3JtYXQ9
ImZsb3dlZCINCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gTWljaGFlbCwgUm9kLA0KPiA+ID4gPiA+
Pg0KPiA+ID4gPiA+PiBBbHRobyBub24tTDRTIGlzIGEgcmVhc29uYWJsZSBpZGVhLCBJIHRoaW5r
IGl0IGhhcyBtb3JlIG9mIGENCj4gPiA+ID4gPj4gbmVnYXRpdmUNCj4gPiA+ID4gPmNvbm5vdGF0
aW9uDQo+ID4gPiA+ID4+IHRoYW4gY2xhc3NpYy4gRm9yIGluc3RhbmNlLCBjb25zaWRlciBkZXNj
cmliaW5nIEFuZHJvaWQgcGhvbmVzIGFzDQo+ID4gPiA+ID5ub24taVBob25lcy4NCj4gPiA+ID4g
Pj4NCj4gPiA+ID4gPj4gQWxzbywgaW4gdGhlIGVjbi1sNHMtaWQgZHJhZnQsIHdlIGludHJvZHVj
ZSB0aGUgcG9zc2liaWxpdHkgdGhhdA0KPiA+ID4gPiA+PiBzb21lDQo+ID4gPiA+ID5vcGVyYXRv
cnMNCj4gPiA+ID4gPj4gbWlnaHQgY2xhc3NpZnkgbm9uLUw0UyB0cmFmZmljIChETlMsIFZvSVAs
IEVGLCBOUUIsIGV0YykgaW50byB0aGUNCj4gPiA+ID4gPnNhbWUNCj4gPiA+ID4gPnF1ZXVlIGFz
DQo+ID4gPiA+ID4+IEw0UyB0cmFmZmljIChhbmQgd2Ugc2F5IHRoYXQgaW4gdGhpcyBjYXNlIHRo
ZSBxdWV1ZSB3b3VsZCBiZQ0KPiA+ID4gPiA+PiBjYWxsZWQNCj4gPiA+ID4gPnRoZQ0KPiA+ID4g
PiA+TG93DQo+ID4gPiA+ID4+IExhdGVuY3kgcXVldWUpLiBUaGlzIHNob3dzIHRoYXQgdGhlIHRl
cm0gbm9uLUw0UyBpcyBub3QgYSBnb29kDQo+ID4gPiA+ID4+IGNob2ljZQ0KPiA+ID4gPiA+Zm9y
DQo+ID4gPiA+ID5hDQo+ID4gPiA+ID4+IG5hbWUsIGJlY2F1c2UgdGhlIHdvcmRzIGl0IGlzIG1h
ZGUgZnJvbSBhbHJlYWR5IGdpdmUgaXQgYSBtZWFuaW5nDQo+ID4gPiA+ID4+IG9mDQo+ID4gPiA+
ID5pdHMNCj4gPiA+ID4gPm93bg0KPiA+ID4gPiA+PiB0aGF0IGNvbmZsaWN0cyB3aXRoIHRoZSBk
ZWZpbml0aW9uIHlvdSB3YW50IGl0IHRvIGhhdmUgaW4gY2VydGFpbg0KPiA+ID4gPiA+Y29udGV4
dHMuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEZvciBleGFtcGxlLCBpZiB5b3UgZGlkIGRlZmlu
ZSB0aGUgbmFtZSAibm9uLWlQaG9uZSIgdG8gbWVhbg0KPiA+ID4gPiA+PiBwaG9uZXMNCj4gPiA+
ID4gPnN1Y2gNCj4gPiA+ID4gPmFzDQo+ID4gPiA+ID4+IEFuZHJvaWQsIFdpbmRvd3MsIGV0Yywg
dGhlbiB5b3Ugd291bGQgZXhwZWN0IHRoZSBwaHJhc2UNCj4gPiA+ID4gPj4gIm5vbi1pUGhvbmUN
Cj4gPiA+ID4gPmtub2NrLQ0KPiA+ID4gPiA+PiBvZmYgcHJvZHVjdHMiIHRvIG1lYW4gImZha2Ug
QW5kcm9pZCBhbmQgV2luZG93cyBwaG9uZXMiLiBIb3dldmVyDQo+ID4gPiA+ID4+IHRoZSBjb25z
dGl0dWVudCBlbGVtZW50cyAibm9uIiBhbmQgImlQaG9uZSIgYWxyZWFkeSBoYXZlIGENCj4gPiA+
ID4gPj4gbWVhbmluZyBvZg0KPiA+ID4gPiA+dGhlaXINCj4gPiA+ID4gPm93biwNCj4gPiA+ID4g
Pj4gc28gaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBwaHJhc2UsIGl0IG1lYW5zICJmYWtlIGlQaG9u
ZXMiLCB3aGljaA0KPiA+ID4gPiA+PiBpcw0KPiA+ID4gPiA+dGhlDQo+ID4gPiA+ID5vcHBvc2l0
ZQ0KPiA+ID4gPiA+PiBvZiB3aGF0IHlvdSB3YW50ZWQuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+
IFRoZSB0ZXJtIENsYXNzaWMgZm9yIHRoZSBub24tTDRTIHNlcnZpY2UsIGl0cyBxdWV1ZSwgaXRz
IHRyYWZmaWMsDQo+ID4gPiA+ID4+IGl0cw0KPiA+ID4gPiA+Y29uZ2VzdGlvbg0KPiA+ID4gPiA+
PiBjb250cm9sLCBldGMuIGlzIGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gb2Yg
dGhlDQo+ID4gPiA+ID4+IGRyYWZ0cywgc28NCj4gPiA+ID4gPkkNCj4gPiA+ID4gPnRoaW5rIGl0
J3MNCj4gPiA+ID4gPj4gYmVzdCB0byBsaXZlIHdpdGggdGhpcyAtIGl0J3Mgbm90IGEgc2lnbmlm
aWNhbnQgcHJvYmxlbS4gSW5kZWVkLA0KPiA+ID4gPiA+PiBpdA0KPiA+ID4gPiA+aGFzDQo+ID4g
PiA+ID5iZWNvbWUgd2lkZWx5DQo+ID4gPiA+ID4+IHVzZWQgYW5kIHdpZGVseSB1bmRlcnN0b29k
IHNpbmNlIDIwMTUsIGFuZCBjaGFuZ2luZyBpdCB0byBub24tTDRTDQo+ID4gPiA+ID4+IG5vdw0K
PiA+ID4gPiA+d291bGQNCj4gPiA+ID4gPj4gY2F1c2UgdW5uZWNlc3NhcnkgY29uZnVzaW9uLg0K
PiA+ID4gPiA+Pg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBCb2INCj4gPiA+
ID4gPj4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gT24gMDQvMTEvMjAxOSAx
OToyMSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4g
SSBhZ3JlZS4gP25vbi1MNFM/IG1heSBiZSBldmVuIGJldHRlci4NCj4gPiA+ID4gPj4gPg0KPiA+
ID4gPiA+PiA+IE1pY2hhZWwNCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+ICpWb246ICpSb2Ru
ZXkgVy4gR3JpbWVzIDxtYWlsdG86NGJvbmVAZ25kcnNoLmRuc21nci5uZXQ+DQo+ID4gPiA+ID4+
ID4gKkdlc2VuZGV0OiAqTW9udGFnLCA0LiBOb3ZlbWJlciAyMDE5IDIwOjE3DQo+ID4gPiA+ID4+
ID4gKkFuOiAqU2NoYXJmLCBNaWNoYWVsIDxtYWlsdG86TWljaGFlbC5TY2hhcmZAaHMtZXNzbGlu
Z2VuLmRlPg0KPiA+ID4gPiA+PiA+ICpDYzogKkJvYiBCcmlzY29lIDxtYWlsdG86aWV0ZkBib2Ji
cmlzY29lLm5ldD47IFdlc2xleSBFZGR5DQo+ID4gPiA+ID4+ID4gPG1haWx0bzp3ZXNAbXRpLXN5
c3RlbXMuY29tPjsgdHN2d2dAaWV0Zi5vcmcNCj4gPiA+ID4gPjxtYWlsdG86dHN2d2dAaWV0Zi5v
cmc+Ow0KPiA+ID4gPiA+PiA+IHRjcG1AaWV0Zi5vcmcgPG1haWx0bzp0Y3BtQGlldGYub3JnPg0K
PiA+ID4gPiA+PiA+ICpCZXRyZWZmOiAqUmU6IFt0Y3BtXSBbdHN2d2ddIEw0UyBzdGF0dXMgdHJh
Y2tpbmcNCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+ID4gWW91IGNhbiBlLmcuIHVzZSA/bm9u
LUw0Uy1lbmFibGVkIFRDUD8uDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gVGVybWlu
b2xvZ3kgZG9lcyBtYXR0ZXIgdG8gbWUgZ2l2ZW4gdGhhdCBJIHN0cm9uZ2x5IGRpc2FncmVlDQo+
ID4gPiA+ID4+ID4gPiB0bw0KPiA+ID4gPiA+YW55DQo+ID4gPiA+ID4+ID4gdXNlIG9mID9tYXJr
ZXRpbmcgbGFuZ3VhZ2U/IHdoZW4gaXQgY29tZXMgdG8gVENQLg0KPiA+ID4gPiA+PiA+DQo+ID4g
PiA+ID4+ID4gTXkgY29uY2VybiBoZXJlIG9mIHVzZSBvZiB0ZXJtcyBsaWtlLCBsZWdhY3ksIGNs
YXNzaWMsIG5ldywgb2xkDQo+ID4gPiA+ID4+ID4gaXMgdGhhdCB0aGV5IGFyZSBwcmV0dHkgbXVj
aCBhbGwgb2YgdGhlIHJlbGF0aXZlIGZyb20gYW5kIHRodXMNCj4gPiA+ID4gPmFtYmlndW91cw0K
PiA+ID4gPiA+PiA+IG92ZXIgdGltZS4NCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+IG5ld1Jl
bm8gaXMgbmV3IG9ubHkgcmVsYXRpdmUgdG8gUmVubywgdGhhdCBpcyBmYWlybHkgY2xlYXIsIGJ1
dA0KPiA+ID4gPiA+PiA+IGlmDQo+ID4gPiA+ID5JDQo+ID4gPiA+ID4+ID4gc2FpZCBuZXdUQ1Ag
b3Igb2xkVENQIHdpdGggd2hhdCBmcmFtZSBzaG91bGQgdGhlIHJlZmVyZW5jZSBiZQ0KPiA+ID4g
PiA+PiA+IGV2YWx1YXRlZC4NCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+IEkgYmVsaWV2ZSBp
biB0aGUgY2FzZSBvZiBMNFMgdGhlIHRpbWUgaW52YXJpYW50IHRlcm0gd291bGQgYmUsDQo+ID4g
PiA+ID4+ID4gYXMgTWljaGFlbCBzdWdnZXN0cyBhYm92ZSwgIm5vbi1MNFMiLj8/IE5vdGUgdGhh
dCBlbmFibGVkIGZvcg0KPiA+ID4gPiA+PiA+IG1lIGlzIGEgbm9pc2Ugd29yZCBpbiB0aGlzIGNv
bnRleHQsIGFuZCBUQ1AgbWF5IG9yIG1heSBub3QgYmUNCj4gPiA+ID4gPj4gPiBuZWVkZWQNCj4g
PiA+ID4gPmRlcGVuZGluZw0KPiA+ID4gPiA+PiA+IG9uIGNvbnRleHQsIGJ1dCBmb3IgbGl0ZXJh
bCByZXBsYWNlbWVudCBvZiBMZWdhY3kgb3IgQ2xhc3NpYw0KPiA+ID4gPiA+Im5vbi1MNFMiDQo+
ID4gPiA+ID4+ID4gaXMgaW52YXJpYW50IG92ZXIgdGltZS4NCj4gPiA+ID4gPj4gPg0KPiA+ID4g
PiA+PiA+IFJvZA0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gPiBNaWNoYWVsDQo+ID4gPiA+
ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IFZvbjogQm9iIEJyaXNjb2U8
bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ+DQo+ID4gPiA+ID4+ID4gPiBHZXNlbmRldDogTW9u
dGFnLCA0LiBOb3ZlbWJlciAyMDE5IDE5OjA5DQo+ID4gPiA+ID4+ID4gPiBBbjogU2NoYXJmLCBN
aWNoYWVsPG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU+Ow0KPiA+ID4gPiA+
V2VzbGV5DQo+ID4gPiA+ID4+ID4gRWRkeTxtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbT47DQo+
ID4gPiA+ID4+ID4gdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KPiA+ID4g
PiA+PiA+ID4gQ2M6IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQo+ID4gPiA+
ID4+ID4gPiBCZXRyZWZmOiBSZTogW3RjcG1dIFt0c3Z3Z10gTDRTIHN0YXR1cyB0cmFja2luZw0K
PiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IE1pY2hhZWwsDQo+ID4gPiA+ID4+ID4gPg0K
PiA+ID4gPiA+PiA+ID4gUHJldmlvdXNseSwgSSBoYXZlIGJlZW4gdG9sZCBub3QgdG8gdXNlIHRo
ZSB0ZXJtIHN0YW5kYXJkIGZvcg0KPiA+ID4gPiA+UkZDcw0KPiA+ID4gPiA+PiA+IHRoYXQgYXJl
IG5vdCBzdGFuZGFyZHMuIFJGQzU2ODEgaXMgJ29ubHknIGEgZHJhZnQgc3RhbmRhcmQuDQo+ID4g
PiA+ID4+ID4gVGhpcyBpcyB3aHksIGluIHRoZSBJRVRGIGF0IGxlYXN0LCBJIGF2b2lkIHVzaW5n
IHRoZSB0ZXJtDQo+ID4gPiA+ID4+ID4gInN0YW5kYXJkIFRDUCBjb25nZXN0aW9uIGNvbnRyb2wi
LiBJIGdlbmVyYWxseSBjYWxsIGl0IFJlbm8NCj4gPiA+ID4gPj4gPiB3aGVuIHJlZmVycmluZyB0
byB0aGUgY29uZ2VzdGlvbiBjb250cm9sLg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+
IEkgaGF2ZSBuZXZlciwgdG8gbXkga25vd2xlZGdlLCB1c2VkIHRoZSB0ZXJtIGNsYXNzaWMgVENQ
LCBvcg0KPiA+ID4gPiA+Y2xhc3NpYw0KPiA+ID4gPiA+PiA+IFRDUCBjb25nZXN0aW9uIGNvbnRy
b2wuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gQW5kIEkgcmFyZWx5IHVzZSB0aGUg
dGVybSBsZWdhY3ksIGFuZCBpZiBJIGRvIEknbSBoYXBweSB0bw0KPiA+ID4gPiA+PiA+ID4gaGF2
ZQ0KPiA+ID4gPiA+PiA+IGFsdGVybmF0aXZlcyBzdWdnZXN0ZWQuDQo+ID4gPiA+ID4+ID4gPg0K
PiA+ID4gPiA+PiA+ID4gSSd2ZSBjaGVja2VkIHRoZSBMNFMgZHJhZnRzLCBhbmQgdGhlcmUgaXMg
b25lIHBocmFzZSB0aGF0IEkNCj4gPiA+ID4gPj4gPiA+IHNoYWxsDQo+ID4gPiA+ID4+ID4gbGVh
dmUgaW4gZWNuLWw0cy1pZDogInRoZSB0cmFkaXRpb25hbCBUQ1AgUmVubyBhZGRpdGl2ZQ0KPiA+
ID4gPiA+PiA+IGluY3JlYXNlIiwgYmVjYXVzZSB0aGlzIGlzIGNvcnJlY3RseSB1c2VkIHRvIG1l
YW4gdGhlDQo+ID4gPiA+ID4+ID4gdHJhZGl0aW9uYWwgaW5jcmVhc2UgKGluIG51bWVyb3VzIEFJ
TUQgQ0NzKSwgbm90IHRyYWRpdGlvbmFsDQo+ID4gPiA+ID4+ID4gVENQLiBUaGVyZSB3YXMgb25l
IG90aGVyIG9jY3VycmVuY2Ugb2YgInRyYWRpdGlvbmFsIFRDUA0KPiA+ID4gPiA+PiA+IHNlbmRl
cnMiIGluIGEgd2hvbGUgcGFyYSBpbiBhbg0KPiA+ID4gPiA+YXBwZW5kaXgNCj4gPiA+ID4gPj4g
PiB0aGF0IGhhcyBqdXN0IGJlZW4gZGVsZXRlZCBhbnl3YXkuIEFuZCBpbiBhcW0tZHVhbHEtY291
cGxlZA0KPiA+ID4gPiA+PiA+IHRoZXJlDQo+ID4gPiA+ID53YXMNCj4gPiA+ID4gPj4gPiBvbmUg
ImxlZ2FjeSBUQ1AgZmxvd3MiIChjaGFuZ2VkIHRvICJDbGFzc2ljIHRyYWZmaWMiIG5vdyBpbiBt
eQ0KPiA+ID4gPiA+bG9jYWwNCj4gPiA+ID4gPj4gPiBjb3B5LCB1c2luZyB0aGUgZGVmaW5lZCB0
ZXJtIGluIGFsbCB0aGUgTDRTIGRyYWZ0cykuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+
ID4gbDRzLWFyY2ggaXMgZ2V0dGluZyBhIGNvbXBsZXRlIG1ha2Utb3ZlciBmb3IgdGVybWlub2xv
Z3ksIHNvDQo+ID4gPiA+ID4+ID4gPiBJDQo+ID4gPiA+ID53aWxsDQo+ID4gPiA+ID4+ID4gY2hl
Y2sgdGhhdCBuZXh0Lg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IGlubGluZS4uLg0K
PiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPiBPbiAyMy8wOC8y
MDE5IDE1OjAxLCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4g
PiA+PiA+ID4gSGkgV2VzLA0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+
ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gST9kIGxpa2UgdG8gYWRkIGEgc21hbGxlciBpdGVtIHRo
YXQgaXMgbW9zdGx5IGVkaXRvcmlhbCBhbmQNCj4gPiA+ID4gPj4gPiA+IGNhbg0KPiA+ID4gPiA+
PiA+IGhvcGVmdWxseSBiZSBzb3J0ZWQganVzdCBvdXQgYnkgcmUtd29yZGluZywgYWxiZWl0IGl0
IG1heQ0KPiA+ID4gPiA+PiA+IHJlcXVpcmUgYSBjYXJlZnVsIGFuYWx5c2lzIG9mIGFsbCBkb2N1
bWVudHMuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+
ID4gPiA+ID4+ID4gPiBBcyBhbHJlYWR5IG5vdGVkIGluDQo+ID4gPiA+ID4+ID4gaHR0cHM6Ly9t
YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90c3Z3Zy96WmtZWktGLQ0KPiA+ID4gPiA+PiBo
RHZXTzNJNU11ZHdwTmtLeUgNCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+WTxodHRwczovL21haWxh
cmNoaXZlLi5pZXRmLm9yZy9hcmNoL21zZy90c3Z3Zy96WmtZWktGLQ0KPiA+ID4gaER2V08zSTVN
dWR3cE5rDQo+ID4gPiA+ID4+ID4gS3lIWT4gLCBJIG9iamVjdCB0byB0aGUgdGVybXMgP3RyYWRp
dGlvbmFsIFRDUD8gYW5kIGFsc28NCj4gPiA+ID4gPj4gPiBLeUhZPiA/Y2xhc3NpYw0KPiA+ID4g
PiA+VENQPw0KPiA+ID4gPiA+PiA+IG9yID9sZWdhY3k/IFRDUCB3aGVuIHJlZmVycmluZyB0byBh
IFRDUCBpbXBsZW1lbnRhdGlvbg0KPiA+ID4gPiA+PiA+IGFjY29yZGluZyB0byBJRVRGIHN0YW5k
YXJkcy10cmFjayBSRkNzLg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+
ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gVG8gbWUgYXMgYSBub24tbmF0aXZlIG5hdGl2ZSBzcGVh
a2VyLCBhbGwgdGhlc2UgdGVybXMgaGF2ZSBhDQo+ID4gPiA+ID4+ID4gbmVnYXRpdmUgY29ubm90
YXRpb24uIEkgYWxzbyB0aGluayB0aGlzIGxhbmd1YWdlIGlzIHR5cGljYWwgdG8NCj4gPiA+ID4g
Pj4gPiBtYXJrZXRpbmcgbWF0ZXJpYWwuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4g
WW91J3JlIGVudGl0bGVkIHRvIHlvdXIgb3BpbmlvbiBidXQsIGFzIGEgbmF0aXZlIHNwZWFrZXIs
IEkNCj4gPiA+ID4gPj4gPiA+IGRvbid0DQo+ID4gPiA+ID4+ID4gdGhpbmsgJ2NsYXNzaWMnIG9y
ICd0cmFkaXRpb25hbCcgYXJlIHBhcnRpY3VsYXJseSBwZWpvcmF0aXZlLA0KPiA+ID4gPiA+PiA+
IHRobw0KPiA+ID4gPiA+dGhleQ0KPiA+ID4gPiA+PiA+IGNhbiBiZSB3aGVuIHVzZWQgaW4gYSBj
b250ZXh0IHRoYXQgaW50ZW5kcyB0aGVtIHRvIGJlLiBUaGV5DQo+ID4gPiA+ID4+ID4gYWxzbw0K
PiA+ID4gPiA+bWVhbg0KPiA+ID4gPiA+PiA+ICJzdG9vZCB0aGUgdGVzdCBvZiB0aW1lIi4gSSBm
aW5kICdsZWdhY3knIGhhcyBhIGNvbm5vdGF0aW9uIG9mDQo+ID4gPiA+ID4+ID4gbWFya2V0aW5n
LXNwZWFrLCBidXQgaXQncyBub3QgdGhhdCBiYWQuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+
PiA+ID4gVGhpcyBpcyBhbiBlbmR1cmluZyBwcm9ibGVtIHdoZW4gdHJ5aW5nIHRvIGltcHJvdmUg
b24gdGhlDQo+ID4gPiA+ID4+ID4gPiBnb29kDQo+ID4gPiA+ID53b3JrDQo+ID4gPiA+ID4+ID4g
dGhhdCBvdGhlciBwZW9wbGUgaGF2ZSBkb25lIGJlZm9yZSB5b3UgKHdoaWNoIGlzIHRoZSBjb250
ZXh0IG9mDQo+ID4gPiA+ID4+ID4gZXZlcnl0aGluZyB3ZSBhcmUgZG9pbmcpLiBXZSBuZWVkIGEg
d29yZCB0aGF0IGRpc3Rpbmd1aXNoZXMgdGhlDQo+ID4gPiA+ID4+ID4gb2xkIGZyb20gdGhlIG5l
dywgYnV0IHdlIGRvbid0IHdhbnQgdG8gY29tcGxldGVseSB0cmFzaCB0aGUNCj4gPiA+ID4gPj4g
PiB0aGluZyB0aGF0DQo+ID4gPiA+ID5oYXMNCj4gPiA+ID4gPj4gPiBhbHJlYWR5IGJlZW4gc3Vj
Y2Vzc2Z1bCwgYnV0IGhhZCBpdHMgZGF5Lg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+
IE5vbmV0aGVsZXNzLCBpdCBpcyBhbHNvIGltcG9ydGFudCBub3QgdG8gYmUgdG9vIHByZWNpb3Vz
DQo+ID4gPiA+ID4+ID4gPiBhYm91dA0KPiA+ID4gPiA+cGFzdA0KPiA+ID4gPiA+PiA+IHdvcmsu
IFdlIGFsbCByZWNvZ25pemUgdGhhdCBSZW5vIFRDUCBpcyB1bnNjYWxhYmxlIGFuZCBoYXMNCj4g
PiA+ID4gPnByb2JsZW1zLg0KPiA+ID4gPiA+PiA+IElNTywgaXQgaXMgT0sgdG8gZGVzY3JpYmUg
dGVjaG5vbG9naWVzIHRoYXQgaGF2ZSBoYWQgdGhlaXIgdGltZQ0KPiA+ID4gPiA+d2l0aA0KPiA+
ID4gPiA+PiA+IG5lZ2F0aXZlIGNvbm5vdGF0aW9ucy4gSW5kZWVkLCB5b3UgaGF2ZSBiZWVuIGFu
IGF1dGhvciAod2l0aA0KPiA+ID4gPiA+PiA+IG1lKSBvZg0KPiA+ID4gPiA+YW4NCj4gPiA+ID4g
Pj4gPiBSRkMgb24gb3BlbiBpc3N1ZXMgaW4gY29uZ2VzdGlvbiBjb250cm9sLg0KPiA+ID4gPiA+
PiA+ID4NCj4gPiA+ID4gPj4gPiA+IEkgbm90aWNlIHlvdSBoYXZlbid0IHN1Z2dlc3RlZCBhbiBh
bHRlcm5hdGl2ZSB0ZXJtIGZvciAidGhlDQo+ID4gPiA+ID50aGluZyhzKQ0KPiA+ID4gPiA+PiA+
IHdlIGFyZSB0cnlpbmcgdG8gaW1wcm92ZSBvbiIuIE5vdCBzdXJwcmlzaW5nLCBiZWNhdXNlIGl0
J3MNCj4gPiA+ID4gPmRpZmZpY3VsdC4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPiBX
aGVuIHdlICh0aGUgTDRTIGRldmVsb3BlcnMpIHdlcmUgZmlyc3QgbG9va2luZyBmb3IgYSB0ZXJt
DQo+ID4gPiA+ID4+ID4gPiBmb3INCj4gPiA+ID4gPnRoZQ0KPiA+ID4gPiA+PiA+IG5vbi1MNFMg
cXVldWUgYW5kIHRoZSBub24tTDRTIHNlcnZpY2UsIHdlIGRpZG4ndCB3YW50IHRvIHVzZQ0KPiA+
ID4gPiA+J2xlZ2FjeScNCj4gPiA+ID4gPj4gPiBmb3IgdGhlIGFib3ZlIHJlYXNvbnMsIGJ1dCB3
ZSBkaWQgd2FudCB0byBpbXBseSBwcmUtZXhpc3RpbmcsDQo+ID4gPiA+ID4+ID4gc28gd2UgZGVj
aWRlZCBvbiAnY2xhc3NpYycsIHdoaWNoIHdlIGFsbCBmZWx0IGhhZCBhIGdlbmVyYWxseQ0KPiA+
ID4gPiA+PiA+IG5ldXRyYWwgY29ubm90YXRpb24sIGJ1dCBzYWlkIHdoYXQgd2UgbWVhbnQuDQo+
ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gRmluYWxseSwgSSBkbyBub3Qgd2FudCB0aGlz
IGlzc3VlIHRvIHRha2UgdXAgYW55IHRpbWUgdGhhdA0KPiA+ID4gPiA+PiA+ID4gd291bGQNCj4g
PiA+ID4gPj4gPiBkZXRyYWN0IGZyb20gdGVjaG5pY2FsIGlzc3Vlcy4NCj4gPiA+ID4gPj4gPiA+
DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IEJvYg0KPiA+
ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+
ID4NCj4gPiA+ID4gPj4gPiA+IE15IHByZWZlcmVkIHRlcm0gd2hlbiByZWZlcnJpbmcgdG8gVENQ
IGFjY29yZGluZyB0bw0KPiA+ID4gPiA+c3RhbmRhcmRzLXRyYWNrDQo+ID4gPiA+ID4+ID4gc3Bl
Y2lmaWNhdGlvbiBpcyA/c3RhbmRhcmQgVENQPy4gSSB3b3VsZCBhbHNvIGJlIGZpbmUgd2l0aA0K
PiA+ID4gPiA+PiA+IG90aGVyDQo+ID4gPiA+ID50ZXJtcw0KPiA+ID4gPiA+PiA+IGFzIGxvbmcg
YXMgdGhleSBhcmUgbmV1dHJhbCBhbmQgbWFrZSBjbGVhciB0aGF0IGV4cGVyaW1lbnRzIGRvDQo+
ID4gPiA+ID4+ID4gbm90IHJlcGxhY2UsIGRlcHJlY2F0ZSwgb3Igb3V0cGVyZm9ybSBzdGFuZGFy
ZHMuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4g
PiA+ID4+ID4gPiBTaW1pbGFybHksIEkgdGhpbmsgdGhhdCB0ZXJtIHN1Y2ggYXMgP2NsYXNzaWM/
IGlzIG5vdA0KPiA+ID4gPiA+PiA+ID4gYXBwcm9wcmlhdGUNCj4gPiA+ID4gPj4gPiBmb3IgdGhl
IFRDUCBzdGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2wgKD9SZW5vPykuIEFzIG9mIHRvZGF5LA0K
PiA+ID4gPiA+PiA+IHRoaXMNCj4gPiA+ID4gPmlzDQo+ID4gPiA+ID4+ID4gdGhlIFRDUCBjb25n
ZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtIG9uIHN0YW5kYXJkcyB0cmFjayB0aGF0DQo+ID4gPiA+
ID4+ID4gaGFzDQo+ID4gPiA+ID5JRVRGDQo+ID4gPiA+ID4+ID4gY29uc2Vuc3VzLiBUaGUgdGVy
bSBpbiB0aGUgVENQTSBjaGFydGVyIGlzID9UQ1Agc3RhbmRhcmQNCj4gPiA+ID4gPj4gPiBjb25n
ZXN0aW9uIGNvbnRyb2w/LiBJIGFsc28gdGhpbmsgdGhhdCB0ZXJtcyBzdWNoIGFzDQo+ID4gPiA+
ID4+ID4gP1Jlbm8tY29tcGF0aWJsZT8gb3IgdGhlIGxpa2Ugd291bGQgYmUgbmV1dHJhbC4NCj4g
PiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4g
PiA+IE5vdGUgdGhhdCBJIGRvIG5vdCBvYmplY3QgdG8gdGhlIHRlcm1zID9jbGFzc2ljIEVDTj8s
ID9sZWdhY3kNCj4gPiA+ID4gPkVDTj8sDQo+ID4gPiA+ID4+ID4gP2xlZ2FjeSBBUU0/IG9yIHRo
ZSBsaWtlLCBpLmUuLCBpZiB0aGUgY29udGV4dCBpcyBFQ04gYW5kIG5vdA0KPiA+ID4gPiA+PiA+
IHNwZWNpZmljYWxseSBUQ1Agb3IgdGhlIFRDUCBjb25nZXN0aW9uIGNvbnRyb2wuIEkgYmVsaWV2
ZSBpdCBpcw0KPiA+ID4gPiA+PiA+IHVwDQo+ID4gPiA+ID50bw0KPiA+ID4gPiA+PiA+IHRoZSBU
U1ZXRyBkbyBkZWNpZGUgaWYgdGhpcyB0ZXJtIHNoYWxsIGJlIHVzZWQgZm9yIGNvbXBsaWFuY2UN
Cj4gPiA+ID4gPj4gPiB0bw0KPiA+ID4gPiA+UkZDDQo+ID4gPiA+ID4+ID4gMzE2OC4gSSBoYXZl
IG5vIHN0cm9uZyBvcGluaW9uIG9uIHRoYXQuIEFzIGZhciBhcyBJIGNhbiBzZWUsDQo+ID4gPiA+
ID4+ID4gbW9zdA0KPiA+ID4gPiA+dXNlDQo+ID4gPiA+ID4+ID4gb2YgdGhlIHRlcm0gP2NsYXNz
aWM/IGlzIGluIHRoaXMgY29udGV4dCBhbmQgSSBkb24/dCBhc2sgZm9yDQo+ID4gPiA+ID5jaGFu
Z2VzDQo+ID4gPiA+ID4+ID4gaW4gdGhvc2UgY2FzZXMuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4g
PiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPiBTb21lIHVzZSBvZiB0aGUg
dGVybSA/Q2xhc3NpYyBTZXJ2aWNlPyBtYXkgYWxzbyByZXF1aXJlDQo+ID4gPiA+ID4+ID4gPiBj
YXJlZnVsDQo+ID4gPiA+ID4+ID4gcmV2aWV3IHRvIGNsZWFybHkgc2VwYXJhdGUgaXQgZnJvbSBU
Q1AgU3RhbmRhcmQgYmVoYXZpb3IuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4g
PiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPiBOb3RlIHRoYXQgc29tZSB1c2Ugb2YgdGhlIHRl
cm0gP0NsYXNzaWMgVENQPyB3b3VsZCBwcm9iYWJseQ0KPiA+ID4gPiA+PiA+ID4gYWxzbw0KPiA+
ID4gPiA+PiA+IGFwcGx5IHRvID9DbGFzc2ljIFFVSUM/IG9uY2UgdGhlIFFVSUMgc3RhbmRhcmQg
aXMgZmluaXNoZWQuIFRvDQo+ID4gPiA+ID4+ID4gbWUNCj4gPiA+ID4gPmFzIGENCj4gPiA+ID4g
Pj4gPiBub24tbmF0aXZlIHNwZWFrZXIsIGl0IHdvdWxkIGJlIHJlYWxseSBzdHJhbmdlIHRvIHVz
ZSB0aGUgdGVybQ0KPiA+ID4gPiA+PiA+ID9jbGFzc2ljPyBpbiB0aGUgY29udGV4dCBvZiBhIGJy
YW5kLW5ldyB0cmFuc3BvcnQgcHJvdG9jb2wuDQo+ID4gPiA+ID4+ID4gSU1ITyBpbiB0aGF0IGNh
c2UgdGhlIHRlcm0gP2NsYXNzaWM/IHdvdWxkIGJlIGV2ZW4gbW9yZSBjb25mdXNpbmcuDQo+ID4g
PiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4g
PiBJIGFsc28gYWRkIHRoZSBUQ1BNIGxpc3QgaW4gQ0MgdG8gZW5zdXJlIGNvbnNpc3RlbmN5Lg0K
PiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+
PiA+ID4gVGhhbmtzDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4g
PiA+DQo+ID4gPiA+ID4+ID4gPiBNaWNoYWVsICh3aXRoIG5vIGhhdCkNCj4gPiA+ID4gPj4gPiA+
DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+
ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gVm9uOiBXZXNsZXkgRWRkeTxtYWlsdG86d2VzQG10aS1z
eXN0ZW1zLmNvbT4NCj4gPiA+ID4gPj4gPiA+IEdlc2VuZGV0OiBTb25udGFnLCAxMS4gQXVndXN0
IDIwMTkgMDc6MDgNCj4gPiA+ID4gPj4gPiA+IEFuOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2
d2dAaWV0Zi5vcmc+DQo+ID4gPiA+ID4+ID4gPiBCZXRyZWZmOiBbdHN2d2ddIEw0UyBzdGF0dXMg
dHJhY2tpbmcNCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4N
Cj4gPiA+ID4gPj4gPiA+IEkgY3JlYXRlZCB0aWNrZXRzIGluIHRoZSBUU1ZXRyAidHJhYyIgdG9v
bCBpbiBvcmRlciB0byBoZWxwDQo+ID4gPiA+ID4+ID4gPiBrZWVwIHRyYWNrIG9mIHRoZSBpbmRp
dmlkdWFsIHRoaW5ncyB0aGF0IGxvb2sgbGlrZSB0aGV5DQo+ID4gPiA+ID4+ID4gPiBzaG91bGQg
YmUgYWRkcmVzc2VkIGluIHByb2dyZXNzaW5nIEw0UyBkb2N1bWVudCBzZXQ6DQo+ID4gPiA+ID4+
ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj
L3RzdndnL3JlcG9ydC8xP3NvcnQ9dGlja2V0JmFzYz0xJnBhZ2U9MQ0KPiA+ID4gPiA+PiA+ID4N
Cj4gPiA+ID4gPj4gPiA+IEknbGwgdHJ5IHRvIHVwZGF0ZSB0aGVzZSBiYXNlZCBvbiB0aGUgb25n
b2luZyBkaXNjdXNzaW9ucywNCj4gPiA+ID4gPnVwZGF0ZXMsDQo+ID4gPiA+ID4+ID4gPiBldGMu
LCBidXQgaXQgd2lsbCBtYWtlIGl0IHZlcnkgZWFzeSBpZiB5b3UgaGFwcGVuIHRvIG1lbnRpb24N
Cj4gPiA+ID4gPj4gPiA+IHRoZSB0aWNrZXQgbnVtYmVycyBvciBzb21lIGtleSB3b3JkcyBpbiB0
aHJlYWRzIGFuZCBtZXNzYWdlcywNCj4gPiA+ID4gPj4gPiA+IHdoZW4NCj4gPiA+ID4gPj4gc2ln
bmlmaWNhbnQuDQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+
DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4+ID4gPiB0
Y3BtIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+PiA+ID4gdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNw
bUBpZXRmLm9yZz4NCj4gPiA+ID4gPj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdGNwbQ0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+
ID4gPg0KPiA+ID4gPiA+PiA+ID4gLS0NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+DQo+ID4g
PiA+DQo+ID4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPj4gPiA+IEJvYiBCcmlzY29lDQo+
ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91
cmw/az05ZTNjZjc3MC1jMmU4ZmI4MS05ZTNjYjdlYi04Ng0KPiA+ID4gPiA+NA0KPiA+ID4gPiA+
PiA+ID4gNjg1YjIwODVjLTRiYTZhMTk2MGM0ZjNlN2EmcT0xJmU9YmY0OWMwZjAtMzgwYi00MmQ0
LTkzYTItDQo+ID4gPiA+ID4+IDllYmVkZmY4MDJlDQo+ID4gPiA+ID4+ID4gPiAwJnU9aHR0cCUz
QSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGDQo+ID4gPiA+ID4+ID4NCj4gPiA+ID4gPj4gPiA+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4+
ID4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+PiA+ID4gdGNwbUBpZXRmLm9yZw0KPiA+
ID4gPiA+PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+
ID4gPiA+ID4+ID4NCj4gPiA+ID4gPj4gPiAtLQ0KPiA+ID4gPiA+PiA+IFJvZCBHcmltZXMgcmdy
aW1lc0BmcmVlYnNkLm9yZw0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiAtLQ0KPiA+ID4gPiA+Pg0K
PiA+ID4gPg0KPiA+ID4NCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4+IEJvYiBCcmlzY29lDQo+
ID4gPiA+ID5odHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTg2MTI0MWE4LQ0K
PiA+ID4gPiA+PiBkYWM2NGQ1OS04NjEyMDEzMy04NjQ2ODViMjA4NWMtDQo+ID4gPiAxNjEyMGEy
N2FiNGE3NTFhJnE9MSZlPWJmNDljMGYwLQ0KPiA+ID4gPiA+PiAzODBiLTQyZDQtOTNhMi05ZWJl
ZGZmODAyZTAmdT1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYNCj4gPiA+ID4gPj4NCj4g
PiA+ID4gPj4gLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tIEFuIEhUTUwg
YXR0YWNobWVudCB3YXMNCj4gPiA+ID4gPj4gc2NydWJiZWQuLi4NCj4gPiA+ID4gPj4gVVJMOg0K
PiA+ID4gPiA+Pg0KPiA+ID4gPiA+PGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9i
cm93c2UvdGNwbS9hdHRhY2htZW50cy8yMDE5MTEwNg0KPiA+ID4gPiA+L2RlNw0KPiA+ID4gPiA+
OTcNCj4gPiA+ID4gPj4gZmQxL2F0dGFjaG1lbnQuaHRtbD4NCj4gPiA+ID4gPj4NCj4gPiA+ID4g
Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+
IFN1YmplY3Q6IERpZ2VzdCBGb290ZXINCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPj4gdGNwbSBt
YWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4gdGNwbUBpZXRmLm9yZw0KPiA+ID4gPiA+PiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gPiA+ID4gPj4NCj4gPiA+ID4g
Pj4NCj4gPiA+ID4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4+
DQo+ID4gPiA+ID4+IEVuZCBvZiB0Y3BtIERpZ2VzdCwgVm9sIDE4NywgSXNzdWUgMTUNCj4gPiA+
ID4gPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+ID4gPg0KPiA+
ID4gPiAtLQ0KPiA+ID4gPiBTZW50IGZyb20gbXkgQW5kcm9pZCBkZXZpY2Ugd2l0aCBLLTkgTWFp
bC4gUGxlYXNlIGV4Y3VzZSBteSBicmV2aXR5Lg0K


From nobody Mon Nov 11 03:41: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 5125A1200FA for ; Mon, 11 Nov 2019 03:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level: 
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 4eBTU4a-PzlA for ; Mon, 11 Nov 2019 03:41:11 -0800 (PST)
Received: from sonic308-1.consmr.mail.bf2.yahoo.com (sonic308-1.consmr.mail.bf2.yahoo.com [74.6.130.40]) (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 1E0321200DB for ; Mon, 11 Nov 2019 03:41:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1573472469; bh=jXWSMpzSOYnCReeFFZX13eVV+5t1aJ32/HmvwYVOn/U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=joK6JvLk6y0ZeiJBtdoXzH9WtaBkQuqmRX/7oU+H5qW/gKNblTGO3+o+hRBdjEcGEQM9B9uUg1fqgTuTA/0BKBkQhIpu8tOmee92QLeWPVJVJ1UaL48eUYFMQ4E9X0wdEs1SrFrz4BnNHFKmT/EFV31kKj/l+2qAtX3kLIdEAKUXfqaQljv2rot2J+r0yDrgmTwsGfGxzfccDGwGiAmHngSIF6h9raDdP/KPZf6fZ++RZb9fHewZHv2ox7xkqIqy5PeqaT5shoyRbFSHh30ac0/3sOICvntkfukucIg1xWXVGc5RwtT8I4Sa0AnDzNdI1RbFiXVEEjtf1boYm0q8Mw==
X-YMail-OSG: iS75k8YVM1koQ6QdvgH6UrGUhLVD_xB9HXMj.s7VBNwuF3vwfS1x_jvDs1JFnUI rScYkDUbECaMo1ZZdZrMLMhfRKK0wIEerX_s_Wsd241JoTbZjU6Jjxf4409a8P535ibleaNi9FKj INdWEWvMaCAWZB3dnkvbdWH4Lr9jH3T0PbGcssYN4IPbDcR9NaljosXVSE5jcCePkeV.ExqRh4d5 i8OLIU.TD5PFx6j.BpykLL6tf90CLuK9zwJwUUQs5smdzZJG2fYx4YqoSzqGhOUY2B6okLpK8Bbb mgEFpfU3xx6akiwyhoWf3U7dS4BRI.JNW4ArmZhRBRnmowYQU_c66DvJgzGM2S3yMY0IQLp2aFZW JPhtE1OubKQvIuWNWt2f2jlVQYpcN5gggdcJkypL78j6sv2ziiutYUTBX9qSLKLVLADOhILq8I3j 1n2xFNuGvjvewzy0rhJ92SwAtVjpIWiccygiO5sUuhU8yBd1xEF7scCKcdVQwoz970u5sH.53Gko nQO2bRM9dtdf61D.6FIDXx_nH4qN_7BuMNt1cBujrnIMofc7LAPypivb3KRflpfByhlNUDhorZuG 7h9fmbvMZXdTe6jhdaDr8UVpdcq1xjRhUCaXt4ctv9dSpV1p4SmvyGTnvVWe18trsxhpBIobZp7m KiTRvaaS.5eEhMJuFdSbpPeENiklCnGJlZUVOPu3p4BrkvbjYKO5VnWzXBsBIlcxvd8le8zsfHxw S_VRCSB7o358U9UhPhcSnBWjmP8inah.KLIZMV_bdBx11Yofj55G7Hvdm4HTdujCjfaUlwDQ5dLU ItH47cxW9PTQPCy7mf51RfYKkONfqQvUWBjfSVPux_f.34CSpT9Z31ySFdF4l9d2J6pKEfxpk8i. Oa5uDXgUkO3HWXoR9rDuuRPuFckJGBBDVgPqed17ltGc.H9_M7615Fjtbqvv4a92X8jYZIDBizy2 mIxkInYKqDydKsYS26slp4QC7CkiKLO0dFW.06ZuWzpE_fhk5ms3MXe6_VWtazFlR1hAQjSvSXEE CwAKXQgLkHFVIlX6YUYdh9ceS.ywYwg2dw9RTl9ro1xxwaTbn.kjmWyjl0Mw.rwd1J1e96Ou3HBF 3OqXaYzGgXboeoA3nIj_PKjnMzwLvI.5H9uRdxRNOCTVhd4n8x6gZ1VdTqaI1CoVICmNW63m.NGn b5cSwpieKQhqb6c3C3n0R3C4MhHXcYNEx14fkCQbTOQp9M0n_ciGQOPT9d8ixogRrzezjxipruIk DBIeLKSAJhUlb.Q6gvassWGKo_LrqHzRWzoO9C1oWiK0FrJP8KtkEkeaUZPn1c30qpVwrTks_dJ8 xLqDOeZ2klAcHWA5yWdiK9AxZx3SL
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Mon, 11 Nov 2019 11:41:09 +0000
Date: Mon, 11 Nov 2019 11:41:05 +0000 (UTC)
From: "alex.burr@ealdwulf.org.uk" 
Reply-To: "alex.burr@ealdwulf.org.uk" 
To: Tom Henderson , Dave Taht 
Cc: tcpm@ietf.org, tsvwg IETF list 
Message-ID: <1369738724.1583995.1573472465758@mail.yahoo.com>
In-Reply-To: <87a7931d1k.fsf@taht.net>
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> <87a7931d1k.fsf@taht.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1583994_884109654.1573472465757"
X-Mailer: WebService/1.1.14680 YMailNorrin Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 11 Nov 2019 11:41:13 -0000

------=_Part_1583994_884109654.1573472465757
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

 (see below)

    On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Taht  wrote:  
 

Cool. If only the dsl and cable worlds had adopted this! it allows for
much smarter handling of packet delivery higher in the stack at the cost
of one interrupt's worth of standing queue. Without BQL we wouldn't be
scaling linux past 10GigE today.

I keep hoping *switches* will start doing bql, also.

[AB] at the CO end (ie downstream) my understanding (which may be out of date) 
is that DSL ICs usually punt queuing to a switch IC. There's a standard (G999.1) which existssolely to enable this (it provides per-subscriber backpressure over ethernet). So, switches doingBQL is exactly what would be required for dsl to do BQL (in the downstream direction).
(Given BQL is a workaround, switches would want to implement a direct solution if they do anything).
Alex



  
------=_Part_1583994_884109654.1573472465757
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        
(see below)

       =20
        

            

               =20
                

                    On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Tah=
t <dave@taht.net> wrote:
                

                


                


Cool. If only the =
dsl and cable worlds had adopted this! it allows for
much smarter handling of packet delivery higher in the stack at the cos=
t
of one interrupt's worth of standing queue. Wit=
hout BQL we wouldn't be
scaling linux past 10GigE=
 today.

I keep hoping =
*switches* will start doing bql, also.

=

[AB] at the CO end (ie downstream) m=
y understanding (which may be out of date) 
is that DSL ICs usually punt queuing to a switch IC. There=
's a standard (G999.1) which exists
solely to enable this (it provides per-subscriber backpressure over et=
hernet). So, switches doing
BQL=
 is exactly what would be required for dsl to do BQL (in the downstream dir=
ection).

(Given BQL is a workaround, switches would want =
to implement a direct solution if they do anything).

Alex=





            

        

------=_Part_1583994_884109654.1573472465757--


From nobody Mon Nov 11 06:42:47 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 85C0C12007C for ; Mon, 11 Nov 2019 06:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 TPHKET2GUqf4 for ; Mon, 11 Nov 2019 06:42:37 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 8A3921207FD for ; Mon, 11 Nov 2019 06:42:37 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id m125so11328863qkd.8 for ; Mon, 11 Nov 2019 06:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=dBTk08Cm+QMU4eeGcxvl25HLH7JBUm2KBZ8QgtbbOrM=; b=DP6QKxa4IBU62mMMsWhaO3GXnC4+jvNajnqoRf31CXpNEcpHsFazDC+tRgXeLHLj2o eRis3z1+D/b3GR2qvthq9e00iTCZCCvnjV8bOP9qenWWDLqalP1QJFTOYCf2EgankEUV nukLS/PX/xWbFh6H/whPM42KC4APWJNxEzUsbzb0Rp4/yCzoL4nCPnUO9djKDC2u1/OZ v3ixnU+bXGhqp9yLfoFj2u0hPV4d9Nv9uahPe3NsecSs+so4Dhg2B3j8vhDdrz/hctGc e69kiBU3StjSrE3tpGsQeApA/vZpLL8gjlIcUDKDUaY7AAGlqpo1KMcHtnsPTdRp/hjn UIKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dBTk08Cm+QMU4eeGcxvl25HLH7JBUm2KBZ8QgtbbOrM=; b=W4ORzuACuEjcmb+nTwbN+43rq6bj/tBkBiLp9fHYqm0Xz4xIB1nsXLiH3BGa9PASrg yODB7PApidshLlU7SR2SIZf2+qKtOZmMOuXmmeImfqyoi4HyIvHXbofG5fYWN+UBeYjN BVfcQDNR1BFhQmdXTJ4pHvdkj1mW+E98gs6WNF3Mbo8xW7Dm/tfKXbkBA2L4XLtj2lRY BPnhSwNlBFsOj4KSqeUg/LJ3Hle2hMMP42xnI6n/aSOvNTnhznSysoOsWzMUAzb4RMwS AT3aJuRcbDuR3ASKYqAoT1WByXaYoP9ifkeTR/ktaKw7+O2cWI0v8JpAg0C9gAgfoPI2 O83A==
X-Gm-Message-State: APjAAAXNUUuVeGK5rVRWJJk2nB9f5RBv2A6FpB917X0TYD99EogdywIH RJToJMQmiTHTp7bmcY3UocLphA==
X-Google-Smtp-Source: APXvYqzvOXFOfELcMxrPdAUQ4RKbtmOEfWgOpMfq4Bz6gHqIILXxiucf4zWrD1prihxKq5vOArmVMA==
X-Received: by 2002:a37:a68d:: with SMTP id p135mr10576239qke.374.1573483356615;  Mon, 11 Nov 2019 06:42:36 -0800 (PST)
Received: from [192.168.1.11] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id t132sm7215393qke.51.2019.11.11.06.42.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 06:42:36 -0800 (PST)
To: tcpm@ietf.org, "tsvwg@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net>  <6EC6417807D9754DA64F3087E2E2E03E2D4FA28D@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Wesley Eddy 
Message-ID: 
Date: Mon, 11 Nov 2019 09:42:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4FA28D@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------A9883BBD9338771DEB9790A4"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
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, 11 Nov 2019 14:42:41 -0000

This is a multi-part message in MIME format.
--------------A9883BBD9338771DEB9790A4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I think both AccECN and RACK are appropriately "informational" 
references in the L4S drafts.

They might be important to TCP Prague code, but the in-network L4S 
pieces don't have a strict dependency.


On 11/11/2019 5:16 AM, Scharf, Michael wrote:
>
> So can you confirm that a TCP sender can use the L4S service without 
> implementing AccECN? I am asking again since there has been some 
> recent list discussion on that, e.g., given the points raised by 
> Sebastian. I am a bit lost here on what the future plan in L4S 
> actually is.
>
> And I still fail to understand why even the general idea of RACK 
> matters to AQM algorithms, traffic classifiers, or priority schedulers 
> for traffic with 1/p congestion control in a router. RACK has lots of 
> merits, but most of them are IMHO entirely unrelated to the vision of 
> L4S. I’d suggest to focus L4S on solving the key problems for traffic 
> with 1/p congestion control.
>

--------------A9883BBD9338771DEB9790A4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I think both AccECN and RACK are appropriately "informational"
      references in the L4S drafts.

    
They might be important to TCP Prague code, but the in-network
      L4S pieces don't have a strict dependency.

    

    


    

    
On 11/11/2019 5:16 AM, Scharf, Michael
      wrote:

    

    

      
      
      
      

        
So can you confirm that a TCP sender can use
            the L4S service without implementing AccECN? I am asking
            again since there has been some recent list discussion on
            that, e.g., given the points raised by Sebastian. I am a bit
            lost here on what the future plan in L4S actually is.

        
 

        
And I still fail to understand why even the
            general idea of RACK matters to AQM algorithms, traffic
            classifiers, or priority schedulers for traffic with 1/p
            congestion control in a router. RACK has lots of merits, but
            most of them are IMHO entirely unrelated to the vision of
            L4S. I’d suggest to focus L4S on solving the key problems
            for traffic with 1/p congestion control.

        
 

      

    

  


--------------A9883BBD9338771DEB9790A4--


From nobody Mon Nov 11 06:59:00 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 A71AE12007C; Mon, 11 Nov 2019 06:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 GPa1Xp3NJ-ps; Mon, 11 Nov 2019 06:58:48 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A84DF12000F; Mon, 11 Nov 2019 06:58:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=tb28LgZB5BEASOd/1y9hvhpMK8jzyczcM8feGTT3kec=; b=cjKS5p5QJlhvSrv4iHJkyNRA4u W7ChdeLuxLXPIImGQSWAfp05HK6DO1qHjaCY0aYh6pEDQ24YmiHMXRZ2KqU7ZfkevzAeMdEogD3dx XPC//MJPu0ESqLbLhEa1QD3que8x+gZ7qFWlsXDlWxAZ1TqaLVkh8B6PO796uEduaZQgz7eZrWBBr NX09S+2tZyDGHdPDNNEmUCahqoxqbsFhELZfNXH0RCeOCvt8X62CgEHsFa7vvKjiFVng9IpGdwsyq wV7rLrRI/pL3yKxJpQqP0JY8wrtULIW6q5Lip//RHQGlMgD/162ZZKMYa8dFdnMS1Dp7QfmYOh5rw WN+JIqEA==;
Received: from [31.185.128.31] (port=55478 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUB9S-0003VU-Jf; Mon, 11 Nov 2019 14:58:46 +0000
To: rgrimes@freebsd.org
Cc: Sebastian Moeller , "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
References: <201911061844.xA6Iihtl011324@gndrsh.dnsmgr.net>
From: Bob Briscoe 
Message-ID: 
Date: Mon, 11 Nov 2019 14:58:45 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <201911061844.xA6Iihtl011324@gndrsh.dnsmgr.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Mon, 11 Nov 2019 14:58:53 -0000

Rod,

On 06/11/2019 18:44, Rodney W. Grimes wrote:
> Bob,
> 	Reply inline with quoted text from draft as to "why" I,
> and probably others are having issues with Classic and your
> terminology.  All IMHO, of cource.
>
> Regards,
> Rod
>
>> Sebastien,
>>
>> On 06/11/2019 07:18, Sebastian Moeller wrote:
>>> Hi Bob,
>>>
>>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe  wrote:
>>>> Michael, Rod,
>>>>
>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative
>>>> connotation than classic.
>>>           [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
>> Which is a good starting point, because that's what is intended. Plus it
>> already has a slightly positive natural meaning of "something robust
>> that has stood the test of time". Then it is defined precisely for the
>> context of each L4S doc, e.g.:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2
> Quoting the whole section inline: (WIth some markers added)
>
>     Classic service:  The 'Classic' service is intended for all the
>     ^A
>        behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
>        Compound, SCTP, etc).
>
>     Low-Latency, Low-Loss and Scalable (L4S) service:  The 'L4S' service
>        is intended for traffic from scalable congestion control
>        algorithms such as Data Center TCP.  But it is also more general--
>        it allows the set of congestion controls with similar scaling
>        properties to DCTCP to evolve (e.g.  Relentless TCP [Mathis09] and
>        the L4S variant of SCREAM for real-time media [RFC8298].
>
>        Both Classic and L4S services can cope with a proportion of
>             ^B
>        unresponsive or less-responsive traffic as well, as long as it
>        does not build a queue (e.g.  DNS, VoIP, game sync datagrams,
>        etc).
>
>     Classic ECN:  The original Explicit Congestion Notification (ECN)
>     ^A
>        protocol [RFC3168].
>
>
> Problem with these terminology definitions:
>
> Classic is used in the names of 2 terms, marked A above, and then
> used without any qualification in the definition of a third term,
> marked as B.  I believe the inference at B is that of "Classic Service".
[BB]
B isn't a third term. The term is 'Classic service' which was just 
defined earlier.

It's regular English that, "Both red and green services..." means "Both 
the red service and the green service..."

Nonetheless, this does make me realize that we need an extra sentence at 
the end of each definition to explain that other nouns can be qualified 
by 'L4S' or 'Classic'. E.g. queue, congestion control, codepoint, 
packet, flow.

> These terminology definintions are fuzzy, due to the use of words
> like "current".  Which current is that?  The date the draft was
> written, the date I am reading the draft?  This is a poor quality
> term definition.
[BB] (When 'currently' is used in an RFC or any text for that matter, 
I'm sure everyone always understands it to mean, "when this was written".)

However, you're right that 'currently' is actually incorrect here, 
because the definition needs to include any Reno-friendly behaviours 
introduced in future as well. Thx. All the L4S drafts use these 
definitions, so I'll remove 'currently' from them all.


> Since I can not put solid definitions of these terms in my mind
> when I read the draft I am always asking myself exactly what is
> "Classic" infering here?
>
> My head spins when I try to parse the above "term" "L4S service",
> and I can not build a solid model from the definition given.  It
> is self referential (L4S is L4S variant of SCREAM).  It has wording
> on what it can cope with.  For me this is not a definition of
> a term.
[BB] Good point. This is indeed not comprehensible without a definition 
of 'scalable congestion control', which we need to copy across from 
l4s-arch.

On "L4S variant of SCREAM", I don't believe it's self-referential, 'cos 
it's given in a list of examples, not as part of the definition. I had 
to call it that, because the variant doesn't have a name of its own.

However, this does make me realize that the use of SCTP as an example of 
a Classic behaviour is not right, because one could build a scalable 
congestion control into SCTP. In the list of examples of Classic 
behaviour I will change it to 'Reno-SCTP'.



>
>
> Now, having said that, let me at least try to resolve one of
> these terms.   There is actually no need to define "Classic ECN"
> as its above definitions is "RFC3168 ECN", exactly 2 words, or
> 11 characters  in length as well, thus the term is not needed
> and actually obfuscates the document.  I feel removeing all
> references to "CLassic ECN" and replacing them with "RFC3168 ECN"
> would make these drafts more understadable.
[BB] That's a possibility, and I use it sometimes. But many people use 
the term Classic ECN these days, probably because RFC3168 ECN requires 
the reader to remember yet another RFC number, which some people don't 
find easy. I'm not hearing a lot of resistance to the term 'Classic ECN'.

For instance, I find the names below are easier to read than the 
numbers, not just because they are shorter:
* 'RFC5681 congestion control' vs. 'Reno'.
* 'RFC8511 Cubic' vs. 'ABE-Cubic'?

Also, RFC3168 defined the response to ECN as equivalent to drop. So 
there is a useful (and deliberate) reinforcement of understanding in the 
association between Classic ECN and the Classic service (assuming we 
continue to use 'Classic' as the name for the service).

Thanks



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Mon Nov 11 07:23:10 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 5E0C61208B3; Mon, 11 Nov 2019 07:23:09 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 Mwq9ECkOumbg; Mon, 11 Nov 2019 07:23:05 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 45FF31208C6; Mon, 11 Nov 2019 07:22:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=9hJPq20EAKxinmOMPzdKV3FaSZU+WyHmxYdYnVxz2p0=; b=HFbtqAnbxy1P6hMlClqz4jnBv +CRXlcgtNaDfe2etyevc5xpv6jOdf+wGdd9WIlKVnupM0RqsXKy7oD2qbMEUh9KVmEKteAdRtsVi0 3nLogPujqezVvI8MWjTIItJsE7ZiL3NmoY1B17f0RikUfDYQlt/xyRF7VepjeG0U9IJ8YbgMHxdQQ 78cQHJ5QZqXTnYRQTkG/Q6XSJfXSzIbfTGfI42qtWAZtfFSBe9sksjgCHtnV39+ceKlL5WVasRtQw BIc7iAJLbcwMa9Oe2oOgFQkOAQGHsnWjw36PLywi8opFWmOzGH9naJ4udWxPSkZeN7V3t1SMZtDFm yRe3vJ/cQ==;
Received: from [31.185.128.31] (port=55888 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUBWr-00071Y-1W; Mon, 11 Nov 2019 15:22:57 +0000
To: Sebastian Moeller 
Cc: "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net> <985D623F-8B16-4DB0-A675-5A726EF6753F@gmx.de>
From: Bob Briscoe 
Message-ID: <73220cb8-2e36-cf87-276a-f67c425a7752@bobbriscoe.net>
Date: Mon, 11 Nov 2019 15:22:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <985D623F-8B16-4DB0-A675-5A726EF6753F@gmx.de>
Content-Type: multipart/alternative; boundary="------------6A93D923AD2A073FFD5359DD"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Mon, 11 Nov 2019 15:23:10 -0000

This is a multi-part message in MIME format.
--------------6A93D923AD2A073FFD5359DD
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Sebastien,


      Chambers (British English)


classic adj *1* made of or belonging to the highest quality; established 
as the best. *2* entirely typical. *3* simple, neat and elegant, 
especially in a traditional style. noun *1* an established work of 
literature. *2* an outstanding example of its type. *3* something, eg an 
item of clothing, which will always last, irrespective of fashions and 
fads • /the little black dress, a classic of the 50s/. *4* (*Classic*) a 
celebrated annual sporting event, especially a horse race. See also the 
Classics . *classically* adverb *1* in a classic or classical 
way. *2* so as to be classical.
ETYMOLOGY: 17c: from Latin /classicus/ relating to classes, especially 
the best.


      Merriam Webster (US English)


clas·​sic | \ ˈkla-sik
1a *: *serving as a standard of excellence *: *of recognized value 
classic literary works a classic case study on hysteria
b *: *traditional 
, enduring 
 classic designs
c *: *characterized by simple tailored lines in fashion year after year 
a classic suit
2 *: *of or relating to the ancient Greeks and Romans or their culture 
*: *classical 
3a *: *historically memorable a classic battle
b *: *noted because of special literary or historical associations Paris 
is the classic refuge of expatriates
4a *: *authentic , 
authoritative  
a classic study of eyewitness accounts
b *: *typical  a 
classic example of chicanery a classic error

Responses inline...


On 06/11/2019 23:04, Sebastian Moeller wrote:
> Dear Bob,
>
>> On Nov 6, 2019, at 19:12, Bob Briscoe  wrote:
>>
>> Sebastien,
>>
>> On 06/11/2019 07:18, Sebastian Moeller wrote:
>>> Hi Bob,
>>>
>>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe
>>> 
>>>   wrote:
>>>
>>>> Michael, Rod,
>>>>
>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative
>>>> connotation than classic.
>>>>
>>>          [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
>> Which is a good starting point, because that's what is intended.
> 	[SM] I know that this is what you intend, but it is the test of time that makes classics classics, no amount of wishful thinking of the new-kid-on-the-block will relegate the reigning champion into classic mode, your solution really has to a) be better, and more importantly b) supersede that champion in the first place.
[BB] Not at all. Because classic has no hint of inferior. Quite the 
opposite according to the dictionaries.

This is an excellent demonstration of how any term, even a good positive 
one, attracts a negative connotation as soon as it is used to mean "the 
things that are claimed to be improved on". This says to me that the 
quest for a better word than classic will be fruitless.

Just like how kids quickly started to use the word 'special' as a term 
of abuse soon after the phrase "children with special needs" was 
introduced by well-meaning people.

>
>
>> Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2
> "Classic service:  The 'Classic' service is intended for all the
>        behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
>        Compound, SCTP, etc)."
>
> Reading this implies that TCP Reno is not in the classic set, as you define that set as those co-existing with Reno and that is does not include Reno. But really =you can define what ever you want, but to have others accept your definition it better be useful.
[BB] Good point. I'll certainly fix that along with the problems that 
Rod pointed out.


>>>> For example, if you did define the name "non-iPhone" to mean phones
>>>> such
>>>> as Android, Windows, etc, then you would expect the phrase "non-iPhone
>>>> knock-off products" to mean "fake Android and Windows phones". However
>>>> the constituent elements "non" and "iPhone" already have a meaning of
>>>> their own, so in the context of this phrase, it means "fake iPhones",
>>>> which is the opposite of what you wanted.
>>>>
>>>          [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.
>> [BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective).
> 	[SM] Your are debating me to score points here, are you?
[BB] Not at all. We need a context-independent meaning. I am raising a 
practical problem with choosing a name that contains an element ("non-") 
with a natural meaning that will change the presumed meaning of 
"non-L4S" dependent on context.

> You sort all flows into two categories, those that show L4S-style response to ECN signals and those that do not. The first group is reasonably homogenous, the second is not. So calling the second set non-L4S-style seems totally reasonably to me, unless you find another PROPERTY that defines that set, and no "classic" is not a property.
[BB] Non-L4S would be reasonable, were it not for its context-dependence 
problem. On what basis can you say that classic is not a property, when 
it is (both as defined for the L4S drafts, and as a well-understood 
adjective)?


> This is getting as ridiculous as your 17 year old car example....
>
>
>> I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1.
>> Then in this context, "Non-L4S" naturally means A - L1.
>>
>> However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1.
> 	[SM] Well, for me L4S traffic is traffic that show a "linear" response to CE markings instead of a "multiplicative" (we can argue whether that is the correct definition, but it sure beats the what ever I feel is L4S definition you seem to propose)
[BB] Are you really meaning to say that I don't know the theoretical 
grounding of my own research as well as you do?

BTW, Reno, Cubic and L4S responses to congestion are all multiplicative.

>   and in that sense the set theoretical observations boil down to your first formulation. The fact that the L4S draft allows for your second formulation is a defect in that draft. The other stuff is not L4S but rather LoW-Latency traffic (which might be qualified to share L4S low latency queue with true L4S traffic).
>
>> So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context.
> 	[SM] If you insist on overloading definitions, be my guest to keep the pieces once things break.
[BB] The current draft does not overload any definition of 'non-L4S'. It 
uses its natural meaning of "traffic that is not L4S" in the reduced 
context of the low latency queue. That's why I picked it as an example 
of a context-dependent word that would not be useful as a 
context-independent name.


>
>
>> It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean.
> 	[SM] I apologize I was not thinking about "in Wonderland" but about Through the Looking Glass (https://sabian.org/looking_glass6.php) :
> "'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'"
> L4S has exactly zero natural meaning, so please stop pretending it does.
[BB] When expanded it completely describes what it means: "Low Latency 
Low Loss Scalable throughput".



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------6A93D923AD2A073FFD5359DD
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Sebastien,

    

    
Chambers (British English)

    

      classic adj 1 made of or
    belonging to the highest quality; established as the best. 2
    entirely typical. 3 simple, neat and elegant, especially in
    a traditional style. noun 1 an
    established work of literature. 2 an outstanding example of
    its type. 3 something, eg an item of clothing, which will
    always last, irrespective of fashions and fads • the little
      black dress, a classic of the 50s. 4 (Classic)
    a celebrated annual sporting event, especially a horse race. See
    also the Classics. classically adverb 1 in a classic or classical way.
    2 so as to be classical. 

    ETYMOLOGY: 17c: from Latin classicus
    relating to classes, especially the best.

    

    
Merriam Webster (US English)

    

    

    

      

        

            
clas·​sic | \ ˈkla-sik 

                  1a :
                  serving as a standard of excellence : of recognized value classic
                      literary works a classic
                    case study on hysteria

           
            
b : traditional,
                  enduring
                  classic
                      designs

           
            
c : characterized
                  by simple tailored lines in fashion year after year a classic suit

          

        

            
2 : of
                  or relating to the ancient Greeks and Romans or their
                  culture : classical

          

        

            
3a
              : historically memorable a classic battle

           
            
b : noted
                  because of special literary or historical associations
                  Paris
                    is the classic refuge
                    of expatriates

          

        

            
4a
              : authentic,
                  authoritative
                  a classic study of eyewitness
                    accounts

           
            
b : typical
                  a classic example of
                    chicanery a classic error

          

      

    

    

    Responses inline...

    

    

    
On 06/11/2019 23:04, Sebastian Moeller
      wrote:

    

    

      
Dear Bob,



      

        
On Nov 6, 2019, at 19:12, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Sebastien,

On 06/11/2019 07:18, Sebastian Moeller wrote:


        

          
Hi Bob,

On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe 
<ietf@bobbriscoe.net>
 wrote:



          

            
Michael, Rod,

Altho non-L4S is a reasonable idea, I think it has more of a negative 
connotation than classic. 



          

          
        [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.


        

        
Which is a good starting point, because that's what is intended. 


      

      
	[SM] I know that this is what you intend, but it is the test of time that makes classics classics, no amount of wishful thinking of the new-kid-on-the-block will relegate the reigning champion into classic mode, your solution really has to a) be better, and more importantly b) supersede that champion in the first place.

    

    [BB] Not at all. Because classic has no hint of inferior. Quite the
    opposite according to the dictionaries.

    

    This is an excellent demonstration of how any term, even a good
    positive one, attracts a negative connotation as soon as it is used
    to mean "the things that are claimed to be improved on". This says
    to me that the quest for a better word than classic will be
    fruitless.

    

    Just like how kids quickly started to use the word 'special' as a
    term of abuse soon after the phrase "children with special needs"
    was introduced by well-meaning people.

    

    

      




      

        
Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2


      

      
"Classic service:  The 'Classic' service is intended for all the
      behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
      Compound, SCTP, etc)."

Reading this implies that TCP Reno is not in the classic set, as you define that set as those co-existing with Reno and that is does not include Reno. But really =you can define what ever you want, but to have others accept your definition it better be useful.

    

    [BB] Good point. I'll certainly fix that along with the problems
    that Rod pointed out.

    

    

    

      

        

          

          

            
For example, if you did define the name "non-iPhone" to mean phones
such 
as Android, Windows, etc, then you would expect the phrase "non-iPhone 
knock-off products" to mean "fake Android and Windows phones". However 
the constituent elements "non" and "iPhone" already have a meaning of 
their own, so in the context of this phrase, it means "fake iPhones", 
which is the opposite of what you wanted.



          

          
        [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.


        

        
[BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective).


      

      
	[SM] Your are debating me to score points here, are you? 

    

    [BB] Not at all. We need a context-independent meaning. I am raising
    a practical problem with choosing a name that contains an element
    ("non-") with a natural meaning that will change the presumed
    meaning of "non-L4S" dependent on context.

    

    

      
You sort all flows into two categories, those that show L4S-style response to ECN signals and those that do not. The first group is reasonably homogenous, the second is not. So calling the second set non-L4S-style seems totally reasonably to me, unless you find another PROPERTY that defines that set, and no "classic" is not a property. 

    

    [BB] Non-L4S would be reasonable, were it not for its
    context-dependence problem. On what basis can you say that classic
    is not a property, when it is (both as defined for the L4S drafts,
    and as a well-understood adjective)?

    

    

    

      
This is getting as ridiculous as your 17 year old car example....




      

        
I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1.
Then in this context, "Non-L4S" naturally means A - L1.

However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1.


      

      
	[SM] Well, for me L4S traffic is traffic that show a "linear" response to CE markings instead of a "multiplicative" (we can argue whether that is the correct definition, but it sure beats the what ever I feel is L4S definition you seem to propose)

    

    [BB] Are you really meaning to say that I don't know the theoretical
    grounding of my own research as well as you do? 

    

    BTW, Reno, Cubic and L4S responses to congestion are all
    multiplicative.

    

    

      
 and in that sense the set theoretical observations boil down to your first formulation. The fact that the L4S draft allows for your second formulation is a defect in that draft. The other stuff is not L4S but rather LoW-Latency traffic (which might be qualified to share L4S low latency queue with true L4S traffic).

    

    

      



      

        
So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context.


      

      
	[SM] If you insist on overloading definitions, be my guest to keep the pieces once things break.

    

    [BB] The current draft does not overload any definition of
    'non-L4S'. It uses its natural meaning of "traffic that is not L4S"
    in the reduced context of the low latency queue. That's why I picked
    it as an example of a context-dependent word that would not be
    useful as a context-independent name.

    

    

    

      




      

        
It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean.


      

      
	[SM] I apologize I was not thinking about "in Wonderland" but about Through the Looking Glass (https://sabian.org/looking_glass6.php) :
"'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'"
L4S has exactly zero natural meaning, so please stop pretending it does.

    

    [BB] When expanded it completely describes what it means: "Low
    Latency Low Loss Scalable throughput".

    

    

    

    Bob

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------6A93D923AD2A073FFD5359DD--


From nobody Mon Nov 11 07:30: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 03C2612004A; Mon, 11 Nov 2019 07:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 18fZPe-Ba8bk; Mon, 11 Nov 2019 07:30:46 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 9C23F12086A; Mon, 11 Nov 2019 07:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=dOj27pRFe+7vSOLymT7ggPf6ICTDBI7FOazO20IVDl4=; b=pDrT4jIiR8PRiBLzhz6JlNiAp KKB1Fx9CgS2GeVuXfBnyekbTjv7GcxuB7kO/liX9AiyVqGL1ED6FZ4ykW2t+eO/Fc6U7H0W7W5ppF oae/A9n/eTjEHzdiiVTJKb/L/cFh3PvnJP2ynMOlJdTqPsnwN+/0I3gkiVrvVa7RiE02t0Pu4GNpW kxqbD6C5EaOY3zb3nDPbfyCRVc4IhOb4Uqhev9e9Yl8sIdI6CBIHh2ho7YvT/1qZmbfJhUEK0u3+E xqxewGboGfYOMvwVQ4vZICdoX1k6gnQtZpV2N9JOeEy1XW+VemNhLpTfP3cNHeL4wTHB7hx4M43ss 4n7FexK4w==;
Received: from [31.185.128.31] (port=55936 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUBeN-00081h-O1; Mon, 11 Nov 2019 15:30:44 +0000
To: "Scharf, Michael" , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tsvwg@ietf.org" , "tcpm@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Bob Briscoe 
Message-ID: <4f5dc8cb-0c20-c38e-ac80-0b6b111c93ee@bobbriscoe.net>
Date: Mon, 11 Nov 2019 15:30:43 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------23A40A32E98C52F9EA3808FB"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Mon, 11 Nov 2019 15:30:48 -0000

This is a multi-part message in MIME format.
--------------23A40A32E98C52F9EA3808FB
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Michael,

On 07/11/2019 08:11, Scharf, Michael wrote:
>
>  and just to show that _/my/_ concern would be trivial to address by 
> small editorial changes:
>
> For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording It gives 
> an incremental migration path so that normal TCP traffic classified in 
> the Classic service of L4S will be no worse off would already work 
> for me. It just takes a small editorial change to make me happy. This 
> cant be so hard.
>
> Personally, I wonder if classic is indeed the best name for a 
> service class (and, e.g., normal sounds better to me), but in the 
> context of a service class, classic could actually work for me, if 
> TSVWG really wants that name with strong consensus. I dont care how 
> about names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic 
> policers/shapers, AQM schemes, or whatever else is done in the fast 
> path of a router to implement low latency service.
>
> I only object to specific terminology such as Classic TCP or 
> Classic congestion control because I dont think that classic is a 
> proper characterization for TCPM standards or TCP/IP stack behavior 
> not aligned with whatever L4S believes the bright future shall be.
>
I thought I had already agreed to remove 'TCP' from all instances of 
'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' 
in the first place. Because it's the congestion controls that are 
relevant in L4S drafts, not the protocols.



Bob
>
> Whether such small rewording address fully the concerns from others 
> may be a different question.
>
> Michael
>
> *From:*Wesley Eddy 
> *Sent:* Wednesday, November 6, 2019 8:54 PM
> *To:* Scharf, Michael ; Bob Briscoe 
> ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
> *Cc:* tsvwg@ietf.org; tcpm@ietf.org
> *Subject:* Re: [tcpm] [tsvwg] L4S status tracking
>
> On 11/6/2019 1:57 PM, Scharf, Michael wrote:
>
>     Bob,
>
>     From draft-ietf-tsvwg-ecn-l4s-id-08: It gives an incremental
>     migration path so that existing 'Classic' TCP traffic will be no
>     worse off
>
>     You are proposing an experiment. Not more than that. I will be
>     fine with the term Classic for TCP and TCPM-specified congestion
>     control when more than 50% of Internet traffic uses that new
>     technology.
>
>     Until this happens, I insist that the word Classic must be
>     removed in all context of TCP and congestion control (as far as it
>     is owned by TCPM), including the reference above. BTW, normal as
>     suggested would also work for me. So, you have plenty of options
>     for other terms.
>
> If Dave+Michael's suggestion of replacing "classic" with "normal" is 
> agreable to others, this seems like a good way forward to me. It 
> should be easy enough to explain in other SDOs that classic and normal 
> mean the same thing, if this is a real issue.
>
> (FWIW, I've never had a problem myself with "classic", nor read any 
> negative connotations to it. However, for the sake of working group 
> progress, I think we just need to pick something that seems the least 
> terrible and agree to move on.)
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------23A40A32E98C52F9EA3808FB
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    
On 07/11/2019 08:11, Scharf, Michael
      wrote:

    

    

      
      
      
      

        
 and just to show that _my_ concern
            would be trivial to address by small editorial changes:

        

        
For the abstract of
            draft-ietf-tsvwg-ecn-l4s-id, the wording
          It gives an incremental migration path so that
            normal TCP traffic classified in the Classic service of
            L4S will be no worse off would already work for me. It
            just takes a small editorial change to make me happy. This
            cant be so hard.

        

        
Personally, I wonder if classic is indeed the
            best name for a service class (and, e.g., normal sounds
            better to me), but in the context of a service class,
            classic could actually work for me, if TSVWG really wants
            that name with strong consensus. I dont care how about
            names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic
            policers/shapers, AQM schemes, or whatever else is done in
            the fast path of a router to implement low latency service.

        

        
I only object to specific terminology such as
            Classic TCP or Classic congestion control because I
            dont think that classic is a proper characterization for
            TCPM standards or TCP/IP stack behavior not aligned with
            whatever L4S believes the bright future shall be.

      

    

    I thought I had already agreed to remove 'TCP' from all instances of
    'Classic TCP traffic' etc, and that I hadn't intended to include
    'TCP' in the first place. Because it's the congestion controls that
    are relevant in L4S drafts, not the protocols.

    

    

    

    Bob

    

      

        

        

        
Whether such small rewording address fully the
            concerns from others may be a different question.

        

        
Michael

        

        

        

        

          

            

              
From: Wesley Eddy
                  <wes@mti-systems.com>
                  

                  Sent: Wednesday, November 6, 2019 8:54 PM

                  To: Scharf, Michael
                  <Michael.Scharf@hs-esslingen.de>; Bob Briscoe
                  <ietf@bobbriscoe.net>; Rodney W. Grimes
                  <4bone@gndrsh.dnsmgr.net>

                  Cc: tsvwg@ietf.org; tcpm@ietf.org

                  Subject: Re: [tcpm] [tsvwg] L4S status tracking

            

          

          

          

            
On 11/6/2019 1:57 PM, Scharf, Michael
              wrote:

          

          

            
Bob,

            

            
From draft-ietf-tsvwg-ecn-l4s-id-08: It
                gives an incremental migration path so that existing
                'Classic' TCP traffic will be no worse off

            

            
You are proposing an experiment. Not more
                than that. I will be fine with the term Classic for
                TCP and TCPM-specified congestion control when more than
                50% of Internet traffic uses that new technology.

            

            
Until this happens, I insist that the word
                Classic must be removed in all context of TCP and
                congestion control (as far as it is owned by TCPM),
                including the reference above. BTW, normal as
                suggested would also work for me. So, you have plenty of
                options for other terms.

            

          

          

          
If Dave+Michael's suggestion of replacing "classic" with
            "normal" is agreable to others, this seems like a good way
            forward to me. It should be easy enough to explain in other
            SDOs that classic and normal mean the same thing, if this is
            a real issue.

          
(FWIW, I've never had a problem myself with "classic", nor
            read any negative connotations to it. However, for the sake
            of working group progress, I think we just need to pick
            something that seems the least terrible and agree to move
            on.)

          

        

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------23A40A32E98C52F9EA3808FB--


From nobody Mon Nov 11 08:00:34 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 9B21C1200B2; Mon, 11 Nov 2019 08:00:32 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 uQrBzGhHgi-Q; Mon, 11 Nov 2019 08:00:31 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 5026F120128; Mon, 11 Nov 2019 08:00:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=y4vjd7qpx2rXL/hVMacocukL3qxvnJjrkdmu0PNzqVU=; b=1DU2ECzpsyR8NM9QYopfqi2Ux osnsOGDaXDk5LFY0ydlOxOCvYKbGK1ROJUfhFSak2/Z3DHNEkzZze0MSuQ2ARUQtuWxOb8xnI2ZRZ QEDVsgneYZZldQRvQkoLx+pNA7TF0gzqWzEXSMNB3qAIK22pGBjnAz/jF74GQKiNw3nC86gIBktdk BlaZuEXquWsRMnypGuHUivtk5RCuN7rL13IcGmHOJFWgbX7EZ2D2nqkrwQPsipUt3u0eYvvtXWQjE Y7sGE9sEUtRpEZytqnStbAVup7Dc6L4b7kPIsSR/qiAozVQCAcjjoPydMuJ8sNL1tEOPL/Dnt9KGd 7zTlB0JiA==;
Received: from [31.185.128.31] (port=56010 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUC7A-0003mf-JW; Mon, 11 Nov 2019 16:00:28 +0000
To: Wesley Eddy , "Scharf, Michael" 
Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" , "tcpm@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de> 
From: Bob Briscoe 
Message-ID: <00682594-0a20-9cb7-2191-f5eecc943222@bobbriscoe.net>
Date: Mon, 11 Nov 2019 16:00:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B1E6D8F7E58476FD25D53CEE"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Mon, 11 Nov 2019 16:00:32 -0000

This is a multi-part message in MIME format.
--------------B1E6D8F7E58476FD25D53CEE
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Wes,

Pls see the dictionary definitions of classic (as just posted in a 
response to Sebastian), which are all about superlative and enduring 
quality. I really don't think we will find a better word.


I'm afraid what is 'normal' changes over time, which is to be avoided 
for an RFC. We deliberately chose 'Classic' because it had a sense of 
"The stuff that has stood the test of time up to publication of this RFC".

If we use 'Normal' for the Reno-friendly service, it will always imply 
that L4S is not normal, even if L4S becomes normal (which is usually the 
intent of the IETF publishing an RFC).

I have no desire to use a word that means 'inferior to L4S'. But I'm not 
happy to use a word that implies that L4S is abnormal. Sorry to make 
resolution of this one difficult (and BTW, thanks go to Michael Scharf 
for being clear on what he can compromise on).


PS. I would like to hear whether anyone who has been either neutral or 
supportive of L4S perceives anything negative in the word 'Classic'. I 
suspect they have tuned out of this thread.




Bob

On 06/11/2019 19:54, Wesley Eddy wrote:
> On 11/6/2019 1:57 PM, Scharf, Michael wrote:
>>
>> Bob,
>>
>> From draft-ietf-tsvwg-ecn-l4s-id-08: It gives an incremental 
>> migration path so that existing 'Classic' TCP traffic will be no 
>> worse off
>>
>> You are proposing an experiment. Not more than that. I will be fine 
>> with the term Classic for TCP and TCPM-specified congestion control 
>> when more than 50% of Internet traffic uses that new technology.
>>
>> Until this happens, I insist that the word Classic must be removed 
>> in all context of TCP and congestion control (as far as it is owned 
>> by TCPM), including the reference above. BTW, normal as suggested 
>> would also work for me. So, you have plenty of options for other terms.
>>
>
> If Dave+Michael's suggestion of replacing "classic" with "normal" is 
> agreable to others, this seems like a good way forward to me. It 
> should be easy enough to explain in other SDOs that classic and normal 
> mean the same thing, if this is a real issue.
>
> (FWIW, I've never had a problem myself with "classic", nor read any 
> negative connotations to it. However, for the sake of working group 
> progress, I think we just need to pick something that seems the least 
> terrible and agree to move on.)
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------B1E6D8F7E58476FD25D53CEE
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Wes,

    

    Pls see the dictionary definitions of classic (as just posted in a
    response to Sebastian), which are all about superlative and enduring
    quality. I really don't think we will find a better word.

    

    

    I'm afraid what is 'normal' changes over time, which is to be
    avoided for an RFC. We deliberately chose 'Classic' because it had a
    sense of "The stuff that has stood the test of time up to
    publication of this RFC". 

    

    If we use 'Normal' for the Reno-friendly service, it will always
    imply that L4S is not normal, even if L4S becomes normal (which is
    usually the intent
    of the IETF publishing an RFC).

    

    I have no desire to use a word that means 'inferior to L4S'. But I'm
    not happy to use a word that implies that L4S is abnormal. Sorry to
    make resolution of this one difficult (and BTW, thanks go to Michael
    Scharf for being clear on what he can compromise on). 

    

    

    PS. I would like to hear whether anyone who has been either neutral
    or supportive of L4S perceives anything negative in the word
    'Classic'. I suspect they have tuned out of this thread.

    

    

    

    

    Bob

    

    
On 06/11/2019 19:54, Wesley Eddy wrote:

    

    

      
      
On 11/6/2019 1:57 PM, Scharf, Michael
        wrote:

      

      

        
        
        
        

          
Bob,

          

          
From draft-ietf-tsvwg-ecn-l4s-id-08: It
              gives an incremental migration path so that existing
              'Classic' TCP traffic will be no worse off

          

          
You are proposing an experiment. Not more
              than that. I will be fine with the term Classic for TCP
              and TCPM-specified congestion control when more than 50%
              of Internet traffic uses that new technology.

          

          
Until this happens, I insist that the word
              Classic must be removed in all context of TCP and
              congestion control (as far as it is owned by TCPM),
              including the reference above. BTW, normal as suggested
              would also work for me. So, you have plenty of options for
              other terms.

          

        

      

      


      

      
If Dave+Michael's suggestion of replacing "classic" with
        "normal" is agreable to others, this seems like a good way
        forward to me. It should be easy enough to explain in other
        SDOs that classic and normal mean the same thing, if this is a
        real issue.

      

      
(FWIW, I've never had a problem myself with "classic", nor read
        any negative connotations to it. However, for the sake of
        working group progress, I think we just need to pick something
        that seems the least terrible and agree to move on.)

      


      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------B1E6D8F7E58476FD25D53CEE--


From nobody Mon Nov 11 08:31: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 2FDFD120958; Mon, 11 Nov 2019 08:31:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 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] 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 lXGezFz6eYow; Mon, 11 Nov 2019 08:31:28 -0800 (PST)
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 84215120909; Mon, 11 Nov 2019 08:31:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573489828; bh=RIS0GPQXOa/RHPBoUjOGjDMJhEDxn3chwuJU9/5Q11c=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=V2Ov/JwSQuRp7PRn+iC/T10NyyvxrFYjUTofTsMIIMFcJoRv1v7CwV83Yle7kwFns n430oPrkGrT2M/Jszx/ygQp+LvbS/Xka+O23oFvxRYPLq9mnK4kedB6hN4Ds98CuVf T3okp+dIm0ls1za4x+daIScIkZQvyHo7WZHptLOY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MF3He-1ifFCW1B8a-00FVJC; Mon, 11 Nov 2019 17:30:28 +0100
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: <73220cb8-2e36-cf87-276a-f67c425a7752@bobbriscoe.net>
Date: Mon, 11 Nov 2019 17:30:26 +0100
Cc: "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AE74B84-95FB-46E0-A6A1-C424CEBEEB96@gmx.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net> <985D623F-8B16-4DB0-A675-5A726EF6753F@gmx.de> <73220cb8-2e36-cf87-276a-f67c425a7752@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:N8ugG19aja3NirpQs1KM3IdE5xKn8Oi93AYwCvxiYW+t/nD4wW2 sOcAFWYxPY+BcX0Sr0XAv3S3DNyR4qrhIJr9bc8WnFkYhwoLv2sy0GnDimY2M/JY7skI3ei sX9NETHx9YYNgG0bdMKJIHlk9N1/cfxfQvOqu7XZrsiSMwMqMuY+88TlbJvKTyzKq/JlAte fKY9x+IsuPdjVQDAACpNQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:I9rqCj3pGQA=:oUlJ5Zy8r0OW+8k6TlRF2p 4MgEsFe8G1QTYSewadXZo75wubmy/QFL2KoV4y0Cdr3bUVqW/VJaeFR2kD4mM1BayoKPKubVK oQ3mmZoEvusvPdeVkCzCdD1R64H9YRi/L0mNLxmi9UZCjq3H7u8vpjVjHuCmJFZXUo92a9Vlr HOgvetb8fJduVR9Pg0zeKRTzXqcib87NkUDKmOUDNURrsPA4qj4WMwf3GMoE5ydjys2BnIUa5 lHT5L7SkiPul4Fk3HUl8cl09tOOPQRFcOQxUzdjgNysdHT926EpsVbQUxaJyjCoK9Yc+7a2RV CVtMDgfmWg+cYWZAm9GIj0sznfAwhISKGRqDonw1k4f/fhs2eLk0LCDie62fqyhJBmEO8SKKN joWnacnVA4b/bV4+ENAGVd2n6npzwGJ+gR/gnVF8N6zXBFyFbyN+sVY2aRmQmQCf3qWqz+W7a JcXljSXfn1ssfAsP88DtAVcpF36ns9V60vpvuA9wtFC1bJR9gNJEogLC0302zoHhxwzKg0e/J 4BZgSv2uqmNpz4V3xsebgt/yhzNaOxcVjxtEJbX5o9k8by1/w/PQEvF4kLLwKls5Xg87eB3qc clPKltR7vCrtIPI6IY9K5ayh7Er/VaF3OgsQ/CNzSHVHhxXV1L3CD6f2gKWIludRu9v9zDICo UIwExs7kl/NQCFUMSPz6moxS49glF2BWfp//Xy6L49jK4cnvNT/PDRynGp9+iwjRC/C5XHvGq 5IVrfrc4hY1dfnURQ7bYk8mG+KgTOeJvX7KutmxhafzrmgUyb+UxjKme3CSo1UL14h+lKy/+0 9dcCSd7SSbq+5KKwL6fpGCSNBG7zeZPZzFpbJ1NBzIxLH7Pjos1nN+aO8yI35xwVH/cV4V83+ tTW+jPHZPF2oO19I6OY94ia7okBENpInDE2/TUZlRcHHZB9IgTAa7Ck7TtscMrsKWY7/4O0pP FtanDiE3ob+c2ASxdvmj+EgwYRF0ZowK48YCLc4nwkVhWayvSPnqDFI/dLW/QoA1CIqJlwXWh F5vlFSwSjzVnuKEOngm3hVBcUYRUk77ZdKL0z/8hZHGIzKwB4Hz/xLzacLDhj4Os/5HbK3IR+ nG4DrPAijArrZE4QTJ6qC7n2ZFMWbdIPk1OLlI6MNvqQyni+gvGdZNhtMO60wuXf0mnh0G8gf nOvo/DeZgoxDLh5j2txCfsmj2y8GBJFOedsMIQYRyReEDmZc2+0WDw7lTEB/7adqD2IAKt5Lt ctajAIuq2huJv5Dmly7KMNj/bjKzROC3Dd/dh5qLEUCHJrKEM3pXboDNn50w=
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: Mon, 11 Nov 2019 16:31:31 -0000

Hi Bob,

to be quite honest, the definitions you seem to insist upon are annoying =
and your rationale to explain your choices do not really convince me as =
given in good-faith.
To repeat once more before I move on to more substantial issues:
	You use classic in a sense of "The stuff that has stood the test =
of time up to publication of this RFC", and I believe it is very =
pretentious to assume that "this RFC" is going to replace the status quo =
especially given that the drafts seem to be in the experimental track.=20=


But my bigger problem is not how you name non-L4S traffic, but what L4S =
does to non-L4S traffic,
According to recently the measured and posted data L4S/dualQ/ AQMTCP =
Prague simply does not work as advertised.

Not sure about the consensus opinion here, but the reported unfairness =
at low RTTs does indicate that at least the tested dualQ aqm =
implementation does not actually manage to make "Scalable and Classic =
flows competing under similar conditions run at roughly the same rate."=20=


Neither ~10:1 @~0ms RTT =
(https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-p=
rague-50Mbit-0ms_var.png) nor 3:1 @ 10ms RTT =
(https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-p=
rague-50Mbit-10ms_var.png) qualify as "roughly the same rate" in my =
opinion. Oliver argued that this might be to be expected behavior due to =
the different RTTS under load for both queues, but he also admitted that =
he posed the same question, indicating that even members of the L4S =
development team consider traffic on the same path as "under similar =
conditions".

	This imbalance could be caused by (hopefully fixable) =
inefficiencies/bugs in the dualQ and/or TCP Prague implementations, or =
it could be part of L4S design; in which case I argue that this needs to =
be spelled out in excruciating detail in the draft.=20
	I find it a bit hard to believe that someone as verbose as you =
could use the term "run at roughly the same rate" to mean "Scalable =
traffic does not completely starve non-scalable traffic".=20
	The fact that this bias seems to diminish with increasing RTTs =
could be construed that at typical internet RTTs of ~100ms this effect =
does not matter much anymore, but that interpretation ignores that a =
considerable fraction of traffic is delivered from close-by data =
centers.=20

Best Regards
	Sebastian



> On Nov 11, 2019, at 16:22, Bob Briscoe  wrote:
>=20
> Sebastien,
>=20
> Chambers (British English)
>=20
>=20
> classic adj 1 made of or belonging to the highest quality; established =
as the best. 2 entirely typical. 3 simple, neat and elegant, especially =
in a traditional style. noun 1 an established work of literature. 2 an =
outstanding example of its type. 3 something, eg an item of clothing, =
which will always last, irrespective of fashions and fads =E2=80=A2 the =
little black dress, a classic of the 50s. 4 (Classic) a celebrated =
annual sporting event, especially a horse race. See also the Classics. =
classically adverb 1 in a classic or classical way. 2 so as to be =
classical.=20
> ETYMOLOGY: 17c: from Latin classicus relating to classes, especially =
the best.
>=20
> Merriam Webster (US English)
>=20
>=20
> clas=C2=B7=E2=80=8Bsic | \ =CB=88kla-sik=20
> 1a : serving as a standard of excellence : of recognized value classic =
literary works a classic case study on hysteria
> b : traditional, enduring classic designs
> c : characterized by simple tailored lines in fashion year after year =
a classic suit
> 2 : of or relating to the ancient Greeks and Romans or their culture : =
classical
> 3a : historically memorable a classic battle
> b : noted because of special literary or historical associations Paris =
is the classic refuge of expatriates
> 4a : authentic, authoritative a classic study of eyewitness accounts
> b : typical a classic example of chicanery a classic error
>=20
> Responses inline...
>=20
>=20
> On 06/11/2019 23:04, Sebastian Moeller wrote:
>> Dear Bob,
>>=20
>>=20
>>> On Nov 6, 2019, at 19:12, Bob Briscoe 
>>>  wrote:
>>>=20
>>> Sebastien,
>>>=20
>>> On 06/11/2019 07:18, Sebastian Moeller wrote:
>>>=20
>>>> Hi Bob,
>>>>=20
>>>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe=20
>>>>=20
>>>> 
>>>>=20
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Michael, Rod,
>>>>>=20
>>>>> Altho non-L4S is a reasonable idea, I think it has more of a =
negative=20
>>>>> connotation than classic.=20
>>>>>=20
>>>>>=20
>>>>         [SM] It does have the advantage though of being a testable, =
with classic all we know is you are talking about something that came =
before.
>>>>=20
>>> Which is a good starting point, because that's what is intended.=20
>>>=20
>> 	[SM] I know that this is what you intend, but it is the test of =
time that makes classics classics, no amount of wishful thinking of the =
new-kid-on-the-block will relegate the reigning champion into classic =
mode, your solution really has to a) be better, and more importantly b) =
supersede that champion in the first place.
> [BB] Not at all. Because classic has no hint of inferior. Quite the =
opposite according to the dictionaries.
>=20
> This is an excellent demonstration of how any term, even a good =
positive one, attracts a negative connotation as soon as it is used to =
mean "the things that are claimed to be improved on". This says to me =
that the quest for a better word than classic will be fruitless.
>=20
> Just like how kids quickly started to use the word 'special' as a term =
of abuse soon after the phrase "children with special needs" was =
introduced by well-meaning people.
>=20
>>=20
>>=20
>>=20
>>> Plus it already has a slightly positive natural meaning of =
"something robust that has stood the test of time". Then it is defined =
precisely for the context of each L4S doc, e.g.:
>>>=20
>>> =
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2
>> "Classic service:  The 'Classic' service is intended for all the
>>       behaviours that currently co-exist with TCP Reno (e.g.  TCP =
Cubic,
>>       Compound, SCTP, etc)."
>>=20
>> Reading this implies that TCP Reno is not in the classic set, as you =
define that set as those co-existing with Reno and that is does not =
include Reno. But really =3Dyou can define what ever you want, but to =
have others accept your definition it better be useful.
>>=20
> [BB] Good point. I'll certainly fix that along with the problems that =
Rod pointed out.
>=20
>=20
>>>>> For example, if you did define the name "non-iPhone" to mean =
phones
>>>>> such=20
>>>>> as Android, Windows, etc, then you would expect the phrase =
"non-iPhone=20
>>>>> knock-off products" to mean "fake Android and Windows phones". =
However=20
>>>>> the constituent elements "non" and "iPhone" already have a meaning =
of=20
>>>>> their own, so in the context of this phrase, it means "fake =
iPhones",=20
>>>>> which is the opposite of what you wanted.
>>>>>=20
>>>>>=20
>>>>         [SM] That is completely besides the point, it made me smile =
though and think about that passage in Alice in Wonderland about the =
meaning of words.
>>>>=20
>>> [BB] Please try to understand why this is very much the critical =
issue (more important than the negative connotation question, which is =
subjective).
>>>=20
>> 	[SM] Your are debating me to score points here, are you?=20
> [BB] Not at all. We need a context-independent meaning. I am raising a =
practical problem with choosing a name that contains an element ("non-") =
with a natural meaning that will change the presumed meaning of =
"non-L4S" dependent on context.
>=20
>> You sort all flows into two categories, those that show L4S-style =
response to ECN signals and those that do not. The first group is =
reasonably homogenous, the second is not. So calling the second set =
non-L4S-style seems totally reasonably to me, unless you find another =
PROPERTY that defines that set, and no "classic" is not a property.=20
> [BB] Non-L4S would be reasonable, were it not for its =
context-dependence problem. On what basis can you say that classic is =
not a property, when it is (both as defined for the L4S drafts, and as a =
well-understood adjective)?
>=20
>=20
>> This is getting as ridiculous as your 17 year old car example....
>>=20
>>=20
>>=20
>>> I believe you are thinking in the context of all traffic. Let's call =
that set A. And let's call the set of all L4S traffic L1.
>>> Then in this context, "Non-L4S" naturally means A - L1.
>>>=20
>>> However, consider another context, say the context of all Low =
Latency traffic, that we'll call L2. This was the context of the example =
I found in the draft. In that context, the term "Non-L4S" already =
naturally means L2 - L1.
>>>=20
>> 	[SM] Well, for me L4S traffic is traffic that show a "linear" =
response to CE markings instead of a "multiplicative" (we can argue =
whether that is the correct definition, but it sure beats the what ever =
I feel is L4S definition you seem to propose)
> [BB] Are you really meaning to say that I don't know the theoretical =
grounding of my own research as well as you do?=20
>=20
> BTW, Reno, Cubic and L4S responses to congestion are all =
multiplicative.
>=20
>>  and in that sense the set theoretical observations boil down to your =
first formulation. The fact that the L4S draft allows for your second =
formulation is a defect in that draft. The other stuff is not L4S but =
rather LoW-Latency traffic (which might be qualified to share L4S low =
latency queue with true L4S traffic).
>>=20
>>> So the term "Non-L4S" already has the intended meaning of Classic, =
but only in one context (A), and it has other meanings in every other =
context.
>>>=20
>> 	[SM] If you insist on overloading definitions, be my guest to =
keep the pieces once things break.
> [BB] The current draft does not overload any definition of 'non-L4S'. =
It uses its natural meaning of "traffic that is not L4S" in the reduced =
context of the low latency queue. That's why I picked it as an example =
of a context-dependent word that would not be useful as a =
context-independent name.
>=20
>=20
>>=20
>>=20
>>=20
>>> It's a very bad idea to choose a name that already has a natural =
meaning that can be different to what you want to define the name to =
mean.
>>>=20
>> 	[SM] I apologize I was not thinking about "in Wonderland" but =
about Through the Looking Glass (https://sabian.org/looking_glass6.php
>> ) :
>> "'When I make a word do a lot of work like that,' said Humpty Dumpty, =
'I always pay it extra.'"
>> L4S has exactly zero natural meaning, so please stop pretending it =
does.
>>=20
> [BB] When expanded it completely describes what it means: "Low Latency =
Low Loss Scalable throughput".
>=20
>=20
>=20
> Bob
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                              =20
> http://bobbriscoe.net/


From nobody Mon Nov 11 09:25: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 9E61B120A98 for ; Mon, 11 Nov 2019 09:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 P_U332B_Du0g for ; Mon, 11 Nov 2019 09:25:24 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 7B674120AAD for ; Mon, 11 Nov 2019 09:25:20 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id m193so12185263oig.0 for ; Mon, 11 Nov 2019 09:25:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ujKHauN5wOYauyxS2y5qXYrM7e7WOKPqIKbiQX1RyOw=; b=cvxBoUqe6zGCqA3ldLHhMTXi6wNRQ0Pk+s/wPjMHG/B1NY8jUyOL/3YAsWEBknjtzJ CZxbguhP2u7R1Ll00+y1RNNGcoIcjp4lH/RVpXH1tkUREApzeq+AU4zDVlG54q1wRO7h 6REBneldU4qbD4phFsQ76i+L+R3sVxO2HuWZw6WmYFBZ+npAcdJa4lXfFjcfwSd5+un/ xvLBoARCqZIjU083RXJ4M4ZMI/29jcebjQ3JZYWQW8E/JIiOZqvhBvVe+FFzrqcp7VMa zi2mPYsKeCBjvYfUF/gH9+pj4zuZW4lIvHXef4jD8eQd4c2Pi5BGW/I0yWNeD5axAikY HB2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ujKHauN5wOYauyxS2y5qXYrM7e7WOKPqIKbiQX1RyOw=; b=iXGj6WGDKk/UVceWduhngDvSpELJmnNJwq1TI+Azeb7sCqf7p42lYULaqvNGWAXeZo +xiH3RpvOjOT7dIGkTPb7ZUOLT9XwXr+5nbNLedn04iK1woVscyvx4vKbgVT5mhhP7Q+ T+b8iSX+2KW84S3jG0dcPS6eUwta59BWWCL0uuxjRLierlwVvP/FPG++osUMBd8z2Vvh PNo8NCkKOoiVIjXymYB6Y1/8BMoyPTtj/9n6k2X/jEvxbc6CEjQLOG4SH+CpHyBTFgWV NZy72Gwctyl+vHABvLZf0OBceLoZCJfVVvzksOBRBvXd6YeTNzYfKHKryT+V9hrp3NXn N0hg==
X-Gm-Message-State: APjAAAXaSg0yvsFEBpzyNv1OuSPz4A/cV5PP5NqJpX2OxVj2xKzBVX0k NejNFV87wxLX7jFXVuNHwdAieH3fopsdt59ed3nhzLVnw44=
X-Google-Smtp-Source: APXvYqwuAZxQJYmyb4URajn0mJJ7bBJL2gtyLMQRhE43tdgB+N/Z25+kv9LtdoCpZckD9wpbBuVlmJSELlTCLjwAqJA=
X-Received: by 2002:aca:d90a:: with SMTP id q10mr56577oig.129.1573493119163; Mon, 11 Nov 2019 09:25:19 -0800 (PST)
MIME-Version: 1.0
From: Neal Cardwell 
Date: Mon, 11 Nov 2019 12:25:02 -0500
Message-ID: 
To: Bob Briscoe , tsvwg IETF list ,  "tcpm@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 11 Nov 2019 17:25:28 -0000

A particular question in regards to the AccECN option:

  https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6

The AccECN option spec lists the EE0B field first, with the EE1B field
at the end.

Given that L4S plans on using ECT(1) for data packets, and unchanging
counter values can be omitted from the end of the AccECN option, why
not list EE1B first, and EE0B last? With EE1B first and EE0B last it
seems that in the common case for an L4S connection the (unchanged)
EE0B could be omitted, allowing 4 extra bytes of payload per packet.
AFAICT this extra 4 bytes would increase goodput for applications
using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
back-of-the-envelope calculations.

best,
neal


From nobody Mon Nov 11 10:25:35 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 1FAE112013D; Mon, 11 Nov 2019 10:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 0INBEzAdO1m0; Mon, 11 Nov 2019 10:25:26 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CF712008F; Mon, 11 Nov 2019 10:25:26 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 7763321B1C; Mon, 11 Nov 2019 18:25:21 +0000 (UTC)
From: Dave Taht 
To: "alex.burr\@ealdwulf.org.uk" 
Cc: Tom Henderson , tcpm@ietf.org, tsvwg IETF list 
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> <87a7931d1k.fsf@taht.net> <1369738724.1583995.1573472465758@mail.yahoo.com>
Date: Mon, 11 Nov 2019 10:25:08 -0800
In-Reply-To: <1369738724.1583995.1573472465758@mail.yahoo.com> (alex's message of "Mon, 11 Nov 2019 11:41:05 +0000 (UTC)")
Message-ID: <87k186z2wr.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 11 Nov 2019 18:25:28 -0000

"alex.burr@ealdwulf.org.uk"  writes:

> (see below)
>
> On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Taht
>  wrote: 
>
> Cool. If only the dsl and cable worlds had adopted this! it allows for
> much smarter handling of packet delivery higher in the stack at the
> cost
> of one interrupt's worth of standing queue. Without BQL we wouldn't be
> scaling linux past 10GigE today.
>
> I keep hoping *switches* will start doing bql, also.
>
> [AB] at the CO end (ie downstream) my understanding (which may be out
> of date) 
> is that DSL ICs usually punt queuing to a switch IC. There's a
> standard (G999.1) which exists
> solely to enable this (it provides per-subscriber backpressure over
> ethernet). So, switches doing
> BQL is exactly what would be required for dsl to do BQL (in the
> downstream direction).

Given that a lot of stuff has moved to a purer software solution,
slicing, sdn, etc, including switching, I can imagine this would
move more into software, also - if folk were still producing new
dsl gear.

One thing that has always been unclear to me is where
dsl subscriber software rate limits are enforced. 

>
> (Given BQL is a workaround, switches would want to implement a direct
> solution if they do anything).

I'd hope so!

>
> Alex


From nobody Mon Nov 11 15:10:53 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 7EE831200D8; Mon, 11 Nov 2019 15:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01] 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 pqaJpQMgiO_Q; Mon, 11 Nov 2019 15:10:40 -0800 (PST)
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 8E3601200B5; Mon, 11 Nov 2019 15:10:40 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AFA7025A16; Tue, 12 Nov 2019 00:10:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573513838; bh=/fgh+EYxRWhqirk12DKMX+MyPpzqDfOHh3BfAvHJ5xY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=OLTuUMI6ojyqRmcCe4ku9wNXZE/XkgIQsIwkVmRJ135BmIr8WrR7iP52VLM+5W9IL ovmzgAuU2S6X056h729W4aSWiqCQ2FQqNJpgY8mOj2uWQRj17+2V2RRH9lMBHTOiXT JXt1oi6WfV4ww9coy1TinYyEHIGj8Cfms82FsCUU=
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 XSGj7dLl3pep; Tue, 12 Nov 2019 00:10:35 +0100 (CET)
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; Tue, 12 Nov 2019 00:10:35 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 12 Nov 2019 00:10:34 +0100
From: "Scharf, Michael" 
To: Bob Briscoe , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: "tsvwg@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] [tsvwg] L4S status tracking
Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53v//8bUAgAASJQ6AAdWZAIAAhk2sgACrVICAABElwIAABJqAgADeR5CABrOxgIAAjl+Q
Date: Mon, 11 Nov 2019 23:10:34 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4FB9BA@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de> <4f5dc8cb-0c20-c38e-ac80-0b6b111c93ee@bobbriscoe.net>
In-Reply-To: <4f5dc8cb-0c20-c38e-ac80-0b6b111c93ee@bobbriscoe.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.165]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4FB9BArznt8114rzntrzd_"
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: Mon, 11 Nov 2019 23:10:46 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4FB9BArznt8114rzntrzd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, so we seem to make some progress at least regarding the term 'classic' =
TCP. As mentioned before, I personally would find the term 'Classic' QUIC v=
ery confusing and you cannot avoid that if you talk about 'Classic' TCP, IM=
HO. So, it seems better to avoid that terminology for all transport protoco=
ls. For the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of th=
e terms 'classic' and 'TCP' back-to-back is used 11 times as far as I can s=
ee.

Regarding congestion control, I'd like to emphasize that David's proposal w=
ould also work well for me, i.e., characterizing the congestion control by =
functional properties. This avoids all issues regarding whether something w=
ill supersede something else (including the issue that EXP is just an exper=
iment that won't update or replace any PS document).

Michael

From: Bob Briscoe 
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael ; Wesley Eddy ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,
On 07/11/2019 08:11, Scharf, Michael wrote:
... and just to show that _my_ concern would be trivial to address by small=
 editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an i=
ncremental migration path so that normal TCP traffic classified in the 'Cla=
ssic' service of L4S will be no worse off" would already work for me.  It j=
ust takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service cla=
ss (and, e.g., "normal" sounds better to me), but in the context of a servi=
ce class, "classic" could actually work for me, if TSVWG really wants that =
name with strong consensus. I don't care how about names for DiffSe^D^D^D^D=
^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whateve=
r else is done in the fast path of a router to implement low latency servic=
e.

I only object to specific terminology such as 'Classic' TCP or 'Classic' co=
ngestion control because I don't think that 'classic' is a proper character=
ization for TCPM standards or TCP/IP stack behavior not aligned with whatev=
er L4S believes the bright future shall be.
I thought I had already agreed to remove 'TCP' from all instances of 'Class=
ic TCP traffic' etc, and that I hadn't intended to include 'TCP' in the fir=
st place. Because it's the congestion controls that are relevant in L4S dra=
fts, not the protocols.



Bob


Whether such small rewording address fully the concerns from others may be =
a different question.

Michael



From: Wesley Eddy 
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael ; Bob Briscoe ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.




If Dave+Michael's suggestion of replacing "classic" with "normal" is agreab=
le to others, this seems like a good way forward to me.  It should be easy =
enough to explain in other SDOs that classic and normal mean the same thing=
, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negativ=
e connotations to it.  However, for the sake of working group progress, I t=
hink we just need to pick something that seems the least terrible and agree=
 to move on.)





--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/

--_000_6EC6417807D9754DA64F3087E2E2E03E2D4FB9BArznt8114rzntrzd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











OK, so we seem to make some progress at least regarding=
 the term ‚classic‘ TCP. As mentioned before, I personally woul=
d find the term ‘Classic’ QUIC very confusing and
 you cannot avoid that if you talk about ‘Classic’ TCP, IMHO. S=
o, it seems better to avoid that terminology for all transport protocols. F=
or the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the ter=
ms ‘classic’ and ‘TCP’ back-to-back is used
 11 times as far as I can see.


 


Regarding congestion control, I’d like to emphasi=
ze that David’s proposal would also work well for me, i.e., character=
izing the congestion control by functional properties.
 This avoids all issues regarding whether something will supersede somethin=
g else (including the issue that EXP is just an experiment that won’t=
 update or replace any PS document).


 


Michael


 








From:=
 Bob Briscoe <ietf@bobbriscoe.net>


Sent: Monday, November 11, 2019 4:31 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Wesley E=
ddy <wes@mti-systems.com>; Rodney W. Grimes <4bone@gndrsh.dnsmgr.n=
et>

Cc: tsvwg@ietf.org; tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 


Michael,




On 07/11/2019 08:11, Scharf, Michael wrote:






… and just to show that _my_ concern would=
 be trivial to address by small editorial changes:


 


For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wo=
rding “It gives an incremental migration path so that normal TCP traf=
fic classified in the ‘Classic’ service of L4S
 will be no worse off” would already work for me.  It just takes=
 a small editorial change to make me happy. This can’t be so hard.


 


Personally, I wonder if “classic” is indeed=
 the best name for a service class (and, e.g., “normal” sounds =
better to me), but in the context of a service class, “classic”
 could actually work for me, if TSVWG really wants that name with strong co=
nsensus. I don’t care how about names for DiffSe^D^D^D^D^D^D traffic =
classifiers, traffic policers/shapers, AQM schemes, or whatever else is don=
e in the fast path of a router to implement
 low latency service.


 


I only object to specific terminology such as ‘Cl=
assic’ TCP or ‘Classic’ congestion control because I don&=
#8217;t think that ‘classic’ is a proper characterization for T=
CPM standards
 or TCP/IP stack behavior not aligned with whatever L4S believes the bright=
 future shall be.




I thought I had already agreed to remove 'TCP' f=
rom all instances of 'Classic TCP traffic' etc, and that I hadn't intended =
to include 'TCP' in the first place. Because it's
 the congestion controls that are relevant in L4S drafts, not the protocols=
.







Bob








 


Whether such small rewording address fully the concerns=
 from others may be a different question.


 


Michael


 


 


 








From:=
 Wesley Eddy
<wes@mti-systems.com> 

Sent: Wednesday, November 6, 2019 8:54 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Bob Briscoe
<ietf@bobbriscoe.net>; Rod=
ney W. Grimes 
<4bone@gndrsh.dnsmgr.net>

Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 




On 11/6/2019 1:57 PM, Scharf, Michael wrote:






Bob,


 


From draft-ietf-tsvwg-ecn-l4s-id-08: “It gives an=
 incremental migration path so that existing 'Classic' TCP traffic will be =
no worse off”


 


You are proposing an experiment. Not more than that. I =
will be fine with the term “Classic” for TCP and TCPM-specified=
 congestion control when more than 50% of Internet
 traffic uses that new technology.


 


Until this happens, I insist that the word “Class=
ic” must be removed in all context of TCP and congestion control (as =
far as it is owned by TCPM), including the reference
 above. BTW, “normal” as suggested would also work for me. So, =
you have plenty of options for other terms.


 




 


If Dave+Michael's suggestion of replacing "classic" with &=
quot;normal" is agreable to others, this seems like a good way forward=
 to me.  It should be easy enough to explain in other SDOs that classi=
c and normal mean the same thing, if this is a real issue.


(FWIW, I've never had a problem myself with "classic", nor rea=
d any negative connotations to it.  However, for the sake of working g=
roup progress, I think we just need to pick something that seems the least =
terrible and agree to move on.)


 













-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/








--_000_6EC6417807D9754DA64F3087E2E2E03E2D4FB9BArznt8114rzntrzd_--


From nobody Mon Nov 11 18:10:49 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 3E0CC1200B1; Mon, 11 Nov 2019 18:10:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 bXSrGqf5YEWQ; Mon, 11 Nov 2019 18:10:38 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73E61200CD; Mon, 11 Nov 2019 18:10:16 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAC29PpU037028; Mon, 11 Nov 2019 18:09:25 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAC29P4g037027; Mon, 11 Nov 2019 18:09:25 -0800 (PST) (envelope-from freebsd)
From: "Rodney W. Grimes" 
Message-Id: <201911120209.xAC29P4g037027@gndrsh.dnsmgr.net>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4FB9BA@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
Date: Mon, 11 Nov 2019 18:09:25 -0800 (PST)
CC: Bob Briscoe , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Reply-To: rgrimes@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
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: Tue, 12 Nov 2019 02:10:40 -0000

> OK, so we seem to make some progress at least regarding the term 'classic' TCP. As mentioned before, I personally would find the term 'Classic' QUIC very confusing and you cannot avoid that if you talk about 'Classic' TCP, IMHO. So, it seems better to avoid that terminology for all transport protocols. For the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms 'classic' and 'TCP' back-to-back is used 11 times as far as I can see.

As a slight point, 'Classic' is not defined standalone in the terminology.  I think that is also a partial cause of problems here.

> 
> Regarding congestion control, I'd like to emphasize that David's proposal would also work well for me, i.e., characterizing the congestion control by functional properties. This avoids all issues regarding whether something will supersede something else (including the issue that EXP is just an experiment that won't update or replace any PS document).

This also works for me.

> 
> Michael
> 
> From: Bob Briscoe 
> Sent: Monday, November 11, 2019 4:31 PM
> To: Scharf, Michael ; Wesley Eddy ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
> Cc: tsvwg@ietf.org; tcpm@ietf.org
> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> 
> Michael,
> On 07/11/2019 08:11, Scharf, Michael wrote:
> .... and just to show that _my_ concern would be trivial to address by small editorial changes:
> 
> For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an incremental migration path so that normal TCP traffic classified in the 'Classic' service of L4S will be no worse off" would already work for me.  It just takes a small editorial change to make me happy. This can't be so hard.
> 
> Personally, I wonder if "classic" is indeed the best name for a service class (and, e.g., "normal" sounds better to me), but in the context of a service class, "classic" could actually work for me, if TSVWG really wants that name with strong consensus. I don't care how about names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whatever else is done in the fast path of a router to implement low latency service.
> 
> I only object to specific terminology such as 'Classic' TCP or 'Classic' congestion control because I don't think that 'classic' is a proper characterization for TCPM standards or TCP/IP stack behavior not aligned with whatever L4S believes the bright future shall be.
> I thought I had already agreed to remove 'TCP' from all instances of 'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' in the first place. Because it's the congestion controls that are relevant in L4S drafts, not the protocols.
> 
> 
> 
> Bob
> 
> 
> Whether such small rewording address fully the concerns from others may be a different question.
> 
> Michael
> 
> 
> 
> From: Wesley Eddy 
> Sent: Wednesday, November 6, 2019 8:54 PM
> To: Scharf, Michael ; Bob Briscoe ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
> Cc: tsvwg@ietf.org; tcpm@ietf.org
> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> 
> On 11/6/2019 1:57 PM, Scharf, Michael wrote:
> Bob,
> 
> >From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off"
> 
> You are proposing an experiment. Not more than that. I will be fine with the term "Classic" for TCP and TCPM-specified congestion control when more than 50% of Internet traffic uses that new technology.
> 
> Until this happens, I insist that the word "Classic" must be removed in all context of TCP and congestion control (as far as it is owned by TCPM), including the reference above. BTW, "normal" as suggested would also work for me. So, you have plenty of options for other terms.
> 
> 
> 
> 
> If Dave+Michael's suggestion of replacing "classic" with "normal" is agreable to others, this seems like a good way forward to me.  It should be easy enough to explain in other SDOs that classic and normal mean the same thing, if this is a real issue.
> 
> (FWIW, I've never had a problem myself with "classic", nor read any negative connotations to it.  However, for the sake of working group progress, I think we just need to pick something that seems the least terrible and agree to move on.)
> 
> 
> 
> 
> 
> --
> 
> ________________________________________________________________
> 
> Bob Briscoe                               http://bobbriscoe.net/

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Tue Nov 12 03:19: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 50E9112025D; Tue, 12 Nov 2019 03:19:58 -0800 (PST)
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, 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=toke.dk
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 1AIeiKS07r25; Tue, 12 Nov 2019 03:19:56 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 5B132120059; Tue, 12 Nov 2019 03:19:56 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1573557593; bh=rIkW0NGow1RMiU2lD9HiRohMsSzfvgAsskhmsvwzPZs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tzd8mNcJGWKQM9+a/8CZqO6fHkPzj/mMA9NBuEMV599mNEX0VAsIJfz7Vhmb6XQ0U x73rI/3M9opqCUgAvJPS66Eiaqa7KRkjq3HfHoqVHenY/+cw1Ikf5+eoNiZ13yP1OR jbbBZEwGgXFzs9UUQnrrWx+Hv/RzpEQeX5/uxhy3NeOwM5LWxdgvOpX3w1sLbQMaVi Lpw2pvaSrM1lI6wr6UAa+mInop+QbjkB3h8VdcMOMsFFSK6UIxVpcn/yKp4Ifbl9xA LT3gpdEPN/aMlKFnV8rt1HQ7UVkEP2aD4qmSv6ovntDI7Tpcb3SZdkrecKtjCl5vLg tAePMke1qk/zw==
To: Dave Taht , "alex.burr\@ealdwulf.org.uk" 
Cc: tcpm@ietf.org, tsvwg IETF list 
In-Reply-To: <87k186z2wr.fsf@taht.net>
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> <87a7931d1k.fsf@taht.net> <1369738724.1583995.1573472465758@mail.yahoo.com> <87k186z2wr.fsf@taht.net>
Date: Tue, 12 Nov 2019 12:19:52 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <874kz9qr3b.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 12 Nov 2019 11:19:58 -0000

Dave Taht  writes:

> "alex.burr@ealdwulf.org.uk"  writes:
>
>> (see below)
>>
>> On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Taht
>>  wrote: 
>>
>> Cool. If only the dsl and cable worlds had adopted this! it allows for
>> much smarter handling of packet delivery higher in the stack at the
>> cost
>> of one interrupt's worth of standing queue. Without BQL we wouldn't be
>> scaling linux past 10GigE today.
>>
>> I keep hoping *switches* will start doing bql, also.
>>
>> [AB] at the CO end (ie downstream) my understanding (which may be out
>> of date) 
>> is that DSL ICs usually punt queuing to a switch IC. There's a
>> standard (G999.1) which exists
>> solely to enable this (it provides per-subscriber backpressure over
>> ethernet). So, switches doing
>> BQL is exactly what would be required for dsl to do BQL (in the
>> downstream direction).
>
> Given that a lot of stuff has moved to a purer software solution,
> slicing, sdn, etc, including switching, I can imagine this would
> move more into software, also - if folk were still producing new
> dsl gear.
>
> One thing that has always been unclear to me is where
> dsl subscriber software rate limits are enforced.

Generally either by forcing the DSL modem to sync up at a rate no higher
than that which the customer has bought; or (more often these days I
think) on a completely separate box that does shaping (or policing) in
the network.

I've seen small ISPs build such boxes using Linux and HTB - and Jesper
and I have been helping a few doing it right (scaling across CPUs, and
using FQ-CoDel on the leaves).

-Toke


From nobody Tue Nov 12 07:33:51 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 460DC12006E; Tue, 12 Nov 2019 07:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 OyBx5ap_FHoM; Tue, 12 Nov 2019 07:33:42 -0800 (PST)
Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (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 3109412006F; Tue, 12 Nov 2019 07:33:42 -0800 (PST)
X-Sender-Id: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5447A5005A2; Tue, 12 Nov 2019 15:33:41 +0000 (UTC)
Received: from pawpaw.tchmachines.com (100-96-14-250.trex.outbound.svc.cluster.local [100.96.14.250]) (Authenticated sender: totalchoicehosting) by relay.mailchannels.net (Postfix) with ESMTPA id 703C8500D95; Tue, 12 Nov 2019 15:33:40 +0000 (UTC)
X-Sender-Id: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com
Received: from pawpaw.tchmachines.com ([TEMPUNAVAIL]. [208.76.80.100]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 12 Nov 2019 15:33:41 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com
X-MailChannels-Auth-Id: totalchoicehosting
X-Tangy-White: 127c6221527a4c19_1573572820916_3194989712
X-MC-Loop-Signature: 1573572820916:2045109460
X-MC-Ingress-Time: 1573572820915
Received: from [98.122.169.11] (port=47858 helo=tachyon.home.arpa) by pawpaw.tchmachines.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iUYAe-0006Iq-BY; Tue, 12 Nov 2019 10:33:32 -0500
Message-ID: <1573572813.20182.3.camel@petri-meat.com>
From: Steven Blake 
To: Dave Taht 
Cc: tcpm@ietf.org, tsvwg IETF list 
Date: Tue, 12 Nov 2019 10:33:33 -0500
In-Reply-To: <87k186z2wr.fsf@taht.net>
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> <87a7931d1k.fsf@taht.net> <1369738724.1583995.1573472465758@mail.yahoo.com> <87k186z2wr.fsf@taht.net>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-AuthUser: slblake+petri-meat.com@pawpaw.tchmachines.com
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 12 Nov 2019 15:33:44 -0000

On Mon, 2019-11-11 at 10:25 -0800, Dave Taht wrote:

> Given that a lot of stuff has moved to a purer software solution,
> slicing, sdn, etc, including switching, I can imagine this would
> move more into software, also - if folk were still producing new
> dsl gear.
> 
> One thing that has always been unclear to me is where
> dsl subscriber software rate limits are enforced. 

In the BRAS. Historically these have been built with quite
sophisticated hierarchical QoS schedulers implemented in custom
silicon. The downstream aggregation switches had tiny buffers and no
meaningful QoS features.


Regards,

// Steve


From nobody Tue Nov 12 08:09:24 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 CC039120835 for ; Tue, 12 Nov 2019 08:09:18 -0800 (PST)
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 folBnaDxbfYJ for ; Tue, 12 Nov 2019 08:09:16 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130058.outbound.protection.outlook.com [40.107.13.58]) (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 3B91E12006E for ; Tue, 12 Nov 2019 08:09:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i994TZtsQZWE6oYUEtbihUdTlMUtTJhBwmmS7R7qEXxUGzpSsgeTHLqR89jrzZnNUhXhEYvsIdHmz1ppVNXiNBMrSIbcGlsD/NPFXqWMpD9UsdbK/zVbR1qF8HT4el/RTxUjrtoCcgbdsGLYro65JjqMOP7YrGnhdfvDID0pL9YWg89i7mmrN/AyhVALFXHoAGLYUFE2hiRkY6H69jSqwg8Zwu3QnGF3r81ooocgX3dCp9PUQWXaMwbpsxfGha/ngBHiO8BALDMaSdbqEI7lzTtSfx/5DRm0Ev7iZh3KaH6jSavC2zHXnQU6eBBJ3VP293C7FirrhnppMY9LW2AhUw==
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=1M0969EhEERw6Zu5hCcqsYipr5nwHfdm+Bh/IwU8U+w=; b=UvokiJ2SpzJw92oHxo6cwbvozlSTSpARxQvJfxJmgosY61S2aWAPTfZVfScBZ3vmbkKiJ7fpn0o+gw5uBuIpIMweovOK92GzD0EU+ZsGkfR43j/KCoQhlw5zmHCWwoIKIRYFz9/XuP+JpyXAiX03/TpsQckRGOYbX4kK1D3OgoeTZMfUbtA+B26WV62k10vMdvGkPhhTYIb7bOoPJfmP5e/JtHKHo8qNUpLpmoYj7LGtvzw+jFNRG4JLfQDrznipmP8PNO/mtNY20I/nTchRxhSdFQKuTvv/BcDQhKP585DQqklFEUYLVgkLJmYpTA6ughQSGidQkThuYFU8x1SBZg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1M0969EhEERw6Zu5hCcqsYipr5nwHfdm+Bh/IwU8U+w=; b=URE+yuFWq31xpfButUx3F8ERYMLm6wYib7Eyb+8WtlRmL7+EZ1XCJiMGpncEBUJkwE6F5VpCrZdes/VlOo6e0d9Fa6oACMk5jGrj5019gvnUtAZxIcxcxmFhS3ZItY2meeP2XBuENNhQw7z3BvlFD0C/lOFSN3p2xekdQdF7O9c=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4818.eurprd07.prod.outlook.com (20.178.19.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.19; Tue, 12 Nov 2019 16:09:13 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1%7]) with mapi id 15.20.2451.018; Tue, 12 Nov 2019 16:09:13 +0000
From: Mirja Kuehlewind 
To: Neal Cardwell , "tcpm@ietf.org" 
CC: Bob Briscoe 
Thread-Topic: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
Thread-Index: AQHVmLUNZ9PVq3HEP0a6bdEGM8kLCaeHxmWA
Date: Tue, 12 Nov 2019 16:09:13 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2001:16b8:2436:c900:a070:9021:b58e:f79a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fdfcb022-bd7d-4c3e-8a1e-08d7678aa93e
x-ms-traffictypediagnostic: AM0PR07MB4818:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(189003)(199004)(966005)(6436002)(110136005)(305945005)(7736002)(6512007)(6306002)(66946007)(2501003)(6486002)(229853002)(6116002)(256004)(14454004)(14444005)(5660300002)(86362001)(316002)(6246003)(99286004)(478600001)(44832011)(46003)(102836004)(2906002)(36756003)(476003)(71200400001)(71190400001)(8676002)(186003)(2616005)(486006)(6506007)(446003)(81156014)(8936002)(4326008)(76116006)(25786009)(81166006)(11346002)(66446008)(33656002)(66476007)(66556008)(64756008)(76176011)(32563001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4818; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PUHjyjKOoA87vs51l3DoEG6+AeBx8X0CWWkMEjRAMM/HIGR3YQNjRI4O6X9GUxSDs/N9XmkL36/4XsEcF/Kes19jEXU+N/PpStd8Zl07ULx4K1m3N6ZIqRlWp8S9u8F9lg88Kzf4V/f0zi0b0/ABa2pSldJmGaKj6IG6HI13Z29K1iJkaLApis3nuhXm1yfOp8K/8vIcDpEYIIeAxBPmKoS3r+urniztGtcC/i496hBVUpDhkJA98YkL90YThwkYrQaNlAuPmG0U04v54jVtoFbm9WGT7FwpyKC13mfkx4CjK42HRNA5Haq1BKe9LV8dyUiUoGl/APA0a9XoW4HONRmH+podaUtCI+a7t3rKfiCPYJzQPe/GJQnAXSEuna4rH1iNOAlOliU03TihEzJFdp1OSnX1Z6N0G56GVw0tPmAZuODgTSUcgQ6vYziZQqCU
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <9EDC5CA8B2DEE24E914D48C63BDEC2F6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fdfcb022-bd7d-4c3e-8a1e-08d7678aa93e
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 16:09:13.7820 (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: 0YVDrDMNCRCSazkS921XCgTKg4tC0elfYAlx4goQWuVkbpoUelIuOMmZOFG0ivuRIfBPed81zlfWkjldN+0DUgovm0varDURcY0RMT9hG50=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4818
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 12 Nov 2019 16:09:19 -0000

SGkgTmVhbCwNCg0KdGhhdCdzIGEgZ29vZCBwb2ludC4gVGhlIG9yZGVyIG9mIHRoZSBmaWVsZCB3
YXMgYmFzZWQgb24gd2hhdCBpcyBleHBlY3RlZCB0byBiZSB0aGUgbW9zdCBsaWtlbHkgY2FzZS4g
Q3VycmVudGx5IG1vc3QgdHJhZmZpYywgaWYgaXQgdXNlcyBFQ04gYXQgYWxsLCB3aWxsIHNldCB0
aGUgY29kZXBvaW50IHRvIEVDVCgwKS4gV2l0aCBkZXBsb3ltZW50IG9mIEw0UyB0aGlzIGNvdWxk
IGNoYW5nZSBpbiBmdXR1cmUsIGhvd2V2ZXIsIHRoZXJlIGFyZSBhbHNvIHN0aWxsIHdheXMgdG8g
ZXh0ZW5kIHRoZSBuZWdvdGlhdGlvbiBpbiB0aGUgQWNjRUNOIFRDUCBoYW5kc2hha2UgdG8gZS5n
LiBzdXBwb3J0IHRoaXMgY2FzZSBiZXR0ZXIgaW4gZnV0dXJlLiANCg0KTWlyamENCg0KDQoNCu+7
v09uIDExLjExLjE5LCAxODoyNSwgInRjcG0gb24gYmVoYWxmIG9mIE5lYWwgQ2FyZHdlbGwiIDx0
Y3BtLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG5jYXJkd2VsbD00MGdvb2dsZS5jb21A
ZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgQSBwYXJ0aWN1bGFyIHF1ZXN0aW9uIGluIHJl
Z2FyZHMgdG8gdGhlIEFjY0VDTiBvcHRpb246DQogICAgDQogICAgICBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wOSNzZWN0aW9uLTMuMi42
DQogICAgDQogICAgVGhlIEFjY0VDTiBvcHRpb24gc3BlYyBsaXN0cyB0aGUgRUUwQiBmaWVsZCBm
aXJzdCwgd2l0aCB0aGUgRUUxQiBmaWVsZA0KICAgIGF0IHRoZSBlbmQuDQogICAgDQogICAgR2l2
ZW4gdGhhdCBMNFMgcGxhbnMgb24gdXNpbmcgRUNUKDEpIGZvciBkYXRhIHBhY2tldHMsIGFuZCB1
bmNoYW5naW5nDQogICAgY291bnRlciB2YWx1ZXMgY2FuIGJlIG9taXR0ZWQgZnJvbSB0aGUgZW5k
IG9mIHRoZSBBY2NFQ04gb3B0aW9uLCB3aHkNCiAgICBub3QgbGlzdCBFRTFCIGZpcnN0LCBhbmQg
RUUwQiBsYXN0PyBXaXRoIEVFMUIgZmlyc3QgYW5kIEVFMEIgbGFzdCBpdA0KICAgIHNlZW1zIHRo
YXQgaW4gdGhlIGNvbW1vbiBjYXNlIGZvciBhbiBMNFMgY29ubmVjdGlvbiB0aGUgKHVuY2hhbmdl
ZCkNCiAgICBFRTBCIGNvdWxkIGJlIG9taXR0ZWQsIGFsbG93aW5nIDQgZXh0cmEgYnl0ZXMgb2Yg
cGF5bG9hZCBwZXIgcGFja2V0Lg0KICAgIEFGQUlDVCB0aGlzIGV4dHJhIDQgYnl0ZXMgd291bGQg
aW5jcmVhc2UgZ29vZHB1dCBmb3IgYXBwbGljYXRpb25zDQogICAgdXNpbmcgSVB2NCBvciBJUHY2
IHdpdGggYW4gTVRVIG9mIDE1MDAgYnkgYWJvdXQgMC4zJSwgYnkgbXkNCiAgICBiYWNrLW9mLXRo
ZS1lbnZlbG9wZSBjYWxjdWxhdGlvbnMuDQogICAgDQogICAgYmVzdCwNCiAgICBuZWFsDQogICAg
DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg
ICB0Y3BtIG1haWxpbmcgbGlzdA0KICAgIHRjcG1AaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCiAgICANCg0K


From nobody Tue Nov 12 08:24:55 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 0313D12008B; Tue, 12 Nov 2019 08:24:48 -0800 (PST)
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, 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=toke.dk
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 3l8wKSIxqWZD; Tue, 12 Nov 2019 08:24:46 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (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 24F3312004A; Tue, 12 Nov 2019 08:24:46 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1573575883; bh=W714BWwW+3W282M4b1ylMXhTssdEyOFiW+GfVkIg8J4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=yGYVI8bFS76yL34AnhqIqiSrmd5f5Jomq/ctXszXHGz0XLanp2uRe7yiXzWpbbT+o WlGan0WogcsduXHO7WOscs0hBmLMB8Fs1gJFuQpp5EFOr039MiO/54QjzPJO7Lg9aM Vt/ly2OmBUr84bCpXnR5S6Akqfa0awH7tonnNYz0c7RgZz230Mxc9WY6Q0QwAjcqD1 vsDrOQNgWT4wnskjTT1G59IT38Y+4bVOW0XMgofHGGMfBiMRWptWLtIbxAoFupfLVR r3IR2To1Ley0/QxqTopYHADkqT2BZceOuSkbBZrFMRcluBn897XB42AwbfhTkEgOrH 8PcfiKo9GeHrg==
To: Steven Blake , Dave Taht 
Cc: tcpm@ietf.org, tsvwg IETF list 
In-Reply-To: <1573572813.20182.3.camel@petri-meat.com>
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> <87a7931d1k.fsf@taht.net> <1369738724.1583995.1573472465758@mail.yahoo.com> <87k186z2wr.fsf@taht.net> <1573572813.20182.3.camel@petri-meat.com>
Date: Tue, 12 Nov 2019 17:24:42 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87eeydoyet.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tcpm] [tsvwg] sce vs l4s comparison plots?
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, 12 Nov 2019 16:24:48 -0000

Steven Blake  writes:

> On Mon, 2019-11-11 at 10:25 -0800, Dave Taht wrote:
>
>> Given that a lot of stuff has moved to a purer software solution,
>> slicing, sdn, etc, including switching, I can imagine this would
>> move more into software, also - if folk were still producing new
>> dsl gear.
>>=20
>> One thing that has always been unclear to me is where
>> dsl subscriber software rate limits are enforced.=C2=A0
>
> In the BRAS.

Heh. In Danish, 'bras' literally means 'junk'. I'm sure that's just a
coincidence :)

-Toke


From nobody Tue Nov 12 08:30: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 DD913120108 for ; Tue, 12 Nov 2019 08:30:12 -0800 (PST)
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 S0ULZMAHghBi for ; Tue, 12 Nov 2019 08:30:10 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00064.outbound.protection.outlook.com [40.107.0.64]) (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 09A8F120098 for ; Tue, 12 Nov 2019 08:30:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aAZBam0qJydO7HuJZQRgNmtsksJAj4bypLsPwtnjSX8c4GoEcSUt1y2I+mNzKFDONy73FkuP/fQvmfDZnrJC7Pt8SArpCBARkoDoYgAA4bAQBqqWWlNXLrFOvc8ucBcW27vPmeDiSywijWpN04sOvjsC+NpqP8CkMIKpphDoGWBxW8VNApokHnqXBaPNN8z+z0eKZG0dGOtjvY3distk69FmeReh2X9jSLmoYZDdpHzbTq2pMKnsPAvapTQnMESHTOPog8YNw+rcqcR/+1pO15b9U8DqHkwY9XUfwnVV5Z4kIGjugBESk/bbzIkYj3Xau/RhdSd08q0W8PgtwO9B0Q==
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=Rc8OyQMbicn6mocJG0gnsIht6dGy/iDISfRNH5KsSPQ=; b=dWJSGQRdN9HPcsia13an6wm5r+ueCLd2oMfiWfAXRyXVgpr5WP6z8T+HyVHgwbJpokPlbGlE2m8mo05WNLf6C9SHwbmNjRnRGaGVH3EJIpmeGZly05TFu3cwzKZv1o6J2hk79VOrX5CRPHH4pMaHI5O+lQMSDD1g+uBE6PZl68pvmAoOJkCfyxLnJxw54PnhsFC/W5W7Hmbz9obE/3ax/11Y6SoxwGlInCKujlErH2QCZEEoAR6uQ01Ihy5Kf7wcSUkk/toDTnHT01sxfg0ysaG9nsRba8zapAZY0UTpCUg7ErvaAVgEc7HEXx0bRugoypGYz9r95f/aKdQOERRdgg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rc8OyQMbicn6mocJG0gnsIht6dGy/iDISfRNH5KsSPQ=; b=bQazwMCUD64kVX//M2x3HXgUXrrGj9nal9orNAif4eDZzRMsm9cQj5pPKzlPEDcw1E5/1F1NHZmlD5UzmkfjqGREwUisAjpv1WRTAyCPZq040YL08LrPZVWmGdRsHBZvJdZx5zXGcKcxeH/JEm7GhH9tLv+DUaTqOMMRjJpAGMA=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6034.eurprd07.prod.outlook.com (20.178.112.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.17; Tue, 12 Nov 2019 16:30:07 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1%7]) with mapi id 15.20.2451.018; Tue, 12 Nov 2019 16:30:07 +0000
From: Mirja Kuehlewind 
To: Pete Heist , "nsd.ietf@gmail.com" 
CC: "tcpm@ietf.org" 
Thread-Topic: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
Thread-Index: AQHVlg3D3FuD8rQyOUeITRzrNWkm0aeH0YoA
Date: Tue, 12 Nov 2019 16:30:07 +0000
Message-ID: <8382D634-8FEC-4932-96ED-9C5FB71E128D@ericsson.com>
References: <201911072222.xA7MMYXb017371@gndrsh.dnsmgr.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2001:16b8:2436:c900:a070:9021:b58e:f79a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 958670c3-6fc9-4802-2355-08d7678d948e
x-ms-traffictypediagnostic: AM0PR07MB6034:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(136003)(39860400002)(376002)(189003)(199004)(6246003)(102836004)(76116006)(6486002)(478600001)(76176011)(229853002)(966005)(36756003)(256004)(66556008)(316002)(64756008)(6306002)(99286004)(6512007)(6436002)(66446008)(2906002)(6506007)(66946007)(66476007)(6116002)(5660300002)(14444005)(4326008)(33656002)(561944003)(8676002)(186003)(110136005)(44832011)(81156014)(81166006)(8936002)(2616005)(446003)(486006)(476003)(25786009)(71200400001)(71190400001)(11346002)(14454004)(7736002)(86362001)(46003)(2501003)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6034; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IwfdmCDCVMqyyfbsWPHLgyVvEp+wPNcqQhsmOGiHxc9tsy+9zwY0uZoorH0RBYQLFvUSoXM2FN/QCoa7g9+4j9oWNpM+l5v/lpQwsdpml7VdO+eIhoJbnSqiqQ7JP0TZpbQbKubFazjoRHG7yjP1yCeJPR9dZl2pmJ3EsYomnmxlfSOi9uwvfZ6u7KaCdWzfc8+PTtKJnyFSXaHIXEqJ0MH+ctOEHSlsvk/HxWmM6A2NubPUVgUqDENGWD/Uw9J543xTRZqRGr85Ua6z9Vx640FKE3+I8BuOwIA8H/TkvcG3vEOouuXxcFWAuV6rqKI4PXShJn+3pFu5miilU7w0D/9Oiq4SI6V0yMxjYpsNjcrxhBBnpdHY3maveGnKHYuizK4fJVqH6Kuiw3oXJXzKkdR4iL2660umJpMRULISpGZ5EMBzvF6U9lYViXYCSkJA
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 958670c3-6fc9-4802-2355-08d7678d948e
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 16:30:07.5957 (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: NleC8c1FKDTEPXSZnc8ZJOQHZm+DXDswhjJzlDVoWOSaEagcOGupy3jLDIr9W1gDKhQZXA9a1cOYIaBj1cJOZAnbDWqBD8+9iBoLXIVTgRE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6034
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 12 Nov 2019 16:30:13 -0000

UGV0ZXIsIEkgZG9uJ3QgdGhpbmsgdGhlIEFjY0VDTiBkcmFmdCBzaG91bGQgc2F5IGFueXRoaW5n
IGFib3V0IHdoYXQgaGFwcGVucyB0byB0aGUgZXgtTlMgYml0IGlmIGl0IGZhbGxzIGJhY2sgdG8g
Y2xhc3NpYyBFQ04gYmVjYXVzZSB0aGF0J3Mgb3V0IG9mIHNjb3BlIG9mIHRoZSBkcmFmdCBkZWZp
bmluZyB0aGUgQWNjRUNOIG1lY2hhbmlzLiBIb3dldmVyLCBJIGFncmVlIHRoYXQgaXMgd291bGQg
YmUgYXZhaWxhYmxlIGZvciBhbm90aGVyIHVzZS4NCg0KWW9zaGksIEkgYmVsaWV2ZSB5b3UgcG9p
bnQgQTEgYmVsb3cgd2FzIGRlY2lkZWQgaW4gdGhlIGdyb3VwIGFscmVhZHkgYXQgYWRvcHRpb24g
dGltZSBhcyB0aGUgYml0IHdhcyB1c2VkIGZyb20gdGhlIGJlZ2lubmluZyB3aXRoIGFsbCBwb3Nz
aWJsZSBBY2NFQ04gbWVjaGFuaXNtcy4gSG93ZXZlciwgaWYgYW5kIGhvdyBpdCBzaG91bGQgYmUg
cmVnaXN0ZXJlZCB3aXRoIElBTkEgaXMgYSBkaWZmZXJlbnQgcXVlc3Rpb24uIFRvIG15IG1lbW9y
eSB0aGVyZSB3YXMgc3VwcG9ydCB0byByZWdpc3RlcmVkIGV2ZW4gdGhvdWdoIGl0J3MgZXhwZXJp
bWVudGFsIGJlY2F1c2UgTlMgd2FzIHJlZ2lzdGVyZWQgYmFzZWQgb24gYW4gZXhwZXJpbWVudGFs
IFJGQyBhbmQgaGF2aW5nIHRoaXMgcmVnaXN0cnkgc2F5aW5nIHNvbWV0aGluZyBhYm91dCB0aGlz
IHNwZWNpZmljIGJpdCB3aGlsZSBub3Qgbm90aW5nIHRoaXMgZXhwZXJpbWVudCB0aGVyZSBzZWVt
cyBjb25mdXNpbmcvYWdhaW5zdCB0aGUgaWRlYSBvZiBhIHJlZ2lzdHJ5LiBXaGF0IHdlIG1heWJl
IGNvdWxkIGRpc2N1c3MgaXMgaWYgd2Ugd2FudCB0byByZW5hbWUgdGhlIGJpdCBpbiB0aGUgcmVn
aXN0cnkgKHRvIEFFKSBvciByYXRoZXIganVzdCBhZGQgYSBub3RlIGFib3V0IHRoaXMgZXhwZXJp
bWVudC4gTGFzdCB0aW1lIHRoZXJlIHdhcyBzdXBwb3J0IHRvIGdpdmUgaXQgYSBwcm9wZXIgbmFt
ZSB3aGljaCB3ZSBmb2xsb3dlZCBhcyBhdXRob3JzIGJ1dCBvZiBjb3Vyc2UgaXQncyB0aGUgd29y
a2luZyBncm91cCB0byBkZWNpZGUgaGVyZS4NCg0KUmVnYXJkaW5nIHBvaW50IEEyLCB0aGlzIHdh
cyBhbHNvIGRpc2N1c3NlZCBhdCBsZW5ndGggaW4gdGhlIGdyb3VwLiBUaGVyZSBhcmUgZGlmZmVy
ZW50IHdheSBvZiBmYWlsaW5nLiBPbmUgaXMsIGFzIHdlIHNhdyBmb3IgTlMsIHRoYXQgdGhlcmUg
d2lsbCBiZSBubyBkZXBsb3ltZW50IGF0IGFsbCBhbmQgd2UgY2FuIHNpbXBseSByZWFzc2lnbi4g
QW5vdGhlciBpdCB0aGF0IGlzIGdldHMgZGVwbG95IGJ1dCBkb2Vzbid0IHdvcmsgYXMgZXhwZWN0
ZWQsIGhvd2V2ZXIsIGluIHRoaXMgY2FzZSB0aGVyZSBhcmUgc3RpbGwgd2F5cyB0byBleHRlbmQv
YWx0ZXIgQWNjRUNOIGJ5IG5lZ290aWF0aW9uIGR1cmluZyB0aGUgaGFuZHNoYWtlLiBUaGlzIGlz
IGFsc28gZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCBhbmQgdGhlIG1heW9yIHJlYXNvbiBmb3IgaGF2
aW5nIHRoZSBoYW5kc2hha2UgbmVnb3RpYXRpb24gaW5zdGVhZCBvZiBqdXN0IHVzaW5nIHRoZSBi
aXQgKGFzIHNvbWUgb3RoZXIgcHJvcG9zYWwgZG8pLiBJZiB0aGF0IGlzIG5vdCBnb29kIGVub3Vn
aCwgSSdtIGFmcmFpZCB3ZSB3b24ndCBiZSBhYmxlIHRvIGV2ZXIgdXNlIGFueSBvZiB0aGUgcmVz
ZXJ2ZWQgYml0cyBpbiB0aGUgVENQIGhhbmRzaGFrZS4NCg0KUmVnYXJkaW5nIHlvdXIgcG9pbnQg
QiBiZWxvdyBJIGRvbid0IHNlZSBhbnkgZGVwZW5kZW5jeSBGUk9NIEFjY0VDTiB0byBhbnkgb2Yg
dGhlc2UgcHJvcG9zYWxzLiBZZXMsIG11bHRpcGxlIHByb3Bvc2FsIHJlcGx5IG9uIEFjY0VDTiwg
d2hpY2ggaXQgZ3JlYXQgYmVjYXVzZSBpdCBzaG93IHRoYXQgaXQgaXMgdXNlZnVsLCBidXQgdGhh
dCBvbmx5IG1lYW5zIHRoYXQgdGhlIHByb3Bvc2FscyBoYXZlIGEgZGVwZW5kZW5jeSBUTyBBY2NF
Q04gYW5kIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZC4gRm9yIG1lIHRoaXMgaXMgYW5vdGhlciBy
ZWFzb24gdG8gcHJvY2VlZCB3aXRoIEFjY0VDTiBxdWlja2x5Lg0KDQpNaXJqYQ0KDQoNCg0KDQrv
u79PbiAwOC4xMS4xOSwgMDk6MjMsICJ0Y3BtIG9uIGJlaGFsZiBvZiBQZXRlIEhlaXN0IiA8dGNw
bS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwZXRlQGhlaXN0cC5uZXQ+IHdyb3RlOg0K
DQogICAgSGksDQogICAgDQogICAgUmVnYXJkaW5nIHBvaW50cyBBMSBhbmQgQiBvdmVyYWxsLCB3
b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgdG8gdGhlIEFjY0VDTiBkcmFmdCBzb21lIGxhbmd1
YWdlIHN1Y2ggdGhhdCB3aGVuIGl0IGZhbGxzIGJhY2sgdG8gUkZDIDMxNjggRUNOLCB0aGUgTlMg
Yml0IGlzIHN0aWxsIGF2YWlsYWJsZSBmb3Igb3RoZXIgZXhwZXJpbWVudHM/IFRoYXQgd2F5IHRo
ZSBiaXQgY291bGQgc3RpbGwgYmUgdXNlZCBieSBTQ0UsIGV2ZW4gaWYgQWNjRUNOIGJlY29tZXMg
YSBwcm9wb3NlZCBzdGFuZGFyZC4NCiAgICANCiAgICA+IEZyb206IFlvc2hpZnVtaSBOaXNoaWRh
IDxuc2QuaWV0ZkBnbWFpbC5jb20+DQogICAgPiBEYXRlOiBUaHUsIDcgTm92IDIwMTkgMTE6MDQ6
MzggLTA4MDANCiAgICA+IA0KICAgID4gSGksDQogICAgPiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJh
dGUtZWNuIGFuZCBkcmFmdC1pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIGhhdmUgYmVlbg0KICAg
ID4gZGlzY3Vzc2VkIGZvciBhIHdoaWxlLg0KICAgID4gdGNwbSBjaGFpcnMgYXJlIG5vdyB0aGlu
a2luZyB0aGF0IHRoZXkgYXJlIGdldHRpbmcgbWF0dXJlZCBhbmQgYmVjb21pbmcNCiAgICA+IHJl
YWR5IGZvciBXR0xDIC4NCiAgICA+IEhvd2V2ZXIsIHdlIGFsc28gdGhpbmsgdGhlcmUgYXJlIHNl
dmVyYWwgcG9pbnRzIHRvIGJlIGNsYXJpZmllZCBiZWZvcmVoYW5kLg0KICAgID4gDQogICAgPiBJ
biBvcmRlciB0byBwcm9jZWVkIHRoZSBjdXJyZW50IHNpdHVhdGlvbiwgd2Ugd291bGQgbGlrZSB0
byBhc2sgdGhlDQogICAgPiBjb21tdW5pdHkgdG8gZ2l2ZSBzb21lIGZlZWRiYWNrIG9uIHRoZSBm
b2xsb3dpbmcgcG9pbnRzLg0KICAgID4gV2Ugd2lsbCBoaWdobHkgYXBwcmVjaWF0ZSB5b3VyIGlu
cHV0cy4NCiAgICA+IA0KICAgID4gQTogQWxsb2NhdGluZyBiaXQgNyBmb3IgZHJhZnQtaWV0Zi10
Y3BtLWFjY3VyYXRlLWVjbg0KICAgID4gIFRoZSBkcmFmdCByZXF1ZXN0cyB0aGUgYWxsb2NhdGlv
biBmb3IgYml0IDcgaW4gVENQIGhlYWRlciAoZXggTlMgYml0KQ0KICAgID4gZm9yIHRoaXMgcHJv
cG9zYWwuDQogICAgPiAgSG93ZXZlciwgdGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZHJhZnQg
aXMgZXhwZXJpbWVudGFsLCB3aGljaCBtYXkgbm90DQogICAgPiBiZSB3ZWxsIGFsaWduZWQgd2l0
aCB0aGUgZGVzY3JpcHRpb24gaW4gUkZDMjc4MC4NCiAgICA+IA0KICAgID4gVGhlIGNoYWlycyB3
b3VsZCBsaWtlIHRvIGNoZWNrIHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KICAgID4gICAgIEExOiBJ
ZiB3ZSBjYW4gaGF2ZSBhIGNvbnNlbnN1cyB0byBhbGxvY2F0ZSBiaXQgNyBmb3IgdGhpcw0KICAg
ID4gZXhwZXJpbWVudGFsIGRyYWZ0LiBPciwgaWYgdGhlcmUgaXMgYW55IG90aGVyIHdheXMgdG8g
YWxsb3cgdGhlIGFsbG9jYXRpb24NCiAgICA+IChlLmcuIHVzaW5nIG90aGVyIGRvY3VtZW50cykN
CiAgICA+ICAgICBBMjogaWYgd2UgZGVjaWRlIHRvIGFsbG9jYXRlIHRoZSBiaXQsIHdoYXQgd2Ug
c2hvdWxkIGRvIHdoZW4gdGhlDQogICAgPiBleHBlcmltZW50IGZhaWxzLg0KICAgID4gDQogICAg
PiBCOiBPdmVybGFwcyB3aXRoIHNvbWUgY29uZ2VzdGlvbiBleHBlcmllbmNlZCBwcm9wb3NhbHMN
CiAgICA+ICBJdCBzZWVtcyB0aGF0IHNvbWUgY29uZ2VzdGlvbiBleHBlcmllbmNlZCBwcm9wb3Nh
bHMNCiAgICA+IChkcmFmdC1ncmltZXMtdGNwbS10Y3BzY2UNCiAgICA+IGFuZCBkcmFmdC1tb3J0
b24tdHN2d2ctc2NlKSBoYXZlIHNpbWlsYXJpdGllcyB3aXRoIHRoZXNlIGRyYWZ0cy4NCiAgICA+
IA0KICAgID4gIFRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBjaGVjayB0aGUgZm9sbG93aW5nIHBv
aW50cyBmb3IgdGhpcy4NCiAgICA+ICAgIEIxOiBUaGUgdHdvIHByb3Bvc2FscyB3b24ndCBjb25m
bGljdCBlYWNoIG90aGVyLiBXZSBjYW4gZGlzY3VzcyBhbmQNCiAgICA+IHByb2NlZWQgdGhlc2Ug
cHJvcG9zYWxzIHNlcGFyYXRlbHkgd2l0aG91dCBhbnkgcG90ZW50aWFsIHJpc2tzLg0KICAgID4g
ICAgQjI6IGl0IHNlZW1zIHRoYXQgU0NFIGFuZCBMNFMgbWF5IGhhdmUgc29tZSBjb25mbGljdHMs
IGJ1dCB0aGlzIHdpbGwNCiAgICA+IG5vdCBhZmZlY3QgdGhlIGRpc2N1c3Npb25zIGZvciBBY2NF
Q04gYW5kIEVDTisrLg0KICAgID4gICAgQjM6IGlmIHdlIGFsbG9jYXRlIHRoZSBiaXQgNyBmb3Ig
QWNjRUNOLCBpdCBpcyBzdGlsbCBhbGxvd2VkIGZvciBTQ0UNCiAgICA+IHByb3Bvc2FscyB0byB1
c2UgdGhlIGJpdCBvciBpdCB3aWxsIGJlIHByb2hpYml0ZWQuDQogICAgPiANCiAgICA+ICBCVFcs
IGp1c3QgaW4gY2FzZS4gcGxlYXNlIGF2b2lkIGluaXRpYXRpbmcgdGVjaG5pY2FsIGRpc2N1c3Np
b25zIGFuZCB0cnkNCiAgICA+IHRvIGRpc2N1c3MgaG93IHRvIHByb2NlZWQgdGhlIGRyYWZ0cyBp
biB0aGlzIHRocmVhZC4NCiAgICA+IC0tDQogICAgPiBZb3NoaSBvbiBiZWhhbGYgb2YgdGNwbSBj
aGFpcnMNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KICAgIHRjcG0gbWFpbGluZyBsaXN0DQogICAgdGNwbUBpZXRmLm9yZw0KICAgIGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KICAgIA0KDQo=


From nobody Tue Nov 12 10:54:44 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 82F4D12091F for ; Tue, 12 Nov 2019 10:54:42 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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=heistp.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 RT4xT2TTAQG9 for ; Tue, 12 Nov 2019 10:54:40 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 90346120846 for ; Tue, 12 Nov 2019 10:54:40 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id i12so12831946wro.5 for ; Tue, 12 Nov 2019 10:54:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j/RN117mgy053W+PVDdZrMFYzS8kNfUCvimL680XQ6s=; b=QVFAxeDSPb3o9hi/GYgmCg/Dbj6XNMoQNZveJvGSL2yuFcy0FRJnmihP3BsX1wApNo XR/QL0SdW/6CG97NxwXpW0o44oYGbhwa5iwV4yvXWaSjO4wwvL04TO3hxjEOqXaq9ACo FuRAT9R0NSjrMdnfU3TfwhfnQR5aAj7uBGjivZ/hGjBtaHeIp2ln9uwWD6MfDJR3FBQP 6mMVAbAG/ge9pUfBrertHmyiBtBZn//bVqn++NMXgDOmhMpA7RLV3EWV0wJnQg1ZoDCL bqyYdRDMbg6BeONU+RJpTlJvX2vbQypRkS043eVboDJq7swwQBs2XU7TPBilqsgO1v3t df9Q==
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=j/RN117mgy053W+PVDdZrMFYzS8kNfUCvimL680XQ6s=; b=nKVHdNrcenY12kWjZjsg/ioEchsT9t+MnY13964e5KEhzZDhRO7CDCcWfQtjEiIPNn x5W2hURRh1iW+8SZF1jyQXsTq3iSu8zquIXVsKZs8G6BApJ4aznJZGxL3K15h2q9umGf qqnpmHmL9OXfjSiJxF/KVzwCBi/1JzSpmokf/KtRrBKBNyJzEphOBGcV2Rq5IXHaZw1j KPWcJ94d1e9z5AB0IgDO14IgxvLlT0+SXkx1iBdcckP7HaoK3Ovx6Ogu9t38jUlpwgG4 3B42HTtQPneZSKkPH1BtpC1GX98rsbx9VhDVeKkge2yi6DGX+H4lXNJAEkYFizIlElar hPDA==
X-Gm-Message-State: APjAAAUjFojRVeTLCiXNUp0PMdZtuz1OLK6keHVoTVjWsB422O36fULk z2jv54zZQ8ZeYcmargi5VcFbAQ==
X-Google-Smtp-Source: APXvYqwb+k51SE9AS96DmJ5pCoCYJZwhp/031yxUrYkDYpFhFTh9EK2Jsf9LVaTx4owzqdn4vL3FOg==
X-Received: by 2002:a5d:4d0c:: with SMTP id z12mr19577714wrt.139.1573584879140;  Tue, 12 Nov 2019 10:54:39 -0800 (PST)
Received: from yoda.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id g133sm4680935wme.42.2019.11.12.10.54.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Nov 2019 10:54:38 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist 
In-Reply-To: <8382D634-8FEC-4932-96ED-9C5FB71E128D@ericsson.com>
Date: Tue, 12 Nov 2019 19:54:37 +0100
Cc: "nsd.ietf@gmail.com" , "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201911072222.xA7MMYXb017371@gndrsh.dnsmgr.net>  <8382D634-8FEC-4932-96ED-9C5FB71E128D@ericsson.com>
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 12 Nov 2019 18:54:43 -0000

> On Nov 12, 2019, at 5:30 PM, Mirja Kuehlewind =
 wrote:
>=20
> Peter, I don't think the AccECN draft should say anything about what =
happens to the ex-NS bit if it falls back to classic ECN because that's =
out of scope of the draft defining the AccECN mechanis. However, I agree =
that is would be available for another use.

Ok, thanks for the reply, if the allocation of that bit is not exclusive =
and it may still be used if AccECN is not negotiated, it sounds like =
that will work out.

Regards,
Pete


From nobody Tue Nov 12 13:45:03 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 E46A312006D for ; Tue, 12 Nov 2019 13:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 myl_xHcZABRj for ; Tue, 12 Nov 2019 13:45:01 -0800 (PST)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 DE5D2120127 for ; Tue, 12 Nov 2019 13:45:00 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xACLbDJP008681; Tue, 12 Nov 2019 13:44:56 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=VHf+gTiXf1ew19J5OA3Xh/naRVY+SpiI3LtRItEVSDY=; b=j1F9h1cX2Z2lDHDwYjMvibq1XRDLv9Zd2zyMejazUo93grbuzJ8LS+fGHmkzz1cg1/pW 4PKVVHqvXJuP9MqVqPl51N956lBMc4YIFp5P7EutQVuLgGrblfboiIw3Xn+3Q72+tDBh 4JEC0Kmiz3Y8/VKIhlekoLUATuu6E6aBTOICbS6w6Bw7QQ6UfmSl83MiqCWXeOhGX5YP Atq/0qpRyTuy8/ZhS23f4oNI3wik9MQSzOBkbKTcjLRyGGGQ3ch4kthRz6+g2xliIL+j UVS6pRGpl2Yfb5f5J+8Duc/Jxhc77S8x2nHP+j6iKHBiY2Ab+8JFPQvTLxouiL0NH0uR Uw== 
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2w6eexhmcv-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Nov 2019 13:44:56 -0800
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPS id <0Q0V001XRLQVS7D0@mr2-mtap-s01.rno.apple.com>; Tue, 12 Nov 2019 13:44:55 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) id <0Q0V00600LEEG100@nwk-mmpp-sz12.apple.com>; Tue, 12 Nov 2019 13:44:55 -0800 (PST)
X-V-A: 
X-V-T-CD: 87af957b8464877f93b78faa11c65a6a
X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d
X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b
X-V-CD: 0
X-V-ID: ac0ca2b7-3a23-4faf-a07f-64408324150d
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-12_08:,, signatures=0
Received: from vimac.scv.apple.com (vimac.scv.apple.com [17.192.171.33]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPSA id <0Q0V008JCLQP4D20@nwk-mmpp-sz12.apple.com>; Tue, 12 Nov 2019 13:44:49 -0800 (PST)
Sender: vidhi_goel@apple.com
From: Vidhi Goel 
Message-id: <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_0B2AAECD-F241-409C-A752-DDFF9427AF62"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3578.1\))
Date: Tue, 12 Nov 2019 13:44:49 -0800
In-reply-to: 
Cc: "tcpm@ietf.org" , mallman@bbn.com
To: Neal Cardwell 
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> 
X-Mailer: Apple Mail (2.3578.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-12_08:, , signatures=0
Archived-At: 
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
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, 12 Nov 2019 21:45:03 -0000

--Apple-Mail=_0B2AAECD-F241-409C-A752-DDFF9427AF62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+Mark Allman

Thank you Neal for the detailed explanation.

I believe that ABC was written to solve the problem with ACK counting by =
counting the number of bytes acknowledged for misbehaving receivers. =
Limiting the increase to 2*MSS was a good solution to avoid bursts at =
the time.

I agree that increasing the congestion window and controlling the burst =
rate are orthogonal issues. ABC intended to solve them by regulating the =
congestion window itself and this approach might have become outdated =
with implementations trying to solve these two issues separately.

Is it worth investing time in writing another draft to document what =
Linux (and possibly other implementations) do for more accurate =
congestion window growth and for solving the burst send issue via =
pacing, TSQ etc.?

Thanks,
Vidhi

> On Nov 5, 2019, at 3:25 PM, Neal Cardwell =
 wrote:
>=20
>=20
>=20
> On Tue, Nov 5, 2019 at 5:08 PM Vidhi Goel =
> wrote:
> Hi All,
>=20
> RFC 3465 suggests to increase the congestion window by the number of =
previously unacknowledged bytes ACKed by each ACK limiting the increase =
to L (L =3D 2MSS or 1MSS in certain conditions). The limiting factor L =
helps to avoid the large bursts that could occur due to stretch ACKs, =
ACK loss or compressed ACKs (GRO/GSO).
>=20
> But, when I looked at Linux source code, it implements one aspect of =
ABC (byte counting to defend from ACK attacks) but doesn=E2=80=99t  =
=E2=80=9Ccap=E2=80=9D the increase to L.=20
>  =
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_cong..c#L385 =

>=20
> This is a bit confusing. How should we address this discrepancy?
>=20
> The differences between the Linux code and the ABC RFC  ( =
https://tools.ietf.org/html/rfc3465 =
 ) are intentional.. The Linux TCP =
code in this area is largely from:
>=20
> 9f9843a751d0 tcp: properly handle stretch acks in slow start
> 95224ac1801c Merge branch 'tcp_stretch_acks'
> d6b1a8a92a14 tcp: fix timing issue in CUBIC slope calculation
> 9cd981dcf174 tcp: fix stretch ACK bugs in CUBIC
> c22bdca94782 tcp: fix stretch ACK bugs in Reno
> 814d488c6126 tcp: fix the timid additive increase on stretch ACKs
> e73ebb0881ea tcp: stretch ACK fixes prep
>=20
> That code is based on experience at Google, both with internal traffic =
and google.com  and YouTube traffic. Experience was =
showing that preventing the full use of ACKs in growing the cwnd in slow =
start and CUBIC's rapid growth phase causes anemic growth in real-world =
situations.
>=20
> The basic principle in the Linux code is that the sender should use =
the ACKs to learn about the capacity of the path (both in volumetric and =
rate dimensions), and should not ignore that information. This allows =
the sender to quickly grow and achieve high throughput, even in the =
presence of stretch ACKs, which are pervasive, due to TSO/GSO, GRO/LRO, =
etc.
>=20
> Considering bursts is important, but that can be tackled as an =
orthogonal issue. Bursts are avoided in the Linux TCP ecosystem by the =
combination of TSO autosizing, pacing, TSQ, and fair queueing.
>=20
> Here is a summary of the Linux TCP design in this area:
>   https://netdevconf.info/1.2/papers/bbr-netdev-1.2.new.new.pdf =

>=20
> best,
> neal
>=20


--Apple-Mail=_0B2AAECD-F241-409C-A752-DDFF9427AF62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


+Mark Allman

Thank =
you Neal for the detailed explanation.

I believe that ABC was written to solve =
the problem with ACK counting by counting the number of bytes =
acknowledged for misbehaving receivers. Limiting the increase to 2*MSS =
was a good solution to avoid bursts at the time.

I agree that increasing the congestion =
window and controlling the burst rate are orthogonal issues. ABC =
intended to solve them by regulating the congestion window itself and =
this approach might have become outdated with implementations trying to =
solve these two issues separately.

Is it worth investing time in writing =
another draft to document what Linux (and possibly other =
implementations) do for more accurate congestion window growth and for =
solving the burst send issue via pacing, TSQ etc.?

Thanks,
Vidhi

On Nov =
5, 2019, at 3:25 PM, Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> =
wrote:



On Tue, Nov 5, 2019 at 5:08 PM Vidhi =
Goel <vidhi_goel=3D40apple..com@dmarc.ietf.org> wrote:
Hi All,

RFC 3465 suggests to increase the =
congestion window by the number of previously unacknowledged bytes ACKed =
by each ACK limiting the increase to L (L =3D 2MSS or 1MSS in certain =
conditions). The limiting factor L helps to avoid the large bursts that =
could occur due to stretch ACKs, ACK loss or compressed ACKs =
(GRO/GSO).

But, when I looked at Linux source =
code, it implements one aspect of ABC (byte counting to defend from ACK =
attacks) but doesn=E2=80=99t  =E2=80=9Ccap=E2=80=9D the increase to =
L. 
 https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_cong=
..c#L385

This is a bit confusing. How should =
we address this discrepancy?

The differences between the Linux code =
and the ABC RFC  ( https://tools.ietf.org/html/rfc3465 ) are =
intentional.. The Linux TCP code in this area is largely from:

9f9843a751d0 tcp: =
properly handle stretch acks in slow start
95224ac1801c Merge branch 'tcp_stretch_acks'
d6b1a8a92a14 tcp: fix timing issue in CUBIC slope =
calculation
9cd981dcf174 tcp: fix stretch ACK bugs in =
CUBIC
c22bdca94782 tcp: fix stretch ACK bugs in Reno
814d488c6126 tcp: fix the timid additive increase on stretch =
ACKs
e73ebb0881ea tcp: stretch ACK fixes prep

That=
 code is based on experience at Google, both with internal traffic and =
google.com and YouTube =
traffic. Experience was showing that preventing the full use of ACKs in =
growing the cwnd in slow start and CUBIC's rapid growth phase causes =
anemic growth in real-world situations.

The basic principle in the Linux code =
is that the sender should use the ACKs to learn about the capacity of =
the path (both in volumetric and rate dimensions), and should not ignore =
that information. This allows the sender to quickly grow and achieve =
high throughput, even in the presence of stretch ACKs, which are =
pervasive, due to TSO/GSO, GRO/LRO, etc.

Considering bursts is important, but =
that can be tackled as an orthogonal issue. Bursts are avoided in the =
Linux TCP ecosystem by the combination of TSO autosizing, pacing, TSQ, =
and fair queueing.

Here is a summary of the Linux TCP design in this =
area:
  https://netdevconf.info/1.2/papers/bbr-netdev-1.2.new.new.pdf

best,
neal




=

--Apple-Mail=_0B2AAECD-F241-409C-A752-DDFF9427AF62--


From nobody Tue Nov 12 15:19: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 9349C12008D; Tue, 12 Nov 2019 15:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] 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 UdJFJr-CG_vV; Tue, 12 Nov 2019 15:19:17 -0800 (PST)
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 694F0120045; Tue, 12 Nov 2019 15:19:17 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8C44025A17; Wed, 13 Nov 2019 00:19:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573600755; bh=8HDJzTm7AdZ+PwvRzKCVNPXJMoyiSxm9ggr2xGaEu64=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=YUSnJhh3gS9IHEzbPhkVcccFxCDfwoPD5BaI5FjgnrhyaCeVCru/e3GjeO09VT4wW e72Uu+T1KJX0n2lt3MXL8qOz0yoRLBc18Lov+BjhIK3Fv2ddvCOVj3MEQcG05OedEU i/vG12nSNskj275R27aMw2Gb02gspwfSFi/SWiVU=
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 zNZdRjq89aYW; Wed, 13 Nov 2019 00:19:14 +0100 (CET)
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; Wed, 13 Nov 2019 00:19:14 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 00:19:14 +0100
From: "Scharf, Michael" 
To: Mirja Kuehlewind 
CC: "tcpm@ietf.org" , "draft-ietf-tcpm-accurate-ecn@ietf.org" 
Thread-Topic: Review of draft-ietf-tcpm-accurate-ecn-09
Thread-Index: AdVmkQbRiws//6LkT9maAPvdYMbTHgtSQZWAAXMTdrA=
Date: Tue, 12 Nov 2019 23:19:13 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4FF9A6@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D437955@rznt8114.rznt.rzdir.fht-esslingen.de> <8E7B2A65-6EED-458E-A98B-98B0550330BB@kuehlewind.net>
In-Reply-To: <8E7B2A65-6EED-458E-A98B-98B0550330BB@kuehlewind.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Review of draft-ietf-tcpm-accurate-ecn-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: Tue, 12 Nov 2019 23:19:20 -0000

SW5saW5lLi4uDQoNCj4gPiAqIEFic3RyYWN0L0ludHJvZHVjdGlvbg0KPiA+DQo+ID4gIGRyYWZ0
LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24gY3VycmVudGx5IGhhcyBhdCBsZWFzdCB0d28gcm9sZXM6
IEl0IGFsbG93cw0KPiBlY2hvaW5nIENFIG1hcmtzIGluIFNZTiBzZWdtZW50cyBhbmQgdGhlcmVm
b3JlLCBpbiBjb21iaW5hdGlvbiB3aXRoIGRyYWZ0LQ0KPiBpZXRmLXRjcG0tZ2VuZXJhbGl6ZWQt
ZWNuLCBhbGxvd3MgdG8gc2V0IEVDVCBvbiBTWU5zLCBhbmQgaXQgcHJvdmlkZXMgZmVlZGJhY2sN
Cj4gbW9yZSB0aGFuIG9uY2UgcGVyIFJUVC4gSSBjYW4gdGhpbmsgb2Ygc2NlbmFyaW9zIGluIHdo
aWNoIHRoZSBmb3JtZXIgaXMgbW9yZQ0KPiBiZW5lZmljaWFsIHRoYW4gdGhlIGxhdHRlciwgaS5l
LiwgaW4gd2hpY2ggdGhlcmUgaXMgYmVuZWZpdCBvZiBlbmFibGluZyBFQ1QgaW4gU1lOcywNCj4g
YnV0IGZlZWRiYWNrIG9uY2UgcGVyIFJUVCBpcyBlbm91Z2guDQo+ID4NCj4gPiAgT25lIHNwZWNp
ZmljIGV4YW1wbGUgKGFsYmVpdCBpdCBtYXkgbm90IGJlIHRoZSBvbmx5IG9uZSkgaXMgZGVzY3Jp
YmVkIGluIGRyYWZ0LQ0KPiBpZXRmLWx3aWctdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29ya3M6
IEEgc2VuZGVyIG9uIGVtYmVkZGVkIGRldmljZXMgd2l0aA0KPiB2ZXJ5IHNtYWxsIHdpbmRvdyAo
c2F5LCBpbml0aWFsbHkgb25seSBvbmUgTVNTKSBjb3VsZCBwcm9iYWJseSBiZW5lZml0IGZyb20N
Cj4gaGF2aW5nIENFIG1hcmtzIGluc3RlYWQgb2YgbG9zcyBmb3IgU1lOcywgYnV0IGluaGVyZW50
bHkgdGhlcmUgY291bGQgb25seSBiZSBvbmUNCj4gQ0UgbWFyayBwZXIgUlRUIGlmIHRoZXJlIGlz
IGF0IG1vc3Qgb25lIHNlZ21lbnQgb3V0c3RhbmRpbmcsIHNvIFJGQzMxNjgtc3R5bGUNCj4gZmVl
ZGJhY2sgc2VlbXMgZ29vZCBlbm91Z2guIEJlaW5nIGFibGUgdG8gcmVmbGVjdCBtb3JlIENFIG1h
cmtzIHBlciBSVFQgaXMNCj4gbm90IG5lZWRlZCBpbiB0aGF0IGNhc2UgYW5kIHRoZSBpbXBsZW1l
bnRhdGlvbiBvdmVyaGVhZCBvZiBkb2luZyB0aGlzIG9uIGFuDQo+IElvVCBkZXZpY2UgbWF5IGJl
IHF1ZXN0aW9uYWJsZS4gVGhpcyBpcyBhbiBhcmVhIHZlcnkgZGlmZmVyZW50IGUuZy4gZnJvbSBE
Q1RDUCwNCj4gYnV0IFRDUCBpcyBhIGdlbmVyYWwgcHVycG9zZSBwcm90b2NvbCB0aGF0IGFsc28g
bWF0dGVycyBpbiBJb1QuIEkgYW0gbm90IGF3YXJlDQo+IG9mIG11Y2ggY3VycmVudCB1c2Ugb2Yg
RUNOIGluIHRoZSBJb1QgYXJlYSwgYnV0IHRoZXJlIGNhbiBiZSBjb250cm9sbGVkDQo+IGVudmly
b25tZW50cyBpbiB0aGlzIHNwYWNlIGFzIHdlbGwsIHdoaWNoLCB0aGVvcmV0aWNhbGx5LCBtYXkg
YmUgYWJsZSB0byByb2xsIG91dA0KPiBFQ04gZWFybGllciB0aGFuIHRoZSBwdWJsaWMgSW50ZXJu
ZXQuIFdoaWxlIEkgYmVsaWV2ZSB0aGF0IHRoZSBoYW5kc2hha2UgYW5kIHRoZQ0KPiBtb3JlLXRo
YW4tb25jZS1wZXItUlRUIGZlZWRiYWNrIGR1cmluZyBhIGNvbm5lY3Rpb24gYXJlIHR3byBzZXBh
cmF0ZSBpdGVtcw0KPiB0aGF0IGNvdWxkIGV2ZW4gYmUgc3BlY2lmaWVkIHNlcGFyYXRlbHksIEkg
Y2Fubm90IGFzayBmb3Igc3VjaCBzZXBhcmF0aW9uIGFzIEkgZG8NCj4gbm90IG93biBydW5uaW5n
IGNvZGUuDQo+ID4NCj4gPiAgQnV0IEkgYmVsaWV2ZSBpdCB3b3VsZCBhdCBsZWFzdCBtYWtlIHNl
bnNlIHRvIGJldHRlciBzdHJlc3MgaW4gdGhlIGFic3RyYWN0IGFuZA0KPiBpbnRyb2R1Y3Rpb24g
dGhhdCBtb3JlIGFjY3VyYXRlIEVDTiBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBkdXJpbmcgdGhl
DQo+IGhhbmRzaGFrZSBhbmQgZm9yIGNvbnRyb2wgc2VnbWVudHMuIEFzIEkgd3JvdGUsIGluIHNv
bWUgdXNlIGNhc2VzIHRoaXMgbWF5IGJlDQo+IHRoZSAob25seSkgcmVsZXZhbnQgcGFydCBvZiB0
aGUgcHJvdG9jb2wuLg0KPiANCj4gQXMgc3BlY2lmaWVkIGluIHRoZSByZXF1aXJlbWVudHMgUkZD
IHRoZSBnb2FsIG9mIGFjY3VyYXRlIEVDTiBpcyB0byBwcm92aWRlDQo+IG1vcmUgYWNjdXJhdGUg
RUNOIGZlZWRiYWNrIHRoYW4gb25jZSBwZXIgUlRULiBIYXZpbmcgZmVlZGJhY2sgb24gYSBwZXIN
Cj4gcGFja2V0IGJhc2lzIGFuZCB3ZWxsIGFzIHBlciBieXRlIGlzIHRoZSBkZXNpZ24gdGhlIGdy
b3VwIHNldHRsZSBvbiB3aGljaCBoYXMgdGhlDQo+IG5pY2UgYmVuZWZpdCB0aGF0IHRoaXMgYWxz
byByZWZsZWN0cyBtYXJraW5nIG9mIHRoZSBTWU4uIEkgdGhpbmsgdGhlIGdvYWwgb2YNCj4gQWNj
RUNOIGlzIGNsZWFybHkgc3RhdGVkIGluIHRoZSBkb2N1bWVudC4gSG93ZXZlciwgaWYgeW91IGhh
dmUgYSBjb25jcmV0ZQ0KPiBwcm9wb3NhbCBmb3IgYWRkaXRpb25hbCB0ZXh0LCBwbGVhc2Ugc2Vu
ZCBpdC4NCg0KSSdkIHN1Z2dlc3QgdG8gYWRkIHRvIGFic3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24g
YSBzZW50ZW5jZSBhbG9uZyB0aGUgbGluZXMgb2YgIlRoZSBBY2NFQ04gbmVnb3RpYXRpb24gaGFz
IGJlZW4gZGVzaWduZWQgYXMgYSBnZW5lcmljIHJlZmxlY3RvciB0aGF0IGFsc28gcHJvdmlkZXMg
ZmVlZGJhY2sgZm9yIEVDTiBtYXJraW5ncyBpbiBTWU4gc2VnbWVudHMuIg0KDQpUbyBtZSwgdGhp
cyByZWZsZWN0b3IgcHJvcGVydHkgZHVyaW5nIFNZTnMgY291bGQgaW4gY2VydGFpbiBjYXNlcyBi
ZSBtdWNoIG1vcmUgcmVsZXZhbnQgdGhhbiB0aGUgZmVlZGJhY2sgbW9yZSB0aGFuIG9uY2UgcGVy
IFJUVC4gVGhlcmVmb3JlLCBJIGJlbGlldmUgaXQgc2hvdWxkIGJlIG1hZGUgZXhwbGljaXQgaW4g
dGhlIGFic3RyYWN0LiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGlzIG9iamVjdGl2ZSBoYXMg
YWxzbyBzaWduaWZpY2FudGx5IGluZmx1ZW5jZWQgdGhlIGRlc2lnbiBvZiB0aGUgQWNjRUNOIHBy
b3RvY29sIGR1cmluZyB0aGUgMy13YXkgaGFuZHNoYWtlIGFuZCB0aGUgZnVuY3Rpb25hbGl0eSBk
b2VzIG5vdCBjb21lIGVudGlyZWx5IGZvciBmcmVlLCBlLmcuLCBhcyBpdCBjb25zdW1lcyBjb2Rl
cG9pbnQgY29tYmluYXRpb25zLg0KDQpBbHNvLCBvdXQgb2YgbXkgaGVhZCwgdGhpcyByZXF1aXJl
bWVudCBpcyBub3QgY2xlYXJseSBzcGVsdCBvdXQgaW4gUkZDIDc1NjAsIGkuZS4sIHRoZSBwcm90
b2NvbCBtYXkgYWN0dWFsbHkgb3V0cGVyZm9ybSB0aGUgcmVxdWlyZW1lbnRzLiBUaGF0IHdvdWxk
IGJlIGFub3RoZXIgcmVhc29uIHdoeSB0byBtZW50aW9uIGl0Lg0KDQo+ID4gKiBGaWd1cmUgMQ0K
PiA+DQo+ID4gIEZpZ3VyZSAxIGlzIG91dGRhdGVkLiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB0
aGlzIGRvY3VtZW50IGRyYXdzIGEgcGljdHVyZQ0KPiB3aXRoIHRoZSAiTlMiIGZsYWcsIHdoaWNo
IGlzIGhpc3RvcmljIGFuZCBoYXMgcHJvYmFibHkgbmV2ZXIgYmVlbiB1c2VkIGluIHdpZGVseQ0K
PiBkZXBsb3llZCBydW5uaW5nIGNvZGUuIEZpZ3VyZSAxIHNob3VsZCBiZSByZW1vdmVkLiBJbnN0
ZWFkLCB3aGF0IHdvdWxkIG1ha2UNCj4gYSBsb3Qgb2Ygc2Vuc2UgaXMgdG8gYWRkIGEgZmlndXJl
IGxhdGVyIGluIHRoZSBub3JtYXRpdmUgcGFydCBvZiB0aGUgZG9jdW1lbnQsDQo+IGUuZy4gaW4g
U2VjdGlvbiAzLjEuIFRoYXQgZmlndXJlIHNob3VsZCBzaG93IHRoZSBUQ1AgaGVhZGVyIHdpdGgg
IkFFIiBmbGFnIGFzDQo+IGJlaW5nIHVzZWQgaW4gU1lOIHNlZ21lbnRzLg0KPiANCj4gQXMgdGhl
IHNlY3Rpb24gY2xlYXJseSBzdGF0ZXMgdGhpcyBzZWN0aW9uIHByb3ZpZGVzIGEgcmVjYXAgb2Yg
b3RoZXIgZmVlZGJhY2sNCj4gbWVjaGFuaXNtIGluIFRDUCBhbmQgdGhlIHBpY3R1cmUgc2hvd3Mg
IlRoZSAocG9zdC1FQ04gTm9uY2UpIGRlZmluaXRpb24gb2YNCj4gdGhlIFRDUCBoZWFkZXIgZmxh
Z3PigJ0gYXMgdGhlIHRpdGxlIHNheXMuIFRoaXMgaXMgdG8gbWFrZSBjbGVhciB3aGF0IHRoZSBy
ZWxhdGlvbg0KPiB0byB0aGUgTlMgYml0IGlzIGFzIHdlIHJlLXVzZSBhIFRDUCBoZWFkZXIgZmxh
ZyBmb3IgdGhlIGZpcnN0IHRpbWUuIEhvd2V2ZXIsIHdlDQo+IGNvdWxkIHByb2JhYmx5IGFkZCBh
bm90aGVyIHN1Y2ggZGlhZ3JhbSB3aXRoIEFFIGluc3RlYWQgb2YgTlMgaW4gdGhlIG5leHQNCj4g
c2VjdGlvbi4NCg0KSSBjb250aW51ZSB0byBiZWxpZXZlIHRoYXQgRmlndXJlIDEgZG9lcyBub3Qg
aGVscCBhbmQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGlzIHNlY3Rpb24uDQoNCkZpcnN0LCBn
aXZlbiB0aGF0IHRoZSBleHBlcmltZW50IGlzIGZpbmlzaGVkLCB3ZSByZWFsbHkgc2hvdWxkIHN0
b3AgdGFsa2luZyBhYm91dCAiTlMgZmxhZyIuIFBlb3BsZSBzaG91bGQgdXNlIHRoZSBuZXcgdGVy
bSBjb25zaXN0ZW50bHkgZnJvbSBub3cgb24uIFRoZSBiZXN0IHdheSB0byBhY2hpZXZlIHRoaXMg
aXMgSU1ITyBqdXN0IHRvIHNob3cgZmlndXJlcyB3aXRoIHRoZSBuZXcgaGVhZGVyIChpLmUuLCBh
Y2NvcmRpbmcgdG8gQWNjRUNOKS4gSSBiZWxpZXZlIGl0IGlzIG5vdCB1bmNvbW1vbiBmb3IgcmVh
ZGVycyBqdXN0IHRvIHNjYW4gdGhyb3VnaCB0aGUgZG9jdW1lbnQgYW5kIGxvb2sgYXQgdGhlIGZp
cnN0IEFTQ0lJIGFydCBmb3IgYSBoZWFkZXIgdGhleSBjYW4gZmluZC4gSW4gdGhhdCBjYXNlLCBG
aWd1cmUgMSBpcyBleGFjdGx5IHRoZSB3cm9uZyBjb250ZW50LiBOb3RlIHRoYXQgb25lIHdheSB0
byBhdm9pZCB0aGF0IHdvdWxkIGJlIHRvIG1vdmUgRmlndXJlIDEgdG8gYW4gYXBwZW5kaXguIFRo
YXQgY291bGQgd29yayBmb3IgbWUuIFRoZSBuZXcgc2Vjb25kIEZpZ3VyZSB3aXRoIHRoZSBBRSBm
bGFnIGNvdWxkIHNvbWV3aGVyZSBub3RlIHRoYXQgdGhlIEFFIGZsYWcgaXMgaWRlbnRpY2FsIHRv
IHRoZSBmb3JtZXIgTlMgZmxhZywgaW4gb3JkZXIgdG8gaGlnaC1saWdodCByZWxhdGlvbi4gVGhl
biB0aGVyZSBpcyBubyBhZGRlZCB2YWx1ZSBvZiB0aGUgY3VycmVudCBGaWd1cmUgMSBpbiBteSBw
b2ludCBvZiB2aWV3Lg0KDQpTZWNvbmQsIHRoZSBjYXB0aW9uIG9mIEZpZ3VyZSAxICJUaGUgKHBv
c3QtRUNOIE5vbmNlKSBkZWZpbml0aW9uIG9mIHRoZSBUQ1AgaGVhZGVyIGZsYWdzIiBlbnRpcmVs
eSBsYWNrcyBhIHdhcm5pbmcgc2lnbiB0aGF0IHRoaXMgaXMgYSBoaXN0b3JpYyBwaWN0dXJlLiBJ
IGJlbGlldmUgd29yZGluZyBsaWtlICJUaGUgaGlzdG9yaWMgUkZDIDM1NDAgZGVmaW5pdGlvbiBv
ZiBUQ1AgaGVhZGVyIGZsYWdzIiB3b3VsZCBiZSByZXF1aXJlZCwgc2F5LCBpbiBhbiBBcHBlbmRp
eCB2ZXJzaW9uIG9mIHRoaXMgZmlndXJlIGlmIHJlbW92YWwgaXMgbm90IGFuIG9wdGlvbi4NCg0K
PiA+ICogU2VjdGlvbiAyLjQgKGFuZCBlbHNld2hlcmUpDQo+ID4NCj4gPiAgVGhlcmUgaXMgYW4g
KHdlbGwsIElNSE8pIHVubmVjZXNzYXJ5IHJlcGV0aXRpb24gb2YgTDRTIGFuZCBDb25FeCBhdCBt
YW55DQo+IHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQuIEkgYW0gZmluZSB3aXRoIGludHJvZHVjaW5n
IGl0IGluIHRoZSBpbnRyb2R1Y3Rpb24uDQo+IEhvd2V2ZXIsIGZvciBpbnN0YW5jZSwgU2VjdGlv
biAyLjQgc3RhdGVzICJJZiBib3RoIGFyZSBwcmVzZW50LCB0aGUgYnl0ZSBjb3VudGVyDQo+IGlu
IHRoZSBvcHRpb24gd2lsbCBwcm92aWRlIHRoZSBtb3JlIGFjY3VyYXRlIGluZm9ybWF0aW9uIG5l
ZWRlZCBmb3IgbW9kZXJuDQo+IGNvbmdlc3Rpb24gY29udHJvbCBhbmQgcG9saWNpbmcgc2NoZW1l
cywgc3VjaCBhcyBMNFMsIERDVENQIG9yIENvbkV4LiIgSXQNCj4gd291bGQgYmUgc3VmZmljaWVu
dCB0byBzdGF0ZSAiSWYgYm90aCBhcmUgcHJlc2VudCwgdGhlIGJ5dGUgY291bnRlciBpbiB0aGUg
b3B0aW9uDQo+IHdpbGwgcHJvdmlkZSB0aGUgbW9yZSBhY2N1cmF0ZSBpbmZvcm1hdGlvbiIuIEF0
IGxlYXN0IGZvciBEQ1RDUCBpdCBpcyBJTUhPIG5vdA0KPiBwcm92ZW4gdGhhdCB0aGUgaW5mb3Jt
YXRpb24gaW4gdGhlIF9vcHRpb25fIGlzIGluZGVlZCBuZWVkZWQsIGFzIGltcGxpZWQgYnkgdGhp
cw0KPiB3b3JkaW5nLiBBcyBhbHNvIGV4cGxhaW5lZCBhbHJlYWR5LCBzb21lIGFzcGVjdHMgb2Yg
QWNjRUNOIGNvdWxkIGFsc28gYmUNCj4gdXNlZnVsIGluIHF1aXRlIGRpZmZlcmVudCBlbnZpcm9u
bWVudHMgYW5kIGl0IGlzIHVuY2xlYXIgdG8gbWUgd2h5IG9ubHkgTDRTLA0KPiBEQ1RDUCBhbmQg
Q29uRXggYXJlIG1lbnRpb25lZCBzbyByZXBlYXRlZGx5IGFzIChvbmx5KSBleGFtcGxlcy4NCj4g
DQo+IEJlY2F1c2UgdGhlc2UgYXJlIHRoZSBhcHByb2FjaGVzIHRoYXQgdGhlIElFVEYgaGFzIHNw
ZWNpZmllZCwgZG9jdW1lbnRlZCwgYW5kDQo+IGlzIHdvcmtpbmcgb24uLi4/IEhvd2V2ZXIsIGdp
dmVuIGl0IHNheXMg4oCcYXMgc3VjaOKAnSBpdCBub3Qgc3VwcG9zZWQgdG8gZXhjbHVkZQ0KPiBv
dGhlciBmdXR1cmUgbWVjaGFuaXNtcy4gSSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHRoZSBj
b25jZXJuIGhlcmUgYW5kIHdvdWxkDQo+IGFkdm9jYXRlIGZvciByZWZlcmVuY2luZyBvdGhlciBl
eGlzdGluZyB3b3JrIG9mIHRoZSBJRVRGIHdoZXJlIHBvc3NpYmxlLg0KDQpUaGUgc3BlY2lmaWMg
Y29tbWVudCBpbiB0aGUgcXVvdGVkIHNlY3Rpb24gaXMgYWJvdXQgdGhlIHdvcmRpbmcgInRoZSBi
eXRlIGNvdW50ZXIgaW4gdGhlIG9wdGlvbiIuIEFuZCBpdCBzZWVtcyB0aGF0IEw0UyBkb2VzIG5v
dCAnbmVlZCcgdGhlIG9wdGlvbiwgYW5kIG5laXRoZXIgZG9lcyBEQ1RDUC4gSSBjb3VsZCByZWFk
IHRoaXMgc2VudGVuY2UgYXMgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBBY2NFQ04gb3B0aW9uIGlz
IG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgaW4gTDRTIG9yIERDVENQLg0KDQpNYXliZSB0aGF0IGlz
IG5vdCB0aGUgaW50ZW50aW9uIGJ1dCB0aGVuIHBsZWFzZSByZXBocmFzZSBpdCBhcyBpdCBjb25m
dXNlcyBhcyBsZWFzdCBtZS4gSSBoYXZlIHByb3ZpZGVkIGFuIGFsdGVybmF0aXZlIHNlbnRlbmNl
IHRoYXQgaGFzIG5vIGFtYmlndWl0eSBpbiBteSB2aWV3LiAgDQoNCj4gPiAqIFNlY3Rpb24gMy4x
LjIuICBGb3J3YXJkIENvbXBhdGliaWxpdHkNCj4gPg0KPiA+ICAgIklmIGEgVENQIHNlcnZlciB0
aGF0IGltcGxlbWVudHMgQWNjRUNOIHJlY2VpdmVzIGEgU1lOIHdpdGggdGhlIHRocmVlDQo+ID4g
ICBUQ1AgaGVhZGVyIGZsYWdzIChBRSwgQ1dSIGFuZCBFQ0UpIHNldCB0byBhbnkgY29tYmluYXRp
b24gb3RoZXIgdGhhbg0KPiA+ICAgMDAwLCAwMTEgb3IgMTExLCBpdCBNVVNUIG5lZ290aWF0ZSB0
aGUgdXNlIG9mIEFjY0VDTiBhcyBpZiB0aGV5IGhhZA0KPiA+ICAgYmVlbiBzZXQgdG8gMTExLiAg
VGhpcyBlbnN1cmVzIHRoYXQgZnV0dXJlIHVzZXMgb2YgdGhlIG90aGVyDQo+ID4gICBjb21iaW5h
dGlvbnMgb24gYSBTWU4gY2FuIHJlbHkgb24gY29uc2lzdGVudCBiZWhhdmlvdXIgZnJvbSB0aGUN
Cj4gPiAgIGluc3RhbGxlZCBiYXNlIG9mIEFjY0VDTiBzZXJ2ZXJzLiINCj4gPgkNCj4gPiAgSSBo
YXZlIHRob3VnaHQgYWJvdXQgdGhlIHByb3MgYW5kIGNvbnMgb2YgdGhpcyBmb3J3YXJkIGNvbXBh
dGliaWxpdHkgcXVpdGUgYQ0KPiBiaXQgYW5kIEkgYW0gbm90IGVudGlyZWx5IGNvbnZpbmNlZCBv
ZiB0aGUgYmVuZWZpdHMgb2YgdGhpcyBydWxlLCBlLmcuLCBvbmUgY291bGQNCj4gZXF1YWxseSBh
cmd1ZSB0aGF0IGZhbGxiYWNrIHRvIFJGQyAzMTY4IHdvdWxkIGJlIHF1aXRlIHJlYXNvbmFibGUg
YXMgdGhpcyBpcyBhDQo+IHN0YW5kYXJkIHRoYXQgaXMgc2FmZSB0byB1c2UuIEJ1dCBJIHdpbGwg
bm90IGZ1cnRoZXIgcHVzaCBiYWNrIG9uIHRoaXMgYXNwZWN0IGlmIEkNCj4gYW0gdGhlIG9ubHkg
b25lIHBlcnNvbiB3aG8gY2FyZXMgYWJvdXQgaXQuDQo+ID4NCj4gPiAgSGF2aW5nIHNhaWQgdGhp
cywgd2hhdCBJTUhPIGlzIG1pc3NpbmcgaXMgYW4gYWRkaXRpb24gdG8gdGhlIGZpcnN0IHNlbnRl
bmNlDQo+IGFsb25nIHRoZSBsaW5lcyBvZiAiLi4uIHVubGVzcyB0aGUgVENQIHNlcnZlciBpbXBs
ZW1lbnRzIGEgVENQIGV4dGVuc2lvbiB0aGF0DQo+IHVzZXMgdGhlc2UgY29kZXBvaW50cyIuIEl0
IGlzIHdlbGwgdW5kZXJzdG9vZCB0aGF0IGFzIG9mIHRvZGF5IG5vIHN1Y2ggVENQDQo+IGV4dGVu
c2lvbiBleGlzdHMuIEJ1dCB0aGUgdGV4dCBvZiBhbiBSRkMgZG9lcyBub3QgY2hhbmdlIGFuZCBp
ZiBpdCBjb250YWlucw0KPiBmb3J3YXJkLWxvb2tpbmcgc3RhdGVtZW50cywgdGhlc2Ugc3RhdGVt
ZW50cyBzaG91bGQgYmUgd3JpdHRlbiBpdCBpbiBhIHdheSB0aGF0DQo+IHRoZSB0ZXh0IHN0YXlz
IHZhbGlkIGFsc28gaW4gZnV0dXJlLCBhcyBmYXIgYXMgdGhpcyBpcyBwb3NzaWJsZQ0KPiANCj4g
SSB0aGluayB0aGlzIGhhcyBiZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIHBhc3QuIEkg
YWxzbyBkb27igJl0IHJlYWxseSBzZWUgdGhlDQo+IGRpZmZlcmVudCBmb3IgdGhlIGFkZGl0aW9u
IHlvdSBwcm9wb3NlZCBhcyBvZiBjb3Vyc2UgbmV3IFJGQ3MgbWF5IGFsd2F5cyBhZGQNCj4gYWRk
aXRpb25hbCBtZWNoYW5pc20gYW5kIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIHRleHQgaGVyZSB0
aGF0IGV4Y2x1ZGVzIHRoYXQuDQoNCk1heWJlIHdlIGNhbiBqdXN0IGFncmVlIHRvIGRpc2FncmVl
IG9uIHRoYXQuDQoNCkkgYmVsaWV2ZSBvdGhlcnMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxk
IGhhdmUgYSBjYXJlZnVsIGxvb2sgYXQgdGhpcyBzZWN0aW9uIGFuZCBpdHMgZGVwbG95bWVudCBp
bXBsaWNhdGlvbnMsIG1vc3Qgbm90YWJseSBpbiBjb21iaW5hdGlvbiB3aXRoIG90aGVyIGZ1dHVy
ZSBUQ1AgZXh0ZW5zaW9ucy4gSSBhbHNvIGJlbGlldmUgdGhpcyBzZWN0aW9uIHJlcXVpcmVzIGNh
cmVmdWwgcmV2aWV3IGR1cmluZyBJRVRGIGxhc3QgY2FsbCBhcyBpdCBpcyBhYm91dCBhIGdlbmVy
YWwgZGVzaWduIHBhdHRlcm4uIEFzIGxvbmcgYXMgSSBhbSB0aGUgb25seSBwZXJzb24gY29uY2Vy
bmVkIGFib3V0IHRoaXMgc2VjdGlvbiBhbmQgaXRzIGltcGxpY2F0aW9ucywgbXkgcHJvcG9zYWwg
aXMgdGhhdCB0aGUgc2hlcGhlcmQgbm90ZXMgZG93biB0aGF0IG9uZSBpbmRpdmlkdWFsIGNvbnRy
aWJ1dG9yIGJlbGlldmVzIHRoYXQgZmFsbGJhY2sgc2hvdWxkIGJlIHRvIFJGQyAzMTY4IGFzIHN0
YW5kYXJkIGFuZCB0aGUgY29udHJpYnV0b3IgYWdyZWVkIHRvIG1vdmUgb24gbm9uZXRoZWxlc3Mu
DQoNCkJ1dCwgYXMgSSBzYWlkLCBJIGZsYWcgdGhpcyBzZWN0aW9uIG1haW5seSB0byBlbnN1cmUg
dGhhdCB0aGUgZm9yd2FyZCBjb21wYXRpYmlsaXR5IHJ1bGUgaXMgY2FyZWZ1bGx5IHJldmlld2Vk
IGJ5IGFsbCB3aG8gbWF5IGJlIGFmZmVjdGVkLg0KDQpNaWNoYWVsDQo=


From nobody Tue Nov 12 22:53:26 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 59E69120861 for ; Tue, 12 Nov 2019 22:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 4TyC1eYbnnUl for ; Tue, 12 Nov 2019 22:53:23 -0800 (PST)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FFE12085D for ; Tue, 12 Nov 2019 22:53:23 -0800 (PST)
Received: from eggert.org (unknown [62.248.255.8]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id E5FAB20033; Wed, 13 Nov 2019 08:53:18 +0200 (EET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Lars Eggert 
In-Reply-To: <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
Date: Wed, 13 Nov 2019 08:53:00 +0200
Cc: Neal Cardwell , "tcpm@ietf.org" , mallman@bbn.com
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com>  <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
To: Vidhi Goel 
X-MailScanner-ID: 66092611EEB.A44BA
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
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, 13 Nov 2019 06:53:25 -0000

Hi,

On 2019-11-12, at 23:44, Vidhi Goel =
 wrote:
> +Mark Allman

oh, is he at BBN now? Not mallman@icir.org?

> Is it worth investing time in writing another draft to document what =
Linux (and possibly other implementations) do for more accurate =
congestion window growth and for solving the burst send issue via =
pacing, TSQ etc.?

That is IMO the key question. *If* there is an alternative mechanism to =
ABC that solves (some of) the same problems, and potentially in a better =
way, or in a way that has a different implementation footprint, that may =
be worth documenting.

I'm not up to speed with the Linux code, but from what Neal writes, it =
seems that the Linux mechanism is tied in with or relying on a bunch of =
lower-level packet I/O functionality that is maybe pretty =
Linux-specific? In other words, can something like the Linux mechanism =
even be instantiated without (much of) this underpinning?

Lars=


From nobody Tue Nov 12 22:58:06 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 6E811120851; Tue, 12 Nov 2019 22:58:03 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 U7x2w9RYBgXZ; Tue, 12 Nov 2019 22:58:02 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6D41F1200CD; Tue, 12 Nov 2019 22:58:02 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAD6vNvx018472; Wed, 13 Nov 2019 06:57:55 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ix128mN6pQgO0gBjAzjayeXJyy3RyLUr/RIqocg+Ukw=; b=iLbjqN9W921J7OepKPKjgNHL2Q7VqUToXEhiYMl7uBCozQCzBgBUBuYrnvD7rjiuhuIY +ei0NrUGMcrEH8y3XefwH6AKJwswaqmFkqqMOLlawfiPbrMtaeyIUUUA0v0zHuR1fTm4 I2utaMQVWxg5hXK6hLTaqG5xaeMT0cO3Iw+5FPT0dJ4NH05pm6B6/EzzdqNpMQ7BB0xC 9j4rbZ2b+jAnYADJf6x4Ejbji0511tMjLuRTEuKSRjgRAA+iedrVV6n1FwSq22fEz+H+ +T60gyieQ2DlW/HlbeDWrkwazUx1LZOQt/hbjITN7zQDr/+zQZSjtdTJQwoYKgulSgAi Iw== 
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2w5p60tkuu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Nov 2019 06:57:55 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAD6kwO4022081; Wed, 13 Nov 2019 01:57:54 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 2w5snyrwa0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Nov 2019 01:57:53 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 Nov 2019 00:57:53 -0600
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1473.005; Wed, 13 Nov 2019 00:57:52 -0600
From: "Holland, Jake" 
To: Sebastian Moeller , Ingemar Johansson S 
CC: Ingemar Johansson S , "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" 
Thread-Topic: [tsvwg] L4S related activity in 3GPP
Thread-Index: AQHVlyEOqflbeAGZskqQkrD3bd7kSaeDnOaA//+x64CAAUN7AIAADA0AgAPxL4A=
Date: Wed, 13 Nov 2019 06:57:51 +0000
Message-ID: <95DD7C4B-0C48-4726-AD7A-D977D1D9C5CC@akamai.com>
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>  <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com>  <577095C3-EE27-40D6-9A8C-662DACEA1A5C@gmx.de>
In-Reply-To: <577095C3-EE27-40D6-9A8C-662DACEA1A5C@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.80.96]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-13_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=436 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911130060
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-13_01:2019-11-11,2019-11-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 clxscore=1015 phishscore=0 mlxlogscore=403 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911130062
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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, 13 Nov 2019 06:58:04 -0000

T24gMjAxOS0xMS0xMCwgMDI6NDYsICJTZWJhc3RpYW4gTW9lbGxlciIgPG1vZWxsZXIwQGdteC5k
ZT4gd3JvdGU6DQo+IFtTTV0gaGFzIGFueSBvbmUgYWN0dWFsbHkgdGVzdGVkIHBhY2VkIGNoaXJw
aW5nIChQQykgb3ZlciByZWFsLWxpZmUNCj4gYm9uZGVkIGxpbmtzPyBBcyBmYXIgYXMgSSBjYW4g
c2VlIFBDIHByZXR0eSBtdWNoIHJlbGllcyBvbiBhKSBsaXR0bGUNCj4gdG8gbm8gcmUtb3JkZXJp
bmcgb2YgcGFja2V0cyAod2VpcmQgZ2l2ZW4gdGhhdCBMNFMgYWxzbyB3YW50cyB0byBhbGxvdw0K
PiBsYXJnZXIgcmUtb3JkZXJpbmcgdG9sZXJhbmNlIGJ5IHJlY29tbWVuZGluZy9tYW5kYXRpbmcg
dGhlIHVzZSBvZiBSQUNLKQ0KPiBhbmQgYikgdGhhdCB0aGUgcGFja2V0IGRlbGl2ZXJ5IHRpbWUg
b2YgZWFjaCBwYWNrZXQgcmVmbGVjdHMgYSBjb21tb24NCj4gcGF0aCBjaGFyYWN0ZXJpc3RpYyAo
d2hpY2ggaXMgbGVzcyB0cnVlIGZvciBhIGJvbmRlZCBsaW5rKS4NCg0KSSdkIGNlcnRhaW5seSBs
b3ZlIHRvIHNlZSBwYWNlZCBjaGlycGluZyBmbGVzaGVkIG91dC4gIElmIHRoZXJlJ3MgYSByb2J1
c3QNCnZlcnNpb24sIGl0IHNlZW1zIGEgcHJvbWlzaW5nIHdheSB0byBhdm9pZCBvdmVyc2hvb3Rp
bmcgb24gc2xvdyBzdGFydCBmb3INCmp1c3QgYWJvdXQgZXZlcnlvbmUgKHNvIG1heWJlIHdlIGNv
dWxkIGFsbCBnZXQgcmlkIG9mIHRoYXQgbGF0ZW5jeSBzcGlrZQ0Kb24gc2NlbmFyaW8gNSksIGFu
ZCBJJ2QgdGhpbmsgaXQgY291bGQgaGF2ZSBhcHBsaWNhdGlvbnMgZXZlbiBvdXRzaWRlIG9mDQpz
bG93IHN0YXJ0IGFueXdoZXJlIHlvdSBoYXZlIGEgd2F5IHRvIGJhY2sgb2ZmIGJlZm9yZSBwdXNo
aW5nIHRvIG92ZXJmbG93DQooZS5nLiBCQlIsIG9yIHNvbWV0aGluZyB1c2luZyBTQ0UsIGFzIHdl
bGwgYXMgTDRTKS4NCg0KT2YgY291cnNlIGFzIHRoZSBwYXBlciBzYWlkLCBpdCdzIG5vdCByZWFk
eSB5ZXQsIGJ1dCBpdCBkb2VzIGFsc28gc2VlbQ0KcG90ZW50aWFsbHkgaGVscGZ1bCBmb3IgdGhl
IHVzZSBjYXNlIG9mIGhpZ2hseSB2YXJpYWJsZSBsaW5rIHRocm91Z2hwdXQuDQpUbyBtZSBpdCBz
ZWVtcyB3b3J0aCBrZWVwaW5nIGluIG1pbmQgYW5kIGV4YW1pbmluZyBmdXJ0aGVyLCB3aGV0aGVy
DQpvciBub3QgeW91IHRoaW5rIEw0UyB3aXRoIEVDVCgxKSB3aWxsIGVuZCB1cCBiZWluZyB2aWFi
bGUuDQoNCkJlc3QsDQpKYWtlDQoNCg0K


From nobody Wed Nov 13 00:04: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 C11FD120145; Wed, 13 Nov 2019 00:04:12 -0800 (PST)
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=unavailable 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 e45lpoddCnsz; Wed, 13 Nov 2019 00:04:11 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 660571200FE; Wed, 13 Nov 2019 00:04:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573632232; bh=W/TykBhGkbcN8Fs1d3I+m/QGO6EA3tlVUlSXi09TtqY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=AHUSKtyEUN0bHY7r9FkxU32l3aTZYazvTxnahj2Ianowu5xMOe2VSyN6HulzSj41f V4+mlcX8DIeDoJxSU/n4XLZKOjY4//CC9/MGiycog/ojr3R5PH/kQA0GAVJSviyV4U WPNFbxgZUXiNsKtw0bkElKh1Z4+74gSDBj+rUNhk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MaJ81-1iRFN70Ig1-00WAov; Wed, 13 Nov 2019 09:03:52 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller 
In-Reply-To: <95DD7C4B-0C48-4726-AD7A-D977D1D9C5CC@akamai.com>
Date: Wed, 13 Nov 2019 09:03:43 +0100
Cc: Ingemar Johansson S , Ingemar Johansson S , "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , "koen.de_schepper@nokia.com" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ED8E685-E284-4470-B808-114316E81D98@gmx.de>
References:  <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>  <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com>  <577095C3-EE27-40D6-9A8C-662DACEA1A5C@gmx.de> <95DD7C4B-0C48-4726-AD7A-D977D1D9C5CC@akamai.com>
To: "Holland, Jake" 
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:wm41HQ3nKNM7fPMK9LbHvs8L7e6BdqtXYZnNXSQoHPZLAz2cjid h5GzDZ3kytqM0KkxYFQ59RNAzXWZHY7KFbh9Ifd4oH69Ats9MvazmlaD8+MYqVJlxrRABPU m+IKJsbLF5MPrxZ0JG93AP0dfSpi2VJmZIHP7DSoWJgDYlsxeyTTXpI9T9fVwQhj9/0dXKj 24KzOxT4/O1nLgJdNRlOg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:P0iPPI0fGmw=:n4gi6MYyDY7YzEy+FWyzJS Dhw+UHUQS4VAZSm4erX/J2ZfjmpkrUDp7y5wZX+/6cKyPwSZn5emy4ZhOTJcWF1c4fo6u9v9C h37yBjIEEwUJKDMm5po43YGliZKdMiJEPaD4ek4dyMzLJPF3Z6lCLT+IAdW33MwznmHvIlI68 bXwTwsRwDRlm5GDZuA3iW2ID5BWe/Jx23vBOSyGfozV0CG6CKJi29g3PiZltKJh61LcwBPcUT EhGNUcw8+f12zrcB+tBdDOfktAa/WSMHwaV9wxhMlJXvy/It5NZ+1upGcfyrClSlDgF7yC/CI 8+z70gCRZWsePUEUhQvg3OALVf61A8O5sNxCwh+LV/gMWIjldCPJaxlKpF5RUp4a/gqMdIUGE ZlVEvqi1aV39u1BH+KozOJOZBf1fge13Za2WRe0aKjZju0FBWmS0K/PWW50XzMH4ngQlS28Ve OcuoraMWojvx0ysPg1RcyTU4t4BPyWNpv+GojGf29M0dTlaYVsJhNVSLMQ2eJU5R2Vt7d4LAK +aEgkS/+uwv2zSFyyDaEraE95JpDKJ4JOZPc8gXByt15RVcOurDvBccX092d8qfxXkGKHwx28 Qg+Zk7lKlT4HWapFz3xVSd+5dRZ6am5zvoLmn31rG0CTdZGT1B6G/oQXwuBClt/E4IjfQEj8e ygpX0olW7tXreZn0T1tKZ721mwZjejT+z1dkJisZ6jJScwUgPyiiX4ZToKk3BJjlPPMd3gXZC p8sszbAjQUWrW0JnFQtfyMRs9pRQiZhhUnItjwBSkbjA00+ikXK/UJl/H3Nxi3CHTST97zqrS 1iklvMGE/AIxpCeGSq06ifXLL32CyLXkbErZkXdSWisP5nJNIQEdbuRHJGLaFiG3IsUBajnaG DXOv7gWOGXqbm3O0OccDhO7iroCIXWcFqxD+ia3w5rhNfBa7rWYpACkuMJfa6ZTLTscT903Hu SEhMMMAN4AjA8TlUUrGX3Z1iAH7rucmxzk3TQHxO88PboiYJHlFauK41UOZtql0Lk2AUiypxr iWAY1LpuuuzBkBWRKScfxNZ7sv5A9E+BJdIIuFMZhdar6jj7oG4vfpaDZKlEKulEu5pVsXIeF nYhGTxkuWeWB3342kHfzwF3Wxjecpu5tXOOWfSDduU7TQDteQ4YRmjv3pXWhjwXYUNPj5M6qv Ga7nxItwqw4SBpfi7+TVJt+E0At7LPMG1wcRrPeoHsQyFjjPVfW7T4A48FMmCqUsL3tNdxbvK EAa915cfqVXGxoKFIe7c+3Tl82TDR3cM/JrKeXeo6WHoDBtlYGYTfWUOCHo0=
Archived-At: 
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
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, 13 Nov 2019 08:04:13 -0000

Hi Jake,

I guess my tone was more negative than it should have been, PC is a =
clever idea, and it would be great if it succeeds in the real world. =
More below in-line.


> On Nov 13, 2019, at 07:57, Holland, Jake  wrote:
>=20
> On 2019-11-10, 02:46, "Sebastian Moeller"  wrote:
>> [SM] has any one actually tested paced chirping (PC) over real-life
>> bonded links? As far as I can see PC pretty much relies on a) little
>> to no re-ordering of packets (weird given that L4S also wants to =
allow
>> larger re-ordering tolerance by recommending/mandating the use of =
RACK)
>> and b) that the packet delivery time of each packet reflects a common
>> path characteristic (which is less true for a bonded link).
>=20
> I'd certainly love to see paced chirping fleshed out.

	[SM] No objection. The promise of it is certainly interesting. =
What I would like to see first, before getting too excited is rigorous =
testing to demonstrate its robustness and functionality even under =
adverse conditions. Of the top of my head, here is a list of things that =
I would like to see tested:

1) robustness against bi-directional path saturation
2) robustness against asymmetric paths
3) robustness against bonded links (possibility of re-ordering and inter =
packet delay does not reflect a single patch characteristic) I believe =
paired-packet probes have similar issues.
4) effect of high prevalence of paced chirpers in the network (these are =
active probes, at what point do the probes of different flow start to =
interfere with each other and ist that problematic)
5) conceptually, if I understand correctly it actually measured return =
latency, while ideally it should measure one-way delays, what are the =
consequences of that mismatch.

Again, would great if this works reliably and robustly, but as far as I =
can see so far all we know is that it works under some conditions.


>  If there's a robust
> version,

	[SM] +1

> it seems a promising way to avoid overshooting on slow start for
> just about everyone (so maybe we could all get rid of that latency =
spike
> on scenario 5),

	[SM] In the new scenario 5? I guess there not re-defining CE =
would be the cleanest solution...

> and I'd think it could have applications even outside of
> slow start anywhere you have a way to back off before pushing to =
overflow
> (e.g. BBR, or something using SCE, as well as L4S).

	[SM] Yes, that is why getting it tested under adverse conditions =
seems like an important next step!

>=20
> Of course as the paper said, it's not ready yet, but it does also seem
> potentially helpful for the use case of highly variable link =
throughput.

	[SM] Excuse my ignorance, but in its proposed role as slow start =
replacement, it would only trigger rarely (on flow start-up and on =
certain time-out conditions, no)?

> To me it seems worth keeping in mind and examining further, whether
> or not you think L4S with ECT(1) will end up being viable.

	[SM] I apologize for lumping to many things together in the =
referenced email, it is just that the whole L4S set of concepts and =
drafts, IHO all could do with more thorough testing...

Best Regards
	Sebastian

>=20
> Best,
> Jake
>=20
>=20


From nobody Wed Nov 13 00:09: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 54A1A12010C for ; Wed, 13 Nov 2019 00:09:11 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 H4kAifZQWZnN for ; Wed, 13 Nov 2019 00:09:08 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 D0D3712001E for ; Wed, 13 Nov 2019 00:09:07 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id q70so929752wme.1 for ; Wed, 13 Nov 2019 00:09:07 -0800 (PST)
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; bh=K/0lYyrkTGHRBIK/pxxSWW4tAWSNduZ9tFKC+tE4oeg=; b=CDr46ZJABWEgcFx3fOv1i42TVtg6GiK+VfAyidPzlsabRlTK+WKCMlcrRUFQb9To3h utUfs5x7bxrULh9D6Apje80DHfFqJ3OPtCkEatlFt5dvvuBko1n7nNi6qYlU7kH55kBA yarNo//8g+T1NEHjNnDJey/hih6bUWN3FfEgahO5Wjn2gwhh4KVTebpTClO5uvXzGVw6 pK17uQF348NB6hFTC4+bOHqlZgpGoCZIvTQpf59Y1j/sNrC3x5HMaRmMK9ca3MYPem6o QIKCjYpXQgSKNuxw/htbFv6yRrAvu+FiYUdeelnqCvYBVBwDkCWbyBzg8exusGMQ70Da h/dA==
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; bh=K/0lYyrkTGHRBIK/pxxSWW4tAWSNduZ9tFKC+tE4oeg=; b=kttmfISlYs4YnY945enR2Tf9MT67NecGjVHhhTCiiTfTKi6t02EIXNf76d3jxkNSyt O4JMdkKJLapdgSRUSGN415jqB0jNyR1R9lOR3ApoWo41CgoQu1JdFZYy21X7JOOMx+RS kR97Btw/NlHbhj3ETA23yrafnx6YD6rrUfnQDYmsD3/vCexn5kz7o21M5gMvIO3mCoNa k2HV12Xtfg2q/dguADfeYeMHg6IQfFQb/RUhewnqv76GFNIYFLzPxJsB61yy2OVLea3c rxjSdRxyESE3sOy26fiWQg/Q9XcJxbJT4gTz/qBho54MFewm+almj8jjqZg1WYyE8sWY U0cA==
X-Gm-Message-State: APjAAAWdQFNcnl4YUgo2Ursm2aSUZ4GxATqVRjOosmWpwuFgDHh/4838 IWK9Yp0FqKgJ7dAl6txO9JeKPAH4wxGiEm/2pCM=
X-Google-Smtp-Source: APXvYqyFSZFKVnh7brdA42N9L2IHYPR9DBAw3WJCKl80xrpUAKwfmPooZkdJjB6EzJqmBCTsohU9KEcJQikyeU5o1hc=
X-Received: by 2002:a05:600c:21d9:: with SMTP id x25mr1624639wmj.50.1573632546250;  Wed, 13 Nov 2019 00:09:06 -0800 (PST)
MIME-Version: 1.0
References: <201911072222.xA7MMYXb017371@gndrsh.dnsmgr.net>  <8382D634-8FEC-4932-96ED-9C5FB71E128D@ericsson.com>
In-Reply-To: <8382D634-8FEC-4932-96ED-9C5FB71E128D@ericsson.com>
From: Yoshifumi Nishida 
Date: Wed, 13 Nov 2019 00:08:54 -0800
Message-ID: 
To: Mirja Kuehlewind 
Cc: Pete Heist , "tcpm@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ed25de059735e05f"
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 13 Nov 2019 08:09:13 -0000

--000000000000ed25de059735e05f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mirja,

Thanks for the response.

On Tue, Nov 12, 2019 at 8:30 AM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Peter, I don't think the AccECN draft should say anything about what
> happens to the ex-NS bit if it falls back to classic ECN because that's o=
ut
> of scope of the draft defining the AccECN mechanis. However, I agree that
> is would be available for another use.
>

Well, this might be just my personal opinion, but two drafts
(draft-ietf-tcpm-accurate-ecn and draft-grimes-tcpm-tcpsce-00) claim to
name ex-NS bit as AE and ESCE without any explanations for each other.
This looks confusing to me.

Yoshi, I believe you point A1 below was decided in the group already at
> adoption time as the bit was used from the beginning with all possible
> AccECN mechanisms. However, if and how it should be registered with IANA =
is
> a different question. To my memory there was support to registered even
> though it's experimental because NS was registered based on an experiment=
al
> RFC and having this registry saying something about this specific bit whi=
le
> not noting this experiment there seems confusing/against the idea of a
> registry. What we maybe could discuss is if we want to rename the bit in
> the registry (to AE) or rather just add a note about this experiment. Las=
t
> time there was support to give it a proper name which we followed as
> authors but of course it's the working group to decide here.
>

I see. I personally would like to select one before WGLC unless we see
solid reason that this is not necessary.

Adding a note about the experiment looks a relatively easier path to me
rather than allocating a bit for experimental doc. But, if we adopt SCE,
we'll need to update the description.
Or, creating a small PS doc to allocate a bit could be an idea as well.



> Regarding point A2, this was also discussed at length in the group. There
> are different way of failing. One is, as we saw for NS, that there will b=
e
> no deployment at all and we can simply reassign. Another it that is gets
> deploy but doesn't work as expected, however, in this case there are stil=
l
> ways to extend/alter AccECN by negotiation during the handshake. This is
> also discussed in the draft and the mayor reason for having the handshake
> negotiation instead of just using the bit (as some other proposal do). If
> that is not good enough, I'm afraid we won't be able to ever use any of t=
he
> reserved bits in the TCP handshake.
>

OK.


>
> Regarding your point B below I don't see any dependency FROM AccECN to an=
y
> of these proposals. Yes, multiple proposal reply on AccECN, which it grea=
t
> because it show that it is useful, but that only means that the proposals
> have a dependency TO AccECN and not the other way around. For me this is
> another reason to proceed with AccECN quickly.
>

OK. just for clarification.
For example,  in near future, some middleboxes may implement a marking
algorithm which depends on AccECN, while other middleboxes may implement a
marking algorithm which doesn't depend on AccECN.
These middleboxes happen to be on the same path, then the packet marking
results will be a mix of two algorithms as middleboxes cannot identify
which TCP flows use AccECN or not.
But, AccECN is just designed to report what it received whether they are
mixed results or not. Hence, you say that AccECN is independent from these
potential conflicts. Correct?

--
Yoshi



>
>
>
> =EF=BB=BFOn 08.11.19, 09:23, "tcpm on behalf of Pete Heist"  on behalf of pete@heistp.net> wrote:
>
>     Hi,
>
>     Regarding points A1 and B overall, would it be possible to add to the
> AccECN draft some language such that when it falls back to RFC 3168 ECN,
> the NS bit is still available for other experiments? That way the bit cou=
ld
> still be used by SCE, even if AccECN becomes a proposed standard.
>
>     > From: Yoshifumi Nishida 
>     > Date: Thu, 7 Nov 2019 11:04:38 -0800
>     >
>     > Hi,
>     > draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
> have been
>     > discussed for a while.
>     > tcpm chairs are now thinking that they are getting matured and
> becoming
>     > ready for WGLC .
>     > However, we also think there are several points to be clarified
> beforehand.
>     >
>     > In order to proceed the current situation, we would like to ask the
>     > community to give some feedback on the following points.
>     > We will highly appreciate your inputs.
>     >
>     > A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn
>     >  The draft requests the allocation for bit 7 in TCP header (ex NS
> bit)
>     > for this proposal.
>     >  However, the intended status of the draft is experimental, which
> may not
>     > be well aligned with the description in RFC2780.
>     >
>     > The chairs would like to check the following points.
>     >     A1: If we can have a consensus to allocate bit 7 for this
>     > experimental draft. Or, if there is any other ways to allow the
> allocation
>     > (e.g. using other documents)
>     >     A2: if we decide to allocate the bit, what we should do when th=
e
>     > experiment fails.
>     >
>     > B: Overlaps with some congestion experienced proposals
>     >  It seems that some congestion experienced proposals
>     > (draft-grimes-tcpm-tcpsce
>     > and draft-morton-tsvwg-sce) have similarities with these drafts.
>     >
>     >  The chairs would like to check the following points for this.
>     >    B1: The two proposals won't conflict each other. We can discuss
> and
>     > proceed these proposals separately without any potential risks.
>     >    B2: it seems that SCE and L4S may have some conflicts, but this
> will
>     > not affect the discussions for AccECN and ECN++.
>     >    B3: if we allocate the bit 7 for AccECN, it is still allowed for
> SCE
>     > proposals to use the bit or it will be prohibited.
>     >
>     >  BTW, just in case. please avoid initiating technical discussions
> and try
>     > to discuss how to proceed the drafts in this thread.
>     > --
>     > Yoshi on behalf of tcpm chairs
>
>     _______________________________________________
>     tcpm mailing list
>     tcpm@ietf.org
>     https://www.ietf.org/mailman/listinfo/tcpm
>
>
>

--000000000000ed25de059735e05f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Mirja,

Thanks for the res=
ponse.

On Tue, Nov 12, 2019 at 8:30 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrot=
e:
Peter, I don&=
#39;t think the AccECN draft should say anything about what happens to the =
ex-NS bit if it falls back to classic ECN because that's out of scope o=
f the draft defining the AccECN mechanis. However, I agree that is would be=
 available for another use.

Well, this =
might be just my personal opinion, but two drafts (draft-ietf-tcpm-accurate=
-ecn and=C2=A0draft-grimes-tcpm-tcpsce-00) claim to name ex-NS bit as AE an=
d ESCE without any explanations for each other.=C2=A0
This looks =
confusing to me.=C2=A0


Yoshi, I believe you point A1 below was decided in the group already at ado=
ption time as the bit was used from the beginning with all possible AccECN =
mechanisms. However, if and how it should be registered with IANA is a diff=
erent question. To my memory there was support to registered even though it=
's experimental because NS was registered based on an experimental RFC =
and having this registry saying something about this specific bit while not=
 noting this experiment there seems confusing/against the idea of a registr=
y. What we maybe could discuss is if we want to rename the bit in the regis=
try (to AE) or rather just add a note about this experiment. Last time ther=
e was support to give it a proper name which we followed as authors but of =
course it's the working group to decide here.

=

I see. I personally would like to select one before WGLC unless =
we see solid reason that this is not necessary.

Ad=
ding a note about the experiment looks a relatively easier path to me rathe=
r than allocating a bit for experimental doc. But, if we adopt SCE, we'=
ll need to update the description.
Or, creating a small PS doc to=
 allocate a bit could be an idea as well.

=C2=A0

Regarding point A2, this was also discussed at length in the group. There a=
re different way of failing. One is, as we saw for NS, that there will be n=
o deployment at all and we can simply reassign. Another it that is gets dep=
loy but doesn't work as expected, however, in this case there are still=
 ways to extend/alter AccECN by negotiation during the handshake. This is a=
lso discussed in the draft and the mayor reason for having the handshake ne=
gotiation instead of just using the bit (as some other proposal do). If tha=
t is not good enough, I'm afraid we won't be able to ever use any o=
f the reserved bits in the TCP handshake.

OK.=C2=A0
=C2=A0



Regarding your point B below I don't see any dependency FROM AccECN to =
any of these proposals. Yes, multiple proposal reply on AccECN, which it gr=
eat because it show that it is useful, but that only means that the proposa=
ls have a dependency TO AccECN and not the other way around. For me this is=
 another reason to proceed with AccECN quickly.

OK. just for clarification.
For example,=C2=A0 in n=
ear future, some middleboxes may implement a marking algorithm which depend=
s on AccECN, while other middleboxes may implement a marking algorithm whic=
h doesn't depend on AccECN.
These middleboxes happen to be on=
 the same path, then the packet marking results will be a mix of two algori=
thms as middleboxes cannot identify which TCP flows use AccECN or not.
But, AccECN is just designed to report what it received whether they =
are mixed results or not. Hence, you say that AccECN is independent from th=
ese potential conflicts. Correct?

--
Yoshi

=C2=A0







=EF=BB=BFOn 08.11.19, 09:23, "tcpm on behalf of Pete Heist" <<=
a href=3D"mailto:tcpm-bounces@ietf.org" target=3D"_blank">tcpm-bounces@ietf=
.org on behalf of =
pete@heistp.net> wrote:



=C2=A0 =C2=A0 Hi,



=C2=A0 =C2=A0 Regarding points A1 and B overall, would it be possible to ad=
d to the AccECN draft some language such that when it falls back to RFC 316=
8 ECN, the NS bit is still available for other experiments? That way the bi=
t could still be used by SCE, even if AccECN becomes a proposed standard.


=C2=A0 =C2=A0 > From: Yoshifumi Nishida <nsd.ietf@gmail.com>

=C2=A0 =C2=A0 > Date: Thu, 7 Nov 2019 11:04:38 -0800

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Hi,

=C2=A0 =C2=A0 > draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-general=
ized-ecn have been

=C2=A0 =C2=A0 > discussed for a while.

=C2=A0 =C2=A0 > tcpm chairs are now thinking that they are getting matur=
ed and becoming

=C2=A0 =C2=A0 > ready for WGLC .

=C2=A0 =C2=A0 > However, we also think there are several points to be cl=
arified beforehand.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > In order to proceed the current situation, we would like=
 to ask the

=C2=A0 =C2=A0 > community to give some feedback on the following points.=


=C2=A0 =C2=A0 > We will highly appreciate your inputs.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn

=C2=A0 =C2=A0 >=C2=A0 The draft requests the allocation for bit 7 in TCP=
 header (ex NS bit)

=C2=A0 =C2=A0 > for this proposal.

=C2=A0 =C2=A0 >=C2=A0 However, the intended status of the draft is exper=
imental, which may not

=C2=A0 =C2=A0 > be well aligned with the description in RFC2780.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > The chairs would like to check the following points.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A1: If we can have a consensus to all=
ocate bit 7 for this

=C2=A0 =C2=A0 > experimental draft. Or, if there is any other ways to al=
low the allocation

=C2=A0 =C2=A0 > (e.g. using other documents)

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A2: if we decide to allocate the bit,=
 what we should do when the

=C2=A0 =C2=A0 > experiment fails.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > B: Overlaps with some congestion experienced proposals
=C2=A0 =C2=A0 >=C2=A0 It seems that some congestion experienced proposal=
s

=C2=A0 =C2=A0 > (draft-grimes-tcpm-tcpsce

=C2=A0 =C2=A0 > and draft-morton-tsvwg-sce) have similarities with these=
 drafts.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 >=C2=A0 The chairs would like to check the following point=
s for this.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 B1: The two proposals won't conflict ea=
ch other. We can discuss and

=C2=A0 =C2=A0 > proceed these proposals separately without any potential=
 risks.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 B2: it seems that SCE and L4S may have some=
 conflicts, but this will

=C2=A0 =C2=A0 > not affect the discussions for AccECN and ECN++.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 B3: if we allocate the bit 7 for AccECN, it=
 is still allowed for SCE

=C2=A0 =C2=A0 > proposals to use the bit or it will be prohibited.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 >=C2=A0 BTW, just in case. please avoid initiating technic=
al discussions and try

=C2=A0 =C2=A0 > to discuss how to proceed the drafts in this thread.

=C2=A0 =C2=A0 > --

=C2=A0 =C2=A0 > Yoshi on behalf of tcpm chairs



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 tcpm mailing list

=C2=A0 =C2=A0 tcpm@ietf.=
org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tcpm








--000000000000ed25de059735e05f--


From nobody Wed Nov 13 00:11: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 48F40120137 for ; Wed, 13 Nov 2019 00:11:07 -0800 (PST)
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 (2048-bit key) header.d=apple.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 cX2tGxwCoHWz for ; Wed, 13 Nov 2019 00:11:06 -0800 (PST)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 EFDA612001E for ; Wed, 13 Nov 2019 00:11:05 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAD86Y4H036348; Wed, 13 Nov 2019 00:10:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=oqmIQR/GL7tWqCXEleW5Vl1Wbjl598mZKjM2KgjHN78=; b=uwweAYJ8T52FGT52AeR22rITa9S8ceTfq2dciz9BkVTIVReMtfTAzbMLiaEsXG6gDTxv FSW/fIsoPPwsbVMADtkBiXJDungMV6/EHgD/+nbmSzNP/OeEtvNlE1Xd9WNWrhZhSUrD NWxZRV+ytshhxnNPuBhJmKeV+2IXirUfJVtNrRcl9EBB5/o1QZ930ng5DBbYDrmocyjO 4TBQoUdMFdsH9IdR1lNgCuvoRfgBwXm8hpZ+43x6ZiES1kx094Si8tG2S+ZZ0S+T7bCQ t6ufE3T2ZHXqtxupfIhhxhjPZAhUN7YfOD1IxflAk8Nk43z5Op2dH8XrTSxl2vEVLum1 Kw== 
Received: from ma-mailsvcp-mta-lapp04.corp.apple.com (ma-mailsvcp-mta-lapp04.corp.apple.com [10.226.18.136]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2w5w943ep4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Nov 2019 00:10:59 -0800
Received: from ma-mailsvcp-mmp-lapp03.apple.com (ma-mailsvcp-mmp-lapp03.apple.com [17.32.222.16]) by ma-mailsvcp-mta-lapp04.corp.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul  4 2019)) with ESMTPS id <0Q0W00GVOEQACV10@ma-mailsvcp-mta-lapp04.corp.apple.com>; Wed, 13 Nov 2019 00:10:58 -0800 (PST)
Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp03.apple.com by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul  4 2019)) id <0Q0W00500D4T2R00@ma-mailsvcp-mmp-lapp03.apple.com>; Wed, 13 Nov 2019 00:10:58 -0800 (PST)
X-Va-A: 
X-Va-T-CD: 891a14b3251185fcf41ff438c430a9b6
X-Va-E-CD: 8ad83cf34a8c3732cb73dea81270d36d
X-Va-R-CD: 2eec4d4b333905bf2498bde820845c7b
X-Va-CD: 0
X-Va-ID: 7a49d862-4eb5-45e8-96cb-91aff11503ab
X-V-A: 
X-V-T-CD: 891a14b3251185fcf41ff438c430a9b6
X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d
X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b
X-V-CD: 0
X-V-ID: 57ec1acf-9b7e-47f3-b1a7-331959b9fa6c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-13_01:,, signatures=0
Received: from [17.234.198.177] (unknown [17.234.198.177]) by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul  4 2019)) with ESMTPSA id <0Q0W00A6XEQ96430@ma-mailsvcp-mmp-lapp03.apple.com>; Wed, 13 Nov 2019 00:10:58 -0800 (PST)
Sender: vidhi_goel@apple.com
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
From: Vidhi Goel 
MIME-version: 1.0 (1.0)
Date: Wed, 13 Nov 2019 00:10:53 -0800
Message-id: 
References: 
Cc: Neal Cardwell , tcpm@ietf.org
In-reply-to: 
To: Lars Eggert , mallman@icir.org
X-Mailer: iPhone Mail (18A160)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-13_01:, , signatures=0
Archived-At: 
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
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, 13 Nov 2019 08:11:07 -0000

Adding Mark again as the bbn email doesn=E2=80=99t exist.

Vidhi

> On Nov 12, 2019, at 10:53 PM, Lars Eggert  wrote:
>=20
> =EF=BB=BFHi,
>=20
>> On 2019-11-12, at 23:44, Vidhi Goel  wrote:
>> +Mark Allman
>=20
> oh, is he at BBN now? Not mallman@icir.org?
>=20
>> Is it worth investing time in writing another draft to document what Linu=
x (and possibly other implementations) do for more accurate congestion windo=
w growth and for solving the burst send issue via pacing, TSQ etc.?
>=20
> That is IMO the key question. *If* there is an alternative mechanism to AB=
C that solves (some of) the same problems, and potentially in a better way, o=
r in a way that has a different implementation footprint, that may be worth d=
ocumenting.
>=20
> I'm not up to speed with the Linux code, but from what Neal writes, it see=
ms that the Linux mechanism is tied in with or relying on a bunch of lower-l=
evel packet I/O functionality that is maybe pretty Linux-specific? In other w=
ords, can something like the Linux mechanism even be instantiated without (m=
uch of) this underpinning?
>=20
> Lars


From nobody Wed Nov 13 01:48: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 2800F1201AA; Wed, 13 Nov 2019 01:48:06 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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=bobbriscoe.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 kDP3fB6Ya3Pb; Wed, 13 Nov 2019 01:48:03 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1F3AF1201B7; Wed, 13 Nov 2019 01:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=lIlJpLheegegmst6gbOp55Aaeom/4y2PqvCgH6flgHk=; b=1iCeJzsNjaB1CRQnf9EtUT0K3X q/yIMurKy7ip9W2/nlpVSKjRsPjgImdV/ALy5cjVC9P3+A8KpuPaKd9fvSexyLJ9uheYhGYxN/wjI ylgbrHJUBi7nJ/wxcLHOuVcHNljO+iP12ywypsKTyXufjNcwqxn+LS8Ie7hggXKuIiYF2NMfwuFgB R04gzIjKVSiciu8kqT9tUac4kKfd2ek3nltA+EHtFqbnC7Kw+gOPWZvj7L+KvYFSxbPCckS3OaBI6 Q81yx/rIO9K+Cc+R0cYyN1+BIOgTFhGKw96DeZGritt2JQ1b6b4kafzguWlF0bRNxNvaYgZv7Uxyb DUFbIbKw==;
Received: from [31.185.128.31] (port=49820 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUpFo-0007lh-OD; Wed, 13 Nov 2019 09:48:01 +0000
To: Sebastian Moeller 
Cc: "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net> <985D623F-8B16-4DB0-A675-5A726EF6753F@gmx.de> <73220cb8-2e36-cf87-276a-f67c425a7752@bobbriscoe.net> <6AE74B84-95FB-46E0-A6A1-C424CEBEEB96@gmx.de>
From: Bob Briscoe 
Message-ID: <438350af-e5ff-88a4-21d8-2cc30d1030bb@bobbriscoe.net>
Date: Wed, 13 Nov 2019 09:47:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6AE74B84-95FB-46E0-A6A1-C424CEBEEB96@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Wed, 13 Nov 2019 09:48:06 -0000

Sebastian,

I am very much arguing in good faith about the term 'Classic', because I 
care about the comprehensibility and correctness of RFCs. So I am always 
willing to change text (or technology) in the face of successfully 
argued reasoned constructive criticism.

In order to keep each thread to its topic, I'll respond on that thread 
to the points about flow rates (unless others have already made the 
points I would make). {Note 1}

It is not pretentious for an experiment to state what it aims to achieve 
in its specification. That is how everyone writes and reads experimental 
specs. I can certainly say that L4S is ambitious. But that is a feature, 
not a bug, and it was well-understood when the work was adopted onto the 
experimental track. It will only have been pretentious if it eventually 
fails to deliver on its promises. Nonetheless, when problems are found, 
there should be a presumption that the proponents might be able to fix 
them, and space should be allowed for that process.

Regards


Bob

{Note 1}: These mailing lists are for co-ordinating a large amount of WG 
work. Please yourself try not to merely repeat the arguments of others 
when posting (unless the chairs have asked for a consensus call). Rough 
consensus requires every substantive objection to be addressed. So 
're-tweeting' just leaves everyone less time for technical progress.


On 11/11/2019 16:30, Sebastian Moeller wrote:
> Hi Bob,
>
> to be quite honest, the definitions you seem to insist upon are annoying and your rationale to explain your choices do not really convince me as given in good-faith.
> To repeat once more before I move on to more substantial issues:
> 	You use classic in a sense of "The stuff that has stood the test of time up to publication of this RFC", and I believe it is very pretentious to assume that "this RFC" is going to replace the status quo especially given that the drafts seem to be in the experimental track.
>
> But my bigger problem is not how you name non-L4S traffic, but what L4S does to non-L4S traffic,
> According to recently the measured and posted data L4S/dualQ/ AQMTCP Prague simply does not work as advertised.
>
> Not sure about the consensus opinion here, but the reported unfairness at low RTTs does indicate that at least the tested dualQ aqm implementation does not actually manage to make "Scalable and Classic flows competing under similar conditions run at roughly the same rate."
>
> Neither ~10:1 @~0ms RTT (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png) nor 3:1 @ 10ms RTT (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-10ms_var.png) qualify as "roughly the same rate" in my opinion. Oliver argued that this might be to be expected behavior due to the different RTTS under load for both queues, but he also admitted that he posed the same question, indicating that even members of the L4S development team consider traffic on the same path as "under similar conditions".
>
> 	This imbalance could be caused by (hopefully fixable) inefficiencies/bugs in the dualQ and/or TCP Prague implementations, or it could be part of L4S design; in which case I argue that this needs to be spelled out in excruciating detail in the draft.
> 	I find it a bit hard to believe that someone as verbose as you could use the term "run at roughly the same rate" to mean "Scalable traffic does not completely starve non-scalable traffic".
> 	The fact that this bias seems to diminish with increasing RTTs could be construed that at typical internet RTTs of ~100ms this effect does not matter much anymore, but that interpretation ignores that a considerable fraction of traffic is delivered from close-by data centers.
>
> Best Regards
> 	Sebastian
>
>
>
>> On Nov 11, 2019, at 16:22, Bob Briscoe  wrote:
>>
>> Sebastien,
>>
>> Chambers (British English)
>>
>>
>> classic adj 1 made of or belonging to the highest quality; established as the best. 2 entirely typical. 3 simple, neat and elegant, especially in a traditional style. noun 1 an established work of literature. 2 an outstanding example of its type. 3 something, eg an item of clothing, which will always last, irrespective of fashions and fads • the little black dress, a classic of the 50s. 4 (Classic) a celebrated annual sporting event, especially a horse race. See also the Classics. classically adverb 1 in a classic or classical way. 2 so as to be classical.
>> ETYMOLOGY: 17c: from Latin classicus relating to classes, especially the best.
>>
>> Merriam Webster (US English)
>>
>>
>> clas·​sic | \ ˈkla-sik
>> 1a : serving as a standard of excellence : of recognized value classic literary works a classic case study on hysteria
>> b : traditional, enduring classic designs
>> c : characterized by simple tailored lines in fashion year after year a classic suit
>> 2 : of or relating to the ancient Greeks and Romans or their culture : classical
>> 3a : historically memorable a classic battle
>> b : noted because of special literary or historical associations Paris is the classic refuge of expatriates
>> 4a : authentic, authoritative a classic study of eyewitness accounts
>> b : typical a classic example of chicanery a classic error
>>
>> Responses inline...
>>
>>
>> On 06/11/2019 23:04, Sebastian Moeller wrote:
>>> Dear Bob,
>>>
>>>
>>>> On Nov 6, 2019, at 19:12, Bob Briscoe 
>>>>   wrote:
>>>>
>>>> Sebastien,
>>>>
>>>> On 06/11/2019 07:18, Sebastian Moeller wrote:
>>>>
>>>>> Hi Bob,
>>>>>
>>>>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe
>>>>>
>>>>> 
>>>>>
>>>>>   wrote:
>>>>>
>>>>>
>>>>>> Michael, Rod,
>>>>>>
>>>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative
>>>>>> connotation than classic.
>>>>>>
>>>>>>
>>>>>          [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
>>>>>
>>>> Which is a good starting point, because that's what is intended.
>>>>
>>> 	[SM] I know that this is what you intend, but it is the test of time that makes classics classics, no amount of wishful thinking of the new-kid-on-the-block will relegate the reigning champion into classic mode, your solution really has to a) be better, and more importantly b) supersede that champion in the first place.
>> [BB] Not at all. Because classic has no hint of inferior. Quite the opposite according to the dictionaries.
>>
>> This is an excellent demonstration of how any term, even a good positive one, attracts a negative connotation as soon as it is used to mean "the things that are claimed to be improved on". This says to me that the quest for a better word than classic will be fruitless.
>>
>> Just like how kids quickly started to use the word 'special' as a term of abuse soon after the phrase "children with special needs" was introduced by well-meaning people.
>>
>>>
>>>
>>>> Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.:
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2
>>> "Classic service:  The 'Classic' service is intended for all the
>>>        behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
>>>        Compound, SCTP, etc)."
>>>
>>> Reading this implies that TCP Reno is not in the classic set, as you define that set as those co-existing with Reno and that is does not include Reno. But really =you can define what ever you want, but to have others accept your definition it better be useful.
>>>
>> [BB] Good point. I'll certainly fix that along with the problems that Rod pointed out.
>>
>>
>>>>>> For example, if you did define the name "non-iPhone" to mean phones
>>>>>> such
>>>>>> as Android, Windows, etc, then you would expect the phrase "non-iPhone
>>>>>> knock-off products" to mean "fake Android and Windows phones". However
>>>>>> the constituent elements "non" and "iPhone" already have a meaning of
>>>>>> their own, so in the context of this phrase, it means "fake iPhones",
>>>>>> which is the opposite of what you wanted.
>>>>>>
>>>>>>
>>>>>          [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.
>>>>>
>>>> [BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective).
>>>>
>>> 	[SM] Your are debating me to score points here, are you?
>> [BB] Not at all. We need a context-independent meaning. I am raising a practical problem with choosing a name that contains an element ("non-") with a natural meaning that will change the presumed meaning of "non-L4S" dependent on context.
>>
>>> You sort all flows into two categories, those that show L4S-style response to ECN signals and those that do not. The first group is reasonably homogenous, the second is not. So calling the second set non-L4S-style seems totally reasonably to me, unless you find another PROPERTY that defines that set, and no "classic" is not a property.
>> [BB] Non-L4S would be reasonable, were it not for its context-dependence problem. On what basis can you say that classic is not a property, when it is (both as defined for the L4S drafts, and as a well-understood adjective)?
>>
>>
>>> This is getting as ridiculous as your 17 year old car example....
>>>
>>>
>>>
>>>> I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1.
>>>> Then in this context, "Non-L4S" naturally means A - L1.
>>>>
>>>> However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1.
>>>>
>>> 	[SM] Well, for me L4S traffic is traffic that show a "linear" response to CE markings instead of a "multiplicative" (we can argue whether that is the correct definition, but it sure beats the what ever I feel is L4S definition you seem to propose)
>> [BB] Are you really meaning to say that I don't know the theoretical grounding of my own research as well as you do?
>>
>> BTW, Reno, Cubic and L4S responses to congestion are all multiplicative.
>>
>>>   and in that sense the set theoretical observations boil down to your first formulation. The fact that the L4S draft allows for your second formulation is a defect in that draft. The other stuff is not L4S but rather LoW-Latency traffic (which might be qualified to share L4S low latency queue with true L4S traffic).
>>>
>>>> So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context.
>>>>
>>> 	[SM] If you insist on overloading definitions, be my guest to keep the pieces once things break.
>> [BB] The current draft does not overload any definition of 'non-L4S'. It uses its natural meaning of "traffic that is not L4S" in the reduced context of the low latency queue. That's why I picked it as an example of a context-dependent word that would not be useful as a context-independent name.
>>
>>
>>>
>>>
>>>> It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean.
>>>>
>>> 	[SM] I apologize I was not thinking about "in Wonderland" but about Through the Looking Glass (https://sabian.org/looking_glass6.php
>>> ) :
>>> "'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'"
>>> L4S has exactly zero natural meaning, so please stop pretending it does.
>>>
>> [BB] When expanded it completely describes what it means: "Low Latency Low Loss Scalable throughput".
>>
>>
>>
>> Bob
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoe
>> http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Wed Nov 13 02:00:16 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 912EB120088; Wed, 13 Nov 2019 02:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 UnnztjaqXzjW; Wed, 13 Nov 2019 02:00:07 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 E4484120052; Wed, 13 Nov 2019 02:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=Ooa88qMG9f4LdQpLXBS+2LxjB4VHeqfyHHfDXmR5WXI=; b=0QaNqAR2nIsau0H0cqFGsHj8w tdF4RnOu4esms8pibn1iXgrobMOvw1xWa6+HvK1NLiVXhG6Qdl1lUyyaNPSLb6LSTPh5DdTEdnh8s HJx0+C94LJpI7G1pMEmCmHT9BCfMVjWRb9h7MRBn/GcN3gRxi1f7Hpv8E+35N1zLRZBUcJtsBGhMm Cl5fYRpORABuLCCv0hXmL2nGhBA8qSiCiVrxMrF6947aQT2IgaWG/EUIOvpDHKETN6b5aF47NJrnA 8Lb8IrOWY+tu7gMjBqUoDFAaurDBTFL/aM57EumYio1tT9uDz4g/xWob/SJFMxs9vDHw9k4iVHjW2 mV/dpMJHg==;
Received: from [31.185.128.31] (port=49852 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUpRV-0000yA-1n; Wed, 13 Nov 2019 10:00:05 +0000
To: "Scharf, Michael" , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tsvwg@ietf.org" , "tcpm@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de> <4f5dc8cb-0c20-c38e-ac80-0b6b111c93ee@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4FB9BA@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Bob Briscoe 
Message-ID: <805428c6-9852-ad02-8d31-c9e9199cb46e@bobbriscoe.net>
Date: Wed, 13 Nov 2019 10:00:04 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4FB9BA@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------2C3E5127504B1214A86383DC"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
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: Wed, 13 Nov 2019 10:00:10 -0000

This is a multi-part message in MIME format.
--------------2C3E5127504B1214A86383DC
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Michael,

I see the problem. Nearly all the occurrences of 'Classic TCP' are in 
the appendix that was written v early on, when the focus was only TCP. 
That text was not written by me, and I haven't got round to editing it 
for consistency. However, there are 4 occurrences of "'Classic' TCP" in 
the abstract and intro, which I will also fix.

Can you say which "David's proposal" you mean please?


Bob

On 11/11/2019 23:10, Scharf, Michael wrote:
>
> OK, so we seem to make some progress at least regarding the term 
> classic TCP. As mentioned before, I personally would find the term 
> Classic QUIC very confusing and you cannot avoid that if you talk 
> about Classic TCP, IMHO. So, it seems better to avoid that 
> terminology for all transport protocols. For the record, in 
> draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms classic 
> and TCP back-to-back is used 11 times as far as I can see.
>
> Regarding congestion control, Id like to emphasize that Davids 
> proposal would also work well for me, i.e., characterizing the 
> congestion control by functional properties. This avoids all issues 
> regarding whether something will supersede something else (including 
> the issue that EXP is just an experiment that wont update or replace 
> any PS document).
>
> Michael
>
> *From:*Bob Briscoe 
> *Sent:* Monday, November 11, 2019 4:31 PM
> *To:* Scharf, Michael ; Wesley Eddy 
> ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
> *Cc:* tsvwg@ietf.org; tcpm@ietf.org
> *Subject:* Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael,
>
> On 07/11/2019 08:11, Scharf, Michael wrote:
>
>      and just to show that _/my/_ concern would be trivial to address
>     by small editorial changes:
>
>     For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording It
>     gives an incremental migration path so that normal TCP traffic
>     classified in the Classic service of L4S will be no worse off
>     would already work for me. It just takes a small editorial change
>     to make me happy. This cant be so hard.
>
>     Personally, I wonder if classic is indeed the best name for a
>     service class (and, e.g., normal sounds better to me), but in
>     the context of a service class, classic could actually work for
>     me, if TSVWG really wants that name with strong consensus. I dont
>     care how about names for DiffSe^D^D^D^D^D^D traffic classifiers,
>     traffic policers/shapers, AQM schemes, or whatever else is done in
>     the fast path of a router to implement low latency service.
>
>     I only object to specific terminology such as Classic TCP or
>     Classic congestion control because I dont think that classic
>     is a proper characterization for TCPM standards or TCP/IP stack
>     behavior not aligned with whatever L4S believes the bright future
>     shall be.
>
> I thought I had already agreed to remove 'TCP' from all instances of 
> 'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' 
> in the first place. Because it's the congestion controls that are 
> relevant in L4S drafts, not the protocols.
>
>
>
> Bob
>
>     Whether such small rewording address fully the concerns from
>     others may be a different question.
>
>     Michael
>
>     *From:*Wesley Eddy  
>     *Sent:* Wednesday, November 6, 2019 8:54 PM
>     *To:* Scharf, Michael 
>     ; Bob Briscoe
>      ; Rodney W.
>     Grimes <4bone@gndrsh.dnsmgr.net> 
>     *Cc:* tsvwg@ietf.org ; tcpm@ietf.org
>     
>     *Subject:* Re: [tcpm] [tsvwg] L4S status tracking
>
>     On 11/6/2019 1:57 PM, Scharf, Michael wrote:
>
>         Bob,
>
>         From draft-ietf-tsvwg-ecn-l4s-id-08: It gives an incremental
>         migration path so that existing 'Classic' TCP traffic will be
>         no worse off
>
>         You are proposing an experiment. Not more than that. I will be
>         fine with the term Classic for TCP and TCPM-specified
>         congestion control when more than 50% of Internet traffic uses
>         that new technology.
>
>         Until this happens, I insist that the word Classic must be
>         removed in all context of TCP and congestion control (as far
>         as it is owned by TCPM), including the reference above. BTW,
>         normal as suggested would also work for me. So, you have
>         plenty of options for other terms.
>
>     If Dave+Michael's suggestion of replacing "classic" with "normal"
>     is agreable to others, this seems like a good way forward to me.
>     It should be easy enough to explain in other SDOs that classic and
>     normal mean the same thing, if this is a real issue.
>
>     (FWIW, I've never had a problem myself with "classic", nor read
>     any negative connotations to it. However, for the sake of working
>     group progress, I think we just need to pick something that seems
>     the least terrible and agree to move on.)
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------2C3E5127504B1214A86383DC
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    I see the problem. Nearly all the occurrences of 'Classic TCP' are
    in the appendix that was written v early on, when the focus was only
    TCP. That text was not written by me, and I haven't got round to
    editing it for consistency. However, there are 4 occurrences of
    "'Classic' TCP" in the abstract and intro, which I will also fix.

    

    Can you say which "David's proposal" you mean please?

    

    

    Bob

    

    
On 11/11/2019 23:10, Scharf, Michael
      wrote:

    

    

      
      
      
      

        
OK, so we seem to make some progress at least
            regarding the term classic TCP. As mentioned before, I
            personally would find the term Classic QUIC very confusing
            and you cannot avoid that if you talk about Classic TCP,
            IMHO. So, it seems better to avoid that terminology for all
            transport protocols. For the record, in
            draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms
            classic and TCP back-to-back is used 11 times as far as
            I can see.

        

        
Regarding congestion control, Id like to
            emphasize that Davids proposal would also work well for me,
            i.e., characterizing the congestion control by functional
            properties. This avoids all issues regarding whether
            something will supersede something else (including the issue
            that EXP is just an experiment that wont update or replace
            any PS document).

        

        
Michael

        

        

          

            

              
From: Bob Briscoe
                  <ietf@bobbriscoe.net>
                  

                  Sent: Monday, November 11, 2019 4:31 PM

                  To: Scharf, Michael
                  <Michael.Scharf@hs-esslingen.de>; Wesley Eddy
                  <wes@mti-systems.com>; Rodney W. Grimes
                  <4bone@gndrsh.dnsmgr.net>

                  Cc: tsvwg@ietf.org; tcpm@ietf.org

                  Subject: Re: [tcpm] [tsvwg] L4S status tracking

            

          

          

          
Michael,

          

            
On 07/11/2019 08:11, Scharf, Michael
              wrote:

          

          

            
 and just to show that _my_ concern
                would be trivial to address by small editorial changes:

            

            
For the abstract of
                draft-ietf-tsvwg-ecn-l4s-id, the wording It gives an
                incremental migration path so that normal TCP traffic
                classified in the Classic service of L4S will be no
                worse off would already work for me. It just takes a
                small editorial change to make me happy. This cant be
                so hard.

            

            
Personally, I wonder if classic is indeed
                the best name for a service class (and, e.g., normal
                sounds better to me), but in the context of a service
                class, classic could actually work for me, if TSVWG
                really wants that name with strong consensus. I dont
                care how about names for DiffSe^D^D^D^D^D^D traffic
                classifiers, traffic policers/shapers, AQM schemes, or
                whatever else is done in the fast path of a router to
                implement low latency service.

            

            
I only object to specific terminology such
                as Classic TCP or Classic congestion control because
                I dont think that classic is a proper
                characterization for TCPM standards or TCP/IP stack
                behavior not aligned with whatever L4S believes the
                bright future shall be.

          

          
I thought I had already agreed to
              remove 'TCP' from all instances of 'Classic TCP traffic'
              etc, and that I hadn't intended to include 'TCP' in the
              first place. Because it's the congestion controls that are
              relevant in L4S drafts, not the protocols.

              

              

              

              Bob

              

              

          

            

            
Whether such small rewording address fully
                the concerns from others may be a different question.

            

            
Michael

            

            

            

            

              

                

                  
From: Wesley Eddy
                      <wes@mti-systems.com>
                      

                      Sent: Wednesday, November 6, 2019 8:54 PM

                      To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>;
                      Bob Briscoe
                      <ietf@bobbriscoe.net>;
                      Rodney W. Grimes 
                        <4bone@gndrsh.dnsmgr.net>

                      Cc: tsvwg@ietf.org; 
                        tcpm@ietf.org

                      Subject: Re: [tcpm] [tsvwg] L4S status
                      tracking

                

              

              

              

                
On 11/6/2019 1:57 PM, Scharf,
                  Michael wrote:

              

              

                
Bob,

                

                
From draft-ietf-tsvwg-ecn-l4s-id-08:
                    It gives an incremental migration path so that
                    existing 'Classic' TCP traffic will be no worse off

                

                
You are proposing an experiment. Not
                    more than that. I will be fine with the term
                    Classic for TCP and TCPM-specified congestion
                    control when more than 50% of Internet traffic uses
                    that new technology.

                

                
Until this happens, I insist that the
                    word Classic must be removed in all context of TCP
                    and congestion control (as far as it is owned by
                    TCPM), including the reference above. BTW, normal
                    as suggested would also work for me. So, you have
                    plenty of options for other terms.

                

              

              

              
If Dave+Michael's suggestion of replacing "classic"
                with "normal" is agreable to others, this seems like a
                good way forward to me. It should be easy enough to
                explain in other SDOs that classic and normal mean the
                same thing, if this is a real issue.

              
(FWIW, I've never had a problem myself with "classic",
                nor read any negative connotations to it. However, for
                the sake of working group progress, I think we just need
                to pick something that seems the least terrible and
                agree to move on.)

              

            

          

          


              

              

          
-- 

          
________________________________________________________________

          
Bob Briscoe http://bobbriscoe.net/

        

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------2C3E5127504B1214A86383DC--


From nobody Wed Nov 13 03:12: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 D564312003F; Wed, 13 Nov 2019 03:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level: 
X-Spam-Status: No, score=-1.986 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, T_KAM_HTML_FONT_INVALID=0.01, 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 gwfd5gWGwWoG; Wed, 13 Nov 2019 03:12:28 -0800 (PST)
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 EEE721200CD; Wed, 13 Nov 2019 03:12:27 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3E9B325A1A; Wed, 13 Nov 2019 12:12:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573643546; bh=Zh6MkLAht88I6HUx3eGG3BhtUfS6edvTLl2qeAyrQME=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=htCjtOv3R8B7FRbC4TIwh5wJcb3B3VUkc2X95EK7CsjYJOr45BFcS5BfKzMI2Wuhd 6GJzKPxUl/MzgPf8TFZ/+gjvV4ISdIBmbkgeoDrCSUuydqdoptaU2kN1vzpFjw88U5 xB1VZAvV37yUETYehT/jvV1fGJoApvBAvbWBQexQ=
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 D-TvD4CEqMEk; Wed, 13 Nov 2019 12:12:22 +0100 (CET)
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; Wed, 13 Nov 2019 12:12:22 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 12:12:22 +0100
From: "Scharf, Michael" 
To: Bob Briscoe , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: "tsvwg@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] [tsvwg] L4S status tracking
Thread-Index: AQHVUALBEtXgqT1yKUqbs6+qKMgfv6cI1m+NgHLuuYCAACE53v//8bUAgAASJQ6AAdWZAIAAhk2sgACrVICAABElwIAABJqAgADeR5CABrOxgIAAjl+QgAI56QCAACM50A==
Date: Wed, 13 Nov 2019 11:12:21 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D500D21@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de> <4f5dc8cb-0c20-c38e-ac80-0b6b111c93ee@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4FB9BA@rznt8114.rznt.rzdir.fht-esslingen.de> <805428c6-9852-ad02-8d31-c9e9199cb46e@bobbriscoe.net>
In-Reply-To: <805428c6-9852-ad02-8d31-c9e9199cb46e@bobbriscoe.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D500D21rznt8114rzntrzd_"
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: Wed, 13 Nov 2019 11:12:32 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D500D21rznt8114rzntrzd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I was referring to this statement from David Black:


For congestion control in particular, I've found myself referring to 1/p an=
d 1/sqrt(p) congestion response behaviors for technical clarity/precision i=
n discussion, but those terms don't exactly roll off the tip of the tongue =
... and assume that the reader is familiar enough with TCP throughput equat=
ions to know what the variable p stands for.


Instead of using equations, one could also define two acronyms to make it m=
ore handy. I am pretty open to different variants.

To me, a key advantage of this approach is that it would be a technically n=
eutral (mathematical) description of behavior that should not be controvers=
ial. At least to me, this would work well.

Michael



From: Bob Briscoe 
Sent: Wednesday, November 13, 2019 11:00 AM
To: Scharf, Michael ; Wesley Eddy ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,

I see the problem. Nearly all the occurrences of 'Classic TCP' are in the a=
ppendix that was written v early on, when the focus was only TCP. That text=
 was not written by me, and I haven't got round to editing it for consisten=
cy. However, there are 4 occurrences of "'Classic' TCP" in the abstract and=
 intro, which I will also fix.

Can you say which "David's proposal" you mean please?


Bob
On 11/11/2019 23:10, Scharf, Michael wrote:
OK, so we seem to make some progress at least regarding the term 'classic' =
TCP. As mentioned before, I personally would find the term 'Classic' QUIC v=
ery confusing and you cannot avoid that if you talk about 'Classic' TCP, IM=
HO. So, it seems better to avoid that terminology for all transport protoco=
ls. For the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of th=
e terms 'classic' and 'TCP' back-to-back is used 11 times as far as I can s=
ee.

Regarding congestion control, I'd like to emphasize that David's proposal w=
ould also work well for me, i.e., characterizing the congestion control by =
functional properties. This avoids all issues regarding whether something w=
ill supersede something else (including the issue that EXP is just an exper=
iment that won't update or replace any PS document).

Michael

From: Bob Briscoe 
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael ; Wesley Eddy ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,
On 07/11/2019 08:11, Scharf, Michael wrote:
... and just to show that _my_ concern would be trivial to address by small=
 editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an i=
ncremental migration path so that normal TCP traffic classified in the 'Cla=
ssic' service of L4S will be no worse off" would already work for me.  It j=
ust takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service cla=
ss (and, e.g., "normal" sounds better to me), but in the context of a servi=
ce class, "classic" could actually work for me, if TSVWG really wants that =
name with strong consensus. I don't care how about names for DiffSe^D^D^D^D=
^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whateve=
r else is done in the fast path of a router to implement low latency servic=
e.

I only object to specific terminology such as 'Classic' TCP or 'Classic' co=
ngestion control because I don't think that 'classic' is a proper character=
ization for TCPM standards or TCP/IP stack behavior not aligned with whatev=
er L4S believes the bright future shall be.
I thought I had already agreed to remove 'TCP' from all instances of 'Class=
ic TCP traffic' etc, and that I hadn't intended to include 'TCP' in the fir=
st place. Because it's the congestion controls that are relevant in L4S dra=
fts, not the protocols.



Bob



Whether such small rewording address fully the concerns from others may be =
a different question.

Michael



From: Wesley Eddy 
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael ; Bob Briscoe ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.




If Dave+Michael's suggestion of replacing "classic" with "normal" is agreab=
le to others, this seems like a good way forward to me.  It should be easy =
enough to explain in other SDOs that classic and normal mean the same thing=
, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negativ=
e connotations to it.  However, for the sake of working group progress, I t=
hink we just need to pick something that seems the least terrible and agree=
 to move on.)






--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/

--_000_6EC6417807D9754DA64F3087E2E2E03E2D500D21rznt8114rzntrzd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I was referring to this statement from David Black:


 


<snip>


For congestion control in particular, I’ve found =
myself referring to 1/p and 1/sqrt(p) congestion response behaviors for tec=
hnical clarity/precision in discussion, but
 those terms don’t exactly roll off the tip of the tongue … and=
 assume that the reader is familiar enough with TCP throughput equations to=
 know what the variable p stands for.


</snip>


 


Instead of using equations, one could also define two a=
cronyms to make it more handy. I am pretty open to different variants.



 


To me, a key advantage of this approach is that it woul=
d be a technically neutral (mathematical) description of behavior that shou=
ld not be controversial. At least to me,
 this would work well.


 


Michael


 


 


 








From:=
 Bob Briscoe <ietf@bobbriscoe.net>


Sent: Wednesday, November 13, 2019 11:00 AM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Wesley E=
ddy <wes@mti-systems.com>; Rodney W. Grimes <4bone@gndrsh.dnsmgr.n=
et>

Cc: tsvwg@ietf.org; tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 


Michael,



I see the problem. Nearly all the occurrences of 'Classic TCP' are in the a=
ppendix that was written v early on, when the focus was only TCP. That text=
 was not written by me, and I haven't got round to editing it for consisten=
cy. However, there are 4 occurrences
 of "'Classic' TCP" in the abstract and intro, which I will also =
fix.



Can you say which "David's proposal" you mean please?





Bob




On 11/11/2019 23:10, Scharf, Michael wrote:






OK, so we seem to make some progress at least regarding=
 the term ‚classic‘ TCP. As mentioned before, I personally woul=
d find the term ‘Classic’ QUIC very confusing and
 you cannot avoid that if you talk about ‘Classic’ TCP, IMHO. S=
o, it seems better to avoid that terminology for all transport protocols. F=
or the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the ter=
ms ‘classic’ and ‘TCP’ back-to-back is used
 11 times as far as I can see.


 


Regarding congestion control, I’d like to emphasi=
ze that David’s proposal would also work well for me, i.e., character=
izing the congestion control by functional properties.
 This avoids all issues regarding whether something will supersede somethin=
g else (including the issue that EXP is just an experiment that won’t=
 update or replace any PS document).


 


Michael


 








From:=
 Bob Briscoe
<ietf@bobbriscoe.net> 

Sent: Monday, November 11, 2019 4:31 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Wesley Eddy
<wes@mti-systems.com>; Rod=
ney W. Grimes 
<4bone@gndrsh.dnsmgr.net>

Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 


Michael,



On 07/11/2019 08:11, Scharf, Michael wrote:






… and just to show that _my_ concern would=
 be trivial to address by small editorial changes:


 


For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wo=
rding “It gives an incremental migration path so that normal TCP traf=
fic classified in the ‘Classic’ service of L4S
 will be no worse off” would already work for me.  It just takes=
 a small editorial change to make me happy. This can’t be so hard.


 


Personally, I wonder if “classic” is indeed=
 the best name for a service class (and, e.g., “normal” sounds =
better to me), but in the context of a service class, “classic”
 could actually work for me, if TSVWG really wants that name with strong co=
nsensus. I don’t care how about names for DiffSe^D^D^D^D^D^D traffic =
classifiers, traffic policers/shapers, AQM schemes, or whatever else is don=
e in the fast path of a router to implement
 low latency service.


 


I only object to specific terminology such as ‘Cl=
assic’ TCP or ‘Classic’ congestion control because I don&=
#8217;t think that ‘classic’ is a proper characterization for T=
CPM standards
 or TCP/IP stack behavior not aligned with whatever L4S believes the bright=
 future shall be.




I thought I had already agreed to remove =
'TCP' from all instances of 'Classic TCP traffic' etc, and that I hadn't in=
tended to include 'TCP' in the first place. Because
 it's the congestion controls that are relevant in L4S drafts, not the prot=
ocols.







Bob










 


Whether such small rewording address fully the concerns=
 from others may be a different question.


 


Michael


 


 


 








From:=
 Wesley Eddy
<wes@mti-systems.com> 

Sent: Wednesday, November 6, 2019 8:54 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Bob Briscoe
<ietf@bobbriscoe.net>; Rod=
ney W. Grimes 
<4bone@gndrsh.dnsmgr.net>

Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 




On 11/6/2019 1:57 PM, Scharf, Michael wrote:






Bob,


 


From draft-ietf-tsvwg-ecn-l4s-id-08: “It gives an=
 incremental migration path so that existing 'Classic' TCP traffic will be =
no worse off”


 


You are proposing an experiment. Not more than that. I =
will be fine with the term “Classic” for TCP and TCPM-specified=
 congestion control when more than 50% of Internet
 traffic uses that new technology.


 


Until this happens, I insist that the word “Class=
ic” must be removed in all context of TCP and congestion control (as =
far as it is owned by TCPM), including the reference
 above. BTW, “normal” as suggested would also work for me. So, =
you have plenty of options for other terms.


 




 


If Dave+Michael's suggestion of replacing "classic" with &=
quot;normal" is agreable to others, this seems like a good way forward=
 to me.  It should be easy enough to explain in other SDOs that classi=
c and normal mean the same thing, if this is a real issue.


(FWIW, I've never had a problem myself with "classic", nor rea=
d any negative connotations to it.  However, for the sake of working g=
roup progress, I think we just need to pick something that seems the least =
terrible and agree to move on.)


 















-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/













-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/








--_000_6EC6417807D9754DA64F3087E2E2E03E2D500D21rznt8114rzntrzd_--


From nobody Wed Nov 13 03:39:06 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 8062A12001A for ; Wed, 13 Nov 2019 03:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 Fi_Qvq8BnpkV for ; Wed, 13 Nov 2019 03:39:01 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (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 C78E812023E for ; Wed, 13 Nov 2019 03:39:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNthaESeHRhZuNKbUmBd/2q7NmgSI5YgaaL21TyrBej3ycBeHD2TaZqvCxfl0VA3BThGVjSsFCeEZUe1Amx7aQDWcjOMpSOcktKcjnYO1DdS72j4glowtFu+bGdv2N+muFkXLTLYJ8wwxHFrjq5HdDVOcmNoJFhWz12LUfWQJZ96QBQQmy53iQ0dsxki0ASQqrEWV7ZuyvJasv7ZBWf9we/s4vc6nHs/veOXWhQMn5z8QuXauzlSv2NnfZ2Be68Cyz7mqd/hBzOiaSE8W0DEs3mTLVpS0CurawyAx0zCWi/b26fVHxxrMzYWqSpkuxBI4h0Z2PIo3c60wkrjOYB7Tg==
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=hVH6mHGNOXNRqe/bjYofiK/aRzpj/FSMXKSfcUK+3qs=; b=LAQAVC13bdikOzauyfFSpZIfYIEL4YmrjkfjaqigUvzuKBF72g5A7GBxG8Ab9JjcPZpDktV5TteVRGGNfFkxitHcrvEXbaeZa8HPAbMTJU0Zbxn7aY1VLjBZgbB3Rq8FWT2mewUPlbp9dFqi6FTVMdGQyZQ9ObWGDHUkMUteiafbeYL5cYm3kk9wUquDbliGnsrR1kdlgJq5aPASDUg4i03jgoi1NjxOcRZoGF5dlVh02ozHpEpXTrz8QtEikI49DgmXAKmA402QAc9KhjDhBGwTSsypxw5PV6w0dfNozqmrtSqYqsDZ6aS4UnUN8QrrkW1itJgDzgTZZ7StiG2T2A==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hVH6mHGNOXNRqe/bjYofiK/aRzpj/FSMXKSfcUK+3qs=; b=XJqj8ezQB2wVyeaCKKeL3s8Zca7gUCx5VXWC5ayjMUnedRPsZMhvCh9YTqglLxnv81irdF4+jVA26Ze3MqJuzrkbRl462lqARLxQixPdEt4iENJ5HNyW7BEJomFktx8cvXP3u8GFv0SqAji8cQ1txjkdJ1t6GiZKp3lTMtHLOa4=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4355.eurprd07.prod.outlook.com (52.133.61.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.7; Wed, 13 Nov 2019 11:38:58 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1%7]) with mapi id 15.20.2451.018; Wed, 13 Nov 2019 11:38:57 +0000
From: Mirja Kuehlewind 
To: Yoshifumi Nishida 
CC: Pete Heist , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
Thread-Index: AQHVlg3D3FuD8rQyOUeITRzrNWkm0aeH0YoAgAD1iACAAEt0gA==
Date: Wed, 13 Nov 2019 11:38:57 +0000
Message-ID: 
References: <201911072222.xA7MMYXb017371@gndrsh.dnsmgr.net>  <8382D634-8FEC-4932-96ED-9C5FB71E128D@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2001:16b8:2cce:e500:edca:fce4:c950:3b39]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e01bc225-9c8c-45df-6990-08d7682e123c
x-ms-traffictypediagnostic: AM0PR07MB4355:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(376002)(366004)(346002)(396003)(199004)(189003)(51914003)(81156014)(8936002)(81166006)(66446008)(316002)(86362001)(4326008)(236005)(6512007)(6486002)(64756008)(6436002)(2906002)(6916009)(8676002)(6306002)(54896002)(6116002)(66946007)(99286004)(5660300002)(256004)(14444005)(76116006)(71200400001)(71190400001)(36756003)(54906003)(66476007)(66556008)(966005)(478600001)(606006)(102836004)(14454004)(76176011)(229853002)(25786009)(7736002)(6506007)(2616005)(476003)(446003)(11346002)(6246003)(186003)(33656002)(561944003)(44832011)(53546011)(486006)(46003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4355; H:AM0PR07MB4691.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: BCL:0;
x-microsoft-antispam-message-info: lhktyr1D+7wcAkcOu3NoTPmoXPCXMh48UmP97DOCR2PG1+g7Mn8gRuRjZN/xhcX4npjLIFj99bmxuUwQA/WxSI6W+8vL8f4Z9XIrzAFiVtEPrOGPr57ShAxadQk/LIkoKHyRM66C0mC80KPBk+6iOukwQOkQyBSvdRDsnLI6qxx4lJSlzM+XwEz+zjCc7J6aW709vrSq9SQHBlYwEwQZYtqqBcEp8IOGpHkAdNOfX5XdT1K+vcCouoXPVl8wW1U3bhHO1aOvWp2pWnWsfHy5NyHXTD7SXNbR87LsGG2xCrJLA646KkPQYQn4h8i7x20z3QhbQcaHDwK6CZpcI5/rxfl9Gu/UcQ455MjLYFYwnZzFQZBVXWGUdIea4KN3pPjnkrW6tH4gA+vY4Ri9h89pzPM2ueEu/SCQGsNYy/QzQ7fQDBxM4RwktAHQa2VAEsNf
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_F4F44758691A40A295FF060ECDA6FEAAericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e01bc225-9c8c-45df-6990-08d7682e123c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 11:38:57.9048 (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: OHGJ1A0HIskEBGWYiYYRqiN3ZhePI4Eg8eX7oUwJeUoPBvBsb5PYSCS67KTpReWhEUFlgx8OMqj0Pxk3whVFITWUJhXeZBDad/3+mRC93Uk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4355
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 13 Nov 2019 11:39:05 -0000

--_000_F4F44758691A40A295FF060ECDA6FEAAericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgWW9zaGksDQoNCnNlZSBzb21lIGNvbW1lbnRzIGluIGxpbmUgKG1hcmtlZCB3aXRoIFtNS10p
Lg0KDQpNaXJqYQ0KDQpGcm9tOiBZb3NoaWZ1bWkgTmlzaGlkYSA8bnNkLmlldGZAZ21haWwuY29t
Pg0KRGF0ZTogV2VkbmVzZGF5LCAxMy4gTm92ZW1iZXIgMjAxOSBhdCAwOTowOQ0KVG86IE1pcmph
IEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KQ2M6IFBldGUgSGVp
c3QgPHBldGVAaGVpc3RwLm5ldD4sICJ0Y3BtQGlldGYub3JnIiA8dGNwbUBpZXRmLm9yZz4NClN1
YmplY3Q6IFJlOiBbdGNwbV0gU2Vla2luZyBmZWVkYmFjayBmb3IgZHJhZnQtaWV0Zi10Y3BtLWFj
Y3VyYXRlLWVjbiBhbmQgZHJhZnQtaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbg0KDQpIaSBNaXJq
YSwNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuDQoNCk9uIFR1ZSwgTm92IDEyLCAyMDE5IGF0
IDg6MzAgQU0gTWlyamEgS3VlaGxld2luZCA8bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208
bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpQZXRlciwgSSBk
b24ndCB0aGluayB0aGUgQWNjRUNOIGRyYWZ0IHNob3VsZCBzYXkgYW55dGhpbmcgYWJvdXQgd2hh
dCBoYXBwZW5zIHRvIHRoZSBleC1OUyBiaXQgaWYgaXQgZmFsbHMgYmFjayB0byBjbGFzc2ljIEVD
TiBiZWNhdXNlIHRoYXQncyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRyYWZ0IGRlZmluaW5nIHRoZSBB
Y2NFQ04gbWVjaGFuaXMuIEhvd2V2ZXIsIEkgYWdyZWUgdGhhdCBpcyB3b3VsZCBiZSBhdmFpbGFi
bGUgZm9yIGFub3RoZXIgdXNlLg0KDQpXZWxsLCB0aGlzIG1pZ2h0IGJlIGp1c3QgbXkgcGVyc29u
YWwgb3BpbmlvbiwgYnV0IHR3byBkcmFmdHMgKGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24g
YW5kIGRyYWZ0LWdyaW1lcy10Y3BtLXRjcHNjZS0wMCkgY2xhaW0gdG8gbmFtZSBleC1OUyBiaXQg
YXMgQUUgYW5kIEVTQ0Ugd2l0aG91dCBhbnkgZXhwbGFuYXRpb25zIGZvciBlYWNoIG90aGVyLg0K
VGhpcyBsb29rcyBjb25mdXNpbmcgdG8gbWUuDQoNCltNS10gWWVzIHRoYXQgaXMgYSBsaXR0bGUg
Y29uZnVzaW5nIGJ1dCBvbiB0aGUgb3RoZXIgaGFuZCB0aGVzZSBhcmUgdHdvIGRpZmZlcmVudCBt
ZWNoYW5pc20uIEkgdGhpbmsgd2UgZmlyc3QgbmVlZCB0byBoYXZlIGEgZGlzY3Vzc2lvbiBpZiB0
aGVyZSBpcyBpbnRlcmVzdCBpbiBUQ1AtU0NFIGluIHRoZSBncm91cCBiZWZvcmUgd2UgZGVjaWRl
IHRvIGNoYW5nZSBhbnl0aGluZyBpbiB0aGUgQWNjRUNOIGRyYWZ0LCBidXQgSSBndWVzcyB3ZSBk
aXNjdXNzIGFsc28gZmluZGluZyBhIG1vcmUgbmV1dHJhbCBuYW1lIG9yIGlmIGFsbG9jYXRlZCB1
bmRlciB0aGlzIG5hbWUgdGhlIFRDUC1TQ0Ugc2hvdWxkIGFsb3MgdXNlIGl0IChhcyB0aGV5IGFy
ZSBjdXJyZW50bHkgY2FsbCBpdCBOUyBiaXQpLg0KDQpZb3NoaSwgSSBiZWxpZXZlIHlvdSBwb2lu
dCBBMSBiZWxvdyB3YXMgZGVjaWRlZCBpbiB0aGUgZ3JvdXAgYWxyZWFkeSBhdCBhZG9wdGlvbiB0
aW1lIGFzIHRoZSBiaXQgd2FzIHVzZWQgZnJvbSB0aGUgYmVnaW5uaW5nIHdpdGggYWxsIHBvc3Np
YmxlIEFjY0VDTiBtZWNoYW5pc21zLiBIb3dldmVyLCBpZiBhbmQgaG93IGl0IHNob3VsZCBiZSBy
ZWdpc3RlcmVkIHdpdGggSUFOQSBpcyBhIGRpZmZlcmVudCBxdWVzdGlvbi4gVG8gbXkgbWVtb3J5
IHRoZXJlIHdhcyBzdXBwb3J0IHRvIHJlZ2lzdGVyZWQgZXZlbiB0aG91Z2ggaXQncyBleHBlcmlt
ZW50YWwgYmVjYXVzZSBOUyB3YXMgcmVnaXN0ZXJlZCBiYXNlZCBvbiBhbiBleHBlcmltZW50YWwg
UkZDIGFuZCBoYXZpbmcgdGhpcyByZWdpc3RyeSBzYXlpbmcgc29tZXRoaW5nIGFib3V0IHRoaXMg
c3BlY2lmaWMgYml0IHdoaWxlIG5vdCBub3RpbmcgdGhpcyBleHBlcmltZW50IHRoZXJlIHNlZW1z
IGNvbmZ1c2luZy9hZ2FpbnN0IHRoZSBpZGVhIG9mIGEgcmVnaXN0cnkuIFdoYXQgd2UgbWF5YmUg
Y291bGQgZGlzY3VzcyBpcyBpZiB3ZSB3YW50IHRvIHJlbmFtZSB0aGUgYml0IGluIHRoZSByZWdp
c3RyeSAodG8gQUUpIG9yIHJhdGhlciBqdXN0IGFkZCBhIG5vdGUgYWJvdXQgdGhpcyBleHBlcmlt
ZW50LiBMYXN0IHRpbWUgdGhlcmUgd2FzIHN1cHBvcnQgdG8gZ2l2ZSBpdCBhIHByb3BlciBuYW1l
IHdoaWNoIHdlIGZvbGxvd2VkIGFzIGF1dGhvcnMgYnV0IG9mIGNvdXJzZSBpdCdzIHRoZSB3b3Jr
aW5nIGdyb3VwIHRvIGRlY2lkZSBoZXJlLg0KDQpJIHNlZS4gSSBwZXJzb25hbGx5IHdvdWxkIGxp
a2UgdG8gc2VsZWN0IG9uZSBiZWZvcmUgV0dMQyB1bmxlc3Mgd2Ugc2VlIHNvbGlkIHJlYXNvbiB0
aGF0IHRoaXMgaXMgbm90IG5lY2Vzc2FyeS4NCg0KW01LXSBJIGRvbuKAmXQgc2VlIGEgZGVwZW5k
ZW5jeSBvbiBUQ1AtU0NFIGV4Y2VwdCB0aGUgbmFtZS4gSG93ZXZlciBkaXNjdXNzaW9uIG9uIFRD
UC1TQ0UganVzdCBzdGFydGVkIGFuZCBJIGRvbuKAmXQgd2FudCB0byBmdXJ0aGVyIGRlbGF5IEFj
Y0VDTiB3aGljaCBpcyBhbHJlYWR5IHN0YWJsZSBmb3IgYSBsb25nIHRpbWUuIElmIGl04oCZcyBq
dXN0IGFib3V0IGNoYW5naW5nIGEgbmFtZSB3aXRob3V0IGFueSB0ZWNobmljYWwgaW1wYWN0IHRo
YXQgY2FuIGJlIGRvbmUgYW55IHRpbWUgaW4gcHJvY2VzcyAoYmVmb3JlIGZpbmFsIHB1YmxpY2F0
aW9uKS4NCg0KQWRkaW5nIGEgbm90ZSBhYm91dCB0aGUgZXhwZXJpbWVudCBsb29rcyBhIHJlbGF0
aXZlbHkgZWFzaWVyIHBhdGggdG8gbWUgcmF0aGVyIHRoYW4gYWxsb2NhdGluZyBhIGJpdCBmb3Ig
ZXhwZXJpbWVudGFsIGRvYy4gQnV0LCBpZiB3ZSBhZG9wdCBTQ0UsIHdlJ2xsIG5lZWQgdG8gdXBk
YXRlIHRoZSBkZXNjcmlwdGlvbi4NCk9yLCBjcmVhdGluZyBhIHNtYWxsIFBTIGRvYyB0byBhbGxv
Y2F0ZSBhIGJpdCBjb3VsZCBiZSBhbiBpZGVhIGFzIHdlbGwuDQoNCltNS10gVGhhdOKAmXMgc29t
ZXRoaW5nIHdlIHNob3VsZCBkaXNjdXNzIG5vdy4NCg0KDQpSZWdhcmRpbmcgcG9pbnQgQTIsIHRo
aXMgd2FzIGFsc28gZGlzY3Vzc2VkIGF0IGxlbmd0aCBpbiB0aGUgZ3JvdXAuIFRoZXJlIGFyZSBk
aWZmZXJlbnQgd2F5IG9mIGZhaWxpbmcuIE9uZSBpcywgYXMgd2Ugc2F3IGZvciBOUywgdGhhdCB0
aGVyZSB3aWxsIGJlIG5vIGRlcGxveW1lbnQgYXQgYWxsIGFuZCB3ZSBjYW4gc2ltcGx5IHJlYXNz
aWduLiBBbm90aGVyIGl0IHRoYXQgaXMgZ2V0cyBkZXBsb3kgYnV0IGRvZXNuJ3Qgd29yayBhcyBl
eHBlY3RlZCwgaG93ZXZlciwgaW4gdGhpcyBjYXNlIHRoZXJlIGFyZSBzdGlsbCB3YXlzIHRvIGV4
dGVuZC9hbHRlciBBY2NFQ04gYnkgbmVnb3RpYXRpb24gZHVyaW5nIHRoZSBoYW5kc2hha2UuIFRo
aXMgaXMgYWxzbyBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0IGFuZCB0aGUgbWF5b3IgcmVhc29uIGZv
ciBoYXZpbmcgdGhlIGhhbmRzaGFrZSBuZWdvdGlhdGlvbiBpbnN0ZWFkIG9mIGp1c3QgdXNpbmcg
dGhlIGJpdCAoYXMgc29tZSBvdGhlciBwcm9wb3NhbCBkbykuIElmIHRoYXQgaXMgbm90IGdvb2Qg
ZW5vdWdoLCBJJ20gYWZyYWlkIHdlIHdvbid0IGJlIGFibGUgdG8gZXZlciB1c2UgYW55IG9mIHRo
ZSByZXNlcnZlZCBiaXRzIGluIHRoZSBUQ1AgaGFuZHNoYWtlLg0KDQpPSy4NCg0KDQpSZWdhcmRp
bmcgeW91ciBwb2ludCBCIGJlbG93IEkgZG9uJ3Qgc2VlIGFueSBkZXBlbmRlbmN5IEZST00gQWNj
RUNOIHRvIGFueSBvZiB0aGVzZSBwcm9wb3NhbHMuIFllcywgbXVsdGlwbGUgcHJvcG9zYWwgcmVw
bHkgb24gQWNjRUNOLCB3aGljaCBpdCBncmVhdCBiZWNhdXNlIGl0IHNob3cgdGhhdCBpdCBpcyB1
c2VmdWwsIGJ1dCB0aGF0IG9ubHkgbWVhbnMgdGhhdCB0aGUgcHJvcG9zYWxzIGhhdmUgYSBkZXBl
bmRlbmN5IFRPIEFjY0VDTiBhbmQgbm90IHRoZSBvdGhlciB3YXkgYXJvdW5kLiBGb3IgbWUgdGhp
cyBpcyBhbm90aGVyIHJlYXNvbiB0byBwcm9jZWVkIHdpdGggQWNjRUNOIHF1aWNrbHkuDQoNCk9L
LiBqdXN0IGZvciBjbGFyaWZpY2F0aW9uLg0KRm9yIGV4YW1wbGUsICBpbiBuZWFyIGZ1dHVyZSwg
c29tZSBtaWRkbGVib3hlcyBtYXkgaW1wbGVtZW50IGEgbWFya2luZyBhbGdvcml0aG0gd2hpY2gg
ZGVwZW5kcyBvbiBBY2NFQ04sIHdoaWxlIG90aGVyIG1pZGRsZWJveGVzIG1heSBpbXBsZW1lbnQg
YSBtYXJraW5nIGFsZ29yaXRobSB3aGljaCBkb2Vzbid0IGRlcGVuZCBvbiBBY2NFQ04uDQpUaGVz
ZSBtaWRkbGVib3hlcyBoYXBwZW4gdG8gYmUgb24gdGhlIHNhbWUgcGF0aCwgdGhlbiB0aGUgcGFj
a2V0IG1hcmtpbmcgcmVzdWx0cyB3aWxsIGJlIGEgbWl4IG9mIHR3byBhbGdvcml0aG1zIGFzIG1p
ZGRsZWJveGVzIGNhbm5vdCBpZGVudGlmeSB3aGljaCBUQ1AgZmxvd3MgdXNlIEFjY0VDTiBvciBu
b3QuDQpCdXQsIEFjY0VDTiBpcyBqdXN0IGRlc2lnbmVkIHRvIHJlcG9ydCB3aGF0IGl0IHJlY2Vp
dmVkIHdoZXRoZXIgdGhleSBhcmUgbWl4ZWQgcmVzdWx0cyBvciBub3QuIEhlbmNlLCB5b3Ugc2F5
IHRoYXQgQWNjRUNOIGlzIGluZGVwZW5kZW50IGZyb20gdGhlc2UgcG90ZW50aWFsIGNvbmZsaWN0
cy4gQ29ycmVjdD8NCg0KW01LXSBDb3JyZWN0LiBBY2NFQ04gcmVhbGx5IGlzIG9ubHkgdGhlIGZl
ZWRiYWNrIHNpZ25hbCBhbmQgSSB0aGluayBMNFMgd291bGQgZS5nLiBhZGRyZXNzIHdoYXQgeW91
IGRlc2NyaWJlIGFib3ZlIChhcyBvbmUgZXhhbXBsZSkuIEJ1dCB3ZSByZWFsbHkgdHJpZWQgdG8g
ZGUtY291cGxlIHRoYXQgYmVjYXVzZSBhKSBhcyBpdCB0dXJuZWQgb3V0IGlzIHdhcyBhbHJlYWR5
IG5vdCBncmVhdCB0byBoYXZlIHRoZXNlIHRoaW5ncyBtaXhlZCB1cCBpbiBvbmUgUkZDIGZvciBj
bGFzc2ljIEVDTiBhbmQgYikgaXTigJlzIGFsc28gdXNlZnVsIGZvciBvdGhlciB0aGluZ3MgKHRo
YXQgZG9u4oCZdCkgY2hhbmdlIHRoZSBjb25nZXN0aW9uIHJlc3BvbnNlLCBlLmcuIEVDTisrLg0K
DQoNCi0tDQpZb3NoaQ0KDQoNCg0KDQoNCk9uIDA4LjExLjE5LCAwOToyMywgInRjcG0gb24gYmVo
YWxmIG9mIFBldGUgSGVpc3QiIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRjcG0tYm91
bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHBldGVAaGVpc3RwLm5ldDxtYWlsdG86cGV0ZUBo
ZWlzdHAubmV0Pj4gd3JvdGU6DQoNCiAgICBIaSwNCg0KICAgIFJlZ2FyZGluZyBwb2ludHMgQTEg
YW5kIEIgb3ZlcmFsbCwgd291bGQgaXQgYmUgcG9zc2libGUgdG8gYWRkIHRvIHRoZSBBY2NFQ04g
ZHJhZnQgc29tZSBsYW5ndWFnZSBzdWNoIHRoYXQgd2hlbiBpdCBmYWxscyBiYWNrIHRvIFJGQyAz
MTY4IEVDTiwgdGhlIE5TIGJpdCBpcyBzdGlsbCBhdmFpbGFibGUgZm9yIG90aGVyIGV4cGVyaW1l
bnRzPyBUaGF0IHdheSB0aGUgYml0IGNvdWxkIHN0aWxsIGJlIHVzZWQgYnkgU0NFLCBldmVuIGlm
IEFjY0VDTiBiZWNvbWVzIGEgcHJvcG9zZWQgc3RhbmRhcmQuDQoNCiAgICA+IEZyb206IFlvc2hp
ZnVtaSBOaXNoaWRhIDxuc2QuaWV0ZkBnbWFpbC5jb208bWFpbHRvOm5zZC5pZXRmQGdtYWlsLmNv
bT4+DQogICAgPiBEYXRlOiBUaHUsIDcgTm92IDIwMTkgMTE6MDQ6MzggLTA4MDANCiAgICA+DQog
ICAgPiBIaSwNCiAgICA+IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24gYW5kIGRyYWZ0LWll
dGYtdGNwbS1nZW5lcmFsaXplZC1lY24gaGF2ZSBiZWVuDQogICAgPiBkaXNjdXNzZWQgZm9yIGEg
d2hpbGUuDQogICAgPiB0Y3BtIGNoYWlycyBhcmUgbm93IHRoaW5raW5nIHRoYXQgdGhleSBhcmUg
Z2V0dGluZyBtYXR1cmVkIGFuZCBiZWNvbWluZw0KICAgID4gcmVhZHkgZm9yIFdHTEMgLg0KICAg
ID4gSG93ZXZlciwgd2UgYWxzbyB0aGluayB0aGVyZSBhcmUgc2V2ZXJhbCBwb2ludHMgdG8gYmUg
Y2xhcmlmaWVkIGJlZm9yZWhhbmQuDQogICAgPg0KICAgID4gSW4gb3JkZXIgdG8gcHJvY2VlZCB0
aGUgY3VycmVudCBzaXR1YXRpb24sIHdlIHdvdWxkIGxpa2UgdG8gYXNrIHRoZQ0KICAgID4gY29t
bXVuaXR5IHRvIGdpdmUgc29tZSBmZWVkYmFjayBvbiB0aGUgZm9sbG93aW5nIHBvaW50cy4NCiAg
ICA+IFdlIHdpbGwgaGlnaGx5IGFwcHJlY2lhdGUgeW91ciBpbnB1dHMuDQogICAgPg0KICAgID4g
QTogQWxsb2NhdGluZyBiaXQgNyBmb3IgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbg0KICAg
ID4gIFRoZSBkcmFmdCByZXF1ZXN0cyB0aGUgYWxsb2NhdGlvbiBmb3IgYml0IDcgaW4gVENQIGhl
YWRlciAoZXggTlMgYml0KQ0KICAgID4gZm9yIHRoaXMgcHJvcG9zYWwuDQogICAgPiAgSG93ZXZl
ciwgdGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZHJhZnQgaXMgZXhwZXJpbWVudGFsLCB3aGlj
aCBtYXkgbm90DQogICAgPiBiZSB3ZWxsIGFsaWduZWQgd2l0aCB0aGUgZGVzY3JpcHRpb24gaW4g
UkZDMjc4MC4NCiAgICA+DQogICAgPiBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gY2hlY2sgdGhl
IGZvbGxvd2luZyBwb2ludHMuDQogICAgPiAgICAgQTE6IElmIHdlIGNhbiBoYXZlIGEgY29uc2Vu
c3VzIHRvIGFsbG9jYXRlIGJpdCA3IGZvciB0aGlzDQogICAgPiBleHBlcmltZW50YWwgZHJhZnQu
IE9yLCBpZiB0aGVyZSBpcyBhbnkgb3RoZXIgd2F5cyB0byBhbGxvdyB0aGUgYWxsb2NhdGlvbg0K
ICAgID4gKGUuZy4gdXNpbmcgb3RoZXIgZG9jdW1lbnRzKQ0KICAgID4gICAgIEEyOiBpZiB3ZSBk
ZWNpZGUgdG8gYWxsb2NhdGUgdGhlIGJpdCwgd2hhdCB3ZSBzaG91bGQgZG8gd2hlbiB0aGUNCiAg
ICA+IGV4cGVyaW1lbnQgZmFpbHMuDQogICAgPg0KICAgID4gQjogT3ZlcmxhcHMgd2l0aCBzb21l
IGNvbmdlc3Rpb24gZXhwZXJpZW5jZWQgcHJvcG9zYWxzDQogICAgPiAgSXQgc2VlbXMgdGhhdCBz
b21lIGNvbmdlc3Rpb24gZXhwZXJpZW5jZWQgcHJvcG9zYWxzDQogICAgPiAoZHJhZnQtZ3JpbWVz
LXRjcG0tdGNwc2NlDQogICAgPiBhbmQgZHJhZnQtbW9ydG9uLXRzdndnLXNjZSkgaGF2ZSBzaW1p
bGFyaXRpZXMgd2l0aCB0aGVzZSBkcmFmdHMuDQogICAgPg0KICAgID4gIFRoZSBjaGFpcnMgd291
bGQgbGlrZSB0byBjaGVjayB0aGUgZm9sbG93aW5nIHBvaW50cyBmb3IgdGhpcy4NCiAgICA+ICAg
IEIxOiBUaGUgdHdvIHByb3Bvc2FscyB3b24ndCBjb25mbGljdCBlYWNoIG90aGVyLiBXZSBjYW4g
ZGlzY3VzcyBhbmQNCiAgICA+IHByb2NlZWQgdGhlc2UgcHJvcG9zYWxzIHNlcGFyYXRlbHkgd2l0
aG91dCBhbnkgcG90ZW50aWFsIHJpc2tzLg0KICAgID4gICAgQjI6IGl0IHNlZW1zIHRoYXQgU0NF
IGFuZCBMNFMgbWF5IGhhdmUgc29tZSBjb25mbGljdHMsIGJ1dCB0aGlzIHdpbGwNCiAgICA+IG5v
dCBhZmZlY3QgdGhlIGRpc2N1c3Npb25zIGZvciBBY2NFQ04gYW5kIEVDTisrLg0KICAgID4gICAg
QjM6IGlmIHdlIGFsbG9jYXRlIHRoZSBiaXQgNyBmb3IgQWNjRUNOLCBpdCBpcyBzdGlsbCBhbGxv
d2VkIGZvciBTQ0UNCiAgICA+IHByb3Bvc2FscyB0byB1c2UgdGhlIGJpdCBvciBpdCB3aWxsIGJl
IHByb2hpYml0ZWQuDQogICAgPg0KICAgID4gIEJUVywganVzdCBpbiBjYXNlLiBwbGVhc2UgYXZv
aWQgaW5pdGlhdGluZyB0ZWNobmljYWwgZGlzY3Vzc2lvbnMgYW5kIHRyeQ0KICAgID4gdG8gZGlz
Y3VzcyBob3cgdG8gcHJvY2VlZCB0aGUgZHJhZnRzIGluIHRoaXMgdGhyZWFkLg0KICAgID4gLS0N
CiAgICA+IFlvc2hpIG9uIGJlaGFsZiBvZiB0Y3BtIGNoYWlycw0KDQogICAgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICB0Y3BtIG1haWxpbmcgbGlz
dA0KICAgIHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQogICAgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCg==

--_000_F4F44758691A40A295FF060ECDA6FEAAericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu
ODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
SGkgWW9zaGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5zZWUgc29tZSBjb21tZW50cyBpbiBsaW5lICht
YXJrZWQgd2l0aCBbTUtdKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NaXJqYTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Zb3NoaWZ1
bWkgTmlzaGlkYSAmbHQ7bnNkLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5X
ZWRuZXNkYXksIDEzLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6
YmxhY2siPk5vdmVtYmVyIDIwMTkgYXQgMDk6MDk8YnI+DQo8Yj5UbzogPC9iPk1pcmphIEt1ZWhs
ZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOiA8
L2I+UGV0ZSBIZWlzdCAmbHQ7cGV0ZUBoZWlzdHAubmV0Jmd0OywgJnF1b3Q7dGNwbUBpZXRmLm9y
ZyZxdW90OyAmbHQ7dGNwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFt0
Y3BtXSBTZWVraW5nIGZlZWRiYWNrIGZvciBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuIGFu
ZCBkcmFmdC1pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgTWlyamEsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyBmb3Ig
dGhlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+
T24gVHVlLCBOb3YgMTIsIDIwMTkgYXQgODozMCBBTSBNaXJqYSBLdWVobGV3aW5kICZsdDs8YSBo
cmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20iPm1pcmphLmt1ZWhsZXdp
bmRAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp
Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij5QZXRlciwgSSBkb24ndCB0aGluayB0aGUgQWNjRUNOIGRyYWZ0IHNob3VsZCBzYXkgYW55dGhp
bmcgYWJvdXQgd2hhdCBoYXBwZW5zIHRvIHRoZSBleC1OUyBiaXQgaWYgaXQgZmFsbHMgYmFjayB0
byBjbGFzc2ljIEVDTiBiZWNhdXNlIHRoYXQncyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRyYWZ0IGRl
ZmluaW5nIHRoZSBBY2NFQ04gbWVjaGFuaXMuIEhvd2V2ZXIsIEkgYWdyZWUNCiB0aGF0IGlzIHdv
dWxkIGJlIGF2YWlsYWJsZSBmb3IgYW5vdGhlciB1c2UuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XZWxsLCB0aGlzIG1pZ2h0IGJlIGp1
c3QgbXkgcGVyc29uYWwgb3BpbmlvbiwgYnV0IHR3byBkcmFmdHMgKGRyYWZ0LWlldGYtdGNwbS1h
Y2N1cmF0ZS1lY24gYW5kJm5ic3A7ZHJhZnQtZ3JpbWVzLXRjcG0tdGNwc2NlLTAwKSBjbGFpbSB0
byBuYW1lIGV4LU5TIGJpdCBhcyBBRSBhbmQgRVNDRSB3aXRob3V0IGFueSBleHBsYW5hdGlvbnMg
Zm9yIGVhY2ggb3RoZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIGxvb2tzIGNv
bmZ1c2luZyB0byBtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+W01LXSBZZXMgdGhhdCBp
cyBhIGxpdHRsZSBjb25mdXNpbmcgYnV0IG9uIHRoZSBvdGhlciBoYW5kIHRoZXNlIGFyZSB0d28g
ZGlmZmVyZW50IG1lY2hhbmlzbS4gSSB0aGluayB3ZSBmaXJzdCBuZWVkIHRvIGhhdmUgYSBkaXNj
dXNzaW9uIGlmIHRoZXJlIGlzIGludGVyZXN0IGluIFRDUC1TQ0UgaW4gdGhlIGdyb3VwIGJlZm9y
ZQ0KIHdlIGRlY2lkZSB0byBjaGFuZ2UgYW55dGhpbmcgaW4gdGhlIEFjY0VDTiBkcmFmdCwgYnV0
IEkgZ3Vlc3Mgd2UgZGlzY3VzcyBhbHNvIGZpbmRpbmcgYSBtb3JlIG5ldXRyYWwgbmFtZSBvciBp
ZiBhbGxvY2F0ZWQgdW5kZXIgdGhpcyBuYW1lIHRoZSBUQ1AtU0NFIHNob3VsZCBhbG9zIHVzZSBp
dCAoYXMgdGhleSBhcmUgY3VycmVudGx5IGNhbGwgaXQgTlMgYml0KS48L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt
IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Zb3NoaSwgSSBiZWxp
ZXZlIHlvdSBwb2ludCBBMSBiZWxvdyB3YXMgZGVjaWRlZCBpbiB0aGUgZ3JvdXAgYWxyZWFkeSBh
dCBhZG9wdGlvbiB0aW1lIGFzIHRoZSBiaXQgd2FzIHVzZWQgZnJvbSB0aGUgYmVnaW5uaW5nIHdp
dGggYWxsIHBvc3NpYmxlIEFjY0VDTiBtZWNoYW5pc21zLiBIb3dldmVyLCBpZiBhbmQgaG93IGl0
IHNob3VsZCBiZSByZWdpc3RlcmVkIHdpdGgNCiBJQU5BIGlzIGEgZGlmZmVyZW50IHF1ZXN0aW9u
LiBUbyBteSBtZW1vcnkgdGhlcmUgd2FzIHN1cHBvcnQgdG8gcmVnaXN0ZXJlZCBldmVuIHRob3Vn
aCBpdCdzIGV4cGVyaW1lbnRhbCBiZWNhdXNlIE5TIHdhcyByZWdpc3RlcmVkIGJhc2VkIG9uIGFu
IGV4cGVyaW1lbnRhbCBSRkMgYW5kIGhhdmluZyB0aGlzIHJlZ2lzdHJ5IHNheWluZyBzb21ldGhp
bmcgYWJvdXQgdGhpcyBzcGVjaWZpYyBiaXQgd2hpbGUgbm90IG5vdGluZyB0aGlzIGV4cGVyaW1l
bnQNCiB0aGVyZSBzZWVtcyBjb25mdXNpbmcvYWdhaW5zdCB0aGUgaWRlYSBvZiBhIHJlZ2lzdHJ5
LiBXaGF0IHdlIG1heWJlIGNvdWxkIGRpc2N1c3MgaXMgaWYgd2Ugd2FudCB0byByZW5hbWUgdGhl
IGJpdCBpbiB0aGUgcmVnaXN0cnkgKHRvIEFFKSBvciByYXRoZXIganVzdCBhZGQgYSBub3RlIGFi
b3V0IHRoaXMgZXhwZXJpbWVudC4gTGFzdCB0aW1lIHRoZXJlIHdhcyBzdXBwb3J0IHRvIGdpdmUg
aXQgYSBwcm9wZXIgbmFtZSB3aGljaCB3ZSBmb2xsb3dlZA0KIGFzIGF1dGhvcnMgYnV0IG9mIGNv
dXJzZSBpdCdzIHRoZSB3b3JraW5nIGdyb3VwIHRvIGRlY2lkZSBoZXJlLjxvOnA+PC9vOnA+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBzZWUuIEkgcGVy
c29uYWxseSB3b3VsZCBsaWtlIHRvIHNlbGVjdCBvbmUgYmVmb3JlIFdHTEMgdW5sZXNzIHdlIHNl
ZSBzb2xpZCByZWFzb24gdGhhdCB0aGlzIGlzIG5vdCBuZWNlc3NhcnkuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
RU4tVVMiPltNS10gSSBkb27igJl0IHNlZSBhIGRlcGVuZGVuY3kgb24gVENQLVNDRSBleGNlcHQg
dGhlIG5hbWUuIEhvd2V2ZXIgZGlzY3Vzc2lvbiBvbiBUQ1AtU0NFIGp1c3Qgc3RhcnRlZCBhbmQg
SSBkb27igJl0IHdhbnQgdG8gZnVydGhlciBkZWxheSBBY2NFQ04gd2hpY2ggaXMgYWxyZWFkeSBz
dGFibGUgZm9yIGEgbG9uZyB0aW1lLg0KIElmIGl04oCZcyBqdXN0IGFib3V0IGNoYW5naW5nIGEg
bmFtZSB3aXRob3V0IGFueSB0ZWNobmljYWwgaW1wYWN0IHRoYXQgY2FuIGJlIGRvbmUgYW55IHRp
bWUgaW4gcHJvY2VzcyAoYmVmb3JlIGZpbmFsIHB1YmxpY2F0aW9uKS48L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BZGRpbmcgYSBub3RlIGFib3V0
IHRoZSBleHBlcmltZW50IGxvb2tzIGEgcmVsYXRpdmVseSBlYXNpZXIgcGF0aCB0byBtZSByYXRo
ZXIgdGhhbiBhbGxvY2F0aW5nIGEgYml0IGZvciBleHBlcmltZW50YWwgZG9jLiBCdXQsIGlmIHdl
IGFkb3B0IFNDRSwgd2UnbGwgbmVlZCB0byB1cGRhdGUgdGhlIGRlc2NyaXB0aW9uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjM2LjBwdCI+T3IsIGNyZWF0aW5nIGEgc21hbGwgUFMgZG9jIHRvIGFsbG9jYXRlIGEg
Yml0IGNvdWxkIGJlIGFuIGlkZWEgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+W01LXSA8
L3NwYW4+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhhdOKAmXMgc29tZXRoaW5nIHdlIHNob3VsZCBk
aXNjdXNzIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g
MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZGluZyBwb2lu
dCBBMiwgdGhpcyB3YXMgYWxzbyBkaXNjdXNzZWQgYXQgbGVuZ3RoIGluIHRoZSBncm91cC4gVGhl
cmUgYXJlIGRpZmZlcmVudCB3YXkgb2YgZmFpbGluZy4gT25lIGlzLCBhcyB3ZSBzYXcgZm9yIE5T
LCB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gZGVwbG95bWVudCBhdCBhbGwgYW5kIHdlIGNhbiBzaW1w
bHkgcmVhc3NpZ24uIEFub3RoZXIgaXQNCiB0aGF0IGlzIGdldHMgZGVwbG95IGJ1dCBkb2Vzbid0
IHdvcmsgYXMgZXhwZWN0ZWQsIGhvd2V2ZXIsIGluIHRoaXMgY2FzZSB0aGVyZSBhcmUgc3RpbGwg
d2F5cyB0byBleHRlbmQvYWx0ZXIgQWNjRUNOIGJ5IG5lZ290aWF0aW9uIGR1cmluZyB0aGUgaGFu
ZHNoYWtlLiBUaGlzIGlzIGFsc28gZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCBhbmQgdGhlIG1heW9y
IHJlYXNvbiBmb3IgaGF2aW5nIHRoZSBoYW5kc2hha2UgbmVnb3RpYXRpb24gaW5zdGVhZCBvZg0K
IGp1c3QgdXNpbmcgdGhlIGJpdCAoYXMgc29tZSBvdGhlciBwcm9wb3NhbCBkbykuIElmIHRoYXQg
aXMgbm90IGdvb2QgZW5vdWdoLCBJJ20gYWZyYWlkIHdlIHdvbid0IGJlIGFibGUgdG8gZXZlciB1
c2UgYW55IG9mIHRoZSByZXNlcnZlZCBiaXRzIGluIHRoZSBUQ1AgaGFuZHNoYWtlLjxvOnA+PC9v
OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T0suJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w
cHQiPjxicj4NClJlZ2FyZGluZyB5b3VyIHBvaW50IEIgYmVsb3cgSSBkb24ndCBzZWUgYW55IGRl
cGVuZGVuY3kgRlJPTSBBY2NFQ04gdG8gYW55IG9mIHRoZXNlIHByb3Bvc2Fscy4gWWVzLCBtdWx0
aXBsZSBwcm9wb3NhbCByZXBseSBvbiBBY2NFQ04sIHdoaWNoIGl0IGdyZWF0IGJlY2F1c2UgaXQg
c2hvdyB0aGF0IGl0IGlzIHVzZWZ1bCwgYnV0IHRoYXQgb25seSBtZWFucyB0aGF0IHRoZSBwcm9w
b3NhbHMgaGF2ZSBhIGRlcGVuZGVuY3kgVE8gQWNjRUNOIGFuZCBub3QNCiB0aGUgb3RoZXIgd2F5
IGFyb3VuZC4gRm9yIG1lIHRoaXMgaXMgYW5vdGhlciByZWFzb24gdG8gcHJvY2VlZCB3aXRoIEFj
Y0VDTiBxdWlja2x5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjM2LjBwdCI+T0suIGp1c3QgZm9yIGNsYXJpZmljYXRpb24uPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjM2LjBwdCI+Rm9yIGV4YW1wbGUsJm5ic3A7IGluIG5lYXIgZnV0dXJlLCBzb21lIG1p
ZGRsZWJveGVzIG1heSBpbXBsZW1lbnQgYSBtYXJraW5nIGFsZ29yaXRobSB3aGljaCBkZXBlbmRz
IG9uIEFjY0VDTiwgd2hpbGUgb3RoZXIgbWlkZGxlYm94ZXMgbWF5IGltcGxlbWVudCBhIG1hcmtp
bmcgYWxnb3JpdGhtIHdoaWNoIGRvZXNuJ3QgZGVwZW5kIG9uIEFjY0VDTi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDozNi4wcHQiPlRoZXNlIG1pZGRsZWJveGVzIGhhcHBlbiB0byBiZSBvbiB0aGUgc2FtZSBwYXRo
LCB0aGVuIHRoZSBwYWNrZXQgbWFya2luZyByZXN1bHRzIHdpbGwgYmUgYSBtaXggb2YgdHdvIGFs
Z29yaXRobXMgYXMgbWlkZGxlYm94ZXMgY2Fubm90IGlkZW50aWZ5IHdoaWNoIFRDUCBmbG93cyB1
c2UgQWNjRUNOIG9yIG5vdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJ1dCwgQWNjRUNOIGlzIGp1
c3QgZGVzaWduZWQgdG8gcmVwb3J0IHdoYXQgaXQgcmVjZWl2ZWQgd2hldGhlciB0aGV5IGFyZSBt
aXhlZCByZXN1bHRzIG9yIG5vdC4gSGVuY2UsIHlvdSBzYXkgdGhhdCBBY2NFQ04gaXMgaW5kZXBl
bmRlbnQgZnJvbSB0aGVzZSBwb3RlbnRpYWwgY29uZmxpY3RzLiBDb3JyZWN0PzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj5bTUtdIDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5Db3JyZWN0LiBBY2NF
Q04gcmVhbGx5IGlzIG9ubHkgdGhlIGZlZWRiYWNrIHNpZ25hbCBhbmQgSSB0aGluayBMNFMgd291
bGQgZS5nLiBhZGRyZXNzIHdoYXQgeW91IGRlc2NyaWJlIGFib3ZlIChhcyBvbmUgZXhhbXBsZSku
IEJ1dCB3ZSByZWFsbHkgdHJpZWQgdG8gZGUtY291cGxlIHRoYXQgYmVjYXVzZSBhKSBhcyBpdCB0
dXJuZWQgb3V0IGlzIHdhcyBhbHJlYWR5IG5vdCBncmVhdCB0byBoYXZlIHRoZXNlIHRoaW5ncw0K
IG1peGVkIHVwIGluIG9uZSBSRkMgZm9yIGNsYXNzaWMgRUNOIGFuZCBiKSBpdOKAmXMgYWxzbyB1
c2VmdWwgZm9yIG90aGVyIHRoaW5ncyAodGhhdCBkb27igJl0KSBjaGFuZ2UgdGhlIGNvbmdlc3Rp
b24gcmVzcG9uc2UsIGUuZy4gRUNOJiM0MzsmIzQzOy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPllvc2hpPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90
dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMDgu
MTEuMTksIDA5OjIzLCAmcXVvdDt0Y3BtIG9uIGJlaGFsZiBvZiBQZXRlIEhlaXN0JnF1b3Q7ICZs
dDs8YSBocmVmPSJtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
dGNwbS1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpw
ZXRlQGhlaXN0cC5uZXQiIHRhcmdldD0iX2JsYW5rIj5wZXRlQGhlaXN0cC5uZXQ8L2E+Jmd0OyB3
cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEhpLDxicj4NCjxicj4NCiZuYnNwOyAmbmJz
cDsgUmVnYXJkaW5nIHBvaW50cyBBMSBhbmQgQiBvdmVyYWxsLCB3b3VsZCBpdCBiZSBwb3NzaWJs
ZSB0byBhZGQgdG8gdGhlIEFjY0VDTiBkcmFmdCBzb21lIGxhbmd1YWdlIHN1Y2ggdGhhdCB3aGVu
IGl0IGZhbGxzIGJhY2sgdG8gUkZDIDMxNjggRUNOLCB0aGUgTlMgYml0IGlzIHN0aWxsIGF2YWls
YWJsZSBmb3Igb3RoZXIgZXhwZXJpbWVudHM/IFRoYXQgd2F5IHRoZSBiaXQgY291bGQgc3RpbGwg
YmUgdXNlZCBieSBTQ0UsIGV2ZW4gaWYgQWNjRUNODQogYmVjb21lcyBhIHByb3Bvc2VkIHN0YW5k
YXJkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBGcm9tOiBZb3NoaWZ1bWkgTmlzaGlk
YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5zZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
Pm5zZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IERhdGU6
IFRodSwgNyBOb3YgMjAxOSAxMTowNDozOCAtMDgwMDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8
YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSGksPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGRyYWZ0
LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24gYW5kIGRyYWZ0LWlldGYtdGNwbS1nZW5lcmFsaXplZC1l
Y24gaGF2ZSBiZWVuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGRpc2N1c3NlZCBmb3IgYSB3aGls
ZS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgdGNwbSBjaGFpcnMgYXJlIG5vdyB0aGlua2luZyB0
aGF0IHRoZXkgYXJlIGdldHRpbmcgbWF0dXJlZCBhbmQgYmVjb21pbmc8YnI+DQombmJzcDsgJm5i
c3A7ICZndDsgcmVhZHkgZm9yIFdHTEMgLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBIb3dldmVy
LCB3ZSBhbHNvIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIHBvaW50cyB0byBiZSBjbGFyaWZpZWQg
YmVmb3JlaGFuZC48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAm
Z3Q7IEluIG9yZGVyIHRvIHByb2NlZWQgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLCB3ZSB3b3VsZCBs
aWtlIHRvIGFzayB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgY29tbXVuaXR5IHRvIGdpdmUg
c29tZSBmZWVkYmFjayBvbiB0aGUgZm9sbG93aW5nIHBvaW50cy48YnI+DQombmJzcDsgJm5ic3A7
ICZndDsgV2Ugd2lsbCBoaWdobHkgYXBwcmVjaWF0ZSB5b3VyIGlucHV0cy48YnI+DQombmJzcDsg
Jm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEE6IEFsbG9jYXRpbmcgYml0IDcg
Zm9yIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY248YnI+DQombmJzcDsgJm5ic3A7ICZndDsm
bmJzcDsgVGhlIGRyYWZ0IHJlcXVlc3RzIHRoZSBhbGxvY2F0aW9uIGZvciBiaXQgNyBpbiBUQ1Ag
aGVhZGVyIChleCBOUyBiaXQpPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGZvciB0aGlzIHByb3Bv
c2FsLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyBIb3dldmVyLCB0aGUgaW50ZW5kZWQg
c3RhdHVzIG9mIHRoZSBkcmFmdCBpcyBleHBlcmltZW50YWwsIHdoaWNoIG1heSBub3Q8YnI+DQom
bmJzcDsgJm5ic3A7ICZndDsgYmUgd2VsbCBhbGlnbmVkIHdpdGggdGhlIGRlc2NyaXB0aW9uIGlu
IFJGQzI3ODAuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0
OyBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gY2hlY2sgdGhlIGZvbGxvd2luZyBwb2ludHMuPGJy
Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtBMTogSWYgd2UgY2FuIGhh
dmUgYSBjb25zZW5zdXMgdG8gYWxsb2NhdGUgYml0IDcgZm9yIHRoaXM8YnI+DQombmJzcDsgJm5i
c3A7ICZndDsgZXhwZXJpbWVudGFsIGRyYWZ0LiBPciwgaWYgdGhlcmUgaXMgYW55IG90aGVyIHdh
eXMgdG8gYWxsb3cgdGhlIGFsbG9jYXRpb248YnI+DQombmJzcDsgJm5ic3A7ICZndDsgKGUuZy4g
dXNpbmcgb3RoZXIgZG9jdW1lbnRzKTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7QTI6IGlmIHdlIGRlY2lkZSB0byBhbGxvY2F0ZSB0aGUgYml0LCB3aGF0IHdlIHNo
b3VsZCBkbyB3aGVuIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBleHBlcmltZW50IGZhaWxz
Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgQjogT3Zl
cmxhcHMgd2l0aCBzb21lIGNvbmdlc3Rpb24gZXhwZXJpZW5jZWQgcHJvcG9zYWxzPGJyPg0KJm5i
c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7IEl0IHNlZW1zIHRoYXQgc29tZSBjb25nZXN0aW9uIGV4cGVy
aWVuY2VkIHByb3Bvc2Fsczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAoZHJhZnQtZ3JpbWVzLXRj
cG0tdGNwc2NlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGFuZCBkcmFmdC1tb3J0b24tdHN2d2ct
c2NlKSBoYXZlIHNpbWlsYXJpdGllcyB3aXRoIHRoZXNlIGRyYWZ0cy48YnI+DQombmJzcDsgJm5i
c3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7IFRoZSBjaGFpcnMgd291bGQg
bGlrZSB0byBjaGVjayB0aGUgZm9sbG93aW5nIHBvaW50cyBmb3IgdGhpcy48YnI+DQombmJzcDsg
Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IEIxOiBUaGUgdHdvIHByb3Bvc2FscyB3b24ndCBjb25m
bGljdCBlYWNoIG90aGVyLiBXZSBjYW4gZGlzY3VzcyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZn
dDsgcHJvY2VlZCB0aGVzZSBwcm9wb3NhbHMgc2VwYXJhdGVseSB3aXRob3V0IGFueSBwb3RlbnRp
YWwgcmlza3MuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyBCMjogaXQgc2Vl
bXMgdGhhdCBTQ0UgYW5kIEw0UyBtYXkgaGF2ZSBzb21lIGNvbmZsaWN0cywgYnV0IHRoaXMgd2ls
bDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBub3QgYWZmZWN0IHRoZSBkaXNjdXNzaW9ucyBmb3Ig
QWNjRUNOIGFuZCBFQ04mIzQzOyYjNDM7Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm
bmJzcDsgQjM6IGlmIHdlIGFsbG9jYXRlIHRoZSBiaXQgNyBmb3IgQWNjRUNOLCBpdCBpcyBzdGls
bCBhbGxvd2VkIGZvciBTQ0U8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgcHJvcG9zYWxzIHRvIHVz
ZSB0aGUgYml0IG9yIGl0IHdpbGwgYmUgcHJvaGliaXRlZC48YnI+DQombmJzcDsgJm5ic3A7ICZn
dDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7IEJUVywganVzdCBpbiBjYXNlLiBwbGVh
c2UgYXZvaWQgaW5pdGlhdGluZyB0ZWNobmljYWwgZGlzY3Vzc2lvbnMgYW5kIHRyeTxicj4NCiZu
YnNwOyAmbmJzcDsgJmd0OyB0byBkaXNjdXNzIGhvdyB0byBwcm9jZWVkIHRoZSBkcmFmdHMgaW4g
dGhpcyB0aHJlYWQuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IC0tPGJyPg0KJm5ic3A7ICZuYnNw
OyAmZ3Q7IFlvc2hpIG9uIGJlaGFsZiBvZiB0Y3BtIGNoYWlyczxicj4NCjxicj4NCiZuYnNwOyAm
bmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQombmJzcDsgJm5ic3A7IHRjcG0gbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBo
cmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8
L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3RjcG0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3RjcG08L2E+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_F4F44758691A40A295FF060ECDA6FEAAericssoncom_--


From nobody Wed Nov 13 05:30: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 BBE9712025D for ; Wed, 13 Nov 2019 05:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 MP49Hxbo343U for ; Wed, 13 Nov 2019 05:30:25 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 CDA14120804 for ; Wed, 13 Nov 2019 05:30:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject: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=PkLy7/4k27pdxJyA1d0TbfFU8OZETHOSvXvdsJxB6BI=; b=KbapFgv0W+uFPqUWDag6aiXm2 f5KGp3HgyZQp/Awk+NW/GXvI0ilBZTfNHjxZcVVIiIff+h93or/DrAB0eL9x9oib2qa+eRhsOUyfR ltbLHSI6LM/1/QaAQPEghsbJ0/hlguy7s3G+TwtbgKWPLqt2M/Dh9XIijyQcacdPpsLXBpZ+mxNbw 4K5wCba/gHRJRzwFTU50Y9shl8MqtyhakJIvtkEdyc1dnb9hkGjssyEYLrO1PadQZLDrGyo4HvWcU CPhBKrSliS/GmQfcWKDmintclERMasCFu1MBupsKDKfhVlVcYu1PdCsIM0r/gCNuu9GHLTx0TLxy3 ss2WlVhxQ==;
Received: from [31.185.128.31] (port=50426 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iUsj0-0003p6-Ru; Wed, 13 Nov 2019 13:30:23 +0000
To: Neal Cardwell , "tcpm@ietf.org" 
References:  
From: Bob Briscoe 
Message-ID: <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>
Date: Wed, 13 Nov 2019 13:30:22 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2A4B8AB4014576494A892F08"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 13 Nov 2019 13:30:28 -0000

This is a multi-part message in MIME format.
--------------2A4B8AB4014576494A892F08
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Neal,

Rather than the IETF have to decide up front which ECT value will be 
more prevalent, I did suggest the following mechanism to my co-authors. 
However, even tho it's fairly simple, we decided wasting some space was 
simpler.

Given TCP Option space is in short supply, if the WG prefers, we can 
include that idea in the spec:...

The data sender for each half-connection currently initializes

	r.e0b = 1 and r.ceb = r.e1b.= 0

then communicates these to the other end in the option. We could make 
the initial values into a signal that determines whether ECT1 feedback 
comes first for feedback on that half connection. For example:

	r.e0b = 0 and r.ceb = r.e1b.= 1

could mean ECT0 & ECT1 will be the other way round.


Bob

On 12/11/2019 16:09, Mirja Kuehlewind wrote:
> Hi Neal,
>
> that's a good point. The order of the field was based on what is expected to be the most likely case. Currently most traffic, if it uses ECN at all, will set the codepoint to ECT(0). With deployment of L4S this could change in future, however, there are also still ways to extend the negotiation in the AccECN TCP handshake to e.g. support this case better in future.
>
> Mirja
>
>
>
> On 11.11.19, 18:25, "tcpm on behalf of Neal Cardwell"  wrote:
>
>      A particular question in regards to the AccECN option:
>      
>        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6
>      
>      The AccECN option spec lists the EE0B field first, with the EE1B field
>      at the end.
>      
>      Given that L4S plans on using ECT(1) for data packets, and unchanging
>      counter values can be omitted from the end of the AccECN option, why
>      not list EE1B first, and EE0B last? With EE1B first and EE0B last it
>      seems that in the common case for an L4S connection the (unchanged)
>      EE0B could be omitted, allowing 4 extra bytes of payload per packet.
>      AFAICT this extra 4 bytes would increase goodput for applications
>      using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
>      back-of-the-envelope calculations.
>      
>      best,
>      neal
>      
>      _______________________________________________
>      tcpm mailing list
>      tcpm@ietf.org
>      https://www.ietf.org/mailman/listinfo/tcpm
>      
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------2A4B8AB4014576494A892F08
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Neal,

    

    Rather than the IETF have to decide up front which ECT value will be
    more prevalent, I did suggest the following mechanism to my
    co-authors. However, even tho it's fairly simple, we decided wasting
    some space was simpler. 

    

    Given TCP Option space is in short supply, if the WG prefers, we can
    include that idea in the spec:...

    

    The data sender for each half-connection currently initializes 

    
	r.e0b = 1 and r.ceb = r.e1b.= 0

    then communicates these to the other end in the option. We could
    make the initial values into a signal that determines whether ECT1
    feedback comes first for feedback on that half connection. For
    example:

    
	r.e0b = 0 and r.ceb = r.e1b.= 1

    could mean ECT0 & ECT1 will be the other way round.

    

    

    Bob

    

    
On 12/11/2019 16:09, Mirja Kuehlewind
      wrote:

    

    

      
Hi Neal,

that's a good point. The order of the field was based on what is expected to be the most likely case. Currently most traffic, if it uses ECN at all, will set the codepoint to ECT(0). With deployment of L4S this could change in future, however, there are also still ways to extend the negotiation in the AccECN TCP handshake to e.g. support this case better in future. 

Mirja



On 11.11.19, 18:25, "tcpm on behalf of Neal Cardwell" <tcpm-bounces@ietf.org on behalf of ncardwell=40google.com@dmarc.ietf.org> wrote:

    A particular question in regards to the AccECN option:
    
      https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6
    
    The AccECN option spec lists the EE0B field first, with the EE1B field
    at the end.
    
    Given that L4S plans on using ECT(1) for data packets, and unchanging
    counter values can be omitted from the end of the AccECN option, why
    not list EE1B first, and EE0B last? With EE1B first and EE0B last it
    seems that in the common case for an L4S connection the (unchanged)
    EE0B could be omitted, allowing 4 extra bytes of payload per packet.
    AFAICT this extra 4 bytes would increase goodput for applications
    using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
    back-of-the-envelope calculations.
    
    best,
    neal
    
    _______________________________________________
    tcpm mailing list
    tcpm@ietf.org
    https://www.ietf.org/mailman/listinfo/tcpm
    



    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------2A4B8AB4014576494A892F08--


From nobody Wed Nov 13 06:39:14 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 0B1FD12080A for ; Wed, 13 Nov 2019 06:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 QAgDzeWbyOih for ; Wed, 13 Nov 2019 06:39:10 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55EE12003E for ; Wed, 13 Nov 2019 06:39:09 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xADEd5ce044223; Wed, 13 Nov 2019 06:39:05 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xADEd4Kv044222; Wed, 13 Nov 2019 06:39:04 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911131439.xADEd4Kv044222@gndrsh.dnsmgr.net>
In-Reply-To: 
To: Mirja Kuehlewind 
Date: Wed, 13 Nov 2019 06:39:04 -0800 (PST)
CC: Yoshifumi Nishida , "tcpm@ietf.org" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 13 Nov 2019 14:39:12 -0000

Hello Mirja, Yoshi, etc al,

Some comments in line (marked with [RWG]

Regards,
Rod

> Hi Yoshi,
> 
> see some comments in line (marked with [MK]).
> 
> Mirja
> 
> From: Yoshifumi Nishida 
> Date: Wednesday, 13. November 2019 at 09:09
> To: Mirja Kuehlewind 
> Cc: Pete Heist , "tcpm@ietf.org" 
> Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
> 
> Hi Mirja,
> 
> Thanks for the response.
> 
> On Tue, Nov 12, 2019 at 8:30 AM Mirja Kuehlewind > wrote:
> Peter, I don't think the AccECN draft should say anything about what happens to the ex-NS bit if it falls back to classic ECN because that's out of scope of the draft defining the AccECN mechanis. However, I agree that is would be available for another use.

 [RWG] Perhaps that is all that would need to be added?  "The newly allocated AE bit would be avaliable for other uses should AccECN fail to negotiate."

> 
> Well, this might be just my personal opinion, but two drafts (draft-ietf-tcpm-accurate-ecn and draft-grimes-tcpm-tcpsce-00) claim to name ex-NS bit as AE and ESCE without any explanations for each other.
> This looks confusing to me.
> 
> [MK] Yes that is a little confusing but on the other hand these are two different mechanism. I think we first need to have a discussion if there is interest in TCP-SCE in the group before we decide to change anything in the AccECN draft, but I guess we discuss also finding a more neutral name or if allocated under this name the TCP-SCE should alos use it (as they are currently call it NS bit).

 [RWG] TCP-SCE calls this bit ESCE (Echo SCE) due to its parallels with CE/ECE.  I have tried to minimize referense to NS in the latest version of the draft.

> Yoshi, I believe you point A1 below was decided in the group already at adoption time as the bit was used from the beginning with all possible AccECN mechanisms. However, if and how it should be registered with IANA is a different question. To my memory there was support to registered even though it's experimental because NS was registered based on an experimental RFC and having this registry saying something about this specific bit while not noting this experiment there seems confusing/against the idea of a registry. What we maybe could discuss is if we want to rename the bit in the registry (to AE) or rather just add a note about this experiment. Last time there was support to give it a proper name which we followed as authors but of course it's the working group to decide here.
> 
> I see. I personally would like to select one before WGLC unless we see solid reason that this is not necessary.
> 
> [MK] I don?t see a dependency on TCP-SCE except the name. However discussion on TCP-SCE just started and I don?t want to further delay AccECN which is already stable for a long time. If it?s just about changing a name without any technical impact that can be done any time in process (before final publication).
> 
> Adding a note about the experiment looks a relatively easier path to me rather than allocating a bit for experimental doc. But, if we adopt SCE, we'll need to update the description.
> Or, creating a small PS doc to allocate a bit could be an idea as well.
> 
> [MK] That?s something we should discuss now.
> 
> 
> Regarding point A2, this was also discussed at length in the group. There are different way of failing. One is, as we saw for NS, that there will be no deployment at all and we can simply reassign. Another it that is gets deploy but doesn't work as expected, however, in this case there are still ways to extend/alter AccECN by negotiation during the handshake. This is also discussed in the draft and the mayor reason for having the handshake negotiation instead of just using the bit (as some other proposal do). If that is not good enough, I'm afraid we won't be able to ever use any of the reserved bits in the TCP handshake.

 [RWG] I believe one of the major reasons that the negotiation MUST occur before doing AccECN is that it redifines the meaning of the CE bit in IP (this is an arguable point, I understand it just counts them and feeds back how many occured, but this is mainly so that L4S can use them in a high fadelity marking scheme), and ECE bit in TCP, I find that redifinition of an IP layer bit based on a TCP layer negotation problematic, see more below.

> 
> OK.
> 
> 
> Regarding your point B below I don't see any dependency FROM AccECN to any of these proposals. Yes, multiple proposal reply on AccECN, which it great because it show that it is useful, but that only means that the proposals have a dependency TO AccECN and not the other way around. For me this is another reason to proceed with AccECN quickly.
> 
> OK. just for clarification.
> For example,  in near future, some middleboxes may implement a marking algorithm which depends on AccECN, while other middleboxes may implement a marking algorithm which doesn't depend on AccECN.
> These middleboxes happen to be on the same path, then the packet marking results will be a mix of two algorithms as middleboxes cannot identify which TCP flows use AccECN or not.
> But, AccECN is just designed to report what it received whether they are mixed results or not. Hence, you say that AccECN is independent from these potential conflicts. Correct?

 [RWG] Yoshi I agree that there are concerns here that should be looked at very carefully, the ECT(1) bit used to classify L4S traffic is the crux of that issue.

> [MK] Correct. AccECN really is only the feedback signal and I think L4S would e.g. address what you describe above (as one example). But we really tried to de-couple that because a) as it turned out is was already not great to have these things mixed up in one RFC for classic ECN and b) it?s also useful for other things (that don?t) change the congestion response, e.g. ECN++.

 [RWG] Mirja it appears that the design of AccECN is heavily biased towards support for L4S, giving that counting CE is the main feedback element, and that L4S is desgined to create more CE marks when in use.  This is one reason that SCE rejected AccECN as a viable solution for closing the feedback loop in SCE at the TCP layer, it is actually ECT(1) mark counts that needs high fadelity feedback as CE rarely occurs in the SCE design (it is a backstop failure mechansim for SCE to retain ECN3168 behavior.)  We do understand that a count of ECT(1) is avaliable, but that it requires a TCP option to get at it.

> --
> Yoshi
> 
> 
> 
> 
> 
> On 08.11.19, 09:23, "tcpm on behalf of Pete Heist"  on behalf of pete@heistp.net> wrote:
> 
>     Hi,
> 
>     Regarding points A1 and B overall, would it be possible to add to the AccECN draft some language such that when it falls back to RFC 3168 ECN, the NS bit is still available for other experiments? That way the bit could still be used by SCE, even if AccECN becomes a proposed standard.
> 
>     > From: Yoshifumi Nishida >
>     > Date: Thu, 7 Nov 2019 11:04:38 -0800
>     >
>     > Hi,
>     > draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn have been
>     > discussed for a while.
>     > tcpm chairs are now thinking that they are getting matured and becoming
>     > ready for WGLC .
>     > However, we also think there are several points to be clarified beforehand.
>     >
>     > In order to proceed the current situation, we would like to ask the
>     > community to give some feedback on the following points.
>     > We will highly appreciate your inputs.
>     >
>     > A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn
>     >  The draft requests the allocation for bit 7 in TCP header (ex NS bit)
>     > for this proposal.
>     >  However, the intended status of the draft is experimental, which may not
>     > be well aligned with the description in RFC2780.
>     >
>     > The chairs would like to check the following points.
>     >     A1: If we can have a consensus to allocate bit 7 for this
>     > experimental draft. Or, if there is any other ways to allow the allocation
>     > (e.g. using other documents)
>     >     A2: if we decide to allocate the bit, what we should do when the
>     > experiment fails.
>     >
>     > B: Overlaps with some congestion experienced proposals
>     >  It seems that some congestion experienced proposals
>     > (draft-grimes-tcpm-tcpsce
>     > and draft-morton-tsvwg-sce) have similarities with these drafts.
>     >
>     >  The chairs would like to check the following points for this.
>     >    B1: The two proposals won't conflict each other. We can discuss and
>     > proceed these proposals separately without any potential risks.
>     >    B2: it seems that SCE and L4S may have some conflicts, but this will
>     > not affect the discussions for AccECN and ECN++.
>     >    B3: if we allocate the bit 7 for AccECN, it is still allowed for SCE
>     > proposals to use the bit or it will be prohibited.
>     >
>     >  BTW, just in case. please avoid initiating technical discussions and try
>     > to discuss how to proceed the drafts in this thread.
>     > --
>     > Yoshi on behalf of tcpm chairs
> 
>     _______________________________________________
>     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

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Wed Nov 13 08:04:38 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 77A1D1208C9 for ; Wed, 13 Nov 2019 08:04:35 -0800 (PST)
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 cRdAnMXycc8u for ; Wed, 13 Nov 2019 08:04:30 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30080.outbound.protection.outlook.com [40.107.3.80]) (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 89ADC12088A for ; Wed, 13 Nov 2019 08:04:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FSL5/4z5JTEZ4kztEuiEPJpIl0NCa3dgA+Y3kXlOMtujSH09Sh+VyJL5dVW9wXcAzJYi/wewVb8Z60a6x8ZJ0tnfLIJu+z8br4MrC+nIJysgIhB5PL8/32KBHIzmHQpTCdLuAryz6yT+0uvuVZguRQPpQ5uVNU2dHKZWERWcRzBygoF1cLWW+6JbO7ETuHvjZFvYuMJzHx4La1ReVIRSSD6VG7n4gjXy5G4zlVCuSq501L3XLsr6hJAm9ILuvWnztimhwP1+GwbAr7WZmal6tEG/9TXiZq0unUPniLRqgM21pdZapvTphALF6I5UuAAisxqtZn9Jdr45cIx7p2okoA==
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=hqOHsaScpi37J+bf9aKrn+6UdqR3ICwXjJFTZn99FoU=; b=ipJ2gwcQVVBXihM9oZE4PKE+NwpW/urDv/S/h+E2LGuhMO41ozL/UANuAuMZu57F+vMGN6IyNmAgW6zidLZPo51ZzbCQPu25J12Ey6DDEGXJ08kHfixCn4uTYXNv+5/Oo7xhA5kNsddUMqyfbqEyzY0klEiuGd6uG6O0sOoA/GRqwwG1DWbAPTWSqYfCcmTPg7tieFtIlQ1HcrsGvyrlQrv+QrDake6t3PKZMBRLE96F0Vn0S3sZxCsS7WXw1fBc+OrBeVMc2zvgslkdSzI/C1MflR0mcgGWXxA2c6PiM7xry18731T2qhaZecmCgn0ZmVWqaF5EzzqFwxTRm7p1eA==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hqOHsaScpi37J+bf9aKrn+6UdqR3ICwXjJFTZn99FoU=; b=oMLFRSmGSEaZ3OloWRsRayI4UQEG5sIPLeKXNeQpmeAZWTwZK922Sotfcbpaye3wq6rTPjnZYMh0VLTlyp8zCqFm+mwf8+cOGBaPANUrWYKR8HqPbe93swYwL2TtP0iNEWxKnvhtbSxoEGgtEgIc3yepvCp+cJPVuT+bJxfKEhA=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB3905.eurprd07.prod.outlook.com (52.134.82.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.18; Wed, 13 Nov 2019 16:04:27 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1%7]) with mapi id 15.20.2451.018; Wed, 13 Nov 2019 16:04:27 +0000
From: Mirja Kuehlewind 
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: Yoshifumi Nishida , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
Thread-Index: AQHVlg3D3FuD8rQyOUeITRzrNWkm0aeH0YoAgAD1iACAAEt0gIAAIY8AgAAongA=
Date: Wed, 13 Nov 2019 16:04:27 +0000
Message-ID: <806F03B4-1E47-4AB9-BF49-A395614CADE8@ericsson.com>
References:  <201911131439.xADEd4Kv044222@gndrsh.dnsmgr.net>
In-Reply-To: <201911131439.xADEd4Kv044222@gndrsh.dnsmgr.net>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2001:16b8:2cce:e500:edca:fce4:c950:3b39]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7d94ef45-158d-4fd2-ec0b-08d7685328de
x-ms-traffictypediagnostic: AM0PR07MB3905:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(396003)(366004)(376002)(51914003)(189003)(199004)(11346002)(2906002)(316002)(446003)(6916009)(6512007)(6306002)(256004)(14444005)(86362001)(71200400001)(71190400001)(64756008)(99286004)(2616005)(76116006)(7736002)(66556008)(66476007)(66446008)(102836004)(54906003)(5660300002)(30864003)(476003)(46003)(305945005)(6506007)(53546011)(76176011)(66946007)(81156014)(14454004)(8676002)(36756003)(81166006)(8936002)(486006)(6246003)(561944003)(186003)(478600001)(33656002)(44832011)(4326008)(229853002)(6486002)(25786009)(6436002)(6116002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3905; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: B1/tzNdX4Qqlf9tTJ3xWv9WWM4rhIDEQifexSSeZax7c9GfTVWg7ci9PtAVQMUjpyzEn0lJrsiIT4LirNVtcc+63s8TftBO+ScCSOGz9kiTxTxIKi/SwY7mnMyqk+NuHm387xxizJZmKUIjVncubYAnGKuekxpPl1a3MA7Ndz1uJtEw9jH2PqGb9IkssKMbhcwYTEEPK+mxSfgc925Ez5PsJNxRtisifcOzSGIf/K4TI52RV+OQkTgupwE5Q8RLVC7AXYQkjQ/cJC7rzZa13yufLtGGNC3ijRLDWcVdjDkvKmJQbiYLpw5OgBE/HCWBa5CjztEQCdtkhrGxNTkMfmvPhSP5G9ReDbXlfo6Q4GOjdDjRBbtM8g5jkJ/ca7CXQi6ssPM3hjmtx6pbhIKzssMe+ou0Md+5K/q1GocKuvpPz2AEJK3iwBKKAzxWySXfv
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d94ef45-158d-4fd2-ec0b-08d7685328de
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 16:04:27.2937 (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: I6/CwtVIdG43+rLK5elWntawZrkfMkPwSLKyAQskpAl61M6ryZdD921Il5qxjffyDVx27dnYbSKfmu5UOWeGCzUxU4IpAf3pfrhE3wqgP0M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3905
Archived-At: 
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
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, 13 Nov 2019 16:04:36 -0000

SEkgUm9kLA0KDQpqdXN0IHF1aWNrbHkgb25lIGNvbW1lbnQgb24gdGhpcyBwYXJ0Og0KDQoiW1JX
R10gTWlyamEgaXQgYXBwZWFycyB0aGF0IHRoZSBkZXNpZ24gb2YgQWNjRUNOIGlzIGhlYXZpbHkg
Ymlhc2VkIHRvd2FyZHMgc3VwcG9ydCBmb3IgTDRTLCBnaXZpbmcgdGhhdCBjb3VudGluZyBDRSBp
cyB0aGUgbWFpbiBmZWVkYmFjayBlbGVtZW50LCBhbmQgdGhhdCBMNFMgaXMgZGVzZ2luZWQgdG8g
Y3JlYXRlIG1vcmUgQ0UgbWFya3Mgd2hlbiBpbiB1c2UuICBUaGlzIGlzIG9uZSByZWFzb24gdGhh
dCBTQ0UgcmVqZWN0ZWQgQWNjRUNOIGFzIGEgdmlhYmxlIHNvbHV0aW9uIGZvciBjbG9zaW5nIHRo
ZSBmZWVkYmFjayBsb29wIGluIFNDRSBhdCB0aGUgVENQIGxheWVyLCBpdCBpcyBhY3R1YWxseSBF
Q1QoMSkgbWFyayBjb3VudHMgdGhhdCBuZWVkcyBoaWdoIGZhZGVsaXR5IGZlZWRiYWNrIGFzIENF
IHJhcmVseSBvY2N1cnMgaW4gdGhlIFNDRSBkZXNpZ24gKGl0IGlzIGEgYmFja3N0b3AgZmFpbHVy
ZSBtZWNoYW5zaW0gZm9yIFNDRSB0byByZXRhaW4gRUNOMzE2OCBiZWhhdmlvci4pICBXZSBkbyB1
bmRlcnN0YW5kIHRoYXQgYSBjb3VudCBvZiBFQ1QoMSkgaXMgYXZhbGlhYmxlLCBidXQgdGhhdCBp
dCByZXF1aXJlcyBhIFRDUCBvcHRpb24gdG8gZ2V0IGF0IGl0LiINCg0KQWNjRUNOIGlzIG5vdCAi
Ymlhc2VkIiB0b3dhcmRzIEw0UyAoaXQgd2FzIGRlZmluZWQgYSBsb25nIHRpbWUgYmVmb3JlIEw0
UyB3aXRoIENvbkV4IGFuZCBEQ1RDUCBpbiBtaW5kKSBidXQgaXQgc2ltcGx5IGFsaWducyB3aXRo
IHRoZSBkZWZpbml0aW9uIGFzIGRlZmluZWQgaW4gUkZDMzE2OCwgd2hpY2ggZGVmaW5lcyBFVEMo
MSksIGFzIHRoZSBuYW1lIHNheXMgRUNOLWNhcGFibGUgVHJhbnNwb3J0LCBhcyBhbiBhbHRlcm5h
dGl2ZSB0byBFVEMoMCkgdXNlZCBieSB0aGUgc2VuZGVyLiBTQ0Ugd291bGQgY2hhbmdlIHRoaXMg
dW5kZXJzdGFuZGluZyBjb21wbGV0ZWx5IGJ5IHVzaW5nIHRoZSBFQ1QoMSkgbWFyayBhcyBhbiBh
bHRlcm5hdGl2ZSBjb25nZXN0aW9uIHNpZ25hbCB0byBuZSBzZXQgaW4gdGhlIG5ldHdvcmsuDQoN
ClZhcmlvdXMgc2NoZW1lcyB0byBwcm92aWRlIGZlZWRiYWNrIGhhdmUgYmVlbiBkaXNjdXNzZWQg
Zm9yIEFjY0VDTiBvdmVyIHRoZSB5ZWFycyBhbmQgdGhlIGdyb3VwIGRlY2lkZWQgZmluYWxseSB0
byBvcHRpbWl6ZSBmb3IgdGhlIGNhc2UgdGhhdCBpcyBtb3N0bHkgZGVwbG95ZWQgdG9kYXkgKGlm
IGF0IGFsbCksIHVzZSBvZiBFVEMoMCkgYW5kIENFIG9ubHkuIE5vdGUgdGhhdCBhcyBub3RlZCBi
eSBOZWFsIHJlY2VudGx5IG9uIHRoZSBsaXN0IHRoZSBvcHRpb24gZGVzaWduIGlzIGFsc28gbm90
IG9wdGltYWwgZm9yIEw0UyBhbmQgdXNlIG9mIEVDVCgxKSBhcyBjbGllbnQgc2lnbmFsLCBob3dl
dmVyLCBhcyBJIHJlcGxpZWQgaW4gdGhhdCB0aHJlYWQsIHRoZXJlIGFyZSB3YXlzIHRvIGV4dGVu
dCBBY2NFQ04gaW4gZnV0dXJlIGFuZCBtYXliZSBlLmcuIHByb3ZpZGUgYW4gYWx0ZXJuYXRpdmUg
b3B0aW9uIGRlc2lnbi4NCg0KTWlyamENCg0KDQrvu79PbiAxMy4xMS4xOSwgMTU6MzksICJSb2Ru
ZXkgVy4gR3JpbWVzIiA8NGJvbmVAZ25kcnNoLmRuc21nci5uZXQ+IHdyb3RlOg0KDQogICAgSGVs
bG8gTWlyamEsIFlvc2hpLCBldGMgYWwsDQogICAgDQogICAgU29tZSBjb21tZW50cyBpbiBsaW5l
IChtYXJrZWQgd2l0aCBbUldHXQ0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgUm9kDQogICAgDQog
ICAgPiBIaSBZb3NoaSwNCiAgICA+IA0KICAgID4gc2VlIHNvbWUgY29tbWVudHMgaW4gbGluZSAo
bWFya2VkIHdpdGggW01LXSkuDQogICAgPiANCiAgICA+IE1pcmphDQogICAgPiANCiAgICA+IEZy
b206IFlvc2hpZnVtaSBOaXNoaWRhIDxuc2QuaWV0ZkBnbWFpbC5jb20+DQogICAgPiBEYXRlOiBX
ZWRuZXNkYXksIDEzLiBOb3ZlbWJlciAyMDE5IGF0IDA5OjA5DQogICAgPiBUbzogTWlyamEgS3Vl
aGxld2luZCA8bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+DQogICAgPiBDYzogUGV0ZSBI
ZWlzdCA8cGV0ZUBoZWlzdHAubmV0PiwgInRjcG1AaWV0Zi5vcmciIDx0Y3BtQGlldGYub3JnPg0K
ICAgID4gU3ViamVjdDogUmU6IFt0Y3BtXSBTZWVraW5nIGZlZWRiYWNrIGZvciBkcmFmdC1pZXRm
LXRjcG0tYWNjdXJhdGUtZWNuIGFuZCBkcmFmdC1pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuDQog
ICAgPiANCiAgICA+IEhpIE1pcmphLA0KICAgID4gDQogICAgPiBUaGFua3MgZm9yIHRoZSByZXNw
b25zZS4NCiAgICA+IA0KICAgID4gT24gVHVlLCBOb3YgMTIsIDIwMTkgYXQgODozMCBBTSBNaXJq
YSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTxtYWlsdG86bWlyamEu
a3VlaGxld2luZEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCiAgICA+IFBldGVyLCBJIGRvbid0IHRo
aW5rIHRoZSBBY2NFQ04gZHJhZnQgc2hvdWxkIHNheSBhbnl0aGluZyBhYm91dCB3aGF0IGhhcHBl
bnMgdG8gdGhlIGV4LU5TIGJpdCBpZiBpdCBmYWxscyBiYWNrIHRvIGNsYXNzaWMgRUNOIGJlY2F1
c2UgdGhhdCdzIG91dCBvZiBzY29wZSBvZiB0aGUgZHJhZnQgZGVmaW5pbmcgdGhlIEFjY0VDTiBt
ZWNoYW5pcy4gSG93ZXZlciwgSSBhZ3JlZSB0aGF0IGlzIHdvdWxkIGJlIGF2YWlsYWJsZSBmb3Ig
YW5vdGhlciB1c2UuDQogICAgDQogICAgIFtSV0ddIFBlcmhhcHMgdGhhdCBpcyBhbGwgdGhhdCB3
b3VsZCBuZWVkIHRvIGJlIGFkZGVkPyAgIlRoZSBuZXdseSBhbGxvY2F0ZWQgQUUgYml0IHdvdWxk
IGJlIGF2YWxpYWJsZSBmb3Igb3RoZXIgdXNlcyBzaG91bGQgQWNjRUNOIGZhaWwgdG8gbmVnb3Rp
YXRlLiINCiAgICANCiAgICA+IA0KICAgID4gV2VsbCwgdGhpcyBtaWdodCBiZSBqdXN0IG15IHBl
cnNvbmFsIG9waW5pb24sIGJ1dCB0d28gZHJhZnRzIChkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt
ZWNuIGFuZCBkcmFmdC1ncmltZXMtdGNwbS10Y3BzY2UtMDApIGNsYWltIHRvIG5hbWUgZXgtTlMg
Yml0IGFzIEFFIGFuZCBFU0NFIHdpdGhvdXQgYW55IGV4cGxhbmF0aW9ucyBmb3IgZWFjaCBvdGhl
ci4NCiAgICA+IFRoaXMgbG9va3MgY29uZnVzaW5nIHRvIG1lLg0KICAgID4gDQogICAgPiBbTUtd
IFllcyB0aGF0IGlzIGEgbGl0dGxlIGNvbmZ1c2luZyBidXQgb24gdGhlIG90aGVyIGhhbmQgdGhl
c2UgYXJlIHR3byBkaWZmZXJlbnQgbWVjaGFuaXNtLiBJIHRoaW5rIHdlIGZpcnN0IG5lZWQgdG8g
aGF2ZSBhIGRpc2N1c3Npb24gaWYgdGhlcmUgaXMgaW50ZXJlc3QgaW4gVENQLVNDRSBpbiB0aGUg
Z3JvdXAgYmVmb3JlIHdlIGRlY2lkZSB0byBjaGFuZ2UgYW55dGhpbmcgaW4gdGhlIEFjY0VDTiBk
cmFmdCwgYnV0IEkgZ3Vlc3Mgd2UgZGlzY3VzcyBhbHNvIGZpbmRpbmcgYSBtb3JlIG5ldXRyYWwg
bmFtZSBvciBpZiBhbGxvY2F0ZWQgdW5kZXIgdGhpcyBuYW1lIHRoZSBUQ1AtU0NFIHNob3VsZCBh
bG9zIHVzZSBpdCAoYXMgdGhleSBhcmUgY3VycmVudGx5IGNhbGwgaXQgTlMgYml0KS4NCiAgICAN
CiAgICAgW1JXR10gVENQLVNDRSBjYWxscyB0aGlzIGJpdCBFU0NFIChFY2hvIFNDRSkgZHVlIHRv
IGl0cyBwYXJhbGxlbHMgd2l0aCBDRS9FQ0UuICBJIGhhdmUgdHJpZWQgdG8gbWluaW1pemUgcmVm
ZXJlbnNlIHRvIE5TIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQogICAgDQog
ICAgPiBZb3NoaSwgSSBiZWxpZXZlIHlvdSBwb2ludCBBMSBiZWxvdyB3YXMgZGVjaWRlZCBpbiB0
aGUgZ3JvdXAgYWxyZWFkeSBhdCBhZG9wdGlvbiB0aW1lIGFzIHRoZSBiaXQgd2FzIHVzZWQgZnJv
bSB0aGUgYmVnaW5uaW5nIHdpdGggYWxsIHBvc3NpYmxlIEFjY0VDTiBtZWNoYW5pc21zLiBIb3dl
dmVyLCBpZiBhbmQgaG93IGl0IHNob3VsZCBiZSByZWdpc3RlcmVkIHdpdGggSUFOQSBpcyBhIGRp
ZmZlcmVudCBxdWVzdGlvbi4gVG8gbXkgbWVtb3J5IHRoZXJlIHdhcyBzdXBwb3J0IHRvIHJlZ2lz
dGVyZWQgZXZlbiB0aG91Z2ggaXQncyBleHBlcmltZW50YWwgYmVjYXVzZSBOUyB3YXMgcmVnaXN0
ZXJlZCBiYXNlZCBvbiBhbiBleHBlcmltZW50YWwgUkZDIGFuZCBoYXZpbmcgdGhpcyByZWdpc3Ry
eSBzYXlpbmcgc29tZXRoaW5nIGFib3V0IHRoaXMgc3BlY2lmaWMgYml0IHdoaWxlIG5vdCBub3Rp
bmcgdGhpcyBleHBlcmltZW50IHRoZXJlIHNlZW1zIGNvbmZ1c2luZy9hZ2FpbnN0IHRoZSBpZGVh
IG9mIGEgcmVnaXN0cnkuIFdoYXQgd2UgbWF5YmUgY291bGQgZGlzY3VzcyBpcyBpZiB3ZSB3YW50
IHRvIHJlbmFtZSB0aGUgYml0IGluIHRoZSByZWdpc3RyeSAodG8gQUUpIG9yIHJhdGhlciBqdXN0
IGFkZCBhIG5vdGUgYWJvdXQgdGhpcyBleHBlcmltZW50LiBMYXN0IHRpbWUgdGhlcmUgd2FzIHN1
cHBvcnQgdG8gZ2l2ZSBpdCBhIHByb3BlciBuYW1lIHdoaWNoIHdlIGZvbGxvd2VkIGFzIGF1dGhv
cnMgYnV0IG9mIGNvdXJzZSBpdCdzIHRoZSB3b3JraW5nIGdyb3VwIHRvIGRlY2lkZSBoZXJlLg0K
ICAgID4gDQogICAgPiBJIHNlZS4gSSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgdG8gc2VsZWN0IG9u
ZSBiZWZvcmUgV0dMQyB1bmxlc3Mgd2Ugc2VlIHNvbGlkIHJlYXNvbiB0aGF0IHRoaXMgaXMgbm90
IG5lY2Vzc2FyeS4NCiAgICA+IA0KICAgID4gW01LXSBJIGRvbj90IHNlZSBhIGRlcGVuZGVuY3kg
b24gVENQLVNDRSBleGNlcHQgdGhlIG5hbWUuIEhvd2V2ZXIgZGlzY3Vzc2lvbiBvbiBUQ1AtU0NF
IGp1c3Qgc3RhcnRlZCBhbmQgSSBkb24/dCB3YW50IHRvIGZ1cnRoZXIgZGVsYXkgQWNjRUNOIHdo
aWNoIGlzIGFscmVhZHkgc3RhYmxlIGZvciBhIGxvbmcgdGltZS4gSWYgaXQ/cyBqdXN0IGFib3V0
IGNoYW5naW5nIGEgbmFtZSB3aXRob3V0IGFueSB0ZWNobmljYWwgaW1wYWN0IHRoYXQgY2FuIGJl
IGRvbmUgYW55IHRpbWUgaW4gcHJvY2VzcyAoYmVmb3JlIGZpbmFsIHB1YmxpY2F0aW9uKS4NCiAg
ICA+IA0KICAgID4gQWRkaW5nIGEgbm90ZSBhYm91dCB0aGUgZXhwZXJpbWVudCBsb29rcyBhIHJl
bGF0aXZlbHkgZWFzaWVyIHBhdGggdG8gbWUgcmF0aGVyIHRoYW4gYWxsb2NhdGluZyBhIGJpdCBm
b3IgZXhwZXJpbWVudGFsIGRvYy4gQnV0LCBpZiB3ZSBhZG9wdCBTQ0UsIHdlJ2xsIG5lZWQgdG8g
dXBkYXRlIHRoZSBkZXNjcmlwdGlvbi4NCiAgICA+IE9yLCBjcmVhdGluZyBhIHNtYWxsIFBTIGRv
YyB0byBhbGxvY2F0ZSBhIGJpdCBjb3VsZCBiZSBhbiBpZGVhIGFzIHdlbGwuDQogICAgPiANCiAg
ICA+IFtNS10gVGhhdD9zIHNvbWV0aGluZyB3ZSBzaG91bGQgZGlzY3VzcyBub3cuDQogICAgPiAN
CiAgICA+IA0KICAgID4gUmVnYXJkaW5nIHBvaW50IEEyLCB0aGlzIHdhcyBhbHNvIGRpc2N1c3Nl
ZCBhdCBsZW5ndGggaW4gdGhlIGdyb3VwLiBUaGVyZSBhcmUgZGlmZmVyZW50IHdheSBvZiBmYWls
aW5nLiBPbmUgaXMsIGFzIHdlIHNhdyBmb3IgTlMsIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBkZXBs
b3ltZW50IGF0IGFsbCBhbmQgd2UgY2FuIHNpbXBseSByZWFzc2lnbi4gQW5vdGhlciBpdCB0aGF0
IGlzIGdldHMgZGVwbG95IGJ1dCBkb2Vzbid0IHdvcmsgYXMgZXhwZWN0ZWQsIGhvd2V2ZXIsIGlu
IHRoaXMgY2FzZSB0aGVyZSBhcmUgc3RpbGwgd2F5cyB0byBleHRlbmQvYWx0ZXIgQWNjRUNOIGJ5
IG5lZ290aWF0aW9uIGR1cmluZyB0aGUgaGFuZHNoYWtlLiBUaGlzIGlzIGFsc28gZGlzY3Vzc2Vk
IGluIHRoZSBkcmFmdCBhbmQgdGhlIG1heW9yIHJlYXNvbiBmb3IgaGF2aW5nIHRoZSBoYW5kc2hh
a2UgbmVnb3RpYXRpb24gaW5zdGVhZCBvZiBqdXN0IHVzaW5nIHRoZSBiaXQgKGFzIHNvbWUgb3Ro
ZXIgcHJvcG9zYWwgZG8pLiBJZiB0aGF0IGlzIG5vdCBnb29kIGVub3VnaCwgSSdtIGFmcmFpZCB3
ZSB3b24ndCBiZSBhYmxlIHRvIGV2ZXIgdXNlIGFueSBvZiB0aGUgcmVzZXJ2ZWQgYml0cyBpbiB0
aGUgVENQIGhhbmRzaGFrZS4NCiAgICANCiAgICAgW1JXR10gSSBiZWxpZXZlIG9uZSBvZiB0aGUg
bWFqb3IgcmVhc29ucyB0aGF0IHRoZSBuZWdvdGlhdGlvbiBNVVNUIG9jY3VyIGJlZm9yZSBkb2lu
ZyBBY2NFQ04gaXMgdGhhdCBpdCByZWRpZmluZXMgdGhlIG1lYW5pbmcgb2YgdGhlIENFIGJpdCBp
biBJUCAodGhpcyBpcyBhbiBhcmd1YWJsZSBwb2ludCwgSSB1bmRlcnN0YW5kIGl0IGp1c3QgY291
bnRzIHRoZW0gYW5kIGZlZWRzIGJhY2sgaG93IG1hbnkgb2NjdXJlZCwgYnV0IHRoaXMgaXMgbWFp
bmx5IHNvIHRoYXQgTDRTIGNhbiB1c2UgdGhlbSBpbiBhIGhpZ2ggZmFkZWxpdHkgbWFya2luZyBz
Y2hlbWUpLCBhbmQgRUNFIGJpdCBpbiBUQ1AsIEkgZmluZCB0aGF0IHJlZGlmaW5pdGlvbiBvZiBh
biBJUCBsYXllciBiaXQgYmFzZWQgb24gYSBUQ1AgbGF5ZXIgbmVnb3RhdGlvbiBwcm9ibGVtYXRp
Yywgc2VlIG1vcmUgYmVsb3cuDQogICAgDQogICAgPiANCiAgICA+IE9LLg0KICAgID4gDQogICAg
PiANCiAgICA+IFJlZ2FyZGluZyB5b3VyIHBvaW50IEIgYmVsb3cgSSBkb24ndCBzZWUgYW55IGRl
cGVuZGVuY3kgRlJPTSBBY2NFQ04gdG8gYW55IG9mIHRoZXNlIHByb3Bvc2Fscy4gWWVzLCBtdWx0
aXBsZSBwcm9wb3NhbCByZXBseSBvbiBBY2NFQ04sIHdoaWNoIGl0IGdyZWF0IGJlY2F1c2UgaXQg
c2hvdyB0aGF0IGl0IGlzIHVzZWZ1bCwgYnV0IHRoYXQgb25seSBtZWFucyB0aGF0IHRoZSBwcm9w
b3NhbHMgaGF2ZSBhIGRlcGVuZGVuY3kgVE8gQWNjRUNOIGFuZCBub3QgdGhlIG90aGVyIHdheSBh
cm91bmQuIEZvciBtZSB0aGlzIGlzIGFub3RoZXIgcmVhc29uIHRvIHByb2NlZWQgd2l0aCBBY2NF
Q04gcXVpY2tseS4NCiAgICA+IA0KICAgID4gT0suIGp1c3QgZm9yIGNsYXJpZmljYXRpb24uDQog
ICAgPiBGb3IgZXhhbXBsZSwgIGluIG5lYXIgZnV0dXJlLCBzb21lIG1pZGRsZWJveGVzIG1heSBp
bXBsZW1lbnQgYSBtYXJraW5nIGFsZ29yaXRobSB3aGljaCBkZXBlbmRzIG9uIEFjY0VDTiwgd2hp
bGUgb3RoZXIgbWlkZGxlYm94ZXMgbWF5IGltcGxlbWVudCBhIG1hcmtpbmcgYWxnb3JpdGhtIHdo
aWNoIGRvZXNuJ3QgZGVwZW5kIG9uIEFjY0VDTi4NCiAgICA+IFRoZXNlIG1pZGRsZWJveGVzIGhh
cHBlbiB0byBiZSBvbiB0aGUgc2FtZSBwYXRoLCB0aGVuIHRoZSBwYWNrZXQgbWFya2luZyByZXN1
bHRzIHdpbGwgYmUgYSBtaXggb2YgdHdvIGFsZ29yaXRobXMgYXMgbWlkZGxlYm94ZXMgY2Fubm90
IGlkZW50aWZ5IHdoaWNoIFRDUCBmbG93cyB1c2UgQWNjRUNOIG9yIG5vdC4NCiAgICA+IEJ1dCwg
QWNjRUNOIGlzIGp1c3QgZGVzaWduZWQgdG8gcmVwb3J0IHdoYXQgaXQgcmVjZWl2ZWQgd2hldGhl
ciB0aGV5IGFyZSBtaXhlZCByZXN1bHRzIG9yIG5vdC4gSGVuY2UsIHlvdSBzYXkgdGhhdCBBY2NF
Q04gaXMgaW5kZXBlbmRlbnQgZnJvbSB0aGVzZSBwb3RlbnRpYWwgY29uZmxpY3RzLiBDb3JyZWN0
Pw0KICAgIA0KICAgICBbUldHXSBZb3NoaSBJIGFncmVlIHRoYXQgdGhlcmUgYXJlIGNvbmNlcm5z
IGhlcmUgdGhhdCBzaG91bGQgYmUgbG9va2VkIGF0IHZlcnkgY2FyZWZ1bGx5LCB0aGUgRUNUKDEp
IGJpdCB1c2VkIHRvIGNsYXNzaWZ5IEw0UyB0cmFmZmljIGlzIHRoZSBjcnV4IG9mIHRoYXQgaXNz
dWUuDQogICAgDQogICAgPiBbTUtdIENvcnJlY3QuIEFjY0VDTiByZWFsbHkgaXMgb25seSB0aGUg
ZmVlZGJhY2sgc2lnbmFsIGFuZCBJIHRoaW5rIEw0UyB3b3VsZCBlLmcuIGFkZHJlc3Mgd2hhdCB5
b3UgZGVzY3JpYmUgYWJvdmUgKGFzIG9uZSBleGFtcGxlKS4gQnV0IHdlIHJlYWxseSB0cmllZCB0
byBkZS1jb3VwbGUgdGhhdCBiZWNhdXNlIGEpIGFzIGl0IHR1cm5lZCBvdXQgaXMgd2FzIGFscmVh
ZHkgbm90IGdyZWF0IHRvIGhhdmUgdGhlc2UgdGhpbmdzIG1peGVkIHVwIGluIG9uZSBSRkMgZm9y
IGNsYXNzaWMgRUNOIGFuZCBiKSBpdD9zIGFsc28gdXNlZnVsIGZvciBvdGhlciB0aGluZ3MgKHRo
YXQgZG9uP3QpIGNoYW5nZSB0aGUgY29uZ2VzdGlvbiByZXNwb25zZSwgZS5nLiBFQ04rKy4NCiAg
ICANCiAgICAgW1JXR10gTWlyamEgaXQgYXBwZWFycyB0aGF0IHRoZSBkZXNpZ24gb2YgQWNjRUNO
IGlzIGhlYXZpbHkgYmlhc2VkIHRvd2FyZHMgc3VwcG9ydCBmb3IgTDRTLCBnaXZpbmcgdGhhdCBj
b3VudGluZyBDRSBpcyB0aGUgbWFpbiBmZWVkYmFjayBlbGVtZW50LCBhbmQgdGhhdCBMNFMgaXMg
ZGVzZ2luZWQgdG8gY3JlYXRlIG1vcmUgQ0UgbWFya3Mgd2hlbiBpbiB1c2UuICBUaGlzIGlzIG9u
ZSByZWFzb24gdGhhdCBTQ0UgcmVqZWN0ZWQgQWNjRUNOIGFzIGEgdmlhYmxlIHNvbHV0aW9uIGZv
ciBjbG9zaW5nIHRoZSBmZWVkYmFjayBsb29wIGluIFNDRSBhdCB0aGUgVENQIGxheWVyLCBpdCBp
cyBhY3R1YWxseSBFQ1QoMSkgbWFyayBjb3VudHMgdGhhdCBuZWVkcyBoaWdoIGZhZGVsaXR5IGZl
ZWRiYWNrIGFzIENFIHJhcmVseSBvY2N1cnMgaW4gdGhlIFNDRSBkZXNpZ24gKGl0IGlzIGEgYmFj
a3N0b3AgZmFpbHVyZSBtZWNoYW5zaW0gZm9yIFNDRSB0byByZXRhaW4gRUNOMzE2OCBiZWhhdmlv
ci4pICBXZSBkbyB1bmRlcnN0YW5kIHRoYXQgYSBjb3VudCBvZiBFQ1QoMSkgaXMgYXZhbGlhYmxl
LCBidXQgdGhhdCBpdCByZXF1aXJlcyBhIFRDUCBvcHRpb24gdG8gZ2V0IGF0IGl0Lg0KICAgIA0K
ICAgID4gLS0NCiAgICA+IFlvc2hpDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAg
ICA+IA0KICAgID4gT24gMDguMTEuMTksIDA5OjIzLCAidGNwbSBvbiBiZWhhbGYgb2YgUGV0ZSBI
ZWlzdCIgPHRjcG0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3Jn
PiBvbiBiZWhhbGYgb2YgcGV0ZUBoZWlzdHAubmV0PG1haWx0bzpwZXRlQGhlaXN0cC5uZXQ+PiB3
cm90ZToNCiAgICA+IA0KICAgID4gICAgIEhpLA0KICAgID4gDQogICAgPiAgICAgUmVnYXJkaW5n
IHBvaW50cyBBMSBhbmQgQiBvdmVyYWxsLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgdG8g
dGhlIEFjY0VDTiBkcmFmdCBzb21lIGxhbmd1YWdlIHN1Y2ggdGhhdCB3aGVuIGl0IGZhbGxzIGJh
Y2sgdG8gUkZDIDMxNjggRUNOLCB0aGUgTlMgYml0IGlzIHN0aWxsIGF2YWlsYWJsZSBmb3Igb3Ro
ZXIgZXhwZXJpbWVudHM/IFRoYXQgd2F5IHRoZSBiaXQgY291bGQgc3RpbGwgYmUgdXNlZCBieSBT
Q0UsIGV2ZW4gaWYgQWNjRUNOIGJlY29tZXMgYSBwcm9wb3NlZCBzdGFuZGFyZC4NCiAgICA+IA0K
ICAgID4gICAgID4gRnJvbTogWW9zaGlmdW1pIE5pc2hpZGEgPG5zZC5pZXRmQGdtYWlsLmNvbTxt
YWlsdG86bnNkLmlldGZAZ21haWwuY29tPj4NCiAgICA+ICAgICA+IERhdGU6IFRodSwgNyBOb3Yg
MjAxOSAxMTowNDozOCAtMDgwMA0KICAgID4gICAgID4NCiAgICA+ICAgICA+IEhpLA0KICAgID4g
ICAgID4gZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbiBhbmQgZHJhZnQtaWV0Zi10Y3BtLWdl
bmVyYWxpemVkLWVjbiBoYXZlIGJlZW4NCiAgICA+ICAgICA+IGRpc2N1c3NlZCBmb3IgYSB3aGls
ZS4NCiAgICA+ICAgICA+IHRjcG0gY2hhaXJzIGFyZSBub3cgdGhpbmtpbmcgdGhhdCB0aGV5IGFy
ZSBnZXR0aW5nIG1hdHVyZWQgYW5kIGJlY29taW5nDQogICAgPiAgICAgPiByZWFkeSBmb3IgV0dM
QyAuDQogICAgPiAgICAgPiBIb3dldmVyLCB3ZSBhbHNvIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFs
IHBvaW50cyB0byBiZSBjbGFyaWZpZWQgYmVmb3JlaGFuZC4NCiAgICA+ICAgICA+DQogICAgPiAg
ICAgPiBJbiBvcmRlciB0byBwcm9jZWVkIHRoZSBjdXJyZW50IHNpdHVhdGlvbiwgd2Ugd291bGQg
bGlrZSB0byBhc2sgdGhlDQogICAgPiAgICAgPiBjb21tdW5pdHkgdG8gZ2l2ZSBzb21lIGZlZWRi
YWNrIG9uIHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KICAgID4gICAgID4gV2Ugd2lsbCBoaWdobHkg
YXBwcmVjaWF0ZSB5b3VyIGlucHV0cy4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBBOiBBbGxv
Y2F0aW5nIGJpdCA3IGZvciBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQogICAgPiAgICAg
PiAgVGhlIGRyYWZ0IHJlcXVlc3RzIHRoZSBhbGxvY2F0aW9uIGZvciBiaXQgNyBpbiBUQ1AgaGVh
ZGVyIChleCBOUyBiaXQpDQogICAgPiAgICAgPiBmb3IgdGhpcyBwcm9wb3NhbC4NCiAgICA+ICAg
ICA+ICBIb3dldmVyLCB0aGUgaW50ZW5kZWQgc3RhdHVzIG9mIHRoZSBkcmFmdCBpcyBleHBlcmlt
ZW50YWwsIHdoaWNoIG1heSBub3QNCiAgICA+ICAgICA+IGJlIHdlbGwgYWxpZ25lZCB3aXRoIHRo
ZSBkZXNjcmlwdGlvbiBpbiBSRkMyNzgwLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+IFRoZSBj
aGFpcnMgd291bGQgbGlrZSB0byBjaGVjayB0aGUgZm9sbG93aW5nIHBvaW50cy4NCiAgICA+ICAg
ICA+ICAgICBBMTogSWYgd2UgY2FuIGhhdmUgYSBjb25zZW5zdXMgdG8gYWxsb2NhdGUgYml0IDcg
Zm9yIHRoaXMNCiAgICA+ICAgICA+IGV4cGVyaW1lbnRhbCBkcmFmdC4gT3IsIGlmIHRoZXJlIGlz
IGFueSBvdGhlciB3YXlzIHRvIGFsbG93IHRoZSBhbGxvY2F0aW9uDQogICAgPiAgICAgPiAoZS5n
LiB1c2luZyBvdGhlciBkb2N1bWVudHMpDQogICAgPiAgICAgPiAgICAgQTI6IGlmIHdlIGRlY2lk
ZSB0byBhbGxvY2F0ZSB0aGUgYml0LCB3aGF0IHdlIHNob3VsZCBkbyB3aGVuIHRoZQ0KICAgID4g
ICAgID4gZXhwZXJpbWVudCBmYWlscy4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBCOiBPdmVy
bGFwcyB3aXRoIHNvbWUgY29uZ2VzdGlvbiBleHBlcmllbmNlZCBwcm9wb3NhbHMNCiAgICA+ICAg
ICA+ICBJdCBzZWVtcyB0aGF0IHNvbWUgY29uZ2VzdGlvbiBleHBlcmllbmNlZCBwcm9wb3NhbHMN
CiAgICA+ICAgICA+IChkcmFmdC1ncmltZXMtdGNwbS10Y3BzY2UNCiAgICA+ICAgICA+IGFuZCBk
cmFmdC1tb3J0b24tdHN2d2ctc2NlKSBoYXZlIHNpbWlsYXJpdGllcyB3aXRoIHRoZXNlIGRyYWZ0
cy4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGNo
ZWNrIHRoZSBmb2xsb3dpbmcgcG9pbnRzIGZvciB0aGlzLg0KICAgID4gICAgID4gICAgQjE6IFRo
ZSB0d28gcHJvcG9zYWxzIHdvbid0IGNvbmZsaWN0IGVhY2ggb3RoZXIuIFdlIGNhbiBkaXNjdXNz
IGFuZA0KICAgID4gICAgID4gcHJvY2VlZCB0aGVzZSBwcm9wb3NhbHMgc2VwYXJhdGVseSB3aXRo
b3V0IGFueSBwb3RlbnRpYWwgcmlza3MuDQogICAgPiAgICAgPiAgICBCMjogaXQgc2VlbXMgdGhh
dCBTQ0UgYW5kIEw0UyBtYXkgaGF2ZSBzb21lIGNvbmZsaWN0cywgYnV0IHRoaXMgd2lsbA0KICAg
ID4gICAgID4gbm90IGFmZmVjdCB0aGUgZGlzY3Vzc2lvbnMgZm9yIEFjY0VDTiBhbmQgRUNOKysu
DQogICAgPiAgICAgPiAgICBCMzogaWYgd2UgYWxsb2NhdGUgdGhlIGJpdCA3IGZvciBBY2NFQ04s
IGl0IGlzIHN0aWxsIGFsbG93ZWQgZm9yIFNDRQ0KICAgID4gICAgID4gcHJvcG9zYWxzIHRvIHVz
ZSB0aGUgYml0IG9yIGl0IHdpbGwgYmUgcHJvaGliaXRlZC4NCiAgICA+ICAgICA+DQogICAgPiAg
ICAgPiAgQlRXLCBqdXN0IGluIGNhc2UuIHBsZWFzZSBhdm9pZCBpbml0aWF0aW5nIHRlY2huaWNh
bCBkaXNjdXNzaW9ucyBhbmQgdHJ5DQogICAgPiAgICAgPiB0byBkaXNjdXNzIGhvdyB0byBwcm9j
ZWVkIHRoZSBkcmFmdHMgaW4gdGhpcyB0aHJlYWQuDQogICAgPiAgICAgPiAtLQ0KICAgID4gICAg
ID4gWW9zaGkgb24gYmVoYWxmIG9mIHRjcG0gY2hhaXJzDQogICAgPiANCiAgICA+ICAgICBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgIHRj
cG0gbWFpbGluZyBsaXN0DQogICAgPiAgICAgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRm
Lm9yZz4NCiAgICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rj
cG0NCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KICAgID4gdGNwbSBtYWlsaW5nIGxpc3QNCiAgICA+IHRjcG1AaWV0
Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K
ICAgIA0KICAgIC0tIA0KICAgIFJvZCBHcmltZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcmdyaW1lc0BmcmVlYnNkLm9yZw0KICAgIA0KDQo=


From nobody Wed Nov 13 08:16:18 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 0CA1F120818; Wed, 13 Nov 2019 08:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level: 
X-Spam-Status: No, score=-2.688 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=PTm06vPv; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=h+ur1XTM
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 xeR0ltv_gePi; Wed, 13 Nov 2019 08:16:05 -0800 (PST)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 24E8E12013C; Wed, 13 Nov 2019 08:16:04 -0800 (PST)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xADGEbff020764; Wed, 13 Nov 2019 11:15:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=LBLYQgX1Yfj5UOBk+s8rBu+A5Ras99QqXa78/bhHvhs=; b=PTm06vPvdIEzeFkE1SWFlOw9Dqt81oeujkF0qZiyBy4Ym/bdh7quFDRWP47BMusb43rs N5knXHUtAmQm/muT1Z5z8vpUvnNNWWoDr/38yySMyPtOskWQTOVTgbwHhhL6tXaBH/sX crRKy+CryW0twMjARsFE5m3DuHAvdqCtCoyMFnIxYLfKy2vvLZBUWgLg9n4HequIKkgP x0/myZE0Seva5D5hfUVbXKp7YlQUm3mmpN4rqGSNhcVcvBUPXLWHqrvQi0lvNEKbneEp ffmJ7NiF5blFAs48FXyr8zYyHO0PhUdTE2EShu+/ti1jkBN8zgqwRu3bB8UoHvJACpFv zA== 
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2w7ppw02s1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Nov 2019 11:15:05 -0500
Received: from pps.filterd (m0090351.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xADFw3NV162280; Wed, 13 Nov 2019 11:15:04 -0500
Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2050.outbound.protection.outlook.com [104.47.49.50]) by mx0b-00154901.pphosted.com with ESMTP id 2w8fqp67u8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Nov 2019 11:15:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jsNAwMnprWBdXsiHFKdPqvmF9mzU+LpiY5zfhVbaycDZxyMwukYch2jZKvzyqinxVY143lryV6lM6PMvWdCMuers5Li7j6I8I1j5vXSqlpMoIbV06dZYVdsEd6X0ARhrxxFq0ehn9m+d5gAczYnYFSzNJhzqpjd/l0Nkg9E1reE3i9DrrC23eMGnuq7D7JzKIy/ntIwDaSd/8igQ9VZZ416A7gVnTLzCTTwuVMk+CveQWjWR+OV1AaAD82Zrp5q5GZeq5P4gOkV3XCBPtK4ZRP9W5WOxmNxh3el4ywT0jgaKRLfV+uMs9ddv6wN0BtwvsryoHUQdpy0vrOO42TVJzw==
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=LBLYQgX1Yfj5UOBk+s8rBu+A5Ras99QqXa78/bhHvhs=; b=OUpVdB7XU+/vS71sMdWyzkqwLuFkg87d+mxudXHG86colshdHAvs794Cul7AI9hmK2Vt+zv6AK47LrEPzPbSWjYkhFoxzgiNAqDAk9tfTCU16bhXX09xNjDpPG3qQxW/ePtCK1+37My8C+1B5OFLBlsqi834SSC1TVgY93XzT4+1nUgQr6dTw0Nt6Rg+5YUfX1vZOoTqO8h1tCeUde+lSYi9uKtnrWbnN82dbiHxcE7Z+DBwrVpV88vvDqtV7NS0EHye4VDFYVZJrNLMv+hH2EXZx3P7N2snjDkEEweLF3gy82MfFMPV0tYNfZZTjFB2obe1xHwoko3djx8S5xcmqw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com;  s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LBLYQgX1Yfj5UOBk+s8rBu+A5Ras99QqXa78/bhHvhs=; b=h+ur1XTMyTC23dcq+QTTtQHuy61x7nNr9VqtswpQxTk50dzMZsIXb0BO+Qj0kU4N1OAUDqNUWELWXUeV9bFxjyEej/nWoxgFeK5P7NRtXdieF+wC6DsOKffR4KN50btpLlqZ/ygRJEeEHNyzFk9R23jShyxrG0Gtl2CHW7AE7w8=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB4061.namprd19.prod.outlook.com (10.141.117.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Wed, 13 Nov 2019 16:15:02 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2430.027; Wed, 13 Nov 2019 16:15:02 +0000
From: "Black, David" 
To: Bob Briscoe , "Scharf, Michael" , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "Black, David" 
Thread-Topic: "David's proposal" for cc class terms (was RE: [tsvwg] [tcpm] L4S status tracking)
Thread-Index: AdWaPX142G8KbCxMRMOy1FLEbuDI0g==
Date: Wed, 13 Nov 2019 16:15:02 +0000
Message-ID: 
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-11-13T16:15:00.8999460Z; 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: [66.170.99.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e36a1013-0ee6-44c2-18ae-08d76854a35c
x-ms-traffictypediagnostic: MN2PR19MB4061:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(366004)(396003)(39860400002)(7502003)(54094003)(189003)(199004)(8936002)(8676002)(81166006)(81156014)(66946007)(110136005)(606006)(54906003)(2906002)(99286004)(71190400001)(71200400001)(256004)(14444005)(786003)(66066001)(316002)(74316002)(486006)(476003)(66476007)(107886003)(4326008)(52536014)(5660300002)(7736002)(53546011)(102836004)(25786009)(966005)(6506007)(26005)(7696005)(6436002)(86362001)(14454004)(236005)(6116002)(3846002)(790700001)(64756008)(66556008)(66446008)(66574012)(478600001)(6306002)(76116006)(561944003)(186003)(54896002)(9686003)(55016002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB4061; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gZcutgzFx8kriWt+JpKd7+8f+vbCw8wPYeR9eRZJMGGOgoKfXm7bUzLUXlnXPxcCcnsS9rbaIXV2tT1ZvmCTgxObpZL7pHB42k1sdKUM6UUlqCLren0b3AIIC7wrYJ6VMYe2Tuztr3ZBwF5lEUM3xz4AXuQWUsz+Uz/7G6bf4vd9bYVNUsGYdEARmOdAZxyXPoWaLlwPHI4rEkny7ahjUQVqeIvUGzDnCZeon9OPUIdOHbRW4h5jXcMCeSTzOwueB5jKzNZy6NQHR/kdENZAj+EPtUUzO/B/DsZWQgkKJp7mEEn4P8dLayinu1J31J3o7ut2pSGwq4iQbmHoOFy3rCJab1CazamvX1ZGiUhGbEvF3rUCTBK9t4wvJ1gJ0DuNdWrxwzNR5texbotj4iQinNVr4HX61Q/vx22Lj9uz7+l2QT9ovT9k3j2BZHQOF3So
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB4045EAFC55061858895E2F0983760MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e36a1013-0ee6-44c2-18ae-08d76854a35c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 16:15:02.1008 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tKfSjbgT4wgzngSwxxbt+Lg4x7OP+odHsII4LsKiOWTtvBlnGnICo5eZqHB/uAyCfAtv5qhn6kuCJIYQA3HUBA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB4061
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-13_04:2019-11-13,2019-11-13 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 spamscore=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911130144
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 suspectscore=0 adultscore=0 mlxscore=0 impostorscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911130145
Archived-At: 
Subject: [tcpm] "David's proposal" for cc class terms (was RE: [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: Wed, 13 Nov 2019 16:16:09 -0000

--_000_MN2PR19MB4045EAFC55061858895E2F0983760MN2PR19MB4045namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In more detail than I explained earlier: in this forum

We are dealing with two classes of congestion controls.  For lack of better=
 terms the following class names are based on what the transport protocol t=
hroughput is proportional to where 'p' is the loss and/or congestion markin=
g probability:
               - 1/sqrt(p)-class congestion controls: Includes most existin=
g TCP congestion control algorithms, e.g., NewReno, CUBIC.
               - 1/p-class congestion controls: Includes DCTCP congestion c=
ontrol.
Keep in mind that p is a probability that is usually << 1 when expressed as=
 a decimal, e.g., p=3D0.01 represents a 1% loss/marking rate.

Thanks, --David

From: tsvwg  On Behalf Of Bob Briscoe
Sent: Wednesday, November 13, 2019 5:00 AM
To: Scharf, Michael; Wesley Eddy; Rodney W. Grimes
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] [tcpm] L4S status tracking


[EXTERNAL EMAIL]
Michael,

I see the problem. Nearly all the occurrences of 'Classic TCP' are in the a=
ppendix that was written v early on, when the focus was only TCP. That text=
 was not written by me, and I haven't got round to editing it for consisten=
cy. However, there are 4 occurrences of "'Classic' TCP" in the abstract and=
 intro, which I will also fix.

Can you say which "David's proposal" you mean please?


Bob
On 11/11/2019 23:10, Scharf, Michael wrote:
OK, so we seem to make some progress at least regarding the term 'classic' =
TCP. As mentioned before, I personally would find the term 'Classic' QUIC v=
ery confusing and you cannot avoid that if you talk about 'Classic' TCP, IM=
HO. So, it seems better to avoid that terminology for all transport protoco=
ls. For the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of th=
e terms 'classic' and 'TCP' back-to-back is used 11 times as far as I can s=
ee.

Regarding congestion control, I'd like to emphasize that David's proposal w=
ould also work well for me, i.e., characterizing the congestion control by =
functional properties. This avoids all issues regarding whether something w=
ill supersede something else (including the issue that EXP is just an exper=
iment that won't update or replace any PS document).

Michael

From: Bob Briscoe 
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael ; Wesley Eddy ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,
On 07/11/2019 08:11, Scharf, Michael wrote:
... and just to show that _my_ concern would be trivial to address by small=
 editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an i=
ncremental migration path so that normal TCP traffic classified in the 'Cla=
ssic' service of L4S will be no worse off" would already work for me.  It j=
ust takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service cla=
ss (and, e.g., "normal" sounds better to me), but in the context of a servi=
ce class, "classic" could actually work for me, if TSVWG really wants that =
name with strong consensus. I don't care how about names for DiffSe^D^D^D^D=
^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whateve=
r else is done in the fast path of a router to implement low latency servic=
e.

I only object to specific terminology such as 'Classic' TCP or 'Classic' co=
ngestion control because I don't think that 'classic' is a proper character=
ization for TCPM standards or TCP/IP stack behavior not aligned with whatev=
er L4S believes the bright future shall be.
I thought I had already agreed to remove 'TCP' from all instances of 'Class=
ic TCP traffic' etc, and that I hadn't intended to include 'TCP' in the fir=
st place. Because it's the congestion controls that are relevant in L4S dra=
fts, not the protocols.



Bob



Whether such small rewording address fully the concerns from others may be =
a different question.

Michael



From: Wesley Eddy 
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael ; Bob Briscoe ; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
Cc: tsvwg@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration pat=
h so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with th=
e term "Classic" for TCP and TCPM-specified congestion control when more th=
an 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all=
 context of TCP and congestion control (as far as it is owned by TCPM), inc=
luding the reference above. BTW, "normal" as suggested would also work for =
me. So, you have plenty of options for other terms.




If Dave+Michael's suggestion of replacing "classic" with "normal" is agreab=
le to others, this seems like a good way forward to me.  It should be easy =
enough to explain in other SDOs that classic and normal mean the same thing=
, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negativ=
e connotations to it.  However, for the sake of working group progress, I t=
hink we just need to pick something that seems the least terrible and agree=
 to move on.)






--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/

--_000_MN2PR19MB4045EAFC55061858895E2F0983760MN2PR19MB4045namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











In more detail than I =
explained earlier: in this forum


 


We are dealing with tw=
o classes of congestion controls.  For lack of better terms the follow=
ing class names are based on what the transport protocol throughput is prop=
ortional to where ‘p’ is the loss and/or
 congestion marking probability:


   &nbs=
p;           - 1/sqrt(p)-=
class congestion controls: Includes most existing TCP congestion control al=
gorithms, e.g., NewReno, CUBIC.


   &nbs=
p;           - 1/p-class =
congestion controls: Includes DCTCP congestion control.

Keep in mind that p is=
 a probability that is usually << 1 when expressed as a decimal, e.g.=
, p=3D0.01 represents a 1% loss/marking rate.


 




Thanks, --David




 








From:=
 tsvwg <tsvwg-bounces@ietf.org>
On Behalf Of Bob Briscoe

Sent: Wednesday, November 13, 2019 5:00 AM

To: Scharf, Michael; Wesley Eddy; Rodney W. Grimes

Cc: tcpm@ietf.org; tsvwg@ietf.org

Subject: Re: [tsvwg] [tcpm] L4S status tracking





 




[EXTERNAL EMAIL] 




Michael,



I see the problem. Nearly all the occurrences of 'Classic TCP' are in the a=
ppendix that was written v early on, when the focus was only TCP. That text=
 was not written by me, and I haven't got round to editing it for consisten=
cy. However, there are 4 occurrences
 of "'Classic' TCP" in the abstract and intro, which I will also =
fix.



Can you say which "David's proposal" you mean please?





Bob




On 11/11/2019 23:10, Scharf, Michael wrote:






OK, so we seem to make=
 some progress at least regarding the term ‚classic‘ TCP. As me=
ntioned before, I personally would find the term ‘Classic’ QUIC=
 very confusing and you cannot avoid that if you talk about
 ‘Classic’ TCP, IMHO. So, it seems better to avoid that termino=
logy for all transport protocols. For the record, in draft-ietf-tsvwg-ecn-l=
4s-id-08 the combination of the terms ‘classic’ and ‘TCP&=
#8217; back-to-back is used 11 times as far as I can see.=



 


Regarding congestion c=
ontrol, I’d like to emphasize that David’s proposal would also =
work well for me, i.e., characterizing the congestion control by functional=
 properties. This avoids all issues regarding whether
 something will supersede something else (including the issue that EXP is j=
ust an experiment that won’t update or replace any PS document).


 


Michael


 








From:=
 Bob Briscoe
<ietf@bobbriscoe.net> 

Sent: Monday, November 11, 2019 4:31 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Wesley Eddy
<wes@mti-systems.com>; Rod=
ney W. Grimes 
<4bone@gndrsh.dnsmgr.net>

Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 


Michael,



On 07/11/2019 08:11, Scharf, Michael wrote:






… and just to sh=
ow that _my_ concern would be trivial to address by small editorial =
changes:


 


For the abstract of dr=
aft-ietf-tsvwg-ecn-l4s-id, the wording “It gives an incremental migra=
tion path so that normal TCP traffic classified in the ‘Classic’=
; service of L4S will be no worse off” would already work
 for me.  It just takes a small editorial change to make me happy. Thi=
s can’t be so hard.


 


Personally, I wonder i=
f “classic” is indeed the best name for a service class (and, e=
.g., “normal” sounds better to me), but in the context of a ser=
vice class, “classic” could actually work for me, if TSVWG real=
ly
 wants that name with strong consensus. I don’t care how about names =
for DiffSe^D^D^D^D^D^D traffic classifiers, traffic policers/shapers, AQM s=
chemes, or whatever else is done in the fast path of a router to implement =
low latency service.


 


I only object to speci=
fic terminology such as ‘Classic’ TCP or ‘Classic’ =
congestion control because I don’t think that ‘classic’ i=
s a proper characterization for TCPM standards or TCP/IP stack behavior not=
 aligned
 with whatever L4S believes the bright future shall be.



I thought I had already agreed to remove =
'TCP' from all instances of 'Classic TCP traffic' etc, and that I hadn't in=
tended to include 'TCP' in the first place. Because
 it's the congestion controls that are relevant in L4S drafts, not the prot=
ocols.







Bob










 


Whether such small rew=
ording address fully the concerns from others may be a different question.<=
/span>


 


Michael


 


 


 








From:=
 Wesley Eddy
<wes@mti-systems.com> 

Sent: Wednesday, November 6, 2019 8:54 PM

To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Bob Briscoe
<ietf@bobbriscoe.net>; Rod=
ney W. Grimes 
<4bone@gndrsh.dnsmgr.net>

Cc: tsvwg@ietf.org; 
tcpm@ietf.org

Subject: Re: [tcpm] [tsvwg] L4S status tracking





 




On 11/6/2019 1:57 PM, Scharf, Michael wrote:






Bob,=



 


From draft-ietf-tsvwg-=
ecn-l4s-id-08: “It gives an incremental migration path so that existi=
ng 'Classic' TCP traffic will be no worse off”


 


You are proposing an e=
xperiment. Not more than that. I will be fine with the term “Classic&=
#8221; for TCP and TCPM-specified congestion control when more than 50% of =
Internet traffic uses that new technology.


 


Until this happens, I =
insist that the word “Classic” must be removed in all context o=
f TCP and congestion control (as far as it is owned by TCPM), including the=
 reference above. BTW, “normal” as suggested would
 also work for me. So, you have plenty of options for other terms.


 




 


If Dave+Michael's suggestion of replacing "classic" with &=
quot;normal" is agreable to others, this seems like a good way forward=
 to me.  It should be easy enough to explain in other SDOs that classi=
c and normal mean the same thing, if this is a real issue.


(FWIW, I've never had a problem myself with "classic", nor rea=
d any negative connotations to it.  However, for the sake of working g=
roup progress, I think we just need to pick something that seems the least =
terrible and agree to move on.)


 















-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/













-- 


________________________________________________________________<=
/o:p>


Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/








--_000_MN2PR19MB4045EAFC55061858895E2F0983760MN2PR19MB4045namp_--


From nobody Wed Nov 13 08:30: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 1B8641208E3 for ; Wed, 13 Nov 2019 08:30:07 -0800 (PST)
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 LsvihRnjHnU1 for ; Wed, 13 Nov 2019 08:30:05 -0800 (PST)
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 C2FB812088A for ; Wed, 13 Nov 2019 08:30:04 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 2EA1A25A1A; Wed, 13 Nov 2019 17:30:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573662603; bh=IMm5KkJ4CHDKyuhK93TpOULPjzOl5dCMh5F+3iubtks=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lHUo7Vp/UjNJNWkTnseeexQzINdW1Cx2KwPpvZ/3WuPK0oAf7pvxqETHRD6yyyHK+ 3qOUYm4AmTiN2qedhrDkNV6HB5/XGnAUWmY1dOg9LTYjBO9i5pf+3PElG4xsO2xQHN vHDsTTVwBhMez7iyWdgGeVrotSC0CgOTtsKXhAQQ=
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 YbqVESMQP7LG; Wed, 13 Nov 2019 17:29:59 +0100 (CET)
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; Wed, 13 Nov 2019 17:29:59 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 17:29:59 +0100
From: "Scharf, Michael" 
To: Mirja Kuehlewind , "Neal Cardwell" , "tcpm@ietf.org" 
CC: Bob Briscoe 
Thread-Topic: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
Thread-Index: AQHVmLUL8707rVPe1ES9nrAQ4+JPDKeHpN6AgAGnlyA=
Date: Wed, 13 Nov 2019 16:29:59 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D501415@rznt8114.rznt.rzdir.fht-esslingen.de>
References:  
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 13 Nov 2019 16:30:07 -0000

V291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0byB3b3JrIHRocm91Z2ggdGhhdCBub3cgaWYgdGhpcyBn
aXZlcyBhIHJlYWwtd29ybGQgYmVuZWZpdD8NCg0KV2hpbGUgQWNjRUNOIGlzIGluZGVlZCBleHRl
bnNpYmxlIGFuZCB0aGlzIGlzIGRvY3VtZW50ZWQgaW4gdGhlIGRvY3VtZW50ICh0aGFua3MhKSwg
YXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGVyZSBpcyBvbmx5IHNvIG11Y2ggb25lIGNhbiBkbyB3
aXRoIGZldyBiaXRzLiBBdCBsZWFzdCB0byBtZSBpdCB3b3VsZCBiZSBtb3JlIGNvbnZpbmNpbmcg
dG8gdW5kZXJzdGFuZCBub3cgaG93IHRoaXMgdXNlIGNhc2UgY291bGQgYmUgc29sdmVkLCBpbiBv
cmRlciB0byBlbnN1cmUgdGhhdCB0aGVyZSBhcmUgbm8gb3BlbiBpc3N1ZXMgaW4gd2hhdGV2ZXIg
dGhlIGluaXRpYWwgc3BlYyBkZXNjcmliZXMuDQoNCk1pY2hhZWwgKHdpdGggbm8gaGF0KQ0KDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGNwbSA8dGNwbS1ib3VuY2Vz
QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWlyamEgS3VlaGxld2luZA0KPiBTZW50OiBUdWVzZGF5
LCBOb3ZlbWJlciAxMiwgMjAxOSA1OjA5IFBNDQo+IFRvOiBOZWFsIENhcmR3ZWxsIDxuY2FyZHdl
bGw9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPjsgdGNwbUBpZXRmLm9yZw0KPiBDYzogQm9i
IEJyaXNjb2UgPHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0Pg0KPiBTdWJqZWN0OiBSZTogW3RjcG1d
IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDk6IEFjY0VDTiBvcHRpb246IHdoeSBub3QN
Cj4gRUUxQiBmaXJzdD8NCj4gDQo+IEhpIE5lYWwsDQo+IA0KPiB0aGF0J3MgYSBnb29kIHBvaW50
LiBUaGUgb3JkZXIgb2YgdGhlIGZpZWxkIHdhcyBiYXNlZCBvbiB3aGF0IGlzIGV4cGVjdGVkIHRv
IGJlDQo+IHRoZSBtb3N0IGxpa2VseSBjYXNlLiBDdXJyZW50bHkgbW9zdCB0cmFmZmljLCBpZiBp
dCB1c2VzIEVDTiBhdCBhbGwsIHdpbGwgc2V0IHRoZQ0KPiBjb2RlcG9pbnQgdG8gRUNUKDApLiBX
aXRoIGRlcGxveW1lbnQgb2YgTDRTIHRoaXMgY291bGQgY2hhbmdlIGluIGZ1dHVyZSwNCj4gaG93
ZXZlciwgdGhlcmUgYXJlIGFsc28gc3RpbGwgd2F5cyB0byBleHRlbmQgdGhlIG5lZ290aWF0aW9u
IGluIHRoZSBBY2NFQ04gVENQDQo+IGhhbmRzaGFrZSB0byBlLmcuIHN1cHBvcnQgdGhpcyBjYXNl
IGJldHRlciBpbiBmdXR1cmUuDQo+IA0KPiBNaXJqYQ0KPiANCj4gDQo+IA0KPiDvu79PbiAxMS4x
MS4xOSwgMTg6MjUsICJ0Y3BtIG9uIGJlaGFsZiBvZiBOZWFsIENhcmR3ZWxsIiA8dGNwbS1ib3Vu
Y2VzQGlldGYub3JnDQo+IG9uIGJlaGFsZiBvZiBuY2FyZHdlbGw9NDBnb29nbGUuY29tQGRtYXJj
LmlldGYub3JnPiB3cm90ZToNCj4gDQo+ICAgICBBIHBhcnRpY3VsYXIgcXVlc3Rpb24gaW4gcmVn
YXJkcyB0byB0aGUgQWNjRUNOIG9wdGlvbjoNCj4gDQo+ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA5I3NlY3Rpb24tMy4yLjYN
Cj4gDQo+ICAgICBUaGUgQWNjRUNOIG9wdGlvbiBzcGVjIGxpc3RzIHRoZSBFRTBCIGZpZWxkIGZp
cnN0LCB3aXRoIHRoZSBFRTFCIGZpZWxkDQo+ICAgICBhdCB0aGUgZW5kLg0KPiANCj4gICAgIEdp
dmVuIHRoYXQgTDRTIHBsYW5zIG9uIHVzaW5nIEVDVCgxKSBmb3IgZGF0YSBwYWNrZXRzLCBhbmQg
dW5jaGFuZ2luZw0KPiAgICAgY291bnRlciB2YWx1ZXMgY2FuIGJlIG9taXR0ZWQgZnJvbSB0aGUg
ZW5kIG9mIHRoZSBBY2NFQ04gb3B0aW9uLCB3aHkNCj4gICAgIG5vdCBsaXN0IEVFMUIgZmlyc3Qs
IGFuZCBFRTBCIGxhc3Q/IFdpdGggRUUxQiBmaXJzdCBhbmQgRUUwQiBsYXN0IGl0DQo+ICAgICBz
ZWVtcyB0aGF0IGluIHRoZSBjb21tb24gY2FzZSBmb3IgYW4gTDRTIGNvbm5lY3Rpb24gdGhlICh1
bmNoYW5nZWQpDQo+ICAgICBFRTBCIGNvdWxkIGJlIG9taXR0ZWQsIGFsbG93aW5nIDQgZXh0cmEg
Ynl0ZXMgb2YgcGF5bG9hZCBwZXIgcGFja2V0Lg0KPiAgICAgQUZBSUNUIHRoaXMgZXh0cmEgNCBi
eXRlcyB3b3VsZCBpbmNyZWFzZSBnb29kcHV0IGZvciBhcHBsaWNhdGlvbnMNCj4gICAgIHVzaW5n
IElQdjQgb3IgSVB2NiB3aXRoIGFuIE1UVSBvZiAxNTAwIGJ5IGFib3V0IDAuMyUsIGJ5IG15DQo+
ICAgICBiYWNrLW9mLXRoZS1lbnZlbG9wZSBjYWxjdWxhdGlvbnMuDQo+IA0KPiAgICAgYmVzdCwN
Cj4gICAgIG5lYWwNCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiAgICAgdGNwbSBtYWlsaW5nIGxpc3QNCj4gICAgIHRjcG1AaWV0Zi5v
cmcNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiAN
Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo=


From Mike.Kosek@comsys.rwth-aachen.de  Tue Nov 12 08:52:10 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 22C4912006E for ; Tue, 12 Nov 2019 08:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KHeuOxBeuCuq for ; Tue, 12 Nov 2019 08:52:07 -0800 (PST)
Received: from mail-out-4.itc.rwth-aachen.de (mail-out-4.itc.rwth-aachen.de [134.130.5.49]) (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 85827120837 for ; Tue, 12 Nov 2019 08:52:06 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BTbADt4cpd/xUN4ollgkaBNQIBEVVZa?= =?us-ascii?q?y80jESGYZs/gXoJAQEBAQEBAQEBCC0CAQGGXyQ8Ag0CDgEBBQEBAQEBBQRthTg?= =?us-ascii?q?LhhIZOAE+QicEgzWCeAEDsHaFToM0gUiBNAMBAYwRgVg/gREnH4QOhwOCLASuE?= =?us-ascii?q?AeBQGhwlFQbgi0Qh2GECYtSjkeaHoEyTguBWDMaJHkBgkJPERSQTo4ughyPJwG?= =?us-ascii?q?BDgEB?=
X-IPAS-Result: =?us-ascii?q?A2BTbADt4cpd/xUN4ollgkaBNQIBEVVZay80jESGYZs/gXo?= =?us-ascii?q?JAQEBAQEBAQEBCC0CAQGGXyQ8Ag0CDgEBBQEBAQEBBQRthTgLhhIZOAE+QicEg?= =?us-ascii?q?zWCeAEDsHaFToM0gUiBNAMBAYwRgVg/gREnH4QOhwOCLASuEAeBQGhwlFQbgi0?= =?us-ascii?q?Qh2GECYtSjkeaHoEyTguBWDMaJHkBgkJPERSQTo4ughyPJwGBDgEB?=
X-IronPort-AV: E=Sophos;i="5.68,297,1569276000"; d="scan'208";a="57297441"
Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-4.itc.rwth-aachen.de with ESMTP; 12 Nov 2019 17:52:02 +0100
Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id 742F842419 for ; Tue, 12 Nov 2019 17:52:01 +0100 (CET)
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 12 Nov 2019 17:52:01 +0100
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1130.005; Tue, 12 Nov 2019 17:52:01 +0100
From: Mike Kosek 
To: "tcpm@ietf.org" 
Thread-Topic: RFC793bis draft 14 Reserved Bits
Thread-Index: AQHVmXmARpCdXGCX80ym8uYEIhcQ0g==
Date: Tue, 12 Nov 2019 16:52:00 +0000
Message-ID: <6BB02BBB-414E-4E64-82EF-7B4DDE31F790@comsys.rwth-aachen.de>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [89.204.155.93]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1C674C7D19B300478876F8AC2711B76A@comsys.rwth-aachen.de>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Wed, 13 Nov 2019 08:31:28 -0800
Subject: [tcpm] RFC793bis draft 14 Reserved Bits
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, 12 Nov 2019 16:53:59 -0000

Hi tcpm,

Catching up on draft-ietf-tcpm-rfc793bis-14, I was wondering why the rsrvd =
bits are not explicitly stated as a formal MUST requirement:=20

"Must be zero in generated segments and must be ignored in received segment=
s, if corresponding future features are unimplemented by the sending or rec=
eiving host."

To my understanding, the current phrasing is up to interpretation, i.e., so=
meone might opt to not implement it as stated due to the missing formal MUS=
T - Please prove me wrong if I am missing something.

Best Regards,
Mike=


From nobody Wed Nov 13 09:05:35 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 075F212088A; Wed, 13 Nov 2019 09:05:34 -0800 (PST)
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 jth3iRjSUnFZ; Wed, 13 Nov 2019 09:05:32 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 89D8A12004F; Wed, 13 Nov 2019 09:05:32 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id t5so3447972ljk.0; Wed, 13 Nov 2019 09:05:32 -0800 (PST)
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=0mZ688kKuo4La7Oze8xQoDt2KXv74fNun1Yg6jh+NZw=; b=unKTZFZkebBW+tXRId7afIAEFliCqQJLWiDridjWzeD/0OEfdn0HZLtYfISHnU7UFb vrtO1T/0ALAlrtAC8Zzoaf+QwPHTUJESmkDN/gnuXCjdkb55K5eGa87ziyG58dtQVr2t uUhqwDjI6GBM7oNuU5vSMq+4YmYR11nx1srlIRTlyKlRQrtKTpig0xEq0nK7qiOvmbG8 8J67X3muK6G6F5EchEBjpSBkDoztUVTP5Ub/+WZKPCsP1zgtgEOrHJxG/CVh9KmRNVTU wMoHU7O7vfMOzTkU/b27bTOyJWvfexwZDiWsMzlo7j4j4gkkbL9bSj5gIZbqPV8+4yEZ V6NA==
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=0mZ688kKuo4La7Oze8xQoDt2KXv74fNun1Yg6jh+NZw=; b=ZaCzy4KOCuRflVrybUK4dZrJY8m8dODYwjaeQ37vc0+QwAIAZQmatOr2GYNkjToZ/+ LHIvO2BvSZ+ajU47l6DcRPn8ufmzIA31zLF351GeowieaJVp8oNOavnVfNCtMn0swzv+ QipP/zFH2BmqaKfSH/f9aYzmZuZ3d76kG4jO+8KeNFicpjYNkJbqxT3g+K1OnK7DSVI8 yifDCmfSbVTwrDZdzmG46BISVJ1eJLzMUOwzKKWSxBFcfX7FtAzlZWSW1SJ6gNFlzkEO /tWLdZ3hMC9I50ih+Poen4Xdvp2aDhLmnerOrDlfMe6vbQwlm1tOX07x1CczjlMeLe+h xa8Q==
X-Gm-Message-State: APjAAAUzBJAtVzYEAhXNIrYUKUpXKnK1Nx5UkOeUoNo1BOhFzMD40AAM 7WKnsvPOPaw4C6pCRwOhgvw=
X-Google-Smtp-Source: APXvYqwLRMOtg55/FzGWWc/jdLkpFdPGi9TLAMUcpUYO5YfsmQrHMIA32ItCkRxSSDvCmluAUO18LQ==
X-Received: by 2002:a2e:b4da:: with SMTP id r26mr3082421ljm.153.1573664730753;  Wed, 13 Nov 2019 09:05:30 -0800 (PST)
Received: from jonathartonsmbp.lan (85-76-23-24-nat.elisa-mobile.fi. [85.76.23.24]) by smtp.gmail.com with ESMTPSA id i30sm1394160lfp.39.2019.11.13.09.05.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 09:05:30 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: 
Date: Wed, 13 Nov 2019 19:05:19 +0200
Cc: Bob Briscoe , "Scharf, Michael" , Wesley Eddy , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <05DAB658-8B0A-4DA9-93E9-2A3B871023DC@gmail.com>
References: 
To: "Black, David" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] [tsvwg] "David's proposal" for cc class terms (was RE: 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: Wed, 13 Nov 2019 17:05:34 -0000

> On 13 Nov, 2019, at 6:15 pm, Black, David  =
wrote:
>=20
> We are dealing with two classes of congestion controls.  For lack of =
better terms the following class names are based on what the transport =
protocol throughput is proportional to where =E2=80=98p=E2=80=99 is the =
loss and/or congestion marking probability:
>                - 1/sqrt(p)-class congestion controls: Includes most =
existing TCP congestion control algorithms, e.g., NewReno, CUBIC.
>                - 1/p-class congestion controls: Includes DCTCP =
congestion control.
> Keep in mind that p is a probability that is usually << 1 when =
expressed as a decimal, e.g., p=3D0.01 represents a 1% loss/marking =
rate.

Specifically CE marking or loss.  SCE marking can orthogonally elicit a =
DCTCP-style 1/p-class or an SCE-specific 1/(p*sqrt(p)) class of =
response, overlaid on the normal 1/sqrt(p) response to CE.

To give these a more intuitively recognisable face, may I suggest:

- "MD" for Multiplicative Decrease, for the traditional 1/sqrt(p)-class =
TCP response.

- "DCTCP" for the 1/p-class response introduced by that scheme.

- "ELR" for Explicit Load Regulation, for SCE's preferred =
1/(p*sqrt(p))-class response.

ELR was an early name considered for SCE, using a control element =
commonly found in diesel locomotives (known as a Load Regulator) as =
inspiration.  This generally has a slow adjustment mode for small =
disturbances from steady state, and a fast adjustment mode for larger =
disturbances.  The MD response corresponds to the fast adjustment mode, =
and the ELR response with the traditional linear cwnd growth correspond =
to the slow adjustment mode.  Since SCE refers specifically to the =
signalling method, we can use ELR to avoid confusion when referring to =
the response function.

Incidentally, another way of writing the above formulae is as an =
exponent to p:

- p^-0.5 is 1/sqrt(p)

- p^-1 is 1/p

- p^-1.5 is 1/(p*sqrt(p))

The above may also be more readable, if not as familiar to =
non-mathematicians.

 - Jonathan Morton


From nobody Wed Nov 13 09:44:07 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 67D0D12011C for ; Wed, 13 Nov 2019 09:43:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 XP3kjTjrswtD for ; Wed, 13 Nov 2019 09:43:54 -0800 (PST)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 5328F120835 for ; Wed, 13 Nov 2019 09:43:54 -0800 (PST)
Received: by mail-qk1-x72c.google.com with SMTP id q70so2464101qke.12 for ; Wed, 13 Nov 2019 09:43:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=TJkOT8Pts+Eb+qGwiA/46/QyLHIuhBUfVfavvGCXjEM=; b=IFrRnP2fh8VJYxAyV/G7GcbSyjK9giNpH0G6Igw9m3b2PcWpdeVYiNkzhozb38FERW twO+BCmVHxANM8P8Hy5y2YlyJN6o4OrY96eV1Yn6Avwy1/H9cti+a2jlmfx9jnBQUXs+ XuLBUjPRMbmo2+pIAEPDlqeeVx8fxmpmc3uGcUT1VSmZGIOn4jdwMYMOM3DLtZYniRX/ hYQ/Gs7g6k6s9WFJMUJ7aLpZMGWyT0zvjtDHCqde6wn+Tb24Eygt9qy1S68poxBGL1ej bCV6lrOyB4n8pIip6D/wLmsWA2AGdDHMh++v4dAbZZ9aAIoRH3GLbZDgo/eWDHiiPIkb rCKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=TJkOT8Pts+Eb+qGwiA/46/QyLHIuhBUfVfavvGCXjEM=; b=JdKdbER9zh9OK4qT2OjXZ4KqD6/tbuhdWh4iyUf0UN1yILKknD/ZRCPzoTsjhBphZD PMsPJv7wihiOUvlJ+zI/VMe3oaFSkeskdknTe922Xx6T5RNsRHRYawsV+u/fhoVDgLYi CYt82XC9tlPgaJw2LSccdcrVkhz2sy5JnFButTyagz3s35eA3J18w+Rp6rESnPWeG635 Zrlfh5/uLHOIbvq+hS8NuxASi+KAd4i0F3FpEOduSmoaE+m/ji6m0JSmuU2bYnAjF/aJ tL/uskSBmnFhPQ1cImMD2IsTniLNOt2Bh4Cg/H8/4rT9xhOdzPdGC48476JX1ejo6flV xGag==
X-Gm-Message-State: APjAAAUgNW+OPtdj0EdvwpJm6ORjnnT/Swx6R5o5nAkRwvk4xutSUnoD NeV4s53QYu0KJuw2FnjBg+6p5g==
X-Google-Smtp-Source: APXvYqyF/ilEfnR15YtjvVdp5Iv/XjSbq4n9s6emF01Tlkwthg98QQVHGO9FXVvZPUlDmaWI1nxBDw==
X-Received: by 2002:ae9:e851:: with SMTP id a78mr3626937qkg.312.1573667033203;  Wed, 13 Nov 2019 09:43:53 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id n17sm1300039qke.53.2019.11.13.09.43.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 09:43:52 -0800 (PST)
To: "Black, David" , Bob Briscoe ,  "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" 
References: 
From: Wesley Eddy 
Message-ID: <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Date: Wed, 13 Nov 2019 12:43:52 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D3AAF2B5C08F295CCDA451F2"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] "David's proposal" for cc class terms (was RE: [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: Wed, 13 Nov 2019 17:43:58 -0000

This is a multi-part message in MIME format.
--------------D3AAF2B5C08F295CCDA451F2
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 11/13/2019 11:15 AM, Black, David wrote:
>
> In more detail than I explained earlier: in this forum
>
> We are dealing with two classes of congestion controls. For lack of 
> better terms the following class names are based on what the transport 
> protocol throughput is proportional to where p is the loss and/or 
> congestion marking probability:
>
> - 1/sqrt(p)-class congestion controls: Includes most existing TCP 
> congestion control algorithms, e.g., NewReno, CUBIC.
>
> - 1/p-class congestion controls: Includes DCTCP congestion control.
>
> Keep in mind that p is a probability that is usually << 1 when 
> expressed as a decimal, e.g., p=0.01 represents a 1% loss/marking rate.
>
"Scalable" is the term we've been using in the L4S documents for 1/p, 
defined in l4s-arch as:

  Scalable Congestion Control: A congestion control where the packet
  flow rate per round trip (the window) is inversely proportional to
  the level (probability) of congestion signals. Then, as flow rate
  scales, the number of congestion signals per round trip remains
  invariant, maintaining the same degree of control. For instance,
  DCTCP averages 2 congestion signals per round-trip whatever the
  flow rate.




--------------D3AAF2B5C08F295CCDA451F2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 11/13/2019 11:15 AM, Black, David
      wrote:

    

    

      
      
      
      

        
In more detail
            than I explained earlier: in this forum

        

        
We are dealing
            with two classes of congestion controls. For lack of better
            terms the following class names are based on what the
            transport protocol throughput is proportional to where p
            is the loss and/or congestion marking probability:

        

            - 1/sqrt(p)-class congestion controls: Includes most
            existing TCP congestion control algorithms, e.g., NewReno,
            CUBIC.

        

            - 1/p-class congestion controls: Includes DCTCP congestion
            control.

        
Keep in mind
            that p is a probability that is usually << 1 when
            expressed as a decimal, e.g., p=0.01 represents a 1%
            loss/marking rate.

        

      

    

    
"Scalable" is the term we've been using in the L4S documents for
      1/p, defined in l4s-arch as:

    
 Scalable Congestion Control: A congestion control where the
      packet

       flow rate per round trip (the window) is inversely
      proportional to

       the level (probability) of congestion signals. Then, as
      flow rate

       scales, the number of congestion signals per round trip
      remains

       invariant, maintaining the same degree of control. For
      instance,

       DCTCP averages 2 congestion signals per round-trip whatever
      the

       flow rate.

    


    

    


    

  


--------------D3AAF2B5C08F295CCDA451F2--


From nobody Wed Nov 13 10:08:32 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 AFD9C120841; Wed, 13 Nov 2019 10:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 02s2PgS4FT7E; Wed, 13 Nov 2019 10:08:29 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3190C12083E; Wed, 13 Nov 2019 10:08:28 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xADI7Y5N045144; Wed, 13 Nov 2019 10:07:34 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xADI7Yc9045143; Wed, 13 Nov 2019 10:07:34 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911131807.xADI7Yc9045143@gndrsh.dnsmgr.net>
In-Reply-To: <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
To: Wesley Eddy 
Date: Wed, 13 Nov 2019 10:07:34 -0800 (PST)
CC: "Black, David" , Bob Briscoe ,  "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] "David's proposal" for cc class terms (was RE: [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: Wed, 13 Nov 2019 18:08:31 -0000

> On 11/13/2019 11:15 AM, Black, David wrote:
> >
> > In more detail than I explained earlier: in this forum
> >
> > We are dealing with two classes of congestion controls. ?For lack of 
> > better terms the following class names are based on what the transport 
> > protocol throughput is proportional to where ?p? is the loss and/or 
> > congestion marking probability:
> >
> > - 1/sqrt(p)-class congestion controls: Includes most existing TCP 
> > congestion control algorithms, e.g., NewReno, CUBIC.
> >
> > - 1/p-class congestion controls: Includes DCTCP congestion control.
> >
> > Keep in mind that p is a probability that is usually << 1 when 
> > expressed as a decimal, e.g., p=0.01 represents a 1% loss/marking rate.
> >
> "Scalable" is the term we've been using in the L4S documents for 1/p, 
> defined in l4s-arch as:
> 
>  ?? Scalable Congestion Control:? A congestion control where the packet
>  ????? flow rate per round trip (the window) is inversely proportional to
>  ????? the level (probability) of congestion signals.? Then, as flow rate
>  ????? scales, the number of congestion signals per round trip remains
>  ????? invariant, maintaining the same degree of control.? For instance,
>  ????? DCTCP averages 2 congestion signals per round-trip whatever the
>  ????? flow rate.

Does reading this definition make anyone elses head hurt?

Flow rate per round trip?
How can one have a rate that is per round trip?
Can someone give me a dimensional analysis and tell me what the units are here?  bits per second per second is what I come up with.

Now "(the window)" is almost getting me there, perhaps "(the window size)"?

For me flow rate is not the right terminology here.

Furthermore, "the number of congestion signals per round trip remains invariant" is that really whats happening here?
For me that says it is a fixed value of some N, for DCTCP that N is 2, but for L4S, and SCE it is not invariant,
it is variant based on the number of packets in flight (the invariant *might* be the ratio or proportion of congestion signals (marks)
to packets, but even that is variant as the marking rate depends on the level of congestion.)

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Wed Nov 13 10:19:18 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 6B7E3120841; Wed, 13 Nov 2019 10:19:16 -0800 (PST)
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 CBiXPgWHhSnf; Wed, 13 Nov 2019 10:19:15 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 9B0F712083E; Wed, 13 Nov 2019 10:19:14 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id m6so2756530lfl.3; Wed, 13 Nov 2019 10:19:14 -0800 (PST)
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=2NI9WLZ9ZkSI8RfZ9e6V1tkvg1yzIu40cSCMFG9WZpg=; b=klzA7fBqumOywEbUhcKTSBbWIdI6Fax5T9qRld7kXXZ7NDAtr01C2z/5wTg0iJoAeA 7WYRiH8QWwXDJyoe8z7W2H+3Co19eoG8WkdM+s830Lbwa83mjdELW45zZ5xRKwacnXAb kH9lQVBpS/lP3MJumaiWdpPRKaCqI3u1O8/c0jvmuF1Xz8AFODHX8pj+q0rHJrvptDXk AORERxrs3X9FIj5MX6YpSI2pAR6pv3dhjgMKgptOq22BCJ9QBcZ9tvdeCsM6qeoGyMlL 3NzP4N/3FCDWeFPXcVIh3RNVSJFwrpXwPMj8sZsBBVk9vXf+pSYuBUkYWboXKqyJGjWg 5BJw==
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=2NI9WLZ9ZkSI8RfZ9e6V1tkvg1yzIu40cSCMFG9WZpg=; b=HTW0KvejZfBfMWxEo9MHY8oixovRAMB/nnpmKcDJJdQCldMEpeIwBe1QP4t9VXJh+D k0epA0qzzNqLASvAz2lRCGlWt8Qxjgvz4sMfaPfRT2NjEJ/k/BUpPrD2CEHwiv2baszn 1/vmBnT1IIBxrWIMvr2kUpeThcA5QFPptSAdeN3A7T5kws6weqe17jQvCk8OM/TBLjiL ZsR3SWHz22t3fSqCn349JehjrvaHfmR0jRRDkaUMVdpqGFe6LLizrjhuMkoMiYGzHBXc UGbiB5kib1UZLUPu9o3z5yYQR7UI9ZvrRyMGbAT0Tek27ZZo8BuSKpMZFhpwASv1b5ag dCxg==
X-Gm-Message-State: APjAAAUyYJqfY3FQi7lSH5CHtj9FCv4ldONN51Zbvjj8APlhWTeXYBdS HJ1o7TSxYbtaI2DywNrIkV8=
X-Google-Smtp-Source: APXvYqxZ7whAiIaNvqNnsfssjBETfglppHbYapJpafo5Djhjje4p+Huz/QAiu4JO5/nTdeOUUHJAbg==
X-Received: by 2002:a19:c790:: with SMTP id x138mr3761182lff.61.1573669152666;  Wed, 13 Nov 2019 10:19:12 -0800 (PST)
Received: from jonathartonsmbp.lan (85-76-23-24-nat.elisa-mobile.fi. [85.76.23.24]) by smtp.gmail.com with ESMTPSA id f14sm1177923ljn.105.2019.11.13.10.19.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 10:19:12 -0800 (PST)
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: <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Date: Wed, 13 Nov 2019 20:19:10 +0200
Cc: "Black, David" , Bob Briscoe ,  "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <96111DEA-669E-47FF-B50D-B60FE59CA15E@gmail.com>
References:  <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
To: Wesley Eddy 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] [tsvwg] "David's proposal" for cc class terms (was RE: 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: Wed, 13 Nov 2019 18:19:16 -0000

> On 13 Nov, 2019, at 7:43 pm, Wesley Eddy  wrote:
>=20
> "Scalable" is the term we've been using in the L4S documents for 1/p, =
defined in l4s-arch as:
>=20
>    Scalable Congestion Control:  A congestion control where the packet
>       flow rate per round trip (the window) is inversely proportional =
to
>       the level (probability) of congestion signals.

Unfortunately, the term "scalable" sounds like a marketing term to me.  =
I would prefer to support terms with some obvious technical basis.  In =
my experience, DCTCP is closely associated with this response function, =
and is often used as shorthand for it.

 - Jonathan Morton=


From nobody Wed Nov 13 12:31:52 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 8216C12008C; Wed, 13 Nov 2019 12:31:43 -0800 (PST)
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 2zZCRUYUJU_a; Wed, 13 Nov 2019 12:31:41 -0800 (PST)
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 4A5E112003E; Wed, 13 Nov 2019 12:31:41 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 81FAE25A1A; Wed, 13 Nov 2019 21:31:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573677099; bh=hXJdr86IdLpTxtiT9pfdeHr7btMBrcuUrTG97N80TSE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=TerpG8sti6+G0TlA9nMMxbaX4X6oIOjWZZqUQfS7nwU9TcAFhRP8Kvas3qtIUSut4 /Vk1iwPlXSGryCUC5AiQ4wW/zKMeFI7IXmkAAtTJ/ZPfZz7Cd05B9khJcvtqus/jtZ NpRWv93SXHNY/P3RHdzQ2c530aTpvEMCCx40SedU=
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 aoAj38d_9pEb; Wed, 13 Nov 2019 21:31:38 +0100 (CET)
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; Wed, 13 Nov 2019 21:31:38 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 21:31:37 +0100
From: "Scharf, Michael" 
To: Jonathan Morton , Wesley Eddy 
CC: "Black, David" , Bob Briscoe ,  "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" , "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S status tracking)
Thread-Index: AQHVmk7bekJMC3Uh2U2Zu9z/tPxjDKeJicYw
Date: Wed, 13 Nov 2019 20:31:37 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D501C59@rznt8114.rznt.rzdir.fht-esslingen.de>
References:  <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com> <96111DEA-669E-47FF-B50D-B60FE59CA15E@gmail.com>
In-Reply-To: <96111DEA-669E-47FF-B50D-B60FE59CA15E@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] [tsvwg] "David's proposal" for cc class terms (was RE: 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: Wed, 13 Nov 2019 20:31:43 -0000

> -----Original Message-----
> From: Jonathan Morton 
> Sent: Wednesday, November 13, 2019 7:19 PM
> To: Wesley Eddy 
> Cc: Black, David ; Bob Briscoe ;
> Scharf, Michael ; Rodney W. Grimes
> <4bone@gndrsh.dnsmgr.net>; tcpm@ietf.org; tsvwg@ietf.org
> Subject: Re: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm=
] L4S
> status tracking)
>=20
> > On 13 Nov, 2019, at 7:43 pm, Wesley Eddy  wrote:
> >
> > "Scalable" is the term we've been using in the L4S documents for 1/p, d=
efined
> in l4s-arch as:
> >
> >    Scalable Congestion Control:  A congestion control where the packet
> >       flow rate per round trip (the window) is inversely proportional t=
o
> >       the level (probability) of congestion signals.
>=20
> Unfortunately, the term "scalable" sounds like a marketing term to me.  I=
 would
> prefer to support terms with some obvious technical basis.  In my experie=
nce,
> DCTCP is closely associated with this response function, and is often use=
d as
> shorthand for it.

At least the wording "'less unscalable' Cubic" in draft-ietf-tsvwg-ecn-l4s-=
id-08 is a marketing term to me. Unscalable has a negative connotation to m=
e (as non-native speaker).

If "scalable" shall be used, IMHO a similar term with positive connotation =
has to be used for 1/sqrt(p) congestion control. An example would be 'high-=
speed congestion control' for CUBIC. That term is IMHO relatively well esta=
blished in the IETF. But I am not sure if we should really go down that roa=
d.

The benefit of using terms with a technical or mathematical foundation is t=
hat we don't have to argue whether 'scalable' outperforms 'high-speed'. And=
 I believe avoiding such controversy could help with finishing this discuss=
ion.

My 2 cents

Michael



From nobody Wed Nov 13 15:49: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 E2BAC120018; Wed, 13 Nov 2019 15:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 VmppLy5x1j9J; Wed, 13 Nov 2019 15:49:47 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 27DDC1209F9; Wed, 13 Nov 2019 15:49:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=4POzk0qvH2LtwoTNDU2ei2q3ZOqLIiDiXqCv1S0atDM=; b=p6DLEk26UQlZXclEKQ0BAzA3z jQymZzHcXC3MeAMWCBDIC4qQvNpPLWRUn3rtqtgt074O2C+qQqwQMvlSqTdpOER3dRdVeUpi3vIo/ vTCxPYHoErgNyjFgEHRdSC/gxwzvAyWsyJCSoUlBdtf+Rz+n3C4RgFrYQTTsG1OoSBDWHPbLYg9Rj XJui0gYOpRZ+5ez9ZDsBKVG2FDzgoDTdUVH5fTFNCLbd7ce8zR+SVJ2u5Pio79ivVG6Uo0AI4EdHx stBUeXr0yH0gzkebD8woPJ68LQQBTtE3wuCHIf6j2kINCs7POT5vmIcK8RMggUb1l5X6L5WzoxL3C zVIzm5nBg==;
Received: from [31.185.128.31] (port=52668 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iV2OO-00053Y-62; Wed, 13 Nov 2019 23:49:44 +0000
To: Wesley Eddy , "Black, David" ,  "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" 
References:  <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
From: Bob Briscoe 
Message-ID: 
Date: Wed, 13 Nov 2019 23:49:43 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Content-Type: multipart/alternative; boundary="------------AC43FCC3F6E5686D1565221B"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] "David's proposal" for cc class terms (was RE: [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: Wed, 13 Nov 2019 23:49:50 -0000

This is a multi-part message in MIME format.
--------------AC43FCC3F6E5686D1565221B
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

David, Wes,

On 13/11/2019 17:43, Wesley Eddy wrote:
> On 11/13/2019 11:15 AM, Black, David wrote:
>>
>> In more detail than I explained earlier: in this forum
>>
>> We are dealing with two classes of congestion controls. For lack of 
>> better terms the following class names are based on what the 
>> transport protocol throughput is proportional to where p is the 
>> loss and/or congestion marking probability:
>>
>> - 1/sqrt(p)-class congestion controls: Includes most existing TCP 
>> congestion control algorithms, e.g., NewReno, CUBIC.
>>
1/sqrt(p) only describes the worst case that the coupled dualq AQM is 
designed to allow for. It includes cubic in it's reno-friendly regime, 
as well as beyond that. It includes compound and a whole host of 
slightly more aggressive congestion control variants than Reno, as well 
as ABE variants of each. It includes the proprietary congestion 
controllers used in Skype, Hangouts, Facetime, Zoom, Whereby, etc. It 
includes rmcat congestion controllers.

So I wouldn't want to use a name that implied everything in this class 
obeyed (or had to obey) a 1/sqrt law.


Bob


>> - 1/p-class congestion controls: Includes DCTCP congestion control.
>>
>> Keep in mind that p is a probability that is usually << 1 when 
>> expressed as a decimal, e.g., p=0.01 represents a 1% loss/marking rate.
>>
> "Scalable" is the term we've been using in the L4S documents for 1/p, 
> defined in l4s-arch as:
>
>  Scalable Congestion Control: A congestion control where the packet
>  flow rate per round trip (the window) is inversely proportional to
>  the level (probability) of congestion signals. Then, as flow rate
>  scales, the number of congestion signals per round trip remains
>  invariant, maintaining the same degree of control. For instance,
>  DCTCP averages 2 congestion signals per round-trip whatever the
>  flow rate.
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------AC43FCC3F6E5686D1565221B
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    David, Wes,

    

    
On 13/11/2019 17:43, Wesley Eddy wrote:

    

    

      
      
On 11/13/2019 11:15 AM, Black, David
        wrote:

      

      

        
        
        
        

          
In more
              detail than I explained earlier: in this forum

          

          
We are
              dealing with two classes of congestion controls. For lack
              of better terms the following class names are based on
              what the transport protocol throughput is proportional to
              where p is the loss and/or congestion marking
              probability:

          

              - 1/sqrt(p)-class congestion controls: Includes most
              existing TCP congestion control algorithms, e.g., NewReno,
              CUBIC.

            

        

      

    

    1/sqrt(p) only describes the worst case that the coupled dualq AQM
    is designed to allow for. It includes cubic in it's reno-friendly
    regime, as well as beyond that. It includes compound and a whole
    host of slightly more aggressive congestion control variants than
    Reno, as well as ABE variants of each. It includes the proprietary
    congestion controllers used in Skype, Hangouts, Facetime, Zoom,
    Whereby, etc. It includes rmcat congestion controllers.

    

    So I wouldn't want to use a name that implied everything in this
    class obeyed (or had to obey) a 1/sqrt law.

    

    

    Bob

    

    

    

      

        

          

          

              - 1/p-class congestion controls: Includes DCTCP congestion
              control.

          
Keep in mind
              that p is a probability that is usually << 1 when
              expressed as a decimal, e.g., p=0.01 represents a 1%
              loss/marking rate.

          

        

      

      
"Scalable" is the term we've been using in the L4S documents
        for 1/p, defined in l4s-arch as:

      
 Scalable Congestion Control: A congestion control where the
        packet

         flow rate per round trip (the window) is inversely
        proportional to

         the level (probability) of congestion signals. Then, as
        flow rate

         scales, the number of congestion signals per round trip
        remains

         invariant, maintaining the same degree of control. For
        instance,

         DCTCP averages 2 congestion signals per round-trip
        whatever the

         flow rate.

      


      

      


      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------AC43FCC3F6E5686D1565221B--


From nobody Wed Nov 13 15:58:26 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 3BCD3120837; Wed, 13 Nov 2019 15:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 yYOO0osTSn9K; Wed, 13 Nov 2019 15:58:22 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6BA8A120018; Wed, 13 Nov 2019 15:58:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:Subject:From: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=5BwCHQA4ZPGBFrS7Ykf53Lyw7gnkfCTWJaEd+FNSd8w=; b=18N8/RLfbRm5fKn0aku/oZXHA rBjsLTp6a9AdDMUC9cGJJNQ4k83tGX9iCtNPu0I6rZkOk/IjpJjGUKDG55VZt2Jdh9mWFEzYvkqM+ p3rAkkHGWanYw8rfTZcEMXN8qL4NIj0W58eONmPw3Vig34ZtJD6l8J8Reke9L40VNpFoigRIky4rH eMeguWkEehhg/OiDhLplPpHtaI9Z4IPlSlC3XLXfv1NJgEGlcI4rI3Ja9UM49YSDpJ2xDKg9WYmvy i0cb2pJEmCEcYy/51m9sfFE6QNIgVJNKoNjKJundzVSjpzZywYbrHd7PAU7U4ghahURz1KtX9Lhho 8IdqHBILw==;
Received: from [31.185.128.31] (port=52690 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iV2Wh-0006HK-6L; Wed, 13 Nov 2019 23:58:19 +0000
From: Bob Briscoe 
To: Wesley Eddy , "Black, David" ,  "Scharf, Michael" , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" 
References:  <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Message-ID: 
Date: Wed, 13 Nov 2019 23:58:18 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Content-Type: multipart/alternative; boundary="------------971C34EEBF9FDA7615296D65"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] "David's proposal" for cc class terms (was RE: [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: Wed, 13 Nov 2019 23:58:24 -0000

This is a multi-part message in MIME format.
--------------971C34EEBF9FDA7615296D65
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

David, Wes, [sry, I omitted to include the 'Bob adds:' para below]

On 13/11/2019 17:43, Wesley Eddy wrote:
> On 11/13/2019 11:15 AM, Black, David wrote:
>>
>> In more detail than I explained earlier: in this forum
>>
>> We are dealing with two classes of congestion controls. For lack of 
>> better terms the following class names are based on what the 
>> transport protocol throughput is proportional to where p is the 
>> loss and/or congestion marking probability:
>>
>> - 1/sqrt(p)-class congestion controls: Includes most existing TCP 
>> congestion control algorithms, e.g., NewReno, CUBIC.
>>
1/sqrt(p) only describes the worst case that the coupled dualq AQM is 
designed to allow for. It includes cubic in it's reno-friendly regime, 
as well as beyond that. It includes compound and a whole host of 
slightly more aggressive congestion control variants than Reno, as well 
as ABE variants of each. It includes the proprietary congestion 
controllers used in Skype, Hangouts, Facetime, Zoom, Whereby, etc. It 
includes rmcat congestion controllers.

So I wouldn't want to use a name that implied everything in this class 
obeyed (or had to obey) a 1/sqrt law.

[Bob adds:] Here's a link to plots of the congestion response functions 
for a selection of congestion controllers that I prepared years ago. 
They are all what has been defined as Classic, except DCTCP and Scalable 
TCP (which is not just a scalable TCP, but the protocol that calls 
itself Scalable TCP):
  http://bobbriscoe.net/projects/latency/responseFns.pdf
Recovery time is the average time the congestion control takes to induce 
one loss after its responded to a previous one. You can see it's 
invariant for the scalable controllers.


Bob


>> - 1/p-class congestion controls: Includes DCTCP congestion control.
>>
>> Keep in mind that p is a probability that is usually << 1 when 
>> expressed as a decimal, e.g., p=0.01 represents a 1% loss/marking rate.
>>
> "Scalable" is the term we've been using in the L4S documents for 1/p, 
> defined in l4s-arch as:
>
>  Scalable Congestion Control: A congestion control where the packet
>  flow rate per round trip (the window) is inversely proportional to
>  the level (probability) of congestion signals. Then, as flow rate
>  scales, the number of congestion signals per round trip remains
>  invariant, maintaining the same degree of control. For instance,
>  DCTCP averages 2 congestion signals per round-trip whatever the
>  flow rate.
>
>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/


--------------971C34EEBF9FDA7615296D65
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    David, Wes, [sry, I omitted to include the 'Bob adds:' para below]

    

    
On 13/11/2019 17:43, Wesley Eddy wrote:

    

    

      
      
On 11/13/2019 11:15 AM, Black, David
        wrote:

      

      

        
        
        
        

          
In more
              detail than I explained earlier: in this forum

          

          
We are
              dealing with two classes of congestion controls. For lack
              of better terms the following class names are based on
              what the transport protocol throughput is proportional to
              where p is the loss and/or congestion marking
              probability:

          

              - 1/sqrt(p)-class congestion controls: Includes most
              existing TCP congestion control algorithms, e.g., NewReno,
              CUBIC.

            

        

      

    

    1/sqrt(p) only describes the worst case that the coupled dualq AQM
    is designed to allow for. It includes cubic in it's reno-friendly
    regime, as well as beyond that. It includes compound and a whole
    host of slightly more aggressive congestion control variants than
    Reno, as well as ABE variants of each. It includes the proprietary
    congestion controllers used in Skype, Hangouts, Facetime, Zoom,
    Whereby, etc. It includes rmcat congestion controllers.

    

    So I wouldn't want to use a name that implied everything in this
    class obeyed (or had to obey) a 1/sqrt law.

    

    [Bob adds:] Here's a link to plots of the congestion response
    functions for a selection of congestion controllers that I prepared
    years ago. They are all what has been defined as Classic, except
    DCTCP and Scalable TCP (which is not just a scalable TCP, but the
    protocol that calls itself Scalable TCP):

     http://bobbriscoe.net/projects/latency/responseFns.pdf

    Recovery time is the average time the congestion control takes to
    induce one loss after its responded to a previous one. You can see
    it's invariant for the scalable controllers.

    

    

    Bob

    

    

    

      

        

          

          

              - 1/p-class congestion controls: Includes DCTCP congestion
              control.

          
Keep in mind
              that p is a probability that is usually << 1 when
              expressed as a decimal, e.g., p=0.01 represents a 1%
              loss/marking rate.

          

        

      

      
"Scalable" is the term we've been using in the L4S documents
        for 1/p, defined in l4s-arch as:

      
 Scalable Congestion Control: A congestion control where the
        packet

         flow rate per round trip (the window) is inversely
        proportional to

         the level (probability) of congestion signals. Then, as
        flow rate

         scales, the number of congestion signals per round trip
        remains

         invariant, maintaining the same degree of control. For
        instance,

         DCTCP averages 2 congestion signals per round-trip
        whatever the

         flow rate.

      


      

      


      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------971C34EEBF9FDA7615296D65--


From nobody Thu Nov 14 02:07: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 DD4B7120142 for ; Thu, 14 Nov 2019 02:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, 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 grZBHh0Xe6nH for ; Thu, 14 Nov 2019 02:07:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 B8EA91200E7 for ; Thu, 14 Nov 2019 02:07:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573725978; bh=On7bZ0RsI3p52awdNAAC9Gy2iHzjC9H99ZXfwCzc8wo=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=IuyWyWAKIDZdzKVyCegvbM4BTbCpwMr0EwJZbo0/oV24jCmXB13JOsWr0b2gg5yvy v558YO+G2Rf1/YyDybaxmy+/vqY2irisx9mx0F0wuiZQQ16M8GxhC8wmmzmnJFXyf9 j6SJgfR5fJgluwjKiUxDvV0QLb/KB2FTUtjfkEQg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.54.132.245] ([88.128.80.165]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M3lY1-1iVSrh05Sd-000vkt; Thu, 14 Nov 2019 11:06:18 +0100
To: Bob Briscoe , "tcpm@ietf.org" 
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Thu, 14 Nov 2019 11:06:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ThgbO9anMnj8PVPQH0AFnTaRKDSYIzenKYHEUY1+z6qBMoz6KNR zPsLGejm/BwW+sSfnM+wbbBfr3/p5Ikrw+cJqtRsADysvgXHTTMO5rkKg2TCOkQ+Nf9aWuJ zUwTHQjUs7ouCa30zKNAEhu38JzCfrNV+gP/jtfqRkJjXg0nDI2hp2c3P9jDSBpKw7FWhak vI5mgO1P/L8LyPGSGNITg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:OzyXnxGwaM0=:VFetX8W5rqByisZ4ZTFg88 fYHC1sDJAVn0nsqwZJX2ZCruYVoP2DrW8vnNlsdwhT8NRGk50NWpThAWM+8QpfGRm7lm4WQU3 So22TB6MROYloOBMI2f5i3OPVE4JIr4mOj4FZkDCV/RSXq28xjR6eakX8z0zUYG2D4FKp6CXy YETbnPOqdFLyh8BDelX7wZRqzFJlr3h1DHmgn4PhFdDLK3dh64KB4fwoizTrbMTKV42M6vQi8 Y2buuQawNkVSj44MUb9c3AttgSi6IIZ4BIxW2JvJ9lPzQDCpLSEPCWm+SKH+EQDqJv0WFMjiW QAKDCBiVEF4WalxlkJmT/fJAJWCnTpD1wD3I3EZ5o2HuONl8MR/rGrn3LLp0pvn3wYOEeShX5 WmHeHcKxCgI4LYuHrYapczFctet3xr788LhCufNJaGhaL2PRI3GnqNmEDZbw3hE+MOWCkuzzo gicVesNwAMoWl6wIlc4Y+reRimbQgS7nRJUNth7oT0ntuOnf8Sn06zldAyBWolUhqWgd4csfp llWKDwcpFCu0HOOZABUGtYnneZi/eOziFu/JcOYleFjImX0NSUQhTjzQi2VQHP2JYgcpqVu4w eDuxDqgJaapJKB6OJlFbxQq51FYtZM2YMpZi7S3pWTo3PLXNsHOyZu+An8oPyd3REYdMyAPOU Uvdgak/BhIbxLTLBmats3qBRBJxX7aXo7GDUgn9LwaHQGvfoa2VQWj8JYvA06JmlVsoBxELb1 67V2QNauRtF9u2fdIQrSvUSMujXIAx9UwDT7DcHHNME1VQCPfjCBmRPhPFZRCriqLJGjGIGTK m8OF+1Pfrjh7nSl3fkIC4fpDOZhoAIS0+4OUhQaD+WgGM/WuZSMS4cSfGQxUCol3RofBd9ilO 1ssd3pqmKp7XjCSXBrpofGI50zjijAMP4ewg3ft2jvVRRGq3dP4iMw6k28sTmVUgdNvAVRPjs HKws53uqvU4yozBlqiAM1TyYpUIj840ptbmGKZMmrAKncIx+IhId8xFK66zqcsn9v78n8xQqh ZWlElNvWhDMqZwSfQOY8bgMz4Ruvnd4jZacQJU8PA7sdH0w/zJwBpTNLyhiTwDQ8VOZOgjr0m T3IaletOr7ecqehHK/F5X8GeziwagPqZLI66Q6Mo8l7CaoDPEfCl4CLQh8SWVsumzWBjmSegY 32mV4hHecKxbOqkBhNAze2QcxBGpfaGfEK/4waioo7U6u5yH3EXkYX9qwuVpiqNJpx35+KVua 6ibfxAJPgbW2OLnlxQNW/EAjtFbF7QVa8uqBMVw==
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 14 Nov 2019 10:07:08 -0000

That would special-case the initial AccECN option (value order) from the
subsequent ones, right?

Perhaps placing a different inital value in the first counter would
implicitly signal this better?

The folks from IPPM will not be all too happy with the semantics of
field values depening on some (possibly missed by passive observation)
initial value though...

Certainly warrants more discussion!

Richard


Am 13.11.2019 um 14:30 schrieb Bob Briscoe:
> Neal,
>
> Rather than the IETF have to decide up front which ECT value will be
> more prevalent, I did suggest the following mechanism to my co-authors.
> However, even tho it's fairly simple, we decided wasting some space was
> simpler.
>
> Given TCP Option space is in short supply, if the WG prefers, we can
> include that idea in the spec:...
>
> The data sender for each half-connection currently initializes
>
> 	r.e0b =3D 1 and r.ceb =3D r.e1b.=3D 0
>
> then communicates these to the other end in the option. We could make
> the initial values into a signal that determines whether ECT1 feedback
> comes first for feedback on that half connection. For example:
>
> 	r.e0b =3D 0 and r.ceb =3D r.e1b.=3D 1
>
> could mean ECT0 & ECT1 will be the other way round.
>
>
> Bob
>
> On 12/11/2019 16:09, Mirja Kuehlewind wrote:
>> Hi Neal,
>>
>> that's a good point. The order of the field was based on what is expect=
ed to be the most likely case. Currently most traffic, if it uses ECN at a=
ll, will set the codepoint to ECT(0). With deployment of L4S this could ch=
ange in future, however, there are also still ways to extend the negotiati=
on in the AccECN TCP handshake to e.g. support this case better in future.
>>
>> Mirja
>>
>>
>>
>> =EF=BB=BFOn 11.11.19, 18:25, "tcpm on behalf of Neal Cardwell"  wrote=
:
>>
>>      A particular question in regards to the AccECN option:
>>
>>        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#sect=
ion-3.2.6
>>
>>      The AccECN option spec lists the EE0B field first, with the EE1B f=
ield
>>      at the end.
>>
>>      Given that L4S plans on using ECT(1) for data packets, and unchang=
ing
>>      counter values can be omitted from the end of the AccECN option, w=
hy
>>      not list EE1B first, and EE0B last? With EE1B first and EE0B last =
it
>>      seems that in the common case for an L4S connection the (unchanged=
)
>>      EE0B could be omitted, allowing 4 extra bytes of payload per packe=
t.
>>      AFAICT this extra 4 bytes would increase goodput for applications
>>      using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
>>      back-of-the-envelope calculations.
>>
>>      best,
>>      neal
>>
>>      _______________________________________________
>>      tcpm mailing list
>>      tcpm@ietf.org
>>      https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


From nobody Thu Nov 14 09:11: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 A3393120044 for ; Wed, 13 Nov 2019 18:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 5cdZseiZtNju for ; Wed, 13 Nov 2019 18:07:16 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7DB120876 for ; Wed, 13 Nov 2019 18:07:16 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 3359AF406D8; Wed, 13 Nov 2019 18:07:10 -0800 (PST)
To: rhee@ncsu.edu, xu@unl.edu, sangtae.ha@colorado.edu, alexander.zimmermann@rwth-aachen.de, lars@netapp.com, rs.ietf@gmx.at, ietf@kuehlewind.net, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: elliott.ecton@netpp.com, tcpm@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20191114020710.3359AF406D8@rfc-editor.org>
Date: Wed, 13 Nov 2019 18:07:10 -0800 (PST)
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Nov 2019 09:11:48 -0800
Subject: [tcpm] [Technical Errata Reported] RFC8312 (5907)
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, 14 Nov 2019 02:07:18 -0000

The following errata report has been submitted for RFC8312,
"CUBIC for Fast Long-Distance Networks".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5907

--------------------------------------
Type: Technical
Reported by: Elliott Ecton 

Section: 5.1

Original Text
-------------
 +--------+----------+-----------+------------+-----------+----------+
   |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
   | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
   +--------+----------+-----------+------------+-----------+----------+
   |  10^-2 |       12 |        12 |         12 |        12 |       12 |
   |  10^-3 |       38 |        38 |         38 |        38 |       59 |
   |  10^-4 |      120 |       263 |        120 |       187 |      333 |
   |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
   |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
   |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
   |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
   +--------+----------+-----------+------------+-----------+----------+

                                  Table 1

Corrected Text
--------------
 +--------+----------+-----------+------------+-----------+----------+
   |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
   | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
   +--------+----------+-----------+------------+-----------+----------+
   |  10^-2 |       12 |        12 |          3 |         6 |       11 |
   |  10^-3 |       38 |        38 |         19 |        33 |       59 |
   |  10^-4 |      120 |       263 |        120 |       187 |      333 |
   |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
   |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
   |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
   |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
   +--------+----------+-----------+------------+-----------+----------+

                                  Table 1

Notes
-----
The CUBIC average window sizes for 10^2 and 10^3 are incorrect in the original text using expression 6.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8312 (draft-ietf-tcpm-cubic-07)
--------------------------------------
Title               : CUBIC for Fast Long-Distance Networks
Publication Date    : February 2018
Author(s)           : I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger
Category            : INFORMATIONAL
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Nov 14 09:11: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 681721200F1 for ; Wed, 13 Nov 2019 18:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 wMAPrY7D8Ogb for ; Wed, 13 Nov 2019 18:17:25 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB6512006B for ; Wed, 13 Nov 2019 18:17:25 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id D517BF40710; Wed, 13 Nov 2019 18:17:18 -0800 (PST)
To: rhee@ncsu.edu, xu@unl.edu, sangtae.ha@colorado.edu, alexander.zimmermann@rwth-aachen.de, lars@netapp.com, rs.ietf@gmx.at, ietf@kuehlewind.net, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: elliott.ecton@netpp.com, tcpm@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20191114021718.D517BF40710@rfc-editor.org>
Date: Wed, 13 Nov 2019 18:17:18 -0800 (PST)
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Nov 2019 09:11:48 -0800
Subject: [tcpm] [Technical Errata Reported] RFC8312 (5909)
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, 14 Nov 2019 02:17:27 -0000

The following errata report has been submitted for RFC8312,
"CUBIC for Fast Long-Distance Networks".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5909

--------------------------------------
Type: Technical
Reported by: Elliott Ecton 

Section: 5.1

Original Text
-------------
   +--------+-----------+-----------+------------+-----------+---------+
   |   Loss |   Average |   Average |      CUBIC |     CUBIC |   CUBIC |
   | Rate P |     TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |   (C=4) |
   +--------+-----------+-----------+------------+-----------+---------+
   |  10^-2 |        12 |        12 |         12 |        12 |      12 |
   |  10^-3 |        38 |        38 |         38 |        38 |      38 |
   |  10^-4 |       120 |       263 |        120 |       120 |     120 |
   |  10^-5 |       379 |      1795 |        379 |       379 |     379 |
   |  10^-6 |      1200 |     12279 |       1200 |      1200 |    1874 |
   |  10^-7 |      3795 |     83981 |       3795 |      5926 |   10538 |
   |  10^-8 |     12000 |    574356 |      18740 |     33325 |   59261 |
   +--------+-----------+-----------+------------+-----------+---------+

                                  Table 2

Corrected Text
--------------
   +--------+-----------+-----------+------------+-----------+---------+
   |   Loss |   Average |   Average |      CUBIC |     CUBIC |   CUBIC |
   | Rate P |     TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |   (C=4) |
   +--------+-----------+-----------+------------+-----------+---------+
   |  10^-2 |        12 |        12 |          1 |         1 |       2 |
   |  10^-3 |        38 |        38 |          3 |         6 |      11 |
   |  10^-4 |       120 |       263 |         19 |        33 |      59 |
   |  10^-5 |       379 |      1795 |        105 |       187 |     333 |
   |  10^-6 |      1200 |     12279 |        593 |      1054 |    1874 |
   |  10^-7 |      3795 |     83981 |       3332 |      5926 |   10538 |
   |  10^-8 |     12000 |    574356 |      18740 |     33325 |   59261 |
   +--------+-----------+-----------+------------+-----------+---------+

                                  Table 2

Notes
-----
The average window size for the CUBIC columns were mostly incorrect in table 2. Corrected them using expression 6

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8312 (draft-ietf-tcpm-cubic-07)
--------------------------------------
Title               : CUBIC for Fast Long-Distance Networks
Publication Date    : February 2018
Author(s)           : I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger
Category            : INFORMATIONAL
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Nov 14 09:47: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 94139120AE8 for ; Thu, 14 Nov 2019 09:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 hZEZxRQUSEgT for ; Thu, 14 Nov 2019 09:47:29 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 E9B95120AE7 for ; Thu, 14 Nov 2019 09:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=E5uX5QmNPaPdiMdeSGyLast/v7A2jFH1/ijCq1mkcwk=; b=NVc0NP81HPRAx5Nku+sNEDGp6a MGLpQ0U0O0Kr8zln1JhQtrqeMqkQto4WA1l122jopfzt1DS/L4Yom9VZXxe/ZMP2aAVQHw61CXzlN IYa21FrIx7wkn5TwTxuOjF0EMax4F3uLpiqckdrrikxpE/yF+NusA5Z+bb5yHaRlumjt9qTym32wK 5S75+db0lF9qp9tDIfmhXN5pf1I0KTZ3Z5XKmdkX0QoY+F1gkOpHQzVAYb48aOkBm85a2vHymXNSn DfEYJlcb5h+CQo+ji27uY02ho+jZLUbqElJgFbG/Efc+NXKKtaZZrycjAVPtfjH/kYZ19IF6LjndZ WT8MC9bA==;
Received: from [212.140.138.217] (port=46544 helo=[10.10.154.161]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iVJDK-0004T4-WD; Thu, 14 Nov 2019 17:47:27 +0000
To: "Scheffenegger, Richard" , "tcpm@ietf.org" , "Scharf, Michael" 
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net> 
From: Bob Briscoe 
Message-ID: <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
Date: Thu, 14 Nov 2019 17:47:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 14 Nov 2019 17:47:31 -0000

Michael,
I'll try to write concrete text before Monday.
Do we have time to discuss this in the TCPM mtg?

Richard, Inline...


Bob

On 14/11/2019 10:06, Scheffenegger, Richard wrote:
> That would special-case the initial AccECN option (value order) from the
> subsequent ones, right?
There's already text in the draft that special-cases the initial AccECN 
option to check the values for middlebox zeroing, and I suspect .

>
> Perhaps placing a different inital value in the first counter would
> implicitly signal this better?
I'll think about this - we can discuss at the hackathon.
Another possibility would be to assign two option kind values for two 
different option orders - I think I prefer this.

>
> The folks from IPPM will not be all too happy with the semantics of
> field values depening on some (possibly missed by passive observation)
> initial value though...
Well, true. But I don't think that's a show-stopper. Two option kind 
values would address this.
>
> Certainly warrants more discussion!
Yup.


Bob



>
> Richard
>
>
> Am 13.11.2019 um 14:30 schrieb Bob Briscoe:
>> Neal,
>>
>> Rather than the IETF have to decide up front which ECT value will be
>> more prevalent, I did suggest the following mechanism to my co-authors.
>> However, even tho it's fairly simple, we decided wasting some space was
>> simpler.
>>
>> Given TCP Option space is in short supply, if the WG prefers, we can
>> include that idea in the spec:...
>>
>> The data sender for each half-connection currently initializes
>>
>>     r.e0b = 1 and r.ceb = r.e1b.= 0
>>
>> then communicates these to the other end in the option. We could make
>> the initial values into a signal that determines whether ECT1 feedback
>> comes first for feedback on that half connection. For example:
>>
>>     r.e0b = 0 and r.ceb = r.e1b.= 1
>>
>> could mean ECT0 & ECT1 will be the other way round.
>>
>>
>> Bob
>>
>> On 12/11/2019 16:09, Mirja Kuehlewind wrote:
>>> Hi Neal,
>>>
>>> that's a good point. The order of the field was based on what is 
>>> expected to be the most likely case. Currently most traffic, if it 
>>> uses ECN at all, will set the codepoint to ECT(0). With deployment 
>>> of L4S this could change in future, however, there are also still 
>>> ways to extend the negotiation in the AccECN TCP handshake to e.g. 
>>> support this case better in future.
>>>
>>> Mirja
>>>
>>>
>>>
>>> On 11.11.19, 18:25, "tcpm on behalf of Neal 
>>> Cardwell">> ncardwell=40google.com@dmarc.ietf.org>  wrote:
>>>
>>>      A particular question in regards to the AccECN option:
>>>
>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6
>>>
>>>      The AccECN option spec lists the EE0B field first, with the 
>>> EE1B field
>>>      at the end.
>>>
>>>      Given that L4S plans on using ECT(1) for data packets, and 
>>> unchanging
>>>      counter values can be omitted from the end of the AccECN 
>>> option, why
>>>      not list EE1B first, and EE0B last? With EE1B first and EE0B 
>>> last it
>>>      seems that in the common case for an L4S connection the 
>>> (unchanged)
>>>      EE0B could be omitted, allowing 4 extra bytes of payload per 
>>> packet.
>>>      AFAICT this extra 4 bytes would increase goodput for applications
>>>      using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
>>>      back-of-the-envelope calculations.
>>>
>>>      best,
>>>      neal
>>>
>>>      _______________________________________________
>>>      tcpm mailing list
>>>      tcpm@ietf.org
>>>      https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>>
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Thu Nov 14 10:01:24 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 F0F8C120AEC for ; Thu, 14 Nov 2019 10:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 x2mHQbk6wOYq for ; Thu, 14 Nov 2019 10:01:18 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 3710E120AE7 for ; Thu, 14 Nov 2019 10:01:17 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id f10so5653048oto.3 for ; Thu, 14 Nov 2019 10:01:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gg9jLy1hDCcu4tmIafKPMRaS3ZZey6Q9QZ2IbKHWYu8=; b=s0mKfeatqrFkCxZfU5Eh9WNyYKo1Y2VeYvWtKgYVSMNh/TdahzUQo0WEjhmQ7r0pIb wfCr6QLR4rPWNyKmGWglww+n++7I6FKayu8Gdf77ssXBTrRNc0WvehePO1hU3Xtn/Ovm H8z7bGdvwGHzn34MuessxXUV2fSWac1H7+3iHyidoWaJ/Ra7idVDt06Rwf+ukZaFpprV sJVWZCq5SRcupAaxedwlfq+6+gUQjXh/E1mADRV1r4o+gZV7QQk9DrtPvSqwpLskxm/m EW3v5wpn8+L0879B6xFjjjkZUWKIohHamT5BvyIsw2H7bHIRvxNYfBZuvY6QcwvDIEf8 DjHA==
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; bh=gg9jLy1hDCcu4tmIafKPMRaS3ZZey6Q9QZ2IbKHWYu8=; b=kpbF/Wy0EgnzI8NEK2ZzXCmqpb67aePdNOgUWxZa36QVxGDwfjue+ff+7NJ+hBax06 ewMNX9/JEkG4lC+rgAzRFSwGwwZQb4VmR6yeXVuK+87orZ/4xW/LWlJFiBppWhrSN9bT DY6F5mm4xBZraDerQHUuuHAHIC1djIHc/8tOtGiJcZUFXPqS30CvUn3jFGzMAkMW942w WCmtVMZF/TTI8ci32VDwiGqjDG7JTqcD7VF5AK6+hnvzH6cc/PvRGeqKqiwMpAeeEe+P a9D2MvXJuNuvE05r4+M8thlhsGR/j0sqfOMoe8as6bFxzQgjLt5f+GwSjjDstnk3zv4h Pz0w==
X-Gm-Message-State: APjAAAW93DmbqAd9reSw840iTQajjy9Xr3RFnU0W0wA6qhEEnR1hZyiZ 023jv18v/Jq1f96YFUYxuK6Obv6GBi9AlErW7Rj+sA==
X-Google-Smtp-Source: APXvYqwKAB0jUXw+rVNOOwESJugf8vfXXi45Suha2J38ywGnUbwTfV7HkFFdbQeTz2KTtjH7ErGoRZ8KPKAgM2bDYXI=
X-Received: by 2002:a05:6830:164d:: with SMTP id h13mr8548791otr.371.1573754476016;  Thu, 14 Nov 2019 10:01:16 -0800 (PST)
MIME-Version: 1.0
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
In-Reply-To: <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
From: Neal Cardwell 
Date: Thu, 14 Nov 2019 13:00:59 -0500
Message-ID: 
To: Bob Briscoe 
Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" , "Scharf, Michael" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 14 Nov 2019 18:01:22 -0000

On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe  wrote:
> On 14/11/2019 10:06, Scheffenegger, Richard wrote:
> > Perhaps placing a different inital value in the first counter would
> > implicitly signal this better?
> I'll think about this - we can discuss at the hackathon.
> Another possibility would be to assign two option kind values for two
> different option orders - I think I prefer this.
>
> >
> > The folks from IPPM will not be all too happy with the semantics of
> > field values depening on some (possibly missed by passive observation)
> > initial value though...
> Well, true. But I don't think that's a show-stopper. Two option kind
> values would address this.

Two option kind values sounds like a nice solution, IMHO. Clear,
simple, and fast.

best,
neal


From nobody Thu Nov 14 13:14:07 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 64E39120AEF for ; Thu, 14 Nov 2019 09:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IE6n9c2HQ_Nz for ; Thu, 14 Nov 2019 09:53:32 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 82B97120AF0 for ; Thu, 14 Nov 2019 09:53:31 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id s71so6047379oih.11 for ; Thu, 14 Nov 2019 09:53:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/QkCD3CfcIuPf4yNU8V5jzYWqA9IMTqQLOFLVBLJtX0=; b=NJ36ZEXjR9WJC2JmIuV9eHEstOeh5y9+9qzOPRnn97iCQKlA1vPgc0NTMWCSFjMJZH 9XLzFgbjeFAWOx/mVuMay/NFUQdhp6dCB6kVVCZ9ZzOPpiNOaUbczcXUELmqu9BeyrlM eu+P7m8PflfKSm/Q0rjeN5Aud45B0MFTeDl+6L+IUa17eQ8DSI4ThYz+53dIHPhdKYiV XGcb+/uaxXOUYkpfsQ8h4SHMm8Nq4v7kDq4BR46laoOcMzol6CNRyqJqKw7bcr23shdB 3IKD4KuD4PczmJVvvIRWY3pdW1Suf7footv3V6Rpmnhwl8zY2e6KWZm5cMZeuDFIWYVH +Smg==
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; bh=/QkCD3CfcIuPf4yNU8V5jzYWqA9IMTqQLOFLVBLJtX0=; b=pjQ5H9CEak3j0Q9DsFsPz4AkPnNqG4rVCJjFO+qrXGZiizm62fGK7glCVoWnZPsVM9 4w3XfmX/jaqKE9O2aGSGjmndktBAuZUYavc6w9ATDpQXnfOSYg6rCoX3rJ+o7j82JEu5 KQG8HXud5XCFnoTgVT1DtpiLRxLCu1NUTUAUa2AzqYuJnjko2LpcKCTrFakHwCwZ90+N LhpKTGkXGCgXz8b/6lb7E7gTSxz2Fkr9/x83paS6+1dqaMb3gan9EEgQnjUztP3LCNLt j1auxGFHj4AfPxziVYkYtzSssV5zbFs5ZjwAZxURFoLkgtJg554yzpve2VXaOtc6Cxas /35g==
X-Gm-Message-State: APjAAAWZF/hx6ODaDAhlHgeaBmhdgwuACOXGOFie6iuGiB4Xj5SNbXqD UDWYWUuRnB965r/SpGs7ko19bbq8sPUxOARRW/RN+A==
X-Google-Smtp-Source: APXvYqymga8tcZxwAnIZckr8dafwd/OHEDPXnUuCnyI6WxjgB9M6v+7P5AJXdAZnq4DEN5wOKSJbEUYBhhim8ok5aiw=
X-Received: by 2002:aca:670b:: with SMTP id z11mr4341691oix.79.1573754010356;  Thu, 14 Nov 2019 09:53:30 -0800 (PST)
MIME-Version: 1.0
References: <20191114020710.3359AF406D8@rfc-editor.org>
In-Reply-To: <20191114020710.3359AF406D8@rfc-editor.org>
From: Neal Cardwell 
Date: Thu, 14 Nov 2019 12:53:14 -0500
Message-ID: 
To: RFC Errata System 
Cc: rhee@ncsu.edu, Lisong Xu , sangtae.ha@colorado.edu,  alexander.zimmermann@rwth-aachen.de, "Eggert, Lars" ,  Richard Scheffenegger , ietf@kuehlewind.net, magnus.westerlund@ericsson.com,  "Scharf, Michael" , Michael Tuexen ,  nsd.ietf@gmail.com, tcpm , elliott.ecton@netpp.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Nov 2019 13:14:07 -0800
Subject: Re: [tcpm] [Technical Errata Reported] RFC8312 (5907)
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, 14 Nov 2019 17:53:35 -0000

On Thu, Nov 14, 2019 at 12:12 PM RFC Errata System
 wrote:
>
> The following errata report has been submitted for RFC8312,
> "CUBIC for Fast Long-Distance Networks".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5907
>
> --------------------------------------
> Type: Technical
> Reported by: Elliott Ecton 
>
> Section: 5.1
>
> Original Text
> -------------
>  +--------+----------+-----------+------------+-----------+----------+
>    |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
>    | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
>    +--------+----------+-----------+------------+-----------+----------+
>    |  10^-2 |       12 |        12 |         12 |        12 |       12 |
>    |  10^-3 |       38 |        38 |         38 |        38 |       59 |
>    |  10^-4 |      120 |       263 |        120 |       187 |      333 |
>    |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
>    |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
>    |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
>    |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
>    +--------+----------+-----------+------------+-----------+----------+
>
>                                   Table 1
>
> Corrected Text
> --------------
>  +--------+----------+-----------+------------+-----------+----------+
>    |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
>    | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
>    +--------+----------+-----------+------------+-----------+----------+
>    |  10^-2 |       12 |        12 |          3 |         6 |       11 |
>    |  10^-3 |       38 |        38 |         19 |        33 |       59 |
>    |  10^-4 |      120 |       263 |        120 |       187 |      333 |
>    |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
>    |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
>    |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
>    |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
>    +--------+----------+-----------+------------+-----------+----------+
>
>                                   Table 1
>
> Notes
> -----
> The CUBIC average window sizes for 10^2 and 10^3 are incorrect in the original text using expression 6.

I strongly suspect that the original text is correct.

Note that the proposed edit would cause the average congestion window
size of CUBIC to be below that of "TCP W", the Reno [RFC5681] window,
in the cases with loss rates of 10^-2 and 10^-3. But as mentioned in
section 4.2. "TCP-Friendly Region", where the native CUBIC curve
computation produces a target congestion window that is lower than the
congestion window Reno would use, the CUBIC algorithm instead uses the
Reno target congestion window. So the average congestion window size
of CUBIC should not be below that of Reno. I believe that is why in
the original table the average congestion window for "TCP W" and CUBIC
match in cases with loss rates of 10^-2 and 10^-3 and with CUBIC using
C=0.04 or C=0.4.

Are there tests or simulations showing CUBIC achieving a lower
congestion window in these cases with loss rates of 10^-2 and 10^-3?

best,
neal


From nobody Thu Nov 14 14:01:16 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 C190D120026; Thu, 14 Nov 2019 14:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 TvpfS1CQYrrq; Thu, 14 Nov 2019 14:01:12 -0800 (PST)
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 8E4CA120024; Thu, 14 Nov 2019 14:01:12 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id z19so8047056wmk.3; Thu, 14 Nov 2019 14:01:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=Yt38aKGLafAVc1dSZE6V84MI8E0xmXrf2MMGeYuDB80=; b=cAvP5dN2cWSzE1u+U2fZifsddyCI+c+KeJBI2rmL3Q+ki8ZhbsGPyKcDf5mgDHZVEh sx8O4jWCxZgRbnOnw4ymn6e0E0PKvhndsjFMxU5/SEKPChf16dZP7nVnruevZEswl0Pr B2ZUJQL6RBIMtr8s9OmF2srazmr1hKXARO0Wraz8v9QRuynXPykxnv6a69k7bVH/AYXq 7HRCCDv1wLaoosgXDNZZm4nY9HFh+pPsopXFX1/SCYAStoC4WTDcJz3UD5VAtkcEZryy 8vxBCRvd3rwLqhB2hrLXWq1wcW4VXVjwPxknv/bR0pPULiHgiMvxqRJaT3mUONBCWCyD gL9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Yt38aKGLafAVc1dSZE6V84MI8E0xmXrf2MMGeYuDB80=; b=Q45uAAHrjnAmuJ9bywobWkYJtTi0YmYwBZjTr87mNN+03k/cbfbbo0C+7s72ZsTHdz VMpNROBaFE8bO4Ahg60Rnqoz/vDUU/8bBLkJWAT/cIK9kSGcd36jog8MUhmPMG8MyHjU lxGP9Fsc7G7zhJ7CRwV5IZD/E4BDVTEQwpShuSgtXF65URIcKPdLQ2RVDwXnI620Uq7Q EMejNuEdlLExjLSnG9XXjN/9n6KrTzgY2kygIQlk3TqlqmX5thdtnVnEG/U0L1ThEtto HHdnFq/gs3hubG5EV+khP2nfg5THmF3YGdJWV9L4b+bnOFNrETMTvv5BXjdlKzE0bSlh AnMg==
X-Gm-Message-State: APjAAAVWDWH95a+Lay7ae701L7OzKRH/uknxUPLEyd0d4qY4c8yuKjox FbMygPdlU20R0UR10omVakGvTTWT8w0YVjBJXKaLKM2U
X-Google-Smtp-Source: APXvYqy9/MUMNege4l8e7YMy/j+EOTcq8h6tAlc7VLXZR9+yA+jjy+XJ5jaxWOre6qq3vGSMaZs9Ej8VUcUg5qBmKKM=
X-Received: by 2002:a05:600c:21d9:: with SMTP id x25mr11490304wmj.50.1573768870778;  Thu, 14 Nov 2019 14:01:10 -0800 (PST)
MIME-Version: 1.0
From: Yoshifumi Nishida 
Date: Thu, 14 Nov 2019 14:00:58 -0800
Message-ID: 
To: "tcpm@ietf.org Extensions" 
Cc: tcpm-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000805d840597559ead"
Archived-At: 
Subject: [tcpm] draft agenda for Singapore meeting
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, 14 Nov 2019 22:01:15 -0000

--000000000000805d840597559ead
Content-Type: text/plain; charset="UTF-8"

Hi,
We are still working on building agenda, but here's the current status.
Please let us know if you have any questions or requests.

https://datatracker.ietf.org/meeting/106/materials/agenda-106-tcpm-02.txt

For folks who will make presentations at the meeting,
  Please submit your presentation material * by Thursday Morning (11/21) *
We appreciate your cooperation.

Thanks,
--
tcpm co-chairs

--000000000000805d840597559ead
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--000000000000805d840597559ead--


From nobody Thu Nov 14 14:01:52 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 9F1C412001E; Thu, 14 Nov 2019 14:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] 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 Y0WtqxL7LTpx; Thu, 14 Nov 2019 14:01:49 -0800 (PST)
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 1BE3C12000F; Thu, 14 Nov 2019 14:01:49 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A20E025A1B; Thu, 14 Nov 2019 23:01:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573768907; bh=GbHOwmUPVdyDLPQUrHCyn36jcTnet0AfMbaY25OaIO0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=P30fXG0wxlY751Bj3allbGTFzGFrku05AuFVWhLqYPeKPzr6YUOc1dcBkUe0mab3m BwF105hNm+JHTKeyx3m8nfe2mxaFCP+4pj1DFLqho6mkIyN79zJs4oG3aC7Yg26dhX yWfRozQTqOZpf9+m0FcwnvVBeAFzEAq6MFE7Xv20=
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 bXJPdjkHKwjt; Thu, 14 Nov 2019 23:01:45 +0100 (CET)
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; Thu, 14 Nov 2019 23:01:45 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 14 Nov 2019 23:01:44 +0100
From: "Scharf, Michael" 
To: Bob Briscoe , "Scheffenegger, Richard" , "tcpm@ietf.org" 
CC: "tcpm-chairs@ietf.org" 
Thread-Topic: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
Thread-Index: AQHVmLUL8707rVPe1ES9nrAQ4+JPDKeHpN6AgAFl8wCAAVlRAIAAgNOAgABXotA=
Date: Thu, 14 Nov 2019 22:01:44 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D50CAF5@rznt8114.rznt.rzdir.fht-esslingen.de>
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
In-Reply-To: <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.63.15]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 14 Nov 2019 22:01:52 -0000

SSBhbSBuZWl0aGVyIHRoZSBzaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudCBub3IgdGhlIG93bmVy
IG9mIHRoZSBtZWV0aW5nIGFnZW5kYS4gPT4gWW9zaGkNCg0KTWljaGFlbA0KDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2Uu
bmV0Pg0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTQsIDIwMTkgNjo0NyBQTQ0KPiBUbzog
U2NoZWZmZW5lZ2dlciwgUmljaGFyZCA8cnMuaWV0ZkBnbXguYXQ+OyB0Y3BtQGlldGYub3JnOyBT
Y2hhcmYsIE1pY2hhZWwNCj4gPE1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT4NCj4gU3Vi
amVjdDogUmU6IFt0Y3BtXSBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA5OiBBY2NFQ04g
b3B0aW9uOiB3aHkgbm90DQo+IEVFMUIgZmlyc3Q/DQo+IA0KPiBNaWNoYWVsLA0KPiBJJ2xsIHRy
eSB0byB3cml0ZSBjb25jcmV0ZSB0ZXh0IGJlZm9yZSBNb25kYXkuDQo+IERvIHdlIGhhdmUgdGlt
ZSB0byBkaXNjdXNzIHRoaXMgaW4gdGhlIFRDUE0gbXRnPw0KPiANCj4gUmljaGFyZCwgSW5saW5l
Li4uDQo+IA0KPiANCj4gQm9iDQo+IA0KPiBPbiAxNC8xMS8yMDE5IDEwOjA2LCBTY2hlZmZlbmVn
Z2VyLCBSaWNoYXJkIHdyb3RlOg0KPiA+IFRoYXQgd291bGQgc3BlY2lhbC1jYXNlIHRoZSBpbml0
aWFsIEFjY0VDTiBvcHRpb24gKHZhbHVlIG9yZGVyKSBmcm9tIHRoZQ0KPiA+IHN1YnNlcXVlbnQg
b25lcywgcmlnaHQ/DQo+IFRoZXJlJ3MgYWxyZWFkeSB0ZXh0IGluIHRoZSBkcmFmdCB0aGF0IHNw
ZWNpYWwtY2FzZXMgdGhlIGluaXRpYWwgQWNjRUNODQo+IG9wdGlvbiB0byBjaGVjayB0aGUgdmFs
dWVzIGZvciBtaWRkbGVib3ggemVyb2luZywgYW5kIEkgc3VzcGVjdCAuDQo+IA0KPiA+DQo+ID4g
UGVyaGFwcyBwbGFjaW5nIGEgZGlmZmVyZW50IGluaXRhbCB2YWx1ZSBpbiB0aGUgZmlyc3QgY291
bnRlciB3b3VsZA0KPiA+IGltcGxpY2l0bHkgc2lnbmFsIHRoaXMgYmV0dGVyPw0KPiBJJ2xsIHRo
aW5rIGFib3V0IHRoaXMgLSB3ZSBjYW4gZGlzY3VzcyBhdCB0aGUgaGFja2F0aG9uLg0KPiBBbm90
aGVyIHBvc3NpYmlsaXR5IHdvdWxkIGJlIHRvIGFzc2lnbiB0d28gb3B0aW9uIGtpbmQgdmFsdWVz
IGZvciB0d28NCj4gZGlmZmVyZW50IG9wdGlvbiBvcmRlcnMgLSBJIHRoaW5rIEkgcHJlZmVyIHRo
aXMuDQo+IA0KPiA+DQo+ID4gVGhlIGZvbGtzIGZyb20gSVBQTSB3aWxsIG5vdCBiZSBhbGwgdG9v
IGhhcHB5IHdpdGggdGhlIHNlbWFudGljcyBvZg0KPiA+IGZpZWxkIHZhbHVlcyBkZXBlbmluZyBv
biBzb21lIChwb3NzaWJseSBtaXNzZWQgYnkgcGFzc2l2ZSBvYnNlcnZhdGlvbikNCj4gPiBpbml0
aWFsIHZhbHVlIHRob3VnaC4uLg0KPiBXZWxsLCB0cnVlLiBCdXQgSSBkb24ndCB0aGluayB0aGF0
J3MgYSBzaG93LXN0b3BwZXIuIFR3byBvcHRpb24ga2luZA0KPiB2YWx1ZXMgd291bGQgYWRkcmVz
cyB0aGlzLg0KPiA+DQo+ID4gQ2VydGFpbmx5IHdhcnJhbnRzIG1vcmUgZGlzY3Vzc2lvbiENCj4g
WXVwLg0KPiANCj4gDQo+IEJvYg0KPiANCj4gDQo+IA0KPiA+DQo+ID4gUmljaGFyZA0KPiA+DQo+
ID4NCj4gPiBBbSAxMy4xMS4yMDE5IHVtIDE0OjMwIHNjaHJpZWIgQm9iIEJyaXNjb2U6DQo+ID4+
IE5lYWwsDQo+ID4+DQo+ID4+IFJhdGhlciB0aGFuIHRoZSBJRVRGIGhhdmUgdG8gZGVjaWRlIHVw
IGZyb250IHdoaWNoIEVDVCB2YWx1ZSB3aWxsIGJlDQo+ID4+IG1vcmUgcHJldmFsZW50LCBJIGRp
ZCBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgbWVjaGFuaXNtIHRvIG15IGNvLWF1dGhvcnMuDQo+ID4+
IEhvd2V2ZXIsIGV2ZW4gdGhvIGl0J3MgZmFpcmx5IHNpbXBsZSwgd2UgZGVjaWRlZCB3YXN0aW5n
IHNvbWUgc3BhY2Ugd2FzDQo+ID4+IHNpbXBsZXIuDQo+ID4+DQo+ID4+IEdpdmVuIFRDUCBPcHRp
b24gc3BhY2UgaXMgaW4gc2hvcnQgc3VwcGx5LCBpZiB0aGUgV0cgcHJlZmVycywgd2UgY2FuDQo+
ID4+IGluY2x1ZGUgdGhhdCBpZGVhIGluIHRoZSBzcGVjOi4uLg0KPiA+Pg0KPiA+PiBUaGUgZGF0
YSBzZW5kZXIgZm9yIGVhY2ggaGFsZi1jb25uZWN0aW9uIGN1cnJlbnRseSBpbml0aWFsaXplcw0K
PiA+Pg0KPiA+PiDCoMKgwqDCoHIuZTBiID0gMSBhbmQgci5jZWIgPSByLmUxYi49IDANCj4gPj4N
Cj4gPj4gdGhlbiBjb21tdW5pY2F0ZXMgdGhlc2UgdG8gdGhlIG90aGVyIGVuZCBpbiB0aGUgb3B0
aW9uLiBXZSBjb3VsZCBtYWtlDQo+ID4+IHRoZSBpbml0aWFsIHZhbHVlcyBpbnRvIGEgc2lnbmFs
IHRoYXQgZGV0ZXJtaW5lcyB3aGV0aGVyIEVDVDEgZmVlZGJhY2sNCj4gPj4gY29tZXMgZmlyc3Qg
Zm9yIGZlZWRiYWNrIG9uIHRoYXQgaGFsZiBjb25uZWN0aW9uLiBGb3IgZXhhbXBsZToNCj4gPj4N
Cj4gPj4gwqDCoMKgwqByLmUwYiA9IDAgYW5kIHIuY2ViID0gci5lMWIuPSAxDQo+ID4+DQo+ID4+
IGNvdWxkIG1lYW4gRUNUMCAmIEVDVDEgd2lsbCBiZSB0aGUgb3RoZXIgd2F5IHJvdW5kLg0KPiA+
Pg0KPiA+Pg0KPiA+PiBCb2INCj4gPj4NCj4gPj4gT24gMTIvMTEvMjAxOSAxNjowOSwgTWlyamEg
S3VlaGxld2luZCB3cm90ZToNCj4gPj4+IEhpIE5lYWwsDQo+ID4+Pg0KPiA+Pj4gdGhhdCdzIGEg
Z29vZCBwb2ludC4gVGhlIG9yZGVyIG9mIHRoZSBmaWVsZCB3YXMgYmFzZWQgb24gd2hhdCBpcw0K
PiA+Pj4gZXhwZWN0ZWQgdG8gYmUgdGhlIG1vc3QgbGlrZWx5IGNhc2UuIEN1cnJlbnRseSBtb3N0
IHRyYWZmaWMsIGlmIGl0DQo+ID4+PiB1c2VzIEVDTiBhdCBhbGwsIHdpbGwgc2V0IHRoZSBjb2Rl
cG9pbnQgdG8gRUNUKDApLiBXaXRoIGRlcGxveW1lbnQNCj4gPj4+IG9mIEw0UyB0aGlzIGNvdWxk
IGNoYW5nZSBpbiBmdXR1cmUsIGhvd2V2ZXIsIHRoZXJlIGFyZSBhbHNvIHN0aWxsDQo+ID4+PiB3
YXlzIHRvIGV4dGVuZCB0aGUgbmVnb3RpYXRpb24gaW4gdGhlIEFjY0VDTiBUQ1AgaGFuZHNoYWtl
IHRvIGUuZy4NCj4gPj4+IHN1cHBvcnQgdGhpcyBjYXNlIGJldHRlciBpbiBmdXR1cmUuDQo+ID4+
Pg0KPiA+Pj4gTWlyamENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IO+7v09uIDExLjExLjE5
LCAxODoyNSwgInRjcG0gb24gYmVoYWxmIG9mIE5lYWwNCj4gPj4+IENhcmR3ZWxsIjx0Y3BtLWJv
dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mDQo+ID4+PiBuY2FyZHdlbGw9NDBnb29nbGUuY29t
QGRtYXJjLmlldGYub3JnPsKgIHdyb3RlOg0KPiA+Pj4NCj4gPj4+IMKgwqDCoMKgIEEgcGFydGlj
dWxhciBxdWVzdGlvbiBpbiByZWdhcmRzIHRvIHRoZSBBY2NFQ04gb3B0aW9uOg0KPiA+Pj4NCj4g
Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt
ZWNuLTA5I3NlY3Rpb24tMy4yLjYNCj4gPj4+DQo+ID4+PiDCoMKgwqDCoCBUaGUgQWNjRUNOIG9w
dGlvbiBzcGVjIGxpc3RzIHRoZSBFRTBCIGZpZWxkIGZpcnN0LCB3aXRoIHRoZQ0KPiA+Pj4gRUUx
QiBmaWVsZA0KPiA+Pj4gwqDCoMKgwqAgYXQgdGhlIGVuZC4NCj4gPj4+DQo+ID4+PiDCoMKgwqDC
oCBHaXZlbiB0aGF0IEw0UyBwbGFucyBvbiB1c2luZyBFQ1QoMSkgZm9yIGRhdGEgcGFja2V0cywg
YW5kDQo+ID4+PiB1bmNoYW5naW5nDQo+ID4+PiDCoMKgwqDCoCBjb3VudGVyIHZhbHVlcyBjYW4g
YmUgb21pdHRlZCBmcm9tIHRoZSBlbmQgb2YgdGhlIEFjY0VDTg0KPiA+Pj4gb3B0aW9uLCB3aHkN
Cj4gPj4+IMKgwqDCoMKgIG5vdCBsaXN0IEVFMUIgZmlyc3QsIGFuZCBFRTBCIGxhc3Q/IFdpdGgg
RUUxQiBmaXJzdCBhbmQgRUUwQg0KPiA+Pj4gbGFzdCBpdA0KPiA+Pj4gwqDCoMKgwqAgc2VlbXMg
dGhhdCBpbiB0aGUgY29tbW9uIGNhc2UgZm9yIGFuIEw0UyBjb25uZWN0aW9uIHRoZQ0KPiA+Pj4g
KHVuY2hhbmdlZCkNCj4gPj4+IMKgwqDCoMKgIEVFMEIgY291bGQgYmUgb21pdHRlZCwgYWxsb3dp
bmcgNCBleHRyYSBieXRlcyBvZiBwYXlsb2FkIHBlcg0KPiA+Pj4gcGFja2V0Lg0KPiA+Pj4gwqDC
oMKgwqAgQUZBSUNUIHRoaXMgZXh0cmEgNCBieXRlcyB3b3VsZCBpbmNyZWFzZSBnb29kcHV0IGZv
ciBhcHBsaWNhdGlvbnMNCj4gPj4+IMKgwqDCoMKgIHVzaW5nIElQdjQgb3IgSVB2NiB3aXRoIGFu
IE1UVSBvZiAxNTAwIGJ5IGFib3V0IDAuMyUsIGJ5IG15DQo+ID4+PiDCoMKgwqDCoCBiYWNrLW9m
LXRoZS1lbnZlbG9wZSBjYWxjdWxhdGlvbnMuDQo+ID4+Pg0KPiA+Pj4gwqDCoMKgwqAgYmVzdCwN
Cj4gPj4+IMKgwqDCoMKgIG5lYWwNCj4gPj4+DQo+ID4+PiDCoMKgwqDCoCBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gwqDCoMKgwqAgdGNwbSBt
YWlsaW5nIGxpc3QNCj4gPj4+IMKgwqDCoMKgIHRjcG1AaWV0Zi5vcmcNCj4gPj4+IMKgwqDCoMKg
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+Pj4NCj4gPj4+
DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gQm9iIEJyaXNjb2VodHRwOi8v
Ym9iYnJpc2NvZS5uZXQvDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4+IHRj
cG1AaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90
Y3BtDQo+ID4+DQo+IA0KPiAtLQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJvYiBCcmlzY29lICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K


From nobody Thu Nov 14 14:11: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 750AF120025 for ; Thu, 14 Nov 2019 14:11:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 k5ZiwJqVEewJ for ; Thu, 14 Nov 2019 14:11:03 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 D938F120019 for ; Thu, 14 Nov 2019 14:11:02 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id w9so8643759wrr.0 for ; Thu, 14 Nov 2019 14:11:02 -0800 (PST)
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; bh=vUeU1+hgjpSvfv49RCy56+NIqhXBUfIyYryCYRBNVnw=; b=hFaFdHGSov0wCyS1CfEc0wbAXoRUCvRXYX36EzU6fOGmvnudhU1mX0WKe9W736KULN saDS1QQ346lh5gjUVPAIUCzjF42sCY70FFdwHpzuyIil3e6YFVxf2PjEDICUhlsDYySk s0rY9V5/YMwL75wB9RG7mE9pO9+ktY+mSWH85hNy7r3j3jPUQxc3BtXvZCRdOmLoMyl9 uhho3E4J921sDkyBzXq5uDeS0Ys482pQF1E5nSlax1qRxgn/BYexRZpyzhjjvO37n4Ls pho/lxNI2CczWrTxJvQvsQE7zHK3fGOoxUdCIUbGxGB5+7J66+QIOEZZ9mkKXdhch62Y ED9A==
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; bh=vUeU1+hgjpSvfv49RCy56+NIqhXBUfIyYryCYRBNVnw=; b=AY5B4WJnklcloPb3p3+KbjpDyxX8hgj1GG/2BeDqqfhiymnfKPCWfv1zfS1k/EsFoI i7Ur9BMts3VMyR+x8uRIas1OdM9MmJv27U6ksfHYAuyZ4yLTnbm7a5vekECZdHPnOhDl HfmK+QhTSn2fvnf2wYOSdkcPhSp9QQ8UM/Qr8lwNbw4rOZa4I3kMu7fJI/ulGY9FVKCg dLL7U4GGbbu2BeJLiXkm2JGvM/Fx8OwivCDPCLoEIapL20giUqguus/Yzum/kMuOpNew xSJ5pkNuXGSKDBw01G1DfT0BnXCuVvK599B6E6nCwOMEhflHQZg7L4aY5y7P/iF6oSQt iOYw==
X-Gm-Message-State: APjAAAVcWT3pIuzcSBg5L9LPQE/zQcc+E/vhuOU74jtRWmtvycSJXf5Q Hfw4XEmnsmbfJJKpN9CzN9F0/JFZLSYiKwzL/pg=
X-Google-Smtp-Source: APXvYqz0Lk4hxqYmQUnxOC49+HQ+V2/4g69CNZ+wczhAXRx43yfKjZW4dlgpiVpfZadrFSz76nfJ3qOBm3cE7XWfQaw=
X-Received: by 2002:adf:d842:: with SMTP id k2mr11015003wrl.163.1573769461365;  Thu, 14 Nov 2019 14:11:01 -0800 (PST)
MIME-Version: 1.0
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
In-Reply-To: <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>
From: Yoshifumi Nishida 
Date: Thu, 14 Nov 2019 14:10:49 -0800
Message-ID: 
To: Bob Briscoe 
Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" , "Scharf, Michael" 
Content-Type: multipart/alternative; boundary="000000000000b3fe47059755c1f5"
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 14 Nov 2019 22:11:06 -0000

--000000000000b3fe47059755c1f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bob,
You can make a request. We'll think about it and will get back to you.
--
Yoshi

On Thu, Nov 14, 2019 at 9:47 AM Bob Briscoe  wrote:

> Michael,
> I'll try to write concrete text before Monday.
> Do we have time to discuss this in the TCPM mtg?
>
> Richard, Inline...
>
>
> Bob
>
> On 14/11/2019 10:06, Scheffenegger, Richard wrote:
> > That would special-case the initial AccECN option (value order) from th=
e
> > subsequent ones, right?
> There's already text in the draft that special-cases the initial AccECN
> option to check the values for middlebox zeroing, and I suspect .
>
> >
> > Perhaps placing a different inital value in the first counter would
> > implicitly signal this better?
> I'll think about this - we can discuss at the hackathon.
> Another possibility would be to assign two option kind values for two
> different option orders - I think I prefer this.
>
> >
> > The folks from IPPM will not be all too happy with the semantics of
> > field values depening on some (possibly missed by passive observation)
> > initial value though...
> Well, true. But I don't think that's a show-stopper. Two option kind
> values would address this.
> >
> > Certainly warrants more discussion!
> Yup.
>
>
> Bob
>
>
>
> >
> > Richard
> >
> >
> > Am 13.11.2019 um 14:30 schrieb Bob Briscoe:
> >> Neal,
> >>
> >> Rather than the IETF have to decide up front which ECT value will be
> >> more prevalent, I did suggest the following mechanism to my co-authors=
.
> >> However, even tho it's fairly simple, we decided wasting some space wa=
s
> >> simpler.
> >>
> >> Given TCP Option space is in short supply, if the WG prefers, we can
> >> include that idea in the spec:...
> >>
> >> The data sender for each half-connection currently initializes
> >>
> >>     r.e0b =3D 1 and r.ceb =3D r.e1b.=3D 0
> >>
> >> then communicates these to the other end in the option. We could make
> >> the initial values into a signal that determines whether ECT1 feedback
> >> comes first for feedback on that half connection. For example:
> >>
> >>     r.e0b =3D 0 and r.ceb =3D r.e1b.=3D 1
> >>
> >> could mean ECT0 & ECT1 will be the other way round.
> >>
> >>
> >> Bob
> >>
> >> On 12/11/2019 16:09, Mirja Kuehlewind wrote:
> >>> Hi Neal,
> >>>
> >>> that's a good point. The order of the field was based on what is
> >>> expected to be the most likely case. Currently most traffic, if it
> >>> uses ECN at all, will set the codepoint to ECT(0). With deployment
> >>> of L4S this could change in future, however, there are also still
> >>> ways to extend the negotiation in the AccECN TCP handshake to e.g.
> >>> support this case better in future.
> >>>
> >>> Mirja
> >>>
> >>>
> >>>
> >>> =EF=BB=BFOn 11.11.19, 18:25, "tcpm on behalf of Neal
> >>> Cardwell" >>> ncardwell=3D40google.com@dmarc.ietf.org>  wrote:
> >>>
> >>>      A particular question in regards to the AccECN option:
> >>>
> >>>
> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6
> >>>
> >>>      The AccECN option spec lists the EE0B field first, with the
> >>> EE1B field
> >>>      at the end.
> >>>
> >>>      Given that L4S plans on using ECT(1) for data packets, and
> >>> unchanging
> >>>      counter values can be omitted from the end of the AccECN
> >>> option, why
> >>>      not list EE1B first, and EE0B last? With EE1B first and EE0B
> >>> last it
> >>>      seems that in the common case for an L4S connection the
> >>> (unchanged)
> >>>      EE0B could be omitted, allowing 4 extra bytes of payload per
> >>> packet.
> >>>      AFAICT this extra 4 bytes would increase goodput for application=
s
> >>>      using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
> >>>      back-of-the-envelope calculations.
> >>>
> >>>      best,
> >>>      neal
> >>>
> >>>      _______________________________________________
> >>>      tcpm mailing list
> >>>      tcpm@ietf.org
> >>>      https://www.ietf.org/mailman/listinfo/tcpm
> >>>
> >>>
> >>
> >> --
> >> ________________________________________________________________
> >> Bob Briscoehttp://bobbriscoe.net/
> >>
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--000000000000b3fe47059755c1f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Bob,=C2=A0
You can make a request. We=
9;ll think about it and will get back to you.
--
Yoshi<=
/div>
O=
n Thu, Nov 14, 2019 at 9:47 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
Michael,

I'll try to write concrete text before Monday.

Do we have time to discuss this in the TCPM mtg?



Richard, Inline...





Bob



On 14/11/2019 10:06, Scheffenegger, Richard wrote:

> That would special-case the initial AccECN option (value order) from t=
he

> subsequent ones, right?

There's already text in the draft that special-cases the initial AccECN=
 

option to check the values for middlebox zeroing, and I suspect .



>

> Perhaps placing a different inital value in the first counter would
> implicitly signal this better?

I'll think about this - we can discuss at the hackathon.

Another possibility would be to assign two option kind values for two 

different option orders - I think I prefer this.



>

> The folks from IPPM will not be all too happy with the semantics of
> field values depening on some (possibly missed by passive observation)=


> initial value though...

Well, true. But I don't think that's a show-stopper. Two option kin=
d 

values would address this.

>

> Certainly warrants more discussion!

Yup.





Bob







>

> Richard

>

>

> Am 13.11.2019 um 14:30 schrieb Bob Briscoe:

>> Neal,

>>

>> Rather than the IETF have to decide up front which ECT value will =
be

>> more prevalent, I did suggest the following mechanism to my co-aut=
hors.

>> However, even tho it's fairly simple, we decided wasting some =
space was

>> simpler.

>>

>> Given TCP Option space is in short supply, if the WG prefers, we c=
an

>> include that idea in the spec:...

>>

>> The data sender for each half-connection currently initializes

>>

>> =C2=A0=C2=A0=C2=A0=C2=A0r.e0b =3D 1 and r.ceb =3D r.e1b.=3D 0

>>

>> then communicates these to the other end in the option. We could m=
ake

>> the initial values into a signal that determines whether ECT1 feed=
back

>> comes first for feedback on that half connection. For example:

>>

>> =C2=A0=C2=A0=C2=A0=C2=A0r.e0b =3D 0 and r.ceb =3D r.e1b.=3D 1

>>

>> could mean ECT0 & ECT1 will be the other way round.

>>

>>

>> Bob

>>

>> On 12/11/2019 16:09, Mirja Kuehlewind wrote:

>>> Hi Neal,

>>>

>>> that's a good point. The order of the field was based on w=
hat is 

>>> expected to be the most likely case. Currently most traffic, i=
f it 

>>> uses ECN at all, will set the codepoint to ECT(0). With deploy=
ment 

>>> of L4S this could change in future, however, there are also st=
ill 

>>> ways to extend the negotiation in the AccECN TCP handshake to =
e.g. 

>>> support this case better in future.

>>>

>>> Mirja

>>>

>>>

>>>

>>> =EF=BB=BFOn 11.11.19, 18:25, "tcpm on behalf of Neal 

>>> Cardwell"<tcpm-bounces@ietf.org on behalf of 

>>> ncardwell=3D40google.com@dmarc.ietf.org>=C2=A0 wrote:

>>>

>>> =C2=A0=C2=A0=C2=A0=C2=A0 A particular question in regards to t=
he AccECN option:

>>>

>>> https://tools.=
ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6

>>>

>>> =C2=A0=C2=A0=C2=A0=C2=A0 The AccECN option spec lists the EE0B=
 field first, with the 

>>> EE1B field

>>> =C2=A0=C2=A0=C2=A0=C2=A0 at the end.

>>>

>>> =C2=A0=C2=A0=C2=A0=C2=A0 Given that L4S plans on using ECT(1) =
for data packets, and 

>>> unchanging

>>> =C2=A0=C2=A0=C2=A0=C2=A0 counter values can be omitted from th=
e end of the AccECN 

>>> option, why

>>> =C2=A0=C2=A0=C2=A0=C2=A0 not list EE1B first, and EE0B last? W=
ith EE1B first and EE0B 

>>> last it

>>> =C2=A0=C2=A0=C2=A0=C2=A0 seems that in the common case for an =
L4S connection the 

>>> (unchanged)

>>> =C2=A0=C2=A0=C2=A0=C2=A0 EE0B could be omitted, allowing 4 ext=
ra bytes of payload per 

>>> packet.

>>> =C2=A0=C2=A0=C2=A0=C2=A0 AFAICT this extra 4 bytes would incre=
ase goodput for applications

>>> =C2=A0=C2=A0=C2=A0=C2=A0 using IPv4 or IPv6 with an MTU of 150=
0 by about 0.3%, by my

>>> =C2=A0=C2=A0=C2=A0=C2=A0 back-of-the-envelope calculations.
>>>

>>> =C2=A0=C2=A0=C2=A0=C2=A0 best,

>>> =C2=A0=C2=A0=C2=A0=C2=A0 neal

>>>

>>> =C2=A0=C2=A0=C2=A0=C2=A0 _____________________________________=
__________

>>> =C2=A0=C2=A0=C2=A0=C2=A0 tcpm mailing list

>>> =C2=A0=C2=A0=C2=A0=C2=A0 tcpm@ietf.org

>>> =C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org=
/mailman/listinfo/tcpm

>>>

>>>

>>

>> -- 

>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/

>>

>>

>> _______________________________________________

>> tcpm mailing list

>> tcpm@ietf.org

>> https://www.ietf.org/mailman/listinfo/tcpm
>>



-- 

________________________________________________________________

Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm




--000000000000b3fe47059755c1f5--


From nobody Fri Nov 15 04:05:31 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 849AB120820 for ; Fri, 15 Nov 2019 04:05:28 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 W9_4YIbsPBZ2 for ; Fri, 15 Nov 2019 04:05:26 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 603AA1200F4 for ; Fri, 15 Nov 2019 04:05:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573819475; bh=cH6Vqrt5bIGrz5BOaKBCQRCK0oxlvuDzEROyMoEs+3g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=BWdoKbj2APpYhg5dzQyDFUCNdJ/VR1B615Luo2Ei2R7wAgCjzceaU/Ai7XY8EYpV/ wQQiBhKwilx0HAaFeWyqUg/PqCQ//vSeBwJlAO5XsjHkAwgNeM72oqS7mbOj4vfScL 68/jgMuMogiYxQcBBIKgPqedp4nNHAiToq99qqDk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.65.107] ([217.70.211.11]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MgesG-1hxKz10tRs-00h9UT; Fri, 15 Nov 2019 13:04:35 +0100
To: Neal Cardwell , Bob Briscoe 
Cc: "tcpm@ietf.org" , "Scharf, Michael" 
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net> 
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Fri, 15 Nov 2019 13:04:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:WG8/rm9SFWukf1hsLOsF5f98xOpFA6FFCFxSCHlFVq99nYDERqC pC8OsmbhFmc4/Vbl4aGJE+Be5va6s6Vq5NmBGgqEnQOZlZs4poufcQ6Qbavx1Bum2B+ZSk1 m6Tb8AwK3eDQqAL9lxGBQKbNJOBgQx6f3kO+UNha61Nj/uA+MOR7AQKCadjPo0aUKhO7ELV mf/HSliuwZHfPCmvINhRQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:63QQoG3JaDg=:9fHEgkw+8K8uPwI3Op5CTd +a3ruK651/bNPZAWpxo7wOCmzSBKO3McwcSv/KEcJ0WoMWfMFmyjOLFTaKuixjOL76f8+7EXy Ej7gzU1mWsUyY4nWW7u+zN8c7ol5tvxJDlTRdREET3OEGOpq1XAHqQfidrrHoJZ7IWsXHW7vF vkc86JO4BvY1vrqT1pyjcE4KggEcDpjP24Lcoy1nygUXK1TpB72tCTKEHTy8ZuGN8eOnPqaPe DRQudwjedFB80t5U47tVCdDS/Ph6WwCw9D3cdBlMH24708qxV4gQA6hF9DbULgiNMO/d6cXC6 TIyI/ILXqjN7WPn8cSb+I9OjLK+yD/0sVCls0hNN7Ik+i1M4qU8rFGJ+YXZbvZK8n6PpfSUAS e5rZ3KHd6NNR5X7tLn2af76Qzrh6M/ztxfMi5YfyEKI/ipLtsNE+Fi0TIOgofWq4vd901pvHE aPZPU8hQ61d9gQ8t1XA3Z0MxfXrCVS3eqXv0d5dJySbZIH02KwIj6lhzB7xQ5GsmfXiasoX0t 6RKp6URPEj65dY2hsJdpKsRTlasfHRQ7GzF9GHiQ7TDuM0zH0dvJ6OMCGkcfpYtiIDV/PVp8m dAyN0jRdNY0TcpK198ugwMtRnXyocF3JxgGrt4+6KHt4uKDYh/yScmZzChqPVZA+eJdx54xgr iqy6zCcRKsmKf3Nl3m4YDx9KXbRWjHnnUbepNDaMECD3d/P2ZaxVsvgSQb3SDyUIdsMI1UP+q MDv4cwi/M0sKV0YRgOyeEI7s9aaWdNKTgZ9FyS94NznbRlHDTy4NNTI/9PD855ZQhI/Z2p8Fi tTHJUeNWAxEgcCMX4AiSg5yN4gNL+kxYNQrzmyObZx+tWJu9RFnTDmtT+oSodsVCJoaFP9vqY KQ9Cchtfj08t1YkFLgbpd/Ls0WU/jIv5swCv1DYcTRDOIGFTijlhxT1OnOjhZ3FfzGMMgAM5u T2uuKNuXXnmctKvbgqTTby+2QYhbIM7THbVnRxfpBtLAZPz2xEjuDkwjwdk0GxgAGiEjmmqen 9lRBkQiswAphCNRRi2rus+tKzIZghg9v7Fwg0LWETGlqt9tVv34FQ2dkSrAR1e6eHPV9wW1PV u9eI+NDJELFeES7boAe/Tu9BYAfZ2lLHUUmkfGljyCNZuHmcq3IxUwAkNmQ/7N3cPvD+ywje8 lZtdVLz+j1mcoQ4j3yzigq1GIZBWsYqFOurMfe9wF7Vp8ht4SZzNNfsPps1Lqd26cQ0UuT7EE CRrUKR0bPyjuN8O6cGOukxk1ye7F0kRi8IQwYeg==
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 15 Nov 2019 12:05:29 -0000

I too like two different option numbers more than initial magic numbers
- we aren't yet that constrained in the tcp options registry to not go
that route...

Richard


Am 14.11.2019 um 19:00 schrieb Neal Cardwell:
> On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe  wrote=
:
>> On 14/11/2019 10:06, Scheffenegger, Richard wrote:
>>> Perhaps placing a different inital value in the first counter would
>>> implicitly signal this better?
>> I'll think about this - we can discuss at the hackathon.
>> Another possibility would be to assign two option kind values for two
>> different option orders - I think I prefer this.
>>
>>>
>>> The folks from IPPM will not be all too happy with the semantics of
>>> field values depening on some (possibly missed by passive observation)
>>> initial value though...
>> Well, true. But I don't think that's a show-stopper. Two option kind
>> values would address this.
>
> Two option kind values sounds like a nice solution, IMHO. Clear,
> simple, and fast.
>
> best,
> neal
>


From nobody Fri Nov 15 06:24: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 3B42A120128 for ; Fri, 15 Nov 2019 06:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level: 
X-Spam-Status: No, score=-1.219 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_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 hUhQFPFwxHqk for ; Fri, 15 Nov 2019 06:24:39 -0800 (PST)
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 E7A65120013 for ; Fri, 15 Nov 2019 06:24:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=z6m8NZQyD3zHAp49H03yIvTXQoh5+WumKDDKswvsRSI=; b=ZQBjikuulGXbEUyZAkLc/s4pe 8zG79RJCRHyjHUsCpExO43WVL5Nl+7LhmQFaH/wQfadG3xaAQHMiLMb89phiU55+Lw48u0vPiN2oU pCcRCb1ixbSFskYQ5u0gcObeJwjir/F9eFDwWAwEbLcVfDKY0j7hzWO5qJZVpE1yeGODBl+kMx7W7 NJlK7hiZYlz3u+o59Xnrcl2MTMVo/uTuEqK8itF4/QWYF0nl/yoNRMpj452itUsN/vIZKoOHqhwS/ KFQfhMbz+sVudGVtpNlcMTeGM87/waeQzoFkEa6MXDKorJb2icYgtgotp6DeqSJGyirpF7OV8F4vy HC5R1+Snw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62773 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 1iVcWW-001poe-H6; Fri, 15 Nov 2019 09:24:38 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: 
Date: Fri, 15 Nov 2019 06:24:30 -0800
Cc: Neal Cardwell , Bob Briscoe , "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <25545344-D61C-490A-90D1-945CF1279BA4@strayalpha.com>
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>  
To: "Scheffenegger, Richard" 
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-accurate-ecn-09: AccECN option: why not EE1B first?
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, 15 Nov 2019 14:24:40 -0000

A better explanation would be important. Just not being =E2=80=9Chappy=E2=80=
=9D and wanting =E2=80=9Cnice=E2=80=9D doesn=E2=80=99t cut it.

The only justification for multiple code points for a single option =
would be the need to signals from both ends AT THE SAME TIME (I just =
went through this exercise for UDP options for PMTUD).

Joe

> On Nov 15, 2019, at 4:04 AM, Scheffenegger, Richard  =
wrote:
>=20
> I too like two different option numbers more than initial magic =
numbers
> - we aren't yet that constrained in the tcp options registry to not go
> that route...
>=20
> Richard
>=20
>=20
> Am 14.11.2019 um 19:00 schrieb Neal Cardwell:
>> On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe  =
wrote:
>>> On 14/11/2019 10:06, Scheffenegger, Richard wrote:
>>>> Perhaps placing a different inital value in the first counter would
>>>> implicitly signal this better?
>>> I'll think about this - we can discuss at the hackathon.
>>> Another possibility would be to assign two option kind values for =
two
>>> different option orders - I think I prefer this.
>>>=20
>>>>=20
>>>> The folks from IPPM will not be all too happy with the semantics of
>>>> field values depening on some (possibly missed by passive =
observation)
>>>> initial value though...
>>> Well, true. But I don't think that's a show-stopper. Two option kind
>>> values would address this.
>>=20
>> Two option kind values sounds like a nice solution, IMHO. Clear,
>> simple, and fast.
>>=20
>> best,
>> neal
>>=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Fri Nov 15 08:34:35 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 5735F120929 for ; Fri, 15 Nov 2019 08:34:33 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 YfYw5ZkDX5L3 for ; Fri, 15 Nov 2019 08:34:31 -0800 (PST)
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 12EF212091F for ; Fri, 15 Nov 2019 08:34:31 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id l17so10260058wmh.0 for ; Fri, 15 Nov 2019 08:34:30 -0800 (PST)
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; bh=TsgsHdBnkhraJviOoGBvll+NLM1QLGTtZvgB4k9RcBM=; b=PsWjlWdx2Y1R+6OZinTOp//1vLCExZ5+mJezXYEgxAny/Nj3LYtkFfUsGWsih+QzCV zUsZ14F2IS1jQxwXfCT9deVhiQNucGtdRzh1+2nDYKSzhnaQX2OumcqTqYP2e71TOjw0 7uVsSgubYhiThZV0o/oRRzk5Lo8aE+e1t2KG5w9eyW4ZSi3+DPD/YMwcEWwqE5+eMbNc 9KvgatTLENsWlvFeMwd0JptXH10ToyPh+i9bsMeEi4xue15DDQgJqbHidglreWUcq2Xx hdHCsWPGRKknEx0cswvTVxyGKNDjNJkfFldz4m8ibDraJiFvXObDzks+lvUCyqFXj4be 0KTw==
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; bh=TsgsHdBnkhraJviOoGBvll+NLM1QLGTtZvgB4k9RcBM=; b=QgPVRN+0QVhksyba7tegO4T5sW4PwwWcAzpFKtV3ufv2wN1ZJebXoECGo4d/RnQ2ND uV1i+YKArdt2+Qo0XNgrNaE8Q4EVrMZXvKuPY0/wnQxjxoTHhshYMQH8tAyc/XA6JBsk hWj5GcIeHKnUxOpDjxfmxr2D2iaoAC0zRB94k5L0QTPcTSh0zb0o17wLDhcOYK28PyO/ j920cKbu6a4QmFaAUM7I/88uM58kiccGcCBVkiONp8PjTWwdS7EQjtg3G510twRHkcHf forwQ3V9bqXme0xj5qaj5HfpIbkkHihysxEsXmpJyo4SoFl4F/MaLIqTKMwGLJACcBIm PxOQ==
X-Gm-Message-State: APjAAAV/aSJNHTEmVBUqCEpOwI3jCKu05DxGz33bPcjboUrxzt9OoxFP sboiY83VtL+rr7nSTi0JSLOcd5DwkpldjKPqO8o=
X-Google-Smtp-Source: APXvYqxxTFDcUSrhH++j419iHPv26etxAgCMnoReAzk0s3/phF6JeHQBeUT0aRnwTj/6/alYbHk3bBmFrYVuImWxKnI=
X-Received: by 2002:a05:600c:21d9:: with SMTP id x25mr16734319wmj.50.1573835669565;  Fri, 15 Nov 2019 08:34:29 -0800 (PST)
MIME-Version: 1.0
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>  
In-Reply-To: 
From: Yoshifumi Nishida 
Date: Fri, 15 Nov 2019 08:34:15 -0800
Message-ID: 
To: "Scheffenegger, Richard" 
Cc: Bob Briscoe , Neal Cardwell ,  "tcpm@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000004f9880597652ce0"
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 15 Nov 2019 16:34:33 -0000

--00000000000004f9880597652ce0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If it=E2=80=99s just binary info, can we allocate a bit for it?
-
Yoshi


On Fri, Nov 15, 2019 at 4:05 AM Scheffenegger, Richard 
wrote:

> I too like two different option numbers more than initial magic numbers
> - we aren't yet that constrained in the tcp options registry to not go
> that route...
>
> Richard
>
>
> Am 14.11.2019 um 19:00 schrieb Neal Cardwell:
> > On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe 
> wrote:
> >> On 14/11/2019 10:06, Scheffenegger, Richard wrote:
> >>> Perhaps placing a different inital value in the first counter would
> >>> implicitly signal this better?
> >> I'll think about this - we can discuss at the hackathon.
> >> Another possibility would be to assign two option kind values for two
> >> different option orders - I think I prefer this.
> >>
> >>>
> >>> The folks from IPPM will not be all too happy with the semantics of
> >>> field values depening on some (possibly missed by passive observation=
)
> >>> initial value though...
> >> Well, true. But I don't think that's a show-stopper. Two option kind
> >> values would address this.
> >
> > Two option kind values sounds like a nice solution, IMHO. Clear,
> > simple, and fast.
> >
> > best,
> > neal
> >
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--00000000000004f9880597652ce0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


If it=E2=80=99s just binary info, can we allocate a =
bit for it?
-
Yoshi


On Fri, Nov 15, 2019 at 4:05 AM Scheffenegger=
, Richard <rs.ietf@gmx.at> wrot=
e:
I too like two different option numbers more t=
han initial magic numbers

- we aren't yet that constrained in the tcp options registry to not go<=
br>
that route...



Richard





Am 14.11.2019 um 19:00 schrieb Neal Cardwell:

> On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:

>> On 14/11/2019 10:06, Scheffenegger, Richard wrote:

>>> Perhaps placing a different inital value in the first counter =
would

>>> implicitly signal this better?

>> I'll think about this - we can discuss at the hackathon.

>> Another possibility would be to assign two option kind values for =
two

>> different option orders - I think I prefer this.

>>

>>>

>>> The folks from IPPM will not be all too happy with the semanti=
cs of

>>> field values depening on some (possibly missed by passive obse=
rvation)

>>> initial value though...

>> Well, true. But I don't think that's a show-stopper. Two o=
ption kind

>> values would address this.

>

> Two option kind values sounds like a nice solution, IMHO. Clear,

> simple, and fast.

>

> best,

> neal

>



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm




--00000000000004f9880597652ce0--


From nobody Fri Nov 15 09:59:47 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 908EC120058; Fri, 15 Nov 2019 09:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 4abOprzdERnT; Fri, 15 Nov 2019 09:59:39 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 AE059120013; Fri, 15 Nov 2019 09:59:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=3uJlRegk2pDDBKv+z7JCxnLRmV37CT4mqUGOU0CbQ1M=; b=WZCJrRScSrZup5eyIsqLGn3QF 7Ltwuy5f/kwdMj7aygzNttUIjjkorpz4S2sZP43IHETcSg587iCzTBVcolvk2GRIX7ypVgw7Gqut1 Nb4uMg8kA9U79Cpzx5gya6hcQuKqC5XO2Zyk7C44lYaNd7QmtzfxL82Bqxyr1ebUtd8KnkjOb0/kO FxV+x/6mz4/qtDAGBNgRsFu1+LJMT2ywFyTRCiHrpavxoYr4dHniJGDjWKWEGD0zP8cnb9SHwvLal 9otS+uV8ws7iSWgpm5tMI8E1nryE2/aUc7d78JgWSIDQx2Alj0ZMBo2DiqZOVhPcRkLA9BAIgT5ww 0RqPSqlSQ==;
Received: from [182.55.86.154] (port=38160 helo=[192.168.0.142]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iVfsZ-00030P-G5; Fri, 15 Nov 2019 17:59:32 +0000
To: rgrimes@freebsd.org, tcpm@ietf.org
Cc: tsvwg@ietf.org, draft-grimes-tcpm-tcpsce@ietf.org
References: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net>
From: Bob Briscoe 
Message-ID: <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
Date: Fri, 15 Nov 2019 17:59:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net>
Content-Type: multipart/alternative; boundary="------------6D748A2B4D41319AF2CB5D5E"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.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: Fri, 15 Nov 2019 17:59:45 -0000

This is a multi-part message in MIME format.
--------------6D748A2B4D41319AF2CB5D5E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Rod, Pete,

This is a review of the TCP ECN feedback schemes in 
draft-grimes-tcpm-tcpsce-01, on its own terms - i.e. whether it does 
what it aims to do, rather than whether I agree with what it aims to do.

Please do not feel the need to answer this email quickly. It will take 
some working through, altho I have tried to summarize for the list as well.

===Terminology===
p% The instantaneous SCE marking probability
d% The delayed ACK ratio, e.g. d%=25% means the receiver ACKs at least 1 
in 4 data packets.

===Assumption===
SCE is intended to sometimes or even often cause high levels of SCE 
marking, particularly when using DCTCP congestion control, when runs 
approaching 100% SCE can be common for a round trip or so, and certainly 
 >50%.

===Exec Summary===
Why go through all the years of pain of altering the TCP wire protocol 
for an accurate feedback scheme that isn't accurate?

There are 4 schemes proposed, one of which is NOT RECOMMENDED by the 
authors themselves. Of the other three:

  * 'Simple' multiplies up the Delayed ACK ratio the more the marking
    level is above the delayACK ratio (p>d), which rules it out on
    safety grounds.
  * 'Dithered' doesn't meet its own stated goal (apparently by definition).
  * 'Advanced' increases the ACK ratio in the mid-range of SCE marking
    levels. However, not as badly as 'Simple', and similar to DCTCP or
    AccECN. However, in this range...
  * ...unlike DCTCP and AccECN, 'Advanced' can toggle between long
    periods of 0% and long periods of 100% feedback, when subjected to
    ACK thinning, or segmentation offload.
  * All three schemes suffer from more and more bias in their error as
    the SCE marking level increases. It is important to eliminate bias,
    because it causes a congestion control scheme to aim for the wrong
    rate and therefore either causes excessive queuing delay, or
    excessive underutilization.

To summarize, in all cases:

	Meets SCE goal#1 in clean network? 	Maintains DelACK ratio? 	Unbiased 
result when ACK thinned?
Simple 	Y
	N
	N
Dithered 	N
	Y
	N
Advanced 	N
	N~
	N

Where:
'Y' means OK.
'N' means Not OK.
'N~' means not too bad.

No scheme meets more than one of these three show-stopper requirements.  
It was recognized (see RFC7560) that compromises would probably be 
needed because of the limited header space. But in all three cases, SCE 
makes compromises that are show-stoppers.

===Divergent Goals===
 From the email discussion so far, I am told that the goal given in the 
'Dithered' subsection is the goal for all schemes:

    The goal is to have the same number of bytes marked
    with ESCE as arrived with SCE.

(Ironically, dithered never meets this goal, apparently by design)

I'll call this Goal #1.

Actually, as we shall see, each scheme has a different goal for how much 
marking the receiver feeds into the ESCE ACK stream:

  * 'Simple' meets the above goal,
  * 'Dithered' aims for d% of the above goal.
  * 'Advanced' needs to be decoded, rather than being based on the
    amount of marking.

Different receivers seem to be allowed to use different schemes or the 
same scheme with a different parameter (e.g. different values of d% in 
the Dithered case). Each will give different meanings to an ESCE ACK in 
different flows.

What if the sender decodes an ACK stream believing it to be the 
'Advanced' coding, when it is actually 'Dithered' at d%=20%?


===Scheme-by-scheme review===

==4.2 Simple==

    Upon receipt of a packet with an SCE
    codepoint immediate ACK processing SHOULD be done

'Simple' meets Goal #1, but at the expense of causing an ACK ratio of 
max(d%, p%), which is unsafe IMO. For instance, at 75% SCE marking 
(which is not uncommon with a DCTCP congestion control), 75% of data 
packets trigger an ACK. Such a large change in ACK ratio brings a 
significant risk that congestion from the forward path will propagate to 
the reverse path.

If subjected to ACK thinning, the more SCE marking rises, the more 
'Simple' under-reports. This is because the proportion of ACKs that are 
ESCE marked rises as the marking level rises. So if a proportion of ACKs 
is thinned blindly, proportionately more ESCE ACKs will be thinned.

==4.3 Dithered==
'Dithered' isn't even defined to meet the goal stated in its own 
section. It is defined to factor down the ESCE ACKs to d_r% of the 
proportion of SCE-marked data packets (i.e. d_r% of p%, where 'r' stands 
for receiver).

As introduced earlier, the sender can't even work out the receiver's 
d_r% heuristically. It can see what ratio of ACKs arrive, d_s% (s for 
sender). But the sender cannot know what d_r% was originally, because it 
doesn't know how much d_r% might have been reduced by ACK thinning, 
either by a middlebox or a NIC.

Actually, the way 'Dithered' is described reveals that this section was 
written after some arm-waving but before any thinking. More on 
'Dithered' later.

==4.4 Advanced==
Advanced meets the goal. But only if no ACKs are lost (and they all 
arrive in order). Its accuracy is sensitive to ACK loss (or reordering), 
because it's a stateful algo. Also, I show below that, as the level of 
SCE marking rises, it will quickly become completely broken in the 
presence of simple ACK thinning.

Let's try an example, with d% = 25%, by typing out a finger-random 
sequence of SCE marks.
     01001011000000101000010111001001....
For this sequence, p% = 100*12/32 = 37.5% > d%.

The resulting ESCE ACK stream will be:
     01-010-1---0-0101---010--1-01-0 ....
That's 13 in 32 ~= 41%, compared to 25% for just DelACKs.

This is the same inflation of the ACK rate as (AccECN+TCP Option) or 
(DCTCP-style feedback). The tcpsce draft rather plays down the impact 
though:

    The ACK
    volume is then inflated only slightly compared to an unmarked
    connection


Unlike the SCE schemes, both AccECN and DCTCP can subsequently be 
thinned or coalesced without the error becoming biased. Here's how 
'Advanced' becomes biased.

Let's run the above sequence through a simple algo that thins every 
other ACK:
Before:
     01-010-1---0-0101---010--1-01-0 ....
Forwarded:
     0--0-0-----0--1-1----1---1--1-- ....
Thinned out:
      1--1--1-----0-0----0-0----0--0 ....

Oh dear. You can see what's happening. It thins out all the 1s for a 
while, then switches to thinning out all the zeros. Not only does this 
completely destroy the feedback signal, it does so with a toggling bias 
that will push the congestion control into large swings. This would 
happen for any algo that thins or coalesces an even proportion of ACKs.

So, the original input:
     01001011000000101000010111001001....
decodes as:
     00000000000011111111111111111   ....
I'd say that's pretty broken.


The problem here is that, for higher SCE marking levels, the Advanced 
scheme turns any random sequence into a regular sequence. And some 
thinning/coalescing algos remove information in a regular way.

4.5 ACK Thinning

    Mathematically, the most extreme errors possible in either direction,
    due to ack thinning, are easily corrected during subsequent RTTs.

Starting a sentence with 'mathematically' makes it sound impressive, but 
it's not if you haven't actually done the maths. Even if the error in a 
control signal is unbiased (on average too high as much as too low), 
subsequent RTTs only correct it in cases when the traffic load is in 
steady state. That's hardly ever the case on the Internet, so error will 
not self-correct.

If you are trying to control the /dynamics/ of traffic flows with a 
signal that might sometimes aim too low and sometimes too high, the 
traffic will swing around more wildly, causing more queuing delay and 
less utilization.

Worse, error introduced by thinning any of the SCE-TCP schemes not only 
introduces error, it introduces /biased/ error. As explained in each 
case above. In the case of 'Advanced' the bias toggles at random points. 
Then if it's already aiming towards too much delay (because the error is 
under-reporting), half the time it might swing towards even more delay 
and half the time towards less.

In summary, why go to all the bother of introducing a high-fidelity SCE 
signal, then feeding it back inaccurately, and lop-sidedly?

==Dithered: How to Implement?==

    If some
    of the packets to be ACKed have SCE state set then some proportional
    number of ACK packets SHOULD be sent with the ESCE code point set.

Let's say d=50%. After 2 data packets, let's say one is SCE-marked, so 
we have to send half the next ACK packets with ESCE. But we only have 
one ACK for these two packets...

OK, we send half the next 2 ACK packets with ESCE. But then we've 
accumulated another two 2 data packets, with 0 1 or 2 SCE marks needing 
feed back. We need 2 more ACKs. But then we'll have between 0 and 4 more 
SCE marks to feed back. This will always snowball.

Hmmm. From its description, it looks like 'Dithered' wasn't thought 
through 'much'.

One could set each ESCE probabilistically, based on the fraction of 
marks since the last ACK. That would be noisy feedback, not accurate 
feedback though.

Instead, one could multiply using a repetitive add-subtract algo, to 
multiply the number of packets between SCE marks by d%, in order to 
count ACKs until the next ESCE feedback.

Even though that removes the noise of randomness, it's still a very 
inaccurate way to be accurate. For instance, for d%=25% and p%=1%, every 
100 packets would be SCE marked, so every 25 ACKs would be ESCE marked.

The problem is it's only communicating 1 bit per ACK. If instead it 
exploited n bits per ACK it would be able to maintain precision while 
sending ACKs 2^n times less frequently.

===Bigger Picture===
A new feedback scheme requires a change to the TCP wire protocol, which 
is one of the core Internet protocols. This requires change at both ends 
before it will work. Therefore, ideally, a new feedback protocol needs 
to be more generic than any one feedback scheme that might use aspects 
of the protocol.

That is why a requirements exercise [RFC7560] preceded AccECN, which 
took years in itself. The requirements admit that compromises will be 
needed. So they are more a checklist of things to consider. And you'll 
need a good reason, if you don't think you need to meet them.

There's also probably requirements missing from RFC7560, 'cos it's hard 
to think of requirements in the abstract, particularly subtle ones.

AccECN is close to becoming more frozen, but it's still open to change. 
You might want to think of other ways of repurposing it, while the 
opportunity to make tweaks is still open.


Bob

On 04/11/2019 22:04, Rodney W. Grimes wrote:
> All, Cross posting to tsvwg and tcpm due to overlap in areas covered,
>
> I have just posted an updated version of TCPSCE which hopefully addresses
> most of the feedback provided since the original publication.
>
> The document structure is unchanged, and the history tool works well
> to show what has been changed since the last revision.
>
> Thanks to those who have provided feedback, and assistance in updating
> this draft.
>
> Regards,
> Rod
>
>> A new version of I-D, draft-grimes-tcpm-tcpsce-01.txt
>> has been successfully submitted by Rodney W. Grimes and posted to the
>> IETF repository.
>>
>> Name:		draft-grimes-tcpm-tcpsce
>> Revision:	01
>> Title:		Some Congestion Experienced in TCP
>> Document date:	2019-11-04
>> Group:		Individual Submission
>> Pages:		6
>> URL:            https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/
>> Htmlized:       https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-01
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-grimes-tcpm-tcpsce
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-grimes-tcpm-tcpsce-01
>>
>> Abstract:
>>     This memo classifies a TCP code point ESCE ("Echo Some Congestion
>>     Experienced") for use in feedback of IP code point SCE ("Some
>>     Congestion Experienced").
>>
>>                                                                                    
>>
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------6D748A2B4D41319AF2CB5D5E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Rod, Pete,

    

    This is a review of the TCP ECN feedback schemes in
    draft-grimes-tcpm-tcpsce-01, on its own terms - i.e. whether it does
    what it aims to do, rather than whether I agree with what it aims to
    do.

    

    Please do not feel the need to answer this email quickly. It will
    take some working through, altho I have tried to summarize for the
    list as well.

    

    ===Terminology===

    p% The instantaneous SCE marking probability

    d% The delayed ACK ratio, e.g. d%=25% means the receiver ACKs at
    least 1 in 4 data packets.

    

    ===Assumption===

    SCE is intended to sometimes or even often cause high levels of SCE
    marking, particularly when using DCTCP congestion control, when runs
    approaching 100% SCE can be common for a round trip or so, and
    certainly >50%. 

    

    ===Exec Summary===

    Why go through all the years of pain of altering the TCP wire
    protocol for an accurate feedback scheme that isn't accurate?

    

    There are 4 schemes proposed, one of which is NOT RECOMMENDED by the
    authors themselves. Of the other three:

    
    
      
  • 'Simple' multiplies up the Delayed ACK ratio the more the
        marking level is above the delayACK ratio (p>d), which rules
        it out on safety grounds.
    
      
    • 
      
  • 'Dithered' doesn't meet its own stated goal (apparently by
        definition).
    • 
      
  • 'Advanced' increases the ACK ratio in the mid-range of SCE
        marking levels. However, not as badly as 'Simple', and similar
        to DCTCP or AccECN. However, in this range...
    
      
    • 
      
  • ...unlike DCTCP and AccECN, 'Advanced' can toggle between long
        periods of 0% and long periods of 100% feedback, when subjected
        to ACK thinning, or segmentation offload. 
    
      
    • 
      
  • All three schemes suffer from more and more bias in their
        error as the SCE marking level increases. It is important to
        eliminate bias, because it causes a congestion control scheme to
        aim for the wrong rate and therefore either causes excessive
        queuing delay, or excessive underutilization.
    
      
    • 
    

    To summarize, in all cases:

    

      
        

          

          		
          Meets SCE goal#1 in clean
            network?
          Maintains DelACK ratio?
          Unbiased result when ACK
            thinned?

          		
        

        

          Simple
          Y

          		
          N

          		
          N

          		
        

        

          Dithered
          N

          		
          Y

          		
          N

          		
        

        

          Advanced
          N

          		
          N~

          		
          N

          		
        

      
    

    Where:

    'Y' means OK.

    'N' means Not OK.

    'N~' means not too bad.

    

    No scheme meets more than one of these three show-stopper
    requirements.  It was recognized (see RFC7560) that compromises
    would probably be needed because of the limited header space. But in
    all three cases, SCE makes compromises that are show-stoppers. 

    

    ===Divergent Goals===

    From the email discussion so far, I am told that the goal given in
    the 'Dithered' subsection is the goal for all schemes:

    
   The goal is to have the same number of bytes marked
   with ESCE as arrived with SCE.

    (Ironically, dithered never meets this goal, apparently by design)

    

    I'll call this Goal #1.

    

    Actually, as we shall see, each scheme has a different goal for how
    much marking the receiver feeds into the ESCE ACK stream:

    
    
      
  • 'Simple' meets the above goal,
    • 
      
  • 'Dithered' aims for d% of the above goal.
    • 
      
  • 'Advanced' needs to be decoded, rather than being based on the
        amount of marking.
    • 
    

    Different receivers seem to be allowed to use different schemes or
    the same scheme with a different parameter (e.g. different values of
    d% in the Dithered case). Each will give different meanings to an
    ESCE ACK in different flows. 

    

    What if the sender decodes an ACK stream believing it to be the
    'Advanced' coding, when it is actually 'Dithered' at d%=20%? 

    

    

    ===Scheme-by-scheme review===

    

    ==4.2 Simple==

    
   Upon receipt of a packet with an SCE
   codepoint immediate ACK processing SHOULD be done

    'Simple' meets Goal #1, but at the expense of causing an ACK ratio
    of max(d%, p%), which is unsafe IMO. For instance, at 75% SCE
    marking (which is not uncommon with a DCTCP congestion control), 75%
    of data packets trigger an ACK. Such a large change in ACK ratio
    brings a significant risk that congestion from the forward path will
    propagate to the reverse path.

    

    If subjected to ACK thinning, the more SCE marking rises, the more
    'Simple' under-reports. This is because the proportion of ACKs that
    are ESCE marked rises as the marking level rises. So if a proportion
    of ACKs is thinned blindly, proportionately more ESCE ACKs will be
    thinned.

    

    ==4.3 Dithered==

    'Dithered' isn't even defined to meet the goal stated in its own
    section. It is defined to factor down the ESCE ACKs to d_r% of the
    proportion of SCE-marked data packets (i.e. d_r% of p%, where 'r'
    stands for receiver). 

    

    As introduced earlier, the sender can't even work out the receiver's
    d_r% heuristically. It can see what ratio of ACKs arrive, d_s% (s
    for sender). But the sender cannot know what d_r% was originally,
    because it doesn't know how much d_r% might have been reduced by ACK
    thinning, either by a middlebox or a NIC. 

    

    Actually, the way 'Dithered' is described reveals that this section
    was written after some arm-waving but before any thinking. More on
    'Dithered' later.

    

    ==4.4 Advanced==

    Advanced meets the goal. But only if no ACKs are lost (and they all
    arrive in order). Its accuracy is sensitive to ACK loss (or
    reordering), because it's a stateful algo. Also, I show below that,
    as the level of SCE marking rises, it will quickly become completely
    broken in the presence of simple ACK thinning.

    

    Let's try an example, with d% = 25%, by typing out a finger-random
    sequence of SCE marks.

        01001011000000101000010111001001....

    For this sequence, p% = 100*12/32 = 37.5% > d%.

    

    The resulting ESCE ACK stream will be:

        01-010-1---0-0101---010--1-01-0 ....

    That's 13 in 32 ~= 41%, compared to 25% for just DelACKs.

    

    This is the same inflation of the ACK rate as (AccECN+TCP Option) or
    (DCTCP-style feedback). The tcpsce draft rather plays down the
    impact though:

    
   The ACK
   volume is then inflated only slightly compared to an unmarked
   connection

    

    Unlike the SCE schemes, both AccECN and DCTCP can subsequently be
    thinned or coalesced without the error becoming biased. Here's how
    'Advanced' becomes biased.

    

    Let's run the above sequence through a simple algo that thins every
    other ACK:

    Before:

        01-010-1---0-0101---010--1-01-0 ....

    Forwarded:

        0--0-0-----0--1-1----1---1--1-- ....

    Thinned out:

         1--1--1-----0-0----0-0----0--0 ....

    

    Oh dear. You can see what's happening. It thins out all the 1s for a
    while, then switches to thinning out all the zeros. Not only does
    this completely destroy the feedback signal, it does so with a
    toggling bias that will push the congestion control into large
    swings. This would happen for any algo that thins or coalesces an
    even proportion of ACKs.

    

    So, the original input:

        01001011000000101000010111001001....

    decodes as:

        00000000000011111111111111111   ....

    I'd say that's pretty broken.

    

    

    The problem here is that, for higher SCE marking levels, the
    Advanced scheme turns any random sequence into a regular sequence.
    And some thinning/coalescing algos remove information in a regular
    way. 

    

    4.5 ACK Thinning

    
   Mathematically, the most extreme errors possible in either direction,
   due to ack thinning, are easily corrected during subsequent RTTs.

    Starting a sentence with 'mathematically' makes it sound impressive,
    but it's not if you haven't actually done the maths. Even if the
    error in a control signal is unbiased (on average too high as much
    as too low), subsequent RTTs only correct it in cases when the
    traffic load is in steady state. That's hardly ever the case on the
    Internet, so error will not self-correct. 

    

    If you are trying to control the /dynamics/ of traffic flows with a
    signal that might sometimes aim too low and sometimes too high, the
    traffic will swing around more wildly, causing more queuing delay
    and less utilization. 

    

    Worse, error introduced by thinning any of the SCE-TCP schemes not
    only introduces error, it introduces /biased/ error. As explained in
    each case above. In the case of 'Advanced' the bias toggles at
    random points. Then if it's already aiming towards too much delay
    (because the error is under-reporting), half the time it might swing
    towards even more delay and half the time towards less.

    

    In summary, why go to all the bother of introducing a high-fidelity
    SCE signal, then feeding it back inaccurately, and lop-sidedly?

    

    ==Dithered: How to Implement?==

    
   If some
   of the packets to be ACKed have SCE state set then some proportional
   number of ACK packets SHOULD be sent with the ESCE code point set.

    Let's say d=50%. After 2 data packets, let's say one is SCE-marked,
    so we have to send half the next ACK packets with ESCE. But we only
    have one ACK for these two packets...

    

    OK, we send half the next 2 ACK packets with ESCE. But then we've
    accumulated another two 2 data packets, with 0 1 or 2 SCE marks
    needing feed back. We need 2 more ACKs. But then we'll have between
    0 and 4 more SCE marks to feed back. This will always snowball.

    

    Hmmm. From its description, it looks like 'Dithered' wasn't thought
    through 'much'. 

    

    One could set each ESCE probabilistically, based on the fraction of
    marks since the last ACK. That would be noisy feedback, not accurate
    feedback though.

    

    Instead, one could multiply using a repetitive add-subtract algo, to
    multiply the number of packets between SCE marks by d%, in order to
    count ACKs until the next ESCE feedback.

    

    Even though that removes the noise of randomness, it's still a very
    inaccurate way to be accurate. For instance, for d%=25% and p%=1%,
    every 100 packets would be SCE marked, so every 25 ACKs would be
    ESCE marked. 

    

    The problem is it's only communicating 1 bit per ACK. If instead it
    exploited n bits per ACK it would be able to maintain precision
    while sending ACKs 2^n times less frequently.

    

    ===Bigger Picture===

    A new feedback scheme requires a change to the TCP wire protocol,
    which is one of the core Internet protocols. This requires change at
    both ends before it will work. Therefore, ideally, a new feedback
    protocol needs to be more generic than any one feedback scheme that
    might use aspects of the protocol.

    

    That is why a requirements exercise [RFC7560] preceded AccECN, which
    took years in itself. The requirements admit that compromises will
    be needed. So they are more a checklist of things to consider. And
    you'll need a good reason, if you don't think you need to meet them.

    

    There's also probably requirements missing from RFC7560, 'cos it's
    hard to think of requirements in the abstract, particularly subtle
    ones.

    

    AccECN is close to becoming more frozen, but it's still open to
    change. You might want to think of other ways of repurposing it,
    while the opportunity to make tweaks is still open.

    

    

    Bob

    

    
On 04/11/2019 22:04, Rodney W. Grimes
      wrote:

    

    

      
All, Cross posting to tsvwg and tcpm due to overlap in areas covered,

I have just posted an updated version of TCPSCE which hopefully addresses
most of the feedback provided since the original publication.

The document structure is unchanged, and the history tool works well
to show what has been changed since the last revision.

Thanks to those who have provided feedback, and assistance in updating
this draft.

Regards,
Rod



      

        
A new version of I-D, draft-grimes-tcpm-tcpsce-01.txt
has been successfully submitted by Rodney W. Grimes and posted to the
IETF repository.

Name:		draft-grimes-tcpm-tcpsce
Revision:	01
Title:		Some Congestion Experienced in TCP
Document date:	2019-11-04
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce-01.txt
Status:         https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/
Htmlized:       https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-grimes-tcpm-tcpsce
Diff:           https://www.ietf.org/rfcdiff?url2=draft-grimes-tcpm-tcpsce-01

Abstract:
   This memo classifies a TCP code point ESCE ("Echo Some Congestion
   Experienced") for use in feedback of IP code point SCE ("Some
   Congestion Experienced").

                                                                                  




      

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------6D748A2B4D41319AF2CB5D5E--


From nobody Fri Nov 15 10:34: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 D82FA120902 for ; Fri, 15 Nov 2019 10:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 LfTHWdVEz2IE for ; Fri, 15 Nov 2019 10:34:16 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 067B712022D for ; Fri, 15 Nov 2019 10:34:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=YOuYSMHb+UaOktr+gmisqRVBE2SIMUiPuh1rsLRl6+M=; b=5VI8mKwGRc6tEDp1lDkTCK25v rurQNk1ZLcHpST4m/jyNO6OGmVkucgwnDrKd862lYRzCopx7FTfm4AHWi3PLO/LYeYl0HjBWWRD6m 9yOuldad+3lHs5LD5RKiWWKF9gi6JZaZQhjhg0iVwhX2budb2z/9XHtTlhLErWqa5SqX2kehVW29G e5ak+KG3d4bGBXCtkZqSpMrf7vVUJXKNF+EXaF86WDHhSZmiqMY/oMRkQUmtJbdqenzkqUP7jjitC iqlSjF6s6xxIU6cF/mcbKmj0dRnqeWFb6Ax5kqrJhJGvK7ZFWCotiQnWl7l1j6nEiW+V3GNtXn24v QvD3Mtaxg==;
Received: from [182.55.86.154] (port=38452 helo=[192.168.0.142]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iVgQ9-0007vl-TU; Fri, 15 Nov 2019 18:34:14 +0000
To: Yoshifumi Nishida , "Scheffenegger, Richard" 
Cc: Neal Cardwell , "tcpm@ietf.org" 
References:   <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>  <8470a4fd-2815-0bf9-534a-ef9928f1f43f@bobbriscoe.net>   
From: Bob Briscoe 
X-Remindit: Sat Nov 16 2019 08:00:00 GMT+0800 (+08)
Message-ID: 
Date: Sat, 16 Nov 2019 02:34:11 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C0695CFA6F5AF6E524450970"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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, 15 Nov 2019 18:34:18 -0000

This is a multi-part message in MIME format.
--------------C0695CFA6F5AF6E524450970
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Yoshi,

Unfortunately, we don't have any spare single bits. That's sort-of the 
problem.

If we have to use the initial magic no. approach, I guess checking a 
number is hardly different to toggling a bit.



Bob

On 15/11/2019 16:34, Yoshifumi Nishida wrote:
> If it’s just binary info, can we allocate a bit for it?
> -
> Yoshi
>
>
> On Fri, Nov 15, 2019 at 4:05 AM Scheffenegger, Richard  > wrote:
>
>     I too like two different option numbers more than initial magic
>     numbers
>     - we aren't yet that constrained in the tcp options registry to not go
>     that route...
>
>     Richard
>
>
>     Am 14.11.2019 um 19:00 schrieb Neal Cardwell:
>     > On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe
>     > wrote:
>     >> On 14/11/2019 10:06, Scheffenegger, Richard wrote:
>     >>> Perhaps placing a different inital value in the first counter
>     would
>     >>> implicitly signal this better?
>     >> I'll think about this - we can discuss at the hackathon.
>     >> Another possibility would be to assign two option kind values
>     for two
>     >> different option orders - I think I prefer this.
>     >>
>     >>>
>     >>> The folks from IPPM will not be all too happy with the
>     semantics of
>     >>> field values depening on some (possibly missed by passive
>     observation)
>     >>> initial value though...
>     >> Well, true. But I don't think that's a show-stopper. Two option
>     kind
>     >> values would address this.
>     >
>     > Two option kind values sounds like a nice solution, IMHO. Clear,
>     > simple, and fast.
>     >
>     > best,
>     > neal
>     >
>
>     _______________________________________________
>     tcpm mailing list
>     tcpm@ietf.org 
>     https://www.ietf.org/mailman/listinfo/tcpm
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------C0695CFA6F5AF6E524450970
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Yoshi,

    

    Unfortunately, we don't have any spare single bits. That's sort-of
    the problem.

    

    If we have to use the initial magic no. approach, I guess checking a
    number is hardly different to toggling a bit.

    

    

    

    Bob

    

    
On 15/11/2019 16:34, Yoshifumi Nishida
      wrote:

    

    

      
      

        
If it’s just binary info, can we allocate a bit
          for it?

        
-

        
Yoshi

        


        

      

      


        

          
On Fri, Nov 15, 2019 at 4:05
            AM Scheffenegger, Richard <rs.ietf@gmx.at>
            wrote:

          

          
I
            too like two different option numbers more than initial
            magic numbers

            - we aren't yet that constrained in the tcp options registry
            to not go

            that route...

            

            Richard

            

            

            Am 14.11.2019 um 19:00 schrieb Neal Cardwell:

            > On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:

            >> On 14/11/2019 10:06, Scheffenegger, Richard wrote:

            >>> Perhaps placing a different inital value in the
            first counter would

            >>> implicitly signal this better?

            >> I'll think about this - we can discuss at the
            hackathon.

            >> Another possibility would be to assign two option
            kind values for two

            >> different option orders - I think I prefer this.

            >>

            >>>

            >>> The folks from IPPM will not be all too happy
            with the semantics of

            >>> field values depening on some (possibly missed
            by passive observation)

            >>> initial value though...

            >> Well, true. But I don't think that's a
            show-stopper. Two option kind

            >> values would address this.

            >

            > Two option kind values sounds like a nice solution,
            IMHO. Clear,

            > simple, and fast.

            >

            > best,

            > neal

            >

            

            _______________________________________________

            tcpm mailing list

            tcpm@ietf.org

            https://www.ietf.org/mailman/listinfo/tcpm

          

        

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------C0695CFA6F5AF6E524450970--


From nobody Fri Nov 15 15:28: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 630C8120044; Fri, 15 Nov 2019 15:28:56 -0800 (PST)
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 a0jgmOe-dmWI; Fri, 15 Nov 2019 15:28:55 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D86F2120033; Fri, 15 Nov 2019 15:28:54 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id j12so5699107plt.9; Fri, 15 Nov 2019 15:28:54 -0800 (PST)
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=NLyJC70St3504OD7sWR7b40qV7nIUalmjUSo0XATMBI=; b=qYYDq+vwp5pwqvUp9JWV46pX1/aD8+wdA/G0FE0Xw2hmhNAWE7oL7WjVoI/0uO/bLc haCNy2+CRR1Dcuj+kDvjjss+/OsI//O41Z567xVMkUmsTTBbrdAEkbnt3VrPMxzTJDEo ruEXuAv+4+Teq/MFvF90xcWahTNLneS9O6kpWenf+ZDDM2idibShgMyPyCxgRBB/97PA OELDR1SAjMVFvJZ6tPwu51UJI1U4OIrvAZEWEDnOHFDCcNiDPT5rRWRoSeLbYRjzgu9j J1OBh8lRsLQ/01JKmxmvw/cJcNjlcZfloMMjHyqZY7XtkJcAYfKZ2PeFsgYDrRQecVnw KVGw==
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=NLyJC70St3504OD7sWR7b40qV7nIUalmjUSo0XATMBI=; b=F7byA2irCG84wQTBOD0J/bP0H8jW1pF8OHiaGmVF28h19B8GSv2zbOZOOFOQY6jEXy cEcb4Mg+uAlizQViIbM2DuGM+UXn6wleESNxRUU79j0ICdZmr8RUMJJ2n3iEKu9p5yqz 8PP6HjBKX7rqwvq/mxS1seHdJG3uYU/EjFRGvtyKjDBanp2x/m1gSen1d8EOsPqsiNv8 AvEr7s/ZezYCgduTTQM4G1RMMiLxQvgMrIGs7Z6FWO5i2QqItahWot/wetQv36BW9ueT CVkFxTVS3T1PjR/hNZ3iOTbo/efsH46X8Cqi7ChsBRG6+73KHDbn0LjjL/slT1aWXv8U ksKw==
X-Gm-Message-State: APjAAAXK6F7E7Pe1aroIpk1klim4kCZlN9/Ip8+JmMM8+u32WiQDzzrn YgRHUINatr++coQLCspHRqw=
X-Google-Smtp-Source: APXvYqwjo71dWpUfX+J5Rm8FUpWIvxWJ5agpKcHNlQP3Fkj0+29+032+xQvMvfgrc3WdC7zCVZenpA==
X-Received: by 2002:a17:902:d891:: with SMTP id b17mr17697736plz.308.1573860534215;  Fri, 15 Nov 2019 15:28:54 -0800 (PST)
Received: from jonathartonsmbp.lan ([182.55.197.52]) by smtp.gmail.com with ESMTPSA id s23sm10998817pgh.21.2019.11.15.15.28.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 15:28:53 -0800 (PST)
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: <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
Date: Sat, 16 Nov 2019 07:28:50 +0800
Cc: rgrimes@freebsd.org, tcpm@ietf.org, draft-grimes-tcpm-tcpsce@ietf.org, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FB1D6B3-7995-473B-8055-C222BE19427A@gmail.com>
References: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net> <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.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: Fri, 15 Nov 2019 23:28:57 -0000

> On 16 Nov, 2019, at 1:59 am, Bob Briscoe  wrote:
>=20
> Why go through all the years of pain of altering the TCP wire protocol =
for an accurate feedback scheme that isn't accurate?

Without delving into the rest of the detail right now, I'd like to =
address this point immediately.

Congestion control is, ultimately, a system with a control loop under =
negative feedback.  When designing such a control loop, one is generally =
concerned with whether it has sufficient gain to converge on the =
appropriate setpoint, and is acceptably stable.  The nature of the =
feedback path feeds into that analysis, but as long as the result meets =
acceptability criteria, a simpler control system is often preferable.  =
One fundamental property of a negative-feedback system, though, is that =
the system returns towards the setpoint after a disturbance, even that =
disturbance occurred *in* the feedback path.

Consequently, SCE can tolerate as much as 100% relative error in the SCE =
feedback path.  The case of being 100% low - no ESCE feedback received =
at all - corresponds to falling back to RFC-3168 compliant behaviour, =
ie. the MD response to CE acts as a ceiling on the positive excursion of =
the control output (cwnd).  The case of being 100% high - twice as much =
ESCE feedback received as SCE marks were applied on the forward path - =
will cause a low excursion which will drain the affected queue, after =
which SCE marking will stop, and the system will then recover.

Consequently we made the design decision that *reliable* accurate =
feedback was not necessary, nor was the associated complexity desirable. =
 We also observed that a single additional bit per received segment was =
always adequate to convey *accurate* feedback, and that usually fewer =
bits were needed, which fits well with using one spare bit per Delayed =
ACK packet - which is what we do here.  Several such bits are available =
in the TCP header for such uses, and we decided to recommend the use of =
one which had recently been freed up and whose previous use was closely =
related.

Without yet having examined your other arguments in detail, I suspect =
you are misunderstanding how some of our proposed feedback methods work =
in practice, perhaps stemming from the above fallacy.  Understand that =
we have actually implemented each of these methods in running code, and =
can demonstrate their operation at the Hackathon.

See you there.

 - Jonathan Morton


From nobody Fri Nov 15 17:00: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 3AA5C120052; Fri, 15 Nov 2019 16:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 V-CexVfBuCeQ; Fri, 15 Nov 2019 16:59:56 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 7D7B9120019; Fri, 15 Nov 2019 16:59:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=iy4XyNLpMNCP+W617ACSVNR1o5322p6WhqrBZwrahMI=; b=er/pkhLt4aWK09LETtFfVvF4lq taW1k5C6d9bhKMMK0TRP25FbTYhAqSbkfOeeK//CsIo6b6Z/wH4NC8jyNXghg5+2pBmZmfK4Mgk6I W5tX5Pt+CTuoP2w2W2uMKw79Mn6jgEE0yEWDo2T93E/Dn6D/eN4nS6GEPHRS5GTaZZiAfUPsK0Ctt tmEgcdYjmJN9kly4jdo6sKthgVkfWNK/brZsCUA+B43JDbs3Dg9p0hgRUCGNSLQsmzO76xnwmhtOW kRUmVAi1g4PWtIB0QRVZsscgNlSz7e57gx/uzNT8hwTbkmSSArCVSOcWJ/a6DsqjbZo2hIE7y/6vf O+adHJTQ==;
Received: from [182.55.86.154] (port=39052 helo=[192.168.0.142]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iVmRN-00078U-Fu; Sat, 16 Nov 2019 00:59:54 +0000
To: Jonathan Morton 
Cc: rgrimes@freebsd.org, tcpm@ietf.org, draft-grimes-tcpm-tcpsce@ietf.org, tsvwg@ietf.org
References: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net> <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net> <7FB1D6B3-7995-473B-8055-C222BE19427A@gmail.com>
From: Bob Briscoe 
Message-ID: <4c4bed55-2cb8-c7c2-bab6-9a5dd672a7bf@bobbriscoe.net>
Date: Sat, 16 Nov 2019 08:59:50 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <7FB1D6B3-7995-473B-8055-C222BE19427A@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.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: Sat, 16 Nov 2019 00:59:59 -0000

Jonathan,

I did ask you not to reply until you've read the review. The reasoning 
against what you've said below is in the review.

What you say (which you wouldn't say if you'd read the review) is only 
true for long-term stable traffic. But the Internet is hardly ever like 
that.

We need to see the delay from SCE at higher percentiles, which 
determines whether interactive applications will experience an 
improvement. If you don't make a significant improvement in 
/consistency/ of delay, there's no point burning codepoints. To measure 
that requires hundred's of thousands of data samples. Not just a few 
time series plots and plots of averaged Q delay. We have provided tools 
to extract all this, and we shall be making them easier to use during 
the Hackathon.

Briefly repeating what I've already said (sigh):
To ensure delay is /consistently/ very low under dynamic conditions 
(e.g. for real-time interactive applications), accuracy and timeliness 
in the feedback loop is critical.

With inaccurate feedback the set point that the congestion control is 
aiming for is incorrect, so the rate it aims for is either too high 
(->qdelay) or too low (->under-utilization). Yes, given enough time 
(under stable conditions), as it heads towards the wrong point, 
congestion will rise higher (or fall lower) than the error, and it will 
head closer to the correct point, but still aiming for the wrong target 
(the right target but with the latest feedback errors (+/-) added).

In addition, the review explains why all the schemes in the tcpsce draft 
give an inherently more biased error the higher the level of congestion. 
Biased error is much more problematic.



Bob

PS. Pls do not reply again without having taken the trouble to read what 
I have spent a lot of time explaining.


On 15/11/2019 23:28, Jonathan Morton wrote:
>> On 16 Nov, 2019, at 1:59 am, Bob Briscoe  wrote:
>>
>> Why go through all the years of pain of altering the TCP wire protocol for an accurate feedback scheme that isn't accurate?
> Without delving into the rest of the detail right now, I'd like to address this point immediately.
>
> Congestion control is, ultimately, a system with a control loop under negative feedback.  When designing such a control loop, one is generally concerned with whether it has sufficient gain to converge on the appropriate setpoint, and is acceptably stable.  The nature of the feedback path feeds into that analysis, but as long as the result meets acceptability criteria, a simpler control system is often preferable.  One fundamental property of a negative-feedback system, though, is that the system returns towards the setpoint after a disturbance, even that disturbance occurred *in* the feedback path.
>
> Consequently, SCE can tolerate as much as 100% relative error in the SCE feedback path.  The case of being 100% low - no ESCE feedback received at all - corresponds to falling back to RFC-3168 compliant behaviour, ie. the MD response to CE acts as a ceiling on the positive excursion of the control output (cwnd).  The case of being 100% high - twice as much ESCE feedback received as SCE marks were applied on the forward path - will cause a low excursion which will drain the affected queue, after which SCE marking will stop, and the system will then recover.
>
> Consequently we made the design decision that *reliable* accurate feedback was not necessary, nor was the associated complexity desirable.  We also observed that a single additional bit per received segment was always adequate to convey *accurate* feedback, and that usually fewer bits were needed, which fits well with using one spare bit per Delayed ACK packet - which is what we do here.  Several such bits are available in the TCP header for such uses, and we decided to recommend the use of one which had recently been freed up and whose previous use was closely related.
>
> Without yet having examined your other arguments in detail, I suspect you are misunderstanding how some of our proposed feedback methods work in practice, perhaps stemming from the above fallacy.  Understand that we have actually implemented each of these methods in running code, and can demonstrate their operation at the Hackathon.
>
> See you there.
>
>   - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Fri Nov 15 23:05:18 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 0F1531200E6; Fri, 15 Nov 2019 23:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 8RY3Cys_cOUi; Fri, 15 Nov 2019 23:05:13 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72B11200E5; Fri, 15 Nov 2019 23:05:11 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAG75ATZ056110; Fri, 15 Nov 2019 23:05:10 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAG75A0t056109; Fri, 15 Nov 2019 23:05:10 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911160705.xAG75A0t056109@gndrsh.dnsmgr.net>
To: tcpm@ietf.org
Date: Fri, 15 Nov 2019 23:05:10 -0800 (PST)
CC: tsvwg@ietf.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: [tcpm] Requesting for discussion of draft-grimes-tcpm-tcpsce
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: Sat, 16 Nov 2019 07:05:14 -0000

TCPM Chairs,
        This is a request to have some presentation and discussion of
draft-grimes-tcpm-tcpsce at tcpm without a request that TCPM adopt
at this time.
 
TCPM,
For some context we our asking for adoption by the TSVWG of 
draft-morton-tsvwg-sce (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01)
during the IETF/106 Singapore TSVWG session.  draft-grimes-tcpm-tcpsce is a
tightly associated draft. 

Regards,
-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Sat Nov 16 05:57:51 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 83D6F1200B4 for ; Sat, 16 Nov 2019 05:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] 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 Yj0kYbJ4MSbY for ; Sat, 16 Nov 2019 05:57:45 -0800 (PST)
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 E733612001A for ; Sat, 16 Nov 2019 05:57:44 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A548425A12; Sat, 16 Nov 2019 14:57:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573912662; bh=UMPVLcD0se9qCoQxDqGSt73QaIXnXU7lqK+ZqYsWDdQ=; h=From:To:Subject:Date:References:In-Reply-To:From; b=lURw0dZjKeiiIp1th+qbCD4dTwbhSUXeQUI5TungJVKWGy6v+b3mmRS+rvWkmN0wx fiyaby6RYWF1hImHmUoYJrpSwvEC5E6tAHXDZ7ewGZ1cs4oCc8iBo5yVmwT8HxqTiK 00n6+qhV8xt/g1MNORrn18Gi2pCmewkR5v6cf4Cc=
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 EQsvRd8nzuiP; Sat, 16 Nov 2019 14:57:41 +0100 (CET)
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; Sat, 16 Nov 2019 14:57:41 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Sat, 16 Nov 2019 14:57:41 +0100
From: "Scharf, Michael" 
To: MARCELO GABRIEL BAGNULO BRAUN , tcpm IETF list 
Thread-Topic: [tcpm] Review of draft-ietf-tcpm-generalized-ecn-04
Thread-Index: AdVnHvNUzPQ6SlYtQJy+BLbT1UpXAwr2i1FG///wqgD/7mUiAA==
Date: Sat, 16 Nov 2019 13:57:40 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D511523@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4379D8@rznt8114.rznt.rzdir.fht-esslingen.de>   
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Review of draft-ietf-tcpm-generalized-ecn-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: Sat, 16 Nov 2019 13:57:49 -0000

SGkgTWFyY2VsbywNCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkgYW5kIHNvcnJ5IGZvciB0aGUgZGVs
YXk7IEkgd2FzIG5vdCBpbiBvZmZpY2UuDQoNCkkgYWdyZWUgdGhhdCB0aGUgZG9jdW1lbnQgaGFz
IGltcHJvdmVkIGEgbG90LiBBdCBmaXJzdCBzaWdodCBtb3N0IG9mIG15IGNvbmNlcm5zIGFyZSBh
ZGRyZXNzZWQsIGFsYmVpdCBJIHN1Z2dlc3QgdGhhdCBvdGhlcnMgaW4gdGhlIHdvcmtpbmcgZ3Jv
dXAgc2hvdWxkIGNhcmVmdWxseSByZXZpZXcgdGhlIGxhdGVzdCBjaGFuZ2VzLiBNb3JlIGlubGlu
ZS4uLg0KDQpbLi4uXQ0KDQo+ID4gKiBTZWN0aW9uIDMuMg0KPiA+DQo+ID4gICAgIkl0IGNhbiBi
ZSBzZWVuIHRoYXQgdGhlIHNlbmRlciBjYW5ub3Qgc2V0IEVDVCBvbiB0aGUgU1lOIGlmIGl0IGlz
IG5vdA0KPiA+ICAgIHJlcXVlc3RpbmcgQWNjRUNOIGZlZWRiYWNrLiINCj4gPg0KPiA+ICAgQXMg
bWVudGlvbmVkIGJlZm9yZSwgSSB0aGluayB0aGlzIGlzIG9uZSBvZiB0aGUgY2FzZXMgaW4gd2hp
Y2ggcmVhc29uaW5nIGlzDQo+IG5lZWRlZCBhcyBpdCBpcyBub3QgdHJpdmlhbCB0byB1bmRlcnN0
YW5kIHRoZSByb290IGNhdXNlLiBBIHJlZmVyZW5jZSB0byBhIGxhdGVyDQo+IHNlY3Rpb24gY291
bGQgd29yay4NCj4gDQo+IA0KPiBTbywgdGhlIHJlYXNvbiB3aHkgd2UgKGFzIFdHKSBkZWNpZGVk
IGFnYWluc3Qgc3VwcG9ydGluZyBFQ04gbWFya2luZw0KPiBvZiB0aGUgU1lOIHBhY2tldHMgd2hl
biBBY2NFQ04gaXMgbm90IHN1cHBvcnRlZCBpcyB0byBwcmV2ZW50IHRoZQ0KPiBjb25zdW1wdGlv
biBvZiByZXNlcnZlZCBiaXRzIGluIHRoZSBUQ1AgaGVhZGVyIGZvciAgdGhpcyBwdXJwb3NlLg0K
PiANCj4gSSBtZWFuLCBhcyBjdXJyZW50bHkgZGVmaW5lZCwgd2UgbmVlZCB0byBiZSBhYmxlIHRv
IGlkZW50aWZ5IDMgdHlwZXMNCj4gb2Ygc2VydmVycywgbmFtZWx5LCBub24tRUNOIHNlcnZlcnMs
IGNsYXNzaWMgRUNOIHNlcnZlcnMgYW5kIEFjY0VDTg0KPiBzZXJ2ZXJzICh3aGljaCBhbHJlYWR5
IGRlZmluZWQgdGhlIGVuY29kaW5nIG9mIHRoZSBDRSBtYXJrIGluIHRoZSBTWU4NCj4gcGFja2V0
KS4NCg0KSSBjb3VsZCB0aGluayBvZiBhIGZvcnRoIHR5cGUgb2Ygc2VydmVyLCBidXQgSSBndWVz
cyB0aGF0IHF1ZXN0aW9uIGRlcGVuZHMgb24gdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbnMgaW4gVFNW
V0cuIFNvIG1heWJlIEknbGwganVzdCBhd2FpdCB0aGUgb3V0Y29tZS4NCg0KPiBJZiB3ZSB3ZXJl
IHRvIGFsc28gc3VwcG9ydCBjbGFzc2ljIEVDTiBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCBFQ04rKywN
Cj4gdGhpcyB3b3VsZCBiZSBhIG5ldyB0eXBlIG9mIHNlcnZlciB0aGF0IHdvdWxkIHRoZW4gcmVx
dWlyZSBhbg0KPiBhZGRpdGlvbmFsIGNvZGVwb2ludCBpbiB0aGUgVENQIGhlYWRlci4gV2UgZGVl
bWVkIHRoaXMgd2FzIHdhc3RlZnVsDQo+IChjb25zaWRlcmluZyB0aGF0IHRoZXJlIGFyZSB2ZXJ5
IGZldyBiaXRzIHJlc2VydmVkIGF2YWlsYWJsZSkgYW5kDQo+IGVzcGVjaWFsbHkgY29uc2lkZXJp
bmcgdGhhdCB3aGVuIHdlIGFza2VkIHRoZSBXRyAoaW4gc2V2ZXJhbA0KPiBvY2Nhc2lvbnMpIG5v
LW9uZSBleHByZXNzZWQgYW55IGludGVyZXN0IGluIHRoZSBzdXBwb3J0IG9mIGEgY2xhc3NpYw0K
PiBFQ04gc2VydmVyIHRoYXQgc3VwcG9ydGVkIEVDTisrLg0KDQpJIGFncmVlIHRoYXQgdGhlcmUg
aGFzIG5vdCBiZWVuIG11Y2ggaW1wbGVtZW50ZXIgaW50ZXJlc3QgaW4gRUNUIGluIFNZTnMgZm9y
IFJGQzMxNjggRUNOIHNlcnZlcnMsIGFuZCBzbyBJJ2xsIG5vdCBmdXJ0aGVyIGluc2lzdCBpbiBz
dWNoIGEgdXNlIGNhc2UuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgRUNUIGluIFNZTnMgd291
bGQgd29yayBpZiBkaWZmZXJlbnQgRUNOIGZlZWRiYWNrIG1lY2hhbmlzbXMgYWxzbyBleGlzdGVk
LCBidXQgbWF5YmUgaXQgaXMgdG9vIGVhcmx5IHRvIGFzayB0aGF0IHF1ZXN0aW9uLCBhcyBpdCBk
ZXBlbmRzIG9uIFRTVldHLg0KDQo+IEluIGFueSBjYXNlLCB3ZSBjaGFuZ2VkIHRoZSB0ZXh0IGFz
IGZvbGxvd3M6DQo+IA0KPiBzLyAgIEl0IGNhbiBiZSBzZWVuIHRoYXQgdGhlIHNlbmRlciBjYW5u
b3Qgc2V0IEVDVCBvbiB0aGUgU1lOIGlmIGl0IGlzIG5vdA0KPiAgICByZXF1ZXN0aW5nIEFjY0VD
TiBmZWVkYmFjay4NCj4gIC8gIHQgY2FuIGJlIHNlZW4gdGhhdCB3ZSByZWNvbW1lbmQgYWdhaW5z
dCB0aGUgc2VuZGVyIHNldHRpbmcgRUNUIG9uDQo+ICAgICAgICAgdGhlIFNZTiBpZiBpdCBpcyBu
b3QgcmVxdWVzdGluZyBBY2NFQ04gZmVlZGJhY2suDQo+ICAvDQoNClRoYW5rcyBmb3IgdGhlIG1v
cmUgY2FyZWZ1bCB3b3JkaW5nLiBJIHRoaW5rIGl0IGlzIHVwIHRvIHRoZSByZXN0IG9mIHRoZSB3
b3JraW5nIGdyb3VwIHRvIGNhcmVmdWxseSBjaGVjayB3aGV0aGVyIHRoaXMgd29ya3MgZm9yIGFs
bCB1c2UgY2FzZXMuDQoNClsuLi5dDQoNCj4gPiAqIFNlY3Rpb24gMy4yDQo+ID4NCj4gPiAgICJU
aGVyZWZvcmUgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUNCj4gPiAgICBleHBlcmltZW50YWwg
QWNjRUNOIHNwZWNpZmljYXRpb24gW0ktRC5pZXRmLXRjcG0tYWNjdXJhdGUtZWNuXSBpcw0KPiA+
ICAgIGltcGxlbWVudGVkIChhcyB3ZWxsIGFzIHRoZSBwcmVzZW50IHNwZWNpZmljYXRpb24pIg0K
PiA+DQo+ID4gICBJIGhhdmUgcmVwZWF0ZWRseSBtZW50aW9uZWQgdGhlIGRvd25zaWRlcyBvZiBj
cmVhdGluZyBkZXBlbmRlbmNpZXMNCj4gYmV0d2VlbiBkb2N1bWVudHMuIEluIHRoaXMgY2FzZSwg
dGhlIHJpc2sgaXMgdGhhdCB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgZmFpbHMNCj4gKGUuZy4sIHRo
ZSBJRVRGIGhhcyB0byBvYnNvbGV0ZSBpdCBpbiBzb21lIHllYXJzIGJlY2F1c2UgYW5vdGhlciBh
bHRlcm5hdGl2ZSBoYXMNCj4gYmVlbiBmb3VuZCkuIFRoZSBzYW1lIGFwcGxpZXMgaWYgYSBzdGFu
ZGFyZHMtdHJhY2sgUkZDIG9mIEFjY0VDTiB3b3VsZCBub3QgYmUNCj4gYmFja3dhcmQtY29tcGF0
aWJsZSBmb3Igd2hhdGV2ZXIgcmVhc29uLiBIaXMgd291bGQgYmUgYSBwaXR5IHNpbmNlIHNpZ25p
ZmljYW50DQo+IHBhcnRzIG9mIHRoZSBkb2N1bWVudCBhcmUgZW50aXJlbHkgaW5kZXBlbmRlbnQg
b2YgQWNjRUNOLiBUaGlzIHJpc2sgY291bGQgYmUNCj4gcmVkdWNlZCBieSBub3QgbWFuZGF0aW5n
IGEgcGFydGljdWxhciBzcGVjaWZpY2F0aW9uLCBidXQgbWFuZGF0aW5nIGZ1bmN0aW9uYWwNCj4g
cmVxdWlyZW1lbnRzLg0KPiA+DQo+ID4gICBGb3IgaW5zdGFuY2UsIEkgYmVsaWV2ZSB0aGF0IEVD
VCBvbiBTWU5zIGNhbiBhbHdheXMgYmUgc2V0IGlmIHRoZXJlIGlzIGENCj4gbWVjaGFuaXNtIHRo
YXQgcmVsaWFibHkgZWNob3MgQ0UgbWFya3Mgb24gU1lOcyBiYWNrIHRvIHRoZSBzZW5kZXIuIEFj
Y0VDTiBpcw0KPiBhIHNvbHV0aW9uIHRvIHRoaXMsIGFuZCB0aGUgb25seSBzb2x1dGlvbiB3ZSBj
dXJyZW50bHkgaGF2ZSwgYnV0IHdlIGFyZSBkZWFsaW5nDQo+IHdpdGggZXhwZXJpbWVudHMsIG5v
dCBzdGFuZGFyZHMsIHNvIHdobyBrbm93cyB3aGF0IHdpbGwgaGFwcGVuIGluIHNvbWUgeWVhcnMN
Cj4gZnJvbSBub3c/IFRvIG1lLCBhIGJldHRlciB3b3JkaW5nIHdvdWxkIGJlIGFsb25nIHRoZSBs
aW5lcyBvZiAobmVnbGVjdGluZyB0aGUNCj4gcHJldmlvdXNseSBtZW50aW9uZWQgZXhjZXB0aW9u
KTogIkVDVCBvbiBTWU5zIGNhbiBvbmx5IGJlIHNldCBpZiB0aGVyZSBpcyBhDQo+IGNvcnJlc3Bv
bmRpbmcgZmVlZGJhY2sgc2NoZW1lLiBUaGUgZXhwZXJpbWVudGFsIEFjY0VDTiBzcGVjaWZpY2F0
aW9uIFtJLQ0KPiBELmlldGYtdGNwbS1hY2N1cmF0ZS1lY25dIHByb3ZpZGVzIHRoaXMgZmVlZGJh
Y2suIEl0IGlzIFJFQ09NTUVOREVEIHRvDQo+IGltcGxlbWVudCBhbiBhY2N1cmF0ZSBmZWVkYmFj
ayBzY2hlbWUgYXMgd2VsbCBhcyB0aGUgcHJlc2VudCBzcGVjaWZpY2F0aW9uLiIgSQ0KPiBtZXJl
bHkgc2hvdyB0aGlzIGFzIGFuIGV4YW1wbGUgdGhhdCB3b3VsZCBub3QgYmUgaW1wb3NzaWJsZSB0
byBiZXR0ZXINCj4gZGVjb3VwbGUgZG9jdW1lbnRzLiBBcyBsb25nIGFzIEkgYW0gdGhlIG9ubHkg
cGVyc29uIHdobyBicmluZ3MgdXAgdGhpcyBwb2ludCwgSQ0KPiBkb24ndCBhc2sgZm9yIHRoaXMg
c3BlY2lmaWMgY2hhbmdlIHRvIGJlIGltcGxlbWVudGVkLiBJIGp1c3QgbGlrZSB0byByZWNvcmQg
bXkNCj4gY29uY2VybiBpbmNsdWRpbmcgcG90ZW50aWFsIHNvbHV0aW9ucyAoZS5nLiwgZm9yIGEg
ZG9jdW1lbnQgc2hlcGhlcmQpLg0KPiA+DQo+IA0KPiBJIGFncmVlIHdpdGggdGhpcyBhcHByb2Fj
aC4NCj4gDQo+IEkgaGF2ZSBtb2RpZmllZCB0aGUgZG9jdW1lbnQgaW4gc2V2ZXJhbCBwYXJ0cyB0
byBwcm92aWRlIGd1aWRhbmNlDQo+IGFib3V0IGhvdyB0byBlbmFibGUgRUNOKysgaW4gZnV0dXJl
IEVDTiBmZWVkYmFjayBtZWNoYW5pc21zIHRvIGJlDQo+IGRlZmluZWQuIEhvd2V2ZXIsIGFzIG9m
IHRvZGF5LCB0aGVyZSBhcmUgb25seSB0d28gRUNOIGZlZWRiYWNrDQo+IG1lY2hhbmlzbXMgZm9y
IFRDUCBkZWZpbmVkLCBzdGFuZGFyZCBFQ04gYW5kIEFjY0VDTi4gV2UgaGF2ZSBhbHNvIGJlZW4N
Cj4gYXNrZWQgdG8gZW5zdXJlIHRoaXMgZHJhZnQgaXMgY29uY3JldGUgYW5kIGNsZWFyLCBzbyB3
ZSB3YW50IHRvDQo+IGRlc2NyaWJlIGluIGRldGFpbCB3aGF0IEVDTisrIHNob3VsZCBkbyBpbiBi
b3RoIGNhc2VzIGFzIHRoZSBkb2N1bWVudA0KPiBkb2VzLiBTbywgbXkgcHJvcG9zYWwgaXMgdG8g
MSkga2VlcCBhbGwgdGhlIGd1aWRhbmNlIGFuZA0KPiByZWNjb21lbmRhdGlvbnMgcmVnYXJkaW5n
IGxlZ2FjeSBFQ04gYW5kIEFjY0VDTiBmZWVkYmFjayBhbmQgMikNCj4gcHJvdmlkZSBndWlkYW5j
ZSBvbiB0aGUgRUNOKysgc3VwcG9ydCBmb3IgZnV0dXJlIEVDTiBmZWVkYmFjaw0KPiBtZWNoYW5p
c21zLCBiYXNlZCBvbiB0aGUgZnVuY2l0b25hbGl0eSByZXF1aXJlZCwgYXMgeW91IHN1Z2dlc3Qu
DQo+IA0KPiBUbyBhY2hpZXZlIHRoYXQgSSBoYXZlIG1vZGlmaWVkIHRoZSBmb2xsb3dpbmcgc3Vi
c2VjdGlvbnM6DQo+IA0KPiBJbiB0aGUgSW50cm9kdWN0aW9uLCBJIGhhdmUgaW5jbHVkZWQ6DQo+
IA0KPiAgICAgICA8dD5FQ04rKyB1c2VzIGEgc2VuZGVyLW9ubHkgZGVwbG95bWVudCBtb2RlbC4g
SXQgd29ya3Mgd2hldGhlciB0aGUgdHdvDQo+ICAgICAgIGVuZHMgb2YgdGhlIFRDUCBjb25uZWN0
aW9uIHVzZSBjbGFzc2ljIEVDTiBmZWVkYmFjayA8eHJlZg0KPiAgICAgICB0YXJnZXQ9IlJGQzMx
NjgiLz4gb3IgZXhwZXJpbWVudGFsIEFjY3VyYXRlIEVDTiBmZWVkYmFjayAoQWNjRUNOIDx4cmVm
DQo+ICAgICAgIHRhcmdldD0iSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY24iLz4pLCB0aGUgb25s
eSB0d28gRUNOIGZlZWRiYWNrDQo+ICAgICAgIG1lY2hhbmlzbXMgZm9yIFRDUCBzdGFuZGFyZGlz
ZWQgYXQgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLg0KDQpUaGUgY29ycmVjdCB0ZXJtIGZvciBh
biBleHBlcmltZW50YWwgcHJvdG9jb2wgd291bGQgYmUgInNwZWNpZmllZCIgaW5zdGVhZCBvZiAi
c3RhbmRhcmRpc2VkIi4gU28sIGF0IG1pbmltdW0sIGl0IG11c3QgYmUgY2hhbmdlZCBpZiB0aGUg
cHJvdG9jb2wgc2hhbGwgYmUgZXhwZXJpbWVudGFsLg0KDQpJIHdvdWxkIHBlcnNvbmFsbHkgcmVj
b21tZW5kIHRvIHJlbW92ZSB0aGUgcGFydCBhZnRlciB0aGUgY29tbWEgYXMgdGhpcyBjcmVhdGVz
IHlldCBhbm90aGVyIGRlcGVuZGVuY3kgb24gdGhlIG91dGNvbWUgb2YgSUVURiBkaXNjdXNzaW9u
cy4gSWYgdGhlIHNlbnRlbmNlIHN0YXlzLCBpdCB3aWxsIG5lZWQgdG8gYmUgdmVyaWZpZWQgbGF0
ZXIuIA0KIA0KPiAgICAgICBOb25ldGhlbGVzcywgaWYgdGhlIGNsaWVudCBkb2VzDQo+ICAgICAg
IG5vdCBpbXBsZW1lbnQgQWNjRUNOLCBpdCBjYW5ub3QgdXNlIEVDTisrIHRoZSBpbml0aWFsIFNZ
TiBwYWNrZXQuDQo+ICAgICAgIFVzaW5nIEVDTiBpbiB0aGUgU1lOIHBhY2tldHMgcHJvdmlkZXMg
c2lnbmlmaWNhbnQgYmVuZWZpdHMsIGFzIHdlIGRlc2NyaWJlDQo+ICAgICAgIGluIHRoZSBuZXh0
IHN1YnNlY3Rpb24uIEhvd2V2ZXIsIHVubGlrZSBSRkMgMzE2OCBmZWVkYmFjaywgQWNjRUNODQo+
IHByb3ZpZGVzDQo+ICAgICAgIGEgd2F5IGZvciBhIFRDUCBzZXJ2ZXIgdG8gZmVlZCBiYWNrIHdo
ZXRoZXIgYSBTWU4gYXJyaXZlZCBtYXJrZWQgQ0UuIFNvLA0KPiAgICAgICBpZiB0aGUgY2xpZW50
IGRvZXMgbm90IGltcGxlbWVudCBBY2NFQ04sIGl0IGNvdWxkIGJlIHVuc2FmZSB0byB1c2UgRUNO
KysNCj4gICAgICAgb24gdGhlIGluaXRpYWwgU1lOIHBhY2tldC4gVGhlcmVmb3JlLCBpbXBsZW1l
bnRlcnMgb2YgRUNOKysNCj4gICAgICAgYXJlIFJFQ09NTUVOREVEIHRvIGFsc28gaW1wbGVtZW50
IEFjY0VDTi4gSW4gdGhpcyBkb2N1bWVudCwgd2UgYWxzbw0KPiAgICAgICBwcm92aWRlIGd1aWRh
bmNlIHJlZ2FyZGluZyB0aGUgRUNOKysgc3VwcG9ydCBmb3IgZnV0dXJlDQo+ICAgICAgIEVDTiBm
ZWVkYmFjayBtZWNoYW5pc21zIGZvciBUQ1AgYmFzZWQgb24gdGhlIHRoZSBmdW5jdGlvbmFsaXR5
IHJlcXVpcmVkDQo+ICAgICAgIHRvIGVuYWJsZSBFQ04gbWFya2luZyBvZiB0aGUgZGlmZmVyZW50
IHBhY2tldHMuPC90Pg0KPiANCj4gVGhlbiBpbiBzZWN0aW9uIDMuMiBJIG1vZGlmaWVkIHRoZSBm
b2xsb3dpbmcgcGFyYWdyYXBoIGFzIGZvbGxvd3M6DQo+IA0KPiAgICAgICAgIDx0Pk5vbmV0aGVs
ZXNzLCB0aGlzIHNwZWNpZmljYXRpb24gYWxzbyBjYXRlcnMgZm9yIHRoZSBjYXNlIHdoZXJlIGFu
DQo+ICAgICAgICAgRUNOKysgVENQIHNlbmRlciBpcyBub3QgdXNpbmcgQWNjRUNOLiBUaGlzIGNv
dWxkIGJlIGJlY2F1c2UgaXQgZG9lcw0KPiAgICAgICAgIG5vdCBzdXBwb3J0IEFjY0VDTiBvciBi
ZWNhdXNlIHRoZSBvdGhlciBlbmQgb2YgdGhlIFRDUCBjb25uZWN0aW9uIGRvZXMNCj4gICAgICAg
ICBub3QgKEFjY0VDTiBjYW4gb25seSBiZSB1c2VkIGZvciBhIGNvbm5lY3Rpb24gaWYgYm90aCBl
bmRzIHN1cHBvcnQNCj4gICAgICAgICBpdCkuIDwvdD4NCj4gQWxzbywgc2VjdGlvbiAzLjIuMS4x
LiB3YXMgbW9kaWZpZWQgYXMgZm9sbG93czoNCj4gDQo+ICAgICAgICAgICAgIDx0PldpdGggY2xh
c3NpYyA8eHJlZiB0YXJnZXQ9IlJGQzMxNjgiLz4gRUNOIGZlZWRiYWNrLCB0aGUgU1lOIHdhcw0K
PiAgICAgICAgICAgICBub3QgZXhwZWN0ZWQgdG8gYmUgRUNOLWNhcGFibGUsIHNvIHRoZSBmbGFn
IHByb3ZpZGVkIHRvIGZlZWQgYmFjaw0KPiAgICAgICAgICAgICBjb25nZXN0aW9uIHdhcyBwdXQg
dG8gYW5vdGhlciB1c2UgKGl0IGlzIHVzZWQgaW4gY29tYmluYXRpb24gd2l0aA0KPiAgICAgICAg
ICAgICBvdGhlciBmbGFncyB0byBpbmRpY2F0ZSB0aGF0IHRoZSByZXNwb25kZXIgc3VwcG9ydHMg
RUNOKS4gSW4NCj4gICAgICAgICAgICAgY29udHJhc3QsIEFjY3VyYXRlIEVDTiAoQWNjRUNOKSBm
ZWVkYmFjayA8eHJlZg0KPiAgICAgICAgICAgICB0YXJnZXQ9IkktRC5pZXRmLXRjcG0tYWNjdXJh
dGUtZWNuIi8+IHByb3ZpZGVzIGEgY29kZXBvaW50IGluIHRoZQ0KPiAgICAgICAgICAgICBTWU4t
QUNLIGZvciB0aGUgcmVzcG9uZGVyIHRvIGZlZWQgYmFjayB3aGV0aGVyIHRoZSBTWU4gYXJyaXZl
ZA0KPiAgICAgICAgICAgICBtYXJrZWQgQ0UuIFRoZXJlZm9yZSB0aGUgc2V0dGluZyBvZiB0aGUg
SVAvRUNOIGZpZWxkIG9uIHRoZSBTWU4gaXMNCj4gICAgICAgICAgICAgc3BlY2lmaWVkIHNlcGFy
YXRlbHkgZm9yIGVhY2ggY2FzZSBpbiB0aGUgZm9sbG93aW5nIHR3bw0KPiAgICAgICAgICAgICBz
dWJzZWN0aW9ucy4gSWYgaW4gdGhlIGZ1dHVyZSwgYWRkaXRpb25hbCBFQ04gZmVlZGJhY2sNCj4g
bWVjaGFuaXNtcyBhcmUNCj4gICAgICAgICAgICAgZGVmaW5lZCBmb3IgVENQLCBpdCB3b3VsZCBv
bmx5IGJlIHBvc3NpYmxlIHRvIGVuYWJsZSB0aGUgRUNUIG1hcmtpbmcNCj4gICAgICAgICAgICAg
b2YgdGhlIFNZTiBwYWNrZXRzIGFzIGxvbmcgYXMgdGhlIG5ldyBFQ04gZmVlZGJhY2sNCj4gbWVj
aGFuaXNtIHByb3ZpZGVzDQo+ICAgICAgICAgICAgIHRoZSBtZWFucyB0byBmZWVkIGJhY2sgdGhl
IENFIG1hcmtpbmcgb2YgdGhlIFNZTiBiYWNrIHRvIHRoZSBUQ1ANCj4gICAgICAgICAgICAgaW5p
dGlhdG9yLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGUgbmV3IEVDTiBmZWVkYmFjaw0KPiBtZWNo
YW5pc20gc2hvdWxkDQo+ICAgICAgICAgICAgIGZvbGxvdyB0aGUgc2FtZSByZWNvbW1lbmRhdGlv
biBkZXNjcmliZWQgYmVsb3cgZm9yIEFjY0VDTg0KPiByZWdhcmRpbmcNCj4gICAgICAgICAgICAg
dGhlIHByb2Nlc3Npbmcgb2YgdGhlIFNZTiBwYWNrZXRzLjwvdD4NCg0KQ3VycmVudGx5IEkgZG9u
J3Qga25vdyBpZiBzdWNoIG5ldyBFQ04gZmVlZGJhY2sgbWVjaGFuaXNtcyB3aWxsIGV4aXN0IHNv
b24taXNoIGluIHRoZSBJRVRGLiBJZiBub3QsIHRoZSB3b3JkaW5nIHdvdWxkIHByb2JhYmx5IHdv
cmsgZm9yIG1lLg0KDQpbLi4uXQ0KDQo+ID4gKiBTZWN0aW9uIDUuMS4gIElXMTANCj4gPg0KPiA+
ICAgIkFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDMuMi4xLjEsIGEgVENQIGluaXRpYXRvciBjYW4g
b25seSBzZXQgRUNUIG9uDQo+ID4gICAgdGhlIFNZTiBpZiBpdCByZXF1ZXN0cyBBY2NFQ04gc3Vw
cG9ydC4gIElmLCBob3dldmVyLCB0aGUgU1lOLUFDSw0KPiA+ICAgIHRlbGxzIHRoZSBpbml0aWF0
b3IgdGhhdCB0aGUgcmVzcG9uZGVyIGRvZXMgbm90IHN1cHBvcnQgQWNjRUNOLA0KPiA+ICAgIFNl
Y3Rpb24gMy4yLjEuMSBhZHZpc2VzIHRoZSBpbml0aWF0b3IgdG8gY29uc2VydmF0aXZlbHkgcmVk
dWNlIGl0cw0KPiA+ICAgIGluaXRpYWwgd2luZG93IHRvIDEgU01TUyBiZWNhdXNlLCBpZiB0aGUg
U1lOIHdhcyBDRS1tYXJrZWQsIHRoZSBTWU4tDQo+ID4gICAgQUNLIGhhcyBubyB3YXkgdG8gZmVl
ZCB0aGF0IGJhY2suDQo+ID4NCj4gPiAgICBJZiB0aGUgaW5pdGlhdG9yIGltcGxlbWVudHMgSVcx
MCwgaXQgc2VlbXMgcmF0aGVyIG92ZXItY29uc2VydmF0aXZlDQo+ID4gICAgdG8gcmVkdWNlIElX
IGZyb20gMTAgdG8gMSBqdXN0IGluIGNhc2UgYSBjb25nZXN0aW9uIG1hcmtpbmcgd2FzDQo+ID4g
ICAgbWlzc2VkLiAgTm9uZXRoZWxlc3MsIHRoZSByZWR1Y3Rpb24gdG8gMSBTTVNTIHdpbGwgcmFy
ZWx5IGhhcm0NCj4gPiAgICBwZXJmb3JtYW5jZSwgYmVjYXVzZToNCj4gPg0KPiA+ICAgIG8gIGFz
IGxvbmcgYXMgdGhlIGluaXRpYXRvciBpcyBjYWNoaW5nIGZhaWx1cmVzIHRvIG5lZ290aWF0ZSBB
Y2NFQ04sDQo+ID4gICAgICAgc3Vic2VxdWVudCBhdHRlbXB0cyB0byBhY2Nlc3MgdGhlIHNhbWUg
c2VydmVyIHdpbGwgbm90IHVzZSBFQ1Qgb24NCj4gPiAgICAgICB0aGUgU1lOIGFueXdheSwgc28g
dGhlcmUgd2lsbCBubyBsb25nZXIgYmUgYW55IG5lZWQgdG8NCj4gPiAgICAgICBjb25zZXJ2YXRp
dmVseSByZWR1Y2UgSVc7DQo+ID4NCj4gPiAgICBvICBjdXJyZW50bHksIGF0IGxlYXN0IGZvciB3
ZWIgc2Vzc2lvbnMsIGl0IGlzIGV4dHJlbWVseSByYXJlIGZvciBhDQo+ID4gICAgICAgVENQIGlu
aXRpYXRvciAoY2xpZW50KSB0byBoYXZlIG1vcmUgdGhhbiBvbmUgZGF0YSBzZWdtZW50IHRvIHNl
bmQNCj4gPiAgICAgICBhdCB0aGUgc3RhcnQgb2YgYSBUQ1AgY29ubmVjdGlvbiBbMjg7IEZpZyAz
XSAtIElXMTAgaXMgcHJpbWFyaWx5DQo+ID4gICAgICAgZXhwbG9pdGVkIGJ5IFRDUCBzZXJ2ZXJz
LiINCj4gPg0KPiA+ICAgU2VlIG15IHByZXZpb3VzIHF1ZXN0aW9ucy4gSSBkbyBub3QgdW5kZXJz
dGFuZCB3aHkgdGhlcmUgaXMgbm8gZGVwbG95ZWQNCj4gVENQLWJhc2VkIGFwcGxpY2F0aW9uIHdp
dGggc29tZSByZWFzb25hYmxlIHNoYXJlIG9mIHRyYWZmaWMgdGhhdCBzZW5kcyBtb3JlDQo+IHRo
YW4gb25lIHNlZ21lbnQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgVENQIGNvbm5lY3Rpb24uIFRo
aXMgZG9jdW1lbnQgZGVhbHMNCj4gd2l0aCBhbGwgVENQIHVzYWdlOyBpdCBpcyBub3Qgd3JpdHRl
biBvbmx5IGZvciB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFdlYg0KPiBicm93c2VycyBhbmQg
V2ViIHNlcnZlcnMuIEZvciBpbnN0YW5jZSwgd2h5IHdvdWxkIHRoZSBUQ1AgY2xpZW50IGluIGFu
IEZUUA0KPiBzZXNzaW9uIG5vdCB1c2UgSVcxMD8gSSBkaXNhZ3JlZSB0aGF0IG9uZSBjYW4gZ2Vu
ZXJhbGl6ZSBmcm9tIEhUVFAgdG8gYWxsIFRDUC0NCj4gYmFzZWQgYXBwbGljYXRpb24gcHJvdG9j
b2xzLiBBbmQgdGhlcmUgaXMgYWxzbyBubyBldmlkZW5jZSB0aGF0IGNhY2hpbmcgd2lsbA0KPiB3
b3JrIGZvciBhbnkgVENQIHByb3RvY29sLiBGb3IgdGhhdCwgdGhlIHdvcnN0LWNhc2Ugc2NlbmFy
aW8gd291bGQgYmUgZW5kLQ0KPiBzeXN0ZW1zIHRoYXQgbWFpbnRhaW4gVENQIGNvbm5lY3Rpb25z
IHRvIF9tYW55XyBwZWVycyAoYXQgbGVhc3QgdGVucyBvZg0KPiB0aG91c2FuZHMgb2YgcGVlcnMs
IG1heWJlIGV2ZW4gbW9yZSkuIEhvdyB3ZWxsIHdpbGwgY2FjaGluZyB3b3JrIGluIHN1Y2gNCj4g
Y2FzZXM/IElmIHRob3NlIHN0YXRlbWVudHMgYXJlIG5vdCBiYWNrZWQgYmV0dGVyLCB0aGUgdGV4
dCBhbHJlYWR5IGV4cGxhaW5zIHdoYXQNCj4gYSByZWFkZXIgY291bGQgY29uY2x1ZGU6ICJpdCBz
ZWVtcyByYXRoZXIgb3Zlci1jb25zZXJ2YXRpdmUgdG8gcmVkdWNlIElXIGZyb20NCj4gMTAgdG8g
MSBqdXN0IGluIGNhc2UgYSBjb25nZXN0aW9uIG1hcmtpbmcgd2FzIG1pc3NlZC4iIFllcywgaW5k
ZWVkLCB1bmxlc3MNCj4gcHJvdmVuIG90aGVyd2lzZS4NCj4gDQo+IA0KPiANCj4gVGhlcmUgYXJl
IHNldmVyYWwgYXNwZWN0cyB0byB0aGlzIGNvbW1lbnQ6DQo+IEZpcnN0LCBzZWN0aW9uIDMuMy4x
LjMgcmVjb21tZW5kcyB0byByZWR1Y2UgdGhlIElXIHRvIDEgTVNTLCBidXQgaXQNCj4gYWxsb3dz
IGZvciB0aGUgaW5pdGlhdG9yIHRvIHVzZSBhIGdyZWF0ZXIgd2luZG93LiBTbywgYW4gaW1wbGVt
ZW50ZXINCj4gY2FuIGRlY2lkZSB3aGV0aGVyIHRvIGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24g
b3Igbm90Lg0KPiANCj4gVGhpcyBzZWN0aW9uIHNlcnZlcyB0aGUgcHVycG9zZSBvZiBpbmZvcm1p
bmcgdGhlIGltcGxlbWVudG9ycyB3aGVuDQo+IGRlY2lkaW5nIHdoZXRoZXIgdGhleSB3aWxsIGZv
bGxvdyB0aGUgcmVjb21tZW5kYXRpb24gb3Igbm90LiBJIGJlbGlldmUNCj4gdGhhdCBpdCBpcyB1
c2VmdWwgZm9yIHRoZW0gdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW1wYWN0IGlu
DQo+IHdlYiB0cmFmZmljLCBhcyBpdCBkb2VzIGFjY291bnQgZm9yIGEgbGFyZ2Ugc2V0IG9mIHRo
ZSB0cmFmZmljLiBJZiB0aGUNCj4gaW1wbGVtZW50YXJvcyBoYXZlIGEgZGlmZmVyZW50IGFwcGxp
Y2F0aW9ucyB1c2UgY2FzZSBpbiBtaW5kLCBzaGUNCj4gc2hvdWxkbnQgdGFrZSB0aGlzIGludG8g
YWNjb3VudC4gU2ltaWxhcmx5IGZvciBjYWNoaW5nLiBLZWVwIGluIG1pbmQNCj4gdGhhdCBjYWNo
aW5nIGlzIHJlbGV2YW50IGluIGNsaWVudHMuIEkgd291bGQgYXNzdW1lIHRoYXQgYSB2ZXJ5IGxh
cmdlDQo+IG1ham9yaXR5IG9mIGNsaWVudHMgd291bGQgd29yayB3ZWxsIHdpdGggYSBzbWFsbGVy
IGNhY2hlIHRoYW4geW91cg0KPiB3b3JzdCBjYXNlLiBJZiBhbiBpbXBsZW1lbnRvciBleHBlY3Rz
IHRoYXQgc2V2ZXJhbCB0ZW5zIG9mIHRob3VzYW5kcw0KPiBvZiBvdXRnb2luZyBjb25uZWN0aW9u
cyB3aWxsIGJlIHRoZSB1c3VhbCBjYXNlLCBzaGUgc2hvdWxkIG5vdA0KPiBjb25zaWRlciB0aGlz
IGFyZ3VtZW50IG5laXRoZXIuIEFnYWluLCB0aGlzIGlzIGEgbm9uIG5vcm1hdGl2ZSBwYXJ0IG9m
DQo+IHRoZSBzcGVjaWZpY2F0aW9uLiBLZWVwaW5nIHRoZXNlIGFyZ3VtZW50cyBoZXJlLCBhbGxv
dyB0aGUNCj4gaW1wbGVtZW50b3JzIHRvIG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIGlm
IHRoZSBhcmd1bWVudHMgaGVyZQ0KPiBhcmUgbm90IGNvbnZpbmNpbmcuDQoNCkFzIEkgYW0gbm90
IGFuIGltcGxlbWVudGVyLCBpdCBwcm9iYWJseSBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIGZ1cnRo
ZXIgcHVzaCBiYWNrIGhlcmUuDQoNCllldCwgSSBzdWdnZXN0IHRoYXQgaW1wbGVtZW50ZXJzIGNh
cmVmdWxseSByZXZpZXcgdGhpcyBzZWN0aW9uIGFzIHRoaXMgaXMgYWxzbyBhIGxvdCBhYm91dCBz
dGFjayBpbnRlcm5hbHMuIEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgY29uZmly
bWF0aW9uIHRoYXQgdGhlIG5ldyB3b3JkaW5nIHdvcmtzIGZvciBpbXBsZW1lbnRlcnMuDQoNCj4g
PiAqIFNlY3Rpb24gMg0KPiA+DQo+ID4gICAiT3B0aW9uYWxseSwgaXQgY291bGQgbWVhbiBFQ1Qo
MSksIHdoaWNoIGlzIGluIHRoZSBwcm9jZXNzIG9mIGJlaW5nIHJlZGVmaW5lZA0KPiBmb3IgdXNl
IGJ5IEw0UyBleHBlcmltZW50cyBbUkZDODMxMV0gW0ktRC5pZXRmLXRzdndnLWVjbi1sNHMtaWRd
LiINCj4gPg0KPiA+ICAgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGlzIG1hdHRlcnMgaGVyZSBn
aXZlbiB0aGF0IHNlY3Rpb24gMSBhbHJlYWR5DQo+IGV4cGxhaW5zIHRoYXQgdGhpcyBkb2N1bWVu
dCBpcyBjb21wYXRpYmxlIHdpdGggTDRTLg0KPiANCj4gDQo+IA0KPiBidXQgaXQgbWFrZXMgc2Vu
c2UgdG8gbWVudGlvbiBpdCBoZXJlLCBzaW5jZSB3ZSBwcm92aWRlIHNvbWUNCj4ganVzdGlmaWNh
dGlvbiB3aHkgYnkgZGVmYXVsdCBpcyBFQ3QoMCkgYW5kIHdoYXQgYWJvdXQgRUNUKDEpLg0KDQpJ
IGJlbGlldmUgdGhhdCAiT3B0aW9uYWxseSwgaXQgY291bGQgbWVhbiBFQ1QoMSkiIHdvdWxkIGJl
IHN1ZmZpY2llbnQsIGFzIHRoZW4gdGhlIGRvY3VtZW50IHdvdWxkIGdldCBpbmRlcGVuZGVudCBv
ZiBvbmdvaW5nIGRpc2N1c3Npb25zLiBBbnl3YXksIHRoaXMgc3RhdGVtZW50IHNob3VsZCBwcm9i
YWJseSBiZSByZXZpZXdlZCBhZnRlciB0aGUgb25nb2luZyBkaXNjdXNzaW9ucyBoYXZlIHJlYWNo
ZWQgY29uc2Vuc3VzLg0KDQpbLi4uXQ0KDQpPbmUgYWRkaXRpb25hbCBjb21tZW50IG9uIHRoZSBT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucywgd2hpY2ggaXMgYSBiaXQgc2hvcnQ6DQoNCkNvdWxkIEVD
TisrIGJlIHVzZWQgZm9yIGltcHJvdmluZyBUQ1AvSVAgc3RhY2sgZmluZ2VycHJpbnRpbmc/IFNw
ZWNpZmljYWxseSB0aGUgU1lOIG1heSBiZSBvZiBpbnRlcmVzdCBmb3IgdGhhdC4gSWYgc28sIGl0
IG1heSBiZSB3b3J0aHdoaWxlIHRvIG1lbnRpb24gdGhpcyBpbiB0aGUgU2VjdXJpdHkgQ29uc2lk
ZXJhdGlvbnMuDQoNCklmIHNvLCB0aGlzIGFjdHVhbGx5IGNvdWxkIGFsc28gbWF0dGVyIGZvciB0
aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uIGluIGRyYWZ0LWlldGYtdGNwbS1hY2N1
cmF0ZS1lY24uDQoNCg0KRWRpdG9yaWFsIG5pdHM6DQoNCi0gcGFnZSA5OiAiZG9lcyBub3Qgc3Vw
cG9ydF9fIEFjY0VDTiINCg0KLSBwYWdlIDExOiAiZG9lcyBub3Qgc3VwcG9ydCBBY2NFQ04gYV9u
X2QgaWYgdGhlIGluaXRpYWwgY29uZ2VzdGlvbiINCg0KDQpUaGFua3MgYWdhaW4NCg0KTWljaGFl
bA0K


From nobody Sat Nov 16 13:45:10 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 F2987120951 for ; Fri, 15 Nov 2019 11:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zyyGYL3hSEaU for ; Fri, 15 Nov 2019 11:54:31 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 9F7BC12093A for ; Fri, 15 Nov 2019 11:54:29 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id l14so9004594oti.10 for ; Fri, 15 Nov 2019 11:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y/rx2rSO9FCdCT2WzhGifssgjaoHof3iQ5ZD1tlJtP4=; b=ANb3c7Y4gJO4hxM1wrcRmSMLiLU2Z8G01YzqtpYaTHxvqwIY2JqoFulqy6by1nzo+U PlCh/tJTddwEGUO9K+BlR4MOwA88v8W6Is1ibGmpDtmb1rG/9+SAneMf8YW8U+xRF3fi lEvqHkR2C6N4S6J5RsR5NblYP45HPP/OrNLA3reyVJtLF0C+fw59sWmQG0ealiQv+mLv ZRoJlpkFasqZ8Cz2H/nkiSwaoXlxxj61kJOqaySJBwMYwsYSuZWr1OzOeX3WhERupeDF 9DQej0szePORBFkyFDZIww53M3Ed9cvJrcR1bVEJSrosD+WQl4ZXd8ZneEZR4fKaFWZm UNzQ==
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; bh=Y/rx2rSO9FCdCT2WzhGifssgjaoHof3iQ5ZD1tlJtP4=; b=ZIRg7qrwSIy22mK7/sj2SfHTDEhMsmqEQHqTSeqUX4A2O3weemAHWwejDAMVPwimsF RnEUXHaqaGD2yLA3woA6iV5T74dWo4O6M9VjWRkQ0Bh26ONfdrq2uJoXh7Eqyyl13gsm HFkBp7JEng3EAu1jU5dEUi/CRw1oN3CqqpXd0F2Tgnkv0rFrmTwhIXCLiS1giLpa3W9F ZWlaXQjhUSjKg88Ckj0Fv3lG2cWWIOn1jHzkKYV/Q/FPhrB8Cbd5gjt0zmVtLl5As+Aj BcR32ZtKMvsQ2sF5rQ63rAlWKQETepGzzxkg1/F6/lEku4AYtVREQSGdG0/LlR05C6wl yzqg==
X-Gm-Message-State: APjAAAUOkggLpLz90PPWtSk5TUDVdmPg7QZsQjBO1norlMTXjlD2sVnd PYKj39H2HT3ATe9MZ9fzkobZ/RR+MvwUJ+1K/0Grpw==
X-Google-Smtp-Source: APXvYqwWK9UTHUoRHWl1T7cIZp5NG6DFIeW61oumf/bXE2bchlwKLovApbQe0i+4XSImRxS1CcaWMIb8iFNY66memz0=
X-Received: by 2002:a9d:1b3:: with SMTP id e48mr13089966ote.341.1573847668148;  Fri, 15 Nov 2019 11:54:28 -0800 (PST)
MIME-Version: 1.0
References: <20191114020710.3359AF406D8@rfc-editor.org> 
In-Reply-To: 
From: Neal Cardwell 
Date: Fri, 15 Nov 2019 14:54:11 -0500
Message-ID: 
To: RFC Errata System 
Cc: rhee@ncsu.edu, Lisong Xu , Sangtae Ha , alexander.zimmermann@rwth-aachen.de, "Eggert, Lars" ,  Richard Scheffenegger , ietf@kuehlewind.net, magnus.westerlund@ericsson.com,  "Scharf, Michael" , Michael Tuexen ,  nsd.ietf@gmail.com, tcpm ,  Elliott Ecton 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-Mailman-Approved-At: Sat, 16 Nov 2019 13:45:09 -0800
Subject: Re: [tcpm] [Technical Errata Reported] RFC8312 (5907)
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, 15 Nov 2019 19:54:34 -0000

On Thu, Nov 14, 2019 at 12:53 PM Neal Cardwell  wrote:
>
> On Thu, Nov 14, 2019 at 12:12 PM RFC Errata System
>  wrote:
> >
> > The following errata report has been submitted for RFC8312,
> > "CUBIC for Fast Long-Distance Networks".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5907
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Elliott Ecton 
> >
> > Section: 5.1
> >
> > Original Text
> > -------------
> >  +--------+----------+-----------+------------+-----------+----------+
> >    |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
> >    | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
> >    +--------+----------+-----------+------------+-----------+----------+
> >    |  10^-2 |       12 |        12 |         12 |        12 |       12 |
> >    |  10^-3 |       38 |        38 |         38 |        38 |       59 |
> >    |  10^-4 |      120 |       263 |        120 |       187 |      333 |
> >    |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
> >    |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
> >    |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
> >    |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
> >    +--------+----------+-----------+------------+-----------+----------+
> >
> >                                   Table 1
> >
> > Corrected Text
> > --------------
> >  +--------+----------+-----------+------------+-----------+----------+
> >    |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
> >    | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
> >    +--------+----------+-----------+------------+-----------+----------+
> >    |  10^-2 |       12 |        12 |          3 |         6 |       11 |
> >    |  10^-3 |       38 |        38 |         19 |        33 |       59 |
> >    |  10^-4 |      120 |       263 |        120 |       187 |      333 |
> >    |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
> >    |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
> >    |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
> >    |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
> >    +--------+----------+-----------+------------+-----------+----------+
> >
> >                                   Table 1
> >
> > Notes
> > -----
> > The CUBIC average window sizes for 10^2 and 10^3 are incorrect in the original text using expression 6.
>
> I strongly suspect that the original text is correct.
>
> Note that the proposed edit would cause the average congestion window
> size of CUBIC to be below that of "TCP W", the Reno [RFC5681] window,
> in the cases with loss rates of 10^-2 and 10^-3. But as mentioned in
> section 4.2. "TCP-Friendly Region", where the native CUBIC curve
> computation produces a target congestion window that is lower than the
> congestion window Reno would use, the CUBIC algorithm instead uses the
> Reno target congestion window. So the average congestion window size
> of CUBIC should not be below that of Reno. I believe that is why in
> the original table the average congestion window for "TCP W" and CUBIC
> match in cases with loss rates of 10^-2 and 10^-3 and with CUBIC using
> C=0.04 or C=0.4.
>
> Are there tests or simulations showing CUBIC achieving a lower
> congestion window in these cases with loss rates of 10^-2 and 10^-3?
>
> best,
> neal

I got a bounce from my "reply-all". It seems there was a typo in the
e-mail address of the report, and it should have been:
  Elliott Ecton 
...rather than:
  Elliott Ecton 

I am following up to make sure the elliott.ecton@netapp.com address
has the reply and the thread has the correct e-mail address.

best,
neal


From nobody Sun Nov 17 00:49:39 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 52DF712008D for ; Sun, 17 Nov 2019 00:49:37 -0800 (PST)
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=microsoft.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 M81EBK98WBSA for ; Sun, 17 Nov 2019 00:49:35 -0800 (PST)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730102.outbound.protection.outlook.com [40.107.73.102]) (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 2CCAF12007A for ; Sun, 17 Nov 2019 00:49:35 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wjw1v+tBjDuHU/PYeA/vPGoP37ooDMdI186FFDFYU+YjCRJDSuJGoBQwThJXfZ/9yM9iYrDHlxqMlvDDMDdqwkevNlSXZx7eKru0o8U/7sb/e9F5VCQ6HgzA4LQaaGxtFoHV9HnVvEKqBwmGZkQXtd9k0bBx88663kPtbs8Xyq8OQPmwcrkOaxWPgBxZvE/gs6Ef/qwfA5/iR1vtNH0njvQ37ohZxPViduE1BdW9M6+xxqIjpWD5n0CiRfaPzrBJhbf9WfAB1zHbj69BNQiliatkDSQZSuAfvupd+Vr8ncAAjDlrWNeRKZVfmE8fbRKrTlDzd/ZWyu/PqAdRt7/QkQ==
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=JBHZ++J4zchhycezy9IUoc3p0cnb4EM1PFthmUaWrN4=; b=Ub0OPIG/0Uw2RJzZIS5rmsAzIp0c5WSeIda9vfE6gj4xwoZ1q0LX09opbGOQorwPQvptRYoLHcnrS35LiG35PziCXVEPpizHIET+lhgz8W4GyctV+YwOt/VCMfSt4DUedF4MVvQMuU8uJF/cb7UOP/6twYKoh8REofo17C7cumfolH+Z+vuxIrBXDP6Quf+AUO3UoCI1Vt+jmDVG5LFIQiSFHYsRfxrIStlUsUj4U7EnulMArevQB1B6sSB/Nc36ofy90JsmiNI6QWKNEhZnqWXyQMPjQxs8SYT7BxoFjQ6FaLnjybNZCY3KBr4GufcfEItomiE377L/TNh5d45h1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JBHZ++J4zchhycezy9IUoc3p0cnb4EM1PFthmUaWrN4=; b=htuuaLdVjhmzbifayNMFCQavYqo6wXilFMn5mRsEHeHW2lcyUu6EB9F3VB1zFbz5uNezhDy+9F6R5e+VGjxvy1f5Cg9obYuhzDW1sbPJQONpm50CihfE7UJhVF2YEQ4HlmZk9OtomsFz1ShvCbINhd82b8Kuh5qMFxAmqAMrJhU=
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1034.namprd21.prod.outlook.com (52.132.149.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.13; Sun, 17 Nov 2019 08:49:18 +0000
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::f8d0:bf38:ea25:edfa]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::f8d0:bf38:ea25:edfa%7]) with mapi id 15.20.2474.011; Sun, 17 Nov 2019 08:49:18 +0000
From: Praveen Balasubramanian 
To: Michael Tuexen , "tcpm@ietf.org Extensions" 
Thread-Topic: [tcpm] Intended status of draft-ietf-tcpm-rack
Thread-Index: AQHVl/uYcnGNU5hNWUS9WmrRVSx0B6ePF1Jg
Date: Sun, 17 Nov 2019 08:49:18 +0000
Message-ID: 
References: <903982D2-36DE-428D-A7C5-D3C389C95E9A@lurchi.franken.de>
In-Reply-To: <903982D2-36DE-428D-A7C5-D3C389C95E9A@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b4c8ee53-5d79-445c-9a19-00001ce927ff; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-17T08:47:30Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-originating-ip: [2001:67c:1232:144:d572:6241:e96f:6710]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cc0c0111-5d70-43bf-2bcf-08d76b3b088e
x-ms-traffictypediagnostic: MW2PR2101MB1034:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 02243C58C6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(39860400002)(396003)(13464003)(189003)(199004)(86362001)(8676002)(110136005)(229853002)(6116002)(74316002)(966005)(102836004)(5660300002)(316002)(76176011)(6436002)(53546011)(6506007)(478600001)(22452003)(25786009)(46003)(2906002)(14454004)(7736002)(9686003)(11346002)(33656002)(6246003)(10290500003)(8990500004)(256004)(446003)(7696005)(55016002)(76116006)(486006)(186003)(305945005)(71200400001)(71190400001)(66946007)(64756008)(66476007)(66556008)(8936002)(81156014)(10090500001)(66446008)(6306002)(52536014)(81166006)(99286004)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1034; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3U3Rkoakhs2QSAmpX1UGgxMd8+WmqHICkBkmIlVNnUQgj3MGKwpIcCVJTIeOWHSYBm/NU/iOdquFMv1Kiu/LhZsPSe/fuNenmb5TTIWX2b3sDF15iIRV1q+Zl0WjY5oykU8XkVWu+kYucPEhmdp/QIihTU+OB9IRP6FaW1QM4iGuU+ZJG6DokTe0o1fcJSOCjYcg0J6QpBwyuGC8uHNs/wkfR4apOfnm9S/+Dq2sCmjcIoDpVasuekjjLcrWqmJtGVEXgt1OrpiP7g9zUx4Eie4QsrZG7eKVvsyQR0ApCPeWVVDc+gE/ETre8ucuKMfanLK8OrZRUN6HhEEgiZ+69WkH3UVy+z2aAKvBWSdH5DYd/tikV5YxcRwNkE9+hFLJRJ2H9rY+ejIWuROOvcTbqvUVoPwWQYVs++zUFf3FQrOOedM42WTJHxsfA7yvyQ4v
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc0c0111-5d70-43bf-2bcf-08d76b3b088e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 08:49:18.6532 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: B+mhW67dxSTq0pdlrwGUOf59sIndpMW6s+k67ohz91s2W1RpOFihtA30RWpyyXgXdTLPFsHuxld64ZPVnpBDrgdexqMayAK8RoTOOQDhUcM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1034
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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: Sun, 17 Nov 2019 08:49:37 -0000

RACK is fundamental enough, subsumes TLP, and has enough implementation and=
 deployment. My vote is for PS status.=20

-----Original Message-----
From: tcpm  On Behalf Of Michael Tuexen
Sent: Monday, November 11, 2019 3:17 AM
To: tcpm@ietf.org Extensions 
Subject: [tcpm] Intended status of draft-ietf-tcpm-rack

Dear all,

the current intended status of draft-ietf-tcpm-rack is experimental.

The authors have indicated that they think the ID is ready for WG LC.
Before starting that, I would like to bring up the question of the intended=
 status of draft-ietf-tcpm-rack.

Due to the fact that there are at least two independent implementations, th=
ere has been substantial testing and also deployment, I would like to ask t=
he working group, if PS is a more appropriate intended status.

Any preferences or opinions?

Best regards
Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.co=
m%7Cb8a101b2647d43d2721908d7661293b5%7C72f988bf86f141af91ab2d7cd011db47%7C1=
%7C0%7C637090102918896374&sdata=3DOpzzv5HV%2FmNrTypK32cTXkuf9jwKoifihf1=
4Wua6aM4%3D&reserved=3D0


From nobody Sun Nov 17 01:33: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 CCC4D1200C4; Sun, 17 Nov 2019 01:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 O52rdU7CCrHI; Sun, 17 Nov 2019 01:33:02 -0800 (PST)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 AE9EA12008D; Sun, 17 Nov 2019 01:33:01 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id xAH9Wox0019864;  Sun, 17 Nov 2019 10:32:50 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6139B1D53C1; Sun, 17 Nov 2019 10:32:49 +0100 (CET)
Received: from 27.96.125.210 by webmail.entel.upc.edu with HTTP; Sun, 17 Nov 2019 10:32:50 +0100
Message-ID: 
In-Reply-To: 
References:    <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu>  
Date: Sun, 17 Nov 2019 10:32:50 +0100
From: "Carles Gomez Montenegro" 
To: =?iso-8859-1?Q?=22Ilpo_J=E4rvinen=22?= 
Cc: "Mohit Sethi M" , "lwip@ietf.org" , "tcpm@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "kojo@cs.helsinki.fi" 
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sun, 17 Nov 2019 10:32:51 +0100 (CET)
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: Sun, 17 Nov 2019 09:33:04 -0000

Hi Ilpo,

First of all, apologies for this very late reply.

Once again, thanks a lot for your thorough review!

We recently published -09. We believe that this last revision addresses
your remaining points below.

Should you have further comments, please do not hesitate to let us know.

Thanks,

Carles




> 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 Sun Nov 17 01:49:48 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 541FB12007A; Sun, 17 Nov 2019 01:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 05PrfPh9PjOc; Sun, 17 Nov 2019 01:49:40 -0800 (PST)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 B391512004D; Sun, 17 Nov 2019 01:49:39 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id xAH9nXjm024864;  Sun, 17 Nov 2019 10:49:33 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D703D1D53C1; Sun, 17 Nov 2019 10:49:32 +0100 (CET)
Received: from 27.96.125.210 by webmail.entel.upc.edu with HTTP; Sun, 17 Nov 2019 10:49:33 +0100
Message-ID: 
In-Reply-To: 
References: <4de71836-c2d1-2a64-6836-8d69a38d4a3d@ericsson.com>   
Date: Sun, 17 Nov 2019 10:49:33 +0100
From: "Carles Gomez Montenegro" 
To: "Markku Kojo" 
Cc: lwip@ietf.org, tcpm@ietf.org, jon.crowcroft@cl.cam.ac.uk
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 00:16:43 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sun, 17 Nov 2019 10:49:34 +0100 (CET)
Archived-At: 
Subject: Re: [tcpm] [Lwip] WGLC review ofdraft-ietf-lwig-tcp-constrained-node-networks
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: Sun, 17 Nov 2019 09:49:42 -0000

Dear Markku,

First of all, our apologies for the delay in this response!

We would like to thank you once again for your thorough review and update
suggestions.

We recently published -09, with the aim of addressing the remaining points.

Please find below our inline responses:

> Dear Carles, all,
>
> it took longer to find time to pass through the draft than I thought a
> week or so ago. My apologies and thanks for your patience.
>
> It looks fine to me with a few exceptions that still seem to need some
> work, I think.
>
> Please see inline.
>
> Cheers,
>
> /Markku
>
> On Wed, 5 Jun 2019, Carles Gomez Montenegro wrote:
>
>> Dear Markku,
>>
>> Thank you very much for your comprehensive and detailed review of the
>> draft. Your constructive comments have been very useful to address
>> issues
>> and improve the quality of the document. Our updates can be found in
>> revision -08.
>>
>> Please find below our inline responses to your comments.
>>
>>> Hi all,
>>>
>>> I have reviewed the -07 version of this draft for the WGLC.
>>>
>>> The draft is very useful for many developpers using or considering of
>>> using TCP in CNN scenarious. It has improved a lot from the previous
>>> versions but there are still a number of issues worth addressing.
>>>
>>> See comments below.
>>>
>>> Best regards,
>>>
>>> /Markku
>>>
>>> Sec 4.1.
>>>
>>> Title: Path properties
>>> - Would it be better to use "Addressing path properties" or something
>>> similar as TCP cannot (much) affect the properties?
>>
>> Sounds good!
>>
>>> Sec. 4.1.1.
>>>
>>> If I understand it correctly, the discussion in this section is
>>> intended
>>> to be all about avoiding Path MTU discovery when running TCP oevr IPv6?
>>> Therefore, "Avoiding Path MTU Discovery in IPv6" would probably be
>>> a better title?
>>
>>> From our point of view, the section is actually about setting the MSS
>>> to a
>> suitable value, which then may help avoiding the need to support Path
>> MTU
>> Discovery, but also the need to perform IP-layer fragmentation at the
>> source. We have explicitly added the latter in -08.
>
> This seems fine now, except I noticed another problem that I didn't spot
> last time. The text says a few of times something about
> limiting/setting MTU, where you actually want to advice limiting IP
> datagram size (by setting the MSS), just like you say above. But the text
> reads, for example:
>
>   ... it may be desirable to limit the MTU to 1280 bytes ...
>
> which I believe should read somethig like:
>
>   ... it may be desirable to limit the IP datagram size to 1280 bytes ...
>
> MTU is the property of the network link at hand, not controllable same way
> as the IP datagram size which can be limited by setting the TCP MSS. And,
> if MTU was settable, avoiding framentation would call for setting it to as
> large value as possible, not limiting it.

Agreed!

>>> In addition, to my understanding TCP implementations typically address
>>> the presence of TCP options such that they eat the necessary space for
>>> TCP options from the payload, not by increasing the IP datagram size
>>> if TCP options are present. For example, if SMSS is set to, let's say
>>> 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes) it
>>> will send only 1448 bytes of payload in a TCP segment?
>>>
>>> What the draft now says in this respect is on the safe side, but it
>>> might be overcautious. I don't remember any RFC saying how SMSS and
>>> adding options to a TCP segment are related. Maybe someone of the TCP
>>> implementors may shed more light to this how?
>>
>> We have tried to address your two comments above. On this matter, we had
>> received feedback that this measure (advertising an MSS smaller than
>> 1220
>> bytes) would be safe, but we have tried to reflect that this might not
>> be
>> necessary, and even overcautious.
>
> Seems fine, thanks.
>
>>> The second but last para discussing IPv4 in this context is very
>>> confusing. In particular, the 2nd sentence
>>>
>>>   "In IPv4, the MTU is 576 bytes."
>>>
>>> is simply incorrect. In IPv4 the requirement is that any host must be
>>> able to accept datagrams of up to 576 octets, but there is no upper
>>> limit of 576 for IPv4 MTU!
>>
>> Indeed. The 2nd sentence missed the word ?minimum? before ?MTU?, and we
>> have made several updates to the paragraph.
>
> Maybe I was unclear in my comment. There is no upper nor lower limit of
> 576 for IPv4 MTU. Definitely MTU can be less than 576. Moreover,
> IPv4 requires that every node must be able to forward an IP packet of 68
> bytes without fragmentation, but even this is not exactly a minimum MTU
> requiremt. It is because IP is not necessarily able to fragment packets
> smaller than 68 bytes. In other words, there is no similar requirement
> for link layers to support a certain minimum MTU with IPv4 as there is
> for IPv6 that requires link layers to support an MTU of at least 1280
> bytes.
> Therefore, I think it is hard to give similar advise for IPv4 as the
> draft gives for IPv6.

Agreed. We removed the intended guidance text for IPv4.

>>> Sec. 4.1.2.
>>>
>>>   "In such traffic patterns, it is more difficult to
>>>    detect packet loss without retransmission timeouts ..."
>>>
>>> ->
>>>
>>>   "In such traffic patterns, it is more difficult and often
>>>    impossible to detect packet loss without retransmission timeouts
>>>    unless ECN is enabled ..."
>>
>> Done.
>>
>>>
>>>   "When the congestion window of a TCP sender has a
>>>   size of one segment, the TCP sender resets the retransmit timer, and
>>>   the sender will only be able to send a new packet when the retransmit
>>>   timer expires [RFC3168]. Effectively, the TCP sender reduces at that
>>>   moment its sending rate from 1 segment per Round Trip Time (RTT) to 1
>>>   segment per RTO, which can result in a very low throughput.  In
>>>   addition to better throughput, ECN can also help reducing latency and
>>>   ECN can also help reducing latency and	jitter."
>>>
>>> This text is somewhat inaccurate in terms of how ECN works if only a
>>> single segment is in flight (cwnd = 1 MSS) and confusing when it says
>>> "which can result in a very low throughput". The latter is kind a true,
>>> but also necessary to avoid congestion and, after all, it may result in
>>> higher throughput compared to the case where ECN is not used and
>>> retransmissions are needed.
>>>
>>> I'd rephrase the above to something along the lines:
>>>
>>>   "When the congestion window of a TCP sender has a
>>>   size of one segment and a TCP ACK with an ECN signal (ECE flag)
>>> arrives
>>>   at the TCP sender, the TCP sender resets the retransmit timer, and
>>>   the sender will only be able to send a new packet when the retransmit
>>>   timer expires. Effectively, the TCP sender reduces at that
>>>   moment its sending rate from 1 segment per Round Trip Time (RTT) to 1
>>>   segment per RTO and reduces the sending rate further on each ECN
>>> signal
>>>   received in subsequent TCP ACKs. Otherwise, if an ECN signal is not
>>>   present in a subsequent TCP ACK the TCP sender resumes the normal
>>>   ack-clocked transmission of segments [RFC 3168].
>>
>> Thank you very much for the proposed text. The draft has been updated
>> accordingly.
>>
>>> It might be also good to rearrange the text in the second and third
>>> paragraphs to disscuss the effect of retrasmission and timeouts more
>>> coherently. I may suggest text for this.
>>
>> We will welcome any suggestion you may have in this regard.
>
> I'm fine with the text as is. It seems to me after all that rearranging
> the text is not crucial. A reader should get the intended message,
> although rewrite might help the reader.
>
>>> Sec 4.2.
>>>
>>>   "This section discusses TCP stacks that focus on transferring a
>>> single
>>>    MSS."
>>>
>>> Maybe better:
>>>
>>>   "This section discusses TCP stacks that allow transferring only a
>>> single
>>>    MSS at a time."
>>
>> Done.
>
> Sorry, but now I am a bit confused here with the new naming. Earlier this
> was titled "single MSS-windows and buffers" and "single-MSS stacks" and
> the text indicated that such TCP stack reduces its maximum advertized
> window to one MSS and may only hold one MSS of data in its send and
> receive buffers. Further, the text indicated and still indicates that
> such a stack may, however, have several TCP segments in flight as long as
> they carry at most one MSS worth of data in total. So, my comments were
> based on that assumption.
>
> Now the new way of naming them as "single-segment stacks" hints that these
> are even more restricted such that the stack has e.g., limited capability
> for bookkeeping and may only hold a single TCP segment in its one MSS send
> or receive buffer at a time regardless of the payload size of the
> segment and thereby possibly have only(?) a single data segment in
> flight in each direction at any point of time. That is, once such a TCP
> sender has received some data from the application, it does not accept
> more data from the application until a cumulative Ack has arrived and
> released the send buffer for the next piece of app data. And such a TCP
> receiver advertises zero window once it receives a data segment carrying
> any amount of data (e.g., only a single byte).
>
> Or, there obviously can be different variants of these two behaviors
> above, for example uIP that releases the send buffer after transmitting
> the segment and requires the app to provide the same data for possible
> retransmission. Or, a receiving TCP always delivers the segment
> immediately to the application (and the receive buffer is possibly
> provided by the application).
>
> So, what is exactly meant by a "single-segment stack"? Both variants
> above are possible, or various flavors of them, and possibly
> both types of stacks exist at least for the TCP send buffer
> implementation? Single-segment reveive buffer implementations that keep
> the segment in the TCP reveive buffer until an application receives it
> would have hard time to work decently with a regular TCP stack in certain
> fully legitimate scenarios, though. Therefore, they possibly are
> non-existing?
>
> The definition affects the text in many parts of the draft as well my
> comments. For now, I continue with my original interpretation and assume
> the definition of "single-MSS buffers" hold. Otherwise, the split hack
> would not be possible at all if the TCP sender is not able to compose
> more than one segment at a time and  would result in really bad
> performance with a receiver stack that may accept only a single segment
> at time, right?

We realized that "single-MSS" is a better term, as in fact it reflects
what is supported by the most constrained major TCP implementations for
IoT scenarios.

>>> Sec 4.2.1.
>>>
>>> Last sentence:
>>>
>>>   "For this use of CoAP, a maximum TCP window
>>>    of one MSS will be sufficient."
>>>
>>> This is not necessarily true. If both TCP stacks involved allow a TCP
>>> window larger than 1 MSS and a CoAP request or response larger than one
>>> MSS is in use, it can be delivered more efficiently than in case where
>>> max TCP window is one MSS.
>
> The above part of the comment is addressed in the new text, thank you.
>
>>> Furthermore, this may also not be the case if a CoAP over TCP
>>> application uses short-lived TCP connections. Why? Because then the
>>> mandatory CSM message that each CoAP endpoint sends after the 3WHS may
>>> introduce an additional RTT as it cannot necessarily be sent during the
>>> same RTT with the first CoAP request/response. Of course, if the CSM
>>> message and the first CoAP request/response message fit into a single
>>> MSS and the TCP Nagle algorithm is disabled, such a single MSS window
>>> does not result in an additional RTT.
>
> .. but this not?
>
> It is true that a CoAP endpoint is not allowed to send a new
> application message until a response to the previous one has been
> received. However, sending a CMS message is a mandatory artefact
> of CoAP over TCP and it is sent as the first msg over the TCP
> connection and in both directions. This CMS message eats a part of the one
> MSS window. The CoAP over TCP spec allows sending the first application
> message immediately after the CMS has been transmitted. However, a TCP
> window of one MSS may prevent TCP from transmitting the app msg until
> the TCP Ack for the TCP segment carrying CSM has arrived (depends on the
> size of these msgs and the MSS). Therefore, the performance may degrade
> notably for apps running on a single-segment or single-MSS stack at either
> end and using short-lived TCP connections as they may need to first wait
> for the TCP Ack for the CSM and only then can the first application
> message be transmitted. The need for waiting for the TCP Ack of CSM
> arises always if Nagle is enabled, and if Nagle is disabled it may arise
> due to the lack of buffer space to hold both CSM and the first data
> segment carrying the first application message.
>
> Not quite sure how to address this nicely, since it is a small
> CoAP over TCP detail that mostly affects short-lived TCP connections but
> depends on the size of the first msgs and MSS (as well as Nagle). That
> is, it has an effect under certain conditions, not necessarily always. And
> it may have a significant effect or only a negligible effect.

We added text intended to point out the above.

>> We have updated the sentence accordingly.
>
>>> Sec. 4.2.2.
>>>
>>>   "A TCP implementation for a constrained device that uses a single-MSS
>>>   TCP receive or transmit window size may not benefit from supporting
>>>   the following TCP options: Window scale [RFC7323], TCP Timestamps
>>>   [RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted
>>>   [RFC2018]."
>>>
>>> It may be useful to mention that a TCP sender can benefit from
>>> Timestamps in detecting spurious RTOs that are quite likely to occur
>>> in CNN scenarios.
>>
>> Done.
>>
>>>
>>> Sec. 4.2.3.
>>>
>>> 2nd para:
>>>
>>>   "A device that advertises a single-MSS receive window should avoid
>>> use
>>>   of Delayed ACKs in order to avoid contributing unnecessary delay (of
>>>   up to 500 ms) to the RTT [RFC5681], which limits the throughput and
>>>   can increase the data delivery time."
>>>
>>> This should not appear as a generic recommendation as it is not
>>> correct for some typical usage scenarios such as request-response
>>> traffic where the node with a single-MSS receive window is the server
>>> sending the responses. With delayed ACKs it can biggyback the TCP ACK
>>> with the response if the response is sent before the delayed ACK timer
>>> expires, thus avoiding unnecessary pure TCP ACKs.
>>>
>>> So, here, like in Sec 4.3.2., it is important to indicate that it
>>> depends
>>> on the communication pattern whether delayed ACKs are useful or
>>> harmful.
>>
>> We have modified this text accordingly.
>>
>>> 3rd para:
>>>
>>>   "A device that can send at most one MSS of data is significantly
>>>   affected if the receiver uses Delayed ACKs, e.g., if a TCP server or
>>>   receiver is outside the CNN."
>>>
>>> Again, this does not hold in all cases. E.g., if the server is outside
>>> of the CNN and request-response communication is used.
>>
>> We have modified and reorganized the text accordingly.
>>
>>> The "split hack" is not advisable workaround. First for the reason
>>> stated in the end of the para, but more importantly because it simply
>>> does not necessarily even work; a TCP receiver is requited to
>>> acknowledge every second full-sized segment, but not two consecutive
>>> small segments.
>>
>> Agreed. This comment has been incorporated into the text. We discuss the
>> ?split hack?, but we do not recommend it.
>
> Fine. May I suggest a minor additional tweak:
>
> "A standard compliant TCP receiver will acknowledge the second MSS of
> data, ..."
>
>   ->
>
> "A standard compliant TCP receiver may immediately acknowledge the second
> MSS of data, ..."

Done, thanks!

>>> 4th para:
>>>
>>>   "Similar issues happen when a sender uses the Nagle algorithm.
>>>   Disabling the algorithm will not have impact if the sender can only
>>>   handle stop-and-wait operation."
>>>
>>> Actually it does have an impact in some specific usage scenarios, e.g.,
>>> with CoAP over TCP disabling the Nagle algorithm allows sending the
>>> mandatory CSM message and the first CoAP  msg (request) and possibly
>>> also CSM and the first response without unnecessarily waiting for a TCP
>>> ACK of the CSM msg. This is of particular impact if short-lived TCP
>>> connections are in use with CoAP over TCP.
>>
>> The text above refers to stop-and-wait operation. In your example above,
>> were you considering stop-and-wait operation?
>
> Yes, I was considering stop-and-wait operation at the application level in
> the context of CoAP over TCP which happens to be a weird thing. Even
> though a single CoAP request msg may be issued at a time, the
> transmission of the CSM message in the beginning of the TCP connection
> breaks the stop-and-wait operation.
>
> But, I'm not anymore sure how to interpret the text. Where does "similar
> issues" now refer to?
>
> It may be useful to consider moving the discussion on Nagle to Sec 4.2.1
> in the context of CoAP over TCP where it has an impact and not discuss it
> here at all, because it is not that necessary to say here that "Nagle is
> no-op"?

We tried to clarify the text in -09.

>>> Sec. 4.2.4.
>>>
>>> RTO is not estimated but calculated using estimated RTT and deviation
>>> from it. That is, modify:
>>>
>>> RTO estimation -> RTO calculation
>>
>> Done.
>>
>>> 2nd para:
>>>   "[RFC6298] describes the standard TCP RTO algorithm."
>>>
>>> You may delete this sentence and cite RFC 6298 in the first sentence
>>> of the Sec 4.2.4 where the algorithm is first mentioned.
>>
>> Done.
>>
>>> 3rd para:
>>>   "As an example, an adaptive RTO algorithm for CoAP over UDP has been
>>>   defined [I-D.ietf-core-cocoa] that has been found to perform  well in
>>>   CNN scenarios [Commag]."
>>>
>>> Maybe not a good idea to cite the current version of CoCoA RTO
>>> algorithm (v3) that have been found also to have detrimental behavior?
>>
>> Done.
>
> Maybe I should not say this but possibly could cite here more than one
> alternative that have been experimentally shown to perform well ;)

Done ;)

>>> Sec. 4.3.1.
>>>
>>>   "Assuming that Delayed ACKs are used by the receiver, the
>>>   mentioned algorithms work efficiently for window sizes of at least 5
>>>   MSS: If in a given TCP transmission of segments 1, 2, 3, 4, 5, and 6
>>>   the segment 2 gets lost, the sender should get an ACK for segment 1
>>>   when 3 arrives and duplicate acknowledgements when 4, 5, and 6
>>>   arrive. It will retransmit segment 2 when the third duplicate ACK
>>>   arrives. In order to have segment 2, 3, 4, 5, and 6 sent, the window
>>>   has to be at least 5 MSS. With an MSS of 1220 byte, a buffer of the
>>>   size of 5 MSS would require 6100 bytes."
>>>
>>> The requirement for the window size to be of at least 5 segments does
>>> not hold if Limited Transmit is in use.
>>
>> We have updated the text (including that now we mention ?up to 5 MSS?),
>> along with updates in the Limited Transmit paragraph.
>>
>>> Also, the requirement of at least 5 segments is valid only if the ACK
>>> for the segment 1 was held by the DelAck timer, i.e., the requirement
>>> holds approx. with 50% probability. That is, if the segment 1 got
>>> acknowledged (because there was also a segment before segment 1 and
>>> that was held by DelAck timer), only a window size of 4 MSS is needed.
>>
>> We have modified the text accordingly.
>
> I have similar comment as Ilpo here. It's worth clarifying the example
> by removing the potential interpretation that segments 1-6 can be in
> flight as a starting point with a cwnd of 5 MSS (assuming they all are
> full-sized segments).

We believe that we corrected the flawed text.

> Note also that in some traffic scenarios where Nagle is disabled and a TCP
> sender does not send MSS-sized segments but smaller segments, it is quite
> possible to levarage FR/FR even with window sizes smaller than 5 MSS
> (actually even with a window size of one MSS 3 dupacks and FR/FR may be
> possible).

Agreed!

>>>
>>>   "For bulk data transfers further TCP improvements may also be useful,
>>>   such as limited transmit [RFC3042].
>>>
>>> Limited Transmit is not useful only for bulk data transfers but for any
>>> transfer that has more than one segment in flight. Small transfers tend
>>> to benefit more, because they are more likely to not receive enough
>>> dupacks.
>>
>> We have modified the paragraph accordingly.
>
> Fine, but it might be useful to start the 2nd para that discusses
> Limited Transmit by noting that the example in the 1st para assumed
> that limited Transmit is not in use.
>
> In addition, actually a cwnd allowing 2 segments in flight would be
> enough to trigger sending segments 1-5. Only difference to cwnd of 3
> segments is that one needs to wait for the DelAck timer to expire for
> segment 1.

Agreed, and done!

>>> Sec. 4.3.1.1.
>>>
>>>   "... a sender (having previously sent the SACK-Permitted
>>>   option) can avoid performing unnecessary retransmissions, saving
>>>   energy and bandwidth, as well as reducing latency."
>>>
>>> It might be worth mentioning also that SACK often allows for faster
>>> loss recovery when there is more than one lost segment in a window of
>>> data (i.e., recovery with less RTTs).
>>
>> Done.
>
> Fine. I'd suggest editing the sentence slightly because it is not
> guaranteed that with SACK recovery takes less RTTs:
>
>   "...since with SACK recovery requires less RTTs."
>
>   -->
>
>   "...since with SACK recovery may complete with less RTTs.

Done.

>>> Sec. 4.3.2.
>>>
>>> Disabling delayed ACKs on a client for infrequent request-response
>>> traffic with small messages might be advisable, too. It would allow
>>> an immediate ACK for the data segment carrying the response.
>>>
>>> This comment holds for Sec. 4.2.3 as well.
>>
>> Added, thanks.
>
> The text here would benefit from more accurate expression of at which end
> the delayed Acks should be turned on and where turned off (e.g.,  "sender"
> does not specify the end point as there is both app. level (data) sender
> as well as TCP sender at each end for request-response type of traffic.
>
> Maybe something like:
>
>   For request-response traffic, enabling Delayed ACKs is recommended,
>   in order to allow combining a response with the ACK into
>   a single segment, thus increasing efficiency.  In this case,
>   disabling Delayed ACKs at the sender allows an immediate
>   ACK for the data segment carrying the response.
>
>   -->
>
>   For request-response traffic, enabling Delayed ACKs is recommended at
>   the server end, in order to allow combining a response with the ACK into
>   a single  segment, thus increasing efficiency.  In addition, if
>   a client issues requests infrequently, disabling Delayed
>   ACKs at the client allows an immediate ACK for the data segment
>   carrying the response.

Done.

Once again, thanks a lot for all your comments and proposed updates!

This is very much appreciated.

Cheers,

Carles


>>> Sec. 5.3.
>>>
>>>   "A mean TCP NAT binding timeout of 386
>>>    minutes has been reported, while in some cases, inactivity timeouts
>>>    are in the order of a few minutes [HomeGateway].
>>>
>>> Reporting just the mean TCP NAT binding timeout from [HomeGateway] does
>>> not give a correct view of the results in this study, because the
>>> meaasured timeouts were highly variable and some devices had a very
>>> long
>>> timeout (or no timeout at all), yielding a very high mean timeout
>>> value.
>>> Therefore, we reported median and it would be more descriptive to
>>> report
>>> it here as well. The median of the measured TCP NAT binding timeouts in
>>> this study was around 60 mins, the shortest being around 2 mins. That
>>> is,
>>> clearly more than 50% of the devices had timeout shorter than RFC
>>> 5382 recommended minimum of 124 mins.
>>>
>>> In the light of these results, it may be hard to find a proper timeout
>>> value for the application-layer heartbeat messages, and it might be
>>> worth mentioning, I think.
>>
>> We have updated the section based on these comments.
>>
>>> Nits:
>>
>> All done, except for the ?Bit-Error Rate? suggestion. The Collins
>> English
>> dictionary uses the non-hyphenated form.
>>
>>> Sec 1:
>>>
>>> 1st para: Add references and cite  6LoWPAN, RPL, and CoAP.
>>>
>>>
>>> 3rd para: "At the application layer, CoAP was developed over UDP
>>> [RFC7252]."
>>>
>>> - this seems to cite UDP incorrectly while the intent is to cite CoAP.
>>>    If you cite CoAP in the first para, you do not need to cite here at
>>> all.
>>>
>>>   "This the main reason..." -> "This is the main reason..."
>>>
>>>
>>> 5th para:
>>>
>>>   "Given the limited resources on constrained devices, careful "tuning"
>>>    of the TCP implementation can make an implementation more
>>> lightweight."
>>>
>>> Instead of saying "tuning" of the TCP implementation, I'd say that
>>> careful
>>> selection of optional TCP features can make an implementation more
>>> lightweight (and improve operation in CNNs).
>>>
>>> 6th para:
>>>
>>>   "This document provides guidance on how to implement and use TCP in
>>>    CNNs.
>>>
>>> ->
>>>
>>>   "This document provides guidance on how to implement and configure
>>> TCP
>>>    as well as how TCP is advisable to be used by applications in CNNs.
>>>
>>>
>>> Sec 3.1., last para:
>>>
>>>   high bit error rate ->  high bit-error rate
>>>
>>>
>>> Sec 5., first sentence:
>>>
>>>   "how a TCP stack can be used" ->  "how TCP can be used"
>>
>> Once again, thank you very much for your comprehensive review and
>> constructive suggestions!
>>
>> Cheers,
>>
>> Carles (on behalf of all authors)
>>
>





From nobody Sun Nov 17 03:08:18 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 B1B121200B1; Sun, 17 Nov 2019 03:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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] 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 RrEHhiMgSZN0; Sun, 17 Nov 2019 03:08:11 -0800 (PST)
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 EC4C7120059; Sun, 17 Nov 2019 03:08:10 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Sun, 17 Nov 2019 13:08:04 +0200
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=WP3x2UsxOFmA1oz48 qD+STh7GiE6cpugrqDiC9EyFY8=; b=XjJVL2CHGd8z07H+X5kT2pJjLSMZFdPj2 3FhpSw388lHMjtwvULflCs2f2gFw0czCrADgJw1zgtt+BRpgLBZRY80PWZHdxO49 AslVVABBWhX9IGQO7IO6SLLa8EppxS9FnrkOzYCnsDJxbbPzX4Kuudni/nIbu4po 1wMKIpED4E=
Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Sun, 17 Nov 2019 13:08:04 +0200 id 00000000005A0040.000000005DD12A14.000063E0
Date: Sun, 17 Nov 2019 13:08:04 +0200 (EET)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" 
X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi
To: Carles Gomez Montenegro 
cc: Mohit Sethi M , "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 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: Sun, 17 Nov 2019 11:08:13 -0000

On Sun, 17 Nov 2019, Carles Gomez Montenegro wrote:

> First of all, apologies for this very late reply.
> 
> Once again, thanks a lot for your thorough review!
> 
> We recently published -09. We believe that this last revision addresses
> your remaining points below.
> 
> Should you have further comments, please do not hesitate to let us know.

Thanks. It looks good now.

I was a bit surprised by the return of the "single-MSS" but then found out 
you had a good reason for that.

-- 
 i.


From nobody Sun Nov 17 06:10: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 08E0012006D for ; Sun, 17 Nov 2019 06:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 veYOqthuFHbV for ; Sun, 17 Nov 2019 06:10:18 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 53D9C1200CD for ; Sun, 17 Nov 2019 06:10:18 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id u13so12200967ote.0 for ; Sun, 17 Nov 2019 06:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DrDGK0EFG+vuVzXrI9VK/I+S/hpL3FF1Y2zzjXX6NvQ=; b=GBSHDFKlhC9u6qmRslVQqNb+wjGy0i0azZ8KxnZ2raWk2GlVLvDSX5/fiIINnPHG1c r+AxaUc8NanHQzTqi2UInxiyWpypAjfDFAaBBg7H0KT9KuOK+p4jT0FX+/jYXOt6nQJe R7KtSyCxu6gCaevkn5dFRpcPGIlOPoyLDFst97bclqEQWGtRR348xAOYOgVJa1LR/0uw 906nLQs+piRshRm/wauvoTiM2ogDapY1glFd97rp/8lQSG/8j8I3w4eoksLJ3AS3Xy0o krqngzGhGo9r0J6cQ/qCOlucnQF0m4nv/rGQ3Wa6dy/mCify5jp+WvaNMWaxZ9SBTg5L 6aJQ==
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; bh=DrDGK0EFG+vuVzXrI9VK/I+S/hpL3FF1Y2zzjXX6NvQ=; b=oovBplcjNtoG4H+fc8ZFa9fQFX1+A9W2i6j2c+A9Ta7L/3ACkCWcNJ/KMLRAIqoLNq TAsH80uknrgyXtt0I0maUw8JEWUxLGNY2d9FwRh0HxiYAo8kf3uspOgZPC+Af7M747KU 2SU/9sO2zFMYx1GF0Weeh6pJtJbSQQm/MiF37TrXjyX7n0uJ5OnP9JTgsT/boxdQrv7d FoZpGPmOsFoYocS9VzgC8QeeTXH/G9CThvTqvcqRgASpzPsyWA8exIcFOYw0FbtXmoHE GGKmwPSBL6p7lwPpvWJ+o6j4ShV0lBOWBOD69XCUbnyAxHGjVphA8sLyW9DKbx6ezArk 26LA==
X-Gm-Message-State: APjAAAVmgDSvoUj8vS2UgQ0iMe6J0gVqlmB8Gm8adFsPIGZXoeBl8GNp 6z/xt/W45veMzNjzoiwRr9K4HPnf/F793Mp3hsJhUBfqJwY=
X-Google-Smtp-Source: APXvYqyXfyP7p83KRyhrll7a1ggz7OWFCZHeOH8104jPpx1nC9JZSoMSyhuyZztEJ85DWzKdPDJElnHqEA8HCjzEPbM=
X-Received: by 2002:a9d:6214:: with SMTP id g20mr18642591otj.302.1573999817181;  Sun, 17 Nov 2019 06:10:17 -0800 (PST)
MIME-Version: 1.0
References: <903982D2-36DE-428D-A7C5-D3C389C95E9A@lurchi.franken.de> 
In-Reply-To: 
From: Neal Cardwell 
Date: Sun, 17 Nov 2019 09:10:00 -0500
Message-ID: 
To: Praveen Balasubramanian 
Cc: Michael Tuexen ,  "tcpm@ietf.org Extensions" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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: Sun, 17 Nov 2019 14:10:20 -0000

On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
 wrote:
>
> RACK is fundamental enough, subsumes TLP, and has enough implementation and deployment. My vote is for PS status.

Personally, I agree with Praveen, that "Proposed Standard" is
appropriate, given my understanding of the definition from
https://tools.ietf.org/html/rfc7127#section-3.1 :

   3.1.  Characterization of IETF Proposed Standard Specifications
   ...
   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

There are several independent and very widely deployed implementations
of RACK at this point.

best regards,
neal


From nobody Sun Nov 17 06:25:06 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 158971200CD; Sun, 17 Nov 2019 06:25:06 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 jeOjNlRpLK88; Sun, 17 Nov 2019 06:25:04 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 F32E612006D; Sun, 17 Nov 2019 06:25:03 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id q70so14633249wme.1; Sun, 17 Nov 2019 06:25:03 -0800 (PST)
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; bh=ZJWerbdLMSvj/kyFbR2kcBFHiDpKe/MzTEk4Mu/+UC0=; b=IzztTqshJb6DSzOF99Jk9c6C69+3/AXOaV/FKTtWkmwUVdR14CQhlgvlZOsPkTOvVe DKAjWBK17cvOCdUiaNrWRfqXgh6hma9sg4aXALgk5u5pswwmRaoj/xcDg37W6bV0YUQU TTBaKq+EqhKZOk3AUFeOzmYinkjqkOLZemQ2wfMviMGahG3n/j8J26VfhkZbRSVlgEwp Jr/DuCdGM06QObTJ+1xh6EPbqoVXN9QtJcqKqMIfLQHCuRdKClA68U1mow64X11W+r4e dwnHWC93UfHajmOM2KmJAWo1XGUJomSLyh4gY9HmXZau03i7BF2BT2oRijqlzljH2nVL EWBg==
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; bh=ZJWerbdLMSvj/kyFbR2kcBFHiDpKe/MzTEk4Mu/+UC0=; b=Eo7B0XO95OyZXsd8mpzVPrW6y4Tzfs/paAlPq3hzuiWUhucI0OVqACszQsnzR6KAoc GTGA+/ZyPYx8f6kHTdpYP5SmDV6KJsXbEeUgYCMO8BpmOXgb84kdCLb5CztLYVNECy9u ebPMN24jQIC4ee6iJNXkrfA7LTj3UYvgzKJrXAxt0tLs5Z4YI8Uo4bKsDB1UrQdGhm3/ fT5F0ICMsufXZ+NI37zJgzADdlSNm4An5lgOWTlSQ2gY//tbaEwWtm4Nf+dBCKCY8sJC zKPknTCMTbTOX8dYU1ViehY2ICxZHiamp6gHQ4gHFTGkcQwMQaAiTExpyc4DtwP8L/JA /b6Q==
X-Gm-Message-State: APjAAAUyC+tvMgv6aOOh8KfYaWjfXVv2rUw/5C8cwy75x2SKrxF+VOBb FV4u1ZQrGTcN5pVK0A1cOgrvPWgZ1gDqzul0aDDidURKDJ4=
X-Google-Smtp-Source: APXvYqw7V152vztj/2+VUUwdSCi+qm+DmCDII/mm71luIXYxRqm4xmC6XDTJVs2X0ZPCTe8OYg4Tn59T8MMLFBTCh6A=
X-Received: by 2002:a05:600c:218c:: with SMTP id e12mr20012259wme.30.1574000702612;  Sun, 17 Nov 2019 06:25:02 -0800 (PST)
MIME-Version: 1.0
References: <201911160705.xAG75A0t056109@gndrsh.dnsmgr.net>
In-Reply-To: <201911160705.xAG75A0t056109@gndrsh.dnsmgr.net>
From: Yoshifumi Nishida 
Date: Sun, 17 Nov 2019 06:24:51 -0800
Message-ID: 
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tcpm@ietf.org Extensions" , tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c1691605978b98bb"
Archived-At: 
Subject: Re: [tcpm] Requesting for discussion of draft-grimes-tcpm-tcpsce
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: Sun, 17 Nov 2019 14:25:06 -0000

--000000000000c1691605978b98bb
Content-Type: text/plain; charset="UTF-8"

Hi Rod,

Thanks for the request.
We've added your presentation in the agenda. (
https://datatracker.ietf.org/meeting/106/materials/agenda-106-tcpm-03.txt)
The presentation order or time might be changed later, though.
Please make sure to send your slide to the chairs before the deadline.
--
Yoshi

On Fri, Nov 15, 2019 at 11:05 PM Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
wrote:

> TCPM Chairs,
>         This is a request to have some presentation and discussion of
> draft-grimes-tcpm-tcpsce at tcpm without a request that TCPM adopt
> at this time.
>
> TCPM,
> For some context we our asking for adoption by the TSVWG of
> draft-morton-tsvwg-sce (
> https://tools.ietf.org/html/draft-morton-tsvwg-sce-01)
> during the IETF/106 Singapore TSVWG session.  draft-grimes-tcpm-tcpsce is a
> tightly associated draft.
>
> Regards,
> --
> Rod Grimes
> rgrimes@freebsd.org
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--000000000000c1691605978b98bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Rod,

Thanks for the reque=
st.

On Fri, Nov 15, 2019 at 11:05 PM Ro=
dney W. Grimes <4bone@gndrsh.=
dnsmgr.net> wrote:
TCPM Chairs,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a request to have some presentation and=
 discussion of

draft-grimes-tcpm-tcpsce at tcpm without a request that TCPM adopt

at this time.



TCPM,

For some context we our asking for adoption by the TSVWG of 

draft-morton-tsvwg-sce (https://tools.ietf.org/=
html/draft-morton-tsvwg-sce-01)

during the IETF/106 Singapore TSVWG session.=C2=A0 draft-grimes-tcpm-tcpsce=
 is a

tightly associated draft. 



Regards,

-- 

Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm




--000000000000c1691605978b98bb--


From nobody Sun Nov 17 07:27: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 0B318120111 for ; Sun, 17 Nov 2019 07:27:20 -0800 (PST)
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=unavailable 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 93TSeGYY5NOX for ; Sun, 17 Nov 2019 07:27:16 -0800 (PST)
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 573ED120112 for ; Sun, 17 Nov 2019 07:27:16 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id DD46525A12; Sun, 17 Nov 2019 16:27:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1574004434; bh=COT5s//MSuh797XJIJ3BGz5MESgB4BwSjP8bhXG0iLY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=C4dFZLpjqVSCSQlqrIrcqMgCzgYrZ/xh0+xqIIDJxLPwygVq7+2HRR0QrBdFsWwkI cEB2ttcBR37vwqsFJHhtkgEKcpjlBRNBJ1rPQpFw8dL/0hC5qzpyoOQQWm+cUREOGi dwExzN6CBX/f34N0s8IAOFOqxpiUKd9Oy6TNSTNU=
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 iIkRS2wTVAmM; Sun, 17 Nov 2019 16:27:13 +0100 (CET)
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; Sun, 17 Nov 2019 16:27:13 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 17 Nov 2019 16:27:13 +0100
From: "Scharf, Michael" 
To: Neal Cardwell , "Praveen Balasubramanian" 
CC: Michael Tuexen , "tcpm@ietf.org Extensions" 
Thread-Topic: [tcpm] Intended status of draft-ietf-tcpm-rack
Thread-Index: AQHVl/tzi6/BEnORi0m/iGBJGQTSaKePBxAAgABZmwCAACZXkQ==
Date: Sun, 17 Nov 2019 15:27:13 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D513A53@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <903982D2-36DE-428D-A7C5-D3C389C95E9A@lurchi.franken.de> , 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D513A53rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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: Sun, 17 Nov 2019 15:27:20 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D513A53rznt8114rzntrzd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1 for PS as individual contributor



BTW, when TCPM adopted the document, support was already very strong, as do=
cumented in https://mailarchive.ietf.org/arch/msg/tcpm/XnQPMWzJyTcP8OZ8n4JP=
GaMgdXM . I think we already discussed PS as potential target back then, bu=
t it was too early to know. Now PS seems more than appropriate.



Michael (with no hat)





Von: Neal Cardwell
Gesendet: Sonntag, 17. November 2019 15:10
An: Praveen Balasubramanian
Cc: Michael Tuexen; tcpm@ietf.org =
Extensions
Betreff: Re: [tcpm] Intended status of draft-ietf-tcpm-rack



On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
 wrote:
>
> RACK is fundamental enough, subsumes TLP, and has enough implementation a=
nd deployment. My vote is for PS status.

Personally, I agree with Praveen, that "Proposed Standard" is
appropriate, given my understanding of the definition from
https://tools.ietf.org/html/rfc7127#section-3.1 :

   3.1.  Characterization of IETF Proposed Standard Specifications
   ...
   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

There are several independent and very widely deployed implementations
of RACK at this point.

best regards,
neal

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

--_000_6EC6417807D9754DA64F3087E2E2E03E2D513A53rznt8114rzntrzd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable














+1 for PS as individual contributor


 


BTW, when TCPM adopted the document, support was a=
lready very strong, as documented in

https://mailarchive.ietf.org/arch/msg/tcpm/XnQPMWzJyTcP8OZ8n4JPGaMgdXM =
. I think we already discussed PS as potential target back then, but it was=
 too early to know. Now PS seems more than appropriate.


 


Michael (with no hat)


 =
;


 




Von: Neal Cardwell
Gesendet: Sonntag, 17. November 2019 15:10

An: Pravee=
n Balasubramanian

Cc: Michael Tuex=
en; 
tcpm@ietf.org Extensions

Betreff: Re: [tcpm] Intended status of draft-ietf-tcpm-rack




 







On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubram=
anian

<pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

>

> RACK is fundamental enough, subsumes TLP, and has enough implementatio=
n and deployment. My vote is for PS status.



Personally, I agree with Praveen, that "Proposed Standard" is

appropriate, given my understanding of the definition from

https://tools.i=
etf.org/html/rfc7127#section-3.1 :



   3.1.  Characterization of IETF Proposed Standard Specific=
ations

   ...

   A Proposed Standard specification is stable, has resolved know=
n

   design choices, has received significant community review, and=


   appears to enjoy enough community interest to be considered va=
luable.



   Usually, neither implementation nor operational experience is<=
br>
   required for the designation of a specification as a Proposed<=
br>
   Standard.  However, such experience is highly desirable a=
nd will

   usually represent a strong argument in favor of a Proposed Sta=
ndard

   designation.



There are several independent and very widely deployed implementations

of RACK at this point.



best regards,

neal



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org=
/mailman/listinfo/tcpm







--_000_6EC6417807D9754DA64F3087E2E2E03E2D513A53rznt8114rzntrzd_--


From nobody Sun Nov 17 07:51:35 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 4C9AD120121 for ; Sun, 17 Nov 2019 07:51:28 -0800 (PST)
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 MwVyajQ6t-p7 for ; Sun, 17 Nov 2019 07:51:26 -0800 (PST)
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 1BF1212006D for ; Sun, 17 Nov 2019 07:51:26 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id BD8FC25A12 for ; Sun, 17 Nov 2019 16:51:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1574005884; bh=rAPkyMEHbZ14e4E0hz+fPnOi69uVVLNvow8ylrvJnb4=; h=From:To:Subject:Date:From; b=Wdty/Z3WMoijKOnvcCma3nRVjdwU/9vAWY6m1L8jTyARG3hv//Su3Qv0VA9GWxcTA sfJ4MdJ63o4reLOFDQLCEk9CFHEIGqGYKXdaZVJp/WsK3wCTHs32pn7GleakIGJ+H5 YUEQtnkZHtWK0FWOeIQBunumIUDQMaB9thuQT6kY=
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 cMvj-OMGMlVg for ; Sun, 17 Nov 2019 16:51:24 +0100 (CET)
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 for ; Sun, 17 Nov 2019 16:51:24 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 17 Nov 2019 16:51:23 +0100
From: "Scharf, Michael" 
To: tcpm IETF list 
Thread-Topic: *Draft* shepherd writeup for draft-ietf-tcpm-converters
Thread-Index: AdWdXl4bgAyTkNdaThGAZFtgPglAfQ==
Date: Sun, 17 Nov 2019 15:51:23 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D513C75@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.48.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] *Draft* shepherd writeup for draft-ietf-tcpm-converters
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: Sun, 17 Nov 2019 15:51:28 -0000

Here is a link to my current version of the shepherd writeup for the conver=
ter document: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/s=
hepherdwriteup/

draft-ietf-tcpm-converters-14 was submitted recently to fix some small idni=
t issues that I found in -13 when preparing that write-up.

I'd like to ship this document to the IESG tomorrow. If I have missed some =
important point in my write-up, please let me know ASAP.

Thanks

Michael


From nobody Sun Nov 17 11:27:55 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 C64F6120128 for ; Sun, 17 Nov 2019 11:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 xGl4eCyhlCuW for ; Sun, 17 Nov 2019 11:27:52 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFF612001E for ; Sun, 17 Nov 2019 11:27:52 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAHJRo0I062724; Sun, 17 Nov 2019 11:27:50 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAHJRnlW062723; Sun, 17 Nov 2019 11:27:49 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911171927.xAHJRnlW062723@gndrsh.dnsmgr.net>
In-Reply-To: 
To: Neal Cardwell 
Date: Sun, 17 Nov 2019 11:27:49 -0800 (PST)
CC: Praveen Balasubramanian , Michael Tuexen , "tcpm@ietf.org Extensions" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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: Sun, 17 Nov 2019 19:27:54 -0000

I am finding myself in agreement with others, PS is the correct status.

Thank you Neal for the good siting of RFC7127 with respect to PS,

Regards,
Rod

> On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
>  wrote:
> >
> > RACK is fundamental enough, subsumes TLP, and has enough implementation and deployment. My vote is for PS status.
> 
> Personally, I agree with Praveen, that "Proposed Standard" is
> appropriate, given my understanding of the definition from
> https://tools.ietf.org/html/rfc7127#section-3.1 :
> 
>    3.1.  Characterization of IETF Proposed Standard Specifications
>    ...
>    A Proposed Standard specification is stable, has resolved known
>    design choices, has received significant community review, and
>    appears to enjoy enough community interest to be considered valuable.
> 
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.
> 
> There are several independent and very widely deployed implementations
> of RACK at this point.
> 
> best regards,
> neal
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Sun Nov 17 16:35:16 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 6767512002F; Sun, 17 Nov 2019 16:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.888
X-Spam-Level: 
X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_RP_RNBL=1.31, 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 Ie8RHEpPTk5Z; Sun, 17 Nov 2019 16:35:09 -0800 (PST)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 93BB912020A; Sun, 17 Nov 2019 16:35:08 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id xAI0Z0Us023384; Mon, 18 Nov 2019 01:35:00 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4E9871D53C1; Mon, 18 Nov 2019 01:34:59 +0100 (CET)
Received: from 111.65.62.226 by webmail.entel.upc.edu with HTTP; Mon, 18 Nov 2019 01:35:00 +0100
Message-ID: <3a32ee556f12c07387e3ed35a18390e5.squirrel@webmail.entel.upc.edu>
In-Reply-To: 
References:    <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu>    
Date: Mon, 18 Nov 2019 01:35:00 +0100
From: "Carles Gomez Montenegro" 
To: =?iso-8859-1?Q?=22Ilpo_J=E4rvinen=22?= 
Cc: "Mohit Sethi M" , "lwip@ietf.org" , "tcpm@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "kojo@cs.helsinki.fi" 
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 15:02:10 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 18 Nov 2019 01:35:01 +0100 (CET)
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: Mon, 18 Nov 2019 00:35:10 -0000

> On Sun, 17 Nov 2019, Carles Gomez Montenegro wrote:
>
>> First of all, apologies for this very late reply.
>>
>> Once again, thanks a lot for your thorough review!
>>
>> We recently published -09. We believe that this last revision addresses
>> your remaining points below.
>>
>> Should you have further comments, please do not hesitate to let us know.
>
> Thanks. It looks good now.
>
> I was a bit surprised by the return of the "single-MSS" but then found out
> you had a good reason for that.

Indeed! :)

Thanks,

Carles


From nobody Sun Nov 17 18:51: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 0E0DC12081A; Sun, 17 Nov 2019 18:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 7nmCdy8lNvJ0; Sun, 17 Nov 2019 18:51:46 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A55A8120013; Sun, 17 Nov 2019 18:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1wSaAKGIxrUHhXW76bRjqAvrsVdydGgRslKpOQR8Flc=; b=0Uylb0b/GY664ZznnY4UJvRJJp dfhL4HxVHN3uKMvaeC4n0KAV/wYxosfbQTQ5Jl1Wv1DJcwHyvXm4b9h2x+8UDtkX6UiwOvLbTpKTz Gq4eNl7wKx35GH2S9ewrKf9jit1S4w63uTHJAFUQ1ygVskoEx20y8Wo1KjKvQI3+swsZsVnesXy8z OmtiyJXwM76m3ytcjhanToIliuzIXE0uIMfcD4a6LMrqi95Amwvlf9qZ/IcrXfY63TzFWH9j5RMFP gEka6Vh22R1DqKIIzZht96QVlw7CUw1vgEfMAsZwEvaaigAQjf97qdFbPmSXdyGKRRkTfhhx4NHN5 przLP6rQ==;
Received: from dhcp-819f.meeting.ietf.org ([31.133.129.159]:37402) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iWX8j-0004vP-1B; Mon, 18 Nov 2019 02:51:45 +0000
To: tsvwg IETF list , iccrg IRTF list , tcpm IETF list 
From: Bob Briscoe 
Message-ID: <22773cc0-f28a-0cd2-8265-a559f427ff8d@bobbriscoe.net>
Date: Mon, 18 Nov 2019 10:51:42 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] TCP Prague Update: L4S-related Side Meeting at IETF-106
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, 18 Nov 2019 02:51:49 -0000

Folks,

The significant amount of TCP Prague update material was too great for 
the iccrg agenda.
So, with the help of the iccrg and tsvwg chairs (thank you), we've 
arranged a side meeting to cover all this.

==Where/when?==
Date: Thu 21 Nov 2019
Time: 08:30 - 09:30
Room: Canning

==Agenda==
http://bobbriscoe.net/projects/latency/TCP_Prague_side-meetingAgendaIETF-106.html

==Meeting Materials==
Links to meeting materials will be added to the above agenda soon.
They will also be added to the tsvwg meeting materials.

==Remote Attendance==
Meetecho is not available for side-meetings, so we're arranging an 
alternative, prob Zoom (link will appear on agenda)

Regards


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Sun Nov 17 19:46:47 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 338EC120818 for ; Sun, 17 Nov 2019 19:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.888
X-Spam-Level: 
X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_RP_RNBL=1.31, 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 LA8kBmkek0CS for ; Sun, 17 Nov 2019 19:46:35 -0800 (PST)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 B12C21208BB for ; Sun, 17 Nov 2019 19:46:34 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id xAI3jlK4020639; Mon, 18 Nov 2019 04:45:47 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 1D52A1D53C1; Mon, 18 Nov 2019 04:45:46 +0100 (CET)
Received: from 111.65.62.226 by webmail.entel.upc.edu with HTTP; Mon, 18 Nov 2019 04:45:47 +0100
Message-ID: <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu>
In-Reply-To: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net>
References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net>
Date: Mon, 18 Nov 2019 04:45:47 +0100
From: "Carles Gomez Montenegro" 
To: "Bob Briscoe" 
Cc: "CROWCROFT, Jon" , "tcpm IETF list" 
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 18 Nov 2019 04:45:48 +0100 (CET)
Archived-At: 
Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull
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, 18 Nov 2019 03:46:38 -0000

Hi Bob,

Once again, thanks a lot for all the very useful feedback!

Please find below some inline responses.

> Carles, Jon, (re-sending, this time without accidentally omitting tcpm,
> also see couple of addenda tagged [Bob adds:])
>
> I'm generally supportive of a mechanism to suppress delayed ACKs from
> the receiver (in any transport protocol including TCP). So thank you.
>
> You might want to borrow at least some of the text for additional
> motivating scenarios for such a facility from the first two posts on a
> thread for a similar facility in QuiC:
> https://github.com/quicwg/base-drafts/issues/1978
>
> Also pasted at the end.
>
> Some is not relevant to your specific ack-pull scheme, 'cos it's
> proposing a more general facility in QUIC for the sender to the receiver
> alters its ACK ratio. (theoretically there are more bits available in
> QUIC, but this particular request has been put on hold while someone
> goes and finds them ;)

Thanks a lot. This is indeed very useful!

As you explain, the more general facility for QUIC allows to suppress
Delayed ACKs and also allows to modify the ACK ratio in a more general
way.

Regarding the Delayed ACK suppression discussion, the additional
motivation is definitely important.

>       Another motivating example (rather niche)
>
> Coincidentally, Just this morning I published a tech report that had to
> use the hack of overlapping a byte from the previous segment to force a
> quick ack:
> TCP Prague Fall-back on Detection of a Classic ECN AQM
>  (the link takes you to Fig
> 2, which illustrates the hack)
> I'd rather not have to do these sorts of hacks - it really messes with
> the segmentation code.

This is very useful feedback as well, and a nice coincidence!

Regarding the hack, sending an old byte may be even worse when there is
not a next data segment readily available for sending, which would lead to
sending a whole packet just to carry an old byte.

>       Middlebox traversal of bit 6
>
> I recall that someone did a study of traversal of each of the reserved
> flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bob
> adds: I mean traversal - not the study!].
> A good search engine might find it ;)

I wasn't able to find the study, but this is an important consideration.

One might think that if new functionality is defined and standardized,
related middlebox traversal of it should improve over time. Perhaps that
might be optimistic...

>       More alternative approaches:
>
> 1/ At one stage, we tried to include a bit for Delayed Ack control in
> another protocol called Accurate ECN. We were persuaded to take it out,
> because it was mission creep (outside the scope of the protocol we were
> working on):
> https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4

I was unaware of this, thanks!

This is actually very aligned with what we are proposing...

> 2/ Have you considered using the Urgent Pointer in a novel way? I.e. a
> non-zero Urgent Pointer field, even tho the URG flag is zero.
> [Bob adds:] From memory, traversal was pretty good - much better than
> bits 4-6. But I think Windows treated it as a potential attack. I
> believe Fernando Gont did a study on how 'invalid' TCP header fields are
> handled.
>
> You could assign, say, 3 bits of the urgent pointer for a variable
> ack_exp that is log base 2 of the ack ratio the sender would like. Then
> the sender can request the receiver uses ack_ratio` = 2^ack_exp, as in
> the QUIC proposal below,
> With ack_exp = 0, you get ack_ratio = 2^0 = 1, which has the same effect
> as ack-pull. But you also have a more general facility for high speed
> machines to widen out the ack ratio.
>
> If this works, you could open up a registry for the other 13 bits. So
> instead of using up a precious bit, you generate 13 more ;)

Nice! :)

Actually, we had not considered such an idea.

In your proposal above, if a segment has the URG flag set to 1, would then
the 3 ack_exp bits still be used as ack_exp bits, thus reducing the size
of the urgent pointer in practice to 13 bits?

> See:
> https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=5
>
> I think there were problems with some implementations and middleboxes
> (bound to be). I've checked the minutes of the IETF meeting where that
> slide was presented
> , but
> there's no push-back in there. I suggest you delve back into the
> archives of the tcpm mailing list around the time of that meeting to
> find out if there were any show-stoppers.

Thanks for the pointers!

Sure, we'll check the tcpm mailing list archive.

Cheers,

Carles


> Cheers
>
>
>
> Bob
>
>
> Paste from QUIC thread:
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
>
>
>       Problem/goals:
>
>  1. Getting up to speed fast without inducing much queue is one of the
>     main areas where latency reductions are needed (for short and long
>     flows). The sender needs frequent ACKing during this phase in many
>     approaches (hystart, etc). A Linux TCP receiver starts with
>     ack_ratio 1 and uses heuristics to identify the end of the sender's
>     slow-start (or a re-start after idle). This has ossified a certain
>     slow-start behaviour into all TCP senders (whether Linux or not). We
>     are trying to new sender behaviours (paced chirping being an
>     example), but we need a way for the sender to suppress delayed ACKs.
>  2. At the other end of the scale, for long-running flows, many current
>     CC approaches (e.g. BBR) use pacing not ACK-clocking so they can use
>     very few ACKs per RTT. And fewer means less cache ejections for GRO.
>     But the receiver doesn't know what CC the sender is using, so it
>     doesn't know how many or few is too many or too few.
>  3. Some middleboxes and the majority of link technologies (e.g. DOCSIS,
>     LTE, Satellite) thin TCP ACKs when they detect the upstream is
>     filled with TCP ACK stream(s), which are unresponsive. Otherwise the
>     ACKs constrain downstream throughput (and any upstream data either
>     in the flow itself, or in others). We don't want these links to
>     attempt to guess which are the QUIC ACKs and try to thin them. QUIC
>     can and should do this itself. QUIC has all the machinery for the
>     sender CC to detect ACK congestion, but not the protocol to tell the
>     receiver to do the thinning. This protocol addition would provide a
>     sufficient hook for hosts to unilaterally add this to their CC
>     behaviour.
>
>
>       Some scenarios where the sender's preferred ack_ratio changes
>       through the connection:
>
>  1.
>
>     A sender CC that wants the receiver to turn off DelAcks during
>     flow-start (e.g. it's using hybrid slow-start as in Cubic and wants
>     to get delay measurements more frequently) sets ack_exp=0 during
>     flow-start (ack_ratio=1), then increases ack_exp during congestion
>     avoidance. If it goes idle, then re-starts, it would set ack_exp=0
>     again.
>
>     Note on heuristics: A Linux TCP receiver currently uses a heuristic
>     to determine when the sender has exited slow-start. However,
>     heuristics -> ossification. A Linux receiver's heuristic only works
>     with the current pattern of slow-start. In TCP, when we tried to
>     improve the pattern on the sender (paced chirping), the heuristic on
>     the receiver killed us.
>
>  2.
>
>     Imagine a paced sender has hardware generic receive offload (GRO),
>     so for a long-running flow it doesn't want a high rate of QUIC ACKs
>     that are opaque to GRO. Let's say it would prefer at least 8 ACKs
>     per RTT. Again, it starts with ack_exp=0, but in congestion
>     avoidance it would use:
>
>     ack_ratio <= cwnd_in_packets/8
>
> Upshot: By remote controlling the receiver, the server offloads nearly
> all the ACKs from large downloads, but still focuses its ACK-receiving
> resources on getting each client up to speed.
>
> Note that calculation of ack_ratio lends itself to fast integer
> arithmetic.
>
>
>
>
>
>
>
> Bob
>
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>



From nobody Sun Nov 17 23:21: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 2ACBD1208D6 for ; Sun, 17 Nov 2019 23:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level: 
X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 KE1pRKYruxHn for ; Sun, 17 Nov 2019 23:21:16 -0800 (PST)
Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (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 C42FB1208BB for ; Sun, 17 Nov 2019 23:21:15 -0800 (PST)
Received: by mail-wm1-f65.google.com with SMTP id j18so15186723wmk.1 for ; Sun, 17 Nov 2019 23:21:15 -0800 (PST)
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; bh=oVsWvRLrNz7qmmiDtPSmF+UqXiNtyVR7OT2o3lU6xEU=; b=AhtmAIDzRlCi9kXg4lbCim8kcV86FXaYb9kmGbWXKENUwip0L8GWrZr7uR9OZuVltE 6s5Hdw+qEYOQ/i+tuI+absCs77JnyU8LToJe4U+prSTHOD7NHIheza8FCsBskjxrZiuJ FtAcmlHTaMCwLwedLeFof2PeVhAgJcN/QscwGoPhQ2Wt8QgNoU3Nzun+XwjImE1UWNzl XnH5Zi+m+TgppoBT5e2sQz8FaIHupE5J3XC7GLy5dmCFC6jjcxJv5u4T1yGK5ihMiDK9 JCOeMKLCAttq60/GfKlyvj8g5oOHZ3vV9ymERfNzs/NowPwGtW4xyHvXRD3KqeswC5nl Fepg==
X-Gm-Message-State: APjAAAWZ0ieln5aRkgjsiOywVfuNXbsPWtedS5PcpI5/SFDRDg7KIhvm TiLn/Bd1H5Vtl8s3Oiuff+9ad+kzu/P61+tOVsI=
X-Google-Smtp-Source: APXvYqy5qPF1vUfCivyxiayCmwGdpGfxJ1qrMxL+yXz8/9peIvCxyrw8h5jbMuwcukhe1g/Pa7UlmRXe0y1gLMMSON8=
X-Received: by 2002:a7b:c747:: with SMTP id w7mr28973037wmk.62.1574061674122;  Sun, 17 Nov 2019 23:21:14 -0800 (PST)
MIME-Version: 1.0
References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu>
In-Reply-To: <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu>
From: Jon Crowcroft 
Date: Mon, 18 Nov 2019 08:21:02 +0100
Message-ID: 
To: Carles Gomez Montenegro 
Cc: ietf@bobbriscoe.net, tcpm IETF list 
Content-Type: multipart/alternative; boundary="000000000000f0d5e7059799caaf"
Archived-At: 
Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull
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, 18 Nov 2019 07:21:18 -0000

--000000000000f0d5e7059799caaf
Content-Type: text/plain; charset="UTF-8"

Mark Handley said a lot of the middlebox corner case avoidance stuff is in
the tcpmp RFC...have got time to look just yet...

On Mon, 18 Nov 2019, 04:46 Carles Gomez Montenegro, 
wrote:

> Hi Bob,
>
> Once again, thanks a lot for all the very useful feedback!
>
> Please find below some inline responses.
>
> > Carles, Jon, (re-sending, this time without accidentally omitting tcpm,
> > also see couple of addenda tagged [Bob adds:])
> >
> > I'm generally supportive of a mechanism to suppress delayed ACKs from
> > the receiver (in any transport protocol including TCP). So thank you.
> >
> > You might want to borrow at least some of the text for additional
> > motivating scenarios for such a facility from the first two posts on a
> > thread for a similar facility in QuiC:
> > https://github.com/quicwg/base-drafts/issues/1978
> >
> > Also pasted at the end.
> >
> > Some is not relevant to your specific ack-pull scheme, 'cos it's
> > proposing a more general facility in QUIC for the sender to the receiver
> > alters its ACK ratio. (theoretically there are more bits available in
> > QUIC, but this particular request has been put on hold while someone
> > goes and finds them ;)
>
> Thanks a lot. This is indeed very useful!
>
> As you explain, the more general facility for QUIC allows to suppress
> Delayed ACKs and also allows to modify the ACK ratio in a more general
> way.
>
> Regarding the Delayed ACK suppression discussion, the additional
> motivation is definitely important.
>
> >       Another motivating example (rather niche)
> >
> > Coincidentally, Just this morning I published a tech report that had to
> > use the hack of overlapping a byte from the previous segment to force a
> > quick ack:
> > TCP Prague Fall-back on Detection of a Classic ECN AQM
> >  (the link takes you to Fig
> > 2, which illustrates the hack)
> > I'd rather not have to do these sorts of hacks - it really messes with
> > the segmentation code.
>
> This is very useful feedback as well, and a nice coincidence!
>
> Regarding the hack, sending an old byte may be even worse when there is
> not a next data segment readily available for sending, which would lead to
> sending a whole packet just to carry an old byte.
>
> >       Middlebox traversal of bit 6
> >
> > I recall that someone did a study of traversal of each of the reserved
> > flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bob
> > adds: I mean traversal - not the study!].
> > A good search engine might find it ;)
>
> I wasn't able to find the study, but this is an important consideration.
>
> One might think that if new functionality is defined and standardized,
> related middlebox traversal of it should improve over time. Perhaps that
> might be optimistic...
>
> >       More alternative approaches:
> >
> > 1/ At one stage, we tried to include a bit for Delayed Ack control in
> > another protocol called Accurate ECN. We were persuaded to take it out,
> > because it was mission creep (outside the scope of the protocol we were
> > working on):
> >
> https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4
>
> I was unaware of this, thanks!
>
> This is actually very aligned with what we are proposing...
>
> > 2/ Have you considered using the Urgent Pointer in a novel way? I.e. a
> > non-zero Urgent Pointer field, even tho the URG flag is zero.
> > [Bob adds:] From memory, traversal was pretty good - much better than
> > bits 4-6. But I think Windows treated it as a potential attack. I
> > believe Fernando Gont did a study on how 'invalid' TCP header fields are
> > handled.
> >
> > You could assign, say, 3 bits of the urgent pointer for a variable
> > ack_exp that is log base 2 of the ack ratio the sender would like. Then
> > the sender can request the receiver uses ack_ratio` = 2^ack_exp, as in
> > the QUIC proposal below,
> > With ack_exp = 0, you get ack_ratio = 2^0 = 1, which has the same effect
> > as ack-pull. But you also have a more general facility for high speed
> > machines to widen out the ack ratio.
> >
> > If this works, you could open up a registry for the other 13 bits. So
> > instead of using up a precious bit, you generate 13 more ;)
>
> Nice! :)
>
> Actually, we had not considered such an idea.
>
> In your proposal above, if a segment has the URG flag set to 1, would then
> the 3 ack_exp bits still be used as ack_exp bits, thus reducing the size
> of the urgent pointer in practice to 13 bits?
>
> > See:
> > https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=5
> >
> > I think there were problems with some implementations and middleboxes
> > (bound to be). I've checked the minutes of the IETF meeting where that
> > slide was presented
> > , but
> > there's no push-back in there. I suggest you delve back into the
> > archives of the tcpm mailing list around the time of that meeting to
> > find out if there were any show-stoppers.
>
> Thanks for the pointers!
>
> Sure, we'll check the tcpm mailing list archive.
>
> Cheers,
>
> Carles
>
>
> > Cheers
> >
> >
> >
> > Bob
> >
> >
> > Paste from QUIC thread:
> >
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> >
> >
> >
> >       Problem/goals:
> >
> >  1. Getting up to speed fast without inducing much queue is one of the
> >     main areas where latency reductions are needed (for short and long
> >     flows). The sender needs frequent ACKing during this phase in many
> >     approaches (hystart, etc). A Linux TCP receiver starts with
> >     ack_ratio 1 and uses heuristics to identify the end of the sender's
> >     slow-start (or a re-start after idle). This has ossified a certain
> >     slow-start behaviour into all TCP senders (whether Linux or not). We
> >     are trying to new sender behaviours (paced chirping being an
> >     example), but we need a way for the sender to suppress delayed ACKs.
> >  2. At the other end of the scale, for long-running flows, many current
> >     CC approaches (e.g. BBR) use pacing not ACK-clocking so they can use
> >     very few ACKs per RTT. And fewer means less cache ejections for GRO.
> >     But the receiver doesn't know what CC the sender is using, so it
> >     doesn't know how many or few is too many or too few.
> >  3. Some middleboxes and the majority of link technologies (e.g. DOCSIS,
> >     LTE, Satellite) thin TCP ACKs when they detect the upstream is
> >     filled with TCP ACK stream(s), which are unresponsive. Otherwise the
> >     ACKs constrain downstream throughput (and any upstream data either
> >     in the flow itself, or in others). We don't want these links to
> >     attempt to guess which are the QUIC ACKs and try to thin them. QUIC
> >     can and should do this itself. QUIC has all the machinery for the
> >     sender CC to detect ACK congestion, but not the protocol to tell the
> >     receiver to do the thinning. This protocol addition would provide a
> >     sufficient hook for hosts to unilaterally add this to their CC
> >     behaviour.
> >
> >
> >       Some scenarios where the sender's preferred ack_ratio changes
> >       through the connection:
> >
> >  1.
> >
> >     A sender CC that wants the receiver to turn off DelAcks during
> >     flow-start (e.g. it's using hybrid slow-start as in Cubic and wants
> >     to get delay measurements more frequently) sets ack_exp=0 during
> >     flow-start (ack_ratio=1), then increases ack_exp during congestion
> >     avoidance. If it goes idle, then re-starts, it would set ack_exp=0
> >     again.
> >
> >     Note on heuristics: A Linux TCP receiver currently uses a heuristic
> >     to determine when the sender has exited slow-start. However,
> >     heuristics -> ossification. A Linux receiver's heuristic only works
> >     with the current pattern of slow-start. In TCP, when we tried to
> >     improve the pattern on the sender (paced chirping), the heuristic on
> >     the receiver killed us.
> >
> >  2.
> >
> >     Imagine a paced sender has hardware generic receive offload (GRO),
> >     so for a long-running flow it doesn't want a high rate of QUIC ACKs
> >     that are opaque to GRO. Let's say it would prefer at least 8 ACKs
> >     per RTT. Again, it starts with ack_exp=0, but in congestion
> >     avoidance it would use:
> >
> >     ack_ratio <= cwnd_in_packets/8
> >
> > Upshot: By remote controlling the receiver, the server offloads nearly
> > all the ACKs from large downloads, but still focuses its ACK-receiving
> > resources on getting each client up to speed.
> >
> > Note that calculation of ack_ratio lends itself to fast integer
> > arithmetic.
> >
> >
> >
> >
> >
> >
> >
> > Bob
> >
> >
> > --
> > ________________________________________________________________
> > Bob Briscoehttp://bobbriscoe.net/
> >
> >
>
>
>

--000000000000f0d5e7059799caaf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Mark Handley said a lot of the middlebox corner case avoi=
dance stuff is in the tcpmp RFC...have got time to look just yet...
On Mon, =
18 Nov 2019, 04:46 Carles Gomez Montenegro, <carlesgo@entel.upc.edu> wrote:
Hi Bob,



Once again, thanks a lot for all the very useful feedback!



Please find below some inline responses.



> Carles, Jon, (re-sending, this time without accidentally omitting tcpm=
,

> also see couple of addenda tagged [Bob adds:])

>

> I'm generally supportive of a mechanism to suppress delayed ACKs f=
rom

> the receiver (in any transport protocol including TCP). So thank you.<=
br>
>

> You might want to borrow at least some of the text for additional

> motivating scenarios for such a facility from the first two posts on a=


> thread for a similar facility in QuiC:

> https://github.com/quicwg/base-draf=
ts/issues/1978

>

> Also pasted at the end.

>

> Some is not relevant to your specific ack-pull scheme, 'cos it'=
;s

> proposing a more general facility in QUIC for the sender to the receiv=
er

> alters its ACK ratio. (theoretically there are more bits available in<=
br>
> QUIC, but this particular request has been put on hold while someone
> goes and finds them ;)



Thanks a lot. This is indeed very useful!



As you explain, the more general facility for QUIC allows to suppress

Delayed ACKs and also allows to modify the ACK ratio in a more general

way.



Regarding the Delayed ACK suppression discussion, the additional

motivation is definitely important.



>=C2=A0 =C2=A0 =C2=A0 =C2=A0Another motivating example (rather niche)
>

> Coincidentally, Just this morning I published a tech report that had t=
o

> use the hack of overlapping a byte from the previous segment to force =
a

> quick ack:

> TCP Prague Fall-back on Detection of a Classic ECN AQM

> <https://arxiv.org/pdf/1911.00710.pdf#p=
age9> (the link takes you to Fig

> 2, which illustrates the hack)

> I'd rather not have to do these sorts of hacks - it really messes =
with

> the segmentation code.



This is very useful feedback as well, and a nice coincidence!



Regarding the hack, sending an old byte may be even worse when there is

not a next data segment readily available for sending, which would lead to<=
br>
sending a whole packet just to carry an old byte.



>=C2=A0 =C2=A0 =C2=A0 =C2=A0Middlebox traversal of bit 6

>

> I recall that someone did a study of traversal of each of the reserved=


> flags (Marcelo Bagnulo maybe?). I don't think it was that good [Bo=
b

> adds: I mean traversal - not the study!].

> A good search engine might find it ;)



I wasn't able to find the study, but this is an important consideration=
.



One might think that if new functionality is defined and standardized,

related middlebox traversal of it should improve over time. Perhaps that
might be optimistic...



>=C2=A0 =C2=A0 =C2=A0 =C2=A0More alternative approaches:

>

> 1/ At one stage, we tried to include a bit for Delayed Ack control in<=
br>
> another protocol called Accurate ECN. We were persuaded to take it out=
,

> because it was mission creep (outside the scope of the protocol we wer=
e

> working on):

> https:=
//tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4



I was unaware of this, thanks!



This is actually very aligned with what we are proposing...



> 2/ Have you considered using the Urgent Pointer in a novel way? I.e. a=


> non-zero Urgent Pointer field, even tho the URG flag is zero.

> [Bob adds:] From memory, traversal was pretty good - much better than<=
br>
> bits 4-6. But I think Windows treated it as a potential attack. I

> believe Fernando Gont did a study on how 'invalid' TCP header =
fields are

> handled.

>

> You could assign, say, 3 bits of the urgent pointer for a variable

> ack_exp that is log base 2 of the ack ratio the sender would like. The=
n

> the sender can request the receiver uses ack_ratio` =3D 2^ack_exp, as =
in

> the QUIC proposal below,

> With ack_exp =3D 0, you get ack_ratio =3D 2^0 =3D 1, which has the sam=
e effect

> as ack-pull. But you also have a more general facility for high speed<=
br>
> machines to widen out the ack ratio.

>

> If this works, you could open up a registry for the other 13 bits. So<=
br>
> instead of using up a precious bit, you generate 13 more ;)



Nice! :)



Actually, we had not considered such an idea.



In your proposal above, if a segment has the URG flag set to 1, would then<=
br>
the 3 ack_exp bits still be used as ack_exp bits, thus reducing the size
of the urgent pointer in practice to 13 bits?



> See:

> https://tools.=
ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=3D5

>

> I think there were problems with some implementations and middleboxes<=
br>
> (bound to be). I've checked the minutes of the IETF meeting where =
that

> slide was presented

> <https://www.ietf.org/=
proceedings/90/minutes/minutes-90-tcpm>, but

> there's no push-back in there. I suggest you delve back into the
> archives of the tcpm mailing list around the time of that meeting to
> find out if there were any show-stoppers.



Thanks for the pointers!



Sure, we'll check the tcpm mailing list archive.



Cheers,



Carles





> Cheers

>

>

>

> Bob

>

>

> Paste from QUIC thread:

> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\=
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Problem/goals:

>

>=C2=A0 1. Getting up to speed fast without inducing much queue is one o=
f the

>=C2=A0 =C2=A0 =C2=A0main areas where latency reductions are needed (for=
 short and long

>=C2=A0 =C2=A0 =C2=A0flows). The sender needs frequent ACKing during thi=
s phase in many

>=C2=A0 =C2=A0 =C2=A0approaches (hystart, etc). A Linux TCP receiver sta=
rts with

>=C2=A0 =C2=A0 =C2=A0ack_ratio 1 and uses heuristics to identify the end=
 of the sender's

>=C2=A0 =C2=A0 =C2=A0slow-start (or a re-start after idle). This has oss=
ified a certain

>=C2=A0 =C2=A0 =C2=A0slow-start behaviour into all TCP senders (whether =
Linux or not). We

>=C2=A0 =C2=A0 =C2=A0are trying to new sender behaviours (paced chirping=
 being an

>=C2=A0 =C2=A0 =C2=A0example), but we need a way for the sender to suppr=
ess delayed ACKs.

>=C2=A0 2. At the other end of the scale, for long-running flows, many c=
urrent

>=C2=A0 =C2=A0 =C2=A0CC approaches (e.g. BBR) use pacing not ACK-clockin=
g so they can use

>=C2=A0 =C2=A0 =C2=A0very few ACKs per RTT. And fewer means less cache e=
jections for GRO.

>=C2=A0 =C2=A0 =C2=A0But the receiver doesn't know what CC the sende=
r is using, so it

>=C2=A0 =C2=A0 =C2=A0doesn't know how many or few is too many or too=
 few.

>=C2=A0 3. Some middleboxes and the majority of link technologies (e.g. =
DOCSIS,

>=C2=A0 =C2=A0 =C2=A0LTE, Satellite) thin TCP ACKs when they detect the =
upstream is

>=C2=A0 =C2=A0 =C2=A0filled with TCP ACK stream(s), which are unresponsi=
ve. Otherwise the

>=C2=A0 =C2=A0 =C2=A0ACKs constrain downstream throughput (and any upstr=
eam data either

>=C2=A0 =C2=A0 =C2=A0in the flow itself, or in others). We don't wan=
t these links to

>=C2=A0 =C2=A0 =C2=A0attempt to guess which are the QUIC ACKs and try to=
 thin them. QUIC

>=C2=A0 =C2=A0 =C2=A0can and should do this itself. QUIC has all the mac=
hinery for the

>=C2=A0 =C2=A0 =C2=A0sender CC to detect ACK congestion, but not the pro=
tocol to tell the

>=C2=A0 =C2=A0 =C2=A0receiver to do the thinning. This protocol addition=
 would provide a

>=C2=A0 =C2=A0 =C2=A0sufficient hook for hosts to unilaterally add this =
to their CC

>=C2=A0 =C2=A0 =C2=A0behaviour.

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Some scenarios where the sender's prefer=
red ack_ratio changes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0through the connection:

>

>=C2=A0 1.

>

>=C2=A0 =C2=A0 =C2=A0A sender CC that wants the receiver to turn off Del=
Acks during

>=C2=A0 =C2=A0 =C2=A0flow-start (e.g. it's using hybrid slow-start a=
s in Cubic and wants

>=C2=A0 =C2=A0 =C2=A0to get delay measurements more frequently) sets ack=
_exp=3D0 during

>=C2=A0 =C2=A0 =C2=A0flow-start (ack_ratio=3D1), then increases ack_exp =
during congestion

>=C2=A0 =C2=A0 =C2=A0avoidance. If it goes idle, then re-starts, it woul=
d set ack_exp=3D0

>=C2=A0 =C2=A0 =C2=A0again.

>

>=C2=A0 =C2=A0 =C2=A0Note on heuristics: A Linux TCP receiver currently =
uses a heuristic

>=C2=A0 =C2=A0 =C2=A0to determine when the sender has exited slow-start.=
 However,

>=C2=A0 =C2=A0 =C2=A0heuristics -> ossification. A Linux receiver'=
;s heuristic only works

>=C2=A0 =C2=A0 =C2=A0with the current pattern of slow-start. In TCP, whe=
n we tried to

>=C2=A0 =C2=A0 =C2=A0improve the pattern on the sender (paced chirping),=
 the heuristic on

>=C2=A0 =C2=A0 =C2=A0the receiver killed us.

>

>=C2=A0 2.

>

>=C2=A0 =C2=A0 =C2=A0Imagine a paced sender has hardware generic receive=
 offload (GRO),

>=C2=A0 =C2=A0 =C2=A0so for a long-running flow it doesn't want a hi=
gh rate of QUIC ACKs

>=C2=A0 =C2=A0 =C2=A0that are opaque to GRO. Let's say it would pref=
er at least 8 ACKs

>=C2=A0 =C2=A0 =C2=A0per RTT. Again, it starts with ack_exp=3D0, but in =
congestion

>=C2=A0 =C2=A0 =C2=A0avoidance it would use:

>

>=C2=A0 =C2=A0 =C2=A0ack_ratio <=3D cwnd_in_packets/8

>

> Upshot: By remote controlling the receiver, the server offloads nearly=


> all the ACKs from large downloads, but still focuses its ACK-receiving=


> resources on getting each client up to speed.

>

> Note that calculation of ack_ratio lends itself to fast integer

> arithmetic.

>

>

>

>

>

>

>

> Bob

>

>

> --

> ________________________________________________________________

> Bob Briscoehttp://bobbriscoe.net/

>

>








--000000000000f0d5e7059799caaf--


From nobody Mon Nov 18 02:08:20 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 9CDB5120018; Mon, 18 Nov 2019 02:08:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Michael Scharf via Datatracker 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: Michael Scharf , tcpm@ietf.org, iesg-secretary@ietf.org, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org
Message-ID: <157407169863.14110.3414673508161665365.idtracker@ietfa.amsl.com>
Date: Mon, 18 Nov 2019 02:08:18 -0800
Archived-At: 
Subject: [tcpm] Publication has been requested for draft-ietf-tcpm-converters-14
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: Mon, 18 Nov 2019 10:08:19 -0000

Michael Scharf has requested publication of draft-ietf-tcpm-converters-14 as Experimental on behalf of the TCPM working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/


From nobody Mon Nov 18 09:18:06 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 6AB8F1209B6 for ; Mon, 18 Nov 2019 09:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 g5mBWDjL91Le for ; Mon, 18 Nov 2019 09:18:02 -0800 (PST)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 2F9D112018B for ; Mon, 18 Nov 2019 09:18:02 -0800 (PST)
Received: by mail-ua1-x936.google.com with SMTP id r13so5511966uan.6 for ; Mon, 18 Nov 2019 09:18:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=irzxpRhqn3CSt2oR2i3g6gaHo/omJN6LMpJphp4SOPE=; b=D2lJagsoBdz1vPEHu5UPXxphxP4UQb5Rz376J4qw6xc7SweF8TtUbgJ6+vm5xDMvjM aYakcXKYB1bPlIRk53AaOpG7pUkW61Cc7QNnC6ahbjq4ThiY+loLiWH54jo2UDKL7JXI S+1/oVgay95EbFmEjuTPwKsQp4QoCOQO/tcjsVy4f+WdIJ8hfwbszu9/NTI4V45URDXD kZQJ80LkMny0z0GTlepGp++jviR1ulTTWlO5GmBDGw4aCQcG5IskZS394pwcbVDejV9G OePgvsQX/e+Zh5Klc2phjdPIs9CPs0xO0dtNHPfabPYAw8hvwQYWo4QTiorX7u6Y81RS 9kFw==
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; bh=irzxpRhqn3CSt2oR2i3g6gaHo/omJN6LMpJphp4SOPE=; b=Nba5ygpT2a13qyZNjgtpWynUv0dXI+goP12TiPUNbqXnB2LU+YpuklLKr/sRLzB/A6 cgCEPvwjCscwK3hZftiHvzspW500LjjQPdfBqr5LvFnWd4yuI+0pEW6/YTcfGSJqetPK zWUYS4BB54eFBOAqiOOgrRkmA+nInr5/p8Jq7NfhBwMewqzvZ956LywyTOYHuSHFSaPW rmsp8pQ+SYUbRHbbKXFIutHcaLIqILgcBcSzaZhYxbVrGWkgWEjEuhiJ5UvpPbii9+9k FiIWCaTuWifyDVfdQC7qnHlPEs8DyoloU5KMSJUNvOvmO3YUqkCL5k6SA2qqFgsWksyu ui6g==
X-Gm-Message-State: APjAAAWblWCyJc/bNoL/QaKCAm9SXRurCn6fk4XcKwf27fsIPYU3lPg8 +o+9/iK7Dnuu3s93vr1m5rucMCLAz4FJ7lb26RgnUA==
X-Google-Smtp-Source: APXvYqy4AMMaVw6YC/iEskivtL+Aca1Ppk4nFAegl28l9c9CbhabiTzPmCTOj7gzZNY4sIVlZrxMtwlET617mPE7PSQ=
X-Received: by 2002:ab0:5a41:: with SMTP id m1mr17980725uad.85.1574097480566;  Mon, 18 Nov 2019 09:18:00 -0800 (PST)
MIME-Version: 1.0
References:  <201911171927.xAHJRnlW062723@gndrsh.dnsmgr.net>
In-Reply-To: <201911171927.xAHJRnlW062723@gndrsh.dnsmgr.net>
From: Yuchung Cheng 
Date: Mon, 18 Nov 2019 09:17:47 -0800
Message-ID: 
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: Neal Cardwell ,  Praveen Balasubramanian ,  Michael Tuexen ,  "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="0000000000002c2d6a0597a221b1"
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 18 Nov 2019 17:18:04 -0000

--0000000000002c2d6a0597a221b1
Content-Type: text/plain; charset="UTF-8"

PS +1 for same reasons people have mentioned

On Sun, Nov 17, 2019, 11:28 AM Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>
wrote:

> I am finding myself in agreement with others, PS is the correct status.
>
> Thank you Neal for the good siting of RFC7127 with respect to PS,
>
> Regards,
> Rod
>
> > On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
> >  wrote:
> > >
> > > RACK is fundamental enough, subsumes TLP, and has enough
> implementation and deployment. My vote is for PS status.
> >
> > Personally, I agree with Praveen, that "Proposed Standard" is
> > appropriate, given my understanding of the definition from
> > https://tools.ietf.org/html/rfc7127#section-3.1 :
> >
> >    3.1.  Characterization of IETF Proposed Standard Specifications
> >    ...
> >    A Proposed Standard specification is stable, has resolved known
> >    design choices, has received significant community review, and
> >    appears to enjoy enough community interest to be considered valuable.
> >
> >    Usually, neither implementation nor operational experience is
> >    required for the designation of a specification as a Proposed
> >    Standard.  However, such experience is highly desirable and will
> >    usually represent a strong argument in favor of a Proposed Standard
> >    designation.
> >
> > There are several independent and very widely deployed implementations
> > of RACK at this point.
> >
> > best regards,
> > neal
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>
> --
> Rod Grimes
> rgrimes@freebsd.org
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--0000000000002c2d6a0597a221b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


PS +1 for same reasons people have mentioned

On Sun, Nov 1=
7, 2019, 11:28 AM Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> wrote:
I am finding myself in agreement with others, PS is the correct =
status.



Thank you Neal for the good siting of RFC7127 with respect to PS,



Regards,

Rod



> On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian

> <pravb=3D40microsoft.com@dmarc.ietf.org> wrote=
:

> >

> > RACK is fundamental enough, subsumes TLP, and has enough implemen=
tation and deployment. My vote is for PS status.

> 

> Personally, I agree with Praveen, that "Proposed Standard" i=
s

> appropriate, given my understanding of the definition from

> https://tools.ietf.org/html/rfc7127#s=
ection-3.1 :

> 

>=C2=A0 =C2=A0 3.1.=C2=A0 Characterization of IETF Proposed Standard Spe=
cifications

>=C2=A0 =C2=A0 ...

>=C2=A0 =C2=A0 A Proposed Standard specification is stable, has resolved=
 known

>=C2=A0 =C2=A0 design choices, has received significant community review=
, and

>=C2=A0 =C2=A0 appears to enjoy enough community interest to be consider=
ed valuable.

> 

>=C2=A0 =C2=A0 Usually, neither implementation nor operational experienc=
e is

>=C2=A0 =C2=A0 required for the designation of a specification as a Prop=
osed

>=C2=A0 =C2=A0 Standard.=C2=A0 However, such experience is highly desira=
ble and will

>=C2=A0 =C2=A0 usually represent a strong argument in favor of a Propose=
d Standard

>=C2=A0 =C2=A0 designation.

> 

> There are several independent and very widely deployed implementations=


> of RACK at this point.

> 

> best regards,

> neal

> 

> _______________________________________________

> tcpm mailing list

> =
tcpm@ietf.org

> https://www.ietf.org/mailman/listinfo/tcpm=


> 



-- 

Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org



_______________________________________________

tcpm mailing list

tcpm@=
ietf.org

https://www.ietf.org/mailman/listinfo/tcpm<=
br>



--0000000000002c2d6a0597a221b1--


From nobody Tue Nov 19 00:18:06 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 B1E40120891 for ; Tue, 19 Nov 2019 00:18:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157415148472.21606.8962379125062106550.idtracker@ietfa.amsl.com>
Date: Tue, 19 Nov 2019 00:18:04 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [tcpm] Milestones changed for tcpm WG
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: Tue, 19 Nov 2019 08:18:05 -0000

Changed milestone "Submit document on TCP converters to the IESG for
publication as an Experimental RFC", resolved as "Done", added
draft-ietf-tcpm-converters to milestone.

URL: https://datatracker.ietf.org/wg/tcpm/about/


From nobody Tue Nov 19 01:52:52 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 59ED3120824 for ; Tue, 19 Nov 2019 01:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 qBcSDc-R24aA for ; Tue, 19 Nov 2019 01:52:46 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) (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 2AF43120104 for ; Tue, 19 Nov 2019 01:52:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AFm2ab1IScyl8BfDVAXoQax7QztwyoO3q7zPvYqhjNDgQjrV/P3JWC5164BezedzYP4g3lGkBjODNFZsakbtbGA7e+O0BvJJ3l83Pnh9Yk92bPGtwED6KyTzLjHF1PG3wb6FfmwcaCI9sYmwbRTC1kOew1ds/ySEaUvXkRO/rSelrkTYyfB/hWiEBiWLYQLXI+7bQE/3lfW4fGBhN5jO6ZmEyjWamzeIMO9J0RtO1Tgy2xd/e+G3wfncCX433BGIiOBWhloeBakJndvnAZ+ryEQy5PeTGILGnTTBNMO/roMew9sL9MLjIUMaBE8KmAcBkT66ekV5TNo2OZYIvlOtdQ==
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=swmN3ulZC1NK1G7ag9YqdyvOFfcQxwFgMVzijd86Wkg=; b=SvOPFS83gvKgtgZCw6nMlLIF/7fgUHCfTT5o3SMa7mQdz66eiBJJUVf51HMwXQSUGDxDa/zW0mbMpo1xVuPMF5W1qV+un5g4gz3oOsusVpcq68GFVqnwuXUSMwY3JuIvFDzdeXZlpdjvvKXwk3wlqfFLeZycWdc/K/UkSqaQsbIz29HpOZu15GAGkRwz4Fex30hMPM6hlVHZvifanphAMOLsxixkGX/W3f6sMYEQOP5qHTmOKb68naoR7j+r4f7Yn5f/JKEOVyfmbGYMM2HDrQsQcaRuAXaD1cvrTxcs0vvf0VHtnYKr5YSsEnBiki6V2QkjhSOeWCgOIDR0bQoRMg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=swmN3ulZC1NK1G7ag9YqdyvOFfcQxwFgMVzijd86Wkg=; b=lHap1biMghBEIi9baY4uc4+wPJd/akaoCu3wrAn3xa1eZvukBf83C6lNrxJRmg1jIya+OL0ZSRE4dEqc8iX5fLh3YuBBTTldg6r7Y+AWHRHEfSbgJyambhveBAiodedfKpLtmGlp0W/PgN4+WRF3FUj+8Ry7Zcmud4B3o9mKVqg=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.81.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.13; Tue, 19 Nov 2019 09:52:43 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::9034:13c8:1ed:5db1%7]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 09:52:43 +0000
From: Mirja Kuehlewind 
To: "tcpm@ietf.org" 
Thread-Topic: New Version Notification for draft-kuehlewind-tcpm-flags-registry-00.txt
Thread-Index: AQHVncNwNiZHeR+KQEauRBdwy0SfHA==
Date: Tue, 19 Nov 2019 09:52:43 +0000
Message-ID: <78356B52-DF62-4FB9-BE5C-4E77E29615CE@ericsson.com>
References: <157404907226.24201.9120992693908341964.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2001:67c:370:128:8c08:8ef9:8447:26d6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 74f1e8f9-2fb1-482e-8612-08d76cd6396f
x-ms-traffictypediagnostic: AM0PR07MB3876:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(346002)(39860400002)(376002)(189003)(199004)(53754006)(186003)(5660300002)(102836004)(66574012)(256004)(14444005)(446003)(44832011)(2616005)(486006)(6916009)(476003)(46003)(36756003)(316002)(478600001)(14454004)(4001150100001)(6116002)(2906002)(2501003)(966005)(33656002)(561944003)(2351001)(76116006)(66946007)(25786009)(91956017)(15650500001)(66616009)(66556008)(6506007)(71190400001)(66446008)(64756008)(66476007)(71200400001)(76176011)(7736002)(99286004)(86362001)(6486002)(8676002)(8936002)(81156014)(1730700003)(229853002)(6436002)(6306002)(54896002)(2473003)(6512007)(5640700003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3876; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: r1tfeKrhTJkRB8ihTY2ez5R0XzX/5NrqSG1pBjX3QTWUQPI5c0ua454tWdvKC9itBb8TJ0DwMeutYud3HcAOMkCvb9i6A34iNKXMVXS1vQI1/2wuqewodlBIa0opsaesr5QlvbCUHl5dzEudqW3kG9zMj2vmcATvCgw0xHO8HdtFqnDxJrKYrB3O0Q1pRxo39uHj60gwBk5VXQJicpDzKnKsC2Mw9Cdmervv8nWCgFO+ntmZpjYZle7ctVyJfROpxNX8ioVoWylXDhlZ1E4jLJElblAi711LjyCYtw4wLxwboG+L6q4PL/qvWLpi+Nbnx9DWUQN2NIr+QV2L9AtYZNGSXIX5Gt38ujnA1GOl/hqvsiUt7LwEosRyQfS8Vdfwg/+vCZ+wYTeZaxrawMLxViXJ5gXV8qjOksmu6Z6+8aUE2+QDHqQ8z2JqLoSaYwkOISAhiIm5Dn6wnAYS5GTVbKjlscJs614ReUu6137mOdU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary=Apple-Mail-2EBBF2E1-C0FA-4E36-B359-93B48361C244; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 74f1e8f9-2fb1-482e-8612-08d76cd6396f
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 09:52:43.7146 (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: 2IjZa+9B9+pT+lBgsmItTA5JbLRDiuQ7awxY8JmVP8gAqxgWBidsH/0TGMc7cOVqN/l3pGTjx4Db/gg9UP1m4Dw9fzrtcwJX6SoohueBr40=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3876
Archived-At: 
Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-flags-registry-00.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: Tue, 19 Nov 2019 09:52:51 -0000

--Apple-Mail-2EBBF2E1-C0FA-4E36-B359-93B48361C244
Content-Type: multipart/alternative;
	boundary=Apple-Mail-4940B013-32BA-4CE5-928F-485569293A46
Content-Transfer-Encoding: 7bit


--Apple-Mail-4940B013-32BA-4CE5-928F-485569293A46
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

SGkgZXZlcnlib2R5LA0KDQpJIGp1c3Qgc3VibWl0dGVkIGEgc2hvcnQgZHJhZnQgeWVzdGVyZGF5
IHdpdGggYSBwcm9wb3NhbCB0byBjaGFuZ2UgdGhlIHBvbGljeSBmb3IgdGhlIHRjcCBmbGFncyBy
ZWdpc3RyeS4gVGhpcyBwcm9wb3NhbCBhcyB3ZWxsIGFzIG90aGVyIG9wdGlvbnMgYXJlIG9uIHRo
ZSBhZ2VuZGEgZm9yIGRpc2N1c3Npb24gb24gRnJpZGF5LiBCdXQgcGxlYXNlIGhhdmUgYSBsb29r
IGFuZCBpZiB5b3UgaGF2ZSBjb21tZW50cyB5b3UgY2FuIGFsc28gb2YgY291cnNlIHByb3ZpZGUg
dGhlbSBiZWZvcmVoYW5kIHRvIHRoZSBsaXN0IQ0KDQpUaGFua3MsDQpNaXJqYQ0KDQoNCkFuZmFu
ZyBkZXIgd2VpdGVyZ2VsZWl0ZXRlbiBOYWNocmljaHQ6DQoNCj4gVm9uOiAiaW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBEYXR1bTogMTguIE5v
dmVtYmVyIDIwMTkgdW0gMTE6NTE6MjAgR01UKzgNCj4gQW46IE1pcmphIEt1ZWhsZXdpbmQgPG1p
cmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KPiBCZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3Rp
ZmljYXRpb24gZm9yIGRyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1mbGFncy1yZWdpc3RyeS0wMC50eHQN
Cj4gDQo+IO+7vw0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3VlaGxld2luZC10Y3Bt
LWZsYWdzLXJlZ2lzdHJ5LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk
IGJ5IE1pcmphIEt1ZWhsZXdpbmQgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5
Lg0KPiANCj4gTmFtZTogICAgICAgIGRyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1mbGFncy1yZWdpc3Ry
eQ0KPiBSZXZpc2lvbjogICAgMDANCj4gVGl0bGU6ICAgICAgICBSZWdpc3RyYXRpb24gUG9saWN5
IGZvciBUQ1AgSGVhZGVyIEZsYWdzDQo+IERvY3VtZW50IGRhdGU6ICAgIDIwMTktMTEtMTgNCj4g
R3JvdXA6ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAgICA1DQo+
IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh
ZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwLnR4dA0KPiBTdGF0dXM6ICAgICAg
ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3VlaGxld2luZC10Y3Bt
LWZsYWdzLXJlZ2lzdHJ5Lw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1mbGFncy1yZWdpc3RyeS0wMA0KPiBIdG1saXpl
ZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1rdWVo
bGV3aW5kLXRjcG0tZmxhZ3MtcmVnaXN0cnkNCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICBSRkMy
NzgwIHNwZWNpZmllcyB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSBmb3IgcmVzZXJ2ZWQgVENQIGhl
YWRlcg0KPiAgIGZsYWdzIGFzIFN0YW5kYXJkcyBBY3Rpb24uICBSRkMzMTY4IGNyZWF0ZWQgYW4g
SUFOQSByZWdpc3RyeSBmb3INCj4gICB0aGVzZSBoZWFkZXIgZmxhZ3MgYW5kIHJlZ2lzdGVyZWQg
Yml0IDggKENXUikgYW5kIDkgKEVDRSkuICBUaGlzDQo+ICAgZHJhZnQgY2hhbmdlcyB0aGUgcmVn
aXN0cmF0aW9uIHBvbGljeSBvZiB0aGUgcmVnaXN0cmF0aW9uIHRvIElFVEYNCj4gICBSZXZpZXcg
YXMgdXN1YWxseSBuZXcgVENQIG1lY2hhbmlzbXMgdGhhdCBjb3VsZCB1c2UgdGhlIHJlbWFpbmlu
Zw0KPiAgIHJlc2VydmVkIGZsYWdzIHdpbGwgYmUgZmlyc3Qgc3BlY2lmaWVkIGFzIGV4cGVyaW1l
bnRhbC4gIE5vdCBub3RpbmcNCj4gICBhbnkgb2YgdGhvc2UgZXhwZXJpbWVudHMgaW4gdGhlIHJl
Z2lzdHJ5IHdvdWxkIHVuZGVybWluZSB0aGUgcHVycG9zZQ0KPiAgIG9mIGhhdmluZyBhIHJlZ2lz
dHJ5LiAgSG93ZXZlciwgY2FyZSBtdXN0IGJlIHRha2VuLCBhcyBvbmx5IGEgZmV3DQo+ICAgcmVz
ZXJ2ZWQgZmxhZ3MgYXJlIGxlZnQgYW5kIGlmIGEgbmV3IChleHBlcmltZW50YWwpIG1lY2hhbmlz
bSBzZWVzDQo+ICAgZGVwbG95bWVudCBpbiB0aGUgSW50ZXJuZXQsIHRoZSBmbGFnIGNhbm5vdCBi
ZSB1bmFzc2lnbmVkIGFueW1vcmUgb3INCj4gICB1c2VkIGZvciBzb21ldGhpbmcgZWxzZS4NCj4g
DQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg
bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVk
IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+
IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0K
--Apple-Mail-4940B013-32BA-4CE5-928F-485569293A46
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJs
dHIiPkhpIGV2ZXJ5Ym9keSw8L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+PGRpdiBkaXI9
Imx0ciI+SSBqdXN0IHN1Ym1pdHRlZCBhIHNob3J0IGRyYWZ0IHllc3RlcmRheSB3aXRoIGEgcHJv
cG9zYWwgdG8gY2hhbmdlIHRoZSBwb2xpY3kgZm9yIHRoZSB0Y3AgZmxhZ3MgcmVnaXN0cnkuIFRo
aXMgcHJvcG9zYWwgYXMgd2VsbCBhcyBvdGhlciBvcHRpb25zIGFyZSBvbiB0aGUgYWdlbmRhIGZv
ciBkaXNjdXNzaW9uIG9uIEZyaWRheS4gQnV0IHBsZWFzZSBoYXZlIGEgbG9vayBhbmQgaWYgeW91
IGhhdmUgY29tbWVudHMgeW91IGNhbiBhbHNvIG9mIGNvdXJzZSBwcm92aWRlIHRoZW0gYmVmb3Jl
aGFuZCB0byB0aGUgbGlzdCE8L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+PGRpdiBkaXI9
Imx0ciI+VGhhbmtzLDwvZGl2PjxkaXYgZGlyPSJsdHIiPk1pcmphPGJyPjxicj48YnI+QW5mYW5n
IGRlciB3ZWl0ZXJnZWxlaXRldGVuIE5hY2hyaWNodDo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxkaXYgZGlyPSJsdHIiPjxiPlZvbjo8L2I+ICJpbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmciICZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7PGJyPjxiPkRhdHVtOjwv
Yj4gMTguIE5vdmVtYmVyIDIwMTkgdW0gMTE6NTE6MjAgR01UKzg8YnI+PGI+QW46PC9iPiBNaXJq
YSBLdWVobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSZndDs8YnI+PGI+
QmV0cmVmZjo8L2I+IDxiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta3VlaGxl
d2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwLnR4dDwvYj48YnI+PGJyPjwvZGl2PjwvYmxvY2tx
dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2IGRpcj0ibHRyIj7vu788c3Bhbj48L3Nw
YW4+PGJyPjxzcGFuPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rdWVobGV3aW5kLXRjcG0t
ZmxhZ3MtcmVnaXN0cnktMDAudHh0PC9zcGFuPjxicj48c3Bhbj5oYXMgYmVlbiBzdWNjZXNzZnVs
bHkgc3VibWl0dGVkIGJ5IE1pcmphIEt1ZWhsZXdpbmQgYW5kIHBvc3RlZCB0byB0aGU8L3NwYW4+
PGJyPjxzcGFuPklFVEYgcmVwb3NpdG9yeS48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNw
YW4+TmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQta3VlaGxld2luZC10Y3Bt
LWZsYWdzLXJlZ2lzdHJ5PC9zcGFuPjxicj48c3Bhbj5SZXZpc2lvbjogJm5ic3A7ICZuYnNwOzAw
PC9zcGFuPjxicj48c3Bhbj5UaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmVnaXN0
cmF0aW9uIFBvbGljeSBmb3IgVENQIEhlYWRlciBGbGFnczwvc3Bhbj48YnI+PHNwYW4+RG9jdW1l
bnQgZGF0ZTogJm5ic3A7ICZuYnNwOzIwMTktMTEtMTg8L3NwYW4+PGJyPjxzcGFuPkdyb3VwOiAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248L3NwYW4+PGJy
PjxzcGFuPlBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs1PC9zcGFuPjxicj48c3Bh
bj5VUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm
dC1rdWVobGV3aW5kLXRjcG0tZmxhZ3MtcmVnaXN0cnktMDAudHh0PC9zcGFuPjxicj48c3Bhbj5T
dGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1mbGFn
cy1yZWdpc3RyeS88L3NwYW4+PGJyPjxzcGFuPkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3VlaGxl
d2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwPC9zcGFuPjxicj48c3Bhbj5IdG1saXplZDogJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvaHRtbC9kcmFmdC1rdWVobGV3aW5kLXRjcG0tZmxhZ3MtcmVnaXN0cnk8L3NwYW4+
PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5BYnN0cmFjdDo8L3Nw
YW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDtSRkMyNzgwIHNwZWNpZmllcyB0aGUgcmVnaXN0cmF0
aW9uIHBvbGljeSBmb3IgcmVzZXJ2ZWQgVENQIGhlYWRlcjwvc3Bhbj48YnI+PHNwYW4+ICZuYnNw
OyZuYnNwO2ZsYWdzIGFzIFN0YW5kYXJkcyBBY3Rpb24uICZuYnNwO1JGQzMxNjggY3JlYXRlZCBh
biBJQU5BIHJlZ2lzdHJ5IGZvcjwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZuYnNwO3RoZXNlIGhl
YWRlciBmbGFncyBhbmQgcmVnaXN0ZXJlZCBiaXQgOCAoQ1dSKSBhbmQgOSAoRUNFKS4gJm5ic3A7
VGhpczwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZuYnNwO2RyYWZ0IGNoYW5nZXMgdGhlIHJlZ2lz
dHJhdGlvbiBwb2xpY3kgb2YgdGhlIHJlZ2lzdHJhdGlvbiB0byBJRVRGPC9zcGFuPjxicj48c3Bh
bj4gJm5ic3A7Jm5ic3A7UmV2aWV3IGFzIHVzdWFsbHkgbmV3IFRDUCBtZWNoYW5pc21zIHRoYXQg
Y291bGQgdXNlIHRoZSByZW1haW5pbmc8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDtyZXNl
cnZlZCBmbGFncyB3aWxsIGJlIGZpcnN0IHNwZWNpZmllZCBhcyBleHBlcmltZW50YWwuICZuYnNw
O05vdCBub3Rpbmc8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDthbnkgb2YgdGhvc2UgZXhw
ZXJpbWVudHMgaW4gdGhlIHJlZ2lzdHJ5IHdvdWxkIHVuZGVybWluZSB0aGUgcHVycG9zZTwvc3Bh
bj48YnI+PHNwYW4+ICZuYnNwOyZuYnNwO29mIGhhdmluZyBhIHJlZ2lzdHJ5LiAmbmJzcDtIb3dl
dmVyLCBjYXJlIG11c3QgYmUgdGFrZW4sIGFzIG9ubHkgYSBmZXc8L3NwYW4+PGJyPjxzcGFuPiAm
bmJzcDsmbmJzcDtyZXNlcnZlZCBmbGFncyBhcmUgbGVmdCBhbmQgaWYgYSBuZXcgKGV4cGVyaW1l
bnRhbCkgbWVjaGFuaXNtIHNlZXM8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDtkZXBsb3lt
ZW50IGluIHRoZSBJbnRlcm5ldCwgdGhlIGZsYWcgY2Fubm90IGJlIHVuYXNzaWduZWQgYW55bW9y
ZSBvcjwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZuYnNwO3VzZWQgZm9yIHNvbWV0aGluZyBlbHNl
Ljwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjwvc3Bh
bj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl
IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPC9zcGFuPjxi
cj48c3Bhbj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl
IGF0IHRvb2xzLmlldGYub3JnLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5UaGUg
SUVURiBTZWNyZXRhcmlhdDwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2Nr
cXVvdGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-4940B013-32BA-4CE5-928F-485569293A46--

--Apple-Mail-2EBBF2E1-C0FA-4E36-B359-93B48361C244
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDM0w
ggYDMIID66ADAgECAg8BaU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC
U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB
IHYzMB4XDTE5MDMwNTE2MTY0M1oXDTIyMDMwNTE2MTY0MlowbjERMA8GA1UECgwIRXJpY3Nzb24x
GTAXBgNVBAMMEE1pcmphIEt1ZWhsZXdpbmQxEDAOBgNVBAUTB2VraGxtcmoxLDAqBgkqhkiG9w0B
CQEWHW1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAzbEm7ACaZBiLCo5AMLb1pe7+qin+EDW/6F5OkuzBE5awAB0DcYPCPnVmvKTjByQE
wXfcv4GpesID1ZoIIw9yvE3JS3e0G9EESbDD/P1dEsvUbfKzqbiogFjxPTcO5393z+S6/lZhh1HE
Xzn5eN4rqXaphkOdt235jtuXr9p9hCXTbk2s2u+Q+UBBsJfDZFnupphfgSJdO2ZDIr54posGTI29
o2Z8Yp0kXGUdReJYhB3U7IyusRfGGlabLLSEb405hQyckqhCqnNDBqgw8s2kCsvCV5vvsU4HxRQB
h6TAo+Qowd5LjjhUb5pWjDzNBw9HDCuv50t6JuUbToV4VodAyQIDAQABo4IBwzCCAb8wHwYDVR0j
BBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwHQYDVR0OBBYEFOS9IY8huUonCxTez1fXbiljN+tp
MA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIB
FixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAoBgNVHREEITAf
gR1taXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v
Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRw
Oi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVs
aWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQAD
ggIBAEifFgbyma9dHCxsY3R0wp+4sjcmAiEvA3S0YKJl7SBd897BV8O/Nq6z6QCx2zKTpfia7bF5
Yzou0/2PS2qX/2TXRsgGKRhWmYyBsiAvKmuEeA9t/3NZOImicaYCn2WVu3tfFE8lnXlH+O/sMRdU
gq7yMusDm9YDO6urKezkh6IZrLWIyz4s4Uy2SMyXc2ujvB0doUB26+ld070A0x+isDjY3of/23Yg
4xAvr5AK5sQtq+0D7tRUlPefXrA1bI/PDEZiq5Bvqa9tfyd7HPlhzHhrQAS5t42fybMpwdGxLvjH
XME5fPB0xRH5kchOawsd2BPSv2ZVWt9WYGDbkAgEtCW37zNwdzX5ix43f8C0TRU5AiU531gObLbr
KWZyhLRurGlwtSqvmGCyCiTN3jhzjVTAM3uiLosG2SZbyq5ZFWI7MezHM1owAQvm0sOEEfXp88nc
Xa7SxkwiJr/UH6P3pRADsVC55HoQVS1GydEBnDBNAyIcnsM7sPbkGF92F7U16PWpJYQaZbVd2Vkj
FahNN9uWbn55A/daE+QiF2QcfCVnFOSj9ah1ke6M3MahqcqkJpXoUizv8DwiKXGkKOiLB3x8pqSr
cCUQ5Pjt3wFjPCuVJ7AoiBYP2GmXAyEXtYeh0nVlKQuVtloCpsyR5bumbOoQf/r6FoUY/xgh8/pg
pOMiMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYD
VQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEw
MjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv
bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6V
iqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1l
VtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV
2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTS
uG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvA
l7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQg
YFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8
s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3W
LJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e
6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzAB
hiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9y
ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjAS
BgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUH
AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwRE
MEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFy
b290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIB
BjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV
6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1A
soZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46g
zKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQG
pieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+L
Faaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOr
MGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5Qxib
XqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6
PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfY
PGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/
HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICyjCCAsYCAQEwWjBHMQswCQYDVQQGEwJTRTER
MA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMC
DwFpTqSZb/vyPJVk+BviKTANBglghkgBZQMEAgEFAKCCAUEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTE5MDk1MjQzWjAvBgkqhkiG9w0BCQQxIgQgLSIyu5Pn
lbqpvOwzyf/vVZvotPjPT2rbFBYkgBrwmnIwaQYJKwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJT
RTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg
djMCDwFpTqSZb/vyPJVk+BviKTBrBgsqhkiG9w0BCRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAP
BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8B
aU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQEBBQAEggEAyKkQJnv6OsB7buRxq5+KL/Go16ZivdKz
XazS/KhNNJ9br/M0WIrfBlyjyT4ru6PmnDZ/KiOM/TS5vIRwX0Sanepc6B0BApWi3+yEavJRmaF/
GN3D/xRz0aYDUsw6X0fMd48oy4yylLgjtFXCy7gln+75RMOPHxA8jg+HZhO+NUL3JfvgfM8AB8RX
Mqws+ME/B6V0kpIcP9q+xFc9hD/f07hiQH7UmTMO6/X7wRRdWXXISP0pdZz5/JZOEb5AVRNltQpR
5ccXPkOyV6CUQBya8dJykd9g2Ea83GbhvijhziqRTnGtOtsG9vs5Ly8dlLxcbOwa8Am3wkKxBNG7
XQq4EQAAAAAAAA==

--Apple-Mail-2EBBF2E1-C0FA-4E36-B359-93B48361C244--


From nobody Tue Nov 19 02:52: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 A8CA5120921 for ; Tue, 19 Nov 2019 02:52:06 -0800 (PST)
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 Hy2cNULm1nPw for ; Tue, 19 Nov 2019 02:52:01 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20074.outbound.protection.outlook.com [40.107.2.74]) (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 00D8A120289 for ; Tue, 19 Nov 2019 02:52:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S4YDHys1oyCorRR1tv/vZdoHk7SmtXxqV6dwS6WlMwGYU2is93gseIw3YINsoyOkQc1AjyRky6ouy3x+8DqdnGbICKqZDZ+YNWoiLEFZCAUoE/8M+1xw1E2leBqOxYXiu+lS9HIURXootzRRJdot41HpGoynHo3Dn/sPgToqmf4zTjKTcBOyjixYpes8j9lOO09r+1Xiyi8mwFiKBmb3ek46DzzcyOaF6N+HSSm/3uQXaB4hM5mIoX8judA4XtzInoiK8iFwOONpepcGpeAmD35qNOx1C2cNamBeO82gFQlCxqlzxc1RncpHCZ8tEjJBhegNxoGr3NQE7F+aOuT9Yw==
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=gea+MK8WsOIVqL6grLEk6yFCASuNLKb6I3SkZF0w4P4=; b=J8kRGMLOTR91uyCKWcXhIS/FaOPkKk8MmYu1vQUvvGdyKAdJyl7NjoX6fNRlaibe6eW2hLI9tSDX/EBRP5w8mwyY1il90mVQxUc4fLs3AZNKwDTF/qpRzWkNxLJIdVSJ5aDwBWpKC/086EinEdYuSRZ7Vdrkc82s0mhGSlu6uoqt4eN5uxpcfe1+pv6248nUgosAUMSXgKS9jg/IZ+VDO3MV8XGdoVDE8hR0A8w9u9OlZlbXNoTH/cq2FdlPkxbcvJihpVi9hBOb2mOdcQObP8C4lKO1W07NTa+CAPc0zPAb8EVWuvoV9p7OkJirfyWX2GPoZ54cN7TrwNe50lRD1g==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gea+MK8WsOIVqL6grLEk6yFCASuNLKb6I3SkZF0w4P4=; b=e2fdKzQNQ/xx4TwfHv4ZP1vIKIBjWY2RZymGyNl0syqARvVF99Rxhakpg59tTHpNcFUWG4IVgGOlmzaocLiLmG7aefr+BVPYJgvB/N8VUQ34CbVFL7Fu5qdrN7YV0U1Ecc/AezjgUWTqV16PLuPicJeOM8AiXFeb9Bhj/pmh+es=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3129.eurprd07.prod.outlook.com (10.170.241.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.7; Tue, 19 Nov 2019 10:51:58 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 10:51:58 +0000
From: Ingemar Johansson S 
To: "tcpm@ietf.org" 
CC: Neal Cardwell , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>, Praveen Balasubramanian , Ingemar Johansson S 
Thread-Topic: Intended status of draft-ietf-tcpm-rack 
Thread-Index: AdWexcS8eS9aGmFuQdyvHIcbtAFW4A==
Date: Tue, 19 Nov 2019 10:51:57 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [192.176.1.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3977e0cc-c423-436b-d9f6-08d76cde7fe0
x-ms-traffictypediagnostic: HE1PR07MB3129:|HE1PR07MB3129:
x-ms-exchange-purlcount: 3
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(39860400002)(136003)(376002)(366004)(189003)(199004)(186003)(7696005)(81166006)(81156014)(64756008)(66446008)(66946007)(66476007)(66556008)(1730700003)(4326008)(8936002)(86362001)(5660300002)(5024004)(107886003)(256004)(66616009)(229853002)(7736002)(6246003)(4743002)(14454004)(26005)(305945005)(966005)(6916009)(6506007)(2351001)(102836004)(71190400001)(53546011)(6306002)(5640700003)(9686003)(2501003)(8676002)(55016002)(25786009)(478600001)(476003)(76116006)(3846002)(6116002)(71200400001)(52536014)(99286004)(66066001)(2906002)(74316002)(54906003)(316002)(6436002)(486006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3129; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Kyo4zax0rF7lc6rWtIcT4OAsRmKk7kSC87FnDw5UNPEhszoahzcBqvg2zPumlPp+Y7V5fq9OQGgJKNz8TP0kz4FKro0U3hJhQNYO0GX0th3BjX+cwi66x8DitNe3OVmMJL2lKL60gP/OfXH1FJyX8td7smiOMODW3brKLYIzEEuQJ306gdzIiPaQld3+o6OhBLSKiDQjif3149fgJv5t7aWIi5xhs4j4mXyR001sHiaZs/PXFndOra0haedRVsC50DCCsaI2qlrlhfklExAPOmvFGUX2t71Kjjasx0Utg3V3RfrZrwKPiTh9Fm9LxF2yyY/quqCYYcrBcgiXb4cId8yuNZsD3i/j+ZJmZXKg3T8YicGvQrR8iZxN+aEt2FmE+AMRzLQfjMI4bPP2PutfyC6BzTPylwqoN1U65UaHtq/y5ZYpXbCI6CobNmiPoY5NWITEVahV8+5hEIzD3Qrlbc+qQGjOU6RfzSTlfgwwqk0=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02D5_01D59ECF.BE337580"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3977e0cc-c423-436b-d9f6-08d76cde7fe0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 10:51:57.8967 (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: 7hNhtz96IQvXdmfHBe0AKqaiSVqJa59BkiJ+xZzcW7s2Ny62kraFO34SwnogATrUgU0RnT+M3PpfnFsX675XdoVz12CUTdmTU3i8Ai4N+0CJnmKzHip8jrE3wIfE8xtJ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3129
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 19 Nov 2019 10:52:07 -0000

------=_NextPart_000_02D5_01D59ECF.BE337580
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi

I am also in support of proposed standard for draft-ietf-tcpm-rack as this
can potentially relax the strict ordering requirements in 5G deployments. I
am not 100% certain of the actual value of proposed standard vs experimental
ditto outside IETF but it is definitely not of negative impact. 

A question (perhaps already discussed on the mailing list): 
How widely do you think that RACK will be deployed in TCP stacks in the near
and more far perspective?. 
I know that it is already in Linux. What about MS Windows, FreeBSD, IOS,
Android ??
/Ingemar

> Date: Mon, 18 Nov 2019 09:17:47 -0800
> From: Yuchung Cheng 
> To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
> Cc: Neal Cardwell ,  Praveen
> 	Balasubramanian ,
> Michael
> 	Tuexen ,  "tcpm@ietf.org
> Extensions"
> 	
> Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
> Message-ID:
> 	 SrGapKQprqwFcOwt9BwkcDHEQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> PS +1 for same reasons people have mentioned
> 
> On Sun, Nov 17, 2019, 11:28 AM Rodney W. Grimes
> <4bone@gndrsh.dnsmgr.net>
> wrote:
> 
> > I am finding myself in agreement with others, PS is the correct status.
> >
> > Thank you Neal for the good siting of RFC7127 with respect to PS,
> >
> > Regards,
> > Rod
> >
> > > On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
> > >  wrote:
> > > >
> > > > RACK is fundamental enough, subsumes TLP, and has enough
> > implementation and deployment. My vote is for PS status.
> > >
> > > Personally, I agree with Praveen, that "Proposed Standard" is
> > > appropriate, given my understanding of the definition from
> > > https://tools.ietf.org/html/rfc7127#section-3.1 :
> > >
> > >    3.1.  Characterization of IETF Proposed Standard Specifications
> > >    ...
> > >    A Proposed Standard specification is stable, has resolved known
> > >    design choices, has received significant community review, and
> > >    appears to enjoy enough community interest to be considered
> valuable.
> > >
> > >    Usually, neither implementation nor operational experience is
> > >    required for the designation of a specification as a Proposed
> > >    Standard.  However, such experience is highly desirable and will
> > >    usually represent a strong argument in favor of a Proposed Standard
> > >    designation.
> > >
> > > There are several independent and very widely deployed
> > > implementations of RACK at this point.
> > >
> > > best regards,
> > > neal
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> >
> > --
> > Rod Grimes
> > rgrimes@freebsd.org
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>  5c28b/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> ------------------------------
> 
> End of tcpm Digest, Vol 187, Issue 64
> *************************************

------=_NextPart_000_02D5_01D59ECF.BE337580
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMTkxMDUxNTZaMCMGCSqGSIb3DQEJBDEWBBRI2lXrgJEhiBI3IiIB
bgy902vZPzBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBADg3HEvveqsWscWy6g3SRsJpEJ4HazvfGaGWl3Po
aYiw68HUGfU8H76JMoCBlNhEvlSFeIadjztKEySLFiRDPQedpfHwC2dastL4o3xEx9tMzyy0LphV
EoLzcqobbKXB3y6ZXh2seSJWacFCRoVCfUqHqlpmJEBX1zceUspqd33WLaeWqsS1gTLN+7FRNq6m
uGnhSBTpNI/T0nR76bTBy0bvV2bRMgQfBk8o3WUVNbFP3x9mH6h88gdOyCnbiDFKBaWbJpNa+9YJ
qVKV7awx2BVgOb2zImNkOEe8zwH8tfUu9usZRX3+DQDhq3UW7zPg/maixq6DLL7Sc9hLhJO9UikA
AAAAAAA=

------=_NextPart_000_02D5_01D59ECF.BE337580--


From nobody Tue Nov 19 03:06:16 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 6104E1208F6 for ; Tue, 19 Nov 2019 03:06:15 -0800 (PST)
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 EvGUVSD5aBCG for ; Tue, 19 Nov 2019 03:06:14 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 F07141200D7 for ; Tue, 19 Nov 2019 03:06:13 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id c184so12017584pfb.0 for ; Tue, 19 Nov 2019 03:06:13 -0800 (PST)
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=DCR57VhUNFSaxByWjL/V7c27eEBJXQMUJqr1UeTeDfk=; b=uj9/j3aeXMS8cW/XB2gNojAGvtSleTruwhpiBiwEd5oZkVrPmUB8krMdbvnc9tUOee RE85t/bnQErDBhYQ/BvAbXXpswsfqpR8ljXUei1s6pWQMYo7FkoMDe3ocFt8yRuFZtjh xB2ta2fhI8BT00bSZnKRINsJkgYhf01kgwpLzCiDUh7sAf3x2CsA9mbBtPScd6g8u9Dt vFCTL4sAIMMeYRU5SuM+5DUd4OindyLaObUq0okO1POyWYOEVQeEqfunymgZscKz1hvI a27Tw/q0rrnrXIg8vHrxwMyviIQviMp9Ffy0aDVvPikhpTLRUUBx9anDPwhW5piNju5D iRQQ==
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=DCR57VhUNFSaxByWjL/V7c27eEBJXQMUJqr1UeTeDfk=; b=Ffa0oX9Yq8xNJZHTgDAJN4ngaJ8OV67xWr6EzoZlJbW+HRNKpZTDxgqLAaQ9pZMCN2 0LiSKntI6NlgkqtzSUvXpfEmTtxNyjhtmF+quqeAJeok5TSKpJoZqaltms4lAKZawXmB /UmIGSH8ZTRFRd9SU4uqtgta1IOSUvCTYM+UyTZhdeYmL1RV5lUSOEj7IEoD5S1lFxyT k0gWu6iFR4zM8LHE0ybLzYgYkLlhvcOMKhz7NKJ43WJvin7JPszxOKSaX/uYmCpoZsmA 4ba4GK6VSTn4jEIL+fo9HRZujFPrIqlr9N6nuy4EOhLXmThwImMaVBDVjWLVk2NHRKyQ D1hA==
X-Gm-Message-State: APjAAAUU4UDMwfniBXz9gOdgiNm4CBSTdLMGoVEzG7BSQz9IAXeBB2So G6ge4f1qYRYoMliFZ52OjKU=
X-Google-Smtp-Source: APXvYqxi6HMdyVyiGjqrqT4YG5ZAM8DsMg4j3D55C8CCJFDnh4jMXziHIa8EkgYay2MH1Jhg1JCScg==
X-Received: by 2002:a62:6086:: with SMTP id u128mr5153136pfb.4.1574161573598;  Tue, 19 Nov 2019 03:06:13 -0800 (PST)
Received: from jonathartonsmbp.lan ([182.55.197.52]) by smtp.gmail.com with ESMTPSA id 83sm24053284pgh.86.2019.11.19.03.06.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 03:06:13 -0800 (PST)
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, 19 Nov 2019 19:06:10 +0800
Cc: "tcpm@ietf.org" , Ingemar Johansson S 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 19 Nov 2019 11:06:15 -0000

> On 19 Nov, 2019, at 6:51 pm, Ingemar Johansson S =
 wrote:
>=20
> I am also in support of proposed standard for draft-ietf-tcpm-rack as =
this
> can potentially relax the strict ordering requirements in 5G =
deployments. I
> am not 100% certain of the actual value of proposed standard vs =
experimental
> ditto outside IETF but it is definitely not of negative impact.=20
>=20
> A question (perhaps already discussed on the mailing list):=20
> How widely do you think that RACK will be deployed in TCP stacks in =
the near
> and more far perspective?.=20
> I know that it is already in Linux. What about MS Windows, FreeBSD, =
IOS,
> Android ??

Android is Linux, to a first approximation, and thus inherits its =
networking capabilities.

FreeBSD I understand has a RACK-capable TCP stack, but which is not the =
default.  I think Rod Grimes should be able to clarify this, and he's =
also on this list.

Apple devices I do not know for sure about.

 - Jonathan Morton


From nobody Tue Nov 19 04:07:55 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 0BC5C12004D for ; Tue, 19 Nov 2019 04:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 vEZCQ_3V5fT4 for ; Tue, 19 Nov 2019 04:07:51 -0800 (PST)
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 2FAF91200DB for ; Tue, 19 Nov 2019 04:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574165262; bh=I4MsKFPsTr5uvE83O/VqUPtoQ6JJsH/Esd+ka3eFIaQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=HE0gB8gGEPQ5BOYkXZ3fWQmZ1KDJa8Zh0mkzZk9WYatwqOfCzJ1VBBTkDZ1yu6O+9 d+RUdoB+XksiwUIjUBGI8ZL4aJ7lGwcOmOuWhEZTQ8jFK6UBdSMkzBJhESAfgIlIFx ilShgfxUlV+EK/tGEXWJ36/dBLwQBgwhKiGWR3l8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.20.8.66] ([202.55.67.146]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N9dsb-1hlHND1gM1-015Voh; Tue, 19 Nov 2019 13:07:42 +0100
To: Jonathan Morton , Ingemar Johansson S 
Cc: Ingemar Johansson S , "tcpm@ietf.org" 
References:  
From: "Scheffenegger, Richard" 
Message-ID: <51d48c8c-c668-8122-fd88-037a86cdbe38@gmx.at>
Date: Tue, 19 Nov 2019 20:07:36 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:kimDg243nIPNvgpKQGKCVjvv7f96bYSdWZRM/1QyBIFN8VIgWII BTkoxwfeQfct/a7uvDegW6FYaZmSo52s3djWS11Eg22VjdEIjGjs+EflOD2E2MWxHv1WqfY S+OnrChWedLK4I7/u9Fh8mHimpqRkaCvtbqVvCP0Z1qZcq35fnbhEprNNe4YWSU/UXZ/DgM 3BeoiOkV6Pig5/Csyco/A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mP5DvPKnB9o=:sOujRmKz+zDfEbF/quQFGv AIxcI6mm7qTH6LdC+sXHphipS71xvG/GbrMLA9hhuqprnEHRAF7N/psaQkoHXOfZmlWqBxdKh dZFdTpzBhul3iz0fBIMArRNXs39kK1TNL3R6EpbVJMVQuEw0ozyR9SFJsvCVZLo6Cz3LUImW8 2vNNB3Ug/j0ol8Pa4YgEYrW/CA+NUh0DLNW6BWpRI293j8hBklzcFOnXPcW/yZxYLcvQI6EKC 6NoceE7127sOSPu9K5iiPpAcckmCAFmyeQiDs2RfKedKZBRjhpRUbg3unAIPy29uhDdbSUTI6 XdX6TjkdsD2twM3waMG06bwMA9ihf6VusC7bwALFwCDzQybmw1XdAB3q5oyOT77bEl5F2YqJL bBoVJ6KKYz/qectmsC8wwDOg6jMJh3MW10mQ6CO2TV9hiDjyQ1nDcTN6DDh9x77AfBwUxUPbX HtyhwhkkmyrSvRT4DOliGwc038+PzBhDG8PcSao1qqZQlW4bNLq7KCjU1K9yyFjS3bq9/czlc CfSnqlPWalSt1B7SWPF9ob+O91f7czSpar7uQbAQLhXEfJCw7tAQ6/EcuHzElbcODVErHkBKV UXnYy+5Rsftt655ItL5nw/H9/Bdn7z/5GVeRL3p3knK8Dk9faX1+xzpCGxBaUbr+rVQhZWQQb 6ht+NvGIaW9FI7A+tmYuLZ/aukYhIji5nhp84QbQHxBI4JEZxX2boVHGKvFcMk5oe3sb9m17G Kim+bQh2c9h14c97uEMHzIUvkB4lBjogeC/3YPN2t2bBvxqzWSntG/6U/oyEskMLY4nVjIRGY VvUWv7/Of5FNzLibh7BqZaznBtyvL32Zrt1JrCwDa7jSgO/R/D+rguRKTKjXLXBPFlE3kkKh/ rWfkj3WzmGW3D6B+IL5mDDRmByG6gbGE7osM/JaHOUeLirU8vIH4zTCt14BGj8/HTmTAmWfiD k+cgLyqWCS8YEN7kH3vucRnObK0nzRWkAYXB0SDUJuviAVLzXjL9sJ1f5pFIsgYsrytxabj4K Cl6/k87p2dwd21CaY8lCuXFsa4qa9Bn8HGobiORth4P3jsZWe9wi0CrWZmaqtWFrbOkJmzb5i 8GUHUUnwphZLJEXSV0ofHq3c57go9EfDaySyIuq/UtB7ESw4JWAKjZMTA7pGA6kCClrsRBws4 gbODJjHlRW+/nMxP2n0GCNvESLxjsyAqjgHcfkAwssMkpgOEoNrhv+4bg1jhWQM80AGxT1FnY +rv5Xv2jnpy2/Ejh0H5ssv2ndBwJ174wkzcnTdQ==
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 19 Nov 2019 12:07:54 -0000

For FreeBSD, that alternate stack is in production (public internet) use
by at least one operator, and other operators are looking into making
RACK their default.

Also, on FBSD any improvements on the base (NewReno) stack need to be
reflected in RACK, e.g. when new functionality is implemented.

RACK is certainly a serious affair :)

Richard



Am 19.11.2019 um 12:06 schrieb Jonathan Morton:
> FreeBSD I understand has a RACK-capable TCP stack, but which is not the =
default.  I think Rod Grimes should be able to clarify this, and he's also=
 on this list.


From nobody Tue Nov 19 04:08:44 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 73595120917 for ; Tue, 19 Nov 2019 04:08:43 -0800 (PST)
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 yhcQm55xp1kY for ; Tue, 19 Nov 2019 04:08:41 -0800 (PST)
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 1687D12004D for ; Tue, 19 Nov 2019 04:08:41 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 99A8125A14 for ; Tue, 19 Nov 2019 13:08:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1574165319; bh=dX5D3lHGQwoOrQTesxK9hCKVJdKwEnntHRK8aqhsLeE=; h=From:To:Subject:Date:From; b=WHDIh7eAj7iM6kFiXjsK4zX5y2MBqMXCJP2RA9QYcWkdMVSn1r1k7MWRGFWQOkcY/ tmPQ9A1XPDVfF8/LSZ//nnXxbnWkYt+nZ/Axef7Rhn8+qPGYgENIft4uArSU3F2wRp MJYu4M/wx5JXEG2IQsAVW/ygoo/SMz4/bBAeNPDg=
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 G5KXMeNiszG0 for ; Tue, 19 Nov 2019 13:08:38 +0100 (CET)
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 for ; Tue, 19 Nov 2019 13:08:38 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 19 Nov 2019 13:08:38 +0100
From: "Scharf, Michael" 
To: tcpm IETF list 
Thread-Topic: Thoughts on EXP vs. PS in TCPM
Thread-Index: AdWew5FU19VWLf+AS/Gv7aHLLJwOLg==
Date: Tue, 19 Nov 2019 12:08:37 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@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.63.68]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] Thoughts on EXP vs. PS in TCPM
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, 19 Nov 2019 12:08:43 -0000

[chair hat off]

In TCPM we repeatedly run into the question whether to publish specs as PS =
or as EXP. We also have several worked examples in which TCPM first publish=
ed a EXP RFC and later a PS.

This somehow implies that TCPM often follows a process with three maturity =
levels (EXP, PS, and Internet Standard), while the IETF actually has two ma=
turity levels (see RFC 6410). Formal definitions are:
* EXP in https://tools.ietf.org/html/rfc2026#section-4.2.1
* PS in https://tools.ietf.org/html/rfc7127#section-3.1=20
* Internet Standard in https://tools.ietf.org/html/rfc6410

As questions on EXP and PS emerges repeatedly, I think it would be useful t=
o discuss two questions:

1/ What is the minimum requirement for publishing an EXP RFC in TCPM?

2/ What is the minimum requirement for publishing an PS RFC in TCPM?

I have been thinking myself about these questions quite a bit, most notably=
 since I have recently also worked in working groups outside TSV (such as R=
TG and OPS). As far as I can tell, other IETF working groups don't make use=
 of EXP as frequently as TCPM. In many working groups PS is the norm.

I start to get worried by that. At the end of the day, the IETF is one stan=
dardization organization and TCPM documents matter also to other areas of t=
he IETF, as well as the networking industry as a whole. So, TCPM does not o=
perate in isolation.

Of course, I am partly accountable for that, given that I have run several =
consensus calls on the target status of RFCs in the last years. I think the=
 community feedback was pretty clear in all these cases, typically in favor=
 of EXP instead of PS. Yet, after more insight in the rest of the IETF, I w=
onder if maybe TCPM sometimes decides to early to go for EXP if PS is actua=
lly possible?

For instance, as individual contributor, I believe that IW10 and TLP could =
fulfill the PS requirements now. And, in retrospective, I think they were n=
ot far away from PS at the time of publication. So, in some sense, TCPM has=
 been very careful and conservative when publishing these RFCs. This now im=
plies that we would have to reissue a PS to actually clean up the RFC servi=
ces.

Given that other working groups apparently operate differently regarding PS=
 as target, do we need to rethink our minimum bars?

I believe that it would be useful to discuss this question, and I'd be in p=
articular interested in the opinions of implementers.

As a starting point, I offer my own understanding of how to answer the two =
questions - with chair hat off. So, feel free to disagree... Of course, a c=
ase-by-case analysis is always needed, so this is not really a checklist, b=
ut I guess we should have some general understanding of what "maturity" rea=
lly implies.

Michael's thought on question 1/:

In order to start a WGLC in TCPM for EXP status, there SHOULD be one implem=
entation in the main source code tree of an important TCP/IP stack; a defau=
lt to "off" is perfectly acceptable. Alternatively, there SHOULD be at leas=
t one implementation outside the main tree and a certain level of operation=
al experience e.g. in very controlled environments. Comprehensive testing b=
y simulation can also be understood as operational experience if the simula=
tion results are verified independently. (As example, the converter specifi=
cation meets this requirement in my point of view.)

Note that this requirement is significantly higher than what is written in =
RFC 2026 - in principle, thousands of research papers on TCP could meet the=
 EXP requirement of RFC 2026. But, at least to me, there is little value in=
 documenting an experiment without proof that it is actually implementable =
in a TCP stack.

Michael's thought on question 2/:

The requirement follows from RFC 7127, which strongly suggests implementati=
on and operational experience, but it is not strictly required. So, there i=
s some room for interpretation. The bar for PS is _not_ widespread deployme=
nt in the Internet. For instance, to me a WGLC for an PS could be started i=
f there are two independent implementations, at least one being deployed in=
 an important TCP stack (i.e., one does not have to be production quality),=
 and some operational experience over a subset of the Internet. For instanc=
e, such operational experience can also be tests, it does not require enabl=
ing by default. (As example, RACK easily meets these requirements as far as=
 I understand.)

Note that with two independent implementations one gets already relatively =
close to the requirements of an Internet Standard, but in that case also wi=
despread deployment and some other conditions are required (see RFC 6410). =
So, the bar for PS must be lower than that.

Please feel free to comment and/or disagree...

Michael


From nobody Tue Nov 19 05:52:51 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 A0ED9120887 for ; Tue, 19 Nov 2019 05:52:49 -0800 (PST)
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=microsoft.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 3N2hgejQNzGX for ; Tue, 19 Nov 2019 05:52:47 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770135.outbound.protection.outlook.com [40.107.77.135]) (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 DC3D31200FE for ; Tue, 19 Nov 2019 05:52:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oPTBWeYP7bPghog1cPmknacr/MLVeFL8H//bV0gYgTBhfKPEUi0e0dwfdK5iNgZJ25U4v05Y0039MHUzE6iqhePEJsAhoB1Z9IoyuX/H6aVK86ocJ5cAayZjMQJ63wMXpgMxPvSQYJJuat+ujAetMMl38qT8iZOMBOwSRuyFakwXtNod9dxvUyJ2KMTfFKqCQBPMX1F4JPIrgVAxTd45fDBxbbTVqd/utXJYs00zXCuzDIHtylrQA76rYihoS5gGD6+0JYdWUIWNOiOFS7p546rDQdrUGPKyovKxvLR0y45dJ+PJ1egEFEawjr2GXiK/k+AQGoyIMBu6f7UKnMnq9A==
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=r+zsRKzcx6ON+EYB5EFzofchDeiP7+1nPJTgcsFs2G4=; b=Sz6Jedc4Z53lkVLcCAfgK9kIUxkFmNPPXdfM2Za49Vr2/mBeK46sAdvokL/LR7TyUz43lhEU7j7DIFpU4BiwHy839yUKo5Fa5XLm91c4sckxPJa0Bt/cR8kg/jC443fyMEq4FYjIPX4ZpWJwCl7oEsYyGj+Wme0hSokvVAZ6Hu8zwAhOmqkFpd45p0K/hTX8+Bu5TIKitfTl/l5N+0PH3bx3rA7eNRuVkn+vGeQniwhfyzD5cM3ols3UAoOkzo6TpsQyOu+YPrv4+S5fBOFtuPHcdpblCIartbc4C7ZAI3aLvPUFxJiUQTRMi9EyEW+2cFeLCWCWluaOyqxQkbkySQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+zsRKzcx6ON+EYB5EFzofchDeiP7+1nPJTgcsFs2G4=; b=O8sMT0BdTXb7+LdWVopUPeqaPqvcgPvmMjx3FqUeiqSmGGNkjb+Pv6Zbxdz1w2/nLqNCGQ9Ze4ZuCKdLU1KIg7dj4pHsSttOYmGwZVt7Bp6lC96ZmOiB9gpZF7WJLQzxzQlDC6YCZHSw9VBapzK39e2gbCekK/ifp4m2BTpo3B4=
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0892.namprd21.prod.outlook.com (52.132.152.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.4; Tue, 19 Nov 2019 13:52:43 +0000
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::f8d0:bf38:ea25:edfa]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::f8d0:bf38:ea25:edfa%7]) with mapi id 15.20.2474.011; Tue, 19 Nov 2019 13:52:43 +0000
From: Praveen Balasubramanian 
To: Ingemar Johansson S , "tcpm@ietf.org" 
Thread-Topic: Intended status of draft-ietf-tcpm-rack 
Thread-Index: AdWexcS8eS9aGmFuQdyvHIcbtAFW4AAGli0g
Date: Tue, 19 Nov 2019 13:52:43 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=af840838-f5d5-460f-bc2c-0000ceb76c0f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-19T13:49:09Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-originating-ip: [101.100.166.3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 7def97d0-101c-4e67-75b0-08d76cf7c029
x-ms-traffictypediagnostic: MW2PR2101MB0892:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:3968;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(346002)(366004)(39860400002)(199004)(189003)(13464003)(6246003)(25786009)(7696005)(186003)(256004)(5024004)(99286004)(26005)(102836004)(55016002)(9686003)(6436002)(6306002)(86362001)(52536014)(76176011)(486006)(5660300002)(11346002)(229853002)(2501003)(446003)(476003)(33656002)(4326008)(110136005)(4743002)(22452003)(53546011)(71200400001)(3846002)(71190400001)(6506007)(10090500001)(6116002)(8990500004)(316002)(81166006)(8676002)(81156014)(966005)(8936002)(2906002)(66946007)(10290500003)(76116006)(64756008)(66556008)(66476007)(66446008)(478600001)(14454004)(7736002)(74316002)(66066001)(54906003)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0892; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PahU/SsMmS3R4EPdg3t4NZGk45DVaF67/ENH18oXu5V/BSeYrP9AhlOyxWw0vHB8WLue8hPyApGifWC2kAaZIo6SROwx1vzGKklRX/vOEeUHK7+Hw27i0GecJiAYFXsDqhAxUo8TCjOKl1MzGRqpVRiSwuD7nNGAV4hDMLbsgWdGn0+elwXNXmgP6T50z4aNG4dqo8193AQjQPA+L1Esi9iCRQG3VhuXsAGsrwQE21PyI98RiC4PR4DJ6fzLiF7ONJxg/m8aWUd+Bb4VC73+SjBnmt7rpRIrFSPOQ/9Q/MxBS6eMIDbheWKNmXe+pDttsW1e3eUXv10MYqu0AohxLXuKSkkBgGPU8q6NJS9N2pUwBEofVXQYACWKRSSrcc1OKaf/iQ9s4wVOmPkGGUcScaDIiBuWisuAx5fxhUapvmGNwIs7+A6wz4Yg2XieIohJ
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7def97d0-101c-4e67-75b0-08d76cf7c029
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 13:52:43.2509 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VSnariy02MY6m4GUlEZmrrAMrNnJFFQdBrP1K5soaCQ2rBCwqqrvOYoUUvDtayTWso2MWIhuBgYPZKR0l9cqe0lX4pTXCTrDMx80CHIWJ6Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0892
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 19 Nov 2019 13:52:50 -0000

Windows 10 and Server 2016/2019 have RACK enabled by default for connection=
s with 10 msec or higher handshake RTT. But do not assume that RACK implies=
 higher reordering resilience. The dynamic adjustment to reo_wnd is optiona=
l in the draft and requires DSACK support. Plus there is still large number=
 of devices on older OS versions which don't have RACK. So for the time bei=
ng strict ordering requirements are here to stay.

-----Original Message-----
From: Ingemar Johansson S =20
Sent: Tuesday, November 19, 2019 6:52 PM
To: tcpm@ietf.org
Cc: Neal Cardwell ; 4bone@gndrsh.dnsmgr.net; Praveen =
Balasubramanian ; Ingemar Johansson S 
Subject: Re: Intended status of draft-ietf-tcpm-rack=20

Hi

I am also in support of proposed standard for draft-ietf-tcpm-rack as this
can potentially relax the strict ordering requirements in 5G deployments. I
am not 100% certain of the actual value of proposed standard vs experimenta=
l
ditto outside IETF but it is definitely not of negative impact.=20

A question (perhaps already discussed on the mailing list):=20
How widely do you think that RACK will be deployed in TCP stacks in the nea=
r
and more far perspective?.=20
I know that it is already in Linux. What about MS Windows, FreeBSD, IOS,
Android ??
/Ingemar

> Date: Mon, 18 Nov 2019 09:17:47 -0800
> From: Yuchung Cheng 
> To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
> Cc: Neal Cardwell ,  Praveen
> 	Balasubramanian ,
> Michael
> 	Tuexen ,  "tcpm@ietf.org
> Extensions"
> 	
> Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
> Message-ID:
> 	 SrGapKQprqwFcOwt9BwkcDHEQ@mail.gmail.com>
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> PS +1 for same reasons people have mentioned
>=20
> On Sun, Nov 17, 2019, 11:28 AM Rodney W. Grimes
> <4bone@gndrsh.dnsmgr.net>
> wrote:
>=20
> > I am finding myself in agreement with others, PS is the correct status.
> >
> > Thank you Neal for the good siting of RFC7127 with respect to PS,
> >
> > Regards,
> > Rod
> >
> > > On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
> > >  wrote:
> > > >
> > > > RACK is fundamental enough, subsumes TLP, and has enough
> > implementation and deployment. My vote is for PS status.
> > >
> > > Personally, I agree with Praveen, that "Proposed Standard" is
> > > appropriate, given my understanding of the definition from
> > > https://tools.ietf.org/html/rfc7127#section-3.1 :
> > >
> > >    3.1.  Characterization of IETF Proposed Standard Specifications
> > >    ...
> > >    A Proposed Standard specification is stable, has resolved known
> > >    design choices, has received significant community review, and
> > >    appears to enjoy enough community interest to be considered
> valuable.
> > >
> > >    Usually, neither implementation nor operational experience is
> > >    required for the designation of a specification as a Proposed
> > >    Standard.  However, such experience is highly desirable and will
> > >    usually represent a strong argument in favor of a Proposed Standar=
d
> > >    designation.
> > >
> > > There are several independent and very widely deployed
> > > implementations of RACK at this point.
> > >
> > > best regards,
> > > neal
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> >
> > --
> > Rod Grimes
> > rgrimes@freebsd.org
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>  5c28b/attachment.html>
>=20
> ------------------------------
>=20
> Subject: Digest Footer
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>=20
>=20
> ------------------------------
>=20
> End of tcpm Digest, Vol 187, Issue 64
> *************************************


From nobody Tue Nov 19 06:36:02 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 EB1E312092A for ; Tue, 19 Nov 2019 06:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.217
X-Spam-Level: 
X-Spam-Status: No, score=-1.217 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, MIME_QP_LONG_LINE=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 UH8DbNjCKoOZ for ; Tue, 19 Nov 2019 06:35:58 -0800 (PST)
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 B5928120934 for ; Tue, 19 Nov 2019 06:35:58 -0800 (PST)
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-Transfer-Encoding:Content-Type:Sender: Reply-To: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=h7cR+Xu9mbWLBEr+mruDs5y8/zI1nyL6Tqtd/cUZh98=; b=v/uaoEb0ZWIcCh0kjpREAJUG26 BG3bPwwQYeYXpnQ5odE2vSAZFvIzliQxnZ1/P8l0EYGYJzpLZXmBxo2XzWvNMi8SrVu5j/aN6pSdA RKzVaUJQf3wWsVEfaS1WiL0ZDBrEZfPOFiGr/mgC23a1/KnMs1agTBoLEcfEaaSX5b4fEh3lj6uyZ 7yevTGCfEju+1DNpKTKMf3btI6o2YGM/SRA+Qab+6otUYJ7E9PR7QdYsAty9v+Wj4pXHBkYyU3rT1 4GvKEsm/VQVk9sSUf8/cdcB3GgniQ/q85v2K1FAbKCQVoXBu99b22ju8L56X02V1Lyd45OJLSY4Yd PNYSpo+w==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60319 helo=[192.168.1.6]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iX4bg-001PBu-9y; Tue, 19 Nov 2019 09:35:57 -0500
Content-Type: multipart/alternative; boundary=Apple-Mail-98FCAA27-0B54-4EEC-8F7C-3169117F6055
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Joe Touch 
In-Reply-To: <78356B52-DF62-4FB9-BE5C-4E77E29615CE@ericsson.com>
Date: Tue, 19 Nov 2019 06:35:51 -0800
Cc: "tcpm@ietf.org" 
Message-Id: <86871EE9-13AA-4821-B603-AF2F68A01CF1@strayalpha.com>
References: <78356B52-DF62-4FB9-BE5C-4E77E29615CE@ericsson.com>
To: Mirja Kuehlewind 
X-Mailer: iPad Mail (17B102)
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] Fwd: New Version Notification for draft-kuehlewind-tcpm-flags-registry-00.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: Tue, 19 Nov 2019 14:36:01 -0000

--Apple-Mail-98FCAA27-0B54-4EEC-8F7C-3169117F6055
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I thought the point of the draft deadline was to prevent this sort of last m=
inute stuff, **especially** for 00 drafts.  Interesting to see the IESG doin=
g the end run.

Can we now stop this silly closure of the submission window, now that it **o=
fficially** isn=E2=80=99t relevant?

Joe

> On Nov 19, 2019, at 1:53 AM, Mirja Kuehlewind  wrote:
>=20
> =EF=BB=BF
> Hi everybody,
>=20
> I just submitted a short draft yesterday with a proposal to change the pol=
icy for the tcp flags registry. This proposal as well as other options are o=
n the agenda for discussion on Friday. But please have a look and if you hav=
e comments you can also of course provide them beforehand to the list!
>=20
> Thanks,
> Mirja
>=20
>=20
> Anfang der weitergeleiteten Nachricht:
>=20
>> Von: "internet-drafts@ietf.org" 
>> Datum: 18. November 2019 um 11:51:20 GMT+8
>> An: Mirja Kuehlewind 
>> Betreff: New Version Notification for draft-kuehlewind-tcpm-flags-registr=
y-00.txt
>>=20
>> =EF=BB=BF
>> A new version of I-D, draft-kuehlewind-tcpm-flags-registry-00.txt
>> has been successfully submitted by Mirja Kuehlewind and posted to the
>> IETF repository.
>>=20
>> Name:        draft-kuehlewind-tcpm-flags-registry
>> Revision:    00
>> Title:        Registration Policy for TCP Header Flags
>> Document date:    2019-11-18
>> Group:        Individual Submission
>> Pages:        5
>> URL:            https://www.ietf.org/internet-drafts/draft-kuehlewind-tcp=
m-flags-registry-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-fl=
ags-registry/
>> Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-tcpm-flags-r=
egistry-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-kuehlewind-tc=
pm-flags-registry
>>=20
>>=20
>> Abstract:
>>   RFC2780 specifies the registration policy for reserved TCP header
>>   flags as Standards Action.  RFC3168 created an IANA registry for
>>   these header flags and registered bit 8 (CWR) and 9 (ECE).  This
>>   draft changes the registration policy of the registration to IETF
>>   Review as usually new TCP mechanisms that could use the remaining
>>   reserved flags will be first specified as experimental.  Not noting
>>   any of those experiments in the registry would undermine the purpose
>>   of having a registry.  However, care must be taken, as only a few
>>   reserved flags are left and if a new (experimental) mechanism sees
>>   deployment in the Internet, the flag cannot be unassigned anymore or
>>   used for something else.
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of submiss=
ion
>> 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-98FCAA27-0B54-4EEC-8F7C-3169117F6055
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I thought the point of the=
 draft deadline was to prevent this sort of last minute stuff, **especially*=
* for 00 drafts.  Interesting to see the IESG doing the end run.
<=
div dir=3D"ltr">
Can we now stop this silly closur=
e of the submission window, now that it **officially** isn=E2=80=99t relevan=
t?

Joe

On Nov 19, 2019, at 1:53 AM, Mirja Kuehlewin=
d <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> wrote:

=EF=BB=BF
Hi everybody,

I just s=
ubmitted a short draft yesterday with a proposal to change the policy for th=
e tcp flags registry. This proposal as well as other options are on the agen=
da for discussion on Friday. But please have a look and if you have comments=
 you can also of course provide them beforehand to the list!

Thanks,
Mirja

=

Anfang der weitergeleiteten Nachricht:

Von: "internet-drafts@ietf.org" <internet-d=
rafts@ietf.org>
Datum: 18. November 2019 um 11:51:20 GMT+8
<=
b>An: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Betre=
ff: New Version Notification for draft-kuehlewind-tcpm-flags-registry=
-00.txt

=EF=BB=BF
A new version of I-D, draft-kuehlewind-=
tcpm-flags-registry-00.txt
has been successfully submitted b=
y Mirja Kuehlewind and posted to the
IETF repository.=


Name:        draft-kuehlewind=
-tcpm-flags-registry
Revision:    00
Title:        Registration Policy for TCP Header Flag=
s
Document date:    2019-11-18
Gro=
up:        Individual Submission
Pages: &=
nbsp;      5
URL:     &nb=
sp;      https://www.ietf.org/internet-drafts/=
draft-kuehlewind-tcpm-flags-registry-00.txt
Status:  &n=
bsp;      https://datatracker.ietf.org/doc/dra=
ft-kuehlewind-tcpm-flags-registry/
Htmlized:   &nb=
sp;   https://tools.ietf.org/html/draft-kuehlewind-tcpm-flags=
-registry-00
Htmlized:       h=
ttps://datatracker.ietf.org/doc/html/draft-kuehlewind-tcpm-flags-registry


Abstract:
 &=
nbsp; RFC2780 specifies the registration policy for reserved TCP header=

   flags as Standards Action.  RFC3168 creat=
ed an IANA registry for
   these header flags and r=
egistered bit 8 (CWR) and 9 (ECE).  This
   d=
raft changes the registration policy of the registration to IETF
<=
span>   Review as usually new TCP mechanisms that could use the re=
maining
   reserved flags will be first specified a=
s experimental.  Not noting
   any of those e=
xperiments in the registry would undermine the purpose
 &nbs=
p; of having a registry.  However, care must be taken, as only a f=
ew
   reserved flags are left and if a new (experi=
mental) mechanism sees
   deployment in the Intern=
et, the flag cannot be unassigned anymore or
   us=
ed for something else.




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

Th=
e IETF Secretariat

_____=
__________________________________________
tcpm mailing list=

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

--Apple-Mail-98FCAA27-0B54-4EEC-8F7C-3169117F6055--


From nobody Tue Nov 19 08:14: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 31FFA120967 for ; Tue, 19 Nov 2019 08:14:18 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 qh8Ajcwog2Eg for ; Tue, 19 Nov 2019 08:14:14 -0800 (PST)
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 F384712095C for ; Tue, 19 Nov 2019 08:14:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574180047; bh=QffuQtSSyO9YRpl5I2PF5RT8R8P9yp9c64DxJhhCp8o=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Z31m/Xmjp7t6uMkiQxsRS5vochmXh0CGGYT34alfp03zCh/4FQPzMSASWsYCAX2Wh y9q0sgVdFDi9nj5wnYKnTilrv4nI5pbnZ6n9pRaHB1PmCGq+taf4kbAP3eZXsUBkOm zGBgOau8XA+YclMkgiaU2kfLQ6pH+jboSnyOItNI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.20.8.66] ([202.55.67.146]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5VD8-1hngV231nm-016yQU; Tue, 19 Nov 2019 17:14:07 +0100
To: "Scharf, Michael" , tcpm IETF list 
References: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de>
From: "Scheffenegger, Richard" 
Message-ID: <7f68d961-c3d9-befa-c661-67656887a183@gmx.at>
Date: Wed, 20 Nov 2019 00:14:06 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Ou1SGg13/nqNYX/trBDMgsufkfA1rQOnEEnfXriTQ+V34NgEVaM M2T4DqxkzJqC3s3vre5JC4/q5Gf/cutSb/p8Jdg+yKpxJi3TItppTTAFq8eKRZv/VOG/DFu 8EpyYF7y1y5QUhzVzuMNTiZFYgrSfsvBgst7+w7OQFczGz7XbeHAdQo1OKUEQ/ceMKfrsgn EEXNbQOp/THhwtN5xay/g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dgANsed1+5I=:dndGXHF4YmkmUat2LpLBZu A9VAnGG0xJXMXzfD0Xdsbg8ndN4B6ezOt+1DKCh9XwCHuBumDO6Vw0oKvM8ylXnvIBxyqJPBZ Ch+0tF/vBPgDU4drT3iXwlSCmiHyCIeYdRJTVmietBxa2o96Dgtm7/gcO8wpBjM5uNdSdDAw8 TewLw+DWVjZMC/JYwcxAZowXuXsEipmU9C9pbO6ZuDrRWDgX7cjpgv9ko6klZncZARH4npHcH m2IWpGF19OoBFLHPzqPp8bQVuLv/U3MSp/LcX+M3IK9pDMcyhUIHEx6Phg2CyJ33ULigtZgYY IDlHlq3QBaT2KgBgQrnNI9W6sbWiGkWfdIdwV/QZHyvEU2KHbZbq40PCT4rplL7mNG4sheLEu qXAxHFSiEIp7RxEZvQaeONfvFH3j/2p+PF2dc43BIKhrRoIPKMDCj4DRTwwd3yHZGG+HuJDjL X7CLf+7WLdyLW0sEbk7UgH5iG/f56erAkdafZ8zTfQRD60HZa1Mvt8SzIpDnKs9HmFImYfLsR xU3kRWs8FQMrqeItDHOht5cfRDg0S3U6NUCv9dIjnOnMNTQ2MKFI8539/DoSQovlG9CR7aPyF wg3lxKaBq58zi7+cOoq8e0qVg+BhfR1d8Ehr6wXEHVKT1q7U/Fmck8/EzXKzYslGNuFlHE8Y/ QbCYmZQHHkY8tRV9BWZHrdHCnBFxa2GnINWFg5h9cabJxn4R2ugsn0TAqq53zkQje4VPT6+Kb Xl/K7LTs6zGqA1w5oD27WK1oJSGog0XGhdqx8f0pOOsN+Tdv1HCTv17XkmHfurIa9lfw63QxP QigfWhg5uajECKfuH+AZcFecud9MFSwT+RHhHvheCObAOg89Upuh8/89UPqnnjXxhiqGArqd8 ge1fcxS/cbeHT8bUvSV5H4oQHYI6a8MelyXRJEQ84dPLd2RrZaadiPgCuqckY0THlSCEvi1zd 6qCaWnXqxbwhJWMjGHBBqbHfTfdr2irMvzuVT0iHe+BkqRJ7DbCzo+HUoxQ6J8xygIJm4M1PM M0vUCiQs2KVreDDWu2zcl3ZodPd/msuMrZQEQTvpfyQTmr8PERuN7jizRdyl6W59k0txh2/mM +r1AHPI1cqWG6LXlfdaxNfzxHRK+MTgIbcNI+UTTYkhdDI3QDoRx2UIuMTcgu44nFd8o/pEKV fdRdB7lpzZUJukm91WBJHtRb0GoVaaM229kVYOzQxdwCw+ctSjFtNnwiAkUOQdIVWBHlHFRnm DWGWgGLAp0PXpSyfzONpv3k4nBk+UpE+cYgS3SA==
Archived-At: 
Subject: Re: [tcpm] Thoughts on EXP vs. PS in TCPM
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, 19 Nov 2019 16:14:18 -0000

Hi Michael,

while I agree with the two broad acceptance criterial you laid out for
EXP and PS, unless my recollection is wrong, at least for IW10 and TLS
at the time I wouldn't have seen them to pass the PS criteria.

However, as both of these mechansims were quite well understood, with a
good amount of discussion of unindended consequences (IW10), and a
limited impact if they would (unexpectedly) fail to meet their goal
(TLS), I believe the criterial for PS should actually slightly wider...

A change that is in a reasonably well defined space, with no
(forseeable) dramatic consequences to the operation of the tcp protocol
itself, could be allowed for PS even before multiple independent
implementations are available...

Alternatively (which is, what came to pass if I remeber correctly), the
status may need to be desided only very late in the process - if
additional implementations were in the works once the technical details
of a draft settled down.


Stiking a new balance in tcpm for the intended status seems to be in order=
.

Regards,
   Richard


Am 19.11.2019 um 13:08 schrieb Scharf, Michael:
> [chair hat off]
>
> In TCPM we repeatedly run into the question whether to publish specs as =
PS or as EXP. We also have several worked examples in which TCPM first pub=
lished a EXP RFC and later a PS.
>
> This somehow implies that TCPM often follows a process with three maturi=
ty levels (EXP, PS, and Internet Standard), while the IETF actually has tw=
o maturity levels (see RFC 6410). Formal definitions are:
> * EXP in https://tools.ietf.org/html/rfc2026#section-4.2.1
> * PS in https://tools.ietf.org/html/rfc7127#section-3.1
> * Internet Standard in https://tools.ietf.org/html/rfc6410
>
> As questions on EXP and PS emerges repeatedly, I think it would be usefu=
l to discuss two questions:
>
> 1/ What is the minimum requirement for publishing an EXP RFC in TCPM?
>
> 2/ What is the minimum requirement for publishing an PS RFC in TCPM?
>
> I have been thinking myself about these questions quite a bit, most nota=
bly since I have recently also worked in working groups outside TSV (such =
as RTG and OPS). As far as I can tell, other IETF working groups don't mak=
e use of EXP as frequently as TCPM. In many working groups PS is the norm.
>
> I start to get worried by that. At the end of the day, the IETF is one s=
tandardization organization and TCPM documents matter also to other areas =
of the IETF, as well as the networking industry as a whole. So, TCPM does =
not operate in isolation.
>
> Of course, I am partly accountable for that, given that I have run sever=
al consensus calls on the target status of RFCs in the last years. I think=
 the community feedback was pretty clear in all these cases, typically in =
favor of EXP instead of PS. Yet, after more insight in the rest of the IET=
F, I wonder if maybe TCPM sometimes decides to early to go for EXP if PS i=
s actually possible?
>
> For instance, as individual contributor, I believe that IW10 and TLP cou=
ld fulfill the PS requirements now. And, in retrospective, I think they we=
re not far away from PS at the time of publication. So, in some sense, TCP=
M has been very careful and conservative when publishing these RFCs. This =
now implies that we would have to reissue a PS to actually clean up the RF=
C services.
>
> Given that other working groups apparently operate differently regarding=
 PS as target, do we need to rethink our minimum bars?
>
> I believe that it would be useful to discuss this question, and I'd be i=
n particular interested in the opinions of implementers.
>
> As a starting point, I offer my own understanding of how to answer the t=
wo questions - with chair hat off. So, feel free to disagree... Of course,=
 a case-by-case analysis is always needed, so this is not really a checkli=
st, but I guess we should have some general understanding of what "maturit=
y" really implies.
>
> Michael's thought on question 1/:
>
> In order to start a WGLC in TCPM for EXP status, there SHOULD be one imp=
lementation in the main source code tree of an important TCP/IP stack; a d=
efault to "off" is perfectly acceptable. Alternatively, there SHOULD be at=
 least one implementation outside the main tree and a certain level of ope=
rational experience e.g. in very controlled environments. Comprehensive te=
sting by simulation can also be understood as operational experience if th=
e simulation results are verified independently. (As example, the converte=
r specification meets this requirement in my point of view.)
>
> Note that this requirement is significantly higher than what is written =
in RFC 2026 - in principle, thousands of research papers on TCP could meet=
 the EXP requirement of RFC 2026. But, at least to me, there is little val=
ue in documenting an experiment without proof that it is actually implemen=
table in a TCP stack.
>
> Michael's thought on question 2/:
>
> The requirement follows from RFC 7127, which strongly suggests implement=
ation and operational experience, but it is not strictly required. So, the=
re is some room for interpretation. The bar for PS is _not_ widespread dep=
loyment in the Internet. For instance, to me a WGLC for an PS could be sta=
rted if there are two independent implementations, at least one being depl=
oyed in an important TCP stack (i.e., one does not have to be production q=
uality), and some operational experience over a subset of the Internet. Fo=
r instance, such operational experience can also be tests, it does not req=
uire enabling by default. (As example, RACK easily meets these requirement=
s as far as I understand.)
>
> Note that with two independent implementations one gets already relative=
ly close to the requirements of an Internet Standard, but in that case als=
o widespread deployment and some other conditions are required (see RFC 64=
10). So, the bar for PS must be lower than that.
>
> Please feel free to comment and/or disagree...
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


From nobody Tue Nov 19 11:35: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 9666312029C for ; Tue, 19 Nov 2019 11:35:27 -0800 (PST)
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 Cf1NfB8OGaZM for ; Tue, 19 Nov 2019 11:35:25 -0800 (PST)
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 A4589120074 for ; Tue, 19 Nov 2019 11:35:24 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id EA10925A15; Tue, 19 Nov 2019 20:35:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1574192122; bh=PUW0qj2A8kDjn4tkao/RY9Wt9PMd4l92RdJfNk0qXBg=; h=From:To:Subject:Date:References:In-Reply-To:From; b=M43z7H6+DCl7Cl2z5eCsXm6CDHSyCHdvbcIn5dJf4v6wiAspStEv5jTBLmQ7eJQxW K/rzMS2IaTiAP/bB0FxtLUPIF44ZM9ie/6pf7QBwVyRc+2Wr101G1hl6dVD/Oj0RJZ ibkdPqwYLlmFq/SHbJyNo2IpMg9Dg5PcFRd6JTSk=
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 fPRLkUngsVfi; Tue, 19 Nov 2019 20:35:21 +0100 (CET)
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; Tue, 19 Nov 2019 20:35:21 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Tue, 19 Nov 2019 20:35:21 +0100
From: "Scharf, Michael" 
To: "Scheffenegger, Richard" , tcpm IETF list 
Thread-Topic: [tcpm] Thoughts on EXP vs. PS in TCPM
Thread-Index: AdWew5FU19VWLf+AS/Gv7aHLLJwOLgAKGqwAAAffsYA=
Date: Tue, 19 Nov 2019 19:35:21 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D51CD85@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de> <7f68d961-c3d9-befa-c661-67656887a183@gmx.at>
In-Reply-To: <7f68d961-c3d9-befa-c661-67656887a183@gmx.at>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.63.14]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Thoughts on EXP vs. PS in TCPM
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, 19 Nov 2019 19:35:28 -0000

PiBIaSBNaWNoYWVsLA0KPiANCj4gd2hpbGUgSSBhZ3JlZSB3aXRoIHRoZSB0d28gYnJvYWQgYWNj
ZXB0YW5jZSBjcml0ZXJpYWwgeW91IGxhaWQgb3V0IGZvcg0KPiBFWFAgYW5kIFBTLCB1bmxlc3Mg
bXkgcmVjb2xsZWN0aW9uIGlzIHdyb25nLCBhdCBsZWFzdCBmb3IgSVcxMCBhbmQgVExTDQo+IGF0
IHRoZSB0aW1lIEkgd291bGRuJ3QgaGF2ZSBzZWVuIHRoZW0gdG8gcGFzcyB0aGUgUFMgY3JpdGVy
aWEuDQoNClllcywgdGhlIElFVEYgY29uc2Vuc3VzIHdhcyB0aGF0IElXMTAgYW5kIFRGTyAod2hp
Y2ggSSB3YW50ZWQgdG8gd3JpdGUpIGRpZG4ndCBwYXNzIHRoZSBQUyBjcml0ZXJpYS4gSSBkb24n
dCB3YW50IHRvIHJldmlzaXQgdGhpcy4gTXkgcG9pbnQgaXMgd2hhdCB0byBkbyBpbiBmdXR1cmUg
aW4gYW4gSUVURiB0aGF0IHB1Ymxpc2hlcyBtYW55IFBTIGRvY3VtZW50cy4uLg0KIA0KPiBIb3dl
dmVyLCBhcyBib3RoIG9mIHRoZXNlIG1lY2hhbnNpbXMgd2VyZSBxdWl0ZSB3ZWxsIHVuZGVyc3Rv
b2QsIHdpdGggYQ0KPiBnb29kIGFtb3VudCBvZiBkaXNjdXNzaW9uIG9mIHVuaW5kZW5kZWQgY29u
c2VxdWVuY2VzIChJVzEwKSwgYW5kIGENCj4gbGltaXRlZCBpbXBhY3QgaWYgdGhleSB3b3VsZCAo
dW5leHBlY3RlZGx5KSBmYWlsIHRvIG1lZXQgdGhlaXIgZ29hbA0KPiAoVExTKSwgSSBiZWxpZXZl
IHRoZSBjcml0ZXJpYWwgZm9yIFBTIHNob3VsZCBhY3R1YWxseSBzbGlnaHRseSB3aWRlci4uLg0K
PiANCj4gQSBjaGFuZ2UgdGhhdCBpcyBpbiBhIHJlYXNvbmFibHkgd2VsbCBkZWZpbmVkIHNwYWNl
LCB3aXRoIG5vDQo+IChmb3JzZWVhYmxlKSBkcmFtYXRpYyBjb25zZXF1ZW5jZXMgdG8gdGhlIG9w
ZXJhdGlvbiBvZiB0aGUgdGNwIHByb3RvY29sDQo+IGl0c2VsZiwgY291bGQgYmUgYWxsb3dlZCBm
b3IgUFMgZXZlbiBiZWZvcmUgbXVsdGlwbGUgaW5kZXBlbmRlbnQNCj4gaW1wbGVtZW50YXRpb25z
IGFyZSBhdmFpbGFibGUuLi4NCg0KSSBhZ3JlZSB0aGF0IGZvciByZWxhdGl2ZWx5IHN0cmFpZ2h0
Zm9yd2FyZCBUQ1AgY2hhbmdlcyB3ZSBjb3VsZCBwb3NzaWJseSBwdWJsaXNoIGEgUFMgZXZlbiB3
aXRoIGEgc2luZ2xlIGltcGxlbWVudGF0aW9uLiBJdCBtYXkgYmUgYSBjYXNlLWJ5LWNhc2UgZGVj
aXNpb24sIGFuZCBwb3NzaWJseSB3ZSB3b3VsZCBoYXZlIHRvIHByZWNpc2VseSBkZWZpbmUgZm9y
IHdoaWNoIHdlbGwtZGVmaW5lZCBzcGFjZSBzdWNoIGEgUFMgaXMgYXBwbGljYWJsZS4gQnV0LCB0
aGUgSUVURiBtYW5kYXRlcyB0d28gaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIGZvciBJbnRl
cm5ldCBTdGFuZGFyZCwgbm90IGZvciBQUy4gU28sIGluIHByaW5jaXBsZSBub3RoaW5nIHByZXZl
bnRzIHVzIGZyb20gYXQgbGVhc3QgdHJ5aW5nIFBTIHN0YXR1cyBpZiB0aGVyZSBpcyBhIHdheSB0
byByZWFzb24gd2h5IHRoZSByZXF1aXJlbWVudHMgaW4gUkZDIDcxMjcgYXJlIGZ1bGZpbGxlZC4N
CiANCj4gQWx0ZXJuYXRpdmVseSAod2hpY2ggaXMsIHdoYXQgY2FtZSB0byBwYXNzIGlmIEkgcmVt
ZWJlciBjb3JyZWN0bHkpLCB0aGUNCj4gc3RhdHVzIG1heSBuZWVkIHRvIGJlIGRlc2lkZWQgb25s
eSB2ZXJ5IGxhdGUgaW4gdGhlIHByb2Nlc3MgLSBpZg0KPiBhZGRpdGlvbmFsIGltcGxlbWVudGF0
aW9ucyB3ZXJlIGluIHRoZSB3b3JrcyBvbmNlIHRoZSB0ZWNobmljYWwgZGV0YWlscw0KPiBvZiBh
IGRyYWZ0IHNldHRsZWQgZG93bi4NCg0KSW5kZWVkLCB3ZSBkaXNjdXNzZWQgdGhpcyB2YXJpYW50
IGluIGEgbnVtYmVyIG9mIGNhc2VzLg0KDQpJbiBUQ1BNLCBvdXIgZGVmYXVsdCB3YXMgb2Z0ZW4g
RVhQIGFzIHRhcmdldCwgaW4gcGFydGljdWxhciBpZiB0aGVyZSB3ZXJlIHVua25vd25zIGF0IFdH
IGFkb3B0aW9uIHRpbWUuIEJ1dCBJTUhPIHdlIHNob3VsZCBhc2sgb3Vyc2VsdmVzIGlmIHdlIHNo
b3VsZCBtb3JlIGZyZXF1ZW50bHkgX3RyeV8gdG8gcHJvZHVjZSBhIFBTLiBPZiBjb3Vyc2UsIGlm
IHRoYXQgaXMgbm90IHBvc3NpYmxlIG9yIG5vdCBwb3NzaWJsZSBpbiBhIHRpbWVseSBmYXNoaW9u
LCBkb3duZ3JhZGUgdG8gRVhQIGxhdGVyIGluIHRoZSBwcm9jZXNzIGlzIGFsd2F5cyBwb3NzaWJs
ZS4gQnV0IGF0IHRoZSBlbmQgb2YgdGhlIGRheSBJRVRGIGlzIGEgc3RhbmRhcmRpemF0aW9uIG9y
Z2FuaXphdGlvbiAtIHNvIHdlIGFyZSBhc3N1bWVkIHRvIHdyaXRlIHN0YW5kYXJkcywgbm8/DQoN
CldoZXRoZXIgbW9yZSBQUyBzcGVjcyBhcmUgZG9hYmxlIGluIFRDUE0gaXMgbm90IGEgdHJpdmlh
bCBxdWVzdGlvbi4gWWV0LCBJIGJlbGlldmUgd2Ugc2hvdWxkIHRoaW5rIGFib3V0IHRoYXQuDQoN
Ck1pY2hhZWwNCg0KDQo+IFN0aWtpbmcgYSBuZXcgYmFsYW5jZSBpbiB0Y3BtIGZvciB0aGUgaW50
ZW5kZWQgc3RhdHVzIHNlZW1zIHRvIGJlIGluIG9yZGVyLg0KPiANCj4gUmVnYXJkcywNCj4gICAg
UmljaGFyZA0KPiANCj4gDQo+IEFtIDE5LjExLjIwMTkgdW0gMTM6MDggc2NocmllYiBTY2hhcmYs
IE1pY2hhZWw6DQo+ID4gW2NoYWlyIGhhdCBvZmZdDQo+ID4NCj4gPiBJbiBUQ1BNIHdlIHJlcGVh
dGVkbHkgcnVuIGludG8gdGhlIHF1ZXN0aW9uIHdoZXRoZXIgdG8gcHVibGlzaCBzcGVjcyBhcyBQ
Uw0KPiBvciBhcyBFWFAuIFdlIGFsc28gaGF2ZSBzZXZlcmFsIHdvcmtlZCBleGFtcGxlcyBpbiB3
aGljaCBUQ1BNIGZpcnN0DQo+IHB1Ymxpc2hlZCBhIEVYUCBSRkMgYW5kIGxhdGVyIGEgUFMuDQo+
ID4NCj4gPiBUaGlzIHNvbWVob3cgaW1wbGllcyB0aGF0IFRDUE0gb2Z0ZW4gZm9sbG93cyBhIHBy
b2Nlc3Mgd2l0aCB0aHJlZSBtYXR1cml0eQ0KPiBsZXZlbHMgKEVYUCwgUFMsIGFuZCBJbnRlcm5l
dCBTdGFuZGFyZCksIHdoaWxlIHRoZSBJRVRGIGFjdHVhbGx5IGhhcyB0d28gbWF0dXJpdHkNCj4g
bGV2ZWxzIChzZWUgUkZDIDY0MTApLiBGb3JtYWwgZGVmaW5pdGlvbnMgYXJlOg0KPiA+ICogRVhQ
IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMDI2I3NlY3Rpb24tNC4yLjENCj4g
PiAqIFBTIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTI3I3NlY3Rpb24tMy4x
DQo+ID4gKiBJbnRlcm5ldCBTdGFuZGFyZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
cmZjNjQxMA0KPiA+DQo+ID4gQXMgcXVlc3Rpb25zIG9uIEVYUCBhbmQgUFMgZW1lcmdlcyByZXBl
YXRlZGx5LCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0bw0KPiBkaXNjdXNzIHR3byBxdWVz
dGlvbnM6DQo+ID4NCj4gPiAxLyBXaGF0IGlzIHRoZSBtaW5pbXVtIHJlcXVpcmVtZW50IGZvciBw
dWJsaXNoaW5nIGFuIEVYUCBSRkMgaW4gVENQTT8NCj4gPg0KPiA+IDIvIFdoYXQgaXMgdGhlIG1p
bmltdW0gcmVxdWlyZW1lbnQgZm9yIHB1Ymxpc2hpbmcgYW4gUFMgUkZDIGluIFRDUE0/DQo+ID4N
Cj4gPiBJIGhhdmUgYmVlbiB0aGlua2luZyBteXNlbGYgYWJvdXQgdGhlc2UgcXVlc3Rpb25zIHF1
aXRlIGEgYml0LCBtb3N0IG5vdGFibHkNCj4gc2luY2UgSSBoYXZlIHJlY2VudGx5IGFsc28gd29y
a2VkIGluIHdvcmtpbmcgZ3JvdXBzIG91dHNpZGUgVFNWIChzdWNoIGFzIFJURw0KPiBhbmQgT1BT
KS4gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIG90aGVyIElFVEYgd29ya2luZyBncm91cHMgZG9uJ3Qg
bWFrZSB1c2Ugb2YgRVhQDQo+IGFzIGZyZXF1ZW50bHkgYXMgVENQTS4gSW4gbWFueSB3b3JraW5n
IGdyb3VwcyBQUyBpcyB0aGUgbm9ybS4NCj4gPg0KPiA+IEkgc3RhcnQgdG8gZ2V0IHdvcnJpZWQg
YnkgdGhhdC4gQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB0aGUgSUVURiBpcyBvbmUNCj4gc3RhbmRh
cmRpemF0aW9uIG9yZ2FuaXphdGlvbiBhbmQgVENQTSBkb2N1bWVudHMgbWF0dGVyIGFsc28gdG8g
b3RoZXIgYXJlYXMNCj4gb2YgdGhlIElFVEYsIGFzIHdlbGwgYXMgdGhlIG5ldHdvcmtpbmcgaW5k
dXN0cnkgYXMgYSB3aG9sZS4gU28sIFRDUE0gZG9lcyBub3QNCj4gb3BlcmF0ZSBpbiBpc29sYXRp
b24uDQo+ID4NCj4gPiBPZiBjb3Vyc2UsIEkgYW0gcGFydGx5IGFjY291bnRhYmxlIGZvciB0aGF0
LCBnaXZlbiB0aGF0IEkgaGF2ZSBydW4gc2V2ZXJhbA0KPiBjb25zZW5zdXMgY2FsbHMgb24gdGhl
IHRhcmdldCBzdGF0dXMgb2YgUkZDcyBpbiB0aGUgbGFzdCB5ZWFycy4gSSB0aGluayB0aGUNCj4g
Y29tbXVuaXR5IGZlZWRiYWNrIHdhcyBwcmV0dHkgY2xlYXIgaW4gYWxsIHRoZXNlIGNhc2VzLCB0
eXBpY2FsbHkgaW4gZmF2b3Igb2YNCj4gRVhQIGluc3RlYWQgb2YgUFMuIFlldCwgYWZ0ZXIgbW9y
ZSBpbnNpZ2h0IGluIHRoZSByZXN0IG9mIHRoZSBJRVRGLCBJIHdvbmRlciBpZg0KPiBtYXliZSBU
Q1BNIHNvbWV0aW1lcyBkZWNpZGVzIHRvIGVhcmx5IHRvIGdvIGZvciBFWFAgaWYgUFMgaXMgYWN0
dWFsbHkNCj4gcG9zc2libGU/DQo+ID4NCj4gPiBGb3IgaW5zdGFuY2UsIGFzIGluZGl2aWR1YWwg
Y29udHJpYnV0b3IsIEkgYmVsaWV2ZSB0aGF0IElXMTAgYW5kIFRMUCBjb3VsZA0KPiBmdWxmaWxs
IHRoZSBQUyByZXF1aXJlbWVudHMgbm93LiBBbmQsIGluIHJldHJvc3BlY3RpdmUsIEkgdGhpbmsg
dGhleSB3ZXJlIG5vdCBmYXINCj4gYXdheSBmcm9tIFBTIGF0IHRoZSB0aW1lIG9mIHB1YmxpY2F0
aW9uLiBTbywgaW4gc29tZSBzZW5zZSwgVENQTSBoYXMgYmVlbg0KPiB2ZXJ5IGNhcmVmdWwgYW5k
IGNvbnNlcnZhdGl2ZSB3aGVuIHB1Ymxpc2hpbmcgdGhlc2UgUkZDcy4gVGhpcyBub3cgaW1wbGll
cw0KPiB0aGF0IHdlIHdvdWxkIGhhdmUgdG8gcmVpc3N1ZSBhIFBTIHRvIGFjdHVhbGx5IGNsZWFu
IHVwIHRoZSBSRkMgc2VydmljZXMuDQo+ID4NCj4gPiBHaXZlbiB0aGF0IG90aGVyIHdvcmtpbmcg
Z3JvdXBzIGFwcGFyZW50bHkgb3BlcmF0ZSBkaWZmZXJlbnRseSByZWdhcmRpbmcgUFMNCj4gYXMg
dGFyZ2V0LCBkbyB3ZSBuZWVkIHRvIHJldGhpbmsgb3VyIG1pbmltdW0gYmFycz8NCj4gPg0KPiA+
IEkgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBkaXNjdXNzIHRoaXMgcXVlc3Rp
b24sIGFuZCBJJ2QgYmUgaW4NCj4gcGFydGljdWxhciBpbnRlcmVzdGVkIGluIHRoZSBvcGluaW9u
cyBvZiBpbXBsZW1lbnRlcnMuDQo+ID4NCj4gPiBBcyBhIHN0YXJ0aW5nIHBvaW50LCBJIG9mZmVy
IG15IG93biB1bmRlcnN0YW5kaW5nIG9mIGhvdyB0byBhbnN3ZXIgdGhlIHR3bw0KPiBxdWVzdGlv
bnMgLSB3aXRoIGNoYWlyIGhhdCBvZmYuIFNvLCBmZWVsIGZyZWUgdG8gZGlzYWdyZWUuLi4gT2Yg
Y291cnNlLCBhIGNhc2UtYnktDQo+IGNhc2UgYW5hbHlzaXMgaXMgYWx3YXlzIG5lZWRlZCwgc28g
dGhpcyBpcyBub3QgcmVhbGx5IGEgY2hlY2tsaXN0LCBidXQgSSBndWVzcyB3ZQ0KPiBzaG91bGQg
aGF2ZSBzb21lIGdlbmVyYWwgdW5kZXJzdGFuZGluZyBvZiB3aGF0ICJtYXR1cml0eSIgcmVhbGx5
IGltcGxpZXMuDQo+ID4NCj4gPiBNaWNoYWVsJ3MgdGhvdWdodCBvbiBxdWVzdGlvbiAxLzoNCj4g
Pg0KPiA+IEluIG9yZGVyIHRvIHN0YXJ0IGEgV0dMQyBpbiBUQ1BNIGZvciBFWFAgc3RhdHVzLCB0
aGVyZSBTSE9VTEQgYmUgb25lDQo+IGltcGxlbWVudGF0aW9uIGluIHRoZSBtYWluIHNvdXJjZSBj
b2RlIHRyZWUgb2YgYW4gaW1wb3J0YW50IFRDUC9JUCBzdGFjazsgYQ0KPiBkZWZhdWx0IHRvICJv
ZmYiIGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlLiBBbHRlcm5hdGl2ZWx5LCB0aGVyZSBTSE9VTEQg
YmUgYXQgbGVhc3QNCj4gb25lIGltcGxlbWVudGF0aW9uIG91dHNpZGUgdGhlIG1haW4gdHJlZSBh
bmQgYSBjZXJ0YWluIGxldmVsIG9mIG9wZXJhdGlvbmFsDQo+IGV4cGVyaWVuY2UgZS5nLiBpbiB2
ZXJ5IGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzLiBDb21wcmVoZW5zaXZlIHRlc3RpbmcgYnkNCj4g
c2ltdWxhdGlvbiBjYW4gYWxzbyBiZSB1bmRlcnN0b29kIGFzIG9wZXJhdGlvbmFsIGV4cGVyaWVu
Y2UgaWYgdGhlIHNpbXVsYXRpb24NCj4gcmVzdWx0cyBhcmUgdmVyaWZpZWQgaW5kZXBlbmRlbnRs
eS4gKEFzIGV4YW1wbGUsIHRoZSBjb252ZXJ0ZXIgc3BlY2lmaWNhdGlvbg0KPiBtZWV0cyB0aGlz
IHJlcXVpcmVtZW50IGluIG15IHBvaW50IG9mIHZpZXcuKQ0KPiA+DQo+ID4gTm90ZSB0aGF0IHRo
aXMgcmVxdWlyZW1lbnQgaXMgc2lnbmlmaWNhbnRseSBoaWdoZXIgdGhhbiB3aGF0IGlzIHdyaXR0
ZW4gaW4gUkZDDQo+IDIwMjYgLSBpbiBwcmluY2lwbGUsIHRob3VzYW5kcyBvZiByZXNlYXJjaCBw
YXBlcnMgb24gVENQIGNvdWxkIG1lZXQgdGhlIEVYUA0KPiByZXF1aXJlbWVudCBvZiBSRkMgMjAy
Ni4gQnV0LCBhdCBsZWFzdCB0byBtZSwgdGhlcmUgaXMgbGl0dGxlIHZhbHVlIGluDQo+IGRvY3Vt
ZW50aW5nIGFuIGV4cGVyaW1lbnQgd2l0aG91dCBwcm9vZiB0aGF0IGl0IGlzIGFjdHVhbGx5IGlt
cGxlbWVudGFibGUgaW4gYQ0KPiBUQ1Agc3RhY2suDQo+ID4NCj4gPiBNaWNoYWVsJ3MgdGhvdWdo
dCBvbiBxdWVzdGlvbiAyLzoNCj4gPg0KPiA+IFRoZSByZXF1aXJlbWVudCBmb2xsb3dzIGZyb20g
UkZDIDcxMjcsIHdoaWNoIHN0cm9uZ2x5IHN1Z2dlc3RzDQo+IGltcGxlbWVudGF0aW9uIGFuZCBv
cGVyYXRpb25hbCBleHBlcmllbmNlLCBidXQgaXQgaXMgbm90IHN0cmljdGx5IHJlcXVpcmVkLiBT
bywNCj4gdGhlcmUgaXMgc29tZSByb29tIGZvciBpbnRlcnByZXRhdGlvbi4gVGhlIGJhciBmb3Ig
UFMgaXMgX25vdF8gd2lkZXNwcmVhZA0KPiBkZXBsb3ltZW50IGluIHRoZSBJbnRlcm5ldC4gRm9y
IGluc3RhbmNlLCB0byBtZSBhIFdHTEMgZm9yIGFuIFBTIGNvdWxkIGJlDQo+IHN0YXJ0ZWQgaWYg
dGhlcmUgYXJlIHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMsIGF0IGxlYXN0IG9uZSBi
ZWluZw0KPiBkZXBsb3llZCBpbiBhbiBpbXBvcnRhbnQgVENQIHN0YWNrIChpLmUuLCBvbmUgZG9l
cyBub3QgaGF2ZSB0byBiZSBwcm9kdWN0aW9uDQo+IHF1YWxpdHkpLCBhbmQgc29tZSBvcGVyYXRp
b25hbCBleHBlcmllbmNlIG92ZXIgYSBzdWJzZXQgb2YgdGhlIEludGVybmV0LiBGb3INCj4gaW5z
dGFuY2UsIHN1Y2ggb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBjYW4gYWxzbyBiZSB0ZXN0cywgaXQg
ZG9lcyBub3QgcmVxdWlyZQ0KPiBlbmFibGluZyBieSBkZWZhdWx0LiAoQXMgZXhhbXBsZSwgUkFD
SyBlYXNpbHkgbWVldHMgdGhlc2UgcmVxdWlyZW1lbnRzIGFzIGZhcg0KPiBhcyBJIHVuZGVyc3Rh
bmQuKQ0KPiA+DQo+ID4gTm90ZSB0aGF0IHdpdGggdHdvIGluZGVwZW5kZW50IGltcGxlbWVudGF0
aW9ucyBvbmUgZ2V0cyBhbHJlYWR5IHJlbGF0aXZlbHkNCj4gY2xvc2UgdG8gdGhlIHJlcXVpcmVt
ZW50cyBvZiBhbiBJbnRlcm5ldCBTdGFuZGFyZCwgYnV0IGluIHRoYXQgY2FzZSBhbHNvDQo+IHdp
ZGVzcHJlYWQgZGVwbG95bWVudCBhbmQgc29tZSBvdGhlciBjb25kaXRpb25zIGFyZSByZXF1aXJl
ZCAoc2VlIFJGQw0KPiA2NDEwKS4gU28sIHRoZSBiYXIgZm9yIFBTIG11c3QgYmUgbG93ZXIgdGhh
biB0aGF0Lg0KPiA+DQo+ID4gUGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50IGFuZC9vciBkaXNh
Z3JlZS4uLg0KPiA+DQo+ID4gTWljaGFlbA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+IHRj
cG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rj
cG0NCj4gPg0K


From nobody Tue Nov 19 15:15: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 9061C1208AC; Tue, 19 Nov 2019 15:15:06 -0800 (PST)
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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kau.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 5GaxFPM5RTtH; Tue, 19 Nov 2019 15:15:04 -0800 (PST)
Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A8120090; Tue, 19 Nov 2019 15:15:03 -0800 (PST)
Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [192.36.171.202]) by smtp1.kau.se (Postfix) with ESMTP id 0175B1802132; Wed, 20 Nov 2019 00:15:00 +0100 (CET)
Received: from Exch-A3.personal.kau (exch-a3.kau.se [130.243.19.84]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAJNExh6077307 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Nov 2019 00:14:59 +0100
Received: from Exch-A1.personal.kau (130.243.19.82) by Exch-A3.personal.kau (130.243.19.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1847.3; Wed, 20 Nov 2019 00:14:47 +0100
Received: from Exch-A1.personal.kau ([fe80::7862:a3d3:1cba:9754]) by Exch-A1.personal.kau ([fe80::7862:a3d3:1cba:9754%2]) with mapi id 15.01.1847.003; Wed, 20 Nov 2019 00:14:59 +0100
From: =?iso-8859-1?Q?Anna_Brunstr=F6m?= 
To: Bob Briscoe , tsvwg IETF list , iccrg IRTF list , tcpm IETF list 
Thread-Topic: [iccrg] TCP Prague Update: L4S-related Side Meeting at IETF-106
Thread-Index: AQHVnbsxaa+bQbVUQ0WOvdkVe58VQKeTIXBQ
Date: Tue, 19 Nov 2019 23:14:59 +0000
Message-ID: 
References: <22773cc0-f28a-0cd2-8265-a559f427ff8d@bobbriscoe.net>
In-Reply-To: <22773cc0-f28a-0cd2-8265-a559f427ff8d@bobbriscoe.net>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.243.27.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-kau-se:default,  kau-se:default, base:default, @@RPTN)
X-p0f-Info: os=Windows 7 or 8, link=Ethernet or modem
X-CanIt-Geo: No geolocation information available for fe80::7862:a3d3:1cba:9754
X-CanItPRO-Stream: outbound-kau-se:outbound (inherits from outbound-kau-se:default, kau-se:default, base:default)
X-Canit-Stats-ID: 0a1rXeXm8 - 08731c58746e - 20191120
X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?c=f&i=0a1rXeXm8&m=08731c58746e&rlm=outbound-kau-se&t=20191120
X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?c=n&i=0a1rXeXm8&m=08731c58746e&rlm=outbound-kau-se&t=20191120
X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?c=p&i=0a1rXeXm8&m=08731c58746e&rlm=outbound-kau-se&t=20191120
X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?c=s&i=0a1rXeXm8&m=08731c58746e&rlm=outbound-kau-se&t=20191120
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kau.se; h=from:to :subject:date:message-id:references:in-reply-to:content-type :content-transfer-encoding:mime-version; s=canit; bh=YTSNFObWCpc BiZLJ839LJhrr1ZJb8Xg6lp9euoL+U0c=; b=tguETToGQz+aRTJykKTqkqKJ1i+ SMDjDbuDIgtAt82GO+lHEkBI+liVaJcbzdrYxAOoMtLRn0mMZApk+CY/L3bs5DMf /9FC/suUwlXG2CGSWUKLNilQ1zQbYYr7G1/c+uGJA4n7bl7V7JIHPxmakrvpO6/v bzJuGyjRJ484KuMnVsUhPdpzDpDdwGS9Fpmkh1Yy05aYew8RqATsQHwB2pd/k3BN PryQPd9+ftcTXSO6mr8kwW5PmN0uBfZsWlQw0WxThFXRlW2xdvtV/FhmxKtwDePS lVRkqymAC+KS+iBTJ0eWCyEOiMVimcXys5xgZkf6uY7KB8qsLaxFeyxLr4A==
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: 
Subject: Re: [tcpm] [iccrg] TCP Prague Update: L4S-related Side Meeting at IETF-106
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, 19 Nov 2019 23:15:07 -0000

Hi Bob,

Thanks for arranging for remote participation. Do you also plan to record t=
he zoom session? Time zones are a bit challenging :-)

Regards,
Anna

-----Original Message-----
From: iccrg  On Behalf Of Bob Briscoe
Sent: den 18 november 2019 03:52
To: tsvwg IETF list ; iccrg IRTF list ; tcp=
m IETF list 
Subject: [iccrg] TCP Prague Update: L4S-related Side Meeting at IETF-106

Folks,

The significant amount of TCP Prague update material was too great for the =
iccrg agenda.
So, with the help of the iccrg and tsvwg chairs (thank you), we've arranged=
 a side meeting to cover all this.

=3D=3DWhere/when?=3D=3D
Date: Thu 21 Nov 2019
Time: 08:30 - 09:30
Room: Canning

=3D=3DAgenda=3D=3D
http://bobbriscoe.net/projects/latency/TCP_Prague_side-meetingAgendaIETF-10=
6.html

=3D=3DMeeting Materials=3D=3D
Links to meeting materials will be added to the above agenda soon.
They will also be added to the tsvwg meeting materials.

=3D=3DRemote Attendance=3D=3D
Meetecho is not available for side-meetings, so we're arranging an alternat=
ive, prob Zoom (link will appear on agenda)

Regards


Bob


--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg


From nobody Tue Nov 19 19:07:55 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 E20931201E0; Tue, 19 Nov 2019 19:07:48 -0800 (PST)
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.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <157421926885.5272.18152361528567835349@ietfa.amsl.com>
Date: Tue, 19 Nov 2019 19:07:48 -0800
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-01.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: Wed, 20 Nov 2019 03:07:49 -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           : TCP Control Block Interdependence
        Authors         : Joe Touch
                          Michael Welzl
                          Safiqul Islam
	Filename        : draft-ietf-tcpm-2140bis-01.txt
	Pages           : 30
	Date            : 2019-11-19

Abstract:
   This memo provides guidance to TCP implementers that are intended to
   help improve convergence to steady-state operation without affecting
   interoperability. It updates and replaces RFC 2140's description of
   interdependent TCP control blocks and the ways that part of TCP
   state can be shared among similar concurrent or consecutive
   connections. TCP state includes a combination of parameters, such as
   connection state, current round-trip time estimates, congestion
   control information, and process information. Most of this state is
   maintained on a per-connection basis in the TCP Control Block (TCB),
   but implementations can (and do) share certain TCB information
   across connections to the same host. Such sharing is intended to
   improve overall transient transport performance, while maintaining
   backward-compatibility with existing implementations. The sharing
   described herein is limited to only the TCB initialization and so
   has no effect on the long-term behavior of TCP after a connection
   has been established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-01
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-01


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 Tue Nov 19 19:26:25 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 8C32812023E for ; Tue, 19 Nov 2019 19:26:24 -0800 (PST)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 k4nGBL_SKXIe for ; Tue, 19 Nov 2019 19:26:23 -0800 (PST)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.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 BF2CC120236 for ; Tue, 19 Nov 2019 19:26:23 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAK37V4m003176; Tue, 19 Nov 2019 19:26:16 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=FhA6oXh7yI9f9IgacwhYrLLmdgOAGpnknDEzzRGNGP4=; b=GHnKQzChxfsLsTGtPU/Jo1O5S8anBNMqwBfImiksfHynb3FHfQd6cxl2dpxAflGZczDN uebIhPyzHnbBMHfJnyrXlHOgbB6xon/Y3ZHaLYN5B4zcI7TfJ1Xn98M/ujdG4tebur34 ziGZFoC7LXN8BLBfZJhJy6uEqb0pJYkhnkD1CPlMSrquTsN6D09a/6Jzgov4zRXzvBib n5JeedbCLTzs79xr0b44g2APch3S6qUGsrJP0Qmgj63kNvgYfUnpnyH9u5oOYloM0vdS ZdfhqGIgNS+lqTxAwozwdFnnOUTEbRynfWCMoZ8aUiAgEZC1aaGQS7BltI5TTQiYmfbL Qw== 
Received: from sg3-postinop-sz01.asia.apple.com (sg3-postinop-sz01.asia.apple.com [17.84.80.96]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2waejneabk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Nov 2019 19:26:16 -0800
Received: from sng-mmpp-sz02.asia.apple.com (sng-mmpp-sz02.asia.apple.com [17.84.80.27]) by sg3-postinop-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPS id <0Q19002R407RG000@sg3-postinop-sz01.asia.apple.com>; Wed, 20 Nov 2019 11:26:15 +0800 (+08)
Received: from process_milters-daemon.sng-mmpp-sz02.asia.apple.com by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.5.20190826 64bit (built Aug 26 2019)) id <0Q1800H00XKVNK00@sng-mmpp-sz02.asia.apple.com>; Wed, 20 Nov 2019 11:26:15 +0800 (+08)
X-Va-A: 
X-Va-T-CD: 8ff8da7a88ca0804b8c9d6489183f540
X-Va-E-CD: 95019b26206f3a4f0e9452ea411b95f0
X-Va-R-CD: dccf78097554b2aee128a81a83535b58
X-Va-CD: 0
X-Va-ID: 43557fdb-a916-4051-a11d-d0af8e8714a2
X-V-A: 
X-V-T-CD: 8ff8da7a88ca0804b8c9d6489183f540
X-V-E-CD: 95019b26206f3a4f0e9452ea411b95f0
X-V-R-CD: dccf78097554b2aee128a81a83535b58
X-V-CD: 0
X-V-ID: d040984f-1775-4fd5-9742-638ee14ebf6e
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-19_08:,, signatures=0
Received: from [17.235.155.46] by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.5.20190826 64bit (built Aug 26 2019)) with ESMTPSA id <0Q1900L2007KFP30@sng-mmpp-sz02.asia.apple.com>; Wed, 20 Nov 2019 11:26:10 +0800 (+08)
Sender: cpaasch@apple.com
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Christoph Paasch 
In-reply-to: 
Date: Wed, 20 Nov 2019 11:26:07 +0800
Cc: Ingemar Johansson S , Ingemar Johansson S , "tcpm@ietf.org" 
Content-transfer-encoding: quoted-printable
Message-id: 
References:  
To: Jonathan Morton 
X-Mailer: Apple Mail (2.3601.0.10)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 20 Nov 2019 03:26:24 -0000

> On Nov 19, 2019, at 7:06 PM, Jonathan Morton  =
wrote:
>=20
>> On 19 Nov, 2019, at 6:51 pm, Ingemar Johansson S =
 wrote:
>>=20
>> I am also in support of proposed standard for draft-ietf-tcpm-rack as =
this
>> can potentially relax the strict ordering requirements in 5G =
deployments. I
>> am not 100% certain of the actual value of proposed standard vs =
experimental
>> ditto outside IETF but it is definitely not of negative impact.=20
>>=20
>> A question (perhaps already discussed on the mailing list):=20
>> How widely do you think that RACK will be deployed in TCP stacks in =
the near
>> and more far perspective?.=20
>> I know that it is already in Linux. What about MS Windows, FreeBSD, =
IOS,
>> Android ??
>=20
> Android is Linux, to a first approximation, and thus inherits its =
networking capabilities.
>=20
> FreeBSD I understand has a RACK-capable TCP stack, but which is not =
the default.  I think Rod Grimes should be able to clarify this, and =
he's also on this list.
>=20
> Apple devices I do not know for sure about.

We do not have an implementation of RACK in our TCP stack.


Regardless of that, I support PS as the intended status for RACK.


Christoph


>=20
> - Jonathan Morton
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Tue Nov 19 23:24:34 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 9B4CD120843 for ; Tue, 19 Nov 2019 23:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-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=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 xGODXoH4I_XF for ; Tue, 19 Nov 2019 23:24:29 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) (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 111D2120856 for ; Tue, 19 Nov 2019 23:24:28 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FoimLLtYAbSWeD8jKefAlLu/AoEi5bqnBPd3KFhP1kVXhxn0f04kTnH/SdvNRYlgJKXMlF7rJm+YjNDsu9NnfIVyAlCBCpx4545hQAFxBZuF7XKGmAExXrHoU+bWOP2zxbW0SNiNgUmcvlFhrY/wZNpzn3RtA/1BlxksZBmFcCCTvhfiF3rNj6dz1x3/QNTihjwH03anUFiWiSdDVYREJx72xjvTKcRIfmPNMiyAMMPhrxbR2ZAhUOj8CwqLpRAazCJKjcoqyn5oMlZs4ag9PyYlk55KaeBYVIql0+3zORKGj43Knmzd2CU7i9M7zBeJMinw1Utsx8iQzBNw4/YqYw==
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=TBAPiDsI/fOzNsLHVHBv684tOY977GABSzkwboMhDf4=; b=eAynUgdgRH3/kRHSJageEcsp4SgznHkgAAfLprThn3RKasCIQTlAgEu9vRVLFkOWVOqjzjgbbBShkXnYTdh0t1kkFg3HiWxcsoSWGAoIJGS7CbYy+BpNYLs5UTe2u2An9YE+ZSRMaP8O64gt1aBcpWYo7wJi6hshk09NuD4GWZJ45rEK3mU9wLZoL6KLbvZsOq8QPBd1tm9Bc3HoWmt/y7IOnit/B3dcB/WII2O9+37c0Izml5Go9O7nH9RxZcdqiPaB0aBK0SBomphnROeLfdrkcxFfsTGCdsw1hRCbFc5BklRE/6zRaoC/Be2KDRmUB++GyvDD+bRGYt6bVF6hHg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TBAPiDsI/fOzNsLHVHBv684tOY977GABSzkwboMhDf4=; b=SYyLGJx/XhNf0jQfKTHog/JU372760I0nmiLGAtGjiwTswBvf7OILzuZwhRMgUKvY3cyPg+g1tXgeE2GmqMGQx174GuYxUIqfEnn5zBliBj43aFbxrdbnLiINVOcODzkK7sYgcgWJc0Az239soPASwNL4HwRU6qhMchJp7vO22k=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB4331.eurprd07.prod.outlook.com (20.176.167.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.7; Wed, 20 Nov 2019 07:24:26 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2495.009; Wed, 20 Nov 2019 07:24:26 +0000
From: Ingemar Johansson S 
To: Christoph Paasch , Jonathan Morton , Praveen Balasubramanian , "Scheffenegger, Richard" , "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>, Neal Cardwell 
CC: "tcpm@ietf.org" , Ingemar Johansson S 
Thread-Topic: [tcpm] Intended status of draft-ietf-tcpm-rack
Thread-Index: AdWexcS8eS9aGmFuQdyvHIcbtAFW4AAA5R8AACI5cIAACDc1cA==
Date: Wed, 20 Nov 2019 07:24:26 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; 
x-originating-ip: [192.176.1.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0741b37-58d8-48e0-9869-08d76d8aacad
x-ms-traffictypediagnostic: HE1PR07MB4331:|HE1PR07MB4331:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(376002)(366004)(346002)(13464003)(189003)(199004)(478600001)(6246003)(4326008)(71190400001)(107886003)(966005)(66066001)(102836004)(6506007)(53546011)(76176011)(7696005)(8936002)(25786009)(99286004)(2501003)(229853002)(2906002)(186003)(8676002)(81166006)(81156014)(26005)(74316002)(7736002)(305945005)(446003)(5660300002)(11346002)(54906003)(66446008)(3846002)(55016002)(71200400001)(6116002)(66476007)(66616009)(66946007)(86362001)(486006)(6306002)(64756008)(66556008)(110136005)(9686003)(256004)(476003)(316002)(6436002)(1511001)(52536014)(14454004)(76116006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4331; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2V3boQFzTTjqA+WOb9biVqrUeysDLPhNH8D3hPytjjfw0HuJ3s7IHKYv4q8ovMjxuRDW9323jbpu3rKVQqf40h1cdhwYGWhICyEz9T3lZ2jzQpA1GEmsm+RnYYBxtIM3kIeYVZzgtNrNl1mTrZPCYf2bDoZe7viMmQvfPbPkGcVvRxquEvzx5rJjroyOrPmAeSME7klV56XFrG2HSE3H/VTuruR4Sf5dDvv9NxD7rq9HK30ileQ6rgFg7WHTquWc+4z2LDZYRPX7gIqenbl+ONRhpbU9Wo/4LBSeNY17js/c8UuKCxENYzbWLDhCchfA2659ugfedgmjYbGWtKvsfesIaj08Qaoojx8RpjUQLd70xnf2FzobN3tZDPxQmUnxElQmGwcA1sDtJPgtruoFOZw213KWF3A2W44jG1uAvjWRppUT4YcEYETC/uhHEj+7Plk1Tl+5rSfAEKP5Mk0dZFEX/bpAzROAk3D4l9l7qoo=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05AF_01D59F7B.EB2F7F50"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b0741b37-58d8-48e0-9869-08d76d8aacad
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 07:24:26.5457 (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: GVLBhqjRLh3GM0Ze/wIAUd94xEOnEEuUYPdYHb18m7RmlQzObAjKXY9v27GbYQO/78j94T8uL2cfr8R+8xEF6AUqQsmENLt42nw2iRP8GiFud39TRBPTqpfezyuS/z2N
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4331
Archived-At: 
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
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, 20 Nov 2019 07:24:32 -0000

------=_NextPart_000_05AF_01D59F7B.EB2F7F50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks all for the response, it is indeed useful information

/Ingemar

> -----Original Message-----
> From: cpaasch@apple.com  On Behalf Of Christoph
> Paasch
> Sent: den 20 november 2019 04:26
> To: Jonathan Morton 
> Cc: Ingemar Johansson S ; Ingemar
> Johansson S ; tcpm@ietf.org
> Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
> 
> 
> 
> > On Nov 19, 2019, at 7:06 PM, Jonathan Morton 
> wrote:
> >
> >> On 19 Nov, 2019, at 6:51 pm, Ingemar Johansson S
>  wrote:
> >>
> >> I am also in support of proposed standard for draft-ietf-tcpm-rack as
> >> this can potentially relax the strict ordering requirements in 5G
> >> deployments. I am not 100% certain of the actual value of proposed
> >> standard vs experimental ditto outside IETF but it is definitely not of
> negative impact.
> >>
> >> A question (perhaps already discussed on the mailing list):
> >> How widely do you think that RACK will be deployed in TCP stacks in
> >> the near and more far perspective?.
> >> I know that it is already in Linux. What about MS Windows, FreeBSD,
> >> IOS, Android ??
> >
> > Android is Linux, to a first approximation, and thus inherits its
networking
> capabilities.
> >
> > FreeBSD I understand has a RACK-capable TCP stack, but which is not the
> default.  I think Rod Grimes should be able to clarify this, and he's also
on this
> list.
> >
> > Apple devices I do not know for sure about.
> 
> We do not have an implementation of RACK in our TCP stack.
> 
> 
> Regardless of that, I support PS as the intended status for RACK.
> 
> 
> Christoph
> 
> 
> >
> > - Jonathan Morton
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm


------=_NextPart_000_05AF_01D59F7B.EB2F7F50
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ
Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3
MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n
ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj
c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD
kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J
0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA
gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9
7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g
O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu
Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp
YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy
aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA
uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP
9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6
Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon
vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k
fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8
TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3
OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO
30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z
elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw
ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM
C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy
MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw
IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3
0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5
S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT
05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV
tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs
bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO
xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT
9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx
5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0
dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs
aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA
oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj
YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq
F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto
FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR
xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d
rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg
vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+
i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI
Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m
dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC
aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xOTExMjAwNzI0MjVaMCMGCSqGSIb3DQEJBDEWBBRO2nE2xf5sN00XhHD0
LSP/vvu8CjBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79
UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM
CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz
IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBABnCUfCPxw/jZz5WcRD3GKdGV8tor/LSPNnG7cNZ
ohO7w36chlE8/xkoaDmNYunUg7BFXwebXZpGiO3fMIL+uEM8rraDP6pepUjuIJTqtP6J1rDfjEEW
IhwPAY1FBdamM8VdY1X2K1ywRo7ISkjoS3o+ep0YnQ4VixB1Ki0eiGxbuPO4TTLV+5a+v/Xr9UUr
vSJvi2scsWqFfsLZBajVIlrgpQ0tCD/qtbjfMt90GhYHWh4uwaepTcJSojMKOaaOe3jqGnmHp3vs
eORTTXAUOyf372OpL+HTXjQyuYR7LRiIe40zu7ecc+VKHLQw8m+3Mu019Gvw2t6ApM1jQ8f7vjYA
AAAAAAA=

------=_NextPart_000_05AF_01D59F7B.EB2F7F50--


From nobody Wed Nov 20 00:18: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 F18E212099E; Wed, 20 Nov 2019 00:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.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 KnB8CVebj9aW; Wed, 20 Nov 2019 00:17:59 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820098.outbound.protection.outlook.com [40.107.82.98]) (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 D4C2F120A65; Wed, 20 Nov 2019 00:17:59 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XEeUBI6Wz9zDTmVlOsqlCvh9tELvdD/IEtMhdUM+N/VOoqzs+sjamnK3wFivSAqpN6s1ZlLPJRZKsl5NwuVYmstYwyl4GwL8vjYxdVqr+dO9VWdKXWektjWIMcS5uMRFXu3Q+GIJGJbn9Cltlj2K6BNF2VgmVp+jdrfMhFH3FlyUxhEK5yPKSLu5Siffvj6H4eim2WLjaD7QudAFKpCwz9Z1tmbVpXbEDAKg0wGVsyoo4zgM6mn4Msy07aH+NNL0TcfgnrfDxMa4ctS4XgKqCY0jMuRX4rl7LfQsdvMuru+kfKYd4iWQfr6J9ky47peZ40ccwPAcnBizSL8a6pqfyg==
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=uP7k7MqvmaW2RjodvS5oElQ893Ii9CKN/Vnq2BcvHNc=; b=VIkFN5R7oJF4a1o1qlE6yBZrYLHGXxWipp5J331bFc2fdG+U2KdWiMwOVKJT3lvJcazz6547CWa1vYQY2yPy0MrzkWLWyIAcjbr/RwzJClxvEjeoGdzFWdDChDI97Mr9gRxmMqMP+c26F9ykBTg5G4Eqv5ZFvIZ6AX6Mgk60XuylkGIBXp3yVWQ5TVd/ySEHG6TmhzLicQyUFyd0A6QsQhPjb80XZYd1xjp6XurrzEntfdYoGgCJc2ooKuI7t/32ljYfAFRa2lbZ/Wg5xKTHaGqSYu08464CXH1/ugVE7MnhlSYSVXwg+tRkJnVxdZ/h3gb9OCVE9a5bHErw+B901w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uP7k7MqvmaW2RjodvS5oElQ893Ii9CKN/Vnq2BcvHNc=; b=O7edod6K5Zvl7FUZwZrXMj81EiB03L9L0TprbjzsWlwGeyGHCqhL85WBuV6TKuIWchvJzcW4eKpwAqVdp02z0wLeMDU962RHu8/GPmjJ8DJ0lWczEjV1kjlV+gT2u+Q6PkgYfsUQ3kxk1slShyP5eE78bm2UDxiQ2Dyi7UVSTws=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4543.namprd06.prod.outlook.com (52.135.115.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Wed, 20 Nov 2019 08:17:57 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::91c5:f29b:4501:6db5]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::91c5:f29b:4501:6db5%2]) with mapi id 15.20.2451.029; Wed, 20 Nov 2019 08:17:57 +0000
From: Greg White 
To: =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= , Bob Briscoe , tsvwg IETF list , iccrg IRTF list , tcpm IETF list 
Thread-Topic: [tsvwg] [iccrg] TCP Prague Update: L4S-related Side Meeting at IETF-106
Thread-Index: AQHVn3sDlXeDDRvJj0WU78yyP5Ii1w==
Date: Wed, 20 Nov 2019 08:17:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; 
x-originating-ip: [2001:67c:370:128:2003:5cd5:187d:1c32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 915bdebb-bf2e-4b30-ff7c-08d76d922647
x-ms-traffictypediagnostic: SN6PR06MB4543:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39840400004)(346002)(376002)(396003)(366004)(189003)(199004)(13464003)(66574012)(8936002)(7110500001)(71200400001)(6506007)(53546011)(71190400001)(46003)(2616005)(2420400007)(186003)(486006)(256004)(14444005)(66556008)(66476007)(66946007)(15650500001)(25786009)(64756008)(6116002)(2906002)(66446008)(5660300002)(99286004)(476003)(305945005)(33656002)(7736002)(102836004)(110136005)(316002)(58126008)(14454004)(6246003)(36756003)(6512007)(6306002)(966005)(6436002)(91956017)(76116006)(81156014)(86362001)(8676002)(81166006)(6486002)(229853002)(478600001)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4543; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ToaoO2LZcDg9IbuNgwpjJZrpmz/cqfSvOpL+g9qpf3VSGBZeLJh72BIZXV/8X5RkrTN3mUhb1Q5PLY6x/3yXuGAbMAvUCiCGgjcO69KNe+rOXTjIkE6KIOkONulOxeqwNq/MiKq5IxbmIHf89784UaCJM2cwxL3KmfLcG+cgHpaGtuWqycTBTlJrOBD8q6Qsq8f+LkJ7O+VELDQcah+QJGBx6x/NJN8VFgQZVU6ZLmMpQ7jf5QynXHZVRgTY1hCMQa4vSUQGi0buiJ0/clAGR8N/ua3tTFJJsz5F6ljGEkiv53rKHB4rjNq2SN2n39jFvF13MwzTCGyGLhMS+4aHneOMgEWtmdyKLzge1SuZN3FGUzTAu6Xr88bvV6O5VOqN3Us06NSppaXThM64+e4RlhM/llQw9eiCfI6R9TiL8/iC4Cm4MFPGo5u7I2NoByJ1nsF5TKJmZyzZwYtyv+CL5JLh8KgzuKKMf2sbcjV8QXU=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 915bdebb-bf2e-4b30-ff7c-08d76d922647
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 08:17:56.9970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WuCxpbUBy7IA61soOOfNufTEBH/UY8vOWTnBcxdHhU4tuHUXp0Cu7BjDdIn5q68cY0aOVdqhmuT9ly/j9ugryQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4543
Archived-At: 
Subject: Re: [tcpm] [tsvwg] [iccrg] TCP Prague Update: L4S-related Side Meeting at IETF-106
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, 20 Nov 2019 08:18:02 -0000

SGkgQW5uYSwNCg0KVGhlIHpvb20gc2Vzc2lvbiB3aWxsIGJlIHJlY29yZGVkLiAgSSB3aWxsIHNl
bmQgYSBsaW5rIHRvIHRoZSByZWNvcmRpbmcgb25jZSBpdCBpcyBhdmFpbGFibGUuDQoNCi1HcmVn
DQoNCu+7v09uIDExLzIwLzE5LCA3OjE1IEFNLCAidHN2d2cgb24gYmVoYWxmIG9mIEFubmEgQnJ1
bnN0csO2bSIgPHRzdndnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFubmEuYnJ1bnN0
cm9tQGthdS5zZT4gd3JvdGU6DQoNCiAgICBIaSBCb2IsDQogICAgDQogICAgVGhhbmtzIGZvciBh
cnJhbmdpbmcgZm9yIHJlbW90ZSBwYXJ0aWNpcGF0aW9uLiBEbyB5b3UgYWxzbyBwbGFuIHRvIHJl
Y29yZCB0aGUgem9vbSBzZXNzaW9uPyBUaW1lIHpvbmVzIGFyZSBhIGJpdCBjaGFsbGVuZ2luZyA6
LSkNCiAgICANCiAgICBSZWdhcmRzLA0KICAgIEFubmENCiAgICANCiAgICAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IGljY3JnIDxpY2NyZy1ib3VuY2VzQGlydGYub3JnPiBP
biBCZWhhbGYgT2YgQm9iIEJyaXNjb2UNCiAgICBTZW50OiBkZW4gMTggbm92ZW1iZXIgMjAxOSAw
Mzo1Mg0KICAgIFRvOiB0c3Z3ZyBJRVRGIGxpc3QgPHRzdndnQGlldGYub3JnPjsgaWNjcmcgSVJU
RiBsaXN0IDxpY2NyZ0BpcnRmLm9yZz47IHRjcG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPg0K
ICAgIFN1YmplY3Q6IFtpY2NyZ10gVENQIFByYWd1ZSBVcGRhdGU6IEw0Uy1yZWxhdGVkIFNpZGUg
TWVldGluZyBhdCBJRVRGLTEwNg0KICAgIA0KICAgIEZvbGtzLA0KICAgIA0KICAgIFRoZSBzaWdu
aWZpY2FudCBhbW91bnQgb2YgVENQIFByYWd1ZSB1cGRhdGUgbWF0ZXJpYWwgd2FzIHRvbyBncmVh
dCBmb3IgdGhlIGljY3JnIGFnZW5kYS4NCiAgICBTbywgd2l0aCB0aGUgaGVscCBvZiB0aGUgaWNj
cmcgYW5kIHRzdndnIGNoYWlycyAodGhhbmsgeW91KSwgd2UndmUgYXJyYW5nZWQgYSBzaWRlIG1l
ZXRpbmcgdG8gY292ZXIgYWxsIHRoaXMuDQogICAgDQogICAgPT1XaGVyZS93aGVuPz09DQogICAg
RGF0ZTogVGh1IDIxIE5vdiAyMDE5DQogICAgVGltZTogMDg6MzAgLSAwOTozMA0KICAgIFJvb206
IENhbm5pbmcNCiAgICANCiAgICA9PUFnZW5kYT09DQogICAgaHR0cDovL2JvYmJyaXNjb2UubmV0
L3Byb2plY3RzL2xhdGVuY3kvVENQX1ByYWd1ZV9zaWRlLW1lZXRpbmdBZ2VuZGFJRVRGLTEwNi5o
dG1sDQogICAgDQogICAgPT1NZWV0aW5nIE1hdGVyaWFscz09DQogICAgTGlua3MgdG8gbWVldGlu
ZyBtYXRlcmlhbHMgd2lsbCBiZSBhZGRlZCB0byB0aGUgYWJvdmUgYWdlbmRhIHNvb24uDQogICAg
VGhleSB3aWxsIGFsc28gYmUgYWRkZWQgdG8gdGhlIHRzdndnIG1lZXRpbmcgbWF0ZXJpYWxzLg0K
ICAgIA0KICAgID09UmVtb3RlIEF0dGVuZGFuY2U9PQ0KICAgIE1lZXRlY2hvIGlzIG5vdCBhdmFp
bGFibGUgZm9yIHNpZGUtbWVldGluZ3MsIHNvIHdlJ3JlIGFycmFuZ2luZyBhbiBhbHRlcm5hdGl2
ZSwgcHJvYiBab29tIChsaW5rIHdpbGwgYXBwZWFyIG9uIGFnZW5kYSkNCiAgICANCiAgICBSZWdh
cmRzDQogICAgDQogICAgDQogICAgQm9iDQogICAgDQogICAgDQogICAgLS0NCiAgICBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQogICAgQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2Jv
YmJyaXNjb2UubmV0Lw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQogICAgaWNjcmcgbWFpbGluZyBsaXN0DQogICAgaWNjcmdAaXJ0Zi5v
cmcNCiAgICBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljY3JnDQogICAg
DQogICAgDQoNCg==


From nobody Wed Nov 20 01:11: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 A537C120B00; Wed, 20 Nov 2019 01:11:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 m5tzr2OwYhLa; Wed, 20 Nov 2019 01:11:11 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 BA19A1208A2; Wed, 20 Nov 2019 01:11:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=ERDTfUekesRoiCfn/aCEXXlhTR5V6RawR214pELJgEg=; b=2gaamYH1IoPMKe6kPuZxUyUXU aKuoLFLOscH+yAUTeriAeZLG0b729eVMOy5Am6Gn9GK98dyRJdeRp5PqyEHpeqTbkYOqmo7trmQ5R syVg2DfWaQx8GCvmAHDsROHkkRY0wkDWrtfjlZa8cZrGD9fXOp+ynd6tJ0eGMRE7Av+p5IB/YMqUM lR5rBOPPGBbzthSqg0EaIpVu8Nz+YQKqWsYwahjZtFiBkbpP88EYLJw30qUD1kTYWpgM3I633EKFZ kEEL8ntzESxUgk4SUmxpovMA0e5xk7FXrU2BKrtKL2T7UFecMXH4SdagMRRaYpsJzdG9QeynEJbGH 0eVVuhYzA==;
Received: from dhcp-98c7.meeting.ietf.org ([31.133.152.199]:52732) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iXM0v-0006lV-Us; Wed, 20 Nov 2019 09:11:06 +0000
To: "Scharf, Michael" , "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" 
Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net>  <6EC6417807D9754DA64F3087E2E2E03E2D4FA28D@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Bob Briscoe 
Message-ID: <9758521f-1ba1-cf12-39dd-a374912c7b02@bobbriscoe.net>
Date: Wed, 20 Nov 2019 17:11:01 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4FA28D@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------A1280018ECFE5F67999B1944"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
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, 20 Nov 2019 09:11:17 -0000

This is a multi-part message in MIME format.
--------------A1280018ECFE5F67999B1944
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Michael,

On 11/11/2019 18:16, Scharf, Michael wrote:
>
> So can you confirm that a TCP sender can use the L4S service without 
> implementing AccECN? I am asking again since there has been some 
> recent list discussion on that, e.g., given the points raised by 
> Sebastian. I am a bit lost here on what the future plan in L4S 
> actually is.
>
L4S needs fine-grained feedback, but not necessarily AccECN.
So, while AccECN is the way to do fine-grained feedback, L4S needs AccECN.

I took your question to be in a context where something else might have 
replaced AccECN in the future for fine-grained feedback. In that case, 
L4S would need that new shiny thing instead, and would not then need AccECN.

> And I still fail to understand why even the general idea of RACK 
> matters to AQM algorithms, traffic classifiers, or priority schedulers 
> for traffic with 1/p congestion control in a router. RACK has lots of 
> merits, but most of them are IMHO entirely unrelated to the vision of 
> L4S. I’d suggest to focus L4S on solving the key problems for traffic 
> with 1/p congestion control.
>

I've promised David Black a full answer to this. So pls see that.
But briefly, an important advance of L4S is scalable throughput (it's in 
the name).

It would be pointless to remove one scaling limitation if it was 
replaced by the 3 DupACK as a throughput limitation (Amdahl's law). In 
an ideal world, the two would be done separately. But L4S creates a 
clean-slate opportunity where there's a new queue and new CCs, and there 
is no downside to placing the time-units requirement on these senders 
that have to be updated anyway. Then future expts that might rely on all 
hosts using time-units will not be precluded.

This is all in the latest text in the appendix.


Bob
>
> Michael (with no hat)
>
> *From:*Bob Briscoe 
> *Sent:* Monday, November 11, 2019 10:39 AM
> *To:* Scharf, Michael ; 
> draft-ietf-tsvwg-ecn-l4s-id@ietf.org
> *Cc:* tcpm@ietf.org; tsvwg@ietf.org
> *Subject:* Re: [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
>
> Michael,
>
> On a similar question of dependency between experiments, I think you 
> also expressed concern that ecn-l4s-id depends on the RACK experiment. 
> However, ecn-l4s-id only refers to RACK informatively, because it only 
> uses the general idea behind RACK. Just as quic-recovery (stds track) 
> uses the general idea behind RACK (expt track) by referring to it 
> informatively.
>
>
>
> Bob
>
> On 04/11/2019 15:26, Bob Briscoe wrote:
>
>     Michael,
>
>     Thank you for pointing this out, many months ago now.
>
>     There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on
>     AccECN, as explained below.
>
>     For any transport protocol to comply with ecn-l4s-id, it needs
>     sufficiently accurate feedback of the extent of CE marking on the
>     forward path. You pointing this out has made me realize that there
>     is a 'needs' that should be a 'MUST' in the spec:
>
>     4.2.  Prerequisite Transport Feedback
>
>     CURRENT:
>
>        In general, a scalable congestion control, needs feedback of the
>
>        extent of CE marking on the forward path.
>
>     PROPOSED:
>
>        In general,for a transport protocol to providescalable
>     congestion control,
>
>     it MUST providefeedback of the
>
>        extent of CE marking on the forward path.
>
>
>     However, ecn-l4s-id only specifies the requirements that any L4S
>     transport protocol would have to satisfy. It does not define a
>     transport protocol itself. So AccECN is not a normative ref. So I
>     am also altering the text a little further down, where it refers
>     to AccECN, as follows:
>
>     CURRENT:
>
>       TCP:  Support for accurate ECN feedback (AccECN
>
>           [I-D.ietf-tcpm-accurate-ecn  ]) by both ends is a prerequisite for
>
>           scalable congestion control.
>
>     PROPOSED:
>
>       TCP:  Support for accurate ECN feedback (such as AccECN
>
>           [I-D.ietf-tcpm-accurate-ecn  ]) by both ends is a prerequisite for
>
>           scalable congestion control.
>
>     Thanks again for pointing this out.
>
>
>           Dependencies between Experiments
>
>
>     The case of TCP Prague provides a counter-argument:
>
>     TCP Prague could be specified in one monolithic experimental spec.
>     Or it could be broken down into experimental components, and a top
>     level experimental spec that pulls them all together.
>
>     The latter option would create multiple dependencies of one
>     experiment on others. But IMHO such modularity is preferable to a
>     monolithic spec. Especially if some of the components might have
>     other uses outside of TCP Prague (which is exactly the case with
>     TCP Prague, e.g. AccECN, ECN++, RACK are all potentially parts of
>     the base TCP stack, and paced-chirping is potentially usable by
>     any other congestion control - these are all experimental
>     component parts).
>
>     As another example, BBR was written up as an experimental draft,
>     and the Linux implementation uses RACK (although not mentioned in
>     the draft) which is enabled by default in Linux.
>
>     Such modularity is good.
>
>
>     Bob
>
>     On 24/03/2019 19:15, Scharf, Michael wrote:
>
>         I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and
>         I run into the following sentence:
>
>         TCP:  Support for accurate ECN feedback (AccECN
>
>               [I-D.ietf-tcpm-accurate-ecn]) by both ends is a
>         prerequisite for
>
>               scalable congestion control.  Therefore, the presence of
>         ECT(1) in
>
>               the IP headers even in one direction of a TCP connection
>         will
>
>               imply that both ends support AccECN.  However, the
>         converse does
>
>               not apply.  So even if both ends support AccECN, either
>         of the two
>
>               ends can choose not to use a scalable congestion
>         control, whatever
>
>               the other end's choice.
>
>         Can the authors please clarify whether there is a normative
>         dependency of draft-ietf-tsvwg-ecn-l4s-id on
>         draft-ietf-tcpm-accurate-ecn?
>
>         If so, I think the formal dependency on implementing AccECN
>         has to be spelt out explicitly. In that case, I would be
>         looking for a statement of the sort "MUST/SHOULD/MAY implement
>         draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement
>         does not exist, I think the above paragraph is confusing.
>
>         As individual contributor, I want to note that I disagree with
>         mandatory dependencies between experiments. I have mentioned
>         in the past that I believe that different experiments must be
>         specified independently of each other and should be
>         implementable independently of each other, specifically also
>         to be able to fail independently of each other. It is possible
>         that I am in the rough part of the consensus. But I haven't
>         changed my mind.
>
>         Michael (as individual)
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoe http://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------A1280018ECFE5F67999B1944
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    
On 11/11/2019 18:16, Scharf, Michael
      wrote:

    

    

      
      
      
      

        
So can you confirm that a TCP sender can use
            the L4S service without implementing AccECN? I am asking
            again since there has been some recent list discussion on
            that, e.g., given the points raised by Sebastian. I am a bit
            lost here on what the future plan in L4S actually is.

      

    

    L4S needs fine-grained feedback, but not necessarily AccECN. 

    So, while AccECN is the way to do fine-grained feedback, L4S needs
    AccECN. 

    

    I took your question to be in a context where something else might
    have replaced AccECN in the future for fine-grained feedback. In
    that case, L4S would need that new shiny thing instead, and would
    not then need AccECN.

    

    

      

        

        
 

        
And I still fail to understand why even the
            general idea of RACK matters to AQM algorithms, traffic
            classifiers, or priority schedulers for traffic with 1/p
            congestion control in a router. RACK has lots of merits, but
            most of them are IMHO entirely unrelated to the vision of
            L4S. I’d suggest to focus L4S on solving the key problems
            for traffic with 1/p congestion control.

      

    

    

    I've promised David Black a full answer to this. So pls see that.

    But briefly, an important advance of L4S is scalable throughput
    (it's in the name). 

    

    It would be pointless to remove one scaling limitation if it was
    replaced by the 3 DupACK as a throughput limitation (Amdahl's law).
    In an ideal world, the two would be done separately. But L4S creates
    a clean-slate opportunity where there's a new queue and new CCs, and
    there is no downside to placing the time-units requirement on these
    senders that have to be updated anyway. Then future expts that might
    rely on all hosts using time-units will not be precluded.

    

    This is all in the latest text in the appendix.

    

    

    Bob

    

      

        

        
 

        
Michael (with no hat)

        
 

        
 

        
 

        

          

            

              
From: Bob Briscoe <in@bobbriscoe.net>
                  

                  Sent: Monday, November 11, 2019 10:39 AM

                  To: Scharf, Michael
                  <Michael.Scharf@hs-esslingen.de>;
                  draft-ietf-tsvwg-ecn-l4s-id@ietf.org

                  Cc: tcpm@ietf.org; tsvwg@ietf.org

                  Subject: Re: [tsvwg]
                  draft-ietf-tsvwg-ecn-l4s-id

            

          

          
 

          
Michael,

              

              On a similar question of dependency between experiments, I
              think you also expressed concern that ecn-l4s-id depends
              on the RACK experiment. However, ecn-l4s-id only refers to
              RACK informatively, because it only uses the general idea
              behind RACK. Just as quic-recovery (stds track) uses the
              general idea behind RACK (expt track) by referring to it
              informatively.

              

              

              

              Bob

          

            
On 04/11/2019 15:26,
                Bob Briscoe wrote:

          

          

            
Michael,

                

                Thank you for pointing this out, many months ago now. 

                

                There is no formal dependency of
                draft-ietf-tsvwg-ecn-l4s-id on AccECN, as explained
                below.

                

                For any transport protocol to comply with ecn-l4s-id, it
                needs sufficiently accurate feedback of the extent of CE
                marking on the forward path. You pointing this out has
                made me realize that there is a 'needs' that should be a
                'MUST' in the spec:

                

                4.2.  Prerequisite Transport Feedback

                

                CURRENT:

            
   In general, a scalable congestion control, needs feedback of the

            
   extent of CE marking on the forward path.

            
PROPOSED:

            
   In general, for a transport protocol to provide scalable congestion control, 

            
   it MUST provide feedback of the

            
   extent of CE marking on the forward path.

            


                However, ecn-l4s-id only specifies the requirements that
                any L4S transport protocol would have to satisfy. It
                does not define a transport protocol itself. So AccECN
                is not a normative ref. So I am also altering the text a
                little further down, where it refers to AccECN, as
                follows:

                

                CURRENT:

            
  TCP:  Support for accurate ECN feedback (AccECN

            
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for

            
      scalable congestion control.

            
PROPOSED:

            
  TCP:  Support for accurate ECN feedback (such as AccECN

            
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for

            
      scalable congestion control.

            
Thanks again for pointing this out.

            
Dependencies between Experiments

            


                The case of TCP Prague provides a counter-argument:

                

                TCP Prague could be specified in one monolithic
                experimental spec. 

                Or it could be broken down into experimental components,
                and a top level experimental spec that pulls them all
                together.

                

                The latter option would create multiple dependencies of
                one experiment on others. But IMHO such modularity is
                preferable to a monolithic spec. Especially if some of
                the components might have other uses outside of TCP
                Prague (which is exactly the case with TCP Prague, e.g.
                AccECN, ECN++, RACK are all potentially parts of the
                base TCP stack, and paced-chirping is potentially usable
                by any other congestion control - these are all
                experimental component parts).
                

                

                As another example, BBR was written up as an
                experimental draft, and the Linux implementation uses
                RACK (although not mentioned in the draft) which is
                enabled by default in Linux.
                

                

                Such modularity is good.

                

                

                Bob

                

                

            

              
On 24/03/2019
                  19:15, Scharf, Michael wrote:

            

            

              
I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence:

              
 

              
TCP:  Support for accurate ECN feedback (AccECN

              
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for

              
      scalable congestion control.  Therefore, the presence of ECT(1) in

              
      the IP headers even in one direction of a TCP connection will

              
      imply that both ends support AccECN.  However, the converse does

              
      not apply.  So even if both ends support AccECN, either of the two

              
      ends can choose not to use a scalable congestion control, whatever

              
      the other end's choice.

              
 

              
Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn?

              
 

              
If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing.

              
 

              
As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind.

              
 

              
Michael (as individual)

              
 

              
 

            

            


                

                

            
-- 

            
________________________________________________________________

            
Bob Briscoe                               http://bobbriscoe.net/

          

          


              

              

          
-- 

          
________________________________________________________________

          
Bob Briscoe                               http://bobbriscoe.net/

        

      

      

      

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


    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------A1280018ECFE5F67999B1944--


From nobody Wed Nov 20 07:06:37 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 53EFD1200E6; Wed, 20 Nov 2019 07:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level: 
X-Spam-Status: No, score=-2.688 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=KgSJ94IL; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=lkqNsg0/
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 FY6KaG1Ke1hh; Wed, 20 Nov 2019 07:06:27 -0800 (PST)
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 2EB0C120024; Wed, 20 Nov 2019 07:06:27 -0800 (PST)
Received: from pps.filterd (m0170392.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAKF0IUD019376; Wed, 20 Nov 2019 10:04:44 -0500
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=Bw6SFwszyK4nYAG/ELOE5MmDHtfXaoni+cJtQNZQHJI=; b=KgSJ94ILefpuMqel3YnkydfpjVtlum/pjDjr8Fi6iGq06avpvmcISP4V3YjY5+GxU6zx hQaLKeaUzI3ZifjQedKcYaYDMxxB4Li8gjfh5k2e6J1Vl82jIsX1if4XT7nzDDXeWDQH jKnAo61U1rZCfFZL3wpXouAbQ1ps0ifTVfjj3ncyaf1ddwSpcVBgXYfZC7owcC/H7F1E zGhWHsNhWKSFuqOMd3ldQbJ3MhO16t2CLCuwSFo0TU2HbT7YTWYYVdzQep9Bbinwl85q VAq1NFGebe56UPDsOwpikddDe+F5ukCxscjcBuqMQLrt012+F2kY2RSAi47tyHYSBgG3 oA== 
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2wad5f9yxe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 10:04:42 -0500
Received: from pps.filterd (m0133268.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAKF495h132581; Wed, 20 Nov 2019 10:04:42 -0500
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2057.outbound.protection.outlook.com [104.47.44.57]) by mx0a-00154901.pphosted.com with ESMTP id 2wac7vefmc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Nov 2019 10:04:41 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RT1j84jA7c1lhQeSQS9N3r9ZdjMBB0GVCmYEujPGhr8fBSoJbx/OHarctcJ89f8XOob/4nVJWEfJa76D6Ua0Yv17Yv10FWpqvoe7w7eqTtbWBzhY4dbcmWAR8vi7Uv7jJ/ZMg/58Wcs3oVUcGFTeRjbrjf3FNAOwNbDRvwBayN43qymFdPDuD0ssSc/2vAtgm2vN5TcmBU0CT1VSrH0oDWtwgFdJ9hR4t0/o0anJ7+E+emxSF19JJYDrgRQK1XF4owYWQKMOx96xLOrL7Ncq84Q8L3l3yRwt7lt2korge3ZzGshJXr8JnCIEr8CYLJaBqvXwrov5Uwhd9rx9pPbwFg==
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=Bw6SFwszyK4nYAG/ELOE5MmDHtfXaoni+cJtQNZQHJI=; b=A2LSI4p7Bnu/SqwOuvMpwNvKMFF34VszTcedUhCCk8Tb2syN+aWK+g816bgWv3Fn1Vzy+zFlZ1uj33VWErzIRc4wI0UCkGqoJtxkbQyzjqgX1VACYSwuPjEnUVSrvHeNoPrjAUEgbhSiY7Zg1J7dq3hTMaXSfsc+0uc8g/tuRqWoFLTWZOUBVxeJllKcu20vTTYZDhv3HOZBVE8e1bYVNj7lNEQ64WcLktQngHBqb6fi9UIo4WqvzkFKBPaXXXcMOv/CRF86iHj5iu8GXN33xvHJhFRKxUnf4wS/KY8fua0SoxoGOEu7dvbH+4WCNkcttjSzOb4z0ZBNfj7GFDCfkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com;  s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bw6SFwszyK4nYAG/ELOE5MmDHtfXaoni+cJtQNZQHJI=; b=lkqNsg0/qS0oYouHc+mAkUJe/fzDIml39DFasIptzNOP2B1WULdCHgnxLlt3aGCZvm3r9CLX20cCmdmFohTk+Odh3GLIHhIUXr/37mvOH22KfHSnYK4wsWF5fWkYpWnHNsm1FzJo3KKx3+xHcEl78qc7H4t+JXCfkzfuz6P5BQQ=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3200.namprd19.prod.outlook.com (20.179.151.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Wed, 20 Nov 2019 15:04:40 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2474.018; Wed, 20 Nov 2019 15:04:39 +0000
From: "Black, David" 
To: Bob Briscoe , "Scharf, Michael" , "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" 
CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "Black, David" 
Thread-Topic: [tsvwg] [tcpm]  draft-ietf-tsvwg-ecn-l4s-id
Thread-Index: AQHVn4J+awhvuOVukEORwsnv9afl4qeUGfZg
Date: Wed, 20 Nov 2019 15:04:39 +0000
Message-ID: 
References: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> <74c959b8-7756-5f9e-1333-07e9d199dd67@bobbriscoe.net>  <6EC6417807D9754DA64F3087E2E2E03E2D4FA28D@rznt8114.rznt.rzdir.fht-esslingen.de> <9758521f-1ba1-cf12-39dd-a374912c7b02@bobbriscoe.net>
In-Reply-To: <9758521f-1ba1-cf12-39dd-a374912c7b02@bobbriscoe.net>
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-11-20T14:12:31.9367319Z; 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: [61.8.238.244]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 83c2d396-99e1-4726-772b-08d76dcaf778
x-ms-traffictypediagnostic: MN2PR19MB3200:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(396003)(376002)(7502003)(199004)(189003)(33656002)(5660300002)(6436002)(8936002)(790700001)(66446008)(476003)(3846002)(99286004)(2501003)(11346002)(786003)(52536014)(478600001)(30864003)(186003)(14454004)(55016002)(9686003)(81156014)(606006)(6306002)(54896002)(236005)(81166006)(4326008)(6246003)(107886003)(8676002)(86362001)(2906002)(966005)(66556008)(64756008)(76116006)(66476007)(6116002)(229853002)(66066001)(446003)(6506007)(316002)(66574012)(76176011)(25786009)(66946007)(53546011)(54906003)(74316002)(256004)(71200400001)(71190400001)(486006)(26005)(7736002)(102836004)(14444005)(7696005)(110136005)(116284003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3200; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jMw8ce3S5omn33ctjhSUDux/9I7nEkzDttkQfNfleuLJUQMMtZ99GkW28Gz2+Eome5cO1CJsGcQE+bTaFx0HrAt4GTvsQFC/ggGhBV4Vja5qbbKmmE2vINrI5yqaL63/c7kdGhYV6VhpskSIWXFKsQH3T+q9kDSiplnPqvV1ICGXSXv6sbBPQ02fWPcti1zveNWqs6lT3W5od76G3XGFE0KSn92iCx0aR/r6pxXPlRixi75aL8ZdhW0AoIbB/v5vMs2xJp8nond+xbL/opBC2wM5WtL1F20fCjL0pr1hQC74cfmPv4VnosNKYXQ4Gt1EjcCvQz4u/efPkd8WFsGjUojUlFqFbhE9+kXPRIxNnTBCnje7GhWuzJLEQgJHPeuBEXgisFHP2rZ1hd+SDE5/zw1J8vE6h4LVz1D+16A5olm2jLoEtQD/ko+xEspM0EQg
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB4045AB7A48C0039B5E3856AC834F0MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 83c2d396-99e1-4726-772b-08d76dcaf778
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 15:04:39.6593 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rLJ+/H4hXAoID+iJt5nZCPlieXaEaLB5imv+bZMUxI2by3tM4/HJVnTdf+MqXqCEd7Y+6VVHSdmTWPOhHMuhCQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3200
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_04:2019-11-15,2019-11-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 impostorscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 bulkscore=0 spamscore=0 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200133
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 impostorscore=0 phishscore=0 clxscore=1015 spamscore=0 adultscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200132
Archived-At: 
Subject: Re: [tcpm] [tsvwg]   draft-ietf-tsvwg-ecn-l4s-id
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, 20 Nov 2019 15:06:30 -0000

--_000_MN2PR19MB4045AB7A48C0039B5E3856AC834F0MN2PR19MB4045namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TWljaGFlbCBTY2hhcmYgd3JpdGVzOg0KPj4gQW5kIEkgc3RpbGwgZmFpbCB0byB1bmRlcnN0YW5k
IHdoeSBldmVuIHRoZSBnZW5lcmFsIGlkZWEgb2YgUkFDSyBtYXR0ZXJzIHRvIEFRTSBhbGdvcml0
aG1zLA0KPj4gdHJhZmZpYyBjbGFzc2lmaWVycywgb3IgcHJpb3JpdHkgc2NoZWR1bGVycyBmb3Ig
dHJhZmZpYyB3aXRoIDEvcCBjb25nZXN0aW9uIGNvbnRyb2wgaW4gYSByb3V0ZXIuDQo+PiBSQUNL
IGhhcyBsb3RzIG9mIG1lcml0cywgYnV0IG1vc3Qgb2YgdGhlbSBhcmUgSU1ITyBlbnRpcmVseSB1
bnJlbGF0ZWQgdG8gdGhlIHZpc2lvbiBvZiBMNFMNCj4+IEnigJlkIHN1Z2dlc3QgdG8gZm9jdXMg
TDRTIG9uIHNvbHZpbmcgdGhlIGtleSBwcm9ibGVtcyBmb3IgdHJhZmZpYyB3aXRoIDEvcCBjb25n
ZXN0aW9uIGNvbnRyb2wuDQoNCkJvYiBCcmlzY29lIHJlc3BvbmRzOg0KPiBJJ3ZlIHByb21pc2Vk
IERhdmlkIEJsYWNrIGEgZnVsbCBhbnN3ZXIgdG8gdGhpcy4gU28gcGxzIHNlZSB0aGF0Lg0KDQpE
YXZpZCBCbGFjayAoYXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvcikgY29udGludWVzOg0KSSBm
aXJtbHkgYWdyZWUgd2l0aCBNaWNoYWVsIFNjaGFyZiBvbiB0aGlzIHRvcGljLCBpbmNsdWRpbmcg
dGhhdCBSQUNLIGhhcyBsb3RzIG9mIG1lcml0cy4gIFRoaXMgaXMgaXNzdWUgIzE4IGluIHRoZSB0
cmFja2VyLCBhbmQgaXTigJlzIGEgbG9uZy1zdGFuZGluZyBpc3N1ZSBhY3Jvc3MgbXVsdGlwbGUg
SUVURiBtZWV0aW5ncyDigKYNCg0KPiBCdXQgYnJpZWZseSwgYW4gaW1wb3J0YW50IGFkdmFuY2Ug
b2YgTDRTIGlzIHNjYWxhYmxlIHRocm91Z2hwdXQgKGl0J3MgaW4gdGhlIG5hbWUpLg0KPg0KPiBJ
dCB3b3VsZCBiZSBwb2ludGxlc3MgdG8gcmVtb3ZlIG9uZSBzY2FsaW5nIGxpbWl0YXRpb24gaWYg
aXQgd2FzIHJlcGxhY2VkIGJ5IHRoZSAzIER1cEFDSyBhcyBhIHRocm91Z2hwdXQgbGltaXRhdGlv
biAoQW1kYWhsJ3MgbGF3KS4NCg0KVGhlIGZ1bGwgYW5zd2VyIHdpbGwgbmVlZCB0byBhZGRyZXNz
IHRocmVlIHBvaW50cyB0byBzYXRpc2Z5IG1lIOKApg0KDQpQb2ludCAjMSBpcyB0byBleHBsYWlu
IGhvdyBhbmQgd2h5IHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbCByZXF1aXJlcyBzY2FsYWJs
ZSByZW9yZGVyaW5nIHRvbGVyYW5jZSwgYmV5b25kIHRoZSBmYWN0IHRoYXQgdGhlIHdvcmQg4oCc
c2NhbGFibGXigJ0gaGFzIGJlZW4gdXNlZCB0d2ljZS4gIFRoZSB0ZXh0IGluIEEuMS43IGluIHRo
ZSAtMDggdmVyc2lvbiBvZiB0aGUgZHJhZnQgZG9lcyBub3QgZG8gdGhhdCwgYW5kIHNpbXBseSBj
aXRpbmcgQW1kYWhs4oCZcyBsYXcgaXMgbm90IHN1ZmZpY2llbnQg4oCmIHRoZSBmdWxsIGFuc3dl
ciBuZWVkcyB0byBzcGVsbCBvdXQgdGhlIGRldGFpbGVkIHJlYXNvbmluZy4NCg0KUG9pbnQgIzIg
aXMgdG8gZXhwbGFpbiB0aGUgc2NvcGUgb2YgdGhlIHNjYWxhYmxlIHJlb3JkZXJpbmcgdG9sZXJh
bmNlIHJlcXVpcmVtZW50LiAgVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgdXNlIG9mIOKAnHJlcGxh
Y2VkIGJ54oCdIGluIHRoZSBhYm92ZSBzZW50ZW5jZSBhcHBlYXJzIHRvIGJlIG1pc2xlYWRpbmcs
IGluIHRoYXQgaXQgaW1wbGllcyBnbG9iYWwgcmVwbGFjZW1lbnQgZm9yIHRoZSBlbnRpcmUgSW50
ZXJuZXQuICBUaGUgdGV4dCBpbiBBLjEuNyBvZiB0aGUgZHJhZnQgaW5kaWNhdGVzIHRoYXQgdGhl
IHByaW1hcnkgbW90aXZhdGlvbiBmb3Igc2NhbGFibGUgcmVvcmRlcmluZyB0b2xlcmFuY2UgaXMg
Ym9uZGVkIGNoYW5uZWwgbGlua3MuICBCZXlvbmQgdGhhdCwgdGhpcyBtb3RpdmF0aW9uIGFwcGVh
cnMgdG8gYXJpc2Ugb25seSBvciBwcmltYXJpbHkgZnJvbSBSRiBsaW5rcyAoY29wcGVyIG9yIHdp
cmVsZXNzKSB3aGVyZSB0aGUgY2hhbm5lbHMgdGhhdCBhcmUgYm9uZGVkIHVzZSBkaWZmZXJlbnQg
cmFkaW8gZnJlcXVlbmNpZXMuICBJbiBjb250cmFzdCwgM0R1cEFDSyBkb2VzIG5vdCBhcHBlYXIg
dG8gY2F1c2UgcHJvYmxlbXMgZm9yIG9wdGljYWwgbGlua3MsIGUuZy4sIGRhdGEgY2VudGVyIEV0
aGVybmV0LCBvcHRpY2FsIFdBTiBhbmQgZmliZXItYmFzZWQgSVNQIHRlY2hub2xvZ2llcy4gICBU
aGUgdXBzaG90IGlzIHRoYXQgdGhlIHNjYWxhYmxlIHJlb3JkZXJpbmcgdG9sZXJhbmNlIHJlcXVp
cmVtZW50IGFwcGVhcnMgdG8gYmUgc3BlY2lmaWMgdG8gY2VydGFpbiBsaW5rIHRlY2hub2xvZ2ll
cyBhbmQgaGVuY2UgdG8gY2VydGFpbiBuZXR3b3JrcywgaS5lLiwgaXMgbm90IGdlbmVyYWxseSBh
cHBsaWNhYmxlIHRvIHRoZSBJbnRlcm5ldCBhcyBhIHdob2xlLg0KDQpQb2ludCAjMyBpcyB0byBl
eHBsYWluIHdoeSBpdOKAmXMgYSBnb29kIHRoaW5nIGZvciB0aGUgSW50ZXJuZXQgYXMgYSB3aG9s
ZSB0byBiaWZ1cmNhdGUgdGhlIHJlbGF0aXZlbHkgbmV3IDEvcC1jbGFzcyBjb25nZXN0aW9uIGNv
bnRyb2wgcHJvdG9jb2xzIGludG8gdGhvc2UgdGhhdCBjYW4gYmUgdXNlZCB3aXRoIEw0UyBsb3cg
bGF0ZW5jeSBzZXJ2aWNlIChpLmUuLCBUQ1AgUHJhZ3VlLCB3aGljaCBoYXMgc2NhbGFibGUgcmVv
cmRlcmluZyB0b2xlcmFuY2UpIGFuZCB0aG9zZSB0aGF0IGNhbuKAmXQgKGV2ZXJ5dGhpbmcgZWxz
ZSwgd2hpY2ggZG9lc27igJl0IGhhdmUgc2NhbGFibGUgcmVvcmRlcmluZyB0b2xlcmFuY2UpLiAg
SWYgdGhlIG92ZXJhbGwgZ29hbCBmb3IgdGhlIEludGVybmV0IGlzIChvciBvdWdodCB0byBiZSkg
dG8gaW5jcmVhc2UgdXNlIG9mIDEvcC1jbGFzcyBjb25nZXN0aW9uIGNvbnRyb2wsIGJhcnJpbmcg
bW9zdCBvZiB0aGUgY3VycmVudCAxL3AgcHJvdG9jb2xzIGZyb20gdGhlIEw0UyBsb3ctbGF0ZW5j
eSBzZXJ2aWNlIHNlZW1zIGNvdW50ZXJwcm9kdWN0aXZlLg0KDQo+IEluIGFuIGlkZWFsIHdvcmxk
LCB0aGUgdHdvIHdvdWxkIGJlIGRvbmUgc2VwYXJhdGVseS4gQnV0IEw0UyBjcmVhdGVzIGEgY2xl
YW4tc2xhdGUgb3Bwb3J0dW5pdHkgd2hlcmUNCj4gdGhlcmUncyBhIG5ldyBxdWV1ZSBhbmQgbmV3
IENDcywgYW5kIHRoZXJlIGlzIG5vIGRvd25zaWRlIHRvIHBsYWNpbmcgdGhlIHRpbWUtdW5pdHMg
cmVxdWlyZW1lbnQNCj4gb24gdGhlc2Ugc2VuZGVycyB0aGF0IGhhdmUgdG8gYmUgdXBkYXRlZCBh
bnl3YXkuDQoNCkhtbSDigJMgSSBoYXZlIHNldmVyZSBwcm9ibGVtcyB3aXRoIHRoYXQg4oCcbm8g
ZG93bnNpZGXigJ0gYXNzZXJ0aW9uIGJhc2VkIG9uIGNvbXBhcmluZyB0aGUgbG9uZyBwZXJpb2Qg
b2YgdGltZSB0aGF0IGl04oCZcyB0YWtlbiB0byBnZXQgVENQIFByYWd1ZSBpbnRvIGl04oCZcyBh
bG1vc3QtZG9uZSBzdGF0ZSB0byBob3cgcXVpY2tseSBtdWx0aXBsZSBwcm90b2NvbHMgaGF2ZSBi
ZWVuIG1vZGlmaWVkIHRvIHN1cHBvcnQgU0NFLiAgIE5vdCBvbmx5IGlzIEw0Uy1jb21wYXRpYmls
aXR5IG9mIGNvbmdlc3Rpb24gY29udHJvbCBub3QgYSDigJxzaW1wbGUgbWF0dGVyIG9mIHNvZnR3
YXJlIGRldmVsb3BtZW504oCdIGJ1dCAxL3AtY2xhc3MgY29uZ2VzdGlvbiBjb250cm9sIGZ1bmN0
aW9uYWxpdHkgYWxzbyBleGlzdHMgaW4gbW9zdCBFdGhlcm5ldCBOSUMgaGFyZHdhcmUvZmlybXdh
cmUgYXQgMjUgR2Ivc2VjIGFuZCBoaWdoZXIgc3BlZWRzLg0KDQo+IFRoZW4gZnV0dXJlIGV4cHRz
IHRoYXQgbWlnaHQgcmVseSBvbiBhbGwgaG9zdHMgdXNpbmcgdGltZS11bml0cyB3aWxsIG5vdCBi
ZSBwcmVjbHVkZWQuDQoNCkZ1dHVyZSBleHBlcmltZW50cyB3aXRoIHNjYWxhYmxlIHJlb3JkZXJp
bmcgdG9sZXJhbmNlIG91Z2h0IHRvIGJlIGV4YWN0bHkgdGhhdCwgZnV0dXJlIGV4cGVyaW1lbnRz
LCBJTUhPLiAgTDRTIHNob3VsZCBiZSBjb25jZW50cmF0aW5nIG9uIHNjYWxhYmxlIEludGVybmV0
IGNvbmdlc3Rpb24gY29udHJvbCBhbmQgbm90IGJlIHRyeWluZyB0byBmaXggb3RoZXIgbGluayBw
cm9ibGVtcyBiZWNhdXNlIGl0IGlzIGNvbnZlbmllbnQgdG8gZG8gc28gYXQgdGhlIHNhbWUgdGlt
ZS4NCg0KSSBhcG9sb2dpemUgc29tZXdoYXQgZm9yIHRoZSB0b25lIG9mIHRoaXMgbWVzc2FnZSwg
YnV0IG15IGNvbmNlcm5zIG9uIHRoaXMgdG9waWMgaGF2ZSBiZWVuIHJlcGVhdGVkbHkgZGlzbWlz
c2VkIG92ZXIgYSBudW1iZXIgb2YgSUVURiBtZWV0aW5ncywgYW5kIHRoZSBpbnRlbnQgb2YgdGhp
cyBtZXNzYWdl4oCZcyB0b25lIGlzIHRvIHB1dCBhIHN0b3AgdG8gdGhhdC4NCg0KVGhhbmtzLCAt
LURhdmlkIChhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKQ0KDQpGcm9tOiB0c3Z3ZyA8dHN2
d2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJvYiBCcmlzY29lDQpTZW50OiBXZWRu
ZXNkYXksIE5vdmVtYmVyIDIwLCAyMDE5IDQ6MTEgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWw7IGRy
YWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZEBpZXRmLm9yZw0KQ2M6IHRjcG1AaWV0Zi5vcmc7IHRz
dndnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBbdGNwbV0gZHJhZnQtaWV0Zi10c3Z3
Zy1lY24tbDRzLWlkDQoNCg0KW0VYVEVSTkFMIEVNQUlMXQ0KTWljaGFlbCwNCk9uIDExLzExLzIw
MTkgMTg6MTYsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNClNvIGNhbiB5b3UgY29uZmlybSB0aGF0
IGEgVENQIHNlbmRlciBjYW4gdXNlIHRoZSBMNFMgc2VydmljZSB3aXRob3V0IGltcGxlbWVudGlu
ZyBBY2NFQ04/IEkgYW0gYXNraW5nIGFnYWluIHNpbmNlIHRoZXJlIGhhcyBiZWVuIHNvbWUgcmVj
ZW50IGxpc3QgZGlzY3Vzc2lvbiBvbiB0aGF0LCBlLmcuLCBnaXZlbiB0aGUgcG9pbnRzIHJhaXNl
ZCBieSBTZWJhc3RpYW4uIEkgYW0gYSBiaXQgbG9zdCBoZXJlIG9uIHdoYXQgdGhlIGZ1dHVyZSBw
bGFuIGluIEw0UyBhY3R1YWxseSBpcy4NCkw0UyBuZWVkcyBmaW5lLWdyYWluZWQgZmVlZGJhY2ss
IGJ1dCBub3QgbmVjZXNzYXJpbHkgQWNjRUNOLg0KU28sIHdoaWxlIEFjY0VDTiBpcyB0aGUgd2F5
IHRvIGRvIGZpbmUtZ3JhaW5lZCBmZWVkYmFjaywgTDRTIG5lZWRzIEFjY0VDTi4NCg0KSSB0b29r
IHlvdXIgcXVlc3Rpb24gdG8gYmUgaW4gYSBjb250ZXh0IHdoZXJlIHNvbWV0aGluZyBlbHNlIG1p
Z2h0IGhhdmUgcmVwbGFjZWQgQWNjRUNOIGluIHRoZSBmdXR1cmUgZm9yIGZpbmUtZ3JhaW5lZCBm
ZWVkYmFjay4gSW4gdGhhdCBjYXNlLCBMNFMgd291bGQgbmVlZCB0aGF0IG5ldyBzaGlueSB0aGlu
ZyBpbnN0ZWFkLCBhbmQgd291bGQgbm90IHRoZW4gbmVlZCBBY2NFQ04uDQoNCg0KDQpBbmQgSSBz
dGlsbCBmYWlsIHRvIHVuZGVyc3RhbmQgd2h5IGV2ZW4gdGhlIGdlbmVyYWwgaWRlYSBvZiBSQUNL
IG1hdHRlcnMgdG8gQVFNIGFsZ29yaXRobXMsIHRyYWZmaWMgY2xhc3NpZmllcnMsIG9yIHByaW9y
aXR5IHNjaGVkdWxlcnMgZm9yIHRyYWZmaWMgd2l0aCAxL3AgY29uZ2VzdGlvbiBjb250cm9sIGlu
IGEgcm91dGVyLiBSQUNLIGhhcyBsb3RzIG9mIG1lcml0cywgYnV0IG1vc3Qgb2YgdGhlbSBhcmUg
SU1ITyBlbnRpcmVseSB1bnJlbGF0ZWQgdG8gdGhlIHZpc2lvbiBvZiBMNFMuIEnigJlkIHN1Z2dl
c3QgdG8gZm9jdXMgTDRTIG9uIHNvbHZpbmcgdGhlIGtleSBwcm9ibGVtcyBmb3IgdHJhZmZpYyB3
aXRoIDEvcCBjb25nZXN0aW9uIGNvbnRyb2wuDQoNCkkndmUgcHJvbWlzZWQgRGF2aWQgQmxhY2sg
YSBmdWxsIGFuc3dlciB0byB0aGlzLiBTbyBwbHMgc2VlIHRoYXQuDQpCdXQgYnJpZWZseSwgYW4g
aW1wb3J0YW50IGFkdmFuY2Ugb2YgTDRTIGlzIHNjYWxhYmxlIHRocm91Z2hwdXQgKGl0J3MgaW4g
dGhlIG5hbWUpLg0KDQpJdCB3b3VsZCBiZSBwb2ludGxlc3MgdG8gcmVtb3ZlIG9uZSBzY2FsaW5n
IGxpbWl0YXRpb24gaWYgaXQgd2FzIHJlcGxhY2VkIGJ5IHRoZSAzIER1cEFDSyBhcyBhIHRocm91
Z2hwdXQgbGltaXRhdGlvbiAoQW1kYWhsJ3MgbGF3KS4gSW4gYW4gaWRlYWwgd29ybGQsIHRoZSB0
d28gd291bGQgYmUgZG9uZSBzZXBhcmF0ZWx5LiBCdXQgTDRTIGNyZWF0ZXMgYSBjbGVhbi1zbGF0
ZSBvcHBvcnR1bml0eSB3aGVyZSB0aGVyZSdzIGEgbmV3IHF1ZXVlIGFuZCBuZXcgQ0NzLCBhbmQg
dGhlcmUgaXMgbm8gZG93bnNpZGUgdG8gcGxhY2luZyB0aGUgdGltZS11bml0cyByZXF1aXJlbWVu
dCBvbiB0aGVzZSBzZW5kZXJzIHRoYXQgaGF2ZSB0byBiZSB1cGRhdGVkIGFueXdheS4gVGhlbiBm
dXR1cmUgZXhwdHMgdGhhdCBtaWdodCByZWx5IG9uIGFsbCBob3N0cyB1c2luZyB0aW1lLXVuaXRz
IHdpbGwgbm90IGJlIHByZWNsdWRlZC4NCg0KVGhpcyBpcyBhbGwgaW4gdGhlIGxhdGVzdCB0ZXh0
IGluIHRoZSBhcHBlbmRpeC4NCg0KDQpCb2INCg0KDQpNaWNoYWVsICh3aXRoIG5vIGhhdCkNCg0K
DQoNCkZyb206IEJvYiBCcmlzY29lIDxpbkBib2JicmlzY29lLm5ldD48bWFpbHRvOmluQGJvYmJy
aXNjb2UubmV0Pg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxOSAxMDozOSBBTQ0KVG86
IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjxtYWlsdG86
TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRz
LWlkQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWRAaWV0Zi5vcmc+
DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz47IHRzdndnQGlldGYub3Jn
PG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIGRyYWZ0LWlldGYt
dHN2d2ctZWNuLWw0cy1pZA0KDQpNaWNoYWVsLA0KDQpPbiBhIHNpbWlsYXIgcXVlc3Rpb24gb2Yg
ZGVwZW5kZW5jeSBiZXR3ZWVuIGV4cGVyaW1lbnRzLCBJIHRoaW5rIHlvdSBhbHNvIGV4cHJlc3Nl
ZCBjb25jZXJuIHRoYXQgZWNuLWw0cy1pZCBkZXBlbmRzIG9uIHRoZSBSQUNLIGV4cGVyaW1lbnQu
IEhvd2V2ZXIsIGVjbi1sNHMtaWQgb25seSByZWZlcnMgdG8gUkFDSyBpbmZvcm1hdGl2ZWx5LCBi
ZWNhdXNlIGl0IG9ubHkgdXNlcyB0aGUgZ2VuZXJhbCBpZGVhIGJlaGluZCBSQUNLLiBKdXN0IGFz
IHF1aWMtcmVjb3ZlcnkgKHN0ZHMgdHJhY2spIHVzZXMgdGhlIGdlbmVyYWwgaWRlYSBiZWhpbmQg
UkFDSyAoZXhwdCB0cmFjaykgYnkgcmVmZXJyaW5nIHRvIGl0IGluZm9ybWF0aXZlbHkuDQoNCg0K
DQpCb2INCk9uIDA0LzExLzIwMTkgMTU6MjYsIEJvYiBCcmlzY29lIHdyb3RlOg0KTWljaGFlbCwN
Cg0KVGhhbmsgeW91IGZvciBwb2ludGluZyB0aGlzIG91dCwgbWFueSBtb250aHMgYWdvIG5vdy4N
Cg0KVGhlcmUgaXMgbm8gZm9ybWFsIGRlcGVuZGVuY3kgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24t
bDRzLWlkIG9uIEFjY0VDTiwgYXMgZXhwbGFpbmVkIGJlbG93Lg0KDQpGb3IgYW55IHRyYW5zcG9y
dCBwcm90b2NvbCB0byBjb21wbHkgd2l0aCBlY24tbDRzLWlkLCBpdCBuZWVkcyBzdWZmaWNpZW50
bHkgYWNjdXJhdGUgZmVlZGJhY2sgb2YgdGhlIGV4dGVudCBvZiBDRSBtYXJraW5nIG9uIHRoZSBm
b3J3YXJkIHBhdGguIFlvdSBwb2ludGluZyB0aGlzIG91dCBoYXMgbWFkZSBtZSByZWFsaXplIHRo
YXQgdGhlcmUgaXMgYSAnbmVlZHMnIHRoYXQgc2hvdWxkIGJlIGEgJ01VU1QnIGluIHRoZSBzcGVj
Og0KDQo0LjIuICBQcmVyZXF1aXNpdGUgVHJhbnNwb3J0IEZlZWRiYWNrDQoNCkNVUlJFTlQ6DQoN
CiAgIEluIGdlbmVyYWwsIGEgc2NhbGFibGUgY29uZ2VzdGlvbiBjb250cm9sLCBuZWVkcyBmZWVk
YmFjayBvZiB0aGUNCg0KICAgZXh0ZW50IG9mIENFIG1hcmtpbmcgb24gdGhlIGZvcndhcmQgcGF0
aC4NClBST1BPU0VEOg0KDQogICBJbiBnZW5lcmFsLCBmb3IgYSB0cmFuc3BvcnQgcHJvdG9jb2wg
dG8gcHJvdmlkZSBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wsDQoNCiAgIGl0IE1VU1QgcHJv
dmlkZSBmZWVkYmFjayBvZiB0aGUNCg0KICAgZXh0ZW50IG9mIENFIG1hcmtpbmcgb24gdGhlIGZv
cndhcmQgcGF0aC4NCg0KSG93ZXZlciwgZWNuLWw0cy1pZCBvbmx5IHNwZWNpZmllcyB0aGUgcmVx
dWlyZW1lbnRzIHRoYXQgYW55IEw0UyB0cmFuc3BvcnQgcHJvdG9jb2wgd291bGQgaGF2ZSB0byBz
YXRpc2Z5LiBJdCBkb2VzIG5vdCBkZWZpbmUgYSB0cmFuc3BvcnQgcHJvdG9jb2wgaXRzZWxmLiBT
byBBY2NFQ04gaXMgbm90IGEgbm9ybWF0aXZlIHJlZi4gU28gSSBhbSBhbHNvIGFsdGVyaW5nIHRo
ZSB0ZXh0IGEgbGl0dGxlIGZ1cnRoZXIgZG93biwgd2hlcmUgaXQgcmVmZXJzIHRvIEFjY0VDTiwg
YXMgZm9sbG93czoNCg0KQ1VSUkVOVDoNCg0KICBUQ1A6ICBTdXBwb3J0IGZvciBhY2N1cmF0ZSBF
Q04gZmVlZGJhY2sgKEFjY0VDTg0KDQogICAgICBbSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY248
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0w
NyNyZWYtSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY24+XSkgYnkgYm90aCBlbmRzIGlzIGEgcHJl
cmVxdWlzaXRlIGZvcg0KDQogICAgICBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wuDQpQUk9Q
T1NFRDoNCg0KICBUQ1A6ICBTdXBwb3J0IGZvciBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sgKHN1Y2gg
YXMgQWNjRUNODQoNCiAgICAgIFtJLUQuaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbjxodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA3I3JlZi1JLUQu
aWV0Zi10Y3BtLWFjY3VyYXRlLWVjbj5dKSBieSBib3RoIGVuZHMgaXMgYSBwcmVyZXF1aXNpdGUg
Zm9yDQoNCiAgICAgIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbC4NClRoYW5rcyBhZ2FpbiBm
b3IgcG9pbnRpbmcgdGhpcyBvdXQuDQpEZXBlbmRlbmNpZXMgYmV0d2VlbiBFeHBlcmltZW50cw0K
DQpUaGUgY2FzZSBvZiBUQ1AgUHJhZ3VlIHByb3ZpZGVzIGEgY291bnRlci1hcmd1bWVudDoNCg0K
VENQIFByYWd1ZSBjb3VsZCBiZSBzcGVjaWZpZWQgaW4gb25lIG1vbm9saXRoaWMgZXhwZXJpbWVu
dGFsIHNwZWMuDQpPciBpdCBjb3VsZCBiZSBicm9rZW4gZG93biBpbnRvIGV4cGVyaW1lbnRhbCBj
b21wb25lbnRzLCBhbmQgYSB0b3AgbGV2ZWwgZXhwZXJpbWVudGFsIHNwZWMgdGhhdCBwdWxscyB0
aGVtIGFsbCB0b2dldGhlci4NCg0KVGhlIGxhdHRlciBvcHRpb24gd291bGQgY3JlYXRlIG11bHRp
cGxlIGRlcGVuZGVuY2llcyBvZiBvbmUgZXhwZXJpbWVudCBvbiBvdGhlcnMuIEJ1dCBJTUhPIHN1
Y2ggbW9kdWxhcml0eSBpcyBwcmVmZXJhYmxlIHRvIGEgbW9ub2xpdGhpYyBzcGVjLiBFc3BlY2lh
bGx5IGlmIHNvbWUgb2YgdGhlIGNvbXBvbmVudHMgbWlnaHQgaGF2ZSBvdGhlciB1c2VzIG91dHNp
ZGUgb2YgVENQIFByYWd1ZSAod2hpY2ggaXMgZXhhY3RseSB0aGUgY2FzZSB3aXRoIFRDUCBQcmFn
dWUsIGUuZy4gQWNjRUNOLCBFQ04rKywgUkFDSyBhcmUgYWxsIHBvdGVudGlhbGx5IHBhcnRzIG9m
IHRoZSBiYXNlIFRDUCBzdGFjaywgYW5kIHBhY2VkLWNoaXJwaW5nIGlzIHBvdGVudGlhbGx5IHVz
YWJsZSBieSBhbnkgb3RoZXIgY29uZ2VzdGlvbiBjb250cm9sIC0gdGhlc2UgYXJlIGFsbCBleHBl
cmltZW50YWwgY29tcG9uZW50IHBhcnRzKS4NCg0KQXMgYW5vdGhlciBleGFtcGxlLCBCQlIgd2Fz
IHdyaXR0ZW4gdXAgYXMgYW4gZXhwZXJpbWVudGFsIGRyYWZ0LCBhbmQgdGhlIExpbnV4IGltcGxl
bWVudGF0aW9uIHVzZXMgUkFDSyAoYWx0aG91Z2ggbm90IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQp
IHdoaWNoIGlzIGVuYWJsZWQgYnkgZGVmYXVsdCBpbiBMaW51eC4NCg0KU3VjaCBtb2R1bGFyaXR5
IGlzIGdvb2QuDQoNCg0KQm9iDQoNCg0KT24gMjQvMDMvMjAxOSAxOToxNSwgU2NoYXJmLCBNaWNo
YWVsIHdyb3RlOg0KDQpJIGhhdmUganVzdCBwYXJzZWQgdGhyb3VnaCBkcmFmdC1pZXRmLXRzdndn
LWVjbi1sNHMtaWQtMDYgYW5kIEkgcnVuIGludG8gdGhlIGZvbGxvd2luZyBzZW50ZW5jZToNCg0K
DQoNClRDUDogIFN1cHBvcnQgZm9yIGFjY3VyYXRlIEVDTiBmZWVkYmFjayAoQWNjRUNODQoNCiAg
ICAgIFtJLUQuaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbl0pIGJ5IGJvdGggZW5kcyBpcyBhIHByZXJl
cXVpc2l0ZSBmb3INCg0KICAgICAgc2NhbGFibGUgY29uZ2VzdGlvbiBjb250cm9sLiAgVGhlcmVm
b3JlLCB0aGUgcHJlc2VuY2Ugb2YgRUNUKDEpIGluDQoNCiAgICAgIHRoZSBJUCBoZWFkZXJzIGV2
ZW4gaW4gb25lIGRpcmVjdGlvbiBvZiBhIFRDUCBjb25uZWN0aW9uIHdpbGwNCg0KICAgICAgaW1w
bHkgdGhhdCBib3RoIGVuZHMgc3VwcG9ydCBBY2NFQ04uICBIb3dldmVyLCB0aGUgY29udmVyc2Ug
ZG9lcw0KDQogICAgICBub3QgYXBwbHkuICBTbyBldmVuIGlmIGJvdGggZW5kcyBzdXBwb3J0IEFj
Y0VDTiwgZWl0aGVyIG9mIHRoZSB0d28NCg0KICAgICAgZW5kcyBjYW4gY2hvb3NlIG5vdCB0byB1
c2UgYSBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wsIHdoYXRldmVyDQoNCiAgICAgIHRoZSBv
dGhlciBlbmQncyBjaG9pY2UuDQoNCg0KDQpDYW4gdGhlIGF1dGhvcnMgcGxlYXNlIGNsYXJpZnkg
d2hldGhlciB0aGVyZSBpcyBhIG5vcm1hdGl2ZSBkZXBlbmRlbmN5IG9mIGRyYWZ0LWlldGYtdHN2
d2ctZWNuLWw0cy1pZCBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPw0KDQoNCg0KSWYg
c28sIEkgdGhpbmsgdGhlIGZvcm1hbCBkZXBlbmRlbmN5IG9uIGltcGxlbWVudGluZyBBY2NFQ04g
aGFzIHRvIGJlIHNwZWx0IG91dCBleHBsaWNpdGx5LiBJbiB0aGF0IGNhc2UsIEkgd291bGQgYmUg
bG9va2luZyBmb3IgYSBzdGF0ZW1lbnQgb2YgdGhlIHNvcnQgIk1VU1QvU0hPVUxEL01BWSBpbXBs
ZW1lbnQgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbiIgc29tZXdoZXJlLiBJZiBzdWNoIGEg
cmVxdWlyZW1lbnQgZG9lcyBub3QgZXhpc3QsIEkgdGhpbmsgdGhlIGFib3ZlIHBhcmFncmFwaCBp
cyBjb25mdXNpbmcuDQoNCg0KDQpBcyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yLCBJIHdhbnQgdG8g
bm90ZSB0aGF0IEkgZGlzYWdyZWUgd2l0aCBtYW5kYXRvcnkgZGVwZW5kZW5jaWVzIGJldHdlZW4g
ZXhwZXJpbWVudHMuIEkgaGF2ZSBtZW50aW9uZWQgaW4gdGhlIHBhc3QgdGhhdCBJIGJlbGlldmUg
dGhhdCBkaWZmZXJlbnQgZXhwZXJpbWVudHMgbXVzdCBiZSBzcGVjaWZpZWQgaW5kZXBlbmRlbnRs
eSBvZiBlYWNoIG90aGVyIGFuZCBzaG91bGQgYmUgaW1wbGVtZW50YWJsZSBpbmRlcGVuZGVudGx5
IG9mIGVhY2ggb3RoZXIsIHNwZWNpZmljYWxseSBhbHNvIHRvIGJlIGFibGUgdG8gZmFpbCBpbmRl
cGVuZGVudGx5IG9mIGVhY2ggb3RoZXIuIEl0IGlzIHBvc3NpYmxlIHRoYXQgSSBhbSBpbiB0aGUg
cm91Z2ggcGFydCBvZiB0aGUgY29uc2Vuc3VzLiBCdXQgSSBoYXZlbid0IGNoYW5nZWQgbXkgbWlu
ZC4NCg0KDQoNCk1pY2hhZWwgKGFzIGluZGl2aWR1YWwpDQoNCg0KDQoNCg0KDQoNCg0KLS0NCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw
Oi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2Ug
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQoN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KdGNw
bSBtYWlsaW5nIGxpc3QNCg0KdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCg0KDQotLQ0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6
Ly9ib2JicmlzY29lLm5ldC8NCg==

--_000_MN2PR19MB4045AB7A48C0039B5E3856AC834F0MN2PR19MB4045namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCI7DQoJcGFub3Nl
LTE6MiAxNSAzIDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0
aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmgzDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMgQ2hhciI7
DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEzLjVw
dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazsN
Cglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi
bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z
by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn
aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0
OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1u
YW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxl
LWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzFGMzc2Mzt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD
b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLmJlcnNjaHJpZnQzLCBsaS5iZXJzY2hyaWZ0Mywg
ZGl2LmJlcnNjaHJpZnQzDQoJe21zby1zdHlsZS1uYW1lOiLDnGJlcnNjaHJpZnQgMyI7DQoJbXNv
LXN0eWxlLWxpbms6IsOcYmVyc2NocmlmdCAzIFpjaG4iOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz
IE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5iZXJzY2hyaWZ0M1pjaG4N
Cgl7bXNvLXN0eWxlLW5hbWU6IsOcYmVyc2NocmlmdCAzIFpjaG4iOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLDnGJlcnNjaHJpZnQgMyI7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNEQ3ODt9DQpwLkhUTUxWb3Jm
b3JtYXRpZXJ0LCBsaS5IVE1MVm9yZm9ybWF0aWVydCwgZGl2LkhUTUxWb3Jmb3JtYXRpZXJ0DQoJ
e21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQiOw0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxWb3Jmb3JtYXRpZXJ0WmNobg0KCXtt
c28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IjsNCglmb250LWZh
bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiM5OTMzNjY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRl
eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA1Ni43cHQgNzAu
ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWwgU2NoYXJmIHdyaXRlczo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsgQW5kIEkgc3RpbGwgZmFpbCB0byB1bmRlcnN0YW5k
IHdoeSBldmVuIHRoZSBnZW5lcmFsIGlkZWEgb2YgUkFDSyBtYXR0ZXJzIHRvIEFRTSBhbGdvcml0
aG1zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyB0cmFmZmljIGNsYXNzaWZpZXJzLCBvciBw
cmlvcml0eSBzY2hlZHVsZXJzIGZvciB0cmFmZmljIHdpdGggMS9wIGNvbmdlc3Rpb24gY29udHJv
bCBpbiBhIHJvdXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsgUkFDSyBoYXMgbG90cyBv
ZiBtZXJpdHMsIGJ1dCBtb3N0IG9mIHRoZW0gYXJlIElNSE8gZW50aXJlbHkgdW5yZWxhdGVkIHRv
IHRoZSB2aXNpb24gb2YgTDRTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IEnigJlkIHN1Z2dl
c3QgdG8gZm9jdXMgTDRTIG9uIHNvbHZpbmcgdGhlIGtleSBwcm9ibGVtcyBmb3IgdHJhZmZpYyB3
aXRoIDEvcCBjb25nZXN0aW9uIGNvbnRyb2wuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJvYiBCcmlzY29lIHJl
c3BvbmRzOiAmbmJzcDs8YnI+DQomZ3Q7IEkndmUgcHJvbWlzZWQgRGF2aWQgQmxhY2sgYSBmdWxs
IGFuc3dlciB0byB0aGlzLiBTbyBwbHMgc2VlIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojOTkzMzY2Ij5EYXZpZCBCbGFjayAoYXMgYW4gaW5kaXZpZHVhbCBjb250cmli
dXRvcikgY29udGludWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2Ij5JIGZpcm1seSBhZ3JlZSB3aXRoIE1p
Y2hhZWwgU2NoYXJmIG9uIHRoaXMgdG9waWMsIGluY2x1ZGluZyB0aGF0IFJBQ0sgaGFzIGxvdHMg
b2YgbWVyaXRzLiZuYnNwOyBUaGlzIGlzIGlzc3VlICMxOCBpbiB0aGUgdHJhY2tlciwgYW5kIGl0
4oCZcyBhIGxvbmctc3RhbmRpbmcgaXNzdWUgYWNyb3NzDQogbXVsdGlwbGUgSUVURiBtZWV0aW5n
cyDigKY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCiZndDsgQnV0IGJyaWVmbHks
IGFuIGltcG9ydGFudCBhZHZhbmNlIG9mIEw0UyBpcyBzY2FsYWJsZSB0aHJvdWdocHV0IChpdCdz
IGluIHRoZSBuYW1lKS4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCB3b3VsZCBiZSBwb2ludGxl
c3MgdG8gcmVtb3ZlIG9uZSBzY2FsaW5nIGxpbWl0YXRpb24gaWYgaXQgd2FzIHJlcGxhY2VkIGJ5
IHRoZSAzIER1cEFDSyBhcyBhIHRocm91Z2hwdXQgbGltaXRhdGlvbiAoQW1kYWhsJ3MgbGF3KS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2Ij5UaGUgZnVsbCBhbnN3ZXIgd2lsbCBuZWVkIHRv
IGFkZHJlc3MgdGhyZWUgcG9pbnRzIHRvIHNhdGlzZnkgbWUg4oCmPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2Ij5Qb2ludCAjMSBpcyB0byBleHBsYWluIGhvdyBhbmQg
d2h5IHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbCByZXF1aXJlcyBzY2FsYWJsZSByZW9yZGVy
aW5nIHRvbGVyYW5jZSwgYmV5b25kIHRoZSBmYWN0IHRoYXQgdGhlIHdvcmQg4oCcc2NhbGFibGXi
gJ0gaGFzIGJlZW4gdXNlZA0KIHR3aWNlLiZuYnNwOyBUaGUgdGV4dCBpbiBBLjEuNyBpbiB0aGUg
LTA4IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGRvZXMgbm90IGRvIHRoYXQsIGFuZCBzaW1wbHkgY2l0
aW5nIEFtZGFobOKAmXMgbGF3IGlzIG5vdCBzdWZmaWNpZW50IOKApiB0aGUgZnVsbCBhbnN3ZXIg
bmVlZHMgdG8gc3BlbGwgb3V0IHRoZSBkZXRhaWxlZCByZWFzb25pbmcuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMz
NjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2Ij5Qb2ludCAjMiBpcyB0byBleHBsYWluIHRoZSBz
Y29wZSBvZiB0aGUgc2NhbGFibGUgcmVvcmRlcmluZyB0b2xlcmFuY2UgcmVxdWlyZW1lbnQuJm5i
c3A7IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHVzZSBvZiDigJxyZXBsYWNlZCBieeKAnSBpbiB0
aGUgYWJvdmUgc2VudGVuY2UgYXBwZWFycw0KIHRvIGJlIG1pc2xlYWRpbmcsIGluIHRoYXQgaXQg
aW1wbGllcyBnbG9iYWwgcmVwbGFjZW1lbnQgZm9yIHRoZSBlbnRpcmUgSW50ZXJuZXQuJm5ic3A7
IFRoZSB0ZXh0IGluIEEuMS43IG9mIHRoZSBkcmFmdCBpbmRpY2F0ZXMgdGhhdCB0aGUgcHJpbWFy
eSBtb3RpdmF0aW9uIGZvciBzY2FsYWJsZSByZW9yZGVyaW5nIHRvbGVyYW5jZSBpcyBib25kZWQg
Y2hhbm5lbCBsaW5rcy4mbmJzcDsgQmV5b25kIHRoYXQsIHRoaXMgbW90aXZhdGlvbiBhcHBlYXJz
IHRvIGFyaXNlDQogb25seSBvciBwcmltYXJpbHkgZnJvbSBSRiBsaW5rcyAoY29wcGVyIG9yIHdp
cmVsZXNzKSB3aGVyZSB0aGUgY2hhbm5lbHMgdGhhdCBhcmUgYm9uZGVkIHVzZSBkaWZmZXJlbnQg
cmFkaW8gZnJlcXVlbmNpZXMuJm5ic3A7IEluIGNvbnRyYXN0LCAzRHVwQUNLIGRvZXMgbm90IGFw
cGVhciB0byBjYXVzZSBwcm9ibGVtcyBmb3Igb3B0aWNhbCBsaW5rcywgZS5nLiwgZGF0YSBjZW50
ZXIgRXRoZXJuZXQsIG9wdGljYWwgV0FOIGFuZCBmaWJlci1iYXNlZCBJU1ANCiB0ZWNobm9sb2dp
ZXMuJm5ic3A7Jm5ic3A7IFRoZSB1cHNob3QgaXMgdGhhdCB0aGUgc2NhbGFibGUgcmVvcmRlcmlu
ZyB0b2xlcmFuY2UgcmVxdWlyZW1lbnQgYXBwZWFycyB0byBiZSBzcGVjaWZpYyB0byBjZXJ0YWlu
IGxpbmsgdGVjaG5vbG9naWVzIGFuZCBoZW5jZSB0byBjZXJ0YWluIG5ldHdvcmtzLCBpLmUuLCBp
cyBub3QgZ2VuZXJhbGx5IGFwcGxpY2FibGUgdG8gdGhlIEludGVybmV0IGFzIGEgd2hvbGUuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2Ij5Qb2ludCAjMyBpcyB0byBl
eHBsYWluIHdoeSBpdOKAmXMgYSBnb29kIHRoaW5nIGZvciB0aGUgSW50ZXJuZXQgYXMgYSB3aG9s
ZSB0byBiaWZ1cmNhdGUgdGhlIHJlbGF0aXZlbHkgbmV3IDEvcC1jbGFzcyBjb25nZXN0aW9uIGNv
bnRyb2wgcHJvdG9jb2xzIGludG8gdGhvc2UgdGhhdA0KIGNhbiBiZSB1c2VkIHdpdGggTDRTIGxv
dyBsYXRlbmN5IHNlcnZpY2UgKGkuZS4sIFRDUCBQcmFndWUsIHdoaWNoIGhhcyBzY2FsYWJsZSBy
ZW9yZGVyaW5nIHRvbGVyYW5jZSkgYW5kIHRob3NlIHRoYXQgY2Fu4oCZdCAoZXZlcnl0aGluZyBl
bHNlLCB3aGljaCBkb2VzbuKAmXQgaGF2ZSBzY2FsYWJsZSByZW9yZGVyaW5nIHRvbGVyYW5jZSku
Jm5ic3A7IElmIHRoZSBvdmVyYWxsIGdvYWwgZm9yIHRoZSBJbnRlcm5ldCBpcyAob3Igb3VnaHQg
dG8gYmUpIHRvIGluY3JlYXNlDQogdXNlIG9mIDEvcC1jbGFzcyBjb25nZXN0aW9uIGNvbnRyb2ws
IGJhcnJpbmcgbW9zdCBvZiB0aGUgY3VycmVudCAxL3AgcHJvdG9jb2xzIGZyb20gdGhlIEw0UyBs
b3ctbGF0ZW5jeSBzZXJ2aWNlIHNlZW1zIGNvdW50ZXJwcm9kdWN0aXZlLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij4mZ3Q7IEluIGFuIGlkZWFsIHdvcmxkLCB0aGUgdHdvIHdvdWxkIGJlIGRvbmUgc2VwYXJhdGVs
eS4gQnV0IEw0UyBjcmVhdGVzIGEgY2xlYW4tc2xhdGUgb3Bwb3J0dW5pdHkgd2hlcmU8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn
dDsgdGhlcmUncyBhIG5ldyBxdWV1ZSBhbmQgbmV3IENDcywgYW5kIHRoZXJlIGlzIG5vIGRvd25z
aWRlIHRvIHBsYWNpbmcgdGhlIHRpbWUtdW5pdHMgcmVxdWlyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgb24gdGhl
c2Ugc2VuZGVycyB0aGF0IGhhdmUgdG8gYmUgdXBkYXRlZCBhbnl3YXkuDQo8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6Izk5MzM2NiI+SG1tIOKAkyBJIGhhdmUgc2V2ZXJlIHByb2JsZW1zIHdpdGggdGhhdCDigJxu
byBkb3duc2lkZeKAnSBhc3NlcnRpb24gYmFzZWQgb24gY29tcGFyaW5nIHRoZSBsb25nIHBlcmlv
ZCBvZiB0aW1lIHRoYXQgaXTigJlzIHRha2VuIHRvIGdldCBUQ1AgUHJhZ3VlIGludG8gaXTigJlz
IGFsbW9zdC1kb25lDQogc3RhdGUgdG8gaG93IHF1aWNrbHkgbXVsdGlwbGUgcHJvdG9jb2xzIGhh
dmUgYmVlbiBtb2RpZmllZCB0byBzdXBwb3J0IFNDRS4mbmJzcDsmbmJzcDsgTm90IG9ubHkgaXMg
TDRTLWNvbXBhdGliaWxpdHkgb2YgY29uZ2VzdGlvbiBjb250cm9sIG5vdCBhIOKAnHNpbXBsZSBt
YXR0ZXIgb2Ygc29mdHdhcmUgZGV2ZWxvcG1lbnTigJ0gYnV0IDEvcC1jbGFzcyBjb25nZXN0aW9u
IGNvbnRyb2wgZnVuY3Rpb25hbGl0eSBhbHNvIGV4aXN0cyBpbiBtb3N0IEV0aGVybmV0IE5JQyBo
YXJkd2FyZS9maXJtd2FyZQ0KIGF0IDI1IEdiL3NlYyBhbmQgaGlnaGVyIHNwZWVkcy48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFRoZW4gZnV0dXJlIGV4cHRzIHRoYXQgbWlnaHQg
cmVseSBvbiBhbGwgaG9zdHMgdXNpbmcgdGltZS11bml0cyB3aWxsIG5vdCBiZSBwcmVjbHVkZWQu
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPkZ1dHVyZSBleHBlcmltZW50cyB3aXRoIHNj
YWxhYmxlIHJlb3JkZXJpbmcgdG9sZXJhbmNlIG91Z2h0IHRvIGJlIGV4YWN0bHkgdGhhdCwgZnV0
dXJlIGV4cGVyaW1lbnRzLCBJTUhPLiZuYnNwOyBMNFMgc2hvdWxkIGJlIGNvbmNlbnRyYXRpbmcg
b24gc2NhbGFibGUgSW50ZXJuZXQgY29uZ2VzdGlvbg0KIGNvbnRyb2wgYW5kIG5vdCBiZSB0cnlp
bmcgdG8gZml4IG90aGVyIGxpbmsgcHJvYmxlbXMgYmVjYXVzZSBpdCBpcyBjb252ZW5pZW50IHRv
IGRvIHNvIGF0IHRoZSBzYW1lIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojOTkzMzY2Ij5JIGFwb2xvZ2l6ZSBzb21ld2hhdCBmb3IgdGhlIHRvbmUgb2YgdGhpcyBtZXNz
YWdlLCBidXQgbXkgY29uY2VybnMgb24gdGhpcyB0b3BpYyBoYXZlIGJlZW4gcmVwZWF0ZWRseSBk
aXNtaXNzZWQgb3ZlciBhIG51bWJlciBvZiBJRVRGIG1lZXRpbmdzLCBhbmQgdGhlIGludGVudA0K
IG9mIHRoaXMgbWVzc2FnZeKAmXMgdG9uZSBpcyB0byBwdXQgYSBzdG9wIHRvIHRoYXQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzM2NiI+VGhhbmtzLCAtLURh
dmlkIChhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMz
NjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IHRzdndnICZsdDt0c3Z3Zy1ib3VuY2VzQGll
dGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Cb2IgQnJpc2NvZTxicj4NCjxiPlNlbnQ6
PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDIwLCAyMDE5IDQ6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+
IFNjaGFyZiwgTWljaGFlbDsgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkQGlldGYub3JnPGJy
Pg0KPGI+Q2M6PC9iPiB0Y3BtQGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSZTogW3RzdndnXSBbdGNwbV0gZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojQ0Ux
MTI2Ij5bRVhURVJOQUwgRU1BSUxdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtjb2xvcjojQ0UxMTI2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMS8xMS8yMDE5IDE4OjE2
LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIGNhbiB5b3Ug
Y29uZmlybSB0aGF0IGEgVENQIHNlbmRlciBjYW4gdXNlIHRoZSBMNFMgc2VydmljZSB3aXRob3V0
IGltcGxlbWVudGluZyBBY2NFQ04/IEkgYW0gYXNraW5nIGFnYWluIHNpbmNlIHRoZXJlIGhhcyBi
ZWVuIHNvbWUgcmVjZW50IGxpc3QgZGlzY3Vzc2lvbiBvbg0KIHRoYXQsIGUuZy4sIGdpdmVuIHRo
ZSBwb2ludHMgcmFpc2VkIGJ5IFNlYmFzdGlhbi4gSSBhbSBhIGJpdCBsb3N0IGhlcmUgb24gd2hh
dCB0aGUgZnV0dXJlIHBsYW4gaW4gTDRTIGFjdHVhbGx5IGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
TDRTIG5lZWRzIGZpbmUtZ3JhaW5lZCBmZWVkYmFjaywgYnV0IG5vdCBuZWNlc3NhcmlseSBBY2NF
Q04uDQo8YnI+DQpTbywgd2hpbGUgQWNjRUNOIGlzIHRoZSB3YXkgdG8gZG8gZmluZS1ncmFpbmVk
IGZlZWRiYWNrLCBMNFMgbmVlZHMgQWNjRUNOLiA8YnI+DQo8YnI+DQpJIHRvb2sgeW91ciBxdWVz
dGlvbiB0byBiZSBpbiBhIGNvbnRleHQgd2hlcmUgc29tZXRoaW5nIGVsc2UgbWlnaHQgaGF2ZSBy
ZXBsYWNlZCBBY2NFQ04gaW4gdGhlIGZ1dHVyZSBmb3IgZmluZS1ncmFpbmVkIGZlZWRiYWNrLiBJ
biB0aGF0IGNhc2UsIEw0UyB3b3VsZCBuZWVkIHRoYXQgbmV3IHNoaW55IHRoaW5nIGluc3RlYWQs
IGFuZCB3b3VsZCBub3QgdGhlbiBuZWVkIEFjY0VDTi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kIEkgc3RpbGwgZmFpbCB0
byB1bmRlcnN0YW5kIHdoeSBldmVuIHRoZSBnZW5lcmFsIGlkZWEgb2YgUkFDSyBtYXR0ZXJzIHRv
IEFRTSBhbGdvcml0aG1zLCB0cmFmZmljIGNsYXNzaWZpZXJzLCBvciBwcmlvcml0eSBzY2hlZHVs
ZXJzIGZvciB0cmFmZmljIHdpdGggMS9wIGNvbmdlc3Rpb24NCiBjb250cm9sIGluIGEgcm91dGVy
LiBSQUNLIGhhcyBsb3RzIG9mIG1lcml0cywgYnV0IG1vc3Qgb2YgdGhlbSBhcmUgSU1ITyBlbnRp
cmVseSB1bnJlbGF0ZWQgdG8gdGhlIHZpc2lvbiBvZiBMNFMuIEnigJlkIHN1Z2dlc3QgdG8gZm9j
dXMgTDRTIG9uIHNvbHZpbmcgdGhlIGtleSBwcm9ibGVtcyBmb3IgdHJhZmZpYyB3aXRoIDEvcCBj
b25nZXN0aW9uIGNvbnRyb2wuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpJJ3ZlIHByb21pc2Vk
IERhdmlkIEJsYWNrIGEgZnVsbCBhbnN3ZXIgdG8gdGhpcy4gU28gcGxzIHNlZSB0aGF0Ljxicj4N
CkJ1dCBicmllZmx5LCBhbiBpbXBvcnRhbnQgYWR2YW5jZSBvZiBMNFMgaXMgc2NhbGFibGUgdGhy
b3VnaHB1dCAoaXQncyBpbiB0aGUgbmFtZSkuDQo8YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBwb2lu
dGxlc3MgdG8gcmVtb3ZlIG9uZSBzY2FsaW5nIGxpbWl0YXRpb24gaWYgaXQgd2FzIHJlcGxhY2Vk
IGJ5IHRoZSAzIER1cEFDSyBhcyBhIHRocm91Z2hwdXQgbGltaXRhdGlvbiAoQW1kYWhsJ3MgbGF3
KS4gSW4gYW4gaWRlYWwgd29ybGQsIHRoZSB0d28gd291bGQgYmUgZG9uZSBzZXBhcmF0ZWx5LiBC
dXQgTDRTIGNyZWF0ZXMgYSBjbGVhbi1zbGF0ZSBvcHBvcnR1bml0eSB3aGVyZSB0aGVyZSdzIGEg
bmV3IHF1ZXVlIGFuZA0KIG5ldyBDQ3MsIGFuZCB0aGVyZSBpcyBubyBkb3duc2lkZSB0byBwbGFj
aW5nIHRoZSB0aW1lLXVuaXRzIHJlcXVpcmVtZW50IG9uIHRoZXNlIHNlbmRlcnMgdGhhdCBoYXZl
IHRvIGJlIHVwZGF0ZWQgYW55d2F5LiBUaGVuIGZ1dHVyZSBleHB0cyB0aGF0IG1pZ2h0IHJlbHkg
b24gYWxsIGhvc3RzIHVzaW5nIHRpbWUtdW5pdHMgd2lsbCBub3QgYmUgcHJlY2x1ZGVkLjxicj4N
Cjxicj4NClRoaXMgaXMgYWxsIGluIHRoZSBsYXRlc3QgdGV4dCBpbiB0aGUgYXBwZW5kaXguPGJy
Pg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWwgKHdpdGggbm8gaGF0KTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lDQo8YSBocmVmPSJtYWlsdG86aW5AYm9i
YnJpc2NvZS5uZXQiPiZsdDtpbkBib2JicmlzY29lLm5ldCZndDs8L2E+IDxicj4NCjxiPlNlbnQ6
PC9iPiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDE5IDEwOjM5IEFNPGJyPg0KPGI+VG86PC9iPiBT
Y2hhcmYsIE1pY2hhZWwgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdl
bi5kZSI+Jmx0O01pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSZndDs8L2E+Ow0KPGEgaHJl
Zj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZEBpZXRmLm9yZyI+ZHJhZnQtaWV0
Zi10c3Z3Zy1lY24tbDRzLWlkQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i
bWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86
dHN2d2dAaWV0Zi5vcmciPg0KdHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbdHN2d2ddIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+TWljaGFlbCw8YnI+DQo8YnI+DQpPbiBhIHNpbWlsYXIgcXVlc3Rpb24gb2YgZGVwZW5kZW5j
eSBiZXR3ZWVuIGV4cGVyaW1lbnRzLCBJIHRoaW5rIHlvdSBhbHNvIGV4cHJlc3NlZCBjb25jZXJu
IHRoYXQgZWNuLWw0cy1pZCBkZXBlbmRzIG9uIHRoZSBSQUNLIGV4cGVyaW1lbnQuIEhvd2V2ZXIs
IGVjbi1sNHMtaWQgb25seSByZWZlcnMgdG8gUkFDSyBpbmZvcm1hdGl2ZWx5LCBiZWNhdXNlIGl0
IG9ubHkgdXNlcyB0aGUgZ2VuZXJhbCBpZGVhIGJlaGluZCBSQUNLLiBKdXN0IGFzIHF1aWMtcmVj
b3ZlcnkNCiAoc3RkcyB0cmFjaykgdXNlcyB0aGUgZ2VuZXJhbCBpZGVhIGJlaGluZCBSQUNLIChl
eHB0IHRyYWNrKSBieSByZWZlcnJpbmcgdG8gaXQgaW5mb3JtYXRpdmVseS48YnI+DQo8YnI+DQo8
YnI+DQo8YnI+DQpCb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiAwNC8xMS8yMDE5IDE1OjI2LCBCb2IgQnJpc2NvZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVsLDxicj4NCjxicj4NClRoYW5r
IHlvdSBmb3IgcG9pbnRpbmcgdGhpcyBvdXQsIG1hbnkgbW9udGhzIGFnbyBub3cuIDxicj4NCjxi
cj4NClRoZXJlIGlzIG5vIGZvcm1hbCBkZXBlbmRlbmN5IG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNu
LWw0cy1pZCBvbiBBY2NFQ04sIGFzIGV4cGxhaW5lZCBiZWxvdy48YnI+DQo8YnI+DQpGb3IgYW55
IHRyYW5zcG9ydCBwcm90b2NvbCB0byBjb21wbHkgd2l0aCBlY24tbDRzLWlkLCBpdCBuZWVkcyBz
dWZmaWNpZW50bHkgYWNjdXJhdGUgZmVlZGJhY2sgb2YgdGhlIGV4dGVudCBvZiBDRSBtYXJraW5n
IG9uIHRoZSBmb3J3YXJkIHBhdGguIFlvdSBwb2ludGluZyB0aGlzIG91dCBoYXMgbWFkZSBtZSBy
ZWFsaXplIHRoYXQgdGhlcmUgaXMgYSAnbmVlZHMnIHRoYXQgc2hvdWxkIGJlIGEgJ01VU1QnIGlu
IHRoZSBzcGVjOjxicj4NCjxicj4NCjQuMi4mbmJzcDsgUHJlcmVxdWlzaXRlIFRyYW5zcG9ydCBG
ZWVkYmFjazxicj4NCjxicj4NCkNVUlJFTlQ6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZu
YnNwOyBJbiBnZW5lcmFsLCBhIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbCwgbmVlZHMgZmVl
ZGJhY2sgb2YgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGV4dGVudCBv
ZiBDRSBtYXJraW5nIG9uIHRoZSBmb3J3YXJkIHBhdGguPG86cD48L286cD48L3ByZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlBST1BPU0VEOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJz
cDsgSW4gZ2VuZXJhbCw8c3BhbiBzdHlsZT0iY29sb3I6IzAwOTkwMCI+IGZvciBhIHRyYW5zcG9y
dCBwcm90b2NvbCB0byBwcm92aWRlPC9zcGFuPiBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2ws
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIHN0eWxlPSJj
b2xvcjojMDA5OTAwIj5pdCBNVVNUIHByb3ZpZGU8L3NwYW4+IGZlZWRiYWNrIG9mIHRoZTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBleHRlbnQgb2YgQ0UgbWFya2luZyBvbiB0
aGUgZm9yd2FyZCBwYXRoLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQpIb3dldmVyLCBlY24tbDRzLWlkIG9ubHkgc3BlY2lmaWVzIHRoZSByZXF1aXJlbWVudHMg
dGhhdCBhbnkgTDRTIHRyYW5zcG9ydCBwcm90b2NvbCB3b3VsZCBoYXZlIHRvIHNhdGlzZnkuIEl0
IGRvZXMgbm90IGRlZmluZSBhIHRyYW5zcG9ydCBwcm90b2NvbCBpdHNlbGYuIFNvIEFjY0VDTiBp
cyBub3QgYSBub3JtYXRpdmUgcmVmLiBTbyBJIGFtIGFsc28gYWx0ZXJpbmcgdGhlIHRleHQgYSBs
aXR0bGUgZnVydGhlciBkb3duLCB3aGVyZSBpdCByZWZlcnMNCiB0byBBY2NFQ04sIGFzIGZvbGxv
d3M6PGJyPg0KPGJyPg0KQ1VSUkVOVDo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7IFRDUDom
bmJzcDsgU3VwcG9ydCBmb3IgYWNjdXJhdGUgRUNOIGZlZWRiYWNrIChBY2NFQ048bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDcj
cmVmLUktRC5pZXRmLXRjcG0tYWNjdXJhdGUtZWNuIiB0aXRsZT0iJnF1b3Q7TW9yZSBBY2N1cmF0
ZSBFQ04gRmVlZGJhY2sgaW4gVENQJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbjwv
YT5dKSBieSBib3RoIGVuZHMgaXMgYSBwcmVyZXF1aXNpdGUgZm9yPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNjYWxhYmxlIGNvbmdlc3Rpb24g
Y29udHJvbC48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFJPUE9TRUQ6
PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyBUQ1A6Jm5ic3A7IFN1cHBvcnQgZm9yIGFjY3Vy
YXRlIEVDTiBmZWVkYmFjayAoPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDk5MDAiPnN1Y2ggYXMgPC9z
cGFuPkFjY0VDTjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
dHN2d2ctZWNuLWw0cy1pZC0wNyNyZWYtSS1ELmlldGYtdGNwbS1hY2N1cmF0ZS1lY24iIHRpdGxl
PSImcXVvdDtNb3JlIEFjY3VyYXRlIEVDTiBGZWVkYmFjayBpbiBUQ1AmcXVvdDsiPkktRC5pZXRm
LXRjcG0tYWNjdXJhdGUtZWNuPC9hPl0pIGJ5IGJvdGggZW5kcyBpcyBhIHByZXJlcXVpc2l0ZSBm
b3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
c2NhbGFibGUgY29uZ2VzdGlvbiBjb250cm9sLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5rcyBhZ2FpbiBmb3Ig
cG9pbnRpbmcgdGhpcyBvdXQuPG86cD48L286cD48L3A+DQo8aDM+RGVwZW5kZW5jaWVzIGJldHdl
ZW4gRXhwZXJpbWVudHM8bzpwPjwvbzpwPjwvaDM+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClRoZSBjYXNlIG9mIFRDUCBQcmFndWUgcHJv
dmlkZXMgYSBjb3VudGVyLWFyZ3VtZW50Ojxicj4NCjxicj4NClRDUCBQcmFndWUgY291bGQgYmUg
c3BlY2lmaWVkIGluIG9uZSBtb25vbGl0aGljIGV4cGVyaW1lbnRhbCBzcGVjLiA8YnI+DQpPciBp
dCBjb3VsZCBiZSBicm9rZW4gZG93biBpbnRvIGV4cGVyaW1lbnRhbCBjb21wb25lbnRzLCBhbmQg
YSB0b3AgbGV2ZWwgZXhwZXJpbWVudGFsIHNwZWMgdGhhdCBwdWxscyB0aGVtIGFsbCB0b2dldGhl
ci48YnI+DQo8YnI+DQpUaGUgbGF0dGVyIG9wdGlvbiB3b3VsZCBjcmVhdGUgbXVsdGlwbGUgZGVw
ZW5kZW5jaWVzIG9mIG9uZSBleHBlcmltZW50IG9uIG90aGVycy4gQnV0IElNSE8gc3VjaCBtb2R1
bGFyaXR5IGlzIHByZWZlcmFibGUgdG8gYSBtb25vbGl0aGljIHNwZWMuIEVzcGVjaWFsbHkgaWYg
c29tZSBvZiB0aGUgY29tcG9uZW50cyBtaWdodCBoYXZlIG90aGVyIHVzZXMgb3V0c2lkZSBvZiBU
Q1AgUHJhZ3VlICh3aGljaCBpcyBleGFjdGx5IHRoZSBjYXNlIHdpdGggVENQDQogUHJhZ3VlLCBl
LmcuIEFjY0VDTiwgRUNOJiM0MzsmIzQzOywgUkFDSyBhcmUgYWxsIHBvdGVudGlhbGx5IHBhcnRz
IG9mIHRoZSBiYXNlIFRDUCBzdGFjaywgYW5kIHBhY2VkLWNoaXJwaW5nIGlzIHBvdGVudGlhbGx5
IHVzYWJsZSBieSBhbnkgb3RoZXIgY29uZ2VzdGlvbiBjb250cm9sIC0gdGhlc2UgYXJlIGFsbCBl
eHBlcmltZW50YWwgY29tcG9uZW50IHBhcnRzKS4NCjxicj4NCjxicj4NCkFzIGFub3RoZXIgZXhh
bXBsZSwgQkJSIHdhcyB3cml0dGVuIHVwIGFzIGFuIGV4cGVyaW1lbnRhbCBkcmFmdCwgYW5kIHRo
ZSBMaW51eCBpbXBsZW1lbnRhdGlvbiB1c2VzIFJBQ0sgKGFsdGhvdWdoIG5vdCBtZW50aW9uZWQg
aW4gdGhlIGRyYWZ0KSB3aGljaCBpcyBlbmFibGVkIGJ5IGRlZmF1bHQgaW4gTGludXguDQo8YnI+
DQo8YnI+DQpTdWNoIG1vZHVsYXJpdHkgaXMgZ29vZC48YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+
DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiAyNC8wMy8yMDE5IDE5OjE1LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHByZT5JIGhhdmUganVzdCBwYXJzZWQgdGhyb3VnaCBkcmFmdC1pZXRm
LXRzdndnLWVjbi1sNHMtaWQtMDYgYW5kIEkgcnVuIGludG8gdGhlIGZvbGxvd2luZyBzZW50ZW5j
ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5U
Q1A6Jm5ic3A7IFN1cHBvcnQgZm9yIGFjY3VyYXRlIEVDTiBmZWVkYmFjayAoQWNjRUNOPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0
Zi10Y3BtLWFjY3VyYXRlLWVjbl0pIGJ5IGJvdGggZW5kcyBpcyBhIHByZXJlcXVpc2l0ZSBmb3I8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Nh
bGFibGUgY29uZ2VzdGlvbiBjb250cm9sLiZuYnNwOyBUaGVyZWZvcmUsIHRoZSBwcmVzZW5jZSBv
ZiBFQ1QoMSkgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgdGhlIElQIGhlYWRlcnMgZXZlbiBpbiBvbmUgZGlyZWN0aW9uIG9mIGEgVENQIGNv
bm5lY3Rpb24gd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBpbXBseSB0aGF0IGJvdGggZW5kcyBzdXBwb3J0IEFjY0VDTi4mbmJzcDsgSG93
ZXZlciwgdGhlIGNvbnZlcnNlIGRvZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgbm90IGFwcGx5LiZuYnNwOyBTbyBldmVuIGlmIGJvdGggZW5k
cyBzdXBwb3J0IEFjY0VDTiwgZWl0aGVyIG9mIHRoZSB0d288bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW5kcyBjYW4gY2hvb3NlIG5vdCB0byB1
c2UgYSBzY2FsYWJsZSBjb25nZXN0aW9uIGNvbnRyb2wsIHdoYXRldmVyPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBvdGhlciBlbmQncyBj
aG9pY2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmU+Q2FuIHRoZSBhdXRob3JzIHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIgdGhlcmUgaXMgYSBub3Jt
YXRpdmUgZGVwZW5kZW5jeSBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQgb24gZHJhZnQt
aWV0Zi10Y3BtLWFjY3VyYXRlLWVjbj88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5JZiBzbywgSSB0aGluayB0aGUgZm9ybWFsIGRlcGVuZGVuY3kg
b24gaW1wbGVtZW50aW5nIEFjY0VDTiBoYXMgdG8gYmUgc3BlbHQgb3V0IGV4cGxpY2l0bHkuIElu
IHRoYXQgY2FzZSwgSSB3b3VsZCBiZSBsb29raW5nIGZvciBhIHN0YXRlbWVudCBvZiB0aGUgc29y
dCAmcXVvdDtNVVNUL1NIT1VMRC9NQVkgaW1wbGVtZW50IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0
ZS1lY24mcXVvdDsgc29tZXdoZXJlLiBJZiBzdWNoIGEgcmVxdWlyZW1lbnQgZG9lcyBub3QgZXhp
c3QsIEkgdGhpbmsgdGhlIGFib3ZlIHBhcmFncmFwaCBpcyBjb25mdXNpbmcuPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgaW5kaXZpZHVhbCBj
b250cmlidXRvciwgSSB3YW50IHRvIG5vdGUgdGhhdCBJIGRpc2FncmVlIHdpdGggbWFuZGF0b3J5
IGRlcGVuZGVuY2llcyBiZXR3ZWVuIGV4cGVyaW1lbnRzLiBJIGhhdmUgbWVudGlvbmVkIGluIHRo
ZSBwYXN0IHRoYXQgSSBiZWxpZXZlIHRoYXQgZGlmZmVyZW50IGV4cGVyaW1lbnRzIG11c3QgYmUg
c3BlY2lmaWVkIGluZGVwZW5kZW50bHkgb2YgZWFjaCBvdGhlciBhbmQgc2hvdWxkIGJlIGltcGxl
bWVudGFibGUgaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyLCBzcGVjaWZpY2FsbHkgYWxzbyB0
byBiZSBhYmxlIHRvIGZhaWwgaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyLiBJdCBpcyBwb3Nz
aWJsZSB0aGF0IEkgYW0gaW4gdGhlIHJvdWdoIHBhcnQgb2YgdGhlIGNvbnNlbnN1cy4gQnV0IEkg
aGF2ZW4ndCBjaGFuZ2VkIG15IG1pbmQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxwcmU+TWljaGFlbCAoYXMgaW5kaXZpZHVhbCk8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm
PSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxw
cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh
IGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+
PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N
CjxwcmU+dGNwbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJt
YWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0i
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbTwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPi0tIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2Nv
ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJp
c2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_MN2PR19MB4045AB7A48C0039B5E3856AC834F0MN2PR19MB4045namp_--


From nobody Wed Nov 20 08:44:25 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 267DB120913 for ; Wed, 20 Nov 2019 08:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 T9jjhWzB-9wn for ; Wed, 20 Nov 2019 08:44:22 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62865120907 for ; Wed, 20 Nov 2019 08:44:22 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id ECA9D2C4039; Wed, 20 Nov 2019 08:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EVauLf-wJVKp; Wed, 20 Nov 2019 08:44:21 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 629C52C4032; Wed, 20 Nov 2019 08:44:21 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F1D931E6D6DF; Wed, 20 Nov 2019 11:44:20 -0500 (EST)
From: "Mark Allman" 
To: "Scharf, Michael" 
Cc: "tcpm IETF list" 
Date: Wed, 20 Nov 2019 11:44:20 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] Thoughts on EXP vs. PS in TCPM
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, 20 Nov 2019 16:44:24 -0000

Hi Michael!

Good questions.  Thanks for starting the thread.

I agree that TCPM is basically too conservative.  We have been too
conservative for a long time.  I probably contributed my fair share
to that.  But, I'd put a finer point on it: Have we ever issued
something at EXP (or PS for that matter!) that had to be pulled back
because it was too aggressive?  I am not conjuring anything at the
moment.

TCPM has long used EXP as a crutch.  We don't have the guts to label
something a PS, yet we still want to publish it.  And, no amount of
non-answers to "what's the experiment?" garners rough consensus for
issuing as PS.

And, my take is that the world doesn't much buy there to be a
distinction.  I.e., EXP doesn't dissuade general use of something.
And, I bet at least part of this is that we're just too conservative
with both kinds of RFCs.  If we occasionally did publish an EXP that
caused TCP to fall on its face then maybe people would be a bit more
careful.

That said, it's sort of hard to come up with good rules for
delineating.  For instance, consider this ...

> In order to start a WGLC in TCPM for EXP status, there SHOULD be
> one implementation in the main source code tree of an important
> TCP/IP stack; a default to "off" is perfectly
> acceptable.

Well, there are a number of implementations of IW=15 or IW=100, it's
just that these are off by default.  I.e., something like the
initial window is just a constant somewhere so what does it mean
that we have 'one implementation' of something like this?

I think in the end TCPM standardizes a wide variety of stuff and a
one-size rule may not apply.  E.g.,

  - We standardize actual protocol mechanisms (a la TFO) and those
    need some sort of interoperability kinds of criteria.

  - We standardize algorithms and those need some sort of behavioral
    and safety criteria (a la RACK).

  - We standardize constants and those need safety criteria (a la
    IW or RTO).

Further, my observation is that for the latter two in particular the
WG cares about 'one impl' vs. 'two impls' much less than we care
about the overall evidence that something works---or, where it falls
down.

I wish I had some idea about how to synthesize this better than
'perhaps we should relax and be less conservative', but I don't.
I'll think on it.

allman


--
https://www.icir.org/mallman/
@mallman_icsi


From nobody Wed Nov 20 09:08:26 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 33BA812088F for ; Wed, 20 Nov 2019 09:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_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=bobbriscoe.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 SmMBWJctbudL for ; Wed, 20 Nov 2019 09:08:21 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C5FB3120119 for ; Wed, 20 Nov 2019 09:08:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:To:Subject:From:Sender:Reply-To:Cc: 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=VmM5Z0xKPHTman9OYN9ijOlX9UF7n0GQBbFzQdENZw8=; b=ry1n8BRbNQBIoZacB9fHbhhTW BtxfFDNyGWwvrU17zSOXmIaFl4vVtPMiiLzYRf08Z2dpyv+NmLD6beNDfy1lBUEqsjEZCFor+gpT8 hG7sw/Pc++he1Bg35ZoCJY2TQFo+KF0FXIGeQwtGjFqdm5yRnurd4Na9Cynq9sPDdPpiOmrMTAQSh C48EBTfNfWc5dM8x+Dy3mD08e/RIiu7aj2A9RW8h5KLLgC61O2RpKuuLCT170k8tfvNa8iSwLjbje Cp+fNekGRr1gVfdNg89y75BxP4iPfCU+LCEX8v+FAvU1REkdWIgRwcaEJeAnu+rSonF6vP0VMcQ3K +M0xxYwXg==;
Received: from [182.55.86.154] (port=33716 helo=[192.168.0.142]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iXTSm-0000Zq-4f for tcpm@ietf.org; Wed, 20 Nov 2019 17:08:20 +0000
From: Bob Briscoe 
To: tcpm IETF list 
References: <22773cc0-f28a-0cd2-8265-a559f427ff8d@bobbriscoe.net>
X-Remindit: Thu Nov 21 2019 08:00:00 GMT+0800 (+08)
Message-ID: 
Date: Thu, 21 Nov 2019 01:08:18 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <22773cc0-f28a-0cd2-8265-a559f427ff8d@bobbriscoe.net>
Content-Type: multipart/alternative; boundary="------------AD37AE0FDE47A935E47E7586"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] Fwd: TCP Prague Update: L4S-related Side Meeting at IETF-106
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, 20 Nov 2019 17:08:24 -0000

This is a multi-part message in MIME format.
--------------AD37AE0FDE47A935E47E7586
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

tcpm,

I'm re-sending the cross-posts of the email below individually, 'cos 
some people missed the email below.
Remote attendance details have been added (via zoom).
And the agenda has changed around a bit.


Bob

-------- Forwarded Message --------
Subject: 	TCP Prague Update: L4S-related Side Meeting at IETF-106
Date: 	Mon, 18 Nov 2019 10:51:42 +0800
From: 	Bob Briscoe 
To: 	tsvwg IETF list , iccrg IRTF list , 
tcpm IETF list 



Folks,

The significant amount of TCP Prague update material was too great for 
the iccrg agenda.
So, with the help of the iccrg and tsvwg chairs (thank you), we've 
arranged a side meeting to cover all this.

==Where/when?==
Date: Thu 21 Nov 2019
Time: 08:30 - 09:30
Room: Canning

==Agenda==
http://bobbriscoe.net/projects/latency/TCP_Prague_side-meetingAgendaIETF-106.html

==Meeting Materials==
Links to meeting materials will be added to the above agenda soon.
They will also be added to the tsvwg meeting materials.

==Remote Attendance==
Meetecho is not available for side-meetings, so we're arranging an 
alternative, prob Zoom (link will appear on agenda)

Regards


Bob


-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/


--------------AD37AE0FDE47A935E47E7586
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    tcpm,

    

    I'm re-sending the cross-posts of the email below individually, 'cos
    some people missed the email below.

    Remote attendance details have been added (via zoom).

    And the agenda has changed around a bit.

    

    

    Bob

    


      -------- Forwarded Message --------
      

        
          

            Subject:
            
            TCP Prague Update: L4S-related Side Meeting at IETF-106
          

          

            Date: 
            Mon, 18 Nov 2019 10:51:42 +0800
          

          

            From: 
            Bob Briscoe <research@bobbriscoe.net>
          

          

            To: 
            tsvwg IETF list <tsvwg@ietf.org>,
              iccrg IRTF list <iccrg@irtf.org>,
              tcpm IETF list <tcpm@ietf.org>
          

        
      

      

      

      Folks,

      

      The significant amount of TCP Prague update material was too great
      for the iccrg agenda.

      So, with the help of the iccrg and tsvwg chairs (thank you), we've
      arranged a side meeting to cover all this.

      

      ==Where/when?==

      Date: Thu 21 Nov 2019

      Time: 08:30 - 09:30

      Room: Canning

      

      ==Agenda==

      http://bobbriscoe.net/projects/latency/TCP_Prague_side-meetingAgendaIETF-106.html

      

      ==Meeting Materials==

      Links to meeting materials will be added to the above agenda soon.

      They will also be added to the tsvwg meeting materials.

      

      ==Remote Attendance==

      Meetecho is not available for side-meetings, so we're arranging an
      alternative, prob Zoom (link will appear on agenda)

      

      Regards

      

      

      Bob

      

      

      
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



    

  


--------------AD37AE0FDE47A935E47E7586--


From nobody Wed Nov 20 09:49:52 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 085D1120108 for ; Wed, 20 Nov 2019 09:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8lw0DqhJXrzo for ; Wed, 20 Nov 2019 09:49:49 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 EAD7112007A for ; Wed, 20 Nov 2019 09:49:48 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id m6so221454vsn.13 for ; Wed, 20 Nov 2019 09:49:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e6CkTBpE1kYxK+DXxI9+ZCP1XQMkHJcHuiYhJJnz/fU=; b=A8VRDyUIsvWIPmx25u4NH7mPo7PGMRJB81NU/n70ahTlSNBPi7LNGHtyFE6kOZJGJi 0rP0eAYk5+zSLiOtA0g8AMC7RdhudG8gRx6/DxBQatLXArEQ0zn8yfIuYgtAzo+318pY wnSdg+pYfTTadl185u6YsaGXBY2NGSZwtRdrqsDGJYa0o54IURB77S5p4a3RswgHaAvW tyCUbZW0jYiNX90hE+6MfgkiwuxnjNo1dYIHjtPQBZ09AQd5dAxZZ+G4hFPUUQlL52ve FYabB4hxxPekRgKZbj3rR79vf4PoSz8RTRSLeCKnCBVzj6qA/Hv/wBsfWDWlfzRSL5mZ w1VQ==
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; bh=e6CkTBpE1kYxK+DXxI9+ZCP1XQMkHJcHuiYhJJnz/fU=; b=SyGe6WIk6RMl0+xxfbhhXQiOUsQPBdQgFN5DPVeqTNqwf+1w2yWHyeB7KEgq8CFIJ6 aFEGh2R12XgzxTzLTr5ZYXdW98Kgq+ICUo/ppVhwsaVGg3BjK7XHv3IMWiuk7CHwQ5bV dlCnqqYL9ior/AWTKQRLRoahPTXs/yLrhOWtBCNNvEGS9KEa1gNmToBiwfSPIfdGHVfq kbXuJ52BlFTiae4Jk/g1pJoegwAmgJy3tG3deNDuFnKEo6DcP7a95aRNK44Bl7/iNSgt n8OpyxadfhTY9UDWN1Sx0scyYRLbg0SbFpZbrbtDEwORr3GmR1QOYSL3A3SfhzIFJ9ji UXhQ==
X-Gm-Message-State: APjAAAWmjG1g3SJbvY1w0dxWv/JH+pqFtZrA74x+mcOsXXRftsr+B9k8 oPbgdgz4dO/2naFWGN57GMuOkXAJamtW4oqBibRLMA==
X-Google-Smtp-Source: APXvYqzavU3ebTcLJ8EtpkaAyWCFMZ1xoA/lOa2LcYOb38+QcxKh6kDGDbV6t6+XfwJAMJWEGKym5e/0xReiLpNppTs=
X-Received: by 2002:a67:6d03:: with SMTP id i3mr2610375vsc.56.1574272187233; Wed, 20 Nov 2019 09:49:47 -0800 (PST)
MIME-Version: 1.0
References: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de> 
In-Reply-To: 
From: Yuchung Cheng 
Date: Wed, 20 Nov 2019 09:49:10 -0800
Message-ID: 
To: Mark Allman 
Cc: "Scharf, Michael" , tcpm IETF list 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] Thoughts on EXP vs. PS in TCPM
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, 20 Nov 2019 17:49:51 -0000

On Wed, Nov 20, 2019 at 8:44 AM Mark Allman  wrote:
>
>
> Hi Michael!
>
> Good questions.  Thanks for starting the thread.
>
> I agree that TCPM is basically too conservative.  We have been too
> conservative for a long time.  I probably contributed my fair share
> to that.  But, I'd put a finer point on it: Have we ever issued
> something at EXP (or PS for that matter!) that had to be pulled back
> because it was too aggressive?  I am not conjuring anything at the
> moment.
>
> TCPM has long used EXP as a crutch.  We don't have the guts to label
> something a PS, yet we still want to publish it.  And, no amount of
> non-answers to "what's the experiment?" garners rough consensus for
> issuing as PS.
>
> And, my take is that the world doesn't much buy there to be a
> distinction.  I.e., EXP doesn't dissuade general use of something.
> And, I bet at least part of this is that we're just too conservative
> with both kinds of RFCs.  If we occasionally did publish an EXP that
> caused TCP to fall on its face then maybe people would be a bit more
> careful.
>
> That said, it's sort of hard to come up with good rules for
> delineating.  For instance, consider this ...
>
> > In order to start a WGLC in TCPM for EXP status, there SHOULD be
> > one implementation in the main source code tree of an important
> > TCP/IP stack; a default to "off" is perfectly
> > acceptable.
>
> Well, there are a number of implementations of IW=15 or IW=100, it's
> just that these are off by default.  I.e., something like the
> initial window is just a constant somewhere so what does it mean
> that we have 'one implementation' of something like this?

I like Mark's remarks on # of implementations. This might be too easy
to game: I and my friend each implemented X in our toy stacks. It
really should be WG's consensus if the proposed change has been
well-tested (or else WG is very confident it works).

>
>
> I think in the end TCPM standardizes a wide variety of stuff and a
> one-size rule may not apply.  E.g.,
>
>   - We standardize actual protocol mechanisms (a la TFO) and those
>     need some sort of interoperability kinds of criteria.
>
>   - We standardize algorithms and those need some sort of behavioral
>     and safety criteria (a la RACK).
>
>   - We standardize constants and those need safety criteria (a la
>     IW or RTO).
>
> Further, my observation is that for the latter two in particular the
> WG cares about 'one impl' vs. 'two impls' much less than we care
> about the overall evidence that something works---or, where it falls
> down.
>
> I wish I had some idea about how to synthesize this better than
> 'perhaps we should relax and be less conservative', but I don't.
> I'll think on it.
>
> allman
>
>
> --
> https://www.icir.org/mallman/
> @mallman_icsi
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Wed Nov 20 12:57:38 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 51F4F12012D for ; Wed, 20 Nov 2019 12:57:36 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 waDn2BFxUKhx for ; Wed, 20 Nov 2019 12:57:35 -0800 (PST)
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 7E9E1120137 for ; Wed, 20 Nov 2019 12:57:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574283437; bh=pTmvQK/I8dTcPqBoagWdzjbpI5efUifKUnYFc+J+4J4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=F8vwa5wCvfYI2VIv/Pe9f7sCoggX9FzFZe+K0cgaBlVWZluvDg2bAlnrlOylWDB/c pHN43Yi465zcXnaWhJ3LF366fjbqyq6O2JkAYl9A/7Rw1P5MKqAUGJ0hQT/q1+qiob Uey8KDcFppalozHKfaK6A2nY833uUCGNhWNBFgR4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.20.8.66] ([203.127.152.4]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MRTNF-1iAFYn1muD-00NOFF; Wed, 20 Nov 2019 21:57:16 +0100
To: Yuchung Cheng , Mark Allman 
Cc: tcpm IETF list 
References: <6EC6417807D9754DA64F3087E2E2E03E2D51A41C@rznt8114.rznt.rzdir.fht-esslingen.de>  
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Thu, 21 Nov 2019 04:57:15 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:l7QVHm7DnGCD38fztbbu1kPrEBJOVzbdpsn2REElxahMx6vCvoQ fHSv9/eexYqGahL6y3WG2X/DkVU01hpxD4GovjYu1/7MQ5VuDqKNRNyp6MvgLaBPH8EzMtv C9ZiFm5uZA9B0EsjPeU9GXVqs1lKKhzdtLo5FnzMAmJXcEZ9R800wF0ajx/EpKnLMxY6Byk OIDgm5n7MJzt3u4fm8d/A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vtwFCl63iLs=:j+B8/Ho4tyH1tHBdzlVSm7 38FnbUsxn+Ex0JMmtb7baUwzVMoFs8hAonUSPFgpqAIdLE4RIsk0c6bGqB1Im9hAaon9Xi/wv rnDHfWW5wRg5hDactJNb9X+cSQ8hlWB3GSCzhR/iXlSrYkXFCVUV4EF1Xom6tXUBBVrdQqLWE nCjyFoTJ3S+QlpDPlEV+UsF+tgkWXICeFLyV+2waz1F+/K493U15e1oAk7AJFJ8cmF8pEOPig cl9o73Ta395WDUMlzNKeWVQEUstlvY2BCtbEhSsirwZ3dt8QVOIKhDubBUdxZS4wQ4BjLbyOp Hija46N0Oxh0wigQIVgmTgnlt0TFsr/piftCJn3criynSQOaatnAUBCQLIYDQzI6KzrU3S6Rw BG/MuCq69ifMvfqOXTCGqTx1I6e78IzlwI7MmDt8N1WRUIFbYRzOyh7RG9jkrfVoOXx/OvEt8 ZbP+qNgfzUvA8Zr7K2qsOtMjM9ds+4KcWMMCinmAeGnws47gIviw35WwOoF5J/fobUO96sLY4 Drzhy2uYgK7mr0gG/OJjFi1jOd8rqXIulbDsl7nAEw4P6uNVa1cTacv7FIICMuRNf+aouRPPR CyJnAt4w7znpaH8GVODqqN8xHFu2PT43eSvF08EPcVtAy4kh9+WNaKQyp1+hCvmQMY+HekRMk bcST00uYmmWQC4sx5eX2eJvXxJsxuJcT3YDIvf5ELnXeF3VO10mgw+Q2Mmjr2NPW4j5jEItB2 iUob5K3XFy5x9ldcSqzItsAJlDumjSS2Nb40FQ0GqyULBdNOVd1Iv0NqOt1ed6mUKBhH+8RdQ 8UCYx0GNAbSh47/TKxwa3kxLCcUFciow57mAOfq0FYNpx4cNJf4TSF3qPWlMJuwLduCc8WHXB cG1VUHkzkxktruf16WmnJ6bl/75mJFjlWcpoy43w5nNeLFxs48RJ9u0Ep6W3DoZNyEB2jEH4Z kznoJT8OxGHXGzjt4COCEWEtDFmo/lxOc7n5pSzHfNRBJgaeOZQsh1AigAbhvOVxh01dnjP7B Yq4mb/130UYSfpqyfWdVQ5/8F6zefjIo+AYMmqTLV6+XUrnKOqQeevkJRTsaz17ug6gLGxwG9 Gf0U5Q1og0iFtPcmsy8PKtLpq9bwpKbmQoS5XSuNjdNgzXyz8R4f2FC/L3DZnnI4oz9R/pbH7 1lm6TZ7VwUIF1cB7N4jeLA13qfwPlokTnQX2F0IabxU0fRFisOUaRfGPgOnvzNrKY6BTN3Ss0 AHcqn0CCVzur9C4/o5JNj/pTde3cQBoUrOLVI9g==
Archived-At: 
Subject: Re: [tcpm] Thoughts on EXP vs. PS in TCPM
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, 20 Nov 2019 20:57:36 -0000

Hi Mark,

> On Wed, Nov 20, 2019 at 8:44 AM Mark Allman  wrote:
>> And, my take is that the world doesn't much buy there to be a
>> distinction.  I.e., EXP doesn't dissuade general use of something.
>> And, I bet at least part of this is that we're just too conservative
>> with both kinds of RFCs.  If we occasionally did publish an EXP that
>> caused TCP to fall on its face then maybe people would be a bit more
>> careful.

Well, in my world there certainly is a distinction between an RFC in EXP
vs. PS vs STD status... I agree, for those of us who deal with drafts
and RFCs in the transport area, what you state here is correct.

However, I've made the observation, that less well initiated people, in
particular decision makers who can not make a call on the technical
merit, will often simply look at procedural things like the status of a
draft or RFC, when funding or not funding resources to implement and
test them.

This is where I would wish the TCPM would actually have a proper follow
up process, where long-time experimental drafts, which are found to be
safe and beneficial would get re-issued from time to time as PS (and
ultimately STD), and failed experiments get cleaned out. For the latter,
we recently had one such major revisit of the state of various RFC (eg.
rfc6247 and rfc8311 for rfc3540). But IIRC, we very rarely promote RFCs
up from experimental - one recent example with good expirience would be
DSACK RFC3708 here - also due to the many dependencies on it (with one
PS document depending on an EXP document :). RFC793bis is the one
currently in progress here.

IMHO, perhaps whenever the TS Area has two new chairs, that could be
made a more routine maintenance task...


From nobody Wed Nov 20 18:05:27 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 C53EE12012E; Wed, 20 Nov 2019 18:05:25 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 6WAhGDpDbaSs; Wed, 20 Nov 2019 18:05:24 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 A42A7120077; Wed, 20 Nov 2019 18:05:23 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id y5so1868850wmi.5; Wed, 20 Nov 2019 18:05:23 -0800 (PST)
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; bh=Bfo8xT2zTrzgEb6Wt6RuVk5T1JGq19TdPvVqfR6dILs=; b=AwfJBRnx4wfatUvRkNfCeJgNEhZcTn1hZ6txnjy+bwUzWBOR+4Zbd0iqOrvpzvdOvf Nymxkkx6nk4j7lLLncKD7SLRji5JGn/XWZike94FDYUPgI4ybItpEHFyXQUDi8K05yIm pBOp3OcfC6dEjpRjdI4udripXCAR4zkGYZJYKK+A0hkQtNcfGdikBHG4rNaxXK4kGpE9 aYCip5CBZNUM7fsGSJlMFmSAWHDVNVSxa6MBFQazmEUv2KQEHVCrmfieUWg3Slso3dbN S0JY+yaXX8yPZV1rJXmfZ6LswqAXWov03I45ksY8SyIB25sRAPf5yO3xirLnHIJwtkTu jHGw==
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; bh=Bfo8xT2zTrzgEb6Wt6RuVk5T1JGq19TdPvVqfR6dILs=; b=CInw61CLWBrOm4UjtMS+og85rpAKQQbZdS8N2gT9RHq5/JZWQtE2QVopp1DakoGKID yexgs5VAZCkxHrdWS8o/vLazc8ByiUroPID0knAmtMb+l1JBKpuhdYtR0KOeSO0mkTjO 4s5rrKHr7yEj1uGcta/gklX8lsRG5JlAJJA2bFMGdXfA7Lo8KbSMVoMvpiiiBp9pSrRy qXM4XazWUzVMjYKlzOrfPmMFoWmKvi9LNU1sfC30lH3AhEUwif0NrSHKUpMWd4/IFCSM l1BIokODXzRRqLkcNUqCUO0EQxbfyeXuqHIBRdLuGpwsvMfu4yZr+r5Ds1ZJoUCJklW8 TXRQ==
X-Gm-Message-State: APjAAAVKI+LDHOkA0r6f8GTK7EOp7h0e/f4uOEptlQudO17Aiz3AV07P fCVd5aE7HfY99IdHb/IOrpYkgEkyyUVxIuim6ydUcjyRWIw=
X-Google-Smtp-Source: APXvYqw1WwcWYo137zwK7q1pvKoA+7MNCq9ouQlD1dFgzwe3FWQpiBCrf/baVb8vOayQh97Is+5NlqjUmazzXaDJweA=
X-Received: by 2002:a1c:9dd3:: with SMTP id g202mr7036319wme.43.1574301922019;  Wed, 20 Nov 2019 18:05:22 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Yoshifumi Nishida 
Date: Wed, 20 Nov 2019 18:05:11 -0800
Message-ID: 
To: "tcpm@ietf.org Extensions" 
Cc: tcpm-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d4d0ad0597d1bae5"
Archived-At: 
Subject: Re: [tcpm] draft agenda for Singapore meeting
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, 21 Nov 2019 02:05:26 -0000

--000000000000d4d0ad0597d1bae5
Content-Type: text/plain; charset="UTF-8"

Hello presenters,

if you haven't sent your slide, please send it to chairs.
BTW, as we changed our agenda plan a bit, I am sorry that I had to adjust
presentation time a little bit. Please be aware of it.

The current agenda plan is listed below (and may have another update)
https://datatracker.ietf.org/meeting/106/materials/agenda-106-tcpm-04.txt

--
Yoshi


On Thu, Nov 14, 2019 at 2:00 PM Yoshifumi Nishida 
wrote:

> Hi,
> We are still working on building agenda, but here's the current status.
> Please let us know if you have any questions or requests.
>
> https://datatracker.ietf.org/meeting/106/materials/agenda-106-tcpm-02.txt
>
> For folks who will make presentations at the meeting,
>   Please submit your presentation material * by Thursday Morning (11/21) *
> We appreciate your cooperation.
>
> Thanks,
> --
> tcpm co-chairs
>

--000000000000d4d0ad0597d1bae5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello presenters,

if you hav=
en't sent your slide, please send it to chairs.
BTW, as we ch=
anged our agenda plan a bit, I am sorry that I had to adjust presentation t=
ime a little bit. Please be aware of it.

The c=
urrent agenda plan is listed below (and may have another update)

--
Yoshi


On Thu, Nov 14, 2019 at 2:00 PM Yoshifumi Nishida=
 <nsd.ietf@gmail=
.com> wrote:
Hi, 
We are still working on buildi=
ng agenda, but here's the current status.
Please let us know =
if you have any questions or requests.


For folks who will ma=
ke presentations at the meeting, 
=C2=A0 Please submit your p=
resentation material * by Thursday Morning (11/21) *
We appre=
ciate your cooperation.

Thanks,
--
tcpm co-chairs




--000000000000d4d0ad0597d1bae5--


From nobody Thu Nov 21 00:14: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 45EB6120985; Thu, 21 Nov 2019 00:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.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 kwfk2-UEruT7; Thu, 21 Nov 2019 00:14:47 -0800 (PST)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720103.outbound.protection.outlook.com [40.107.72.103]) (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 ED921120A76; Thu, 21 Nov 2019 00:14:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jtbp/xtsWwJaSvani2oOLQl5nFm8AMmvUzZ8iDtKZ9c4Saa4RvSjEUEg/70G1u412H8zeDOKt4MbsR7CYHSlGJSZf6W1Je8YGdaUP65aIefnNLhYeh/TBpnbaGBkMqntARSXuLnZ9Mw1HWmFlRaj8uU/LBOxIRl41sw0kuEFIIZjZnkrfR1iGzEIaSRXpHImoTfHkuZu2iG3sa5PFDEEEr1iW/QNqUk7N0GyioCiJsuI47TEElYvi+jQ1BsVyy7dykWXjVgY9maIebPHO2Vss2WXNJeJcyHnZ/yZvhI1rvi+8iGErFcdTZuLM58q+133aeLvbNZzsBf3hQOoahe6jw==
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=+yvPY7rHgFCK8zrxiMVCOhceeqZpZavom0WQGoxU/OI=; b=BQo++hK7y5k82JPFLfnF7dV9tfDE6yksv+alHp7fh4BYMacICQUjSQjSUm9Lj1lAWoHGUuytRZTkQKbaID43X1HGU6ua5u2Zqneya7A2yDy1j1xd23baN/3Pe73eNB9kGOCzia+a+Tt6S07u4q4HUPnUarJAvZkDdplThxWAZG+mmuF/Dpyvnn1S69NlVDwtQxJNRSTN2fPmKpJ9WsFe/0Fg7w+7AoPP1e3UPfLNNrbyfgG8EawqUymW3ZtxVVdDOfh3QgOfqFGGrQDYYmas+qiJllushMC9FVd0y3AZTT20LwfjvF1v8LiiZkrFGgC5mhb75IdmBJHYv4ko4Df0Bg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+yvPY7rHgFCK8zrxiMVCOhceeqZpZavom0WQGoxU/OI=; b=nYmLO6TH/n8TW5rJ6edmY5ujzpHEU5lA1FQo/qdEQZ1nvKRxlJyNEonq9cDyAHXqCJN7ZPh4rY83l8rnFaZKlPsKM4rj0RhHJTixFRpuRHNl9JbEYtd66aheVsijL/TnewNao5znqNH7J/ppJxxU6w9j7eUxTMmT328vjRdM9wQ=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4720.namprd06.prod.outlook.com (52.135.117.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.16; Thu, 21 Nov 2019 08:14:30 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::91c5:f29b:4501:6db5]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::91c5:f29b:4501:6db5%2]) with mapi id 15.20.2474.019; Thu, 21 Nov 2019 08:14:30 +0000
From: Greg White 
To: =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= , Bob Briscoe , tsvwg IETF list , iccrg IRTF list , tcpm IETF list 
Thread-Topic: [iccrg] [tsvwg] TCP Prague Update: L4S-related Side Meeting at IETF-106
Thread-Index: AQHVoEOyTEr4qE36NUSyHTeh/0rzpg==
Date: Thu, 21 Nov 2019 08:14:30 +0000
Message-ID: <3152F4FA-3419-4B47-BC2E-C2E752844456@cablelabs.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; 
x-originating-ip: [203.127.152.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1b057460-882e-4f4b-a344-08d76e5ad56c
x-ms-traffictypediagnostic: SN6PR06MB4720:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(346002)(136003)(376002)(366004)(199004)(189003)(13464003)(15650500001)(11346002)(2420400007)(316002)(6436002)(14444005)(5660300002)(6512007)(6486002)(6246003)(256004)(8936002)(76176011)(6306002)(110136005)(58126008)(86362001)(81166006)(66574012)(8676002)(81156014)(99286004)(229853002)(186003)(446003)(66556008)(76116006)(64756008)(478600001)(66476007)(66446008)(91956017)(66946007)(36756003)(26005)(102836004)(7110500001)(53546011)(6506007)(25786009)(71200400001)(71190400001)(305945005)(2616005)(33656002)(7736002)(3846002)(6116002)(14454004)(66066001)(966005)(2906002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4720; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: C1zvTeTAffTlCoxVN//WHMZpqUHD8lWo+2KKqf3+M1Alr1WyolIv+72f7wptCQFIoC/joltZOjzlkfdQjCOfefw2twjnfYAxMxehQolrLSzyWOFmDV829dU9Q1msCJ/yzsYHX1bIO+zwJuoUBRbKabi086SpV+Vnk6JdQW3Lqc2ztkKRMhbRhmdZKc84TooRw4aKg8/nM2t/7Jmyft+gbz3KkXURDhkYIS1QtVB18C9HyF8OKk9k5TmNfIehILy4q8ohwUZfMNxtoQCJvhxc/w2JUXh4ZMW6qxUVduIwZtv78T7xe7WhUV1XyUFklugBgmI935Hb2k/qH4ZDiyGTrny3jnAg0Xswbtyb2eqDIZyEAMgnHakozTaXaAsDxG2scJSx0ao+FzC1DkddgqcExyxEAWxlegBJcx0EkHUe6F7yLAohGUimxu+tl2NjjhrhkZnzT+lclbCtLxjoM/38YpbPRfgk5xrZehpHTMKKy98=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <6BBBD33FD5CE1341AA3764B4F008073B@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b057460-882e-4f4b-a344-08d76e5ad56c
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 08:14:30.0294 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GYpYzPF2/4/zzZx5YrBDtHhv8b9cY2M47Agnyo/g0WkyJTgJBLEFvkBHyzDy6/Zfl/s7KivjrhQa1n3eRCN/2w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4720
Archived-At: 
Subject: Re: [tcpm] [iccrg] [tsvwg] TCP Prague Update: L4S-related Side Meeting at IETF-106
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, 21 Nov 2019 08:14:50 -0000

Rm9yIHRob3NlIHdobyB3ZXJlIHVuYWJsZSB0byBhdHRlbmQgdGhlIFRDUCBQcmFndWUgc2lkZSBt
ZWV0aW5nIHRoaXMgbW9ybmluZywgdGhlIHJlY29yZGluZyBpcyBhdmFpbGFibGUgaGVyZToNCmh0
dHBzOi8vY2FibGVsYWJzLnpvb20udXMvcmVjb3JkaW5nL3NoYXJlLzlMcEQxdE1JRDEtdDJlaG5N
Z1FhbmE3QkljM3hDUXQxekRPbEJ5eU1hUEt3SXVtZWtUemlNdz9zdGFydFRpbWU9MTU3NDI5NDM4
OTAwMA0KDQpCZXN0IFJlZ2FyZHMsDQpHcmVnIFdoaXRlDQoNCg0KDQrvu79PbiAxMS8yMC8xOSwg
NDoxOCBQTSwgImljY3JnIG9uIGJlaGFsZiBvZiBHcmVnIFdoaXRlIiA8aWNjcmctYm91bmNlc0Bp
cnRmLm9yZyBvbiBiZWhhbGYgb2YgZy53aGl0ZUBDYWJsZUxhYnMuY29tPiB3cm90ZToNCg0KICAg
IEhpIEFubmEsDQogICAgDQogICAgVGhlIHpvb20gc2Vzc2lvbiB3aWxsIGJlIHJlY29yZGVkLiAg
SSB3aWxsIHNlbmQgYSBsaW5rIHRvIHRoZSByZWNvcmRpbmcgb25jZSBpdCBpcyBhdmFpbGFibGUu
DQogICAgDQogICAgLUdyZWcNCiAgICANCiAgICBPbiAxMS8yMC8xOSwgNzoxNSBBTSwgInRzdndn
IG9uIGJlaGFsZiBvZiBBbm5hIEJydW5zdHLDtm0iIDx0c3Z3Zy1ib3VuY2VzQGlldGYub3JnIG9u
IGJlaGFsZiBvZiBhbm5hLmJydW5zdHJvbUBrYXUuc2U+IHdyb3RlOg0KICAgIA0KICAgICAgICBI
aSBCb2IsDQogICAgICAgIA0KICAgICAgICBUaGFua3MgZm9yIGFycmFuZ2luZyBmb3IgcmVtb3Rl
IHBhcnRpY2lwYXRpb24uIERvIHlvdSBhbHNvIHBsYW4gdG8gcmVjb3JkIHRoZSB6b29tIHNlc3Np
b24/IFRpbWUgem9uZXMgYXJlIGEgYml0IGNoYWxsZW5naW5nIDotKQ0KICAgICAgICANCiAgICAg
ICAgUmVnYXJkcywNCiAgICAgICAgQW5uYQ0KICAgICAgICANCiAgICAgICAgLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCiAgICAgICAgRnJvbTogaWNjcmcgPGljY3JnLWJvdW5jZXNAaXJ0Zi5v
cmc+IE9uIEJlaGFsZiBPZiBCb2IgQnJpc2NvZQ0KICAgICAgICBTZW50OiBkZW4gMTggbm92ZW1i
ZXIgMjAxOSAwMzo1Mg0KICAgICAgICBUbzogdHN2d2cgSUVURiBsaXN0IDx0c3Z3Z0BpZXRmLm9y
Zz47IGljY3JnIElSVEYgbGlzdCA8aWNjcmdAaXJ0Zi5vcmc+OyB0Y3BtIElFVEYgbGlzdCA8dGNw
bUBpZXRmLm9yZz4NCiAgICAgICAgU3ViamVjdDogW2ljY3JnXSBUQ1AgUHJhZ3VlIFVwZGF0ZTog
TDRTLXJlbGF0ZWQgU2lkZSBNZWV0aW5nIGF0IElFVEYtMTA2DQogICAgICAgIA0KICAgICAgICBG
b2xrcywNCiAgICAgICAgDQogICAgICAgIFRoZSBzaWduaWZpY2FudCBhbW91bnQgb2YgVENQIFBy
YWd1ZSB1cGRhdGUgbWF0ZXJpYWwgd2FzIHRvbyBncmVhdCBmb3IgdGhlIGljY3JnIGFnZW5kYS4N
CiAgICAgICAgU28sIHdpdGggdGhlIGhlbHAgb2YgdGhlIGljY3JnIGFuZCB0c3Z3ZyBjaGFpcnMg
KHRoYW5rIHlvdSksIHdlJ3ZlIGFycmFuZ2VkIGEgc2lkZSBtZWV0aW5nIHRvIGNvdmVyIGFsbCB0
aGlzLg0KICAgICAgICANCiAgICAgICAgPT1XaGVyZS93aGVuPz09DQogICAgICAgIERhdGU6IFRo
dSAyMSBOb3YgMjAxOQ0KICAgICAgICBUaW1lOiAwODozMCAtIDA5OjMwDQogICAgICAgIFJvb206
IENhbm5pbmcNCiAgICAgICAgDQogICAgICAgID09QWdlbmRhPT0NCiAgICAgICAgaHR0cDovL2Jv
YmJyaXNjb2UubmV0L3Byb2plY3RzL2xhdGVuY3kvVENQX1ByYWd1ZV9zaWRlLW1lZXRpbmdBZ2Vu
ZGFJRVRGLTEwNi5odG1sDQogICAgICAgIA0KICAgICAgICA9PU1lZXRpbmcgTWF0ZXJpYWxzPT0N
CiAgICAgICAgTGlua3MgdG8gbWVldGluZyBtYXRlcmlhbHMgd2lsbCBiZSBhZGRlZCB0byB0aGUg
YWJvdmUgYWdlbmRhIHNvb24uDQogICAgICAgIFRoZXkgd2lsbCBhbHNvIGJlIGFkZGVkIHRvIHRo
ZSB0c3Z3ZyBtZWV0aW5nIG1hdGVyaWFscy4NCiAgICAgICAgDQogICAgICAgID09UmVtb3RlIEF0
dGVuZGFuY2U9PQ0KICAgICAgICBNZWV0ZWNobyBpcyBub3QgYXZhaWxhYmxlIGZvciBzaWRlLW1l
ZXRpbmdzLCBzbyB3ZSdyZSBhcnJhbmdpbmcgYW4gYWx0ZXJuYXRpdmUsIHByb2IgWm9vbSAobGlu
ayB3aWxsIGFwcGVhciBvbiBhZ2VuZGEpDQogICAgICAgIA0KICAgICAgICBSZWdhcmRzDQogICAg
ICAgIA0KICAgICAgICANCiAgICAgICAgQm9iDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAg
LS0NCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KICAgICAgICBCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQogICAgICAgIA0KICAgICAgICBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBp
Y2NyZyBtYWlsaW5nIGxpc3QNCiAgICAgICAgaWNjcmdAaXJ0Zi5vcmcNCiAgICAgICAgaHR0cHM6
Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2NyZw0KICAgICAgICANCiAgICAgICAg
DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCiAgICBpY2NyZyBtYWlsaW5nIGxpc3QNCiAgICBpY2NyZ0BpcnRmLm9yZw0KICAgIGh0dHBz
Oi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNjcmcNCiAgICANCg0K


From nobody Thu Nov 21 18:43: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 3540412012A for ; Thu, 21 Nov 2019 18:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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_PASS=-0.001, TVD_SPACE_RATIO=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=bobbriscoe.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 zh26u69lmzjR for ; Thu, 21 Nov 2019 18:43:42 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 4871412010F for ; Thu, 21 Nov 2019 18:43:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yGbTtrubznLSOYYM9bkKwKVKuFg7wZakr4K+6rZa7JA=; b=YIfhE1nKR5tJSkJ2E/ZWdVHjM3 ba0tnqaVBf2rv4L7j9vlp1BlPVnb+XmEMI+Q0HStdtMDvtDdzhVU+VJkacWAwsSGQBeNkY4KqjbfJ sidhIBrRqmnHgNRvmlKshzfsv7fpDWhfIE7xn7Oovk81kihapGRGkF9WmXzYm/rGJzvVWEw4tRuH8 JJgTNgEyK1AjVq9p/+7GwmOxiWLG8XAQwc+zbOiRgWKjBW7zkd/U5hm07hIROdRp4qPZRgNlAeOqL L0Y6aAge6/5F00EjtLOLvl5p9v87bc1v1rPzKcZ09W3Azy+CFo7EzRduAyDnX0C3sxkp4ynZAX1+m IL4xJKqQ==;
Received: from dhcp-819f.meeting.ietf.org ([31.133.129.159]:44400) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iXyv4-0005bP-Jf; Fri, 22 Nov 2019 02:43:39 +0000
To: Yoshifumi Nishada 
Cc: tcpm IETF list 
From: Bob Briscoe 
Message-ID: <9e3fbb71-ba1b-e85f-8799-449afbbba3bb@bobbriscoe.net>
Date: Fri, 22 Nov 2019 10:43:35 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] AccECN slides
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, 22 Nov 2019 02:43:44 -0000

http://bobbriscoe.net/presents/1911ietf/1911accurate-ecn.pdf

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Thu Nov 21 19:55: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 7DD9C120967 for ; Thu, 21 Nov 2019 19:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 Sbbt000-PLmL for ; Thu, 21 Nov 2019 19:55:04 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 6FA3B1208E1 for ; Thu, 21 Nov 2019 19:55:04 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id v201so3345811lfa.11 for ; Thu, 21 Nov 2019 19:55:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=Pv+tw8qvhOIfXDdnEiF5icGesrRI8qASplXJHuBl+nE=; b=nOIgBRosd7ynba2lunBHXwKLnKkFJVX/8jM6uuueqxH+tozDjfdw7dkx0VDDIQsY7E /U30wvvzWzvzV9EgU47+evacg2FfC5+uA+zIwF9805r0mAlOmMdYmsEUHmPRcCbD4C1H RywXUFCCEqeohIKayaZ3r+HQAC/THUMPx14eK13NGzpNOj/hs9qFkkWivQbH4L2WsQts mfwqyTMWFGf0uTdMyspjWenEoX75ykygnilM0D2eAFSHZfn3RBZRhxDxVP7NoHN8PA/L RcszWa7YR1Z8Nk2obG7+x+P4dwEj2J/eGOydnmgQpgkZPUjP2+H/PEIYE/3zknbCye1a i1/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Pv+tw8qvhOIfXDdnEiF5icGesrRI8qASplXJHuBl+nE=; b=FegOcwHRJKNEivMzPk7svXBxvmSq+VxxbhyDZ2jSgJ8FabCGxc4Qv6JlmxKlQQvjnj sAL75Vz5my2RGOPzmPIvzoA55EYzAFGDV76ntkGpwkyOT9VVlPgqrWR/2b7W65oZAc4A +Ulp+SyG88rS54L7acv1Scue07DaUxay422ss5TgTga+vuwcxd9lPl50jVlSA9EiPhBe iqiv4GnAyF1G5IXGk0fSb0j/X58s7Nnws5HTInvxh7OpByZ+sVQ4txPKCq2RWGR8RO+8 tzrR2gsDdxgmkx8jvB126aR9HMgI++8poSJzJ2BK6+Q7aT5gnJDEq1fZQln3dcDF70Df jK+A==
X-Gm-Message-State: APjAAAXbqxqEXbUGs6aYf1yyWpIV77mbqeZvEL7soIEjHX7uQrH6VUOy 10quW5leZqqxa7gkIE28F7cloGY6MBfN63uoDCZoQLAcOU8=
X-Google-Smtp-Source: APXvYqxH/aHOFh1tX9skTiD5qeIBuLWJ7wp5z5NE2eVR5veecRbydihyS1v2+13SkOh0y6raqOp/AQ/I3P0R5EnnqY4=
X-Received: by 2002:ac2:4c8e:: with SMTP id d14mr2282425lfl.32.1574394902509;  Thu, 21 Nov 2019 19:55:02 -0800 (PST)
MIME-Version: 1.0
From: Jana Iyengar 
Date: Fri, 22 Nov 2019 11:54:51 +0800
Message-ID: 
To: tcpm@ietf.org, mallman@icir.org
Content-Type: multipart/alternative; boundary="000000000000e67f400597e7600e"
Archived-At: 
Subject: [tcpm] (no subject)
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, 22 Nov 2019 03:55:07 -0000

--000000000000e67f400597e7600e
Content-Type: text/plain; charset="UTF-8"

Mark,

Apologies for this late review. It's been a while since I read the draft,
and I have just a couple of comments.

I have one high-order point. The document limits itself to transports where
loss detection *and retransmission* occurs. Specifically, Section (S.2)
says: "The requirements in this document only apply to cases where loss
detected via a timer is repaired by a retransmission of the original data.
Other cases are certainly possible---e.g., replacing the lost data with an
updated version---but fall outside the scope of this document."

There are a couple of other places as well ("all timer-based retransmission
mechanisms", and also in requirement (3)). I would suggest that the draft
applies to loss detection, not to recovery or retransmission. Specifically,
QUIC detects loss using a Probe Timeout (equivalent to an RTO), but may not
retransmit lost data for a variety of reasons. Is there a reason to
preclude this behavior?

More generally, TCP conflates *what* to send with *when* to send it, and
whether to send something is presumed "yes". QUIC decouples these pieces,
and that may be true of other future protocols as well. (This is true of
SCTP using the partial-reliability extension as well, RFC 3758).

The requirements in the document already apply to these protocols, because
the principles apply to the loss detection function of the transport, not
the recovery function.

In terms of text changes, I think simply removing "and retransmission" from
most places is adequate to achieve this. Requirement (3) however relies on
the data getting acked, which can be generalized. The current text is:
"The backoff SHOULD be removed after the successful repair of the lost data
and subsequent transmission of non-retransmitted data."
This can be replaced by:
"The backoff SHOULD be removed after an acknowledgement is received for a
subsequently sent packet."
---

Editorial suggestions:
- remove para beginning with "This document is a bit "weird" ...", and also
drop the phrase "At this point, however" from the beginning of the next
para. This is unnecessary text, IMO.
- Take it or leave it: change title from "Requirements" to "Guidelines".

- jana

--000000000000e67f400597e7600e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Mark,

Apologies for this=
 late review. It's been a while since I read the draft, and I have just=
 a couple of comments.

I have one high-order point=
. The document limits itself to transports where loss detection *and retran=
smission* occurs. Specifically, Section=C2=A0(S.2) says: "The requirem=
ents in this document only apply to cases where loss detected via a timer i=
s repaired by a retransmission of the original data. Other cases are certai=
nly possible---e.g., replacing the lost data with an updated version---but =
fall outside the scope of this document."

There are a co=
uple of other places as well ("all timer-based retransmission mechanis=
ms", and also in requirement (3)). I would suggest that the draft appl=
ies to loss detection, not to recovery or retransmission. Specifically, QUI=
C detects loss using a Probe Timeout (equivalent to an RTO), but may not re=
transmit lost data for a variety of reasons. Is there a reason to preclude =
this behavior?

More generally, TCP conflates *what=
* to send with *when* to send it, and whether to send something is presumed=
 "yes". QUIC decouples these pieces, and that may be true of othe=
r future protocols as well. (This is true of SCTP using the partial-reliabi=
lity extension as well, RFC 3758).

The requirement=
s in the document already apply to these protocols, because the principles =
apply to the loss detection function of the transport, not the recovery fun=
ction.

In terms of text changes, I think simply re=
moving "and retransmission" from most places is adequate to achie=
ve this. Requirement (3) however relies on the data getting acked, which ca=
n be generalized. The current text is:
"The backoff SHOULD be remov=
ed after the successful repair of the lost data and subsequent transmission=
 of non-retransmitted data." 
This can be replaced by:
&q=
uot;The backoff SHOULD be removed after an acknowledgement is received for =
a subsequently sent packet." 
---

Editoria=
l suggestions:
- remove para beginning with "This document i=
s a bit "weird" ...", and also drop the phrase "At this=
 point, however" from the beginning of the next para. This is unnecess=
ary text, IMO.
- Take it or leave it: change title from "=
;Requirements" to "Guidelines".

- j=
ana


--000000000000e67f400597e7600e--


From nobody Thu Nov 21 19:57:09 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 9F60312022D for ; Thu, 21 Nov 2019 19:57:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 HUGqEBpsB4g5 for ; Thu, 21 Nov 2019 19:57:05 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 328BF120103 for ; Thu, 21 Nov 2019 19:57:05 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id e9so5643312ljp.13 for ; Thu, 21 Nov 2019 19:57:05 -0800 (PST)
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;  bh=ffZkQpUrDuT2xYbmMvBGcfDN9lM3RqwG+dJeNWtXIbY=; b=tV6FKPXkRO1G7c/7JTj+IyEJSmvDGJ/i4Z/4v1w0d39nq15Z9O49MrsjicMYAPgQMt zT4KWOzJfJAkTMBt4XY0sAr1kRki+5vg+h/ZojpfaWube3OqIwXeOm+cBISbNUwlnDiR P6MCWCsls//0QQP4/ThLFxSdHhwP1Z2A5b4WqbXT/k3YljRCZi7T4+aHZNNZ0y4XRm14 ldWnnYU3uUReyJkTzuXS3J98kQb5nl7RUV+1sx7D+jVKXsb1o8r6MqwH6Z+27T8/+b5X DE/Hhp00NgJZgDGl+zOBZl7Is60aoZY81yvy0oSz9i7CEyhRhulVCCFTfBeEKYF05zMi Valw==
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; bh=ffZkQpUrDuT2xYbmMvBGcfDN9lM3RqwG+dJeNWtXIbY=; b=g/Bye3dumJydmFymeG6KhC5Mu+npYeXyKHSHkPbCgOmtCYXaoG1TvCPqUnPO7FzT00 b5mC08+oN8o62hgAZPemKT2YXKZfXqu6JPQMAqmKBccU1Hr47UTzg6q+SwCdgbfIvKF/ oIDRyVMRbbQcHEX9Q3g1mjEN32mzGzQBxiE6FT7TIvCU+mvpLEli3zJItmT+0WpMiRjU GU0Vy+Mfd0vzJEV/OpDpmRUIQARgmWemP7xbh3q7eoB3NV3EB0GJgdp661/00WoDTSlr 2TzSvRakwpc4jBB/c1kFWI5paRfJkQyaB+IJ0trgBp3/cTibYKtW/uWaca78KD1FJwO4 JoiQ==
X-Gm-Message-State: APjAAAW7cu6oW1j6A5nOT26KO5Wuv98aFgNdbnvDrgVz1ORQNdxN+Dav Cc7hzryAnlE+dZWFiUZpEAQ2fs3UFXn/Dezbf78UQgSy
X-Google-Smtp-Source: APXvYqxxq9YZppdfPCiR6J/kcOYt25LOCsJn/r8028Q/txeGpHcEUr6Nq4ezfhBK650bmDJTvOYBirzR/aN9CnEAny8=
X-Received: by 2002:a2e:9016:: with SMTP id h22mr10160291ljg.137.1574395023350;  Thu, 21 Nov 2019 19:57:03 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jana Iyengar 
Date: Fri, 22 Nov 2019 11:56:52 +0800
Message-ID: 
To: tcpm@ietf.org, mallman@icir.org
Content-Type: multipart/alternative; boundary="0000000000001a606b0597e76809"
Archived-At: 
Subject: [tcpm] review of draft-ietf-tcpm-rto-consider-08
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, 22 Nov 2019 03:57:08 -0000

--0000000000001a606b0597e76809
Content-Type: text/plain; charset="UTF-8"

Gah! Now with a (better) subject line.

On Fri, Nov 22, 2019 at 11:54 AM Jana Iyengar  wrote:

> Mark,
>
> Apologies for this late review. It's been a while since I read the draft,
> and I have just a couple of comments.
>
> I have one high-order point. The document limits itself to transports
> where loss detection *and retransmission* occurs. Specifically,
> Section (S.2) says: "The requirements in this document only apply to cases
> where loss detected via a timer is repaired by a retransmission of the
> original data. Other cases are certainly possible---e.g., replacing the
> lost data with an updated version---but fall outside the scope of this
> document."
>
> There are a couple of other places as well ("all timer-based
> retransmission mechanisms", and also in requirement (3)). I would suggest
> that the draft applies to loss detection, not to recovery or
> retransmission. Specifically, QUIC detects loss using a Probe Timeout
> (equivalent to an RTO), but may not retransmit lost data for a variety of
> reasons. Is there a reason to preclude this behavior?
>
> More generally, TCP conflates *what* to send with *when* to send it, and
> whether to send something is presumed "yes". QUIC decouples these pieces,
> and that may be true of other future protocols as well. (This is true of
> SCTP using the partial-reliability extension as well, RFC 3758).
>
> The requirements in the document already apply to these protocols, because
> the principles apply to the loss detection function of the transport, not
> the recovery function.
>
> In terms of text changes, I think simply removing "and retransmission"
> from most places is adequate to achieve this. Requirement (3) however
> relies on the data getting acked, which can be generalized. The current
> text is:
> "The backoff SHOULD be removed after the successful repair of the lost
> data and subsequent transmission of non-retransmitted data."
> This can be replaced by:
> "The backoff SHOULD be removed after an acknowledgement is received for a
> subsequently sent packet."
> ---
>
> Editorial suggestions:
> - remove para beginning with "This document is a bit "weird" ...", and
> also drop the phrase "At this point, however" from the beginning of the
> next para. This is unnecessary text, IMO.
> - Take it or leave it: change title from "Requirements" to "Guidelines".
>
> - jana
>

--0000000000001a606b0597e76809
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Gah! Now with a (better) subject line.

On Fri, Nov 22,=
 2019 at 11:54 AM Jana Iyengar <jr=
i.ietf@gmail.com> wrote:
Mark,

Ap=
ologies for this late review. It's been a while since I read the draft,=
 and I have just a couple of comments.

I have one =
high-order point. The document limits itself to transports where loss detec=
tion *and retransmission* occurs. Specifically, Section=C2=A0(S.2) says: &q=
uot;The requirements in this document only apply to cases where loss detect=
ed via a timer is repaired by a retransmission of the original data. Other =
cases are certainly possible---e.g., replacing the lost data with an update=
d version---but fall outside the scope of this document."
There are a couple of other places as well ("all timer-based retrans=
mission mechanisms", and also in requirement (3)). I would suggest tha=
t the draft applies to loss detection, not to recovery or retransmission. S=
pecifically, QUIC detects loss using a Probe Timeout (equivalent to an RTO)=
, but may not retransmit lost data for a variety of reasons. Is there a rea=
son to preclude this behavior?

More generally, TCP=
 conflates *what* to send with *when* to send it, and whether to send somet=
hing is presumed "yes". QUIC decouples these pieces, and that may=
 be true of other future protocols as well. (This is true of SCTP using the=
 partial-reliability extension as well, RFC 3758).

The requirements in the document already apply to these protocols, because=
 the principles apply to the loss detection function of the transport, not =
the recovery function.

In terms of text changes, I=
 think simply removing "and retransmission" from most places is a=
dequate to achieve this. Requirement (3) however relies on the data getting=
 acked, which can be generalized. The current text is:
"The backoff=
 SHOULD be removed after the successful repair of the lost data and subsequ=
ent transmission of non-retransmitted data." 
This can be replaced =
by:
"The backoff SHOULD be removed after an acknowledgement =
is received for a subsequently sent packet." 
---

Editorial suggestions:
- remove para beginning with "=
;This document is a bit "weird" ...", and also drop the phra=
se "At this point, however" from the beginning of the next para. =
This is unnecessary text, IMO.
- Take it or leave it: change =
title from "Requirements" to "Guidelines".
- jana




--0000000000001a606b0597e76809--


From nobody Thu Nov 21 20:12:28 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 30FEC12003F for ; Thu, 21 Nov 2019 20:12:27 -0800 (PST)
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 w9CrHUblN19W for ; Thu, 21 Nov 2019 20:12:25 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 050AF120025 for ; Thu, 21 Nov 2019 20:12:24 -0800 (PST)
Received: from dhcp-9bdb.meeting.ietf.org (dhcp-9bdb.meeting.ietf.org [31.133.155.219]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 80F7B1B001FC for ; Fri, 22 Nov 2019 04:12:08 +0000 (GMT)
Message-ID: <5DD76011.9030701@erg.abdn.ac.uk>
Date: Fri, 22 Nov 2019 12:12:01 +0800
From: G Fairhurst 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tcpm@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [tcpm] GF review of draft-ietf-tcpm-rto-consider-08
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, 22 Nov 2019 04:12:27 -0000

I presented slides to motivate more review of RTO-consider, (as an 
invited reviewer providing individual comments), so it seemed useful to 
copy these comments in the TCPM list,
best wishes,

Gorry

---

I read draft-ietf-tcpm-rto-consider-08.

I found this *is* readable.
The basis seems correct to me.
It (mostly) comes to the same conclusions as CC Guidelines (an 
individual draft) and this can I think proceed in parallel - I don't see 
that any future CC Guidelines needs to proceed first.
---
(Comment 1)
This sets out to BCP status, which makes me note:
Current text: "The correct way to
view this document is as the default case and these other specifications 
as agreed upon deviations from the default."
- where as the abstract concludes:
Current text: "Within the requirements, implementations have latitude
to define particulars that best address each situation."
- My comment is ... Does this really update existing RFCs?

As also current text:
E.g., a protocol like SCTP (or DCCP) could leverage...

- Is that over-riding the RFCs that define these, or is this intended as 
something more like:
E.g., a new protocol with a design like SCTP [RFC4960] could leverage
---
(Comment 2)
Current text: "In steady state the RTO SHOULD be set based on recent
observations of both the FT and the variance of the FT."
- I dont think these are wrong, but I think the advice of "recent" is 
not very crisp for a BCP - how recent? Can we set any upper bound or 
motivate how we would judge whether a protocol met the "SHOULD"?

---
(Comment 3)
Current text: "FT observations SHOULD be taken regularly ...
The notion of "regularly" SHOULD be defined as at least once
per RTT or as frequently as data is exchanged in cases where that 
happens less frequently than once per RTT."
- To me, this reads as impossible to read RFC2119 text, is this a 
definition or something else? or Designs are REQUIRED to define ... etc.

I hope this actually is intended to be:

I wonder if this proposed text below could be better "FT observations 
SHOULD be taken be at least once
per RTT or as frequently as data is exchanged in cases where that 
happens less frequently than once per RTT."
----
(Comment 4)
Current text: "Retransmissions triggered by the RTO mechanism MUST be 
taken as indications of network congestion and the sending rate adapted 
using a standard mechanism (e.g., TCP collapses the congestion window to 
one segment [RFC5681]).
- Is this the word intended to be /retransmissions/, or a time-out of 
the RTO?
(in CC guidelines this described as a lack of response that needs to be 
handled in this way).
---
(Comment 5)
Current text: "Finally, we note that while allowing implementations to 
be more aggressive may in fact increase the number of needless 
retransmissions"
- Textual NiT: I think it would be wiser to say /could/ rather than 
/may/ to be sure no-one seems readable as potentially permissive.

---


From nobody Fri Nov 22 05:45: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 7462112084E for ; Fri, 22 Nov 2019 05:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Xz6gBQF0B3o6 for ; Fri, 22 Nov 2019 05:45:36 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B60C12081A for ; Fri, 22 Nov 2019 05:45:36 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E3FB82C4058; Fri, 22 Nov 2019 05:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g+6LxG4XzlE1; Fri, 22 Nov 2019 05:45:35 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 77DC92C404F; Fri, 22 Nov 2019 05:45:35 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 26D081E87D67; Fri, 22 Nov 2019 08:45:35 -0500 (EST)
From: "Mark Allman" 
To: "G Fairhurst" 
Cc: Extensions 
Date: Fri, 22 Nov 2019 08:45:34 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [tcpm] rto-consider: "regularly" taking RTT samples
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, 22 Nov 2019 13:45:38 -0000

Hi Gorry!

Thanks for all the comments.  I am going to work through them and
hack on the document.  I am addressing a couple of the easier
comments today.  But, will address them all soon.

I-D>> In steady state the RTO SHOULD be set based on recent
I-D>> observations of both the FT and the variance of the FT.

Gorry> - I don’t think these are wrong, but I think the advice is
Gorry>   not very crisp for a BCP - how recent? How does this relate
Gorry>   to Comment 3?

The "recent" here is defined in requirement (2b), as you note.  So,
it isn't meant to be crisp here.  I can see two paths:

(1) Remove the word "recent" from here.  The overall point of
    guideline (2a) is really that the RTO SHOULD be based on
    observations---i.e., not statically set.  The notion of "recent"
    isn't hugely important here as it is concretely developed in
    (2b).

OR,

(2) We could leave the "recent" in (2a) with a forward reference to
    indicate we are not leaving this as nebulous somehow.  E.g.,
    "... recent observations---as defined below---of both ..." if
    folks think keeping this notion (colloquially) in (2a) is a good
    idea.

I am pretty indifferent to both options.

I-D>> FT observations SHOULD be taken regularly ...
I-D>>
I-D>> The notion of "regularly" SHOULD be defined as at least once
I-D>> per RTT or as frequently as data is exchanged in cases where
I-D>> that happens less frequently than once per RTT.

Gorry> - To me, reads as impossible RFC2119 text, is this a
Gorry>   definition or something else? or Designs are REQUIRED to
Gorry>   define ... etc.

I really can't parse the complaint here (which is probably because
you well explained it, but since I wasn't there the slide isn't
conveying that to me).  I don't see this impossibility you are
suggesting.

That said,

Gorry> I hope this actually is intended to be:
Gorry> FT observations SHOULD be taken be at least once
Gorry> per RTT or as frequently as data is exchanged in cases where
Gorry> that happens less frequently than once per RTT.

This is in fact the intent and I am happy to use those words.

allman


From nobody Fri Nov 22 05:58:52 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 56EB2120147 for ; Fri, 22 Nov 2019 05:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 MTnkKXPalxj8 for ; Fri, 22 Nov 2019 05:58:50 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445431200B9 for ; Fri, 22 Nov 2019 05:58:50 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 251962C404F; Fri, 22 Nov 2019 05:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K8aIQzsRw7KJ; Fri, 22 Nov 2019 05:58:49 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 95DAA2C402B; Fri, 22 Nov 2019 05:58:49 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 441F61E88755; Fri, 22 Nov 2019 08:58:49 -0500 (EST)
From: "Mark Allman" 
To: "G Fairhurst" 
Cc: Extensions 
Date: Fri, 22 Nov 2019 08:58:49 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <37BEAEC9-3D47-4312-9BDB-6F963617A3BB@icir.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [tcpm] rto-consider: may vs could wording nit
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, 22 Nov 2019 13:58:51 -0000

I-D>> Finally, we note that while allowing implementations to be
I-D>> more aggressive may in fact increase the number of needless
I-D>> retransmissions

Gorry> - I think it would be wiser to say /could/ to be sure no-one
Gorry>   seems readable as potentially permissive.

I really don’t grok this comment.  However, I see no harm in
changing “may” to "could" and so I've done it.

allman


From nobody Fri Nov 22 09:56:00 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 2F66A120856 for ; Fri, 22 Nov 2019 09:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qvPSSvgyvaLh for ; Fri, 22 Nov 2019 09:55:58 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7FA120089 for ; Fri, 22 Nov 2019 09:55:58 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A63A62C4077; Fri, 22 Nov 2019 09:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DDrOkSg+zqVK; Fri, 22 Nov 2019 09:55:57 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 41AC52C4068; Fri, 22 Nov 2019 09:55:57 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E486A1E8AE37; Fri, 22 Nov 2019 12:55:56 -0500 (EST)
From: "Mark Allman" 
To: "G Fairhurst" 
Cc: Extensions 
Date: Fri, 22 Nov 2019 12:55:56 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [tcpm] rto-consider: retransmission vs vs loss detection
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, 22 Nov 2019 17:55:59 -0000

I-D>> Retransmissions triggered by the RTO mechanism MUST be taken
I-D>> as indications of network congestion and the sending rate
I-D>> adapted using a standard mechanism (e.g., TCP collapses the
I-D>> congestion window to one segment [RFC5681]).

Gorry> - Is this the retransmissions, or a time-out of the RTO?  (in
Gorry>   CC guidelines this described as a lack of response that
Gorry>   needs to be handled in this way).

Good catch.  I hacked the point to be in line with your suggestion.
I now have it as:

    (4) Loss detected by the RTO mechanism MUST be taken as an
        indication of network congestion and the sending rate adapted
        using a standard mechanism (e.g., TCP collapses the congestion
        window to one segment [RFC5681]).

Let me know if I need to do more work here.

allman


From nobody Fri Nov 22 17:31:27 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 DEE1C1200B7 for ; Fri, 22 Nov 2019 17:31:25 -0800 (PST)
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 7-KYcOSjIVp7 for ; Fri, 22 Nov 2019 17:31:23 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id B2F311200B6 for ; Fri, 22 Nov 2019 17:31:23 -0800 (PST)
Received: from G-MacBook.local (unknown [132.147.98.37]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C9D001B001FC; Sat, 23 Nov 2019 01:31:17 +0000 (GMT)
Message-ID: <5DD88BE2.8090604@erg.abdn.ac.uk>
Date: Sat, 23 Nov 2019 09:31:14 +0800
From: G Fairhurst 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Mark Allman 
CC: Extensions 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [tcpm] rto-consider: "regularly" taking RTT samples
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: Sat, 23 Nov 2019 01:31:26 -0000

Hi Mark!

On 22/11/2019, 21:45, Mark Allman wrote:
> Hi Gorry!
>
> Thanks for all the comments.  I am going to work through them and
> hack on the document.  I am addressing a couple of the easier
> comments today.  But, will address them all soon.
>
> I-D>>  In steady state the RTO SHOULD be set based on recent
> I-D>>  observations of both the FT and the variance of the FT.
>
> Gorry>  - I don’t think these are wrong, but I think the advice is
> Gorry>    not very crisp for a BCP - how recent? How does this relate
> Gorry>    to Comment 3?
>
> The "recent" here is defined in requirement (2b), as you note.  So,
> it isn't meant to be crisp here.  I can see two paths:
>
> (1) Remove the word "recent" from here.  The overall point of
>      guideline (2a) is really that the RTO SHOULD be based on
>      observations---i.e., not statically set.  The notion of "recent"
>      isn't hugely important here as it is concretely developed in
>      (2b).
>
> OR,
>
> (2) We could leave the "recent" in (2a) with a forward reference to
>      indicate we are not leaving this as nebulous somehow.  E.g.,
>      "... recent observations---as defined below---of both ..." if
>      folks think keeping this notion (colloquially) in (2a) is a good
>      idea.
>
> I am pretty indifferent to both options.
Omitting the word (a) is indeed easy. I suspect the new formulation of 
(b) effectively defines regularly, so a recent sample should be available.
> I-D>>  FT observations SHOULD be taken regularly ...
> I-D>>
> I-D>>  The notion of "regularly" SHOULD be defined as at least once
> I-D>>  per RTT or as frequently as data is exchanged in cases where
> I-D>>  that happens less frequently than once per RTT.
>
> Gorry>  - To me, reads as impossible RFC2119 text, is this a
> Gorry>    definition or something else? or Designs are REQUIRED to
> Gorry>    define ... etc.
>
> I really can't parse the complaint here (which is probably because
> you well explained it, but since I wasn't there the slide isn't
> conveying that to me).  I don't see this impossibility you are
> suggesting.
Sorry, happy to explain why I thiunk this can be misread, but reading-on 
we already have a solution that works for me.
> That said,
>
> Gorry>  I hope this actually is intended to be:
> Gorry>  FT observations SHOULD be taken be at least once
> Gorry>  per RTT or as frequently as data is exchanged in cases where
> Gorry>  that happens less frequently than once per RTT.
>
> This is in fact the intent and I am happy to use those words.
Then let's do that.
> allman
Gorry


From nobody Sat Nov 23 03:27:13 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 AA976120058 for ; Sat, 23 Nov 2019 03:27:10 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 LTgqc9RRBLFz for ; Sat, 23 Nov 2019 03:27:08 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 157C1120048 for ; Sat, 23 Nov 2019 03:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XSxDEXDX6DrClG9a7082dv/0+CQwR6L4Wn1Ef79IDJo=; b=GH7aBYPJLp4yybcDdrV2JDZgR3 seDgcWglmDDc9G1xHmybxt9khAMeVQ3dmCSA/D4HdawXCxC0Z//5/slTn+jYZeVmJzcXQtm9MoB8b +CbUeFdYCdomOVaIakgg/r5hVHExnc6DpAbe+js3R9jQdiaHUu3BG6ZcY+WrYzBORkHMkgl52qbki dvFnU2FhxWKnCgYJk8txKq0pSBFlGtxDmGqWxlZb3ZNid8iw2Hg84Mgd1UvVtZQZ7mqwnttsMhiOo I0lu2TopwaKSuUba7pxCuzqKwHUaVWBW5OB3F6B848pYBogWA6TTGXqxFqDOjoPK3SkIGLD7Fp2j9 rH+Z8QPQ==;
Received: from [31.185.128.31] (port=39306 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iYTZ6-0007zu-VN for tcpm@ietf.org; Sat, 23 Nov 2019 11:27:02 +0000
To: tcpm IETF list 
From: Bob Briscoe 
Message-ID: <83880058-a057-66bf-24a3-855480b29f00@bobbriscoe.net>
Date: Sat, 23 Nov 2019 19:26:59 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------0990FEC165EB1A4890B458DE"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] Impact on AccECN draft of change from EXP to PS
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: Sat, 23 Nov 2019 11:27:11 -0000

This is a multi-part message in MIME format.
--------------0990FEC165EB1A4890B458DE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

tcpm-ers,

Here's analysis of the things in draft-ietf-tcpm-accurate-ecn that would 
have to be altered to upgrade it to PS from EXP. This was generally 
favoured in the tcpm meeting today, but it has to be ratified on this 
list, so I thought this info would be helpful.

==Header Block==
Intended Status: Proposed Standard
Updates: 3168

==Throughout==
(substituting intelligently):
s/experimental/standards track/
s/other experiments/experiments/
s/other variants/variants/

==1. Intro==
CURRENT:
  "Until the AccECN experiment succeeds, [RFC3168] will remain as the
    only standards track specification for adding ECN to TCP. "
PROPOSED:
   Instead, summarize here how this doc updates RFC3168, referring to a 
new section XXX (below) that gives detailed updates.

CURRENT:
  "It is completely independent of how TCP might respond to congestion
   feedback, which is out of scope. For that we refer to [RFC3168]..."
PROPOSED
  "It is completely independent of how TCP might respond to congestion
   feedback, which is out of scope. For that we refer to [RFC3168] and 
[RFC8311], excepting the updates to RFC 3168 in Section XXX of the 
present document that generalize the wording to include AccECN."

==1.1 Document Roadmap==
Remove ref to 1.3 & include a ref to the new section XXX detailing the 
updates to 3168.

==1.3 Experiment Goals==
Delete section

FYI, the two experiment goals are:
1. fall-back strategies in the face of path traversal problems
2. interaction of change-triggered ACKs and offloaded processing

The two "MUST" requirements behind #2 have just been relaxed to 
"SHOULD"s as part of the splitting up of change-triggered ACKs between 
ACE and the AccECN TCP Option, as I mentioned in the presentation to the WG.

#1 is more likely to affect implementation than design, given the design 
provides for fall-back in most conceivable circumstances (e.g. it is 
designed for any or all AccECN TCP options to be sent but not received 
{Note 1}) and there's considerable checking of mangling already. 
Nonetheless, we might find byzantine middlebox behaviour, e.g. stripping 
the TCP option from some packets but not others, altering selected 
protocol fields, altering some header bits but not others,... I'd like 
to see some large-scale testing over production networks before the RFC 
is published.

{Note 1}: Altho the latest change has made it necessary to receive the 
first AccECN Option in each direction to be able to correctly understand 
later options.

==XXX. Updates to RFC3168==
New section XXX between sections 3 & 4.
For content, see later in this email.

==3.2.6 The AccECN Option==
The Kind of the option can be assigned a permanent value, rather than a 
2B longer option with Kind=254 and a magic number.

==6. IANA Considerations==
Delete the para about using experimental option 254.



===Section XXX. Updates to RFC3168===

The following sections of RFC3168 would be updated by the AccECN 
specification, if it were stds track:

  * The Introduction to Section "6. Support from the Transport Protocol"
    that summarizes the way TCP feeds back ECN markings
  * the whole of "6.1.1  TCP Initialization"
  * The whole of "6.1.2. The TCP Sender" except the second, third and
    last paras still apply to RFC5681 congestion control, but not
    necessarily to other experimental forms of ECN congestion control
    allowed by RFC8311 (specified by a suitable experimental RFC).
  * The whole of "6.1.3.  The TCP Receiver" except the last two
    sentences till stand (which are incidentally in the wrong section,
    because they relate to TCP sender behaviour):
         "Some care
        is required if the TCP sender is to avoid unnecessary reductions of
        the congestion window when a window of data includes both dropped
        packets and (marked) CE packets.  This is illustrated in
    [Floyd98]. "
  * The following text within "6.1.5. Retransmitted TCP packets" is
    updated as follows:
      o CURRENT:
        "the TCP data receiver SHOULD
        ignore the ECN field on arriving data packets that are outside
        of the
        receiver's current window."
      o UPDATED:
        "The TCP data receiver MUST ignore the CE codepoint on incoming
        segments that fail any validity check.  The validity check in
        section
        5.2 of [RFC5961] is RECOMMENDED."
  * Section "5.2 Dropped or Corrupted Packets" of RFC3168 says '"pure"
    ACK packets MUST NOT indicate ECN-Capability.' The AccECN draft will
    not update this aspect, but it will say what TCP should do if it
    receives an ECN-capable pure ACK.

I'm slightly unsure about this one - any opinions?:

  * Section "23.2 TCP header Flags" within the "IANA Considerations"
    Section:
    If AccECN is going to update 3168, we will need to consider whether
    to update the names ECE and CWR. Even though they don't do anything
    related to those names in AccECN, AccECN has to be able to fall-back
    to 3168, so I suggest we keep these names.


==Opportunities to close loop-holes==

I would also like people to check through RFC3168 to look for 
opportunities to make behaviour for currently unused values in protocol 
fields unambiguous - in order to allow for forward compatibility (or 
remove unnecessary restrictions on forward compatibility) for other 
future protocols derived from RFC3168.

As well as the changes that AccECN already makes to the TCP part of 
3168, making AccECN stds track would give an opportunity to update some 
TCP feedback-related aspects of 3168 that might have been overlooked 
when 8311 was written. I can't think of any, but I'll check and it would 
be good if others did too.




Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------0990FEC165EB1A4890B458DE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    tcpm-ers,

    

    Here's analysis of the things in draft-ietf-tcpm-accurate-ecn that
    would have to be altered to upgrade it to PS from EXP. This was
    generally favoured in the tcpm meeting today, but it has to be
    ratified on this list, so I thought this info would be helpful.

    

    ==Header Block==

    Intended Status: Proposed Standard

    Updates: 3168

    

    ==Throughout==

    (substituting intelligently): 

    s/experimental/standards track/

    s/other experiments/experiments/

    s/other variants/variants/

    

    ==1. Intro==

    CURRENT:

     "Until the AccECN experiment succeeds, [RFC3168] will remain as the

       only standards track specification for adding ECN to TCP. "

    PROPOSED:

      Instead, summarize here how this doc updates RFC3168, referring to
    a new section XXX (below) that gives detailed updates.

    

    CURRENT:

     "It is completely independent of how TCP might respond to
    congestion

      feedback, which is out of scope. For that we refer to
    [RFC3168]..."

    PROPOSED

     "It is completely independent of how TCP might respond to
    congestion

      feedback, which is out of scope. For that we refer to [RFC3168]
    and [RFC8311], excepting the updates to RFC 3168 in Section XXX of
    the present document that generalize the wording to include AccECN."

    

    ==1.1 Document Roadmap==

    Remove ref to 1.3 & include a ref to the new section XXX
    detailing the updates to 3168.

    

    ==1.3 Experiment Goals==

    Delete section 

    

    FYI, the two experiment goals are: 

    1. fall-back strategies in the face of path traversal problems

    2. interaction of change-triggered ACKs and offloaded processing

    

    The two "MUST" requirements behind #2 have just been relaxed to
    "SHOULD"s as part of the splitting up of change-triggered ACKs
    between ACE and the AccECN TCP Option, as I mentioned in the
    presentation to the WG.

    

    #1 is more likely to affect implementation than design, given the
    design provides for fall-back in most conceivable circumstances
    (e.g. it is designed for any or all AccECN TCP options to be sent
    but not received {Note 1}) and there's considerable checking of
    mangling already. Nonetheless, we might find byzantine middlebox
    behaviour, e.g. stripping the TCP option from some packets but not
    others, altering selected protocol fields, altering some header bits
    but not others,... I'd like to see some large-scale testing over
    production networks before the RFC is published.

    

    {Note 1}: Altho the latest change has made it necessary to receive
    the first AccECN Option in each direction to be able to correctly
    understand later options.

    

    ==XXX. Updates to RFC3168==

    New section XXX between sections 3 & 4.

    For content, see later in this email.

    

    ==3.2.6 The AccECN Option==

    The Kind of the option can be assigned a permanent value, rather
    than a 2B longer option with Kind=254 and a magic number.

    

    ==6. IANA Considerations==

    Delete the para about using experimental option 254.

    

    

    

    ===Section XXX. Updates to RFC3168===

    

    The following sections of RFC3168 would be updated by the AccECN
    specification, if it were stds track:

    
    
      
  • The Introduction to Section "6. Support from the Transport
        Protocol" that summarizes the way TCP feeds back ECN markings
    • 
      
  • the whole of "6.1.1  TCP Initialization" 
    • 
      
  • The whole of "6.1.2. The TCP Sender" except the second, third
        and last paras still apply to RFC5681 congestion control, but
        not necessarily to other experimental forms of ECN congestion
        control allowed by RFC8311 (specified by a suitable experimental
        RFC).
    • 
      
  • The whole of "6.1.3.  The TCP Receiver" except the last two
        sentences till stand (which are incidentally in the wrong
        section, because they relate to TCP sender behaviour):
    
            "Some care

    
           is required if the TCP sender is to avoid unnecessary
        reductions of
    
           the congestion window when a window of data includes both
        dropped
    
           packets and (marked) CE packets.  This is illustrated in
        [Floyd98].
"
    • 
      
  • The following text within "6.1.5. Retransmitted TCP packets"
        is updated as follows:
    • 
      
      
        
    • CURRENT:
      
          "the TCP data receiver SHOULD

      
          ignore the ECN field on arriving data packets that are outside
          of the

      
          receiver's current window."
      • 
      
    
      
      
        
    • UPDATED:
      
          "The TCP data receiver MUST ignore the CE codepoint on
          incoming
      
          segments that fail any validity check.  The validity check in
          section
      
          5.2 of [RFC5961] is RECOMMENDED."
      • 
      
    
      
  • Section "5.2 Dropped or Corrupted Packets" of RFC3168 says
        '"pure" ACK packets MUST NOT indicate ECN-Capability.' The
        AccECN draft will not update this aspect, but it will say what
        TCP should do if it receives an ECN-capable pure ACK.
    
      
    • 
    

    I'm slightly unsure about this one - any opinions?:

    
    
      
  • Section "23.2 TCP header Flags" within the "IANA
        Considerations" Section:
    
        If AccECN is going to update 3168, we will need to consider
        whether to update the names ECE and CWR. Even though they don't
        do anything related to those names in AccECN, AccECN has to be
        able to fall-back to 3168, so I suggest we keep these names.
    
      
    • 
    

    

    ==Opportunities to close loop-holes==

    

    I would also like people to check through RFC3168 to look for
    opportunities to make behaviour for currently unused values in
    protocol fields unambiguous - in order to allow for forward
    compatibility (or remove unnecessary restrictions on forward
    compatibility) for other future protocols derived from RFC3168. 

    

    As well as the changes that AccECN already makes to the TCP part of
    3168, making AccECN stds track would give an opportunity to update
    some TCP feedback-related aspects of 3168 that might have been
    overlooked when 8311 was written. I can't think of any, but I'll
    check and it would be good if others did too.

    

    

    

    

    Bob

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------0990FEC165EB1A4890B458DE--


From nobody Sat Nov 23 03:27: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 BEA5E1207FD for ; Sat, 23 Nov 2019 03:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 OOAnyyJH77Yi for ; Sat, 23 Nov 2019 03:27:52 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 3040C12008A for ; Sat, 23 Nov 2019 03:27:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/8l0hp0cPoVwltyhrS4S4+0qdL7zHhA4o1o1O5/7dlM=; b=Ep0ZrGhAgAHEtLv9Qj5MHcZXwt bj71TXQ+xT5hWo1qlm5TqePtGR2j4PC6KnMTkmr4ikom2N+8bJyY6rlO1cqzUQBz94cG7Xir0osXX 7IMCCz9PTD6u6N5NIuGIu8hMVp6bRoaut3u6HL1CffUA6PgRVbJUUoUWAz0tbv1ZPCO5mnMlLyIKp 9xu5O+kcFLwpx004rNrLWqMVZzxzZA6TgzffBL5U4i4tcCmuGCuQUbmx0zieAKoc6rn2EZTDm2m5q 3iLoVV96RWv9Wyv3NERJdeirYu+5iU2sX5pfNXXzqXL9SUlVHfR1Z6p6jupG2C9SstMfKAwal/YCJ ZJZiuroQ==;
Received: from [31.185.128.31] (port=39314 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iYTZt-00088D-Ks; Sat, 23 Nov 2019 11:27:50 +0000
To: tcpm IETF list , Mirja Kuehlewind , Richard Scheffenegger 
From: Bob Briscoe 
Message-ID: 
Date: Sat, 23 Nov 2019 19:27:48 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] A possible simplification for AccECN servers
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: Sat, 23 Nov 2019 11:27:55 -0000

tcpm-ers, Mirja, Richard,

draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled 
server MUST support both classic ECN and non ECN. However, that's not 
actually necessary for interoperability. Certainly, when an AccECN 
server receives a non-ECN-setup SYN, it MUST fall back to a 
non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone 
object if we change it from MUST to SHOULD respond with an ECN-setup 
SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?

Potential reasons for a server only supporting AccECN and non-ECN (which 
we can put in the draft):
* lightweight server to minimize code complexity;
* to allow for the possibility that AccECN clients might one day have 
widely replaced classic ECN, and some servers might choose to remove 
their classic ECN code to save having to maintain it.



FYI, the other way round, no such simplification of the client is 
possible. 'Cos there's no space for an AccECN SYN to say "I support 
AccECN but not ECN". So the client has to be able to support all three 
(AccECN, Classic ECN and non-ECN).




Bob



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Sat Nov 23 06:07:01 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 E0BEF1200D8 for ; Sat, 23 Nov 2019 06:06:59 -0800 (PST)
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, HTML_MESSAGE=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 KBam8qtjae91 for ; Sat, 23 Nov 2019 06:06:56 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 C1372120088 for ; Sat, 23 Nov 2019 06:06:56 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id o49so11453579qta.7 for ; Sat, 23 Nov 2019 06:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b6dL/yOr81p14tFTefGm2785sf8CmbFbjH1uChChuto=; b=fzPixsZzEJI5ieL9TOzgrAZHdXlNscNODu5zXCh1MAbsEuYjYrU3Nak9zEqogT0b2Q MTW0FM4vLyKCksUMk5sA0PZPj6T41iIXgYjqV1OHbwYBpJPdxEelP/Oq76stC5SdTZC+ dJ+Zc/OWxJAomtq58MUmy7DcI0W/UIBCYi50Ib8Ky/R1Hrwr3Kz23fS9Xov5KuQ8RZbU tKivKRC1pIc7m1DCf3se1MOsWe1u4gMYToaTOTGKgGqU/+/jzdhEgngVdb9SgOpmDpId AYB6iADuUuBuTA3F4fKNKpCMe19Xdo9MAWExYeh2x1Ibb77sNXA4KeGQkCqyrks+Pigq 64pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b6dL/yOr81p14tFTefGm2785sf8CmbFbjH1uChChuto=; b=CjKPqb/xGrFCXAWNTsDKl/Nkd1spEuCjzbyZ4Hig3b4nYp0/uQTNqzyLLyZiMwJOVU JdpAvMr9a6BcPSUHBk/a9+6tH9MIewdxr6MCGmlqw8m4Tc7MqnNfMj0PzONezugKEp70 FaPXmKd0sD6EaFCSrjMbyPk1hbtIxnUvzFb9ScWEWB/eFSOCRMBEt1Aw38FirhDlTrKh kYgNs6pJU5wGMG2BdJigT+AiUfoco2EuXRNP498mAZzK1SLDnYuEpe5djIGpwbcQbc/Q r8KJCwbrE/q2x0BMfCapsAeGZ1lNOtfTXIw/iUZB/E+V9uOowrv3U2W0d1lpO8XNSD+V asAw==
X-Gm-Message-State: APjAAAUPyLZLDQwI5wWxvo1bUcOxuFVhILh0iOZtGyfFSuzFMeFFOUxJ n/ZVzzJn+8FkZDZYFhT/19+T8qdhE7G5rqay7kk=
X-Google-Smtp-Source: APXvYqxUz6Jb4f0aMa16OKpE1GJyFiDM7GEKzx+1ej88FJDTOHnSoTE5Oh+yhB4QdZf+ph2n/CDn/iGlyO4zneYmQo8=
X-Received: by 2002:aed:24af:: with SMTP id t44mr5270528qtc.57.1574518015671;  Sat, 23 Nov 2019 06:06:55 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a0c:e48b:0:0:0:0:0 with HTTP; Sat, 23 Nov 2019 06:06:54 -0800 (PST)
Received: by 2002:a0c:e48b:0:0:0:0:0 with HTTP; Sat, 23 Nov 2019 06:06:54 -0800 (PST)
In-Reply-To: 
References: 
From: Jonathan Morton 
Date: Sat, 23 Nov 2019 16:06:54 +0200
Message-ID: 
To: Bob Briscoe 
Cc: Richard Scheffenegger , tcpm IETF list ,  Mirja Kuehlewind 
Content-Type: multipart/alternative; boundary="0000000000000441b50598040be6"
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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: Sat, 23 Nov 2019 14:07:00 -0000

--0000000000000441b50598040be6
Content-Type: text/plain; charset="UTF-8"

I believe that taking advantage of such a provision would result in a
violation of RFC-3168, as seen by a server supporting that specification
but not AccECN.

If I happen to be wrong about that, could you explain how the server gets
to know that the connection has reverted to Not-ECT mode after sending a
SYN-ACK confirming RFC-3168 support in response to a valid RFC-3168 SYN?

- Jonathan Morton

--0000000000000441b50598040be6
Content-Type: text/html; charset="UTF-8"


I believe that taking advantage of such a provision would result in a violation of RFC-3168, as seen by a server supporting that specification but not AccECN.


If I happen to be wrong about that, could you explain how the server gets to know that the connection has reverted to Not-ECT mode after sending a SYN-ACK confirming RFC-3168 support in response to a valid RFC-3168 SYN?


 - Jonathan Morton


--0000000000000441b50598040be6--


From nobody Sat Nov 23 12:16:24 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 6304C120089 for ; Sat, 23 Nov 2019 12:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 B087xLv0p9P9 for ; Sat, 23 Nov 2019 12:16:21 -0800 (PST)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 48EE4120024 for ; Sat, 23 Nov 2019 12:16:21 -0800 (PST)
Received: by mail-oi1-x22f.google.com with SMTP id v138so9651531oif.6 for ; Sat, 23 Nov 2019 12:16:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qi8Lic0k9Y9YGVJxqcsRjJ82bH0mLnYaqwbVa/S3FWg=; b=VHZagoUMEJt9axdMHS7US6eNAXlqNsoEMmMdAgEZk8Cxs5ueWwwdkrSrq/uPHdF2zn f8BZpqQq8hhgHRosYngqfMbVrhpTgpfpP0ULsn13vT5CB+VrmAwmjyEmek9vcdgUhzFS 230vyMxtoGGJnsSaGUTHvauLeIL+4kj0t6MtAH5uGkgu/pCeywmWI68LEFiSwbo6UOoC P4vN+vF+kussYqjZ0lRqsqhWuIpFs7C4rjKNkAGWnTyi1Wfh9dsPxi49YX6GNtMbv0fe WcT7hpvyFK5vqd6VMH7+gBAEmd+oDTYmGWdQE28ZD3/JmSqPEn2pXWAGJk5cVaI86aFD tuBA==
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; bh=Qi8Lic0k9Y9YGVJxqcsRjJ82bH0mLnYaqwbVa/S3FWg=; b=bLjhLCVKcb+yqv5aHKp9UFVIin4Qz1g+fxKdJlW3qo4s5WMj5wxA1EMFBja5kpze4u npMg/bZ4HBSSHq3gX13OHUTMxMGUFe9GikdLTI+4h+NQGsi0H1Jmxof9S12gGtN+maNF D0BmZKNpr6TgCTrK/qFNe5d9i30JtT96PcrNqJ3rttTu2Fqt7nL8axkOH88Doz3v/nhD sqc+EDI+vaZCDc4/zuF/gkg0JDUzOjAGAwPbtM8gEQ32/mVXLV/waWu/9ZtXCuD6CuLA lsv7RCku67KXzmIZSiUrzG18wbQ2abjp3TEV0BwWrah5ibEQI2bwTFa/oyND0k3rciqu sZLA==
X-Gm-Message-State: APjAAAWvJvMdvsauTng5Uz2j9huivh0Y7ieUODzNTnibIDIe9Av/B3V3 lSuQO/7xR8AFoReaVIfi8kPzqxDrS3dQyGkIe2M0KWs4OMs=
X-Google-Smtp-Source: APXvYqx4bFXh6qbIAcaL1lcpb1AVkHYjaJG8egEmhGsCdDfqAcK5HbPNgnajyfWkOVvV7fK0cUKFzyz5Gp+PJ1HovyA=
X-Received: by 2002:a54:4407:: with SMTP id k7mr17819824oiw.129.1574540179893;  Sat, 23 Nov 2019 12:16:19 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Neal Cardwell 
Date: Sat, 23 Nov 2019 15:16:03 -0500
Message-ID: 
To: Bob Briscoe 
Cc: tcpm IETF list , Mirja Kuehlewind ,  Richard Scheffenegger 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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: Sat, 23 Nov 2019 20:16:23 -0000

On Sat, Nov 23, 2019 at 6:28 AM Bob Briscoe  wrote:
>
> tcpm-ers, Mirja, Richard,
>
> draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled
> server MUST support both classic ECN and non ECN. However, that's not
> actually necessary for interoperability. Certainly, when an AccECN
> server receives a non-ECN-setup SYN, it MUST fall back to a
> non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone
> object if we change it from MUST to SHOULD respond with an ECN-setup
> SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?

I think removing that MUST and replacing with SHOULD or MAY is an
important change. Many servers are situated in datacenter networks
where the datacenter switches are CE-marking using shallow-threshold
DCTCP-style ECN. I don't see a way for such servers to feasibly
participate in classic/RFC-3168 ECN, because to do so would risk
interpreting shallow-threshold DCTCP-style CE marks as deep-threshold
classic/RFC-3168 CE marks, causing overreaction to the CE marks and
thus poor performance.

For servers in such networks it seems important to preserve the option
to participate only in non-ECN, DCTCP-ECN, and L4S-ECN conversations,
and decline classic/RFC-3168 ECN conversations.

best,
neal


From nobody Sat Nov 23 21:21: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 20478120077 for ; Sat, 23 Nov 2019 21:21:03 -0800 (PST)
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 0wxZ1vCb4OUz for ; Sat, 23 Nov 2019 21:21:00 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 73AD1120046 for ; Sat, 23 Nov 2019 21:21:00 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id l14so8429867lfh.10 for ; Sat, 23 Nov 2019 21:21:00 -0800 (PST)
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=E7Sa2ixFHngg0ah0bkUEbXfcvWf9IExhb5FCKATdjhA=; b=WULIIs9QTFIvLHVhRPKLh9e1FW+iLhTgKyOcy+VS/EsNaVnV9Jeca6PhFw5dz8tRug DP/ANR1dTolR+AMcGQWiA6HlMFvqRwahvD3pDZ/XXCrE1fe/X0XBwv4zH+bUahHXIFUx VeU9bdNzXAcwjdiv6g684F8PCrWbBTS2ARH2p8gFYpfB9ywWc09rMW/YF3i1jjhUrTED x85MrnKYJwkUH0lDmtKfGDOm7jxXXmdtHW3ARjPm9Kr2giNHkk/+1OOXNrIJqO36ajVF b8c7t/NWwWzTIcKdoesbWDbhTTiU4OsMyrFgNdqJlzlVZVXxBA/ucrEABpDq+1qlbCvG Vriw==
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=E7Sa2ixFHngg0ah0bkUEbXfcvWf9IExhb5FCKATdjhA=; b=q/lFjpmPukanA54320AeZQ+9TISiy+nO5rXlY/pTbspSKLUXgRSuvs/9wJX2lPQSYV v/OZmbpnBcIEbP7K/jfSkAjg4RaVkT0ImqvrzaRu8eay9DZWC1Wz6OVgZqq+sobYLczI 3uumhC88gJQgpa1h3+yLd3Z0ng07JbwxzM3BaTiYitXYSRL14Tlag/v8narRGqNslnSB a/CpSf36tcs5XEk7L4BR4jvCSzHSSf0dU+xQN3W53KqiuXkkSexSQ0+8eL84UAx6T2Kz Jyzdf8od1nv11XU0FXGsobJRl69ba5D07WL/WFrr7iEexlxkf2nGccGEEHRW6qRliBF5 kigA==
X-Gm-Message-State: APjAAAWLfWiZGOoFg1opsN4y4tTcoAoT2i/eWJCobWpM2/WfjpOHzw4Z ob4I5/GIxIzk9S1SUY0z4t8=
X-Google-Smtp-Source: APXvYqwkeOoXXhj3PLG2bRFwe2MQdHb5R++pF80duJeHkwONpx6GNegURlBaVydobvXwV+VMHe8cuw==
X-Received: by 2002:a05:6512:21a:: with SMTP id a26mr16671793lfo.145.1574572858592;  Sat, 23 Nov 2019 21:20:58 -0800 (PST)
Received: from [192.168.44.148] (176-93-181-88.bb.dnainternet.fi. [176.93.181.88]) by smtp.gmail.com with ESMTPSA id t8sm1074420lji.37.2019.11.23.21.20.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Nov 2019 21:20:57 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: 
Date: Sun, 24 Nov 2019 07:20:15 +0200
Cc: Mirja Kuehlewind , tcpm IETF list , Bob Briscoe 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
References:   
To: Richard Scheffenegger 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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: Sun, 24 Nov 2019 05:21:03 -0000

> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger  =
wrote:
>=20
> My reading of bob=E2=80=99s suggestion is
>=20
> Syn - accecn
> Syn-ack no ect
>=20
> I don=E2=80=99t see any problem there ;

That is indeed a valid transaction, but one which represents an AccECN =
client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it =
is also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE =
without AE on SYN) with a Not-ECT server.

What the draft currently (and correctly, IMO) forbids is for an AccECN =
server to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason =
for allowing this, because the difference in code complexity must be =
very small, and the benefit to the RFC-3168 supporting clients which are =
ubiquitous today (even if they don't always advertise it) in terms of =
avoiding packet loss and retransmissions just for the sake of a =
congestion signal is significant.

It does appear that I missed part of Bob's proposal through trying to =
read it on a phone at the airport.  It made me think that he was =
proposing that AccECN *clients* might not support RFC-3168 as well.  I =
now see that he was proposing this only for servers.  I still think this =
is wrong-headed, but it technically doesn't break the protocol on the =
wire.

I should point out here that datacentres are a special case - a =
contained environment in which it is permissible to bend certain rules =
for the sake of performance, in ways that would not be acceptable for =
Internet traffic.  I think this is one of these cases, like DCTCP =
itself.

 - Jonathan Morton=


From nobody Sun Nov 24 06:53:51 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 B5E4B12013C for ; Sun, 24 Nov 2019 06:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 gUF9HR1cbW12 for ; Sun, 24 Nov 2019 06:53:48 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117EE1200C5 for ; Sun, 24 Nov 2019 06:53:48 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id CB8842C405E; Sun, 24 Nov 2019 06:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xpwUUlTxDNJp; Sun, 24 Nov 2019 06:53:47 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7173C2C4051; Sun, 24 Nov 2019 06:53:47 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 03F231E9DF8A; Sun, 24 Nov 2019 09:53:47 -0500 (EST)
From: "Mark Allman" 
To: "G Fairhurst" 
Cc: "tcpm IETF list" 
Date: Sun, 24 Nov 2019 09:53:46 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <179D2194-9C6A-4E13-ADA9-BBBBB23B36C6@icir.org>
In-Reply-To: <5DD88BE2.8090604@erg.abdn.ac.uk>
References:  <5DD88BE2.8090604@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] rto-consider: "regularly" taking RTT samples
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: Sun, 24 Nov 2019 14:53:50 -0000

> Omitting the word (a) is indeed easy. I suspect the new
> formulation of (b) effectively defines regularly, so a recent
> sample should be available.

I removed the word from my version.

>> Gorry>  FT observations SHOULD be taken be at least once
>> Gorry>  per RTT or as frequently as data is exchanged in cases where
>> Gorry>  that happens less frequently than once per RTT.
>>
>> This is in fact the intent and I am happy to use those words.
>>
> Then let's do that.

I tweaked the words ever-so-slightly to be even more specific:

        (b) FT observations SHOULD be taken and incorporated into the
            RTO at least once per RTT or as frequently as data is
            exchanged in cases where that happens less frequently than
            once per RTT.

The supporting (non-normative) text that followed is still there.

Seem OK?

allman


From nobody Mon Nov 25 01:02:32 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 558C912083A for ; Mon, 25 Nov 2019 01:02:31 -0800 (PST)
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 Oci8ZI148UQv for ; Mon, 25 Nov 2019 01:02:29 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id A656B120288 for ; Mon, 25 Nov 2019 01:02:29 -0800 (PST)
Received: from [10.13.33.86] (unknown [185.69.145.34]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 493A01B00257; Mon, 25 Nov 2019 09:02:25 +0000 (GMT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: "Gorry (erg)" 
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Nov 2019 09:02:24 +0000
Message-Id: <3DC9C3C7-7889-4E04-9CF1-41879B3DCEA1@erg.abdn.ac.uk>
References: <179D2194-9C6A-4E13-ADA9-BBBBB23B36C6@icir.org>
Cc: tcpm IETF list 
In-Reply-To: <179D2194-9C6A-4E13-ADA9-BBBBB23B36C6@icir.org>
To: Mark Allman 
X-Mailer: iPhone Mail (17A860)
Archived-At: 
Subject: Re: [tcpm] rto-consider: "regularly" taking RTT samples
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, 25 Nov 2019 09:02:31 -0000

Yes works for me.

Gorry

> On 24 Nov 2019, at 14:53, Mark Allman  wrote:
>=20
> =EF=BB=BF
>> Omitting the word (a) is indeed easy. I suspect the new
>> formulation of (b) effectively defines regularly, so a recent
>> sample should be available.
>=20
> I removed the word from my version.
>=20
>>> Gorry>  FT observations SHOULD be taken be at least once
>>> Gorry>  per RTT or as frequently as data is exchanged in cases where
>>> Gorry>  that happens less frequently than once per RTT.
>>>=20
>>> This is in fact the intent and I am happy to use those words.
>>>=20
>> Then let's do that.
>=20
> I tweaked the words ever-so-slightly to be even more specific:
>=20
>        (b) FT observations SHOULD be taken and incorporated into the
>            RTO at least once per RTT or as frequently as data is
>            exchanged in cases where that happens less frequently than
>            once per RTT.
>=20
> The supporting (non-normative) text that followed is still there.
>=20
> Seem OK?
>=20
> allman


From nobody Mon Nov 25 04:56:00 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 9B1B812013A for ; Mon, 25 Nov 2019 04:55:58 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 2A_aQg5_97zg for ; Mon, 25 Nov 2019 04:55:55 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 B2B4912009C for ; Mon, 25 Nov 2019 04:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iou7+nmiveZ5FVGTWYnQcVw/ip7XYMXqbznVIOmC11I=; b=1upBZnSnhZRBk3ZfcRWnn8W+bi 0WETHNlDBg8VczSOkpEP3kJkTP8qzFWF/NyFfh7RqoKx0JeJRMOpt3i94l/SHtU3SF7WtHHvDtoLS iHQfuo0HXOlqxnlyNOf4pbtqtywwNJSnO+Fnn82tuYtHBYNZ+apDF+NMvnGlly+a43hravhsPtJtq VyTBVZvMC1p/uyU3aMSQRq9WvxNQvO6ftnqSmHZVOjAhneWztfyFHbdefCScfiLxSNfz3OpRtDcHw I+R5UH60zPexg7Ws88aZxUwlwKmN6XBnrXR42FsVc7tsSsDJKdFWvNKGTZR8UEtuntuGFu8rAoKnH 1oftnCHw==;
Received: from [31.185.128.31] (port=47204 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iZDuC-00024Q-AP; Mon, 25 Nov 2019 12:55:52 +0000
To: tcpm IETF list 
From: Bob Briscoe 
Message-ID: <28cdf725-546f-6d0f-516e-1c8f19a00749@bobbriscoe.net>
Date: Mon, 25 Nov 2019 12:55:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------CC9C83B569F8CFCB643623C6"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tcpm] History of ECN's use of TCP header bits vs. TCP option
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, 25 Nov 2019 12:55:58 -0000

This is a multi-part message in MIME format.
--------------CC9C83B569F8CFCB643623C6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

tcpm-ers,

In Appendix B.1 of the AccECN draft 
 
it says:

    It is not recorded why ECN originally used this [header flags]
    approach instead of the more orthodox use of a TCP option.

Having dug into the history, I propose we change this to:

ECN originally used header flags rather than a TCP option because it was 
considered more efficient to use a header flag for 1 bit of feedback per 
ACK, and this bit could be overloaded to indicate support for ECN during 
the handshake. During the development of ECN, 1 bit crept up to 2, in 
order to deliver the feedback reliably and to work round some broken 
hosts that reflected the reserved flags during the handshake.

==History==
While checking through RFC3168, in the acknowledgements I noticed it 
says "we would like to thank Kenjiro Cho for the proposal for the TCP 
mechanism for negotiating ECN-Capability," so I asked Kenjiro what the 
history was. Here's the outcome, following some further digging via the 
archival section  of Sally 
Floyd's ECN page.

==Exec summary==
A TCP header flag was uncontroversial for 1-bit TCP feedback of 
Congestion Experienced at the IP layer, but a TCP option was not ruled 
out. Initially, the authors imaged a TCP option to negotiate the ECN 
capability. But when Kenjiro implemented it, he suggested overloading 
the feedback flag for each peer to communicate their ECN-capability 
during the TCP handshake as well. This made the whole thing simpler 
without having to assign any additional options or bits so it was 
quickly adopted. 1 bit crept up to 2 when reliable delivery of feedback 
needed to be solved. Then the second bit was overloaded during the 
handshake as well, to work round a bug in certain TCP implementations 
that reflected unrecognized header bits.

==More detail==
In the -00 ECN draft  
(Nov'97), the authors proposed a TCP header flag called ECN-Notify for 1 
bit of ECN feedback per ACK.

On 19-Nov-1997, in this email to Curtis Villamizar about the ECN I-D 
, Sally and K. K. 
Ramakrishnan explained that they had not ruled our the alternative of a 
TCP Option:

(The main decision to be made
is whether to allocate an ECN-Notify bit in the TCP header (as recommended
in our draft) instead of using an ECN option to carry the ECN notification
from the receiver to the sender.  Not too earth-shattering...)


At the time, the authors were imagining a host would declare that it was 
ECN-capable, either using the ECN-capable bit at the IP layer, or using 
a TCP option. On 23-Jan-1998, Kenjiro explained to Sally how his 
experimental implementation overloaded the ECN-Notify flag at the TCP 
layer for initialization as well as feedback. The authors quickly 
adopted this, because it made the whole thing simpler without having to 
assign any additional options or bits. And the two functions of the bit 
didn't conflict, because it was realized that there wasn't a need to 
echo ECN on the SYN-ACK because, while the client didn't know whether 
the server was ECN-capable, it was safer not to make the SYN ECN-capable.

On 29 Jan-1998, a few days after Kenjiro had suggested this, Sally 
posted this txt file recording that decision 
. By then, Sally had also 
introduced stickiness of the ECE flag (acknowledging Kevin Fall for the 
idea) and added a new CWR flag to acknowledge it. This was how ECN stood 
in Jul'98 when draft-kksjf-ecn-01 was published.

Then, by the -02 version of the ECN draft in Sep'98, the broken hosts 
that reflect the TCP flags had been discovered, and, building further 
onto Kenjiro's solution, both the ECE and the CWR flags were used on SYN 
and SYN-ACK to indicate ECN-capability, but in different combinations to 
distinguish the SYN-ACK from a broken reflection of the SYN.



Bob



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------CC9C83B569F8CFCB643623C6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    tcpm-ers,

    

    In Appendix
      B.1 of the AccECN draft it says:

    
   It is not recorded why ECN originally used this [header flags]
   approach instead of the more orthodox use of a TCP option.


    Having dug into the history, I propose we change this to:

    

    ECN originally used header flags rather than a TCP option
      because it was considered more efficient to use a header flag for
      1 bit of feedback per ACK, and this bit could be overloaded to
      indicate support for ECN during the handshake. During the
      development of ECN, 1 bit crept up to 2, in order to deliver the
      feedback reliably and to work round some broken hosts that
      reflected the reserved flags during the handshake.

    

    ==History==

    While checking through RFC3168, in the acknowledgements I noticed it
    says "we would like to thank Kenjiro Cho for the proposal for the
    TCP mechanism for negotiating ECN-Capability," so I asked Kenjiro
    what the history was. Here's the outcome, following some further
    digging via the archival
      section of Sally Floyd's ECN page.

    

    ==Exec summary==

    A TCP header flag was uncontroversial for 1-bit TCP feedback of
    Congestion Experienced at the IP layer, but a TCP option was not
    ruled out. Initially, the authors imaged a TCP option to negotiate
    the ECN capability. But when Kenjiro implemented it, he suggested
    overloading the feedback flag for each peer to communicate their
    ECN-capability during the TCP handshake as well. This made the whole
    thing simpler without having to assign any additional options or
    bits so it was quickly adopted. 1 bit crept up to 2 when reliable
    delivery of feedback needed to be solved. Then the second bit was
    overloaded during the handshake as well, to work round a bug in
    certain TCP implementations that reflected unrecognized header bits.

    

    ==More detail==

    In the -00 ECN
      draft (Nov'97), the authors proposed a TCP header flag called
    ECN-Notify for 1 bit of ECN feedback per ACK. 

    

    On 19-Nov-1997, in this email
      to Curtis Villamizar about the ECN I-D, Sally and K. K.
    Ramakrishnan explained that they had not ruled our the alternative
    of a TCP Option:

    
(The main decision to be made
is whether to allocate an ECN-Notify bit in the TCP header (as recommended
in our draft) instead of using an ECN option to carry the ECN notification
from the receiver to the sender.  Not too earth-shattering...)

    

    At the time, the authors were imagining a host would declare that it
    was ECN-capable, either using the ECN-capable bit at the IP layer,
    or using a TCP option. On 23-Jan-1998, Kenjiro explained to Sally
    how his experimental implementation overloaded the ECN-Notify flag
    at the TCP layer for initialization as well as feedback. The authors
    quickly adopted this, because it made the whole thing simpler
    without having to assign any additional options or bits. And the two
    functions of the bit didn't conflict, because it was realized that
    there wasn't a need to echo ECN on the SYN-ACK because, while the
    client didn't know whether the server was ECN-capable, it was safer
    not to make the SYN ECN-capable.
    

    

    On 29 Jan-1998, a few days after Kenjiro had suggested this, Sally
    posted this txt file recording
      that decision. By then, Sally had also introduced stickiness
    of the ECE flag (acknowledging Kevin Fall for the idea) and added a
    new CWR flag to acknowledge it. This was how ECN stood in Jul'98
    when draft-kksjf-ecn-01 was published.
    

    

    Then, by the -02 version of the ECN draft in Sep'98, the broken
    hosts that reflect the TCP flags had been discovered, and, building
    further onto Kenjiro's solution, both the ECE and the CWR flags were
    used on SYN and SYN-ACK to indicate ECN-capability, but in different
    combinations to distinguish the SYN-ACK from a broken reflection of
    the SYN.
    

    

    

    

    Bob

    

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------CC9C83B569F8CFCB643623C6--


From nobody Mon Nov 25 06:57: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 930AB120977 for ; Mon, 25 Nov 2019 06:57:10 -0800 (PST)
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 cubmKw7bruPG for ; Mon, 25 Nov 2019 06:57:09 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 22798120976 for ; Mon, 25 Nov 2019 06:57:09 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id q2so16247878ljg.7 for ; Mon, 25 Nov 2019 06:57:08 -0800 (PST)
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=YN6bKzu3vCoH7aTVbZzxAiR1OqfCtd2vXS43WhzcSOU=; b=gI13qmmrHhNzzso1Wn84gWirPULC7+xBugmGQI+gHkS+A2Trbe5LMU1tNHm7S/yfmL 0pVqktxoj/kAZ8hia8xhj5ftWoUATCmVE9+OxsJEugonazWrpA5Ax8HA1Ewp95CgVXIy zOqZiObWGUO1b9n8ccCVliC00+hbqi/bNG6xhz+rwZioNz9mbaxPxpGn32U2Zkobcm8G 5hEzsXKcAtAs721gsCD17zM4e4/d8x9YHemygdAdQzV6/KKVoD8tkTnYYWpJqJ6FG9e2 /gb833Ry/V3tGiwA4zaW5efoDnwJPdyyWXtzwhyvdaCi2GhT0i5N5sxs+K5cb/7LqGq0 3wWw==
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=YN6bKzu3vCoH7aTVbZzxAiR1OqfCtd2vXS43WhzcSOU=; b=P6UrGEIIjQSG79D9ij5gi9xgPoTZY7o/J8z/7vxU4wkRvTyPTLGSO0QyNfLGbk7era hRFXeQAb1REkj3pvHXA/pgb8b+KLQc72NiZmMFC/zZJ/K4BuLBALiReJnUpn5QvxUUdi 0/ksv8rIn0LFZ39JAcbIekI1ZgJVCfF1wboAsrB+E6laMGEQAInE7JAoVQlLQJOj4w3I 07B/pjEWwrGtYMTUFQadHtXoD+fHBujI17n59ozasFr3+pbimKkbllUyi55WnmhMGc2O 1HWAvkNMsoOPO48DUb1/LkVDmMubv/sbuG5F2ujYBub37qc3U3YU6DGNF0YmxI8174Nc cZkg==
X-Gm-Message-State: APjAAAUgS9Gl8KPLt20JII9dj6GtvUFkOCK4Pi/58ejhnfMf+g3zoNHh RaQxnxF/cGJU+YfllLq6l5JWvQds
X-Google-Smtp-Source: APXvYqzdwm9y6/Mn4bnKV6fq79B/Yl5WPhUxUlY2M/MkrvseJXxE1DSLROzAXGq7177RDCNs28dFKQ==
X-Received: by 2002:a2e:574d:: with SMTP id r13mr22495605ljd.10.1574693827134;  Mon, 25 Nov 2019 06:57:07 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id s20sm3762824lfb.6.2019.11.25.06.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 06:57:06 -0800 (PST)
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: <28cdf725-546f-6d0f-516e-1c8f19a00749@bobbriscoe.net>
Date: Mon, 25 Nov 2019 16:57:04 +0200
Cc: tcpm IETF list 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F389E20-C5A7-441D-89CE-5F32A3629151@gmail.com>
References: <28cdf725-546f-6d0f-516e-1c8f19a00749@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] History of ECN's use of TCP header bits vs. TCP option
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, 25 Nov 2019 14:57:10 -0000

> On 25 Nov, 2019, at 2:55 pm, Bob Briscoe  wrote:
>=20
> In Appendix B.1 of the AccECN draft it says:
>    It is not recorded why ECN originally used this [header flags]
>    approach instead of the more orthodox use of a TCP option.
>=20
> Having dug into the history, I propose we change this to:
>=20
> ECN originally used header flags rather than a TCP option because it =
was considered more efficient to use a header flag for 1 bit of feedback =
per ACK, and this bit could be overloaded to indicate support for ECN =
during the handshake. During the development of ECN, 1 bit crept up to =
2, in order to deliver the feedback reliably and to work round some =
broken hosts that reflected the reserved flags during the handshake.

This seems like a reasonable improvement to me.

 - Jonathan Morton=


From rscheff@gmx.at  Sun Nov 24 10:56:02 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 BEE15120041 for ; Sun, 24 Nov 2019 10:56:02 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 tsi2UAGMzc0J for ; Sun, 24 Nov 2019 10:56:00 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 DA50B120033 for ; Sun, 24 Nov 2019 10:55:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574621711; bh=rFA4f7fk5ExPRpPicOOsbdHDu5xvZ/wIfH7lub0D6mQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=BNxWXBQY+9tNvZU+6ez4mPzpWmxnUTIkO2Jnw8dZAOIJE3bdRvDDlbRrqfuaYKzUV qSuMFpAQYW+aiIx7Z98pTvBf2zc6jsOnvTo0WborlIR/FwClkK5MiDuVDqH20Ic9bU w4A+SeNgEPvxNBbGsCpu4lfzTBxwK3p1a9ZRhPWQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [213.162.73.157] ([213.162.73.157]) by msvc-mesg-gmx122.server.lan (via HTTP); Sun, 24 Nov 2019 19:55:11 +0100
MIME-Version: 1.0
Message-ID: 
From: "Richard Scheffenegger" 
To: "Jonathan Morton" 
Cc: "Mirja Kuehlewind" , "Bob Briscoe" , "tcpm IETF list" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Date: Sun, 24 Nov 2019 19:55:11 +0100
In-Reply-To: <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
References:    <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
X-Provags-ID: V03:K1:abIEScxoJTFYzEoGOGd/EmwyhxQB4cYE2yTFwqdR1/lBRWd9ShmIEEKKw5lVS1vGfYPbe f37nqVPqwjJaZldUAy9EUGZJVNW/Zg6fqebegaT9h31PB/ySsdMw9NkTN78uZAaWXhTDxrwXz8+D czF/OXyQNZc4p2VGnvHgDwfjoQ+YBZ+HfAImBHfFRWAYkB7ymzz3tDC7MEoqKCP97e0xKRFnrfHx e684FyZZaH4zlMkYqPHyzbtrAtICOalqmcswHqMylpl7ladfpg3+zGm0/pkrNzT0ePS9g/ONV6Gh 5s=
X-UI-Out-Filterresults: notjunk:1;V03:K0:2o+sTQwNyZ0=:U3agqH9IR0Kf9OWiAhS0+F qRhN5oWQ7g4iA+3yZynl91smqzwGgbgWM0OmoMZ1+zdzUj9kj4csKvdWkqeD5JAuMJtVlvgmY Wi7jY7iUzzGhruAUBXdj8SoIKV7y4mvrCFxnkRLYmTeZgpOluwsG9kIATv1GoskA/sv9jUK+Q jiz84JTQsT6BCQAWYxm51EnAo3X7SYgFQpqfyFST2C037AngsH6PxLitvf2NdprIWOLiu0x+6 fYhOnYvjvKmtrhSPO/QTMVNkWICy5U13DWFx0v1kGVByoFgMKGg9YR2YCXLpC+fpyBqt2ho0y SyBbNkunZWq0RwhBBdOorYVp9/a3p72Qkqniv88LBXFzaSTPjb7NGJ3gLdcx2hKpDkYZlvVDz xc02/FjwfstFrDHC2YqC8tCbmct2j+xq9F4iavdbwrgkvnZHX/LhOt5VX8tBqSoOkt2LMsivU pG5XJuK3BsKzze4PxnKpY5nnCTZ6DP4CSGFPULJkso6bCt+PNjMD57nVSKJ9IX/f5WcRSXIF0 /P1mwUXN8e8/bfTDUOeeehgGVF+mR0ygfCE8+cWyHWI8Pf2H85+q1rs8RLP7epq2hcMc0F7G6 ShQTkKzJw3GYtFuQ+/aWdFvaPL9HcEW7UK0Gn3jdYyvQ7wBqa9CP0pODShZk3SIglrSEp6chx zkOcVRgQQCAzA+bSy2A2BxXlp1gq3WqBGCh/augoSf+QiwImw5j1+hYNDu/jBBFVcRAfdTql9 Ry2le73CV1jn6uqNJ7JiJHl8WBDOWlq1UABE7WohW/6rC2OIeWTcX6Hl6no=
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 14:59:32 -0000

Yes i think a tcp server in a DC accepting only accecn (possibly w/ option =
to switch to dctcp style reflection), and no-ect does make sense=2E

There is gear deployed already, which ONLY supports shallow ce marking - w=
hich breaks 3168 entirely=2E Behind such a switch, a server would be better=
 off going only with non-ect (no ecn at all), or accecn=2E So that state tr=
ansition should be allowed (and i think it is) by the accecn draft=2E

(Non-ect is classified into a different Q on the one example i could name,=
 so no q sharing w/ drop class cc)

Gesendet mit der GMX Mail App

Am 24=2E11=2E19 um 06:20 schrieb Jonathan Morton

> > On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger  =
wrote:
> >=20
> > My reading of bob=E2=80=99s suggestion is
> >=20
> > Syn - accecn
> > Syn-ack no ect
> >=20
> > I don=E2=80=99t see any problem there ;
>=20
> That is indeed a valid transaction, but one which represents an AccECN c=
lient (that is, AE|CWR|ECE on SYN) and a Not-ECT server=2E  Of course, it i=
s also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE without =
AE on SYN) with a Not-ECT server=2E
>=20
> What the draft currently (and correctly, IMO) forbids is for an AccECN s=
erver to downgrade RFC-3168 clients to Not-ECT=2E  I don't see any reason f=
or allowing this, because the difference in code complexity must be very sm=
all, and the benefit to the RFC-3168 supporting clients which are ubiquitou=
s today (even if they don't always advertise it) in terms of avoiding packe=
t loss and retransmissions just for the sake of a congestion signal is sign=
ificant=2E
>=20
> It does appear that I missed part of Bob's proposal through trying to re=
ad it on a phone at the airport=2E  It made me think that he was proposing =
that AccECN *clients* might not support RFC-3168 as well=2E  I now see that=
 he was proposing this only for servers=2E  I still think this is wrong-hea=
ded, but it technically doesn't break the protocol on the wire=2E
>=20
> I should point out here that datacentres are a special case - a containe=
d environment in which it is permissible to bend certain rules for the sake=
 of performance, in ways that would not be acceptable for Internet traffic=
=2E  I think this is one of these cases, like DCTCP itself=2E
>=20
>  - Jonathan Morton


From rscheff@gmx.at  Sat Nov 23 06:49:34 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 A2C4712022A for ; Sat, 23 Nov 2019 06:49:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 NUCWcAhf7F2r for ; Sat, 23 Nov 2019 06:49:32 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D01C2120147 for ; Sat, 23 Nov 2019 06:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574520568; bh=CkqzBBYiJBs+GyB9smI2zruq6HAZEMqki+9h4RITgbk=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=SQim766IhWW7R7NWVSCYjWirf/i1vALx1HeI9+7/asyOTWaVUgtLUcI2u0qPrrSq1 LPeUIApqDXrQkd8B+BcNZ3m4t31ya6Kvs3SDyMkxcQeEdllHwdKapekrfAhWNttzBJ d9PcPpqwjo4XQnWn1uAIRPX2vlfVvxleRe0px76c=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [113.53.15.53] ([113.53.15.53]) by msvc-mesg-gmx023.server.lan (via HTTP); Sat, 23 Nov 2019 15:43:18 +0100
MIME-Version: 1.0
Message-ID: 
From: "Richard Scheffenegger" 
To: "Jonathan Morton" 
Cc: "Mirja Kuehlewind" , "tcpm IETF list" , "Bob Briscoe" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Date: Sat, 23 Nov 2019 15:43:18 +0100
In-Reply-To: 
References:  
X-Provags-ID: V03:K1:SnX4aO1WYn1wy1qcwU2lONUxd2lMS5Ko/vnGfTPi6C2F62VMaMTRTOBQHb7pRy9ljcqlA GiPWAM+66LdKljZtJMdiE8tSMnXuoUzkkV7IVwtIn5jwnTbhRDF1LRs6RAvSIiutypDarLFGnjZI 6o0EP7mZQt4PZIwCsAHsq8UJbL/OaW0JVTfIvoNFU9uuctNtRydt9mzQO33Ho/M+HjPfi1W5zwF5 AaMhWzGolfw9byWGCZ1xsB168sOfp6qnFi+WGmk3c+q2yx88ImcRyEmrhyw70DczKRKjLh+HnuTR ds=
X-UI-Out-Filterresults: notjunk:1;V03:K0:A1X1i6ZKetk=:qPiyBBMiTNKxZ7z3yCScjn tzi4hwR5QngsW40Oe5XRuWbpnzpQYgyVRixnYrcc21skkSUO1t7/8oB52/Qycvjf9v/wqPZmV wNfSCkzWcJoM+u6Wo1qFkwzJGySg72qclf/3WdJjD233oBY808uXaZ5XzaUEkHhwmyOSVxPMN miLr2YvuNSyWVrPyfuVuSim1T2JQIXWiJCEKaf+1pCCULqCfn2QJ31eFJ5wpBoL7ynVeIo9e1 +mAgggPhSSbtYvPanXwLDu5PNpg4nIK2fGKgXNT3xPoJg7aqcLvLRWinRfRdKPiRS24LdK2T8 S/U6xmfv0witoyvgljh6fEMg8UyB4v938uv40akqzQ6fPgCU3BCOwSFJvTMkHl8A39Hse/o49 tYB0913mgPL0TMYCMjZFJcMqniYqQQgemxjrRXJGFbKPIYkvrwX6g7v+nJQwfXkIDsxlN/3VG cp8mT1YBvzDMG+gb7IXcgiepDLrhrKTudGJ9rLghMrXH/4uL29BH7KAeiWOER+up06NR1AKvv 7f7XVvZy8YSiT34k8APAmYxk3C+1H9Z/wq+wvYg3dfxjSpdIc7NgUflZgW6FpmN6XwL4PBCL0 QY3+rq/7QjKx6XLnWFTxrvx80yMsLDO1U21dDhLWbizUSsEM91iFgw0nylrRsl6uGVI7EMAti SEpX5KbnSjp/+OZWQN6SdSir586HQz7ZtfnE5MeO9cm+5gQl4t+Fs656C3D5sJGC2mSC2bhMn q+4uK6UM/ukg8RFwB6mZ0pU1jokPFnJXS2zpZZmmmU8cTz/ovDvIR9zsrIs=
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 14:59:34 -0000

My reading of bob=E2=80=99s suggestion is

Syn - accecn
Syn-ack no ect

I don=E2=80=99t see any problem there ;

The handshake is only complete (and the server continues to use ip ect in =
the final ack), if the client responded by either non-ect synack(ae/esce =
=3D0, cwr=3D0, ece =3D0), a rfc3168=20
Synack(ae/esce=3D0, cwr=3D1, ece=3D0), or one of the four synack accecn co=
depoints;

The only violation would be a server trying an ecn++ / accecn handshake wi=
th a ect0/ect1 marked syn=2E=2E=2E

Am i missing something?

Richard
Gesendet mit der GMX Mail App

Am 23=2E11=2E19 um 15:06 schrieb Jonathan Morton

> I believe that taking advantage of such a provision would result in a
> violation of RFC-3168, as seen by a server supporting that specification
> but not AccECN=2E
>=20
> If I happen to be wrong about that, could you explain how the server get=
s
> to know that the connection has reverted to Not-ECT mode after sending a
> SYN-ACK confirming RFC-3168 support in response to a valid RFC-3168 SYN?
>=20
> - Jonathan Morton


From nobody Mon Nov 25 07:21:47 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 28326120105 for ; Mon, 25 Nov 2019 07:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 P9qRmsvqng-M for ; Mon, 25 Nov 2019 07:21:45 -0800 (PST)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 016981200B3 for ; Mon, 25 Nov 2019 07:21:45 -0800 (PST)
Received: by mail-oi1-x22b.google.com with SMTP id s71so13374885oih.11 for ; Mon, 25 Nov 2019 07:21:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PKQF+n5e4nF4/0ZCYcSCYeMj6Bk1EJchtyvU4klILJs=; b=Mge4I1DuV/bIE0AI7bTjdrinG1tijbA2zNr4n7lccsqqfiu0LLa5luAtdc9mS6Rr/2 5RntcL+479+47V6iHZDrcovBFNYc9RPcKebS7Lr9jqlA8XI4787xr46HShn6TAIBzyhL 9MxWeo1Sj3RE3nz0xxJGFFleUxN29foCDn0CidDVT9VOw3HmtzoR7hcb3Zzk6z/A5krl EzuSqq7Wz0Ya/RV0ztNxzV+rmzuNf1Fn6174RW6tFpDnYILO3aTQR3ZNr3VSoxrCZbck e0EifPka7WQ1PEllbp2ACRavG4tHBp5gH1ugEhJZOYHsCPORMV04qV2p0ilIt8+vbSVi m4QA==
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; bh=PKQF+n5e4nF4/0ZCYcSCYeMj6Bk1EJchtyvU4klILJs=; b=Ax1xNYwlAbjURxE65tMl797TLgeNgwroGplBNweG2C8z/lnsE66FwQwOEBe63iR4sM jMkggfTJr/bQ0lOWu/+3Rd/Nml39nQCKzXkvHnvdsbQUWLY0RQZisi3q/TxDUk8iaav/ 5jlz0RmmS1HShR7UEEG2E9fP7zqnXAXNdubx1W/NE27BcePVBErfiTOn3AP7Cb/M+/XZ D4QzDeZSRT2jqWDIpcWv9hlYVT+BS3EHArHAk8OpJUdKQCnCtFqrgrLJfmgpX1dAFtmM rGAkax2ba/k+5GADMDwyUvICW54+UYQagOFA91/0DDXtmNwBnqDs7PwtfoKD/vA7Z9sH I3fA==
X-Gm-Message-State: APjAAAXpoKNdx+GZi/WF7K0GL4yWuJ5v6xunj+3fFMOHe2zUpf6fszwT OsPBAKmmKdEoIZyhB0LwXZ4MZOpAMCznxU6fXbh6Dg==
X-Google-Smtp-Source: APXvYqxQUFOo5yWIZYwKJS2AkFeOLqaBj3MpN1ItOiynQlDNJXxZX8hNgou3c1vYQnxXS1ohCIl0B/tHuI/1OTjkYqo=
X-Received: by 2002:aca:3889:: with SMTP id f131mr23268346oia.14.1574695303737;  Mon, 25 Nov 2019 07:21:43 -0800 (PST)
MIME-Version: 1.0
References:    <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
In-Reply-To: <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
From: Neal Cardwell 
Date: Mon, 25 Nov 2019 10:21:27 -0500
Message-ID: 
To: Jonathan Morton 
Cc: Richard Scheffenegger , tcpm IETF list ,  Mirja Kuehlewind 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 15:21:46 -0000

On Sun, Nov 24, 2019 at 12:21 AM Jonathan Morton  wrote:
> I should point out here that datacentres are a special case - a contained
> environment in which it is permissible to bend certain rules for the sake
> of performance, in ways that would not be acceptable for Internet traffic.
> I think this is one of these cases, like DCTCP itself.

IMHO it is worth emphasizing that much of the traffic that travels
over the public Internet is sent by servers that are situated in
datacenter networks where the datacenter switches are CE-marking using
shallow-threshold DCTCP-style ECN. So that "datacenter traffic" and
"public Internet traffic" are, in some sense, overlapping categories,
rather than disjoint categories.

neal


From nobody Mon Nov 25 07:46:23 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 AE34412098D for ; Mon, 25 Nov 2019 07:46:20 -0800 (PST)
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 YiPHdgrO9BHw for ; Mon, 25 Nov 2019 07:46:18 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 29E071208B0 for ; Mon, 25 Nov 2019 07:46:18 -0800 (PST)
Received: from 200116b82c892300b4b6b2442066fb94.dip.versatel-1u1.de ([2001:16b8:2c89:2300:b4b6:b244:2066:fb94]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iZGZ5-0007oU-HM; Mon, 25 Nov 2019 16:46:15 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Mon, 25 Nov 2019 16:46:14 +0100
Cc: tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net>
References: 
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1574696778;363303b6;
X-HE-SMSGID: 1iZGZ5-0007oU-HM
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 15:46:21 -0000

Hi all,

Replying to Bob initial message because I have another point.

I need to double-check what the exact context of the sentence Bob =
mentions below is in the accECN draft but probably this should not be a =
normative requirement in this draft at all. I=E2=80=99m actually further =
not sure what exactly is meant with =E2=80=9Csupport=E2=80=9D in that =
sentence, but the question if a server replies to a RFC3168 SYN with an =
RFC3168 SYN-ACK is solely a question for RFC3168 and not AccECN.

Mirja



> On 23. Nov 2019, at 12:27, Bob Briscoe  wrote:
>=20
> tcpm-ers, Mirja, Richard,
>=20
> draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled =
server MUST support both classic ECN and non ECN. However, that's not =
actually necessary for interoperability. Certainly, when an AccECN =
server receives a non-ECN-setup SYN, it MUST fall back to a =
non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone =
object if we change it from MUST to SHOULD respond with an ECN-setup =
SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?
>=20
> Potential reasons for a server only supporting AccECN and non-ECN =
(which we can put in the draft):
> * lightweight server to minimize code complexity;
> * to allow for the possibility that AccECN clients might one day have =
widely replaced classic ECN, and some servers might choose to remove =
their classic ECN code to save having to maintain it.
>=20
>=20
>=20
> FYI, the other way round, no such simplification of the client is =
possible. 'Cos there's no space for an AccECN SYN to say "I support =
AccECN but not ECN". So the client has to be able to support all three =
(AccECN, Classic ECN and non-ECN).
>=20
>=20
>=20
>=20
> Bob
>=20
>=20
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>=20
>=20


From nobody Mon Nov 25 08:35: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 C0FF912099D for ; Mon, 25 Nov 2019 08:35:12 -0800 (PST)
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 KiAat56mwxHo for ; Mon, 25 Nov 2019 08:35:11 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4A77512099A for ; Mon, 25 Nov 2019 08:35:11 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id f16so11561979lfm.3 for ; Mon, 25 Nov 2019 08:35:11 -0800 (PST)
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=pGn5lRbtz3aWRyJM/AID+4hPjN0rSj4HIRJZN96s0nc=; b=ElVbnUV7f/CDCPJmkFpXsbrnbifu+jjDyY9tKFxcdcfr0TxOEnv7cpm9mCnkfgQuEp ibiXnOXFC/LVcY8T4wFklw1ej3gpmIbQ73dzOXdyJ9HmAnOqzxbcYYC0vdp/na63SReI hxLPMzH+02v3+kvx/25r1G6nCmkQwAnccP4sHa7uHxR1tsz8U990H7nQsQf4iwZj5hlw NVIC0uCBFfoAapzP97I9hzd8wOhM2/RpRPDe6tjvhlfGSMEBLicYZvMoxqDpPhkTl+Lw CwIFk/yiFp79LM54Zy0CKSPmdlByWhwKOo7jPKz4W1ruhM8jf13WCqXeAP+fhdn2c3eT hthQ==
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=pGn5lRbtz3aWRyJM/AID+4hPjN0rSj4HIRJZN96s0nc=; b=lxvbDp5OL/2xPkVnM/8GzwWNwcu1xgYb65+tIcX7+WPxrh1ShQuPn/wUMV8Nkklfb8 T4p0m1UTAESyO9DDcb8niGoyXwG9P7YhBpIcaMqpDHkx0el63lYuPKzUbwGSd+X/Rlh1 E1vjkEO5+hhiAU3XWCgags/q5tlyXqebPxxS5gC5I4I1RtJWntEsEBjfpAF3OirDZuum a3lfGdhUGqfZjnPANKlN7O3REeRykoTm/JbjHM1MNZacs70ZW2BjZoGukOqATu3utHFp JzezZbX+kk50cLyMp462SqBR/jrst0ej5YSm+219u8QVpsS98HA0+8rCGfxpInlSuoUN yq1A==
X-Gm-Message-State: APjAAAVKdLmZBdgAGLJdSS3KoykFnGW70MegEscGKZ3cIoFmnh41s/Of hepESGBm+j9Tmb+q2c1p3ww=
X-Google-Smtp-Source: APXvYqyZl8nMqW6jHPi6po+0d+G2vLnGR9HY+GAjMBLa0/OdNKzBjULwhW7VjdjiL6r5+HbEWGG2jg==
X-Received: by 2002:ac2:5a43:: with SMTP id r3mr7112599lfn.150.1574699709258;  Mon, 25 Nov 2019 08:35:09 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id m26sm4422525lfc.90.2019.11.25.08.35.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 08:35:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net>
Date: Mon, 25 Nov 2019 18:35:03 +0200
Cc: Bob Briscoe , tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com>
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net>
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 16:35:13 -0000

> On 25 Nov, 2019, at 5:46 pm, Mirja Kuehlewind  =
wrote:
>=20
> I need to double-check what the exact context of the sentence Bob =
mentions below is in the accECN draft but probably this should not be a =
normative requirement in this draft at all. I=E2=80=99m actually further =
not sure what exactly is meant with =E2=80=9Csupport=E2=80=9D in that =
sentence, but the question if a server replies to a RFC3168 SYN with an =
RFC3168 SYN-ACK is solely a question for RFC3168 and not AccECN.

As far as I can tell, the requirement is not worded precisely as Bob put =
it, but is implied in Section 3.1.1:

   +--------+--------+------------+-------------+----------------------+
   | A      | B      |  SYN A->B  |   SYN/ACK   | Feedback Mode        |
   |        |        |            |     B->A    |                      |
   +--------+--------+------------+-------------+----------------------+
   |        |        | AE CWR ECE |  AE CWR ECE |                      |

   | Nonce  | AccECN | 0   1   1  |  0   0   1  | classic ECN          |
   | ECN    | AccECN | 0   1   1  |  0   0   1  | classic ECN          |
   | No ECN | AccECN | 0   0   0  |  0   0   0  | Not ECN              |

[...]

   3.  The third block shows the cases where the TCP server (B) supports
       AccECN but the TCP client (A) supports some earlier variant of
       TCP feedback, indicated in its SYN.  Therefore, as soon as an
       AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
       both its half connections into the feedback mode shown in the
       rightmost column.

Now considering Richard's and Neal's points:

> There is gear deployed already, which ONLY supports shallow ce marking =
- which breaks 3168 entirely. Behind such a switch, a server would be =
better off going only with non-ect (no ecn at all), or accecn. So that =
state transition should be allowed (and i think it is) by the accecn =
draft.

> (Non-ect is classified into a different Q on the one example i could =
name, so no q sharing w/ drop class cc)

> IMHO it is worth emphasizing that much of the traffic that travels
> over the public Internet is sent by servers that are situated in
> datacenter networks where the datacenter switches are CE-marking using
> shallow-threshold DCTCP-style ECN. So that "datacenter traffic" and
> "public Internet traffic" are, in some sense, overlapping categories,
> rather than disjoint categories.

I imagine that any individual flow going out to the general Internet =
would occupy only a small fraction of a datacentre switch's capacity on =
any given link, and so would be unlikely to trigger CE marking even with =
a basic shallow threshold marking policy.  If it did, that would suggest =
that the link is indeed at capacity, and a reduction of send rate is =
therefore justified to avoid subsequent packet loss from the tail of the =
queue.

It is also, strictly speaking, a violation of RFC-3168 to apply =
differing policies for CE marking on ECT packets versus dropping Not-ECT =
packets, in this case by using the ECN field as a traffic classifier.  =
That a performance problem then arises when RFC-3168 traffic passes =
through an RFC-ignorant AQM is perhaps unsurprising.  Again, this sort =
of thing is acceptable in a closed and carefully controlled environment, =
but what is described here is not.

Absent such special interests, I think the existing language (quoted =
above) is correct.

 - Jonathan Morton


From nobody Mon Nov 25 08:44:01 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 152311209E3 for ; Mon, 25 Nov 2019 08:43:59 -0800 (PST)
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 wr_ccudR_EXV for ; Mon, 25 Nov 2019 08:43:57 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 2518F1209E2 for ; Mon, 25 Nov 2019 08:43:57 -0800 (PST)
Received: from 200116b82c892300b4b6b2442066fb94.dip.versatel-1u1.de ([2001:16b8:2c89:2300:b4b6:b244:2066:fb94]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iZHSt-0008Gu-6d; Mon, 25 Nov 2019 17:43:55 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com>
Date: Mon, 25 Nov 2019 17:43:54 +0100
Cc: Bob Briscoe , tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com>
To: Jonathan Morton 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1574700237;19d4225f;
X-HE-SMSGID: 1iZHSt-0008Gu-6d
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 16:43:59 -0000

Hi Jonathan,

I don=E2=80=99t think we can or should derive a normative requirement =
from this table. The table rather explains which mode you are in =
depending on the handshake that has happened. So it says: when client A =
is ECN capable and requests classic ECN support in the handshake and =
server B is AccECN capable and negotiated classic ECN support in the =
handshake then you are in classic ECN mode.=20

Even if you implement classic ECN or AccECN, you can of course always =
configure your machine to not use ECN. So for me that is an interface =
question which we don=E2=80=99t address in the draft.

Mirja



> On 25. Nov 2019, at 17:35, Jonathan Morton  =
wrote:
>=20
>> On 25 Nov, 2019, at 5:46 pm, Mirja Kuehlewind  =
wrote:
>>=20
>> I need to double-check what the exact context of the sentence Bob =
mentions below is in the accECN draft but probably this should not be a =
normative requirement in this draft at all. I=E2=80=99m actually further =
not sure what exactly is meant with =E2=80=9Csupport=E2=80=9D in that =
sentence, but the question if a server replies to a RFC3168 SYN with an =
RFC3168 SYN-ACK is solely a question for RFC3168 and not AccECN.
>=20
> As far as I can tell, the requirement is not worded precisely as Bob =
put it, but is implied in Section 3.1.1:
>=20
>   =
+--------+--------+------------+-------------+----------------------+
>   | A      | B      |  SYN A->B  |   SYN/ACK   | Feedback Mode        =
|
>   |        |        |            |     B->A    |                      =
|
>   =
+--------+--------+------------+-------------+----------------------+
>   |        |        | AE CWR ECE |  AE CWR ECE |                      =
|
> 
>   | Nonce  | AccECN | 0   1   1  |  0   0   1  | classic ECN          =
|
>   | ECN    | AccECN | 0   1   1  |  0   0   1  | classic ECN          =
|
>   | No ECN | AccECN | 0   0   0  |  0   0   0  | Not ECN              =
|
>=20
> [...]
>=20
>   3.  The third block shows the cases where the TCP server (B) =
supports
>       AccECN but the TCP client (A) supports some earlier variant of
>       TCP feedback, indicated in its SYN.  Therefore, as soon as an
>       AccECN-enabled TCP server (B) receives the SYN shown, it MUST =
set
>       both its half connections into the feedback mode shown in the
>       rightmost column.


From nobody Mon Nov 25 08:48: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 06B36120999 for ; Mon, 25 Nov 2019 08:48:20 -0800 (PST)
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 2LwQ70og8Rea for ; Mon, 25 Nov 2019 08:48:19 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 0924A12013D for ; Mon, 25 Nov 2019 08:48:19 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id r15so8647765lff.2 for ; Mon, 25 Nov 2019 08:48:18 -0800 (PST)
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=8WXucb26+tqG91r/uptWlAyiaMFtR3z2Ec0zdT0k1vI=; b=UlSRCA4Toy2u/zYayXNqHmcWAdciVnBof34GI4EaZZz4KhtPstSkXFw7b1GHuo2E9N 2TyBLaJdqxuX+amJ029WW1R/fDxRtcxpflHQFkNPa/3fhynZJbcdOqw6h7qRkl8N7uaS teR4tO3c6b8G4liuQ7Brctfw1nKmz9W5Smn2NmeiegUk8vW+pnoUS/8Vagf+q1Wkmufj bZj0Spo577DyxsMtR3dt9yGsZ4HU4RQvQd7TC6F/2miFUkIfjWwNtH1o3vokBPdO6Y6t OZHOFmnNunrl6A0GDPENYDd7SMBHqQCuSoM2Ye3TrpxlB2MaYXv+FH4FKJF7VfurTSpF 4SqA==
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=8WXucb26+tqG91r/uptWlAyiaMFtR3z2Ec0zdT0k1vI=; b=eI8n1SmeY5Ai/mESoyCwtWBMObKrFzASBCr63yZD5VqqFbUwbrVuI5mFV2tO9JfjLN 38ocAL8xM/xVRQzSd0sI6ACxDObnRE4Q9c+nrJ9oP27jCb9xYZLNpjmErwwcNQ+0Ymsq w7QDjdK7kPHoRjr9ooFuVHeLegVTCD4nEvNy7VVTRbfA2UExdeBH5fq+uJyM4TYFF0rh xxMHjf40NULC/A6yOye/mkxJ2sZJgsVcR5pa6Q3durGobByj1jOaKfbW5U/q266ZOVio h7f7JRppAKZ3wnccouMzGj/xcyukcNIxpwhzpbwywixS28tyroSdPHiV47GSfDtRcNxN RGuw==
X-Gm-Message-State: APjAAAVEwZiYn9N7rO+iZkFG8zUdsSfgkGx8RZfPDKvwS02fhTb90+Vw GTGP41shgOWqN0v/xyXPKTQ=
X-Google-Smtp-Source: APXvYqz7hJlSwVDD7Q6l2dgLBV2REqXTIdtKQvidguBgplMi8Z1VT5IGnxpT8J5Jn7a8A5VxZzMjAA==
X-Received: by 2002:ac2:5210:: with SMTP id a16mr21954226lfl.156.1574700497302;  Mon, 25 Nov 2019 08:48:17 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id k22sm3911499lfm.48.2019.11.25.08.48.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 08:48:16 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>
Date: Mon, 25 Nov 2019 18:48:09 +0200
Cc: Bob Briscoe , tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 16:48:20 -0000

> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind  =
wrote:
>=20
> I don=E2=80=99t think we can or should derive a normative requirement =
from this table. The table rather explains which mode you are in =
depending on the handshake that has happened. So it says: when client A =
is ECN capable and requests classic ECN support in the handshake and =
server B is AccECN capable and negotiated classic ECN support in the =
handshake then you are in classic ECN mode.=20

I will merely re-quote the final sentence from my quoted text, which =
transforms that table into a normative requirement:

>       Therefore, as soon as an
>       AccECN-enabled TCP server (B) receives the SYN shown, it MUST =
set
>       both its half connections into the feedback mode shown in the
>       rightmost column.

 - Jonathan Morton=


From nobody Mon Nov 25 09:02: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 B2C4612099E for ; Mon, 25 Nov 2019 09:02:11 -0800 (PST)
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 Jr7oms4TjOUx for ; Mon, 25 Nov 2019 09:02:10 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 031CB12099A for ; Mon, 25 Nov 2019 09:02:09 -0800 (PST)
Received: from 200116b82c892300b4b6b2442066fb94.dip.versatel-1u1.de ([2001:16b8:2c89:2300:b4b6:b244:2066:fb94]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iZHkU-0007YI-TD; Mon, 25 Nov 2019 18:02:06 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Mon, 25 Nov 2019 18:02:05 +0100
Cc: Bob Briscoe , tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> 
To: Jonathan Morton 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1574701330;9d151d66;
X-HE-SMSGID: 1iZHkU-0007YI-TD
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 17:02:12 -0000

Hi Jonathan,

Sorry I wasn=E2=80=99t clear. I think we should not have these normative =
requirement in the draft and change the text to make it non-normative. =
This section was meant to explain which modes you end up in and the =
current use of normative language doesn=E2=80=99t seem to be right to =
me.=20

Likewise the table was also not meant to say whenever you implement =
AccECN, you MUST negotiate it in the handshake. And likewise the table =
does not show any classic ECN only transitions.

Mirja


> On 25. Nov 2019, at 17:48, Jonathan Morton  =
wrote:
>=20
>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind  =
wrote:
>>=20
>> I don=E2=80=99t think we can or should derive a normative requirement =
from this table. The table rather explains which mode you are in =
depending on the handshake that has happened. So it says: when client A =
is ECN capable and requests classic ECN support in the handshake and =
server B is AccECN capable and negotiated classic ECN support in the =
handshake then you are in classic ECN mode.=20
>=20
> I will merely re-quote the final sentence from my quoted text, which =
transforms that table into a normative requirement:
>=20
>>      Therefore, as soon as an
>>      AccECN-enabled TCP server (B) receives the SYN shown, it MUST =
set
>>      both its half connections into the feedback mode shown in the
>>      rightmost column.
>=20
> - Jonathan Morton


From nobody Mon Nov 25 09:12: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 1A1501209F9 for ; Mon, 25 Nov 2019 09:12:20 -0800 (PST)
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, HTML_MESSAGE=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=bobbriscoe.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 5WncZr7NlST9 for ; Mon, 25 Nov 2019 09:12:17 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 632641209D7 for ; Mon, 25 Nov 2019 09:12:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=il0/Xr2DK9+OiKa33IVzr0a6uiFva914x7MqLNcSDlw=; b=Nm3ObsgJ7LbVnkYQmjc8rPm4C 5BW+EFZwrEqDbrsDOhVoxNHEgkAKIazX/tXttIqh4nIimfwwy6XzJZhra00A5Uh80hkiPxCSF+vnQ B9wmq4WFcZJBWXbq9t2i4jHfWOQ4fqz2/vpM7gwLkecBb+4J/7rCLtQAP5gnd+pFUQfbphUa/ZKrq bePXtbYXUknFRRK1Vb+42JpYN9P0kqDZ70/ULAJCD1FLsF9YFegQ6kaHR21FGRvKz8+sfRhEC+Rjc 6nreKZzEJc7ZvGmxIr8daSIOWYwRRE0wJZ+5rxjclepmxaoWlNXe7n1kH01DBGFBeEFA+pmv6moSE 3CzZwZFgQ==;
Received: from [31.185.128.31] (port=37234 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iZHuJ-00087D-Rh; Mon, 25 Nov 2019 17:12:16 +0000
To: Jonathan Morton , Richard Scheffenegger 
Cc: Mirja Kuehlewind , tcpm IETF list 
References:    <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
From: Bob Briscoe 
Message-ID: <2f085024-85e3-fe4f-1625-13574b19ff29@bobbriscoe.net>
Date: Mon, 25 Nov 2019 17:12:15 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <9D63E04D-73F0-4CF0-9357-3ACEF67FCA0F@gmail.com>
Content-Type: multipart/alternative; boundary="------------3E1F9624546E09A91AE4F2AE"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 17:12:20 -0000

This is a multi-part message in MIME format.
--------------3E1F9624546E09A91AE4F2AE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Jonathan,

On 24/11/2019 13:20, Jonathan Morton wrote:
>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger  wrote:
>>
>> My reading of bob’s suggestion is
>>
>> Syn - accecn
>> Syn-ack no ect
I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect', 
which implies the IP layer. I don't think this led to any confusion so 
far on the thread, but I've corrected it in case someone else gets confused.

>>
>> I don’t see any problem there ;
> That is indeed a valid transaction, but one which represents an AccECN client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it is also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE without AE on SYN) with a Not-ECT server.
>
> What the draft currently (and correctly, IMO) forbids is for an AccECN server to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason for allowing this, because the difference in code complexity must be very small, and the benefit to the RFC-3168 supporting clients which are ubiquitous today (even if they don't always advertise it) in terms of avoiding packet loss and retransmissions just for the sake of a congestion signal is significant.
I also "don't see any reason for allowing this", but that isn't what 
motivates text in RFCs. If there is no interoperability reason to 
disallow such a downgrade, then we should not disallow it.
>
> It does appear that I missed part of Bob's proposal through trying to read it on a phone at the airport.  It made me think that he was proposing that AccECN *clients* might not support RFC-3168 as well.  I now see that he was proposing this only for servers.  I still think this is wrong-headed, but it technically doesn't break the protocol on the wire.
Yes, that's my point.

If it doesn't break the protocol, it's not up to the IETF to tell 
implementers what is "right-headed". The two examples I gave are 
possible valid reasons an implementer might have (but even if no-one 
could think of a valid reason now, there's no need to preclude this):
i) a cut-down lightweight TCP implementation
ii) an implementer wishing to rationalize the server code she has to 
maintain when, in the long term future (recall that RFCs last for ever) 
AccECN might have become pervasive and 3168 ECN hardly ever seen.

Here's how I propose to alter the text:

CURRENT:

    3.  The third block shows the cases where the TCP server (B) supports
        AccECN but the TCP client (A) supports some earlier variant of
        TCP feedback, indicated in its SYN.Therefore, as soon as an AccECN-enabled TCP server (B) receives the SYN 
shown, it MUST set both its half connections into the feedback mode 
shown in the rightmost column.


PROPOSED:

    3.  The third block shows the cases where the TCP server (B) supports
        AccECN but the TCP client (A) supports some earlier variant of
        TCP feedback, indicated in its SYN.When an AccECN-enabled TCP server (B) receives a SYN from a client in 
classic ECN feedback mode (AE,CWR,ECE = 0,1,1) it SHOULD set both its 
half connections into the classic ECN feedback mode as shown in the 
rightmost column and return a SYN-ACK as shown (AE, CWR, ECE = 0,0,1). 
The "SHOULD" allows for the unlikely case where a server might not wish 
to implement classic ECN. When an AccECN-enabled TCP server (B) receives 
a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both 
its half connections into the No ECN feedback mode as shown in the 
rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).


Bob
>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------3E1F9624546E09A91AE4F2AE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Jonathan,

    

    
On 24/11/2019 13:20, Jonathan Morton
      wrote:

    

    

      

        
On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger <rscheff@gmx.at> wrote:

My reading of bob’s suggestion is

Syn - accecn
Syn-ack no ect

      

    

    I think Richard meant 'no ECN' at the TCP layer, rather than 'no
    ect', which implies the IP layer. I don't think this led to any
    confusion so far on the thread, but I've corrected it in case
    someone else gets confused.

    

    

      

        

I don’t see any problem there ;


      

      
That is indeed a valid transaction, but one which represents an AccECN client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it is also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE without AE on SYN) with a Not-ECT server.

What the draft currently (and correctly, IMO) forbids is for an AccECN server to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason for allowing this, because the difference in code complexity must be very small, and the benefit to the RFC-3168 supporting clients which are ubiquitous today (even if they don't always advertise it) in terms of avoiding packet loss and retransmissions just for the sake of a congestion signal is significant.

    

    I also "don't see any reason for allowing this", but that isn't what
    motivates text in RFCs. If there is no interoperability reason to
    disallow such a downgrade, then we should not disallow it.

    

      

It does appear that I missed part of Bob's proposal through trying to read it on a phone at the airport.  It made me think that he was proposing that AccECN *clients* might not support RFC-3168 as well.  I now see that he was proposing this only for servers.  I still think this is wrong-headed, but it technically doesn't break the protocol on the wire.

    

    Yes, that's my point.

    

    If it doesn't break the protocol, it's not up to the IETF to tell
    implementers what is "right-headed". The two examples I gave are
    possible valid reasons an implementer might have (but even if no-one
    could think of a valid reason now, there's no need to preclude
    this):

    i) a cut-down lightweight TCP implementation 

    ii) an implementer wishing to rationalize the server code she has to
    maintain when, in the long term future (recall that RFCs last for
    ever) AccECN might have become pervasive and 3168 ECN hardly ever
    seen.

    

    Here's how I propose to alter the text:

    

    CURRENT:

    
   3.  The third block shows the cases where the TCP server (B) supports
       AccECN but the TCP client (A) supports some earlier variant of
       TCP feedback, indicated in its SYN.  Therefore, as soon as an
       AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
       both its half connections into the feedback mode shown in the
       rightmost column.

    

    PROPOSED:

    

    
   3.  The third block shows the cases where the TCP server (B) supports
       AccECN but the TCP client (A) supports some earlier variant of
       TCP feedback, indicated in its SYN. When an AccECN-enabled TCP 
       server (B) receives a SYN from a client in classic ECN feedback 
       mode (AE,CWR,ECE = 0,1,1) it SHOULD set both its half connections 
       into the classic ECN feedback mode as shown in the rightmost 
       column and return a SYN-ACK as shown (AE, CWR, ECE = 0,0,1). 
       The "SHOULD" allows for the unlikely case where a server might 
       not wish to implement classic ECN.
       When an AccECN-enabled TCP server (B) receives a SYN from a client 
       in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both its half 
       connections into the No ECN feedback mode as shown in the rightmost 
       column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0). 



    

    Bob

    

      

 - Jonathan Morton

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------3E1F9624546E09A91AE4F2AE--


From nobody Mon Nov 25 13:42: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 1F89B120FB8 for ; Mon, 25 Nov 2019 13:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 o3vXs2asYAPl for ; Mon, 25 Nov 2019 13:42:09 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 78D32120F6C for ; Mon, 25 Nov 2019 13:42:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=cPw2nPM9suIhfOXBzC1lvDLvrbiKST/J7KlH/D0Vhng=; b=cz1xWeSKdTErVmTpMeQMR71o2V 2S+m/z2pE4f9IWmjjn74ceWkidFqkH2FC2utt4KYmb0Ux8p7A+FvuceFpieW5sl422J2N3LT7e8cM L49qDXcTjc9fnE/5AUFIUbKuTcOEfV/YeZcFfCT6akY3wyu3u5Zn/NKvlRNWjkBsOXdYzCdd+v3T+ W0WY2xdFVA3WW2is0qvV5/rO0/DeZ5w209mcEsGys0vqO9TyLBLo5HO5Nl0Wnx8+y/yB3hddfRtJs EG6VhkpdNc8F4qtjLfnfaM7zOZS+243Q4Z3zvqjTRScdhdUKJOntOzpLvQLNx2ipPSUuMTszwgxzL B57zAAKw==;
Received: from [31.185.128.31] (port=50474 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iZM7N-0004Qm-7U; Mon, 25 Nov 2019 21:42:01 +0000
To: Mirja Kuehlewind , Jonathan Morton 
Cc: tcpm IETF list , Richard Scheffenegger 
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>  
From: Bob Briscoe 
Message-ID: <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>
Date: Mon, 25 Nov 2019 21:41:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 21:42:14 -0000

Mirja,


On 26/11/2019 01:02, Mirja Kuehlewind wrote:
> Hi Jonathan,
>
> Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.
>
> Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.
In the spec of AccECN, it's necessary and reasonable to state normative 
requirements for a node "that is AccECN-enabled". That doesn't mean that 
an AccECN implementation has to always support AccECN - it can always 
disable AccECN. But we do have to say what it is expected to do if it is 
following the AccECN protocol.

This draft has included that normative language for the negotiation 
phase in all 16 revisions since the first individual draft (that you 
wrote!).

The table shows only cases where one end or the other is AccECN-capable, 
and the text preceding and following the table gives normative 
requirements solely for the AccECN node(s) in those cases. It doesn't 
give any normative requirements for non-AccECN nodes.

In block 3, the server is AccECN capable, so in the AccECN spec. it's 
perfectly reasonable to say what it ought to do in response to various 
types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 
the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.

The only case that is in question, AFAIC, is whether we have to say what 
an AccECN-capable server does in response to a SYN from an RFC3168 
client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can 
respond with a SYN-ACK that is either RFC3168 or non-ECN.

I just proposed respectively SHOULD and MAY, but I can now see there is 
no need to make that judgement call. However, it is still important to 
say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).

It's also important that the spec defines all three bits in the SYN-ACK 
responses, not just the 2-bits defined in RFC3168 - so that the 
combinations with AE=1 are ruled out and therefore remain available for 
future use.



Bob
>
> Mirja
>
>
>> On 25. Nov 2019, at 17:48, Jonathan Morton  wrote:
>>
>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind  wrote:
>>>
>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode.
>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:
>>
>>>       Therefore, as soon as an
>>>       AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
>>>       both its half connections into the feedback mode shown in the
>>>       rightmost column.
>> - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Tue Nov 26 00:02: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 C098F12101B for ; Tue, 26 Nov 2019 00:02:12 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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=bobbriscoe.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 WvDjc5CnaxvL for ; Tue, 26 Nov 2019 00:02:11 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 BEE33120804 for ; Tue, 26 Nov 2019 00:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=7nBPT4V1PARc3to3asGqc/aOlg+qjXaGAmEbmXx6chI=; b=wygpG1+HHDpgpJgC5rJjGgUKWZ YBr8tX0+ixZFaSZcvOnyuEthl4A7zTxg8LbbBAX+V7ojwnQbVbjbvH+FvvBgdrHkCnMsvONWDv0ZV OeTX6n4ZgnHJDVhGZX9qFrQm7CAjyKZ7eoVeT8/XG8wX7pqpuxmKKrjrAENQfl868mni/qjY7LIOq LBI+SQ/4Y3pxKYpDivNSh5xIKmZdalAVQmMofjQbhPFHwZSbXA2LjEzJ5hh2p4HcsNZNhbzR1D98t kkOXB9+yqJXeRWf7cgy0+Qjlby/u7LMprmAw/5A14745rkKtYi93YGQX3vprkihnRqyTWQGub+TO6 xpfD7sfA==;
Received: from [31.185.128.31] (port=50966 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iZVnS-0008En-ML; Tue, 26 Nov 2019 08:02:06 +0000
To: Jonathan Morton 
Cc: tcpm IETF list 
References: <28cdf725-546f-6d0f-516e-1c8f19a00749@bobbriscoe.net> <4F389E20-C5A7-441D-89CE-5F32A3629151@gmail.com>
From: Bob Briscoe 
Message-ID: <714a8940-5a2d-4302-300b-43f73eb9c476@bobbriscoe.net>
Date: Tue, 26 Nov 2019 08:02:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <4F389E20-C5A7-441D-89CE-5F32A3629151@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] History of ECN's use of TCP header bits vs. TCP option
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, 26 Nov 2019 08:02:15 -0000

Done - in the offline copy.

On 25/11/2019 22:57, Jonathan Morton wrote:
>> On 25 Nov, 2019, at 2:55 pm, Bob Briscoe  wrote:
>>
>> In Appendix B.1 of the AccECN draft it says:
>>     It is not recorded why ECN originally used this [header flags]
>>     approach instead of the more orthodox use of a TCP option.
>>
>> Having dug into the history, I propose we change this to:
>>
>> ECN originally used header flags rather than a TCP option because it was considered more efficient to use a header flag for 1 bit of feedback per ACK, and this bit could be overloaded to indicate support for ECN during the handshake. During the development of ECN, 1 bit crept up to 2, in order to deliver the feedback reliably and to work round some broken hosts that reflected the reserved flags during the handshake.
> This seems like a reasonable improvement to me.
>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Tue Nov 26 10:03: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 BD1EB1209DA for ; Tue, 26 Nov 2019 10:03:43 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 (2048-bit key) header.d=apple.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 O8NQJdwidez6 for ; Tue, 26 Nov 2019 10:03:40 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 0D51C120999 for ; Tue, 26 Nov 2019 10:03:39 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAQI2j5E024600; Tue, 26 Nov 2019 10:02:55 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=YPEaJA0vGxYhOlZkTNZLjutdeB2xRRSIhOkfFvAPqwI=; b=eg4UoHVdJj9qziyvbyKs8dvvLTtGQTofUGag+HDZknT5NEBu7a3Z4KhMfdEXopktbxK1 dU7k6NElKJmx75lKefAitXOWNiv9RT002DamKN0f4MtMfsKKkMNZ1vedsonmRmlrRdTq 1KX3FVXb7+j0qfhsiuD9Z0U/oTTnAPbRWMdrsElDG8tr+VWyu/kax3QkF2bvGdh2vIv+ iwPt2LftmvyIxNxtgLE1ITZvLu2e4atGeX1xLede2DGUyjF4M/nSIksOLjYWsymxKhO2 nwe5jEKVHDltGUiChx1kk5OmumTOwTsGwYc/6u66E1b8dZZsjGiAsBXTsFQvVcFQXuiU rg== 
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2wf4n7cw90-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Nov 2019 10:02:54 -0800
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPS id <0Q1L00M4Q8SFDT70@mr2-mtap-s01.rno.apple.com>; Tue, 26 Nov 2019 10:02:39 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) id <0Q1L00H008Q0FR00@nwk-mmpp-sz12.apple.com>; Tue, 26 Nov 2019 10:02:39 -0800 (PST)
X-Va-A: 
X-Va-T-CD: f53acd41044cfd4ed231c2dc519dc709
X-Va-E-CD: 4731977435aec74e69aa977e5c3ca6d0
X-Va-R-CD: b84307938ba62a64a1b6a12fbe868462
X-Va-CD: 0
X-Va-ID: 11ad7e9a-57ff-4890-baff-38801aa9db8e
X-V-A: 
X-V-T-CD: f53acd41044cfd4ed231c2dc519dc709
X-V-E-CD: 4731977435aec74e69aa977e5c3ca6d0
X-V-R-CD: b84307938ba62a64a1b6a12fbe868462
X-V-CD: 0
X-V-ID: 6f1bbc06-45ff-4767-be93-9f6de46baf5c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-26_05:,, signatures=0
Received: from [17.234.21.101] (unknown [17.234.21.101]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPSA id <0Q1L003ZK8SD6R50@nwk-mmpp-sz12.apple.com>; Tue, 26 Nov 2019 10:02:38 -0800 (PST)
Sender: cpaasch@apple.com
Content-type: multipart/alternative; boundary=Apple-Mail-4AFB73D1-F007-4D7D-B223-2DDF2A83D584
Content-transfer-encoding: 7bit
From: Christoph Paasch 
MIME-version: 1.0 (1.0)
Date: Tue, 26 Nov 2019 10:02:35 -0800
Message-id: <5164E35F-64F1-4852-AC43-AB071E245AA1@apple.com>
References: <2f085024-85e3-fe4f-1625-13574b19ff29@bobbriscoe.net>
Cc: Jonathan Morton , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind 
In-reply-to: <2f085024-85e3-fe4f-1625-13574b19ff29@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: iPhone Mail (18A172)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-26_05:, , signatures=0
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 26 Nov 2019 18:03:44 -0000

--Apple-Mail-4AFB73D1-F007-4D7D-B223-2DDF2A83D584
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

> On Nov 25, 2019, at 9:12 AM, Bob Briscoe  wrote:
>=20
> =EF=BB=BF Jonathan,
>=20
> On 24/11/2019 13:20, Jonathan Morton wrote:
>>>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger  wro=
te:
>>>>=20
>>>> My reading of bob=E2=80=99s suggestion is
>>>>=20
>>>> Syn - accecn
>>>> Syn-ack no ect
>> I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect', wh=
ich implies the IP layer. I don't think this led to any confusion so far on t=
he thread, but I've corrected it in case someone else gets confused.
>>=20
>>>=20
>>> I don=E2=80=99t see any problem there ;
>> That is indeed a valid transaction, but one which represents an AccECN cl=
ient (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it is al=
so legal by protocol to request RFC-3168 ECN (that is, CWR|ECE without AE on=
 SYN) with a Not-ECT server.
>>=20
>> What the draft currently (and correctly, IMO) forbids is for an AccECN se=
rver to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason for a=
llowing this, because the difference in code complexity must be very small, a=
nd the benefit to the RFC-3168 supporting clients which are ubiquitous today=
 (even if they don't always advertise it) in terms of avoiding packet loss a=
nd retransmissions just for the sake of a congestion signal is significant.
> I also "don't see any reason for allowing this", but that isn't what motiv=
ates text in RFCs. If there is no interoperability reason to disallow such a=
 downgrade, then we should not disallow it.
>>=20
>> It does appear that I missed part of Bob's proposal through trying to rea=
d it on a phone at the airport.  It made me think that he was proposing that=
 AccECN *clients* might not support RFC-3168 as well.  I now see that he was=
 proposing this only for servers.  I still think this is wrong-headed, but i=
t technically doesn't break the protocol on the wire.
> Yes, that's my point.
>=20
> If it doesn't break the protocol, it's not up to the IETF to tell implemen=
ters what is "right-headed". The two examples I gave are possible valid reas=
ons an implementer might have (but even if no-one could think of a valid rea=
son now, there's no need to preclude this):
> i) a cut-down lightweight TCP implementation=20
> ii) an implementer wishing to rationalize the server code she has to maint=
ain when, in the long term future (recall that RFCs last for ever) AccECN mi=
ght have become pervasive and 3168 ECN hardly ever seen.
>=20
> Here's how I propose to alter the text:
>=20
> CURRENT:
>    3.  The third block shows the cases where the TCP server (B) supports
>        AccECN but the TCP client (A) supports some earlier variant of
>        TCP feedback, indicated in its SYN.  Therefore, as soon as an
>        AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
>        both its half connections into the feedback mode shown in the
>        rightmost column.
>=20
> PROPOSED:
>=20
>    3.  The third block shows the cases where the TCP server (B) supports
>        AccECN but the TCP client (A) supports some earlier variant of
>        TCP feedback, indicated in its SYN. When an AccECN-enabled TCP=20
>        server (B) receives a SYN from a client in classic ECN feedback=20
>        mode (AE,CWR,ECE =3D 0,1,1) it SHOULD set both its half connections=
=20
>        into the classic ECN feedback mode as shown in the rightmost=20
>        column and return a SYN-ACK as shown (AE, CWR, ECE =3D 0,0,1).=20
>        The "SHOULD" allows for the unlikely case where a server might=20
>        not wish to implement classic ECN.
>        When an AccECN-enabled TCP server (B) receives a SYN from a client=20=

>        in No ECN mode (AE,CWR,ECE =3D 0,0,0) it MUST set both its half=20
>        connections into the No ECN feedback mode as shown in the rightmost=
=20
>        column and return the SYN-ACK shown (AE,CWR,ECE =3D 0,0,0).=20

I support this proposed change for all the reasons that have been outlined b=
y Bob and Neal.


Christoph


>=20
>=20
> Bob
>>=20
>>  - Jonathan Morton
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

--Apple-Mail-4AFB73D1-F007-4D7D-B223-2DDF2A83D584
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hello,

On Nov 25, 2019, at 9:12 AM, Bob Briscoe &l=
t;ietf@bobbriscoe.net> wrote:

=EF=BB=BF
 =20
    
 =20
 =20
    Jonathan,

    

    
On 24/11/2019 13:20, Jonathan Morton
      wrote:

    

    

      

        
On 23 Nov, 2019, at 4:43 pm, R=
ichard Scheffenegger <rscheff@gmx.at> wrote:

My reading of bob=E2=80=99s suggestion is

Syn - accecn
Syn-ack no ect

      

    

    I think Richard meant 'no ECN' at the TCP layer, rather than 'no
    ect', which implies the IP layer. I don't think this led to any
    confusion so far on the thread, but I've corrected it in case
    someone else gets confused.

    

    

      

        
I don=E2=80=99t see any problem there ;


      

      
That is indeed a valid transact=
ion, but one which represents an AccECN client (that is, AE|CWR|ECE on SYN) a=
nd a Not-ECT server.  Of course, it is also legal by protocol to request RFC=
-3168 ECN (that is, CWR|ECE without AE on SYN) with a Not-ECT server.

What the draft currently (and correctly, IMO) forbids is for an AccECN serve=
r to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason for allo=
wing this, because the difference in code complexity must be very small, and=
 the benefit to the RFC-3168 supporting clients which are ubiquitous today (=
even if they don't always advertise it) in terms of avoiding packet loss and=
 retransmissions just for the sake of a congestion signal is significant.
    

    I also "don't see any reason for allowing this", but that isn't what
    motivates text in RFCs. If there is no interoperability reason to
    disallow such a downgrade, then we should not disallow it.

    

      
It does appear that I missed part of Bob's proposal through trying to read i=
t on a phone at the airport.  It made me think that he was proposing that Ac=
cECN *clients* might not support RFC-3168 as well.  I now see that he was pr=
oposing this only for servers.  I still think this is wrong-headed, but it t=
echnically doesn't break the protocol on the wire.

    

    Yes, that's my point.

    

    If it doesn't break the protocol, it's not up to the IETF to tell
    implementers what is "right-headed". The two examples I gave are
    possible valid reasons an implementer might have (but even if no-one
    could think of a valid reason now, there's no need to preclude
    this):

    i) a cut-down lightweight TCP implementation 

    ii) an implementer wishing to rationalize the server code she has to
    maintain when, in the long term future (recall that RFCs last for
    ever) AccECN might have become pervasive and 3168 ECN hardly ever
    seen.

    

    Here's how I propose to alter the text:

    

    CURRENT:

    
   3.  The third block shows the cases where the T=
CP server (B) supports
       AccECN but the TCP client (A) supports some earlier variant of
       TCP feedback, indicated in its SYN.  Therefor=
e, as soon as an
       AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
       both its half connections into the feedback mode shown in the
       rightmost column.

    

    PROPOSED:

    

    
   3.  The third block shows the cases where the T=
CP server (B) supports
       AccECN but the TCP client (A) supports some earlier variant of
       TCP feedback, indicated in its SYN. When an A=
ccECN-enabled TCP=20
       server (B) receives a SYN from a client in classic ECN feedback=20
       mode (AE,CWR,ECE =3D 0,1,1) it SHOULD set both its half connections=20=

       into the classic ECN feedback mode as shown in the rightmost=20
       column and return a SYN-ACK as shown (AE, CWR, ECE =3D 0,0,1).=20
       The "SHOULD" allows for the unlikely case where a server might=20
       not wish to implement classic ECN.
       When an AccECN-enabled TCP server (B) receives a SYN from a client=20=

       in No ECN mode (AE,CWR,ECE =3D 0,0,0) it MUST set both its half=20
       connections into the No ECN feedback mode as shown in the rightmost=20=

       column and return the SYN-ACK shown (AE,CWR,ECE =3D 0,0,0). 


I support this proposed change f=
or all the reasons that have been outlined by Bob and Neal.


Christoph



    

    Bob

    

      
 - Jonathan Morton

    

    

    
--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

 =20

_______________________________________________
tcpm m=
ailing list
tcpm@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/tcpm
=

--Apple-Mail-4AFB73D1-F007-4D7D-B223-2DDF2A83D584--


From nobody Tue Nov 26 11:50:46 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 627781208E5 for ; Tue, 26 Nov 2019 11:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 3AYLEaXguKyu for ; Tue, 26 Nov 2019 11:50:43 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C87120804 for ; Tue, 26 Nov 2019 11:50:43 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAQJnsVN004169; Tue, 26 Nov 2019 11:49:54 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAQJnrjK004168; Tue, 26 Nov 2019 11:49:53 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911261949.xAQJnrjK004168@gndrsh.dnsmgr.net>
In-Reply-To: <2f085024-85e3-fe4f-1625-13574b19ff29@bobbriscoe.net>
To: Bob Briscoe 
Date: Tue, 26 Nov 2019 11:49:53 -0800 (PST)
CC: Jonathan Morton , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 26 Nov 2019 19:50:44 -0000

tcpm'ers:

        I believe the more common terminology is "Not ECT" (Not
ECN Capable Transport), rather than Non ECN.  Many new 
instances of "Classic" has crept in with the new text, which I
do think we should avoid.

        Comments inline marked [RWG].

Regards,
Rod

> Jonathan,
> 
> On 24/11/2019 13:20, Jonathan Morton wrote:
> >> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger  wrote:
> >>
> >> My reading of bob?s suggestion is
> >>
> >> Syn - accecn
> >> Syn-ack no ect
> I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect', 
> which implies the IP layer. I don't think this led to any confusion so 
> far on the thread, but I've corrected it in case someone else gets confused.
> 
> >>
> >> I don?t see any problem there ;
> > That is indeed a valid transaction, but one which represents an AccECN client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it is also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE without AE on SYN) with a Not-ECT server.
> >
> > What the draft currently (and correctly, IMO) forbids is for an AccECN server to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason for allowing this, because the difference in code complexity must be very small, and the benefit to the RFC-3168 supporting clients which are ubiquitous today (even if they don't always advertise it) in terms of avoiding packet loss and retransmissions just for the sake of a congestion signal is significant.
> I also "don't see any reason for allowing this", but that isn't what 
> motivates text in RFCs. If there is no interoperability reason to 
> disallow such a downgrade, then we should not disallow it.
> >
> > It does appear that I missed part of Bob's proposal through trying to read it on a phone at the airport.  It made me think that he was proposing that AccECN *clients* might not support RFC-3168 as well.  I now see that he was proposing this only for servers.  I still think this is wrong-headed, but it technically doesn't break the protocol on the wire.
> Yes, that's my point.
> 
> If it doesn't break the protocol, it's not up to the IETF to tell 
> implementers what is "right-headed". The two examples I gave are 
> possible valid reasons an implementer might have (but even if no-one 
> could think of a valid reason now, there's no need to preclude this):
> i) a cut-down lightweight TCP implementation
> ii) an implementer wishing to rationalize the server code she has to 
> maintain when, in the long term future (recall that RFCs last for ever) 
> AccECN might have become pervasive and 3168 ECN hardly ever seen.
> 
> Here's how I propose to alter the text:
> 
> CURRENT:
> 
>     3.  The third block shows the cases where the TCP server (B) supports
>         AccECN but the TCP client (A) supports some earlier variant of
>         TCP feedback, indicated in its SYN.Therefore, as soon as an AccECN-enabled TCP server (B) receives the SYN 
> shown, it MUST set both its half connections into the feedback mode 
> shown in the rightmost column.
> 
> 
> PROPOSED:
> 
>     3.  The third block shows the cases where the TCP server (B) supports
>         AccECN but the TCP client (A) supports some earlier variant of
>         TCP feedback, indicated in its SYN.When an AccECN-enabled TCP server (B) receives a SYN from a client in 
> classic ECN feedback mode (AE,CWR,ECE = 0,1,1) it SHOULD set both its 

classic -> RFC3168 

> half connections into the classic ECN feedback mode as shown in the 

ditto

> rightmost column and return a SYN-ACK as shown (AE, CWR, ECE = 0,0,1). 
> The "SHOULD" allows for the unlikely case where a server might not wish 
> to implement classic ECN. When an AccECN-enabled TCP server (B) receives 

Ditto

> a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both 

No ECN -> Not ECT

> its half connections into the No ECN feedback mode as shown in the 

No ECN -> Not ECT

> rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).
> 
> 
> Bob
> >
> >   - Jonathan Morton
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 

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

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Tue Nov 26 17:11:13 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 CF165120B17 for ; Tue, 26 Nov 2019 17:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 kgAjG10ZvK3b for ; Tue, 26 Nov 2019 17:11:10 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 53A9D1200D7 for ; Tue, 26 Nov 2019 17:11:10 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAR16xnu040573; Tue, 26 Nov 2019 17:11:03 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=r29MUFjKBWpuXhzlHn16wqP2h9zh2qkUrl3Ayh/1OJg=; b=bN9BtQmRWp1Xi8W29bPLf943Cmq7A7jWoxl3pN2yk0ABtOLcOQF9acipzxU5OHeqRUie x6bwl3B/PJFKDb7pXzbk2rW6fjRi/+H7oaAawUiGTrP59pndLtAEptlAmH6jjq76ILoK DimH24EqVWoRtNtdc0UpYkiMOMyp0CLOLHwp4YYYwuudUekNBNYmC4g1MY6A0PY5/PuG nmynNMZwt76Ya+hphYIu7+ms7ha1c17UIfYCan4lGjnqxDjz5Iqrb+yzzPuihcTO4WKZ On99Lr5djWJYQqJ5npFyXT7GuNAkAIF9Kk6VWqix3HQm41elLdrExf5MVWGYdfocIdfR QA== 
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2wf4n7k2hp-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Nov 2019 17:11:03 -0800
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPS id <0Q1L00EYGSMEM350@ma1-mtap-s03.corp.apple.com>; Tue, 26 Nov 2019 17:11:02 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) id <0Q1L00F00S9K9100@nwk-mmpp-sz12.apple.com>; Tue, 26 Nov 2019 17:11:02 -0800 (PST)
X-Va-A: 
X-Va-T-CD: 
X-Va-E-CD: 
X-Va-R-CD: 
X-Va-CD: 0
X-Va-ID: 4bea6dc0-61e9-4742-ae76-175ad6809e19
X-V-A: 
X-V-T-CD: 891a14b3251185fcf41ff438c430a9b6
X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d
X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b
X-V-CD: 0
X-V-ID: 32465768-91b8-459f-b105-e93263eac7d4
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-26_08:,, signatures=0
Received: from [17.234.13.111] (unknown [17.234.13.111]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPSA id <0Q1L006VHSMDZT40@nwk-mmpp-sz12.apple.com>; Tue, 26 Nov 2019 17:11:02 -0800 (PST)
Sender: vidhi_goel@apple.com
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Vidhi Goel 
In-reply-to: 
Date: Tue, 26 Nov 2019 17:11:01 -0800
Cc: Neal Cardwell , tcpm@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <61394400-07CA-412D-AF1E-260B788A3D79@apple.com>
References:  
To: Lars Eggert , mallman@icir.org
X-Mailer: Apple Mail (2.3594.4.19)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-26_08:, , signatures=0
Archived-At: 
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
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, 27 Nov 2019 01:11:12 -0000

>> That is IMO the key question. *If* there is an alternative mechanism =
to ABC that solves (some of) the same problems, and potentially in a =
better way, or in a way that has a different implementation footprint, =
that may be worth documenting.

I think we can combine the byte counting mechanism of ABC for increasing =
congestion window and come up with an alternate way for controlling the =
burst sending. This will allow us to keep the two issues separate.

>> I'm not up to speed with the Linux code, but from what Neal writes, =
it seems that the Linux mechanism is tied in with or relying on a bunch =
of lower-level packet I/O functionality that is maybe pretty =
Linux-specific? In other words, can something like the Linux mechanism =
even be instantiated without (much of) this underpinning?

If we can come up with a generic approach (like pacing) to do it, an =
implementation wouldn=E2=80=99t require Linux specific mechanisms.

Vidhi

> On Nov 13, 2019, at 12:10 AM, Vidhi Goel  wrote:
>=20
> Adding Mark again as the bbn email doesn=E2=80=99t exist.
>=20
> Vidhi
>=20
>> On Nov 12, 2019, at 10:53 PM, Lars Eggert  wrote:
>>=20
>> =EF=BB=BFHi,
>>=20
>>> On 2019-11-12, at 23:44, Vidhi Goel =
 wrote:
>>> +Mark Allman
>>=20
>> oh, is he at BBN now? Not mallman@icir.org?
>>=20
>>> Is it worth investing time in writing another draft to document what =
Linux (and possibly other implementations) do for more accurate =
congestion window growth and for solving the burst send issue via =
pacing, TSQ etc.?
>>=20
>> That is IMO the key question. *If* there is an alternative mechanism =
to ABC that solves (some of) the same problems, and potentially in a =
better way, or in a way that has a different implementation footprint, =
that may be worth documenting.
>>=20
>> I'm not up to speed with the Linux code, but from what Neal writes, =
it seems that the Linux mechanism is tied in with or relying on a bunch =
of lower-level packet I/O functionality that is maybe pretty =
Linux-specific? In other words, can something like the Linux mechanism =
even be instantiated without (much of) this underpinning?
>>=20
>> Lars


From nobody Wed Nov 27 05:14: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 7CC4F1208B1 for ; Wed, 27 Nov 2019 05:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ULEYwxMEEaHk for ; Wed, 27 Nov 2019 05:14:27 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5654A12083F for ; Wed, 27 Nov 2019 05:14:27 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2BC832C4081; Wed, 27 Nov 2019 05:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NPQhYeScFLLv; Wed, 27 Nov 2019 05:14:26 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9A7322C407E; Wed, 27 Nov 2019 05:14:26 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3B21A1EDC31D; Wed, 27 Nov 2019 08:14:26 -0500 (EST)
From: "Mark Allman" 
To: "Vidhi Goel" 
Cc: "Neal Cardwell" , tcpm@ietf.org
Date: Wed, 27 Nov 2019 08:14:26 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu>
In-Reply-To: <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com>  <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
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, 27 Nov 2019 13:14:28 -0000

> +Mark Allman

Just to clear it up, I *was* at BBN long ago when the ABC document
was written.  It's a cool place to work.  I recommend it.  But, I
now hang out at ICSI.

> I believe that ABC was written to solve the problem with ACK
> counting by counting the number of bytes acknowledged for
> misbehaving receivers. Limiting the increase to 2*MSS was a good
> solution to avoid bursts at the time.

The main motivation behind ABC was to counteract delayed ACKs.  The
common approach at the time was to just bump cwnd by one MSS every
time an ACK rolled in.  So, if an ACK covered two segments because
the receiver was delaying the ACKs then the growth rate during slow
start was 1.5x per RTT instead of the 2x that was really
envisioned.  During congestion avoidance the growth was 1 MSS every
2 RTTs instead of the envisioned every RTT.

A secondary motivation was to counteract these ACK division attacks
that Savage taught us about.  I.e., we could ACK an MSS-sized packet
one byte at a time and the sender would then increase the cwnd by
MSS*MSS bytes in the prevalent ACK counting scheme (i.e., cwnd would
get bumped by MSS bytes for every ACK).

The limit has two roots ...

(1) The limit is important in slow starts that follow an RTO.  As
    the RFC discusses, in this case we might retransmit a single
    packet and this will cause the receiver's window to slide a
    great deal.  Therefore, an ACK may indicate that a ton of data
    has left the network, but that isn't really the case.  So, we
    don't want to increase the cwnd based on all the new bytes
    ACKed.

    I have since mostly decided that this use of L is crude.
    Probably there is a more elegant way to do it by using the
    scoreboard and the SACK information to get a better
    understanding of what left the network and when.  That said, in
    this case L is simple and probably about right most of the
    time.

(2) I think there was some general conservativeness to bursts and
    using L everywhere quelled some of the worry.  Here L=2 was used
    to exactly offset delayed ACKs.

> I agree that increasing the congestion window and controlling the
> burst rate are orthogonal issues.

Yes.  In fact, we did subsequent research on mitigating bursts
because we never really thought of ABC as somehow the way to control
bursts (research papers available, but never went into RFCs).

And, in a world that leverages stretch ACKs as a routine I think
Linux's approach of not using an L may well be correct.  Documenting
that and the reasoning behind it in modern networks seems useful to
me.

allman


From nobody Wed Nov 27 09:30:28 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 02CBA12098B for ; Wed, 27 Nov 2019 09:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 E-Fq-1jo19u2 for ; Wed, 27 Nov 2019 09:30:22 -0800 (PST)
Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [134.130.5.47]) (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 4CCD3120871 for ; Wed, 27 Nov 2019 09:30:22 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BdGwBxst5d/xUN4ollgkaBSVVZay80k?= =?us-ascii?q?yKBbJtSCQEBAQEBAQEBAQgtAgEBhkIkOQUNAhABAQUBAQEBAQUEbYU4C4YTGTg?= =?us-ascii?q?BPkInBIM1gngBtQKFT4M8gUiBN4wVD4FMP4ERJwwDEYQOhweCLASuOQeBRGxyl?= =?us-ascii?q?GQbgjAQh2uEEotijkiaPIEyOCGBWDMaJHkBgkJPERSGYI4ughyMBQGBDwEB?=
X-IPAS-Result: =?us-ascii?q?A2BdGwBxst5d/xUN4ollgkaBSVVZay80kyKBbJtSCQEBAQE?= =?us-ascii?q?BAQEBAQgtAgEBhkIkOQUNAhABAQUBAQEBAQUEbYU4C4YTGTgBPkInBIM1gngBt?= =?us-ascii?q?QKFT4M8gUiBN4wVD4FMP4ERJwwDEYQOhweCLASuOQeBRGxylGQbgjAQh2uEEot?= =?us-ascii?q?ijkiaPIEyOCGBWDMaJHkBgkJPERSGYI4ughyMBQGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.69,250,1571695200"; d="scan'208";a="95751275"
Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 27 Nov 2019 18:29:57 +0100
Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id E67C141AB5 for ; Wed, 27 Nov 2019 18:29:56 +0100 (CET)
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 27 Nov 2019 18:29:56 +0100
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1130.005; Wed, 27 Nov 2019 18:29:56 +0100
From: Mike Kosek 
To: "tcpm@ietf.org" 
Thread-Topic: RFC793bis draft 14 Reserved Bits
Thread-Index: AQHVpUhJOB/Pnwk6jkiMTcFgdsUcHg==
Date: Wed, 27 Nov 2019 17:29:55 +0000
Message-ID: <6D121F63-82F5-4AFA-9593-DE22BAC7C153@comsys.rwth-aachen.de>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.226.12.218]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1A4396FA02A3B245A12A140ACC657FC4@comsys.rwth-aachen.de>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] RFC793bis draft 14 Reserved Bits
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, 27 Nov 2019 17:30:25 -0000

Hi tcpm,

Sorry for bumping this, maybe it got overlooked during 106.

Catching up on draft-ietf-tcpm-rfc793bis-14, I was wondering why the rsrvd =
bits are not explicitly stated as a formal MUST requirement:=20

"Must be zero in generated segments and must be ignored in received segment=
s, if corresponding future features are unimplemented by the sending or rec=
eiving host."

To my understanding, the current phrasing is up to interpretation, i.e., so=
meone might opt to not implement it as stated due to the missing formal MUS=
T - Please prove me wrong if I am missing something.

Best Regards,
Mike=


From nobody Wed Nov 27 18:44:42 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
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 92CB11208C4 for ; Wed, 27 Nov 2019 18:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 Ps6MYvFIKWop for ; Wed, 27 Nov 2019 18:44:39 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A1D1200E7 for ; Wed, 27 Nov 2019 18:44:39 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAS2iYbD010084; Wed, 27 Nov 2019 18:44:34 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAS2iX3T010083; Wed, 27 Nov 2019 18:44:33 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net>
In-Reply-To: <6D121F63-82F5-4AFA-9593-DE22BAC7C153@comsys.rwth-aachen.de>
To: Mike Kosek 
Date: Wed, 27 Nov 2019 18:44:33 -0800 (PST)
CC: "tcpm@ietf.org" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] RFC793bis draft 14 Reserved Bits
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, 28 Nov 2019 02:44:40 -0000

> Hi tcpm,
> 
> Sorry for bumping this, maybe it got overlooked during 106.
> 
> Catching up on draft-ietf-tcpm-rfc793bis-14, I was wondering why the rsrvd bits are not explicitly stated as a formal MUST requirement: 
> 
> "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."
> 
> To my understanding, the current phrasing is up to interpretation, i.e., someone might opt to not implement it as stated due to the missing formal MUST - Please prove me wrong if I am missing something.

I would even like to see it go further and add "they MUST be ignored by the network, and traverse the network unchanged."


-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Wed Nov 27 19:53: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 E059A120B34 for ; Wed, 27 Nov 2019 19:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level: 
X-Spam-Status: No, score=-1.219 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_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 kCpZesMZObw0 for ; Wed, 27 Nov 2019 19:53:00 -0800 (PST)
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 AB8731200D5 for ; Wed, 27 Nov 2019 19:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=TiDjy7pmlXT+/9hBKe9d47KIPFI8vS3IGP6vTbZKUjQ=; b=qZtt2MmJQF2rpIlYiO53C15bU bRNc6IU9Bs2cTuAaIHEx0k76MWGiCNcuEvogrpQWtJeAHwkWUKRF62O+8S5eU7xzV09rbheoJQ5uP iY+NQY3fa64t4SLkjCnLMPNHxywvltWQ0D7Dtja+IjScCzGZECD+E7qRUK9s9JbPYKpZrLYPiO+nr fsOje1jKIFWVJbk/VvivPy/F2k+zLgPkxQphSLDJ8yvT4DTjeKQPr54KkThXfFzxEHrBQTL4tBCeI wJYZawoYBCa11AopLArrpqR84jSC3m/vDlHZvq8FbGZDOlFWQZDQVwsJesNOrpgPoCyedONF+cLFh s+etbMkKQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54316 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 1iaArO-000sSt-VH; Wed, 27 Nov 2019 22:52:59 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net>
Date: Wed, 27 Nov 2019 19:52:53 -0800
Cc: Mike Kosek , "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com>
References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net>
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
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] RFC793bis draft 14 Reserved Bits
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, 28 Nov 2019 03:53:04 -0000

> On Nov 27, 2019, at 6:44 PM, Rodney W. Grimes =
<4bone@gndrsh.dnsmgr.net> wrote:
>=20
>> Hi tcpm,
>>=20
>> Sorry for bumping this, maybe it got overlooked during 106.
>>=20
>> Catching up on draft-ietf-tcpm-rfc793bis-14, I was wondering why the =
rsrvd bits are not explicitly stated as a formal MUST requirement:=20
>>=20
>> "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."
>>=20
>> To my understanding, the current phrasing is up to interpretation, =
i.e., someone might opt to not implement it as stated due to the missing =
formal MUST - Please prove me wrong if I am missing something.
>=20
> I would even like to see it go further and add "they MUST be ignored =
by the network, and traverse the network unchanged.=E2=80=9D

Perhaps further explicitly:

they MUST be ignored by the network and MUST traverse the network =
unchanged=


From nobody Thu Nov 28 03:35:31 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 EC3CA12081A for ; Thu, 28 Nov 2019 03:35:29 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 9czu875Ud9DP for ; Thu, 28 Nov 2019 03:35:27 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 C9B18120819 for ; Thu, 28 Nov 2019 03:35:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574940874; bh=4EPztg4j/3wwv7Jb1Ag0hQoXnkAMCLjo/3vtLevzhKQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=KtO59CbEu1CKZWUyEu+OSlMa96Mup2vP6WEafqR2Y6k4scJPQOroSKJZn4e/IuRRo M+KnvslZTGUO2oThlW9RPkJosB7ny9tTAWsPl37kox4mWSsN8lbndDg2tTErRR8jE0 rAUtb6yNRh4e1jw4vk0CQVlcnKvpUSYLY8dS5wzY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.69.89] ([217.70.211.12]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MgvrB-1hsydL2pBt-00hPaL; Thu, 28 Nov 2019 12:34:34 +0100
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, Bob Briscoe 
Cc: tcpm IETF list , Richard Scheffenegger , Mirja Kuehlewind 
References: <201911261949.xAQJnrjK004168@gndrsh.dnsmgr.net>
From: "Scheffenegger, Richard" 
Message-ID: <38984214-7d4b-81b1-9c15-8347ad411c0b@gmx.at>
Date: Thu, 28 Nov 2019 12:34:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <201911261949.xAQJnrjK004168@gndrsh.dnsmgr.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Xv45JgwGUqNVWM6wHJPhFR7VdYvMxDcEPayiV2uFohwR4U80nSg i0L++u/EDotAbhR9zGsRb0h0vybMQZeVA/b6vgx03mpf5cfTAQPLYacIuMNxLKpXG6bKNxf ioYGil+B5dTpn0Lkj9h2wrwf67OLnwj/rp8ZXYhnL9LaeWboS4RG06jeyia55+BJPK4luDM F3gLkz9fySMa5s4U55sWA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mIAK7rRMgZE=:2S8L1AKn3nvxsJJcshVf1x i5g5/iF9jO7sBB6aXa9pDp9jEuhF67LgCxt3ub/yu/N1DbR24FMADJMNwEQrU0jVsdu6cUhnw 6/7EJBQvJBzHXeOViJM0GxzUUF4P6LmdS6dwwJt49AzbJMiVojaVzda1tVsbd916HMRMqk8eG H1pXTejOdaexMRtoc0PoObvk+COSjpsSSv/FffikYRBaGhe0+x4B7Hu6gwqEr+6+a6l4lv3hm Im2EtYeYP9XI7U/vXecW7IvnCAZz1LoL/Qj8bt45LrkPGYK4Hg1LQJyeECjZZXzUj6WaWHC+a u0AuHY+oS5HGVhyroTPjGzxZXPxr8v6mNgTv5sK+zNZwGam7f6q0kxzrVBWGjQ3UQOAM5y3p8 494ERxFX6KxXtUu2MPYRm2e4hWKz4s3L2tMzpf7HeSzbs5q/jv8yU/w5rX2AVqn9Yd/uNUdIv SMFn/LSocciKhuTFjvUIhNsIp93AXcQ0vaG7Y2+hOJBIoNkhK1/VKTaE2D7pvdjyqRuwH9Wkf wASJCGe/PJVikeOEZHw4ps/smu8mkHy44/Zd316XAswSroFlBnbdv9VpkeKfrVnWYizpkDDEr H0gqxAXGFlNiTmyfds8B78wMQf59kLraa3bNDliGB9sAZbV0YijkYxRw2mWOF17EjWSw5LxXr xv0umFXCiZ2mJpiuBcmlP2j9pIgHZVG3U1UNz1bidylfXMOWlFOY7wjqDKbZ3mmFh+bM/oEns xRSTtLRbjcTBHrgNhEixyDwbLmkSlThFa6vSgyr0i5ZdHYTBPLnSYaWvhkw/uz8D2aATuoeI2 PMCCHyxrjyvgXxuJzGrOX7p8Aegab0C5a2hZtbhK0ScTwUQVVJndk/QhbqZtGjCExhnxpXTtX kMZTrrOh4BcU8Jz95JX1EwjqScJP0Jxi8pHRuBT5EA8iTD283ZEPYVmzgRk49b2uSwrzhTIsT HteKx8Tdd/c87d0kWC9+Vm+mwbY1TqA+RVpGoM05fqRUSRjzE838kQXfDM3D+4GI99iUsZtpD x7DEMBQ3caEdZlFOGgiPeXXFxgbDrT1IVv9nWCpxadl+5zDiEdiR8u1xVUNvlRThIy0UGPNVX TVRiAssvdrCx/FoaZQ2AIzEdEFTPH+HQNEeZSoW8mVBRv6PInORmQtbvO8+NObs9Uul4Ngfoi dDHbXYkziNyX0DAdoA82F0R12V9obD7s9m36Nc/2gY9+/fnV1IiFNV/XRji5QrF4yI1cJWaTc vrka0YpuSpGD5pw09a6yGU7ZwYmDZldnSEXv+Hw==
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 28 Nov 2019 11:35:30 -0000

Hi,

I support the new text that Bob has suggested to allow a AccECN server
to choose to not support RFC3168 ECN.

I also support Rod's suggestion to replace references to "classic" ECN
with RFC3168 ECN.

However, as bob also pointed out, "ECT" is usually interpreted in the
context of the IP header, but the AccECN draft only concerns itself with
the TCP layer, where "ECN mode" / "non ECN mode" is the correct
description of the state of the TCP sessions feedback...

Best regards,
   Richard


Am 26.11.2019 um 02:49 schrieb Rodney W. Grimes:
> tcpm'ers:
>
>          I believe the more common terminology is "Not ECT" (Not
> ECN Capable Transport), rather than Non ECN.  Many new
> instances of "Classic" has crept in with the new text, which I
> do think we should avoid.
>
>          Comments inline marked [RWG].
>
> Regards,
> Rod
>
>> Jonathan,
>>
>> On 24/11/2019 13:20, Jonathan Morton wrote:
>>>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger  w=
rote:
>>>>
>>>> My reading of bob?s suggestion is
>>>>
>>>> Syn - accecn
>>>> Syn-ack no ect
>> I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect',
>> which implies the IP layer. I don't think this led to any confusion so
>> far on the thread, but I've corrected it in case someone else gets conf=
used.
>>
>>>>
>>>> I don?t see any problem there ;
>>> That is indeed a valid transaction, but one which represents an AccECN=
 client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  Of course, it =
is also legal by protocol to request RFC-3168 ECN (that is, CWR|ECE withou=
t AE on SYN) with a Not-ECT server.
>>>
>>> What the draft currently (and correctly, IMO) forbids is for an AccECN=
 server to downgrade RFC-3168 clients to Not-ECT.  I don't see any reason =
for allowing this, because the difference in code complexity must be very =
small, and the benefit to the RFC-3168 supporting clients which are ubiqui=
tous today (even if they don't always advertise it) in terms of avoiding p=
acket loss and retransmissions just for the sake of a congestion signal is=
 significant.
>> I also "don't see any reason for allowing this", but that isn't what
>> motivates text in RFCs. If there is no interoperability reason to
>> disallow such a downgrade, then we should not disallow it.
>>>
>>> It does appear that I missed part of Bob's proposal through trying to =
read it on a phone at the airport.  It made me think that he was proposing=
 that AccECN *clients* might not support RFC-3168 as well.  I now see that=
 he was proposing this only for servers.  I still think this is wrong-head=
ed, but it technically doesn't break the protocol on the wire.
>> Yes, that's my point.
>>
>> If it doesn't break the protocol, it's not up to the IETF to tell
>> implementers what is "right-headed". The two examples I gave are
>> possible valid reasons an implementer might have (but even if no-one
>> could think of a valid reason now, there's no need to preclude this):
>> i) a cut-down lightweight TCP implementation
>> ii) an implementer wishing to rationalize the server code she has to
>> maintain when, in the long term future (recall that RFCs last for ever)
>> AccECN might have become pervasive and 3168 ECN hardly ever seen.
>>
>> Here's how I propose to alter the text:
>>
>> CURRENT:
>>
>>      3.  The third block shows the cases where the TCP server (B) suppo=
rts
>>          AccECN but the TCP client (A) supports some earlier variant of
>>          TCP feedback, indicated in its SYN.Therefore, as soon as an Ac=
cECN-enabled TCP server (B) receives the SYN
>> shown, it MUST set both its half connections into the feedback mode
>> shown in the rightmost column.
>>
>>
>> PROPOSED:
>>
>>      3.  The third block shows the cases where the TCP server (B) suppo=
rts
>>          AccECN but the TCP client (A) supports some earlier variant of
>>          TCP feedback, indicated in its SYN.When an AccECN-enabled TCP =
server (B) receives a SYN from a client in
>> classic ECN feedback mode (AE,CWR,ECE =3D 0,1,1) it SHOULD set both its
>
> classic -> RFC3168
>
>> half connections into the classic ECN feedback mode as shown in the
>
> ditto
>
>> rightmost column and return a SYN-ACK as shown (AE, CWR, ECE =3D 0,0,1)=
.
>> The "SHOULD" allows for the unlikely case where a server might not wish
>> to implement classic ECN. When an AccECN-enabled TCP server (B) receive=
s
>
> Ditto
>
>> a SYN from a client in No ECN mode (AE,CWR,ECE =3D 0,0,0) it MUST set b=
oth
>
> No ECN -> Not ECT
>
>> its half connections into the No ECN feedback mode as shown in the
>
> No ECN -> Not ECT
>
>> rightmost column and return the SYN-ACK shown (AE,CWR,ECE =3D 0,0,0).
>>
>>
>> Bob
>>>
>>>    - Jonathan Morton
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>


From nobody Thu Nov 28 10:37:07 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 9BA3D120809; Thu, 28 Nov 2019 10:37:05 -0800 (PST)
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 kaUAxCeV_96d; Thu, 28 Nov 2019 10:37:03 -0800 (PST)
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 2F1801208B7; Thu, 28 Nov 2019 10:37:02 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 593AB25A12; Thu, 28 Nov 2019 19:37:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1574966221; bh=7RUf0HM9XERJjKVBAy64VCkQ9lvbtqFa9n0XbQuTLTU=; h=From:To:CC:Subject:Date:From; b=LTQc+U6ejU4M9z5/J+Jcsau2Yjh/c7TDUITb7XPvPNouC2ufAvm+IKZkISwzx+l3N MwZNqOQN5z2r0nBafvwC6ItYklujZ88FaaHazIAlhFDqGwdJhry0T5INqLM/3+GiJs Oo+/4ioCVqkio0hIAl2YBOC9JPo+LAHdf9LkXDzI=
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 1XBHjwZQPyGX; Thu, 28 Nov 2019 19:37:00 +0100 (CET)
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; Thu, 28 Nov 2019 19:37:00 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.242]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 28 Nov 2019 19:37:00 +0100
From: "Scharf, Michael" 
To: tcpm IETF list 
CC: "draft-scharf-tcpm-yang-tcp@ietf.org" 
Thread-Topic: Open questions in draft-scharf-tcpm-yang-tcp-03
Thread-Index: AdWmGolxZReXGVxfT16zv56GRPhU5A==
Date: Thu, 28 Nov 2019 18:37:00 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D54D9D2@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.63.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] Open questions in draft-scharf-tcpm-yang-tcp-03
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, 28 Nov 2019 18:37:05 -0000

[chair hat off]

At IETF 106 there was not enough time left for Mahesh to present the latest=
 update of the document "YANG Model for Transmission Control Protocol (TCP)=
 Configuration".

Mahesh, Vishal and me have significantly updated draft-scharf-tcpm-yang-tcp=
-03 since the last meeting. The changes are summarized in the slides that c=
an be found at:

   https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-yang-=
model-for-transmission-control-protocol-tcp-configuration-01

Our proposal to refine the scope of the document. This results in at least =
4 questions:

1. Should the model support statistics?

2. Should it model all TCP connections?

3. Add support for TCP-AO?

4. Add support for TCP-MD5?

The slide deck details why these four questions are relevant. At least the =
last two requirements originate from another IETF document (draft-ietf-idr-=
bgp-model).

The authors plan to further update the document and address open issues as =
far as possible. Therefore we seek guidance from the TCPM community on thes=
e questions. Feedback on the list (or off-list) would be highly welcome.

Thanks

Michael (on behalf of the authors)


PS: I'd like to note that the TCPM chairs usually try hard to give at least=
 some time to all presentations on the agenda. While I believe that this is=
 an important tradition in TCPM, I decided not to intervene last meeting in=
 order to avoid an impression that an own document would be prioritized ove=
r other topics.


From nobody Fri Nov 29 09:08:46 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 29592120A33; Fri, 29 Nov 2019 09:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 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_NEUTRAL=0.779] 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 iZjkuDU93Trt; Fri, 29 Nov 2019 09:08:43 -0800 (PST)
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 29EFC12088D; Fri, 29 Nov 2019 09:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=ZRW0kv2z/1ANFBfotOP+zlc/jNdWrCBulqXlZd6gXuw=; b=bKn5i4DniMv/kZFOQ9M4xug0F av8kNOFrlx6d+B3j+8okKzUg/sS2fky2vfFMfkVTVbYVfJ6vFfiQ/u1LMMCSizkA/xS6SyB38JB4f gOsPS+/0wnSwadXZMD8Fuj+7KQhwRp28E/jUBPHuVFBzwh1OVTEZlzqQbgh0qVWHblBF6wP5y4wWt H89kdVPlQiYtgEOwoqNQnW9hZlNPv9xyVVzWJYlDQvIswAtoXTPwMnRlzr3ljCtWijW7AqB+YBFc+ qVFryK02KYFPu4cKN15vzG76E/eFaf3XZjUklT2CQIrEyzJFYLY7ODLj1nXX/ts36WdevKT6ZTJF2 8/Iu4O7+A==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55851 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 1iajl0-001bFQ-95; Fri, 29 Nov 2019 12:08:42 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D54D9D2@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Fri, 29 Nov 2019 09:08:37 -0800
Cc: tcpm IETF list , "draft-scharf-tcpm-yang-tcp@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5491D316-6F86-4DD1-A92C-E64D41986823@strayalpha.com>
References: <6EC6417807D9754DA64F3087E2E2E03E2D54D9D2@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
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] Open questions in draft-scharf-tcpm-yang-tcp-03
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, 29 Nov 2019 17:08:44 -0000

Hi, Michael,

> On Nov 28, 2019, at 10:37 AM, Scharf, Michael =
 wrote:
>=20
> [chair hat off]
>=20
> At IETF 106 there was not enough time left for Mahesh to present the =
latest update of the document "YANG Model for Transmission Control =
Protocol (TCP) Configuration".
>=20
> Mahesh, Vishal and me have significantly updated =
draft-scharf-tcpm-yang-tcp-03 since the last meeting. The changes are =
summarized in the slides that can be found at:
>=20
>   =
https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-yang-mo=
del-for-transmission-control-protocol-tcp-configuration-01
>=20
> Our proposal to refine the scope of the document. This results in at =
least 4 questions:
>=20
> 1. Should the model support statistics?

IMO, no - that should be a different, optional model (TCP-stats or =
something).

> 2. Should it model all TCP connections?

I don=E2=80=99t know what that means, even given the slides. I would =
expect there to be some common practice for this in YANG models, i.e., =
to describe how state is grouped by address.

> 3. Add support for TCP-AO?

It should include all current standards-track options IMO.

> 4. Add support for TCP-MD5?

For the reason above, this should not be included - it is deprecated by =
TCP-AO. If supported, it should be clearly identified as deprecated.

Joe=