From nobody Fri Mar 1 13:11:05 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7351F130EFE; Fri, 1 Mar 2019 13:09:57 -0800 (PST) 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.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147459746.6101.9870419298113616686.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:09:57 -0800 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 104 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:09:58 -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:00 requested) Monday, 25 March 2019, Afternoon Session I 1350-1550 Room Name: Grand Ballroom size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/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 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas detnet 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 Mar 3 15:48:26 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2F7124BF6 for ; Sun, 3 Mar 2019 15:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOW2x-MV4p80 for ; Sun, 3 Mar 2019 15:48:22 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BAB12426A for ; Sun, 3 Mar 2019 15:48:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8E01725A1C; Mon, 4 Mar 2019 00:48:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1551656898; bh=Lq2rFiev5pEUNsZdB/cmAPVldiqyfK+hWU9EZU8bKWg=; h=From:To:Subject:Date:References:In-Reply-To:From; b=g/2afOnAHpO+L4+cTtKnyIoa2noRqhGcYwgla/jfh4GsUE9k5BlB58qWnvmsf6RvF kyuVRkZLZmN42IDc6NmJoUzjcT9BB2X0uSDPFh9XASgZ4jdqnqHx6m1CE8WFVJojiz pYpXmzHC9adIUiaCFdVubxGdJoKuU8+e1adbT3jU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut1HZBYNnOTS; Mon, 4 Mar 2019 00:48:17 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Mar 2019 00:48:17 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 4 Mar 2019 00:48:17 +0100 From: "Scharf, Michael" To: Olivier Bonaventure , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiig Date: Sun, 3 Mar 2019 23:48:16 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> In-Reply-To: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.63.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 23:48:25 -0000 Hi Olivier, I have read -05. Please find below some comments/questions (with chair hat = off): - Page 8: Sorry if I missed this... Can a client ask the converter to send = application data in the SYN payload data to the server (possibly even witho= ut TFO option)? Is it correct that the Convert protocol does not allow such= use of SYN payload data towards the remote host? - Page 8: What happens if the SYN,ACK from the server to the converter cont= ains payload data (possibly even without TFO option)? - Page 10: I wonder if the text on address sharing modes can be understood = without having read RFC 4787 and RFC 6888 and whether they would be normati= ve references (instead of informative references). - Page 13: If the remote host used payload data in the SYN towards the conv= erter (possibly even without TFO option), would this require any special ha= ndling in the converter? - Page 18: Is my understanding correct that when a client sends a Connect T= LV with one of its own addresses as "remote peer IP Address", then the tran= sport converter MUST attempt to establish this connection? In other words, = a converter that would _not_ set up this connection back to the client woul= d violate the protocol specification? - Page 25/26: Related to the first two comments: In this discussion on TFO = handling, I wonder what would happen to actual payload data in the SYN or S= YN,ACK of the connection between the converter and the remote peer. - Page 29: "IANA is requested to create the "Convert versions" sub-registry= . New values are assigned via Standards Action." The term "Standards Actio= n" is defined in RFC 8126 Section 4.9. I observe that this document specifi= es an experimental protocol. Why is the IANA policy not set e.g. to "RFC re= quired"? - Page 30: "The values in the range 1-127 can be assigned via Standards Act= ion." Again, what is the reason for not using e.g. "RFC required" here? - Page 34: Changes from 04 to -05 are not documented, e.g. the text below c= ould be useful here - Page 40: " A first difference is that the Convert protocol leverages the = TFO option [RFC7413] to exchange all control information during the three-w= ay handshake." That seems inconsistent with what is written below. Editorial nits: - Page 5: "Applicability document may _be_ defined in the future." - Page 7: "making use of _new_ TCP extensions" Best regards Michael > -----Original Message----- > From: tcpm On Behalf Of Olivier Bonaventure > Sent: Friday, February 8, 2019 5:51 PM > To: tcpm@ietf.org > Subject: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hello, >=20 > We have uploaded a new version of draft-ietf-tcpm-converters-05 (see > https://www.ietf.org/internet-drafts/draft-ietf-tcpm-converters-05.txt ) > that includes a lot of feedback from implementors who have worked on > client and server side implementations. Compared to the previous version, > the main modifications are the following : >=20 > - TCP Fast Open is not strictly required anymore. Several implementors > expressed concerns about this requirement. The TFO Cookie protects from > some attack scenarios that affect open servers like web servers. The Conv= ert > protocol is different and as discussed in RFC7413, there are different wa= ys to > protect from such attacks. Instead of using a TFO cookie inside the TCP > options, which consumes precious space in the extended TCP header, this > new version supports the utilisation of a Cookie that is placed in the SY= N > payload. This provides the same level of protection as a TFO Cookie in > environments were such protection is required. >=20 > - the Boostrap procedure has been simplified based on feedback from > implementers >=20 > - Error messages are not included in RST segments anymore but sent in the > bytestream. Implementors have indicated that processing such segments on > clients was difficult on some platforms. This change simplifies client > implementations. >=20 > - many small editorial changes to clarify the text based on implementors > feedback >=20 > Chairs, we believe that the document is now stable. As the milestone was = set > to > December 2018, we kindly request to organize a WGLC on -05 ASAP so that > we can address issues that may arise during the call and prepare an updat= ed > version for the Prague meeting. >=20 > FWIW, both the Broadband Forum and 3GPPP are working on documents > that leverage the protocol proposed in this draft. >=20 > Best regards, >=20 > Olivier and Med > -- >=20 >=20 > Disclaimer: https://www.tessares.net/mail-disclaimer/ > >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Mar 3 22:50:43 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072A1131006 for ; Sun, 3 Mar 2019 22:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fSCvbehdlGiF for ; Sun, 3 Mar 2019 22:50:31 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F01A1228B7 for ; Sun, 3 Mar 2019 22:50:31 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 44CVys2JKRz1y95; Mon, 4 Mar 2019 07:50:29 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 44CVys1N1kz1xnx; Mon, 4 Mar 2019 07:50:29 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2%21]) with mapi id 14.03.0435.000; Mon, 4 Mar 2019 07:50:29 +0100 From: To: "Scharf, Michael" , Olivier Bonaventure , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxA= Date: Mon, 4 Mar 2019 06:50:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 06:50:34 -0000 Hi Michael, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael > Envoy=E9=A0: lundi 4 mars 2019 00:48 > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Olivier, >=20 > I have read -05. Please find below some comments/questions (with chair ha= t > off): >=20 > - Page 8: Sorry if I missed this... Can a client ask the converter to sen= d > application data in the SYN payload data to the server (possibly even wit= hout > TFO option)? Is it correct that the Convert protocol does not allow such = use > of SYN payload data towards the remote host? >=20 [Med] The Converter does not track whether a client has negotiated TFO, as = such any data supplied in the initial SYN is related to the server by the c= onverter. The following rule applies:=20 Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. =20 > - Page 8: What happens if the SYN,ACK from the server to the converter > contains payload data (possibly even without TFO option)? [Med] Idem as above.=20 >=20 > - Page 10: I wonder if the text on address sharing modes can be understoo= d > without having read RFC 4787 and RFC 6888 and whether they would be norma= tive > references (instead of informative references). [Med] Makes sense. Updated the draft accordingly.=20 >=20 > - Page 13: If the remote host used payload data in the SYN towards the > converter (possibly even without TFO option), would this require any spec= ial > handling in the converter? [Med] Data supplied to the converter is unambiguously distinguished from th= e data destined to the server. This is covered by this field:=20 The Total Length is the number of 32 bits word, including the header, of the bytestream that are consumed by the Convert messages. >=20 > - Page 18: Is my understanding correct that when a client sends a Connect= TLV > with one of its own addresses as "remote peer IP Address", then the trans= port > converter MUST attempt to establish this connection? [Med] This is policy-based. The converter may restrict relying MPTCP connec= tions on its customer-facing interfaces or may relax it. =20 The draft can set a default behavior, though.=20 >From where I sit, I'd like to allow for a possible future extension similar= to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for tro= ubleshooting purposes. =20 What is your take on this?=20 In other words, a > converter that would _not_ set up this connection back to the client woul= d > violate the protocol specification? [Med] No. >=20 > - Page 25/26: Related to the first two comments: In this discussion on TF= O > handling, I wonder what would happen to actual payload data in the SYN or > SYN,ACK of the connection between the converter and the remote peer. [Med] This is covered by this rule: Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. >=20 > - Page 29: "IANA is requested to create the "Convert versions" sub-regist= ry. > New values are assigned via Standards Action." The term "Standards Action= " is > defined in RFC 8126 Section 4.9. I observe that this document specifies a= n > experimental protocol. Why is the IANA policy not set e.g. to "RFC requir= ed"? [Med] If we have to change the policy, I suggest we go for "IETF Review". = =20 >=20 > - Page 30: "The values in the range 1-127 can be assigned via Standards > Action." Again, what is the reason for not using e.g. "RFC required" here= ? [Med] Idem. >=20 > - Page 34: Changes from 04 to -05 are not documented, e.g. the text below > could be useful here >=20 > - Page 40: " A first difference is that the Convert protocol leverages th= e > TFO option [RFC7413] to exchange all control information during the three= -way > handshake." That seems inconsistent with what is written below. >=20 [Med] Good catch.=20 > Editorial nits: [Med] Wiil be fixed: https://github.com/obonaventure/draft-tcp-converters/p= ull/55/files =20 >=20 > - Page 5: "Applicability document may _be_ defined in the future." >=20 > - Page 7: "making use of _new_ TCP extensions" >=20 > Best regards >=20 > Michael >=20 >=20 > > -----Original Message----- > > From: tcpm On Behalf Of Olivier Bonaventure > > Sent: Friday, February 8, 2019 5:51 PM > > To: tcpm@ietf.org > > Subject: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Hello, > > > > We have uploaded a new version of draft-ietf-tcpm-converters-05 (see > > https://www.ietf.org/internet-drafts/draft-ietf-tcpm-converters-05.txt= ) > > that includes a lot of feedback from implementors who have worked on > > client and server side implementations. Compared to the previous versio= n, > > the main modifications are the following : > > > > - TCP Fast Open is not strictly required anymore. Several implementors > > expressed concerns about this requirement. The TFO Cookie protects from > > some attack scenarios that affect open servers like web servers. The > Convert > > protocol is different and as discussed in RFC7413, there are different = ways > to > > protect from such attacks. Instead of using a TFO cookie inside the TCP > > options, which consumes precious space in the extended TCP header, this > > new version supports the utilisation of a Cookie that is placed in the = SYN > > payload. This provides the same level of protection as a TFO Cookie in > > environments were such protection is required. > > > > - the Boostrap procedure has been simplified based on feedback from > > implementers > > > > - Error messages are not included in RST segments anymore but sent in t= he > > bytestream. Implementors have indicated that processing such segments o= n > > clients was difficult on some platforms. This change simplifies client > > implementations. > > > > - many small editorial changes to clarify the text based on implementor= s > > feedback > > > > Chairs, we believe that the document is now stable. As the milestone wa= s > set > > to > > December 2018, we kindly request to organize a WGLC on -05 ASAP so that > > we can address issues that may arise during the call and prepare an upd= ated > > version for the Prague meeting. > > > > FWIW, both the Broadband Forum and 3GPPP are working on documents > > that leverage the protocol proposed in this draft. > > > > Best regards, > > > > Olivier and Med > > -- > > > > > > Disclaimer: https://www.tessares.net/mail-disclaimer/ > > > > > > > > _______________________________________________ > > 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 Mon Mar 4 00:13:38 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6938B127AC2 for ; Mon, 4 Mar 2019 00:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NG0OF7W-zPU5 for ; Mon, 4 Mar 2019 00:13:34 -0800 (PST) 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 C1CEB1200D8 for ; Mon, 4 Mar 2019 00:13:32 -0800 (PST) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 89A6A278453 for ; Mon, 4 Mar 2019 17:13:29 +0900 (JST) Received: by mail-wm1-f43.google.com with SMTP id e74so3613874wmg.3 for ; Mon, 04 Mar 2019 00:13:29 -0800 (PST) X-Gm-Message-State: AHQUAuZqeCslMFWE36/3zwqZnMqoSn5W8KVVLJgKt+ihBqd/O3jcH1Xm eH8GdNF5shVI8qg6rp54A1WntclZUTBAIugyxq0= X-Google-Smtp-Source: AHgI3IaNAPKo8Tm1/i+AgKzRe5f+LOj73+ZGGoPeeOm8ZLWOIb3fdOXD7AL9EtuJ7mTrn0Zja/PWF9G8Y5Wj+wILwyc= X-Received: by 2002:a1c:4e09:: with SMTP id g9mr9794065wmh.56.1551687207403; Mon, 04 Mar 2019 00:13:27 -0800 (PST) MIME-Version: 1.0 References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <787AE7BB302AE849A7480A190F8B93302EA2273F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA23CC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA24AC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25443@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25F47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA25F47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yoshifumi Nishida Date: Mon, 4 Mar 2019 00:13:15 -0800 X-Gmail-Original-Message-ID: Message-ID: To: mohamed.boucadair@orange.com Cc: Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ccc8fd05834054db" Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 08:13:36 -0000 --000000000000ccc8fd05834054db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, I put my comment in lines. On Wed, Feb 27, 2019 at 1:34 AM wrote: > Hi Yoshi, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > *Envoy=C3=A9 :* mercredi 27 f=C3=A9vrier 2019 10:10 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* Yoshifumi Nishida; tcpm@ietf.org > *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Hi Med, > > > > I put my comments, > > > > On Mon, Feb 25, 2019 at 10:42 PM wrote: > > Hi Yoshi, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > *Envoy=C3=A9 :* lundi 25 f=C3=A9vrier 2019 19:35 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* Yoshifumi Nishida; tcpm@ietf.org > *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Hi Med, > > > > Thanks for the updates. I have one question. > > When the converter does mptcp conversion and the client wants to use TLS > for the connection, how TLS is used? > > > > [Med] TLS is managed e2e between the client and the server. The converter > can only read/strip data that is supplied by the client for the conversio= n > service. Unlike data exchanged between the client and the server, the dat= a > used for conversion purposes is supplied in clear between the client and > the converter. > > > > From a functional standpoint, the establishment of TLS between the client > and the server is similar to the establishment of such session when a > NAT/NAT6 is on-path. > > > > Yes, when the converter does non-mptcp conversion, I think the above text= s > are correct. > > [Med] If it is OK for simple TCP, then it should be OK for MPTCP: > I don't think this is always true. If mptcp client uses multiple subflows for the mptcp connection, how does it looks to the server? I believe it should be a single connection on the serve side. But, this means when you convert mptcp into tcp, you'll need to merge multiple TCP connections into a single TCP connection. This merging process will not be very easy when TLS are used for subflows. > > > Does this means TLS will be used only between the converter and the > server, but not used between the client and the converter? > > [Med] No. TLS is managed directly between the client and the converter. > The scope is as follows: > > > > In my understanding, in case of mptcp + TLS case, I think it should be (A= ) > architecture. > > To be precise, it will be like this. > > > > C------Converter-----S > > <=3D=3D=3D=3D=3D=3D=3D=3D><=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> > > <=3D=3D=3D=3D=3D=3D=3D=3D> > > <=3D=3D=3D=3D=3D=3D=3D=3D> > > <=3D=3D=3D=3D=3D=3D=3D=3D> > > TLS TLS > > > > So, I think it means mptcp + TLS case is out of focus for this draft. > (which is fine with me.) > > [Med] This is out of scope. > ok. > > > Or, you can make a special exception to break end-to-end principle in thi= s > case. > > But, I think it would be good if the draft clarifies this point. > > > > [Med] We added this NEW text to the draft : > > > > =E2=80=9CIt is out of scope of this document to elaborate on consideratio= ns > related to the use of TLS in the Client-Converter connection leg to > exchange conversion-supplied data.=E2=80=9D. > Hmm. I'm not very sure if this text can apply mptcp cases well. I am not fully sure what is conversion-supplied data is, however, I think mptcp case is the case where a client wants to use TLS between the client and the server. Thanks, -- Yoshi > --000000000000ccc8fd05834054db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,

I put my comment in lines.

On Wed, Feb 27, 2019 at 1:34 AM <mohamed.boucadair@orange.com> wrote:

Hi Yoshi,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoy=C3=A9=C2=A0: mercredi 27 f=C3=A9vrier 2019 10:10
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN
Cc=C2=A0: Yoshifumi Nishida; tcpm@ietf.org
Objet=C2=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converter= s-05

=C2=A0

Hi Med,

=C2=A0

I put my comments,

=C2=A0

On Mon, Feb 25, 2019 at 10:42 PM <mohamed.boucadair@orange= .com> wrote:

Hi Yoshi,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoy=C3=A9=C2=A0: lundi 25 f=C3=A9vrier 2019 19:35
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN
Cc=C2=A0: Yoshifumi Nishida; tcpm@ietf.org
Objet=C2=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converter= s-05

=C2=A0

Hi Med,

=C2=A0

Thanks for the updates. I have = one question.

When the converter does mptcp c= onversion and the client wants to use TLS for the connection, how TLS is us= ed?

=C2=A0

[Med] TLS is managed e2e between = the client and the server. The converter can only read/strip data that is supplied by the client for the conversion service. Unlike data exc= hanged between the client and the server, the data used for conversion purp= oses is supplied in clear between the client and the converter.

=C2=A0

From a functional standpoint, the= establishment of TLS between the client and the server is similar to the establishment of such session when a NAT/NAT6 is on-path.=C2= =A0

=C2=A0

Yes, when the converter does non-mptcp conversion, I= think the above texts are correct.=C2=A0

[Med] If it is OK for simple TCP,= then it should be OK for MPTCP:


I don't th= ink this is always true.
If mptcp client uses multiple subflows f= or the mptcp connection, how does it looks to the server?
I belie= ve it should be a single connection on the serve side.
But, this = means when you convert mptcp into tcp, you'll need to merge multiple TC= P connections into a single TCP connection.
This merging process = will not be very easy when TLS are used for subflows.

=C2=A0=C2=A0

Does this means TLS will be use= d only between the converter and the server, but not used between the clien= t and the converter?

[Med] No. TLS is managed directly= between the client and the converter. The scope is as follows: =C2=A0=C2=A0

=C2=A0

In my understanding, in case of mptcp + TLS case, I = think it should be (A) architecture.

To be precise, it will be like this.

=C2=A0

C------Converter-----S<= /u>

<=3D=3D=3D=3D=3D=3D=3D=3D>&= lt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>

<=3D=3D=3D=3D=3D=3D=3D=3D><= /span>

<=3D=3D=3D=3D=3D=3D=3D=3D><= /span>

<=3D=3D=3D=3D=3D=3D=3D=3D><= /span>

=C2=A0=C2=A0 TLS=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 TLS

=C2=A0

So, I think it means mptcp + TLS case is out of focu= s for this draft. (which is fine with me.)

[Med] This is out of scope.


ok.
=C2=A0

=C2=A0

Or, you can make a special exception to break end-to= -end principle in this case.=C2=A0

But, I think it would be good if the draft clarifies= this point.

=C2=A0

[Med] We added this NEW text to t= he draft=C2=A0:

=C2=A0

=E2=80=9CIt is out of scope of this document to elaborate on = considerations related to the use of TLS in the Client-Converter connection leg to exchange conve= rsion-supplied data.=E2=80=9D.


Hmm. I= 9;m not very sure if this text can apply mptcp cases well.=C2=A0
= I am not fully sure what is conversion-supplied data is, however, I think m= ptcp case is the case where a client wants to use TLS between the client an= d the server.=C2=A0

Thanks,
--
Yoshi
<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5pt 0cm= 5pt 4.8pt">
--000000000000ccc8fd05834054db-- From nobody Mon Mar 4 03:37:07 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1484B131167 for ; Mon, 4 Mar 2019 03:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7JNUnYUYFGL for ; Mon, 4 Mar 2019 03:36:56 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2514A131116 for ; Mon, 4 Mar 2019 03:36:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1CE5425A17; Mon, 4 Mar 2019 12:36:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1551699411; bh=SvMmTbLVJI00lCq9WxfEd6NIEIUtFrKd7dNRMrIUrOQ=; h=From:To:Subject:Date:References:In-Reply-To:From; b=SKq9ThH/kQdvyq4RL7FxZ4fJBRXq004mCQYMiyCo3IT5M+5g82Q4ddIdV3jGKAdAe OBLhi1RVABMM4WpPGLnfa35vdT/9pzuPWXAT8XQ5UsyLE11zg71tRipmzMYeeEYuRW JLWOv+WkqohFXAmKco+AgzRIn/HT2bZZpcO2pzKc= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ6WIKPupDWc; Mon, 4 Mar 2019 12:36:49 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Mar 2019 12:36:49 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 4 Mar 2019 12:36:49 +0100 From: "Scharf, Michael" To: "mohamed.boucadair@orange.com" , "Olivier Bonaventure" , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxCAAErBwA== Date: Mon, 4 Mar 2019 11:36:48 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.2.171] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 11:37:05 -0000 Hi Med, Please also see inline [ms]. I removed the parts that seem to be sorted out= . Michael -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Monday, March 04, 2019 7:50 AM To: Scharf, Michael; Olivier Bonaventure; tcpm@ietf.org Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Hi Michael, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael > Envoy=E9=A0: lundi 4 mars 2019 00:48 > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Olivier, >=20 > I have read -05. Please find below some comments/questions (with chair ha= t > off): >=20 > - Page 8: Sorry if I missed this... Can a client ask the converter to sen= d > application data in the SYN payload data to the server (possibly even wit= hout > TFO option)? Is it correct that the Convert protocol does not allow such = use > of SYN payload data towards the remote host? >=20 [Med] The Converter does not track whether a client has negotiated TFO, as = such any data supplied in the initial SYN is related to the server by the c= onverter. The following rule applies:=20 Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. =20 [ms] That is pretty clear for all data in non-SYN segments. But IMHO it ope= ns room for interpretation _when_ to relay data included in any of the SYNs= and SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or= whether it would be relayed after the three-way handshake. If the handling= of SYN data is an internal decision of the converter implementation, IMHO = the draft could call that out explicitly. (I note that w/o TFO the use of p= ayload in SYNs should be a corner case, albeit allowed by TCP.) > - Page 8: What happens if the SYN,ACK from the server to the converter > contains payload data (possibly even without TFO option)? [Med] Idem as above.=20 [ms] My question is whether the converter would relay the payload data from= the server's SYN, ACK to the client in (a) the SYN,ACK after the Convert TLV (b) separately (c) both is possible (d) ... or whether this does not require any text in the specification I think I can reverse engineer from other text in the I-D that probably (a)= and (b) is allowed, i.e., the answer is (c), but can't this be made more e= xplicit? > - Page 13: If the remote host used payload data in the SYN towards the > converter (possibly even without TFO option), would this require any spec= ial > handling in the converter? [Med] Data supplied to the converter is unambiguously distinguished from th= e data destined to the server. This is covered by this field:=20 The Total Length is the number of 32 bits word, including the header, of the bytestream that are consumed by the Convert messages. [ms] IMHO it would help to make the two different usage patterns of the byt= estream more explicit along the lines of your explanation, e.g., "Data adde= d by the Convert protocol to the TCP bytestream in the upstream connection = is unambiguously distinguished from payload data in the downstream connecti= on by the total length field in the Convert messages". Also, note that in t= he specific context of page 13 I wonder about payload data sent in the SYN = sent from the remote host to the converter, i.e., that data is destined _to= the client_. =20 > - Page 18: Is my understanding correct that when a client sends a Connect= TLV > with one of its own addresses as "remote peer IP Address", then the trans= port > converter MUST attempt to establish this connection? [Med] This is policy-based. The converter may restrict relying MPTCP connec= tions on its customer-facing interfaces or may relax it. =20 The draft can set a default behavior, though.=20 >From where I sit, I'd like to allow for a possible future extension similar= to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for tro= ubleshooting purposes. =20 What is your take on this?=20 [ms] The exact wording in -05 is: "Upon reception of a Connect TLV, and abs= ent any rate limit policy or resource exhaustion conditions, a Transport Co= nverter MUST attempt to establish a connection to the address and port that= it contains." A later statement somehow contradicts this MUST requirement:= "The Transport Converter may discard a Connect TLV request for various rea= sons (e.g., authorization failed, out of resources, invalid address type)."= . So probably the key question is why to have a capital letter MUST in the = first place? Of course, this question may matter for troubleshooting.=20 In other words, a > converter that would _not_ set up this connection back to the client woul= d > violate the protocol specification? [Med] No. [ms] Well, in my reading such a converter policy would violates the MUST ci= ted above, albeit that may not be the intended meaning of the MUST. Actuall= y, I believe that the security considerations in Section 7 lack a discussio= n of (firewall) policies on the client-facing interfaces/network of the con= verter. For instance, let's assume that in the client-facing network there = would be firewall policies that prevent direct TCP connections between diff= erent clients, e.g., within the same Wifi network. Depending how the conver= ter deals with connect requests to IP addresses in the client-facing networ= k, clients could possibly use the converter to bypass firewall policies and= setup "direct" communication via the converter? Isn't bypassing firewall r= ules something that could be relevant for Section 7? > - Page 25/26: Related to the first two comments: In this discussion on TF= O > handling, I wonder what would happen to actual payload data in the SYN or > SYN,ACK of the connection between the converter and the remote peer. [Med] This is covered by this rule: Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. [ms] See above. I really wonder about the timing of relaying data. SYN payl= oad data would probably be used by application protocols for some specific = reason (e.g., low latency delivery). The question is therefore whether the = converter would care about low latency delivery, or not. Of course, SYN pay= load data in TCP may be a corner case, but as the Convert protocol is all a= bout SYNs, it seems somewhat obvious to ask how exactly "normal" SYN payloa= d data would be handled. Michael From nobody Mon Mar 4 06:42:49 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B913104B for ; Mon, 4 Mar 2019 06:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 bG4DZ9mSQYWR for ; Mon, 4 Mar 2019 06:42:46 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FD8129BBF for ; Mon, 4 Mar 2019 06:42:45 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 44CjRm2hBYz1ypd; Mon, 4 Mar 2019 15:42:44 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 44CjRl6VWpzyPk; Mon, 4 Mar 2019 15:42:43 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0435.000; Mon, 4 Mar 2019 15:42:44 +0100 From: To: "Scharf, Michael" , Olivier Bonaventure , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxCAAErBwIAAO0+A Date: Mon, 4 Mar 2019 14:42:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA27EA2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 14:42:48 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > Envoy=E9=A0: lundi 4 mars 2019 12:37 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; tcpm@ietf.org > Objet=A0: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Med, >=20 > Please also see inline [ms]. I removed the parts that seem to be sorted o= ut. >=20 > Michael >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, March 04, 2019 7:50 AM > To: Scharf, Michael; Olivier Bonaventure; tcpm@ietf.org > Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Michael, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michae= l > > Envoy=E9=A0: lundi 4 mars 2019 00:48 > > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Hi Olivier, > > > > I have read -05. Please find below some comments/questions (with chair = hat > > off): > > > > - Page 8: Sorry if I missed this... Can a client ask the converter to s= end > > application data in the SYN payload data to the server (possibly even > without > > TFO option)? Is it correct that the Convert protocol does not allow suc= h > use > > of SYN payload data towards the remote host? > > >=20 > [Med] The Converter does not track whether a client has negotiated TFO, a= s > such any data supplied in the initial SYN is related to the server by the > converter. The following rule applies: >=20 > Any user data received by the Transport Converter over the upstream > (resp., downstream) connection is relayed over the downstream (resp., > upstream) connection. >=20 > [ms] That is pretty clear for all data in non-SYN segments. But IMHO it o= pens > room for interpretation _when_ to relay data included in any of the SYNs = and > SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or > whether it would be relayed after the three-way handshake. If the handlin= g of > SYN data is an internal decision of the converter implementation, IMHO th= e > draft could call that out explicitly. (I note that w/o TFO the use of pay= load > in SYNs should be a corner case, albeit allowed by TCP.) [Med] The above applies for both non-SYN and SYNs. We can make this explici= t: OLD:=20 Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. NEW:=20 Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. In particular, if the initial SYN message contai= ns data in its payload (e.g., [RFC7413]), that data MUST be placed=20 right after the Convert TLVs when generating the relayed SYN. >=20 > > - Page 8: What happens if the SYN,ACK from the server to the converter > > contains payload data (possibly even without TFO option)? >=20 > [Med] Idem as above. >=20 > [ms] My question is whether the converter would relay the payload data fr= om > the server's SYN, ACK to the client in > (a) the SYN,ACK after the Convert TLV > (b) separately > (c) both is possible > (d) ... or whether this does not require any text in the specification >=20 > I think I can reverse engineer from other text in the I-D that probably (= a) > and (b) is allowed, i.e., the answer is (c), but can't this be made more > explicit? >=20 [Med] We can make this explicit.=20 > > - Page 13: If the remote host used payload data in the SYN towards the > > converter (possibly even without TFO option), would this require any > special > > handling in the converter? >=20 > [Med] Data supplied to the converter is unambiguously distinguished from = the > data destined to the server. This is covered by this field: >=20 > The Total Length is the number of 32 bits word, including the header, > of the bytestream that are consumed by the Convert messages. >=20 > [ms] IMHO it would help to make the two different usage patterns of the > bytestream more explicit along the lines of your explanation, e.g., "Data > added by the Convert protocol to the TCP bytestream in the upstream > connection is unambiguously distinguished from payload data in the downst= ream > connection by the total length field in the Convert messages". [Med] Deal. Also, note > that in the specific context of page 13 I wonder about payload data sent = in > the SYN sent from the remote host to the converter, i.e., that data is > destined _to the client_. >=20 > > - Page 18: Is my understanding correct that when a client sends a Conne= ct > TLV > > with one of its own addresses as "remote peer IP Address", then the > transport > > converter MUST attempt to establish this connection? >=20 > [Med] This is policy-based. The converter may restrict relying MPTCP > connections on its customer-facing interfaces or may relax it. > The draft can set a default behavior, though. >=20 > From where I sit, I'd like to allow for a possible future extension simil= ar > to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for > troubleshooting purposes. >=20 > What is your take on this? >=20 > [ms] The exact wording in -05 is: "Upon reception of a Connect TLV, and > absent any rate limit policy or resource exhaustion conditions, a Transpo= rt > Converter MUST attempt to establish a connection to the address and port = that > it contains." A later statement somehow contradicts this MUST requirement= : > "The Transport Converter may discard a Connect TLV request for various > reasons (e.g., authorization failed, out of resources, invalid address > type).". So probably the key question is why to have a capital letter MUS= T in > the first place? Of course, this question may matter for troubleshooting. >=20 [Med] Good point. We can update the text as follows:=20 OLD:=20 Upon reception of a Connect TLV, and absent any rate limit policy or resource exhaustion conditions, a Transport Converter MUST attempt to establish a connection to the address and port that it contains. The Transport Converter MUST use by default the TCP options that correspond to its local policy to establish this connection. These are the options that it advertises in the Supported TCP Extensions TLV. NEW: Upon reception of a Connect TLV, and absent any policy (e.g., rate-limit= ) or resource exhaustion conditions, a Transport Converter attempts to establish a connection to the address and port that it contains. The Transport Converter MUST use by default the TCP options that correspond to its local policy to establish this connection. These are the options that it advertises in the Supported TCP Extensions TLV. > In other words, a > > converter that would _not_ set up this connection back to the client wo= uld > > violate the protocol specification? >=20 > [Med] No. >=20 > [ms] Well, in my reading such a converter policy would violates the MUST > cited above, albeit that may not be the intended meaning of the MUST. > Actually, I believe that the security considerations in Section 7 lack a > discussion of (firewall) policies on the client-facing interfaces/network= of > the converter. For instance, let's assume that in the client-facing netwo= rk > there would be firewall policies that prevent direct TCP connections betw= een > different clients, e.g., within the same Wifi network. Depending how the > converter deals with connect requests to IP addresses in the client-facin= g > network, clients could possibly use the converter to bypass firewall poli= cies > and setup "direct" communication via the converter? Isn't bypassing firew= all > rules something that could be relevant for Section 7? [Med] Actually, this is similar to hairpining for NATs (fwiw, the default b= ehavior is MUST be enabled; see https://tools.ietf.org/html/rfc4787#section= -6). =20 Whether this is enabled/disabled is deployment-specific. We can add some te= xt if you think this is helpful.=20 >=20 > > - Page 25/26: Related to the first two comments: In this discussion on = TFO > > handling, I wonder what would happen to actual payload data in the SYN = or > > SYN,ACK of the connection between the converter and the remote peer. >=20 > [Med] This is covered by this rule: >=20 > Any user data received by the Transport Converter over the upstream > (resp., downstream) connection is relayed over the downstream (resp., > upstream) connection. >=20 > [ms] See above. I really wonder about the timing of relaying data. SYN > payload data would probably be used by application protocols for some > specific reason (e.g., low latency delivery). The question is therefore > whether the converter would care about low latency delivery, or not. Of > course, SYN payload data in TCP may be a corner case, but as the Convert > protocol is all about SYNs, it seems somewhat obvious to ask how exactly > "normal" SYN payload data would be handled. >=20 > Michael From nobody Mon Mar 4 06:57:53 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F3C131074; Mon, 4 Mar 2019 06:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 BL39PnRzWe7t; Mon, 4 Mar 2019 06:57:48 -0800 (PST) Received: from mx2.cnes.fr (mx2.cnes.fr [194.199.174.201]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7F13108B; Mon, 4 Mar 2019 06:57:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,440,1544486400"; d="scan'208";a="24899499" X-IPAS-Result: =?us-ascii?q?A2EEAACbO31c/wUBeAplGgEBAQICAQEBCAIBAQGBUgUBA?= =?us-ascii?q?QEMAYIPV2EhEicKjBiNV5ghgXs4AYRAAoQmIjQJDQEBAwEBAQIBAwICAmkoh?= =?us-ascii?q?UsBAQEBAgF5BQsCAQUDDQEUJDIlAgQOBQiFCAiqEBqKC4EvAYFZiDGDM4ERR?= =?us-ascii?q?oJMhQMFgzSCJgKQZEuSVQcCgRyRcWiBDIVigzYDiBOLdotEhzs5gVYzGieDO?= =?us-ascii?q?IIWFxOOC0IwgSAIjk4BgR4BAQ?= From: Kuhn Nicolas To: 'Mark Allman' CC: "draft-ietf-tcpm-rto-consider@ietf.org" , "tcpm@ietf.org" Thread-Topic: [draft-ietf-tcpm-rto-consider-07] Interaction with other time-based recovery schemes? Thread-Index: AdTCJhVWLilqk5paQGaQX70xlfjc7wAAfPmAACEM0bAACdr7AAA1aVNQAZ25HYACHo/B4A== Date: Mon, 4 Mar 2019 14:56:44 +0000 Deferred-Delivery: Mon, 4 Mar 2019 14:57:44 +0000 Message-ID: References: <86798307-C256-4911-A4CB-0DDD2693175A@icsi.berkeley.edu> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24468.007 x-tm-as-result: No--21.680500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [draft-ietf-tcpm-rto-consider-07] Interaction with other time-based recovery schemes? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 14:57:52 -0000 Thanks for the update that covers my comments.=20 Cheers, Nico -----Message d'origine----- De=A0: Mark Allman =20 Envoy=E9=A0: jeudi 21 f=E9vrier 2019 22:01 =C0=A0: Kuhn Nicolas Cc=A0: draft-ietf-tcpm-rto-consider@ietf.org; tcpm@ietf.org Objet=A0: Re: [draft-ietf-tcpm-rto-consider-07] Interaction with other time= -based recovery schemes? > I think that most of the confusion came for the usage of "RTO" > while the draft actually covers is more generic than TCP-RTO. A change=20 > in the name or a disclaimer at the beginning of the draft could help. OK. I thought this was pretty clear, but I added some words to the second = paragraph sort of along the line of your suggestion. I now have this as th= e beginning of the second paragraph. The second sentence is new. See what= you think ... Various protocols have defined their own RTO mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP [RFC3261]). In this document, our use of "RTO" does not refer to any one specific scheme, but rather is a generic term that includes all timer-based retransmission mechanisms. The specifics of retransmission timeouts often represent a particular tradeoff between correctness and responsiveness [AP99]. > [NK] The last paragraph of section 2 indeed somehow covers what I was=20 > meaning. I now see it more clearly but some rewording may be relevant.=20 > I would propose to rephrase the beginning as follows : > " However, adding a requirements umbrella to a body of existing > specific retransmission timer specifications is inherently messy and > we run the risk of creating "inconsistencies". The correct way to > view this document is as the default case and these other > specifications as agreed upon deviations from the default." >>> > " Existing protocols may exploit multiple specific retransmission timers > and there may be inconsistencies between the recommendation of this > draft and the actual use of timers for retransmissions. As example, th= is > document assesses retransmission timeouts in general, while TCP may > exploit RACK and RTO for a timer-based reliability. The correct way to > view this document is as a general protocol-agnostic case." These words I am less happy with. I think the suggested words exclude the = meaning of the original words. And, this is more detail about multiple tim= ers than I really think is useful in setting the context. That said, I get the multiple timer scenario that you've brought up and thi= nk it'd be good to specifically call that out. I added the following to th= e S.6 note in the draft. E.g., some protocols may leverage more than one retransmission timer simultaneously. In these cases, the general guidance in this document can be applied to all such timers. Please send along further thoughts. Many thanks! allman From nobody Mon Mar 4 07:21:29 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC1812D4E9 for ; Mon, 4 Mar 2019 07:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NGVm2Wo3ie07 for ; Mon, 4 Mar 2019 07:21:22 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3994D130FC7 for ; Mon, 4 Mar 2019 07:21:22 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 44CkJJ36mCz4wWT; Mon, 4 Mar 2019 16:21:20 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 44CkJJ2G07zDq7k; Mon, 4 Mar 2019 16:21:20 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d%21]) with mapi id 14.03.0435.000; Mon, 4 Mar 2019 16:21:20 +0100 From: To: Yoshifumi Nishida CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHU0mIq8F1YPdE/0kmdbGAelCsfdaX7kCWQ Date: Mon, 4 Mar 2019 15:21:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA27F2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <787AE7BB302AE849A7480A190F8B93302EA2273F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA23CC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA24AC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25443@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25F47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA27F2FOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 15:21:27 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA27F2FOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW9zaGksDQoNCuKAnEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbHdheXMgdHJ1ZS4NCklmIG1wdGNw IGNsaWVudCB1c2VzIG11bHRpcGxlIHN1YmZsb3dzIGZvciB0aGUgbXB0Y3AgY29ubmVjdGlvbiwg aG93IGRvZXMgaXQgbG9va3MgdG8gdGhlIHNlcnZlcj8NCkkgYmVsaWV2ZSBpdCBzaG91bGQgYmUg YSBzaW5nbGUgY29ubmVjdGlvbiBvbiB0aGUgc2VydmUgc2lkZS7igJ0NCg0KVGhlIHNlcnZlciB3 aWxsIGFsd2F5cyBzZWUgdGhlIHNhbWUgc291cmNlIGFkZHJlc3MvcG9ydC4NCg0K4oCcQnV0LCB0 aGlzIG1lYW5zIHdoZW4geW91IGNvbnZlcnQgbXB0Y3AgaW50byB0Y3AsIHlvdSdsbCBuZWVkIHRv IG1lcmdlIG11bHRpcGxlIFRDUCBjb25uZWN0aW9ucyBpbnRvIGEgc2luZ2xlIFRDUCBjb25uZWN0 aW9uLuKAnQ0KDQpUaGUgZ2x1ZSBpcyBkb25lIGF0IHRoZSBUQ1AgbGV2ZWwgYnkgdGhlIGNvbnZl cnRlci4NCg0K4oCcVGhpcyBtZXJnaW5nIHByb2Nlc3Mgd2lsbCBub3QgYmUgdmVyeSBlYXN5IHdo ZW4gVExTIGFyZSB1c2VkIGZvciBzdWJmbG93cy7igJ0NCg0KV2h5PyBJIHRoaW5rIHRoZSBkaXNj b25uZWN0IGlzIHRoYXQgeW91IHNlZW0gdG8gaW1wbHkgdGhhdCBkYXRhIGZyb20gdmFyaW91cyBz ZWdtZW50cyBhcmUgbXVsdGlwbGV4ZWQgaW4gdGhlIHNhbWUgc2VnbWVudCB1cHN0cmVhbS4NCg0K Q2hlZXJzLA0KTWVkDQoNCkRlIDogWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNm Yy53aWRlLmFkLmpwXQ0KRW52b3nDqSA6IGx1bmRpIDQgbWFycyAyMDE5IDA5OjEzDQrDgCA6IEJP VUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCkNjIDogWW9zaGlmdW1pIE5pc2hpZGE7IHRjcG1AaWV0 Zi5vcmcNCk9iamV0IDogUmU6IFt0Y3BtXSBVcGRhdGVkIHZlcnNpb24gb2YgZHJhZnQtaWV0Zi10 Y3BtLWNvbnZlcnRlcnMtMDUNCg0KSGkgTWVkLA0KDQpJIHB1dCBteSBjb21tZW50IGluIGxpbmVz Lg0KDQpPbiBXZWQsIEZlYiAyNywgMjAxOSBhdCAxOjM0IEFNIDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpI aSBZb3NoaSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IFlv c2hpZnVtaSBOaXNoaWRhIFttYWlsdG86bmlzaGlkYUBzZmMud2lkZS5hZC5qcDxtYWlsdG86bmlz aGlkYUBzZmMud2lkZS5hZC5qcD5dDQpFbnZvecOpIDogbWVyY3JlZGkgMjcgZsOpdnJpZXIgMjAx OSAxMDoxMA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpDYyA6IFlvc2hpZnVtaSBO aXNoaWRhOyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KT2JqZXQgOiBSZTog W3RjcG1dIFVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy0wNQ0K DQpIaSBNZWQsDQoNCkkgcHV0IG15IGNvbW1lbnRzLA0KDQpPbiBNb24sIEZlYiAyNSwgMjAxOSBh dCAxMDo0MiBQTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkgWW9zaGksDQoNClBsZWFzZSBzZWUgaW5s aW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBZb3NoaWZ1bWkgTmlzaGlkYSBbbWFpbHRvOm5p c2hpZGFAc2ZjLndpZGUuYWQuanA8bWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQuanA+XQ0KRW52 b3nDqSA6IGx1bmRpIDI1IGbDqXZyaWVyIDIwMTkgMTk6MzUNCsOAIDogQk9VQ0FEQUlSIE1vaGFt ZWQgVEdJL09MTg0KQ2MgOiBZb3NoaWZ1bWkgTmlzaGlkYTsgdGNwbUBpZXRmLm9yZzxtYWlsdG86 dGNwbUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFt0Y3BtXSBVcGRhdGVkIHZlcnNpb24gb2YgZHJh ZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMtMDUNCg0KSGkgTWVkLA0KDQpUaGFua3MgZm9yIHRoZSB1 cGRhdGVzLiBJIGhhdmUgb25lIHF1ZXN0aW9uLg0KV2hlbiB0aGUgY29udmVydGVyIGRvZXMgbXB0 Y3AgY29udmVyc2lvbiBhbmQgdGhlIGNsaWVudCB3YW50cyB0byB1c2UgVExTIGZvciB0aGUgY29u bmVjdGlvbiwgaG93IFRMUyBpcyB1c2VkPw0KDQpbTWVkXSBUTFMgaXMgbWFuYWdlZCBlMmUgYmV0 d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLiBUaGUgY29udmVydGVyIGNhbiBvbmx5IHJl YWQvc3RyaXAgZGF0YSB0aGF0IGlzIHN1cHBsaWVkIGJ5IHRoZSBjbGllbnQgZm9yIHRoZSBjb252 ZXJzaW9uIHNlcnZpY2UuIFVubGlrZSBkYXRhIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBjbGllbnQg YW5kIHRoZSBzZXJ2ZXIsIHRoZSBkYXRhIHVzZWQgZm9yIGNvbnZlcnNpb24gcHVycG9zZXMgaXMg c3VwcGxpZWQgaW4gY2xlYXIgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgY29udmVydGVyLg0K DQpGcm9tIGEgZnVuY3Rpb25hbCBzdGFuZHBvaW50LCB0aGUgZXN0YWJsaXNobWVudCBvZiBUTFMg YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyIGlzIHNpbWlsYXIgdG8gdGhlIGVzdGFi bGlzaG1lbnQgb2Ygc3VjaCBzZXNzaW9uIHdoZW4gYSBOQVQvTkFUNiBpcyBvbi1wYXRoLg0KDQpZ ZXMsIHdoZW4gdGhlIGNvbnZlcnRlciBkb2VzIG5vbi1tcHRjcCBjb252ZXJzaW9uLCBJIHRoaW5r IHRoZSBhYm92ZSB0ZXh0cyBhcmUgY29ycmVjdC4NCltNZWRdIElmIGl0IGlzIE9LIGZvciBzaW1w bGUgVENQLCB0aGVuIGl0IHNob3VsZCBiZSBPSyBmb3IgTVBUQ1A6DQoNCkkgZG9uJ3QgdGhpbmsg dGhpcyBpcyBhbHdheXMgdHJ1ZS4NCklmIG1wdGNwIGNsaWVudCB1c2VzIG11bHRpcGxlIHN1YmZs b3dzIGZvciB0aGUgbXB0Y3AgY29ubmVjdGlvbiwgaG93IGRvZXMgaXQgbG9va3MgdG8gdGhlIHNl cnZlcj8NCkkgYmVsaWV2ZSBpdCBzaG91bGQgYmUgYSBzaW5nbGUgY29ubmVjdGlvbiBvbiB0aGUg c2VydmUgc2lkZS4NCkJ1dCwgdGhpcyBtZWFucyB3aGVuIHlvdSBjb252ZXJ0IG1wdGNwIGludG8g dGNwLCB5b3UnbGwgbmVlZCB0byBtZXJnZSBtdWx0aXBsZSBUQ1AgY29ubmVjdGlvbnMgaW50byBh IHNpbmdsZSBUQ1AgY29ubmVjdGlvbi4NClRoaXMgbWVyZ2luZyBwcm9jZXNzIHdpbGwgbm90IGJl IHZlcnkgZWFzeSB3aGVuIFRMUyBhcmUgdXNlZCBmb3Igc3ViZmxvd3MuDQoNCkRvZXMgdGhpcyBt ZWFucyBUTFMgd2lsbCBiZSB1c2VkIG9ubHkgYmV0d2VlbiB0aGUgY29udmVydGVyIGFuZCB0aGUg c2VydmVyLCBidXQgbm90IHVzZWQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgY29udmVydGVy Pw0KW01lZF0gTm8uIFRMUyBpcyBtYW5hZ2VkIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIGNvbnZlcnRlci4gVGhlIHNjb3BlIGlzIGFzIGZvbGxvd3M6DQoNCkluIG15IHVuZGVy c3RhbmRpbmcsIGluIGNhc2Ugb2YgbXB0Y3AgKyBUTFMgY2FzZSwgSSB0aGluayBpdCBzaG91bGQg YmUgKEEpIGFyY2hpdGVjdHVyZS4NClRvIGJlIHByZWNpc2UsIGl0IHdpbGwgYmUgbGlrZSB0aGlz Lg0KDQpDLS0tLS0tQ29udmVydGVyLS0tLS1TDQo8PT09PT09PT0+PD09PT09PT09PT0+DQo8PT09 PT09PT0+DQo8PT09PT09PT0+DQo8PT09PT09PT0+DQogICBUTFMgICAgICAgIFRMUw0KDQpTbywg SSB0aGluayBpdCBtZWFucyBtcHRjcCArIFRMUyBjYXNlIGlzIG91dCBvZiBmb2N1cyBmb3IgdGhp cyBkcmFmdC4gKHdoaWNoIGlzIGZpbmUgd2l0aCBtZS4pDQpbTWVkXSBUaGlzIGlzIG91dCBvZiBz Y29wZS4NCg0Kb2suDQoNCg0KT3IsIHlvdSBjYW4gbWFrZSBhIHNwZWNpYWwgZXhjZXB0aW9uIHRv IGJyZWFrIGVuZC10by1lbmQgcHJpbmNpcGxlIGluIHRoaXMgY2FzZS4NCkJ1dCwgSSB0aGluayBp dCB3b3VsZCBiZSBnb29kIGlmIHRoZSBkcmFmdCBjbGFyaWZpZXMgdGhpcyBwb2ludC4NCg0KW01l ZF0gV2UgYWRkZWQgdGhpcyBORVcgdGV4dCB0byB0aGUgZHJhZnQgOg0KDQrigJxJdCBpcyBvdXQg b2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudCB0byBlbGFib3JhdGUgb24gY29uc2lkZXJhdGlvbnMg cmVsYXRlZCB0byB0aGUgdXNlIG9mIFRMUyBpbiB0aGUgQ2xpZW50LUNvbnZlcnRlciBjb25uZWN0 aW9uIGxlZyB0byBleGNoYW5nZSBjb252ZXJzaW9uLXN1cHBsaWVkIGRhdGEu4oCdLg0KDQpIbW0u IEknbSBub3QgdmVyeSBzdXJlIGlmIHRoaXMgdGV4dCBjYW4gYXBwbHkgbXB0Y3AgY2FzZXMgd2Vs bC4NCkkgYW0gbm90IGZ1bGx5IHN1cmUgd2hhdCBpcyBjb252ZXJzaW9uLXN1cHBsaWVkIGRhdGEg aXMsIGhvd2V2ZXIsIEkgdGhpbmsgbXB0Y3AgY2FzZSBpcyB0aGUgY2FzZSB3aGVyZSBhIGNsaWVu dCB3YW50cyB0byB1c2UgVExTIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4NCg0K VGhhbmtzLA0KLS0NCllvc2hpDQo= --_000_787AE7BB302AE849A7480A190F8B93302EA27F2FOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLmdtYWlsLW0zMzYyNzEwMzE1MTY2 ODg2MDc4bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTMzNjI3MTAzMTUxNjY4ODYwNzhtc29s aXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbTMzNjI3MTAzMTUxNjY4ODYwNzhtc29saXN0cGFyYWdy YXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fMzM2MjcxMDMxNTE2Njg4NjA3OG1zb2xpc3Rw YXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uZ21haWwtbTMzNjI3MTAzMTUxNjY4ODYwNzhwbC1zDQoJe21zby1zdHlsZS1uYW1lOmdtYWls LW1fMzM2MjcxMDMxNTE2Njg4NjA3OHBsLXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPllvc2hpLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvbid0 IHRoaW5rIHRoaXMgaXMgYWx3YXlzIHRydWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIG1wdGNwIGNsaWVudCB1c2VzIG11 bHRpcGxlIHN1YmZsb3dzIGZvciB0aGUgbXB0Y3AgY29ubmVjdGlvbiwgaG93IGRvZXMgaXQgbG9v a3MgdG8gdGhlIHNlcnZlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBiZWxpZXZlIGl0IHNob3VsZCBiZSBhIHNpbmdsZSBj b25uZWN0aW9uIG9uIHRoZSBzZXJ2ZSBzaWRlLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRo ZSBzZXJ2ZXIgd2lsbCBhbHdheXMgc2VlIHRoZSBzYW1lIHNvdXJjZSBhZGRyZXNzL3BvcnQuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPuKAnEJ1dCwgdGhpcyBtZWFucyB3aGVuIHlvdSBjb252ZXJ0IG1w dGNwIGludG8gdGNwLCB5b3UnbGwgbmVlZCB0byBtZXJnZSBtdWx0aXBsZSBUQ1AgY29ubmVjdGlv bnMgaW50byBhIHNpbmdsZSBUQ1AgY29ubmVjdGlvbi7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5UaGUgZ2x1ZSBpcyBkb25lIGF0IHRoZSBUQ1AgbGV2ZWwgYnkgdGhlIGNvbnZlcnRlci4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxUaGlzIG1lcmdp bmcgcHJvY2VzcyB3aWxsIG5vdCBiZSB2ZXJ5IGVhc3kgd2hlbiBUTFMgYXJlIHVzZWQgZm9yIHN1 YmZsb3dzLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XaHk/DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHRoaW5rIHRoZSBkaXNj b25uZWN0IGlzIHRoYXQgeW91IHNlZW0gdG8gaW1wbHkgdGhhdCBkYXRhIGZyb20gdmFyaW91cyBz ZWdtZW50cyBhcmUgbXVsdGlwbGV4ZWQgaW4gdGhlIHNhbWUgc2VnbWVudCB1cHN0cmVhbS4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBZb3NoaWZ1bWkg TmlzaGlkYSBbbWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQuanBdDQo8YnI+DQo8Yj5FbnZvecOp Jm5ic3A7OjwvYj4gbHVuZGkgNCBtYXJzIDIwMTkgMDk6MTM8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+ IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFlvc2hpZnVt aSBOaXNoaWRhOyB0Y3BtQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Rj cG1dIFVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy0wNTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIE1lZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgcHV0IG15IGNvbW1lbnQgaW4gbGluZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDI3 LCAyMDE5IGF0IDE6MzQgQU0gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIFlvc2hpLA0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bmlz aGlkYUBzZmMud2lkZS5hZC5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5pc2hpZGFAc2ZjLndpZGUuYWQu anA8L2E+XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDI3IGbDqXZyaWVy IDIwMTkgMTA6MTA8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9P TE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFlvc2hpZnVtaSBOaXNoaWRhOyA8YSBocmVmPSJtYWls dG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3RjcG1dIFVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1p ZXRmLXRjcG0tY29udmVydGVycy0wNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IaSBNZWQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIHB1dCBteSBjb21tZW50cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEZlYiAyNSwgMjAx OSBhdCAxMDo0MiBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBZb3NoaSw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFlvc2hpZnVtaSBOaXNoaWRhIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj5uaXNo aWRhQHNmYy53aWRlLmFkLmpwPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5k aSAyNSBmw6l2cmllciAyMDE5IDE5OjM1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIg TW9oYW1lZCBUR0kvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYTsg PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYu b3JnPC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt0Y3BtXSBVcGRhdGVkIHZlcnNp b24gb2YgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMtMDU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBNZWQsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB0aGUgdXBkYXRlcy4gSSBoYXZlIG9uZSBxdWVzdGlv bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGVuIHRoZSBjb252ZXJ0ZXIgZG9lcyBtcHRjcCBj b252ZXJzaW9uIGFuZCB0aGUgY2xpZW50IHdhbnRzIHRvIHVzZSBUTFMgZm9yIHRoZSBjb25uZWN0 aW9uLCBob3cgVExTIGlzIHVzZWQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUTFMgaXMgbWFuYWdlZCBlMmUgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgc2VydmVyLiBUaGUgY29udmVydGVyIGNhbiBvbmx5IHJlYWQvc3RyaXAg ZGF0YQ0KIHRoYXQgaXMgc3VwcGxpZWQgYnkgdGhlIGNsaWVudCBmb3IgdGhlIGNvbnZlcnNpb24g c2VydmljZS4gVW5saWtlIGRhdGEgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhl IHNlcnZlciwgdGhlIGRhdGEgdXNlZCBmb3IgY29udmVyc2lvbiBwdXJwb3NlcyBpcyBzdXBwbGll ZCBpbiBjbGVhciBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBjb252ZXJ0ZXIuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tIGEgZnVu Y3Rpb25hbCBzdGFuZHBvaW50LCB0aGUgZXN0YWJsaXNobWVudCBvZiBUTFMgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgc2VydmVyIGlzIHNpbWlsYXINCiB0byB0aGUgZXN0YWJsaXNobWVudCBv ZiBzdWNoIHNlc3Npb24gd2hlbiBhIE5BVC9OQVQ2IGlzIG9uLXBhdGguPC9zcGFuPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHdoZW4g dGhlIGNvbnZlcnRlciBkb2VzIG5vbi1tcHRjcCBjb252ZXJzaW9uLCBJIHRoaW5rIHRoZSBhYm92 ZSB0ZXh0cyBhcmUgY29ycmVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJZiBpdCBp cyBPSyBmb3Igc2ltcGxlIFRDUCwgdGhlbiBpdCBzaG91bGQgYmUgT0sgZm9yIE1QVENQOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayB0aGlzIGlzIGFsd2F5 cyB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgbXB0Y3AgY2xpZW50IHVzZXMgbXVsdGlwbGUgc3ViZmxvd3MgZm9yIHRoZSBtcHRjcCBj b25uZWN0aW9uLCBob3cgZG9lcyBpdCBsb29rcyB0byB0aGUgc2VydmVyPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIGl0IHNob3Vs ZCBiZSBhIHNpbmdsZSBjb25uZWN0aW9uIG9uIHRoZSBzZXJ2ZSBzaWRlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0LCB0aGlzIG1lYW5zIHdo ZW4geW91IGNvbnZlcnQgbXB0Y3AgaW50byB0Y3AsIHlvdSdsbCBuZWVkIHRvIG1lcmdlIG11bHRp cGxlIFRDUCBjb25uZWN0aW9ucyBpbnRvIGEgc2luZ2xlIFRDUCBjb25uZWN0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZXJnaW5n IHByb2Nlc3Mgd2lsbCBub3QgYmUgdmVyeSBlYXN5IHdoZW4gVExTIGFyZSB1c2VkIGZvciBzdWJm bG93cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5Eb2VzIHRoaXMgbWVhbnMgVExTIHdpbGwgYmUgdXNlZCBvbmx5IGJldHdlZW4gdGhlIGNv bnZlcnRlciBhbmQgdGhlIHNlcnZlciwgYnV0IG5vdCB1c2VkIGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIGNvbnZlcnRlcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gTm8uIFRMUyBp cyBtYW5hZ2VkIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGNvbnZlcnRlci4g VGhlIHNjb3BlIGlzIGFzIGZvbGxvd3M6DQogJm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBteSB1bmRlcnN0YW5kaW5n LCBpbiBjYXNlIG9mIG1wdGNwICYjNDM7IFRMUyBjYXNlLCBJIHRoaW5rIGl0IHNob3VsZCBiZSAo QSkgYXJjaGl0ZWN0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UbyBiZSBwcmVjaXNlLCBpdCB3aWxsIGJlIGxpa2UgdGhpcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Qy0tLS0tLUNvbnZlcnRlci0tLS0tUzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbHQ7PT09PT09PT0mZ3Q7Jmx0Oz09PT09PT09PT0mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZsdDs9PT09PT09PSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jmx0Oz09PT09 PT09Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbHQ7PT09PT09PT0mZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUTFMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVExTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28sIEkgdGhpbmsgaXQgbWVhbnMgbXB0Y3Ag JiM0MzsgVExTIGNhc2UgaXMgb3V0IG9mIGZvY3VzIGZvciB0aGlzIGRyYWZ0LiAod2hpY2ggaXMg ZmluZSB3aXRoIG1lLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGlzIGlzIG91dCBvZiBzY29w ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9rLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T3IsIHlvdSBjYW4gbWFrZSBhIHNwZWNpYWwgZXhjZXB0aW9uIHRvIGJyZWFrIGVu ZC10by1lbmQgcHJpbmNpcGxlIGluIHRoaXMgY2FzZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0LCBJIHRoaW5rIGl0IHdvdWxk IGJlIGdvb2QgaWYgdGhlIGRyYWZ0IGNsYXJpZmllcyB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdlIGFkZGVkIHRoaXMgTkVXIHRleHQgdG8gdGhl IGRyYWZ0Jm5ic3A7Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj7igJw8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0zMzYyNzEwMzE1MTY2 ODg2MDc4cGwtcyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SXQNCiBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudCB0 byBlbGFib3JhdGUgb24gY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byB0aGUgdXNlIG9mIFRMUyBp biB0aGUgQ2xpZW50LUNvbnZlcnRlciBjb25uZWN0aW9uIGxlZyB0byBleGNoYW5nZSBjb252ZXJz aW9uLXN1cHBsaWVkIGRhdGEu4oCdLjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhtbS4gSSdtIG5vdCB2ZXJ5IHN1cmUgaWYgdGhpcyB0ZXh0IGNhbiBhcHBseSBtcHRj cCBjYXNlcyB3ZWxsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgZnVsbHkgc3VyZSB3aGF0IGlzIGNvbnZlcnNpb24tc3Vw cGxpZWQgZGF0YSBpcywgaG93ZXZlciwgSSB0aGluayBtcHRjcCBjYXNlIGlzIHRoZSBjYXNlIHdo ZXJlIGEgY2xpZW50IHdhbnRzIHRvIHVzZSBUTFMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUg c2VydmVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WW9zaGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302EA27F2FOPEXCAUBMA2corp_-- From nobody Mon Mar 4 07:43:12 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7612D84C for ; Mon, 4 Mar 2019 07:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Rl_cF7-mda for ; Mon, 4 Mar 2019 07:43:06 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B9412870E for ; Mon, 4 Mar 2019 07:43:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id ADC9125A1D; Mon, 4 Mar 2019 16:43:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1551714183; bh=6qX2Xa/B772HsOBqx093KtK+d63PmCYsqqy5+G1BmSc=; h=From:To:Subject:Date:References:In-Reply-To:From; b=DK6ohO4NxWC3nIBcou0oY7PaJs+1cpbqGYm2uI/5W1J/uuiSoAZQAIOi4sN5SwZgZ oV0U3okqTjEAmkkJvTt/zKe3gmw1dIK7OYpAnZFAr+MIsp/NpygJ3zuy9yp4M8aKmR TKxmLHi8UqxTFhe9ebUi6Op/hxHKH5vecwfih5+4= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZiP53NkcY9v; Mon, 4 Mar 2019 16:43:02 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Mar 2019 16:43:02 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 4 Mar 2019 16:43:02 +0100 From: "Scharf, Michael" To: "mohamed.boucadair@orange.com" , "Olivier Bonaventure" , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxCAAErBwIAAO0+AgAASEMA= Date: Mon, 4 Mar 2019 15:43:01 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D24A93C@rznt8114.rznt.rzdir.fht-esslingen.de> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27EA2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA27EA2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.2.171] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 15:43:10 -0000 Inline [ms2] as far as not sorted out already -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Monday, March 04, 2019 3:43 PM To: Scharf, Michael; Olivier Bonaventure; tcpm@ietf.org Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > Envoy=E9=A0: lundi 4 mars 2019 12:37 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; tcpm@ietf.org > Objet=A0: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Med, >=20 > Please also see inline [ms]. I removed the parts that seem to be sorted o= ut. >=20 > Michael >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, March 04, 2019 7:50 AM > To: Scharf, Michael; Olivier Bonaventure; tcpm@ietf.org > Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Michael, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michae= l > > Envoy=E9=A0: lundi 4 mars 2019 00:48 > > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Hi Olivier, > > > > I have read -05. Please find below some comments/questions (with chair = hat > > off): > > > > - Page 8: Sorry if I missed this... Can a client ask the converter to s= end > > application data in the SYN payload data to the server (possibly even > without > > TFO option)? Is it correct that the Convert protocol does not allow suc= h > use > > of SYN payload data towards the remote host? > > >=20 > [Med] The Converter does not track whether a client has negotiated TFO, a= s > such any data supplied in the initial SYN is related to the server by the > converter. The following rule applies: >=20 > Any user data received by the Transport Converter over the upstream > (resp., downstream) connection is relayed over the downstream (resp., > upstream) connection. >=20 > [ms] That is pretty clear for all data in non-SYN segments. But IMHO it o= pens > room for interpretation _when_ to relay data included in any of the SYNs = and > SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or > whether it would be relayed after the three-way handshake. If the handlin= g of > SYN data is an internal decision of the converter implementation, IMHO th= e > draft could call that out explicitly. (I note that w/o TFO the use of pay= load > in SYNs should be a corner case, albeit allowed by TCP.) [Med] The above applies for both non-SYN and SYNs. We can make this explici= t: OLD:=20 Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. NEW:=20 Any user data received by the Transport Converter over the upstream (resp., downstream) connection is relayed over the downstream (resp., upstream) connection. In particular, if the initial SYN message contai= ns data in its payload (e.g., [RFC7413]), that data MUST be placed=20 right after the Convert TLVs when generating the relayed SYN. [ms2] Regarding the MUST: Theoretically, the Convert TLV plus the payload c= ould exceed the MTU... That is probably the corner case of a corner case. I= n that case, I actually believe it is not entirely obvious whether to reall= y use the SYN... Anyway, I don't have a specific preference how to handle S= YN payload in the converter. My concern is mainly to be (more) explicit abo= ut the fact that payload in SYN is possible in TCP, as this is IMHO somethi= ng implementers could easily get wrong. Also, note > that in the specific context of page 13 I wonder about payload data sent = in > the SYN sent from the remote host to the converter, i.e., that data is > destined _to the client_. >=20 > > - Page 18: Is my understanding correct that when a client sends a Conne= ct > TLV > > with one of its own addresses as "remote peer IP Address", then the > transport > > converter MUST attempt to establish this connection? >=20 > [Med] This is policy-based. The converter may restrict relying MPTCP > connections on its customer-facing interfaces or may relax it. > The draft can set a default behavior, though. >=20 > From where I sit, I'd like to allow for a possible future extension simil= ar > to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for > troubleshooting purposes. >=20 > What is your take on this? >=20 > [ms] The exact wording in -05 is: "Upon reception of a Connect TLV, and > absent any rate limit policy or resource exhaustion conditions, a Transpo= rt > Converter MUST attempt to establish a connection to the address and port = that > it contains." A later statement somehow contradicts this MUST requirement= : > "The Transport Converter may discard a Connect TLV request for various > reasons (e.g., authorization failed, out of resources, invalid address > type).". So probably the key question is why to have a capital letter MUS= T in > the first place? Of course, this question may matter for troubleshooting. >=20 [Med] Good point. We can update the text as follows:=20 OLD:=20 Upon reception of a Connect TLV, and absent any rate limit policy or resource exhaustion conditions, a Transport Converter MUST attempt to establish a connection to the address and port that it contains. The Transport Converter MUST use by default the TCP options that correspond to its local policy to establish this connection. These are the options that it advertises in the Supported TCP Extensions TLV. NEW: Upon reception of a Connect TLV, and absent any policy (e.g., rate-limit= ) or resource exhaustion conditions, a Transport Converter attempts to establish a connection to the address and port that it contains. The Transport Converter MUST use by default the TCP options that correspond to its local policy to establish this connection. These are the options that it advertises in the Supported TCP Extensions TLV. [ms2] That works for me > In other words, a > > converter that would _not_ set up this connection back to the client wo= uld > > violate the protocol specification? >=20 > [Med] No. >=20 > [ms] Well, in my reading such a converter policy would violates the MUST > cited above, albeit that may not be the intended meaning of the MUST. > Actually, I believe that the security considerations in Section 7 lack a > discussion of (firewall) policies on the client-facing interfaces/network= of > the converter. For instance, let's assume that in the client-facing netwo= rk > there would be firewall policies that prevent direct TCP connections betw= een > different clients, e.g., within the same Wifi network. Depending how the > converter deals with connect requests to IP addresses in the client-facin= g > network, clients could possibly use the converter to bypass firewall poli= cies > and setup "direct" communication via the converter? Isn't bypassing firew= all > rules something that could be relevant for Section 7? [Med] Actually, this is similar to hairpining for NATs (fwiw, the default b= ehavior is MUST be enabled; see https://tools.ietf.org/html/rfc4787#section= -6). =20 Whether this is enabled/disabled is deployment-specific. We can add some te= xt if you think this is helpful.=20 [ms2] I agree that this is not an entirely new problem, and I don't have an= y preference on whether to enable/disable this by default. Yet, I believe t= hat some warning signs would be useful in the security consideration sectio= n.=20 Michael From nobody Mon Mar 4 23:05:31 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB01130FCE for ; Mon, 4 Mar 2019 23:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 rvunoaw06kLC for ; Mon, 4 Mar 2019 23:05:28 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA243130FBD for ; Mon, 4 Mar 2019 23:05:27 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 44D7Fd65gsz200r; Tue, 5 Mar 2019 08:05:25 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 44D7Fd5HjpzyQ3; Tue, 5 Mar 2019 08:05:25 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0435.000; Tue, 5 Mar 2019 08:05:25 +0100 From: To: "Scharf, Michael" , Olivier Bonaventure , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxCAAErBwIAAO0+AgAASEMCAAQiJkA== Date: Tue, 5 Mar 2019 07:05:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA285CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27EA2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A93C@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D24A93C@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 07:05:31 -0000 Hi Michael, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > Envoy=E9=A0: lundi 4 mars 2019 16:43 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; tcpm@ietf.org > Objet=A0: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Inline [ms2] as far as not sorted out already >=20 ... > > > > > -----Message d'origine----- > > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Mich= ael > > > Envoy=E9=A0: lundi 4 mars 2019 00:48 > > > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > > > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > > > Hi Olivier, > > > > > > I have read -05. Please find below some comments/questions (with chai= r > hat > > > off): > > > > > > - Page 8: Sorry if I missed this... Can a client ask the converter to > send > > > application data in the SYN payload data to the server (possibly even > > without > > > TFO option)? Is it correct that the Convert protocol does not allow s= uch > > use > > > of SYN payload data towards the remote host? > > > > > > > [Med] The Converter does not track whether a client has negotiated TFO,= as > > such any data supplied in the initial SYN is related to the server by t= he > > converter. The following rule applies: > > > > Any user data received by the Transport Converter over the upstream > > (resp., downstream) connection is relayed over the downstream (resp.= , > > upstream) connection. > > > > [ms] That is pretty clear for all data in non-SYN segments. But IMHO it > opens > > room for interpretation _when_ to relay data included in any of the SYN= s > and > > SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or > > whether it would be relayed after the three-way handshake. If the handl= ing > of > > SYN data is an internal decision of the converter implementation, IMHO = the > > draft could call that out explicitly. (I note that w/o TFO the use of > payload > > in SYNs should be a corner case, albeit allowed by TCP.) >=20 > [Med] The above applies for both non-SYN and SYNs. We can make this expli= cit: >=20 > OLD: > Any user data received by the Transport Converter over the upstream > (resp., downstream) connection is relayed over the downstream (resp.= , > upstream) connection. >=20 > NEW: > Any user data received by the Transport Converter over the upstream > (resp., downstream) connection is relayed over the downstream (resp.= , > upstream) connection. In particular, if the initial SYN message cont= ains > data in its payload (e.g., [RFC7413]), that data MUST be placed > right after the Convert TLVs when generating the relayed SYN. >=20 > [ms2] Regarding the MUST: Theoretically, the Convert TLV plus the payload > could exceed the MTU... That is probably the corner case of a corner case= . In > that case, I actually believe it is not entirely obvious whether to reall= y > use the SYN... Anyway, I don't have a specific preference how to handle S= YN > payload in the converter. My concern is mainly to be (more) explicit abou= t > the fact that payload in SYN is possible in TCP, as this is IMHO somethin= g > implementers could easily get wrong. [Med] Agree.=20 >=20 > Also, note > > that in the specific context of page 13 I wonder about payload data sen= t in > > the SYN sent from the remote host to the converter, i.e., that data is > > destined _to the client_. > > > > > - Page 18: Is my understanding correct that when a client sends a Con= nect > > TLV > > > with one of its own addresses as "remote peer IP Address", then the > > transport > > > converter MUST attempt to establish this connection? > > > > [Med] This is policy-based. The converter may restrict relying MPTCP > > connections on its customer-facing interfaces or may relax it. > > The draft can set a default behavior, though. > > > > From where I sit, I'd like to allow for a possible future extension sim= ilar > > to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for > > troubleshooting purposes. > > > > What is your take on this? > > > > [ms] The exact wording in -05 is: "Upon reception of a Connect TLV, and > > absent any rate limit policy or resource exhaustion conditions, a Trans= port > > Converter MUST attempt to establish a connection to the address and por= t > that > > it contains." A later statement somehow contradicts this MUST requireme= nt: > > "The Transport Converter may discard a Connect TLV request for various > > reasons (e.g., authorization failed, out of resources, invalid address > > type).". So probably the key question is why to have a capital letter M= UST > in > > the first place? Of course, this question may matter for troubleshootin= g. > > >=20 > [Med] Good point. We can update the text as follows: >=20 > OLD: >=20 > Upon reception of a Connect TLV, and absent any rate limit policy or > resource exhaustion conditions, a Transport Converter MUST attempt to > establish a connection to the address and port that it contains. The > Transport Converter MUST use by default the TCP options that > correspond to its local policy to establish this connection. These > are the options that it advertises in the Supported TCP Extensions > TLV. >=20 >=20 > NEW: >=20 > Upon reception of a Connect TLV, and absent any policy (e.g., rate-lim= it) > or > resource exhaustion conditions, a Transport Converter attempts to > establish a connection to the address and port that it contains. The > Transport Converter MUST use by default the TCP options that > correspond to its local policy to establish this connection. These > are the options that it advertises in the Supported TCP Extensions > TLV. >=20 > [ms2] That works for me >=20 > > In other words, a > > > converter that would _not_ set up this connection back to the client > would > > > violate the protocol specification? > > > > [Med] No. > > > > [ms] Well, in my reading such a converter policy would violates the MUS= T > > cited above, albeit that may not be the intended meaning of the MUST. > > Actually, I believe that the security considerations in Section 7 lack = a > > discussion of (firewall) policies on the client-facing interfaces/netwo= rk > of > > the converter. For instance, let's assume that in the client-facing net= work > > there would be firewall policies that prevent direct TCP connections > between > > different clients, e.g., within the same Wifi network. Depending how th= e > > converter deals with connect requests to IP addresses in the client-fac= ing > > network, clients could possibly use the converter to bypass firewall > policies > > and setup "direct" communication via the converter? Isn't bypassing > firewall > > rules something that could be relevant for Section 7? >=20 > [Med] Actually, this is similar to hairpining for NATs (fwiw, the default > behavior is MUST be enabled; see https://tools.ietf.org/html/rfc4787#sect= ion- > 6). >=20 > Whether this is enabled/disabled is deployment-specific. We can add some = text > if you think this is helpful. >=20 > [ms2] I agree that this is not an entirely new problem, and I don't have = any > preference on whether to enable/disable this by default. Yet, I believe t= hat > some warning signs would be useful in the security consideration section. [Med] I added this NEW text:=20 In deployments where network-assisted connections are not allowed between hosts of a domain (i.e., hairpinning is not allowed),=20 the Converter may be instructed to discard such connections. Absent explicit configuration otherwise, hairpinning is enabled by the Converter (sse {{fig-hairp}}. =20 >=20 > Michael From nobody Tue Mar 5 00:33:01 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9B312785F for ; Tue, 5 Mar 2019 00:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxC8H6ZSsj5w for ; Tue, 5 Mar 2019 00:32:57 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92A9124B0C for ; Tue, 5 Mar 2019 00:32:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0E8ED25A21; Tue, 5 Mar 2019 09:32:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1551774775; bh=DrFELmhzBHahZp/Z1pr7soQTM3Eo/7jUZTsxDlWDWoU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=vpTEqplMMTnBGpB5+vWBA/yYuEqUS/CEQHMQXHOdu6fLoFXEVF7PbpAo2SWYeElcg 9TMQHv8a9awPNub8LA7r2ACsKek3Ui4ThrR47epL7UCE++iEeHBLIz0fue+keMJO7r JgkpiPAFQQhpu0hdnnOou8auAFTDkqiQmRytb2IE= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 134a0xz1Yydq; Tue, 5 Mar 2019 09:32:53 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 5 Mar 2019 09:32:53 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 5 Mar 2019 09:32:53 +0100 From: "Scharf, Michael" To: "mohamed.boucadair@orange.com" , "Olivier Bonaventure" , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxCAAErBwIAAO0+AgAASEMCAAQiJkIAAGGBw Date: Tue, 5 Mar 2019 08:32:53 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D24B7D9@rznt8114.rznt.rzdir.fht-esslingen.de> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27EA2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A93C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA285CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA285CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 08:33:00 -0000 Inline [ms3] Michael > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, March 5, 2019 8:05 AM > To: Scharf, Michael; Olivier Bonaventure; tcpm@ietf.org > Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Hi Michael, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > > Envoy=E9=A0: lundi 4 mars 2019 16:43 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; tcpm@ietf.org > > Objet=A0: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Inline [ms2] as far as not sorted out already > > > ... > > > > > > > -----Message d'origine----- > > > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, > Michael > > > > Envoy=E9=A0: lundi 4 mars 2019 00:48 > > > > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > > > > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converters- > 05 > > > > > > > > Hi Olivier, > > > > > > > > I have read -05. Please find below some comments/questions (with > chair > > hat > > > > off): > > > > > > > > - Page 8: Sorry if I missed this... Can a client ask the > converter to > > send > > > > application data in the SYN payload data to the server (possibly > even > > > without > > > > TFO option)? Is it correct that the Convert protocol does not > allow such > > > use > > > > of SYN payload data towards the remote host? > > > > > > > > > > [Med] The Converter does not track whether a client has negotiated > TFO, as > > > such any data supplied in the initial SYN is related to the server > by the > > > converter. The following rule applies: > > > > > > Any user data received by the Transport Converter over the > upstream > > > (resp., downstream) connection is relayed over the downstream > (resp., > > > upstream) connection. > > > > > > [ms] That is pretty clear for all data in non-SYN segments. But > IMHO it > > opens > > > room for interpretation _when_ to relay data included in any of the > SYNs > > and > > > SYN,ACK, i.e., whether it would be relayed in SYN segments as well, > or > > > whether it would be relayed after the three-way handshake. If the > handling > > of > > > SYN data is an internal decision of the converter implementation, > IMHO the > > > draft could call that out explicitly. (I note that w/o TFO the use > of > > payload > > > in SYNs should be a corner case, albeit allowed by TCP.) > > > > [Med] The above applies for both non-SYN and SYNs. We can make this > explicit: > > > > OLD: > > Any user data received by the Transport Converter over the > upstream > > (resp., downstream) connection is relayed over the downstream > (resp., > > upstream) connection. > > > > NEW: > > Any user data received by the Transport Converter over the > upstream > > (resp., downstream) connection is relayed over the downstream > (resp., > > upstream) connection. In particular, if the initial SYN message > contains > > data in its payload (e.g., [RFC7413]), that data MUST be placed > > right after the Convert TLVs when generating the relayed SYN. > > > > [ms2] Regarding the MUST: Theoretically, the Convert TLV plus the > payload > > could exceed the MTU... That is probably the corner case of a corner > case. In > > that case, I actually believe it is not entirely obvious whether to > really > > use the SYN... Anyway, I don't have a specific preference how to > handle SYN > > payload in the converter. My concern is mainly to be (more) explicit > about > > the fact that payload in SYN is possible in TCP, as this is IMHO > something > > implementers could easily get wrong. >=20 > [Med] Agree. [ms3] To be precise, it is not entirely clear to me whether the MUST is rea= lly required. But if implementers would deal with SYN payload this way, the= proposed wording would work for me. > > Also, note > > > that in the specific context of page 13 I wonder about payload data > sent in > > > the SYN sent from the remote host to the converter, i.e., that data > is > > > destined _to the client_. > > > > > > > - Page 18: Is my understanding correct that when a client sends a > Connect > > > TLV > > > > with one of its own addresses as "remote peer IP Address", then > the > > > transport > > > > converter MUST attempt to establish this connection? > > > > > > [Med] This is policy-based. The converter may restrict relying > MPTCP > > > connections on its customer-facing interfaces or may relax it. > > > The draft can set a default behavior, though. > > > > > > From where I sit, I'd like to allow for a possible future extension > similar > > > to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 > for > > > troubleshooting purposes. > > > > > > What is your take on this? > > > > > > [ms] The exact wording in -05 is: "Upon reception of a Connect TLV, > and > > > absent any rate limit policy or resource exhaustion conditions, a > Transport > > > Converter MUST attempt to establish a connection to the address and > port > > that > > > it contains." A later statement somehow contradicts this MUST > requirement: > > > "The Transport Converter may discard a Connect TLV request for > various > > > reasons (e.g., authorization failed, out of resources, invalid > address > > > type).". So probably the key question is why to have a capital > letter MUST > > in > > > the first place? Of course, this question may matter for > troubleshooting. > > > > > > > [Med] Good point. We can update the text as follows: > > > > OLD: > > > > Upon reception of a Connect TLV, and absent any rate limit policy > or > > resource exhaustion conditions, a Transport Converter MUST attempt > to > > establish a connection to the address and port that it contains. > The > > Transport Converter MUST use by default the TCP options that > > correspond to its local policy to establish this connection. > These > > are the options that it advertises in the Supported TCP Extensions > > TLV. > > > > > > NEW: > > > > Upon reception of a Connect TLV, and absent any policy (e.g., > rate-limit) > > or > > resource exhaustion conditions, a Transport Converter attempts to > > establish a connection to the address and port that it contains. > The > > Transport Converter MUST use by default the TCP options that > > correspond to its local policy to establish this connection. > These > > are the options that it advertises in the Supported TCP Extensions > > TLV. > > > > [ms2] That works for me > > > > > In other words, a > > > > converter that would _not_ set up this connection back to the > client > > would > > > > violate the protocol specification? > > > > > > [Med] No. > > > > > > [ms] Well, in my reading such a converter policy would violates the > MUST > > > cited above, albeit that may not be the intended meaning of the > MUST. > > > Actually, I believe that the security considerations in Section 7 > lack a > > > discussion of (firewall) policies on the client-facing > interfaces/network > > of > > > the converter. For instance, let's assume that in the client-facing > network > > > there would be firewall policies that prevent direct TCP > connections > > between > > > different clients, e.g., within the same Wifi network. Depending > how the > > > converter deals with connect requests to IP addresses in the > client-facing > > > network, clients could possibly use the converter to bypass > firewall > > policies > > > and setup "direct" communication via the converter? Isn't bypassing > > firewall > > > rules something that could be relevant for Section 7? > > > > [Med] Actually, this is similar to hairpining for NATs (fwiw, the > default > > behavior is MUST be enabled; see > https://tools.ietf.org/html/rfc4787#section- > > 6). > > > > Whether this is enabled/disabled is deployment-specific. We can add > some text > > if you think this is helpful. > > > > [ms2] I agree that this is not an entirely new problem, and I don't > have any > > preference on whether to enable/disable this by default. Yet, I > believe that > > some warning signs would be useful in the security consideration > section. >=20 > [Med] I added this NEW text: >=20 > In deployments where network-assisted connections are not allowed > between hosts of a domain (i.e., hairpinning is not allowed), > the Converter may be instructed to discard such connections. Absent > explicit configuration otherwise, hairpinning is enabled by > the Converter (sse {{fig-hairp}}. [ms3] Works for me Thanks Michael From nobody Tue Mar 5 00:55:35 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B9812DDA3 for ; Tue, 5 Mar 2019 00:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sX5G-HGBy0J2 for ; Tue, 5 Mar 2019 00:55:31 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A722112785F for ; Tue, 5 Mar 2019 00:55:30 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 44D9hd0lLmz5wD6; Tue, 5 Mar 2019 09:55:29 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 44D9hc74qgzDq7J; Tue, 5 Mar 2019 09:55:28 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0435.000; Tue, 5 Mar 2019 09:55:28 +0100 From: To: "Scharf, Michael" , Olivier Bonaventure , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHUv86JmdngfITgq0CMtVlOHS+P7aX6oiiggACAVxCAAErBwIAAO0+AgAASEMCAAQiJkIAAGGBwgAAE1uA= Date: Tue, 5 Mar 2019 08:55:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA2868B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <6EC6417807D9754DA64F3087E2E2E03E2D248C3C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27A85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A4B4@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA27EA2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24A93C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EA285CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D24B7D9@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D24B7D9@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 08:55:34 -0000 Re, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > Envoy=E9=A0: mardi 5 mars 2019 09:33 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; tcpm@ietf.org > Objet=A0: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 >=20 > Inline [ms3] >=20 > Michael >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, March 5, 2019 8:05 AM > > To: Scharf, Michael; Olivier Bonaventure; tcpm@ietf.org > > Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > Hi Michael, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > > > Envoy=E9=A0: lundi 4 mars 2019 16:43 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; tcpm@ietf.org > > > Objet=A0: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05 > > > > > > Inline [ms2] as far as not sorted out already > > > > > ... > > > > > > > > > -----Message d'origine----- > > > > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, > > Michael > > > > > Envoy=E9=A0: lundi 4 mars 2019 00:48 > > > > > =C0=A0: Olivier Bonaventure; tcpm@ietf.org > > > > > Objet=A0: Re: [tcpm] Updated version of draft-ietf-tcpm-converter= s- > > 05 > > > > > > > > > > Hi Olivier, > > > > > > > > > > I have read -05. Please find below some comments/questions (with > > chair > > > hat > > > > > off): > > > > > > > > > > - Page 8: Sorry if I missed this... Can a client ask the > > converter to > > > send > > > > > application data in the SYN payload data to the server (possibly > > even > > > > without > > > > > TFO option)? Is it correct that the Convert protocol does not > > allow such > > > > use > > > > > of SYN payload data towards the remote host? > > > > > > > > > > > > > [Med] The Converter does not track whether a client has negotiated > > TFO, as > > > > such any data supplied in the initial SYN is related to the server > > by the > > > > converter. The following rule applies: > > > > > > > > Any user data received by the Transport Converter over the > > upstream > > > > (resp., downstream) connection is relayed over the downstream > > (resp., > > > > upstream) connection. > > > > > > > > [ms] That is pretty clear for all data in non-SYN segments. But > > IMHO it > > > opens > > > > room for interpretation _when_ to relay data included in any of the > > SYNs > > > and > > > > SYN,ACK, i.e., whether it would be relayed in SYN segments as well, > > or > > > > whether it would be relayed after the three-way handshake. If the > > handling > > > of > > > > SYN data is an internal decision of the converter implementation, > > IMHO the > > > > draft could call that out explicitly. (I note that w/o TFO the use > > of > > > payload > > > > in SYNs should be a corner case, albeit allowed by TCP.) > > > > > > [Med] The above applies for both non-SYN and SYNs. We can make this > > explicit: > > > > > > OLD: > > > Any user data received by the Transport Converter over the > > upstream > > > (resp., downstream) connection is relayed over the downstream > > (resp., > > > upstream) connection. > > > > > > NEW: > > > Any user data received by the Transport Converter over the > > upstream > > > (resp., downstream) connection is relayed over the downstream > > (resp., > > > upstream) connection. In particular, if the initial SYN message > > contains > > > data in its payload (e.g., [RFC7413]), that data MUST be placed > > > right after the Convert TLVs when generating the relayed SYN. > > > > > > [ms2] Regarding the MUST: Theoretically, the Convert TLV plus the > > payload > > > could exceed the MTU... That is probably the corner case of a corner > > case. In > > > that case, I actually believe it is not entirely obvious whether to > > really > > > use the SYN... Anyway, I don't have a specific preference how to > > handle SYN > > > payload in the converter. My concern is mainly to be (more) explicit > > about > > > the fact that payload in SYN is possible in TCP, as this is IMHO > > something > > > implementers could easily get wrong. > > > > [Med] Agree. >=20 > [ms3] To be precise, it is not entirely clear to me whether the MUST is > really required. But if implementers would deal with SYN payload this way= , > the proposed wording would work for me. [Med] The intent is to cover relaying data even when included in a SYN.=20 The text does not mention the "corner case of the corner case" you indicate= d because the document targets deployments in single domains for which we a= ssume that the MTU is well-managed. This is aligned with the reco in https:= //tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02#section-9: In summary: o In some deployments an encapsulation can assume well-managed MTU hence no need for fragmentation and reassembly related to the encapsulation.=20 Obviously, we don't have MTU issues for non-SYN and non-initial SYNs. =20 >=20 > > > Also, note > > > > that in the specific context of page 13 I wonder about payload data > > sent in > > > > the SYN sent from the remote host to the converter, i.e., that data > > is > > > > destined _to the client_. > > > > > > > > > - Page 18: Is my understanding correct that when a client sends a > > Connect > > > > TLV > > > > > with one of its own addresses as "remote peer IP Address", then > > the > > > > transport > > > > > converter MUST attempt to establish this connection? > > > > > > > > [Med] This is policy-based. The converter may restrict relying > > MPTCP > > > > connections on its customer-facing interfaces or may relax it. > > > > The draft can set a default behavior, though. > > > > > > > > From where I sit, I'd like to allow for a possible future extension > > similar > > > > to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 > > for > > > > troubleshooting purposes. > > > > > > > > What is your take on this? > > > > > > > > [ms] The exact wording in -05 is: "Upon reception of a Connect TLV, > > and > > > > absent any rate limit policy or resource exhaustion conditions, a > > Transport > > > > Converter MUST attempt to establish a connection to the address and > > port > > > that > > > > it contains." A later statement somehow contradicts this MUST > > requirement: > > > > "The Transport Converter may discard a Connect TLV request for > > various > > > > reasons (e.g., authorization failed, out of resources, invalid > > address > > > > type).". So probably the key question is why to have a capital > > letter MUST > > > in > > > > the first place? Of course, this question may matter for > > troubleshooting. > > > > > > > > > > [Med] Good point. We can update the text as follows: > > > > > > OLD: > > > > > > Upon reception of a Connect TLV, and absent any rate limit policy > > or > > > resource exhaustion conditions, a Transport Converter MUST attempt > > to > > > establish a connection to the address and port that it contains. > > The > > > Transport Converter MUST use by default the TCP options that > > > correspond to its local policy to establish this connection. > > These > > > are the options that it advertises in the Supported TCP Extensions > > > TLV. > > > > > > > > > NEW: > > > > > > Upon reception of a Connect TLV, and absent any policy (e.g., > > rate-limit) > > > or > > > resource exhaustion conditions, a Transport Converter attempts to > > > establish a connection to the address and port that it contains. > > The > > > Transport Converter MUST use by default the TCP options that > > > correspond to its local policy to establish this connection. > > These > > > are the options that it advertises in the Supported TCP Extensions > > > TLV. > > > > > > [ms2] That works for me > > > > > > > In other words, a > > > > > converter that would _not_ set up this connection back to the > > client > > > would > > > > > violate the protocol specification? > > > > > > > > [Med] No. > > > > > > > > [ms] Well, in my reading such a converter policy would violates the > > MUST > > > > cited above, albeit that may not be the intended meaning of the > > MUST. > > > > Actually, I believe that the security considerations in Section 7 > > lack a > > > > discussion of (firewall) policies on the client-facing > > interfaces/network > > > of > > > > the converter. For instance, let's assume that in the client-facing > > network > > > > there would be firewall policies that prevent direct TCP > > connections > > > between > > > > different clients, e.g., within the same Wifi network. Depending > > how the > > > > converter deals with connect requests to IP addresses in the > > client-facing > > > > network, clients could possibly use the converter to bypass > > firewall > > > policies > > > > and setup "direct" communication via the converter? Isn't bypassing > > > firewall > > > > rules something that could be relevant for Section 7? > > > > > > [Med] Actually, this is similar to hairpining for NATs (fwiw, the > > default > > > behavior is MUST be enabled; see > > https://tools.ietf.org/html/rfc4787#section- > > > 6). > > > > > > Whether this is enabled/disabled is deployment-specific. We can add > > some text > > > if you think this is helpful. > > > > > > [ms2] I agree that this is not an entirely new problem, and I don't > > have any > > > preference on whether to enable/disable this by default. Yet, I > > believe that > > > some warning signs would be useful in the security consideration > > section. > > > > [Med] I added this NEW text: > > > > In deployments where network-assisted connections are not allowed > > between hosts of a domain (i.e., hairpinning is not allowed), > > the Converter may be instructed to discard such connections. Absent > > explicit configuration otherwise, hairpinning is enabled by > > the Converter (sse {{fig-hairp}}. >=20 > [ms3] Works for me >=20 > Thanks >=20 > Michael From nobody Wed Mar 6 04:45:13 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61796130EDB; Wed, 6 Mar 2019 04:45:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <155187630831.24626.4470552298232758878@ietfa.amsl.com> Date: Wed, 06 Mar 2019 04:45:08 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 12:45:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Benjamin Hesmans Filename : draft-ietf-tcpm-converters-06.txt Pages : 44 Date : 2019-03-06 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-06 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 6 04:50:36 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0B130EC6 for ; Wed, 6 Mar 2019 04:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 a9aaKak9lCVG for ; Wed, 6 Mar 2019 04:50:33 -0800 (PST) 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 10AD41292F1 for ; Wed, 6 Mar 2019 04:50:33 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 44DtsM244Sz2yXF for ; Wed, 6 Mar 2019 13:50:31 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 44DtsM07tFzCqkS for ; Wed, 6 Mar 2019 13:50:31 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0435.000; Wed, 6 Mar 2019 13:50:30 +0100 From: To: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-06.txt Thread-Index: AQHU1Bp9VSLN2dAF/UuqnPwl0WOCtaX+jRwQ Date: Wed, 6 Mar 2019 12:50:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA2974F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155187630831.24626.4470552298232758878@ietfa.amsl.com> In-Reply-To: <155187630831.24626.4470552298232758878@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] 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-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 12:50:35 -0000 Hi all,=20 This new version integrates the comments from Yoshi and Michael. The main c= hanges are:=20 * Reiterate the scope * Updated IANA policy to require "IETF Review" instead of "Standard Action= "=09 * Call out explicitly that data in SYNs are relayed by the Converter=09 * Hairpinning behavior can be disabled (policy-based)=09 * Fix some nits We do think that the document is ready for WGLC.=20 Cheers, Olivier & Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 6 mars 2019 13:45 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: [tcpm] I-D Action: draft-ietf-tcpm-converters-06.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 > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-06.txt > Pages : 44 > Date : 2019-03-06 >=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). >=20 > 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 0-RTT TCP Convert 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-06 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-06 >=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 From nobody Wed Mar 6 14:48:34 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0210F131065 for ; Wed, 6 Mar 2019 14:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leE7pS_6E5Cp for ; Wed, 6 Mar 2019 14:48:30 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE043130F70 for ; Wed, 6 Mar 2019 14:48:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1809725A13 for ; Wed, 6 Mar 2019 23:48:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1551912508; bh=laSZk9WnaG0lfuF4eQ4JuDbCm6BMy6OYg+rd7RtFJNc=; h=From:To:Subject:Date:From; b=pRzd92+fRyWCWA6EEbOJo5yVMio2QEmN7lmiG5UpjgHSanf4UuufhuLRsC+5wrEZh pYT70ybd0sUnCT7SVTUcMWyOkOHtaT9NU6iuss3L94sv8PczYmGyeH69u8NRy1Y22M u8UEh1PoIPaqJJqy8Em4o42AwkIRXwWnKARI7SyM= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXbKWZ1TePau for ; Wed, 6 Mar 2019 23:48:27 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Wed, 6 Mar 2019 23:48:27 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Wed, 6 Mar 2019 23:48:26 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status Thread-Index: AQHU1G616iHOJHkpoEO6XOB3g3fkFQ== Date: Wed, 6 Mar 2019 22:48:26 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D24EEA4@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 22:48:34 -0000 SGkgYWxsLA0KDQpUaGUgZG9jdW1lbnQgZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzIGhhcyBiZWVu IGRpc2N1c3NlZCBxdWl0ZSBhIGJpdCBpbiBUQ1BNLiBPbmUgcXVlc3Rpb24gaGFzIGJlZW4gdGhl IHN0YXR1cyAoQkNQIG9yIElORk8pLiBUaGUgdmVyc2lvbiBkcmFmdC10b3VjaC10Y3BtLTIxNDBi aXMtMDYgZXhwbGljaXRseSB0YXJnZXRzIGluZm9ybWF0aW9uYWwgc3RhdHVzIGFuZCBwbGFucyB0 byBvYnNvbGV0ZSBSRkMgMjE0MCAod2hpY2ggaXMgaW5mb3JtYXRpb25hbCwgdG9vKS4NCg0KVGhl IGludGVudGlvbiBvZiB0aGlzIGUtbWFpbCBpcyB0byBjb25maXJtIHRoYXQgZHJhZnQtdG91Y2gt dGNwbS0yMTQwYmlzLTA2IHNob3VsZCBiZSBhZG9wdGVkIGFzIGluZm9ybWF0aW9uYWwgVENQTSB3 b3JraW5nIGdyb3VwIGl0ZW0sIGkuZS4sIHRoYXQgYSBuZXcgaXRlbSBzaG91bGQgYmUgYWRkZWQg dG8gdGhlIFRDUE0gY2hhcnRlcjoNCg0KICBOb3YuIDIwMTkgIFN1Ym1pdCBkb2N1bWVudCBvbiBU Q1AgQ29udHJvbCBCbG9jayBJbnRlcmRlcGVuZGVuY2UgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0 aW9uIGFzIEluZm9ybWF0aW9uYWwgUkZDIA0KDQpUaGUgYWRvcHRpb24gY2FsbCBydW5zIG9uIHRo ZSBUQ1BNIG1haWxpbmcgbGlzdCB1bnRpbCBNYXJjaCAyMi4gUGxlYXNlIGxldCB1cyBrbm93IGlm IHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCwgb3IgaWYgdGhlcmUgYXJlIGFu eSBjb25jZXJucy4NCg0KQmVzdCByZWdhcmRzDQoNCk1pY2hhZWwNCihUQ1BNIGNvLWNoYWlyKQ0K DQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpGcm9tOiB0Y3BtIFttYWls dG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lIFRvdWNoDQpTZW50OiBG cmlkYXksIEphbnVhcnkgNCwgMjAxOSA1OjUyIFBNDQpUbzogdGNwbUBpZXRmLm9yZw0KU3ViamVj dDogW3RjcG1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10b3VjaC10 Y3BtLTIxNDBiaXMtMDYudHh0DQoNCkZZSSAtIA0KVGhpcyB2ZXJzaW9uOg0KwqDCoMKgIC0gb2Jz b2xldGVzIDIxNDANCsKgwqDCoCAtIHNheXMgc28gaW4gdGhlIGFic3RyYWN0IGFuZCBpbnRybw0K wqDCoMKgIC0gaW5jbHVkZXMgYSAiY2hhbmdlcyBmcm9tIDIxNDAiIHNlY3Rpb24gc3VtbWFyaXpp bmcgdGhlIGRpZmZlcmVuY2VzDQpOb3RlIHRoYXQgdGhlIGVhcmxpZXIgdmVyc2lvbnMgZGlkIGNp dGUgMjE0MCwgYnV0IGRpZCBub3QgYXMgZGlyZWN0bHkgaW5kaWNhdGUgdGhhdCB0aGlzIGlzIGlu dGVuZGVkIGFzIGl0cyByZXBsYWNlbWVudC4NCkpvZQ0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVz c2FnZSAtLS0tLS0tLSANClN1YmplY3Q6IA0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC10b3VjaC10Y3BtLTIxNDBiaXMtMDYudHh0DQpEYXRlOiANCkZyaSwgMDQgSmFuIDIwMTkg MDg6NDk6MjUgLTA4MDANCkZyb206IA0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpUbzogDQpT YWZpcXVsIElzbGFtIDxzYWZpcXVsaUBpZmkudWlvLm5vPiwgTWljaGFlbCBXZWx6bCA8bWljaGF3 ZUBpZmkudWlvLm5vPiwgSm9zZXBoIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbT4sIEpvZSBU b3VjaCA8dG91Y2hAc3RyYXlhbHBoYS5jb20+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzLTA2LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBKb2UgVG91Y2ggYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzDQpSZXZpc2lvbjogMDYNClRpdGxlOiBU Q1AgQ29udHJvbCBCbG9jayBJbnRlcmRlcGVuZGVuY2UNCkRvY3VtZW50IGRhdGU6IDIwMTktMDEt MDQNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAyMg0KVVJMOiBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzLTA2 LnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10b3Vj aC10Y3BtLTIxNDBiaXMvDQpIdG1saXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0wNg0KSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzDQpEaWZmOiBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzLTA2DQoN CkFic3RyYWN0Og0KVGhpcyBtZW1vIHVwZGF0ZXMgYW5kIHJlcGxhY2VzIFJGQyAyMTQwJ3MgZGVz Y3JpcHRpb24gb2YNCmludGVyZGVwZW5kZW50IFRDUCBjb250cm9sIGJsb2NrcywgaW4gd2hpY2gg cGFydCBvZiB0aGUgVENQIHN0YXRlIGlzDQpzaGFyZWQgYW1vbmcgc2ltaWxhciBjb25jdXJyZW50 IG9yIGNvbnNlY3V0aXZlIGNvbm5lY3Rpb25zLiBUQ1ANCnN0YXRlIGluY2x1ZGVzIGEgY29tYmlu YXRpb24gb2YgcGFyYW1ldGVycywgc3VjaCBhcyBjb25uZWN0aW9uDQpzdGF0ZSwgY3VycmVudCBy b3VuZC10cmlwIHRpbWUgZXN0aW1hdGVzLCBjb25nZXN0aW9uIGNvbnRyb2wNCmluZm9ybWF0aW9u LCBhbmQgcHJvY2VzcyBpbmZvcm1hdGlvbi4gTW9zdCBvZiB0aGlzIHN0YXRlIGlzDQptYWludGFp bmVkIG9uIGEgcGVyLWNvbm5lY3Rpb24gYmFzaXMgaW4gdGhlIFRDUCBDb250cm9sIEJsb2NrIChU Q0IpLA0KYnV0IGltcGxlbWVudGF0aW9ucyBjYW4gKGFuZCBkbykgc2hhcmUgY2VydGFpbiBUQ0Ig aW5mb3JtYXRpb24NCmFjcm9zcyBjb25uZWN0aW9ucyB0byB0aGUgc2FtZSBob3N0LiBTdWNoIHNo YXJpbmcgaXMgaW50ZW5kZWQgdG8NCmltcHJvdmUgb3ZlcmFsbCB0cmFuc2llbnQgdHJhbnNwb3J0 IHBlcmZvcm1hbmNlLCB3aGlsZSBtYWludGFpbmluZw0KYmFja3dhcmQtY29tcGF0aWJpbGl0eSB3 aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gVGhlIHNoYXJpbmcNCmRlc2NyaWJlZCBoZXJl aW4gaXMgbGltaXRlZCB0byBvbmx5IHRoZSBUQ0IgaW5pdGlhbGl6YXRpb24gYW5kIHNvDQpoYXMg bm8gZWZmZWN0IG9uIHRoZSBsb25nLXRlcm0gYmVoYXZpb3Igb2YgVENQIGFmdGVyIGEgY29ubmVj dGlvbg0KaGFzIGJlZW4gZXN0YWJsaXNoZWQuDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From nobody Sat Mar 9 23:56:31 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2729012787E; Sat, 9 Mar 2019 23:56:23 -0800 (PST) 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 lrOCpyWr-gTB; Sat, 9 Mar 2019 23:56:20 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2F0126DFA; Sat, 9 Mar 2019 23:56:19 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x2A7uA7k052331; Sun, 10 Mar 2019 08:56:10 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 2680B1D53C1; Sun, 10 Mar 2019 08:56:10 +0100 (CET) Received: from 90.221.200.240 by webmail.entel.upc.edu with HTTP; Sun, 10 Mar 2019 08:56:10 +0100 Message-ID: Date: Sun, 10 Mar 2019 08:56:10 +0100 From: "Carles Gomez Montenegro" To: lwip@ietf.org, tcpm@ietf.org Cc: michael.scharf@hs-esslingen.de, jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sun, 10 Mar 2019 08:56:10 +0100 (CET) Archived-At: Subject: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-05.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 07:56:23 -0000 Dear LWIP and TCPM WGs, First of all, thanks to everyone who provided feedback on revision -04 of our "TCP Usage Guidance in the Internet of Things (IoT)" draft. Please find below the pointers to an update of the draft (revision -05), based on the comments received. Main changes: o Addressed comments by Yoshifumi Nishida o Removed mentioning MD5 as an example (comment by David Black) o Added memory footprint details of TCP implementations (Contiki-NG and lwIP 2.1.2) provided by Rahul Jadhav in the Annex [1] o Addressed comments by Ilpo Jarvinen throughout the whole document o Improved the RIOT section in the Annex, based on feedback from Emmanuel Baccelli [1] Rahul kindly performed memory footprint measurements for the sake of this draft (feel free to visit https://github.com/nyrahul/sizeof) The authors believe that the document is now ready for WGLC. Cheers, Carles (on behalf of all authors) ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-05.txt From: internet-drafts@ietf.org Date: Sun, March 10, 2019 8:39 am To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-05.txt Pages : 26 Date : 2019-03-09 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-05 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From jwalter03@frostburg.edu Sat Mar 9 12:35:10 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C7A124B91 for ; Sat, 9 Mar 2019 12:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frostburg.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 7dDKPKxR86ak for ; Sat, 9 Mar 2019 12:35:08 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680108.outbound.protection.outlook.com [40.107.68.108]) (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 00AFB124B19 for ; Sat, 9 Mar 2019 12:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=frostburg.onmicrosoft.com; s=selector1-frostburg-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MguA9SGqG6i8sFq9pid1aQkj2DgcQVoRHbUxwO+HHz4=; b=F6wY/B2gujw8rpxSNaGk7wqttZmXCwlm+OxBidnsByvh+SuWcDLx1GnCQwg4hD+buD7Y96Be3aYiBlao2wiU6vzLT4XhCDoCbZS6xkXdYULhYF6UeHVOm0Z6b43aAn3G9YQWPU8oJQOlTjDVRSqDveT5MU3dK4HZYwX+cWaT5vY= Received: from SN4PR0701MB3776.namprd07.prod.outlook.com (10.167.142.31) by SN4PR0701MB3773.namprd07.prod.outlook.com (10.167.150.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Sat, 9 Mar 2019 20:35:03 +0000 Received: from SN4PR0701MB3776.namprd07.prod.outlook.com ([fe80::442b:eb4a:67db:55af]) by SN4PR0701MB3776.namprd07.prod.outlook.com ([fe80::442b:eb4a:67db:55af%4]) with mapi id 15.20.1686.019; Sat, 9 Mar 2019 20:35:03 +0000 From: Jonathan Walter To: "tcpm@ietf.org" Thread-Topic: RFC 6298 Thread-Index: AQHU1rcC7jsh4P0lCEiAdwabPwjz5g== Date: Sat, 9 Mar 2019 20:35:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.73.186.15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82f0fa57-3f89-4101-cee3-08d6a4ceb59c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN4PR0701MB3773; x-ms-traffictypediagnostic: SN4PR0701MB3773: x-microsoft-exchange-diagnostics: 1; SN4PR0701MB3773; 20:KbKWdBRuinakM2VvVEdJMAalpFY/kubCggC6OyNCrZ1rwGPH6UMxn0DT/3vQZ8SqKSvOFjzIPpcwCUI+CO+JN4gneCmp1lOniq/bM99frf35N+JJANuqOf8eDHtawqiXJBt/CSaleU+do1hhGz7c3I8ThNKc36wahu6FCIBOPAk= x-microsoft-antispam-prvs: x-forefront-prvs: 0971922F40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(136003)(366004)(346002)(376002)(199004)(189003)(52536013)(75432002)(33656002)(2501003)(97736004)(2906002)(88552002)(68736007)(413944005)(256004)(8936002)(4744005)(7116003)(71200400001)(5660300002)(71190400001)(316002)(786003)(86362001)(3846002)(6116002)(14454004)(81166006)(1730700003)(81156014)(6436002)(54896002)(476003)(9686003)(66066001)(99286004)(19627405001)(55016002)(8676002)(478600001)(2351001)(106356001)(105586002)(74316002)(6916009)(25786009)(105004)(102836004)(486006)(6346003)(6506007)(7696005)(186003)(26005)(5640700003)(53936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR0701MB3773; H:SN4PR0701MB3776.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: frostburg.edu does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jwalter03@frostburg.edu; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1Td9gpJoe2nk8UyzCj7jSxZVVJUGY6IohQVW/CMYu/U+iDtMkXOaJwQXzMPZD0f5cAwHA2FE1UIRbJqZkHVUwSbgbs58xy5Yt/92qa1AVljAGjwY9JtGrwhVqoZXM7zcNGi/aCltdcPpRNq2rhZQfePMIR8whyqXrHCxAx+7QOoPQCu0wgl8vWvqmsTyPH2OEMlYLGVwy23ymbxSRINde5SlYxC1KOJ1oed2GjVFIz55EDrtzfkf0NztSdBGafXJf3TwESJWhOFks+/tAPjiRomiPSlY4J3DJLFWfrNAWJAnZqflRmtRdIOr/iDnw2s8ftj8fqu5sNQFcjKon2S1SDPNJbq/1eXozg2Z7ebUIV52/s2j5NAgHCrqjZ39CUu0kKsjVtEGO2Bh8BAHt6jEhTjvgKXf6x5KCVTmfIBLGU8= Content-Type: multipart/alternative; boundary="_000_SN4PR0701MB377691BE579AE6AF8D12A9F2AE4E0SN4PR0701MB3776_" MIME-Version: 1.0 X-OriginatorOrg: frostburg.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 82f0fa57-3f89-4101-cee3-08d6a4ceb59c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2019 20:35:03.5804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b8f95ed1-2a18-4246-8104-03a67478d3a3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0701MB3773 Archived-At: X-Mailman-Approved-At: Sun, 10 Mar 2019 08:22:42 -0700 Subject: [tcpm] RFC 6298 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 21:29:17 -0000 --_000_SN4PR0701MB377691BE579AE6AF8D12A9F2AE4E0SN4PR0701MB3776_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear IETF, I am studying computer science at Frostburg State University and doing a mi= ni research project on calculating RTO timer. I am interested in background discussions around changes that were made whe= n the latest RFC was revised in 2011, especially around how the 1 second mi= nimum was determined and why it was reduced to that from 3 seconds. Please= could you let me know if there is a public discussion board that would hav= e background discussions posted I could read to gets some background histor= y? Thank you. Sincerely, Jon Walter --_000_SN4PR0701MB377691BE579AE6AF8D12A9F2AE4E0SN4PR0701MB3776_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear IETF,

I am studying computer science at Frostburg State University and doing a mi= ni research project on calculating RTO timer.
I am interested in background discussions around changes that were made whe= n the latest RFC was revised in 2011, especially around how the 1 second mi= nimum was determined and why it was reduced to that from 3 seconds.  P= lease could you let me know if there is a public discussion board that would have background discussions posted= I could read to gets some background history?

Thank you.

Sincerely,

Jon Walter
--_000_SN4PR0701MB377691BE579AE6AF8D12A9F2AE4E0SN4PR0701MB3776_-- From nobody Sun Mar 10 08:32:01 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889F11278CF for ; Sun, 10 Mar 2019 08:31:59 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtyhbyDBc1yV for ; Sun, 10 Mar 2019 08:31:56 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1ED127817 for ; Sun, 10 Mar 2019 08:31:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8D63725A17; Sun, 10 Mar 2019 16:31:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1552231914; bh=9IwHY9VsZuEDjHecbfAyOaeT4b/QoDnmKPOrj7AHKoY=; h=From:To:Subject:Date:References:In-Reply-To:From; b=sI76IBj05z4W7ujfVcqvBfN02UIhi1zgryPihYNznZbjUFqrdAMaItwwM/kS0CxPP 1EIrNVRmRt4ApLGEKNkkAis5zmrOlzqV+XOJmQ0Ki1dTySVqthmXOb211VEWx7+pnn yu/uWoMTSOrXsmZTFOPJ5ZEI9wlmqYo2JmcKZN4Q= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILd9Klz_M8ni; Sun, 10 Mar 2019 16:31:53 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 10 Mar 2019 16:31:53 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Sun, 10 Mar 2019 16:31:53 +0100 From: "Scharf, Michael" To: Jonathan Walter , "tcpm@ietf.org" Thread-Topic: RFC 6298 Thread-Index: AQHU1rcC7jsh4P0lCEiAdwabPwjz5qYE/tJQ Date: Sun, 10 Mar 2019 15:31:53 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D2534BF@rznt8114.rznt.rzdir.fht-esslingen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D2534BFrznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] RFC 6298 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 15:32:00 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D2534BFrznt8114rzntrzd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, You can parse the list archive of the TCPM working group, most notably for = the term "rfc2988bis": https://mailarchive.ietf.org/arch/browse/tcpm/?q=3Drfc2988bis That, as well as the appendix of RFC 6298, is probably a good starting poin= t. Best regards Michael From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Jonathan Walter Sent: Saturday, March 9, 2019 9:35 PM To: tcpm@ietf.org Subject: [tcpm] RFC 6298 Dear IETF, I am studying computer science at Frostburg State University and doing a mi= ni research project on calculating RTO timer. I am interested in background discussions around changes that were made whe= n the latest RFC was revised in 2011, especially around how the 1 second mi= nimum was determined and why it was reduced to that from 3 seconds. Please= could you let me know if there is a public discussion board that would hav= e background discussions posted I could read to gets some background histor= y? Thank you. Sincerely, Jon Walter --_000_6EC6417807D9754DA64F3087E2E2E03E2D2534BFrznt8114rzntrzd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,=

 <= /p>

You can pa= rse the list archive of the TCPM working group, most notably for the term &= #8220;rfc2988bis”:

 = ;

https://mai= larchive.ietf.org/arch/browse/tcpm/?q=3Drfc2988bis

 = ;

That, as w= ell as the appendix of RFC 6298, is probably a good starting point.

 = ;

Best regar= ds

 = ;

Michael

 = ;

 = ;

From: tcpm [ma= ilto:tcpm-bounces@ietf.org] On Behalf Of Jonathan Walter
Sent: Saturday, March 9, 2019 9:35 PM
To: tcpm@ietf.org
Subject: [tcpm] RFC 6298

 

Dear IETF,

 

I am studying computer science at Frostburg = State University and doing a mini research project on calculating RTO timer= .

I am interested in background discussions ar= ound changes that were made when the latest RFC was revised in 2011, especi= ally around how the 1 second minimum was determined and why it was reduced to that from 3 seconds.  Please could you let me k= now if there is a public discussion board that would have background discus= sions posted I could read to gets some background history?

 

Thank you.

 

Sincerely,

 

Jon Walter

--_000_6EC6417807D9754DA64F3087E2E2E03E2D2534BFrznt8114rzntrzd_-- From nobody Sun Mar 10 08:36:56 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65F12796C for ; Sun, 10 Mar 2019 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIkeU9P_smsO for ; Sun, 10 Mar 2019 08:36:52 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 95C85127817 for ; Sun, 10 Mar 2019 08:36:52 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id n71so1846916ota.10 for ; Sun, 10 Mar 2019 08:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VjQdLvF/cI1DfMram80YNZGqFV+sw1hPhqIcpgIE1gU=; b=kV6egm2dA4pKc8jYGAZcLpCKStHJQpeNgrC7FGcxYxGzMKExjJwKAEBH0JNLP6ACGC Y7/bJh3jVb61/1wMB3HP9wOKeq4X1PDNfQgAvVXPgaxMo8ubHXy0msU1wkDQyuX2C1BW dmVIyOKsdDqHBLD/6rDsvEcjKSqCOlMawMnLGP8kDSFg8niDASehvX0HWYMZg+/v5AsJ zwcTZ/fgCMblq7HyCSBOrvTHrmFe7ZCfv9PbnAz+fXYUfoadd19IpelTr6FgUSPHmAPI f5y8e6Mx1gVmSvOroxNZEpONVmvmLs6o26MSy7MJDHAFBLaEc8Mhw06LZ3SScjR+TRCT UyGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VjQdLvF/cI1DfMram80YNZGqFV+sw1hPhqIcpgIE1gU=; b=JGpVr2+M6WYzbDIF5qUIMdPb/Fkjq2UOZ/C2D0qRRT2aC6Sb6sNm0HFSkNTfT9Fn5e vpOkKb/BOBuwYZQpeQr3gDB7VQ1+MEfQJ0Lol71oSe12jv2zT3KFXNg+KDlmJVP+CD5h EmzJ1OhtbYmcmfm80GnsSSEtaCqqoOltJDj/xPPmJhpPfqqgCSJxkLvf0aVmLbdijBcy rB72KJaMQqgctlj9qg8Iwgd2tkqfp3pdIk+TulRoBvrx5Kb4BIEA2Dd007GmQ26xKmVX 0i2eWtCWJoczLikcLtX1JEXxZ5/FYppTAyWsWzx2bZ0L0PXrzsfvEoR47q8EC+z+lRsE WTMQ== X-Gm-Message-State: APjAAAWBWwIUVZi83ZMQyo4Dg7iodNxhTp5A5M4Om0Sr7ChAQUx88aWk y8YgbBzWa+YK0iV5GTV2kVgSj5tiQ06F4qA/YylPUQ== X-Google-Smtp-Source: APXvYqxmHc1zSKJlLJrURFeAToXGx5PCQm6ywO/BLDKj+KTsuftDcCxga6qjxQR+lWDEtU0W1bBCmfUnATzYvuyvygY= X-Received: by 2002:a9d:5cc8:: with SMTP id r8mr17273386oti.104.1552232211427; Sun, 10 Mar 2019 08:36:51 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D2534BF@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D2534BF@rznt8114.rznt.rzdir.fht-esslingen.de> From: Neal Cardwell Date: Sun, 10 Mar 2019 11:36:35 -0400 Message-ID: To: "Scharf, Michael" Cc: Jonathan Walter , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000929ab50583bf3922" Archived-At: Subject: Re: [tcpm] RFC 6298 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 15:36:55 -0000 --000000000000929ab50583bf3922 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable These slide decks also have some motivating context for the 1 second value: https://www.ietf.org/proceedings/75/slides/tcpm-1.pdf (" ~2.5% connections with RTT > 1sec") https://www.ietf.org/proceedings/77/slides/iccrg-1.pdf ("~97.5% of connections have RTT < 1 second") neal On Sun, Mar 10, 2019 at 11:32 AM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > Hi Jon, > > > > You can parse the list archive of the TCPM working group, most notably fo= r > the term =E2=80=9Crfc2988bis=E2=80=9D: > > > > https://mailarchive.ietf.org/arch/browse/tcpm/?q=3Drfc2988bis > > > > That, as well as the appendix of RFC 6298, is probably a good starting > point. > > > > Best regards > > > > Michael > > > > > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Jonathan Walte= r > *Sent:* Saturday, March 9, 2019 9:35 PM > *To:* tcpm@ietf.org > *Subject:* [tcpm] RFC 6298 > > > > Dear IETF, > > > > I am studying computer science at Frostburg State University and doing a > mini research project on calculating RTO timer.. > > I am interested in background discussions around changes that were made > when the latest RFC was revised in 2011, especially around how the 1 seco= nd > minimum was determined and why it was reduced to that from 3 seconds. > Please could you let me know if there is a public discussion board that > would have background discussions posted I could read to gets some > background history? > > > > Thank you. > > > > Sincerely, > > > > Jon Walter > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000929ab50583bf3922 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These slide decks also have some mot= ivating context for the 1 second value:

=C2=A0 (" ~2.5% connections with RTT > 1sec")

=C2=A0 ("~97.5% of connections h= ave RTT < 1 second")

neal


On Sun, Mar 10, 2019 at 11:32 AM Scharf, Michael <= Michael.Scharf@hs-essling= en.de> wrote:

Hi Jon,

=C2=A0

You can parse the list archiv= e of the TCPM working group, most notably for the term =E2=80=9Crfc2988bis= =E2=80=9D:

=C2=A0

https://mail= archive.ietf.org/arch/browse/tcpm/?q=3Drfc2988bis<= /p>

=C2=A0

That, as well as the appendix= of RFC 6298, is probably a good starting point.

=C2=A0

Best regards

=C2=A0

Michael<= /p>

=C2=A0

=C2=A0

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Jonathan Walter
Sent: Saturday, March 9, 2019 9:35 PM
To: tcpm@ietf.org=
Subject: [tcpm] RFC 6298

=C2=A0

Dear IETF,

=C2=A0

I am studying computer science at Frostburg State University and doi= ng a mini research project on calculating RTO timer..<= /p>

I am interested in background discussions around changes that were m= ade when the latest RFC was revised in 2011, especially around how the 1 se= cond minimum was determined and why it was reduced to that from 3 seconds.=C2=A0 Please could you let me k= now if there is a public discussion board that would have background discus= sions posted I could read to gets some background history?

=C2=A0

Thank you.

=C2=A0

Sincerely,

=C2=A0

Jon Walter

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000929ab50583bf3922-- From nobody Mon Mar 11 11:56:43 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 105F6131122; Mon, 11 Mar 2019 11:56:35 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <155233059497.23086.12359765295007089620@ietfa.amsl.com> Date: Mon, 11 Mar 2019 11:56:34 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 18:56:35 -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-08.txt Pages : 46 Date : 2019-03-11 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). Recent 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-08 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 Mar 11 14:56:37 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA821311E3; Mon, 11 Mar 2019 14:56:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar4zONpHJJMl; Mon, 11 Mar 2019 14:56:24 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8A2131249; Mon, 11 Mar 2019 14:56:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A59A225A14; Mon, 11 Mar 2019 22:56:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1552341382; bh=oPTLodDM5h5MptoE8iMz/eaxtBkiDJU1fHD4wMTzHF4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=q95obJz+7H9n85c2CkH599grQqkXqsBWn1U+rV42UachwKegRvbu4vyCPP1NMp8b5 QXPkdPWfYhOQBN0ZR1ur/y1HdzRkGpNojLoXmeS2W+KzLTnA5kMF1ceqfL8G8Anrf2 JAu0nZUc6mHNplpY/mz9sPd4Wzvr2kADCNDRoYD0= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfwjptPikBGi; Mon, 11 Mar 2019 22:56:21 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 11 Mar 2019 22:56:21 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Mon, 11 Mar 2019 22:56:21 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "draft-touch-tcpm-2140bis@ietf.org" Thread-Topic: Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status Thread-Index: AQHU1G616iHOJHkpoEO6XOB3g3fkFaYG8qpw Date: Mon, 11 Mar 2019 21:56:19 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D256A45@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D24EEA4@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D24EEA4@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:56:37 -0000 RGlzY2xhaW1lcjogQ2hhaXIgaGF0IG9mZg0KDQoNCkkgaGF2ZSByZWFkIGRyYWZ0LXRvdWNoLXRj cG0tMjE0MGJpcy0wNi4gSSBiZWxpZXZlIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhIGdvb2Qgc3Rh cnRpbmcgcG9pbnQgZm9yIGEgbmV3IFRDUE0gd29ya2luZyBncm91cCBpdGVtIHRhcmdldGluZyBh biBpbmZvcm1hdGlvbmFsIFJGQy4NCg0KDQpCZWxvdyBhcmUgc29tZSBpbml0aWFsIGNvbW1lbnRz IHRoYXQgYXJlIGhvcGVmdWxseSBub3QgZGlmZmljdWx0IHRvIHNvcnQgb3V0IGluIGEgZm9sbG93 LXVwIHZlcnNpb24uDQoNCkNvbW1lbnRzOg0KDQotIFRoZSBhYnN0cmFjdCBhbmQvb3IgdGhlIGlu dHJvZHVjdGlvbiBjb3VsZCBiZXR0ZXIgZXhwbGFpbiB0aGUgcHVycG9zZSBvZiB0aGUgZG9jdW1l bnQgYW5kIHdoeSBpdCBpcyBpbmZvcm1hdGlvbmFsLiBGb3IgaW5zdGFuY2UsIGEgc2VudGVuY2Ug c3VjaCBhcyAidGhpcyBkb2N1bWVudCBwcm92aWRlcyBpbmZvcm1hdGlvbmFsIGd1aWRhbmNlIHRv IFRDUCBpbXBsZW1lbnRlcnMuLi4iIG9yIHRoZSBsaWtlIGNvdWxkIGJlIHVzZWZ1bC4NCg0KLSBX aGlsZSB0aGlzIG1heSBiZSBzb21ld2hhdCBvYnZpb3VzIHRvIG1vc3Qgb2YgdXMsIHRoZSBkb2N1 bWVudCBjb3VsZCBhbHNvIG1lbnRpb24gbW9yZSBleHBsaWNpdGx5IHRoYXQgdGhlIGNvbnRlbnQg ZG9lcyBub3QgYWZmZWN0IFRDUCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQotIFNlY3Rpb24gMiBtYXkg bm90IGJlIHJlcXVpcmVkIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGRvZXMgbm90IHVzZSBSRkMg MjExOSBsYW5ndWFnZSwgZXhjZXB0IGluIGEgcXVvdGUgZnJvbSBSRkMgNzQxMyBhbmQgaW4gdGhl IGFwcGVuZGl4IHRoYXQgd2lsbCBiZSByZW1vdmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLiBJZiBz ZWN0aW9uIDIgc3RheXMgaW4gdGhlIGRvY3VtZW50LCBpdCBzaG91bGQgYmUgcmV3b3JkZWQgYWNj b3JkaW5nIHRvIFJGQyA4MTc0Lg0KDQotIEluIFNlY3Rpb24gNiwgSSBmaW5kIHRoZSBzZW50ZW5j ZSBhbmQgcmVmZXJlbmNlcyAiUlRUIHZhbHVlcyBhcmUgdXBkYXRlZCBieSBhIG1vcmUgY29tcGxp Y2F0ZWQgbWVjaGFuaXNtIFtSRkMxNjQ0XVtKYTg2XSIgc29tZXdoYXQgY29uZnVzaW5nLiBGaXJz dCwgSSBkb24ndCBrbm93IHdoYXQgW0phODZdIGFjdHVhbGx5IHJlZmVycyB0bzsgd2l0aG91dCBh IHB1YmxpYyBhcmNoaXZlIHN1Y2ggYSByZWZlcmVuY2UgaGFzIG9ubHkgdmVyeSBsaW1pdGVkIHZh bHVlIHRvICh5b3VuZ2VyKSByZWFkZXJzLiBUaGF0IGFsc28gYXBwbGllcyB0byBhIGxhdGVyIHVz ZSBvZiBbSmE4Nl0uIFNlY29uZCwgUkZDIDE2NDQgaXMgbm93IG9ic29sZXRlIGFuZCBJIHRoaW5r IFQvVENQIGJlbG9uZ3MgYmV0dGVyIGludG8gQXBwZW5kaXggQS4gSSB3b25kZXIgaWYgdGhpcyBz ZWN0aW9uIGNvdWxkIGJlIHJld29yZGVkIHdpdGggcmVmZXJlbmNlcyB0byBSRkMgNjI5OD8gVGhl IHNhbWUgY29tbWVudCBtYXkgYWxzbyBhcHBseSB0byBsYXRlciBkaXNjdXNzaW9ucyBvZiB0aGUg UlRULg0KDQoNCkVkaXRvcmlhbCBuaXRzOg0KDQotIFRoZSBhYnN0cmFjdCBtYXkgYmUgbW9yZSB1 c2VmdWwgb24gdGhlIGZpcnN0IHBhZ2UNCg0KLSBTZWN0aW9uIDg6ICJUQ1AgaXMgc29tZXRpbWVz IHVzZWQgaW4gc2l0dWF0aW9ucyB3aGVyZSBwYWNrZXRzIG9mIHRoZSBzYW1lIGhvc3QtcGFpciBh bHdheXMgdGFrZSB0aGUgc2FtZSBwYXRoLiIgVGhpcyBzZW50ZW5jZSBzZWVtcyBicm9rZW4sIG5v Pw0KDQotIFNlY3Rpb24gODogInNvbWUgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtzIChWUE5zKSBh cmUga25vd24gdG8gdXNlIHByb3ByaWV0YXJ5IFVEUCBlbmNhcHN1bGF0aW9uIG1ldGhvZHMiLiBJ IGRvbid0IHVuZGVyc3RhbmQgd2h5ICJwcm9wcmlldGFyeSIgaXMgdXNlZCBpbiB0aGlzIGNvbnRl eHQ7IGFjdHVhbGx5IEkgZXZlbiBkb24ndCBldmVuIHVuZGVyc3RhbmQgd2h5ICJVRFAgZW5jYXBz dWxhdGlvbiIgbWF0dGVycy4gRG9lc24ndCB0aGlzIHBhcmFncmFwaCBhcHBseSB0byBhbGwgdHVu bmVsIGVuY2Fwcz8NCg0KLSBTZWN0aW9uIDk6ICJPbmUgc3VjaCBwcm9ibGVtIGlzIGRldGVybWlu aW5nIHRoZSBhc3NvY2lhdGVkIHByaW9yIG91dGdvaW5nIHBhY2tldCBmb3IgYW4gaW5jb21pbmcg cGFja2V0LCB0byBpbmZlciBSVFQgZnJvbSB0aGUgZXhjaGFuZ2UuIiBXZWxsLCBhcyBhIG5vbi1u YXRpdmUgc3BlYWtlciwgSSBoYWQgdG8gcmVhZCB0aGlzIHNlbnRlbmNlIGF0IGxlYXN0IHRocmVl IHRpbWVzIHRvIHVuZGVyc3RhbmQgd2hhdCBpcyBwcm9iYWJseSBtZWFudCBieSB0aGF0Lg0KDQoN ClRoYW5rcw0KDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2No YXJmLCBNaWNoYWVsDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggNiwgMjAxOSAxMTo0OCBQTQ0K PiBUbzogdGNwbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdGNwbV0gV29ya2luZyBncm91cCBhY2Nl cHRhbmNlIG9mIGRyYWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0wNg0KPiB0YXJnZXRpbmcgaW5mb3Jt YXRpb25hbCBzdGF0dXMNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IFRoZSBkb2N1bWVudCBkcmFmdC10 b3VjaC10Y3BtLTIxNDBiaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIHF1aXRlIGEgYml0IGluDQo+IFRD UE0uIE9uZSBxdWVzdGlvbiBoYXMgYmVlbiB0aGUgc3RhdHVzIChCQ1Agb3IgSU5GTykuIFRoZSB2 ZXJzaW9uDQo+IGRyYWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0wNiBleHBsaWNpdGx5IHRhcmdldHMg aW5mb3JtYXRpb25hbCBzdGF0dXMgYW5kDQo+IHBsYW5zIHRvIG9ic29sZXRlIFJGQyAyMTQwICh3 aGljaCBpcyBpbmZvcm1hdGlvbmFsLCB0b28pLg0KPiANCj4gVGhlIGludGVudGlvbiBvZiB0aGlz IGUtbWFpbCBpcyB0byBjb25maXJtIHRoYXQgZHJhZnQtdG91Y2gtdGNwbS0NCj4gMjE0MGJpcy0w NiBzaG91bGQgYmUgYWRvcHRlZCBhcyBpbmZvcm1hdGlvbmFsIFRDUE0gd29ya2luZyBncm91cCBp dGVtLA0KPiBpLmUuLCB0aGF0IGEgbmV3IGl0ZW0gc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBUQ1BN IGNoYXJ0ZXI6DQo+IA0KPiAgIE5vdi4gMjAxOSAgU3VibWl0IGRvY3VtZW50IG9uIFRDUCBDb250 cm9sIEJsb2NrIEludGVyZGVwZW5kZW5jZSB0bw0KPiB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24g YXMgSW5mb3JtYXRpb25hbCBSRkMNCj4gDQo+IFRoZSBhZG9wdGlvbiBjYWxsIHJ1bnMgb24gdGhl IFRDUE0gbWFpbGluZyBsaXN0IHVudGlsIE1hcmNoIDIyLiBQbGVhc2UNCj4gbGV0IHVzIGtub3cg aWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50LCBvciBpZiB0aGVyZSBhcmUN Cj4gYW55IGNvbmNlcm5zLg0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBNaWNoYWVsDQo+IChU Q1BNIGNvLWNoYWlyKQ0KPiANCj4gDQo+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0t LS0tDQo+IEZyb206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKb2UgVG91Y2gNCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDQsIDIwMTkgNTo1MiBQTQ0K PiBUbzogdGNwbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdGNwbV0gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXRvdWNoLXRjcG0tDQo+IDIxNDBiaXMtMDYudHh0DQo+IA0K PiBGWUkgLQ0KPiBUaGlzIHZlcnNpb246DQo+IMKgwqDCoCAtIG9ic29sZXRlcyAyMTQwDQo+IMKg wqDCoCAtIHNheXMgc28gaW4gdGhlIGFic3RyYWN0IGFuZCBpbnRybw0KPiDCoMKgwqAgLSBpbmNs dWRlcyBhICJjaGFuZ2VzIGZyb20gMjE0MCIgc2VjdGlvbiBzdW1tYXJpemluZyB0aGUNCj4gZGlm ZmVyZW5jZXMNCj4gTm90ZSB0aGF0IHRoZSBlYXJsaWVyIHZlcnNpb25zIGRpZCBjaXRlIDIxNDAs IGJ1dCBkaWQgbm90IGFzIGRpcmVjdGx5DQo+IGluZGljYXRlIHRoYXQgdGhpcyBpcyBpbnRlbmRl ZCBhcyBpdHMgcmVwbGFjZW1lbnQuDQo+IEpvZQ0KPiANCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1l c3NhZ2UgLS0tLS0tLS0NCj4gU3ViamVjdDoNCj4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC10b3VjaC10Y3BtLTIxNDBiaXMtMDYudHh0DQo+IERhdGU6DQo+IEZyaSwgMDQgSmFu IDIwMTkgMDg6NDk6MjUgLTA4MDANCj4gRnJvbToNCj4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn DQo+IFRvOg0KPiBTYWZpcXVsIElzbGFtIDxzYWZpcXVsaUBpZmkudWlvLm5vPiwgTWljaGFlbCBX ZWx6bA0KPiA8bWljaGF3ZUBpZmkudWlvLm5vPiwgSm9zZXBoIFRvdWNoIDx0b3VjaEBzdHJheWFs cGhhLmNvbT4sIEpvZSBUb3VjaA0KPiA8dG91Y2hAc3RyYXlhbHBoYS5jb20+DQo+IA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10b3VjaC10Y3BtLTIxNDBiaXMtMDYudHh0 DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9lIFRvdWNoIGFuZCBwb3N0 ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6IGRyYWZ0LXRvdWNoLXRj cG0tMjE0MGJpcw0KPiBSZXZpc2lvbjogMDYNCj4gVGl0bGU6IFRDUCBDb250cm9sIEJsb2NrIElu dGVyZGVwZW5kZW5jZQ0KPiBEb2N1bWVudCBkYXRlOiAyMDE5LTAxLTA0DQo+IEdyb3VwOiBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6IDIyDQo+IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0NCj4gMDYudHh0DQo+ IFN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdG91Y2gtdGNw bS0yMTQwYmlzLw0KPiBIdG1saXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRvdWNoLXRjcG0tMjE0MGJpcy0wNg0KPiBIdG1saXplZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC10b3VjaC10Y3BtLQ0KPiAyMTQwYmlzDQo+IERpZmY6IGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10b3VjaC10Y3BtLTIxNDBiaXMt MDYNCj4gDQo+IEFic3RyYWN0Og0KPiBUaGlzIG1lbW8gdXBkYXRlcyBhbmQgcmVwbGFjZXMgUkZD IDIxNDAncyBkZXNjcmlwdGlvbiBvZg0KPiBpbnRlcmRlcGVuZGVudCBUQ1AgY29udHJvbCBibG9j a3MsIGluIHdoaWNoIHBhcnQgb2YgdGhlIFRDUCBzdGF0ZSBpcw0KPiBzaGFyZWQgYW1vbmcgc2lt aWxhciBjb25jdXJyZW50IG9yIGNvbnNlY3V0aXZlIGNvbm5lY3Rpb25zLiBUQ1ANCj4gc3RhdGUg aW5jbHVkZXMgYSBjb21iaW5hdGlvbiBvZiBwYXJhbWV0ZXJzLCBzdWNoIGFzIGNvbm5lY3Rpb24N Cj4gc3RhdGUsIGN1cnJlbnQgcm91bmQtdHJpcCB0aW1lIGVzdGltYXRlcywgY29uZ2VzdGlvbiBj b250cm9sDQo+IGluZm9ybWF0aW9uLCBhbmQgcHJvY2VzcyBpbmZvcm1hdGlvbi4gTW9zdCBvZiB0 aGlzIHN0YXRlIGlzDQo+IG1haW50YWluZWQgb24gYSBwZXItY29ubmVjdGlvbiBiYXNpcyBpbiB0 aGUgVENQIENvbnRyb2wgQmxvY2sgKFRDQiksDQo+IGJ1dCBpbXBsZW1lbnRhdGlvbnMgY2FuIChh bmQgZG8pIHNoYXJlIGNlcnRhaW4gVENCIGluZm9ybWF0aW9uDQo+IGFjcm9zcyBjb25uZWN0aW9u cyB0byB0aGUgc2FtZSBob3N0LiBTdWNoIHNoYXJpbmcgaXMgaW50ZW5kZWQgdG8NCj4gaW1wcm92 ZSBvdmVyYWxsIHRyYW5zaWVudCB0cmFuc3BvcnQgcGVyZm9ybWFuY2UsIHdoaWxlIG1haW50YWlu aW5nDQo+IGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlv bnMuIFRoZSBzaGFyaW5nDQo+IGRlc2NyaWJlZCBoZXJlaW4gaXMgbGltaXRlZCB0byBvbmx5IHRo ZSBUQ0IgaW5pdGlhbGl6YXRpb24gYW5kIHNvDQo+IGhhcyBubyBlZmZlY3Qgb24gdGhlIGxvbmct dGVybSBiZWhhdmlvciBvZiBUQ1AgYWZ0ZXIgYSBjb25uZWN0aW9uDQo+IGhhcyBiZWVuIGVzdGFi bGlzaGVkLg0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K From nobody Wed Mar 13 02:02:20 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A93130ECF; Wed, 13 Mar 2019 02:02:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmew-e6qucAj; Wed, 13 Mar 2019 02:02:16 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0C8130EC6; Wed, 13 Mar 2019 02:02:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id DF62725A19; Wed, 13 Mar 2019 10:02:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1552467733; bh=w7XTbUdrlplyGh8oZ8vCyiull41FGyNow15Rwmp1riA=; h=From:To:CC:Subject:Date:From; b=qtDu4wJQOrmnxuoFgfkVIBvrB6v9pCqA6vsbRfDBQGoIjKUqTiA2NUQCk73FZrJjp ejF58aXZsahgdBL4NX5e3VYhcmglccHzp1Kq4lBXKAnZo9gbBkFFjuBKuHXKGMSpwC FFp/zUK0LrauNWul99LL/GSi/CmDf6T5BDrMhkV0= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEYgdO9urdQX; Wed, 13 Mar 2019 10:02:08 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 13 Mar 2019 10:02:08 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 10:02:08 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: DRAFT agenda for Prague Thread-Index: AdTZe3ChDi51rHh7T5ipgKPX1HaYXg== Date: Wed, 13 Mar 2019 09:02:08 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D259B52@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] DRAFT agenda for Prague X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 09:02:19 -0000 Hi all, A first draft of the TCPM agenda for IETF 104 has been posted on https://da= tatracker.ietf.org/meeting/104/materials/ and is also copied below. Please let the chairs know if I missed something, or if there are late slot= requests. Happy agenda bashing! Michael ************************************************* TCPM meeting, IETF 104, Prague Monday, March 25, 2019, 13:50-15:50 (Afternoon session I) =20 WG Status updates ------------------------------------------------- Time: 15 min Working Group Items ------------------------------------------------- * 0-RTT TCP Convert Protocol draft-ietf-tcpm-converters Speaker: Olivier Bonaventure Time: 15 min Other Items ------------------------------------------------- * Transmission Control Protocol (TCP) YANG Model draft-scharf-tcpm-yang-tcp Speaker: Michael Scharf Time: 15 min * DNS Transport over TCP - Operational Requirements draft-ietf-dnsop-dns-tcp-requirements Speaker: Duane Wessels Time: 10 min * TCP advancements in Windows Speaker: Praveen Balasubramanian (on-site or remote) Time: 15 min * QUIC Loss Detection and Congestion Control=20 draft-ietf-quic-recovery Speaker: Jana Iyengar Time: 30 min From nobody Wed Mar 13 02:44:31 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0F130EC6 for ; Wed, 13 Mar 2019 02:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8_gvfPx2bbL for ; Wed, 13 Mar 2019 02:44:28 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76FE130EBF for ; Wed, 13 Mar 2019 02:44:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 02B3825A19; Wed, 13 Mar 2019 10:44:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1552470266; bh=bBuzXQ531SWE5YdhdTVS9wmSQHPpiiBd5epvd1L+utw=; h=From:To:CC:Subject:Date:From; b=BFUizd40l3ffqISn1jn3qI5vwp53lIBSY5SY1SJLnNSjWPioFgBh3DFR/JzJoevdL G7Zo+sP1fVxdqvOnRP5GQd7z9TmJ87NlNyL68iDxvMoKQc6IMP1ZEjQtaWUM1Ps6hi 6llcdmdJbRcSPfJrmxkz/Q7lr3Ou30N0xQBTzuAg= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eEg_4dkqo-b; Wed, 13 Mar 2019 10:44:25 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 13 Mar 2019 10:44:25 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.183]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 10:44:24 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "cheshire@apple.com" , Carles Gomez , Jon Crowcroft , "Ted Lemon" , Vividh Siddha , Vincent Lubet , Christoph Paasch Thread-Topic: Draft-ietf-lwig-tcp-constrained-node-networks-04 Thread-Index: AQHU2TX1/fKUvmMCbU+1+9M5UQ7ZpaYJT4Lw Date: Wed, 13 Mar 2019 09:44:24 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D259C73@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tcpm] FW: Draft-ietf-lwig-tcp-constrained-node-networks-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 09:44:30 -0000 Rm9yd2FyZGVkIHRvIHRoZSBUQ1BNIGxpc3QgKHdpdGggU3R1YXJ0J3MgcGVybWlzc2lvbikNCg0K VGhhbmtzIQ0KDQpNaWNoYWVsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGNoZXNoaXJlQGFwcGxlLmNvbSBbbWFpbHRvOmNoZXNoaXJlQGFwcGxlLmNvbV0gDQpTZW50OiBX ZWRuZXNkYXksIE1hcmNoIDEzLCAyMDE5IDE6NDUgQU0NClRvOiBDYXJsZXMgR29tZXo7IEpvbiBD cm93Y3JvZnQ7IFNjaGFyZiwgTWljaGFlbA0KQ2M6IFRlZCBMZW1vbjsgVml2aWRoIFNpZGRoYTsg VmluY2VudCBMdWJldDsgQ2hyaXN0b3BoIFBhYXNjaA0KU3ViamVjdDogRHJhZnQtaWV0Zi1sd2ln LXRjcC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTA0DQoNCkRlYXIgYXV0aG9ycywNCg0KSSBy ZWFkIHlvdXIgZG9jdW1lbnQgZHJhZnQtaWV0Zi1sd2lnLXRjcC1jb25zdHJhaW5lZC1ub2RlLW5l dHdvcmtzLTA0IGxhc3Qgd2Vla2VuZC4NCg0KVGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMuIEl0 IGlzIGFuIGV4Y2VsbGVudCByZXNvdXJjZS4gSSBhbSBjb25zdGFudGx5IGJhdHRsaW5nIGluIHRo ZSBaaWdiZWUgYW5kIFRocmVhZCBjb21tdW5pdGllcyBhYm91dCB3aHkgZm9yIG1hbnkgam9icyBU Q1AgaXMgdGhlIHJpZ2h0IHByb3RvY29sLCBhbmQgd2UgaGF2ZSBiZWVuIHB1c2hpbmcgaGFyZCBm b3IgbW9yZSBUaHJlYWQgZGV2aWNlIHZlbmRvcnMgdG8gbWFrZSBUQ1AgYXZhaWxhYmxlIGluIHRo ZWlyIFNES3MuIEhhdmluZyB0aGlzIGRvY3VtZW50IHRvIHJlY29tbWVuZCB0byBwZW9wbGUgaXMg ZXh0cmVtZWx5IGhlbHBmdWwuDQoNClNvbWUgZmVlZGJhY2s6DQoNCiAgIEEgVENQIGltcGxlbWVu dGF0aW9uIG5lZWRzIHRvIHN1cHBvcnQgb3B0aW9ucyAwLCAxIGFuZCAyIFtSRkMwNzkzXS4NCg0K U2luY2UgeW91ciBwcmltYXJ5IGF1ZGllbmNlIGlzIHBlb3BsZSB1bmluZm9ybWVkIGFib3V0IFRD UCwgaXQgd291bGQgYmUgZ29vZCB0byBleHBsYWluIHdoYXQgdGhpcyBtZWFucywgaW5zdGVhZCBv ZiBtYWtpbmcgdGhlbSBodW50IGluIGFuIGFuY2llbnQgZG9jdW1lbnQuDQoNClBlcmhhcHMgc2F5 OiDigJxBIFRDUCBpbXBsZW1lbnRhdGlvbiBuZWVkcyB0byBzdXBwb3J0LCBhdCBhIG1pbmltdW0s IFRDUCBvcHRpb25zIDIsIDEgYW5kIDAuIFRoZXNlIGFyZSwgcmVzcGVjdGl2ZWx5LCB0aGUgTWF4 aW11bSBTZWdtZW50IFNpemUgKE1TUykgb3B0aW9uLCB0aGUgTm8tT3BlcmF0aW9uIG9wdGlvbiwg YW5kIHRoZSBFbmQgT2YgT3B0aW9uIExpc3QgbWFya2VyIFtSRkMwNzkzXS4gTm9uZSBvZiB0aGVz ZSBhcmUgYSBzdWJzdGFudGlhbCBidXJkZW4gdG8gc3VwcG9ydC4gQSBUQ1AgaW1wbGVtZW50YXRp b24gaXMgcGVybWl0dGVkIHRvIHNpbGVudGx5IGlnbm9yZSBhbGwgb3RoZXIgVENQIG9wdGlvbnMu 4oCdDQoNCiAgIEFuIElQdjYgZGF0YWdyYW0gc2l6ZSBleGNlZWRpbmcgMTI4MCBieXRlcyBjYW4g YmUgYXZvaWRlZCBieSBzZXR0aW5nDQogICB0aGUgVENQIE1TUyBub3QgbGFyZ2VyIHRoYW4gMTIy MCBieXRlcy4gIChOb3RlOiBJUCB2ZXJzaW9uIDYgaXMgYXNzdW1lZC4pDQoNClRoaXMgYWR2aWNl IGFzc3VtZXMgdGhlIHJlbW90ZSBwZWVyIHNlbmRzIG5vIFRDUCBvcHRpb25zLiBQZXJoYXBzIHNh eTog4oCcVGhpcyBhc3N1bWVzIHRoYXQgdGhlIHJlbW90ZSBzZW5kZXIgd2lsbCB1c2Ugbm8gVENQ IG9wdGlvbnMsIGFzaWRlIGZyb20gcG9zc2libHkgdGhlIE1TUyBvcHRpb24sIHdoaWNoIGlzIG9u bHkgdXNlZCBpbiB0aGUgaW5pdGlhbCBUQ1AgU1lOIHBhY2tldC7igJ0NCg0KTm90ZSB0aGF0IHNv bWUgcGxhdGZvcm1zIHdpbGwgdW5jb25kaXRpb25hbGx5IGluY2x1ZGUgVENQIHRpbWVzdGFtcHMs IHdoaWNoIGFkZCAxMiBieXRlcyB0byB0aGUgVENQIGhlYWRlci4gTWF5YmUgdG8gYWNjb21tb2Rh dGUgdGhpcywgdGhlIGNvbnN0cmFpbmVkIGRldmljZSBzaG91bGQgYWR2ZXJ0aXNlIGFuIE1TUyBv ZiAxMjAwIGJ5dGVzLCB0byBsZWF2ZSAyMCBieXRlcyBmb3IgYW55ICh1bnJlcXVlc3RlZCkgVENQ IG9wdGlvbnM/DQoNCiAgIElmIGluIHN1Y2ggY29uZGl0aW9ucyB0aGUgcGVlcg0KICAgZGV2aWNl IGlzIGFkbWluaXN0ZXJlZCBieSB0aGUgc2FtZSBlbnRpdHkgbWFuYWdpbmcgdGhlIGNvbnN0cmFp bmVkDQogICBkZXZpY2UsIGl0IGlzIHJlY29tbWVuZGVkIHRvIGRpc2FibGUgZGVsYXllZCBBQ0tz IGF0IHRoZSBwZWVyIHNpZGUuDQoNCkkgZGlzYWdyZWUgdGhhdCBpdCBpcyBnb29kIGFkdmljZSB0 byByZWNvbW1lbmQgZGlzYWJsaW5nIGRlbGF5ZWQgQUNLcywgZXNwZWNpYWxseSBvbiBhbiBhbHJl YWR5LWNvbnN0cmFpbmVkIG5ldHdvcmssIHdoZXJlIHdhc3RlZnVsIHRyYWZmaWMgbWFrZXMgYSBi YWQgc2l0dWF0aW9uIHdvcnNlLg0KDQpBdHRhY2hlZCBiZWxvdyBpcyBzb21lIHRleHQgSSB3cm90 ZSBmb3IgZHJhZnQtaWV0Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbCAoRE5TIFN0YXRlZnVsIE9wZXJh dGlvbnMpIG9uIHRoZSBzdWJqZWN0IG9mIGRlbGF5ZWQgQUNLcy4NCg0KVGhlIOKAnHNwbGl0IGhh Y2vigJ0gaXMgYWxzbyBiYWQgYmVjYXVzZSBpdCBzZW5kcyB0d28gcGFja2V0cyBpbnN0ZWFkIG9m IG9uZTsgbW9yZSB3YXN0ZWZ1bCB0cmFmZmljIHRoYXQgbWFrZXMgYSBiYWQgc2l0dWF0aW9uIHdv cnNlLg0KDQpQZXJoYXBzIHdlIG5lZWQgdG8gZGVmaW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dz IGEgc3RhY2sgd2l0aCBhIHNpbmdsZS1NU1MgdHJhbnNtaXQgYnVmZmVyIHRvIGF2b2lkIHRoZSBk ZWxheWVkIEFDSyBwZW5hbHR5PyBQZXJoYXBzIGEgbmV3IFRDUCDigJxhY2sgbm93IHBsZWFzZeKA nSBvcHRpb24/IFBlcmhhcHMgc29tZSBvdGhlciBjcmVhdGl2ZSBjcmFmdGluZyBvZiB0aGUgcGFj a2V0IChpbWFnaW5hdGl2ZSB1c2Ugb2YgU0FDSywgRFNBQ0ssIGludmFsaWQgQUNLIG51bWJlciwg ZXRjLikgdGhhdCB3aWxsIGNhdXNlIHRoZSByZW1vdGUgcGVlciB0byBieXBhc3MgaXRzIHVzdWFs IGRlbGF5ZWQgQUNLIHRpbWVyPw0KDQpNeSBjb2xsZWFndWUgQ2hyaXN0b3BoIFBhYXNjaCBzdWdn ZXN0ZWQgb25lIGlkZWEgZm9yIGhvdyB0byBkbyB0aGlzOiBpZiBhIHNlZ21lbnQgaXMgc2VudCBt YXJrZWQgRUNULCBhbmQgc3Vic2VxdWVudCBzZWdtZW50cyBhcmUgc2VudCAqbm90KiBtYXJrZWQg RUNULCB0aGVuIExpbnV4IHdpbGwgQUNLIHRob3NlIG5vbi1FQ1Qgc2VnbWVudHMgaW1tZWRpYXRl bHkgYmVjYXVzZSBMaW51eCBhc3N1bWVzIHRoZXkgbXVzdCBiZSByZXRyYW5zbWlzc2lvbnMuIFRo aXMsIG9yIHNvbWV0aGluZyBsaWtlIGl0LCBjb3VsZCBiZSBhIGdvb2QgaGFjayBmb3Igc2luZ2xl LU1TUyBjb25zdHJhaW5lZCBzZW5kZXJzLg0KDQpTdHVhcnQgQ2hlc2hpcmUNCg0KLS0NCg0KRnJv bSBkcmFmdC1pZXRmLWRuc29wLXNlc3Npb24tc2lnbmFsIChETlMgU3RhdGVmdWwgT3BlcmF0aW9u cyk6DQoNCjkuNS4gIFRDUCBEZWxheWVkIEFja25vd2xlZGdlbWVudCBDb25zaWRlcmF0aW9ucw0K DQogICBNb3N0IG1vZGVybiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIFRyYW5zbWlzc2lvbiBDb250 cm9sIFByb3RvY29sDQogICAoVENQKSBpbmNsdWRlIGEgZmVhdHVyZSBjYWxsZWQgIkRlbGF5ZWQg QWNrbm93bGVkZ2VtZW50IiBbUkZDMTEyMl0uDQoNCiAgIFdpdGhvdXQgdGhpcyBmZWF0dXJlLCBU Q1AgY2FuIGJlIHZlcnkgd2FzdGVmdWwgb24gdGhlIG5ldHdvcmsuICBGb3INCiAgIGlsbHVzdHJh dGlvbiwgY29uc2lkZXIgYSBzaW1wbGUgZXhhbXBsZSBsaWtlIHJlbW90ZSBsb2dpbiB1c2luZyBh DQogICB2ZXJ5IHNpbXBsZSBUQ1AgaW1wbGVtZW50YXRpb24gdGhhdCBsYWNrcyBkZWxheWVkIGFj a3MuICBXaGVuIHRoZQ0KICAgdXNlciB0eXBlcyBhIGtleXN0cm9rZSwgYSBkYXRhIHBhY2tldCBp cyBzZW50LiAgV2hlbiB0aGUgZGF0YSBwYWNrZXQNCiAgIGFycml2ZXMgYXQgdGhlIHNlcnZlciwg dGhlIHNpbXBsZSBUQ1AgaW1wbGVtZW50YXRpb24gc2VuZHMgYW4NCiAgIGltbWVkaWF0ZSBhY2tu b3dsZWRnZW1lbnQuICBNZXJlIG1pbGxpc2Vjb25kcyBsYXRlciwgdGhlIHNlcnZlcg0KICAgcHJv Y2VzcyByZWFkcyB0aGUgb25lIGJ5dGUgb2Yga2V5c3Ryb2tlIGRhdGEsIGFuZCBjb25zZXF1ZW50 bHkgdGhlDQogICBzaW1wbGUgVENQIGltcGxlbWVudGF0aW9uIHNlbmRzIGFuIGltbWVkaWF0ZSB3 aW5kb3cgdXBkYXRlLiAgTWVyZQ0KICAgbWlsbGlzZWNvbmRzIGxhdGVyLCB0aGUgc2VydmVyIHBy b2Nlc3MgZ2VuZXJhdGVzIHRoZSBjaGFyYWN0ZXIgZWNobw0KICAgYW5kIHNlbmRzIHRoaXMgZGF0 YSBiYWNrIGluIHJlcGx5LiAgVGhlIHNpbXBsZSBUQ1AgaW1wbGVtZW50YXRpb24NCiAgIHRoZW4g c2VuZHMgdGhpcyBkYXRhIHBhY2tldCBpbW1lZGlhdGVseSB0b28uICBJbiB0aGlzIGNhc2UsIHRo aXMNCiAgIHNpbXBsZSBUQ1AgaW1wbGVtZW50YXRpb24gc2VuZHMgYSBidXJzdCBvZiB0aHJlZSBw YWNrZXRzIGFsbW9zdA0KICAgaW5zdGFudGFuZW91c2x5IChhY2ssIHdpbmRvdyB1cGRhdGUsIGRh dGEpLg0KDQogICBDbGVhcmx5IGl0IHdvdWxkIGJlIG1vcmUgZWZmaWNpZW50IGlmIHRoZSBUQ1Ag aW1wbGVtZW50YXRpb24gd2VyZSB0bw0KICAgY29tYmluZSB0aGUgdGhyZWUgc2VwYXJhdGUgcGFj a2V0cyBpbnRvIG9uZSwgYW5kIHRoaXMgaXMgd2hhdCB0aGUNCiAgIGRlbGF5ZWQgYWNrIGZlYXR1 cmUgZW5hYmxlcy4NCg0KICAgV2l0aCBkZWxheWVkIGFjaywgdGhlIFRDUCBpbXBsZW1lbnRhdGlv biB3YWl0cyBhZnRlciByZWNlaXZpbmcgYSBkYXRhDQogICBwYWNrZXQsIHR5cGljYWxseSBmb3Ig MjAwIG1zLCBhbmQgdGhlbiBzZW5kcyBpdHMgYWNrIGlmIChhKSBtb3JlIGRhdGENCiAgIHBhY2tl dChzKSBhcnJpdmUsIChiKSB0aGUgcmVjZWl2aW5nIHByb2Nlc3MgZ2VuZXJhdGVzIHNvbWUgcmVw bHkNCiAgIGRhdGEsIG9yIChjKSAyMDAgbXMgZWxhcHNlIHdpdGhvdXQgZWl0aGVyIG9mIHRoZSBh Ym92ZSBvY2N1cnJpbmcuDQoNCiAgIFdpdGggZGVsYXllZCBhY2ssIHJlbW90ZSBsb2dpbiBiZWNv bWVzIG11Y2ggbW9yZSBlZmZpY2llbnQsDQogICBnZW5lcmF0aW5nIGp1c3Qgb25lIHBhY2tldCBp bnN0ZWFkIG9mIHRocmVlIGZvciBlYWNoIGNoYXJhY3RlciBlY2hvLg0KDQogICBUaGUgbG9naWMg b2YgZGVsYXllZCBhY2sgaXMgdGhhdCB0aGUgMjAwIG1zIGRlbGF5IGNhbm5vdCBkbyBhbnkNCiAg IHNpZ25pZmljYW50IGhhcm0uICBJZiBzb21ldGhpbmcgYXQgdGhlIG90aGVyIGVuZCB3ZXJlIHdh aXRpbmcgZm9yDQogICBzb21ldGhpbmcsIHRoZW4gdGhlIHJlY2VpdmluZyBwcm9jZXNzIHNob3Vs ZCBnZW5lcmF0ZSB0aGUgcmVwbHkgdGhhdA0KICAgdGhlIHRoaW5nIGF0IHRoZSBvdGhlciBlbmQg aXMgd2FpdGluZyBmb3IsIGFuZCBUQ1Agd2lsbCB0aGVuDQogICBpbW1lZGlhdGVseSBzZW5kIHRo YXQgcmVwbHkgKGNvbWJpbmVkIHdpdGggdGhlIGFjayBhbmQgd2luZG93DQogICB1cGRhdGUpLiAg QW5kIGlmIHRoZSByZWNlaXZpbmcgcHJvY2VzcyBkb2VzIG5vdCBpbiBmYWN0IGdlbmVyYXRlIGFu eQ0KICAgcmVwbHkgZm9yIHRoaXMgcGFydGljdWxhciBtZXNzYWdlLCB0aGVuIGJ5IGRlZmluaXRp b24gdGhlIHRoaW5nIGF0DQogICB0aGUgb3RoZXIgZW5kIGNhbm5vdCBiZSB3YWl0aW5nIGZvciBh bnl0aGluZy4gIFRoZXJlZm9yZSwgdGhlIDIwMCBtcw0KICAgZGVsYXkgaXMgaGFybWxlc3MuDQoN CiAgIFRoaXMgYXNzdW1wdGlvbiBtYXkgYmUgdHJ1ZSB1bmxlc3MgdGhlIHNlbmRlciBpcyB1c2lu ZyBOYWdsZSdzDQogICBhbGdvcml0aG0sIGEgc2ltaWxhciBlZmZpY2llbmN5IGZlYXR1cmUsIGNy ZWF0ZWQgdG8gcHJvdGVjdCB0aGUNCiAgIG5ldHdvcmsgZnJvbSBwb29ybHkgd3JpdHRlbiBjbGll bnQgc29mdHdhcmUgdGhhdCBwZXJmb3JtcyBtYW55IHJhcGlkDQogICBzbWFsbCB3cml0ZXMgaW4g c3VjY2Vzc2lvbi4gIE5hZ2xlJ3MgYWxnb3JpdGhtIGFsbG93cyB0aGVzZSBzbWFsbA0KICAgd3Jp dGVzIHRvIGJlIGNvYWxlc2NlZCBpbnRvIGxhcmdlciwgbGVzcyB3YXN0ZWZ1bCBwYWNrZXRzLg0K DQogICBVbmZvcnR1bmF0ZWx5LCBOYWdsZSdzIGFsZ29yaXRobSBhbmQgZGVsYXllZCBhY2ssIHR3 byB2YWx1YWJsZQ0KICAgZWZmaWNpZW5jeSBmZWF0dXJlcywgY2FuIGludGVyYWN0IGJhZGx5IHdp dGggZWFjaCBvdGhlciB3aGVuIHVzZWQNCiAgIHRvZ2V0aGVyIFtOYWdsZURBXS4NCg0KICAgRFNP IHJlcXVlc3QgbWVzc2FnZXMgZWxpY2l0IHJlc3BvbnNlczsgRFNPIHVuaWRpcmVjdGlvbmFsIG1l c3NhZ2VzDQogICBhbmQgRFNPIHJlc3BvbnNlIG1lc3NhZ2VzIGRvIG5vdC4NCg0KICAgRm9yIERT TyByZXF1ZXN0IG1lc3NhZ2VzLCB3aGljaCBkbyBlbGljaXQgcmVzcG9uc2VzLCBOYWdsZSdzDQog ICBhbGdvcml0aG0gYW5kIGRlbGF5ZWQgYWNrIHdvcmsgYXMgaW50ZW5kZWQuDQoNCiAgIEZvciBE U08gbWVzc2FnZXMgdGhhdCBkbyBub3QgZWxpY2l0IHJlc3BvbnNlcywgdGhlIGRlbGF5ZWQgYWNr DQogICBtZWNoYW5pc20gY2F1c2VzIHRoZSBhY2sgdG8gYmUgZGVsYXllZCBieSAyMDAgbXMuICBU aGUgMjAwIG1zIGRlbGF5DQogICBvbiB0aGUgYWNrIGNhbiBpbiB0dXJuIGNhdXNlIE5hZ2xlJ3Mg YWxnb3JpdGhtIHRvIHByZXZlbnQgdGhlIHNlbmRlcg0KICAgZnJvbSBzZW5kaW5nIGFueSBtb3Jl IGRhdGEgZm9yIDIwMCBtcyB1bnRpbCB0aGUgYXdhaXRlZCBhY2sgYXJyaXZlcy4NCiAgIE9uIGFu IGVudGVycHJpc2UgR2lnYWJpdCBFdGhlcm5ldCAoR2lnRSkgYmFja2JvbmUgd2l0aCBzdWItDQog ICBtaWxsaXNlY29uZCByb3VuZC10cmlwIHRpbWVzLCBhIDIwMCBtcyBkZWxheSBpcyBlbm9ybW91 cyBpbg0KICAgY29tcGFyaXNvbi4NCg0KICAgV2hlbiB0aGlzIGlzc3VlcyBpcyByYWlzZWQsIHRo ZXJlIGFyZSB0d28gc29sdXRpb25zIHRoYXQgYXJlIG9mdGVuDQogICBvZmZlcmVkLCBuZWl0aGVy IG9mIHRoZW0gaWRlYWw6DQoNCiAgIDEuICBEaXNhYmxlIGRlbGF5ZWQgYWNrLiAgRm9yIERTTyBt ZXNzYWdlcyB0aGF0IGVsaWNpdCBubyByZXNwb25zZSwNCiAgICAgICByZW1vdmluZyBkZWxheWVk IGFjayBhdm9pZHMgdGhlIG5lZWRsZXNzIDIwMCBtcyBkZWxheSBhbmQgc2VuZHMNCiAgICAgICBi YWNrIGFuIGltbWVkaWF0ZSBhY2sgdGhhdCB0ZWxscyBOYWdsZSdzIGFsZ29yaXRobSB0aGF0IGl0 IHNob3VsZA0KICAgICAgIGltbWVkaWF0ZWx5IGdyYW50IHRoZSBzZW5kZXIgcGVybWlzc2lvbiB0 byBzZW5kIGl0cyBuZXh0IHBhY2tldC4NCiAgICAgICBVbmZvcnR1bmF0ZWx5LCBmb3IgRFNPIG1l c3NhZ2VzIHRoYXQgKmRvKiBlbGljaXQgYSByZXNwb25zZSwNCiAgICAgICByZW1vdmluZyBkZWxh eWVkIGFjayByZW1vdmVzIHRoZSBlZmZpY2llbmN5IGdhaW5zIG9mIGNvbWJpbmluZw0KICAgICAg IGFja3Mgd2l0aCBkYXRhLCBhbmQgdGhlIHJlc3BvbmRlciB3aWxsIG5vdyBzZW5kIHR3byBvciB0 aHJlZQ0KICAgICAgIHBhY2tldHMgaW5zdGVhZCBvZiBvbmUuDQoNCiAgIDIuICBEaXNhYmxlIE5h Z2xlJ3MgYWxnb3JpdGhtLiAgV2hlbiBhY2tzIGFyZSBkZWxheWVkIGJ5IHRoZSBkZWxheWVkDQog ICAgICAgYWNrIGFsZ29yaXRobSwgcmVtb3ZpbmcgTmFnbGUncyBhbGdvcml0aG0gcHJldmVudHMg dGhlIHNlbmRlcg0KICAgICAgIGZyb20gYmVpbmcgYmxvY2tlZCBmcm9tIHNlbmRpbmcgaXRzIG5l eHQgc21hbGwgcGFja2V0DQogICAgICAgaW1tZWRpYXRlbHkuICBVbmZvcnR1bmF0ZWx5LCBvbiBh IG5ldHdvcmsgd2l0aCBhIGhpZ2hlciByb3VuZC0NCiAgICAgICB0cmlwIHRpbWUsIHJlbW92aW5n IE5hZ2xlJ3MgYWxnb3JpdGhtIHJlbW92ZXMgdGhlIGVmZmljaWVuY3kNCiAgICAgICBnYWlucyBv ZiBjb21iaW5pbmcgbXVsdGlwbGUgc21hbGwgcGFja2V0cyBpbnRvIGZld2VyIGxhcmdlciBvbmVz LA0KICAgICAgIHdpdGggdGhlIGdvYWwgb2YgbGltaXRpbmcgdGhlIG51bWJlciBvZiBzbWFsbCBw YWNrZXRzIGluIGZsaWdodA0KICAgICAgIGF0IGFueSBvbmUgdGltZS4NCg0KICAgVGhlIHByb2Js ZW0gaGVyZSBpcyB0aGF0IHdpdGggRFNPIG1lc3NhZ2VzIHRoYXQgZWxpY2l0IG5vIHJlc3BvbnNl LA0KICAgdGhlIFRDUCBpbXBsZW1lbnRhdGlvbiBpcyBzdHVjayB3YWl0aW5nLCB1bnN1cmUgaWYg YSByZXNwb25zZSBpcw0KICAgYWJvdXQgdG8gYmUgZ2VuZXJhdGVkIG9yIHdoZXRoZXIgdGhlIFRD UCBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZ28NCiAgIGFoZWFkIGFuZCBzZW5kIGFuIGFjayBhbmQg d2luZG93IHVwZGF0ZS4NCg0KICAgVGhlIHNvbHV0aW9uIGlzIG5ldHdvcmtpbmcgQVBJcyB0aGF0 IGFsbG93IHRoZSByZWNlaXZlciB0byBpbmZvcm0gdGhlDQogICBUQ1AgaW1wbGVtZW50YXRpb24g dGhhdCBhIHJlY2VpdmVkIG1lc3NhZ2UgaGFzIGJlZW4gcmVhZCwgcHJvY2Vzc2VkLA0KICAgYW5k IG5vIHJlc3BvbnNlIGZvciB0aGlzIG1lc3NhZ2Ugd2lsbCBiZSBnZW5lcmF0ZWQuICBUQ1AgY2Fu IHRoZW4NCiAgIHN0b3Agd2FpdGluZyBmb3IgYSByZXNwb25zZSB0aGF0IHdpbGwgbmV2ZXIgY29t ZSwgYW5kIGltbWVkaWF0ZWx5IGdvDQogICBhaGVhZCBhbmQgc2VuZCBhbiBhY2sgYW5kIHdpbmRv dyB1cGRhdGUuDQoNCiAgIEZvciBpbXBsZW1lbnRhdGlvbnMgb2YgRFNPLCBkaXNhYmxpbmcgZGVs YXllZCBhY2sgaXMgTk9UIFJFQ09NTUVOREVEDQogICBiZWNhdXNlIG9mIHRoZSBoYXJtIHRoaXMg Y2FuIGRvIHRvIHRoZSBuZXR3b3JrLg0KDQogICBGb3IgaW1wbGVtZW50YXRpb25zIG9mIERTTywg ZGlzYWJsaW5nIE5hZ2xlJ3MgYWxnb3JpdGhtIGlzIE5PVA0KICAgUkVDT01NRU5ERUQgYmVjYXVz ZSBvZiB0aGUgaGFybSB0aGlzIGNhbiBkbyB0byB0aGUgbmV0d29yay4NCg0KICAgQXQgdGhlIHRp bWUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIGJlaW5nIHByZXBhcmVkIGZvciBwdWJsaWNhdGlvbiwg aXQNCiAgIGlzIGtub3duIHRoYXQgYXQgbGVhc3Qgb25lIFRDUCBpbXBsZW1lbnRhdGlvbiBwcm92 aWRlcyB0aGUgYWJpbGl0eQ0KICAgZm9yIHRoZSByZWNpcGllbnQgb2YgYSBUQ1AgbWVzc2FnZSB0 byBzaWduYWwgdGhhdCBpdCBpcyBub3QgZ29pbmcgdG8NCiAgIHNlbmQgYSByZXNwb25zZSwgYW5k IGhlbmNlIHRoZSBkZWxheWVkIGFjayBtZWNoYW5pc20gY2FuIHN0b3ANCiAgIHdhaXRpbmcuICBJ bXBsZW1lbnRhdGlvbnMgb24gb3BlcmF0aW5nIHN5c3RlbXMgd2hlcmUgdGhpcyBmZWF0dXJlIGlz DQogICBhdmFpbGFibGUgU0hPVUxEIG1ha2UgdXNlIG9mIGl0Lg0KDQotLQ0KDQo= From nobody Thu Mar 14 23:35:16 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCB0130E2F for ; Thu, 14 Mar 2019 23:35:14 -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 7RdZ58UGewhk for ; Thu, 14 Mar 2019 23:35:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803: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 CD433127987 for ; Thu, 14 Mar 2019 23:35:12 -0700 (PDT) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CA118279602 for ; Fri, 15 Mar 2019 15:35:09 +0900 (JST) Received: by mail-wr1-f53.google.com with SMTP id t5so8319670wri.7 for ; Thu, 14 Mar 2019 23:35:09 -0700 (PDT) X-Gm-Message-State: APjAAAWZ34LGRpgOVkhx++ghchNR2F3xIRV1LAm93uLoA1EPukpEn1oP CVUXssl9361pKaAI/vunhcQAaC/abd8YqHSllII= X-Google-Smtp-Source: APXvYqx/2JPv5XMk7fvyG6ryHr9ZdyWVa5kTR3YYNobtembpNEjnlhgx6NgIrCJ8ae+Fi4507zZKZUz4J+o8TRmvaKI= X-Received: by 2002:adf:f487:: with SMTP id l7mr1069741wro.86.1552631707519; Thu, 14 Mar 2019 23:35:07 -0700 (PDT) MIME-Version: 1.0 References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <787AE7BB302AE849A7480A190F8B93302EA2273F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA23CC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA24AC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25443@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25F47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA27F2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA27F2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yoshifumi Nishida Date: Thu, 14 Mar 2019 23:34:55 -0700 X-Gmail-Original-Message-ID: Message-ID: To: mohamed.boucadair@orange.com Cc: Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000064d18705841c3d42" Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 06:35:15 -0000 --00000000000064d18705841c3d42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, On Mon, Mar 4, 2019 at 7:21 AM wrote: > Yoshi, > > > > =E2=80=9CI don't think this is always true. > > If mptcp client uses multiple subflows for the mptcp connection, how does > it looks to the server? > > I believe it should be a single connection on the serve side.=E2=80=9D > > > > The server will always see the same source address/port. > > > > =E2=80=9CBut, this means when you convert mptcp into tcp, you'll need to = merge > multiple TCP connections into a single TCP connection.=E2=80=9D > > > > The glue is done at the TCP level by the converter. > > > > =E2=80=9CThis merging process will not be very easy when TLS are used for > subflows.=E2=80=9D > > > > Why? I think the disconnect is that you seem to imply that data from > various segments are multiplexed in the same segment upstream. > > Sorry for my slow response. I did some small experiments to examine this and took some time to setup. After I've checked, I've found the concept of the converter can work properly with TLS. I'm sorry for the confusion. I am now fine with the current statement on this point. -- Yoshi --00000000000064d18705841c3d42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,

On Mon, Mar 4, 2019 at 7:21 AM <mohamed.boucadair@o= range.com> wrote:

Yoshi,

=C2=A0

=E2=80=9CI don't think this is always true.

If mptcp client uses multiple s= ubflows for the mptcp connection, how does it looks to the server?

I believe it should be a single= connection on the serve side.=E2=80=9D

=C2=A0

The server will always see the same source ad= dress/port.

=C2=A0

=E2=80=9CBut, this means when y= ou convert mptcp into tcp, you'll need to merge multiple TCP connection= s into a single TCP connection.=E2=80=9D

=C2=A0

The glue is done at the TCP level by the conv= erter.

=C2=A0

=E2=80=9CThis merging process w= ill not be very easy when TLS are used for subflows.=E2=80=9D=

=C2=A0

Why? I think the disconnect is that you seem to imply = that data from various segments are multiplexed in the same segment upstrea= m. =C2=A0=C2=A0

=C2=A0


Sorry for my slow response. I did some = small experiments to examine this and took some time to setup.
Af= ter I've checked, I've found the concept of the converter can work = properly with TLS.
I'm sorry for the confusion. I am now fine= with the current statement on this point.
--
Yoshi=C2= =A0

<= div lang=3D"FR">
=
--00000000000064d18705841c3d42-- From nobody Fri Mar 15 00:28:44 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4EE1311F9 for ; Fri, 15 Mar 2019 00:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 JIqvwSjGM77E for ; Fri, 15 Mar 2019 00:28:39 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADD6127987 for ; Fri, 15 Mar 2019 00:28:39 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 44LHHp0H6qz8tZm; Fri, 15 Mar 2019 08:28:38 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 44LHHn6jN3z3wbD; Fri, 15 Mar 2019 08:28:37 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0439.000; Fri, 15 Mar 2019 08:28:37 +0100 From: To: Yoshifumi Nishida CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Updated version of draft-ietf-tcpm-converters-05 Thread-Index: AQHU2vlApo0NOiqnkki5WmPF1laDg6YMSyrw Date: Fri, 15 Mar 2019 07:28:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3E51E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <787AE7BB302AE849A7480A190F8B93302EA2273F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA23CC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA24AC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25443@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA25F47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA27F2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA3E51EOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 07:28:42 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA3E51EOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNCkdyZWF0IQ0KDQpUaGFuayB5b3UgZm9yIGRvdWJsZSBjaGVja2luZy4NCg0K Q2hlZXJzLA0KTWVkDQoNCkRlIDogWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNm Yy53aWRlLmFkLmpwXQ0KRW52b3nDqSA6IHZlbmRyZWRpIDE1IG1hcnMgMjAxOSAwNzozNQ0Kw4Ag OiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpDYyA6IFlvc2hpZnVtaSBOaXNoaWRhOyB0Y3Bt QGlldGYub3JnDQpPYmpldCA6IFJlOiBbdGNwbV0gVXBkYXRlZCB2ZXJzaW9uIG9mIGRyYWZ0LWll dGYtdGNwbS1jb252ZXJ0ZXJzLTA1DQoNCkhpIE1lZCwNCg0KT24gTW9uLCBNYXIgNCwgMjAxOSBh dCA3OjIxIEFNIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpZb3NoaSwNCg0K4oCcSSBkb24ndCB0aGluayB0 aGlzIGlzIGFsd2F5cyB0cnVlLg0KSWYgbXB0Y3AgY2xpZW50IHVzZXMgbXVsdGlwbGUgc3ViZmxv d3MgZm9yIHRoZSBtcHRjcCBjb25uZWN0aW9uLCBob3cgZG9lcyBpdCBsb29rcyB0byB0aGUgc2Vy dmVyPw0KSSBiZWxpZXZlIGl0IHNob3VsZCBiZSBhIHNpbmdsZSBjb25uZWN0aW9uIG9uIHRoZSBz ZXJ2ZSBzaWRlLuKAnQ0KDQpUaGUgc2VydmVyIHdpbGwgYWx3YXlzIHNlZSB0aGUgc2FtZSBzb3Vy Y2UgYWRkcmVzcy9wb3J0Lg0KDQrigJxCdXQsIHRoaXMgbWVhbnMgd2hlbiB5b3UgY29udmVydCBt cHRjcCBpbnRvIHRjcCwgeW91J2xsIG5lZWQgdG8gbWVyZ2UgbXVsdGlwbGUgVENQIGNvbm5lY3Rp b25zIGludG8gYSBzaW5nbGUgVENQIGNvbm5lY3Rpb24u4oCdDQoNClRoZSBnbHVlIGlzIGRvbmUg YXQgdGhlIFRDUCBsZXZlbCBieSB0aGUgY29udmVydGVyLg0KDQrigJxUaGlzIG1lcmdpbmcgcHJv Y2VzcyB3aWxsIG5vdCBiZSB2ZXJ5IGVhc3kgd2hlbiBUTFMgYXJlIHVzZWQgZm9yIHN1YmZsb3dz LuKAnQ0KDQpXaHk/IEkgdGhpbmsgdGhlIGRpc2Nvbm5lY3QgaXMgdGhhdCB5b3Ugc2VlbSB0byBp bXBseSB0aGF0IGRhdGEgZnJvbSB2YXJpb3VzIHNlZ21lbnRzIGFyZSBtdWx0aXBsZXhlZCBpbiB0 aGUgc2FtZSBzZWdtZW50IHVwc3RyZWFtLg0KDQoNClNvcnJ5IGZvciBteSBzbG93IHJlc3BvbnNl LiBJIGRpZCBzb21lIHNtYWxsIGV4cGVyaW1lbnRzIHRvIGV4YW1pbmUgdGhpcyBhbmQgdG9vayBz b21lIHRpbWUgdG8gc2V0dXAuDQpBZnRlciBJJ3ZlIGNoZWNrZWQsIEkndmUgZm91bmQgdGhlIGNv bmNlcHQgb2YgdGhlIGNvbnZlcnRlciBjYW4gd29yayBwcm9wZXJseSB3aXRoIFRMUy4NCkknbSBz b3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4gSSBhbSBub3cgZmluZSB3aXRoIHRoZSBjdXJyZW50IHN0 YXRlbWVudCBvbiB0aGlzIHBvaW50Lg0KLS0NCllvc2hpDQoNCg== --_000_787AE7BB302AE849A7480A190F8B93302EA3E51EOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgWW9zaGksDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5HcmVhdCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciBkb3VibGUgY2hlY2tp bmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53 aWRlLmFkLmpwXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDE1IG1hcnMg MjAxOSAwNzozNTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09M Tjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gWW9zaGlmdW1pIE5pc2hpZGE7IHRjcG1AaWV0Zi5vcmc8 YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdGNwbV0gVXBkYXRlZCB2ZXJzaW9uIG9mIGRy YWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNZWQsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciA0LCAyMDE5IGF0IDc6MjEg QU0gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3NoaSwNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbHdheXMgdHJ1ZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiBtcHRjcCBj bGllbnQgdXNlcyBtdWx0aXBsZSBzdWJmbG93cyBmb3IgdGhlIG1wdGNwIGNvbm5lY3Rpb24sIGhv dyBkb2VzIGl0IGxvb2tzIHRvIHRoZSBzZXJ2ZXI/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBiZWxpZXZlIGl0IHNob3Vs ZCBiZSBhIHNpbmdsZSBjb25uZWN0aW9uIG9uIHRoZSBzZXJ2ZSBzaWRlLuKAnTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5UaGUgc2VydmVyIHdpbGwgYWx3YXlzIHNlZSB0aGUgc2FtZSBzb3Vy Y2UgYWRkcmVzcy9wb3J0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+4oCcQnV0LCB0aGlzIG1l YW5zIHdoZW4geW91IGNvbnZlcnQgbXB0Y3AgaW50byB0Y3AsIHlvdSdsbCBuZWVkIHRvIG1lcmdl IG11bHRpcGxlIFRDUCBjb25uZWN0aW9ucyBpbnRvIGEgc2luZ2xlIFRDUCBjb25uZWN0aW9uLuKA nTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgZ2x1ZSBpcyBkb25lIGF0IHRoZSBUQ1Ag bGV2ZWwgYnkgdGhlIGNvbnZlcnRlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPuKAnFRoaXMg bWVyZ2luZyBwcm9jZXNzIHdpbGwgbm90IGJlIHZlcnkgZWFzeSB3aGVuIFRMUyBhcmUgdXNlZCBm b3Igc3ViZmxvd3Mu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5XaHk/DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgdGhpbmsgdGhlIGRpc2Nvbm5lY3Qg aXMgdGhhdCB5b3Ugc2VlbSB0byBpbXBseSB0aGF0IGRhdGEgZnJvbSB2YXJpb3VzIHNlZ21lbnRz IGFyZSBtdWx0aXBsZXhlZCBpbiB0aGUgc2FtZSBzZWdtZW50IHVwc3RyZWFtLg0KPC9zcGFuPiZu YnNwOzwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNvcnJ5IGZvciBteSBzbG93IHJlc3BvbnNlLiBJIGRpZCBzb21lIHNtYWxs IGV4cGVyaW1lbnRzIHRvIGV4YW1pbmUgdGhpcyBhbmQgdG9vayBzb21lIHRpbWUgdG8gc2V0dXAu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRl ciBJJ3ZlIGNoZWNrZWQsIEkndmUgZm91bmQgdGhlIGNvbmNlcHQgb2YgdGhlIGNvbnZlcnRlciBj YW4gd29yayBwcm9wZXJseSB3aXRoIFRMUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBzb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4gSSBhbSBu b3cgZmluZSB3aXRoIHRoZSBjdXJyZW50IHN0YXRlbWVudCBvbiB0aGlzIHBvaW50LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvc2hpJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302EA3E51EOPEXCAUBMA2corp_-- From nobody Fri Mar 15 02:33:06 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5A13121E for ; Fri, 15 Mar 2019 02:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4Evjc6cX0qG2 for ; Fri, 15 Mar 2019 02:32:57 -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 76A4E127887 for ; Fri, 15 Mar 2019 02:32:52 -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:To:References: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=Hq0ZbCssMuyuVHMihgKNMkc+5d6TlAmB1178RJjyUi4=; b=GqtfbsITcweauPXi613Z7lb7R OMqxOdKJoT0x5XQjaUSYY3FLKLEfCYbza3sdzYBAkKEzRGu2ypdWINxTxCLYgaeqSzpVwsCfoBnd3 c+PSld+fiTC2BxA9lh8773knKnf7DVeFVv2EkkDmVsSLYkHo6TvGX0ubM0gUYZVehsgYmBR1JnT67 NjOdvFvp9g9TrkYlwlslXpcAzVk1zA/5dhe+8GYemXMGBpxQ1pOzP+ND3zqi5c+smPHL09yKLzx0Y 81SZH99ZNRUu6sI2xSY8kn2X3pO2WfXaOIpkPHErOpXT7AXjSKJEF/EfrEoNl8rW3mXtZvEdAt6xn E6zuh8m+g==; Received: from [31.185.135.153] (port=47040 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h4jCr-0002kh-JW; Fri, 15 Mar 2019 09:32:50 +0000 References: To: tcpm IETF list , iccrg IRTF list From: Bob Briscoe X-Forwarded-Message-Id: Message-ID: Date: Fri, 15 Mar 2019 09:32:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------762A4C75311A3E00F78E3690" 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: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 09:32:59 -0000 This is a multi-part message in MIME format. --------------762A4C75311A3E00F78E3690 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Forwarding to tcpm & iccrg - apologies if you were already on one of the lists that received this. Olivier has been working hard on integrating the pieces of a Linux implementation of TCP Prague, and is close to having a version ported against the tip of the Linux mainline tree. This is his request for more people to get involved. Bob -------- Forwarded Message -------- Subject: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 Date: Wed, 6 Mar 2019 10:26:05 +0000 From: Tilmans, Olivier (Nokia - BE/Antwerp) To: hackathon@ietf.org , tcpprague@ietf.org CC: dlebrun@google.com , Joakim Misund , Bob Briscoe , Quentin De Coninck , François Michel , Mirja Kuehlewind , Maxime Piraux , Olga Albisser , Fabien Duchêne , De Schepper, Koen (Nokia - BE/Antwerp) Hi all, We'll be working on the "TCP Prague" congestion control/L4S architecture during the IETF-104 hackaton. This topics aims at accelerating the work that started during the IETF93 (coincidentally also in Prague), in order to get TCP Prague to an 'usable' state—i.e., meet the safety requirements and have supporting materials (e.g., VMs, labs) to let people experiment with it. Depending on people's interest, prototyping something similar for QUIC is another possible output. Details and links to resources/supporting drafts are available at https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon#tcp-prague and copied below. Additionally, few topics will presented during netdev 0x13 the week before. See you in Prague. Best, Olivier Implementation and experimentation of TCP Prague/L4S * Champion * Olivier Tilmans * Projects * Prototype the "TCP Prague" congestion control on Linux * Finalize the implementation of accurate ECN (draft conformance), and port it on Linux v5.x * Build tooling around L4S to let people experiment with the technology (e.g., virtual machine, or mininet labs) * Work towards "QUIC Prague" * Resources * TCP Prague * Repository — ​https://github.com/L4STeam/tcp-prague * Requirements — ​https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21 * Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s * Accurate ECN * Specs — ​https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07 * Implementation for Linux v4.17 — ​https://github.com/mirjak/linux-accecn * Past netdev talk — https://www.netdevconf.org/2.2/session.html?kuhlewind-accecn-talk * Paced Chirping * Repository — ​https://github.com/JoakimMisund/PacedChirping * Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-chirp * L4S architecture * Specs — ​https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03 * DualPI2 AQM * Specs — ​https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08 * Repository — ​https://github.com/L4STeam/sch_dualpi2_upstream * Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM * RITE Project — ​https://riteproject.eu/dctth/#code _______________________________________________ tcpPrague mailing list tcpPrague@ietf.org https://www.ietf.org/mailman/listinfo/tcpprague --------------762A4C75311A3E00F78E3690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Forwarding to tcpm & iccrg - apologies if you were already on one of the lists that received this.

Olivier has been working hard on integrating the pieces of a Linux implementation of TCP Prague, and is close to having a version ported against the tip of the Linux mainline tree. This is his request for more people to get involved.


Bob


-------- Forwarded Message --------
Subject: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Date: Wed, 6 Mar 2019 10:26:05 +0000
From: Tilmans, Olivier (Nokia - BE/Antwerp) <olivier.tilmans@nokia-bell-labs.com>
To: hackathon@ietf.org <hackathon@ietf.org>, tcpprague@ietf.org <tcpprague@ietf.org>
CC: dlebrun@google.com <dlebrun@google.com>, Joakim Misund <joakim.misund@gmail.com>, Bob Briscoe <research@bobbriscoe.net>, Quentin De Coninck <quentin.deconinck@uclouvain.be>, François Michel <francois.michel@uclouvain.be>, Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Maxime Piraux <maxime.piraux@uclouvain.be>, Olga Albisser <olga@albisser.org>, Fabien Duchêne <fabien.duchene@uclouvain.be>, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>


Hi all,

We'll be working on the "TCP Prague" congestion control/L4S architecture during the IETF-104 hackaton.
This topics aims at accelerating the work that started during the IETF93 (coincidentally also in Prague), in order to get TCP Prague to an 'usable' state—i.e., meet the safety requirements and have supporting materials (e.g., VMs, labs) to let people experiment with it. Depending on people's interest, prototyping something similar for QUIC is another possible output.

Details and links to resources/supporting drafts are available at https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon#tcp-prague and copied below.
Additionally, few topics will presented during netdev 0x13 the week before.

See you in Prague.

Best,
Olivier


Implementation and experimentation of TCP Prague/L4S

* Champion
* Olivier Tilmans <olivier.tilmans at nokia-bell-labs.com>
* Projects
* Prototype the "TCP Prague" congestion control on Linux
* Finalize the implementation of accurate ECN (draft conformance), and port it on Linux v5.x * Build tooling around L4S to let people experiment with the technology (e.g., virtual machine, or mininet labs)
* Work towards "QUIC Prague"
* Resources
* TCP Prague
* Repository — ​https://github.com/L4STeam/tcp-prague
* Requirements — ​https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21
* Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s
* Accurate ECN
* Specs — ​https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07
* Implementation for Linux v4.17 — ​https://github.com/mirjak/linux-accecn
* Past netdev talk — https://www.netdevconf.org/2.2/session.html?kuhlewind-accecn-talk
* Paced Chirping * Repository — ​https://github.com/JoakimMisund/PacedChirping
* Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-chirp
* L4S architecture
* Specs — ​https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03
* DualPI2 AQM
* Specs — ​https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
* Repository — ​https://github.com/L4STeam/sch_dualpi2_upstream
* Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM
* RITE Project — ​https://riteproject.eu/dctth/#code
_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague
--------------762A4C75311A3E00F78E3690-- From nobody Fri Mar 15 03:46:48 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD29127A73 for ; Fri, 15 Mar 2019 03:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpQY96mMAQQp for ; Fri, 15 Mar 2019 03:46:41 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 6A6FC12865E for ; Fri, 15 Mar 2019 03:46:41 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id k2so9529510qtm.1 for ; Fri, 15 Mar 2019 03:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=myDgnxek1A0g6mVA8qKx0rtEvTjX98r2YbQxJa5nzkk=; b=K1H4RkB5e94N/gjlVhqnm2OAsFasBNP1H8xZDeFt67VpkYwiyxLRWL9FRyiupJZn/H YWJ8WSj5LtaNkzdJuCldFFIjl4s+udDqtssCKcKPB4U1eOrNXcBO/coyQSOmI7jwe2Z/ PBV/jyYuQoSzxZxuIGjb6E/3ySWcZR84nCPuHqeEbcFE7zKOcBnsMLr9WLkbtADvYjkv VY5samQ+S/Ehz81/ZDSv7oDMH5YlXqLpkV3ClUxd8RN0hVkbIeWDvX034uUKS/mT97m9 iTAdW93tyH7djuWBO6cR1sEdk7Vo9aO6YwmWeWHy1sQb7FEwE6V+ntow79mYIIoIlYVc MevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=myDgnxek1A0g6mVA8qKx0rtEvTjX98r2YbQxJa5nzkk=; b=WjjgvdqNXYGXmmc0dfoOk/Dxw/M5n3fITXjiid/CW2/fzC5HaaSvtiw9ALRHEs3QDK 8P8VraXUWG/6qe9KLwr58nR418hL6ZCPDI8mXcvLLmDMSqTjWDg5q+vKh+F+T/Aa7n6N j0rV9CAwWkho3yHJXhuZmpr0LGXlaJFGNRr4dBtyzOKcigUYU/iQ+dQi1oKHc85X15p8 1fd3q9YgNQqnO9LhNRxk79E/LvE4hQv/laxroaQAncqvg6MPp7j/9kkXuuuemAN/S8RB /2sj0PWX2Ro3NRBhcWSoNUFIB4lgxOQf2/XX0naS8DaAS0dgTL0lGnkSKJm81uW6c89Z JiSA== X-Gm-Message-State: APjAAAUoTG35kAa/rZsdi3A4h9ZeVQcjdNQW6udk5khAXfDrW8tG5oAJ XFLghiPN2IpLmLMWiwXmEH6grI0BbWWZ4j9JCueWV/nW X-Google-Smtp-Source: APXvYqzb92DFRl4jyS7VknHEZ2diUVpoGoSZx1HrsA/iMdO3RhZ+1n+qHisftZkwchlFH7qOx5A8iqNkoaequRsCidQ= X-Received: by 2002:a0c:a485:: with SMTP id x5mr1906210qvx.206.1552646800307; Fri, 15 Mar 2019 03:46:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 15 Mar 2019 03:46:28 -0700 Message-ID: To: Bob Briscoe Cc: tcpm IETF list , iccrg IRTF list , ecn-sane@lists.bufferbloat.net, bloat Content-Type: multipart/alternative; boundary="000000000000fe7ad705841fc0ee" Archived-At: Subject: Re: [tcpm] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 10:46:46 -0000 --000000000000fe7ad705841fc0ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bufferbloat.net's ecn-sane working group members have a co-ordinated response to your efforts brewing but it's not ready yet. We have a worldwide team of linux and freebsd developers co-ordinating on landing code for our competing proposal "Some Congestion Experienced", which we submitted to tsvwg last sunday. That draft is under continuous revision, here: https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-morton-taht= -tsvwg-sce.txt Our Linux and FreeBSD team is also flying into prague for SCE presentations at netdevconf and ietf. Some background to this: after the L4S/TCP Prague/and dualpi experiments appeared stalled out indefinitely in the IETF, and with our own frustration with IETF processes, bufferbloat.net project members publicly formed our own working group to look into the problems with ecn, back in august of last year. Its charter is here: https://www.bufferbloat.net/projects/ecn-sane/wiki/ We were unaware, until last month, that the cable industry had 16 months back gone and formed its own private working group also, and was intending to turn the tcp prague/l4s/dualpi IETF "experiments" into an actual DOCSIS standard. Our SCE proposal appears to be backward compatible with the existing 10s-100s of millions of ecn-enabled fq_codel[1] and sch_cake[2] deployments, and doesn't require any changes to any RFC3168 tcps (or any tcp-friendly congestion control) at all in order to basically work. tcp-prague is subtly incompatible with that, and dualpi, more so. Our proposal is different also, it proposes some receiver side changes in order to get the full benefit of SCE while remaining backward compatible with the existing meaning of the CE codepoint. In either case, either approach essentially permanently redefines the ECT_1 codepoint incompatibly, once and for all, and for all time. This is a final battle over the meaning of a single bit in IP, and I expect the debates to be as difficult as the ones described in https://www.ietf.org/rfc/ien/ien137.txt - I would really, really, really prefer that they stay technical and not veer into politics, but I have little hope for that. The members of the ecn-sane working group are delighted to finally hear that running code for tcp-prague might land this ietf, and look forward to finally testing the whole l4s/tcpprague/dualpi architecture in conjunction with the flent.org 's and irtt's exhaustive suite of tests and servers in the cloud in the coming months, both against our existing, deployed, fq_codel, fq_pie, cake and pie derived solutions and our new SCE proposal. We hope to finally be able to write new tests for flent in particular, that can show tcpprague off in the ways that are important to those developing it. Flent has some basic dctcp tests, but nothing that can get down below a 20ms sample rate on modern hardware. (currently. It's easy to add tests, flent is written in python) We also hope that more test tools and implementations in ns2 and ns3 show up for tcpprauge and dualpi show up soon also, from members of those projects. Note: sunday's dual-pi linux submission was kicked back from the linux networking developers due to some technical and legal problems with linux net-next HEAD ( https://patchwork.ozlabs.org/patch/1054521/ ) , and I do hope that a corrected version lands soon, so we can safely test it with current versions of OpenWrt, etc. Finally, running code. Will we find consensus? Thx! [1] https://tools.ietf.org/html/rfc8290 [2] sch_cake was available for 3 years out of tree and was mainlined last august, in linux 4.19. It is partially described by "Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways" " https://arxiv.org/pdf/1804.07617.pdf A second paper describing its fq_codel-derived "cobalt" AQM algorithm is awaiting publication in a peer reviewed journal. It has been part of openwrt and the related sqm-scripts for many years and is widely deployed on multiple commercial products, such as those from eero and evenroute. Cake has a docsis specific mode which we longed for cablelabs to evaluate. On Fri, Mar 15, 2019 at 2:33 AM Bob Briscoe wrote: > Forwarding to tcpm & iccrg - apologies if you were already on one of the > lists that received this. > > Olivier has been working hard on integrating the pieces of a Linux > implementation of TCP Prague, and is close to having a version ported > against the tip of the Linux mainline tree. This is his request for more > people to get involved. > > > Bob > > > -------- Forwarded Message -------- > Subject: [tcpPrague] Implementation and experimentation of TCP Prague/L4S > hackaton at IETF104 > Date: Wed, 6 Mar 2019 10:26:05 +0000 > From: Tilmans, Olivier (Nokia - BE/Antwerp) > > > To: hackathon@ietf.org , > tcpprague@ietf.org > CC: dlebrun@google.com , Joakim > Misund , Bob Briscoe > , Quentin De Coninck > , > Fran=C3=A7ois Michel > , Mirja Kuehlewind > , > Maxime Piraux , > Olga Albisser , Fabien Duch=C3=AAn= e > , De Schepper, > Koen (Nokia - BE/Antwerp) > > > Hi all, > > We'll be working on the "TCP Prague" congestion control/L4S architecture > during the IETF-104 hackaton. > This topics aims at accelerating the work that started during the IETF93 > (coincidentally also in Prague), in order to get TCP Prague to an 'usable= ' > state=E2=80=94i.e., meet the safety requirements and have supporting mate= rials > (e.g., VMs, labs) to let people experiment with it. Depending on people's > interest, prototyping something similar for QUIC is another possible outp= ut. > > Details and links to resources/supporting drafts are available at > https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon#tcp-prague and > copied below. > Additionally, few topics will presented during netdev 0x13 the week befor= e. > > See you in Prague. > > Best, > Olivier > > > Implementation and experimentation of TCP Prague/L4S > > * Champion > * Olivier Tilmans > * Projects > * Prototype the "TCP Prague" congestion control on Linux > * Finalize the implementation of accurate ECN (draft conformance), and > port it on Linux v5.x * Build tooling around L4S to let people experiment > with the technology (e.g., virtual machine, or mininet labs) > * Work towards "QUIC Prague" > * Resources > * TCP Prague > * Repository =E2=80=94 =E2=80=8Bhttps://github.com/L4STeam/tcp-prague > * Requirements =E2=80=94 =E2=80=8B > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21 > * Upcoming netdev talk =E2=80=94 > https://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s > * Accurate ECN > * Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft-ietf-tcpm-ac= curate-ecn-07 > * Implementation for Linux v4.17 =E2=80=94 =E2=80=8Bhttps://github.com/mi= rjak/linux-accecn > * Past netdev talk =E2=80=94 > https://www.netdevconf.org/2.2/session.html?kuhlewind-accecn-talk > * Paced Chirping * Repository =E2=80=94 =E2=80=8B > https://github.com/JoakimMisund/PacedChirping > * Upcoming netdev talk =E2=80=94 > https://netdevconf.org/0x13/session.html?talk-chirp > * L4S architecture > * Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft-ietf-tsvwg-l= 4s-arch-03 > * DualPI2 AQM > * Specs =E2=80=94 =E2=80=8B > https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08 > * Repository =E2=80=94 =E2=80=8Bhttps://github.com/L4STeam/sch_dualpi2_up= stream > * Upcoming netdev talk =E2=80=94 > https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM > * RITE Project =E2=80=94 =E2=80=8Bhttps://riteproject.eu/dctth/#code > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 --000000000000fe7ad705841fc0ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bufferbloat.net's ecn-sane = working group members have a co-ordinated response to your efforts brewing = but it's not ready yet. We have a worldwide team of linux and freebsd d= evelopers co-ordinating on landing code for our competing proposal "So= me Congestion Experienced", which we submitted to tsvwg last sunday.= =C2=A0

That draft is under continuous = revision, here:


Our Linux and FreeBSD team is also flying into prague for SCE prese= ntations at netdevconf and ietf.

= Some background to this: after the L4S/TCP Prague/and dualpi experiments ap= peared stalled out indefinitely in the IETF, and with our own frustration w= ith IETF processes, bu= fferbloat.net project members publicly formed our own working group to = look into the problems with ecn, back in august of last year.
Its charter is here:=C2=A0https://www.bufferbloat.net/pr= ojects/ecn-sane/wiki/

We were unaware, until las= t month, that the cable industry had 16 months back gone and formed its own= private working group also, and was intending to turn the tcp prague/l4s/d= ualpi IETF "experiments" into an actual DOCSIS standard.

Our SCE proposal appears to be backward compatible with th= e existing 10s-100s of millions of ecn-enabled fq_codel[1] and sch_cake[2] = deployments, and doesn't require any changes to any RFC3168 tcps (or an= y tcp-friendly congestion control) at all in order to basically work. tcp-p= rague is subtly incompatible with that, and dualpi, more so. Our proposal i= s different also, it proposes some receiver side changes in order to get th= e full benefit of SCE while remaining backward compatible with the existing= meaning of the CE codepoint.

In either case, eith= er approach essentially permanently redefines the ECT_1 codepoint incompati= bly, once and for all, and for all time. This is a final battle over the me= aning of a single bit in IP, and I expect the debates to be as difficult as= the ones described in=C2=A0https://www.ietf.org/rfc/ien/ien137.txt - I woul= d really, really, really prefer that they stay technical and not veer into = politics, but I have little hope for that.

The mem= bers of the ecn-sane working group are delighted to finally hear that runni= ng code for tcp-prague might land this ietf, and look forward to finally te= sting the whole l4s/tcpprague/dualpi architecture in conjunction with the <= a href=3D"http://flent.org" target=3D"_blank">flent.org 's and irtt= 's exhaustive suite of tests and servers in the cloud in the coming mon= ths, both against our existing, deployed, fq_codel, fq_pie, cake and pie de= rived solutions and our new SCE proposal. We hope to finally be able to wri= te new tests for flent in particular, that can show tcpprague off in the wa= ys that are important to those developing it. Flent has some basic dctcp te= sts, but nothing that can get down below a 20ms sample rate on modern hardw= are. (currently. It's easy to add tests, flent is written in python)

We also hope that more test tools and implementation= s in ns2 and ns3 show up for tcpprauge=C2=A0 and dualpi show up soon also, = from members of those projects.

Note: sunday's= dual-pi linux submission was kicked back from the linux networking develop= ers due to some technical and legal problems with linux net-next HEAD (=C2= =A0https://patchwor= k.ozlabs.org/patch/1054521/=C2=A0 ) , and I do hope that a corrected ve= rsion lands soon, so we can safely test it with current versions of OpenWrt= , etc.

Finally, running code. Will we find consens= us?

Thx!


[2] sch_cake was available= for 3 years out of tree and was mainlined last august, in linux 4.19. It i= s partially described by "Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways" "https://arxiv.org/pdf/1804.07617.= pdf=C2=A0

A second paper describing its fq_cod= el-derived "cobalt" AQM algorithm is awaiting publication in a pe= er reviewed journal. It has been part of openwrt and the related sqm-script= s for many years and is widely deployed on multiple commercial products, su= ch as those from eero and evenroute.

Cake has a do= csis specific mode which we longed for cablelabs to evaluate.


On Fri, Mar 15, 2019 at 2:= 33 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Forwarding to tcpm & iccrg - apologies if you were already on one of the lists that received this.

Olivier has been working hard on integrating the pieces of a Linux implementation of TCP Prague, and is close to having a version ported against the tip of the Linux mainline tree. This is his request for more people to get involved.


Bob


-------- Forwarded Message --------
Subject: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Date: Wed, 6 Mar 2019 10:26:05 +0000
From: Tilmans, Olivier (Nokia - BE/Antwerp) <olivier.tilmans@nokia-bell-labs.com>
To: hackathon@ietf.org <hackathon@ietf.org>, tcpprague@ietf.org <tcpprague@ietf.org>
CC: dlebrun@google.com <dlebrun@google.com>, Joakim Misund <joakim.misund@gmail.com>, Bob Briscoe <research@bobbriscoe.net>, Quentin De Coninck <quentin.deconinck@uclouvain.be>, Fran=C3=A7oi= s Michel <francois.michel@uclouvain.be>, Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Maxime Pir= aux <maxime.piraux@uclouvain.be>, Olga Albisser <olga@albisser.org>, Fabien Duch=C3=AAne <fabien.duchene@uclouvain.be>, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>


Hi all,

We'll be working on the "TCP Prague" congestion control= /L4S architecture during the IETF-104 hackaton.
This topics aims at accelerating the work that started during the IETF93 (coincidentally also in Prague), in order to get TCP Prague to an 'usable' state=E2=80=94i.e., meet the safety requiremen= ts and have supporting materials (e.g., VMs, labs) to let people experiment with it. Depending on people's interest, prototyping something similar for QUIC is another possible output.

Details and links to resources/supporting drafts are available at https://trac.ietf.org/trac/ietf/meeting= /wiki/104hackathon#tcp-prague and copied below.
Additionally, few topics will presented during netdev 0x13 the week before.

See you in Prague.

Best,
Olivier


Implementation and experimentation of TCP Prague/L4S

* Champion
* Olivier Tilmans <olivier.tilmans at nokia-bell-labs.com>
* Projects
* Prototype the "TCP Prague" congestion control on Linux * Finalize the implementation of accurate ECN (draft conformance), and port it on Linux v5.x * Build tooling around L4S to let people experiment with the technology (e.g., virtual machine, or mininet labs)
* Work towards "QUIC Prague"
* Resources
* TCP Prague
* Repository =E2=80=94 =E2=80=8Bhttps://github.com/L4STeam/tcp-p= rague
* Requirements =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/htm= l/draft-ietf-tsvwg-ecn-l4s-id-05#page-21
* Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.html?= talk-tcp-prague-l4s
* Accurate ECN
* Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft= -ietf-tcpm-accurate-ecn-07
* Implementation for Linux v4.17 =E2=80=94 =E2=80=8Bhttps://github.com/mirjak/linux-accecn
* Past netdev talk =E2=80=94 https://www.netdevconf.org/2.2/sessi= on.html?kuhlewind-accecn-talk
* Paced Chirping * Repository =E2=80=94 =E2=80=8Bhttps://github.com/JoakimMisund/PacedChirping
* Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.html?talk-chir= p
* L4S architecture
* Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft-ie= tf-tsvwg-l4s-arch-03
* DualPI2 AQM
* Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html= /draft-ietf-tsvwg-aqm-dualq-coupled-08
* Repository =E2=80=94 =E2=80=8Bhttps://github.com/L4S= Team/sch_dualpi2_upstream
* Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.html?tal= k-DUALPI2-AQM
* RITE Project =E2=80=94 =E2=80=8Bhttps://riteproject.eu/dctth/#cod= e
_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague
_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg


--

Dave T=C3=A4htCTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
--000000000000fe7ad705841fc0ee-- From nobody Fri Mar 15 03:58:12 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF5131226 for ; Fri, 15 Mar 2019 03:58: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 ub81KgzUDliz for ; Fri, 15 Mar 2019 03:58:04 -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 1F9CB131255 for ; Fri, 15 Mar 2019 03:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MmXKfx7FwEFZY3D05oU3GDg/a3+Zyz7Sz3xBcVzdaAs=; b=KPDodg23hBCrc7i190yUsWAkUI H3fTGRBilwhQlRl+w8ekWCium+gkHgXLdsL81F5F1+Y5ntZc0K5XMxXBmI9jqwuqAWWLLG9afJPoF 7fKVYSDb6i+KjGj6MA0XsJvSSwKDtqnG0pNa9CqqAZrH5RAPO3HaKoN1fw7q3kCbQw4hKtdcaYwSF HrT7+ePcPIRJ53NVNfRaSVt65budG8gaAEI4ooYsu4JkdjrsWq1MS0zxmcsIcGQPwF1vbvV9+5lgK v9dJdYb3RG1K4tL5WHAg+SRybYVW5IA+2V7LWxruErNQQc6/Sk1k6744bWILCpfVVVdilPTvfISot VP9KwijA==; Received: from [31.185.135.153] (port=47324 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h4kXI-0001c7-Fe; Fri, 15 Mar 2019 10:58:01 +0000 To: tcpm IETF list , Yuchung Cheng , Praveen Balasubramanian From: Bob Briscoe Message-ID: <0d9977c9-e774-0498-4218-afe62ebb85fd@bobbriscoe.net> Date: Fri, 15 Mar 2019 10:57:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------114F238141634174502E3168" 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] Progress with draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 10:58:11 -0000 This is a multi-part message in MIME format. --------------114F238141634174502E3168 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi folks, A few weeks ago we had two main outstanding issues with AccECN: * Unclear whether the AccECN Option is optional to implement * Lack of consensus on how to address generic receive offload hardware Last Monday, we posted a new revision of the draft: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-08 ==AccECN TCP Option: Optional to implement== Hopefully it is now very clear that the AccECN Option is optional to implement. Given middleboxes could block packets with it on, the sender of the option had to be able to not send it, and the potential receiver of the option had to be prepared not to receive it anyway. So there was no point trying to make it mandatory to implement. @Praveen and possibly others have been uncertain of what the draft required, so pls check whether you are now happy that the text allows you to not do what you don't want to do. ==GRO Hardware== Inherently, ECN and its feedback make headers toggle, which ejects the currently cached header from current GRO hardware. @Yuchung likes DCTCP-style feedback 'cos it doesn't change if there's a run of unchanged markings and you often get unchanged runs with the step marking of DCTCP. However, some people would like to move from step to ramp-marking, which would allow DCTCP to be more responsive. There is no style of feedback (neither DCTCP, AccECN or anything) that hardware is currently optimized for when ECN is toggling randomly (as it is designed to). So ultimately we need NIC hardware to be optimized for the inherent variability of ECN. Therefore, given DCTCP's inherent unreliable delivery, we've decided to forge ahead with AccECN as it is. Then NIC hardware developers will know which scheme it is worth optimizing for. That's the role of standards (even experimental ones). ==Forward Compatibility== I ran through a full check of all the fields to check we'd specified what to do for every value that might be used in the future. We'd caught nearly all of them, but added a new section to capture these: 3.1.2 Forward Compatibility ==Implementation== Mirja has ported her Linux implementation to a later Linux kernel and Olivier Tilmans is porting that to v5.0. I just forwarded the invitation to work on TCP Prague the hackathon on the Sat before the IETF in Prague. The idea is particularly to update AccECN to the lastest draft revision. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------114F238141634174502E3168 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi folks,

A few weeks ago we had two main outstanding issues with AccECN:
* Unclear whether the AccECN Option is optional to implement
* Lack of consensus on how to address generic receive offload hardware

Last Monday, we posted a new revision of the draft:
https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-08

==AccECN TCP Option: Optional to implement==
Hopefully it is now very clear that the AccECN Option is optional to implement. Given middleboxes could block packets with it on, the sender of the option had to be able to not send it, and the potential receiver of the option had to be prepared not to receive it anyway. So there was no point trying to make it mandatory to implement.

@Praveen and possibly others have been uncertain of what the draft required, so pls check whether you are now happy that the text allows you to not do what you don't want to do.

==GRO Hardware==
Inherently, ECN and its feedback make headers toggle, which ejects the currently cached header from current GRO hardware.
@Yuchung likes DCTCP-style feedback 'cos it doesn't change if there's a run of unchanged markings and you often get unchanged runs with the step marking of DCTCP. However, some people would like to move from step to ramp-marking, which would allow DCTCP to be more responsive. There is no style of feedback (neither DCTCP, AccECN or anything) that hardware is currently optimized for when ECN is toggling randomly (as it is designed to). So ultimately we need NIC hardware to be optimized for the inherent variability of ECN.

Therefore, given DCTCP's inherent unreliable delivery, we've decided to forge ahead with AccECN as it is. Then NIC hardware developers will know which scheme it is worth optimizing for. That's the role of standards (even experimental ones).

==Forward Compatibility==

I ran through a full check of all the fields to check we'd specified what to do for every value that might be used in the future. We'd caught nearly all of them, but added a new section to capture these:
3.1.2 Forward Compatibility

==Implementation==
Mirja has ported her Linux implementation to a later Linux kernel and Olivier Tilmans is porting that to v5.0.
I just forwarded the invitation to work on TCP Prague the hackathon on the Sat before the IETF in Prague. The idea is particularly to update AccECN to the lastest draft revision.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------114F238141634174502E3168-- From nobody Fri Mar 15 04:25:51 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61571131229; Fri, 15 Mar 2019 04:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 dGVrEZ9lwzmm; Fri, 15 Mar 2019 04:25:48 -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 75DE8131227; Fri, 15 Mar 2019 04:25:48 -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=t+aD3FY65sMpYGQBgxI1xVDK3OC4E44K6+6Q4KdcxGc=; b=mdvLndAJa43OZfboW7vN9Wc1ZP bvfQ51eXZf1zLPwXhkjiZFBfBhbOpPMW8o7r0xeHFSASrU8wKyGofCQN7+GNtbgRI6pO/35OJHs0L weIj4adi8rLB2oT/891nB+fhX2QQlIPXauh59Wmi3uKrg/gafyoppV68t9/IArQ0gcqFsHydaZZ3t Pz8yiVaJUJ/nrHw/gNklc2eekvf5P0oSitXQ231wCdFuXhPXMkJVG07F7J3SBTop8P0jBN8dhOLFG 0R5P4ZWhQgJkwgjj/PcUBsj3I+kBVxLlGFoQJeGnrZUUKnLZC9StuMAqG56MmWXA4bKq28Na4NtF+ i5/xyAOQ==; Received: from [31.185.135.153] (port=47442 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h4kyA-0006yU-Is; Fri, 15 Mar 2019 11:25:46 +0000 To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" , Mirja Kuehlewind , "Scheffenegger, Richard" , marcelo bagnulo braun References: <6EC6417807D9754DA64F3087E2E2E03E2D259B52@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <4b40f2e4-e29d-7848-a10d-5a52e71824bd@bobbriscoe.net> Date: Fri, 15 Mar 2019 11:25:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D259B52@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] DRAFT agenda for Prague X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 11:25:50 -0000 Michael, Could we have a brief slot on AccECN in Prague: draft-ietf-tcpm-accurate-ecn-08 Duration 10 mins (incl. discussion) On ECN++, I could include 1 slide in the above, cos we've submitted a 1-line bugfix to the Linux mainline that should be widely back-ported - to solve the deployment problem with the installed base of Linux servers that I talked about in Singapore. So no changes to the spec, but that should fix the deployment incentive problem that the bug caused. [Mirja, Richard and Michael - sorry for not sending this until today - it appears I didn't click send.] Regards Bob On 13/03/2019 09:02, Scharf, Michael wrote: > Hi all, > > A first draft of the TCPM agenda for IETF 104 has been posted on https://datatracker.ietf.org/meeting/104/materials/ and is also copied below. > > Please let the chairs know if I missed something, or if there are late slot requests. > > Happy agenda bashing! > > Michael > > > ************************************************* > TCPM meeting, IETF 104, Prague > Monday, March 25, 2019, 13:50-15:50 (Afternoon session I) > > WG Status updates > ------------------------------------------------- > Time: 15 min > > Working Group Items > ------------------------------------------------- > > * 0-RTT TCP Convert Protocol > draft-ietf-tcpm-converters > Speaker: Olivier Bonaventure > Time: 15 min > > Other Items > ------------------------------------------------- > > * Transmission Control Protocol (TCP) YANG Model > draft-scharf-tcpm-yang-tcp > Speaker: Michael Scharf > Time: 15 min > > * DNS Transport over TCP - Operational Requirements > draft-ietf-dnsop-dns-tcp-requirements > Speaker: Duane Wessels > Time: 10 min > > * TCP advancements in Windows > Speaker: Praveen Balasubramanian (on-site or remote) > Time: 15 min > > * QUIC Loss Detection and Congestion Control > draft-ietf-quic-recovery > Speaker: Jana Iyengar > Time: 30 min > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Mar 15 14:34:49 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51CE130EBB for ; Fri, 15 Mar 2019 14:34:41 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwNgr_9Bq3fG for ; Fri, 15 Mar 2019 14:34:38 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 5CDEF130E00 for ; Fri, 15 Mar 2019 14:34:38 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id k14so6075635qtb.0 for ; Fri, 15 Mar 2019 14:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=E7rjdmu+HWK/ZrphIP0JCmM2LeQiaaKYEtGxWS1C4tg=; b=XOJwFjwjpNzLNc5k4pIwdp82gWmaQCA8PT+78trmwjA1dmB5HohtxKl8jZ4writTzU kzd8MTpeN6EnwB+1hY3SZp0yfOhJjecswNqKemhFWDdP3r/iDQdGnMax142vwneyrgkN BKS901fnFNBrBjS/NQ2S7wjSLFLigy/9U5VZXb217/GpnIazLPfxg89WE0DN5j+y/tn9 FJMo2YqULM2+7KtWz6oDzdvumJ8lancQWrEr9Cu5FlHmwAZUZ1G6YSHqgU5SRlBJtPr4 P5vksVxLAVUtU0D/X06wHj871gcW9OjAvJUb30c1mBW2dVqVmFsGY3lRNFru+FNd9Xbi Uwug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=E7rjdmu+HWK/ZrphIP0JCmM2LeQiaaKYEtGxWS1C4tg=; b=M8J5aGRd/3c/seoe7b1tZ/g4AUccpO9Mle4tSFRRu+QxEIBU+VCa+9vlY4Xrm71uoE ue0084cO8FN7b4y20IkyhTCmTDV9MUkHXGanfWcNtQeYa13nOib+EI6l2uQ/G37/lG9w WUNtaiYbK7crNwC46ltAgJyXqHdjO5X88/9ew2g15NWuR6aq6the4Yl5/hJVD97xBSRr hbl20BTYidOyzw1Lo4IMX9y5dCORxT6jqFVYa5BsEoZurQhtkWu4kV+5IWHINB13G19i qTfOtLCR6tlrfA0YsAF+ybIV2Hh8gB4FSst7BmdZ2+VFKdDjURzooyUW2uTp07+v1jJh G0qw== X-Gm-Message-State: APjAAAVFZPvT7KDy3VsbH5NkEgSeHv5Pa4o08664Tt7Wj6T35nexs9+f 3a6x6PGkXxOkd9yYg/lF2+465A== X-Google-Smtp-Source: APXvYqwQA2f5r8jM3zRX043udIPYkuDsNs1qxirhXRZrQMuUinuJ0sELqdBnVtKMuTcQ09F1WaeWIA== X-Received: by 2002:ac8:2ca1:: with SMTP id 30mr663931qtw.245.1552685677521; Fri, 15 Mar 2019 14:34:37 -0700 (PDT) Received: from [192.168.1.14] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id k42sm3275722qtk.58.2019.03.15.14.34.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 14:34:36 -0700 (PDT) To: Dave Taht , Bob Briscoe Cc: tcpm IETF list , ecn-sane@lists.bufferbloat.net, iccrg IRTF list , bloat References: From: Wesley Eddy Message-ID: Date: Fri, 15 Mar 2019 17:34:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 21:34:42 -0000 Hi, Dave, strangely it looks like nobody has been copying TSVWG on this thread, even though that is where the L4S work is happening in the IETF!  :) I just wanted to respond to one part of your message since I am currently acting as document shepherd for the L4S drafts in TSVWG, and it seems like maybe you don't know where to find all of the IETF materials in order to participate (based on the "stalled out indefinitely" comment below).  So in case it's helpful here are some pointers to where things are kept. The 3 base L4S documents were adopted in the TSVWG WG, and have been regularly updated.  You can find the charter and milestone dates (currently June 2019) quite easily on the WG datatracker page: https://datatracker.ietf.org/group/tsvwg/about/ and of course the "Documents" tab there takes you to the copies of all the documents. There have been updates on L4S and presentations/discussions at the IETF meetings (with minutes and charts posted to the proceedings), as well as L4S draft reviews and comment threads on the TSVWG list whose archives are under "List archive".  You can find meeting minutes and slide decks also readily linked from that WG page: https://datatracker.ietf.org/group/tsvwg/meetings/ There are source code repositories, papers, videos, etc. that the proponents have also made very easy to find, e.g. https://riteproject.eu/dctth/#code (and as linked in meeting materials). Since we (TSVWG chairs) are looking for inputs towards WGLC readiness to proceed on these, hopefully this information is helpful for you. On 3/15/2019 6:46 AM, Dave Taht wrote: > ... > > Some background to this: after the L4S/TCP Prague/and dualpi experiments appeared stalled out indefinitely in the IETF, and with our own frustration with IETF processes, bufferbloat.net project members publicly formed our own working group to look into the problems with ecn, back in august of last year. From nobody Sat Mar 16 04:38:31 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3848B1277C9 for ; Sat, 16 Mar 2019 04:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YmlfJwY-k_QA for ; Sat, 16 Mar 2019 04:38:25 -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 49396127887 for ; Sat, 16 Mar 2019 04:38:25 -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:Cc:To:From:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LEY/8gzvA2t4zNrgueyJQIXSzazIu0s2lGrtdaANW+w=; b=BU/WArjBbgrFHF28K2BCeaKRO 3kR980jQEgQOi3wFvh7S16Z2pIYsO/EW4rMpcvxE9AFO/HwRSClqxsamBK10FD12ac2VKhuKlvupF gF8Pzo/jBp35H+da9FrR+h0VwXgFCuJNbUiLFbC6BJ0WDp29NLWi73ApkA1ylQo/4m3GBbmLNc3Zn dfmX9t71DCXudNmDF6pNUX2rQvp9ri8KFSt8QOFApI/ghhod2aWwb+L31TDJtztnIExaly8sYkvGk xNuxzpkxk5RSbZ0AxtBCONAkI2uhA/dBfPo3lRIajBNg3Xc+7uV7hwMn//dgKGXL5d8JRubl6U6JD +bEhEwc8g==; Received: from [31.185.135.153] (port=51446 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h57du-0001HG-8V; Sat, 16 Mar 2019 11:38:22 +0000 From: Bob Briscoe To: tcpm IETF list References: Message-ID: Date: Sat, 16 Mar 2019 11:38:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------91DB4DEA282342225DD913A5" 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] Does this fix sufficiently de-ossify overstrict ECN negotiation by Linux TCP servers? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 11:38:29 -0000 This is a multi-part message in MIME format. --------------91DB4DEA282342225DD913A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks, After offline discussion with the Linux maintainers, we have agreed on option #2, which is to make overstrict ECN test more specific to RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field and the first six TCP flags in the main header are 0b000011. This will be a simple 1-line patch that maximizes the likelihood that it will be back-ported as far back as possible, hopefully back to the introduction of the over-strict test in May 2012. This should fix a large proportion of the installed base of Linux servers reasonably quickly. ==Logging== Separately we will submit a patch to add logging of each event that disables ECN, but only for future kernel versions, not for back-porting. However, there is resistance to any logging, so this might not be accepted. The proposal is * at default logging level, increment an SNMP count when ECN disabled for a connection due to a protocol violation * at increased logging level, on each event also write rate-limited kernel messages that record the client IP. Then, if a sysadmin wants to, they can get any network mangling fixed. Bob On 20/01/2019 23:31, Bob Briscoe wrote: > TCPM folks, > > RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. > However, if a client sends an ECN-capable SYN, existing Linux servers > disable ECN for the rest of the connection. > > To fix as many existing Linux servers as possible, as soon as > possible, I would recommend short-term solution #2 (see 'Three Fixes' > below). An alternative would be short-term solution #3. > > Anyone got a better fix? Anyone disagree with recommending #2? If not, > pls confirm your agreement. > > > Summary of Pros and Cons > > #2 pro: No longer ossifies non-ECN SYN > #2 pro: If a path does "unbleach" IP-ECN, protects the connection by > disabling ECN > #2 con: A residual degree of ossification remains > > #3 pro: No longer ossifies non-ECN SYN > #3 pro: No ossification at all > #3 con: If a path does "unbleach" IP-ECN, connection still attempts to > use ECN even though the path is mangling the ECN field. > > #1 is the full solution, but it should proceed in parallel as a > solution for the future, not to fix the past. > > > Background > > To negotiate ECN for a connection the client sets flag bits 8-9 in the > TCP header to 11 [RFC3168 Section 6.1.1] > . For your > convenience, I've included a picture of the TCP header flags at the end. > > In 2012 an additional test was patched into Linux servers. It disables > ECN for the connection unless the IP-ECN field of the SYN is also zero > (I'll call this the "overstrict ECN test"). > > This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT > set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN > test ossifies this requirement into TCP. > > The Linux patch was intended to protect a connection against the > network mangling the IP-ECN field to a non-zero value. Unfortunately, > it also disables ECN completely if a client tries to set ECT in the > IP-ECN field of the SYN. > > RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction > with the ECN++ experiment. But few developers are going to set ECT on > a SYN if it causes about 84% of servers to completely disable ECN (see > Section 4.2.2. of the ECN++ draft > > for further details and the source of these numbers). > > > Three Fixes > > I can think of three ways to fix existing Linux servers: > > 1. Deploy Accurate ECN > on > existing Linux servers. > * AccECN inherently replaces the overstrict ECN test with a pair > of proper two-ended tests for network mangling, in which each > end feeds back the arriving IP ECN field in its TCP feedback. > In contrast, the overstrict ECN test is one-ended, with the > server only assuming what the client set. > * Altho AccECN will solve the problem, it should not be relied > on to fix the last six years of Linux server deployment. > AccECN is a non-trivial update so it is unlikely to get > back-ported and auto-deployed to most existing Linux servers > any time soon. > 2. Make the overstrict ECN test more specific to RFC3168, and add > logging. > * Currently, the only proposal for allowing ECT on a SYN > requires the client to also request Accurate ECN feedback, > which requires TCP header bits 7-9 to be 111. > * Therefore, the overstrict ECN test in a Linux server could be > altered to solely apply if bits 7-9 == 011 (rather than just > testing if bits 8-9 == 11). > * However, I am concerned that this ossifies around the solution > based on ECN++ and AccECN. What if ECN++ needs to be > superseded by some future protocol that allows ECT on a SYN > when some other field is different (e.g. one of TCP's three > remaining reserved flags, or a new TCP option)? > * Unfortunately, we cannot test for the absence of a > yet-to-be-invented TCP option. Nonetheless, I suggest *the > overstrict ECN test in a Linux server should at least be > altered to solely apply if TCP header bits 4-9 == 000011*. > * I suggest Linux also *logs whenever it disables ECN due to > this test*, so that broken paths can be identified and fixed. > * An extremely simple patch like this would be much more likely > than #1 (AccECN) to be back-ported and deployed to most > existing servers via regular Linux auto-updates. > 3. As #2, but do not disable ECN when the test fails, just log those > paths suspected of mangling ECN. > * Our most recent measurements of millions of Internet paths > found no occurrences where zero IP-ECN on a SYN was changed to > non-zero ("unbleaching"). So we could just remove the test. > * However, no occurrences found does not mean none exist. Altho > we tested millions of paths, we only tested from a few dozen > vantage points, albeit we did test both mobile and fixed > networks (see Section 4.2.2. of the ECN++ draft > > for summary of tests). > * If the number of problematic paths is small, it would still > make sense to run the ECN test as proposed under item #2, but > not disable ECN if it fails. Instead, just log any negative > results, so the broken network elements can be identified and > fixed. > > Cheers > > > Bob > > PS. For convenience, here's the TCP header flags (assuming the > experimental AccECN protocol is approved as RFC): > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | | | A | C | E | U | A | P | R | S | F | > | Header Length | Reserved | E | W | C | R | C | S | S | Y | I | > | | | | R | E | G | K | H | T | N | N | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------91DB4DEA282342225DD913A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Folks,

After offline discussion with the Linux maintainers, we have agreed on option #2, which is to make overstrict ECN test more specific to RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field and the first six TCP flags in the main header are 0b000011.

This will be a simple 1-line patch that maximizes the likelihood that it will be back-ported as far back as possible, hopefully back to the introduction of the over-strict test in May 2012. This should fix a large proportion of the installed base of Linux servers reasonably quickly.

==Logging==
Separately we will submit a patch to add logging of each event that disables ECN, but only for future kernel versions, not for back-porting. However, there is resistance to any logging, so this might not be accepted. The proposal is
* at default logging level, increment an SNMP count when ECN disabled for a connection due to a protocol violation
* at increased logging level, on each event also write rate-limited kernel messages that record the client IP.

Then, if a sysadmin wants to, they can get any network mangling fixed.


Bob

On 20/01/2019 23:31, Bob Briscoe wrote:
TCPM folks,

RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. However, if a client sends an ECN-capable SYN, existing Linux servers disable ECN for the rest of the connection.

To fix as many existing Linux servers as possible, as soon as possible, I would recommend short-term solution #2 (see 'Three Fixes' below). An alternative would be short-term solution #3.

Anyone got a better fix? Anyone disagree with recommending #2? If not, pls confirm your agreement.

Summary of Pros and Cons

#2 pro: No longer ossifies non-ECN SYN
#2 pro: If a path does "unbleach" IP-ECN, protects the connection by disabling ECN
#2 con: A residual degree of ossification remains

#3 pro: No longer ossifies non-ECN SYN
#3 pro: No ossification at all
#3 con: If a path does "unbleach" IP-ECN, connection still attempts to use ECN even though the path is mangling the ECN field.

#1 is the full solution, but it should proceed in parallel as a solution for the future, not to fix the past.

Background

To negotiate ECN for a connection the client sets flag bits 8-9 in the TCP header to 11 [RFC3168 Section 6.1.1]. For your convenience, I've included a picture of the TCP header flags at the end.

In 2012 an additional test was patched into Linux servers. It disables ECN for the connection unless the IP-ECN field of the SYN is also zero (I'll call this the "overstrict ECN test").

This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossifies this requirement into TCP.

The Linux patch was intended to protect a connection against the network mangling the IP-ECN field to a non-zero value. Unfortunately, it also disables ECN completely if a client tries to set ECT in the IP-ECN field of the SYN.

RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction with the ECN++ experiment. But few developers are going to set ECT on a SYN if it causes about 84% of servers to completely disable ECN (see Section 4.2.2. of the ECN++ draft for further details and the source of these numbers).

Three Fixes

I can think of three ways to fix existing Linux servers:
  1. Deploy Accurate ECN on existing Linux servers.
    • AccECN inherently replaces the overstrict ECN test with a pair of proper two-ended tests for network mangling, in which each end feeds back the arriving IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is one-ended, with the server only assuming what the client set.
    • Altho AccECN will solve the problem, it should not be relied on to fix the last six years of Linux server deployment. AccECN is a non-trivial update so it is unlikely to get back-ported and auto-deployed to most existing Linux servers any time soon.
  2. Make the overstrict ECN test more specific to RFC3168, and add logging.
    • Currently, the only proposal for allowing ECT on a SYN requires the client to also request Accurate ECN feedback, which requires TCP header bits 7-9 to be 111.
    • Therefore, the overstrict ECN test in a Linux server could be altered to solely apply if bits 7-9 == 011 (rather than just testing if bits 8-9 == 11).
    • However, I am concerned that this ossifies around the solution based on ECN++ and AccECN. What if ECN++ needs to be superseded by some future protocol that allows ECT on a SYN when some other field is different (e.g. one of TCP's three remaining reserved flags, or a new TCP option)?
    • Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP option. Nonetheless, I suggest the overstrict ECN test in a Linux server should at least be altered to solely apply if TCP header bits 4-9 == 000011.
    • I suggest Linux also logs whenever it disables ECN due to this test, so that broken paths can be identified and fixed.
    • An extremely simple patch like this would be much more likely than #1 (AccECN) to be back-ported and deployed to most existing servers via regular Linux auto-updates.
  3. As #2, but do not disable ECN when the test fails, just log those paths suspected of mangling ECN.
    • Our most recent measurements of millions of Internet paths found no occurrences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). So we could just remove the test.
    • However, no occurrences found does not mean none exist. Altho we tested millions of paths, we only tested from a few dozen vantage points, albeit we did test both mobile and fixed networks (see Section 4.2.2. of the ECN++ draft for summary of tests).
    • If the number of problematic paths is small, it would still make sense to run the ECN test as proposed under item #2, but not disable ECN if it fails. Instead, just log any negative results, so the broken network elements can be identified and fixed.
Cheers


Bob

PS. For convenience, here's the TCP header flags (assuming the experimental AccECN protocol is approved as RFC):
       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |           | A | C | E | U | A | P | R | S | F |
     | Header Length | Reserved  | E | W | C | R | C | S | S | Y | I |
     |               |           |   | R | E | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------91DB4DEA282342225DD913A5-- From nobody Sat Mar 16 07:33:00 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8851A12D4ED for ; Sat, 16 Mar 2019 07:32:59 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8_lVxRt6B4z for ; Sat, 16 Mar 2019 07:32:55 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 E6225128CF2 for ; Sat, 16 Mar 2019 07:32:54 -0700 (PDT) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x2GEW3PJ003394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 16 Mar 2019 15:32:03 +0100 Received: from [10.226.140.207] (80-254-69-15.dynamic.monzoon.net [80.254.69.15]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x2GEW3aR125667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 16 Mar 2019 15:32:03 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-2AE5B5E6-D242-462D-9883-FFA32FE4DCD7 Mime-Version: 1.0 (1.0) From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Sat, 16 Mar 2019 15:32:02 +0100 Cc: tcpm IETF list Content-Transfer-Encoding: 7bit Message-Id: References: To: Bob Briscoe X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [tcpm] Does this fix sufficiently de-ossify overstrict ECN negotiation by Linux TCP servers? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 14:33:00 -0000 --Apple-Mail-2AE5B5E6-D242-462D-9883-FFA32FE4DCD7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, This seems eminently reasonable. I=E2=80=99m curious, would there be equival= ent pushback on _only_ adding the SNMP counter? One could always use observa= tion to debug once the counter starts going up... Cheers, Brian Sent from my iPhone > On 16 Mar 2019, at 12:38, Bob Briscoe wrote: >=20 > Folks, >=20 > After offline discussion with the Linux maintainers, we have agreed on opt= ion #2, which is to make overstrict ECN test more specific to RFC3168 by onl= y disabling ECN if a SYN has a non-zero IP-ECN field and the first six TCP f= lags in the main header are 0b000011. >=20 > This will be a simple 1-line patch that maximizes the likelihood that it w= ill be back-ported as far back as possible, hopefully back to the introducti= on of the over-strict test in May 2012. This should fix a large proportion o= f the installed base of Linux servers reasonably quickly. >=20 > =3D=3DLogging=3D=3D > Separately we will submit a patch to add logging of each event that disabl= es ECN, but only for future kernel versions, not for back-porting. However, t= here is resistance to any logging, so this might not be accepted. The propos= al is=20 > * at default logging level, increment an SNMP count when ECN disabled for a= connection due to a protocol violation > * at increased logging level, on each event also write rate-limited kernel= messages that record the client IP. >=20 > Then, if a sysadmin wants to, they can get any network mangling fixed. >=20 >=20 > Bob >=20 >> On 20/01/2019 23:31, Bob Briscoe wrote: >> TCPM folks, >>=20 >> RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. Howe= ver, if a client sends an ECN-capable SYN, existing Linux servers disable EC= N for the rest of the connection. >>=20 >> To fix as many existing Linux servers as possible, as soon as possible, I= would recommend short-term solution #2 (see 'Three Fixes' below). An altern= ative would be short-term solution #3. >>=20 >> Anyone got a better fix? Anyone disagree with recommending #2? If not, pl= s confirm your agreement. >>=20 >> Summary of Pros and Cons >>=20 >> #2 pro: No longer ossifies non-ECN SYN >> #2 pro: If a path does "unbleach" IP-ECN, protects the connection by disa= bling ECN >> #2 con: A residual degree of ossification remains >>=20 >> #3 pro: No longer ossifies non-ECN SYN >> #3 pro: No ossification at all >> #3 con: If a path does "unbleach" IP-ECN, connection still attempts to us= e ECN even though the path is mangling the ECN field. >>=20 >> #1 is the full solution, but it should proceed in parallel as a solution f= or the future, not to fix the past. >> Background >>=20 >> To negotiate ECN for a connection the client sets flag bits 8-9 in the TC= P header to 11 [RFC3168 Section 6.1.1]. For your convenience, I've included a= picture of the TCP header flags at the end. >>=20 >> In 2012 an additional test was patched into Linux servers. It disables EC= N for the connection unless the IP-ECN field of the SYN is also zero (I'll c= all this the "overstrict ECN test"). >>=20 >> This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set= ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossi= fies this requirement into TCP.=20 >>=20 >> The Linux patch was intended to protect a connection against the network m= angling the IP-ECN field to a non-zero value. Unfortunately, it also disable= s ECN completely if a client tries to set ECT in the IP-ECN field of the SYN= . >>=20 >> RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction wit= h the ECN++ experiment. But few developers are going to set ECT on a SYN if i= t causes about 84% of servers to completely disable ECN (see Section 4.2.2. o= f the ECN++ draft for further details and the source of these numbers). >> Three Fixes >>=20 >> I can think of three ways to fix existing Linux servers: >> Deploy Accurate ECN on existing Linux servers. >> AccECN inherently replaces the overstrict ECN test with a pair of proper t= wo-ended tests for network mangling, in which each end feeds back the arrivi= ng IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is= one-ended, with the server only assuming what the client set. >> Altho AccECN will solve the problem, it should not be relied on to fix th= e last six years of Linux server deployment. AccECN is a non-trivial update s= o it is unlikely to get back-ported and auto-deployed to most existing Linux= servers any time soon.=20 >> Make the overstrict ECN test more specific to RFC3168, and add logging. >> Currently, the only proposal for allowing ECT on a SYN requires the clien= t to also request Accurate ECN feedback, which requires TCP header bits 7-9 t= o be 111. >> Therefore, the overstrict ECN test in a Linux server could be altered to s= olely apply if bits 7-9 =3D=3D 011 (rather than just testing if bits 8-9 =3D= =3D 11). >> However, I am concerned that this ossifies around the solution based on E= CN++ and AccECN. What if ECN++ needs to be superseded by some future protoco= l that allows ECT on a SYN when some other field is different (e.g. one of T= CP's three remaining reserved flags, or a new TCP option)?=20 >> Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP= option. Nonetheless, I suggest the overstrict ECN test in a Linux server sh= ould at least be altered to solely apply if TCP header bits 4-9 =3D=3D 00001= 1.=20 >> I suggest Linux also logs whenever it disables ECN due to this test, so t= hat broken paths can be identified and fixed. >> An extremely simple patch like this would be much more likely than #1 (Ac= cECN) to be back-ported and deployed to most existing servers via regular Li= nux auto-updates. >> As #2, but do not disable ECN when the test fails, just log those paths s= uspected of mangling ECN. >> Our most recent measurements of millions of Internet paths found no occur= rences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). S= o we could just remove the test. >> However, no occurrences found does not mean none exist. Altho we tested m= illions of paths, we only tested from a few dozen vantage points, albeit we d= id test both mobile and fixed networks (see Section 4.2.2. of the ECN++ draf= t for summary of tests). >> If the number of problematic paths is small, it would still make sense to= run the ECN test as proposed under item #2, but not disable ECN if it fails= . Instead, just log any negative results, so the broken network elements can= be identified and fixed. >> Cheers >>=20 >>=20 >> Bob >>=20 >> PS. For convenience, here's the TCP header flags (assuming the experiment= al AccECN protocol is approved as RFC): >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | | | A | C | E | U | A | P | R | S | F | >> | Header Length | Reserved | E | W | C | R | C | S | S | Y | I | >> | | | | R | E | G | K | H | T | N | N | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-2AE5B5E6-D242-462D-9883-FFA32FE4DCD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob,

This seems emine= ntly reasonable. I=E2=80=99m curious, would there be equivalent pushback on _= only_ adding the SNMP counter? One could always use observation to debug onc= e the counter starts going up...

Cheers,
=
Brian

Sent f= rom my iPhone

On 16 Mar 2019, at 12:38, Bob Brisco= e <ietf@bobbriscoe.net> wro= te:

=20 =20 =20 Folks,

After offline discussion with the Linux maintainers, we have agreed on option #2, which is to make overstrict ECN test more specific to RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field and the first six TCP flags in the main header are 0b000011.

This will be a simple 1-line patch that maximizes the likelihood that it will be back-ported as far back as possible, hopefully back to the introduction of the over-strict test in May 2012. This should fix a large proportion of the installed base of Linux servers reasonably quickly.

=3D=3DLogging=3D=3D
Separately we will submit a patch to add logging of each event that disables ECN, but only for future kernel versions, not for back-porting. However, there is resistance to any logging, so this might not be accepted. The proposal is
* at default logging level, increment an SNMP count when ECN disabled for a connection due to a protocol violation
* at increased logging level, on each event also write rate-limited kernel messages that record the client IP.

Then, if a sysadmin wants to, they can get any network mangling fixed.


Bob

On 20/01/2019 23:31, Bob Briscoe wrote:
TCPM folks,

RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. However, if a client sends an ECN-capable SYN, existing Linux servers disable ECN for the rest of the connection.

To fix as many existing Linux servers as possible, as soon as possible, I would recommend short-term solution #2 (see 'Three Fixes' below). An alternative would be short-term solution #3.

Anyone got a better fix? Anyone disagree with recommending #2? If not, pls confirm your agreement.

Summary of Pros and Cons

#2 pro: No longer ossifies non-ECN SYN
#2 pro: If a path does "unbleach" IP-ECN, protects the connection by disabling ECN
#2 con: A residual degree of ossification remains

#3 pro: No longer ossifies non-ECN SYN
#3 pro: No ossification at all
#3 con: If a path does "unbleach" IP-ECN, connection still attempts to use ECN even though the path is mangling the ECN field.

#1 is the full solution, but it should proceed in parallel as a solution for the future, not to fix the past.

Background

To negotiate ECN for a connection the client sets flag bits 8-9 in the TCP header to 11 [RFC3168 Section 6.1.1]. For your convenience, I've included a picture of the TCP header flags at the end.

In 2012 an additional test was patched into Linux servers. It disables ECN for the connection unless the IP-ECN field of the SYN is also zero (I'll call this the "overstrict ECN test").

This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossifies this requirement into TCP.

The Linux patch was intended to protect a connection against the network mangling the IP-ECN field to a non-zero value. Unfortunately, it also disables ECN completely if a client tries to set ECT in the IP-ECN field of the SYN.

RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction with the ECN++ experiment. But few developers are going to set ECT on a SYN if it causes about 84% of servers to completely disable ECN (see Se= ction 4.2.2. of the ECN++ draft for further details and the source of these numbers).

Three Fixes

I can think of three ways to fix existing Linux servers:
  1. Deploy Accurate ECN on existing Linux servers.
    • AccECN inherently replaces the overstrict ECN test with a pair of proper two-ended tests for network mangling, in which each end feeds back the arriving IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is one-ended, with the server only assuming what the client set.
    • Altho AccECN will solve the problem, it should not be relied on to fix the last six years of Linux server deployment. AccECN is a non-trivial update so it is unlikely to get back-ported and auto-deployed to most existing Linux servers any time soon.
  2. Make the overstrict ECN test more specific to RFC3168, and add logging.
    • Currently, the only proposal for allowing ECT on a SYN requires the client to also request Accurate ECN feedback, which requires TCP header bits 7-9 to be 111.
    • Therefore, the overstrict ECN test in a Linux server could be altered to solely apply if bits 7-9 =3D=3D 011 (rather than just testing if bits 8-9 =3D=3D 11).
    • However, I am concerned that this ossifies around the solution based on ECN++ and AccECN. What if ECN++ needs to be superseded by some future protocol that allows ECT on a SYN when some other field is different (e.g. one of TCP's three remaining reserved flags, or a new TCP option)?
    • Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP option. Nonetheless, I suggest the overstrict ECN test in a Linux server should at least be altered to solely apply if TCP header bits 4-9 =3D=3D 000011.
    • I suggest Linux also logs whenever it disables ECN due to this test, so that broken paths can be identified and fixed.
    • An extremely simple patch like this would be much more likely than #1 (AccECN) to be back-ported and deployed to most existing servers via regular Linux auto-updates.
  3. As #2, but do not disable ECN when the test fails, just log those paths suspected of mangling ECN.
    • Our most recent measurements of millions of Internet paths found no occurrences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). So we could just remove the test.
    • However, no occurrences found does not mean none exist. Altho we tested millions of paths, we only tested from a few dozen vantage points, albeit we did test both mobile and fixed networks (see Sect= ion 4.2.2. of the ECN++ draft for summary of tests).
    • If the number of problematic paths is small, it would still make sense to run the ECN test as proposed under item #2, but not disable ECN if it fails. Instead, just log any negative results, so the broken network elements can be identified and fixed.
Cheers


Bob

PS. For convenience, here's the TCP header flags (assuming the experimental AccECN protocol is approved as RFC):
       0   1   2   3   4   5   6   7   8   9  1=
0  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |           | A | C | E | U | A | P | R | S | F |
     | Header Length | Reserved  | E | W | C | R | C | S | S | Y | I |
     |               |           |   | R | E | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+



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

--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
=20
________= _______________________________________
tcpm mailing list
tcpm@ietf.org
<= span>https://www.ietf= .org/mailman/listinfo/tcpm
= --Apple-Mail-2AE5B5E6-D242-462D-9883-FFA32FE4DCD7-- From nobody Sat Mar 16 19:05:35 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90F1288BD for ; Sat, 16 Mar 2019 19:05:34 -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 eHvygOT3eCSZ for ; Sat, 16 Mar 2019 19:05:31 -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 D620012796A for ; Sat, 16 Mar 2019 19:05:30 -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=7F2w4NlFAbM9sPCkDX6tjs+pmc+/VroOvGjSndebkXc=; b=FqliBlh7D5LyQy/0saLNoH21m OASR0GAHBbmuaToPqNwj2zaCh5bWs9hwXoZId7uUgUFoSj5ahLriiBPr9OUNy08O9Ve81hZfYPNo2 KmLrRNjKCerTLVpXG1eotOK579/NQ5mTxwpbG4f5BhCkkBxuEkpyvqRzP/rylMuxM/pIOtQf5oZMa GjHblEI9T3XpZwlHOc7FNoA0zpf+tmSlZ0ErODPn/VFgC947K+8LQQAMA0LpsHnXtBvCSRxT9rHkg Bq3/UBJWlutG4fHD2epKqVjVO/IhVhgPK/ixyzRcBuA2oQN1Z9B+rTsZQtIfLyRfVdOrhlldAPCMo QH6oYJioA==; Received: from [31.185.135.153] (port=35588 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h5LB1-0002SV-Ru; Sun, 17 Mar 2019 02:05:28 +0000 To: "Brian Trammell (IETF)" Cc: tcpm IETF list References: From: Bob Briscoe Message-ID: <6fa5db15-fc49-a662-6a33-ac11c97a30a6@bobbriscoe.net> Date: Sun, 17 Mar 2019 02:05:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F8AAB23B2497378D1A7E64E3" 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] Does this fix sufficiently de-ossify overstrict ECN negotiation by Linux TCP servers? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 02:05:35 -0000 This is a multi-part message in MIME format. --------------F8AAB23B2497378D1A7E64E3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Brian, I've asked - I'll let you know once I hear. Bob On 16/03/2019 14:32, Brian Trammell (IETF) wrote: > Hi Bob, > > This seems eminently reasonable. I’m curious, would there be > equivalent pushback on _only_ adding the SNMP counter? One could > always use observation to debug once the counter starts going up... > > Cheers, > > Brian > > Sent from my iPhone > > On 16 Mar 2019, at 12:38, Bob Briscoe > wrote: > >> Folks, >> >> After offline discussion with the Linux maintainers, we have agreed >> on option #2, which is to make overstrict ECN test more specific to >> RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field >> and the first six TCP flags in the main header are 0b000011. >> >> This will be a simple 1-line patch that maximizes the likelihood that >> it will be back-ported as far back as possible, hopefully back to the >> introduction of the over-strict test in May 2012. This should fix a >> large proportion of the installed base of Linux servers reasonably >> quickly. >> >> ==Logging== >> Separately we will submit a patch to add logging of each event that >> disables ECN, but only for future kernel versions, not for >> back-porting. However, there is resistance to any logging, so this >> might not be accepted. The proposal is >> * at default logging level, increment an SNMP count when ECN disabled >> for a connection due to a protocol violation >> * at increased logging level, on each event also write rate-limited >> kernel messages that record the client IP. >> >> Then, if a sysadmin wants to, they can get any network mangling fixed. >> >> >> Bob >> >> On 20/01/2019 23:31, Bob Briscoe wrote: >>> TCPM folks, >>> >>> RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. >>> However, if a client sends an ECN-capable SYN, existing Linux >>> servers disable ECN for the rest of the connection. >>> >>> To fix as many existing Linux servers as possible, as soon as >>> possible, I would recommend short-term solution #2 (see 'Three >>> Fixes' below). An alternative would be short-term solution #3. >>> >>> Anyone got a better fix? Anyone disagree with recommending #2? If >>> not, pls confirm your agreement. >>> >>> >>> Summary of Pros and Cons >>> >>> #2 pro: No longer ossifies non-ECN SYN >>> #2 pro: If a path does "unbleach" IP-ECN, protects the connection by >>> disabling ECN >>> #2 con: A residual degree of ossification remains >>> >>> #3 pro: No longer ossifies non-ECN SYN >>> #3 pro: No ossification at all >>> #3 con: If a path does "unbleach" IP-ECN, connection still attempts >>> to use ECN even though the path is mangling the ECN field. >>> >>> #1 is the full solution, but it should proceed in parallel as a >>> solution for the future, not to fix the past. >>> >>> >>> Background >>> >>> To negotiate ECN for a connection the client sets flag bits 8-9 in >>> the TCP header to 11 [RFC3168 Section 6.1.1] >>> . For your >>> convenience, I've included a picture of the TCP header flags at the end. >>> >>> In 2012 an additional test was patched into Linux servers. It >>> disables ECN for the connection unless the IP-ECN field of the SYN >>> is also zero (I'll call this the "overstrict ECN test"). >>> >>> This was because Section 6.1.1. of RFC3168 also said "A host MUST >>> NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the >>> overstrict ECN test ossifies this requirement into TCP. >>> >>> The Linux patch was intended to protect a connection against the >>> network mangling the IP-ECN field to a non-zero value. >>> Unfortunately, it also disables ECN completely if a client tries to >>> set ECT in the IP-ECN field of the SYN. >>> >>> RFC8311 has now updated RFC3168 to allow ECT on a SYN, in >>> conjunction with the ECN++ experiment. But few developers are going >>> to set ECT on a SYN if it causes about 84% of servers to completely >>> disable ECN (see Section 4.2.2. of the ECN++ draft >>> >>> for further details and the source of these numbers). >>> >>> >>> Three Fixes >>> >>> I can think of three ways to fix existing Linux servers: >>> >>> 1. Deploy Accurate ECN >>> on >>> existing Linux servers. >>> * AccECN inherently replaces the overstrict ECN test with a >>> pair of proper two-ended tests for network mangling, in >>> which each end feeds back the arriving IP ECN field in its >>> TCP feedback. In contrast, the overstrict ECN test is >>> one-ended, with the server only assuming what the client set. >>> * Altho AccECN will solve the problem, it should not be relied >>> on to fix the last six years of Linux server deployment. >>> AccECN is a non-trivial update so it is unlikely to get >>> back-ported and auto-deployed to most existing Linux servers >>> any time soon. >>> 2. Make the overstrict ECN test more specific to RFC3168, and add >>> logging. >>> * Currently, the only proposal for allowing ECT on a SYN >>> requires the client to also request Accurate ECN feedback, >>> which requires TCP header bits 7-9 to be 111. >>> * Therefore, the overstrict ECN test in a Linux server could >>> be altered to solely apply if bits 7-9 == 011 (rather than >>> just testing if bits 8-9 == 11). >>> * However, I am concerned that this ossifies around the >>> solution based on ECN++ and AccECN. What if ECN++ needs to >>> be superseded by some future protocol that allows ECT on a >>> SYN when some other field is different (e.g. one of TCP's >>> three remaining reserved flags, or a new TCP option)? >>> * Unfortunately, we cannot test for the absence of a >>> yet-to-be-invented TCP option. Nonetheless, I suggest *the >>> overstrict ECN test in a Linux server should at least be >>> altered to solely apply if TCP header bits 4-9 == 000011*. >>> * I suggest Linux also *logs whenever it disables ECN due to >>> this test*, so that broken paths can be identified and fixed. >>> * An extremely simple patch like this would be much more >>> likely than #1 (AccECN) to be back-ported and deployed to >>> most existing servers via regular Linux auto-updates. >>> 3. As #2, but do not disable ECN when the test fails, just log >>> those paths suspected of mangling ECN. >>> * Our most recent measurements of millions of Internet paths >>> found no occurrences where zero IP-ECN on a SYN was changed >>> to non-zero ("unbleaching"). So we could just remove the test. >>> * However, no occurrences found does not mean none exist. >>> Altho we tested millions of paths, we only tested from a few >>> dozen vantage points, albeit we did test both mobile and >>> fixed networks (see Section 4.2.2. of the ECN++ draft >>> >>> for summary of tests). >>> * If the number of problematic paths is small, it would still >>> make sense to run the ECN test as proposed under item #2, >>> but not disable ECN if it fails. Instead, just log any >>> negative results, so the broken network elements can be >>> identified and fixed. >>> >>> Cheers >>> >>> >>> Bob >>> >>> PS. For convenience, here's the TCP header flags (assuming the >>> experimental AccECN protocol is approved as RFC): >>> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> | | | A | C | E | U | A | P | R | S | F | >>> | Header Length | Reserved | E | W | C | R | C | S | S | Y | I | >>> | | | | R | E | G | K | H | T | N | N | >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F8AAB23B2497378D1A7E64E3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Brian,
I've asked - I'll let you know once I hear.

Bob

On 16/03/2019 14:32, Brian Trammell (IETF) wrote:
Hi Bob,

This seems eminently reasonable. I’m curious, would there be equivalent pushback on _only_ adding the SNMP counter? One could always use observation to debug once the counter starts going up...

Cheers,

Brian

Sent from my iPhone

On 16 Mar 2019, at 12:38, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Folks,

After offline discussion with the Linux maintainers, we have agreed on option #2, which is to make overstrict ECN test more specific to RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field and the first six TCP flags in the main header are 0b000011.

This will be a simple 1-line patch that maximizes the likelihood that it will be back-ported as far back as possible, hopefully back to the introduction of the over-strict test in May 2012. This should fix a large proportion of the installed base of Linux servers reasonably quickly.

==Logging==
Separately we will submit a patch to add logging of each event that disables ECN, but only for future kernel versions, not for back-porting. However, there is resistance to any logging, so this might not be accepted. The proposal is
* at default logging level, increment an SNMP count when ECN disabled for a connection due to a protocol violation
* at increased logging level, on each event also write rate-limited kernel messages that record the client IP.

Then, if a sysadmin wants to, they can get any network mangling fixed.


Bob

On 20/01/2019 23:31, Bob Briscoe wrote:
TCPM folks,

RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. However, if a client sends an ECN-capable SYN, existing Linux servers disable ECN for the rest of the connection.

To fix as many existing Linux servers as possible, as soon as possible, I would recommend short-term solution #2 (see 'Three Fixes' below). An alternative would be short-term solution #3.

Anyone got a better fix? Anyone disagree with recommending #2? If not, pls confirm your agreement.

Summary of Pros and Cons

#2 pro: No longer ossifies non-ECN SYN
#2 pro: If a path does "unbleach" IP-ECN, protects the connection by disabling ECN
#2 con: A residual degree of ossification remains

#3 pro: No longer ossifies non-ECN SYN
#3 pro: No ossification at all
#3 con: If a path does "unbleach" IP-ECN, connection still attempts to use ECN even though the path is mangling the ECN field.

#1 is the full solution, but it should proceed in parallel as a solution for the future, not to fix the past.

Background

To negotiate ECN for a connection the client sets flag bits 8-9 in the TCP header to 11 [RFC3168 Section 6.1.1]. For your convenience, I've included a picture of the TCP header flags at the end.

In 2012 an additional test was patched into Linux servers. It disables ECN for the connection unless the IP-ECN field of the SYN is also zero (I'll call this the "overstrict ECN test").

This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossifies this requirement into TCP.

The Linux patch was intended to protect a connection against the network mangling the IP-ECN field to a non-zero value. Unfortunately, it also disables ECN completely if a client tries to set ECT in the IP-ECN field of the SYN.

RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction with the ECN++ experiment. But few developers are going to set ECT on a SYN if it causes about 84% of servers to completely disable ECN (see Section 4.2.2. of the ECN++ draft for further details and the source of these numbers).

Three Fixes

I can think of three ways to fix existing Linux servers:
  1. Deploy Accurate ECN on existing Linux servers.
    • AccECN inherently replaces the overstrict ECN test with a pair of proper two-ended tests for network mangling, in which each end feeds back the arriving IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is one-ended, with the server only assuming what the client set.
    • Altho AccECN will solve the problem, it should not be relied on to fix the last six years of Linux server deployment. AccECN is a non-trivial update so it is unlikely to get back-ported and auto-deployed to most existing Linux servers any time soon.
  2. Make the overstrict ECN test more specific to RFC3168, and add logging.
    • Currently, the only proposal for allowing ECT on a SYN requires the client to also request Accurate ECN feedback, which requires TCP header bits 7-9 to be 111.
    • Therefore, the overstrict ECN test in a Linux server could be altered to solely apply if bits 7-9 == 011 (rather than just testing if bits 8-9 == 11).
    • However, I am concerned that this ossifies around the solution based on ECN++ and AccECN. What if ECN++ needs to be superseded by some future protocol that allows ECT on a SYN when some other field is different (e.g. one of TCP's three remaining reserved flags, or a new TCP option)?
    • Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP option. Nonetheless, I suggest the overstrict ECN test in a Linux server should at least be altered to solely apply if TCP header bits 4-9 == 000011.
    • I suggest Linux also logs whenever it disables ECN due to this test, so that broken paths can be identified and fixed.
    • An extremely simple patch like this would be much more likely than #1 (AccECN) to be back-ported and deployed to most existing servers via regular Linux auto-updates.
  3. As #2, but do not disable ECN when the test fails, just log those paths suspected of mangling ECN.
    • Our most recent measurements of millions of Internet paths found no occurrences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). So we could just remove the test.
    • However, no occurrences found does not mean none exist. Altho we tested millions of paths, we only tested from a few dozen vantage points, albeit we did test both mobile and fixed networks (see Section 4.2.2. of the ECN++ draft for summary of tests).
    • If the number of problematic paths is small, it would still make sense to run the ECN test as proposed under item #2, but not disable ECN if it fails. Instead, just log any negative results, so the broken network elements can be identified and fixed.
Cheers


Bob

PS. For convenience, here's the TCP header flags (assuming the experimental AccECN protocol is approved as RFC):
       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |           | A | C | E | U | A | P | R | S | F |
     | Header Length | Reserved  | E | W | C | R | C | S | S | Y | I |
     |               |           |   | R | E | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+



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

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F8AAB23B2497378D1A7E64E3-- From nobody Sun Mar 17 17:17:02 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6944A12F18C for ; Sun, 17 Mar 2019 17:17:01 -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 dQe6OUxzbhXA for ; Sun, 17 Mar 2019 17:16:57 -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 6FC11128B14 for ; Sun, 17 Mar 2019 17:16:56 -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:Cc:To:From:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gZBP/MP0+EeM6+sqky67jl3ybzt2/JlfD9ibrb3wvFM=; b=JnY9TX++10+Yif+GsS9fOBobu N3VXi+mnWDWsBhvypt6Q67p2dsnznROcgyUtA7UxlKbjd6L0TnDYC7RZ7hkoSTmPE7a+rK9SM5yi6 eayyZNuprh60GpKENeXxl+/BOaKeuEEFQEvNXthcgOLW/6WVk1J1XeBJAHOrnEyaQht46rYZLpRJ+ dVlTEalwEpKuTjHPNtwIC719wnxJwI/7XKA00JAY/bKx7wIwn/99f86sLrcweKvsgFFzPWtdHnKeW aZ/k3UiXeyQFehyaxzbL1JL1Ul5JdRvhpD+KS5KPn73iyvCKB5bvLlg34XT9V0or7sn1ySEReSqDQ 5XW+dQEWg==; Received: from [31.185.135.153] (port=37604 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h5fxV-0003LQ-NZ; Mon, 18 Mar 2019 00:16:54 +0000 From: Bob Briscoe To: "Brian Trammell (IETF)" Cc: tcpm IETF list References: <6fa5db15-fc49-a662-6a33-ac11c97a30a6@bobbriscoe.net> Message-ID: <887403fc-59a3-c23f-ca5e-8a3cd4a69c65@bobbriscoe.net> Date: Mon, 18 Mar 2019 00:16:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <6fa5db15-fc49-a662-6a33-ac11c97a30a6@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------0A27312D6001F581A28799D5" 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] Does this fix sufficiently de-ossify overstrict ECN negotiation by Linux TCP servers? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 00:17:02 -0000 This is a multi-part message in MIME format. --------------0A27312D6001F581A28799D5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Brian, Looks like adding only an SNMP counter could be acceptable. We'll submit a patch for net-next on that basis (as well as a patch without logging for net-stable). Bob On 17/03/2019 02:05, Bob Briscoe wrote: > Brian, > I've asked - I'll let you know once I hear. > > Bob > > On 16/03/2019 14:32, Brian Trammell (IETF) wrote: >> Hi Bob, >> >> This seems eminently reasonable. I’m curious, would there be >> equivalent pushback on _only_ adding the SNMP counter? One could >> always use observation to debug once the counter starts going up... >> >> Cheers, >> >> Brian >> >> Sent from my iPhone >> >> On 16 Mar 2019, at 12:38, Bob Briscoe > > wrote: >> >>> Folks, >>> >>> After offline discussion with the Linux maintainers, we have agreed >>> on option #2, which is to make overstrict ECN test more specific to >>> RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field >>> and the first six TCP flags in the main header are 0b000011. >>> >>> This will be a simple 1-line patch that maximizes the likelihood >>> that it will be back-ported as far back as possible, hopefully back >>> to the introduction of the over-strict test in May 2012. This should >>> fix a large proportion of the installed base of Linux servers >>> reasonably quickly. >>> >>> ==Logging== >>> Separately we will submit a patch to add logging of each event that >>> disables ECN, but only for future kernel versions, not for >>> back-porting. However, there is resistance to any logging, so this >>> might not be accepted. The proposal is >>> * at default logging level, increment an SNMP count when ECN >>> disabled for a connection due to a protocol violation >>> * at increased logging level, on each event also write rate-limited >>> kernel messages that record the client IP. >>> >>> Then, if a sysadmin wants to, they can get any network mangling fixed. >>> >>> >>> Bob >>> >>> On 20/01/2019 23:31, Bob Briscoe wrote: >>>> TCPM folks, >>>> >>>> RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable >>>> SYNs. However, if a client sends an ECN-capable SYN, existing Linux >>>> servers disable ECN for the rest of the connection. >>>> >>>> To fix as many existing Linux servers as possible, as soon as >>>> possible, I would recommend short-term solution #2 (see 'Three >>>> Fixes' below). An alternative would be short-term solution #3. >>>> >>>> Anyone got a better fix? Anyone disagree with recommending #2? If >>>> not, pls confirm your agreement. >>>> >>>> >>>> Summary of Pros and Cons >>>> >>>> #2 pro: No longer ossifies non-ECN SYN >>>> #2 pro: If a path does "unbleach" IP-ECN, protects the connection >>>> by disabling ECN >>>> #2 con: A residual degree of ossification remains >>>> >>>> #3 pro: No longer ossifies non-ECN SYN >>>> #3 pro: No ossification at all >>>> #3 con: If a path does "unbleach" IP-ECN, connection still attempts >>>> to use ECN even though the path is mangling the ECN field. >>>> >>>> #1 is the full solution, but it should proceed in parallel as a >>>> solution for the future, not to fix the past. >>>> >>>> >>>> Background >>>> >>>> To negotiate ECN for a connection the client sets flag bits 8-9 in >>>> the TCP header to 11 [RFC3168 Section 6.1.1] >>>> . For your >>>> convenience, I've included a picture of the TCP header flags at the >>>> end. >>>> >>>> In 2012 an additional test was patched into Linux servers. It >>>> disables ECN for the connection unless the IP-ECN field of the SYN >>>> is also zero (I'll call this the "overstrict ECN test"). >>>> >>>> This was because Section 6.1.1. of RFC3168 also said "A host MUST >>>> NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the >>>> overstrict ECN test ossifies this requirement into TCP. >>>> >>>> The Linux patch was intended to protect a connection against the >>>> network mangling the IP-ECN field to a non-zero value. >>>> Unfortunately, it also disables ECN completely if a client tries to >>>> set ECT in the IP-ECN field of the SYN. >>>> >>>> RFC8311 has now updated RFC3168 to allow ECT on a SYN, in >>>> conjunction with the ECN++ experiment. But few developers are going >>>> to set ECT on a SYN if it causes about 84% of servers to completely >>>> disable ECN (see Section 4.2.2. of the ECN++ draft >>>> >>>> for further details and the source of these numbers). >>>> >>>> >>>> Three Fixes >>>> >>>> I can think of three ways to fix existing Linux servers: >>>> >>>> 1. Deploy Accurate ECN >>>> on >>>> existing Linux servers. >>>> * AccECN inherently replaces the overstrict ECN test with a >>>> pair of proper two-ended tests for network mangling, in >>>> which each end feeds back the arriving IP ECN field in its >>>> TCP feedback. In contrast, the overstrict ECN test is >>>> one-ended, with the server only assuming what the client set. >>>> * Altho AccECN will solve the problem, it should not be >>>> relied on to fix the last six years of Linux server >>>> deployment. AccECN is a non-trivial update so it is >>>> unlikely to get back-ported and auto-deployed to most >>>> existing Linux servers any time soon. >>>> 2. Make the overstrict ECN test more specific to RFC3168, and add >>>> logging. >>>> * Currently, the only proposal for allowing ECT on a SYN >>>> requires the client to also request Accurate ECN feedback, >>>> which requires TCP header bits 7-9 to be 111. >>>> * Therefore, the overstrict ECN test in a Linux server could >>>> be altered to solely apply if bits 7-9 == 011 (rather than >>>> just testing if bits 8-9 == 11). >>>> * However, I am concerned that this ossifies around the >>>> solution based on ECN++ and AccECN. What if ECN++ needs to >>>> be superseded by some future protocol that allows ECT on a >>>> SYN when some other field is different (e.g. one of TCP's >>>> three remaining reserved flags, or a new TCP option)? >>>> * Unfortunately, we cannot test for the absence of a >>>> yet-to-be-invented TCP option. Nonetheless, I suggest *the >>>> overstrict ECN test in a Linux server should at least be >>>> altered to solely apply if TCP header bits 4-9 == 000011*. >>>> * I suggest Linux also *logs whenever it disables ECN due to >>>> this test*, so that broken paths can be identified and fixed. >>>> * An extremely simple patch like this would be much more >>>> likely than #1 (AccECN) to be back-ported and deployed to >>>> most existing servers via regular Linux auto-updates. >>>> 3. As #2, but do not disable ECN when the test fails, just log >>>> those paths suspected of mangling ECN. >>>> * Our most recent measurements of millions of Internet paths >>>> found no occurrences where zero IP-ECN on a SYN was changed >>>> to non-zero ("unbleaching"). So we could just remove the test. >>>> * However, no occurrences found does not mean none exist. >>>> Altho we tested millions of paths, we only tested from a >>>> few dozen vantage points, albeit we did test both mobile >>>> and fixed networks (see Section 4.2.2. of the ECN++ draft >>>> >>>> for summary of tests). >>>> * If the number of problematic paths is small, it would still >>>> make sense to run the ECN test as proposed under item #2, >>>> but not disable ECN if it fails. Instead, just log any >>>> negative results, so the broken network elements can be >>>> identified and fixed. >>>> >>>> Cheers >>>> >>>> >>>> Bob >>>> >>>> PS. For convenience, here's the TCP header flags (assuming the >>>> experimental AccECN protocol is approved as RFC): >>>> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>> | | | A | C | E | U | A | P | R | S | F | >>>> | Header Length | Reserved | E | W | C | R | C | S | S | Y | I | >>>> | | | | R | E | G | K | H | T | N | N | >>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>> >>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------0A27312D6001F581A28799D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Brian,

Looks like adding only an SNMP counter could be acceptable. We'll submit a patch for net-next on that basis (as well as a patch without logging for net-stable).


Bob

On 17/03/2019 02:05, Bob Briscoe wrote:
Brian,
I've asked - I'll let you know once I hear.

Bob

On 16/03/2019 14:32, Brian Trammell (IETF) wrote:
Hi Bob,

This seems eminently reasonable. I’m curious, would there be equivalent pushback on _only_ adding the SNMP counter? One could always use observation to debug once the counter starts going up...

Cheers,

Brian

Sent from my iPhone

On 16 Mar 2019, at 12:38, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Folks,

After offline discussion with the Linux maintainers, we have agreed on option #2, which is to make overstrict ECN test more specific to RFC3168 by only disabling ECN if a SYN has a non-zero IP-ECN field and the first six TCP flags in the main header are 0b000011.

This will be a simple 1-line patch that maximizes the likelihood that it will be back-ported as far back as possible, hopefully back to the introduction of the over-strict test in May 2012. This should fix a large proportion of the installed base of Linux servers reasonably quickly.

==Logging==
Separately we will submit a patch to add logging of each event that disables ECN, but only for future kernel versions, not for back-porting. However, there is resistance to any logging, so this might not be accepted. The proposal is
* at default logging level, increment an SNMP count when ECN disabled for a connection due to a protocol violation
* at increased logging level, on each event also write rate-limited kernel messages that record the client IP.

Then, if a sysadmin wants to, they can get any network mangling fixed.


Bob

On 20/01/2019 23:31, Bob Briscoe wrote:
TCPM folks,

RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. However, if a client sends an ECN-capable SYN, existing Linux servers disable ECN for the rest of the connection.

To fix as many existing Linux servers as possible, as soon as possible, I would recommend short-term solution #2 (see 'Three Fixes' below). An alternative would be short-term solution #3.

Anyone got a better fix? Anyone disagree with recommending #2? If not, pls confirm your agreement.

Summary of Pros and Cons

#2 pro: No longer ossifies non-ECN SYN
#2 pro: If a path does "unbleach" IP-ECN, protects the connection by disabling ECN
#2 con: A residual degree of ossification remains

#3 pro: No longer ossifies non-ECN SYN
#3 pro: No ossification at all
#3 con: If a path does "unbleach" IP-ECN, connection still attempts to use ECN even though the path is mangling the ECN field.

#1 is the full solution, but it should proceed in parallel as a solution for the future, not to fix the past.

Background

To negotiate ECN for a connection the client sets flag bits 8-9 in the TCP header to 11 [RFC3168 Section 6.1.1]. For your convenience, I've included a picture of the TCP header flags at the end.

In 2012 an additional test was patched into Linux servers. It disables ECN for the connection unless the IP-ECN field of the SYN is also zero (I'll call this the "overstrict ECN test").

This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossifies this requirement into TCP.

The Linux patch was intended to protect a connection against the network mangling the IP-ECN field to a non-zero value. Unfortunately, it also disables ECN completely if a client tries to set ECT in the IP-ECN field of the SYN.

RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction with the ECN++ experiment. But few developers are going to set ECT on a SYN if it causes about 84% of servers to completely disable ECN (see Section 4.2.2. of the ECN++ draft for further details and the source of these numbers).

Three Fixes

I can think of three ways to fix existing Linux servers:
  1. Deploy Accurate ECN on existing Linux servers.
    • AccECN inherently replaces the overstrict ECN test with a pair of proper two-ended tests for network mangling, in which each end feeds back the arriving IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is one-ended, with the server only assuming what the client set.
    • Altho AccECN will solve the problem, it should not be relied on to fix the last six years of Linux server deployment. AccECN is a non-trivial update so it is unlikely to get back-ported and auto-deployed to most existing Linux servers any time soon.
  2. Make the overstrict ECN test more specific to RFC3168, and add logging.
    • Currently, the only proposal for allowing ECT on a SYN requires the client to also request Accurate ECN feedback, which requires TCP header bits 7-9 to be 111.
    • Therefore, the overstrict ECN test in a Linux server could be altered to solely apply if bits 7-9 == 011 (rather than just testing if bits 8-9 == 11).
    • However, I am concerned that this ossifies around the solution based on ECN++ and AccECN. What if ECN++ needs to be superseded by some future protocol that allows ECT on a SYN when some other field is different (e.g. one of TCP's three remaining reserved flags, or a new TCP option)?
    • Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP option. Nonetheless, I suggest the overstrict ECN test in a Linux server should at least be altered to solely apply if TCP header bits 4-9 == 000011.
    • I suggest Linux also logs whenever it disables ECN due to this test, so that broken paths can be identified and fixed.
    • An extremely simple patch like this would be much more likely than #1 (AccECN) to be back-ported and deployed to most existing servers via regular Linux auto-updates.
  3. As #2, but do not disable ECN when the test fails, just log those paths suspected of mangling ECN.
    • Our most recent measurements of millions of Internet paths found no occurrences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). So we could just remove the test.
    • However, no occurrences found does not mean none exist. Altho we tested millions of paths, we only tested from a few dozen vantage points, albeit we did test both mobile and fixed networks (see Section 4.2.2. of the ECN++ draft for summary of tests).
    • If the number of problematic paths is small, it would still make sense to run the ECN test as proposed under item #2, but not disable ECN if it fails. Instead, just log any negative results, so the broken network elements can be identified and fixed.
Cheers


Bob

PS. For convenience, here's the TCP header flags (assuming the experimental AccECN protocol is approved as RFC):
       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |           | A | C | E | U | A | P | R | S | F |
     | Header Length | Reserved  | E | W | C | R | C | S | S | Y | I |
     |               |           |   | R | E | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+



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

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

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------0A27312D6001F581A28799D5-- From nobody Mon Mar 18 07:10:38 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECAB12AF83; Mon, 18 Mar 2019 07:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, L_8BIT_MISMATCH=0.01, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWmP02egK2Ju; Mon, 18 Mar 2019 07:10:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C982A12872C; Mon, 18 Mar 2019 07:10:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 484DBB80088; Mon, 18 Mar 2019 07:10:14 -0700 (PDT) To: marco.caspers@t-mobilethuis.nl, david.borman@quantum.com, braden@isi.edu, vanj@google.com, rs@netapp.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@kuehlewind.net, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190318141014.484DBB80088@rfc-editor.org> Date: Mon, 18 Mar 2019 07:10:14 -0700 (PDT) Archived-At: Subject: [tcpm] [Errata Held for Document Update] RFC7323 (5585) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 14:10:29 -0000 The following errata report has been held for document update for RFC7323, "TCP Extensions for High Performance". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5585 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Marco Caspers Date Reported: 2018-12-27 Held by: Mirja Kühlewind (IESG) Section: 2.2 Original Text ------------- 2.2. Window Scale Option The three-byte Window Scale option MAY be sent in a segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to both send and receive window scaling, and (2) communicate the exponent of a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows SHOULD send the option, even if its own scale factor is 1 and the exponent 0. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. The maximum scale exponent is limited to 14 for a maximum permissible receive window size of 1 GiB (2^(14+16)). Corrected Text -------------- 2.2. Window Scale Option The three-byte Window Scale option MAY be sent in a segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to both send and receive window scaling, and (2) communicate the exponent of a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows SHOULD send the option, even if its own scale factor is 1 and the exponent 0. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. The maximum scale exponent is limited to 14 for a maximum permissible receive window size of approximately 1 GiB ((2^30-1) - (2^14-1)). Notes ----- Left shift inserts zero's on the right hand side so the maximum window size is actually 16KiB shy of 1 GiB. The exact calculation would be ((2^30-1) - (2^14-1)). As it is stated as "approximately 1 GiB" the text is not incorrect but it would be good to provide the complete calculation in a document update to avoid invalid implementations. -------------------------------------- RFC7323 (draft-ietf-tcpm-1323bis-21) -------------------------------------- Title : TCP Extensions for High Performance Publication Date : September 2014 Author(s) : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed. Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Fri Mar 22 01:39:38 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD46130EBD for ; Fri, 22 Mar 2019 01:39:36 -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 GBlP3p9AU8m8 for ; Fri, 22 Mar 2019 01:39:33 -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 8AC4E130E8F for ; Fri, 22 Mar 2019 01:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:Cc:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zh15diZc5z6AILcEukbJdGMkoXfWDXhFxPwCOQqp2JA=; b=0p2FfR7QOnNRjMZYUg1PBlRsaW nwanNjFWPuSeRdDkqmcBXjgT70KOZNoIOCEuH6eBNKLgQUvRFgTU8RliDjPaSCiGSS1EHDl8bfEME LAUZmfmSHDlyMU8Paxx2KkUZ7cqTe9xtaGKj8Y5USj1bMrJmLTuIrlDo775sMJTS3/vm290Fd1qko meph0RKwmlC5jiMaE9gUG4S9X0US2LYDbwyRmQIwt9v3yiv2iNzSufm5dFvAvghM+2NtGFvEAf6x1 8xD9sYmH0N+c8tFA9WkK75mKfOmaq3UnHdt8SaIN+8deGGNMh16s1uh5lSmpKrLiMZV0C0NyzLoNS IyXtrdrA==; Received: from 140.212.broadband18.iol.cz ([109.81.212.140]:53517 helo=[10.0.0.47]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h7Fi6-0005ec-1L; Fri, 22 Mar 2019 08:39:30 +0000 To: "Tilmans, Olivier (Nokia - BE/Antwerp)" Cc: tcpm IETF list From: Bob Briscoe Message-ID: <71f6ff55-6b8b-b488-873f-81c0f37dce99@bobbriscoe.net> Date: Fri, 22 Mar 2019 09:39:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F75A37D292E21757ABFFA7EC" 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] draft-ietf-tcpm-accurate-ecn-08 inconsistencies? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 08:39:37 -0000 This is a multi-part message in MIME format. --------------F75A37D292E21757ABFFA7EC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Olivier, Thanks for pointing out verbally last night at netdev that the spec states three different sets of valid values for the 'ACE' field on the SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless handshake). I promised I would check whether this was deliberate or an editorial mistake.... ==SYN/ACK== Valid values are 2,3,4 & 6 ==3rd ACK== By my reading, the valid values for the 3rd ACK are 2-7 and the draft is consistent in both stateful and stateless cases. Please tell me if the text is not clear in some way that I cannot see. ==Ease of Implementation== You also mentioned that the values chosen required an awkward set of case statements, just to check validity. Yes, there's a gap in the sequence - because value 5 (decimal) in the codepoint space on the SYN/ACK might have already been used (by RFC3540). However, the mapping was chosen to enable a simple algo to match them, and for the same function to be used for both SYN/ACK and ACK, as follows: (values shown in decimal) IP ECN f/b ACE SYN/ACK ACE 3rd ACK 0 2 2 1 3 3 2 4 4 3 6 6 A pseudocode expression for the IP ECN f/b would be:     bool server;            // pseudocode for "I'm receiving the ACK of my SYN/ACK"     unsigned ip_ecn_fb, ace;     ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( (ace >= 6) ? 3 : 2) : RETURN_INVALID; What's so hard about that? ;) Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F75A37D292E21757ABFFA7EC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Olivier,

Thanks for pointing out verbally last night at netdev that the spec states three different sets of valid values for the 'ACE' field on the SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless handshake).

I promised I would check whether this was deliberate or an editorial mistake....

==SYN/ACK==
Valid values are 2,3,4 & 6

==3rd ACK==
By my reading, the valid values for the 3rd ACK are 2-7 and the draft is consistent in both stateful and stateless cases.
Please tell me if the text is not clear in some way that I cannot see.

==Ease of Implementation==
You also mentioned that the values chosen required an awkward set of case statements, just to check validity. Yes, there's a gap in the sequence - because value 5 (decimal) in the codepoint space on the SYN/ACK might have already been used (by RFC3540). However, the mapping was chosen to enable a simple algo to match them, and for the same function to be used for both SYN/ACK and ACK, as follows: (values shown in decimal)

IP ECN f/b
 ACE SYN/ACK ACE 3rd ACK
0
 2
 2
1
 3
 3
2
 4
 4
3
 6
 6

A pseudocode expression for the IP ECN f/b would be:
    bool server;            // pseudocode for "I'm receiving the ACK of my SYN/ACK"
    unsigned ip_ecn_fb, ace;
    ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( (ace >= 6) ? 3 : 2) : RETURN_INVALID;

What's so hard about that? ;)




Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F75A37D292E21757ABFFA7EC-- From nobody Fri Mar 22 03:47:46 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C95F130DE7 for ; Fri, 22 Mar 2019 03:47:44 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 qJkuC7q_r-3k for ; Fri, 22 Mar 2019 03:47:41 -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-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4721200B3 for ; Fri, 22 Mar 2019 03:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LU101cBGj1oCsdn1tDPSsza7Uac6HtRYkSZZK4i05Hw=; b=kKADTror2WLhRs7Cr2v33IvoxCA5+pMJu02NGccv0XDqZdeiJSWik+80aSda5eIHRHrtXMVhufpWEwlFpnOGYoOip7HcHteqUbRYIHOFaQ5KZAHLntCmfGPUDSe9wNmZVJyav/kUnnfb85TyAofOwyZQjdcd6gIn2cAEF47fRHg= Received: from AM0PR07MB4819.eurprd07.prod.outlook.com (20.178.19.14) by AM0PR07MB6019.eurprd07.prod.outlook.com (20.178.112.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.11; Fri, 22 Mar 2019 10:47:37 +0000 Received: from AM0PR07MB4819.eurprd07.prod.outlook.com ([fe80::59f0:fdb8:2725:c844]) by AM0PR07MB4819.eurprd07.prod.outlook.com ([fe80::59f0:fdb8:2725:c844%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 10:47:37 +0000 From: "Tilmans, Olivier (Nokia - BE/Antwerp)" To: Bob Briscoe CC: tcpm IETF list Thread-Topic: draft-ietf-tcpm-accurate-ecn-08 inconsistencies? Thread-Index: AQHU4IrHtT6VMmuBIk2I678VPDmkzqYXeD3w Date: Fri, 22 Mar 2019 10:47:37 +0000 Message-ID: References: <71f6ff55-6b8b-b488-873f-81c0f37dce99@bobbriscoe.net> In-Reply-To: <71f6ff55-6b8b-b488-873f-81c0f37dce99@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=olivier.tilmans@nokia-bell-labs.com; x-originating-ip: [40.67.249.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72051680-f3ff-467b-639a-08d6aeb3cce0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB6019; x-ms-traffictypediagnostic: AM0PR07MB6019: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39860400002)(396003)(366004)(199004)(189003)(33656002)(8676002)(81156014)(6506007)(14454004)(53546011)(476003)(6116002)(3846002)(76176011)(102836004)(81166006)(486006)(26005)(7736002)(86362001)(99286004)(68736007)(106356001)(6436002)(8936002)(478600001)(7696005)(6916009)(105586002)(71200400001)(71190400001)(74316002)(966005)(5660300002)(316002)(446003)(52536014)(229853002)(66066001)(2906002)(53936002)(97736004)(53376002)(6246003)(256004)(25786009)(6306002)(54896002)(9686003)(55016002)(4326008)(186003)(606006)(236005)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6019; H:AM0PR07MB4819.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rX3UmADO2uwuK8FXbOasjyQyhA7lYgAwqJjxk2A94VVVv3TIqOP/UXdsu4yTvjvmEiGJu/v/tmiFxBbW11igLRsg9w0rvZlsvG71H3VlTvW5TVL9aONydelIvExRxr/+XeSOpQN2rzcZ0qHCzDH37HBOz9eXer1y5jz5NEGxNX7mUpaDltm9fBZw3pw+esVRHg7ag3W3gB1Wg2fVndbB5DUH7GoQOUYxpmTUa/i1PhOtIC58EloGCxttyD20rdXTR8zN+rsHlMmpcmNsWG5xSmN8juLjwdvd51zrKotBYbHYfT1SdwxIJs2o8wMg0Zz1eSCkuOHqnUySY8qPw69Nv6r0VhDq0Kuo1kuTNrFnl2BuvKl2ovcaU9hHdxejGOC1VV7npnGWTQ8pAiLBp0ZyoieksekQUls59Bvy5sKFAbM= Content-Type: multipart/alternative; boundary="_000_AM0PR07MB4819372326EC8F99A7CFFC67E0430AM0PR07MB4819eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72051680-f3ff-467b-639a-08d6aeb3cce0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 10:47:37.4917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6019 Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-08 inconsistencies? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 10:47:44 -0000 --_000_AM0PR07MB4819372326EC8F99A7CFFC67E0430AM0PR07MB4819eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, Thanks for looking it up. The perceived difference I had was due to the notes 2/3 in table 3 in combi= nation with the s.cep column which led me to believe that all values but 0 = were acceptable for the final ACK of a statefull opening, whereas the synco= okies case was stricter. The ecn negociation status is embedded in the syn cookies, the 0b001 ACE is= thus not needed/used to remember/identify that classic ecn was negociated = (at least on Linux). It should thus be possible to be more specific about what an AccECN server = should do when receiving an ACE of 0b001 on the final ACK if it had an AccE= CN state for the connection/didn't find back the ecn bit in the syncookie: = should it fallback to classic ECN? Disable ECN altogether as that is an err= or state? I doubt this can be safely ignored... The draft doesn't specify it beyond 'it ought to be impossible'. Best, Olivier ________________________________ From: Bob Briscoe Sent: Friday, March 22, 2019 9:39:25 AM To: Tilmans, Olivier (Nokia - BE/Antwerp) Cc: tcpm IETF list Subject: draft-ietf-tcpm-accurate-ecn-08 inconsistencies? Olivier, Thanks for pointing out verbally last night at netdev that the spec states = three different sets of valid values for the 'ACE' field on the SYN-ACK and= the 3rd ACK of the 3WHS (with stateful or stateless handshake). I promised I would check whether this was deliberate or an editorial mistak= e.... =3D=3DSYN/ACK=3D=3D Valid values are 2,3,4 & 6 =3D=3D3rd ACK=3D=3D By my reading, the valid values for the 3rd ACK are 2-7 and the draft is co= nsistent in both stateful and stateless cases. Please tell me if the text is not clear in some way that I cannot see. =3D=3DEase of Implementation=3D=3D You also mentioned that the values chosen required an awkward set of case s= tatements, just to check validity. Yes, there's a gap in the sequence - bec= ause value 5 (decimal) in the codepoint space on the SYN/ACK might have alr= eady been used (by RFC3540). However, the mapping was chosen to enable a si= mple algo to match them, and for the same function to be used for both SYN/= ACK and ACK, as follows: (values shown in decimal) IP ECN f/b ACE SYN/ACK ACE 3rd ACK 0 2 2 1 3 3 2 4 4 3 6 6 A pseudocode expression for the IP ECN f/b would be: bool server; // pseudocode for "I'm receiving the ACK of my = SYN/ACK" unsigned ip_ecn_fb, ace; ip_ecn_fb =3D ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( (ace= >=3D 6) ? 3 : 2) : RETURN_INVALID; What's so hard about that? ;) Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_AM0PR07MB4819372326EC8F99A7CFFC67E0430AM0PR07MB4819eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bob,

Thanks for looking it up.

The perceived difference I had was due to the notes 2/3 in table 3 in combi= nation with the s.cep column which led me to believe that all values but 0 = were acceptable for the final ACK of a statefull opening, whereas the synco= okies case was stricter.

The ecn negociation status is embedded in the syn cookies, the 0b001 ACE is= thus not needed/used to remember/identify that classic ecn was negociated = (at least on Linux).

It should thus be possible to be more specific about what an AccECN server = should do when receiving an ACE of 0b001 on the final ACK if it had an AccE= CN state for the connection/didn't find back the ecn bit in the syncookie: = should it fallback to classic ECN? Disable ECN altogether as that is an error state? I doubt this can be safe= ly ignored...
The draft doesn't specify it beyond 'it ought to be impossible'.


Best,
Olivier
From: Bob Briscoe <ietf@= bobbriscoe.net>
Sent: Friday, March 22, 2019 9:39:25 AM
To: Tilmans, Olivier (Nokia - BE/Antwerp)
Cc: tcpm IETF list
Subject: draft-ietf-tcpm-accurate-ecn-08 inconsistencies?
 
Olivier,

Thanks for pointing out verbally last night at netdev that the spec states = three different sets of valid values for the 'ACE' field on the SYN-ACK and= the 3rd ACK of the 3WHS (with stateful or stateless handshake).

I promised I would check whether this was deliberate or an editorial mistak= e....

=3D=3DSYN/ACK=3D=3D
Valid values are 2,3,4 & 6

=3D=3D3rd ACK=3D=3D
By my reading, the valid values for the 3rd ACK are 2-7 and the draft is co= nsistent in both stateful and stateless cases.
Please tell me if the text is not clear in some way that I cannot see.

=3D=3DEase of Implementation=3D=3D
You also mentioned that the values chosen required an awkward set of case s= tatements, just to check validity. Yes, there's a gap in the sequence - bec= ause value 5 (decimal) in the codepoint space on the SYN/ACK might have alr= eady been used (by RFC3540). However, the mapping was chosen to enable a simple algo to match them, and for the = same function to be used for both SYN/ACK and ACK, as follows: (values show= n in decimal)

IP ECN f/b
 ACE SYN/ACK ACE 3rd ACK
0
 2
 2
1
 3
 3
2
 4
 4
3
 6
 6

A pseudocode expression for the IP ECN f/b would be:
    bool server;         =    // pseudocode for "I'm receiving the ACK of my SYN/ACK&qu= ot;
    unsigned ip_ecn_fb, ace;
    ip_ecn_fb =3D ( (ace>1 ) && (!server || (ace = & 0b101)) ) ? ace - ( (ace >=3D 6) ? 3 : 2) : RETURN_INVALID;

What's so hard about that? ;)




Bob


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--_000_AM0PR07MB4819372326EC8F99A7CFFC67E0430AM0PR07MB4819eurp_-- From nobody Fri Mar 22 14:30:43 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8A130F5C for ; Fri, 22 Mar 2019 14:30:42 -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 LxHq5vHSR_nP for ; Fri, 22 Mar 2019 14:30:40 -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 C9B65131017 for ; Fri, 22 Mar 2019 14:30:39 -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=9FCZD//XjSjrtA6wrhrMmdCc0hfdJST4zUXJTbZcj4A=; b=2UNgrhhfFe1GiOAWNuLDX6t4b aK9gdy/ZW1Qg87mS/ippLK4BOIa9YKdi88PoUvEKBbHdvOJB8tDdAGfQnDnLZQjFCMddUOMOGAtQV 6NEs4sH1vuHtAkhRoJHTqr8BzH7hyvSS7u+rOLr1kbVO4+/3qFQFFVD0uj0/h2n7a/ECH+3QSvyDw kLaj/iHei8V4Lb8erk8K5A/K1TY5enXh1S4wmDbVw436v5/5RcU0hH2Qax6tHXC6aMMdqh7MgGTzf G97WbNOZsVFBkvulji0pf+AOmzDG7Fkf/qNgbRexySfq882pzXv7/bXCK3/pYs4Eh6e8Pr169iV56 2MG19ZZTA==; Received: from 198.212.broadband18.iol.cz ([109.81.212.198]:36755 helo=[10.0.0.47]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h7RkK-0002Pi-75; Fri, 22 Mar 2019 21:30:36 +0000 To: "Tilmans, Olivier (Nokia - BE/Antwerp)" Cc: tcpm IETF list References: <71f6ff55-6b8b-b488-873f-81c0f37dce99@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Fri, 22 Mar 2019 22:30:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------116D51020A0B15D8E62CA234" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-08 inconsistencies? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 21:30:43 -0000 This is a multi-part message in MIME format. --------------116D51020A0B15D8E62CA234 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Olivier, On 22/03/2019 11:47, Tilmans, Olivier (Nokia - BE/Antwerp) wrote: > Bob, > > Thanks for looking it up. > > The perceived difference I had was due to the notes 2/3 in table 3 in > combination with the s.cep column which led me to believe that all > values but 0 were acceptable for the final ACK of a statefull opening, > whereas the syncookies case was stricter. That is indeed what the notes mean. That's why note 3 (forward compatibility for CU) applies to the 0b001 case as well as Note 2 (stateless handshake). > > The ecn negociation status is embedded in the syn cookies, the 0b001 > ACE is thus not needed/used to remember/identify that classic ecn was > negociated (at least on Linux). OK. I'll write this for an implementation-generic case that doesn't preclude Linux. > > It should thus be possible to be more specific about what an AccECN > server should do when receiving an ACE of 0b001 on the final ACK if it > had an AccECN state for the connection/didn't find back the ecn bit in > the syncookie: should it fallback to classic ECN? Disable ECN > altogether as that is an error state? I doubt this can be safely > ignored... > The draft doesn't specify it beyond 'it ought to be impossible'. You're right, I haven't given behaviour in all possibilities. I think it might help to switch round notes 2 & 3, cos note 2 is more general than note 3. I've rewritten the notes as follows (in the authors' github copy for now): {Note 2}: If the server is in AccECN mode, these values are Currently Unused but the AccECN server's behaviour is still defined for forward compatibility. Then the designer of a future protocol can know for certain what AccECN servers will do with these codepoints. {Note 3}: In the case where a server that implements AccECN is also using a stateless handshake (termed a SYN cookie) it will not remember whether it entered AccECN mode. The values 0b000 or 0b001 will remind it that it did not enter AccECN mode, because AccECN does not use them (see Section 4.1 for details). If a stateless server that implements AccECN receives either of these two values in the ACK, its action is implementation-dependent and outside the scope of this spec, It will certainly not take the action in the third column because, after it receives either of these values, it is not in AccECN mode. I.e., it will not disable ECN (at least not just because ACE is 0b000) and it will not set s.cep. I'm avoiding going any deeper, 'cos there's the two cases with & without ECN, then there's the sub-case with ECE feedback, yada yada. Bob Very few IETF protocols are designed for complete future compatibility like AccECN has been. I am hoping it will be used as an exemplar in future. > > > Best, > Olivier > ------------------------------------------------------------------------ > *From:* Bob Briscoe > *Sent:* Friday, March 22, 2019 9:39:25 AM > *To:* Tilmans, Olivier (Nokia - BE/Antwerp) > *Cc:* tcpm IETF list > *Subject:* draft-ietf-tcpm-accurate-ecn-08 inconsistencies? > Olivier, > > Thanks for pointing out verbally last night at netdev that the spec > states three different sets of valid values for the 'ACE' field on the > SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless > handshake). > > I promised I would check whether this was deliberate or an editorial > mistake.... > > ==SYN/ACK== > Valid values are 2,3,4 & 6 > > ==3rd ACK== > By my reading, the valid values for the 3rd ACK are 2-7 and the draft > is consistent in both stateful and stateless cases. > Please tell me if the text is not clear in some way that I cannot see. > > ==Ease of Implementation== > You also mentioned that the values chosen required an awkward set of > case statements, just to check validity. Yes, there's a gap in the > sequence - because value 5 (decimal) in the codepoint space on the > SYN/ACK might have already been used (by RFC3540). However, the > mapping was chosen to enable a simple algo to match them, and for the > same function to be used for both SYN/ACK and ACK, as follows: (values > shown in decimal) > > IP ECN f/b > ACE SYN/ACK ACE 3rd ACK > 0 > 2 > 2 > 1 > 3 > 3 > 2 > 4 > 4 > 3 > 6 > 6 > > > A pseudocode expression for the IP ECN f/b would be: >     bool server;            // pseudocode for "I'm receiving the ACK > of my SYN/ACK" >     unsigned ip_ecn_fb, ace; >     ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( > (ace >= 6) ? 3 : 2) : RETURN_INVALID; > > What's so hard about that? ;) > > > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------116D51020A0B15D8E62CA234 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Olivier,

On 22/03/2019 11:47, Tilmans, Olivier (Nokia - BE/Antwerp) wrote:
Bob,

Thanks for looking it up.

The perceived difference I had was due to the notes 2/3 in table 3 in combination with the s.cep column which led me to believe that all values but 0 were acceptable for the final ACK of a statefull opening, whereas the syncookies case was stricter.
That is indeed what the notes mean.
That's why note 3 (forward compatibility for CU) applies to the 0b001 case as well as Note 2 (stateless handshake).

The ecn negociation status is embedded in the syn cookies, the 0b001 ACE is thus not needed/used to remember/identify that classic ecn was negociated (at least on Linux).
OK. I'll write this for an implementation-generic case that doesn't preclude Linux.


It should thus be possible to be more specific about what an AccECN server should do when receiving an ACE of 0b001 on the final ACK if it had an AccECN state for the connection/didn't find back the ecn bit in the syncookie: should it fallback to classic ECN? Disable ECN altogether as that is an error state? I doubt this can be safely ignored...
The draft doesn't specify it beyond 'it ought to be impossible'.
You're right, I haven't given behaviour in all possibilities.

I think it might help to switch round notes 2 & 3, cos note 2 is more general than note 3. I've rewritten the notes as follows (in the authors' github copy for now):

   {Note 2}: If the server is in AccECN mode, these values are Currently
   Unused but the AccECN server's behaviour is still defined for forward
   compatibility.  Then the designer of a future protocol can know for
   certain what AccECN servers will do with these codepoints.

   {Note 3}: In the case where a server that implements AccECN is also
   using a stateless handshake (termed a SYN cookie) it will not
   remember whether it entered AccECN mode.  The values 0b000 or 0b001
   will remind it that it did not enter AccECN mode, because AccECN does
   not use them (see Section 4.1 for details).

   If a stateless server that implements AccECN receives either of these
   two values in the ACK, its action is implementation-dependent and
   outside the scope of this spec, It will certainly not take the action
   in the third column because, after it receives either of these
   values, it is not in AccECN mode.  I.e., it will not disable ECN (at
   least not just because ACE is 0b000) and it will not set s.cep.
I'm avoiding going any deeper, 'cos there's the two cases with & without ECN, then there's the sub-case with ECE feedback, yada yada.


Bob

Very few IETF protocols are designed for complete future compatibility like AccECN has been. I am hoping it will be used as an exemplar in future.




Best,
Olivier
From: Bob Briscoe <ietf@bobbriscoe.net>
Sent: Friday, March 22, 2019 9:39:25 AM
To: Tilmans, Olivier (Nokia - BE/Antwerp)
Cc: tcpm IETF list
Subject: draft-ietf-tcpm-accurate-ecn-08 inconsistencies?
 
Olivier,

Thanks for pointing out verbally last night at netdev that the spec states three different sets of valid values for the 'ACE' field on the SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless handshake).

I promised I would check whether this was deliberate or an editorial mistake....

==SYN/ACK==
Valid values are 2,3,4 & 6

==3rd ACK==
By my reading, the valid values for the 3rd ACK are 2-7 and the draft is consistent in both stateful and stateless cases.
Please tell me if the text is not clear in some way that I cannot see.

==Ease of Implementation==
You also mentioned that the values chosen required an awkward set of case statements, just to check validity. Yes, there's a gap in the sequence - because value 5 (decimal) in the codepoint space on the SYN/ACK might have already been used (by RFC3540). However, the mapping was chosen to enable a simple algo to match them, and for the same function to be used for both SYN/ACK and ACK, as follows: (values shown in decimal)

IP ECN f/b
 ACE SYN/ACK ACE 3rd ACK
0
 2
 2
1
 3
 3
2
 4
 4
3
 6
 6

A pseudocode expression for the IP ECN f/b would be:
    bool server;            // pseudocode for "I'm receiving the ACK of my SYN/ACK"
    unsigned ip_ecn_fb, ace;
    ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( (ace >= 6) ? 3 : 2) : RETURN_INVALID;

What's so hard about that? ;)




Bob


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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------116D51020A0B15D8E62CA234-- From nobody Sun Mar 24 12:15:50 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD081120041; Sun, 24 Mar 2019 12:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XkuFFYs73Pj; Sun, 24 Mar 2019 12:15:46 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DF2120026; Sun, 24 Mar 2019 12:15:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 976F325A1B; Sun, 24 Mar 2019 20:15:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553454941; bh=u4I864gYVGfwORrNhJ2VWrpWaRCGRI0YICCQuoebZ/0=; h=From:To:CC:Subject:Date:From; b=IXvaOnXjd5TzOqrcWMhriWXpEkRIENpFmzukwlC2qeQYxvsPRDV3ufWmO6FVeW3Qp on7TxYZ/tBGQ8QnQODt4W+MydNEnICgGR524Ip46I0wPb8RglG7+V02hivdb0rlCxM hYZqJEuZTxYyY3UzIvzkMsCz6228fZK5UAoyldZQ= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4s_Kc4nMI-7; Sun, 24 Mar 2019 20:15:41 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 24 Mar 2019 20:15:41 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Sun, 24 Mar 2019 20:15:40 +0100 From: "Scharf, Michael" To: "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" CC: "tsvwg@ietf.org" , "tcpm@ietf.org" Thread-Topic: draft-ietf-tsvwg-ecn-l4s-id Thread-Index: AdTicaw/eTo/dzaNQFmeZc0gTHeEvw== Date: Sun, 24 Mar 2019 19:15:39 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] draft-ietf-tsvwg-ecn-l4s-id X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 19:15:49 -0000 I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into th= e following sentence: TCP: Support for accurate ECN feedback (AccECN [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for scalable congestion control. Therefore, the presence of ECT(1) in the IP headers even in one direction of a TCP connection will imply that both ends support AccECN. However, the converse does not apply. So even if both ends support AccECN, either of the two ends can choose not to use a scalable congestion control, whatever the other end's choice. Can the authors please clarify whether there is a normative dependency of d= raft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn? If so, I think the formal dependency on implementing AccECN has to be spelt= out explicitly. In that case, I would be looking for a statement of the so= rt "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If s= uch a requirement does not exist, I think the above paragraph is confusing. As individual contributor, I want to note that I disagree with mandatory de= pendencies between experiments. I have mentioned in the past that I believe= that different experiments must be specified independently of each other a= nd should be implementable independently of each other, specifically also t= o be able to fail independently of each other. It is possible that I am in = the rough part of the consensus. But I haven't changed my mind. Michael (as individual) From nobody Mon Mar 25 01:22:00 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F639120370 for ; Mon, 25 Mar 2019 01:21:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155350211932.22258.12817171740362260623.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2019 01:21:59 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:21:59 -0000 Changed milestone "Submit document on Alternative Backoff with ECN to the IESG for publication as Experimental RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Mon Mar 25 08:27:08 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0A0120013 for ; Sun, 24 Mar 2019 10:47:55 -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, 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 XHRmqjRoSGJ9 for ; Sun, 24 Mar 2019 10:47:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE28120005 for ; Sun, 24 Mar 2019 10:47:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 68C7AB82235; Sun, 24 Mar 2019 10:47:43 -0700 (PDT) To: touch@isi.edu, mankin@psg.com, rbonica@juniper.net, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nishida@sfc.wide.ad.jp X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: touch@strayalpha.com, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190324174743.68C7AB82235@rfc-editor.org> Date: Sun, 24 Mar 2019 10:47:43 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 25 Mar 2019 08:27:06 -0700 Subject: [tcpm] [Technical Errata Reported] RFC5925 (5672) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 17:47:55 -0000 The following errata report has been submitted for RFC5925, "The TCP Authentication Option". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5672 -------------------------------------- Type: Technical Reported by: Joe Touch Section: 6.2 Original Text ------------- /* set the flag when the SEG.SEQ first rolls over */ if ((RCV.SNE_FLAG == 0) && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { RCV.SNE = RCV.SNE + 1; RCV.SNE_FLAG = 1; } /* decide which SNE to use after incremented */ if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { SNE = RCV.SNE - 1; # use the pre-increment value } else { SNE = RCV.SNE; # use the current value } /* reset the flag in the *middle* of the window */ if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { RCV.SNE_FLAG = 0; } /* save the current SEQ for the next time through the code */ RCV.PREV_SEQ = SEG.SEQ; Corrected Text -------------- /* set the flag when the SEG.SEQ first rolls over */ if ((RCV.SNE_FLAG == 0) && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { RCV.SNE = RCV.SNE + 1; RCV.SNE_FLAG = 1; } /* decide which SNE to use after incremented */ if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fffffff)) { SNE = RCV.SNE - 1; # use the pre-increment value } else { SNE = RCV.SNE; # use the current value } /* reset the flag in the *middle* of the window */ if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) { RCV.SNE_FLAG = 0; } /* save the current SEQ for the next time through the code */ RCV.PREV_SEQ = SEG.SEQ; Notes ----- The SNE values are 32 bits; the current pseudocode used 16-bit masks (0x7fff) instead of their 32-bit equivalent (0x7fffffff). This error was first noted by Tero Kivinen . Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) -------------------------------------- Title : The TCP Authentication Option Publication Date : June 2010 Author(s) : J. Touch, A. Mankin, R. Bonica Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Mar 25 10:38:05 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50E1205AC for ; Mon, 25 Mar 2019 10:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EftOVtT11YhZ for ; Mon, 25 Mar 2019 10:38:01 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D741112059A for ; Mon, 25 Mar 2019 10:38:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 19B1325A19 for ; Mon, 25 Mar 2019 18:37:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553535479; bh=tNI5DIIo6YXFc3ISu3ulk7371YeVXUHTYnQbqEWcm1Y=; h=From:To:Subject:Date:References:In-Reply-To:From; b=PoQGz58Be4N16853izxW2Jy8K6xRejek1NWB9jpbdCp7qITGHoL+SyxIoxZNgc53a e7AUwIe3vtH9i57bZC/bpdJUpBskdPydr4EZCmNIjJg/Zta8XRsLUHMMLPFQuDgWU+ i9eRnA8DV1bqdVdukev9xbCiBb+1UgXi0YVPTqZM= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvo0QP9PoswF for ; Mon, 25 Mar 2019 18:37:57 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Mon, 25 Mar 2019 18:37:57 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 25 Mar 2019 18:37:57 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status Thread-Index: AQHU1G616iHOJHkpoEO6XOB3g3fkFaYcuRwA Date: Mon, 25 Mar 2019 17:37:56 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D2803EA@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D24EEA4@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D24EEA4@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:38:04 -0000 SGkgYWxsLA0KDQpUaGlzIGUtbWFpbCBjb25jbHVkZXMgdGhlIGFjY2VwdGFuY2UgY2FsbC4gQXMg bWVudGlvbmVkIGluIHRvZGF5J3MgbWVldGluZywgdGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgaXQg aXMgdGhlIHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzIHRvIGFkb3B0IHRoZSBkb2N1bWVudCBhcyBp bmZvcm1hdGlvbmFsLg0KDQpJJ2xsIHdvcmsgb24gdGhlIGNoYXJ0ZXIgbWlsZXN0b25lLiBPbmNl IHRoZSBjaGFydGVyIG1pbGVzdG9uZSBpcyBpbiBwbGFjZSwgSSdsbCBhc2sgdGhlIGF1dGhvcnMg dG8gcmVzdWJtaXQgdGhlIGRvY3VtZW50IGFzIGRyYWZ0LWlldGYtLg0KDQpUaGFua3MgYSBsb3QN Cg0KTWljaGFlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGNw bSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgU2NoYXJmLCBNaWNoYWVsDQo+ IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggNiwgMjAxOSAxMTo0OCBQTQ0KPiBUbzogdGNwbUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBbdGNwbV0gV29ya2luZyBncm91cCBhY2NlcHRhbmNlIG9mIGRyYWZ0 LXRvdWNoLXRjcG0tMjE0MGJpcy0wNg0KPiB0YXJnZXRpbmcgaW5mb3JtYXRpb25hbCBzdGF0dXMN Cj4gDQo+IEhpIGFsbCwNCj4gDQo+IFRoZSBkb2N1bWVudCBkcmFmdC10b3VjaC10Y3BtLTIxNDBi aXMgaGFzIGJlZW4gZGlzY3Vzc2VkIHF1aXRlIGEgYml0IGluDQo+IFRDUE0uIE9uZSBxdWVzdGlv biBoYXMgYmVlbiB0aGUgc3RhdHVzIChCQ1Agb3IgSU5GTykuIFRoZSB2ZXJzaW9uIGRyYWZ0LQ0K PiB0b3VjaC10Y3BtLTIxNDBiaXMtMDYgZXhwbGljaXRseSB0YXJnZXRzIGluZm9ybWF0aW9uYWwg c3RhdHVzIGFuZCBwbGFucyB0bw0KPiBvYnNvbGV0ZSBSRkMgMjE0MCAod2hpY2ggaXMgaW5mb3Jt YXRpb25hbCwgdG9vKS4NCj4gDQo+IFRoZSBpbnRlbnRpb24gb2YgdGhpcyBlLW1haWwgaXMgdG8g Y29uZmlybSB0aGF0IGRyYWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0wNg0KPiBzaG91bGQgYmUgYWRv cHRlZCBhcyBpbmZvcm1hdGlvbmFsIFRDUE0gd29ya2luZyBncm91cCBpdGVtLCBpLmUuLCB0aGF0 IGENCj4gbmV3IGl0ZW0gc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBUQ1BNIGNoYXJ0ZXI6DQo+IA0K PiAgIE5vdi4gMjAxOSAgU3VibWl0IGRvY3VtZW50IG9uIFRDUCBDb250cm9sIEJsb2NrIEludGVy ZGVwZW5kZW5jZSB0byB0aGUNCj4gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgSW5mb3JtYXRpb25h bCBSRkMNCj4gDQo+IFRoZSBhZG9wdGlvbiBjYWxsIHJ1bnMgb24gdGhlIFRDUE0gbWFpbGluZyBs aXN0IHVudGlsIE1hcmNoIDIyLiBQbGVhc2UgbGV0IHVzDQo+IGtub3cgaWYgeW91IHN1cHBvcnQg YWRvcHRpb24gb2YgdGhlIGRvY3VtZW50LCBvciBpZiB0aGVyZSBhcmUgYW55IGNvbmNlcm5zLg0K PiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBNaWNoYWVsDQo+IChUQ1BNIGNvLWNoYWlyKQ0KPiAN Cj4gDQo+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+IEZyb206IHRjcG0g W21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2UgVG91Y2gNCj4g U2VudDogRnJpZGF5LCBKYW51YXJ5IDQsIDIwMTkgNTo1MiBQTQ0KPiBUbzogdGNwbUBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbdGNwbV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0NCj4gMDYudHh0DQo+IA0KPiBGWUkgLQ0KPiBUaGlzIHZl cnNpb246DQo+IMKgwqDCoCAtIG9ic29sZXRlcyAyMTQwDQo+IMKgwqDCoCAtIHNheXMgc28gaW4g dGhlIGFic3RyYWN0IGFuZCBpbnRybw0KPiDCoMKgwqAgLSBpbmNsdWRlcyBhICJjaGFuZ2VzIGZy b20gMjE0MCIgc2VjdGlvbiBzdW1tYXJpemluZyB0aGUgZGlmZmVyZW5jZXMNCj4gTm90ZSB0aGF0 IHRoZSBlYXJsaWVyIHZlcnNpb25zIGRpZCBjaXRlIDIxNDAsIGJ1dCBkaWQgbm90IGFzIGRpcmVj dGx5IGluZGljYXRlDQo+IHRoYXQgdGhpcyBpcyBpbnRlbmRlZCBhcyBpdHMgcmVwbGFjZW1lbnQu DQo+IEpvZQ0KPiANCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gU3Vi amVjdDoNCj4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10b3VjaC10Y3BtLTIx NDBiaXMtMDYudHh0DQo+IERhdGU6DQo+IEZyaSwgMDQgSmFuIDIwMTkgMDg6NDk6MjUgLTA4MDAN Cj4gRnJvbToNCj4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFRvOg0KPiBTYWZpcXVsIElz bGFtIDxzYWZpcXVsaUBpZmkudWlvLm5vPiwgTWljaGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlv Lm5vPiwNCj4gSm9zZXBoIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbT4sIEpvZSBUb3VjaA0K PiA8dG91Y2hAc3RyYXlhbHBoYS5jb20+DQo+IA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC10b3VjaC10Y3BtLTIxNDBiaXMtMDYudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSm9lIFRvdWNoIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVw b3NpdG9yeS4NCj4gDQo+IE5hbWU6IGRyYWZ0LXRvdWNoLXRjcG0tMjE0MGJpcw0KPiBSZXZpc2lv bjogMDYNCj4gVGl0bGU6IFRDUCBDb250cm9sIEJsb2NrIEludGVyZGVwZW5kZW5jZQ0KPiBEb2N1 bWVudCBkYXRlOiAyMDE5LTAxLTA0DQo+IEdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g UGFnZXM6IDIyDQo+IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXRvdWNoLXRjcG0tMjE0MGJpcy0wNi50eHQNCj4gU3RhdHVzOiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC10b3VjaC10Y3BtLTIxNDBiaXMvDQo+IEh0bWxpemVkOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzLTA2DQo+ IEh0bWxpemVkOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRv dWNoLXRjcG0tMjE0MGJpcw0KPiBEaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzLTA2DQo+IA0KPiBBYnN0cmFjdDoNCj4gVGhpcyBt ZW1vIHVwZGF0ZXMgYW5kIHJlcGxhY2VzIFJGQyAyMTQwJ3MgZGVzY3JpcHRpb24gb2YNCj4gaW50 ZXJkZXBlbmRlbnQgVENQIGNvbnRyb2wgYmxvY2tzLCBpbiB3aGljaCBwYXJ0IG9mIHRoZSBUQ1Ag c3RhdGUgaXMNCj4gc2hhcmVkIGFtb25nIHNpbWlsYXIgY29uY3VycmVudCBvciBjb25zZWN1dGl2 ZSBjb25uZWN0aW9ucy4gVENQDQo+IHN0YXRlIGluY2x1ZGVzIGEgY29tYmluYXRpb24gb2YgcGFy YW1ldGVycywgc3VjaCBhcyBjb25uZWN0aW9uDQo+IHN0YXRlLCBjdXJyZW50IHJvdW5kLXRyaXAg dGltZSBlc3RpbWF0ZXMsIGNvbmdlc3Rpb24gY29udHJvbA0KPiBpbmZvcm1hdGlvbiwgYW5kIHBy b2Nlc3MgaW5mb3JtYXRpb24uIE1vc3Qgb2YgdGhpcyBzdGF0ZSBpcw0KPiBtYWludGFpbmVkIG9u IGEgcGVyLWNvbm5lY3Rpb24gYmFzaXMgaW4gdGhlIFRDUCBDb250cm9sIEJsb2NrIChUQ0IpLA0K PiBidXQgaW1wbGVtZW50YXRpb25zIGNhbiAoYW5kIGRvKSBzaGFyZSBjZXJ0YWluIFRDQiBpbmZv cm1hdGlvbg0KPiBhY3Jvc3MgY29ubmVjdGlvbnMgdG8gdGhlIHNhbWUgaG9zdC4gU3VjaCBzaGFy aW5nIGlzIGludGVuZGVkIHRvDQo+IGltcHJvdmUgb3ZlcmFsbCB0cmFuc2llbnQgdHJhbnNwb3J0 IHBlcmZvcm1hbmNlLCB3aGlsZSBtYWludGFpbmluZw0KPiBiYWNrd2FyZC1jb21wYXRpYmlsaXR5 IHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiBUaGUgc2hhcmluZw0KPiBkZXNjcmliZWQg aGVyZWluIGlzIGxpbWl0ZWQgdG8gb25seSB0aGUgVENCIGluaXRpYWxpemF0aW9uIGFuZCBzbw0K PiBoYXMgbm8gZWZmZWN0IG9uIHRoZSBsb25nLXRlcm0gYmVoYXZpb3Igb2YgVENQIGFmdGVyIGEg Y29ubmVjdGlvbg0KPiBoYXMgYmVlbiBlc3RhYmxpc2hlZC4NCj4gDQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNw bSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RjcG0NCg== From nobody Tue Mar 26 06:03:03 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BAA120004; Tue, 26 Mar 2019 06:03:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BnINJ2jB7hn; Tue, 26 Mar 2019 06:02:56 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D2E120003; Tue, 26 Mar 2019 06:02:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B29EE25A22; Tue, 26 Mar 2019 14:02:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553605374; bh=jQKirudCDBmxrjcpH5KNUiGIjjG5LPut39AqeV/ZSzw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=SoWZCg4k1g2sG1/hWXfvotdN/nHpgnu4o0IMu3SFaAsnniB5TU15dF7xdjX9foy5n l29crN7eRBwlSEQ9QSZxvnt1ukenAKr3SUmTR1I1KEu0WkSS2yOKl8nvNXEvjNE5U1 cigZFk0cKATjYgJiebke4BTRuKk/aW7TqOPirtJk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QHBOvI5q8Fr; Tue, 26 Mar 2019 14:02:49 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 14:02:49 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 14:02:49 +0100 From: "Scharf, Michael" To: Mahesh Jethanandani , Netconf CC: "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1Q Date: Tue, 26 Mar 2019 13:02:49 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 13:03:02 -0000 Hi Mahesh, As chair of the TCPM working group, I believe that the document draft-kwats= en-netconf-tcp-client-server-00 belongs into the TCPM working group. The do= cument is about a generic YANG model for an interface for TCP "for an SSH, = TLS, or HTTP based application". I fail to see a reason why such a generic = TCP model should be done in NETCONF. Thus, as a chair of TCPM, I object to adoption in NETCONF. I also want to note that it would have been possible to send a note to the = TCPM list prior to starting an adoption call, as the TCPM list is monitored= by many TCP implementers who could be affected by such a YANG model. YANG = models can be used in different use cases. TCPM has a tradition of being ve= ry open to presentations from other working groups if they relate to TCP. I= have added the TCPM list in CC. As an individual contributor to the IETF, I happen to be an author of draft= -scharf-tcpm-yang-tcp, which actually was submitted last year. Given that d= ifferent working groups seem to be involved, I believe that it would make s= ense to join efforts. Shouldn't we have a chat on the best next steps? Thanks Michael > -----Original Message----- > From: netconf On Behalf Of Mahesh > Jethanandani > Sent: Tuesday, March 26, 2019 12:17 PM > To: Netconf > Subject: [netconf] Adoption poll for tcp-client-server and http-client-se= rver > draft >=20 > This is the start of a two week poll for WG adoption of the two drafts: >=20 > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 >=20 > Please indicate your support for or any objections you might have for > adopting the two drafts as WG items by April 9. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Mar 26 07:19:13 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B060C1202F0; Tue, 26 Mar 2019 07:19:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 I4aEgRYXF76d; Tue, 26 Mar 2019 07:19:09 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4C11202EE; Tue, 26 Mar 2019 07:19:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A8C826F4; Tue, 26 Mar 2019 15:19:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id a4S9LElk9ezY; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91952200A8; Tue, 26 Mar 2019 15:19:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id M2PdasdmXJoP; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 37839200A7; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 15:19:06 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 2FB9730079D370; Tue, 26 Mar 2019 15:19:05 +0100 (CET) Date: Tue, 26 Mar 2019 15:19:05 +0100 From: Juergen Schoenwaelder To: "Scharf, Michael" CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Message-ID: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Scharf, Michael" , Mahesh Jethanandani , Netconf , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 14:19:12 -0000 Dear Michael, please note that a configuration model for NETCONF is on the NETCONF charter for ~5 years. To establish NETCONF session, we obviously need to establish TCP connections. This is what this work does. It is entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about TCP protocol engine internals. If the TCPM chair has an issue with a generic solution to establish TCP connection not being done in TCPM, we should perhaps just hardcode how to establish TCP connections for NETCONF and RESTCONF and call it the day and then TCPM can pick up the pieces and start work on a generic solution. /js On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote: > Hi Mahesh, > > As chair of the TCPM working group, I believe that the document draft-kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group. The document is about a generic YANG model for an interface for TCP "for an SSH, TLS, or HTTP based application". I fail to see a reason why such a generic TCP model should be done in NETCONF. > > Thus, as a chair of TCPM, I object to adoption in NETCONF. > > I also want to note that it would have been possible to send a note to the TCPM list prior to starting an adoption call, as the TCPM list is monitored by many TCP implementers who could be affected by such a YANG model. YANG models can be used in different use cases. TCPM has a tradition of being very open to presentations from other working groups if they relate to TCP. I have added the TCPM list in CC. > > As an individual contributor to the IETF, I happen to be an author of draft-scharf-tcpm-yang-tcp, which actually was submitted last year. Given that different working groups seem to be involved, I believe that it would make sense to join efforts. Shouldn't we have a chat on the best next steps? > > Thanks > > Michael > > > > -----Original Message----- > > From: netconf On Behalf Of Mahesh > > Jethanandani > > Sent: Tuesday, March 26, 2019 12:17 PM > > To: Netconf > > Subject: [netconf] Adoption poll for tcp-client-server and http-client-server > > draft > > > > This is the start of a two week poll for WG adoption of the two drafts: > > > > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 > > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 > > > > Please indicate your support for or any objections you might have for > > adopting the two drafts as WG items by April 9. > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 07:52:49 2019 Return-Path: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@amazonses.watsen.net> X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10B12032C; Tue, 26 Mar 2019 07:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 iFTnC3cu4Dxs; Tue, 26 Mar 2019 07:52:45 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3BC120306; Tue, 26 Mar 2019 07:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553611963; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=BTaMq4uUMWPT9AwwnpydH7oJmQvO+zFFPzIjkYU/N/o=; b=NInVSQCDwp3js///NQRb5ZIthyKXoqKNfAQHs8tMWBVgNhaI7G8HE/eJfbpDHKFi 8Fw2OdNiG72y2splnJAXjYKbztIoPnZf2V+OV71ggwFPSkvNI1/sUcZmf/WtLFBQPtY J/1OlzGAJmkVPW5rm5+H7vPwbORYZ+gRrABhB+o8= Content-Type: multipart/alternative; boundary=Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> Date: Tue, 26 Mar 2019 14:52:42 +0000 Cc: "Scharf, Michael" , "tcpm@ietf.org" , Netconf Content-Transfer-Encoding: 7bit Message-ID: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-SES-Outgoing: 2019.03.26-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 14:52:47 -0000 --Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wait, I don=E2=80=99t think we need to do anything drastic here. Michael, please note that the TCP modules here are intended to be very limit= ed in scope, just the bare minimum necessary to support the NETCONF/RESTCONF= that (in case you don=E2=80=99t know) are layered on top of SSH and TLS, an= d hence TCP. The bare minimum appears to be just addresses, ports, and keep= -alives. The NETCONF WG has NO interest in extending this module beyond th= is minimal amount. Additionally, please see Slide 9 here [1] and note that this module is part o= f a rather large eco-system of interrelated modules. The point being is tha= t the reason for it being structured the way it is (e.g., as groupings) is p= retty well justified. My proposal is as follows: 1) Let=E2=80=99s (as co-authors) get the draft-kwatsen-netconf-tcp-client-= server-00 with it=E2=80=99s current scope to RFC status ASAP (a couple months), s= o that this five-year NETCONF project can end. Happy to tweak it as you see fit. = =20 Which WG does this is not important, but for a time-expediency perspec= tive, I recommend the NETCONF WG due to the heavy interlinking mentioned before. 2) TCPM takes over the RFC, publishing a bis with all the extra parameters= that are in draft-scharf-tcpm-yang-tcp. TCPM could even do this work= in parallel, so as to not cause any scheduling delays. Thoughts? Can we have a short-term collaboration and then let TCPM take ove= r? [1] https://datatracker.ietf.org/meeting/104/materials/slides-104-netconf-cr= ypto-types-clientserver-suite-of-drafts-00.pdf PS: Let=E2=80=99s (+ co-chairs) meet up today/tomorrow. Kent // contributor=20 > On Mar 26, 2019, at 3:19 PM, Juergen Schoenwaelder wrote: >=20 > Dear Michael, >=20 > please note that a configuration model for NETCONF is on the NETCONF > charter for ~5 years. To establish NETCONF session, we obviously need > to establish TCP connections. This is what this work does. It is > entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about > TCP protocol engine internals. If the TCPM chair has an issue with a > generic solution to establish TCP connection not being done in TCPM, > we should perhaps just hardcode how to establish TCP connections for > NETCONF and RESTCONF and call it the day and then TCPM can pick up the > pieces and start work on a generic solution. >=20 > /js >=20 >> On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote: >> Hi Mahesh, >>=20 >> As chair of the TCPM working group, I believe that the document draft-kwa= tsen-netconf-tcp-client-server-00 belongs into the TCPM working group. The d= ocument is about a generic YANG model for an interface for TCP "for an SSH, T= LS, or HTTP based application". I fail to see a reason why such a generic TC= P model should be done in NETCONF. >>=20 >> Thus, as a chair of TCPM, I object to adoption in NETCONF. >>=20 >> I also want to note that it would have been possible to send a note to th= e TCPM list prior to starting an adoption call, as the TCPM list is monitore= d by many TCP implementers who could be affected by such a YANG model. YANG m= odels can be used in different use cases. TCPM has a tradition of being very= open to presentations from other working groups if they relate to TCP. I ha= ve added the TCPM list in CC. >>=20 >> As an individual contributor to the IETF, I happen to be an author of dra= ft-scharf-tcpm-yang-tcp, which actually was submitted last year. Given that d= ifferent working groups seem to be involved, I believe that it would make se= nse to join efforts. Shouldn't we have a chat on the best next steps? >>=20 >> Thanks >>=20 >> Michael >>=20 >>=20 >>> -----Original Message----- >>> From: netconf On Behalf Of Mahesh >>> Jethanandani >>> Sent: Tuesday, March 26, 2019 12:17 PM >>> To: Netconf >>> Subject: [netconf] Adoption poll for tcp-client-server and http-client-s= erver >>> draft >>>=20 >>> This is the start of a two week poll for WG adoption of the two drafts: >>>=20 >>> https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 >>> https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 >>>=20 >>> Please indicate your support for or any objections you might have for >>> adopting the two drafts as WG items by April 9. >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Wait, I don=E2=80=99t think w= e need to do anything drastic here.

Michael, please note t= hat the TCP modules here are intended to be very limited in scope, just the b= are minimum necessary to support the NETCONF/RESTCONF that (in case you don=E2= =80=99t know) are layered on top of SSH and TLS, and hence TCP.  The ba= re minimum appears to be just addresses, ports, and keep-alives.   The N= ETCONF WG has NO interest in extending this module beyond this minimal amoun= t.

Additionally, please see Slide 9 here [1] and no= te that this module is part of a rather large eco-system of interrelated mod= ules.  The point being is that the reason for it being  structured= the way it is (e.g., as groupings) is pretty well justified.

=
My proposal is as follows:

  1) Let= =E2=80=99s (as co-authors) get the draft-kwatsen-netconf-tcp-client-server-00
    &nb= sp; with it=E2=80=99s current scope to RFC status ASAP (a couple months), so= that this
      five-year NETCONF project can end.  Happy to tw= eak it as you see fit.  
      Which WG does this is = ;not import= ant, but for a time-expediency perspective,
      I recommend t= he NET= CONF WG due to the heavy interlinking mentioned
      before.<= /span>
<= br>
  2) TCPM takes over the RFC, publishing a bis with all the extra pa= rameters
       that are in draft-scharf-tcpm-yang-tcp.  T= CPM could even do this work
       in parallel, so as to n= ot cause any scheduling delays.

Thoughts? &n= bsp;Can we have a short-term collaboration and then let TCPM take over?


=

PS: Let=E2=80=99s (+ co-chairs) meet up today/tomorrow.<= /div>

Kent // contributor 


On Mar 26, 2019, at 3:19 PM, Juergen Sc= hoenwaelder <j.sc= hoenwaelder@jacobs-university.de> wrote:

Dear Michael,

<= span>please note that a configuration model for NETCONF is on the NETCONF
charter for ~5 years. To establish NETCONF session, we obvious= ly need
to establish TCP connections. This is what this work= does. It is
entirely orthogonal to draft-scharf-tcpm-yang-t= cp, which talks about
TCP protocol engine internals. If the T= CPM chair has an issue with a
generic solution to establish T= CP connection not being done in TCPM,
we should perhaps just= hardcode how to establish TCP connections for
NETCONF and R= ESTCONF and call it the day and then TCPM can pick up the
pi= eces and start work on a generic solution.

= /js

On Tue, Mar 26, 2019 at 01:02:49PM +000= 0, Scharf, Michael wrote:
Hi Mahes= h,

As chair of the TCPM working group, I b= elieve that the document draft-kwatsen-netconf-tcp-client-server-00 belongs i= nto the TCPM working group. The document is about a generic YANG model for a= n interface for TCP "for an SSH, TLS, or HTTP based application". I fail to s= ee a reason why such a generic TCP model should be done in NETCONF.

Thus, as a chair of TCPM, I object to adoption in= NETCONF.

=
I also want to note that it wou= ld have been possible to send a note to the TCPM list prior to starting an a= doption call, as the TCPM list is monitored by many TCP implementers who cou= ld be affected by such a YANG model. YANG models can be used in different us= e cases. TCPM has a tradition of being very open to presentations from other= working groups if they relate to TCP. I have added the TCPM list in CC.

=
As an individual contributor to the IETF, I h= appen to be an author of draft-scharf-tcpm-yang-tcp, which actually was subm= itted last year. Given that different working groups seem to be involved, I b= elieve that it would make sense to join efforts. Shouldn't we have a chat on= the best next steps?

Thanks

Michael

----= -Original Message-----
From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahes= h
Jethanandani
Sent: Tuesday, March 26, 2= 019 12:17 PM
<= blockquote type=3D"cite">To: Netconf <netconf@ietf.org>
Subject: [netconf] Adoptio= n poll for tcp-client-server and http-client-server
<= /blockquote>
draft<= /span>

This is the start of a two week poll fo= r WG adoption of the two drafts:

<= /blockquote>
https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00<= /span>
https://tools.ietf.org/html/draft-kwatsen-netconf-= http-client-server-00

Please indica= te your support for or any objections you might have for
a= dopting the two drafts as WG items by April 9.

=
Mahesh Jethanandani
mjethanandani@gmail.com
=



______________________________________= _________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/= listinfo/netconf

_______= ________________________________________
netconf mailing list
netconf@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/n= etconf

--
Juergen Schoenwaelder          = ; Jacobs University Bremen gGmbH
Phone: +49 421 200 358= 7         Campus Ring 1 | 28759 Brem= en | Germany
Fax:   +49 421 200 3103   &= nbsp;     <https://www.jacobs-university.de/>
_______________________________________________
netc= onf mailing list
netconf= @ietf.org
https://www.ietf.org/mailman/listinfo/netconf
= --Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E-- From nobody Tue Mar 26 07:54:51 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D4D120369; Tue, 26 Mar 2019 07:54:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuYpFmGn6fAY; Tue, 26 Mar 2019 07:54:41 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96D8120306; Tue, 26 Mar 2019 07:54:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1C28B25A13; Tue, 26 Mar 2019 15:54:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553612079; bh=lS6RMbEAoVEk6UYXkFnHWgMAF+uIpwl/U0N70B25sgo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=X6RtOWcICsrTa/ltkV7frNcV67K4xps2+mBC9yVEKCgSDLn4SVzqLtynqT7RDOkib RsH6yLscscAMMSri0lQrQk7tj8hO9CUWoQtbDnpOzC8UDKxQRfBhmhlIvseqoeADn6 mQOjs+qclTyGRFL5iT9u5cd2XSMBREHdPOxdGEJ0= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlLl1GRGtFZd; Tue, 26 Mar 2019 15:54:37 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 15:54:37 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 15:54:37 +0100 From: "Scharf, Michael" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoA== Date: Tue, 26 Mar 2019 14:54:36 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> In-Reply-To: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 14:54:44 -0000 Hi Juergen, The document includes TCP keepalives configuration and this is actually abo= ut TCP protocol engine internals, no? And I fail to see the benefit of doing TCP YANG modeling specific to NETCON= F or RESTCONF. For instance, on a router, I believe that NETCONF, RESTCONF,= BGP and LDP could use the same TCP stack, as well as possibly all other TC= P-based protocols running on the NE. And if HTTP is included, YANG models h= ave a pretty broad applicability beyond routers. So what makes NETCONF or R= ESTCONF so special that NETCONF needs its own model? As I mentioned, in the last years TCPM has been extremely open to TCP-relat= ed needs in other working groups and we have quite successful cross-area wo= rk.=20 Michael > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, March 26, 2019 3:19 PM > To: Scharf, Michael > Cc: Mahesh Jethanandani ; Netconf > ; tcpm@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server draft >=20 > Dear Michael, >=20 > please note that a configuration model for NETCONF is on the NETCONF > charter for ~5 years. To establish NETCONF session, we obviously need > to establish TCP connections. This is what this work does. It is > entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about > TCP protocol engine internals. If the TCPM chair has an issue with a > generic solution to establish TCP connection not being done in TCPM, > we should perhaps just hardcode how to establish TCP connections for > NETCONF and RESTCONF and call it the day and then TCPM can pick up the > pieces and start work on a generic solution. >=20 > /js >=20 > On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote: > > Hi Mahesh, > > > > As chair of the TCPM working group, I believe that the document draft- > kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group. > The document is about a generic YANG model for an interface for TCP "for = an > SSH, TLS, or HTTP based application". I fail to see a reason why such a g= eneric > TCP model should be done in NETCONF. > > > > Thus, as a chair of TCPM, I object to adoption in NETCONF. > > > > I also want to note that it would have been possible to send a note to = the > TCPM list prior to starting an adoption call, as the TCPM list is monitor= ed by > many TCP implementers who could be affected by such a YANG model. > YANG models can be used in different use cases. TCPM has a tradition of > being very open to presentations from other working groups if they relate= to > TCP. I have added the TCPM list in CC. > > > > As an individual contributor to the IETF, I happen to be an author of d= raft- > scharf-tcpm-yang-tcp, which actually was submitted last year. Given that > different working groups seem to be involved, I believe that it would mak= e > sense to join efforts. Shouldn't we have a chat on the best next steps? > > > > Thanks > > > > Michael > > > > > > > -----Original Message----- > > > From: netconf On Behalf Of Mahesh > > > Jethanandani > > > Sent: Tuesday, March 26, 2019 12:17 PM > > > To: Netconf > > > Subject: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server > > > draft > > > > > > This is the start of a two week poll for WG adoption of the two draft= s: > > > > > > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-0= 0 > > > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-= 00 > > > > > > Please indicate your support for or any objections you might have for > > > adopting the two drafts as WG items by April 9. > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Mar 26 08:34:12 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844231203FB; Tue, 26 Mar 2019 08:34:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5c74ZK4NytZd; Tue, 26 Mar 2019 08:34:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708ED120435; Tue, 26 Mar 2019 08:34:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 04AA840; Tue, 26 Mar 2019 16:34:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TfI6pCJ5pcyb; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDD4A200A8; Tue, 26 Mar 2019 16:34:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id solL5DBM57iF; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7DCE0200A7; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 16:34:03 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 925F530079D64E; Tue, 26 Mar 2019 16:34:03 +0100 (CET) Date: Tue, 26 Mar 2019 16:34:03 +0100 From: Juergen Schoenwaelder To: "Scharf, Michael" CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Message-ID: <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Scharf, Michael" , Mahesh Jethanandani , Netconf , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 15:34:10 -0000 On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > Hi Juergen, > > The document includes TCP keepalives configuration and this is actually about TCP protocol engine internals, no? I think we are talking about a client or server using setsockopt() calls. This is not about globally changing TCP engine behavior. > And I fail to see the benefit of doing TCP YANG modeling specific to NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF, RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly all other TCP-based protocols running on the NE. And if HTTP is included, YANG models have a pretty broad applicability beyond routers. So what makes NETCONF or RESTCONF so special that NETCONF needs its own model? > > As I mentioned, in the last years TCPM has been extremely open to TCP-related needs in other working groups and we have quite successful cross-area work. > The models are not NETCONF/RESTCONF specific unless process forces us to make them NETCONF/RESTCONF specific. What makes NETCONF/RESTCONF special is that we started this 5 years ago. I do not care at the end who owns the document as long as process does not bring us more delay. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 08:53:53 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E037120494; Tue, 26 Mar 2019 08:53:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e99S7tO0Xxb; Tue, 26 Mar 2019 08:53:43 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2C01204A6; Tue, 26 Mar 2019 08:53:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 363E625A15; Tue, 26 Mar 2019 16:53:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553615621; bh=dscI/wWifN4+KJ1F4gIraW40RhkoAOGb6fpym7rLxAs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JqX2J6w7XKxjUydLt4vNDVwbYPjDzkgA178V/sbGPnEd6ElE7UDdlZ3F6IkoSZCyI 52SfclhlwsEddKR3i1jgGdTEyN2gRRR+1l1DvNAleHv3aRw7satADkUG8Wm8PfF5hs 5pvpc/3JabXBjGaudgQSHUq9+bK/jCQR6yx1dqhk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Doe80OWyQiH9; Tue, 26 Mar 2019 16:53:40 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 16:53:40 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 16:53:40 +0100 From: "Scharf, Michael" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoIAAAwaAgAARMKA= Date: Tue, 26 Mar 2019 15:53:39 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> In-Reply-To: <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 15:53:45 -0000 > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, March 26, 2019 4:34 PM > To: Scharf, Michael > Cc: Mahesh Jethanandani ; Netconf > ; tcpm@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server draft >=20 > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > > Hi Juergen, > > > > The document includes TCP keepalives configuration and this is actually > about TCP protocol engine internals, no? >=20 > I think we are talking about a client or server using setsockopt() > calls. This is not about globally changing TCP engine behavior. There is a grey area between setsockopt() style configuration and TCP stack= configuration. And one can easily end up in the question if other paramete= rs of the TCP stack need to be optimized in an actual NETCONF/RESTCONF impl= ementation for some reason, possibly on a per-connection basis. Then one ge= ts into details of the TCP stack. =20 > > And I fail to see the benefit of doing TCP YANG modeling specific to > NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF, > RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly a= ll > other TCP-based protocols running on the NE. And if HTTP is included, YAN= G > models have a pretty broad applicability beyond routers. So what makes > NETCONF or RESTCONF so special that NETCONF needs its own model? > > > > As I mentioned, in the last years TCPM has been extremely open to TCP- > related needs in other working groups and we have quite successful cross- > area work. > > >=20 > The models are not NETCONF/RESTCONF specific unless process forces us > to make them NETCONF/RESTCONF specific. What makes > NETCONF/RESTCONF > special is that we started this 5 years ago. I do not care at the end > who owns the document as long as process does not bring us more delay. It is reasonable to ask for a fast solution. And, well, a solution will be = actually be faster if there are no "surprises" late in the publication proc= ess. So it may be better to discuss early what the best approach would be, = and where to home what. Michael From nobody Tue Mar 26 09:10:54 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9431F120551; Tue, 26 Mar 2019 09:10:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nPELAb-I4ah1; Tue, 26 Mar 2019 09:10:43 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29C6120548; Tue, 26 Mar 2019 09:10:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1C0876F4; Tue, 26 Mar 2019 17:10:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id bIY-OCMmnclm; Tue, 26 Mar 2019 17:10:41 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 17:10:41 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03E9E200A8; Tue, 26 Mar 2019 17:10:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id b9mSItQ50v-2; Tue, 26 Mar 2019 17:10:40 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7C641200A7; Tue, 26 Mar 2019 17:10:40 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 17:10:39 +0100 Received: by anna.localdomain (Postfix, from userid 501) id A166130079D818; Tue, 26 Mar 2019 17:10:39 +0100 (CET) Date: Tue, 26 Mar 2019 17:10:39 +0100 From: Juergen Schoenwaelder To: "Scharf, Michael" CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Message-ID: <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Scharf, Michael" , Mahesh Jethanandani , Netconf , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:10:46 -0000 On Tue, Mar 26, 2019 at 03:53:39PM +0000, Scharf, Michael wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: Tuesday, March 26, 2019 4:34 PM > > To: Scharf, Michael > > Cc: Mahesh Jethanandani ; Netconf > > ; tcpm@ietf.org > > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client- > > server draft > > > > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > > > Hi Juergen, > > > > > > The document includes TCP keepalives configuration and this is actually > > about TCP protocol engine internals, no? > > > > I think we are talking about a client or server using setsockopt() > > calls. This is not about globally changing TCP engine behavior. > > There is a grey area between setsockopt() style configuration and TCP stack configuration. And one can easily end up in the question if other parameters of the TCP stack need to be optimized in an actual NETCONF/RESTCONF implementation for some reason, possibly on a per-connection basis. Then one gets into details of the TCP stack. > > > > And I fail to see the benefit of doing TCP YANG modeling specific to > > NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF, > > RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly all > > other TCP-based protocols running on the NE. And if HTTP is included, YANG > > models have a pretty broad applicability beyond routers. So what makes > > NETCONF or RESTCONF so special that NETCONF needs its own model? > > > > > > As I mentioned, in the last years TCPM has been extremely open to TCP- > > related needs in other working groups and we have quite successful cross- > > area work. > > > > > > > The models are not NETCONF/RESTCONF specific unless process forces us > > to make them NETCONF/RESTCONF specific. What makes > > NETCONF/RESTCONF > > special is that we started this 5 years ago. I do not care at the end > > who owns the document as long as process does not bring us more delay. > > It is reasonable to ask for a fast solution. And, well, a solution will be actually be faster if there are no "surprises" late in the publication process. So it may be better to discuss early what the best approach would be, and where to home what. > We had objects to configure TCP connections over which we run TLS and SSH over which we run RESTCONF and NETCONF in the making for ~5 years. And I also know RFCs that include YANG objects to establish TCP connections. Is the keep alive the reason for TCPM to claim control of this? Or the fact that we moved to more generic groupings? Anyway, I am just saying you should be aware of the history and scope of this work and then the WG chairs can settle this somehow. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 09:21:14 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D14120598; Tue, 26 Mar 2019 09:21:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTJLNnpS7svt; Tue, 26 Mar 2019 09:21:09 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D145D120582; Tue, 26 Mar 2019 09:21:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8D89D25A13; Tue, 26 Mar 2019 17:21:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553617266; bh=gL7mQybliCPIsetwd/vPs8p9LoKnyjTY32lT03TCc18=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZIyJa/U8QohJzZeTy2l/gZNa1SgIrZQTV9IacWQtZyqjjwuypDJUiDP1fkg3EcmZr qzpshzCnl5pSIbiJ0UE/v8yn+oAP2K01SqohEF24/oMDKDdBZ/wu8nb6YQoLv+M+Ig ddJymdFixqyUIp5okOTDLuMrj1iwZzvOfcNNs7wU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvr5KA60tPPa; Tue, 26 Mar 2019 17:21:05 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 17:21:05 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 17:21:04 +0100 From: "Scharf, Michael" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoIAAAwaAgAARMKD///kKgIAAETOQ Date: Tue, 26 Mar 2019 16:21:04 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D283B33@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de> In-Reply-To: <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:21:12 -0000 > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, March 26, 2019 5:11 PM > To: Scharf, Michael > Cc: Mahesh Jethanandani ; Netconf > ; tcpm@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server draft >=20 > On Tue, Mar 26, 2019 at 03:53:39PM +0000, Scharf, Michael wrote: > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: Tuesday, March 26, 2019 4:34 PM > > > To: Scharf, Michael > > > Cc: Mahesh Jethanandani ; Netconf > > > ; tcpm@ietf.org > > > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-c= lient- > > > server draft > > > > > > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > > > > Hi Juergen, > > > > > > > > The document includes TCP keepalives configuration and this is actu= ally > > > about TCP protocol engine internals, no? > > > > > > I think we are talking about a client or server using setsockopt() > > > calls. This is not about globally changing TCP engine behavior. > > > > There is a grey area between setsockopt() style configuration and TCP s= tack > configuration. And one can easily end up in the question if other paramet= ers > of the TCP stack need to be optimized in an actual NETCONF/RESTCONF > implementation for some reason, possibly on a per-connection basis. Then > one gets into details of the TCP stack. > > > > > > And I fail to see the benefit of doing TCP YANG modeling specific t= o > > > NETCONF or RESTCONF. For instance, on a router, I believe that > NETCONF, > > > RESTCONF, BGP and LDP could use the same TCP stack, as well as possib= ly > all > > > other TCP-based protocols running on the NE. And if HTTP is included, > YANG > > > models have a pretty broad applicability beyond routers. So what make= s > > > NETCONF or RESTCONF so special that NETCONF needs its own model? > > > > > > > > As I mentioned, in the last years TCPM has been extremely open to > TCP- > > > related needs in other working groups and we have quite successful > cross- > > > area work. > > > > > > > > > > The models are not NETCONF/RESTCONF specific unless process forces us > > > to make them NETCONF/RESTCONF specific. What makes > > > NETCONF/RESTCONF > > > special is that we started this 5 years ago. I do not care at the end > > > who owns the document as long as process does not bring us more delay= . > > > > It is reasonable to ask for a fast solution. And, well, a solution will= be > actually be faster if there are no "surprises" late in the publication pr= ocess. So > it may be better to discuss early what the best approach would be, and > where to home what. > > >=20 > We had objects to configure TCP connections over which we run TLS and > SSH over which we run RESTCONF and NETCONF in the making for ~5 years. > And I also know RFCs that include YANG objects to establish TCP connectio= ns. > Is the keep alive the reason for TCPM to claim control of this? Or the > fact that we moved to more generic groupings? Standardizing generic groupings including protocol-specific configuration w= ithout talking to the working group owning the protocol is probably not the= right approach - no matter what the protocol is and where it is homed in t= he IETF. As a TCPM chair, I speak up because I believe such a document needs to be r= eviewed by TCP implementers early. That expertise can be found in TCPM. Note that it is perfectly possible that the TCPM working group decides that= the specific problem at hand does not have to be solved in TCPM. We could = have discussed that yesterday in TCPM. Michael =20 > Anyway, I am just saying you should be aware of the history and scope > of this work and then the WG chairs can settle this somehow. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Mar 26 10:00:05 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13197120611 for ; Tue, 26 Mar 2019 10:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155361960306.7324.16498182740634294698.idtracker@ietfa.amsl.com> Date: Tue, 26 Mar 2019 10:00:03 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 17:00:04 -0000 Changed milestone "Submit document on TCP Control Block Interdependence to the IESG for publication as Informational RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Mar 27 03:19:22 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05C61204EF; Wed, 27 Mar 2019 03:19:16 -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 eZOCE7XCXHPl; Wed, 27 Mar 2019 03:19:13 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE07120518; Wed, 27 Mar 2019 03:19:13 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x2RAJ8fK021139; Wed, 27 Mar 2019 11:19:08 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id F23B61D53C1; Wed, 27 Mar 2019 11:19:07 +0100 (CET) Received: from 88.208.109.142 by webmail.entel.upc.edu with HTTP; Wed, 27 Mar 2019 11:19:07 +0100 Message-ID: <4d2b06be1791ac611fb200f5fc35b7e1.squirrel@webmail.entel.upc.edu> Date: Wed, 27 Mar 2019 11:19:07 +0100 From: "Carles Gomez Montenegro" To: lwip@ietf.org, tcpm@ietf.org Cc: jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 27 Mar 2019 11:19:08 +0100 (CET) Archived-At: Subject: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-06.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 10:19:21 -0000 Dear LWIG and TCPM WGs, We have just submitted a new revision (-06) of the draft referenced below. This revision incorporates the comments that we received from Stuart Cheshire. As expressed in the sessions in IETF 104, the authors believe that the document is ready for WGLC. Thanks, Carles (on behalf of all authors) ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-06.txt From: internet-drafts@ietf.org Date: Wed, March 27, 2019 11:10 am To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-06.txt Pages : 26 Date : 2019-03-27 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-06 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Wed Mar 27 07:41:06 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D8512008A; Wed, 27 Mar 2019 07:41:04 -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, 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 TexS30fmIixW; Wed, 27 Mar 2019 07:41:00 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6A12002F; Wed, 27 Mar 2019 07:40:59 -0700 (PDT) Received: from dhcp-8118.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:407f:d4ba:7a30:88bf]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 039E51B000A6; Wed, 27 Mar 2019 14:40:54 +0000 (GMT) Message-ID: <5C9B8B7E.20908@erg.abdn.ac.uk> Date: Wed, 27 Mar 2019 15:41:02 +0100 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: lwip@ietf.org CC: Carles Gomez Montenegro , tcpm@ietf.org References: <4d2b06be1791ac611fb200f5fc35b7e1.squirrel@webmail.entel.upc.edu> In-Reply-To: <4d2b06be1791ac611fb200f5fc35b7e1.squirrel@webmail.entel.upc.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [tcpm] review on the last rev of lwig-tcp-constrained-node-networks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 14:41:04 -0000 I also did a review based on the last rev of lwig-tcp-constrained-node-networks, after I saw it presented in TCPM. Gorry — 4.1.1. Maximum Segment Size (MSS) " For the sake of lightweight implementation and operation, unless applications require handling large data units (i.e. leading to an IPv6 datagram size greater than 1280 bytes), it may be desirable to limit the MTU to 1280 bytes in order to avoid the need to support Path MTU Discovery [RFC8201]." An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is assumed.) ISSUE: I think the ID should also note the minimm size for IPv4 is smaller than 1280B. —— 4.2.1. Single-MSS stacks - benefits and issues NOTE: FastRetransmit/FastRecovery reduces recovery time, so a single MSS solution relies solely on timer-based recovery. Also it later says: “A standard compliant TCP receiver will then immediately acknowledge the second segment, which can improve throughput. “ NOTE: I suggest a TCP receiver will acknowledge the second MSS of data. - The ACK_Delay paremater can also can set a bound on the time to issue the ACK. —- 4.3.1. Loss recovery and congestion/flow control "Devices that have enough memory to allow larger TCP window size can leverage a more efficient loss recovery using Fast Retransmit and Fast Recovery [RFC5681]," NOTE - insert "a" after "allow" and please define "larger” - i.e. "more than 3 MSS of data". —— Section 4.3.1. Loss recovery and congestion/flow control could usefully be cross-referenced to 4.2.1 because these are on very similar topics. — The words memory and RAM are used in various places. I think memeory is arguably a better choice of word. — “Another approach is to use long-lived TCP connections with application-layer heartbeat messages. “ - No advice on how to set and use heartbeats. is there an RFC that provides this guidance, - Is this advice any help - from RFC 8085? "NATs require a state timeout of 2 minutes or longer [RFC4787]. However, empirical evidence suggests that a significant fraction of currently deployed middleboxes unfortunately use shorter timeouts. The timeout of 15 seconds originates with the Interactive Connectivity Establishment (ICE) protocol [RFC5245]." --- On 27/03/2019, 11:19, Carles Gomez Montenegro wrote: > Dear LWIG and TCPM WGs, > > We have just submitted a new revision (-06) of the draft referenced below. > This revision incorporates the comments that we received from Stuart > Cheshire. > > As expressed in the sessions in IETF 104, the authors believe that the > document is ready for WGLC. > > Thanks, > > Carles (on behalf of all authors) > > > > ---------------------------- Original Message ---------------------------- > Subject: [Lwip] I-D Action: > draft-ietf-lwig-tcp-constrained-node-networks-06.txt > From: internet-drafts@ietf.org > Date: Wed, March 27, 2019 11:10 am > To: i-d-announce@ietf.org > Cc: lwip@ietf.org > -------------------------------------------------------------------------- > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Light-Weight Implementation Guidance WG > of the IETF. > > Title : TCP Usage Guidance in the Internet of Things (IoT) > Authors : Carles Gomez > Jon Crowcroft > Michael Scharf > Filename : draft-ietf-lwig-tcp-constrained-node-networks-06.txt > Pages : 26 > Date : 2019-03-27 > > Abstract: > This document provides guidance on how to implement and use the > Transmission Control Protocol (TCP) in Constrained-Node Networks > (CNNs), which are a characterstic of the Internet of Things (IoT). > Such environments require a lightweight TCP implementation and may > not make use of optional functionality. This document explains a > number of known and deployed techniques to simplify a TCP stack as > well as corresponding tradeoffs. The objective is to help embedded > developers with decisions on which TCP features to use. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-06 > https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Mar 29 01:59:24 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0450112015F; Fri, 29 Mar 2019 01:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJndKO_Xo8Re; Fri, 29 Mar 2019 01:59:11 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B441120026; Fri, 29 Mar 2019 01:59:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7AE1B25A1C; Fri, 29 Mar 2019 09:59:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553849948; bh=Bt3UObEVEy/qT1flteVbaf+/C8G7fPdRvxO0JlWbY/w=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lP7eHMZUzpnn8wTD9POSfQtwCfzQ6eVoeu94+rN79yBU2P/lwpM2j/jJ5eo2OjBTi wUHzM50Xv9rMy97JLXqRuSVndjui8IcdwkbQ8bAYUZapKPsxhEAo5h/RrudeyShPeP 91pdQzOa9vfnQIuT0IKhitBit5lbUli3IOYQU1pY= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWBwx1lWb3-C; Fri, 29 Mar 2019 09:59:06 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 09:59:06 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Fri, 29 Mar 2019 09:59:06 +0100 From: "Scharf, Michael" To: Kent Watsen , Juergen Schoenwaelder CC: "tcpm@ietf.org" , Netconf Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAAAllAIAEWONg Date: Fri, 29 Mar 2019 08:59:05 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28C36D@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com> In-Reply-To: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 08:59:16 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KQXMgYWxyZWFkeSBub3RlZCBkdXJpbmcgb3VyIHZlcnkgdXNlZnVsIGhhbGx3 YXkgZGlzY3Vzc2lvbiwgSSBhbSBmaW5lIHdpdGggdGhpcyBwcm9wb3NhbCAoYm90aCBhcyBjaGFp ciBhbmQgYXMgaW5kaXZpZHVhbCBjb250cmlidXRvcikuIEkgYmVsaWV2ZSB0aGF0IHRoZSBkcmFm dCBzaG91bGQgYmUgcHJlc2VudGVkIGluIFRDUE0gaW4gTW9udHJlYWwgc28gdGhhdCB0aGUgVENQ TSBjb21tdW5pdHkgY2FuIHJldmlldyB0aGUgbW9kZWwgYW5kIGRpc2N1c3MgcG90ZW50aWFsIG5l eHQgc3RlcHMuIFRoZSBUQ1BNIGNvbW11bml0eSBjYW4gdGhlbiBkZWNpZGUgZS5nLiB3aGV0aGVy IGEgam9pbnQgV0dMQyB3aWxsIGJlIHVzZWZ1bC4gQXMgdXN1YWwgaW4gVENQTSwgdGhlIGNoYWly cyB3aWxsIGNhcmVmdWxseSBsaXN0ZW4gdG8gZmVlZGJhY2sgZnJvbSBUQ1AgaW1wbGVtZW50ZXJz Lg0KDQpBcyBsb25nIGFzIHByb3BlciByZXZpZXcgYnkgVENQIGltcGxlbWVudGVycyBpcyBlbnN1 cmVkIGFuZCBhcyBsb25nIGFzIHdlIGNhbiBjb21lIHVwIHdpdGggYSBmdXR1cmUtcHJvb2Ygc29s dXRpb24sIGl0IGlzIGFjdHVhbGx5IG5vdCBpbXBvcnRhbnQgdG8gbWUgd2hpY2ggV0cgcHVibGlz aGVzIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0wMC4NCg0KSSBoYXZl IHNvbWUgdGVjaG5pY2FsIHF1ZXN0aW9ucyBvbiB0aGUgbW9kZWwgYW5kIGl0cyBzdHJ1Y3R1cmUg KGUuZy4sIHdoeSB0aGUgcGFyYW1ldGVyIOKAnGlkbGUtdGltZeKAnSBpcyBtZWFzdXJlZCBpbiBt aW51dGVzIGluc3RlYWQgb2Ygc2Vjb25kcykuIExldOKAmXMgc29ydCB0aGF0IG91dCBvZmZsaW5l Lg0KDQpUaGFua3MNCg0KTUljaGFlbA0KDQoNClBTOiBBIHBlcnNvbmFsIGNvbW1lbnQgbW9zdGx5 IHRvIHRoZSBUQ1BNIGNvbW11bml0eTogVW5mb3J0dW5hdGVseSBJIGhhdmUgbm90IGJlZW4gYXdh cmUgb2YgZHJhZnQta3dhdHNlbi1uZXRjb25mLXRjcC1jbGllbnQtc2VydmVyLTAwIHByaW9yIHRv IFR1ZXNkYXkgYW5kIHRoaXMgaXMgd2h5IEkgaGF2ZSBub3QgbWVudGlvbmVkIHRoZSBJLUQgZHVy aW5nIG15IHRhbGsgaW4gVENQTSBvbiBNb25kYXkuIEkgZm9sbG93IHF1aXRlIGEgYml0IG9mIHdv cmtpbmcgZ3JvdXBzIG91dHNpZGUgVFNWIGFyZWEsIGJ1dCBJIHdhcyBxdWl0ZSBidXN5IGluIHRo ZSB3ZWVrcyBwcmlvciB0byB0aGUgbWVldGluZyBhbmQgdGh1cyBJIG1pc3NlZCB0aGUgc3VibWlz c2lvbiBvZiB0aGlzIGRyYWZ0LiBJZiBJIGhhZCBiZWVuIGF3YXJlIG9mIHRoZSBJLUQsIEkgd291 bGQgb2J2aW91c2x5IGhhdmUgaW52aXRlZCBLZW50IHRvIHByZXNlbnQgdGhlIGRvY3VtZW50IGlu IFRDUE0gaW4gUHJhZ3VlLCBhcyBvbmUgZXhhbXBsZSBvZiBlbWVyZ2luZyBUQ1AtcmVsYXRlZCBZ QU5HIG1vZGVscyB0aGF0IFRDUE0gc2hvdWxkIHBlcmhhcHMgYmUgYXdhcmUgb2YuDQoNCg0KDQpG cm9tOiBLZW50IFdhdHNlbiA8a2VudEB3YXRzZW4ubmV0Pg0KU2VudDogVHVlc2RheSwgTWFyY2gg MjYsIDIwMTkgMzo1MyBQTQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KQ2M6IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5T Y2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgdGNwbUBpZXRmLm9yZzsgTmV0Y29uZiA8bmV0Y29uZkBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNwLWNs aWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlciBkcmFmdA0KDQoNCldhaXQsIEkgZG9u 4oCZdCB0aGluayB3ZSBuZWVkIHRvIGRvIGFueXRoaW5nIGRyYXN0aWMgaGVyZS4NCg0KTWljaGFl bCwgcGxlYXNlIG5vdGUgdGhhdCB0aGUgVENQIG1vZHVsZXMgaGVyZSBhcmUgaW50ZW5kZWQgdG8g YmUgdmVyeSBsaW1pdGVkIGluIHNjb3BlLCBqdXN0IHRoZSBiYXJlIG1pbmltdW0gbmVjZXNzYXJ5 IHRvIHN1cHBvcnQgdGhlIE5FVENPTkYvUkVTVENPTkYgdGhhdCAoaW4gY2FzZSB5b3UgZG9u4oCZ dCBrbm93KSBhcmUgbGF5ZXJlZCBvbiB0b3Agb2YgU1NIIGFuZCBUTFMsIGFuZCBoZW5jZSBUQ1Au ICBUaGUgYmFyZSBtaW5pbXVtIGFwcGVhcnMgdG8gYmUganVzdCBhZGRyZXNzZXMsIHBvcnRzLCBh bmQga2VlcC1hbGl2ZXMuICAgVGhlIE5FVENPTkYgV0cgaGFzIE5PIGludGVyZXN0IGluIGV4dGVu ZGluZyB0aGlzIG1vZHVsZSBiZXlvbmQgdGhpcyBtaW5pbWFsIGFtb3VudC4NCg0KQWRkaXRpb25h bGx5LCBwbGVhc2Ugc2VlIFNsaWRlIDkgaGVyZSBbMV0gYW5kIG5vdGUgdGhhdCB0aGlzIG1vZHVs ZSBpcyBwYXJ0IG9mIGEgcmF0aGVyIGxhcmdlIGVjby1zeXN0ZW0gb2YgaW50ZXJyZWxhdGVkIG1v ZHVsZXMuICBUaGUgcG9pbnQgYmVpbmcgaXMgdGhhdCB0aGUgcmVhc29uIGZvciBpdCBiZWluZyAg c3RydWN0dXJlZCB0aGUgd2F5IGl0IGlzIChlLmcuLCBhcyBncm91cGluZ3MpIGlzIHByZXR0eSB3 ZWxsIGp1c3RpZmllZC4NCg0KTXkgcHJvcG9zYWwgaXMgYXMgZm9sbG93czoNCg0KICAxKSBMZXTi gJlzIChhcyBjby1hdXRob3JzKSBnZXQgdGhlIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xp ZW50LXNlcnZlci0wMA0KICAgICAgd2l0aCBpdOKAmXMgY3VycmVudCBzY29wZSB0byBSRkMgc3Rh dHVzIEFTQVAgKGEgY291cGxlIG1vbnRocyksIHNvIHRoYXQgdGhpcw0KICAgICAgZml2ZS15ZWFy IE5FVENPTkYgcHJvamVjdCBjYW4gZW5kLiAgSGFwcHkgdG8gdHdlYWsgaXQgYXMgeW91IHNlZSBm aXQuDQogICAgICBXaGljaCBXRyBkb2VzIHRoaXMgaXMgbm90IGltcG9ydGFudCwgYnV0IGZvciBh IHRpbWUtZXhwZWRpZW5jeSBwZXJzcGVjdGl2ZSwNCiAgICAgIEkgcmVjb21tZW5kIHRoZSBORVRD T05GIFdHIGR1ZSB0byB0aGUgaGVhdnkgaW50ZXJsaW5raW5nIG1lbnRpb25lZA0KICAgICAgYmVm b3JlLg0KDQoNCiAgMikgVENQTSB0YWtlcyBvdmVyIHRoZSBSRkMsIHB1Ymxpc2hpbmcgYSBiaXMg d2l0aCBhbGwgdGhlIGV4dHJhIHBhcmFtZXRlcnMNCiAgICAgICB0aGF0IGFyZSBpbiBkcmFmdC1z Y2hhcmYtdGNwbS15YW5nLXRjcC4gIFRDUE0gY291bGQgZXZlbiBkbyB0aGlzIHdvcmsNCiAgICAg ICBpbiBwYXJhbGxlbCwgc28gYXMgdG8gbm90IGNhdXNlIGFueSBzY2hlZHVsaW5nIGRlbGF5cy4N Cg0KVGhvdWdodHM/ICBDYW4gd2UgaGF2ZSBhIHNob3J0LXRlcm0gY29sbGFib3JhdGlvbiBhbmQg dGhlbiBsZXQgVENQTSB0YWtlIG92ZXI/DQoNClsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9zbGlkZXMtMTA0LW5ldGNvbmYtY3J5cHRvLXR5cGVz LWNsaWVudHNlcnZlci1zdWl0ZS1vZi1kcmFmdHMtMDAucGRmDQoNCg0KUFM6IExldOKAmXMgKCsg Y28tY2hhaXJzKSBtZWV0IHVwIHRvZGF5L3RvbW9ycm93Lg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9y DQoNCg0KT24gTWFyIDI2LCAyMDE5LCBhdCAzOjE5IFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpEZWFyIE1pY2hhZWwsDQoNCnBsZWFz ZSBub3RlIHRoYXQgYSBjb25maWd1cmF0aW9uIG1vZGVsIGZvciBORVRDT05GIGlzIG9uIHRoZSBO RVRDT05GDQpjaGFydGVyIGZvciB+NSB5ZWFycy4gVG8gZXN0YWJsaXNoIE5FVENPTkYgc2Vzc2lv biwgd2Ugb2J2aW91c2x5IG5lZWQNCnRvIGVzdGFibGlzaCBUQ1AgY29ubmVjdGlvbnMuIFRoaXMg aXMgd2hhdCB0aGlzIHdvcmsgZG9lcy4gSXQgaXMNCmVudGlyZWx5IG9ydGhvZ29uYWwgdG8gZHJh ZnQtc2NoYXJmLXRjcG0teWFuZy10Y3AsIHdoaWNoIHRhbGtzIGFib3V0DQpUQ1AgcHJvdG9jb2wg ZW5naW5lIGludGVybmFscy4gSWYgdGhlIFRDUE0gY2hhaXIgaGFzIGFuIGlzc3VlIHdpdGggYQ0K Z2VuZXJpYyBzb2x1dGlvbiB0byBlc3RhYmxpc2ggVENQIGNvbm5lY3Rpb24gbm90IGJlaW5nIGRv bmUgaW4gVENQTSwNCndlIHNob3VsZCBwZXJoYXBzIGp1c3QgaGFyZGNvZGUgaG93IHRvIGVzdGFi bGlzaCBUQ1AgY29ubmVjdGlvbnMgZm9yDQpORVRDT05GIGFuZCBSRVNUQ09ORiBhbmQgY2FsbCBp dCB0aGUgZGF5IGFuZCB0aGVuIFRDUE0gY2FuIHBpY2sgdXAgdGhlDQpwaWVjZXMgYW5kIHN0YXJ0 IHdvcmsgb24gYSBnZW5lcmljIHNvbHV0aW9uLg0KDQovanMNCg0KT24gVHVlLCBNYXIgMjYsIDIw MTkgYXQgMDE6MDI6NDlQTSArMDAwMCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KDQpIaSBNYWhl c2gsDQoNCkFzIGNoYWlyIG9mIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAsIEkgYmVsaWV2ZSB0aGF0 IHRoZSBkb2N1bWVudCBkcmFmdC1rd2F0c2VuLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2ZXItMDAg YmVsb25ncyBpbnRvIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAuIFRoZSBkb2N1bWVudCBpcyBhYm91 dCBhIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgYW4gaW50ZXJmYWNlIGZvciBUQ1AgImZvciBhbiBT U0gsIFRMUywgb3IgSFRUUCBiYXNlZCBhcHBsaWNhdGlvbiIuIEkgZmFpbCB0byBzZWUgYSByZWFz b24gd2h5IHN1Y2ggYSBnZW5lcmljIFRDUCBtb2RlbCBzaG91bGQgYmUgZG9uZSBpbiBORVRDT05G Lg0KDQpUaHVzLCBhcyBhIGNoYWlyIG9mIFRDUE0sIEkgb2JqZWN0IHRvIGFkb3B0aW9uIGluIE5F VENPTkYuDQoNCkkgYWxzbyB3YW50IHRvIG5vdGUgdGhhdCBpdCB3b3VsZCBoYXZlIGJlZW4gcG9z c2libGUgdG8gc2VuZCBhIG5vdGUgdG8gdGhlIFRDUE0gbGlzdCBwcmlvciB0byBzdGFydGluZyBh biBhZG9wdGlvbiBjYWxsLCBhcyB0aGUgVENQTSBsaXN0IGlzIG1vbml0b3JlZCBieSBtYW55IFRD UCBpbXBsZW1lbnRlcnMgd2hvIGNvdWxkIGJlIGFmZmVjdGVkIGJ5IHN1Y2ggYSBZQU5HIG1vZGVs LiBZQU5HIG1vZGVscyBjYW4gYmUgdXNlZCBpbiBkaWZmZXJlbnQgdXNlIGNhc2VzLiBUQ1BNIGhh cyBhIHRyYWRpdGlvbiBvZiBiZWluZyB2ZXJ5IG9wZW4gdG8gcHJlc2VudGF0aW9ucyBmcm9tIG90 aGVyIHdvcmtpbmcgZ3JvdXBzIGlmIHRoZXkgcmVsYXRlIHRvIFRDUC4gSSBoYXZlIGFkZGVkIHRo ZSBUQ1BNIGxpc3QgaW4gQ0MuDQoNCkFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IgdG8gdGhl IElFVEYsIEkgaGFwcGVuIHRvIGJlIGFuIGF1dGhvciBvZiBkcmFmdC1zY2hhcmYtdGNwbS15YW5n LXRjcCwgd2hpY2ggYWN0dWFsbHkgd2FzIHN1Ym1pdHRlZCBsYXN0IHllYXIuIEdpdmVuIHRoYXQg ZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzIHNlZW0gdG8gYmUgaW52b2x2ZWQsIEkgYmVsaWV2ZSB0 aGF0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gam9pbiBlZmZvcnRzLiBTaG91bGRuJ3Qgd2UgaGF2 ZSBhIGNoYXQgb24gdGhlIGJlc3QgbmV4dCBzdGVwcz8NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYg T2YgTWFoZXNoDQpKZXRoYW5hbmRhbmkNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI2LCAyMDE5IDEy OjE3IFBNDQpUbzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNwLWNsaWVudC1z ZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlcg0KZHJhZnQNCg0KVGhpcyBpcyB0aGUgc3RhcnQg b2YgYSB0d28gd2VlayBwb2xsIGZvciBXRyBhZG9wdGlvbiBvZiB0aGUgdHdvIGRyYWZ0czoNCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xp ZW50LXNlcnZlci0wMA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4t bmV0Y29uZi1odHRwLWNsaWVudC1zZXJ2ZXItMDANCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgc3Vw cG9ydCBmb3Igb3IgYW55IG9iamVjdGlvbnMgeW91IG1pZ2h0IGhhdmUgZm9yDQphZG9wdGluZyB0 aGUgdHdvIGRyYWZ0cyBhcyBXRyBpdGVtcyBieSBBcHJpbCA5Lg0KDQpNYWhlc2ggSmV0aGFuYW5k YW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5j b20+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNv bmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCi0tDQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K c3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkUtTWFpbEZvcm1hdHZvcmxhZ2UxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgS2VudCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBhbHJlYWR5IG5vdGVkIGR1cmlu ZyBvdXIgdmVyeSB1c2VmdWwgaGFsbHdheSBkaXNjdXNzaW9uLCBJIGFtIGZpbmUgd2l0aCB0aGlz IHByb3Bvc2FsIChib3RoIGFzIGNoYWlyIGFuZCBhcyBpbmRpdmlkdWFsDQogY29udHJpYnV0b3Ip LiBJIGJlbGlldmUgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGJlIHByZXNlbnRlZCBpbiBUQ1BNIGlu IE1vbnRyZWFsIHNvIHRoYXQgdGhlIFRDUE0gY29tbXVuaXR5IGNhbiByZXZpZXcgdGhlIG1vZGVs IGFuZCBkaXNjdXNzIHBvdGVudGlhbCBuZXh0IHN0ZXBzLiBUaGUgVENQTSBjb21tdW5pdHkgY2Fu IHRoZW4gZGVjaWRlIGUuZy4gd2hldGhlciBhIGpvaW50IFdHTEMgd2lsbCBiZSB1c2VmdWwuIEFz IHVzdWFsIGluIFRDUE0sDQogdGhlIGNoYWlycyB3aWxsIGNhcmVmdWxseSBsaXN0ZW4gdG8gZmVl ZGJhY2sgZnJvbSBUQ1AgaW1wbGVtZW50ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBsb25nIGFzIHByb3BlciBy ZXZpZXcgYnkgVENQIGltcGxlbWVudGVycyBpcyBlbnN1cmVkIGFuZCBhcyBsb25nIGFzIHdlIGNh biBjb21lIHVwIHdpdGggYSBmdXR1cmUtcHJvb2Ygc29sdXRpb24sIGl0DQogaXMgYWN0dWFsbHkg bm90IGltcG9ydGFudCB0byBtZSB3aGljaCBXRyBwdWJsaXNoZXMgZHJhZnQta3dhdHNlbi1uZXRj b25mLXRjcC1jbGllbnQtc2VydmVyLTAwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGhhdmUgc29tZSB0ZWNobmljYWwg cXVlc3Rpb25zIG9uIHRoZSBtb2RlbCBhbmQgaXRzIHN0cnVjdHVyZSAoZS5nLiwgd2h5IHRoZSBw YXJhbWV0ZXIg4oCcaWRsZS10aW1l4oCdIGlzIG1lYXN1cmVkIGluIG1pbnV0ZXMNCiBpbnN0ZWFk IG9mIHNlY29uZHMpLiBMZXTigJlzIHNvcnQgdGhhdCBvdXQgb2ZmbGluZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhh bmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPk1JY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5QUzogQSBwZXJzb25hbCBjb21t ZW50IG1vc3RseSB0byB0aGUgVENQTSBjb21tdW5pdHk6IFVuZm9ydHVuYXRlbHkgSSBoYXZlIG5v dCBiZWVuIGF3YXJlIG9mIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0w MA0KIHByaW9yIHRvIFR1ZXNkYXkgYW5kIHRoaXMgaXMgd2h5IEkgaGF2ZSBub3QgbWVudGlvbmVk IHRoZSBJLUQgZHVyaW5nIG15IHRhbGsgaW4gVENQTSBvbiBNb25kYXkuIEkgZm9sbG93IHF1aXRl IGEgYml0IG9mIHdvcmtpbmcgZ3JvdXBzIG91dHNpZGUgVFNWIGFyZWEsIGJ1dCBJIHdhcyBxdWl0 ZSBidXN5IGluIHRoZSB3ZWVrcyBwcmlvciB0byB0aGUgbWVldGluZyBhbmQgdGh1cyBJIG1pc3Nl ZCB0aGUgc3VibWlzc2lvbiBvZiB0aGlzIGRyYWZ0Lg0KIElmIEkgaGFkIGJlZW4gYXdhcmUgb2Yg dGhlIEktRCwgSSB3b3VsZCBvYnZpb3VzbHkgaGF2ZSBpbnZpdGVkIEtlbnQgdG8gcHJlc2VudCB0 aGUgZG9jdW1lbnQgaW4gVENQTSBpbiBQcmFndWUsIGFzIG9uZSBleGFtcGxlIG9mIGVtZXJnaW5n IFRDUC1yZWxhdGVkIFlBTkcgbW9kZWxzIHRoYXQgVENQTSBzaG91bGQgcGVyaGFwcyBiZSBhd2Fy ZSBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEtlbnQgV2F0c2VuICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7DQo8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMjYsIDIwMTkgMzo1MyBQTTxicj4NCjxiPlRv OjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTY2hhcmYsIE1pY2hhZWwgJmx0O01pY2hh ZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSZndDs7IHRjcG1AaWV0Zi5vcmc7IE5ldGNvbmYgJmx0 O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0g QWRvcHRpb24gcG9sbCBmb3IgdGNwLWNsaWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZl ciBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2FpdCwgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gZG8gYW55dGhpbmcgZHJhc3RpYyBoZXJl LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWljaGFlbCwg cGxlYXNlIG5vdGUgdGhhdCB0aGUgVENQIG1vZHVsZXMgaGVyZSBhcmUgaW50ZW5kZWQgdG8gYmUg dmVyeSBsaW1pdGVkIGluIHNjb3BlLCBqdXN0IHRoZSBiYXJlIG1pbmltdW0gbmVjZXNzYXJ5IHRv IHN1cHBvcnQgdGhlIE5FVENPTkYvUkVTVENPTkYgdGhhdCAoaW4gY2FzZSB5b3UgZG9u4oCZdCBr bm93KSBhcmUgbGF5ZXJlZCBvbiB0b3Agb2YgU1NIIGFuZCBUTFMsIGFuZCBoZW5jZSBUQ1AuICZu YnNwO1RoZQ0KIGJhcmUgbWluaW11bSBhcHBlYXJzIHRvIGJlIGp1c3QgYWRkcmVzc2VzLCBwb3J0 cywgYW5kIGtlZXAtYWxpdmVzLiAmbmJzcDsgVGhlIE5FVENPTkYgV0cgaGFzIE5PIGludGVyZXN0 IGluIGV4dGVuZGluZyB0aGlzIG1vZHVsZSBiZXlvbmQgdGhpcyBtaW5pbWFsIGFtb3VudC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRp b25hbGx5LCBwbGVhc2Ugc2VlIFNsaWRlIDkgaGVyZSBbMV0gYW5kIG5vdGUgdGhhdCB0aGlzIG1v ZHVsZSBpcyBwYXJ0IG9mIGEgcmF0aGVyIGxhcmdlIGVjby1zeXN0ZW0gb2YgaW50ZXJyZWxhdGVk IG1vZHVsZXMuICZuYnNwO1RoZSBwb2ludCBiZWluZyBpcyB0aGF0IHRoZSByZWFzb24gZm9yIGl0 IGJlaW5nICZuYnNwO3N0cnVjdHVyZWQgdGhlIHdheSBpdCBpcyAoZS5nLiwgYXMgZ3JvdXBpbmdz KSBpcyBwcmV0dHkNCiB3ZWxsIGp1c3RpZmllZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcHJvcG9zYWwgaXMgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IDEpIExldOKAmXMgKGFzIGNvLWF1dGhvcnMpIGdldCB0aGUgZHJhZnQta3dhdHNlbi1uZXRjb25m LXRjcC1jbGllbnQtc2VydmVyLTAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIGl04oCZcyBjdXJyZW50 IHNjb3BlIHRvIFJGQyBzdGF0dXMgQVNBUCAoYSBjb3VwbGUgbW9udGhzKSwgc28gdGhhdCB0aGlz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyBmaXZlLXllYXIgTkVUQ09ORiZuYnNwO3Byb2plY3QgY2FuIGVuZC4g Jm5ic3A7SGFwcHkgdG8gdHdlYWsgaXQgYXMgeW91IHNlZSBmaXQuICZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgV2hpY2ggV0cgZG9lcyB0aGlzIGlzJm5ic3A7bm90IGltcG9ydGFudCwgYnV0IGZvciBh IHRpbWUtZXhwZWRpZW5jeSBwZXJzcGVjdGl2ZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEkgcmVjb21tZW5k IHRoZSZuYnNwO05FVENPTkYgV0cgZHVlIHRvIHRoZSBoZWF2eSBpbnRlcmxpbmtpbmcgbWVudGlv bmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyBiZWZvcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAyKSBUQ1BNIHRha2VzIG92ZXIg dGhlIFJGQywgcHVibGlzaGluZyBhIGJpcyB3aXRoIGFsbCB0aGUgZXh0cmEgcGFyYW1ldGVyczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBhcmUgaW4mbmJzcDtkcmFmdC1zY2hhcmYtdGNwbS15 YW5nLXRjcC4gJm5ic3A7VENQTSBjb3VsZCBldmVuIGRvIHRoaXMgd29yazxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aW4gcGFyYWxsZWwsIHNvIGFzIHRvIG5vdCBjYXVzZSBhbnkgc2NoZWR1bGluZyBk ZWxheXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRob3VnaHRzPyAmbmJzcDtDYW4gd2UgaGF2ZSBhIHNob3J0LXRlcm0gY29sbGFib3JhdGlv biBhbmQgdGhlbiBsZXQgVENQTSB0YWtlIG92ZXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQtbmV0Y29u Zi1jcnlwdG8tdHlwZXMtY2xpZW50c2VydmVyLXN1aXRlLW9mLWRyYWZ0cy0wMC5wZGYiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQt bmV0Y29uZi1jcnlwdG8tdHlwZXMtY2xpZW50c2VydmVyLXN1aXRlLW9mLWRyYWZ0cy0wMC5wZGY8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UFM6IExldOKAmXMgKCYjNDM7IGNvLWNoYWlycykgbWVldCB1cCB0b2RheS90b21vcnJvdy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2Vu dCAvLyBjb250cmlidXRvciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gTWFyIDI2LCAyMDE5LCBhdCAzOjE5IFBNLCBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E ZWFyIE1pY2hhZWwsPGJyPg0KPGJyPg0KcGxlYXNlIG5vdGUgdGhhdCBhIGNvbmZpZ3VyYXRpb24g bW9kZWwgZm9yIE5FVENPTkYgaXMgb24gdGhlIE5FVENPTkY8YnI+DQpjaGFydGVyIGZvciB+NSB5 ZWFycy4gVG8gZXN0YWJsaXNoIE5FVENPTkYgc2Vzc2lvbiwgd2Ugb2J2aW91c2x5IG5lZWQ8YnI+ DQp0byBlc3RhYmxpc2ggVENQIGNvbm5lY3Rpb25zLiBUaGlzIGlzIHdoYXQgdGhpcyB3b3JrIGRv ZXMuIEl0IGlzPGJyPg0KZW50aXJlbHkgb3J0aG9nb25hbCB0byBkcmFmdC1zY2hhcmYtdGNwbS15 YW5nLXRjcCwgd2hpY2ggdGFsa3MgYWJvdXQ8YnI+DQpUQ1AgcHJvdG9jb2wgZW5naW5lIGludGVy bmFscy4gSWYgdGhlIFRDUE0gY2hhaXIgaGFzIGFuIGlzc3VlIHdpdGggYTxicj4NCmdlbmVyaWMg c29sdXRpb24gdG8gZXN0YWJsaXNoIFRDUCBjb25uZWN0aW9uIG5vdCBiZWluZyBkb25lIGluIFRD UE0sPGJyPg0Kd2Ugc2hvdWxkIHBlcmhhcHMganVzdCBoYXJkY29kZSBob3cgdG8gZXN0YWJsaXNo IFRDUCBjb25uZWN0aW9ucyBmb3I8YnI+DQpORVRDT05GIGFuZCBSRVNUQ09ORiBhbmQgY2FsbCBp dCB0aGUgZGF5IGFuZCB0aGVuIFRDUE0gY2FuIHBpY2sgdXAgdGhlPGJyPg0KcGllY2VzIGFuZCBz dGFydCB3b3JrIG9uIGEgZ2VuZXJpYyBzb2x1dGlvbi48YnI+DQo8YnI+DQovanM8YnI+DQo8YnI+ DQpPbiBUdWUsIE1hciAyNiwgMjAxOSBhdCAwMTowMjo0OVBNICYjNDM7MDAwMCwgU2NoYXJmLCBN aWNoYWVsIHdyb3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBNYWhlc2gsPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBjaGFpciBvZiB0aGUgVENQTSB3b3JraW5nIGdyb3VwLCBJ IGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgZHJhZnQta3dhdHNlbi1uZXRjb25mLXRjcC1jbGll bnQtc2VydmVyLTAwIGJlbG9uZ3MgaW50byB0aGUgVENQTSB3b3JraW5nIGdyb3VwLiBUaGUgZG9j dW1lbnQgaXMgYWJvdXQgYSBnZW5lcmljIFlBTkcgbW9kZWwgZm9yIGFuIGludGVyZmFjZSBmb3Ig VENQICZxdW90O2ZvciBhbiBTU0gsIFRMUywgb3IgSFRUUA0KIGJhc2VkIGFwcGxpY2F0aW9uJnF1 b3Q7LiBJIGZhaWwgdG8gc2VlIGEgcmVhc29uIHdoeSBzdWNoIGEgZ2VuZXJpYyBUQ1AgbW9kZWwg c2hvdWxkIGJlIGRvbmUgaW4gTkVUQ09ORi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodXMsIGFzIGEgY2hhaXIgb2YgVENQTSwgSSBv YmplY3QgdG8gYWRvcHRpb24gaW4gTkVUQ09ORi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB3YW50IHRvIG5vdGUgdGhhdCBp dCB3b3VsZCBoYXZlIGJlZW4gcG9zc2libGUgdG8gc2VuZCBhIG5vdGUgdG8gdGhlIFRDUE0gbGlz dCBwcmlvciB0byBzdGFydGluZyBhbiBhZG9wdGlvbiBjYWxsLCBhcyB0aGUgVENQTSBsaXN0IGlz IG1vbml0b3JlZCBieSBtYW55IFRDUCBpbXBsZW1lbnRlcnMgd2hvIGNvdWxkIGJlIGFmZmVjdGVk IGJ5IHN1Y2ggYSBZQU5HIG1vZGVsLiBZQU5HIG1vZGVscyBjYW4NCiBiZSB1c2VkIGluIGRpZmZl cmVudCB1c2UgY2FzZXMuIFRDUE0gaGFzIGEgdHJhZGl0aW9uIG9mIGJlaW5nIHZlcnkgb3BlbiB0 byBwcmVzZW50YXRpb25zIGZyb20gb3RoZXIgd29ya2luZyBncm91cHMgaWYgdGhleSByZWxhdGUg dG8gVENQLiBJIGhhdmUgYWRkZWQgdGhlIFRDUE0gbGlzdCBpbiBDQy48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGFuIGluZGl2aWR1 YWwgY29udHJpYnV0b3IgdG8gdGhlIElFVEYsIEkgaGFwcGVuIHRvIGJlIGFuIGF1dGhvciBvZiBk cmFmdC1zY2hhcmYtdGNwbS15YW5nLXRjcCwgd2hpY2ggYWN0dWFsbHkgd2FzIHN1Ym1pdHRlZCBs YXN0IHllYXIuIEdpdmVuIHRoYXQgZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzIHNlZW0gdG8gYmUg aW52b2x2ZWQsIEkgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gam9pbg0KIGVm Zm9ydHMuIFNob3VsZG4ndCB3ZSBoYXZlIGEgY2hhdCBvbiB0aGUgYmVzdCBuZXh0IHN0ZXBzPzxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NaWNoYWVsPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZyb206IG5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBN YWhlc2g8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50OiBUdWVz ZGF5LCBNYXJjaCAyNiwgMjAxOSAxMjoxNyBQTTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvOiBOZXRjb25mICZs dDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4m Z3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogW25ldGNvbmZdIEFkb3B0aW9uIHBvbGwgZm9yIHRj cC1jbGllbnQtc2VydmVyIGFuZCBodHRwLWNsaWVudC1zZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFm dDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhlIHN0YXJ0IG9m IGEgdHdvIHdlZWsgcG9sbCBmb3IgV0cgYWRvcHRpb24gb2YgdGhlIHR3byBkcmFmdHM6PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0wMCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50 LXNlcnZlci0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRjb25mLWh0dHAtY2xpZW50LXNlcnZlci0wMCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi1odHRwLWNsaWVu dC1zZXJ2ZXItMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNl IGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3Igb3IgYW55IG9iamVjdGlvbnMgeW91IG1pZ2h0IGhh dmUgZm9yPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YWRvcHRpbmcgdGhlIHR3byBkcmFmdHMgYXMgV0cgaXRlbXMg YnkgQXByaWwgOS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWhlc2ggSmV0 aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPm5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm5l dGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5uZXRjb25mIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLSA8 YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH bWJIPGJyPg0KUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4g fCBHZXJtYW55PGJyPg0KRmF4OiAmbmJzcDsmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0i aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5odHRwczovL3d3dy5qYWNvYnMtdW5p dmVyc2l0eS5kZS88L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_-- From nobody Fri Mar 29 12:28:25 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDBB1202C4; Fri, 29 Mar 2019 12:28:23 -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 6mnkLVy8bav1; Fri, 29 Mar 2019 12:28:20 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498BF120004; Fri, 29 Mar 2019 12:28:20 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x2TJSCmN065196; Fri, 29 Mar 2019 20:28:12 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4B5341D53C1; Fri, 29 Mar 2019 20:28:12 +0100 (CET) Received: from 90.205.25.232 by webmail.entel.upc.edu with HTTP; Fri, 29 Mar 2019 20:28:12 +0100 Message-ID: Date: Fri, 29 Mar 2019 20:28:12 +0100 From: "Carles Gomez Montenegro" To: lwip@ietf.org, tcpm@ietf.org Cc: gorry@erg.abdn.ac.uk, jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at dash X-Virus-Status: Clean X-Greylist: Delayed for 57:09:04 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 29 Mar 2019 20:28:13 +0100 (CET) Archived-At: Subject: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-07.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 19:28:23 -0000 Dear all, Please find below a new revision (-07) of the draft entitled "TCP Usage Guidance in the Internet of Things (IoT)". The updates in this revision are intended to address the comments and incorporate the suggestions kindly provided by Gorry Fairhurst. @Gorry: thank you very much for taking the time to review the draft. Cheers, Carles (on behalf of all authors) ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-07.txt From: internet-drafts@ietf.org Date: Fri, March 29, 2019 8:17 pm To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-07.txt Pages : 27 Date : 2019-03-29 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-07 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-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/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip