From nobody Sun Jul 1 21:14:42 2018 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 8FB4B130E00; Sun, 1 Jul 2018 21:14:40 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153050488054.27349.1876886521545326995@ietfa.amsl.com> Date: Sun, 01 Jul 2018 21:14:40 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 04:14:41 -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 : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-10.txt Pages : 102 Date : 2018-07-01 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It updates RFC 5961 due to a small clarification in reset handling while in the SYN-RECEIVED state. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-10 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 04:51:47 2018 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 2E651130F72; Mon, 2 Jul 2018 04:51:39 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053229913.28022.7863509414342639235@ietfa.amsl.com> Date: Mon, 02 Jul 2018 04:51:39 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 11:51:45 -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 Filename : draft-ietf-tcpm-converters-02.txt Pages : 37 Date : 2018-07-02 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 Converter 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-02 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 Mon Jul 2 08:55:17 2018 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 B710813121D; Mon, 2 Jul 2018 08:54:50 -0700 (PDT) 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, 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 sVkxp3y_rjT1; Mon, 2 Jul 2018 08:54:37 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE0113120A; Mon, 2 Jul 2018 08:54:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41KBdh2dGRz15MyV; Mon, 2 Jul 2018 17:54:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0r2I4CF_7jB; Mon, 2 Jul 2018 17:54:30 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (mue-88-130-61-042.dsl.tropolys.de [88.130.61.42]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 2 Jul 2018 17:54:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 2 Jul 2018 17:54:28 +0200 Cc: "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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, 02 Jul 2018 15:55:01 -0000 Hi Micheal, I addressed a couple of your comments below.=20 For the other, bigger comments regarding extensibility, that I did not = yet address below, we plan to add a new section to the appendix to = explain extensibility options as previously discussed by mail. We will = probably send a separate email on that part. Mirja > Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - DE/Stuttgart) = : >=20 > Hi Mirja, >=20 > Thanks a lot for the explanation. I won't follow-up on some of the = editorial suggestions. >=20 > Yet, I continue to believe that some formal wording in the document = needs to change, as explained below.=20 >=20 > Thanks >=20 > Michael (with no hat on) >=20 >=20 >> -----Original Message----- >> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >> Sent: Monday, March 05, 2018 1:54 PM >> To: Scharf, Michael (Nokia - DE/Stuttgart) >> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>=20 >> Hi Micheal, >>=20 >> thanks for your feedback and sorry for my late reply. >>=20 >> Please see inline. >>=20 >>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - = DE/Stuttgart) >> : >>>=20 >>> Hi all, >>>=20 >>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix). = I >> believe this document needs further work before moving forward. >>>=20 >>> Please find below my comments marked as [ms]. I have read the >> document independent of the review from Gorry. I apologize if there = is >> duplication. >>>=20 >>> Thanks >>>=20 >>> Michael (with no hat on) >>>=20 >>>=20 >>> ****************************** >>>=20 >>> * Abstract: >>>=20 >>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or = Data >> Center TCP >>> (DCTCP) need more accurate ECN feedback information whenever more >>> than one marking is received in one RTT. >>>=20 >>> [ms] I don't think this statement is fully backed by RFC 8257. I = suggest to >> remove this, or replace it by a more generic statement that more = accurate >> information can be useful for several TCP extensions. >>=20 >> I disagree. Both ConEx and DCTCP need more accurate information. They = do >> not need the mechanism that is specified in this draft, however, this = is not >> what the sentences is saying. >=20 > In my understanding (as a non-native speaker), the use of the word = "need" is not correct here. DCTCP as specified in RFC 8257 can be = implemented without any such mechanism.=20 >=20 > What would work for me is something of the form "... Data Center TCP = cannot get precise ECN feedback whenever more than one marking is = received in one RTT=E2=80=9C. This is not correct. DCTP need more than one feedback signal per RTT and = therefore cannot use RFC3168; instead it implement it=E2=80=99s own = feedback mechanism. However, to avoid confusion such that people could = assume DCTP would not work without the accECN scheme as specified in = this doc, I rephrased to: "Recently, proposed mechanisms like Congestion Exposure (ConEx ), DCTCP or L4S need to know when more than = one marking is received in one RTT which is information that cannot be provided by the feedback scheme as = specified in ." >=20 >>> This document specifies an >>> experimental scheme to provide more than one feedback signal per = RTT >>> in the TCP header. Given TCP header space is scarce, it overloads >>> the three existing ECN-related flags in the TCP header and = provides >>> additional information in a new TCP option. >>>=20 >>> [ms] This statement needs to be rewritten to correctly reflect what = is >> requested from IANA. My understanding is that this experimental = document >> asks for allocation of a reserved TCP header flag. This needs to be = called out >> prominently, IMHO. In addition, since this is not a standard, the = suggested >> experimentation with the main TCP header must IMHO be explicitly >> mentioned. I also suggest to have later in a document a section that = explicitly >> explains why it is appropriate to modify the main TCP header in an >> experiment. >>=20 >> I don=E2=80=99t know if any requirement that IANA assignment need to = be called out >> in the abstract but we can do that. However, I believe the question = if this >> document should or should not assign the bit is still not completely = solved, or >> is it? >=20 > I believe this question will have to be reviewed during WGLC and, more = importantly, IETF last call. For the moment, my concern is that the = document correctly describes the IANA allocation. >=20 > I would like to see here a statement such as : "Given TCP header space = is scarce, this specification allocates a reserved header bit and = overloads the two ECN flags in the TCP header ...=E2=80=9C.=20 A bit lengthy but now: "Given TCP header space is scarce, it allocates a reserved header bit, that was previously = used for ECN-Nonce which was recently declared historic, and overloads the two existing ECN flags in the TCP header. Further, additional information can be provided in a new TCP option that however is = not used on the TCP SYN." >=20 >>> * 1. Introduction >>>=20 >>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>> more accurate ECN feedback information whenever more than one >> marking >>> is received in one RTT. >>>=20 >>> [ms] At least for RFC 8257 seems to be implementable withoit this. = Instead >> of stating a "need", it would IMHO make more sense to discuss the = benefits >> of the suggested mechanism in this document of its own, independent = of >> other proposals. To me, this document should be independent of other >> documents and specifically other experiments. We have to think about = cases >> where not all experiments are successful. Then independent documents = will >> be more future-proof in future. >>=20 >> This is a naming collision=E2=80=A6 The sentence was meant to say = that these >> mechanisms new more accurate ECN feedback than provided today by >> RFC3168 but it was not meant to say that these mechanism have to use = the >> scheme as specified in this document. >>=20 >> I added the following part sentence: >>=20 >> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure = (ConEx >> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need = more >> accurate ECN feedback information than provided by the feedback = scheme >> as specified in [RFC3168] whenever more than one marking is received = in one >> RTT. This document specifies an alternative feedback scheme that = provides >> more accurate information and could be used by these new TCP = extensions.=E2=80=9C >>=20 >> Does this help? >=20 > See my proposal for the abstract. I continue to disagree with the term = "need" but I think this can be sorted out by another term. >=20 >>> If AccECN progresses from experimental to the standards >>> track, it is intended to be a complete replacement for classic = TCP/ >>> ECN feedback, not a fork in the design of TCP. >>>=20 >>> [ms] This sentence should be removed, as this is speculation. >>=20 >> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent that = we have. >>=20 >>>=20 >>> Until the AccECN experiment succeeds, [RFC3168] will remain as the >>> standards track specification for adding ECN to TCP. >>>=20 >>> [ms] This sentence should be removed (or reworded) >>=20 >> Why? Does it help to add an only here: >>=20 >> "Until the AccECN experiment succeeds, [RFC3168] will remain as the = only >> standards track specification for adding ECN to TCP.=E2=80=9C >=20 > This wording is better. >=20 >>> AccECN feedback overloads flags and fields in the main TCP header >>> with new definitions, so both ends have to support the new wire >>> protocol before it can be used. >>>=20 >>> [ms] In my reading this experimental document asks for *new* = allocation >> of a reserved TCP header flag. >>=20 >> Is this better? >>=20 >> "AccECN feedback overloads the two existing ECN flags as well as the >> currently reserved and previously called NS flag in the main TCP = header >> with new definitions, so both ends have to support the new wire = protocol >> before it can be used.=E2=80=9C >>=20 >> I understand that you are not happy with the word =E2=80=9Eoverload=E2=80= =9C here but the >> point of this sentence really is that the flags can/could be used = differently >> and therefore we need a new negotiation before we can use them. >=20 > For me the following would work: "AccECN feedback overloads the two = existing ECN flags and=20 > allocates the currently reserved and previously called NS flag in the = main TCP header. > Given the new definitions, both ends have to support the new wire = protocol > before it can be used." >=20 > I believe the wording has to be crystal clear on the reservation of = bit 7 when it is discussed the first time in the text. In follow-up = sections, maybe shorter terms could be used. Okay, now: "AccECN feedback overloads the two existing ECN flags and allocates the currently reserved and previously called NS flag in = the TCP header, to be used as one field indicating the number of = congestion experienced marked packets. Given the new definitions of these three = bits, both ends have to support the new wire protocol before it can be = used. Therefore during the TCP handshake the two ends use these three bit = in the TCP header to negotiate the most advanced feedback protocol that they can both support in a backward compatible way to=20 ." >=20 >> If you prefer, we can also remove the NS flag in this list, as ECN = Nonce was >> anyway never deployed. >>=20 >>>=20 >>> For that we refer to [RFC3168] or any RFC that >>> specifies a different response to TCP ECN feedback, for example: >>> [RFC8257]; or the ECN experiments referred to in >>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low = Latency >>> Low Loss Scalable (L4S) congestion control = [I-D.ietf-tsvwg-l4s-arch]; >>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], = or >>> Alternative Backoff with ECN (ABE) >>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>=20 >>> [ms] At least ABE seems orthogonal. Anyway, I think this paragraph = can just >> be deleted. If other experiments need more accurate feedback, it is = up to >> them to explain how they would use this mechanism. This document = should >> focus on how to signal the feedback, not how to use that. >>=20 >> Yes, that is what the paragraph says. Isn=E2=80=99t it better to be = explicit about this? >>=20 >>>=20 >>> It is likely (but not required) that the AccECN protocol will be >>> implemented along with the following experimental additions to the >>> TCP-ECN protocol: ECN-capable TCP control packets and = retransmissions >>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable = SYN/ >>> ACK experiment [RFC5562]; and testing receiver non-compliance >>> [I-D.moncaster-tcpm-rcv-cheat]. >>>=20 >>> [ms] I am a big fan of simple, standalone documents. In my view, the = TCPM >> working group should publish draft-ietf-tcpm-accurate-ecn and = draft-ietf- >> tcpm-generalized-ecn independent documents, which probably implies = that >> draft-ietf-tcpm-generalized-ecn does not use AccECN. If = experimentation >> with ECT in SYN requires a combination, this could be done in a new, = third >> document. Apart from having simpler focused documents, this could >> significantly help later with moving forward documents to standards = track. >>=20 >> I disagree, however, this is a discussion to have on draft-ietf-tcpm- >> generalized-ecn. I don=E2=80=99t see a problem in providing a = reference here that >> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>=20 >>>=20 >>>=20 >>> * 1.1. Document Roadmap >>>=20 >>> [ms] A macroscopic comment is that this document has a lot of = introduction >> and tutorial text with lot's of redundancy towards other documents. I = think >> the document can be made much easier to read by shorten it. In many = cases >> this is just an editorial change as there is redundancy. As one such = example, >> just remove this section. >>=20 >> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan of = short and concise >> documents, however, some redundancy can also help understanding, >> especially if you explain things multiple times but with a different = level of >> detail. I personally would not need the roadmap but I know many = people >> who find these things helpful and to be honest I don=E2=80=99t see = how removing this >> part makes the doc any better. If you don=E2=80=99t want it, don=E2=80=99= t read it. >>=20 >>>=20 >>>=20 >>> * 1.2. Goals >>>=20 >>> [ms] I think this section can also just be removed. >>=20 >> I have to say I also don=E2=80=99t see the point of removing this = part. Given we=E2=80=99ve >> done the work on requirements, I think we should also link to this = doc >> somewhere. >>>=20 >>>=20 >>> * 1.3. Experiment Goals >>>=20 >>> TCP is critical to the robust functioning of the Internet, = therefore >>> any proposed modifications to TCP need to be thoroughly tested. = The >>> present specification describes an experimental protocol that adds >>> more accurate ECN feedback to the TCP protocol. The intention is = to >>> specify the protocol sufficiently so that more than one >>> implementation can be built in order to test its function, = robustness >>> and interoperability (with itself and with previous version of ECN >>> and TCP). >>>=20 >>> [ms] I think all what is written in this paragraph is obvious, no? = Can't we just >> delete this? >>=20 >> Sure, however, I don=E2=80=99t think it hurts to spell it out. For me = both is fine, keep it >> or remove it. >>=20 >>>=20 >>> The experimental protocol will be considered successful if it is >>> deployed and if it satisfies the requirements of [RFC7560] in the >>> consensus opinion of the IETF tcpm working group. In short, this >>> requires that it improves the accuracy and timeliness of TCP's ECN >>> feedback, as claimed in Section 5, while striking a balance = between >>> the conflicting requirements of resilience, integrity and >>> minimisation of overhead. It also requires that it is not unduly >>> complex, and that it is compatible with prevalent equipment >>> behaviours in the current Internet (e.g. hardware offloading and >>> middleboxes), whether or not they comply with standards. >>>=20 >>> Testing will mostly focus on fall-back strategies in case of >>> middlebox interference. Current recommended strategies are = specified >>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>> these strategies depends on the actual deployment situation of >>> middleboxes. Therefore experimental verification to confirm = large- >>> scale path traversal in the Internet is needed before finalizing = this >>> specification on the Standards Track. >>>=20 >>> [ms] These two paragraphs must be entirely rewritten. As I have >> mentioned before, I don't think an RFC should speculate about TCPM = and its >> consensus opinion. I would suggest a wording along the lines of: >>>=20 >>> >>> The experimental protocol will be considered successful if >>> testing confirms that the proposed mechanism can be deployed at = large >> scale. >>> Testing will mostly focus on fall-back strategies in case of >>> middlebox interference. Current recommended strategies are = specified >>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>> these strategies depends on the actual deployment situation of >>> middleboxes. Therefore experimental verification to confirm = large- >>> scale path traversal in the Internet is needed, e.g., by support = in >>> major TCP stacks. >>> >>>=20 >> I don=E2=80=99t understand your point here. I don=E2=80=99t think = that the paraphrase >> speculates about the consensus of tcpm, in contrast it say tcpm has = to >> decided if the requirements previously specified by tcpm are = sufficiently >> fulfilled. I don=E2=80=99t see a reason to not mention the = requirement draft as this >> draft as tcpm consensus and was written for this purpose. >=20 > My suggested wording uses the expression "can be deployed at large = scale" and I believe this is relevant. >=20 > The document already describes in Section 5 how the protocol satisfies = the agreed requirements for a more accurate ECN feedback protocol = [RFC7560]. So, if the TCPM working group publishes this document with = the content of Section 5, I believe the TCPM working group already has = reached consensus that the protocol meets requirements. In addition, it = is possible that new requirements would be identified in future, e.g., = as an outcome of the experiment, and that would obviously have to be = considered by TCPM. In that case, for the success of the experiment not = only RFC 7560 would matter, but also further requirements. My proposed = wording does not have all these problems. >=20 > In a nutshell, I continue to believe that this section has to change. Okay, used your proposed wording. You have a point about the requirement = and I mis-read you proposal earlier as =E2=80=9Ehas to be deployed = large-scale=E2=80=9C. >=20 >>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>=20 >>> [ms] This section could probably be shortened as well. >>>=20 >>> The last bit in byte 13 of the TCP header was defined as the Nonce >>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deployed = so >>> it is being reclassified as historic, making this TCP flag = available >>> for use by the AccECN experiment instead. >>>=20 >>> [ms] This wording, as well as Figure 1, needs to take into account = the IANA >> status when draft-ietf-tsvwg-ecn-experimentation is published. >>=20 >> Is does. However, I can explicitly say that is has be re-clssified as = reserved. >>=20 >> "RFC 3540 was never deployed so it is being reclassified as historic = [I-D.ietf- >> tsvwg-ecn-experimentation] and the respective flag has been marked as >> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags registry, = making this TCP flag >> available for use by the AccECN experiment instead.=E2=80=9C >>=20 >> Better? >>=20 >>> In my understanding, this experimental document asks for new = assignment >> of a reserved TCP header flag. >>=20 >> As I said I=E2=80=99m not sure if we have fully concluded this = discussion yet. However, >> what we really would want to is mention somewhere that this = experiment >> with this flags is running. I guess there are three options: >> 1) keep it in the registry as reserved and conserve the knowledge in = tcpm >> that this experiment is running and no other experimental RFC such = use this >> flags as long as this experiment is running. >> 2) Keep is marked as reserved but add a note about this experiment in = the >> IANA registry >> 3) Or assign it right away with IESG approval. I guess in this case = tcpm could >> also consider to change the registration policy to =E2=80=9EIETF = Review=E2=80=9C. >=20 > The current registration policy for the TCP header flags is "standards = action". I understand that the IESG could approve exceptions. But given = the policy, I believe the document has to be very precise on the request = regarding bit 7. Okay, it now says: "[TO BE REMOVED: IANA is requested to update the existing entry in the = Transmission Control Protocol (TCP) Header Flags registration = (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#= tcp-header-flags-1) for Bit 7 to "AE (Accurate ECN), previously used by = Historic as NS (Nonce Sum) [RFC3540, RFC8311]" and change the reference = to this RFC-to-be instead of RFC8311.]=E2=80=9C I guess we could also ask IANA to add an additional comment column = instead (but not sure if we then have to update RFC3168, which I think = we really don=E2=80=99t want. Should be fine now. >=20 >>> * 2. AccECN Protocol Overview and Rationale >>>=20 >>> o an essential part that re-uses ECN TCP header bits to feed back >>> the number of arriving CE marked packets. This provides more >>> accuracy than classic ECN feedback, but limited resilience = against >>> ACK loss; >>>=20 >>> [ms] The word "re-use" is IMHO not correct. >>=20 >> I think this is nit picking. Using a different phrasing here makes = the sentence >> unnecessary complicated. We don=E2=80=99t try to some how get a round = the fact >> that we need to handle the flag registration correctly. However, here = the >> point really is to explain how the protocol word. The main point of = using the >> work =E2=80=9Ere-use=E2=80=9C here is really that we say that these = flags are or have been >> used different by other TCP extension (and we therefore need a proper >> negotiation scheme). >=20 > If the allocation of a reserved flag is correctly explained in the = abstract and introduction, I think these sentences can use a bit relaxed = terminology. >=20 >>> The two part design was necessary, given limitations on the space >>> available for TCP options and given the possibility that certain >>> incorrectly designed middleboxes prevent TCP using any new = options. >>>=20 >>> [ms] IMHO it would make sense to more explicitly mention the = downsides >> of only specifying an option and not allocating a TCP header flag, in = this >> experimental document. >>=20 >> We need to use the flags (all three of them) for the negotiation. >=20 > I think that an explanation why negotiation by a TCP option would not = solve all use cases (or requirements) would help here. >=20 >>> The obvious alternative would be to postpone the header flag = allocation to >> a follow-up standards track document and just keep it reserved. >>=20 >> We can still do that. We should discuss and make a final decision. >>=20 >>>=20 >>> The essential part overloads the previous definition of the three >>> flags in the TCP header that had been assigned for use by ECN. = This >>> design choice deliberately replaces the classic ECN feedback >>> protocol, rather than leaving classic ECN feedback intact and = adding >>> more accurate feedback separately because: >>>=20 >>> [ms] Similar like previous comments, in my reading there are only = _two_ >> ECN header flags. >>=20 >> I think there are three flags that "had been assigned for use by = ECN=E2=80=9C as ECN >> Nonce is also an ECN mechanism. The fact that one of the flags is now >> marked as reserved instead, it not that important for me here. >>=20 >>> And, in addition, I think care is needed with wording such "replaces = the >> classic ECN feedback". I don't think this experiment replaces the ECN >> standards. That would be up to a follow-up PS. >>=20 >> This sentence is not meant to say that RFC3168 is replaced. Actually = we don=E2=80=99t. >> You can still use RFC3168 even if AccECN is implemented and deploy >> (however, we do intent that AccECN will be used as the default scheme = in >> future and RFC3168 is hopefully simply not needed anymore at some = point, >> even though you probably still need to have it implemented as the >> negotiation specified in this draft covers that as well, anyway...). = The >> sentence says that if AccECN is negotiation, the header flags as used = by >> RFC3168 and previously ECN Nonce are used differently (aka re-used). = That=E2=80=99s >> all. >>>=20 >>>=20 >>> 2.1. Capability Negotiation >>>=20 >>> AccECN is a change to the wire protocol of the main TCP header, >>> therefore it can only be used if both endpoints have been upgraded = to >>> understand it. The TCP client signals support for AccECN on the >>> initial SYN of a connection and the TCP server signals whether it >>> supports AccECN on the SYN/ACK. The TCP flags on the SYN that the >>> client uses to signal AccECN support have been carefully chosen so >>> that a TCP server will interpret them as a request to support the >>> most recent variant of ECN feedback that it supports. Then the >>> client falls back to the same variant of ECN feedback. >>>=20 >>> [ms] As this is an experimental specification, I would really like = to see a >> discussion how a future standards track version of more accurate ECN = could >> be negotiated. >>=20 >> As described in this draft. There will be no different. AccECN IS and = will >> always be backward compatible with RFC3168. >=20 > That is not the problem I think about. I wonder about a PS version of = accurate ECN feedback that would possibly include changes as compared to = this experiment, e.g., because the experiment may have some lessons = learnt. What options would we have to negotiate the PS version, and how = could a stack implementing the PS version figure out whether the remote = end uses the experimental or the PS version of the protocol? >=20 > The reason why I ask is because I don't see any easy solution to this = but I may miss something. Maybe this would not be a concern if there = were some codepoints left. >=20 >>> How could both endpoints detect whether the other one implements the >> future standards track version? >>=20 >> If the initiator implements AccECN it will request it=E2=80=99s use. = If the receiver also >> implement it, it will/can negotiate it, if not it will look like an = RFC3168 request >> for the receiver (as the NS flags will be ignored in the SYN) and it = will >> negotiate RFC3168 ECN feedback if implemented. There is no additional >> detection needed. >=20 > My concern is the migration strategy for a future version, given that = we only experiment right now. For instance, if the initiator implements = the experimental version but the recipient implements the PS version of = AccECN, how would that work? Under the assumption that there are = changes, would there be a way to know? Maybe the answer to this question = is no, given the small number of bits we have. But not having any room = for extensions is not necessarily good protocol design. >=20 >>> For instance, would the only safe variant be that we allocate yet = another >> reserved TCP header flag in a proposed standard to negotiate the = standards >> track version, thus investing another reserved bit in the TCP header? >>=20 >> No, that=E2=80=99s exactly what we use the NS flags for in the = handshake. >=20 > If the PS version of AccECN was different to the experimental version = of AccECN, and if there was a deployed base of both, I still believe we = could end up in a situation in which we had to allocate yet another TCP = header flag to distinguish the different versions of AccECN. The NS flag = would not work for that if it is used by the experimental version. The = risk of having to spend further TCP header flags somehow concerns me. Of = course, that problem would only matter if the AccECN experiment succeeds = somehow, but lessons learnt would require protocol changes, which is = speculation. >=20 >>> I may be wrong, but to me it is too early to speculate how the PS = version >> would look like, and whether it would have to be different to the >> experimental version, due to lessons learnt. >>=20 >> Of course you can always be wrong. However, the handshake negotiation = is >> not the part we need experimentation for. That part is straight = forward and >> works. If we really happen to detect a problem in that part, we would = need >> to end the experiment declare failure and start over new. >=20 > My concern is ending the experiment when the experiment got (partly) = deployed in the Internet. In that case neither a new RFC nor a change of = the IANA registry will solve the migration issue. >=20 >>> I believe in the IETF we typically design protocols that allow = future >> extension, and it is not exactly clear to be how AccECN could be = extended >> later. >>=20 >> This is an TCP extension. If we want future extension we use the = usually TCP >> mechanism (by defining a new TCP option I guess). >=20 > The root cause of my concern is that this proposal does *not* use the = usual way to experiment with TCP by options. It experiments with a = header flag, including in the SYN, and it seems to consume all = codepoints. So, I see the risk of a protocol design "not ready for = future improvements". >=20 > I cannot easily propose text. Maybe "lack of extensibility" is just = one of the short-comings of the protocol design that cannot be avoided = but that short-coming would have to be noted.=20 >=20 >>> An AccECN TCP client does not send the new AccECN Option on the = SYN >>> as SYN option space is limited and successful negotiation using = the >>> flags in the main header is taken as sufficient evidence that both >>> ends also support the AccECN Option. The TCP server sends the = AccECN >>> Option on the SYN/ACK and the client sends it on the first ACK to >>> test whether the network path forwards the option correctly. >>>=20 >>> [ms] For what it is worth, I would personally be quite fine with = allowing (or >> even mandating) an option in the SYN in the experimental version of = this >> protocol. For instance, saving the SYN option space would then an = excellent >> reason for moving towards the PS specification. I am also fine with = being in >> the rough part of the consensus here. >>=20 >> The point is that we really don=E2=80=99t need the option in the SYN = as we don=E2=80=99t use it >> for negotiation purposes as we use the header bits instead. So why = should >> we waste the space? >=20 > For instance, mandating the option in the SYN would be away for the = receiver to distinguish the experiment from a follow-up PS version of = the spec, as the PS version may not mandate the option, to save header = space. >=20 > Maybe that proposal does not make any sense, and it may only have = downsides. But the document already speculates about a PS-follow-up. So = it seems a valid question to ask if the EXP and the PS version of the = spec have to be identical. This all comes down to the SYN negotiation.=20= >=20 >>> * 2.3. Delayed ACKs and Resilience Against ACK Loss >>>=20 >>> If the AccECN Option is not available, e.g. it is being stripped = by a >>> middlebox, the AccECN protocol will only feed back information on = CE >>> markings (using the ACE field). Although not ideal, this will be >>> sufficient, because it is envisaged that neither ECT(0) nor ECT(1) >>> will ever indicate more severe congestion than CE, even though = future >>> uses for ECT(0) or ECT(1) are still unclear >>> [I-D.ietf-tsvwg-ecn-experimentation]. >>>=20 >>> [ms] This needs to be reworded >>=20 >> Why? >>=20 >>>=20 >>>=20 >>>=20 >>> * 2.4. Feedback Metrics >>>=20 >>> The CE packet counter in the ACE field and the CE byte counter in = the >>> AccECN Option both provide feedback on received CE-marks. The CE >>> packet counter includes control packets that do not have payload >>> data, while the CE byte counter solely includes marked payload = bytes. >>> 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 DCTCP or ConEx. >>>=20 >>> [ms] I suggest to write in the last sentence only "... the option = will provide >> the more accurate information needed for congestion control". In = general, I >> would prefer to have references to other mechanisms at only few = (ideally a >> *single*) places in the document, instead of mixing them together. >>=20 >> Sorry, I don=E2=80=99t see your point here. ConEx has been mentioned = previously, so >> why not also mention it here. >=20 > As written earlier, in my understanding DCTCP does not "need" this. I = would suggest to have one place where to define exactly how this = mechanism can be used by other TCP extensions. Having said this, in this = specific paragraph I am less concerned about that than elsewhere. >=20 >>> Feedback in bytes is recommended in order to protect against the >>> receiver using attacks similar to 'ACK-Division' to artificially >>> inflate the congestion window, which is why [RFC5681] now = recommends >>> that TCP counts acknowledged bytes not packets. >>>=20 >>> [ms] At least the last part and the reference to RFC 5681 is IMHO = not >> needed here. >>=20 >> Why? RFC5681 explains/refers the ACK division attack, so I think it = is a very >> good reference to have here. >>>=20 >>>=20 >>>=20 >>> * 2.5. Generic (Dumb) Reflector >>>=20 >>> The ACE field provides information about CE markings on both data = and >>> control packets. According to [RFC3168] the Data Sender is meant = to >>> set control packets to Not-ECT. However, mechanisms in certain >>> private networks (e.g. data centres) set control packets to be ECN >>> capable because they are precisely the packets that performance >>> depends on most. >>>=20 >>> For this reason, AccECN is designed to be a generic reflector of >>> whatever ECN markings it sees, whether or not they are compliant = with >>> a current standard. Then as standards evolve, Data Senders can >>> upgrade unilaterally without any need for receivers to upgrade = too. >>> It is also useful to be able to rely on generic reflection = behaviour >>> when senders need to test for unexpected interference with = markings >>> (for instance [I-D.kuehlewind-tcpm-ecn-fallback] and >>> [I-D.moncaster-tcpm-rcv-cheat]). >>>=20 >>> The initial SYN is the most critical control packet, so AccECN >>> provides feedback on whether it is CE marked. Although RFC 3168 >>> prohibits an ECN-capable SYN, providing feedback of CE marking on = the >>> SYN supports future scenarios in which SYNs might be ECN-enabled >>> (without prejudging whether they ought to be). For instance, >>> [I-D.ietf-tsvwg-ecn-experimentation] updates this aspect of RFC = 3168 >>> to allow experimentation with ECN-capable TCP control packets. >>>=20 >>> [ms] To me, the only thing that matters in this document that AccECN = can >> provide feedback on whether the SYN is CE marked. The discussion on = how >> to experiment with ECT e.g. in SYNs IMHO does not belong into this >> document. So it seems sufficient here to note that one of the = benefits of >> AccECN is that CE marks in SYNs can be fed back. >>=20 >> I disagree. Explicitly saying that AccECN is only an feedback scheme = and DOES >> NOT define how the information is used is VERY important because = people >> come back to me over and over again and mix these things up. >>>=20 >>>=20 >>> * 3.1.1. Negotiation during the TCP handshake >>>=20 >>> Given the ECN Nonce [RFC3540] is being reclassified as historic, = the >>> present specification renames the TCP flag at bit 7 of the TCP = header >>> flags from NS (Nonce Sum) to AE (Accurate ECN) (see IANA >>> Considerations in Section 6). >>>=20 >>> [ms] As mentioned before, this needs to be rewritten to ask for new = IANA >> allocation of bit 7 in the TCP header flags. >>=20 >> I really don=E2=80=99t understand this comment. That is what the IANA = section does >> as referred here correctly. >=20 > In my reading of = https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml, = this flag currently has no name, i.e., it does not have the name NS. So = this statement on "renaming" is formally incorrect IMHO. >=20 > I'd suggest something like: "This specification assigns the name AE = (Accurate ECN) to the TCP flag at bit 7; this flag has previously been = known as NS (Nonce Sum) =E2=80=A6". Now: "Given the ECN Nonce has been reclassified as historic , the = present specification re-allocates the TCP flag at bit 7of the TCP header flags, which was previously = called NS (Nonce Sum), as the AE (Accurate ECN) flag (see IANA Considerations in )." >=20 >> Again, yes, we can discuss if this document should do this, but if = published as >> it is, section 6 says everything that is needs to say. (I does not = put any >> request on IANA, instead it is written as it would show up = post-publication, >> implicitly providing a request to IANA at approval time. That is = fine.) >>=20 >>>=20 >>> Table 2: ECN capability negotiation between Client (A) and Server >>> (B) >>>=20 >>> [ms] As far as I can see, in -05 this table allocates all existing = codepoints, >> while -03 had two currently unused codepoints. Not having any = codepoints >> left seems to me not really future proof, e.g., regarding future = proposed >> standards in this space (and I personally believe that TCP header = flags must >> be allocated in a PS). And I don't fully see a need of feeding back = ECT0 and >> specifically ECT1 in the TCP header flags as part of the experiment. = Do we >> know for sure that this is the only possible use case of these two = unallocated >> header bits? And why can't e.g. this be done in a TCP option instead? = Or do I >> miss something? >>=20 >> The point is really, if we don=E2=80=99t assign them now and start = deployment we >> effetely we not be able to every assign them again because don=E2=80=99= t have a >> different negotiation mechanisms. Realizing this, it is just the = right think to >> define the space completely that is negotiated as use for AccECN in = the >> handshake. >=20 > I disagree that consuming all codepoints and not having room for = future extensions is the "right thing" to do. It is in fact the wrong = thing. But possibly there is no alternative with the few bits, so maybe = we end up doing it. >=20 > Yet, at minimum, using all codepoints needs to be reasoned in the = document. Specifically since in -03 a different protocol design seemed = possible, which looked to me more future-proof. >=20 >>> * 3.1.2. Retransmission of the SYN >>>=20 >>> However, >>> current measurements imply that a drop is less likely to be due to >>> middlebox interference than other intermittent causes of loss, = e.g. >>> congestion, wireless interference, etc. >>>=20 >>> [ms] Such wording IMHO doesn't belong into normative text. This may >> actually also apply to other heuristics discussed in this section, = which are not >> really important for interoperability. >>=20 >> I don=E2=80=99t really understand your point. This sentence is solely = meant to reason >> the design decision to not say that a sender SHOULD attempt to re- >> negotiation after a loss. >=20 > One could split the reasoning from the normative design. The normative = specification may still be relevant in 20 years from now. Middleboxes = will almost likely be different in 20 years. Having said this, this is = more of an editorial remark. >=20 >>> 3.2.7. Path Traversal of the AccECN Option >>>=20 >>> 3.2.7.1. Testing the AccECN Option during the Handshake >>>=20 >>> The TCP client MUST NOT include the AccECN TCP Option on the SYN. >>>=20 >>> [ms] I am not sure if I really understand the motivation for not = allowing a >> option in the SYN. If the sender has space in the SYN left, what is = the harm in >> an experimental version of the protocol? And I may miss something, = but >> what would prevent the use of 2-byte option to negotiate the use of >> AccECN, e.g., to avoid experimental allocation of bit 7 in the = initial SYN? >>=20 >> I did have a draft on that as a proposal for an alternative design. = However, >> the gourd was more supportive of this design as it is proof of = middlebox SYN >> option mangling which is a know problem. >>=20 >> Therefore we simply don=E2=80=99t need option in the SYN and there is = no reason to >> waste the space. >>=20 >>> While I think many tutorial text in this document could be = shortened, I >> believe the use of a reserved TCP header flag should be reasoned. >>=20 >> I=E2=80=99m actually uncertain what you expect here. >=20 > For instance, this reply with the explanation of SYN option mangling = seems useful explanation. >=20 >>> * 3.2.8. Usage of the AccECN TCP Option >>>=20 >>> The following rules determine when a Data Receiver in AccECN mode >>> sends the AccECN TCP Option, and which fields to include: >>>=20 >>> Change-Triggered ACKs: 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, >>> without waiting for the next delayed ACK (this is in addition = to >>> the safety recommendation in Section 3.2.5 against ambiguity of >>> the ACE field). >>>=20 >>> This is stated as a "MUST" so that the data sender can rely on >>> change-triggered ACKs to detect transitions right from the very >>> start of a flow, without first having to detect whether the >>> receiver complies. A concern has been raised that certain = offload >>> hardware needed for high performance might not be able to = support >>> change-triggered ACKs, although high performance protocols such = as >>> DCTCP successfully use change-triggered ACKs. >>>=20 >>> [ms] To me this sounds like a perfect example for a SHOULD with = additional >> guidance why implementing this SHOULD is really important. >>=20 >> This is one of the most discussed point from the author and we really = tried to >> get additional guidance here of what to do also from outside the IETF = but did >> no clear feedback. >>=20 >> As explained this MUST enables additional functionality. However, = this is an >> experiment document. If we detect that this MUST does actually hinder >> implementation or has just never been implemented, we should = reconsider >> this in the final PS RFC. >>=20 >> I was on the SHOULD side of the discussion, but can say that the >> implementation in Linux was way more simple then expected. Offloading >> might be a different topic but that is where I could not get a clear = feedback >> and offloading could probably be anyway optimized for use with AccECN = (if it >> gets deploy widely). >=20 > If a MUST requires changes in hardware, I think there must be a clear = reason. >=20 > As individual contributor, with the current explanation in the text, I = believe this has to be a SHOULD. >=20 >> I though we added this as something to mention in the exp goals = section, but >> obviously we didn=E2=80=99t. I added the following text now: >>=20 >> "Another experimentation focus is the implementation feasibiliy of = change- >> triggered ACKs as described in section 3.2.8. While on average this = should not >> lead to a higher ACK rate, it changes the ACK patter which especially = can have >> an impact on hardware offload. Further experimentation is needed to = advise >> if this should a hard requirement or just prefer behavior.=E2=80=9C >=20 > If it is unclear if a MUST can actually be implemented, having a MUST = is in my opinion the wrong approach. >=20 > One could equally state here that further experimentation is needed to = determine whether the SHOULD can be upgraded to a MUST. I=E2=80=99m still open for everything here, but I believe this was = discussed and agreed in the working group=E2=80=A6?=20 >=20 >>> For the avoidance of doubt, the change-triggered ACK mechanism is >>> deliberately worded to ignore the arrival of a control packet with = no >>> payload, which therefore does not alter any byte counters, because = it >>> is important that TCP does not acknowledge pure ACKs. The change- >>> triggered ACK approach will lead to some additional ACKs but it = feeds >>> back the timing and the order in which ECN marks are received with >>> minimal additional complexity. >>>=20 >>> [ms] The additional acks create network load. I think some wording = is >> needed on the tradeoff between information accuracy and network load. >> There are network environments in which any additional packet is very >> expensive (e.g., energy) and it is not clear to me how the protocol = design >> takes into account the potential overhead of additional ACKs. Maybe = this >> could be another reason for a SHOULD. >>=20 >> The above. However, this is not really an additional ACK because you = do >> delay the next one. Further experimentation needed. >=20 > The document states "lead to some additional ACKs". If that does not = increase network load, I think it has to be explicitly explained why the = ACK load is at most equal to a current TCP stack, in all potential = cases. If it can increases network load, it has to be reasoned why = increasing load (and risk of reverse congestion and the like) is worth = the effort. >=20 > I agree that this may be an area of experimentation, but I believe = then it has to be explained to implementers what the tradeoffs are. Added: "Especially, if only few CE marks occurred or multiple marks in a row, the additional = load will be low. Other, unexpected marking pattern could increase the = load significantly, however, investigating the additional load it = part of the proposed experimentation." >=20 >>> * 4.2. Compatibility with Other TCP Options and Experiments >>>=20 >>> AccECN is compatible (at least on paper) with the most commonly = used >>> TCP options: MSS, time-stamp, window scaling, SACK and TCP-AO. It = is >>> also compatible with the recent promising experimental TCP options >>> TCP Fast Open (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824]). >>>=20 >>> [ms] I would suggest the wording "... compatible with the = experimental >> TCP options ..." or even "... compatible with the TCP options =E2=80=A6= ". >>=20 >> These option are to experimental..? >=20 > "It is also compatible with the experimental TCP options TCP Fast Open = (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824])." would have same = technical meaning. Having said this, this is editorial only. >=20 >> The point of using =E2=80=9Ecommonly used=E2=80=9C was to say that we = checked on those as >> they seem important. Just because your favorite experiment option is = not >> listed here it doesn=E2=80=99t means it incompatible, we just = didn=E2=80=99t check. I=E2=80=99m okay to >> removed =E2=80=9Ecommonly used=E2=80=9C but I don=E2=80=99t think it = makes anything better. >>=20 >>>=20 >>> * 4.3. Compatibility with Feedback Integrity Mechanisms >>>=20 >>> [ms] Quite a bit in this section is experimental work, which IMHO >>> should be clearly emphasized. The one exception is=E2=80=A6 >>=20 >> I would really like to keep this section because integrity is usually = the fist >> question that come up when I present AccECN. Effectively these are = two >> independent topics, however, I really think it help people to = understand the >> whole picture if this is also discussed in this document. >>=20 >>>=20 >>> However, TCP-AO is often too brittle to use on many end-to-end >>> paths, where middleboxes can make verification fail in their >>> attempts to improve performance or security, e.g. by >>> resegmentation or shifting the sequence space. >>>=20 >>> [ms] I am not sure if deployment challenges of other options need to = be >> discussed in this document. >>=20 >> If we keep the discussion, I guess we should mention this as well. As = the doc >> clearly stated section 4 is not meant to be normative. >=20 > As far as I can see, there are use cases for TCP-AO where middleboxes = are simply not a problem, but it is exactly this sort of discussion that = may not be needed in this document. But I won't rat-hole on this comment = here. >=20 >>> Originally the ECN Nonce [RFC3540] was proposed to ensure = integrity >>> of congestion feedback. With minor changes AccECN could be = optimised >>> for the possibility that the ECT(1) codepoint might be used as an = ECN >>> Nonce . However, given RFC 3540 is being reclassified as historic, >>> the AccECN design has been generalised so that it ought to be able = to >>> support other possible uses of the ECT(1) codepoint, such as a = lower >>> severity or a more instant congestion signal than CE. >>>=20 >>> [ms] The discussion of RFC 3540 can probably be removed to a large = extent. >>=20 >> Unfortunately, please still think that ECN Nonce, even though is was = never >> deployed and doesn=E2=80=99t really work, is the only was to provide = integrity >> protection and we need it as a prerequisite to deploy ECN at all=E2=80=A6= i would >> really prefer to keep this in this non-normative part of the doc. >>=20 >>>=20 >>>=20 >>> * 6. IANA Considerations >>>=20 >>> [ms] I think this section needs to be rewritten to request a new = allocation >> of bit 7 of the TCP header flags. At least for the process I think it = would make >> sense to have somewhere in the document a comprehensive explanation = of >> why an experimental document requests a change of the main TCP = header, >> and why this cannot be avoided (most notably in the initial SYN) by = an >> alternative protocol design. >>=20 >> As I said previously this section is written as it would look like = after the >> allocation has happened with publication approval of the IESG. This = is fine. >>=20 >> Having a discussion about an experiment doc assigning a flag (or not) = is a >> question for tcpm as a whole and not specifically this document. How = do we >> envision to every use any further flags? We go to PS right away? Or = should >> we change the registration policy? For me the latter makes actually = more >> sense. However, if we don=E2=80=99t want/can to decide this now, we = also could go >> forward as it is with IESG approval. However, is this case it is also = not needed >> to explain this in the document. The responsible AD has to explain = this to the >> other IESG probably in the ballot or even better the shepherd could = provide >> these information in the write-up. >>=20 >>>=20 >>>=20 >>> * 9. Comments Solicited >>>=20 >>> Comments and questions are encouraged and very welcome. They can >> be >>> addressed to the IETF TCP maintenance and minor modifications = working >>> group mailing list , and/or to the authors. >>>=20 >>> [ms] This section is not needed IMHO >>=20 >> Yes, it will be removed before publication. >>>=20 >>>=20 >>> 10. References >>>=20 >>> [I-D.ietf-tsvwg-ecn-experimentation] >>> Black, D., "Relaxing Restrictions on Explicit = Congestion >>> Notification (ECN) Experimentation", = draft-ietf-tsvwg-ecn- >>> experimentation-07 (work in progress), October 2017. >>>=20 >>> [ms] Normative reference? >>=20 >> Don=E2=80=99t see why. No need to read ietf-tsvwg-ecn-experimentation = to >> understand the spec in this doc. >>=20 >> Thanks! >> Mirja >>=20 >=20 From nobody Mon Jul 2 14:00:02 2018 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 913D91312DA; Mon, 2 Jul 2018 14:00:00 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153056520054.16259.14729166400166911333@ietfa.amsl.com> Date: Mon, 02 Jul 2018 14:00:00 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 21:00:01 -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-04.txt Pages : 29 Date : 2018-07-02 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-04 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 Mon Jul 2 15:50:08 2018 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 2F144131229; Mon, 2 Jul 2018 15:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057180013.16161.7596417123654378130@ietfa.amsl.com> Date: Mon, 02 Jul 2018 15:50:00 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 22:50:08 -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 : More Accurate ECN Feedback in TCP Authors : Bob Briscoe Mirja Kühlewind Richard Scheffenegger Filename : draft-ietf-tcpm-accurate-ecn-07.txt Pages : 45 Date : 2018-07-02 Abstract: Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the end-points. Receivers with an ECN- capable transport protocol feed back this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently, new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document specifies an experimental scheme to provide more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit, that was previously used for the ECN-Nonce which has now been declared historic. It also overloads the two existing ECN flags in the TCP header. Supplementary feedback information can optionally be provided in a new TCP option, which is never used on the TCP SYN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-07 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 Jul 3 02:30:23 2018 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 D90A4131208 for ; Tue, 3 Jul 2018 02:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 tz-aem8eDnxA for ; Tue, 3 Jul 2018 02:30:16 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70719130E36 for ; Tue, 3 Jul 2018 02:30:16 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C4345340F31; Tue, 3 Jul 2018 11:30:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.32460); Tue, 3 Jul 2018 11:30:14 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 3 Jul 2018 11:30:14 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 60167029; Tue, 03 Jul 2018 11:30:14 +0200 From: "Brian Trammell (IETF)" Message-Id: <6DFC0BD8-CE70-4412-9EB3-8FBE56EFF5A9@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_105C285E-B913-4C30-9DEF-E3ECD9FA781D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 11:30:12 +0200 In-Reply-To: Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" To: Yoshifumi Nishida References: <3b6c1b5f-766c-12e1-5fa9-35e369042120@gmx.at> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 09:30:22 -0000 --Apple-Mail=_105C285E-B913-4C30-9DEF-E3ECD9FA781D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Yoshi, all, I'm intrigued in general by the possibility of disabling PAWS in certain = circumstances, but (not just as a co-author of the TS negotiation draft = Richard mentions ;) ) am also concerned about the secondary effects of = shutting down timestamps, especially on passive latency measurement. On the other hand, the current timestamp facility is both high-overhead = and leaks a fair amount of information about the identity of the sending = host (by exposing clock drift in the simplest of implementations), so = alternatives would be useful, even in the case that one only cares about = passive measurability. There would be another way to disable PAWS while supporting passive = latency measurement and addressing issues with timestamps as presently = exposed: add a latency spin signal (i.e., the QUIC spin bit) to TCP in = the three reserved bits next to the to-be-reassigned nonce sum. See = https://tools.ietf.org/html/draft-trammell-tsvwg-spin. This is only a semi-serious suggestion at this point: we wrote this up = mainly since we (well, Mirja did all the implementation) had already = added it to TCP in order to have a stable platform for experimenting = with passive measurement techniques for the signal itself, as QUIC = remains under construction. But it's not a *terrible* idea, especially = if a consensus emerges that selectively disabling PAWS is also not a = terrible idea. (more inline) > On 27 Jun 2018, at 06:05, Yoshifumi Nishida = wrote: >=20 > Hi Richard, >=20 > On Mon, Jun 25, 2018 at 2:32 AM, Scheffenegger, Richard = wrote: > Hi Yoshifumi, Neal, >=20 >=20 > Am 23.06.2018 um 01:23 schrieb Yoshifumi Nishida: >=20 > My intention is to relax the requirement "The TSopt MUST be sent in = every non- segment for the duration of the connection" in RFC7323 > so that TSopt can be sent at arbitrary intervals. Arbitrary intervals = can contain infinite interval, but you can only do so when you really = want, otherwise you shouldn't. This relaxation would allow a fix for the average overhead problem, and = would reduce (but not eliminate) the data available for drift-based = fingerprinting approaches, so IMO it's equivalent in utility to the spin = bit, with the advantage that it doesn't use weird new flags in the = header (and the disadvantage that it changes the semantic of an old = option in ways that certain middleboxes might not like)... > So, disabling TS entirely is just an option. >=20 >=20 > > =46rom my perspective, one huge advantage from disabling PAWS is = that it > > enables the timestamps to be an opaque identifier, so that the = sender > > can use them in any way it chooses. In particular, it would allow = the > > sender to use microsecond timestamps, without worrying about the > > remote side dropping packets due to PAWS checks. This was the = main > > challenge we found in implementing microsecond TCP timestamps = inside > > Google datacenters, as we discussed at TCPM a while back (slide = 6): >=20 > [...] >=20 > > > My main comment would be, if some proposal is going to > > > standardize a negotiation scheme for using timestamps but > > > disabling PAWS, IMHO there could be huge value in having that > > > negotiation mechanism optionally specify the semantics of a > > > sender's timestamp values, so that congestion control and > > > passive monitoring tools could make use of the timestamps > > > for bandwidth and latency measurements. This could be > > > something as simple as 2 bits, e.g.: > > > > > > bits : meaning > > > 00: traditional RFC 7323 timestamps: use PAWS > > > 01: microsecond timestamps, disable PAWS > > > 10: millisecond timestamps, disable PAWS > > > 11: values with other semantics, disable PAWS >=20 (not sure who i'm replying to here -- apple/gmail incompatibilities) > TSopt is today semi-opaque - a receiver can not rely on timestamps to = have a specific granularity or monotonicity today. No, but in most implementations constant granularity (driven from some = time or interrupt counter) still holds, no? > It seems to me, that two paths should be discussed here: making TSopt = completely opaque - that is, disallowing the receiver to make any use of = it, only allowing it to be a signal from the sender in the past (1RTT) = to the sender in the future. by "disallowing" do you mean "a sternly worded MUST" or do you mean = "encryption"? One of these will work better than the other. ;) > Or making it more transparent, but disabling PAWS - meaning that the = content of TSopt can actually be interpreted by a receiver, potentially = allowing additional capabilities (one-way delay variation measurement, = "TCP Chirp", springs to mind). I'm obviously more of a fan of this approach. Cheers, Brian > Provided the clock granularity is fine enough, both points (unique = packet identifier, and allowing fine-grained timing data to be = extracted) could be done. >=20 > Some of these functionalities were touched upon in this draft some = time ago: > = https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation= -05 >=20 > Yep, signaling mechanism to change the semantics of TS is an = interesting point for discussions. > We can extend TS option like you proposed in the draft or integrating = into existing negotiation mechanisms or developing a new option. > Developing a new option seems to be a straightforward approach, but it = will consume extra option space and may be discarded by middleboxes. >=20 > BTW, the draft above is cited in the draft as a good starting point of = discussion. > -- > Yoshi >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_105C285E-B913-4C30-9DEF-E3ECD9FA781D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAls7QiQACgkQihK3vwvq RqNcWBAAqnHbAeg/GAJ1LaVXmuwxv8rqypaJMSJlTzw7ejINOjPNPys3QvXkWrkn bjuKsJKXF689zKNmwABIAHJvoodvaEURPWIrAlg6YGngOaI+vzQptyy9M0ouexwP tARlAFiQO+awXiznLiZDykKIZCY8UcCrMzIM7qkpqJUXqEijhmXoe7xP99BedcKv 2vwamFXKRZLZvQ7Ifsw+aTkioyFRX8qpwn/lgYVtOEjOH3T6BdTPzpLkgQKsnq3v lBidQTrBbcG1ysYk2ceIOojTtIMsuOldaUfaOQwBllVvsgerbjqlRAIYor2sT8Gy af6wtYcmdvuyG5ACsZeqqiopCNan3X4GvvHHVk36y9ELJw3DFGkFSQZH+/L/yVae Ac+/cv3q4qARtfDhca4yyQp2FbO30g5UekuTsUbFzMEjNIOTqH8rtoo0JjqaTogG N7t21DP8eDk2eQYsJlA4A0E7E2s2mZ1mKPazBEjQhN2HhtIoS7JYhuYSkxtJPrOw 77zNKkavrBOMbcccXsdImLhbcwXXzJWNZt5QBDzqupXEbMbkg5mdDWdzQ5HtH3Hq gxqTuRXU0DrOzmZf1KZRHuSsKrN0DnlMBckfGrfV0E4wxFDFPwyxOyRuHodaysRR LDdy60SO45ErsBpT2w7Y20jMj77faxKvXoBG+cJ8uO5xiXaxhCY= =UHP7 -----END PGP SIGNATURE----- --Apple-Mail=_105C285E-B913-4C30-9DEF-E3ECD9FA781D-- From nobody Tue Jul 3 05:23:53 2018 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 73CF4130E8F for ; Tue, 3 Jul 2018 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham 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 aMsk9fub1H4w for ; Tue, 3 Jul 2018 05:23:50 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 E7E13130E84 for ; Tue, 3 Jul 2018 05:23:49 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id f18-v6so1301358qtp.10 for ; Tue, 03 Jul 2018 05:23:49 -0700 (PDT) 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-transfer-encoding:content-language; bh=IvxYvTgv2ISKtL78g4yGZXEYKmQhhGvWYr3uJxyAs2Q=; b=HTccu3IH8/OCdhtkYhiNMhqmu2s9Lrs7nrkeaFLqpEA4ssezq/8xXogs/HKZzPXL4N vLMJr6nkWPm+YJRC8npExgg7B+0sW4vhYsICrkRgxzYC8bjnwdg2Vra5EXZNS81oOFqt ZrpOVMGpuEZ3ROnY3iAaPVFoR0RMmHMfk4ha2wbWMQVbXNZWA+fcs5G0nqNbUpR7A5Vo LkDxh+JPzNF4EIo9f/Q9i965t2nL9vVp87uNnvJSPLqYFAGUV53uEp9FCAVpkcR6G9SP o8hh5YiHI5t6W2OPmu5pCy5t9vKhdK0HM+C+EnyWUg5vOO7G8RQkmy0QCLfT4jnE78Oe QPWA== 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-transfer-encoding :content-language; bh=IvxYvTgv2ISKtL78g4yGZXEYKmQhhGvWYr3uJxyAs2Q=; b=Qjr0qp20zWG9MSVI/Yul+jmbsLPTfYGC8Ijwwp/rjfSd/BLUDoqtzEYjXI3PhQZU6k DG+ddkSKMKX7Ob1LxbKqw5fxB1f8DFHheWfT9/qB24kZHlcsJYHT1fwKRHUQOTEzNwyo I6rh4d6pd8zfKdqxJWCKODtGzPrUJr2wKbyqTzsizgBVoiZRDS5MoJRUWSTvT8aNiYV7 fg0iDxhuS2h+s+WxLrle4JZqmh659Q2zQJP+Q7/fYLMmrnli3W5iyjsRKZan1iyPSQQw Y0DVTHBMr1Jdy9q4zVaxTxr+RioCAr2GpUji7MtPTfMDMOwECE3UvqFmWl6bChq1sOId DsiA== X-Gm-Message-State: APt69E2weS3Nndl7pNhkG3VjCdRrkyvysBMhXdQ92X1fJFDTd5mCmADW iLKUq9b5reeAZS0xnHfKS/WRsZkKY0k= X-Google-Smtp-Source: AAOMgpe8rE9j2r/6u5V+FUOcyNuTmblv3rB/jSoDrQym1aS6kGAyQJOO7uvrVs8/FeomRpGzV9fQ7Q== X-Received: by 2002:a0c:90e1:: with SMTP id p88-v6mr25993406qvp.145.1530620628927; Tue, 03 Jul 2018 05:23:48 -0700 (PDT) Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id 18-v6sm667896qtw.43.2018.07.03.05.23.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 05:23:48 -0700 (PDT) To: tcpm@ietf.org References: <153050488054.27349.1876886521545326995@ietfa.amsl.com> From: Wesley Eddy Message-ID: <6fc34b38-0dd5-7f84-1394-c5131eeb14bc@mti-systems.com> Date: Tue, 3 Jul 2018 08:23:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153050488054.27349.1876886521545326995@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 12:23:53 -0000 This is a small update that mainly attempts to address: - comments from Yuchung and Gorry about attempts in the previous revisions to replace obsoleted TOS with DiffServ - comments from Joe on security considerations Comments, critiques, and corrections are welcome! On 7/2/2018 12:14 AM, internet-drafts@ietf.org 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 : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-10.txt > Pages : 102 > Date : 2018-07-01 > > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, > 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, > and should be considered as a replacement for the portions of that > document dealing with TCP requirements. It updates RFC 5961 due to a > small clarification in reset handling while in the SYN-RECEIVED > state. > > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-10 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 3 09:01:21 2018 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 0288D130F3C; Tue, 3 Jul 2018 09:00:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361200.4893.9298860021980793372.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:12 -0700 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 102 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:14 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:30 requested) Tuesday, 17 July 2018, Morning Session I 0930-1200 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/tcpm.ics Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 8 11:32:23 2018 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 A47A0130E8F for ; Sun, 8 Jul 2018 11:32:21 -0700 (PDT) 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_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 sgdJT9AveuPv for ; Sun, 8 Jul 2018 11:32:19 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48051310C7 for ; Sun, 8 Jul 2018 11:32:19 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BEB782783BC for ; Mon, 9 Jul 2018 03:32:17 +0900 (JST) Received: by mail-it0-f42.google.com with SMTP id a195-v6so22553587itd.3 for ; Sun, 08 Jul 2018 11:32:17 -0700 (PDT) X-Gm-Message-State: APt69E1AH+3k+kAIkvGpU5RxskR7lxsTwU6ezJhlA0PbnqAMpWJ/jQWk DMP3Cq5jXM76XctwePHMCiMFGFNvc3O2DZC5/V0= X-Google-Smtp-Source: AAOMgpeFsKHIfSq8tFyccs+dU1nXeSuInzjwjP839iMxO5v5uGCkX/qbJZtlOPhyWSWEoxA3bC8HnzGJ5IF8KV/bF9g= X-Received: by 2002:a24:78c9:: with SMTP id p192-v6mr14983188itc.143.1531074736227; Sun, 08 Jul 2018 11:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 11:32:15 -0700 (PDT) From: Yoshifumi Nishida Date: Sun, 8 Jul 2018 11:32:15 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] draft agenda has been uploaded X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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, 08 Jul 2018 18:32:22 -0000 Hi, I have uploaded current draft agenda on https://tools.ietf.org/wg/tcpm/agenda?item=agenda-102-tcpm-00.html We are having less items than usual now. This may mean it's a good chance for you to have longer discussion time than usual. If you are interested in presenting something, please let the chairs know. BTW, if you want to present something from remote, we'll set up meetecho for it. (but, please aware the deadline for reserving meetecho is 7/13) Thanks, -- Yoshi From nobody Wed Jul 11 11:00:43 2018 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 843B0130E40; Wed, 11 Jul 2018 11:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 QlVVwp0d_b86; Wed, 11 Jul 2018 11:00:36 -0700 (PDT) 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 724F8130DF2; Wed, 11 Jul 2018 11:00:35 -0700 (PDT) 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=QFdIOLCe97jNAv6I0S8M4r3YkvuieodYsPKXQI5BRhE=; b=mZ1ci15nD21Zu64fyN8jbySwCD udBN3hafrtf08ccWzqwTRp+BhLy5nwr422s3QcK4X+eC0KDiXsfq0uhVElfl5YUeIa+HO4+K+DUIn vLll5bOHmk2UQ11yqMCDo7z8xRuzho+766jkWWHR6EZDYixDPCVHL27KHA+Zds46naYV99rwRtO5y TK+/JNc7SDbLLRzX+tY1XySXLU9prxEo1Cpzt50YqdsPiAuh6d+oFE1FdDUGngJZag1Q3nSm6mtlm KR3tQcvjulgiKH8IF5MQ21iQYYchS+smd9Nms0uMmAZI1b+FsAAeoANbUOeC1j6c67SJuHIjzxAmY WX2Gj/QA==; Received: from 70.245.199.146.dyn.plus.net ([146.199.245.70]:49884 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fdJPk-00063I-TV; Wed, 11 Jul 2018 19:00:33 +0100 To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> From: Bob Briscoe Message-ID: Date: Wed, 11 Jul 2018 19:00:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 18:00:42 -0000 Michael, tcpm list, As well as addressing your points, as Mirja has already mentioned below, we added a whole new appendix giving the rationale for the bits and codepoints that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd subsection also identifies space for future evolution. It also points to where rationale was already given in the body of the draft. The appendix is in the draft submitted last week, available here: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B We'd be interested to hear whether this allays your concerns. We have asked to present this in Montreal as well. Cheers Bob On 02/07/18 16:54, Mirja Kühlewind wrote: > Hi Micheal, > > I addressed a couple of your comments below. > > For the other, bigger comments regarding extensibility, that I did not yet address below, we plan to add a new section to the appendix to explain extensibility options as previously discussed by mail. We will probably send a separate email on that part. > > Mirja > > >> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - DE/Stuttgart) : >> >> Hi Mirja, >> >> Thanks a lot for the explanation. I won't follow-up on some of the editorial suggestions. >> >> Yet, I continue to believe that some formal wording in the document needs to change, as explained below. >> >> Thanks >> >> Michael (with no hat on) >> >> >>> -----Original Message----- >>> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>> Sent: Monday, March 05, 2018 1:54 PM >>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>> >>> Hi Micheal, >>> >>> thanks for your feedback and sorry for my late reply. >>> >>> Please see inline. >>> >>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>> : >>>> Hi all, >>>> >>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix). I >>> believe this document needs further work before moving forward. >>>> Please find below my comments marked as [ms]. I have read the >>> document independent of the review from Gorry. I apologize if there is >>> duplication. >>>> Thanks >>>> >>>> Michael (with no hat on) >>>> >>>> >>>> ****************************** >>>> >>>> * Abstract: >>>> >>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or Data >>> Center TCP >>>> (DCTCP) need more accurate ECN feedback information whenever more >>>> than one marking is received in one RTT. >>>> >>>> [ms] I don't think this statement is fully backed by RFC 8257. I suggest to >>> remove this, or replace it by a more generic statement that more accurate >>> information can be useful for several TCP extensions. >>> >>> I disagree. Both ConEx and DCTCP need more accurate information. They do >>> not need the mechanism that is specified in this draft, however, this is not >>> what the sentences is saying. >> In my understanding (as a non-native speaker), the use of the word "need" is not correct here. DCTCP as specified in RFC 8257 can be implemented without any such mechanism. >> >> What would work for me is something of the form "... Data Center TCP cannot get precise ECN feedback whenever more than one marking is received in one RTT“. > This is not correct. DCTP need more than one feedback signal per RTT and therefore cannot use RFC3168; instead it implement it’s own feedback mechanism. However, to avoid confusion such that people could assume DCTP would not work without the accECN scheme as specified in this doc, I rephrased to: > > "Recently, proposed > mechanisms like Congestion Exposure (ConEx ), > DCTCP or L4S target="I-D.ietf-tsvwg-l4s-arch"/> need to know when more than one > marking is received in one RTT which is > information that cannot be provided by the feedback scheme as specified in > ." > > >>>> This document specifies an >>>> experimental scheme to provide more than one feedback signal per RTT >>>> in the TCP header. Given TCP header space is scarce, it overloads >>>> the three existing ECN-related flags in the TCP header and provides >>>> additional information in a new TCP option. >>>> >>>> [ms] This statement needs to be rewritten to correctly reflect what is >>> requested from IANA. My understanding is that this experimental document >>> asks for allocation of a reserved TCP header flag. This needs to be called out >>> prominently, IMHO. In addition, since this is not a standard, the suggested >>> experimentation with the main TCP header must IMHO be explicitly >>> mentioned. I also suggest to have later in a document a section that explicitly >>> explains why it is appropriate to modify the main TCP header in an >>> experiment. >>> >>> I don’t know if any requirement that IANA assignment need to be called out >>> in the abstract but we can do that. However, I believe the question if this >>> document should or should not assign the bit is still not completely solved, or >>> is it? >> I believe this question will have to be reviewed during WGLC and, more importantly, IETF last call. For the moment, my concern is that the document correctly describes the IANA allocation. >> >> I would like to see here a statement such as : "Given TCP header space is scarce, this specification allocates a reserved header bit and overloads the two ECN flags in the TCP header ...“. > A bit lengthy but now: > > "Given TCP header space is > scarce, it allocates a reserved header bit, that was previously used for > ECN-Nonce which was recently declared historic, and overloads the > two existing ECN flags in the TCP header. Further, additional > information can be provided in a new TCP option that however is not used > on the TCP SYN." > >>>> * 1. Introduction >>>> >>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>> more accurate ECN feedback information whenever more than one >>> marking >>>> is received in one RTT. >>>> >>>> [ms] At least for RFC 8257 seems to be implementable withoit this. Instead >>> of stating a "need", it would IMHO make more sense to discuss the benefits >>> of the suggested mechanism in this document of its own, independent of >>> other proposals. To me, this document should be independent of other >>> documents and specifically other experiments. We have to think about cases >>> where not all experiments are successful. Then independent documents will >>> be more future-proof in future. >>> >>> This is a naming collision… The sentence was meant to say that these >>> mechanisms new more accurate ECN feedback than provided today by >>> RFC3168 but it was not meant to say that these mechanism have to use the >>> scheme as specified in this document. >>> >>> I added the following part sentence: >>> >>> „Recently, proposed mechanisms like Congestion Exposure (ConEx >>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need more >>> accurate ECN feedback information than provided by the feedback scheme >>> as specified in [RFC3168] whenever more than one marking is received in one >>> RTT. This document specifies an alternative feedback scheme that provides >>> more accurate information and could be used by these new TCP extensions.“ >>> >>> Does this help? >> See my proposal for the abstract. I continue to disagree with the term "need" but I think this can be sorted out by another term. >> >>>> If AccECN progresses from experimental to the standards >>>> track, it is intended to be a complete replacement for classic TCP/ >>>> ECN feedback, not a fork in the design of TCP. >>>> >>>> [ms] This sentence should be removed, as this is speculation. >>> Why? It states an intent… and that’s the intent that we have. >>> >>>> Until the AccECN experiment succeeds, [RFC3168] will remain as the >>>> standards track specification for adding ECN to TCP. >>>> >>>> [ms] This sentence should be removed (or reworded) >>> Why? Does it help to add an only here: >>> >>> "Until the AccECN experiment succeeds, [RFC3168] will remain as the only >>> standards track specification for adding ECN to TCP.“ >> This wording is better. >> >>>> AccECN feedback overloads flags and fields in the main TCP header >>>> with new definitions, so both ends have to support the new wire >>>> protocol before it can be used. >>>> >>>> [ms] In my reading this experimental document asks for *new* allocation >>> of a reserved TCP header flag. >>> >>> Is this better? >>> >>> "AccECN feedback overloads the two existing ECN flags as well as the >>> currently reserved and previously called NS flag in the main TCP header >>> with new definitions, so both ends have to support the new wire protocol >>> before it can be used.“ >>> >>> I understand that you are not happy with the word „overload“ here but the >>> point of this sentence really is that the flags can/could be used differently >>> and therefore we need a new negotiation before we can use them. >> For me the following would work: "AccECN feedback overloads the two existing ECN flags and >> allocates the currently reserved and previously called NS flag in the main TCP header. >> Given the new definitions, both ends have to support the new wire protocol >> before it can be used." >> >> I believe the wording has to be crystal clear on the reservation of bit 7 when it is discussed the first time in the text. In follow-up sections, maybe shorter terms could be used. > Okay, now: > > "AccECN feedback overloads the two existing ECN flags and > allocates the currently reserved and previously called NS flag in the > TCP header, to be used as one field indicating the number of congestion > experienced marked packets. Given the new definitions of these three bits, > both ends have to support the new wire protocol before it can be used. > Therefore during the TCP handshake the two ends use these three bit in > the TCP header to negotiate the most advanced feedback protocol > that they can both support in a backward compatible way to > ." >>> If you prefer, we can also remove the NS flag in this list, as ECN Nonce was >>> anyway never deployed. >>> >>>> For that we refer to [RFC3168] or any RFC that >>>> specifies a different response to TCP ECN feedback, for example: >>>> [RFC8257]; or the ECN experiments referred to in >>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low Latency >>>> Low Loss Scalable (L4S) congestion control [I-D.ietf-tsvwg-l4s-arch]; >>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], or >>>> Alternative Backoff with ECN (ABE) >>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>> >>>> [ms] At least ABE seems orthogonal. Anyway, I think this paragraph can just >>> be deleted. If other experiments need more accurate feedback, it is up to >>> them to explain how they would use this mechanism. This document should >>> focus on how to signal the feedback, not how to use that. >>> >>> Yes, that is what the paragraph says. Isn’t it better to be explicit about this? >>> >>>> It is likely (but not required) that the AccECN protocol will be >>>> implemented along with the following experimental additions to the >>>> TCP-ECN protocol: ECN-capable TCP control packets and retransmissions >>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/ >>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>> >>>> [ms] I am a big fan of simple, standalone documents. In my view, the TCPM >>> working group should publish draft-ietf-tcpm-accurate-ecn and draft-ietf- >>> tcpm-generalized-ecn independent documents, which probably implies that >>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If experimentation >>> with ECT in SYN requires a combination, this could be done in a new, third >>> document. Apart from having simpler focused documents, this could >>> significantly help later with moving forward documents to standards track. >>> >>> I disagree, however, this is a discussion to have on draft-ietf-tcpm- >>> generalized-ecn. I don’t see a problem in providing a reference here that >>> says „it is likely…“ and nothing more. >>>> >>>> >>>> * 1.1. Document Roadmap >>>> >>>> [ms] A macroscopic comment is that this document has a lot of introduction >>> and tutorial text with lot's of redundancy towards other documents. I think >>> the document can be made much easier to read by shorten it. In many cases >>> this is just an editorial change as there is redundancy. As one such example, >>> just remove this section. >>> >>> I guess this a matter of taste. As an AD, I’m a big fan of short and concise >>> documents, however, some redundancy can also help understanding, >>> especially if you explain things multiple times but with a different level of >>> detail. I personally would not need the roadmap but I know many people >>> who find these things helpful and to be honest I don’t see how removing this >>> part makes the doc any better. If you don’t want it, don’t read it. >>> >>>> >>>> * 1.2. Goals >>>> >>>> [ms] I think this section can also just be removed. >>> I have to say I also don’t see the point of removing this part. Given we’ve >>> done the work on requirements, I think we should also link to this doc >>> somewhere. >>>> >>>> * 1.3. Experiment Goals >>>> >>>> TCP is critical to the robust functioning of the Internet, therefore >>>> any proposed modifications to TCP need to be thoroughly tested. The >>>> present specification describes an experimental protocol that adds >>>> more accurate ECN feedback to the TCP protocol. The intention is to >>>> specify the protocol sufficiently so that more than one >>>> implementation can be built in order to test its function, robustness >>>> and interoperability (with itself and with previous version of ECN >>>> and TCP). >>>> >>>> [ms] I think all what is written in this paragraph is obvious, no? Can't we just >>> delete this? >>> >>> Sure, however, I don’t think it hurts to spell it out. For me both is fine, keep it >>> or remove it. >>> >>>> The experimental protocol will be considered successful if it is >>>> deployed and if it satisfies the requirements of [RFC7560] in the >>>> consensus opinion of the IETF tcpm working group. In short, this >>>> requires that it improves the accuracy and timeliness of TCP's ECN >>>> feedback, as claimed in Section 5, while striking a balance between >>>> the conflicting requirements of resilience, integrity and >>>> minimisation of overhead. It also requires that it is not unduly >>>> complex, and that it is compatible with prevalent equipment >>>> behaviours in the current Internet (e.g. hardware offloading and >>>> middleboxes), whether or not they comply with standards. >>>> >>>> Testing will mostly focus on fall-back strategies in case of >>>> middlebox interference. Current recommended strategies are specified >>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>> these strategies depends on the actual deployment situation of >>>> middleboxes. Therefore experimental verification to confirm large- >>>> scale path traversal in the Internet is needed before finalizing this >>>> specification on the Standards Track. >>>> >>>> [ms] These two paragraphs must be entirely rewritten. As I have >>> mentioned before, I don't think an RFC should speculate about TCPM and its >>> consensus opinion. I would suggest a wording along the lines of: >>>> >>>> The experimental protocol will be considered successful if >>>> testing confirms that the proposed mechanism can be deployed at large >>> scale. >>>> Testing will mostly focus on fall-back strategies in case of >>>> middlebox interference. Current recommended strategies are specified >>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>> these strategies depends on the actual deployment situation of >>>> middleboxes. Therefore experimental verification to confirm large- >>>> scale path traversal in the Internet is needed, e.g., by support in >>>> major TCP stacks. >>>> >>>> >>> I don’t understand your point here. I don’t think that the paraphrase >>> speculates about the consensus of tcpm, in contrast it say tcpm has to >>> decided if the requirements previously specified by tcpm are sufficiently >>> fulfilled. I don’t see a reason to not mention the requirement draft as this >>> draft as tcpm consensus and was written for this purpose. >> My suggested wording uses the expression "can be deployed at large scale" and I believe this is relevant. >> >> The document already describes in Section 5 how the protocol satisfies the agreed requirements for a more accurate ECN feedback protocol [RFC7560]. So, if the TCPM working group publishes this document with the content of Section 5, I believe the TCPM working group already has reached consensus that the protocol meets requirements. In addition, it is possible that new requirements would be identified in future, e.g., as an outcome of the experiment, and that would obviously have to be considered by TCPM. In that case, for the success of the experiment not only RFC 7560 would matter, but also further requirements. My proposed wording does not have all these problems. >> >> In a nutshell, I continue to believe that this section has to change. > > Okay, used your proposed wording. You have a point about the requirement and I mis-read you proposal earlier as „has to be deployed large-scale“. > >>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>> >>>> [ms] This section could probably be shortened as well. >>>> >>>> The last bit in byte 13 of the TCP header was defined as the Nonce >>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deployed so >>>> it is being reclassified as historic, making this TCP flag available >>>> for use by the AccECN experiment instead. >>>> >>>> [ms] This wording, as well as Figure 1, needs to take into account the IANA >>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>> >>> Is does. However, I can explicitly say that is has be re-clssified as reserved. >>> >>> "RFC 3540 was never deployed so it is being reclassified as historic [I-D.ietf- >>> tsvwg-ecn-experimentation] and the respective flag has been marked as >>> „reserved“ in the IANA TCP Header Flags registry, making this TCP flag >>> available for use by the AccECN experiment instead.“ >>> >>> Better? >>> >>>> In my understanding, this experimental document asks for new assignment >>> of a reserved TCP header flag. >>> >>> As I said I’m not sure if we have fully concluded this discussion yet. However, >>> what we really would want to is mention somewhere that this experiment >>> with this flags is running. I guess there are three options: >>> 1) keep it in the registry as reserved and conserve the knowledge in tcpm >>> that this experiment is running and no other experimental RFC such use this >>> flags as long as this experiment is running. >>> 2) Keep is marked as reserved but add a note about this experiment in the >>> IANA registry >>> 3) Or assign it right away with IESG approval. I guess in this case tcpm could >>> also consider to change the registration policy to „IETF Review“. >> The current registration policy for the TCP header flags is "standards action". I understand that the IESG could approve exceptions. But given the policy, I believe the document has to be very precise on the request regarding bit 7. > Okay, it now says: > > "[TO BE REMOVED: IANA is requested to update the existing entry in the Transmission Control Protocol (TCP) Header Flags registration (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1) for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS (Nonce Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be instead of RFC8311.]“ > > I guess we could also ask IANA to add an additional comment column instead (but not sure if we then have to update RFC3168, which I think we really don’t want. Should be fine now. > >>>> * 2. AccECN Protocol Overview and Rationale >>>> >>>> o an essential part that re-uses ECN TCP header bits to feed back >>>> the number of arriving CE marked packets. This provides more >>>> accuracy than classic ECN feedback, but limited resilience against >>>> ACK loss; >>>> >>>> [ms] The word "re-use" is IMHO not correct. >>> I think this is nit picking. Using a different phrasing here makes the sentence >>> unnecessary complicated. We don’t try to some how get a round the fact >>> that we need to handle the flag registration correctly. However, here the >>> point really is to explain how the protocol word. The main point of using the >>> work „re-use“ here is really that we say that these flags are or have been >>> used different by other TCP extension (and we therefore need a proper >>> negotiation scheme). >> If the allocation of a reserved flag is correctly explained in the abstract and introduction, I think these sentences can use a bit relaxed terminology. >> >>>> The two part design was necessary, given limitations on the space >>>> available for TCP options and given the possibility that certain >>>> incorrectly designed middleboxes prevent TCP using any new options. >>>> >>>> [ms] IMHO it would make sense to more explicitly mention the downsides >>> of only specifying an option and not allocating a TCP header flag, in this >>> experimental document. >>> >>> We need to use the flags (all three of them) for the negotiation. >> I think that an explanation why negotiation by a TCP option would not solve all use cases (or requirements) would help here. >> >>>> The obvious alternative would be to postpone the header flag allocation to >>> a follow-up standards track document and just keep it reserved. >>> >>> We can still do that. We should discuss and make a final decision. >>> >>>> The essential part overloads the previous definition of the three >>>> flags in the TCP header that had been assigned for use by ECN. This >>>> design choice deliberately replaces the classic ECN feedback >>>> protocol, rather than leaving classic ECN feedback intact and adding >>>> more accurate feedback separately because: >>>> >>>> [ms] Similar like previous comments, in my reading there are only _two_ >>> ECN header flags. >>> >>> I think there are three flags that "had been assigned for use by ECN“ as ECN >>> Nonce is also an ECN mechanism. The fact that one of the flags is now >>> marked as reserved instead, it not that important for me here. >>> >>>> And, in addition, I think care is needed with wording such "replaces the >>> classic ECN feedback". I don't think this experiment replaces the ECN >>> standards. That would be up to a follow-up PS. >>> >>> This sentence is not meant to say that RFC3168 is replaced. Actually we don’t. >>> You can still use RFC3168 even if AccECN is implemented and deploy >>> (however, we do intent that AccECN will be used as the default scheme in >>> future and RFC3168 is hopefully simply not needed anymore at some point, >>> even though you probably still need to have it implemented as the >>> negotiation specified in this draft covers that as well, anyway...). The >>> sentence says that if AccECN is negotiation, the header flags as used by >>> RFC3168 and previously ECN Nonce are used differently (aka re-used). That’s >>> all. >>>> >>>> 2.1. Capability Negotiation >>>> >>>> AccECN is a change to the wire protocol of the main TCP header, >>>> therefore it can only be used if both endpoints have been upgraded to >>>> understand it. The TCP client signals support for AccECN on the >>>> initial SYN of a connection and the TCP server signals whether it >>>> supports AccECN on the SYN/ACK. The TCP flags on the SYN that the >>>> client uses to signal AccECN support have been carefully chosen so >>>> that a TCP server will interpret them as a request to support the >>>> most recent variant of ECN feedback that it supports. Then the >>>> client falls back to the same variant of ECN feedback. >>>> >>>> [ms] As this is an experimental specification, I would really like to see a >>> discussion how a future standards track version of more accurate ECN could >>> be negotiated. >>> >>> As described in this draft. There will be no different. AccECN IS and will >>> always be backward compatible with RFC3168. >> That is not the problem I think about. I wonder about a PS version of accurate ECN feedback that would possibly include changes as compared to this experiment, e.g., because the experiment may have some lessons learnt. What options would we have to negotiate the PS version, and how could a stack implementing the PS version figure out whether the remote end uses the experimental or the PS version of the protocol? >> >> The reason why I ask is because I don't see any easy solution to this but I may miss something. Maybe this would not be a concern if there were some codepoints left. >> >>>> How could both endpoints detect whether the other one implements the >>> future standards track version? >>> >>> If the initiator implements AccECN it will request it’s use. If the receiver also >>> implement it, it will/can negotiate it, if not it will look like an RFC3168 request >>> for the receiver (as the NS flags will be ignored in the SYN) and it will >>> negotiate RFC3168 ECN feedback if implemented. There is no additional >>> detection needed. >> My concern is the migration strategy for a future version, given that we only experiment right now. For instance, if the initiator implements the experimental version but the recipient implements the PS version of AccECN, how would that work? Under the assumption that there are changes, would there be a way to know? Maybe the answer to this question is no, given the small number of bits we have. But not having any room for extensions is not necessarily good protocol design. >> >>>> For instance, would the only safe variant be that we allocate yet another >>> reserved TCP header flag in a proposed standard to negotiate the standards >>> track version, thus investing another reserved bit in the TCP header? >>> >>> No, that’s exactly what we use the NS flags for in the handshake. >> If the PS version of AccECN was different to the experimental version of AccECN, and if there was a deployed base of both, I still believe we could end up in a situation in which we had to allocate yet another TCP header flag to distinguish the different versions of AccECN. The NS flag would not work for that if it is used by the experimental version. The risk of having to spend further TCP header flags somehow concerns me. Of course, that problem would only matter if the AccECN experiment succeeds somehow, but lessons learnt would require protocol changes, which is speculation. >> >>>> I may be wrong, but to me it is too early to speculate how the PS version >>> would look like, and whether it would have to be different to the >>> experimental version, due to lessons learnt. >>> >>> Of course you can always be wrong. However, the handshake negotiation is >>> not the part we need experimentation for. That part is straight forward and >>> works. If we really happen to detect a problem in that part, we would need >>> to end the experiment declare failure and start over new. >> My concern is ending the experiment when the experiment got (partly) deployed in the Internet. In that case neither a new RFC nor a change of the IANA registry will solve the migration issue. >> >>>> I believe in the IETF we typically design protocols that allow future >>> extension, and it is not exactly clear to be how AccECN could be extended >>> later. >>> >>> This is an TCP extension. If we want future extension we use the usually TCP >>> mechanism (by defining a new TCP option I guess). >> The root cause of my concern is that this proposal does *not* use the usual way to experiment with TCP by options. It experiments with a header flag, including in the SYN, and it seems to consume all codepoints. So, I see the risk of a protocol design "not ready for future improvements". >> >> I cannot easily propose text. Maybe "lack of extensibility" is just one of the short-comings of the protocol design that cannot be avoided but that short-coming would have to be noted. >> >>>> An AccECN TCP client does not send the new AccECN Option on the SYN >>>> as SYN option space is limited and successful negotiation using the >>>> flags in the main header is taken as sufficient evidence that both >>>> ends also support the AccECN Option. The TCP server sends the AccECN >>>> Option on the SYN/ACK and the client sends it on the first ACK to >>>> test whether the network path forwards the option correctly. >>>> >>>> [ms] For what it is worth, I would personally be quite fine with allowing (or >>> even mandating) an option in the SYN in the experimental version of this >>> protocol. For instance, saving the SYN option space would then an excellent >>> reason for moving towards the PS specification. I am also fine with being in >>> the rough part of the consensus here. >>> >>> The point is that we really don’t need the option in the SYN as we don’t use it >>> for negotiation purposes as we use the header bits instead. So why should >>> we waste the space? >> For instance, mandating the option in the SYN would be away for the receiver to distinguish the experiment from a follow-up PS version of the spec, as the PS version may not mandate the option, to save header space. >> >> Maybe that proposal does not make any sense, and it may only have downsides. But the document already speculates about a PS-follow-up. So it seems a valid question to ask if the EXP and the PS version of the spec have to be identical. This all comes down to the SYN negotiation. >> >>>> * 2.3. Delayed ACKs and Resilience Against ACK Loss >>>> >>>> If the AccECN Option is not available, e.g. it is being stripped by a >>>> middlebox, the AccECN protocol will only feed back information on CE >>>> markings (using the ACE field). Although not ideal, this will be >>>> sufficient, because it is envisaged that neither ECT(0) nor ECT(1) >>>> will ever indicate more severe congestion than CE, even though future >>>> uses for ECT(0) or ECT(1) are still unclear >>>> [I-D.ietf-tsvwg-ecn-experimentation]. >>>> >>>> [ms] This needs to be reworded >>> Why? >>> >>>> >>>> >>>> * 2.4. Feedback Metrics >>>> >>>> The CE packet counter in the ACE field and the CE byte counter in the >>>> AccECN Option both provide feedback on received CE-marks. The CE >>>> packet counter includes control packets that do not have payload >>>> data, while the CE byte counter solely includes marked payload bytes. >>>> 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 DCTCP or ConEx. >>>> >>>> [ms] I suggest to write in the last sentence only "... the option will provide >>> the more accurate information needed for congestion control". In general, I >>> would prefer to have references to other mechanisms at only few (ideally a >>> *single*) places in the document, instead of mixing them together. >>> >>> Sorry, I don’t see your point here. ConEx has been mentioned previously, so >>> why not also mention it here. >> As written earlier, in my understanding DCTCP does not "need" this. I would suggest to have one place where to define exactly how this mechanism can be used by other TCP extensions. Having said this, in this specific paragraph I am less concerned about that than elsewhere. >> >>>> Feedback in bytes is recommended in order to protect against the >>>> receiver using attacks similar to 'ACK-Division' to artificially >>>> inflate the congestion window, which is why [RFC5681] now recommends >>>> that TCP counts acknowledged bytes not packets. >>>> >>>> [ms] At least the last part and the reference to RFC 5681 is IMHO not >>> needed here. >>> >>> Why? RFC5681 explains/refers the ACK division attack, so I think it is a very >>> good reference to have here. >>>> >>>> >>>> * 2.5. Generic (Dumb) Reflector >>>> >>>> The ACE field provides information about CE markings on both data and >>>> control packets. According to [RFC3168] the Data Sender is meant to >>>> set control packets to Not-ECT. However, mechanisms in certain >>>> private networks (e.g. data centres) set control packets to be ECN >>>> capable because they are precisely the packets that performance >>>> depends on most. >>>> >>>> For this reason, AccECN is designed to be a generic reflector of >>>> whatever ECN markings it sees, whether or not they are compliant with >>>> a current standard. Then as standards evolve, Data Senders can >>>> upgrade unilaterally without any need for receivers to upgrade too. >>>> It is also useful to be able to rely on generic reflection behaviour >>>> when senders need to test for unexpected interference with markings >>>> (for instance [I-D.kuehlewind-tcpm-ecn-fallback] and >>>> [I-D.moncaster-tcpm-rcv-cheat]). >>>> >>>> The initial SYN is the most critical control packet, so AccECN >>>> provides feedback on whether it is CE marked. Although RFC 3168 >>>> prohibits an ECN-capable SYN, providing feedback of CE marking on the >>>> SYN supports future scenarios in which SYNs might be ECN-enabled >>>> (without prejudging whether they ought to be). For instance, >>>> [I-D.ietf-tsvwg-ecn-experimentation] updates this aspect of RFC 3168 >>>> to allow experimentation with ECN-capable TCP control packets. >>>> >>>> [ms] To me, the only thing that matters in this document that AccECN can >>> provide feedback on whether the SYN is CE marked. The discussion on how >>> to experiment with ECT e.g. in SYNs IMHO does not belong into this >>> document. So it seems sufficient here to note that one of the benefits of >>> AccECN is that CE marks in SYNs can be fed back. >>> >>> I disagree. Explicitly saying that AccECN is only an feedback scheme and DOES >>> NOT define how the information is used is VERY important because people >>> come back to me over and over again and mix these things up. >>>> >>>> * 3.1.1. Negotiation during the TCP handshake >>>> >>>> Given the ECN Nonce [RFC3540] is being reclassified as historic, the >>>> present specification renames the TCP flag at bit 7 of the TCP header >>>> flags from NS (Nonce Sum) to AE (Accurate ECN) (see IANA >>>> Considerations in Section 6). >>>> >>>> [ms] As mentioned before, this needs to be rewritten to ask for new IANA >>> allocation of bit 7 in the TCP header flags. >>> >>> I really don’t understand this comment. That is what the IANA section does >>> as referred here correctly. >> In my reading of https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml, this flag currently has no name, i.e., it does not have the name NS. So this statement on "renaming" is formally incorrect IMHO. >> >> I'd suggest something like: "This specification assigns the name AE (Accurate ECN) to the TCP flag at bit 7; this flag has previously been known as NS (Nonce Sum) …". > Now: > > "Given the ECN Nonce has been > reclassified as historic , the present specification re-allocates the TCP > flag at bit 7of the TCP header flags, which was previously called NS > (Nonce Sum), as the AE > (Accurate ECN) flag (see IANA Considerations in target="accecn_IANA_Considerations"/>)." >>> Again, yes, we can discuss if this document should do this, but if published as >>> it is, section 6 says everything that is needs to say. (I does not put any >>> request on IANA, instead it is written as it would show up post-publication, >>> implicitly providing a request to IANA at approval time. That is fine.) >>> >>>> Table 2: ECN capability negotiation between Client (A) and Server >>>> (B) >>>> >>>> [ms] As far as I can see, in -05 this table allocates all existing codepoints, >>> while -03 had two currently unused codepoints. Not having any codepoints >>> left seems to me not really future proof, e.g., regarding future proposed >>> standards in this space (and I personally believe that TCP header flags must >>> be allocated in a PS). And I don't fully see a need of feeding back ECT0 and >>> specifically ECT1 in the TCP header flags as part of the experiment. Do we >>> know for sure that this is the only possible use case of these two unallocated >>> header bits? And why can't e.g. this be done in a TCP option instead? Or do I >>> miss something? >>> >>> The point is really, if we don’t assign them now and start deployment we >>> effetely we not be able to every assign them again because don’t have a >>> different negotiation mechanisms. Realizing this, it is just the right think to >>> define the space completely that is negotiated as use for AccECN in the >>> handshake. >> I disagree that consuming all codepoints and not having room for future extensions is the "right thing" to do. It is in fact the wrong thing. But possibly there is no alternative with the few bits, so maybe we end up doing it. >> >> Yet, at minimum, using all codepoints needs to be reasoned in the document. Specifically since in -03 a different protocol design seemed possible, which looked to me more future-proof. >> >>>> * 3.1.2. Retransmission of the SYN >>>> >>>> However, >>>> current measurements imply that a drop is less likely to be due to >>>> middlebox interference than other intermittent causes of loss, e.g. >>>> congestion, wireless interference, etc. >>>> >>>> [ms] Such wording IMHO doesn't belong into normative text. This may >>> actually also apply to other heuristics discussed in this section, which are not >>> really important for interoperability. >>> >>> I don’t really understand your point. This sentence is solely meant to reason >>> the design decision to not say that a sender SHOULD attempt to re- >>> negotiation after a loss. >> One could split the reasoning from the normative design. The normative specification may still be relevant in 20 years from now. Middleboxes will almost likely be different in 20 years. Having said this, this is more of an editorial remark. >> >>>> 3.2.7. Path Traversal of the AccECN Option >>>> >>>> 3.2.7.1. Testing the AccECN Option during the Handshake >>>> >>>> The TCP client MUST NOT include the AccECN TCP Option on the SYN. >>>> >>>> [ms] I am not sure if I really understand the motivation for not allowing a >>> option in the SYN. If the sender has space in the SYN left, what is the harm in >>> an experimental version of the protocol? And I may miss something, but >>> what would prevent the use of 2-byte option to negotiate the use of >>> AccECN, e.g., to avoid experimental allocation of bit 7 in the initial SYN? >>> >>> I did have a draft on that as a proposal for an alternative design. However, >>> the gourd was more supportive of this design as it is proof of middlebox SYN >>> option mangling which is a know problem. >>> >>> Therefore we simply don’t need option in the SYN and there is no reason to >>> waste the space. >>> >>>> While I think many tutorial text in this document could be shortened, I >>> believe the use of a reserved TCP header flag should be reasoned. >>> >>> I’m actually uncertain what you expect here. >> For instance, this reply with the explanation of SYN option mangling seems useful explanation. >> >>>> * 3.2.8. Usage of the AccECN TCP Option >>>> >>>> The following rules determine when a Data Receiver in AccECN mode >>>> sends the AccECN TCP Option, and which fields to include: >>>> >>>> Change-Triggered ACKs: 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, >>>> without waiting for the next delayed ACK (this is in addition to >>>> the safety recommendation in Section 3.2.5 against ambiguity of >>>> the ACE field). >>>> >>>> This is stated as a "MUST" so that the data sender can rely on >>>> change-triggered ACKs to detect transitions right from the very >>>> start of a flow, without first having to detect whether the >>>> receiver complies. A concern has been raised that certain offload >>>> hardware needed for high performance might not be able to support >>>> change-triggered ACKs, although high performance protocols such as >>>> DCTCP successfully use change-triggered ACKs. >>>> >>>> [ms] To me this sounds like a perfect example for a SHOULD with additional >>> guidance why implementing this SHOULD is really important. >>> >>> This is one of the most discussed point from the author and we really tried to >>> get additional guidance here of what to do also from outside the IETF but did >>> no clear feedback. >>> >>> As explained this MUST enables additional functionality. However, this is an >>> experiment document. If we detect that this MUST does actually hinder >>> implementation or has just never been implemented, we should reconsider >>> this in the final PS RFC. >>> >>> I was on the SHOULD side of the discussion, but can say that the >>> implementation in Linux was way more simple then expected. Offloading >>> might be a different topic but that is where I could not get a clear feedback >>> and offloading could probably be anyway optimized for use with AccECN (if it >>> gets deploy widely). >> If a MUST requires changes in hardware, I think there must be a clear reason. >> >> As individual contributor, with the current explanation in the text, I believe this has to be a SHOULD. >> >>> I though we added this as something to mention in the exp goals section, but >>> obviously we didn’t. I added the following text now: >>> >>> "Another experimentation focus is the implementation feasibiliy of change- >>> triggered ACKs as described in section 3.2.8. While on average this should not >>> lead to a higher ACK rate, it changes the ACK patter which especially can have >>> an impact on hardware offload. Further experimentation is needed to advise >>> if this should a hard requirement or just prefer behavior.“ >> If it is unclear if a MUST can actually be implemented, having a MUST is in my opinion the wrong approach. >> >> One could equally state here that further experimentation is needed to determine whether the SHOULD can be upgraded to a MUST. > I’m still open for everything here, but I believe this was discussed and agreed in the working group…? > > >>>> For the avoidance of doubt, the change-triggered ACK mechanism is >>>> deliberately worded to ignore the arrival of a control packet with no >>>> payload, which therefore does not alter any byte counters, because it >>>> is important that TCP does not acknowledge pure ACKs. The change- >>>> triggered ACK approach will lead to some additional ACKs but it feeds >>>> back the timing and the order in which ECN marks are received with >>>> minimal additional complexity. >>>> >>>> [ms] The additional acks create network load. I think some wording is >>> needed on the tradeoff between information accuracy and network load. >>> There are network environments in which any additional packet is very >>> expensive (e.g., energy) and it is not clear to me how the protocol design >>> takes into account the potential overhead of additional ACKs. Maybe this >>> could be another reason for a SHOULD. >>> >>> The above. However, this is not really an additional ACK because you do >>> delay the next one. Further experimentation needed. >> The document states "lead to some additional ACKs". If that does not increase network load, I think it has to be explicitly explained why the ACK load is at most equal to a current TCP stack, in all potential cases. If it can increases network load, it has to be reasoned why increasing load (and risk of reverse congestion and the like) is worth the effort. >> >> I agree that this may be an area of experimentation, but I believe then it has to be explained to implementers what the tradeoffs are. > Added: > "Especially, if only few > CE marks occurred or multiple marks in a row, the additional load will > be low. Other, unexpected marking pattern could increase the load > significantly, however, investigating the additional load it part > of the proposed experimentation." >>>> * 4.2. Compatibility with Other TCP Options and Experiments >>>> >>>> AccECN is compatible (at least on paper) with the most commonly used >>>> TCP options: MSS, time-stamp, window scaling, SACK and TCP-AO. It is >>>> also compatible with the recent promising experimental TCP options >>>> TCP Fast Open (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824]). >>>> >>>> [ms] I would suggest the wording "... compatible with the experimental >>> TCP options ..." or even "... compatible with the TCP options …". >>> >>> These option are to experimental..? >> "It is also compatible with the experimental TCP options TCP Fast Open (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824])." would have same technical meaning. Having said this, this is editorial only. >> >>> The point of using „commonly used“ was to say that we checked on those as >>> they seem important. Just because your favorite experiment option is not >>> listed here it doesn’t means it incompatible, we just didn’t check. I’m okay to >>> removed „commonly used“ but I don’t think it makes anything better. >>> >>>> * 4.3. Compatibility with Feedback Integrity Mechanisms >>>> >>>> [ms] Quite a bit in this section is experimental work, which IMHO >>>> should be clearly emphasized. The one exception is… >>> I would really like to keep this section because integrity is usually the fist >>> question that come up when I present AccECN. Effectively these are two >>> independent topics, however, I really think it help people to understand the >>> whole picture if this is also discussed in this document. >>> >>>> However, TCP-AO is often too brittle to use on many end-to-end >>>> paths, where middleboxes can make verification fail in their >>>> attempts to improve performance or security, e.g. by >>>> resegmentation or shifting the sequence space. >>>> >>>> [ms] I am not sure if deployment challenges of other options need to be >>> discussed in this document. >>> >>> If we keep the discussion, I guess we should mention this as well. As the doc >>> clearly stated section 4 is not meant to be normative. >> As far as I can see, there are use cases for TCP-AO where middleboxes are simply not a problem, but it is exactly this sort of discussion that may not be needed in this document. But I won't rat-hole on this comment here. >> >>>> Originally the ECN Nonce [RFC3540] was proposed to ensure integrity >>>> of congestion feedback. With minor changes AccECN could be optimised >>>> for the possibility that the ECT(1) codepoint might be used as an ECN >>>> Nonce . However, given RFC 3540 is being reclassified as historic, >>>> the AccECN design has been generalised so that it ought to be able to >>>> support other possible uses of the ECT(1) codepoint, such as a lower >>>> severity or a more instant congestion signal than CE. >>>> >>>> [ms] The discussion of RFC 3540 can probably be removed to a large extent. >>> Unfortunately, please still think that ECN Nonce, even though is was never >>> deployed and doesn’t really work, is the only was to provide integrity >>> protection and we need it as a prerequisite to deploy ECN at all… i would >>> really prefer to keep this in this non-normative part of the doc. >>> >>>> >>>> * 6. IANA Considerations >>>> >>>> [ms] I think this section needs to be rewritten to request a new allocation >>> of bit 7 of the TCP header flags. At least for the process I think it would make >>> sense to have somewhere in the document a comprehensive explanation of >>> why an experimental document requests a change of the main TCP header, >>> and why this cannot be avoided (most notably in the initial SYN) by an >>> alternative protocol design. >>> >>> As I said previously this section is written as it would look like after the >>> allocation has happened with publication approval of the IESG. This is fine. >>> >>> Having a discussion about an experiment doc assigning a flag (or not) is a >>> question for tcpm as a whole and not specifically this document. How do we >>> envision to every use any further flags? We go to PS right away? Or should >>> we change the registration policy? For me the latter makes actually more >>> sense. However, if we don’t want/can to decide this now, we also could go >>> forward as it is with IESG approval. However, is this case it is also not needed >>> to explain this in the document. The responsible AD has to explain this to the >>> other IESG probably in the ballot or even better the shepherd could provide >>> these information in the write-up. >>> >>>> >>>> * 9. Comments Solicited >>>> >>>> Comments and questions are encouraged and very welcome. They can >>> be >>>> addressed to the IETF TCP maintenance and minor modifications working >>>> group mailing list , and/or to the authors. >>>> >>>> [ms] This section is not needed IMHO >>> Yes, it will be removed before publication. >>>> >>>> 10. References >>>> >>>> [I-D.ietf-tsvwg-ecn-experimentation] >>>> Black, D., "Relaxing Restrictions on Explicit Congestion >>>> Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn- >>>> experimentation-07 (work in progress), October 2017. >>>> >>>> [ms] Normative reference? >>> Don’t see why. No need to read ietf-tsvwg-ecn-experimentation to >>> understand the spec in this doc. >>> >>> Thanks! >>> Mirja >>> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jul 11 11:36:48 2018 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 F190F130F61 for ; Wed, 11 Jul 2018 11:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 uX5_xKHZtkf5 for ; Wed, 11 Jul 2018 11:36:40 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09669130F3C for ; Wed, 11 Jul 2018 11:36:40 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id y10-v6so10288998ioa.10 for ; Wed, 11 Jul 2018 11:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pc4823Isj1hEgb/yZWjHIp4T9+1IvH9+tIdyPt4K9Q0=; b=cJ5L7hGoPRvSgFlPUCtI3jtrW8lKCmPwLJ7QA6Q7VXbhUxGiGE953VU4Z31Lwu6eT5 sKhnbFR+Bw1AfBWbSS/9DVnD0GyjgFem1qCi3qZfK/hhogC5tPSfkswDzNooGCIbp624 cxmCHsobrpyE5FUVIqaA4br8by/v7bXD6q0yBgoJHfD5n1alvc1GBkvSQjVHFKhO6VBP j70U/q0tTX7CGtfOCgFU9yLVhy9MIbDt2jfWyTogChdqJ+I+MYyPxek9lJHdaONNP9AH A7DkCh8E91AKOGjSLL4eJcOJoywkamrskRN2Ctou5noW0o4SOHPL6Im46qgEbO81jWb1 Qxjw== 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:content-transfer-encoding; bh=pc4823Isj1hEgb/yZWjHIp4T9+1IvH9+tIdyPt4K9Q0=; b=dH+RAvcd3Uw/AcdT4TPqfjjgNThXwnWbtS01SJRJaWVsCRUXcrzrtogRyvl//aS+ji ryc3Ac20x1pS0pUb71uRjndtzT0Gh0NUSPKV1JBz1jC2SxQKMbhKWIxC5KPfwdA4B/ho Z7oy/1AGk5+6tgkbeeuNcO8pZx34KZyD/qKmij0ftksmwKe4O30XrviAjrmFEr39w0h6 STCNeQhrpIontyNZ0PoPKghEmTppWS8VUFKYolHawTpTrnBcad/L2opmQpGPnroqM76p 9aMToEaefsUr+353sukMhYWBd8g2tg6oDPora0cf3k9RXQ+QH1XEgfraC6mQkN34+z53 0MWg== X-Gm-Message-State: APt69E11Pi+ZvPh9BmjerrsW2mCxKLO71IYoR+GU3myEiegLlqH3b9Ov zjuG4t9AHaCSIeIFlv764GpxY4v/SBWTPgpMWOwhlw== X-Google-Smtp-Source: AAOMgpciEbQD0s1Rjyk4jyF+Si3jlD2pEvtSw1pivahAQDHHl3yGULNek6yASjDdZ+Uau7E3V3lirCiQp7cXYiUsiWc= X-Received: by 2002:a6b:1d2:: with SMTP id 201-v6mr25209498iob.140.1531334198638; Wed, 11 Jul 2018 11:36:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:ee18:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:35:58 -0700 (PDT) In-Reply-To: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> From: Yuchung Cheng Date: Wed, 11 Jul 2018 11:35:58 -0700 Message-ID: To: Bob Briscoe Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 18:36:46 -0000 Hi Bob, Neal and I evaluated the earlier draft. It is well-thought out but we're concerned about the options. Option is not mandatory but the lack of it also reduces accuracy. Option runs into space issues w/ SACK and offload issues w/ TSO/GRO. They can be addressed for sure but aren't easy. We're curious how much more "accuracy" it buys over current DCTCP-style ECN. Is there any study to show trade-offs of full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe wrote: > Michael, tcpm list, > > As well as addressing your points, as Mirja has already mentioned below, = we > added a whole new appendix giving the rationale for the bits and codepoin= ts > that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd > subsection also identifies space for future evolution. It also points to > where rationale was already given in the body of the draft. > > The appendix is in the draft submitted last week, available here: > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B > > We'd be interested to hear whether this allays your concerns. > > We have asked to present this in Montreal as well. > > Cheers > > > Bob > > > On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >> >> Hi Micheal, >> >> I addressed a couple of your comments below. >> >> For the other, bigger comments regarding extensibility, that I did not y= et >> address below, we plan to add a new section to the appendix to explain >> extensibility options as previously discussed by mail. We will probably = send >> a separate email on that part. >> >> Mirja >> >> >>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>> : >>> >>> Hi Mirja, >>> >>> Thanks a lot for the explanation. I won't follow-up on some of the >>> editorial suggestions. >>> >>> Yet, I continue to believe that some formal wording in the document nee= ds >>> to change, as explained below. >>> >>> Thanks >>> >>> Michael (with no hat on) >>> >>> >>>> -----Original Message----- >>>> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>> Sent: Monday, March 05, 2018 1:54 PM >>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>> >>>> Hi Micheal, >>>> >>>> thanks for your feedback and sorry for my late reply. >>>> >>>> Please see inline. >>>> >>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>>> >>>> : >>>>> >>>>> Hi all, >>>>> >>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix). I >>>> >>>> believe this document needs further work before moving forward. >>>>> >>>>> Please find below my comments marked as [ms]. I have read the >>>> >>>> document independent of the review from Gorry. I apologize if there is >>>> duplication. >>>>> >>>>> Thanks >>>>> >>>>> Michael (with no hat on) >>>>> >>>>> >>>>> ****************************** >>>>> >>>>> * Abstract: >>>>> >>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or >>>>> Data >>>> >>>> Center TCP >>>>> >>>>> (DCTCP) need more accurate ECN feedback information whenever more >>>>> than one marking is received in one RTT. >>>>> >>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>> suggest to >>>> >>>> remove this, or replace it by a more generic statement that more >>>> accurate >>>> information can be useful for several TCP extensions. >>>> >>>> I disagree. Both ConEx and DCTCP need more accurate information. They = do >>>> not need the mechanism that is specified in this draft, however, this = is >>>> not >>>> what the sentences is saying. >>> >>> In my understanding (as a non-native speaker), the use of the word "nee= d" >>> is not correct here. DCTCP as specified in RFC 8257 can be implemented >>> without any such mechanism. >>> >>> What would work for me is something of the form "... Data Center TCP >>> cannot get precise ECN feedback whenever more than one marking is recei= ved >>> in one RTT=E2=80=9C. >> >> This is not correct. DCTP need more than one feedback signal per RTT and >> therefore cannot use RFC3168; instead it implement it=E2=80=99s own feed= back >> mechanism. However, to avoid confusion such that people could assume DCT= P >> would not work without the accECN scheme as specified in this doc, I >> rephrased to: >> >> "Recently, proposed >> mechanisms like Congestion Exposure (ConEx > target=3D"RFC7713"/>), >> DCTCP or L4S > target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more than = one >> marking is received in one RTT which is >> information that cannot be provided by the feedback scheme as >> specified in >> ." >> >> >>>>> This document specifies an >>>>> experimental scheme to provide more than one feedback signal per R= TT >>>>> in the TCP header. Given TCP header space is scarce, it overloads >>>>> the three existing ECN-related flags in the TCP header and provide= s >>>>> additional information in a new TCP option. >>>>> >>>>> [ms] This statement needs to be rewritten to correctly reflect what i= s >>>> >>>> requested from IANA. My understanding is that this experimental docume= nt >>>> asks for allocation of a reserved TCP header flag. This needs to be >>>> called out >>>> prominently, IMHO. In addition, since this is not a standard, the >>>> suggested >>>> experimentation with the main TCP header must IMHO be explicitly >>>> mentioned. I also suggest to have later in a document a section that >>>> explicitly >>>> explains why it is appropriate to modify the main TCP header in an >>>> experiment. >>>> >>>> I don=E2=80=99t know if any requirement that IANA assignment need to b= e called >>>> out >>>> in the abstract but we can do that. However, I believe the question if >>>> this >>>> document should or should not assign the bit is still not completely >>>> solved, or >>>> is it? >>> >>> I believe this question will have to be reviewed during WGLC and, more >>> importantly, IETF last call. For the moment, my concern is that the doc= ument >>> correctly describes the IANA allocation. >>> >>> I would like to see here a statement such as : "Given TCP header space = is >>> scarce, this specification allocates a reserved header bit and overload= s the >>> two ECN flags in the TCP header ...=E2=80=9C. >> >> A bit lengthy but now: >> >> "Given TCP header space is >> scarce, it allocates a reserved header bit, that was previously >> used for >> ECN-Nonce which was recently declared historic, and overloads the >> two existing ECN flags in the TCP header. Further, additional >> information can be provided in a new TCP option that however is n= ot >> used >> on the TCP SYN." >> >>>>> * 1. Introduction >>>>> >>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>>> more accurate ECN feedback information whenever more than one >>>> >>>> marking >>>>> >>>>> is received in one RTT. >>>>> >>>>> [ms] At least for RFC 8257 seems to be implementable withoit this. >>>>> Instead >>>> >>>> of stating a "need", it would IMHO make more sense to discuss the >>>> benefits >>>> of the suggested mechanism in this document of its own, independent of >>>> other proposals. To me, this document should be independent of other >>>> documents and specifically other experiments. We have to think about >>>> cases >>>> where not all experiments are successful. Then independent documents >>>> will >>>> be more future-proof in future. >>>> >>>> This is a naming collision=E2=80=A6 The sentence was meant to say that= these >>>> mechanisms new more accurate ECN feedback than provided today by >>>> RFC3168 but it was not meant to say that these mechanism have to use t= he >>>> scheme as specified in this document. >>>> >>>> I added the following part sentence: >>>> >>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure (ConEx >>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need more >>>> accurate ECN feedback information than provided by the feedback scheme >>>> as specified in [RFC3168] whenever more than one marking is received i= n >>>> one >>>> RTT. This document specifies an alternative feedback scheme that >>>> provides >>>> more accurate information and could be used by these new TCP >>>> extensions.=E2=80=9C >>>> >>>> Does this help? >>> >>> See my proposal for the abstract. I continue to disagree with the term >>> "need" but I think this can be sorted out by another term. >>> >>>>> If AccECN progresses from experimental to the standards >>>>> track, it is intended to be a complete replacement for classic TCP= / >>>>> ECN feedback, not a fork in the design of TCP. >>>>> >>>>> [ms] This sentence should be removed, as this is speculation. >>>> >>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent that w= e have. >>>> >>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as the >>>>> standards track specification for adding ECN to TCP. >>>>> >>>>> [ms] This sentence should be removed (or reworded) >>>> >>>> Why? Does it help to add an only here: >>>> >>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as the on= ly >>>> standards track specification for adding ECN to TCP.=E2=80=9C >>> >>> This wording is better. >>> >>>>> AccECN feedback overloads flags and fields in the main TCP header >>>>> with new definitions, so both ends have to support the new wire >>>>> protocol before it can be used. >>>>> >>>>> [ms] In my reading this experimental document asks for *new* allocati= on >>>> >>>> of a reserved TCP header flag. >>>> >>>> Is this better? >>>> >>>> "AccECN feedback overloads the two existing ECN flags as well as the >>>> currently reserved and previously called NS flag in the main TCP >>>> header >>>> with new definitions, so both ends have to support the new wire >>>> protocol >>>> before it can be used.=E2=80=9C >>>> >>>> I understand that you are not happy with the word =E2=80=9Eoverload=E2= =80=9C here but >>>> the >>>> point of this sentence really is that the flags can/could be used >>>> differently >>>> and therefore we need a new negotiation before we can use them. >>> >>> For me the following would work: "AccECN feedback overloads the two >>> existing ECN flags and >>> allocates the currently reserved and previously called NS flag in the >>> main TCP header. >>> Given the new definitions, both ends have to support the new wire >>> protocol >>> before it can be used." >>> >>> I believe the wording has to be crystal clear on the reservation of bit= 7 >>> when it is discussed the first time in the text. In follow-up sections, >>> maybe shorter terms could be used. >> >> Okay, now: >> >> "AccECN feedback overloads the two existing ECN flags and >> allocates the currently reserved and previously called NS flag in t= he >> TCP header, to be used as one field indicating the number of >> congestion >> experienced marked packets. Given the new definitions of these thre= e >> bits, >> both ends have to support the new wire protocol before it can b= e >> used. >> Therefore during the TCP handshake the two ends use these three bit >> in >> the TCP header to negotiate the most advanced feedback protocol >> that they can both support in a backward compatible way to >> ." >>>> >>>> If you prefer, we can also remove the NS flag in this list, as ECN Non= ce >>>> was >>>> anyway never deployed. >>>> >>>>> For that we refer to [RFC3168] or any RFC that >>>>> specifies a different response to TCP ECN feedback, for example: >>>>> [RFC8257]; or the ECN experiments referred to in >>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>> Latency >>>>> Low Loss Scalable (L4S) congestion control >>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], o= r >>>>> Alternative Backoff with ECN (ABE) >>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>> >>>>> [ms] At least ABE seems orthogonal. Anyway, I think this paragraph ca= n >>>>> just >>>> >>>> be deleted. If other experiments need more accurate feedback, it is up >>>> to >>>> them to explain how they would use this mechanism. This document shoul= d >>>> focus on how to signal the feedback, not how to use that. >>>> >>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better to be ex= plicit >>>> about this? >>>> >>>>> It is likely (but not required) that the AccECN protocol will be >>>>> implemented along with the following experimental additions to the >>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>> retransmissions >>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SY= N/ >>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>> >>>>> [ms] I am a big fan of simple, standalone documents. In my view, the >>>>> TCPM >>>> >>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>> draft-ietf- >>>> tcpm-generalized-ecn independent documents, which probably implies tha= t >>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If experimentatio= n >>>> with ECT in SYN requires a combination, this could be done in a new, >>>> third >>>> document. Apart from having simpler focused documents, this could >>>> significantly help later with moving forward documents to standards >>>> track. >>>> >>>> I disagree, however, this is a discussion to have on draft-ietf-tcpm- >>>> generalized-ecn. I don=E2=80=99t see a problem in providing a referen= ce here >>>> that >>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>>> >>>>> >>>>> >>>>> * 1.1. Document Roadmap >>>>> >>>>> [ms] A macroscopic comment is that this document has a lot of >>>>> introduction >>>> >>>> and tutorial text with lot's of redundancy towards other documents. I >>>> think >>>> the document can be made much easier to read by shorten it. In many >>>> cases >>>> this is just an editorial change as there is redundancy. As one such >>>> example, >>>> just remove this section. >>>> >>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan of sho= rt and >>>> concise >>>> documents, however, some redundancy can also help understanding, >>>> especially if you explain things multiple times but with a different >>>> level of >>>> detail. I personally would not need the roadmap but I know many people >>>> who find these things helpful and to be honest I don=E2=80=99t see how= removing >>>> this >>>> part makes the doc any better. If you don=E2=80=99t want it, don=E2=80= =99t read it. >>>> >>>>> >>>>> * 1.2. Goals >>>>> >>>>> [ms] I think this section can also just be removed. >>>> >>>> I have to say I also don=E2=80=99t see the point of removing this part= . Given >>>> we=E2=80=99ve >>>> done the work on requirements, I think we should also link to this doc >>>> somewhere. >>>>> >>>>> >>>>> * 1.3. Experiment Goals >>>>> >>>>> TCP is critical to the robust functioning of the Internet, therefo= re >>>>> any proposed modifications to TCP need to be thoroughly tested. Th= e >>>>> present specification describes an experimental protocol that adds >>>>> more accurate ECN feedback to the TCP protocol. The intention is = to >>>>> specify the protocol sufficiently so that more than one >>>>> implementation can be built in order to test its function, >>>>> robustness >>>>> and interoperability (with itself and with previous version of ECN >>>>> and TCP). >>>>> >>>>> [ms] I think all what is written in this paragraph is obvious, no? >>>>> Can't we just >>>> >>>> delete this? >>>> >>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. For me = both is >>>> fine, keep it >>>> or remove it. >>>> >>>>> The experimental protocol will be considered successful if it is >>>>> deployed and if it satisfies the requirements of [RFC7560] in the >>>>> consensus opinion of the IETF tcpm working group. In short, this >>>>> requires that it improves the accuracy and timeliness of TCP's ECN >>>>> feedback, as claimed in Section 5, while striking a balance betwee= n >>>>> the conflicting requirements of resilience, integrity and >>>>> minimisation of overhead. It also requires that it is not unduly >>>>> complex, and that it is compatible with prevalent equipment >>>>> behaviours in the current Internet (e.g. hardware offloading and >>>>> middleboxes), whether or not they comply with standards. >>>>> >>>>> Testing will mostly focus on fall-back strategies in case of >>>>> middlebox interference. Current recommended strategies are >>>>> specified >>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>> these strategies depends on the actual deployment situation of >>>>> middleboxes. Therefore experimental verification to confirm large= - >>>>> scale path traversal in the Internet is needed before finalizing >>>>> this >>>>> specification on the Standards Track. >>>>> >>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>> >>>> mentioned before, I don't think an RFC should speculate about TCPM and >>>> its >>>> consensus opinion. I would suggest a wording along the lines of: >>>>> >>>>> >>>>> The experimental protocol will be considered successful if >>>>> testing confirms that the proposed mechanism can be deployed at >>>>> large >>>> >>>> scale. >>>>> >>>>> Testing will mostly focus on fall-back strategies in case of >>>>> middlebox interference. Current recommended strategies are >>>>> specified >>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>> these strategies depends on the actual deployment situation of >>>>> middleboxes. Therefore experimental verification to confirm large= - >>>>> scale path traversal in the Internet is needed, e.g., by support i= n >>>>> major TCP stacks. >>>>> >>>>> >>>> I don=E2=80=99t understand your point here. I don=E2=80=99t think that= the paraphrase >>>> speculates about the consensus of tcpm, in contrast it say tcpm has to >>>> decided if the requirements previously specified by tcpm are >>>> sufficiently >>>> fulfilled. I don=E2=80=99t see a reason to not mention the requirement= draft as >>>> this >>>> draft as tcpm consensus and was written for this purpose. >>> >>> My suggested wording uses the expression "can be deployed at large scal= e" >>> and I believe this is relevant. >>> >>> The document already describes in Section 5 how the protocol satisfies >>> the agreed requirements for a more accurate ECN feedback protocol [RFC7= 560]. >>> So, if the TCPM working group publishes this document with the content = of >>> Section 5, I believe the TCPM working group already has reached consens= us >>> that the protocol meets requirements. In addition, it is possible that = new >>> requirements would be identified in future, e.g., as an outcome of the >>> experiment, and that would obviously have to be considered by TCPM. In = that >>> case, for the success of the experiment not only RFC 7560 would matter,= but >>> also further requirements. My proposed wording does not have all these >>> problems. >>> >>> In a nutshell, I continue to believe that this section has to change. >> >> >> Okay, used your proposed wording. You have a point about the requirement >> and I mis-read you proposal earlier as =E2=80=9Ehas to be deployed large= -scale=E2=80=9C. >> >>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>> >>>>> [ms] This section could probably be shortened as well. >>>>> >>>>> The last bit in byte 13 of the TCP header was defined as the Nonce >>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deployed >>>>> so >>>>> it is being reclassified as historic, making this TCP flag availab= le >>>>> for use by the AccECN experiment instead. >>>>> >>>>> [ms] This wording, as well as Figure 1, needs to take into account th= e >>>>> IANA >>>> >>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>> >>>> Is does. However, I can explicitly say that is has be re-clssified as >>>> reserved. >>>> >>>> "RFC 3540 was never deployed so it is being reclassified as historic >>>> [I-D.ietf- >>>> tsvwg-ecn-experimentation] and the respective flag has been marked as >>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags registry, maki= ng this TCP flag >>>> available for use by the AccECN experiment instead.=E2=80=9C >>>> >>>> Better? >>>> >>>>> In my understanding, this experimental document asks for new assignme= nt >>>> >>>> of a reserved TCP header flag. >>>> >>>> As I said I=E2=80=99m not sure if we have fully concluded this discuss= ion yet. >>>> However, >>>> what we really would want to is mention somewhere that this experiment >>>> with this flags is running. I guess there are three options: >>>> 1) keep it in the registry as reserved and conserve the knowledge in >>>> tcpm >>>> that this experiment is running and no other experimental RFC such use >>>> this >>>> flags as long as this experiment is running. >>>> 2) Keep is marked as reserved but add a note about this experiment in >>>> the >>>> IANA registry >>>> 3) Or assign it right away with IESG approval. I guess in this case tc= pm >>>> could >>>> also consider to change the registration policy to =E2=80=9EIETF Revie= w=E2=80=9C. >>> >>> The current registration policy for the TCP header flags is "standards >>> action". I understand that the IESG could approve exceptions. But given= the >>> policy, I believe the document has to be very precise on the request >>> regarding bit 7. >> >> Okay, it now says: >> >> "[TO BE REMOVED: IANA is requested to update the existing entry in the >> Transmission Control Protocol (TCP) Header Flags registration >> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtm= l#tcp-header-flags-1) >> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS (Nonc= e >> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be inst= ead >> of RFC8311.]=E2=80=9C >> >> I guess we could also ask IANA to add an additional comment column inste= ad >> (but not sure if we then have to update RFC3168, which I think we really >> don=E2=80=99t want. Should be fine now. >> >>>>> * 2. AccECN Protocol Overview and Rationale >>>>> >>>>> o an essential part that re-uses ECN TCP header bits to feed back >>>>> the number of arriving CE marked packets. This provides more >>>>> accuracy than classic ECN feedback, but limited resilience >>>>> against >>>>> ACK loss; >>>>> >>>>> [ms] The word "re-use" is IMHO not correct. >>>> >>>> I think this is nit picking. Using a different phrasing here makes the >>>> sentence >>>> unnecessary complicated. We don=E2=80=99t try to some how get a round = the fact >>>> that we need to handle the flag registration correctly. However, here >>>> the >>>> point really is to explain how the protocol word. The main point of >>>> using the >>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that these fl= ags are or have >>>> been >>>> used different by other TCP extension (and we therefore need a proper >>>> negotiation scheme). >>> >>> If the allocation of a reserved flag is correctly explained in the >>> abstract and introduction, I think these sentences can use a bit relaxe= d >>> terminology. >>> >>>>> The two part design was necessary, given limitations on the space >>>>> available for TCP options and given the possibility that certain >>>>> incorrectly designed middleboxes prevent TCP using any new options= . >>>>> >>>>> [ms] IMHO it would make sense to more explicitly mention the downside= s >>>> >>>> of only specifying an option and not allocating a TCP header flag, in >>>> this >>>> experimental document. >>>> >>>> We need to use the flags (all three of them) for the negotiation. >>> >>> I think that an explanation why negotiation by a TCP option would not >>> solve all use cases (or requirements) would help here. >>> >>>>> The obvious alternative would be to postpone the header flag >>>>> allocation to >>>> >>>> a follow-up standards track document and just keep it reserved. >>>> >>>> We can still do that. We should discuss and make a final decision. >>>> >>>>> The essential part overloads the previous definition of the three >>>>> flags in the TCP header that had been assigned for use by ECN. Th= is >>>>> design choice deliberately replaces the classic ECN feedback >>>>> protocol, rather than leaving classic ECN feedback intact and addi= ng >>>>> more accurate feedback separately because: >>>>> >>>>> [ms] Similar like previous comments, in my reading there are only _tw= o_ >>>> >>>> ECN header flags. >>>> >>>> I think there are three flags that "had been assigned for use by ECN= =E2=80=9C as >>>> ECN >>>> Nonce is also an ECN mechanism. The fact that one of the flags is now >>>> marked as reserved instead, it not that important for me here. >>>> >>>>> And, in addition, I think care is needed with wording such "replaces >>>>> the >>>> >>>> classic ECN feedback". I don't think this experiment replaces the ECN >>>> standards. That would be up to a follow-up PS. >>>> >>>> This sentence is not meant to say that RFC3168 is replaced. Actually w= e >>>> don=E2=80=99t. >>>> You can still use RFC3168 even if AccECN is implemented and deploy >>>> (however, we do intent that AccECN will be used as the default scheme = in >>>> future and RFC3168 is hopefully simply not needed anymore at some poin= t, >>>> even though you probably still need to have it implemented as the >>>> negotiation specified in this draft covers that as well, anyway...). T= he >>>> sentence says that if AccECN is negotiation, the header flags as used = by >>>> RFC3168 and previously ECN Nonce are used differently (aka re-used). >>>> That=E2=80=99s >>>> all. >>>>> >>>>> >>>>> 2.1. Capability Negotiation >>>>> >>>>> AccECN is a change to the wire protocol of the main TCP header, >>>>> therefore it can only be used if both endpoints have been upgraded >>>>> to >>>>> understand it. The TCP client signals support for AccECN on the >>>>> initial SYN of a connection and the TCP server signals whether it >>>>> supports AccECN on the SYN/ACK. The TCP flags on the SYN that the >>>>> client uses to signal AccECN support have been carefully chosen so >>>>> that a TCP server will interpret them as a request to support the >>>>> most recent variant of ECN feedback that it supports. Then the >>>>> client falls back to the same variant of ECN feedback. >>>>> >>>>> [ms] As this is an experimental specification, I would really like to >>>>> see a >>>> >>>> discussion how a future standards track version of more accurate ECN >>>> could >>>> be negotiated. >>>> >>>> As described in this draft. There will be no different. AccECN IS and >>>> will >>>> always be backward compatible with RFC3168. >>> >>> That is not the problem I think about. I wonder about a PS version of >>> accurate ECN feedback that would possibly include changes as compared t= o >>> this experiment, e.g., because the experiment may have some lessons lea= rnt. >>> What options would we have to negotiate the PS version, and how could a >>> stack implementing the PS version figure out whether the remote end use= s the >>> experimental or the PS version of the protocol? >>> >>> The reason why I ask is because I don't see any easy solution to this b= ut >>> I may miss something. Maybe this would not be a concern if there were s= ome >>> codepoints left. >>> >>>>> How could both endpoints detect whether the other one implements the >>>> >>>> future standards track version? >>>> >>>> If the initiator implements AccECN it will request it=E2=80=99s use. I= f the >>>> receiver also >>>> implement it, it will/can negotiate it, if not it will look like an >>>> RFC3168 request >>>> for the receiver (as the NS flags will be ignored in the SYN) and it >>>> will >>>> negotiate RFC3168 ECN feedback if implemented. There is no additional >>>> detection needed. >>> >>> My concern is the migration strategy for a future version, given that w= e >>> only experiment right now. For instance, if the initiator implements th= e >>> experimental version but the recipient implements the PS version of Acc= ECN, >>> how would that work? Under the assumption that there are changes, would >>> there be a way to know? Maybe the answer to this question is no, given = the >>> small number of bits we have. But not having any room for extensions is= not >>> necessarily good protocol design. >>> >>>>> For instance, would the only safe variant be that we allocate yet >>>>> another >>>> >>>> reserved TCP header flag in a proposed standard to negotiate the >>>> standards >>>> track version, thus investing another reserved bit in the TCP header? >>>> >>>> No, that=E2=80=99s exactly what we use the NS flags for in the handsha= ke. >>> >>> If the PS version of AccECN was different to the experimental version o= f >>> AccECN, and if there was a deployed base of both, I still believe we co= uld >>> end up in a situation in which we had to allocate yet another TCP heade= r >>> flag to distinguish the different versions of AccECN. The NS flag would= not >>> work for that if it is used by the experimental version. The risk of ha= ving >>> to spend further TCP header flags somehow concerns me. Of course, that >>> problem would only matter if the AccECN experiment succeeds somehow, bu= t >>> lessons learnt would require protocol changes, which is speculation. >>> >>>>> I may be wrong, but to me it is too early to speculate how the PS >>>>> version >>>> >>>> would look like, and whether it would have to be different to the >>>> experimental version, due to lessons learnt. >>>> >>>> Of course you can always be wrong. However, the handshake negotiation = is >>>> not the part we need experimentation for. That part is straight forwar= d >>>> and >>>> works. If we really happen to detect a problem in that part, we would >>>> need >>>> to end the experiment declare failure and start over new. >>> >>> My concern is ending the experiment when the experiment got (partly) >>> deployed in the Internet. In that case neither a new RFC nor a change o= f the >>> IANA registry will solve the migration issue. >>> >>>>> I believe in the IETF we typically design protocols that allow future >>>> >>>> extension, and it is not exactly clear to be how AccECN could be >>>> extended >>>> later. >>>> >>>> This is an TCP extension. If we want future extension we use the usual= ly >>>> TCP >>>> mechanism (by defining a new TCP option I guess). >>> >>> The root cause of my concern is that this proposal does *not* use the >>> usual way to experiment with TCP by options. It experiments with a head= er >>> flag, including in the SYN, and it seems to consume all codepoints. So,= I >>> see the risk of a protocol design "not ready for future improvements". >>> >>> I cannot easily propose text. Maybe "lack of extensibility" is just one >>> of the short-comings of the protocol design that cannot be avoided but = that >>> short-coming would have to be noted. >>> >>>>> An AccECN TCP client does not send the new AccECN Option on the SY= N >>>>> as SYN option space is limited and successful negotiation using th= e >>>>> flags in the main header is taken as sufficient evidence that both >>>>> ends also support the AccECN Option. The TCP server sends the >>>>> AccECN >>>>> Option on the SYN/ACK and the client sends it on the first ACK to >>>>> test whether the network path forwards the option correctly. >>>>> >>>>> [ms] For what it is worth, I would personally be quite fine with >>>>> allowing (or >>>> >>>> even mandating) an option in the SYN in the experimental version of th= is >>>> protocol. For instance, saving the SYN option space would then an >>>> excellent >>>> reason for moving towards the PS specification. I am also fine with >>>> being in >>>> the rough part of the consensus here. >>>> >>>> The point is that we really don=E2=80=99t need the option in the SYN a= s we don=E2=80=99t >>>> use it >>>> for negotiation purposes as we use the header bits instead. So why >>>> should >>>> we waste the space? >>> >>> For instance, mandating the option in the SYN would be away for the >>> receiver to distinguish the experiment from a follow-up PS version of t= he >>> spec, as the PS version may not mandate the option, to save header spac= e. >>> >>> Maybe that proposal does not make any sense, and it may only have >>> downsides. But the document already speculates about a PS-follow-up. So= it >>> seems a valid question to ask if the EXP and the PS version of the spec= have >>> to be identical. This all comes down to the SYN negotiation. >>> >>>>> * 2.3. Delayed ACKs and Resilience Against ACK Loss >>>>> >>>>> If the AccECN Option is not available, e.g. it is being stripped b= y >>>>> a >>>>> middlebox, the AccECN protocol will only feed back information on = CE >>>>> markings (using the ACE field). Although not ideal, this will be >>>>> sufficient, because it is envisaged that neither ECT(0) nor ECT(1) >>>>> will ever indicate more severe congestion than CE, even though >>>>> future >>>>> uses for ECT(0) or ECT(1) are still unclear >>>>> [I-D.ietf-tsvwg-ecn-experimentation]. >>>>> >>>>> [ms] This needs to be reworded >>>> >>>> Why? >>>> >>>>> >>>>> >>>>> * 2.4. Feedback Metrics >>>>> >>>>> The CE packet counter in the ACE field and the CE byte counter in >>>>> the >>>>> AccECN Option both provide feedback on received CE-marks. The CE >>>>> packet counter includes control packets that do not have payload >>>>> data, while the CE byte counter solely includes marked payload >>>>> bytes. >>>>> If both are present, the byte counter in the option will provide t= he >>>>> more accurate information needed for modern congestion control and >>>>> policing schemes, such as DCTCP or ConEx. >>>>> >>>>> [ms] I suggest to write in the last sentence only "... the option wil= l >>>>> provide >>>> >>>> the more accurate information needed for congestion control". In >>>> general, I >>>> would prefer to have references to other mechanisms at only few (ideal= ly >>>> a >>>> *single*) places in the document, instead of mixing them together. >>>> >>>> Sorry, I don=E2=80=99t see your point here. ConEx has been mentioned p= reviously, >>>> so >>>> why not also mention it here. >>> >>> As written earlier, in my understanding DCTCP does not "need" this. I >>> would suggest to have one place where to define exactly how this mechan= ism >>> can be used by other TCP extensions. Having said this, in this specific >>> paragraph I am less concerned about that than elsewhere. >>> >>>>> Feedback in bytes is recommended in order to protect against the >>>>> receiver using attacks similar to 'ACK-Division' to artificially >>>>> inflate the congestion window, which is why [RFC5681] now recommen= ds >>>>> that TCP counts acknowledged bytes not packets. >>>>> >>>>> [ms] At least the last part and the reference to RFC 5681 is IMHO not >>>> >>>> needed here. >>>> >>>> Why? RFC5681 explains/refers the ACK division attack, so I think it is= a >>>> very >>>> good reference to have here. >>>>> >>>>> >>>>> >>>>> * 2.5. Generic (Dumb) Reflector >>>>> >>>>> The ACE field provides information about CE markings on both data >>>>> and >>>>> control packets. According to [RFC3168] the Data Sender is meant = to >>>>> set control packets to Not-ECT. However, mechanisms in certain >>>>> private networks (e.g. data centres) set control packets to be ECN >>>>> capable because they are precisely the packets that performance >>>>> depends on most. >>>>> >>>>> For this reason, AccECN is designed to be a generic reflector of >>>>> whatever ECN markings it sees, whether or not they are compliant >>>>> with >>>>> a current standard. Then as standards evolve, Data Senders can >>>>> upgrade unilaterally without any need for receivers to upgrade too= . >>>>> It is also useful to be able to rely on generic reflection behavio= ur >>>>> when senders need to test for unexpected interference with marking= s >>>>> (for instance [I-D.kuehlewind-tcpm-ecn-fallback] and >>>>> [I-D.moncaster-tcpm-rcv-cheat]). >>>>> >>>>> The initial SYN is the most critical control packet, so AccECN >>>>> provides feedback on whether it is CE marked. Although RFC 3168 >>>>> prohibits an ECN-capable SYN, providing feedback of CE marking on >>>>> the >>>>> SYN supports future scenarios in which SYNs might be ECN-enabled >>>>> (without prejudging whether they ought to be). For instance, >>>>> [I-D.ietf-tsvwg-ecn-experimentation] updates this aspect of RFC 31= 68 >>>>> to allow experimentation with ECN-capable TCP control packets. >>>>> >>>>> [ms] To me, the only thing that matters in this document that AccECN >>>>> can >>>> >>>> provide feedback on whether the SYN is CE marked. The discussion on ho= w >>>> to experiment with ECT e.g. in SYNs IMHO does not belong into this >>>> document. So it seems sufficient here to note that one of the benefits >>>> of >>>> AccECN is that CE marks in SYNs can be fed back. >>>> >>>> I disagree. Explicitly saying that AccECN is only an feedback scheme a= nd >>>> DOES >>>> NOT define how the information is used is VERY important because peopl= e >>>> come back to me over and over again and mix these things up. >>>>> >>>>> >>>>> * 3.1.1. Negotiation during the TCP handshake >>>>> >>>>> Given the ECN Nonce [RFC3540] is being reclassified as historic, t= he >>>>> present specification renames the TCP flag at bit 7 of the TCP >>>>> header >>>>> flags from NS (Nonce Sum) to AE (Accurate ECN) (see IANA >>>>> Considerations in Section 6). >>>>> >>>>> [ms] As mentioned before, this needs to be rewritten to ask for new >>>>> IANA >>>> >>>> allocation of bit 7 in the TCP header flags. >>>> >>>> I really don=E2=80=99t understand this comment. That is what the IANA = section >>>> does >>>> as referred here correctly. >>> >>> In my reading of >>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtm= l, >>> this flag currently has no name, i.e., it does not have the name NS. So= this >>> statement on "renaming" is formally incorrect IMHO. >>> >>> I'd suggest something like: "This specification assigns the name AE >>> (Accurate ECN) to the TCP flag at bit 7; this flag has previously been = known >>> as NS (Nonce Sum) =E2=80=A6". >> >> Now: >> >> "Given the ECN Nonce has been >> reclassified as historic , the pres= ent >> specification re-allocates the TCP >> flag at bit 7of the TCP header flags, which was previously >> called NS >> (Nonce Sum), as the AE >> (Accurate ECN) flag (see IANA Considerations in > target=3D"accecn_IANA_Considerations"/>)." >>>> >>>> Again, yes, we can discuss if this document should do this, but if >>>> published as >>>> it is, section 6 says everything that is needs to say. (I does not put >>>> any >>>> request on IANA, instead it is written as it would show up >>>> post-publication, >>>> implicitly providing a request to IANA at approval time. That is fine.= ) >>>> >>>>> Table 2: ECN capability negotiation between Client (A) and Server >>>>> (B) >>>>> >>>>> [ms] As far as I can see, in -05 this table allocates all existing >>>>> codepoints, >>>> >>>> while -03 had two currently unused codepoints. Not having any codepoin= ts >>>> left seems to me not really future proof, e.g., regarding future >>>> proposed >>>> standards in this space (and I personally believe that TCP header flag= s >>>> must >>>> be allocated in a PS). And I don't fully see a need of feeding back EC= T0 >>>> and >>>> specifically ECT1 in the TCP header flags as part of the experiment. D= o >>>> we >>>> know for sure that this is the only possible use case of these two >>>> unallocated >>>> header bits? And why can't e.g. this be done in a TCP option instead? = Or >>>> do I >>>> miss something? >>>> >>>> The point is really, if we don=E2=80=99t assign them now and start dep= loyment we >>>> effetely we not be able to every assign them again because don=E2=80= =99t have a >>>> different negotiation mechanisms. Realizing this, it is just the right >>>> think to >>>> define the space completely that is negotiated as use for AccECN in th= e >>>> handshake. >>> >>> I disagree that consuming all codepoints and not having room for future >>> extensions is the "right thing" to do. It is in fact the wrong thing. B= ut >>> possibly there is no alternative with the few bits, so maybe we end up = doing >>> it. >>> >>> Yet, at minimum, using all codepoints needs to be reasoned in the >>> document. Specifically since in -03 a different protocol design seemed >>> possible, which looked to me more future-proof. >>> >>>>> * 3.1.2. Retransmission of the SYN >>>>> >>>>> However, >>>>> current measurements imply that a drop is less likely to be due to >>>>> middlebox interference than other intermittent causes of loss, e.g= . >>>>> congestion, wireless interference, etc. >>>>> >>>>> [ms] Such wording IMHO doesn't belong into normative text. This may >>>> >>>> actually also apply to other heuristics discussed in this section, whi= ch >>>> are not >>>> really important for interoperability. >>>> >>>> I don=E2=80=99t really understand your point. This sentence is solely = meant to >>>> reason >>>> the design decision to not say that a sender SHOULD attempt to re- >>>> negotiation after a loss. >>> >>> One could split the reasoning from the normative design. The normative >>> specification may still be relevant in 20 years from now. Middleboxes w= ill >>> almost likely be different in 20 years. Having said this, this is more = of an >>> editorial remark. >>> >>>>> 3.2.7. Path Traversal of the AccECN Option >>>>> >>>>> 3.2.7.1. Testing the AccECN Option during the Handshake >>>>> >>>>> The TCP client MUST NOT include the AccECN TCP Option on the SYN. >>>>> >>>>> [ms] I am not sure if I really understand the motivation for not >>>>> allowing a >>>> >>>> option in the SYN. If the sender has space in the SYN left, what is th= e >>>> harm in >>>> an experimental version of the protocol? And I may miss something, but >>>> what would prevent the use of 2-byte option to negotiate the use of >>>> AccECN, e.g., to avoid experimental allocation of bit 7 in the initial >>>> SYN? >>>> >>>> I did have a draft on that as a proposal for an alternative design. >>>> However, >>>> the gourd was more supportive of this design as it is proof of middleb= ox >>>> SYN >>>> option mangling which is a know problem. >>>> >>>> Therefore we simply don=E2=80=99t need option in the SYN and there is = no reason >>>> to >>>> waste the space. >>>> >>>>> While I think many tutorial text in this document could be shortened,= I >>>> >>>> believe the use of a reserved TCP header flag should be reasoned. >>>> >>>> I=E2=80=99m actually uncertain what you expect here. >>> >>> For instance, this reply with the explanation of SYN option mangling >>> seems useful explanation. >>> >>>>> * 3.2.8. Usage of the AccECN TCP Option >>>>> >>>>> The following rules determine when a Data Receiver in AccECN mode >>>>> sends the AccECN TCP Option, and which fields to include: >>>>> >>>>> Change-Triggered ACKs: If an arriving packet increments a differe= nt >>>>> byte counter to that incremented by the previous packet, the Da= ta >>>>> Receiver MUST immediately send an ACK with an AccECN Option, >>>>> without waiting for the next delayed ACK (this is in addition t= o >>>>> the safety recommendation in Section 3.2.5 against ambiguity of >>>>> the ACE field). >>>>> >>>>> This is stated as a "MUST" so that the data sender can rely on >>>>> change-triggered ACKs to detect transitions right from the very >>>>> start of a flow, without first having to detect whether the >>>>> receiver complies. A concern has been raised that certain >>>>> offload >>>>> hardware needed for high performance might not be able to suppo= rt >>>>> change-triggered ACKs, although high performance protocols such >>>>> as >>>>> DCTCP successfully use change-triggered ACKs. >>>>> >>>>> [ms] To me this sounds like a perfect example for a SHOULD with >>>>> additional >>>> >>>> guidance why implementing this SHOULD is really important. >>>> >>>> This is one of the most discussed point from the author and we really >>>> tried to >>>> get additional guidance here of what to do also from outside the IETF >>>> but did >>>> no clear feedback. >>>> >>>> As explained this MUST enables additional functionality. However, this >>>> is an >>>> experiment document. If we detect that this MUST does actually hinder >>>> implementation or has just never been implemented, we should reconside= r >>>> this in the final PS RFC. >>>> >>>> I was on the SHOULD side of the discussion, but can say that the >>>> implementation in Linux was way more simple then expected. Offloading >>>> might be a different topic but that is where I could not get a clear >>>> feedback >>>> and offloading could probably be anyway optimized for use with AccECN >>>> (if it >>>> gets deploy widely). >>> >>> If a MUST requires changes in hardware, I think there must be a clear >>> reason. >>> >>> As individual contributor, with the current explanation in the text, I >>> believe this has to be a SHOULD. >>> >>>> I though we added this as something to mention in the exp goals sectio= n, >>>> but >>>> obviously we didn=E2=80=99t. I added the following text now: >>>> >>>> "Another experimentation focus is the implementation feasibiliy of >>>> change- >>>> triggered ACKs as described in section 3.2.8. While on average this >>>> should not >>>> lead to a higher ACK rate, it changes the ACK patter which especially >>>> can have >>>> an impact on hardware offload. Further experimentation is needed to >>>> advise >>>> if this should a hard requirement or just prefer behavior.=E2=80=9C >>> >>> If it is unclear if a MUST can actually be implemented, having a MUST i= s >>> in my opinion the wrong approach. >>> >>> One could equally state here that further experimentation is needed to >>> determine whether the SHOULD can be upgraded to a MUST. >> >> I=E2=80=99m still open for everything here, but I believe this was discu= ssed and >> agreed in the working group=E2=80=A6? >> >> >>>>> For the avoidance of doubt, the change-triggered ACK mechanism is >>>>> deliberately worded to ignore the arrival of a control packet with >>>>> no >>>>> payload, which therefore does not alter any byte counters, because >>>>> it >>>>> is important that TCP does not acknowledge pure ACKs. The change- >>>>> triggered ACK approach will lead to some additional ACKs but it >>>>> feeds >>>>> back the timing and the order in which ECN marks are received with >>>>> minimal additional complexity. >>>>> >>>>> [ms] The additional acks create network load. I think some wording is >>>> >>>> needed on the tradeoff between information accuracy and network load. >>>> There are network environments in which any additional packet is very >>>> expensive (e.g., energy) and it is not clear to me how the protocol >>>> design >>>> takes into account the potential overhead of additional ACKs. Maybe th= is >>>> could be another reason for a SHOULD. >>>> >>>> The above. However, this is not really an additional ACK because you d= o >>>> delay the next one. Further experimentation needed. >>> >>> The document states "lead to some additional ACKs". If that does not >>> increase network load, I think it has to be explicitly explained why th= e ACK >>> load is at most equal to a current TCP stack, in all potential cases. I= f it >>> can increases network load, it has to be reasoned why increasing load (= and >>> risk of reverse congestion and the like) is worth the effort. >>> >>> I agree that this may be an area of experimentation, but I believe then >>> it has to be explained to implementers what the tradeoffs are. >> >> Added: >> "Especially, if only few >> CE marks occurred or multiple marks in a row, the additional >> load will >> be low. Other, unexpected marking pattern could increase the >> load >> significantly, however, investigating the additional load it >> part >> of the proposed experimentation." >>>>> >>>>> * 4.2. Compatibility with Other TCP Options and Experiments >>>>> >>>>> AccECN is compatible (at least on paper) with the most commonly us= ed >>>>> TCP options: MSS, time-stamp, window scaling, SACK and TCP-AO. It >>>>> is >>>>> also compatible with the recent promising experimental TCP options >>>>> TCP Fast Open (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824]). >>>>> >>>>> [ms] I would suggest the wording "... compatible with the experimenta= l >>>> >>>> TCP options ..." or even "... compatible with the TCP options =E2=80= =A6". >>>> >>>> These option are to experimental..? >>> >>> "It is also compatible with the experimental TCP options TCP Fast Open >>> (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824])." would have same >>> technical meaning. Having said this, this is editorial only. >>> >>>> The point of using =E2=80=9Ecommonly used=E2=80=9C was to say that we = checked on those >>>> as >>>> they seem important. Just because your favorite experiment option is n= ot >>>> listed here it doesn=E2=80=99t means it incompatible, we just didn=E2= =80=99t check. I=E2=80=99m >>>> okay to >>>> removed =E2=80=9Ecommonly used=E2=80=9C but I don=E2=80=99t think it m= akes anything better. >>>> >>>>> * 4.3. Compatibility with Feedback Integrity Mechanisms >>>>> >>>>> [ms] Quite a bit in this section is experimental work, which IMHO >>>>> should be clearly emphasized. The one exception is=E2=80=A6 >>>> >>>> I would really like to keep this section because integrity is usually >>>> the fist >>>> question that come up when I present AccECN. Effectively these are two >>>> independent topics, however, I really think it help people to understa= nd >>>> the >>>> whole picture if this is also discussed in this document. >>>> >>>>> However, TCP-AO is often too brittle to use on many end-to-end >>>>> paths, where middleboxes can make verification fail in their >>>>> attempts to improve performance or security, e.g. by >>>>> resegmentation or shifting the sequence space. >>>>> >>>>> [ms] I am not sure if deployment challenges of other options need to = be >>>> >>>> discussed in this document. >>>> >>>> If we keep the discussion, I guess we should mention this as well. As >>>> the doc >>>> clearly stated section 4 is not meant to be normative. >>> >>> As far as I can see, there are use cases for TCP-AO where middleboxes a= re >>> simply not a problem, but it is exactly this sort of discussion that ma= y not >>> be needed in this document. But I won't rat-hole on this comment here. >>> >>>>> Originally the ECN Nonce [RFC3540] was proposed to ensure integrit= y >>>>> of congestion feedback. With minor changes AccECN could be >>>>> optimised >>>>> for the possibility that the ECT(1) codepoint might be used as an >>>>> ECN >>>>> Nonce . However, given RFC 3540 is being reclassified as historic, >>>>> the AccECN design has been generalised so that it ought to be able >>>>> to >>>>> support other possible uses of the ECT(1) codepoint, such as a low= er >>>>> severity or a more instant congestion signal than CE. >>>>> >>>>> [ms] The discussion of RFC 3540 can probably be removed to a large >>>>> extent. >>>> >>>> Unfortunately, please still think that ECN Nonce, even though is was >>>> never >>>> deployed and doesn=E2=80=99t really work, is the only was to provide i= ntegrity >>>> protection and we need it as a prerequisite to deploy ECN at all=E2=80= =A6 i >>>> would >>>> really prefer to keep this in this non-normative part of the doc. >>>> >>>>> >>>>> * 6. IANA Considerations >>>>> >>>>> [ms] I think this section needs to be rewritten to request a new >>>>> allocation >>>> >>>> of bit 7 of the TCP header flags. At least for the process I think it >>>> would make >>>> sense to have somewhere in the document a comprehensive explanation of >>>> why an experimental document requests a change of the main TCP header, >>>> and why this cannot be avoided (most notably in the initial SYN) by an >>>> alternative protocol design. >>>> >>>> As I said previously this section is written as it would look like aft= er >>>> the >>>> allocation has happened with publication approval of the IESG. This is >>>> fine. >>>> >>>> Having a discussion about an experiment doc assigning a flag (or not) = is >>>> a >>>> question for tcpm as a whole and not specifically this document. How d= o >>>> we >>>> envision to every use any further flags? We go to PS right away? Or >>>> should >>>> we change the registration policy? For me the latter makes actually mo= re >>>> sense. However, if we don=E2=80=99t want/can to decide this now, we al= so could >>>> go >>>> forward as it is with IESG approval. However, is this case it is also >>>> not needed >>>> to explain this in the document. The responsible AD has to explain thi= s >>>> to the >>>> other IESG probably in the ballot or even better the shepherd could >>>> provide >>>> these information in the write-up. >>>> >>>>> >>>>> * 9. Comments Solicited >>>>> >>>>> Comments and questions are encouraged and very welcome. They can >>>> >>>> be >>>>> >>>>> addressed to the IETF TCP maintenance and minor modifications >>>>> working >>>>> group mailing list , and/or to the authors. >>>>> >>>>> [ms] This section is not needed IMHO >>>> >>>> Yes, it will be removed before publication. >>>>> >>>>> >>>>> 10. References >>>>> >>>>> [I-D.ietf-tsvwg-ecn-experimentation] >>>>> Black, D., "Relaxing Restrictions on Explicit Congestio= n >>>>> Notification (ECN) Experimentation", >>>>> draft-ietf-tsvwg-ecn- >>>>> experimentation-07 (work in progress), October 2017. >>>>> >>>>> [ms] Normative reference? >>>> >>>> Don=E2=80=99t see why. No need to read ietf-tsvwg-ecn-experimentation = to >>>> understand the spec in this doc. >>>> >>>> Thanks! >>>> Mirja >>>> >> _______________________________________________ >> 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 From nobody Wed Jul 11 15:53:01 2018 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 98EF4130EAF; Wed, 11 Jul 2018 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 d0Ac78xN4VnR; Wed, 11 Jul 2018 15:52:50 -0700 (PDT) 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 23486130E5D; Wed, 11 Jul 2018 15:52:49 -0700 (PDT) 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=w+TG7jZXdE69mN0idnRyW/vJnXvvYFsbmrya89ZaQco=; b=ScbKh4+rjku1aK+8leLf4HDeXl wHmXhBPBAVip3BoWS9wVZEACplW5sFC7HtixjgR7KUM40sEp/p6/ThtVDQ0JanXH+7Tq7dr/prlQK vkkBtJUpyuGvgqOae0xrgQc9C1FocDzY8cBaWeluUhE0c6vj7iOBN1tq6mPpowTMUFTOf1m4iVRen P9QoEkbqAitgRaoPmUC+9wYPXYu49+6xTpKPEW3X87DPffwlYtU9+9ot5ogF8Ku6ZK80bp/zBcIts TzBMa8DkSSFkJxuWQxwBjTRvDJGv/3GTcaZ2nYHzyfD1lzIqIiI3PSNgP8UPmphaSB4rWkozcPfny d/mo6VOA==; Received: from 70.245.199.146.dyn.plus.net ([146.199.245.70]:51134 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fdNyZ-0000Ub-1D; Wed, 11 Jul 2018 23:52:47 +0100 To: Yuchung Cheng Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> From: Bob Briscoe Message-ID: <07dacfdf-232a-b82e-7f41-fa5ce1f1853a@bobbriscoe.net> Date: Wed, 11 Jul 2018 23:52:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 22:52:55 -0000 Yuchung, On 11/07/18 19:35, Yuchung Cheng wrote: > Hi Bob, > > Neal and I evaluated the earlier draft. It is well-thought out but > we're concerned about the options. Option is not mandatory but the > lack of it also reduces accuracy. Option runs into space issues w/ > SACK and offload issues w/ TSO/GRO. They can be addressed for sure but > aren't easy. We had various ideas for smart schemes to reduce the size of the option (the fields for the counters don't always need to be so wide and you often only need one field). However, we ended up opting for simplicity at the expense of space. If you're interested, we could dig out the ideas we had (between the co-authors) and see if you would prefer fewer option bytes but less simplicity. I assume you saw the rules around when an option can be suppressed. Search for the text around "Receiver MUST give precedence to SACK information about loss." Is there a specific issue with the option and TSO/GRO, or just that the h/w wouldn't understand what to do with this option? > We're curious how much more "accuracy" it buys over current > DCTCP-style ECN. Is there any study to show trade-offs of > full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? There's a brief summary of the problem with DCTCP-style feedback in the appendix of the AccECN Requirements RFC here: https://tools.ietf.org/html/rfc7560#appendix-A Essentially, the DCTCP scheme relies on the sender using the feedback to keep its copy of the receiver's state machine in sync, which can get out of sync in the presence of pure ACK losses and therefore become highly ambiguous. Even if there are no ACK losses for a while, it can look like a gap could have been caused by a loss - the sender cannot guess what might have happened. The state machine gets back into sync once losses stop. However, DCTCP feedback is change-triggered so the sender cannot predict which ACKs it should receive and which not. That combines with 2 potential reasons for a gap in the ACK stream: delayed ACK; or a lost pure ACK. All three factors combined cause considerable ambiguity. Bob > > > On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe wrote: >> Michael, tcpm list, >> >> As well as addressing your points, as Mirja has already mentioned below, we >> added a whole new appendix giving the rationale for the bits and codepoints >> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >> subsection also identifies space for future evolution. It also points to >> where rationale was already given in the body of the draft. >> >> The appendix is in the draft submitted last week, available here: >> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >> >> We'd be interested to hear whether this allays your concerns. >> >> We have asked to present this in Montreal as well. >> >> Cheers >> >> >> Bob >> >> >> On 02/07/18 16:54, Mirja Kühlewind wrote: >>> Hi Micheal, >>> >>> I addressed a couple of your comments below. >>> >>> For the other, bigger comments regarding extensibility, that I did not yet >>> address below, we plan to add a new section to the appendix to explain >>> extensibility options as previously discussed by mail. We will probably send >>> a separate email on that part. >>> >>> Mirja >>> >>> >>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>>> : >>>> >>>> Hi Mirja, >>>> >>>> Thanks a lot for the explanation. I won't follow-up on some of the >>>> editorial suggestions. >>>> >>>> Yet, I continue to believe that some formal wording in the document needs >>>> to change, as explained below. >>>> >>>> Thanks >>>> >>>> Michael (with no hat on) >>>> >>>> >>>>> -----Original Message----- >>>>> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>> >>>>> Hi Micheal, >>>>> >>>>> thanks for your feedback and sorry for my late reply. >>>>> >>>>> Please see inline. >>>>> >>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>>>> : >>>>>> Hi all, >>>>>> >>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix). I >>>>> believe this document needs further work before moving forward. >>>>>> Please find below my comments marked as [ms]. I have read the >>>>> document independent of the review from Gorry. I apologize if there is >>>>> duplication. >>>>>> Thanks >>>>>> >>>>>> Michael (with no hat on) >>>>>> >>>>>> >>>>>> ****************************** >>>>>> >>>>>> * Abstract: >>>>>> >>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or >>>>>> Data >>>>> Center TCP >>>>>> (DCTCP) need more accurate ECN feedback information whenever more >>>>>> than one marking is received in one RTT. >>>>>> >>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>>> suggest to >>>>> remove this, or replace it by a more generic statement that more >>>>> accurate >>>>> information can be useful for several TCP extensions. >>>>> >>>>> I disagree. Both ConEx and DCTCP need more accurate information. They do >>>>> not need the mechanism that is specified in this draft, however, this is >>>>> not >>>>> what the sentences is saying. >>>> In my understanding (as a non-native speaker), the use of the word "need" >>>> is not correct here. DCTCP as specified in RFC 8257 can be implemented >>>> without any such mechanism. >>>> >>>> What would work for me is something of the form "... Data Center TCP >>>> cannot get precise ECN feedback whenever more than one marking is received >>>> in one RTT“. >>> This is not correct. DCTP need more than one feedback signal per RTT and >>> therefore cannot use RFC3168; instead it implement it’s own feedback >>> mechanism. However, to avoid confusion such that people could assume DCTP >>> would not work without the accECN scheme as specified in this doc, I >>> rephrased to: >>> >>> "Recently, proposed >>> mechanisms like Congestion Exposure (ConEx >> target="RFC7713"/>), >>> DCTCP or L4S >> target="I-D.ietf-tsvwg-l4s-arch"/> need to know when more than one >>> marking is received in one RTT which is >>> information that cannot be provided by the feedback scheme as >>> specified in >>> ." >>> >>> >>>>>> This document specifies an >>>>>> experimental scheme to provide more than one feedback signal per RTT >>>>>> in the TCP header. Given TCP header space is scarce, it overloads >>>>>> the three existing ECN-related flags in the TCP header and provides >>>>>> additional information in a new TCP option. >>>>>> >>>>>> [ms] This statement needs to be rewritten to correctly reflect what is >>>>> requested from IANA. My understanding is that this experimental document >>>>> asks for allocation of a reserved TCP header flag. This needs to be >>>>> called out >>>>> prominently, IMHO. In addition, since this is not a standard, the >>>>> suggested >>>>> experimentation with the main TCP header must IMHO be explicitly >>>>> mentioned. I also suggest to have later in a document a section that >>>>> explicitly >>>>> explains why it is appropriate to modify the main TCP header in an >>>>> experiment. >>>>> >>>>> I don’t know if any requirement that IANA assignment need to be called >>>>> out >>>>> in the abstract but we can do that. However, I believe the question if >>>>> this >>>>> document should or should not assign the bit is still not completely >>>>> solved, or >>>>> is it? >>>> I believe this question will have to be reviewed during WGLC and, more >>>> importantly, IETF last call. For the moment, my concern is that the document >>>> correctly describes the IANA allocation. >>>> >>>> I would like to see here a statement such as : "Given TCP header space is >>>> scarce, this specification allocates a reserved header bit and overloads the >>>> two ECN flags in the TCP header ...“. >>> A bit lengthy but now: >>> >>> "Given TCP header space is >>> scarce, it allocates a reserved header bit, that was previously >>> used for >>> ECN-Nonce which was recently declared historic, and overloads the >>> two existing ECN flags in the TCP header. Further, additional >>> information can be provided in a new TCP option that however is not >>> used >>> on the TCP SYN." >>> >>>>>> * 1. Introduction >>>>>> >>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>>>> more accurate ECN feedback information whenever more than one >>>>> marking >>>>>> is received in one RTT. >>>>>> >>>>>> [ms] At least for RFC 8257 seems to be implementable withoit this. >>>>>> Instead >>>>> of stating a "need", it would IMHO make more sense to discuss the >>>>> benefits >>>>> of the suggested mechanism in this document of its own, independent of >>>>> other proposals. To me, this document should be independent of other >>>>> documents and specifically other experiments. We have to think about >>>>> cases >>>>> where not all experiments are successful. Then independent documents >>>>> will >>>>> be more future-proof in future. >>>>> >>>>> This is a naming collision… The sentence was meant to say that these >>>>> mechanisms new more accurate ECN feedback than provided today by >>>>> RFC3168 but it was not meant to say that these mechanism have to use the >>>>> scheme as specified in this document. >>>>> >>>>> I added the following part sentence: >>>>> >>>>> „Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need more >>>>> accurate ECN feedback information than provided by the feedback scheme >>>>> as specified in [RFC3168] whenever more than one marking is received in >>>>> one >>>>> RTT. This document specifies an alternative feedback scheme that >>>>> provides >>>>> more accurate information and could be used by these new TCP >>>>> extensions.“ >>>>> >>>>> Does this help? >>>> See my proposal for the abstract. I continue to disagree with the term >>>> "need" but I think this can be sorted out by another term. >>>> >>>>>> If AccECN progresses from experimental to the standards >>>>>> track, it is intended to be a complete replacement for classic TCP/ >>>>>> ECN feedback, not a fork in the design of TCP. >>>>>> >>>>>> [ms] This sentence should be removed, as this is speculation. >>>>> Why? It states an intent… and that’s the intent that we have. >>>>> >>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as the >>>>>> standards track specification for adding ECN to TCP. >>>>>> >>>>>> [ms] This sentence should be removed (or reworded) >>>>> Why? Does it help to add an only here: >>>>> >>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as the only >>>>> standards track specification for adding ECN to TCP.“ >>>> This wording is better. >>>> >>>>>> AccECN feedback overloads flags and fields in the main TCP header >>>>>> with new definitions, so both ends have to support the new wire >>>>>> protocol before it can be used. >>>>>> >>>>>> [ms] In my reading this experimental document asks for *new* allocation >>>>> of a reserved TCP header flag. >>>>> >>>>> Is this better? >>>>> >>>>> "AccECN feedback overloads the two existing ECN flags as well as the >>>>> currently reserved and previously called NS flag in the main TCP >>>>> header >>>>> with new definitions, so both ends have to support the new wire >>>>> protocol >>>>> before it can be used.“ >>>>> >>>>> I understand that you are not happy with the word „overload“ here but >>>>> the >>>>> point of this sentence really is that the flags can/could be used >>>>> differently >>>>> and therefore we need a new negotiation before we can use them. >>>> For me the following would work: "AccECN feedback overloads the two >>>> existing ECN flags and >>>> allocates the currently reserved and previously called NS flag in the >>>> main TCP header. >>>> Given the new definitions, both ends have to support the new wire >>>> protocol >>>> before it can be used." >>>> >>>> I believe the wording has to be crystal clear on the reservation of bit 7 >>>> when it is discussed the first time in the text. In follow-up sections, >>>> maybe shorter terms could be used. >>> Okay, now: >>> >>> "AccECN feedback overloads the two existing ECN flags and >>> allocates the currently reserved and previously called NS flag in the >>> TCP header, to be used as one field indicating the number of >>> congestion >>> experienced marked packets. Given the new definitions of these three >>> bits, >>> both ends have to support the new wire protocol before it can be >>> used. >>> Therefore during the TCP handshake the two ends use these three bit >>> in >>> the TCP header to negotiate the most advanced feedback protocol >>> that they can both support in a backward compatible way to >>> ." >>>>> If you prefer, we can also remove the NS flag in this list, as ECN Nonce >>>>> was >>>>> anyway never deployed. >>>>> >>>>>> For that we refer to [RFC3168] or any RFC that >>>>>> specifies a different response to TCP ECN feedback, for example: >>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>> Latency >>>>>> Low Loss Scalable (L4S) congestion control >>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], or >>>>>> Alternative Backoff with ECN (ABE) >>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>> >>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this paragraph can >>>>>> just >>>>> be deleted. If other experiments need more accurate feedback, it is up >>>>> to >>>>> them to explain how they would use this mechanism. This document should >>>>> focus on how to signal the feedback, not how to use that. >>>>> >>>>> Yes, that is what the paragraph says. Isn’t it better to be explicit >>>>> about this? >>>>> >>>>>> It is likely (but not required) that the AccECN protocol will be >>>>>> implemented along with the following experimental additions to the >>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>> retransmissions >>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/ >>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>> >>>>>> [ms] I am a big fan of simple, standalone documents. In my view, the >>>>>> TCPM >>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>> draft-ietf- >>>>> tcpm-generalized-ecn independent documents, which probably implies that >>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If experimentation >>>>> with ECT in SYN requires a combination, this could be done in a new, >>>>> third >>>>> document. Apart from having simpler focused documents, this could >>>>> significantly help later with moving forward documents to standards >>>>> track. >>>>> >>>>> I disagree, however, this is a discussion to have on draft-ietf-tcpm- >>>>> generalized-ecn. I don’t see a problem in providing a reference here >>>>> that >>>>> says „it is likely…“ and nothing more. >>>>>> >>>>>> >>>>>> * 1.1. Document Roadmap >>>>>> >>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>> introduction >>>>> and tutorial text with lot's of redundancy towards other documents. I >>>>> think >>>>> the document can be made much easier to read by shorten it. In many >>>>> cases >>>>> this is just an editorial change as there is redundancy. As one such >>>>> example, >>>>> just remove this section. >>>>> >>>>> I guess this a matter of taste. As an AD, I’m a big fan of short and >>>>> concise >>>>> documents, however, some redundancy can also help understanding, >>>>> especially if you explain things multiple times but with a different >>>>> level of >>>>> detail. I personally would not need the roadmap but I know many people >>>>> who find these things helpful and to be honest I don’t see how removing >>>>> this >>>>> part makes the doc any better. If you don’t want it, don’t read it. >>>>> >>>>>> * 1.2. Goals >>>>>> >>>>>> [ms] I think this section can also just be removed. >>>>> I have to say I also don’t see the point of removing this part. Given >>>>> we’ve >>>>> done the work on requirements, I think we should also link to this doc >>>>> somewhere. >>>>>> >>>>>> * 1.3. Experiment Goals >>>>>> >>>>>> TCP is critical to the robust functioning of the Internet, therefore >>>>>> any proposed modifications to TCP need to be thoroughly tested. The >>>>>> present specification describes an experimental protocol that adds >>>>>> more accurate ECN feedback to the TCP protocol. The intention is to >>>>>> specify the protocol sufficiently so that more than one >>>>>> implementation can be built in order to test its function, >>>>>> robustness >>>>>> and interoperability (with itself and with previous version of ECN >>>>>> and TCP). >>>>>> >>>>>> [ms] I think all what is written in this paragraph is obvious, no? >>>>>> Can't we just >>>>> delete this? >>>>> >>>>> Sure, however, I don’t think it hurts to spell it out. For me both is >>>>> fine, keep it >>>>> or remove it. >>>>> >>>>>> The experimental protocol will be considered successful if it is >>>>>> deployed and if it satisfies the requirements of [RFC7560] in the >>>>>> consensus opinion of the IETF tcpm working group. In short, this >>>>>> requires that it improves the accuracy and timeliness of TCP's ECN >>>>>> feedback, as claimed in Section 5, while striking a balance between >>>>>> the conflicting requirements of resilience, integrity and >>>>>> minimisation of overhead. It also requires that it is not unduly >>>>>> complex, and that it is compatible with prevalent equipment >>>>>> behaviours in the current Internet (e.g. hardware offloading and >>>>>> middleboxes), whether or not they comply with standards. >>>>>> >>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>> middlebox interference. Current recommended strategies are >>>>>> specified >>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>>> these strategies depends on the actual deployment situation of >>>>>> middleboxes. Therefore experimental verification to confirm large- >>>>>> scale path traversal in the Internet is needed before finalizing >>>>>> this >>>>>> specification on the Standards Track. >>>>>> >>>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>>> mentioned before, I don't think an RFC should speculate about TCPM and >>>>> its >>>>> consensus opinion. I would suggest a wording along the lines of: >>>>>> >>>>>> The experimental protocol will be considered successful if >>>>>> testing confirms that the proposed mechanism can be deployed at >>>>>> large >>>>> scale. >>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>> middlebox interference. Current recommended strategies are >>>>>> specified >>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>>> these strategies depends on the actual deployment situation of >>>>>> middleboxes. Therefore experimental verification to confirm large- >>>>>> scale path traversal in the Internet is needed, e.g., by support in >>>>>> major TCP stacks. >>>>>> >>>>>> >>>>> I don’t understand your point here. I don’t think that the paraphrase >>>>> speculates about the consensus of tcpm, in contrast it say tcpm has to >>>>> decided if the requirements previously specified by tcpm are >>>>> sufficiently >>>>> fulfilled. I don’t see a reason to not mention the requirement draft as >>>>> this >>>>> draft as tcpm consensus and was written for this purpose. >>>> My suggested wording uses the expression "can be deployed at large scale" >>>> and I believe this is relevant. >>>> >>>> The document already describes in Section 5 how the protocol satisfies >>>> the agreed requirements for a more accurate ECN feedback protocol [RFC7560]. >>>> So, if the TCPM working group publishes this document with the content of >>>> Section 5, I believe the TCPM working group already has reached consensus >>>> that the protocol meets requirements. In addition, it is possible that new >>>> requirements would be identified in future, e.g., as an outcome of the >>>> experiment, and that would obviously have to be considered by TCPM. In that >>>> case, for the success of the experiment not only RFC 7560 would matter, but >>>> also further requirements. My proposed wording does not have all these >>>> problems. >>>> >>>> In a nutshell, I continue to believe that this section has to change. >>> >>> Okay, used your proposed wording. You have a point about the requirement >>> and I mis-read you proposal earlier as „has to be deployed large-scale“. >>> >>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>> >>>>>> [ms] This section could probably be shortened as well. >>>>>> >>>>>> The last bit in byte 13 of the TCP header was defined as the Nonce >>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deployed >>>>>> so >>>>>> it is being reclassified as historic, making this TCP flag available >>>>>> for use by the AccECN experiment instead. >>>>>> >>>>>> [ms] This wording, as well as Figure 1, needs to take into account the >>>>>> IANA >>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>> >>>>> Is does. However, I can explicitly say that is has be re-clssified as >>>>> reserved. >>>>> >>>>> "RFC 3540 was never deployed so it is being reclassified as historic >>>>> [I-D.ietf- >>>>> tsvwg-ecn-experimentation] and the respective flag has been marked as >>>>> „reserved“ in the IANA TCP Header Flags registry, making this TCP flag >>>>> available for use by the AccECN experiment instead.“ >>>>> >>>>> Better? >>>>> >>>>>> In my understanding, this experimental document asks for new assignment >>>>> of a reserved TCP header flag. >>>>> >>>>> As I said I’m not sure if we have fully concluded this discussion yet. >>>>> However, >>>>> what we really would want to is mention somewhere that this experiment >>>>> with this flags is running. I guess there are three options: >>>>> 1) keep it in the registry as reserved and conserve the knowledge in >>>>> tcpm >>>>> that this experiment is running and no other experimental RFC such use >>>>> this >>>>> flags as long as this experiment is running. >>>>> 2) Keep is marked as reserved but add a note about this experiment in >>>>> the >>>>> IANA registry >>>>> 3) Or assign it right away with IESG approval. I guess in this case tcpm >>>>> could >>>>> also consider to change the registration policy to „IETF Review“. >>>> The current registration policy for the TCP header flags is "standards >>>> action". I understand that the IESG could approve exceptions. But given the >>>> policy, I believe the document has to be very precise on the request >>>> regarding bit 7. >>> Okay, it now says: >>> >>> "[TO BE REMOVED: IANA is requested to update the existing entry in the >>> Transmission Control Protocol (TCP) Header Flags registration >>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1) >>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS (Nonce >>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be instead >>> of RFC8311.]“ >>> >>> I guess we could also ask IANA to add an additional comment column instead >>> (but not sure if we then have to update RFC3168, which I think we really >>> don’t want. Should be fine now. >>> >>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>> >>>>>> o an essential part that re-uses ECN TCP header bits to feed back >>>>>> the number of arriving CE marked packets. This provides more >>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>> against >>>>>> ACK loss; >>>>>> >>>>>> [ms] The word "re-use" is IMHO not correct. >>>>> I think this is nit picking. Using a different phrasing here makes the >>>>> sentence >>>>> unnecessary complicated. We don’t try to some how get a round the fact >>>>> that we need to handle the flag registration correctly. However, here >>>>> the >>>>> point really is to explain how the protocol word. The main point of >>>>> using the >>>>> work „re-use“ here is really that we say that these flags are or have >>>>> been >>>>> used different by other TCP extension (and we therefore need a proper >>>>> negotiation scheme). >>>> If the allocation of a reserved flag is correctly explained in the >>>> abstract and introduction, I think these sentences can use a bit relaxed >>>> terminology. >>>> >>>>>> The two part design was necessary, given limitations on the space >>>>>> available for TCP options and given the possibility that certain >>>>>> incorrectly designed middleboxes prevent TCP using any new options -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jul 12 03:23:28 2018 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 591F71310AF; Thu, 12 Jul 2018 03:23:26 -0700 (PDT) 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, 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 yc9pgoQBiaw0; Thu, 12 Jul 2018 03:23:21 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D4A130FF1; Thu, 12 Jul 2018 03:23:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41RBpv3Z8dz15NQ0; Thu, 12 Jul 2018 12:23:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcrHY4QQyd-c; Thu, 12 Jul 2018 12:23:17 +0200 (CEST) X-MtScore: NO score=0 Received: from dhcp-903d.meeting.ietf.org (dhcp-903d.meeting.ietf.org [31.133.144.61]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 12 Jul 2018 12:23:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 12 Jul 2018 06:23:14 -0400 Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 12 Jul 2018 10:23:27 -0000 Hi Yuchung, the question if you need this =E2=80=9Emore=E2=80=9C on accuracy really = depends on the use case. If you use DCTCP as today, the ACE counter in = the TCP is probably sufficient and you might not want to pay the = additional overhead in your data center (that why the option is actually = optional). If you however, e.g., have very differently sized packets, then the byte = counter in the option could give you a more accurate signal. Or if you = are also interested in the ECT(1) counter, you need the option. Further = the ACE counter also give your feedback on control packet and the option = enables you to distinguish between CE-amrked payload and control = packets, which can also become important when experimenting with making = all packets ECN-capable.=20 Given accECN is a general feedback mechanism that in fact is designed to = enable new future uses of the ECN signal, we wanted to keep all these = option available while making is still as simple as possible and as = flexible as possible. Mirja > Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >=20 > Hi Bob, >=20 > Neal and I evaluated the earlier draft. It is well-thought out but > we're concerned about the options. Option is not mandatory but the > lack of it also reduces accuracy. Option runs into space issues w/ > SACK and offload issues w/ TSO/GRO. They can be addressed for sure but > aren't easy. >=20 > We're curious how much more "accuracy" it buys over current > DCTCP-style ECN. Is there any study to show trade-offs of > full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >=20 >=20 > On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe = wrote: >> Michael, tcpm list, >>=20 >> As well as addressing your points, as Mirja has already mentioned = below, we >> added a whole new appendix giving the rationale for the bits and = codepoints >> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >> subsection also identifies space for future evolution. It also points = to >> where rationale was already given in the body of the draft. >>=20 >> The appendix is in the draft submitted last week, available here: >> = https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>=20 >> We'd be interested to hear whether this allays your concerns. >>=20 >> We have asked to present this in Montreal as well. >>=20 >> Cheers >>=20 >>=20 >> Bob >>=20 >>=20 >> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>=20 >>> Hi Micheal, >>>=20 >>> I addressed a couple of your comments below. >>>=20 >>> For the other, bigger comments regarding extensibility, that I did = not yet >>> address below, we plan to add a new section to the appendix to = explain >>> extensibility options as previously discussed by mail. We will = probably send >>> a separate email on that part. >>>=20 >>> Mirja >>>=20 >>>=20 >>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - = DE/Stuttgart) >>>> : >>>>=20 >>>> Hi Mirja, >>>>=20 >>>> Thanks a lot for the explanation. I won't follow-up on some of the >>>> editorial suggestions. >>>>=20 >>>> Yet, I continue to believe that some formal wording in the document = needs >>>> to change, as explained below. >>>>=20 >>>> Thanks >>>>=20 >>>> Michael (with no hat on) >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Mirja K=C3=BChlewind = [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) = >>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>=20 >>>>> Hi Micheal, >>>>>=20 >>>>> thanks for your feedback and sorry for my late reply. >>>>>=20 >>>>> Please see inline. >>>>>=20 >>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - = DE/Stuttgart) >>>>>=20 >>>>> : >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the = appendix). I >>>>>=20 >>>>> believe this document needs further work before moving forward. >>>>>>=20 >>>>>> Please find below my comments marked as [ms]. I have read the >>>>>=20 >>>>> document independent of the review from Gorry. I apologize if = there is >>>>> duplication. >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> Michael (with no hat on) >>>>>>=20 >>>>>>=20 >>>>>> ****************************** >>>>>>=20 >>>>>> * Abstract: >>>>>>=20 >>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) = or >>>>>> Data >>>>>=20 >>>>> Center TCP >>>>>>=20 >>>>>> (DCTCP) need more accurate ECN feedback information whenever = more >>>>>> than one marking is received in one RTT. >>>>>>=20 >>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>>> suggest to >>>>>=20 >>>>> remove this, or replace it by a more generic statement that more >>>>> accurate >>>>> information can be useful for several TCP extensions. >>>>>=20 >>>>> I disagree. Both ConEx and DCTCP need more accurate information. = They do >>>>> not need the mechanism that is specified in this draft, however, = this is >>>>> not >>>>> what the sentences is saying. >>>>=20 >>>> In my understanding (as a non-native speaker), the use of the word = "need" >>>> is not correct here. DCTCP as specified in RFC 8257 can be = implemented >>>> without any such mechanism. >>>>=20 >>>> What would work for me is something of the form "... Data Center = TCP >>>> cannot get precise ECN feedback whenever more than one marking is = received >>>> in one RTT=E2=80=9C. >>>=20 >>> This is not correct. DCTP need more than one feedback signal per RTT = and >>> therefore cannot use RFC3168; instead it implement it=E2=80=99s own = feedback >>> mechanism. However, to avoid confusion such that people could assume = DCTP >>> would not work without the accECN scheme as specified in this doc, I >>> rephrased to: >>>=20 >>> "Recently, proposed >>> mechanisms like Congestion Exposure (ConEx >> target=3D"RFC7713"/>), >>> DCTCP or L4S >> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more = than one >>> marking is received in one RTT which is >>> information that cannot be provided by the feedback scheme as >>> specified in >>> ." >>>=20 >>>=20 >>>>>> This document specifies an >>>>>> experimental scheme to provide more than one feedback signal = per RTT >>>>>> in the TCP header. Given TCP header space is scarce, it = overloads >>>>>> the three existing ECN-related flags in the TCP header and = provides >>>>>> additional information in a new TCP option. >>>>>>=20 >>>>>> [ms] This statement needs to be rewritten to correctly reflect = what is >>>>>=20 >>>>> requested from IANA. My understanding is that this experimental = document >>>>> asks for allocation of a reserved TCP header flag. This needs to = be >>>>> called out >>>>> prominently, IMHO. In addition, since this is not a standard, the >>>>> suggested >>>>> experimentation with the main TCP header must IMHO be explicitly >>>>> mentioned. I also suggest to have later in a document a section = that >>>>> explicitly >>>>> explains why it is appropriate to modify the main TCP header in an >>>>> experiment. >>>>>=20 >>>>> I don=E2=80=99t know if any requirement that IANA assignment need = to be called >>>>> out >>>>> in the abstract but we can do that. However, I believe the = question if >>>>> this >>>>> document should or should not assign the bit is still not = completely >>>>> solved, or >>>>> is it? >>>>=20 >>>> I believe this question will have to be reviewed during WGLC and, = more >>>> importantly, IETF last call. For the moment, my concern is that the = document >>>> correctly describes the IANA allocation. >>>>=20 >>>> I would like to see here a statement such as : "Given TCP header = space is >>>> scarce, this specification allocates a reserved header bit and = overloads the >>>> two ECN flags in the TCP header ...=E2=80=9C. >>>=20 >>> A bit lengthy but now: >>>=20 >>> "Given TCP header space is >>> scarce, it allocates a reserved header bit, that was = previously >>> used for >>> ECN-Nonce which was recently declared historic, and overloads = the >>> two existing ECN flags in the TCP header. Further, additional >>> information can be provided in a new TCP option that however = is not >>> used >>> on the TCP SYN." >>>=20 >>>>>> * 1. Introduction >>>>>>=20 >>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] = need >>>>>> more accurate ECN feedback information whenever more than one >>>>>=20 >>>>> marking >>>>>>=20 >>>>>> is received in one RTT. >>>>>>=20 >>>>>> [ms] At least for RFC 8257 seems to be implementable withoit = this. >>>>>> Instead >>>>>=20 >>>>> of stating a "need", it would IMHO make more sense to discuss the >>>>> benefits >>>>> of the suggested mechanism in this document of its own, = independent of >>>>> other proposals. To me, this document should be independent of = other >>>>> documents and specifically other experiments. We have to think = about >>>>> cases >>>>> where not all experiments are successful. Then independent = documents >>>>> will >>>>> be more future-proof in future. >>>>>=20 >>>>> This is a naming collision=E2=80=A6 The sentence was meant to say = that these >>>>> mechanisms new more accurate ECN feedback than provided today by >>>>> RFC3168 but it was not meant to say that these mechanism have to = use the >>>>> scheme as specified in this document. >>>>>=20 >>>>> I added the following part sentence: >>>>>=20 >>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure = (ConEx >>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need = more >>>>> accurate ECN feedback information than provided by the feedback = scheme >>>>> as specified in [RFC3168] whenever more than one marking is = received in >>>>> one >>>>> RTT. This document specifies an alternative feedback scheme that >>>>> provides >>>>> more accurate information and could be used by these new TCP >>>>> extensions.=E2=80=9C >>>>>=20 >>>>> Does this help? >>>>=20 >>>> See my proposal for the abstract. I continue to disagree with the = term >>>> "need" but I think this can be sorted out by another term. >>>>=20 >>>>>> If AccECN progresses from experimental to the standards >>>>>> track, it is intended to be a complete replacement for classic = TCP/ >>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>=20 >>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>=20 >>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent = that we have. >>>>>=20 >>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as = the >>>>>> standards track specification for adding ECN to TCP. >>>>>>=20 >>>>>> [ms] This sentence should be removed (or reworded) >>>>>=20 >>>>> Why? Does it help to add an only here: >>>>>=20 >>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as = the only >>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>=20 >>>> This wording is better. >>>>=20 >>>>>> AccECN feedback overloads flags and fields in the main TCP = header >>>>>> with new definitions, so both ends have to support the new wire >>>>>> protocol before it can be used. >>>>>>=20 >>>>>> [ms] In my reading this experimental document asks for *new* = allocation >>>>>=20 >>>>> of a reserved TCP header flag. >>>>>=20 >>>>> Is this better? >>>>>=20 >>>>> "AccECN feedback overloads the two existing ECN flags as well as = the >>>>> currently reserved and previously called NS flag in the main = TCP >>>>> header >>>>> with new definitions, so both ends have to support the new = wire >>>>> protocol >>>>> before it can be used.=E2=80=9C >>>>>=20 >>>>> I understand that you are not happy with the word =E2=80=9Eoverload=E2= =80=9C here but >>>>> the >>>>> point of this sentence really is that the flags can/could be used >>>>> differently >>>>> and therefore we need a new negotiation before we can use them. >>>>=20 >>>> For me the following would work: "AccECN feedback overloads the two >>>> existing ECN flags and >>>> allocates the currently reserved and previously called NS flag in = the >>>> main TCP header. >>>> Given the new definitions, both ends have to support the new wire >>>> protocol >>>> before it can be used." >>>>=20 >>>> I believe the wording has to be crystal clear on the reservation of = bit 7 >>>> when it is discussed the first time in the text. In follow-up = sections, >>>> maybe shorter terms could be used. >>>=20 >>> Okay, now: >>>=20 >>> "AccECN feedback overloads the two existing ECN flags and >>> allocates the currently reserved and previously called NS flag = in the >>> TCP header, to be used as one field indicating the number of >>> congestion >>> experienced marked packets. Given the new definitions of these = three >>> bits, >>> both ends have to support the new wire protocol before it = can be >>> used. >>> Therefore during the TCP handshake the two ends use these three = bit >>> in >>> the TCP header to negotiate the most advanced feedback protocol >>> that they can both support in a backward compatible way to >>> ." >>>>>=20 >>>>> If you prefer, we can also remove the NS flag in this list, as ECN = Nonce >>>>> was >>>>> anyway never deployed. >>>>>=20 >>>>>> For that we refer to [RFC3168] or any RFC that >>>>>> specifies a different response to TCP ECN feedback, for = example: >>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>> Latency >>>>>> Low Loss Scalable (L4S) congestion control >>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>> ECN-capable TCP control packets = [I-D.ietf-tcpm-generalized-ecn], or >>>>>> Alternative Backoff with ECN (ABE) >>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>=20 >>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this = paragraph can >>>>>> just >>>>>=20 >>>>> be deleted. If other experiments need more accurate feedback, it = is up >>>>> to >>>>> them to explain how they would use this mechanism. This document = should >>>>> focus on how to signal the feedback, not how to use that. >>>>>=20 >>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better to = be explicit >>>>> about this? >>>>>=20 >>>>>> It is likely (but not required) that the AccECN protocol will = be >>>>>> implemented along with the following experimental additions to = the >>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>> retransmissions >>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable = SYN/ >>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>=20 >>>>>> [ms] I am a big fan of simple, standalone documents. In my view, = the >>>>>> TCPM >>>>>=20 >>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>> draft-ietf- >>>>> tcpm-generalized-ecn independent documents, which probably implies = that >>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If = experimentation >>>>> with ECT in SYN requires a combination, this could be done in a = new, >>>>> third >>>>> document. Apart from having simpler focused documents, this could >>>>> significantly help later with moving forward documents to = standards >>>>> track. >>>>>=20 >>>>> I disagree, however, this is a discussion to have on = draft-ietf-tcpm- >>>>> generalized-ecn. I don=E2=80=99t see a problem in providing a = reference here >>>>> that >>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * 1.1. Document Roadmap >>>>>>=20 >>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>> introduction >>>>>=20 >>>>> and tutorial text with lot's of redundancy towards other = documents. I >>>>> think >>>>> the document can be made much easier to read by shorten it. In = many >>>>> cases >>>>> this is just an editorial change as there is redundancy. As one = such >>>>> example, >>>>> just remove this section. >>>>>=20 >>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan of = short and >>>>> concise >>>>> documents, however, some redundancy can also help understanding, >>>>> especially if you explain things multiple times but with a = different >>>>> level of >>>>> detail. I personally would not need the roadmap but I know many = people >>>>> who find these things helpful and to be honest I don=E2=80=99t see = how removing >>>>> this >>>>> part makes the doc any better. If you don=E2=80=99t want it, = don=E2=80=99t read it. >>>>>=20 >>>>>>=20 >>>>>> * 1.2. Goals >>>>>>=20 >>>>>> [ms] I think this section can also just be removed. >>>>>=20 >>>>> I have to say I also don=E2=80=99t see the point of removing this = part. Given >>>>> we=E2=80=99ve >>>>> done the work on requirements, I think we should also link to this = doc >>>>> somewhere. >>>>>>=20 >>>>>>=20 >>>>>> * 1.3. Experiment Goals >>>>>>=20 >>>>>> TCP is critical to the robust functioning of the Internet, = therefore >>>>>> any proposed modifications to TCP need to be thoroughly tested. = The >>>>>> present specification describes an experimental protocol that = adds >>>>>> more accurate ECN feedback to the TCP protocol. The intention = is to >>>>>> specify the protocol sufficiently so that more than one >>>>>> implementation can be built in order to test its function, >>>>>> robustness >>>>>> and interoperability (with itself and with previous version of = ECN >>>>>> and TCP). >>>>>>=20 >>>>>> [ms] I think all what is written in this paragraph is obvious, = no? >>>>>> Can't we just >>>>>=20 >>>>> delete this? >>>>>=20 >>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. For = me both is >>>>> fine, keep it >>>>> or remove it. >>>>>=20 >>>>>> The experimental protocol will be considered successful if it = is >>>>>> deployed and if it satisfies the requirements of [RFC7560] in = the >>>>>> consensus opinion of the IETF tcpm working group. In short, = this >>>>>> requires that it improves the accuracy and timeliness of TCP's = ECN >>>>>> feedback, as claimed in Section 5, while striking a balance = between >>>>>> the conflicting requirements of resilience, integrity and >>>>>> minimisation of overhead. It also requires that it is not = unduly >>>>>> complex, and that it is compatible with prevalent equipment >>>>>> behaviours in the current Internet (e.g. hardware offloading = and >>>>>> middleboxes), whether or not they comply with standards. >>>>>>=20 >>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>> middlebox interference. Current recommended strategies are >>>>>> specified >>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>> these strategies depends on the actual deployment situation of >>>>>> middleboxes. Therefore experimental verification to confirm = large- >>>>>> scale path traversal in the Internet is needed before = finalizing >>>>>> this >>>>>> specification on the Standards Track. >>>>>>=20 >>>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>>>=20 >>>>> mentioned before, I don't think an RFC should speculate about TCPM = and >>>>> its >>>>> consensus opinion. I would suggest a wording along the lines of: >>>>>>=20 >>>>>> >>>>>> The experimental protocol will be considered successful if >>>>>> testing confirms that the proposed mechanism can be deployed at >>>>>> large >>>>>=20 >>>>> scale. >>>>>>=20 >>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>> middlebox interference. Current recommended strategies are >>>>>> specified >>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>> these strategies depends on the actual deployment situation of >>>>>> middleboxes. Therefore experimental verification to confirm = large- >>>>>> scale path traversal in the Internet is needed, e.g., by = support in >>>>>> major TCP stacks. >>>>>> >>>>>>=20 >>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t think = that the paraphrase >>>>> speculates about the consensus of tcpm, in contrast it say tcpm = has to >>>>> decided if the requirements previously specified by tcpm are >>>>> sufficiently >>>>> fulfilled. I don=E2=80=99t see a reason to not mention the = requirement draft as >>>>> this >>>>> draft as tcpm consensus and was written for this purpose. >>>>=20 >>>> My suggested wording uses the expression "can be deployed at large = scale" >>>> and I believe this is relevant. >>>>=20 >>>> The document already describes in Section 5 how the protocol = satisfies >>>> the agreed requirements for a more accurate ECN feedback protocol = [RFC7560]. >>>> So, if the TCPM working group publishes this document with the = content of >>>> Section 5, I believe the TCPM working group already has reached = consensus >>>> that the protocol meets requirements. In addition, it is possible = that new >>>> requirements would be identified in future, e.g., as an outcome of = the >>>> experiment, and that would obviously have to be considered by TCPM. = In that >>>> case, for the success of the experiment not only RFC 7560 would = matter, but >>>> also further requirements. My proposed wording does not have all = these >>>> problems. >>>>=20 >>>> In a nutshell, I continue to believe that this section has to = change. >>>=20 >>>=20 >>> Okay, used your proposed wording. You have a point about the = requirement >>> and I mis-read you proposal earlier as =E2=80=9Ehas to be deployed = large-scale=E2=80=9C. >>>=20 >>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>=20 >>>>>> [ms] This section could probably be shortened as well. >>>>>>=20 >>>>>> The last bit in byte 13 of the TCP header was defined as the = Nonce >>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never = deployed >>>>>> so >>>>>> it is being reclassified as historic, making this TCP flag = available >>>>>> for use by the AccECN experiment instead. >>>>>>=20 >>>>>> [ms] This wording, as well as Figure 1, needs to take into = account the >>>>>> IANA >>>>>=20 >>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>=20 >>>>> Is does. However, I can explicitly say that is has be re-clssified = as >>>>> reserved. >>>>>=20 >>>>> "RFC 3540 was never deployed so it is being reclassified as = historic >>>>> [I-D.ietf- >>>>> tsvwg-ecn-experimentation] and the respective flag has been marked = as >>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags registry, = making this TCP flag >>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>=20 >>>>> Better? >>>>>=20 >>>>>> In my understanding, this experimental document asks for new = assignment >>>>>=20 >>>>> of a reserved TCP header flag. >>>>>=20 >>>>> As I said I=E2=80=99m not sure if we have fully concluded this = discussion yet. >>>>> However, >>>>> what we really would want to is mention somewhere that this = experiment >>>>> with this flags is running. I guess there are three options: >>>>> 1) keep it in the registry as reserved and conserve the knowledge = in >>>>> tcpm >>>>> that this experiment is running and no other experimental RFC such = use >>>>> this >>>>> flags as long as this experiment is running. >>>>> 2) Keep is marked as reserved but add a note about this experiment = in >>>>> the >>>>> IANA registry >>>>> 3) Or assign it right away with IESG approval. I guess in this = case tcpm >>>>> could >>>>> also consider to change the registration policy to =E2=80=9EIETF = Review=E2=80=9C. >>>>=20 >>>> The current registration policy for the TCP header flags is = "standards >>>> action". I understand that the IESG could approve exceptions. But = given the >>>> policy, I believe the document has to be very precise on the = request >>>> regarding bit 7. >>>=20 >>> Okay, it now says: >>>=20 >>> "[TO BE REMOVED: IANA is requested to update the existing entry in = the >>> Transmission Control Protocol (TCP) Header Flags registration >>> = (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#= tcp-header-flags-1) >>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS = (Nonce >>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be = instead >>> of RFC8311.]=E2=80=9C >>>=20 >>> I guess we could also ask IANA to add an additional comment column = instead >>> (but not sure if we then have to update RFC3168, which I think we = really >>> don=E2=80=99t want. Should be fine now. >>>=20 >>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>=20 >>>>>> o an essential part that re-uses ECN TCP header bits to feed = back >>>>>> the number of arriving CE marked packets. This provides = more >>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>> against >>>>>> ACK loss; >>>>>>=20 >>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>=20 >>>>> I think this is nit picking. Using a different phrasing here makes = the >>>>> sentence >>>>> unnecessary complicated. We don=E2=80=99t try to some how get a = round the fact >>>>> that we need to handle the flag registration correctly. However, = here >>>>> the >>>>> point really is to explain how the protocol word. The main point = of >>>>> using the >>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that = these flags are or have >>>>> been >>>>> used different by other TCP extension (and we therefore need a = proper >>>>> negotiation scheme). >>>>=20 >>>> If the allocation of a reserved flag is correctly explained in the >>>> abstract and introduction, I think these sentences can use a bit = relaxed >>>> terminology. >>>>=20 >>>>>> The two part design was necessary, given limitations on the = space >>>>>> available for TCP options and given the possibility that = certain >>>>>> incorrectly designed middleboxes prevent TCP using any new = options From nobody Thu Jul 12 05:23:16 2018 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 6EF5D130DF1 for ; Thu, 12 Jul 2018 05:23:14 -0700 (PDT) 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_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWlLV_BFNTh1 for ; Thu, 12 Jul 2018 05:23:12 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAA3130DDE for ; Thu, 12 Jul 2018 05:23:12 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 41RFTB5kmzz8tRJ for ; Thu, 12 Jul 2018 14:23:10 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 41RFTB57TPzCqkY for ; Thu, 12 Jul 2018 14:23:10 +0200 (CEST) Received: from opfedar03.bagnolet.francetelecom.fr by opfedar03.bagnolet.francetelecom.fr with queue id 626964-29 for tcpm@ietf.org; Thu, 12 Jul 2018 12:23:10 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 41RFTB4YZHzCqkS; Thu, 12 Jul 2018 14:23:10 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0399.000; Thu, 12 Jul 2018 14:23:10 +0200 From: To: "philip.eardley@bt.com" , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt Thread-Index: AQHTtK4iDI+Mo6jxv0utHg3D/M2BoKQpg4TwgGLB2BA= Date: Thu, 12 Jul 2018 12:23:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF598FD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152027380186.14624.8843516061240272538@ietfa.amsl.com> <718b17025c25456490724ad442040422@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <718b17025c25456490724ad442040422@rew09926dag03b.domain1.systemhost.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 12 Jul 2018 12:23:15 -0000 Hi Phil,=20 Apologies of the delay to answer.=20 Thank you for sharing these comments.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de philip.eardley@b= t.com > Envoy=E9=A0: jeudi 10 mai 2018 17:51 > =C0=A0: tcpm@ietf.org > Objet=A0: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt >=20 > Hi, >=20 > I remember in the London discussion there were some comments about things= it > would be good to add to the draft - mainly about more examples. I agree w= ith > this, it would be useful I think to cover: >=20 > - The example is for one client. I assume multiple clients each require > their own Ipv6 address on the converter (ie which is the source address f= or > that client's converter-server(s) connections)? [Med] This is deployment-specific. The converter may behave in address shar= ing or address preservation modes. A text change is proposed here: https://= github.com/obonaventure/draft-tcp-converters/pull/41/commits/de004090c1861f= 0f8b076285b4119d48f7ab47e8=20 "The Converter may behave in address preservation or address sharing modes = as discussed in Section 5.4 of {{draft-nam-mptcp-deployment-considerations}= }. Which behavior to use by a Converter is deployment-specific. If address = sharing mode is enabled, the Converter MUST adhere to REQ-2 of RFC6888 whic= h implies a default "IP address pooling" behavior of "Paired" (as defined i= n Section 4.1 of [RFC4787]) must be supported. This behavior is meant to av= oid breaking applications that depend on the external address remaining con= stant. Also, maintaining the same external IP address for a client is meant= to preserve the validity of the TFO cookie." > - How would the client access Ipv4 content? [Med] We would like to avoid overloading the document with deployment-speci= fic examples. Plenty of those are described in draft-nam-mptcp-deployment-c= onsiderations. We may add a pointer if needed.=20 > - I assume the client has to be configured somehow with the converter's > address [Med] Yes, we do have the following text in the draft: This document assumes that a client is configured with one or a list of Converters (e.g., [I-D.boucadair-tcpm-dhc-converter]). Configuration means are outside the scope of this document. > - What happens if the converter fails? I suppose the client has to > somehow notice, and (at config time) it gets told the address for a back-= up > converter or a DNS name. [Med] I-D.boucadair-tcpm-dhc-converter specifies a procedure to provision = one or multiple converters; each identified by a list of IP addresses. The = procedure to follow for selecting the address to use will need to be specif= ied. Should we include it in draft-ietf-tcpm-converters or in I-D.boucadair= -tcpm-dhc-converter? I do prefer to leave that procedure out of draft-ietf-= tcpm-converters because the selection may not only be based on the availabi= lity of an address, but based on other criteria. =20 > - What happens if a link fails? I assume if one of the client-converter > links fails, then MPTCP shifts all the traffic to the other path. [Med] This is normal MPTCP behavior. Do we really need to say something the= re?=20 If the > converter-server connection fails, how does the client discover this? [Med] This is done by means of the "Network Failure (65)" error code:=20 o Network Failure (65): This error indicates that the Converter is experiencing a network failure to relay the request. The Converter MUST send this error code when it experiences forwarding issues to relay a connection. I > assume packets build up at the converter and are dropped, and at some poi= nt > the converter informs the client. >=20 > Thanks, > Best wishes, > phil >=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 05 March 2018 18:17 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt >=20 >=20 > 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. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Bart Peirens > SungHoon Seo > Anandatirtha Nandugudi > Filename : draft-ietf-tcpm-converters-01.txt > Pages : 37 > Date : 2018-03-05 >=20 > 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. >=20 > -- Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: > [This-RFC] >=20 > Please update TBA statements with the port number to be assigned to > the Converter Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-01 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 12 08:42:20 2018 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 8EFE4130E9F for ; Thu, 12 Jul 2018 08:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 cxb-089v7hJf for ; Thu, 12 Jul 2018 08:42:10 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 347EA130EA7 for ; Thu, 12 Jul 2018 08:42:09 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id s7-v6so7427804itb.4 for ; Thu, 12 Jul 2018 08:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QXzDDeeiBMiNugKuT8r1VmVdk+qj170MpyZxC7TTguc=; b=aPETqgKmjDsHtyAoGCID/fM8RDRPSfH8i8moWAs2E6ZIFsY90LBvwT9QR4zb9JmfYx MVge5Aor+tW7gcEBWHh8Faeqkp6grfl+drP4GdFv16vOWTtJxzTkFB302vBCLE/qthdk XVX+iuUnvELROEB2QkKTte/fOiVj5NIcKSIEeS4b0ou9Plv+aX6n0ZglenAZRJwufiQu J8vUhGqiPfKyT3vmTNE+o59XjOziom6UT6D1A1LnrRFHE2NBA+Krg8YhV4hQJh+HJFEs yRiBLdYtetSLwY5jpxJ7Hi4FpWkR6FCSAT3rsxRL39o5FoDJzSTx8R9RWSfFobcVv/5w SxQw== 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:content-transfer-encoding; bh=QXzDDeeiBMiNugKuT8r1VmVdk+qj170MpyZxC7TTguc=; b=njCOrusCqxuGkG06XppaQUA6s1qBKianWEFBTwvnjKdmR4d3Q+AvDRoBX+Nvj5TL99 8OpyydtkZbH4SF/WAbgBzHci+lasmC4lpXp1V4cCFgzdLGGrespJEP0HgXHdYf11evLH hSJpQYvV0cQCncaQhTVLjZGi0T3X+eCyV5sCNaRugbJuXL6zSkFOKxQRM9Qf8MtH3Odd 1gwwWg8sM+kaASq9PVSjYnRT4yg8YFMJ8BjseF0GBkXA8FE3C27thrCy24gJomVjhOrv AqCo8rW05bQ/xVOVXuw9wEZ/nrwI1O0sdsLfudNuN0Pe6iPkzkagaOKXoDGNEgkLWdhG BznA== X-Gm-Message-State: AOUpUlElWdHAt8cb96IUozRmLQVMUOVSwnQGyb9wMV+wXc6ILZOIh/F7 ePimsJExn65rk3qNOGIc3PeiPsGGNsByroaUQKwzAA== X-Google-Smtp-Source: AAOMgpch22y7Dg53ajTzdcxLZfUCNFLc8IjzalWBQApZpUKlShDxIwfnWbILFwJAoYZOHHl4ahtb2bRcWupE9Enknak= X-Received: by 2002:a02:1294:: with SMTP id 20-v6mr2045371jap.141.1531410127896; Thu, 12 Jul 2018 08:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:ee18:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 08:41:27 -0700 (PDT) In-Reply-To: <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> From: Yuchung Cheng Date: Thu, 12 Jul 2018 08:41:27 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 12 Jul 2018 15:42:16 -0000 Yes packets with ACE options and (different) ACE-counter header would break GRO. There're many legacy h/w and s/w. Even without option, ACE header only allows reflecting up to 8 packets for receiver segmentation offload and ACK suppression? The appendix on ack loss causes ambiguity is good: but the pattern drops specifically the state-switch (CE<->noCE) ACK which only happens on delayed ACK. Is that pattern common? - or can we address most of that by delaying less ACKs? I am all for making ECN more accurate for wide area beyond DCTCP, but am evaluating the pros/cons. What if we just 1. negotiate 'better' ECN via new SYN option 2. mark all packets like ECN++ On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind wrote: > Hi Yuchung, > > the question if you need this =E2=80=9Emore=E2=80=9C on accuracy really d= epends on the use case. If you use DCTCP as today, the ACE counter in the T= CP is probably sufficient and you might not want to pay the additional over= head in your data center (that why the option is actually optional). > > If you however, e.g., have very differently sized packets, then the byte = counter in the option could give you a more accurate signal. Or if you are = also interested in the ECT(1) counter, you need the option. Further the ACE= counter also give your feedback on control packet and the option enables y= ou to distinguish between CE-amrked payload and control packets, which can = also become important when experimenting with making all packets ECN-capabl= e. > > Given accECN is a general feedback mechanism that in fact is designed to = enable new future uses of the ECN signal, we wanted to keep all these optio= n available while making is still as simple as possible and as flexible as = possible. > > Mirja > > > >> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >> >> Hi Bob, >> >> Neal and I evaluated the earlier draft. It is well-thought out but >> we're concerned about the options. Option is not mandatory but the >> lack of it also reduces accuracy. Option runs into space issues w/ >> SACK and offload issues w/ TSO/GRO. They can be addressed for sure but >> aren't easy. >> >> We're curious how much more "accuracy" it buys over current >> DCTCP-style ECN. Is there any study to show trade-offs of >> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >> >> >> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe wrot= e: >>> Michael, tcpm list, >>> >>> As well as addressing your points, as Mirja has already mentioned below= , we >>> added a whole new appendix giving the rationale for the bits and codepo= ints >>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >>> subsection also identifies space for future evolution. It also points t= o >>> where rationale was already given in the body of the draft. >>> >>> The appendix is in the draft submitted last week, available here: >>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>> >>> We'd be interested to hear whether this allays your concerns. >>> >>> We have asked to present this in Montreal as well. >>> >>> Cheers >>> >>> >>> Bob >>> >>> >>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>> >>>> Hi Micheal, >>>> >>>> I addressed a couple of your comments below. >>>> >>>> For the other, bigger comments regarding extensibility, that I did not= yet >>>> address below, we plan to add a new section to the appendix to explain >>>> extensibility options as previously discussed by mail. We will probabl= y send >>>> a separate email on that part. >>>> >>>> Mirja >>>> >>>> >>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>>>> : >>>>> >>>>> Hi Mirja, >>>>> >>>>> Thanks a lot for the explanation. I won't follow-up on some of the >>>>> editorial suggestions. >>>>> >>>>> Yet, I continue to believe that some formal wording in the document n= eeds >>>>> to change, as explained below. >>>>> >>>>> Thanks >>>>> >>>>> Michael (with no hat on) >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>> >>>>>> Hi Micheal, >>>>>> >>>>>> thanks for your feedback and sorry for my late reply. >>>>>> >>>>>> Please see inline. >>>>>> >>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - DE/Stuttgar= t) >>>>>> >>>>>> : >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix).= I >>>>>> >>>>>> believe this document needs further work before moving forward. >>>>>>> >>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>> >>>>>> document independent of the review from Gorry. I apologize if there = is >>>>>> duplication. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Michael (with no hat on) >>>>>>> >>>>>>> >>>>>>> ****************************** >>>>>>> >>>>>>> * Abstract: >>>>>>> >>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or >>>>>>> Data >>>>>> >>>>>> Center TCP >>>>>>> >>>>>>> (DCTCP) need more accurate ECN feedback information whenever more >>>>>>> than one marking is received in one RTT. >>>>>>> >>>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>>>> suggest to >>>>>> >>>>>> remove this, or replace it by a more generic statement that more >>>>>> accurate >>>>>> information can be useful for several TCP extensions. >>>>>> >>>>>> I disagree. Both ConEx and DCTCP need more accurate information. The= y do >>>>>> not need the mechanism that is specified in this draft, however, thi= s is >>>>>> not >>>>>> what the sentences is saying. >>>>> >>>>> In my understanding (as a non-native speaker), the use of the word "n= eed" >>>>> is not correct here. DCTCP as specified in RFC 8257 can be implemente= d >>>>> without any such mechanism. >>>>> >>>>> What would work for me is something of the form "... Data Center TCP >>>>> cannot get precise ECN feedback whenever more than one marking is rec= eived >>>>> in one RTT=E2=80=9C. >>>> >>>> This is not correct. DCTP need more than one feedback signal per RTT a= nd >>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s own fe= edback >>>> mechanism. However, to avoid confusion such that people could assume D= CTP >>>> would not work without the accECN scheme as specified in this doc, I >>>> rephrased to: >>>> >>>> "Recently, proposed >>>> mechanisms like Congestion Exposure (ConEx >>> target=3D"RFC7713"/>), >>>> DCTCP or L4S >>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more than= one >>>> marking is received in one RTT which is >>>> information that cannot be provided by the feedback scheme as >>>> specified in >>>> ." >>>> >>>> >>>>>>> This document specifies an >>>>>>> experimental scheme to provide more than one feedback signal per = RTT >>>>>>> in the TCP header. Given TCP header space is scarce, it overload= s >>>>>>> the three existing ECN-related flags in the TCP header and provid= es >>>>>>> additional information in a new TCP option. >>>>>>> >>>>>>> [ms] This statement needs to be rewritten to correctly reflect what= is >>>>>> >>>>>> requested from IANA. My understanding is that this experimental docu= ment >>>>>> asks for allocation of a reserved TCP header flag. This needs to be >>>>>> called out >>>>>> prominently, IMHO. In addition, since this is not a standard, the >>>>>> suggested >>>>>> experimentation with the main TCP header must IMHO be explicitly >>>>>> mentioned. I also suggest to have later in a document a section that >>>>>> explicitly >>>>>> explains why it is appropriate to modify the main TCP header in an >>>>>> experiment. >>>>>> >>>>>> I don=E2=80=99t know if any requirement that IANA assignment need to= be called >>>>>> out >>>>>> in the abstract but we can do that. However, I believe the question = if >>>>>> this >>>>>> document should or should not assign the bit is still not completely >>>>>> solved, or >>>>>> is it? >>>>> >>>>> I believe this question will have to be reviewed during WGLC and, mor= e >>>>> importantly, IETF last call. For the moment, my concern is that the d= ocument >>>>> correctly describes the IANA allocation. >>>>> >>>>> I would like to see here a statement such as : "Given TCP header spac= e is >>>>> scarce, this specification allocates a reserved header bit and overlo= ads the >>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>> >>>> A bit lengthy but now: >>>> >>>> "Given TCP header space is >>>> scarce, it allocates a reserved header bit, that was previously >>>> used for >>>> ECN-Nonce which was recently declared historic, and overloads th= e >>>> two existing ECN flags in the TCP header. Further, additional >>>> information can be provided in a new TCP option that however is = not >>>> used >>>> on the TCP SYN." >>>> >>>>>>> * 1. Introduction >>>>>>> >>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>>>>> more accurate ECN feedback information whenever more than one >>>>>> >>>>>> marking >>>>>>> >>>>>>> is received in one RTT. >>>>>>> >>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit this. >>>>>>> Instead >>>>>> >>>>>> of stating a "need", it would IMHO make more sense to discuss the >>>>>> benefits >>>>>> of the suggested mechanism in this document of its own, independent = of >>>>>> other proposals. To me, this document should be independent of other >>>>>> documents and specifically other experiments. We have to think about >>>>>> cases >>>>>> where not all experiments are successful. Then independent documents >>>>>> will >>>>>> be more future-proof in future. >>>>>> >>>>>> This is a naming collision=E2=80=A6 The sentence was meant to say th= at these >>>>>> mechanisms new more accurate ECN feedback than provided today by >>>>>> RFC3168 but it was not meant to say that these mechanism have to use= the >>>>>> scheme as specified in this document. >>>>>> >>>>>> I added the following part sentence: >>>>>> >>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure (Con= Ex >>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need mo= re >>>>>> accurate ECN feedback information than provided by the feedback sche= me >>>>>> as specified in [RFC3168] whenever more than one marking is received= in >>>>>> one >>>>>> RTT. This document specifies an alternative feedback scheme that >>>>>> provides >>>>>> more accurate information and could be used by these new TCP >>>>>> extensions.=E2=80=9C >>>>>> >>>>>> Does this help? >>>>> >>>>> See my proposal for the abstract. I continue to disagree with the ter= m >>>>> "need" but I think this can be sorted out by another term. >>>>> >>>>>>> If AccECN progresses from experimental to the standards >>>>>>> track, it is intended to be a complete replacement for classic TC= P/ >>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>> >>>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>> >>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent that= we have. >>>>>> >>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as th= e >>>>>>> standards track specification for adding ECN to TCP. >>>>>>> >>>>>>> [ms] This sentence should be removed (or reworded) >>>>>> >>>>>> Why? Does it help to add an only here: >>>>>> >>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as the = only >>>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>> >>>>> This wording is better. >>>>> >>>>>>> AccECN feedback overloads flags and fields in the main TCP header >>>>>>> with new definitions, so both ends have to support the new wire >>>>>>> protocol before it can be used. >>>>>>> >>>>>>> [ms] In my reading this experimental document asks for *new* alloca= tion >>>>>> >>>>>> of a reserved TCP header flag. >>>>>> >>>>>> Is this better? >>>>>> >>>>>> "AccECN feedback overloads the two existing ECN flags as well as the >>>>>> currently reserved and previously called NS flag in the main TC= P >>>>>> header >>>>>> with new definitions, so both ends have to support the new wire >>>>>> protocol >>>>>> before it can be used.=E2=80=9C >>>>>> >>>>>> I understand that you are not happy with the word =E2=80=9Eoverload= =E2=80=9C here but >>>>>> the >>>>>> point of this sentence really is that the flags can/could be used >>>>>> differently >>>>>> and therefore we need a new negotiation before we can use them. >>>>> >>>>> For me the following would work: "AccECN feedback overloads the two >>>>> existing ECN flags and >>>>> allocates the currently reserved and previously called NS flag in the >>>>> main TCP header. >>>>> Given the new definitions, both ends have to support the new wire >>>>> protocol >>>>> before it can be used." >>>>> >>>>> I believe the wording has to be crystal clear on the reservation of b= it 7 >>>>> when it is discussed the first time in the text. In follow-up section= s, >>>>> maybe shorter terms could be used. >>>> >>>> Okay, now: >>>> >>>> "AccECN feedback overloads the two existing ECN flags and >>>> allocates the currently reserved and previously called NS flag in = the >>>> TCP header, to be used as one field indicating the number of >>>> congestion >>>> experienced marked packets. Given the new definitions of these thr= ee >>>> bits, >>>> both ends have to support the new wire protocol before it can = be >>>> used. >>>> Therefore during the TCP handshake the two ends use these three bi= t >>>> in >>>> the TCP header to negotiate the most advanced feedback protocol >>>> that they can both support in a backward compatible way to >>>> ." >>>>>> >>>>>> If you prefer, we can also remove the NS flag in this list, as ECN N= once >>>>>> was >>>>>> anyway never deployed. >>>>>> >>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>> specifies a different response to TCP ECN feedback, for example: >>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>>> Latency >>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], = or >>>>>>> Alternative Backoff with ECN (ABE) >>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>> >>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this paragraph = can >>>>>>> just >>>>>> >>>>>> be deleted. If other experiments need more accurate feedback, it is = up >>>>>> to >>>>>> them to explain how they would use this mechanism. This document sho= uld >>>>>> focus on how to signal the feedback, not how to use that. >>>>>> >>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better to be = explicit >>>>>> about this? >>>>>> >>>>>>> It is likely (but not required) that the AccECN protocol will be >>>>>>> implemented along with the following experimental additions to th= e >>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>> retransmissions >>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable S= YN/ >>>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>> >>>>>>> [ms] I am a big fan of simple, standalone documents. In my view, th= e >>>>>>> TCPM >>>>>> >>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>> draft-ietf- >>>>>> tcpm-generalized-ecn independent documents, which probably implies t= hat >>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If experimentat= ion >>>>>> with ECT in SYN requires a combination, this could be done in a new, >>>>>> third >>>>>> document. Apart from having simpler focused documents, this could >>>>>> significantly help later with moving forward documents to standards >>>>>> track. >>>>>> >>>>>> I disagree, however, this is a discussion to have on draft-ietf-tcpm= - >>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing a refer= ence here >>>>>> that >>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>>>>> >>>>>>> >>>>>>> >>>>>>> * 1.1. Document Roadmap >>>>>>> >>>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>>> introduction >>>>>> >>>>>> and tutorial text with lot's of redundancy towards other documents. = I >>>>>> think >>>>>> the document can be made much easier to read by shorten it. In many >>>>>> cases >>>>>> this is just an editorial change as there is redundancy. As one such >>>>>> example, >>>>>> just remove this section. >>>>>> >>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan of s= hort and >>>>>> concise >>>>>> documents, however, some redundancy can also help understanding, >>>>>> especially if you explain things multiple times but with a different >>>>>> level of >>>>>> detail. I personally would not need the roadmap but I know many peop= le >>>>>> who find these things helpful and to be honest I don=E2=80=99t see h= ow removing >>>>>> this >>>>>> part makes the doc any better. If you don=E2=80=99t want it, don=E2= =80=99t read it. >>>>>> >>>>>>> >>>>>>> * 1.2. Goals >>>>>>> >>>>>>> [ms] I think this section can also just be removed. >>>>>> >>>>>> I have to say I also don=E2=80=99t see the point of removing this pa= rt. Given >>>>>> we=E2=80=99ve >>>>>> done the work on requirements, I think we should also link to this d= oc >>>>>> somewhere. >>>>>>> >>>>>>> >>>>>>> * 1.3. Experiment Goals >>>>>>> >>>>>>> TCP is critical to the robust functioning of the Internet, theref= ore >>>>>>> any proposed modifications to TCP need to be thoroughly tested. T= he >>>>>>> present specification describes an experimental protocol that add= s >>>>>>> more accurate ECN feedback to the TCP protocol. The intention is= to >>>>>>> specify the protocol sufficiently so that more than one >>>>>>> implementation can be built in order to test its function, >>>>>>> robustness >>>>>>> and interoperability (with itself and with previous version of EC= N >>>>>>> and TCP). >>>>>>> >>>>>>> [ms] I think all what is written in this paragraph is obvious, no? >>>>>>> Can't we just >>>>>> >>>>>> delete this? >>>>>> >>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. For m= e both is >>>>>> fine, keep it >>>>>> or remove it. >>>>>> >>>>>>> The experimental protocol will be considered successful if it is >>>>>>> deployed and if it satisfies the requirements of [RFC7560] in the >>>>>>> consensus opinion of the IETF tcpm working group. In short, this >>>>>>> requires that it improves the accuracy and timeliness of TCP's EC= N >>>>>>> feedback, as claimed in Section 5, while striking a balance betwe= en >>>>>>> the conflicting requirements of resilience, integrity and >>>>>>> minimisation of overhead. It also requires that it is not unduly >>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>> behaviours in the current Internet (e.g. hardware offloading and >>>>>>> middleboxes), whether or not they comply with standards. >>>>>>> >>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>> middlebox interference. Current recommended strategies are >>>>>>> specified >>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>>>> these strategies depends on the actual deployment situation of >>>>>>> middleboxes. Therefore experimental verification to confirm larg= e- >>>>>>> scale path traversal in the Internet is needed before finalizing >>>>>>> this >>>>>>> specification on the Standards Track. >>>>>>> >>>>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>>>> >>>>>> mentioned before, I don't think an RFC should speculate about TCPM a= nd >>>>>> its >>>>>> consensus opinion. I would suggest a wording along the lines of: >>>>>>> >>>>>>> >>>>>>> The experimental protocol will be considered successful if >>>>>>> testing confirms that the proposed mechanism can be deployed at >>>>>>> large >>>>>> >>>>>> scale. >>>>>>> >>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>> middlebox interference. Current recommended strategies are >>>>>>> specified >>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>>>> these strategies depends on the actual deployment situation of >>>>>>> middleboxes. Therefore experimental verification to confirm larg= e- >>>>>>> scale path traversal in the Internet is needed, e.g., by support = in >>>>>>> major TCP stacks. >>>>>>> >>>>>>> >>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t think th= at the paraphrase >>>>>> speculates about the consensus of tcpm, in contrast it say tcpm has = to >>>>>> decided if the requirements previously specified by tcpm are >>>>>> sufficiently >>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the requireme= nt draft as >>>>>> this >>>>>> draft as tcpm consensus and was written for this purpose. >>>>> >>>>> My suggested wording uses the expression "can be deployed at large sc= ale" >>>>> and I believe this is relevant. >>>>> >>>>> The document already describes in Section 5 how the protocol satisfie= s >>>>> the agreed requirements for a more accurate ECN feedback protocol [RF= C7560]. >>>>> So, if the TCPM working group publishes this document with the conten= t of >>>>> Section 5, I believe the TCPM working group already has reached conse= nsus >>>>> that the protocol meets requirements. In addition, it is possible tha= t new >>>>> requirements would be identified in future, e.g., as an outcome of th= e >>>>> experiment, and that would obviously have to be considered by TCPM. I= n that >>>>> case, for the success of the experiment not only RFC 7560 would matte= r, but >>>>> also further requirements. My proposed wording does not have all thes= e >>>>> problems. >>>>> >>>>> In a nutshell, I continue to believe that this section has to change. >>>> >>>> >>>> Okay, used your proposed wording. You have a point about the requireme= nt >>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be deployed lar= ge-scale=E2=80=9C. >>>> >>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>> >>>>>>> [ms] This section could probably be shortened as well. >>>>>>> >>>>>>> The last bit in byte 13 of the TCP header was defined as the Nonc= e >>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deploye= d >>>>>>> so >>>>>>> it is being reclassified as historic, making this TCP flag availa= ble >>>>>>> for use by the AccECN experiment instead. >>>>>>> >>>>>>> [ms] This wording, as well as Figure 1, needs to take into account = the >>>>>>> IANA >>>>>> >>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>> >>>>>> Is does. However, I can explicitly say that is has be re-clssified a= s >>>>>> reserved. >>>>>> >>>>>> "RFC 3540 was never deployed so it is being reclassified as historic >>>>>> [I-D.ietf- >>>>>> tsvwg-ecn-experimentation] and the respective flag has been marked a= s >>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags registry, ma= king this TCP flag >>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>> >>>>>> Better? >>>>>> >>>>>>> In my understanding, this experimental document asks for new assign= ment >>>>>> >>>>>> of a reserved TCP header flag. >>>>>> >>>>>> As I said I=E2=80=99m not sure if we have fully concluded this discu= ssion yet. >>>>>> However, >>>>>> what we really would want to is mention somewhere that this experime= nt >>>>>> with this flags is running. I guess there are three options: >>>>>> 1) keep it in the registry as reserved and conserve the knowledge in >>>>>> tcpm >>>>>> that this experiment is running and no other experimental RFC such u= se >>>>>> this >>>>>> flags as long as this experiment is running. >>>>>> 2) Keep is marked as reserved but add a note about this experiment i= n >>>>>> the >>>>>> IANA registry >>>>>> 3) Or assign it right away with IESG approval. I guess in this case = tcpm >>>>>> could >>>>>> also consider to change the registration policy to =E2=80=9EIETF Rev= iew=E2=80=9C. >>>>> >>>>> The current registration policy for the TCP header flags is "standard= s >>>>> action". I understand that the IESG could approve exceptions. But giv= en the >>>>> policy, I believe the document has to be very precise on the request >>>>> regarding bit 7. >>>> >>>> Okay, it now says: >>>> >>>> "[TO BE REMOVED: IANA is requested to update the existing entry in the >>>> Transmission Control Protocol (TCP) Header Flags registration >>>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xh= tml#tcp-header-flags-1) >>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS (No= nce >>>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be in= stead >>>> of RFC8311.]=E2=80=9C >>>> >>>> I guess we could also ask IANA to add an additional comment column ins= tead >>>> (but not sure if we then have to update RFC3168, which I think we real= ly >>>> don=E2=80=99t want. Should be fine now. >>>> >>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>> >>>>>>> o an essential part that re-uses ECN TCP header bits to feed bac= k >>>>>>> the number of arriving CE marked packets. This provides more >>>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>>> against >>>>>>> ACK loss; >>>>>>> >>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>> >>>>>> I think this is nit picking. Using a different phrasing here makes t= he >>>>>> sentence >>>>>> unnecessary complicated. We don=E2=80=99t try to some how get a roun= d the fact >>>>>> that we need to handle the flag registration correctly. However, her= e >>>>>> the >>>>>> point really is to explain how the protocol word. The main point of >>>>>> using the >>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that these = flags are or have >>>>>> been >>>>>> used different by other TCP extension (and we therefore need a prope= r >>>>>> negotiation scheme). >>>>> >>>>> If the allocation of a reserved flag is correctly explained in the >>>>> abstract and introduction, I think these sentences can use a bit rela= xed >>>>> terminology. >>>>> >>>>>>> The two part design was necessary, given limitations on the space >>>>>>> available for TCP options and given the possibility that certain >>>>>>> incorrectly designed middleboxes prevent TCP using any new option= s > From nobody Thu Jul 12 09:04:08 2018 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 55DCF130E28; Thu, 12 Jul 2018 09:04:06 -0700 (PDT) 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, 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 TgZ5TbF1LroZ; Thu, 12 Jul 2018 09:04:01 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3857C130DD7; Thu, 12 Jul 2018 09:04:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41RLMz4g31zMpYy; Thu, 12 Jul 2018 18:03:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYmtVUjmTTli; Thu, 12 Jul 2018 18:03:56 +0200 (CEST) X-MtScore: NO score=0 Received: from [172.20.4.114] (unknown [207.96.227.101]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 12 Jul 2018 18:03:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 12 Jul 2018 12:03:52 -0400 Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 12 Jul 2018 16:04:07 -0000 Hi Yuchung, please see below. > Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >=20 > Yes packets with ACE options and (different) ACE-counter header would > break GRO. There're many legacy h/w and s/w. I=E2=80=99m not the expert here but my understanding is that is would = not break GRO but could not make actual use or it if the ACE counter = changed or the option is present. However, usually your will only have a = small number of CE marks every couple of RTTs, and the counter only = changes if you CE marks/the option is only present a few times per RTT. = So the impact should be rather low. But this clear something to evaluate = for the experiment. >=20 > Even without option, ACE header only allows reflecting up to 8 packets > for receiver segmentation offload and ACK suppression? Same as above, it can only up to 8 CE marked packets per ACK, however, = CE marking rater are expected to be rather low. ACK suppression should = probably not be used if the ACE counter has changes, however, usually = the ACE counter stays stable for multiple RTTs and then ACK suppression = is not a problem. However, not sure I understood you question here = correctly=E2=80=A6? >=20 > The appendix on ack loss causes ambiguity is good: but the pattern > drops specifically the state-switch (CE<->noCE) ACK which only happens > on delayed ACK. Is that pattern common? - or can we address most of > that by delaying less ACKs? I guess you have a 50% chance today to hit a delayed ACK. I guess = delaying less (where you delay every second ACK today) would mean ACK = very packet, and thus double ACK load on the network. I guess on today = networks that actually in most cases not a problem, however, there might = be specially cases where it is. However, that=E2=80=99s problem an = independent question to evaluate. >=20 > I am all for making ECN more accurate for wide area beyond DCTCP, but > am evaluating the pros/cons. What if we just > 1. negotiate 'better' ECN via new SYN option Not sure I understand your proposal correctly, but I assume you mean = negotiate via SYN option and then just use the ACE counter in the = header? If so, I don=E2=80=99t understand why you see the negotiation = part in the TCP header as the problem? > 2. mark all packets like ECN++ That would be nice but here you actually need AccECN because you want to = have feedback for control packets as well. AccECN is providing this = feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; = that=E2=80=99s what we have ECN++ for; both thing ideally would be = deployed together however. Was that your questions? Mirja >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind > wrote: >> Hi Yuchung, >>=20 >> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy = really depends on the use case. If you use DCTCP as today, the ACE = counter in the TCP is probably sufficient and you might not want to pay = the additional overhead in your data center (that why the option is = actually optional). >>=20 >> If you however, e.g., have very differently sized packets, then the = byte counter in the option could give you a more accurate signal. Or if = you are also interested in the ECT(1) counter, you need the option. = Further the ACE counter also give your feedback on control packet and = the option enables you to distinguish between CE-amrked payload and = control packets, which can also become important when experimenting with = making all packets ECN-capable. >>=20 >> Given accECN is a general feedback mechanism that in fact is designed = to enable new future uses of the ECN signal, we wanted to keep all these = option available while making is still as simple as possible and as = flexible as possible. >>=20 >> Mirja >>=20 >>=20 >>=20 >>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>=20 >>> Hi Bob, >>>=20 >>> Neal and I evaluated the earlier draft. It is well-thought out but >>> we're concerned about the options. Option is not mandatory but the >>> lack of it also reduces accuracy. Option runs into space issues w/ >>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure = but >>> aren't easy. >>>=20 >>> We're curious how much more "accuracy" it buys over current >>> DCTCP-style ECN. Is there any study to show trade-offs of >>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>=20 >>>=20 >>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe = wrote: >>>> Michael, tcpm list, >>>>=20 >>>> As well as addressing your points, as Mirja has already mentioned = below, we >>>> added a whole new appendix giving the rationale for the bits and = codepoints >>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >>>> subsection also identifies space for future evolution. It also = points to >>>> where rationale was already given in the body of the draft. >>>>=20 >>>> The appendix is in the draft submitted last week, available here: >>>> = https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>>>=20 >>>> We'd be interested to hear whether this allays your concerns. >>>>=20 >>>> We have asked to present this in Montreal as well. >>>>=20 >>>> Cheers >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>=20 >>>>> Hi Micheal, >>>>>=20 >>>>> I addressed a couple of your comments below. >>>>>=20 >>>>> For the other, bigger comments regarding extensibility, that I did = not yet >>>>> address below, we plan to add a new section to the appendix to = explain >>>>> extensibility options as previously discussed by mail. We will = probably send >>>>> a separate email on that part. >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - = DE/Stuttgart) >>>>>> : >>>>>>=20 >>>>>> Hi Mirja, >>>>>>=20 >>>>>> Thanks a lot for the explanation. I won't follow-up on some of = the >>>>>> editorial suggestions. >>>>>>=20 >>>>>> Yet, I continue to believe that some formal wording in the = document needs >>>>>> to change, as explained below. >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> Michael (with no hat on) >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Mirja K=C3=BChlewind = [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) = >>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>=20 >>>>>>> Hi Micheal, >>>>>>>=20 >>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>=20 >>>>>>> Please see inline. >>>>>>>=20 >>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - = DE/Stuttgart) >>>>>>>=20 >>>>>>> : >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the = appendix). I >>>>>>>=20 >>>>>>> believe this document needs further work before moving forward. >>>>>>>>=20 >>>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>>>=20 >>>>>>> document independent of the review from Gorry. I apologize if = there is >>>>>>> duplication. >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>>=20 >>>>>>>> Michael (with no hat on) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ****************************** >>>>>>>>=20 >>>>>>>> * Abstract: >>>>>>>>=20 >>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) = or >>>>>>>> Data >>>>>>>=20 >>>>>>> Center TCP >>>>>>>>=20 >>>>>>>> (DCTCP) need more accurate ECN feedback information whenever = more >>>>>>>> than one marking is received in one RTT. >>>>>>>>=20 >>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257. = I >>>>>>>> suggest to >>>>>>>=20 >>>>>>> remove this, or replace it by a more generic statement that more >>>>>>> accurate >>>>>>> information can be useful for several TCP extensions. >>>>>>>=20 >>>>>>> I disagree. Both ConEx and DCTCP need more accurate information. = They do >>>>>>> not need the mechanism that is specified in this draft, however, = this is >>>>>>> not >>>>>>> what the sentences is saying. >>>>>>=20 >>>>>> In my understanding (as a non-native speaker), the use of the = word "need" >>>>>> is not correct here. DCTCP as specified in RFC 8257 can be = implemented >>>>>> without any such mechanism. >>>>>>=20 >>>>>> What would work for me is something of the form "... Data Center = TCP >>>>>> cannot get precise ECN feedback whenever more than one marking is = received >>>>>> in one RTT=E2=80=9C. >>>>>=20 >>>>> This is not correct. DCTP need more than one feedback signal per = RTT and >>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s = own feedback >>>>> mechanism. However, to avoid confusion such that people could = assume DCTP >>>>> would not work without the accECN scheme as specified in this doc, = I >>>>> rephrased to: >>>>>=20 >>>>> "Recently, proposed >>>>> mechanisms like Congestion Exposure (ConEx >>>> target=3D"RFC7713"/>), >>>>> DCTCP or L4S >>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more = than one >>>>> marking is received in one RTT which is >>>>> information that cannot be provided by the feedback scheme as >>>>> specified in >>>>> ." >>>>>=20 >>>>>=20 >>>>>>>> This document specifies an >>>>>>>> experimental scheme to provide more than one feedback signal = per RTT >>>>>>>> in the TCP header. Given TCP header space is scarce, it = overloads >>>>>>>> the three existing ECN-related flags in the TCP header and = provides >>>>>>>> additional information in a new TCP option. >>>>>>>>=20 >>>>>>>> [ms] This statement needs to be rewritten to correctly reflect = what is >>>>>>>=20 >>>>>>> requested from IANA. My understanding is that this experimental = document >>>>>>> asks for allocation of a reserved TCP header flag. This needs to = be >>>>>>> called out >>>>>>> prominently, IMHO. In addition, since this is not a standard, = the >>>>>>> suggested >>>>>>> experimentation with the main TCP header must IMHO be explicitly >>>>>>> mentioned. I also suggest to have later in a document a section = that >>>>>>> explicitly >>>>>>> explains why it is appropriate to modify the main TCP header in = an >>>>>>> experiment. >>>>>>>=20 >>>>>>> I don=E2=80=99t know if any requirement that IANA assignment = need to be called >>>>>>> out >>>>>>> in the abstract but we can do that. However, I believe the = question if >>>>>>> this >>>>>>> document should or should not assign the bit is still not = completely >>>>>>> solved, or >>>>>>> is it? >>>>>>=20 >>>>>> I believe this question will have to be reviewed during WGLC and, = more >>>>>> importantly, IETF last call. For the moment, my concern is that = the document >>>>>> correctly describes the IANA allocation. >>>>>>=20 >>>>>> I would like to see here a statement such as : "Given TCP header = space is >>>>>> scarce, this specification allocates a reserved header bit and = overloads the >>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>=20 >>>>> A bit lengthy but now: >>>>>=20 >>>>> "Given TCP header space is >>>>> scarce, it allocates a reserved header bit, that was = previously >>>>> used for >>>>> ECN-Nonce which was recently declared historic, and overloads = the >>>>> two existing ECN flags in the TCP header. Further, additional >>>>> information can be provided in a new TCP option that however = is not >>>>> used >>>>> on the TCP SYN." >>>>>=20 >>>>>>>> * 1. Introduction >>>>>>>>=20 >>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] = need >>>>>>>> more accurate ECN feedback information whenever more than one >>>>>>>=20 >>>>>>> marking >>>>>>>>=20 >>>>>>>> is received in one RTT. >>>>>>>>=20 >>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit = this. >>>>>>>> Instead >>>>>>>=20 >>>>>>> of stating a "need", it would IMHO make more sense to discuss = the >>>>>>> benefits >>>>>>> of the suggested mechanism in this document of its own, = independent of >>>>>>> other proposals. To me, this document should be independent of = other >>>>>>> documents and specifically other experiments. We have to think = about >>>>>>> cases >>>>>>> where not all experiments are successful. Then independent = documents >>>>>>> will >>>>>>> be more future-proof in future. >>>>>>>=20 >>>>>>> This is a naming collision=E2=80=A6 The sentence was meant to = say that these >>>>>>> mechanisms new more accurate ECN feedback than provided today by >>>>>>> RFC3168 but it was not meant to say that these mechanism have to = use the >>>>>>> scheme as specified in this document. >>>>>>>=20 >>>>>>> I added the following part sentence: >>>>>>>=20 >>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure = (ConEx >>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] = need more >>>>>>> accurate ECN feedback information than provided by the feedback = scheme >>>>>>> as specified in [RFC3168] whenever more than one marking is = received in >>>>>>> one >>>>>>> RTT. This document specifies an alternative feedback scheme that >>>>>>> provides >>>>>>> more accurate information and could be used by these new TCP >>>>>>> extensions.=E2=80=9C >>>>>>>=20 >>>>>>> Does this help? >>>>>>=20 >>>>>> See my proposal for the abstract. I continue to disagree with the = term >>>>>> "need" but I think this can be sorted out by another term. >>>>>>=20 >>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>> track, it is intended to be a complete replacement for classic = TCP/ >>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>=20 >>>>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>>>=20 >>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent = that we have. >>>>>>>=20 >>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as = the >>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>=20 >>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>=20 >>>>>>> Why? Does it help to add an only here: >>>>>>>=20 >>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as = the only >>>>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>>>=20 >>>>>> This wording is better. >>>>>>=20 >>>>>>>> AccECN feedback overloads flags and fields in the main TCP = header >>>>>>>> with new definitions, so both ends have to support the new = wire >>>>>>>> protocol before it can be used. >>>>>>>>=20 >>>>>>>> [ms] In my reading this experimental document asks for *new* = allocation >>>>>>>=20 >>>>>>> of a reserved TCP header flag. >>>>>>>=20 >>>>>>> Is this better? >>>>>>>=20 >>>>>>> "AccECN feedback overloads the two existing ECN flags as well as = the >>>>>>> currently reserved and previously called NS flag in the main = TCP >>>>>>> header >>>>>>> with new definitions, so both ends have to support the new = wire >>>>>>> protocol >>>>>>> before it can be used.=E2=80=9C >>>>>>>=20 >>>>>>> I understand that you are not happy with the word =E2=80=9Eoverloa= d=E2=80=9C here but >>>>>>> the >>>>>>> point of this sentence really is that the flags can/could be = used >>>>>>> differently >>>>>>> and therefore we need a new negotiation before we can use them. >>>>>>=20 >>>>>> For me the following would work: "AccECN feedback overloads the = two >>>>>> existing ECN flags and >>>>>> allocates the currently reserved and previously called NS flag in = the >>>>>> main TCP header. >>>>>> Given the new definitions, both ends have to support the new wire >>>>>> protocol >>>>>> before it can be used." >>>>>>=20 >>>>>> I believe the wording has to be crystal clear on the reservation = of bit 7 >>>>>> when it is discussed the first time in the text. In follow-up = sections, >>>>>> maybe shorter terms could be used. >>>>>=20 >>>>> Okay, now: >>>>>=20 >>>>> "AccECN feedback overloads the two existing ECN flags and >>>>> allocates the currently reserved and previously called NS flag = in the >>>>> TCP header, to be used as one field indicating the number of >>>>> congestion >>>>> experienced marked packets. Given the new definitions of these = three >>>>> bits, >>>>> both ends have to support the new wire protocol before it = can be >>>>> used. >>>>> Therefore during the TCP handshake the two ends use these three = bit >>>>> in >>>>> the TCP header to negotiate the most advanced feedback protocol >>>>> that they can both support in a backward compatible way to >>>>> ." >>>>>>>=20 >>>>>>> If you prefer, we can also remove the NS flag in this list, as = ECN Nonce >>>>>>> was >>>>>>> anyway never deployed. >>>>>>>=20 >>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>> specifies a different response to TCP ECN feedback, for = example: >>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>>>> Latency >>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>> ECN-capable TCP control packets = [I-D.ietf-tcpm-generalized-ecn], or >>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>=20 >>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this = paragraph can >>>>>>>> just >>>>>>>=20 >>>>>>> be deleted. If other experiments need more accurate feedback, it = is up >>>>>>> to >>>>>>> them to explain how they would use this mechanism. This document = should >>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>=20 >>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better to = be explicit >>>>>>> about this? >>>>>>>=20 >>>>>>>> It is likely (but not required) that the AccECN protocol will = be >>>>>>>> implemented along with the following experimental additions to = the >>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>> retransmissions >>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the = ECN-capable SYN/ >>>>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>=20 >>>>>>>> [ms] I am a big fan of simple, standalone documents. In my = view, the >>>>>>>> TCPM >>>>>>>=20 >>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>> draft-ietf- >>>>>>> tcpm-generalized-ecn independent documents, which probably = implies that >>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If = experimentation >>>>>>> with ECT in SYN requires a combination, this could be done in a = new, >>>>>>> third >>>>>>> document. Apart from having simpler focused documents, this = could >>>>>>> significantly help later with moving forward documents to = standards >>>>>>> track. >>>>>>>=20 >>>>>>> I disagree, however, this is a discussion to have on = draft-ietf-tcpm- >>>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing a = reference here >>>>>>> that >>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> * 1.1. Document Roadmap >>>>>>>>=20 >>>>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>>>> introduction >>>>>>>=20 >>>>>>> and tutorial text with lot's of redundancy towards other = documents. I >>>>>>> think >>>>>>> the document can be made much easier to read by shorten it. In = many >>>>>>> cases >>>>>>> this is just an editorial change as there is redundancy. As one = such >>>>>>> example, >>>>>>> just remove this section. >>>>>>>=20 >>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan = of short and >>>>>>> concise >>>>>>> documents, however, some redundancy can also help understanding, >>>>>>> especially if you explain things multiple times but with a = different >>>>>>> level of >>>>>>> detail. I personally would not need the roadmap but I know many = people >>>>>>> who find these things helpful and to be honest I don=E2=80=99t = see how removing >>>>>>> this >>>>>>> part makes the doc any better. If you don=E2=80=99t want it, = don=E2=80=99t read it. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> * 1.2. Goals >>>>>>>>=20 >>>>>>>> [ms] I think this section can also just be removed. >>>>>>>=20 >>>>>>> I have to say I also don=E2=80=99t see the point of removing = this part. Given >>>>>>> we=E2=80=99ve >>>>>>> done the work on requirements, I think we should also link to = this doc >>>>>>> somewhere. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> * 1.3. Experiment Goals >>>>>>>>=20 >>>>>>>> TCP is critical to the robust functioning of the Internet, = therefore >>>>>>>> any proposed modifications to TCP need to be thoroughly = tested. The >>>>>>>> present specification describes an experimental protocol that = adds >>>>>>>> more accurate ECN feedback to the TCP protocol. The intention = is to >>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>> implementation can be built in order to test its function, >>>>>>>> robustness >>>>>>>> and interoperability (with itself and with previous version of = ECN >>>>>>>> and TCP). >>>>>>>>=20 >>>>>>>> [ms] I think all what is written in this paragraph is obvious, = no? >>>>>>>> Can't we just >>>>>>>=20 >>>>>>> delete this? >>>>>>>=20 >>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. = For me both is >>>>>>> fine, keep it >>>>>>> or remove it. >>>>>>>=20 >>>>>>>> The experimental protocol will be considered successful if it = is >>>>>>>> deployed and if it satisfies the requirements of [RFC7560] in = the >>>>>>>> consensus opinion of the IETF tcpm working group. In short, = this >>>>>>>> requires that it improves the accuracy and timeliness of TCP's = ECN >>>>>>>> feedback, as claimed in Section 5, while striking a balance = between >>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>> minimisation of overhead. It also requires that it is not = unduly >>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>> behaviours in the current Internet (e.g. hardware offloading = and >>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>=20 >>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>> specified >>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>> middleboxes. Therefore experimental verification to confirm = large- >>>>>>>> scale path traversal in the Internet is needed before = finalizing >>>>>>>> this >>>>>>>> specification on the Standards Track. >>>>>>>>=20 >>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>>>>>=20 >>>>>>> mentioned before, I don't think an RFC should speculate about = TCPM and >>>>>>> its >>>>>>> consensus opinion. I would suggest a wording along the lines of: >>>>>>>>=20 >>>>>>>> >>>>>>>> The experimental protocol will be considered successful if >>>>>>>> testing confirms that the proposed mechanism can be deployed = at >>>>>>>> large >>>>>>>=20 >>>>>>> scale. >>>>>>>>=20 >>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>> specified >>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>> middleboxes. Therefore experimental verification to confirm = large- >>>>>>>> scale path traversal in the Internet is needed, e.g., by = support in >>>>>>>> major TCP stacks. >>>>>>>> >>>>>>>>=20 >>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t = think that the paraphrase >>>>>>> speculates about the consensus of tcpm, in contrast it say tcpm = has to >>>>>>> decided if the requirements previously specified by tcpm are >>>>>>> sufficiently >>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the = requirement draft as >>>>>>> this >>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>=20 >>>>>> My suggested wording uses the expression "can be deployed at = large scale" >>>>>> and I believe this is relevant. >>>>>>=20 >>>>>> The document already describes in Section 5 how the protocol = satisfies >>>>>> the agreed requirements for a more accurate ECN feedback protocol = [RFC7560]. >>>>>> So, if the TCPM working group publishes this document with the = content of >>>>>> Section 5, I believe the TCPM working group already has reached = consensus >>>>>> that the protocol meets requirements. In addition, it is possible = that new >>>>>> requirements would be identified in future, e.g., as an outcome = of the >>>>>> experiment, and that would obviously have to be considered by = TCPM. In that >>>>>> case, for the success of the experiment not only RFC 7560 would = matter, but >>>>>> also further requirements. My proposed wording does not have all = these >>>>>> problems. >>>>>>=20 >>>>>> In a nutshell, I continue to believe that this section has to = change. >>>>>=20 >>>>>=20 >>>>> Okay, used your proposed wording. You have a point about the = requirement >>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be deployed = large-scale=E2=80=9C. >>>>>=20 >>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>=20 >>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>=20 >>>>>>>> The last bit in byte 13 of the TCP header was defined as the = Nonce >>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never = deployed >>>>>>>> so >>>>>>>> it is being reclassified as historic, making this TCP flag = available >>>>>>>> for use by the AccECN experiment instead. >>>>>>>>=20 >>>>>>>> [ms] This wording, as well as Figure 1, needs to take into = account the >>>>>>>> IANA >>>>>>>=20 >>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>>>=20 >>>>>>> Is does. However, I can explicitly say that is has be = re-clssified as >>>>>>> reserved. >>>>>>>=20 >>>>>>> "RFC 3540 was never deployed so it is being reclassified as = historic >>>>>>> [I-D.ietf- >>>>>>> tsvwg-ecn-experimentation] and the respective flag has been = marked as >>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags = registry, making this TCP flag >>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>=20 >>>>>>> Better? >>>>>>>=20 >>>>>>>> In my understanding, this experimental document asks for new = assignment >>>>>>>=20 >>>>>>> of a reserved TCP header flag. >>>>>>>=20 >>>>>>> As I said I=E2=80=99m not sure if we have fully concluded this = discussion yet. >>>>>>> However, >>>>>>> what we really would want to is mention somewhere that this = experiment >>>>>>> with this flags is running. I guess there are three options: >>>>>>> 1) keep it in the registry as reserved and conserve the = knowledge in >>>>>>> tcpm >>>>>>> that this experiment is running and no other experimental RFC = such use >>>>>>> this >>>>>>> flags as long as this experiment is running. >>>>>>> 2) Keep is marked as reserved but add a note about this = experiment in >>>>>>> the >>>>>>> IANA registry >>>>>>> 3) Or assign it right away with IESG approval. I guess in this = case tcpm >>>>>>> could >>>>>>> also consider to change the registration policy to =E2=80=9EIETF = Review=E2=80=9C. >>>>>>=20 >>>>>> The current registration policy for the TCP header flags is = "standards >>>>>> action". I understand that the IESG could approve exceptions. But = given the >>>>>> policy, I believe the document has to be very precise on the = request >>>>>> regarding bit 7. >>>>>=20 >>>>> Okay, it now says: >>>>>=20 >>>>> "[TO BE REMOVED: IANA is requested to update the existing entry in = the >>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>> = (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#= tcp-header-flags-1) >>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS = (Nonce >>>>> Sum) [RFC3540, RFC8311]" and change the reference to this = RFC-to-be instead >>>>> of RFC8311.]=E2=80=9C >>>>>=20 >>>>> I guess we could also ask IANA to add an additional comment column = instead >>>>> (but not sure if we then have to update RFC3168, which I think we = really >>>>> don=E2=80=99t want. Should be fine now. >>>>>=20 >>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>=20 >>>>>>>> o an essential part that re-uses ECN TCP header bits to feed = back >>>>>>>> the number of arriving CE marked packets. This provides = more >>>>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>>>> against >>>>>>>> ACK loss; >>>>>>>>=20 >>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>=20 >>>>>>> I think this is nit picking. Using a different phrasing here = makes the >>>>>>> sentence >>>>>>> unnecessary complicated. We don=E2=80=99t try to some how get a = round the fact >>>>>>> that we need to handle the flag registration correctly. However, = here >>>>>>> the >>>>>>> point really is to explain how the protocol word. The main point = of >>>>>>> using the >>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that = these flags are or have >>>>>>> been >>>>>>> used different by other TCP extension (and we therefore need a = proper >>>>>>> negotiation scheme). >>>>>>=20 >>>>>> If the allocation of a reserved flag is correctly explained in = the >>>>>> abstract and introduction, I think these sentences can use a bit = relaxed >>>>>> terminology. >>>>>>=20 >>>>>>>> The two part design was necessary, given limitations on the = space >>>>>>>> available for TCP options and given the possibility that = certain >>>>>>>> incorrectly designed middleboxes prevent TCP using any new = options >>=20 From nobody Thu Jul 12 09:25:51 2018 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 A520E130E9A; Thu, 12 Jul 2018 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-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=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 3baXLfK5qTup; Thu, 12 Jul 2018 09:25:44 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730118.outbound.protection.outlook.com [40.107.73.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D957130E89; Thu, 12 Jul 2018 09:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XuNv93+y1pH3k8cnuNP1QmtjSgyDIy5cBSp6mzmHZOs=; b=FL3qaepGCZJHO8b1WmiZaYXTgCeaHMRQ3U9xlVapnhtj/HLiQqHHEJxYXdOZzt7MjlPLJTZc50E2yAgWMeG638Hs9u9YUeDI+KE5zSYq3xfaIENkbHtUEXy+YxdAZroVXrZZv9BTQAJk+HYRwRvXGKHNdQ9f6qK+yp28sc2UsVI= Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0829.namprd21.prod.outlook.com (10.173.51.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.12; Thu, 12 Jul 2018 16:25:41 +0000 Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::60a2:45d4:b972:fca4]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::60a2:45d4:b972:fca4%6]) with mapi id 15.20.0973.013; Thu, 12 Jul 2018 16:25:41 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Yuchung Cheng CC: "tcpm@ietf.org" , "draft-ietf-tcpm-accurate-ecn@ietf.org" Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn Thread-Index: AdNsZwbKZl7dQfJhQeSI1pXOpUN55hIGf9OAAUAqXJAWJtFgAAHJBo4AAAE8zAAAIRU6AAALHRSAAADIbAAAAHfNAA== Date: Thu, 12 Jul 2018 16:25:41 +0000 Message-ID: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:b:f1c6:cdc0:5b39:ca82] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0829; 6:lEVAW1U3GljQx5jjzoddeUM69baXSTSQ4Y52kf4tTb1bH/QK/kfvwjP5ByEl9TrndvFxYhh6NtAqyMQxglF9T1tt1C5hIPaZYslqu3xNb7vKbnrBMaKOAtoUjHFzbOv4T6UVSx79TVKxOgkIIgQgdrjkEd2x3PV6OfJrngsnjjhhLgwk/nfxZJKhNZKYMd5boyb6cs63uChsEg0fpdDmxW541BxlfgKpbDOO7bkCkQs+N60rPRo9k+NacI3I4p9pfN6IVMEo8onGu/kWkFUQSuQXvdmJ2ThGeopYQf8uvet0kBbbJ8EBKKetAZpftJsdMVaSxcG6LTyGbQ637JkfLb7NRhb5mWweydA5NsGmhxarPPBYnXGXC62jrLrZWEEV82Ah02Iwa2GXvErHoY6gdTBlDfCch1Ul43g8hdfm919zIWx5ujMgEH/BLpdawMG2zKwAFaCqMNU/lMCwsQatvQ==; 5:W113PJod2BEfG9+/bYDNYE4tIfp1OKJy5n7ZQ+4RtWm9x67Zo2FSXKrJDOtC5sfJ/BwBfaRcKQ0NrjR12N7iRAANCsKLfEf2Dq9WU3clJsKXKfLEws6VQZmwxwtOR8UF4sVVLHMi7uC6h8LmNW730YqUp+S6uuNvj9broUscpRs=; 7:A1nsf7pK/aRFoPt56fdGxj50H5VsoZuYu3NeoLGzNOUcuU4dvo+WhVcVNeCVbRiuVZ6o8AygkIn2Y5+KAUSofPWpIgS/1Gzu7NpDQb/h8URGPG2qSR0VG++wqCeczJomqUbF7SQyEfOE8DdqnT0L6UhRDb63BsUWDBPKVwwygRLbVuJliwYJo1/nriG7SCkYARQg2iL2dQpSHSFozQMoXO4ZtkWld98uexrEdTMxID+CyTAyCxtL/9z7C8XPyWAy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: aafaaa25-e685-483a-f2b8-08d5e8141c73 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:MWHPR21MB0829; x-ms-traffictypediagnostic: MWHPR21MB0829: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(82608151540597)(109105607167333)(788757137089)(211936372134217)(100405760836317)(153496737603132)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(2018427008)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR21MB0829; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0829; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(39860400002)(396003)(53754006)(189003)(199004)(52314003)(13464003)(446003)(97736004)(7736002)(8936002)(256004)(14444005)(33656002)(8990500004)(6436002)(186003)(14454004)(93886005)(55016002)(561944003)(8676002)(81166006)(81156014)(966005)(305945005)(16200700003)(53946003)(46003)(9686003)(10090500001)(478600001)(5660300001)(6306002)(74316002)(2900100001)(476003)(53936002)(105586002)(68736007)(99286004)(11346002)(7696005)(86612001)(22452003)(106356001)(25786009)(10290500003)(110136005)(316002)(54906003)(6246003)(5250100002)(6116002)(2906002)(229853002)(486006)(575784001)(76176011)(102836004)(4326008)(86362001)(53546011)(6506007)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0829; H:MWHPR21MB0191.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-microsoft-antispam-message-info: zYauDOo6uyucYhsrpCOiZb6TrZweGmq4tvkkf3nk+6BRKemuSdVFYQpukS1h6xqlnX4F6ikL0gSOLaMHfB8TtSNJRSfT/yHFHblSAU26zuxk8mECbwl3H7w7WlMvEslCJyrWlDDiJRoRWMzuwsy+63sYhTW9WJM9qkIS6AmPZ2d9bp7WgNdHTlBUW0NnZ0+EuI+60ta78iEb2pOizj6e490J0m2Qedq5+aT3+aMwS0uYbAB33x8c25y2i/RYBsRZ886/wIHyrTRGI6j42cxm2CzSJIf4KdjNDQnswoIxEkZhwqz888x3SGHK1aUk55hVPsnC5rb4vi3q/ON15w/0bqmTfgQwWeGZAI229pYYINE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: aafaaa25-e685-483a-f2b8-08d5e8141c73 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 16:25:41.5702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0829 Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 12 Jul 2018 16:25:50 -0000 SSBoYWQgc2ltaWxhciBjb25jZXJucyB3aXRoIHRoZSBuZXcgVENQIG9wdGlvbiBhdCB0aGUgbGFz dCB0Y3BtIG1lZXRpbmcuIEkgd2FzIHJlcXVlc3RpbmcgdGhhdCB3ZSBtYWtlIHRoZSBvcHRpb24g dHJ1bHkgb3B0aW9uYWwgYnV0IEkgZ290IHNvbWUgZmVlZGJhY2sgdGhhdCBpbXBsZW1lbnRhdGlv bnMgc2hvdWxkIGhvbm9yIGFuZCBwcm9jZXNzIHRoZSBvcHRpb24gb24gcmVjZWl2ZSBldmVuIGlm IHRoZXkgZG9u4oCZdCBnZW5lcmF0ZSBpdC4gSSdkIHByZWZlciBpZiB3ZSBtYWtlIHRoZSBhY2N1 cmF0ZSBtZWFzdXJlbWVudHMgcGFydCBvcHRpb25hbC4gVGhlIGJpZ2dlc3QgYWR2YW50YWdlIG9m IEFjY3VyYXRlIEVDTiBpcyB0aGUgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHRoYXQgRENUQ1AgbGFj a3MgYW5kIHRoZSBzYW1lIG5lZ290aWF0aW9uIGNhbiBiZSB1c2VkIG9uIHRoZSBJbnRlcm5ldCBm b3IgYW55IHNjYWxhYmxlIFRDUCB0aGF0IHdhbnRzIHRvIHJlbHkgb24gYWNjdXJhdGUgRUNOLg0K DQpSZS4gR1JPL0xSTy9SU0M6IGh0dHBzOi8vZG9jcy5taWNyb3NvZnQuY29tL2VuLXVzL3dpbmRv d3MtaGFyZHdhcmUvZHJpdmVycy9uZXR3b3JrL2V4Y2VwdGlvbi1jb25kaXRpb25zLXRoYXQtdGVy bWluYXRlLWNvYWxlc2Npbmcgc2VlIGNvbmRpdGlvbiA0IGZvciBhbiBleGNlcHRpb24gdGhhdCB0 ZXJtaW5hdGVzIGNvYWxlc2Npbmc6ICJUaGUgc2VnbWVudCBjb250YWlucyBvbmUgb3IgbW9yZSBU Q1Agb3B0aW9ucyBvdGhlciB0aGFuIHRoZSBUQ1AgdGltZXN0YW1wIG9wdGlvbiIuIFNvIHdoaWxl IHNvZnR3YXJlIGltcGxlbWVudGF0aW9ucyBvZiBjb2FsZXNjaW5nIGNhbiBiZSB1cGRhdGVkLCBl eGlzdGluZyBoYXJkd2FyZSB3aWxsIGNhdXNlIHBvb3IgcGVyZm9ybWFuY2Ugd2l0aCBuZXcgVENQ IG9wdGlvbnMgdGhhdCBhcmUgcHJlc2VudCBpbiBhIGxvdCBvZiBkYXRhIHBhY2tldHMuIA0KDQo+ PiBiZWNhdXNlIHlvdSB3YW50IHRvIGhhdmUgZmVlZGJhY2sgZm9yIGNvbnRyb2wgcGFja2V0cyBh cyB3ZWxsDQpJIGRvbuKAmXQgZnVsbHkgdW5kZXJzdGFuZCB0aGlzLiBFQ04rKyBhbGxvd3MgbWFy a2luZyBvZiBjb250cm9sIHBhY2tldHMgYW5kIGRlZmluZXMgYSByZXNwb25zZS4gRG8gd2UgcmVh bGx5IG5lZWQgdGhlIFRDUCBvcHRpb24gZm9yIHByb2Nlc3NpbmcgdGhlIGZlZWRiYWNrPw0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphIEvDvGhsZXdpbmQNClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDEyLCAyMDE4IDk6MDQgQU0NClRvOiBZdWNodW5nIENoZW5nIDx5Y2hlbmdAZ29vZ2xl LmNvbT4NCkNjOiB0Y3BtQGlldGYub3JnOyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1h Y2N1cmF0ZS1lY24NCg0KSGkgWXVjaHVuZywNCg0KcGxlYXNlIHNlZSBiZWxvdy4NCg0KPiBBbSAx Mi4wNy4yMDE4IHVtIDExOjQxIHNjaHJpZWIgWXVjaHVuZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5j b20+Og0KPiANCj4gWWVzIHBhY2tldHMgd2l0aCBBQ0Ugb3B0aW9ucyBhbmQgKGRpZmZlcmVudCkg QUNFLWNvdW50ZXIgaGVhZGVyIHdvdWxkIA0KPiBicmVhayBHUk8uIFRoZXJlJ3JlIG1hbnkgbGVn YWN5IGgvdyBhbmQgcy93Lg0KDQpJ4oCZbSBub3QgdGhlIGV4cGVydCBoZXJlIGJ1dCBteSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgaXMgd291bGQgbm90IGJyZWFrIEdSTyBidXQgY291bGQgbm90IG1h a2UgYWN0dWFsIHVzZSBvciBpdCBpZiB0aGUgQUNFIGNvdW50ZXIgY2hhbmdlZCBvciB0aGUgb3B0 aW9uIGlzIHByZXNlbnQuIEhvd2V2ZXIsIHVzdWFsbHkgeW91ciB3aWxsIG9ubHkgaGF2ZSBhIHNt YWxsIG51bWJlciBvZiBDRSBtYXJrcyBldmVyeSBjb3VwbGUgb2YgUlRUcywgYW5kIHRoZSBjb3Vu dGVyIG9ubHkgY2hhbmdlcyBpZiB5b3UgQ0UgbWFya3MvdGhlIG9wdGlvbiBpcyBvbmx5IHByZXNl bnQgYSBmZXcgdGltZXMgcGVyIFJUVC4gU28gdGhlIGltcGFjdCBzaG91bGQgYmUgcmF0aGVyIGxv dy4gQnV0IHRoaXMgY2xlYXIgc29tZXRoaW5nIHRvIGV2YWx1YXRlIGZvciB0aGUgZXhwZXJpbWVu dC4NCg0KPiANCj4gRXZlbiB3aXRob3V0IG9wdGlvbiwgQUNFIGhlYWRlciBvbmx5IGFsbG93cyBy ZWZsZWN0aW5nIHVwIHRvIDggcGFja2V0cyANCj4gZm9yIHJlY2VpdmVyIHNlZ21lbnRhdGlvbiBv ZmZsb2FkIGFuZCBBQ0sgc3VwcHJlc3Npb24/DQoNClNhbWUgYXMgYWJvdmUsIGl0IGNhbiBvbmx5 IHVwIHRvIDggQ0UgbWFya2VkIHBhY2tldHMgcGVyIEFDSywgaG93ZXZlciwgQ0UgbWFya2luZyBy YXRlciBhcmUgZXhwZWN0ZWQgdG8gYmUgcmF0aGVyIGxvdy4gQUNLIHN1cHByZXNzaW9uIHNob3Vs ZCBwcm9iYWJseSBub3QgYmUgdXNlZCBpZiB0aGUgQUNFIGNvdW50ZXIgaGFzIGNoYW5nZXMsIGhv d2V2ZXIsIHVzdWFsbHkgdGhlIEFDRSBjb3VudGVyIHN0YXlzIHN0YWJsZSBmb3IgbXVsdGlwbGUg UlRUcyBhbmQgdGhlbiBBQ0sgc3VwcHJlc3Npb24gaXMgbm90IGEgcHJvYmxlbS4gSG93ZXZlciwg bm90IHN1cmUgSSB1bmRlcnN0b29kIHlvdSBxdWVzdGlvbiBoZXJlIGNvcnJlY3RseeKApj8NCg0K PiANCj4gVGhlIGFwcGVuZGl4IG9uIGFjayBsb3NzIGNhdXNlcyBhbWJpZ3VpdHkgaXMgZ29vZDog YnV0IHRoZSBwYXR0ZXJuIA0KPiBkcm9wcyBzcGVjaWZpY2FsbHkgdGhlIHN0YXRlLXN3aXRjaCAo Q0U8LT5ub0NFKSBBQ0sgd2hpY2ggb25seSBoYXBwZW5zIA0KPiBvbiBkZWxheWVkIEFDSy4gSXMg dGhhdCBwYXR0ZXJuIGNvbW1vbj8gLSBvciBjYW4gd2UgYWRkcmVzcyBtb3N0IG9mIA0KPiB0aGF0 IGJ5IGRlbGF5aW5nIGxlc3MgQUNLcz8NCg0KSSBndWVzcyB5b3UgaGF2ZSBhIDUwJSBjaGFuY2Ug dG9kYXkgdG8gaGl0IGEgZGVsYXllZCBBQ0suIEkgZ3Vlc3MgZGVsYXlpbmcgbGVzcyAod2hlcmUg eW91IGRlbGF5IGV2ZXJ5IHNlY29uZCBBQ0sgdG9kYXkpIHdvdWxkIG1lYW4gQUNLIHZlcnkgcGFj a2V0LCBhbmQgdGh1cyBkb3VibGUgQUNLIGxvYWQgb24gdGhlIG5ldHdvcmsuIEkgZ3Vlc3Mgb24g dG9kYXkgbmV0d29ya3MgdGhhdCBhY3R1YWxseSBpbiBtb3N0IGNhc2VzIG5vdCBhIHByb2JsZW0s IGhvd2V2ZXIsIHRoZXJlIG1pZ2h0IGJlIHNwZWNpYWxseSBjYXNlcyB3aGVyZSBpdCBpcy4gSG93 ZXZlciwgdGhhdOKAmXMgcHJvYmxlbSBhbiBpbmRlcGVuZGVudCBxdWVzdGlvbiB0byBldmFsdWF0 ZS4NCg0KPiANCj4gSSBhbSBhbGwgZm9yIG1ha2luZyBFQ04gbW9yZSBhY2N1cmF0ZSBmb3Igd2lk ZSBhcmVhIGJleW9uZCBEQ1RDUCwgYnV0IA0KPiBhbSBldmFsdWF0aW5nIHRoZSBwcm9zL2NvbnMu IFdoYXQgaWYgd2UganVzdCAxLiBuZWdvdGlhdGUgJ2JldHRlcicgRUNOIA0KPiB2aWEgbmV3IFNZ TiBvcHRpb24NCg0KTm90IHN1cmUgSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgY29ycmVjdGx5 LCBidXQgSSBhc3N1bWUgeW91IG1lYW4gbmVnb3RpYXRlIHZpYSBTWU4gb3B0aW9uIGFuZCB0aGVu IGp1c3QgdXNlIHRoZSBBQ0UgY291bnRlciBpbiB0aGUgaGVhZGVyPyBJZiBzbywgSSBkb27igJl0 IHVuZGVyc3RhbmQgd2h5IHlvdSBzZWUgdGhlIG5lZ290aWF0aW9uIHBhcnQgaW4gdGhlIFRDUCBo ZWFkZXIgYXMgdGhlIHByb2JsZW0/DQoNCj4gMi4gbWFyayBhbGwgcGFja2V0cyBsaWtlIEVDTisr DQoNClRoYXQgd291bGQgYmUgbmljZSBidXQgaGVyZSB5b3UgYWN0dWFsbHkgbmVlZCBBY2NFQ04g YmVjYXVzZSB5b3Ugd2FudCB0byBoYXZlIGZlZWRiYWNrIGZvciBjb250cm9sIHBhY2tldHMgYXMg d2VsbC4gQWNjRUNOIGlzIHByb3ZpZGluZyB0aGlzIGZlZWRiYWNrLiBBY2NFQ04gZG9lcyBub3Qg Y2hhbmdlIHRoZSDigJ51c2Ugb2YgRUNO4oCcOyB0aGF04oCZcyB3aGF0IHdlIGhhdmUgRUNOKysg Zm9yOyBib3RoIHRoaW5nIGlkZWFsbHkgd291bGQgYmUgZGVwbG95ZWQgdG9nZXRoZXIgaG93ZXZl ci4gV2FzIHRoYXQgeW91ciBxdWVzdGlvbnM/DQoNCk1pcmphDQoNCg0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiBPbiBUaHUsIEp1bCAxMiwgMjAxOCBhdCAzOjIzIEFNLCBNaXJqYSBLw7xobGV3 aW5kIA0KPiA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4gd3JvdGU6DQo+PiBIaSBZ dWNodW5nLA0KPj4gDQo+PiB0aGUgcXVlc3Rpb24gaWYgeW91IG5lZWQgdGhpcyDigJ5tb3Jl4oCc IG9uIGFjY3VyYWN5IHJlYWxseSBkZXBlbmRzIG9uIHRoZSB1c2UgY2FzZS4gSWYgeW91IHVzZSBE Q1RDUCBhcyB0b2RheSwgdGhlIEFDRSBjb3VudGVyIGluIHRoZSBUQ1AgaXMgcHJvYmFibHkgc3Vm ZmljaWVudCBhbmQgeW91IG1pZ2h0IG5vdCB3YW50IHRvIHBheSB0aGUgYWRkaXRpb25hbCBvdmVy aGVhZCBpbiB5b3VyIGRhdGEgY2VudGVyICh0aGF0IHdoeSB0aGUgb3B0aW9uIGlzIGFjdHVhbGx5 IG9wdGlvbmFsKS4NCj4+IA0KPj4gSWYgeW91IGhvd2V2ZXIsIGUuZy4sIGhhdmUgdmVyeSBkaWZm ZXJlbnRseSBzaXplZCBwYWNrZXRzLCB0aGVuIHRoZSBieXRlIGNvdW50ZXIgaW4gdGhlIG9wdGlv biBjb3VsZCBnaXZlIHlvdSBhIG1vcmUgYWNjdXJhdGUgc2lnbmFsLiBPciBpZiB5b3UgYXJlIGFs c28gaW50ZXJlc3RlZCBpbiB0aGUgRUNUKDEpIGNvdW50ZXIsIHlvdSBuZWVkIHRoZSBvcHRpb24u IEZ1cnRoZXIgdGhlIEFDRSBjb3VudGVyIGFsc28gZ2l2ZSB5b3VyIGZlZWRiYWNrIG9uIGNvbnRy b2wgcGFja2V0IGFuZCB0aGUgb3B0aW9uIGVuYWJsZXMgeW91IHRvIGRpc3Rpbmd1aXNoIGJldHdl ZW4gQ0UtYW1ya2VkIHBheWxvYWQgYW5kIGNvbnRyb2wgcGFja2V0cywgd2hpY2ggY2FuIGFsc28g YmVjb21lIGltcG9ydGFudCB3aGVuIGV4cGVyaW1lbnRpbmcgd2l0aCBtYWtpbmcgYWxsIHBhY2tl dHMgRUNOLWNhcGFibGUuDQo+PiANCj4+IEdpdmVuIGFjY0VDTiBpcyBhIGdlbmVyYWwgZmVlZGJh Y2sgbWVjaGFuaXNtIHRoYXQgaW4gZmFjdCBpcyBkZXNpZ25lZCB0byBlbmFibGUgbmV3IGZ1dHVy ZSB1c2VzIG9mIHRoZSBFQ04gc2lnbmFsLCB3ZSB3YW50ZWQgdG8ga2VlcCBhbGwgdGhlc2Ugb3B0 aW9uIGF2YWlsYWJsZSB3aGlsZSBtYWtpbmcgaXMgc3RpbGwgYXMgc2ltcGxlIGFzIHBvc3NpYmxl IGFuZCBhcyBmbGV4aWJsZSBhcyBwb3NzaWJsZS4NCj4+IA0KPj4gTWlyamENCj4+IA0KPj4gDQo+ PiANCj4+PiBBbSAxMS4wNy4yMDE4IHVtIDE0OjM1IHNjaHJpZWIgWXVjaHVuZyBDaGVuZyA8eWNo ZW5nQGdvb2dsZS5jb20+Og0KPj4+IA0KPj4+IEhpIEJvYiwNCj4+PiANCj4+PiBOZWFsIGFuZCBJ IGV2YWx1YXRlZCB0aGUgZWFybGllciBkcmFmdC4gSXQgaXMgd2VsbC10aG91Z2h0IG91dCBidXQg DQo+Pj4gd2UncmUgY29uY2VybmVkIGFib3V0IHRoZSBvcHRpb25zLiBPcHRpb24gaXMgbm90IG1h bmRhdG9yeSBidXQgdGhlIA0KPj4+IGxhY2sgb2YgaXQgYWxzbyByZWR1Y2VzIGFjY3VyYWN5LiBP cHRpb24gcnVucyBpbnRvIHNwYWNlIGlzc3VlcyB3LyANCj4+PiBTQUNLIGFuZCBvZmZsb2FkIGlz c3VlcyB3LyBUU08vR1JPLiBUaGV5IGNhbiBiZSBhZGRyZXNzZWQgZm9yIHN1cmUgDQo+Pj4gYnV0 IGFyZW4ndCBlYXN5Lg0KPj4+IA0KPj4+IFdlJ3JlIGN1cmlvdXMgaG93IG11Y2ggbW9yZSAiYWNj dXJhY3kiIGl0IGJ1eXMgb3ZlciBjdXJyZW50IA0KPj4+IERDVENQLXN0eWxlIEVDTi4gSXMgdGhl cmUgYW55IHN0dWR5IHRvIHNob3cgdHJhZGUtb2ZmcyBvZiANCj4+PiBmdWxsLUFDRS13LW9wdGlv bnMgdnMgQUNFLXdvLW9wdGlvbnMgdnMgY3VycmVudCBEQ1RDUC1FQ04/DQo+Pj4gDQo+Pj4gDQo+ Pj4gT24gV2VkLCBKdWwgMTEsIDIwMTggYXQgMTE6MDAgQU0sIEJvYiBCcmlzY29lIDxpZXRmQGJv YmJyaXNjb2UubmV0PiB3cm90ZToNCj4+Pj4gTWljaGFlbCwgdGNwbSBsaXN0LA0KPj4+PiANCj4+ Pj4gQXMgd2VsbCBhcyBhZGRyZXNzaW5nIHlvdXIgcG9pbnRzLCBhcyBNaXJqYSBoYXMgYWxyZWFk eSBtZW50aW9uZWQgDQo+Pj4+IGJlbG93LCB3ZSBhZGRlZCBhIHdob2xlIG5ldyBhcHBlbmRpeCBn aXZpbmcgdGhlIHJhdGlvbmFsZSBmb3IgdGhlIA0KPj4+PiBiaXRzIGFuZCBjb2RlcG9pbnRzIHRo YXQgQWNjRUNOIGhhcyBwcm9wb3NlZCB0byB1c2Ugb24gMSkgdGhlIFNZTiANCj4+Pj4gYW5kIDIp IFNZTi9BQ0suIEEgM3JkIHN1YnNlY3Rpb24gYWxzbyBpZGVudGlmaWVzIHNwYWNlIGZvciBmdXR1 cmUgDQo+Pj4+IGV2b2x1dGlvbi4gSXQgYWxzbyBwb2ludHMgdG8gd2hlcmUgcmF0aW9uYWxlIHdh cyBhbHJlYWR5IGdpdmVuIGluIHRoZSBib2R5IG9mIHRoZSBkcmFmdC4NCj4+Pj4gDQo+Pj4+IFRo ZSBhcHBlbmRpeCBpcyBpbiB0aGUgZHJhZnQgc3VibWl0dGVkIGxhc3Qgd2VlaywgYXZhaWxhYmxl IGhlcmU6DQo+Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdG8NCj4+Pj4gb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0 LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDclMjNhcHBlbmRpeC1CJg0KPj4+PiBhbXA7ZGF0YT0w MiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMmU0OTgwZjkxZDg5NDEwZmE1ODcwOGQ1 DQo+Pj4+IGU4MTExZmJiJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNjY3MDA4MjYxMDQNCj4+Pj4gNTM2MjAmYW1wO3NkYXRhPUo1cXdyWjhIJTJCYmZyaVRG MWp4SlhabGRYNiUyQkEwVXklMkZUVjBsR2RIMlViV1klMw0KPj4+PiBEJmFtcDtyZXNlcnZlZD0w DQo+Pj4+IA0KPj4+PiBXZSdkIGJlIGludGVyZXN0ZWQgdG8gaGVhciB3aGV0aGVyIHRoaXMgYWxs YXlzIHlvdXIgY29uY2VybnMuDQo+Pj4+IA0KPj4+PiBXZSBoYXZlIGFza2VkIHRvIHByZXNlbnQg dGhpcyBpbiBNb250cmVhbCBhcyB3ZWxsLg0KPj4+PiANCj4+Pj4gQ2hlZXJzDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gQm9iDQo+Pj4+IA0KPj4+PiANCj4+Pj4gT24gMDIvMDcvMTggMTY6NTQsIE1pcmph IEvDvGhsZXdpbmQgd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpIE1pY2hlYWwsDQo+Pj4+PiANCj4+ Pj4+IEkgYWRkcmVzc2VkIGEgY291cGxlIG9mIHlvdXIgY29tbWVudHMgYmVsb3cuDQo+Pj4+PiAN Cj4+Pj4+IEZvciB0aGUgb3RoZXIsIGJpZ2dlciBjb21tZW50cyByZWdhcmRpbmcgZXh0ZW5zaWJp bGl0eSwgdGhhdCBJIGRpZCANCj4+Pj4+IG5vdCB5ZXQgYWRkcmVzcyBiZWxvdywgd2UgcGxhbiB0 byBhZGQgYSBuZXcgc2VjdGlvbiB0byB0aGUgDQo+Pj4+PiBhcHBlbmRpeCB0byBleHBsYWluIGV4 dGVuc2liaWxpdHkgb3B0aW9ucyBhcyBwcmV2aW91c2x5IGRpc2N1c3NlZCANCj4+Pj4+IGJ5IG1h aWwuIFdlIHdpbGwgcHJvYmFibHkgc2VuZCBhIHNlcGFyYXRlIGVtYWlsIG9uIHRoYXQgcGFydC4N Cj4+Pj4+IA0KPj4+Pj4gTWlyamENCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gQW0gMTIuMDMuMjAx OCB1bSAwMTo1OSBzY2hyaWViIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSANCj4+Pj4+PiBERS9T dHV0dGdhcnQpDQo+Pj4+Pj4gPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT46DQo+Pj4+Pj4gDQo+ Pj4+Pj4gSGkgTWlyamEsDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhhbmtzIGEgbG90IGZvciB0aGUgZXhw bGFuYXRpb24uIEkgd29uJ3QgZm9sbG93LXVwIG9uIHNvbWUgb2YgDQo+Pj4+Pj4gdGhlIGVkaXRv cmlhbCBzdWdnZXN0aW9ucy4NCj4+Pj4+PiANCj4+Pj4+PiBZZXQsIEkgY29udGludWUgdG8gYmVs aWV2ZSB0aGF0IHNvbWUgZm9ybWFsIHdvcmRpbmcgaW4gdGhlIA0KPj4+Pj4+IGRvY3VtZW50IG5l ZWRzIHRvIGNoYW5nZSwgYXMgZXhwbGFpbmVkIGJlbG93Lg0KPj4+Pj4+IA0KPj4+Pj4+IFRoYW5r cw0KPj4+Pj4+IA0KPj4+Pj4+IE1pY2hhZWwgKHdpdGggbm8gaGF0IG9uKQ0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBN aXJqYSBLw7xobGV3aW5kIFttYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaF0N Cj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBNYXJjaCAwNSwgMjAxOCAxOjU0IFBNDQo+Pj4+Pj4+IFRv OiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSANCj4+Pj4+Pj4gPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT4NCj4+Pj4+Pj4gQ2M6IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0 ZS1lY25AaWV0Zi5vcmc7IHRjcG1AaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUmU6IENvbW1l bnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEhp IE1pY2hlYWwsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiB0aGFua3MgZm9yIHlvdXIgZmVlZGJhY2sgYW5k IHNvcnJ5IGZvciBteSBsYXRlIHJlcGx5Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gUGxlYXNlIHNlZSBp bmxpbmUuDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQW0gMDMuMTIuMjAxNyB1bSAyMDoxNyBzY2hyaWVi IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSANCj4+Pj4+Pj4+IERFL1N0dXR0Z2FydCkNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+Og0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBIaSBhbGwsDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEkgaGF2ZSByZWFkIGRyYWZ0LWlldGYt dGNwbS1hY2N1cmF0ZS1lY24tMDUgKHdpdGhvdXQgdGhlIA0KPj4+Pj4+Pj4gYXBwZW5kaXgpLiBJ DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgbmVlZHMgZnVydGhlciB3 b3JrIGJlZm9yZSBtb3ZpbmcgZm9yd2FyZC4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gUGxlYXNlIGZp bmQgYmVsb3cgbXkgY29tbWVudHMgbWFya2VkIGFzIFttc10uIEkgaGF2ZSByZWFkIHRoZQ0KPj4+ Pj4+PiANCj4+Pj4+Pj4gZG9jdW1lbnQgaW5kZXBlbmRlbnQgb2YgdGhlIHJldmlldyBmcm9tIEdv cnJ5LiBJIGFwb2xvZ2l6ZSBpZiANCj4+Pj4+Pj4gdGhlcmUgaXMgZHVwbGljYXRpb24uDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IFRoYW5rcw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBNaWNoYWVsICh3aXRo IG5vIGhhdCBvbikNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gKiBBYnN0cmFjdDoNCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gIFJlY2VudGx5LCBuZXcgVENQIG1lY2hhbmlzbXMgbGlrZSBDb25nZXN0 aW9uIEV4cG9zdXJlIChDb25FeCkgDQo+Pj4+Pj4+PiBvciBEYXRhDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBDZW50ZXIgVENQDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAoRENUQ1ApIG5lZWQgbW9yZSBhY2N1 cmF0ZSBFQ04gZmVlZGJhY2sgaW5mb3JtYXRpb24gd2hlbmV2ZXIgDQo+Pj4+Pj4+PiBtb3JlICB0 aGFuIG9uZSBtYXJraW5nIGlzIHJlY2VpdmVkIGluIG9uZSBSVFQuDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IFttc10gSSBkb24ndCB0aGluayB0aGlzIHN0YXRlbWVudCBpcyBmdWxseSBiYWNrZWQgYnkg UkZDIDgyNTcuIA0KPj4+Pj4+Pj4gSSBzdWdnZXN0IHRvDQo+Pj4+Pj4+IA0KPj4+Pj4+PiByZW1v dmUgdGhpcywgb3IgcmVwbGFjZSBpdCBieSBhIG1vcmUgZ2VuZXJpYyBzdGF0ZW1lbnQgdGhhdCBt b3JlIA0KPj4+Pj4+PiBhY2N1cmF0ZSBpbmZvcm1hdGlvbiBjYW4gYmUgdXNlZnVsIGZvciBzZXZl cmFsIFRDUCBleHRlbnNpb25zLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSBkaXNhZ3JlZS4gQm90aCBD b25FeCBhbmQgRENUQ1AgbmVlZCBtb3JlIGFjY3VyYXRlIGluZm9ybWF0aW9uLiANCj4+Pj4+Pj4g VGhleSBkbyBub3QgbmVlZCB0aGUgbWVjaGFuaXNtIHRoYXQgaXMgc3BlY2lmaWVkIGluIHRoaXMg ZHJhZnQsIA0KPj4+Pj4+PiBob3dldmVyLCB0aGlzIGlzIG5vdCB3aGF0IHRoZSBzZW50ZW5jZXMg aXMgc2F5aW5nLg0KPj4+Pj4+IA0KPj4+Pj4+IEluIG15IHVuZGVyc3RhbmRpbmcgKGFzIGEgbm9u LW5hdGl2ZSBzcGVha2VyKSwgdGhlIHVzZSBvZiB0aGUgd29yZCAibmVlZCINCj4+Pj4+PiBpcyBu b3QgY29ycmVjdCBoZXJlLiBEQ1RDUCBhcyBzcGVjaWZpZWQgaW4gUkZDIDgyNTcgY2FuIGJlIA0K Pj4+Pj4+IGltcGxlbWVudGVkIHdpdGhvdXQgYW55IHN1Y2ggbWVjaGFuaXNtLg0KPj4+Pj4+IA0K Pj4+Pj4+IFdoYXQgd291bGQgd29yayBmb3IgbWUgaXMgc29tZXRoaW5nIG9mIHRoZSBmb3JtICIu Li4gRGF0YSBDZW50ZXIgDQo+Pj4+Pj4gVENQIGNhbm5vdCBnZXQgcHJlY2lzZSBFQ04gZmVlZGJh Y2sgd2hlbmV2ZXIgbW9yZSB0aGFuIG9uZSANCj4+Pj4+PiBtYXJraW5nIGlzIHJlY2VpdmVkIGlu IG9uZSBSVFTigJwuDQo+Pj4+PiANCj4+Pj4+IFRoaXMgaXMgbm90IGNvcnJlY3QuIERDVFAgbmVl ZCBtb3JlIHRoYW4gb25lIGZlZWRiYWNrIHNpZ25hbCBwZXIgDQo+Pj4+PiBSVFQgYW5kIHRoZXJl Zm9yZSBjYW5ub3QgdXNlIFJGQzMxNjg7IGluc3RlYWQgaXQgaW1wbGVtZW50IGl04oCZcyANCj4+ Pj4+IG93biBmZWVkYmFjayBtZWNoYW5pc20uIEhvd2V2ZXIsIHRvIGF2b2lkIGNvbmZ1c2lvbiBz dWNoIHRoYXQgDQo+Pj4+PiBwZW9wbGUgY291bGQgYXNzdW1lIERDVFAgd291bGQgbm90IHdvcmsg d2l0aG91dCB0aGUgYWNjRUNOIHNjaGVtZSANCj4+Pj4+IGFzIHNwZWNpZmllZCBpbiB0aGlzIGRv YywgSSByZXBocmFzZWQgdG86DQo+Pj4+PiANCj4+Pj4+ICJSZWNlbnRseSwgcHJvcG9zZWQNCj4+ Pj4+ICAgICAgbWVjaGFuaXNtcyBsaWtlIENvbmdlc3Rpb24gRXhwb3N1cmUgKENvbkV4IDx4cmVm IA0KPj4+Pj4gdGFyZ2V0PSJSRkM3NzEzIi8+KSwNCj4+Pj4+ICAgICAgRENUQ1AgPHhyZWYgdGFy Z2V0PSJSRkM4MjU3Ii8+IG9yIEw0UyA8eHJlZg0KPj4+Pj4gICAgICB0YXJnZXQ9IkktRC5pZXRm LXRzdndnLWw0cy1hcmNoIi8+IG5lZWQgdG8ga25vdyB3aGVuIG1vcmUgdGhhbiBvbmUNCj4+Pj4+ ICAgICAgbWFya2luZyBpcyByZWNlaXZlZCBpbiBvbmUgUlRUIHdoaWNoIGlzDQo+Pj4+PiAgICAg IGluZm9ybWF0aW9uIHRoYXQgY2Fubm90IGJlIHByb3ZpZGVkIGJ5IHRoZSBmZWVkYmFjayBzY2hl bWUgYXMgDQo+Pj4+PiBzcGVjaWZpZWQgaW4NCj4+Pj4+ICAgICAgPHhyZWYgdGFyZ2V0PSJSRkMz MTY4Ii8+LiINCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4+PiAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgYW4NCj4+Pj4+Pj4+ICBleHBlcmltZW50YWwgc2NoZW1lIHRvIHByb3ZpZGUgbW9yZSB0aGFu IG9uZSBmZWVkYmFjayBzaWduYWwgDQo+Pj4+Pj4+PiBwZXIgUlRUICBpbiB0aGUgVENQIGhlYWRl ci4gIEdpdmVuIFRDUCBoZWFkZXIgc3BhY2UgaXMgc2NhcmNlLCANCj4+Pj4+Pj4+IGl0IG92ZXJs b2FkcyAgdGhlIHRocmVlIGV4aXN0aW5nIEVDTi1yZWxhdGVkIGZsYWdzIGluIHRoZSBUQ1AgDQo+ Pj4+Pj4+PiBoZWFkZXIgYW5kIHByb3ZpZGVzICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIGEg bmV3IFRDUCBvcHRpb24uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFttc10gVGhpcyBzdGF0ZW1lbnQg bmVlZHMgdG8gYmUgcmV3cml0dGVuIHRvIGNvcnJlY3RseSByZWZsZWN0IA0KPj4+Pj4+Pj4gd2hh dCBpcw0KPj4+Pj4+PiANCj4+Pj4+Pj4gcmVxdWVzdGVkIGZyb20gSUFOQS4gTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHRoaXMgZXhwZXJpbWVudGFsIA0KPj4+Pj4+PiBkb2N1bWVudCBhc2tzIGZv ciBhbGxvY2F0aW9uIG9mIGEgcmVzZXJ2ZWQgVENQIGhlYWRlciBmbGFnLiBUaGlzIA0KPj4+Pj4+ PiBuZWVkcyB0byBiZSBjYWxsZWQgb3V0IHByb21pbmVudGx5LCBJTUhPLiBJbiBhZGRpdGlvbiwg c2luY2UgDQo+Pj4+Pj4+IHRoaXMgaXMgbm90IGEgc3RhbmRhcmQsIHRoZSBzdWdnZXN0ZWQgZXhw ZXJpbWVudGF0aW9uIHdpdGggdGhlIA0KPj4+Pj4+PiBtYWluIFRDUCBoZWFkZXIgbXVzdCBJTUhP IGJlIGV4cGxpY2l0bHkgbWVudGlvbmVkLiBJIGFsc28gDQo+Pj4+Pj4+IHN1Z2dlc3QgdG8gaGF2 ZSBsYXRlciBpbiBhIGRvY3VtZW50IGEgc2VjdGlvbiB0aGF0IGV4cGxpY2l0bHkgDQo+Pj4+Pj4+ IGV4cGxhaW5zIHdoeSBpdCBpcyBhcHByb3ByaWF0ZSB0byBtb2RpZnkgdGhlIG1haW4gVENQIGhl YWRlciBpbiANCj4+Pj4+Pj4gYW4gZXhwZXJpbWVudC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgZG9u 4oCZdCBrbm93IGlmIGFueSByZXF1aXJlbWVudCB0aGF0IElBTkEgYXNzaWdubWVudCBuZWVkIHRv IGJlIA0KPj4+Pj4+PiBjYWxsZWQgb3V0IGluIHRoZSBhYnN0cmFjdCBidXQgd2UgY2FuIGRvIHRo YXQuIEhvd2V2ZXIsIEkgDQo+Pj4+Pj4+IGJlbGlldmUgdGhlIHF1ZXN0aW9uIGlmIHRoaXMgZG9j dW1lbnQgc2hvdWxkIG9yIHNob3VsZCBub3QgDQo+Pj4+Pj4+IGFzc2lnbiB0aGUgYml0IGlzIHN0 aWxsIG5vdCBjb21wbGV0ZWx5IHNvbHZlZCwgb3IgaXMgaXQ/DQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBi ZWxpZXZlIHRoaXMgcXVlc3Rpb24gd2lsbCBoYXZlIHRvIGJlIHJldmlld2VkIGR1cmluZyBXR0xD IGFuZCwgDQo+Pj4+Pj4gbW9yZSBpbXBvcnRhbnRseSwgSUVURiBsYXN0IGNhbGwuIEZvciB0aGUg bW9tZW50LCBteSBjb25jZXJuIGlzIA0KPj4+Pj4+IHRoYXQgdGhlIGRvY3VtZW50IGNvcnJlY3Rs eSBkZXNjcmliZXMgdGhlIElBTkEgYWxsb2NhdGlvbi4NCj4+Pj4+PiANCj4+Pj4+PiBJIHdvdWxk IGxpa2UgdG8gc2VlIGhlcmUgYSBzdGF0ZW1lbnQgc3VjaCBhcyA6ICJHaXZlbiBUQ1AgaGVhZGVy IA0KPj4+Pj4+IHNwYWNlIGlzIHNjYXJjZSwgdGhpcyBzcGVjaWZpY2F0aW9uIGFsbG9jYXRlcyBh IHJlc2VydmVkIGhlYWRlciANCj4+Pj4+PiBiaXQgYW5kIG92ZXJsb2FkcyB0aGUgdHdvIEVDTiBm bGFncyBpbiB0aGUgVENQIGhlYWRlciAuLi7igJwuDQo+Pj4+PiANCj4+Pj4+IEEgYml0IGxlbmd0 aHkgYnV0IG5vdzoNCj4+Pj4+IA0KPj4+Pj4gIkdpdmVuIFRDUCBoZWFkZXIgc3BhY2UgaXMNCj4+ Pj4+ICAgICAgc2NhcmNlLCBpdCBhbGxvY2F0ZXMgYSByZXNlcnZlZCBoZWFkZXIgYml0LCB0aGF0 IHdhcyANCj4+Pj4+IHByZXZpb3VzbHkgdXNlZCBmb3INCj4+Pj4+ICAgICAgRUNOLU5vbmNlIHdo aWNoIHdhcyByZWNlbnRseSBkZWNsYXJlZCBoaXN0b3JpYywgYW5kIG92ZXJsb2FkcyB0aGUNCj4+ Pj4+ICAgICAgdHdvIGV4aXN0aW5nIEVDTiBmbGFncyBpbiB0aGUgVENQIGhlYWRlci4gRnVydGhl ciwgYWRkaXRpb25hbA0KPj4+Pj4gICAgICBpbmZvcm1hdGlvbiBjYW4gYmUgcHJvdmlkZWQgaW4g YSBuZXcgVENQIG9wdGlvbiB0aGF0IGhvd2V2ZXIgDQo+Pj4+PiBpcyBub3QgdXNlZA0KPj4+Pj4g ICAgICBvbiB0aGUgVENQIFNZTi4iDQo+Pj4+PiANCj4+Pj4+Pj4+ICogMS4gIEludHJvZHVjdGlv bg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgUmVjZW50bHksIHByb3Bvc2VkIG1lY2hhbmlzbXMgbGlr ZSBDb25nZXN0aW9uIEV4cG9zdXJlIChDb25FeCAgDQo+Pj4+Pj4+PiBbUkZDNzcxM10pLCBEQ1RD UCBbUkZDODI1N10gb3IgTDRTIFtJLUQuaWV0Zi10c3Z3Zy1sNHMtYXJjaF0gDQo+Pj4+Pj4+PiBu ZWVkICBtb3JlIGFjY3VyYXRlIEVDTiBmZWVkYmFjayBpbmZvcm1hdGlvbiB3aGVuZXZlciBtb3Jl IHRoYW4gDQo+Pj4+Pj4+PiBvbmUNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IG1hcmtpbmcNCj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4gIGlzIHJlY2VpdmVkIGluIG9uZSBSVFQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IFttc10gQXQgbGVhc3QgZm9yIFJGQyA4MjU3IHNlZW1zIHRvIGJlIGltcGxlbWVudGFibGUgd2l0 aG9pdCB0aGlzLg0KPj4+Pj4+Pj4gSW5zdGVhZA0KPj4+Pj4+PiANCj4+Pj4+Pj4gb2Ygc3RhdGlu ZyBhICJuZWVkIiwgaXQgd291bGQgSU1ITyBtYWtlIG1vcmUgc2Vuc2UgdG8gZGlzY3VzcyANCj4+ Pj4+Pj4gdGhlIGJlbmVmaXRzIG9mIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtIGluIHRoaXMgZG9j dW1lbnQgb2YgaXRzIA0KPj4+Pj4+PiBvd24sIGluZGVwZW5kZW50IG9mIG90aGVyIHByb3Bvc2Fs cy4gVG8gbWUsIHRoaXMgZG9jdW1lbnQgc2hvdWxkIA0KPj4+Pj4+PiBiZSBpbmRlcGVuZGVudCBv ZiBvdGhlciBkb2N1bWVudHMgYW5kIHNwZWNpZmljYWxseSBvdGhlciANCj4+Pj4+Pj4gZXhwZXJp bWVudHMuIFdlIGhhdmUgdG8gdGhpbmsgYWJvdXQgY2FzZXMgd2hlcmUgbm90IGFsbCANCj4+Pj4+ Pj4gZXhwZXJpbWVudHMgYXJlIHN1Y2Nlc3NmdWwuIFRoZW4gaW5kZXBlbmRlbnQgZG9jdW1lbnRz IHdpbGwgYmUgDQo+Pj4+Pj4+IG1vcmUgZnV0dXJlLXByb29mIGluIGZ1dHVyZS4NCj4+Pj4+Pj4g DQo+Pj4+Pj4+IFRoaXMgaXMgYSBuYW1pbmcgY29sbGlzaW9u4oCmIFRoZSBzZW50ZW5jZSB3YXMg bWVhbnQgdG8gc2F5IHRoYXQgDQo+Pj4+Pj4+IHRoZXNlIG1lY2hhbmlzbXMgbmV3IG1vcmUgYWNj dXJhdGUgRUNOIGZlZWRiYWNrIHRoYW4gcHJvdmlkZWQgDQo+Pj4+Pj4+IHRvZGF5IGJ5DQo+Pj4+ Pj4+IFJGQzMxNjggYnV0IGl0IHdhcyBub3QgbWVhbnQgdG8gc2F5IHRoYXQgdGhlc2UgbWVjaGFu aXNtIGhhdmUgdG8gDQo+Pj4+Pj4+IHVzZSB0aGUgc2NoZW1lIGFzIHNwZWNpZmllZCBpbiB0aGlz IGRvY3VtZW50Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSBhZGRlZCB0aGUgZm9sbG93aW5nIHBhcnQg c2VudGVuY2U6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiDigJ5SZWNlbnRseSwgcHJvcG9zZWQgbWVjaGFu aXNtcyBsaWtlIENvbmdlc3Rpb24gRXhwb3N1cmUgKENvbkV4IA0KPj4+Pj4+PiBbUkZDNzcxM10p LCBEQ1RDUCBbUkZDODI1N10gb3IgTDRTIFtJLUQuaWV0Zi10c3Z3Zy1sNHMtYXJjaF0gDQo+Pj4+ Pj4+IG5lZWQgbW9yZSBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sgaW5mb3JtYXRpb24gdGhhbiBwcm92 aWRlZCBieSB0aGUgDQo+Pj4+Pj4+IGZlZWRiYWNrIHNjaGVtZSBhcyBzcGVjaWZpZWQgaW4gW1JG QzMxNjhdIHdoZW5ldmVyIG1vcmUgdGhhbiBvbmUgDQo+Pj4+Pj4+IG1hcmtpbmcgaXMgcmVjZWl2 ZWQgaW4gb25lIFJUVC4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gDQo+Pj4+Pj4+IGFsdGVy bmF0aXZlIGZlZWRiYWNrIHNjaGVtZSB0aGF0IHByb3ZpZGVzIG1vcmUgYWNjdXJhdGUgDQo+Pj4+ Pj4+IGluZm9ybWF0aW9uIGFuZCBjb3VsZCBiZSB1c2VkIGJ5IHRoZXNlIG5ldyBUQ1AgZXh0ZW5z aW9ucy7igJwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IERvZXMgdGhpcyBoZWxwPw0KPj4+Pj4+IA0KPj4+ Pj4+IFNlZSBteSBwcm9wb3NhbCBmb3IgdGhlIGFic3RyYWN0LiBJIGNvbnRpbnVlIHRvIGRpc2Fn cmVlIHdpdGggdGhlIA0KPj4+Pj4+IHRlcm0gIm5lZWQiIGJ1dCBJIHRoaW5rIHRoaXMgY2FuIGJl IHNvcnRlZCBvdXQgYnkgYW5vdGhlciB0ZXJtLg0KPj4+Pj4+IA0KPj4+Pj4+Pj4gIElmIEFjY0VD TiBwcm9ncmVzc2VzIGZyb20gZXhwZXJpbWVudGFsIHRvIHRoZSBzdGFuZGFyZHMgIA0KPj4+Pj4+ Pj4gdHJhY2ssIGl0IGlzIGludGVuZGVkIHRvIGJlIGEgY29tcGxldGUgcmVwbGFjZW1lbnQgZm9y IGNsYXNzaWMgDQo+Pj4+Pj4+PiBUQ1AvICBFQ04gZmVlZGJhY2ssIG5vdCBhIGZvcmsgaW4gdGhl IGRlc2lnbiBvZiBUQ1AuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFttc10gVGhpcyBzZW50ZW5jZSBz aG91bGQgYmUgcmVtb3ZlZCwgYXMgdGhpcyBpcyBzcGVjdWxhdGlvbi4NCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IFdoeT8gSXQgc3RhdGVzIGFuIGludGVudOKApiBhbmQgdGhhdOKAmXMgdGhlIGludGVudCB0 aGF0IHdlIGhhdmUuDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gIFVudGlsIHRoZSBBY2NFQ04gZXhwZXJp bWVudCBzdWNjZWVkcywgW1JGQzMxNjhdIHdpbGwgcmVtYWluIGFzIA0KPj4+Pj4+Pj4gdGhlICBz dGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBmb3IgYWRkaW5nIEVDTiB0byBUQ1AuDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IFttc10gVGhpcyBzZW50ZW5jZSBzaG91bGQgYmUgcmVtb3ZlZCAob3Ig cmV3b3JkZWQpDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBXaHk/IERvZXMgaXQgaGVscCB0byBhZGQgYW4g b25seSBoZXJlOg0KPj4+Pj4+PiANCj4+Pj4+Pj4gIlVudGlsIHRoZSBBY2NFQ04gZXhwZXJpbWVu dCBzdWNjZWVkcywgW1JGQzMxNjhdIHdpbGwgcmVtYWluIGFzIA0KPj4+Pj4+PiB0aGUgb25seSBz dGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBmb3IgYWRkaW5nIEVDTiB0byBUQ1Au4oCcDQo+ Pj4+Pj4gDQo+Pj4+Pj4gVGhpcyB3b3JkaW5nIGlzIGJldHRlci4NCj4+Pj4+PiANCj4+Pj4+Pj4+ ICBBY2NFQ04gZmVlZGJhY2sgb3ZlcmxvYWRzIGZsYWdzIGFuZCBmaWVsZHMgaW4gdGhlIG1haW4g VENQIA0KPj4+Pj4+Pj4gaGVhZGVyICB3aXRoIG5ldyBkZWZpbml0aW9ucywgc28gYm90aCBlbmRz IGhhdmUgdG8gc3VwcG9ydCB0aGUgDQo+Pj4+Pj4+PiBuZXcgd2lyZSAgcHJvdG9jb2wgYmVmb3Jl IGl0IGNhbiBiZSB1c2VkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBbbXNdIEluIG15IHJlYWRpbmcg dGhpcyBleHBlcmltZW50YWwgZG9jdW1lbnQgYXNrcyBmb3IgKm5ldyogDQo+Pj4+Pj4+PiBhbGxv Y2F0aW9uDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBvZiBhIHJlc2VydmVkIFRDUCBoZWFkZXIgZmxhZy4N Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IElzIHRoaXMgYmV0dGVyPw0KPj4+Pj4+PiANCj4+Pj4+Pj4gIkFj Y0VDTiBmZWVkYmFjayBvdmVybG9hZHMgdGhlIHR3byBleGlzdGluZyBFQ04gZmxhZ3MgYXMgd2Vs bCBhcyB0aGUNCj4+Pj4+Pj4gICAgIGN1cnJlbnRseSByZXNlcnZlZCBhbmQgcHJldmlvdXNseSBj YWxsZWQgTlMgZmxhZyBpbiB0aGUgbWFpbiANCj4+Pj4+Pj4gVENQIGhlYWRlcg0KPj4+Pj4+PiAg ICAgd2l0aCBuZXcgZGVmaW5pdGlvbnMsIHNvIGJvdGggZW5kcyBoYXZlIHRvIHN1cHBvcnQgdGhl IG5ldyANCj4+Pj4+Pj4gd2lyZSBwcm90b2NvbA0KPj4+Pj4+PiAgICAgYmVmb3JlIGl0IGNhbiBi ZSB1c2VkLuKAnA0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgeW91IGFyZSBu b3QgaGFwcHkgd2l0aCB0aGUgd29yZCDigJ5vdmVybG9hZOKAnCANCj4+Pj4+Pj4gaGVyZSBidXQg dGhlIHBvaW50IG9mIHRoaXMgc2VudGVuY2UgcmVhbGx5IGlzIHRoYXQgdGhlIGZsYWdzIA0KPj4+ Pj4+PiBjYW4vY291bGQgYmUgdXNlZCBkaWZmZXJlbnRseSBhbmQgdGhlcmVmb3JlIHdlIG5lZWQg YSBuZXcgDQo+Pj4+Pj4+IG5lZ290aWF0aW9uIGJlZm9yZSB3ZSBjYW4gdXNlIHRoZW0uDQo+Pj4+ Pj4gDQo+Pj4+Pj4gRm9yIG1lIHRoZSBmb2xsb3dpbmcgd291bGQgd29yazogIkFjY0VDTiBmZWVk YmFjayBvdmVybG9hZHMgdGhlIA0KPj4+Pj4+IHR3byBleGlzdGluZyBFQ04gZmxhZ3MgYW5kIGFs bG9jYXRlcyB0aGUgY3VycmVudGx5IHJlc2VydmVkIGFuZCANCj4+Pj4+PiBwcmV2aW91c2x5IGNh bGxlZCBOUyBmbGFnIGluIHRoZSBtYWluIFRDUCBoZWFkZXIuDQo+Pj4+Pj4gR2l2ZW4gdGhlIG5l dyBkZWZpbml0aW9ucywgYm90aCBlbmRzIGhhdmUgdG8gc3VwcG9ydCB0aGUgbmV3IHdpcmUgDQo+ Pj4+Pj4gcHJvdG9jb2wgYmVmb3JlIGl0IGNhbiBiZSB1c2VkLiINCj4+Pj4+PiANCj4+Pj4+PiBJ IGJlbGlldmUgdGhlIHdvcmRpbmcgaGFzIHRvIGJlIGNyeXN0YWwgY2xlYXIgb24gdGhlIHJlc2Vy dmF0aW9uIA0KPj4+Pj4+IG9mIGJpdCA3IHdoZW4gaXQgaXMgZGlzY3Vzc2VkIHRoZSBmaXJzdCB0 aW1lIGluIHRoZSB0ZXh0LiBJbiANCj4+Pj4+PiBmb2xsb3ctdXAgc2VjdGlvbnMsIG1heWJlIHNo b3J0ZXIgdGVybXMgY291bGQgYmUgdXNlZC4NCj4+Pj4+IA0KPj4+Pj4gT2theSwgbm93Og0KPj4+ Pj4gDQo+Pj4+PiAiQWNjRUNOIGZlZWRiYWNrIG92ZXJsb2FkcyB0aGUgdHdvIGV4aXN0aW5nIEVD TiBmbGFncyBhbmQNCj4+Pj4+ICAgIGFsbG9jYXRlcyB0aGUgY3VycmVudGx5IHJlc2VydmVkIGFu ZCBwcmV2aW91c2x5IGNhbGxlZCBOUyBmbGFnIGluIHRoZQ0KPj4+Pj4gICAgVENQIGhlYWRlciwg dG8gYmUgdXNlZCBhcyBvbmUgZmllbGQgaW5kaWNhdGluZyB0aGUgbnVtYmVyIG9mIA0KPj4+Pj4g Y29uZ2VzdGlvbg0KPj4+Pj4gICAgZXhwZXJpZW5jZWQgbWFya2VkIHBhY2tldHMuIEdpdmVuIHRo ZSBuZXcgZGVmaW5pdGlvbnMgb2YgdGhlc2UgDQo+Pj4+PiB0aHJlZSBiaXRzLA0KPj4+Pj4gICAg Ym90aCBlbmRzICAgICBoYXZlIHRvIHN1cHBvcnQgdGhlIG5ldyB3aXJlIHByb3RvY29sIGJlZm9y ZSBpdCBjYW4gYmUNCj4+Pj4+IHVzZWQuDQo+Pj4+PiAgICBUaGVyZWZvcmUgZHVyaW5nIHRoZSBU Q1AgaGFuZHNoYWtlIHRoZSB0d28gZW5kcyB1c2UgdGhlc2UgdGhyZWUgDQo+Pj4+PiBiaXQgaW4N Cj4+Pj4+ICAgIHRoZSBUQ1AgaGVhZGVyIHRvIG5lZ290aWF0ZSB0aGUgbW9zdCBhZHZhbmNlZCBm ZWVkYmFjayBwcm90b2NvbA0KPj4+Pj4gICAgdGhhdCB0aGV5IGNhbiBib3RoIHN1cHBvcnQgaW4g YSBiYWNrd2FyZCBjb21wYXRpYmxlIHdheSB0bw0KPj4+Pj4gICAgPHhyZWYgdGFyZ2V0PSJSRkMz MTY4Ii8+LiINCj4+Pj4+Pj4gDQo+Pj4+Pj4+IElmIHlvdSBwcmVmZXIsIHdlIGNhbiBhbHNvIHJl bW92ZSB0aGUgTlMgZmxhZyBpbiB0aGlzIGxpc3QsIGFzIA0KPj4+Pj4+PiBFQ04gTm9uY2Ugd2Fz IGFueXdheSBuZXZlciBkZXBsb3llZC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgRm9yIHRoYXQgd2Ug cmVmZXIgdG8gW1JGQzMxNjhdIG9yIGFueSBSRkMgdGhhdCAgc3BlY2lmaWVzIGEgDQo+Pj4+Pj4+ PiBkaWZmZXJlbnQgcmVzcG9uc2UgdG8gVENQIEVDTiBmZWVkYmFjaywgZm9yIGV4YW1wbGU6DQo+ Pj4+Pj4+PiAgW1JGQzgyNTddOyBvciB0aGUgRUNOIGV4cGVyaW1lbnRzIHJlZmVycmVkIHRvIGlu ICANCj4+Pj4+Pj4+IFtJLUQuaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uXSwgbmFtZWx5 OiBhIFRDUC1iYXNlZCBMb3cgDQo+Pj4+Pj4+PiBMYXRlbmN5ICBMb3cgTG9zcyBTY2FsYWJsZSAo TDRTKSBjb25nZXN0aW9uIGNvbnRyb2wgDQo+Pj4+Pj4+PiBbSS1ELmlldGYtdHN2d2ctbDRzLWFy Y2hdOyAgRUNOLWNhcGFibGUgVENQIGNvbnRyb2wgcGFja2V0cyANCj4+Pj4+Pj4+IFtJLUQuaWV0 Zi10Y3BtLWdlbmVyYWxpemVkLWVjbl0sIG9yICBBbHRlcm5hdGl2ZSBCYWNrb2ZmIHdpdGggDQo+ Pj4+Pj4+PiBFQ04gKEFCRSkgIFtJLUQuaWV0Zi10Y3BtLWFsdGVybmF0aXZlYmFja29mZi1lY25d Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBbbXNdIEF0IGxlYXN0IEFCRSBzZWVtcyBvcnRob2dvbmFs LiBBbnl3YXksIEkgdGhpbmsgdGhpcyANCj4+Pj4+Pj4+IHBhcmFncmFwaCBjYW4ganVzdA0KPj4+ Pj4+PiANCj4+Pj4+Pj4gYmUgZGVsZXRlZC4gSWYgb3RoZXIgZXhwZXJpbWVudHMgbmVlZCBtb3Jl IGFjY3VyYXRlIGZlZWRiYWNrLCBpdCANCj4+Pj4+Pj4gaXMgdXAgdG8gdGhlbSB0byBleHBsYWlu IGhvdyB0aGV5IHdvdWxkIHVzZSB0aGlzIG1lY2hhbmlzbS4gVGhpcyANCj4+Pj4+Pj4gZG9jdW1l bnQgc2hvdWxkIGZvY3VzIG9uIGhvdyB0byBzaWduYWwgdGhlIGZlZWRiYWNrLCBub3QgaG93IHRv IA0KPj4+Pj4+PiB1c2UgdGhhdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFllcywgdGhhdCBpcyB3aGF0 IHRoZSBwYXJhZ3JhcGggc2F5cy4gSXNu4oCZdCBpdCBiZXR0ZXIgdG8gYmUgDQo+Pj4+Pj4+IGV4 cGxpY2l0IGFib3V0IHRoaXM/DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gIEl0IGlzIGxpa2VseSAoYnV0 IG5vdCByZXF1aXJlZCkgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIHdpbGwgDQo+Pj4+Pj4+PiBi ZSAgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aCB0aGUgZm9sbG93aW5nIGV4cGVyaW1lbnRhbCBhZGRp dGlvbnMgDQo+Pj4+Pj4+PiB0byB0aGUgIFRDUC1FQ04gcHJvdG9jb2w6IEVDTi1jYXBhYmxlIFRD UCBjb250cm9sIHBhY2tldHMgYW5kIA0KPj4+Pj4+Pj4gcmV0cmFuc21pc3Npb25zICBbSS1ELmll dGYtdGNwbS1nZW5lcmFsaXplZC1lY25dLCB3aGljaCANCj4+Pj4+Pj4+IGluY2x1ZGVzIHRoZSBF Q04tY2FwYWJsZSBTWU4vICBBQ0sgZXhwZXJpbWVudCBbUkZDNTU2Ml07IGFuZCANCj4+Pj4+Pj4+ IHRlc3RpbmcgcmVjZWl2ZXIgbm9uLWNvbXBsaWFuY2UgIA0KPj4+Pj4+Pj4gW0ktRC5tb25jYXN0 ZXItdGNwbS1yY3YtY2hlYXRdLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBbbXNdIEkgYW0gYSBiaWcg ZmFuIG9mIHNpbXBsZSwgc3RhbmRhbG9uZSBkb2N1bWVudHMuIEluIG15IA0KPj4+Pj4+Pj4gdmll dywgdGhlIFRDUE0NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IHdvcmtpbmcgZ3JvdXAgc2hvdWxkIHB1Ymxp c2ggZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbiBhbmQNCj4+Pj4+Pj4gZHJhZnQtaWV0Zi0N Cj4+Pj4+Pj4gdGNwbS1nZW5lcmFsaXplZC1lY24gaW5kZXBlbmRlbnQgZG9jdW1lbnRzLCB3aGlj aCBwcm9iYWJseSANCj4+Pj4+Pj4gaW1wbGllcyB0aGF0IGRyYWZ0LWlldGYtdGNwbS1nZW5lcmFs aXplZC1lY24gZG9lcyBub3QgdXNlIA0KPj4+Pj4+PiBBY2NFQ04uIElmIGV4cGVyaW1lbnRhdGlv biB3aXRoIEVDVCBpbiBTWU4gcmVxdWlyZXMgYSANCj4+Pj4+Pj4gY29tYmluYXRpb24sIHRoaXMg Y291bGQgYmUgZG9uZSBpbiBhIG5ldywgdGhpcmQgZG9jdW1lbnQuIEFwYXJ0IA0KPj4+Pj4+PiBm cm9tIGhhdmluZyBzaW1wbGVyIGZvY3VzZWQgZG9jdW1lbnRzLCB0aGlzIGNvdWxkIHNpZ25pZmlj YW50bHkgDQo+Pj4+Pj4+IGhlbHAgbGF0ZXIgd2l0aCBtb3ZpbmcgZm9yd2FyZCBkb2N1bWVudHMg dG8gc3RhbmRhcmRzIHRyYWNrLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSBkaXNhZ3JlZSwgaG93ZXZl ciwgdGhpcyBpcyBhIGRpc2N1c3Npb24gdG8gaGF2ZSBvbiANCj4+Pj4+Pj4gZHJhZnQtaWV0Zi10 Y3BtLSBnZW5lcmFsaXplZC1lY24uIEkgZG9u4oCZdCBzZWUgYSBwcm9ibGVtIGluICANCj4+Pj4+ Pj4gcHJvdmlkaW5nIGEgcmVmZXJlbmNlIGhlcmUgdGhhdCBzYXlzIOKAnml0IGlzIGxpa2VseeKA puKAnCBhbmQgbm90aGluZyANCj4+Pj4+Pj4gbW9yZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+ICogMS4xLiAgRG9jdW1lbnQgUm9hZG1hcA0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiBbbXNdIEEgbWFjcm9zY29waWMgY29tbWVudCBpcyB0aGF0IHRoaXMgZG9jdW1lbnQg aGFzIGEgbG90IG9mIA0KPj4+Pj4+Pj4gaW50cm9kdWN0aW9uDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBh bmQgdHV0b3JpYWwgdGV4dCB3aXRoIGxvdCdzIG9mIHJlZHVuZGFuY3kgdG93YXJkcyBvdGhlciAN Cj4+Pj4+Pj4gZG9jdW1lbnRzLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBjYW4gYmUgbWFkZSBtdWNo IGVhc2llciB0byByZWFkIA0KPj4+Pj4+PiBieSBzaG9ydGVuIGl0LiBJbiBtYW55IGNhc2VzIHRo aXMgaXMganVzdCBhbiBlZGl0b3JpYWwgY2hhbmdlIGFzIA0KPj4+Pj4+PiB0aGVyZSBpcyByZWR1 bmRhbmN5LiBBcyBvbmUgc3VjaCBleGFtcGxlLCBqdXN0IHJlbW92ZSB0aGlzIA0KPj4+Pj4+PiBz ZWN0aW9uLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSBndWVzcyB0aGlzIGEgbWF0dGVyIG9mIHRhc3Rl LiBBcyBhbiBBRCwgSeKAmW0gYSBiaWcgZmFuIG9mIHNob3J0IA0KPj4+Pj4+PiBhbmQgY29uY2lz ZSBkb2N1bWVudHMsIGhvd2V2ZXIsIHNvbWUgcmVkdW5kYW5jeSBjYW4gYWxzbyBoZWxwIA0KPj4+ Pj4+PiB1bmRlcnN0YW5kaW5nLCBlc3BlY2lhbGx5IGlmIHlvdSBleHBsYWluIHRoaW5ncyBtdWx0 aXBsZSB0aW1lcyANCj4+Pj4+Pj4gYnV0IHdpdGggYSBkaWZmZXJlbnQgbGV2ZWwgb2YgZGV0YWls LiBJIHBlcnNvbmFsbHkgd291bGQgbm90IA0KPj4+Pj4+PiBuZWVkIHRoZSByb2FkbWFwIGJ1dCBJ IGtub3cgbWFueSBwZW9wbGUgd2hvIGZpbmQgdGhlc2UgdGhpbmdzIA0KPj4+Pj4+PiBoZWxwZnVs IGFuZCB0byBiZSBob25lc3QgSSBkb27igJl0IHNlZSBob3cgcmVtb3ZpbmcgdGhpcyBwYXJ0IA0K Pj4+Pj4+PiBtYWtlcyB0aGUgZG9jIGFueSBiZXR0ZXIuIElmIHlvdSBkb27igJl0IHdhbnQgaXQs IGRvbuKAmXQgcmVhZCBpdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICogMS4yLiAg R29hbHMNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gW21zXSBJIHRoaW5rIHRoaXMgc2VjdGlvbiBjYW4g YWxzbyBqdXN0IGJlIHJlbW92ZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJIGhhdmUgdG8gc2F5IEkg YWxzbyBkb27igJl0IHNlZSB0aGUgcG9pbnQgb2YgcmVtb3ZpbmcgdGhpcyBwYXJ0LiBHaXZlbg0K Pj4+Pj4+PiB3ZeKAmXZlDQo+Pj4+Pj4+IGRvbmUgdGhlIHdvcmsgb24gcmVxdWlyZW1lbnRzLCBJ IHRoaW5rIHdlIHNob3VsZCBhbHNvIGxpbmsgdG8gdGhpcyBkb2MNCj4+Pj4+Pj4gc29tZXdoZXJl Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICogMS4zLiAgRXhwZXJpbWVudCBHb2Fs cw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgVENQIGlzIGNyaXRpY2FsIHRvIHRoZSByb2J1c3QgZnVu Y3Rpb25pbmcgb2YgdGhlIEludGVybmV0LCB0aGVyZWZvcmUNCj4+Pj4+Pj4+ICBhbnkgcHJvcG9z ZWQgbW9kaWZpY2F0aW9ucyB0byBUQ1AgbmVlZCB0byBiZSB0aG9yb3VnaGx5IHRlc3RlZC4gVGhl DQo+Pj4+Pj4+PiAgcHJlc2VudCBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyBhbiBleHBlcmltZW50 YWwgcHJvdG9jb2wgdGhhdCBhZGRzDQo+Pj4+Pj4+PiAgbW9yZSBhY2N1cmF0ZSBFQ04gZmVlZGJh Y2sgdG8gdGhlIFRDUCBwcm90b2NvbC4gIFRoZSBpbnRlbnRpb24gaXMgdG8NCj4+Pj4+Pj4+ICBz cGVjaWZ5IHRoZSBwcm90b2NvbCBzdWZmaWNpZW50bHkgc28gdGhhdCBtb3JlIHRoYW4gb25lDQo+ Pj4+Pj4+PiAgaW1wbGVtZW50YXRpb24gY2FuIGJlIGJ1aWx0IGluIG9yZGVyIHRvIHRlc3QgaXRz IGZ1bmN0aW9uLA0KPj4+Pj4+Pj4gcm9idXN0bmVzcw0KPj4+Pj4+Pj4gIGFuZCBpbnRlcm9wZXJh YmlsaXR5ICh3aXRoIGl0c2VsZiBhbmQgd2l0aCBwcmV2aW91cyB2ZXJzaW9uIG9mIEVDTg0KPj4+ Pj4+Pj4gIGFuZCBUQ1ApLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBbbXNdIEkgdGhpbmsgYWxsIHdo YXQgaXMgd3JpdHRlbiBpbiB0aGlzIHBhcmFncmFwaCBpcyBvYnZpb3VzLCBubz8NCj4+Pj4+Pj4+ IENhbid0IHdlIGp1c3QNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IGRlbGV0ZSB0aGlzPw0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gU3VyZSwgaG93ZXZlciwgSSBkb27igJl0IHRoaW5rIGl0IGh1cnRzIHRvIHNwZWxs IGl0IG91dC4gRm9yIG1lIGJvdGggaXMNCj4+Pj4+Pj4gZmluZSwga2VlcCBpdA0KPj4+Pj4+PiBv ciByZW1vdmUgaXQuDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gIFRoZSBleHBlcmltZW50YWwgcHJvdG9j b2wgd2lsbCBiZSBjb25zaWRlcmVkIHN1Y2Nlc3NmdWwgaWYgaXQgaXMNCj4+Pj4+Pj4+ICBkZXBs b3llZCBhbmQgaWYgaXQgc2F0aXNmaWVzIHRoZSByZXF1aXJlbWVudHMgb2YgW1JGQzc1NjBdIGlu IHRoZQ0KPj4+Pj4+Pj4gIGNvbnNlbnN1cyBvcGluaW9uIG9mIHRoZSBJRVRGIHRjcG0gd29ya2lu ZyBncm91cC4gIEluIHNob3J0LCB0aGlzDQo+Pj4+Pj4+PiAgcmVxdWlyZXMgdGhhdCBpdCBpbXBy b3ZlcyB0aGUgYWNjdXJhY3kgYW5kIHRpbWVsaW5lc3Mgb2YgVENQJ3MgRUNODQo+Pj4+Pj4+PiAg ZmVlZGJhY2ssIGFzIGNsYWltZWQgaW4gU2VjdGlvbiA1LCB3aGlsZSBzdHJpa2luZyBhIGJhbGFu Y2UgYmV0d2Vlbg0KPj4+Pj4+Pj4gIHRoZSBjb25mbGljdGluZyByZXF1aXJlbWVudHMgb2YgcmVz aWxpZW5jZSwgaW50ZWdyaXR5IGFuZA0KPj4+Pj4+Pj4gIG1pbmltaXNhdGlvbiBvZiBvdmVyaGVh ZC4gIEl0IGFsc28gcmVxdWlyZXMgdGhhdCBpdCBpcyBub3QgdW5kdWx5DQo+Pj4+Pj4+PiAgY29t cGxleCwgYW5kIHRoYXQgaXQgaXMgY29tcGF0aWJsZSB3aXRoIHByZXZhbGVudCBlcXVpcG1lbnQN Cj4+Pj4+Pj4+ICBiZWhhdmlvdXJzIGluIHRoZSBjdXJyZW50IEludGVybmV0IChlLmcuIGhhcmR3 YXJlIG9mZmxvYWRpbmcgYW5kDQo+Pj4+Pj4+PiAgbWlkZGxlYm94ZXMpLCB3aGV0aGVyIG9yIG5v dCB0aGV5IGNvbXBseSB3aXRoIHN0YW5kYXJkcy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gIFRlc3Rp bmcgd2lsbCBtb3N0bHkgZm9jdXMgb24gZmFsbC1iYWNrIHN0cmF0ZWdpZXMgaW4gY2FzZSBvZg0K Pj4+Pj4+Pj4gIG1pZGRsZWJveCBpbnRlcmZlcmVuY2UuICBDdXJyZW50IHJlY29tbWVuZGVkIHN0 cmF0ZWdpZXMgYXJlDQo+Pj4+Pj4+PiBzcGVjaWZpZWQNCj4+Pj4+Pj4+ICBpbiBTZWN0aW9ucyAz LjEuMiwgMy4yLjMsIDMuMi40IGFuZCAzLjIuNy4gIFRoZSBlZmZlY3RpdmVuZXNzIG9mDQo+Pj4+ Pj4+PiAgdGhlc2Ugc3RyYXRlZ2llcyBkZXBlbmRzIG9uIHRoZSBhY3R1YWwgZGVwbG95bWVudCBz aXR1YXRpb24gb2YNCj4+Pj4+Pj4+ICBtaWRkbGVib3hlcy4gIFRoZXJlZm9yZSBleHBlcmltZW50 YWwgdmVyaWZpY2F0aW9uIHRvIGNvbmZpcm0gbGFyZ2UtDQo+Pj4+Pj4+PiAgc2NhbGUgcGF0aCB0 cmF2ZXJzYWwgaW4gdGhlIEludGVybmV0IGlzIG5lZWRlZCBiZWZvcmUgZmluYWxpemluZw0KPj4+ Pj4+Pj4gdGhpcw0KPj4+Pj4+Pj4gIHNwZWNpZmljYXRpb24gb24gdGhlIFN0YW5kYXJkcyBUcmFj ay4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gW21zXSBUaGVzZSB0d28gcGFyYWdyYXBocyBtdXN0IGJl IGVudGlyZWx5IHJld3JpdHRlbi4gQXMgSSBoYXZlDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBtZW50aW9u ZWQgYmVmb3JlLCBJIGRvbid0IHRoaW5rIGFuIFJGQyBzaG91bGQgc3BlY3VsYXRlIGFib3V0IFRD UE0gYW5kDQo+Pj4+Pj4+IGl0cw0KPj4+Pj4+PiBjb25zZW5zdXMgb3Bpbmlvbi4gSSB3b3VsZCBz dWdnZXN0IGEgd29yZGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IDxtcz4NCj4+Pj4+Pj4+ICBUaGUgZXhwZXJpbWVudGFsIHByb3RvY29sIHdpbGwgYmUgY29uc2lk ZXJlZCBzdWNjZXNzZnVsIGlmDQo+Pj4+Pj4+PiAgdGVzdGluZyBjb25maXJtcyB0aGF0IHRoZSBw cm9wb3NlZCBtZWNoYW5pc20gY2FuIGJlIGRlcGxveWVkIGF0DQo+Pj4+Pj4+PiBsYXJnZQ0KPj4+ Pj4+PiANCj4+Pj4+Pj4gc2NhbGUuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICBUZXN0aW5nIHdpbGwg bW9zdGx5IGZvY3VzIG9uIGZhbGwtYmFjayBzdHJhdGVnaWVzIGluIGNhc2Ugb2YNCj4+Pj4+Pj4+ ICBtaWRkbGVib3ggaW50ZXJmZXJlbmNlLiAgQ3VycmVudCByZWNvbW1lbmRlZCBzdHJhdGVnaWVz IGFyZQ0KPj4+Pj4+Pj4gc3BlY2lmaWVkDQo+Pj4+Pj4+PiAgaW4gU2VjdGlvbnMgMy4xLjIsIDMu Mi4zLCAzLjIuNCBhbmQgMy4yLjcuICBUaGUgZWZmZWN0aXZlbmVzcyBvZg0KPj4+Pj4+Pj4gIHRo ZXNlIHN0cmF0ZWdpZXMgZGVwZW5kcyBvbiB0aGUgYWN0dWFsIGRlcGxveW1lbnQgc2l0dWF0aW9u IG9mDQo+Pj4+Pj4+PiAgbWlkZGxlYm94ZXMuICBUaGVyZWZvcmUgZXhwZXJpbWVudGFsIHZlcmlm aWNhdGlvbiB0byBjb25maXJtIGxhcmdlLQ0KPj4+Pj4+Pj4gIHNjYWxlIHBhdGggdHJhdmVyc2Fs IGluIHRoZSBJbnRlcm5ldCBpcyBuZWVkZWQsIGUuZy4sIGJ5IHN1cHBvcnQgaW4NCj4+Pj4+Pj4+ ICBtYWpvciBUQ1Agc3RhY2tzLg0KPj4+Pj4+Pj4gPC9tcz4NCj4+Pj4+Pj4+IA0KPj4+Pj4+PiBJ IGRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIHBvaW50IGhlcmUuIEkgZG9u4oCZdCB0aGluayB0aGF0 IHRoZSBwYXJhcGhyYXNlDQo+Pj4+Pj4+IHNwZWN1bGF0ZXMgYWJvdXQgdGhlIGNvbnNlbnN1cyBv ZiB0Y3BtLCBpbiBjb250cmFzdCBpdCBzYXkgdGNwbSBoYXMgdG8NCj4+Pj4+Pj4gZGVjaWRlZCBp ZiB0aGUgcmVxdWlyZW1lbnRzIHByZXZpb3VzbHkgc3BlY2lmaWVkIGJ5IHRjcG0gYXJlDQo+Pj4+ Pj4+IHN1ZmZpY2llbnRseQ0KPj4+Pj4+PiBmdWxmaWxsZWQuIEkgZG9u4oCZdCBzZWUgYSByZWFz b24gdG8gbm90IG1lbnRpb24gdGhlIHJlcXVpcmVtZW50IGRyYWZ0IGFzDQo+Pj4+Pj4+IHRoaXMN Cj4+Pj4+Pj4gZHJhZnQgYXMgdGNwbSBjb25zZW5zdXMgYW5kIHdhcyB3cml0dGVuIGZvciB0aGlz IHB1cnBvc2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4gTXkgc3VnZ2VzdGVkIHdvcmRpbmcgdXNlcyB0aGUg ZXhwcmVzc2lvbiAiY2FuIGJlIGRlcGxveWVkIGF0IGxhcmdlIHNjYWxlIg0KPj4+Pj4+IGFuZCBJ IGJlbGlldmUgdGhpcyBpcyByZWxldmFudC4NCj4+Pj4+PiANCj4+Pj4+PiBUaGUgZG9jdW1lbnQg YWxyZWFkeSBkZXNjcmliZXMgaW4gU2VjdGlvbiA1IGhvdyB0aGUgcHJvdG9jb2wgc2F0aXNmaWVz DQo+Pj4+Pj4gdGhlIGFncmVlZCByZXF1aXJlbWVudHMgZm9yIGEgbW9yZSBhY2N1cmF0ZSBFQ04g ZmVlZGJhY2sgcHJvdG9jb2wgW1JGQzc1NjBdLg0KPj4+Pj4+IFNvLCBpZiB0aGUgVENQTSB3b3Jr aW5nIGdyb3VwIHB1Ymxpc2hlcyB0aGlzIGRvY3VtZW50IHdpdGggdGhlIGNvbnRlbnQgb2YNCj4+ Pj4+PiBTZWN0aW9uIDUsIEkgYmVsaWV2ZSB0aGUgVENQTSB3b3JraW5nIGdyb3VwIGFscmVhZHkg aGFzIHJlYWNoZWQgY29uc2Vuc3VzDQo+Pj4+Pj4gdGhhdCB0aGUgcHJvdG9jb2wgbWVldHMgcmVx dWlyZW1lbnRzLiBJbiBhZGRpdGlvbiwgaXQgaXMgcG9zc2libGUgdGhhdCBuZXcNCj4+Pj4+PiBy ZXF1aXJlbWVudHMgd291bGQgYmUgaWRlbnRpZmllZCBpbiBmdXR1cmUsIGUuZy4sIGFzIGFuIG91 dGNvbWUgb2YgdGhlDQo+Pj4+Pj4gZXhwZXJpbWVudCwgYW5kIHRoYXQgd291bGQgb2J2aW91c2x5 IGhhdmUgdG8gYmUgY29uc2lkZXJlZCBieSBUQ1BNLiBJbiB0aGF0DQo+Pj4+Pj4gY2FzZSwgZm9y IHRoZSBzdWNjZXNzIG9mIHRoZSBleHBlcmltZW50IG5vdCBvbmx5IFJGQyA3NTYwIHdvdWxkIG1h dHRlciwgYnV0DQo+Pj4+Pj4gYWxzbyBmdXJ0aGVyIHJlcXVpcmVtZW50cy4gTXkgcHJvcG9zZWQg d29yZGluZyBkb2VzIG5vdCBoYXZlIGFsbCB0aGVzZQ0KPj4+Pj4+IHByb2JsZW1zLg0KPj4+Pj4+ IA0KPj4+Pj4+IEluIGEgbnV0c2hlbGwsIEkgY29udGludWUgdG8gYmVsaWV2ZSB0aGF0IHRoaXMg c2VjdGlvbiBoYXMgdG8gY2hhbmdlLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9rYXksIHVzZWQg eW91ciBwcm9wb3NlZCB3b3JkaW5nLiBZb3UgaGF2ZSBhIHBvaW50IGFib3V0IHRoZSByZXF1aXJl bWVudA0KPj4+Pj4gYW5kIEkgbWlzLXJlYWQgeW91IHByb3Bvc2FsIGVhcmxpZXIgYXMg4oCeaGFz IHRvIGJlIGRlcGxveWVkIGxhcmdlLXNjYWxl4oCcLg0KPj4+Pj4gDQo+Pj4+Pj4+PiAqIDEuNS4g IFJlY2FwIG9mIEV4aXN0aW5nIEVDTiBmZWVkYmFjayBpbiBJUC9UQ1ANCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gW21zXSBUaGlzIHNlY3Rpb24gY291bGQgcHJvYmFibHkgYmUgc2hvcnRlbmVkIGFzIHdl bGwuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICBUaGUgbGFzdCBiaXQgaW4gYnl0ZSAxMyBvZiB0aGUg VENQIGhlYWRlciB3YXMgZGVmaW5lZCBhcyB0aGUgTm9uY2UNCj4+Pj4+Pj4+ICBTdW0gKE5TKSBm b3IgdGhlIEVDTiBOb25jZSBbUkZDMzU0MF0uICBSRkMgMzU0MCB3YXMgbmV2ZXIgZGVwbG95ZWQN Cj4+Pj4+Pj4+IHNvDQo+Pj4+Pj4+PiAgaXQgaXMgYmVpbmcgcmVjbGFzc2lmaWVkIGFzIGhpc3Rv cmljLCBtYWtpbmcgdGhpcyBUQ1AgZmxhZyBhdmFpbGFibGUNCj4+Pj4+Pj4+ICBmb3IgdXNlIGJ5 IHRoZSBBY2NFQ04gZXhwZXJpbWVudCBpbnN0ZWFkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBbbXNd IFRoaXMgd29yZGluZywgYXMgd2VsbCBhcyBGaWd1cmUgMSwgbmVlZHMgdG8gdGFrZSBpbnRvIGFj Y291bnQgdGhlDQo+Pj4+Pj4+PiBJQU5BDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBzdGF0dXMgd2hlbiBk cmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24gaXMgcHVibGlzaGVkLg0KPj4+Pj4+ PiANCj4+Pj4+Pj4gSXMgZG9lcy4gSG93ZXZlciwgSSBjYW4gZXhwbGljaXRseSBzYXkgdGhhdCBp cyBoYXMgYmUgcmUtY2xzc2lmaWVkIGFzDQo+Pj4+Pj4+IHJlc2VydmVkLg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gIlJGQyAzNTQwIHdhcyBuZXZlciBkZXBsb3llZCBzbyBpdCBpcyBiZWluZyByZWNsYXNz aWZpZWQgYXMgaGlzdG9yaWMNCj4+Pj4+Pj4gW0ktRC5pZXRmLQ0KPj4+Pj4+PiB0c3Z3Zy1lY24t ZXhwZXJpbWVudGF0aW9uXSBhbmQgdGhlIHJlc3BlY3RpdmUgZmxhZyBoYXMgYmVlbiBtYXJrZWQg YXMNCj4+Pj4+Pj4g4oCecmVzZXJ2ZWTigJwgaW4gdGhlIElBTkEgVENQIEhlYWRlciBGbGFncyBy ZWdpc3RyeSwgbWFraW5nIHRoaXMgVENQIGZsYWcNCj4+Pj4+Pj4gYXZhaWxhYmxlIGZvciB1c2Ug YnkgdGhlIEFjY0VDTiBleHBlcmltZW50IGluc3RlYWQu4oCcDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBC ZXR0ZXI/DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhpcyBleHBl cmltZW50YWwgZG9jdW1lbnQgYXNrcyBmb3IgbmV3IGFzc2lnbm1lbnQNCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IG9mIGEgcmVzZXJ2ZWQgVENQIGhlYWRlciBmbGFnLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gQXMg SSBzYWlkIEnigJltIG5vdCBzdXJlIGlmIHdlIGhhdmUgZnVsbHkgY29uY2x1ZGVkIHRoaXMgZGlz Y3Vzc2lvbiB5ZXQuDQo+Pj4+Pj4+IEhvd2V2ZXIsDQo+Pj4+Pj4+IHdoYXQgd2UgcmVhbGx5IHdv dWxkIHdhbnQgdG8gaXMgbWVudGlvbiBzb21ld2hlcmUgdGhhdCB0aGlzIGV4cGVyaW1lbnQNCj4+ Pj4+Pj4gd2l0aCB0aGlzIGZsYWdzIGlzIHJ1bm5pbmcuIEkgZ3Vlc3MgdGhlcmUgYXJlIHRocmVl IG9wdGlvbnM6DQo+Pj4+Pj4+IDEpIGtlZXAgaXQgaW4gdGhlIHJlZ2lzdHJ5IGFzIHJlc2VydmVk IGFuZCBjb25zZXJ2ZSB0aGUga25vd2xlZGdlIGluDQo+Pj4+Pj4+IHRjcG0NCj4+Pj4+Pj4gdGhh dCB0aGlzIGV4cGVyaW1lbnQgaXMgcnVubmluZyBhbmQgbm8gb3RoZXIgZXhwZXJpbWVudGFsIFJG QyBzdWNoIHVzZQ0KPj4+Pj4+PiB0aGlzDQo+Pj4+Pj4+IGZsYWdzIGFzIGxvbmcgYXMgdGhpcyBl eHBlcmltZW50IGlzIHJ1bm5pbmcuDQo+Pj4+Pj4+IDIpIEtlZXAgaXMgbWFya2VkIGFzIHJlc2Vy dmVkIGJ1dCBhZGQgYSBub3RlIGFib3V0IHRoaXMgZXhwZXJpbWVudCBpbg0KPj4+Pj4+PiB0aGUN Cj4+Pj4+Pj4gSUFOQSByZWdpc3RyeQ0KPj4+Pj4+PiAzKSBPciBhc3NpZ24gaXQgcmlnaHQgYXdh eSB3aXRoIElFU0cgYXBwcm92YWwuIEkgZ3Vlc3MgaW4gdGhpcyBjYXNlIHRjcG0NCj4+Pj4+Pj4g Y291bGQNCj4+Pj4+Pj4gYWxzbyBjb25zaWRlciB0byBjaGFuZ2UgdGhlIHJlZ2lzdHJhdGlvbiBw b2xpY3kgdG8g4oCeSUVURiBSZXZpZXfigJwuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIGN1cnJlbnQg cmVnaXN0cmF0aW9uIHBvbGljeSBmb3IgdGhlIFRDUCBoZWFkZXIgZmxhZ3MgaXMgInN0YW5kYXJk cw0KPj4+Pj4+IGFjdGlvbiIuIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBJRVNHIGNvdWxkIGFwcHJv dmUgZXhjZXB0aW9ucy4gQnV0IGdpdmVuIHRoZQ0KPj4+Pj4+IHBvbGljeSwgSSBiZWxpZXZlIHRo ZSBkb2N1bWVudCBoYXMgdG8gYmUgdmVyeSBwcmVjaXNlIG9uIHRoZSByZXF1ZXN0DQo+Pj4+Pj4g cmVnYXJkaW5nIGJpdCA3Lg0KPj4+Pj4gDQo+Pj4+PiBPa2F5LCBpdCBub3cgc2F5czoNCj4+Pj4+ IA0KPj4+Pj4gIltUTyBCRSBSRU1PVkVEOiBJQU5BIGlzIHJlcXVlc3RlZCB0byB1cGRhdGUgdGhl IGV4aXN0aW5nIGVudHJ5IGluIHRoZQ0KPj4+Pj4gVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9j b2wgKFRDUCkgSGVhZGVyIEZsYWdzIHJlZ2lzdHJhdGlvbg0KPj4+Pj4gKGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmlh bmEub3JnJTJGYXNzaWdubWVudHMlMkZ0Y3AtaGVhZGVyLWZsYWdzJTJGdGNwLWhlYWRlci1mbGFn cy54aHRtbCUyM3RjcC1oZWFkZXItZmxhZ3MtMSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBt aWNyb3NvZnQuY29tJTdDMmU0OTgwZjkxZDg5NDEwZmE1ODcwOGQ1ZTgxMTFmYmIlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjcwMDgyNjEwNDUzNjIwJmFt cDtzZGF0YT1LWE9GUFElMkZmV1cwZGVrdjUlMkJkWU04c3RiTGw4MGhMdGxKVm5NOXM1RzlsUSUz RCZhbXA7cmVzZXJ2ZWQ9MCkNCj4+Pj4+IGZvciBCaXQgNyB0byAiQUUgKEFjY3VyYXRlIEVDTiks IHByZXZpb3VzbHkgdXNlZCBieSBIaXN0b3JpYyBhcyBOUyAoTm9uY2UNCj4+Pj4+IFN1bSkgW1JG QzM1NDAsIFJGQzgzMTFdIiBhbmQgY2hhbmdlIHRoZSByZWZlcmVuY2UgdG8gdGhpcyBSRkMtdG8t YmUgaW5zdGVhZA0KPj4+Pj4gb2YgUkZDODMxMS5d4oCcDQo+Pj4+PiANCj4+Pj4+IEkgZ3Vlc3Mg d2UgY291bGQgYWxzbyBhc2sgSUFOQSB0byBhZGQgYW4gYWRkaXRpb25hbCBjb21tZW50IGNvbHVt biBpbnN0ZWFkDQo+Pj4+PiAoYnV0IG5vdCBzdXJlIGlmIHdlIHRoZW4gaGF2ZSB0byB1cGRhdGUg UkZDMzE2OCwgd2hpY2ggSSB0aGluayB3ZSByZWFsbHkNCj4+Pj4+IGRvbuKAmXQgd2FudC4gU2hv dWxkIGJlIGZpbmUgbm93Lg0KPj4+Pj4gDQo+Pj4+Pj4+PiAqIDIuICBBY2NFQ04gUHJvdG9jb2wg T3ZlcnZpZXcgYW5kIFJhdGlvbmFsZQ0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgbyAgYW4gZXNzZW50 aWFsIHBhcnQgdGhhdCByZS11c2VzIEVDTiBUQ1AgaGVhZGVyIGJpdHMgdG8gZmVlZCBiYWNrDQo+ Pj4+Pj4+PiAgICAgdGhlIG51bWJlciBvZiBhcnJpdmluZyBDRSBtYXJrZWQgcGFja2V0cy4gIFRo aXMgcHJvdmlkZXMgbW9yZQ0KPj4+Pj4+Pj4gICAgIGFjY3VyYWN5IHRoYW4gY2xhc3NpYyBFQ04g ZmVlZGJhY2ssIGJ1dCBsaW1pdGVkIHJlc2lsaWVuY2UNCj4+Pj4+Pj4+IGFnYWluc3QNCj4+Pj4+ Pj4+ICAgICBBQ0sgbG9zczsNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gW21zXSBUaGUgd29yZCAicmUt dXNlIiBpcyBJTUhPIG5vdCBjb3JyZWN0Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSB0aGluayB0aGlz IGlzIG5pdCBwaWNraW5nLiBVc2luZyBhIGRpZmZlcmVudCBwaHJhc2luZyBoZXJlIG1ha2VzIHRo ZQ0KPj4+Pj4+PiBzZW50ZW5jZQ0KPj4+Pj4+PiB1bm5lY2Vzc2FyeSBjb21wbGljYXRlZC4gV2Ug ZG9u4oCZdCB0cnkgdG8gc29tZSBob3cgZ2V0IGEgcm91bmQgdGhlIGZhY3QNCj4+Pj4+Pj4gdGhh dCB3ZSBuZWVkIHRvIGhhbmRsZSB0aGUgZmxhZyByZWdpc3RyYXRpb24gY29ycmVjdGx5LiBIb3dl dmVyLCBoZXJlDQo+Pj4+Pj4+IHRoZQ0KPj4+Pj4+PiBwb2ludCByZWFsbHkgaXMgdG8gZXhwbGFp biBob3cgdGhlIHByb3RvY29sIHdvcmQuIFRoZSBtYWluIHBvaW50IG9mDQo+Pj4+Pj4+IHVzaW5n IHRoZQ0KPj4+Pj4+PiB3b3JrIOKAnnJlLXVzZeKAnCBoZXJlIGlzIHJlYWxseSB0aGF0IHdlIHNh eSB0aGF0IHRoZXNlIGZsYWdzIGFyZSBvciBoYXZlDQo+Pj4+Pj4+IGJlZW4NCj4+Pj4+Pj4gdXNl ZCBkaWZmZXJlbnQgYnkgb3RoZXIgVENQIGV4dGVuc2lvbiAoYW5kIHdlIHRoZXJlZm9yZSBuZWVk IGEgcHJvcGVyDQo+Pj4+Pj4+IG5lZ290aWF0aW9uIHNjaGVtZSkuDQo+Pj4+Pj4gDQo+Pj4+Pj4g SWYgdGhlIGFsbG9jYXRpb24gb2YgYSByZXNlcnZlZCBmbGFnIGlzIGNvcnJlY3RseSBleHBsYWlu ZWQgaW4gdGhlDQo+Pj4+Pj4gYWJzdHJhY3QgYW5kIGludHJvZHVjdGlvbiwgSSB0aGluayB0aGVz ZSBzZW50ZW5jZXMgY2FuIHVzZSBhIGJpdCByZWxheGVkDQo+Pj4+Pj4gdGVybWlub2xvZ3kuDQo+ Pj4+Pj4gDQo+Pj4+Pj4+PiAgVGhlIHR3byBwYXJ0IGRlc2lnbiB3YXMgbmVjZXNzYXJ5LCBnaXZl biBsaW1pdGF0aW9ucyBvbiB0aGUgc3BhY2UNCj4+Pj4+Pj4+ICBhdmFpbGFibGUgZm9yIFRDUCBv cHRpb25zIGFuZCBnaXZlbiB0aGUgcG9zc2liaWxpdHkgdGhhdCBjZXJ0YWluDQo+Pj4+Pj4+PiAg aW5jb3JyZWN0bHkgZGVzaWduZWQgbWlkZGxlYm94ZXMgcHJldmVudCBUQ1AgdXNpbmcgYW55IG5l dyBvcHRpb25zDQo+PiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnDQpodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p ZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q3By YXZiJTQwbWljcm9zb2Z0LmNvbSU3QzJlNDk4MGY5MWQ4OTQxMGZhNTg3MDhkNWU4MTExZmJiJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY3MDA4MjYxMDQ1 MzYyMCZhbXA7c2RhdGE9QnpMZFczWVRJU0FDRzVwYWtKaHFUR0UlMkJXZzVtUlgzVDUxNFo3d29H Mm9JJTNEJmFtcDtyZXNlcnZlZD0wDQo= From nobody Thu Jul 12 11:16:51 2018 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 709F7130F34; Thu, 12 Jul 2018 11:16:48 -0700 (PDT) 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, 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 3iKPPTF8nC4m; Thu, 12 Jul 2018 11:16:43 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E098B130E48; Thu, 12 Jul 2018 11:16:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41RPK53F5Rz15NQ5; Thu, 12 Jul 2018 20:16:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbPH8CIFcYHX; Thu, 12 Jul 2018 20:16:38 +0200 (CEST) X-MtScore: NO score=0 Received: from [172.20.4.114] (unknown [207.96.227.254]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 12 Jul 2018 20:16:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 12 Jul 2018 14:16:34 -0400 Cc: Yuchung Cheng , "tcpm@ietf.org" , "draft-ietf-tcpm-accurate-ecn@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7C16D47C-3EC2-40CC-AE72-21C2A7BCDFD1@tik.ee.ethz.ch> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 12 Jul 2018 18:16:49 -0000 Hi Praveen, see below. > Am 12.07.2018 um 12:25 schrieb Praveen Balasubramanian = : >=20 > I had similar concerns with the new TCP option at the last tcpm = meeting. I was requesting that we make the option truly optional but I = got some feedback that implementations should honor and process the = option on receive even if they don=E2=80=99t generate it. I'd prefer if = we make the accurate measurements part optional. The biggest advantage = of Accurate ECN is the negotiation mechanism that DCTCP lacks and the = same negotiation can be used on the Internet for any scalable TCP that = wants to rely on accurate ECN. Right, I thought that the outcome of that discussion was that this = actually is covered by the current spec, but to be honest I forgot to = double-check. However, having talked to Yuchung in the mean time (greetings from = NetDev), I now also understand his use case/concerns for DCTCP where you = can actually have a large number of CE marking in a row and with AccECN = you basically need to send an ACK at least every 8 packets in a large = burst of successive EC-marked packet (e.g. if the whole window is CE = marked with can happen with DCTCP). If you want to coalesce more than 8 = ACKs in this case, this would warp the ACE counter in the TCP header, = however, I guess you could then still send an option instead because I = think the spec says that the information in the option should take = precedence over the ACE counter in the TCP header. Also something I = would need to double-check in the spec. I guess it=E2=80=99s a fair point that in that use case AccECN would = actually have a slightly higher overhead than DCTCP today. However, = AccECN was designed to cover a hopefully broad set of future use cases = and is more optimized to Internet-wide use case (with the assumption = that the CE marking rate is usually rather low) and not specifically for = DCTCP only. Still I=E2=80=99m open for concrete proposals to change something but I = guess it would also be nice to wrap this up at some point and actually = start the experimentation (to e.g. find an concrete answer to the = overhead question). >=20 > Re. GRO/LRO/RSC: = https://docs.microsoft.com/en-us/windows-hardware/drivers/network/exceptio= n-conditions-that-terminate-coalescing see condition 4 for an exception = that terminates coalescing: "The segment contains one or more TCP = options other than the TCP timestamp option". So while software = implementations of coalescing can be updated, existing hardware will = cause poor performance with new TCP options that are present in a lot of = data packets.=20 I think this is still fine because you don=E2=80=99t have to send the = TCP option very often. More problematic is actually rule 8 though: " =E2=80=A2 The segment contains ECN flags, as defined in RFC = 3168, that meet one or both of the following criteria: =E2=80=A2 The segment contains a different value for the = ECN field (ECT, CE) in the IP header than the previous segment. =E2=80=A2 The segment has a different value for the ECN = flags (ECE and CWR) in the TCP header than the previous segment.=E2=80=9C I guess that would need to be changed to "if the flags different from = the flags in the previous packet=E2=80=9C.. >=20 >>> because you want to have feedback for control packets as well > I don=E2=80=99t fully understand this. ECN++ allows marking of control = packets and defines a response. Do we really need the TCP option for = processing the feedback? I didn=E2=80=99t meant to say you need the option, actually the AccECN = option does not help you here. But you need the ACE counter in the TCP = header because with classic RFC3168 feedback you don=E2=80=99t get any = feedback about marked control packets. Mirja >=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Mirja = K=C3=BChlewind > Sent: Thursday, July 12, 2018 9:04 AM > To: Yuchung Cheng > Cc: tcpm@ietf.org; draft-ietf-tcpm-accurate-ecn@ietf.org > Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn >=20 > Hi Yuchung, >=20 > please see below. >=20 >> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>=20 >> Yes packets with ACE options and (different) ACE-counter header would=20= >> break GRO. There're many legacy h/w and s/w. >=20 > I=E2=80=99m not the expert here but my understanding is that is would = not break GRO but could not make actual use or it if the ACE counter = changed or the option is present. However, usually your will only have a = small number of CE marks every couple of RTTs, and the counter only = changes if you CE marks/the option is only present a few times per RTT. = So the impact should be rather low. But this clear something to evaluate = for the experiment. >=20 >>=20 >> Even without option, ACE header only allows reflecting up to 8 = packets=20 >> for receiver segmentation offload and ACK suppression? >=20 > Same as above, it can only up to 8 CE marked packets per ACK, however, = CE marking rater are expected to be rather low. ACK suppression should = probably not be used if the ACE counter has changes, however, usually = the ACE counter stays stable for multiple RTTs and then ACK suppression = is not a problem. However, not sure I understood you question here = correctly=E2=80=A6? >=20 >>=20 >> The appendix on ack loss causes ambiguity is good: but the pattern=20 >> drops specifically the state-switch (CE<->noCE) ACK which only = happens=20 >> on delayed ACK. Is that pattern common? - or can we address most of=20= >> that by delaying less ACKs? >=20 > I guess you have a 50% chance today to hit a delayed ACK. I guess = delaying less (where you delay every second ACK today) would mean ACK = very packet, and thus double ACK load on the network. I guess on today = networks that actually in most cases not a problem, however, there might = be specially cases where it is. However, that=E2=80=99s problem an = independent question to evaluate. >=20 >>=20 >> I am all for making ECN more accurate for wide area beyond DCTCP, but=20= >> am evaluating the pros/cons. What if we just 1. negotiate 'better' = ECN=20 >> via new SYN option >=20 > Not sure I understand your proposal correctly, but I assume you mean = negotiate via SYN option and then just use the ACE counter in the = header? If so, I don=E2=80=99t understand why you see the negotiation = part in the TCP header as the problem? >=20 >> 2. mark all packets like ECN++ >=20 > That would be nice but here you actually need AccECN because you want = to have feedback for control packets as well. AccECN is providing this = feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; = that=E2=80=99s what we have ECN++ for; both thing ideally would be = deployed together however. Was that your questions? >=20 > Mirja >=20 >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind=20 >> wrote: >>> Hi Yuchung, >>>=20 >>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy = really depends on the use case. If you use DCTCP as today, the ACE = counter in the TCP is probably sufficient and you might not want to pay = the additional overhead in your data center (that why the option is = actually optional). >>>=20 >>> If you however, e.g., have very differently sized packets, then the = byte counter in the option could give you a more accurate signal. Or if = you are also interested in the ECT(1) counter, you need the option. = Further the ACE counter also give your feedback on control packet and = the option enables you to distinguish between CE-amrked payload and = control packets, which can also become important when experimenting with = making all packets ECN-capable. >>>=20 >>> Given accECN is a general feedback mechanism that in fact is = designed to enable new future uses of the ECN signal, we wanted to keep = all these option available while making is still as simple as possible = and as flexible as possible. >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>>=20 >>>> Hi Bob, >>>>=20 >>>> Neal and I evaluated the earlier draft. It is well-thought out but=20= >>>> we're concerned about the options. Option is not mandatory but the=20= >>>> lack of it also reduces accuracy. Option runs into space issues w/=20= >>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure=20= >>>> but aren't easy. >>>>=20 >>>> We're curious how much more "accuracy" it buys over current=20 >>>> DCTCP-style ECN. Is there any study to show trade-offs of=20 >>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>=20 >>>>=20 >>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe = wrote: >>>>> Michael, tcpm list, >>>>>=20 >>>>> As well as addressing your points, as Mirja has already mentioned=20= >>>>> below, we added a whole new appendix giving the rationale for the=20= >>>>> bits and codepoints that AccECN has proposed to use on 1) the SYN=20= >>>>> and 2) SYN/ACK. A 3rd subsection also identifies space for future=20= >>>>> evolution. It also points to where rationale was already given in = the body of the draft. >>>>>=20 >>>>> The appendix is in the draft submitted last week, available here: >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto >>>>> = ols.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-accurate-ecn-07%23appendix-B& >>>>> = amp;data=3D02%7C01%7Cpravb%40microsoft.com%7C2e4980f91d89410fa58708d5 >>>>> = e8111fbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366700826104 >>>>> = 53620&sdata=3DJ5qwrZ8H%2BbfriTF1jxJXZldX6%2BA0Uy%2FTV0lGdH2UbWY%3 >>>>> D&reserved=3D0 >>>>>=20 >>>>> We'd be interested to hear whether this allays your concerns. >>>>>=20 >>>>> We have asked to present this in Montreal as well. >>>>>=20 >>>>> Cheers >>>>>=20 >>>>>=20 >>>>> Bob >>>>>=20 >>>>>=20 >>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>=20 >>>>>> Hi Micheal, >>>>>>=20 >>>>>> I addressed a couple of your comments below. >>>>>>=20 >>>>>> For the other, bigger comments regarding extensibility, that I = did=20 >>>>>> not yet address below, we plan to add a new section to the=20 >>>>>> appendix to explain extensibility options as previously discussed=20= >>>>>> by mail. We will probably send a separate email on that part. >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia -=20 >>>>>>> DE/Stuttgart) >>>>>>> : >>>>>>>=20 >>>>>>> Hi Mirja, >>>>>>>=20 >>>>>>> Thanks a lot for the explanation. I won't follow-up on some of=20= >>>>>>> the editorial suggestions. >>>>>>>=20 >>>>>>> Yet, I continue to believe that some formal wording in the=20 >>>>>>> document needs to change, as explained below. >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>> Michael (with no hat on) >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Mirja K=C3=BChlewind = [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart)=20 >>>>>>>> >>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>=20 >>>>>>>> Hi Micheal, >>>>>>>>=20 >>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>=20 >>>>>>>> Please see inline. >>>>>>>>=20 >>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia -=20 >>>>>>>>> DE/Stuttgart) >>>>>>>>=20 >>>>>>>> : >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the=20 >>>>>>>>> appendix). I >>>>>>>>=20 >>>>>>>> believe this document needs further work before moving forward. >>>>>>>>>=20 >>>>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>>>>=20 >>>>>>>> document independent of the review from Gorry. I apologize if=20= >>>>>>>> there is duplication. >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>>=20 >>>>>>>>> Michael (with no hat on) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ****************************** >>>>>>>>>=20 >>>>>>>>> * Abstract: >>>>>>>>>=20 >>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx)=20= >>>>>>>>> or Data >>>>>>>>=20 >>>>>>>> Center TCP >>>>>>>>>=20 >>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever=20= >>>>>>>>> more than one marking is received in one RTT. >>>>>>>>>=20 >>>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257.=20= >>>>>>>>> I suggest to >>>>>>>>=20 >>>>>>>> remove this, or replace it by a more generic statement that = more=20 >>>>>>>> accurate information can be useful for several TCP extensions. >>>>>>>>=20 >>>>>>>> I disagree. Both ConEx and DCTCP need more accurate = information.=20 >>>>>>>> They do not need the mechanism that is specified in this draft,=20= >>>>>>>> however, this is not what the sentences is saying. >>>>>>>=20 >>>>>>> In my understanding (as a non-native speaker), the use of the = word "need" >>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be=20 >>>>>>> implemented without any such mechanism. >>>>>>>=20 >>>>>>> What would work for me is something of the form "... Data Center=20= >>>>>>> TCP cannot get precise ECN feedback whenever more than one=20 >>>>>>> marking is received in one RTT=E2=80=9C. >>>>>>=20 >>>>>> This is not correct. DCTP need more than one feedback signal per=20= >>>>>> RTT and therefore cannot use RFC3168; instead it implement it=E2=80= =99s=20 >>>>>> own feedback mechanism. However, to avoid confusion such that=20 >>>>>> people could assume DCTP would not work without the accECN scheme=20= >>>>>> as specified in this doc, I rephrased to: >>>>>>=20 >>>>>> "Recently, proposed >>>>>> mechanisms like Congestion Exposure (ConEx >>>>> target=3D"RFC7713"/>), >>>>>> DCTCP or L4S >>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more = than one >>>>>> marking is received in one RTT which is >>>>>> information that cannot be provided by the feedback scheme as=20= >>>>>> specified in >>>>>> ." >>>>>>=20 >>>>>>=20 >>>>>>>>> This document specifies an >>>>>>>>> experimental scheme to provide more than one feedback signal=20= >>>>>>>>> per RTT in the TCP header. Given TCP header space is scarce,=20= >>>>>>>>> it overloads the three existing ECN-related flags in the TCP=20= >>>>>>>>> header and provides additional information in a new TCP = option. >>>>>>>>>=20 >>>>>>>>> [ms] This statement needs to be rewritten to correctly reflect=20= >>>>>>>>> what is >>>>>>>>=20 >>>>>>>> requested from IANA. My understanding is that this experimental=20= >>>>>>>> document asks for allocation of a reserved TCP header flag. = This=20 >>>>>>>> needs to be called out prominently, IMHO. In addition, since=20 >>>>>>>> this is not a standard, the suggested experimentation with the=20= >>>>>>>> main TCP header must IMHO be explicitly mentioned. I also=20 >>>>>>>> suggest to have later in a document a section that explicitly=20= >>>>>>>> explains why it is appropriate to modify the main TCP header in=20= >>>>>>>> an experiment. >>>>>>>>=20 >>>>>>>> I don=E2=80=99t know if any requirement that IANA assignment = need to be=20 >>>>>>>> called out in the abstract but we can do that. However, I=20 >>>>>>>> believe the question if this document should or should not=20 >>>>>>>> assign the bit is still not completely solved, or is it? >>>>>>>=20 >>>>>>> I believe this question will have to be reviewed during WGLC = and,=20 >>>>>>> more importantly, IETF last call. For the moment, my concern is=20= >>>>>>> that the document correctly describes the IANA allocation. >>>>>>>=20 >>>>>>> I would like to see here a statement such as : "Given TCP header=20= >>>>>>> space is scarce, this specification allocates a reserved header=20= >>>>>>> bit and overloads the two ECN flags in the TCP header ...=E2=80=9C= . >>>>>>=20 >>>>>> A bit lengthy but now: >>>>>>=20 >>>>>> "Given TCP header space is >>>>>> scarce, it allocates a reserved header bit, that was=20 >>>>>> previously used for >>>>>> ECN-Nonce which was recently declared historic, and overloads = the >>>>>> two existing ECN flags in the TCP header. Further, additional >>>>>> information can be provided in a new TCP option that however=20= >>>>>> is not used >>>>>> on the TCP SYN." >>>>>>=20 >>>>>>>>> * 1. Introduction >>>>>>>>>=20 >>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx =20= >>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch]=20= >>>>>>>>> need more accurate ECN feedback information whenever more = than=20 >>>>>>>>> one >>>>>>>>=20 >>>>>>>> marking >>>>>>>>>=20 >>>>>>>>> is received in one RTT. >>>>>>>>>=20 >>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit = this. >>>>>>>>> Instead >>>>>>>>=20 >>>>>>>> of stating a "need", it would IMHO make more sense to discuss=20= >>>>>>>> the benefits of the suggested mechanism in this document of its=20= >>>>>>>> own, independent of other proposals. To me, this document = should=20 >>>>>>>> be independent of other documents and specifically other=20 >>>>>>>> experiments. We have to think about cases where not all=20 >>>>>>>> experiments are successful. Then independent documents will be=20= >>>>>>>> more future-proof in future. >>>>>>>>=20 >>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant to = say that=20 >>>>>>>> these mechanisms new more accurate ECN feedback than provided=20= >>>>>>>> today by >>>>>>>> RFC3168 but it was not meant to say that these mechanism have = to=20 >>>>>>>> use the scheme as specified in this document. >>>>>>>>=20 >>>>>>>> I added the following part sentence: >>>>>>>>=20 >>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure = (ConEx=20 >>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch]=20 >>>>>>>> need more accurate ECN feedback information than provided by = the=20 >>>>>>>> feedback scheme as specified in [RFC3168] whenever more than = one=20 >>>>>>>> marking is received in one RTT. This document specifies an=20 >>>>>>>> alternative feedback scheme that provides more accurate=20 >>>>>>>> information and could be used by these new TCP extensions.=E2=80=9C= >>>>>>>>=20 >>>>>>>> Does this help? >>>>>>>=20 >>>>>>> See my proposal for the abstract. I continue to disagree with = the=20 >>>>>>> term "need" but I think this can be sorted out by another term. >>>>>>>=20 >>>>>>>>> If AccECN progresses from experimental to the standards =20 >>>>>>>>> track, it is intended to be a complete replacement for classic=20= >>>>>>>>> TCP/ ECN feedback, not a fork in the design of TCP. >>>>>>>>>=20 >>>>>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>>>>=20 >>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent = that we have. >>>>>>>>=20 >>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as=20= >>>>>>>>> the standards track specification for adding ECN to TCP. >>>>>>>>>=20 >>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>=20 >>>>>>>> Why? Does it help to add an only here: >>>>>>>>=20 >>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as=20= >>>>>>>> the only standards track specification for adding ECN to = TCP.=E2=80=9C >>>>>>>=20 >>>>>>> This wording is better. >>>>>>>=20 >>>>>>>>> AccECN feedback overloads flags and fields in the main TCP=20 >>>>>>>>> header with new definitions, so both ends have to support the=20= >>>>>>>>> new wire protocol before it can be used. >>>>>>>>>=20 >>>>>>>>> [ms] In my reading this experimental document asks for *new*=20= >>>>>>>>> allocation >>>>>>>>=20 >>>>>>>> of a reserved TCP header flag. >>>>>>>>=20 >>>>>>>> Is this better? >>>>>>>>=20 >>>>>>>> "AccECN feedback overloads the two existing ECN flags as well = as the >>>>>>>> currently reserved and previously called NS flag in the main=20= >>>>>>>> TCP header >>>>>>>> with new definitions, so both ends have to support the new=20= >>>>>>>> wire protocol >>>>>>>> before it can be used.=E2=80=9C >>>>>>>>=20 >>>>>>>> I understand that you are not happy with the word = =E2=80=9Eoverload=E2=80=9C=20 >>>>>>>> here but the point of this sentence really is that the flags=20 >>>>>>>> can/could be used differently and therefore we need a new=20 >>>>>>>> negotiation before we can use them. >>>>>>>=20 >>>>>>> For me the following would work: "AccECN feedback overloads the=20= >>>>>>> two existing ECN flags and allocates the currently reserved and=20= >>>>>>> previously called NS flag in the main TCP header. >>>>>>> Given the new definitions, both ends have to support the new = wire=20 >>>>>>> protocol before it can be used." >>>>>>>=20 >>>>>>> I believe the wording has to be crystal clear on the reservation=20= >>>>>>> of bit 7 when it is discussed the first time in the text. In=20 >>>>>>> follow-up sections, maybe shorter terms could be used. >>>>>>=20 >>>>>> Okay, now: >>>>>>=20 >>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>> allocates the currently reserved and previously called NS flag = in the >>>>>> TCP header, to be used as one field indicating the number of=20 >>>>>> congestion >>>>>> experienced marked packets. Given the new definitions of these=20= >>>>>> three bits, >>>>>> both ends have to support the new wire protocol before it = can be >>>>>> used. >>>>>> Therefore during the TCP handshake the two ends use these three=20= >>>>>> bit in >>>>>> the TCP header to negotiate the most advanced feedback protocol >>>>>> that they can both support in a backward compatible way to >>>>>> ." >>>>>>>>=20 >>>>>>>> If you prefer, we can also remove the NS flag in this list, as=20= >>>>>>>> ECN Nonce was anyway never deployed. >>>>>>>>=20 >>>>>>>>> For that we refer to [RFC3168] or any RFC that specifies a=20 >>>>>>>>> different response to TCP ECN feedback, for example: >>>>>>>>> [RFC8257]; or the ECN experiments referred to in =20 >>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low=20= >>>>>>>>> Latency Low Loss Scalable (L4S) congestion control=20 >>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; ECN-capable TCP control packets=20 >>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], or Alternative Backoff with=20= >>>>>>>>> ECN (ABE) [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>=20 >>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this=20 >>>>>>>>> paragraph can just >>>>>>>>=20 >>>>>>>> be deleted. If other experiments need more accurate feedback, = it=20 >>>>>>>> is up to them to explain how they would use this mechanism. = This=20 >>>>>>>> document should focus on how to signal the feedback, not how to=20= >>>>>>>> use that. >>>>>>>>=20 >>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better = to be=20 >>>>>>>> explicit about this? >>>>>>>>=20 >>>>>>>>> It is likely (but not required) that the AccECN protocol will=20= >>>>>>>>> be implemented along with the following experimental = additions=20 >>>>>>>>> to the TCP-ECN protocol: ECN-capable TCP control packets and=20= >>>>>>>>> retransmissions [I-D.ietf-tcpm-generalized-ecn], which=20 >>>>>>>>> includes the ECN-capable SYN/ ACK experiment [RFC5562]; and=20= >>>>>>>>> testing receiver non-compliance =20 >>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>=20 >>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my=20 >>>>>>>>> view, the TCPM >>>>>>>>=20 >>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>>> draft-ietf- >>>>>>>> tcpm-generalized-ecn independent documents, which probably=20 >>>>>>>> implies that draft-ietf-tcpm-generalized-ecn does not use=20 >>>>>>>> AccECN. If experimentation with ECT in SYN requires a=20 >>>>>>>> combination, this could be done in a new, third document. Apart=20= >>>>>>>> from having simpler focused documents, this could significantly=20= >>>>>>>> help later with moving forward documents to standards track. >>>>>>>>=20 >>>>>>>> I disagree, however, this is a discussion to have on=20 >>>>>>>> draft-ietf-tcpm- generalized-ecn. I don=E2=80=99t see a problem = in =20 >>>>>>>> providing a reference here that says =E2=80=9Eit is = likely=E2=80=A6=E2=80=9C and nothing=20 >>>>>>>> more. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>=20 >>>>>>>>> [ms] A macroscopic comment is that this document has a lot of=20= >>>>>>>>> introduction >>>>>>>>=20 >>>>>>>> and tutorial text with lot's of redundancy towards other=20 >>>>>>>> documents. I think the document can be made much easier to read=20= >>>>>>>> by shorten it. In many cases this is just an editorial change = as=20 >>>>>>>> there is redundancy. As one such example, just remove this=20 >>>>>>>> section. >>>>>>>>=20 >>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan = of short=20 >>>>>>>> and concise documents, however, some redundancy can also help=20= >>>>>>>> understanding, especially if you explain things multiple times=20= >>>>>>>> but with a different level of detail. I personally would not=20 >>>>>>>> need the roadmap but I know many people who find these things=20= >>>>>>>> helpful and to be honest I don=E2=80=99t see how removing this = part=20 >>>>>>>> makes the doc any better. If you don=E2=80=99t want it, don=E2=80= =99t read it. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> * 1.2. Goals >>>>>>>>>=20 >>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>=20 >>>>>>>> I have to say I also don=E2=80=99t see the point of removing = this part. Given >>>>>>>> we=E2=80=99ve >>>>>>>> done the work on requirements, I think we should also link to = this doc >>>>>>>> somewhere. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>=20 >>>>>>>>> TCP is critical to the robust functioning of the Internet, = therefore >>>>>>>>> any proposed modifications to TCP need to be thoroughly = tested. The >>>>>>>>> present specification describes an experimental protocol that = adds >>>>>>>>> more accurate ECN feedback to the TCP protocol. The intention = is to >>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>> implementation can be built in order to test its function, >>>>>>>>> robustness >>>>>>>>> and interoperability (with itself and with previous version of = ECN >>>>>>>>> and TCP). >>>>>>>>>=20 >>>>>>>>> [ms] I think all what is written in this paragraph is obvious, = no? >>>>>>>>> Can't we just >>>>>>>>=20 >>>>>>>> delete this? >>>>>>>>=20 >>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. = For me both is >>>>>>>> fine, keep it >>>>>>>> or remove it. >>>>>>>>=20 >>>>>>>>> The experimental protocol will be considered successful if it = is >>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] in = the >>>>>>>>> consensus opinion of the IETF tcpm working group. In short, = this >>>>>>>>> requires that it improves the accuracy and timeliness of TCP's = ECN >>>>>>>>> feedback, as claimed in Section 5, while striking a balance = between >>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>> minimisation of overhead. It also requires that it is not = unduly >>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>> behaviours in the current Internet (e.g. hardware offloading = and >>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>=20 >>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>> specified >>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>>> middleboxes. Therefore experimental verification to confirm = large- >>>>>>>>> scale path traversal in the Internet is needed before = finalizing >>>>>>>>> this >>>>>>>>> specification on the Standards Track. >>>>>>>>>=20 >>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I = have >>>>>>>>=20 >>>>>>>> mentioned before, I don't think an RFC should speculate about = TCPM and >>>>>>>> its >>>>>>>> consensus opinion. I would suggest a wording along the lines = of: >>>>>>>>>=20 >>>>>>>>> >>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>> testing confirms that the proposed mechanism can be deployed = at >>>>>>>>> large >>>>>>>>=20 >>>>>>>> scale. >>>>>>>>>=20 >>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>> specified >>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>>> middleboxes. Therefore experimental verification to confirm = large- >>>>>>>>> scale path traversal in the Internet is needed, e.g., by = support in >>>>>>>>> major TCP stacks. >>>>>>>>> >>>>>>>>>=20 >>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t = think that the paraphrase >>>>>>>> speculates about the consensus of tcpm, in contrast it say tcpm = has to >>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>> sufficiently >>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the = requirement draft as >>>>>>>> this >>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>=20 >>>>>>> My suggested wording uses the expression "can be deployed at = large scale" >>>>>>> and I believe this is relevant. >>>>>>>=20 >>>>>>> The document already describes in Section 5 how the protocol = satisfies >>>>>>> the agreed requirements for a more accurate ECN feedback = protocol [RFC7560]. >>>>>>> So, if the TCPM working group publishes this document with the = content of >>>>>>> Section 5, I believe the TCPM working group already has reached = consensus >>>>>>> that the protocol meets requirements. In addition, it is = possible that new >>>>>>> requirements would be identified in future, e.g., as an outcome = of the >>>>>>> experiment, and that would obviously have to be considered by = TCPM. In that >>>>>>> case, for the success of the experiment not only RFC 7560 would = matter, but >>>>>>> also further requirements. My proposed wording does not have all = these >>>>>>> problems. >>>>>>>=20 >>>>>>> In a nutshell, I continue to believe that this section has to = change. >>>>>>=20 >>>>>>=20 >>>>>> Okay, used your proposed wording. You have a point about the = requirement >>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be = deployed large-scale=E2=80=9C. >>>>>>=20 >>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>=20 >>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>=20 >>>>>>>>> The last bit in byte 13 of the TCP header was defined as the = Nonce >>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never = deployed >>>>>>>>> so >>>>>>>>> it is being reclassified as historic, making this TCP flag = available >>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>=20 >>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into = account the >>>>>>>>> IANA >>>>>>>>=20 >>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>>>>=20 >>>>>>>> Is does. However, I can explicitly say that is has be = re-clssified as >>>>>>>> reserved. >>>>>>>>=20 >>>>>>>> "RFC 3540 was never deployed so it is being reclassified as = historic >>>>>>>> [I-D.ietf- >>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been = marked as >>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags = registry, making this TCP flag >>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>=20 >>>>>>>> Better? >>>>>>>>=20 >>>>>>>>> In my understanding, this experimental document asks for new = assignment >>>>>>>>=20 >>>>>>>> of a reserved TCP header flag. >>>>>>>>=20 >>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded this = discussion yet. >>>>>>>> However, >>>>>>>> what we really would want to is mention somewhere that this = experiment >>>>>>>> with this flags is running. I guess there are three options: >>>>>>>> 1) keep it in the registry as reserved and conserve the = knowledge in >>>>>>>> tcpm >>>>>>>> that this experiment is running and no other experimental RFC = such use >>>>>>>> this >>>>>>>> flags as long as this experiment is running. >>>>>>>> 2) Keep is marked as reserved but add a note about this = experiment in >>>>>>>> the >>>>>>>> IANA registry >>>>>>>> 3) Or assign it right away with IESG approval. I guess in this = case tcpm >>>>>>>> could >>>>>>>> also consider to change the registration policy to =E2=80=9EIETF = Review=E2=80=9C. >>>>>>>=20 >>>>>>> The current registration policy for the TCP header flags is = "standards >>>>>>> action". I understand that the IESG could approve exceptions. = But given the >>>>>>> policy, I believe the document has to be very precise on the = request >>>>>>> regarding bit 7. >>>>>>=20 >>>>>> Okay, it now says: >>>>>>=20 >>>>>> "[TO BE REMOVED: IANA is requested to update the existing entry = in the >>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>> = (https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ia= na.org%2Fassignments%2Ftcp-header-flags%2Ftcp-header-flags.xhtml%23tcp-hea= der-flags-1&data=3D02%7C01%7Cpravb%40microsoft.com%7C2e4980f91d89410fa= 58708d5e8111fbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366700826104= 53620&sdata=3DKXOFPQ%2FfWW0dekv5%2BdYM8stbLl80hLtlJVnM9s5G9lQ%3D&r= eserved=3D0) >>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as = NS (Nonce >>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this = RFC-to-be instead >>>>>> of RFC8311.]=E2=80=9C >>>>>>=20 >>>>>> I guess we could also ask IANA to add an additional comment = column instead >>>>>> (but not sure if we then have to update RFC3168, which I think we = really >>>>>> don=E2=80=99t want. Should be fine now. >>>>>>=20 >>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>=20 >>>>>>>>> o an essential part that re-uses ECN TCP header bits to feed = back >>>>>>>>> the number of arriving CE marked packets. This provides = more >>>>>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>>>>> against >>>>>>>>> ACK loss; >>>>>>>>>=20 >>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>=20 >>>>>>>> I think this is nit picking. Using a different phrasing here = makes the >>>>>>>> sentence >>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how get a = round the fact >>>>>>>> that we need to handle the flag registration correctly. = However, here >>>>>>>> the >>>>>>>> point really is to explain how the protocol word. The main = point of >>>>>>>> using the >>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that = these flags are or have >>>>>>>> been >>>>>>>> used different by other TCP extension (and we therefore need a = proper >>>>>>>> negotiation scheme). >>>>>>>=20 >>>>>>> If the allocation of a reserved flag is correctly explained in = the >>>>>>> abstract and introduction, I think these sentences can use a bit = relaxed >>>>>>> terminology. >>>>>>>=20 >>>>>>>>> The two part design was necessary, given limitations on the = space >>>>>>>>> available for TCP options and given the possibility that = certain >>>>>>>>> incorrectly designed middleboxes prevent TCP using any new = options >>>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.c= om%7C2e4980f91d89410fa58708d5e8111fbb%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636670082610453620&sdata=3DBzLdW3YTISACG5pakJhqTGE%2BWg5mRX3T= 514Z7woG2oI%3D&reserved=3D0 From nobody Thu Jul 12 22:23:36 2018 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 987CB130E30; Thu, 12 Jul 2018 22:23:33 -0700 (PDT) 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, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 pywn45QfPd7h; Thu, 12 Jul 2018 22:23:30 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF6D130E15; Thu, 12 Jul 2018 22:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BuUXJRgc7p+KGoMGrCMXKJKd0DunInObUdm7gbrkDZk=; b=APb9BFQrqZAMvMEOPGTUOaeyD YsAvmz87zPKf5xTaLPqsDI/EZ1+gBh99O23Zf416IeL4XK6K9/uMO2AAdgGCmXjG908nj1gD89xrP /IKC6eXQ8OFpJVNdAEBkPR9O0BMDdFZ7xDzPH7Jy5Az+nVSIruyjsNby+iUa7xESI5NIppRVnZTAV c93JBX8Ur9v0W/gwNCRrb3QGoXSRKu1C36XP+07q4e04HAIIo8aG+hNKTlawc2vsc47TKWBAgNefw N82aASndZDo6EC0upijsaIOVLSAx8jJBAe7dqoYhxzZkQfXCBTq7mBYYVhOwRMbSaT20DWDjs6Ncv d8VVlowCA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:63363 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fdqY7-003wOx-Rc; Fri, 13 Jul 2018 01:23:29 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_2C539CF5-BB31-4B83-9F7B-8CA5BE6366FF" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: Date: Thu, 12 Jul 2018 22:23:23 -0700 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , Yuchung Cheng , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Message-Id: <0D497F4E-9918-499B-83D2-1C00BD6577E6@strayalpha.com> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3445.8.2) 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] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 05:23:34 -0000 --Apple-Mail=_2C539CF5-BB31-4B83-9F7B-8CA5BE6366FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let=E2=80=99s please be clear: > On Jul 12, 2018, at 9:25 AM, Praveen Balasubramanian = wrote: >=20 > Re. GRO/LRO/RSC: = https://docs.microsoft.com/en-us/windows-hardware/drivers/network/exceptio= n-conditions-that-terminate-coalescing = see condition 4 for an = exception that terminates coalescing: "The segment contains one or more = TCP options other than the TCP timestamp option". So while software = implementations of coalescing can be updated, existing hardware will = cause poor performance with new TCP options that are present in a lot of = data packets.=20 While that may be true, it is also true that such performance = optimizations always violated TCP. If we avoid updating the protocol as = defined because of such existing violations, we might as well engrain = TCP coalescing as legitimate in the protocol and deprecate all options = other than timestamp. Joe --Apple-Mail=_2C539CF5-BB31-4B83-9F7B-8CA5BE6366FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Let=E2=80=99s please be clear:

On Jul = 12, 2018, at 9:25 AM, Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> = wrote:

Re. GRO/LRO/RSC: https://docs.microsoft.com/en-us/windows-hardware/drivers/netwo= rk/exception-conditions-that-terminate-coalescing see condition 4 for an = exception that terminates coalescing: "The segment contains one or more = TCP options other than the TCP timestamp option". So while software = implementations of coalescing can be updated, existing hardware will = cause poor performance with new TCP options that are present in a lot of = data packets. 
While that may be true, it is also true that such = performance optimizations always violated TCP. If we avoid updating the = protocol as defined because of such existing violations, we might as = well engrain TCP coalescing as legitimate in the protocol and deprecate = all options other than timestamp.

Joe

= --Apple-Mail=_2C539CF5-BB31-4B83-9F7B-8CA5BE6366FF-- From nobody Fri Jul 13 01:18:28 2018 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 3378E130DDB; Fri, 13 Jul 2018 01:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 rYVqi06ikm-2; Fri, 13 Jul 2018 01:18:19 -0700 (PDT) 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 C6834130E13; Fri, 13 Jul 2018 01:18:18 -0700 (PDT) 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=qVrnvOMDSGbjhvKGcGMN/3WoE9PmbkDjp17+7hYulZs=; b=XIW1dLTuf49/EV4gK1O485LTwn 1yWcNXfIc7fPcAgr+NWN6BpD5IjDlcJaEGqbhHVIxLim8xtHf93grQlb6ccA8ahovdOiGMtjsWIB2 eQMnc/rgyNeUXZtqttdy4E0BbRZ8tVm9HThpN5FnIcKtyvbcIAhfy1x1CKRRL82FJKttZR3PnNDcV Df+cwaFUpB2e7QI7Irm6xx2WE9rq8g3vGE/WGG45i9oFPFjLBdvoAkwNRjG8yD3P6XcpYEjaHWBiL Zif0Bo/k0ojjVXBdt3IhbyUU+z8G0XmXXgXT07+B/gF0BMKAjpYbeSr2sPKAEqUXJhelvf23IJFvV YlodezZQ==; Received: from 70.245.199.146.dyn.plus.net ([146.199.245.70]:40086 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fdtHK-0006um-SW; Fri, 13 Jul 2018 09:18:16 +0100 To: Yuchung Cheng Cc: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> From: Bob Briscoe Message-ID: Date: Fri, 13 Jul 2018 09:18:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 08:18:26 -0000 Yuchung, On 12/07/18 17:03, Mirja Kühlewind wrote: > Hi Yuchung, > > please see below. > >> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >> >> Yes packets with ACE options and (different) ACE-counter header would >> break GRO. There're many legacy h/w and s/w. > I’m not the expert here but my understanding is that is would not break GRO but could not make actual use or it if the ACE counter changed or the option is present. [BB] Yuchung's criticism applies to any scheme that feeds back a continually changing signal like ECN. For instance, like AccECN feedback, DCTCP ECN feedback continually changes the TCP header flags, and I believe DCTCP is widely used in DCs. I believe, to make GRO support ECN feedback (whether DCTCP or AccECN), it would be necessary for GRO to know which bits to mask when determining whether a packet is mergeable with others. I believe GRO already collects header fields separately for the TCP logic to be able to work on them, but I'm also not an expert. > However, usually your will only have a small number of CE marks every couple of RTTs, and the counter only changes if you CE marks/the option is only present a few times per RTT. So the impact should be rather low. But this clear something to evaluate for the experiment. [BB] With DCTCP as currently designed, you tend to get runs of 100% CE if the load of short flows is very small. In that case, DCTCP feedback will change the header flags less often than AccECN. However, with more short flows, the feedback is more on-off. Then the flags change more often with DCTCP than with AccECN feedback. In general, hardware optimization is not going to optimize a protocol that didn't exist when the hardware was designed. It would be ideal to design a new protocol that takes advantage of existing hardware optimization. However, as long as an experimental protocol still works with existing hardware, I think it's reasonable to assume that hardware optimization will only arrive once a protocol has become well-established. > >> Even without option, ACE header only allows reflecting up to 8 packets >> for receiver segmentation offload and ACK suppression? > Same as above, it can only up to 8 CE marked packets per ACK, however, CE marking rater are expected to be rather low. ACK suppression should probably not be used if the ACE counter has changes, however, usually the ACE counter stays stable for multiple RTTs and then ACK suppression is not a problem. However, not sure I understood you question here correctly…? > >> The appendix on ack loss causes ambiguity is good: but the pattern >> drops specifically the state-switch (CE<->noCE) ACK which only happens >> on delayed ACK. Is that pattern common? - or can we address most of >> that by delaying less ACKs? > I guess you have a 50% chance today to hit a delayed ACK. I guess delaying less (where you delay every second ACK today) would mean ACK every packet, and thus double ACK load on the network. I guess on today networks that actually in most cases not a problem, however, there might be specially cases where it is. However, that’s problem an independent question to evaluate. [BB] If there were no delayed ACKs, the problem with DCTCP feedback would largely disappear. But delayed ACKs are not going away. Which is why we proposed replacing DCTCP feedback with AccECN feedback. > >> I am all for making ECN more accurate for wide area beyond DCTCP, but >> am evaluating the pros/cons. What if we just >> 1. negotiate 'better' ECN via new SYN option > Not sure I understand your proposal correctly, but I assume you mean negotiate via SYN option and then just use the ACE counter in the header? If so, I don’t understand why you see the negotiation part in the TCP header as the problem? [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a solution without a problem. In fact an option on the SYN would create a new problem 'cos of the severe shortage of space for SYN options (for this reason, the AccECN TCP option was designed not to be needed on the SYN). > >> 2. mark all packets like ECN++ > That would be nice but here you actually need AccECN because you want to have feedback for control packets as well. AccECN is providing this feedback. AccECN does not change the „use of ECN“; that’s what we have ECN++ for; both thing ideally would be deployed together however. Was that your questions? Cheers Bob > Mirja > > >> >> >> >> >> >> On Thu, Jul 12, 2018 at 3:23 AM, Mirja Kühlewind >> wrote: >>> Hi Yuchung, >>> >>> the question if you need this „more“ on accuracy really depends on the use case. If you use DCTCP as today, the ACE counter in the TCP is probably sufficient and you might not want to pay the additional overhead in your data center (that why the option is actually optional). >>> >>> If you however, e.g., have very differently sized packets, then the byte counter in the option could give you a more accurate signal. Or if you are also interested in the ECT(1) counter, you need the option. Further the ACE counter also give your feedback on control packet and the option enables you to distinguish between CE-amrked payload and control packets, which can also become important when experimenting with making all packets ECN-capable. >>> >>> Given accECN is a general feedback mechanism that in fact is designed to enable new future uses of the ECN signal, we wanted to keep all these option available while making is still as simple as possible and as flexible as possible. >>> >>> Mirja >>> >>> >>> >>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>> >>>> Hi Bob, >>>> >>>> Neal and I evaluated the earlier draft. It is well-thought out but >>>> we're concerned about the options. Option is not mandatory but the >>>> lack of it also reduces accuracy. Option runs into space issues w/ >>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure but >>>> aren't easy. >>>> >>>> We're curious how much more "accuracy" it buys over current >>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>> >>>> >>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe wrote: >>>>> Michael, tcpm list, >>>>> >>>>> As well as addressing your points, as Mirja has already mentioned below, we >>>>> added a whole new appendix giving the rationale for the bits and codepoints >>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >>>>> subsection also identifies space for future evolution. It also points to >>>>> where rationale was already given in the body of the draft. >>>>> >>>>> The appendix is in the draft submitted last week, available here: >>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>>>> >>>>> We'd be interested to hear whether this allays your concerns. >>>>> >>>>> We have asked to present this in Montreal as well. >>>>> >>>>> Cheers >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>>> On 02/07/18 16:54, Mirja Kühlewind wrote: >>>>>> Hi Micheal, >>>>>> >>>>>> I addressed a couple of your comments below. >>>>>> >>>>>> For the other, bigger comments regarding extensibility, that I did not yet >>>>>> address below, we plan to add a new section to the appendix to explain >>>>>> extensibility options as previously discussed by mail. We will probably send >>>>>> a separate email on that part. >>>>>> >>>>>> Mirja >>>>>> >>>>>> >>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>> : >>>>>>> >>>>>>> Hi Mirja, >>>>>>> >>>>>>> Thanks a lot for the explanation. I won't follow-up on some of the >>>>>>> editorial suggestions. >>>>>>> >>>>>>> Yet, I continue to believe that some formal wording in the document needs >>>>>>> to change, as explained below. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Michael (with no hat on) >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>> >>>>>>>> Hi Micheal, >>>>>>>> >>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>> >>>>>>>> Please see inline. >>>>>>>> >>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>> : >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix). I >>>>>>>> believe this document needs further work before moving forward. >>>>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>>>> document independent of the review from Gorry. I apologize if there is >>>>>>>> duplication. >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Michael (with no hat on) >>>>>>>>> >>>>>>>>> >>>>>>>>> ****************************** >>>>>>>>> >>>>>>>>> * Abstract: >>>>>>>>> >>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or >>>>>>>>> Data >>>>>>>> Center TCP >>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever more >>>>>>>>> than one marking is received in one RTT. >>>>>>>>> >>>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>>>>>> suggest to >>>>>>>> remove this, or replace it by a more generic statement that more >>>>>>>> accurate >>>>>>>> information can be useful for several TCP extensions. >>>>>>>> >>>>>>>> I disagree. Both ConEx and DCTCP need more accurate information. They do >>>>>>>> not need the mechanism that is specified in this draft, however, this is >>>>>>>> not >>>>>>>> what the sentences is saying. >>>>>>> In my understanding (as a non-native speaker), the use of the word "need" >>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be implemented >>>>>>> without any such mechanism. >>>>>>> >>>>>>> What would work for me is something of the form "... Data Center TCP >>>>>>> cannot get precise ECN feedback whenever more than one marking is received >>>>>>> in one RTT“. >>>>>> This is not correct. DCTP need more than one feedback signal per RTT and >>>>>> therefore cannot use RFC3168; instead it implement it’s own feedback >>>>>> mechanism. However, to avoid confusion such that people could assume DCTP >>>>>> would not work without the accECN scheme as specified in this doc, I >>>>>> rephrased to: >>>>>> >>>>>> "Recently, proposed >>>>>> mechanisms like Congestion Exposure (ConEx >>>>> target="RFC7713"/>), >>>>>> DCTCP or L4S >>>>> target="I-D.ietf-tsvwg-l4s-arch"/> need to know when more than one >>>>>> marking is received in one RTT which is >>>>>> information that cannot be provided by the feedback scheme as >>>>>> specified in >>>>>> ." >>>>>> >>>>>> >>>>>>>>> This document specifies an >>>>>>>>> experimental scheme to provide more than one feedback signal per RTT >>>>>>>>> in the TCP header. Given TCP header space is scarce, it overloads >>>>>>>>> the three existing ECN-related flags in the TCP header and provides >>>>>>>>> additional information in a new TCP option. >>>>>>>>> >>>>>>>>> [ms] This statement needs to be rewritten to correctly reflect what is >>>>>>>> requested from IANA. My understanding is that this experimental document >>>>>>>> asks for allocation of a reserved TCP header flag. This needs to be >>>>>>>> called out >>>>>>>> prominently, IMHO. In addition, since this is not a standard, the >>>>>>>> suggested >>>>>>>> experimentation with the main TCP header must IMHO be explicitly >>>>>>>> mentioned. I also suggest to have later in a document a section that >>>>>>>> explicitly >>>>>>>> explains why it is appropriate to modify the main TCP header in an >>>>>>>> experiment. >>>>>>>> >>>>>>>> I don’t know if any requirement that IANA assignment need to be called >>>>>>>> out >>>>>>>> in the abstract but we can do that. However, I believe the question if >>>>>>>> this >>>>>>>> document should or should not assign the bit is still not completely >>>>>>>> solved, or >>>>>>>> is it? >>>>>>> I believe this question will have to be reviewed during WGLC and, more >>>>>>> importantly, IETF last call. For the moment, my concern is that the document >>>>>>> correctly describes the IANA allocation. >>>>>>> >>>>>>> I would like to see here a statement such as : "Given TCP header space is >>>>>>> scarce, this specification allocates a reserved header bit and overloads the >>>>>>> two ECN flags in the TCP header ...“. >>>>>> A bit lengthy but now: >>>>>> >>>>>> "Given TCP header space is >>>>>> scarce, it allocates a reserved header bit, that was previously >>>>>> used for >>>>>> ECN-Nonce which was recently declared historic, and overloads the >>>>>> two existing ECN flags in the TCP header. Further, additional >>>>>> information can be provided in a new TCP option that however is not >>>>>> used >>>>>> on the TCP SYN." >>>>>> >>>>>>>>> * 1. Introduction >>>>>>>>> >>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>>>>>>> more accurate ECN feedback information whenever more than one >>>>>>>> marking >>>>>>>>> is received in one RTT. >>>>>>>>> >>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit this. >>>>>>>>> Instead >>>>>>>> of stating a "need", it would IMHO make more sense to discuss the >>>>>>>> benefits >>>>>>>> of the suggested mechanism in this document of its own, independent of >>>>>>>> other proposals. To me, this document should be independent of other >>>>>>>> documents and specifically other experiments. We have to think about >>>>>>>> cases >>>>>>>> where not all experiments are successful. Then independent documents >>>>>>>> will >>>>>>>> be more future-proof in future. >>>>>>>> >>>>>>>> This is a naming collision… The sentence was meant to say that these >>>>>>>> mechanisms new more accurate ECN feedback than provided today by >>>>>>>> RFC3168 but it was not meant to say that these mechanism have to use the >>>>>>>> scheme as specified in this document. >>>>>>>> >>>>>>>> I added the following part sentence: >>>>>>>> >>>>>>>> „Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need more >>>>>>>> accurate ECN feedback information than provided by the feedback scheme >>>>>>>> as specified in [RFC3168] whenever more than one marking is received in >>>>>>>> one >>>>>>>> RTT. This document specifies an alternative feedback scheme that >>>>>>>> provides >>>>>>>> more accurate information and could be used by these new TCP >>>>>>>> extensions.“ >>>>>>>> >>>>>>>> Does this help? >>>>>>> See my proposal for the abstract. I continue to disagree with the term >>>>>>> "need" but I think this can be sorted out by another term. >>>>>>> >>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>> track, it is intended to be a complete replacement for classic TCP/ >>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>> >>>>>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>>>> Why? It states an intent… and that’s the intent that we have. >>>>>>>> >>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as the >>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>> >>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>> Why? Does it help to add an only here: >>>>>>>> >>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as the only >>>>>>>> standards track specification for adding ECN to TCP.“ >>>>>>> This wording is better. >>>>>>> >>>>>>>>> AccECN feedback overloads flags and fields in the main TCP header >>>>>>>>> with new definitions, so both ends have to support the new wire >>>>>>>>> protocol before it can be used. >>>>>>>>> >>>>>>>>> [ms] In my reading this experimental document asks for *new* allocation >>>>>>>> of a reserved TCP header flag. >>>>>>>> >>>>>>>> Is this better? >>>>>>>> >>>>>>>> "AccECN feedback overloads the two existing ECN flags as well as the >>>>>>>> currently reserved and previously called NS flag in the main TCP >>>>>>>> header >>>>>>>> with new definitions, so both ends have to support the new wire >>>>>>>> protocol >>>>>>>> before it can be used.“ >>>>>>>> >>>>>>>> I understand that you are not happy with the word „overload“ here but >>>>>>>> the >>>>>>>> point of this sentence really is that the flags can/could be used >>>>>>>> differently >>>>>>>> and therefore we need a new negotiation before we can use them. >>>>>>> For me the following would work: "AccECN feedback overloads the two >>>>>>> existing ECN flags and >>>>>>> allocates the currently reserved and previously called NS flag in the >>>>>>> main TCP header. >>>>>>> Given the new definitions, both ends have to support the new wire >>>>>>> protocol >>>>>>> before it can be used." >>>>>>> >>>>>>> I believe the wording has to be crystal clear on the reservation of bit 7 >>>>>>> when it is discussed the first time in the text. In follow-up sections, >>>>>>> maybe shorter terms could be used. >>>>>> Okay, now: >>>>>> >>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>> allocates the currently reserved and previously called NS flag in the >>>>>> TCP header, to be used as one field indicating the number of >>>>>> congestion >>>>>> experienced marked packets. Given the new definitions of these three >>>>>> bits, >>>>>> both ends have to support the new wire protocol before it can be >>>>>> used. >>>>>> Therefore during the TCP handshake the two ends use these three bit >>>>>> in >>>>>> the TCP header to negotiate the most advanced feedback protocol >>>>>> that they can both support in a backward compatible way to >>>>>> ." >>>>>>>> If you prefer, we can also remove the NS flag in this list, as ECN Nonce >>>>>>>> was >>>>>>>> anyway never deployed. >>>>>>>> >>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>> specifies a different response to TCP ECN feedback, for example: >>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>>>>> Latency >>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], or >>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>> >>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this paragraph can >>>>>>>>> just >>>>>>>> be deleted. If other experiments need more accurate feedback, it is up >>>>>>>> to >>>>>>>> them to explain how they would use this mechanism. This document should >>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>> >>>>>>>> Yes, that is what the paragraph says. Isn’t it better to be explicit >>>>>>>> about this? >>>>>>>> >>>>>>>>> It is likely (but not required) that the AccECN protocol will be >>>>>>>>> implemented along with the following experimental additions to the >>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>> retransmissions >>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/ >>>>>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>> >>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my view, the >>>>>>>>> TCPM >>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>>> draft-ietf- >>>>>>>> tcpm-generalized-ecn independent documents, which probably implies that >>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If experimentation >>>>>>>> with ECT in SYN requires a combination, this could be done in a new, >>>>>>>> third >>>>>>>> document. Apart from having simpler focused documents, this could >>>>>>>> significantly help later with moving forward documents to standards >>>>>>>> track. >>>>>>>> >>>>>>>> I disagree, however, this is a discussion to have on draft-ietf-tcpm- >>>>>>>> generalized-ecn. I don’t see a problem in providing a reference here >>>>>>>> that >>>>>>>> says „it is likely…“ and nothing more. >>>>>>>>> >>>>>>>>> >>>>>>>>> * 1.1. Document Roadmap >>>>>>>>> >>>>>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>>>>> introduction >>>>>>>> and tutorial text with lot's of redundancy towards other documents. I >>>>>>>> think >>>>>>>> the document can be made much easier to read by shorten it. In many >>>>>>>> cases >>>>>>>> this is just an editorial change as there is redundancy. As one such >>>>>>>> example, >>>>>>>> just remove this section. >>>>>>>> >>>>>>>> I guess this a matter of taste. As an AD, I’m a big fan of short and >>>>>>>> concise >>>>>>>> documents, however, some redundancy can also help understanding, >>>>>>>> especially if you explain things multiple times but with a different >>>>>>>> level of >>>>>>>> detail. I personally would not need the roadmap but I know many people >>>>>>>> who find these things helpful and to be honest I don’t see how removing >>>>>>>> this >>>>>>>> part makes the doc any better. If you don’t want it, don’t read it. >>>>>>>> >>>>>>>>> * 1.2. Goals >>>>>>>>> >>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>> I have to say I also don’t see the point of removing this part. Given >>>>>>>> we’ve >>>>>>>> done the work on requirements, I think we should also link to this doc >>>>>>>> somewhere. >>>>>>>>> >>>>>>>>> * 1.3. Experiment Goals >>>>>>>>> >>>>>>>>> TCP is critical to the robust functioning of the Internet, therefore >>>>>>>>> any proposed modifications to TCP need to be thoroughly tested. The >>>>>>>>> present specification describes an experimental protocol that adds >>>>>>>>> more accurate ECN feedback to the TCP protocol. The intention is to >>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>> implementation can be built in order to test its function, >>>>>>>>> robustness >>>>>>>>> and interoperability (with itself and with previous version of ECN >>>>>>>>> and TCP). >>>>>>>>> >>>>>>>>> [ms] I think all what is written in this paragraph is obvious, no? >>>>>>>>> Can't we just >>>>>>>> delete this? >>>>>>>> >>>>>>>> Sure, however, I don’t think it hurts to spell it out. For me both is >>>>>>>> fine, keep it >>>>>>>> or remove it. >>>>>>>> >>>>>>>>> The experimental protocol will be considered successful if it is >>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] in the >>>>>>>>> consensus opinion of the IETF tcpm working group. In short, this >>>>>>>>> requires that it improves the accuracy and timeliness of TCP's ECN >>>>>>>>> feedback, as claimed in Section 5, while striking a balance between >>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>> minimisation of overhead. It also requires that it is not unduly >>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>> behaviours in the current Internet (e.g. hardware offloading and >>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>> >>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>> specified >>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>>> middleboxes. Therefore experimental verification to confirm large- >>>>>>>>> scale path traversal in the Internet is needed before finalizing >>>>>>>>> this >>>>>>>>> specification on the Standards Track. >>>>>>>>> >>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>>>>>> mentioned before, I don't think an RFC should speculate about TCPM and >>>>>>>> its >>>>>>>> consensus opinion. I would suggest a wording along the lines of: >>>>>>>>> >>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>> testing confirms that the proposed mechanism can be deployed at >>>>>>>>> large >>>>>>>> scale. >>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>> specified >>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of >>>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>>> middleboxes. Therefore experimental verification to confirm large- >>>>>>>>> scale path traversal in the Internet is needed, e.g., by support in >>>>>>>>> major TCP stacks. >>>>>>>>> >>>>>>>>> >>>>>>>> I don’t understand your point here. I don’t think that the paraphrase >>>>>>>> speculates about the consensus of tcpm, in contrast it say tcpm has to >>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>> sufficiently >>>>>>>> fulfilled. I don’t see a reason to not mention the requirement draft as >>>>>>>> this >>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>> My suggested wording uses the expression "can be deployed at large scale" >>>>>>> and I believe this is relevant. >>>>>>> >>>>>>> The document already describes in Section 5 how the protocol satisfies >>>>>>> the agreed requirements for a more accurate ECN feedback protocol [RFC7560]. >>>>>>> So, if the TCPM working group publishes this document with the content of >>>>>>> Section 5, I believe the TCPM working group already has reached consensus >>>>>>> that the protocol meets requirements. In addition, it is possible that new >>>>>>> requirements would be identified in future, e.g., as an outcome of the >>>>>>> experiment, and that would obviously have to be considered by TCPM. In that >>>>>>> case, for the success of the experiment not only RFC 7560 would matter, but >>>>>>> also further requirements. My proposed wording does not have all these >>>>>>> problems. >>>>>>> >>>>>>> In a nutshell, I continue to believe that this section has to change. >>>>>> >>>>>> Okay, used your proposed wording. You have a point about the requirement >>>>>> and I mis-read you proposal earlier as „has to be deployed large-scale“. >>>>>> >>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>> >>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>> >>>>>>>>> The last bit in byte 13 of the TCP header was defined as the Nonce >>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deployed >>>>>>>>> so >>>>>>>>> it is being reclassified as historic, making this TCP flag available >>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>> >>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into account the >>>>>>>>> IANA >>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>>>> >>>>>>>> Is does. However, I can explicitly say that is has be re-clssified as >>>>>>>> reserved. >>>>>>>> >>>>>>>> "RFC 3540 was never deployed so it is being reclassified as historic >>>>>>>> [I-D.ietf- >>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been marked as >>>>>>>> „reserved“ in the IANA TCP Header Flags registry, making this TCP flag >>>>>>>> available for use by the AccECN experiment instead.“ >>>>>>>> >>>>>>>> Better? >>>>>>>> >>>>>>>>> In my understanding, this experimental document asks for new assignment >>>>>>>> of a reserved TCP header flag. >>>>>>>> >>>>>>>> As I said I’m not sure if we have fully concluded this discussion yet. >>>>>>>> However, >>>>>>>> what we really would want to is mention somewhere that this experiment >>>>>>>> with this flags is running. I guess there are three options: >>>>>>>> 1) keep it in the registry as reserved and conserve the knowledge in >>>>>>>> tcpm >>>>>>>> that this experiment is running and no other experimental RFC such use >>>>>>>> this >>>>>>>> flags as long as this experiment is running. >>>>>>>> 2) Keep is marked as reserved but add a note about this experiment in >>>>>>>> the >>>>>>>> IANA registry >>>>>>>> 3) Or assign it right away with IESG approval. I guess in this case tcpm >>>>>>>> could >>>>>>>> also consider to change the registration policy to „IETF Review“. >>>>>>> The current registration policy for the TCP header flags is "standards >>>>>>> action". I understand that the IESG could approve exceptions. But given the >>>>>>> policy, I believe the document has to be very precise on the request >>>>>>> regarding bit 7. >>>>>> Okay, it now says: >>>>>> >>>>>> "[TO BE REMOVED: IANA is requested to update the existing entry in the >>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1) >>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS (Nonce >>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be instead >>>>>> of RFC8311.]“ >>>>>> >>>>>> I guess we could also ask IANA to add an additional comment column instead >>>>>> (but not sure if we then have to update RFC3168, which I think we really >>>>>> don’t want. Should be fine now. >>>>>> >>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>> >>>>>>>>> o an essential part that re-uses ECN TCP header bits to feed back >>>>>>>>> the number of arriving CE marked packets. This provides more >>>>>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>>>>> against >>>>>>>>> ACK loss; >>>>>>>>> >>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>> I think this is nit picking. Using a different phrasing here makes the >>>>>>>> sentence >>>>>>>> unnecessary complicated. We don’t try to some how get a round the fact >>>>>>>> that we need to handle the flag registration correctly. However, here >>>>>>>> the >>>>>>>> point really is to explain how the protocol word. The main point of >>>>>>>> using the >>>>>>>> work „re-use“ here is really that we say that these flags are or have >>>>>>>> been >>>>>>>> used different by other TCP extension (and we therefore need a proper >>>>>>>> negotiation scheme). >>>>>>> If the allocation of a reserved flag is correctly explained in the >>>>>>> abstract and introduction, I think these sentences can use a bit relaxed >>>>>>> terminology. >>>>>>> >>>>>>>>> The two part design was necessary, given limitations on the space >>>>>>>>> available for TCP options and given the possibility that certain >>>>>>>>> incorrectly designed middleboxes prevent TCP using any new options -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jul 13 11:39:03 2018 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 83EB1130E6A for ; Fri, 13 Jul 2018 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 ZtDYeAUe67ii for ; Fri, 13 Jul 2018 11:38:51 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 80A14130F5C for ; Fri, 13 Jul 2018 11:38:47 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id r24-v6so32140419ioh.9 for ; Fri, 13 Jul 2018 11:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=57rlpsjCoM8vYwQj/08EOUMiCjVmbDTGkBFZ081IRYs=; b=h/tZ81LHp5lWegAqr1zodCiratCOMnoGGObL836uYwsnkMJ30GFwYZYKEUZaAfjYAh 38ytY2WC3vuqaJwNtvd/Yw6QKH6is2v71JxWiBnEursE1A5X+s1/uTie/QuTUgsTAW2E Ghdm4K3FuyozC3g0WsXIJoRpiLwKg3NRj1QuIgUduTT8Gs2LXvz6XWvIRtltqh2jMwg4 M6OWsEwLuwanBcudleWFLSSP9iDGNoLOEGc3wQloKTWfWK+IOW3YB2QAfqeRHhgYHlwQ 7R5xz9QGmFjm7xwAmd6+EGFh59mnQTyA43w5gIIKtdkecHESmaDkvf0u9H2GE1GkS2bw niPg== 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:content-transfer-encoding; bh=57rlpsjCoM8vYwQj/08EOUMiCjVmbDTGkBFZ081IRYs=; b=OPIz7OK/3R5/occ3GD+dD6qYPI98Tkqc3lNl3ifXKK6ngxrrlqGPcT2P72h1BI91ZU WLloU4c7yYx9ROwCYgputM3CP5RHcH2rMoW9T9qHPVTd2qUhVbMIc/paT/v+CwqvTnQC B5o6VzVF5V+zjLrsEX9rIP0ElFB4wNNoXZNgwGfb7/dccrIeIWMV/9yKz9hDXv33nErM Wor/yao6OyA9rf0WAZ3QoEgIGD0qVMSPemZapVBmq82rd9pRXomoQltP4VyWNtKxPHa7 CpY+N9XfhX/8xG0KN3KRoNSseRkBwi5s5WW5oAtcxDhI9fktgxt4VBy4gA9IPSz5WIuC DnHw== X-Gm-Message-State: AOUpUlGkUDIgTKHTjLjU0gWPEETz73Tm8McQXfhdojfzp/sJb8NWg0yh sq3wZpwa49rWmfoGo8SaNbvq7IZhp18eNdEXqFwf+A== X-Google-Smtp-Source: AAOMgpcC5CSj6O4v6ZjVymjqUtOrJyoDBNP8tq6fkBZq5H+6zavWx7ikox75VlqBV7BlAjY7FWE5EAheRetvuJx3CXI= X-Received: by 2002:a6b:825e:: with SMTP id e91-v6mr8048276iod.118.1531507126222; Fri, 13 Jul 2018 11:38:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5e:c10d:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 11:38:05 -0700 (PDT) In-Reply-To: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> From: Yuchung Cheng Date: Fri, 13 Jul 2018 11:38:05 -0700 Message-ID: To: Bob Briscoe Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 18:39:01 -0000 hi -- I agree: 1. delayed/streched ACK aren't going away (in fact will be more common) 2. GRO isn't and should not be a show-stopper 3. SYN option is running tight 4. HW opt comes after SW I worry: 1. GRO is a unavoidable issue in deployment (let's not produce an undeployable RFC). the ACE counter won't work as GRO can pack up to 64KB/MTU =3D~ 45 pkts under heavy congestion. 2. ACE's benefit over DCTCP is when delayed ACKs and ack losses happen. Now delayed ACKs happen frequently when the messages are small, which means they don't solicit too many ACKs to be dropped in the reverse path. Also that under heavy downstream loss or reordering, 3 SACK options become dominant to have ACE option. 4. If SYN option space is a concern, ACE header exchange is ok. But I suspect the latter has more middlebox issue based on my TFO deployment experience. So with all that said, is it possible to have a "minimal"-ACE that 1. Does ACE handshake as proposed 2. Mark ECT on all (or at least SYN & data & rtx) packets like ECN++ 3. Leave ACE-count and ACE option optional (i.e. MAY) as a "fairly safe" to deployment compromise. And I am happy to draft a kernel patch for that :-) On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe wrote: > Yuchung, > > On 12/07/18 17:03, Mirja K=C3=BChlewind wrote: >> >> Hi Yuchung, >> >> please see below. >> >>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>> >>> Yes packets with ACE options and (different) ACE-counter header would >>> break GRO. There're many legacy h/w and s/w. >> >> I=E2=80=99m not the expert here but my understanding is that is would no= t break >> GRO but could not make actual use or it if the ACE counter changed or th= e >> option is present. > > [BB] Yuchung's criticism applies to any scheme that feeds back a continua= lly > changing signal like ECN. For instance, like AccECN feedback, DCTCP ECN > feedback continually changes the TCP header flags, and I believe DCTCP is > widely used in DCs. > > I believe, to make GRO support ECN feedback (whether DCTCP or AccECN), it > would be necessary for GRO to know which bits to mask when determining > whether a packet is mergeable with others. I believe GRO already collects > header fields separately for the TCP logic to be able to work on them, bu= t > I'm also not an expert. >> >> However, usually your will only have a small number of CE marks every >> couple of RTTs, and the counter only changes if you CE marks/the option = is >> only present a few times per RTT. So the impact should be rather low. Bu= t >> this clear something to evaluate for the experiment. > > [BB] With DCTCP as currently designed, you tend to get runs of 100% CE if > the load of short flows is very small. In that case, DCTCP feedback will > change the header flags less often than AccECN. However, with more short > flows, the feedback is more on-off. Then the flags change more often with > DCTCP than with AccECN feedback. > > In general, hardware optimization is not going to optimize a protocol tha= t > didn't exist when the hardware was designed. It would be ideal to design = a > new protocol that takes advantage of existing hardware optimization. > However, as long as an experimental protocol still works with existing > hardware, I think it's reasonable to assume that hardware optimization wi= ll > only arrive once a protocol has become well-established. > >> >>> Even without option, ACE header only allows reflecting up to 8 packets >>> for receiver segmentation offload and ACK suppression? >> >> Same as above, it can only up to 8 CE marked packets per ACK, however, C= E >> marking rater are expected to be rather low. ACK suppression should prob= ably >> not be used if the ACE counter has changes, however, usually the ACE cou= nter >> stays stable for multiple RTTs and then ACK suppression is not a problem= . >> However, not sure I understood you question here correctly=E2=80=A6? >> >>> The appendix on ack loss causes ambiguity is good: but the pattern >>> drops specifically the state-switch (CE<->noCE) ACK which only happens >>> on delayed ACK. Is that pattern common? - or can we address most of >>> that by delaying less ACKs? >> >> I guess you have a 50% chance today to hit a delayed ACK. I guess delayi= ng >> less (where you delay every second ACK today) would mean ACK every packe= t, >> and thus double ACK load on the network. I guess on today networks that >> actually in most cases not a problem, however, there might be specially >> cases where it is. However, that=E2=80=99s problem an independent questi= on to >> evaluate. > > [BB] If there were no delayed ACKs, the problem with DCTCP feedback would > largely disappear. But delayed ACKs are not going away. Which is why we > proposed replacing DCTCP feedback with AccECN feedback. >> >> >>> I am all for making ECN more accurate for wide area beyond DCTCP, but >>> am evaluating the pros/cons. What if we just >>> 1. negotiate 'better' ECN via new SYN option >> >> Not sure I understand your proposal correctly, but I assume you mean >> negotiate via SYN option and then just use the ACE counter in the header= ? If >> so, I don=E2=80=99t understand why you see the negotiation part in the T= CP header as >> the problem? > > [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a solut= ion > without a problem. In fact an option on the SYN would create a new proble= m > 'cos of the severe shortage of space for SYN options (for this reason, th= e > AccECN TCP option was designed not to be needed on the SYN). >> >> >>> 2. mark all packets like ECN++ >> >> That would be nice but here you actually need AccECN because you want to >> have feedback for control packets as well. AccECN is providing this >> feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; that= =E2=80=99s what we have ECN++ >> for; both thing ideally would be deployed together however. Was that you= r >> questions? > > Cheers > > > Bob > >> Mirja >> >> >>> >>> >>> >>> >>> >>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind >>> wrote: >>>> >>>> Hi Yuchung, >>>> >>>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy reall= y depends on the >>>> use case. If you use DCTCP as today, the ACE counter in the TCP is pro= bably >>>> sufficient and you might not want to pay the additional overhead in yo= ur >>>> data center (that why the option is actually optional). >>>> >>>> If you however, e.g., have very differently sized packets, then the by= te >>>> counter in the option could give you a more accurate signal. Or if you= are >>>> also interested in the ECT(1) counter, you need the option. Further th= e ACE >>>> counter also give your feedback on control packet and the option enabl= es you >>>> to distinguish between CE-amrked payload and control packets, which ca= n also >>>> become important when experimenting with making all packets ECN-capabl= e. >>>> >>>> Given accECN is a general feedback mechanism that in fact is designed = to >>>> enable new future uses of the ECN signal, we wanted to keep all these = option >>>> available while making is still as simple as possible and as flexible = as >>>> possible. >>>> >>>> Mirja >>>> >>>> >>>> >>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>>> >>>>> Hi Bob, >>>>> >>>>> Neal and I evaluated the earlier draft. It is well-thought out but >>>>> we're concerned about the options. Option is not mandatory but the >>>>> lack of it also reduces accuracy. Option runs into space issues w/ >>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure bu= t >>>>> aren't easy. >>>>> >>>>> We're curious how much more "accuracy" it buys over current >>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>> >>>>> >>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe >>>>> wrote: >>>>>> >>>>>> Michael, tcpm list, >>>>>> >>>>>> As well as addressing your points, as Mirja has already mentioned >>>>>> below, we >>>>>> added a whole new appendix giving the rationale for the bits and >>>>>> codepoints >>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >>>>>> subsection also identifies space for future evolution. It also point= s >>>>>> to >>>>>> where rationale was already given in the body of the draft. >>>>>> >>>>>> The appendix is in the draft submitted last week, available here: >>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix= -B >>>>>> >>>>>> We'd be interested to hear whether this allays your concerns. >>>>>> >>>>>> We have asked to present this in Montreal as well. >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>> >>>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>> >>>>>>> Hi Micheal, >>>>>>> >>>>>>> I addressed a couple of your comments below. >>>>>>> >>>>>>> For the other, bigger comments regarding extensibility, that I did >>>>>>> not yet >>>>>>> address below, we plan to add a new section to the appendix to >>>>>>> explain >>>>>>> extensibility options as previously discussed by mail. We will >>>>>>> probably send >>>>>>> a separate email on that part. >>>>>>> >>>>>>> Mirja >>>>>>> >>>>>>> >>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>> DE/Stuttgart) >>>>>>>> : >>>>>>>> >>>>>>>> Hi Mirja, >>>>>>>> >>>>>>>> Thanks a lot for the explanation. I won't follow-up on some of the >>>>>>>> editorial suggestions. >>>>>>>> >>>>>>>> Yet, I continue to believe that some formal wording in the documen= t >>>>>>>> needs >>>>>>>> to change, as explained below. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Michael (with no hat on) >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.c= h] >>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>> >>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>> >>>>>>>>> Hi Micheal, >>>>>>>>> >>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>> >>>>>>>>> Please see inline. >>>>>>>>> >>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>> DE/Stuttgart) >>>>>>>>> >>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>> appendix). I >>>>>>>>> >>>>>>>>> believe this document needs further work before moving forward. >>>>>>>>>> >>>>>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>>>>> >>>>>>>>> document independent of the review from Gorry. I apologize if the= re >>>>>>>>> is >>>>>>>>> duplication. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Michael (with no hat on) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ****************************** >>>>>>>>>> >>>>>>>>>> * Abstract: >>>>>>>>>> >>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) = or >>>>>>>>>> Data >>>>>>>>> >>>>>>>>> Center TCP >>>>>>>>>> >>>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever >>>>>>>>>> more >>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>> >>>>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>>>>>>> suggest to >>>>>>>>> >>>>>>>>> remove this, or replace it by a more generic statement that more >>>>>>>>> accurate >>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>> >>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate information. >>>>>>>>> They do >>>>>>>>> not need the mechanism that is specified in this draft, however, >>>>>>>>> this is >>>>>>>>> not >>>>>>>>> what the sentences is saying. >>>>>>>> >>>>>>>> In my understanding (as a non-native speaker), the use of the word >>>>>>>> "need" >>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>> implemented >>>>>>>> without any such mechanism. >>>>>>>> >>>>>>>> What would work for me is something of the form "... Data Center T= CP >>>>>>>> cannot get precise ECN feedback whenever more than one marking is >>>>>>>> received >>>>>>>> in one RTT=E2=80=9C. >>>>>>> >>>>>>> This is not correct. DCTP need more than one feedback signal per RT= T >>>>>>> and >>>>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s own= feedback >>>>>>> mechanism. However, to avoid confusion such that people could assum= e >>>>>>> DCTP >>>>>>> would not work without the accECN scheme as specified in this doc, = I >>>>>>> rephrased to: >>>>>>> >>>>>>> "Recently, proposed >>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>> target=3D"RFC7713"/>), >>>>>>> DCTCP or L4S >>>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more t= han >>>>>>> one >>>>>>> marking is received in one RTT which is >>>>>>> information that cannot be provided by the feedback scheme as >>>>>>> specified in >>>>>>> ." >>>>>>> >>>>>>> >>>>>>>>>> This document specifies an >>>>>>>>>> experimental scheme to provide more than one feedback signal p= er >>>>>>>>>> RTT >>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>> overloads >>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>> provides >>>>>>>>>> additional information in a new TCP option. >>>>>>>>>> >>>>>>>>>> [ms] This statement needs to be rewritten to correctly reflect >>>>>>>>>> what is >>>>>>>>> >>>>>>>>> requested from IANA. My understanding is that this experimental >>>>>>>>> document >>>>>>>>> asks for allocation of a reserved TCP header flag. This needs to = be >>>>>>>>> called out >>>>>>>>> prominently, IMHO. In addition, since this is not a standard, the >>>>>>>>> suggested >>>>>>>>> experimentation with the main TCP header must IMHO be explicitly >>>>>>>>> mentioned. I also suggest to have later in a document a section >>>>>>>>> that >>>>>>>>> explicitly >>>>>>>>> explains why it is appropriate to modify the main TCP header in a= n >>>>>>>>> experiment. >>>>>>>>> >>>>>>>>> I don=E2=80=99t know if any requirement that IANA assignment need= to be >>>>>>>>> called >>>>>>>>> out >>>>>>>>> in the abstract but we can do that. However, I believe the questi= on >>>>>>>>> if >>>>>>>>> this >>>>>>>>> document should or should not assign the bit is still not >>>>>>>>> completely >>>>>>>>> solved, or >>>>>>>>> is it? >>>>>>>> >>>>>>>> I believe this question will have to be reviewed during WGLC and, >>>>>>>> more >>>>>>>> importantly, IETF last call. For the moment, my concern is that th= e >>>>>>>> document >>>>>>>> correctly describes the IANA allocation. >>>>>>>> >>>>>>>> I would like to see here a statement such as : "Given TCP header >>>>>>>> space is >>>>>>>> scarce, this specification allocates a reserved header bit and >>>>>>>> overloads the >>>>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>>> >>>>>>> A bit lengthy but now: >>>>>>> >>>>>>> "Given TCP header space is >>>>>>> scarce, it allocates a reserved header bit, that was previous= ly >>>>>>> used for >>>>>>> ECN-Nonce which was recently declared historic, and overloads >>>>>>> the >>>>>>> two existing ECN flags in the TCP header. Further, additional >>>>>>> information can be provided in a new TCP option that however = is >>>>>>> not >>>>>>> used >>>>>>> on the TCP SYN." >>>>>>> >>>>>>>>>> * 1. Introduction >>>>>>>>>> >>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] >>>>>>>>>> need >>>>>>>>>> more accurate ECN feedback information whenever more than one >>>>>>>>> >>>>>>>>> marking >>>>>>>>>> >>>>>>>>>> is received in one RTT. >>>>>>>>>> >>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit thi= s. >>>>>>>>>> Instead >>>>>>>>> >>>>>>>>> of stating a "need", it would IMHO make more sense to discuss the >>>>>>>>> benefits >>>>>>>>> of the suggested mechanism in this document of its own, independe= nt >>>>>>>>> of >>>>>>>>> other proposals. To me, this document should be independent of >>>>>>>>> other >>>>>>>>> documents and specifically other experiments. We have to think >>>>>>>>> about >>>>>>>>> cases >>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>> documents >>>>>>>>> will >>>>>>>>> be more future-proof in future. >>>>>>>>> >>>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant to say= that >>>>>>>>> these >>>>>>>>> mechanisms new more accurate ECN feedback than provided today by >>>>>>>>> RFC3168 but it was not meant to say that these mechanism have to >>>>>>>>> use the >>>>>>>>> scheme as specified in this document. >>>>>>>>> >>>>>>>>> I added the following part sentence: >>>>>>>>> >>>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure (= ConEx >>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>>>>>>> more >>>>>>>>> accurate ECN feedback information than provided by the feedback >>>>>>>>> scheme >>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>> received in >>>>>>>>> one >>>>>>>>> RTT. This document specifies an alternative feedback scheme that >>>>>>>>> provides >>>>>>>>> more accurate information and could be used by these new TCP >>>>>>>>> extensions.=E2=80=9C >>>>>>>>> >>>>>>>>> Does this help? >>>>>>>> >>>>>>>> See my proposal for the abstract. I continue to disagree with the >>>>>>>> term >>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>> >>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>> track, it is intended to be a complete replacement for classic >>>>>>>>>> TCP/ >>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>> >>>>>>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>>>>> >>>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent t= hat we have. >>>>>>>>> >>>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain as >>>>>>>>>> the >>>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>>> >>>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>> >>>>>>>>> Why? Does it help to add an only here: >>>>>>>>> >>>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as t= he >>>>>>>>> only >>>>>>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>>>>> >>>>>>>> This wording is better. >>>>>>>> >>>>>>>>>> AccECN feedback overloads flags and fields in the main TCP >>>>>>>>>> header >>>>>>>>>> with new definitions, so both ends have to support the new wir= e >>>>>>>>>> protocol before it can be used. >>>>>>>>>> >>>>>>>>>> [ms] In my reading this experimental document asks for *new* >>>>>>>>>> allocation >>>>>>>>> >>>>>>>>> of a reserved TCP header flag. >>>>>>>>> >>>>>>>>> Is this better? >>>>>>>>> >>>>>>>>> "AccECN feedback overloads the two existing ECN flags as well as >>>>>>>>> the >>>>>>>>> currently reserved and previously called NS flag in the main >>>>>>>>> TCP >>>>>>>>> header >>>>>>>>> with new definitions, so both ends have to support the new >>>>>>>>> wire >>>>>>>>> protocol >>>>>>>>> before it can be used.=E2=80=9C >>>>>>>>> >>>>>>>>> I understand that you are not happy with the word =E2=80=9Eoverlo= ad=E2=80=9C here >>>>>>>>> but >>>>>>>>> the >>>>>>>>> point of this sentence really is that the flags can/could be used >>>>>>>>> differently >>>>>>>>> and therefore we need a new negotiation before we can use them. >>>>>>>> >>>>>>>> For me the following would work: "AccECN feedback overloads the tw= o >>>>>>>> existing ECN flags and >>>>>>>> allocates the currently reserved and previously called NS flag in >>>>>>>> the >>>>>>>> main TCP header. >>>>>>>> Given the new definitions, both ends have to support the new wire >>>>>>>> protocol >>>>>>>> before it can be used." >>>>>>>> >>>>>>>> I believe the wording has to be crystal clear on the reservation o= f >>>>>>>> bit 7 >>>>>>>> when it is discussed the first time in the text. In follow-up >>>>>>>> sections, >>>>>>>> maybe shorter terms could be used. >>>>>>> >>>>>>> Okay, now: >>>>>>> >>>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>>> allocates the currently reserved and previously called NS flag = in >>>>>>> the >>>>>>> TCP header, to be used as one field indicating the number of >>>>>>> congestion >>>>>>> experienced marked packets. Given the new definitions of these >>>>>>> three >>>>>>> bits, >>>>>>> both ends have to support the new wire protocol before it c= an >>>>>>> be >>>>>>> used. >>>>>>> Therefore during the TCP handshake the two ends use these three >>>>>>> bit >>>>>>> in >>>>>>> the TCP header to negotiate the most advanced feedback protocol >>>>>>> that they can both support in a backward compatible way to >>>>>>> ." >>>>>>>>> >>>>>>>>> If you prefer, we can also remove the NS flag in this list, as EC= N >>>>>>>>> Nonce >>>>>>>>> was >>>>>>>>> anyway never deployed. >>>>>>>>> >>>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>>> specifies a different response to TCP ECN feedback, for exampl= e: >>>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>>>>>> Latency >>>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn= ], >>>>>>>>>> or >>>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>> >>>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this paragra= ph >>>>>>>>>> can >>>>>>>>>> just >>>>>>>>> >>>>>>>>> be deleted. If other experiments need more accurate feedback, it = is >>>>>>>>> up >>>>>>>>> to >>>>>>>>> them to explain how they would use this mechanism. This document >>>>>>>>> should >>>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>>> >>>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better to = be >>>>>>>>> explicit >>>>>>>>> about this? >>>>>>>>> >>>>>>>>>> It is likely (but not required) that the AccECN protocol will = be >>>>>>>>>> implemented along with the following experimental additions to >>>>>>>>>> the >>>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>>> retransmissions >>>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capabl= e >>>>>>>>>> SYN/ >>>>>>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>> >>>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my view, >>>>>>>>>> the >>>>>>>>>> TCPM >>>>>>>>> >>>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>>>> draft-ietf- >>>>>>>>> tcpm-generalized-ecn independent documents, which probably implie= s >>>>>>>>> that >>>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If >>>>>>>>> experimentation >>>>>>>>> with ECT in SYN requires a combination, this could be done in a >>>>>>>>> new, >>>>>>>>> third >>>>>>>>> document. Apart from having simpler focused documents, this could >>>>>>>>> significantly help later with moving forward documents to standar= ds >>>>>>>>> track. >>>>>>>>> >>>>>>>>> I disagree, however, this is a discussion to have on >>>>>>>>> draft-ietf-tcpm- >>>>>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing a re= ference >>>>>>>>> here >>>>>>>>> that >>>>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>> >>>>>>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>>>>>> introduction >>>>>>>>> >>>>>>>>> and tutorial text with lot's of redundancy towards other document= s. >>>>>>>>> I >>>>>>>>> think >>>>>>>>> the document can be made much easier to read by shorten it. In ma= ny >>>>>>>>> cases >>>>>>>>> this is just an editorial change as there is redundancy. As one >>>>>>>>> such >>>>>>>>> example, >>>>>>>>> just remove this section. >>>>>>>>> >>>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan o= f short >>>>>>>>> and >>>>>>>>> concise >>>>>>>>> documents, however, some redundancy can also help understanding, >>>>>>>>> especially if you explain things multiple times but with a >>>>>>>>> different >>>>>>>>> level of >>>>>>>>> detail. I personally would not need the roadmap but I know many >>>>>>>>> people >>>>>>>>> who find these things helpful and to be honest I don=E2=80=99t se= e how >>>>>>>>> removing >>>>>>>>> this >>>>>>>>> part makes the doc any better. If you don=E2=80=99t want it, don= =E2=80=99t read it. >>>>>>>>> >>>>>>>>>> * 1.2. Goals >>>>>>>>>> >>>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>> >>>>>>>>> I have to say I also don=E2=80=99t see the point of removing this= part. >>>>>>>>> Given >>>>>>>>> we=E2=80=99ve >>>>>>>>> done the work on requirements, I think we should also link to thi= s >>>>>>>>> doc >>>>>>>>> somewhere. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>> >>>>>>>>>> TCP is critical to the robust functioning of the Internet, >>>>>>>>>> therefore >>>>>>>>>> any proposed modifications to TCP need to be thoroughly tested= . >>>>>>>>>> The >>>>>>>>>> present specification describes an experimental protocol that >>>>>>>>>> adds >>>>>>>>>> more accurate ECN feedback to the TCP protocol. The intention >>>>>>>>>> is to >>>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>>> implementation can be built in order to test its function, >>>>>>>>>> robustness >>>>>>>>>> and interoperability (with itself and with previous version of >>>>>>>>>> ECN >>>>>>>>>> and TCP). >>>>>>>>>> >>>>>>>>>> [ms] I think all what is written in this paragraph is obvious, n= o? >>>>>>>>>> Can't we just >>>>>>>>> >>>>>>>>> delete this? >>>>>>>>> >>>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. Fo= r me both >>>>>>>>> is >>>>>>>>> fine, keep it >>>>>>>>> or remove it. >>>>>>>>> >>>>>>>>>> The experimental protocol will be considered successful if it = is >>>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] in >>>>>>>>>> the >>>>>>>>>> consensus opinion of the IETF tcpm working group. In short, >>>>>>>>>> this >>>>>>>>>> requires that it improves the accuracy and timeliness of TCP's >>>>>>>>>> ECN >>>>>>>>>> feedback, as claimed in Section 5, while striking a balance >>>>>>>>>> between >>>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>>> minimisation of overhead. It also requires that it is not >>>>>>>>>> unduly >>>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>>> behaviours in the current Internet (e.g. hardware offloading a= nd >>>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>> >>>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>> specified >>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>>>> middleboxes. Therefore experimental verification to confirm >>>>>>>>>> large- >>>>>>>>>> scale path traversal in the Internet is needed before finalizi= ng >>>>>>>>>> this >>>>>>>>>> specification on the Standards Track. >>>>>>>>>> >>>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I have >>>>>>>>> >>>>>>>>> mentioned before, I don't think an RFC should speculate about TCP= M >>>>>>>>> and >>>>>>>>> its >>>>>>>>> consensus opinion. I would suggest a wording along the lines of: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>>> testing confirms that the proposed mechanism can be deployed a= t >>>>>>>>>> large >>>>>>>>> >>>>>>>>> scale. >>>>>>>>>> >>>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>> specified >>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness = of >>>>>>>>>> these strategies depends on the actual deployment situation of >>>>>>>>>> middleboxes. Therefore experimental verification to confirm >>>>>>>>>> large- >>>>>>>>>> scale path traversal in the Internet is needed, e.g., by suppo= rt >>>>>>>>>> in >>>>>>>>>> major TCP stacks. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t think= that the >>>>>>>>> paraphrase >>>>>>>>> speculates about the consensus of tcpm, in contrast it say tcpm h= as >>>>>>>>> to >>>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>>> sufficiently >>>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the requir= ement >>>>>>>>> draft as >>>>>>>>> this >>>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>> >>>>>>>> My suggested wording uses the expression "can be deployed at large >>>>>>>> scale" >>>>>>>> and I believe this is relevant. >>>>>>>> >>>>>>>> The document already describes in Section 5 how the protocol >>>>>>>> satisfies >>>>>>>> the agreed requirements for a more accurate ECN feedback protocol >>>>>>>> [RFC7560]. >>>>>>>> So, if the TCPM working group publishes this document with the >>>>>>>> content of >>>>>>>> Section 5, I believe the TCPM working group already has reached >>>>>>>> consensus >>>>>>>> that the protocol meets requirements. In addition, it is possible >>>>>>>> that new >>>>>>>> requirements would be identified in future, e.g., as an outcome of >>>>>>>> the >>>>>>>> experiment, and that would obviously have to be considered by TCPM= . >>>>>>>> In that >>>>>>>> case, for the success of the experiment not only RFC 7560 would >>>>>>>> matter, but >>>>>>>> also further requirements. My proposed wording does not have all >>>>>>>> these >>>>>>>> problems. >>>>>>>> >>>>>>>> In a nutshell, I continue to believe that this section has to >>>>>>>> change. >>>>>>> >>>>>>> >>>>>>> Okay, used your proposed wording. You have a point about the >>>>>>> requirement >>>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be deployed >>>>>>> large-scale=E2=80=9C. >>>>>>> >>>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>> >>>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>> >>>>>>>>>> The last bit in byte 13 of the TCP header was defined as the >>>>>>>>>> Nonce >>>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never >>>>>>>>>> deployed >>>>>>>>>> so >>>>>>>>>> it is being reclassified as historic, making this TCP flag >>>>>>>>>> available >>>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>> >>>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into accou= nt >>>>>>>>>> the >>>>>>>>>> IANA >>>>>>>>> >>>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>>>>> >>>>>>>>> Is does. However, I can explicitly say that is has be re-clssifie= d >>>>>>>>> as >>>>>>>>> reserved. >>>>>>>>> >>>>>>>>> "RFC 3540 was never deployed so it is being reclassified as >>>>>>>>> historic >>>>>>>>> [I-D.ietf- >>>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been marke= d >>>>>>>>> as >>>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags registry,= making this TCP >>>>>>>>> flag >>>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>> >>>>>>>>> Better? >>>>>>>>> >>>>>>>>>> In my understanding, this experimental document asks for new >>>>>>>>>> assignment >>>>>>>>> >>>>>>>>> of a reserved TCP header flag. >>>>>>>>> >>>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded this di= scussion >>>>>>>>> yet. >>>>>>>>> However, >>>>>>>>> what we really would want to is mention somewhere that this >>>>>>>>> experiment >>>>>>>>> with this flags is running. I guess there are three options: >>>>>>>>> 1) keep it in the registry as reserved and conserve the knowledge >>>>>>>>> in >>>>>>>>> tcpm >>>>>>>>> that this experiment is running and no other experimental RFC suc= h >>>>>>>>> use >>>>>>>>> this >>>>>>>>> flags as long as this experiment is running. >>>>>>>>> 2) Keep is marked as reserved but add a note about this experimen= t >>>>>>>>> in >>>>>>>>> the >>>>>>>>> IANA registry >>>>>>>>> 3) Or assign it right away with IESG approval. I guess in this ca= se >>>>>>>>> tcpm >>>>>>>>> could >>>>>>>>> also consider to change the registration policy to =E2=80=9EIETF = Review=E2=80=9C. >>>>>>>> >>>>>>>> The current registration policy for the TCP header flags is >>>>>>>> "standards >>>>>>>> action". I understand that the IESG could approve exceptions. But >>>>>>>> given the >>>>>>>> policy, I believe the document has to be very precise on the reque= st >>>>>>>> regarding bit 7. >>>>>>> >>>>>>> Okay, it now says: >>>>>>> >>>>>>> "[TO BE REMOVED: IANA is requested to update the existing entry in >>>>>>> the >>>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>>> >>>>>>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags= .xhtml#tcp-header-flags-1) >>>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as NS >>>>>>> (Nonce >>>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-be >>>>>>> instead >>>>>>> of RFC8311.]=E2=80=9C >>>>>>> >>>>>>> I guess we could also ask IANA to add an additional comment column >>>>>>> instead >>>>>>> (but not sure if we then have to update RFC3168, which I think we >>>>>>> really >>>>>>> don=E2=80=99t want. Should be fine now. >>>>>>> >>>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>> >>>>>>>>>> o an essential part that re-uses ECN TCP header bits to feed >>>>>>>>>> back >>>>>>>>>> the number of arriving CE marked packets. This provides mo= re >>>>>>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>>>>>> against >>>>>>>>>> ACK loss; >>>>>>>>>> >>>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>> >>>>>>>>> I think this is nit picking. Using a different phrasing here make= s >>>>>>>>> the >>>>>>>>> sentence >>>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how get a r= ound the >>>>>>>>> fact >>>>>>>>> that we need to handle the flag registration correctly. However, >>>>>>>>> here >>>>>>>>> the >>>>>>>>> point really is to explain how the protocol word. The main point = of >>>>>>>>> using the >>>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that the= se flags are or >>>>>>>>> have >>>>>>>>> been >>>>>>>>> used different by other TCP extension (and we therefore need a >>>>>>>>> proper >>>>>>>>> negotiation scheme). >>>>>>>> >>>>>>>> If the allocation of a reserved flag is correctly explained in the >>>>>>>> abstract and introduction, I think these sentences can use a bit >>>>>>>> relaxed >>>>>>>> terminology. >>>>>>>> >>>>>>>>>> The two part design was necessary, given limitations on the >>>>>>>>>> space >>>>>>>>>> available for TCP options and given the possibility that certa= in >>>>>>>>>> incorrectly designed middleboxes prevent TCP using any new >>>>>>>>>> options > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > From nobody Fri Jul 13 11:54:03 2018 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 4405B130F27; Fri, 13 Jul 2018 11:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3NR-vz5XPOEb; Fri, 13 Jul 2018 11:53:57 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104B512F1A5; Fri, 13 Jul 2018 11:53:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41S25b1vzFz15NTD; Fri, 13 Jul 2018 20:53:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8UlQGlyZwwr; Fri, 13 Jul 2018 20:53:53 +0200 (CEST) X-MtScore: NO score=0 Received: from [172.20.4.114] (unknown [207.96.227.254]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Jul 2018 20:53:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 13 Jul 2018 14:53:48 -0400 Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 18:54:03 -0000 Hi Yucheng, please see below. > Am 13.07.2018 um 14:38 schrieb Yuchung Cheng : >=20 > hi -- >=20 > I agree: > 1. delayed/streched ACK aren't going away (in fact will be more = common) > 2. GRO isn't and should not be a show-stopper > 3. SYN option is running tight > 4. HW opt comes after SW >=20 > I worry: > 1. GRO is a unavoidable issue in deployment (let's not produce an > undeployable RFC). the ACE counter won't work as GRO can pack up to > 64KB/MTU =3D~ 45 pkts under heavy congestion. >=20 > 2. ACE's benefit over DCTCP is when delayed ACKs and ack losses > happen. Now delayed ACKs happen frequently when the messages are > small, which means they don't solicit too many ACKs to be dropped in > the reverse path. Also that under heavy downstream loss or reordering, >=20 > 3 SACK options become dominant to have ACE option. >=20 > 4. If SYN option space is a concern, ACE header exchange is ok. But I > suspect the latter has more middlebox issue based on my TFO deployment > experience. >=20 >=20 > So with all that said, is it possible to have a "minimal"-ACE that > 1. Does ACE handshake as proposed > 2. Mark ECT on all (or at least SYN & data & rtx) packets like ECN++ This is ECN++ and independent of AccECN. We on purposed have split the = feedback and usage of ECN (which is not the case in RFC3168) to be able = to change things in future independently > 3. Leave ACE-count and ACE option optional (i.e. MAY) I don=E2=80=99t understand this. If both is optional, you don=E2=80=99t = have any feedback. Or what do you mean by =E2=80=9Eleave ACE-count = optional=E2=80=9C? Mirja >=20 > as a "fairly safe" to deployment compromise. And I am happy to draft a > kernel patch for that :-) >=20 >=20 >=20 > On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe = wrote: >> Yuchung, >>=20 >> On 12/07/18 17:03, Mirja K=C3=BChlewind wrote: >>>=20 >>> Hi Yuchung, >>>=20 >>> please see below. >>>=20 >>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>>>=20 >>>> Yes packets with ACE options and (different) ACE-counter header = would >>>> break GRO. There're many legacy h/w and s/w. >>>=20 >>> I=E2=80=99m not the expert here but my understanding is that is = would not break >>> GRO but could not make actual use or it if the ACE counter changed = or the >>> option is present. >>=20 >> [BB] Yuchung's criticism applies to any scheme that feeds back a = continually >> changing signal like ECN. For instance, like AccECN feedback, DCTCP = ECN >> feedback continually changes the TCP header flags, and I believe = DCTCP is >> widely used in DCs. >>=20 >> I believe, to make GRO support ECN feedback (whether DCTCP or = AccECN), it >> would be necessary for GRO to know which bits to mask when = determining >> whether a packet is mergeable with others. I believe GRO already = collects >> header fields separately for the TCP logic to be able to work on = them, but >> I'm also not an expert. >>>=20 >>> However, usually your will only have a small number of CE marks = every >>> couple of RTTs, and the counter only changes if you CE marks/the = option is >>> only present a few times per RTT. So the impact should be rather = low. But >>> this clear something to evaluate for the experiment. >>=20 >> [BB] With DCTCP as currently designed, you tend to get runs of 100% = CE if >> the load of short flows is very small. In that case, DCTCP feedback = will >> change the header flags less often than AccECN. However, with more = short >> flows, the feedback is more on-off. Then the flags change more often = with >> DCTCP than with AccECN feedback. >>=20 >> In general, hardware optimization is not going to optimize a protocol = that >> didn't exist when the hardware was designed. It would be ideal to = design a >> new protocol that takes advantage of existing hardware optimization. >> However, as long as an experimental protocol still works with = existing >> hardware, I think it's reasonable to assume that hardware = optimization will >> only arrive once a protocol has become well-established. >>=20 >>>=20 >>>> Even without option, ACE header only allows reflecting up to 8 = packets >>>> for receiver segmentation offload and ACK suppression? >>>=20 >>> Same as above, it can only up to 8 CE marked packets per ACK, = however, CE >>> marking rater are expected to be rather low. ACK suppression should = probably >>> not be used if the ACE counter has changes, however, usually the ACE = counter >>> stays stable for multiple RTTs and then ACK suppression is not a = problem. >>> However, not sure I understood you question here correctly=E2=80=A6? >>>=20 >>>> The appendix on ack loss causes ambiguity is good: but the pattern >>>> drops specifically the state-switch (CE<->noCE) ACK which only = happens >>>> on delayed ACK. Is that pattern common? - or can we address most of >>>> that by delaying less ACKs? >>>=20 >>> I guess you have a 50% chance today to hit a delayed ACK. I guess = delaying >>> less (where you delay every second ACK today) would mean ACK every = packet, >>> and thus double ACK load on the network. I guess on today networks = that >>> actually in most cases not a problem, however, there might be = specially >>> cases where it is. However, that=E2=80=99s problem an independent = question to >>> evaluate. >>=20 >> [BB] If there were no delayed ACKs, the problem with DCTCP feedback = would >> largely disappear. But delayed ACKs are not going away. Which is why = we >> proposed replacing DCTCP feedback with AccECN feedback. >>>=20 >>>=20 >>>> I am all for making ECN more accurate for wide area beyond DCTCP, = but >>>> am evaluating the pros/cons. What if we just >>>> 1. negotiate 'better' ECN via new SYN option >>>=20 >>> Not sure I understand your proposal correctly, but I assume you mean >>> negotiate via SYN option and then just use the ACE counter in the = header? If >>> so, I don=E2=80=99t understand why you see the negotiation part in = the TCP header as >>> the problem? >>=20 >> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a = solution >> without a problem. In fact an option on the SYN would create a new = problem >> 'cos of the severe shortage of space for SYN options (for this = reason, the >> AccECN TCP option was designed not to be needed on the SYN). >>>=20 >>>=20 >>>> 2. mark all packets like ECN++ >>>=20 >>> That would be nice but here you actually need AccECN because you = want to >>> have feedback for control packets as well. AccECN is providing this >>> feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; = that=E2=80=99s what we have ECN++ >>> for; both thing ideally would be deployed together however. Was that = your >>> questions? >>=20 >> Cheers >>=20 >>=20 >> Bob >>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind >>>> wrote: >>>>>=20 >>>>> Hi Yuchung, >>>>>=20 >>>>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy = really depends on the >>>>> use case. If you use DCTCP as today, the ACE counter in the TCP is = probably >>>>> sufficient and you might not want to pay the additional overhead = in your >>>>> data center (that why the option is actually optional). >>>>>=20 >>>>> If you however, e.g., have very differently sized packets, then = the byte >>>>> counter in the option could give you a more accurate signal. Or if = you are >>>>> also interested in the ECT(1) counter, you need the option. = Further the ACE >>>>> counter also give your feedback on control packet and the option = enables you >>>>> to distinguish between CE-amrked payload and control packets, = which can also >>>>> become important when experimenting with making all packets = ECN-capable. >>>>>=20 >>>>> Given accECN is a general feedback mechanism that in fact is = designed to >>>>> enable new future uses of the ECN signal, we wanted to keep all = these option >>>>> available while making is still as simple as possible and as = flexible as >>>>> possible. >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>>>>=20 >>>>>> Hi Bob, >>>>>>=20 >>>>>> Neal and I evaluated the earlier draft. It is well-thought out = but >>>>>> we're concerned about the options. Option is not mandatory but = the >>>>>> lack of it also reduces accuracy. Option runs into space issues = w/ >>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for = sure but >>>>>> aren't easy. >>>>>>=20 >>>>>> We're curious how much more "accuracy" it buys over current >>>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe = >>>>>> wrote: >>>>>>>=20 >>>>>>> Michael, tcpm list, >>>>>>>=20 >>>>>>> As well as addressing your points, as Mirja has already = mentioned >>>>>>> below, we >>>>>>> added a whole new appendix giving the rationale for the bits and >>>>>>> codepoints >>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A = 3rd >>>>>>> subsection also identifies space for future evolution. It also = points >>>>>>> to >>>>>>> where rationale was already given in the body of the draft. >>>>>>>=20 >>>>>>> The appendix is in the draft submitted last week, available = here: >>>>>>> = https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>>>>>>=20 >>>>>>> We'd be interested to hear whether this allays your concerns. >>>>>>>=20 >>>>>>> We have asked to present this in Montreal as well. >>>>>>>=20 >>>>>>> Cheers >>>>>>>=20 >>>>>>>=20 >>>>>>> Bob >>>>>>>=20 >>>>>>>=20 >>>>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>>>=20 >>>>>>>> Hi Micheal, >>>>>>>>=20 >>>>>>>> I addressed a couple of your comments below. >>>>>>>>=20 >>>>>>>> For the other, bigger comments regarding extensibility, that I = did >>>>>>>> not yet >>>>>>>> address below, we plan to add a new section to the appendix to >>>>>>>> explain >>>>>>>> extensibility options as previously discussed by mail. We will >>>>>>>> probably send >>>>>>>> a separate email on that part. >>>>>>>>=20 >>>>>>>> Mirja >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>>> DE/Stuttgart) >>>>>>>>> : >>>>>>>>>=20 >>>>>>>>> Hi Mirja, >>>>>>>>>=20 >>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some of = the >>>>>>>>> editorial suggestions. >>>>>>>>>=20 >>>>>>>>> Yet, I continue to believe that some formal wording in the = document >>>>>>>>> needs >>>>>>>>> to change, as explained below. >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>>=20 >>>>>>>>> Michael (with no hat on) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Mirja K=C3=BChlewind = [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>>> >>>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>>>=20 >>>>>>>>>> Hi Micheal, >>>>>>>>>>=20 >>>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>>>=20 >>>>>>>>>> Please see inline. >>>>>>>>>>=20 >>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>=20 >>>>>>>>>> : >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>>> appendix). I >>>>>>>>>>=20 >>>>>>>>>> believe this document needs further work before moving = forward. >>>>>>>>>>>=20 >>>>>>>>>>> Please find below my comments marked as [ms]. I have read = the >>>>>>>>>>=20 >>>>>>>>>> document independent of the review from Gorry. I apologize if = there >>>>>>>>>> is >>>>>>>>>> duplication. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks >>>>>>>>>>>=20 >>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ****************************** >>>>>>>>>>>=20 >>>>>>>>>>> * Abstract: >>>>>>>>>>>=20 >>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure = (ConEx) or >>>>>>>>>>> Data >>>>>>>>>>=20 >>>>>>>>>> Center TCP >>>>>>>>>>>=20 >>>>>>>>>>> (DCTCP) need more accurate ECN feedback information = whenever >>>>>>>>>>> more >>>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC = 8257. I >>>>>>>>>>> suggest to >>>>>>>>>>=20 >>>>>>>>>> remove this, or replace it by a more generic statement that = more >>>>>>>>>> accurate >>>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>>>=20 >>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate = information. >>>>>>>>>> They do >>>>>>>>>> not need the mechanism that is specified in this draft, = however, >>>>>>>>>> this is >>>>>>>>>> not >>>>>>>>>> what the sentences is saying. >>>>>>>>>=20 >>>>>>>>> In my understanding (as a non-native speaker), the use of the = word >>>>>>>>> "need" >>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>>> implemented >>>>>>>>> without any such mechanism. >>>>>>>>>=20 >>>>>>>>> What would work for me is something of the form "... Data = Center TCP >>>>>>>>> cannot get precise ECN feedback whenever more than one marking = is >>>>>>>>> received >>>>>>>>> in one RTT=E2=80=9C. >>>>>>>>=20 >>>>>>>> This is not correct. DCTP need more than one feedback signal = per RTT >>>>>>>> and >>>>>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s = own feedback >>>>>>>> mechanism. However, to avoid confusion such that people could = assume >>>>>>>> DCTP >>>>>>>> would not work without the accECN scheme as specified in this = doc, I >>>>>>>> rephrased to: >>>>>>>>=20 >>>>>>>> "Recently, proposed >>>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>>> target=3D"RFC7713"/>), >>>>>>>> DCTCP or L4S >>>>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when = more than >>>>>>>> one >>>>>>>> marking is received in one RTT which is >>>>>>>> information that cannot be provided by the feedback scheme = as >>>>>>>> specified in >>>>>>>> ." >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> This document specifies an >>>>>>>>>>> experimental scheme to provide more than one feedback = signal per >>>>>>>>>>> RTT >>>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>>> overloads >>>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>>> provides >>>>>>>>>>> additional information in a new TCP option. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] This statement needs to be rewritten to correctly = reflect >>>>>>>>>>> what is >>>>>>>>>>=20 >>>>>>>>>> requested from IANA. My understanding is that this = experimental >>>>>>>>>> document >>>>>>>>>> asks for allocation of a reserved TCP header flag. This needs = to be >>>>>>>>>> called out >>>>>>>>>> prominently, IMHO. In addition, since this is not a standard, = the >>>>>>>>>> suggested >>>>>>>>>> experimentation with the main TCP header must IMHO be = explicitly >>>>>>>>>> mentioned. I also suggest to have later in a document a = section >>>>>>>>>> that >>>>>>>>>> explicitly >>>>>>>>>> explains why it is appropriate to modify the main TCP header = in an >>>>>>>>>> experiment. >>>>>>>>>>=20 >>>>>>>>>> I don=E2=80=99t know if any requirement that IANA assignment = need to be >>>>>>>>>> called >>>>>>>>>> out >>>>>>>>>> in the abstract but we can do that. However, I believe the = question >>>>>>>>>> if >>>>>>>>>> this >>>>>>>>>> document should or should not assign the bit is still not >>>>>>>>>> completely >>>>>>>>>> solved, or >>>>>>>>>> is it? >>>>>>>>>=20 >>>>>>>>> I believe this question will have to be reviewed during WGLC = and, >>>>>>>>> more >>>>>>>>> importantly, IETF last call. For the moment, my concern is = that the >>>>>>>>> document >>>>>>>>> correctly describes the IANA allocation. >>>>>>>>>=20 >>>>>>>>> I would like to see here a statement such as : "Given TCP = header >>>>>>>>> space is >>>>>>>>> scarce, this specification allocates a reserved header bit and >>>>>>>>> overloads the >>>>>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>>>>=20 >>>>>>>> A bit lengthy but now: >>>>>>>>=20 >>>>>>>> "Given TCP header space is >>>>>>>> scarce, it allocates a reserved header bit, that was = previously >>>>>>>> used for >>>>>>>> ECN-Nonce which was recently declared historic, and = overloads >>>>>>>> the >>>>>>>> two existing ECN flags in the TCP header. Further, = additional >>>>>>>> information can be provided in a new TCP option that = however is >>>>>>>> not >>>>>>>> used >>>>>>>> on the TCP SYN." >>>>>>>>=20 >>>>>>>>>>> * 1. Introduction >>>>>>>>>>>=20 >>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure = (ConEx >>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S = [I-D.ietf-tsvwg-l4s-arch] >>>>>>>>>>> need >>>>>>>>>>> more accurate ECN feedback information whenever more than = one >>>>>>>>>>=20 >>>>>>>>>> marking >>>>>>>>>>>=20 >>>>>>>>>>> is received in one RTT. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit = this. >>>>>>>>>>> Instead >>>>>>>>>>=20 >>>>>>>>>> of stating a "need", it would IMHO make more sense to discuss = the >>>>>>>>>> benefits >>>>>>>>>> of the suggested mechanism in this document of its own, = independent >>>>>>>>>> of >>>>>>>>>> other proposals. To me, this document should be independent = of >>>>>>>>>> other >>>>>>>>>> documents and specifically other experiments. We have to = think >>>>>>>>>> about >>>>>>>>>> cases >>>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>>> documents >>>>>>>>>> will >>>>>>>>>> be more future-proof in future. >>>>>>>>>>=20 >>>>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant to = say that >>>>>>>>>> these >>>>>>>>>> mechanisms new more accurate ECN feedback than provided today = by >>>>>>>>>> RFC3168 but it was not meant to say that these mechanism have = to >>>>>>>>>> use the >>>>>>>>>> scheme as specified in this document. >>>>>>>>>>=20 >>>>>>>>>> I added the following part sentence: >>>>>>>>>>=20 >>>>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion = Exposure (ConEx >>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] = need >>>>>>>>>> more >>>>>>>>>> accurate ECN feedback information than provided by the = feedback >>>>>>>>>> scheme >>>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>>> received in >>>>>>>>>> one >>>>>>>>>> RTT. This document specifies an alternative feedback scheme = that >>>>>>>>>> provides >>>>>>>>>> more accurate information and could be used by these new TCP >>>>>>>>>> extensions.=E2=80=9C >>>>>>>>>>=20 >>>>>>>>>> Does this help? >>>>>>>>>=20 >>>>>>>>> See my proposal for the abstract. I continue to disagree with = the >>>>>>>>> term >>>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>>>=20 >>>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>>> track, it is intended to be a complete replacement for = classic >>>>>>>>>>> TCP/ >>>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] This sentence should be removed, as this is = speculation. >>>>>>>>>>=20 >>>>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the = intent that we have. >>>>>>>>>>=20 >>>>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain = as >>>>>>>>>>> the >>>>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>>>=20 >>>>>>>>>> Why? Does it help to add an only here: >>>>>>>>>>=20 >>>>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain = as the >>>>>>>>>> only >>>>>>>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>>>>>>=20 >>>>>>>>> This wording is better. >>>>>>>>>=20 >>>>>>>>>>> AccECN feedback overloads flags and fields in the main TCP >>>>>>>>>>> header >>>>>>>>>>> with new definitions, so both ends have to support the new = wire >>>>>>>>>>> protocol before it can be used. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] In my reading this experimental document asks for *new* >>>>>>>>>>> allocation >>>>>>>>>>=20 >>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>=20 >>>>>>>>>> Is this better? >>>>>>>>>>=20 >>>>>>>>>> "AccECN feedback overloads the two existing ECN flags as well = as >>>>>>>>>> the >>>>>>>>>> currently reserved and previously called NS flag in the = main >>>>>>>>>> TCP >>>>>>>>>> header >>>>>>>>>> with new definitions, so both ends have to support the = new >>>>>>>>>> wire >>>>>>>>>> protocol >>>>>>>>>> before it can be used.=E2=80=9C >>>>>>>>>>=20 >>>>>>>>>> I understand that you are not happy with the word = =E2=80=9Eoverload=E2=80=9C here >>>>>>>>>> but >>>>>>>>>> the >>>>>>>>>> point of this sentence really is that the flags can/could be = used >>>>>>>>>> differently >>>>>>>>>> and therefore we need a new negotiation before we can use = them. >>>>>>>>>=20 >>>>>>>>> For me the following would work: "AccECN feedback overloads = the two >>>>>>>>> existing ECN flags and >>>>>>>>> allocates the currently reserved and previously called NS flag = in >>>>>>>>> the >>>>>>>>> main TCP header. >>>>>>>>> Given the new definitions, both ends have to support the new = wire >>>>>>>>> protocol >>>>>>>>> before it can be used." >>>>>>>>>=20 >>>>>>>>> I believe the wording has to be crystal clear on the = reservation of >>>>>>>>> bit 7 >>>>>>>>> when it is discussed the first time in the text. In follow-up >>>>>>>>> sections, >>>>>>>>> maybe shorter terms could be used. >>>>>>>>=20 >>>>>>>> Okay, now: >>>>>>>>=20 >>>>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>>>> allocates the currently reserved and previously called NS = flag in >>>>>>>> the >>>>>>>> TCP header, to be used as one field indicating the number of >>>>>>>> congestion >>>>>>>> experienced marked packets. Given the new definitions of = these >>>>>>>> three >>>>>>>> bits, >>>>>>>> both ends have to support the new wire protocol before = it can >>>>>>>> be >>>>>>>> used. >>>>>>>> Therefore during the TCP handshake the two ends use these = three >>>>>>>> bit >>>>>>>> in >>>>>>>> the TCP header to negotiate the most advanced feedback = protocol >>>>>>>> that they can both support in a backward compatible way to >>>>>>>> ." >>>>>>>>>>=20 >>>>>>>>>> If you prefer, we can also remove the NS flag in this list, = as ECN >>>>>>>>>> Nonce >>>>>>>>>> was >>>>>>>>>> anyway never deployed. >>>>>>>>>>=20 >>>>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>>>> specifies a different response to TCP ECN feedback, for = example: >>>>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based = Low >>>>>>>>>>> Latency >>>>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>>>> ECN-capable TCP control packets = [I-D.ietf-tcpm-generalized-ecn], >>>>>>>>>>> or >>>>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this = paragraph >>>>>>>>>>> can >>>>>>>>>>> just >>>>>>>>>>=20 >>>>>>>>>> be deleted. If other experiments need more accurate feedback, = it is >>>>>>>>>> up >>>>>>>>>> to >>>>>>>>>> them to explain how they would use this mechanism. This = document >>>>>>>>>> should >>>>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>>>>=20 >>>>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better = to be >>>>>>>>>> explicit >>>>>>>>>> about this? >>>>>>>>>>=20 >>>>>>>>>>> It is likely (but not required) that the AccECN protocol = will be >>>>>>>>>>> implemented along with the following experimental additions = to >>>>>>>>>>> the >>>>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>>>> retransmissions >>>>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the = ECN-capable >>>>>>>>>>> SYN/ >>>>>>>>>>> ACK experiment [RFC5562]; and testing receiver = non-compliance >>>>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my = view, >>>>>>>>>>> the >>>>>>>>>>> TCPM >>>>>>>>>>=20 >>>>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>>>>> draft-ietf- >>>>>>>>>> tcpm-generalized-ecn independent documents, which probably = implies >>>>>>>>>> that >>>>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If >>>>>>>>>> experimentation >>>>>>>>>> with ECT in SYN requires a combination, this could be done in = a >>>>>>>>>> new, >>>>>>>>>> third >>>>>>>>>> document. Apart from having simpler focused documents, this = could >>>>>>>>>> significantly help later with moving forward documents to = standards >>>>>>>>>> track. >>>>>>>>>>=20 >>>>>>>>>> I disagree, however, this is a discussion to have on >>>>>>>>>> draft-ietf-tcpm- >>>>>>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing = a reference >>>>>>>>>> here >>>>>>>>>> that >>>>>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing = more. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>>>=20 >>>>>>>>>>> [ms] A macroscopic comment is that this document has a lot = of >>>>>>>>>>> introduction >>>>>>>>>>=20 >>>>>>>>>> and tutorial text with lot's of redundancy towards other = documents. >>>>>>>>>> I >>>>>>>>>> think >>>>>>>>>> the document can be made much easier to read by shorten it. = In many >>>>>>>>>> cases >>>>>>>>>> this is just an editorial change as there is redundancy. As = one >>>>>>>>>> such >>>>>>>>>> example, >>>>>>>>>> just remove this section. >>>>>>>>>>=20 >>>>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big = fan of short >>>>>>>>>> and >>>>>>>>>> concise >>>>>>>>>> documents, however, some redundancy can also help = understanding, >>>>>>>>>> especially if you explain things multiple times but with a >>>>>>>>>> different >>>>>>>>>> level of >>>>>>>>>> detail. I personally would not need the roadmap but I know = many >>>>>>>>>> people >>>>>>>>>> who find these things helpful and to be honest I don=E2=80=99t = see how >>>>>>>>>> removing >>>>>>>>>> this >>>>>>>>>> part makes the doc any better. If you don=E2=80=99t want it, = don=E2=80=99t read it. >>>>>>>>>>=20 >>>>>>>>>>> * 1.2. Goals >>>>>>>>>>>=20 >>>>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>>>=20 >>>>>>>>>> I have to say I also don=E2=80=99t see the point of removing = this part. >>>>>>>>>> Given >>>>>>>>>> we=E2=80=99ve >>>>>>>>>> done the work on requirements, I think we should also link to = this >>>>>>>>>> doc >>>>>>>>>> somewhere. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>>>=20 >>>>>>>>>>> TCP is critical to the robust functioning of the Internet, >>>>>>>>>>> therefore >>>>>>>>>>> any proposed modifications to TCP need to be thoroughly = tested. >>>>>>>>>>> The >>>>>>>>>>> present specification describes an experimental protocol = that >>>>>>>>>>> adds >>>>>>>>>>> more accurate ECN feedback to the TCP protocol. The = intention >>>>>>>>>>> is to >>>>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>>>> implementation can be built in order to test its function, >>>>>>>>>>> robustness >>>>>>>>>>> and interoperability (with itself and with previous version = of >>>>>>>>>>> ECN >>>>>>>>>>> and TCP). >>>>>>>>>>>=20 >>>>>>>>>>> [ms] I think all what is written in this paragraph is = obvious, no? >>>>>>>>>>> Can't we just >>>>>>>>>>=20 >>>>>>>>>> delete this? >>>>>>>>>>=20 >>>>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it = out. For me both >>>>>>>>>> is >>>>>>>>>> fine, keep it >>>>>>>>>> or remove it. >>>>>>>>>>=20 >>>>>>>>>>> The experimental protocol will be considered successful if = it is >>>>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] = in >>>>>>>>>>> the >>>>>>>>>>> consensus opinion of the IETF tcpm working group. In = short, >>>>>>>>>>> this >>>>>>>>>>> requires that it improves the accuracy and timeliness of = TCP's >>>>>>>>>>> ECN >>>>>>>>>>> feedback, as claimed in Section 5, while striking a balance >>>>>>>>>>> between >>>>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>>>> minimisation of overhead. It also requires that it is not >>>>>>>>>>> unduly >>>>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>>>> behaviours in the current Internet (e.g. hardware = offloading and >>>>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>>>=20 >>>>>>>>>>> Testing will mostly focus on fall-back strategies in case = of >>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>> specified >>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The = effectiveness of >>>>>>>>>>> these strategies depends on the actual deployment situation = of >>>>>>>>>>> middleboxes. Therefore experimental verification to = confirm >>>>>>>>>>> large- >>>>>>>>>>> scale path traversal in the Internet is needed before = finalizing >>>>>>>>>>> this >>>>>>>>>>> specification on the Standards Track. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I = have >>>>>>>>>>=20 >>>>>>>>>> mentioned before, I don't think an RFC should speculate about = TCPM >>>>>>>>>> and >>>>>>>>>> its >>>>>>>>>> consensus opinion. I would suggest a wording along the lines = of: >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>>>> testing confirms that the proposed mechanism can be = deployed at >>>>>>>>>>> large >>>>>>>>>>=20 >>>>>>>>>> scale. >>>>>>>>>>>=20 >>>>>>>>>>> Testing will mostly focus on fall-back strategies in case = of >>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>> specified >>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The = effectiveness of >>>>>>>>>>> these strategies depends on the actual deployment situation = of >>>>>>>>>>> middleboxes. Therefore experimental verification to = confirm >>>>>>>>>>> large- >>>>>>>>>>> scale path traversal in the Internet is needed, e.g., by = support >>>>>>>>>>> in >>>>>>>>>>> major TCP stacks. >>>>>>>>>>> >>>>>>>>>>>=20 >>>>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t = think that the >>>>>>>>>> paraphrase >>>>>>>>>> speculates about the consensus of tcpm, in contrast it say = tcpm has >>>>>>>>>> to >>>>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>>>> sufficiently >>>>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the = requirement >>>>>>>>>> draft as >>>>>>>>>> this >>>>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>>>=20 >>>>>>>>> My suggested wording uses the expression "can be deployed at = large >>>>>>>>> scale" >>>>>>>>> and I believe this is relevant. >>>>>>>>>=20 >>>>>>>>> The document already describes in Section 5 how the protocol >>>>>>>>> satisfies >>>>>>>>> the agreed requirements for a more accurate ECN feedback = protocol >>>>>>>>> [RFC7560]. >>>>>>>>> So, if the TCPM working group publishes this document with the >>>>>>>>> content of >>>>>>>>> Section 5, I believe the TCPM working group already has = reached >>>>>>>>> consensus >>>>>>>>> that the protocol meets requirements. In addition, it is = possible >>>>>>>>> that new >>>>>>>>> requirements would be identified in future, e.g., as an = outcome of >>>>>>>>> the >>>>>>>>> experiment, and that would obviously have to be considered by = TCPM. >>>>>>>>> In that >>>>>>>>> case, for the success of the experiment not only RFC 7560 = would >>>>>>>>> matter, but >>>>>>>>> also further requirements. My proposed wording does not have = all >>>>>>>>> these >>>>>>>>> problems. >>>>>>>>>=20 >>>>>>>>> In a nutshell, I continue to believe that this section has to >>>>>>>>> change. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Okay, used your proposed wording. You have a point about the >>>>>>>> requirement >>>>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be = deployed >>>>>>>> large-scale=E2=80=9C. >>>>>>>>=20 >>>>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>>>=20 >>>>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>>>=20 >>>>>>>>>>> The last bit in byte 13 of the TCP header was defined as = the >>>>>>>>>>> Nonce >>>>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never >>>>>>>>>>> deployed >>>>>>>>>>> so >>>>>>>>>>> it is being reclassified as historic, making this TCP flag >>>>>>>>>>> available >>>>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>>>=20 >>>>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into = account >>>>>>>>>>> the >>>>>>>>>>> IANA >>>>>>>>>>=20 >>>>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is = published. >>>>>>>>>>=20 >>>>>>>>>> Is does. However, I can explicitly say that is has be = re-clssified >>>>>>>>>> as >>>>>>>>>> reserved. >>>>>>>>>>=20 >>>>>>>>>> "RFC 3540 was never deployed so it is being reclassified as >>>>>>>>>> historic >>>>>>>>>> [I-D.ietf- >>>>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been = marked >>>>>>>>>> as >>>>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags = registry, making this TCP >>>>>>>>>> flag >>>>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>>>=20 >>>>>>>>>> Better? >>>>>>>>>>=20 >>>>>>>>>>> In my understanding, this experimental document asks for new >>>>>>>>>>> assignment >>>>>>>>>>=20 >>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>=20 >>>>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded = this discussion >>>>>>>>>> yet. >>>>>>>>>> However, >>>>>>>>>> what we really would want to is mention somewhere that this >>>>>>>>>> experiment >>>>>>>>>> with this flags is running. I guess there are three options: >>>>>>>>>> 1) keep it in the registry as reserved and conserve the = knowledge >>>>>>>>>> in >>>>>>>>>> tcpm >>>>>>>>>> that this experiment is running and no other experimental RFC = such >>>>>>>>>> use >>>>>>>>>> this >>>>>>>>>> flags as long as this experiment is running. >>>>>>>>>> 2) Keep is marked as reserved but add a note about this = experiment >>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>> IANA registry >>>>>>>>>> 3) Or assign it right away with IESG approval. I guess in = this case >>>>>>>>>> tcpm >>>>>>>>>> could >>>>>>>>>> also consider to change the registration policy to =E2=80=9EIET= F Review=E2=80=9C. >>>>>>>>>=20 >>>>>>>>> The current registration policy for the TCP header flags is >>>>>>>>> "standards >>>>>>>>> action". I understand that the IESG could approve exceptions. = But >>>>>>>>> given the >>>>>>>>> policy, I believe the document has to be very precise on the = request >>>>>>>>> regarding bit 7. >>>>>>>>=20 >>>>>>>> Okay, it now says: >>>>>>>>=20 >>>>>>>> "[TO BE REMOVED: IANA is requested to update the existing entry = in >>>>>>>> the >>>>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>>>>=20 >>>>>>>> = (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#= tcp-header-flags-1) >>>>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as = NS >>>>>>>> (Nonce >>>>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this = RFC-to-be >>>>>>>> instead >>>>>>>> of RFC8311.]=E2=80=9C >>>>>>>>=20 >>>>>>>> I guess we could also ask IANA to add an additional comment = column >>>>>>>> instead >>>>>>>> (but not sure if we then have to update RFC3168, which I think = we >>>>>>>> really >>>>>>>> don=E2=80=99t want. Should be fine now. >>>>>>>>=20 >>>>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>>>=20 >>>>>>>>>>> o an essential part that re-uses ECN TCP header bits to = feed >>>>>>>>>>> back >>>>>>>>>>> the number of arriving CE marked packets. This provides = more >>>>>>>>>>> accuracy than classic ECN feedback, but limited = resilience >>>>>>>>>>> against >>>>>>>>>>> ACK loss; >>>>>>>>>>>=20 >>>>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>>>=20 >>>>>>>>>> I think this is nit picking. Using a different phrasing here = makes >>>>>>>>>> the >>>>>>>>>> sentence >>>>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how get = a round the >>>>>>>>>> fact >>>>>>>>>> that we need to handle the flag registration correctly. = However, >>>>>>>>>> here >>>>>>>>>> the >>>>>>>>>> point really is to explain how the protocol word. The main = point of >>>>>>>>>> using the >>>>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that = these flags are or >>>>>>>>>> have >>>>>>>>>> been >>>>>>>>>> used different by other TCP extension (and we therefore need = a >>>>>>>>>> proper >>>>>>>>>> negotiation scheme). >>>>>>>>>=20 >>>>>>>>> If the allocation of a reserved flag is correctly explained in = the >>>>>>>>> abstract and introduction, I think these sentences can use a = bit >>>>>>>>> relaxed >>>>>>>>> terminology. >>>>>>>>>=20 >>>>>>>>>>> The two part design was necessary, given limitations on the >>>>>>>>>>> space >>>>>>>>>>> available for TCP options and given the possibility that = certain >>>>>>>>>>> incorrectly designed middleboxes prevent TCP using any new >>>>>>>>>>> options >>=20 >>=20 >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >>=20 >=20 From nobody Fri Jul 13 12:31:07 2018 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 8E6FC130F52 for ; Fri, 13 Jul 2018 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 LeayR6TW5v2D for ; Fri, 13 Jul 2018 12:31:00 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 D4D3D130F43 for ; Fri, 13 Jul 2018 12:30:59 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id j185-v6so13052002ite.1 for ; Fri, 13 Jul 2018 12:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=neiC4n1EhdKPD/xcnKMMnpsbVVfi9ptQGADREa+g320=; b=lThU/CvqEJ3knYD0vQascmccP9nk+cBa3dXIFv5nfaotZoxWKREl2TVRNWOZco5voB I8gHNOGwxNTPh7vsLoCjFnkxCMkgXEE4cUcsODJU685Lr9Lo9UYl56hMgDL9R8LBNvt7 7e/ltyJTQVtA50V4l1yRzpqxIuy6QWD4fHyDchQQGCpjaTpYZC833QI2vhyiPzTOUkUO iV3T5HikCgYko4Crq+105xuCKNj4b21D9l4JsWYcPkUCt/PGPWy4GSOsk4Qm4KkoXUD1 vUtdtNP/o6MDONCEhaYHV6lRI053F/onXv2YpxjPXkXyiAIz8JipYAzMnClV47HcAPqI IG6g== 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:content-transfer-encoding; bh=neiC4n1EhdKPD/xcnKMMnpsbVVfi9ptQGADREa+g320=; b=iD/0bqY3/UjGp9tHhUr6u8Op/fWRK0eH0/YmKWFgr3gM55sKoy4V+Odn3ga2SZrHFh 2YP0Y0CpV4x5PhID7NvczGksI9NRIKzyiY7qq1nu8mSf+rCGSWgwACre7GN9ci0OTcp8 KL+8b2B+qeuFLEOXpD81L+8KpPZz20KNAwodx2FTn08zcWZjn9cwBOy1dnJtAaR0z30w TpmVZTrVx6Vvt3tbviWRxKJcxZA8I8AxsSw7txDIah6XTjw/HPJABk0IcY95Uv3vFUXN wBBJYuzBmsIn4goqdZK605BkZlKa+3/oCd2sx+/PhFp9eZgePgrH//G3tT2/VBx3wmsP TxXA== X-Gm-Message-State: AOUpUlE2z9FRdzRzvvso1d+sZHiay84MXaOIt+hu6WcShyEGnETFWD+y wtmBZlGt/J8Ru3i8fuj9jm99ZCEckCiUHVSVm8Mwng== X-Google-Smtp-Source: AAOMgpeHrPNK5GCtlU7NW0iDYWC+vVx88w4w6PJgo3VB/cvWnrs83+stFuXulwDRq5wB2IYequUVdL/w9btbmlRDkUM= X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr6050208itb.45.1531510258531; Fri, 13 Jul 2018 12:30:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5e:c10d:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 12:30:17 -0700 (PDT) In-Reply-To: <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> From: Yuchung Cheng Date: Fri, 13 Jul 2018 12:30:17 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 19:31:06 -0000 On Fri, Jul 13, 2018 at 11:53 AM, Mirja K=C3=BChlewind wrote: > Hi Yucheng, > > please see below. > >> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng : >> >> hi -- >> >> I agree: >> 1. delayed/streched ACK aren't going away (in fact will be more common) >> 2. GRO isn't and should not be a show-stopper >> 3. SYN option is running tight >> 4. HW opt comes after SW >> >> I worry: >> 1. GRO is a unavoidable issue in deployment (let's not produce an >> undeployable RFC). the ACE counter won't work as GRO can pack up to >> 64KB/MTU =3D~ 45 pkts under heavy congestion. >> >> 2. ACE's benefit over DCTCP is when delayed ACKs and ack losses >> happen. Now delayed ACKs happen frequently when the messages are >> small, which means they don't solicit too many ACKs to be dropped in >> the reverse path. Also that under heavy downstream loss or reordering, >> >> 3 SACK options become dominant to have ACE option. >> >> 4. If SYN option space is a concern, ACE header exchange is ok. But I >> suspect the latter has more middlebox issue based on my TFO deployment >> experience. >> >> >> So with all that said, is it possible to have a "minimal"-ACE that >> 1. Does ACE handshake as proposed >> 2. Mark ECT on all (or at least SYN & data & rtx) packets like ECN++ > > This is ECN++ and independent of AccECN. We on purposed have split the fe= edback and usage of ECN (which is not the case in RFC3168) to be able to ch= ange things in future independently sure - IMO marking all packets just improve the accuracy significantly vs the counters and options. For example, ECN on SYN is very useful on incast / loaded link. > >> 3. Leave ACE-count and ACE option optional (i.e. MAY) > > I don=E2=80=99t understand this. If both is optional, you don=E2=80=99t h= ave any feedback. Or what do you mean by =E2=80=9Eleave ACE-count optional= =E2=80=9C? use-case: We can negotiate DCTCP-style ECN for the internet. Then interested parties can progressively experiment on more accurate "options" (!=3D TCP-option) > > Mirja > > > >> >> as a "fairly safe" to deployment compromise. And I am happy to draft a >> kernel patch for that :-) >> >> >> >> On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe wrote= : >>> Yuchung, >>> >>> On 12/07/18 17:03, Mirja K=C3=BChlewind wrote: >>>> >>>> Hi Yuchung, >>>> >>>> please see below. >>>> >>>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>>>> >>>>> Yes packets with ACE options and (different) ACE-counter header would >>>>> break GRO. There're many legacy h/w and s/w. >>>> >>>> I=E2=80=99m not the expert here but my understanding is that is would = not break >>>> GRO but could not make actual use or it if the ACE counter changed or = the >>>> option is present. >>> >>> [BB] Yuchung's criticism applies to any scheme that feeds back a contin= ually >>> changing signal like ECN. For instance, like AccECN feedback, DCTCP ECN >>> feedback continually changes the TCP header flags, and I believe DCTCP = is >>> widely used in DCs. >>> >>> I believe, to make GRO support ECN feedback (whether DCTCP or AccECN), = it >>> would be necessary for GRO to know which bits to mask when determining >>> whether a packet is mergeable with others. I believe GRO already collec= ts >>> header fields separately for the TCP logic to be able to work on them, = but >>> I'm also not an expert. >>>> >>>> However, usually your will only have a small number of CE marks every >>>> couple of RTTs, and the counter only changes if you CE marks/the optio= n is >>>> only present a few times per RTT. So the impact should be rather low. = But >>>> this clear something to evaluate for the experiment. >>> >>> [BB] With DCTCP as currently designed, you tend to get runs of 100% CE = if >>> the load of short flows is very small. In that case, DCTCP feedback wil= l >>> change the header flags less often than AccECN. However, with more shor= t >>> flows, the feedback is more on-off. Then the flags change more often wi= th >>> DCTCP than with AccECN feedback. >>> >>> In general, hardware optimization is not going to optimize a protocol t= hat >>> didn't exist when the hardware was designed. It would be ideal to desig= n a >>> new protocol that takes advantage of existing hardware optimization. >>> However, as long as an experimental protocol still works with existing >>> hardware, I think it's reasonable to assume that hardware optimization = will >>> only arrive once a protocol has become well-established. >>> >>>> >>>>> Even without option, ACE header only allows reflecting up to 8 packet= s >>>>> for receiver segmentation offload and ACK suppression? >>>> >>>> Same as above, it can only up to 8 CE marked packets per ACK, however,= CE >>>> marking rater are expected to be rather low. ACK suppression should pr= obably >>>> not be used if the ACE counter has changes, however, usually the ACE c= ounter >>>> stays stable for multiple RTTs and then ACK suppression is not a probl= em. >>>> However, not sure I understood you question here correctly=E2=80=A6? >>>> >>>>> The appendix on ack loss causes ambiguity is good: but the pattern >>>>> drops specifically the state-switch (CE<->noCE) ACK which only happen= s >>>>> on delayed ACK. Is that pattern common? - or can we address most of >>>>> that by delaying less ACKs? >>>> >>>> I guess you have a 50% chance today to hit a delayed ACK. I guess dela= ying >>>> less (where you delay every second ACK today) would mean ACK every pac= ket, >>>> and thus double ACK load on the network. I guess on today networks tha= t >>>> actually in most cases not a problem, however, there might be speciall= y >>>> cases where it is. However, that=E2=80=99s problem an independent ques= tion to >>>> evaluate. >>> >>> [BB] If there were no delayed ACKs, the problem with DCTCP feedback wou= ld >>> largely disappear. But delayed ACKs are not going away. Which is why we >>> proposed replacing DCTCP feedback with AccECN feedback. >>>> >>>> >>>>> I am all for making ECN more accurate for wide area beyond DCTCP, but >>>>> am evaluating the pros/cons. What if we just >>>>> 1. negotiate 'better' ECN via new SYN option >>>> >>>> Not sure I understand your proposal correctly, but I assume you mean >>>> negotiate via SYN option and then just use the ACE counter in the head= er? If >>>> so, I don=E2=80=99t understand why you see the negotiation part in the= TCP header as >>>> the problem? >>> >>> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a sol= ution >>> without a problem. In fact an option on the SYN would create a new prob= lem >>> 'cos of the severe shortage of space for SYN options (for this reason, = the >>> AccECN TCP option was designed not to be needed on the SYN). >>>> >>>> >>>>> 2. mark all packets like ECN++ >>>> >>>> That would be nice but here you actually need AccECN because you want = to >>>> have feedback for control packets as well. AccECN is providing this >>>> feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; tha= t=E2=80=99s what we have ECN++ >>>> for; both thing ideally would be deployed together however. Was that y= our >>>> questions? >>> >>> Cheers >>> >>> >>> Bob >>> >>>> Mirja >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind >>>>> wrote: >>>>>> >>>>>> Hi Yuchung, >>>>>> >>>>>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy rea= lly depends on the >>>>>> use case. If you use DCTCP as today, the ACE counter in the TCP is p= robably >>>>>> sufficient and you might not want to pay the additional overhead in = your >>>>>> data center (that why the option is actually optional). >>>>>> >>>>>> If you however, e.g., have very differently sized packets, then the = byte >>>>>> counter in the option could give you a more accurate signal. Or if y= ou are >>>>>> also interested in the ECT(1) counter, you need the option. Further = the ACE >>>>>> counter also give your feedback on control packet and the option ena= bles you >>>>>> to distinguish between CE-amrked payload and control packets, which = can also >>>>>> become important when experimenting with making all packets ECN-capa= ble. >>>>>> >>>>>> Given accECN is a general feedback mechanism that in fact is designe= d to >>>>>> enable new future uses of the ECN signal, we wanted to keep all thes= e option >>>>>> available while making is still as simple as possible and as flexibl= e as >>>>>> possible. >>>>>> >>>>>> Mirja >>>>>> >>>>>> >>>>>> >>>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>>>>> >>>>>>> Hi Bob, >>>>>>> >>>>>>> Neal and I evaluated the earlier draft. It is well-thought out but >>>>>>> we're concerned about the options. Option is not mandatory but the >>>>>>> lack of it also reduces accuracy. Option runs into space issues w/ >>>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure = but >>>>>>> aren't easy. >>>>>>> >>>>>>> We're curious how much more "accuracy" it buys over current >>>>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe >>>>>>> wrote: >>>>>>>> >>>>>>>> Michael, tcpm list, >>>>>>>> >>>>>>>> As well as addressing your points, as Mirja has already mentioned >>>>>>>> below, we >>>>>>>> added a whole new appendix giving the rationale for the bits and >>>>>>>> codepoints >>>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3r= d >>>>>>>> subsection also identifies space for future evolution. It also poi= nts >>>>>>>> to >>>>>>>> where rationale was already given in the body of the draft. >>>>>>>> >>>>>>>> The appendix is in the draft submitted last week, available here: >>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#append= ix-B >>>>>>>> >>>>>>>> We'd be interested to hear whether this allays your concerns. >>>>>>>> >>>>>>>> We have asked to present this in Montreal as well. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>>> >>>>>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>>>> >>>>>>>>> Hi Micheal, >>>>>>>>> >>>>>>>>> I addressed a couple of your comments below. >>>>>>>>> >>>>>>>>> For the other, bigger comments regarding extensibility, that I di= d >>>>>>>>> not yet >>>>>>>>> address below, we plan to add a new section to the appendix to >>>>>>>>> explain >>>>>>>>> extensibility options as previously discussed by mail. We will >>>>>>>>> probably send >>>>>>>>> a separate email on that part. >>>>>>>>> >>>>>>>>> Mirja >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>>>> DE/Stuttgart) >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi Mirja, >>>>>>>>>> >>>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some of t= he >>>>>>>>>> editorial suggestions. >>>>>>>>>> >>>>>>>>>> Yet, I continue to believe that some formal wording in the docum= ent >>>>>>>>>> needs >>>>>>>>>> to change, as explained below. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Michael (with no hat on) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz= .ch] >>>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>>>> >>>>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>>>> >>>>>>>>>>> Hi Micheal, >>>>>>>>>>> >>>>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>>>> >>>>>>>>>>> Please see inline. >>>>>>>>>>> >>>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>> >>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>>>> appendix). I >>>>>>>>>>> >>>>>>>>>>> believe this document needs further work before moving forward. >>>>>>>>>>>> >>>>>>>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>>>>>>> >>>>>>>>>>> document independent of the review from Gorry. I apologize if t= here >>>>>>>>>>> is >>>>>>>>>>> duplication. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ****************************** >>>>>>>>>>>> >>>>>>>>>>>> * Abstract: >>>>>>>>>>>> >>>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx)= or >>>>>>>>>>>> Data >>>>>>>>>>> >>>>>>>>>>> Center TCP >>>>>>>>>>>> >>>>>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever >>>>>>>>>>>> more >>>>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>>>> >>>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257.= I >>>>>>>>>>>> suggest to >>>>>>>>>>> >>>>>>>>>>> remove this, or replace it by a more generic statement that mor= e >>>>>>>>>>> accurate >>>>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>>>> >>>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate information= . >>>>>>>>>>> They do >>>>>>>>>>> not need the mechanism that is specified in this draft, however= , >>>>>>>>>>> this is >>>>>>>>>>> not >>>>>>>>>>> what the sentences is saying. >>>>>>>>>> >>>>>>>>>> In my understanding (as a non-native speaker), the use of the wo= rd >>>>>>>>>> "need" >>>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>>>> implemented >>>>>>>>>> without any such mechanism. >>>>>>>>>> >>>>>>>>>> What would work for me is something of the form "... Data Center= TCP >>>>>>>>>> cannot get precise ECN feedback whenever more than one marking i= s >>>>>>>>>> received >>>>>>>>>> in one RTT=E2=80=9C. >>>>>>>>> >>>>>>>>> This is not correct. DCTP need more than one feedback signal per = RTT >>>>>>>>> and >>>>>>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s o= wn feedback >>>>>>>>> mechanism. However, to avoid confusion such that people could ass= ume >>>>>>>>> DCTP >>>>>>>>> would not work without the accECN scheme as specified in this doc= , I >>>>>>>>> rephrased to: >>>>>>>>> >>>>>>>>> "Recently, proposed >>>>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>>>> target=3D"RFC7713"/>), >>>>>>>>> DCTCP or L4S >>>>>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more = than >>>>>>>>> one >>>>>>>>> marking is received in one RTT which is >>>>>>>>> information that cannot be provided by the feedback scheme a= s >>>>>>>>> specified in >>>>>>>>> ." >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> This document specifies an >>>>>>>>>>>> experimental scheme to provide more than one feedback signal = per >>>>>>>>>>>> RTT >>>>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>>>> overloads >>>>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>>>> provides >>>>>>>>>>>> additional information in a new TCP option. >>>>>>>>>>>> >>>>>>>>>>>> [ms] This statement needs to be rewritten to correctly reflect >>>>>>>>>>>> what is >>>>>>>>>>> >>>>>>>>>>> requested from IANA. My understanding is that this experimental >>>>>>>>>>> document >>>>>>>>>>> asks for allocation of a reserved TCP header flag. This needs t= o be >>>>>>>>>>> called out >>>>>>>>>>> prominently, IMHO. In addition, since this is not a standard, t= he >>>>>>>>>>> suggested >>>>>>>>>>> experimentation with the main TCP header must IMHO be explicitl= y >>>>>>>>>>> mentioned. I also suggest to have later in a document a section >>>>>>>>>>> that >>>>>>>>>>> explicitly >>>>>>>>>>> explains why it is appropriate to modify the main TCP header in= an >>>>>>>>>>> experiment. >>>>>>>>>>> >>>>>>>>>>> I don=E2=80=99t know if any requirement that IANA assignment ne= ed to be >>>>>>>>>>> called >>>>>>>>>>> out >>>>>>>>>>> in the abstract but we can do that. However, I believe the ques= tion >>>>>>>>>>> if >>>>>>>>>>> this >>>>>>>>>>> document should or should not assign the bit is still not >>>>>>>>>>> completely >>>>>>>>>>> solved, or >>>>>>>>>>> is it? >>>>>>>>>> >>>>>>>>>> I believe this question will have to be reviewed during WGLC and= , >>>>>>>>>> more >>>>>>>>>> importantly, IETF last call. For the moment, my concern is that = the >>>>>>>>>> document >>>>>>>>>> correctly describes the IANA allocation. >>>>>>>>>> >>>>>>>>>> I would like to see here a statement such as : "Given TCP header >>>>>>>>>> space is >>>>>>>>>> scarce, this specification allocates a reserved header bit and >>>>>>>>>> overloads the >>>>>>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>>>>> >>>>>>>>> A bit lengthy but now: >>>>>>>>> >>>>>>>>> "Given TCP header space is >>>>>>>>> scarce, it allocates a reserved header bit, that was previou= sly >>>>>>>>> used for >>>>>>>>> ECN-Nonce which was recently declared historic, and overload= s >>>>>>>>> the >>>>>>>>> two existing ECN flags in the TCP header. Further, additiona= l >>>>>>>>> information can be provided in a new TCP option that however= is >>>>>>>>> not >>>>>>>>> used >>>>>>>>> on the TCP SYN." >>>>>>>>> >>>>>>>>>>>> * 1. Introduction >>>>>>>>>>>> >>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] >>>>>>>>>>>> need >>>>>>>>>>>> more accurate ECN feedback information whenever more than one >>>>>>>>>>> >>>>>>>>>>> marking >>>>>>>>>>>> >>>>>>>>>>>> is received in one RTT. >>>>>>>>>>>> >>>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit t= his. >>>>>>>>>>>> Instead >>>>>>>>>>> >>>>>>>>>>> of stating a "need", it would IMHO make more sense to discuss t= he >>>>>>>>>>> benefits >>>>>>>>>>> of the suggested mechanism in this document of its own, indepen= dent >>>>>>>>>>> of >>>>>>>>>>> other proposals. To me, this document should be independent of >>>>>>>>>>> other >>>>>>>>>>> documents and specifically other experiments. We have to think >>>>>>>>>>> about >>>>>>>>>>> cases >>>>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>>>> documents >>>>>>>>>>> will >>>>>>>>>>> be more future-proof in future. >>>>>>>>>>> >>>>>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant to s= ay that >>>>>>>>>>> these >>>>>>>>>>> mechanisms new more accurate ECN feedback than provided today b= y >>>>>>>>>>> RFC3168 but it was not meant to say that these mechanism have t= o >>>>>>>>>>> use the >>>>>>>>>>> scheme as specified in this document. >>>>>>>>>>> >>>>>>>>>>> I added the following part sentence: >>>>>>>>>>> >>>>>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposure= (ConEx >>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] ne= ed >>>>>>>>>>> more >>>>>>>>>>> accurate ECN feedback information than provided by the feedback >>>>>>>>>>> scheme >>>>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>>>> received in >>>>>>>>>>> one >>>>>>>>>>> RTT. This document specifies an alternative feedback scheme tha= t >>>>>>>>>>> provides >>>>>>>>>>> more accurate information and could be used by these new TCP >>>>>>>>>>> extensions.=E2=80=9C >>>>>>>>>>> >>>>>>>>>>> Does this help? >>>>>>>>>> >>>>>>>>>> See my proposal for the abstract. I continue to disagree with th= e >>>>>>>>>> term >>>>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>>>> >>>>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>>>> track, it is intended to be a complete replacement for classi= c >>>>>>>>>>>> TCP/ >>>>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>>>> >>>>>>>>>>>> [ms] This sentence should be removed, as this is speculation. >>>>>>>>>>> >>>>>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the intent= that we have. >>>>>>>>>>> >>>>>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain a= s >>>>>>>>>>>> the >>>>>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>>>>> >>>>>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>>>> >>>>>>>>>>> Why? Does it help to add an only here: >>>>>>>>>>> >>>>>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain as= the >>>>>>>>>>> only >>>>>>>>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>>>>>>> >>>>>>>>>> This wording is better. >>>>>>>>>> >>>>>>>>>>>> AccECN feedback overloads flags and fields in the main TCP >>>>>>>>>>>> header >>>>>>>>>>>> with new definitions, so both ends have to support the new wi= re >>>>>>>>>>>> protocol before it can be used. >>>>>>>>>>>> >>>>>>>>>>>> [ms] In my reading this experimental document asks for *new* >>>>>>>>>>>> allocation >>>>>>>>>>> >>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>> >>>>>>>>>>> Is this better? >>>>>>>>>>> >>>>>>>>>>> "AccECN feedback overloads the two existing ECN flags as well a= s >>>>>>>>>>> the >>>>>>>>>>> currently reserved and previously called NS flag in the mai= n >>>>>>>>>>> TCP >>>>>>>>>>> header >>>>>>>>>>> with new definitions, so both ends have to support the new >>>>>>>>>>> wire >>>>>>>>>>> protocol >>>>>>>>>>> before it can be used.=E2=80=9C >>>>>>>>>>> >>>>>>>>>>> I understand that you are not happy with the word =E2=80=9Eover= load=E2=80=9C here >>>>>>>>>>> but >>>>>>>>>>> the >>>>>>>>>>> point of this sentence really is that the flags can/could be us= ed >>>>>>>>>>> differently >>>>>>>>>>> and therefore we need a new negotiation before we can use them. >>>>>>>>>> >>>>>>>>>> For me the following would work: "AccECN feedback overloads the = two >>>>>>>>>> existing ECN flags and >>>>>>>>>> allocates the currently reserved and previously called NS flag i= n >>>>>>>>>> the >>>>>>>>>> main TCP header. >>>>>>>>>> Given the new definitions, both ends have to support the new wir= e >>>>>>>>>> protocol >>>>>>>>>> before it can be used." >>>>>>>>>> >>>>>>>>>> I believe the wording has to be crystal clear on the reservation= of >>>>>>>>>> bit 7 >>>>>>>>>> when it is discussed the first time in the text. In follow-up >>>>>>>>>> sections, >>>>>>>>>> maybe shorter terms could be used. >>>>>>>>> >>>>>>>>> Okay, now: >>>>>>>>> >>>>>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>>>>> allocates the currently reserved and previously called NS flag= in >>>>>>>>> the >>>>>>>>> TCP header, to be used as one field indicating the number of >>>>>>>>> congestion >>>>>>>>> experienced marked packets. Given the new definitions of these >>>>>>>>> three >>>>>>>>> bits, >>>>>>>>> both ends have to support the new wire protocol before it = can >>>>>>>>> be >>>>>>>>> used. >>>>>>>>> Therefore during the TCP handshake the two ends use these thre= e >>>>>>>>> bit >>>>>>>>> in >>>>>>>>> the TCP header to negotiate the most advanced feedback protoco= l >>>>>>>>> that they can both support in a backward compatible way to >>>>>>>>> ." >>>>>>>>>>> >>>>>>>>>>> If you prefer, we can also remove the NS flag in this list, as = ECN >>>>>>>>>>> Nonce >>>>>>>>>>> was >>>>>>>>>>> anyway never deployed. >>>>>>>>>>> >>>>>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>>>>> specifies a different response to TCP ECN feedback, for examp= le: >>>>>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low >>>>>>>>>>>> Latency >>>>>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ec= n], >>>>>>>>>>>> or >>>>>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>>>> >>>>>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this parag= raph >>>>>>>>>>>> can >>>>>>>>>>>> just >>>>>>>>>>> >>>>>>>>>>> be deleted. If other experiments need more accurate feedback, i= t is >>>>>>>>>>> up >>>>>>>>>>> to >>>>>>>>>>> them to explain how they would use this mechanism. This documen= t >>>>>>>>>>> should >>>>>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>>>>> >>>>>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better t= o be >>>>>>>>>>> explicit >>>>>>>>>>> about this? >>>>>>>>>>> >>>>>>>>>>>> It is likely (but not required) that the AccECN protocol will= be >>>>>>>>>>>> implemented along with the following experimental additions t= o >>>>>>>>>>>> the >>>>>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>>>>> retransmissions >>>>>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capab= le >>>>>>>>>>>> SYN/ >>>>>>>>>>>> ACK experiment [RFC5562]; and testing receiver non-compliance >>>>>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>>>> >>>>>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my vie= w, >>>>>>>>>>>> the >>>>>>>>>>>> TCPM >>>>>>>>>>> >>>>>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>>>>>> draft-ietf- >>>>>>>>>>> tcpm-generalized-ecn independent documents, which probably impl= ies >>>>>>>>>>> that >>>>>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If >>>>>>>>>>> experimentation >>>>>>>>>>> with ECT in SYN requires a combination, this could be done in a >>>>>>>>>>> new, >>>>>>>>>>> third >>>>>>>>>>> document. Apart from having simpler focused documents, this cou= ld >>>>>>>>>>> significantly help later with moving forward documents to stand= ards >>>>>>>>>>> track. >>>>>>>>>>> >>>>>>>>>>> I disagree, however, this is a discussion to have on >>>>>>>>>>> draft-ietf-tcpm- >>>>>>>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing a = reference >>>>>>>>>>> here >>>>>>>>>>> that >>>>>>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>>>> >>>>>>>>>>>> [ms] A macroscopic comment is that this document has a lot of >>>>>>>>>>>> introduction >>>>>>>>>>> >>>>>>>>>>> and tutorial text with lot's of redundancy towards other docume= nts. >>>>>>>>>>> I >>>>>>>>>>> think >>>>>>>>>>> the document can be made much easier to read by shorten it. In = many >>>>>>>>>>> cases >>>>>>>>>>> this is just an editorial change as there is redundancy. As one >>>>>>>>>>> such >>>>>>>>>>> example, >>>>>>>>>>> just remove this section. >>>>>>>>>>> >>>>>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big fan= of short >>>>>>>>>>> and >>>>>>>>>>> concise >>>>>>>>>>> documents, however, some redundancy can also help understanding= , >>>>>>>>>>> especially if you explain things multiple times but with a >>>>>>>>>>> different >>>>>>>>>>> level of >>>>>>>>>>> detail. I personally would not need the roadmap but I know many >>>>>>>>>>> people >>>>>>>>>>> who find these things helpful and to be honest I don=E2=80=99t = see how >>>>>>>>>>> removing >>>>>>>>>>> this >>>>>>>>>>> part makes the doc any better. If you don=E2=80=99t want it, do= n=E2=80=99t read it. >>>>>>>>>>> >>>>>>>>>>>> * 1.2. Goals >>>>>>>>>>>> >>>>>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>>>> >>>>>>>>>>> I have to say I also don=E2=80=99t see the point of removing th= is part. >>>>>>>>>>> Given >>>>>>>>>>> we=E2=80=99ve >>>>>>>>>>> done the work on requirements, I think we should also link to t= his >>>>>>>>>>> doc >>>>>>>>>>> somewhere. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>>>> >>>>>>>>>>>> TCP is critical to the robust functioning of the Internet, >>>>>>>>>>>> therefore >>>>>>>>>>>> any proposed modifications to TCP need to be thoroughly teste= d. >>>>>>>>>>>> The >>>>>>>>>>>> present specification describes an experimental protocol that >>>>>>>>>>>> adds >>>>>>>>>>>> more accurate ECN feedback to the TCP protocol. The intentio= n >>>>>>>>>>>> is to >>>>>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>>>>> implementation can be built in order to test its function, >>>>>>>>>>>> robustness >>>>>>>>>>>> and interoperability (with itself and with previous version o= f >>>>>>>>>>>> ECN >>>>>>>>>>>> and TCP). >>>>>>>>>>>> >>>>>>>>>>>> [ms] I think all what is written in this paragraph is obvious,= no? >>>>>>>>>>>> Can't we just >>>>>>>>>>> >>>>>>>>>>> delete this? >>>>>>>>>>> >>>>>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out. = For me both >>>>>>>>>>> is >>>>>>>>>>> fine, keep it >>>>>>>>>>> or remove it. >>>>>>>>>>> >>>>>>>>>>>> The experimental protocol will be considered successful if it= is >>>>>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] in >>>>>>>>>>>> the >>>>>>>>>>>> consensus opinion of the IETF tcpm working group. In short, >>>>>>>>>>>> this >>>>>>>>>>>> requires that it improves the accuracy and timeliness of TCP'= s >>>>>>>>>>>> ECN >>>>>>>>>>>> feedback, as claimed in Section 5, while striking a balance >>>>>>>>>>>> between >>>>>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>>>>> minimisation of overhead. It also requires that it is not >>>>>>>>>>>> unduly >>>>>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>>>>> behaviours in the current Internet (e.g. hardware offloading = and >>>>>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>>>> >>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>>> specified >>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness= of >>>>>>>>>>>> these strategies depends on the actual deployment situation o= f >>>>>>>>>>>> middleboxes. Therefore experimental verification to confirm >>>>>>>>>>>> large- >>>>>>>>>>>> scale path traversal in the Internet is needed before finaliz= ing >>>>>>>>>>>> this >>>>>>>>>>>> specification on the Standards Track. >>>>>>>>>>>> >>>>>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I hav= e >>>>>>>>>>> >>>>>>>>>>> mentioned before, I don't think an RFC should speculate about T= CPM >>>>>>>>>>> and >>>>>>>>>>> its >>>>>>>>>>> consensus opinion. I would suggest a wording along the lines of= : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>>>>> testing confirms that the proposed mechanism can be deployed = at >>>>>>>>>>>> large >>>>>>>>>>> >>>>>>>>>>> scale. >>>>>>>>>>>> >>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>>> specified >>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness= of >>>>>>>>>>>> these strategies depends on the actual deployment situation o= f >>>>>>>>>>>> middleboxes. Therefore experimental verification to confirm >>>>>>>>>>>> large- >>>>>>>>>>>> scale path traversal in the Internet is needed, e.g., by supp= ort >>>>>>>>>>>> in >>>>>>>>>>>> major TCP stacks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t thi= nk that the >>>>>>>>>>> paraphrase >>>>>>>>>>> speculates about the consensus of tcpm, in contrast it say tcpm= has >>>>>>>>>>> to >>>>>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>>>>> sufficiently >>>>>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the requ= irement >>>>>>>>>>> draft as >>>>>>>>>>> this >>>>>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>>>> >>>>>>>>>> My suggested wording uses the expression "can be deployed at lar= ge >>>>>>>>>> scale" >>>>>>>>>> and I believe this is relevant. >>>>>>>>>> >>>>>>>>>> The document already describes in Section 5 how the protocol >>>>>>>>>> satisfies >>>>>>>>>> the agreed requirements for a more accurate ECN feedback protoco= l >>>>>>>>>> [RFC7560]. >>>>>>>>>> So, if the TCPM working group publishes this document with the >>>>>>>>>> content of >>>>>>>>>> Section 5, I believe the TCPM working group already has reached >>>>>>>>>> consensus >>>>>>>>>> that the protocol meets requirements. In addition, it is possibl= e >>>>>>>>>> that new >>>>>>>>>> requirements would be identified in future, e.g., as an outcome = of >>>>>>>>>> the >>>>>>>>>> experiment, and that would obviously have to be considered by TC= PM. >>>>>>>>>> In that >>>>>>>>>> case, for the success of the experiment not only RFC 7560 would >>>>>>>>>> matter, but >>>>>>>>>> also further requirements. My proposed wording does not have all >>>>>>>>>> these >>>>>>>>>> problems. >>>>>>>>>> >>>>>>>>>> In a nutshell, I continue to believe that this section has to >>>>>>>>>> change. >>>>>>>>> >>>>>>>>> >>>>>>>>> Okay, used your proposed wording. You have a point about the >>>>>>>>> requirement >>>>>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be deploye= d >>>>>>>>> large-scale=E2=80=9C. >>>>>>>>> >>>>>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>>>> >>>>>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>>>> >>>>>>>>>>>> The last bit in byte 13 of the TCP header was defined as the >>>>>>>>>>>> Nonce >>>>>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never >>>>>>>>>>>> deployed >>>>>>>>>>>> so >>>>>>>>>>>> it is being reclassified as historic, making this TCP flag >>>>>>>>>>>> available >>>>>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>>>> >>>>>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into acc= ount >>>>>>>>>>>> the >>>>>>>>>>>> IANA >>>>>>>>>>> >>>>>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published. >>>>>>>>>>> >>>>>>>>>>> Is does. However, I can explicitly say that is has be re-clssif= ied >>>>>>>>>>> as >>>>>>>>>>> reserved. >>>>>>>>>>> >>>>>>>>>>> "RFC 3540 was never deployed so it is being reclassified as >>>>>>>>>>> historic >>>>>>>>>>> [I-D.ietf- >>>>>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been mar= ked >>>>>>>>>>> as >>>>>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags registr= y, making this TCP >>>>>>>>>>> flag >>>>>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>>>> >>>>>>>>>>> Better? >>>>>>>>>>> >>>>>>>>>>>> In my understanding, this experimental document asks for new >>>>>>>>>>>> assignment >>>>>>>>>>> >>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>> >>>>>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded this = discussion >>>>>>>>>>> yet. >>>>>>>>>>> However, >>>>>>>>>>> what we really would want to is mention somewhere that this >>>>>>>>>>> experiment >>>>>>>>>>> with this flags is running. I guess there are three options: >>>>>>>>>>> 1) keep it in the registry as reserved and conserve the knowled= ge >>>>>>>>>>> in >>>>>>>>>>> tcpm >>>>>>>>>>> that this experiment is running and no other experimental RFC s= uch >>>>>>>>>>> use >>>>>>>>>>> this >>>>>>>>>>> flags as long as this experiment is running. >>>>>>>>>>> 2) Keep is marked as reserved but add a note about this experim= ent >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> IANA registry >>>>>>>>>>> 3) Or assign it right away with IESG approval. I guess in this = case >>>>>>>>>>> tcpm >>>>>>>>>>> could >>>>>>>>>>> also consider to change the registration policy to =E2=80=9EIET= F Review=E2=80=9C. >>>>>>>>>> >>>>>>>>>> The current registration policy for the TCP header flags is >>>>>>>>>> "standards >>>>>>>>>> action". I understand that the IESG could approve exceptions. Bu= t >>>>>>>>>> given the >>>>>>>>>> policy, I believe the document has to be very precise on the req= uest >>>>>>>>>> regarding bit 7. >>>>>>>>> >>>>>>>>> Okay, it now says: >>>>>>>>> >>>>>>>>> "[TO BE REMOVED: IANA is requested to update the existing entry i= n >>>>>>>>> the >>>>>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>>>>> >>>>>>>>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-fla= gs.xhtml#tcp-header-flags-1) >>>>>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as N= S >>>>>>>>> (Nonce >>>>>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-to-= be >>>>>>>>> instead >>>>>>>>> of RFC8311.]=E2=80=9C >>>>>>>>> >>>>>>>>> I guess we could also ask IANA to add an additional comment colum= n >>>>>>>>> instead >>>>>>>>> (but not sure if we then have to update RFC3168, which I think we >>>>>>>>> really >>>>>>>>> don=E2=80=99t want. Should be fine now. >>>>>>>>> >>>>>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>>>> >>>>>>>>>>>> o an essential part that re-uses ECN TCP header bits to feed >>>>>>>>>>>> back >>>>>>>>>>>> the number of arriving CE marked packets. This provides m= ore >>>>>>>>>>>> accuracy than classic ECN feedback, but limited resilience >>>>>>>>>>>> against >>>>>>>>>>>> ACK loss; >>>>>>>>>>>> >>>>>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>>>> >>>>>>>>>>> I think this is nit picking. Using a different phrasing here ma= kes >>>>>>>>>>> the >>>>>>>>>>> sentence >>>>>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how get a= round the >>>>>>>>>>> fact >>>>>>>>>>> that we need to handle the flag registration correctly. However= , >>>>>>>>>>> here >>>>>>>>>>> the >>>>>>>>>>> point really is to explain how the protocol word. The main poin= t of >>>>>>>>>>> using the >>>>>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that t= hese flags are or >>>>>>>>>>> have >>>>>>>>>>> been >>>>>>>>>>> used different by other TCP extension (and we therefore need a >>>>>>>>>>> proper >>>>>>>>>>> negotiation scheme). >>>>>>>>>> >>>>>>>>>> If the allocation of a reserved flag is correctly explained in t= he >>>>>>>>>> abstract and introduction, I think these sentences can use a bit >>>>>>>>>> relaxed >>>>>>>>>> terminology. >>>>>>>>>> >>>>>>>>>>>> The two part design was necessary, given limitations on the >>>>>>>>>>>> space >>>>>>>>>>>> available for TCP options and given the possibility that cert= ain >>>>>>>>>>>> incorrectly designed middleboxes prevent TCP using any new >>>>>>>>>>>> options >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>> >> > > From nobody Fri Jul 13 12:42:21 2018 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 03CBF128BAC; Fri, 13 Jul 2018 12:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 FEquO6FKQAt9; Fri, 13 Jul 2018 12:42:14 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79A6130F30; Fri, 13 Jul 2018 12:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41S39J13q7z15NS7; Fri, 13 Jul 2018 21:42:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jpk2DuW-rlo; Fri, 13 Jul 2018 21:42:09 +0200 (CEST) X-MtScore: NO score=0 Received: from [172.20.4.114] (unknown [207.96.227.254]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Jul 2018 21:42:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 13 Jul 2018 15:42:05 -0400 Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 19:42:20 -0000 Hi Yuchung, > Am 13.07.2018 um 15:30 schrieb Yuchung Cheng : >=20 > On Fri, Jul 13, 2018 at 11:53 AM, Mirja K=C3=BChlewind > wrote: >> Hi Yucheng, >>=20 >> please see below. >>=20 >>> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng : >>>=20 >>> hi -- >>>=20 >>> I agree: >>> 1. delayed/streched ACK aren't going away (in fact will be more = common) >>> 2. GRO isn't and should not be a show-stopper >>> 3. SYN option is running tight >>> 4. HW opt comes after SW >>>=20 >>> I worry: >>> 1. GRO is a unavoidable issue in deployment (let's not produce an >>> undeployable RFC). the ACE counter won't work as GRO can pack up to >>> 64KB/MTU =3D~ 45 pkts under heavy congestion. >>>=20 >>> 2. ACE's benefit over DCTCP is when delayed ACKs and ack losses >>> happen. Now delayed ACKs happen frequently when the messages are >>> small, which means they don't solicit too many ACKs to be dropped in >>> the reverse path. Also that under heavy downstream loss or = reordering, >>>=20 >>> 3 SACK options become dominant to have ACE option. >>>=20 >>> 4. If SYN option space is a concern, ACE header exchange is ok. But = I >>> suspect the latter has more middlebox issue based on my TFO = deployment >>> experience. >>>=20 >>>=20 >>> So with all that said, is it possible to have a "minimal"-ACE that >>> 1. Does ACE handshake as proposed >>> 2. Mark ECT on all (or at least SYN & data & rtx) packets like ECN++ >>=20 >> This is ECN++ and independent of AccECN. We on purposed have split = the feedback and usage of ECN (which is not the case in RFC3168) to be = able to change things in future independently > sure - IMO marking all packets just improve the accuracy significantly > vs the counters and options. For example, ECN on SYN is very useful on > incast / loaded link. Yes, but to be able to mark control packets as ECN-enables you also need = a way to feedback congestion experienced information if they appear on = these packets. Therefore you can use ECN++ only safely with e.g. AccECN = feedback (but not with classic RFC3168 ECN feedback). Still these two = things should be specified in separate documents to be able to change = them separately in future. >=20 >>=20 >>> 3. Leave ACE-count and ACE option optional (i.e. MAY) >>=20 >> I don=E2=80=99t understand this. If both is optional, you don=E2=80=99t= have any feedback. Or what do you mean by =E2=80=9Eleave ACE-count = optional=E2=80=9C? > use-case: We can negotiate DCTCP-style ECN for the internet. >=20 > Then interested parties can progressively experiment on more accurate > "options" (!=3D TCP-option) As Appendix A of RFC7560 says I don=E2=80=99t think it is a safe option = for the Internet where packet loss more likely then in a full = ECN-enabled data center. Mirja >=20 >>=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> as a "fairly safe" to deployment compromise. And I am happy to draft = a >>> kernel patch for that :-) >>>=20 >>>=20 >>>=20 >>> On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe = wrote: >>>> Yuchung, >>>>=20 >>>> On 12/07/18 17:03, Mirja K=C3=BChlewind wrote: >>>>>=20 >>>>> Hi Yuchung, >>>>>=20 >>>>> please see below. >>>>>=20 >>>>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>>>>>=20 >>>>>> Yes packets with ACE options and (different) ACE-counter header = would >>>>>> break GRO. There're many legacy h/w and s/w. >>>>>=20 >>>>> I=E2=80=99m not the expert here but my understanding is that is = would not break >>>>> GRO but could not make actual use or it if the ACE counter changed = or the >>>>> option is present. >>>>=20 >>>> [BB] Yuchung's criticism applies to any scheme that feeds back a = continually >>>> changing signal like ECN. For instance, like AccECN feedback, DCTCP = ECN >>>> feedback continually changes the TCP header flags, and I believe = DCTCP is >>>> widely used in DCs. >>>>=20 >>>> I believe, to make GRO support ECN feedback (whether DCTCP or = AccECN), it >>>> would be necessary for GRO to know which bits to mask when = determining >>>> whether a packet is mergeable with others. I believe GRO already = collects >>>> header fields separately for the TCP logic to be able to work on = them, but >>>> I'm also not an expert. >>>>>=20 >>>>> However, usually your will only have a small number of CE marks = every >>>>> couple of RTTs, and the counter only changes if you CE marks/the = option is >>>>> only present a few times per RTT. So the impact should be rather = low. But >>>>> this clear something to evaluate for the experiment. >>>>=20 >>>> [BB] With DCTCP as currently designed, you tend to get runs of 100% = CE if >>>> the load of short flows is very small. In that case, DCTCP feedback = will >>>> change the header flags less often than AccECN. However, with more = short >>>> flows, the feedback is more on-off. Then the flags change more = often with >>>> DCTCP than with AccECN feedback. >>>>=20 >>>> In general, hardware optimization is not going to optimize a = protocol that >>>> didn't exist when the hardware was designed. It would be ideal to = design a >>>> new protocol that takes advantage of existing hardware = optimization. >>>> However, as long as an experimental protocol still works with = existing >>>> hardware, I think it's reasonable to assume that hardware = optimization will >>>> only arrive once a protocol has become well-established. >>>>=20 >>>>>=20 >>>>>> Even without option, ACE header only allows reflecting up to 8 = packets >>>>>> for receiver segmentation offload and ACK suppression? >>>>>=20 >>>>> Same as above, it can only up to 8 CE marked packets per ACK, = however, CE >>>>> marking rater are expected to be rather low. ACK suppression = should probably >>>>> not be used if the ACE counter has changes, however, usually the = ACE counter >>>>> stays stable for multiple RTTs and then ACK suppression is not a = problem. >>>>> However, not sure I understood you question here correctly=E2=80=A6?= >>>>>=20 >>>>>> The appendix on ack loss causes ambiguity is good: but the = pattern >>>>>> drops specifically the state-switch (CE<->noCE) ACK which only = happens >>>>>> on delayed ACK. Is that pattern common? - or can we address most = of >>>>>> that by delaying less ACKs? >>>>>=20 >>>>> I guess you have a 50% chance today to hit a delayed ACK. I guess = delaying >>>>> less (where you delay every second ACK today) would mean ACK every = packet, >>>>> and thus double ACK load on the network. I guess on today networks = that >>>>> actually in most cases not a problem, however, there might be = specially >>>>> cases where it is. However, that=E2=80=99s problem an independent = question to >>>>> evaluate. >>>>=20 >>>> [BB] If there were no delayed ACKs, the problem with DCTCP feedback = would >>>> largely disappear. But delayed ACKs are not going away. Which is = why we >>>> proposed replacing DCTCP feedback with AccECN feedback. >>>>>=20 >>>>>=20 >>>>>> I am all for making ECN more accurate for wide area beyond DCTCP, = but >>>>>> am evaluating the pros/cons. What if we just >>>>>> 1. negotiate 'better' ECN via new SYN option >>>>>=20 >>>>> Not sure I understand your proposal correctly, but I assume you = mean >>>>> negotiate via SYN option and then just use the ACE counter in the = header? If >>>>> so, I don=E2=80=99t understand why you see the negotiation part in = the TCP header as >>>>> the problem? >>>>=20 >>>> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a = solution >>>> without a problem. In fact an option on the SYN would create a new = problem >>>> 'cos of the severe shortage of space for SYN options (for this = reason, the >>>> AccECN TCP option was designed not to be needed on the SYN). >>>>>=20 >>>>>=20 >>>>>> 2. mark all packets like ECN++ >>>>>=20 >>>>> That would be nice but here you actually need AccECN because you = want to >>>>> have feedback for control packets as well. AccECN is providing = this >>>>> feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; = that=E2=80=99s what we have ECN++ >>>>> for; both thing ideally would be deployed together however. Was = that your >>>>> questions? >>>>=20 >>>> Cheers >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind >>>>>> wrote: >>>>>>>=20 >>>>>>> Hi Yuchung, >>>>>>>=20 >>>>>>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy = really depends on the >>>>>>> use case. If you use DCTCP as today, the ACE counter in the TCP = is probably >>>>>>> sufficient and you might not want to pay the additional overhead = in your >>>>>>> data center (that why the option is actually optional). >>>>>>>=20 >>>>>>> If you however, e.g., have very differently sized packets, then = the byte >>>>>>> counter in the option could give you a more accurate signal. Or = if you are >>>>>>> also interested in the ECT(1) counter, you need the option. = Further the ACE >>>>>>> counter also give your feedback on control packet and the option = enables you >>>>>>> to distinguish between CE-amrked payload and control packets, = which can also >>>>>>> become important when experimenting with making all packets = ECN-capable. >>>>>>>=20 >>>>>>> Given accECN is a general feedback mechanism that in fact is = designed to >>>>>>> enable new future uses of the ECN signal, we wanted to keep all = these option >>>>>>> available while making is still as simple as possible and as = flexible as >>>>>>> possible. >>>>>>>=20 >>>>>>> Mirja >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng = : >>>>>>>>=20 >>>>>>>> Hi Bob, >>>>>>>>=20 >>>>>>>> Neal and I evaluated the earlier draft. It is well-thought out = but >>>>>>>> we're concerned about the options. Option is not mandatory but = the >>>>>>>> lack of it also reduces accuracy. Option runs into space issues = w/ >>>>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for = sure but >>>>>>>> aren't easy. >>>>>>>>=20 >>>>>>>> We're curious how much more "accuracy" it buys over current >>>>>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe = >>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Michael, tcpm list, >>>>>>>>>=20 >>>>>>>>> As well as addressing your points, as Mirja has already = mentioned >>>>>>>>> below, we >>>>>>>>> added a whole new appendix giving the rationale for the bits = and >>>>>>>>> codepoints >>>>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. = A 3rd >>>>>>>>> subsection also identifies space for future evolution. It also = points >>>>>>>>> to >>>>>>>>> where rationale was already given in the body of the draft. >>>>>>>>>=20 >>>>>>>>> The appendix is in the draft submitted last week, available = here: >>>>>>>>> = https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>>>>>>>>=20 >>>>>>>>> We'd be interested to hear whether this allays your concerns. >>>>>>>>>=20 >>>>>>>>> We have asked to present this in Montreal as well. >>>>>>>>>=20 >>>>>>>>> Cheers >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Bob >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi Micheal, >>>>>>>>>>=20 >>>>>>>>>> I addressed a couple of your comments below. >>>>>>>>>>=20 >>>>>>>>>> For the other, bigger comments regarding extensibility, that = I did >>>>>>>>>> not yet >>>>>>>>>> address below, we plan to add a new section to the appendix = to >>>>>>>>>> explain >>>>>>>>>> extensibility options as previously discussed by mail. We = will >>>>>>>>>> probably send >>>>>>>>>> a separate email on that part. >>>>>>>>>>=20 >>>>>>>>>> Mirja >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>> : >>>>>>>>>>>=20 >>>>>>>>>>> Hi Mirja, >>>>>>>>>>>=20 >>>>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some = of the >>>>>>>>>>> editorial suggestions. >>>>>>>>>>>=20 >>>>>>>>>>> Yet, I continue to believe that some formal wording in the = document >>>>>>>>>>> needs >>>>>>>>>>> to change, as explained below. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks >>>>>>>>>>>=20 >>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Mirja K=C3=BChlewind = [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>>>>> >>>>>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>>=20 >>>>>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline. >>>>>>>>>>>>=20 >>>>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>>=20 >>>>>>>>>>>> : >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>>>>> appendix). I >>>>>>>>>>>>=20 >>>>>>>>>>>> believe this document needs further work before moving = forward. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please find below my comments marked as [ms]. I have read = the >>>>>>>>>>>>=20 >>>>>>>>>>>> document independent of the review from Gorry. I apologize = if there >>>>>>>>>>>> is >>>>>>>>>>>> duplication. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ****************************** >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * Abstract: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure = (ConEx) or >>>>>>>>>>>>> Data >>>>>>>>>>>>=20 >>>>>>>>>>>> Center TCP >>>>>>>>>>>>>=20 >>>>>>>>>>>>> (DCTCP) need more accurate ECN feedback information = whenever >>>>>>>>>>>>> more >>>>>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC = 8257. I >>>>>>>>>>>>> suggest to >>>>>>>>>>>>=20 >>>>>>>>>>>> remove this, or replace it by a more generic statement that = more >>>>>>>>>>>> accurate >>>>>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>>>>>=20 >>>>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate = information. >>>>>>>>>>>> They do >>>>>>>>>>>> not need the mechanism that is specified in this draft, = however, >>>>>>>>>>>> this is >>>>>>>>>>>> not >>>>>>>>>>>> what the sentences is saying. >>>>>>>>>>>=20 >>>>>>>>>>> In my understanding (as a non-native speaker), the use of = the word >>>>>>>>>>> "need" >>>>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>>>>> implemented >>>>>>>>>>> without any such mechanism. >>>>>>>>>>>=20 >>>>>>>>>>> What would work for me is something of the form "... Data = Center TCP >>>>>>>>>>> cannot get precise ECN feedback whenever more than one = marking is >>>>>>>>>>> received >>>>>>>>>>> in one RTT=E2=80=9C. >>>>>>>>>>=20 >>>>>>>>>> This is not correct. DCTP need more than one feedback signal = per RTT >>>>>>>>>> and >>>>>>>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s= own feedback >>>>>>>>>> mechanism. However, to avoid confusion such that people could = assume >>>>>>>>>> DCTP >>>>>>>>>> would not work without the accECN scheme as specified in this = doc, I >>>>>>>>>> rephrased to: >>>>>>>>>>=20 >>>>>>>>>> "Recently, proposed >>>>>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>>>>> target=3D"RFC7713"/>), >>>>>>>>>> DCTCP or L4S >>>>>>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when = more than >>>>>>>>>> one >>>>>>>>>> marking is received in one RTT which is >>>>>>>>>> information that cannot be provided by the feedback = scheme as >>>>>>>>>> specified in >>>>>>>>>> ." >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>>> This document specifies an >>>>>>>>>>>>> experimental scheme to provide more than one feedback = signal per >>>>>>>>>>>>> RTT >>>>>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>>>>> overloads >>>>>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>>>>> provides >>>>>>>>>>>>> additional information in a new TCP option. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] This statement needs to be rewritten to correctly = reflect >>>>>>>>>>>>> what is >>>>>>>>>>>>=20 >>>>>>>>>>>> requested from IANA. My understanding is that this = experimental >>>>>>>>>>>> document >>>>>>>>>>>> asks for allocation of a reserved TCP header flag. This = needs to be >>>>>>>>>>>> called out >>>>>>>>>>>> prominently, IMHO. In addition, since this is not a = standard, the >>>>>>>>>>>> suggested >>>>>>>>>>>> experimentation with the main TCP header must IMHO be = explicitly >>>>>>>>>>>> mentioned. I also suggest to have later in a document a = section >>>>>>>>>>>> that >>>>>>>>>>>> explicitly >>>>>>>>>>>> explains why it is appropriate to modify the main TCP = header in an >>>>>>>>>>>> experiment. >>>>>>>>>>>>=20 >>>>>>>>>>>> I don=E2=80=99t know if any requirement that IANA = assignment need to be >>>>>>>>>>>> called >>>>>>>>>>>> out >>>>>>>>>>>> in the abstract but we can do that. However, I believe the = question >>>>>>>>>>>> if >>>>>>>>>>>> this >>>>>>>>>>>> document should or should not assign the bit is still not >>>>>>>>>>>> completely >>>>>>>>>>>> solved, or >>>>>>>>>>>> is it? >>>>>>>>>>>=20 >>>>>>>>>>> I believe this question will have to be reviewed during WGLC = and, >>>>>>>>>>> more >>>>>>>>>>> importantly, IETF last call. For the moment, my concern is = that the >>>>>>>>>>> document >>>>>>>>>>> correctly describes the IANA allocation. >>>>>>>>>>>=20 >>>>>>>>>>> I would like to see here a statement such as : "Given TCP = header >>>>>>>>>>> space is >>>>>>>>>>> scarce, this specification allocates a reserved header bit = and >>>>>>>>>>> overloads the >>>>>>>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>>>>>>=20 >>>>>>>>>> A bit lengthy but now: >>>>>>>>>>=20 >>>>>>>>>> "Given TCP header space is >>>>>>>>>> scarce, it allocates a reserved header bit, that was = previously >>>>>>>>>> used for >>>>>>>>>> ECN-Nonce which was recently declared historic, and = overloads >>>>>>>>>> the >>>>>>>>>> two existing ECN flags in the TCP header. Further, = additional >>>>>>>>>> information can be provided in a new TCP option that = however is >>>>>>>>>> not >>>>>>>>>> used >>>>>>>>>> on the TCP SYN." >>>>>>>>>>=20 >>>>>>>>>>>>> * 1. Introduction >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure = (ConEx >>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S = [I-D.ietf-tsvwg-l4s-arch] >>>>>>>>>>>>> need >>>>>>>>>>>>> more accurate ECN feedback information whenever more than = one >>>>>>>>>>>>=20 >>>>>>>>>>>> marking >>>>>>>>>>>>>=20 >>>>>>>>>>>>> is received in one RTT. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable = withoit this. >>>>>>>>>>>>> Instead >>>>>>>>>>>>=20 >>>>>>>>>>>> of stating a "need", it would IMHO make more sense to = discuss the >>>>>>>>>>>> benefits >>>>>>>>>>>> of the suggested mechanism in this document of its own, = independent >>>>>>>>>>>> of >>>>>>>>>>>> other proposals. To me, this document should be independent = of >>>>>>>>>>>> other >>>>>>>>>>>> documents and specifically other experiments. We have to = think >>>>>>>>>>>> about >>>>>>>>>>>> cases >>>>>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>>>>> documents >>>>>>>>>>>> will >>>>>>>>>>>> be more future-proof in future. >>>>>>>>>>>>=20 >>>>>>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant = to say that >>>>>>>>>>>> these >>>>>>>>>>>> mechanisms new more accurate ECN feedback than provided = today by >>>>>>>>>>>> RFC3168 but it was not meant to say that these mechanism = have to >>>>>>>>>>>> use the >>>>>>>>>>>> scheme as specified in this document. >>>>>>>>>>>>=20 >>>>>>>>>>>> I added the following part sentence: >>>>>>>>>>>>=20 >>>>>>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion = Exposure (ConEx >>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S = [I-D.ietf-tsvwg-l4s-arch] need >>>>>>>>>>>> more >>>>>>>>>>>> accurate ECN feedback information than provided by the = feedback >>>>>>>>>>>> scheme >>>>>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>>>>> received in >>>>>>>>>>>> one >>>>>>>>>>>> RTT. This document specifies an alternative feedback scheme = that >>>>>>>>>>>> provides >>>>>>>>>>>> more accurate information and could be used by these new = TCP >>>>>>>>>>>> extensions.=E2=80=9C >>>>>>>>>>>>=20 >>>>>>>>>>>> Does this help? >>>>>>>>>>>=20 >>>>>>>>>>> See my proposal for the abstract. I continue to disagree = with the >>>>>>>>>>> term >>>>>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>>>>>=20 >>>>>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>>>>> track, it is intended to be a complete replacement for = classic >>>>>>>>>>>>> TCP/ >>>>>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] This sentence should be removed, as this is = speculation. >>>>>>>>>>>>=20 >>>>>>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the = intent that we have. >>>>>>>>>>>>=20 >>>>>>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will = remain as >>>>>>>>>>>>> the >>>>>>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>>>>>=20 >>>>>>>>>>>> Why? Does it help to add an only here: >>>>>>>>>>>>=20 >>>>>>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will = remain as the >>>>>>>>>>>> only >>>>>>>>>>>> standards track specification for adding ECN to TCP.=E2=80=9C= >>>>>>>>>>>=20 >>>>>>>>>>> This wording is better. >>>>>>>>>>>=20 >>>>>>>>>>>>> AccECN feedback overloads flags and fields in the main TCP >>>>>>>>>>>>> header >>>>>>>>>>>>> with new definitions, so both ends have to support the new = wire >>>>>>>>>>>>> protocol before it can be used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] In my reading this experimental document asks for = *new* >>>>>>>>>>>>> allocation >>>>>>>>>>>>=20 >>>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>>>=20 >>>>>>>>>>>> Is this better? >>>>>>>>>>>>=20 >>>>>>>>>>>> "AccECN feedback overloads the two existing ECN flags as = well as >>>>>>>>>>>> the >>>>>>>>>>>> currently reserved and previously called NS flag in the = main >>>>>>>>>>>> TCP >>>>>>>>>>>> header >>>>>>>>>>>> with new definitions, so both ends have to support the = new >>>>>>>>>>>> wire >>>>>>>>>>>> protocol >>>>>>>>>>>> before it can be used.=E2=80=9C >>>>>>>>>>>>=20 >>>>>>>>>>>> I understand that you are not happy with the word = =E2=80=9Eoverload=E2=80=9C here >>>>>>>>>>>> but >>>>>>>>>>>> the >>>>>>>>>>>> point of this sentence really is that the flags can/could = be used >>>>>>>>>>>> differently >>>>>>>>>>>> and therefore we need a new negotiation before we can use = them. >>>>>>>>>>>=20 >>>>>>>>>>> For me the following would work: "AccECN feedback overloads = the two >>>>>>>>>>> existing ECN flags and >>>>>>>>>>> allocates the currently reserved and previously called NS = flag in >>>>>>>>>>> the >>>>>>>>>>> main TCP header. >>>>>>>>>>> Given the new definitions, both ends have to support the new = wire >>>>>>>>>>> protocol >>>>>>>>>>> before it can be used." >>>>>>>>>>>=20 >>>>>>>>>>> I believe the wording has to be crystal clear on the = reservation of >>>>>>>>>>> bit 7 >>>>>>>>>>> when it is discussed the first time in the text. In = follow-up >>>>>>>>>>> sections, >>>>>>>>>>> maybe shorter terms could be used. >>>>>>>>>>=20 >>>>>>>>>> Okay, now: >>>>>>>>>>=20 >>>>>>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>>>>>> allocates the currently reserved and previously called NS = flag in >>>>>>>>>> the >>>>>>>>>> TCP header, to be used as one field indicating the number = of >>>>>>>>>> congestion >>>>>>>>>> experienced marked packets. Given the new definitions of = these >>>>>>>>>> three >>>>>>>>>> bits, >>>>>>>>>> both ends have to support the new wire protocol before = it can >>>>>>>>>> be >>>>>>>>>> used. >>>>>>>>>> Therefore during the TCP handshake the two ends use these = three >>>>>>>>>> bit >>>>>>>>>> in >>>>>>>>>> the TCP header to negotiate the most advanced feedback = protocol >>>>>>>>>> that they can both support in a backward compatible way to >>>>>>>>>> ." >>>>>>>>>>>>=20 >>>>>>>>>>>> If you prefer, we can also remove the NS flag in this list, = as ECN >>>>>>>>>>>> Nonce >>>>>>>>>>>> was >>>>>>>>>>>> anyway never deployed. >>>>>>>>>>>>=20 >>>>>>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>>>>>> specifies a different response to TCP ECN feedback, for = example: >>>>>>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based = Low >>>>>>>>>>>>> Latency >>>>>>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>>>>>> ECN-capable TCP control packets = [I-D.ietf-tcpm-generalized-ecn], >>>>>>>>>>>>> or >>>>>>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this = paragraph >>>>>>>>>>>>> can >>>>>>>>>>>>> just >>>>>>>>>>>>=20 >>>>>>>>>>>> be deleted. If other experiments need more accurate = feedback, it is >>>>>>>>>>>> up >>>>>>>>>>>> to >>>>>>>>>>>> them to explain how they would use this mechanism. This = document >>>>>>>>>>>> should >>>>>>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it = better to be >>>>>>>>>>>> explicit >>>>>>>>>>>> about this? >>>>>>>>>>>>=20 >>>>>>>>>>>>> It is likely (but not required) that the AccECN protocol = will be >>>>>>>>>>>>> implemented along with the following experimental = additions to >>>>>>>>>>>>> the >>>>>>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>>>>>> retransmissions >>>>>>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the = ECN-capable >>>>>>>>>>>>> SYN/ >>>>>>>>>>>>> ACK experiment [RFC5562]; and testing receiver = non-compliance >>>>>>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my = view, >>>>>>>>>>>>> the >>>>>>>>>>>>> TCPM >>>>>>>>>>>>=20 >>>>>>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn = and >>>>>>>>>>>> draft-ietf- >>>>>>>>>>>> tcpm-generalized-ecn independent documents, which probably = implies >>>>>>>>>>>> that >>>>>>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If >>>>>>>>>>>> experimentation >>>>>>>>>>>> with ECT in SYN requires a combination, this could be done = in a >>>>>>>>>>>> new, >>>>>>>>>>>> third >>>>>>>>>>>> document. Apart from having simpler focused documents, this = could >>>>>>>>>>>> significantly help later with moving forward documents to = standards >>>>>>>>>>>> track. >>>>>>>>>>>>=20 >>>>>>>>>>>> I disagree, however, this is a discussion to have on >>>>>>>>>>>> draft-ietf-tcpm- >>>>>>>>>>>> generalized-ecn. I don=E2=80=99t see a problem in = providing a reference >>>>>>>>>>>> here >>>>>>>>>>>> that >>>>>>>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing = more. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] A macroscopic comment is that this document has a lot = of >>>>>>>>>>>>> introduction >>>>>>>>>>>>=20 >>>>>>>>>>>> and tutorial text with lot's of redundancy towards other = documents. >>>>>>>>>>>> I >>>>>>>>>>>> think >>>>>>>>>>>> the document can be made much easier to read by shorten it. = In many >>>>>>>>>>>> cases >>>>>>>>>>>> this is just an editorial change as there is redundancy. As = one >>>>>>>>>>>> such >>>>>>>>>>>> example, >>>>>>>>>>>> just remove this section. >>>>>>>>>>>>=20 >>>>>>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big = fan of short >>>>>>>>>>>> and >>>>>>>>>>>> concise >>>>>>>>>>>> documents, however, some redundancy can also help = understanding, >>>>>>>>>>>> especially if you explain things multiple times but with a >>>>>>>>>>>> different >>>>>>>>>>>> level of >>>>>>>>>>>> detail. I personally would not need the roadmap but I know = many >>>>>>>>>>>> people >>>>>>>>>>>> who find these things helpful and to be honest I don=E2=80=99= t see how >>>>>>>>>>>> removing >>>>>>>>>>>> this >>>>>>>>>>>> part makes the doc any better. If you don=E2=80=99t want = it, don=E2=80=99t read it. >>>>>>>>>>>>=20 >>>>>>>>>>>>> * 1.2. Goals >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>>>>>=20 >>>>>>>>>>>> I have to say I also don=E2=80=99t see the point of = removing this part. >>>>>>>>>>>> Given >>>>>>>>>>>> we=E2=80=99ve >>>>>>>>>>>> done the work on requirements, I think we should also link = to this >>>>>>>>>>>> doc >>>>>>>>>>>> somewhere. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>>>>>=20 >>>>>>>>>>>>> TCP is critical to the robust functioning of the Internet, >>>>>>>>>>>>> therefore >>>>>>>>>>>>> any proposed modifications to TCP need to be thoroughly = tested. >>>>>>>>>>>>> The >>>>>>>>>>>>> present specification describes an experimental protocol = that >>>>>>>>>>>>> adds >>>>>>>>>>>>> more accurate ECN feedback to the TCP protocol. The = intention >>>>>>>>>>>>> is to >>>>>>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>>>>>> implementation can be built in order to test its function, >>>>>>>>>>>>> robustness >>>>>>>>>>>>> and interoperability (with itself and with previous = version of >>>>>>>>>>>>> ECN >>>>>>>>>>>>> and TCP). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] I think all what is written in this paragraph is = obvious, no? >>>>>>>>>>>>> Can't we just >>>>>>>>>>>>=20 >>>>>>>>>>>> delete this? >>>>>>>>>>>>=20 >>>>>>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it = out. For me both >>>>>>>>>>>> is >>>>>>>>>>>> fine, keep it >>>>>>>>>>>> or remove it. >>>>>>>>>>>>=20 >>>>>>>>>>>>> The experimental protocol will be considered successful if = it is >>>>>>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] = in >>>>>>>>>>>>> the >>>>>>>>>>>>> consensus opinion of the IETF tcpm working group. In = short, >>>>>>>>>>>>> this >>>>>>>>>>>>> requires that it improves the accuracy and timeliness of = TCP's >>>>>>>>>>>>> ECN >>>>>>>>>>>>> feedback, as claimed in Section 5, while striking a = balance >>>>>>>>>>>>> between >>>>>>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>>>>>> minimisation of overhead. It also requires that it is not >>>>>>>>>>>>> unduly >>>>>>>>>>>>> complex, and that it is compatible with prevalent = equipment >>>>>>>>>>>>> behaviours in the current Internet (e.g. hardware = offloading and >>>>>>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case = of >>>>>>>>>>>>> middlebox interference. Current recommended strategies = are >>>>>>>>>>>>> specified >>>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The = effectiveness of >>>>>>>>>>>>> these strategies depends on the actual deployment = situation of >>>>>>>>>>>>> middleboxes. Therefore experimental verification to = confirm >>>>>>>>>>>>> large- >>>>>>>>>>>>> scale path traversal in the Internet is needed before = finalizing >>>>>>>>>>>>> this >>>>>>>>>>>>> specification on the Standards Track. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I = have >>>>>>>>>>>>=20 >>>>>>>>>>>> mentioned before, I don't think an RFC should speculate = about TCPM >>>>>>>>>>>> and >>>>>>>>>>>> its >>>>>>>>>>>> consensus opinion. I would suggest a wording along the = lines of: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> >>>>>>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>>>>>> testing confirms that the proposed mechanism can be = deployed at >>>>>>>>>>>>> large >>>>>>>>>>>>=20 >>>>>>>>>>>> scale. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case = of >>>>>>>>>>>>> middlebox interference. Current recommended strategies = are >>>>>>>>>>>>> specified >>>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The = effectiveness of >>>>>>>>>>>>> these strategies depends on the actual deployment = situation of >>>>>>>>>>>>> middleboxes. Therefore experimental verification to = confirm >>>>>>>>>>>>> large- >>>>>>>>>>>>> scale path traversal in the Internet is needed, e.g., by = support >>>>>>>>>>>>> in >>>>>>>>>>>>> major TCP stacks. >>>>>>>>>>>>> >>>>>>>>>>>>>=20 >>>>>>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t = think that the >>>>>>>>>>>> paraphrase >>>>>>>>>>>> speculates about the consensus of tcpm, in contrast it say = tcpm has >>>>>>>>>>>> to >>>>>>>>>>>> decided if the requirements previously specified by tcpm = are >>>>>>>>>>>> sufficiently >>>>>>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the = requirement >>>>>>>>>>>> draft as >>>>>>>>>>>> this >>>>>>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>>>>>=20 >>>>>>>>>>> My suggested wording uses the expression "can be deployed at = large >>>>>>>>>>> scale" >>>>>>>>>>> and I believe this is relevant. >>>>>>>>>>>=20 >>>>>>>>>>> The document already describes in Section 5 how the protocol >>>>>>>>>>> satisfies >>>>>>>>>>> the agreed requirements for a more accurate ECN feedback = protocol >>>>>>>>>>> [RFC7560]. >>>>>>>>>>> So, if the TCPM working group publishes this document with = the >>>>>>>>>>> content of >>>>>>>>>>> Section 5, I believe the TCPM working group already has = reached >>>>>>>>>>> consensus >>>>>>>>>>> that the protocol meets requirements. In addition, it is = possible >>>>>>>>>>> that new >>>>>>>>>>> requirements would be identified in future, e.g., as an = outcome of >>>>>>>>>>> the >>>>>>>>>>> experiment, and that would obviously have to be considered = by TCPM. >>>>>>>>>>> In that >>>>>>>>>>> case, for the success of the experiment not only RFC 7560 = would >>>>>>>>>>> matter, but >>>>>>>>>>> also further requirements. My proposed wording does not have = all >>>>>>>>>>> these >>>>>>>>>>> problems. >>>>>>>>>>>=20 >>>>>>>>>>> In a nutshell, I continue to believe that this section has = to >>>>>>>>>>> change. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Okay, used your proposed wording. You have a point about the >>>>>>>>>> requirement >>>>>>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be = deployed >>>>>>>>>> large-scale=E2=80=9C. >>>>>>>>>>=20 >>>>>>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The last bit in byte 13 of the TCP header was defined as = the >>>>>>>>>>>>> Nonce >>>>>>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never >>>>>>>>>>>>> deployed >>>>>>>>>>>>> so >>>>>>>>>>>>> it is being reclassified as historic, making this TCP flag >>>>>>>>>>>>> available >>>>>>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into = account >>>>>>>>>>>>> the >>>>>>>>>>>>> IANA >>>>>>>>>>>>=20 >>>>>>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is = published. >>>>>>>>>>>>=20 >>>>>>>>>>>> Is does. However, I can explicitly say that is has be = re-clssified >>>>>>>>>>>> as >>>>>>>>>>>> reserved. >>>>>>>>>>>>=20 >>>>>>>>>>>> "RFC 3540 was never deployed so it is being reclassified as >>>>>>>>>>>> historic >>>>>>>>>>>> [I-D.ietf- >>>>>>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been = marked >>>>>>>>>>>> as >>>>>>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags = registry, making this TCP >>>>>>>>>>>> flag >>>>>>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>>>>>=20 >>>>>>>>>>>> Better? >>>>>>>>>>>>=20 >>>>>>>>>>>>> In my understanding, this experimental document asks for = new >>>>>>>>>>>>> assignment >>>>>>>>>>>>=20 >>>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>>>=20 >>>>>>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded = this discussion >>>>>>>>>>>> yet. >>>>>>>>>>>> However, >>>>>>>>>>>> what we really would want to is mention somewhere that this >>>>>>>>>>>> experiment >>>>>>>>>>>> with this flags is running. I guess there are three = options: >>>>>>>>>>>> 1) keep it in the registry as reserved and conserve the = knowledge >>>>>>>>>>>> in >>>>>>>>>>>> tcpm >>>>>>>>>>>> that this experiment is running and no other experimental = RFC such >>>>>>>>>>>> use >>>>>>>>>>>> this >>>>>>>>>>>> flags as long as this experiment is running. >>>>>>>>>>>> 2) Keep is marked as reserved but add a note about this = experiment >>>>>>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>> IANA registry >>>>>>>>>>>> 3) Or assign it right away with IESG approval. I guess in = this case >>>>>>>>>>>> tcpm >>>>>>>>>>>> could >>>>>>>>>>>> also consider to change the registration policy to =E2=80=9EI= ETF Review=E2=80=9C. >>>>>>>>>>>=20 >>>>>>>>>>> The current registration policy for the TCP header flags is >>>>>>>>>>> "standards >>>>>>>>>>> action". I understand that the IESG could approve = exceptions. But >>>>>>>>>>> given the >>>>>>>>>>> policy, I believe the document has to be very precise on the = request >>>>>>>>>>> regarding bit 7. >>>>>>>>>>=20 >>>>>>>>>> Okay, it now says: >>>>>>>>>>=20 >>>>>>>>>> "[TO BE REMOVED: IANA is requested to update the existing = entry in >>>>>>>>>> the >>>>>>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>>>>>>=20 >>>>>>>>>> = (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#= tcp-header-flags-1) >>>>>>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic = as NS >>>>>>>>>> (Nonce >>>>>>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this = RFC-to-be >>>>>>>>>> instead >>>>>>>>>> of RFC8311.]=E2=80=9C >>>>>>>>>>=20 >>>>>>>>>> I guess we could also ask IANA to add an additional comment = column >>>>>>>>>> instead >>>>>>>>>> (but not sure if we then have to update RFC3168, which I = think we >>>>>>>>>> really >>>>>>>>>> don=E2=80=99t want. Should be fine now. >>>>>>>>>>=20 >>>>>>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>>>>>=20 >>>>>>>>>>>>> o an essential part that re-uses ECN TCP header bits to = feed >>>>>>>>>>>>> back >>>>>>>>>>>>> the number of arriving CE marked packets. This = provides more >>>>>>>>>>>>> accuracy than classic ECN feedback, but limited = resilience >>>>>>>>>>>>> against >>>>>>>>>>>>> ACK loss; >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think this is nit picking. Using a different phrasing = here makes >>>>>>>>>>>> the >>>>>>>>>>>> sentence >>>>>>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how = get a round the >>>>>>>>>>>> fact >>>>>>>>>>>> that we need to handle the flag registration correctly. = However, >>>>>>>>>>>> here >>>>>>>>>>>> the >>>>>>>>>>>> point really is to explain how the protocol word. The main = point of >>>>>>>>>>>> using the >>>>>>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say = that these flags are or >>>>>>>>>>>> have >>>>>>>>>>>> been >>>>>>>>>>>> used different by other TCP extension (and we therefore = need a >>>>>>>>>>>> proper >>>>>>>>>>>> negotiation scheme). >>>>>>>>>>>=20 >>>>>>>>>>> If the allocation of a reserved flag is correctly explained = in the >>>>>>>>>>> abstract and introduction, I think these sentences can use a = bit >>>>>>>>>>> relaxed >>>>>>>>>>> terminology. >>>>>>>>>>>=20 >>>>>>>>>>>>> The two part design was necessary, given limitations on = the >>>>>>>>>>>>> space >>>>>>>>>>>>> available for TCP options and given the possibility that = certain >>>>>>>>>>>>> incorrectly designed middleboxes prevent TCP using any new >>>>>>>>>>>>> options >>>>=20 >>>>=20 >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Fri Jul 13 13:46:16 2018 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 9225E130F2D for ; Fri, 13 Jul 2018 13:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 9NqrcFLnVoGi for ; Fri, 13 Jul 2018 13:46:09 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 544ED130E25 for ; Fri, 13 Jul 2018 13:46:09 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id s7-v6so13229419itb.4 for ; Fri, 13 Jul 2018 13:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CgIVW52ZbwfMSHaFBz055xSjVJ8w3uWHMD0uPJL7lzs=; b=C8tTAuo8zMtHXMGE92ee76OAXj7i0E6LLpJehZP/AraTizIa7tijqMFG0EKLGKxiEU b2mcCy2WCshG7iBK5bcEvDyKpKjdaWOXAtDRGQKFIABeHMpTpDhQqik7W/970hMu+85q evEfsoCfXIh/bC0IejqCUXlDI4t6QezY7fE2W3p7XYuJ4dfTS8+9aQE6Tzu2MTviXdkV 0zHlV7LgEJvDJ46o30WROZz5YSSVwYIotn2f15m8nXm1FBmkcyBKBhqyszBAIn6rqVnC mHh2cVlVhHQ7FUUeNBoInKuOPfzkedPEbxvxu7vAojed9omXV3fItxVcdbaosdQ5U7KM yNvA== 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:content-transfer-encoding; bh=CgIVW52ZbwfMSHaFBz055xSjVJ8w3uWHMD0uPJL7lzs=; b=YIVIApqpkD0gOf2X85rOdkP50VMLl8Yy5Q6aQjp60R6Nwl4lsYhyEMj+xfkFeH3reY +3GgY8MI0WGJ/Q/AE/ASoNIcDz5AuRuo7UBe47PJAvmb6az9lW2CcoawVXt49Jb8jsJb 2kicK4xeBrvgSSvOYe9JVEdFcTD4ZqYDQR8bhg8hwG725npxbw8ynLqeOwxFTCX452s3 6JMYSYWUroggceRzGql6JbOj7gD8V+oIhA2B+g5v49agI3MXQEBvZ96f50vNOdI4kwJj nyJNeW2O4aTaMLiNNVCHUGtlYgXjN+Bxj+jan/A+ePdjVYJLgG9fqjBXrIzTmMjpqtyT cvUw== X-Gm-Message-State: AOUpUlE6fu2HEMxBkoBDUX9TPVzUYvCNYqbIpspSzYgHmg5JA7A7ajj9 tSEXJvSLMWdbEPYSTHvTKyMblEvCN+LfMBTlaghJiA== X-Google-Smtp-Source: AAOMgpfC1Uo4IVUYthYb2vGLno3wif6h3jTjSyAvBH6DJ6GmuVeHhY4mwDka+hWKVK2NVUyfFgy947P7Mg0Tdn6S304= X-Received: by 2002:a24:9003:: with SMTP id x3-v6mr6062400itd.139.1531514767972; Fri, 13 Jul 2018 13:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5e:c10d:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 13:45:27 -0700 (PDT) In-Reply-To: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> From: Yuchung Cheng Date: Fri, 13 Jul 2018 13:45:27 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 20:46:15 -0000 On Fri, Jul 13, 2018 at 12:42 PM, Mirja K=C3=BChlewind wrote: > Hi Yuchung, > >> Am 13.07.2018 um 15:30 schrieb Yuchung Cheng : >> >> On Fri, Jul 13, 2018 at 11:53 AM, Mirja K=C3=BChlewind >> wrote: >>> Hi Yucheng, >>> >>> please see below. >>> >>>> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng : >>>> >>>> hi -- >>>> >>>> I agree: >>>> 1. delayed/streched ACK aren't going away (in fact will be more common= ) >>>> 2. GRO isn't and should not be a show-stopper >>>> 3. SYN option is running tight >>>> 4. HW opt comes after SW >>>> >>>> I worry: >>>> 1. GRO is a unavoidable issue in deployment (let's not produce an >>>> undeployable RFC). the ACE counter won't work as GRO can pack up to >>>> 64KB/MTU =3D~ 45 pkts under heavy congestion. >>>> >>>> 2. ACE's benefit over DCTCP is when delayed ACKs and ack losses >>>> happen. Now delayed ACKs happen frequently when the messages are >>>> small, which means they don't solicit too many ACKs to be dropped in >>>> the reverse path. Also that under heavy downstream loss or reordering, >>>> >>>> 3 SACK options become dominant to have ACE option. >>>> >>>> 4. If SYN option space is a concern, ACE header exchange is ok. But I >>>> suspect the latter has more middlebox issue based on my TFO deployment >>>> experience. >>>> >>>> >>>> So with all that said, is it possible to have a "minimal"-ACE that >>>> 1. Does ACE handshake as proposed >>>> 2. Mark ECT on all (or at least SYN & data & rtx) packets like ECN++ >>> >>> This is ECN++ and independent of AccECN. We on purposed have split the = feedback and usage of ECN (which is not the case in RFC3168) to be able to = change things in future independently >> sure - IMO marking all packets just improve the accuracy significantly >> vs the counters and options. For example, ECN on SYN is very useful on >> incast / loaded link. > > Yes, but to be able to mark control packets as ECN-enables you also need = a way to feedback congestion experienced information if they appear on thes= e packets. Therefore you can use ECN++ only safely with e.g. AccECN feedbac= k (but not with classic RFC3168 ECN feedback). Still these two things shoul= d be specified in separate documents to be able to change them separately i= n future. >> >>> >>>> 3. Leave ACE-count and ACE option optional (i.e. MAY) >>> >>> I don=E2=80=99t understand this. If both is optional, you don=E2=80=99t= have any feedback. Or what do you mean by =E2=80=9Eleave ACE-count optiona= l=E2=80=9C? >> use-case: We can negotiate DCTCP-style ECN for the internet. >> >> Then interested parties can progressively experiment on more accurate >> "options" (!=3D TCP-option) > > As Appendix A of RFC7560 says I don=E2=80=99t think it is a safe option f= or the Internet where packet loss more likely then in a full ECN-enabled da= ta center. Again I disagree RFC7560 Appendix A is a big problem based on my experience with at times loss-heavy ECN-enabled data-center (Google data-center runs very hot and uses a DCTCP-variant). We can quabble forever w/o data. That's why I asked for some (non-simulation) data. > > Mirja > > > >> >>> >>> Mirja >>> >>> >>> >>>> >>>> as a "fairly safe" to deployment compromise. And I am happy to draft a >>>> kernel patch for that :-) >>>> >>>> >>>> >>>> On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe wro= te: >>>>> Yuchung, >>>>> >>>>> On 12/07/18 17:03, Mirja K=C3=BChlewind wrote: >>>>>> >>>>>> Hi Yuchung, >>>>>> >>>>>> please see below. >>>>>> >>>>>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>>>>>> >>>>>>> Yes packets with ACE options and (different) ACE-counter header wou= ld >>>>>>> break GRO. There're many legacy h/w and s/w. >>>>>> >>>>>> I=E2=80=99m not the expert here but my understanding is that is woul= d not break >>>>>> GRO but could not make actual use or it if the ACE counter changed o= r the >>>>>> option is present. >>>>> >>>>> [BB] Yuchung's criticism applies to any scheme that feeds back a cont= inually >>>>> changing signal like ECN. For instance, like AccECN feedback, DCTCP E= CN >>>>> feedback continually changes the TCP header flags, and I believe DCTC= P is >>>>> widely used in DCs. >>>>> >>>>> I believe, to make GRO support ECN feedback (whether DCTCP or AccECN)= , it >>>>> would be necessary for GRO to know which bits to mask when determinin= g >>>>> whether a packet is mergeable with others. I believe GRO already coll= ects >>>>> header fields separately for the TCP logic to be able to work on them= , but >>>>> I'm also not an expert. >>>>>> >>>>>> However, usually your will only have a small number of CE marks ever= y >>>>>> couple of RTTs, and the counter only changes if you CE marks/the opt= ion is >>>>>> only present a few times per RTT. So the impact should be rather low= . But >>>>>> this clear something to evaluate for the experiment. >>>>> >>>>> [BB] With DCTCP as currently designed, you tend to get runs of 100% C= E if >>>>> the load of short flows is very small. In that case, DCTCP feedback w= ill >>>>> change the header flags less often than AccECN. However, with more sh= ort >>>>> flows, the feedback is more on-off. Then the flags change more often = with >>>>> DCTCP than with AccECN feedback. >>>>> >>>>> In general, hardware optimization is not going to optimize a protocol= that >>>>> didn't exist when the hardware was designed. It would be ideal to des= ign a >>>>> new protocol that takes advantage of existing hardware optimization. >>>>> However, as long as an experimental protocol still works with existin= g >>>>> hardware, I think it's reasonable to assume that hardware optimizatio= n will >>>>> only arrive once a protocol has become well-established. >>>>> >>>>>> >>>>>>> Even without option, ACE header only allows reflecting up to 8 pack= ets >>>>>>> for receiver segmentation offload and ACK suppression? >>>>>> >>>>>> Same as above, it can only up to 8 CE marked packets per ACK, howeve= r, CE >>>>>> marking rater are expected to be rather low. ACK suppression should = probably >>>>>> not be used if the ACE counter has changes, however, usually the ACE= counter >>>>>> stays stable for multiple RTTs and then ACK suppression is not a pro= blem. >>>>>> However, not sure I understood you question here correctly=E2=80=A6? >>>>>> >>>>>>> The appendix on ack loss causes ambiguity is good: but the pattern >>>>>>> drops specifically the state-switch (CE<->noCE) ACK which only happ= ens >>>>>>> on delayed ACK. Is that pattern common? - or can we address most of >>>>>>> that by delaying less ACKs? >>>>>> >>>>>> I guess you have a 50% chance today to hit a delayed ACK. I guess de= laying >>>>>> less (where you delay every second ACK today) would mean ACK every p= acket, >>>>>> and thus double ACK load on the network. I guess on today networks t= hat >>>>>> actually in most cases not a problem, however, there might be specia= lly >>>>>> cases where it is. However, that=E2=80=99s problem an independent qu= estion to >>>>>> evaluate. >>>>> >>>>> [BB] If there were no delayed ACKs, the problem with DCTCP feedback w= ould >>>>> largely disappear. But delayed ACKs are not going away. Which is why = we >>>>> proposed replacing DCTCP feedback with AccECN feedback. >>>>>> >>>>>> >>>>>>> I am all for making ECN more accurate for wide area beyond DCTCP, b= ut >>>>>>> am evaluating the pros/cons. What if we just >>>>>>> 1. negotiate 'better' ECN via new SYN option >>>>>> >>>>>> Not sure I understand your proposal correctly, but I assume you mean >>>>>> negotiate via SYN option and then just use the ACE counter in the he= ader? If >>>>>> so, I don=E2=80=99t understand why you see the negotiation part in t= he TCP header as >>>>>> the problem? >>>>> >>>>> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a s= olution >>>>> without a problem. In fact an option on the SYN would create a new pr= oblem >>>>> 'cos of the severe shortage of space for SYN options (for this reason= , the >>>>> AccECN TCP option was designed not to be needed on the SYN). >>>>>> >>>>>> >>>>>>> 2. mark all packets like ECN++ >>>>>> >>>>>> That would be nice but here you actually need AccECN because you wan= t to >>>>>> have feedback for control packets as well. AccECN is providing this >>>>>> feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; t= hat=E2=80=99s what we have ECN++ >>>>>> for; both thing ideally would be deployed together however. Was that= your >>>>>> questions? >>>>> >>>>> Cheers >>>>> >>>>> >>>>> Bob >>>>> >>>>>> Mirja >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Yuchung, >>>>>>>> >>>>>>>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy r= eally depends on the >>>>>>>> use case. If you use DCTCP as today, the ACE counter in the TCP is= probably >>>>>>>> sufficient and you might not want to pay the additional overhead i= n your >>>>>>>> data center (that why the option is actually optional). >>>>>>>> >>>>>>>> If you however, e.g., have very differently sized packets, then th= e byte >>>>>>>> counter in the option could give you a more accurate signal. Or if= you are >>>>>>>> also interested in the ECT(1) counter, you need the option. Furthe= r the ACE >>>>>>>> counter also give your feedback on control packet and the option e= nables you >>>>>>>> to distinguish between CE-amrked payload and control packets, whic= h can also >>>>>>>> become important when experimenting with making all packets ECN-ca= pable. >>>>>>>> >>>>>>>> Given accECN is a general feedback mechanism that in fact is desig= ned to >>>>>>>> enable new future uses of the ECN signal, we wanted to keep all th= ese option >>>>>>>> available while making is still as simple as possible and as flexi= ble as >>>>>>>> possible. >>>>>>>> >>>>>>>> Mirja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>>>>>>> >>>>>>>>> Hi Bob, >>>>>>>>> >>>>>>>>> Neal and I evaluated the earlier draft. It is well-thought out bu= t >>>>>>>>> we're concerned about the options. Option is not mandatory but th= e >>>>>>>>> lack of it also reduces accuracy. Option runs into space issues w= / >>>>>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sur= e but >>>>>>>>> aren't easy. >>>>>>>>> >>>>>>>>> We're curious how much more "accuracy" it buys over current >>>>>>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Michael, tcpm list, >>>>>>>>>> >>>>>>>>>> As well as addressing your points, as Mirja has already mentione= d >>>>>>>>>> below, we >>>>>>>>>> added a whole new appendix giving the rationale for the bits and >>>>>>>>>> codepoints >>>>>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A = 3rd >>>>>>>>>> subsection also identifies space for future evolution. It also p= oints >>>>>>>>>> to >>>>>>>>>> where rationale was already given in the body of the draft. >>>>>>>>>> >>>>>>>>>> The appendix is in the draft submitted last week, available here= : >>>>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appe= ndix-B >>>>>>>>>> >>>>>>>>>> We'd be interested to hear whether this allays your concerns. >>>>>>>>>> >>>>>>>>>> We have asked to present this in Montreal as well. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bob >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Micheal, >>>>>>>>>>> >>>>>>>>>>> I addressed a couple of your comments below. >>>>>>>>>>> >>>>>>>>>>> For the other, bigger comments regarding extensibility, that I = did >>>>>>>>>>> not yet >>>>>>>>>>> address below, we plan to add a new section to the appendix to >>>>>>>>>>> explain >>>>>>>>>>> extensibility options as previously discussed by mail. We will >>>>>>>>>>> probably send >>>>>>>>>>> a separate email on that part. >>>>>>>>>>> >>>>>>>>>>> Mirja >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> Hi Mirja, >>>>>>>>>>>> >>>>>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some of= the >>>>>>>>>>>> editorial suggestions. >>>>>>>>>>>> >>>>>>>>>>>> Yet, I continue to believe that some formal wording in the doc= ument >>>>>>>>>>>> needs >>>>>>>>>>>> to change, as explained below. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.et= hz.ch] >>>>>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>>>>>> >>>>>>>>>>>>> Please see inline. >>>>>>>>>>>>> >>>>>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>>> >>>>>>>>>>>>> : >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>>>>>> appendix). I >>>>>>>>>>>>> >>>>>>>>>>>>> believe this document needs further work before moving forwar= d. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please find below my comments marked as [ms]. I have read th= e >>>>>>>>>>>>> >>>>>>>>>>>>> document independent of the review from Gorry. I apologize if= there >>>>>>>>>>>>> is >>>>>>>>>>>>> duplication. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ****************************** >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Abstract: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx= ) or >>>>>>>>>>>>>> Data >>>>>>>>>>>>> >>>>>>>>>>>>> Center TCP >>>>>>>>>>>>>> >>>>>>>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever >>>>>>>>>>>>>> more >>>>>>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC 825= 7. I >>>>>>>>>>>>>> suggest to >>>>>>>>>>>>> >>>>>>>>>>>>> remove this, or replace it by a more generic statement that m= ore >>>>>>>>>>>>> accurate >>>>>>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>>>>>> >>>>>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate informati= on. >>>>>>>>>>>>> They do >>>>>>>>>>>>> not need the mechanism that is specified in this draft, howev= er, >>>>>>>>>>>>> this is >>>>>>>>>>>>> not >>>>>>>>>>>>> what the sentences is saying. >>>>>>>>>>>> >>>>>>>>>>>> In my understanding (as a non-native speaker), the use of the = word >>>>>>>>>>>> "need" >>>>>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>>>>>> implemented >>>>>>>>>>>> without any such mechanism. >>>>>>>>>>>> >>>>>>>>>>>> What would work for me is something of the form "... Data Cent= er TCP >>>>>>>>>>>> cannot get precise ECN feedback whenever more than one marking= is >>>>>>>>>>>> received >>>>>>>>>>>> in one RTT=E2=80=9C. >>>>>>>>>>> >>>>>>>>>>> This is not correct. DCTP need more than one feedback signal pe= r RTT >>>>>>>>>>> and >>>>>>>>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99s= own feedback >>>>>>>>>>> mechanism. However, to avoid confusion such that people could a= ssume >>>>>>>>>>> DCTP >>>>>>>>>>> would not work without the accECN scheme as specified in this d= oc, I >>>>>>>>>>> rephrased to: >>>>>>>>>>> >>>>>>>>>>> "Recently, proposed >>>>>>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>>>>>> target=3D"RFC7713"/>), >>>>>>>>>>> DCTCP or L4S >>>>>>>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when more= than >>>>>>>>>>> one >>>>>>>>>>> marking is received in one RTT which is >>>>>>>>>>> information that cannot be provided by the feedback scheme = as >>>>>>>>>>> specified in >>>>>>>>>>> ." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> This document specifies an >>>>>>>>>>>>>> experimental scheme to provide more than one feedback signal= per >>>>>>>>>>>>>> RTT >>>>>>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>>>>>> overloads >>>>>>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>>>>>> provides >>>>>>>>>>>>>> additional information in a new TCP option. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] This statement needs to be rewritten to correctly refle= ct >>>>>>>>>>>>>> what is >>>>>>>>>>>>> >>>>>>>>>>>>> requested from IANA. My understanding is that this experiment= al >>>>>>>>>>>>> document >>>>>>>>>>>>> asks for allocation of a reserved TCP header flag. This needs= to be >>>>>>>>>>>>> called out >>>>>>>>>>>>> prominently, IMHO. In addition, since this is not a standard,= the >>>>>>>>>>>>> suggested >>>>>>>>>>>>> experimentation with the main TCP header must IMHO be explici= tly >>>>>>>>>>>>> mentioned. I also suggest to have later in a document a secti= on >>>>>>>>>>>>> that >>>>>>>>>>>>> explicitly >>>>>>>>>>>>> explains why it is appropriate to modify the main TCP header = in an >>>>>>>>>>>>> experiment. >>>>>>>>>>>>> >>>>>>>>>>>>> I don=E2=80=99t know if any requirement that IANA assignment = need to be >>>>>>>>>>>>> called >>>>>>>>>>>>> out >>>>>>>>>>>>> in the abstract but we can do that. However, I believe the qu= estion >>>>>>>>>>>>> if >>>>>>>>>>>>> this >>>>>>>>>>>>> document should or should not assign the bit is still not >>>>>>>>>>>>> completely >>>>>>>>>>>>> solved, or >>>>>>>>>>>>> is it? >>>>>>>>>>>> >>>>>>>>>>>> I believe this question will have to be reviewed during WGLC a= nd, >>>>>>>>>>>> more >>>>>>>>>>>> importantly, IETF last call. For the moment, my concern is tha= t the >>>>>>>>>>>> document >>>>>>>>>>>> correctly describes the IANA allocation. >>>>>>>>>>>> >>>>>>>>>>>> I would like to see here a statement such as : "Given TCP head= er >>>>>>>>>>>> space is >>>>>>>>>>>> scarce, this specification allocates a reserved header bit and >>>>>>>>>>>> overloads the >>>>>>>>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>>>>>>> >>>>>>>>>>> A bit lengthy but now: >>>>>>>>>>> >>>>>>>>>>> "Given TCP header space is >>>>>>>>>>> scarce, it allocates a reserved header bit, that was previo= usly >>>>>>>>>>> used for >>>>>>>>>>> ECN-Nonce which was recently declared historic, and overloa= ds >>>>>>>>>>> the >>>>>>>>>>> two existing ECN flags in the TCP header. Further, addition= al >>>>>>>>>>> information can be provided in a new TCP option that howeve= r is >>>>>>>>>>> not >>>>>>>>>>> used >>>>>>>>>>> on the TCP SYN." >>>>>>>>>>> >>>>>>>>>>>>>> * 1. Introduction >>>>>>>>>>>>>> >>>>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConE= x >>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] >>>>>>>>>>>>>> need >>>>>>>>>>>>>> more accurate ECN feedback information whenever more than on= e >>>>>>>>>>>>> >>>>>>>>>>>>> marking >>>>>>>>>>>>>> >>>>>>>>>>>>>> is received in one RTT. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit= this. >>>>>>>>>>>>>> Instead >>>>>>>>>>>>> >>>>>>>>>>>>> of stating a "need", it would IMHO make more sense to discuss= the >>>>>>>>>>>>> benefits >>>>>>>>>>>>> of the suggested mechanism in this document of its own, indep= endent >>>>>>>>>>>>> of >>>>>>>>>>>>> other proposals. To me, this document should be independent o= f >>>>>>>>>>>>> other >>>>>>>>>>>>> documents and specifically other experiments. We have to thin= k >>>>>>>>>>>>> about >>>>>>>>>>>>> cases >>>>>>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>>>>>> documents >>>>>>>>>>>>> will >>>>>>>>>>>>> be more future-proof in future. >>>>>>>>>>>>> >>>>>>>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant to= say that >>>>>>>>>>>>> these >>>>>>>>>>>>> mechanisms new more accurate ECN feedback than provided today= by >>>>>>>>>>>>> RFC3168 but it was not meant to say that these mechanism have= to >>>>>>>>>>>>> use the >>>>>>>>>>>>> scheme as specified in this document. >>>>>>>>>>>>> >>>>>>>>>>>>> I added the following part sentence: >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Exposu= re (ConEx >>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] = need >>>>>>>>>>>>> more >>>>>>>>>>>>> accurate ECN feedback information than provided by the feedba= ck >>>>>>>>>>>>> scheme >>>>>>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>>>>>> received in >>>>>>>>>>>>> one >>>>>>>>>>>>> RTT. This document specifies an alternative feedback scheme t= hat >>>>>>>>>>>>> provides >>>>>>>>>>>>> more accurate information and could be used by these new TCP >>>>>>>>>>>>> extensions.=E2=80=9C >>>>>>>>>>>>> >>>>>>>>>>>>> Does this help? >>>>>>>>>>>> >>>>>>>>>>>> See my proposal for the abstract. I continue to disagree with = the >>>>>>>>>>>> term >>>>>>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>>>>>> >>>>>>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>>>>>> track, it is intended to be a complete replacement for class= ic >>>>>>>>>>>>>> TCP/ >>>>>>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] This sentence should be removed, as this is speculation= . >>>>>>>>>>>>> >>>>>>>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the inte= nt that we have. >>>>>>>>>>>>> >>>>>>>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain = as >>>>>>>>>>>>>> the >>>>>>>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>>>>>> >>>>>>>>>>>>> Why? Does it help to add an only here: >>>>>>>>>>>>> >>>>>>>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain = as the >>>>>>>>>>>>> only >>>>>>>>>>>>> standards track specification for adding ECN to TCP.=E2=80=9C >>>>>>>>>>>> >>>>>>>>>>>> This wording is better. >>>>>>>>>>>> >>>>>>>>>>>>>> AccECN feedback overloads flags and fields in the main TCP >>>>>>>>>>>>>> header >>>>>>>>>>>>>> with new definitions, so both ends have to support the new w= ire >>>>>>>>>>>>>> protocol before it can be used. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] In my reading this experimental document asks for *new* >>>>>>>>>>>>>> allocation >>>>>>>>>>>>> >>>>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>>>> >>>>>>>>>>>>> Is this better? >>>>>>>>>>>>> >>>>>>>>>>>>> "AccECN feedback overloads the two existing ECN flags as well= as >>>>>>>>>>>>> the >>>>>>>>>>>>> currently reserved and previously called NS flag in the ma= in >>>>>>>>>>>>> TCP >>>>>>>>>>>>> header >>>>>>>>>>>>> with new definitions, so both ends have to support the new >>>>>>>>>>>>> wire >>>>>>>>>>>>> protocol >>>>>>>>>>>>> before it can be used.=E2=80=9C >>>>>>>>>>>>> >>>>>>>>>>>>> I understand that you are not happy with the word =E2=80=9Eov= erload=E2=80=9C here >>>>>>>>>>>>> but >>>>>>>>>>>>> the >>>>>>>>>>>>> point of this sentence really is that the flags can/could be = used >>>>>>>>>>>>> differently >>>>>>>>>>>>> and therefore we need a new negotiation before we can use the= m. >>>>>>>>>>>> >>>>>>>>>>>> For me the following would work: "AccECN feedback overloads th= e two >>>>>>>>>>>> existing ECN flags and >>>>>>>>>>>> allocates the currently reserved and previously called NS flag= in >>>>>>>>>>>> the >>>>>>>>>>>> main TCP header. >>>>>>>>>>>> Given the new definitions, both ends have to support the new w= ire >>>>>>>>>>>> protocol >>>>>>>>>>>> before it can be used." >>>>>>>>>>>> >>>>>>>>>>>> I believe the wording has to be crystal clear on the reservati= on of >>>>>>>>>>>> bit 7 >>>>>>>>>>>> when it is discussed the first time in the text. In follow-up >>>>>>>>>>>> sections, >>>>>>>>>>>> maybe shorter terms could be used. >>>>>>>>>>> >>>>>>>>>>> Okay, now: >>>>>>>>>>> >>>>>>>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>>>>>>> allocates the currently reserved and previously called NS fla= g in >>>>>>>>>>> the >>>>>>>>>>> TCP header, to be used as one field indicating the number of >>>>>>>>>>> congestion >>>>>>>>>>> experienced marked packets. Given the new definitions of thes= e >>>>>>>>>>> three >>>>>>>>>>> bits, >>>>>>>>>>> both ends have to support the new wire protocol before it= can >>>>>>>>>>> be >>>>>>>>>>> used. >>>>>>>>>>> Therefore during the TCP handshake the two ends use these thr= ee >>>>>>>>>>> bit >>>>>>>>>>> in >>>>>>>>>>> the TCP header to negotiate the most advanced feedback protoc= ol >>>>>>>>>>> that they can both support in a backward compatible way to >>>>>>>>>>> ." >>>>>>>>>>>>> >>>>>>>>>>>>> If you prefer, we can also remove the NS flag in this list, a= s ECN >>>>>>>>>>>>> Nonce >>>>>>>>>>>>> was >>>>>>>>>>>>> anyway never deployed. >>>>>>>>>>>>> >>>>>>>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>>>>>>> specifies a different response to TCP ECN feedback, for exam= ple: >>>>>>>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Lo= w >>>>>>>>>>>>>> Latency >>>>>>>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>>>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-e= cn], >>>>>>>>>>>>>> or >>>>>>>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this par= agraph >>>>>>>>>>>>>> can >>>>>>>>>>>>>> just >>>>>>>>>>>>> >>>>>>>>>>>>> be deleted. If other experiments need more accurate feedback,= it is >>>>>>>>>>>>> up >>>>>>>>>>>>> to >>>>>>>>>>>>> them to explain how they would use this mechanism. This docum= ent >>>>>>>>>>>>> should >>>>>>>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it better= to be >>>>>>>>>>>>> explicit >>>>>>>>>>>>> about this? >>>>>>>>>>>>> >>>>>>>>>>>>>> It is likely (but not required) that the AccECN protocol wil= l be >>>>>>>>>>>>>> implemented along with the following experimental additions = to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>>>>>>> retransmissions >>>>>>>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capa= ble >>>>>>>>>>>>>> SYN/ >>>>>>>>>>>>>> ACK experiment [RFC5562]; and testing receiver non-complianc= e >>>>>>>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my v= iew, >>>>>>>>>>>>>> the >>>>>>>>>>>>>> TCPM >>>>>>>>>>>>> >>>>>>>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn and >>>>>>>>>>>>> draft-ietf- >>>>>>>>>>>>> tcpm-generalized-ecn independent documents, which probably im= plies >>>>>>>>>>>>> that >>>>>>>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If >>>>>>>>>>>>> experimentation >>>>>>>>>>>>> with ECT in SYN requires a combination, this could be done in= a >>>>>>>>>>>>> new, >>>>>>>>>>>>> third >>>>>>>>>>>>> document. Apart from having simpler focused documents, this c= ould >>>>>>>>>>>>> significantly help later with moving forward documents to sta= ndards >>>>>>>>>>>>> track. >>>>>>>>>>>>> >>>>>>>>>>>>> I disagree, however, this is a discussion to have on >>>>>>>>>>>>> draft-ietf-tcpm- >>>>>>>>>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing = a reference >>>>>>>>>>>>> here >>>>>>>>>>>>> that >>>>>>>>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing more= . >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] A macroscopic comment is that this document has a lot o= f >>>>>>>>>>>>>> introduction >>>>>>>>>>>>> >>>>>>>>>>>>> and tutorial text with lot's of redundancy towards other docu= ments. >>>>>>>>>>>>> I >>>>>>>>>>>>> think >>>>>>>>>>>>> the document can be made much easier to read by shorten it. I= n many >>>>>>>>>>>>> cases >>>>>>>>>>>>> this is just an editorial change as there is redundancy. As o= ne >>>>>>>>>>>>> such >>>>>>>>>>>>> example, >>>>>>>>>>>>> just remove this section. >>>>>>>>>>>>> >>>>>>>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big f= an of short >>>>>>>>>>>>> and >>>>>>>>>>>>> concise >>>>>>>>>>>>> documents, however, some redundancy can also help understandi= ng, >>>>>>>>>>>>> especially if you explain things multiple times but with a >>>>>>>>>>>>> different >>>>>>>>>>>>> level of >>>>>>>>>>>>> detail. I personally would not need the roadmap but I know ma= ny >>>>>>>>>>>>> people >>>>>>>>>>>>> who find these things helpful and to be honest I don=E2=80=99= t see how >>>>>>>>>>>>> removing >>>>>>>>>>>>> this >>>>>>>>>>>>> part makes the doc any better. If you don=E2=80=99t want it, = don=E2=80=99t read it. >>>>>>>>>>>>> >>>>>>>>>>>>>> * 1.2. Goals >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>>>>>> >>>>>>>>>>>>> I have to say I also don=E2=80=99t see the point of removing = this part. >>>>>>>>>>>>> Given >>>>>>>>>>>>> we=E2=80=99ve >>>>>>>>>>>>> done the work on requirements, I think we should also link to= this >>>>>>>>>>>>> doc >>>>>>>>>>>>> somewhere. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>>>>>> >>>>>>>>>>>>>> TCP is critical to the robust functioning of the Internet, >>>>>>>>>>>>>> therefore >>>>>>>>>>>>>> any proposed modifications to TCP need to be thoroughly test= ed. >>>>>>>>>>>>>> The >>>>>>>>>>>>>> present specification describes an experimental protocol tha= t >>>>>>>>>>>>>> adds >>>>>>>>>>>>>> more accurate ECN feedback to the TCP protocol. The intenti= on >>>>>>>>>>>>>> is to >>>>>>>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>>>>>>> implementation can be built in order to test its function, >>>>>>>>>>>>>> robustness >>>>>>>>>>>>>> and interoperability (with itself and with previous version = of >>>>>>>>>>>>>> ECN >>>>>>>>>>>>>> and TCP). >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] I think all what is written in this paragraph is obviou= s, no? >>>>>>>>>>>>>> Can't we just >>>>>>>>>>>>> >>>>>>>>>>>>> delete this? >>>>>>>>>>>>> >>>>>>>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it out= . For me both >>>>>>>>>>>>> is >>>>>>>>>>>>> fine, keep it >>>>>>>>>>>>> or remove it. >>>>>>>>>>>>> >>>>>>>>>>>>>> The experimental protocol will be considered successful if i= t is >>>>>>>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] i= n >>>>>>>>>>>>>> the >>>>>>>>>>>>>> consensus opinion of the IETF tcpm working group. In short, >>>>>>>>>>>>>> this >>>>>>>>>>>>>> requires that it improves the accuracy and timeliness of TCP= 's >>>>>>>>>>>>>> ECN >>>>>>>>>>>>>> feedback, as claimed in Section 5, while striking a balance >>>>>>>>>>>>>> between >>>>>>>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>>>>>>> minimisation of overhead. It also requires that it is not >>>>>>>>>>>>>> unduly >>>>>>>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>>>>>>> behaviours in the current Internet (e.g. hardware offloading= and >>>>>>>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>>>>> specified >>>>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectivenes= s of >>>>>>>>>>>>>> these strategies depends on the actual deployment situation = of >>>>>>>>>>>>>> middleboxes. Therefore experimental verification to confirm >>>>>>>>>>>>>> large- >>>>>>>>>>>>>> scale path traversal in the Internet is needed before finali= zing >>>>>>>>>>>>>> this >>>>>>>>>>>>>> specification on the Standards Track. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I h= ave >>>>>>>>>>>>> >>>>>>>>>>>>> mentioned before, I don't think an RFC should speculate about= TCPM >>>>>>>>>>>>> and >>>>>>>>>>>>> its >>>>>>>>>>>>> consensus opinion. I would suggest a wording along the lines = of: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>>>>>>> testing confirms that the proposed mechanism can be deployed= at >>>>>>>>>>>>>> large >>>>>>>>>>>>> >>>>>>>>>>>>> scale. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case of >>>>>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>>>>> specified >>>>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectivenes= s of >>>>>>>>>>>>>> these strategies depends on the actual deployment situation = of >>>>>>>>>>>>>> middleboxes. Therefore experimental verification to confirm >>>>>>>>>>>>>> large- >>>>>>>>>>>>>> scale path traversal in the Internet is needed, e.g., by sup= port >>>>>>>>>>>>>> in >>>>>>>>>>>>>> major TCP stacks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t t= hink that the >>>>>>>>>>>>> paraphrase >>>>>>>>>>>>> speculates about the consensus of tcpm, in contrast it say tc= pm has >>>>>>>>>>>>> to >>>>>>>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>>>>>>> sufficiently >>>>>>>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the re= quirement >>>>>>>>>>>>> draft as >>>>>>>>>>>>> this >>>>>>>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>>>>>> >>>>>>>>>>>> My suggested wording uses the expression "can be deployed at l= arge >>>>>>>>>>>> scale" >>>>>>>>>>>> and I believe this is relevant. >>>>>>>>>>>> >>>>>>>>>>>> The document already describes in Section 5 how the protocol >>>>>>>>>>>> satisfies >>>>>>>>>>>> the agreed requirements for a more accurate ECN feedback proto= col >>>>>>>>>>>> [RFC7560]. >>>>>>>>>>>> So, if the TCPM working group publishes this document with the >>>>>>>>>>>> content of >>>>>>>>>>>> Section 5, I believe the TCPM working group already has reache= d >>>>>>>>>>>> consensus >>>>>>>>>>>> that the protocol meets requirements. In addition, it is possi= ble >>>>>>>>>>>> that new >>>>>>>>>>>> requirements would be identified in future, e.g., as an outcom= e of >>>>>>>>>>>> the >>>>>>>>>>>> experiment, and that would obviously have to be considered by = TCPM. >>>>>>>>>>>> In that >>>>>>>>>>>> case, for the success of the experiment not only RFC 7560 woul= d >>>>>>>>>>>> matter, but >>>>>>>>>>>> also further requirements. My proposed wording does not have a= ll >>>>>>>>>>>> these >>>>>>>>>>>> problems. >>>>>>>>>>>> >>>>>>>>>>>> In a nutshell, I continue to believe that this section has to >>>>>>>>>>>> change. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Okay, used your proposed wording. You have a point about the >>>>>>>>>>> requirement >>>>>>>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be deplo= yed >>>>>>>>>>> large-scale=E2=80=9C. >>>>>>>>>>> >>>>>>>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The last bit in byte 13 of the TCP header was defined as the >>>>>>>>>>>>>> Nonce >>>>>>>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never >>>>>>>>>>>>>> deployed >>>>>>>>>>>>>> so >>>>>>>>>>>>>> it is being reclassified as historic, making this TCP flag >>>>>>>>>>>>>> available >>>>>>>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into a= ccount >>>>>>>>>>>>>> the >>>>>>>>>>>>>> IANA >>>>>>>>>>>>> >>>>>>>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is published= . >>>>>>>>>>>>> >>>>>>>>>>>>> Is does. However, I can explicitly say that is has be re-clss= ified >>>>>>>>>>>>> as >>>>>>>>>>>>> reserved. >>>>>>>>>>>>> >>>>>>>>>>>>> "RFC 3540 was never deployed so it is being reclassified as >>>>>>>>>>>>> historic >>>>>>>>>>>>> [I-D.ietf- >>>>>>>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been m= arked >>>>>>>>>>>>> as >>>>>>>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags regis= try, making this TCP >>>>>>>>>>>>> flag >>>>>>>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>>>>>> >>>>>>>>>>>>> Better? >>>>>>>>>>>>> >>>>>>>>>>>>>> In my understanding, this experimental document asks for new >>>>>>>>>>>>>> assignment >>>>>>>>>>>>> >>>>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>>>> >>>>>>>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded thi= s discussion >>>>>>>>>>>>> yet. >>>>>>>>>>>>> However, >>>>>>>>>>>>> what we really would want to is mention somewhere that this >>>>>>>>>>>>> experiment >>>>>>>>>>>>> with this flags is running. I guess there are three options: >>>>>>>>>>>>> 1) keep it in the registry as reserved and conserve the knowl= edge >>>>>>>>>>>>> in >>>>>>>>>>>>> tcpm >>>>>>>>>>>>> that this experiment is running and no other experimental RFC= such >>>>>>>>>>>>> use >>>>>>>>>>>>> this >>>>>>>>>>>>> flags as long as this experiment is running. >>>>>>>>>>>>> 2) Keep is marked as reserved but add a note about this exper= iment >>>>>>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>> IANA registry >>>>>>>>>>>>> 3) Or assign it right away with IESG approval. I guess in thi= s case >>>>>>>>>>>>> tcpm >>>>>>>>>>>>> could >>>>>>>>>>>>> also consider to change the registration policy to =E2=80=9EI= ETF Review=E2=80=9C. >>>>>>>>>>>> >>>>>>>>>>>> The current registration policy for the TCP header flags is >>>>>>>>>>>> "standards >>>>>>>>>>>> action". I understand that the IESG could approve exceptions. = But >>>>>>>>>>>> given the >>>>>>>>>>>> policy, I believe the document has to be very precise on the r= equest >>>>>>>>>>>> regarding bit 7. >>>>>>>>>>> >>>>>>>>>>> Okay, it now says: >>>>>>>>>>> >>>>>>>>>>> "[TO BE REMOVED: IANA is requested to update the existing entry= in >>>>>>>>>>> the >>>>>>>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>>>>>>> >>>>>>>>>>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-f= lags.xhtml#tcp-header-flags-1) >>>>>>>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic as= NS >>>>>>>>>>> (Nonce >>>>>>>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-t= o-be >>>>>>>>>>> instead >>>>>>>>>>> of RFC8311.]=E2=80=9C >>>>>>>>>>> >>>>>>>>>>> I guess we could also ask IANA to add an additional comment col= umn >>>>>>>>>>> instead >>>>>>>>>>> (but not sure if we then have to update RFC3168, which I think = we >>>>>>>>>>> really >>>>>>>>>>> don=E2=80=99t want. Should be fine now. >>>>>>>>>>> >>>>>>>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>>>>>> >>>>>>>>>>>>>> o an essential part that re-uses ECN TCP header bits to fee= d >>>>>>>>>>>>>> back >>>>>>>>>>>>>> the number of arriving CE marked packets. This provides = more >>>>>>>>>>>>>> accuracy than classic ECN feedback, but limited resilienc= e >>>>>>>>>>>>>> against >>>>>>>>>>>>>> ACK loss; >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>>>>>> >>>>>>>>>>>>> I think this is nit picking. Using a different phrasing here = makes >>>>>>>>>>>>> the >>>>>>>>>>>>> sentence >>>>>>>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how get= a round the >>>>>>>>>>>>> fact >>>>>>>>>>>>> that we need to handle the flag registration correctly. Howev= er, >>>>>>>>>>>>> here >>>>>>>>>>>>> the >>>>>>>>>>>>> point really is to explain how the protocol word. The main po= int of >>>>>>>>>>>>> using the >>>>>>>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say that= these flags are or >>>>>>>>>>>>> have >>>>>>>>>>>>> been >>>>>>>>>>>>> used different by other TCP extension (and we therefore need = a >>>>>>>>>>>>> proper >>>>>>>>>>>>> negotiation scheme). >>>>>>>>>>>> >>>>>>>>>>>> If the allocation of a reserved flag is correctly explained in= the >>>>>>>>>>>> abstract and introduction, I think these sentences can use a b= it >>>>>>>>>>>> relaxed >>>>>>>>>>>> terminology. >>>>>>>>>>>> >>>>>>>>>>>>>> The two part design was necessary, given limitations on the >>>>>>>>>>>>>> space >>>>>>>>>>>>>> available for TCP options and given the possibility that cer= tain >>>>>>>>>>>>>> incorrectly designed middleboxes prevent TCP using any new >>>>>>>>>>>>>> options >>>>> >>>>> >>>>> -- >>>>> ________________________________________________________________ >>>>> Bob Briscoe http://bobbriscoe.net/ >>>>> >>>> >>> >>> >> > > From nobody Fri Jul 13 13:55:01 2018 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 BCCB8130FFA for ; Fri, 13 Jul 2018 13:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 Y66_IyZfPU4g for ; Fri, 13 Jul 2018 13:54:43 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 E105E130FF4 for ; Fri, 13 Jul 2018 13:54:42 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h2-v6so11447771itj.1 for ; Fri, 13 Jul 2018 13:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IkJMpyWERSDyEKTZ03wk3xyU/ADFha6MstDpG1uFbTc=; b=UAFpfzurgyvaDoBlhmusN0sKnc/yIDGbVr7JPIJ/SADkvMSQvPrlSqD68LGwe6yPkm o6GhJvEXwppbCDShLAKXBknvyV2ummUd1ryC2TYNZnJDZLju5W03bsOmTym1TDxRw/Rj HoWsXCjYvBDf+P5/Hpm7xRThqQaJicdOhsIfm1mLPXRvCcWtDQ592EsVGzLNEOR+ueZm CQMPavK2kHnNfst2RM8uKWOAQEPX/Lbac+i1WQZCOQDcM9U4f3MUNv8axTqrat6xUV/I IwssmHXdX2Y4ZhwV89T6UrlD0H10297YEHzTt7KmHHeu0hrMTZqUf4yXLqZ6wq/HmIj8 0HsA== 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:content-transfer-encoding; bh=IkJMpyWERSDyEKTZ03wk3xyU/ADFha6MstDpG1uFbTc=; b=ee4iG4gVjlse9naqjYvj8Rj26IPlDtB3kzRQagYyFWlfW71JF7/ZUvZ4ODRitr1JKN JhaYdoev8O/4Q2zOHOY1+PLnGIeDKTo9h3PF+X4HjXbsfDxInfUzNdhm/8X6xwC5PH/O csmnzNWg9eYspTa56v8gTpaO8pDMLaLP0S0G9Y5sno0x5ar6bwcktYhtIULSROs2RAX7 rCc/DwRwBEMvCyau9dQp4kM5evj/2ciMrCWI6Maanticd807+nfijfZ1VhMXcBdJF2Ub NSdPyDEjzgi5cR9EXeD05jlfb2FzEM0UHGuvhsubz7RqN/EMvgWU5AH8B4wzyNEG5IPP nsIg== X-Gm-Message-State: AOUpUlF+Ga3XnJzcizpwAW2Q9x+bPMWbd7xjGzg07qM+215lP7qKTjY+ LCCf+V2Jfgeboeq+bHW33WDMB09Yqb+gHKxkAUxsqA== X-Google-Smtp-Source: AAOMgpdss6mvuTvP13LZ9CdNIgCCtERpCYxrJ+6md3/mbr96xGMn1iRCHiDMa9Io/rRhg7YMI1xHc8hJXu7uANyb2FY= X-Received: by 2002:a24:c7c7:: with SMTP id t190-v6mr6119661itg.116.1531515281639; Fri, 13 Jul 2018 13:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5e:c10d:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 13:54:00 -0700 (PDT) In-Reply-To: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> From: Yuchung Cheng Date: Fri, 13 Jul 2018 13:54:00 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 20:55:00 -0000 On Fri, Jul 13, 2018 at 1:45 PM, Yuchung Cheng wrote: > On Fri, Jul 13, 2018 at 12:42 PM, Mirja K=C3=BChlewind > wrote: >> Hi Yuchung, >> >>> Am 13.07.2018 um 15:30 schrieb Yuchung Cheng : >>> >>> On Fri, Jul 13, 2018 at 11:53 AM, Mirja K=C3=BChlewind >>> wrote: >>>> Hi Yucheng, >>>> >>>> please see below. >>>> >>>>> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng : >>>>> >>>>> hi -- >>>>> >>>>> I agree: >>>>> 1. delayed/streched ACK aren't going away (in fact will be more commo= n) >>>>> 2. GRO isn't and should not be a show-stopper >>>>> 3. SYN option is running tight >>>>> 4. HW opt comes after SW >>>>> >>>>> I worry: >>>>> 1. GRO is a unavoidable issue in deployment (let's not produce an >>>>> undeployable RFC). the ACE counter won't work as GRO can pack up to >>>>> 64KB/MTU =3D~ 45 pkts under heavy congestion. >>>>> >>>>> 2. ACE's benefit over DCTCP is when delayed ACKs and ack losses >>>>> happen. Now delayed ACKs happen frequently when the messages are >>>>> small, which means they don't solicit too many ACKs to be dropped in >>>>> the reverse path. Also that under heavy downstream loss or reordering= , >>>>> >>>>> 3 SACK options become dominant to have ACE option. >>>>> >>>>> 4. If SYN option space is a concern, ACE header exchange is ok. But I >>>>> suspect the latter has more middlebox issue based on my TFO deploymen= t >>>>> experience. >>>>> >>>>> >>>>> So with all that said, is it possible to have a "minimal"-ACE that >>>>> 1. Does ACE handshake as proposed >>>>> 2. Mark ECT on all (or at least SYN & data & rtx) packets like ECN++ >>>> >>>> This is ECN++ and independent of AccECN. We on purposed have split the= feedback and usage of ECN (which is not the case in RFC3168) to be able to= change things in future independently >>> sure - IMO marking all packets just improve the accuracy significantly >>> vs the counters and options. For example, ECN on SYN is very useful on >>> incast / loaded link. >> >> Yes, but to be able to mark control packets as ECN-enables you also need= a way to feedback congestion experienced information if they appear on the= se packets. Therefore you can use ECN++ only safely with e.g. AccECN feedba= ck (but not with classic RFC3168 ECN feedback). Still these two things shou= ld be specified in separate documents to be able to change them separately = in future. >>> >>>> >>>>> 3. Leave ACE-count and ACE option optional (i.e. MAY) >>>> >>>> I don=E2=80=99t understand this. If both is optional, you don=E2=80=99= t have any feedback. Or what do you mean by =E2=80=9Eleave ACE-count option= al=E2=80=9C? >>> use-case: We can negotiate DCTCP-style ECN for the internet. >>> >>> Then interested parties can progressively experiment on more accurate >>> "options" (!=3D TCP-option) >> >> As Appendix A of RFC7560 says I don=E2=80=99t think it is a safe option = for the Internet where packet loss more likely then in a full ECN-enabled d= ata center. > > Again I disagree RFC7560 Appendix A is a big problem based on my > experience with at times loss-heavy ECN-enabled data-center (Google > data-center runs very hot and uses a DCTCP-variant). > > We can quabble forever w/o data. That's why I asked for some > (non-simulation) data. I recall you mentioned you have a ACE Linux patch. Could you share w/ me? > >> >> Mirja >> >> >> >>> >>>> >>>> Mirja >>>> >>>> >>>> >>>>> >>>>> as a "fairly safe" to deployment compromise. And I am happy to draft = a >>>>> kernel patch for that :-) >>>>> >>>>> >>>>> >>>>> On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe wr= ote: >>>>>> Yuchung, >>>>>> >>>>>> On 12/07/18 17:03, Mirja K=C3=BChlewind wrote: >>>>>>> >>>>>>> Hi Yuchung, >>>>>>> >>>>>>> please see below. >>>>>>> >>>>>>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>>>>>>> >>>>>>>> Yes packets with ACE options and (different) ACE-counter header wo= uld >>>>>>>> break GRO. There're many legacy h/w and s/w. >>>>>>> >>>>>>> I=E2=80=99m not the expert here but my understanding is that is wou= ld not break >>>>>>> GRO but could not make actual use or it if the ACE counter changed = or the >>>>>>> option is present. >>>>>> >>>>>> [BB] Yuchung's criticism applies to any scheme that feeds back a con= tinually >>>>>> changing signal like ECN. For instance, like AccECN feedback, DCTCP = ECN >>>>>> feedback continually changes the TCP header flags, and I believe DCT= CP is >>>>>> widely used in DCs. >>>>>> >>>>>> I believe, to make GRO support ECN feedback (whether DCTCP or AccECN= ), it >>>>>> would be necessary for GRO to know which bits to mask when determini= ng >>>>>> whether a packet is mergeable with others. I believe GRO already col= lects >>>>>> header fields separately for the TCP logic to be able to work on the= m, but >>>>>> I'm also not an expert. >>>>>>> >>>>>>> However, usually your will only have a small number of CE marks eve= ry >>>>>>> couple of RTTs, and the counter only changes if you CE marks/the op= tion is >>>>>>> only present a few times per RTT. So the impact should be rather lo= w. But >>>>>>> this clear something to evaluate for the experiment. >>>>>> >>>>>> [BB] With DCTCP as currently designed, you tend to get runs of 100% = CE if >>>>>> the load of short flows is very small. In that case, DCTCP feedback = will >>>>>> change the header flags less often than AccECN. However, with more s= hort >>>>>> flows, the feedback is more on-off. Then the flags change more often= with >>>>>> DCTCP than with AccECN feedback. >>>>>> >>>>>> In general, hardware optimization is not going to optimize a protoco= l that >>>>>> didn't exist when the hardware was designed. It would be ideal to de= sign a >>>>>> new protocol that takes advantage of existing hardware optimization. >>>>>> However, as long as an experimental protocol still works with existi= ng >>>>>> hardware, I think it's reasonable to assume that hardware optimizati= on will >>>>>> only arrive once a protocol has become well-established. >>>>>> >>>>>>> >>>>>>>> Even without option, ACE header only allows reflecting up to 8 pac= kets >>>>>>>> for receiver segmentation offload and ACK suppression? >>>>>>> >>>>>>> Same as above, it can only up to 8 CE marked packets per ACK, howev= er, CE >>>>>>> marking rater are expected to be rather low. ACK suppression should= probably >>>>>>> not be used if the ACE counter has changes, however, usually the AC= E counter >>>>>>> stays stable for multiple RTTs and then ACK suppression is not a pr= oblem. >>>>>>> However, not sure I understood you question here correctly=E2=80=A6= ? >>>>>>> >>>>>>>> The appendix on ack loss causes ambiguity is good: but the pattern >>>>>>>> drops specifically the state-switch (CE<->noCE) ACK which only hap= pens >>>>>>>> on delayed ACK. Is that pattern common? - or can we address most o= f >>>>>>>> that by delaying less ACKs? >>>>>>> >>>>>>> I guess you have a 50% chance today to hit a delayed ACK. I guess d= elaying >>>>>>> less (where you delay every second ACK today) would mean ACK every = packet, >>>>>>> and thus double ACK load on the network. I guess on today networks = that >>>>>>> actually in most cases not a problem, however, there might be speci= ally >>>>>>> cases where it is. However, that=E2=80=99s problem an independent q= uestion to >>>>>>> evaluate. >>>>>> >>>>>> [BB] If there were no delayed ACKs, the problem with DCTCP feedback = would >>>>>> largely disappear. But delayed ACKs are not going away. Which is why= we >>>>>> proposed replacing DCTCP feedback with AccECN feedback. >>>>>>> >>>>>>> >>>>>>>> I am all for making ECN more accurate for wide area beyond DCTCP, = but >>>>>>>> am evaluating the pros/cons. What if we just >>>>>>>> 1. negotiate 'better' ECN via new SYN option >>>>>>> >>>>>>> Not sure I understand your proposal correctly, but I assume you mea= n >>>>>>> negotiate via SYN option and then just use the ACE counter in the h= eader? If >>>>>>> so, I don=E2=80=99t understand why you see the negotiation part in = the TCP header as >>>>>>> the problem? >>>>>> >>>>>> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a = solution >>>>>> without a problem. In fact an option on the SYN would create a new p= roblem >>>>>> 'cos of the severe shortage of space for SYN options (for this reaso= n, the >>>>>> AccECN TCP option was designed not to be needed on the SYN). >>>>>>> >>>>>>> >>>>>>>> 2. mark all packets like ECN++ >>>>>>> >>>>>>> That would be nice but here you actually need AccECN because you wa= nt to >>>>>>> have feedback for control packets as well. AccECN is providing this >>>>>>> feedback. AccECN does not change the =E2=80=9Euse of ECN=E2=80=9C; = that=E2=80=99s what we have ECN++ >>>>>>> for; both thing ideally would be deployed together however. Was tha= t your >>>>>>> questions? >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>>> Mirja >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja K=C3=BChlewind >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Yuchung, >>>>>>>>> >>>>>>>>> the question if you need this =E2=80=9Emore=E2=80=9C on accuracy = really depends on the >>>>>>>>> use case. If you use DCTCP as today, the ACE counter in the TCP i= s probably >>>>>>>>> sufficient and you might not want to pay the additional overhead = in your >>>>>>>>> data center (that why the option is actually optional). >>>>>>>>> >>>>>>>>> If you however, e.g., have very differently sized packets, then t= he byte >>>>>>>>> counter in the option could give you a more accurate signal. Or i= f you are >>>>>>>>> also interested in the ECT(1) counter, you need the option. Furth= er the ACE >>>>>>>>> counter also give your feedback on control packet and the option = enables you >>>>>>>>> to distinguish between CE-amrked payload and control packets, whi= ch can also >>>>>>>>> become important when experimenting with making all packets ECN-c= apable. >>>>>>>>> >>>>>>>>> Given accECN is a general feedback mechanism that in fact is desi= gned to >>>>>>>>> enable new future uses of the ECN signal, we wanted to keep all t= hese option >>>>>>>>> available while making is still as simple as possible and as flex= ible as >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> Mirja >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng = : >>>>>>>>>> >>>>>>>>>> Hi Bob, >>>>>>>>>> >>>>>>>>>> Neal and I evaluated the earlier draft. It is well-thought out b= ut >>>>>>>>>> we're concerned about the options. Option is not mandatory but t= he >>>>>>>>>> lack of it also reduces accuracy. Option runs into space issues = w/ >>>>>>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for su= re but >>>>>>>>>> aren't easy. >>>>>>>>>> >>>>>>>>>> We're curious how much more "accuracy" it buys over current >>>>>>>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>>>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Michael, tcpm list, >>>>>>>>>>> >>>>>>>>>>> As well as addressing your points, as Mirja has already mention= ed >>>>>>>>>>> below, we >>>>>>>>>>> added a whole new appendix giving the rationale for the bits an= d >>>>>>>>>>> codepoints >>>>>>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A= 3rd >>>>>>>>>>> subsection also identifies space for future evolution. It also = points >>>>>>>>>>> to >>>>>>>>>>> where rationale was already given in the body of the draft. >>>>>>>>>>> >>>>>>>>>>> The appendix is in the draft submitted last week, available her= e: >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#app= endix-B >>>>>>>>>>> >>>>>>>>>>> We'd be interested to hear whether this allays your concerns. >>>>>>>>>>> >>>>>>>>>>> We have asked to present this in Montreal as well. >>>>>>>>>>> >>>>>>>>>>> Cheers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bob >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 02/07/18 16:54, Mirja K=C3=BChlewind wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>> >>>>>>>>>>>> I addressed a couple of your comments below. >>>>>>>>>>>> >>>>>>>>>>>> For the other, bigger comments regarding extensibility, that I= did >>>>>>>>>>>> not yet >>>>>>>>>>>> address below, we plan to add a new section to the appendix to >>>>>>>>>>>> explain >>>>>>>>>>>> extensibility options as previously discussed by mail. We will >>>>>>>>>>>> probably send >>>>>>>>>>>> a separate email on that part. >>>>>>>>>>>> >>>>>>>>>>>> Mirja >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Mirja, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some o= f the >>>>>>>>>>>>> editorial suggestions. >>>>>>>>>>>>> >>>>>>>>>>>>> Yet, I continue to believe that some formal wording in the do= cument >>>>>>>>>>>>> needs >>>>>>>>>>>>> to change, as explained below. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.e= thz.ch] >>>>>>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please see inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>>>> >>>>>>>>>>>>>> : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>>>>>>> appendix). I >>>>>>>>>>>>>> >>>>>>>>>>>>>> believe this document needs further work before moving forwa= rd. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please find below my comments marked as [ms]. I have read t= he >>>>>>>>>>>>>> >>>>>>>>>>>>>> document independent of the review from Gorry. I apologize i= f there >>>>>>>>>>>>>> is >>>>>>>>>>>>>> duplication. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ****************************** >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Abstract: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConE= x) or >>>>>>>>>>>>>>> Data >>>>>>>>>>>>>> >>>>>>>>>>>>>> Center TCP >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (DCTCP) need more accurate ECN feedback information wheneve= r >>>>>>>>>>>>>>> more >>>>>>>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC 82= 57. I >>>>>>>>>>>>>>> suggest to >>>>>>>>>>>>>> >>>>>>>>>>>>>> remove this, or replace it by a more generic statement that = more >>>>>>>>>>>>>> accurate >>>>>>>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate informat= ion. >>>>>>>>>>>>>> They do >>>>>>>>>>>>>> not need the mechanism that is specified in this draft, howe= ver, >>>>>>>>>>>>>> this is >>>>>>>>>>>>>> not >>>>>>>>>>>>>> what the sentences is saying. >>>>>>>>>>>>> >>>>>>>>>>>>> In my understanding (as a non-native speaker), the use of the= word >>>>>>>>>>>>> "need" >>>>>>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>>>>>>> implemented >>>>>>>>>>>>> without any such mechanism. >>>>>>>>>>>>> >>>>>>>>>>>>> What would work for me is something of the form "... Data Cen= ter TCP >>>>>>>>>>>>> cannot get precise ECN feedback whenever more than one markin= g is >>>>>>>>>>>>> received >>>>>>>>>>>>> in one RTT=E2=80=9C. >>>>>>>>>>>> >>>>>>>>>>>> This is not correct. DCTP need more than one feedback signal p= er RTT >>>>>>>>>>>> and >>>>>>>>>>>> therefore cannot use RFC3168; instead it implement it=E2=80=99= s own feedback >>>>>>>>>>>> mechanism. However, to avoid confusion such that people could = assume >>>>>>>>>>>> DCTP >>>>>>>>>>>> would not work without the accECN scheme as specified in this = doc, I >>>>>>>>>>>> rephrased to: >>>>>>>>>>>> >>>>>>>>>>>> "Recently, proposed >>>>>>>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>>>>>>> target=3D"RFC7713"/>), >>>>>>>>>>>> DCTCP or L4S >>>>>>>>>>> target=3D"I-D.ietf-tsvwg-l4s-arch"/> need to know when mor= e than >>>>>>>>>>>> one >>>>>>>>>>>> marking is received in one RTT which is >>>>>>>>>>>> information that cannot be provided by the feedback scheme= as >>>>>>>>>>>> specified in >>>>>>>>>>>> ." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> This document specifies an >>>>>>>>>>>>>>> experimental scheme to provide more than one feedback signa= l per >>>>>>>>>>>>>>> RTT >>>>>>>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>>>>>>> overloads >>>>>>>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>>>>>>> provides >>>>>>>>>>>>>>> additional information in a new TCP option. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This statement needs to be rewritten to correctly refl= ect >>>>>>>>>>>>>>> what is >>>>>>>>>>>>>> >>>>>>>>>>>>>> requested from IANA. My understanding is that this experimen= tal >>>>>>>>>>>>>> document >>>>>>>>>>>>>> asks for allocation of a reserved TCP header flag. This need= s to be >>>>>>>>>>>>>> called out >>>>>>>>>>>>>> prominently, IMHO. In addition, since this is not a standard= , the >>>>>>>>>>>>>> suggested >>>>>>>>>>>>>> experimentation with the main TCP header must IMHO be explic= itly >>>>>>>>>>>>>> mentioned. I also suggest to have later in a document a sect= ion >>>>>>>>>>>>>> that >>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>> explains why it is appropriate to modify the main TCP header= in an >>>>>>>>>>>>>> experiment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don=E2=80=99t know if any requirement that IANA assignment= need to be >>>>>>>>>>>>>> called >>>>>>>>>>>>>> out >>>>>>>>>>>>>> in the abstract but we can do that. However, I believe the q= uestion >>>>>>>>>>>>>> if >>>>>>>>>>>>>> this >>>>>>>>>>>>>> document should or should not assign the bit is still not >>>>>>>>>>>>>> completely >>>>>>>>>>>>>> solved, or >>>>>>>>>>>>>> is it? >>>>>>>>>>>>> >>>>>>>>>>>>> I believe this question will have to be reviewed during WGLC = and, >>>>>>>>>>>>> more >>>>>>>>>>>>> importantly, IETF last call. For the moment, my concern is th= at the >>>>>>>>>>>>> document >>>>>>>>>>>>> correctly describes the IANA allocation. >>>>>>>>>>>>> >>>>>>>>>>>>> I would like to see here a statement such as : "Given TCP hea= der >>>>>>>>>>>>> space is >>>>>>>>>>>>> scarce, this specification allocates a reserved header bit an= d >>>>>>>>>>>>> overloads the >>>>>>>>>>>>> two ECN flags in the TCP header ...=E2=80=9C. >>>>>>>>>>>> >>>>>>>>>>>> A bit lengthy but now: >>>>>>>>>>>> >>>>>>>>>>>> "Given TCP header space is >>>>>>>>>>>> scarce, it allocates a reserved header bit, that was previ= ously >>>>>>>>>>>> used for >>>>>>>>>>>> ECN-Nonce which was recently declared historic, and overlo= ads >>>>>>>>>>>> the >>>>>>>>>>>> two existing ECN flags in the TCP header. Further, additio= nal >>>>>>>>>>>> information can be provided in a new TCP option that howev= er is >>>>>>>>>>>> not >>>>>>>>>>>> used >>>>>>>>>>>> on the TCP SYN." >>>>>>>>>>>> >>>>>>>>>>>>>>> * 1. Introduction >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (Con= Ex >>>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch= ] >>>>>>>>>>>>>>> need >>>>>>>>>>>>>>> more accurate ECN feedback information whenever more than o= ne >>>>>>>>>>>>>> >>>>>>>>>>>>>> marking >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> is received in one RTT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoi= t this. >>>>>>>>>>>>>>> Instead >>>>>>>>>>>>>> >>>>>>>>>>>>>> of stating a "need", it would IMHO make more sense to discus= s the >>>>>>>>>>>>>> benefits >>>>>>>>>>>>>> of the suggested mechanism in this document of its own, inde= pendent >>>>>>>>>>>>>> of >>>>>>>>>>>>>> other proposals. To me, this document should be independent = of >>>>>>>>>>>>>> other >>>>>>>>>>>>>> documents and specifically other experiments. We have to thi= nk >>>>>>>>>>>>>> about >>>>>>>>>>>>>> cases >>>>>>>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>>>>>>> documents >>>>>>>>>>>>>> will >>>>>>>>>>>>>> be more future-proof in future. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a naming collision=E2=80=A6 The sentence was meant t= o say that >>>>>>>>>>>>>> these >>>>>>>>>>>>>> mechanisms new more accurate ECN feedback than provided toda= y by >>>>>>>>>>>>>> RFC3168 but it was not meant to say that these mechanism hav= e to >>>>>>>>>>>>>> use the >>>>>>>>>>>>>> scheme as specified in this document. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added the following part sentence: >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=9ERecently, proposed mechanisms like Congestion Expos= ure (ConEx >>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch]= need >>>>>>>>>>>>>> more >>>>>>>>>>>>>> accurate ECN feedback information than provided by the feedb= ack >>>>>>>>>>>>>> scheme >>>>>>>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>>>>>>> received in >>>>>>>>>>>>>> one >>>>>>>>>>>>>> RTT. This document specifies an alternative feedback scheme = that >>>>>>>>>>>>>> provides >>>>>>>>>>>>>> more accurate information and could be used by these new TCP >>>>>>>>>>>>>> extensions.=E2=80=9C >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does this help? >>>>>>>>>>>>> >>>>>>>>>>>>> See my proposal for the abstract. I continue to disagree with= the >>>>>>>>>>>>> term >>>>>>>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>>>>>>> >>>>>>>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>>>>>>> track, it is intended to be a complete replacement for clas= sic >>>>>>>>>>>>>>> TCP/ >>>>>>>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This sentence should be removed, as this is speculatio= n. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why? It states an intent=E2=80=A6 and that=E2=80=99s the int= ent that we have. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Until the AccECN experiment succeeds, [RFC3168] will remain= as >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> standards track specification for adding ECN to TCP. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This sentence should be removed (or reworded) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why? Does it help to add an only here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "Until the AccECN experiment succeeds, [RFC3168] will remain= as the >>>>>>>>>>>>>> only >>>>>>>>>>>>>> standards track specification for adding ECN to TCP.=E2=80= =9C >>>>>>>>>>>>> >>>>>>>>>>>>> This wording is better. >>>>>>>>>>>>> >>>>>>>>>>>>>>> AccECN feedback overloads flags and fields in the main TCP >>>>>>>>>>>>>>> header >>>>>>>>>>>>>>> with new definitions, so both ends have to support the new = wire >>>>>>>>>>>>>>> protocol before it can be used. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] In my reading this experimental document asks for *new= * >>>>>>>>>>>>>>> allocation >>>>>>>>>>>>>> >>>>>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this better? >>>>>>>>>>>>>> >>>>>>>>>>>>>> "AccECN feedback overloads the two existing ECN flags as wel= l as >>>>>>>>>>>>>> the >>>>>>>>>>>>>> currently reserved and previously called NS flag in the m= ain >>>>>>>>>>>>>> TCP >>>>>>>>>>>>>> header >>>>>>>>>>>>>> with new definitions, so both ends have to support the ne= w >>>>>>>>>>>>>> wire >>>>>>>>>>>>>> protocol >>>>>>>>>>>>>> before it can be used.=E2=80=9C >>>>>>>>>>>>>> >>>>>>>>>>>>>> I understand that you are not happy with the word =E2=80=9Eo= verload=E2=80=9C here >>>>>>>>>>>>>> but >>>>>>>>>>>>>> the >>>>>>>>>>>>>> point of this sentence really is that the flags can/could be= used >>>>>>>>>>>>>> differently >>>>>>>>>>>>>> and therefore we need a new negotiation before we can use th= em. >>>>>>>>>>>>> >>>>>>>>>>>>> For me the following would work: "AccECN feedback overloads t= he two >>>>>>>>>>>>> existing ECN flags and >>>>>>>>>>>>> allocates the currently reserved and previously called NS fla= g in >>>>>>>>>>>>> the >>>>>>>>>>>>> main TCP header. >>>>>>>>>>>>> Given the new definitions, both ends have to support the new = wire >>>>>>>>>>>>> protocol >>>>>>>>>>>>> before it can be used." >>>>>>>>>>>>> >>>>>>>>>>>>> I believe the wording has to be crystal clear on the reservat= ion of >>>>>>>>>>>>> bit 7 >>>>>>>>>>>>> when it is discussed the first time in the text. In follow-up >>>>>>>>>>>>> sections, >>>>>>>>>>>>> maybe shorter terms could be used. >>>>>>>>>>>> >>>>>>>>>>>> Okay, now: >>>>>>>>>>>> >>>>>>>>>>>> "AccECN feedback overloads the two existing ECN flags and >>>>>>>>>>>> allocates the currently reserved and previously called NS fl= ag in >>>>>>>>>>>> the >>>>>>>>>>>> TCP header, to be used as one field indicating the number of >>>>>>>>>>>> congestion >>>>>>>>>>>> experienced marked packets. Given the new definitions of the= se >>>>>>>>>>>> three >>>>>>>>>>>> bits, >>>>>>>>>>>> both ends have to support the new wire protocol before i= t can >>>>>>>>>>>> be >>>>>>>>>>>> used. >>>>>>>>>>>> Therefore during the TCP handshake the two ends use these th= ree >>>>>>>>>>>> bit >>>>>>>>>>>> in >>>>>>>>>>>> the TCP header to negotiate the most advanced feedback proto= col >>>>>>>>>>>> that they can both support in a backward compatible way to >>>>>>>>>>>> ." >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you prefer, we can also remove the NS flag in this list, = as ECN >>>>>>>>>>>>>> Nonce >>>>>>>>>>>>>> was >>>>>>>>>>>>>> anyway never deployed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> For that we refer to [RFC3168] or any RFC that >>>>>>>>>>>>>>> specifies a different response to TCP ECN feedback, for exa= mple: >>>>>>>>>>>>>>> [RFC8257]; or the ECN experiments referred to in >>>>>>>>>>>>>>> [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based L= ow >>>>>>>>>>>>>>> Latency >>>>>>>>>>>>>>> Low Loss Scalable (L4S) congestion control >>>>>>>>>>>>>>> [I-D.ietf-tsvwg-l4s-arch]; >>>>>>>>>>>>>>> ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-= ecn], >>>>>>>>>>>>>>> or >>>>>>>>>>>>>>> Alternative Backoff with ECN (ABE) >>>>>>>>>>>>>>> [I-D.ietf-tcpm-alternativebackoff-ecn]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] At least ABE seems orthogonal. Anyway, I think this pa= ragraph >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> just >>>>>>>>>>>>>> >>>>>>>>>>>>>> be deleted. If other experiments need more accurate feedback= , it is >>>>>>>>>>>>>> up >>>>>>>>>>>>>> to >>>>>>>>>>>>>> them to explain how they would use this mechanism. This docu= ment >>>>>>>>>>>>>> should >>>>>>>>>>>>>> focus on how to signal the feedback, not how to use that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, that is what the paragraph says. Isn=E2=80=99t it bette= r to be >>>>>>>>>>>>>> explicit >>>>>>>>>>>>>> about this? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is likely (but not required) that the AccECN protocol wi= ll be >>>>>>>>>>>>>>> implemented along with the following experimental additions= to >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> TCP-ECN protocol: ECN-capable TCP control packets and >>>>>>>>>>>>>>> retransmissions >>>>>>>>>>>>>>> [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-cap= able >>>>>>>>>>>>>>> SYN/ >>>>>>>>>>>>>>> ACK experiment [RFC5562]; and testing receiver non-complian= ce >>>>>>>>>>>>>>> [I-D.moncaster-tcpm-rcv-cheat]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] I am a big fan of simple, standalone documents. In my = view, >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> TCPM >>>>>>>>>>>>>> >>>>>>>>>>>>>> working group should publish draft-ietf-tcpm-accurate-ecn an= d >>>>>>>>>>>>>> draft-ietf- >>>>>>>>>>>>>> tcpm-generalized-ecn independent documents, which probably i= mplies >>>>>>>>>>>>>> that >>>>>>>>>>>>>> draft-ietf-tcpm-generalized-ecn does not use AccECN. If >>>>>>>>>>>>>> experimentation >>>>>>>>>>>>>> with ECT in SYN requires a combination, this could be done i= n a >>>>>>>>>>>>>> new, >>>>>>>>>>>>>> third >>>>>>>>>>>>>> document. Apart from having simpler focused documents, this = could >>>>>>>>>>>>>> significantly help later with moving forward documents to st= andards >>>>>>>>>>>>>> track. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I disagree, however, this is a discussion to have on >>>>>>>>>>>>>> draft-ietf-tcpm- >>>>>>>>>>>>>> generalized-ecn. I don=E2=80=99t see a problem in providing= a reference >>>>>>>>>>>>>> here >>>>>>>>>>>>>> that >>>>>>>>>>>>>> says =E2=80=9Eit is likely=E2=80=A6=E2=80=9C and nothing mor= e. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * 1.1. Document Roadmap >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] A macroscopic comment is that this document has a lot = of >>>>>>>>>>>>>>> introduction >>>>>>>>>>>>>> >>>>>>>>>>>>>> and tutorial text with lot's of redundancy towards other doc= uments. >>>>>>>>>>>>>> I >>>>>>>>>>>>>> think >>>>>>>>>>>>>> the document can be made much easier to read by shorten it. = In many >>>>>>>>>>>>>> cases >>>>>>>>>>>>>> this is just an editorial change as there is redundancy. As = one >>>>>>>>>>>>>> such >>>>>>>>>>>>>> example, >>>>>>>>>>>>>> just remove this section. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I guess this a matter of taste. As an AD, I=E2=80=99m a big = fan of short >>>>>>>>>>>>>> and >>>>>>>>>>>>>> concise >>>>>>>>>>>>>> documents, however, some redundancy can also help understand= ing, >>>>>>>>>>>>>> especially if you explain things multiple times but with a >>>>>>>>>>>>>> different >>>>>>>>>>>>>> level of >>>>>>>>>>>>>> detail. I personally would not need the roadmap but I know m= any >>>>>>>>>>>>>> people >>>>>>>>>>>>>> who find these things helpful and to be honest I don=E2=80= =99t see how >>>>>>>>>>>>>> removing >>>>>>>>>>>>>> this >>>>>>>>>>>>>> part makes the doc any better. If you don=E2=80=99t want it,= don=E2=80=99t read it. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * 1.2. Goals >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] I think this section can also just be removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have to say I also don=E2=80=99t see the point of removing= this part. >>>>>>>>>>>>>> Given >>>>>>>>>>>>>> we=E2=80=99ve >>>>>>>>>>>>>> done the work on requirements, I think we should also link t= o this >>>>>>>>>>>>>> doc >>>>>>>>>>>>>> somewhere. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * 1.3. Experiment Goals >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TCP is critical to the robust functioning of the Internet, >>>>>>>>>>>>>>> therefore >>>>>>>>>>>>>>> any proposed modifications to TCP need to be thoroughly tes= ted. >>>>>>>>>>>>>>> The >>>>>>>>>>>>>>> present specification describes an experimental protocol th= at >>>>>>>>>>>>>>> adds >>>>>>>>>>>>>>> more accurate ECN feedback to the TCP protocol. The intent= ion >>>>>>>>>>>>>>> is to >>>>>>>>>>>>>>> specify the protocol sufficiently so that more than one >>>>>>>>>>>>>>> implementation can be built in order to test its function, >>>>>>>>>>>>>>> robustness >>>>>>>>>>>>>>> and interoperability (with itself and with previous version= of >>>>>>>>>>>>>>> ECN >>>>>>>>>>>>>>> and TCP). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] I think all what is written in this paragraph is obvio= us, no? >>>>>>>>>>>>>>> Can't we just >>>>>>>>>>>>>> >>>>>>>>>>>>>> delete this? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sure, however, I don=E2=80=99t think it hurts to spell it ou= t. For me both >>>>>>>>>>>>>> is >>>>>>>>>>>>>> fine, keep it >>>>>>>>>>>>>> or remove it. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The experimental protocol will be considered successful if = it is >>>>>>>>>>>>>>> deployed and if it satisfies the requirements of [RFC7560] = in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> consensus opinion of the IETF tcpm working group. In short= , >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> requires that it improves the accuracy and timeliness of TC= P's >>>>>>>>>>>>>>> ECN >>>>>>>>>>>>>>> feedback, as claimed in Section 5, while striking a balance >>>>>>>>>>>>>>> between >>>>>>>>>>>>>>> the conflicting requirements of resilience, integrity and >>>>>>>>>>>>>>> minimisation of overhead. It also requires that it is not >>>>>>>>>>>>>>> unduly >>>>>>>>>>>>>>> complex, and that it is compatible with prevalent equipment >>>>>>>>>>>>>>> behaviours in the current Internet (e.g. hardware offloadin= g and >>>>>>>>>>>>>>> middleboxes), whether or not they comply with standards. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case o= f >>>>>>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>>>>>> specified >>>>>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectivene= ss of >>>>>>>>>>>>>>> these strategies depends on the actual deployment situation= of >>>>>>>>>>>>>>> middleboxes. Therefore experimental verification to confir= m >>>>>>>>>>>>>>> large- >>>>>>>>>>>>>>> scale path traversal in the Internet is needed before final= izing >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> specification on the Standards Track. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] These two paragraphs must be entirely rewritten. As I = have >>>>>>>>>>>>>> >>>>>>>>>>>>>> mentioned before, I don't think an RFC should speculate abou= t TCPM >>>>>>>>>>>>>> and >>>>>>>>>>>>>> its >>>>>>>>>>>>>> consensus opinion. I would suggest a wording along the lines= of: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The experimental protocol will be considered successful if >>>>>>>>>>>>>>> testing confirms that the proposed mechanism can be deploye= d at >>>>>>>>>>>>>>> large >>>>>>>>>>>>>> >>>>>>>>>>>>>> scale. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing will mostly focus on fall-back strategies in case o= f >>>>>>>>>>>>>>> middlebox interference. Current recommended strategies are >>>>>>>>>>>>>>> specified >>>>>>>>>>>>>>> in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectivene= ss of >>>>>>>>>>>>>>> these strategies depends on the actual deployment situation= of >>>>>>>>>>>>>>> middleboxes. Therefore experimental verification to confir= m >>>>>>>>>>>>>>> large- >>>>>>>>>>>>>>> scale path traversal in the Internet is needed, e.g., by su= pport >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> major TCP stacks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I don=E2=80=99t understand your point here. I don=E2=80=99t = think that the >>>>>>>>>>>>>> paraphrase >>>>>>>>>>>>>> speculates about the consensus of tcpm, in contrast it say t= cpm has >>>>>>>>>>>>>> to >>>>>>>>>>>>>> decided if the requirements previously specified by tcpm are >>>>>>>>>>>>>> sufficiently >>>>>>>>>>>>>> fulfilled. I don=E2=80=99t see a reason to not mention the r= equirement >>>>>>>>>>>>>> draft as >>>>>>>>>>>>>> this >>>>>>>>>>>>>> draft as tcpm consensus and was written for this purpose. >>>>>>>>>>>>> >>>>>>>>>>>>> My suggested wording uses the expression "can be deployed at = large >>>>>>>>>>>>> scale" >>>>>>>>>>>>> and I believe this is relevant. >>>>>>>>>>>>> >>>>>>>>>>>>> The document already describes in Section 5 how the protocol >>>>>>>>>>>>> satisfies >>>>>>>>>>>>> the agreed requirements for a more accurate ECN feedback prot= ocol >>>>>>>>>>>>> [RFC7560]. >>>>>>>>>>>>> So, if the TCPM working group publishes this document with th= e >>>>>>>>>>>>> content of >>>>>>>>>>>>> Section 5, I believe the TCPM working group already has reach= ed >>>>>>>>>>>>> consensus >>>>>>>>>>>>> that the protocol meets requirements. In addition, it is poss= ible >>>>>>>>>>>>> that new >>>>>>>>>>>>> requirements would be identified in future, e.g., as an outco= me of >>>>>>>>>>>>> the >>>>>>>>>>>>> experiment, and that would obviously have to be considered by= TCPM. >>>>>>>>>>>>> In that >>>>>>>>>>>>> case, for the success of the experiment not only RFC 7560 wou= ld >>>>>>>>>>>>> matter, but >>>>>>>>>>>>> also further requirements. My proposed wording does not have = all >>>>>>>>>>>>> these >>>>>>>>>>>>> problems. >>>>>>>>>>>>> >>>>>>>>>>>>> In a nutshell, I continue to believe that this section has to >>>>>>>>>>>>> change. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Okay, used your proposed wording. You have a point about the >>>>>>>>>>>> requirement >>>>>>>>>>>> and I mis-read you proposal earlier as =E2=80=9Ehas to be depl= oyed >>>>>>>>>>>> large-scale=E2=80=9C. >>>>>>>>>>>> >>>>>>>>>>>>>>> * 1.5. Recap of Existing ECN feedback in IP/TCP >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This section could probably be shortened as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The last bit in byte 13 of the TCP header was defined as th= e >>>>>>>>>>>>>>> Nonce >>>>>>>>>>>>>>> Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never >>>>>>>>>>>>>>> deployed >>>>>>>>>>>>>>> so >>>>>>>>>>>>>>> it is being reclassified as historic, making this TCP flag >>>>>>>>>>>>>>> available >>>>>>>>>>>>>>> for use by the AccECN experiment instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This wording, as well as Figure 1, needs to take into = account >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> IANA >>>>>>>>>>>>>> >>>>>>>>>>>>>> status when draft-ietf-tsvwg-ecn-experimentation is publishe= d. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is does. However, I can explicitly say that is has be re-cls= sified >>>>>>>>>>>>>> as >>>>>>>>>>>>>> reserved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> "RFC 3540 was never deployed so it is being reclassified as >>>>>>>>>>>>>> historic >>>>>>>>>>>>>> [I-D.ietf- >>>>>>>>>>>>>> tsvwg-ecn-experimentation] and the respective flag has been = marked >>>>>>>>>>>>>> as >>>>>>>>>>>>>> =E2=80=9Ereserved=E2=80=9C in the IANA TCP Header Flags regi= stry, making this TCP >>>>>>>>>>>>>> flag >>>>>>>>>>>>>> available for use by the AccECN experiment instead.=E2=80=9C >>>>>>>>>>>>>> >>>>>>>>>>>>>> Better? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In my understanding, this experimental document asks for ne= w >>>>>>>>>>>>>>> assignment >>>>>>>>>>>>>> >>>>>>>>>>>>>> of a reserved TCP header flag. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I said I=E2=80=99m not sure if we have fully concluded th= is discussion >>>>>>>>>>>>>> yet. >>>>>>>>>>>>>> However, >>>>>>>>>>>>>> what we really would want to is mention somewhere that this >>>>>>>>>>>>>> experiment >>>>>>>>>>>>>> with this flags is running. I guess there are three options: >>>>>>>>>>>>>> 1) keep it in the registry as reserved and conserve the know= ledge >>>>>>>>>>>>>> in >>>>>>>>>>>>>> tcpm >>>>>>>>>>>>>> that this experiment is running and no other experimental RF= C such >>>>>>>>>>>>>> use >>>>>>>>>>>>>> this >>>>>>>>>>>>>> flags as long as this experiment is running. >>>>>>>>>>>>>> 2) Keep is marked as reserved but add a note about this expe= riment >>>>>>>>>>>>>> in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> IANA registry >>>>>>>>>>>>>> 3) Or assign it right away with IESG approval. I guess in th= is case >>>>>>>>>>>>>> tcpm >>>>>>>>>>>>>> could >>>>>>>>>>>>>> also consider to change the registration policy to =E2=80=9E= IETF Review=E2=80=9C. >>>>>>>>>>>>> >>>>>>>>>>>>> The current registration policy for the TCP header flags is >>>>>>>>>>>>> "standards >>>>>>>>>>>>> action". I understand that the IESG could approve exceptions.= But >>>>>>>>>>>>> given the >>>>>>>>>>>>> policy, I believe the document has to be very precise on the = request >>>>>>>>>>>>> regarding bit 7. >>>>>>>>>>>> >>>>>>>>>>>> Okay, it now says: >>>>>>>>>>>> >>>>>>>>>>>> "[TO BE REMOVED: IANA is requested to update the existing entr= y in >>>>>>>>>>>> the >>>>>>>>>>>> Transmission Control Protocol (TCP) Header Flags registration >>>>>>>>>>>> >>>>>>>>>>>> (https://www.iana.org/assignments/tcp-header-flags/tcp-header-= flags.xhtml#tcp-header-flags-1) >>>>>>>>>>>> for Bit 7 to "AE (Accurate ECN), previously used by Historic a= s NS >>>>>>>>>>>> (Nonce >>>>>>>>>>>> Sum) [RFC3540, RFC8311]" and change the reference to this RFC-= to-be >>>>>>>>>>>> instead >>>>>>>>>>>> of RFC8311.]=E2=80=9C >>>>>>>>>>>> >>>>>>>>>>>> I guess we could also ask IANA to add an additional comment co= lumn >>>>>>>>>>>> instead >>>>>>>>>>>> (but not sure if we then have to update RFC3168, which I think= we >>>>>>>>>>>> really >>>>>>>>>>>> don=E2=80=99t want. Should be fine now. >>>>>>>>>>>> >>>>>>>>>>>>>>> * 2. AccECN Protocol Overview and Rationale >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o an essential part that re-uses ECN TCP header bits to fe= ed >>>>>>>>>>>>>>> back >>>>>>>>>>>>>>> the number of arriving CE marked packets. This provides= more >>>>>>>>>>>>>>> accuracy than classic ECN feedback, but limited resilien= ce >>>>>>>>>>>>>>> against >>>>>>>>>>>>>>> ACK loss; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] The word "re-use" is IMHO not correct. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think this is nit picking. Using a different phrasing here= makes >>>>>>>>>>>>>> the >>>>>>>>>>>>>> sentence >>>>>>>>>>>>>> unnecessary complicated. We don=E2=80=99t try to some how ge= t a round the >>>>>>>>>>>>>> fact >>>>>>>>>>>>>> that we need to handle the flag registration correctly. Howe= ver, >>>>>>>>>>>>>> here >>>>>>>>>>>>>> the >>>>>>>>>>>>>> point really is to explain how the protocol word. The main p= oint of >>>>>>>>>>>>>> using the >>>>>>>>>>>>>> work =E2=80=9Ere-use=E2=80=9C here is really that we say tha= t these flags are or >>>>>>>>>>>>>> have >>>>>>>>>>>>>> been >>>>>>>>>>>>>> used different by other TCP extension (and we therefore need= a >>>>>>>>>>>>>> proper >>>>>>>>>>>>>> negotiation scheme). >>>>>>>>>>>>> >>>>>>>>>>>>> If the allocation of a reserved flag is correctly explained i= n the >>>>>>>>>>>>> abstract and introduction, I think these sentences can use a = bit >>>>>>>>>>>>> relaxed >>>>>>>>>>>>> terminology. >>>>>>>>>>>>> >>>>>>>>>>>>>>> The two part design was necessary, given limitations on the >>>>>>>>>>>>>>> space >>>>>>>>>>>>>>> available for TCP options and given the possibility that ce= rtain >>>>>>>>>>>>>>> incorrectly designed middleboxes prevent TCP using any new >>>>>>>>>>>>>>> options >>>>>> >>>>>> >>>>>> -- >>>>>> ________________________________________________________________ >>>>>> Bob Briscoe http://bobbriscoe.net/ >>>>>> >>>>> >>>> >>>> >>> >> >> From nobody Fri Jul 13 13:59:22 2018 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 CD790130E25; Fri, 13 Jul 2018 13:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 I8b3aMqnQxmb; Fri, 13 Jul 2018 13:59:18 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DBB130E17; Fri, 13 Jul 2018 13:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41S4tD0SKtzMpd7; Fri, 13 Jul 2018 22:59:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UVtYsfz4KV2; Fri, 13 Jul 2018 22:59:15 +0200 (CEST) X-MtScore: NO score=0 Received: from [172.20.4.114] (unknown [207.96.227.254]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Jul 2018 22:59:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 13 Jul 2018 16:59:11 -0400 Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1E4B736B-DCB5-4A17-AEAD-8E773139345B@tik.ee.ethz.ch> References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 20:59:21 -0000 > Am 13.07.2018 um 16:45 schrieb Yuchung Cheng : >=20 >>>>> 3. Leave ACE-count and ACE option optional (i.e. MAY) >>>>=20 >>>> I don=E2=80=99t understand this. If both is optional, you don=E2=80=99= t have any feedback. Or what do you mean by =E2=80=9Eleave ACE-count = optional=E2=80=9C? >>> use-case: We can negotiate DCTCP-style ECN for the internet. >>>=20 >>> Then interested parties can progressively experiment on more = accurate >>> "options" (!=3D TCP-option) >>=20 >> As Appendix A of RFC7560 says I don=E2=80=99t think it is a safe = option for the Internet where packet loss more likely then in a full = ECN-enabled data center. >=20 > Again I disagree RFC7560 Appendix A is a big problem based on my > experience with at times loss-heavy ECN-enabled data-center (Google > data-center runs very hot and uses a DCTCP-variant). >=20 > We can quabble forever w/o data. That's why I asked for some > (non-simulation) data. I=E2=80=99m not sure if that is a question about data. With the feedback = scheme that is used by DCTCP a single ACK loss can already cause = feedback to get lost and I don=E2=80=99t think that a safe option to be = deployed on the Internet. Actually in high loss situation the chance to = at least get some feedback is pretty high, however, if you only have a = single CE mark, chances to misses that are much higher. The other problem with the feedback scheme used by DCTCP is that is does = not provide feedback for control packets (as it relies on the ACK/SEQ = number with does not increase for control packets) and therefore cannot = be used with ECN++. Mirja From nobody Fri Jul 13 14:02:12 2018 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 D05A5130E37; Fri, 13 Jul 2018 14:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hwiZPGHR4las; Fri, 13 Jul 2018 14:02:07 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9705F130E17; Fri, 13 Jul 2018 14:02:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41S4xV2WShzMp9D; Fri, 13 Jul 2018 23:02:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQY1qFRGT5Wf; Fri, 13 Jul 2018 23:02:05 +0200 (CEST) X-MtScore: NO score=0 Received: from [172.20.4.114] (unknown [207.96.227.254]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Jul 2018 23:02:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 13 Jul 2018 17:02:02 -0400 Cc: Bob Briscoe , "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 13 Jul 2018 21:02:10 -0000 > Am 13.07.2018 um 16:54 schrieb Yuchung Cheng : >=20 > I recall you mentioned you have a ACE Linux patch. Could you share w/ = me? the implementation is here but it=E2=80=99s not complete regarding the = latest spec and not well tested: https://github.com/mirjak/linux-accecn Let me see if I can look into this in August sometime! Mirja From nobody Fri Jul 13 17:52:19 2018 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 6AFCC130F62; Fri, 13 Jul 2018 17:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 E9EmYjAN-k1l; Fri, 13 Jul 2018 17:52:11 -0700 (PDT) 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 1D983130F53; Fri, 13 Jul 2018 17:52:09 -0700 (PDT) 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=pGSn3jZmGPLeWWwLGyYz6ArEraDHZmEcCO8V/LXgJAw=; b=iXbqkzBnSH7rIwQep7hRDAcMF tVMLiy2MBn3136w1ksGeNoKiGRYPllS2Me7/9TVe47mfI8b4IbASNteYs5+gn2u+7W/FWjeJ8jXZ6 zZHToCU1Xp5qBOrLKFInb36wF6cUMK7nOfg/9CF/vxYWCyBWePPKY2vu8B50vCW9XBG7nJUaoBlGX 7P8EQwqupVJ5F6D+vCAr14bMW5TB4ktDPBbNad2GfKjY433xtSi1XAITsj98WrTJSuIBxWM8Lrexg cC2dDgFVQNuNqUeCN/p6ecs03SMtCPJur0Td0jpK0sGRj02P92CdeHMq14oK/KkEewsbqHsbwbo1W m0qP8SCgQ==; Received: from 70.245.199.146.dyn.plus.net ([146.199.245.70]:42114 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fe8n7-0008Pv-JL; Sat, 14 Jul 2018 01:52:06 +0100 To: Yuchung Cheng , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" References: <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch> <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch> <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch> From: Bob Briscoe Message-ID: Date: Sat, 14 Jul 2018 01:52:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------39BCA64FFC8DCE4F3C8D56F4" 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] Comments on draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 00:52:16 -0000 This is a multi-part message in MIME format. --------------39BCA64FFC8DCE4F3C8D56F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yuchung, On 13/07/18 21:45, Yuchung Cheng wrote: > On Fri, Jul 13, 2018 at 12:42 PM, Mirja Kühlewind > wrote: >> Hi Yuchung, >> >>> Am 13.07.2018 um 15:30 schrieb Yuchung Cheng : >>> >>> On Fri, Jul 13, 2018 at 11:53 AM, Mirja Kühlewind >>> wrote: >>>> Hi Yucheng, >>>> >>>> please see below. >>>> >>>>> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng : >>>>> >>>>> hi -- >>>>> >>>>> I agree: >>>>> 1. delayed/streched ACK aren't going away (in fact will be more common) >>>>> 2. GRO isn't and should not be a show-stopper >>>>> 3. SYN option is running tight >>>>> 4. HW opt comes after SW >>>>> >>>>> I worry: >>>>> 1. GRO is a unavoidable issue in deployment (let's not produce an >>>>> undeployable RFC). the ACE counter won't work as GRO can pack up to >>>>> 64KB/MTU =~ 45 pkts under heavy congestion. [BB] I'm really not expert on offload, but I thought GRO collects (or can be made to collect) a set of fields from the headers it strips off? If I'm wrong (quite likely), bear in mind the following: * you only need the ACE counter (main header) when the AccECN Option is being stripped by a middlebox * on those connections that need ACE (cos of middlebox meddling) couldn't GRO be limited to 8 packets, at least while experimenting with AccECN to see if it is useful and gather data? * Appendix A.2. Example Algorithm for Safety Against Long Sequences of ACK Loss is not just for ACK losses. It would be just as useful if GRO 'lost' the headers. It uses the TCP acknowledgement number and any SACK options to check whether the ACE field could have wrapped, and if so by how much. >>>>> 4. If SYN option space is a concern, ACE header exchange is ok. But I >>>>> suspect the latter has more middlebox issue based on my TFO deployment >>>>> experience. You may remember earlier in TCPM, Marcelo presented the measurement study we did. Altho it was titled as primarily about ECN++ traversal (IP header), it also did a lot more limited measurements of traversal of the ECN flags (main TCP header). The paper summarizing the results is here, as well as the dataset:     http://www.it.uc3m.es/amandala/ecn++/ It covered 6.5 million different paths over 20 mobile networks in 8 European countries as well as over 50 fixed networks globally. I know that's diddly-squat compared to what Google can do, but the data is still worth a lot. However, the data we got on traversal of the TCP header was much more limited. We controlled all our client vantage points, but only a few servers, with the bulk of the servers being the Alexa 500k. Where we didn't control the server, we could only rely on using tracebox which checks ICMP TTL exceeded messages against what was sent. But few routers implement the updated ICMP [RFC1812] that includes more of the transport header than the first 8B. FWIW, we didn't find any mangling of the ECN TCP header flags. >>>>> >>>>> >>>>> So with all that said, is it possible to have a "minimal"-ACE that >>>>> 1. Does ACE handshake as proposed >>>>> >>>>> [snip #2 about ECN++] >>>>> 3. Leave ACE-count and ACE option optional (i.e. MAY) >>>> I don’t understand this. If both is optional, you don’t have any feedback. Or what do you mean by „leave ACE-count optional“? >>> use-case: We can negotiate DCTCP-style ECN for the internet. >>> >>> Then interested parties can progressively experiment on more accurate >>> "options" (!= TCP-option) I must point out that there is very limited space and flexibility for versioning experiments with multiple variants of how the 3 'ECN' flags in the main header are used. You will see from the latest appendix B (added in response to Michael Scharf's point on this) that there is no more space for further negotiation on the SYN or SYN/ACK, but there are 5 unused codepoints on the final ACK of the 3WHS and 7 on the first data packet. Ideally the negotiation would be on the SYN and SYN/ACK though, especially if used in combination with TFO. This means you will need to be much more certain about whether there really are GRO problems, or just maybe. And if so, we're going to have to try to work out a solution on paper first (or at least on private networks), rather than burning bits by trial and error. This also means going into the depths of the draft in full (if you haven't already done so), cos the co-authors did go thru a huge number of possible designs ourselves over the years, and we fixed all sorts of potential problems in the process. Put another way, if you start from scratch, you will be finding new problems to solve for a year or so after you start. BTW, there is a lot more scope for versioning multiple variants of AccECN TCP options. >> As Appendix A of RFC7560 says I don’t think it is a safe option for the Internet where packet loss more likely then in a full ECN-enabled data center. > Again I disagree RFC7560 Appendix A is a big problem based on my > experience with at times loss-heavy ECN-enabled data-center (Google > data-center runs very hot and uses a DCTCP-variant). To be clear, you're only disagreeing that packet loss is not a non-problem in DCs (excuse the double negative). You're not disagreeing that packet loss is a problem for DCTCP feedback. Cheers Bob > > We can quabble forever w/o data. That's why I asked for some > (non-simulation) data. > >> Mirja >> >> >> >>>> Mirja >>>> >>>> >>>> >>>>> as a "fairly safe" to deployment compromise. And I am happy to draft a >>>>> kernel patch for that :-) >>>>> >>>>> >>>>> >>>>> On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe wrote: >>>>>> Yuchung, >>>>>> >>>>>> On 12/07/18 17:03, Mirja Kühlewind wrote: >>>>>>> Hi Yuchung, >>>>>>> >>>>>>> please see below. >>>>>>> >>>>>>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng : >>>>>>>> >>>>>>>> Yes packets with ACE options and (different) ACE-counter header would >>>>>>>> break GRO. There're many legacy h/w and s/w. >>>>>>> I’m not the expert here but my understanding is that is would not break >>>>>>> GRO but could not make actual use or it if the ACE counter changed or the >>>>>>> option is present. >>>>>> [BB] Yuchung's criticism applies to any scheme that feeds back a continually >>>>>> changing signal like ECN. For instance, like AccECN feedback, DCTCP ECN >>>>>> feedback continually changes the TCP header flags, and I believe DCTCP is >>>>>> widely used in DCs. >>>>>> >>>>>> I believe, to make GRO support ECN feedback (whether DCTCP or AccECN), it >>>>>> would be necessary for GRO to know which bits to mask when determining >>>>>> whether a packet is mergeable with others. I believe GRO already collects >>>>>> header fields separately for the TCP logic to be able to work on them, but >>>>>> I'm also not an expert. >>>>>>> However, usually your will only have a small number of CE marks every >>>>>>> couple of RTTs, and the counter only changes if you CE marks/the option is >>>>>>> only present a few times per RTT. So the impact should be rather low. But >>>>>>> this clear something to evaluate for the experiment. >>>>>> [BB] With DCTCP as currently designed, you tend to get runs of 100% CE if >>>>>> the load of short flows is very small. In that case, DCTCP feedback will >>>>>> change the header flags less often than AccECN. However, with more short >>>>>> flows, the feedback is more on-off. Then the flags change more often with >>>>>> DCTCP than with AccECN feedback. >>>>>> >>>>>> In general, hardware optimization is not going to optimize a protocol that >>>>>> didn't exist when the hardware was designed. It would be ideal to design a >>>>>> new protocol that takes advantage of existing hardware optimization. >>>>>> However, as long as an experimental protocol still works with existing >>>>>> hardware, I think it's reasonable to assume that hardware optimization will >>>>>> only arrive once a protocol has become well-established. >>>>>> >>>>>>>> Even without option, ACE header only allows reflecting up to 8 packets >>>>>>>> for receiver segmentation offload and ACK suppression? >>>>>>> Same as above, it can only up to 8 CE marked packets per ACK, however, CE >>>>>>> marking rater are expected to be rather low. ACK suppression should probably >>>>>>> not be used if the ACE counter has changes, however, usually the ACE counter >>>>>>> stays stable for multiple RTTs and then ACK suppression is not a problem. >>>>>>> However, not sure I understood you question here correctly…? >>>>>>> >>>>>>>> The appendix on ack loss causes ambiguity is good: but the pattern >>>>>>>> drops specifically the state-switch (CE<->noCE) ACK which only happens >>>>>>>> on delayed ACK. Is that pattern common? - or can we address most of >>>>>>>> that by delaying less ACKs? >>>>>>> I guess you have a 50% chance today to hit a delayed ACK. I guess delaying >>>>>>> less (where you delay every second ACK today) would mean ACK every packet, >>>>>>> and thus double ACK load on the network. I guess on today networks that >>>>>>> actually in most cases not a problem, however, there might be specially >>>>>>> cases where it is. However, that’s problem an independent question to >>>>>>> evaluate. >>>>>> [BB] If there were no delayed ACKs, the problem with DCTCP feedback would >>>>>> largely disappear. But delayed ACKs are not going away. Which is why we >>>>>> proposed replacing DCTCP feedback with AccECN feedback. >>>>>>> >>>>>>>> I am all for making ECN more accurate for wide area beyond DCTCP, but >>>>>>>> am evaluating the pros/cons. What if we just >>>>>>>> 1. negotiate 'better' ECN via new SYN option >>>>>>> Not sure I understand your proposal correctly, but I assume you mean >>>>>>> negotiate via SYN option and then just use the ACE counter in the header? If >>>>>>> so, I don’t understand why you see the negotiation part in the TCP header as >>>>>>> the problem? >>>>>> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a solution >>>>>> without a problem. In fact an option on the SYN would create a new problem >>>>>> 'cos of the severe shortage of space for SYN options (for this reason, the >>>>>> AccECN TCP option was designed not to be needed on the SYN). >>>>>>> >>>>>>>> 2. mark all packets like ECN++ >>>>>>> That would be nice but here you actually need AccECN because you want to >>>>>>> have feedback for control packets as well. AccECN is providing this >>>>>>> feedback. AccECN does not change the „use of ECN“; that’s what we have ECN++ >>>>>>> for; both thing ideally would be deployed together however. Was that your >>>>>>> questions? >>>>>> Cheers >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>>> Mirja >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja Kühlewind >>>>>>>> wrote: >>>>>>>>> Hi Yuchung, >>>>>>>>> >>>>>>>>> the question if you need this „more“ on accuracy really depends on the >>>>>>>>> use case. If you use DCTCP as today, the ACE counter in the TCP is probably >>>>>>>>> sufficient and you might not want to pay the additional overhead in your >>>>>>>>> data center (that why the option is actually optional). >>>>>>>>> >>>>>>>>> If you however, e.g., have very differently sized packets, then the byte >>>>>>>>> counter in the option could give you a more accurate signal. Or if you are >>>>>>>>> also interested in the ECT(1) counter, you need the option. Further the ACE >>>>>>>>> counter also give your feedback on control packet and the option enables you >>>>>>>>> to distinguish between CE-amrked payload and control packets, which can also >>>>>>>>> become important when experimenting with making all packets ECN-capable. >>>>>>>>> >>>>>>>>> Given accECN is a general feedback mechanism that in fact is designed to >>>>>>>>> enable new future uses of the ECN signal, we wanted to keep all these option >>>>>>>>> available while making is still as simple as possible and as flexible as >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> Mirja >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng : >>>>>>>>>> >>>>>>>>>> Hi Bob, >>>>>>>>>> >>>>>>>>>> Neal and I evaluated the earlier draft. It is well-thought out but >>>>>>>>>> we're concerned about the options. Option is not mandatory but the >>>>>>>>>> lack of it also reduces accuracy. Option runs into space issues w/ >>>>>>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure but >>>>>>>>>> aren't easy. >>>>>>>>>> >>>>>>>>>> We're curious how much more "accuracy" it buys over current >>>>>>>>>> DCTCP-style ECN. Is there any study to show trade-offs of >>>>>>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe >>>>>>>>>> wrote: >>>>>>>>>>> Michael, tcpm list, >>>>>>>>>>> >>>>>>>>>>> As well as addressing your points, as Mirja has already mentioned >>>>>>>>>>> below, we >>>>>>>>>>> added a whole new appendix giving the rationale for the bits and >>>>>>>>>>> codepoints >>>>>>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd >>>>>>>>>>> subsection also identifies space for future evolution. It also points >>>>>>>>>>> to >>>>>>>>>>> where rationale was already given in the body of the draft. >>>>>>>>>>> >>>>>>>>>>> The appendix is in the draft submitted last week, available here: >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B >>>>>>>>>>> >>>>>>>>>>> We'd be interested to hear whether this allays your concerns. >>>>>>>>>>> >>>>>>>>>>> We have asked to present this in Montreal as well. >>>>>>>>>>> >>>>>>>>>>> Cheers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bob >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 02/07/18 16:54, Mirja Kühlewind wrote: >>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>> >>>>>>>>>>>> I addressed a couple of your comments below. >>>>>>>>>>>> >>>>>>>>>>>> For the other, bigger comments regarding extensibility, that I did >>>>>>>>>>>> not yet >>>>>>>>>>>> address below, we plan to add a new section to the appendix to >>>>>>>>>>>> explain >>>>>>>>>>>> extensibility options as previously discussed by mail. We will >>>>>>>>>>>> probably send >>>>>>>>>>>> a separate email on that part. >>>>>>>>>>>> >>>>>>>>>>>> Mirja >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Mirja, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some of the >>>>>>>>>>>>> editorial suggestions. >>>>>>>>>>>>> >>>>>>>>>>>>> Yet, I continue to believe that some formal wording in the document >>>>>>>>>>>>> needs >>>>>>>>>>>>> to change, as explained below. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >>>>>>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM >>>>>>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org >>>>>>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks for your feedback and sorry for my late reply. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please see inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia - >>>>>>>>>>>>>>> DE/Stuttgart) >>>>>>>>>>>>>> : >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the >>>>>>>>>>>>>>> appendix). I >>>>>>>>>>>>>> believe this document needs further work before moving forward. >>>>>>>>>>>>>>> Please find below my comments marked as [ms]. I have read the >>>>>>>>>>>>>> document independent of the review from Gorry. I apologize if there >>>>>>>>>>>>>> is >>>>>>>>>>>>>> duplication. >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Michael (with no hat on) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ****************************** >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Abstract: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or >>>>>>>>>>>>>>> Data >>>>>>>>>>>>>> Center TCP >>>>>>>>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever >>>>>>>>>>>>>>> more >>>>>>>>>>>>>>> than one marking is received in one RTT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I >>>>>>>>>>>>>>> suggest to >>>>>>>>>>>>>> remove this, or replace it by a more generic statement that more >>>>>>>>>>>>>> accurate >>>>>>>>>>>>>> information can be useful for several TCP extensions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate information. >>>>>>>>>>>>>> They do >>>>>>>>>>>>>> not need the mechanism that is specified in this draft, however, >>>>>>>>>>>>>> this is >>>>>>>>>>>>>> not >>>>>>>>>>>>>> what the sentences is saying. >>>>>>>>>>>>> In my understanding (as a non-native speaker), the use of the word >>>>>>>>>>>>> "need" >>>>>>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be >>>>>>>>>>>>> implemented >>>>>>>>>>>>> without any such mechanism. >>>>>>>>>>>>> >>>>>>>>>>>>> What would work for me is something of the form "... Data Center TCP >>>>>>>>>>>>> cannot get precise ECN feedback whenever more than one marking is >>>>>>>>>>>>> received >>>>>>>>>>>>> in one RTT“. >>>>>>>>>>>> This is not correct. DCTP need more than one feedback signal per RTT >>>>>>>>>>>> and >>>>>>>>>>>> therefore cannot use RFC3168; instead it implement it’s own feedback >>>>>>>>>>>> mechanism. However, to avoid confusion such that people could assume >>>>>>>>>>>> DCTP >>>>>>>>>>>> would not work without the accECN scheme as specified in this doc, I >>>>>>>>>>>> rephrased to: >>>>>>>>>>>> >>>>>>>>>>>> "Recently, proposed >>>>>>>>>>>> mechanisms like Congestion Exposure (ConEx >>>>>>>>>>> target="RFC7713"/>), >>>>>>>>>>>> DCTCP or L4S >>>>>>>>>>> target="I-D.ietf-tsvwg-l4s-arch"/> need to know when more than >>>>>>>>>>>> one >>>>>>>>>>>> marking is received in one RTT which is >>>>>>>>>>>> information that cannot be provided by the feedback scheme as >>>>>>>>>>>> specified in >>>>>>>>>>>> ." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> This document specifies an >>>>>>>>>>>>>>> experimental scheme to provide more than one feedback signal per >>>>>>>>>>>>>>> RTT >>>>>>>>>>>>>>> in the TCP header. Given TCP header space is scarce, it >>>>>>>>>>>>>>> overloads >>>>>>>>>>>>>>> the three existing ECN-related flags in the TCP header and >>>>>>>>>>>>>>> provides >>>>>>>>>>>>>>> additional information in a new TCP option. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This statement needs to be rewritten to correctly reflect >>>>>>>>>>>>>>> what is >>>>>>>>>>>>>> requested from IANA. My understanding is that this experimental >>>>>>>>>>>>>> document >>>>>>>>>>>>>> asks for allocation of a reserved TCP header flag. This needs to be >>>>>>>>>>>>>> called out >>>>>>>>>>>>>> prominently, IMHO. In addition, since this is not a standard, the >>>>>>>>>>>>>> suggested >>>>>>>>>>>>>> experimentation with the main TCP header must IMHO be explicitly >>>>>>>>>>>>>> mentioned. I also suggest to have later in a document a section >>>>>>>>>>>>>> that >>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>> explains why it is appropriate to modify the main TCP header in an >>>>>>>>>>>>>> experiment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don’t know if any requirement that IANA assignment need to be >>>>>>>>>>>>>> called >>>>>>>>>>>>>> out >>>>>>>>>>>>>> in the abstract but we can do that. However, I believe the question >>>>>>>>>>>>>> if >>>>>>>>>>>>>> this >>>>>>>>>>>>>> document should or should not assign the bit is still not >>>>>>>>>>>>>> completely >>>>>>>>>>>>>> solved, or >>>>>>>>>>>>>> is it? >>>>>>>>>>>>> I believe this question will have to be reviewed during WGLC and, >>>>>>>>>>>>> more >>>>>>>>>>>>> importantly, IETF last call. For the moment, my concern is that the >>>>>>>>>>>>> document >>>>>>>>>>>>> correctly describes the IANA allocation. >>>>>>>>>>>>> >>>>>>>>>>>>> I would like to see here a statement such as : "Given TCP header >>>>>>>>>>>>> space is >>>>>>>>>>>>> scarce, this specification allocates a reserved header bit and >>>>>>>>>>>>> overloads the >>>>>>>>>>>>> two ECN flags in the TCP header ...“. >>>>>>>>>>>> A bit lengthy but now: >>>>>>>>>>>> >>>>>>>>>>>> "Given TCP header space is >>>>>>>>>>>> scarce, it allocates a reserved header bit, that was previously >>>>>>>>>>>> used for >>>>>>>>>>>> ECN-Nonce which was recently declared historic, and overloads >>>>>>>>>>>> the >>>>>>>>>>>> two existing ECN flags in the TCP header. Further, additional >>>>>>>>>>>> information can be provided in a new TCP option that however is >>>>>>>>>>>> not >>>>>>>>>>>> used >>>>>>>>>>>> on the TCP SYN." >>>>>>>>>>>> >>>>>>>>>>>>>>> * 1. Introduction >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] >>>>>>>>>>>>>>> need >>>>>>>>>>>>>>> more accurate ECN feedback information whenever more than one >>>>>>>>>>>>>> marking >>>>>>>>>>>>>>> is received in one RTT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit this. >>>>>>>>>>>>>>> Instead >>>>>>>>>>>>>> of stating a "need", it would IMHO make more sense to discuss the >>>>>>>>>>>>>> benefits >>>>>>>>>>>>>> of the suggested mechanism in this document of its own, independent >>>>>>>>>>>>>> of >>>>>>>>>>>>>> other proposals. To me, this document should be independent of >>>>>>>>>>>>>> other >>>>>>>>>>>>>> documents and specifically other experiments. We have to think >>>>>>>>>>>>>> about >>>>>>>>>>>>>> cases >>>>>>>>>>>>>> where not all experiments are successful. Then independent >>>>>>>>>>>>>> documents >>>>>>>>>>>>>> will >>>>>>>>>>>>>> be more future-proof in future. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a naming collision… The sentence was meant to say that >>>>>>>>>>>>>> these >>>>>>>>>>>>>> mechanisms new more accurate ECN feedback than provided today by >>>>>>>>>>>>>> RFC3168 but it was not meant to say that these mechanism have to >>>>>>>>>>>>>> use the >>>>>>>>>>>>>> scheme as specified in this document. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added the following part sentence: >>>>>>>>>>>>>> >>>>>>>>>>>>>> „Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need >>>>>>>>>>>>>> more >>>>>>>>>>>>>> accurate ECN feedback information than provided by the feedback >>>>>>>>>>>>>> scheme >>>>>>>>>>>>>> as specified in [RFC3168] whenever more than one marking is >>>>>>>>>>>>>> received in >>>>>>>>>>>>>> one >>>>>>>>>>>>>> RTT. This document specifies an alternative feedback scheme that >>>>>>>>>>>>>> provides >>>>>>>>>>>>>> more accurate information and could be used by these new TCP >>>>>>>>>>>>>> extensions.“ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does this help? >>>>>>>>>>>>> See my proposal for the abstract. I continue to disagree with the >>>>>>>>>>>>> term >>>>>>>>>>>>> "need" but I think this can be sorted out by another term. >>>>>>>>>>>>> >>>>>>>>>>>>>>> If AccECN progresses from experimental to the standards >>>>>>>>>>>>>>> track, it is intended to be a complete replacement for classic >>>>>>>>>>>>>>> TCP/ >>>>>>>>>>>>>>> ECN feedback, not a fork in the design of TCP. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ms] This sentence should be removed, as this is speculation -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------39BCA64FFC8DCE4F3C8D56F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yuchung,

On 13/07/18 21:45, Yuchung Cheng wrote:
On Fri, Jul 13, 2018 at 12:42 PM, Mirja Kühlewind
<mirja.kuehlewind@tik.ee.ethz.ch> wrote:

Hi Yuchung,


Am 13.07.2018 um 15:30 schrieb Yuchung Cheng <ycheng@google.com>:

On Fri, Jul 13, 2018 at 11:53 AM, Mirja Kühlewind
<mirja.kuehlewind@tik.ee.ethz.ch> wrote:

Hi Yucheng,

please see below.


Am 13.07.2018 um 14:38 schrieb Yuchung Cheng <ycheng@google.com>:

hi --

I agree:
1. delayed/streched ACK aren't going away (in fact will be more common)
2. GRO isn't and should not be a show-stopper
3. SYN option is running tight
4. HW opt comes after SW

I worry:
1. GRO is a unavoidable issue in deployment (let's not produce an
undeployable RFC). the ACE counter won't work as GRO can pack up to
64KB/MTU =~ 45 pkts under heavy congestion.
[BB] I'm really not expert on offload, but I thought GRO collects (or can be made to collect) a set of fields from the headers it strips off?

If I'm wrong (quite likely), bear in mind the following:
* you only need the ACE counter (main header) when the AccECN Option is being stripped by a middlebox
* on those connections that need ACE (cos of middlebox meddling) couldn't GRO be limited to 8 packets, at least while experimenting with AccECN to see if it is useful and gather data?

* Appendix A.2.  Example Algorithm for Safety Against Long Sequences of ACK Loss is not just for ACK losses. It would be just as useful if GRO 'lost' the headers. It uses the TCP acknowledgement number and any SACK options to check whether the ACE field could have wrapped, and if so by how much.


4. If SYN option space is a concern, ACE header exchange is ok. But I
suspect the latter has more middlebox issue based on my TFO deployment
experience.
You may remember earlier in TCPM, Marcelo presented the measurement study we did. Altho it was titled as primarily about ECN++ traversal (IP header), it also did a lot more limited measurements of traversal of the ECN flags (main TCP header).

The paper summarizing the results is here, as well as the dataset:
    http://www.it.uc3m.es/amandala/ecn++/

It covered 6.5 million different paths over 20 mobile networks in 8 European countries as well as over 50 fixed networks globally. I know that's diddly-squat compared to what Google can do, but the data is still worth a lot.

However, the data we got on traversal of the TCP header was much more limited. We controlled all our client vantage points, but only a few servers, with the bulk of the servers being the Alexa 500k. Where we didn't control the server, we could only rely on using tracebox which checks ICMP TTL exceeded messages against what was sent. But few routers implement the updated ICMP [RFC1812] that includes more of the transport header than the first 8B.

FWIW, we didn't find any mangling of the ECN TCP header flags.




So with all that said, is it possible to have a "minimal"-ACE that
1. Does ACE handshake as proposed
[snip #2 about ECN++]
3. Leave ACE-count and ACE option optional (i.e. MAY)

I don’t understand this. If both is optional, you don’t have any feedback. Or what do you mean by „leave ACE-count optional“?

use-case: We can negotiate DCTCP-style ECN for the internet.

Then interested parties can progressively experiment on more accurate
"options" (!= TCP-option)
I must point out that there is very limited space and flexibility for versioning experiments with multiple variants of how the 3 'ECN' flags in the main header are used. You will see from the latest appendix B (added in response to Michael Scharf's point on this) that there is no more space for further negotiation on the SYN or SYN/ACK, but there are 5 unused codepoints on the final ACK of the 3WHS and 7 on the first data packet. Ideally the negotiation would be on the SYN and SYN/ACK though, especially if used in combination with TFO.

This means you will need to be much more certain about whether there really are GRO problems, or just maybe. And if so, we're going to have to try to work out a solution on paper first (or at least on private networks), rather than burning bits by trial and error.

This also means going into the depths of the draft in full (if you haven't already done so), cos the co-authors did go thru a huge number of possible designs ourselves over the years, and we fixed all sorts of potential problems in the process.

Put another way, if you start from scratch, you will be finding new problems to solve for a year or so after you start.


BTW, there is a lot more scope for versioning multiple variants of AccECN TCP options.

As Appendix A of RFC7560 says I don’t think it is a safe option for the Internet where packet loss more likely then in a full ECN-enabled data center.

Again I disagree RFC7560 Appendix A is a big problem based on my
experience with at times loss-heavy ECN-enabled data-center (Google
data-center runs very hot and uses a DCTCP-variant).
To be clear, you're only disagreeing that packet loss is not a non-problem in DCs (excuse the double negative). You're not disagreeing that packet loss is a problem for DCTCP feedback.

Cheers



Bob

We can quabble forever w/o data. That's why I asked for some
(non-simulation) data.


Mirja





          

            
Mirja





            

              
as a "fairly safe" to deployment compromise. And I am happy to draft a
kernel patch for that :-)



On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:


              

                
Yuchung,

On 12/07/18 17:03, Mirja Kühlewind wrote:


                

                  
Hi Yuchung,

please see below.



                  

                    
Am 12.07.2018 um 11:41 schrieb Yuchung Cheng <ycheng@google.com>:

Yes packets with ACE options and (different) ACE-counter header would
break GRO. There're many legacy h/w and s/w.


                  

                  
I’m not the expert here but my understanding is that is would not break
GRO but could not make actual use or it if the ACE counter changed or the
option is present.


                

                
[BB] Yuchung's criticism applies to any scheme that feeds back a continually
changing signal like ECN. For instance, like AccECN feedback, DCTCP ECN
feedback continually changes the TCP header flags, and I believe DCTCP is
widely used in DCs.

I believe, to make GRO support ECN feedback (whether DCTCP or AccECN), it
would be necessary for GRO to know which bits to mask when determining
whether a packet is mergeable with others. I believe GRO already collects
header fields separately for the TCP logic to be able to work on them, but
I'm also not an expert.


                

                  
However, usually your will only have a small number of CE marks every
couple of RTTs, and the counter only changes if you CE marks/the option is
only present a few times per RTT. So the impact should be rather low. But
this clear something to evaluate for the experiment.


                

                
[BB] With DCTCP as currently designed, you tend to get runs of 100% CE if
the load of short flows is very small. In that case, DCTCP feedback will
change the header flags less often than AccECN. However, with more short
flows, the feedback is more on-off. Then the flags change more often with
DCTCP than with AccECN feedback.

In general, hardware optimization is not going to optimize a protocol that
didn't exist when the hardware was designed. It would be ideal to design a
new protocol that takes advantage of existing hardware optimization.
However, as long as an experimental protocol still works with existing
hardware, I think it's reasonable to assume that hardware optimization will
only arrive once a protocol has become well-established.



                

                  

                  

                    
Even without option, ACE header only allows reflecting up to 8 packets
for receiver segmentation offload and ACK suppression?


                  

                  
Same as above, it can only up to 8 CE marked packets per ACK, however, CE
marking rater are expected to be rather low. ACK suppression should probably
not be used if the ACE counter has changes, however, usually the ACE counter
stays stable for multiple RTTs and then ACK suppression is not a problem.
However, not sure I understood you question here correctly…?



                  

                    
The appendix on ack loss causes ambiguity is good: but the pattern
drops specifically the state-switch (CE<->noCE) ACK which only happens
on delayed ACK. Is that pattern common? - or can we address most of
that by delaying less ACKs?


                  

                  
I guess you have a 50% chance today to hit a delayed ACK. I guess delaying
less (where you delay every second ACK today) would mean ACK every packet,
and thus double ACK load on the network. I guess on today networks that
actually in most cases not a problem, however, there might be specially
cases where it is. However, that’s problem an independent question to
evaluate.


                

                
[BB] If there were no delayed ACKs, the problem with DCTCP feedback would
largely disappear. But delayed ACKs are not going away. Which is why we
proposed replacing DCTCP feedback with AccECN feedback.


                

                  



                  

                    
I am all for making ECN more accurate for wide area beyond DCTCP, but
am evaluating the pros/cons. What if we just
1. negotiate 'better' ECN via new SYN option


                  

                  
Not sure I understand your proposal correctly, but I assume you mean
negotiate via SYN option and then just use the ACE counter in the header? If
so, I don’t understand why you see the negotiation part in the TCP header as
the problem?


                

                
[BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a solution
without a problem. In fact an option on the SYN would create a new problem
'cos of the severe shortage of space for SYN options (for this reason, the
AccECN TCP option was designed not to be needed on the SYN).


                

                  



                  

                    
2. mark all packets like ECN++


                  

                  
That would be nice but here you actually need AccECN because you want to
have feedback for control packets as well. AccECN is providing this
feedback. AccECN does not change the „use of ECN“; that’s what we have ECN++
for; both thing ideally would be deployed together however. Was that your
questions?


                

                
Cheers


Bob



                

                  
Mirja




                  

                    




On Thu, Jul 12, 2018 at 3:23 AM, Mirja Kühlewind
<mirja.kuehlewind@tik.ee.ethz.ch> wrote:


                    

                      
Hi Yuchung,

the question if you need this „more“ on accuracy really depends on the
use case. If you use DCTCP as today, the ACE counter in the TCP is probably
sufficient and you might not want to pay the additional overhead in your
data center (that why the option is actually optional).

If you however, e.g., have very differently sized packets, then the byte
counter in the option could give you a more accurate signal. Or if you are
also interested in the ECT(1) counter, you need the option. Further the ACE
counter also give your feedback on control packet and the option enables you
to distinguish between CE-amrked payload and control packets, which can also
become important when experimenting with making all packets ECN-capable.

Given accECN is a general feedback mechanism that in fact is designed to
enable new future uses of the ECN signal, we wanted to keep all these option
available while making is still as simple as possible and as flexible as
possible.

Mirja





                      

                        
Am 11.07.2018 um 14:35 schrieb Yuchung Cheng <ycheng@google.com>:

Hi Bob,

Neal and I evaluated the earlier draft. It is well-thought out but
we're concerned about the options. Option is not mandatory but the
lack of it also reduces accuracy. Option runs into space issues w/
SACK and offload issues w/ TSO/GRO. They can be addressed for sure but
aren't easy.

We're curious how much more "accuracy" it buys over current
DCTCP-style ECN. Is there any study to show trade-offs of
full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN?


On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe <ietf@bobbriscoe.net>
wrote:


                        

                          
Michael, tcpm list,

As well as addressing your points, as Mirja has already mentioned
below, we
added a whole new appendix giving the rationale for the bits and
codepoints
that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd
subsection also identifies space for future evolution. It also points
to
where rationale was already given in the body of the draft.

The appendix is in the draft submitted last week, available here:
https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B

We'd be interested to hear whether this allays your concerns.

We have asked to present this in Montreal as well.

Cheers


Bob


On 02/07/18 16:54, Mirja Kühlewind wrote:


                          

                            
Hi Micheal,

I addressed a couple of your comments below.

For the other, bigger comments regarding extensibility, that I did
not yet
address below, we plan to add a new section to the appendix to
explain
extensibility options as previously discussed by mail. We will
probably send
a separate email on that part.

Mirja




                            

                              
Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia -
DE/Stuttgart)
<michael.scharf@nokia.com>:

Hi Mirja,

Thanks a lot for the explanation. I won't follow-up on some of the
editorial suggestions.

Yet, I continue to believe that some formal wording in the document
needs
to change, as explained below.

Thanks

Michael (with no hat on)




                              

                                
-----Original Message-----
From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
Sent: Monday, March 05, 2018 1:54 PM
To: Scharf, Michael (Nokia - DE/Stuttgart)
<michael.scharf@nokia.com>
Cc: draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org
Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn

Hi Micheal,

thanks for your feedback and sorry for my late reply.

Please see inline.



                                

                                  
Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia -
DE/Stuttgart)


                                

                                
<michael.scharf@nokia.com>:


                                

                                  
Hi all,

I have read draft-ietf-tcpm-accurate-ecn-05 (without the
appendix). I


                                

                                
believe this document needs further work before moving forward.


                                

                                  
Please find below my comments marked as [ms]. I have read the


                                

                                
document independent of the review from Gorry. I apologize if there
is
duplication.


                                

                                  
Thanks

Michael (with no hat on)


******************************

* Abstract:

Recently, new TCP mechanisms like Congestion Exposure (ConEx) or
Data


                                

                                
Center TCP


                                

                                  
(DCTCP) need more accurate ECN feedback information whenever
more
than one marking is received in one RTT.

[ms] I don't think this statement is fully backed by RFC 8257. I
suggest to


                                

                                
remove this, or replace it by a more generic statement that more
accurate
information can be useful for several TCP extensions.

I disagree. Both ConEx and DCTCP need more accurate information.
They do
not need the mechanism that is specified in this draft, however,
this is
not
what the sentences is saying.


                              

                              
In my understanding (as a non-native speaker), the use of the word
"need"
is not correct here. DCTCP as specified in RFC 8257 can be
implemented
without any such mechanism.

What would work for me is something of the form "... Data Center TCP
cannot get precise ECN feedback whenever more than one marking is
received
in one RTT“.


                            

                            
This is not correct. DCTP need more than one feedback signal per RTT
and
therefore cannot use RFC3168; instead it implement it’s own feedback
mechanism. However, to avoid confusion such that people could assume
DCTP
would not work without the accECN scheme as specified in this doc, I
rephrased to:

"Recently, proposed
    mechanisms like Congestion Exposure (ConEx <xref
target="RFC7713"/>),
    DCTCP <xref target="RFC8257"/> or L4S <xref
    target="I-D.ietf-tsvwg-l4s-arch"/> need to know when more than
one
    marking is received in one RTT which is
    information that cannot be provided by the feedback scheme as
specified in
    <xref target="RFC3168"/>."




                            

                              

                                

                                  
This document specifies an
experimental scheme to provide more than one feedback signal per
RTT
in the TCP header.  Given TCP header space is scarce, it
overloads
the three existing ECN-related flags in the TCP header and
provides
additional information in a new TCP option.

[ms] This statement needs to be rewritten to correctly reflect
what is


                                

                                
requested from IANA. My understanding is that this experimental
document
asks for allocation of a reserved TCP header flag. This needs to be
called out
prominently, IMHO. In addition, since this is not a standard, the
suggested
experimentation with the main TCP header must IMHO be explicitly
mentioned. I also suggest to have later in a document a section
that
explicitly
explains why it is appropriate to modify the main TCP header in an
experiment.

I don’t know if any requirement that IANA assignment need to be
called
out
in the abstract but we can do that. However, I believe the question
if
this
document should or should not assign the bit is still not
completely
solved, or
is it?


                              

                              
I believe this question will have to be reviewed during WGLC and,
more
importantly, IETF last call. For the moment, my concern is that the
document
correctly describes the IANA allocation.

I would like to see here a statement such as : "Given TCP header
space is
scarce, this specification allocates a reserved header bit and
overloads the
two ECN flags in the TCP header ...“.


                            

                            
A bit lengthy but now:

"Given TCP header space is
    scarce, it allocates a reserved header bit, that was previously
used for
    ECN-Nonce which was recently declared historic, and overloads
the
    two existing ECN flags in the TCP header. Further, additional
    information can be provided in a new TCP option that however is
not
used
    on the TCP SYN."



                            

                              

                                

                                  
* 1.  Introduction

Recently, proposed mechanisms like Congestion Exposure (ConEx
[RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch]
need
more accurate ECN feedback information whenever more than one


                                

                                
marking


                                

                                  
is received in one RTT.

[ms] At least for RFC 8257 seems to be implementable withoit this.
Instead


                                

                                
of stating a "need", it would IMHO make more sense to discuss the
benefits
of the suggested mechanism in this document of its own, independent
of
other proposals. To me, this document should be independent of
other
documents and specifically other experiments. We have to think
about
cases
where not all experiments are successful. Then independent
documents
will
be more future-proof in future.

This is a naming collision… The sentence was meant to say that
these
mechanisms new more accurate ECN feedback than provided today by
RFC3168 but it was not meant to say that these mechanism have to
use the
scheme as specified in this document.

I added the following part sentence:

„Recently, proposed mechanisms like Congestion Exposure (ConEx
[RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need
more
accurate ECN feedback information than provided by the feedback
scheme
as specified in [RFC3168] whenever more than one marking is
received in
one
RTT. This document specifies an alternative feedback scheme that
provides
more accurate information and could be used by these new TCP
extensions.“

Does this help?


                              

                              
See my proposal for the abstract. I continue to disagree with the
term
"need" but I think this can be sorted out by another term.



                              

                                

                                  
If AccECN progresses from experimental to the standards
track, it is intended to be a complete replacement for classic
TCP/
ECN feedback, not a fork in the design of TCP.

[ms] This sentence should be removed, as this is speculation

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

    

    

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

  


--------------39BCA64FFC8DCE4F3C8D56F4--


From nobody Fri Jul 13 23:33:39 2018
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 9AD1F13107B; Fri, 13 Jul 2018 23:33:36 -0700 (PDT)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XFZXUsHIWN_9; Fri, 13 Jul 2018 23:33:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BF4131070; Fri, 13 Jul 2018 23:33:33 -0700 (PDT)
Received: from [192.168.233.109] ([213.143.121.76]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MC8iq-1fn3oQ0hxg-008voL; Sat, 14 Jul 2018 08:32:42 +0200
To: Bob Briscoe , Yuchung Cheng , =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-accurate-ecn@ietf.org" 
References:      <646D10B9-FED7-4E2D-9A9F-0C052F1C908D@tik.ee.ethz.ch>     <64747841-13C7-43DC-AEA9-FA7EFA1FDD32@tik.ee.ethz.ch>    
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Sat, 14 Jul 2018 08:32:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:EkrW2DiI3aYC9zLbAkEk6N1tDqSq73S9sPw1M/N2+mRjGv1h+9E 7IrbNkvCgQP1Z5mc8G/dtnRu5KmjqUrZExG+r8OXrfSg66D8DNsIrvRXeULMlZW/Lb5DpIl CRqImfSEOEcmkR+ex34zeGNtaprsCTfLNRtjmjFC6fLQUcuEeosRqKoH5rWxtJ4s5h7c7SN beHm+r5B5WImQBjKx+P2g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aN0GSqwLCE0=:3wbWDlO8JiSdJgZ0IGzgx5 s3rxuX/GU3tliRtWksf+cDf7Kx6pLXmrqkrGWU9oMmFtfsKIOjxGOlYgzAP0OiMsbwtrm5tRO Z4q41jw1x9s/hvM1IctE0bluDQu+E8vTqY1cUxynRiO3pkIZQ7KIRSPr93A2iYRngEfi3QJT9 3GAnxv4yF+nPE4dSbsV6A9drgBa9b4uj55A0rVY86EIHKggpePahn8M0aBhtIl4lkGlLHYwFF WuNbxK8PBTkiSMMnAoC12i2TKF7IA5ZbL+4O5i1piyJvGAVaTNG8A5Ui7gKkzwx8/ocnGBqg5 uEDJ2laqyTANvSfNZmCS9Zv5Tn9QiMUQqvfqIiaJwA12evJAQ0Sdf94QyPpOtxayGoWsJ6J/K sMv1Cjqk0Krag0LHiNFDobnRwnthsORKu2QlPUJhOlbMjA5r8dYWKYf4uRhvhKEiJBfUPA5+l cTBxsi5gyy5E7/qkU8qZq6ilJvK8ZL5p3S0FwCNI3hb9xuy0S/r7lLY0AYK07jsSoQdy7uyvA ycCZDayAktB2YKG5FEh7EI3ipmm7sL0fIpDIGN1iMCOc3MBeVya5gPIB8+VFbTZF/JxKHdPjI kZ87SE8sRUxGJoS25Xchd1sZ3zQZ8QHPw2Ze4YlfoUPbVUw6zzLU8y3wX5IXI8rcKMtom3y9b h2yKaRe2BSnKXieZZ5MmuSzx5y6Se5rU/rrXqbx41WvIEVQQngXGaII4tX4DV7gV1G5G2Kvv3 EyW11w1Id8YNhI1cQ5sMaNJblFh7ALLlSg7UEucqDkFt+A5VBkpzs13bJVRkvpMMCi6Rq9zG4 Ep3B/KC
Archived-At: 
Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 14 Jul 2018 06:33:37 -0000

Yuchung, Bob,

I really like this discussion!

Two points:


Am 14.07.2018 um 02:52 schrieb Bob Briscoe:
> Yuchung,
> 
> On 13/07/18 21:45, Yuchung Cheng wrote:
>> On Fri, Jul 13, 2018 at 12:42 PM, Mirja Kühlewind
>>   wrote:
>>> Hi Yuchung,
>>>
>>>> Am 13.07.2018 um 15:30 schrieb Yuchung Cheng:
>>>>
>>>> On Fri, Jul 13, 2018 at 11:53 AM, Mirja Kühlewind
>>>>   wrote:
>>>>> Hi Yucheng,
>>>>>
>>>>> please see below.
>>>>>
>>>>>> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng:
>>>>>>
>>>>>> hi --
>>>>>>
>>>>>> I agree:
>>>>>> 1. delayed/streched ACK aren't going away (in fact will be more common)
>>>>>> 2. GRO isn't and should not be a show-stopper
>>>>>> 3. SYN option is running tight
>>>>>> 4. HW opt comes after SW
>>>>>>
>>>>>> I worry:
>>>>>> 1. GRO is a unavoidable issue in deployment (let's not produce an
>>>>>> undeployable RFC). the ACE counter won't work as GRO can pack up to
>>>>>> 64KB/MTU =~ 45 pkts under heavy congestion.
> [BB] I'm really not expert on offload, but I thought GRO collects (or 
> can be made to collect) a set of fields from the headers it strips off?
> 
> If I'm wrong (quite likely), bear in mind the following:
> * you only need the ACE counter (main header) when the AccECN Option is 
> being stripped by a middlebox
> * on those connections that need ACE (cos of middlebox meddling) 
> couldn't GRO be limited to 8 packets, at least while experimenting with 
> AccECN to see if it is useful and gather data?

[RS @ Group] To be pedantic, GRO can coalesce packets, until the ACE 
counter has increased by 7 counts (one less than the previously 
delivered "superpacket"). Under heavy CE marking, this may be as few as 
7 or 8 packets, correct. However, this is when the network expiriences 
congestion. Thus "slowing things down" by reducing the processing speed 
on the client is not an acute problem IMHO - as a slightly delayed 
ACKing would implicitily also reduce the sending speed somewhat.

With many flows, higher RTTs etc, I would expect GRO to be able to 
coalesce many more than just 7 packets.


[...]



 >>>> 3. Leave ACE-count and ACE option optional (i.e. MAY)
 >>>
 >>> I don’t understand this. If both is optional, you don’t have any 
feedback. Or what do you mean by „leave ACE-count optional“?
 >> use-case: We can negotiate DCTCP-style ECN for the internet.
 >>
 >> Then interested parties can progressively experiment on more accurate
 >> "options" (!= TCP-option)


>>>>>> 3. Leave ACE-count and ACE option optional (i.e. MAY)
>>>>> I don’t understand this. If both is optional, you don’t have any feedback. Or what do you mean by „leave ACE-count optional“?
>>>> use-case: We can negotiate DCTCP-style ECN for the internet.
>>>>
>>>> Then interested parties can progressively experiment on more accurate
>>>> "options" (!= TCP-option)
 >>>
 >>> As Appendix A of RFC7560 says I don’t think it is a safe option for 
 >>> the Internet where packet loss more likely then in a full
 >>> ECN-enabled data center.
 >>>
 >>> Again I disagree RFC7560 Appendix A is a big problem based on my
 >>> experience with at times loss-heavy ECN-enabled data-center (Google
 >>> data-center runs very hot and uses a DCTCP-variant).
 >>>
 >>> We can quabble forever w/o data. That's why I asked for some
 >>> (non-simulation) data.

[RS @ Yuchung] I'm afraid I'm with Mirja's comment (other fork of this 
discussing added here), I don't quite follow what you proposing. An 
AccECN-style negotiation, which is used in conjunction with ECN++ (and 
possibly L4S style ECT-1 marking of all packets instead of ECT-0?). But 
how do you envision the feedback scheme? Like the DCTCP-like state 
machine to send change-triggered ACKs, and stretches of ECE and non-ECE 
marked TCP header bits? (Which does not cater well for ACK thinning, ACK 
loss)


However, I think I see where you are coming from. Let me try to 
summarize what I assume here:

With DCTCP-style feedback in a datacenter, and some level of ACK losses, 
the sender-side estimation of the CE levels with with equal probability 
over- and under-estimated the marking levels during one specific RTT. If 
the sender underestimated congestion, the network will provide a higher 
marking level during the next RTT, and thereby correct the false 
estimate. On overestimation, the flow would only have reduced its 
sending rate more than necessary, and regular CA across all flows of 
that bottleneck link will readily make use of that free bandwidth. All 
of that happening in datacenter-typical RTTs of a few dozend nanoseconds 
to a few microseconds... So any deviation will only persist for a very 
short period of time, while most flows have very similar RTTs.

Now, the problem space AccECN tries to address includes the public 
internet, with RTTs over a bottleneck, that vary many orders of 
magnitude potentially. Thus the goal should be to avoid the over- and 
more so, the under-estimation of congestion as much as possible already 
within the first RTT.

Or summarized differently, in a datacenter, small errors in congestion 
estimation have a predictable, very short life-time until they will be 
corrected. On the public internet, it is a better approach to try and 
avoid an estimator error on congestion as good as possible, as these 
errors would result in more unfairness among flows.

I hope that is a fair summary, but please expand on how/what your 
feedback scheme would encompass.

Best regards,
   Richard


From nobody Sat Jul 14 04:35:28 2018
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 2CB05130F2D; Sat, 14 Jul 2018 04:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 KvaRQL3vgjwn; Sat, 14 Jul 2018 04:35:23 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C069130E09; Sat, 14 Jul 2018 04:35:22 -0700 (PDT)
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 14 Jul 2018 12:35:18 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sat, 14 Jul 2018 12:35:19 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Sat, 14 Jul 2018 12:35:19 +0100
From: 
To: 
CC: 
Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis
Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQAGiU/gBBgqcVADkYxTEA==
Date: Sat, 14 Jul 2018 11:35:18 +0000
Message-ID: <260cb4ded4a8435ca22bb12d0831e26f@rew09926dag03b.domain1.systemhost.net>
References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> <8b63f3c2af9b4b1d93ec1ad73422be5b@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <8b63f3c2af9b4b1d93ec1ad73422be5b@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.202.242]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] FW: WG Last Call for draft-ietf-mptcp-rfc6824bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 14 Jul 2018 11:35:26 -0000

In case TCPM people missed it, the bis document for the Multipath TCP proto=
col is in WG last call - all comments would be very much appreciated.
https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-11=20

Thank-you!
Phil & Yoshi


-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil=
ip.eardley@bt.com
Sent: 26 June 2018 03:33
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

Hi,
Just a reminder about the WGLC for the protocol bis. Please send comments, =
Thanks!
Phil & Yoshi

-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil=
ip.eardley@bt.com
Sent: 05 June 2018 12:21
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

As a reminder, this document Obsoletes: 6824 (if approved) and its Intended=
 status is Standards Track.

As well as suggested changes or edits, positive review comments ("It's read=
y") are also very valuable.=20

-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil=
ip.eardley@bt.com
Sent: 05 June 2018 09:14
To: multipathtcp@ietf.org
Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com=
ments by the end of June.=20

Please note there are three IPR disclosures (we're working on getting them =
added to the rfc6824bis page):=20

* two are inherited from RFC6824  https://datatracker.ietf.org/ipr/search/?=
submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed   =20
* one is inherited from draft-paasch-mptcp-syncookies (which got include in=
 rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20

Thanks,
Phil & Yoshi
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

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

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


From nobody Sat Jul 14 09:00:28 2018
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 E549B1310DE for ; Sat, 14 Jul 2018 09:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 y9nbsTXwG5_c for ; Sat, 14 Jul 2018 09:00:17 -0700 (PDT)
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 1193C131115 for ; Sat, 14 Jul 2018 09:00:17 -0700 (PDT)
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=oMi/j6aMNrOTH73kEEHbOTlb9ykiGhps/4VwAb/xV60=; b=ir8vSxE48GlIg09miU37qCZOv dAxCJ5cgdBu18vsTuQ+Ax8p0+JsKWFkmxxOzXs6HnBYwxjl4xEh+/FPJGWikqI0rwgrFKXL+2hulY 45U2Wdc5NOfcGYPVuTnufKIduIkmrrPGmx76lSnsJX8v75HbzmV7AHYaRTDvBqWNOXgRCspTfTJo5 eon7EJpagNVX7DFxW44jh+03lRBXE8+JCIxYB5UPazwARK/GgnULZNO1/GoYW15XZUV2Me9q8445Q O/zjTO4m0ALnXY90cUzEkGEZnbXEGdrfokuy67UUjE1DyII0gvFf1xbF6voCGQ0LrqOdRGwwZH0ir Q3jhgYk2g==;
Received: from [37.205.56.236] (port=46638 helo=[10.210.68.138]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1feMxy-0007Vf-9W; Sat, 14 Jul 2018 17:00:14 +0100
To: gorry@erg.abdn.ac.uk, =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Cc: tcpm@ietf.org
References: <5A128116.9080609@erg.abdn.ac.uk> <0C9DF549-632F-4FAC-A561-3C3679552C6E@tik.ee.ethz.ch> 
From: Bob Briscoe 
Message-ID: <6e96aa71-afc8-4006-819b-9d8466d1d2e1@bobbriscoe.net>
Date: Sat, 14 Jul 2018 17:00:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B768E4692BE5D07C0CE38CE3"
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] Detailed review of AccECN rev -04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 14 Jul 2018 16:00:27 -0000

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

Gorry, Mirja,


While reviewing conversations on the list for including in our slides in 
Montreal, I thought again about the conversation below from March...

On 13/03/18 16:49, Gorry Fairhurst wrote:
>>> A future standards-track document based on the AccECN experimental 
>>> RFC could update RFC3168.
>>
>> No, I don’t it would update RFC3168. It does not change anything in 
>> that RFC. It also specified an additional meachismen (which we hope 
>> will deploy as the default). The only thing we change is the use of 
>> the NS bit in the SYN but that was previously unused; with or without 
>> ECN Nonce.
>>
> OK that makes sense. 

Although nothing in AccECN updates RFC3168, the goal was not to fork the 
wire protocol, but instead to eventually provide a generic wire protocol 
that could either feed back to a host behaving like RFC3168 (one 
response per RTT) or behaving with an updated behaviour (e.g. L4S).

So, some time in the future we might want to work out whether / how to 
update RFC3168 with a new standards track feedback protocol.



Bob

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


--------------B768E4692BE5D07C0CE38CE3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Gorry, Mirja,

    

    

    While reviewing conversations on the list for including in our
    slides in Montreal, I thought again about the conversation below
    from March...

    

    
On 13/03/18 16:49, Gorry Fairhurst
      wrote:

    

    

      

        
A future
          standards-track document based on the AccECN experimental RFC
          could update RFC3168.
          

        

        

        No, I don’t it would update RFC3168. It does not change anything
        in that RFC. It also specified an additional meachismen (which
        we hope will deploy as the default). The only thing we change is
        the use of the NS bit in the SYN but that was previously unused;
        with or without ECN Nonce.
        

        

      

      OK that makes sense.
    

    

    Although nothing in AccECN updates RFC3168, the goal was not to fork
    the wire protocol, but instead to eventually provide a generic wire
    protocol that could either feed back to a host behaving like RFC3168
    (one response per RTT) or behaving with an updated behaviour (e.g.
    L4S).

    

    So, some time in the future we might want to work out whether / how
    to update RFC3168 with a new standards track feedback protocol.

    

    

    

    Bob

    

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

  


--------------B768E4692BE5D07C0CE38CE3--


From nobody Sat Jul 14 14:47:35 2018
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 CA118130ED8; Sat, 14 Jul 2018 14:47:32 -0700 (PDT)
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, HTML_MESSAGE=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 dgzJTGRvQWTx; Sat, 14 Jul 2018 14:47:30 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A265130DC5; Sat, 14 Jul 2018 14:47:29 -0700 (PDT)
Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0FEB22783BC; Sun, 15 Jul 2018 06:47:28 +0900 (JST)
Received: by mail-it0-f53.google.com with SMTP id 198-v6so7853299ite.4; Sat, 14 Jul 2018 14:47:27 -0700 (PDT)
X-Gm-Message-State: AOUpUlGfJa2cWWBbbnhM6OlKVbzpwzDO0SAkonk5geWq66zehlw+wuwR T4wbRhzgpmCE8QCh9qxtTfDpUkR22G+BR3KbsWM=
X-Google-Smtp-Source: AAOMgpdcaSqy/LCD/mgAA4OeNbGfezStOnNEOd8KLN7/trB954h3hE9sd5yaKwsy9zJMnEuPbtbHQ0WqngfoUXaWsOc=
X-Received: by 2002:a02:2505:: with SMTP id g5-v6mr10086164jag.130.1531604846387;  Sat, 14 Jul 2018 14:47:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Sat, 14 Jul 2018 14:47:26 -0700 (PDT)
From: Yoshifumi Nishida 
Date: Sat, 14 Jul 2018 14:47:26 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "tcpm@ietf.org" 
Cc: "tcpm-chairs@ietf.org" , carlesgo@entel.upc.edu
Content-Type: multipart/alternative; boundary="000000000000ce2cae0570fc8ad0"
Archived-At: 
Subject: [tcpm] slides for tcpm meeting on Tuesday (7/17)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 14 Jul 2018 21:47:33 -0000

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

Hello presenters for the meeting,

Please make sure to send your slides by ** Monday (7/16) morning ** to
chairs. We appreciate your cooperation!

BTW, you can find the current agenda at:
https://tools.ietf.org/wg/tcpm/agenda

Thanks,
--
tcpm co-chairs

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


Hello presenters for the me=
eting,

Please=C2=A0make sure to send your=C2=A0slides=
=C2=A0by ** Monday (7/16) morning ** to chairs.=C2=A0We appreciate your cooperation!

BTW, you can find the current agenda at:=C2=A0https://tools.ietf.org/wg/tcpm/agenda

Thanks,
--
=
tcpm co-chairs


--000000000000ce2cae0570fc8ad0--


From nobody Sun Jul 15 07:32:05 2018
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 68E68130ECF for ; Sun, 15 Jul 2018 07:32:04 -0700 (PDT)
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] 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 MUnwohUp8GDH for ; Sun, 15 Jul 2018 07:32:02 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 09572130ECD for ; Sun, 15 Jul 2018 07:32:02 -0700 (PDT)
Received: from G-MacBook.local (unknown [72.142.123.242]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D4A641B001CF; Sun, 15 Jul 2018 15:31:53 +0100 (BST)
Message-ID: <5B4B5AD8.2060209@erg.abdn.ac.uk>
Date: Sun, 15 Jul 2018 10:31:52 -0400
From: G Fairhurst 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bob Briscoe 
CC: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , tcpm@ietf.org
References: <5A128116.9080609@erg.abdn.ac.uk> <0C9DF549-632F-4FAC-A561-3C3679552C6E@tik.ee.ethz.ch>  <6e96aa71-afc8-4006-819b-9d8466d1d2e1@bobbriscoe.net>
In-Reply-To: <6e96aa71-afc8-4006-819b-9d8466d1d2e1@bobbriscoe.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [tcpm] Detailed review of AccECN rev -04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 15 Jul 2018 14:32:05 -0000

OK, it makes sense and I agree. I think that's a key difference with the 
ABE ID. That does change RFC3168, by specifying a different  mechanism 
to respond to feedback, which we expect will deploy as the default for 
ECT(0).

Gorry

On 14/07/2018, 12:00, Bob Briscoe wrote:
> Gorry, Mirja,
>
>
> While reviewing conversations on the list for including in our slides 
> in Montreal, I thought again about the conversation below from March...
>
> On 13/03/18 16:49, Gorry Fairhurst wrote:
>>>> A future standards-track document based on the AccECN experimental 
>>>> RFC could update RFC3168.
>>>
>>> No, I don’t it would update RFC3168. It does not change anything in 
>>> that RFC. It also specified an additional meachismen (which we hope 
>>> will deploy as the default). The only thing we change is the use of 
>>> the NS bit in the SYN but that was previously unused; with or 
>>> without ECN Nonce.
>>>
>> OK that makes sense. 
>
> Although nothing in AccECN updates RFC3168, the goal was not to fork 
> the wire protocol, but instead to eventually provide a generic wire 
> protocol that could either feed back to a host behaving like RFC3168 
> (one response per RTT) or behaving with an updated behaviour (e.g. L4S).
>
> So, some time in the future we might want to work out whether / how to 
> update RFC3168 with a new standards track feedback protocol.
>
>
>
> Bob
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/


From nobody Sun Jul 15 13:19:36 2018
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 C0FB9130E48; Sun, 15 Jul 2018 13:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 Vm9Kok0Tm5bi; Sun, 15 Jul 2018 13:19:28 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9A1130DF4; Sun, 15 Jul 2018 13:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/w/MqzrcpuTmIZ5rG6Dowci7u5hJKtNc1J4sSLlOZkE=; b=byC97/r2jFFyVfMl/CgxpGFGmiHCo15O2gY/hAgdDaN38xptSXcX/1hvAht09vLzCfuDw3qONiIBRC26mpb/LDOI+bbPM/tzmEjxDboLPrTIxAXAWSFwdfpJd/5QtYDsnsvqWOhEwpNUibMW9RVbPXBUa9W3lv5mBEEpCmxyp84=
Received: from AM2PR07MB0867.eurprd07.prod.outlook.com (10.161.71.153) by AM2PR07MB0788.eurprd07.prod.outlook.com (10.161.71.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.13; Sun, 15 Jul 2018 20:19:23 +0000
Received: from AM2PR07MB0867.eurprd07.prod.outlook.com ([fe80::2408:bde2:6996:189d]) by AM2PR07MB0867.eurprd07.prod.outlook.com ([fe80::2408:bde2:6996:189d%10]) with mapi id 15.20.0973.013; Sun, 15 Jul 2018 20:19:22 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe 
CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdNsZwbKZl7dQfJhQeSI1pXOpUN55hIGf9OAAUAqXJAWJtFgAAHJBo4AAM3W/WA=
Date: Sun, 15 Jul 2018 20:19:22 +0000
Message-ID: 
References:  <44FDECF5-A031-4343-BA1A-AE0D9C2C078C@tik.ee.ethz.ch>   
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [92.203.139.253]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0788; 6:lQOghFwSOjDPCo71GWCmx8Kjd4zar4J+obrloIx4my+kF6k23oM1w/ygoY+DMXa1w9ZzNp/fYiiDG8lK8mut6GxqJgZC6+0nIvSaNcygAXccypVSZcQpmrTGiCtmgUpXJGtjkztuIhUKKw03006Zh8gAR5eA9UpgS4YdY//Wqk9FewGPiBiiTy2aMp6Scsoa9XhiMegXUekiOzjaa84up6TkvDjtZACmcRUTEsTkuR2CZ+xnxs2AztoshpAQd1qLl5ErjssTsbhTouI0j1v7BfMCmLeuW4vaikx7Xvp90Pkf32qp0Z5JJHwMZBl3+KdEJBbtladgHwa8+BU06c/SqLOOQRJjydSzNGMu+5xdHuo9InfoE9e1XqYYgWTU97j4l5yjmPiSQT3/WqI/6PwFqIT3Eea46tNGMIENsewl13je2Lvol/cpoDcQQOXwhiQGp365RwAAOOFQFKWU+6pxOg==; 5:zCOUrAdNLX5MJnpyFwJGTb/76fgNAjyuarQAAmeEdN3MDmtOej5oxOOBucOoHGl94mj2qUdMZH8nzhUnPXPXj+zKtNoL49FmsF/8Pza7gIj12DZuXSR1SRh3jg5xTUXUjisIkhODSh9XpmB7/kZ9qjgKKhHr/5weVlV3OlO3qB4=; 7:GxbcqmXs6YR3VrUSvTIGIqfGnGprozowrMw0sKFsLr/fRf1z6KTI002YO1rqYJtCijrITOfJdPDtCbQn0P9AZb4BSITsBqhXLrzuFIvhXfeY3ZrBf/7oNHT/DojSh6LyNIQ2OmyOU8GLXxKXv+iWcBOVo+oSrqaE8X76WhYq1VFVcsNHEp5cXohj+kSW5KuuY6N2ClY7xbE5vIRwjxrGxVhWcVNx2RwD4hvlQ+Xmn0r6sSPk3f/WmdFIP9eo3LgS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: cad116e4-9012-4532-a59a-08d5ea9040de
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(223705240517415)(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:AM2PR07MB0788; 
x-ms-traffictypediagnostic: AM2PR07MB0788:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(223705240517415)(82608151540597)(109105607167333)(788757137089)(100405760836317)(1591387915157);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231311)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM2PR07MB0788; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0788; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(346002)(376002)(366004)(199004)(189003)(13464003)(78094002)(53754006)(51444003)(52314003)(68736007)(53946003)(53546011)(6436002)(8936002)(81166006)(99286004)(105586002)(7696005)(106356001)(81156014)(76176011)(6506007)(66066001)(74316002)(476003)(5250100002)(2906002)(16200700003)(305945005)(25786009)(11346002)(8676002)(446003)(7736002)(93886005)(4326008)(26005)(229853002)(86362001)(54906003)(14454004)(2900100001)(53376002)(6916009)(256004)(14444005)(6246003)(966005)(33656002)(561944003)(6306002)(102836004)(9686003)(97736004)(478600001)(6116002)(55016002)(3846002)(316002)(186003)(5660300001)(53936002)(486006)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0788; H:AM2PR07MB0867.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: G6VT89LQCE6cBNj3UEdyb7b9R1kwwladQ3Hw77czgxzOUXnJqpvj5Np6HWcADcZJR8pF5iJGAs/JItEf0XkY3SeRQFeLLSjIs3yECp3rF8rgmAKGnyLa4W0i3aJnwS8hAFJE/h44PH92bQPLzeZDVswgWPjU/L/ajLxyIu7vUi/iH57SLR0s+ri1zZ6UA6Mg2T5cAs3V2MdsF4Z/aHzeu5rNdyBD16K4VaPITsPX/cVlDpkvv4YGiSEovlwxB0yLqhY07zvMjKkHHVPPYmzaEWNXLJfhgdrAOJCBK9+IM7z4cbqp/F7OiUOKJQspIbMP0Cq6je433ywFAQm93vYxkBTbXWRojuCJKZ8CYw1QjPpWHd3sB0XBFEJX9WWUDDymnWzabu8E3JqFX1XGrluF+Q==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cad116e4-9012-4532-a59a-08d5ea9040de
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2018 20:19:22.5355 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0788
Archived-At: 
Subject: Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 15 Jul 2018 20:19:35 -0000

TWlyamEsIEJvYiwNCg0KVGhhbmtzIGEgbG90IGZvciB0aGUgcmVwbGllcy4gSSBoYXZlIHJlYWQg
dGhlIGxhdGVzdCB2ZXJzaW9uIC0wNy4gSSBhZ3JlZSB0aGF0IC0wNyBpcyBpbiBhIGJldHRlciBz
aGFwZS4gVG8gbWUsIEFwcGVuZGl4IEIgY29udGFpbnMgdXNlZnVsIGluZm9ybWF0aW9uLg0KDQpJ
J2xsIG9wZW4gYSBuZXcgdGhyZWFkIGZvciBzb21lIGZ1cnRoZXIgcmVtYXJrcyBvbiAtMDcuDQoN
CkJlc3QgcmVnYXJkcw0KDQpNaWNoYWVsIChjaGFpciBoYXQgb2ZmKQ0KDQoNCj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJy
aXNjb2UubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTEsIDIwMTggODowMSBQTQ0KPiBU
bzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJm
QG5va2lhLmNvbT4NCj4gQ2M6IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlr
LmVlLmV0aHouY2g+OyBkcmFmdC1pZXRmLXRjcG0tDQo+IGFjY3VyYXRlLWVjbkBpZXRmLm9yZzsg
dGNwbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIENvbW1lbnRzIG9uIGRyYWZ0LWll
dGYtdGNwbS1hY2N1cmF0ZS1lY24NCj4gDQo+IE1pY2hhZWwsIHRjcG0gbGlzdCwNCj4gDQo+IEFz
IHdlbGwgYXMgYWRkcmVzc2luZyB5b3VyIHBvaW50cywgYXMgTWlyamEgaGFzIGFscmVhZHkgbWVu
dGlvbmVkIGJlbG93LA0KPiB3ZSBhZGRlZCBhIHdob2xlIG5ldyBhcHBlbmRpeCBnaXZpbmcgdGhl
IHJhdGlvbmFsZSBmb3IgdGhlIGJpdHMgYW5kDQo+IGNvZGVwb2ludHMgdGhhdCBBY2NFQ04gaGFz
IHByb3Bvc2VkIHRvIHVzZSBvbiAxKSB0aGUgU1lOIGFuZCAyKSBTWU4vQUNLLg0KPiBBIDNyZCBz
dWJzZWN0aW9uIGFsc28gaWRlbnRpZmllcyBzcGFjZSBmb3IgZnV0dXJlIGV2b2x1dGlvbi4gSXQg
YWxzbw0KPiBwb2ludHMgdG8gd2hlcmUgcmF0aW9uYWxlIHdhcyBhbHJlYWR5IGdpdmVuIGluIHRo
ZSBib2R5IG9mIHRoZSBkcmFmdC4NCj4gDQo+IFRoZSBhcHBlbmRpeCBpcyBpbiB0aGUgZHJhZnQg
c3VibWl0dGVkIGxhc3Qgd2VlaywgYXZhaWxhYmxlIGhlcmU6DQo+IGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I2FwcGVuZGl4LUINCj4g
DQo+IFdlJ2QgYmUgaW50ZXJlc3RlZCB0byBoZWFyIHdoZXRoZXIgdGhpcyBhbGxheXMgeW91ciBj
b25jZXJucy4NCj4gDQo+IFdlIGhhdmUgYXNrZWQgdG8gcHJlc2VudCB0aGlzIGluIE1vbnRyZWFs
IGFzIHdlbGwuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IA0KPiBCb2INCj4gDQo+IE9uIDAyLzA3LzE4
IDE2OjU0LCBNaXJqYSBLw7xobGV3aW5kIHdyb3RlOg0KPiA+IEhpIE1pY2hlYWwsDQo+ID4NCj4g
PiBJIGFkZHJlc3NlZCBhIGNvdXBsZSBvZiB5b3VyIGNvbW1lbnRzIGJlbG93Lg0KPiA+DQo+ID4g
Rm9yIHRoZSBvdGhlciwgYmlnZ2VyIGNvbW1lbnRzIHJlZ2FyZGluZyBleHRlbnNpYmlsaXR5LCB0
aGF0IEkgZGlkIG5vdCB5ZXQNCj4gYWRkcmVzcyBiZWxvdywgd2UgcGxhbiB0byBhZGQgYSBuZXcg
c2VjdGlvbiB0byB0aGUgYXBwZW5kaXggdG8gZXhwbGFpbg0KPiBleHRlbnNpYmlsaXR5IG9wdGlv
bnMgYXMgcHJldmlvdXNseSBkaXNjdXNzZWQgYnkgbWFpbC4gV2Ugd2lsbCBwcm9iYWJseSBzZW5k
IGENCj4gc2VwYXJhdGUgZW1haWwgb24gdGhhdCBwYXJ0Lg0KPiA+DQo+ID4gTWlyamENCj4gPg0K
PiA+DQo+ID4+IEFtIDEyLjAzLjIwMTggdW0gMDE6NTkgc2NocmllYiBTY2hhcmYsIE1pY2hhZWwg
KE5va2lhIC0gREUvU3R1dHRnYXJ0KQ0KPiA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPjoNCj4g
Pj4NCj4gPj4gSGkgTWlyamEsDQo+ID4+DQo+ID4+IFRoYW5rcyBhIGxvdCBmb3IgdGhlIGV4cGxh
bmF0aW9uLiBJIHdvbid0IGZvbGxvdy11cCBvbiBzb21lIG9mIHRoZQ0KPiBlZGl0b3JpYWwgc3Vn
Z2VzdGlvbnMuDQo+ID4+DQo+ID4+IFlldCwgSSBjb250aW51ZSB0byBiZWxpZXZlIHRoYXQgc29t
ZSBmb3JtYWwgd29yZGluZyBpbiB0aGUgZG9jdW1lbnQNCj4gbmVlZHMgdG8gY2hhbmdlLCBhcyBl
eHBsYWluZWQgYmVsb3cuDQo+ID4+DQo+ID4+IFRoYW5rcw0KPiA+Pg0KPiA+PiBNaWNoYWVsICh3
aXRoIG5vIGhhdCBvbikNCj4gPj4NCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+ID4+PiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86bWlyamEua3VlaGxld2lu
ZEB0aWsuZWUuZXRoei5jaF0NCj4gPj4+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIwMTggMTo1
NCBQTQ0KPiA+Pj4gVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxt
aWNoYWVsLnNjaGFyZkBub2tpYS5jb20+DQo+ID4+PiBDYzogZHJhZnQtaWV0Zi10Y3BtLWFjY3Vy
YXRlLWVjbkBpZXRmLm9yZzsgdGNwbUBpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUmU6IENvbW1l
bnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24NCj4gPj4+DQo+ID4+PiBIaSBNaWNo
ZWFsLA0KPiA+Pj4NCj4gPj4+IHRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayBhbmQgc29ycnkgZm9y
IG15IGxhdGUgcmVwbHkuDQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4+Pg0K
PiA+Pj4+IEFtIDAzLjEyLjIwMTcgdW0gMjA6MTcgc2NocmllYiBTY2hhcmYsIE1pY2hhZWwgKE5v
a2lhIC0gREUvU3R1dHRnYXJ0KQ0KPiA+Pj4gPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT46DQo+
ID4+Pj4gSGkgYWxsLA0KPiA+Pj4+DQo+ID4+Pj4gSSBoYXZlIHJlYWQgZHJhZnQtaWV0Zi10Y3Bt
LWFjY3VyYXRlLWVjbi0wNSAod2l0aG91dCB0aGUgYXBwZW5kaXgpLiBJDQo+ID4+PiBiZWxpZXZl
IHRoaXMgZG9jdW1lbnQgbmVlZHMgZnVydGhlciB3b3JrIGJlZm9yZSBtb3ZpbmcgZm9yd2FyZC4N
Cj4gPj4+PiBQbGVhc2UgZmluZCBiZWxvdyBteSBjb21tZW50cyBtYXJrZWQgYXMgW21zXS4gSSBo
YXZlIHJlYWQgdGhlDQo+ID4+PiBkb2N1bWVudCBpbmRlcGVuZGVudCBvZiB0aGUgcmV2aWV3IGZy
b20gR29ycnkuIEkgYXBvbG9naXplIGlmIHRoZXJlIGlzDQo+ID4+PiBkdXBsaWNhdGlvbi4NCj4g
Pj4+PiBUaGFua3MNCj4gPj4+Pg0KPiA+Pj4+IE1pY2hhZWwgKHdpdGggbm8gaGF0IG9uKQ0KPiA+
Pj4+DQo+ID4+Pj4NCj4gPj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4+
Pg0KPiA+Pj4+ICogQWJzdHJhY3Q6DQo+ID4+Pj4NCj4gPj4+PiAgICBSZWNlbnRseSwgbmV3IFRD
UCBtZWNoYW5pc21zIGxpa2UgQ29uZ2VzdGlvbiBFeHBvc3VyZSAoQ29uRXgpIG9yDQo+IERhdGEN
Cj4gPj4+IENlbnRlciBUQ1ANCj4gPj4+PiAgICAoRENUQ1ApIG5lZWQgbW9yZSBhY2N1cmF0ZSBF
Q04gZmVlZGJhY2sgaW5mb3JtYXRpb24gd2hlbmV2ZXINCj4gbW9yZQ0KPiA+Pj4+ICAgIHRoYW4g
b25lIG1hcmtpbmcgaXMgcmVjZWl2ZWQgaW4gb25lIFJUVC4NCj4gPj4+Pg0KPiA+Pj4+IFttc10g
SSBkb24ndCB0aGluayB0aGlzIHN0YXRlbWVudCBpcyBmdWxseSBiYWNrZWQgYnkgUkZDIDgyNTcu
IEkgc3VnZ2VzdA0KPiB0bw0KPiA+Pj4gcmVtb3ZlIHRoaXMsIG9yIHJlcGxhY2UgaXQgYnkgYSBt
b3JlIGdlbmVyaWMgc3RhdGVtZW50IHRoYXQgbW9yZQ0KPiBhY2N1cmF0ZQ0KPiA+Pj4gaW5mb3Jt
YXRpb24gY2FuIGJlIHVzZWZ1bCBmb3Igc2V2ZXJhbCBUQ1AgZXh0ZW5zaW9ucy4NCj4gPj4+DQo+
ID4+PiBJIGRpc2FncmVlLiBCb3RoIENvbkV4IGFuZCBEQ1RDUCBuZWVkIG1vcmUgYWNjdXJhdGUg
aW5mb3JtYXRpb24uIFRoZXkNCj4gZG8NCj4gPj4+IG5vdCBuZWVkIHRoZSBtZWNoYW5pc20gdGhh
dCBpcyBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCwgaG93ZXZlciwgdGhpcyBpcw0KPiBub3QNCj4g
Pj4+IHdoYXQgdGhlIHNlbnRlbmNlcyBpcyBzYXlpbmcuDQo+ID4+IEluIG15IHVuZGVyc3RhbmRp
bmcgKGFzIGEgbm9uLW5hdGl2ZSBzcGVha2VyKSwgdGhlIHVzZSBvZiB0aGUgd29yZA0KPiAibmVl
ZCIgaXMgbm90IGNvcnJlY3QgaGVyZS4gRENUQ1AgYXMgc3BlY2lmaWVkIGluIFJGQyA4MjU3IGNh
biBiZQ0KPiBpbXBsZW1lbnRlZCB3aXRob3V0IGFueSBzdWNoIG1lY2hhbmlzbS4NCj4gPj4NCj4g
Pj4gV2hhdCB3b3VsZCB3b3JrIGZvciBtZSBpcyBzb21ldGhpbmcgb2YgdGhlIGZvcm0gIi4uLiBE
YXRhIENlbnRlciBUQ1ANCj4gY2Fubm90IGdldCBwcmVjaXNlIEVDTiBmZWVkYmFjayB3aGVuZXZl
ciBtb3JlIHRoYW4gb25lIG1hcmtpbmcgaXMNCj4gcmVjZWl2ZWQgaW4gb25lIFJUVOKAnC4NCj4g
PiBUaGlzIGlzIG5vdCBjb3JyZWN0LiBEQ1RQIG5lZWQgbW9yZSB0aGFuIG9uZSBmZWVkYmFjayBz
aWduYWwgcGVyIFJUVCBhbmQNCj4gdGhlcmVmb3JlIGNhbm5vdCB1c2UgUkZDMzE2ODsgaW5zdGVh
ZCBpdCBpbXBsZW1lbnQgaXTigJlzIG93biBmZWVkYmFjaw0KPiBtZWNoYW5pc20uIEhvd2V2ZXIs
IHRvIGF2b2lkIGNvbmZ1c2lvbiBzdWNoIHRoYXQgcGVvcGxlIGNvdWxkIGFzc3VtZQ0KPiBEQ1RQ
IHdvdWxkIG5vdCB3b3JrIHdpdGhvdXQgdGhlIGFjY0VDTiBzY2hlbWUgYXMgc3BlY2lmaWVkIGlu
IHRoaXMgZG9jLCBJDQo+IHJlcGhyYXNlZCB0bzoNCj4gPg0KPiA+ICJSZWNlbnRseSwgcHJvcG9z
ZWQNCj4gPiAgICAgICAgbWVjaGFuaXNtcyBsaWtlIENvbmdlc3Rpb24gRXhwb3N1cmUgKENvbkV4
IDx4cmVmDQo+IHRhcmdldD0iUkZDNzcxMyIvPiksDQo+ID4gICAgICAgIERDVENQIDx4cmVmIHRh
cmdldD0iUkZDODI1NyIvPiBvciBMNFMgPHhyZWYNCj4gPiAgICAgICAgdGFyZ2V0PSJJLUQuaWV0
Zi10c3Z3Zy1sNHMtYXJjaCIvPiBuZWVkIHRvIGtub3cgd2hlbiBtb3JlIHRoYW4gb25lDQo+ID4g
ICAgICAgIG1hcmtpbmcgaXMgcmVjZWl2ZWQgaW4gb25lIFJUVCB3aGljaCBpcw0KPiA+ICAgICAg
ICBpbmZvcm1hdGlvbiB0aGF0IGNhbm5vdCBiZSBwcm92aWRlZCBieSB0aGUgZmVlZGJhY2sgc2No
ZW1lIGFzDQo+IHNwZWNpZmllZCBpbg0KPiA+ICAgICAgICA8eHJlZiB0YXJnZXQ9IlJGQzMxNjgi
Lz4uIg0KPiA+DQo+ID4NCj4gPj4+PiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbg0KPiA+
Pj4+ICAgIGV4cGVyaW1lbnRhbCBzY2hlbWUgdG8gcHJvdmlkZSBtb3JlIHRoYW4gb25lIGZlZWRi
YWNrIHNpZ25hbCBwZXINCj4gUlRUDQo+ID4+Pj4gICAgaW4gdGhlIFRDUCBoZWFkZXIuICBHaXZl
biBUQ1AgaGVhZGVyIHNwYWNlIGlzIHNjYXJjZSwgaXQgb3ZlcmxvYWRzDQo+ID4+Pj4gICAgdGhl
IHRocmVlIGV4aXN0aW5nIEVDTi1yZWxhdGVkIGZsYWdzIGluIHRoZSBUQ1AgaGVhZGVyIGFuZCBw
cm92aWRlcw0KPiA+Pj4+ICAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gYSBuZXcgVENQIG9w
dGlvbi4NCj4gPj4+Pg0KPiA+Pj4+IFttc10gVGhpcyBzdGF0ZW1lbnQgbmVlZHMgdG8gYmUgcmV3
cml0dGVuIHRvIGNvcnJlY3RseSByZWZsZWN0IHdoYXQgaXMNCj4gPj4+IHJlcXVlc3RlZCBmcm9t
IElBTkEuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIGV4cGVyaW1lbnRhbA0KPiBkb2N1
bWVudA0KPiA+Pj4gYXNrcyBmb3IgYWxsb2NhdGlvbiBvZiBhIHJlc2VydmVkIFRDUCBoZWFkZXIg
ZmxhZy4gVGhpcyBuZWVkcyB0byBiZSBjYWxsZWQNCj4gb3V0DQo+ID4+PiBwcm9taW5lbnRseSwg
SU1ITy4gSW4gYWRkaXRpb24sIHNpbmNlIHRoaXMgaXMgbm90IGEgc3RhbmRhcmQsIHRoZQ0KPiBz
dWdnZXN0ZWQNCj4gPj4+IGV4cGVyaW1lbnRhdGlvbiB3aXRoIHRoZSBtYWluIFRDUCBoZWFkZXIg
bXVzdCBJTUhPIGJlIGV4cGxpY2l0bHkNCj4gPj4+IG1lbnRpb25lZC4gSSBhbHNvIHN1Z2dlc3Qg
dG8gaGF2ZSBsYXRlciBpbiBhIGRvY3VtZW50IGEgc2VjdGlvbiB0aGF0DQo+IGV4cGxpY2l0bHkN
Cj4gPj4+IGV4cGxhaW5zIHdoeSBpdCBpcyBhcHByb3ByaWF0ZSB0byBtb2RpZnkgdGhlIG1haW4g
VENQIGhlYWRlciBpbiBhbg0KPiA+Pj4gZXhwZXJpbWVudC4NCj4gPj4+DQo+ID4+PiBJIGRvbuKA
mXQga25vdyBpZiBhbnkgcmVxdWlyZW1lbnQgdGhhdCBJQU5BIGFzc2lnbm1lbnQgbmVlZCB0byBi
ZSBjYWxsZWQNCj4gb3V0DQo+ID4+PiBpbiB0aGUgYWJzdHJhY3QgYnV0IHdlIGNhbiBkbyB0aGF0
LiBIb3dldmVyLCBJIGJlbGlldmUgdGhlIHF1ZXN0aW9uIGlmIHRoaXMNCj4gPj4+IGRvY3VtZW50
IHNob3VsZCBvciBzaG91bGQgbm90IGFzc2lnbiB0aGUgYml0IGlzIHN0aWxsIG5vdCBjb21wbGV0
ZWx5DQo+IHNvbHZlZCwgb3INCj4gPj4+IGlzIGl0Pw0KPiA+PiBJIGJlbGlldmUgdGhpcyBxdWVz
dGlvbiB3aWxsIGhhdmUgdG8gYmUgcmV2aWV3ZWQgZHVyaW5nIFdHTEMgYW5kLCBtb3JlDQo+IGlt
cG9ydGFudGx5LCBJRVRGIGxhc3QgY2FsbC4gRm9yIHRoZSBtb21lbnQsIG15IGNvbmNlcm4gaXMg
dGhhdCB0aGUgZG9jdW1lbnQNCj4gY29ycmVjdGx5IGRlc2NyaWJlcyB0aGUgSUFOQSBhbGxvY2F0
aW9uLg0KPiA+Pg0KPiA+PiBJIHdvdWxkIGxpa2UgdG8gc2VlIGhlcmUgYSBzdGF0ZW1lbnQgc3Vj
aCBhcyA6ICJHaXZlbiBUQ1AgaGVhZGVyIHNwYWNlIGlzDQo+IHNjYXJjZSwgdGhpcyBzcGVjaWZp
Y2F0aW9uIGFsbG9jYXRlcyBhIHJlc2VydmVkIGhlYWRlciBiaXQgYW5kIG92ZXJsb2FkcyB0aGUN
Cj4gdHdvIEVDTiBmbGFncyBpbiB0aGUgVENQIGhlYWRlciAuLi7igJwuDQo+ID4gQSBiaXQgbGVu
Z3RoeSBidXQgbm93Og0KPiA+DQo+ID4gIkdpdmVuIFRDUCBoZWFkZXIgc3BhY2UgaXMNCj4gPiAg
ICAgICAgc2NhcmNlLCBpdCBhbGxvY2F0ZXMgYSByZXNlcnZlZCBoZWFkZXIgYml0LCB0aGF0IHdh
cyBwcmV2aW91c2x5IHVzZWQgZm9yDQo+ID4gICAgICAgIEVDTi1Ob25jZSB3aGljaCB3YXMgcmVj
ZW50bHkgZGVjbGFyZWQgaGlzdG9yaWMsIGFuZCBvdmVybG9hZHMgdGhlDQo+ID4gICAgICAgIHR3
byBleGlzdGluZyBFQ04gZmxhZ3MgaW4gdGhlIFRDUCBoZWFkZXIuIEZ1cnRoZXIsIGFkZGl0aW9u
YWwNCj4gPiAgICAgICAgaW5mb3JtYXRpb24gY2FuIGJlIHByb3ZpZGVkIGluIGEgbmV3IFRDUCBv
cHRpb24gdGhhdCBob3dldmVyIGlzIG5vdA0KPiB1c2VkDQo+ID4gICAgICAgIG9uIHRoZSBUQ1Ag
U1lOLiINCj4gPg0KPiA+Pj4+ICogMS4gIEludHJvZHVjdGlvbg0KPiA+Pj4+DQo+ID4+Pj4gICAg
UmVjZW50bHksIHByb3Bvc2VkIG1lY2hhbmlzbXMgbGlrZSBDb25nZXN0aW9uIEV4cG9zdXJlIChD
b25FeA0KPiA+Pj4+ICAgIFtSRkM3NzEzXSksIERDVENQIFtSRkM4MjU3XSBvciBMNFMgW0ktRC5p
ZXRmLXRzdndnLWw0cy1hcmNoXSBuZWVkDQo+ID4+Pj4gICAgbW9yZSBhY2N1cmF0ZSBFQ04gZmVl
ZGJhY2sgaW5mb3JtYXRpb24gd2hlbmV2ZXIgbW9yZSB0aGFuIG9uZQ0KPiA+Pj4gbWFya2luZw0K
PiA+Pj4+ICAgIGlzIHJlY2VpdmVkIGluIG9uZSBSVFQuDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIEF0
IGxlYXN0IGZvciBSRkMgODI1NyBzZWVtcyB0byBiZSBpbXBsZW1lbnRhYmxlIHdpdGhvaXQgdGhp
cy4NCj4gSW5zdGVhZA0KPiA+Pj4gb2Ygc3RhdGluZyBhICJuZWVkIiwgaXQgd291bGQgSU1ITyBt
YWtlIG1vcmUgc2Vuc2UgdG8gZGlzY3VzcyB0aGUNCj4gYmVuZWZpdHMNCj4gPj4+IG9mIHRoZSBz
dWdnZXN0ZWQgbWVjaGFuaXNtIGluIHRoaXMgZG9jdW1lbnQgb2YgaXRzIG93biwgaW5kZXBlbmRl
bnQNCj4gb2YNCj4gPj4+IG90aGVyIHByb3Bvc2Fscy4gVG8gbWUsIHRoaXMgZG9jdW1lbnQgc2hv
dWxkIGJlIGluZGVwZW5kZW50IG9mIG90aGVyDQo+ID4+PiBkb2N1bWVudHMgYW5kIHNwZWNpZmlj
YWxseSBvdGhlciBleHBlcmltZW50cy4gV2UgaGF2ZSB0byB0aGluayBhYm91dA0KPiBjYXNlcw0K
PiA+Pj4gd2hlcmUgbm90IGFsbCBleHBlcmltZW50cyBhcmUgc3VjY2Vzc2Z1bC4gVGhlbiBpbmRl
cGVuZGVudCBkb2N1bWVudHMNCj4gd2lsbA0KPiA+Pj4gYmUgbW9yZSBmdXR1cmUtcHJvb2YgaW4g
ZnV0dXJlLg0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgYSBuYW1pbmcgY29sbGlzaW9u4oCmIFRoZSBz
ZW50ZW5jZSB3YXMgbWVhbnQgdG8gc2F5IHRoYXQgdGhlc2UNCj4gPj4+IG1lY2hhbmlzbXMgbmV3
IG1vcmUgYWNjdXJhdGUgRUNOIGZlZWRiYWNrIHRoYW4gcHJvdmlkZWQgdG9kYXkgYnkNCj4gPj4+
IFJGQzMxNjggYnV0IGl0IHdhcyBub3QgbWVhbnQgdG8gc2F5IHRoYXQgdGhlc2UgbWVjaGFuaXNt
IGhhdmUgdG8gdXNlDQo+IHRoZQ0KPiA+Pj4gc2NoZW1lIGFzIHNwZWNpZmllZCBpbiB0aGlzIGRv
Y3VtZW50Lg0KPiA+Pj4NCj4gPj4+IEkgYWRkZWQgdGhlIGZvbGxvd2luZyBwYXJ0IHNlbnRlbmNl
Og0KPiA+Pj4NCj4gPj4+IOKAnlJlY2VudGx5LCBwcm9wb3NlZCBtZWNoYW5pc21zIGxpa2UgQ29u
Z2VzdGlvbiBFeHBvc3VyZSAoQ29uRXgNCj4gPj4+IFtSRkM3NzEzXSksIERDVENQIFtSRkM4MjU3
XSBvciBMNFMgW0ktRC5pZXRmLXRzdndnLWw0cy1hcmNoXSBuZWVkIG1vcmUNCj4gPj4+IGFjY3Vy
YXRlIEVDTiBmZWVkYmFjayBpbmZvcm1hdGlvbiB0aGFuIHByb3ZpZGVkIGJ5IHRoZSBmZWVkYmFj
aw0KPiBzY2hlbWUNCj4gPj4+IGFzIHNwZWNpZmllZCBpbiBbUkZDMzE2OF0gd2hlbmV2ZXIgbW9y
ZSB0aGFuIG9uZSBtYXJraW5nIGlzIHJlY2VpdmVkIGluDQo+IG9uZQ0KPiA+Pj4gUlRULiBUaGlz
IGRvY3VtZW50IHNwZWNpZmllcyBhbiBhbHRlcm5hdGl2ZSBmZWVkYmFjayBzY2hlbWUgdGhhdA0K
PiBwcm92aWRlcw0KPiA+Pj4gbW9yZSBhY2N1cmF0ZSBpbmZvcm1hdGlvbiBhbmQgY291bGQgYmUg
dXNlZCBieSB0aGVzZSBuZXcgVENQDQo+IGV4dGVuc2lvbnMu4oCcDQo+ID4+Pg0KPiA+Pj4gRG9l
cyB0aGlzIGhlbHA/DQo+ID4+IFNlZSBteSBwcm9wb3NhbCBmb3IgdGhlIGFic3RyYWN0LiBJIGNv
bnRpbnVlIHRvIGRpc2FncmVlIHdpdGggdGhlIHRlcm0NCj4gIm5lZWQiIGJ1dCBJIHRoaW5rIHRo
aXMgY2FuIGJlIHNvcnRlZCBvdXQgYnkgYW5vdGhlciB0ZXJtLg0KPiA+Pg0KPiA+Pj4+ICAgIElm
IEFjY0VDTiBwcm9ncmVzc2VzIGZyb20gZXhwZXJpbWVudGFsIHRvIHRoZSBzdGFuZGFyZHMNCj4g
Pj4+PiAgICB0cmFjaywgaXQgaXMgaW50ZW5kZWQgdG8gYmUgYSBjb21wbGV0ZSByZXBsYWNlbWVu
dCBmb3IgY2xhc3NpYyBUQ1AvDQo+ID4+Pj4gICAgRUNOIGZlZWRiYWNrLCBub3QgYSBmb3JrIGlu
IHRoZSBkZXNpZ24gb2YgVENQLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBUaGlzIHNlbnRlbmNlIHNo
b3VsZCBiZSByZW1vdmVkLCBhcyB0aGlzIGlzIHNwZWN1bGF0aW9uLg0KPiA+Pj4gV2h5PyBJdCBz
dGF0ZXMgYW4gaW50ZW504oCmIGFuZCB0aGF04oCZcyB0aGUgaW50ZW50IHRoYXQgd2UgaGF2ZS4N
Cj4gPj4+DQo+ID4+Pj4gICAgVW50aWwgdGhlIEFjY0VDTiBleHBlcmltZW50IHN1Y2NlZWRzLCBb
UkZDMzE2OF0gd2lsbCByZW1haW4gYXMgdGhlDQo+ID4+Pj4gICAgc3RhbmRhcmRzIHRyYWNrIHNw
ZWNpZmljYXRpb24gZm9yIGFkZGluZyBFQ04gdG8gVENQLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBU
aGlzIHNlbnRlbmNlIHNob3VsZCBiZSByZW1vdmVkIChvciByZXdvcmRlZCkNCj4gPj4+IFdoeT8g
RG9lcyBpdCBoZWxwIHRvIGFkZCBhbiBvbmx5IGhlcmU6DQo+ID4+Pg0KPiA+Pj4gIlVudGlsIHRo
ZSBBY2NFQ04gZXhwZXJpbWVudCBzdWNjZWVkcywgW1JGQzMxNjhdIHdpbGwgcmVtYWluIGFzIHRo
ZQ0KPiBvbmx5DQo+ID4+PiBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBmb3IgYWRkaW5n
IEVDTiB0byBUQ1Au4oCcDQo+ID4+IFRoaXMgd29yZGluZyBpcyBiZXR0ZXIuDQo+ID4+DQo+ID4+
Pj4gICAgQWNjRUNOIGZlZWRiYWNrIG92ZXJsb2FkcyBmbGFncyBhbmQgZmllbGRzIGluIHRoZSBt
YWluIFRDUCBoZWFkZXINCj4gPj4+PiAgICB3aXRoIG5ldyBkZWZpbml0aW9ucywgc28gYm90aCBl
bmRzIGhhdmUgdG8gc3VwcG9ydCB0aGUgbmV3IHdpcmUNCj4gPj4+PiAgICBwcm90b2NvbCBiZWZv
cmUgaXQgY2FuIGJlIHVzZWQuDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIEluIG15IHJlYWRpbmcgdGhp
cyBleHBlcmltZW50YWwgZG9jdW1lbnQgYXNrcyBmb3IgKm5ldyoNCj4gYWxsb2NhdGlvbg0KPiA+
Pj4gb2YgYSByZXNlcnZlZCBUQ1AgaGVhZGVyIGZsYWcuDQo+ID4+Pg0KPiA+Pj4gSXMgdGhpcyBi
ZXR0ZXI/DQo+ID4+Pg0KPiA+Pj4gIkFjY0VDTiBmZWVkYmFjayBvdmVybG9hZHMgdGhlIHR3byBl
eGlzdGluZyBFQ04gZmxhZ3MgYXMgd2VsbCBhcyB0aGUNCj4gPj4+ICAgICAgIGN1cnJlbnRseSBy
ZXNlcnZlZCBhbmQgcHJldmlvdXNseSBjYWxsZWQgTlMgZmxhZyBpbiB0aGUgbWFpbiBUQ1ANCj4g
aGVhZGVyDQo+ID4+PiAgICAgICB3aXRoIG5ldyBkZWZpbml0aW9ucywgc28gYm90aCBlbmRzIGhh
dmUgdG8gc3VwcG9ydCB0aGUgbmV3IHdpcmUNCj4gcHJvdG9jb2wNCj4gPj4+ICAgICAgIGJlZm9y
ZSBpdCBjYW4gYmUgdXNlZC7igJwNCj4gPj4+DQo+ID4+PiBJIHVuZGVyc3RhbmQgdGhhdCB5b3Ug
YXJlIG5vdCBoYXBweSB3aXRoIHRoZSB3b3JkIOKAnm92ZXJsb2Fk4oCcIGhlcmUgYnV0DQo+IHRo
ZQ0KPiA+Pj4gcG9pbnQgb2YgdGhpcyBzZW50ZW5jZSByZWFsbHkgaXMgdGhhdCB0aGUgZmxhZ3Mg
Y2FuL2NvdWxkIGJlIHVzZWQNCj4gZGlmZmVyZW50bHkNCj4gPj4+IGFuZCB0aGVyZWZvcmUgd2Ug
bmVlZCBhIG5ldyBuZWdvdGlhdGlvbiBiZWZvcmUgd2UgY2FuIHVzZSB0aGVtLg0KPiA+PiBGb3Ig
bWUgdGhlIGZvbGxvd2luZyB3b3VsZCB3b3JrOiAiQWNjRUNOIGZlZWRiYWNrIG92ZXJsb2FkcyB0
aGUgdHdvDQo+IGV4aXN0aW5nIEVDTiBmbGFncyBhbmQNCj4gPj4gYWxsb2NhdGVzIHRoZSBjdXJy
ZW50bHkgcmVzZXJ2ZWQgYW5kIHByZXZpb3VzbHkgY2FsbGVkIE5TIGZsYWcgaW4gdGhlIG1haW4N
Cj4gVENQIGhlYWRlci4NCj4gPj4gR2l2ZW4gdGhlIG5ldyBkZWZpbml0aW9ucywgYm90aCBlbmRz
IGhhdmUgdG8gc3VwcG9ydCB0aGUgbmV3IHdpcmUNCj4gcHJvdG9jb2wNCj4gPj4gYmVmb3JlIGl0
IGNhbiBiZSB1c2VkLiINCj4gPj4NCj4gPj4gSSBiZWxpZXZlIHRoZSB3b3JkaW5nIGhhcyB0byBi
ZSBjcnlzdGFsIGNsZWFyIG9uIHRoZSByZXNlcnZhdGlvbiBvZiBiaXQgNw0KPiB3aGVuIGl0IGlz
IGRpc2N1c3NlZCB0aGUgZmlyc3QgdGltZSBpbiB0aGUgdGV4dC4gSW4gZm9sbG93LXVwIHNlY3Rp
b25zLCBtYXliZQ0KPiBzaG9ydGVyIHRlcm1zIGNvdWxkIGJlIHVzZWQuDQo+ID4gT2theSwgbm93
Og0KPiA+DQo+ID4gIkFjY0VDTiBmZWVkYmFjayBvdmVybG9hZHMgdGhlIHR3byBleGlzdGluZyBF
Q04gZmxhZ3MgYW5kDQo+ID4gICAgICBhbGxvY2F0ZXMgdGhlIGN1cnJlbnRseSByZXNlcnZlZCBh
bmQgcHJldmlvdXNseSBjYWxsZWQgTlMgZmxhZyBpbiB0aGUNCj4gPiAgICAgIFRDUCBoZWFkZXIs
IHRvIGJlIHVzZWQgYXMgb25lIGZpZWxkIGluZGljYXRpbmcgdGhlIG51bWJlciBvZiBjb25nZXN0
aW9uDQo+ID4gICAgICBleHBlcmllbmNlZCBtYXJrZWQgcGFja2V0cy4gR2l2ZW4gdGhlIG5ldyBk
ZWZpbml0aW9ucyBvZiB0aGVzZSB0aHJlZQ0KPiBiaXRzLA0KPiA+ICAgICAgYm90aCBlbmRzICAg
ICBoYXZlIHRvIHN1cHBvcnQgdGhlIG5ldyB3aXJlIHByb3RvY29sIGJlZm9yZSBpdCBjYW4gYmUN
Cj4gdXNlZC4NCj4gPiAgICAgIFRoZXJlZm9yZSBkdXJpbmcgdGhlIFRDUCBoYW5kc2hha2UgdGhl
IHR3byBlbmRzIHVzZSB0aGVzZSB0aHJlZSBiaXQgaW4NCj4gPiAgICAgIHRoZSBUQ1AgaGVhZGVy
IHRvIG5lZ290aWF0ZSB0aGUgbW9zdCBhZHZhbmNlZCBmZWVkYmFjayBwcm90b2NvbA0KPiA+ICAg
ICAgdGhhdCB0aGV5IGNhbiBib3RoIHN1cHBvcnQgaW4gYSBiYWNrd2FyZCBjb21wYXRpYmxlIHdh
eSB0bw0KPiA+ICAgICAgPHhyZWYgdGFyZ2V0PSJSRkMzMTY4Ii8+LiINCj4gPj4+IElmIHlvdSBw
cmVmZXIsIHdlIGNhbiBhbHNvIHJlbW92ZSB0aGUgTlMgZmxhZyBpbiB0aGlzIGxpc3QsIGFzIEVD
TiBOb25jZQ0KPiB3YXMNCj4gPj4+IGFueXdheSBuZXZlciBkZXBsb3llZC4NCj4gPj4+DQo+ID4+
Pj4gICAgRm9yIHRoYXQgd2UgcmVmZXIgdG8gW1JGQzMxNjhdIG9yIGFueSBSRkMgdGhhdA0KPiA+
Pj4+ICAgIHNwZWNpZmllcyBhIGRpZmZlcmVudCByZXNwb25zZSB0byBUQ1AgRUNOIGZlZWRiYWNr
LCBmb3IgZXhhbXBsZToNCj4gPj4+PiAgICBbUkZDODI1N107IG9yIHRoZSBFQ04gZXhwZXJpbWVu
dHMgcmVmZXJyZWQgdG8gaW4NCj4gPj4+PiAgICBbSS1ELmlldGYtdHN2d2ctZWNuLWV4cGVyaW1l
bnRhdGlvbl0sIG5hbWVseTogYSBUQ1AtYmFzZWQgTG93DQo+IExhdGVuY3kNCj4gPj4+PiAgICBM
b3cgTG9zcyBTY2FsYWJsZSAoTDRTKSBjb25nZXN0aW9uIGNvbnRyb2wgW0ktRC5pZXRmLXRzdndn
LWw0cy1hcmNoXTsNCj4gPj4+PiAgICBFQ04tY2FwYWJsZSBUQ1AgY29udHJvbCBwYWNrZXRzIFtJ
LUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbl0sIG9yDQo+ID4+Pj4gICAgQWx0ZXJuYXRpdmUg
QmFja29mZiB3aXRoIEVDTiAoQUJFKQ0KPiA+Pj4+ICAgIFtJLUQuaWV0Zi10Y3BtLWFsdGVybmF0
aXZlYmFja29mZi1lY25dLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBBdCBsZWFzdCBBQkUgc2VlbXMg
b3J0aG9nb25hbC4gQW55d2F5LCBJIHRoaW5rIHRoaXMgcGFyYWdyYXBoIGNhbg0KPiBqdXN0DQo+
ID4+PiBiZSBkZWxldGVkLiBJZiBvdGhlciBleHBlcmltZW50cyBuZWVkIG1vcmUgYWNjdXJhdGUg
ZmVlZGJhY2ssIGl0IGlzIHVwDQo+IHRvDQo+ID4+PiB0aGVtIHRvIGV4cGxhaW4gaG93IHRoZXkg
d291bGQgdXNlIHRoaXMgbWVjaGFuaXNtLiBUaGlzIGRvY3VtZW50DQo+IHNob3VsZA0KPiA+Pj4g
Zm9jdXMgb24gaG93IHRvIHNpZ25hbCB0aGUgZmVlZGJhY2ssIG5vdCBob3cgdG8gdXNlIHRoYXQu
DQo+ID4+Pg0KPiA+Pj4gWWVzLCB0aGF0IGlzIHdoYXQgdGhlIHBhcmFncmFwaCBzYXlzLiBJc27i
gJl0IGl0IGJldHRlciB0byBiZSBleHBsaWNpdCBhYm91dA0KPiB0aGlzPw0KPiA+Pj4NCj4gPj4+
PiAgICBJdCBpcyBsaWtlbHkgKGJ1dCBub3QgcmVxdWlyZWQpIHRoYXQgdGhlIEFjY0VDTiBwcm90
b2NvbCB3aWxsIGJlDQo+ID4+Pj4gICAgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aCB0aGUgZm9sbG93
aW5nIGV4cGVyaW1lbnRhbCBhZGRpdGlvbnMgdG8gdGhlDQo+ID4+Pj4gICAgVENQLUVDTiBwcm90
b2NvbDogRUNOLWNhcGFibGUgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQNCj4gcmV0cmFuc21pc3Np
b25zDQo+ID4+Pj4gICAgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuXSwgd2hpY2ggaW5j
bHVkZXMgdGhlIEVDTi1jYXBhYmxlIFNZTi8NCj4gPj4+PiAgICBBQ0sgZXhwZXJpbWVudCBbUkZD
NTU2Ml07IGFuZCB0ZXN0aW5nIHJlY2VpdmVyIG5vbi1jb21wbGlhbmNlDQo+ID4+Pj4gICAgW0kt
RC5tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXRdLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBJIGFtIGEg
YmlnIGZhbiBvZiBzaW1wbGUsIHN0YW5kYWxvbmUgZG9jdW1lbnRzLiBJbiBteSB2aWV3LCB0aGUN
Cj4gVENQTQ0KPiA+Pj4gd29ya2luZyBncm91cCBzaG91bGQgcHVibGlzaCBkcmFmdC1pZXRmLXRj
cG0tYWNjdXJhdGUtZWNuIGFuZCBkcmFmdC0NCj4gaWV0Zi0NCj4gPj4+IHRjcG0tZ2VuZXJhbGl6
ZWQtZWNuIGluZGVwZW5kZW50IGRvY3VtZW50cywgd2hpY2ggcHJvYmFibHkgaW1wbGllcw0KPiB0
aGF0DQo+ID4+PiBkcmFmdC1pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIGRvZXMgbm90IHVzZSBB
Y2NFQ04uIElmDQo+IGV4cGVyaW1lbnRhdGlvbg0KPiA+Pj4gd2l0aCBFQ1QgaW4gU1lOIHJlcXVp
cmVzIGEgY29tYmluYXRpb24sIHRoaXMgY291bGQgYmUgZG9uZSBpbiBhIG5ldywNCj4gdGhpcmQN
Cj4gPj4+IGRvY3VtZW50LiBBcGFydCBmcm9tIGhhdmluZyBzaW1wbGVyIGZvY3VzZWQgZG9jdW1l
bnRzLCB0aGlzIGNvdWxkDQo+ID4+PiBzaWduaWZpY2FudGx5IGhlbHAgbGF0ZXIgd2l0aCBtb3Zp
bmcgZm9yd2FyZCBkb2N1bWVudHMgdG8gc3RhbmRhcmRzDQo+IHRyYWNrLg0KPiA+Pj4NCj4gPj4+
IEkgZGlzYWdyZWUsIGhvd2V2ZXIsIHRoaXMgaXMgYSBkaXNjdXNzaW9uIHRvIGhhdmUgb24gZHJh
ZnQtaWV0Zi10Y3BtLQ0KPiA+Pj4gZ2VuZXJhbGl6ZWQtZWNuLiBJIGRvbuKAmXQgc2VlIGEgcHJv
YmxlbSBpbiAgcHJvdmlkaW5nIGEgcmVmZXJlbmNlIGhlcmUNCj4gdGhhdA0KPiA+Pj4gc2F5cyDi
gJ5pdCBpcyBsaWtlbHnigKbigJwgYW5kIG5vdGhpbmcgbW9yZS4NCj4gPj4+Pg0KPiA+Pj4+DQo+
ID4+Pj4gKiAxLjEuICBEb2N1bWVudCBSb2FkbWFwDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIEEgbWFj
cm9zY29waWMgY29tbWVudCBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIGEgbG90IG9mDQo+IGlu
dHJvZHVjdGlvbg0KPiA+Pj4gYW5kIHR1dG9yaWFsIHRleHQgd2l0aCBsb3QncyBvZiByZWR1bmRh
bmN5IHRvd2FyZHMgb3RoZXIgZG9jdW1lbnRzLiBJDQo+IHRoaW5rDQo+ID4+PiB0aGUgZG9jdW1l
bnQgY2FuIGJlIG1hZGUgbXVjaCBlYXNpZXIgdG8gcmVhZCBieSBzaG9ydGVuIGl0LiBJbiBtYW55
DQo+IGNhc2VzDQo+ID4+PiB0aGlzIGlzIGp1c3QgYW4gZWRpdG9yaWFsIGNoYW5nZSBhcyB0aGVy
ZSBpcyByZWR1bmRhbmN5LiBBcyBvbmUgc3VjaA0KPiBleGFtcGxlLA0KPiA+Pj4ganVzdCByZW1v
dmUgdGhpcyBzZWN0aW9uLg0KPiA+Pj4NCj4gPj4+IEkgZ3Vlc3MgdGhpcyBhIG1hdHRlciBvZiB0
YXN0ZS4gQXMgYW4gQUQsIEnigJltIGEgYmlnIGZhbiBvZiBzaG9ydCBhbmQgY29uY2lzZQ0KPiA+
Pj4gZG9jdW1lbnRzLCBob3dldmVyLCBzb21lIHJlZHVuZGFuY3kgY2FuIGFsc28gaGVscCB1bmRl
cnN0YW5kaW5nLA0KPiA+Pj4gZXNwZWNpYWxseSBpZiB5b3UgZXhwbGFpbiB0aGluZ3MgbXVsdGlw
bGUgdGltZXMgYnV0IHdpdGggYSBkaWZmZXJlbnQgbGV2ZWwgb2YNCj4gPj4+IGRldGFpbC4gSSBw
ZXJzb25hbGx5IHdvdWxkIG5vdCBuZWVkIHRoZSByb2FkbWFwIGJ1dCBJIGtub3cgbWFueQ0KPiBw
ZW9wbGUNCj4gPj4+IHdobyBmaW5kIHRoZXNlIHRoaW5ncyBoZWxwZnVsIGFuZCB0byBiZSBob25l
c3QgSSBkb27igJl0IHNlZSBob3cNCj4gcmVtb3ZpbmcgdGhpcw0KPiA+Pj4gcGFydCBtYWtlcyB0
aGUgZG9jIGFueSBiZXR0ZXIuIElmIHlvdSBkb27igJl0IHdhbnQgaXQsIGRvbuKAmXQgcmVhZCBp
dC4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiAqIDEuMi4gIEdvYWxzDQo+ID4+Pj4NCj4gPj4+PiBb
bXNdIEkgdGhpbmsgdGhpcyBzZWN0aW9uIGNhbiBhbHNvIGp1c3QgYmUgcmVtb3ZlZC4NCj4gPj4+
IEkgaGF2ZSB0byBzYXkgSSBhbHNvIGRvbuKAmXQgc2VlIHRoZSBwb2ludCBvZiByZW1vdmluZyB0
aGlzIHBhcnQuIEdpdmVuDQo+IHdl4oCZdmUNCj4gPj4+IGRvbmUgdGhlIHdvcmsgb24gcmVxdWly
ZW1lbnRzLCBJIHRoaW5rIHdlIHNob3VsZCBhbHNvIGxpbmsgdG8gdGhpcyBkb2MNCj4gPj4+IHNv
bWV3aGVyZS4NCj4gPj4+Pg0KPiA+Pj4+ICogMS4zLiAgRXhwZXJpbWVudCBHb2Fscw0KPiA+Pj4+
DQo+ID4+Pj4gICAgVENQIGlzIGNyaXRpY2FsIHRvIHRoZSByb2J1c3QgZnVuY3Rpb25pbmcgb2Yg
dGhlIEludGVybmV0LCB0aGVyZWZvcmUNCj4gPj4+PiAgICBhbnkgcHJvcG9zZWQgbW9kaWZpY2F0
aW9ucyB0byBUQ1AgbmVlZCB0byBiZSB0aG9yb3VnaGx5IHRlc3RlZC4gVGhlDQo+ID4+Pj4gICAg
cHJlc2VudCBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyBhbiBleHBlcmltZW50YWwgcHJvdG9jb2wg
dGhhdCBhZGRzDQo+ID4+Pj4gICAgbW9yZSBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sgdG8gdGhlIFRD
UCBwcm90b2NvbC4gIFRoZSBpbnRlbnRpb24gaXMgdG8NCj4gPj4+PiAgICBzcGVjaWZ5IHRoZSBw
cm90b2NvbCBzdWZmaWNpZW50bHkgc28gdGhhdCBtb3JlIHRoYW4gb25lDQo+ID4+Pj4gICAgaW1w
bGVtZW50YXRpb24gY2FuIGJlIGJ1aWx0IGluIG9yZGVyIHRvIHRlc3QgaXRzIGZ1bmN0aW9uLCBy
b2J1c3RuZXNzDQo+ID4+Pj4gICAgYW5kIGludGVyb3BlcmFiaWxpdHkgKHdpdGggaXRzZWxmIGFu
ZCB3aXRoIHByZXZpb3VzIHZlcnNpb24gb2YgRUNODQo+ID4+Pj4gICAgYW5kIFRDUCkuDQo+ID4+
Pj4NCj4gPj4+PiBbbXNdIEkgdGhpbmsgYWxsIHdoYXQgaXMgd3JpdHRlbiBpbiB0aGlzIHBhcmFn
cmFwaCBpcyBvYnZpb3VzLCBubz8gQ2FuJ3Qgd2UNCj4ganVzdA0KPiA+Pj4gZGVsZXRlIHRoaXM/
DQo+ID4+Pg0KPiA+Pj4gU3VyZSwgaG93ZXZlciwgSSBkb27igJl0IHRoaW5rIGl0IGh1cnRzIHRv
IHNwZWxsIGl0IG91dC4gRm9yIG1lIGJvdGggaXMgZmluZSwNCj4ga2VlcCBpdA0KPiA+Pj4gb3Ig
cmVtb3ZlIGl0Lg0KPiA+Pj4NCj4gPj4+PiAgICBUaGUgZXhwZXJpbWVudGFsIHByb3RvY29sIHdp
bGwgYmUgY29uc2lkZXJlZCBzdWNjZXNzZnVsIGlmIGl0IGlzDQo+ID4+Pj4gICAgZGVwbG95ZWQg
YW5kIGlmIGl0IHNhdGlzZmllcyB0aGUgcmVxdWlyZW1lbnRzIG9mIFtSRkM3NTYwXSBpbiB0aGUN
Cj4gPj4+PiAgICBjb25zZW5zdXMgb3BpbmlvbiBvZiB0aGUgSUVURiB0Y3BtIHdvcmtpbmcgZ3Jv
dXAuICBJbiBzaG9ydCwgdGhpcw0KPiA+Pj4+ICAgIHJlcXVpcmVzIHRoYXQgaXQgaW1wcm92ZXMg
dGhlIGFjY3VyYWN5IGFuZCB0aW1lbGluZXNzIG9mIFRDUCdzIEVDTg0KPiA+Pj4+ICAgIGZlZWRi
YWNrLCBhcyBjbGFpbWVkIGluIFNlY3Rpb24gNSwgd2hpbGUgc3RyaWtpbmcgYSBiYWxhbmNlIGJl
dHdlZW4NCj4gPj4+PiAgICB0aGUgY29uZmxpY3RpbmcgcmVxdWlyZW1lbnRzIG9mIHJlc2lsaWVu
Y2UsIGludGVncml0eSBhbmQNCj4gPj4+PiAgICBtaW5pbWlzYXRpb24gb2Ygb3ZlcmhlYWQuICBJ
dCBhbHNvIHJlcXVpcmVzIHRoYXQgaXQgaXMgbm90IHVuZHVseQ0KPiA+Pj4+ICAgIGNvbXBsZXgs
IGFuZCB0aGF0IGl0IGlzIGNvbXBhdGlibGUgd2l0aCBwcmV2YWxlbnQgZXF1aXBtZW50DQo+ID4+
Pj4gICAgYmVoYXZpb3VycyBpbiB0aGUgY3VycmVudCBJbnRlcm5ldCAoZS5nLiBoYXJkd2FyZSBv
ZmZsb2FkaW5nIGFuZA0KPiA+Pj4+ICAgIG1pZGRsZWJveGVzKSwgd2hldGhlciBvciBub3QgdGhl
eSBjb21wbHkgd2l0aCBzdGFuZGFyZHMuDQo+ID4+Pj4NCj4gPj4+PiAgICBUZXN0aW5nIHdpbGwg
bW9zdGx5IGZvY3VzIG9uIGZhbGwtYmFjayBzdHJhdGVnaWVzIGluIGNhc2Ugb2YNCj4gPj4+PiAg
ICBtaWRkbGVib3ggaW50ZXJmZXJlbmNlLiAgQ3VycmVudCByZWNvbW1lbmRlZCBzdHJhdGVnaWVz
IGFyZQ0KPiBzcGVjaWZpZWQNCj4gPj4+PiAgICBpbiBTZWN0aW9ucyAzLjEuMiwgMy4yLjMsIDMu
Mi40IGFuZCAzLjIuNy4gIFRoZSBlZmZlY3RpdmVuZXNzIG9mDQo+ID4+Pj4gICAgdGhlc2Ugc3Ry
YXRlZ2llcyBkZXBlbmRzIG9uIHRoZSBhY3R1YWwgZGVwbG95bWVudCBzaXR1YXRpb24gb2YNCj4g
Pj4+PiAgICBtaWRkbGVib3hlcy4gIFRoZXJlZm9yZSBleHBlcmltZW50YWwgdmVyaWZpY2F0aW9u
IHRvIGNvbmZpcm0gbGFyZ2UtDQo+ID4+Pj4gICAgc2NhbGUgcGF0aCB0cmF2ZXJzYWwgaW4gdGhl
IEludGVybmV0IGlzIG5lZWRlZCBiZWZvcmUgZmluYWxpemluZyB0aGlzDQo+ID4+Pj4gICAgc3Bl
Y2lmaWNhdGlvbiBvbiB0aGUgU3RhbmRhcmRzIFRyYWNrLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBU
aGVzZSB0d28gcGFyYWdyYXBocyBtdXN0IGJlIGVudGlyZWx5IHJld3JpdHRlbi4gQXMgSSBoYXZl
DQo+ID4+PiBtZW50aW9uZWQgYmVmb3JlLCBJIGRvbid0IHRoaW5rIGFuIFJGQyBzaG91bGQgc3Bl
Y3VsYXRlIGFib3V0IFRDUE0NCj4gYW5kIGl0cw0KPiA+Pj4gY29uc2Vuc3VzIG9waW5pb24uIEkg
d291bGQgc3VnZ2VzdCBhIHdvcmRpbmcgYWxvbmcgdGhlIGxpbmVzIG9mOg0KPiA+Pj4+IDxtcz4N
Cj4gPj4+PiAgICBUaGUgZXhwZXJpbWVudGFsIHByb3RvY29sIHdpbGwgYmUgY29uc2lkZXJlZCBz
dWNjZXNzZnVsIGlmDQo+ID4+Pj4gICAgdGVzdGluZyBjb25maXJtcyB0aGF0IHRoZSBwcm9wb3Nl
ZCBtZWNoYW5pc20gY2FuIGJlIGRlcGxveWVkIGF0DQo+IGxhcmdlDQo+ID4+PiBzY2FsZS4NCj4g
Pj4+PiAgICBUZXN0aW5nIHdpbGwgbW9zdGx5IGZvY3VzIG9uIGZhbGwtYmFjayBzdHJhdGVnaWVz
IGluIGNhc2Ugb2YNCj4gPj4+PiAgICBtaWRkbGVib3ggaW50ZXJmZXJlbmNlLiAgQ3VycmVudCBy
ZWNvbW1lbmRlZCBzdHJhdGVnaWVzIGFyZQ0KPiBzcGVjaWZpZWQNCj4gPj4+PiAgICBpbiBTZWN0
aW9ucyAzLjEuMiwgMy4yLjMsIDMuMi40IGFuZCAzLjIuNy4gIFRoZSBlZmZlY3RpdmVuZXNzIG9m
DQo+ID4+Pj4gICAgdGhlc2Ugc3RyYXRlZ2llcyBkZXBlbmRzIG9uIHRoZSBhY3R1YWwgZGVwbG95
bWVudCBzaXR1YXRpb24gb2YNCj4gPj4+PiAgICBtaWRkbGVib3hlcy4gIFRoZXJlZm9yZSBleHBl
cmltZW50YWwgdmVyaWZpY2F0aW9uIHRvIGNvbmZpcm0gbGFyZ2UtDQo+ID4+Pj4gICAgc2NhbGUg
cGF0aCB0cmF2ZXJzYWwgaW4gdGhlIEludGVybmV0IGlzIG5lZWRlZCwgZS5nLiwgYnkgc3VwcG9y
dCBpbg0KPiA+Pj4+ICAgIG1ham9yIFRDUCBzdGFja3MuDQo+ID4+Pj4gPC9tcz4NCj4gPj4+Pg0K
PiA+Pj4gSSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBwb2ludCBoZXJlLiBJIGRvbuKAmXQgdGhp
bmsgdGhhdCB0aGUgcGFyYXBocmFzZQ0KPiA+Pj4gc3BlY3VsYXRlcyBhYm91dCB0aGUgY29uc2Vu
c3VzIG9mIHRjcG0sIGluIGNvbnRyYXN0IGl0IHNheSB0Y3BtIGhhcyB0bw0KPiA+Pj4gZGVjaWRl
ZCBpZiB0aGUgcmVxdWlyZW1lbnRzIHByZXZpb3VzbHkgc3BlY2lmaWVkIGJ5IHRjcG0gYXJlIHN1
ZmZpY2llbnRseQ0KPiA+Pj4gZnVsZmlsbGVkLiBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIG5v
dCBtZW50aW9uIHRoZSByZXF1aXJlbWVudCBkcmFmdCBhcw0KPiB0aGlzDQo+ID4+PiBkcmFmdCBh
cyB0Y3BtIGNvbnNlbnN1cyBhbmQgd2FzIHdyaXR0ZW4gZm9yIHRoaXMgcHVycG9zZS4NCj4gPj4g
TXkgc3VnZ2VzdGVkIHdvcmRpbmcgdXNlcyB0aGUgZXhwcmVzc2lvbiAiY2FuIGJlIGRlcGxveWVk
IGF0IGxhcmdlDQo+IHNjYWxlIiBhbmQgSSBiZWxpZXZlIHRoaXMgaXMgcmVsZXZhbnQuDQo+ID4+
DQo+ID4+IFRoZSBkb2N1bWVudCBhbHJlYWR5IGRlc2NyaWJlcyBpbiBTZWN0aW9uIDUgaG93IHRo
ZSBwcm90b2NvbCBzYXRpc2ZpZXMNCj4gdGhlIGFncmVlZCByZXF1aXJlbWVudHMgZm9yIGEgbW9y
ZSBhY2N1cmF0ZSBFQ04gZmVlZGJhY2sgcHJvdG9jb2wNCj4gW1JGQzc1NjBdLiBTbywgaWYgdGhl
IFRDUE0gd29ya2luZyBncm91cCBwdWJsaXNoZXMgdGhpcyBkb2N1bWVudCB3aXRoIHRoZQ0KPiBj
b250ZW50IG9mIFNlY3Rpb24gNSwgSSBiZWxpZXZlIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAgYWxy
ZWFkeSBoYXMgcmVhY2hlZA0KPiBjb25zZW5zdXMgdGhhdCB0aGUgcHJvdG9jb2wgbWVldHMgcmVx
dWlyZW1lbnRzLiBJbiBhZGRpdGlvbiwgaXQgaXMgcG9zc2libGUNCj4gdGhhdCBuZXcgcmVxdWly
ZW1lbnRzIHdvdWxkIGJlIGlkZW50aWZpZWQgaW4gZnV0dXJlLCBlLmcuLCBhcyBhbiBvdXRjb21l
IG9mDQo+IHRoZSBleHBlcmltZW50LCBhbmQgdGhhdCB3b3VsZCBvYnZpb3VzbHkgaGF2ZSB0byBi
ZSBjb25zaWRlcmVkIGJ5IFRDUE0uDQo+IEluIHRoYXQgY2FzZSwgZm9yIHRoZSBzdWNjZXNzIG9m
IHRoZSBleHBlcmltZW50IG5vdCBvbmx5IFJGQyA3NTYwIHdvdWxkDQo+IG1hdHRlciwgYnV0IGFs
c28gZnVydGhlciByZXF1aXJlbWVudHMuIE15IHByb3Bvc2VkIHdvcmRpbmcgZG9lcyBub3QgaGF2
ZQ0KPiBhbGwgdGhlc2UgcHJvYmxlbXMuDQo+ID4+DQo+ID4+IEluIGEgbnV0c2hlbGwsIEkgY29u
dGludWUgdG8gYmVsaWV2ZSB0aGF0IHRoaXMgc2VjdGlvbiBoYXMgdG8gY2hhbmdlLg0KPiA+DQo+
ID4gT2theSwgdXNlZCB5b3VyIHByb3Bvc2VkIHdvcmRpbmcuIFlvdSBoYXZlIGEgcG9pbnQgYWJv
dXQgdGhlDQo+IHJlcXVpcmVtZW50IGFuZCBJIG1pcy1yZWFkIHlvdSBwcm9wb3NhbCBlYXJsaWVy
IGFzIOKAnmhhcyB0byBiZSBkZXBsb3llZA0KPiBsYXJnZS1zY2FsZeKAnC4NCj4gPg0KPiA+Pj4+
ICogMS41LiAgUmVjYXAgb2YgRXhpc3RpbmcgRUNOIGZlZWRiYWNrIGluIElQL1RDUA0KPiA+Pj4+
DQo+ID4+Pj4gW21zXSBUaGlzIHNlY3Rpb24gY291bGQgcHJvYmFibHkgYmUgc2hvcnRlbmVkIGFz
IHdlbGwuDQo+ID4+Pj4NCj4gPj4+PiAgICBUaGUgbGFzdCBiaXQgaW4gYnl0ZSAxMyBvZiB0aGUg
VENQIGhlYWRlciB3YXMgZGVmaW5lZCBhcyB0aGUgTm9uY2UNCj4gPj4+PiAgICBTdW0gKE5TKSBm
b3IgdGhlIEVDTiBOb25jZSBbUkZDMzU0MF0uICBSRkMgMzU0MCB3YXMgbmV2ZXINCj4gZGVwbG95
ZWQgc28NCj4gPj4+PiAgICBpdCBpcyBiZWluZyByZWNsYXNzaWZpZWQgYXMgaGlzdG9yaWMsIG1h
a2luZyB0aGlzIFRDUCBmbGFnIGF2YWlsYWJsZQ0KPiA+Pj4+ICAgIGZvciB1c2UgYnkgdGhlIEFj
Y0VDTiBleHBlcmltZW50IGluc3RlYWQuDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIFRoaXMgd29yZGlu
ZywgYXMgd2VsbCBhcyBGaWd1cmUgMSwgbmVlZHMgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlDQo+
IElBTkENCj4gPj4+IHN0YXR1cyB3aGVuIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRh
dGlvbiBpcyBwdWJsaXNoZWQuDQo+ID4+Pg0KPiA+Pj4gSXMgZG9lcy4gSG93ZXZlciwgSSBjYW4g
ZXhwbGljaXRseSBzYXkgdGhhdCBpcyBoYXMgYmUgcmUtY2xzc2lmaWVkIGFzDQo+IHJlc2VydmVk
Lg0KPiA+Pj4NCj4gPj4+ICJSRkMgMzU0MCB3YXMgbmV2ZXIgZGVwbG95ZWQgc28gaXQgaXMgYmVp
bmcgcmVjbGFzc2lmaWVkIGFzIGhpc3RvcmljIFtJLQ0KPiBELmlldGYtDQo+ID4+PiB0c3Z3Zy1l
Y24tZXhwZXJpbWVudGF0aW9uXSBhbmQgdGhlIHJlc3BlY3RpdmUgZmxhZyBoYXMgYmVlbiBtYXJr
ZWQgYXMNCj4gPj4+IOKAnnJlc2VydmVk4oCcIGluIHRoZSBJQU5BIFRDUCBIZWFkZXIgRmxhZ3Mg
cmVnaXN0cnksIG1ha2luZyB0aGlzIFRDUCBmbGFnDQo+ID4+PiBhdmFpbGFibGUgZm9yIHVzZSBi
eSB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgaW5zdGVhZC7igJwNCj4gPj4+DQo+ID4+PiBCZXR0ZXI/
DQo+ID4+Pg0KPiA+Pj4+IEluIG15IHVuZGVyc3RhbmRpbmcsIHRoaXMgZXhwZXJpbWVudGFsIGRv
Y3VtZW50IGFza3MgZm9yIG5ldw0KPiBhc3NpZ25tZW50DQo+ID4+PiBvZiBhIHJlc2VydmVkIFRD
UCBoZWFkZXIgZmxhZy4NCj4gPj4+DQo+ID4+PiBBcyBJIHNhaWQgSeKAmW0gbm90IHN1cmUgaWYg
d2UgaGF2ZSBmdWxseSBjb25jbHVkZWQgdGhpcyBkaXNjdXNzaW9uIHlldC4NCj4gSG93ZXZlciwN
Cj4gPj4+IHdoYXQgd2UgcmVhbGx5IHdvdWxkIHdhbnQgdG8gaXMgbWVudGlvbiBzb21ld2hlcmUg
dGhhdCB0aGlzDQo+IGV4cGVyaW1lbnQNCj4gPj4+IHdpdGggdGhpcyBmbGFncyBpcyBydW5uaW5n
LiBJIGd1ZXNzIHRoZXJlIGFyZSB0aHJlZSBvcHRpb25zOg0KPiA+Pj4gMSkga2VlcCBpdCBpbiB0
aGUgcmVnaXN0cnkgYXMgcmVzZXJ2ZWQgYW5kIGNvbnNlcnZlIHRoZSBrbm93bGVkZ2UgaW4NCj4g
dGNwbQ0KPiA+Pj4gdGhhdCB0aGlzIGV4cGVyaW1lbnQgaXMgcnVubmluZyBhbmQgbm8gb3RoZXIg
ZXhwZXJpbWVudGFsIFJGQyBzdWNoIHVzZQ0KPiB0aGlzDQo+ID4+PiBmbGFncyBhcyBsb25nIGFz
IHRoaXMgZXhwZXJpbWVudCBpcyBydW5uaW5nLg0KPiA+Pj4gMikgS2VlcCBpcyBtYXJrZWQgYXMg
cmVzZXJ2ZWQgYnV0IGFkZCBhIG5vdGUgYWJvdXQgdGhpcyBleHBlcmltZW50IGluDQo+IHRoZQ0K
PiA+Pj4gSUFOQSByZWdpc3RyeQ0KPiA+Pj4gMykgT3IgYXNzaWduIGl0IHJpZ2h0IGF3YXkgd2l0
aCBJRVNHIGFwcHJvdmFsLiBJIGd1ZXNzIGluIHRoaXMgY2FzZSB0Y3BtDQo+IGNvdWxkDQo+ID4+
PiBhbHNvIGNvbnNpZGVyIHRvIGNoYW5nZSB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSB0byDigJ5J
RVRGIFJldmlld+KAnC4NCj4gPj4gVGhlIGN1cnJlbnQgcmVnaXN0cmF0aW9uIHBvbGljeSBmb3Ig
dGhlIFRDUCBoZWFkZXIgZmxhZ3MgaXMgInN0YW5kYXJkcw0KPiBhY3Rpb24iLiBJIHVuZGVyc3Rh
bmQgdGhhdCB0aGUgSUVTRyBjb3VsZCBhcHByb3ZlIGV4Y2VwdGlvbnMuIEJ1dCBnaXZlbiB0aGUN
Cj4gcG9saWN5LCBJIGJlbGlldmUgdGhlIGRvY3VtZW50IGhhcyB0byBiZSB2ZXJ5IHByZWNpc2Ug
b24gdGhlIHJlcXVlc3QNCj4gcmVnYXJkaW5nIGJpdCA3Lg0KPiA+IE9rYXksIGl0IG5vdyBzYXlz
Og0KPiA+DQo+ID4gIltUTyBCRSBSRU1PVkVEOiBJQU5BIGlzIHJlcXVlc3RlZCB0byB1cGRhdGUg
dGhlIGV4aXN0aW5nIGVudHJ5IGluIHRoZQ0KPiBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2Nv
bCAoVENQKSBIZWFkZXIgRmxhZ3MgcmVnaXN0cmF0aW9uDQo+IChodHRwczovL3d3dy5pYW5hLm9y
Zy9hc3NpZ25tZW50cy90Y3AtaGVhZGVyLWZsYWdzL3RjcC1oZWFkZXItDQo+IGZsYWdzLnhodG1s
I3RjcC1oZWFkZXItZmxhZ3MtMSkgZm9yIEJpdCA3IHRvICJBRSAoQWNjdXJhdGUgRUNOKSwgcHJl
dmlvdXNseQ0KPiB1c2VkIGJ5IEhpc3RvcmljIGFzIE5TIChOb25jZSBTdW0pIFtSRkMzNTQwLCBS
RkM4MzExXSIgYW5kIGNoYW5nZSB0aGUNCj4gcmVmZXJlbmNlIHRvIHRoaXMgUkZDLXRvLWJlIGlu
c3RlYWQgb2YgUkZDODMxMS5d4oCcDQo+ID4NCj4gPiBJIGd1ZXNzIHdlIGNvdWxkIGFsc28gYXNr
IElBTkEgdG8gYWRkIGFuIGFkZGl0aW9uYWwgY29tbWVudCBjb2x1bW4NCj4gaW5zdGVhZCAoYnV0
IG5vdCBzdXJlIGlmIHdlIHRoZW4gaGF2ZSB0byB1cGRhdGUgUkZDMzE2OCwgd2hpY2ggSSB0aGlu
ayB3ZQ0KPiByZWFsbHkgZG9u4oCZdCB3YW50LiBTaG91bGQgYmUgZmluZSBub3cuDQo+ID4NCj4g
Pj4+PiAqIDIuICBBY2NFQ04gUHJvdG9jb2wgT3ZlcnZpZXcgYW5kIFJhdGlvbmFsZQ0KPiA+Pj4+
DQo+ID4+Pj4gICAgbyAgYW4gZXNzZW50aWFsIHBhcnQgdGhhdCByZS11c2VzIEVDTiBUQ1AgaGVh
ZGVyIGJpdHMgdG8gZmVlZCBiYWNrDQo+ID4+Pj4gICAgICAgdGhlIG51bWJlciBvZiBhcnJpdmlu
ZyBDRSBtYXJrZWQgcGFja2V0cy4gIFRoaXMgcHJvdmlkZXMgbW9yZQ0KPiA+Pj4+ICAgICAgIGFj
Y3VyYWN5IHRoYW4gY2xhc3NpYyBFQ04gZmVlZGJhY2ssIGJ1dCBsaW1pdGVkIHJlc2lsaWVuY2Ug
YWdhaW5zdA0KPiA+Pj4+ICAgICAgIEFDSyBsb3NzOw0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBUaGUg
d29yZCAicmUtdXNlIiBpcyBJTUhPIG5vdCBjb3JyZWN0Lg0KPiA+Pj4gSSB0aGluayB0aGlzIGlz
IG5pdCBwaWNraW5nLiBVc2luZyBhIGRpZmZlcmVudCBwaHJhc2luZyBoZXJlIG1ha2VzIHRoZQ0K
PiBzZW50ZW5jZQ0KPiA+Pj4gdW5uZWNlc3NhcnkgY29tcGxpY2F0ZWQuIFdlIGRvbuKAmXQgdHJ5
IHRvIHNvbWUgaG93IGdldCBhIHJvdW5kIHRoZQ0KPiBmYWN0DQo+ID4+PiB0aGF0IHdlIG5lZWQg
dG8gaGFuZGxlIHRoZSBmbGFnIHJlZ2lzdHJhdGlvbiBjb3JyZWN0bHkuIEhvd2V2ZXIsIGhlcmUN
Cj4gdGhlDQo+ID4+PiBwb2ludCByZWFsbHkgaXMgdG8gZXhwbGFpbiBob3cgdGhlIHByb3RvY29s
IHdvcmQuIFRoZSBtYWluIHBvaW50IG9mIHVzaW5nDQo+IHRoZQ0KPiA+Pj4gd29yayDigJ5yZS11
c2XigJwgaGVyZSBpcyByZWFsbHkgdGhhdCB3ZSBzYXkgdGhhdCB0aGVzZSBmbGFncyBhcmUgb3Ig
aGF2ZSBiZWVuDQo+ID4+PiB1c2VkIGRpZmZlcmVudCBieSBvdGhlciBUQ1AgZXh0ZW5zaW9uIChh
bmQgd2UgdGhlcmVmb3JlIG5lZWQgYSBwcm9wZXINCj4gPj4+IG5lZ290aWF0aW9uIHNjaGVtZSku
DQo+ID4+IElmIHRoZSBhbGxvY2F0aW9uIG9mIGEgcmVzZXJ2ZWQgZmxhZyBpcyBjb3JyZWN0bHkg
ZXhwbGFpbmVkIGluIHRoZSBhYnN0cmFjdCBhbmQNCj4gaW50cm9kdWN0aW9uLCBJIHRoaW5rIHRo
ZXNlIHNlbnRlbmNlcyBjYW4gdXNlIGEgYml0IHJlbGF4ZWQgdGVybWlub2xvZ3kuDQo+ID4+DQo+
ID4+Pj4gICAgVGhlIHR3byBwYXJ0IGRlc2lnbiB3YXMgbmVjZXNzYXJ5LCBnaXZlbiBsaW1pdGF0
aW9ucyBvbiB0aGUgc3BhY2UNCj4gPj4+PiAgICBhdmFpbGFibGUgZm9yIFRDUCBvcHRpb25zIGFu
ZCBnaXZlbiB0aGUgcG9zc2liaWxpdHkgdGhhdCBjZXJ0YWluDQo+ID4+Pj4gICAgaW5jb3JyZWN0
bHkgZGVzaWduZWQgbWlkZGxlYm94ZXMgcHJldmVudCBUQ1AgdXNpbmcgYW55IG5ldyBvcHRpb25z
Lg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBJTUhPIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gbW9yZSBl
eHBsaWNpdGx5IG1lbnRpb24gdGhlDQo+IGRvd25zaWRlcw0KPiA+Pj4gb2Ygb25seSBzcGVjaWZ5
aW5nIGFuIG9wdGlvbiBhbmQgbm90IGFsbG9jYXRpbmcgYSBUQ1AgaGVhZGVyIGZsYWcsIGluIHRo
aXMNCj4gPj4+IGV4cGVyaW1lbnRhbCBkb2N1bWVudC4NCj4gPj4+DQo+ID4+PiBXZSBuZWVkIHRv
IHVzZSB0aGUgZmxhZ3MgKGFsbCB0aHJlZSBvZiB0aGVtKSBmb3IgdGhlIG5lZ290aWF0aW9uLg0K
PiA+PiBJIHRoaW5rIHRoYXQgYW4gZXhwbGFuYXRpb24gd2h5IG5lZ290aWF0aW9uIGJ5IGEgVENQ
IG9wdGlvbiB3b3VsZCBub3QNCj4gc29sdmUgYWxsIHVzZSBjYXNlcyAob3IgcmVxdWlyZW1lbnRz
KSB3b3VsZCBoZWxwIGhlcmUuDQo+ID4+DQo+ID4+Pj4gVGhlIG9idmlvdXMgIGFsdGVybmF0aXZl
IHdvdWxkIGJlIHRvIHBvc3Rwb25lIHRoZSBoZWFkZXIgZmxhZw0KPiBhbGxvY2F0aW9uIHRvDQo+
ID4+PiBhIGZvbGxvdy11cCBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgYW5kIGp1c3Qga2VlcCBp
dCByZXNlcnZlZC4NCj4gPj4+DQo+ID4+PiBXZSBjYW4gc3RpbGwgZG8gdGhhdC4gV2Ugc2hvdWxk
IGRpc2N1c3MgYW5kIG1ha2UgYSBmaW5hbCBkZWNpc2lvbi4NCj4gPj4+DQo+ID4+Pj4gICAgVGhl
IGVzc2VudGlhbCBwYXJ0IG92ZXJsb2FkcyB0aGUgcHJldmlvdXMgZGVmaW5pdGlvbiBvZiB0aGUg
dGhyZWUNCj4gPj4+PiAgICBmbGFncyBpbiB0aGUgVENQIGhlYWRlciB0aGF0IGhhZCBiZWVuIGFz
c2lnbmVkIGZvciB1c2UgYnkgRUNOLiAgVGhpcw0KPiA+Pj4+ICAgIGRlc2lnbiBjaG9pY2UgZGVs
aWJlcmF0ZWx5IHJlcGxhY2VzIHRoZSBjbGFzc2ljIEVDTiBmZWVkYmFjaw0KPiA+Pj4+ICAgIHBy
b3RvY29sLCByYXRoZXIgdGhhbiBsZWF2aW5nIGNsYXNzaWMgRUNOIGZlZWRiYWNrIGludGFjdCBh
bmQgYWRkaW5nDQo+ID4+Pj4gICAgbW9yZSBhY2N1cmF0ZSBmZWVkYmFjayBzZXBhcmF0ZWx5IGJl
Y2F1c2U6DQo+ID4+Pj4NCj4gPj4+PiBbbXNdIFNpbWlsYXIgbGlrZSBwcmV2aW91cyBjb21tZW50
cywgaW4gbXkgcmVhZGluZyB0aGVyZSBhcmUgb25seQ0KPiBfdHdvXw0KPiA+Pj4gRUNOIGhlYWRl
ciBmbGFncy4NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIHRoZXJlIGFyZSB0aHJlZSBmbGFncyB0aGF0
ICJoYWQgYmVlbiBhc3NpZ25lZCBmb3IgdXNlIGJ5IEVDTuKAnCBhcw0KPiBFQ04NCj4gPj4+IE5v
bmNlIGlzIGFsc28gYW4gRUNOIG1lY2hhbmlzbS4gVGhlIGZhY3QgdGhhdCBvbmUgb2YgdGhlIGZs
YWdzIGlzIG5vdw0KPiA+Pj4gbWFya2VkIGFzIHJlc2VydmVkIGluc3RlYWQsIGl0IG5vdCB0aGF0
IGltcG9ydGFudCBmb3IgbWUgaGVyZS4NCj4gPj4+DQo+ID4+Pj4gQW5kLCBpbiBhZGRpdGlvbiwg
SSB0aGluayBjYXJlIGlzIG5lZWRlZCB3aXRoIHdvcmRpbmcgc3VjaCAicmVwbGFjZXMgdGhlDQo+
ID4+PiBjbGFzc2ljIEVDTiBmZWVkYmFjayIuIEkgZG9uJ3QgdGhpbmsgdGhpcyBleHBlcmltZW50
IHJlcGxhY2VzIHRoZSBFQ04NCj4gPj4+IHN0YW5kYXJkcy4gVGhhdCB3b3VsZCBiZSB1cCB0byBh
IGZvbGxvdy11cCBQUy4NCj4gPj4+DQo+ID4+PiBUaGlzIHNlbnRlbmNlIGlzIG5vdCBtZWFudCB0
byBzYXkgdGhhdCBSRkMzMTY4IGlzIHJlcGxhY2VkLiBBY3R1YWxseSB3ZQ0KPiBkb27igJl0Lg0K
PiA+Pj4gWW91IGNhbiBzdGlsbCB1c2UgUkZDMzE2OCBldmVuIGlmIEFjY0VDTiBpcyBpbXBsZW1l
bnRlZCBhbmQgZGVwbG95DQo+ID4+PiAoaG93ZXZlciwgd2UgZG8gaW50ZW50IHRoYXQgQWNjRUNO
IHdpbGwgYmUgdXNlZCBhcyB0aGUgZGVmYXVsdCBzY2hlbWUNCj4gaW4NCj4gPj4+IGZ1dHVyZSBh
bmQgUkZDMzE2OCBpcyBob3BlZnVsbHkgc2ltcGx5IG5vdCBuZWVkZWQgYW55bW9yZSBhdCBzb21l
DQo+IHBvaW50LA0KPiA+Pj4gZXZlbiB0aG91Z2ggeW91IHByb2JhYmx5IHN0aWxsIG5lZWQgdG8g
aGF2ZSBpdCBpbXBsZW1lbnRlZCBhcyB0aGUNCj4gPj4+IG5lZ290aWF0aW9uIHNwZWNpZmllZCBp
biB0aGlzIGRyYWZ0IGNvdmVycyB0aGF0IGFzIHdlbGwsIGFueXdheS4uLikuIFRoZQ0KPiA+Pj4g
c2VudGVuY2Ugc2F5cyB0aGF0IGlmIEFjY0VDTiBpcyBuZWdvdGlhdGlvbiwgdGhlIGhlYWRlciBm
bGFncyBhcyB1c2VkIGJ5DQo+ID4+PiBSRkMzMTY4IGFuZCBwcmV2aW91c2x5IEVDTiBOb25jZSBh
cmUgdXNlZCBkaWZmZXJlbnRseSAoYWthIHJlLXVzZWQpLg0KPiBUaGF04oCZcw0KPiA+Pj4gYWxs
Lg0KPiA+Pj4+DQo+ID4+Pj4gMi4xLiAgQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbg0KPiA+Pj4+DQo+
ID4+Pj4gICAgQWNjRUNOIGlzIGEgY2hhbmdlIHRvIHRoZSB3aXJlIHByb3RvY29sIG9mIHRoZSBt
YWluIFRDUCBoZWFkZXIsDQo+ID4+Pj4gICAgdGhlcmVmb3JlIGl0IGNhbiBvbmx5IGJlIHVzZWQg
aWYgYm90aCBlbmRwb2ludHMgaGF2ZSBiZWVuIHVwZ3JhZGVkDQo+IHRvDQo+ID4+Pj4gICAgdW5k
ZXJzdGFuZCBpdC4gIFRoZSBUQ1AgY2xpZW50IHNpZ25hbHMgc3VwcG9ydCBmb3IgQWNjRUNOIG9u
IHRoZQ0KPiA+Pj4+ICAgIGluaXRpYWwgU1lOIG9mIGEgY29ubmVjdGlvbiBhbmQgdGhlIFRDUCBz
ZXJ2ZXIgc2lnbmFscyB3aGV0aGVyIGl0DQo+ID4+Pj4gICAgc3VwcG9ydHMgQWNjRUNOIG9uIHRo
ZSBTWU4vQUNLLiAgVGhlIFRDUCBmbGFncyBvbiB0aGUgU1lOIHRoYXQgdGhlDQo+ID4+Pj4gICAg
Y2xpZW50IHVzZXMgdG8gc2lnbmFsIEFjY0VDTiBzdXBwb3J0IGhhdmUgYmVlbiBjYXJlZnVsbHkg
Y2hvc2VuIHNvDQo+ID4+Pj4gICAgdGhhdCBhIFRDUCBzZXJ2ZXIgd2lsbCBpbnRlcnByZXQgdGhl
bSBhcyBhIHJlcXVlc3QgdG8gc3VwcG9ydCB0aGUNCj4gPj4+PiAgICBtb3N0IHJlY2VudCB2YXJp
YW50IG9mIEVDTiBmZWVkYmFjayB0aGF0IGl0IHN1cHBvcnRzLiAgVGhlbiB0aGUNCj4gPj4+PiAg
ICBjbGllbnQgZmFsbHMgYmFjayB0byB0aGUgc2FtZSB2YXJpYW50IG9mIEVDTiBmZWVkYmFjay4N
Cj4gPj4+Pg0KPiA+Pj4+IFttc10gQXMgdGhpcyBpcyBhbiBleHBlcmltZW50YWwgc3BlY2lmaWNh
dGlvbiwgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgYQ0KPiA+Pj4gZGlzY3Vzc2lvbiBob3cg
YSBmdXR1cmUgc3RhbmRhcmRzIHRyYWNrIHZlcnNpb24gb2YgbW9yZSBhY2N1cmF0ZSBFQ04NCj4g
Y291bGQNCj4gPj4+IGJlIG5lZ290aWF0ZWQuDQo+ID4+Pg0KPiA+Pj4gQXMgZGVzY3JpYmVkIGlu
IHRoaXMgZHJhZnQuIFRoZXJlIHdpbGwgYmUgbm8gZGlmZmVyZW50LiBBY2NFQ04gSVMgYW5kIHdp
bGwNCj4gPj4+IGFsd2F5cyBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggUkZDMzE2OC4NCj4g
Pj4gVGhhdCBpcyBub3QgdGhlIHByb2JsZW0gSSB0aGluayBhYm91dC4gSSB3b25kZXIgYWJvdXQg
YSBQUyB2ZXJzaW9uIG9mDQo+IGFjY3VyYXRlIEVDTiBmZWVkYmFjayB0aGF0IHdvdWxkIHBvc3Np
Ymx5IGluY2x1ZGUgY2hhbmdlcyBhcyBjb21wYXJlZCB0bw0KPiB0aGlzIGV4cGVyaW1lbnQsIGUu
Zy4sIGJlY2F1c2UgdGhlIGV4cGVyaW1lbnQgbWF5IGhhdmUgc29tZSBsZXNzb25zDQo+IGxlYXJu
dC4gV2hhdCBvcHRpb25zIHdvdWxkIHdlIGhhdmUgdG8gbmVnb3RpYXRlIHRoZSBQUyB2ZXJzaW9u
LCBhbmQgaG93DQo+IGNvdWxkIGEgc3RhY2sgaW1wbGVtZW50aW5nIHRoZSBQUyB2ZXJzaW9uIGZp
Z3VyZSBvdXQgd2hldGhlciB0aGUgcmVtb3RlDQo+IGVuZCB1c2VzIHRoZSBleHBlcmltZW50YWwg
b3IgdGhlIFBTIHZlcnNpb24gb2YgdGhlIHByb3RvY29sPw0KPiA+Pg0KPiA+PiBUaGUgcmVhc29u
IHdoeSBJIGFzayBpcyBiZWNhdXNlIEkgZG9uJ3Qgc2VlIGFueSBlYXN5IHNvbHV0aW9uIHRvIHRo
aXMgYnV0IEkNCj4gbWF5IG1pc3Mgc29tZXRoaW5nLiBNYXliZSB0aGlzIHdvdWxkIG5vdCBiZSBh
IGNvbmNlcm4gaWYgdGhlcmUgd2VyZSBzb21lDQo+IGNvZGVwb2ludHMgbGVmdC4NCj4gPj4NCj4g
Pj4+PiBIb3cgY291bGQgYm90aCBlbmRwb2ludHMgZGV0ZWN0IHdoZXRoZXIgdGhlIG90aGVyIG9u
ZSBpbXBsZW1lbnRzDQo+IHRoZQ0KPiA+Pj4gZnV0dXJlIHN0YW5kYXJkcyB0cmFjayB2ZXJzaW9u
Pw0KPiA+Pj4NCj4gPj4+IElmIHRoZSBpbml0aWF0b3IgaW1wbGVtZW50cyBBY2NFQ04gaXQgd2ls
bCByZXF1ZXN0IGl04oCZcyB1c2UuIElmIHRoZSByZWNlaXZlcg0KPiBhbHNvDQo+ID4+PiBpbXBs
ZW1lbnQgaXQsIGl0IHdpbGwvY2FuIG5lZ290aWF0ZSBpdCwgaWYgbm90IGl0IHdpbGwgbG9vayBs
aWtlIGFuIFJGQzMxNjgNCj4gcmVxdWVzdA0KPiA+Pj4gZm9yIHRoZSByZWNlaXZlciAoYXMgdGhl
IE5TIGZsYWdzIHdpbGwgYmUgaWdub3JlZCBpbiB0aGUgU1lOKSBhbmQgaXQgd2lsbA0KPiA+Pj4g
bmVnb3RpYXRlIFJGQzMxNjggRUNOIGZlZWRiYWNrIGlmIGltcGxlbWVudGVkLiBUaGVyZSBpcyBu
byBhZGRpdGlvbmFsDQo+ID4+PiBkZXRlY3Rpb24gbmVlZGVkLg0KPiA+PiBNeSBjb25jZXJuIGlz
IHRoZSBtaWdyYXRpb24gc3RyYXRlZ3kgZm9yIGEgZnV0dXJlIHZlcnNpb24sIGdpdmVuIHRoYXQg
d2UNCj4gb25seSBleHBlcmltZW50IHJpZ2h0IG5vdy4gRm9yIGluc3RhbmNlLCBpZiB0aGUgaW5p
dGlhdG9yIGltcGxlbWVudHMgdGhlDQo+IGV4cGVyaW1lbnRhbCB2ZXJzaW9uIGJ1dCB0aGUgcmVj
aXBpZW50IGltcGxlbWVudHMgdGhlIFBTIHZlcnNpb24gb2YgQWNjRUNOLA0KPiBob3cgd291bGQg
dGhhdCB3b3JrPyBVbmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZXJlIGFyZSBjaGFuZ2VzLCB3
b3VsZA0KPiB0aGVyZSBiZSBhIHdheSB0byBrbm93PyBNYXliZSB0aGUgYW5zd2VyIHRvIHRoaXMg
cXVlc3Rpb24gaXMgbm8sIGdpdmVuIHRoZQ0KPiBzbWFsbCBudW1iZXIgb2YgYml0cyB3ZSBoYXZl
LiBCdXQgbm90IGhhdmluZyBhbnkgcm9vbSBmb3IgZXh0ZW5zaW9ucyBpcyBub3QNCj4gbmVjZXNz
YXJpbHkgZ29vZCBwcm90b2NvbCBkZXNpZ24uDQo+ID4+DQo+ID4+Pj4gRm9yIGluc3RhbmNlLCB3
b3VsZCB0aGUgb25seSBzYWZlIHZhcmlhbnQgYmUgdGhhdCB3ZSBhbGxvY2F0ZSB5ZXQNCj4gYW5v
dGhlcg0KPiA+Pj4gcmVzZXJ2ZWQgVENQIGhlYWRlciBmbGFnIGluIGEgcHJvcG9zZWQgc3RhbmRh
cmQgdG8gbmVnb3RpYXRlIHRoZQ0KPiBzdGFuZGFyZHMNCj4gPj4+IHRyYWNrIHZlcnNpb24sIHRo
dXMgaW52ZXN0aW5nIGFub3RoZXIgcmVzZXJ2ZWQgYml0IGluIHRoZSBUQ1AgaGVhZGVyPw0KPiA+
Pj4NCj4gPj4+IE5vLCB0aGF04oCZcyBleGFjdGx5IHdoYXQgd2UgdXNlIHRoZSBOUyBmbGFncyBm
b3IgaW4gdGhlIGhhbmRzaGFrZS4NCj4gPj4gSWYgdGhlIFBTIHZlcnNpb24gb2YgQWNjRUNOIHdh
cyBkaWZmZXJlbnQgdG8gdGhlIGV4cGVyaW1lbnRhbCB2ZXJzaW9uIG9mDQo+IEFjY0VDTiwgYW5k
IGlmIHRoZXJlIHdhcyBhIGRlcGxveWVkIGJhc2Ugb2YgYm90aCwgSSBzdGlsbCBiZWxpZXZlIHdl
IGNvdWxkIGVuZA0KPiB1cCBpbiBhIHNpdHVhdGlvbiBpbiB3aGljaCB3ZSBoYWQgdG8gYWxsb2Nh
dGUgeWV0IGFub3RoZXIgVENQIGhlYWRlciBmbGFnIHRvDQo+IGRpc3Rpbmd1aXNoIHRoZSBkaWZm
ZXJlbnQgdmVyc2lvbnMgb2YgQWNjRUNOLiBUaGUgTlMgZmxhZyB3b3VsZCBub3Qgd29yayBmb3IN
Cj4gdGhhdCBpZiBpdCBpcyB1c2VkIGJ5IHRoZSBleHBlcmltZW50YWwgdmVyc2lvbi4gVGhlIHJp
c2sgb2YgaGF2aW5nIHRvIHNwZW5kDQo+IGZ1cnRoZXIgVENQIGhlYWRlciBmbGFncyBzb21laG93
IGNvbmNlcm5zIG1lLiBPZiBjb3Vyc2UsIHRoYXQgcHJvYmxlbQ0KPiB3b3VsZCBvbmx5IG1hdHRl
ciBpZiB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgc3VjY2VlZHMgc29tZWhvdywgYnV0IGxlc3NvbnMN
Cj4gbGVhcm50IHdvdWxkIHJlcXVpcmUgcHJvdG9jb2wgY2hhbmdlcywgd2hpY2ggaXMgc3BlY3Vs
YXRpb24uDQo+ID4+DQo+ID4+Pj4gSSBtYXkgYmUgd3JvbmcsIGJ1dCB0byBtZSBpdCBpcyB0b28g
ZWFybHkgdG8gc3BlY3VsYXRlIGhvdyB0aGUgUFMNCj4gdmVyc2lvbg0KPiA+Pj4gd291bGQgbG9v
ayBsaWtlLCBhbmQgd2hldGhlciBpdCB3b3VsZCBoYXZlIHRvIGJlIGRpZmZlcmVudCB0byB0aGUN
Cj4gPj4+IGV4cGVyaW1lbnRhbCB2ZXJzaW9uLCBkdWUgdG8gbGVzc29ucyBsZWFybnQuDQo+ID4+
Pg0KPiA+Pj4gT2YgY291cnNlIHlvdSBjYW4gYWx3YXlzIGJlIHdyb25nLiBIb3dldmVyLCB0aGUg
aGFuZHNoYWtlDQo+IG5lZ290aWF0aW9uIGlzDQo+ID4+PiBub3QgdGhlIHBhcnQgd2UgbmVlZCBl
eHBlcmltZW50YXRpb24gZm9yLiBUaGF0IHBhcnQgaXMgc3RyYWlnaHQgZm9yd2FyZA0KPiBhbmQN
Cj4gPj4+IHdvcmtzLiBJZiB3ZSByZWFsbHkgaGFwcGVuIHRvIGRldGVjdCBhIHByb2JsZW0gaW4g
dGhhdCBwYXJ0LCB3ZSB3b3VsZA0KPiBuZWVkDQo+ID4+PiB0byBlbmQgdGhlIGV4cGVyaW1lbnQg
ZGVjbGFyZSBmYWlsdXJlIGFuZCBzdGFydCBvdmVyIG5ldy4NCj4gPj4gTXkgY29uY2VybiBpcyBl
bmRpbmcgdGhlIGV4cGVyaW1lbnQgd2hlbiB0aGUgZXhwZXJpbWVudCBnb3QgKHBhcnRseSkNCj4g
ZGVwbG95ZWQgaW4gdGhlIEludGVybmV0LiBJbiB0aGF0IGNhc2UgbmVpdGhlciBhIG5ldyBSRkMg
bm9yIGEgY2hhbmdlIG9mIHRoZQ0KPiBJQU5BIHJlZ2lzdHJ5IHdpbGwgc29sdmUgdGhlIG1pZ3Jh
dGlvbiBpc3N1ZS4NCj4gPj4NCj4gPj4+PiBJIGJlbGlldmUgaW4gdGhlIElFVEYgd2UgdHlwaWNh
bGx5IGRlc2lnbiBwcm90b2NvbHMgdGhhdCBhbGxvdyBmdXR1cmUNCj4gPj4+IGV4dGVuc2lvbiwg
YW5kIGl0IGlzIG5vdCBleGFjdGx5IGNsZWFyIHRvIGJlIGhvdyBBY2NFQ04gY291bGQgYmUNCj4g
ZXh0ZW5kZWQNCj4gPj4+IGxhdGVyLg0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgYW4gVENQIGV4dGVu
c2lvbi4gSWYgd2Ugd2FudCBmdXR1cmUgZXh0ZW5zaW9uIHdlIHVzZSB0aGUgdXN1YWxseQ0KPiBU
Q1ANCj4gPj4+IG1lY2hhbmlzbSAoYnkgZGVmaW5pbmcgYSBuZXcgVENQIG9wdGlvbiBJIGd1ZXNz
KS4NCj4gPj4gVGhlIHJvb3QgY2F1c2Ugb2YgbXkgY29uY2VybiBpcyB0aGF0IHRoaXMgcHJvcG9z
YWwgZG9lcyAqbm90KiB1c2UgdGhlDQo+IHVzdWFsIHdheSB0byBleHBlcmltZW50IHdpdGggVENQ
IGJ5IG9wdGlvbnMuIEl0IGV4cGVyaW1lbnRzIHdpdGggYSBoZWFkZXINCj4gZmxhZywgaW5jbHVk
aW5nIGluIHRoZSBTWU4sIGFuZCBpdCBzZWVtcyB0byBjb25zdW1lIGFsbCBjb2RlcG9pbnRzLiBT
bywgSSBzZWUNCj4gdGhlIHJpc2sgb2YgYSBwcm90b2NvbCBkZXNpZ24gIm5vdCByZWFkeSBmb3Ig
ZnV0dXJlIGltcHJvdmVtZW50cyIuDQo+ID4+DQo+ID4+IEkgY2Fubm90IGVhc2lseSBwcm9wb3Nl
IHRleHQuIE1heWJlICJsYWNrIG9mIGV4dGVuc2liaWxpdHkiIGlzIGp1c3Qgb25lIG9mDQo+IHRo
ZSBzaG9ydC1jb21pbmdzIG9mIHRoZSBwcm90b2NvbCBkZXNpZ24gdGhhdCBjYW5ub3QgYmUgYXZv
aWRlZCBidXQgdGhhdA0KPiBzaG9ydC1jb21pbmcgd291bGQgaGF2ZSB0byBiZSBub3RlZC4NCj4g
Pj4NCj4gPj4+PiAgICBBbiBBY2NFQ04gVENQIGNsaWVudCBkb2VzIG5vdCBzZW5kIHRoZSBuZXcg
QWNjRUNOIE9wdGlvbiBvbiB0aGUNCj4gU1lODQo+ID4+Pj4gICAgYXMgU1lOIG9wdGlvbiBzcGFj
ZSBpcyBsaW1pdGVkIGFuZCBzdWNjZXNzZnVsIG5lZ290aWF0aW9uIHVzaW5nIHRoZQ0KPiA+Pj4+
ICAgIGZsYWdzIGluIHRoZSBtYWluIGhlYWRlciBpcyB0YWtlbiBhcyBzdWZmaWNpZW50IGV2aWRl
bmNlIHRoYXQgYm90aA0KPiA+Pj4+ICAgIGVuZHMgYWxzbyBzdXBwb3J0IHRoZSBBY2NFQ04gT3B0
aW9uLiAgVGhlIFRDUCBzZXJ2ZXIgc2VuZHMgdGhlDQo+IEFjY0VDTg0KPiA+Pj4+ICAgIE9wdGlv
biBvbiB0aGUgU1lOL0FDSyBhbmQgdGhlIGNsaWVudCBzZW5kcyBpdCBvbiB0aGUgZmlyc3QgQUNL
IHRvDQo+ID4+Pj4gICAgdGVzdCB3aGV0aGVyIHRoZSBuZXR3b3JrIHBhdGggZm9yd2FyZHMgdGhl
IG9wdGlvbiBjb3JyZWN0bHkuDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIEZvciB3aGF0IGl0IGlzIHdv
cnRoLCBJIHdvdWxkIHBlcnNvbmFsbHkgYmUgcXVpdGUgZmluZSB3aXRoIGFsbG93aW5nDQo+IChv
cg0KPiA+Pj4gZXZlbiBtYW5kYXRpbmcpIGFuIG9wdGlvbiBpbiB0aGUgU1lOIGluIHRoZSBleHBl
cmltZW50YWwgdmVyc2lvbiBvZiB0aGlzDQo+ID4+PiBwcm90b2NvbC4gRm9yIGluc3RhbmNlLCBz
YXZpbmcgdGhlIFNZTiBvcHRpb24gc3BhY2Ugd291bGQgdGhlbiBhbg0KPiBleGNlbGxlbnQNCj4g
Pj4+IHJlYXNvbiBmb3IgbW92aW5nIHRvd2FyZHMgdGhlIFBTIHNwZWNpZmljYXRpb24uIEkgYW0g
YWxzbyBmaW5lIHdpdGggYmVpbmcNCj4gaW4NCj4gPj4+IHRoZSByb3VnaCBwYXJ0IG9mIHRoZSBj
b25zZW5zdXMgaGVyZS4NCj4gPj4+DQo+ID4+PiBUaGUgcG9pbnQgaXMgdGhhdCB3ZSByZWFsbHkg
ZG9u4oCZdCBuZWVkIHRoZSBvcHRpb24gaW4gdGhlIFNZTiBhcyB3ZSBkb27igJl0DQo+IHVzZSBp
dA0KPiA+Pj4gZm9yIG5lZ290aWF0aW9uIHB1cnBvc2VzIGFzIHdlIHVzZSB0aGUgaGVhZGVyIGJp
dHMgaW5zdGVhZC4gU28gd2h5DQo+IHNob3VsZA0KPiA+Pj4gd2Ugd2FzdGUgdGhlIHNwYWNlPw0K
PiA+PiBGb3IgaW5zdGFuY2UsIG1hbmRhdGluZyB0aGUgb3B0aW9uIGluIHRoZSBTWU4gd291bGQg
YmUgYXdheSBmb3IgdGhlDQo+IHJlY2VpdmVyIHRvIGRpc3Rpbmd1aXNoIHRoZSBleHBlcmltZW50
IGZyb20gYSBmb2xsb3ctdXAgUFMgdmVyc2lvbiBvZiB0aGUNCj4gc3BlYywgYXMgdGhlIFBTIHZl
cnNpb24gbWF5IG5vdCBtYW5kYXRlIHRoZSBvcHRpb24sIHRvIHNhdmUgaGVhZGVyIHNwYWNlLg0K
PiA+Pg0KPiA+PiBNYXliZSB0aGF0IHByb3Bvc2FsIGRvZXMgbm90IG1ha2UgYW55IHNlbnNlLCBh
bmQgaXQgbWF5IG9ubHkgaGF2ZQ0KPiBkb3duc2lkZXMuIEJ1dCB0aGUgZG9jdW1lbnQgYWxyZWFk
eSBzcGVjdWxhdGVzIGFib3V0IGEgUFMtZm9sbG93LXVwLiBTbyBpdA0KPiBzZWVtcyBhIHZhbGlk
IHF1ZXN0aW9uIHRvIGFzayBpZiB0aGUgRVhQIGFuZCB0aGUgUFMgdmVyc2lvbiBvZiB0aGUgc3Bl
YyBoYXZlDQo+IHRvIGJlIGlkZW50aWNhbC4gVGhpcyBhbGwgY29tZXMgZG93biB0byB0aGUgU1lO
IG5lZ290aWF0aW9uLg0KPiA+Pg0KPiA+Pj4+ICogMi4zLiAgRGVsYXllZCBBQ0tzIGFuZCBSZXNp
bGllbmNlIEFnYWluc3QgQUNLIExvc3MNCj4gPj4+Pg0KPiA+Pj4+ICAgIElmIHRoZSBBY2NFQ04g
T3B0aW9uIGlzIG5vdCBhdmFpbGFibGUsIGUuZy4gaXQgaXMgYmVpbmcgc3RyaXBwZWQgYnkgYQ0K
PiA+Pj4+ICAgIG1pZGRsZWJveCwgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIG9ubHkgZmVlZCBi
YWNrIGluZm9ybWF0aW9uIG9uIENFDQo+ID4+Pj4gICAgbWFya2luZ3MgKHVzaW5nIHRoZSBBQ0Ug
ZmllbGQpLiAgQWx0aG91Z2ggbm90IGlkZWFsLCB0aGlzIHdpbGwgYmUNCj4gPj4+PiAgICBzdWZm
aWNpZW50LCBiZWNhdXNlIGl0IGlzIGVudmlzYWdlZCB0aGF0IG5laXRoZXIgRUNUKDApIG5vciBF
Q1QoMSkNCj4gPj4+PiAgICB3aWxsIGV2ZXIgaW5kaWNhdGUgbW9yZSBzZXZlcmUgY29uZ2VzdGlv
biB0aGFuIENFLCBldmVuIHRob3VnaA0KPiBmdXR1cmUNCj4gPj4+PiAgICB1c2VzIGZvciBFQ1Qo
MCkgb3IgRUNUKDEpIGFyZSBzdGlsbCB1bmNsZWFyDQo+ID4+Pj4gICAgW0ktRC5pZXRmLXRzdndn
LWVjbi1leHBlcmltZW50YXRpb25dLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBUaGlzIG5lZWRzIHRv
IGJlIHJld29yZGVkDQo+ID4+PiBXaHk/DQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAq
IDIuNC4gIEZlZWRiYWNrIE1ldHJpY3MNCj4gPj4+Pg0KPiA+Pj4+ICAgIFRoZSBDRSBwYWNrZXQg
Y291bnRlciBpbiB0aGUgQUNFIGZpZWxkIGFuZCB0aGUgQ0UgYnl0ZSBjb3VudGVyIGluIHRoZQ0K
PiA+Pj4+ICAgIEFjY0VDTiBPcHRpb24gYm90aCBwcm92aWRlIGZlZWRiYWNrIG9uIHJlY2VpdmVk
IENFLW1hcmtzLiAgVGhlIENFDQo+ID4+Pj4gICAgcGFja2V0IGNvdW50ZXIgaW5jbHVkZXMgY29u
dHJvbCBwYWNrZXRzIHRoYXQgZG8gbm90IGhhdmUgcGF5bG9hZA0KPiA+Pj4+ICAgIGRhdGEsIHdo
aWxlIHRoZSBDRSBieXRlIGNvdW50ZXIgc29sZWx5IGluY2x1ZGVzIG1hcmtlZCBwYXlsb2FkIGJ5
dGVzLg0KPiA+Pj4+ICAgIElmIGJvdGggYXJlIHByZXNlbnQsIHRoZSBieXRlIGNvdW50ZXIgaW4g
dGhlIG9wdGlvbiB3aWxsIHByb3ZpZGUgdGhlDQo+ID4+Pj4gICAgbW9yZSBhY2N1cmF0ZSBpbmZv
cm1hdGlvbiBuZWVkZWQgZm9yIG1vZGVybiBjb25nZXN0aW9uIGNvbnRyb2wNCj4gYW5kDQo+ID4+
Pj4gICAgcG9saWNpbmcgc2NoZW1lcywgc3VjaCBhcyBEQ1RDUCBvciBDb25FeC4NCj4gPj4+Pg0K
PiA+Pj4+IFttc10gSSBzdWdnZXN0IHRvIHdyaXRlIGluIHRoZSBsYXN0IHNlbnRlbmNlIG9ubHkg
Ii4uLiB0aGUgb3B0aW9uIHdpbGwNCj4gcHJvdmlkZQ0KPiA+Pj4gdGhlIG1vcmUgYWNjdXJhdGUg
aW5mb3JtYXRpb24gbmVlZGVkIGZvciBjb25nZXN0aW9uIGNvbnRyb2wiLiBJbg0KPiBnZW5lcmFs
LCBJDQo+ID4+PiB3b3VsZCBwcmVmZXIgdG8gaGF2ZSByZWZlcmVuY2VzIHRvIG90aGVyIG1lY2hh
bmlzbXMgYXQgb25seSBmZXcNCj4gKGlkZWFsbHkgYQ0KPiA+Pj4gKnNpbmdsZSopIHBsYWNlcyBp
biB0aGUgZG9jdW1lbnQsIGluc3RlYWQgb2YgbWl4aW5nIHRoZW0gdG9nZXRoZXIuDQo+ID4+Pg0K
PiA+Pj4gU29ycnksIEkgZG9u4oCZdCBzZWUgeW91ciBwb2ludCBoZXJlLiBDb25FeCBoYXMgYmVl
biBtZW50aW9uZWQNCj4gcHJldmlvdXNseSwgc28NCj4gPj4+IHdoeSBub3QgYWxzbyBtZW50aW9u
IGl0IGhlcmUuDQo+ID4+IEFzIHdyaXR0ZW4gZWFybGllciwgaW4gbXkgdW5kZXJzdGFuZGluZyBE
Q1RDUCBkb2VzIG5vdCAibmVlZCIgdGhpcy4gSQ0KPiB3b3VsZCBzdWdnZXN0IHRvIGhhdmUgb25l
IHBsYWNlIHdoZXJlIHRvIGRlZmluZSBleGFjdGx5IGhvdyB0aGlzDQo+IG1lY2hhbmlzbSBjYW4g
YmUgdXNlZCBieSBvdGhlciBUQ1AgZXh0ZW5zaW9ucy4gSGF2aW5nIHNhaWQgdGhpcywgaW4gdGhp
cw0KPiBzcGVjaWZpYyBwYXJhZ3JhcGggSSBhbSBsZXNzIGNvbmNlcm5lZCBhYm91dCB0aGF0IHRo
YW4gZWxzZXdoZXJlLg0KPiA+Pg0KPiA+Pj4+ICAgIEZlZWRiYWNrIGluIGJ5dGVzIGlzIHJlY29t
bWVuZGVkIGluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGUNCj4gPj4+PiAgICByZWNlaXZl
ciB1c2luZyBhdHRhY2tzIHNpbWlsYXIgdG8gJ0FDSy1EaXZpc2lvbicgdG8gYXJ0aWZpY2lhbGx5
DQo+ID4+Pj4gICAgaW5mbGF0ZSB0aGUgY29uZ2VzdGlvbiB3aW5kb3csIHdoaWNoIGlzIHdoeSBb
UkZDNTY4MV0gbm93DQo+IHJlY29tbWVuZHMNCj4gPj4+PiAgICB0aGF0IFRDUCBjb3VudHMgYWNr
bm93bGVkZ2VkIGJ5dGVzIG5vdCBwYWNrZXRzLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBBdCBsZWFz
dCB0aGUgbGFzdCBwYXJ0IGFuZCB0aGUgcmVmZXJlbmNlIHRvIFJGQyA1NjgxIGlzIElNSE8gbm90
DQo+ID4+PiBuZWVkZWQgaGVyZS4NCj4gPj4+DQo+ID4+PiBXaHk/IFJGQzU2ODEgZXhwbGFpbnMv
cmVmZXJzIHRoZSBBQ0sgZGl2aXNpb24gYXR0YWNrLCBzbyBJIHRoaW5rIGl0IGlzIGENCj4gdmVy
eQ0KPiA+Pj4gZ29vZCByZWZlcmVuY2UgdG8gaGF2ZSBoZXJlLg0KPiA+Pj4+DQo+ID4+Pj4NCj4g
Pj4+PiAqIDIuNS4gIEdlbmVyaWMgKER1bWIpIFJlZmxlY3Rvcg0KPiA+Pj4+DQo+ID4+Pj4gICAg
VGhlIEFDRSBmaWVsZCBwcm92aWRlcyBpbmZvcm1hdGlvbiBhYm91dCBDRSBtYXJraW5ncyBvbiBi
b3RoIGRhdGENCj4gYW5kDQo+ID4+Pj4gICAgY29udHJvbCBwYWNrZXRzLiAgQWNjb3JkaW5nIHRv
IFtSRkMzMTY4XSB0aGUgRGF0YSBTZW5kZXIgaXMgbWVhbnQgdG8NCj4gPj4+PiAgICBzZXQgY29u
dHJvbCBwYWNrZXRzIHRvIE5vdC1FQ1QuICBIb3dldmVyLCBtZWNoYW5pc21zIGluIGNlcnRhaW4N
Cj4gPj4+PiAgICBwcml2YXRlIG5ldHdvcmtzIChlLmcuIGRhdGEgY2VudHJlcykgc2V0IGNvbnRy
b2wgcGFja2V0cyB0byBiZSBFQ04NCj4gPj4+PiAgICBjYXBhYmxlIGJlY2F1c2UgdGhleSBhcmUg
cHJlY2lzZWx5IHRoZSBwYWNrZXRzIHRoYXQgcGVyZm9ybWFuY2UNCj4gPj4+PiAgICBkZXBlbmRz
IG9uIG1vc3QuDQo+ID4+Pj4NCj4gPj4+PiAgICBGb3IgdGhpcyByZWFzb24sIEFjY0VDTiBpcyBk
ZXNpZ25lZCB0byBiZSBhIGdlbmVyaWMgcmVmbGVjdG9yIG9mDQo+ID4+Pj4gICAgd2hhdGV2ZXIg
RUNOIG1hcmtpbmdzIGl0IHNlZXMsIHdoZXRoZXIgb3Igbm90IHRoZXkgYXJlIGNvbXBsaWFudA0K
PiB3aXRoDQo+ID4+Pj4gICAgYSBjdXJyZW50IHN0YW5kYXJkLiAgVGhlbiBhcyBzdGFuZGFyZHMg
ZXZvbHZlLCBEYXRhIFNlbmRlcnMgY2FuDQo+ID4+Pj4gICAgdXBncmFkZSB1bmlsYXRlcmFsbHkg
d2l0aG91dCBhbnkgbmVlZCBmb3IgcmVjZWl2ZXJzIHRvIHVwZ3JhZGUgdG9vLg0KPiA+Pj4+ICAg
IEl0IGlzIGFsc28gdXNlZnVsIHRvIGJlIGFibGUgdG8gcmVseSBvbiBnZW5lcmljIHJlZmxlY3Rp
b24gYmVoYXZpb3VyDQo+ID4+Pj4gICAgd2hlbiBzZW5kZXJzIG5lZWQgdG8gdGVzdCBmb3IgdW5l
eHBlY3RlZCBpbnRlcmZlcmVuY2Ugd2l0aA0KPiBtYXJraW5ncw0KPiA+Pj4+ICAgIChmb3IgaW5z
dGFuY2UgW0ktRC5rdWVobGV3aW5kLXRjcG0tZWNuLWZhbGxiYWNrXSBhbmQNCj4gPj4+PiAgICBb
SS1ELm1vbmNhc3Rlci10Y3BtLXJjdi1jaGVhdF0pLg0KPiA+Pj4+DQo+ID4+Pj4gICAgVGhlIGlu
aXRpYWwgU1lOIGlzIHRoZSBtb3N0IGNyaXRpY2FsIGNvbnRyb2wgcGFja2V0LCBzbyBBY2NFQ04N
Cj4gPj4+PiAgICBwcm92aWRlcyBmZWVkYmFjayBvbiB3aGV0aGVyIGl0IGlzIENFIG1hcmtlZC4g
IEFsdGhvdWdoIFJGQyAzMTY4DQo+ID4+Pj4gICAgcHJvaGliaXRzIGFuIEVDTi1jYXBhYmxlIFNZ
TiwgcHJvdmlkaW5nIGZlZWRiYWNrIG9mIENFIG1hcmtpbmcgb24NCj4gdGhlDQo+ID4+Pj4gICAg
U1lOIHN1cHBvcnRzIGZ1dHVyZSBzY2VuYXJpb3MgaW4gd2hpY2ggU1lOcyBtaWdodCBiZSBFQ04t
ZW5hYmxlZA0KPiA+Pj4+ICAgICh3aXRob3V0IHByZWp1ZGdpbmcgd2hldGhlciB0aGV5IG91Z2h0
IHRvIGJlKS4gIEZvciBpbnN0YW5jZSwNCj4gPj4+PiAgICBbSS1ELmlldGYtdHN2d2ctZWNuLWV4
cGVyaW1lbnRhdGlvbl0gdXBkYXRlcyB0aGlzIGFzcGVjdCBvZiBSRkMgMzE2OA0KPiA+Pj4+ICAg
IHRvIGFsbG93IGV4cGVyaW1lbnRhdGlvbiB3aXRoIEVDTi1jYXBhYmxlIFRDUCBjb250cm9sIHBh
Y2tldHMuDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIFRvIG1lLCB0aGUgb25seSB0aGluZyB0aGF0IG1h
dHRlcnMgaW4gdGhpcyBkb2N1bWVudCB0aGF0IEFjY0VDTg0KPiBjYW4NCj4gPj4+IHByb3ZpZGUg
ZmVlZGJhY2sgb24gd2hldGhlciB0aGUgU1lOIGlzIENFIG1hcmtlZC4gVGhlIGRpc2N1c3Npb24g
b24NCj4gaG93DQo+ID4+PiB0byBleHBlcmltZW50IHdpdGggRUNUIGUuZy4gaW4gU1lOcyBJTUhP
IGRvZXMgbm90IGJlbG9uZyBpbnRvIHRoaXMNCj4gPj4+IGRvY3VtZW50LiBTbyBpdCBzZWVtcyBz
dWZmaWNpZW50IGhlcmUgdG8gbm90ZSB0aGF0IG9uZSBvZiB0aGUgYmVuZWZpdHMNCj4gb2YNCj4g
Pj4+IEFjY0VDTiBpcyB0aGF0IENFIG1hcmtzIGluIFNZTnMgY2FuIGJlIGZlZCBiYWNrLg0KPiA+
Pj4NCj4gPj4+IEkgZGlzYWdyZWUuIEV4cGxpY2l0bHkgc2F5aW5nIHRoYXQgQWNjRUNOIGlzIG9u
bHkgYW4gZmVlZGJhY2sgc2NoZW1lIGFuZA0KPiBET0VTDQo+ID4+PiBOT1QgZGVmaW5lIGhvdyB0
aGUgaW5mb3JtYXRpb24gaXMgdXNlZCBpcyBWRVJZIGltcG9ydGFudCBiZWNhdXNlDQo+IHBlb3Bs
ZQ0KPiA+Pj4gY29tZSBiYWNrIHRvIG1lIG92ZXIgYW5kIG92ZXIgYWdhaW4gYW5kIG1peCB0aGVz
ZSB0aGluZ3MgdXAuDQo+ID4+Pj4NCj4gPj4+PiAqIDMuMS4xLiAgTmVnb3RpYXRpb24gZHVyaW5n
IHRoZSBUQ1AgaGFuZHNoYWtlDQo+ID4+Pj4NCj4gPj4+PiAgICBHaXZlbiB0aGUgRUNOIE5vbmNl
IFtSRkMzNTQwXSBpcyBiZWluZyByZWNsYXNzaWZpZWQgYXMgaGlzdG9yaWMsIHRoZQ0KPiA+Pj4+
ICAgIHByZXNlbnQgc3BlY2lmaWNhdGlvbiByZW5hbWVzIHRoZSBUQ1AgZmxhZyBhdCBiaXQgNyBv
ZiB0aGUgVENQIGhlYWRlcg0KPiA+Pj4+ICAgIGZsYWdzIGZyb20gTlMgKE5vbmNlIFN1bSkgdG8g
QUUgKEFjY3VyYXRlIEVDTikgKHNlZSBJQU5BDQo+ID4+Pj4gICAgQ29uc2lkZXJhdGlvbnMgaW4g
U2VjdGlvbiA2KS4NCj4gPj4+Pg0KPiA+Pj4+IFttc10gQXMgbWVudGlvbmVkIGJlZm9yZSwgdGhp
cyBuZWVkcyB0byBiZSByZXdyaXR0ZW4gdG8gYXNrIGZvciBuZXcNCj4gSUFOQQ0KPiA+Pj4gYWxs
b2NhdGlvbiBvZiBiaXQgNyBpbiB0aGUgVENQIGhlYWRlciBmbGFncy4NCj4gPj4+DQo+ID4+PiBJ
IHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50LiBUaGF0IGlzIHdoYXQgdGhl
IElBTkEgc2VjdGlvbg0KPiBkb2VzDQo+ID4+PiBhcyByZWZlcnJlZCBoZXJlIGNvcnJlY3RseS4N
Cj4gPj4gSW4gbXkgcmVhZGluZyBvZiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy90
Y3AtaGVhZGVyLQ0KPiBmbGFncy90Y3AtaGVhZGVyLWZsYWdzLnhodG1sLCB0aGlzIGZsYWcgY3Vy
cmVudGx5IGhhcyBubyBuYW1lLCBpLmUuLCBpdCBkb2VzIG5vdA0KPiBoYXZlIHRoZSBuYW1lIE5T
LiBTbyB0aGlzIHN0YXRlbWVudCBvbiAicmVuYW1pbmciIGlzIGZvcm1hbGx5IGluY29ycmVjdA0K
PiBJTUhPLg0KPiA+Pg0KPiA+PiBJJ2Qgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZTogIlRoaXMgc3Bl
Y2lmaWNhdGlvbiBhc3NpZ25zIHRoZSBuYW1lIEFFDQo+IChBY2N1cmF0ZSBFQ04pIHRvIHRoZSBU
Q1AgZmxhZyBhdCBiaXQgNzsgdGhpcyBmbGFnIGhhcyBwcmV2aW91c2x5IGJlZW4ga25vd24gYXMN
Cj4gTlMgKE5vbmNlIFN1bSkg4oCmIi4NCj4gPiBOb3c6DQo+ID4NCj4gPiAiR2l2ZW4gdGhlIEVD
TiBOb25jZSA8eHJlZiB0YXJnZXQ9IlJGQzM1NDAiLz4gaGFzIGJlZW4NCj4gPiAgICAgICAgICAg
IHJlY2xhc3NpZmllZCBhcyBoaXN0b3JpYyA8eHJlZiB0YXJnZXQ9IlJGQzgzMTEiLz4sIHRoZSBw
cmVzZW50DQo+IAkgIHNwZWNpZmljYXRpb24gcmUtYWxsb2NhdGVzIHRoZSBUQ1ANCj4gPiAgICAg
ICAgICAgIGZsYWcgYXQgYml0IDdvZiB0aGUgVENQIGhlYWRlciBmbGFncywgd2hpY2ggd2FzIHBy
ZXZpb3VzbHkgY2FsbGVkIE5TDQo+ID4gICAgICAgICAgICAoTm9uY2UgU3VtKSwgYXMgdGhlIEFF
DQo+ID4gICAgICAgICAgICAoQWNjdXJhdGUgRUNOKSBmbGFnIChzZWUgSUFOQSBDb25zaWRlcmF0
aW9ucyBpbiA8eHJlZg0KPiA+ICAgICAgICAgICAgdGFyZ2V0PSJhY2NlY25fSUFOQV9Db25zaWRl
cmF0aW9ucyIvPikuIg0KPiA+Pj4gQWdhaW4sIHllcywgd2UgY2FuIGRpc2N1c3MgaWYgdGhpcyBk
b2N1bWVudCBzaG91bGQgZG8gdGhpcywgYnV0IGlmDQo+IHB1Ymxpc2hlZCBhcw0KPiA+Pj4gaXQg
aXMsIHNlY3Rpb24gNiBzYXlzIGV2ZXJ5dGhpbmcgdGhhdCBpcyBuZWVkcyB0byBzYXkuIChJIGRv
ZXMgbm90IHB1dCBhbnkNCj4gPj4+IHJlcXVlc3Qgb24gSUFOQSwgaW5zdGVhZCBpdCBpcyB3cml0
dGVuIGFzIGl0IHdvdWxkIHNob3cgdXAgcG9zdC0NCj4gcHVibGljYXRpb24sDQo+ID4+PiBpbXBs
aWNpdGx5IHByb3ZpZGluZyBhIHJlcXVlc3QgdG8gSUFOQSBhdCBhcHByb3ZhbCB0aW1lLiBUaGF0
IGlzIGZpbmUuKQ0KPiA+Pj4NCj4gPj4+PiAgICBUYWJsZSAyOiBFQ04gY2FwYWJpbGl0eSBuZWdv
dGlhdGlvbiBiZXR3ZWVuIENsaWVudCAoQSkgYW5kIFNlcnZlcg0KPiA+Pj4+IChCKQ0KPiA+Pj4+
DQo+ID4+Pj4gW21zXSBBcyBmYXIgYXMgSSBjYW4gc2VlLCBpbiAtMDUgdGhpcyB0YWJsZSBhbGxv
Y2F0ZXMgYWxsIGV4aXN0aW5nIGNvZGVwb2ludHMsDQo+ID4+PiB3aGlsZSAtMDMgaGFkIHR3byBj
dXJyZW50bHkgdW51c2VkIGNvZGVwb2ludHMuIE5vdCBoYXZpbmcgYW55DQo+IGNvZGVwb2ludHMN
Cj4gPj4+IGxlZnQgc2VlbXMgdG8gbWUgbm90IHJlYWxseSBmdXR1cmUgcHJvb2YsIGUuZy4sIHJl
Z2FyZGluZyBmdXR1cmUgcHJvcG9zZWQNCj4gPj4+IHN0YW5kYXJkcyBpbiB0aGlzIHNwYWNlIChh
bmQgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCBUQ1AgaGVhZGVyIGZsYWdzDQo+IG11c3QNCj4g
Pj4+IGJlIGFsbG9jYXRlZCBpbiBhIFBTKS4gQW5kIEkgZG9uJ3QgZnVsbHkgc2VlIGEgbmVlZCBv
ZiBmZWVkaW5nIGJhY2sgRUNUMA0KPiBhbmQNCj4gPj4+IHNwZWNpZmljYWxseSBFQ1QxIGluIHRo
ZSBUQ1AgaGVhZGVyIGZsYWdzIGFzIHBhcnQgb2YgdGhlIGV4cGVyaW1lbnQuIERvDQo+IHdlDQo+
ID4+PiBrbm93IGZvciBzdXJlIHRoYXQgdGhpcyBpcyB0aGUgb25seSBwb3NzaWJsZSB1c2UgY2Fz
ZSBvZiB0aGVzZSB0d28NCj4gdW5hbGxvY2F0ZWQNCj4gPj4+IGhlYWRlciBiaXRzPyBBbmQgd2h5
IGNhbid0IGUuZy4gdGhpcyBiZSBkb25lIGluIGEgVENQIG9wdGlvbiBpbnN0ZWFkPyBPcg0KPiBk
byBJDQo+ID4+PiBtaXNzIHNvbWV0aGluZz8NCj4gPj4+DQo+ID4+PiBUaGUgcG9pbnQgaXMgcmVh
bGx5LCBpZiB3ZSBkb27igJl0IGFzc2lnbiB0aGVtIG5vdyBhbmQgc3RhcnQgZGVwbG95bWVudCB3
ZQ0KPiA+Pj4gZWZmZXRlbHkgd2Ugbm90IGJlIGFibGUgdG8gZXZlcnkgYXNzaWduIHRoZW0gYWdh
aW4gYmVjYXVzZSBkb27igJl0IGhhdmUgYQ0KPiA+Pj4gZGlmZmVyZW50IG5lZ290aWF0aW9uIG1l
Y2hhbmlzbXMuIFJlYWxpemluZyB0aGlzLCBpdCBpcyBqdXN0IHRoZSByaWdodCB0aGluaw0KPiB0
bw0KPiA+Pj4gZGVmaW5lIHRoZSBzcGFjZSBjb21wbGV0ZWx5IHRoYXQgaXMgbmVnb3RpYXRlZCBh
cyB1c2UgZm9yIEFjY0VDTiBpbiB0aGUNCj4gPj4+IGhhbmRzaGFrZS4NCj4gPj4gSSBkaXNhZ3Jl
ZSB0aGF0IGNvbnN1bWluZyBhbGwgY29kZXBvaW50cyBhbmQgbm90IGhhdmluZyByb29tIGZvciBm
dXR1cmUNCj4gZXh0ZW5zaW9ucyBpcyB0aGUgInJpZ2h0IHRoaW5nIiB0byBkby4gSXQgaXMgaW4g
ZmFjdCB0aGUgd3JvbmcgdGhpbmcuIEJ1dCBwb3NzaWJseQ0KPiB0aGVyZSBpcyBubyBhbHRlcm5h
dGl2ZSB3aXRoIHRoZSBmZXcgYml0cywgc28gbWF5YmUgd2UgZW5kIHVwIGRvaW5nIGl0Lg0KPiA+
Pg0KPiA+PiBZZXQsIGF0IG1pbmltdW0sIHVzaW5nIGFsbCBjb2RlcG9pbnRzIG5lZWRzIHRvIGJl
IHJlYXNvbmVkIGluIHRoZQ0KPiBkb2N1bWVudC4gU3BlY2lmaWNhbGx5IHNpbmNlIGluIC0wMyBh
IGRpZmZlcmVudCBwcm90b2NvbCBkZXNpZ24gc2VlbWVkDQo+IHBvc3NpYmxlLCB3aGljaCBsb29r
ZWQgdG8gbWUgbW9yZSBmdXR1cmUtcHJvb2YuDQo+ID4+DQo+ID4+Pj4gKiAzLjEuMi4gIFJldHJh
bnNtaXNzaW9uIG9mIHRoZSBTWU4NCj4gPj4+Pg0KPiA+Pj4+ICAgIEhvd2V2ZXIsDQo+ID4+Pj4g
ICAgY3VycmVudCBtZWFzdXJlbWVudHMgaW1wbHkgdGhhdCBhIGRyb3AgaXMgbGVzcyBsaWtlbHkg
dG8gYmUgZHVlIHRvDQo+ID4+Pj4gICAgbWlkZGxlYm94IGludGVyZmVyZW5jZSB0aGFuIG90aGVy
IGludGVybWl0dGVudCBjYXVzZXMgb2YgbG9zcywgZS5nLg0KPiA+Pj4+ICAgIGNvbmdlc3Rpb24s
IHdpcmVsZXNzIGludGVyZmVyZW5jZSwgZXRjLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBTdWNoIHdv
cmRpbmcgSU1ITyBkb2Vzbid0IGJlbG9uZyBpbnRvIG5vcm1hdGl2ZSB0ZXh0LiBUaGlzIG1heQ0K
PiA+Pj4gYWN0dWFsbHkgYWxzbyBhcHBseSB0byBvdGhlciBoZXVyaXN0aWNzIGRpc2N1c3NlZCBp
biB0aGlzIHNlY3Rpb24sIHdoaWNoIGFyZQ0KPiBub3QNCj4gPj4+IHJlYWxseSBpbXBvcnRhbnQg
Zm9yIGludGVyb3BlcmFiaWxpdHkuDQo+ID4+Pg0KPiA+Pj4gSSBkb27igJl0IHJlYWxseSB1bmRl
cnN0YW5kIHlvdXIgcG9pbnQuIFRoaXMgc2VudGVuY2UgaXMgc29sZWx5IG1lYW50IHRvDQo+IHJl
YXNvbg0KPiA+Pj4gdGhlIGRlc2lnbiBkZWNpc2lvbiB0byBub3Qgc2F5IHRoYXQgYSBzZW5kZXIg
U0hPVUxEIGF0dGVtcHQgdG8gcmUtDQo+ID4+PiBuZWdvdGlhdGlvbiBhZnRlciBhIGxvc3MuDQo+
ID4+IE9uZSBjb3VsZCBzcGxpdCB0aGUgcmVhc29uaW5nIGZyb20gdGhlIG5vcm1hdGl2ZSBkZXNp
Z24uIFRoZSBub3JtYXRpdmUNCj4gc3BlY2lmaWNhdGlvbiBtYXkgc3RpbGwgYmUgcmVsZXZhbnQg
aW4gMjAgeWVhcnMgZnJvbSBub3cuIE1pZGRsZWJveGVzIHdpbGwNCj4gYWxtb3N0IGxpa2VseSBi
ZSBkaWZmZXJlbnQgaW4gMjAgeWVhcnMuIEhhdmluZyBzYWlkIHRoaXMsIHRoaXMgaXMgbW9yZSBv
ZiBhbg0KPiBlZGl0b3JpYWwgcmVtYXJrLg0KPiA+Pg0KPiA+Pj4+IDMuMi43LiAgUGF0aCBUcmF2
ZXJzYWwgb2YgdGhlIEFjY0VDTiBPcHRpb24NCj4gPj4+Pg0KPiA+Pj4+IDMuMi43LjEuICBUZXN0
aW5nIHRoZSBBY2NFQ04gT3B0aW9uIGR1cmluZyB0aGUgSGFuZHNoYWtlDQo+ID4+Pj4NCj4gPj4+
PiAgICBUaGUgVENQIGNsaWVudCBNVVNUIE5PVCBpbmNsdWRlIHRoZSBBY2NFQ04gVENQIE9wdGlv
biBvbiB0aGUgU1lOLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBJIGFtIG5vdCBzdXJlIGlmIEkgcmVh
bGx5IHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gZm9yIG5vdCBhbGxvd2luZw0KPiBhDQo+ID4+
PiBvcHRpb24gaW4gdGhlIFNZTi4gSWYgdGhlIHNlbmRlciBoYXMgc3BhY2UgaW4gdGhlIFNZTiBs
ZWZ0LCB3aGF0IGlzIHRoZQ0KPiBoYXJtIGluDQo+ID4+PiBhbiBleHBlcmltZW50YWwgdmVyc2lv
biBvZiB0aGUgcHJvdG9jb2w/IEFuZCBJIG1heSBtaXNzIHNvbWV0aGluZywgYnV0DQo+ID4+PiB3
aGF0IHdvdWxkIHByZXZlbnQgdGhlIHVzZSBvZiAyLWJ5dGUgb3B0aW9uIHRvIG5lZ290aWF0ZSB0
aGUgdXNlIG9mDQo+ID4+PiBBY2NFQ04sIGUuZy4sIHRvIGF2b2lkIGV4cGVyaW1lbnRhbCBhbGxv
Y2F0aW9uIG9mIGJpdCA3IGluIHRoZSBpbml0aWFsIFNZTj8NCj4gPj4+DQo+ID4+PiBJIGRpZCBo
YXZlIGEgZHJhZnQgb24gdGhhdCBhcyBhIHByb3Bvc2FsIGZvciBhbiBhbHRlcm5hdGl2ZSBkZXNp
Z24uDQo+IEhvd2V2ZXIsDQo+ID4+PiB0aGUgZ291cmQgd2FzIG1vcmUgc3VwcG9ydGl2ZSBvZiB0
aGlzIGRlc2lnbiBhcyBpdCBpcyBwcm9vZiBvZiBtaWRkbGVib3gNCj4gU1lODQo+ID4+PiBvcHRp
b24gbWFuZ2xpbmcgd2hpY2ggaXMgYSBrbm93IHByb2JsZW0uDQo+ID4+Pg0KPiA+Pj4gVGhlcmVm
b3JlIHdlIHNpbXBseSBkb27igJl0IG5lZWQgb3B0aW9uIGluIHRoZSBTWU4gYW5kIHRoZXJlIGlz
IG5vDQo+IHJlYXNvbiB0bw0KPiA+Pj4gd2FzdGUgdGhlIHNwYWNlLg0KPiA+Pj4NCj4gPj4+PiBX
aGlsZSBJIHRoaW5rIG1hbnkgdHV0b3JpYWwgdGV4dCBpbiB0aGlzIGRvY3VtZW50IGNvdWxkIGJl
IHNob3J0ZW5lZCwgSQ0KPiA+Pj4gYmVsaWV2ZSB0aGUgdXNlIG9mIGEgcmVzZXJ2ZWQgVENQIGhl
YWRlciBmbGFnIHNob3VsZCBiZSByZWFzb25lZC4NCj4gPj4+DQo+ID4+PiBJ4oCZbSBhY3R1YWxs
eSB1bmNlcnRhaW4gd2hhdCB5b3UgZXhwZWN0IGhlcmUuDQo+ID4+IEZvciBpbnN0YW5jZSwgdGhp
cyByZXBseSB3aXRoIHRoZSBleHBsYW5hdGlvbiBvZiBTWU4gb3B0aW9uIG1hbmdsaW5nDQo+IHNl
ZW1zIHVzZWZ1bCBleHBsYW5hdGlvbi4NCj4gPj4NCj4gPj4+PiAqIDMuMi44LiAgVXNhZ2Ugb2Yg
dGhlIEFjY0VDTiBUQ1AgT3B0aW9uDQo+ID4+Pj4NCj4gPj4+PiAgICBUaGUgZm9sbG93aW5nIHJ1
bGVzIGRldGVybWluZSB3aGVuIGEgRGF0YSBSZWNlaXZlciBpbiBBY2NFQ04gbW9kZQ0KPiA+Pj4+
ICAgIHNlbmRzIHRoZSBBY2NFQ04gVENQIE9wdGlvbiwgYW5kIHdoaWNoIGZpZWxkcyB0byBpbmNs
dWRlOg0KPiA+Pj4+DQo+ID4+Pj4gICAgQ2hhbmdlLVRyaWdnZXJlZCBBQ0tzOiAgSWYgYW4gYXJy
aXZpbmcgcGFja2V0IGluY3JlbWVudHMgYSBkaWZmZXJlbnQNCj4gPj4+PiAgICAgICBieXRlIGNv
dW50ZXIgdG8gdGhhdCBpbmNyZW1lbnRlZCBieSB0aGUgcHJldmlvdXMgcGFja2V0LCB0aGUgRGF0
YQ0KPiA+Pj4+ICAgICAgIFJlY2VpdmVyIE1VU1QgaW1tZWRpYXRlbHkgc2VuZCBhbiBBQ0sgd2l0
aCBhbiBBY2NFQ04gT3B0aW9uLA0KPiA+Pj4+ICAgICAgIHdpdGhvdXQgd2FpdGluZyBmb3IgdGhl
IG5leHQgZGVsYXllZCBBQ0sgKHRoaXMgaXMgaW4gYWRkaXRpb24gdG8NCj4gPj4+PiAgICAgICB0
aGUgc2FmZXR5IHJlY29tbWVuZGF0aW9uIGluIFNlY3Rpb24gMy4yLjUgYWdhaW5zdCBhbWJpZ3Vp
dHkgb2YNCj4gPj4+PiAgICAgICB0aGUgQUNFIGZpZWxkKS4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAg
IFRoaXMgaXMgc3RhdGVkIGFzIGEgIk1VU1QiIHNvIHRoYXQgdGhlIGRhdGEgc2VuZGVyIGNhbiBy
ZWx5IG9uDQo+ID4+Pj4gICAgICAgY2hhbmdlLXRyaWdnZXJlZCBBQ0tzIHRvIGRldGVjdCB0cmFu
c2l0aW9ucyByaWdodCBmcm9tIHRoZSB2ZXJ5DQo+ID4+Pj4gICAgICAgc3RhcnQgb2YgYSBmbG93
LCB3aXRob3V0IGZpcnN0IGhhdmluZyB0byBkZXRlY3Qgd2hldGhlciB0aGUNCj4gPj4+PiAgICAg
ICByZWNlaXZlciBjb21wbGllcy4gIEEgY29uY2VybiBoYXMgYmVlbiByYWlzZWQgdGhhdCBjZXJ0
YWluIG9mZmxvYWQNCj4gPj4+PiAgICAgICBoYXJkd2FyZSBuZWVkZWQgZm9yIGhpZ2ggcGVyZm9y
bWFuY2UgbWlnaHQgbm90IGJlIGFibGUgdG8NCj4gc3VwcG9ydA0KPiA+Pj4+ICAgICAgIGNoYW5n
ZS10cmlnZ2VyZWQgQUNLcywgYWx0aG91Z2ggaGlnaCBwZXJmb3JtYW5jZSBwcm90b2NvbHMgc3Vj
aA0KPiBhcw0KPiA+Pj4+ICAgICAgIERDVENQIHN1Y2Nlc3NmdWxseSB1c2UgY2hhbmdlLXRyaWdn
ZXJlZCBBQ0tzLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBUbyBtZSB0aGlzIHNvdW5kcyBsaWtlIGEg
cGVyZmVjdCBleGFtcGxlIGZvciBhIFNIT1VMRCB3aXRoDQo+IGFkZGl0aW9uYWwNCj4gPj4+IGd1
aWRhbmNlIHdoeSBpbXBsZW1lbnRpbmcgdGhpcyBTSE9VTEQgaXMgcmVhbGx5IGltcG9ydGFudC4N
Cj4gPj4+DQo+ID4+PiBUaGlzIGlzIG9uZSBvZiB0aGUgbW9zdCBkaXNjdXNzZWQgcG9pbnQgZnJv
bSB0aGUgYXV0aG9yIGFuZCB3ZSByZWFsbHkNCj4gdHJpZWQgdG8NCj4gPj4+IGdldCBhZGRpdGlv
bmFsIGd1aWRhbmNlIGhlcmUgb2Ygd2hhdCB0byBkbyBhbHNvIGZyb20gb3V0c2lkZSB0aGUgSUVU
RiBidXQNCj4gZGlkDQo+ID4+PiBubyBjbGVhciBmZWVkYmFjay4NCj4gPj4+DQo+ID4+PiBBcyBl
eHBsYWluZWQgdGhpcyBNVVNUIGVuYWJsZXMgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5LiBIb3dl
dmVyLCB0aGlzIGlzDQo+IGFuDQo+ID4+PiBleHBlcmltZW50IGRvY3VtZW50LiBJZiB3ZSBkZXRl
Y3QgdGhhdCB0aGlzIE1VU1QgZG9lcyBhY3R1YWxseSBoaW5kZXINCj4gPj4+IGltcGxlbWVudGF0
aW9uIG9yIGhhcyBqdXN0IG5ldmVyIGJlZW4gaW1wbGVtZW50ZWQsIHdlIHNob3VsZA0KPiByZWNv
bnNpZGVyDQo+ID4+PiB0aGlzIGluIHRoZSBmaW5hbCBQUyBSRkMuDQo+ID4+Pg0KPiA+Pj4gSSB3
YXMgb24gdGhlIFNIT1VMRCBzaWRlIG9mIHRoZSBkaXNjdXNzaW9uLCBidXQgY2FuIHNheSB0aGF0
IHRoZQ0KPiA+Pj4gaW1wbGVtZW50YXRpb24gaW4gTGludXggd2FzIHdheSBtb3JlIHNpbXBsZSB0
aGVuIGV4cGVjdGVkLg0KPiBPZmZsb2FkaW5nDQo+ID4+PiBtaWdodCBiZSBhIGRpZmZlcmVudCB0
b3BpYyBidXQgdGhhdCBpcyB3aGVyZSBJIGNvdWxkIG5vdCBnZXQgYSBjbGVhcg0KPiBmZWVkYmFj
aw0KPiA+Pj4gYW5kIG9mZmxvYWRpbmcgY291bGQgcHJvYmFibHkgYmUgYW55d2F5IG9wdGltaXpl
ZCBmb3IgdXNlIHdpdGggQWNjRUNODQo+IChpZiBpdA0KPiA+Pj4gZ2V0cyBkZXBsb3kgd2lkZWx5
KS4NCj4gPj4gSWYgYSBNVVNUIHJlcXVpcmVzIGNoYW5nZXMgaW4gaGFyZHdhcmUsIEkgdGhpbmsg
dGhlcmUgbXVzdCBiZSBhIGNsZWFyDQo+IHJlYXNvbi4NCj4gPj4NCj4gPj4gQXMgaW5kaXZpZHVh
bCBjb250cmlidXRvciwgd2l0aCB0aGUgY3VycmVudCBleHBsYW5hdGlvbiBpbiB0aGUgdGV4dCwg
SQ0KPiBiZWxpZXZlIHRoaXMgaGFzIHRvIGJlIGEgU0hPVUxELg0KPiA+Pg0KPiA+Pj4gSSB0aG91
Z2ggd2UgYWRkZWQgdGhpcyBhcyBzb21ldGhpbmcgdG8gbWVudGlvbiBpbiB0aGUgZXhwIGdvYWxz
DQo+IHNlY3Rpb24sIGJ1dA0KPiA+Pj4gb2J2aW91c2x5IHdlIGRpZG7igJl0LiBJIGFkZGVkIHRo
ZSBmb2xsb3dpbmcgdGV4dCBub3c6DQo+ID4+Pg0KPiA+Pj4gIkFub3RoZXIgZXhwZXJpbWVudGF0
aW9uIGZvY3VzIGlzIHRoZSBpbXBsZW1lbnRhdGlvbiBmZWFzaWJpbGl5IG9mDQo+IGNoYW5nZS0N
Cj4gPj4+IHRyaWdnZXJlZCBBQ0tzIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMi44LiBXaGls
ZSBvbiBhdmVyYWdlIHRoaXMNCj4gc2hvdWxkIG5vdA0KPiA+Pj4gbGVhZCB0byBhIGhpZ2hlciBB
Q0sgcmF0ZSwgaXQgY2hhbmdlcyB0aGUgQUNLIHBhdHRlciB3aGljaCBlc3BlY2lhbGx5IGNhbg0K
PiBoYXZlDQo+ID4+PiBhbiBpbXBhY3Qgb24gaGFyZHdhcmUgb2ZmbG9hZC4gRnVydGhlciBleHBl
cmltZW50YXRpb24gaXMgbmVlZGVkIHRvDQo+IGFkdmlzZQ0KPiA+Pj4gaWYgdGhpcyBzaG91bGQg
YSBoYXJkIHJlcXVpcmVtZW50IG9yIGp1c3QgcHJlZmVyIGJlaGF2aW9yLuKAnA0KPiA+PiBJZiBp
dCBpcyB1bmNsZWFyIGlmIGEgTVVTVCBjYW4gYWN0dWFsbHkgYmUgaW1wbGVtZW50ZWQsIGhhdmlu
ZyBhIE1VU1QgaXMgaW4NCj4gbXkgb3BpbmlvbiB0aGUgd3JvbmcgYXBwcm9hY2guDQo+ID4+DQo+
ID4+IE9uZSBjb3VsZCBlcXVhbGx5IHN0YXRlIGhlcmUgdGhhdCBmdXJ0aGVyIGV4cGVyaW1lbnRh
dGlvbiBpcyBuZWVkZWQgdG8NCj4gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIFNIT1VMRCBjYW4gYmUg
dXBncmFkZWQgdG8gYSBNVVNULg0KPiA+IEnigJltIHN0aWxsIG9wZW4gZm9yIGV2ZXJ5dGhpbmcg
aGVyZSwgYnV0IEkgYmVsaWV2ZSB0aGlzIHdhcyBkaXNjdXNzZWQgYW5kDQo+IGFncmVlZCBpbiB0
aGUgd29ya2luZyBncm91cOKApj8NCj4gPg0KPiA+DQo+ID4+Pj4gICAgRm9yIHRoZSBhdm9pZGFu
Y2Ugb2YgZG91YnQsIHRoZSBjaGFuZ2UtdHJpZ2dlcmVkIEFDSyBtZWNoYW5pc20gaXMNCj4gPj4+
PiAgICBkZWxpYmVyYXRlbHkgd29yZGVkIHRvIGlnbm9yZSB0aGUgYXJyaXZhbCBvZiBhIGNvbnRy
b2wgcGFja2V0IHdpdGggbm8NCj4gPj4+PiAgICBwYXlsb2FkLCB3aGljaCB0aGVyZWZvcmUgZG9l
cyBub3QgYWx0ZXIgYW55IGJ5dGUgY291bnRlcnMsIGJlY2F1c2UgaXQNCj4gPj4+PiAgICBpcyBp
bXBvcnRhbnQgdGhhdCBUQ1AgZG9lcyBub3QgYWNrbm93bGVkZ2UgcHVyZSBBQ0tzLiAgVGhlIGNo
YW5nZS0NCj4gPj4+PiAgICB0cmlnZ2VyZWQgQUNLIGFwcHJvYWNoIHdpbGwgbGVhZCB0byBzb21l
IGFkZGl0aW9uYWwgQUNLcyBidXQgaXQgZmVlZHMNCj4gPj4+PiAgICBiYWNrIHRoZSB0aW1pbmcg
YW5kIHRoZSBvcmRlciBpbiB3aGljaCBFQ04gbWFya3MgYXJlIHJlY2VpdmVkIHdpdGgNCj4gPj4+
PiAgICBtaW5pbWFsIGFkZGl0aW9uYWwgY29tcGxleGl0eS4NCj4gPj4+Pg0KPiA+Pj4+IFttc10g
VGhlIGFkZGl0aW9uYWwgYWNrcyBjcmVhdGUgbmV0d29yayBsb2FkLiBJIHRoaW5rIHNvbWUgd29y
ZGluZyBpcw0KPiA+Pj4gbmVlZGVkIG9uIHRoZSB0cmFkZW9mZiBiZXR3ZWVuIGluZm9ybWF0aW9u
IGFjY3VyYWN5IGFuZCBuZXR3b3JrDQo+IGxvYWQuDQo+ID4+PiBUaGVyZSBhcmUgbmV0d29yayBl
bnZpcm9ubWVudHMgaW4gd2hpY2ggYW55IGFkZGl0aW9uYWwgcGFja2V0IGlzIHZlcnkNCj4gPj4+
IGV4cGVuc2l2ZSAoZS5nLiwgZW5lcmd5KSBhbmQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIGhvdyB0
aGUgcHJvdG9jb2wNCj4gZGVzaWduDQo+ID4+PiB0YWtlcyBpbnRvIGFjY291bnQgdGhlIHBvdGVu
dGlhbCBvdmVyaGVhZCBvZiBhZGRpdGlvbmFsIEFDS3MuIE1heWJlIHRoaXMNCj4gPj4+IGNvdWxk
IGJlIGFub3RoZXIgcmVhc29uIGZvciBhIFNIT1VMRC4NCj4gPj4+DQo+ID4+PiBUaGUgYWJvdmUu
IEhvd2V2ZXIsIHRoaXMgaXMgbm90IHJlYWxseSBhbiBhZGRpdGlvbmFsIEFDSyBiZWNhdXNlIHlv
dSBkbw0KPiA+Pj4gZGVsYXkgdGhlIG5leHQgb25lLiBGdXJ0aGVyIGV4cGVyaW1lbnRhdGlvbiBu
ZWVkZWQuDQo+ID4+IFRoZSBkb2N1bWVudCBzdGF0ZXMgImxlYWQgdG8gc29tZSBhZGRpdGlvbmFs
IEFDS3MiLiBJZiB0aGF0IGRvZXMgbm90DQo+IGluY3JlYXNlIG5ldHdvcmsgbG9hZCwgSSB0aGlu
ayBpdCBoYXMgdG8gYmUgZXhwbGljaXRseSBleHBsYWluZWQgd2h5IHRoZSBBQ0sNCj4gbG9hZCBp
cyBhdCBtb3N0IGVxdWFsIHRvIGEgY3VycmVudCBUQ1Agc3RhY2ssIGluIGFsbCBwb3RlbnRpYWwg
Y2FzZXMuIElmIGl0IGNhbg0KPiBpbmNyZWFzZXMgbmV0d29yayBsb2FkLCBpdCBoYXMgdG8gYmUg
cmVhc29uZWQgd2h5IGluY3JlYXNpbmcgbG9hZCAoYW5kIHJpc2sgb2YNCj4gcmV2ZXJzZSBjb25n
ZXN0aW9uIGFuZCB0aGUgbGlrZSkgaXMgd29ydGggdGhlIGVmZm9ydC4NCj4gPj4NCj4gPj4gSSBh
Z3JlZSB0aGF0IHRoaXMgbWF5IGJlIGFuIGFyZWEgb2YgZXhwZXJpbWVudGF0aW9uLCBidXQgSSBi
ZWxpZXZlIHRoZW4gaXQNCj4gaGFzIHRvIGJlIGV4cGxhaW5lZCB0byBpbXBsZW1lbnRlcnMgd2hh
dCB0aGUgdHJhZGVvZmZzIGFyZS4NCj4gPiBBZGRlZDoNCj4gPiAiRXNwZWNpYWxseSwgaWYgb25s
eSBmZXcNCj4gPiAgICAgICAgICAgIENFIG1hcmtzIG9jY3VycmVkIG9yIG11bHRpcGxlIG1hcmtz
IGluIGEgcm93LCB0aGUgYWRkaXRpb25hbCBsb2FkIHdpbGwNCj4gPiAgICAgICAgICAgIGJlIGxv
dy4gT3RoZXIsIHVuZXhwZWN0ZWQgbWFya2luZyBwYXR0ZXJuIGNvdWxkIGluY3JlYXNlIHRoZSBs
b2FkDQo+ID4gICAgICAgICAgICBzaWduaWZpY2FudGx5LCBob3dldmVyLCBpbnZlc3RpZ2F0aW5n
IHRoZSBhZGRpdGlvbmFsIGxvYWQgaXQgcGFydA0KPiA+ICAgICAgICAgICAgb2YgdGhlIHByb3Bv
c2VkIGV4cGVyaW1lbnRhdGlvbi4iDQo+ID4+Pj4gKiA0LjIuICBDb21wYXRpYmlsaXR5IHdpdGgg
T3RoZXIgVENQIE9wdGlvbnMgYW5kIEV4cGVyaW1lbnRzDQo+ID4+Pj4NCj4gPj4+PiAgICBBY2NF
Q04gaXMgY29tcGF0aWJsZSAoYXQgbGVhc3Qgb24gcGFwZXIpIHdpdGggdGhlIG1vc3QgY29tbW9u
bHkNCj4gdXNlZA0KPiA+Pj4+ICAgIFRDUCBvcHRpb25zOiBNU1MsIHRpbWUtc3RhbXAsIHdpbmRv
dyBzY2FsaW5nLCBTQUNLIGFuZCBUQ1AtQU8uICBJdA0KPiBpcw0KPiA+Pj4+ICAgIGFsc28gY29t
cGF0aWJsZSB3aXRoIHRoZSByZWNlbnQgcHJvbWlzaW5nIGV4cGVyaW1lbnRhbCBUQ1Agb3B0aW9u
cw0KPiA+Pj4+ICAgIFRDUCBGYXN0IE9wZW4gKFRGTyBbUkZDNzQxM10pIGFuZCBNdWx0aXBhdGgg
VENQIChNUFRDUA0KPiBbUkZDNjgyNF0pLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBJIHdvdWxkIHN1
Z2dlc3QgdGhlIHdvcmRpbmcgIi4uLiBjb21wYXRpYmxlIHdpdGggdGhlIGV4cGVyaW1lbnRhbA0K
PiA+Pj4gVENQIG9wdGlvbnMgLi4uIiBvciBldmVuICIuLi4gY29tcGF0aWJsZSB3aXRoIHRoZSBU
Q1Agb3B0aW9ucyDigKYiLg0KPiA+Pj4NCj4gPj4+IFRoZXNlIG9wdGlvbiBhcmUgdG8gZXhwZXJp
bWVudGFsLi4/DQo+ID4+ICJJdCBpcyBhbHNvIGNvbXBhdGlibGUgd2l0aCB0aGUgZXhwZXJpbWVu
dGFsIFRDUCBvcHRpb25zIFRDUCBGYXN0IE9wZW4NCj4gKFRGTyBbUkZDNzQxM10pIGFuZCBNdWx0
aXBhdGggVENQIChNUFRDUCBbUkZDNjgyNF0pLiIgd291bGQgaGF2ZSBzYW1lDQo+IHRlY2huaWNh
bCBtZWFuaW5nLiBIYXZpbmcgc2FpZCB0aGlzLCB0aGlzIGlzIGVkaXRvcmlhbCBvbmx5Lg0KPiA+
Pg0KPiA+Pj4gVGhlIHBvaW50IG9mIHVzaW5nIOKAnmNvbW1vbmx5IHVzZWTigJwgd2FzIHRvIHNh
eSB0aGF0IHdlIGNoZWNrZWQgb24NCj4gdGhvc2UgYXMNCj4gPj4+IHRoZXkgc2VlbSBpbXBvcnRh
bnQuIEp1c3QgYmVjYXVzZSB5b3VyIGZhdm9yaXRlIGV4cGVyaW1lbnQgb3B0aW9uIGlzDQo+IG5v
dA0KPiA+Pj4gbGlzdGVkIGhlcmUgaXQgZG9lc27igJl0IG1lYW5zIGl0IGluY29tcGF0aWJsZSwg
d2UganVzdCBkaWRu4oCZdCBjaGVjay4gSeKAmW0NCj4gb2theSB0bw0KPiA+Pj4gcmVtb3ZlZCDi
gJ5jb21tb25seSB1c2Vk4oCcIGJ1dCBJIGRvbuKAmXQgdGhpbmsgaXQgbWFrZXMgYW55dGhpbmcg
YmV0dGVyLg0KPiA+Pj4NCj4gPj4+PiAqIDQuMy4gIENvbXBhdGliaWxpdHkgd2l0aCBGZWVkYmFj
ayBJbnRlZ3JpdHkgTWVjaGFuaXNtcw0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBRdWl0ZSBhIGJpdCBp
biB0aGlzIHNlY3Rpb24gaXMgZXhwZXJpbWVudGFsIHdvcmssIHdoaWNoIElNSE8NCj4gPj4+PiBz
aG91bGQgYmUgY2xlYXJseSBlbXBoYXNpemVkLiBUaGUgb25lIGV4Y2VwdGlvbiBpc+KApg0KPiA+
Pj4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBrZWVwIHRoaXMgc2VjdGlvbiBiZWNhdXNlIGludGVn
cml0eSBpcyB1c3VhbGx5IHRoZSBmaXN0DQo+ID4+PiBxdWVzdGlvbiB0aGF0IGNvbWUgdXAgd2hl
biBJIHByZXNlbnQgQWNjRUNOLiBFZmZlY3RpdmVseSB0aGVzZSBhcmUgdHdvDQo+ID4+PiBpbmRl
cGVuZGVudCB0b3BpY3MsIGhvd2V2ZXIsIEkgcmVhbGx5IHRoaW5rIGl0IGhlbHAgcGVvcGxlIHRv
IHVuZGVyc3RhbmQNCj4gdGhlDQo+ID4+PiB3aG9sZSBwaWN0dXJlIGlmIHRoaXMgaXMgYWxzbyBk
aXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVudC4NCj4gPj4+DQo+ID4+Pj4gICAgICAgSG93ZXZlciwg
VENQLUFPIGlzIG9mdGVuIHRvbyBicml0dGxlIHRvIHVzZSBvbiBtYW55IGVuZC10by1lbmQNCj4g
Pj4+PiAgICAgICBwYXRocywgd2hlcmUgbWlkZGxlYm94ZXMgY2FuIG1ha2UgdmVyaWZpY2F0aW9u
IGZhaWwgaW4gdGhlaXINCj4gPj4+PiAgICAgICBhdHRlbXB0cyB0byBpbXByb3ZlIHBlcmZvcm1h
bmNlIG9yIHNlY3VyaXR5LCBlLmcuIGJ5DQo+ID4+Pj4gICAgICAgcmVzZWdtZW50YXRpb24gb3Ig
c2hpZnRpbmcgdGhlIHNlcXVlbmNlIHNwYWNlLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBJIGFtIG5v
dCBzdXJlIGlmIGRlcGxveW1lbnQgY2hhbGxlbmdlcyBvZiBvdGhlciBvcHRpb25zIG5lZWQgdG8N
Cj4gYmUNCj4gPj4+IGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+Pj4NCj4gPj4+IElm
IHdlIGtlZXAgdGhlIGRpc2N1c3Npb24sIEkgZ3Vlc3Mgd2Ugc2hvdWxkIG1lbnRpb24gdGhpcyBh
cyB3ZWxsLiBBcyB0aGUNCj4gZG9jDQo+ID4+PiBjbGVhcmx5IHN0YXRlZCBzZWN0aW9uIDQgaXMg
bm90IG1lYW50IHRvIGJlIG5vcm1hdGl2ZS4NCj4gPj4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhl
cmUgYXJlIHVzZSBjYXNlcyBmb3IgVENQLUFPIHdoZXJlIG1pZGRsZWJveGVzIGFyZQ0KPiBzaW1w
bHkgbm90IGEgcHJvYmxlbSwgYnV0IGl0IGlzIGV4YWN0bHkgdGhpcyBzb3J0IG9mIGRpc2N1c3Np
b24gdGhhdCBtYXkgbm90IGJlDQo+IG5lZWRlZCBpbiB0aGlzIGRvY3VtZW50LiBCdXQgSSB3b24n
dCByYXQtaG9sZSBvbiB0aGlzIGNvbW1lbnQgaGVyZS4NCj4gPj4NCj4gPj4+PiAgICBPcmlnaW5h
bGx5IHRoZSBFQ04gTm9uY2UgW1JGQzM1NDBdIHdhcyBwcm9wb3NlZCB0byBlbnN1cmUgaW50ZWdy
aXR5DQo+ID4+Pj4gICAgb2YgY29uZ2VzdGlvbiBmZWVkYmFjay4gIFdpdGggbWlub3IgY2hhbmdl
cyBBY2NFQ04gY291bGQgYmUNCj4gb3B0aW1pc2VkDQo+ID4+Pj4gICAgZm9yIHRoZSBwb3NzaWJp
bGl0eSB0aGF0IHRoZSBFQ1QoMSkgY29kZXBvaW50IG1pZ2h0IGJlIHVzZWQgYXMgYW4gRUNODQo+
ID4+Pj4gICAgTm9uY2UgLiBIb3dldmVyLCBnaXZlbiBSRkMgMzU0MCBpcyBiZWluZyByZWNsYXNz
aWZpZWQgYXMgaGlzdG9yaWMsDQo+ID4+Pj4gICAgdGhlIEFjY0VDTiBkZXNpZ24gaGFzIGJlZW4g
Z2VuZXJhbGlzZWQgc28gdGhhdCBpdCBvdWdodCB0byBiZSBhYmxlIHRvDQo+ID4+Pj4gICAgc3Vw
cG9ydCBvdGhlciBwb3NzaWJsZSB1c2VzIG9mIHRoZSBFQ1QoMSkgY29kZXBvaW50LCBzdWNoIGFz
IGEgbG93ZXINCj4gPj4+PiAgICBzZXZlcml0eSBvciBhIG1vcmUgaW5zdGFudCBjb25nZXN0aW9u
IHNpZ25hbCB0aGFuIENFLg0KPiA+Pj4+DQo+ID4+Pj4gW21zXSBUaGUgZGlzY3Vzc2lvbiBvZiBS
RkMgMzU0MCBjYW4gcHJvYmFibHkgYmUgcmVtb3ZlZCB0byBhIGxhcmdlDQo+IGV4dGVudC4NCj4g
Pj4+IFVuZm9ydHVuYXRlbHksIHBsZWFzZSBzdGlsbCB0aGluayB0aGF0IEVDTiBOb25jZSwgZXZl
biB0aG91Z2ggaXMgd2FzDQo+IG5ldmVyDQo+ID4+PiBkZXBsb3llZCBhbmQgZG9lc27igJl0IHJl
YWxseSB3b3JrLCBpcyB0aGUgb25seSB3YXMgdG8gcHJvdmlkZSBpbnRlZ3JpdHkNCj4gPj4+IHBy
b3RlY3Rpb24gYW5kIHdlIG5lZWQgaXQgYXMgYSBwcmVyZXF1aXNpdGUgdG8gZGVwbG95IEVDTiBh
dCBhbGzigKYgaSB3b3VsZA0KPiA+Pj4gcmVhbGx5IHByZWZlciB0byBrZWVwIHRoaXMgaW4gdGhp
cyBub24tbm9ybWF0aXZlIHBhcnQgb2YgdGhlIGRvYy4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiAq
IDYuICBJQU5BIENvbnNpZGVyYXRpb25zDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIEkgdGhpbmsgdGhp
cyBzZWN0aW9uIG5lZWRzIHRvIGJlIHJld3JpdHRlbiB0byByZXF1ZXN0IGEgbmV3DQo+IGFsbG9j
YXRpb24NCj4gPj4+IG9mIGJpdCA3IG9mIHRoZSBUQ1AgaGVhZGVyIGZsYWdzLiBBdCBsZWFzdCBm
b3IgdGhlIHByb2Nlc3MgSSB0aGluayBpdCB3b3VsZA0KPiBtYWtlDQo+ID4+PiBzZW5zZSB0byBo
YXZlIHNvbWV3aGVyZSBpbiB0aGUgZG9jdW1lbnQgYSBjb21wcmVoZW5zaXZlDQo+IGV4cGxhbmF0
aW9uIG9mDQo+ID4+PiB3aHkgYW4gZXhwZXJpbWVudGFsIGRvY3VtZW50IHJlcXVlc3RzIGEgY2hh
bmdlIG9mIHRoZSBtYWluIFRDUA0KPiBoZWFkZXIsDQo+ID4+PiBhbmQgd2h5IHRoaXMgY2Fubm90
IGJlIGF2b2lkZWQgKG1vc3Qgbm90YWJseSBpbiB0aGUgaW5pdGlhbCBTWU4pIGJ5IGFuDQo+ID4+
PiBhbHRlcm5hdGl2ZSBwcm90b2NvbCBkZXNpZ24uDQo+ID4+Pg0KPiA+Pj4gQXMgSSBzYWlkIHBy
ZXZpb3VzbHkgdGhpcyBzZWN0aW9uIGlzIHdyaXR0ZW4gYXMgaXQgd291bGQgbG9vayBsaWtlIGFm
dGVyIHRoZQ0KPiA+Pj4gYWxsb2NhdGlvbiBoYXMgaGFwcGVuZWQgd2l0aCBwdWJsaWNhdGlvbiBh
cHByb3ZhbCBvZiB0aGUgSUVTRy4gVGhpcyBpcw0KPiBmaW5lLg0KPiA+Pj4NCj4gPj4+IEhhdmlu
ZyBhIGRpc2N1c3Npb24gYWJvdXQgYW4gZXhwZXJpbWVudCBkb2MgYXNzaWduaW5nIGEgZmxhZyAo
b3Igbm90KSBpcyBhDQo+ID4+PiBxdWVzdGlvbiBmb3IgdGNwbSBhcyBhIHdob2xlIGFuZCBub3Qg
c3BlY2lmaWNhbGx5IHRoaXMgZG9jdW1lbnQuIEhvdyBkbw0KPiB3ZQ0KPiA+Pj4gZW52aXNpb24g
dG8gZXZlcnkgdXNlIGFueSBmdXJ0aGVyIGZsYWdzPyBXZSBnbyB0byBQUyByaWdodCBhd2F5PyBP
cg0KPiBzaG91bGQNCj4gPj4+IHdlIGNoYW5nZSB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeT8gRm9y
IG1lIHRoZSBsYXR0ZXIgbWFrZXMgYWN0dWFsbHkgbW9yZQ0KPiA+Pj4gc2Vuc2UuIEhvd2V2ZXIs
IGlmIHdlIGRvbuKAmXQgd2FudC9jYW4gdG8gZGVjaWRlIHRoaXMgbm93LCB3ZSBhbHNvIGNvdWxk
DQo+IGdvDQo+ID4+PiBmb3J3YXJkIGFzIGl0IGlzIHdpdGggSUVTRyBhcHByb3ZhbC4gSG93ZXZl
ciwgaXMgdGhpcyBjYXNlIGl0IGlzIGFsc28gbm90DQo+IG5lZWRlZA0KPiA+Pj4gdG8gZXhwbGFp
biB0aGlzIGluIHRoZSBkb2N1bWVudC4gVGhlIHJlc3BvbnNpYmxlIEFEIGhhcyB0byBleHBsYWlu
IHRoaXMgdG8NCj4gdGhlDQo+ID4+PiBvdGhlciBJRVNHIHByb2JhYmx5IGluIHRoZSBiYWxsb3Qg
b3IgZXZlbiBiZXR0ZXIgdGhlIHNoZXBoZXJkIGNvdWxkDQo+IHByb3ZpZGUNCj4gPj4+IHRoZXNl
IGluZm9ybWF0aW9uIGluIHRoZSB3cml0ZS11cC4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiAqIDku
ICBDb21tZW50cyBTb2xpY2l0ZWQNCj4gPj4+Pg0KPiA+Pj4+ICAgIENvbW1lbnRzIGFuZCBxdWVz
dGlvbnMgYXJlIGVuY291cmFnZWQgYW5kIHZlcnkgd2VsY29tZS4gIFRoZXkNCj4gY2FuDQo+ID4+
PiBiZQ0KPiA+Pj4+ICAgIGFkZHJlc3NlZCB0byB0aGUgSUVURiBUQ1AgbWFpbnRlbmFuY2UgYW5k
IG1pbm9yIG1vZGlmaWNhdGlvbnMNCj4gd29ya2luZw0KPiA+Pj4+ICAgIGdyb3VwIG1haWxpbmcg
bGlzdCA8dGNwbUBpZXRmLm9yZz4sIGFuZC9vciB0byB0aGUgYXV0aG9ycy4NCj4gPj4+Pg0KPiA+
Pj4+IFttc10gVGhpcyBzZWN0aW9uIGlzIG5vdCBuZWVkZWQgSU1ITw0KPiA+Pj4gWWVzLCBpdCB3
aWxsIGJlIHJlbW92ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gMTAuICBS
ZWZlcmVuY2VzDQo+ID4+Pj4NCj4gPj4+PiAgICBbSS1ELmlldGYtdHN2d2ctZWNuLWV4cGVyaW1l
bnRhdGlvbl0NCj4gPj4+PiAgICAgICAgICAgICAgIEJsYWNrLCBELiwgIlJlbGF4aW5nIFJlc3Ry
aWN0aW9ucyBvbiBFeHBsaWNpdCBDb25nZXN0aW9uDQo+ID4+Pj4gICAgICAgICAgICAgICBOb3Rp
ZmljYXRpb24gKEVDTikgRXhwZXJpbWVudGF0aW9uIiwgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tDQo+
ID4+Pj4gICAgICAgICAgICAgICBleHBlcmltZW50YXRpb24tMDcgKHdvcmsgaW4gcHJvZ3Jlc3Mp
LCBPY3RvYmVyIDIwMTcuDQo+ID4+Pj4NCj4gPj4+PiBbbXNdIE5vcm1hdGl2ZSByZWZlcmVuY2U/
DQo+ID4+PiBEb27igJl0IHNlZSB3aHkuIE5vIG5lZWQgdG8gcmVhZCBpZXRmLXRzdndnLWVjbi1l
eHBlcmltZW50YXRpb24gdG8NCj4gPj4+IHVuZGVyc3RhbmQgdGhlIHNwZWMgaW4gdGhpcyBkb2Mu
DQo+ID4+Pg0KPiA+Pj4gVGhhbmtzIQ0KPiA+Pj4gTWlyamENCj4gPj4+DQo+ID4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0Y3BtIG1haWxpbmcg
bGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3RjcG0NCj4gDQo+IC0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fDQo+IEJvYiBCcmlzY29lICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K


From nobody Sun Jul 15 13:54:43 2018
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 3C0C0130E77; Sun, 15 Jul 2018 13:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 1PwDRUAWlJ0Y; Sun, 15 Jul 2018 13:54:39 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD1F130E6A; Sun, 15 Jul 2018 13:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJNmN827VpBuKNEVuZRyLRX+A1N2oUQ9IXEzd149WBw=; b=ciHOvz4W5m7iVqO2XC8rH77pv4c2mtZmm1i5oPFE6WIfFZZnurFIrmbuueI4V4upB879m3QGNfCtjzUuQ7eUWzVC7G+mve1VVgNDldVeg/jS2PxhCHJ4KTOG0f/sAXADhnWIZoVCPEZBZ5nE1mfFUgbrDgFgVVLwgBuNA7wLy7M=
Received: from AM2PR07MB0867.eurprd07.prod.outlook.com (10.161.71.153) by AM2PR07MB0562.eurprd07.prod.outlook.com (10.160.32.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.14; Sun, 15 Jul 2018 20:54:31 +0000
Received: from AM2PR07MB0867.eurprd07.prod.outlook.com ([fe80::2408:bde2:6996:189d]) by AM2PR07MB0867.eurprd07.prod.outlook.com ([fe80::2408:bde2:6996:189d%10]) with mapi id 15.20.0973.013; Sun, 15 Jul 2018 20:54:31 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vg==
Date: Sun, 15 Jul 2018 20:54:31 +0000
Message-ID: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-originating-ip: [92.203.139.253]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0562; 7:p49oQMrj9rYun5LRObxssNPt/YYbDcNuhzghwEZvRJysMNQwRw0F5h/rpkzTdjoVElfvc6xDekREwJBDQ/yXIkVfySEp3Er3wOX4j2pnKMC0XFxNleOG3goIaFjzuvZW9kZL0FWfQ+1YcLI8zt315dZxR7MkKizzT7jxph+qRMC25FbrXWZttj3GlizpzeM3CNKl+ggRnZOZ2suCPRYq3CJTg4W8rCMH9Do4VypRU/ZHSQ+7ogY5W3ON2Y85T+Qw
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e1e00372-31f9-4453-e422-08d5ea9529df
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:AM2PR07MB0562; 
x-ms-traffictypediagnostic: AM2PR07MB0562:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(72170088055959)(192374486261705); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(11241501184)(806099)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM2PR07MB0562; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0562; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(366004)(396003)(136003)(346002)(39860400002)(376002)(53754006)(199004)(189003)(26005)(5660300001)(5250100002)(2501003)(106356001)(2906002)(6506007)(186003)(102836004)(14454004)(53936002)(486006)(110136005)(478600001)(476003)(66066001)(450100002)(99286004)(316002)(25786009)(105586002)(7696005)(14444005)(7736002)(9686003)(86362001)(2900100001)(256004)(33656002)(74316002)(6116002)(68736007)(8676002)(305945005)(3846002)(8936002)(6436002)(55016002)(81156014)(97736004)(81166006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0562; H:AM2PR07MB0867.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: iUyEMm9C/TA8/pOhTgm5wvkMTjHNc1mVu1k3PFVsJIjHyATTMYt1P4SoRUyQYM2rCMnaKwevuTfrrSk7aQEFvEu4EncCpwMfwMY6ofbHZQ9MbWtU+Sw5u+DLUZXVhH1p/trIMh2zmdVaAGQDKW5BQ0RJoOltyXr/Wvpe9wj3UrICYhCfVji05TY2CDSjN2/544kg/Dy4idhNBmZLtoPmt34gX2yZtU92x8VVk0jHFBRrZmKADHZE1biYLpRHpy1729VtyNut0+PDoQgj78WCSXDUqkUJ886/zNWUQ2oNtASUwEmDl0E726yFSxBX+J192Ey90zn6/n88M4sM5uOX5kA1tddhaQecJEU4VwQgTMfKKS7pb74Q+HPrXZdachgxwo8jqs5fnhfhjq+EjT8Jxw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e1e00372-31f9-4453-e422-08d5ea9529df
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2018 20:54:31.4477 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0562
Archived-At: 
Subject: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 15 Jul 2018 20:54:42 -0000

Hi all,

While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:


Section 1. Introduction

   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
   ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].

[ms] I have commented on this section before. And I still dislike the term =
"likely". To me, "likely" is speculation. A neutral phrasing would be "... =
it is possible..." or "... it is useful...". Having said this, I observe th=
at draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely"=
 is it that the AccECN protocol will be implemented along with a mechanism =
documented in an ID that has been written more than 10 years ago and not be=
en updated for about 4 years? Are implementers indeed so interested in draf=
t-moncaster-tcpm-rcv-cheat that an implementation is "likely"?


Section 2.1.  Capability Negotiation
  =20
   The TCP server sends the AccECN
   Option on the SYN/ACK and the client sends it on the first ACK to
   test whether the network path forwards the option correctly.

[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 i=
s not normative, the whole Section 2 does not really describe well the actu=
al requirements regarding options. This paragraph in Section 2.1 is one exa=
mple for that. It would make sense to be more explicit in Section 2 to whic=
h extent options have to be supported.


Section 7.  Security Considerations

[ms] I wonder about the security implications of "confusing" classic ECN an=
d AccECN feedback in (passive) network monitoring solutions, most notably i=
f packet sampling is used and no per-connection state is applied. At least =
theoretically, passive monitoring of "classic ECN" TCP header flags could b=
e used for network monitoring, e.g., to estimate congestion levels in a net=
work, no? How would such a (hypothetical) passive monitoring solution be ab=
le to distinguish the standard ECN feedback from an ongoing AccECN experime=
nt, in particular in a sampled packet stream w/o having access to the SYN n=
egotiation? Would there be security or safety implications when experimenti=
ng with AccECN in networks using network monitoring solutions that only sup=
port ECN as standardized by the IETF?


Thanks

Michael (chair hat off)


From nobody Mon Jul 16 02:15:46 2018
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 88F78130DE8; Mon, 16 Jul 2018 02:15:45 -0700 (PDT)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wbpSlf-QJQYR; Mon, 16 Jul 2018 02:15:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D69130DC1; Mon, 16 Jul 2018 02:15:42 -0700 (PDT)
Received: from [192.168.233.109] ([213.143.121.76]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M9eHT-1flIJz0dR9-00CyIs; Mon, 16 Jul 2018 11:15:36 +0200
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References: 
From: "Scheffenegger, Richard" 
Message-ID: <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at>
Date: Mon, 16 Jul 2018 11:15:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:WQBczm/2KY9aH/lmBeWs0dbNPJhzEJ8SGQlMgz9951V1bDXvGGP fcI/oWg0jJ0k3VrdspLEUQyTwrqWU0rcpT0N9bUOE1t/WXrWRazYpuGNkr9kCpJrbWpKjC7 XmmiOi8pv8bYOWQDgWuVIx4JDSzwAw3oYyznpUpOBo2Dc3NUGFiHeUYqljYPTvMQsOobOA2 hUyrrOjovLCMWqqbdaOvA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UpZVx9uAk80=:1dwWEuUefe0O9VUHL5gs9/ EbP9gcysd5J7naP5HWM1W+hsn0MzpSSuHdw5TnD9ZORL+JOv3rt9FWQIg+O8pR9SKvJXet2gX ZC3tmA+Oy90PYP9+y3tm2Q400X2EgCoNeYwOkNz9bNBQJfbvFkCr5Z7ZdnI7KpRL6pOgpinVK VZVIAaF2NqZq9TKzqE3A7EVnxBFms93WuWRw1kXHIkHltbnTD+a95cBJKfNPlshW9TikxsrHn VRKn83sdGm5e3p8S45YgGwkhA0zfTTKILEb/OQgPwTrpgUqCfPwCt0t/6D4sUPF6vnZTfkIbb 3SXY4rYosWhdL8igZ6iQc7HPFyG2jyk6do211oGwl26Ou9GiSeo7vps3H6fsHy4rlv4bGJoox Se+XDns46qwaa5TVxiRLXq1KrGlPEgczWgoGxM0Gt7PDiAwDXum47oB4GuQUdZYB73SMpadc6 3Tm6oBtMV7EvTmgJE2p13/mnJCG/MtQklcXMY0LRNDaeYZ8P6h1sIZz7KVzTVkmG0uTgmC6DN mCSl2etxJI064/9MflBWSEwMTMK+xAB/FAZ9EKTmcoNhbZDqfZ7R/sFqUqg9SI7qabuuvSQY3 T054axZb8f+NZJ4+vUAM2kjLQ4LSznmqMz90ScMGptFDq/VpG9dt9jvziDY3c7yk6AxJKbj2v fpUfSlP5jP9ij6xSTetTl2mjx9dWmC4hd3cn4ge+OTeqkWlAGcga+7yQtgsM0TFPUhwiPyyeG PRKZpytrLPOf6utQWsc1OBeC0DrNuwLqt+k6g4mpW6Pf4vpDIEeYLDYY1MDaKgGiaJ3mi8HEx Ym5ryeD
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 16 Jul 2018 09:15:46 -0000

Hi Michael,



Am 15.07.2018 um 22:54 schrieb Scharf, Michael (Nokia - DE/Stuttgart):
> Hi all,
> 
> While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>
 > [...]
 >
> Section 7.  Security Considerations
> 
> [ms] I wonder about the security implications of "confusing" classic ECN and AccECN feedback in (passive) network monitoring solutions, most notably if packet sampling is used and no per-connection state is applied. At least theoretically, passive monitoring of "classic ECN" TCP header flags could be used for network monitoring, e.g., to estimate congestion levels in a network, no? How would such a (hypothetical) passive monitoring solution be able to distinguish the standard ECN feedback from an ongoing AccECN experiment, in particular in a sampled packet stream w/o having access to the SYN negotiation? Would there be security or safety implications when experimenting with AccECN in networks using network monitoring solutions that only support ECN as standardized by the IETF?
> 

For the safety aspect, if a middlebox meddles with the tcp header bits, 
and doesn't forward segments with specific ACE field codepoints, a 
reasonable response would be to resend the second or third 
retransmission with ECN disabled, and disable ECN for the remainder of 
the session. However, none of the large scale measurements conducted so 
far has found an indication of such a middlebox misbehavior to warrant 
text here. The regular AccECN negotiation will capture all known 
misbehaving middleboxes.

As to the passive monitoring - Mirja and Brian will certainly expand on 
this, but sampling ever so often should expose ACE field codepoints with 
high probability, which are unlikely or not possible with RFC3168 ECN 
(e.g. CWR + ECE is very unlikely - pure ACKs are not ECT marked in 
RFC3168, and bidirectional data exchange without stretches of pure acks 
is not common), anything with the former "NS" bit set has never been 
observed on the public internet to my knowledge. To summarize random 
sampling has at least a 5/8th chance to detect AccECN. However, as r.cep 
(section 3.2) is initialized to a value of 5 (101b), and many (short) 
flows probably rarely encounter a CE mark, the chance to detect, by 
random sampling, the presence of AccECN passively is even higher than 
this.  Short flow with up to 2 CE marks are immediately detectable, as 
the former "NS" bit remains set.


As to the passive monitoring of the congestion levels - the same problem 
of having only 1 bit signal per RTT applies here too, not? Also, you 
probably don't know where the congestion point (doing the CE marks) is 
from your vantage point, but looking at the TCP header flags to estimate 
the congestion levels is IMHO not the correct approach - for that, you'd 
want to evaluate the IP header "CE" marks, and AccECN does not change 
that at all...

If anything, AccECN should improve the passive monitoring of congestion 
*levels* (on asymetric paths) as now the monitoring point can track each 
CE in the reverse path; formerly, you could only use the stream of ECEs 
to estimate the connection receive window (spin bit), but not the extent 
of congestion in the network...

This "former use" of the ECE bit could be taken over by a different 
signal - see https://tools.ietf.org/html/draft-trammell-tsvwg-spin :)

Best regards,
   Richard






From nobody Mon Jul 16 10:48:28 2018
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 79A91130E3E; Mon, 16 Jul 2018 10:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=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 5ev1IhxamPiB; Mon, 16 Jul 2018 10:48:21 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D54A130EB3; Mon, 16 Jul 2018 10:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6k1Tnax+Uu7H/TRtOgqytCRRLxgG7iNxNRGPmooRM7Q=; b=WHy4+ETqj+C0wo3ZphdpmUIdhrOoLBXwaran6z3MMiIs3w1uVD5u8OSL6MHeW2v/IDQQDjmiNK3nEWwYT7yMNlfDjtiYTBcD585hIeC2vvoC49ITQneEpMPsy4+ns6V1kkgM7emtimp3h39ObzINRsj0/4oTaZwKo+0LpypkYts=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB3486.eurprd07.prod.outlook.com (10.175.244.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Mon, 16 Jul 2018 17:48:18 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.013; Mon, 16 Jul 2018 17:48:17 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: "Scheffenegger, Richard" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgAbKySAABFOwRA=
Date: Mon, 16 Jul 2018 17:48:17 +0000
Message-ID: 
References:  <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at>
In-Reply-To: <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [92.203.197.39]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3486; 6:uYH+x5fIxNSJ/kckY9NWv0I0KMwGekAlSNJvMIkHcyrn+XzKIue3xS0jVvk/kqLvFESW3C9TnAU7kGOinDhww0KUY9bFqE0HMnIIjrNcrSxXlcCbPm/f3YwT7TaK+VWrL5mq+dcWs4AZSB49wKa0pPqVKoYdjdgmC0j5OiCKmS9CF4JThZU1Vtbt8f7ybekCIrFI2yXTC9kDNdql80NyOdgLUSjEoX5gvSxgp3Z6kXiHy7mCZpX1Ss43C4lBt2lV1gosEaluLR4WjAt6akLBGbucwRNOR8xMuZ1GDA5S3HwVmuwY87jmn6sOWZIPtNvPBVWMNSgo001XkIzbmBcfk+TABCVR7pB6++5HAgju26u0vQHprBd9kEkZKOtqU89mabOK974rBUtwhspPa3M/aW7vxRQY9n2vahIm/UeHLUrq9ANCoqt+oA9RHHVGvcwoc2Z1e1JKPsinlyqjqtH2QQ==; 5:v8tkh0dF9C6ysKji4Be/TniISv4g7/PprsexSZUgpkLaMjfMEH2ytmdAua3Vge5rYDPlmsxlO3ts7s+nPzsAZ5gL+nytM+q+hOk9lhn/3DYPTlb1/iju9FyeV6HAb2aLuVum2R0DEuUEyMbVMsePZoM7GjJivQQ5V8iYVhQI68M=; 7:ft/fu1FtrLXr+A17Kdci30t5w1HETNSF3PhITWjvLiLRrBA0RqClgIlkU1SJHs+cidi26yVAxBGtiwpTH8gIPY8K3sg0h5qMlDD/B+pd7GDRKAJRKxVBuyA5noGrWgpdWYYKSHqG/eXbXOnsV1Vr7FGeH/pKYhA7LwZGTyLwmPJruB8JerOOGkyQJsgzFTyFVmIXAg4iTDCZudWrZsjnQAzmzB8iEJAhl+WomuNZJbMkhxIbTDVIA7h8U7JcU96d
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2cff991c-bf37-4508-490b-08d5eb445039
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR07MB3486; 
x-ms-traffictypediagnostic: VI1PR07MB3486:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(82608151540597)(109105607167333); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(806099)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB3486; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3486; 
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(136003)(366004)(346002)(53754006)(13464003)(199004)(189003)(486006)(476003)(6306002)(9686003)(2900100001)(256004)(66066001)(14444005)(186003)(11346002)(446003)(26005)(2201001)(68736007)(3846002)(2906002)(74316002)(6116002)(86362001)(7736002)(229853002)(6436002)(55016002)(305945005)(5660300001)(966005)(478600001)(6246003)(81166006)(33656002)(8676002)(25786009)(53936002)(81156014)(14454004)(5250100002)(6506007)(97736004)(316002)(53546011)(2501003)(102836004)(76176011)(7696005)(8936002)(99286004)(106356001)(105586002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3486; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: D8vzJmSezv7tSsnh/JeOcaDsEfH7BqcfjwKuSAHz24XqOHnYCZBtsSOG83+HV/iPtRaGPxu5qq6U4RxaAHpe+9xaLw9XnISE/Mhah6RGeP7vc19uZxR4bHjpV7+dnimJZXFLRusSb0g8db4BPARYJZFHNy8Eh8cN80qClebk3qAJKeRUuT7+CXdXNpR8Uq+P3036B2A5F6ZXocq1vbyp7+78+htjNJWQxj0fo9JZKP4rBybqGpX0hQHP8nui4WMiymHg52mEzJRuUw7clDENR1bbbETRp4/h5PS/N8jjLEJt5qwWHMrds1/MUDlKRtjofkaMpAfWsfPY3pM++6SAjXueUpxFzmELZl9P8o35vYzTM42bqJk++gDqiL0GUOz/tnvpv8EoNZm4Yordwks3iQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2cff991c-bf37-4508-490b-08d5eb445039
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 17:48:17.8077 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3486
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 16 Jul 2018 17:48:25 -0000

SW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NoZWZm
ZW5lZ2dlciwgUmljaGFyZCBbbWFpbHRvOnJzLmlldGZAZ214LmF0XQ0KPiBTZW50OiBNb25kYXks
IEp1bHkgMTYsIDIwMTggMTE6MTYgQU0NCj4gVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE
RS9TdHV0dGdhcnQpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+Ow0KPiBkcmFmdC1pZXRmLXRj
cG0tYWNjdXJhdGUtZWNuQGlldGYub3JnOyB0Y3BtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb
dGNwbV0gRnVydGhlciBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQo+
IA0KPiBIaSBNaWNoYWVsLA0KPiANCj4gDQo+IA0KPiBBbSAxNS4wNy4yMDE4IHVtIDIyOjU0IHNj
aHJpZWIgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCk6DQo+ID4gSGkgYWxs
LA0KPiA+DQo+ID4gV2hpbGUgcmVhZGluZyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3
LCBJIG5vdGljZWQgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiAgPiBbLi4uXQ0KPiAgPg0KPiA+IFNl
Y3Rpb24gNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+ID4NCj4gPiBbbXNdIEkgd29uZGVy
IGFib3V0IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgImNvbmZ1c2luZyIgY2xhc3NpYyBF
Q04gYW5kDQo+IEFjY0VDTiBmZWVkYmFjayBpbiAocGFzc2l2ZSkgbmV0d29yayBtb25pdG9yaW5n
IHNvbHV0aW9ucywgbW9zdCBub3RhYmx5IGlmDQo+IHBhY2tldCBzYW1wbGluZyBpcyB1c2VkIGFu
ZCBubyBwZXItY29ubmVjdGlvbiBzdGF0ZSBpcyBhcHBsaWVkLiBBdCBsZWFzdA0KPiB0aGVvcmV0
aWNhbGx5LCBwYXNzaXZlIG1vbml0b3Jpbmcgb2YgImNsYXNzaWMgRUNOIiBUQ1AgaGVhZGVyIGZs
YWdzIGNvdWxkIGJlDQo+IHVzZWQgZm9yIG5ldHdvcmsgbW9uaXRvcmluZywgZS5nLiwgdG8gZXN0
aW1hdGUgY29uZ2VzdGlvbiBsZXZlbHMgaW4gYQ0KPiBuZXR3b3JrLCBubz8gSG93IHdvdWxkIHN1
Y2ggYSAoaHlwb3RoZXRpY2FsKSBwYXNzaXZlIG1vbml0b3Jpbmcgc29sdXRpb24NCj4gYmUgYWJs
ZSB0byBkaXN0aW5ndWlzaCB0aGUgc3RhbmRhcmQgRUNOIGZlZWRiYWNrIGZyb20gYW4gb25nb2lu
ZyBBY2NFQ04NCj4gZXhwZXJpbWVudCwgaW4gcGFydGljdWxhciBpbiBhIHNhbXBsZWQgcGFja2V0
IHN0cmVhbSB3L28gaGF2aW5nIGFjY2VzcyB0bw0KPiB0aGUgU1lOIG5lZ290aWF0aW9uPyBXb3Vs
ZCB0aGVyZSBiZSBzZWN1cml0eSBvciBzYWZldHkgaW1wbGljYXRpb25zIHdoZW4NCj4gZXhwZXJp
bWVudGluZyB3aXRoIEFjY0VDTiBpbiBuZXR3b3JrcyB1c2luZyBuZXR3b3JrIG1vbml0b3Jpbmcg
c29sdXRpb25zDQo+IHRoYXQgb25seSBzdXBwb3J0IEVDTiBhcyBzdGFuZGFyZGl6ZWQgYnkgdGhl
IElFVEY/DQo+ID4NCj4gDQo+IEZvciB0aGUgc2FmZXR5IGFzcGVjdCwgaWYgYSBtaWRkbGVib3gg
bWVkZGxlcyB3aXRoIHRoZSB0Y3AgaGVhZGVyIGJpdHMsIGFuZA0KPiBkb2Vzbid0IGZvcndhcmQg
c2VnbWVudHMgd2l0aCBzcGVjaWZpYyBBQ0UgZmllbGQgY29kZXBvaW50cywgYSByZWFzb25hYmxl
DQo+IHJlc3BvbnNlIHdvdWxkIGJlIHRvIHJlc2VuZCB0aGUgc2Vjb25kIG9yIHRoaXJkIHJldHJh
bnNtaXNzaW9uIHdpdGggRUNODQo+IGRpc2FibGVkLCBhbmQgZGlzYWJsZSBFQ04gZm9yIHRoZSBy
ZW1haW5kZXIgb2YgdGhlIHNlc3Npb24uIEhvd2V2ZXIsIG5vbmUNCj4gb2YgdGhlIGxhcmdlIHNj
YWxlIG1lYXN1cmVtZW50cyBjb25kdWN0ZWQgc28gZmFyIGhhcyBmb3VuZCBhbiBpbmRpY2F0aW9u
IG9mDQo+IHN1Y2ggYSBtaWRkbGVib3ggbWlzYmVoYXZpb3IgdG8gd2FycmFudCB0ZXh0IGhlcmUu
IFRoZSByZWd1bGFyIEFjY0VDTg0KPiBuZWdvdGlhdGlvbiB3aWxsIGNhcHR1cmUgYWxsIGtub3du
IG1pc2JlaGF2aW5nIG1pZGRsZWJveGVzLg0KDQpUaGlzIGNvbW1lbnQgaXMgbm90IGFib3V0IG1p
ZGRsZWJveGVzOyBpdCBpcyBhYm91dCBwYXNzaXZlIG5ldHdvcmsgbW9uaXRvcmluZyBmb3IgdHJh
ZmZpYyBlbmdpbmVlcmluZy4NCg0KPiBBcyB0byB0aGUgcGFzc2l2ZSBtb25pdG9yaW5nIC0gTWly
amEgYW5kIEJyaWFuIHdpbGwgY2VydGFpbmx5IGV4cGFuZCBvbiB0aGlzLA0KPiBidXQgc2FtcGxp
bmcgZXZlciBzbyBvZnRlbiBzaG91bGQgZXhwb3NlIEFDRSBmaWVsZCBjb2RlcG9pbnRzIHdpdGgg
aGlnaA0KPiBwcm9iYWJpbGl0eSwgd2hpY2ggYXJlIHVubGlrZWx5IG9yIG5vdCBwb3NzaWJsZSB3
aXRoIFJGQzMxNjggRUNOIChlLmcuIENXUiArDQo+IEVDRSBpcyB2ZXJ5IHVubGlrZWx5IC0gcHVy
ZSBBQ0tzIGFyZSBub3QgRUNUIG1hcmtlZCBpbiBSRkMzMTY4LCBhbmQNCj4gYmlkaXJlY3Rpb25h
bCBkYXRhIGV4Y2hhbmdlIHdpdGhvdXQgc3RyZXRjaGVzIG9mIHB1cmUgYWNrcyBpcyBub3QgY29t
bW9uKSwNCj4gYW55dGhpbmcgd2l0aCB0aGUgZm9ybWVyICJOUyIgYml0IHNldCBoYXMgbmV2ZXIg
YmVlbiBvYnNlcnZlZCBvbiB0aGUgcHVibGljDQo+IGludGVybmV0IHRvIG15IGtub3dsZWRnZS4g
VG8gc3VtbWFyaXplIHJhbmRvbSBzYW1wbGluZyBoYXMgYXQgbGVhc3QgYQ0KPiA1Lzh0aCBjaGFu
Y2UgdG8gZGV0ZWN0IEFjY0VDTi4gSG93ZXZlciwgYXMgci5jZXAgKHNlY3Rpb24gMy4yKSBpcyBp
bml0aWFsaXplZCB0bw0KPiBhIHZhbHVlIG9mIDUgKDEwMWIpLCBhbmQgbWFueSAoc2hvcnQpIGZs
b3dzIHByb2JhYmx5IHJhcmVseSBlbmNvdW50ZXIgYSBDRQ0KPiBtYXJrLCB0aGUgY2hhbmNlIHRv
IGRldGVjdCwgYnkgcmFuZG9tIHNhbXBsaW5nLCB0aGUgcHJlc2VuY2Ugb2YgQWNjRUNODQo+IHBh
c3NpdmVseSBpcyBldmVuIGhpZ2hlciB0aGFuIHRoaXMuICBTaG9ydCBmbG93IHdpdGggdXAgdG8g
MiBDRSBtYXJrcyBhcmUNCj4gaW1tZWRpYXRlbHkgZGV0ZWN0YWJsZSwgYXMgdGhlIGZvcm1lciAi
TlMiIGJpdCByZW1haW5zIHNldC4NCg0KVG8gbWUsIHRoaXMgc29ydCBvZiBkaXNjdXNzaW9uIGJl
bG9uZ3MgaW50byB0aGUgZG9jdW1lbnQuDQoNCj4gQXMgdG8gdGhlIHBhc3NpdmUgbW9uaXRvcmlu
ZyBvZiB0aGUgY29uZ2VzdGlvbiBsZXZlbHMgLSB0aGUgc2FtZSBwcm9ibGVtIG9mDQo+IGhhdmlu
ZyBvbmx5IDEgYml0IHNpZ25hbCBwZXIgUlRUIGFwcGxpZXMgaGVyZSB0b28sIG5vdD8gQWxzbywg
eW91IHByb2JhYmx5DQo+IGRvbid0IGtub3cgd2hlcmUgdGhlIGNvbmdlc3Rpb24gcG9pbnQgKGRv
aW5nIHRoZSBDRSBtYXJrcykgaXMgZnJvbSB5b3VyDQo+IHZhbnRhZ2UgcG9pbnQsIGJ1dCBsb29r
aW5nIGF0IHRoZSBUQ1AgaGVhZGVyIGZsYWdzIHRvIGVzdGltYXRlIHRoZSBjb25nZXN0aW9uDQo+
IGxldmVscyBpcyBJTUhPIG5vdCB0aGUgY29ycmVjdCBhcHByb2FjaCAtIGZvciB0aGF0LCB5b3Un
ZCB3YW50IHRvIGV2YWx1YXRlIHRoZQ0KPiBJUCBoZWFkZXIgIkNFIiBtYXJrcywgYW5kIEFjY0VD
TiBkb2VzIG5vdCBjaGFuZ2UgdGhhdCBhdCBhbGwuLi4NCg0KQWdyZWVkLCBidXQgaXQgbWF5IG5v
dCBiZSBlYXN5IHRvIGZpZ3VyZSBvdXQgaWYgc29tZSBwYXNzaXZlIG1vbml0b3Jpbmcgc29sdXRp
b24gc3RpbGwgYW5hbHl6ZXMgdGhlIHN0YW5kYXJkaXplZCBFQ04gYml0cyBpbiB0aGUgVENQIGhl
YWRlci4NCg0KTWljaGFlbA0KDQo+IElmIGFueXRoaW5nLCBBY2NFQ04gc2hvdWxkIGltcHJvdmUg
dGhlIHBhc3NpdmUgbW9uaXRvcmluZyBvZiBjb25nZXN0aW9uDQo+ICpsZXZlbHMqIChvbiBhc3lt
ZXRyaWMgcGF0aHMpIGFzIG5vdyB0aGUgbW9uaXRvcmluZyBwb2ludCBjYW4gdHJhY2sgZWFjaCBD
RQ0KPiBpbiB0aGUgcmV2ZXJzZSBwYXRoOyBmb3JtZXJseSwgeW91IGNvdWxkIG9ubHkgdXNlIHRo
ZSBzdHJlYW0gb2YgRUNFcyB0bw0KPiBlc3RpbWF0ZSB0aGUgY29ubmVjdGlvbiByZWNlaXZlIHdp
bmRvdyAoc3BpbiBiaXQpLCBidXQgbm90IHRoZSBleHRlbnQgb2YNCj4gY29uZ2VzdGlvbiBpbiB0
aGUgbmV0d29yay4uLg0KPiANCj4gVGhpcyAiZm9ybWVyIHVzZSIgb2YgdGhlIEVDRSBiaXQgY291
bGQgYmUgdGFrZW4gb3ZlciBieSBhIGRpZmZlcmVudCBzaWduYWwgLQ0KPiBzZWUgaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRyYW1tZWxsLXRzdndnLXNwaW4gOikNCj4gDQo+IEJl
c3QgcmVnYXJkcywNCj4gICAgUmljaGFyZA0KPiANCj4gDQo+IA0KPiANCg0K


From nobody Mon Jul 16 16:13:00 2018
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 6F986130EDF; Mon, 16 Jul 2018 16:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 KU2pzzPlGGFi; Mon, 16 Jul 2018 16:12:54 -0700 (PDT)
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 9BD8D126BED; Mon, 16 Jul 2018 16:12:54 -0700 (PDT)
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:To:Subject: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=+3+uXbZefwxXBfOfsTokmzU410UGwWWczKYsUH3YuS4=; b=6Mly/cCrjTC5ioatNg+hraviY sh2e2KcjTVuuWh72TK4UTpcRr3/0a2X2fusVUA+3gID3z9DXijFTSHCGUDj8VGekTaGak+hmgXrXD VQMM3gTAQoow0f+e2ppJ7IYIxcJnMUzqSJbS3xoLvrORX4tI+W5OczGffXsdcK8uj7z0OsYcDUicf Xm8wR8OHKoXg4QVxfgxmYXF1JCHbryOc1qpa+sya7rDJQY2JqHkm4wHPSxIbbzI5Pj/FV18IYARXb KTMW1VBhZNkvHnIHohysFmc2D8I7kFqfUA2ekXrA7p8J+ZCyofM4bo/e6r9dT1VjuOpdZfrZ/7hbS QRRC733Ng==;
Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:50634) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffCfk-0001vd-Ab; Tue, 17 Jul 2018 00:12:52 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "Scheffenegger, Richard" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at> 
From: Bob Briscoe 
Message-ID: <6da3bc63-7720-2d5a-7cf4-dc79c791e9c7@bobbriscoe.net>
Date: Mon, 16 Jul 2018 19:12:50 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E5B57CACC3C1581A934645A1"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 16 Jul 2018 23:12:58 -0000

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

Michael,

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:rs.ietf@gmx.at]
> Sent: Monday, July 16, 2018 11:16 AM
> To: Scharf, Michael (Nokia - DE/Stuttgart);
> draft-ietf-tcpm-accurate-ecn@ietf.org;tcpm@ietf.org
> Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Hi Michael,
On 16/07/18 13:48, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>> Section 7.  Security Considerations
>>>
>>> [ms] I wonder about the security implications of "confusing" classic ECN
>>> and AccECN feedback in (passive) network monitoring solutions,
>>>
[snip]
>> [RS] As to the passive monitoring - Mirja and Brian will certainly expand on this,
>> but sampling ever so often should expose ACE field codepoints with high
>> probability, which are unlikely or not possible with RFC3168 ECN (e.g. CWR +
>> ECE is very unlikely - pure ACKs are not ECT marked in RFC3168, and
>> bidirectional data exchange without stretches of pure acks is not common),
>> anything with the former "NS" bit set has never been observed on the public
>> internet to my knowledge. To summarize random sampling has at least a
>> 5/8th chance to detect AccECN. However, as r.cep (section 3.2) is initialized to
>> a value of 5 (101b), and many (short) flows probably rarely encounter a CE
>> mark, the chance to detect, by random sampling, the presence of AccECN
>> passively is even higher than this.  Short flow with up to 2 CE marks are
>> immediately detectable, as the former "NS" bit remains set.
> [ms] To me, this sort of discussion belongs into the document.
>
[BB] Although it's interesting to consider whether passive monitoring 
would be able to detect a difference between one version of a protocol 
and another, I think any discussion of that belongs in a draft about 
passive monitoring, or in mailing list discussion (as here). Not in a 
protocol spec.

We can't be expected to have to ensure that new protocols can be 
distinguished from old protocols by monitoring systems that haven't been 
properly programmed to look for the protocol negotiation during the 
handshake. If such a monitoring system is controlling something critical 
and it's not monitoring correctly, that is surely a safety issue with 
the monitoring system, not with the new protocol.

Having just been talking to a colleague who set up the monitoring 
systems for a mobile operator, the first and most obvious thing they do 
is look for the flow starts.




Bob


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


--------------E5B57CACC3C1581A934645A1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Michael,

    

    

      
-----Original Message-----
From: Scheffenegger, Richard [mailto:rs.ietf@gmx.at]
Sent: Monday, July 16, 2018 11:16 AM
To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>;
draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Hi Michael,


    

    
On 16/07/18 13:48, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      

        

          
Section 7.  Security Considerations

[ms] I wonder about the security implications of "confusing" classic ECN 
and AccECN feedback in (passive) network monitoring solutions, 



        

      

    

    [snip]
    

      

        
[RS] As to the passive monitoring - Mirja and Brian will certainly expand on this,
but sampling ever so often should expose ACE field codepoints with high
probability, which are unlikely or not possible with RFC3168 ECN (e.g. CWR +
ECE is very unlikely - pure ACKs are not ECT marked in RFC3168, and
bidirectional data exchange without stretches of pure acks is not common),
anything with the former "NS" bit set has never been observed on the public
internet to my knowledge. To summarize random sampling has at least a
5/8th chance to detect AccECN. However, as r.cep (section 3.2) is initialized to
a value of 5 (101b), and many (short) flows probably rarely encounter a CE
mark, the chance to detect, by random sampling, the presence of AccECN
passively is even higher than this.  Short flow with up to 2 CE marks are
immediately detectable, as the former "NS" bit remains set.


      

      
[ms] To me, this sort of discussion belongs into the document.



    

    [BB] Although it's interesting to consider whether passive
    monitoring would be able to detect a difference between one version
    of a protocol and another, I think any discussion of that belongs in
    a draft about passive monitoring, or in mailing list discussion (as
    here). Not in a protocol spec.

    

    We can't be expected to have to ensure that new protocols can be
    distinguished from old protocols by monitoring systems that haven't
    been properly programmed to look for the protocol negotiation during
    the handshake. If such a monitoring system is controlling something
    critical and it's not monitoring correctly, that is surely a safety
    issue with the monitoring system, not with the new protocol.

    

    Having just been talking to a colleague who set up the monitoring
    systems for a mobile operator, the first and most obvious thing they
    do is look for the flow starts.

    

    

    

    

    Bob

    

    

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

  


--------------E5B57CACC3C1581A934645A1--


From nobody Mon Jul 16 16:34:11 2018
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 DA582130E64; Mon, 16 Jul 2018 16:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 8-k609AdvJ6u; Mon, 16 Jul 2018 16:34:07 -0700 (PDT)
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 110A1130E12; Mon, 16 Jul 2018 16:34:07 -0700 (PDT)
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:To:Subject: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=Q9uUKRWxl1scHYi5vl4WNBxbyjvTlXIruEtS/4GzaDw=; b=kg568yhw+22L0tw8TbJ4QwV8j 8tEHxjB99EBaHKoCp1GUCBKJtavRQ8aMIEDktBKtLfibYBlJlq42Xvoa8MK31nv/RbimtCCVH129Y JqVbiL1RwZoeIf8ZX4OY1ojWC+u0VvcajgCz0lZZqdEwl6xGk7gbmib3ZarhZA2npws03PbZwFy32 JBanemOalCLbH5WH3Gn8UNP2NWrfnirE2AX7XfJJn9PcrxU6SE5RTrkzfNLR0LvH7eT+mHxh47Q2t zONo0Shcc7CLJEdPYBYY5YEB5cLboM3ssu1wUsbghz+cuCojyMjMTI7MyAEkMfI5BX9mJTANXi+ol beLT3gkLQ==;
Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:50728) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffD0F-0003NT-Ku; Tue, 17 Jul 2018 00:34:03 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References: 
From: Bob Briscoe 
Message-ID: <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>
Date: Mon, 16 Jul 2018 19:34:02 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------69150EB487B3EB83CAC68FB2"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 16 Jul 2018 23:34:10 -0000

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

Michael,

On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> Hi all,
>
> While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>
>
> Section 1. Introduction
>
>     It is likely (but not required) that the AccECN protocol will be
>     implemented along with the following experimental additions to the
>     TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>     [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
>     ACK experiment [RFC5562]; and testing receiver non-compliance
>     [I-D.moncaster-tcpm-rcv-cheat].
>
> [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

I agree. For ECN++, I think something like your suggestion of "useful", 
or even RECOMMENDED is what is needed here. I think the testing receiver 
compliance one could be removed from the intro. It's mentioned under 
testing for unexpected interference and under integrity checking, which 
are sufficient.

Also, this makes me notice that the word "includes" is wrong. ECN++ 
intends to obsolete RFC5562, but I don't think we need to mention that 
here (cos it might change before ECN++ gets published).

CURRENT TEXT:

    It is likely (but not required) that the AccECN protocol will be
    implemented along with the following experimental additions to the
    TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
    [I-D.ietf-tcpm-generalized-ecn 
], which includes the ECN-capable SYN/
    ACK experiment [RFC5562 ]; and testing receiver non-compliance
    [I-D.moncaster-tcpm-rcv-cheat 
].

PROPOSED TEXT:

    It is RECOMMENDED that the AccECN protocol is implemented along with
    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
].


>
>
> Section 2.1.  Capability Negotiation
>     
>     The TCP server sends the AccECN
>     Option on the SYN/ACK and the client sends it on the first ACK to
>     test whether the network path forwards the option correctly.
>
> [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
OK, we need to review section 2, to ensure it is consistent with changes 
that have been made in the normative section 3 since it was written.

In this particular case, we already promised to check (offlist with an 
implementer) that there was no text that contradicted the optionality of 
the option stated at the end of Section 3.2.6.

I have already started this with a list I prepared (also offlist) of 
which middlebox checking sections an implementer could ignore if they 
were only reading but not sending the TCP options.




Bob


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


--------------69150EB487B3EB83CAC68FB2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    
On 15/07/18 16:54, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      
Hi all,

While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:


Section 1. Introduction

   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
   ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].

[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

    

    

    I agree. For ECN++, I think something like your suggestion of
    "useful", or even RECOMMENDED is what is needed here. I think the
    testing receiver compliance one could be removed from the intro.
    It's mentioned under testing for unexpected interference and under
    integrity checking, which are sufficient. 

    

    Also, this makes me notice that the word "includes" is wrong. ECN++
    intends to obsolete RFC5562, but I don't think we need to mention
    that here (cos it might change before ECN++ gets published).

    

    CURRENT TEXT:

    
   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
   ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].

    PROPOSED TEXT:

    
   It is RECOMMENDED that the AccECN protocol is implemented along with
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

    

    

      


Section 2.1.  Capability Negotiation
   
   The TCP server sends the AccECN
   Option on the SYN/ACK and the client sends it on the first ACK to
   test whether the network path forwards the option correctly.

[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.


    

    OK, we need to review section 2, to ensure it is consistent with
    changes that have been made in the normative section 3 since it was
    written.

    

    In this particular case, we already promised to check (offlist with
    an implementer) that there was no text that contradicted the
    optionality of the option stated at the end of Section 3.2.6.

    

    I have already started this with a list I prepared (also offlist) of
    which middlebox checking sections an implementer could ignore if
    they were only reading but not sending the TCP options.

    

    

    

    

    Bob

    

    

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

  


--------------69150EB487B3EB83CAC68FB2--


From nobody Mon Jul 16 22:04:14 2018
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 EBCDB130F35; Mon, 16 Jul 2018 22:04:02 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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=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 y9cTYN7c0Nq2; Mon, 16 Jul 2018 22:03:59 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50116.outbound.protection.outlook.com [40.107.5.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5519413126F; Mon, 16 Jul 2018 22:03:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cw2fSUlpezO9UQq5tCQOPTy3xrxLRXfTFITIFHrODLY=; b=hOZntYjBwczfhd9/GlO9128Dbsftgl95L3TNDttfn5h+4gTpW+GGTT41XXVDo9o5yo6fx7hiLJnBbRl32RqQrzYjimFN6QiUiMihXpVbkfNHGbn0DJryupU61q3lmI5lIcmQgwnwsnsPBoKsTKwSD5BDFzMR/fa/8qhbC9vZzGE=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB4111.eurprd07.prod.outlook.com (52.134.21.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Tue, 17 Jul 2018 05:03:55 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.013; Tue, 17 Jul 2018 05:03:55 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe , "Scheffenegger, Richard" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgAbKySAABFOwRAAC+6MAAALpqVw
Date: Tue, 17 Jul 2018 05:03:55 +0000
Message-ID: 
References:  <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at>  <6da3bc63-7720-2d5a-7cf4-dc79c791e9c7@bobbriscoe.net>
In-Reply-To: <6da3bc63-7720-2d5a-7cf4-dc79c791e9c7@bobbriscoe.net>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [92.203.174.125]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4111; 6:alxaxvTQUnP+wN1hRvuWWyafUMpdMKCXV+AnBYdHVWyFc5TbZ0RwC3ZFUlbsgxgZFp9QdRP7/rY+DmwTDdJwoIQQ+ZMJ8DTkWLVsaNk+zBpRtdzxtN2aTBSrgpZTygpmVR9DXg7g20v0IZTNVDFHVHxeLbS1vvMunP/jkr3FGLmFyfacmSDc9vurcgGPws8RdLEyBJIt+qr1Y7VShpI4VblRhPGfczldnO21CyR2s8Jchu8m7hB9In17mXs7G7ExW0Q01AWYSKX/eJta5Tc/tlxoPbblu0w/nmprUuxiaxGYGWIPLX+fgT8g5ikVyaxVjPxD4sdnD18uzoDPE05/Vj0MrKS7/yf0a3n9I81SJSpCvvj5Qdpjvm8TseVjKviXCpt1xe3mMLcYWfIiAH6ZC1G8hmyvAoW5tSI20K7CSimrCePCjlnfOCYbXRNHaxr14DKZz/Yco6rpveOmw7pKDw==; 5:378pD7lpzVuEIvgOBI9DxSgd59JL9ejGqme4pPMH0gN9u1UXb/xWaJv3otwsfjea1TOWqQQcJwm+VhO05lFQDRDVImPOYkZFN2DspeulPjujdm7u2cjT99LewcYA1UmFlwDfYr09YWgDZ0LhuXTrDy+zJ37iinNPv+Db1SOTLDY=; 7:itWYSeqFoWeAriZdho/Sul5Kr5PUPJiYY2NRcnFb7WhDD4U6ZfJyhdO+ZkweMFj77Ke5yOq8GpNacfFm1fF8nJV7K6TplLKk1saPF7t2JsLEDpUxRe3EGLdEXNQehEAkD0gaZon8FtYyAldPoxT3lKpxHE6vhpQWUmigaDpzSdWKRiYYMO5fBcn3NoUn8VLU1NlMCn2ynT1FJt+VVzjuXpjD7ZKjfqNEEnrKJUiw4PerDcReHwd48inrN5znibGe
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 5ad796ca-0090-4a63-eca4-08d5eba2b267
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR07MB4111; 
x-ms-traffictypediagnostic: VI1PR07MB4111:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(72170088055959)(192374486261705)(82608151540597)(109105607167333)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB4111; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4111; 
x-forefront-prvs: 073631BD3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(366004)(39860400002)(396003)(13464003)(189003)(199004)(7736002)(110136005)(11346002)(2501003)(476003)(486006)(74316002)(446003)(99286004)(2201001)(2900100001)(14454004)(966005)(5250100002)(6116002)(5660300001)(3846002)(86362001)(478600001)(93886005)(2906002)(316002)(790700001)(105586002)(8676002)(106356001)(97736004)(7696005)(26005)(6436002)(81156014)(81166006)(229853002)(8936002)(76176011)(606006)(256004)(68736007)(53936002)(25786009)(14444005)(6506007)(53546011)(102836004)(66066001)(9686003)(236005)(186003)(33656002)(53376002)(6246003)(55016002)(54896002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4111; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ayYq+pIb61QBeMErZ6j5SSByo57BR4ZXwyGKVc9M104cWeuD72sxyFjfyHlnkoalhxunJ+jNgNf3tXrXndXACLtz8TnP8BaGr7DdElOlhm0W2tPVHcxxLSa9yzQeDZV/de1+ylr7N1DEJUnW0A9CNC0jcuqHi9RXmQOlEDzPhqqqARcHruBiaf6ZlQ2pwRES49RYjB/G2BBu787nUZxZF+zOa3WS890qvm5KC3u2Pj22ZfntvicTR053WvHFjbMNNWjMJdQUbWyeRRrf/8tdKYPkQL53pcYoqEDzzgU7PXaGkAqQGF2Mprh7jyczPWAWv4r14rkt3DxHkaY8KMl33abHTPnq3GDnAJegjZb+uJxYeAojbN99lYpM1YEb6LYrQ4ZNF2KuyXsAEaE1dwheMQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB0880117F1E022DB8B7A6C987935C0VI1PR07MB0880eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ad796ca-0090-4a63-eca4-08d5eba2b267
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 05:03:55.1966 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4111
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 05:04:12 -0000

--_000_VI1PR07MB0880117F1E022DB8B7A6C987935C0VI1PR07MB0880eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBkaXNhZ3JlZS4gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGRlc2lnbiBhIHBy
b3RvY29sIHNwZWMgdGhhdCBpcyBtb3JlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBzdGFuZGFy
ZGl6ZWQgRUNOIG9uIHRoZSB3aXJlLCB3aGljaCB3b3VsZCBub3QgY2F1c2UgaXNzdWUgdG8gKHBv
dGVudGlhbGx5KSBkZXBsb3llZCBwYXNzaXZlIG1vbml0b3Jpbmcgc3lzdGVtcyB0aGF0IHVzZSBw
YWNrZXQgc2FtcGxpbmcuIFN1Y2ggcGFzc2l2ZSBtb25pdG9yaW5nIHN5c3RlbXMgY291bGQgZS5n
LiBtYWtlIHdyb25nIHRyYWZmaWMgZW5naW5lZXJpbmcgZGVjaXNpb25zIGJlY2F1c2UgdGhlIFRD
UCBjb25uZWN0aW9uIGlzIG5vdCBjb21wbGlhbnQgdG8gdGhlIEVDTiBzdGFuZGFyZHMuIEFub21h
bHkgZGV0ZWN0aW9uIGNvdWxkIGFsc28gYmUgdHJpZ2dlcmVkIGFzIHRoZSBUQ1AgaGVhZGVyIG9m
IHBhY2tldHMgZGV2aWF0ZXMgZnJvbSB0aGUgSUVURiBzdGFuZGFyZHMuIER1ZSB0byB0aGUgbGlt
aXRlZCBkZXBsb3ltZW50IG9mIEVDTiwgaXQgaXMgcG9zc2libGUgdGhhdCB0aGlzIGlzIG5vdCBh
biBpbXBvcnRhbnQgcHJvYmxlbS4NCg0KWWV0LCBpdCBpcyBhIGRlc2lnbiBjaG9pY2Ugb2YgdGhl
IHByb3RvY29sIHRoYXQgd2l0aGluIGEgc2FtcGxlZCBwYWNrZXQgc3RyZWFtIHN0YW5kYXJkaXpl
ZCBFQ04gY2Fubm90IGJlIGRpc3Rpbmd1aXNoZWQgZnJvbSB0aGUgcHJvcG9zZWQgZXhwZXJpbWVu
dCwgYW5kIHRoYXQgdGhlIGV4cGVyaW1lbnRhbCBUQ1AgaGVhZGVyIGVuY29kaW5nIG9uIHRoZSB3
aXJlIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlIHRvIHRoZSBleGlzdGluZyBzdGFuZGFyZHMu
DQoNCkkgYmVsaWV2ZSBhIGRpc2N1c3Npb24gb24gcG90ZW50aWFsIG9wZXJhdGlvbmFsIGltcGFj
dCBvbiBwb3RlbnRpYWxseSBkZXBsb3llZCBzeXN0ZW1zIGJlbG9uZyBpbnRvIHRoZSBkb2N1bWVu
dCwgZS5nLiwgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSB0ZXh0IG9mIFJpY2hhcmQgaGFzIHdyaXR0
ZW4uDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmluQGJvYmJyaXNj
b2UubmV0XQ0KU2VudDogVHVlc2RheSwgSnVseSAxNywgMjAxOCAxOjEzIEFNDQpUbzogU2NoYXJm
LCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNv
bT47IFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQgPHJzLmlldGZAZ214LmF0PjsgZHJhZnQtaWV0Zi10
Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZzsgdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0
Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24NCg0K
TWljaGFlbCwNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IFNjaGVm
ZmVuZWdnZXIsIFJpY2hhcmQgW21haWx0bzpycy5pZXRmQGdteC5hdF0NCg0KU2VudDogTW9uZGF5
LCBKdWx5IDE2LCAyMDE4IDExOjE2IEFNDQoNClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0g
REUvU3R1dHRnYXJ0KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPjxtYWlsdG86bWljaGFlbC5z
Y2hhcmZAbm9raWEuY29tPjsNCg0KZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9y
ZzxtYWlsdG86ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZz47IHRjcG1AaWV0
Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbdGNwbV0gRnVydGhl
ciBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQoNCg0KDQpIaSBNaWNo
YWVsLA0KT24gMTYvMDcvMTggMTM6NDgsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0
dGdhcnQpIHdyb3RlOg0KDQpTZWN0aW9uIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQoN
Cg0KW21zXSBJIHdvbmRlciBhYm91dCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mICJjb25m
dXNpbmciIGNsYXNzaWMgRUNODQoNCmFuZCBBY2NFQ04gZmVlZGJhY2sgaW4gKHBhc3NpdmUpIG5l
dHdvcmsgbW9uaXRvcmluZyBzb2x1dGlvbnMsDQoNCg0KW3NuaXBdDQoNCltSU10gQXMgdG8gdGhl
IHBhc3NpdmUgbW9uaXRvcmluZyAtIE1pcmphIGFuZCBCcmlhbiB3aWxsIGNlcnRhaW5seSBleHBh
bmQgb24gdGhpcywNCg0KYnV0IHNhbXBsaW5nIGV2ZXIgc28gb2Z0ZW4gc2hvdWxkIGV4cG9zZSBB
Q0UgZmllbGQgY29kZXBvaW50cyB3aXRoIGhpZ2gNCg0KcHJvYmFiaWxpdHksIHdoaWNoIGFyZSB1
bmxpa2VseSBvciBub3QgcG9zc2libGUgd2l0aCBSRkMzMTY4IEVDTiAoZS5nLiBDV1IgKw0KDQpF
Q0UgaXMgdmVyeSB1bmxpa2VseSAtIHB1cmUgQUNLcyBhcmUgbm90IEVDVCBtYXJrZWQgaW4gUkZD
MzE2OCwgYW5kDQoNCmJpZGlyZWN0aW9uYWwgZGF0YSBleGNoYW5nZSB3aXRob3V0IHN0cmV0Y2hl
cyBvZiBwdXJlIGFja3MgaXMgbm90IGNvbW1vbiksDQoNCmFueXRoaW5nIHdpdGggdGhlIGZvcm1l
ciAiTlMiIGJpdCBzZXQgaGFzIG5ldmVyIGJlZW4gb2JzZXJ2ZWQgb24gdGhlIHB1YmxpYw0KDQpp
bnRlcm5ldCB0byBteSBrbm93bGVkZ2UuIFRvIHN1bW1hcml6ZSByYW5kb20gc2FtcGxpbmcgaGFz
IGF0IGxlYXN0IGENCg0KNS84dGggY2hhbmNlIHRvIGRldGVjdCBBY2NFQ04uIEhvd2V2ZXIsIGFz
IHIuY2VwIChzZWN0aW9uIDMuMikgaXMgaW5pdGlhbGl6ZWQgdG8NCg0KYSB2YWx1ZSBvZiA1ICgx
MDFiKSwgYW5kIG1hbnkgKHNob3J0KSBmbG93cyBwcm9iYWJseSByYXJlbHkgZW5jb3VudGVyIGEg
Q0UNCg0KbWFyaywgdGhlIGNoYW5jZSB0byBkZXRlY3QsIGJ5IHJhbmRvbSBzYW1wbGluZywgdGhl
IHByZXNlbmNlIG9mIEFjY0VDTg0KDQpwYXNzaXZlbHkgaXMgZXZlbiBoaWdoZXIgdGhhbiB0aGlz
LiAgU2hvcnQgZmxvdyB3aXRoIHVwIHRvIDIgQ0UgbWFya3MgYXJlDQoNCmltbWVkaWF0ZWx5IGRl
dGVjdGFibGUsIGFzIHRoZSBmb3JtZXIgIk5TIiBiaXQgcmVtYWlucyBzZXQuDQoNClttc10gVG8g
bWUsIHRoaXMgc29ydCBvZiBkaXNjdXNzaW9uIGJlbG9uZ3MgaW50byB0aGUgZG9jdW1lbnQuDQoN
Cg0KW0JCXSBBbHRob3VnaCBpdCdzIGludGVyZXN0aW5nIHRvIGNvbnNpZGVyIHdoZXRoZXIgcGFz
c2l2ZSBtb25pdG9yaW5nIHdvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IGEgZGlmZmVyZW5jZSBiZXR3
ZWVuIG9uZSB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wgYW5kIGFub3RoZXIsIEkgdGhpbmsgYW55IGRp
c2N1c3Npb24gb2YgdGhhdCBiZWxvbmdzIGluIGEgZHJhZnQgYWJvdXQgcGFzc2l2ZSBtb25pdG9y
aW5nLCBvciBpbiBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiAoYXMgaGVyZSkuIE5vdCBpbiBhIHBy
b3RvY29sIHNwZWMuDQoNCldlIGNhbid0IGJlIGV4cGVjdGVkIHRvIGhhdmUgdG8gZW5zdXJlIHRo
YXQgbmV3IHByb3RvY29scyBjYW4gYmUgZGlzdGluZ3Vpc2hlZCBmcm9tIG9sZCBwcm90b2NvbHMg
YnkgbW9uaXRvcmluZyBzeXN0ZW1zIHRoYXQgaGF2ZW4ndCBiZWVuIHByb3Blcmx5IHByb2dyYW1t
ZWQgdG8gbG9vayBmb3IgdGhlIHByb3RvY29sIG5lZ290aWF0aW9uIGR1cmluZyB0aGUgaGFuZHNo
YWtlLiBJZiBzdWNoIGEgbW9uaXRvcmluZyBzeXN0ZW0gaXMgY29udHJvbGxpbmcgc29tZXRoaW5n
IGNyaXRpY2FsIGFuZCBpdCdzIG5vdCBtb25pdG9yaW5nIGNvcnJlY3RseSwgdGhhdCBpcyBzdXJl
bHkgYSBzYWZldHkgaXNzdWUgd2l0aCB0aGUgbW9uaXRvcmluZyBzeXN0ZW0sIG5vdCB3aXRoIHRo
ZSBuZXcgcHJvdG9jb2wuDQoNCkhhdmluZyBqdXN0IGJlZW4gdGFsa2luZyB0byBhIGNvbGxlYWd1
ZSB3aG8gc2V0IHVwIHRoZSBtb25pdG9yaW5nIHN5c3RlbXMgZm9yIGEgbW9iaWxlIG9wZXJhdG9y
LCB0aGUgZmlyc3QgYW5kIG1vc3Qgb2J2aW91cyB0aGluZyB0aGV5IGRvIGlzIGxvb2sgZm9yIHRo
ZSBmbG93IHN0YXJ0cy4NCg0KDQoNCg0KQm9iDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9i
IEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2Uu
bmV0Lw0K

--_000_VI1PR07MB0880117F1E022DB8B7A6C987935C0VI1PR07MB0880eurp_
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
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SSBkaXNhZ3JlZS4gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGRlc2lnbiBh
IHByb3RvY29sIHNwZWMgdGhhdCBpcyBtb3JlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBzdGFu
ZGFyZGl6ZWQgRUNOIG9uIHRoZSB3aXJlLCB3aGljaCB3b3VsZCBub3QgY2F1c2UgaXNzdWUgdG8g
KHBvdGVudGlhbGx5KSBkZXBsb3llZCBwYXNzaXZlIG1vbml0b3Jpbmcgc3lzdGVtcyB0aGF0IHVz
ZSBwYWNrZXQgc2FtcGxpbmcuDQogU3VjaCBwYXNzaXZlIG1vbml0b3Jpbmcgc3lzdGVtcyBjb3Vs
ZCBlLmcuIG1ha2Ugd3JvbmcgdHJhZmZpYyBlbmdpbmVlcmluZyBkZWNpc2lvbnMgYmVjYXVzZSB0
aGUgVENQIGNvbm5lY3Rpb24gaXMgbm90IGNvbXBsaWFudCB0byB0aGUgRUNOIHN0YW5kYXJkcy4g
QW5vbWFseSBkZXRlY3Rpb24gY291bGQgYWxzbyBiZSB0cmlnZ2VyZWQgYXMgdGhlIFRDUCBoZWFk
ZXIgb2YgcGFja2V0cyBkZXZpYXRlcyBmcm9tIHRoZSBJRVRGIHN0YW5kYXJkcy4gRHVlDQogdG8g
dGhlIGxpbWl0ZWQgZGVwbG95bWVudCBvZiBFQ04sIGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhpcyBp
cyBub3QgYW4gaW1wb3J0YW50IHByb2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllldCwg
aXQgaXMgYSBkZXNpZ24gY2hvaWNlIG9mIHRoZSBwcm90b2NvbCB0aGF0IHdpdGhpbiBhIHNhbXBs
ZWQgcGFja2V0IHN0cmVhbSBzdGFuZGFyZGl6ZWQgRUNOIGNhbm5vdCBiZSBkaXN0aW5ndWlzaGVk
IGZyb20gdGhlIHByb3Bvc2VkIGV4cGVyaW1lbnQsIGFuZCB0aGF0IHRoZSBleHBlcmltZW50YWwg
VENQIGhlYWRlciBlbmNvZGluZyBvbiB0aGUgd2lyZSBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJs
ZSB0bw0KIHRoZSBleGlzdGluZyBzdGFuZGFyZHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
YmVsaWV2ZSBhIGRpc2N1c3Npb24gb24gcG90ZW50aWFsIG9wZXJhdGlvbmFsIGltcGFjdCBvbiBw
b3RlbnRpYWxseSBkZXBsb3llZCBzeXN0ZW1zIGJlbG9uZyBpbnRvIHRoZSBkb2N1bWVudCwgZS5n
LiwgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSB0ZXh0IG9mIFJpY2hhcmQgaGFzIHdyaXR0ZW4uPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk
ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlz
Y29lIFttYWlsdG86aW5AYm9iYnJpc2NvZS5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh
eSwgSnVseSAxNywgMjAxOCAxOjEzIEFNPGJyPg0KPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwg
KE5va2lhIC0gREUvU3R1dHRnYXJ0KSAmbHQ7bWljaGFlbC5zY2hhcmZAbm9raWEuY29tJmd0Ozsg
U2NoZWZmZW5lZ2dlciwgUmljaGFyZCAmbHQ7cnMuaWV0ZkBnbXguYXQmZ3Q7OyBkcmFmdC1pZXRm
LXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnOyB0Y3BtQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNj
dXJhdGUtZWNuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
TWljaGFlbCw8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IFNjaGVmZmVu
ZWdnZXIsIFJpY2hhcmQgWzxhIGhyZWY9Im1haWx0bzpycy5pZXRmQGdteC5hdCI+bWFpbHRvOnJz
LmlldGZAZ214LmF0PC9hPl08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBNb25kYXksIEp1
bHkgMTYsIDIwMTggMTE6MTYgQU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogU2NoYXJmLCBN
aWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2No
YXJmQG5va2lhLmNvbSI+Jmx0O21pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSZndDs8L2E+OzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRjcG0tYWNjdXJh
dGUtZWNuQGlldGYub3JnIj5kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnPC9h
PjsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9u
IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5IaSBNaWNoYWVsLDxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTYvMDcvMTggMTM6
NDgsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlNlY3Rpb24gNy4mbmJzcDsgU2VjdXJpdHkgQ29u
c2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT5bbXNdIEkgd29uZGVyIGFib3V0IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2Yg
JnF1b3Q7Y29uZnVzaW5nJnF1b3Q7IGNsYXNzaWMgRUNOIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmFuZCBBY2NFQ04gZmVlZGJhY2sgaW4gKHBhc3NpdmUpIG5ldHdvcmsgbW9uaXRvcmluZyBzb2x1
dGlvbnMsIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5bc25pcF0gPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5bUlNdIEFzIHRvIHRoZSBw
YXNzaXZlIG1vbml0b3JpbmcgLSBNaXJqYSBhbmQgQnJpYW4gd2lsbCBjZXJ0YWlubHkgZXhwYW5k
IG9uIHRoaXMsPG86cD48L286cD48L3ByZT4NCjxwcmU+YnV0IHNhbXBsaW5nIGV2ZXIgc28gb2Z0
ZW4gc2hvdWxkIGV4cG9zZSBBQ0UgZmllbGQgY29kZXBvaW50cyB3aXRoIGhpZ2g8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5wcm9iYWJpbGl0eSwgd2hpY2ggYXJlIHVubGlrZWx5IG9yIG5vdCBwb3Nz
aWJsZSB3aXRoIFJGQzMxNjggRUNOIChlLmcuIENXUiAmIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPkVDRSBpcyB2ZXJ5IHVubGlrZWx5IC0gcHVyZSBBQ0tzIGFyZSBub3QgRUNUIG1hcmtlZCBp
biBSRkMzMTY4LCBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iaWRpcmVjdGlvbmFsIGRhdGEg
ZXhjaGFuZ2Ugd2l0aG91dCBzdHJldGNoZXMgb2YgcHVyZSBhY2tzIGlzIG5vdCBjb21tb24pLDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFueXRoaW5nIHdpdGggdGhlIGZvcm1lciAmcXVvdDtOUyZx
dW90OyBiaXQgc2V0IGhhcyBuZXZlciBiZWVuIG9ic2VydmVkIG9uIHRoZSBwdWJsaWM8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5pbnRlcm5ldCB0byBteSBrbm93bGVkZ2UuIFRvIHN1bW1hcml6ZSBy
YW5kb20gc2FtcGxpbmcgaGFzIGF0IGxlYXN0IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT41Lzh0
aCBjaGFuY2UgdG8gZGV0ZWN0IEFjY0VDTi4gSG93ZXZlciwgYXMgci5jZXAgKHNlY3Rpb24gMy4y
KSBpcyBpbml0aWFsaXplZCB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgdmFsdWUgb2YgNSAo
MTAxYiksIGFuZCBtYW55IChzaG9ydCkgZmxvd3MgcHJvYmFibHkgcmFyZWx5IGVuY291bnRlciBh
IENFPG86cD48L286cD48L3ByZT4NCjxwcmU+bWFyaywgdGhlIGNoYW5jZSB0byBkZXRlY3QsIGJ5
IHJhbmRvbSBzYW1wbGluZywgdGhlIHByZXNlbmNlIG9mIEFjY0VDTjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnBhc3NpdmVseSBpcyBldmVuIGhpZ2hlciB0aGFuIHRoaXMuJm5ic3A7IFNob3J0IGZs
b3cgd2l0aCB1cCB0byAyIENFIG1hcmtzIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmltbWVk
aWF0ZWx5IGRldGVjdGFibGUsIGFzIHRoZSBmb3JtZXIgJnF1b3Q7TlMmcXVvdDsgYml0IHJlbWFp
bnMgc2V0LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPlttc10gVG8gbWUs
IHRoaXMgc29ydCBvZiBkaXNjdXNzaW9uIGJlbG9uZ3MgaW50byB0aGUgZG9jdW1lbnQuPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQl0gQWx0aG91Z2ggaXQncyBpbnRlcmVzdGluZyB0byBj
b25zaWRlciB3aGV0aGVyIHBhc3NpdmUgbW9uaXRvcmluZyB3b3VsZCBiZSBhYmxlIHRvIGRldGVj
dCBhIGRpZmZlcmVuY2UgYmV0d2VlbiBvbmUgdmVyc2lvbiBvZiBhIHByb3RvY29sIGFuZCBhbm90
aGVyLCBJIHRoaW5rIGFueSBkaXNjdXNzaW9uIG9mIHRoYXQgYmVsb25ncyBpbiBhIGRyYWZ0IGFi
b3V0IHBhc3NpdmUgbW9uaXRvcmluZywgb3IgaW4NCiBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiAo
YXMgaGVyZSkuIE5vdCBpbiBhIHByb3RvY29sIHNwZWMuPGJyPg0KPGJyPg0KV2UgY2FuJ3QgYmUg
ZXhwZWN0ZWQgdG8gaGF2ZSB0byBlbnN1cmUgdGhhdCBuZXcgcHJvdG9jb2xzIGNhbiBiZSBkaXN0
aW5ndWlzaGVkIGZyb20gb2xkIHByb3RvY29scyBieSBtb25pdG9yaW5nIHN5c3RlbXMgdGhhdCBo
YXZlbid0IGJlZW4gcHJvcGVybHkgcHJvZ3JhbW1lZCB0byBsb29rIGZvciB0aGUgcHJvdG9jb2wg
bmVnb3RpYXRpb24gZHVyaW5nIHRoZSBoYW5kc2hha2UuIElmIHN1Y2ggYSBtb25pdG9yaW5nIHN5
c3RlbSBpcyBjb250cm9sbGluZw0KIHNvbWV0aGluZyBjcml0aWNhbCBhbmQgaXQncyBub3QgbW9u
aXRvcmluZyBjb3JyZWN0bHksIHRoYXQgaXMgc3VyZWx5IGEgc2FmZXR5IGlzc3VlIHdpdGggdGhl
IG1vbml0b3Jpbmcgc3lzdGVtLCBub3Qgd2l0aCB0aGUgbmV3IHByb3RvY29sLjxicj4NCjxicj4N
CkhhdmluZyBqdXN0IGJlZW4gdGFsa2luZyB0byBhIGNvbGxlYWd1ZSB3aG8gc2V0IHVwIHRoZSBt
b25pdG9yaW5nIHN5c3RlbXMgZm9yIGEgbW9iaWxlIG9wZXJhdG9yLCB0aGUgZmlyc3QgYW5kIG1v
c3Qgb2J2aW91cyB0aGluZyB0aGV5IGRvIGlzIGxvb2sgZm9yIHRoZSBmbG93IHN0YXJ0cy48YnI+
DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9i
b2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3By
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_VI1PR07MB0880117F1E022DB8B7A6C987935C0VI1PR07MB0880eurp_--


From nobody Mon Jul 16 22:05:25 2018
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 45A49130F13; Mon, 16 Jul 2018 22:05:24 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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=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 LJLQWBgfpXgI; Mon, 16 Jul 2018 22:05:21 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B012130F11; Mon, 16 Jul 2018 22:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5l95mDRPmbMj3+cPcyYcLjntCcietWMbfh1e5Hbv9k8=; b=qFKE9DL3JvbHawOMWmjV4qHfypRwLJ7+MNO9U9awDjnkq/fgaCzYroqbclzwASg1JOTVhKUQrFm4V+WvbHBv/b0CtKEpklHqsOkxEvSz8ztozP+K2c9s/CeYCget+Koch7KbKm24yjserdZT8J8U8yMrAC6QnfPRAA8Hb4SIvAM=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB4111.eurprd07.prod.outlook.com (52.134.21.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Tue, 17 Jul 2018 05:05:17 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.013; Tue, 17 Jul 2018 05:05:17 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgA5JfwAAAuIsyA=
Date: Tue, 17 Jul 2018 05:05:17 +0000
Message-ID: 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>
In-Reply-To: <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [92.203.174.125]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4111; 6:0R9boLiL78mYoTGt8jenNDS0wHr1Ug7zKsyKC0ZPSVMp4/PDjUzagPJk3hbU/T5lXQ+S7Zt3lOkV/OYPc8pxbAPC2a/XgGBQtIYv5i2iydXZnKJ1AkDYUJQzcegGWR/rTwiylGCdO6gW4hi1c3BW7ycL++oR/TWSt3ue9T3NKEh6lLS8HZTw++JiBfYAan7u91tefE2BSxnHNJHtS96iFsm7nFF/bwbwk8vOaj+SaAcDAaVZQZnbxpTrdlfBVlppQgO3rMRalAdYd3DgCdlBQmDaJfplcTYQtn93uhT7g6tccIUZcfAeX++LT4dEMAWl/Lb9W2XeGLsNJYyPcHVir8qX6esQKXK9dmHMsygg+wU4oobad7CbsjvOqK2FNHjWRVJz/Kix2yBgnw6R+ecZ9lmQMTTqKpNtyych1JC1DLKQqjT651oiAK2o3S3xD/bHIkeLVcGwDz6TXKHZZT3Dxw==; 5:T3ucmRqVJV7zglFw4c/4UmJA+1KRk/0xf41QQmY3KgKzAcnFSScP9B66dcBv8G37EEZKYL8dfdN745aQxISB9Trgbxio9PTMzVlrS5d4Dad/nBoZnqUQWDB18Vlj68He5nM4qp7M3J7GJjNBDPkW/RZERHQwSqegzAlQL2OT2VA=; 7:/5E8bb94NSbpRsejjEyprCjDJdYq9oXt8PF0AEiue+XMHX/nwBPXXPCtOCc8cVCSKDzeH5z0dgPlRPtVP7R1drJbqhJJWK90PvF08CLxFdWfMmvFu1mqZMR2VUNGmTYrV4sxW2Pg8ddxAV6HEbVEMleSjYgPoyepdpzN4GNB3gtLlefify5hlungoQA7eVGNz0TN1LhZRChga9MXtA6T0hs67wMDzPl+a03cdRmG/VxZNF1IT7AK9acPeHPVdYGg
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 854e9c13-f593-4826-4546-08d5eba2e38e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR07MB4111; 
x-ms-traffictypediagnostic: VI1PR07MB4111:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(82608151540597)(109105607167333)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB4111; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4111; 
x-forefront-prvs: 073631BD3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(366004)(39860400002)(396003)(53754006)(189003)(199004)(7736002)(110136005)(11346002)(2501003)(476003)(486006)(74316002)(446003)(99286004)(2201001)(2900100001)(14454004)(966005)(5250100002)(6116002)(5660300001)(3846002)(86362001)(478600001)(2906002)(316002)(790700001)(105586002)(8676002)(106356001)(97736004)(7696005)(26005)(6436002)(81156014)(81166006)(229853002)(8936002)(76176011)(606006)(256004)(68736007)(53936002)(25786009)(14444005)(6506007)(53546011)(102836004)(66066001)(9686003)(236005)(186003)(33656002)(53376002)(6246003)(55016002)(54896002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4111; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: G/zb+ceaZ7lCqKvn7X6nsM5554tMyPuvWDmZukMTzb8ggSs9xQLE6PZPCkt8CoxPhcziQeQry4Up76tW04TY1YMWXuCNtr85ckmjhb6MQ2MfbS67cYZq8miFg6iiZmZBPt/iEZhAmcV4QSG4/yvTykmHhX64G8qdeChj8i8bgIub/U6+mfg7fj+6/Z3GpwK4cetlhbzUpzyfpwwzpxtjUb643C7t5WaGEwrwF2eowBKQWjuvlnpEYVtbyNnXND0F5bloqH0zLepcGC5FRsHz8RZDxnjztZ0upxjwRd4Uv5jAwMG33YsYWHNdzp5O27q/LCrFjZJhZMIYtIZMROkyS0dDvNPg33zVXMehW0+ZYj20VMm2ZkhBr++AAjLHAA85iEoQ0e3imIOKNE58UkN6xA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB0880170EF06C9CE1C63A464C935C0VI1PR07MB0880eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 854e9c13-f593-4826-4546-08d5eba2e38e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 05:05:17.5682 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4111
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 05:05:25 -0000

--_000_VI1PR07MB0880170EF06C9CE1C63A464C935C0VI1PR07MB0880eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyB3b3VsZCBmb3IgZm9yIG1lLg0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQpGcm9tOiBCb2Ig
QnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBUdWVzZGF5LCBKdWx5
IDE3LCAyMDE4IDE6MzQgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRn
YXJ0KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPjsgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRl
LWVjbkBpZXRmLm9yZzsgdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBGdXJ0aGVy
IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24NCg0KTWljaGFlbCwNCk9u
IDE1LzA3LzE4IDE2OjU0LCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSB3
cm90ZToNCg0KSGkgYWxsLA0KDQoNCg0KV2hpbGUgcmVhZGluZyBkcmFmdC1pZXRmLXRjcG0tYWNj
dXJhdGUtZWNuLTA3LCBJIG5vdGljZWQgdGhlIGZvbGxvd2luZzoNCg0KDQoNCg0KDQpTZWN0aW9u
IDEuIEludHJvZHVjdGlvbg0KDQoNCg0KICAgSXQgaXMgbGlrZWx5IChidXQgbm90IHJlcXVpcmVk
KSB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgd2lsbCBiZQ0KDQogICBpbXBsZW1lbnRlZCBhbG9u
ZyB3aXRoIHRoZSBmb2xsb3dpbmcgZXhwZXJpbWVudGFsIGFkZGl0aW9ucyB0byB0aGUNCg0KICAg
VENQLUVDTiBwcm90b2NvbDogRUNOLWNhcGFibGUgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQgcmV0
cmFuc21pc3Npb25zDQoNCiAgIFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbl0sIHdoaWNo
IGluY2x1ZGVzIHRoZSBFQ04tY2FwYWJsZSBTWU4vDQoNCiAgIEFDSyBleHBlcmltZW50IFtSRkM1
NTYyXTsgYW5kIHRlc3RpbmcgcmVjZWl2ZXIgbm9uLWNvbXBsaWFuY2UNCg0KICAgW0ktRC5tb25j
YXN0ZXItdGNwbS1yY3YtY2hlYXRdLg0KDQoNCg0KW21zXSBJIGhhdmUgY29tbWVudGVkIG9uIHRo
aXMgc2VjdGlvbiBiZWZvcmUuIEFuZCBJIHN0aWxsIGRpc2xpa2UgdGhlIHRlcm0gImxpa2VseSIu
IFRvIG1lLCAibGlrZWx5IiBpcyBzcGVjdWxhdGlvbi4gQSBuZXV0cmFsIHBocmFzaW5nIHdvdWxk
IGJlICIuLi4gaXQgaXMgcG9zc2libGUuLi4iIG9yICIuLi4gaXQgaXMgdXNlZnVsLi4uIi4gSGF2
aW5nIHNhaWQgdGhpcywgSSBvYnNlcnZlIHRoYXQgZHJhZnQtbW9uY2FzdGVyLXRjcG0tcmN2LWNo
ZWF0LTAzIHdhcyBsYXN0IHVwZGF0ZWQgaW4gMjAxNC4gSG93ICJsaWtlbHkiIGlzIGl0IHRoYXQg
dGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlIGltcGxlbWVudGVkIGFsb25nIHdpdGggYSBtZWNo
YW5pc20gZG9jdW1lbnRlZCBpbiBhbiBJRCB0aGF0IGhhcyBiZWVuIHdyaXR0ZW4gbW9yZSB0aGFu
IDEwIHllYXJzIGFnbyBhbmQgbm90IGJlZW4gdXBkYXRlZCBmb3IgYWJvdXQgNCB5ZWFycz8gQXJl
IGltcGxlbWVudGVycyBpbmRlZWQgc28gaW50ZXJlc3RlZCBpbiBkcmFmdC1tb25jYXN0ZXItdGNw
bS1yY3YtY2hlYXQgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBpcyAibGlrZWx5Ij8NCg0KSSBhZ3Jl
ZS4gRm9yIEVDTisrLCBJIHRoaW5rIHNvbWV0aGluZyBsaWtlIHlvdXIgc3VnZ2VzdGlvbiBvZiAi
dXNlZnVsIiwgb3IgZXZlbiBSRUNPTU1FTkRFRCBpcyB3aGF0IGlzIG5lZWRlZCBoZXJlLiBJIHRo
aW5rIHRoZSB0ZXN0aW5nIHJlY2VpdmVyIGNvbXBsaWFuY2Ugb25lIGNvdWxkIGJlIHJlbW92ZWQg
ZnJvbSB0aGUgaW50cm8uIEl0J3MgbWVudGlvbmVkIHVuZGVyIHRlc3RpbmcgZm9yIHVuZXhwZWN0
ZWQgaW50ZXJmZXJlbmNlIGFuZCB1bmRlciBpbnRlZ3JpdHkgY2hlY2tpbmcsIHdoaWNoIGFyZSBz
dWZmaWNpZW50Lg0KDQpBbHNvLCB0aGlzIG1ha2VzIG1lIG5vdGljZSB0aGF0IHRoZSB3b3JkICJp
bmNsdWRlcyIgaXMgd3JvbmcuIEVDTisrIGludGVuZHMgdG8gb2Jzb2xldGUgUkZDNTU2MiwgYnV0
IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBtZW50aW9uIHRoYXQgaGVyZSAoY29zIGl0IG1pZ2h0
IGNoYW5nZSBiZWZvcmUgRUNOKysgZ2V0cyBwdWJsaXNoZWQpLg0KDQpDVVJSRU5UIFRFWFQ6DQoN
CiAgIEl0IGlzIGxpa2VseSAoYnV0IG5vdCByZXF1aXJlZCkgdGhhdCB0aGUgQWNjRUNOIHByb3Rv
Y29sIHdpbGwgYmUNCg0KICAgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aCB0aGUgZm9sbG93aW5nIGV4
cGVyaW1lbnRhbCBhZGRpdGlvbnMgdG8gdGhlDQoNCiAgIFRDUC1FQ04gcHJvdG9jb2w6IEVDTi1j
YXBhYmxlIFRDUCBjb250cm9sIHBhY2tldHMgYW5kIHJldHJhbnNtaXNzaW9ucw0KDQogICBbSS1E
LmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6
ZWQtZWNuPl0sIHdoaWNoIGluY2x1ZGVzIHRoZSBFQ04tY2FwYWJsZSBTWU4vDQoNCiAgIEFDSyBl
eHBlcmltZW50IFtSRkM1NTYyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTYyPl07
IGFuZCB0ZXN0aW5nIHJlY2VpdmVyIG5vbi1jb21wbGlhbmNlDQoNCiAgIFtJLUQubW9uY2FzdGVy
LXRjcG0tcmN2LWNoZWF0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRj
cG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQubW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0Pl0uDQpQ
Uk9QT1NFRCBURVhUOg0KDQogICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBBY2NFQ04gcHJv
dG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aA0KDQogICB0aGUgZXhwZXJpbWVudGFsIEVD
TisrIHByb3RvY29sIFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjxodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmll
dGYtdGNwbS1nZW5lcmFsaXplZC1lY24+XS4NCg0KDQoNCg0KDQoNCg0KDQoNClNlY3Rpb24gMi4x
LiAgQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbg0KDQoNCg0KICAgVGhlIFRDUCBzZXJ2ZXIgc2VuZHMg
dGhlIEFjY0VDTg0KDQogICBPcHRpb24gb24gdGhlIFNZTi9BQ0sgYW5kIHRoZSBjbGllbnQgc2Vu
ZHMgaXQgb24gdGhlIGZpcnN0IEFDSyB0bw0KDQogICB0ZXN0IHdoZXRoZXIgdGhlIG5ldHdvcmsg
cGF0aCBmb3J3YXJkcyB0aGUgb3B0aW9uIGNvcnJlY3RseS4NCg0KDQoNClttc10gQWNjb3JkaW5n
IHRvIFNlY3Rpb24gMy4yLjYsIG9wdGlvbnMgYXJlIFJFQ09NTUVOREVELiBXaGlsZSBTZWN0aW9u
IDIgaXMgbm90IG5vcm1hdGl2ZSwgdGhlIHdob2xlIFNlY3Rpb24gMiBkb2VzIG5vdCByZWFsbHkg
ZGVzY3JpYmUgd2VsbCB0aGUgYWN0dWFsIHJlcXVpcmVtZW50cyByZWdhcmRpbmcgb3B0aW9ucy4g
VGhpcyBwYXJhZ3JhcGggaW4gU2VjdGlvbiAyLjEgaXMgb25lIGV4YW1wbGUgZm9yIHRoYXQuIEl0
IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYmUgbW9yZSBleHBsaWNpdCBpbiBTZWN0aW9uIDIgdG8gd2hp
Y2ggZXh0ZW50IG9wdGlvbnMgaGF2ZSB0byBiZSBzdXBwb3J0ZWQuDQpPSywgd2UgbmVlZCB0byBy
ZXZpZXcgc2VjdGlvbiAyLCB0byBlbnN1cmUgaXQgaXMgY29uc2lzdGVudCB3aXRoIGNoYW5nZXMg
dGhhdCBoYXZlIGJlZW4gbWFkZSBpbiB0aGUgbm9ybWF0aXZlIHNlY3Rpb24gMyBzaW5jZSBpdCB3
YXMgd3JpdHRlbi4NCg0KSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHdlIGFscmVhZHkgcHJvbWlz
ZWQgdG8gY2hlY2sgKG9mZmxpc3Qgd2l0aCBhbiBpbXBsZW1lbnRlcikgdGhhdCB0aGVyZSB3YXMg
bm8gdGV4dCB0aGF0IGNvbnRyYWRpY3RlZCB0aGUgb3B0aW9uYWxpdHkgb2YgdGhlIG9wdGlvbiBz
dGF0ZWQgYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDMuMi42Lg0KDQpJIGhhdmUgYWxyZWFkeSBzdGFy
dGVkIHRoaXMgd2l0aCBhIGxpc3QgSSBwcmVwYXJlZCAoYWxzbyBvZmZsaXN0KSBvZiB3aGljaCBt
aWRkbGVib3ggY2hlY2tpbmcgc2VjdGlvbnMgYW4gaW1wbGVtZW50ZXIgY291bGQgaWdub3JlIGlm
IHRoZXkgd2VyZSBvbmx5IHJlYWRpbmcgYnV0IG5vdCBzZW5kaW5nIHRoZSBUQ1Agb3B0aW9ucy4N
Cg0KDQoNCg0KQm9iDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0K

--_000_VI1PR07MB0880170EF06C9CE1C63A464C935C0VI1PR07MB0880eurp_
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
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoaXMgd291bGQgZm9yIGZvciBtZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoYW5rczxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TWljaGFlbDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2Ug
W21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks
IEp1bHkgMTcsIDIwMTggMTozNCBBTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChO
b2tpYSAtIERFL1N0dXR0Z2FydCkgJmx0O21pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSZndDs7IGRy
YWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY25AaWV0Zi5vcmc7IHRjcG1AaWV0Zi5vcmc8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYt
dGNwbS1hY2N1cmF0ZS1lY248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTUvMDcvMTggMTY6NTQsIFNjaGFy
ZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+SGkgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPldoaWxlIHJlYWRpbmcgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRl
LWVjbi0wNywgSSBub3RpY2VkIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+U2VjdGlvbiAxLiBJbnRyb2R1Y3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgSXQgaXMgbGlrZWx5IChidXQgbm90
IHJlcXVpcmVkKSB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgd2lsbCBiZTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIHRoZSBmb2xsb3dp
bmcgZXhwZXJpbWVudGFsIGFkZGl0aW9ucyB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsgVENQLUVDTiBwcm90b2NvbDogRUNOLWNhcGFibGUgVENQIGNvbnRyb2wgcGFj
a2V0cyBhbmQgcmV0cmFuc21pc3Npb25zPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbl0sIHdoaWNoIGluY2x1ZGVzIHRoZSBF
Q04tY2FwYWJsZSBTWU4vPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFDSyBl
eHBlcmltZW50IFtSRkM1NTYyXTsgYW5kIHRlc3RpbmcgcmVjZWl2ZXIgbm9uLWNvbXBsaWFuY2U8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgW0ktRC5tb25jYXN0ZXItdGNwbS1y
Y3YtY2hlYXRdLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPlttc10gSSBoYXZlIGNvbW1lbnRlZCBvbiB0aGlzIHNlY3Rpb24gYmVmb3JlLiBBbmQg
SSBzdGlsbCBkaXNsaWtlIHRoZSB0ZXJtICZxdW90O2xpa2VseSZxdW90Oy4gVG8gbWUsICZxdW90
O2xpa2VseSZxdW90OyBpcyBzcGVjdWxhdGlvbi4gQSBuZXV0cmFsIHBocmFzaW5nIHdvdWxkIGJl
ICZxdW90Oy4uLiBpdCBpcyBwb3NzaWJsZS4uLiZxdW90OyBvciAmcXVvdDsuLi4gaXQgaXMgdXNl
ZnVsLi4uJnF1b3Q7LiBIYXZpbmcgc2FpZCB0aGlzLCBJIG9ic2VydmUgdGhhdCBkcmFmdC1tb25j
YXN0ZXItdGNwbS1yY3YtY2hlYXQtMDMgd2FzIGxhc3QgdXBkYXRlZCBpbiAyMDE0LiBIb3cgJnF1
b3Q7bGlrZWx5JnF1b3Q7IGlzIGl0IHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlIGlt
cGxlbWVudGVkIGFsb25nIHdpdGggYSBtZWNoYW5pc20gZG9jdW1lbnRlZCBpbiBhbiBJRCB0aGF0
IGhhcyBiZWVuIHdyaXR0ZW4gbW9yZSB0aGFuIDEwIHllYXJzIGFnbyBhbmQgbm90IGJlZW4gdXBk
YXRlZCBmb3IgYWJvdXQgNCB5ZWFycz8gQXJlIGltcGxlbWVudGVycyBpbmRlZWQgc28gaW50ZXJl
c3RlZCBpbiBkcmFmdC1tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQgdGhhdCBhbiBpbXBsZW1lbnRh
dGlvbiBpcyAmcXVvdDtsaWtlbHkmcXVvdDs/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkkgYWdyZWUuIEZvciBFQ04mIzQzOyYjNDM7
LCBJIHRoaW5rIHNvbWV0aGluZyBsaWtlIHlvdXIgc3VnZ2VzdGlvbiBvZiAmcXVvdDt1c2VmdWwm
cXVvdDssIG9yIGV2ZW4gUkVDT01NRU5ERUQgaXMgd2hhdCBpcyBuZWVkZWQgaGVyZS4gSSB0aGlu
ayB0aGUgdGVzdGluZyByZWNlaXZlciBjb21wbGlhbmNlIG9uZSBjb3VsZCBiZSByZW1vdmVkIGZy
b20gdGhlIGludHJvLiBJdCdzIG1lbnRpb25lZCB1bmRlciB0ZXN0aW5nIGZvciB1bmV4cGVjdGVk
IGludGVyZmVyZW5jZSBhbmQgdW5kZXINCiBpbnRlZ3JpdHkgY2hlY2tpbmcsIHdoaWNoIGFyZSBz
dWZmaWNpZW50LiA8YnI+DQo8YnI+DQpBbHNvLCB0aGlzIG1ha2VzIG1lIG5vdGljZSB0aGF0IHRo
ZSB3b3JkICZxdW90O2luY2x1ZGVzJnF1b3Q7IGlzIHdyb25nLiBFQ04mIzQzOyYjNDM7IGludGVu
ZHMgdG8gb2Jzb2xldGUgUkZDNTU2MiwgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBtZW50
aW9uIHRoYXQgaGVyZSAoY29zIGl0IG1pZ2h0IGNoYW5nZSBiZWZvcmUgRUNOJiM0MzsmIzQzOyBn
ZXRzIHB1Ymxpc2hlZCkuPGJyPg0KPGJyPg0KQ1VSUkVOVCBURVhUOjxvOnA+PC9vOnA+PC9wPg0K
PHByZT4mbmJzcDsmbmJzcDsgSXQgaXMgbGlrZWx5IChidXQgbm90IHJlcXVpcmVkKSB0aGF0IHRo
ZSBBY2NFQ04gcHJvdG9jb2wgd2lsbCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIHRoZSBmb2xsb3dpbmcgZXhwZXJpbWVudGFsIGFk
ZGl0aW9ucyB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVENQLUVD
TiBwcm90b2NvbDogRUNOLWNhcGFibGUgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQgcmV0cmFuc21p
c3Npb25zPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNy
ZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY24iIHRpdGxlPSImcXVvdDtFQ04mIzQzOyYj
NDM7OiBBZGRpbmcgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gVENQ
IENvbnRyb2wgUGFja2V0cyZxdW90OyI+SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248L2E+
XSwgd2hpY2ggaW5jbHVkZXMgdGhlIEVDTi1jYXBhYmxlIFNZTi88bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsgQUNLIGV4cGVyaW1lbnQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9yZmM1NTYyIiB0aXRsZT0iJnF1b3Q7QWRkaW5nIEV4cGxpY2l0IENvbmdl
c3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIENhcGFiaWxpdHkgdG8gVENQJ3MgU1lOL0FDSyBQYWNr
ZXRzJnF1b3Q7Ij5SRkM1NTYyPC9hPl07IGFuZCB0ZXN0aW5nIHJlY2VpdmVyIG5vbi1jb21wbGlh
bmNlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYt
SS1ELm1vbmNhc3Rlci10Y3BtLXJjdi1jaGVhdCIgdGl0bGU9IiZxdW90O0EgVENQIFRlc3QgdG8g
QWxsb3cgU2VuZGVycyB0byBJZGVudGlmeSBSZWNlaXZlciBOb24tQ29tcGxpYW5jZSZxdW90OyI+
SS1ELm1vbmNhc3Rlci10Y3BtLXJjdi1jaGVhdDwvYT5dLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5QUk9QT1NFRCBURVhUOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJz
cDsmbmJzcDsgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIGlzIGlt
cGxlbWVudGVkIGFsb25nIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7
dGhlIGV4cGVyaW1lbnRhbCBFQ04mIzQzOyYjNDM7IHByb3RvY29sIFs8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYt
SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY24iIHRpdGxlPSImcXVvdDtFQ04mIzQzOyYjNDM7
OiBBZGRpbmcgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gVENQIENv
bnRyb2wgUGFja2V0cyZxdW90OyI+SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248L2E+XS48
bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2VjdGlv
biAyLjEuJm5ic3A7IENhcGFiaWxpdHkgTmVnb3RpYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
VGhlIFRDUCBzZXJ2ZXIgc2VuZHMgdGhlIEFjY0VDTjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBPcHRpb24gb24gdGhlIFNZTi9BQ0sgYW5kIHRoZSBjbGllbnQgc2VuZHMgaXQg
b24gdGhlIGZpcnN0IEFDSyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0
ZXN0IHdoZXRoZXIgdGhlIG5ldHdvcmsgcGF0aCBmb3J3YXJkcyB0aGUgb3B0aW9uIGNvcnJlY3Rs
eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5b
bXNdIEFjY29yZGluZyB0byBTZWN0aW9uIDMuMi42LCBvcHRpb25zIGFyZSBSRUNPTU1FTkRFRC4g
V2hpbGUgU2VjdGlvbiAyIGlzIG5vdCBub3JtYXRpdmUsIHRoZSB3aG9sZSBTZWN0aW9uIDIgZG9l
cyBub3QgcmVhbGx5IGRlc2NyaWJlIHdlbGwgdGhlIGFjdHVhbCByZXF1aXJlbWVudHMgcmVnYXJk
aW5nIG9wdGlvbnMuIFRoaXMgcGFyYWdyYXBoIGluIFNlY3Rpb24gMi4xIGlzIG9uZSBleGFtcGxl
IGZvciB0aGF0LiBJdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGJlIG1vcmUgZXhwbGljaXQgaW4gU2Vj
dGlvbiAyIHRvIHdoaWNoIGV4dGVudCBvcHRpb25zIGhhdmUgdG8gYmUgc3VwcG9ydGVkLjxvOnA+
PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgd2Ug
bmVlZCB0byByZXZpZXcgc2VjdGlvbiAyLCB0byBlbnN1cmUgaXQgaXMgY29uc2lzdGVudCB3aXRo
IGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWFkZSBpbiB0aGUgbm9ybWF0aXZlIHNlY3Rpb24gMyBz
aW5jZSBpdCB3YXMgd3JpdHRlbi48YnI+DQo8YnI+DQpJbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwg
d2UgYWxyZWFkeSBwcm9taXNlZCB0byBjaGVjayAob2ZmbGlzdCB3aXRoIGFuIGltcGxlbWVudGVy
KSB0aGF0IHRoZXJlIHdhcyBubyB0ZXh0IHRoYXQgY29udHJhZGljdGVkIHRoZSBvcHRpb25hbGl0
eSBvZiB0aGUgb3B0aW9uIHN0YXRlZCBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMy4yLjYuPGJyPg0K
PGJyPg0KSSBoYXZlIGFscmVhZHkgc3RhcnRlZCB0aGlzIHdpdGggYSBsaXN0IEkgcHJlcGFyZWQg
KGFsc28gb2ZmbGlzdCkgb2Ygd2hpY2ggbWlkZGxlYm94IGNoZWNraW5nIHNlY3Rpb25zIGFuIGlt
cGxlbWVudGVyIGNvdWxkIGlnbm9yZSBpZiB0aGV5IHdlcmUgb25seSByZWFkaW5nIGJ1dCBub3Qg
c2VuZGluZyB0aGUgVENQIG9wdGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9i
PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2Nv
ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJp
c2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_VI1PR07MB0880170EF06C9CE1C63A464C935C0VI1PR07MB0880eurp_--


From nobody Tue Jul 17 05:42:41 2018
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 EFFBB130F16; Tue, 17 Jul 2018 05:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 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_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 xs8mlxyf6zbK; Tue, 17 Jul 2018 05:42:35 -0700 (PDT)
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 435C6130EC0; Tue, 17 Jul 2018 05:42:34 -0700 (PDT)
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:To:Subject: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=MMqb0KkBuF9cYEssSfA9rlOxmGmOXcUthGUJhi6gtw0=; b=CQ/8gjfSdYzyjtwviGcScR7nv dI4lO8YiprphdxhY0xNts8UzV1imC2MFcL8Gs7lXmEf7+innfx/i18re5PDRTjFFc4YBkpesG88xi SJzdmFWIlM1NpoocpdM2Eqm+1eoFCFQBySEXKJleM0qmWpXvpngTJ5wF0fNJGLl4nPgwNpSYQ4imC OzxcBMvPpcoMBLq317wWbofAYpXZQZ16PI4Le2Ksxw4E+23P9ab5E8jrr29I4gipLDZO2n7QlPj03 RsJF+covaR9u0ekJMpfcl8oO4mib26uIzJDvC850zpEpR+oyr51acFNOnxwAXTjeihVabZVvbo66L g3ArKTkgw==;
Received: from mtrlpq426kw-lp140-01-65-94-232-118.dsl.bell.ca ([65.94.232.118]:56384 helo=[192.168.2.57]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffPJH-0006Z5-G4; Tue, 17 Jul 2018 13:42:31 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net> 
From: Bob Briscoe 
Message-ID: 
Date: Tue, 17 Jul 2018 08:42:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------48756434BBD742CB554E448C"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 12:42:39 -0000

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

Michael,

I've written the proposed edits into a local copy of draft-08, which 
we'll post after this IETF.

Wile writing the last point, I thought it best to add an extra sentence.

    It is RECOMMENDED that the AccECN protocol is implemented along with

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
].
    [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
    experimental scheme [RFC5562] so there is no need to implement RFC
    5562 along with AccECN.



Bob

On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> This would for for me.
>
> Thanks
>
> Michael
>
> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
> *Sent:* Tuesday, July 17, 2018 1:34 AM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
> ; draft-ietf-tcpm-accurate-ecn@ietf.org; 
> tcpm@ietf.org
> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Michael,
>
> On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>     Hi all,
>
>     While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>
>     Section 1. Introduction
>
>         It is likely (but not required) that the AccECN protocol will be
>
>         implemented along with the following experimental additions to the
>
>         TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>         [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
>
>         ACK experiment [RFC5562]; and testing receiver non-compliance
>
>         [I-D.moncaster-tcpm-rcv-cheat].
>
>     [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?
>
>
> I agree. For ECN++, I think something like your suggestion of 
> "useful", or even RECOMMENDED is what is needed here. I think the 
> testing receiver compliance one could be removed from the intro. It's 
> mentioned under testing for unexpected interference and under 
> integrity checking, which are sufficient.
>
> Also, this makes me notice that the word "includes" is wrong. ECN++ 
> intends to obsolete RFC5562, but I don't think we need to mention that 
> here (cos it might change before ECN++ gets published).
>
> CURRENT TEXT:
>
>     It is likely (but not required) that the AccECN protocol will be
>     implemented along with the following experimental additions to the
>     TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>     [I-D.ietf-tcpm-generalized-ecn 
> ], which includes the ECN-capable SYN/
>     ACK experiment [RFC5562 ]; and testing receiver non-compliance
>     [I-D.moncaster-tcpm-rcv-cheat 
> ].
>
> PROPOSED TEXT:
>
>     It is RECOMMENDED that the AccECN protocol is implemented along with
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>
>
>
>     Section 2.1.  Capability Negotiation
>
>         
>
>         The TCP server sends the AccECN
>
>         Option on the SYN/ACK and the client sends it on the first ACK to
>
>         test whether the network path forwards the option correctly.
>
>     [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
>
> OK, we need to review section 2, to ensure it is consistent with 
> changes that have been made in the normative section 3 since it was 
> written.
>
> In this particular case, we already promised to check (offlist with an 
> implementer) that there was no text that contradicted the optionality 
> of the option stated at the end of Section 3.2.6.
>
> I have already started this with a list I prepared (also offlist) of 
> which middlebox checking sections an implementer could ignore if they 
> were only reading but not sending the TCP options.
>
>
>
>
> Bob
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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


--------------48756434BBD742CB554E448C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    I've written the proposed edits into a local copy of draft-08, which
    we'll post after this IETF.

    

    Wile writing the last point, I thought it best to add an extra
    sentence.

    

    
   It is RECOMMENDED that the AccECN protocol is implemented along with

    
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 
   [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
   experimental scheme [RFC5562] so there is no need to implement RFC
   5562 along with AccECN.



    

    

    Bob

    

    
On 17/07/18 01:05, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      
      
      
      

        
This would
            for for me.

        
 

        
Thanks

        
 

        
Michael

        
 

        

          

            

              
From: Bob Briscoe
                  [mailto:ietf@bobbriscoe.net]
                  

                  Sent: Tuesday, July 17, 2018 1:34 AM

                  To: Scharf, Michael (Nokia - DE/Stuttgart)
                  <michael.scharf@nokia.com>;
                  draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                  Subject: Re: [tcpm] Further comments on
                  draft-ietf-tcpm-accurate-ecn

            

          

          
 

          
Michael,

          

            
On 15/07/18 16:54, Scharf, Michael
              (Nokia - DE/Stuttgart) wrote:

          

          

            
Hi all,

            
 

            
While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:

            
 

            
 

            
Section 1. Introduction

            
 

            
   It is likely (but not required) that the AccECN protocol will be

            
   implemented along with the following experimental additions to the

            
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

            
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

            
   ACK experiment [RFC5562]; and testing receiver non-compliance

            
   [I-D.moncaster-tcpm-rcv-cheat].

            
 

            
[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

          

          


            I agree. For ECN++, I think something like your suggestion
            of "useful", or even RECOMMENDED is what is needed here. I
            think the testing receiver compliance one could be removed
            from the intro. It's mentioned under testing for unexpected
            interference and under integrity checking, which are
            sufficient. 

            

            Also, this makes me notice that the word "includes" is
            wrong. ECN++ intends to obsolete RFC5562, but I don't think
            we need to mention that here (cos it might change before
            ECN++ gets published).

            

            CURRENT TEXT:

          
   It is likely (but not required) that the AccECN protocol will be

          
   implemented along with the following experimental additions to the

          
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

          
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

          
   ACK experiment [RFC5562]; and testing receiver non-compliance

          
   [I-D.moncaster-tcpm-rcv-cheat].

          
PROPOSED TEXT:

          
   It is RECOMMENDED that the AccECN protocol is implemented along with

          
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

          


            

            

          

            
 

            
 

            
 

            
Section 2.1.  Capability Negotiation

            
   

            
   The TCP server sends the AccECN

            
   Option on the SYN/ACK and the client sends it on the first ACK to

            
   test whether the network path forwards the option correctly.

            
 

            
[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.

          

          
OK, we need to review section 2, to
            ensure it is consistent with changes that have been made in
            the normative section 3 since it was written.

            

            In this particular case, we already promised to check
            (offlist with an implementer) that there was no text that
            contradicted the optionality of the option stated at the end
            of Section 3.2.6.

            

            I have already started this with a list I prepared (also
            offlist) of which middlebox checking sections an implementer
            could ignore if they were only reading but not sending the
            TCP options.

            

            

            

            

            Bob

            

            

            

            

          
-- 

          
________________________________________________________________

          
Bob Briscoe                               http://bobbriscoe.net/

        

      

    

    

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

  


--------------48756434BBD742CB554E448C--


From nobody Tue Jul 17 05:57:10 2018
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 B9B78130EAC; Tue, 17 Jul 2018 05:57:08 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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=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 I4T9tsmDgBx0; Tue, 17 Jul 2018 05:57:05 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40134.outbound.protection.outlook.com [40.107.4.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD3D130DF5; Tue, 17 Jul 2018 05:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MFDKv4d33I5tW+mmUsY5tvn/Rh1F64mBRDbIWwb2cTo=; b=rliHNyDJupDfTTnrqDqv1Mucztsw3DxAs8exflC06IBQHhWXwiQq7K55P9ww5mzT0WdqOndNRAqCVlA3IjVPiAJqm7Bf22ONqNEDbJZTSDhIsBh0zEGQZU+9AGEDY3hfP9GDpbIq9FwJAcZdPXeDIZn0FQmFPDunRDFweL3ufIA=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB4365.eurprd07.prod.outlook.com (20.176.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Tue, 17 Jul 2018 12:57:02 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.013; Tue, 17 Jul 2018 12:57:01 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgA5JfwAAAuIsyAAEAC+AAAADp/g
Date: Tue, 17 Jul 2018 12:57:01 +0000
Message-ID: 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>  
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-originating-ip: [135.245.212.158]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4365; 6:URoeyaF2gqVXrM9PKBf7ac/sf/6ZNR8xCumWaknalMsbwZ1N/5DJUSJLGL8mx0qsa2SFnIGxyOAgehZzoqTCBOvMbmBI+lzHfo1qEr8+z5FeCc4WO/nsppCBnvWJ5bIA76+N0IoOXWFkTUA61GKaT9gK+a7a2weUpY1xrO+9B47c7th0bLszrfsp5n1pUW0I4/GITC8D7W11WmU+9mxj1RQVlcd/s5qUE5zO6fxYdR0oQOL8Zy4ye8NzD5IzuAAVDQ7l72X7nUsPdPdzzQm6yOyXoBj71752pXV2djYTPQm5yS9vA4+wTRmpPtBpghdY7hKoN8hfxOodVigXv1oJrH8+CG4V8UfEy7pqPWDI4Sg/PYFgEVNch+Om8LBx2igp/oB0H7gDNnCbkO536fP1vmvZ7aU2JWn4Tm5GncjPmGc/Eo3mHOGsTbRtq1PsEJmCje+V74njAie7ltR4GhDXEQ==; 5:KuHCeeg14GXivYxAxh5En3BN1+YGEu/nwEHw12fwSJ8ohEAcvo7rMwbKhPA14au1xini9CcqBsA8utaMNzBVb/9sXD5Xld/3AIU4+eV46fdYiEOvV6OkZxHV7qFrjcc1e/doD0pD1m7Ekwnr3orPNdHe1BmvWg7EZ48ZBBrxSUo=; 7:FXa3B4qKwJLTlxwNP4v0Bf8AJTZHsTawvi+36gwQFMh9m55Ufwn8XRlE0WNsH8bUoyYa9+IwC8mrt3H+Bzudjp8JvQKpP3rkbo+1B6D44NAITcN/w1xTuZHFfX37F71udYPC6O0No8DS3O2BaZAIge0SN2amfp31BQmM/Cb2VBDoHpLGThI3E6yfmBw1PU76SSgFzq1D2CtT0cSiOEJj7gc+G1rw+5VEVcK6CtVR034ZVuhyd9mL7lJl6d1+9c4+
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 35489741-46f1-4f88-74eb-08d5ebe4ca2e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR07MB4365; 
x-ms-traffictypediagnostic: VI1PR07MB4365:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(82608151540597)(109105607167333)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB4365; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4365; 
x-forefront-prvs: 073631BD3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(366004)(39860400002)(376002)(136003)(396003)(199004)(189003)(53754006)(99286004)(53546011)(81156014)(8676002)(606006)(76176011)(106356001)(55016002)(2906002)(26005)(105586002)(229853002)(446003)(110136005)(186003)(6506007)(11346002)(102836004)(6246003)(33656002)(97736004)(53376002)(66066001)(74316002)(6436002)(53936002)(7736002)(81166006)(8936002)(54896002)(7696005)(9686003)(5660300001)(68736007)(93886005)(25786009)(3846002)(236005)(2201001)(478600001)(316002)(790700001)(6116002)(14444005)(2501003)(14454004)(256004)(86362001)(5250100002)(2900100001)(476003)(486006)(966005)(6306002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4365; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: mq9hKB82NfZiF2U6QaXBN03w/466hhO4gwt77SNYEzQmEWvAMJ86okY1ECVyDdgHTeqPu3jOzZweualJ8sYlTyR9GXKoWm6bMhFXaWe52H3MRc8cKXABJWivxx20jc1gHVSOTmTMXY687Rvvd70waJrufA/b4llkm4M8RSw6ka7NxVZb6M7N+mCRb9HvufMdfrCBHenYqC1siJbX/g82OSc2zCIvmKD2MHePSiJ6uzVTnhXPtx6oPWy+x20WL8DYZ+dp7Jn0YitWx644o+pkEtCTg8aXT/t+iycN/WdupaIifY4T6l2cidWzORubkrQSGFwag1BDMSRPUlgcbarfI78YaiVZ2Fq8F7rakVtZqOmPhBH2hYqNd5TBYJE+fDzketrSfD6xxiQ/z7pis8inMg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB088038B7B4E017DCCF4F2718935C0VI1PR07MB0880eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35489741-46f1-4f88-74eb-08d5ebe4ca2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 12:57:01.8255 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4365
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 12:57:09 -0000

--_000_VI1PR07MB088038B7B4E017DCCF4F2718935C0VI1PR07MB0880eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3b3VsZCBwcmVmZXIgdGhlIGZpcnN0LCBzaG9ydGVyIHdvcmRpbmcuDQoNCkZvciBpbnN0YW5j
ZSwgaXQgd291bGQgYmUgcG9zc2libGUgdGhhdCBUQ1BNIGRlY2lkZXMgdG8gb2Jzb2xldGUgUkZD
IDU1NjIuIEnigJlkIHN1Z2dlc3QgdG8ga2VlcCB0aGUgc3RhdHVzIGFuZCBmdXR1cmUgdXNlIG9m
IFJGQyA1NTYyIGluIGNvbWJpbmF0aW9uIHdpdGggRUNOKysgb3V0c2lkZSBvZiB0aGlzIGRvY3Vt
ZW50Lg0KDQpXaGF0IG1pZ2h0IGJlIGluIHNjb3BlIG9mIHRoZSBBY2NFQ04gc3BlYyB3b3VsZCBi
ZSBhIGh5cG90aGV0aWNhbCB1c2Ugb2YgQWNjRUNOIGluIGNvbWJpbmF0aW9uIHdpdGggUkZDIDU1
NjIuIEJ1dCBJIHdvdWxkIGJlIGZpbmUgd2l0aCBqdXN0IG9taXR0aW5nIHRoYXQuIEFsdGVybmF0
aXZlbHksIGEgbW9yZSBzdGF0ZW1lbnQgbm90IHJlbGF0ZWQgdG8gdGhlIHN0YXR1cyB3b3VsZCBi
ZSDigJxhIGNvbWJpbmF0aW9uIG9mIEFjY0VDTiB3aXRoIFJGQyA1NTYyIGlzIG91dHNpZGUgdGhl
IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnTigJ0uDQoNCkFjdHVhbGx5LCBJIGFtIGFsc28gbm90IHN1
cmUgaWYgdGhpcyBwYXJhZ3JhcGggaXMgYSBnb29kIGV4YW1wbGUgZm9yIFJFQ09NTUVOREVEIGlu
IGEgY2FwaXRhbCBsZXR0ZXJzLiBUbyBtZSwgdGhlIGZvbGxvd2luZyB3b3VsZCBiZSBzdWZmaWNp
ZW50Og0KDQoNCiAgIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCBp
cyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoDQoNCiAgIHRoZSBleHBlcmltZW50YWwgRUNOKysgcHJv
dG9jb2wgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3Bt
LWdlbmVyYWxpemVkLWVjbj5dLg0KDQpNaWNoYWVsDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWls
dG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTggMjo0
MyBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxtaWNoYWVs
LnNjaGFyZkBub2tpYS5jb20+OyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3Jn
OyB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIEZ1cnRoZXIgY29tbWVudHMgb24g
ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbg0KDQpNaWNoYWVsLA0KDQpJJ3ZlIHdyaXR0ZW4g
dGhlIHByb3Bvc2VkIGVkaXRzIGludG8gYSBsb2NhbCBjb3B5IG9mIGRyYWZ0LTA4LCB3aGljaCB3
ZSdsbCBwb3N0IGFmdGVyIHRoaXMgSUVURi4NCg0KV2lsZSB3cml0aW5nIHRoZSBsYXN0IHBvaW50
LCBJIHRob3VnaHQgaXQgYmVzdCB0byBhZGQgYW4gZXh0cmEgc2VudGVuY2UuDQoNCiAgIEl0IGlz
IFJFQ09NTUVOREVEIHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9u
ZyB3aXRoDQoNCiAgIHRoZSBleHBlcmltZW50YWwgRUNOKysgcHJvdG9jb2wgW0ktRC5pZXRmLXRj
cG0tZ2VuZXJhbGl6ZWQtZWNuPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbj5d
Lg0KDQogICBbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY25dIGlzIGEgcHJvcG9zZWQgYWx0
ZXJuYXRpdmUgdG8gYW5vdGhlcg0KDQogICBleHBlcmltZW50YWwgc2NoZW1lIFtSRkM1NTYyXSBz
byB0aGVyZSBpcyBubyBuZWVkIHRvIGltcGxlbWVudCBSRkMNCg0KICAgNTU2MiBhbG9uZyB3aXRo
IEFjY0VDTi4NCg0KDQoNCg0KQm9iDQpPbiAxNy8wNy8xOCAwMTowNSwgU2NoYXJmLCBNaWNoYWVs
IChOb2tpYSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6DQpUaGlzIHdvdWxkIGZvciBmb3IgbWUuDQoN
ClRoYW5rcw0KDQpNaWNoYWVsDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2Ji
cmlzY29lLm5ldF0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTggMTozNCBBTQ0KVG86IFNj
aGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxtaWNoYWVsLnNjaGFyZkBub2tp
YS5jb20+PG1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+OyBkcmFmdC1pZXRmLXRjcG0t
YWNjdXJhdGUtZWNuQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNu
QGlldGYub3JnPjsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6
IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt
ZWNuDQoNCk1pY2hhZWwsDQpPbiAxNS8wNy8xOCAxNjo1NCwgU2NoYXJmLCBNaWNoYWVsIChOb2tp
YSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6DQoNCkhpIGFsbCwNCg0KDQoNCldoaWxlIHJlYWRpbmcg
ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNywgSSBub3RpY2VkIHRoZSBmb2xsb3dpbmc6
DQoNCg0KDQoNCg0KU2VjdGlvbiAxLiBJbnRyb2R1Y3Rpb24NCg0KDQoNCiAgIEl0IGlzIGxpa2Vs
eSAoYnV0IG5vdCByZXF1aXJlZCkgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIHdpbGwgYmUNCg0K
ICAgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aCB0aGUgZm9sbG93aW5nIGV4cGVyaW1lbnRhbCBhZGRp
dGlvbnMgdG8gdGhlDQoNCiAgIFRDUC1FQ04gcHJvdG9jb2w6IEVDTi1jYXBhYmxlIFRDUCBjb250
cm9sIHBhY2tldHMgYW5kIHJldHJhbnNtaXNzaW9ucw0KDQogICBbSS1ELmlldGYtdGNwbS1nZW5l
cmFsaXplZC1lY25dLCB3aGljaCBpbmNsdWRlcyB0aGUgRUNOLWNhcGFibGUgU1lOLw0KDQogICBB
Q0sgZXhwZXJpbWVudCBbUkZDNTU2Ml07IGFuZCB0ZXN0aW5nIHJlY2VpdmVyIG5vbi1jb21wbGlh
bmNlDQoNCiAgIFtJLUQubW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0XS4NCg0KDQoNClttc10gSSBo
YXZlIGNvbW1lbnRlZCBvbiB0aGlzIHNlY3Rpb24gYmVmb3JlLiBBbmQgSSBzdGlsbCBkaXNsaWtl
IHRoZSB0ZXJtICJsaWtlbHkiLiBUbyBtZSwgImxpa2VseSIgaXMgc3BlY3VsYXRpb24uIEEgbmV1
dHJhbCBwaHJhc2luZyB3b3VsZCBiZSAiLi4uIGl0IGlzIHBvc3NpYmxlLi4uIiBvciAiLi4uIGl0
IGlzIHVzZWZ1bC4uLiIuIEhhdmluZyBzYWlkIHRoaXMsIEkgb2JzZXJ2ZSB0aGF0IGRyYWZ0LW1v
bmNhc3Rlci10Y3BtLXJjdi1jaGVhdC0wMyB3YXMgbGFzdCB1cGRhdGVkIGluIDIwMTQuIEhvdyAi
bGlrZWx5IiBpcyBpdCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgd2lsbCBiZSBpbXBsZW1lbnRl
ZCBhbG9uZyB3aXRoIGEgbWVjaGFuaXNtIGRvY3VtZW50ZWQgaW4gYW4gSUQgdGhhdCBoYXMgYmVl
biB3cml0dGVuIG1vcmUgdGhhbiAxMCB5ZWFycyBhZ28gYW5kIG5vdCBiZWVuIHVwZGF0ZWQgZm9y
IGFib3V0IDQgeWVhcnM/IEFyZSBpbXBsZW1lbnRlcnMgaW5kZWVkIHNvIGludGVyZXN0ZWQgaW4g
ZHJhZnQtbW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0IHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaXMg
Imxpa2VseSI/DQoNCkkgYWdyZWUuIEZvciBFQ04rKywgSSB0aGluayBzb21ldGhpbmcgbGlrZSB5
b3VyIHN1Z2dlc3Rpb24gb2YgInVzZWZ1bCIsIG9yIGV2ZW4gUkVDT01NRU5ERUQgaXMgd2hhdCBp
cyBuZWVkZWQgaGVyZS4gSSB0aGluayB0aGUgdGVzdGluZyByZWNlaXZlciBjb21wbGlhbmNlIG9u
ZSBjb3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIGludHJvLiBJdCdzIG1lbnRpb25lZCB1bmRlciB0
ZXN0aW5nIGZvciB1bmV4cGVjdGVkIGludGVyZmVyZW5jZSBhbmQgdW5kZXIgaW50ZWdyaXR5IGNo
ZWNraW5nLCB3aGljaCBhcmUgc3VmZmljaWVudC4NCg0KQWxzbywgdGhpcyBtYWtlcyBtZSBub3Rp
Y2UgdGhhdCB0aGUgd29yZCAiaW5jbHVkZXMiIGlzIHdyb25nLiBFQ04rKyBpbnRlbmRzIHRvIG9i
c29sZXRlIFJGQzU1NjIsIGJ1dCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gbWVudGlvbiB0aGF0
IGhlcmUgKGNvcyBpdCBtaWdodCBjaGFuZ2UgYmVmb3JlIEVDTisrIGdldHMgcHVibGlzaGVkKS4N
Cg0KQ1VSUkVOVCBURVhUOg0KDQogICBJdCBpcyBsaWtlbHkgKGJ1dCBub3QgcmVxdWlyZWQpIHRo
YXQgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlDQoNCiAgIGltcGxlbWVudGVkIGFsb25nIHdp
dGggdGhlIGZvbGxvd2luZyBleHBlcmltZW50YWwgYWRkaXRpb25zIHRvIHRoZQ0KDQogICBUQ1At
RUNOIHByb3RvY29sOiBFQ04tY2FwYWJsZSBUQ1AgY29udHJvbCBwYWNrZXRzIGFuZCByZXRyYW5z
bWlzc2lvbnMNCg0KICAgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQu
aWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbj5dLCB3aGljaCBpbmNsdWRlcyB0aGUgRUNOLWNhcGFi
bGUgU1lOLw0KDQogICBBQ0sgZXhwZXJpbWVudCBbUkZDNTU2MjxodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvcmZjNTU2Mj5dOyBhbmQgdGVzdGluZyByZWNlaXZlciBub24tY29tcGxpYW5jZQ0K
DQogICBbSS1ELm1vbmNhc3Rlci10Y3BtLXJjdi1jaGVhdDxodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELm1vbmNhc3Rlci10
Y3BtLXJjdi1jaGVhdD5dLg0KUFJPUE9TRUQgVEVYVDoNCg0KICAgSXQgaXMgUkVDT01NRU5ERUQg
dGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIGlzIGltcGxlbWVudGVkIGFsb25nIHdpdGgNCg0KICAg
dGhlIGV4cGVyaW1lbnRhbCBFQ04rKyBwcm90b2NvbCBbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXpl
ZC1lY248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0
ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPl0uDQoNCg0KDQoNCg0K
DQoNCg0KDQoNClNlY3Rpb24gMi4xLiAgQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbg0KDQoNCg0KICAg
VGhlIFRDUCBzZXJ2ZXIgc2VuZHMgdGhlIEFjY0VDTg0KDQogICBPcHRpb24gb24gdGhlIFNZTi9B
Q0sgYW5kIHRoZSBjbGllbnQgc2VuZHMgaXQgb24gdGhlIGZpcnN0IEFDSyB0bw0KDQogICB0ZXN0
IHdoZXRoZXIgdGhlIG5ldHdvcmsgcGF0aCBmb3J3YXJkcyB0aGUgb3B0aW9uIGNvcnJlY3RseS4N
Cg0KDQoNClttc10gQWNjb3JkaW5nIHRvIFNlY3Rpb24gMy4yLjYsIG9wdGlvbnMgYXJlIFJFQ09N
TUVOREVELiBXaGlsZSBTZWN0aW9uIDIgaXMgbm90IG5vcm1hdGl2ZSwgdGhlIHdob2xlIFNlY3Rp
b24gMiBkb2VzIG5vdCByZWFsbHkgZGVzY3JpYmUgd2VsbCB0aGUgYWN0dWFsIHJlcXVpcmVtZW50
cyByZWdhcmRpbmcgb3B0aW9ucy4gVGhpcyBwYXJhZ3JhcGggaW4gU2VjdGlvbiAyLjEgaXMgb25l
IGV4YW1wbGUgZm9yIHRoYXQuIEl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYmUgbW9yZSBleHBsaWNp
dCBpbiBTZWN0aW9uIDIgdG8gd2hpY2ggZXh0ZW50IG9wdGlvbnMgaGF2ZSB0byBiZSBzdXBwb3J0
ZWQuDQpPSywgd2UgbmVlZCB0byByZXZpZXcgc2VjdGlvbiAyLCB0byBlbnN1cmUgaXQgaXMgY29u
c2lzdGVudCB3aXRoIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWFkZSBpbiB0aGUgbm9ybWF0aXZl
IHNlY3Rpb24gMyBzaW5jZSBpdCB3YXMgd3JpdHRlbi4NCg0KSW4gdGhpcyBwYXJ0aWN1bGFyIGNh
c2UsIHdlIGFscmVhZHkgcHJvbWlzZWQgdG8gY2hlY2sgKG9mZmxpc3Qgd2l0aCBhbiBpbXBsZW1l
bnRlcikgdGhhdCB0aGVyZSB3YXMgbm8gdGV4dCB0aGF0IGNvbnRyYWRpY3RlZCB0aGUgb3B0aW9u
YWxpdHkgb2YgdGhlIG9wdGlvbiBzdGF0ZWQgYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDMuMi42Lg0K
DQpJIGhhdmUgYWxyZWFkeSBzdGFydGVkIHRoaXMgd2l0aCBhIGxpc3QgSSBwcmVwYXJlZCAoYWxz
byBvZmZsaXN0KSBvZiB3aGljaCBtaWRkbGVib3ggY2hlY2tpbmcgc2VjdGlvbnMgYW4gaW1wbGVt
ZW50ZXIgY291bGQgaWdub3JlIGlmIHRoZXkgd2VyZSBvbmx5IHJlYWRpbmcgYnV0IG5vdCBzZW5k
aW5nIHRoZSBUQ1Agb3B0aW9ucy4NCg0KDQoNCg0KQm9iDQoNCg0KDQoNCg0KLS0NCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9i
YnJpc2NvZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg==

--_000_VI1PR07MB088038B7B4E017DCCF4F2718935C0VI1PR07MB0880eurp_
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
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s
b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx
Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg
Ymdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+SSB3b3VsZCBwcmVmZXIgdGhlIGZpcnN0LCBzaG9ydGVy
IHdvcmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gb3Ig
aW5zdGFuY2UsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRoYXQgVENQTSBkZWNpZGVzIHRvIG9ic29s
ZXRlIFJGQyA1NTYyLiBJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l
cyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+4oCZPC9zcGFuPjxzcGFu
IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5kIHN1Z2dlc3QgdG8ga2VlcA0KIHRoZSBzdGF0dXMg
YW5kIGZ1dHVyZSB1c2Ugb2YgUkZDIDU1NjIgaW4gY29tYmluYXRpb24gd2l0aCBFQ04mIzQzOyYj
NDM7IG91dHNpZGUgb2YgdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQiPldoYXQgbWlnaHQgYmUgaW4gc2NvcGUgb2YgdGhlIEFjY0VDTiBzcGVj
IHdvdWxkIGJlIGEgaHlwb3RoZXRpY2FsIHVzZSBvZiBBY2NFQ04gaW4gY29tYmluYXRpb24gd2l0
aCBSRkMgNTU2Mi4gQnV0IEkgd291bGQgYmUgZmluZSB3aXRoIGp1c3Qgb21pdHRpbmcgdGhhdC4g
QWx0ZXJuYXRpdmVseSwgYSBtb3JlIHN0YXRlbWVudCBub3QgcmVsYXRlZCB0byB0aGUNCiBzdGF0
dXMgd291bGQgYmUgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+4oCcPC9zcGFuPjxzcGFuIHN0
eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5hIGNvbWJpbmF0aW9uIG9mIEFjY0VDTiB3aXRoIFJGQyA1
NTYyIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQ8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjp3
aW5kb3d0ZXh0Ij7igJ08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPi48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkFjdHVhbGx5LCBJIGFtIGFs
c28gbm90IHN1cmUgaWYgdGhpcyBwYXJhZ3JhcGggaXMgYSBnb29kIGV4YW1wbGUgZm9yIFJFQ09N
TUVOREVEIGluIGEgY2FwaXRhbCBsZXR0ZXJzLiBUbyBtZSwgdGhlIGZvbGxvd2luZyB3b3VsZCBi
ZSBzdWZmaWNpZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04g
cHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyAmbmJzcDt0aGUgZXhwZXJpbWVudGFsIEVDTiYjNDM7JiM0MzsgcHJvdG9jb2wgWzxh
IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJh
dGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbiIgdGl0bGU9IiZxdW90
O0VDTiYjNDM7JiM0Mzs6IEFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAo
RUNOKSB0byBUQ1AgQ29udHJvbCBQYWNrZXRzJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWdlbmVyYWxp
emVkLWVjbjwvYT5dLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPk1pY2hh
ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs
dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNl
bnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDI6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IFNj
aGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpICZsdDttaWNoYWVsLnNjaGFyZkBu
b2tpYS5jb20mZ3Q7OyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnOyB0Y3Bt
QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50
cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNo
YWVsLDxicj4NCjxicj4NCkkndmUgd3JpdHRlbiB0aGUgcHJvcG9zZWQgZWRpdHMgaW50byBhIGxv
Y2FsIGNvcHkgb2YgZHJhZnQtMDgsIHdoaWNoIHdlJ2xsIHBvc3QgYWZ0ZXIgdGhpcyBJRVRGLjxi
cj4NCjxicj4NCldpbGUgd3JpdGluZyB0aGUgbGFzdCBwb2ludCwgSSB0aG91Z2h0IGl0IGJlc3Qg
dG8gYWRkIGFuIGV4dHJhIHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJz
cDsgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIGlzIGltcGxlbWVu
dGVkIGFsb25nIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7dGhlIGV4
cGVyaW1lbnRhbCBFQ04mIzQzOyYjNDM7IHByb3RvY29sIFs8YSBocmVmPSJodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmll
dGYtdGNwbS1nZW5lcmFsaXplZC1lY24iIHRpdGxlPSImcXVvdDtFQ04mIzQzOyYjNDM7OiBBZGRp
bmcgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gVENQIENvbnRyb2wg
UGFja2V0cyZxdW90OyI+SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248L2E+XS4gPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7W0ktRC5pZXRmLXRjcG0tZ2VuZXJh
bGl6ZWQtZWNuXSBpcyBhIHByb3Bvc2VkIGFsdGVybmF0aXZlIHRvIGFub3RoZXI8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZXhwZXJpbWVudGFsIHNjaGVtZSBbUkZDNTU2Ml0g
c28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbXBsZW1lbnQgUkZDPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IDU1NjIgYWxvbmcgd2l0aCBBY2NFQ04uPG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcvMDcvMTggMDE6MDUsIFNjaGFyZiwgTWlj
aGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5U
aGlzIHdvdWxkIGZvciBmb3IgbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0Ij5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi
Pk1pY2hhZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2lu
ZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5l
dCI+bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1
ZXNkYXksIEp1bHkgMTcsIDIwMTggMTozNCBBTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNo
YWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2NoYXJm
QG5va2lhLmNvbSI+DQombHQ7bWljaGFlbC5zY2hhcmZAbm9raWEuY29tJmd0OzwvYT47IDxhIGhy
ZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnIj4NCmRyYWZ0
LWlldGYtdGNwbS1hY2N1cmF0ZS1lY25AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86dGNw
bUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0
Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY248L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gMTUvMDcvMTggMTY6NTQsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE
RS9TdHV0dGdhcnQpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGkgYWxs
LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldo
aWxlIHJlYWRpbmcgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNywgSSBub3RpY2VkIHRo
ZSBmb2xsb3dpbmc6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+U2VjdGlvbiAxLiBJbnRyb2R1
Y3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgSXQgaXMgbGlrZWx5IChidXQgbm90IHJlcXVpcmVkKSB0aGF0IHRoZSBB
Y2NFQ04gcHJvdG9jb2wgd2lsbCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIHRoZSBmb2xsb3dpbmcgZXhwZXJpbWVudGFsIGFkZGl0
aW9ucyB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVENQLUVDTiBw
cm90b2NvbDogRUNOLWNhcGFibGUgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQgcmV0cmFuc21pc3Np
b25zPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0Zi10Y3BtLWdl
bmVyYWxpemVkLWVjbl0sIHdoaWNoIGluY2x1ZGVzIHRoZSBFQ04tY2FwYWJsZSBTWU4vPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFDSyBleHBlcmltZW50IFtSRkM1NTYyXTsg
YW5kIHRlc3RpbmcgcmVjZWl2ZXIgbm9uLWNvbXBsaWFuY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgW0ktRC5tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXRdLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlttc10gSSBoYXZlIGNv
bW1lbnRlZCBvbiB0aGlzIHNlY3Rpb24gYmVmb3JlLiBBbmQgSSBzdGlsbCBkaXNsaWtlIHRoZSB0
ZXJtICZxdW90O2xpa2VseSZxdW90Oy4gVG8gbWUsICZxdW90O2xpa2VseSZxdW90OyBpcyBzcGVj
dWxhdGlvbi4gQSBuZXV0cmFsIHBocmFzaW5nIHdvdWxkIGJlICZxdW90Oy4uLiBpdCBpcyBwb3Nz
aWJsZS4uLiZxdW90OyBvciAmcXVvdDsuLi4gaXQgaXMgdXNlZnVsLi4uJnF1b3Q7LiBIYXZpbmcg
c2FpZCB0aGlzLCBJIG9ic2VydmUgdGhhdCBkcmFmdC1tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQt
MDMgd2FzIGxhc3QgdXBkYXRlZCBpbiAyMDE0LiBIb3cgJnF1b3Q7bGlrZWx5JnF1b3Q7IGlzIGl0
IHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlIGltcGxlbWVudGVkIGFsb25nIHdpdGgg
YSBtZWNoYW5pc20gZG9jdW1lbnRlZCBpbiBhbiBJRCB0aGF0IGhhcyBiZWVuIHdyaXR0ZW4gbW9y
ZSB0aGFuIDEwIHllYXJzIGFnbyBhbmQgbm90IGJlZW4gdXBkYXRlZCBmb3IgYWJvdXQgNCB5ZWFy
cz8gQXJlIGltcGxlbWVudGVycyBpbmRlZWQgc28gaW50ZXJlc3RlZCBpbiBkcmFmdC1tb25jYXN0
ZXItdGNwbS1yY3YtY2hlYXQgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBpcyAmcXVvdDtsaWtlbHkm
cXVvdDs/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCkkgYWdyZWUuIEZvciBFQ04mIzQzOyYjNDM7LCBJIHRoaW5rIHNvbWV0aGluZyBs
aWtlIHlvdXIgc3VnZ2VzdGlvbiBvZiAmcXVvdDt1c2VmdWwmcXVvdDssIG9yIGV2ZW4gUkVDT01N
RU5ERUQgaXMgd2hhdCBpcyBuZWVkZWQgaGVyZS4gSSB0aGluayB0aGUgdGVzdGluZyByZWNlaXZl
ciBjb21wbGlhbmNlIG9uZSBjb3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIGludHJvLiBJdCdzIG1l
bnRpb25lZCB1bmRlciB0ZXN0aW5nIGZvciB1bmV4cGVjdGVkIGludGVyZmVyZW5jZSBhbmQgdW5k
ZXINCiBpbnRlZ3JpdHkgY2hlY2tpbmcsIHdoaWNoIGFyZSBzdWZmaWNpZW50LiA8YnI+DQo8YnI+
DQpBbHNvLCB0aGlzIG1ha2VzIG1lIG5vdGljZSB0aGF0IHRoZSB3b3JkICZxdW90O2luY2x1ZGVz
JnF1b3Q7IGlzIHdyb25nLiBFQ04mIzQzOyYjNDM7IGludGVuZHMgdG8gb2Jzb2xldGUgUkZDNTU2
MiwgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBtZW50aW9uIHRoYXQgaGVyZSAoY29zIGl0
IG1pZ2h0IGNoYW5nZSBiZWZvcmUgRUNOJiM0MzsmIzQzOyBnZXRzIHB1Ymxpc2hlZCkuPGJyPg0K
PGJyPg0KQ1VSUkVOVCBURVhUOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSXQg
aXMgbGlrZWx5IChidXQgbm90IHJlcXVpcmVkKSB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgd2ls
bCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRlZCBhbG9u
ZyB3aXRoIHRoZSBmb2xsb3dpbmcgZXhwZXJpbWVudGFsIGFkZGl0aW9ucyB0byB0aGU8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVENQLUVDTiBwcm90b2NvbDogRUNOLWNhcGFi
bGUgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQgcmV0cmFuc21pc3Npb25zPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNwbS1nZW5l
cmFsaXplZC1lY24iIHRpdGxlPSImcXVvdDtFQ04mIzQzOyYjNDM7OiBBZGRpbmcgRXhwbGljaXQg
Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gVENQIENvbnRyb2wgUGFja2V0cyZxdW90
OyI+SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248L2E+XSwgd2hpY2ggaW5jbHVkZXMgdGhl
IEVDTi1jYXBhYmxlIFNZTi88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQUNL
IGV4cGVyaW1lbnQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTYy
IiB0aXRsZT0iJnF1b3Q7QWRkaW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChF
Q04pIENhcGFiaWxpdHkgdG8gVENQJ3MgU1lOL0FDSyBQYWNrZXRzJnF1b3Q7Ij5SRkM1NTYyPC9h
Pl07IGFuZCB0ZXN0aW5nIHJlY2VpdmVyIG5vbi1jb21wbGlhbmNlPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELm1vbmNhc3Rlci10Y3BtLXJj
di1jaGVhdCIgdGl0bGU9IiZxdW90O0EgVENQIFRlc3QgdG8gQWxsb3cgU2VuZGVycyB0byBJZGVu
dGlmeSBSZWNlaXZlciBOb24tQ29tcGxpYW5jZSZxdW90OyI+SS1ELm1vbmNhc3Rlci10Y3BtLXJj
di1jaGVhdDwvYT5dLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QUk9Q
T1NFRCBURVhUOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSXQgaXMgUkVDT01N
RU5ERUQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIGlzIGltcGxlbWVudGVkIGFsb25nIHdpdGg8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7dGhlIGV4cGVyaW1lbnRhbCBFQ04m
IzQzOyYjNDM7IHByb3RvY29sIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFs
aXplZC1lY24iIHRpdGxlPSImcXVvdDtFQ04mIzQzOyYjNDM7OiBBZGRpbmcgRXhwbGljaXQgQ29u
Z2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gVENQIENvbnRyb2wgUGFja2V0cyZxdW90OyI+
SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248L2E+XS48bzpwPjwvbzpwPjwvcHJlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+U2VjdGlvbiAyLjEuJm5ic3A7IENh
cGFiaWxpdHkgTmVnb3RpYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIFRDUCBzZXJ2ZXIg
c2VuZHMgdGhlIEFjY0VDTjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBPcHRp
b24gb24gdGhlIFNZTi9BQ0sgYW5kIHRoZSBjbGllbnQgc2VuZHMgaXQgb24gdGhlIGZpcnN0IEFD
SyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0ZXN0IHdoZXRoZXIgdGhl
IG5ldHdvcmsgcGF0aCBmb3J3YXJkcyB0aGUgb3B0aW9uIGNvcnJlY3RseS48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5bbXNdIEFjY29yZGluZyB0
byBTZWN0aW9uIDMuMi42LCBvcHRpb25zIGFyZSBSRUNPTU1FTkRFRC4gV2hpbGUgU2VjdGlvbiAy
IGlzIG5vdCBub3JtYXRpdmUsIHRoZSB3aG9sZSBTZWN0aW9uIDIgZG9lcyBub3QgcmVhbGx5IGRl
c2NyaWJlIHdlbGwgdGhlIGFjdHVhbCByZXF1aXJlbWVudHMgcmVnYXJkaW5nIG9wdGlvbnMuIFRo
aXMgcGFyYWdyYXBoIGluIFNlY3Rpb24gMi4xIGlzIG9uZSBleGFtcGxlIGZvciB0aGF0LiBJdCB3
b3VsZCBtYWtlIHNlbnNlIHRvIGJlIG1vcmUgZXhwbGljaXQgaW4gU2VjdGlvbiAyIHRvIHdoaWNo
IGV4dGVudCBvcHRpb25zIGhhdmUgdG8gYmUgc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgd2UgbmVlZCB0byByZXZpZXcg
c2VjdGlvbiAyLCB0byBlbnN1cmUgaXQgaXMgY29uc2lzdGVudCB3aXRoIGNoYW5nZXMgdGhhdCBo
YXZlIGJlZW4gbWFkZSBpbiB0aGUgbm9ybWF0aXZlIHNlY3Rpb24gMyBzaW5jZSBpdCB3YXMgd3Jp
dHRlbi48YnI+DQo8YnI+DQpJbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgd2UgYWxyZWFkeSBwcm9t
aXNlZCB0byBjaGVjayAob2ZmbGlzdCB3aXRoIGFuIGltcGxlbWVudGVyKSB0aGF0IHRoZXJlIHdh
cyBubyB0ZXh0IHRoYXQgY29udHJhZGljdGVkIHRoZSBvcHRpb25hbGl0eSBvZiB0aGUgb3B0aW9u
IHN0YXRlZCBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMy4yLjYuPGJyPg0KPGJyPg0KSSBoYXZlIGFs
cmVhZHkgc3RhcnRlZCB0aGlzIHdpdGggYSBsaXN0IEkgcHJlcGFyZWQgKGFsc28gb2ZmbGlzdCkg
b2Ygd2hpY2ggbWlkZGxlYm94IGNoZWNraW5nIHNlY3Rpb25zIGFuIGltcGxlbWVudGVyIGNvdWxk
IGlnbm9yZSBpZiB0aGV5IHdlcmUgb25seSByZWFkaW5nIGJ1dCBub3Qgc2VuZGluZyB0aGUgVENQ
IG9wdGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQv
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2Um
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNj
b2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_VI1PR07MB088038B7B4E017DCCF4F2718935C0VI1PR07MB0880eurp_--


From nobody Tue Jul 17 06:59:31 2018
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 E25B7130FC4; Tue, 17 Jul 2018 06:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 PF9n03Rp8FUi; Tue, 17 Jul 2018 06:59:11 -0700 (PDT)
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 C32F2130F9D; Tue, 17 Jul 2018 06:59:05 -0700 (PDT)
Received: from [10.249.64.239] ([217.70.210.5]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LbuIK-1gM99t086G-00jMIs; Tue, 17 Jul 2018 15:58:21 +0200
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , Bob Briscoe , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>   
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Tue, 17 Jul 2018 15:58:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:NzguQZxbcBwu+rR9VKDvJ8ylhm37QqpaZPZW8bbpQoOpUEQ0htp XwoJRGpMljTbdn9ush/Zj3ZRr7Xyh2okdcX2a0OI9hEm8FoD8SCPIp/J/EpPrOZwfmj2qqe Trtc75B2rVaJtK5d719Qbk/iURA0xM4uKZ2yYd3BSMKS0sJYWHBFXlbI2qKjBqRFJPqQk6V ohG0f2h3KbzENd9Q6VssQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:7VmrMuvd0r0=:UJsuLJdUtjrXuaGEG+s3Hk QLRWkaxHQ/xWNosE8yPBv8IzYnfDLxqAIjiE0eppTDuQaGDv9dnBXauMhKkIyPf3sZvHInj7O +t3TWI28F2ly+6RJEG8QX9065efBv4QVhg82dRccx+fInOKJxPxjlXlYI44SYGCjd+0j5QI4c zcZQZ2CSAGjDfYlp0F03VlCiQ6HruAm3ucpd59mFUDX4E7XgadQPMqAC2AVC0QBL1nMQsOGDo PTRl+BRS8eMP7gAPu1Yav8Oj9olJkKifLHlh68yLkSyczGTKeXwBk0C/H07aDPrMh+lMKiGzd FJjb4XWtwruiTZWz5Jwssf/0LN3YaFfdtBaBc5orUsvaC9pry8iYp0PfFuXRdQWM0acQmQIth oeJqmuWojcAitAMN16aHRT6MT6EUH0ZcpwQBO1/chSUA41sLuB5mCorWcfThvOwPD2XtbNVWP Efc68OmInr7+gmJlbK7y1oYnaHBjLmBNjRb9MfhdjL2fCUaZWOnMXqgtJMLDAKaSSl7naChOz 7ncfJ3UsjnBaSyBVpDpJjsKJHf0GMihd0T2791f1CJ58OlJwXQwjW0ZgCYCMZQ+1WcRieBy3Z eU78kAaUorul6Jl8E9RXGvZw0La0Xk9oyNeRZa7hKclRT5G1NyxF487KDxo3Ge7rN2bnTHT24 97aA0u6Xb5CuhWe/linqKfsSf3rso2RLSayCuz/Bm/GZyaMF2RrgJkGmPu0HKWueij15904WD PNZ9TIeoD3+yM+Jyo8f05k2EBQAxCwJA5L16VgRMUpGa7BgAwHZmxD5dKOSkgMXkPrmXFUTTb +LhBp+B
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 13:59:29 -0000

Hi,

I agree, the RECOMMENDED would belong to the actual mechanisms which 
would make use of the increased fidelity of the feedback mechanism.

The feedback mechanism can be implemented to provide both signals - one 
that is compatible with the legacy use of ECN, and one with high 
accuracy. These are implementation details though. However, AccECN would 
be functionally backwards compatible with 3168 and therefor work with 
all algorithms using ECN signals.

Adding the out-of-scope statement seems like a good approach to me.

Regards,
   Richard

Am 17.07.2018 um 14:57 schrieb Scharf, Michael (Nokia - DE/Stuttgart):
> I would prefer the first, shorter wording.
> 
> For instance, it would be possible that TCPM decides to obsolete RFC 
> 5562. I’d suggest to keep the status and future use of RFC 5562 in 
> combination with ECN++ outside of this document.
> 
> What might be in scope of the AccECN spec would be a hypothetical use of 
> AccECN in combination with RFC 5562. But I would be fine with just 
> omitting that. Alternatively, a more statement not related to the status 
> would be “a combination of AccECN with RFC 5562 is outside the scope of 
> this document”.
> 
> Actually, I am also not sure if this paragraph is a good example for 
> RECOMMENDED in a capital letters. To me, the following would be sufficient:
> 
>     It is recommended that the AccECN protocol is implemented along with
> 
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
> 
> Michael
> 
> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
> *Sent:* Tuesday, July 17, 2018 2:43 PM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) ; 
> draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org
> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
> 
> Michael,
> 
> I've written the proposed edits into a local copy of draft-08, which 
> we'll post after this IETF.
> 
> Wile writing the last point, I thought it best to add an extra sentence.
> 
>     It is RECOMMENDED that the AccECN protocol is implemented along with
> 
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
> 
>     [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
> 
>     experimental scheme [RFC5562] so there is no need to implement RFC
> 
>     5562 along with AccECN.
> 
> 
> 
> Bob
> 
> On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> 
>     This would for for me.
> 
>     Thanks
> 
>     Michael
> 
>     *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>     *Sent:* Tuesday, July 17, 2018 1:34 AM
>     *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>      ;
>     draft-ietf-tcpm-accurate-ecn@ietf.org
>     ; tcpm@ietf.org
>     
>     *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
> 
>     Michael,
> 
>     On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> 
>         Hi all,
> 
>           
> 
>         While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
> 
>           
> 
>           
> 
>         Section 1. Introduction
> 
>           
> 
>             It is likely (but not required) that the AccECN protocol will be
> 
>             implemented along with the following experimental additions to the
> 
>             TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
> 
>             [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
> 
>             ACK experiment [RFC5562]; and testing receiver non-compliance
> 
>             [I-D.moncaster-tcpm-rcv-cheat].
> 
>           
> 
>         [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?
> 
> 
>     I agree. For ECN++, I think something like your suggestion of
>     "useful", or even RECOMMENDED is what is needed here. I think the
>     testing receiver compliance one could be removed from the intro.
>     It's mentioned under testing for unexpected interference and under
>     integrity checking, which are sufficient.
> 
>     Also, this makes me notice that the word "includes" is wrong. ECN++
>     intends to obsolete RFC5562, but I don't think we need to mention
>     that here (cos it might change before ECN++ gets published).
> 
>     CURRENT TEXT:
> 
>         It is likely (but not required) that the AccECN protocol will be
> 
>         implemented along with the following experimental additions to the
> 
>         TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
> 
>         [I-D.ietf-tcpm-generalized-ecn
>     ], which includes the ECN-capable SYN/
> 
>         ACK experiment [RFC5562 ]; and testing receiver non-compliance
> 
>         [I-D.moncaster-tcpm-rcv-cheat
>     ].
> 
>     PROPOSED TEXT:
> 
>         It is RECOMMENDED that the AccECN protocol is implemented along with
> 
>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>     ].
> 
> 
> 
> 
>           
> 
>           
> 
>           
> 
>         Section 2.1.  Capability Negotiation
> 
>             
> 
>             The TCP server sends the AccECN
> 
>             Option on the SYN/ACK and the client sends it on the first ACK to
> 
>             test whether the network path forwards the option correctly.
> 
>           
> 
>         [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
> 
>     OK, we need to review section 2, to ensure it is consistent with
>     changes that have been made in the normative section 3 since it was
>     written.
> 
>     In this particular case, we already promised to check (offlist with
>     an implementer) that there was no text that contradicted the
>     optionality of the option stated at the end of Section 3.2.6.
> 
>     I have already started this with a list I prepared (also offlist) of
>     which middlebox checking sections an implementer could ignore if
>     they were only reading but not sending the TCP options.
> 
> 
> 
> 
>     Bob
> 
> 
> 
> 
>     -- 
> 
>     ________________________________________________________________
> 
>     Bob Briscoehttp://bobbriscoe.net/
> 
> 
> 
> -- 
> 
> ________________________________________________________________
> 
> Bob Briscoehttp://bobbriscoe.net/
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 


From nobody Tue Jul 17 08:30:38 2018
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 04917130E9E for ; Tue, 17 Jul 2018 08:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 RLoiPotvOefR for ; Tue, 17 Jul 2018 08:30:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC708130ED2 for ; Tue, 17 Jul 2018 08:30:29 -0700 (PDT)
Received: from [10.249.64.239] ([217.70.210.5]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lb5Tp-1gLgRa27yL-00kidX; Tue, 17 Jul 2018 17:30:15 +0200
To: Yoshifumi Nishida 
Cc: "tcpm@ietf.org" , ncardwell@google.com, ietf@trammell.ch
References:    <3b6c1b5f-766c-12e1-5fa9-35e369042120@gmx.at> 
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Tue, 17 Jul 2018 17:30:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:tkE/FHVOhgr11MVOexxshNGHcNpY/+eGSVsg2W4GgQzo/M6oEWl SqHL8UaHNcK8Q3AP682I3KHRw+8r3Bj0ag9d9Co1LVs18Klvt9UZg6Oz2EX+dmaKXj5c7wH e2SilvGs/5amv+LgNjPtX97mfjj6KYM+bzGqI2M6W0DIJQOwlm6Cf1AqDcGewzMVZXv9NSi /3WCffjQIoL0lQ8v1HpaQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:cDr1PaQQTUs=:RBr1htEz6MZ+h/snrt7z3r dVRsf2eHVCduo3J0ZFsUBZCOIhEXQgXb+CECoGI4RHCEmTBghiEcm9rdEWtH89w4WVOZ4NO5Q 8bCMVW2hia7wEWDu57bGEYCwjSjekWaB6iqJwi36th0SR+09lRR0ha0l7GeiH2ir1h1MERKzj EF5wCt0Z2+BLkIImO8fhl7jeHcW6uMYSEaEzDoU7vgHCgm5HDNkL+P3+/LnsXvsAeFY+x7r/q 94mlk2A9Bq4WoSH/mqO2RubDKmIRJ6f/3U/Fu2cO7ZLrQpQt4FhzlicjzYOf9+AQ7mCxO4Epo jIkGZgG0nMKufTAYjxmELsw5zImSgxcvgHXzwI99fZ5N2FepmKlAAfsilQ0mBf4NnjkdNskFI REJatXxiEoSzzKUzieerwqLEgiofaqvwwQSEW9ZerfsGQ1BhP+BFGlLGiPXAbH61c9XjY1van Xa1TCweVcmLaEv2gSvY2XjuFxLVyaNEcAhyjxmWjPQ5tni4NsRqbvIrWrsJHH4jMH8ujFlDp7 83/Iih/rYWZhKMzCAz6K0aETroYpNjIWZmCpd3GQQzOYWxmimLVyog/gdwK3py5ha833ZALSb Ay3ImtVAv281iu3zHSgAEYmmqt2qVewVKxIyeNC1qvaJ+91JEZtIinILTwWv/oVRG2Qa1iyoW Jx3I91IUXz1T65qai/o4/gUL76wP0ON6mLW5BgCZBDfNKB4bkiLFts39Ea0QIK2KvCKoScLi7 AGpts9iD3kSz4Aw1pc2s/crpLoSJlXeAahN5oVINIrMD+24itUKvmtarN46dooX1QlSqIZ6U/ WEhI5ba
Archived-At: 
Subject: Re: [tcpm] Disabling PAWS when possible
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 15:30:35 -0000

Yoshi, Neil, Brian,


As pointed out by Brian - it really sounds like the time has come to 
revive the old TS nego draft, put in the semantic changes (Randall), 
disable PAWS (usec resolution) - perhaps not explicitly declare the used 
clock granularity though.

I'd be happy to work on that again.

Richard





Am 27.06.2018 um 06:05 schrieb Yoshifumi Nishida:
> Hi Richard,
> 
> On Mon, Jun 25, 2018 at 2:32 AM, Scheffenegger, Richard  > wrote:
> 
>     Hi Yoshifumi, Neal,
> 
> 
>     Am 23.06.2018 um 01:23 schrieb Yoshifumi Nishida:
> 
>         My intention is to relax the requirement "The TSopt MUST be sent
>         in every non- segment for the duration of the connection"
>         in RFC7323
>         so that TSopt can be sent at arbitrary intervals. Arbitrary
>         intervals can contain infinite interval, but you can only do so
>         when you really want, otherwise you shouldn't.
>         So, disabling TS entirely is just an option.
> 
> 
>            >  From my perspective, one huge advantage from disabling
>         PAWS is that it
>            >  enables the timestamps to be an opaque identifier, so that
>         the sender
>            >  can use them in any way it chooses. In particular, it
>         would allow the
>            >  sender to use microsecond timestamps, without worrying
>         about the
>            >  remote side dropping packets due to PAWS checks. This was
>         the main
>            >  challenge we found in implementing microsecond TCP
>         timestamps inside
>            >  Google datacenters, as we discussed at TCPM a while back
>         (slide 6):
> 
>     [...]
> 
>     >   >  My main comment would be, if some proposal is going to
>     >   >  standardize a negotiation scheme for using timestamps but
>     >   >  disabling PAWS, IMHO there could be huge value in having that
>     >   >  negotiation mechanism optionally specify the semantics of a
>     >   >  sender's timestamp values, so that congestion control and
>     >   >  passive monitoring tools could make use of the timestamps
>     >   >  for bandwidth and latency measurements. This could be
>     >   >  something as simple as 2 bits, e.g.:
>     >   >
>     >   >  bits : meaning
>     >   >   00: traditional RFC 7323 timestamps: use PAWS
>     >   >   01: microsecond timestamps, disable PAWS
>     >   >   10: millisecond timestamps, disable PAWS
>     >   >   11: values with other semantics, disable PAWS
> 
> 
>     TSopt is today semi-opaque - a receiver can not rely on timestamps
>     to have a specific granularity or monotonicity today.
> 
>     It seems to me, that two paths should be discussed here: making
>     TSopt completely opaque - that is, disallowing the receiver to make
>     any use of it, only allowing it to be a signal from the sender in
>     the past (1RTT) to the sender in the future.
> 
>     Or making it more transparent, but disabling PAWS - meaning that the
>     content of TSopt can actually be interpreted by a receiver,
>     potentially allowing additional capabilities (one-way delay
>     variation measurement, "TCP Chirp", springs to mind).
> 
> 
>     Provided the clock granularity is fine enough, both points (unique
>     packet identifier, and allowing fine-grained timing data to be
>     extracted) could be done.
> 
>     Some of these functionalities were touched upon in this draft some
>     time ago:
>     https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05
>     
> 
> 
> Yep, signaling mechanism to change the semantics of TS is an interesting 
> point for discussions.
> We can extend TS option like you proposed in the draft or integrating 
> into existing negotiation mechanisms or developing a new option.
> Developing a new option seems to be a straightforward approach, but it 
> will consume extra option space and may be discarded by middleboxes.
> 
> BTW, the draft above is cited in the draft as a good starting point of 
> discussion.
> --
> Yoshi
> 


From nobody Tue Jul 17 13:28:22 2018
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 A5E1B130E62; Tue, 17 Jul 2018 13:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 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_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 U4J-vtK72He6; Tue, 17 Jul 2018 13:28:14 -0700 (PDT)
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 ECC6B130DEB; Tue, 17 Jul 2018 13:28:13 -0700 (PDT)
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:To:Subject: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=KSk74B6Lyui+5H/Jpsweq5YtBia40Wc5hEXqGNLJIaM=; b=2eM499pRpNS+bbm5S/dFqj3eD QfBJGDa9Xau4C1zdNb95P7NrjnUMinottQQ8NROt2i/69xu/+7kSl1HX1NXgyrvxcA3330v2QGlQU EPRQCOeRjNxNPw6axgiHubw9QmoyeaxML5twD18Ve9NbIU9YX0W5fPsPcvFYKGqCl3mqa+3+p3T6A mcuN+iDsuSmVCF0/FNZH+GIgeGhMXf2fExAFaIjsDbvxgWIXi2vhcZRhn0BSk/E6OHriUSBRgibEA fYMns5ttpqtjLhUoRyZenI6ONpt2qipLl15ILGrTcDGv0W1dXCQaHX3BqCYzB0SDhL8f0BhLFjcJU J3/5HHtNQ==;
Received: from dhcp-94a4.meeting.ietf.org ([31.133.148.164]:41274) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffWZt-0004zQ-GM; Tue, 17 Jul 2018 21:28:10 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>   
From: Bob Briscoe 
Message-ID: 
Date: Tue, 17 Jul 2018 16:28:05 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F2B4DD23B351CBD619BC4D20"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 20:28:19 -0000

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

Michael,

OK RECOMMENDED -> recommended.
That's good, otherwise I think ECN++ would have become a normative 
reference.

> Alternatively, a more statement not related to the status would be “a 
> combination of AccECN with RFC 5562 is outside the scope of this 
> document”.
Someone who had never even thought about combining AccECN with RFC5562 
might think we mean "AccECN could also be combined with RFC5562, but 
this isn't the place to talk about it?"

How about:

    It is recommended that the AccECN protocol is implemented alongside

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
].
    Therefore, this specification does not discuss implementing AccECN
    alongside the earlier experimental alternative to ECN++ in [RFC5562].





Bob

On 17/07/18 08:57, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> I would prefer the first, shorter wording.
>
> For instance, it would be possible that TCPM decides to obsolete RFC 
> 5562. I’d suggest to keep the status and future use of RFC 5562 in 
> combination with ECN++ outside of this document.
>
> What might be in scope of the AccECN spec would be a hypothetical use 
> of AccECN in combination with RFC 5562. But I would be fine with just 
> omitting that. Alternatively, a more statement not related to the 
> status would be “a combination of AccECN with RFC 5562 is outside the 
> scope of this document”.
>
> Actually, I am also not sure if this paragraph is a good example for 
> RECOMMENDED in a capital letters. To me, the following would be 
> sufficient:
>
>     It is recommended that the AccECN protocol is implemented along with
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>
> Michael
>
> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
> *Sent:* Tuesday, July 17, 2018 2:43 PM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
> ; draft-ietf-tcpm-accurate-ecn@ietf.org; 
> tcpm@ietf.org
> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Michael,
>
> I've written the proposed edits into a local copy of draft-08, which 
> we'll post after this IETF.
>
> Wile writing the last point, I thought it best to add an extra sentence.
>
>     It is RECOMMENDED that the AccECN protocol is implemented along with
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>     [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
>     experimental scheme [RFC5562] so there is no need to implement RFC
>     5562 along with AccECN.
>
>
>
> Bob
>
> On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>     This would for for me.
>
>     Thanks
>
>     Michael
>
>     *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>     *Sent:* Tuesday, July 17, 2018 1:34 AM
>     *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>      ;
>     draft-ietf-tcpm-accurate-ecn@ietf.org
>     ; tcpm@ietf.org
>     
>     *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
>     Michael,
>
>     On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>         Hi all,
>
>           
>
>         While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>
>           
>
>           
>
>         Section 1. Introduction
>
>           
>
>             It is likely (but not required) that the AccECN protocol will be
>
>             implemented along with the following experimental additions to the
>
>             TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>             [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
>
>             ACK experiment [RFC5562]; and testing receiver non-compliance
>
>             [I-D.moncaster-tcpm-rcv-cheat].
>
>           
>
>         [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?
>
>
>     I agree. For ECN++, I think something like your suggestion of
>     "useful", or even RECOMMENDED is what is needed here. I think the
>     testing receiver compliance one could be removed from the intro.
>     It's mentioned under testing for unexpected interference and under
>     integrity checking, which are sufficient.
>
>     Also, this makes me notice that the word "includes" is wrong.
>     ECN++ intends to obsolete RFC5562, but I don't think we need to
>     mention that here (cos it might change before ECN++ gets published).
>
>     CURRENT TEXT:
>
>         It is likely (but not required) that the AccECN protocol will be
>
>         implemented along with the following experimental additions to the
>
>         TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>         [I-D.ietf-tcpm-generalized-ecn
>     ], which includes the ECN-capable SYN/
>
>         ACK experiment [RFC5562 ]; and testing receiver non-compliance
>
>         [I-D.moncaster-tcpm-rcv-cheat
>     ].
>
>     PROPOSED TEXT:
>
>         It is RECOMMENDED that the AccECN protocol is implemented along with
>
>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>     ].
>
>
>
>
>           
>
>           
>
>           
>
>         Section 2.1.  Capability Negotiation
>
>             
>
>             The TCP server sends the AccECN
>
>             Option on the SYN/ACK and the client sends it on the first ACK to
>
>             test whether the network path forwards the option correctly.
>
>           
>
>         [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
>
>     OK, we need to review section 2, to ensure it is consistent with
>     changes that have been made in the normative section 3 since it
>     was written.
>
>     In this particular case, we already promised to check (offlist
>     with an implementer) that there was no text that contradicted the
>     optionality of the option stated at the end of Section 3.2.6.
>
>     I have already started this with a list I prepared (also offlist)
>     of which middlebox checking sections an implementer could ignore
>     if they were only reading but not sending the TCP options.
>
>
>
>
>     Bob
>
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoehttp://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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


--------------F2B4DD23B351CBD619BC4D20
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    OK RECOMMENDED -> recommended.

    That's good, otherwise I think ECN++ would have become a normative
    reference.

    

    
Alternatively,
        a more statement not related to the status would be “a combination of AccECN with RFC 5562
        is outside the scope of this document”.

    Someone who had never even thought about combining AccECN with
    RFC5562 might think we mean "AccECN could also be combined with
    RFC5562, but this isn't the place to talk about it?" 

    

    How about:

    
   It is recommended that the AccECN protocol is implemented alongside

    
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 
   Therefore, this specification does not discuss implementing AccECN 
   alongside the earlier experimental alternative to ECN++ in [RFC5562].


    

    

    

    

    Bob

    

    
On 17/07/18 08:57, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      
      
      
      

        
I would
            prefer the first, shorter wording.

        
 

        
For
            instance, it would be possible that TCPM decides to obsolete
            RFC 5562. I’d suggest to keep the status and
            future use of RFC 5562 in combination with ECN++ outside of
            this document.

        
 

        
What might
            be in scope of the AccECN spec would be a hypothetical use
            of AccECN in combination with RFC 5562. But I would be fine
            with just omitting that. Alternatively, a more statement not
            related to the status would be “a combination of AccECN with RFC
            5562 is outside the scope of this document”.

        
 

        
Actually, I
            am also not sure if this paragraph is a good example for
            RECOMMENDED in a capital letters. To me, the following would
            be sufficient:

        
 

        
   It is recommended that the AccECN protocol is implemented along with

        
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

        
 

        
Michael

        
 

        

          

            

              
From: Bob Briscoe
                  [mailto:ietf@bobbriscoe.net]
                  

                  Sent: Tuesday, July 17, 2018 2:43 PM

                  To: Scharf, Michael (Nokia - DE/Stuttgart)
                  <michael.scharf@nokia.com>;
                  draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                  Subject: Re: [tcpm] Further comments on
                  draft-ietf-tcpm-accurate-ecn

            

          

          
 

          
Michael,

            

            I've written the proposed edits into a local copy of
            draft-08, which we'll post after this IETF.

            

            Wile writing the last point, I thought it best to add an
            extra sentence.

          
   It is RECOMMENDED that the AccECN protocol is implemented along with

          
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

          
   [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another

          
   experimental scheme [RFC5562] so there is no need to implement RFC

          
   5562 along with AccECN.

          
 

          


            

            Bob

          

            
On 17/07/18 01:05, Scharf, Michael
              (Nokia - DE/Stuttgart) wrote:

          

          

            
This
                would for for me.

            
 

            
Thanks

            
 

            
Michael

            
 

            

              

                

                  
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                      

                      Sent: Tuesday, July 17, 2018 1:34 AM

                      To: Scharf, Michael (Nokia - DE/Stuttgart)
                      
                        <michael.scharf@nokia.com>; 
                        draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                      Subject: Re: [tcpm] Further comments on
                      draft-ietf-tcpm-accurate-ecn

                

              

              
 

              
Michael,

              

                
On 15/07/18 16:54, Scharf, Michael
                  (Nokia - DE/Stuttgart) wrote:

              

              

                
Hi all,

                
 

                
While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:

                
 

                
 

                
Section 1. Introduction

                
 

                
   It is likely (but not required) that the AccECN protocol will be

                
   implemented along with the following experimental additions to the

                
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                
   ACK experiment [RFC5562]; and testing receiver non-compliance

                
   [I-D.moncaster-tcpm-rcv-cheat].

                
 

                
[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

              

              


                I agree. For ECN++, I think something like your
                suggestion of "useful", or even RECOMMENDED is what is
                needed here. I think the testing receiver compliance one
                could be removed from the intro. It's mentioned under
                testing for unexpected interference and under integrity
                checking, which are sufficient. 

                

                Also, this makes me notice that the word "includes" is
                wrong. ECN++ intends to obsolete RFC5562, but I don't
                think we need to mention that here (cos it might change
                before ECN++ gets published).

                

                CURRENT TEXT:

              
   It is likely (but not required) that the AccECN protocol will be

              
   implemented along with the following experimental additions to the

              
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

              
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

              
   ACK experiment [RFC5562]; and testing receiver non-compliance

              
   [I-D.moncaster-tcpm-rcv-cheat].

              
PROPOSED TEXT:

              
   It is RECOMMENDED that the AccECN protocol is implemented along with

              
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

              


                

                

                

              

                
 

                
 

                
 

                
Section 2.1.  Capability Negotiation

                
   

                
   The TCP server sends the AccECN

                
   Option on the SYN/ACK and the client sends it on the first ACK to

                
   test whether the network path forwards the option correctly.

                
 

                
[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.

              

              
OK, we need to review section 2, to
                ensure it is consistent with changes that have been made
                in the normative section 3 since it was written.

                

                In this particular case, we already promised to check
                (offlist with an implementer) that there was no text
                that contradicted the optionality of the option stated
                at the end of Section 3.2.6.

                

                I have already started this with a list I prepared (also
                offlist) of which middlebox checking sections an
                implementer could ignore if they were only reading but
                not sending the TCP options.

                

                

                

                

                Bob

                

                

                

                

                

              
-- 

              
________________________________________________________________

              
Bob Briscoe                               http://bobbriscoe.net/

            

          

          


            

            

          
-- 

          
________________________________________________________________

          
Bob Briscoe                               http://bobbriscoe.net/

        

      

    

    

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

  


--------------F2B4DD23B351CBD619BC4D20--


From nobody Tue Jul 17 14:02:08 2018
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 08FD0130DEB; Tue, 17 Jul 2018 14:02:07 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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=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 5C9ytpdSDQ26; Tue, 17 Jul 2018 14:02:03 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5B5129C6B; Tue, 17 Jul 2018 14:02:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5YO/TLTTGZFSg9RvwNFmhvNs+KxdOsBbL4woG2EQfAg=; b=OdUfx1GXBr4eurm5m6Bvtv+hU/qcqohkHEEOAA5s4A+1lkVspH4kLkfQeziM6po+cNgb0WJ1ImeNU0Ame4IyA3ZuqCbWmcVRJjm+ltKoCIDbyfOtfQOpNHXieziy7XNCP1C92CmSSvAxPVQc/zGoaS3B4CVgxhzSkpwMHOvvXOI=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB4509.eurprd07.prod.outlook.com (20.177.56.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Tue, 17 Jul 2018 21:01:59 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.013; Tue, 17 Jul 2018 21:01:59 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgA5JfwAAAuIsyAAEAC+AAAADp/gABA0BIAAAApQUA==
Date: Tue, 17 Jul 2018 21:01:58 +0000
Message-ID: 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>    
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-originating-ip: [92.203.174.125]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4509; 6:tyrfa8ErPc1utuH/SV0buoyGg+pruLH2MugKrAaAdTRqWOqLV6NwNzA3xpAIto7UOon1WadJp3ZELwCKG53CNHesQCzUnizYVU+VyP+F2ELJpKS6o4EDgbhTPf/bW8jQKHuldD5jszlIpgGx0pBPulEJ30fjfLwQ33ak8YN8pZQqOViFcpiKx9ZOALWguaO7is4zZLm6UPsidaMwQ03l4bo6hmsMTz+vmznkBHc7E9or7/OTyrC0SKm61cx92tmVO72cJwHPKbpnywMJH3J/n45NXtkn0mtQEk5KRluYkgtsJ8f0fpIeQobGI9w/pmQ6Ui2XtvCrjsQVUHUUdDNmsJ9LZN4s989pfPLXSoUsNoHTQyziixVYFTdN7Dj04nelx9jQ8OO44k6ug5V2cHw1QZQfhnwTjcxZ0wnT4WbXACBxihdDo161Db0hpzPMcw0sdFQmygGcTfhuU3Zc8veGow==; 5:eUFUW4oSCdy7dgHprlzqkNk522Z0tyv0r+W1UwDOeg9ZwCwQjokSMl3UO2iQVH3yzdOxJT5Wf5BXqkkWXPOc1JJWKS9J4vaOxrZ6AC2FszNdp5EhTNWkJgIE1T8/001rwsXzGGH5TOJE2p1pxeNEcjpXl9l7+Pg7FoTUPmMu5zk=; 7:dRLLThDkwQSd3syXaKnXB4Cx9yw+iwf/zAx+uEZx1YWYe4yUVejl6kXptyFxsXlVPXXmCqf1cc53ie9WSba9pkeNHXl/I4OJbo2NZGPAXp1serRljyvzUwVVFH2/tFZjwv+GfnDHFAaQt0pJp4SSqH6KTQdr7pXmeaPizQFPluBEKwE2jsbsY52eK10CO5S3bJ+roJxwojQzQ1rGByDghn73OmYuekq4D3dHeYj0OzWY3ULXus3cqLJLx4P5R6kN
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 7b6a6639-4f0d-47e7-1a43-08d5ec288971
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:VI1PR07MB4509; 
x-ms-traffictypediagnostic: VI1PR07MB4509:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(82608151540597)(109105607167333)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB4509; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4509; 
x-forefront-prvs: 073631BD3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(376002)(136003)(346002)(199004)(189003)(53754006)(8936002)(102836004)(76176011)(25786009)(2900100001)(229853002)(7696005)(74316002)(99286004)(476003)(11346002)(53546011)(486006)(53936002)(86362001)(2201001)(7736002)(33656002)(53376002)(256004)(66066001)(6506007)(14444005)(446003)(6246003)(110136005)(6306002)(81166006)(5250100002)(186003)(790700001)(3846002)(55016002)(6116002)(8676002)(6436002)(9686003)(97736004)(81156014)(54896002)(5660300001)(68736007)(236005)(316002)(966005)(93886005)(478600001)(105586002)(26005)(106356001)(2906002)(14454004)(2501003)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4509; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: mCe6yoWwFDnEaGxZ6vhD5QBt8CpM71jApsejYLz0cEl6rDhlRHahQYBhDoCJLJV2qO0a5GmgphWBaQTHBnCPEPSC6E/vlfWORIjBd8daO8drKvfHx/BjuTG1lXcmqihZOUrD34c+/e/U+ILo3t9OBSmzDW2E6ge/qV3AhXcCHLa18jQJfY6E/SuJRpxXhG4hTMmicdwVgBAAQXMGIUk6uviG2ziS1jfi0EHtdgivXNB3VgW8/IGvAbVJustOPC5YGoS0Bj0w7rL16ngHBbTwvTGMBNFjk8Hj5dxIvrWrmKiWONBXuhfZlVzoFnzeIV5JwuVgA2sfCrCUJw/G/Ixnqm8gPZzJNnTZpwDRUOYKfuUglBSDuN9Ri9Jz+t4DDXN6buOWnAXs1nu9FwjO7U5bNA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB088008BBCA30D8391D31E302935C0VI1PR07MB0880eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b6a6639-4f0d-47e7-1a43-08d5ec288971
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 21:01:59.0230 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4509
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 21:02:07 -0000

--_000_VI1PR07MB088008BBCA30D8391D31E302935C0VI1PR07MB0880eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyB3b3JkaW5nIHdvdWxkIGltcGx5IHRoYXQgRUNOKysgYW5kIFJGQyA1NTYyIGFyZSBpbmRl
ZWQg4oCcYWx0ZXJuYXRpdmVz4oCdLiBUaGF0IGlzIElNSE8gbm90IGZ1bGx5IGNvcnJlY3QsIEVD
TisrIHNlZW1zIHRvIGhhdmUgYSBicm9hZGVyIHNjb3BlLg0KDQpJIHRoaW5rIHNvbWV0aGluZyBh
bG9uZyB0aGUgbGluZXMgb2Yg4oCmDQoNCg0KICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUg
QWNjRUNOIHByb3RvY29sIGlzIGltcGxlbWVudGVkIGFsb25nc2lkZQ0KDQogICB0aGUgZXhwZXJp
bWVudGFsIEVDTisrIHByb3RvY29sIFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjxodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNy
ZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY24+XS4NCg0KICAgVGhpcyBzcGVjaWZpY2F0
aW9uIGRvZXMgbm90IGRpc2N1c3MgaW1wbGVtZW50aW5nIEFjY0VDTg0KDQogICBhbG9uZ3NpZGUg
dGhlIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBbUkZDNTU2Ml0uDQoNCuKApiBkb2VzIHRoZSBqb2Iu
DQoNCk1pY2hhZWwNCg0KDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2Jicmlz
Y29lLm5ldF0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTggMTA6MjggUE0NClRvOiBTY2hh
cmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSA8bWljaGFlbC5zY2hhcmZAbm9raWEu
Y29tPjsgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZzsgdGNwbUBpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNw
bS1hY2N1cmF0ZS1lY24NCg0KTWljaGFlbCwNCg0KT0sgUkVDT01NRU5ERUQgLT4gcmVjb21tZW5k
ZWQuDQpUaGF0J3MgZ29vZCwgb3RoZXJ3aXNlIEkgdGhpbmsgRUNOKysgd291bGQgaGF2ZSBiZWNv
bWUgYSBub3JtYXRpdmUgcmVmZXJlbmNlLg0KDQoNCkFsdGVybmF0aXZlbHksIGEgbW9yZSBzdGF0
ZW1lbnQgbm90IHJlbGF0ZWQgdG8gdGhlIHN0YXR1cyB3b3VsZCBiZSDigJxhIGNvbWJpbmF0aW9u
IG9mIEFjY0VDTiB3aXRoIFJGQyA1NTYyIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9j
dW1lbnTigJ0uDQpTb21lb25lIHdobyBoYWQgbmV2ZXIgZXZlbiB0aG91Z2h0IGFib3V0IGNvbWJp
bmluZyBBY2NFQ04gd2l0aCBSRkM1NTYyIG1pZ2h0IHRoaW5rIHdlIG1lYW4gIkFjY0VDTiBjb3Vs
ZCBhbHNvIGJlIGNvbWJpbmVkIHdpdGggUkZDNTU2MiwgYnV0IHRoaXMgaXNuJ3QgdGhlIHBsYWNl
IHRvIHRhbGsgYWJvdXQgaXQ/Ig0KDQpIb3cgYWJvdXQ6DQoNCiAgIEl0IGlzIHJlY29tbWVuZGVk
IHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZ3NpZGUNCg0KICAg
dGhlIGV4cGVyaW1lbnRhbCBFQ04rKyBwcm90b2NvbCBbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXpl
ZC1lY248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0
ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPl0uDQoNCiAgIFRoZXJl
Zm9yZSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGRpc2N1c3MgaW1wbGVtZW50aW5nIEFj
Y0VDTg0KDQogICBhbG9uZ3NpZGUgdGhlIGVhcmxpZXIgZXhwZXJpbWVudGFsIGFsdGVybmF0aXZl
IHRvIEVDTisrIGluIFtSRkM1NTYyXS4NCg0KDQoNCg0KQm9iDQpPbiAxNy8wNy8xOCAwODo1Nywg
U2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6DQpJIHdvdWxkIHBy
ZWZlciB0aGUgZmlyc3QsIHNob3J0ZXIgd29yZGluZy4NCg0KRm9yIGluc3RhbmNlLCBpdCB3b3Vs
ZCBiZSBwb3NzaWJsZSB0aGF0IFRDUE0gZGVjaWRlcyB0byBvYnNvbGV0ZSBSRkMgNTU2Mi4gSeKA
mWQgc3VnZ2VzdCB0byBrZWVwIHRoZSBzdGF0dXMgYW5kIGZ1dHVyZSB1c2Ugb2YgUkZDIDU1NjIg
aW4gY29tYmluYXRpb24gd2l0aCBFQ04rKyBvdXRzaWRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCldo
YXQgbWlnaHQgYmUgaW4gc2NvcGUgb2YgdGhlIEFjY0VDTiBzcGVjIHdvdWxkIGJlIGEgaHlwb3Ro
ZXRpY2FsIHVzZSBvZiBBY2NFQ04gaW4gY29tYmluYXRpb24gd2l0aCBSRkMgNTU2Mi4gQnV0IEkg
d291bGQgYmUgZmluZSB3aXRoIGp1c3Qgb21pdHRpbmcgdGhhdC4gQWx0ZXJuYXRpdmVseSwgYSBt
b3JlIHN0YXRlbWVudCBub3QgcmVsYXRlZCB0byB0aGUgc3RhdHVzIHdvdWxkIGJlIOKAnGEgY29t
YmluYXRpb24gb2YgQWNjRUNOIHdpdGggUkZDIDU1NjIgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg
dGhpcyBkb2N1bWVudOKAnS4NCg0KQWN0dWFsbHksIEkgYW0gYWxzbyBub3Qgc3VyZSBpZiB0aGlz
IHBhcmFncmFwaCBpcyBhIGdvb2QgZXhhbXBsZSBmb3IgUkVDT01NRU5ERUQgaW4gYSBjYXBpdGFs
IGxldHRlcnMuIFRvIG1lLCB0aGUgZm9sbG93aW5nIHdvdWxkIGJlIHN1ZmZpY2llbnQ6DQoNCg0K
ICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIGlzIGltcGxlbWVu
dGVkIGFsb25nIHdpdGgNCg0KICAgdGhlIGV4cGVyaW1lbnRhbCBFQ04rKyBwcm90b2NvbCBbSS1E
LmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6
ZWQtZWNuPl0uDQoNCk1pY2hhZWwNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJv
YmJyaXNjb2UubmV0XQ0KU2VudDogVHVlc2RheSwgSnVseSAxNywgMjAxOCAyOjQzIFBNDQpUbzog
U2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5v
a2lhLmNvbT48bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT47IGRyYWZ0LWlldGYtdGNw
bS1hY2N1cmF0ZS1lY25AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1l
Y25AaWV0Zi5vcmc+OyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KU3ViamVj
dDogUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0
ZS1lY24NCg0KTWljaGFlbCwNCg0KSSd2ZSB3cml0dGVuIHRoZSBwcm9wb3NlZCBlZGl0cyBpbnRv
IGEgbG9jYWwgY29weSBvZiBkcmFmdC0wOCwgd2hpY2ggd2UnbGwgcG9zdCBhZnRlciB0aGlzIElF
VEYuDQoNCldpbGUgd3JpdGluZyB0aGUgbGFzdCBwb2ludCwgSSB0aG91Z2h0IGl0IGJlc3QgdG8g
YWRkIGFuIGV4dHJhIHNlbnRlbmNlLg0KDQogICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBB
Y2NFQ04gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aA0KDQogICB0aGUgZXhwZXJp
bWVudGFsIEVDTisrIHByb3RvY29sIFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjxodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNy
ZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY24+XS4NCg0KICAgW0ktRC5pZXRmLXRjcG0t
Z2VuZXJhbGl6ZWQtZWNuXSBpcyBhIHByb3Bvc2VkIGFsdGVybmF0aXZlIHRvIGFub3RoZXINCg0K
ICAgZXhwZXJpbWVudGFsIHNjaGVtZSBbUkZDNTU2Ml0gc28gdGhlcmUgaXMgbm8gbmVlZCB0byBp
bXBsZW1lbnQgUkZDDQoNCiAgIDU1NjIgYWxvbmcgd2l0aCBBY2NFQ04uDQoNCg0KDQoNCkJvYg0K
T24gMTcvMDcvMTggMDE6MDUsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQp
IHdyb3RlOg0KVGhpcyB3b3VsZCBmb3IgZm9yIG1lLg0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQpG
cm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBUdWVz
ZGF5LCBKdWx5IDE3LCAyMDE4IDE6MzQgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0g
REUvU3R1dHRnYXJ0KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPjxtYWlsdG86bWljaGFlbC5z
Y2hhcmZAbm9raWEuY29tPjsgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZzxt
YWlsdG86ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZz47IHRjcG1AaWV0Zi5v
cmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIEZ1cnRoZXIgY29t
bWVudHMgb24gZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbg0KDQpNaWNoYWVsLA0KT24gMTUv
MDcvMTggMTY6NTQsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3Rl
Og0KDQpIaSBhbGwsDQoNCg0KDQpXaGlsZSByZWFkaW5nIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0
ZS1lY24tMDcsIEkgbm90aWNlZCB0aGUgZm9sbG93aW5nOg0KDQoNCg0KDQoNClNlY3Rpb24gMS4g
SW50cm9kdWN0aW9uDQoNCg0KDQogICBJdCBpcyBsaWtlbHkgKGJ1dCBub3QgcmVxdWlyZWQpIHRo
YXQgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlDQoNCiAgIGltcGxlbWVudGVkIGFsb25nIHdp
dGggdGhlIGZvbGxvd2luZyBleHBlcmltZW50YWwgYWRkaXRpb25zIHRvIHRoZQ0KDQogICBUQ1At
RUNOIHByb3RvY29sOiBFQ04tY2FwYWJsZSBUQ1AgY29udHJvbCBwYWNrZXRzIGFuZCByZXRyYW5z
bWlzc2lvbnMNCg0KICAgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuXSwgd2hpY2ggaW5j
bHVkZXMgdGhlIEVDTi1jYXBhYmxlIFNZTi8NCg0KICAgQUNLIGV4cGVyaW1lbnQgW1JGQzU1NjJd
OyBhbmQgdGVzdGluZyByZWNlaXZlciBub24tY29tcGxpYW5jZQ0KDQogICBbSS1ELm1vbmNhc3Rl
ci10Y3BtLXJjdi1jaGVhdF0uDQoNCg0KDQpbbXNdIEkgaGF2ZSBjb21tZW50ZWQgb24gdGhpcyBz
ZWN0aW9uIGJlZm9yZS4gQW5kIEkgc3RpbGwgZGlzbGlrZSB0aGUgdGVybSAibGlrZWx5Ii4gVG8g
bWUsICJsaWtlbHkiIGlzIHNwZWN1bGF0aW9uLiBBIG5ldXRyYWwgcGhyYXNpbmcgd291bGQgYmUg
Ii4uLiBpdCBpcyBwb3NzaWJsZS4uLiIgb3IgIi4uLiBpdCBpcyB1c2VmdWwuLi4iLiBIYXZpbmcg
c2FpZCB0aGlzLCBJIG9ic2VydmUgdGhhdCBkcmFmdC1tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQt
MDMgd2FzIGxhc3QgdXBkYXRlZCBpbiAyMDE0LiBIb3cgImxpa2VseSIgaXMgaXQgdGhhdCB0aGUg
QWNjRUNOIHByb3RvY29sIHdpbGwgYmUgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aCBhIG1lY2hhbmlz
bSBkb2N1bWVudGVkIGluIGFuIElEIHRoYXQgaGFzIGJlZW4gd3JpdHRlbiBtb3JlIHRoYW4gMTAg
eWVhcnMgYWdvIGFuZCBub3QgYmVlbiB1cGRhdGVkIGZvciBhYm91dCA0IHllYXJzPyBBcmUgaW1w
bGVtZW50ZXJzIGluZGVlZCBzbyBpbnRlcmVzdGVkIGluIGRyYWZ0LW1vbmNhc3Rlci10Y3BtLXJj
di1jaGVhdCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGlzICJsaWtlbHkiPw0KDQpJIGFncmVlLiBG
b3IgRUNOKyssIEkgdGhpbmsgc29tZXRoaW5nIGxpa2UgeW91ciBzdWdnZXN0aW9uIG9mICJ1c2Vm
dWwiLCBvciBldmVuIFJFQ09NTUVOREVEIGlzIHdoYXQgaXMgbmVlZGVkIGhlcmUuIEkgdGhpbmsg
dGhlIHRlc3RpbmcgcmVjZWl2ZXIgY29tcGxpYW5jZSBvbmUgY291bGQgYmUgcmVtb3ZlZCBmcm9t
IHRoZSBpbnRyby4gSXQncyBtZW50aW9uZWQgdW5kZXIgdGVzdGluZyBmb3IgdW5leHBlY3RlZCBp
bnRlcmZlcmVuY2UgYW5kIHVuZGVyIGludGVncml0eSBjaGVja2luZywgd2hpY2ggYXJlIHN1ZmZp
Y2llbnQuDQoNCkFsc28sIHRoaXMgbWFrZXMgbWUgbm90aWNlIHRoYXQgdGhlIHdvcmQgImluY2x1
ZGVzIiBpcyB3cm9uZy4gRUNOKysgaW50ZW5kcyB0byBvYnNvbGV0ZSBSRkM1NTYyLCBidXQgSSBk
b24ndCB0aGluayB3ZSBuZWVkIHRvIG1lbnRpb24gdGhhdCBoZXJlIChjb3MgaXQgbWlnaHQgY2hh
bmdlIGJlZm9yZSBFQ04rKyBnZXRzIHB1Ymxpc2hlZCkuDQoNCkNVUlJFTlQgVEVYVDoNCg0KICAg
SXQgaXMgbGlrZWx5IChidXQgbm90IHJlcXVpcmVkKSB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wg
d2lsbCBiZQ0KDQogICBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIHRoZSBmb2xsb3dpbmcgZXhwZXJp
bWVudGFsIGFkZGl0aW9ucyB0byB0aGUNCg0KICAgVENQLUVDTiBwcm90b2NvbDogRUNOLWNhcGFi
bGUgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQgcmV0cmFuc21pc3Npb25zDQoNCiAgIFtJLUQuaWV0
Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1l
Y24+XSwgd2hpY2ggaW5jbHVkZXMgdGhlIEVDTi1jYXBhYmxlIFNZTi8NCg0KICAgQUNLIGV4cGVy
aW1lbnQgW1JGQzU1NjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1NjI+XTsgYW5k
IHRlc3RpbmcgcmVjZWl2ZXIgbm9uLWNvbXBsaWFuY2UNCg0KICAgW0ktRC5tb25jYXN0ZXItdGNw
bS1yY3YtY2hlYXQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1h
Y2N1cmF0ZS1lY24tMDcjcmVmLUktRC5tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQ+XS4NClBST1BP
U0VEIFRFWFQ6DQoNCiAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIEFjY0VDTiBwcm90b2Nv
bCBpcyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoDQoNCiAgIHRoZSBleHBlcmltZW50YWwgRUNOKysg
cHJvdG9jb2wgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10
Y3BtLWdlbmVyYWxpemVkLWVjbj5dLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNlY3Rpb24gMi4x
LiAgQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbg0KDQoNCg0KICAgVGhlIFRDUCBzZXJ2ZXIgc2VuZHMg
dGhlIEFjY0VDTg0KDQogICBPcHRpb24gb24gdGhlIFNZTi9BQ0sgYW5kIHRoZSBjbGllbnQgc2Vu
ZHMgaXQgb24gdGhlIGZpcnN0IEFDSyB0bw0KDQogICB0ZXN0IHdoZXRoZXIgdGhlIG5ldHdvcmsg
cGF0aCBmb3J3YXJkcyB0aGUgb3B0aW9uIGNvcnJlY3RseS4NCg0KDQoNClttc10gQWNjb3JkaW5n
IHRvIFNlY3Rpb24gMy4yLjYsIG9wdGlvbnMgYXJlIFJFQ09NTUVOREVELiBXaGlsZSBTZWN0aW9u
IDIgaXMgbm90IG5vcm1hdGl2ZSwgdGhlIHdob2xlIFNlY3Rpb24gMiBkb2VzIG5vdCByZWFsbHkg
ZGVzY3JpYmUgd2VsbCB0aGUgYWN0dWFsIHJlcXVpcmVtZW50cyByZWdhcmRpbmcgb3B0aW9ucy4g
VGhpcyBwYXJhZ3JhcGggaW4gU2VjdGlvbiAyLjEgaXMgb25lIGV4YW1wbGUgZm9yIHRoYXQuIEl0
IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYmUgbW9yZSBleHBsaWNpdCBpbiBTZWN0aW9uIDIgdG8gd2hp
Y2ggZXh0ZW50IG9wdGlvbnMgaGF2ZSB0byBiZSBzdXBwb3J0ZWQuDQpPSywgd2UgbmVlZCB0byBy
ZXZpZXcgc2VjdGlvbiAyLCB0byBlbnN1cmUgaXQgaXMgY29uc2lzdGVudCB3aXRoIGNoYW5nZXMg
dGhhdCBoYXZlIGJlZW4gbWFkZSBpbiB0aGUgbm9ybWF0aXZlIHNlY3Rpb24gMyBzaW5jZSBpdCB3
YXMgd3JpdHRlbi4NCg0KSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHdlIGFscmVhZHkgcHJvbWlz
ZWQgdG8gY2hlY2sgKG9mZmxpc3Qgd2l0aCBhbiBpbXBsZW1lbnRlcikgdGhhdCB0aGVyZSB3YXMg
bm8gdGV4dCB0aGF0IGNvbnRyYWRpY3RlZCB0aGUgb3B0aW9uYWxpdHkgb2YgdGhlIG9wdGlvbiBz
dGF0ZWQgYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDMuMi42Lg0KDQpJIGhhdmUgYWxyZWFkeSBzdGFy
dGVkIHRoaXMgd2l0aCBhIGxpc3QgSSBwcmVwYXJlZCAoYWxzbyBvZmZsaXN0KSBvZiB3aGljaCBt
aWRkbGVib3ggY2hlY2tpbmcgc2VjdGlvbnMgYW4gaW1wbGVtZW50ZXIgY291bGQgaWdub3JlIGlm
IHRoZXkgd2VyZSBvbmx5IHJlYWRpbmcgYnV0IG5vdCBzZW5kaW5nIHRoZSBUQ1Agb3B0aW9ucy4N
Cg0KDQoNCg0KQm9iDQoNCg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoN
Cg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBC
cmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5l
dC8NCg==

--_000_VI1PR07MB088008BBCA30D8391D31E302935C0VI1PR07MB0880eurp_
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
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu
MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0
aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N
CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286
c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3
aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij5UaGlzIHdvcmRpbmcgd291bGQgaW1wbHkgdGhhdCBFQ04mIzQzOyYjNDM7
IGFuZCBSRkMgNTU2MiBhcmUgaW5kZWVkDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij7igJw8
L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmFsdGVybmF0aXZlczwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm
O2NvbG9yOndpbmRvd3RleHQiPuKAnTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+LiBUaGF0IGlzIElNSE8gbm90DQogZnVsbHkgY29ycmVjdCwgRUNOJiM0MzsmIzQzOyBzZWVt
cyB0byBoYXZlIGEgYnJvYWRlciBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPkkgdGhpbmsgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZg0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy
aWY7Y29sb3I6d2luZG93dGV4dCI+4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0
ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29s
IGlzIGltcGxlbWVudGVkIGFsb25nc2lkZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAm
bmJzcDt0aGUgZXhwZXJpbWVudGFsIEVDTiYjNDM7JiM0MzsgcHJvdG9jb2wgWzxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3
I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbiIgdGl0bGU9IiZxdW90O0VDTiYjNDM7
JiM0Mzs6IEFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBU
Q1AgQ29udHJvbCBQYWNrZXRzJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjwv
YT5dLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDtUaGlzIHNwZWNp
ZmljYXRpb24gZG9lcyBub3QgZGlzY3VzcyBpbXBsZW1lbnRpbmcgQWNjRUNOIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO2Fsb25nc2lkZSB0aGUgZXhwZXJpbWVudGFs
IHByb3RvY29sIFtSRkM1NTYyXS48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+4oCmPC9zcGFu
PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gZG9lcyB0aGUgam9iLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbbWFpbHRvOmll
dGZAYm9iYnJpc2NvZS5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywg
MjAxOCAxMDoyOCBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERF
L1N0dXR0Z2FydCkgJmx0O21pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSZndDs7IGRyYWZ0LWlldGYt
dGNwbS1hY2N1cmF0ZS1lY25AaWV0Zi5vcmc7IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1hY2N1
cmF0ZS1lY248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N
aWNoYWVsLDxicj4NCjxicj4NCk9LIFJFQ09NTUVOREVEIC0mZ3Q7IHJlY29tbWVuZGVkLjxicj4N
ClRoYXQncyBnb29kLCBvdGhlcndpc2UgSSB0aGluayBFQ04mIzQzOyYjNDM7IHdvdWxkIGhhdmUg
YmVjb21lIGEgbm9ybWF0aXZlIHJlZmVyZW5jZS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPkFsdGVybmF0aXZlbHksIGEgbW9yZSBzdGF0ZW1lbnQgbm90IHJlbGF0ZWQgdG8gdGhlIHN0
YXR1cyB3b3VsZCBiZQ0KPC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5h
IGNvbWJpbmF0aW9uIG9mIEFjY0VDTiB3aXRoIFJGQyA1NTYyIGlzIG91dHNpZGUgdGhlIHNjb3Bl
IG9mIHRoaXMgZG9jdW1lbnQ8L3NwYW4+4oCdPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi
Pi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Tb21lb25lIHdobyBoYWQgbmV2ZXIgZXZlbiB0aG91Z2h0IGFib3V0IGNvbWJpbmluZyBB
Y2NFQ04gd2l0aCBSRkM1NTYyIG1pZ2h0IHRoaW5rIHdlIG1lYW4gJnF1b3Q7QWNjRUNOIGNvdWxk
IGFsc28gYmUgY29tYmluZWQgd2l0aCBSRkM1NTYyLCBidXQgdGhpcyBpc24ndCB0aGUgcGxhY2Ug
dG8gdGFsayBhYm91dCBpdD8mcXVvdDsNCjxicj4NCjxicj4NCkhvdyBhYm91dDo8bzpwPjwvbzpw
PjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIEFjY0VD
TiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZ3NpZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsgJm5ic3A7dGhlIGV4cGVyaW1lbnRhbCBFQ04mIzQzOyYjNDM7IHByb3RvY29sIFs8
YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3Vy
YXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY24iIHRpdGxlPSImcXVv
dDtFQ04mIzQzOyYjNDM7OiBBZGRpbmcgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24g
KEVDTikgdG8gVENQIENvbnRyb2wgUGFja2V0cyZxdW90OyI+SS1ELmlldGYtdGNwbS1nZW5lcmFs
aXplZC1lY248L2E+XS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
VGhlcmVmb3JlLCB0aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZGlzY3VzcyBpbXBsZW1lbnRp
bmcgQWNjRUNOIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO2Fsb25n
c2lkZSB0aGUgZWFybGllciBleHBlcmltZW50YWwgYWx0ZXJuYXRpdmUgdG8gRUNOJiM0MzsmIzQz
OyBpbiBbUkZDNTU2Ml0uPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcvMDcvMTggMDg6
NTcsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij5JIHdvdWxkIHByZWZlciB0aGUgZmlyc3QsIHNob3J0ZXIgd29yZGluZy48
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZvciBpbnN0YW5jZSwg
aXQgd291bGQgYmUgcG9zc2libGUgdGhhdCBUQ1BNIGRlY2lkZXMgdG8gb2Jzb2xldGUgUkZDIDU1
NjIuIEk8L3NwYW4+4oCZPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmQgc3VnZ2VzdCB0
byBrZWVwIHRoZSBzdGF0dXMgYW5kIGZ1dHVyZSB1c2Ugb2YgUkZDIDU1NjIgaW4gY29tYmluYXRp
b24gd2l0aCBFQ04mIzQzOyYjNDM7IG91dHNpZGUNCiBvZiB0aGlzIGRvY3VtZW50Ljwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+V2hhdCBtaWdodCBiZSBpbiBzY29w
ZSBvZiB0aGUgQWNjRUNOIHNwZWMgd291bGQgYmUgYSBoeXBvdGhldGljYWwgdXNlIG9mIEFjY0VD
TiBpbiBjb21iaW5hdGlvbiB3aXRoIFJGQyA1NTYyLiBCdXQgSSB3b3VsZCBiZSBmaW5lIHdpdGgg
anVzdCBvbWl0dGluZyB0aGF0LiBBbHRlcm5hdGl2ZWx5LCBhIG1vcmUgc3RhdGVtZW50IG5vdCBy
ZWxhdGVkIHRvIHRoZQ0KIHN0YXR1cyB3b3VsZCBiZSA8L3NwYW4+4oCcPHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQiPmEgY29tYmluYXRpb24gb2YgQWNjRUNOIHdpdGggUkZDIDU1NjIgaXMg
b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudDwvc3Bhbj7igJ08c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93
dGV4dCI+QWN0dWFsbHksIEkgYW0gYWxzbyBub3Qgc3VyZSBpZiB0aGlzIHBhcmFncmFwaCBpcyBh
IGdvb2QgZXhhbXBsZSBmb3IgUkVDT01NRU5ERUQgaW4gYSBjYXBpdGFsIGxldHRlcnMuIFRvIG1l
LCB0aGUgZm9sbG93aW5nIHdvdWxkIGJlIHN1ZmZpY2llbnQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlY29t
bWVuZGVkIHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRo
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNwO3RoZSBleHBlcmltZW50YWwgRUNO
JiM0MzsmIzQzOyBwcm90b2NvbCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJh
bGl6ZWQtZWNuIiB0aXRsZT0iJnF1b3Q7RUNOJiM0MzsmIzQzOzogQWRkaW5nIEV4cGxpY2l0IENv
bmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIHRvIFRDUCBDb250cm9sIFBhY2tldHMmcXVvdDsi
PkktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPC9hPl0uPG86cD48L286cD48L3ByZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0
Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx
RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxhIGhyZWY9Im1haWx0bzpp
ZXRmQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldDwvYT5dDQo8YnI+
DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAxOCAyOjQzIFBNPGJyPg0KPGI+VG86
PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSA8YSBocmVmPSJtYWls
dG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tIj4NCiZsdDttaWNoYWVsLnNjaGFyZkBub2tpYS5j
b20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY25A
aWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZzwvYT47IDxh
IGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxiPlN1
YmplY3Q6PC9iPiBSZTogW3RjcG1dIEZ1cnRoZXIgY29tbWVudHMgb24gZHJhZnQtaWV0Zi10Y3Bt
LWFjY3VyYXRlLWVjbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8YnI+DQo8YnI+DQpJJ3Zl
IHdyaXR0ZW4gdGhlIHByb3Bvc2VkIGVkaXRzIGludG8gYSBsb2NhbCBjb3B5IG9mIGRyYWZ0LTA4
LCB3aGljaCB3ZSdsbCBwb3N0IGFmdGVyIHRoaXMgSUVURi48YnI+DQo8YnI+DQpXaWxlIHdyaXRp
bmcgdGhlIGxhc3QgcG9pbnQsIEkgdGhvdWdodCBpdCBiZXN0IHRvIGFkZCBhbiBleHRyYSBzZW50
ZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlzIFJFQ09NTUVOREVE
IHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNwO3RoZSBleHBlcmltZW50YWwgRUNOJiM0Mzsm
IzQzOyBwcm90b2NvbCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQt
ZWNuIiB0aXRsZT0iJnF1b3Q7RUNOJiM0MzsmIzQzOzogQWRkaW5nIEV4cGxpY2l0IENvbmdlc3Rp
b24gTm90aWZpY2F0aW9uIChFQ04pIHRvIFRDUCBDb250cm9sIFBhY2tldHMmcXVvdDsiPkktRC5p
ZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPC9hPl0uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyZuYnNwO1tJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbl0gaXMgYSBwcm9w
b3NlZCBhbHRlcm5hdGl2ZSB0byBhbm90aGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7IGV4cGVyaW1lbnRhbCBzY2hlbWUgW1JGQzU1NjJdIHNvIHRoZXJlIGlzIG5vIG5lZWQg
dG8gaW1wbGVtZW50IFJGQzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA1NTYy
IGFsb25nIHdpdGggQWNjRUNOLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIDE3LzA3LzE4IDAxOjA1LCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1
dHRnYXJ0KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+VGhpcyB3b3VsZCBmb3IgZm9yIG1l
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+VGhhbmtzPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5NaWNoYWVsPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2Nv
ZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPm1haWx0bzppZXRmQGJvYmJy
aXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4
IDE6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0
dGdhcnQpIDxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iPg0KJmx0O21p
Y2hhZWwuc2NoYXJmQG5va2lhLmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0
Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt
ZWNuQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0
Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50
cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNo
YWVsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE1LzA3
LzE4IDE2OjU0LCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhpIGFsbCw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XaGlsZSByZWFkaW5nIGRyYWZ0LWll
dGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcsIEkgbm90aWNlZCB0aGUgZm9sbG93aW5nOjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb24gMS4gSW50cm9kdWN0aW9uPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlz
IGxpa2VseSAoYnV0IG5vdCByZXF1aXJlZCkgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIHdpbGwg
YmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW1wbGVtZW50ZWQgYWxvbmcg
d2l0aCB0aGUgZm9sbG93aW5nIGV4cGVyaW1lbnRhbCBhZGRpdGlvbnMgdG8gdGhlPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRDUC1FQ04gcHJvdG9jb2w6IEVDTi1jYXBhYmxl
IFRDUCBjb250cm9sIHBhY2tldHMgYW5kIHJldHJhbnNtaXNzaW9uczxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyBbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY25dLCB3aGlj
aCBpbmNsdWRlcyB0aGUgRUNOLWNhcGFibGUgU1lOLzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBBQ0sgZXhwZXJpbWVudCBbUkZDNTU2Ml07IGFuZCB0ZXN0aW5nIHJlY2VpdmVy
IG5vbi1jb21wbGlhbmNlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFtJLUQu
bW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5bbXNdIEkgaGF2ZSBjb21tZW50ZWQgb24gdGhpcyBzZWN0
aW9uIGJlZm9yZS4gQW5kIEkgc3RpbGwgZGlzbGlrZSB0aGUgdGVybSAmcXVvdDtsaWtlbHkmcXVv
dDsuIFRvIG1lLCAmcXVvdDtsaWtlbHkmcXVvdDsgaXMgc3BlY3VsYXRpb24uIEEgbmV1dHJhbCBw
aHJhc2luZyB3b3VsZCBiZSAmcXVvdDsuLi4gaXQgaXMgcG9zc2libGUuLi4mcXVvdDsgb3IgJnF1
b3Q7Li4uIGl0IGlzIHVzZWZ1bC4uLiZxdW90Oy4gSGF2aW5nIHNhaWQgdGhpcywgSSBvYnNlcnZl
IHRoYXQgZHJhZnQtbW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0LTAzIHdhcyBsYXN0IHVwZGF0ZWQg
aW4gMjAxNC4gSG93ICZxdW90O2xpa2VseSZxdW90OyBpcyBpdCB0aGF0IHRoZSBBY2NFQ04gcHJv
dG9jb2wgd2lsbCBiZSBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIGEgbWVjaGFuaXNtIGRvY3VtZW50
ZWQgaW4gYW4gSUQgdGhhdCBoYXMgYmVlbiB3cml0dGVuIG1vcmUgdGhhbiAxMCB5ZWFycyBhZ28g
YW5kIG5vdCBiZWVuIHVwZGF0ZWQgZm9yIGFib3V0IDQgeWVhcnM/IEFyZSBpbXBsZW1lbnRlcnMg
aW5kZWVkIHNvIGludGVyZXN0ZWQgaW4gZHJhZnQtbW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0IHRo
YXQgYW4gaW1wbGVtZW50YXRpb24gaXMgJnF1b3Q7bGlrZWx5JnF1b3Q7PzxvOnA+PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIGFncmVlLiBG
b3IgRUNOJiM0MzsmIzQzOywgSSB0aGluayBzb21ldGhpbmcgbGlrZSB5b3VyIHN1Z2dlc3Rpb24g
b2YgJnF1b3Q7dXNlZnVsJnF1b3Q7LCBvciBldmVuIFJFQ09NTUVOREVEIGlzIHdoYXQgaXMgbmVl
ZGVkIGhlcmUuIEkgdGhpbmsgdGhlIHRlc3RpbmcgcmVjZWl2ZXIgY29tcGxpYW5jZSBvbmUgY291
bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBpbnRyby4gSXQncyBtZW50aW9uZWQgdW5kZXIgdGVzdGlu
ZyBmb3IgdW5leHBlY3RlZCBpbnRlcmZlcmVuY2UgYW5kIHVuZGVyDQogaW50ZWdyaXR5IGNoZWNr
aW5nLCB3aGljaCBhcmUgc3VmZmljaWVudC4gPGJyPg0KPGJyPg0KQWxzbywgdGhpcyBtYWtlcyBt
ZSBub3RpY2UgdGhhdCB0aGUgd29yZCAmcXVvdDtpbmNsdWRlcyZxdW90OyBpcyB3cm9uZy4gRUNO
JiM0MzsmIzQzOyBpbnRlbmRzIHRvIG9ic29sZXRlIFJGQzU1NjIsIGJ1dCBJIGRvbid0IHRoaW5r
IHdlIG5lZWQgdG8gbWVudGlvbiB0aGF0IGhlcmUgKGNvcyBpdCBtaWdodCBjaGFuZ2UgYmVmb3Jl
IEVDTiYjNDM7JiM0MzsgZ2V0cyBwdWJsaXNoZWQpLjxicj4NCjxicj4NCkNVUlJFTlQgVEVYVDo8
bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlzIGxpa2VseSAoYnV0IG5vdCBy
ZXF1aXJlZCkgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIHdpbGwgYmU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aCB0aGUgZm9sbG93aW5n
IGV4cGVyaW1lbnRhbCBhZGRpdGlvbnMgdG8gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IFRDUC1FQ04gcHJvdG9jb2w6IEVDTi1jYXBhYmxlIFRDUCBjb250cm9sIHBhY2tl
dHMgYW5kIHJldHJhbnNtaXNzaW9uczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1h
Y2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIiB0aXRsZT0i
JnF1b3Q7RUNOJiM0MzsmIzQzOzogQWRkaW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0
aW9uIChFQ04pIHRvIFRDUCBDb250cm9sIFBhY2tldHMmcXVvdDsiPkktRC5pZXRmLXRjcG0tZ2Vu
ZXJhbGl6ZWQtZWNuPC9hPl0sIHdoaWNoIGluY2x1ZGVzIHRoZSBFQ04tY2FwYWJsZSBTWU4vPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFDSyBleHBlcmltZW50IFs8YSBocmVm
PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU2MiIgdGl0bGU9IiZxdW90O0FkZGlu
ZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBDYXBhYmlsaXR5IHRvIFRD
UCdzIFNZTi9BQ0sgUGFja2V0cyZxdW90OyI+UkZDNTU2MjwvYT5dOyBhbmQgdGVzdGluZyByZWNl
aXZlciBub24tY29tcGxpYW5jZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBb
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1
cmF0ZS1lY24tMDcjcmVmLUktRC5tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQiIHRpdGxlPSImcXVv
dDtBIFRDUCBUZXN0IHRvIEFsbG93IFNlbmRlcnMgdG8gSWRlbnRpZnkgUmVjZWl2ZXIgTm9uLUNv
bXBsaWFuY2UmcXVvdDsiPkktRC5tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQ8L2E+XS48bzpwPjwv
bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFJPUE9TRUQgVEVYVDo8bzpwPjwvbzpw
PjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIEFjY0VD
TiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7ICZuYnNwO3RoZSBleHBlcmltZW50YWwgRUNOJiM0MzsmIzQzOyBwcm90b2NvbCBb
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1
cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIiB0aXRsZT0iJnF1
b3Q7RUNOJiM0MzsmIzQzOzogQWRkaW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9u
IChFQ04pIHRvIFRDUCBDb250cm9sIFBhY2tldHMmcXVvdDsiPkktRC5pZXRmLXRjcG0tZ2VuZXJh
bGl6ZWQtZWNuPC9hPl0uPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb24gMi4xLiZuYnNwOyBDYXBhYmlsaXR5IE5lZ290
aWF0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO1RoZSBUQ1Agc2VydmVyIHNlbmRzIHRoZSBBY2NF
Q048bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgT3B0aW9uIG9uIHRoZSBTWU4v
QUNLIGFuZCB0aGUgY2xpZW50IHNlbmRzIGl0IG9uIHRoZSBmaXJzdCBBQ0sgdG88bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGVzdCB3aGV0aGVyIHRoZSBuZXR3b3JrIHBhdGgg
Zm9yd2FyZHMgdGhlIG9wdGlvbiBjb3JyZWN0bHkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+W21zXSBBY2NvcmRpbmcgdG8gU2VjdGlvbiAzLjIu
Niwgb3B0aW9ucyBhcmUgUkVDT01NRU5ERUQuIFdoaWxlIFNlY3Rpb24gMiBpcyBub3Qgbm9ybWF0
aXZlLCB0aGUgd2hvbGUgU2VjdGlvbiAyIGRvZXMgbm90IHJlYWxseSBkZXNjcmliZSB3ZWxsIHRo
ZSBhY3R1YWwgcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyBvcHRpb25zLiBUaGlzIHBhcmFncmFwaCBp
biBTZWN0aW9uIDIuMSBpcyBvbmUgZXhhbXBsZSBmb3IgdGhhdC4gSXQgd291bGQgbWFrZSBzZW5z
ZSB0byBiZSBtb3JlIGV4cGxpY2l0IGluIFNlY3Rpb24gMiB0byB3aGljaCBleHRlbnQgb3B0aW9u
cyBoYXZlIHRvIGJlIHN1cHBvcnRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIHdlIG5lZWQgdG8gcmV2aWV3IHNlY3Rpb24gMiwgdG8g
ZW5zdXJlIGl0IGlzIGNvbnNpc3RlbnQgd2l0aCBjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVuIG1hZGUg
aW4gdGhlIG5vcm1hdGl2ZSBzZWN0aW9uIDMgc2luY2UgaXQgd2FzIHdyaXR0ZW4uPGJyPg0KPGJy
Pg0KSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHdlIGFscmVhZHkgcHJvbWlzZWQgdG8gY2hlY2sg
KG9mZmxpc3Qgd2l0aCBhbiBpbXBsZW1lbnRlcikgdGhhdCB0aGVyZSB3YXMgbm8gdGV4dCB0aGF0
IGNvbnRyYWRpY3RlZCB0aGUgb3B0aW9uYWxpdHkgb2YgdGhlIG9wdGlvbiBzdGF0ZWQgYXQgdGhl
IGVuZCBvZiBTZWN0aW9uIDMuMi42Ljxicj4NCjxicj4NCkkgaGF2ZSBhbHJlYWR5IHN0YXJ0ZWQg
dGhpcyB3aXRoIGEgbGlzdCBJIHByZXBhcmVkIChhbHNvIG9mZmxpc3QpIG9mIHdoaWNoIG1pZGRs
ZWJveCBjaGVja2luZyBzZWN0aW9ucyBhbiBpbXBsZW1lbnRlciBjb3VsZCBpZ25vcmUgaWYgdGhl
eSB3ZXJlIG9ubHkgcmVhZGluZyBidXQgbm90IHNlbmRpbmcgdGhlIFRDUCBvcHRpb25zLjxicj4N
Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJl
Zj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48
L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29l
Lm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJp
c2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9i
YnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_VI1PR07MB088008BBCA30D8391D31E302935C0VI1PR07MB0880eurp_--


From nobody Wed Jul 18 03:14:43 2018
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 3A6C8131132; Wed, 18 Jul 2018 03:14:40 -0700 (PDT)
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_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 hbvxd4BzkZwL; Wed, 18 Jul 2018 03:14:35 -0700 (PDT)
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 3766F130F37; Wed, 18 Jul 2018 03:14:34 -0700 (PDT)
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:To:Subject: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=7lCxbr/OT+6WJC4YgIJLt/Fc+fBQrdIcfstbQ+JEkjU=; b=ZXajp1VF15SDCgMMtSRs8qS7K C0A7hGFHIC/AlayYiLK0B0Idldy2Q6RlAXY0B2teUCfCfwI2q+/+OiJc55AXJkdws83RShgkiH69j cuwBYlmAIWs23LLX3I9TJWlBzu3RMRhUUnSPkls+KJfhRDcccaONI38q/5KiS23CJY3P6H33KAhGC wmJpArSqz9erlyj0Md7VNEToLZ3kRLxwnME1nl0mYfecROmT15v5Un3OAvs388fXtaM6CcGeC5U4L 9ivM+S0UYNW5EZAUmOGEvAsTN95F6ulHTAWF4eKXAlZAv7cHOPSlZGolzOpZ7FRn51/mlk6oy5RB4 WRP2FYj7Q==;
Received: from mtrlpq426kw-lp140-01-65-94-232-118.dsl.bell.ca ([65.94.232.118]:59948 helo=[192.168.2.57]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffjTb-00068V-4p; Wed, 18 Jul 2018 11:14:31 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>     
From: Bob Briscoe 
Message-ID: 
Date: Wed, 18 Jul 2018 06:14:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B477C5D3CA80A8455F168BA7"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 18 Jul 2018 10:14:41 -0000

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

Michael,

That regains the problem I said I was trying remove, of risking implying 
"AccECN could also be combined with RFC5562, but this isn't the place to 
talk about it?", by not explaining that ECN++ subsumes the function of 
RFC5562. How about:

    It is recommended that the AccECN protocol is implemented alongside

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
].
    This specification does not discuss implementing AccECN alongside
    [RFC5562], which was an earlier experimental protocol with narrower
    scope than ECN++.




Bob

On 17/07/18 17:01, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> This wording would imply that ECN++ and RFC 5562 are indeed 
> “alternatives”. That is IMHO not fully correct, ECN++ seems to have a 
> broader scope.
>
> I think something along the lines of …
>
>     It is recommended that the AccECN protocol is implemented alongside
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>     This specification does not discuss implementing AccECN
>     alongside the experimental protocol [RFC5562].
>
> …does the job.
>
> Michael
>
> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
> *Sent:* Tuesday, July 17, 2018 10:28 PM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
> ; draft-ietf-tcpm-accurate-ecn@ietf.org; 
> tcpm@ietf.org
> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Michael,
>
> OK RECOMMENDED -> recommended.
> That's good, otherwise I think ECN++ would have become a normative 
> reference.
>
>
>     Alternatively, a more statement not related to the status would be
>     “a combination of AccECN with RFC 5562 is outside the scope of
>     this document”.
>
> Someone who had never even thought about combining AccECN with RFC5562 
> might think we mean "AccECN could also be combined with RFC5562, but 
> this isn't the place to talk about it?"
>
> How about:
>
>     It is recommended that the AccECN protocol is implemented alongside
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>     Therefore, this specification does not discuss implementing AccECN
>     alongside the earlier experimental alternative to ECN++ in [RFC5562].
>
>
>
>
>
> Bob
>
> On 17/07/18 08:57, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>     I would prefer the first, shorter wording.
>
>     For instance, it would be possible that TCPM decides to obsolete
>     RFC 5562. I’d suggest to keep the status and future use of RFC
>     5562 in combination with ECN++ outside of this document.
>
>     What might be in scope of the AccECN spec would be a hypothetical
>     use of AccECN in combination with RFC 5562. But I would be fine
>     with just omitting that. Alternatively, a more statement not
>     related to the status would be “a combination of AccECN with RFC
>     5562 is outside the scope of this document”.
>
>     Actually, I am also not sure if this paragraph is a good example
>     for RECOMMENDED in a capital letters. To me, the following would
>     be sufficient:
>
>         It is recommended that the AccECN protocol is implemented along with
>
>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>     ].
>
>     Michael
>
>     *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>     *Sent:* Tuesday, July 17, 2018 2:43 PM
>     *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>      ;
>     draft-ietf-tcpm-accurate-ecn@ietf.org
>     ; tcpm@ietf.org
>     
>     *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
>     Michael,
>
>     I've written the proposed edits into a local copy of draft-08,
>     which we'll post after this IETF.
>
>     Wile writing the last point, I thought it best to add an extra
>     sentence.
>
>         It is RECOMMENDED that the AccECN protocol is implemented along with
>
>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>     ].
>
>         [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
>
>         experimental scheme [RFC5562] so there is no need to implement RFC
>
>         5562 along with AccECN.
>
>       
>
>
>
>     Bob
>
>     On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>         This would for for me.
>
>         Thanks
>
>         Michael
>
>         *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>         *Sent:* Tuesday, July 17, 2018 1:34 AM
>         *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>          ;
>         draft-ietf-tcpm-accurate-ecn@ietf.org
>         ; tcpm@ietf.org
>         
>         *Subject:* Re: [tcpm] Further comments on
>         draft-ietf-tcpm-accurate-ecn
>
>         Michael,
>
>         On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>             Hi all,
>
>               
>
>             While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>
>               
>
>               
>
>             Section 1. Introduction
>
>               
>
>                 It is likely (but not required) that the AccECN protocol will be
>
>                 implemented along with the following experimental additions to the
>
>                 TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>                 [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
>
>                 ACK experiment [RFC5562]; and testing receiver non-compliance
>
>                 [I-D.moncaster-tcpm-rcv-cheat].
>
>               
>
>             [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?
>
>
>         I agree. For ECN++, I think something like your suggestion of
>         "useful", or even RECOMMENDED is what is needed here. I think
>         the testing receiver compliance one could be removed from the
>         intro. It's mentioned under testing for unexpected
>         interference and under integrity checking, which are sufficient.
>
>         Also, this makes me notice that the word "includes" is wrong.
>         ECN++ intends to obsolete RFC5562, but I don't think we need
>         to mention that here (cos it might change before ECN++ gets
>         published).
>
>         CURRENT TEXT:
>
>             It is likely (but not required) that the AccECN protocol will be
>
>             implemented along with the following experimental additions to the
>
>             TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>             [I-D.ietf-tcpm-generalized-ecn
>         ], which includes the ECN-capable SYN/
>
>             ACK experiment [RFC5562 ]; and testing receiver non-compliance
>
>             [I-D.moncaster-tcpm-rcv-cheat
>         ].
>
>         PROPOSED TEXT:
>
>             It is RECOMMENDED that the AccECN protocol is implemented along with
>
>             the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>         ].
>
>
>
>
>
>               
>
>               
>
>               
>
>             Section 2.1.  Capability Negotiation
>
>                 
>
>                 The TCP server sends the AccECN
>
>                 Option on the SYN/ACK and the client sends it on the first ACK to
>
>                 test whether the network path forwards the option correctly.
>
>               
>
>             [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
>
>         OK, we need to review section 2, to ensure it is consistent
>         with changes that have been made in the normative section 3
>         since it was written.
>
>         In this particular case, we already promised to check (offlist
>         with an implementer) that there was no text that contradicted
>         the optionality of the option stated at the end of Section 3.2.6.
>
>         I have already started this with a list I prepared (also
>         offlist) of which middlebox checking sections an implementer
>         could ignore if they were only reading but not sending the TCP
>         options.
>
>
>
>
>         Bob
>
>
>
>
>
>         -- 
>
>         ________________________________________________________________
>
>         Bob Briscoehttp://bobbriscoe.net/
>
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoehttp://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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


--------------B477C5D3CA80A8455F168BA7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    That regains the problem I said I was trying remove, of risking
    implying "AccECN could also be combined with RFC5562, but this isn't
    the place to talk about it?", by not explaining that ECN++ subsumes
    the function of RFC5562. How about:

    

    
   It is recommended that the AccECN protocol is implemented alongside

    
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 
   This specification does not discuss implementing AccECN alongside
   [RFC5562], which was an earlier experimental protocol with narrower
   scope than ECN++.


    

    

    

    Bob

    

    
On 17/07/18 17:01, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      
      
      
      

        
This wording
            would imply that ECN++ and RFC 5562 are indeed
          “alternatives”. That is IMHO not fully correct,
            ECN++ seems to have a broader scope.

        
 

        
I think
            something along the lines of
          …

        
 

        
   It is recommended that the AccECN protocol is implemented alongside

        
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

        
   This specification does not discuss implementing AccECN 

        
   alongside the experimental protocol [RFC5562].

        
 

        
… does the job.

        
 

        
Michael

        
 

        
 

        
 

        

          

            

              
From: Bob Briscoe
                  [mailto:ietf@bobbriscoe.net]
                  

                  Sent: Tuesday, July 17, 2018 10:28 PM

                  To: Scharf, Michael (Nokia - DE/Stuttgart)
                  <michael.scharf@nokia.com>;
                  draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                  Subject: Re: [tcpm] Further comments on
                  draft-ietf-tcpm-accurate-ecn

            

          

          
 

          
Michael,

            

            OK RECOMMENDED -> recommended.

            That's good, otherwise I think ECN++ would have become a
            normative reference.

            

            

            

          

            
Alternatively,
                a more statement not related to the status would be
              “a combination of
                AccECN with RFC 5562 is outside the scope of this
                document”.

          

          
Someone who had never even thought about
            combining AccECN with RFC5562 might think we mean "AccECN
            could also be combined with RFC5562, but this isn't the
            place to talk about it?"
            

            

            How about:

          
   It is recommended that the AccECN protocol is implemented alongside

          
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

          
   Therefore, this specification does not discuss implementing AccECN 

          
   alongside the earlier experimental alternative to ECN++ in [RFC5562].

          


            

            

            

            Bob

          

            
On 17/07/18 08:57, Scharf, Michael
              (Nokia - DE/Stuttgart) wrote:

          

          

            
I would
                prefer the first, shorter wording.

            
 

            
For
                instance, it would be possible that TCPM decides to
                obsolete RFC 5562. I’d suggest to keep the status
                and future use of RFC 5562 in combination with ECN++
                outside of this document.

            
 

            
What
                might be in scope of the AccECN spec would be a
                hypothetical use of AccECN in combination with RFC 5562.
                But I would be fine with just omitting that.
                Alternatively, a more statement not related to the
                status would be “a
                combination of AccECN with RFC 5562 is outside the scope
                of this document”.

            
 

            
Actually,
                I am also not sure if this paragraph is a good example
                for RECOMMENDED in a capital letters. To me, the
                following would be sufficient:

            
 

            
   It is recommended that the AccECN protocol is implemented along with

            
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

            
 

            
Michael

            
 

            

              

                

                  
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                      

                      Sent: Tuesday, July 17, 2018 2:43 PM

                      To: Scharf, Michael (Nokia - DE/Stuttgart)
                      
                        <michael.scharf@nokia.com>; 
                        draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                      Subject: Re: [tcpm] Further comments on
                      draft-ietf-tcpm-accurate-ecn

                

              

              
 

              
Michael,

                

                I've written the proposed edits into a local copy of
                draft-08, which we'll post after this IETF.

                

                Wile writing the last point, I thought it best to add an
                extra sentence.

              
   It is RECOMMENDED that the AccECN protocol is implemented along with

              
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

              
   [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another

              
   experimental scheme [RFC5562] so there is no need to implement RFC

              
   5562 along with AccECN.

              
 

              


                

                Bob

              

                
On 17/07/18 01:05, Scharf, Michael
                  (Nokia - DE/Stuttgart) wrote:

              

              

                
This
                    would for for me.

                
 

                
Thanks

                
 

                
Michael

                
 

                

                  

                    

                      
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                          

                          Sent: Tuesday, July 17, 2018 1:34 AM

                          To: Scharf, Michael (Nokia -
                          DE/Stuttgart) 
                            <michael.scharf@nokia.com>; 
                            draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                          Subject: Re: [tcpm] Further comments on
                          draft-ietf-tcpm-accurate-ecn

                    

                  

                  
 

                  
Michael,

                  

                    
On 15/07/18 16:54, Scharf,
                      Michael (Nokia - DE/Stuttgart) wrote:

                  

                  

                    
Hi all,

                    
 

                    
While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:

                    
 

                    
 

                    
Section 1. Introduction

                    
 

                    
   It is likely (but not required) that the AccECN protocol will be

                    
   implemented along with the following experimental additions to the

                    
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                    
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                    
   ACK experiment [RFC5562]; and testing receiver non-compliance

                    
   [I-D.moncaster-tcpm-rcv-cheat].

                    
 

                    
[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

                  

                  


                    I agree. For ECN++, I think something like your
                    suggestion of "useful", or even RECOMMENDED is what
                    is needed here. I think the testing receiver
                    compliance one could be removed from the intro. It's
                    mentioned under testing for unexpected interference
                    and under integrity checking, which are sufficient.
                    

                    

                    Also, this makes me notice that the word "includes"
                    is wrong. ECN++ intends to obsolete RFC5562, but I
                    don't think we need to mention that here (cos it
                    might change before ECN++ gets published).

                    

                    CURRENT TEXT:

                  
   It is likely (but not required) that the AccECN protocol will be

                  
   implemented along with the following experimental additions to the

                  
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                  
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                  
   ACK experiment [RFC5562]; and testing receiver non-compliance

                  
   [I-D.moncaster-tcpm-rcv-cheat].

                  
PROPOSED TEXT:

                  
   It is RECOMMENDED that the AccECN protocol is implemented along with

                  
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

                  


                    

                    

                    

                    

                  

                    
 

                    
 

                    
 

                    
Section 2.1.  Capability Negotiation

                    
   

                    
   The TCP server sends the AccECN

                    
   Option on the SYN/ACK and the client sends it on the first ACK to

                    
   test whether the network path forwards the option correctly.

                    
 

                    
[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.

                  

                  
OK, we need to review section 2,
                    to ensure it is consistent with changes that have
                    been made in the normative section 3 since it was
                    written.

                    

                    In this particular case, we already promised to
                    check (offlist with an implementer) that there was
                    no text that contradicted the optionality of the
                    option stated at the end of Section 3.2.6.

                    

                    I have already started this with a list I prepared
                    (also offlist) of which middlebox checking sections
                    an implementer could ignore if they were only
                    reading but not sending the TCP options.

                    

                    

                    

                    

                    Bob

                    

                    

                    

                    

                    

                    

                  
-- 

                  
________________________________________________________________

                  
Bob Briscoe                               http://bobbriscoe.net/

                

              

              


                

                

                

              
-- 

              
________________________________________________________________

              
Bob Briscoe                               http://bobbriscoe.net/

            

          

          


            

            

          
-- 

          
________________________________________________________________

          
Bob Briscoe                               http://bobbriscoe.net/

        

      

    

    

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

  


--------------B477C5D3CA80A8455F168BA7--


From nobody Wed Jul 18 03:18:05 2018
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 7C4C813112E; Wed, 18 Jul 2018 03:18:03 -0700 (PDT)
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_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 FZ32QM3d09GK; Wed, 18 Jul 2018 03:18:00 -0700 (PDT)
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 334C8130E2F; Wed, 18 Jul 2018 03:17:59 -0700 (PDT)
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:From:Subject: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=3Rs4Gz5gQYjZGv9bU641XxnHjJaaQ5/wGSkF7kiJOAc=; b=1qu4HOQ0HvDwPFtcMp30cS4jP umv33Q9hrFwGWv9JIvSfneRdXs2VLwKl9fbfAE+l7XaOHHEH+mnajFUkGckIjmfF3eL/k/ugWss3G IC4Yjy4GMWz+Xx5OJ6LuiQh7mEcXH5UAfFeKBVl0I6syBb9rb/LGxJA/8NaI9uav5JQGBE2lJUFST SQyXyyDBsj4Nsp9t0R4c4mEpQ2AHlgVsqdqcDiCs6AQl7pepNGmlLNnqjte7Ky8NziuC8vQVSuj+B ED8YM77uIS2pipfXIbYm16rsH7YyRzY2AfmGk+DpsaIFqD/IGQAQdOt9Sfcjo9iUBh+kAc63UWeRR 9eCgacqYA==;
Received: from mtrlpq426kw-lp140-01-65-94-232-118.dsl.bell.ca ([65.94.232.118]:59964 helo=[192.168.2.57]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffjWv-0006OY-H2; Wed, 18 Jul 2018 11:17:57 +0100
From: Bob Briscoe 
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>      
Message-ID: <2faf9b21-28ba-283c-3bea-8fd3941ccb40@bobbriscoe.net>
Date: Wed, 18 Jul 2018 06:17:56 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FC479EFC4512E0C5D180AC2D"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 18 Jul 2018 10:18:04 -0000

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

Michael,

Sorry, I meant to add back in 'Therefore':

    It is recommended that the AccECN protocol is implemented alongside

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
].
    Therefore, this specification does not discuss implementing AccECN alongside
    [RFC5562], which was an earlier experimental protocol with narrower
    scope than ECN++.



Bob

On 18/07/18 06:14, Bob Briscoe wrote:
> Michael,
>
> That regains the problem I said I was trying remove, of risking 
> implying "AccECN could also be combined with RFC5562, but this isn't 
> the place to talk about it?", by not explaining that ECN++ subsumes 
> the function of RFC5562. How about:
>
>     It is recommended that the AccECN protocol is implemented alongside
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>     This specification does not discuss implementing AccECN alongside
>     [RFC5562], which was an earlier experimental protocol with narrower
>     scope than ECN++.
>
>
>
> Bob
>
> On 17/07/18 17:01, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>
>> This wording would imply that ECN++ and RFC 5562 are indeed 
>> “alternatives”. That is IMHO not fully correct, ECN++ seems to have a 
>> broader scope.
>>
>> I think something along the lines of …
>>
>>     It is recommended that the AccECN protocol is implemented alongside
>>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
>> ].
>>     This specification does not discuss implementing AccECN
>>     alongside the experimental protocol [RFC5562].
>>
>> …does the job.
>>
>> Michael
>>
>> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>> *Sent:* Tuesday, July 17, 2018 10:28 PM
>> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
>> ; draft-ietf-tcpm-accurate-ecn@ietf.org; 
>> tcpm@ietf.org
>> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>>
>> Michael,
>>
>> OK RECOMMENDED -> recommended.
>> That's good, otherwise I think ECN++ would have become a normative 
>> reference.
>>
>>
>>     Alternatively, a more statement not related to the status would
>>     be “a combination of AccECN with RFC 5562 is outside the scope of
>>     this document”.
>>
>> Someone who had never even thought about combining AccECN with 
>> RFC5562 might think we mean "AccECN could also be combined with 
>> RFC5562, but this isn't the place to talk about it?"
>>
>> How about:
>>
>>     It is recommended that the AccECN protocol is implemented alongside
>>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
>> ].
>>     Therefore, this specification does not discuss implementing AccECN
>>     alongside the earlier experimental alternative to ECN++ in [RFC5562].
>>
>>
>>
>>
>>
>> Bob
>>
>> On 17/07/18 08:57, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>
>>     I would prefer the first, shorter wording.
>>
>>     For instance, it would be possible that TCPM decides to obsolete
>>     RFC 5562. I’d suggest to keep the status and future use of RFC
>>     5562 in combination with ECN++ outside of this document.
>>
>>     What might be in scope of the AccECN spec would be a hypothetical
>>     use of AccECN in combination with RFC 5562. But I would be fine
>>     with just omitting that. Alternatively, a more statement not
>>     related to the status would be “a combination of AccECN with RFC
>>     5562 is outside the scope of this document”.
>>
>>     Actually, I am also not sure if this paragraph is a good example
>>     for RECOMMENDED in a capital letters. To me, the following would
>>     be sufficient:
>>
>>         It is recommended that the AccECN protocol is implemented along with
>>
>>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>>     ].
>>
>>     Michael
>>
>>     *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>>     *Sent:* Tuesday, July 17, 2018 2:43 PM
>>     *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>>      ;
>>     draft-ietf-tcpm-accurate-ecn@ietf.org
>>     ; tcpm@ietf.org
>>     
>>     *Subject:* Re: [tcpm] Further comments on
>>     draft-ietf-tcpm-accurate-ecn
>>
>>     Michael,
>>
>>     I've written the proposed edits into a local copy of draft-08,
>>     which we'll post after this IETF.
>>
>>     Wile writing the last point, I thought it best to add an extra
>>     sentence.
>>
>>         It is RECOMMENDED that the AccECN protocol is implemented along with
>>
>>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>>     ].
>>
>>         [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
>>
>>         experimental scheme [RFC5562] so there is no need to implement RFC
>>
>>         5562 along with AccECN.
>>
>>       
>>
>>
>>
>>     Bob
>>
>>     On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>
>>         This would for for me.
>>
>>         Thanks
>>
>>         Michael
>>
>>         *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>>         *Sent:* Tuesday, July 17, 2018 1:34 AM
>>         *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>>          ;
>>         draft-ietf-tcpm-accurate-ecn@ietf.org
>>         ; tcpm@ietf.org
>>         
>>         *Subject:* Re: [tcpm] Further comments on
>>         draft-ietf-tcpm-accurate-ecn
>>
>>         Michael,
>>
>>         On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>
>>             Hi all,
>>
>>               
>>
>>             While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>>
>>               
>>
>>               
>>
>>             Section 1. Introduction
>>
>>               
>>
>>                 It is likely (but not required) that the AccECN protocol will be
>>
>>                 implemented along with the following experimental additions to the
>>
>>                 TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>>
>>                 [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
>>
>>                 ACK experiment [RFC5562]; and testing receiver non-compliance
>>
>>                 [I-D.moncaster-tcpm-rcv-cheat].
>>
>>               
>>
>>             [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?
>>
>>
>>         I agree. For ECN++, I think something like your suggestion of
>>         "useful", or even RECOMMENDED is what is needed here. I think
>>         the testing receiver compliance one could be removed from the
>>         intro. It's mentioned under testing for unexpected
>>         interference and under integrity checking, which are sufficient.
>>
>>         Also, this makes me notice that the word "includes" is wrong.
>>         ECN++ intends to obsolete RFC5562, but I don't think we need
>>         to mention that here (cos it might change before ECN++ gets
>>         published).
>>
>>         CURRENT TEXT:
>>
>>             It is likely (but not required) that the AccECN protocol will be
>>
>>             implemented along with the following experimental additions to the
>>
>>             TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>>
>>             [I-D.ietf-tcpm-generalized-ecn
>>         ], which includes the ECN-capable SYN/
>>
>>             ACK experiment [RFC5562 ]; and testing receiver non-compliance
>>
>>             [I-D.moncaster-tcpm-rcv-cheat
>>         ].
>>
>>         PROPOSED TEXT:
>>
>>             It is RECOMMENDED that the AccECN protocol is implemented along with
>>
>>             the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>>         ].
>>
>>
>>
>>
>>
>>               
>>
>>               
>>
>>               
>>
>>             Section 2.1.  Capability Negotiation
>>
>>                 
>>
>>                 The TCP server sends the AccECN
>>
>>                 Option on the SYN/ACK and the client sends it on the first ACK to
>>
>>                 test whether the network path forwards the option correctly.
>>
>>               
>>
>>             [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
>>
>>         OK, we need to review section 2, to ensure it is consistent
>>         with changes that have been made in the normative section 3
>>         since it was written.
>>
>>         In this particular case, we already promised to check
>>         (offlist with an implementer) that there was no text that
>>         contradicted the optionality of the option stated at the end
>>         of Section 3.2.6.
>>
>>         I have already started this with a list I prepared (also
>>         offlist) of which middlebox checking sections an implementer
>>         could ignore if they were only reading but not sending the
>>         TCP options.
>>
>>
>>
>>
>>         Bob
>>
>>
>>
>>
>>
>>         -- 
>>
>>         ________________________________________________________________
>>
>>         Bob Briscoehttp://bobbriscoe.net/
>>
>>
>>
>>
>>     -- 
>>
>>     ________________________________________________________________
>>
>>     Bob Briscoehttp://bobbriscoe.net/
>>
>>
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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


--------------FC479EFC4512E0C5D180AC2D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    Sorry, I meant to add back in 'Therefore':

    

    
   It is recommended that the AccECN protocol is implemented alongside

    
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 
   Therefore, this specification does not discuss implementing AccECN alongside
   [RFC5562], which was an earlier experimental protocol with narrower
   scope than ECN++.


    

    

    Bob

    

    
On 18/07/18 06:14, Bob Briscoe wrote:

    

    

      
      Michael,

      

      That regains the problem I said I was trying remove, of risking
      implying "AccECN could also be combined with RFC5562, but this
      isn't the place to talk about it?", by not explaining that ECN++
      subsumes the function of RFC5562. How about:

      

      
   It is recommended that the AccECN protocol is implemented alongside

      
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 
   This specification does not discuss implementing AccECN alongside
   [RFC5562], which was an earlier experimental protocol with narrower
   scope than ECN++.


      

      

      

      Bob

      

      
On 17/07/18 17:01, Scharf, Michael
        (Nokia - DE/Stuttgart) wrote:

      

      

        
        
        
        

          
This
              wording would imply that ECN++ and RFC 5562 are indeed “alternatives”. That is IMHO not fully correct,
              ECN++ seems to have a broader scope.

          
 

          
I think
              something along the lines of …

          
 

          
   It is recommended that the AccECN protocol is implemented alongside

          
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

          
   This specification does not discuss implementing AccECN 

          
   alongside the experimental protocol [RFC5562].

          
 

          
… does the job.

          
 

          
Michael

          
 

          
 

          
 

          

            

              

                
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                    

                    Sent: Tuesday, July 17, 2018 10:28 PM

                    To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>;
                    draft-ietf-tcpm-accurate-ecn@ietf.org;
                    tcpm@ietf.org

                    Subject: Re: [tcpm] Further comments on
                    draft-ietf-tcpm-accurate-ecn

              

            

            
 

            
Michael,

              

              OK RECOMMENDED -> recommended.

              That's good, otherwise I think ECN++ would have become a
              normative reference.

              

              

              

            

              
Alternatively,
                  a more statement not related to the status would be “a combination of AccECN with
                  RFC 5562 is outside the scope of this document”.

            

            
Someone who had never even thought
              about combining AccECN with RFC5562 might think we mean
              "AccECN could also be combined with RFC5562, but this
              isn't the place to talk about it?" 

              

              How about:

            
   It is recommended that the AccECN protocol is implemented alongside

            
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

            
   Therefore, this specification does not discuss implementing AccECN 

            
   alongside the earlier experimental alternative to ECN++ in [RFC5562].

            


              

              

              

              Bob

            

              
On 17/07/18 08:57, Scharf, Michael
                (Nokia - DE/Stuttgart) wrote:

            

            

              
I
                  would prefer the first, shorter wording.

              
 

              
For
                  instance, it would be possible that TCPM decides to
                  obsolete RFC 5562. I’d suggest to keep the status
                  and future use of RFC 5562 in combination with ECN++
                  outside of this document.

              
 

              
What
                  might be in scope of the AccECN spec would be a
                  hypothetical use of AccECN in combination with RFC
                  5562. But I would be fine with just omitting that.
                  Alternatively, a more statement not related to the
                  status would be “a combination of AccECN with
                  RFC 5562 is outside the scope of this document”.

              
 

              
Actually,
                  I am also not sure if this paragraph is a good example
                  for RECOMMENDED in a capital letters. To me, the
                  following would be sufficient:

              
 

              
   It is recommended that the AccECN protocol is implemented along with

              
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

              
 

              
Michael

              
 

              

                

                  

                    
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                        

                        Sent: Tuesday, July 17, 2018 2:43 PM

                        To: Scharf, Michael (Nokia -
                        DE/Stuttgart) 
                          <michael.scharf@nokia.com>; 
                          draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                        Subject: Re: [tcpm] Further comments on
                        draft-ietf-tcpm-accurate-ecn

                  

                

                
 

                
Michael,

                  

                  I've written the proposed edits into a local copy of
                  draft-08, which we'll post after this IETF.

                  

                  Wile writing the last point, I thought it best to add
                  an extra sentence.

                
   It is RECOMMENDED that the AccECN protocol is implemented along with

                
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

                
   [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another

                
   experimental scheme [RFC5562] so there is no need to implement RFC

                
   5562 along with AccECN.

                
 

                


                  

                  Bob

                

                  
On 17/07/18 01:05, Scharf,
                    Michael (Nokia - DE/Stuttgart) wrote:

                

                

                  
This
                      would for for me.

                  
 

                  
Thanks

                  
 

                  
Michael

                  
 

                  

                    

                      

                        
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                            

                            Sent: Tuesday, July 17, 2018 1:34 AM

                            To: Scharf, Michael (Nokia -
                            DE/Stuttgart) 
                              <michael.scharf@nokia.com>; 
                              draft-ietf-tcpm-accurate-ecn@ietf.org;
                            tcpm@ietf.org

                            Subject: Re: [tcpm] Further comments
                            on draft-ietf-tcpm-accurate-ecn

                      

                    

                    
 

                    
Michael,

                    

                      
On 15/07/18 16:54, Scharf,
                        Michael (Nokia - DE/Stuttgart) wrote:

                    

                    

                      
Hi all,

                      
 

                      
While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:

                      
 

                      
 

                      
Section 1. Introduction

                      
 

                      
   It is likely (but not required) that the AccECN protocol will be

                      
   implemented along with the following experimental additions to the

                      
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                      
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                      
   ACK experiment [RFC5562]; and testing receiver non-compliance

                      
   [I-D.moncaster-tcpm-rcv-cheat].

                      
 

                      
[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

                    

                    


                      I agree. For ECN++, I think something like your
                      suggestion of "useful", or even RECOMMENDED is
                      what is needed here. I think the testing receiver
                      compliance one could be removed from the intro.
                      It's mentioned under testing for unexpected
                      interference and under integrity checking, which
                      are sufficient. 

                      

                      Also, this makes me notice that the word
                      "includes" is wrong. ECN++ intends to obsolete
                      RFC5562, but I don't think we need to mention that
                      here (cos it might change before ECN++ gets
                      published).

                      

                      CURRENT TEXT:

                    
   It is likely (but not required) that the AccECN protocol will be

                    
   implemented along with the following experimental additions to the

                    
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                    
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                    
   ACK experiment [RFC5562]; and testing receiver non-compliance

                    
   [I-D.moncaster-tcpm-rcv-cheat].

                    
PROPOSED TEXT:

                    
   It is RECOMMENDED that the AccECN protocol is implemented along with

                    
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

                    


                      

                      

                      

                      

                    

                      
 

                      
 

                      
 

                      
Section 2.1.  Capability Negotiation

                      
   

                      
   The TCP server sends the AccECN

                      
   Option on the SYN/ACK and the client sends it on the first ACK to

                      
   test whether the network path forwards the option correctly.

                      
 

                      
[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.

                    

                    
OK, we need to review section
                      2, to ensure it is consistent with changes that
                      have been made in the normative section 3 since it
                      was written.

                      

                      In this particular case, we already promised to
                      check (offlist with an implementer) that there was
                      no text that contradicted the optionality of the
                      option stated at the end of Section 3.2.6.

                      

                      I have already started this with a list I prepared
                      (also offlist) of which middlebox checking
                      sections an implementer could ignore if they were
                      only reading but not sending the TCP options.

                      

                      

                      

                      

                      Bob

                      

                      

                      

                      

                      

                      

                    
-- 

                    
________________________________________________________________

                    
Bob Briscoe                               http://bobbriscoe.net/

                  

                

                


                  

                  

                  

                
-- 

                
________________________________________________________________

                
Bob Briscoe                               http://bobbriscoe.net/

              

            

            


              

              

            
-- 

            
________________________________________________________________

            
Bob Briscoe                               http://bobbriscoe.net/

          

        

      

      

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

    

    

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

  


--------------FC479EFC4512E0C5D180AC2D--


From nobody Wed Jul 18 04:41:08 2018
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 E6E37130E0F for ; Wed, 18 Jul 2018 04:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 jak0FMQl5jUX for ; Wed, 18 Jul 2018 04:41:03 -0700 (PDT)
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 B8DC7126CC7 for ; Wed, 18 Jul 2018 04:41:03 -0700 (PDT)
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:To:References: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=gpM1o7h08l8laWsSnDW/Ny7N0YQpicLjEF7h7wmsQ94=; b=MQGkACFBC3VS1iSuULlqoVlXs eJjQM2xiLuZvnpkKquxN0jM8hvbCu2nwkfEAJJqVvu5U/p0IsGD/iYEVS4c8Fnmki8zBQ8a7dCNP4 ILlFoQNeH07nK2GDCmYxlz+FHyM/O1wGDw75W7H2c/Ym99Vl68+w3ot+qDxqIy9rx3S4wTLG+oeJc KkQapkjwCCU2map70ux1WXW+LUI5oN4YPIVvdfdxU3aECpb3ug/HZc8n+pO6d53nHhshp6LQdOugK 4FZgjt+c0l7Z5ANk0ErzD4SMPRPaG/+pU3rBwMrufEuSXziCtPQM+cj8f3njDpVX0S+2e22+MB9tQ ZSULQMi6g==;
Received: from mtrlpq426kw-lp140-01-65-94-232-118.dsl.bell.ca ([65.94.232.118]:60422 helo=[192.168.2.57]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffkpI-0004dl-35; Wed, 18 Jul 2018 12:41:00 +0100
References: 
To: Michael Scharf 
Cc: tcpm IETF list , ANNA MARIA MANDALARI 
From: Bob Briscoe 
X-Forwarded-Message-Id: 
Message-ID: 
Date: Wed, 18 Jul 2018 07:40:59 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D2CFB69132F9CAC6CC78BBF7"
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: Re: Data on 'Nonce' and 'Broken' responses to AccECN SYN?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 18 Jul 2018 11:41:07 -0000

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

Michael,

Below is data from 410,803 of the Alexa top 500k web server that 
confirms what I said in the presentation about space for future 
evolution of AccECN:

  * the nonce pattern on the SYN-ACK could be reused now (0.0007%)
  * the broken reflection pattern is still far too prevalent to re-use
    it (0.35%).

If anyone wants the list of broken servers that Anna attached for me, 
pls ask.
The whole dataset is also available via: 
http://www.it.uc3m.es/amandala/ecn++/

@Anna, thanks v much for responding so quickly - it was me that hadn't 
read your email in time for the talk.



Bob

-------- Forwarded Message --------
Subject: 	Re: Data on 'Nonce' and 'Broken' responses to AccECN SYN?
Date: 	Tue, 17 Jul 2018 15:42:10 +0200
From: 	ANNA MARIA MANDALARI 
To: 	Bob Briscoe 



Hi Bob,

I had a look at the data and I found *1,438 servers *over the top 
410,803 Alexa (0.35%) that reply SYN/ACK+111 to a SYN+111 (attached the 
list).

Only *3 servers *(0.0007%) reply SYN/ACK+101 to a SYN+111:

test_synack;200.12.171.53;80;ect;0;flags;338
test_synack;60.28.220.134;80;ect;0;flags;338
test_synack;200.12.171.52;80;ect;0;flags;338

Let me know if I can help you with something else!






2018-07-17 13:26 GMT+02:00 Bob Briscoe >:

    Anna,

    Could you do me a favour and look up how many servers responded to
    an AccECN (111) SYN with a SYN/ACK carrying respectively 'Nonce'
    (101) or 'Broken' (111)?

    And also the total number of tests sent with an AccECN SYN, so I can
    give proportions in the AccECN draft.

    Cheers



    Bob (too lazy to look at the data myself)

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




-- 
ANNA MARIA MANDALARI
Universidad Carlos III de Madrid

--------------D2CFB69132F9CAC6CC78BBF7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Michael,

    


      Below is data from 410,803 of the Alexa top 500k web server that
      confirms what I said in the presentation about space for future
      evolution of AccECN:

      
    
        
  • the nonce pattern on the SYN-ACK could be reused now
          (0.0007%)
    • 
        
  • the broken reflection pattern is still far too prevalent to
          re-use it (0.35%).
    • 
      

      If anyone wants the list of broken servers that Anna attached for
      me, pls ask.

      The whole dataset is also available via:
      http://www.it.uc3m.es/amandala/ecn++/

      

      @Anna, thanks v much for responding so quickly - it was me that
      hadn't read your email in time for the talk.

      

      

      

      Bob

      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            Re: Data on 'Nonce' and 'Broken' responses to AccECN
              SYN?
          

          

            Date: 
            Tue, 17 Jul 2018 15:42:10 +0200
          

          

            From: 
            ANNA MARIA MANDALARI <amandala@it.uc3m.es>
          

          

            To: 
            Bob Briscoe <research@bobbriscoe.net>
          

        
      

      

      

      

        
Hi Bob,

        


        

        
I had a look at the data and I found 1,438 servers over
          the top 410,803 Alexa (0.35%) that reply SYN/ACK+111 to a
          SYN+111 (attached the list).

        


        

        
Only 3 servers (0.0007%) reply SYN/ACK+101 to a
          SYN+111:

        


        

        
test_synack;200.12.171.53;80;ect;0;flags;338

          test_synack;60.28.220.134;80;ect;0;flags;338

          test_synack;200.12.171.52;80;ect;0;flags;338

        


        

        
Let me know if I can help you with something else!

        

        


        

        


        

        


        

        


        

        


        

      

      


        
2018-07-17 13:26 GMT+02:00 Bob Briscoe
          <research@bobbriscoe.net>:

          
Anna,

            

            Could you do me a favour and look up how many servers
            responded to an AccECN (111) SYN with a SYN/ACK carrying
            respectively 'Nonce' (101) or 'Broken' (111)?

            

            And also the total number of tests sent with an AccECN SYN,
            so I can give proportions in the AccECN draft.

            

            Cheers

            

            

            

            Bob (too lazy to look at the data myself)

                

                -- 

                ________________________________________________________________

                Bob Briscoe                               http://bobbriscoe.net/

                

              

        

        

        

        

        -- 

        
ANNA
          MARIA MANDALARI 

          Universidad Carlos III de Madrid

      

    

  


--------------D2CFB69132F9CAC6CC78BBF7--


From nobody Wed Jul 18 06:12:47 2018
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 1F69E1311F1; Wed, 18 Jul 2018 06:12:35 -0700 (PDT)
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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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=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 U-jdkVN0e66t; Wed, 18 Jul 2018 06:12:31 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70135.outbound.protection.outlook.com [40.107.7.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1451A1311FB; Wed, 18 Jul 2018 06:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a2EGFn2fpReXDtMsKnLfo0uyXNi44jNqUt/fi+8lFiM=; b=XFP8ZS1GXvSBEo1tu0Ded8N1KzI5DubZ6zF+4JE33DOpAgy6aSdBhrdUKfvFv1499H9ZB/RaYNnP5+I3suu4spUDNGy5hWi6xoG0P6wVerCDdNwAPrb/PGwyCunBaxfWEcX5Pgnb6Jzhj+clgJYm8ZoVgP45Ejz3iJJ624beJWg=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB3373.eurprd07.prod.outlook.com (10.175.244.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Wed, 18 Jul 2018 13:12:04 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.016; Wed, 18 Jul 2018 13:12:04 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgA5JfwAAAuIsyAAEAC+AAAADp/gABA0BIAAAApQUAAc0kiAAAAe2AAABcVwAA==
Date: Wed, 18 Jul 2018 13:12:04 +0000
Message-ID: 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>       <2faf9b21-28ba-283c-3bea-8fd3941ccb40@bobbriscoe.net>
In-Reply-To: <2faf9b21-28ba-283c-3bea-8fd3941ccb40@bobbriscoe.net>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-originating-ip: [135.245.212.158]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3373; 6:5bmjt3iznyiSDPNNTDt5jq0sHs9kisZkvAZCOR7Jd1HNbO3XTYHIa53jVarrCJr6LGiRKZdvbT5LkqjMnjfq7Axzgq9x1jKJYfAPgO6ihcGAZeWNeg1ax+kckWITQMz9nrbZU11Gd9QPU2cGHIgVHZZL04PBCBr3onh2XC5IBzREZe4mCZFSsfLKV3icxrFbaO9ASa3R8fVGXHdA23qLq2/WtJRa+rp6yyxVzLl7KJm/MRC2fqckWT0Egyha0PuiT7MdE9Nr76TC5BrKd1t91xFQdzBJwyo6xHyAJobJ5K9xB8CES/+JbDAnP5JNe7rvee90kIFwknwqzApAwQGieIcfWvAMPhgfrmURsBuc7rNkd0vvb4fMQ+9Wjxp5DaFcZv3hOC9qTKLrKAp1FsgoV0Z76o1oS4bElhVQeSX38ujMAjTBF8lKHWZDJrZY1uDyOJJEdDUrJuXWa1I9J5kvzQ==; 5:7d9m+FjCAxPo7u/gZy/2fW2AB49xwBbNi65HrN9btiEn+aWVeOyTCqWKZ4s4bd0bmJ0BCfCulxqyuCt2tI9FRQF1SLIJXei5xzyE6Dz8ZZV8S2ttGWRoBkw/Ll5BVOJqIluncu/9WnnHko0Vc0FAqigthtmw79O85dkwFtcvaGA=; 7:9GN1lRZlssqH/ZKXQhMC2TWXaTQ/4TJQh/CRupuOrZVIM5C9leOJa4unKvVIuIJumkZoR1zAOuNueXU7BoQqkyJvv8CbRooKhN2xzf86UQYDnC50szIFC5Hv9qdKLVVgzHujEnB2l/aELS5HO/f6e7ow/AAYpuALsUFt+rh0Ra0OxRsPC5TwtUMTyNzMcUJ1/E4vzix9L4GyGHRx84w4gOepy4RUYb7Geb/euShQhT3YT/RxIRMteRE6wo1vT8n2
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 95ddcda9-c449-469b-1260-08d5ecb00e6b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR07MB3373; 
x-ms-traffictypediagnostic: VI1PR07MB3373:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(82608151540597)(109105607167333)(195916259791689)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB3373; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3373; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(136003)(39860400002)(346002)(53754006)(189003)(199004)(93886005)(6116002)(3846002)(606006)(316002)(5250100002)(2501003)(2906002)(11346002)(256004)(790700001)(476003)(2900100001)(110136005)(6436002)(14444005)(446003)(99286004)(8936002)(66066001)(229853002)(86362001)(2201001)(486006)(53936002)(33656002)(7736002)(6246003)(6506007)(53546011)(26005)(81156014)(81166006)(236005)(53376002)(97736004)(68736007)(8676002)(76176011)(54896002)(6306002)(966005)(9686003)(55016002)(74316002)(5660300001)(25786009)(186003)(478600001)(7696005)(102836004)(106356001)(105586002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3373; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: kCMq6wagfT1+dathezd5010RAlQitdQGj3ZQ93mqHYyud+dox2RsOPZCuN2wasQr1LwWjO67gLILc69aoL0LostgU5wCgka/JWHUu6hGx8b/hTUsmx5t/BCrHLVOnpTMOfnLhaiu/4ItCefgRlMvgkICmD1eUPibKMYyEBIwXx4l+pmwJq+LEl+NJ2hS8KqoG9cGQtORksLLukrs2sQiigEnoUcv5dLZ+llrDPokv9KWYT+p+Dj++XmC+Hn6UQrs63NPFx+03e2t4Dlm3bBZhHrYDC9Y3RKwvyCDogYNdL/HQnyM6ucDSAz6OuhVUfHTrg1yHzNhSFjGuE+Dk/KYHxTZYjXAsSfmQ+oZhV54n9C0w2coM8Calat2IXGNXXI7e2gK33w6QzRCdv/hnFAG7Q==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB0880A773470BEAF2B86AE69393530VI1PR07MB0880eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95ddcda9-c449-469b-1260-08d5ecb00e6b
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2018 13:12:04.0748 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3373
Archived-At: 
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 18 Jul 2018 13:12:46 -0000

--_000_VI1PR07MB0880A773470BEAF2B86AE69393530VI1PR07MB0880eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGZvbGxvd2luZyB3b3JkaW5nIG1pZ2h0IHdvcmsgZm9yIG1lOg0KDQogICBJdCBpcyByZWNv
bW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmdzaWRl
DQoNCiAgIHRoZSBleHBlcmltZW50YWwgRUNOKysgcHJvdG9jb2wgW0ktRC5pZXRmLXRjcG0tZ2Vu
ZXJhbGl6ZWQtZWNuPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0t
YWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbj5dLg0KDQog
ICBUaGVyZWZvcmUsIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkaXNjdXNzIGltcGxlbWVu
dGluZyBBY2NFQ04gYWxvbmdzaWRlDQoNCiAgIFtSRkM1NTYyXSwgd2hpY2ggaXMgYW4gZWFybGll
ciBleHBlcmltZW50YWwgcHJvdG9jb2wuDQoNCkFzIGZhciBhcyBJIGtub3csIHRoZSBleHBlcmlt
ZW50IG9mIFJGQyA1NTYyIGhhcyBub3QgYmVlbiBvZmZpY2lhbGx5IGZpbmlzaGVkIHNvIGZhciwg
aS5lLiwgdXNlIG9mIHBhc3QgdGVuc2UgbWlnaHQgbm90IGJlIGFwcHJvcHJpYXRlLg0KDQooUGVy
c29uYWxseSwgSSBjb3VsZCBpbWFnaW5lIHRoYXQgVENQTSBkZWNpZGVzIHRvIGZpbmlzaCB0aGUg
ZXhwZXJpbWVudCBvZiBSRkMgNTU2MiwgYnV0IHRoYXQgcXVlc3Rpb24gZG9lcyBub3QgYmVsb25n
IGludG8gdGhpcyBJLUQuKQ0KDQpNaWNoYWVsDQoNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0
bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDE4IDEy
OjE4IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hh
ZWwuc2NoYXJmQG5va2lhLmNvbT47IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY25AaWV0Zi5v
cmc7IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50cyBv
biBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQoNCk1pY2hhZWwsDQoNClNvcnJ5LCBJIG1l
YW50IHRvIGFkZCBiYWNrIGluICdUaGVyZWZvcmUnOg0KDQogICBJdCBpcyByZWNvbW1lbmRlZCB0
aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmdzaWRlDQoNCiAgIHRo
ZSBleHBlcmltZW50YWwgRUNOKysgcHJvdG9jb2wgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQt
ZWNuPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt
ZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbj5dLg0KDQogICBUaGVyZWZv
cmUsIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkaXNjdXNzIGltcGxlbWVudGluZyBBY2NF
Q04gYWxvbmdzaWRlDQoNCiAgIFtSRkM1NTYyXSwgd2hpY2ggd2FzIGFuIGVhcmxpZXIgZXhwZXJp
bWVudGFsIHByb3RvY29sIHdpdGggbmFycm93ZXINCg0KICAgc2NvcGUgdGhhbiBFQ04rKy4NCg0K
DQpCb2INCk9uIDE4LzA3LzE4IDA2OjE0LCBCb2IgQnJpc2NvZSB3cm90ZToNCk1pY2hhZWwsDQoN
ClRoYXQgcmVnYWlucyB0aGUgcHJvYmxlbSBJIHNhaWQgSSB3YXMgdHJ5aW5nIHJlbW92ZSwgb2Yg
cmlza2luZyBpbXBseWluZyAiQWNjRUNOIGNvdWxkIGFsc28gYmUgY29tYmluZWQgd2l0aCBSRkM1
NTYyLCBidXQgdGhpcyBpc24ndCB0aGUgcGxhY2UgdG8gdGFsayBhYm91dCBpdD8iLCBieSBub3Qg
ZXhwbGFpbmluZyB0aGF0IEVDTisrIHN1YnN1bWVzIHRoZSBmdW5jdGlvbiBvZiBSRkM1NTYyLiBI
b3cgYWJvdXQ6DQoNCiAgIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIEFjY0VDTiBwcm90b2Nv
bCBpcyBpbXBsZW1lbnRlZCBhbG9uZ3NpZGUNCg0KICAgdGhlIGV4cGVyaW1lbnRhbCBFQ04rKyBw
cm90b2NvbCBbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRj
cG0tZ2VuZXJhbGl6ZWQtZWNuPl0uDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBk
aXNjdXNzIGltcGxlbWVudGluZyBBY2NFQ04gYWxvbmdzaWRlDQoNCiAgIFtSRkM1NTYyXSwgd2hp
Y2ggd2FzIGFuIGVhcmxpZXIgZXhwZXJpbWVudGFsIHByb3RvY29sIHdpdGggbmFycm93ZXINCg0K
ICAgc2NvcGUgdGhhbiBFQ04rKy4NCg0KDQoNCkJvYg0KT24gMTcvMDcvMTggMTc6MDEsIFNjaGFy
ZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOg0KVGhpcyB3b3JkaW5nIHdv
dWxkIGltcGx5IHRoYXQgRUNOKysgYW5kIFJGQyA1NTYyIGFyZSBpbmRlZWQg4oCcYWx0ZXJuYXRp
dmVz4oCdLiBUaGF0IGlzIElNSE8gbm90IGZ1bGx5IGNvcnJlY3QsIEVDTisrIHNlZW1zIHRvIGhh
dmUgYSBicm9hZGVyIHNjb3BlLg0KDQpJIHRoaW5rIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMg
b2Yg4oCmDQoNCg0KICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29s
IGlzIGltcGxlbWVudGVkIGFsb25nc2lkZQ0KDQogICB0aGUgZXhwZXJpbWVudGFsIEVDTisrIHBy
b3RvY29sIFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjxodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNw
bS1nZW5lcmFsaXplZC1lY24+XS4NCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGRp
c2N1c3MgaW1wbGVtZW50aW5nIEFjY0VDTg0KDQogICBhbG9uZ3NpZGUgdGhlIGV4cGVyaW1lbnRh
bCBwcm90b2NvbCBbUkZDNTU2Ml0uDQoNCuKApiBkb2VzIHRoZSBqb2IuDQoNCk1pY2hhZWwNCg0K
DQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6
IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTggMTA6MjggUE0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5v
a2lhIC0gREUvU3R1dHRnYXJ0KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPjxtYWlsdG86bWlj
aGFlbC5zY2hhcmZAbm9raWEuY29tPjsgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRm
Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZz47IHRjcG1A
aWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIEZ1cnRo
ZXIgY29tbWVudHMgb24gZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbg0KDQpNaWNoYWVsLA0K
DQpPSyBSRUNPTU1FTkRFRCAtPiByZWNvbW1lbmRlZC4NClRoYXQncyBnb29kLCBvdGhlcndpc2Ug
SSB0aGluayBFQ04rKyB3b3VsZCBoYXZlIGJlY29tZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQoN
Cg0KDQpBbHRlcm5hdGl2ZWx5LCBhIG1vcmUgc3RhdGVtZW50IG5vdCByZWxhdGVkIHRvIHRoZSBz
dGF0dXMgd291bGQgYmUg4oCcYSBjb21iaW5hdGlvbiBvZiBBY2NFQ04gd2l0aCBSRkMgNTU2MiBp
cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW504oCdLg0KU29tZW9uZSB3aG8gaGFk
IG5ldmVyIGV2ZW4gdGhvdWdodCBhYm91dCBjb21iaW5pbmcgQWNjRUNOIHdpdGggUkZDNTU2MiBt
aWdodCB0aGluayB3ZSBtZWFuICJBY2NFQ04gY291bGQgYWxzbyBiZSBjb21iaW5lZCB3aXRoIFJG
QzU1NjIsIGJ1dCB0aGlzIGlzbid0IHRoZSBwbGFjZSB0byB0YWxrIGFib3V0IGl0PyINCg0KSG93
IGFib3V0Og0KDQogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wg
aXMgaW1wbGVtZW50ZWQgYWxvbmdzaWRlDQoNCiAgIHRoZSBleHBlcmltZW50YWwgRUNOKysgcHJv
dG9jb2wgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3Bt
LWdlbmVyYWxpemVkLWVjbj5dLg0KDQogICBUaGVyZWZvcmUsIHRoaXMgc3BlY2lmaWNhdGlvbiBk
b2VzIG5vdCBkaXNjdXNzIGltcGxlbWVudGluZyBBY2NFQ04NCg0KICAgYWxvbmdzaWRlIHRoZSBl
YXJsaWVyIGV4cGVyaW1lbnRhbCBhbHRlcm5hdGl2ZSB0byBFQ04rKyBpbiBbUkZDNTU2Ml0uDQoN
Cg0KDQoNCkJvYg0KT24gMTcvMDcvMTggMDg6NTcsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE
RS9TdHV0dGdhcnQpIHdyb3RlOg0KSSB3b3VsZCBwcmVmZXIgdGhlIGZpcnN0LCBzaG9ydGVyIHdv
cmRpbmcuDQoNCkZvciBpbnN0YW5jZSwgaXQgd291bGQgYmUgcG9zc2libGUgdGhhdCBUQ1BNIGRl
Y2lkZXMgdG8gb2Jzb2xldGUgUkZDIDU1NjIuIEnigJlkIHN1Z2dlc3QgdG8ga2VlcCB0aGUgc3Rh
dHVzIGFuZCBmdXR1cmUgdXNlIG9mIFJGQyA1NTYyIGluIGNvbWJpbmF0aW9uIHdpdGggRUNOKysg
b3V0c2lkZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpXaGF0IG1pZ2h0IGJlIGluIHNjb3BlIG9mIHRo
ZSBBY2NFQ04gc3BlYyB3b3VsZCBiZSBhIGh5cG90aGV0aWNhbCB1c2Ugb2YgQWNjRUNOIGluIGNv
bWJpbmF0aW9uIHdpdGggUkZDIDU1NjIuIEJ1dCBJIHdvdWxkIGJlIGZpbmUgd2l0aCBqdXN0IG9t
aXR0aW5nIHRoYXQuIEFsdGVybmF0aXZlbHksIGEgbW9yZSBzdGF0ZW1lbnQgbm90IHJlbGF0ZWQg
dG8gdGhlIHN0YXR1cyB3b3VsZCBiZSDigJxhIGNvbWJpbmF0aW9uIG9mIEFjY0VDTiB3aXRoIFJG
QyA1NTYyIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnTigJ0uDQoNCkFjdHVh
bGx5LCBJIGFtIGFsc28gbm90IHN1cmUgaWYgdGhpcyBwYXJhZ3JhcGggaXMgYSBnb29kIGV4YW1w
bGUgZm9yIFJFQ09NTUVOREVEIGluIGEgY2FwaXRhbCBsZXR0ZXJzLiBUbyBtZSwgdGhlIGZvbGxv
d2luZyB3b3VsZCBiZSBzdWZmaWNpZW50Og0KDQoNCiAgIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQg
dGhlIEFjY0VDTiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoDQoNCiAgIHRoZSBl
eHBlcmltZW50YWwgRUNOKysgcHJvdG9jb2wgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNu
PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNu
LTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbj5dLg0KDQpNaWNoYWVsDQoNCkZy
b206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IFR1ZXNk
YXksIEp1bHkgMTcsIDIwMTggMjo0MyBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE
RS9TdHV0dGdhcnQpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+PG1haWx0bzptaWNoYWVsLnNj
aGFyZkBub2tpYS5jb20+OyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnPG1h
aWx0bzpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnPjsgdGNwbUBpZXRmLm9y
ZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdGNwbV0gRnVydGhlciBjb21t
ZW50cyBvbiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQoNCk1pY2hhZWwsDQoNCkkndmUg
d3JpdHRlbiB0aGUgcHJvcG9zZWQgZWRpdHMgaW50byBhIGxvY2FsIGNvcHkgb2YgZHJhZnQtMDgs
IHdoaWNoIHdlJ2xsIHBvc3QgYWZ0ZXIgdGhpcyBJRVRGLg0KDQpXaWxlIHdyaXRpbmcgdGhlIGxh
c3QgcG9pbnQsIEkgdGhvdWdodCBpdCBiZXN0IHRvIGFkZCBhbiBleHRyYSBzZW50ZW5jZS4NCg0K
ICAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIGlzIGltcGxlbWVu
dGVkIGFsb25nIHdpdGgNCg0KICAgdGhlIGV4cGVyaW1lbnRhbCBFQ04rKyBwcm90b2NvbCBbSS1E
LmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6
ZWQtZWNuPl0uDQoNCiAgIFtJLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbl0gaXMgYSBwcm9w
b3NlZCBhbHRlcm5hdGl2ZSB0byBhbm90aGVyDQoNCiAgIGV4cGVyaW1lbnRhbCBzY2hlbWUgW1JG
QzU1NjJdIHNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW1wbGVtZW50IFJGQw0KDQogICA1NTYyIGFs
b25nIHdpdGggQWNjRUNOLg0KDQoNCg0KDQpCb2INCk9uIDE3LzA3LzE4IDAxOjA1LCBTY2hhcmYs
IE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSB3cm90ZToNClRoaXMgd291bGQgZm9yIGZv
ciBtZS4NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzpp
ZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogVHVlc2RheSwgSnVseSAxNywgMjAxOCAxOjM0IEFN
DQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hhZWwuc2No
YXJmQG5va2lhLmNvbT48bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT47IGRyYWZ0LWll
dGYtdGNwbS1hY2N1cmF0ZS1lY25AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGNwbS1hY2N1
cmF0ZS1lY25AaWV0Zi5vcmc+OyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0K
U3ViamVjdDogUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdGNwbS1h
Y2N1cmF0ZS1lY24NCg0KTWljaGFlbCwNCk9uIDE1LzA3LzE4IDE2OjU0LCBTY2hhcmYsIE1pY2hh
ZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSB3cm90ZToNCg0KSGkgYWxsLA0KDQoNCg0KV2hpbGUg
cmVhZGluZyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3LCBJIG5vdGljZWQgdGhlIGZv
bGxvd2luZzoNCg0KDQoNCg0KDQpTZWN0aW9uIDEuIEludHJvZHVjdGlvbg0KDQoNCg0KICAgSXQg
aXMgbGlrZWx5IChidXQgbm90IHJlcXVpcmVkKSB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgd2ls
bCBiZQ0KDQogICBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIHRoZSBmb2xsb3dpbmcgZXhwZXJpbWVu
dGFsIGFkZGl0aW9ucyB0byB0aGUNCg0KICAgVENQLUVDTiBwcm90b2NvbDogRUNOLWNhcGFibGUg
VENQIGNvbnRyb2wgcGFja2V0cyBhbmQgcmV0cmFuc21pc3Npb25zDQoNCiAgIFtJLUQuaWV0Zi10
Y3BtLWdlbmVyYWxpemVkLWVjbl0sIHdoaWNoIGluY2x1ZGVzIHRoZSBFQ04tY2FwYWJsZSBTWU4v
DQoNCiAgIEFDSyBleHBlcmltZW50IFtSRkM1NTYyXTsgYW5kIHRlc3RpbmcgcmVjZWl2ZXIgbm9u
LWNvbXBsaWFuY2UNCg0KICAgW0ktRC5tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXRdLg0KDQoNCg0K
W21zXSBJIGhhdmUgY29tbWVudGVkIG9uIHRoaXMgc2VjdGlvbiBiZWZvcmUuIEFuZCBJIHN0aWxs
IGRpc2xpa2UgdGhlIHRlcm0gImxpa2VseSIuIFRvIG1lLCAibGlrZWx5IiBpcyBzcGVjdWxhdGlv
bi4gQSBuZXV0cmFsIHBocmFzaW5nIHdvdWxkIGJlICIuLi4gaXQgaXMgcG9zc2libGUuLi4iIG9y
ICIuLi4gaXQgaXMgdXNlZnVsLi4uIi4gSGF2aW5nIHNhaWQgdGhpcywgSSBvYnNlcnZlIHRoYXQg
ZHJhZnQtbW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0LTAzIHdhcyBsYXN0IHVwZGF0ZWQgaW4gMjAx
NC4gSG93ICJsaWtlbHkiIGlzIGl0IHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlIGlt
cGxlbWVudGVkIGFsb25nIHdpdGggYSBtZWNoYW5pc20gZG9jdW1lbnRlZCBpbiBhbiBJRCB0aGF0
IGhhcyBiZWVuIHdyaXR0ZW4gbW9yZSB0aGFuIDEwIHllYXJzIGFnbyBhbmQgbm90IGJlZW4gdXBk
YXRlZCBmb3IgYWJvdXQgNCB5ZWFycz8gQXJlIGltcGxlbWVudGVycyBpbmRlZWQgc28gaW50ZXJl
c3RlZCBpbiBkcmFmdC1tb25jYXN0ZXItdGNwbS1yY3YtY2hlYXQgdGhhdCBhbiBpbXBsZW1lbnRh
dGlvbiBpcyAibGlrZWx5Ij8NCg0KSSBhZ3JlZS4gRm9yIEVDTisrLCBJIHRoaW5rIHNvbWV0aGlu
ZyBsaWtlIHlvdXIgc3VnZ2VzdGlvbiBvZiAidXNlZnVsIiwgb3IgZXZlbiBSRUNPTU1FTkRFRCBp
cyB3aGF0IGlzIG5lZWRlZCBoZXJlLiBJIHRoaW5rIHRoZSB0ZXN0aW5nIHJlY2VpdmVyIGNvbXBs
aWFuY2Ugb25lIGNvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgaW50cm8uIEl0J3MgbWVudGlvbmVk
IHVuZGVyIHRlc3RpbmcgZm9yIHVuZXhwZWN0ZWQgaW50ZXJmZXJlbmNlIGFuZCB1bmRlciBpbnRl
Z3JpdHkgY2hlY2tpbmcsIHdoaWNoIGFyZSBzdWZmaWNpZW50Lg0KDQpBbHNvLCB0aGlzIG1ha2Vz
IG1lIG5vdGljZSB0aGF0IHRoZSB3b3JkICJpbmNsdWRlcyIgaXMgd3JvbmcuIEVDTisrIGludGVu
ZHMgdG8gb2Jzb2xldGUgUkZDNTU2MiwgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBtZW50
aW9uIHRoYXQgaGVyZSAoY29zIGl0IG1pZ2h0IGNoYW5nZSBiZWZvcmUgRUNOKysgZ2V0cyBwdWJs
aXNoZWQpLg0KDQpDVVJSRU5UIFRFWFQ6DQoNCiAgIEl0IGlzIGxpa2VseSAoYnV0IG5vdCByZXF1
aXJlZCkgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIHdpbGwgYmUNCg0KICAgaW1wbGVtZW50ZWQg
YWxvbmcgd2l0aCB0aGUgZm9sbG93aW5nIGV4cGVyaW1lbnRhbCBhZGRpdGlvbnMgdG8gdGhlDQoN
CiAgIFRDUC1FQ04gcHJvdG9jb2w6IEVDTi1jYXBhYmxlIFRDUCBjb250cm9sIHBhY2tldHMgYW5k
IHJldHJhbnNtaXNzaW9ucw0KDQogICBbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcj
cmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPl0sIHdoaWNoIGluY2x1ZGVzIHRoZSBF
Q04tY2FwYWJsZSBTWU4vDQoNCiAgIEFDSyBleHBlcmltZW50IFtSRkM1NTYyPGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTYyPl07IGFuZCB0ZXN0aW5nIHJlY2VpdmVyIG5vbi1jb21w
bGlhbmNlDQoNCiAgIFtJLUQubW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0PGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQubW9u
Y2FzdGVyLXRjcG0tcmN2LWNoZWF0Pl0uDQpQUk9QT1NFRCBURVhUOg0KDQogICBJdCBpcyBSRUNP
TU1FTkRFRCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmcgd2l0
aA0KDQogICB0aGUgZXhwZXJpbWVudGFsIEVDTisrIHByb3RvY29sIFtJLUQuaWV0Zi10Y3BtLWdl
bmVyYWxpemVkLWVjbjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3Bt
LWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY24+XS4NCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNClNlY3Rpb24gMi4xLiAgQ2FwYWJpbGl0eSBOZWdvdGlhdGlv
bg0KDQoNCg0KICAgVGhlIFRDUCBzZXJ2ZXIgc2VuZHMgdGhlIEFjY0VDTg0KDQogICBPcHRpb24g
b24gdGhlIFNZTi9BQ0sgYW5kIHRoZSBjbGllbnQgc2VuZHMgaXQgb24gdGhlIGZpcnN0IEFDSyB0
bw0KDQogICB0ZXN0IHdoZXRoZXIgdGhlIG5ldHdvcmsgcGF0aCBmb3J3YXJkcyB0aGUgb3B0aW9u
IGNvcnJlY3RseS4NCg0KDQoNClttc10gQWNjb3JkaW5nIHRvIFNlY3Rpb24gMy4yLjYsIG9wdGlv
bnMgYXJlIFJFQ09NTUVOREVELiBXaGlsZSBTZWN0aW9uIDIgaXMgbm90IG5vcm1hdGl2ZSwgdGhl
IHdob2xlIFNlY3Rpb24gMiBkb2VzIG5vdCByZWFsbHkgZGVzY3JpYmUgd2VsbCB0aGUgYWN0dWFs
IHJlcXVpcmVtZW50cyByZWdhcmRpbmcgb3B0aW9ucy4gVGhpcyBwYXJhZ3JhcGggaW4gU2VjdGlv
biAyLjEgaXMgb25lIGV4YW1wbGUgZm9yIHRoYXQuIEl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYmUg
bW9yZSBleHBsaWNpdCBpbiBTZWN0aW9uIDIgdG8gd2hpY2ggZXh0ZW50IG9wdGlvbnMgaGF2ZSB0
byBiZSBzdXBwb3J0ZWQuDQpPSywgd2UgbmVlZCB0byByZXZpZXcgc2VjdGlvbiAyLCB0byBlbnN1
cmUgaXQgaXMgY29uc2lzdGVudCB3aXRoIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWFkZSBpbiB0
aGUgbm9ybWF0aXZlIHNlY3Rpb24gMyBzaW5jZSBpdCB3YXMgd3JpdHRlbi4NCg0KSW4gdGhpcyBw
YXJ0aWN1bGFyIGNhc2UsIHdlIGFscmVhZHkgcHJvbWlzZWQgdG8gY2hlY2sgKG9mZmxpc3Qgd2l0
aCBhbiBpbXBsZW1lbnRlcikgdGhhdCB0aGVyZSB3YXMgbm8gdGV4dCB0aGF0IGNvbnRyYWRpY3Rl
ZCB0aGUgb3B0aW9uYWxpdHkgb2YgdGhlIG9wdGlvbiBzdGF0ZWQgYXQgdGhlIGVuZCBvZiBTZWN0
aW9uIDMuMi42Lg0KDQpJIGhhdmUgYWxyZWFkeSBzdGFydGVkIHRoaXMgd2l0aCBhIGxpc3QgSSBw
cmVwYXJlZCAoYWxzbyBvZmZsaXN0KSBvZiB3aGljaCBtaWRkbGVib3ggY2hlY2tpbmcgc2VjdGlv
bnMgYW4gaW1wbGVtZW50ZXIgY291bGQgaWdub3JlIGlmIHRoZXkgd2VyZSBvbmx5IHJlYWRpbmcg
YnV0IG5vdCBzZW5kaW5nIHRoZSBUQ1Agb3B0aW9ucy4NCg0KDQoNCg0KQm9iDQoNCg0KDQoNCg0K
DQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
Qm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNj
b2UubmV0Lw0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoNCi0tDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDov
L2JvYmJyaXNjb2UubmV0Lw0KDQoNCg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQo=

--_000_VI1PR07MB0880A773470BEAF2B86AE69393530VI1PR07MB0880eurp_
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
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsN
Cgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
CnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy
Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n
PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj
dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5UaGUgZm9sbG93aW5nIHdvcmRpbmcgbWlnaHQgd29yayBmb3IgbWU6PG86cD48L286cD48L3A+
DQo8cHJlPiZuYnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04gcHJv
dG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmdzaWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7ICZuYnNwO3RoZSBleHBlcmltZW50YWwgRUNOJiM0MzsmIzQzOyBwcm90b2NvbCBbPGEgaHJl
Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1l
Y24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIiB0aXRsZT0iJnF1b3Q7RUNO
JiM0MzsmIzQzOzogQWRkaW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04p
IHRvIFRDUCBDb250cm9sIFBhY2tldHMmcXVvdDsiPkktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQt
ZWNuPC9hPl0uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO1RoZXJl
Zm9yZSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGRpc2N1c3MgaW1wbGVtZW50aW5nIEFj
Y0VDTiBhbG9uZ3NpZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgW1JGQzU1
NjJdLCB3aGljaCBpcyBhbiBlYXJsaWVyIGV4cGVyaW1lbnRhbCBwcm90b2NvbC48bzpwPjwvbzpw
PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5BcyBmYXIgYXMgSSBrbm93LCB0aGUgZXhwZXJp
bWVudCBvZiBSRkMgNTU2MiBoYXMgbm90IGJlZW4gb2ZmaWNpYWxseSBmaW5pc2hlZCBzbyBmYXIs
IGkuZS4sIHVzZSBvZiBwYXN0IHRlbnNlIG1pZ2h0IG5vdCBiZSBhcHByb3ByaWF0ZS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPihQZXJzb25hbGx5LCBJIGNvdWxk
IGltYWdpbmUgdGhhdCBUQ1BNIGRlY2lkZXMgdG8gZmluaXNoIHRoZSBleHBlcmltZW50IG9mIFJG
QyA1NTYyLCBidXQgdGhhdCBxdWVzdGlvbiBkb2VzIG5vdCBiZWxvbmcgaW50byB0aGlzIEktRC4p
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5NaWNoYWVsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g
MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFttYWls
dG86aWV0ZkBib2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1
bHkgMTgsIDIwMTggMTI6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTm9r
aWEgLSBERS9TdHV0dGdhcnQpICZsdDttaWNoYWVsLnNjaGFyZkBub2tpYS5jb20mZ3Q7OyBkcmFm
dC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnOyB0Y3BtQGlldGYub3JnPGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRj
cG0tYWNjdXJhdGUtZWNuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNoYWVsLDxicj4NCjxicj4NClNv
cnJ5LCBJIG1lYW50IHRvIGFkZCBiYWNrIGluICdUaGVyZWZvcmUnOjxvOnA+PC9vOnA+PC9wPg0K
PHByZT4mbmJzcDsmbmJzcDsgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgQWNjRUNOIHByb3Rv
Y29sIGlzIGltcGxlbWVudGVkIGFsb25nc2lkZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyAmbmJzcDt0aGUgZXhwZXJpbWVudGFsIEVDTiYjNDM7JiM0MzsgcHJvdG9jb2wgWzxhIGhyZWY9
Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNu
LTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbiIgdGl0bGU9IiZxdW90O0VDTiYj
NDM7JiM0Mzs6IEFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0
byBUQ1AgQ29udHJvbCBQYWNrZXRzJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVj
bjwvYT5dLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDtUaGVyZWZv
cmUsIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkaXNjdXNzIGltcGxlbWVudGluZyBBY2NF
Q04gYWxvbmdzaWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFtSRkM1NTYy
XSwgd2hpY2ggd2FzIGFuIGVhcmxpZXIgZXhwZXJpbWVudGFsIHByb3RvY29sIHdpdGggbmFycm93
ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc2NvcGUgdGhhbiBFQ04mIzQz
OyYjNDM7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE4LzA3LzE4IDA2OjE0LCBCb2IgQnJpc2NvZSB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KVGhhdCByZWdhaW5zIHRo
ZSBwcm9ibGVtIEkgc2FpZCBJIHdhcyB0cnlpbmcgcmVtb3ZlLCBvZiByaXNraW5nIGltcGx5aW5n
ICZxdW90O0FjY0VDTiBjb3VsZCBhbHNvIGJlIGNvbWJpbmVkIHdpdGggUkZDNTU2MiwgYnV0IHRo
aXMgaXNuJ3QgdGhlIHBsYWNlIHRvIHRhbGsgYWJvdXQgaXQ/JnF1b3Q7LCBieSBub3QgZXhwbGFp
bmluZyB0aGF0IEVDTiYjNDM7JiM0Mzsgc3Vic3VtZXMgdGhlIGZ1bmN0aW9uIG9mIFJGQzU1NjIu
IEhvdyBhYm91dDo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlY29t
bWVuZGVkIHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbG9uZ3NpZGU8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7dGhlIGV4cGVyaW1lbnRhbCBFQ04m
IzQzOyYjNDM7IHByb3RvY29sIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0wNyNyZWYtSS1ELmlldGYtdGNwbS1nZW5lcmFs
aXplZC1lY24iIHRpdGxlPSImcXVvdDtFQ04mIzQzOyYjNDM7OiBBZGRpbmcgRXhwbGljaXQgQ29u
Z2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gVENQIENvbnRyb2wgUGFja2V0cyZxdW90OyI+
SS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY248L2E+XS4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGRpc2N1c3Mg
aW1wbGVtZW50aW5nIEFjY0VDTiBhbG9uZ3NpZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5i
c3A7Jm5ic3A7W1JGQzU1NjJdLCB3aGljaCB3YXMgYW4gZWFybGllciBleHBlcmltZW50YWwgcHJv
dG9jb2wgd2l0aCBuYXJyb3dlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBz
Y29wZSB0aGFuIEVDTiYjNDM7JiM0MzsuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KQm9i
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcvMDcvMTgg
MTc6MDEsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij5UaGlzIHdvcmRpbmcgd291bGQgaW1wbHkgdGhhdCBFQ04mIzQzOyYj
NDM7IGFuZCBSRkMgNTU2MiBhcmUgaW5kZWVkDQo8L3NwYW4+4oCcPHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPmFsdGVybmF0aXZlczwvc3Bhbj7igJ08c3BhbiBzdHlsZT0iY29sb3I6d2lu
ZG93dGV4dCI+LiBUaGF0IGlzIElNSE8gbm90IGZ1bGx5IGNvcnJlY3QsIEVDTiYjNDM7JiM0Mzsg
c2VlbXMgdG8gaGF2ZSBhIGJyb2FkZXIgc2NvcGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij5JIHRoaW5rIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YNCjwv
c3Bhbj7igKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPiZu
YnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMg
aW1wbGVtZW50ZWQgYWxvbmdzaWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNw
O3RoZSBleHBlcmltZW50YWwgRUNOJiM0MzsmIzQzOyBwcm90b2NvbCBbPGEgaHJlZj0iaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVm
LUktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuIiB0aXRsZT0iJnF1b3Q7RUNOJiM0MzsmIzQz
OzogQWRkaW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIHRvIFRDUCBD
b250cm9sIFBhY2tldHMmcXVvdDsiPkktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPC9hPl0u
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgc3BlY2lmaWNh
dGlvbiBkb2VzIG5vdCBkaXNjdXNzIGltcGxlbWVudGluZyBBY2NFQ04gPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7YWxvbmdzaWRlIHRoZSBleHBlcmltZW50YWwgcHJv
dG9jb2wgW1JGQzU1NjJdLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi
PiBkb2VzIHRoZSBqb2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0
Ij5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs
dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+IEJvYiBCcmlzY29lIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5u
ZXQiPm1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAxOCAxMDoy
OCBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2Fy
dCkgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iPiZsdDtt
aWNoYWVsLnNjaGFyZkBub2tpYS5jb20mZ3Q7PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0
ZXh0Ij47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1l
Y25AaWV0Zi5vcmciPmRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY25AaWV0Zi5vcmc8L2E+PHNw
YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNw
bUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gRnVydGhlciBjb21tZW50cyBvbiBk
cmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+TWljaGFlbCw8YnI+DQo8YnI+DQpPSyBSRUNPTU1FTkRFRCAtJmd0
OyByZWNvbW1lbmRlZC48YnI+DQpUaGF0J3MgZ29vZCwgb3RoZXJ3aXNlIEkgdGhpbmsgRUNOJiM0
MzsmIzQzOyB3b3VsZCBoYXZlIGJlY29tZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5BbHRlcm5hdGl2ZWx5LCBhIG1vcmUgc3RhdGVt
ZW50IG5vdCByZWxhdGVkIHRvIHRoZSBzdGF0dXMgd291bGQgYmUNCjwvc3Bhbj7igJw8c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+YSBjb21iaW5hdGlvbiBvZiBBY2NFQ04gd2l0aCBSRkMg
NTU2MiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50PC9zcGFuPuKAnTxzcGFu
IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZW9uZSB3aG8gaGFkIG5ldmVyIGV2ZW4g
dGhvdWdodCBhYm91dCBjb21iaW5pbmcgQWNjRUNOIHdpdGggUkZDNTU2MiBtaWdodCB0aGluayB3
ZSBtZWFuICZxdW90O0FjY0VDTiBjb3VsZCBhbHNvIGJlIGNvbWJpbmVkIHdpdGggUkZDNTU2Miwg
YnV0IHRoaXMgaXNuJ3QgdGhlIHBsYWNlIHRvIHRhbGsgYWJvdXQgaXQ/JnF1b3Q7DQo8YnI+DQo8
YnI+DQpIb3cgYWJvdXQ6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBJdCBpcyBy
ZWNvbW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmdz
aWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNwO3RoZSBleHBlcmltZW50YWwg
RUNOJiM0MzsmIzQzOyBwcm90b2NvbCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24tMDcjcmVmLUktRC5pZXRmLXRjcG0tZ2Vu
ZXJhbGl6ZWQtZWNuIiB0aXRsZT0iJnF1b3Q7RUNOJiM0MzsmIzQzOzogQWRkaW5nIEV4cGxpY2l0
IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIHRvIFRDUCBDb250cm9sIFBhY2tldHMmcXVv
dDsiPkktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuPC9hPl0uIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO1RoZXJlZm9yZSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRv
ZXMgbm90IGRpc2N1c3MgaW1wbGVtZW50aW5nIEFjY0VDTiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsmbmJzcDthbG9uZ3NpZGUgdGhlIGVhcmxpZXIgZXhwZXJpbWVudGFsIGFs
dGVybmF0aXZlIHRvIEVDTiYjNDM7JiM0MzsgaW4gW1JGQzU1NjJdLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N
Cjxicj4NCjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIDE3LzA3LzE4IDA4OjU3LCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUv
U3R1dHRnYXJ0KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SSB3b3VsZCBwcmVmZXIgdGhl
IGZpcnN0LCBzaG9ydGVyIHdvcmRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0Ij5Gb3IgaW5zdGFuY2UsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRoYXQgVENQTSBk
ZWNpZGVzIHRvIG9ic29sZXRlIFJGQyA1NTYyLiBJPC9zcGFuPuKAmTxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij5kIHN1Z2dlc3QgdG8ga2VlcCB0aGUgc3RhdHVzIGFuZCBmdXR1cmUgdXNl
IG9mIFJGQyA1NTYyIGluIGNvbWJpbmF0aW9uIHdpdGggRUNOJiM0MzsmIzQzOyBvdXRzaWRlDQog
b2YgdGhpcyBkb2N1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPldoYXQgbWlnaHQgYmUgaW4gc2NvcGUgb2YgdGhlIEFjY0VDTiBzcGVjIHdvdWxkIGJlIGEg
aHlwb3RoZXRpY2FsIHVzZSBvZiBBY2NFQ04gaW4gY29tYmluYXRpb24gd2l0aCBSRkMgNTU2Mi4g
QnV0IEkgd291bGQgYmUgZmluZSB3aXRoIGp1c3Qgb21pdHRpbmcgdGhhdC4gQWx0ZXJuYXRpdmVs
eSwgYSBtb3JlIHN0YXRlbWVudCBub3QgcmVsYXRlZCB0byB0aGUNCiBzdGF0dXMgd291bGQgYmUg
PC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5hIGNvbWJpbmF0aW9uIG9m
IEFjY0VDTiB3aXRoIFJGQyA1NTYyIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l
bnQ8L3NwYW4+4oCdPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPi48L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93
dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkFjdHVhbGx5LCBJIGFtIGFsc28gbm90IHN1
cmUgaWYgdGhpcyBwYXJhZ3JhcGggaXMgYSBnb29kIGV4YW1wbGUgZm9yIFJFQ09NTUVOREVEIGlu
IGEgY2FwaXRhbCBsZXR0ZXJzLiBUbyBtZSwgdGhlIGZvbGxvd2luZyB3b3VsZCBiZSBzdWZmaWNp
ZW50Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJl
PiZuYnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wg
aXMgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAm
bmJzcDt0aGUgZXhwZXJpbWVudGFsIEVDTiYjNDM7JiM0MzsgcHJvdG9jb2wgWzxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3
I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbiIgdGl0bGU9IiZxdW90O0VDTiYjNDM7
JiM0Mzs6IEFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBU
Q1AgQ29udHJvbCBQYWNrZXRzJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjwv
YT5dLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPk1pY2hhZWw8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7
cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEJvYiBC
cmlzY29lIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPm1haWx0
bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5d
DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAxOCAyOjQzIFBNPGJyPg0K
PGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSA8L3NwYW4+
PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSI+Jmx0O21pY2hhZWwuc2No
YXJmQG5va2lhLmNvbSZndDs8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjsNCjwv
c3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9y
ZyI+ZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbkBpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3Jn
Ij50Y3BtQGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBGdXJ0aGVyIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYt
dGNwbS1hY2N1cmF0ZS1lY248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0K
SSd2ZSB3cml0dGVuIHRoZSBwcm9wb3NlZCBlZGl0cyBpbnRvIGEgbG9jYWwgY29weSBvZiBkcmFm
dC0wOCwgd2hpY2ggd2UnbGwgcG9zdCBhZnRlciB0aGlzIElFVEYuPGJyPg0KPGJyPg0KV2lsZSB3
cml0aW5nIHRoZSBsYXN0IHBvaW50LCBJIHRob3VnaHQgaXQgYmVzdCB0byBhZGQgYW4gZXh0cmEg
c2VudGVuY2UuPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBJdCBpcyBSRUNPTU1F
TkRFRCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgYWxvbmcgd2l0aDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDt0aGUgZXhwZXJpbWVudGFsIEVDTiYj
NDM7JiM0MzsgcHJvdG9jb2wgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxp
emVkLWVjbiIgdGl0bGU9IiZxdW90O0VDTiYjNDM7JiM0Mzs6IEFkZGluZyBFeHBsaWNpdCBDb25n
ZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBUQ1AgQ29udHJvbCBQYWNrZXRzJnF1b3Q7Ij5J
LUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjwvYT5dLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsmbmJzcDtbSS1ELmlldGYtdGNwbS1nZW5lcmFsaXplZC1lY25dIGlzIGEg
cHJvcG9zZWQgYWx0ZXJuYXRpdmUgdG8gYW5vdGhlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBleHBlcmltZW50YWwgc2NoZW1lIFtSRkM1NTYyXSBzbyB0aGVyZSBpcyBubyBu
ZWVkIHRvIGltcGxlbWVudCBSRkM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
NTU2MiBhbG9uZyB3aXRoIEFjY0VDTi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48YnI+DQo8YnI+DQpCb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PbiAxNy8wNy8xOCAwMTowNSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERF
L1N0dXR0Z2FydCkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoaXMgd291bGQgZm9yIGZv
ciBtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoYW5rczwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TWljaGFlbDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw
YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJy
aXNjb2UgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCI+bWFpbHRv
OmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPl0N
Cjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDE6MzQgQU08YnI+DQo8
Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDwvc3Bhbj48
YSBocmVmPSJtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tIj4mbHQ7bWljaGFlbC5zY2hh
cmZAbm9raWEuY29tJmd0OzwvYT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Ow0KPC9z
cGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3Jn
Ij5kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuQGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmci
PnRjcG1AaWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIEZ1cnRoZXIgY29tbWVudHMgb24gZHJhZnQtaWV0Zi10
Y3BtLWFjY3VyYXRlLWVjbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNS8wNy8xOCAxNjo1NCwgU2NoYXJm
LCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT5IaSBhbGwsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+V2hpbGUgcmVhZGluZyBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt
ZWNuLTA3LCBJIG5vdGljZWQgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5TZWN0aW9uIDEuIEludHJvZHVjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBJdCBpcyBsaWtlbHkgKGJ1dCBub3Qg
cmVxdWlyZWQpIHRoYXQgdGhlIEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGVkIGFsb25nIHdpdGggdGhlIGZvbGxvd2lu
ZyBleHBlcmltZW50YWwgYWRkaXRpb25zIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBUQ1AtRUNOIHByb3RvY29sOiBFQ04tY2FwYWJsZSBUQ1AgY29udHJvbCBwYWNr
ZXRzIGFuZCByZXRyYW5zbWlzc2lvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsgW0ktRC5pZXRmLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuXSwgd2hpY2ggaW5jbHVkZXMgdGhlIEVD
Ti1jYXBhYmxlIFNZTi88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQUNLIGV4
cGVyaW1lbnQgW1JGQzU1NjJdOyBhbmQgdGVzdGluZyByZWNlaXZlciBub24tY29tcGxpYW5jZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBbSS1ELm1vbmNhc3Rlci10Y3BtLXJj
di1jaGVhdF0uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+W21zXSBJIGhhdmUgY29tbWVudGVkIG9uIHRoaXMgc2VjdGlvbiBiZWZvcmUuIEFuZCBJ
IHN0aWxsIGRpc2xpa2UgdGhlIHRlcm0gJnF1b3Q7bGlrZWx5JnF1b3Q7LiBUbyBtZSwgJnF1b3Q7
bGlrZWx5JnF1b3Q7IGlzIHNwZWN1bGF0aW9uLiBBIG5ldXRyYWwgcGhyYXNpbmcgd291bGQgYmUg
JnF1b3Q7Li4uIGl0IGlzIHBvc3NpYmxlLi4uJnF1b3Q7IG9yICZxdW90Oy4uLiBpdCBpcyB1c2Vm
dWwuLi4mcXVvdDsuIEhhdmluZyBzYWlkIHRoaXMsIEkgb2JzZXJ2ZSB0aGF0IGRyYWZ0LW1vbmNh
c3Rlci10Y3BtLXJjdi1jaGVhdC0wMyB3YXMgbGFzdCB1cGRhdGVkIGluIDIwMTQuIEhvdyAmcXVv
dDtsaWtlbHkmcXVvdDsgaXMgaXQgdGhhdCB0aGUgQWNjRUNOIHByb3RvY29sIHdpbGwgYmUgaW1w
bGVtZW50ZWQgYWxvbmcgd2l0aCBhIG1lY2hhbmlzbSBkb2N1bWVudGVkIGluIGFuIElEIHRoYXQg
aGFzIGJlZW4gd3JpdHRlbiBtb3JlIHRoYW4gMTAgeWVhcnMgYWdvIGFuZCBub3QgYmVlbiB1cGRh
dGVkIGZvciBhYm91dCA0IHllYXJzPyBBcmUgaW1wbGVtZW50ZXJzIGluZGVlZCBzbyBpbnRlcmVz
dGVkIGluIGRyYWZ0LW1vbmNhc3Rlci10Y3BtLXJjdi1jaGVhdCB0aGF0IGFuIGltcGxlbWVudGF0
aW9uIGlzICZxdW90O2xpa2VseSZxdW90Oz88bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSBhZ3JlZS4gRm9yIEVDTiYjNDM7JiM0Mzss
IEkgdGhpbmsgc29tZXRoaW5nIGxpa2UgeW91ciBzdWdnZXN0aW9uIG9mICZxdW90O3VzZWZ1bCZx
dW90Oywgb3IgZXZlbiBSRUNPTU1FTkRFRCBpcyB3aGF0IGlzIG5lZWRlZCBoZXJlLiBJIHRoaW5r
IHRoZSB0ZXN0aW5nIHJlY2VpdmVyIGNvbXBsaWFuY2Ugb25lIGNvdWxkIGJlIHJlbW92ZWQgZnJv
bSB0aGUgaW50cm8uIEl0J3MgbWVudGlvbmVkIHVuZGVyIHRlc3RpbmcgZm9yIHVuZXhwZWN0ZWQg
aW50ZXJmZXJlbmNlIGFuZCB1bmRlcg0KIGludGVncml0eSBjaGVja2luZywgd2hpY2ggYXJlIHN1
ZmZpY2llbnQuIDxicj4NCjxicj4NCkFsc28sIHRoaXMgbWFrZXMgbWUgbm90aWNlIHRoYXQgdGhl
IHdvcmQgJnF1b3Q7aW5jbHVkZXMmcXVvdDsgaXMgd3JvbmcuIEVDTiYjNDM7JiM0MzsgaW50ZW5k
cyB0byBvYnNvbGV0ZSBSRkM1NTYyLCBidXQgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIG1lbnRp
b24gdGhhdCBoZXJlIChjb3MgaXQgbWlnaHQgY2hhbmdlIGJlZm9yZSBFQ04mIzQzOyYjNDM7IGdl
dHMgcHVibGlzaGVkKS48YnI+DQo8YnI+DQpDVVJSRU5UIFRFWFQ6PG86cD48L286cD48L3A+DQo8
cHJlPiZuYnNwOyZuYnNwOyBJdCBpcyBsaWtlbHkgKGJ1dCBub3QgcmVxdWlyZWQpIHRoYXQgdGhl
IEFjY0VDTiBwcm90b2NvbCB3aWxsIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IGltcGxlbWVudGVkIGFsb25nIHdpdGggdGhlIGZvbGxvd2luZyBleHBlcmltZW50YWwgYWRk
aXRpb25zIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUQ1AtRUNO
IHByb3RvY29sOiBFQ04tY2FwYWJsZSBUQ1AgY29udHJvbCBwYWNrZXRzIGFuZCByZXRyYW5zbWlz
c2lvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgWzxhIGhyZWY9Imh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3Jl
Zi1JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbiIgdGl0bGU9IiZxdW90O0VDTiYjNDM7JiM0
Mzs6IEFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBUQ1Ag
Q29udHJvbCBQYWNrZXRzJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjwvYT5d
LCB3aGljaCBpbmNsdWRlcyB0aGUgRUNOLWNhcGFibGUgU1lOLzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyBBQ0sgZXhwZXJpbWVudCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL3JmYzU1NjIiIHRpdGxlPSImcXVvdDtBZGRpbmcgRXhwbGljaXQgQ29uZ2Vz
dGlvbiBOb3RpZmljYXRpb24gKEVDTikgQ2FwYWJpbGl0eSB0byBUQ1AncyBTWU4vQUNLIFBhY2tl
dHMmcXVvdDsiPlJGQzU1NjI8L2E+XTsgYW5kIHRlc3RpbmcgcmVjZWl2ZXIgbm9uLWNvbXBsaWFu
Y2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1J
LUQubW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0IiB0aXRsZT0iJnF1b3Q7QSBUQ1AgVGVzdCB0byBB
bGxvdyBTZW5kZXJzIHRvIElkZW50aWZ5IFJlY2VpdmVyIE5vbi1Db21wbGlhbmNlJnF1b3Q7Ij5J
LUQubW9uY2FzdGVyLXRjcG0tcmN2LWNoZWF0PC9hPl0uPG86cD48L286cD48L3ByZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlBST1BPU0VEIFRFWFQ6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNw
OyZuYnNwOyBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBBY2NFQ04gcHJvdG9jb2wgaXMgaW1w
bGVtZW50ZWQgYWxvbmcgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDt0
aGUgZXhwZXJpbWVudGFsIEVDTiYjNDM7JiM0MzsgcHJvdG9jb2wgWzxhIGhyZWY9Imh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTA3I3JlZi1J
LUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbiIgdGl0bGU9IiZxdW90O0VDTiYjNDM7JiM0Mzs6
IEFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBUQ1AgQ29u
dHJvbCBQYWNrZXRzJnF1b3Q7Ij5JLUQuaWV0Zi10Y3BtLWdlbmVyYWxpemVkLWVjbjwvYT5dLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5TZWN0aW9uIDIuMS4mbmJzcDsgQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsmbmJzcDtUaGUgVENQIHNlcnZlciBzZW5kcyB0aGUgQWNjRUNOPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IE9wdGlvbiBvbiB0aGUgU1lOL0FDSyBhbmQgdGhl
IGNsaWVudCBzZW5kcyBpdCBvbiB0aGUgZmlyc3QgQUNLIHRvPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IHRlc3Qgd2hldGhlciB0aGUgbmV0d29yayBwYXRoIGZvcndhcmRzIHRo
ZSBvcHRpb24gY29ycmVjdGx5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlttc10gQWNjb3JkaW5nIHRvIFNlY3Rpb24gMy4yLjYsIG9wdGlvbnMg
YXJlIFJFQ09NTUVOREVELiBXaGlsZSBTZWN0aW9uIDIgaXMgbm90IG5vcm1hdGl2ZSwgdGhlIHdo
b2xlIFNlY3Rpb24gMiBkb2VzIG5vdCByZWFsbHkgZGVzY3JpYmUgd2VsbCB0aGUgYWN0dWFsIHJl
cXVpcmVtZW50cyByZWdhcmRpbmcgb3B0aW9ucy4gVGhpcyBwYXJhZ3JhcGggaW4gU2VjdGlvbiAy
LjEgaXMgb25lIGV4YW1wbGUgZm9yIHRoYXQuIEl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYmUgbW9y
ZSBleHBsaWNpdCBpbiBTZWN0aW9uIDIgdG8gd2hpY2ggZXh0ZW50IG9wdGlvbnMgaGF2ZSB0byBi
ZSBzdXBwb3J0ZWQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9LLCB3ZSBuZWVkIHRvIHJldmlldyBzZWN0aW9uIDIsIHRvIGVuc3VyZSBpdCBp
cyBjb25zaXN0ZW50IHdpdGggY2hhbmdlcyB0aGF0IGhhdmUgYmVlbiBtYWRlIGluIHRoZSBub3Jt
YXRpdmUgc2VjdGlvbiAzIHNpbmNlIGl0IHdhcyB3cml0dGVuLjxicj4NCjxicj4NCkluIHRoaXMg
cGFydGljdWxhciBjYXNlLCB3ZSBhbHJlYWR5IHByb21pc2VkIHRvIGNoZWNrIChvZmZsaXN0IHdp
dGggYW4gaW1wbGVtZW50ZXIpIHRoYXQgdGhlcmUgd2FzIG5vIHRleHQgdGhhdCBjb250cmFkaWN0
ZWQgdGhlIG9wdGlvbmFsaXR5IG9mIHRoZSBvcHRpb24gc3RhdGVkIGF0IHRoZSBlbmQgb2YgU2Vj
dGlvbiAzLjIuNi48YnI+DQo8YnI+DQpJIGhhdmUgYWxyZWFkeSBzdGFydGVkIHRoaXMgd2l0aCBh
IGxpc3QgSSBwcmVwYXJlZCAoYWxzbyBvZmZsaXN0KSBvZiB3aGljaCBtaWRkbGVib3ggY2hlY2tp
bmcgc2VjdGlvbnMgYW4gaW1wbGVtZW50ZXIgY291bGQgaWdub3JlIGlmIHRoZXkgd2VyZSBvbmx5
IHJlYWRpbmcgYnV0IG5vdCBzZW5kaW5nIHRoZSBUQ1Agb3B0aW9ucy48YnI+DQo8YnI+DQo8YnI+
DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0
dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286
cD48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2Nv
ZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4t
LSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+
Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0
cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5l
dC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N
CjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0
LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_VI1PR07MB0880A773470BEAF2B86AE69393530VI1PR07MB0880eurp_--


From nobody Wed Jul 18 06:24:56 2018
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 DA0E9130DC4 for ; Wed, 18 Jul 2018 06:24:53 -0700 (PDT)
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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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=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 fOuN3ibcenGz for ; Wed, 18 Jul 2018 06:24:50 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40126.outbound.protection.outlook.com [40.107.4.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E03F126F72 for ; Wed, 18 Jul 2018 06:24:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F0OGlb46EWQlenAUcafGgNNgI8qk8wKD5CPfgSzRwuM=; b=AzDAtDM91Ff8XUwIZAAhr/8YMZ+Umg7KnQ3iPnT19lPffdno9bfgk+IL0uNzplec8i+XqBS+OKE51RI3gkciCGAnmX3mH/P0+jtXlA/QLPmnxWO1wP6Q+J8uD5Gswcapm/MTTDrRcMO7p6Nl1zbjvNHpOUcqDKuIr6906cLnrnA=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB3248.eurprd07.prod.outlook.com (10.175.243.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Wed, 18 Jul 2018 13:24:47 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.016; Wed, 18 Jul 2018 13:24:47 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" 
To: Bob Briscoe 
CC: ANNA MARIA MANDALARI , tcpm IETF list 
Thread-Topic: [tcpm] Fwd: Re: Data on 'Nonce' and 'Broken' responses to AccECN SYN?
Thread-Index: AQHUHow/b8Ap3RKVakKEgphqvUnb66SU9+Dw
Date: Wed, 18 Jul 2018 13:24:47 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.212.158]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3248; 6:X0MGbL/a3AqEFVE0fzM0btHG3sf8OC3VcKzUSQfIb/hISi0+toicbpkguxZqHQDt8UyetcG7+JQlFHY40HGZ5weE8EURaJGQnMvjK4ZCm7KTTq/w8FdnZMCKXB7YK5Rb5/rNk9Z1p7w/Cb2p9rqGFirzb9bP239BHZpZa3bTnhcJhyTt8Gwxv46et2VSUXHJkglV3iQf1slAcNGUwSOOoIZmotDFBhI2TvF8dWdkLuDn0wvZDNWSxUPpiX6HaO4so+znpF+kUUtKEMyEslUR5tB7W6Sbp0ntlm2NGuNllDZxhHO3+pC1dHZXFEcWe9ZMiRvxG4y7MgN7pbDGPOFq0WYKgrJ2ExLPOgwyuxZMmZd8A+wexIaxA6nfvbpNulOn9C57PvsKV3lI/Va3RxQbASGwP5gzKmaTbsdePOuS4381iiGF4KLo3EqET5+rfCIOPie+osaL8fHbPeREwFNwKg==; 5:W1t2NA4IE95LcCVw4ISxrnqofugKmRQTYTCfkJL1kzggYdRq2uIx6hovy7k5v8FHzLxuzOxRBKacLAZHOefkUTtJqC+bFiyzzLJtjQVe1qlk/8BbAYrC4sJOEetytuqy8RgKXsGd5zLI36DvDWybqNQIwOsmapbKzcmgOLxnFi0=; 7:h7ZRj2/TJwmPNbuaM8dNi2DsVUu6b9rgz83yMOcoXgt2lmrQyt7X0Tj7l+MkEvCkT0sEZBc6XhOrGeMurdvNldPXPKamwGwyJ9wsxcETSvUFn9uaeFi/pqby4zN8tmr3wmmYSaNJ39U9JGMepj8plC5ubQZL9Mr3oDFaXWlTtmiNBm/ZVP16PkBON+lZciSLX+xQBcRbeHHrwdCS+pGnoz/oAX/AfXOAQX6+6cGIWTFZ6N7TfVLW8ljpMs0Jhv8d
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 0b3a9a57-9d91-4235-f923-08d5ecb1d580
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600064)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:VI1PR07MB3248; 
x-ms-traffictypediagnostic: VI1PR07MB3248:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB3248; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3248; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(136003)(366004)(189003)(199004)(54896002)(6916009)(5660300001)(316002)(6436002)(66066001)(7696005)(102836004)(7736002)(9686003)(3846002)(54906003)(55016002)(236005)(186003)(106356001)(26005)(6306002)(74316002)(76176011)(105586002)(6506007)(97736004)(33656002)(53546011)(790700001)(68736007)(81156014)(6116002)(81166006)(8676002)(2906002)(8936002)(4326008)(14454004)(53376002)(229853002)(966005)(478600001)(2900100001)(6246003)(25786009)(53936002)(476003)(486006)(446003)(256004)(5024004)(11346002)(5250100002)(86362001)(99286004)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3248; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4V7JTaqggwcaxrQaeduWNbHd821YDysPOMJASRVY4Gy9voStJOtBgkba5hek7b83/laM0eoVp1y3SAQZefVzQHJWeF0bsG6hLiGhEW/Wufhubgycus8Kh3YfUXnteSIcYGssy9Frx6RUXy484dm6fvDqPzwQQvnUazT0m9HcsKOkDzj5odK17kMz/4lUzy8D66gflZ5vl4istxoNtQUlevtEk8eaxTeIofeYaNV04Ali568/qxFUQiK+BF52Aw5YUGU9WRYXHI3UnVjsYGE2256kYIdFF81aTGTK26Qrd3hLQYx5gvlD9sDEulPQeGRYnxKJeMWulK011AGabESvAZBdUxmmQ21JcnsFGJ6nxix4EuqmLKb7jgyVCak4fszgnuFtJWzeW76BAyMN6nnjlA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB0880A7BF3FCC4FBC31E81D6093530VI1PR07MB0880eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b3a9a57-9d91-4235-f923-08d5ecb1d580
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2018 13:24:47.6607 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3248
Archived-At: 
Subject: Re: [tcpm] Fwd: Re: Data on 'Nonce' and 'Broken' responses to AccECN SYN?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 18 Jul 2018 13:24:54 -0000

--_000_VI1PR07MB0880A7BF3FCC4FBC31E81D6093530VI1PR07MB0880eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW50ZXJlc3RpbmcuIFNvIHdoYXQgcHJldmVudHMgdXMgZnJvbSByZXNlcnZpbmcgdGhlIG5vbmNl
IHBhdHRlcm4gZm9yIGZ1dHVyZSB1c2U/DQoNCk1pY2hhZWwNCg0KDQpGcm9tOiB0Y3BtIFttYWls
dG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9iIEJyaXNjb2UNClNlbnQ6
IFdlZG5lc2RheSwgSnVseSAxOCwgMjAxOCAxOjQxIFBNDQpUbzogTWljaGFlbCBTY2hhcmYgPG1p
Y2hhZWwuc2NoYXJmQGdtYWlsLmNvbT4NCkNjOiBBTk5BIE1BUklBIE1BTkRBTEFSSSA8YW1hbmRh
bGFAaXQudWMzbS5lcz47IHRjcG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDog
W3RjcG1dIEZ3ZDogUmU6IERhdGEgb24gJ05vbmNlJyBhbmQgJ0Jyb2tlbicgcmVzcG9uc2VzIHRv
IEFjY0VDTiBTWU4/DQoNCk1pY2hhZWwsDQoNCkJlbG93IGlzIGRhdGEgZnJvbSA0MTAsODAzIG9m
IHRoZSBBbGV4YSB0b3AgNTAwayB3ZWIgc2VydmVyIHRoYXQgY29uZmlybXMgd2hhdCBJIHNhaWQg
aW4gdGhlIHByZXNlbnRhdGlvbiBhYm91dCBzcGFjZSBmb3IgZnV0dXJlIGV2b2x1dGlvbiBvZiBB
Y2NFQ046DQoNCiAgKiAgIHRoZSBub25jZSBwYXR0ZXJuIG9uIHRoZSBTWU4tQUNLIGNvdWxkIGJl
IHJldXNlZCBub3cgKDAuMDAwNyUpDQogICogICB0aGUgYnJva2VuIHJlZmxlY3Rpb24gcGF0dGVy
biBpcyBzdGlsbCBmYXIgdG9vIHByZXZhbGVudCB0byByZS11c2UgaXQgKDAuMzUlKS4NCklmIGFu
eW9uZSB3YW50cyB0aGUgbGlzdCBvZiBicm9rZW4gc2VydmVycyB0aGF0IEFubmEgYXR0YWNoZWQg
Zm9yIG1lLCBwbHMgYXNrLg0KVGhlIHdob2xlIGRhdGFzZXQgaXMgYWxzbyBhdmFpbGFibGUgdmlh
OiBodHRwOi8vd3d3Lml0LnVjM20uZXMvYW1hbmRhbGEvZWNuKysvDQoNCkBBbm5hLCB0aGFua3Mg
diBtdWNoIGZvciByZXNwb25kaW5nIHNvIHF1aWNrbHkgLSBpdCB3YXMgbWUgdGhhdCBoYWRuJ3Qg
cmVhZCB5b3VyIGVtYWlsIGluIHRpbWUgZm9yIHRoZSB0YWxrLg0KDQoNCg0KQm9iDQoNCi0tLS0t
LS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpSZTogRGF0YSBvbiAn
Tm9uY2UnIGFuZCAnQnJva2VuJyByZXNwb25zZXMgdG8gQWNjRUNOIFNZTj8NCg0KRGF0ZToNCg0K
VHVlLCAxNyBKdWwgMjAxOCAxNTo0MjoxMCArMDIwMA0KDQpGcm9tOg0KDQpBTk5BIE1BUklBIE1B
TkRBTEFSSSA8YW1hbmRhbGFAaXQudWMzbS5lcz48bWFpbHRvOmFtYW5kYWxhQGl0LnVjM20uZXM+
DQoNClRvOg0KDQpCb2IgQnJpc2NvZSA8cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQ+PG1haWx0bzpy
ZXNlYXJjaEBib2JicmlzY29lLm5ldD4NCg0KDQpIaSBCb2IsDQoNCkkgaGFkIGEgbG9vayBhdCB0
aGUgZGF0YSBhbmQgSSBmb3VuZCAxLDQzOCBzZXJ2ZXJzIG92ZXIgdGhlIHRvcCA0MTAsODAzIEFs
ZXhhICgwLjM1JSkgdGhhdCByZXBseSBTWU4vQUNLKzExMSB0byBhIFNZTisxMTEgKGF0dGFjaGVk
IHRoZSBsaXN0KS4NCg0KT25seSAzIHNlcnZlcnMgKDAuMDAwNyUpIHJlcGx5IFNZTi9BQ0srMTAx
IHRvIGEgU1lOKzExMToNCg0KdGVzdF9zeW5hY2s7MjAwLjEyLjE3MS41Mzs4MDtlY3Q7MDtmbGFn
czszMzgNCnRlc3Rfc3luYWNrOzYwLjI4LjIyMC4xMzQ7ODA7ZWN0OzA7ZmxhZ3M7MzM4DQp0ZXN0
X3N5bmFjazsyMDAuMTIuMTcxLjUyOzgwO2VjdDswO2ZsYWdzOzMzOA0KDQpMZXQgbWUga25vdyBp
ZiBJIGNhbiBoZWxwIHlvdSB3aXRoIHNvbWV0aGluZyBlbHNlIQ0KDQoNCg0KDQoNCg0KMjAxOC0w
Ny0xNyAxMzoyNiBHTVQrMDI6MDAgQm9iIEJyaXNjb2UgPHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0
PG1haWx0bzpyZXNlYXJjaEBib2JicmlzY29lLm5ldD4+Og0KQW5uYSwNCg0KQ291bGQgeW91IGRv
IG1lIGEgZmF2b3VyIGFuZCBsb29rIHVwIGhvdyBtYW55IHNlcnZlcnMgcmVzcG9uZGVkIHRvIGFu
IEFjY0VDTiAoMTExKSBTWU4gd2l0aCBhIFNZTi9BQ0sgY2FycnlpbmcgcmVzcGVjdGl2ZWx5ICdO
b25jZScgKDEwMSkgb3IgJ0Jyb2tlbicgKDExMSk/DQoNCkFuZCBhbHNvIHRoZSB0b3RhbCBudW1i
ZXIgb2YgdGVzdHMgc2VudCB3aXRoIGFuIEFjY0VDTiBTWU4sIHNvIEkgY2FuIGdpdmUgcHJvcG9y
dGlvbnMgaW4gdGhlIEFjY0VDTiBkcmFmdC4NCg0KQ2hlZXJzDQoNCg0KDQpCb2IgKHRvbyBsYXp5
IHRvIGxvb2sgYXQgdGhlIGRhdGEgbXlzZWxmKQ0KDQotLQ0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQm9iIEJyaXNjb2Ug
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQoN
Cg0KLS0NCkFOTkEgTUFSSUEgTUFOREFMQVJJDQpVbml2ZXJzaWRhZCBDYXJsb3MgSUlJIGRlIE1h
ZHJpZA0K

--_000_VI1PR07MB0880A7BF3FCC4FBC31E81D6093530VI1PR07MB0880eurp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv
LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6
MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpi
O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl
OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ
bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ
e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ
e21zby1saXN0LWlkOjIyNzEwODE2NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjM1OTgzNjg2
O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv
Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox
MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0
IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODgu
MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu
MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h
cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SW50ZXJlc3RpbmcuIFNvIHdoYXQgcHJldmVudHMgdXMgZnJvbSByZXNlcnZpbmcgdGhlIG5vbmNl
IHBhdHRlcm4gZm9yIGZ1dHVyZSB1c2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiB0Y3BtIFttYWlsdG86dGNwbS1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Cb2IgQnJpc2NvZTxicj4NCjxi
PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMTgsIDIwMTggMTo0MSBQTTxicj4NCjxiPlRvOjwv
Yj4gTWljaGFlbCBTY2hhcmYgJmx0O21pY2hhZWwuc2NoYXJmQGdtYWlsLmNvbSZndDs8YnI+DQo8
Yj5DYzo8L2I+IEFOTkEgTUFSSUEgTUFOREFMQVJJICZsdDthbWFuZGFsYUBpdC51YzNtLmVzJmd0
OzsgdGNwbSBJRVRGIGxpc3QgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8
L2I+IFt0Y3BtXSBGd2Q6IFJlOiBEYXRhIG9uICdOb25jZScgYW5kICdCcm9rZW4nIHJlc3BvbnNl
cyB0byBBY2NFQ04gU1lOPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk1pY2hhZWwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KQmVsb3cgaXMgZGF0YSBmcm9tIDQxMCw4MDMgb2YgdGhlIEFsZXhhIHRvcCA1MDBr
IHdlYiBzZXJ2ZXIgdGhhdCBjb25maXJtcyB3aGF0IEkgc2FpZCBpbiB0aGUgcHJlc2VudGF0aW9u
IGFib3V0IHNwYWNlIGZvciBmdXR1cmUgZXZvbHV0aW9uIG9mIEFjY0VDTjo8bzpwPjwvbzpwPjwv
cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzEiPg0KdGhlIG5vbmNlIHBhdHRlcm4gb24gdGhlIFNZTi1BQ0sgY291bGQgYmUg
cmV1c2VkIG5vdyAoMC4wMDA3JSk8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQp0aGUgYnJva2VuIHJlZmxlY3Rpb24gcGF0dGVy
biBpcyBzdGlsbCBmYXIgdG9vIHByZXZhbGVudCB0byByZS11c2UgaXQgKDAuMzUlKS48bzpwPjwv
bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGFueW9uZSB3YW50cyB0aGUg
bGlzdCBvZiBicm9rZW4gc2VydmVycyB0aGF0IEFubmEgYXR0YWNoZWQgZm9yIG1lLCBwbHMgYXNr
Ljxicj4NClRoZSB3aG9sZSBkYXRhc2V0IGlzIGFsc28gYXZhaWxhYmxlIHZpYTogPGEgaHJlZj0i
aHR0cDovL3d3dy5pdC51YzNtLmVzL2FtYW5kYWxhL2VjbiYjNDM7JiM0MzsvIj4NCmh0dHA6Ly93
d3cuaXQudWMzbS5lcy9hbWFuZGFsYS9lY24mIzQzOyYjNDM7LzwvYT48YnI+DQo8YnI+DQpAQW5u
YSwgdGhhbmtzIHYgbXVjaCBmb3IgcmVzcG9uZGluZyBzbyBxdWlja2x5IC0gaXQgd2FzIG1lIHRo
YXQgaGFkbid0IHJlYWQgeW91ciBlbWFpbCBpbiB0aW1lIGZvciB0aGUgdGFsay48YnI+DQo8YnI+
DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAt
LS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv
cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4N
Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu
OnJpZ2h0Ij48Yj5TdWJqZWN0OiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl
PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZTogRGF0
YSBvbiAnTm9uY2UnIGFuZCAnQnJva2VuJyByZXNwb25zZXMgdG8gQWNjRUNOIFNZTj88bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIg
c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs
aWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6IDxvOnA+PC9vOnA+
PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlR1ZSwgMTcgSnVsIDIwMTggMTU6NDI6MTAgJiM0MzswMjAwPG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwv
bzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BTk5BIE1BUklBIE1BTkRBTEFSSSA8YSBocmVmPSJtYWls
dG86YW1hbmRhbGFAaXQudWMzbS5lcyI+Jmx0O2FtYW5kYWxhQGl0LnVjM20uZXMmZ3Q7PC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0i
dG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+VG86IDxvOnA+PC9v
OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvYiBCcmlzY29lIDxhIGhyZWY9Im1haWx0bzpyZXNlYXJj
aEBib2JicmlzY29lLm5ldCI+Jmx0O3Jlc2VhcmNoQGJvYmJyaXNjb2UubmV0Jmd0OzwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBCb2IsPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGFkIGEgbG9v
ayBhdCB0aGUgZGF0YSBhbmQgSSBmb3VuZCA8Yj4xLDQzOCBzZXJ2ZXJzIDwvYj5vdmVyIHRoZSB0
b3AgNDEwLDgwMyBBbGV4YSAoMC4zNSUpIHRoYXQgcmVwbHkgU1lOL0FDSyYjNDM7MTExIHRvIGEg
U1lOJiM0MzsxMTEgKGF0dGFjaGVkIHRoZSBsaXN0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25seSA8Yj4zIHNlcnZlcnMgPC9iPigwLjAw
MDclKSByZXBseSBTWU4vQUNLJiM0MzsxMDEgdG8gYSBTWU4mIzQzOzExMTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGVzdF9zeW5hY2s7MjAw
LjEyLjE3MS41Mzs4MDtlY3Q7MDtmbGFnczszMzg8YnI+DQp0ZXN0X3N5bmFjazs2MC4yOC4yMjAu
MTM0OzgwO2VjdDswO2ZsYWdzOzMzODxicj4NCnRlc3Rfc3luYWNrOzIwMC4xMi4xNzEuNTI7ODA7
ZWN0OzA7ZmxhZ3M7MzM4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkxldCBtZSBrbm93IGlmIEkgY2FuIGhlbHAgeW91IHdpdGggc29tZXRoaW5n
IGVsc2UhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4yMDE4LTA3LTE3IDEzOjI2IEdNVCYjNDM7MDI6MDAgQm9iIEJyaXNjb2Ug
Jmx0OzxhIGhyZWY9Im1haWx0bzpyZXNlYXJjaEBib2JicmlzY29lLm5ldCIgdGFyZ2V0PSJfYmxh
bmsiPnJlc2VhcmNoQGJvYmJyaXNjb2UubmV0PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo
dDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5Bbm5hLDxicj4NCjxicj4NCkNvdWxkIHlvdSBkbyBtZSBhIGZhdm91ciBhbmQgbG9vayB1cCBo
b3cgbWFueSBzZXJ2ZXJzIHJlc3BvbmRlZCB0byBhbiBBY2NFQ04gKDExMSkgU1lOIHdpdGggYSBT
WU4vQUNLIGNhcnJ5aW5nIHJlc3BlY3RpdmVseSAnTm9uY2UnICgxMDEpIG9yICdCcm9rZW4nICgx
MTEpPzxicj4NCjxicj4NCkFuZCBhbHNvIHRoZSB0b3RhbCBudW1iZXIgb2YgdGVzdHMgc2VudCB3
aXRoIGFuIEFjY0VDTiBTWU4sIHNvIEkgY2FuIGdpdmUgcHJvcG9ydGlvbnMgaW4gdGhlIEFjY0VD
TiBkcmFmdC48YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2IgKHRv
byBsYXp5IHRvIGxvb2sgYXQgdGhlIGRhdGEgbXlzZWxmKTxzcGFuIHN0eWxlPSJjb2xvcjojODg4
ODg4Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0KPHNw
YW4gY2xhc3M9ImhvZW56YiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpi
Ij5Cb2IgQnJpc2NvZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iIHRhcmdldD0iX2JsYW5r
Ij5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBj
bGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFOTkEgTUFSSUEgTUFOREFMQVJJIDxicj4NClVuaXZlcnNpZGFkIENhcmxvcyBJ
SUkgZGUgTWFkcmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_VI1PR07MB0880A7BF3FCC4FBC31E81D6093530VI1PR07MB0880eurp_--


From nobody Wed Jul 18 10:50:35 2018
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 78EE7130F96 for ; Wed, 18 Jul 2018 10:50:25 -0700 (PDT)
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_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 w2s35OaeQ_tW for ; Wed, 18 Jul 2018 10:50:22 -0700 (PDT)
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 9F00D130E32 for ; Wed, 18 Jul 2018 10:50:21 -0700 (PDT)
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=Ss3tabiJNFAB81+xsJoZZhqkV6RDXLiAR8wc/0D7UVk=; b=T/Hxbw5udQu4P/lTRxnV+R6jL cVTRXm2e1Lu3kcXNZVKebYiYJLCUV36NqK6MqqczH7PV3e740nlnNbPue0Qqz4KqJrT8ZRUdZktZs du3Un17dRspQKL1NcdDnCUVrvvBeNgIgTy47sd+7RG68wZFqHPylQMxkhOyhVna7mB9ayO1jXmIjF BouhabhKEAutxxPqLYbEtUjRvdrm2c+yMtJXn3suJMdHCqOHOReczT++EEtm3L0Y8PBVPcts+e7y7 QPekmBFaG05Pznd0DEbj1uDNH4a06OX2i6ei1UWEROVbFFBlZYr6XIl3e9yHRMcXne1kgizG9YAH4 gqxSk2P5g==;
Received: from dhcp-94a4.meeting.ietf.org ([31.133.148.164]:46006) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffqah-0002Py-Jy; Wed, 18 Jul 2018 18:50:19 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" 
Cc: tcpm IETF list 
References:   
From: Bob Briscoe 
Message-ID: <8b8363c9-aca2-3888-58f8-dc1a9bb88b02@bobbriscoe.net>
Date: Wed, 18 Jul 2018 13:50:18 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0CC9A9F4B7F267C02D6EF741"
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] Fwd: Re: Data on 'Nonce' and 'Broken' responses to AccECN SYN?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 18 Jul 2018 17:50:31 -0000

This is a multi-part message in MIME format.
--------------0CC9A9F4B7F267C02D6EF741
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

I agree. Also, even tho 'broken' is not currently any use, it might be 
one day.

So we should reserve both the nonce and broken patterns on the SYN-ACK 
(in response to 111 on the SYN) for future AccECN use. They have to be 
solely for AccECN use, cos the SYN is still saying "I support AccECN".


We can add a RESVD tag in table 2, and explain in the notes underneath.


Bob

On 18/07/18 09:24, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> Interesting. So what prevents us from reserving the nonce pattern for 
> future use?
>
> Michael
>
> *From:*tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Bob Briscoe
> *Sent:* Wednesday, July 18, 2018 1:41 PM
> *To:* Michael Scharf 
> *Cc:* ANNA MARIA MANDALARI ; tcpm IETF list 
> 
> *Subject:* [tcpm] Fwd: Re: Data on 'Nonce' and 'Broken' responses to 
> AccECN SYN?
>
> Michael,
>
>
> Below is data from 410,803 of the Alexa top 500k web server that 
> confirms what I said in the presentation about space for future 
> evolution of AccECN:
>
>   * the nonce pattern on the SYN-ACK could be reused now (0.0007%)
>   * the broken reflection pattern is still far too prevalent to re-use
>     it (0.35%).
>
> If anyone wants the list of broken servers that Anna attached for me, 
> pls ask.
> The whole dataset is also available via: 
> http://www.it.uc3m.es/amandala/ecn++/ 
> 
>
> @Anna, thanks v much for responding so quickly - it was me that hadn't 
> read your email in time for the talk.
>
>
>
> Bob
>
> -------- Forwarded Message --------
>
> *Subject: *
>
> 	
>
> Re: Data on 'Nonce' and 'Broken' responses to AccECN SYN?
>
> *Date: *
>
> 	
>
> Tue, 17 Jul 2018 15:42:10 +0200
>
> *From: *
>
> 	
>
> ANNA MARIA MANDALARI  
>
> *To: *
>
> 	
>
> Bob Briscoe  
>
> Hi Bob,
>
> I had a look at the data and I found *1,438 servers *over the top 
> 410,803 Alexa (0.35%) that reply SYN/ACK+111 to a SYN+111 (attached 
> the list).
>
> Only *3 servers *(0.0007%) reply SYN/ACK+101 to a SYN+111:
>
> test_synack;200.12.171.53;80;ect;0;flags;338
> test_synack;60.28.220.134;80;ect;0;flags;338
> test_synack;200.12.171.52;80;ect;0;flags;338
>
> Let me know if I can help you with something else!
>
> 2018-07-17 13:26 GMT+02:00 Bob Briscoe  >:
>
>     Anna,
>
>     Could you do me a favour and look up how many servers responded to
>     an AccECN (111) SYN with a SYN/ACK carrying respectively 'Nonce'
>     (101) or 'Broken' (111)?
>
>     And also the total number of tests sent with an AccECN SYN, so I
>     can give proportions in the AccECN draft.
>
>     Cheers
>
>
>
>     Bob (too lazy to look at the data myself)
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoe http://bobbriscoe.net/
>
>
>
>
> -- 
>
> ANNA MARIA MANDALARI
> Universidad Carlos III de Madrid
>

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


--------------0CC9A9F4B7F267C02D6EF741
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    I agree. Also, even tho 'broken' is not currently any use, it might
    be one day.

    

    So we should reserve both the nonce and broken patterns on the
    SYN-ACK (in response to 111 on the SYN) for future AccECN use. They
    have to be solely for AccECN use, cos the SYN is still saying "I
    support AccECN".

    

    

    We can add a RESVD tag in table 2, and explain in the notes
    underneath.

    

    

    Bob

    

    
On 18/07/18 09:24, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      
      
      
      

        
Interesting. So what prevents us from
          reserving the nonce pattern for future use?

        
 

        
Michael

        
 

        
 

        

          

            

              
From: tcpm
                  [mailto:tcpm-bounces@ietf.org]
                  On Behalf Of Bob Briscoe

                  Sent: Wednesday, July 18, 2018 1:41 PM

                  To: Michael Scharf
                  <michael.scharf@gmail.com>

                  Cc: ANNA MARIA MANDALARI
                  <amandala@it.uc3m.es>; tcpm IETF list
                  <tcpm@ietf.org>

                  Subject: [tcpm] Fwd: Re: Data on 'Nonce' and
                  'Broken' responses to AccECN SYN?

            

          

          
 

          
Michael,

          

            


              Below is data from 410,803 of the Alexa top 500k web
              server that confirms what I said in the presentation about
              space for future evolution of AccECN:

            
    
              
  • 
                the nonce pattern on the SYN-ACK could be reused now
                (0.0007%)
    • 
              
  • 
                the broken reflection pattern is still far too prevalent
                to re-use it (0.35%).
    • 
            

            
If anyone wants the list of broken
              servers that Anna attached for me, pls ask.

              The whole dataset is also available via: 
                http://www.it.uc3m.es/amandala/ecn++/

              

              @Anna, thanks v much for responding so quickly - it was me
              that hadn't read your email in time for the talk.

              

              

              

              Bob

              

              -------- Forwarded Message -------- 

            

              
                

                  
                    
Subject: 

                  		
                  
                    
Re: Data on 'Nonce' and
                      'Broken' responses to AccECN SYN?

                  		
                

                

                  
                    
Date: 

                  		
                  
                    
Tue, 17 Jul 2018 15:42:10 +0200

                  		
                

                

                  
                    
From: 

                  		
                  
                    
ANNA MARIA MANDALARI <amandala@it.uc3m.es>

                  		
                

                

                  
                    
To: 

                  		
                  
                    
Bob Briscoe <research@bobbriscoe.net>

                  		
                

              
            

            
 

            

              

                
Hi Bob,

              

              

                
 

              

              

                
I had a look at the data and I
                  found 1,438 servers over the top 410,803
                  Alexa (0.35%) that reply SYN/ACK+111 to a SYN+111
                  (attached the list).

              

              

                
 

              

              

                
Only 3 servers (0.0007%)
                  reply SYN/ACK+101 to a SYN+111:

              

              

                
 

              

              

                
test_synack;200.12.171.53;80;ect;0;flags;338

                  test_synack;60.28.220.134;80;ect;0;flags;338

                  test_synack;200.12.171.52;80;ect;0;flags;338

              

              

                
 

              

              

                
Let me know if I can help you with
                  something else!

              

              

                
 

              

              

                
 

              

              

                
 

              

              

                
 

              

              

                
 

              

            

            

              
 

              

                
2018-07-17 13:26 GMT+02:00 Bob
                  Briscoe <research@bobbriscoe.net>:

                

                  
Anna,

                    

                    Could you do me a favour and look up how many
                    servers responded to an AccECN (111) SYN with a
                    SYN/ACK carrying respectively 'Nonce' (101) or
                    'Broken' (111)?

                    

                    And also the total number of tests sent with an
                    AccECN SYN, so I can give proportions in the AccECN
                    draft.

                    

                    Cheers

                    

                    

                    

                    Bob (too lazy to look at the data myself)

                      

                      -- 

                      ________________________________________________________________

                      Bob Briscoe                 
                                     http://bobbriscoe.net/

                

              

              


                

                

                -- 

              

                
ANNA MARIA MANDALARI 

                  Universidad Carlos III de Madrid

              

            

          

        

      

    

    

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

  


--------------0CC9A9F4B7F267C02D6EF741--


From nobody Thu Jul 19 19:08:24 2018
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 CD2A9130FBB; Thu, 19 Jul 2018 19:08:14 -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.82.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <153205249475.10524.3203455937828579531@ietfa.amsl.com>
Date: Thu, 19 Jul 2018 19:08:14 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-10.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 02:08:20 -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 Extended Data Offset Option
        Authors         : Joe Touch
                          Wesley M. Eddy
	Filename        : draft-ietf-tcpm-tcp-edo-10.txt
	Pages           : 23
	Date            : 2018-07-19

Abstract:
   TCP segments include a Data Offset field to indicate space for TCP
   options but the size of the field can limit the space available for
   complex options such as SACK and Multipath TCP and can limit the
   combination of such options supported in a single connection. This
   document updates RFC 793 with an optional TCP extension to that
   space to support the use of multiple large options. It also explains
   why the initial SYN of a connection cannot be extending a single
   segment.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-10
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-10


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Jul 21 11:42:35 2018
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 6AD58130E15; Sat, 21 Jul 2018 11:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.447
X-Spam-Level: 
X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mbPWEzKNjDDP; Sat, 21 Jul 2018 11:42:30 -0700 (PDT)
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 5AFC7130E0A; Sat, 21 Jul 2018 11:42:29 -0700 (PDT)
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:To:Subject: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=fIxGu5dWJ/IRU/Yg2FMqUFwgImzhGmmF/j5GsRRSW0I=; b=yHQ6xXOStInlOoW4zYUSZ14V2 EJgEMgocl1CIHrjVsY+xQg0j495DoSgwaBUE603k/nCpN/KfWibvkuARG2e2fVE+R5VrSwOrCQjW/ sQje/f49SkmnroljTv7Cw7KKvt6/nKELKARWa8uB9MWh3cDrcKqVwuKE0hfnSKo0rkavR7J7WLD4w eRSFAnh4KFM6ekKTlToFNLeiHtqlBemZQqBtuaaWKdjHK7eYbfet2pMDOjtwFwkVmtXEJTqA6v2go DJXeG3Z4UBZ4uWAlZbphG1AZhQ2ifnVsTMYPr17VvEXX1oWvSmIwQrF7qxdNZYRkBm7SqBKjxPVrk Rv1QTXAOA==;
Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:48986 helo=[192.168.2.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fgwpm-0007Cp-Fp; Sat, 21 Jul 2018 19:42:27 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" 
References:  <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net>       <2faf9b21-28ba-283c-3bea-8fd3941ccb40@bobbriscoe.net> 
From: Bob Briscoe 
Message-ID: <33f7e9ad-0ac1-77d6-4ec7-77389b1e8536@bobbriscoe.net>
Date: Sat, 21 Jul 2018 12:23:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------82854462158D61EC75C972B4"
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] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 21 Jul 2018 18:42:34 -0000

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

Michael,

There is no past tense in my suggested wording, and no implication that 
5562 is obsolete. Nonetheless, I think you mean that I am saying RFC5562 
is an older experiment than ECN++. Yes, I suggested we say it that way, 
'cos that's a present fact. if anyone wants to read that as meaning that 
ECN++ is aiming to improve on 5562, that's fine 'cos that is also a fact.

I didn't want the AccECN draft to say that ECN++ /does/ improve on 5562, 
because that's a judgement, not a fact.




Bob

PS. Nonetheless, you will see that the ECN++ draft says "Obsoletes: 5562 
(if approved) " in the header block, and it provides very solid 
reasoning for why within the text. So the WG /is/ discussing that 
question, but you are right that it is not discussing that question in 
the context of the AccECN draft.


On 18/07/18 14:12, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> The following wording might work for me:
>
>     It is recommended that the AccECN protocol is implemented alongside
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>     Therefore, this specification does not discuss implementing AccECN alongside
>     [RFC5562], which is an earlier experimental protocol.
>
> As far as I know, the experiment of RFC 5562 has not been officially 
> finished so far, i.e., use of past tense might not be appropriate.
>
> (Personally, I could imagine that TCPM decides to finish the 
> experiment of RFC 5562, but that question does not belong into this I-D.)
>
> Michael
>
> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
> *Sent:* Wednesday, July 18, 2018 12:18 PM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
> ; draft-ietf-tcpm-accurate-ecn@ietf.org; 
> tcpm@ietf.org
> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Michael,
>
> Sorry, I meant to add back in 'Therefore':
>
>     It is recommended that the AccECN protocol is implemented alongside
>     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
> ].
>     Therefore, this specification does not discuss implementing AccECN alongside
>     [RFC5562], which was an earlier experimental protocol with narrower
>     scope than ECN++.
>
>
>
> Bob
>
> On 18/07/18 06:14, Bob Briscoe wrote:
>
>     Michael,
>
>     That regains the problem I said I was trying remove, of risking
>     implying "AccECN could also be combined with RFC5562, but this
>     isn't the place to talk about it?", by not explaining that ECN++
>     subsumes the function of RFC5562. How about:
>
>         It is recommended that the AccECN protocol is implemented alongside
>
>         the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>     ].
>
>         This specification does not discuss implementing AccECN alongside
>
>         [RFC5562], which was an earlier experimental protocol with narrower
>
>         scope than ECN++.
>
>
>
>
>     Bob
>
>     On 17/07/18 17:01, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>         This wording would imply that ECN++ and RFC 5562 are indeed
>         “alternatives”. That is IMHO not fully correct, ECN++ seems to
>         have a broader scope.
>
>         I think something along the lines of …
>
>             It is recommended that the AccECN protocol is implemented alongside
>
>             the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>         ].
>
>             This specification does not discuss implementing AccECN
>
>             alongside the experimental protocol [RFC5562].
>
>         …does the job.
>
>         Michael
>
>         *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>         *Sent:* Tuesday, July 17, 2018 10:28 PM
>         *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>          ;
>         draft-ietf-tcpm-accurate-ecn@ietf.org
>         ; tcpm@ietf.org
>         
>         *Subject:* Re: [tcpm] Further comments on
>         draft-ietf-tcpm-accurate-ecn
>
>         Michael,
>
>         OK RECOMMENDED -> recommended.
>         That's good, otherwise I think ECN++ would have become a
>         normative reference.
>
>
>
>             Alternatively, a more statement not related to the status
>             would be “a combination of AccECN with RFC 5562 is outside
>             the scope of this document”.
>
>         Someone who had never even thought about combining AccECN with
>         RFC5562 might think we mean "AccECN could also be combined
>         with RFC5562, but this isn't the place to talk about it?"
>
>         How about:
>
>             It is recommended that the AccECN protocol is implemented alongside
>
>             the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>         ].
>
>             Therefore, this specification does not discuss implementing AccECN
>
>             alongside the earlier experimental alternative to ECN++ in [RFC5562].
>
>
>
>
>
>         Bob
>
>         On 17/07/18 08:57, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
>             I would prefer the first, shorter wording.
>
>             For instance, it would be possible that TCPM decides to
>             obsolete RFC 5562. I’d suggest to keep the status and
>             future use of RFC 5562 in combination with ECN++ outside
>             of this document.
>
>             What might be in scope of the AccECN spec would be a
>             hypothetical use of AccECN in combination with RFC 5562.
>             But I would be fine with just omitting that.
>             Alternatively, a more statement not related to the status
>             would be “a combination of AccECN with RFC 5562 is outside
>             the scope of this document”.
>
>             Actually, I am also not sure if this paragraph is a good
>             example for RECOMMENDED in a capital letters. To me, the
>             following would be sufficient:
>
>                 It is recommended that the AccECN protocol is implemented along with
>
>                 the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>             ].
>
>             Michael
>
>             *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>             *Sent:* Tuesday, July 17, 2018 2:43 PM
>             *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>             
>             ;
>             draft-ietf-tcpm-accurate-ecn@ietf.org
>             ;
>             tcpm@ietf.org 
>             *Subject:* Re: [tcpm] Further comments on
>             draft-ietf-tcpm-accurate-ecn
>
>             Michael,
>
>             I've written the proposed edits into a local copy of
>             draft-08, which we'll post after this IETF.
>
>             Wile writing the last point, I thought it best to add an
>             extra sentence.
>
>                 It is RECOMMENDED that the AccECN protocol is implemented along with
>
>                 the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>             ].
>
>                 [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
>
>                 experimental scheme [RFC5562] so there is no need to implement RFC
>
>                 5562 along with AccECN.
>
>               
>
>
>
>             Bob
>
>             On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart)
>             wrote:
>
>                 This would for for me.
>
>                 Thanks
>
>                 Michael
>
>                 *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net]
>                 *Sent:* Tuesday, July 17, 2018 1:34 AM
>                 *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>                 
>                 ;
>                 draft-ietf-tcpm-accurate-ecn@ietf.org
>                 ;
>                 tcpm@ietf.org 
>                 *Subject:* Re: [tcpm] Further comments on
>                 draft-ietf-tcpm-accurate-ecn
>
>                 Michael,
>
>                 On 15/07/18 16:54, Scharf, Michael (Nokia -
>                 DE/Stuttgart) wrote:
>
>                     Hi all,
>
>                       
>
>                     While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
>
>                       
>
>                       
>
>                     Section 1. Introduction
>
>                       
>
>                         It is likely (but not required) that the AccECN protocol will be
>
>                         implemented along with the following experimental additions to the
>
>                         TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>                         [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
>
>                         ACK experiment [RFC5562]; and testing receiver non-compliance
>
>                         [I-D.moncaster-tcpm-rcv-cheat].
>
>                       
>
>                     [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?
>
>
>                 I agree. For ECN++, I think something like your
>                 suggestion of "useful", or even RECOMMENDED is what is
>                 needed here. I think the testing receiver compliance
>                 one could be removed from the intro. It's mentioned
>                 under testing for unexpected interference and under
>                 integrity checking, which are sufficient.
>
>                 Also, this makes me notice that the word "includes" is
>                 wrong. ECN++ intends to obsolete RFC5562, but I don't
>                 think we need to mention that here (cos it might
>                 change before ECN++ gets published).
>
>                 CURRENT TEXT:
>
>                     It is likely (but not required) that the AccECN protocol will be
>
>                     implemented along with the following experimental additions to the
>
>                     TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
>
>                     [I-D.ietf-tcpm-generalized-ecn
>                 ], which includes the ECN-capable SYN/
>
>                     ACK experiment [RFC5562 ]; and testing receiver non-compliance
>
>                     [I-D.moncaster-tcpm-rcv-cheat
>                 ].
>
>                 PROPOSED TEXT:
>
>                     It is RECOMMENDED that the AccECN protocol is implemented along with
>
>                     the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn
>                 ].
>
>
>
>
>
>
>                       
>
>                       
>
>                       
>
>                     Section 2.1.  Capability Negotiation
>
>                         
>
>                         The TCP server sends the AccECN
>
>                         Option on the SYN/ACK and the client sends it on the first ACK to
>
>                         test whether the network path forwards the option correctly.
>
>                       
>
>                     [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
>
>                 OK, we need to review section 2, to ensure it is
>                 consistent with changes that have been made in the
>                 normative section 3 since it was written.
>
>                 In this particular case, we already promised to check
>                 (offlist with an implementer) that there was no text
>                 that contradicted the optionality of the option stated
>                 at the end of Section 3.2.6.
>
>                 I have already started this with a list I prepared
>                 (also offlist) of which middlebox checking sections an
>                 implementer could ignore if they were only reading but
>                 not sending the TCP options.
>
>
>
>
>                 Bob
>
>
>
>
>
>
>                 -- 
>
>                 ________________________________________________________________
>
>                 Bob Briscoehttp://bobbriscoe.net/
>
>
>
>
>
>             -- 
>
>             ________________________________________________________________
>
>             Bob Briscoehttp://bobbriscoe.net/
>
>
>
>
>         -- 
>
>         ________________________________________________________________
>
>         Bob Briscoehttp://bobbriscoe.net/
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoehttp://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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


--------------82854462158D61EC75C972B4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    There is no past tense in my suggested wording, and no implication
    that 5562 is obsolete. Nonetheless, I think you mean that I am
    saying RFC5562 is an older experiment than ECN++. Yes, I suggested
    we say it that way, 'cos that's a present fact. if anyone wants to
    read that as meaning that ECN++ is aiming to improve on 5562, that's
    fine 'cos that is also a fact. 

    

    I didn't want the AccECN draft to say that ECN++ /does/ improve on
    5562, because that's a judgement, not a fact.

    

    

    

    

    Bob

    

    PS. Nonetheless, you will see that the ECN++ draft says "Obsoletes:
    5562 (if approved) " in the header block, and it provides very solid
    reasoning for why within the text. So the WG /is/ discussing that
    question, but you are right that it is not discussing that question
    in the context of the AccECN draft.

    

    

    
On 18/07/18 14:12, Scharf, Michael
      (Nokia - DE/Stuttgart) wrote:

    

    

      
      
      
      

        
The following
          wording might work for me:

        
   It is recommended that the AccECN protocol is implemented alongside

        
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

        
   Therefore, this specification does not discuss implementing AccECN alongside

        
   [RFC5562], which is an earlier experimental protocol.

        
 

        
As far as I
            know, the experiment of RFC 5562 has not been officially
            finished so far, i.e., use of past tense might not be
            appropriate.

        
 

        
(Personally,
            I could imagine that TCPM decides to finish the experiment
            of RFC 5562, but that question does not belong into this
            I-D.)

        
 

        
Michael

        
 

        
 

        

          

            

              
From: Bob Briscoe
                  [mailto:ietf@bobbriscoe.net]
                  

                  Sent: Wednesday, July 18, 2018 12:18 PM

                  To: Scharf, Michael (Nokia - DE/Stuttgart)
                  <michael.scharf@nokia.com>;
                  draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org

                  Subject: Re: [tcpm] Further comments on
                  draft-ietf-tcpm-accurate-ecn

            

          

          
 

          
Michael,

            

            Sorry, I meant to add back in 'Therefore':

          
   It is recommended that the AccECN protocol is implemented alongside

          
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

          
   Therefore, this specification does not discuss implementing AccECN alongside

          
   [RFC5562], which was an earlier experimental protocol with narrower

          
   scope than ECN++.

          


            

            Bob

          

            
On 18/07/18 06:14, Bob Briscoe wrote:

          

          

            
Michael,

              

              That regains the problem I said I was trying remove, of
              risking implying "AccECN could also be combined with
              RFC5562, but this isn't the place to talk about it?", by
              not explaining that ECN++ subsumes the function of
              RFC5562. How about:

            
   It is recommended that the AccECN protocol is implemented alongside

            
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

            
   This specification does not discuss implementing AccECN alongside

            
   [RFC5562], which was an earlier experimental protocol with narrower

            
   scope than ECN++.

            


              

              

              Bob

            

              
On 17/07/18 17:01, Scharf, Michael
                (Nokia - DE/Stuttgart) wrote:

            

            

              
This
                  wording would imply that ECN++ and RFC 5562 are indeed
                “alternatives”. That is IMHO not fully
                  correct, ECN++ seems to have a broader scope.

              
 

              
I
                  think something along the lines of
                …

              
 

              
   It is recommended that the AccECN protocol is implemented alongside

              
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

              
   This specification does not discuss implementing AccECN 

              
   alongside the experimental protocol [RFC5562].

              
 

              
… does
                  the job.

              
 

              
Michael

              
 

              
 

              
 

              

                

                  

                    
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                        

                        Sent: Tuesday, July 17, 2018 10:28 PM

                        To: Scharf, Michael (Nokia -
                        DE/Stuttgart) <michael.scharf@nokia.com>;
                      draft-ietf-tcpm-accurate-ecn@ietf.org;
                      tcpm@ietf.org

                        Subject: Re: [tcpm] Further comments on
                        draft-ietf-tcpm-accurate-ecn

                  

                

                
 

                
Michael,

                  

                  OK RECOMMENDED -> recommended.

                  That's good, otherwise I think ECN++ would have become
                  a normative reference.

                  

                  

                  

                  

                

                  
Alternatively,
                      a more statement not related to the status would
                      be
                    “a combination
                      of AccECN with RFC 5562 is outside the scope of
                      this document”.

                

                
Someone who had never even thought
                  about combining AccECN with RFC5562 might think we
                  mean "AccECN could also be combined with RFC5562, but
                  this isn't the place to talk about it?"
                  

                  

                  How about:

                
   It is recommended that the AccECN protocol is implemented alongside

                
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

                
   Therefore, this specification does not discuss implementing AccECN 

                
   alongside the earlier experimental alternative to ECN++ in [RFC5562].

                


                  

                  

                  

                  Bob

                

                  
On 17/07/18 08:57, Scharf,
                    Michael (Nokia - DE/Stuttgart) wrote:

                

                

                  
I
                      would prefer the first, shorter wording.

                  
 

                  
For
                      instance, it would be possible that TCPM decides
                      to obsolete RFC 5562. I’d suggest to keep the
                      status and future use of RFC 5562 in combination
                      with ECN++ outside of this document.

                  
 

                  
What
                      might be in scope of the AccECN spec would be a
                      hypothetical use of AccECN in combination with RFC
                      5562. But I would be fine with just omitting that.
                      Alternatively, a more statement not related to the
                      status would be “a combination of AccECN
                      with RFC 5562 is outside the scope of this
                      document”.

                  
 

                  
Actually,
                      I am also not sure if this paragraph is a good
                      example for RECOMMENDED in a capital letters. To
                      me, the following would be sufficient:

                  
 

                  
   It is recommended that the AccECN protocol is implemented along with

                  
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

                  
 

                  
Michael

                  
 

                  

                    

                      

                        
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                            

                            Sent: Tuesday, July 17, 2018 2:43 PM

                            To: Scharf, Michael (Nokia -
                            DE/Stuttgart) <michael.scharf@nokia.com>;
                          draft-ietf-tcpm-accurate-ecn@ietf.org;
                          tcpm@ietf.org

                            Subject: Re: [tcpm] Further comments
                            on draft-ietf-tcpm-accurate-ecn

                      

                    

                    
 

                    
Michael,

                      

                      I've written the proposed edits into a local copy
                      of draft-08, which we'll post after this IETF.

                      

                      Wile writing the last point, I thought it best to
                      add an extra sentence.

                    
   It is RECOMMENDED that the AccECN protocol is implemented along with

                    
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn]. 

                    
   [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another

                    
   experimental scheme [RFC5562] so there is no need to implement RFC

                    
   5562 along with AccECN.

                    
 

                    


                      

                      Bob

                    

                      
On 17/07/18 01:05, Scharf,
                        Michael (Nokia - DE/Stuttgart) wrote:

                    

                    

                      
This would for for
                          me.

                      
 

                      
Thanks

                      
 

                      
Michael

                      
 

                      

                        

                          

                            
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
                                

                                Sent: Tuesday, July 17, 2018 1:34
                                AM

                                To: Scharf, Michael (Nokia -
                                DE/Stuttgart) <michael.scharf@nokia.com>;
                              draft-ietf-tcpm-accurate-ecn@ietf.org;
                              tcpm@ietf.org

                                Subject: Re: [tcpm] Further
                                comments on draft-ietf-tcpm-accurate-ecn

                          

                        

                        
 

                        
Michael,

                        

                          
On 15/07/18 16:54,
                            Scharf, Michael (Nokia - DE/Stuttgart)
                            wrote:

                        

                        

                          
Hi all,

                          
 

                          
While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:

                          
 

                          
 

                          
Section 1. Introduction

                          
 

                          
   It is likely (but not required) that the AccECN protocol will be

                          
   implemented along with the following experimental additions to the

                          
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                          
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                          
   ACK experiment [RFC5562]; and testing receiver non-compliance

                          
   [I-D.moncaster-tcpm-rcv-cheat].

                          
 

                          
[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

                        

                        


                          I agree. For ECN++, I think something like
                          your suggestion of "useful", or even
                          RECOMMENDED is what is needed here. I think
                          the testing receiver compliance one could be
                          removed from the intro. It's mentioned under
                          testing for unexpected interference and under
                          integrity checking, which are sufficient. 

                          

                          Also, this makes me notice that the word
                          "includes" is wrong. ECN++ intends to obsolete
                          RFC5562, but I don't think we need to mention
                          that here (cos it might change before ECN++
                          gets published).

                          

                          CURRENT TEXT:

                        
   It is likely (but not required) that the AccECN protocol will be

                        
   implemented along with the following experimental additions to the

                        
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions

                        
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/

                        
   ACK experiment [RFC5562]; and testing receiver non-compliance

                        
   [I-D.moncaster-tcpm-rcv-cheat].

                        
PROPOSED TEXT:

                        
   It is RECOMMENDED that the AccECN protocol is implemented along with

                        
   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn].

                        


                          

                          

                          

                          

                          

                        

                          
 

                          
 

                          
 

                          
Section 2.1.  Capability Negotiation

                          
   

                          
   The TCP server sends the AccECN

                          
   Option on the SYN/ACK and the client sends it on the first ACK to

                          
   test whether the network path forwards the option correctly.

                          
 

                          
[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.

                        

                        
OK, we need to review
                          section 2, to ensure it is consistent with
                          changes that have been made in the normative
                          section 3 since it was written.

                          

                          In this particular case, we already promised
                          to check (offlist with an implementer) that
                          there was no text that contradicted the
                          optionality of the option stated at the end of
                          Section 3.2.6.

                          

                          I have already started this with a list I
                          prepared (also offlist) of which middlebox
                          checking sections an implementer could ignore
                          if they were only reading but not sending the
                          TCP options.

                          

                          

                          

                          

                          Bob

                          

                          

                          

                          

                          

                          

                          

                        
-- 

                        
________________________________________________________________

                        
Bob Briscoe                               http://bobbriscoe.net/

                      

                    

                    


                      

                      

                      

                      

                    
-- 

                    
________________________________________________________________

                    
Bob Briscoe                               http://bobbriscoe.net/

                  

                

                


                  

                  

                  

                
-- 

                
________________________________________________________________

                
Bob Briscoe                               http://bobbriscoe.net/

              

            

            


              

              

            
-- 

            
________________________________________________________________

            
Bob Briscoe                               http://bobbriscoe.net/

          

          


            

            

          
-- 

          
________________________________________________________________

          
Bob Briscoe                               http://bobbriscoe.net/

        

      

    

    

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

  


--------------82854462158D61EC75C972B4--


From nobody Fri Jul 27 08:22:35 2018
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 CA7BC130F33 for ; Fri, 27 Jul 2018 08:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham 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 Qcyo-nEynLgH for ; Fri, 27 Jul 2018 08:22:30 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B5013130EBD for ; Fri, 27 Jul 2018 08:22:30 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id g141-v6so7850660ita.4 for ; Fri, 27 Jul 2018 08:22:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=NWVcECPYXkG1rmprsueHVtrA2r+bOBC96UGrzpIiVBY=; b=jzFJUWVMVESNPTOiq5+MqZPvgePhyZPGgSOGi/5clhK3JJW1FAoUXugq16SgQUq0V4 ixTIq3TS2u98+vgqDsGU6o7GknDnwBzYATC+IFvSNqVvakUiCcUFs/bDEdqoKmSRHkHE bOrhUoBrRsB4g1RxzhgudQySZql/W/faxOdE/pzDOVJli/ACbkm9DBT5cxCaCcfcSrcO sbmuDarxCaVeDorAugPLnFVzf5X/SHcV02uJs0JN3THITvKrJeQaGyrtS/D35fTKiLCK 1MPIVmkbzv9i8gByIPe+kLKlvZhk7h1IYZImJNE07rIx1B3nx4vnhaJUKhESmbXakU56 wM0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=NWVcECPYXkG1rmprsueHVtrA2r+bOBC96UGrzpIiVBY=; b=oj9zT8sALnusEUe67N8tWgbpZxWnU1h+lrdZvrtdvXYESbmjZyd21bbQinX0HyDPfb 7sqrAqCUjQ6WRHye4oyxL6Vl/hkt4XrBYVrrC5JfiXJebI+bCg3Cx7147HnTAx/J3Y0X TlGDVxLhW19U68XjTzS6cqf55S7AuTptY3Zi5tPHPVPhXuu2o8sWzbYkSEaVDOg9aZY8 WqL7y28azZvxBh6JHTJ1ZCmw1XBGTHdzFqL7XhZFRGZmWeq39hmeRi1R2i2RtmamkcdY caVfDroUNaEL7NdCr76i8LVD8SgUjuNjAaP16RJsnOLCEyx2nbTQN5xAUbLJSdV3+VFh 1oqQ==
X-Gm-Message-State: AOUpUlGEmpnjWav0XH5xosDRag+9tvqcejZS/lHxQYC9X0X9T8frzzay p06kWpguPd7Btak0PZRImerecToFjtk=
X-Google-Smtp-Source: AAOMgpchi0DnruMxFYh3GaOwuCtYDTa1k9/1edlwclCErfetQ6LUahqw+3Bcaqac6SYt6Hu7OH6auQ==
X-Received: by 2002:a24:d80a:: with SMTP id b10-v6mr6082119itg.27.1532704949732;  Fri, 27 Jul 2018 08:22:29 -0700 (PDT)
Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id c12-v6sm1262156ioh.2.2018.07.27.08.22.28 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 08:22:29 -0700 (PDT)
To: tcpm@ietf.org
From: Wesley Eddy 
Message-ID: 
Date: Fri, 27 Jul 2018 11:22:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C0244D80D3EB4B9F0FFAA8DB"
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: references to 2119 keywords
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 15:22:33 -0000

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

In the 793bis draft, some time ago we had included the appendix from 
1122 that has a table of all the places where 2119 keywords are used 
(MUST/SHOULD/MAY/etc).

I'm now updating that so that it:
(1) points to the right section numbers or places within the current 
document rather than 1122
(2) contains references for requirements that came from other documents 
than 1122

There are a few challenges, and I have a proposal.

Instead of carrying forth exactly the prior format where the table 
looked like:

                                                   |        | | | |S| |
                                                   |        | | | |H| |F
                                                   |        | | | |O|M|o
                                                   |        | |S| |U|U|o
                                                   |        | |H| |L|S|t
                                                   |        |M|O| |D|T|n
                                                   |        |U|U|M| | |o
                                                   |        |S|L|A|N|N|t
                                                   |RFC1122 |T|D|Y|O|O|t
  FEATURE                                          |SECTION | | | |T|T|e
  -------------------------------------------------|--------|-|-|-|-|-|--
  Closing Connections                              |        | | | | | |
    Half-duplex close connections                  |4.2.2.13| | |x| | |

I'm suggesting to replace the "RFC1122 SECTION" column with one called 
something like "ID", and then adding an ID tag into the sentence where 
the requirement occurs, which winds up looking like:

                                                   |        | | | |S| |
                                                   |        | | | |H| |F
                                                   |        | | | |O|M|o
                                                   |        | |S| |U|U|o
                                                   |        | |H| |L|S|t
                                                   |        |M|O| |D|T|n
                                                   |        |U|U|M| | |o
                                                   |        |S|L|A|N|N|t
                                                   |        |T|D|Y|O|O|t
  FEATURE                                          |   ID   | | | |T|T|e
  -------------------------------------------------|--------|-|-|-|-|-|--
  Closing Connections                              |        | | | | | |
    Half-duplex close connections                  | MAY-1  | | |x| | |


And then searching the document for "MAY-1", you would find the sentence 
in section 3.5.1:

    A host MAY implement a "half-duplex" TCP close sequence, so that an
    application that has called CLOSE cannot continue to read data from
    the connection (MAY-1).

Subsequent statements would be labelled "MAY-2", "MAY-3", etc.

Before I do this for a large number of these, I thought it would be good 
to solicit feedback from the group. Does this seem like a good idea? Is 
it valuable? Given that XML2RFC "artwork" can't contain "xref" tags, it 
seems easier and less error prone than maintaining section number 
references in that table.



--------------C0244D80D3EB4B9F0FFAA8DB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    In the 793bis draft, some time ago we had included the appendix from
    1122 that has a table of all the places where 2119 keywords are used
    (MUST/SHOULD/MAY/etc).

    

    I'm now updating that so that it:

    (1) points to the right section numbers or places within the current
    document rather than 1122

    (2) contains references for requirements that came from other
    documents than 1122

    

    There are a few challenges, and I have a proposal.

    

    Instead of carrying forth exactly the prior format where the table
    looked like:

    
                                                  |        | | | |S| |
                                                  |        | | | |H| |F
                                                  |        | | | |O|M|o
                                                  |        | |S| |U|U|o
                                                  |        | |H| |L|S|t
                                                  |        |M|O| |D|T|n
                                                  |        |U|U|M| | |o
                                                  |        |S|L|A|N|N|t
                                                  |RFC1122 |T|D|Y|O|O|t
 FEATURE                                          |SECTION | | | |T|T|e
 -------------------------------------------------|--------|-|-|-|-|-|--
 Closing Connections                              |        | | | | | |
   Half-duplex close connections                  |4.2.2.13| | |x| | |



    I'm suggesting to replace the "RFC1122 SECTION" column with one
    called something like "ID", and then adding an ID tag into the
    sentence where the requirement occurs, which winds up looking like:
    
                                                  |        | | | |S| |
                                                  |        | | | |H| |F
                                                  |        | | | |O|M|o
                                                  |        | |S| |U|U|o
                                                  |        | |H| |L|S|t
                                                  |        |M|O| |D|T|n
                                                  |        |U|U|M| | |o
                                                  |        |S|L|A|N|N|t
                                                  |        |T|D|Y|O|O|t
 FEATURE                                          |   ID   | | | |T|T|e
 -------------------------------------------------|--------|-|-|-|-|-|--
 Closing Connections                              |        | | | | | |
   Half-duplex close connections                  | MAY-1  | | |x| | |




    And then searching the document for "MAY-1", you would find the
    sentence in section 3.5.1:

    
   A host MAY implement a "half-duplex" TCP close sequence, so that an
   application that has called CLOSE cannot continue to read data from
   the connection (MAY-1). 

    Subsequent statements would be labelled "MAY-2", "MAY-3", etc.

    

    Before I do this for a large number of these, I thought it would be
    good to solicit feedback from the group. Does this seem like a good
    idea? Is it valuable? Given that XML2RFC "artwork" can't contain
    "xref" tags, it seems easier and less error prone than maintaining
    section number references in that table.

    

    

  


--------------C0244D80D3EB4B9F0FFAA8DB--


From nobody Fri Jul 27 11:27:09 2018
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 BC5CE130EAB for ; Fri, 27 Jul 2018 11:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=aero.org header.b=j80oHoGC; dkim=pass (1024-bit key) header.d=aerospacecloud.onmicrosoft.com header.b=KAIbfH9N
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 1MAbCk0rVsP9 for ; Fri, 27 Jul 2018 11:27:05 -0700 (PDT)
Received: from email3-east.aero.org (email3-east.aero.org [130.221.184.167]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B38130E89 for ; Fri, 27 Jul 2018 11:27:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1532716025; x=1564252025; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sh0AoPn93f1p4l29QEWYXP8vltEsEmkqshV8JGvUjxQ=; b=j80oHoGC1wnJ2ptVL9SwcR70wusTiohtKzaPNYGHszGLT/FXRXgL66/n 7tStwnxhsYb4tIJh5pBpfno4KlyjnhAhHJwNtVdL0o9jqZmuu0aadkbPc F0rfKHYVs8HYiQdWUhO41GDj4fprMfplj+38A26aHpwV+HCDw9xo1YUII U=;
x-SBRS: 3.5
x-SenderGroup: Inbound_Office365
X-IronPort-AV: E=McAfee;i="5900,7806,8967"; a="7224699"
X-IronPort-AV: E=Sophos;i="5.51,410,1526367600";  d="scan'208";a="7224699"
X-IPAS-Result: =?us-ascii?q?A2FhAwAbY1tbhzPGZxdYAxwBAQEEAQEKAQGCelGBUwMECyg?= =?us-ascii?q?KjFmLFHGBY5Z1Axg7CywCgSgBgxUCgx03FQECAQEBAQEBAgICEAEBAQgNCQgpI?= =?us-ascii?q?wELgzM4MgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCODg?= =?us-ascii?q?BAQEBA0ABATgPAgEIEQQBAS8yHQgCBBMIgxiBaAMVAaMKAooFghyCdAEBBYQcG?= =?us-ascii?q?IMXCIl9gRyBEUaCTIR9Ah8mgmuCJIdVIYUDLYxnBwKQfocKhTSSDQIEAgQFAg0?= =?us-ascii?q?BAQWBV4F1TTCDLIIZGoNOilJvAYEVjSEBgRoBAQ?=
Received: from mail-dm2gcc01lp0051.outbound.protection.outlook.com (HELO GCC01-DM2-obe.outbound.protection.outlook.com) ([23.103.198.51]) by email3-east.aero.org with ESMTP/TLS/AES256-GCM-SHA384; 27 Jul 2018 11:27:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerospacecloud.onmicrosoft.com; s=selector1-aero-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mvC4drxS7PH8UsAfuGJ+4C7Plg2WiGI6Kp7pOMam9+g=; b=KAIbfH9NLXqLTVtkkaqP7l0ZOl3XCyyUR8UKVcXuYYOLTEgjR8ti2y0ksQBURGufyDDakkgSFD1fKchYBoV3OmnFmTvlfieWVSSxIl/7DDv+EoyOCuK0eV3aKEdGMYKL0ejSlC5b+MgwnxfjX97dyhjBOH4zwYZ38InNTx9y4HQ=
Received: from DM5PR09MB1306.namprd09.prod.outlook.com (10.172.34.140) by DM5PR09MB1306.namprd09.prod.outlook.com (10.172.34.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.16; Fri, 27 Jul 2018 18:27:02 +0000
Received: from DM5PR09MB1306.namprd09.prod.outlook.com ([fe80::71e8:93fa:3890:ee1b]) by DM5PR09MB1306.namprd09.prod.outlook.com ([fe80::71e8:93fa:3890:ee1b%10]) with mapi id 15.20.0995.014; Fri, 27 Jul 2018 18:27:02 +0000
From: Theodore V Faber 
To: "tcpm@ietf.org" 
Thread-Topic: [tcpm] 793bis: references to 2119 keywords
Thread-Index: AQHUJb3AZcvqtcaKeEKeVXTxXlQ6xqSjYuhI
Date: Fri, 27 Jul 2018 18:27:02 +0000
Message-ID: 
References: 
In-Reply-To: 
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=theodore.v.faber@aero.org; 
x-originating-ip: [130.221.224.7]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR09MB1306; 6:0C0JSZeU6887JuA4hqQqCRkuePd2bZSg71UrCeGJy0CaVjqgjYmP78hu/2tgysNV/GDbyMhWJVC3WwfYGgJPxcgvhzBJdzWCOYP+AnaVZX7gN1o1VIQ/gu3ayBqoued968HSaq9fLu3oZoIowvReBzkM71FG1vZW0oOKAbIyNKMMQLmV2fsGCYNz5V/sQA6gDavlsKHRhXZfwVBh0MkyR0GSVysWkIu5WqteNzjwhiNC1n9AJJgqWJuOGXas9JwY97sFvnzA4hwLZJDMjrbTB0jordjLP/WHIX2H1upgS/MoqYDxIsQhdd9upZ6lR62yA/DrFUGzkHRiHhbtA+BryugN7K/Q+1IqbdFV+7hjaaexppANK+1/0/A+QP6nHk7nY/jIP14Nhpdlund4JDp645t6c5bFJObzY0soWqot+cmRVDh3ZLueNUv+UZQt8wzM8dLM6eIk+MdVC3xgkHwyLQ==; 5:ldsaUMUBDJmh82bvpi2k9xuH2un4Kl6GLotrrEG2yMJTZ7L2CJS2jOs9suSnauiBgKtu6tiSyiWDVIbZeQRHLHoptX7TvJqIYY071DtBYEh7g465YDnm0/+hni9u7B1wInYIhz46NyiyLCyORNgG55jO0QT2ckh+J8p+6lM3f9c=; 7:JeVcoHrIIG1Jh2GZgGSo1YiBZ0vrv5sMURU81z11/Xt0uFDa96BQk78dZubBE+Aoq7REU/s1obbvgBvTtQxF6oimJkyKuhJ/PA1nUUPiK+GnHtI8Cyihf+67WQeefCcFlyJYHrUA/rmWgepiCHPCF5HqQmpTrU95au9ObL9vyDjEiad61TJihOIt3nr2hKJOw8fGtJ/AOQrYnhLEpzFLFiBleKXxe9uLhsL/gcrLfGKtZ84A3e2zRNlyliFGwNCT
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f17dcc51-aaa7-4d89-3d8d-08d5f3ee8c77
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR09MB1306; 
x-ms-traffictypediagnostic: DM5PR09MB1306:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(788757137089);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR09MB1306; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1306; 
x-forefront-prvs: 07467C4D33
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(366004)(396003)(39860400002)(199004)(189003)(1730700003)(2906002)(97736004)(8676002)(68736007)(2900100001)(81156014)(5250100002)(2501003)(6116002)(74316002)(7736002)(3846002)(81166006)(305945005)(256004)(6246003)(14444005)(25786009)(5660300001)(561944003)(9686003)(86362001)(55016002)(102836004)(53546011)(33656002)(6506007)(53936002)(229853002)(14454004)(446003)(486006)(26005)(186003)(6436002)(11346002)(66066001)(476003)(5640700003)(478600001)(8936002)(105586002)(76176011)(7696005)(99286004)(106356001)(6916009)(316002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR09MB1306; H:DM5PR09MB1306.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
x-microsoft-antispam-message-info: WpT0paE7AYGU/wOeCJUxORy7jxUa5aQC0kTpdDKSiVi5elAQIWtVqX/vz/J+CZBEY/3RnrjiE7KuMksVPKRoI98bIbn38VQrYm7Yi2UWOm4Y4hJU0ODAgdPazlQ4eSUTGxSLt8CKxRkrerV5mrtR1MdduDk6btFopfe600bBSh0xyKJDduCCjGPzaGFP+wvMEDO9/3umxD+2LBEgswtgyke7uv98FMw2eujmHN0tmxgqAndLbS9HAElnVFOQEJkuzMPBDbeNsxfsA4XLh0Js5rQ6pyW98iocS0FqZT/dJ+5eveDfkUk4XE3+h9BDp8niaMIzIxRIPNkHO6ryOWrRKkIph/IAnGhBQ8e7tUMdSx8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: aero.org
X-MS-Exchange-CrossTenant-Network-Message-Id: f17dcc51-aaa7-4d89-3d8d-08d5f3ee8c77
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 18:27:02.5465 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1306
Archived-At: 
Subject: Re: [tcpm] 793bis: references to 2119 keywords
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 18:27:08 -0000

That seems like a sound idea to me.

I suggest using some abbreviation other than "ID" to avoid confusion with "=
I-D" (Internet-Draft).  "Marker", maybe?

--
Ted Faber 
Senior Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373


________________________________________
From: tcpm  on behalf of Wesley Eddy 
Sent: Friday, July 27, 2018 08:22
To: tcpm@ietf.org
Subject: [tcpm] 793bis: references to 2119 keywords

In the 793bis draft, some time ago we had included the appendix from 1122 t=
hat has a table of all the places where 2119 keywords are used (MUST/SHOULD=
/MAY/etc).

I'm now updating that so that it:
(1) points to the right section numbers or places within the current docume=
nt rather than 1122
(2) contains references for requirements that came from other documents tha=
n 1122

There are a few challenges, and I have a proposal.

Instead of carrying forth exactly the prior format where the table looked l=
ike:

                                                  |        | | | |S| |
                                                  |        | | | |H| |F
                                                  |        | | | |O|M|o
                                                  |        | |S| |U|U|o
                                                  |        | |H| |L|S|t
                                                  |        |M|O| |D|T|n
                                                  |        |U|U|M| | |o
                                                  |        |S|L|A|N|N|t
                                                  |RFC1122 |T|D|Y|O|O|t
 FEATURE                                          |SECTION | | | |T|T|e
 -------------------------------------------------|--------|-|-|-|-|-|--
 Closing Connections                              |        | | | | | |
   Half-duplex close connections                  |4.2.2.13| | |x| | |



I'm suggesting to replace the "RFC1122 SECTION" column with one called some=
thing like "ID", and then adding an ID tag into the sentence where the requ=
irement occurs, which winds up looking like:

                                                  |        | | | |S| |
                                                  |        | | | |H| |F
                                                  |        | | | |O|M|o
                                                  |        | |S| |U|U|o
                                                  |        | |H| |L|S|t
                                                  |        |M|O| |D|T|n
                                                  |        |U|U|M| | |o
                                                  |        |S|L|A|N|N|t
                                                  |        |T|D|Y|O|O|t
 FEATURE                                          |   ID   | | | |T|T|e
 -------------------------------------------------|--------|-|-|-|-|-|--
 Closing Connections                              |        | | | | | |
   Half-duplex close connections                  | MAY-1  | | |x| | |




And then searching the document for "MAY-1", you would find the sentence in=
 section 3.5.1:

   A host MAY implement a "half-duplex" TCP close sequence, so that an
   application that has called CLOSE cannot continue to read data from
   the connection (MAY-1).

Subsequent statements would be labelled "MAY-2", "MAY-3", etc.

Before I do this for a large number of these, I thought it would be good to=
 solicit feedback from the group. Does this seem like a good idea? Is it va=
luable? Given that XML2RFC "artwork" can't contain "xref" tags, it seems ea=
sier and less error prone than maintaining section number references in tha=
t table.