From nobody Mon Jul 1 03:09: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 20F81120077; Mon, 1 Jul 2019 03:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiqKOorAyX1e; Mon, 1 Jul 2019 03:08:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A89312001A; Mon, 1 Jul 2019 03:08:56 -0700 (PDT) Received: from tpw09926dag17h.domain1.systemhost.net (10.9.212.41) by RDW083A012ED68.bt.com (10.187.98.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 1 Jul 2019 11:04:44 +0100 Received: from tpw09926dag10h.domain1.systemhost.net (10.9.202.49) by tpw09926dag17h.domain1.systemhost.net (10.9.212.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Jul 2019 11:05:02 +0100 Received: from bwp09926079.bt.com (10.36.82.110) by tpw09926dag10h.domain1.systemhost.net (10.9.202.49) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 1 Jul 2019 11:05:02 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.57) by smtpe1.intersmtp.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Mon, 1 Jul 2019 11:04:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3YNY+F73WTIwv9SH5pN5s6T31ZLheM8hK0Rqh/Gr/wU=; b=fzVihgavKbnQV1k9mni87krxUV4YJDhDnTRGjFALiknMRhShresS3OhK17h5wAaiQSpBWKDEafuWEObouoIz+tQ52OHawzpbsgLn0bc3PMkb15AhKtWk9ysTdsq11hlSd/zkUZmomoRzzkITTZGTElVL47/wrnkRQbjZUoP+waA= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB2042.GBRP123.PROD.OUTLOOK.COM (20.179.128.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Mon, 1 Jul 2019 10:04:14 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2032.019; Mon, 1 Jul 2019 10:04:13 +0000 From: To: , , CC: Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwAMW68XA= Date: Mon, 1 Jul 2019 10:04:13 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea70716b-36ea-4f75-9552-08d6fe0b7885 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2042; x-ms-traffictypediagnostic: LNXP123MB2042: x-ms-exchange-purlcount: 2 x-antispam-2: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(136003)(376002)(39860400002)(13464003)(54534003)(199004)(189003)(53754006)(76176011)(8936002)(102836004)(6506007)(53546011)(966005)(52536014)(4326008)(25786009)(186003)(5660300002)(14454004)(68736007)(476003)(11346002)(486006)(26005)(110136005)(6116002)(2906002)(446003)(316002)(3846002)(99286004)(7696005)(76116006)(66476007)(66066001)(66946007)(73956011)(66556008)(55016002)(66446008)(64756008)(33656002)(7736002)(6246003)(74316002)(14444005)(256004)(2201001)(478600001)(86362001)(305945005)(53936002)(9686003)(2501003)(81166006)(81156014)(229853002)(71190400001)(6436002)(71200400001)(6306002)(66574012)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2042; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: F6j/8IOOfoFcZ4MevMKITl4gJ5I/NYMJlwn33Uz22K/bmMigXTKC9UiMwYZrgPLuJlqnB4pKROMjPB2hb6aG2A/E3gJqc26I86ACMUDfWSxqwiFSW5Nz0EiRR8WtEZlV0HM0N8YwEqLEiEPzc5FdzFQhp8hC5nHGgyDkS9NANH5CFFC/c+W03Adx7SwT/cPN826iuQSUKK4yfbxXWj8UF2D3pFD+DSDsD86o5D4jJLVokBIrT/LEMT55w7gRKjxDU36RaRPox7nvVRmgU6TZ8Ou5VRYqMWcwFEoDp6JooFZONHhlKTx7kUk0TZ5lNngJmh/j59GOhTS+Yu05sHz0MK0cCcQXHyrxGb3lBF+zPlr8H562FE1OGVpqTYlZzMpILhp758UJyvnsMgu6lrDFBg/Y9VlX33o4WecQ+0vXQYo= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ea70716b-36ea-4f75-9552-08d6fe0b7885 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2019 10:04:13.8830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2042 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 10:09:00 -0000 Finishing my review... Section 4.2.8 Error TLV Resource exceeded & Network failure " The Transport Converter may indicate in the Value field the suggested delay (in seconds) that the Client SHOULD wait before soliciting the Transport Converter for a new proxied connection. A Value of zero corresponds to a default delay of at least 30 seconds." Are there any circumstances in which a Transport Converter may want to sugg= est that the Client waits less than one second before re-trying? Section 7.5 Multipath TCP-specific Considerations " aggregation service" -> multipath TCP converter service? " This method does not require any interaction with the Transport Converter." [twice] You could say interaction of what (since something is interacting with it!) Section 8 IANA Considerations Convert TLVs=20 It has a range assigned via IETF review, a range assigned via Specification= required and a range for Private use. Wouldn't it be simpler to choose eit= her IETF review or Specification required (plus private use)? I think Speci= fication required would be ok, given the RFC will be Experimental. Convert Error Messages It has a range assigned via IETF review and a range assigned via Specificat= ion required.=20 Same comment as above, except more strongly - for error messages, IETF revi= ew seems excessive to me. Also, would it be useful to have some space for Private use? Section 11 Example Socket API Changes to Support the 0-RTT Convert Protocol " As an example, on Linux, a client can send the 0-RTT Convert message inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in the example below" Is this example right? Since Transport Converter now uses TLV messages rath= er than TFO? Section 12 " A recently proposed extension to SOCKS also leverages the TFO option" I think "also" should be deleted (since Transport Converter now uses TLV me= ssages rather than TFO) Section 13 [RFC6824] Would be good to update to the bis document (which has currently completed = IESG - I think waiting for AD follow-up) Thanks - best wishes, phil -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 27 June 2019 16:58 To: Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 I support this document. Thanks to the authors for the nice work.=20 Here are some comments /questions and suggested clarifications. Questions: Section 4.1 " The Client and the Transport Converter MUST send the fixed-sized header, shown in Figure 9, as the first four bytes of the bytestream." Are there any other protocols that claim rights on the first bytes of the b= ytestream? Even in the context of signalling as indicated by the port# (to = be assigned), is this certain? " Data added by the Convert protocol to the TCP bytestream in the upstream connection is unambiguously distinguished from payload data in the downstream connection by the Total Length field in the Convert messages." Is it required that the Convert data is at a fixed point in the bytestream?= Think you've assumed it's at the start? (Also, I think you could delete 'upstream' and 'downstream' in the quoted s= entence - in any case, presumably they should both be one or the other) Convert protocol: How do the messages with the Supported TCP Extensions TLV and Connect TLV r= elate to each other? Is it required to learn through the "Supported TCP Ext= ensions" that a Converter supports a particular TCP option before sending a= Connect with that Option? I assume not - and that it's just a MAY to send = the Supported TCP Extensions - as it seems to me like an optimisation and n= ot too much harm happens if you send a Connect for an unsupported extension= .=20 -------------- Suggested clarifications - significant:- I think it would be great if Section 3 was expanded into a "protocol model"= https://tools.ietf.org/html/rfc4101 in particular to expand on << 2. What messages are being transmitted and what do they mean?>> - figu= res show the basic msg exchanges (info, connect, extended, supported, cooki= e and error) << 3. What are the important, but unobvious, features of the protocol?>> = eg use of assigned port# ; use of first bytes of bytestream ;etc. I think you could distinguish more carefully between: the initiator of the = TCP convert protocol and the other 'legacy' end point versus the end device= downstream on a broadband line and the server upstream in the internet. Th= e language of the doc basically assumes that a "Client" fulfils both the fi= rst roles and a "Server" fulfils both the last roles, but this needs not al= ways be the case. I realised this reading Section 4.2.8, but I suspect it's= true in many other places.=20 ---------------- Suggested clarifications - other:- Section 1: Para " There are some situations..." I think you could slightly adjust the = mention of PEPs. For example, a PEP that re-spaces TCP ACKs doesn't have an= ything to do with the problem mentioned in the first part of the para (abou= t the difficulty of ensuring both clients and servers are upgraded) Para " More recently, experimentation" I found the first sentence hard to p= arse. The para seems to use latency to refer to two things (without pointin= g this out): packet forwarding latency and set-up signalling latency List of bullets about what a transport converter achieves. I 'd add one to = say it achieves 0-RTT - and to explain what 0-RTT means (quite a bit later = before the reader discovers this) (and expand the RTT abbreviation) Section 3: Figure 2: explain "R" " Further, the architecture allows for making use of new TCP extensions even if those are not supported by a given server." I find the sentence a bit awkward. Maybe: Further, the architecture enables= the use of new TCP extensions between the client and Transport Converter w= hen they are not supported by a server. Figure 3: I didn't understand why the note is needed "* TLS messages exhang= ed between the Client and the Server are not shown." Para under figure 3: This mentions Connect TLVs, which is a mystery concept= at this stage.=20 Section 1 mostly says TCP extensions, with an occasional TCP options. Be co= nsistent? Section 3.2: Figure 5: in the figure title there's "(1)" - what does this mean or is it = a typo? Para " A Transport Converter MAY operate" "external address" - what does 'external' mean? Section 4 Should there be a new Section 4.1 that explains the use of port # (to be as= signed) to identify Convert protocol messages? S4.1 title "fixed header" - is "fixed" needed? Figure 10: I think the first "(optional)" should be deleted (ie in bytes 3 & 4) " In general zero padding MUST be added if the value's length in bytes can not be expressed as 2+(4 * n)." better, something like: If necessary, Value MUST be padded with zeroes so t= hat the length of the TLV is a multiple of 32 bits. " As a general rule, when an error is encountered an Error TLV with the appropriate error code MUST be returned by the Transport Converter." 'As a general rule' seems to conflict with 'MUST' " Transport Converter SHOULD include in this list the TCP options that it accepts from Clients and that it includes the SYN packets that it sends to initiate connections." I couldn't parse the second part of the sentence ("and that it...") " The list of Supported TCP Extension is padded with 0 to end on a 32 bits boundary." Replace: The list of Supported TCP Extensions MUST be padded with 0 to end = on a 32 bits boundary. Section 6 This section actually only discusses one type of middlebox (removes SYN). C= an the discussion be widened slightly - or maybe simply say that if middleb= ox interference detected, then MUST stop using the Converter (with SYN remo= val given as an example)? Not yet read Section 7 onwards, comments to follow. Section 10 Change log There's lots of really useful info about why the design is as it is (eg the= use of TLV rather than Options). It would be a shame if this was lost from= the rfc - please can info be extracted into a section "how implementation = experiences have influenced design decisions" or similar? Thanks phil -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael Sent: 25 June 2019 17:39 To: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08 Hi all, draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***. Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is e= xperimental. Thanks a lot Michael (TCPM co-chair)=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 2 00:24: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 793B71201D7 for ; Tue, 2 Jul 2019 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 cbW3mKrK93iy for ; Tue, 2 Jul 2019 00:24:52 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8F61200B3 for ; Tue, 2 Jul 2019 00:24:51 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x627OkOM019389; Tue, 2 Jul 2019 09:24:47 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id C01931D53C1; Tue, 2 Jul 2019 09:24:46 +0200 (CEST) Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Tue, 2 Jul 2019 09:24:46 +0200 Message-ID: Date: Tue, 2 Jul 2019 09:24:46 +0200 From: "Carles Gomez Montenegro" To: 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 violet X-Virus-Status: Clean X-Greylist: Delayed for 116:31:58 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 02 Jul 2019 09:24:47 +0200 (CEST) Archived-At: Subject: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 07:24:55 -0000 Dear WG, Please find below the pointers to a new Internet Draft that describes a simple "ACK Pull" mechanism, intended to improve performance in a number of scenarios / use cases. Comments are very much welcome. Thanks, Carles and Jon ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt From: internet-drafts@ietf.org Date: Mon, July 1, 2019 5:08 pm To: "Jon Crowcroft" "Carles Gomez" -------------------------------------------------------------------------- A new version of I-D, draft-gomez-tcpm-ack-pull-00.txt has been successfully submitted by Carles Gomez and posted to the IETF repository. Name: draft-gomez-tcpm-ack-pull Revision: 00 Title: TCP ACK Pull Document date: 2019-07-01 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gomez-tcpm-ack-pull-00.txt Status: https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/ Htmlized: https://tools.ietf.org/html/draft-gomez-tcpm-ack-pull-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-pull Abstract: Delayed Acknowledgments (ACKs) allow reducing protocol overhead in many scenarios. However, in some cases, Delayed ACKs may significantly degrade network and device performance in terms of link utilization, latency, memory usage and/or energy consumption. This document defines the TCP ACK Pull (AKP) mechanism, which allows a sender to request the ACK for a data segment to be sent without additional delay by the receiver. AKP makes use of one of the reserved bits in the TCP header, which is defined in this specification as the AKP flag. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jul 2 02:05:28 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7AC120047; Tue, 2 Jul 2019 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6DNiymDe3Sl; Tue, 2 Jul 2019 02:05:25 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.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 26D01120043; Tue, 2 Jul 2019 02:05:25 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45dJH71Jxjz205x; Tue, 2 Jul 2019 11:05:23 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 45dJH70Gpfz8sYK; Tue, 2 Jul 2019 11:05:23 +0200 (CEST) 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.0439.000; Tue, 2 Jul 2019 11:05:22 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwAMW68XAAMI3dUA== Date: Tue, 2 Jul 2019 09:05:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAB0E38@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 09:05:27 -0000 Hi Phil, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > philip.eardley@bt.com > Envoy=E9=A0: lundi 1 juillet 2019 12:04 > =C0=A0: philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; tcpm@ietf.= org > Cc=A0: tcpm-chairs@ietf.org > Objet=A0: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 >=20 > Finishing my review... >=20 > Section 4.2.8 Error TLV > Resource exceeded & Network failure > " The > Transport Converter may indicate in the Value field the suggested > delay (in seconds) that the Client SHOULD wait before soliciting > the Transport Converter for a new proxied connection. A Value of > zero corresponds to a default delay of at least 30 seconds." > Are there any circumstances in which a Transport Converter may want to > suggest that the Client waits less than one second before re-trying? [Med] The errors we identified so far do not have such requirements.=20 >=20 > Section 7.5 Multipath TCP-specific Considerations > " aggregation service" -> multipath TCP converter service? [Med] OK. >=20 > " This method does not require any interaction > with the Transport Converter." [twice] > You could say interaction of what (since something is interacting with > it!) [Med] added "... for authorization matters." >=20 > Section 8 IANA Considerations > Convert TLVs > It has a range assigned via IETF review, a range assigned via > Specification required and a range for Private use. Wouldn't it be simple= r > to choose either IETF review or Specification required (plus private use)= ? > I think Specification required would be ok, given the RFC will be > Experimental. [Med] We are simplifying the assignment for some code points while allowing= for a range to be reserved to key extensions. This is simple compared to "= Standards Action" I have seen in some experimental RFCs!=20 >=20 > Convert Error Messages > It has a range assigned via IETF review and a range assigned via > Specification required. > Same comment as above, except more strongly - for error messages, IETF > review seems excessive to me. [Med] Why? The same considerations (interoperability) apply for the error c= odes and TLVs. =20 > Also, would it be useful to have some space for Private use? [Med] Makes sense.=20 >=20 > Section 11 Example Socket API Changes to Support the 0-RTT Convert > Protocol > " As an example, on Linux, a client can send the 0-RTT Convert message > inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in > the example below" > Is this example right? [Med] Yes.=20 Since Transport Converter now uses TLV messages > rather than TFO? [Med] This is about the control flags.=20 >=20 > Section 12 > " A recently > proposed extension to SOCKS also leverages the TFO option" > I think "also" should be deleted (since Transport Converter now uses TLV > messages rather than TFO) [Med] OK. >=20 > Section 13 > [RFC6824] > Would be good to update to the bis document (which has currently complete= d > IESG - I think waiting for AD follow-up) [Med] Will consider this once the bis is sent to the RFC editor.=20 FWIW, the changes to address this review can be seen at: https://github.com= /obonaventure/draft-tcp-converters/pull/65/files=20 >=20 > Thanks - best wishes, > phil From nobody Fri Jul 5 02:04:09 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E001200A1; Fri, 5 Jul 2019 02:04:07 -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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Ky6m5sDq9ils; Fri, 5 Jul 2019 02:04:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.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 2C40B1200CE; Fri, 5 Jul 2019 02:04:05 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45g86B6Rdpz2y79; Fri, 5 Jul 2019 11:04:02 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 45g86B5CmPz2xCr; Fri, 5 Jul 2019 11:04:02 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 5 Jul 2019 11:04:02 +0200 From: To: "Scharf, Michael" , "draft-ietf-tcpm-converters@ietf.org" CC: "tcpm@ietf.org Extensions" Thread-Topic: IPR poll for draft-ietf-tcpm-converters Thread-Index: AQHVLnIDTXNv04YI7U2lMwCokCEJ6Ka7w4zw Date: Fri, 5 Jul 2019 09:04:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAC103F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D366722@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.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EAC103FOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] IPR poll for draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 09:04:08 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EAC103FOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, I am not aware of any undisclosed IPR relevant to this document. Cheers, Med De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] Envoy=E9 : samedi 29 juin 2019 13:59 =C0 : draft-ietf-tcpm-converters@ietf.org Cc : tcpm@ietf.org Extensions Objet : IPR poll for draft-ietf-tcpm-converters Dear authors, The document shepherd has to ensure compliance with the IPR guidelines of t= he IETF. Can each author please confirm that their direct, personal knowledge of any= IPR related to this document has already been disclosed, in conformance wi= th BCPs 78 and 79? Note that an answer is required from all authors of the document. The TCPM = lists is added in CC for the sake of transparency. Thanks Michael Von: Scharf, Michael Gesendet: Dienstag, 25. Juni 2019 18:39 An: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org Betreff: WGLC for draft-ietf-tcpm-converters-08 Hi all, draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***. Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is e= xperimental. Thanks a lot Michael (TCPM co-chair) --_000_787AE7BB302AE849A7480A190F8B93302EAC103FOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

I am not aware of any undisclos= ed IPR relevant to this document.

 

Cheers,

Med

 

De : Scha= rf, Michael [mailto:Michael.Scharf@hs-esslingen.de]
Envoy=E9 : samedi 29 juin 2019 13:59
=C0 : draft-ietf-tcpm-converters@ietf.org
Cc : tcpm@ietf.org Extensions
Objet : IPR poll for draft-ietf-tcpm-converters

 

Dear authors,

 

The document shepherd has to ensu= re compliance with the IPR guidelines of the IETF.

 

Can each author please confirm that their direct= , personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

Thanks

 

Michael

 

 

Von: Scharf, Michael Gesendet: Dienstag, 25. Juni 2019 18:39
An: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org=
Betreff: WGLC for draft-ietf-tcpm-converters-08

 

Hi all,

draft-ietf-tcpm-converters has been discussed and reviewed quite a bit.

Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***.

Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is experimental.

Thanks a lot

Michael
(TCPM co-chair)

--_000_787AE7BB302AE849A7480A190F8B93302EAC103FOPEXCAUBMA2corp_-- From nobody Fri Jul 5 02:23: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 525F9120153; Fri, 5 Jul 2019 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OFYKdkQx7D1; Fri, 5 Jul 2019 02:23:02 -0700 (PDT) Received: from smfilter3.kt.com (smfilter3.kt.com [14.63.245.79]) by ietfa.amsl.com (Postfix) with ESMTP id 823141200CE; Fri, 5 Jul 2019 02:23:00 -0700 (PDT) Received: from external ([10.215.33.52]) by smfilter3.kt.com (1.0) id x659M3o001CF; Fri, 05 Jul 2019 18:22:03 +0900 Received: from MAIL-MBX-02.corp.ktad.kt.com ([10.215.33.72]) by MAIL-FRT-02.corp.ktad.kt.com ([10.215.33.52]) with mapi id 14.03.0210.002; Fri, 5 Jul 2019 18:22:02 +0900 From: SungHoon Seo To: "Scharf, Michael" CC: "tcpm@ietf.org Extensions" , "draft-ietf-tcpm-converters@ietf.org" Thread-Topic: IPR poll for draft-ietf-tcpm-converters Thread-Index: AQHVLnM1holE8c4F+EeFK9xw1M4sPKa7yBVQ Date: Fri, 5 Jul 2019 09:22:01 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dispnameaddress: sh.seo@kt.com x-originating-ip: [10.214.73.222] Content-Type: multipart/alternative; boundary="_000_AAA2913CE97A474D937BF3C760E855A7E421BE51MAILMBX02_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] IPR poll for draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 09:23:05 -0000 --_000_AAA2913CE97A474D937BF3C760E855A7E421BE51MAILMBX02_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBTY2hhcmYsDQoNCkkgY29uZmlybSB0aGF0IHRoZXJlIGlzIG5vIHVuZGlzY2xvc2VkIElQ UiByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQgaW4gbXkgYXdhcmVuZXNzLg0KDQpUaGFuayB5b3Us DQpTdW5nSG9vbiBTZW8NCg0KDQpGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU2NoYXJmLCBNaWNoYWVsDQpTZW50OiBTYXR1cmRheSwgSnVuZSAy OSwgMjAxOSA4OjU5IFBNDQpUbzogZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnNAaWV0Zi5vcmcN CkNjOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBb dGNwbV0gSVBSIHBvbGwgZm9yIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQoNCg0KRGVhciBh dXRob3JzLA0KDQoNCg0KVGhlIGRvY3VtZW50IHNoZXBoZXJkIGhhcyB0byBlbnN1cmUgY29tcGxp YW5jZSB3aXRoIHRoZSBJUFIgZ3VpZGVsaW5lcyBvZiB0aGUgSUVURi4NCg0KDQoNCkNhbiBlYWNo IGF1dGhvciBwbGVhc2UgY29uZmlybSB0aGF0IHRoZWlyIGRpcmVjdCwgcGVyc29uYWwga25vd2xl ZGdlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IGhhcyBhbHJlYWR5IGJlZW4g ZGlzY2xvc2VkLCBpbiBjb25mb3JtYW5jZSB3aXRoIEJDUHMgNzggYW5kIDc5Pw0KDQoNCg0KTm90 ZSB0aGF0IGFuIGFuc3dlciBpcyByZXF1aXJlZCBmcm9tIGFsbCBhdXRob3JzIG9mIHRoZSBkb2N1 bWVudC4gVGhlIFRDUE0gbGlzdHMgaXMgYWRkZWQgaW4gQ0MgZm9yIHRoZSBzYWtlIG9mIHRyYW5z cGFyZW5jeS4NCg0KDQoNClRoYW5rcw0KDQoNCg0KTWljaGFlbA0KDQoNCg0KDQoNClZvbjogU2No YXJmLCBNaWNoYWVsPG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU+DQpHZXNl bmRldDogRGllbnN0YWcsIDI1LiBKdW5pIDIwMTkgMTg6MzkNCkFuOiB0Y3BtQGlldGYub3JnIEV4 dGVuc2lvbnM8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpDYzogdGNwbS1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOnRjcG0tY2hhaXJzQGlldGYub3JnPg0KQmV0cmVmZjogV0dMQyBmb3IgZHJhZnQtaWV0 Zi10Y3BtLWNvbnZlcnRlcnMtMDgNCg0KDQpIaSBhbGwsDQoNCmRyYWZ0LWlldGYtdGNwbS1jb252 ZXJ0ZXJzIGhhcyBiZWVuIGRpc2N1c3NlZCBhbmQgcmV2aWV3ZWQgcXVpdGUgYSBiaXQuDQoNClRo ZXJlZm9yZSwgdGhpcyBlLW1haWwgc3RhcnRzIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgKFdH TEMpIGZvciBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy0wOCB0aGF0IHdpbGwgcnVuIHVudGls ICoqKkp1bHkgMTQsIDIwMTkqKiouDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGVyZSBhcmUg YW55IHJlbWFpbmluZyBvcGVuIGlzc3VlcyByZWdhcmRpbmcgdGhpcyBkb2N1bWVudC4gU3RhdGVt ZW50cyBzdXBwb3J0aW5nIHB1YmxpY2F0aW9uIGFyZSBhbHNvIHdlbGNvbWUuIEluIGFic2VuY2Ug b2YgZmVlZGJhY2sgd2Ugd2lsbCBhc3N1bWUgdGhhdCB0aGUgVENQTSBjb25zZW5zdXMgaXMgdG8g bW92ZSB0aGUgZG9jdW1lbnQgdG8gdGhlIElFU0cuIEFzIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCwg dGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQgaXMgZXhwZXJpbWVudGFsLg0KDQpU aGFua3MgYSBsb3QNCg0KTWljaGFlbA0KKFRDUE0gY28tY2hhaXIpDQoNCg0KwMwguN7Az8C6IMH2 waS1yCC89sPrwM64uMC7IMCnx9ggwNu8urXHvvrAuLjnLCDB37/kx9EgwaS6uLOqIMD6wNuxx8C7 IMb3x9THz7DtIMDWwLsgvPYgwNa9wLTPtNkuIL7utrDH0SCxx8fRIL74wMwsILq7ILmuvK2/oSDG 98fUtcggwaS6uMDHIMD8us4gtse0wiDAz7rOuKYguau03MC4t84gwaYzwNq/obDUILD4sLMsILno xvcsILq5u+cgtse0wiC757/rx8+0wiCwzcC7IL72sN3I9yCx3cH2x9W0z7TZLiC4uL7gLCC6uyC4 3sDPwMwgwN+4+CDA/LzbtcggsOa/7Cwgud+9xcDOILbHtMIgtOe757+hIL7Lt8HB1r3DsO0sILq7 ILjewM/AuyDB773DILvowabHz7+pIMHWvcOx4iC52bb4tM+02S4NClRoaXMgRS1tYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQvb3IgY29weXJpZ2h0IG1hdGVyaWFs LiBUaGlzIGVtYWlsIGlzIGludGVuZGVkIGZvciB0aGUgdXNlIG9mIHRoZSBhZGRyZXNzZWUgb25s eS4gSWYgeW91IHJlY2VpdmUgdGhpcyBlbWFpbCBieSBtaXN0YWtlLCBwbGVhc2UgZWl0aGVyIGRl bGV0ZSBpdCB3aXRob3V0IHJlcHJvZHVjaW5nLCBkaXN0cmlidXRpbmcgb3IgcmV0YWluaW5nIGNv cGllcyB0aGVyZW9mIG9yIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5Lg0K --_000_AAA2913CE97A474D937BF3C760E855A7E421BE51MAILMBX02_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Dear Scharf,

 

I confirm that there is no undisclosed IPR related to this = document in my awareness.

 

Thank you,

SungHoon Seo

 <= /span>

 

From: = tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael
Sent: Saturday, June 29, 2019 8:59 PM
To: draft-ietf-tcpm-converters@ietf.org
Cc: tcpm@ietf.org Extensions <tcpm@ietf.org>
Subject: [tcpm] IPR poll for draft-ietf-tcpm-converters

 

Dear authors,

 

The document shepherd has to ensu= re compliance with the IPR guidelines of the IETF.

 

Can each author please confirm that their direct, personal knowledge of any = IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

 

Note that = an answer is required from all authors of the document. The TCPM lists is a= dded in CC for the sake of transparency.

 

Thanks

 

Michael

 

 

Von: = Scharf, Michael
Gesendet: Dienstag, 25. Juni 2019 18:39
An: tcpm@ietf.org Extensions=
Cc: tcpm-chairs@ietf.org
Betreff: WGLC for draft-ietf-tcpm-converters-08

&nbs= p;

Hi all,

draft-ietf-tcpm-converters has been discussed and reviewed quite a bit.

Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***.

Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is experimental.

Thanks a lot

Michael
(TCPM co-chair)

 

=C0=CC =B8=DE=C0=CF=C0=BA =C1=F6=C1=A4=B5=C8 =BC=F6=C3=EB=C0=CE=B8=B8=C0=BB= =C0=A7=C7=D8 =C0=DB=BC=BA=B5=C7=BE=FA=C0=B8=B8=E7, =C1=DF=BF=E4=C7=D1 =C1= =A4=BA=B8=B3=AA =C0=FA=C0=DB=B1=C7=C0=BB =C6=F7=C7=D4=C7=CF=B0=ED =C0=D6=C0= =BB =BC=F6 =C0=D6=BD=C0=B4=CF=B4=D9. =BE=EE=B6=B0=C7=D1 =B1=C7=C7=D1 =BE=F8= =C0=CC, =BA=BB =B9=AE=BC=AD=BF=A1 =C6=F7=C7=D4=B5=C8 =C1=A4=BA=B8=C0=C7 =C0= =FC=BA=CE =B6=C7=B4=C2 =C0=CF=BA=CE=B8=A6 =B9=AB=B4=DC=C0=B8=B7=CE =C1=A63= =C0=DA=BF=A1=B0=D4 =B0=F8=B0=B3, =B9=E8=C6=F7, =BA=B9=BB=E7 =B6=C7=B4=C2 = =BB=E7=BF=EB=C7=CF=B4=C2 =B0=CD=C0=BB =BE=F6=B0=DD=C8=F7 =B1=DD=C1=F6=C7=D5= =B4=CF=B4=D9. =B8=B8=BE=E0, =BA=BB =B8=DE=C0=CF=C0=CC =C0=DF=B8=F8 =C0=FC= =BC=DB=B5=C8 =B0=E6=BF=EC, =B9=DF=BD=C5=C0=CE =B6=C7=B4=C2 =B4=E7=BB=E7=BF= =A1 =BE=CB=B7=C1=C1=D6=BD=C3=B0=ED, =BA=BB =B8=DE=C0=CF=C0=BB =C1=EF=BD=C3 = =BB=E8=C1=A6=C7=CF=BF=A9 =C1=D6=BD=C3=B1=E2 =B9=D9=B6=F8=B4=CF=B4=D9.
This E-mail may contain confidential information and/or copyright material.= This email is intended for the use of the addressee only. If you receive t= his email by mistake, please either delete it without reproducing, distribu= ting or retaining copies thereof or notify the sender immediately.

--_000_AAA2913CE97A474D937BF3C760E855A7E421BE51MAILMBX02_-- From nobody Fri Jul 5 14:00:09 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 0F51212011B; Fri, 5 Jul 2019 14:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: Cc: tcpm@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156236040202.22050.12087445941514242632@ietfa.amsl.com> Date: Fri, 05 Jul 2019 14:00:02 -0700 Archived-At: Subject: [tcpm] =?utf-8?q?IPR_Disclosure_Universit=C3=A9_catholique_de_Lo?= =?utf-8?q?uvain=26=2339=3Bs_Statement_about_IPR_related_to_draft-ietf-tcp?= =?utf-8?q?m-converters=2C_draft-boucadair-mptcp-plain-mode=2C_and_draft-b?= =?utf-8?q?oucadair-mptcp-plain-mode?= 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, 05 Jul 2019 21:00:03 -0000 Dear Olivier Bonaventure, Mohamed Boucadair, Sri Gundavelli, SungHoon Seo, Benjamin Hesmans: An IPR disclosure that pertains to your Internet-Draft entitled "0-RTT TCP Convert Protocol" (draft-ietf-tcpm-converters) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3616/). The title of the IPR disclosure is "Université catholique de Louvain's Statement about IPR related to draft-ietf-tcpm-converters, draft-boucadair-mptcp-plain-mode, and draft-boucadair-mptcp-plain-mode" Thank you IETF Secretariat From nobody Sun Jul 7 01:36:09 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C9412007C for ; Sun, 7 Jul 2019 01:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LCm3zVoY2Ti for ; Sun, 7 Jul 2019 01:36:05 -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 2BC6312002E for ; Sun, 7 Jul 2019 01:36:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id ED1D125A17 for ; Sun, 7 Jul 2019 10:36:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1562488563; bh=EDkwUXEm73P9KgI5ZOaj6MRa9aevmtQPv3/bDCPFm+A=; h=From:To:Subject:Date:From; b=dpg2r9+kCwTPwdPoslMxtllnb49WFMOJ3SOSV/6KNHVFBxfx1+RmCfkI5o0BBI3Lr 1ivB7CGooBeLaLX+jVH4Y1GXA/UqCoggZqBgh88BM/XDtvPtEit6qFrsu9skl/UwGI oAsax5OwKT5Vr94MPnbQIElqfSwFMqeEJ6xfPVPs= 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 Xfskjz_ZdM00 for ; Sun, 7 Jul 2019 10:36:01 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Sun, 7 Jul 2019 10:36:01 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.38]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Sun, 7 Jul 2019 10:36:01 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org Extensions" Thread-Topic: draft-scharf-tcpm-yang-tcp-02 Thread-Index: AdU0nwE/UyiHKOryQMqpILXfLwVQBA== Content-Class: urn:content-classes:message Date: Sun, 7 Jul 2019 08:36:00 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3811E7@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3811E7rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] draft-scharf-tcpm-yang-tcp-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 07 Jul 2019 08:36:08 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3811E7rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgdXBkYXRlZCBkcmFmdC1zY2hhcmYtdGNwbS15YW5nLXRjcCBhbG9u ZyB0aGUgbGluZXMgb2YgdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBsYXN0IG1lZXRpbmcuIEFz IGEgcmVzdWx0LCB0aGVyZSBhcmUgbWFqb3IgY2hhbmdlcyBpbiB2ZXJzaW9uIC0wMi4NCg0KTm90 ZSB0aGF0IHRoaXMgdmVyc2lvbiBvZiB0aGUgSS1EIGRvZXMgbm90IGluY2x1ZGUgYSBjb21wbGV0 ZSBZQU5HIG1vZGVsLiBJIGJlbGlldmUgaXQgd291bGQgYmUgdXNlZnVsIHRvIGZpcnN0IGRpc2N1 c3MgaW4gVENQTSB0aGUgb3ZlcmFsbCBkaXJlY3Rpb24gYW5kIHRoZSBzY29wZSBvZiBhIG1vZGVs LiBEZXBlbmRpbmcgb24gdGhlIG91dGNvbWUsIGEgY29tcGxldGUgWUFORyBtb2RlbCBjb3VsZCBl LmcuIGJlIGFkZGVkIGluIGEgdmVyc2lvbiAtMDMuDQoNClBsZWFzZSBmZWVsIGZyZWUgdG8gaGF2 ZSBhIGxvb2sgYXQgdGhlIG5ldyB2ZXJzaW9uIGFuZCBsZXQgdXMga25vdyB5b3VyIHRob3VnaHRz Lg0KDQpUaGFua3MNCg0KTWljaGFlbCAoYXMgYXV0aG9yKQ0KDQoNCg0KVm9uOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkdlc2VuZGV0 OiBTb25udGFnLCA3LiBKdWxpIDIwMTkgMTA6MjYNCkFuOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8 bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkJldHJlZmY6IEktRCBBY3Rpb246IGRyYWZ0 LXNjaGFyZi10Y3BtLXlhbmctdGNwLTAyLnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4N Cg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFlBTkcgR3JvdXBpbmdzIGZvciBUcmFuc21p c3Npb24gQ29udHJvbCBQcm90b2NvbCAoVENQKSBDb25maWd1cmF0aW9uDQogICAgICAgIEF1dGhv cnMgICAgICAgICA6IE1pY2hhZWwgU2NoYXJmDQogICAgICAgICAgICAgICAgICAgICAgICAgIFZp c2hhbCBNdXJnYWkNCiAgICAgICAgICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1zY2hh cmYtdGNwbS15YW5nLXRjcC0wMi50eHQNCiAgICAgICAgICAgICAgICBQYWdlcyAgICAgICAgICAg OiAxMQ0KICAgICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTktMDctMDcNCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIFlBTkcgbW9kZWwgZm9yIFRDUCBv biBkZXZpY2VzIHRoYXQgYXJlDQogICBjb25maWd1cmVkIGJ5IG5ldHdvcmsgbWFuYWdlbWVudCBw cm90b2NvbHMuICBUaGUgWUFORyBtb2RlbCBkZWZpbmVzDQogICBncm91cGluZ3MgZm9yIGZ1bmRh bWVudGFsIHBhcmFtZXRlcnMgdGhhdCBjYW4gYmUgbW9kaWZpZWQgaW4gbWFueSBUQ1ANCiAgIGlt cGxlbWVudGF0aW9ucy4gIFRoZSBtb2RlbCBleHRlbmRzIGEgYmFzZSBtb2RlbCBmb3IgVENQIGNs aWVudHMgYW5kDQogICBzZXJ2ZXJzIFtJLUQuaWV0Zi1uZXRjb25mLXRjcC1jbGllbnQtc2VydmVy XS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNjaGFyZi10Y3BtLXlh bmctdGNwLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2NoYXJmLXRjcG0teWFuZy10Y3At MDINCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc2NoYXJmLXRj cG0teWFuZy10Y3AtMDINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNjaGFy Zi10Y3BtLXlhbmctdGNwLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxp c3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hh ZG93LXNpdGVzLnR4dA0KDQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D3811E7rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-ID: <26346E52929A004184F6E4352D3ECED5@exchange.hs-esslingen.de> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAy LjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgdXBkYXRlZCBkcmFmdC1z Y2hhcmYtdGNwbS15YW5nLXRjcCBhbG9uZyB0aGUgbGluZXMgb2YgdGhlIGRpc2N1c3Npb24gZHVy aW5nIHRoZSBsYXN0IG1lZXRpbmcuIEFzIGEgcmVzdWx0LCB0aGVyZSBhcmUgbWFqb3IgY2hhbmdl cyBpbiB2ZXJzaW9uIC0wMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IHRoaXMg dmVyc2lvbiBvZiB0aGUgSS1EIGRvZXMgbm90IGluY2x1ZGUgYSBjb21wbGV0ZSBZQU5HIG1vZGVs LiBJIGJlbGlldmUgaXQgd291bGQgYmUgdXNlZnVsIHRvIGZpcnN0IGRpc2N1c3MgaW4gVENQTSB0 aGUgb3ZlcmFsbCBkaXJlY3Rpb24gYW5kIHRoZSBzY29wZSBvZiBhIG1vZGVsLiBEZXBlbmRpbmcg b24gdGhlIG91dGNvbWUsIGEgY29tcGxldGUgWUFORyBtb2RlbCBjb3VsZCBlLmcuIGJlDQogYWRk ZWQgaW4gYSB2ZXJzaW9uIC0wMy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGZlZWwg ZnJlZSB0byBoYXZlIGEgbG9vayBhdCB0aGUgbmV3IHZlcnNpb24gYW5kIGxldCB1cyBrbm93IHlv dXIgdGhvdWdodHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NaWNoYWVsIChhcyBhdXRob3IpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNt Ij48Yj5Wb246IDwvYj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5p bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+R2VzZW5kZXQ6IDwvYj5Tb25udGFn LCA3LiBKdWxpIDIwMTkgMTA6MjY8YnI+DQo8Yj5BbjogPC9iPjxhIGhyZWY9Im1haWx0bzppLWQt YW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5CZXRy ZWZmOiA8L2I+SS1EIEFjdGlvbjogZHJhZnQtc2NoYXJmLXRjcG0teWFuZy10Y3AtMDIudHh0PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBZQU5HIEdyb3VwaW5ncyBmb3IgVHJhbnNtaXNzaW9u IENvbnRyb2wgUHJvdG9jb2wgKFRDUCkgQ29uZmlndXJhdGlvbjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3Jz Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogTWljaGFl bCBTY2hhcmY8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgVmlzaGFsIE11cmdhaTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IGRyYWZ0LXNjaGFyZi10Y3BtLXlhbmctdGNwLTAy LnR4dDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA6IDExPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE5LTA3LTA3PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BYnN0cmFjdDo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBZQU5HIG1vZGVsIGZvciBUQ1Agb24gZGV2aWNlcyB0 aGF0IGFyZTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBjb25maWd1cmVk IGJ5IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMuJm5ic3A7IFRoZSBZQU5HIG1vZGVsIGRl ZmluZXM8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgZ3JvdXBpbmdzIGZv ciBmdW5kYW1lbnRhbCBwYXJhbWV0ZXJzIHRoYXQgY2FuIGJlIG1vZGlmaWVkIGluIG1hbnkgVENQ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9ucy4m bmJzcDsgVGhlIG1vZGVsIGV4dGVuZHMgYSBiYXNlIG1vZGVsIGZvciBUQ1AgY2xpZW50cyBhbmQ8 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgc2VydmVycyBbSS1ELmlldGYt bmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlcl0uPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNjaGFyZi10Y3BtLXlhbmctdGNwLzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zY2hhcmYtdGNwbS15YW5nLXRjcC0wMjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc2NoYXJmLXRjcG0teWFuZy10 Y3AtMDI8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5odHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtc2NoYXJmLXRjcG0teWFuZy10Y3AtMDI8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SS1ELUFubm91bmNlIG1haWxpbmcg bGlzdDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkktRC1Bbm5vdW5jZUBpZXRmLm9yZzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaS1kLWFubm91bmNlPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5vciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4 dDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D3811E7rznt8114rzntrzd_-- From nobody Mon Jul 8 01:11: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 C7848120127 for ; Mon, 8 Jul 2019 01:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.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 vxLQTFiW75wj for ; Mon, 8 Jul 2019 01:10:59 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E5012012B for ; Mon, 8 Jul 2019 01:10:58 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id l2so8066258wmg.0 for ; Mon, 08 Jul 2019 01:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=efgYqK/ofXDGorX6yATYFoWYbsSDPT9moHgEwc/Mmbc=; b=ikDg2C+3wmkG0ZTlswYgQB3XBDOQtB4xuHLI6/OVHaOzxjayglmK5vi3E3BFnxuv9/ hfQAYQ2pv9N4l1GTdSYr+Ny4KChDR40Rpv5V/sPQeO0f4r60g97AujvP5lZaCSqyVfeg b9l2xFRuB8IzrizF+O1hdB7KKtoQE4v/CEzQX83r8RB1GjgAVYNMAN6JrBFxXdtGD2gE VqYs6GJ+Hhlix8tJLqX5hDKagaOZ1E72e7w3RFpcjJeBQc4w9sOD7g0cTGrakYxDDczz YitnzMoVH30ZHHr51ZbFLAQh2sf3za7WkJZEyI9yIedEK7WjMipcSTL+2BoOlw4YtokT I3Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=efgYqK/ofXDGorX6yATYFoWYbsSDPT9moHgEwc/Mmbc=; b=o/WQJhdC27VH2INSxaqbirlldXnPbu/nlN/91hFeVjYw/U97tQCUGrGaFfAw3m1ob1 EWlLDjlIOGgKvLZ4/KYMdnn4AsZq3BsejliwmspiOtnNzHP+cVHneAO9v1x2HCXaOTWZ 66dONSvtxXfod4pobqQLjBOWViygaq95erFbeMV547teM2DSKcovlnwVKyuVtObbyceG T1uASHdEBBni/ykPDzS5VpxCsuqwa+8AzQSNMtG+/PppnyuVS75+dlycaC6upD4UXEQQ 1P6Yeye2RScEPJcS/2LTchI65Xn9nVr+uCZx3gbJFXKV9f4r90hzdQRVyPuZux6XAbPj 4Lqg== X-Gm-Message-State: APjAAAUhhD4I9iNEZWkKmojfUNlGUADYmk9WziQVhwRYpZWXuhpYgcMB UROpcf451vdZtc2wpYnX4p/1WmL3U9LGGQKUnfVy54IJ2H+U9FXdwyshqCuI+SUifGgKuiLL X-Google-Smtp-Source: APXvYqxhh5Hiw1Hi+PHcWsVDauODiZN4mdJ35cqoBt00coaAOKFuw5Ufd2i13gb9F1TatAecnnSMNQ== X-Received: by 2002:a05:600c:1150:: with SMTP id z16mr14928422wmz.168.1562573456457; Mon, 08 Jul 2019 01:10:56 -0700 (PDT) Received: from ?IPv6:2001:6a8:3081:4f04:895f:c2f4:68ee:2f7a? ([2001:6a8:3081:4f04:895f:c2f4:68ee:2f7a]) by smtp.gmail.com with ESMTPSA id 18sm15987370wmg.43.2019.07.08.01.10.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 01:10:54 -0700 (PDT) From: Olivier Bonaventure Message-Id: <8F93401A-9C4D-4061-90CA-B1970E14FCE6@tessares.net> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 8 Jul 2019 10:10:52 +0200 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAC103F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: "Scharf, Michael" , "draft-ietf-tcpm-converters@ietf.org" , "tcpm@ietf.org Extensions" To: mohamed.boucadair@orange.com References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAC103F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.104.11) Content-Type: multipart/alternative; boundary="Apple-Mail=_FADC09DD-EB25-437D-A52F-B56CECBBC27A" Archived-At: Subject: Re: [tcpm] IPR poll for draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 08:11:01 -0000 --Apple-Mail=_FADC09DD-EB25-437D-A52F-B56CECBBC27A Content-Type: text/plain; charset="US-ASCII" Michael, > > I am not aware of any undisclosed IPR relevant to this document. Same for me Olivier -- Disclaimer: https://www.tessares.net/mail-disclaimer/ --Apple-Mail=_FADC09DD-EB25-437D-A52F-B56CECBBC27A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1" Michael,<= br class=3D"">
 
I am not aware o= f any undisclosed IPR relevant to this document.

Same for me
=

Olivier





--Apple-Mail=_FADC09DD-EB25-437D-A52F-B56CECBBC27A-- From nobody Mon Jul 8 03:21:59 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD48120120 for ; Mon, 8 Jul 2019 03:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.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 KvMu1Dr9rj-5 for ; Mon, 8 Jul 2019 03:21:55 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 1DE07120111 for ; Mon, 8 Jul 2019 03:21:54 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k20so33900109ios.10 for ; Mon, 08 Jul 2019 03:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6hC649yjCAcau/eSQa9QeQQfp3BWdV1CUV2E4Qb0xnQ=; b=Z9HtJ0Nz5bzW6ZnOR2s4tH6xaSB5a3k7bGr7Rzr76HeQcDWCajlkXyujFy10BK/lOX HCTyg79bJn7YOEmWCJAh5eBRaxq6op8YQj+qHo34fTLbcIOXlUQyljUl/4EgSM/QzMUD UN1SW3iDakB43TPB1P7hxB4I6TqMbrmek3JjSlnbfs+roJ7g61RkQ77Yjj6DT1HTpKhC LvpNJ0SgLJdZGleCJWh3jMUGOeDkEHrlWgHJ/9VW7j2iDFYQZT6TXz6gjoYepdnzlFmq 5IU58V5alOQciAMQIXuO5aSLuYm41ypXDF+gHwoy+Ux8nS/1B4n4swldqruIHUWxGgmY QNIw== 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=6hC649yjCAcau/eSQa9QeQQfp3BWdV1CUV2E4Qb0xnQ=; b=hC/RGjodrvmNzDN6WpOVe7ds8GadGxSDBadQEUpXv2ebYIWPqHusojXZ15yGm09Bw0 PBm2EDULmFvRtHSJXPdqJaXVBVBO0MhVsnKJhk19pCZirldhg2gTs9X1AI120521DbVx AE+8d1RjDpuKr7+eJQ0G8ha527Sm7Lmk3iGmp3zrFvU6Qb+uwnb08F8tQmWkEt/SSM4a +92Im6rxo8s5FVdeSjRQtRPAZyXfeXAopeTjJepbndITdRjgTNytkEiCap2TJXLCszC3 Z2d4pBN7md3J4HG+/A7UJhQvtvcFmv9e1n8xkDlx/EtT10bqajqw3LUdUcctgvS1ZpJH h4xw== X-Gm-Message-State: APjAAAUelg+0pAFnSkS7yPE2F1ykYQ3cp7c9EmsI+WDz07MbNumn6fjs +yqwiGbmEPfX8kAPdFkcn3YgLNg3JP1TczZkXQ8DdRnzCvQHFmywt/NiNlBjclT8eQ6KVsvDSYN aKZG1/+VXoU/igw== X-Google-Smtp-Source: APXvYqx7OGUGRR4Iv4lD3LomWbdNf2+BGHVBmtr/9P8eoxLKVk9w45G8Wa+8aADEITb9BxDOi/i/dCgFFzHnH+Vz7iw= X-Received: by 2002:a5d:9b1a:: with SMTP id y26mr7177724ion.238.1562581314052; Mon, 08 Jul 2019 03:21:54 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAC103F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <8F93401A-9C4D-4061-90CA-B1970E14FCE6@tessares.net> In-Reply-To: <8F93401A-9C4D-4061-90CA-B1970E14FCE6@tessares.net> From: Benjamin Hesmans Date: Mon, 8 Jul 2019 12:21:43 +0200 Message-ID: To: Olivier Bonaventure Cc: mohamed.boucadair@orange.com, "Scharf, Michael" , "draft-ietf-tcpm-converters@ietf.org" , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000283cf9058d28d050" Archived-At: Subject: Re: [tcpm] IPR poll for draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 10:21:57 -0000 --000000000000283cf9058d28d050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Michael, I=E2=80=99m not aware of any undisclosed IPR related to this document Best regards, On Mon, Jul 8, 2019 at 10:11 AM Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Michael, > > > I am not aware of any undisclosed IPR relevant to this document. > > > Same for me > > > Olivier > > > ------------------------------ > > Disclaimer: https://www.tessares.net/mail-disclaimer/ > > > --=20 [image: Tessares SA] Benjamin Hesmans | R&D Engineer benjamin.hesmans@tessares.net | Tessares SA | Hybrid Access Solutions www.tessares.net 1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 --000000000000283cf9058d28d050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Michael,


I=E2=80=99m not aware of any undi= sclosed IPR related to this document


Best regards,

=
On Mon, Ju= l 8, 2019 at 10:11 AM Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:
<= /div>
Michael,
=C2=A0
I am n= ot aware of any undisclosed IPR relevant to this document.

Same for me


Olivier







--
=20
3D"Tes= Benjamin Hesmans | R&D Engineer
benjamin.hesmans@tessares.net | =20
Tessares SA | Hybrid Access Solutions
 www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
=20




--000000000000283cf9058d28d050-- From nobody Mon Jul 8 07:16: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 A7CAA1201CD; Mon, 8 Jul 2019 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D1mcCmYh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=skS1Xc9I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc6YP9VhBO16; Mon, 8 Jul 2019 07:16:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA561201E6; Mon, 8 Jul 2019 07:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16826; q=dns/txt; s=iport; t=1562595360; x=1563804960; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K7YMldlEcIdekz9hiDwY8U7lfktDx6w20pO4MfMIE+E=; b=D1mcCmYhfRelJqCKYPxb+qi02rlqZ3MoOva++WpT9+TIjoMMjIhyEKSY zIIaYTC1SzbEzzRe4wQfaZdGHjgw5roPUvIfC1yJ0506FFBEiFp0mKuNR rMC6c4zvmrYVyv81+i8H4MtQvnQp+BGYIYtucCHm0xrH3zd3jcRdt3Uvc U=; IronPort-PHdr: =?us-ascii?q?9a23=3AUTQDLhwapUB5FGjXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZueBlD9IPf0YgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAADhTiNd/5xdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFC9QA2pVIAQLKAqHWQOEUol1HII/l0aBLhS?= =?us-ascii?q?BEANUCQEBAQwBAS0CAQGEQAKCOCM0CQ4BAwEBBAEBAgEFbYo3DIVKAQEBAQM?= =?us-ascii?q?SGxMBATcBDwIBCBEDAQIoBzIUCQgCBAENBSKDAYEdTQMdAQKeZQKBOIhggiO?= =?us-ascii?q?CeQEBBYR5GIISCYE0AYteF4FAP4ERgxI+hAxGEhaFLJNtfJVtCQKCF5QEG4I?= =?us-ascii?q?shyGOMY0wlz0CBAIEBQIOAQEFgVA4gVhwFYMngkGDcYpTcoEpjCcBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,466,1557187200"; d="scan'208,217";a="504391361" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 14:15:58 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x68EFw8p003508 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 14:15:58 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 09:15:58 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 09:15:56 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 10:15:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q0PoP8oVW9GY78BqgXYw03jmGgpgVh7VrKhLbpyGipE=; b=skS1Xc9I046dPCrFCDrXfcHiPT5CLcgXYvZ1QEo1pGRQs0DmYI2TLHWGZ2Z9Ur012MDKFFxcIxwY9aJT9pMIyNrSzKew1fAG4m/FWO/lPARQkEMeFLZhnRTi9ik+XaEGVQjUnrX1tHfriYXidTEjcCR/4mMHFZwWhkmTGyIVMCM= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB2550.namprd11.prod.outlook.com (52.135.226.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 14:15:55 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::9454:1da4:f3b4:43a2]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::9454:1da4:f3b4:43a2%5]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 14:15:55 +0000 From: "Sri Gundavelli (sgundave)" To: "mohamed.boucadair@orange.com" , "Scharf, Michael" , "draft-ietf-tcpm-converters@ietf.org" CC: "tcpm@ietf.org Extensions" Thread-Topic: IPR poll for draft-ietf-tcpm-converters Thread-Index: AQHVNZemM6QGI6mO9kKGBK9Bn7a7ow== Date: Mon, 8 Jul 2019 14:15:54 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAC103F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAC103F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [128.107.241.172] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d24f5030-e993-40e9-e276-08d703aeca72 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2550; x-ms-traffictypediagnostic: BYAPR11MB2550: x-ms-exchange-purlcount: 37 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(366004)(136003)(346002)(376002)(199004)(189003)(53754006)(19273905006)(53936002)(186003)(66066001)(99286004)(7736002)(6246003)(256004)(4326008)(53376002)(110136005)(25786009)(236005)(36756003)(14454004)(102836004)(316002)(14444005)(8936002)(58126008)(81156014)(81166006)(26005)(86362001)(8676002)(5660300002)(2906002)(54896002)(476003)(53546011)(6506007)(6306002)(11346002)(66946007)(2501003)(76116006)(66476007)(64756008)(66556008)(66446008)(6512007)(73956011)(3846002)(6486002)(6116002)(790700001)(76176011)(6436002)(68736007)(229853002)(2616005)(446003)(486006)(71200400001)(71190400001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2550; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GCmna5zS59hcZhrzUqPxw78KSJucwR48b2Z7g+1R/XKUvBEyHdyXB1H3F9H4+ORNn9NxFOu/R+MbNH3+wFE0n9U0c+qfR0efyO8Y1RtDjXO9f7NQjcoHOBie4ki9omSOu38ih33VWfKDurIMaIo2iCF2y1dqeFUI47HXRNJ8eTkBqrH3yb+Zpp23S1G9He7JFIW/0guUB8DBTvdlQwh1yNv0VfOnfYRxZMtjkCICZZwPOASqxh/C4EcaOQIQavgfQRjfL+sJOZp54HlgmihYVGN4vzrKsQL0SjtUMxxhZGTnRvIRFufd+xVRD6AjTT9C2gX6Pf2pP9C5yoD4V2P/35sWJVMzhOq5mVA4tdd2l1ZotDD8gc0vgYd0zTLu9uhrk5fUGpZvxoCYuEvrfBWFpsB0LtG+aFZwjnm9B3mlko8= Content-Type: multipart/alternative; boundary="_000_D9489E1E3046E4sgundaveciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d24f5030-e993-40e9-e276-08d703aeca72 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:15:55.0045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sgundave@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2550 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [tcpm] IPR poll for draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 14:16:06 -0000 --_000_D9489E1E3046E4sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, I am not aware of any undisclosed IPR on this draft. Regards Sri From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Friday, July 5, 2019 at 2:04 AM To: "Scharf, Michael" >, "draft-ietf-tcpm-converters@ietf.org" > Cc: "tcpm@ietf.org Extensions" > Subject: RE: IPR poll for draft-ietf-tcpm-converters Resent-From: > Resent-To: >, >, Sri Gundavelli >, >, > Resent-Date: Friday, July 5, 2019 at 2:04 AM Hi Michael, I am not aware of any undisclosed IPR relevant to this document. Cheers, Med De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] Envoy=E9 : samedi 29 juin 2019 13:59 =C0 : draft-ietf-tcpm-converters@ietf.org Cc : tcpm@ietf.org Extensions Objet : IPR poll for draft-ietf-tcpm-converters Dear authors, The document shepherd has to ensure compliance with the IPR guidelines of t= he IETF. Can each author please confirm that their direct, personal knowledge of any= IPR related to this document has already been disclosed, in conformance wi= th BCPs 78 and 79? Note that an answer is required from all authors of the document. The TCPM = lists is added in CC for the sake of transparency. Thanks Michael Von: Scharf, Michael Gesendet: Dienstag, 25. Juni 2019 18:39 An: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org Betreff: WGLC for draft-ietf-tcpm-converters-08 Hi all, draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***. Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is e= xperimental. Thanks a lot Michael (TCPM co-chair) --_000_D9489E1E3046E4sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0E52CE373AF8E544B8CF7712C403E1F7@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Michael,

I am not aware of any undisclosed IPR on this draft.

Regards
Sri

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Friday, July 5, 2019 at 2:04 = AM
To: "Scharf, Michael" <= ;Michael.Scharf@hs-esslin= gen.de>, "draft-ietf-tcpm-converters@ietf.org" <draft-ietf-tcpm-converters@ietf.org>=
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: RE: IPR poll for draft-iet= f-tcpm-converters
Resent-From: <alias-bounces@ietf.org>
Resent-To: <olivier.bonaventure@tessares.net>, &= lt;mohamed.boucadair@orange= .com>, Sri Gundavelli <sgun= dave@cisco.com>, <sh.seo@kt.com>, <benjamin.hesmans@tessares.net>= ;
Resent-Date: Friday, July 5, 2019 a= t 2:04 AM

Hi Michael,

 

I am not aware of any undisclos= ed IPR relevant to this document.

 

Cheers,

Med

 

De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de]
Envoy=E9 : samedi 29 juin 2019 13:59
=C0 : dr= aft-ietf-tcpm-converters@ietf.org
Cc : tcpm@ietf.org Extensi= ons
Objet : IPR poll for draft-ietf-tcpm-converters

 

Dear authors,

 

The document shepherd has to ensu= re compliance with the IPR guidelines of the IETF.

 

Can each author please confirm that their direct, personal knowledge of any IPR related to this document = has already been disclosed, in conformance with BCPs 78 and 79?

 

Note tha= t an answer is required from all authors of the document. The TCPM lists is added in CC for the sake of transparenc= y.

 

Thanks

 

Michael

 

 

Von: Scharf, Michael Gesendet: Dienstag, 25. Juni 2019 18:39
An: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org=
Betreff: WGLC for draft-ietf-tcpm-converters-08

 

Hi all,

draft-ietf-tcpm-converters has been discussed and reviewed quite a bit.

Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***.

Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is experimental.

Thanks a lot

Michael
(TCPM co-chair)

--_000_D9489E1E3046E4sgundaveciscocom_-- From nobody Mon Jul 8 14:52:06 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 783B0120018; Mon, 8 Jul 2019 14:52:03 -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.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <156262272341.1025.13950526549198754755@ietfa.amsl.com> Date: Mon, 08 Jul 2019 14:52:03 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-09.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, 08 Jul 2019 21:52:04 -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-09.txt Pages : 46 Date : 2019-07-08 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 15:25:00 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EA4120316; Mon, 8 Jul 2019 15:24:49 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrzpjTt_nhy0; Mon, 8 Jul 2019 15:24:46 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE66120089; Mon, 8 Jul 2019 15:24:46 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x68MOd5t039639; Mon, 8 Jul 2019 15:24:39 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x68MOdVX039638; Mon, 8 Jul 2019 15:24:39 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201907082224.x68MOdVX039638@gndrsh.dnsmgr.net> In-Reply-To: <156262206203.815.3639685648474150771.idtracker@ietfa.amsl.com> To: tsvwg@ietf.org, tcpm@ietf.org Date: Mon, 8 Jul 2019 15:24:39 -0700 (PDT) CC: "Peter G. Heist" , Rodney Grimes X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] New Version Notification for draft-grimes-tcpmwg-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 22:24:59 -0000 Cross posting to tsvwg@ietf.org as this is part of SCE > A new version of I-D, draft-grimes-tcpmwg-tcpsce-00.txt > has been successfully submitted by Rodney W. Grimes and posted to the > IETF repository. > > Name: draft-grimes-tcpmwg-tcpsce > Revision: 00 > Title: Some Congestion Experienced in TCP > Document date: 2019-07-08 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-grimes-tcpmwg-tcpsce-00.txt > Status: https://datatracker.ietf.org/doc/draft-grimes-tcpmwg-tcpsce/ > Htmlized: https://tools.ietf.org/html/draft-grimes-tcpmwg-tcpsce-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-grimes-tcpmwg-tcpsce > > > Abstract: > This memo classifies a TCP code point ESCE ("Echo Some Congestion > Experienced") for use in feedback of IP code point SCE ("Some > Congestion Experienced"). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat -- Rod Grimes rgrimes@freebsd.org From nobody Mon Jul 8 16:05:37 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 8A1A7120316; Mon, 8 Jul 2019 16:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <156262712848.815.3894908539769714878@ietfa.amsl.com> Date: Mon, 08 Jul 2019 16:05:28 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-04.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, 08 Jul 2019 23:05: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 : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-04.txt Pages : 44 Date : 2019-07-08 Abstract: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-04 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 16:08: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 8864512038A for ; Mon, 8 Jul 2019 16:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtxwhb1mXBRN for ; Mon, 8 Jul 2019 16:07:57 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720096.outbound.protection.outlook.com [40.107.72.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36E5120320 for ; Mon, 8 Jul 2019 16:07:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JMLvInKM7Nb+5ANApGeXTi1LAhfwsCtr0iH9B7wNV+mq1Ug/SY8fqI7Y0XuwhgVGP2/rMfG7NPrpu8MmcTZp/gnoowcmP9KrJds+G5y6zn6ZEtBFyrXlN43l8xM9oawKKRxJVUxb/N5k0E2wrrJm/RqCGd32JiMP/Rt3JVPnGXInCKQ370KisyNCz9HhrQe5tmK0odqYBuUvIYVkxOiG2MdCIm91MpYZeDJMeYLh+Y1wWA4fiByyP6Ebtgab5Hk1mXXsJgH/NU2xvgHv8+5u5idShX8Dmf2nL5OErW8J9JAx55cLeH92CX5oIVbSR8c2ub6MK3ySwI3nPE1BPADLUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/fINJoHY5KCi0URThoNwIwxorzxTS/rAJtbiWE3xQqM=; b=TDM6+7eyxSGV/Gpdw0tGf0sfwyROgLZrSEryC/A4g5n4wbum8vSS+4DujmErKhgz16vc6FokG/XkS/VWdznnfzwsgudLZn81Pvi70MBv3H4MYQ78pj8j6OBmznNjQHBf42vQpo7jQaz98BwXgn2x4h8DbOm42rwuY1kkDqJK8L35Hzlh97oT2Ykhh9ieytFZPkwrF109yppEHySJP0FptQT+wcAIEOP20TbUFOaSQLWsB51+xR0FCe7w2qDcONw6yXXR8rwdQgJtlCwuRPv2/CWt5fSBTYB6cxcJ/SPFLePL/umhZecSPeLAhzgmLYTURLvxlH/hVSUIxsDhNbCqDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/fINJoHY5KCi0URThoNwIwxorzxTS/rAJtbiWE3xQqM=; b=IFZkK+EaP4GrRxib2nJ7slGHCYv2tPXHiLfLoihRjMYXV98ZCEynjWv04+UhAKV6WJChJgeRThmCMNJMxHFpyAAqcI4eUBkjtLt+5jJucFVRRHwMjOIu7i9nu/yHYlJOonWcU38bbLVXTYXKWToAtn8aFTVFNRSGvgGheskfJRo= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0924.namprd21.prod.outlook.com (52.132.152.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.3; Mon, 8 Jul 2019 23:07:53 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab%6]) with mapi id 15.20.2094.001; Mon, 8 Jul 2019 23:07:53 +0000 From: Praveen Balasubramanian To: "tcpm@ietf.org" CC: Matt Olson , Yi Huang Thread-Topic: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt Thread-Index: AQHVNeDXs6wG1Y3E+0uQvV9n53yFv6bBV5MA Date: Mon, 8 Jul 2019 23:07:53 +0000 Message-ID: References: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> In-Reply-To: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-08T23:07:52.5425070Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6c3aae67-c05a-4369-9407-f4e80b2edde5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:9:6c75:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4291764b-5211-4a44-8751-08d703f91b5e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB0924; x-ms-traffictypediagnostic: MW2PR2101MB0924:|MW2PR2101MB0924: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(366004)(39860400002)(396003)(346002)(376002)(199004)(189003)(13464003)(1730700003)(81166006)(8676002)(81156014)(476003)(11346002)(790700001)(446003)(10290500003)(478600001)(8936002)(6116002)(68736007)(25786009)(14454004)(316002)(6436002)(606006)(22452003)(14444005)(486006)(15650500001)(10090500001)(2420400007)(7110500001)(86362001)(966005)(4326008)(256004)(6506007)(2906002)(7696005)(229853002)(107886003)(53546011)(102836004)(54906003)(76176011)(2351001)(74316002)(186003)(66574012)(99286004)(52536014)(71190400001)(8990500004)(71200400001)(73956011)(66946007)(76116006)(64756008)(66446008)(66556008)(236005)(66476007)(6916009)(5660300002)(6306002)(33656002)(5640700003)(9686003)(55016002)(2473003)(2501003)(53936002)(46003)(54896002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0924; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: a5uq0YGlx1nTaTGA001dFUzaaJP3N8yqgbOzlNlGT8HUwP8RNo8EXHCdJTdJME4K2sT8zSs5N+hfA+E8gbLgNej03mC1kVetqiyuwz8r4dzNRqYswnL5pcd76m4tdo9avVzfOG+++eSfZjLh4sIKaXzFwpPpuwj0zuwonz7xVqa1iUxwSwyusZz1I8Vkg1dQL1mSrrxfvZ47EZvfD+Ggy9q+O4Nl/yXjuAbWlBqWk0J+Ne8mm8g/GmjwIsa+QpgIlO0kOS0VW+k92s0X/O9BzKE8kJxVdNaAnaymVFK0NbC3UybPApWSj4YylQ+DjfQOsfknpPSxgCr5YnehYpGz4d6gMBOT6YoQAWKr5/KrPLvpxo0USJlC2nawlgP0VSpNHTGs57V1v3GdzX2FR9oYOM7ajYA4JnGp+gqUqzZRo5A= Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB10495E1951F40C4CE6526413B6F60MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4291764b-5211-4a44-8751-08d703f91b5e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 23:07:53.5395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0924 Archived-At: Subject: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:08:11 -0000 --_000_MW2PR2101MB10495E1951F40C4CE6526413B6F60MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugc3VibWl0dGVkIGEgZHJhZnQgZm9yIG1vZGlmaWVkIHNsb3cgc3RhcnQgdXNpbmcgSHlTdGFy dCBhbmQgTGltaXRlZCBTbG93IFN0YXJ0LiBGZWVkYmFjayBpcyB3ZWxjb21lLg0KDQoNCg0KVGhh bmtzDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1 bHkgOCwgMjAxOSA0OjAwIFBNDQpUbzogTWF0dCBPbHNvbiA8bWFvbHNvbkBtaWNyb3NvZnQuY29t PjsgWWkgSHVhbmcgPGh1YW55aUBtaWNyb3NvZnQuY29tPjsgUHJhdmVlbiBCYWxhc3VicmFtYW5p YW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVzcGx1cy0wMC50eHQN Cg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRj cG0taHlzdGFydHBsdXNwbHVzLTAwLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KDQoNCk5hbWU6ICAgICAgICAgICAgICAgICAgZHJhZnQtYmFsYXN1YnJhbWFu aWFuLXRjcG0taHlzdGFydHBsdXNwbHVzDQoNClJldmlzaW9uOiAgICAgICAgICAgICAgMDANCg0K VGl0bGU6ICAgICAgICAgICAgICAgICAgICAgIEh5U3RhcnQrKzogTW9kaWZpZWQgU2xvdyBTdGFy dCBmb3IgVENQDQoNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAgMjAxOS0wNy0wOA0KDQpH cm91cDogICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAg ICAgICAgICAgICAgICAgIDYNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vbmFtMDYuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRmludGVybmV0LWRyYWZ0cyUyRmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRw bHVzcGx1cy0wMC50eHQmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3 QzQ1NzI4NjZiOTZkYzQ0YzY3NzJmMDhkNzAzZjdmOGJkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4MjIzNTg3NDk3NjI0MCZhbXA7c2RhdGE9eXJiWDU1 c2diMEQxWndaUEU5blNreSUyRkx3UFVGR3hSTjdzOTklMkIlMkZqSWRjOCUzRCZhbXA7cmVzZXJ2 ZWQ9MA0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZkcmFmdC1iYWxhc3VicmFtYW5pYW4tdGNwbS1oeXN0YXJ0cGx1c3BsdXMlMkYmYW1wO2Rh dGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzQ1NzI4NjZiOTZkYzQ0YzY3NzJm MDhkNzAzZjdmOGJkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjk4MjIzNTg3NDk3NjI0MCZhbXA7c2RhdGE9emFLdmVGT3NhNUJWYjZoUnJ0ellUZllRVk5p WnBHOVdDSVFCOEI2WkF0byUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0t aHlzdGFydHBsdXNwbHVzLTAwJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5j b20lN0M0NTcyODY2Yjk2ZGM0NGM2NzcyZjA4ZDcwM2Y3ZjhiZCU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5ODIyMzU4NzQ5NzYyNDAmYW1wO3NkYXRhPUNB Um51ZlNCajgxMWNBSUVlJTJCSmpBd1Y0dFY1bnclMkYlMkZEODEyMFpVR3NHdFElM0QmYW1wO3Jl c2VydmVkPTANCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVzcGx1 cyZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNDU3Mjg2NmI5NmRj NDRjNjc3MmYwOGQ3MDNmN2Y4YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM2OTgyMjM1ODc0OTc2MjQwJmFtcDtzZGF0YT1HWmVwNm92MlNaZUl4WjNXcXEz a0tPSERuQm9rMFclMkJSRnVZdzFpWEFUVU0lM0QmYW1wO3Jlc2VydmVkPTANCg0KDQoNCg0KDQpB YnN0cmFjdDoNCg0KICAgVGhpcyBleHBlcmltZW50YWwgbWVtbyBkZXNjcmliZXMgSHlTdGFydCsr LCBhIHNpbXBsZSBtb2RpZmljYXRpb24gdG8NCg0KICAgdGhlIHNsb3cgc3RhcnQgcGhhc2Ugb2Yg VENQIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zLiAgSHlTdGFydCsrDQoNCiAgIGNvbWJp bmVzIHRoZSB1c2Ugb2Ygb25lIHZhcmlhbnQgb2YgSHlTdGFydCBhbmQgTGltaXRlZCBTbG93IFN0 YXJ0DQoNCiAgIChMU1MpIHRvIHByZXZlbnQgb3ZlcnNob290aW5nIG9mIHRoZSBpZGVhbCBzZW5k aW5nIHJhdGUgdmFsdWUsIHdoaWxlDQoNCiAgIGFsc28gbWl0aWdhdGluZyBwb29yIHBlcmZvcm1h bmNlIHdoaWNoIGNhbiByZXN1bHQgZnJvbSBmYWxzZQ0KDQogICBwb3NpdGl2ZXMgd2hlbiBIeVN0 YXJ0IGlzIHVzZWQgYWxvbmUuICBUaGlzIG1lbW8gYWxzbyBkZXNjcmliZXMgdGhlDQoNCiAgIGRl dGFpbHMgb2YgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaW4gdGhlIFdpbmRvd3Mgb3BlcmF0 aW5nDQoNCiAgIHN5c3RlbS4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_MW2PR2101MB10495E1951F40C4CE6526413B6F60MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBzdWJtaXR0ZWQgYSBkcmFmdCBmb3Ig bW9kaWZpZWQgc2xvdyBzdGFydCB1c2luZyBIeVN0YXJ0IGFuZCBMaW1pdGVkIFNsb3cgU3RhcnQu IEZlZWRiYWNrIGlzIHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5r czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyAmbHQ7aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnJmd0OyA8YnI+DQpTZW50OiBNb25kYXksIEp1bHkgOCwgMjAxOSA0OjAwIFBNPGJy Pg0KVG86IE1hdHQgT2xzb24gJmx0O21hb2xzb25AbWljcm9zb2Z0LmNvbSZndDs7IFlpIEh1YW5n ICZsdDtodWFueWlAbWljcm9zb2Z0LmNvbSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZs dDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0taHlzdGFydHBsdXNwbHVzLTAw LnR4dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmFsYXN1YnJhbWFuaWFu LXRjcG0taHlzdGFydHBsdXNwbHVzLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQcmF2ZWVuIEJh bGFzdWJyYW1hbmlhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVzcGx1 czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmV2aXNpb246Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDAwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSHlTdGFydCYjNDM7JiM0Mzs6IE1vZGlmaWVkIFNsb3cgU3Rh cnQgZm9yIFRDUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RG9jdW1l bnQgZGF0ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxOS0wNy0wODxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGaW50ZXJuZXQtZHJhZnRzJTJGZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0taHlzdGFy dHBsdXNwbHVzLTAwLnR4dCZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0 LmNvbSU3QzQ1NzI4NjZiOTZkYzQ0YzY3NzJmMDhkNzAzZjdmOGJkJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4MjIzNTg3NDk3NjI0MCZhbXA7YW1wO3Nk YXRhPXlyYlg1NXNnYjBEMVp3WlBFOW5Ta3klMkZMd1BVRkd4Uk43czk5JTJCJTJGaklkYzglM0Qm YW1wO2FtcDtyZXNlcnZlZD0wIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpbnRlcm5ldC1kcmFmdHMl MkZkcmFmdC1iYWxhc3VicmFtYW5pYW4tdGNwbS1oeXN0YXJ0cGx1c3BsdXMtMDAudHh0JmFtcDth bXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNDU3Mjg2NmI5NmRjNDRj Njc3MmYwOGQ3MDNmN2Y4YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2OTgyMjM1ODc0OTc2MjQwJmFtcDthbXA7c2RhdGE9eXJiWDU1c2diMEQxWndaUEU5 blNreSUyRkx3UFVGR3hSTjdzOTklMkIlMkZqSWRjOCUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3RhdHVzOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWJhbGFzdWJyYW1hbmlh bi10Y3BtLWh5c3RhcnRwbHVzcGx1cyUyRiZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQw bWljcm9zb2Z0LmNvbSU3QzQ1NzI4NjZiOTZkYzQ0YzY3NzJmMDhkNzAzZjdmOGJkJTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4MjIzNTg3NDk3NjI0MCZh bXA7YW1wO3NkYXRhPXphS3ZlRk9zYTVCVmI2aFJydHpZVGZZUVZOaVpwRzlXQ0lRQjhCNlpBdG8l M0QmYW1wO2FtcDtyZXNlcnZlZD0wIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUy RmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVzcGx1cyUyRiZhbXA7YW1wO2Rh dGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzQ1NzI4NjZiOTZkYzQ0YzY3NzJm MDhkNzAzZjdmOGJkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjk4MjIzNTg3NDk3NjI0MCZhbXA7YW1wO3NkYXRhPXphS3ZlRk9zYTVCVmI2aFJydHpZVGZZ UVZOaVpwRzlXQ0lRQjhCNlpBdG8lM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkh0bWxpemVkOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9y ZyUyRmh0bWwlMkZkcmFmdC1iYWxhc3VicmFtYW5pYW4tdGNwbS1oeXN0YXJ0cGx1c3BsdXMtMDAm YW1wO2FtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M0NTcyODY2Yjk2 ZGM0NGM2NzcyZjA4ZDcwM2Y3ZjhiZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzY5ODIyMzU4NzQ5NzYyNDAmYW1wO2FtcDtzZGF0YT1DQVJudWZTQmo4MTFj QUlFZSUyQkpqQXdWNHRWNW53JTJGJTJGRDgxMjBaVUdzR3RRJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9 MCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRj cG0taHlzdGFydHBsdXNwbHVzLTAwJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNy b3NvZnQuY29tJTdDNDU3Mjg2NmI5NmRjNDRjNjc3MmYwOGQ3MDNmN2Y4YmQlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTgyMjM1ODc0OTc2MjQwJmFtcDth bXA7c2RhdGE9Q0FSbnVmU0JqODExY0FJRWUlMkJKakF3VjR0VjVudyUyRiUyRkQ4MTIwWlVHc0d0 USUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRt bCUyRmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVzcGx1cyZhbXA7YW1wO2Rh dGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzQ1NzI4NjZiOTZkYzQ0YzY3NzJm MDhkNzAzZjdmOGJkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjk4MjIzNTg3NDk3NjI0MCZhbXA7YW1wO3NkYXRhPUdaZXA2b3YyU1plSXhaM1dxcTNrS09I RG5Cb2swVyUyQlJGdVl3MWlYQVRVTSUzRCZhbXA7YW1wO3Jlc2VydmVkPTAiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3Bt LWh5c3RhcnRwbHVzcGx1cyZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0 LmNvbSU3QzQ1NzI4NjZiOTZkYzQ0YzY3NzJmMDhkNzAzZjdmOGJkJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4MjIzNTg3NDk3NjI0MCZhbXA7YW1wO3Nk YXRhPUdaZXA2b3YyU1plSXhaM1dxcTNrS09IRG5Cb2swVyUyQlJGdVl3MWlYQVRVTSUzRCZhbXA7 YW1wO3Jlc2VydmVkPTA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0Ojxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZXhwZXJpbWVudGFsIG1lbW8gZGVzY3JpYmVzIEh5U3RhcnQmIzQzOyYjNDM7LCBhIHNpbXBsZSBt b2RpZmljYXRpb24gdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyB0aGUgc2xvdyBzdGFydCBwaGFzZSBvZiBUQ1AgY29uZ2VzdGlvbiBjb250cm9s IGFsZ29yaXRobXMuJm5ic3A7IEh5U3RhcnQmIzQzOyYjNDM7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgY29tYmluZXMgdGhlIHVzZSBvZiBvbmUg dmFyaWFudCBvZiBIeVN0YXJ0IGFuZCBMaW1pdGVkIFNsb3cgU3RhcnQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAoTFNTKSB0byBwcmV2ZW50IG92 ZXJzaG9vdGluZyBvZiB0aGUgaWRlYWwgc2VuZGluZyByYXRlIHZhbHVlLCB3aGlsZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFsc28gbWl0aWdh dGluZyBwb29yIHBlcmZvcm1hbmNlIHdoaWNoIGNhbiByZXN1bHQgZnJvbSBmYWxzZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHBvc2l0aXZlcyB3 aGVuIEh5U3RhcnQgaXMgdXNlZCBhbG9uZS4mbmJzcDsgVGhpcyBtZW1vIGFsc28gZGVzY3JpYmVz IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IGRldGFpbHMgb2YgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaW4gdGhlIFdpbmRvd3Mgb3Bl cmF0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgc3lzdGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIElFVEYgU2VjcmV0 YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW2PR2101MB10495E1951F40C4CE6526413B6F60MW2PR2101MB1049_-- From nobody Tue Jul 9 03:13: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 ACB8F120401; Tue, 9 Jul 2019 03:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxMpjYRIkuXg; Tue, 9 Jul 2019 03:12:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BADF1203FC; Tue, 9 Jul 2019 03:12:56 -0700 (PDT) Received: from tpw09926dag12g.domain1.systemhost.net (10.9.212.28) by BWP09926083.bt.com (10.36.82.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 9 Jul 2019 11:13:22 +0100 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by tpw09926dag12g.domain1.systemhost.net (10.9.212.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 11:12:53 +0100 Received: from bwp09926084.bt.com (10.36.82.115) by tpw09926dag18e.domain1.systemhost.net (10.9.212.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 9 Jul 2019 11:12:53 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.56) by smtpe1.intersmtp.com (10.36.82.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 9 Jul 2019 11:08:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6dtNFo0eXzgG4gGDW3lWRD4uJspJd92MCsNx+m/GxKA=; b=XY7cen+pxdq6M6O4vof1CJTa46G70EO7WA6X/dIsGgsJ4ts3MOgMm7X+UPAnlM3eAmkH8dDAi3k4d0jObS0p9lV/1l0NIPmd1S9CSBZhoyHn2SsrcDSBax2D48at0n6BmahjTeDv+M02ZADEAYEj9U1Tf283A1LmLEqIrVZscdU= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB2123.GBRP123.PROD.OUTLOOK.COM (20.176.159.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Tue, 9 Jul 2019 10:07:59 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 10:07:59 +0000 From: To: , , CC: Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACioYfACL1MtoA== Date: Tue, 9 Jul 2019 10:07:59 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAAF3AA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAF3AA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8f58b7b-37ed-4e5b-2f16-08d704555282 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2123; x-ms-traffictypediagnostic: LNXP123MB2123: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(189003)(199004)(7696005)(305945005)(33656002)(74316002)(316002)(2906002)(102836004)(110136005)(99286004)(71190400001)(186003)(26005)(14454004)(4326008)(446003)(256004)(68736007)(8676002)(76176011)(6506007)(486006)(2501003)(11346002)(8936002)(476003)(71200400001)(81166006)(81156014)(25786009)(5660300002)(229853002)(86362001)(2201001)(73956011)(66946007)(66446008)(66476007)(52536014)(66556008)(64756008)(76116006)(6116002)(55016002)(7736002)(53936002)(9686003)(3846002)(6246003)(6436002)(478600001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2123; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K5+rKAWj+APPBpAZNr2OfaDLnFfPmtrZnolTh6XSsdlfmQ6BO3LykgQWi/k7Absk6U+ToX4kLLZPnuo8TaEg98cZ496enzr/WrYHZnZ8Mqg/2UEFFXVWMeGmkiiY/Q4J9Kap8gBferkfJuvCbWTjNgLoGACJyOQovOBc2MMe7UGddTn6sB2GqCsGn+5wikVS6F0YuYFB4v3Pfzw3unTlhNPOEzYSzFuw4rSx9GUgr8GDuzWSS2RENoKkOnEo8JbYlEEZCFRFaOulDMuIq96PUdeWm6S4LWxmdbBxk/scYCtAIyZDtvk9pL1RD5kwm2GHQF3p9PvTkAlNzQ+kcRgBeCURFGnIg9kvUcofa3LqRZkB09wsCvgVXo7aEB3IY5XRTgrOgeq8m1RoCEl4eJrAas+YeQeR23804tR4+C0TkSA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f8f58b7b-37ed-4e5b-2f16-08d704555282 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 10:07:59.7879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2123 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Report: 5 Rules triggered * 0.1 -- GEN_SPAM_FEATRE * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6585 X-NAI-Spam-Version: 2.2.0.9309 : core <6585> : inlines <7115> : streams <1826840> : uri <2865510> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 10:13:00 -0000 Med, Thanks, just following up a couple of points. >=20 > S4.1 title > "fixed header" - is "fixed" needed? [Med] It is fixed because it is present in all convert messages. Do you pre= fer "common" ? [phil] I'd prefer if you explicitly stated that all Convert messages have t= his header.=20 In fact, I think you could start Section 4 with text to capture the key poi= nts: "This section describes the messages that are exchanged between a Client an= d a Transport Converter. All Convert protocol messages MUST be sent on a SY= N, ACK or SYN-ACK, to port [tba]. All Convert protocol messages MUST be sen= t as the first bytes of the bytestream and MUST use the header shown in Fig= ure 9 and described in Section 4.1, followed by the message itself using th= e generic TLV format shown in Figure 10 and described in Section 4.2. " >=20 > " Transport Converter SHOULD include in this > list the TCP options that it accepts from Clients and that it > includes the SYN packets that it sends to initiate connections." > I couldn't parse the second part of the sentence ("and that it...") >=20 [Med] Changed to: " A Transport Converter SHOULD include in this list the TCP options that it accepts from Clients; these options are=20 included by the Transport Converter in the SYN packets that it sends to ini= tiate connections." Better?=20 [phil] Yes. Instead of "are included" you could say MUST /SHOULD /MAY > Section 6 > This section actually only discusses one type of middlebox (removes SYN). > Can the discussion be widened slightly [Med] This section only focuses on SYN/SYN-ACK because these are used by th= e Convert protocol. Do you have in mind a particular case (specific to the Convert protocol) th= at may be problematic? [phil] the section only discusses removal of SYN, and not other ways a midd= lebox could interfere with the SYN/ACK.=20 Thanks phil From nobody Tue Jul 9 03:13: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 5CAE41203FC; Tue, 9 Jul 2019 03:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JipulWSnOZEf; Tue, 9 Jul 2019 03:13:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA51120401; Tue, 9 Jul 2019 03:13:24 -0700 (PDT) Received: from tpw09926dag09e.domain1.systemhost.net (10.9.202.36) by BWP09926082.bt.com (10.36.82.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 9 Jul 2019 11:13:22 +0100 Received: from tpw09926dag05f.domain1.systemhost.net (10.9.202.24) by tpw09926dag09e.domain1.systemhost.net (10.9.202.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 11:13:22 +0100 Received: from bwp09926085.bt.com (10.36.82.116) by tpw09926dag05f.domain1.systemhost.net (10.9.202.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 9 Jul 2019 11:13:22 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.50) by smtpe1.intersmtp.com (10.36.82.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 9 Jul 2019 11:13:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bei0Skdoa0cYjwY/BZ2+DKo/9a9kLzKpY2roXjsvM0w=; b=HIVb/8uM0yhzo0Uuj/RRp/AOgdx4dqJYECG/ZqHXEasDqtU5JNQd50Zgy2+melbmmg6Ot7EG84wrQUBB+C/Ls/djcys40QOXOMOqQ4jwkHQtc/nK+iCeK75jf81wAfctSWNRZQsheZMkD74KdGT30yxGUvfczcG5Fg4V4VlQM/U= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB1979.GBRP123.PROD.OUTLOOK.COM (20.179.128.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Tue, 9 Jul 2019 10:12:46 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 10:12:45 +0000 From: To: , , CC: Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACyBV3ACLRGJsA== Date: Tue, 9 Jul 2019 10:12:43 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAAF429@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAF429@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e69faac5-43b1-4403-b4c1-08d70455fcb5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1979; x-ms-traffictypediagnostic: LNXP123MB1979: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(52314003)(189003)(199004)(76176011)(14444005)(66476007)(64756008)(66446008)(66556008)(14454004)(86362001)(76116006)(66946007)(2201001)(316002)(26005)(110136005)(71190400001)(7696005)(33656002)(6246003)(73956011)(71200400001)(6506007)(2501003)(53936002)(256004)(99286004)(186003)(9686003)(102836004)(5660300002)(55016002)(6116002)(3846002)(6436002)(81156014)(446003)(7736002)(8936002)(6306002)(68736007)(52536014)(81166006)(4326008)(8676002)(229853002)(25786009)(4744005)(305945005)(476003)(66066001)(11346002)(478600001)(486006)(74316002)(2906002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1979; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JzCB9PtF9Ujl6KtHdKUmzID1b0AxTWqzyoOIrIrCfA7ULsu3sNDCoD9OmPylMBEAXh8l5MDeZE5luwOTRt1OP34o5iVBTCEp1Q1iu1TNs1jRjDFVH5ZfhikibkkegUgFSWcUaMUEqBBMyeenum8KOSaY1FgPmtbsCVTz3bJa7LJOWg91WIVJGCp77y8+XdO0izLN4KYLVOtKT7X+y4rXGntwU9ZdFOPQUSrcA2/+lDGr4DFDdDUEwx52y712/WTcfHjs2VJH1OLBFr8Z8sNVZr9YJNPsFRhTAUGhqUCQtQCf85Xb4VQUhw67I/y+QMFNzw+Hq6AFgQUDkKR8oj0Co61UdB0zanwcyKWpXkC0eqyaZvhgwbmzWdLkMbHkQFQ7Oi0p7WTviFTIYGg9uHHB+kReV25vv3/JdK0IhpWbf+0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e69faac5-43b1-4403-b4c1-08d70455fcb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 10:12:44.3608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1979 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 2 X-NAI-Spam-Report: 9 Rules triggered * 1 -- SJEY_DJEPYSY_W_SORT_LNK_1HTP_CTPLN * 0.5 -- SJEY_DJEPYSY * 0.2 -- SORT_LNK_1HTP_CTPLN * 0.1 -- GEN_SPAM_FEATRE * 0.1 -- SORT_LNK_1HTP_CTPLN_W_GEN_SPAM_FEATRE * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6585 X-NAI-Spam-Version: 2.2.0.9309 : core <6585> : inlines <7115> : streams <1826840> : uri <2865511> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 10:13:28 -0000 >=20 > I think it would be great if Section 3 was expanded into a "protocol=20 > model" https://tools.ietf.org/html/rfc4101 in particular to expand on [Med] Section 3 is purposely edited "to quickly grasp the essence of" the c= onvert protocol. It focuses on the main design rationale that is use one si= ngle SYN to supply data to a converter. That supplied data is unambiguously= distinguished by means of TLVs and location within the payload. =20 [phil] that's exactly the purpose of a protocol model. The full protocol de= scription is just for people who need to understand the details, implemente= rs etc. Anyway, I leave you to think about it and edit as you feel best.=20 From nobody Tue Jul 9 03:33: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 8412712041D; Tue, 9 Jul 2019 03:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB8ccFrn_2jh; Tue, 9 Jul 2019 03:33:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E68B120404; Tue, 9 Jul 2019 03:33:03 -0700 (PDT) Received: from tpw09926dag08f.domain1.systemhost.net (10.9.202.39) by BWP09926083.bt.com (10.36.82.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 9 Jul 2019 11:33:29 +0100 Received: from tpw09926dag10f.domain1.systemhost.net (10.9.202.41) by tpw09926dag08f.domain1.systemhost.net (10.9.202.39) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jul 2019 11:33:00 +0100 Received: from bwp09926078.bt.com (10.36.82.109) by tpw09926dag10f.domain1.systemhost.net (10.9.202.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 9 Jul 2019 11:33:00 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.56) by smtpe1.intersmtp.com (10.36.82.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 9 Jul 2019 11:32:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c0P5FDR4hnYXYUWg/fqsgBQKXgKOUBopqIBJpDj/kvU=; b=DYlUm9YUm2NUjeo3OiiCeKWFJbmVhb4BUDSnX1xyUbcbHOfemTpeP9ngibiIarIcKYa2ENfTk4/6y7n3Q4zile0aN6jWeEQ0zfv/8fWz6SCyXX/fLOpxqlkhdsgAfbLILaKm27Kv9BoVERwtwElUZETZtOfzo9pO4Ot6eUf2pxs= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB1946.GBRP123.PROD.OUTLOOK.COM (20.179.128.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Tue, 9 Jul 2019 10:32:58 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 10:32:58 +0000 From: To: , , CC: Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwAMW68XAAMI3dUAFkFuUA Date: Tue, 9 Jul 2019 10:32:58 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAB0E38@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAB0E38@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e87ba3c2-85c9-4eac-e07e-08d70458cfde x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LNXP123MB1946; x-ms-traffictypediagnostic: LNXP123MB1946: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(346002)(39860400002)(366004)(13464003)(189003)(199004)(8936002)(476003)(81156014)(81166006)(6506007)(110136005)(6436002)(53546011)(25786009)(71200400001)(316002)(966005)(71190400001)(33656002)(102836004)(305945005)(478600001)(74316002)(3846002)(4326008)(6246003)(2906002)(6116002)(53936002)(68736007)(8676002)(229853002)(86362001)(7696005)(2501003)(2201001)(5660300002)(14454004)(486006)(256004)(14444005)(52536014)(76176011)(66446008)(99286004)(66556008)(55016002)(66476007)(9686003)(66946007)(64756008)(186003)(73956011)(76116006)(66066001)(11346002)(7736002)(26005)(446003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1946; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 61hYsy1Mn6u7szk7xuNACPwvsn3KbAi4T9KceUfInqYntolBw/EG0xhuOWacIjt07tTsbsQx2eNSGbopT/pxd185uo9w5qF8MNCXJvvqfpkAoPEv3CbcPegJNDpubC4z6PYSIBIh3e6hbrFcgEKCBbACeMCdU0TG6BUF/shw/EJjRr+LeJyvy+UF7IPblvmoB/D91C4BvmdMQZmFToPeMMnSmG2WX9KwDHMbBhYtHYjtmHI/wKmsr5487tAUqpqLCK0meYo7a3k5qeUYZtZE4mCTk56IOiqNoa+rZr1MsYo34qcMG21TT4GP4vwvtp6Oihmy2D1khzVSBNu/Ow7KHo3MTMHatz3YV6us38w1j3MU7Qy18pz8X4Kw5QBUKSldkD1OPHn2nucBblA+GtMfHEpu1XTv/bYuT4Y9WKoxQ9s= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e87ba3c2-85c9-4eac-e07e-08d70458cfde X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 10:32:58.5298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1946 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Report: 5 Rules triggered * 0.1 -- GEN_SPAM_FEATRE * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6585 X-NAI-Spam-Version: 2.2.0.9309 : core <6585> : inlines <7115> : streams <1826841> : uri <2865516> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 10:33:08 -0000 Med - thanks - no follow-ups phil -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 02 July 2019 10:05 To: Eardley,PL,Philip,TUD1 R ; Michael.Scharf@hs-ess= lingen.de; tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: RE: WGLC for draft-ietf-tcpm-converters-08 Hi Phil, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de=20 > philip.eardley@bt.com Envoy=E9=A0: lundi 1 juillet 2019 12:04 =C0=A0:=20 > philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; tcpm@ietf.org=20 > Cc=A0: tcpm-chairs@ietf.org Objet=A0: Re: [tcpm] WGLC for=20 > draft-ietf-tcpm-converters-08 >=20 > Finishing my review... >=20 > Section 4.2.8 Error TLV > Resource exceeded & Network failure > " The > Transport Converter may indicate in the Value field the suggested > delay (in seconds) that the Client SHOULD wait before soliciting > the Transport Converter for a new proxied connection. A Value of > zero corresponds to a default delay of at least 30 seconds." > Are there any circumstances in which a Transport Converter may want to=20 > suggest that the Client waits less than one second before re-trying? [Med] The errors we identified so far do not have such requirements.=20 >=20 > Section 7.5 Multipath TCP-specific Considerations " aggregation=20 > service" -> multipath TCP converter service? [Med] OK. >=20 > " This method does not require any interaction > with the Transport Converter." [twice] You could say interaction=20 > of what (since something is interacting with > it!) [Med] added "... for authorization matters." >=20 > Section 8 IANA Considerations > Convert TLVs > It has a range assigned via IETF review, a range assigned via=20 > Specification required and a range for Private use. Wouldn't it be=20 > simpler to choose either IETF review or Specification required (plus priv= ate use)? > I think Specification required would be ok, given the RFC will be=20 > Experimental. [Med] We are simplifying the assignment for some code points while allowing= for a range to be reserved to key extensions. This is simple compared to "= Standards Action" I have seen in some experimental RFCs!=20 >=20 > Convert Error Messages > It has a range assigned via IETF review and a range assigned via=20 > Specification required. > Same comment as above, except more strongly - for error messages, IETF=20 > review seems excessive to me. [Med] Why? The same considerations (interoperability) apply for the error c= odes and TLVs. =20 > Also, would it be useful to have some space for Private use? [Med] Makes sense.=20 >=20 > Section 11 Example Socket API Changes to Support the 0-RTT Convert=20 > Protocol " As an example, on Linux, a client can send the 0-RTT=20 > Convert message > inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in > the example below" > Is this example right? [Med] Yes.=20 Since Transport Converter now uses TLV messages > rather than TFO? [Med] This is about the control flags.=20 >=20 > Section 12 > " A recently > proposed extension to SOCKS also leverages the TFO option" > I think "also" should be deleted (since Transport Converter now uses=20 > TLV messages rather than TFO) [Med] OK. >=20 > Section 13 > [RFC6824] > Would be good to update to the bis document (which has currently=20 > completed IESG - I think waiting for AD follow-up) [Med] Will consider this once the bis is sent to the RFC editor.=20 FWIW, the changes to address this review can be seen at: https://github.com= /obonaventure/draft-tcp-converters/pull/65/files=20 >=20 > Thanks - best wishes, > phil From nobody Tue Jul 9 05:16: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 CDA3A120140; Tue, 9 Jul 2019 05:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ocV7WZj6AGo; Tue, 9 Jul 2019 05:16:04 -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 0D72812013C; Tue, 9 Jul 2019 05:16:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0598725A19; Tue, 9 Jul 2019 14:16:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1562674562; bh=XmQ2rmGc6bU36riYRLZeH1xXRD7agWuFhObmc84Dcp8=; h=From:To:CC:Subject:Date:From; b=svo2Cjsl01B8ssgEkiFgQkLjRZKNco97uEEILCQf6t6y0uY8hr/njn7jJG5mfW2Br Za6nivx7NvI8crjrPw2ieFe7FWgANBjZ+ELOh5CgxQVtyfMUbR5ZO1H+RE+Jj/ZOqC uO9j/maJ/lzRCBLDA7wDHHMN+pagVtlnr9DACF5k= 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 HuOpFUZoM7Qz; Tue, 9 Jul 2019 14:16:01 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 9 Jul 2019 14:16:01 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.38]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 9 Jul 2019 14:16:00 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org Extensions" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgK3RwHg Date: Tue, 9 Jul 2019 12:16:00 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D38D7D0@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.63.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 12:16:07 -0000 Hi all, I'd like to ensure that the TCPM working group is aware of the following IP= R disclosure and the licensing declaration: https://datatracker.ietf.org/ip= r/3616/ The IETF takes no position regarding the validity or scope of any intellect= ual property rights or other rights that might be claimed to pertain to the= implementation or use of the technology described in any IETF documents or= the extent to which any license under such rights might or might not be av= ailable; nor does it represent that it has made any independent effort to i= dentify any such rights. The working group last call for the document is ongoing. As already noted, = in absence of feedback we will assume that the TCPM consensus is to move th= e document to the IESG. Thanks Michael > -----Original Message----- > From: Scharf, Michael > Sent: Tuesday, June 25, 2019 6:39 PM > To: tcpm@ietf.org Extensions > Cc: tcpm-chairs@ietf.org > Subject: WGLC for draft-ietf-tcpm-converters-08 >=20 > Hi all, >=20 > draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. >=20 > Therefore, this e-mail starts a working group last call (WGLC) for draft-= ietf- > tcpm-converters-08 that will run until ***July 14, 2019***. >=20 > Please let us know if there are any remaining open issues regarding this > document. Statements supporting publication are also welcome. In absence > of feedback we will assume that the TCPM consensus is to move the > document to the IESG. As discussed in the past, the intended status of th= e > document is experimental. >=20 > Thanks a lot >=20 > Michael > (TCPM co-chair) From nobody Tue Jul 9 06:49: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 5518D12007C; Tue, 9 Jul 2019 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHec42ecx07n; Tue, 9 Jul 2019 06:49:49 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E2A120139; Tue, 9 Jul 2019 06:49:49 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 45jkG409Rlz8t00; Tue, 9 Jul 2019 15:49:48 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 45jkG368Ykz2xCg; Tue, 9 Jul 2019 15:49:47 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 15:49:47 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACioYfACL1MtoAAE0urA Date: Tue, 9 Jul 2019 13:49:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAC7701@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B93302EAAF3AA@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 13:49:53 -0000 Hi Phil, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Envoy=E9=A0: mardi 9 juillet 2019 12:08 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de; > tcpm@ietf.org > Cc=A0: tcpm-chairs@ietf.org > Objet=A0: RE: WGLC for draft-ietf-tcpm-converters-08 >=20 > Med, > Thanks, just following up a couple of points. > > > > S4.1 title > > "fixed header" - is "fixed" needed? >=20 > [Med] It is fixed because it is present in all convert messages. Do you > prefer "common" ? >=20 > [phil] I'd prefer if you explicitly stated that all Convert messages have > this header. > In fact, I think you could start Section 4 with text to capture the key > points: > "This section describes the messages that are exchanged between a Client > and a Transport Converter. All Convert protocol messages MUST be sent on = a > SYN, ACK or SYN-ACK, to port [tba]. All Convert protocol messages MUST be > sent as the first bytes of the bytestream and MUST use the header shown i= n > Figure 9 and described in Section 4.1, followed by the message itself > using the generic TLV format shown in Figure 10 and described in Section > 4.2. " [Med] Thanks. Some of this proposed text is redundant with existing text, e= .g., The Client and the Transport Converter MUST send the fixed-sized header, shown in Figure 9, as the first four bytes of the bytestream. While other part of the text may not be accurate for incoming connections (= MUST be sent ...to port (TBA)). Now that I see more your point, I made some tweaking to address your commen= t as shown in: https://github.com/obonaventure/draft-tcp-converters/pull/63/files=20 >=20 > > > > " Transport Converter SHOULD include in this > > list the TCP options that it accepts from Clients and that it > > includes the SYN packets that it sends to initiate connections." > > I couldn't parse the second part of the sentence ("and that it...") > > >=20 > [Med] Changed to: >=20 > " A Transport Converter SHOULD include in > this list the TCP options that it accepts from Clients; these options are > included by the Transport Converter in the SYN packets that it sends to > initiate connections." >=20 > Better? >=20 > [phil] Yes. Instead of "are included" you could say MUST /SHOULD /MAY [Med] This would be redundant with the "SHOULD" in that text.=20 >=20 >=20 > > Section 6 > > This section actually only discusses one type of middlebox (removes > SYN). > > Can the discussion be widened slightly >=20 > [Med] This section only focuses on SYN/SYN-ACK because these are used by > the Convert protocol. >=20 > Do you have in mind a particular case (specific to the Convert protocol) > that may be problematic? >=20 > [phil] the section only discusses removal of SYN, and not other ways a > middlebox could interfere with the SYN/ACK. [Med] The following cases can be considered for SYN/ACKs:=20 (1) a middlebox that drops SYN/ACKs having a payload is straightforward. Th= e client won't naturally be able to establish the connection via the conver= ter. =20 (2) a middlebox that removes the payload of SYN/ACKs: 2-a. If that middlebox removes also the payload of SYNs (which is likely),= this would have been detected by the client as per the text already in the= draft.=20 2-b. If that middlebox lets pass SYNs with their payload but removes the p= ayload of SYN/ACKs (for some mysterious reasons): This can be easily handle= d by the client because it expects an Error or Extended TCP Header TLV in t= he response. If an Error TLV was included, a message to terminate the conne= ction would be sent by the Converter. Otherwise, there is no reason to clos= e the connection. =20 Do you think that "2-b" is likely and is worth to be documented in the text= ? Thank you. =20 >=20 > Thanks > phil From nobody Tue Jul 9 07:44:40 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD095120486; Tue, 9 Jul 2019 07:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=mb5C7rDW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=JsOfgdW7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyKfytUSon-B; Tue, 9 Jul 2019 07:44:32 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0AF120485; Tue, 9 Jul 2019 07:44:32 -0700 (PDT) Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x69Ee8xK004813; Tue, 9 Jul 2019 10:43:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=ZKIHq/7KR9vNEbykE4JilpU/BdtA+5tobk8fM0SLt3Q=; b=mb5C7rDWJD3U1oL1DafHQvRbH3jHnepGGdmpQJEMiiAIS/TSBZLGu7f+AMM+nTq7lkvd TuWtx+4P9FlhIwisz+lgu1yfCWNvsIcnVrkm8/e0s868ZaGKzQzkwrWuQwC5/67HKZi/ V9fDi8UMNH2iBwRSjfUEi0cFAvtvY72edcaQik2vndy6Ww68xW4WGaxMInOKFIuMKiTC 5Qrgn9lDQZCzhhP+k0u4uSM30oNoZtXvSwu5Oy+gqB9Wx6zP3JP/mvoVGWSWqH4Brjf0 +3GFXXPxRqnonHoVVuftms0DAqwX9RRoAPE4RTbBdOuWhQbHC5bKTt8fEVR9X9CbwH6C UQ== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2tme96kjj9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Jul 2019 10:43:48 -0400 Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x69EhXtZ061183; Tue, 9 Jul 2019 10:43:48 -0400 Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0b-00154901.pphosted.com with ESMTP id 2tmv8c0y17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 09 Jul 2019 10:43:47 -0400 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x69EhcVb018503 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jul 2019 10:43:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x69EhcVb018503 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1562683426; bh=A5HiedJrzjeOK++NfS9g4fpV3rY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=JsOfgdW7h142tvXUm0ulvqGwKrJuHkF0709jCMn4hhK/maESH+2FRVDhlGYRkUHjS QtGTmahS+ciE42jfk9Tj7xJgy1gOZyFLNLParg6eNfvtTt2r75KU6UNzL3sR1Lbhww yuOWXx+zBETSqxOwjT+Eg6+JLoogxy+FUy6DPTG0= Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Tue, 9 Jul 2019 10:41:05 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x69Ef54r027571 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 9 Jul 2019 10:41:05 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 10:41:04 -0400 From: "Black, David" To: Bob Briscoe , "ecn-sane@lists.bufferbloat.net" , tcpm IETF list CC: tsvwg IETF list , "Black, David" Thread-Topic: [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S Thread-Index: AQHVIgfVHJuiHQ6zPkakYH0F258pwabCeiqw Date: Tue, 9 Jul 2019 14:41:04 +0000 Message-ID: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> In-Reply-To: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-09T14:09:55.0166457Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.238.21.131] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363060CC9CMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907090176 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907090176 Archived-At: Subject: Re: [tcpm] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 14:44:37 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363060CC9CMX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9iLA0KDQpDb21tZW50aW5nIGFzIGFuIGluZGl2aWR1YWwsIG5vdCBhIFdHIGNoYWlyLg0KDQo+ IFEjMTogSWYgdGhpcyBnbG9zc2VzIG92ZXIgYW55IGNvbmNlcm5zIHlvdSBoYXZlLCBwbGVhc2Ug ZXhwbGFpbi4NCg0KSXQgZG9lcyBnbG9zcyBvdmVyLCBhdCBsZWFzdCBmb3IgbWUuICBUaGUgVEw7 RFIgc3VtbWFyeSBpcyB0aGF0IGl0ZW1zIDEtMyBhcmVu4oCZdCByZWxldmFudCBvciBoZWxwZnVs LCBJTUhPLCBsZWF2aW5nIGl0ZW1zIDQgYW5kIDUsIHdob3NlIGVmZmVjdGl2ZW5lc3MgZGVwZW5k cyBvbiB3aWRlc3ByZWFkIGRlcGxveW1lbnQgb2YgUkFDSyBhbmQgRlEgQVFNcyAoZS5nLiwgRlEt Q29EZWwpIHJlc3BlY3RpdmVseS4NCg0KSXRlbXMgMSAmIDI6IFRoZSBnZW5lcmFsIGV4cGVjdGF0 aW9uIGZvciBJbnRlcm5ldCB0cmFuc3BvcnQgcHJvdG9jb2xzIGlzIHRoYXQgdGhleeKAmXJlIHJv YnVzdCBhZ2FpbnN0IOKAnHN0dXBpZCBuZXR3b3JrIHRyaWNrc+KAnSBsaWtlIHJlb3JkZXJpbmcs IGJ1dCBleGlzdGluZyBwcm90b2NvbHMgdHJhbnNwb3J0IHdpbmQgdXAgYmVpbmcgZGVzaWduZWQv aW1wbGVtZW50ZWQgZm9yIHRoZSBuZXR3b3JrIHdlIGhhdmUsIG5vdCB0aGUgb25lIHdlIHdpc2gg d2UgaGFkLiAgSeKAmW0gZ2VuZXJhbGx5IHNrZXB0aWNhbCBvZiDigJxoaWdobHkgdW5saWtlbHni gJ0gYXJndW1lbnRzLCBhcyBob3JyZW5kb3VzIHJlc3VsdHMgaW4gYSBoaWdobHkgdW5saWtlbHkg c2NlbmFyaW8gYXJlIG5vdCBhY2NlcHRhYmxlIGlmIHRoYXQgc2NlbmFyaW8gb2NjdXJzIHJlcGVh dGVkbHksIGV2ZW4gd2l0aCBsb25nIGludGVydmFscyBpbiBiZXR3ZWVuIG9jY3VycmVuY2VzLiAg SW4gbGlnaHQgb2YgdGhhdCwgSSB2aWV3IGl0ZW1zIDEgYW5kIDIgYXMgZGVmaW5pbmcgdGhlIHBy b2JsZW0gc2NlbmFyaW8gdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQsIHBhcnRpY3VsYXJseSBp ZiBMNFMgaXMgdG8gYmUgd2lkZWx5IGRlcGxveWVkLCBhbmQgcHJlZmVyIHRvIGZvY3VzIG9uIGl0 ZW1zIDMtNSBhYm91dCBob3cgdGhlIHByb2JsZW0gaXMgZGVhbHQgd2l0aC4NCg0KSXRlbSAzOiBU aGlzIGJlZ2lucyBieSBjb3JyZWN0bHkgcG9pbnRzIG91dCB0aGF0IDNEdXBBQ0sgaXMgdGhlIGNy aXRlcmlhIGZvciB0cmlnZ2VyaW5nIGNvbnZlbnRpb25hbCBUQ1AgcmV0cmFuc21pc3Npb24sIGUu Zy4sIDJEdXBBQ0sgZG9lc27igJl0LiAgQW4gYXNwZWN0IHRoYXQgaXNu4oCZdCBtZW50aW9uZWQg aXMgdGhhdCBBUU1zIGZvciBjbGFzc2ljIChub24tTDRTKSB0cmFmZmljIHNob3VsZCBiZSByYW5k b21seSBtYXJraW5nIChhYm92ZSBhIHF1ZXVlIHRocmVzaG9sZCwgQ0UgbWFya2luZyBwcm9iYWJp bGl0eSBkZXBlbmRzIG9uIHF1ZXVlIG9jY3VwYW5jeSksIG5vdCB0aHJlc2hvbGQgbWFya2luZyAo YWJvdmUgYSBxdWV1ZSB0aHJlc2hvbGQsIG1hcmsgYWxsIHBhY2tldHMgd2l0aCBDRSkuICBJZiB0 aHJlc2hvbGQgbWFya2luZyBpcyB1c2VkLCAzIENFIG1hcmtzIGluIGEgcm93IGlzIGEgbmVhciBj ZXJ0YWludHksIGFzIGZvciBub24tbWljZSBmbG93cywgb25lIGNhbiBleHBlY3QgdG8gaGF2ZSBh dCBsZWFzdCB0aGF0IG1hbnkgcGFja2V0cyBpbiBhbiBSVFQgd2luZG93OyB0aGlzIGlzIGEg4oCc RG9jdG9yIGl0IGh1cnRzIHdoZW4gSSBkbyA8dGhpcz4u4oCdL+KAnURvbuKAmXQgZG8gdGhhdCHi gJ0gc2NlbmFyaW8gd2hlcmUgdGhlIHJpZ2h0IGFuc3dlciBpcyB0byBmaXggdGhlIGJyb2tlbiB0 aHJlc2hvbGQgbWFya2luZyBpbXBsZW1lbnRhdGlvbi4NCg0KQXNzdW1pbmcgcHJvYmFiaWxpc3Rp YyBtYXJraW5nLCBvbmUgdGhlbiBuZWVkcyB0byBsb29rIGF0IDMtaW4tYS1yb3cgQ0UgbWFya2lu ZyBwcm9iYWJpbGl0aWVzIGJhc2VkIG9uIHRoZSBtYXJraW5nIHJhdGUuICBUaGVzZSBhcmUgbm90 IHNtYWxsIC0gZm9yIGV4YW1wbGUsIGF0IGEgMTAlIG1hcmtpbmcgcHJvYmFiaWxpdHksIHRoZSBs aWtlbGlob29kIG9mIENFLW1hcmtpbmcgMyBwYWNrZXRzIGluIGEgcm93IHN0YXJ0aW5nIGZyb20g YSBzcGVjaWZpYyBwYWNrZXQgaXMgMSBpbiAxLDAwMCAoMS8xMHRoIG9mIDElKSwgYnV0IGFjcm9z cyA1MDAgcGFja2V0cyBpbiBhIGZsb3csIHRoYXQgcHJvYmFiaWxpdHkgaXMgYWJvdXQgNTAlLiAg IE15IGluaXRpYWwgdGFrZS1hd2F5IGZyb20gdGhpcyBpcyB0aGF0IGlmIHRoZSB0d28gYm90dGxl bmVja3MgKGNvbnZlbnRpb25hbCBmb2xsb3dlZCBieSBMNFMpIHBlcnNpc3QsIHRoZW4gdGhlIOKA nHVudXN1YWwgc2NlbmFyaW/igJ0gb2YgMyBDRS1tYXJrZWQgcGFja2V0cyBpbiBhIHJvdyBpcyBu ZWFybHkgY2VydGFpbiB0byBoYXBwZW4sIHdoaWNoIHN1Z2dlc3RzIHRoYXQgaXRlbSAzIGlzIG5v dCBwYXJ0aWN1bGFybHkgaGVscGZ1bCwgbGVhdmluZyBpdGVtcyA0IChSQUNLKSBhbmQgNSAoRlEt Q29EZWwpLg0KDQpTbywgd2hpbGUgSSBkb27igJl0IGhhdmUgYSBjb25jbHVzaW9uIHRvIGRyYXcs IGl0IGFwcGVhcnMgdG8gbWUgdGhhdCB0aGUgY291bnRlcm1lYXN1cmVzIHRvIHRoaXMgY29udmVu dGlvbmFsIFRDUCBmbG93IG1pc2JlaGF2aW9yIHdpdGggTDRTIGFyZSBkZXBsb3ltZW50IG9mIFJB Q0sgYXQgZW5kcG9pbnRzIGFuZCBkZXBsb3ltZW50IG9mIEZRIEFRTXMgc3VjaCBhcyBGUS1Db0Rl bCBhdCBub24tTDRTIHBvdGVudGlhbCBib3R0bGVuZWNrIG5vZGVzLiAgSXRlbXMgNCBhbmQgNSBi ZWxvdyBlZmZlY3RpdmVseSBhc3NlcnQgd2lkZSBkZXBsb3ltZW50IG9mIHRob3NlIGFsZ29yaXRo bXMg4oCTIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYW5kIGRhdGEgb24gdGhhdCB3b3VsZCBiZSBv ZiBpbnRlcmVzdC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCkZyb206IHRzdndnIDx0c3Z3Zy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQm9iIEJyaXNjb2UNClNlbnQ6IFRodXJzZGF5LCBK dW5lIDEzLCAyMDE5IDEyOjQ4IFBNDQpUbzogZWNuLXNhbmVAbGlzdHMuYnVmZmVyYmxvYXQubmV0 OyB0Y3BtIElFVEYgbGlzdA0KQ2M6IHRzdndnIElFVEYgbGlzdA0KU3ViamVjdDogW3RzdndnXSBF Q04gQ0UgdGhhdCB3YXMgRUNUKDApIGluY29ycmVjdGx5IGNsYXNzaWZpZWQgYXMgTDRTDQoNCg0K W0VYVEVSTkFMIEVNQUlMXQ0KDQpbSSdtIHNlbmRpbmcgdGhpcyB0byBlY24tc2FuZSAnY29zIHRo YXQncyB3aGVyZSBJIGRldGVjdCB0aGF0IHRoaXMgY29uY2VybiBpcyBzdGlsbCBydW1ibGluZy4N CkknbSBhbHNvIHNlbmRpbmcgdG8gdGNwbUBpZXRmICdjb3MgdGhlcmUncyBhIHF1ZXN0aW9uIGZv ciBUQ1AgZXhwZXJ0cyBqdXN0IGJlZm9yZSB0aGUgcXVvdGVkIHRleHQgYmVsb3cuDQpBbmQgdHN2 d2dAaWV0ZiBpcyB3aGVyZSBpdCBvdWdodCB0byBiZSBkaXNjdXNzZWQuXQ0KDQpOb3cgdGhhdCB0 aGUgSVBSIGlzc3VlIHdpdGggTDRTIGhhcyBiZWVuIHB1dCB0byBiZWQsIG9uZSBieSBvbmUgSSBh bSBnb2luZyB0aHJvdWdoIHRoZSBvdGhlciBjb25jZXJucyB0aGF0IGhhdmUgYmVlbiByYWlzZWQg YWJvdXQgTDRTLg0KDQpJbiB0aGUgSUVURiBkcmFmdCB0aGF0IHJlY29yZHMgYWxsIHRoZSBwcm9z IGFuZCBjb25zIG9mIGRpZmZlcmVudCBpZGVudGlmaWVycyB0byB1c2UgZm9yIEw0UywgdW5kZXIg dGhlICJFQ1QoMSkgYW5kIENFIiBjaG9pY2UgKHdoaWNoIGlzIGN1cnJlbnRseSB0aGUgb25lIGFk b3B0ZWQgYXQgdGhlIElFVEYpIHRoZXJlIHdhcyBhbHJlYWR5IGFuIGV4cGxhbmF0aW9uIG9mIHdo eSB0aGVyZSB3b3VsZCBiZSB2YW5pc2hpbmdseSBsb3cgcmlzayBvZiBhbnkgaGFybWZ1bCBjb25z ZXF1ZW5jZXMgZnJvbSBDRSB0aGF0IHdhcyBvcmlnaW5hbGx5IEVDVCgwKSBiZWluZyBjbGFzc2lm aWVkIGludG8gdGhlIEw0UyBxdWV1ZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDYjcGFnZS0zMg0KDQpSZS1yZWFkaW5nIHRoYXQsIEkg aGF2ZSBmb3VuZCBzb21lIHRoaW5ncyB1bnN0YXRlZCB0aGF0IEkgaGFkIHRob3VnaHQgd2VyZSBv YnZpb3VzLiBTbyBJJ3ZlIHNwZWxsZWQgaXQgYWxsIG91dCBsb25nLWhhbmQgaW4gdGhlIHRleHQg YmVsb3csIHdoaWNoIGlzIG5vdyBpbiBteSBsb2NhbCBjb3B5IG9mIHRoZSBkcmFmdCBhbmQgd2ls bCBiZSBpbiB0aGUgbmV4dCByZXZpc2lvbiB1bmxlc3MgcGVvcGxlIHN1Z2dlc3QgaW1wcm92ZW1l bnRzL2NvcnJlY3Rpb25zIGhlcmUuDQoNClEjMTogSWYgdGhpcyBnbG9zc2VzIG92ZXIgYW55IGNv bmNlcm5zIHlvdSBoYXZlLCBwbGVhc2UgZXhwbGFpbi4NCk90aGVyd2lzZSBJIHdpbGwgY29udGlu dWUgdG8gY29uc2lkZXIgdGhhdCB0aGlzIGlzIGVmZmVjdGl2ZWx5IGEgbm9uLWlzc3VlLCB3aGlj aCBpcyB0aGUgY29uY2x1c2lvbiBldmVyeW9uZSBpbiB0aGUgVENQIGNvbW11bml0eSBjYW1lIHRv IGF0IHRoZSB0aW1lIHRoZSBMNFMgaWRlbnRpZmllciB3YXMgY2hvc2VuIGJhY2sgaW4gMjAxNS4N Cg0KUSMyOiBUaGUgbGFzdCBjb3VwbGUgb2YgbGluZXMgYXJlIHRoZSBvbmx5IHBhcnQgSSBhbSBu b3Qgc3VyZSBvZi4gRG8gbW9zdCBvZiB0b2RheSdzIFRDUCBpbXBsZW1lbnRhdGlvbnMgcmVjb3Zl ciB0aGUgcmVkdWN0aW9uIGluIGNvbmdlc3Rpb24gd2luZG93IHdoZW4gdGhleSBkaXNjb3ZlciBs YXRlciB0aGF0IGEgZmFzdCByZXRyYW5zbWl0IHdhcyBzcHVyaW91cz8gVGhlcmUncyBhIG5vdGUg YXQgdGhlIGVuZCBvZiB0aGUgaW50cm8gdG8gcmZjNDAxNSBzYXlpbmcgdGhlcmUgd2FzIGluc3Vm ZmljaWVudCBjb25zZW5zdXMgdG8gc3RhbmRhcmRpemUgdGhpcyBiZWhhdmlvdXIsIGJ1dCB0aGF0 IG1vc3QgbGlrZWx5IG1lYW5zIGl0J3MgZG9uZSBpbiBkaWZmZXJlbnQgd2F5cywgcmF0aGVyIHRo YW4gaXQgaXNuJ3QgZG9uZSBhdCBhbGwuDQoNCg0KQm9iDQoNCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCg0KICAgUmlzayBvZiByZW9yZGVyaW5nIGNsYXNzaWMgQ0Ug cGFja2V0czogIENsYXNzaWZ5aW5nIGFsbCBDRSBwYWNrZXRzDQoNCiAgICAgIGludG8gdGhlIEw0 UyBxdWV1ZSByaXNrcyBhbnkgQ0UgcGFja2V0cyB0aGF0IHdlcmUgb3JpZ2luYWxseQ0KDQogICAg ICBFQ1QoMCkgYmVpbmcgaW5jb3JyZWN0bHkgY2xhc3NpZmllZCBhcyBMNFMuICBJZiB0aGVyZSB3 ZXJlIGRlbGF5DQoNCiAgICAgIGluIHRoZSBDbGFzc2ljIHF1ZXVlLCB0aGVzZSBpbmNvcnJlY3Rs eSBjbGFzc2lmaWVkIENFIHBhY2tldHMNCg0KICAgICAgd291bGQgYXJyaXZlIGVhcmx5LCB3aGlj aCBpcyBhIGZvcm0gb2YgcmVvcmRlcmluZy4gIFJlb3JkZXJpbmcgY2FuDQoNCiAgICAgIGNhdXNl IFRDUCBzZW5kZXJzIChhbmQgc2VuZGVycyBvZiBzaW1pbGFyIHRyYW5zcG9ydHMpIHRvDQoNCiAg ICAgIHJldHJhbnNtaXQgc3B1cmlvdXNseS4gIEhvd2V2ZXIsIHRoZSByaXNrIG9mIHNwdXJpb3Vz DQoNCiAgICAgIHJldHJhbnNtaXNzaW9ucyB3b3VsZCBiZSBleHRyZW1lbHkgbG93IGZvciB0aGUg Zm9sbG93aW5nIHJlYXNvbnM6DQoNCg0KDQogICAgICAxLiAgSXQgaXMgcXVpdGUgdW51c3VhbCB0 byBleHBlcmllbmNlIHF1ZXVpbmcgYXQgbW9yZSB0aGFuIG9uZQ0KDQogICAgICAgICAgYm90dGxl bmVjayBvbiB0aGUgc2FtZSBwYXRoICh0aGUgYXZhaWxhYmxlIGNhcGFjaXRpZXMgaGF2ZSB0bw0K DQogICAgICAgICAgYmUgaWRlbnRpY2FsKS4NCg0KDQoNCiAgICAgIDIuICBJbiBvbmx5IGEgc3Vi c2V0IG9mIHRoZXNlIHVudXN1YWwgY2FzZXMgd291bGQgdGhlIGZpcnN0DQoNCiAgICAgICAgICBi b3R0bGVuZWNrIHN1cHBvcnQgY2xhc3NpYyBFQ04gbWFya2luZyB3aGlsZSB0aGUgc2Vjb25kDQoN CiAgICAgICAgICBzdXBwb3J0ZWQgTDRTIEVDTiBtYXJraW5nLCB3aGljaCB3b3VsZCBiZSB0aGUg b25seSBzY2VuYXJpbw0KDQogICAgICAgICAgd2hlcmUgc29tZSBFQ1QoMCkgcGFja2V0cyBjb3Vs ZCBiZSBDRSBtYXJrZWQgYnkgYSBub24tTDRTIEFRTQ0KDQogICAgICAgICAgdGhlbiB0aGUgcmVt YWluZGVyIGV4cGVyaWVuY2VkIGZ1cnRoZXIgZGVsYXkgdGhyb3VnaCB0aGUNCg0KICAgICAgICAg IENsYXNzaWMgc2lkZSBvZiBhIHN1YnNlcXVlbnQgTDRTIER1YWxRIEFRTS4NCg0KDQoNCiAgICAg IDMuICBFdmVuIHRoZW4sIHdoZW4gYSBmZXcgcGFja2V0cyBhcmUgZGVsaXZlcmVkIGVhcmx5LCBp dCB0YWtlcw0KDQogICAgICAgICAgdmVyeSB1bnVzdWFsIGNvbmRpdGlvbnMgdG8gY2F1c2UgYSBz cHVyaW91cyByZXRyYW5zbWlzc2lvbiwgaW4NCg0KICAgICAgICAgIGNvbnRyYXN0IHRvIHdoZW4g c29tZSBwYWNrZXRzIGFyZSBkZWxpdmVyZWQgbGF0ZS4gIFRoZSBmaXJzdA0KDQogICAgICAgICAg Ym90dGxlbmVjayBoYXMgdG8gYXBwbHkgQ0UtbWFya3MgdG8gYXQgbGVhc3QgTiBjb250aWd1b3Vz DQoNCiAgICAgICAgICBwYWNrZXRzIGFuZCB0aGUgc2Vjb25kIGJvdHRsZW5lY2sgaGFzIHRvIGlu amVjdCBhbg0KDQogICAgICAgICAgdW5pbnRlcnJ1cHRlZCBzZXF1ZW5jZSBvZiBhdCBsZWFzdCBO IG9mIHRoZXNlIHBhY2tldHMgYmV0d2Vlbg0KDQogICAgICAgICAgdHdvIHBhY2tldHMgZWFybGll ciBpbiB0aGUgc3RyZWFtICh3aGVyZSBOIGlzIHRoZSByZW9yZGVyaW5nDQoNCiAgICAgICAgICB3 aW5kb3cgdGhhdCB0aGUgdHJhbnNwb3J0IHByb3RvY29sIGFsbG93cyBiZWZvcmUgaXQgY29uc2lk ZXJzDQoNCiAgICAgICAgICBhIHBhY2tldCBpcyBsb3N0KS4NCg0KDQoNCiAgICAgICAgICAgICBG b3IgZXhhbXBsZSBjb25zaWRlciBOPTMsIGFuZCBjb25zaWRlciB0aGUgc2VxdWVuY2Ugb2YNCg0K ICAgICAgICAgICAgIHBhY2tldHMgMTAwLCAxMDEsIDEwMiwgMTAzLC4uLiBhbmQgaW1hZ2luZSB0 aGF0IHBhY2tldHMNCg0KICAgICAgICAgICAgIDE1MCwxNTEsMTUyIGZyb20gbGF0ZXIgaW4gdGhl IGZsb3cgYXJlIGluamVjdGVkIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgICAgICAxMDAsIDE1MCwg MTUxLCAxMDEsIDE1MiwgMTAyLCAxMDMuLi4gIElmIHRoaXMgd2VyZSBsYXRlDQoNCiAgICAgICAg ICAgICByZW9yZGVyaW5nLCBldmVuIG9uZSBwYWNrZXQgYXJyaXZpbmcgNTAgb3V0IG9mIHNlcXVl bmNlDQoNCiAgICAgICAgICAgICB3b3VsZCB0cmlnZ2VyIGEgc3B1cmlvdXMgcmV0cmFuc21pc3Np b24sIGJ1dCB0aGVyZSBpcyBubw0KDQogICAgICAgICAgICAgc3B1cmlvdXMgcmV0cmFuc21pc3Np b24gaGVyZSwgYmVjYXVzZSBwYWNrZXQgMTAxIG1vdmVzIHRoZQ0KDQogICAgICAgICAgICAgY3Vt dWxhdGl2ZSBBQ0sgY291bnRlciBmb3J3YXJkIGJlZm9yZSAzIHBhY2tldHMgaGF2ZQ0KDQogICAg ICAgICAgICAgYXJyaXZlZCBvdXQgb2Ygb3JkZXIuICBMYXRlciwgd2hlbiBwYWNrZXRzIDE0OCwg MTQ5LCAxNTMuLi4NCg0KICAgICAgICAgICAgIGFycml2ZSwgZXZlbiB0aG91Z2ggdGhlcmUgaXMg YSAzLXBhY2tldCBob2xlLCB0aGVyZSB3aWxsIGJlDQoNCiAgICAgICAgICAgICBubyBwcm9ibGVt LCBiZWNhdXNlIHRoZSBwYWNrZXRzIHRvIGZpbGwgdGhlIGhvbGUgYXJlDQoNCiAgICAgICAgICAg ICBhbHJlYWR5IGluIHRoZSByZWNlaXZlIGJ1ZmZlci4NCg0KDQoNCiAgICAgIDQuICBFdmVuIHdp dGggdGhlIGN1cnJlbnQgcmVjb21tZW5kZWQgVENQIChOPTMpIHNwdXJpb3VzDQoNCiAgICAgICAg ICByZXRyYW5zbWlzc2lvbnMgd2lsbCBiZSB1bmxpa2VseSBmb3IgYWxsIHRoZSBhYm92ZSByZWFz b25zLg0KDQogICAgICAgICAgQXMgUkFDSyBbSS1ELmlldGYtdGNwbS1yYWNrXSBpcyBiZWNvbWlu ZyB3aWRlbHkgZGVwbG95ZWQsIGl0DQoNCiAgICAgICAgICB0ZW5kcyB0byBhZGFwdCBpdHMgcmVv cmRlcmluZyB3aW5kb3cgdG8gYSBsYXJnZXIgdmFsdWUgb2YgTiwNCg0KICAgICAgICAgIHdoaWNo IHdpbGwgbWFrZSB0aGUgY2hhbmNlIG9mIGEgY29udGlndW91cyBzZXF1ZW5jZSBvZiBOIGVhcmx5 DQoNCiAgICAgICAgICBhcnJpdmFscyB2YW5pc2hpbmdseSBzbWFsbC4NCg0KDQoNCiAgICAgIDUu ICBFdmVuIGEgcnVuIG9mIDIgQ0UgbWFya3Mgd2l0aGluIGEgY2xhc3NpYyBFQ04gZmxvdyBpcw0K DQogICAgICAgICAgdW5saWtlbHksIGdpdmVuIEZRLUNvRGVsIGlzIHRoZSBvbmx5IGtub3duIHdp ZGVseSBkZXBsb3llZCBBUU0NCg0KICAgICAgICAgIHRoYXQgc3VwcG9ydHMgY2xhc3NpYyBFQ04g bWFya2luZyBhbmQgaXQgdGFrZXMgZ3JlYXQgY2FyZSB0bw0KDQogICAgICAgICAgc2VwYXJhdGUg b3V0IGZsb3dzIGFuZCB0byBzcGFjZSBhbnkgbWFya2luZ3MgZXZlbmx5IGFsb25nIGVhY2gNCg0K ICAgICAgICAgIGZsb3cuDQoNCg0KDQogICAgICBJdCBpcyBleHRyZW1lbHkgdW5saWtlbHkgdGhh dCB0aGUgYWJvdmUgc2V0IG9mIDUgZXZlbnR1YWxpdGllcw0KDQogICAgICB0aGF0IGFyZSBlYWNo IHVudXN1YWwgaW4gdGhlbXNlbHZlcyB3b3VsZCBhbGwgaGFwcGVuDQoNCiAgICAgIHNpbXVsdGFu ZW91c2x5LiAgQnV0LCBldmVuIGlmIHRoZXkgZGlkLCB0aGUgY29uc2VxdWVuY2VzIHdvdWxkDQoN CiAgICAgIGhhcmRseSBiZSBkaXJlOiB0aGUgb2RkIHNwdXJpb3VzIGZhc3QgcmV0cmFuc21pc3Np b24uICBBZG1pdHRlZGx5DQoNCiAgICAgIFRDUCByZWR1Y2VzIGl0cyBjb25nZXN0aW9uIHdpbmRv dyB3aGVuIGl0IGRlZW1zIHRoZXJlIGhhcyBiZWVuIGENCg0KICAgICAgbG9zcywgYnV0IGV2ZW4g dGhpcyBjYW4gYmUgcmVjb3ZlcmVkIG9uY2UgdGhlIHNlbmRlciBkZXRlY3RzIHRoYXQNCg0KICAg ICAgdGhlIHJldHJhbnNtaXNzaW9uIHdhcyBzcHVyaW91cy4NCg0KDQoNCg0KDQotLQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9i b2JicmlzY29lLm5ldC8NCg== --_000_CE03DB3D7B45C245BCA0D243277949363060CC9CMX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6Izk5MzM2NjsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij5Cb2IsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij5Db21tZW50aW5nIGFzIGFuIGluZGl2aWR1YWws IG5vdCBhIFdHIGNoYWlyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4mZ3Q7IFEjMTo8L2I+IElmIHRoaXMgZ2xvc3Nl cyBvdmVyIGFueSBjb25jZXJucyB5b3UgaGF2ZSwgcGxlYXNlIGV4cGxhaW4uPHNwYW4gc3R5bGU9 ImNvbG9yOiM5OTMzNjYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+SXQg ZG9lcyBnbG9zcyBvdmVyLCBhdCBsZWFzdCBmb3IgbWUuJm5ic3A7IFRoZSBUTDtEUiBzdW1tYXJ5 IGlzIHRoYXQgaXRlbXMgMS0zIGFyZW7igJl0IHJlbGV2YW50IG9yIGhlbHBmdWwsIElNSE8sIGxl YXZpbmcgaXRlbXMgNCBhbmQgNSwgd2hvc2UgZWZmZWN0aXZlbmVzcyBkZXBlbmRzIG9uIHdpZGVz cHJlYWQgZGVwbG95bWVudCBvZiBSQUNLIGFuZCBGUSBBUU1zIChlLmcuLA0KIEZRLUNvRGVsKSBy ZXNwZWN0aXZlbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij5JdGVtcyAx ICZhbXA7IDI6IFRoZSBnZW5lcmFsIGV4cGVjdGF0aW9uIGZvciBJbnRlcm5ldCB0cmFuc3BvcnQg cHJvdG9jb2xzIGlzIHRoYXQgdGhleeKAmXJlIHJvYnVzdCBhZ2FpbnN0IOKAnHN0dXBpZCBuZXR3 b3JrIHRyaWNrc+KAnSBsaWtlIHJlb3JkZXJpbmcsIGJ1dCBleGlzdGluZyBwcm90b2NvbHMgdHJh bnNwb3J0IHdpbmQgdXAgYmVpbmcgZGVzaWduZWQvaW1wbGVtZW50ZWQNCiBmb3IgdGhlIG5ldHdv cmsgd2UgaGF2ZSwgbm90IHRoZSBvbmUgd2Ugd2lzaCB3ZSBoYWQuJm5ic3A7IEnigJltIGdlbmVy YWxseSBza2VwdGljYWwgb2Yg4oCcaGlnaGx5IHVubGlrZWx54oCdIGFyZ3VtZW50cywgYXMgaG9y cmVuZG91cyByZXN1bHRzIGluIGEgaGlnaGx5IHVubGlrZWx5IHNjZW5hcmlvIGFyZSBub3QgYWNj ZXB0YWJsZSBpZiB0aGF0IHNjZW5hcmlvIG9jY3VycyByZXBlYXRlZGx5LCBldmVuIHdpdGggbG9u ZyBpbnRlcnZhbHMgaW4gYmV0d2VlbiBvY2N1cnJlbmNlcy4NCiAmbmJzcDtJbiBsaWdodCBvZiB0 aGF0LCBJIHZpZXcgaXRlbXMgMSBhbmQgMiBhcyBkZWZpbmluZyB0aGUgcHJvYmxlbSBzY2VuYXJp byB0aGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCwgcGFydGljdWxhcmx5IGlmIEw0UyBpcyB0byBi ZSB3aWRlbHkgZGVwbG95ZWQsIGFuZCBwcmVmZXIgdG8gZm9jdXMgb24gaXRlbXMgMy01IGFib3V0 IGhvdyB0aGUgcHJvYmxlbSBpcyBkZWFsdCB3aXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6Izk5MzM2NiI+SXRlbSAzOiBUaGlzIGJlZ2lucyBieSBjb3JyZWN0bHkgcG9pbnRzIG91dCB0 aGF0IDNEdXBBQ0sgaXMgdGhlIGNyaXRlcmlhIGZvciB0cmlnZ2VyaW5nIGNvbnZlbnRpb25hbCBU Q1AgcmV0cmFuc21pc3Npb24sIGUuZy4sIDJEdXBBQ0sgZG9lc27igJl0LiZuYnNwOyBBbiBhc3Bl Y3QgdGhhdCBpc27igJl0IG1lbnRpb25lZCBpcyB0aGF0IEFRTXMgZm9yIGNsYXNzaWMgKG5vbi1M NFMpDQogdHJhZmZpYyBzaG91bGQgYmUgcmFuZG9tbHkgbWFya2luZyAoYWJvdmUgYSBxdWV1ZSB0 aHJlc2hvbGQsIENFIG1hcmtpbmcgcHJvYmFiaWxpdHkgZGVwZW5kcyBvbiBxdWV1ZSBvY2N1cGFu Y3kpLCBub3QgdGhyZXNob2xkIG1hcmtpbmcgKGFib3ZlIGEgcXVldWUgdGhyZXNob2xkLCBtYXJr IGFsbCBwYWNrZXRzIHdpdGggQ0UpLiZuYnNwOyBJZiB0aHJlc2hvbGQgbWFya2luZyBpcyB1c2Vk LCAzIENFIG1hcmtzIGluIGEgcm93IGlzIGEgbmVhciBjZXJ0YWludHksDQogYXMgZm9yIG5vbi1t aWNlIGZsb3dzLCBvbmUgY2FuIGV4cGVjdCB0byBoYXZlIGF0IGxlYXN0IHRoYXQgbWFueSBwYWNr ZXRzIGluIGFuIFJUVCB3aW5kb3c7IHRoaXMgaXMgYSDigJxEb2N0b3IgaXQgaHVydHMgd2hlbiBJ IGRvICZsdDt0aGlzJmd0Oy7igJ0v4oCdRG9u4oCZdCBkbyB0aGF0IeKAnSBzY2VuYXJpbyB3aGVy ZSB0aGUgcmlnaHQgYW5zd2VyIGlzIHRvIGZpeCB0aGUgYnJva2VuIHRocmVzaG9sZCBtYXJraW5n IGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+QXNz dW1pbmcgcHJvYmFiaWxpc3RpYyBtYXJraW5nLCBvbmUgdGhlbiBuZWVkcyB0byBsb29rIGF0IDMt aW4tYS1yb3cgQ0UgbWFya2luZyBwcm9iYWJpbGl0aWVzIGJhc2VkIG9uIHRoZSBtYXJraW5nIHJh dGUuJm5ic3A7IFRoZXNlIGFyZSBub3Qgc21hbGwgLSBmb3IgZXhhbXBsZSwgYXQgYSAxMCUgbWFy a2luZyBwcm9iYWJpbGl0eSwgdGhlIGxpa2VsaWhvb2Qgb2YgQ0UtbWFya2luZw0KIDMgcGFja2V0 cyBpbiBhIHJvdyBzdGFydGluZyBmcm9tIGEgc3BlY2lmaWMgcGFja2V0IGlzIDEgaW4gMSwwMDAg KDEvMTA8c3VwPnRoPC9zdXA+IG9mIDElKSwgYnV0IGFjcm9zcyA1MDAgcGFja2V0cyBpbiBhIGZs b3csIHRoYXQgcHJvYmFiaWxpdHkgaXMgYWJvdXQgNTAlLiAmbmJzcDsmbmJzcDtNeSBpbml0aWFs IHRha2UtYXdheSBmcm9tIHRoaXMgaXMgdGhhdCBpZiB0aGUgdHdvIGJvdHRsZW5lY2tzIChjb252 ZW50aW9uYWwgZm9sbG93ZWQgYnkgTDRTKSBwZXJzaXN0LA0KIHRoZW4gdGhlIOKAnHVudXN1YWwg c2NlbmFyaW/igJ0gb2YgMyBDRS1tYXJrZWQgcGFja2V0cyBpbiBhIHJvdyBpcyBuZWFybHkgY2Vy dGFpbiB0byBoYXBwZW4sIHdoaWNoIHN1Z2dlc3RzIHRoYXQgaXRlbSAzIGlzIG5vdCBwYXJ0aWN1 bGFybHkgaGVscGZ1bCwgbGVhdmluZyBpdGVtcyA0IChSQUNLKSBhbmQgNSAoRlEtQ29EZWwpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+U28sIHdoaWxlIEkgZG9u4oCZdCBo YXZlIGEgY29uY2x1c2lvbiB0byBkcmF3LCBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhlIGNvdW50 ZXJtZWFzdXJlcyB0byB0aGlzIGNvbnZlbnRpb25hbCBUQ1AgZmxvdyBtaXNiZWhhdmlvciB3aXRo IEw0UyBhcmUgZGVwbG95bWVudCBvZiBSQUNLIGF0IGVuZHBvaW50cyBhbmQgZGVwbG95bWVudCBv ZiBGUSBBUU1zIHN1Y2ggYXMNCiBGUS1Db0RlbCBhdCBub24tTDRTIHBvdGVudGlhbCBib3R0bGVu ZWNrIG5vZGVzLiZuYnNwOyBJdGVtcyA0IGFuZCA1IGJlbG93IGVmZmVjdGl2ZWx5IGFzc2VydCB3 aWRlIGRlcGxveW1lbnQgb2YgdGhvc2UgYWxnb3JpdGhtcyDigJMgYWRkaXRpb25hbCBpbmZvcm1h dGlvbiBhbmQgZGF0YSBvbiB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IHRzdndnICZsdDt0c3Z3Zy1ib3VuY2Vz QGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Cb2IgQnJpc2NvZTxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAxMywgMjAxOSAxMjo0OCBQTTxicj4NCjxiPlRvOjwvYj4g ZWNuLXNhbmVAbGlzdHMuYnVmZmVyYmxvYXQubmV0OyB0Y3BtIElFVEYgbGlzdDxicj4NCjxiPkNj OjwvYj4gdHN2d2cgSUVURiBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0c3Z3Z10gRUNOIENF IHRoYXQgd2FzIEVDVCgwKSBpbmNvcnJlY3RseSBjbGFzc2lmaWVkIGFzIEw0UzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6I0NFMTEyNiI+W0VY VEVSTkFMIEVNQUlMXSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KW0knbSBzZW5kaW5n IHRoaXMgdG8gZWNuLXNhbmUgJ2NvcyB0aGF0J3Mgd2hlcmUgSSBkZXRlY3QgdGhhdCB0aGlzIGNv bmNlcm4gaXMgc3RpbGwgcnVtYmxpbmcuPGJyPg0KSSdtIGFsc28gc2VuZGluZyB0byB0Y3BtQGll dGYgJ2NvcyB0aGVyZSdzIGEgcXVlc3Rpb24gZm9yIFRDUCBleHBlcnRzIGp1c3QgYmVmb3JlIHRo ZSBxdW90ZWQgdGV4dCBiZWxvdy48YnI+DQpBbmQgdHN2d2dAaWV0ZiBpcyB3aGVyZSBpdCBvdWdo dCB0byBiZSBkaXNjdXNzZWQuXTxicj4NCjxicj4NCk5vdyB0aGF0IHRoZSBJUFIgaXNzdWUgd2l0 aCBMNFMgaGFzIGJlZW4gcHV0IHRvIGJlZCwgb25lIGJ5IG9uZSBJIGFtIGdvaW5nIHRocm91Z2gg dGhlIG90aGVyIGNvbmNlcm5zIHRoYXQgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCBMNFMuPGJyPg0K PGJyPg0KSW4gdGhlIElFVEYgZHJhZnQgdGhhdCByZWNvcmRzIGFsbCB0aGUgcHJvcyBhbmQgY29u cyBvZiBkaWZmZXJlbnQgaWRlbnRpZmllcnMgdG8gdXNlIGZvciBMNFMsIHVuZGVyIHRoZSAmcXVv dDtFQ1QoMSkgYW5kIENFJnF1b3Q7IGNob2ljZSAod2hpY2ggaXMgY3VycmVudGx5IHRoZSBvbmUg YWRvcHRlZCBhdCB0aGUgSUVURikgdGhlcmUgd2FzIGFscmVhZHkgYW4gZXhwbGFuYXRpb24gb2Yg d2h5IHRoZXJlIHdvdWxkIGJlIHZhbmlzaGluZ2x5IGxvdyByaXNrIG9mIGFueQ0KIGhhcm1mdWwg Y29uc2VxdWVuY2VzIGZyb20gQ0UgdGhhdCB3YXMgb3JpZ2luYWxseSBFQ1QoMCkgYmVpbmcgY2xh c3NpZmllZCBpbnRvIHRoZSBMNFMgcXVldWU6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNiNwYWdlLTMyIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA2I3Bh Z2UtMzI8L2E+PGJyPg0KPGJyPg0KUmUtcmVhZGluZyB0aGF0LCBJIGhhdmUgZm91bmQgc29tZSB0 aGluZ3MgdW5zdGF0ZWQgdGhhdCBJIGhhZCB0aG91Z2h0IHdlcmUgb2J2aW91cy4gU28gSSd2ZSBz cGVsbGVkIGl0IGFsbCBvdXQgbG9uZy1oYW5kIGluIHRoZSB0ZXh0IGJlbG93LCB3aGljaCBpcyBu b3cgaW4gbXkgbG9jYWwgY29weSBvZiB0aGUgZHJhZnQgYW5kIHdpbGwgYmUgaW4gdGhlIG5leHQg cmV2aXNpb24gdW5sZXNzIHBlb3BsZSBzdWdnZXN0IGltcHJvdmVtZW50cy9jb3JyZWN0aW9ucw0K IGhlcmUuPGJyPg0KPGJyPg0KPGI+USMxOjwvYj4gSWYgdGhpcyBnbG9zc2VzIG92ZXIgYW55IGNv bmNlcm5zIHlvdSBoYXZlLCBwbGVhc2UgZXhwbGFpbi4gPGJyPg0KT3RoZXJ3aXNlIEkgd2lsbCBj b250aW51ZSB0byBjb25zaWRlciB0aGF0IHRoaXMgaXMgZWZmZWN0aXZlbHkgYSBub24taXNzdWUs IHdoaWNoIGlzIHRoZSBjb25jbHVzaW9uIGV2ZXJ5b25lIGluIHRoZSBUQ1AgY29tbXVuaXR5IGNh bWUgdG8gYXQgdGhlIHRpbWUgdGhlIEw0UyBpZGVudGlmaWVyIHdhcyBjaG9zZW4gYmFjayBpbiAy MDE1Ljxicj4NCjxicj4NCjxiPlEjMjogPC9iPlRoZSBsYXN0IGNvdXBsZSBvZiBsaW5lcyBhcmUg dGhlIG9ubHkgcGFydCBJIGFtIG5vdCBzdXJlIG9mLiBEbyBtb3N0IG9mIHRvZGF5J3MgVENQIGlt cGxlbWVudGF0aW9ucyByZWNvdmVyIHRoZSByZWR1Y3Rpb24gaW4gY29uZ2VzdGlvbiB3aW5kb3cg d2hlbiB0aGV5IGRpc2NvdmVyIGxhdGVyIHRoYXQgYSBmYXN0IHJldHJhbnNtaXQgd2FzIHNwdXJp b3VzPyBUaGVyZSdzIGEgbm90ZSBhdCB0aGUgZW5kIG9mIHRoZSBpbnRybyB0bw0KIHJmYzQwMTUg c2F5aW5nIHRoZXJlIHdhcyBpbnN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvIHN0YW5kYXJkaXplIHRo aXMgYmVoYXZpb3VyLCBidXQgdGhhdCBtb3N0IGxpa2VseSBtZWFucyBpdCdzIGRvbmUgaW4gZGlm ZmVyZW50IHdheXMsIHJhdGhlciB0aGFuIGl0IGlzbid0IGRvbmUgYXQgYWxsLjxicj4NCjxicj4N Cjxicj4NCkJvYjxicj4NCjxicj4NCjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBSaXNrIG9mIHJlb3Jk ZXJpbmcgY2xhc3NpYyBDRSBwYWNrZXRzOiZuYnNwOyBDbGFzc2lmeWluZyBhbGwgQ0UgcGFja2V0 czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp bnRvIHRoZSBMNFMgcXVldWUgcmlza3MgYW55IENFIHBhY2tldHMgdGhhdCB3ZXJlIG9yaWdpbmFs bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RUNUKDApIGJlaW5nIGluY29ycmVjdGx5IGNsYXNzaWZpZWQgYXMgTDRTLiZuYnNwOyBJZiB0aGVy ZSB3ZXJlIGRlbGF5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluIHRoZSBDbGFzc2ljIHF1ZXVlLCB0aGVzZSBpbmNvcnJlY3RseSBjbGFzc2lm aWVkIENFIHBhY2tldHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgd291bGQgYXJyaXZlIGVhcmx5LCB3aGljaCBpcyBhIGZvcm0gb2YgcmVvcmRl cmluZy4mbmJzcDsgUmVvcmRlcmluZyBjYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2F1c2UgVENQIHNlbmRlcnMgKGFuZCBzZW5kZXJzIG9m IHNpbWlsYXIgdHJhbnNwb3J0cykgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV0cmFuc21pdCBzcHVyaW91c2x5LiZuYnNwOyBIb3dldmVy LCB0aGUgcmlzayBvZiBzcHVyaW91czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyByZXRyYW5zbWlzc2lvbnMgd291bGQgYmUgZXh0cmVtZWx5IGxv dyBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAx LiZuYnNwOyBJdCBpcyBxdWl0ZSB1bnVzdWFsIHRvIGV4cGVyaWVuY2UgcXVldWluZyBhdCBtb3Jl IHRoYW4gb25lPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvdHRsZW5lY2sgb24gdGhlIHNhbWUgcGF0 aCAodGhlIGF2YWlsYWJsZSBjYXBhY2l0aWVzIGhhdmUgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YmUgaWRlbnRpY2FsKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4mbmJzcDsgSW4gb25s eSBhIHN1YnNldCBvZiB0aGVzZSB1bnVzdWFsIGNhc2VzIHdvdWxkIHRoZSBmaXJzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBib3R0bGVuZWNrIHN1cHBvcnQgY2xhc3NpYyBFQ04gbWFya2luZyB3aGls ZSB0aGUgc2Vjb25kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZCBMNFMgRUNOIG1hcmtp bmcsIHdoaWNoIHdvdWxkIGJlIHRoZSBvbmx5IHNjZW5hcmlvPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHdoZXJlIHNvbWUgRUNUKDApIHBhY2tldHMgY291bGQgYmUgQ0UgbWFya2VkIGJ5IGEgbm9uLUw0 UyBBUU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiB0aGUgcmVtYWluZGVyIGV4cGVyaWVuY2Vk IGZ1cnRoZXIgZGVsYXkgdGhyb3VnaCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xhc3NpYyBz aWRlIG9mIGEgc3Vic2VxdWVudCBMNFMgRHVhbFEgQVFNLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAzLiZuYnNwOyBFdmVuIHRoZW4sIHdoZW4gYSBmZXcgcGFja2V0cyBhcmUgZGVsaXZlcmVk IGVhcmx5LCBpdCB0YWtlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2ZXJ5IHVudXN1YWwgY29uZGl0 aW9ucyB0byBjYXVzZSBhIHNwdXJpb3VzIHJldHJhbnNtaXNzaW9uLCBpbjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBjb250cmFzdCB0byB3aGVuIHNvbWUgcGFja2V0cyBhcmUgZGVsaXZlcmVkIGxhdGUu Jm5ic3A7IFRoZSBmaXJzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib3R0bGVuZWNrIGhhcyB0byBh cHBseSBDRS1tYXJrcyB0byBhdCBsZWFzdCBOIGNvbnRpZ3VvdXM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcGFja2V0cyBhbmQgdGhlIHNlY29uZCBib3R0bGVuZWNrIGhhcyB0byBpbmplY3QgYW48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdW5pbnRlcnJ1cHRlZCBzZXF1ZW5jZSBvZiBhdCBsZWFzdCBOIG9m IHRoZXNlIHBhY2tldHMgYmV0d2VlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0d28gcGFja2V0cyBl YXJsaWVyIGluIHRoZSBzdHJlYW0gKHdoZXJlIE4gaXMgdGhlIHJlb3JkZXJpbmc8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgd2luZG93IHRoYXQgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBhbGxvd3MgYmVm b3JlIGl0IGNvbnNpZGVyczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIHBhY2tldCBpcyBsb3N0KS48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRm9yIGV4YW1wbGUgY29uc2lkZXIgTj0zLCBhbmQgY29uc2lkZXIgdGhlIHNl cXVlbmNlIG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhY2tldHMg MTAwLCAxMDEsIDEwMiwgMTAzLC4uLiBhbmQgaW1hZ2luZSB0aGF0IHBhY2tldHM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTUwLDE1MSwxNTIgZnJvbSBsYXRlciBpbiB0 aGUgZmxvdyBhcmUgaW5qZWN0ZWQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMTAwLCAxNTAsIDE1MSwgMTAxLCAxNTIsIDEwMiwgMTAzLi4uJm5ic3A7 IElmIHRoaXMgd2VyZSBsYXRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlb3JkZXJpbmcsIGV2ZW4gb25lIHBhY2tldCBhcnJpdmluZyA1MCBvdXQgb2Ygc2VxdWVuY2U8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd291bGQgdHJpZ2dlciBhIHNw dXJpb3VzIHJldHJhbnNtaXNzaW9uLCBidXQgdGhlcmUgaXMgbm88bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3B1cmlvdXMgcmV0cmFuc21pc3Npb24gaGVyZSwgYmVjYXVz ZSBwYWNrZXQgMTAxIG1vdmVzIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBjdW11bGF0aXZlIEFDSyBjb3VudGVyIGZvcndhcmQgYmVmb3JlIDMgcGFja2V0cyBoYXZl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFycml2ZWQgb3V0IG9mIG9y ZGVyLiZuYnNwOyBMYXRlciwgd2hlbiBwYWNrZXRzIDE0OCwgMTQ5LCAxNTMuLi48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJyaXZlLCBldmVuIHRob3VnaCB0aGVyZSBp cyBhIDMtcGFja2V0IGhvbGUsIHRoZXJlIHdpbGwgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbm8gcHJvYmxlbSwgYmVjYXVzZSB0aGUgcGFja2V0cyB0byBmaWxsIHRo ZSBob2xlIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbHJlYWR5 IGluIHRoZSByZWNlaXZlIGJ1ZmZlci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4mbmJz cDsgRXZlbiB3aXRoIHRoZSBjdXJyZW50IHJlY29tbWVuZGVkIFRDUCAoTj0zKSBzcHVyaW91czxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyByZXRyYW5zbWlzc2lvbnMgd2lsbCBiZSB1bmxpa2VseSBmb3Ig YWxsIHRoZSBhYm92ZSByZWFzb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcyBSQUNLIFtJLUQu aWV0Zi10Y3BtLXJhY2tdIGlzIGJlY29taW5nIHdpZGVseSBkZXBsb3llZCwgaXQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGVuZHMgdG8gYWRhcHQgaXRzIHJlb3JkZXJpbmcgd2luZG93IHRvIGEgbGFy Z2VyIHZhbHVlIG9mIE4sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIHdpbGwgbWFrZSB0aGUg Y2hhbmNlIG9mIGEgY29udGlndW91cyBzZXF1ZW5jZSBvZiBOIGVhcmx5PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGFycml2YWxzIHZhbmlzaGluZ2x5IHNtYWxsLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA1LiZuYnNwOyBFdmVuIGEgcnVuIG9mIDIgQ0UgbWFya3Mgd2l0aGluIGEgY2xhc3NpYyBF Q04gZmxvdyBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1bmxpa2VseSwgZ2l2ZW4gRlEtQ29EZWwg aXMgdGhlIG9ubHkga25vd24gd2lkZWx5IGRlcGxveWVkIEFRTTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGF0IHN1cHBvcnRzIGNsYXNzaWMgRUNOIG1hcmtpbmcgYW5kIGl0IHRha2VzIGdyZWF0IGNh cmUgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VwYXJhdGUgb3V0IGZsb3dzIGFuZCB0byBzcGFj ZSBhbnkgbWFya2luZ3MgZXZlbmx5IGFsb25nIGVhY2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmxv dy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgZXh0cmVtZWx5IHVubGlrZWx5IHRo YXQgdGhlIGFib3ZlIHNldCBvZiA1IGV2ZW50dWFsaXRpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBhcmUgZWFjaCB1bnVzdWFsIGlu IHRoZW1zZWx2ZXMgd291bGQgYWxsIGhhcHBlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaW11bHRhbmVvdXNseS4mbmJzcDsgQnV0LCBldmVu IGlmIHRoZXkgZGlkLCB0aGUgY29uc2VxdWVuY2VzIHdvdWxkPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2hhcmRseSBiZSBkaXJlOiB0aGUgb2Rk IHNwdXJpb3VzIGZhc3QgcmV0cmFuc21pc3Npb24uJm5ic3A7IEFkbWl0dGVkbHk8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVENQIHJlZHVjZXMg aXRzIGNvbmdlc3Rpb24gd2luZG93IHdoZW4gaXQgZGVlbXMgdGhlcmUgaGFzIGJlZW4gYTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb3NzLCBi dXQgZXZlbiB0aGlzIGNhbiBiZSByZWNvdmVyZWQgb25jZSB0aGUgc2VuZGVyIGRldGVjdHMgdGhh dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGUgcmV0cmFuc21pc3Npb24gd2FzIHNwdXJpb3VzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxw cmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8i Pmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE03DB3D7B45C245BCA0D243277949363060CC9CMX307CL04corpem_-- From freebsd@gndrsh.dnsmgr.net Mon Jul 8 17:07: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 1EB881203B5; Mon, 8 Jul 2019 17:07:24 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwU2GRgEHo48; Mon, 8 Jul 2019 17:07:22 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3448E120390; Mon, 8 Jul 2019 17:07:22 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6907KjA040089; Mon, 8 Jul 2019 17:07:20 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6907J5B040088; Mon, 8 Jul 2019 17:07:19 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201907090007.x6907J5B040088@gndrsh.dnsmgr.net> To: tcpm@ietf.org, tsvwg@ietf.org Date: Mon, 8 Jul 2019 17:07:19 -0700 (PDT) Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Tue, 09 Jul 2019 08:04:29 -0700 Subject: [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 00:09:34 -0000 I have posted a new version with updated proper tcpm working group name of draft-grimes-tcpm-tcpsce-00 (formerly draft-grimes-tcpmwg-tcpsce-00.txt) This is first cut at how SCE works in TCP Cross posting this to both tsvwg and tcpm due to overlap > A new version of I-D, draft-grimes-tcpm-tcpsce-00.txt > has been successfully submitted by Rodney W. Grimes and posted to the > IETF repository. > > Name: draft-grimes-tcpm-tcpsce > Revision: 00 > Title: Some Congestion Experienced in TCP > Document date: 2019-07-08 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce-00.txt > Status: https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/ > Htmlized: https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-grimes-tcpm-tcpsce > > > Abstract: > This memo classifies a TCP code point ESCE ("Echo Some Congestion > Experienced") for use in feedback of IP code point SCE ("Some > Congestion Experienced"). -- Rod Grimes rgrimes@freebsd.org From nobody Tue Jul 9 08:07: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 AD3AF1201DC for ; Tue, 9 Jul 2019 08:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.205 X-Spam-Level: X-Spam-Status: No, score=-16.205 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 yz8MmI7oLEQL for ; Tue, 9 Jul 2019 08:07:26 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21E9120248 for ; Tue, 9 Jul 2019 08:07:18 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id p17so19953858ljg.1 for ; Tue, 09 Jul 2019 08:07:18 -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=ZV+ejO1m3BJmQ2Lynropf5L8pIQT1m1CcMJjfudg9JE=; b=VETvZYj4cqdCGB3LfirAtWJDWU05VKXF+7eN/qx5X/QgA8FpvQbdiB1WSSKHZTKdsX ZihNy1KlcGEBUotyaUQrlbk4lD445jFDV2+mEKe2v4X1gwB147UjCc4iXSUAL78pzByR vBvs9ElXbW51r67eFgoBYLaFU40TKbP/u3HxYbdV9yxS5IFBSzbEjj15gnyRyufVF/bp 6LRUT/Vp2GWITcG7ISgKGfB6ZkmH+XIWjf+NuOGPjEKCIVbJYreBh6l4WgLx9NKI439f xbjQvc7XqVIDWvYUaezSN6iBxuDgjno2/LHWcMr/DOlavBiuqh6+Zqs8UWCvBqDFML2V qA8Q== 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=ZV+ejO1m3BJmQ2Lynropf5L8pIQT1m1CcMJjfudg9JE=; b=s+7VYm48sNf718OTcZUDFZmm6H9r7NZZSbMTI31B5pdpm3RV26a/QEioq5oEECNAPr rfhXWQAADlVmwSndzvepNMfemrIatWXFIg3cHDVoIzA4c1hSUvRAAaEAvbwnEf339gjW mpt1j2DJcQpDJPABh6cwclW84pYvDN+UC1rhTn8Mu+kAQLGen1UCGd8jCso6wzntD6K1 HnfvJsIeJH7HYQTA85TCZdk+VjKaX+QaIG88RWzMJPjKMnRq6w93QxlkgwkM6H4zRIQ6 Y7XH+34nTo9mSxZoeIzlhu8z3/krlzS4y07wkZR+ibA0eWWsFUwFlIC218aWLBiWGGld XOFw== X-Gm-Message-State: APjAAAULOt6+aJ5Uopdx5aVvgnUaY+S21g7QC0SGSaO/nXhqqw7GgsfK pmL18xh5x/5aykwqfak1LbKT7F6nxbOxn2zctPnkTg== X-Google-Smtp-Source: APXvYqz9uGaJZ58LacXj9euxyi6ABW97cJ9qJRPd04c5mDyLI6T7ZAOLRj5FesMopjzJ6GmK99eBUEI7qRUk+amge6Y= X-Received: by 2002:a2e:894a:: with SMTP id b10mr12198979ljk.99.1562684836934; Tue, 09 Jul 2019 08:07:16 -0700 (PDT) MIME-Version: 1.0 References: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> In-Reply-To: From: Neal Cardwell Date: Tue, 9 Jul 2019 11:06:58 -0400 Message-ID: To: Praveen Balasubramanian Cc: "tcpm@ietf.org" , Matt Olson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:07:28 -0000 On Mon, Jul 8, 2019 at 7:11 PM Praveen Balasubramanian wrote: > > We submitted a draft for modified slow start using HyStart and Limited Slow Start. Feedback is welcome. Thanks for posting this draft! ( https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-00 ) This is a very nice, clear document, IMHO. I was curious about a couple of items: (1) In the draft the condition for exiting slow start is: Eta = clamp(MIN_ETA, currentRoundMinRTT / 8, MAX_ETA) if (currentRoundMinRTT >= (lastRoundMinRTT + Eta)) The use of currentRoundMinRTT/8 to compute Eta is counterintuitive to me, and is different from both the Hystart paper and the Linux CUBIC Hystart implementation from the CUBIC authors. The Hystart paper used (modified pseudocode): if (currentRoundMinRTT> lastRoundMinRTT + clamp(lastRoundMinRTT / 16)) The Linux implementation from the Hystart author Sangtae Ha in 2008 used the approach (pseudocode): if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 16)) Eric Dumazet changed the Linux approach in 2014 to use a different constant scaling factor (also pseudocode): if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 8)) I am curious about the rationale for: (a) Using an RTT threshold for exiting slow-start that is based on currentRoundMinRTT/8, rather than being purely a function of the RTT values from previous rounds (as in the Hystart paper) or the lifetime of the connection (as in Linux)? (b) Using a function of lastRoundMinRTT and currentRoundMinRTT for the exit threshold, rather than a function of the min RTT over the lifetime of the connection ("lifetimeMinRTT" in my pseudocode, above)? Is the rationale here partly to deal with fluctuations in RTT due to cellular/wifi/DOCSIS paths with noisy RTTs? Any background on the motivation would be interesting to hear, or perhaps to include in future drafts. (2) The Limited Slow-Start approach described in the draft seems to boil down to increasing cwnd by roughly ssthresh/4 each round trip. It does seem like that would be considerably faster than Reno or CUBIC would normally grow in congestion avoidance, for the first few seconds after exiting slow start. But it does seem to be essentially just a large additive increase. And so it would seem that if CUBIC were instead in its native CUBIC congestion avoidance instead of limited slow-start, then CUBIC would eventually (e.g. after a few seconds) tend to reach the rapid-growth convex portion of the cubic curve, and eventually grow much faster (eventually reaching exponential growth of 1.5x per round trip). I wonder if it would be advantageous for CUBIC connections exiting HyStart++ to use a strategy of growing the cwnd using the maximum of the schedule calculated using limited slow-start and the schedule calculated using the normal CUBIC congestion avoidance logic. That seems like it might have the potential to mitigate performance issues for CUBIC connections that spuriously exit slow-start too soon? best regards, neal From nobody Tue Jul 9 08:32:41 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700541201F8 for ; Tue, 9 Jul 2019 08:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.205 X-Spam-Level: X-Spam-Status: No, score=-16.205 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 VGAxYDWGFJpR for ; Tue, 9 Jul 2019 08:32:36 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C541201E2 for ; Tue, 9 Jul 2019 08:32:36 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id c19so8104290lfm.10 for ; Tue, 09 Jul 2019 08:32:35 -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:content-transfer-encoding; bh=IgapQB5KoXCyiE47XwYOfNz8yDExIed+DMkrfqhZw5w=; b=KQDoPgzmC9Xg6QbWYRTwMGVgauQOl87Zn9lQO0Nf5yi0hMSa07mYB1OzGHXlIRnmJY g82scT9vAS1hid8uXDKa4GmTDTdmSapHM/d1gQUddhmAisEE4zbWlPcEq0xE0ymFN7r7 hUFszxWrNcv4hBxoxMM4jgC9MCPWx/ZFrYNuudyoa7+jKJeQpkPdIxpNtIGm+5en3/Sv n6ozhJ8YpjN/uAgdUSxFulGJkyXR1v6/hv0QHb5dkMd0dqu+PeG2eKPhmqi5FmjNQPDw jl/UsLBWqTrSU/Kf0tT5ABmL5MLHYbYPU6tBbOIsVQvQMc+P2xh0z9xOecT6uzADVwiJ XueQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IgapQB5KoXCyiE47XwYOfNz8yDExIed+DMkrfqhZw5w=; b=ezOveyXV65Yokd9W3bmdRAvDgxEu0wHO0YaCG3YYgPMWVcxuV8c2sHu5enBIc0TPUa TQmT01N/nEsDZsiexL/Be6xjwBK5Ek7pKLBs7WRyjVWSETgFcXi8hqHzc3Jl9PhocQul /dkvfHpuro/Pny5t++41Hqi0PkaPP8YfuQL9neEoWmB2VLKcgGtKQDGvQce2dQwvQt2q m8G1W002BiDd58O7iU54JUh+NWYJN6QpJUdEwPFQxR+wTYSbUAoM1x9x00Hoxougch5k P3XApSEfJS6wNfIeGMNib0IuHd8yNaD/YrGnZdMCUDjLzCw987856pxIoip19VSW+T3Y 0Zjg== X-Gm-Message-State: APjAAAXEK+Q5Pt00VNo/aHI8wviOli60JsUGUEdS6MswminmW9tPSVPm rwy61kwkVgQXqTvYC0MywyN4hKzuYEmxJIntsDjCIFaDiu8VHQ== X-Google-Smtp-Source: APXvYqzfIQH64ELmXBrCYn5aIa0YlRlmKYP6UwhH5DG3hA50V4+Ot2i7a6btcXvLKsq0s4ob8PLOBCRlmaNuUjQkd0w= X-Received: by 2002:a19:8c56:: with SMTP id i22mr12042121lfj.105.1562686353727; Tue, 09 Jul 2019 08:32:33 -0700 (PDT) MIME-Version: 1.0 References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> In-Reply-To: From: Neal Cardwell Date: Tue, 9 Jul 2019 11:32:16 -0400 Message-ID: To: "Black, David" Cc: Bob Briscoe , "ecn-sane@lists.bufferbloat.net" , tcpm IETF list , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:32:40 -0000 On the particular question of Q#2 ("Do most of today's TCP implementations recover the reduction in congestion window when they discover later that a fast retransmit was spurious?"), one relevant data point: Linux TCP should generally be able to revert reductions in cwnd from spurious fast recovery episodes, using either TCP timestamps (along the lines of RFC 4015, starting from at least as far back as 2005 and working well since 7026b912f97d912 in 2013) or DSACKs (functioning well from 5628adf1a0ff3 in late 2011). thanks, neal On Tue, Jul 9, 2019 at 10:44 AM Black, David wrote: > > Bob, > > > > Commenting as an individual, not a WG chair. > > > > > Q#1: If this glosses over any concerns you have, please explain. > > > > It does gloss over, at least for me. The TL;DR summary is that items 1-3= aren=E2=80=99t relevant or helpful, IMHO, leaving items 4 and 5, whose eff= ectiveness depends on widespread deployment of RACK and FQ AQMs (e.g., FQ-C= oDel) respectively. > > > > Items 1 & 2: The general expectation for Internet transport protocols is = that they=E2=80=99re robust against =E2=80=9Cstupid network tricks=E2=80=9D= like reordering, but existing protocols transport wind up being designed/i= mplemented for the network we have, not the one we wish we had. I=E2=80=99= m generally skeptical of =E2=80=9Chighly unlikely=E2=80=9D arguments, as ho= rrendous results in a highly unlikely scenario are not acceptable if that s= cenario occurs repeatedly, even with long intervals in between occurrences.= In light of that, I view items 1 and 2 as defining the problem scenario t= hat needs to be addressed, particularly if L4S is to be widely deployed, an= d prefer to focus on items 3-5 about how the problem is dealt with. > > > > Item 3: This begins by correctly points out that 3DupACK is the criteria = for triggering conventional TCP retransmission, e.g., 2DupACK doesn=E2=80= =99t. An aspect that isn=E2=80=99t mentioned is that AQMs for classic (non= -L4S) traffic should be randomly marking (above a queue threshold, CE marki= ng probability depends on queue occupancy), not threshold marking (above a = queue threshold, mark all packets with CE). If threshold marking is used, = 3 CE marks in a row is a near certainty, as for non-mice flows, one can exp= ect to have at least that many packets in an RTT window; this is a =E2=80= =9CDoctor it hurts when I do .=E2=80=9D/=E2=80=9DDon=E2=80=99t do tha= t!=E2=80=9D scenario where the right answer is to fix the broken threshold = marking implementation. > > > > Assuming probabilistic marking, one then needs to look at 3-in-a-row CE m= arking probabilities based on the marking rate. These are not small - for = example, at a 10% marking probability, the likelihood of CE-marking 3 packe= ts in a row starting from a specific packet is 1 in 1,000 (1/10th of 1%), b= ut across 500 packets in a flow, that probability is about 50%. My initia= l take-away from this is that if the two bottlenecks (conventional followed= by L4S) persist, then the =E2=80=9Cunusual scenario=E2=80=9D of 3 CE-marke= d packets in a row is nearly certain to happen, which suggests that item 3 = is not particularly helpful, leaving items 4 (RACK) and 5 (FQ-CoDel). > > > > So, while I don=E2=80=99t have a conclusion to draw, it appears to me tha= t the countermeasures to this conventional TCP flow misbehavior with L4S ar= e deployment of RACK at endpoints and deployment of FQ AQMs such as FQ-CoDe= l at non-L4S potential bottleneck nodes. Items 4 and 5 below effectively a= ssert wide deployment of those algorithms =E2=80=93 additional information = and data on that would be of interest. > > > > Thanks, --David > > > > From: tsvwg On Behalf Of Bob Briscoe > Sent: Thursday, June 13, 2019 12:48 PM > To: ecn-sane@lists.bufferbloat.net; tcpm IETF list > Cc: tsvwg IETF list > Subject: [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S > > > > [EXTERNAL EMAIL] > > > [I'm sending this to ecn-sane 'cos that's where I detect that this concer= n is still rumbling. > I'm also sending to tcpm@ietf 'cos there's a question for TCP experts jus= t before the quoted text below. > And tsvwg@ietf is where it ought to be discussed.] > > Now that the IPR issue with L4S has been put to bed, one by one I am goin= g through the other concerns that have been raised about L4S. > > In the IETF draft that records all the pros and cons of different identif= iers to use for L4S, under the "ECT(1) and CE" choice (which is currently t= he one adopted at the IETF) there was already an explanation of why there w= ould be vanishingly low risk of any harmful consequences from CE that was o= riginally ECT(0) being classified into the L4S queue: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06#page-32 > > Re-reading that, I have found some things unstated that I had thought wer= e obvious. So I've spelled it all out long-hand in the text below, which is= now in my local copy of the draft and will be in the next revision unless = people suggest improvements/corrections here. > > Q#1: If this glosses over any concerns you have, please explain. > Otherwise I will continue to consider that this is effectively a non-issu= e, which is the conclusion everyone in the TCP community came to at the tim= e the L4S identifier was chosen back in 2015. > > Q#2: The last couple of lines are the only part I am not sure of. Do most= of today's TCP implementations recover the reduction in congestion window = when they discover later that a fast retransmit was spurious? There's a not= e at the end of the intro to rfc4015 saying there was insufficient consensu= s to standardize this behaviour, but that most likely means it's done in di= fferent ways, rather than it isn't done at all. > > > Bob > > > =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 > > Risk of reordering classic CE packets: Classifying all CE packets > > into the L4S queue risks any CE packets that were originally > > ECT(0) being incorrectly classified as L4S. If there were delay > > in the Classic queue, these incorrectly classified CE packets > > would arrive early, which is a form of reordering. Reordering can > > cause TCP senders (and senders of similar transports) to > > retransmit spuriously. However, the risk of spurious > > retransmissions would be extremely low for the following reasons: > > > > 1. It is quite unusual to experience queuing at more than one > > bottleneck on the same path (the available capacities have to > > be identical). > > > > 2. In only a subset of these unusual cases would the first > > bottleneck support classic ECN marking while the second > > supported L4S ECN marking, which would be the only scenario > > where some ECT(0) packets could be CE marked by a non-L4S AQM > > then the remainder experienced further delay through the > > Classic side of a subsequent L4S DualQ AQM. > > > > 3. Even then, when a few packets are delivered early, it takes > > very unusual conditions to cause a spurious retransmission, in > > contrast to when some packets are delivered late. The first > > bottleneck has to apply CE-marks to at least N contiguous > > packets and the second bottleneck has to inject an > > uninterrupted sequence of at least N of these packets between > > two packets earlier in the stream (where N is the reordering > > window that the transport protocol allows before it considers > > a packet is lost). > > > > For example consider N=3D3, and consider the sequence of > > packets 100, 101, 102, 103,... and imagine that packets > > 150,151,152 from later in the flow are injected as follows: > > 100, 150, 151, 101, 152, 102, 103... If this were late > > reordering, even one packet arriving 50 out of sequence > > would trigger a spurious retransmission, but there is no > > spurious retransmission here, because packet 101 moves the > > cumulative ACK counter forward before 3 packets have > > arrived out of order. Later, when packets 148, 149, 153... > > arrive, even though there is a 3-packet hole, there will be > > no problem, because the packets to fill the hole are > > already in the receive buffer. > > > > 4. Even with the current recommended TCP (N=3D3) spurious > > retransmissions will be unlikely for all the above reasons. > > As RACK [I-D.ietf-tcpm-rack] is becoming widely deployed, it > > tends to adapt its reordering window to a larger value of N, > > which will make the chance of a contiguous sequence of N early > > arrivals vanishingly small. > > > > 5. Even a run of 2 CE marks within a classic ECN flow is > > unlikely, given FQ-CoDel is the only known widely deployed AQM > > that supports classic ECN marking and it takes great care to > > separate out flows and to space any markings evenly along each > > flow. > > > > It is extremely unlikely that the above set of 5 eventualities > > that are each unusual in themselves would all happen > > simultaneously. But, even if they did, the consequences would > > hardly be dire: the odd spurious fast retransmission. Admittedly > > TCP reduces its congestion window when it deems there has been a > > loss, but even this can be recovered once the sender detects that > > the retransmission was spurious. > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 9 08:41: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 CF47212070F; Tue, 9 Jul 2019 08:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWI0L1d1V--T; Tue, 9 Jul 2019 08:41:42 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D620C120283; Tue, 9 Jul 2019 08:41:14 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id r9so20027866ljg.5; Tue, 09 Jul 2019 08:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2FjdbXAz/FJzIp0q0XX2KwDHU4oS9dOUuy/3LBUrCRo=; b=DyYRn8TxutrLH04/YPnFe6ap32NlyMLhL/A2TzjAYklvAS7BgjA3ZTxPBwYVqKxtJg wJEssU2uRv3ppnc1JSsgXKxp7C5R3kzmDzIZVPSo9i/C9A8ejagXNFvcBIounDVanGc/ 2d40oq0FGALXFcHXxcVCXtsLP25+gIlbMzdJ5yF7olYo1NNpOktnAZ493DJEcg9EPWmc Z0/h3YZZabqL28ELhMoMiQJaMZH93dHjJALe8n5HiRco7esAGBJPahZIOGUgmiWi1sfx G2RxABvA5C8yUUCLffjg8Tx8rnHgCrmCMUMFJbqbWepEbRCA5xswxWNHR0QFgieR5e+I StBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2FjdbXAz/FJzIp0q0XX2KwDHU4oS9dOUuy/3LBUrCRo=; b=CSRAH1lrKPEupDscda3vEYHStS0m+9SsRavngh3xViwU+qXdN3XpBs5e+8JKZS7iLw LQQ/pTUbpEdC+4qn5nDoheyYqDMCJvbal0EuMMzq7mGM/DgKpmUhf+6wHjcyW6NB/F/6 TEnnuiunFYNcXc0Htdq57ikPeJJopf9rTJxneBu/jUphEfFI0qy1iusKL22gRTLWwRZ8 dE7tei06Nsq8lVcOzim38+nbOfdg2IZggNpJxyyk0Lykl8GvEnv1Lx29GNwhjidgaDUn GQ3v6vF3rO5ApFXTOk2X6QuCZeyz6zpMgcH5KFFunJmMfGbLSYmFk8iERUgKItiz/Zy9 oYYw== X-Gm-Message-State: APjAAAXmQrIXefvvfxgRxP70u4yDmBykauZK/Qb4+msnn6uimSnVlGss qRZi5NGvLRVOL1QEZu/1h5c= X-Google-Smtp-Source: APXvYqw3Bh1wcXv3ifpN6COW8NwV9ITaeKmis5u5jAIaM86zFvnjvfdDJ7Ree+RRxpil2NzkCLadlA== X-Received: by 2002:a2e:8559:: with SMTP id u25mr14094250ljj.224.1562686873072; Tue, 09 Jul 2019 08:41:13 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-234-41-nat-p.elisa-mobile.fi. [83.245.234.41]) by smtp.gmail.com with ESMTPSA id u22sm4901510ljd.18.2019.07.09.08.41.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 08:41:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> Date: Tue, 9 Jul 2019 18:41:10 +0300 Cc: "ecn-sane@lists.bufferbloat.net" , tcpm IETF list , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:41:45 -0000 > On 13 Jun, 2019, at 7:48 pm, Bob Briscoe wrote: >=20 > 1. It is quite unusual to experience queuing at more than one > bottleneck on the same path (the available capacities have = to > be identical). Following up on David Black's comments, I'd just like to note that the = above is not the true criterion for multiple sequential queuing. Many existing TCP senders are unpaced (aside from ack-clocking), = including FreeBSD, resulting in potentially large line-rate bursts at = the origin - especially during slow-start. Even in congestion = avoidance, each ack will trigger a closely spaced packet pair (or = sometimes a triplet). It is then easy to imagine, or to build a testbed = containing, an arbitrarily long sequence of consecutively narrower = links; upon entering each, the burst of packets will briefly collect in = a queue and then be paced out at the new rate. TCP pacing does largely eliminate these bursts when implemented = correctly. However, Linux' pacing and IW is specifically (and = apparently deliberately) set up to issue a 10-packet line-rate burst on = startup. This effect has shown up in SCE tests to the point where we = had to patch this behaviour out of the sending kernel to prevent an = instant exit from slow-start. - Jonathan Morton From nobody Tue Jul 9 15:18:23 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA89D1201CB for ; Tue, 9 Jul 2019 15:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK5OZ_EbRNyR for ; Tue, 9 Jul 2019 15:18:19 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700129.outbound.protection.outlook.com [40.107.70.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBE7120141 for ; Tue, 9 Jul 2019 15:18:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=luzXy4B14cPIfWtZXFEgXyKjmmM0Ypa09nLGBQUvdZpD/9uDyNKm1MeUhA5YMAHYOZJOCz8R+1QoF/kQhGhf8aGF8toWHvSSl3C7GweyeXajTSHM6JN3zWg8sdgIVvmu4Xs0KcYrvnf3t0NYaKU5MDeAL5UHmbsjgnWa/0socqbIoZ5svplDdpmVh94JHxfMoK/x/pyKOo1r8V2VQjFeUTRFKqbWONQPBtLX2Lrt8ZwtHJVN3+o/ZNfbodhaJFF6dy3LdmS6B24OO58W4Y3KPShs7b2S9Fikh//6FRZTGdgGeTuKI3mN0YjsF/MFTqNvfvO3SpMV+U5Cb4NhxX6l1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4+SCzWgZKYxPcJnhiGln9oj9hepywsjQBikBtBwomiw=; b=G+x3+Q58F6GVKBamLelmneBYkI7HD9fhqjBFy6lPfX0eRjJGFQ8SmmI47axswpXNnbYzF4FK6CsHj4hpa3Ih1spjxsib/sfzt6w9m7wj0f/zdDc4+Dc/ZA6P3e2vylRLKzMWsnJYUBm+R/JqytgyUhZ+AL3+y3ykb34bQ8dWgpgckLKF9SLuVZYfl+19S0uFcc16J7KFhZwg/V57nrb6y2144Xg+yxmTf9Y2K+G5aPqk9JJfNWIBKn6u72OCU7UE29lKa5ZTwhE7QES5PfzKFj+K5xrd4MSIpWNoHN5PBuZrif+p/nPfuJfpZZw/D5fFDl0SR077Uog2BWeEv9XDyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4+SCzWgZKYxPcJnhiGln9oj9hepywsjQBikBtBwomiw=; b=fHQ1CGqPH63Q3W+Wap8QrW/Ze+OHfsoRN7mvM0QysPHN1VUecq9saqB9dAldWqjTEOTP4p11jUNofZ6FxF5vABpmMsJ01rdlkSKDhUqyzar8VpBHMwNdPC5tnh+VOqLCLJH9O1SQHYoyxOQ0Hnbh5l86dAergHiyM6l5ddKube4= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1083.namprd21.prod.outlook.com (52.132.149.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.3; Tue, 9 Jul 2019 22:18:16 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab%6]) with mapi id 15.20.2094.001; Tue, 9 Jul 2019 22:18:16 +0000 From: Praveen Balasubramanian To: Neal Cardwell , Praveen Balasubramanian CC: "tcpm@ietf.org" , Matt Olson , Yi Huang Thread-Topic: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt Thread-Index: AQHVNeDXs6wG1Y3E+0uQvV9n53yFv6bBV5MAgAEMkwCAAHXTQA== Date: Tue, 9 Jul 2019 22:18:16 +0000 Message-ID: References: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-09T22:18:15.6453482Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=70acef76-5879-4b0c-80ee-dff544dfae4f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:3:6c7b:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4065dbca-7103-49e4-69b6-08d704bb5781 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1083; x-ms-traffictypediagnostic: MW2PR2101MB1083:|MW2PR2101MB1083: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(189003)(199004)(54094003)(13464003)(81156014)(8676002)(19627235002)(10290500003)(8936002)(256004)(71200400001)(81166006)(4326008)(478600001)(71190400001)(102836004)(76176011)(6116002)(5660300002)(15650500001)(53546011)(14444005)(46003)(66476007)(7696005)(52536014)(2906002)(76116006)(6506007)(7736002)(66556008)(99286004)(966005)(229853002)(66946007)(64756008)(305945005)(68736007)(74316002)(110136005)(66446008)(53936002)(14454004)(6436002)(86362001)(486006)(446003)(6246003)(6306002)(9686003)(55016002)(8990500004)(316002)(107886003)(186003)(25786009)(476003)(22452003)(11346002)(10090500001)(54906003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1083; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xv1d6y8GhSY58zp3PJjxpSdcp723ge7gVcA4YF3Gzjk2KTeCsI5X7GXbJ8jpjiKV2CVteW5l3usgbLomPxB4w3rK9yEy0M3++gju4sLIPduYNnSYJb00TbjlXEiUl/RoEnRHkhv0aR8Ne1caIWqo1t2arvXdtd/g/OSHpK6dxtXaFLMiyRlEvuXJ+ghHgWqdy+MgWWQxM4rXFRtRJd3bySYNolHjqAgGrZBEtin5x20vynD+pE2EIF9TISOJKyJ2JIo6DuAveNqTNGMDA5TJm5gztdtGvkV8OKWscbuXoi3yagfzIw/jbMUsBtMvL27j+6/i9VS4rb1a7Y6NSSFeMl1L1g+ueJrQjCKfpvkR605aELCdguLXvQJcmLvBOaiAt0Siv2fzwY0+iRSkeg/MVwS6rMsCIthgGyE7UQUUwDE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4065dbca-7103-49e4-69b6-08d704bb5781 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 22:18:16.8109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1083 Archived-At: Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 22:18:22 -0000 Re (1). Great catch Neal. That's a bug in the draft and not in our implemen= tation. Eta is computed based on lastRoundMinRTT and not currentRoundMinRTT= . We will fix this in next revision. What was the reason for Linux to switch to lifetimeMinRTT? On Wifi links RT= T does fluctuate a lot. Re (2). I agree that the goal is to find a function that's faster than CA a= nd slower than slow start. LSS works well in practice. For long lived flows= on high BDP links incorporating the CUBIC CA early can help and that's a g= ood idea. But given that this is an informational RFC describing the curren= t implementation, we'd have to experiment and deploy any changes before upd= ating the text. We will look into it. -----Original Message----- From: tcpm On Behalf Of Neal Cardwell Sent: Tuesday, July 9, 2019 8:07 AM To: Praveen Balasubramanian Cc: tcpm@ietf.org; Matt Olson Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-= tcpm-hystartplusplus-00.txt On Mon, Jul 8, 2019 at 7:11 PM Praveen Balasubramanian wrote: > > We submitted a draft for modified slow start using HyStart and Limited Sl= ow Start. Feedback is welcome. Thanks for posting this draft! ( https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-balasubramanian-tcpm-hystartplusplus-00&data=3D0= 2%7C01%7Cpravb%40microsoft.com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988b= f86f141af91ab2d7cd011db47%7C1%7C0%7C636982816578522537&sdata=3DGttDyDYh= w3sG%2BxDGAFSefMYeRyNfjeUih6XVvbJa7MQ%3D&reserved=3D0 ) This is a very nice, clear document, IMHO. I was curious about a couple of items: (1) In the draft the condition for exiting slow start is: Eta =3D clamp(MIN_ETA, currentRoundMinRTT / 8, MAX_ETA) if (currentRoundMinRTT >=3D (lastRoundMinRTT + Eta)) The use of currentRoundMinRTT/8 to compute Eta is counterintuitive to me, a= nd is different from both the Hystart paper and the Linux CUBIC Hystart imp= lementation from the CUBIC authors. The Hystart paper used (modified pseudocode): if (currentRoundMinRTT> lastRoundMinRTT + clamp(lastRoundMinRTT / 16)) The Linux implementation from the Hystart author Sangtae Ha in 2008 used th= e approach (pseudocode): if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 16)) Eric Dumazet changed the Linux approach in 2014 to use a different constant= scaling factor (also pseudocode): if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 8)) I am curious about the rationale for: (a) Using an RTT threshold for exiting slow-start that is based on currentR= oundMinRTT/8, rather than being purely a function of the RTT values from pr= evious rounds (as in the Hystart paper) or the lifetime of the connection (= as in Linux)? (b) Using a function of lastRoundMinRTT and currentRoundMinRTT for the exit= threshold, rather than a function of the min RTT over the lifetime of the = connection ("lifetimeMinRTT" in my pseudocode, above)? Is the rationale here partly to deal with fluctuations in RTT due to cellul= ar/wifi/DOCSIS paths with noisy RTTs? Any background on the motivation would be interesting to hear, or perhaps t= o include in future drafts. (2) The Limited Slow-Start approach described in the draft seems to boil do= wn to increasing cwnd by roughly ssthresh/4 each round trip. It does seem like that would be considerably faster than Reno or CUBIC woul= d normally grow in congestion avoidance, for the first few seconds after ex= iting slow start. But it does seem to be essentially just a large additive = increase. And so it would seem that if CUBIC were instead in its native CUB= IC congestion avoidance instead of limited slow-start, then CUBIC would eve= ntually (e.g. after a few seconds) tend to reach the rapid-growth convex po= rtion of the cubic curve, and eventually grow much faster (eventually reach= ing exponential growth of 1.5x per round trip). I wonder if it would be adv= antageous for CUBIC connections exiting HyStart++ to use a strategy of gro= wing the cwnd using the maximum of the schedule calculated using limited sl= ow-start and the schedule calculated using the normal CUBIC congestion avoi= dance logic. That seems like it might have the potential to mitigate perfor= mance issues for CUBIC connections that spuriously exit slow-start too soon= ? best regards, neal _______________________________________________ tcpm mailing list tcpm@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.co= m%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C636982816578522537&sdata=3D0Sjqt2FWz1rKTqply%2FMJIzGeleyolWWNObL= 58KdCxm4%3D&reserved=3D0 From nobody Tue Jul 9 15:54:33 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA412009C for ; Tue, 9 Jul 2019 15:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.104 X-Spam-Level: X-Spam-Status: No, score=-16.104 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, HTTPS_HTTP_MISMATCH=0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 SdGQUiLHf8YX for ; Tue, 9 Jul 2019 15:54:26 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 9606012006D for ; Tue, 9 Jul 2019 15:54:26 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id q10so167432otk.10 for ; Tue, 09 Jul 2019 15:54:26 -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=A604BZYGFMjZYZZvEOVDC6Wq7Q8OT7l92p67dURBx20=; b=BmnPbMtvYjvSQi9MI3kE3TqzCUu9bQd0zbHj7SgN/x84s1I+26Fqen35pC6+YVGcUg FIoydLgqnoxw/FhCFahE0uQeUX24R2Y6oAEfFLauezs27Gr/fLkCbreX5L6wZtzsaVgP rmlxxRgIgdIIjH1Wjt/e76wVyCsd9U1ZH5/weuvf4Wu88APw/AFOCxciuUFq/QjwPOCv F7z+Ib5IXBSgpaC9hjoL53vzEOI9Oaigadq/ZVSPzS8uobCW7m99Kwp2ReKVDgqcAMQO Wo5TaGREJBY7G4D8zhEuy1qjTpVXuK3EbrksKAKNQ+Sv2mT0df7mZsauiK0vPmjB4ewV o5Cw== 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=A604BZYGFMjZYZZvEOVDC6Wq7Q8OT7l92p67dURBx20=; b=qAEBcG5cCEESR0XHCHEoQ83OSwog+91Ez80WguHYR29bj0vsSrK+Kc4jBVprlzQov5 pHrEe1CgErWGKwocpgVD0TzJlKNF4zlhfYnV1irxgId7mbJKHKchvnQrZoLy87YCczm8 XhKug8lTWkx5VIOmoAMjkZHgp33LYbKVTpoSwHgCM417zBEL97mEIGcqMKVcsSab9Dr7 fo11z267Td16nVsJWhEvQHnMO9LAHfJKjZqqA3tie2AMCgw3KllO14943Ck8OrTtGX48 24/pcVM2+32Z5oAVcx52rkdsKurDNxmiuoUP/jAOOrB9Ic5lXQcIcLMHMsVfrpXe9UWh qrFA== X-Gm-Message-State: APjAAAUmL6KB6QS+qd4hLz3u7b+CDqrCfaVez2cKyeJTHN84NmrNFAMd A4jHuqA+M3oa6RT5tghoy1UuG+hr3Y6+HCts9h/yOA== X-Google-Smtp-Source: APXvYqzGZJeT5/4SRUdA8jjv1+r+YKpEYcjxZZsPXmSs0AvR1xu5f5/cnu09CQtSFYQb5uLYRlsTRS3sV3qfiqgLxEc= X-Received: by 2002:a9d:6742:: with SMTP id w2mr21613123otm.371.1562712865403; Tue, 09 Jul 2019 15:54:25 -0700 (PDT) MIME-Version: 1.0 References: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> In-Reply-To: From: Neal Cardwell Date: Tue, 9 Jul 2019 18:54:07 -0400 Message-ID: To: Praveen Balasubramanian Cc: Praveen Balasubramanian , "tcpm@ietf.org" , Matt Olson , Yi Huang Content-Type: multipart/alternative; boundary="0000000000003ae129058d477107" Archived-At: Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 22:54:30 -0000 --0000000000003ae129058d477107 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2019 at 6:18 PM Praveen Balasubramanian wrote: > Re (1). Great catch Neal. That's a bug in the draft and not in our > implementation. Eta is computed based on lastRoundMinRTT and not > currentRoundMinRTT.. We will fix this in next revision. > Got it. Thanks! > What was the reason for Linux to switch to lifetimeMinRTT? On Wifi links > RTT does fluctuate a lot. > I'm not sure what the motivation was. The "Taming the Elephants" paper and dissertation both use the lastRoundMinRTT, but the code that was submitted to Linux (ae27e98a51526595837 on Oct 29 2008) uses the lifetimeMinRTT, without a comment about the rationale. I can imagine both approaches having pros and cons. > Re (2). I agree that the goal is to find a function that's faster than CA > and slower than slow start. LSS works well in practice. For long lived > flows on high BDP links incorporating the CUBIC CA early can help and > that's a good idea. But given that this is an informational RFC describin= g > the current implementation, we'd have to experiment and deploy any change= s > before updating the text. We will look into it. > Makes sense. thanks, neal -----Original Message----- > From: tcpm On Behalf Of Neal Cardwell > Sent: Tuesday, July 9, 2019 8:07 AM > To: Praveen Balasubramanian > Cc: tcpm@ietf.org; Matt Olson > Subject: Re: [tcpm] FW: New Version Notification for > draft-balasubramanian-tcpm-hystartplusplus-00.txt > > On Mon, Jul 8, 2019 at 7:11 PM Praveen Balasubramanian 40microsoft..com@dmarc.ietf.org> wrote: > > > > We submitted a draft for modified slow start using HyStart and Limited > Slow Start. Feedback is welcome. > > Thanks for posting this draft! ( > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-balasubramanian-tcpm-hystartplusplus-00&data= =3D02%7C01%7Cpravb%40microsoft.com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f= 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636982816578522537&sdata=3DGttD= yDYhw3sG%2BxDGAFSefMYeRyNfjeUih6XVvbJa7MQ%3D&reserved=3D0 > ) > > This is a very nice, clear document, IMHO. > > I was curious about a couple of items: > > (1) In the draft the condition for exiting slow start is: > > Eta =3D clamp(MIN_ETA, currentRoundMinRTT / 8, MAX_ETA) > if (currentRoundMinRTT >=3D (lastRoundMinRTT + Eta)) > > The use of currentRoundMinRTT/8 to compute Eta is counterintuitive to me, > and is different from both the Hystart paper and the Linux CUBIC Hystart > implementation from the CUBIC authors. > > The Hystart paper used (modified pseudocode): > > if (currentRoundMinRTT> lastRoundMinRTT + clamp(lastRoundMinRTT / 16)) > > The Linux implementation from the Hystart author Sangtae Ha in 2008 used > the approach (pseudocode): > > if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 16)) > > Eric Dumazet changed the Linux approach in 2014 to use a different > constant scaling factor (also pseudocode): > > if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 8)) > > I am curious about the rationale for: > > (a) Using an RTT threshold for exiting slow-start that is based on > currentRoundMinRTT/8, rather than being purely a function of the RTT valu= es > from previous rounds (as in the Hystart paper) or the lifetime of the > connection (as in Linux)? > > (b) Using a function of lastRoundMinRTT and currentRoundMinRTT for the > exit threshold, rather than a function of the min RTT over the lifetime o= f > the connection ("lifetimeMinRTT" in my pseudocode, above)? > Is the rationale here partly to deal with fluctuations in RTT due to > cellular/wifi/DOCSIS paths with noisy RTTs? > > Any background on the motivation would be interesting to hear, or perhaps > to include in future drafts. > > (2) The Limited Slow-Start approach described in the draft seems to boil > down to increasing cwnd by roughly ssthresh/4 each round trip. > It does seem like that would be considerably faster than Reno or CUBIC > would normally grow in congestion avoidance, for the first few seconds > after exiting slow start. But it does seem to be essentially just a large > additive increase. And so it would seem that if CUBIC were instead in its > native CUBIC congestion avoidance instead of limited slow-start, then CUB= IC > would eventually (e.g. after a few seconds) tend to reach the rapid-growt= h > convex portion of the cubic curve, and eventually grow much faster > (eventually reaching exponential growth of 1.5x per round trip). I wonder > if it would be advantageous for CUBIC connections exiting HyStart++ to us= e > a strategy of growing the cwnd using the maximum of the schedule > calculated using limited slow-start and the schedule calculated using the > normal CUBIC congestion avoidance logic. That seems like it might have th= e > potential to mitigate performance issues for CUBIC connections that > spuriously exit slow-start too soon? > > best regards, > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.= com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636982816578522537&sdata=3D0Sjqt2FWz1rKTqply%2FMJIzGeleyolWWNO= bL58KdCxm4%3D&reserved=3D0 > --0000000000003ae129058d477107 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 6:18 PM Praveen Ba= lasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
Re (1). Great cat= ch Neal. That's a bug in the draft and not in our implementation. Eta i= s computed based on lastRoundMinRTT and not currentRoundMinRTT.. We will fi= x this in next revision.

Got it. Thanks= !
=C2=A0
What was the reason for Linux to switch to lifetimeMinRTT? On Wifi links RT= T does fluctuate a lot.

I'm not sur= e what the motivation was. The "Taming the Elephants" paper and d= issertation both use the=C2=A0lastRoundMinRTT, but the code that was submit= ted to Linux (ae27e98a51526595837 on Oct 29 2008) uses the=C2=A0=C2=A0lifet= imeMinRTT, without a comment about the rationale. I can imagine both approa= ches having pros and cons.
=C2=A0
Re (2). I agree that the goal is to find a function that's faster than = CA and slower than slow start. LSS works well in practice. For long lived f= lows on high BDP links incorporating the CUBIC CA early can help and that&#= 39;s a good idea. But given that this is an informational RFC describing th= e current implementation, we'd have to experiment and deploy any change= s before updating the text. We will look into it.

=
Makes sense.

thanks,
neal
=C2=A0

-----Original Message-----
From: tcpm <t= cpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Tuesday, July 9, 2019 8:07 AM
To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>
Cc: tcpm@ietf.org; M= att Olson <ma= olson@microsoft.com>
Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-= tcpm-hystartplusplus-00.txt

On Mon, Jul 8, 2019 at 7:11 PM Praveen Balasubramanian <pravb=3D40microsoft..= com@dmarc.ietf.org> wrote:
>
> We submitted a draft for modified slow start using HyStart and Limited= Slow Start. Feedback is welcome.

Thanks for posting this draft! (
https://nam06.safelinks.protect= ion.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-balasubr= amanian-tcpm-hystartplusplus-00&amp;data=3D02%7C01%7Cpravb%40microsoft.= com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636982816578522537&amp;sdata=3DGttDyDYhw3sG%2BxDGAFSefMYeRyNfj= eUih6XVvbJa7MQ%3D&amp;reserved=3D0
)

This is a very nice, clear document, IMHO.

I was curious about a couple of items:

(1) In the draft the condition for exiting slow start is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Eta =3D clamp(MIN_ETA, currentRou= ndMinRTT / 8, MAX_ETA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (currentRoundMinRTT >=3D (l= astRoundMinRTT + Eta))

The use of currentRoundMinRTT/8 to compute Eta is counterintuitive to me, a= nd is different from both the Hystart paper and the Linux CUBIC Hystart imp= lementation from the CUBIC authors.

The Hystart paper used (modified pseudocode):

=C2=A0 if (currentRoundMinRTT> lastRoundMinRTT + clamp(lastRoundMinRTT /= 16))

The Linux implementation from the Hystart author Sangtae Ha in 2008 used th= e approach (pseudocode):

=C2=A0 if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 1= 6))

Eric Dumazet changed the Linux approach in 2014 to use a different constant= scaling factor (also pseudocode):

=C2=A0 if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 8= ))

I am curious about the rationale for:

(a) Using an RTT threshold for exiting slow-start that is based on currentR= oundMinRTT/8, rather than being purely a function of the RTT values from pr= evious rounds (as in the Hystart paper) or the lifetime of the connection (= as in Linux)?

(b) Using a function of lastRoundMinRTT and currentRoundMinRTT for the exit= threshold, rather than a function of the min RTT over the lifetime of the = connection ("lifetimeMinRTT" in my pseudocode, above)?
Is the rationale here partly to deal with fluctuations in RTT due to cellul= ar/wifi/DOCSIS paths with noisy RTTs?

Any background on the motivation would be interesting to hear, or perhaps t= o include in future drafts.

(2) The Limited Slow-Start approach described in the draft seems to boil do= wn to increasing cwnd by roughly ssthresh/4 each round trip.
It does seem like that would be considerably faster than Reno or CUBIC woul= d normally grow in congestion avoidance, for the first few seconds after ex= iting slow start. But it does seem to be essentially just a large additive = increase. And so it would seem that if CUBIC were instead in its native CUB= IC congestion avoidance instead of limited slow-start, then CUBIC would eve= ntually (e.g. after a few seconds) tend to reach the rapid-growth convex po= rtion of the cubic curve, and eventually grow much faster (eventually reach= ing exponential growth of 1.5x per round trip). I wonder if it would be adv= antageous for CUBIC connections exiting HyStart++ to use a=C2=A0 strategy o= f growing the cwnd using the maximum of the schedule calculated using limit= ed slow-start and the schedule calculated using the normal CUBIC congestion= avoidance logic. That seems like it might have the potential to mitigate p= erformance issues for CUBIC connections that spuriously exit slow-start too= soon?

best regards,
neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cp= ravb%40microsoft.com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988bf86f141af9= 1ab2d7cd011db47%7C1%7C0%7C636982816578522537&amp;sdata=3D0Sjqt2FWz1rKTq= ply%2FMJIzGeleyolWWNObL58KdCxm4%3D&amp;reserved=3D0
--0000000000003ae129058d477107-- From nobody Tue Jul 9 16:08: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 2888E1200F6 for ; Tue, 9 Jul 2019 16:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.205 X-Spam-Level: X-Spam-Status: No, score=-16.205 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 0VeC7MluwQea for ; Tue, 9 Jul 2019 16:08:51 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 BD13D1200C3 for ; Tue, 9 Jul 2019 16:08:50 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id s3so413014wms.2 for ; Tue, 09 Jul 2019 16:08:50 -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:content-transfer-encoding; bh=RFGWIyJ8UomFdQHf8tvoMCGq2s8XebABzhj93IftLec=; b=oSIPvGeR+jIQOcc+MP/gZEPy/IxJhZ+c3VyVaFmD5QvwE12BEcR7NfB3SEYR/JYeKC HPXlwyq41dyQoPReVZs7+mBa1zpVbbImbzDAcRJGAmUmNys068D4iEaNbKknLG5R5Eoe JXJbbFF/PaZCwTIxqdN47cN0t57oWFe2RvHat6EYXSn/49dLHYtNuaL4otDlECWe8l1s ok5uxyNC97FzQAs0UqA0Fm3VrhYJ8NYiyNo2F5Movo3VyYcCgq6nWcp3GI9oBhaekVgE JbDE/nf1gTzdXGNiZDfyybnMz9DvLCnOJMPtnm7JV+FpDTuiPMrYqJ46wolDB+6L4C81 q83Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RFGWIyJ8UomFdQHf8tvoMCGq2s8XebABzhj93IftLec=; b=oGHPT2YHpNwWkrlcdvW0nadFg9eVTwgoYgYMWEY9Rb6+r2lORJJACuID/XlPjw9PzF PkXMn42fd8QK15dU8XJGNUypGfa/dR1FLhseJ1vPKmwJ0o7SR3K0cB9NUgtrdGBQ+D8U akNtn85wZgipbe30QWrbLQl6K7jxH0yjl7+cr9nmffDikP1dDncBz9lAP0FBv2tl9Afn QyZXKXb9joLwSZZ/9FLPVkDHSJoCrctoCTQGELuShSXhBN5ezNSnxPVQdquj3YnTut7j KAThc52FMtvGzr/Y0VfJDjDJDU391sg6Iag5JFY7tB+HaZ+1KAi0EWXv7BKyUGcDXDo0 f7nQ== X-Gm-Message-State: APjAAAVChaJAxGFZj09KH87gIE8poRuumhLXG2sHC38RZS/Op+hXNefV W2uy5k8xBE2YCiqywctloMHepBtAbWCswPnqngg7dQ== X-Google-Smtp-Source: APXvYqxAwY5qqyM/Rm+/hPBY+3DaOVS6fwNKmfRjAE31RbwuxWAjMxzuFiEy223ru7PZRpb3Pl4HJWTFMyzrjBt3Zyw= X-Received: by 2002:a1c:c1c1:: with SMTP id r184mr1663655wmf.9.1562713728808; Tue, 09 Jul 2019 16:08:48 -0700 (PDT) MIME-Version: 1.0 References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> In-Reply-To: From: Yuchung Cheng Date: Tue, 9 Jul 2019 16:08:04 -0700 Message-ID: To: Jonathan Morton Cc: Bob Briscoe , tcpm IETF list , "ecn-sane@lists.bufferbloat.net" , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 23:08:52 -0000 On Tue, Jul 9, 2019 at 8:41 AM Jonathan Morton wrot= e: > > > On 13 Jun, 2019, at 7:48 pm, Bob Briscoe wrote: > > > > 1. It is quite unusual to experience queuing at more than one > > bottleneck on the same path (the available capacities have to > > be identical). > > Following up on David Black's comments, I'd just like to note that the ab= ove is not the true criterion for multiple sequential queuing. > > Many existing TCP senders are unpaced (aside from ack-clocking), includin= g FreeBSD, resulting in potentially large line-rate bursts at the origin - = especially during slow-start. Even in congestion avoidance, each ack will = trigger a closely spaced packet pair (or sometimes a triplet). It is then = easy to imagine, or to build a testbed containing, an arbitrarily long sequ= ence of consecutively narrower links; upon entering each, the burst of pack= ets will briefly collect in a queue and then be paced out at the new rate. > > TCP pacing does largely eliminate these bursts when implemented correctly= . However, Linux' pacing and IW is specifically (and apparently deliberate= ly) set up to issue a 10-packet line-rate burst on startup. This effect ha= s shown up in SCE tests to the point where we had to patch this behaviour o= ut of the sending kernel to prevent an instant exit from slow-start. We (Google TCP folks) are internally experimenting (always) pacing IW. May hurt very long RTT and short transfers (<=3DIW), but could be an overall win. > > - Jonathan Morton > From nobody Wed Jul 10 07:58:59 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3B9120319 for ; Wed, 10 Jul 2019 07:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 S5sC4B5OzoWk for ; Wed, 10 Jul 2019 07:58:55 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D71120341 for ; Wed, 10 Jul 2019 07:58:12 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:a042:d4a9:24f5:b661] (unknown [IPv6:2a02:8109:1140:c3d:a042:d4a9:24f5:b661]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 260C471B18AC8 for ; Wed, 10 Jul 2019 16:58:09 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_1016A2F2-6EB8-47E2-AC27-AF8B45CFAB64"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <6DBB15BB-5507-4DFC-83F7-F8E374DB4C83@fh-muenster.de> Date: Wed, 10 Jul 2019 16:58:07 +0200 To: tcpm IETF list X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [tcpm] First version of the agenda online X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 10 Jul 2019 14:58:57 -0000 --Apple-Mail=_1016A2F2-6EB8-47E2-AC27-AF8B45CFAB64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, the first version of the agenda for the TCPM meeting at IETF 105 is = available: https://datatracker.ietf.org/meeting/105/materials/agenda-105-tcpm-00 Looking forward to seeing you in Montreal Michael= --Apple-Mail=_1016A2F2-6EB8-47E2-AC27-AF8B45CFAB64 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA3 MTAxNDU4MDhaMC8GCSqGSIb3DQEJBDEiBCB5cCDIRLVtgxusKvY3ymfMHp0VkEiyGn6I59S6jolL /jCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEADzQEpcPJKGZTSopxSL9VvOwG3FVK iZHHSI1vc+xrulD8rnNhx8l0LFqdWrgeG8QML2HcGbIXWY77Xqi3nGFGQse9uDWYPwzX/2Uxhjva IFVK6JIUlJ68kK8IlcPmpNxhdv/OIJDDQw2NXvrC5+Ohqgzt9UTwD2Dl/y9Lo8jNf9WwMZIYaj+m HyXffbbPbzazCSw5cgtTb/2mhIBxt+8IRMl9tZasS3gzh1A4kN1LyJSOIvSq/SJCNGxY3WIZzT6X mHa36Jqs38k7gS3C/fBz8GFbTNpakabChHlUIYBh4CNL81Db8XIyjAWQnmWJLiIsf0JhA/0Jb+Fp KnO44/+sGgAAAAAAAA== --Apple-Mail=_1016A2F2-6EB8-47E2-AC27-AF8B45CFAB64-- From nobody Fri Jul 12 10:19: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 27AC41207DF; Fri, 12 Jul 2019 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=Mp1QORpL; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=wVps8XUj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8vuRzwmDsdC; Fri, 12 Jul 2019 10:19:26 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FE21203A9; Fri, 12 Jul 2019 10:19:26 -0700 (PDT) Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6CH9qsS030660; Fri, 12 Jul 2019 13:19:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=2cYhtS0iCwstZrRMNUJWNODG4ekfZlWaG1H6IX+Scj4=; b=Mp1QORpLUy7M9KDyhcyMFvjnSQ3/M/N/oVgEoChry+1hRQ92B6OptlGTnSkwSpp3avxT uVTdSZA2NtG/3s/CbhsSIIhoxmwa4WCNnkPgwIDULT+GLGE/u4sRA3K5C/TYz96VP/Sm WmX7E9V23k03qYdeyt2YswMPNHCDw/ECSydiaObSj6Dh6zMqVBKviJV4beixy5XRg35E vHxQaePuaw31fe5HgXnfprAcoJgHxxtgsUJoC0HzglKhP9YG2hnhGi2VQ9Mz6Z5FMKkf HooP+ELj1Uuo6i1zpyUhFHvHkcB7qjHiXmhVjjaZAzuXBdl7ZmMeGSU+5FF27jUjrXNo 3g== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2tpun68mj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 13:19:21 -0400 Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6CHJGX3069611; Fri, 12 Jul 2019 13:19:20 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2tptunkp70-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jul 2019 13:19:19 -0400 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6CHJDXk006923 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 13:19:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com x6CHJDXk006923 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1562951959; bh=vZJtNjY52nSLNiSjiqFQ4cxjBu8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wVps8XUjPZa9gpQJdbDPvwzfCSvcpu/Rcz6IjFellqg5RcQORecusLVDT7FkzO8DD yKV9FHRDFq7K+/G4ZVwmTKUutL1gW8pq0vPNMpXs5bLREW3jruJ0f32u67iB90EcJO SNmmhGA3Q4o6wRDzfVxPRwsveuEihVRl09Uz0oR8= Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 12 Jul 2019 13:19:01 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6CHJ0ra007270 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 12 Jul 2019 13:19:01 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 13:19:00 -0400 From: "Black, David" To: "rgrimes@freebsd.org" , "tcpm@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt Thread-Index: AQHVNer4HkPpSmkSZkWNhs7RvqhNPabHPt9A Date: Fri, 12 Jul 2019 17:18:59 +0000 Message-ID: References: <201907090007.x6907J5B040088@gndrsh.dnsmgr.net> In-Reply-To: <201907090007.x6907J5B040088@gndrsh.dnsmgr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-12T17:16:25.5778349Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.238.21.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-12_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907120177 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907120175 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:19:36 -0000 Rod, This draft appears to be focused on obtaining a TCP header bit for SCE. As an alternative to this single-bit proposal, please take a look at draft-= ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-ac= curate-ecn/) and consider how that functionality might (or might not) be us= able with SCE.=20 Thanks, --David > -----Original Message----- > From: tsvwg On Behalf Of Rodney W. Grimes > Sent: Monday, July 8, 2019 8:07 PM > To: tcpm@ietf.org; tsvwg@ietf.org > Subject: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce- > 00.txt >=20 >=20 > [EXTERNAL EMAIL] >=20 > I have posted a new version with updated proper tcpm working group > name of draft-grimes-tcpm-tcpsce-00 > (formerly draft-grimes-tcpmwg-tcpsce-00.txt) >=20 > This is first cut at how SCE works in TCP >=20 > Cross posting this to both tsvwg and tcpm due to overlap >=20 >=20 > > A new version of I-D, draft-grimes-tcpm-tcpsce-00.txt > > has been successfully submitted by Rodney W. Grimes and posted to the > > IETF repository. > > > > Name: draft-grimes-tcpm-tcpsce > > Revision: 00 > > Title: Some Congestion Experienced in TCP > > Document date: 2019-07-08 > > Group: Individual Submission > > Pages: 5 > > URL: https://www.ietf.org/internet-drafts/draft-grimes-tcpm-= tcpsce- > 00.txt > > Status: https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcps= ce/ > > Htmlized: https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-grimes-tcpm= - > tcpsce > > > > > > Abstract: > > This memo classifies a TCP code point ESCE ("Echo Some Congestion > > Experienced") for use in feedback of IP code point SCE ("Some > > Congestion Experienced"). >=20 > -- > Rod Grimes rgrimes@freebs= d.org From nobody Fri Jul 12 11:10:33 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F2D120802; Fri, 12 Jul 2019 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkJBkQgc2NGL; Fri, 12 Jul 2019 11:10:29 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED8C1207FD; Fri, 12 Jul 2019 11:10:17 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id p17so10219922ljg.1; Fri, 12 Jul 2019 11:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lWTh7FWUu2P0DIbCMB3WRpP/7ZoGa8NX89vVpQ+bBM0=; b=arMpPszuzUWP6meDgTJvLWd4sEU0MF3STnyQHKhWBNsSMVxMeAProkrIsjuUiO1BKb VjhrLQ7lnXwM+gnpsneYqZB1W7kxVy1HlQ6z/uu+DriBC+pdkuRrJJ8pvs5idJb64L5X ry+1U8r7VBg03+6CqZBJao/NmWk1VzaUjqG1WQCY0EMaw2psMlNEiROYCLPBiPgSSIo4 fsNpXwgPOuubz0TLqur78XxGqDS83hUM3qXl5oetDjbkFUIAwpTDDV50FsxJZz/f8cLx ggWG39VGKCkLFXHRe/lSpPRqVQ8rJOLi9mtW9sxivUqEopfX5GzChagQ/yp6iMbOd4W+ CyYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lWTh7FWUu2P0DIbCMB3WRpP/7ZoGa8NX89vVpQ+bBM0=; b=L/6RrkWVsy2fnEt+htHuHvUHec+fh4xQAcu6jA9tO5xb9NOUrIgOdJUHZ0woxEWWeg ErIt7ot/4GreWx1ZtaKKv8NoD/rmmQg57ZDfC8XeiO0LHKnbJa/PxHysrxkjAcsmqOIn Kb1PKX/IgjHSpLc4b9xjbhR9K7TCykMVJ3u+GSxU4BIgFgQ5kjDWqUwP51yyrvZ+uePl GLYHAeZo+vouGYr/9rnHwAfot/fO29poHb2cNZQv26uxZWlPgOg1OsiRpRWVAW44Y9xX Lu79nmZmbe4WusUi7S9HDDszLDBcCv+rRy7KCe0Sn2/4ZWfZdm6GYMd/iWYfFdfjNQKS 92Kg== X-Gm-Message-State: APjAAAWmU/ErcxsxnSDU64pXa6zUYL5q4XqVSLlHWuoLMsIKMegdcCLA A/LsXjr1Nl9d6vUQ6kJDowc= X-Google-Smtp-Source: APXvYqx04jDjs+s7e5RvL6r1HHQqRePIPdWC1QO0juMPdJZbQ9oWI6Genk+XbjSCvc1b/OfY8MB1Tw== X-Received: by 2002:a2e:87d0:: with SMTP id v16mr6817681ljj.24.1562955015374; Fri, 12 Jul 2019 11:10:15 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-234-41-nat-p.elisa-mobile.fi. [83.245.234.41]) by smtp.gmail.com with ESMTPSA id f10sm1191066lfh.82.2019.07.12.11.10.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 11:10:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Fri, 12 Jul 2019 21:10:12 +0300 Cc: "rgrimes@freebsd.org" , "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <201907090007.x6907J5B040088@gndrsh.dnsmgr.net> To: "Black, David" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 18:10:31 -0000 > On 12 Jul, 2019, at 8:18 pm, Black, David = wrote: >=20 > As an alternative to this single-bit proposal, please take a look at = draft-ietf-tcpm-accurate-ecn = (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and = consider how that functionality might (or might not) be usable with SCE.=20= We did look into this, but found some shortcomings that simple reuse of = the NS bit (or assigning one of the other spare TCP header bits adjacent = to NS) neatly overcomes. First is that much of AccECN is focused on providing accurate feedback = of CE marks, which is not very relevant to SCE since the existing = ECE/CWR mechanism from RFC-3168 works well. For this purpose the NS bit = is also consumed, forming a 3-bit field that straddles a byte boundary = and is thus awkward to parse. A simple transformation of this field into one that counts SCE marks = doesn't work, because feedback of CE marks is then lost. Retaining the = original response to purely CE-based congestion feedback is a crucial = part of SCE's design for incremental deployment. To get feedback of ECT(1) which carries the SCE information, the full = length of the AccECN TCP Option must be used, inflating the volume of = the ack stream - and concerns have been raised about TCP Options in = discussions here. A similar concern made one of our other ideas = (replacing TCP Timestamps with a slight larger option that would absorb = the NOP padding currently used) less desirable, though that also avoided = the ack-inflation problem. We therefore tried to explore ideas that posed minimum risk of confusing = firewalls or increasing software complexity. We considered that reusing = a bit that had previously been assigned to an ECT(1) related mechanism = would be safest, and subsequently found that it could convey all the = information needed with sufficient reliability. I agree that this draft could be improved to explain the above choice = and give more detail on the expected semantics. I'll work with Rod to = sort that out. - Jonathan Morton From nobody Sat Jul 13 08:47: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 181121200D7; Fri, 12 Jul 2019 12:39:59 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fknzBamGNp0z; Fri, 12 Jul 2019 12:39:56 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894A6120091; Fri, 12 Jul 2019 12:39:56 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6CJdlgc060766; Fri, 12 Jul 2019 12:39:47 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6CJdlp7060765; Fri, 12 Jul 2019 12:39:47 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> In-Reply-To: To: "Black, David" Date: Fri, 12 Jul 2019 12:39:47 -0700 (PDT) CC: "rgrimes@freebsd.org" , "tcpm@ietf.org" , "tsvwg@ietf.org" Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Sat, 13 Jul 2019 08:47:32 -0700 Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 19:39:59 -0000 > Rod, > > This draft appears to be focused on obtaining a TCP header bit for SCE. Yes, that is correct. > As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. I specifically did not do what Accurate Ecn attempts as that requires a TCP option negotiation at connection establishment to negotiate the overloading of other TCP header bits. SCE only needs 1 new bit, and does not alter the behavior of any current bits. This proposal (TCPSCE) does not in any way effect the current use of any of the other bits, and use of the NS bit should be fully backwards compatible and ignored by pre SCE implementations and does not require a TCP option negotiation. I have to get additional data but have been lead to understand that adding a tcp option and doing that negotiation is going to cause a great deal of pain in the ability to deploy accurate ecn as it is currently designed due to middle box inspection and handling. Regards, Rod > Thanks, --David > > > -----Original Message----- > > From: tsvwg On Behalf Of Rodney W. Grimes > > Sent: Monday, July 8, 2019 8:07 PM > > To: tcpm@ietf.org; tsvwg@ietf.org > > Subject: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce- > > 00.txt > > > > > > [EXTERNAL EMAIL] > > > > I have posted a new version with updated proper tcpm working group > > name of draft-grimes-tcpm-tcpsce-00 > > (formerly draft-grimes-tcpmwg-tcpsce-00.txt) > > > > This is first cut at how SCE works in TCP > > > > Cross posting this to both tsvwg and tcpm due to overlap > > > > > > > A new version of I-D, draft-grimes-tcpm-tcpsce-00.txt > > > has been successfully submitted by Rodney W. Grimes and posted to the > > > IETF repository. > > > > > > Name: draft-grimes-tcpm-tcpsce > > > Revision: 00 > > > Title: Some Congestion Experienced in TCP > > > Document date: 2019-07-08 > > > Group: Individual Submission > > > Pages: 5 > > > URL: https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce- > > 00.txt > > > Status: https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/ > > > Htmlized: https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-00 > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-grimes-tcpm- > > tcpsce > > > > > > > > > Abstract: > > > This memo classifies a TCP code point ESCE ("Echo Some Congestion > > > Experienced") for use in feedback of IP code point SCE ("Some > > > Congestion Experienced"). > > > > -- > > Rod Grimes rgrimes@freebsd.org > > > -- Rod Grimes rgrimes@freebsd.org From nobody Tue Jul 16 23:59: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 CF09D120198 for ; Tue, 16 Jul 2019 23:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VzKHYNuqQxa for ; Tue, 16 Jul 2019 23:59:02 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C189512019B for ; Tue, 16 Jul 2019 23:59:00 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id u25so10549407wmc.4 for ; Tue, 16 Jul 2019 23:59:00 -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=qmdvNuAxOkR6CKtdjZhlgLMh26+aZgI6KlLnR8AwjkY=; b=ElUvrpUgNAB0rdFQZk8ADrZE6OJHsg3RrrZJHuRY3oEuaO8Ii2NPOiQ58iFN1rMuO/ S0kCtYRrFkjQXeTdBfF3GypEsweaY8odhL6IgXckHvGCZ8OqOzqkY3CRyiuK2/uzs6H8 9BoIVsofiyBoZvkb3W2ClLShLTPbsLfYwNqMZ0Npbp0nijw2DQ8qBhjIw4zz99IXW09K NDaxvKkgq+jc8H/q7Bcn0CYh2ur99WwM9AwjSjMJM5+DFnJ/Z2cZKlOrWZrO6DvrRpPr JYpUCXuDIY2bvpImMbYhtWhX+eUCjgEvz6Zha9S0E9mr/ybBezR+GKUUpiApSv5u0ma9 BIwA== 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=qmdvNuAxOkR6CKtdjZhlgLMh26+aZgI6KlLnR8AwjkY=; b=ora+NQnMD4kQrxWgcIH8OI+A/s0W79d2XAQ0ArrF5NEHRayClD/YdADqecw8Uo81P9 EWGlqxXJOtqPElqJZq23cvvGCfKj5VEDlBcHKB468assONveQa8ngyLFH4ZIa2UMgP5C 5MgQFvBVopAPuVfFiSsjKs0SwLjyHLUeOZaW/TMD+VzjXq5oHuxO1Kd7gsy1ulQrRw2b /jh119oYFZjjIZRK0eGQGED1E6TE7JqwLGic1aQsNB2Nh9Fdh39ebTKsZjvSPWFJm95o Zjd/iK6xjQzGXjZ22dx87Dav0KzLJAopEJvsjIO8xSrc8kdoe/GNJifUoJd8LM8z+bQX ptZA== X-Gm-Message-State: APjAAAWuU5EVfqNEauwZxSgnSefUn5ozkiCvMk+EaDL0p/9WanGIDi8b 90HBnVFBdniOSb7/0OWo1DFcH72K/rpENgxbaqU= X-Google-Smtp-Source: APXvYqzkQn8QhbGgXTYfpTlGAThhP0vDn0Wvwd6lFQdgvk52Xhy0097nuB0jqdh/8TngjIvagYpsvcxuwDvLaPyIBWo= X-Received: by 2002:a1c:7c11:: with SMTP id x17mr32186592wmc.22.1563346739326; Tue, 16 Jul 2019 23:58:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Tue, 16 Jul 2019 23:58:48 -0700 Message-ID: To: Carles Gomez Montenegro Cc: "tcpm@ietf.org Extensions" , jon.crowcroft@cl.cam.ac.uk Content-Type: multipart/alternative; boundary="0000000000000ef2d2058ddb0726" Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 06:59:07 -0000 --0000000000000ef2d2058ddb0726 Content-Type: text/plain; charset="UTF-8" Hi Carles, Thanks for the draft. I think understand the motivation, although I think using a reserved flag is a bit expensive as it's sparse resource. I am thinking utilizing MAD option proposal (draft-wang-tcpm-low-latency-opt-00) might be another option for this. If we know the maximum ACK delay values from this option and sender's window size is one MSS, we can set a certain sleep timer for sender after transmitting a packet. This may be able to save the battery on the sender side. Thanks, -- Yoshi On Tue, Jul 2, 2019 at 12:25 AM Carles Gomez Montenegro < carlesgo@entel.upc.edu> wrote: > Dear WG, > > Please find below the pointers to a new Internet Draft that describes a > simple "ACK Pull" mechanism, intended to improve performance in a number > of scenarios / use cases. > > Comments are very much welcome. > > Thanks, > > Carles and Jon > > > ---------------------------- Original Message ---------------------------- > Subject: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt > From: internet-drafts@ietf.org > Date: Mon, July 1, 2019 5:08 pm > To: "Jon Crowcroft" > "Carles Gomez" > -------------------------------------------------------------------------- > > > A new version of I-D, draft-gomez-tcpm-ack-pull-00.txt > has been successfully submitted by Carles Gomez and posted to the > IETF repository. > > Name: draft-gomez-tcpm-ack-pull > Revision: 00 > Title: TCP ACK Pull > Document date: 2019-07-01 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-gomez-tcpm-ack-pull-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/ > Htmlized: https://tools.ietf.org/html/draft-gomez-tcpm-ack-pull-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-pull > > > Abstract: > Delayed Acknowledgments (ACKs) allow reducing protocol overhead in > many scenarios. However, in some cases, Delayed ACKs may > significantly degrade network and device performance in terms of link > utilization, latency, memory usage and/or energy consumption. This > document defines the TCP ACK Pull (AKP) mechanism, which allows a > sender to request the ACK for a data segment to be sent without > additional delay by the receiver. AKP makes use of one of the > reserved bits in the TCP header, which is defined in this > specification as the AKP flag. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000000ef2d2058ddb0726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carles,=C2=A0

Thanks for = the draft. I think understand the motivation, although I think using a rese= rved flag is a bit expensive as it's sparse resource.
I am th= inking utilizing MAD option proposal (draft-wang-tcpm-low-latency-opt-00) m= ight be another option for this.
If we know the maximum ACK delay= values from this option and sender's window size is one MSS, we can se= t a certain sleep timer for sender after transmitting a packet.
T= his may be able to save the battery on the sender side.

Thanks,
--
Yoshi

On Tue, Jul 2, 2019 = at 12:25 AM Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:
Dear WG,

Please find below the pointers to a new Internet Draft that describes a
simple "ACK Pull" mechanism, intended to improve performance in a= number
of scenarios / use cases.

Comments are very much welcome.

Thanks,

Carles and Jon


---------------------------- Original Message ----------------------------<= br> Subject: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt
From:=C2=A0 =C2=A0 internet-drafts@ietf.org
Date:=C2=A0 =C2=A0 Mon, July 1, 2019 5:08 pm
To:=C2=A0 =C2=A0 =C2=A0 "Jon Crowcroft" <jon.crowcroft@cl.cam.ac.uk&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Carles Gomez" <carlesgo@entel.upc.edu&= gt;
--------------------------------------------------------------------------<= br>

A new version of I-D, draft-gomez-tcpm-ack-pull-00.txt
has been successfully submitted by Carles Gomez and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gomez-tcpm-ack-pull
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP ACK Pull
Document date:=C2=A0 2019-07-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
https://www.ietf.org/internet-d= rafts/draft-gomez-tcpm-ack-pull-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-gomez-tcpm-ack-pull-00
Htmlized:=C2=A0 =C2=A0 =C2=A0
https://datatracker.ietf.org/doc/html= /draft-gomez-tcpm-ack-pull


Abstract:
=C2=A0 =C2=A0Delayed Acknowledgments (ACKs) allow reducing protocol overhea= d in
=C2=A0 =C2=A0many scenarios.=C2=A0 However, in some cases, Delayed ACKs may=
=C2=A0 =C2=A0significantly degrade network and device performance in terms = of link
=C2=A0 =C2=A0utilization, latency, memory usage and/or energy consumption.= =C2=A0 This
=C2=A0 =C2=A0document defines the TCP ACK Pull (AKP) mechanism, which allow= s a
=C2=A0 =C2=A0sender to request the ACK for a data segment to be sent withou= t
=C2=A0 =C2=A0additional delay by the receiver.=C2=A0 AKP makes use of one o= f the
=C2=A0 =C2=A0reserved bits in the TCP header, which is defined in this
=C2=A0 =C2=A0specification as the AKP flag.




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

The IETF Secretariat



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000000ef2d2058ddb0726-- From nobody Wed Jul 17 00:56: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 B2C1312019F for ; Wed, 17 Jul 2019 00:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQIDjAC3JJ2e for ; Wed, 17 Jul 2019 00:56:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E896C12009C for ; Wed, 17 Jul 2019 00:56:09 -0700 (PDT) Received: from [192.168.217.110] (p548DCE40.dip0.t-ipconnect.de [84.141.206.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45pV2H1Qxqz14b4; Wed, 17 Jul 2019 09:56:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 17 Jul 2019 09:56:06 +0200 Cc: Carles Gomez Montenegro , "tcpm@ietf.org Extensions" , jon.crowcroft@cl.cam.ac.uk X-Mao-Original-Outgoing-Id: 585042964.52837-271dbd517440f49c302faef0fa71dbbb Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 07:56:12 -0000 On Jul 17, 2019, at 08:58, Yoshifumi Nishida wrote: >=20 > using a reserved flag is a bit expensive The option could simply redefine existing PSH as having the AKP = semantics. (And possibly all packets having what used to be the PSH semantics.) They are close enough anyway=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 17 04:06:30 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DBE1200B2 for ; Wed, 17 Jul 2019 04:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 RmWRwMJ5aJn9 for ; Wed, 17 Jul 2019 04:06:26 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04124120048 for ; Wed, 17 Jul 2019 04:06:26 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:7843:89ae:ec92:371] (unknown [IPv6:2a02:8109:1140:c3d:7843:89ae:ec92:371]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id A35DB72106C25; Wed, 17 Jul 2019 13:06:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: Date: Wed, 17 Jul 2019 13:06:20 +0200 Cc: Yoshifumi Nishida , jon.crowcroft@cl.cam.ac.uk, "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <5E0F8087-6B8A-4608-8C52-F4C5BA188B84@lurchi.franken.de> References: To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 11:06:29 -0000 > On 17. Jul 2019, at 09:56, Carsten Bormann wrote: >=20 > On Jul 17, 2019, at 08:58, Yoshifumi Nishida = wrote: >>=20 >> using a reserved flag is a bit expensive >=20 > The option could simply redefine existing PSH as having the AKP = semantics. > (And possibly all packets having what used to be the PSH semantics.) Could you define what you mean by "what used to be the PSH semantics"? > They are close enough anyway=E2=80=A6 Hmm. My understanding of the OSH semantic is that it might trigger a = local behaviour on the receiver side: Deliver data to the application. The AKP semantic is to trigger an behaviour on the network: send an ACK = segment. Best regards Michael >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 17 05:45:04 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709521200C7 for ; Wed, 17 Jul 2019 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo5Z2NUpt08B for ; Wed, 17 Jul 2019 05:44:59 -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 8B88412004D for ; Wed, 17 Jul 2019 05:44:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0CB3C25A18; Wed, 17 Jul 2019 14:44:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563367498; bh=vQbFsIedDzJELc5ChuJmYOi7/7Wd/mGhZRSFUMj+ytA=; h=From:To:CC:Subject:Date:From; b=JCLpuKZ1AeZ3oc5lH102B/p9GA/Ho+P1F2gqL4TPb2RqCAgSeR4QYHefK9fh4dkSQ c9U3eLAZn37WD69zlLvrSjzXh1I/+knYTS4oAlG35WU7khHt+vbVkVa7gX6V+glP4k 95LYo8vjf1DCvGmCPKIeOQP/7bCwmigunWi2EEsc= 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 PT6fV1Puzwwd; Wed, 17 Jul 2019 14:44:57 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 17 Jul 2019 14:44:57 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 17 Jul 2019 14:44:56 +0200 From: "Scharf, Michael" To: Carsten Bormann , Yoshifumi Nishida CC: "jon.crowcroft@cl.cam.ac.uk" , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] Thread-Index: AdU8nW+IDa2PDN2I0Eq3gpEStoBnrg== Content-Class: urn:content-classes:message Date: Wed, 17 Jul 2019 12:44:55 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3B2F41rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 12:45:03 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3B2F41rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0IHRoYXQgdGhpcyBjb3VsZCBiZSBmb3JtYWxpemVk IGFzIGZvbGxvd3M6DQoNCiAgQSBUQ1AgTUFZIG5vdCBkZWxheSBBQ0tzIGZvciBkYXRhIHNlZ21l bnRzIHdpdGggdGhlIFBTSCBmbGFnLg0KDQpJZiB0aGF0IHdhcyB0aGUgaW50ZW50aW9uLCBJIGJl bGlldmUgdGhhdCB0aGUgd29yZGluZyBvZiBSRkMgMTEyMiAoYW5kIGRyYWZ0LWlldGYtdGNwbS1y ZmM3OTNiaXMpIHdvdWxkIGFsbG93IHN1Y2ggYSByZWNlaXZlci1zaWRlIGhldXJpc3RpYyBhbHJl YWR5LiBEZWxheWVkIEFDS3MgYXJlIGEgU0hPVUxEIGluIFJGQyAxMTIyIGFuZCB0aGUgZXhhY3Qg bG9naWMgaXMgbm90IHNwZWNpZmllZC4gVGh1cywgdGFraW5nIHRoZSBQU0ggZmxhZyBpbnRvIGFj Y291bnQgaW5zaWRlIGEgcmVjZWl2ZXItc2lkZSBkZWxheWVkIEFDSyBoZXVyaXN0aWMgbWF5IG5v dCBldmVuIGJlIGEgY2hhbmdlIG9mIHRoZSBUQ1Agc2VtYW50aWNz4oCmDQoNCk1pY2hhZWwNCg0K DQpWb246IENhcnN0ZW4gQm9ybWFubjxtYWlsdG86Y2Fib0B0emkub3JnPg0KR2VzZW5kZXQ6IE1p dHR3b2NoLCAxNy4gSnVsaSAyMDE5IDA5OjU2DQpBbjogWW9zaGlmdW1pIE5pc2hpZGE8bWFpbHRv Om5zZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51azxtYWls dG86am9uLmNyb3djcm9mdEBjbC5jYW0uYWMudWs+OyB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnM8 bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpCZXRyZWZmOiBSZTogW3RjcG1dIFtGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ29tZXotdGNwbS1hY2stcHVsbC0wMC50eHRdDQoN Ck9uIEp1bCAxNywgMjAxOSwgYXQgMDg6NTgsIFlvc2hpZnVtaSBOaXNoaWRhIDxuc2QuaWV0ZkBn bWFpbC5jb20+IHdyb3RlOg0KPg0KPiAgdXNpbmcgYSByZXNlcnZlZCBmbGFnIGlzIGEgYml0IGV4 cGVuc2l2ZQ0KDQpUaGUgb3B0aW9uIGNvdWxkIHNpbXBseSByZWRlZmluZSBleGlzdGluZyBQU0gg YXMgaGF2aW5nIHRoZSBBS1Agc2VtYW50aWNzLg0KKEFuZCBwb3NzaWJseSBhbGwgcGFja2V0cyBo YXZpbmcgd2hhdCB1c2VkIHRvIGJlIHRoZSBQU0ggc2VtYW50aWNzLikNClRoZXkgYXJlIGNsb3Nl IGVub3VnaCBhbnl3YXnigKYNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1A aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D3B2F41rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-ID: <5A2CABA8CB6F904886252E2BE0E7BCC6@exchange.hs-esslingen.de> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAy LjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0IHRoYXQgdGhpcyBjb3VsZCBiZSBmb3JtYWxp emVkIGFzIGZvbGxvd3M6PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgQSBUQ1AgTUFZIG5vdCBkZWxheSBB Q0tzIGZvciBkYXRhIHNlZ21lbnRzIHdpdGggdGhlIFBTSCBmbGFnLjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg dGhhdCB3YXMgdGhlIGludGVudGlvbiwgSSBiZWxpZXZlIHRoYXQgdGhlIHdvcmRpbmcgb2YgUkZD IDExMjIgKGFuZCBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzKSB3b3VsZCBhbGxvdyBzdWNoIGEg cmVjZWl2ZXItc2lkZSBoZXVyaXN0aWMgYWxyZWFkeS4gRGVsYXllZCBBQ0tzIGFyZSBhIFNIT1VM RCBpbiBSRkMgMTEyMiBhbmQgdGhlIGV4YWN0IGxvZ2ljIGlzIG5vdCBzcGVjaWZpZWQuIFRodXMs IHRha2luZw0KIHRoZSBQU0ggZmxhZyBpbnRvIGFjY291bnQgaW5zaWRlIGEgcmVjZWl2ZXItc2lk ZSBkZWxheWVkIEFDSyBoZXVyaXN0aWMgbWF5IG5vdCBldmVuIGJlIGEgY2hhbmdlIG9mIHRoZSBU Q1Agc2VtYW50aWNz4oCmPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1i b3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3Jk ZXI6bm9uZTtwYWRkaW5nOjBjbSI+PGI+Vm9uOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHpp Lm9yZyI+Q2Fyc3RlbiBCb3JtYW5uPC9hPjxicj4NCjxiPkdlc2VuZGV0OiA8L2I+TWl0dHdvY2gs IDE3LiBKdWxpIDIwMTkgMDk6NTY8YnI+DQo8Yj5BbjogPC9iPjxhIGhyZWY9Im1haWx0bzpuc2Qu aWV0ZkBnbWFpbC5jb20iPllvc2hpZnVtaSBOaXNoaWRhPC9hPjxicj4NCjxiPkNjOiA8L2I+PGEg aHJlZj0ibWFpbHRvOmpvbi5jcm93Y3JvZnRAY2wuY2FtLmFjLnVrIj5qb24uY3Jvd2Nyb2Z0QGNs LmNhbS5hYy51azwvYT47DQo8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRm Lm9yZyBFeHRlbnNpb25zPC9hPjxicj4NCjxiPkJldHJlZmY6IDwvYj5SZTogW3RjcG1dIFtGd2Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ29tZXotdGNwbS1hY2stcHVsbC0w MC50eHRdPC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAxNywgMjAxOSwgYXQgMDg6NTgsIFlv c2hpZnVtaSBOaXNoaWRhICZsdDtuc2QuaWV0ZkBnbWFpbC5jb20mZ3Q7IHdyb3RlOjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZu YnNwOyB1c2luZyBhIHJlc2VydmVkIGZsYWcgaXMgYSBiaXQgZXhwZW5zaXZlPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgb3B0aW9uIGNvdWxkIHNpbXBseSByZWRlZmluZSBleGlzdGluZyBQU0ggYXMgaGF2aW5n IHRoZSBBS1Agc2VtYW50aWNzLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihBbmQgcG9zc2li bHkgYWxsIHBhY2tldHMgaGF2aW5nIHdoYXQgdXNlZCB0byBiZSB0aGUgUFNIIHNlbWFudGljcy4p PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhleSBhcmUgY2xvc2UgZW5vdWdoIGFueXdheeKA pjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+R3LDvMOfZSwgQ2Fyc3RlbjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj50Y3BtIG1haWxpbmcgbGlzdDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG1AaWV0 Zi5vcmc8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG08L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D3B2F41rznt8114rzntrzd_-- From nobody Wed Jul 17 06:41: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 2E6ED120400 for ; Wed, 17 Jul 2019 06:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mqeuoh4PI4aa for ; Wed, 17 Jul 2019 06:40:56 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71653120406 for ; Wed, 17 Jul 2019 06:40:56 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:d878:d920:c09d:25c5] (unknown [IPv6:2a02:8109:1140:c3d:d878:d920:c09d:25c5]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 5687172106C2C; Wed, 17 Jul 2019 15:40:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Wed, 17 Jul 2019 15:40:52 +0200 Cc: Carsten Bormann , Yoshifumi Nishida , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Content-Transfer-Encoding: quoted-printable Message-Id: <437D3782-04FB-4D5B-9A38-4BA9DB7C2ECF@lurchi.franken.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 13:40:58 -0000 > On 17. Jul 2019, at 14:44, Scharf, Michael = wrote: >=20 > Is my understanding correct that this could be formalized as follows: > =20 > A TCP MAY not delay ACKs for data segments with the PSH flag. I think this is what Carsten was referring to. My point was: Is this already deployed? The reason I'm asking is that I have heard several time that the = semantic of the PSH bit is to send out an ACK immediately. I could not find the source = of this statement... Best regards Michael > =20 > If that was the intention, I believe that the wording of RFC 1122 (and = draft-ietf-tcpm-rfc793bis) would allow such a receiver-side heuristic = already. Delayed ACKs are a SHOULD in RFC 1122 and the exact logic is = not specified. Thus, taking the PSH flag into account inside a = receiver-side delayed ACK heuristic may not even be a change of the TCP = semantics=E2=80=A6 > =20 > Michael > =20 > =20 > Von: Carsten Bormann > Gesendet: Mittwoch, 17. Juli 2019 09:56 > An: Yoshifumi Nishida > Cc: jon.crowcroft@cl.cam.ac.uk; tcpm@ietf.org Extensions > Betreff: Re: [tcpm] [Fwd: New Version Notification for = draft-gomez-tcpm-ack-pull-00.txt] > =20 > On Jul 17, 2019, at 08:58, Yoshifumi Nishida = wrote: > > > > using a reserved flag is a bit expensive > =20 > The option could simply redefine existing PSH as having the AKP = semantics. > (And possibly all packets having what used to be the PSH semantics.) > They are close enough anyway=E2=80=A6 > =20 > Gr=C3=BC=C3=9Fe, Carsten > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 17 09:21: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 E224012066F for ; Wed, 17 Jul 2019 09:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPKtsD9dWesI for ; Wed, 17 Jul 2019 09:21:39 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740118.outbound.protection.outlook.com [40.107.74.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B46120657 for ; Wed, 17 Jul 2019 09:21:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ArsDD+T/dNmcHmK9jHnNQO6PahpXyr0BokiQ+l+DhgLLR2lizwb62LlHqOFUyKkwWy1xDbq/ut+H9oQHo35Jt1Y/o8E64goO0cGvKzBoNe2l6KM4fCoADIPNEd7oKhY7ckhyVSwiGKDc1huMCo1JzKPh/nTaGNd1tO0IhUQWrIYO3xGZYaUfFCSTDDyIi9gzYWOsZ6vAMyw8Y11/mhcRgLWw9iVAJ5tHH1djvp8wdXnd7aX/FyihrHvHf3g2JsJMCpU38zXOuoma6yqvWAzdMxjsmP/dXhYHwfFuu9Fx+C72bw6Y4fo4/lggUiaOoMJNlzGa42RU/EREbneD/oZiQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rqCzuLeU0vS6mPALt7TEqJC2+cHDs4btpSoeMZF0b8g=; b=mAGIyp5mqjoyGGyzuWerAM/RGQLWgu9qNgnuTV0pgGsJNqpPJcwpF817FC/+TJ9Y4sZvtGLe4F2TooYmJu9kjBiolpF1lVQwZXQ1CUe9lNoUww+AUzoANWzGWe8d/I9MSjONIeb/604bDFaIIZbKNCf01S0Yd+nSj7/K/3ctszujDGxJV3S4W1zgJF9P9VI5j203dzsxGnk5vW0H39N8//BV6FCSHKR5bgfNMPSB+nNuBxHrMEz1uNui3yLw/10Mds/g7D7ybWvtZNGBxsdT8UGc7MYjjAXp3SAEiYq/s0vY7Kvi84Hy2602yzGS6Fs9AETu1gOU5m2R1PbC9YWfNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rqCzuLeU0vS6mPALt7TEqJC2+cHDs4btpSoeMZF0b8g=; b=IqdodNefxG7zIdZhsl9xQlv3+vhygPZ218A/+86T+UPE7imnPb52iut2XMlSZLJHnQ7Hu0WCwTUv7bePIWXPR7gABLoWYaTqCQmlGqk00pXsxbTWNJv4HQWZWsN5fJJpWOHQWVW+7JvwD/FQs6r8xM2qSzm9ygbCpVBd+Oc4I0Q= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0938.namprd21.prod.outlook.com (52.132.146.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.1; Wed, 17 Jul 2019 16:21:37 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab%5]) with mapi id 15.20.2115.003; Wed, 17 Jul 2019 16:21:37 +0000 From: Praveen Balasubramanian To: Michael Tuexen , "Scharf, Michael" CC: "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Thread-Topic: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] Thread-Index: AdU8nW+IDa2PDN2I0Eq3gpEStoBnrgAB9CQAAAUzQzA= Date: Wed, 17 Jul 2019 16:21:37 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> <437D3782-04FB-4D5B-9A38-4BA9DB7C2ECF@lurchi.franken.de> In-Reply-To: <437D3782-04FB-4D5B-9A38-4BA9DB7C2ECF@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-17T16:21:35.8758624Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9cea1cbc-a016-4bb3-8941-dec95fe1df8a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:8:6c76:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 92900ec0-d829-4672-04f4-08d70ad2d7dc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB0938; x-ms-traffictypediagnostic: MW2PR2101MB0938: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(199004)(189003)(13464003)(6116002)(6506007)(305945005)(8990500004)(11346002)(14444005)(71200400001)(53546011)(71190400001)(446003)(256004)(10290500003)(4326008)(68736007)(10090500001)(476003)(186003)(7736002)(8936002)(316002)(14454004)(22452003)(76176011)(81156014)(81166006)(102836004)(74316002)(54906003)(110136005)(55016002)(8676002)(9686003)(6306002)(52536014)(966005)(2906002)(561944003)(6436002)(25786009)(33656002)(15650500001)(66556008)(6246003)(66476007)(66446008)(486006)(66946007)(229853002)(64756008)(5660300002)(7696005)(46003)(53936002)(76116006)(86362001)(478600001)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0938; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HDYHQFZlXfMMocKlXNsHL2rS6z/cGcPZnMEQ/WwPXd7JlMDi64VgF0UnAPhcMZeI9Qo+poRg0ER/ZxgbvF9gKMB34BcF1m54+APnbakOMNnsE75+RK9Vrg9W8V/PRuBTqZMeDAXeV+YwbGHweIwNsGbtSQh6pYO6CD1nHzeWUAGkXVLzOSYr6TtA6Ih8irWwgOqvyxNyxKIigM2CxVxAvIg6ubnHDmRikr3eZcMMuvqbi2PYN8SF1wxgYxEbWmUeK2pWr7tRBMJPI42iPlrKhLBquuk/NE2Q6AxEwpP72/6MsURaO+taelrvGfxDsKkHDL4g1KhQb3CHDoTxfbkJvkXLWuEhF6qzqdzBH3DW8//dtSYvYNV9E9nGtuhqDMZ1N0mU/YG2lSn03we2CrHvjerFdrZlifNrp9MiACenCIE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92900ec0-d829-4672-04f4-08d70ad2d7dc X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 16:21:37.5687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0938 Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 16:21:42 -0000 V2luZG93cyBUQ1Agb24gc2VuZGVyIHNpZGUgd2lsbCBzZXQgUFNIIGF0IHRoZSBtZXNzYWdlIGJv dW5kYXJ5IGkuZS4gd2hlbiBpdCBmaW5pc2hlcyBnZW5lcmF0aW5nIHNlbmRzIGFzIHBhcnQgb2Yg YSBwb3N0ZWQgc2VuZCgpIEFQSSBjYWxsIG9yIGVxdWl2YWxlbnQuIE9uIHJlY2VpdmVyIHNpZGUg aG93ZXZlciBpdCBkb2VzIG5vdCBnZW5lcmF0ZWQgaW1tZWRpYXRlIEFDSyB1cG9uIHJlY2Vpdmlu ZyBQU0guIElJUkMgTGludXggYWxzbyBzZXRzIFBTSCBvbiBzZW5kbXNnKCkgYm91bmRhcnkuIE5v dCBzdXJlIGFib3V0IG90aGVyIGltcGxlbWVudGF0aW9ucy4gSWYgbW9zdCBtYWpvciBpbXBsZW1l bnRhdGlvbnMgYXJlIGRvaW5nIHRoaXMgdGhlbiBnZW5lcmF0aW5nIGltbWVkaWF0ZSBBQ0sgdXBv biBQU0ggd2lsbCBiZSBhbiBpbXByb3ZlbWVudC4gDQoNCkkgZG8gdGhpbmsgcmV1c2luZyBQU0gg dG8gcmVxdWlyZSBlbGljaXRpbmcgQUNLcyBpcyBhIHJlYXNvbmFibGUgYWx0ZXJuYXRpdmUgdGhh biB1c2luZyB1cCBhIHJlc2VydmVkIGJpdC4gT25lIGNvbmNlcm4gd2l0aCBib3RoIHRoZSBvcmln aW5hbCBkcmFmdCBhbmQgdGhlIFBTSCBwcm9wb3NhbCBpcyB0aGF0IHdlJ2xsIG5lZWQgY2xlYXIg cmVjb21tZW5kYXRpb25zIG9uIHdoZW4gYSByZWNlaXZlciB3aWxsIHJlcXVlc3QgdGhpcy4gT3Ro ZXJ3aXNlIChzZWxmaXNoKSByZWNlaXZlcnMgd2lsbCBhbHdheXMgcmVxdWVzdCBpdCBhbmQgc2Vu ZGVycyB3aWxsIGhhdmUgdG8gYnVpbGQgY29tcGxpY2F0ZWQgaGV1cmlzdGljcyB0byBkZXRlY3Qg c3VjaCBiZWhhdmlvciBhbmQgZmFsbCBiYWNrIHRvIGRvaW5nIGRlbGF5ZWQgQUNLcy4gDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFR1ZXhlbg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3 LCAyMDE5IDY6NDEgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWwgPE1pY2hhZWwuU2NoYXJmQGhzLWVz c2xpbmdlbi5kZT4NCkNjOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+ OyBqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51aw0KU3ViamVjdDogUmU6IFt0Y3BtXSBbRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWdvbWV6LXRjcG0tYWNrLXB1bGwtMDAu dHh0XQ0KDQo+IE9uIDE3LiBKdWwgMjAxOSwgYXQgMTQ6NDQsIFNjaGFyZiwgTWljaGFlbCA8TWlj aGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPiB3cm90ZToNCj4gDQo+IElzIG15IHVuZGVyc3Rh bmRpbmcgY29ycmVjdCB0aGF0IHRoaXMgY291bGQgYmUgZm9ybWFsaXplZCBhcyBmb2xsb3dzOg0K PiAgDQo+ICAgQSBUQ1AgTUFZIG5vdCBkZWxheSBBQ0tzIGZvciBkYXRhIHNlZ21lbnRzIHdpdGgg dGhlIFBTSCBmbGFnLg0KSSB0aGluayB0aGlzIGlzIHdoYXQgQ2Fyc3RlbiB3YXMgcmVmZXJyaW5n IHRvLg0KDQpNeSBwb2ludCB3YXM6IElzIHRoaXMgYWxyZWFkeSBkZXBsb3llZD8NCg0KVGhlIHJl YXNvbiBJJ20gYXNraW5nIGlzIHRoYXQgSSBoYXZlIGhlYXJkIHNldmVyYWwgdGltZSB0aGF0IHRo ZSBzZW1hbnRpYyBvZiB0aGUgUFNIIGJpdCBpcyB0byBzZW5kIG91dCBhbiBBQ0sgaW1tZWRpYXRl bHkuIEkgY291bGQgbm90IGZpbmQgdGhlIHNvdXJjZSBvZiB0aGlzIHN0YXRlbWVudC4uLg0KDQpC ZXN0IHJlZ2FyZHMNCk1pY2hhZWwNCj4gIA0KPiBJZiB0aGF0IHdhcyB0aGUgaW50ZW50aW9uLCBJ IGJlbGlldmUgdGhhdCB0aGUgd29yZGluZyBvZiBSRkMgMTEyMiAoYW5kIA0KPiBkcmFmdC1pZXRm LXRjcG0tcmZjNzkzYmlzKSB3b3VsZCBhbGxvdyBzdWNoIGEgcmVjZWl2ZXItc2lkZSBoZXVyaXN0 aWMgDQo+IGFscmVhZHkuIERlbGF5ZWQgQUNLcyBhcmUgYSBTSE9VTEQgaW4gUkZDIDExMjIgYW5k IHRoZSBleGFjdCBsb2dpYyBpcyANCj4gbm90IHNwZWNpZmllZC4gVGh1cywgdGFraW5nIHRoZSBQ U0ggZmxhZyBpbnRvIGFjY291bnQgaW5zaWRlIGEgDQo+IHJlY2VpdmVyLXNpZGUgZGVsYXllZCBB Q0sgaGV1cmlzdGljIG1heSBub3QgZXZlbiBiZSBhIGNoYW5nZSBvZiB0aGUgDQo+IFRDUCBzZW1h bnRpY3PigKYNCj4gIA0KPiBNaWNoYWVsDQo+ICANCj4gIA0KPiBWb246IENhcnN0ZW4gQm9ybWFu bg0KPiBHZXNlbmRldDogTWl0dHdvY2gsIDE3LiBKdWxpIDIwMTkgMDk6NTYNCj4gQW46IFlvc2hp ZnVtaSBOaXNoaWRhDQo+IENjOiBqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51azsgdGNwbUBpZXRm Lm9yZyBFeHRlbnNpb25zDQo+IEJldHJlZmY6IFJlOiBbdGNwbV0gW0Z3ZDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtZ29tZXotdGNwbS1hY2stcHVsbC0wMC50eHRdDQo+ ICANCj4gT24gSnVsIDE3LCAyMDE5LCBhdCAwODo1OCwgWW9zaGlmdW1pIE5pc2hpZGEgPG5zZC5p ZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiAgdXNpbmcgYSByZXNlcnZlZCBmbGFnIGlz IGEgYml0IGV4cGVuc2l2ZQ0KPiAgDQo+IFRoZSBvcHRpb24gY291bGQgc2ltcGx5IHJlZGVmaW5l IGV4aXN0aW5nIFBTSCBhcyBoYXZpbmcgdGhlIEFLUCBzZW1hbnRpY3MuDQo+IChBbmQgcG9zc2li bHkgYWxsIHBhY2tldHMgaGF2aW5nIHdoYXQgdXNlZCB0byBiZSB0aGUgUFNIIHNlbWFudGljcy4p IA0KPiBUaGV5IGFyZSBjbG9zZSBlbm91Z2ggYW55d2F54oCmDQo+ICANCj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 Lg0KPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0Mw MSU3Q3ByYXZiJTQwbWljcm9zDQo+IG9mdC5jb20lN0NiZmRiNGUwMmJhNTI0ZTBjNzA3NDA4ZDcw YWJjNmQxZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QNCj4gMDExZGI0NyU3QzElN0MwJTdD NjM2OTg5Njc2NzMzOTEzNzYzJmFtcDtzZGF0YT1ZeEQwZ1NYVTZvd1FlWGdLcVlwNDYyag0KPiBt UzlpaExySTVSRG9jcXBTOENmUSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiAgDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0 DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lg0KPiBpZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zDQo+IG9m dC5jb20lN0NiZmRiNGUwMmJhNTI0ZTBjNzA3NDA4ZDcwYWJjNmQxZSU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QNCj4gMDExZGI0NyU3QzElN0MwJTdDNjM2OTg5Njc2NzMzOTEzNzYzJmFtcDtz ZGF0YT1ZeEQwZ1NYVTZvd1FlWGdLcVlwNDYyag0KPiBtUzlpaExySTVSRG9jcXBTOENmUSUzRCZh bXA7cmVzZXJ2ZWQ9MA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmcNCmh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p ZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q3By YXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2JmZGI0ZTAyYmE1MjRlMGM3MDc0MDhkNzBhYmM2ZDFlJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4OTY3NjczMzky Mzc1NSZhbXA7c2RhdGE9REx1Y1BjeTR4MDRzWnNsbUY4RWdtOUJpZ2d4Vnh1NWdDdVclMkY4VDcw eVFvJTNEJmFtcDtyZXNlcnZlZD0wDQo= From nobody Wed Jul 17 09:53: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 D66C2120155 for ; Wed, 17 Jul 2019 09:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyEHbQasl6k2 for ; Wed, 17 Jul 2019 09:53:09 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA9D120090 for ; Wed, 17 Jul 2019 09:53:09 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id m202so19072709oig.6 for ; Wed, 17 Jul 2019 09:53:09 -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:content-transfer-encoding; bh=8QjpjN4uBwtryVD6F0fCyeFiSfLkU0/bITNeBKiPowQ=; b=RNjPoKsXHQVohJS8cR8HzgnyqyzMitADuTGxsF8v0JykPQV+ueVRRtOj9gNx7J3JiC z4Vq8t0YSoXXDJmSqMpK9Q30SBQpFlua4DO+X2i+CuM74TGbjFg+hGkIw1ngTuCbHeML 7ZrE4pcNL0WyvcM7drbE/1ucbN0AeLwbqrWgEVx+1LNbhIbl0IDEWquu8ST7oFpjYa4W u6qkXDbBXTQb+rd5edRXi4UCrs4tNwdmeZ8CpU8mNoiYz6hAElkKh0lmdxQFe9vaxFLX 2e/98/mhZMXniRS1qQ2UiKJsGRp0K8TA1rVukybboqJIf4Mn8ALrfxACZaPd3xTFP8ZT DgBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8QjpjN4uBwtryVD6F0fCyeFiSfLkU0/bITNeBKiPowQ=; b=U5yNTBLqQW8sS6S73mRSZ9KbVxhg+aK62IPfWpu/LslI0lg/upkYk6jIm7uVzCXtRK 9rSf0d7iWsqYH/qdqKxZ5V2eJsgXIGC/5wFoSEHmsywkQ40UbIyEOL5NMWLSgmXd/nTu OK0Om98WCC0MlHFAWO895uLy+TdTIm/4GSRw/z281hMbuATPEqm1qpfku5wKuNez81Ss 4wVJS9x1Jw6sLBWLiboEDtFt0L6tq9vfYBcq+LJVZQqgXZ/3Xcug3AfpFWMCC2n5bvLZ rm4nt+cHK2I6543P8Wd0RLPwBRGTVkQd7RfprcRPO+PL94c6vpo1fUtuycJEbRtO9ltf V7zQ== X-Gm-Message-State: APjAAAUFCJu871ZdkA8pwD4LANfiotiiQkFFRfaK1i7pxvcXHiFwaWaJ yxxLacxC/hl37RIeOAOxcEcXUybbaHBT5XFEOqJSCA== X-Google-Smtp-Source: APXvYqy0l7W6SUz+rP5cyOxU9uqN/M5qF52zlqjf4xbugS5FX4/N/MNn88Gt7n7sG+CqDv6+6WGikvM8+K0HYlAOUeg= X-Received: by 2002:aca:bfd4:: with SMTP id p203mr21034481oif.95.1563382388026; Wed, 17 Jul 2019 09:53:08 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> <437D3782-04FB-4D5B-9A38-4BA9DB7C2ECF@lurchi.franken.de> In-Reply-To: From: Neal Cardwell Date: Wed, 17 Jul 2019 12:52:49 -0400 Message-ID: To: Praveen Balasubramanian Cc: Michael Tuexen , "Scharf, Michael" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 16:53:12 -0000 Indeed, Linux also does not generate an immediate ACK upon receiving PSH, and also sets PSH on sendmsg() boundaries. One perspective I am not sure has been discussed in this thread: Those behaviors to generate PSH on sendmsg() boundaries are widely deployed. There are lots of workloads that have a large number of small packets with PSH set (RPC, web, ...). If we change the semantics of PSH to cause an immediate ACK, then we will effectively turn off delayed ACK acks for many RPC and web workloads. This will increase CPU and network loads for such workloads. For some RPC workloads it would double the number of packets sent by servers (the server would now send 1 ACK for every request, and then 1 response packet, instead of piggybacking ACKs and replies). That cost has to be weighed against any latency advantages. Using a new bit would have the advantage of allowing senders to only force more ACKs when their available cwnd or rwnd is low enough that they need an immediate ACK to allow good performance. Just a thought. cheers, neal On Wed, Jul 17, 2019 at 12:21 PM Praveen Balasubramanian wrote: > > Windows TCP on sender side will set PSH at the message boundary i.e. when= it finishes generating sends as part of a posted send() API call or equiva= lent. On receiver side however it does not generated immediate ACK upon rec= eiving PSH. IIRC Linux also sets PSH on sendmsg() boundary. Not sure about = other implementations. If most major implementations are doing this then ge= nerating immediate ACK upon PSH will be an improvement. > > I do think reusing PSH to require eliciting ACKs is a reasonable alternat= ive than using up a reserved bit. One concern with both the original draft = and the PSH proposal is that we'll need clear recommendations on when a rec= eiver will request this. Otherwise (selfish) receivers will always request = it and senders will have to build complicated heuristics to detect such beh= avior and fall back to doing delayed ACKs. > > -----Original Message----- > From: tcpm On Behalf Of Michael Tuexen > Sent: Wednesday, July 17, 2019 6:41 AM > To: Scharf, Michael > Cc: tcpm@ietf.org Extensions ; jon.crowcroft@cl.cam.ac.uk > Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-a= ck-pull-00.txt] > > > On 17. Jul 2019, at 14:44, Scharf, Michael wrote: > > > > Is my understanding correct that this could be formalized as follows: > > > > A TCP MAY not delay ACKs for data segments with the PSH flag. > I think this is what Carsten was referring to. > > My point was: Is this already deployed? > > The reason I'm asking is that I have heard several time that the semantic= of the PSH bit is to send out an ACK immediately. I could not find the sou= rce of this statement... > > Best regards > Michael > > > > If that was the intention, I believe that the wording of RFC 1122 (and > > draft-ietf-tcpm-rfc793bis) would allow such a receiver-side heuristic > > already. Delayed ACKs are a SHOULD in RFC 1122 and the exact logic is > > not specified. Thus, taking the PSH flag into account inside a > > receiver-side delayed ACK heuristic may not even be a change of the > > TCP semantics=E2=80=A6 > > > > Michael > > > > > > Von: Carsten Bormann > > Gesendet: Mittwoch, 17. Juli 2019 09:56 > > An: Yoshifumi Nishida > > Cc: jon.crowcroft@cl.cam.ac.uk; tcpm@ietf.org Extensions > > Betreff: Re: [tcpm] [Fwd: New Version Notification for > > draft-gomez-tcpm-ack-pull-00.txt] > > > > On Jul 17, 2019, at 08:58, Yoshifumi Nishida wrote= : > > > > > > using a reserved flag is a bit expensive > > > > The option could simply redefine existing PSH as having the AKP semanti= cs. > > (And possibly all packets having what used to be the PSH semantics.) > > They are close enough anyway=E2=80=A6 > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= s > > oft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C636989676733913763&sdata=3DYxD0gSXU6owQeXgKqYp462= j > > mS9ihLrI5RDocqpS8CfQ%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= s > > oft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C636989676733913763&sdata=3DYxD0gSXU6owQeXgKqYp462= j > > mS9ihLrI5RDocqpS8CfQ%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.= com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636989676733923755&sdata=3DDLucPcy4x04sZslmF8Egm9BiggxVxu5gCuW= %2F8T70yQo%3D&reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 17 10:32:11 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FACC120833 for ; Wed, 17 Jul 2019 10:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Qk9df7FRfB for ; Wed, 17 Jul 2019 10:32:07 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 D9F3612081A for ; Wed, 17 Jul 2019 10:32:06 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id x4so25694831wrt.6 for ; Wed, 17 Jul 2019 10:32:06 -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:content-transfer-encoding; bh=hGH6eXtAXehFroDCW8VbmTbUW3fm38kxM7vJiUUjtho=; b=MiNTTjdz+UGpEOu19GUaB1NhIbEk0ogNPW8G53wwnJk8IatECQabJiSC3kNXnsTYkT V5AkOhwLLEt3/2uPlOK+aGNrd/aJ1aRpdpvykHAtSmeh1BUQQkOvjY7QScPh3jB5yAJx fxjE0+zkpmvYWmgfAckpeORqsm2ldDnpHELVnkr0TSAAFsPYLdqoasYLN4FHcblbQJbt 7Z1rsblG+Iq/EHoaXiwATA1zxdAgHjXID9fcdNZk7p/rh1YaAc+3CtGZXx9QjB4YYJGZ xhJI/u3/lciM2xsaatRAVL58s/SEg3Rpdqn9Flg5HVwLg0MWl0gAm+Gkd2h4UfoCUNea YALA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hGH6eXtAXehFroDCW8VbmTbUW3fm38kxM7vJiUUjtho=; b=norueFZdU/wv904F1FirtIIkx1GJ969PckWX6tO6/ZBaLv4fripkLn2ST6Ig7QTTVU FZ7yEY0+McTBVhLTv7YOWZ8I/Btcah3YJ/8Yrb4BLD8W+n2GWsBStLtag0KhvZfz7kkM w/gNIocha/qUgo8nXcT6xxL/KzUbjLkbRtZZYTzQeq03+kCoVDWna2kQDXqM714w8IK1 arD4vvxk4vcNNfQlh9wweH3Ygan9s1UaSJwjPgSGRZJ8fE9fBIUtphVoRdd6aY1FUcdU Lq4aGaP3S5ebfGUteCJQ4yfI9kWs6Gvdgdx3DSHSc0it4hNqwa1UBGfVNR098phmBMbo jPqg== X-Gm-Message-State: APjAAAWOxNMILatLALhb58ShfKDle++utOJMKCGqqx6ki/VbGd54vQgb jaSoR0lvtcHUj0WXYsEeQtffxc/XSVJSqrjCizJIOQ== X-Google-Smtp-Source: APXvYqyApao0M0UEGI30Sgv3CbWPBzx7MvkwNYzyBrQU3+4CtFxjyOxe4vUD2gjU+XNB+fXd8iDLbj11uicp1DkM0rA= X-Received: by 2002:adf:cf0d:: with SMTP id o13mr31646558wrj.291.1563384724888; Wed, 17 Jul 2019 10:32:04 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> <437D3782-04FB-4D5B-9A38-4BA9DB7C2ECF@lurchi.franken.de> In-Reply-To: From: Yuchung Cheng Date: Wed, 17 Jul 2019 10:31:27 -0700 Message-ID: To: Neal Cardwell Cc: Praveen Balasubramanian , Michael Tuexen , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 17:32:10 -0000 On Wed, Jul 17, 2019 at 9:53 AM Neal Cardwell wrote: > > Indeed, Linux also does not generate an immediate ACK upon receiving > PSH, and also sets PSH on sendmsg() boundaries. > > One perspective I am not sure has been discussed in this thread: Those > behaviors to generate PSH on sendmsg() boundaries are widely deployed. > There are lots of workloads that have a large number of small packets > with PSH set (RPC, web, ...). If we change the semantics of PSH to > cause an immediate ACK, then we will effectively turn off delayed ACK > acks for many RPC and web workloads. This will increase CPU and > network loads for such workloads. For some RPC workloads it would > double the number of packets sent by servers (the server would now > send 1 ACK for every request, and then 1 response packet, instead of > piggybacking ACKs and replies). That cost has to be weighed against > any latency advantages. +1 on similar concern. It's worth noting a recent issue we discovered while testing BBRv2 which uses DCTCP-ECN protocol. The Linux delayed-ACK implementation does no= t always ACK every other data packet. It may delay sending an ACK until the available receive window has at least matched or grown beyond to the previous window announced. Under heavy (data-path) network congestion, a slower receiver could frequently delay the ACKs when most data packets have CE marks. This ACK delay causes the sender to further slow down in additional to the CE events being returned since both BBRv2 and DCTCP are still ACK-clocked. The large RPC is received more slowly (compared to a policy that acks immediately every other packet). The application goodput is zero until the RPC is finally completely received. This cause much longer RPC tail latency visible to the users. So this design causes all RPCs to progress more slowly in parallel, vs fewer RPCs to progress more quickly in serial. Arguably this is an implementation / optimization issue, but I think it's very relevant to this thread. Neal may talk about that in the upcoming ICCRG bbr.v2 talk. > > Using a new bit would have the advantage of allowing senders to only > force more ACKs when their available cwnd or rwnd is low enough that > they need an immediate ACK to allow good performance. > > Just a thought. > > cheers, > neal > > > > On Wed, Jul 17, 2019 at 12:21 PM Praveen Balasubramanian > wrote: > > > > Windows TCP on sender side will set PSH at the message boundary i.e. wh= en it finishes generating sends as part of a posted send() API call or equi= valent. On receiver side however it does not generated immediate ACK upon r= eceiving PSH. IIRC Linux also sets PSH on sendmsg() boundary. Not sure abou= t other implementations. If most major implementations are doing this then = generating immediate ACK upon PSH will be an improvement. > > > > I do think reusing PSH to require eliciting ACKs is a reasonable altern= ative than using up a reserved bit. One concern with both the original draf= t and the PSH proposal is that we'll need clear recommendations on when a r= eceiver will request this. Otherwise (selfish) receivers will always reques= t it and senders will have to build complicated heuristics to detect such b= ehavior and fall back to doing delayed ACKs. > > > > -----Original Message----- > > From: tcpm On Behalf Of Michael Tuexen > > Sent: Wednesday, July 17, 2019 6:41 AM > > To: Scharf, Michael > > Cc: tcpm@ietf.org Extensions ; jon.crowcroft@cl.cam.ac.u= k > > Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm= -ack-pull-00.txt] > > > > > On 17. Jul 2019, at 14:44, Scharf, Michael wrote: > > > > > > Is my understanding correct that this could be formalized as follows: > > > > > > A TCP MAY not delay ACKs for data segments with the PSH flag. > > I think this is what Carsten was referring to. > > > > My point was: Is this already deployed? > > > > The reason I'm asking is that I have heard several time that the semant= ic of the PSH bit is to send out an ACK immediately. I could not find the s= ource of this statement... > > > > Best regards > > Michael > > > > > > If that was the intention, I believe that the wording of RFC 1122 (an= d > > > draft-ietf-tcpm-rfc793bis) would allow such a receiver-side heuristic > > > already. Delayed ACKs are a SHOULD in RFC 1122 and the exact logic is > > > not specified. Thus, taking the PSH flag into account inside a > > > receiver-side delayed ACK heuristic may not even be a change of the > > > TCP semantics=E2=80=A6 > > > > > > Michael > > > > > > > > > Von: Carsten Bormann > > > Gesendet: Mittwoch, 17. Juli 2019 09:56 > > > An: Yoshifumi Nishida > > > Cc: jon.crowcroft@cl.cam.ac.uk; tcpm@ietf.org Extensions > > > Betreff: Re: [tcpm] [Fwd: New Version Notification for > > > draft-gomez-tcpm-ack-pull-00.txt] > > > > > > On Jul 17, 2019, at 08:58, Yoshifumi Nishida wro= te: > > > > > > > > using a reserved flag is a bit expensive > > > > > > The option could simply redefine existing PSH as having the AKP seman= tics. > > > (And possibly all packets having what used to be the PSH semantics.) > > > They are close enough anyway=E2=80=A6 > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40mic= ros > > > oft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7c= d > > > 011db47%7C1%7C0%7C636989676733913763&sdata=3DYxD0gSXU6owQeXgKqYp4= 62j > > > mS9ihLrI5RDocqpS8CfQ%3D&reserved=3D0 > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40mic= ros > > > oft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7c= d > > > 011db47%7C1%7C0%7C636989676733913763&sdata=3DYxD0gSXU6owQeXgKqYp4= 62j > > > mS9ihLrI5RDocqpS8CfQ%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsof= t.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C636989676733923755&sdata=3DDLucPcy4x04sZslmF8Egm9BiggxVxu5gC= uW%2F8T70yQo%3D&reserved=3D0 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 19 02:42:28 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C86412017D for ; Fri, 19 Jul 2019 02:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8k-AOUovYPf for ; Fri, 19 Jul 2019 02:42:25 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63356120176 for ; Fri, 19 Jul 2019 02:42:25 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x6J9fqx4040752; Fri, 19 Jul 2019 11:41:52 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D712E1D53C1; Fri, 19 Jul 2019 11:41:51 +0200 (CEST) Received: from 90.213.234.54 by webmail.entel.upc.edu with HTTP; Fri, 19 Jul 2019 11:41:52 +0200 Message-ID: <61b6befca142b6743121c6175d9a4061.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <6EC6417807D9754DA64F3087E2E2E03E2D3B2F41@rznt8114.rznt.rzdir.fht-esslingen.de> <437D3782-04FB-4D5B-9A38-4BA9DB7C2ECF@lurchi.franken.de> Date: Fri, 19 Jul 2019 11:41:52 +0200 From: "Carles Gomez Montenegro" To: "Yuchung Cheng" Cc: "Neal Cardwell" , "Praveen Balasubramanian" , "Michael Tuexen" , "tcpm@ietf.org Extensions" , "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 violet X-Virus-Status: Clean X-Greylist: Delayed for 00:47:27 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Fri, 19 Jul 2019 11:41:53 +0200 (CEST) Archived-At: Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 09:42:28 -0000 Hello everyone, Thanks a lot for all the suggestions and feedback provided. Assessing the pros and cons of the alternatives on the table (in the light of, but perhaps not limited to, the considerations already expressed on the list) will be an important next step. I plan to include a summary of the discussion so far in my presentation in Montreal. Looking forward to continuing the discussion, Carles > On Wed, Jul 17, 2019 at 9:53 AM Neal Cardwell > wrote: >> >> Indeed, Linux also does not generate an immediate ACK upon receiving >> PSH, and also sets PSH on sendmsg() boundaries. >> >> One perspective I am not sure has been discussed in this thread: Those >> behaviors to generate PSH on sendmsg() boundaries are widely deployed. >> There are lots of workloads that have a large number of small packets >> with PSH set (RPC, web, ...). If we change the semantics of PSH to >> cause an immediate ACK, then we will effectively turn off delayed ACK >> acks for many RPC and web workloads. This will increase CPU and >> network loads for such workloads. For some RPC workloads it would >> double the number of packets sent by servers (the server would now >> send 1 ACK for every request, and then 1 response packet, instead of >> piggybacking ACKs and replies). That cost has to be weighed against >> any latency advantages. > +1 on similar concern. > > It's worth noting a recent issue we discovered while testing BBRv2 > which uses DCTCP-ECN protocol. The Linux delayed-ACK implementation does > not > always ACK every other data packet. It may delay sending an ACK until > the available receive window has at least matched or grown beyond to > the previous window announced. Under heavy (data-path) network > congestion, a slower receiver could frequently delay the ACKs when > most data packets have CE marks. > > This ACK delay causes the sender to further slow down in additional to > the CE events being returned since both BBRv2 and DCTCP are still > ACK-clocked. The large RPC is received more slowly (compared to a > policy that acks immediately every other packet). The application > goodput is zero until the RPC is finally completely received. This > cause much longer RPC tail latency visible to the users. So this > design causes all RPCs to progress more slowly in parallel, vs fewer > RPCs to progress more quickly in serial. > > Arguably this is an implementation / optimization issue, but I think > it's very relevant to this thread. Neal may talk about that in the > upcoming ICCRG bbr.v2 talk. > > >> >> Using a new bit would have the advantage of allowing senders to only >> force more ACKs when their available cwnd or rwnd is low enough that >> they need an immediate ACK to allow good performance. >> >> Just a thought. >> >> cheers, >> neal >> >> >> >> On Wed, Jul 17, 2019 at 12:21 PM Praveen Balasubramanian >> wrote: >> > >> > Windows TCP on sender side will set PSH at the message boundary i.e. >> when it finishes generating sends as part of a posted send() API call >> or equivalent. On receiver side however it does not generated >> immediate ACK upon receiving PSH. IIRC Linux also sets PSH on >> sendmsg() boundary. Not sure about other implementations. If most >> major implementations are doing this then generating immediate ACK >> upon PSH will be an improvement. >> > >> > I do think reusing PSH to require eliciting ACKs is a reasonable >> alternative than using up a reserved bit. One concern with both the >> original draft and the PSH proposal is that we'll need clear >> recommendations on when a receiver will request this. Otherwise >> (selfish) receivers will always request it and senders will have to >> build complicated heuristics to detect such behavior and fall back to >> doing delayed ACKs. >> > >> > -----Original Message----- >> > From: tcpm On Behalf Of Michael Tuexen >> > Sent: Wednesday, July 17, 2019 6:41 AM >> > To: Scharf, Michael >> > Cc: tcpm@ietf.org Extensions ; >> jon.crowcroft@cl.cam.ac.uk >> > Subject: Re: [tcpm] [Fwd: New Version Notification for >> draft-gomez-tcpm-ack-pull-00.txt] >> > >> > > On 17. Jul 2019, at 14:44, Scharf, Michael >> wrote: >> > > >> > > Is my understanding correct that this could be formalized as >> follows: >> > > >> > > A TCP MAY not delay ACKs for data segments with the PSH flag. >> > I think this is what Carsten was referring to. >> > >> > My point was: Is this already deployed? >> > >> > The reason I'm asking is that I have heard several time that the >> semantic of the PSH bit is to send out an ACK immediately. I could not >> find the source of this statement... >> > >> > Best regards >> > Michael >> > > >> > > If that was the intention, I believe that the wording of RFC 1122 >> (and >> > > draft-ietf-tcpm-rfc793bis) would allow such a receiver-side >> heuristic >> > > already. Delayed ACKs are a SHOULD in RFC 1122 and the exact logic >> is >> > > not specified. Thus, taking the PSH flag into account inside a >> > > receiver-side delayed ACK heuristic may not even be a change of the >> > > TCP semantics… >> > > >> > > Michael >> > > >> > > >> > > Von: Carsten Bormann >> > > Gesendet: Mittwoch, 17. Juli 2019 09:56 >> > > An: Yoshifumi Nishida >> > > Cc: jon.crowcroft@cl.cam.ac.uk; tcpm@ietf.org Extensions >> > > Betreff: Re: [tcpm] [Fwd: New Version Notification for >> > > draft-gomez-tcpm-ack-pull-00.txt] >> > > >> > > On Jul 17, 2019, at 08:58, Yoshifumi Nishida >> wrote: >> > > > >> > > > using a reserved flag is a bit expensive >> > > >> > > The option could simply redefine existing PSH as having the AKP >> semantics. >> > > (And possibly all packets having what used to be the PSH semantics.) >> > > They are close enough anyway… >> > > >> > > Grüße, Carsten From nobody Sun Jul 21 07:28: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 CD87A12013D for ; Sun, 21 Jul 2019 07:27:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wSmQFTRnHMa for ; Sun, 21 Jul 2019 07:27: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 C6D0C120159 for ; Sun, 21 Jul 2019 07:27:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0DEFB25A12; Sun, 21 Jul 2019 16:27:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563719274; bh=SFlqJqipyYGx/6EnGozRnMRmz3iRdNEUYQBZHpLX9VA=; h=From:To:CC:Subject:Date:From; b=YobmE224OoeqvKIpzhuVEfh2uophPHkXDHct7br5NDFcQGx7Hbl9rCq7VfSUvPQFv o5pGF066VJ0ljXkvfX7H2fNNIqVsOV2a2HS/hbrdniQML1ydQ0vKZAOvwn7H9dKB69 iVqu0bsVpuNGEuI/IYFj/fwqI15cdjEB4K1lMjDQ= 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 qNXXAtzAoeqO; Sun, 21 Jul 2019 16:27:53 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 21 Jul 2019 16:27:53 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 21 Jul 2019 16:27:53 +0200 From: "Scharf, Michael" To: Wesley Eddy CC: "tcpm@ietf.org Extensions" Thread-Topic: Some comments on draft-ietf-tcpm-rfc793bis Thread-Index: AdU/y0QHaugjFL0hTAywGUTGNy0axg== Date: Sun, 21 Jul 2019 14:27:52 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@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] Some comments on draft-ietf-tcpm-rfc793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 21 Jul 2019 14:28:06 -0000 Hi Wes, I went through draft-ietf-tcpm-rfc793bis-13 in the airplane. Here are some = minor observations, basically editorial: * Section 3.6 explains why the document uses the terms "security level" and= "compartment" and in what specific context this may matter. However, these= terms are used earlier in the document. I believe it could be useful to ad= d a forward reference earlier in the document to Section 3.6 (and Appendix = A.1), in particular for implementers who do not implement this. For instanc= e, maybe one could add a forward reference in Section 3.2 Terminology, wher= e these terms seem to be used for the first time. * Section 3.7.4 defines the Nagle algorithm. The exact same definition is r= epeated in 3.8.6.2.1 (except for a reference). It is not clear to me why th= e definition must be repeated in 3.8.6.2.1.=20 * Section 3.8 states: "The notation used is similar to most procedure or fu= nction calls in high level languages, but this usage is not meant to rule o= ut trap type service calls (e.g., SVCs, UUOs, EMTs)." The acronyms SVCs, UU= Os and EMTs have not been expanded in RFC 793. I wonder if I am really the = only person who is not really familiar with those acronyms? In any case, I = believe that "(e.g., SVCs, UUOs, EMTs)" could just be removed from the docu= ment. * I wonder if Erratas should added to the references, in particular if ther= e is an explicit reference to their content. An example would be Errata ID = 4772, which is cited like an RFC. Probably this is a formal question to the= IESG or the RFC editor... Anyway, I don't know the answer, but it is somet= hing we could probably try to find out. * The Glossary includes terms that are not used in the document. I wonder i= f we really need to keep entries that maybe mattered in the original RFC 79= 3 only. Actually, I don't even understand why RFC 793 included some entries= (e.g., "1822", "leader"), as they do not even show up in the document body= of RFC 793. Finally, I want to note that the document by and large looks good to me and= I really encourage others to read it, too. Thanks Michael From nobody Sun Jul 21 10:27:42 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44C120155 for ; Sun, 21 Jul 2019 10:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MmxanQZ7xJO for ; Sun, 21 Jul 2019 10:27:38 -0700 (PDT) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 3E764120131 for ; Sun, 21 Jul 2019 10:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1563730056; bh=ifVRryb0YwGINp8MxY6twc/0U+A8N5Ydg17DrzIgtEY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kd/1psD14m5uqwtiMDzxPiWT/ULNfClcdxsoyoEPbsbb/KVvnOOPo/uVIy60dF9mAmOgXc05uOZihUP4PGAspQ0i4PEd2AHSVZcKdAIR1Hxs17aDkI0w2GUhQnHT+DLkhg2VIa2wF8N22AG1+p1qIQMT6HScjM3C9h5tX50IzdgxWnF9KLA6ygevb2IVEkjoYC/bKQCO8i1zM9a9baRr2OwmVplgTu9D22RBMjL3deT0BJrisuOjDU6ahrCEPZZNp5MdUYxBkXHvFeMei7fQKHGZr3KWBJSfF7HErd1U5QkAEZ+5RmblcRj1BJ6kFOm59mBEE8JN+5woTUVdnuYs/g== X-YMail-OSG: Xr9v07EVM1mP.te1mKAQvoGTiCMU0XY7yl_jIbBnef0KGtCuzrvTYK5Y1LPJ5bJ TV790GHyQsjT8VeRmD7GCWsJWYDuI1JgfmIaJogmubc6MGpSYMFxdVC9NgbfxMvJu8hjaWYck9zz 2aPWCp9NSGWkcbmJOX1CsFsGiRDXXDU2dLlOUETW6YU7QLPPmwh6avUknd0QnNx2Afp1jKr9t_FO 1VMtoTBkkytn.tkiGgprSZFg.ERbE2qeNO0T8n1XO45SWVGWr1W3J.3eGJAMafn5Ul7q7tejMmMt mcvRDMBK7gv.9Y3DuHBs1F_B3BVhqzNshFiQNEo9rwu405jAe3JL7RpYvER.VRYtgJOhHgloYOul mAItLmGGo3DLC6hd6pfmXfuEvgfJuGz8iMy4_LnYmh_PVkoklGizZYAZdnyTLYpGrWnMwmcQtN31 rnXzqMDs5mL5VFSaJxi9vtmJQCAE158wj.1XIlmxlO.siCsKdyY0lQfA2d89wk3MYfm6h0MfFnMN yFWkWQPKGTUxVpwc2AoR4BH5rPvu.HzeIjm6jwSqu0fH_yaNdwwpZ7b6BopRbHo8AISdzibJE7Nc 0oOAu5xSX0TqHndtMF5dfvfuYaqQCnobEHwRjFjPHVRHkCQd5nKz3OaaYG9tTaZ.YxCIQWqGAvVP x3iUrxQXXyADGwLnQ.HwJCeV3K9I9_EPerM.vmIBAYFGCSC.QpXY3NX1UAdi2x_lql2v9ve9_RUf dwKjdancyrNfGR.5YkzfrPdfo6LJ14r5qf4k9btpdmoB3wkwBahN78UmX6XkG.mDWhI5BqNn2AzM cXgqgNMF37lBkvW1882BK_LJEEqGKbnAsK7Qgt0bjNUeFQZJyFWBOwUHd3IDF2HX6VtJzZX3xI0n 5SbeSLp7OgZcLCOIGUStF5wAHVUHZKj1rnvwxzbmH8EHB.lZR_7Cc3_mWxUTqyQ3xYKFRORpBP1P iMyIRovA.RsIU6Pl4QPkQO9gHWZE6i3K.jeSKj6p8yATgyX3RykPFwpFwWHMbxPfehDGTH4QI_h5 icfIzVg2y1cHWlcThyf0ksFRTdqghdNxG2gR_CaKi1wNp6vwhN4kyYVEo8OV5JvpBztL5A8p.BlF yGTYUxUSfTE0U6iwiS.Yp7sHYEld8g7V0tk9yAEymCYaTfkprqYKrpm7C8ckitChiaP57Yx1mFSx RIlTpnCFE8On3yta_4W42cMKQu8LgDYvXgSKKZPB1bOVEyHc6IVgnhu.gaiMCzMgfJLEXN.Mj5xB w.5WsYFG_C09s8KsLCA60tTLoce4qb8LAO3QibSG3zvgwUig579eA6jfkbJ0eNgLEtPkTeNF7kEx okw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sun, 21 Jul 2019 17:27:36 +0000 Date: Sun, 21 Jul 2019 17:27:09 +0000 (UTC) From: "alex.burr@ealdwulf.org.uk" Reply-To: "alex.burr@ealdwulf.org.uk" To: Jonathan Morton , "\"Rodney W. Grimes\"" Cc: "\"tcpm@ietf.org\"" , "\"tsvwg@ietf.org\"" Message-ID: <1468777263.2671021.1563730029999@mail.yahoo.com> In-Reply-To: <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2671020_2127187413.1563730029998" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 17:27:40 -0000 ------=_Part_2671020_2127187413.1563730029998 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rod, Jonathan, =C2=A0I could be wrong, but it appears to me that this draft does not merel= y not make use of draft-ietf-tcpm-accurate-ecn,it's incompatible with it. I= s this the case? Of course SCE is a competitor to L4S, but the accurate-ecn= draft also asserts that there are other uses for accurate-ecn besides L4S = (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could s= tate your position on those other uses, for the record.=20 Also, presumably it is incorrect that "There are no IANA considerations", s= ince IANA would need to change the NS bit. Regards, Alex Rodney W. Grimes" wrote: > > Rod, > >=20 > > This draft appears to be focused on obtaining a TCP header bit for SCE. >=20 > Yes, that is correct. >=20 > > As an alternative to this single-bit proposal, please take a look at dr= aft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcp= m-accurate-ecn/) and consider how that functionality might (or might not) b= e usable with SCE.=20 >=20 > I specifically did not do what Accurate Ecn attempts as that requires > a TCP option negotiation at connection establishment to negotiate the > overloading of other TCP header bits.=C2=A0 SCE only needs 1 new bit, and > does not alter the behavior of any current bits. >=20 > This proposal (TCPSCE) does not in any way effect the current use of > any of the other bits, and use of the NS bit should be fully backwards > compatible and ignored by pre SCE implementations and does not require > a TCP option negotiation. >=20 > I have to get additional data but have been lead to understand that > adding a tcp option and doing that negotiation is going to cause a > great deal of pain in the ability to deploy accurate ecn as it is > currently designed due to middle box inspection and handling. >=20 > Regards, > Rod >=20 > > Thanks, --David > >=20 ------=_Part_2671020_2127187413.1563730029998 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rod, Jonathan,
 I could be wrong, but it appears to me that this draft does not m= erely not make use of draft-ietf-tcpm-accurate-ecn,
it's incompatible with it. Is this = the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft = also asserts that there are other uses for accurate-ecn besides L4S (DCTCP = and ConEx) . It would be useful if you (the TCPSCE authors ) could state yo= ur position on those other uses, for the record.

Also, presumably it is incorrect that "There are no IANA = considerations", since IANA would need to change the NS bit.
=
Regards,

Alex

Rodney W. Grimes" <freebsd@gndrsh.dns= mgr.net> wrote:

> > Rod,
> >
> > This = draft appears to be focused on obtaining a TCP header bit for SCE.
> =
> Yes, that is correct.
>
> > As an alternative to t= his single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn= (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consi= der how that functionality might (or might not) be usable with SCE.
>= ;
> I specifically did not do what Accurate Ecn attempts as that req= uires
> a TCP option negotiation at connection establishment to negot= iate the
> overloading of other TCP header bits.  SCE only needs= 1 new bit, and
> does not alter the behavior of any current bits.>
> This proposal (TCPSCE) does not in any way effect the curren= t use of
> any of the other bits, and use of the NS bit should be ful= ly backwards
> compatible and ignored by pre SCE implementations and = does not require
> a TCP option negotiation.
>
> I have = to get additional data but have been lead to understand that
> adding= a tcp option and doing that negotiation is going to cause a
> great = deal of pain in the ability to deploy accurate ecn as it is
> current= ly designed due to middle box inspection and handling.
>
> Reg= ards,
> Rod
>
> > Thanks, --David
> >



------=_Part_2671020_2127187413.1563730029998-- From nobody Sun Jul 21 10:32:40 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B6D1201DA; Sun, 21 Jul 2019 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvj2OizrXVQ5; Sun, 21 Jul 2019 10:32:23 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 1ABCE120199; Sun, 21 Jul 2019 10:32:23 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id r6so31955623qtt.0; Sun, 21 Jul 2019 10:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h37YrM4UXxZ/u+hm5HlNIVf6omEmKBf0ylz1+dXbkC4=; b=UQqA2Sbx3gZpcC0ApYzxMI4egasjPuyMd/D4IHYpJDOBeKA8ul0P8b/qx3ekaIeE43 MZukkdLaUKWgbnvTeO0IzzKN+fBhd2tuI269KVt/Bqv17TOFQMiAdEHsOmDraMQPMm5Y zuCzVBsHfBKEiyxtamHMSrtiXuyov7IAI4zTO79hmffxuVbQAyky8CWGihkhejzsfmCh iRmu5nanGc34X4mHEibdd3wWAdZAMH/5CG2HJvGzMZ7+btDhBldtc5cWMvQHqmMkTsUe EbfkaMvkpDvs7n05kJyYOVyueHjFTLSkjmlsnGjbypXaeWviYc7rNy5WzZLQ/RXWDDAr VWBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h37YrM4UXxZ/u+hm5HlNIVf6omEmKBf0ylz1+dXbkC4=; b=fr7pmQzEXVLw1e4/m+nY9CMnE6e0b8PwDPdq0oi7VeFvzFSZamcD1aYURs1N4GQ6YC se43iT5cXbJAnRs6W/7jmcC3GIRBx5ujumq3M+0v9Og6dpYG8Be9OGBDeYEmz4d8JgOO 5onm2omCSaICstLxvs3iVfKEi/aL4AxK/KU2FVve+iE9Alxl8lIwBFwtkfqLLKjnI8oU +f9VU3O9AGe3aRLJoV9RP7MzXp0sb6kbJ7lPSWQqERfF6WwZzrnYbzF2XBybNi3cPSwb yg8ipsMaD+Czqu28PHQRUrH2J9n4fcNL560+Z/q+cN0+7XxfA7pcQ66kwe8p4q/RN8Gk qNTA== X-Gm-Message-State: APjAAAV5QzTppNSCeF9r4bNXqPPoYI5S4bTDHyauEjx0djwrI3YSFmm/ rhMnoKvqFclOBXUwh4KUTh4= X-Google-Smtp-Source: APXvYqwawL3xlzZvWs4TVV9B+M9V0HYtVz5L/PEcsQP2eWLHtWi07ZVn4mEXdeBZK1a+xAn+yjdMMA== X-Received: by 2002:ac8:1e8a:: with SMTP id c10mr44787987qtm.45.1563730342259; Sun, 21 Jul 2019 10:32:22 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:c6f:1909:360d:46a2? ([2001:67c:370:128:c6f:1909:360d:46a2]) by smtp.gmail.com with ESMTPSA id r189sm17694387qkc.60.2019.07.21.10.32.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 10:32:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <1468777263.2671021.1563730029999@mail.yahoo.com> Date: Sun, 21 Jul 2019 13:32:15 -0400 Cc: "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1762E7D4-DD53-4810-ADA9-3FDE6B270ACF@gmail.com> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> To: "alex.burr@ealdwulf.org.uk" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 17:32:31 -0000 > On 21 Jul, 2019, at 1:27 pm, alex.burr@ealdwulf.org.uk wrote: >=20 > I could be wrong, but it appears to me that this draft does not merely = not make use of draft-ietf-tcpm-accurate-ecn, it's incompatible with it. = Is this the case? Of course SCE is a competitor to L4S, but the = accurate-ecn draft also asserts that there are other uses for = accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you = (the TCPSCE authors ) could state your position on those other uses, for = the record.=20 AccECN goes through a negotiation on the SYN and SYN-ACK phases before = its use of NS/CWR/ECE bits is changed. This is very important. SCE's = revised use of the NS bit comes into play only after that negotiation = has established (to an AccECN-aware endpoint) that Classic ECN is in = use. This is actually similar to the old Nonce Sum spec, which the = AccECN draft still seems to believe is current. > Also, presumably it is incorrect that "There are no IANA = considerations", since IANA would need to change the NS bit. This may be true, and is another thing I'll work on with Rod when we = have a moment. - Jonathan Morton= From nobody Sun Jul 21 12:52: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 8E8141200B8 for ; Sun, 21 Jul 2019 12:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYKOX6i9B9nz for ; Sun, 21 Jul 2019 12:52:40 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 27C43120135 for ; Sun, 21 Jul 2019 12:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1563738758; bh=6GgDC7lnsZreHMVtzCb2k4aTv/bgxaLc5d8VpdXPKIs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dj1VUdCLEntQ9c9CNTc62L3WgY0ZdsiXQMHhsu75F6f6b3r8bKsqYt6tySaiq0TXSn3XMb606sUKa2V4M38ZrjAt/kjQSGzLIYPEUBdFKmAyh6TUep0pvSRoyTy9sVwETfxzOSV+/3AqvWS5GaFEUtZA+M2V6GOVtuLGt1kCLF9b/snlV0KimALUWgmrETyzRfVUGpFZY802REvw0M2g+GRZ5Yd5bK7azFf6CHWl4DBZxo1JxC+MT49LPL8/nZyjGKEAAPj+iAGIv+uhpVxRyhAM+YK9veR/NDgD9gvonO3VmLyZHQUQj+8zqNfzYlOFZ3lC0kvNRLsWHOE6BZXq6g== X-YMail-OSG: oXItRYwVM1kwbG.UXUwJ.NQkmOoeKx0kjMh0qxQlOTQ2NhC88_LwGOePMMvAD1f QWbCdh9hVlsjnx8HSON43BNJuDQesJj9Fl0sdNuW.GDN55BZyFso0_lyKZ.3X498pZ2OQ_yiE0bx qDBPIueACdPKc_U.3LDlvUrVdZxrIYmS5Uruo0J8QoD7Ty26fuMb0t3BElz6e0Wk_VjOEroIVbe1 .xj7a1pbb3FUAF16hYSfBGl1NJ1VMtfWG3KJA2Nzelox2F1TUXggI5EvdKbgrNhgUQie1Ryx_gZx HlYogyvDfrHNHaR6dHfBPF21FcAoKaetHCrnbDs7.83rhUWGnNKhaspIs9ITGcxXxR6zp_ADUtvU R6zAYaSLjvodXVFHGBFbF0d7lAilZmAWYQJUdMiyliqG.edHM4NKM9bpGI4vdJHdUujcnJqPbXKC UwwQdbboIpsMpuo3ZJjYfUL3d2EZL7_mbTA4KOXXEt5uPH6TMGSkmC5X2b5oYRMzdRMAfhcl35NX P5ixboog8Qyvc.WbQ1nOqrUQPsmb7YgAMfYou3XllUD1q5HqK45.jO3ZailUutzGRzXeJXEA8iFK 6DTJyNvS4AmM0UZxyOTB1BV3VBKcQADvyBvaGHSxYrUyEa8Q1HVWxBPb8AzhuUzwK6S85yd1y_mr _YxtF5_fQp5tK1b_u.HzbltsIb8xxfEeyM8Zc1HEUa24uOHDy0AgiTLtkcM1XAHt423HBQET9Iu1 JFy2_kivWKdEHqP5iHm19YgGB6mw2rzzudJnDc5pM0xO8og5GZ5GN96Cg.ue3m_vqwJRATcVXdm0 IorSjf3H2rWusmy425OE2H1eCpP7nH7ZCGm5zDHWdsa3lANB9zRrI.erteANbUcLiu6277CO7BL2 dlngGFpaUX_geJ3m9_g6G1BLOVHNN3PBRR_9F5l_xMbkhLpEfGThqT6hcpij..U1Top680I6o4b. N4ZnBYuWxtZT.lReLNEo5D0THgNq.albp9yvhup4LqceaeNSCNgVTJBxe.W1LecoMveTOAY6TsvD _eSah2KYqTe8pa0lbCXIqje2TjxYxB7jEtDaS.2hPAyGZsl6ufmSahBCzHFXYK6MkG_.BxZQxgnn eMUTRJ9oGrbZVz2Sve412VtnaDdF8HO9a8PKneM_bcMSqD86TkD2RCaidEXekVpK8d_pf4DOOJJR 1leUM7eZxLVJPPN08RA8zJ_3AIktCehm_x0hUHoQmuIcraIteS24rwPtkwk.J02XpA2chWSZnHJZ 2AXuBB0WAl474BbbG Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sun, 21 Jul 2019 19:52:38 +0000 Date: Sun, 21 Jul 2019 19:52:37 +0000 (UTC) From: "alex.burr@ealdwulf.org.uk" Reply-To: "alex.burr@ealdwulf.org.uk" To: Jonathan Morton Cc: "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" Message-ID: <427853763.2687825.1563738757916@mail.yahoo.com> In-Reply-To: <1762E7D4-DD53-4810-ADA9-3FDE6B270ACF@gmail.com> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> <1762E7D4-DD53-4810-ADA9-3FDE6B270ACF@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2687824_1366379724.1563738757915" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 19:52:42 -0000 ------=_Part_2687824_1366379724.1563738757915 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, July 21, 2019, 6:48:49 PM GMT+1, Jonathan Morton wrote: > AccECN goes through a negotiation on the SYN and SYN-ACK phases before it= s use of > NS/CWR/ECE bits is changed.=C2=A0 This is very important.=C2=A0 SCE's rev= ised use of the NS bit > comes into play only after that negotiation has established (to an > AccECN-aware endpoint) that Classic ECN is in use.=C2=A0 This is actually= similar to the > old Nonce Sum spec, which the AccECN draft still seems to believe is curr= ent. Ah, right. For some reason I was assuming that to be compatible with AccECN= , you'd need to use one of the NS=3D1 codepoints of NS/CWR/ECE to signal yo= ur use of NS. But of course, you don't need to do that, so it is compatible= as it stands. Thanks! Alex ------=_Part_2687824_1366379724.1563738757915 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On Sunday, July 21, 2019, 6:48:49 PM GMT+1, Jonathan Morton <chromatix99@gmail.com> wrote:

> AccECN goes through a negotiation on the SYN and SYN-ACK phases before its use of
> NS/CWR/ECE bits is changed.  This is very important.  SCE's revised use of the NS bit
> comes into play only after that negotiation has established (to an
> AccECN-aware endpoint) that Classic ECN is in use.  This is actually similar to the
> old Nonce Sum spec, which the AccECN draft still seems to believe is current.

Ah, right. For some reason I was assuming that to be compatible with AccECN, you'd need to use one of the NS=1 codepoints of NS/CWR/ECE to signal your use of NS. But of course, you don't need to do that, so it is compatible as it stands. Thanks!

Alex


------=_Part_2687824_1366379724.1563738757915-- From nobody Sun Jul 21 18:01: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 3A86F12007A; Sun, 21 Jul 2019 18:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DKH5Nd8LxUI; Sun, 21 Jul 2019 18:01:34 -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 736F9120075; Sun, 21 Jul 2019 18:01:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7B3AE25A12; Mon, 22 Jul 2019 03:01:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563757292; bh=RXhTIwexMBsOfjzRX3ZtFsniLdp/RX4AI94SFVulukA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Hxx/ls7kKeXQy0OgE/Dajn4gUr5V1gOHQihuvf4kTlXqNHqOLU5302mVtuST45hSO EuSeBBCcT1jJpQpNwqXQ1CKkobCBPFhVAzuL4ZTb8SCLEFDjJXXGw7iTsuR/IJ1w8E 9ZzGsW8eyAzLw7MGHPtI4Ow++aKFEoKbtSzztIbk= 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 sd-o1qiVtQAS; Mon, 22 Jul 2019 03:01:31 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 22 Jul 2019 03:01:31 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 22 Jul 2019 03:01:31 +0200 From: "Scharf, Michael" To: "alex.burr@ealdwulf.org.uk" , Jonathan Morton , "\"Rodney W. Grimes\"" CC: "\"tcpm@ietf.org\"" , "\"tsvwg@ietf.org\"" Thread-Topic: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt Thread-Index: AQHVP+mkbmQ55M6iAkCskFHm+5fteqbVyiBQ Date: Mon, 22 Jul 2019 01:01:30 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3C0A43@rznt8114.rznt.rzdir.fht-esslingen.de> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> In-Reply-To: <1468777263.2671021.1563730029999@mail.yahoo.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_6EC6417807D9754DA64F3087E2E2E03E2D3C0A43rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 01:01:37 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3C0A43rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgYWxzbyBkcmFmdC1pZXRmLXRjcG0tZ2VuZXJh bGl6ZWQtZWNuLTA0LCB3aGljaCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIGhhcyBhIGRlcGVuZGVu Y3kgb24gZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbiBmb3IgY2VydGFpbiBjYXNlcy4NCg0K SnVzdCB0byBzdGF0ZSB0aGUgb2J2aW91czogVGhlc2UgZG9jdW1lbnRzIGFyZSB3b3JrIGluIHBy b2dyZXNzIGluIFRDUE0gYW5kIFRDUE0gYWx3YXlzIHdlbGNvbWVzIGZlZWRiYWNrLg0KDQpNaWNo YWVsDQoNCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIGFs ZXguYnVyckBlYWxkd3VsZi5vcmcudWsNClNlbnQ6IFN1bmRheSwgSnVseSAyMSwgMjAxOSA3OjI3 IFBNDQpUbzogSm9uYXRoYW4gTW9ydG9uIDxjaHJvbWF0aXg5OUBnbWFpbC5jb20+OyAiUm9kbmV5 IFcuIEdyaW1lcyIgPGZyZWVic2RAZ25kcnNoLmRuc21nci5uZXQ+DQpDYzogInRjcG1AaWV0Zi5v cmciIDx0Y3BtQGlldGYub3JnPjsgInRzdndnQGlldGYub3JnIiA8dHN2d2dAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3RjcG1dIFt0c3Z3Z10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1ncmltZXMtdGNwbS10Y3BzY2UtMDAudHh0DQoNClJvZCwgSm9uYXRoYW4sDQogSSBjb3Vs ZCBiZSB3cm9uZywgYnV0IGl0IGFwcGVhcnMgdG8gbWUgdGhhdCB0aGlzIGRyYWZ0IGRvZXMgbm90 IG1lcmVseSBub3QgbWFrZSB1c2Ugb2YgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbiwNCml0 J3MgaW5jb21wYXRpYmxlIHdpdGggaXQuIElzIHRoaXMgdGhlIGNhc2U/IE9mIGNvdXJzZSBTQ0Ug aXMgYSBjb21wZXRpdG9yIHRvIEw0UywgYnV0IHRoZSBhY2N1cmF0ZS1lY24gZHJhZnQgYWxzbyBh c3NlcnRzIHRoYXQgdGhlcmUgYXJlIG90aGVyIHVzZXMgZm9yIGFjY3VyYXRlLWVjbiBiZXNpZGVz IEw0UyAoRENUQ1AgYW5kIENvbkV4KSAuIEl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB5b3UgKHRoZSBU Q1BTQ0UgYXV0aG9ycyApIGNvdWxkIHN0YXRlIHlvdXIgcG9zaXRpb24gb24gdGhvc2Ugb3RoZXIg dXNlcywgZm9yIHRoZSByZWNvcmQuDQoNCkFsc28sIHByZXN1bWFibHkgaXQgaXMgaW5jb3JyZWN0 IHRoYXQgIlRoZXJlIGFyZSBubyBJQU5BIGNvbnNpZGVyYXRpb25zIiwgc2luY2UgSUFOQSB3b3Vs ZCBuZWVkIHRvIGNoYW5nZSB0aGUgTlMgYml0Lg0KDQpSZWdhcmRzLA0KDQpBbGV4DQoNClJvZG5l eSBXLiBHcmltZXMiIDxmcmVlYnNkQGduZHJzaC5kbnNtZ3IubmV0PG1haWx0bzpmcmVlYnNkQGdu ZHJzaC5kbnNtZ3IubmV0Pj4gd3JvdGU6DQoNCj4gPiBSb2QsDQo+ID4NCj4gPiBUaGlzIGRyYWZ0 IGFwcGVhcnMgdG8gYmUgZm9jdXNlZCBvbiBvYnRhaW5pbmcgYSBUQ1AgaGVhZGVyIGJpdCBmb3Ig U0NFLg0KPg0KPiBZZXMsIHRoYXQgaXMgY29ycmVjdC4NCj4NCj4gPiBBcyBhbiBhbHRlcm5hdGl2 ZSB0byB0aGlzIHNpbmdsZS1iaXQgcHJvcG9zYWwsIHBsZWFzZSB0YWtlIGEgbG9vayBhdCBkcmFm dC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLykgYW5kIGNvbnNpZGVyIGhvdyB0aGF0IGZ1 bmN0aW9uYWxpdHkgbWlnaHQgKG9yIG1pZ2h0IG5vdCkgYmUgdXNhYmxlIHdpdGggU0NFLg0KPg0K PiBJIHNwZWNpZmljYWxseSBkaWQgbm90IGRvIHdoYXQgQWNjdXJhdGUgRWNuIGF0dGVtcHRzIGFz IHRoYXQgcmVxdWlyZXMNCj4gYSBUQ1Agb3B0aW9uIG5lZ290aWF0aW9uIGF0IGNvbm5lY3Rpb24g ZXN0YWJsaXNobWVudCB0byBuZWdvdGlhdGUgdGhlDQo+IG92ZXJsb2FkaW5nIG9mIG90aGVyIFRD UCBoZWFkZXIgYml0cy4gIFNDRSBvbmx5IG5lZWRzIDEgbmV3IGJpdCwgYW5kDQo+IGRvZXMgbm90 IGFsdGVyIHRoZSBiZWhhdmlvciBvZiBhbnkgY3VycmVudCBiaXRzLg0KPg0KPiBUaGlzIHByb3Bv c2FsIChUQ1BTQ0UpIGRvZXMgbm90IGluIGFueSB3YXkgZWZmZWN0IHRoZSBjdXJyZW50IHVzZSBv Zg0KPiBhbnkgb2YgdGhlIG90aGVyIGJpdHMsIGFuZCB1c2Ugb2YgdGhlIE5TIGJpdCBzaG91bGQg YmUgZnVsbHkgYmFja3dhcmRzDQo+IGNvbXBhdGlibGUgYW5kIGlnbm9yZWQgYnkgcHJlIFNDRSBp bXBsZW1lbnRhdGlvbnMgYW5kIGRvZXMgbm90IHJlcXVpcmUNCj4gYSBUQ1Agb3B0aW9uIG5lZ290 aWF0aW9uLg0KPg0KPiBJIGhhdmUgdG8gZ2V0IGFkZGl0aW9uYWwgZGF0YSBidXQgaGF2ZSBiZWVu IGxlYWQgdG8gdW5kZXJzdGFuZCB0aGF0DQo+IGFkZGluZyBhIHRjcCBvcHRpb24gYW5kIGRvaW5n IHRoYXQgbmVnb3RpYXRpb24gaXMgZ29pbmcgdG8gY2F1c2UgYQ0KPiBncmVhdCBkZWFsIG9mIHBh aW4gaW4gdGhlIGFiaWxpdHkgdG8gZGVwbG95IGFjY3VyYXRlIGVjbiBhcyBpdCBpcw0KPiBjdXJy ZW50bHkgZGVzaWduZWQgZHVlIHRvIG1pZGRsZSBib3ggaW5zcGVjdGlvbiBhbmQgaGFuZGxpbmcu DQo+DQo+IFJlZ2FyZHMsDQo+IFJvZA0KPg0KPiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQoNCg0K DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D3C0A43rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UGxlYXNlIGJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgYWxzbyBkcmFmdC1pZXRmLXRj cG0tZ2VuZXJhbGl6ZWQtZWNuLTA0LCB3aGljaCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIGhhcyBh IGRlcGVuZGVuY3kgb24NCiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuIGZvciBjZXJ0YWlu IGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5KdXN0IHRvIHN0YXRlIHRoZSBvYnZpb3VzOiBUaGVzZSBkb2N1bWVu dHMgYXJlIHdvcmsgaW4gcHJvZ3Jlc3MgaW4gVENQTSBhbmQgVENQTSBhbHdheXMgd2VsY29tZXMg ZmVlZGJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gdGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYub3JnJmd0Ow0K PGI+T24gQmVoYWxmIE9mIDwvYj5hbGV4LmJ1cnJAZWFsZHd1bGYub3JnLnVrPGJyPg0KPGI+U2Vu dDo8L2I+IFN1bmRheSwgSnVseSAyMSwgMjAxOSA3OjI3IFBNPGJyPg0KPGI+VG86PC9iPiBKb25h dGhhbiBNb3J0b24gJmx0O2Nocm9tYXRpeDk5QGdtYWlsLmNvbSZndDs7ICZxdW90O1JvZG5leSBX LiBHcmltZXMmcXVvdDsgJmx0O2ZyZWVic2RAZ25kcnNoLmRuc21nci5uZXQmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiAmcXVvdDt0Y3BtQGlldGYub3JnJnF1b3Q7ICZsdDt0Y3BtQGlldGYub3JnJmd0Ozsg JnF1b3Q7dHN2d2dAaWV0Zi5vcmcmcXVvdDsgJmx0O3RzdndnQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIFt0c3Z3Z10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1ncmltZXMtdGNwbS10Y3BzY2UtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Um9kLCBKb25hdGhhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO0kgY291bGQgYmUgd3JvbmcsIGJ1dCBpdCBhcHBlYXJz IHRvIG1lIHRoYXQgdGhpcyBkcmFmdCBkb2VzIG5vdCBtZXJlbHkgbm90IG1ha2UgdXNlIG9mIGRy YWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5pdCdzIGluY29tcGF0aWJsZSB3aXRoIGl0 LiBJcyB0aGlzIHRoZSBjYXNlPyBPZiBjb3Vyc2UgU0NFIGlzIGEgY29tcGV0aXRvciB0byBMNFMs IGJ1dCB0aGUgYWNjdXJhdGUtZWNuIGRyYWZ0IGFsc28gYXNzZXJ0cyB0aGF0IHRoZXJlIGFyZSBv dGhlciB1c2VzIGZvciBhY2N1cmF0ZS1lY24gYmVzaWRlcyBMNFMgKERDVENQIGFuZA0KIENvbkV4 KSAuIEl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB5b3UgKHRoZSBUQ1BTQ0UgYXV0aG9ycyApIGNvdWxk IHN0YXRlIHlvdXIgcG9zaXRpb24gb24gdGhvc2Ugb3RoZXIgdXNlcywgZm9yIHRoZSByZWNvcmQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+QWxzbywgcHJlc3VtYWJseSBpdCBpcyBpbmNvcnJlY3QgdGhhdCAm cXVvdDtUaGVyZSBhcmUgbm8gSUFOQSBjb25zaWRlcmF0aW9ucyZxdW90Oywgc2luY2UgSUFOQSB3 b3VsZCBuZWVkIHRvIGNoYW5nZSB0aGUgTlMgYml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5BbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJvZG5leSBXLiBHcmltZXMmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpmcmVlYnNkQGduZHJzaC5kbnNtZ3IubmV0Ij5mcmVlYnNkQGdu ZHJzaC5kbnNtZ3IubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KJmd0OyAmZ3Q7IFJvZCw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMg ZHJhZnQgYXBwZWFycyB0byBiZSBmb2N1c2VkIG9uIG9idGFpbmluZyBhIFRDUCBoZWFkZXIgYml0 IGZvciBTQ0UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFllcywgdGhhdCBpcyBjb3JyZWN0Ljxicj4N CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFzIGFuIGFsdGVybmF0aXZlIHRvIHRoaXMgc2luZ2xlLWJp dCBwcm9wb3NhbCwgcGxlYXNlIHRha2UgYSBsb29rIGF0IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0 ZS1lY24gKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdGNwbS1hY2N1cmF0ZS1lY24vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLzwvYT4pIGFuZCBjb25zaWRlcg0KIGhvdyB0aGF0 IGZ1bmN0aW9uYWxpdHkgbWlnaHQgKG9yIG1pZ2h0IG5vdCkgYmUgdXNhYmxlIHdpdGggU0NFLiA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBzcGVjaWZpY2FsbHkgZGlkIG5vdCBkbyB3aGF0IEFjY3Vy YXRlIEVjbiBhdHRlbXB0cyBhcyB0aGF0IHJlcXVpcmVzPGJyPg0KJmd0OyBhIFRDUCBvcHRpb24g bmVnb3RpYXRpb24gYXQgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHRvIG5lZ290aWF0ZSB0aGU8 YnI+DQomZ3Q7IG92ZXJsb2FkaW5nIG9mIG90aGVyIFRDUCBoZWFkZXIgYml0cy4mbmJzcDsgU0NF IG9ubHkgbmVlZHMgMSBuZXcgYml0LCBhbmQ8YnI+DQomZ3Q7IGRvZXMgbm90IGFsdGVyIHRoZSBi ZWhhdmlvciBvZiBhbnkgY3VycmVudCBiaXRzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIHBy b3Bvc2FsIChUQ1BTQ0UpIGRvZXMgbm90IGluIGFueSB3YXkgZWZmZWN0IHRoZSBjdXJyZW50IHVz ZSBvZjxicj4NCiZndDsgYW55IG9mIHRoZSBvdGhlciBiaXRzLCBhbmQgdXNlIG9mIHRoZSBOUyBi aXQgc2hvdWxkIGJlIGZ1bGx5IGJhY2t3YXJkczxicj4NCiZndDsgY29tcGF0aWJsZSBhbmQgaWdu b3JlZCBieSBwcmUgU0NFIGltcGxlbWVudGF0aW9ucyBhbmQgZG9lcyBub3QgcmVxdWlyZTxicj4N CiZndDsgYSBUQ1Agb3B0aW9uIG5lZ290aWF0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGhh dmUgdG8gZ2V0IGFkZGl0aW9uYWwgZGF0YSBidXQgaGF2ZSBiZWVuIGxlYWQgdG8gdW5kZXJzdGFu ZCB0aGF0PGJyPg0KJmd0OyBhZGRpbmcgYSB0Y3Agb3B0aW9uIGFuZCBkb2luZyB0aGF0IG5lZ290 aWF0aW9uIGlzIGdvaW5nIHRvIGNhdXNlIGE8YnI+DQomZ3Q7IGdyZWF0IGRlYWwgb2YgcGFpbiBp biB0aGUgYWJpbGl0eSB0byBkZXBsb3kgYWNjdXJhdGUgZWNuIGFzIGl0IGlzPGJyPg0KJmd0OyBj dXJyZW50bHkgZGVzaWduZWQgZHVlIHRvIG1pZGRsZSBib3ggaW5zcGVjdGlvbiBhbmQgaGFuZGxp bmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBSb2Q8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGFua3MsIC0tRGF2aWQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D3C0A43rznt8114rzntrzd_-- From nobody Sun Jul 21 19:05: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 8C04A120112; Sun, 21 Jul 2019 19:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIlnEptpz-ao; Sun, 21 Jul 2019 19:05:35 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03BFB12003F; Sun, 21 Jul 2019 19:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l8AT2PbrW4xfM1RbD0+JHa1XlCl9aXtpVRCqXhQ72a8=; b=xkF7A0+Dmobw3Yt0RCsdYaqpn gHmHwfonX5+Q3wjhabODIGtuLJLQAXdjRrknf+bTG5ttXEqnCiA80OzDh01jtb+6qn/KQ3puObQvu Ak+ZZv5WoGpNUeGUPqShVuSEBZ5TshEjzHuhgrsanNH4OhFL7suM4crtCgpWfROpgrAf/l55A9I0s ACWn5O0NebhLWSs0ShlLbkEyu/YDRERtEGwJScClh8eYeewGE8/e9xYsLYVCrjQZJcNRE2y5Iv5Y1 9zHk2aSwcpoFkAmRyOd9oPVTOK3pCl2iGkZjQGHuBsEElFxn+eKf2i0bPG/hz2mJXEv9mEMvyR0Ae EqDHLFgOg==; Received: from modemcable186.232-83-70.mc.videotron.ca ([70.83.232.186]:36952 helo=[192.168.0.161]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hpNhj-0005cL-MJ; Mon, 22 Jul 2019 03:05:32 +0100 From: Bob Briscoe To: "Scharf, Michael" , Praveen Balasubramanian , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> <6413d62f-ecf1-3319-7bb2-2c763b0633be@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D154250@rznt8114.rznt.rzdir.fht-esslingen.de> Message-ID: Date: Mon, 22 Jul 2019 03:05:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D154250@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------64A99559A645D0691FCD6031" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 02:05:42 -0000 This is a multi-part message in MIME format. --------------64A99559A645D0691FCD6031 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, Sorry, I held off responding until the Low Latency additions to the DOCSIS 3.1 spec were published (which was imminent at the time, but then got delayed). Then I omitted to pick up this thread again. I can now give one of the real world examples that I couldn't give before, even tho it's not the most interesting one... On 10/11/2018 08:13, Scharf, Michael wrote: > > Hi Bob, > > I believe more empirical evidence is needed that this is a problem > that need to be addressed. > > For instance, for what link technologies does this problem exist in > reality? > Main problem is radio links that do link-layer retransmission (due to intermittent corruption loss). RFC3366 explains the problem of needing different ARQ persistence for transports with different ordering sensitivities. LTE LTE typically does a max of 3 link-layer retransmissions as part of HARQ. Each takes about 8ms. And after 3 re-transmissions, despite wasting 24ms, the block error rate is typically not significantly improved (implying that, once 1 retransmission is needed, many more retransmissions are often needed). So being allows to immediately forward those packets that can be assembled saves 24ms - more often than not. Packets from one flow (or stream in a QUIC/SCTP scenario) can be sitting behind a missing frame waiting for link-layer retransmission (HoL blocking). Here's a thesis about exploiting RACK by turning off resequencing at the PDCP layer in LTE: Implementing immediate forwarding for 4G in a network simulator Unfortunately the evaluations are limited - I plan to pick this up soon. WiFi I haven't studied WiFi, The retry limits are higher than LTE (max 6 short retries and 4 long = 10 total). The overall potential delay is greater than LTE, altho each round is somewhat faster. DOCSIS Since DOCSIS 3.1 i17 when L4S was added, resequencing is specified to be disabled in the downlink for the L4S service flow. This doesn't give such a big gain in delay as it would in a radio link, cos the cable has much lower loss, of course. The saving is primarily in cable modem buffer memory usage and less processing. Resequencing is necessary on the Classic service flow because traditional (3DupACK) TCPs would otherwise spuriously detect losses. The misordering happens on links that bond together multiple OFDMA channels for faster throughput. Data on different channels arrives faster or slower. > Your example with 94us seems to imply a data rate of 384 Mbit/s for a > single TCP stream. That is probably not what the vast majority of TCP > connections use. So is there an engineering need? > Perhaps you've misunderstood. This is described in the spec. as a scaling requirement. That means it's so that it is easier to design faster links in future, with less constraint on ordering (typically using parallelism at the link layer). If the requirement on L4S senders is not made from the start, it will never be possible to introduce it later, because there will always be the risk of 'legacy' senders on the link. Link rates have doubled every 1.6 years for the last couple of decades. Even if this slows down, it's not going to be long before 384Mb/s is normal. Now compare that with the average time it takes to go from experimental WG draft to proposed standard RFC. By the time this is a PS, 384Mb/s will seem slow. > And I don’t get why keeping reordering within 94us is so much of a > challenge for a link layer technology. I would really like to learn > technical reasons why (mostly) in-order delivery on links cannot be > implemented now or in future. > If you still need me to explain, pls ask. But I assume it's obvious in the 3 cases above (LTE, WiFi and DOCSIS). * In the radio cases, it's a question of excessive HoL buffering delay. * In the fixed link example, it cuts the cost of high speed buffer memory and being able to use processing for more useful purposes. You don't necessarily get these benefits when you first turn reseq off. You get them once the approach becomes the norm, so you can cost-reduce the equipment. > If we indeed run into a real-world technical problem, it wouldn’t help > to solve that problem for L4S – it must be solved for all Internet > traffic then and the overall solution would (probably) be different to > the one used in an experiment. > Irrespective of the proportion of traffic that uses L4S: * Removing HoL blocking of retransmission delay on wireless links, gives an immediate performance benefit for all the traffic that uses L4S * On fixed links, unless the equipment is designed so that resources are dedicated to configured comms channels (which would be a bad design), reducing buffer memory and processing for a fraction of the traffic, reduces those resources by that fraction (or frees up that fraction to be used by the other fraction). The idea of the L4S experiment (as stated in l4s-arch) is ultimately low delay for all Internet traffic (because there would be no reason not to use it if it achieves its ambitions). > To me, one of the fundamental requirements on a packet network is that > the network invests some reasonable effort to keep packets in order on > a given path – albeit a packet network is not always perfect and that > has always been OK. I am not convinced so far that it makes sense to > give up that design guideline for link technologies – not even for L4S. > Constraints change. Design principles change. What you and I learned at school was true for its time. There's a lot more parallelism in networks now, because it's much more expensive to get individual links to keep increasing in speed, than it is to stick a load in parallel. Bob > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Saturday, November 10, 2018 2:35 AM > *To:* Praveen Balasubramanian; Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" > > Praveen, Michael, > > The idea is not to relax ordering requirement on links. It's to make > sure it doesn't keep getting tighter for ever. > > As flow-rates get faster, the requirements on links get tighter if the > reordering window is expressed in packets. > For instance (as I showed in my presentation), with RTT = 24ms (say), > if the window is 12 segments, a reordering window of 3 DupACKs equates > to 6ms. But as flow rates increase, say 8 times faster (window = 96) > reduces the time over which links have to keep packets in order to > 750μs. Another 8x faster, and links have to keep order within 94μs. > And so on. > > This cannot go on indefinitely, because the constraints on link-layer > retransmission are constant in time (length of link / speed of light + > processing time). If the 3 DupACK rule is not removed, link timings > will be continually squeezed, so radio links will eventually have to > give up ARQ, which will be awful for performance. > > It will take decades before /all/ legacy (non-RACK) TCPs have stopped > using any particular link. So links in general will still have to keep > tightening their re-sequencing time because of legacy 3 Dup-ACK flows. > But eventually the 3-DupACK flows that remain will tend to be those on > unmaintained machines that will not be taking advantage of higher > speeds. Then, assuming the RACK experiment remains successful over > these decades, links will be able to stop tightening their reordering > degree. > > > The idea is that, for the L4S experiment, we can remove the 3 DupACK > rule entirely from the start, and solely express reordering in units > of time. Then, L4S transports will evolve, presumably using similar > RACK-like reordering logic to non-L4S transports. And we shall see > where the minimum reordering window ends up (in time units), and > hopefully converge on a value we can standardize - both in TCP and in > other transports. > > No L4S link would relax its ordering requirement if it led to worse > TCP performance. So layer 4 will be in control of this process. > Nonetheless, it is important to stop measuring reordering in packets. > But hopefully, from the start of the L4S experiment, logical links > solely bearing L4S traffic will not need to continually tighten their > ordering requirement. > > If an OS supports RACK, which yours does, then buffering on the > receiver will remain constant in time, which will mean the memory > requirement will grow as flow rates scale up. > > You (Praveen) supported and implemented RACK before I'd even thought > about all this. I'm also now a convert. I'm recognizing and > articulating its wider advantages. > > > Bob > > On 09/11/2018 19:10, Praveen Balasubramanian wrote: > > >> Therefore they can estimate the max reordering they allow their > links to introduce > > IMO L2 shouldn’t /introduce/ more reordering just because L4 > /congestion control/ is more resilient to it. There is other > performance impact due to reordering: LRO / GRO / RSC opportunity > will be reduced, more memory and CPU cost to do reassembly at L4 > (this is an active area for remote attacks) etc. IMO L4 guidance > should remain that link vendors must avoid reordering as much as > possible and not build solutions that cause frequent or consistent > reordering. > > *From:*tcpm > *On Behalf Of *Bob Briscoe > *Sent:* Friday, November 9, 2018 10:52 AM > *To:* Scharf, Michael > ; tcpm@ietf.org > > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > The idea is that (as now in the RACK draft since discussion on the > tcpm list earlier this year under a subject something like vicious > circle or virtuous circle) there will be a limit on the initial > RACK reordering window expressed in fractional RTT units. > > Link vendors know the min e2e RTT of the paths that their links > are usually deployed over. Therefore they can estimate the max > reordering they allow their links to introduce. > > I don't expect this limit to be set in stone while both RACK and > L4S are experimental. But as both these experiments progress, I > think the industry will get a better idea of where the limit > should lie. > > It was the realization that, if TCP adapted its reordering window > to the measured reordering degree without bound, the L2 world > would continually increase the reordering degree of their links > (the vicious circle). > > If there is any aspect of this limit expressed in units of > packets, the limit will decrease in time as flow rates increase, > and therefore not serve to give the L2 world any clear guidance - > no de facto limit agreed between the L4 world and the L2 world. > > If we keep the limit in units of RTT, hopefully then we have a > virtuous circle, not a vicious circle. > > > > Bob > > > On 09/11/2018 18:28, Scharf, Michael wrote: > > I may miss something, but I read the outcome of the appendix > as a requirement “must be more robust to reordering”. As far > as I understand, that can be implemented in different ways. > > And I may be wrong, but those link technologies could be well > implemented in a router and then one needs to analyze how that > whole architecture fits into the scheduler, queue, policer, > and line card hardware design of a router. But that is > something routing people know better than me. My point is just > to get the experts into the loop early. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 7:04 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > Please address the scaling rationale in the appendix for why > it does matter how a sender realizes this internally. > > The list of access links types I mentioned are rarely > connected directly to routers. > > > > Bob > > On 09/11/2018 17:44, Scharf, Michael wrote: > > I’ll not comment on link technology implementation, > scheduler and queue design assumptions in Appendix A.1.7 > of draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area > may be more familiar with the implications of internal > designs e.g. inside a router. IMHO the best way to get > routing experts into the loop before further discussing > what is currently listed in Appendix A.1.7. > > Thus, I limit my response to the actual wording in the > main part of draft-ietf-tsvwg-ecn-l4s-id-05: > >     o  A scalable congestion control MUST detect loss by > counting in > >       units of time, which is scalable, and MUST NOT count > in units of > >       packets (as in the 3 DupACK rule of traditional > TCP), which is not > >       scalable (see Appendix A.1.7 > for > rationale). > > As individual contributor, I disagree with this > requirement. I would probably be OK with a wording that a > TCP sender must be able to tolerate reordering beyond 3 > Duplicate ACKs. I believe it does not matter how a sender > realizes this internally. > > And if that requirement is not just removed, I believe the > wording “traditional TCP” has to be replaced by “standard > TCP”. > > BTW, also, in the rest of the document there has to be a > clear distinction between experiments and standards. > History tells us that some experiments can evolve into > standards track specifications, while other experiments > may fail. And there is no way of knowing that in advance. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 11:08 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > On 09/11/2018 06:21, Scharf, Michael wrote: > > I don’t see the fundamental difference between a link > technology that guarantees in-order delivery within a > flow (say by flow hashing, see ECMP) vs. some link > scheme that guarantees in-order delivery, say, only > for some fraction of the traffic characterized by some > other means (say, other header bits). > > [The "other means" and "other bits" wording is pretty > ambiguous here. I reckon I can guess what you mean but > then I don't know why you're saying this, 'cos I don't > think I've disagreed with you on this. So perhaps you > could be more specific and we might be able to see why > you've brought this up.] > > Also I wasn't really talking about all "link technology > that guarantees in-order delivery within a flow". {Note 1} > I was talking about link technology where all flows are > blocked while waiting to get the aggregate back in order > that it was in when it arrived. I specifically said: > > > > > Note that there can be multiple flows over one link. So > 'in-order delivery' for a link does not mean in order of > TCP sequence number. It means 'delivered in the order that > packets arrived at the link' (the link ingress adds its > own sequence numbers, and the link egress buffers them > until it can send out in the same order, or until a > time-out or max no. of link retransmissions). > > For example: > > * A packet resequencing buffer after allowing for > link-layer retransmissions is common for radio link > technologies such as LTE (PDCP layer) and 802.11 WiFi. > * A packet resequencing buffer after merging multiple > bonded link channels is common for other access link > technologies such as downstream DOCSIS bonded channels. > > > > > > > Clearly, reordering is a problem that needs to be > discussed in the IETF as a whole. And we could discuss > whether a revision of RFC 3366 is needed. > > No. There is no proposal to alter general guidance for all > links like RFC 3366. No-one is saying this. > > There is not even a proposal to require or even recommend > that L4S-specific links do anything. > > The specific proposal is to require L4S /sources/ to use a > RACK-like scheme, as a condition for setting the ECT(1) > codepoint. See the last bullet in S.4.3 of > draft-ietf-tsvwg-ecn-l4s-id-05 > . > > > This says nothing about what L4S links MUST, SHOULD or MAY > do. It just gives an L4S link an opportunity not to have > to do resequencing. > > > > > > But I am not convinced that this topic has to be tied into > an experiment such as L4S. > > It is an opportunity that currently only applies to L4S. > > L4S is merely an example of a case where we can mandate > that there will be no non-RACK traffic in a link, which > creates an opportunity for those who are implementing the > L4S DualQ Coupled AQM to ignore the RFC3366 resequencing > advice for the L4S queue (but we are not changing the > advice, because L4S is only an experiment). The prize is > to remove the head-of-line blocking problem for their users. > > This is not L4S-specific, altho there are no other > examples at the moment where this opportunity is possible > (so in that sense it is /currently/ L4S-specific). > > > The message has to be handled really carefully, because > the opportunities for misunderstanding are enormous (as > evidenced by this thread, and we haven't even started > talking to non-transport people yet). > > So Gorry and David B want me to draft a short I-D that > they will word-smith and author as tsvwg chairs to make > the situation clear. > > I have said I don't want this discussion to be officially > raised outside the transport area until we are sure that a > variant of RACK is even feasible without any packet > counting at all (i.e. without the initial 3-DupACK rule in > current RACK). So I'll prioritize working that out for the > next week or so, rather than drafting anything. > > > > Bob > > {Note 1}: I hadn't considered that this would affect > technologies like ECMP that maintain order without a > resequencing buffer and without introducing HoL blocking. > But actually, the consequence there would be that L4S > traffic could be sprayed by ECMP without per-flow hashing. > > > > > > Michael > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 6:42 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > That is the point I thought you were making, and my point > /is/ about that. > > If an application needs all the packets (i.e. a reliable > protocol), it's not useful to reduce the latency of some > packets but not all. That's where the in-order requirement > comes from. > > However, if a stream-based transport is used (i.e. TCP) > the /application/ still gets in-order delivery from TCP. > It just doesn't have to require links to provide in order > delivery as well. > > Note that there can be multiple flows over one link. So > 'in-order delivery' for a link does not mean in order of > TCP sequence number. It means 'delivered in the order that > packets arrived at the link' (the link ingress adds its > own sequence numbers, and the link egress buffers them > until it can send out in the same order, or until a > time-out or max no. of link retransmissions). > > So, if the link loses a packet from flow A (the link isn't > aware of microflows, I'm just saying the packet happens to > be from flow A), link-layer in-order delivery will hold > back all packets sent after that packet (from all flows, > not just flow A) until the link repairs the gap or gives up. > > So hop-by-hop in-order delivery gives every flow the same > delay as the worst delayed flow. > > Of course, someone building a network for DETNET would > avoid link technologies like WiFi or LTE that frequently > lose and retransmit packets. But wherever there is > variable delay in a link, guaranteed in-order delivery > per-hop means every flow is guaranteed to always get the > worst delay from every link, which would have been > experienced by only one flow without per-hop in-order > delivery. > > And many of the applications of DETNET involve dumb > industrial machinery that just expects everything to > arrive in order and to a clocked schedule. But it's always > as effective to deploy a resequencing buffer as the > penultimate hop, screwed onto the receiving machine if > necessary, rather than require per-hop resequencing in the > network. > > ________________ > So, why do Internet links often ensure in-order delivery > even though TCP puts everything in order for the application? > > Short answer: the 3 DupACK rule (which is to do with > loss-recovery, a different issue from the discussion above). > > Long answer: As flow rates have scaled up, the typical > time between 3 packet arrivals has become so small that > TCP's 3-DupACK rule makes links have to provide delivery > with only a very small re-ordering degree - so small that > it's easier for a link to just deliver everything in the > order it received it; not because TCP doesn't put packets > back in order, but just so as not to trigger TCP into > generating spurious retransmissions. > > > > Bob > > On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S > and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on > where the resequencing function should be located. > > * L4S takes the end-to-end approach saying that it > is sufficient to do resequencing in one place (the > receiving host) if it is needed. Then any > resequencing delay only affects that flow. > * The DETNET approach is saying the resequencing > must be done hop-by-hop. This means there appears > to be no resequencing needed on the receiver > (except if there's re-ordering on the final hop). > > * In order to guarantee no resequencing in the > network (DETNET approach), only the the worst case > latency can be guaranteed, and every packet has to > have that same worst-case latency. > * When you leave resequencing to the receiver > (end-to-end approach), most of the packets arrive > earlier than they would with DETNET, but out of > order ones might not. Then the application chooses > whether it wants to wait. > > [ms] My point is different: There seem to be other > working groups in the IETF that do talk about “low > latency” as well but apparently they also do need > in-order delivery of packets, too. So the assumption > that e.g. a link layer technology can simply disable > in-order delivery for all “low latency” applications > seems not correct. The reality may be a bit more complex. > > The 3 DupACK rule in TCP led the Internet not to > follow the end-to-end principle on re-sequencing. Now > we're removing the 3 DupACK rule, we can take > advantage of the e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 > and RFC 5681 is standards track. So the bar for > “removing” that rule for TCP is not low… > > [ms] Also, the end-to-end principle comes with > tradeoffs. For instance, relying on the end-to-end > principle for recovery of bit errors is not efficient. > For in-order delivery there are tradeoffs as well, see > e.g. Section 4 in draft-ietf-tcpm-rack-04. There may > be no free lunch. > > Of course, an application might choose to use TCP and > L4S, rather than UDP and L4S (e.g QUIC). Then there > could still be HoL blocking in the receiving TCP > stack. But at least there's no HoL blocking in the > network, and the app can choose between stream (TCP) > or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed > up, I fail to see the benefit (see > draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > As far as I understand, the DETNET WG in RTG area > has quite some uses cases for ultra-low latency > transport - in particular also with bounded > jitter. And some of these applications (e.g. using > UDP) apparently may not be able to tolerate *any* > out-of-order packet delivery. > > So perhaps some cross-area alignment on > ulta-low-latency application requirements would be > useful? > > Michael > > (who recently had to review > draft-ietf-detnet-architecture) > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------64A99559A645D0691FCD6031 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

Sorry, I held off responding until the Low Latency additions to the DOCSIS 3.1 spec were published (which was imminent at the time, but then got delayed). Then I omitted to pick up this thread again.

I can now give one of the real world examples that I couldn't give before, even tho it's not the most interesting one...

On 10/11/2018 08:13, Scharf, Michael wrote:

Hi Bob,

 

I believe more empirical evidence is needed that this is a problem that need to be addressed.

 

For instance, for what link technologies does this problem exist in reality?

Main problem is radio links that do link-layer retransmission (due to intermittent corruption loss). RFC3366 explains the problem of needing different ARQ persistence for transports with different ordering sensitivities.

LTE

LTE typically does a max of 3 link-layer retransmissions as part of HARQ. Each takes about 8ms. And after 3 re-transmissions, despite wasting 24ms, the block error rate is typically not significantly improved (implying that, once 1 retransmission is needed, many more retransmissions are often needed). So being allows to immediately forward those packets that can be assembled saves 24ms - more often than not.

Packets from one flow (or stream in a QUIC/SCTP scenario) can be sitting behind a missing frame waiting for link-layer retransmission (HoL blocking).

Here's a thesis about exploiting RACK by turning off resequencing at the PDCP layer in LTE:
Implementing immediate forwarding for 4G in a network simulator
Unfortunately the evaluations are limited - I plan to pick this up soon.

WiFi

I haven't studied WiFi, The retry limits are higher than LTE (max 6 short retries and 4 long = 10 total). The overall potential delay is greater than LTE, altho each round is somewhat faster.

DOCSIS

Since DOCSIS 3.1 i17 when L4S was added, resequencing is specified to be disabled in the downlink for the L4S service flow. This doesn't give such a big gain in delay as it would in a radio link, cos the cable has much lower loss, of course. The saving is primarily in cable modem buffer memory usage and less processing.

Resequencing is necessary on the Classic service flow because traditional (3DupACK) TCPs would otherwise spuriously detect losses. The misordering happens on links that bond together multiple OFDMA channels for faster throughput. Data on different channels arrives faster or slower.


 

Your example with 94us seems to imply a data rate of 384 Mbit/s for a single TCP stream. That is probably not what the vast majority of TCP connections use. So is there an engineering need?

Perhaps you've misunderstood. This is described in the spec. as a scaling requirement. That means it's so that it is easier to design faster links in future, with less constraint on ordering (typically using parallelism at the link layer).

If the requirement on L4S senders is not made from the start, it will never be possible to introduce it later, because there will always be the risk of 'legacy' senders on the link.

Link rates have doubled every 1.6 years for the last couple of decades. Even if this slows down, it's not going to be long before 384Mb/s is normal.

Now compare that with the average time it takes to go from experimental WG draft to proposed standard RFC. By the time this is a PS, 384Mb/s will seem slow.


 

And I don’t get why keeping reordering within 94us is so much of a challenge for a link layer technology. I would really like to learn technical reasons why (mostly) in-order delivery on links cannot be implemented now or in future.

If you still need me to explain, pls ask. But I assume it's obvious in the 3 cases above (LTE, WiFi and DOCSIS).
  • In the radio cases, it's a question of excessive HoL buffering delay.
  • In the fixed link example, it cuts the cost of high speed buffer memory and being able to use processing for more useful purposes. You don't necessarily get these benefits when you first turn reseq off. You get them once the approach becomes the norm, so you can cost-reduce the equipment.

 

If we indeed run into a real-world technical problem, it wouldn’t help to solve that problem for L4S – it must be solved for all Internet traffic then and the overall solution would (probably) be different to the one used in an experiment.

Irrespective of the proportion of traffic that uses L4S:
  • Removing HoL blocking of retransmission delay on wireless links, gives an immediate performance benefit for all the traffic that uses L4S
  • On fixed links, unless the equipment is designed so that resources are dedicated to configured comms channels (which would be a bad design), reducing buffer memory and processing for a fraction of the traffic, reduces those resources by that fraction (or frees up that fraction to be used by the other fraction).

The idea of the L4S experiment (as stated in l4s-arch) is ultimately low delay for all Internet traffic (because there would be no reason not to use it if it achieves its ambitions).

 

To me, one of the fundamental requirements on a packet network is that the network invests some reasonable effort to keep packets in order on a given path – albeit a packet network is not always perfect and that has always been OK. I am not convinced so far that it makes sense to give up that design guideline for link technologies – not even for L4S.

Constraints change. Design principles change. What you and I learned at school was true for its time. There's a lot more parallelism in networks now, because it's much more expensive to get individual links to keep increasing in speed, than it is to stick a load in parallel.



Bob

 

Michael

 

 

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Saturday, November 10, 2018 2:35 AM
To: Praveen Balasubramanian; Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK"

 

Praveen, Michael,

The idea is not to relax ordering requirement on links. It's to make sure it doesn't keep getting tighter for ever.

As flow-rates get faster, the requirements on links get tighter if the reordering window is expressed in packets.
For instance (as I showed in my presentation), with RTT = 24ms (say), if the window is 12 segments, a reordering window of 3 DupACKs equates to 6ms. But as flow rates increase, say 8 times faster (window = 96) reduces the time over which links have to keep packets in order to 750μs. Another 8x faster, and links have to keep order within 94μs. And so on.

This cannot go on indefinitely, because the constraints on link-layer retransmission are constant in time (length of link / speed of light + processing time). If the 3 DupACK rule is not removed, link timings will be continually squeezed, so radio links will eventually have to give up ARQ, which will be awful for performance.

It will take decades before /all/ legacy (non-RACK) TCPs have stopped using any particular link. So links in general will still have to keep tightening their re-sequencing time because of legacy 3 Dup-ACK flows. But eventually the 3-DupACK flows that remain will tend to be those on unmaintained machines that will not be taking advantage of higher speeds. Then, assuming the RACK experiment remains successful over these decades, links will be able to stop tightening their reordering degree.


The idea is that, for the L4S experiment, we can remove the 3 DupACK rule entirely from the start, and solely express reordering in units of time. Then, L4S transports will evolve, presumably using similar RACK-like reordering logic to non-L4S transports. And we shall see where the minimum reordering window ends up (in time units), and hopefully converge on a value we can standardize - both in TCP and in other transports.

No L4S link would relax its ordering requirement if it led to worse TCP performance. So layer 4 will be in control of this process. Nonetheless, it is important to stop measuring reordering in packets. But hopefully, from the start of the L4S experiment, logical links solely bearing L4S traffic will not need to continually tighten their ordering requirement.

If an OS supports RACK, which yours does, then buffering on the receiver will remain constant in time, which will mean the memory requirement will grow as flow rates scale up.

You (Praveen) supported and implemented RACK before I'd even thought about all this. I'm also now a convert. I'm recognizing and articulating its wider advantages.


Bob

On 09/11/2018 19:10, Praveen Balasubramanian wrote:

>> Therefore they can estimate the max reordering they allow their links to introduce

IMO L2 shouldn’t introduce more reordering just because L4 congestion control is more resilient to it. There is other performance impact due to reordering: LRO / GRO / RSC opportunity will be reduced, more memory and CPU cost to do reassembly at L4 (this is an active area for remote attacks) etc. IMO L4 guidance should remain that link vendors must avoid reordering as much as possible and not build solutions that cause frequent or consistent reordering.

 

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Bob Briscoe
Sent: Friday, November 9, 2018 10:52 AM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

The idea is that (as now in the RACK draft since discussion on the tcpm list earlier this year under a subject something like vicious circle or virtuous circle) there will be a limit on the initial RACK reordering window expressed in fractional RTT units.

Link vendors know the min e2e RTT of the paths that their links are usually deployed over. Therefore they can estimate the max reordering they allow their links to introduce.

I don't expect this limit to be set in stone while both RACK and L4S are experimental. But as both these experiments progress, I think the industry will get a better idea of where the limit should lie.

It was the realization that, if TCP adapted its reordering window to the measured reordering degree without bound, the L2 world would continually increase the reordering degree of their links (the vicious circle).

If there is any aspect of this limit expressed in units of packets, the limit will decrease in time as flow rates increase, and therefore not serve to give the L2 world any clear guidance - no de facto limit agreed between the L4 world and the L2 world.

If we keep the limit in units of RTT, hopefully then we have a virtuous circle, not a vicious circle.



Bob


On 09/11/2018 18:28, Scharf, Michael wrote:

I may miss something, but I read the outcome of the appendix as a requirement “must be more robust to reordering”. As far as I understand, that can be implemented in different ways.

 

And I may be wrong, but those link technologies could be well implemented in a router and then one needs to analyze how that whole architecture fits into the scheduler, queue, policer, and line card hardware design of a router. But that is something routing people know better than me. My point is just to get the experts into the loop early.

 

Michael

 

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 7:04 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

Please address the scaling rationale in the appendix for why it does matter how a sender realizes this internally.

The list of access links types I mentioned are rarely connected directly to routers.



Bob

On 09/11/2018 17:44, Scharf, Michael wrote:

I’ll not comment on link technology implementation, scheduler and queue design assumptions in Appendix A.1.7 of draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more familiar with the implications of internal designs e.g. inside a router. IMHO the best way to get routing experts into the loop before further discussing what is currently listed in Appendix A.1.7.

 

Thus, I limit my response to the actual wording in the main part of draft-ietf-tsvwg-ecn-l4s-id-05:

 

    o  A scalable congestion control MUST detect loss by counting in

      units of time, which is scalable, and MUST NOT count in units of

      packets (as in the 3 DupACK rule of traditional TCP), which is not

      scalable (see Appendix A.1.7 for rationale).

 

As individual contributor, I disagree with this requirement. I would probably be OK with a wording that a TCP sender must be able to tolerate reordering beyond 3 Duplicate ACKs. I believe it does not matter how a sender realizes this internally.

 

And if that requirement is not just removed, I believe the wording “traditional TCP” has to be replaced by “standard TCP”.

 

BTW, also, in the rest of the document there has to be a clear distinction between experiments and standards. History tells us that some experiments can evolve into standards track specifications, while other experiments may fail. And there is no way of knowing that in advance.

 

Michael

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 11:08 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

On 09/11/2018 06:21, Scharf, Michael wrote:

I don’t see the fundamental difference between a link technology that guarantees in-order delivery within a flow (say by flow hashing, see ECMP) vs. some link scheme that guarantees in-order delivery, say, only for some fraction of the traffic characterized by some other means (say, other header bits).

[The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.]

Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said:




Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

For example:

  • A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi.
  • A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels.






 

Clearly, reordering is a problem that needs to be discussed in the IETF as a whole. And we could discuss whether a revision of RFC 3366 is needed.

No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this.

There is not even a proposal to require or even recommend that L4S-specific links do anything.

The specific proposal is to require L4S sources to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05.

This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing.





 

But I am not convinced that this topic has to be tied into an experiment such as L4S.

It is an opportunity that currently only applies to L4S.

L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users.

This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is currently L4S-specific).


The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet).

So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear.

I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything.



Bob

{Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing.





 

Michael

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Friday, November 9, 2018 6:42 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 








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







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






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





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




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



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------64A99559A645D0691FCD6031-- From nobody Sun Jul 21 23:03:46 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 157A212004C; Sun, 21 Jul 2019 23:03:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <156377542404.8780.6543249806301267669@ietfa.amsl.com> Date: Sun, 21 Jul 2019 23:03:44 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-09.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, 22 Jul 2019 06:03:44 -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-09.txt Pages : 47 Date : 2019-07-21 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-09 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 21 23:09: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 ADB491200A1 for ; Sun, 21 Jul 2019 23:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejiGm80cG63A for ; Sun, 21 Jul 2019 23:09:09 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FCB12004C for ; Sun, 21 Jul 2019 23:09:09 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45sWQW42ktz1yBS; Mon, 22 Jul 2019 08:09:07 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 45sWQW3DnyzFpWY; Mon, 22 Jul 2019 08:09:07 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 08:09:07 +0200 From: To: "Scharf, Michael (Michael.Scharf@hs-esslingen.de)" , "tcpm@ietf.org" , "philip.eardley@bt.com" Thread-Topic: I-D Action: draft-ietf-tcpm-converters-09.txt Thread-Index: AQHVQFNI6snpvRA6n0KOpesBpWur/6bWJkGg Date: Mon, 22 Jul 2019 06:09:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330312E3275@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <156377542404.8780.6543249806301267669@ietfa.amsl.com> In-Reply-To: <156377542404.8780.6543249806301267669@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-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 06:09:11 -0000 Hi all,=20 This version integrates the comments raised during the WGLC. It implements = in particular the various changes shared on the list to address Phil's revi= ew. Cheers, Olivier & Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: lundi 22 juillet 2019 08:04 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: I-D Action: draft-ietf-tcpm-converters-09.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-09.txt > Pages : 47 > Date : 2019-07-21 >=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 >=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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 22 01:51: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 D4A481201A1; Mon, 22 Jul 2019 01:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqEl8BVsvqWh; Mon, 22 Jul 2019 01:51: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 7E749120191; Mon, 22 Jul 2019 01:51:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id D1FC025A12; Mon, 22 Jul 2019 10:51:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563785504; bh=AAMUf5lxs5R5dYM86TaP90xCm++ev5TuMXxyaPROAVI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qa26ufMVIyMZxqkoXzcJ4R4av/alLXdtjKnTYVMvM3G+aEujb6oxMYrOrbsuubE6J jVVBA4T00GtKwYCxP88yA8BVhZwVR9PnOaUkoHHTrK2chwmk9SLeWKszTGpQsdKGQb X0LPqL0p9jHsDsaXUYEu+V/E0JUxPC2uBsXY8oLc= 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 3fp52KNFnsPY; Mon, 22 Jul 2019 10:51:42 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 22 Jul 2019 10:51:42 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 22 Jul 2019 10:51:42 +0200 From: "Scharf, Michael" To: Bob Briscoe , Praveen Balasubramanian , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04QAAaGWYAAD7CAQAAA6LeAAAIdXND///yrgIAABP8AgABrZoD//40q8IGPmtoA//9tY5A= Date: Mon, 22 Jul 2019 08:51:42 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3C1119@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> <6413d62f-ecf1-3319-7bb2-2c763b0633be@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D154250@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3C1119rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 08:51:49 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3C1119rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1NvcnJ5IGZvciBzdHJpcHBpbmcgdGhlIG9yaWdpbmFsIHRleHQsIGJ1dCBtYWlsbWFuIGNvbXBs YWlucyBhYm91dCA+MTAwS0Igc2l6ZV0NCg0KSGkgQm9iLA0KDQpUbyBtZSwgbm9uZSBvZiB0aGVz ZSBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvIEw0Uy4gVGhleSBhcmUgbm90IGV2ZW4gc3BlY2lmaWMg dG8gdXNlIG9mIEVDTiBvciBjb25nZXN0aW9uIGNvbnRyb2wuIFRvIG1lLCBpdCBpcyBhIHZhbGlk IGJ1dCBvcnRob2dvbmFsIHByb2JsZW0uDQoNCkFzIEkgcmVzdWx0LCB3aXRoIFRDUE0gY2hhaXIg aGF0IG9mZiwgSSBjb250aW51ZSB0byBkaXNhZ3JlZSB0aGF0IHRoaXMgYmVsb25ncyBpbnRvIHRo ZSBMNFMgZXhwZXJpbWVudC4NCg0KU3BlY2lmaWNhbGx5LCBJIGRpc2FncmVlIHRoYXQgdGhpcyBz aGFsbCBiZSBidW5kbGVkIHdpdGggYW4gRUNOIGNvZGVwb2ludCBhbGxvY2F0aW9uLiBJZiBMNFMg dXNlZCBhbm90aGVyIGlkZW50aWZpZXIsIGUuZy4sIGEgcHJvdG9jb2wgaWRlbnRpZmllciBkaWZm ZXJlbnQgdG8gVENQLCBJIHdvdWxkIG1heWJlIGJlIGxlc3MgY29uY2VybmVkLCBidXQgbXkgcG9p bnQgdGhhdCBpdCBzb3VuZHMgZW50aXJlbHkgb3J0aG9nb25hbCB3b3VsZCBzdGlsbCBhcHBseS4N Cg0KQXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvciwgd2hvIGRvZXMgbm90IG93biBydW5uaW5n IGNvZGUgKGkuZS4sIEkgaGF2ZSBub3QgbXVjaCB0byBzYXkgaW4gdGhlIElFVEYgYXQgdGhlIGVu ZCBvZiB0aGUgZGF5KSwgSSBiZWxpZXZlIHRoYXQgdGhlIE1VU1QgcmVxdWlyZW1lbnQgZm9yIOKA nGRldGVjdCBsb3NzIGJ5IGNvdW50aW5nIGluIHRpbWUtYmFzZWQgdW5pdHPigJ0gbXVzdCBlaXRo ZXIgYmUgcmVtb3ZlZCBvciwgbWF5YmUgYXMgYSBjb21wcm9taXNlLCBjb252ZXJ0ZWQgaW50byBh IFNIT1VMRC4NCg0KSSBkbyBhZ3JlZSB0aGF0IFRDUE0gbmVlZHMgdG8gdGhpbmsgYWJvdXQgdGhp cywgcHJvYmFibHkgdG9nZXRoZXIgd2l0aCBUU1ZXRywgYnV0IEkgZmFpbCB0byBzZWUgdGhlIG5l ZWQgb2YgdXJnZW5jeS4gQW5kLCB5ZXMsIHRoaXMgbWF5IHJlc3VsdCBpbiBUQ1BNIHN0YW5kYXJk cyB0cmFjayBzdGFuZGFyZGl6YXRpb24gKGUuZy4sIGEgUkFDSyBzcGVjaWZpY2F0aW9uIGFzIFBT KS4gQnV0IGlmIFRDUE0gc29ydHMgdGhpcyBvdXQsIHdlIG5lZWQgdG8gc29sdmUgdGhlIGlzc3Vl IGZvciBUQ1AgYXMgYSB3aG9sZSBhbmQgbm90IGZvciBvbmUgZXhwZXJpbWVudCBvbmx5Lg0KDQpC VFcsIHlvdXIgY29tbWVudCBvbiB0aGUgZGVsYXkgb2YgYSBQUyBzcGVjaWZpY2F0aW9uIG1pc3Nl cyB0aGUga2V5IHBvaW50LiBGb3JtYWxseSwgVENQTSBjYW4gcHVibGlzaCBhIFBTIFJGQyB3aXRo aW4gZmV3IG1vbnRocy4gQW55IGRlbGF5IG9uIHRvcCBvZiB0aGlzIGNvbWVzIGZyb20gdGhlIGNv bXByZWhlbnNpdmUgdmFsaWRhdGlvbiBhbmQgZmVlZGJhY2sgZnJvbSBpbXBsZW1lbnRlcnMgdGhh dCBpcyBuZWVkZWQgb24gc3RhbmRhcmRzIHRyYWNrLiBJZiB0aGVyZSBpcyBpbmR1c3RyeSBjb25z ZW5zdXMgb24gZG9pbmcgc29tZXRoaW5nIGluIHRoYXQgc3BhY2UsIGFuZCBjb3JyZXNwb25kaW5n IGVuZXJneSwgVENQTSB3aWxsIG5vdCBiZSB0aGUgYm90dGxlbmVjaywgSU1ITy4NCg0KTm90ZSB0 aGF0IGl0IGlzIHBlcmZlY3RseSBmaW5lIGlmIEkgZmluYWxseSBlbmQgdXAgaW4gdGhlIHJvdWdo IHBhcnQgb2YgdGhlIGNvbnNlbnN1cy4NCg0KTWljaGFlbA0KDQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D3C1119rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KaDMNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IsOcYmVyc2NocmlmdCAzIFpjaG4iOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMy41cHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFu LkhUTUxWb3Jmb3JtYXRpZXJ0WmNobg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRp ZXJ0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBWb3Jmb3JtYXRpZXJ0IjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj azt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJl Zm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3Js YWdlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2Uy NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjYNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTI4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5iZXJzY2hyaWZ0M1pjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IsOc YmVyc2NocmlmdCAzIFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiLDnGJlcnNjaHJpZnQgMyI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNEQ3ODt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UzMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20g NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUxODgxMzY0OTsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzODUwMDIzMjQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTg4OTMyNTI4Ow0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTY3ODA4NTE1Njt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iixz ZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo2MDU4ODkzNjk7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTA5ODg1MjQ4O30NCkBsaXN0IGwyOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC10YWIt c3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDgu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6 bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC10YWIt c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjc4NDAzNjg5OTsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MjAxOTA1NjIwMDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6 bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxMDIyMjQ3NjYyOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNTU0OTI0MTM0O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0Omxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJE RSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5bU29ycnkgZm9yIHN0cmlwcGlu ZyB0aGUgb3JpZ2luYWwgdGV4dCwgYnV0IG1haWxtYW4gY29tcGxhaW5zIGFib3V0ICZndDsxMDBL QiBzaXplXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSBCb2IsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRvIG1lLCBub25lIG9mIHRoZXNlIGlz c3VlcyBhcmUgc3BlY2lmaWMgdG8gTDRTLiBUaGV5IGFyZSBub3QgZXZlbiBzcGVjaWZpYyB0byB1 c2Ugb2YgRUNOIG9yIGNvbmdlc3Rpb24gY29udHJvbC4gVG8gbWUsDQogaXQgaXMgYSB2YWxpZCBi dXQgb3J0aG9nb25hbCBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBJIHJlc3VsdCwgd2l0aCBUQ1BNIGNo YWlyIGhhdCBvZmYsIEkgY29udGludWUgdG8gZGlzYWdyZWUgdGhhdCB0aGlzIGJlbG9uZ3MgaW50 byB0aGUgTDRTIGV4cGVyaW1lbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3BlY2lmaWNhbGx5LCBJIGRpc2FncmVl IHRoYXQgdGhpcyBzaGFsbCBiZSBidW5kbGVkIHdpdGggYW4gRUNOIGNvZGVwb2ludCBhbGxvY2F0 aW9uLiBJZiBMNFMgdXNlZCBhbm90aGVyIGlkZW50aWZpZXIsDQogZS5nLiwgYSBwcm90b2NvbCBp ZGVudGlmaWVyIGRpZmZlcmVudCB0byBUQ1AsIEkgd291bGQgbWF5YmUgYmUgbGVzcyBjb25jZXJu ZWQsIGJ1dCBteSBwb2ludCB0aGF0IGl0IHNvdW5kcyBlbnRpcmVseSBvcnRob2dvbmFsIHdvdWxk IHN0aWxsIGFwcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yLCB3aG8g ZG9lcyBub3Qgb3duIHJ1bm5pbmcgY29kZSAoaS5lLiwgSSBoYXZlIG5vdCBtdWNoIHRvIHNheSBp biB0aGUgSUVURiBhdCB0aGUgZW5kIG9mIHRoZQ0KIGRheSksIEkgYmVsaWV2ZSB0aGF0IHRoZSBN VVNUIHJlcXVpcmVtZW50IGZvciDigJxkZXRlY3QgbG9zcyBieSBjb3VudGluZyBpbiB0aW1lLWJh c2VkIHVuaXRz4oCdIG11c3QgZWl0aGVyIGJlIHJlbW92ZWQgb3IsIG1heWJlIGFzIGEgY29tcHJv bWlzZSwgY29udmVydGVkIGludG8gYSBTSE9VTEQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZG8gYWdyZWUgdGhhdCBU Q1BNIG5lZWRzIHRvIHRoaW5rIGFib3V0IHRoaXMsIHByb2JhYmx5IHRvZ2V0aGVyIHdpdGggVFNW V0csIGJ1dCBJIGZhaWwgdG8gc2VlIHRoZSBuZWVkIG9mIHVyZ2VuY3kuIEFuZCwNCiB5ZXMsIHRo aXMgbWF5IHJlc3VsdCBpbiBUQ1BNIHN0YW5kYXJkcyB0cmFjayBzdGFuZGFyZGl6YXRpb24gKGUu Zy4sIGEgUkFDSyBzcGVjaWZpY2F0aW9uIGFzIFBTKS4gQnV0IGlmIFRDUE0gc29ydHMgdGhpcyBv dXQsIHdlIG5lZWQgdG8gc29sdmUgdGhlIGlzc3VlIGZvciBUQ1AgYXMgYSB3aG9sZSBhbmQgbm90 IGZvciBvbmUgZXhwZXJpbWVudCBvbmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CVFcsIHlvdXIgY29tbWVudCBvbiB0 aGUgZGVsYXkgb2YgYSBQUyBzcGVjaWZpY2F0aW9uIG1pc3NlcyB0aGUga2V5IHBvaW50LiBGb3Jt YWxseSwgVENQTSBjYW4gcHVibGlzaCBhIFBTIFJGQyB3aXRoaW4NCiBmZXcgbW9udGhzLiBBbnkg ZGVsYXkgb24gdG9wIG9mIHRoaXMgY29tZXMgZnJvbSB0aGUgY29tcHJlaGVuc2l2ZSB2YWxpZGF0 aW9uIGFuZCBmZWVkYmFjayBmcm9tIGltcGxlbWVudGVycyB0aGF0IGlzIG5lZWRlZCBvbiBzdGFu ZGFyZHMgdHJhY2suIElmIHRoZXJlIGlzIGluZHVzdHJ5IGNvbnNlbnN1cyBvbiBkb2luZyBzb21l dGhpbmcgaW4gdGhhdCBzcGFjZSwgYW5kIGNvcnJlc3BvbmRpbmcgZW5lcmd5LCBUQ1BNIHdpbGwg bm90IGJlIHRoZSBib3R0bGVuZWNrLA0KIElNSE8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5vdGUgdGhhdCBpdCBpcyBw ZXJmZWN0bHkgZmluZSBpZiBJIGZpbmFsbHkgZW5kIHVwIGluIHRoZSByb3VnaCBwYXJ0IG9mIHRo ZSBjb25zZW5zdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D3C1119rznt8114rzntrzd_-- From nobody Mon Jul 22 07:48: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 00102120288; Mon, 22 Jul 2019 07:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESTgVpCHYsiY; Mon, 22 Jul 2019 07:48:42 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 6B09C120276; Mon, 22 Jul 2019 07:48:42 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id r6so34567102qtt.0; Mon, 22 Jul 2019 07:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlaBMUc3W+mJozhtpbGqQlqqbiZZLl/lsMOo7BseYcw=; b=LaRZ9ClelykbkIi1Byy2gL16bA4RfoWifCb/hDSF10GuHxk8vppw67y7cJ+7flnFc8 OGGMYlubA7AsZm8AvbbKoh980KfKJAuMMvUbVzkpFoZqOC6pvMEvQsJ2lFr3zyicMXrI 3qdLGpV+ExdQc1vvZWdwmNsRNtW0TtHYBdQOB6Aqx3D16J/+2yqn2rJn7Z6B5APamx1b 7RA9uvK2u5VvZLQl2/mgwivuinfxq4tNH8UWG6nYGU+AqCv2aoY0RLsVDlgenVaVb9Ma HPbeYAnKLDqgrXd4opqaJUf+NeMNBlT+ZVBfWKHJ5mXazI5eM1gn1E9v103rpcMezvcp 2gUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlaBMUc3W+mJozhtpbGqQlqqbiZZLl/lsMOo7BseYcw=; b=YAFucCg6/GBcuWhV/WM6C/LEelTTKnyi286xYjWHVMxxyK40Qbpj94NECmxgT7puoE SwjvKH1vSqJbeuG4D0nMb8jl9RNklwEV4JG9l2oB4OV9dvMvDkmdeFSD7/dRzUOXxEbV sCJvWIlRQhLc5oETthvzpzhO1+TJlyn3faYdzelU19VbHr7kYrcln/CnjwnT5NA1R+3e vM/2N2KQC96kxJoz7ZkoGjuRwBAI595qdCsnqxUPwpqsa0FbywSDGfsSIWmSpBZ6/egy FNeF1ovrdAmzjc1V/vYrVi46m5TcBf0wElLvm9UFjUEwyeRZb1nYYYTGACIYgsaFDHvs DPLQ== X-Gm-Message-State: APjAAAVzyeq0dmzxv1vDKcK0NmIhSxVl6EwkVMHNvq0xspD3ZdcBAoVF uHzkRi58GEoZr/PMey1W+ZM= X-Google-Smtp-Source: APXvYqx6mTdDfmKRZNvwvU61KpUR1zEHu0/QfNUj0DJy5cOfT6xN3SrluD5PCIrQ4V8jGJ1hNj3Y3g== X-Received: by 2002:a0c:fa8b:: with SMTP id o11mr51210599qvn.6.1563806921551; Mon, 22 Jul 2019 07:48:41 -0700 (PDT) Received: from jonathartonsmbp.lan (173-246-8-242.qc.cable.ebox.net. [173.246.8.242]) by smtp.gmail.com with ESMTPSA id f20sm16099116qkh.15.2019.07.22.07.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 07:48:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3C0A43@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Mon, 22 Jul 2019 10:48:39 -0400 Cc: "alex.burr@ealdwulf.org.uk" , "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> <6EC6417807D9754DA64F3087E2E2E03E2D3C0A43@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:48:44 -0000 > On 21 Jul, 2019, at 9:01 pm, Scharf, Michael = wrote: >=20 > Please be aware that there is also draft-ietf-tcpm-generalized-ecn-04, = which in the current version has a dependency on = draft-ietf-tcpm-accurate-ecn for certain cases. > =20 > Just to state the obvious: These documents are work in progress in = TCPM and TCPM always welcomes feedback. I just skimmed through it to remind myself of certain details. Most of = it only applies once AccECN has completed negotiation, so the same = arguments apply. I do however note that SYN is described as the most important packet to = protect with ECN, and this is of course sent before AccECN negotiation = has completed. Further, if the SYN-ACK then indicates that AccECN is = *not* supported by the remote end - which would be the case for both an = SCE endpoint and any conventional one - a conservative IW of 1 segment = SHOULD be conservatively selected, with no modification for the = increasingly common IW10 case (the default for current versions of = Linux). This incurs a flow completion time delay of approximately 3 = RTTs, which could be perceptible to end users. A less extreme response may be justified here, given that the strongest = signal that may have been missed by the lack of ECN feedback is a CE = mark, for which the most conservative TCP response is to halve the cwnd. = So for an IW4 sender, the IW should be reduced to 2, and for an IW10 = sender, the IW should be reduced to 5. This would reduce the flow = completion penalty to 1 RTT when encountering a non-AccECN endpoint. - Jonathan Morton From nobody Mon Jul 22 13:29: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 2C3A11200CE for ; Mon, 22 Jul 2019 13:29:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-IMMEW88EBQ for ; Mon, 22 Jul 2019 13:29:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3CA1200A3 for ; Mon, 22 Jul 2019 13:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563827354; bh=DXCXq70CkLbxO/Of6xwnjaTaEKov17iFLqBn4iHjw5U=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=itzu+YTMATmnjy0VSzy4YAzpbUQJtUPzesZ+clxvyHIuGJ2exDqB7tIlh7uJoFwoG DNoW6AgDY1jTPdOuZ9QatVf8GPoD7NLx6GPKSQoMQnkjy7Yu7+MGC4gEvWfhlf4HNd gqZm6YfSuReh8QS/ykSzWVX6AcINHz+hw+Z/unJU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [31.133.136.206] ([31.133.136.206]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LdKs1-1iGVD02b4b-00iQkT; Mon, 22 Jul 2019 22:24:03 +0200 To: Yuchung Cheng , Marc Cc: "tcpm@ietf.org Extensions" References: From: "Scheffenegger, Richard" Message-ID: Date: Mon, 22 Jul 2019 16:23:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:bf4buxSezGAS3U/c6f0Ujuh04S4BDRqQdcUYhcFZm7F+YP1+YSD WX4ONdea8t7c1bMzFnWoxUsv35mvwJHoF61E/yIiFiEBK+MfVyq/R9obusPwiUIIeYm8H8n E3tlf2T3DakcCu3wxRWERK0/xLyIOKm2pw1H2En40V/lAyIaSR6cSDZP8to7yGWTIzYSI9A I/a90ZoiGP60aSbhhXzGg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Jge6AN7TpSE=:eP160HLdz+2ILImFeLFJPc rX67YFLTDU+060jQQ+0LrkGhG5PClzpJQ/GaCh7japeqN4ZUhR6qZ15Nw6aPi2E52wG7SDbVU aRBPl2tTx1KUmWRPv0U5C/yQZqf66lPYnemfPrcSihKGiQhOvnxphC5LcbJVvtmREbqe2Qhch FRuuFNYKJbtcLyu/zlEVd9F7G2olkY4gBLM2/+giz1HB0SUHZOjd+AJ40aBiMy7d1wiWAWFhK /BNPW8ngbCxumsnBhvsucKW7gWizqHhrJDJ41u3q7o5PKZGz891jD3zh215N6YVidDL488zwc 6F3nsG8++ImzciWC0Z3wE2d09Cq34f6bIEeGHAEDO6FaERtrtU/UsVIt6tP2CU0w9XIIYXhxq M0FKlcEMmbTl6eLfOJl9hfKF+u0+LMtxxIpDquIV7oJHHP8fz/DQNeI79KjV2YR34RZF/uHOU YnmJoEtKSdITKtqci4xAj44kWkR0wSw1O0OfUyGeh/ibJ/HYzznnAQpT+oQIseahXI5gv6BJP wWFrBqCeMpBi73Ot5lQjL2oTwdei1CbYBqXXSJvlL5Gz0Kfb/VquY4Gl5jPvecbLyT35mQ8gI v7HaDEPd3kfIuClGU/vqfMQMg7ySu6jWIibj9tytNvDoaMVLFAZmHZdYK1zx+G4GcPolbib6f sbZuSsW7wRGqPTz2PtXvfge9Ql/3snK3cxRL8iqbn4qikGnWu9YM0d9PbKyioA2xRglVcCb3B +WAx+NANZJsF2M01PH89POdxKxnA7ZbKxdvUWNRCXi+0i6HD3ashwKS4R8UO+CpmaxFnocDHt L5J1Yz7xfVw0BsxPCLWO1wI9XPNjWk3TrsrlUMHBPGOtH6ivqINm8QLmjEYWQr1w/5tTtFa7G eKX+wL/dUXSTGhknqejcBL/FUO++zNrUISF4qg7hHBu/mKvqHzsZwgb+wp2bDG8LdES8qM5ys kdS7VZtkFsIORvYhuUTQtamTn+RU1Bh+qQG5Ta+VJwTLbi3YSXyFFO92KHkcp93xe+kOWjc5a CMZx4CCPiPRZZJYb9ReiaC21MCK0oZqh4rNh2Sul9smFglP/ieJPAcobUGx23vBIGiGZP85n+ 6GYZs+2/lsVD/U= Archived-At: Subject: Re: [tcpm] tcp window size X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 22 Jul 2019 20:29:19 -0000 Marc, remember that in effect, the smaller between the sender's send buffer, and the receiver's announced receive window can be used at a maximum, since the sender has to hold on to any data until it receives positive confirmation of delivery - in case the data has to be retransmitted after a packet drop... Regards, Richard Am 20.05.2019 um 12:53 schrieb Yuchung Cheng: > On Mon, May 20, 2019 at 9:23 AM Marc wrote: >> >> Hello experts, >> >> I've been trying to find definitive information about tcp window size >> negotiation, and if it exists at all. >> >> Take a browser that downloads a file (receiver) and a webserver (sender= ). If >> - both sender and receiver support window scaling >> - the receiver advertises a TCP winsize of 256KB >> - the sender advertises a window size of 32KB >> - the sender has enough space in its TCP send buffer >> (/proc/sys/net/ipv4/tcp_wmem on linux) >> >> How much 'outstanding unacked data' is the sender allowed to have, >> 32KB or 256KB ? >> >> I can't see any logic for it being limited to the window size of the >> sender (32KB), I think it depends on both the receiver winsize and the >> sender TCP Send Buffer Size, but I need to be sure. >> >> Reading https://tools.ietf.org/html/rfc793 also suggests there is no >> such thing like window size 'negotiation' and each end of a TCP >> connection just advertises its own to indicate how much data it can >> receive, independently. >> >> Is that correct ? > That's correct. It's FYI not negotiated. >> >> Thanks! >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Jul 22 15:48: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 1BAB712006B for ; Mon, 22 Jul 2019 15:48:37 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbWfGOeYPVIa for ; Mon, 22 Jul 2019 15:48:33 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820129.outbound.protection.outlook.com [40.107.82.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167F1120094 for ; Mon, 22 Jul 2019 15:48:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DnlrRxIZrt4aj5YkyDd24QL6vREk10rrZ+u7I0dXFY0Y14GUgu8nETxv5w0CEoG9DM15S39CxY98q3Uq+5//GGim50bTLbMKLskjiP+OV2ZOzQcaJye4T4z3a15qeFwWRFRajp8g4JCHAl7sdxaSTdADtKCW9AoKCYQccQzLeSfeAcmhVTd3+3y+QPCcBvs7kphqxlNbYIsep74OdX2VleXjvlevGC7IJC9H6MZ5fqwV2+c6KDLmpNYxFI+EutCQzgm9DWWkO5mdDkOELEbLOCQK9HjeSDOVMFgr1wtRc3UW8+ZdwnPQU4Mysd+afjHJ4wXPCQptUkdrYirazYdejw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z+VD19N2s6+xVffEBoyeKDLNB5x+nTc2AdgxZykOW7I=; b=RqEnqd4PrKjPiyMSk8e1oOKAlGf2zC4CYpFKgplPCO688cP/68LX6mLGZadHsSRYXcYraiVxOoqdUySDTJWlzZyKn+iWoHp8107Vv+KH15/psl+HEcCeDrgT/Y63yGdMi9zULlm4eVgpYjB9XgN1HfgMBrJgiK91VEfyENdkD4rZKGiXC+puoS8TAnd98PJt8eR5XRWkRwkmibRolnC7tMou1WCoYRqU9glUfCJzLsXymkS3rOXvYf//7fWQ/pjq24z9LCaaKffW1gVQN1cTZnqKK4Kx3jCieNG5KyvWqu6N7cRbfRzqWTWuD0EPl1XKAfO5TGJKrWMSLyJYJUIyig== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z+VD19N2s6+xVffEBoyeKDLNB5x+nTc2AdgxZykOW7I=; b=me6rVDrgyNa+MK3d1UoEfRiS+Y1nrXbTzGHfpG+hLCiQAaUqimW0/bCuYdFdEsX4uwTehPcx801TdPK0gH2atatlgl1gbZWr1e604BW6TF2gYBktMYHbHZ6MYkiDkaTHYfszXh3/GJJD2x2BX+TUrwBcRtGIICNiZDDQ9XHYrPc= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0985.namprd21.prod.outlook.com (52.132.146.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.2; Mon, 22 Jul 2019 22:48:31 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab%4]) with mapi id 15.20.2136.000; Mon, 22 Jul 2019 22:48:31 +0000 From: Praveen Balasubramanian To: Neal Cardwell , Praveen Balasubramanian CC: "tcpm@ietf.org" , Matt Olson , Yi Huang Thread-Topic: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt Thread-Index: AQHVNeDXs6wG1Y3E+0uQvV9n53yFv6bBV5MAgAEMkwCAAHXTQIAADLKAgBRsHXA= Date: Mon, 22 Jul 2019 22:48:29 +0000 Message-ID: References: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-22T22:48:28.6872475Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=8356c032-e979-46a7-a376-d9421e72cae0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:9:6c75:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e881fc4-5a39-434c-59b3-08d70ef6b88b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB0985; x-ms-traffictypediagnostic: MW2PR2101MB0985:|MW2PR2101MB0985: x-ms-exchange-transport-forked: True x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(396003)(39860400002)(366004)(346002)(199004)(189003)(13464003)(54094003)(476003)(25786009)(790700001)(66476007)(66556008)(64756008)(66446008)(6116002)(966005)(606006)(5660300002)(14454004)(76116006)(66946007)(229853002)(11346002)(33656002)(446003)(86362001)(256004)(14444005)(15650500001)(2420400007)(99286004)(19627235002)(52536014)(2906002)(22452003)(316002)(54906003)(110136005)(4326008)(7696005)(68736007)(6246003)(107886003)(8936002)(81166006)(81156014)(76176011)(71190400001)(53936002)(74316002)(7110500001)(55016002)(71200400001)(236005)(54896002)(9686003)(6306002)(486006)(7736002)(6436002)(186003)(10290500003)(8676002)(8990500004)(46003)(102836004)(6506007)(53546011)(478600001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0985; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: e6qrrfYzcwAextFWchNtlqg0hmtvtA73dEfBw0WPhOZW7kmNGNTfzTv3OaPZ1EoASQuCpUgrQFIZ3MD4GpHigpEWUlrrwucATBEK5PbOkBRUZkEl5gxiDYXUM+CMzHPX4zfNpwiE/5qBq9Qw5BX4aJhCXG1qwt37Swlljhuoc1XuRf3cYxstVWaMmNMKSdgHI/Px3Y0n3SRV8G8p+LSC574/kqmHzwisEMlupaiLf0Gr7Xr56qdmQQbWxVkrMS+mDO/JxYHC+uPx/Su/EOJBixQm5KVXjW6NVRW+bTrilhfOajzLQyG79B+q+mib33KGpOQOIZP21+9eDkkPWB98yjVoemQ/gj2lYXgi32gckdUkSQJh5reQ4Atf/JeMlL030bl4uhYGGj8/FD2xc3g36UqlRxoM29GB63xvYUL2gVU= Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB1049F44BDAA89FC27D4576D8B6C40MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e881fc4-5a39-434c-59b3-08d70ef6b88b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 22:48:31.2770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0985 Archived-At: Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:48:37 -0000 --_000_MW2PR2101MB1049F44BDAA89FC27D4576D8B6C40MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgcHVibGlzaGVkIHRoZSBuZXh0IHJldmlzaW9uIGluY29ycG9yYXRpbmcgY2hhbmdlcyB0byB0 aGUgYWxnb3JpdGhtIGFuZCBzb21lIGVkaXRvcmlhbCBmaXhlcy4NCg0KRnJvbTogTmVhbCBDYXJk d2VsbCA8bmNhcmR3ZWxsQGdvb2dsZS5jb20+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDksIDIwMTkg Mzo1NCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1p Y3Jvc29mdC5jb20+OyB0Y3BtQGlldGYub3JnOyBNYXR0IE9sc29uIDxtYW9sc29uQG1pY3Jvc29m dC5jb20+OyBZaSBIdWFuZyA8aHVhbnlpQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTogW3Rj cG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJhbGFzdWJyYW1hbmlh bi10Y3BtLWh5c3RhcnRwbHVzcGx1cy0wMC50eHQNCg0KT24gVHVlLCBKdWwgOSwgMjAxOSBhdCA2 OjE4IFBNIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KUmUgKDEpLiBHcmVhdCBjYXRjaCBOZWFsLiBUaGF0J3MgYSBidWcgaW4gdGhlIGRyYWZ0IGFu ZCBub3QgaW4gb3VyIGltcGxlbWVudGF0aW9uLiBFdGEgaXMgY29tcHV0ZWQgYmFzZWQgb24gbGFz dFJvdW5kTWluUlRUIGFuZCBub3QgY3VycmVudFJvdW5kTWluUlRULi4gV2Ugd2lsbCBmaXggdGhp cyBpbiBuZXh0IHJldmlzaW9uLg0KDQpHb3QgaXQuIFRoYW5rcyENCg0KV2hhdCB3YXMgdGhlIHJl YXNvbiBmb3IgTGludXggdG8gc3dpdGNoIHRvIGxpZmV0aW1lTWluUlRUPyBPbiBXaWZpIGxpbmtz IFJUVCBkb2VzIGZsdWN0dWF0ZSBhIGxvdC4NCg0KSSdtIG5vdCBzdXJlIHdoYXQgdGhlIG1vdGl2 YXRpb24gd2FzLiBUaGUgIlRhbWluZyB0aGUgRWxlcGhhbnRzIiBwYXBlciBhbmQgZGlzc2VydGF0 aW9uIGJvdGggdXNlIHRoZSBsYXN0Um91bmRNaW5SVFQsIGJ1dCB0aGUgY29kZSB0aGF0IHdhcyBz dWJtaXR0ZWQgdG8gTGludXggKGFlMjdlOThhNTE1MjY1OTU4Mzcgb24gT2N0IDI5IDIwMDgpIHVz ZXMgdGhlICBsaWZldGltZU1pblJUVCwgd2l0aG91dCBhIGNvbW1lbnQgYWJvdXQgdGhlIHJhdGlv bmFsZS4gSSBjYW4gaW1hZ2luZSBib3RoIGFwcHJvYWNoZXMgaGF2aW5nIHByb3MgYW5kIGNvbnMu DQoNClJlICgyKS4gSSBhZ3JlZSB0aGF0IHRoZSBnb2FsIGlzIHRvIGZpbmQgYSBmdW5jdGlvbiB0 aGF0J3MgZmFzdGVyIHRoYW4gQ0EgYW5kIHNsb3dlciB0aGFuIHNsb3cgc3RhcnQuIExTUyB3b3Jr cyB3ZWxsIGluIHByYWN0aWNlLiBGb3IgbG9uZyBsaXZlZCBmbG93cyBvbiBoaWdoIEJEUCBsaW5r cyBpbmNvcnBvcmF0aW5nIHRoZSBDVUJJQyBDQSBlYXJseSBjYW4gaGVscCBhbmQgdGhhdCdzIGEg Z29vZCBpZGVhLiBCdXQgZ2l2ZW4gdGhhdCB0aGlzIGlzIGFuIGluZm9ybWF0aW9uYWwgUkZDIGRl c2NyaWJpbmcgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24sIHdlJ2QgaGF2ZSB0byBleHBlcmlt ZW50IGFuZCBkZXBsb3kgYW55IGNoYW5nZXMgYmVmb3JlIHVwZGF0aW5nIHRoZSB0ZXh0LiBXZSB3 aWxsIGxvb2sgaW50byBpdC4NCg0KTWFrZXMgc2Vuc2UuDQoNCnRoYW5rcywNCm5lYWwNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTmVhbCBDYXJk d2VsbA0KU2VudDogVHVlc2RheSwgSnVseSA5LCAyMDE5IDg6MDcgQU0NClRvOiBQcmF2ZWVuIEJh bGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IHRjcG1AaWV0Zi5vcmc8bWFp bHRvOnRjcG1AaWV0Zi5vcmc+OyBNYXR0IE9sc29uIDxtYW9sc29uQG1pY3Jvc29mdC5jb208bWFp bHRvOm1hb2xzb25AbWljcm9zb2Z0LmNvbT4+DQpTdWJqZWN0OiBSZTogW3RjcG1dIEZXOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3Rh cnRwbHVzcGx1cy0wMC50eHQNCg0KT24gTW9uLCBKdWwgOCwgMjAxOSBhdCA3OjExIFBNIFByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC4uY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MG1pY3Jvc29mdC4uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+DQo+IFdl IHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciBtb2RpZmllZCBzbG93IHN0YXJ0IHVzaW5nIEh5U3RhcnQg YW5kIExpbWl0ZWQgU2xvdyBTdGFydC4gRmVlZGJhY2sgaXMgd2VsY29tZS4NCg0KVGhhbmtzIGZv ciBwb3N0aW5nIHRoaXMgZHJhZnQhICgNCmh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVzcGx1cy0wMCZhbXA7ZGF0YT0w MiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDY2YwMDhjZDRhM2FlNDFlODdlN2QwOGQ3 MDQ3ZjJjMzMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 OTgyODE2NTc4NTIyNTM3JmFtcDtzZGF0YT1HdHREeURZaHczc0clMkJ4REdBRlNlZk1ZZVJ5TmZq ZVVpaDZYVnZiSmE3TVElM0QmYW1wO3Jlc2VydmVkPTA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0taHlzdGFydHBsdXNwbHVzLTAwJmRh dGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2E5ZmM3NjkwYWExNzQzMWU3NGUw MDhkNzA0YzA2NDlkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjk4MzA5NjY4NzMxMjExMSZzZGF0YT1SMmpLenlvY1U0YnYydEhkUzYyazN5QUIyZDNVYWd0 cEtsZkFjNWdkSGdjJTNEJnJlc2VydmVkPTA+DQopDQoNClRoaXMgaXMgYSB2ZXJ5IG5pY2UsIGNs ZWFyIGRvY3VtZW50LCBJTUhPLg0KDQpJIHdhcyBjdXJpb3VzIGFib3V0IGEgY291cGxlIG9mIGl0 ZW1zOg0KDQooMSkgSW4gdGhlIGRyYWZ0IHRoZSBjb25kaXRpb24gZm9yIGV4aXRpbmcgc2xvdyBz dGFydCBpczoNCg0KICAgICAgICAgICAgRXRhID0gY2xhbXAoTUlOX0VUQSwgY3VycmVudFJvdW5k TWluUlRUIC8gOCwgTUFYX0VUQSkNCiAgICAgICAgICAgIGlmIChjdXJyZW50Um91bmRNaW5SVFQg Pj0gKGxhc3RSb3VuZE1pblJUVCArIEV0YSkpDQoNClRoZSB1c2Ugb2YgY3VycmVudFJvdW5kTWlu UlRULzggdG8gY29tcHV0ZSBFdGEgaXMgY291bnRlcmludHVpdGl2ZSB0byBtZSwgYW5kIGlzIGRp ZmZlcmVudCBmcm9tIGJvdGggdGhlIEh5c3RhcnQgcGFwZXIgYW5kIHRoZSBMaW51eCBDVUJJQyBI eXN0YXJ0IGltcGxlbWVudGF0aW9uIGZyb20gdGhlIENVQklDIGF1dGhvcnMuDQoNClRoZSBIeXN0 YXJ0IHBhcGVyIHVzZWQgKG1vZGlmaWVkIHBzZXVkb2NvZGUpOg0KDQogIGlmIChjdXJyZW50Um91 bmRNaW5SVFQ+IGxhc3RSb3VuZE1pblJUVCArIGNsYW1wKGxhc3RSb3VuZE1pblJUVCAvIDE2KSkN Cg0KVGhlIExpbnV4IGltcGxlbWVudGF0aW9uIGZyb20gdGhlIEh5c3RhcnQgYXV0aG9yIFNhbmd0 YWUgSGEgaW4gMjAwOCB1c2VkIHRoZSBhcHByb2FjaCAocHNldWRvY29kZSk6DQoNCiAgaWYgKGN1 cnJlbnRSb3VuZE1pblJUVD4gbGlmZXRpbWVNaW5SVFQgKyBjbGFtcChsaWZldGltZU1pblJUVCAv IDE2KSkNCg0KRXJpYyBEdW1hemV0IGNoYW5nZWQgdGhlIExpbnV4IGFwcHJvYWNoIGluIDIwMTQg dG8gdXNlIGEgZGlmZmVyZW50IGNvbnN0YW50IHNjYWxpbmcgZmFjdG9yIChhbHNvIHBzZXVkb2Nv ZGUpOg0KDQogIGlmIChjdXJyZW50Um91bmRNaW5SVFQ+IGxpZmV0aW1lTWluUlRUICsgY2xhbXAo bGlmZXRpbWVNaW5SVFQgLyA4KSkNCg0KSSBhbSBjdXJpb3VzIGFib3V0IHRoZSByYXRpb25hbGUg Zm9yOg0KDQooYSkgVXNpbmcgYW4gUlRUIHRocmVzaG9sZCBmb3IgZXhpdGluZyBzbG93LXN0YXJ0 IHRoYXQgaXMgYmFzZWQgb24gY3VycmVudFJvdW5kTWluUlRULzgsIHJhdGhlciB0aGFuIGJlaW5n IHB1cmVseSBhIGZ1bmN0aW9uIG9mIHRoZSBSVFQgdmFsdWVzIGZyb20gcHJldmlvdXMgcm91bmRz IChhcyBpbiB0aGUgSHlzdGFydCBwYXBlcikgb3IgdGhlIGxpZmV0aW1lIG9mIHRoZSBjb25uZWN0 aW9uIChhcyBpbiBMaW51eCk/DQoNCihiKSBVc2luZyBhIGZ1bmN0aW9uIG9mIGxhc3RSb3VuZE1p blJUVCBhbmQgY3VycmVudFJvdW5kTWluUlRUIGZvciB0aGUgZXhpdCB0aHJlc2hvbGQsIHJhdGhl ciB0aGFuIGEgZnVuY3Rpb24gb2YgdGhlIG1pbiBSVFQgb3ZlciB0aGUgbGlmZXRpbWUgb2YgdGhl IGNvbm5lY3Rpb24gKCJsaWZldGltZU1pblJUVCIgaW4gbXkgcHNldWRvY29kZSwgYWJvdmUpPw0K SXMgdGhlIHJhdGlvbmFsZSBoZXJlIHBhcnRseSB0byBkZWFsIHdpdGggZmx1Y3R1YXRpb25zIGlu IFJUVCBkdWUgdG8gY2VsbHVsYXIvd2lmaS9ET0NTSVMgcGF0aHMgd2l0aCBub2lzeSBSVFRzPw0K DQpBbnkgYmFja2dyb3VuZCBvbiB0aGUgbW90aXZhdGlvbiB3b3VsZCBiZSBpbnRlcmVzdGluZyB0 byBoZWFyLCBvciBwZXJoYXBzIHRvIGluY2x1ZGUgaW4gZnV0dXJlIGRyYWZ0cy4NCg0KKDIpIFRo ZSBMaW1pdGVkIFNsb3ctU3RhcnQgYXBwcm9hY2ggZGVzY3JpYmVkIGluIHRoZSBkcmFmdCBzZWVt cyB0byBib2lsIGRvd24gdG8gaW5jcmVhc2luZyBjd25kIGJ5IHJvdWdobHkgc3N0aHJlc2gvNCBl YWNoIHJvdW5kIHRyaXAuDQpJdCBkb2VzIHNlZW0gbGlrZSB0aGF0IHdvdWxkIGJlIGNvbnNpZGVy YWJseSBmYXN0ZXIgdGhhbiBSZW5vIG9yIENVQklDIHdvdWxkIG5vcm1hbGx5IGdyb3cgaW4gY29u Z2VzdGlvbiBhdm9pZGFuY2UsIGZvciB0aGUgZmlyc3QgZmV3IHNlY29uZHMgYWZ0ZXIgZXhpdGlu ZyBzbG93IHN0YXJ0LiBCdXQgaXQgZG9lcyBzZWVtIHRvIGJlIGVzc2VudGlhbGx5IGp1c3QgYSBs YXJnZSBhZGRpdGl2ZSBpbmNyZWFzZS4gQW5kIHNvIGl0IHdvdWxkIHNlZW0gdGhhdCBpZiBDVUJJ QyB3ZXJlIGluc3RlYWQgaW4gaXRzIG5hdGl2ZSBDVUJJQyBjb25nZXN0aW9uIGF2b2lkYW5jZSBp bnN0ZWFkIG9mIGxpbWl0ZWQgc2xvdy1zdGFydCwgdGhlbiBDVUJJQyB3b3VsZCBldmVudHVhbGx5 IChlLmcuIGFmdGVyIGEgZmV3IHNlY29uZHMpIHRlbmQgdG8gcmVhY2ggdGhlIHJhcGlkLWdyb3d0 aCBjb252ZXggcG9ydGlvbiBvZiB0aGUgY3ViaWMgY3VydmUsIGFuZCBldmVudHVhbGx5IGdyb3cg bXVjaCBmYXN0ZXIgKGV2ZW50dWFsbHkgcmVhY2hpbmcgZXhwb25lbnRpYWwgZ3Jvd3RoIG9mIDEu NXggcGVyIHJvdW5kIHRyaXApLiBJIHdvbmRlciBpZiBpdCB3b3VsZCBiZSBhZHZhbnRhZ2VvdXMg Zm9yIENVQklDIGNvbm5lY3Rpb25zIGV4aXRpbmcgSHlTdGFydCsrIHRvIHVzZSBhICBzdHJhdGVn eSBvZiBncm93aW5nIHRoZSBjd25kIHVzaW5nIHRoZSBtYXhpbXVtIG9mIHRoZSBzY2hlZHVsZSBj YWxjdWxhdGVkIHVzaW5nIGxpbWl0ZWQgc2xvdy1zdGFydCBhbmQgdGhlIHNjaGVkdWxlIGNhbGN1 bGF0ZWQgdXNpbmcgdGhlIG5vcm1hbCBDVUJJQyBjb25nZXN0aW9uIGF2b2lkYW5jZSBsb2dpYy4g VGhhdCBzZWVtcyBsaWtlIGl0IG1pZ2h0IGhhdmUgdGhlIHBvdGVudGlhbCB0byBtaXRpZ2F0ZSBw ZXJmb3JtYW5jZSBpc3N1ZXMgZm9yIENVQklDIGNvbm5lY3Rpb25zIHRoYXQgc3B1cmlvdXNseSBl eGl0IHNsb3ctc3RhcnQgdG9vIHNvb24/DQoNCmJlc3QgcmVnYXJkcywNCm5lYWwNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBs aXN0DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJh dmIlNDBtaWNyb3NvZnQuY29tJTdDY2YwMDhjZDRhM2FlNDFlODdlN2QwOGQ3MDQ3ZjJjMzMlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTgyODE2NTc4NTIy NTM3JmFtcDtzZGF0YT0wU2pxdDJGV3oxcktUcXBseSUyRk1KSXpHZWxleW9sV1dOT2JMNThLZEN4 bTQlM0QmYW1wO3Jlc2VydmVkPTA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGdGNwbSZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NhOWZj NzY5MGFhMTc0MzFlNzRlMDA4ZDcwNGMwNjQ5ZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzY5ODMwOTY2ODczMTIxMTEmc2RhdGE9VG9SNnFhU3VoS0tCR2hF SHdmcHdUZk9vdmtLS1RPQ0hSQm8ydDU5VjFLNCUzRCZyZXNlcnZlZD0wPg0K --_000_MW2PR2101MB1049F44BDAA89FC27D4576D8B6C40MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSBwdWJsaXNoZWQgdGhlIG5leHQgcmV2aXNpb24gaW5jb3Jwb3JhdGluZyBjaGFuZ2VzIHRvIHRo ZSBhbGdvcml0aG0gYW5kIHNvbWUgZWRpdG9yaWFsIGZpeGVzLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBOZWFsIENhcmR3ZWxsICZsdDtuY2FyZHdlbGxAZ29vZ2xlLmNv bSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgOSwgMjAxOSAzOjU0IFBNPGJy Pg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyB0Y3BtQGlldGYub3JnOyBNYXR0 IE9sc29uICZsdDttYW9sc29uQG1pY3Jvc29mdC5jb20mZ3Q7OyBZaSBIdWFuZyAmbHQ7aHVhbnlp QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0taHlz dGFydHBsdXNwbHVzLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgNjoxOCBQTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAm bHQ7cHJhdmI9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+ NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmUg KDEpLiBHcmVhdCBjYXRjaCBOZWFsLiBUaGF0J3MgYSBidWcgaW4gdGhlIGRyYWZ0IGFuZCBub3Qg aW4gb3VyIGltcGxlbWVudGF0aW9uLiBFdGEgaXMgY29tcHV0ZWQgYmFzZWQgb24gbGFzdFJvdW5k TWluUlRUIGFuZCBub3QgY3VycmVudFJvdW5kTWluUlRULi4gV2Ugd2lsbCBmaXggdGhpcyBpbiBu ZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+R290IGl0LiBUaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgd2FzIHRoZSByZWFzb24g Zm9yIExpbnV4IHRvIHN3aXRjaCB0byBsaWZldGltZU1pblJUVD8gT24gV2lmaSBsaW5rcyBSVFQg ZG9lcyBmbHVjdHVhdGUgYSBsb3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1cmUgd2hhdCB0aGUgbW90aXZhdGlv biB3YXMuIFRoZSAmcXVvdDtUYW1pbmcgdGhlIEVsZXBoYW50cyZxdW90OyBwYXBlciBhbmQgZGlz c2VydGF0aW9uIGJvdGggdXNlIHRoZSZuYnNwO2xhc3RSb3VuZE1pblJUVCwgYnV0IHRoZSBjb2Rl IHRoYXQgd2FzIHN1Ym1pdHRlZCB0byBMaW51eCAoYWUyN2U5OGE1MTUyNjU5NTgzNyBvbiBPY3Qg MjkgMjAwOCkgdXNlcyB0aGUmbmJzcDsmbmJzcDtsaWZldGltZU1pblJUVCwgd2l0aG91dCBhIGNv bW1lbnQNCiBhYm91dCB0aGUgcmF0aW9uYWxlLiBJIGNhbiBpbWFnaW5lIGJvdGggYXBwcm9hY2hl cyBoYXZpbmcgcHJvcyBhbmQgY29ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmUgKDIpLiBJIGFncmVlIHRoYXQgdGhlIGdvYWwg aXMgdG8gZmluZCBhIGZ1bmN0aW9uIHRoYXQncyBmYXN0ZXIgdGhhbiBDQSBhbmQgc2xvd2VyIHRo YW4gc2xvdyBzdGFydC4gTFNTIHdvcmtzIHdlbGwgaW4gcHJhY3RpY2UuIEZvciBsb25nIGxpdmVk IGZsb3dzIG9uIGhpZ2ggQkRQIGxpbmtzIGluY29ycG9yYXRpbmcgdGhlIENVQklDIENBIGVhcmx5 IGNhbiBoZWxwIGFuZCB0aGF0J3MgYSBnb29kIGlkZWEuIEJ1dA0KIGdpdmVuIHRoYXQgdGhpcyBp cyBhbiBpbmZvcm1hdGlvbmFsIFJGQyBkZXNjcmliaW5nIHRoZSBjdXJyZW50IGltcGxlbWVudGF0 aW9uLCB3ZSdkIGhhdmUgdG8gZXhwZXJpbWVudCBhbmQgZGVwbG95IGFueSBjaGFuZ2VzIGJlZm9y ZSB1cGRhdGluZyB0aGUgdGV4dC4gV2Ugd2lsbCBsb29rIGludG8gaXQuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWtlcyBzZW5z ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+bmVhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogdGNwbSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRjcG0tYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBOZWFsIENhcmR3ZWxs PGJyPg0KU2VudDogVHVlc2RheSwgSnVseSA5LCAyMDE5IDg6MDcgQU08YnI+DQpUbzogUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+OyBNYXR0IE9sc29uICZsdDs8YSBocmVm PSJtYWlsdG86bWFvbHNvbkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFvbHNvbkBt aWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3RjcG1dIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRw bHVzcGx1cy0wMC50eHQ8YnI+DQo8YnI+DQpPbiBNb24sIEp1bCA4LCAyMDE5IGF0IDc6MTEgUE0g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jv c29mdC4uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuLmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIHN1 Ym1pdHRlZCBhIGRyYWZ0IGZvciBtb2RpZmllZCBzbG93IHN0YXJ0IHVzaW5nIEh5U3RhcnQgYW5k IExpbWl0ZWQgU2xvdyBTdGFydC4gRmVlZGJhY2sgaXMgd2VsY29tZS48YnI+DQo8YnI+DQpUaGFu a3MgZm9yIHBvc3RpbmcgdGhpcyBkcmFmdCEgKDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz LmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3RhcnRwbHVz cGx1cy0wMCZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYTlmYzc2 OTBhYTE3NDMxZTc0ZTAwOGQ3MDRjMDY0OWQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2OTgzMDk2Njg3MzEyMTExJmFtcDtzZGF0YT1SMmpLenlvY1U0YnYy dEhkUzYyazN5QUIyZDNVYWd0cEtsZkFjNWdkSGdjJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtYmFsYXN1YnJh bWFuaWFuLXRjcG0taHlzdGFydHBsdXNwbHVzLTAwJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDcHJh dmIlNDBtaWNyb3NvZnQuY29tJTdDY2YwMDhjZDRhM2FlNDFlODdlN2QwOGQ3MDQ3ZjJjMzMlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTgyODE2NTc4NTIy NTM3JmFtcDthbXA7c2RhdGE9R3R0RHlEWWh3M3NHJTJCeERHQUZTZWZNWWVSeU5mamVVaWg2WFZ2 YkphN01RJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQopPGJyPg0KPGJyPg0KVGhpcyBp cyBhIHZlcnkgbmljZSwgY2xlYXIgZG9jdW1lbnQsIElNSE8uPGJyPg0KPGJyPg0KSSB3YXMgY3Vy aW91cyBhYm91dCBhIGNvdXBsZSBvZiBpdGVtczo8YnI+DQo8YnI+DQooMSkgSW4gdGhlIGRyYWZ0 IHRoZSBjb25kaXRpb24gZm9yIGV4aXRpbmcgc2xvdyBzdGFydCBpczo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBFdGEgPSBjbGFtcChNSU5fRVRB LCBjdXJyZW50Um91bmRNaW5SVFQgLyA4LCBNQVhfRVRBKTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlmIChjdXJyZW50Um91bmRNaW5SVFQgJmd0Oz0gKGxh c3RSb3VuZE1pblJUVCAmIzQzOyBFdGEpKTxicj4NCjxicj4NClRoZSB1c2Ugb2YgY3VycmVudFJv dW5kTWluUlRULzggdG8gY29tcHV0ZSBFdGEgaXMgY291bnRlcmludHVpdGl2ZSB0byBtZSwgYW5k IGlzIGRpZmZlcmVudCBmcm9tIGJvdGggdGhlIEh5c3RhcnQgcGFwZXIgYW5kIHRoZSBMaW51eCBD VUJJQyBIeXN0YXJ0IGltcGxlbWVudGF0aW9uIGZyb20gdGhlIENVQklDIGF1dGhvcnMuPGJyPg0K PGJyPg0KVGhlIEh5c3RhcnQgcGFwZXIgdXNlZCAobW9kaWZpZWQgcHNldWRvY29kZSk6PGJyPg0K PGJyPg0KJm5ic3A7IGlmIChjdXJyZW50Um91bmRNaW5SVFQmZ3Q7IGxhc3RSb3VuZE1pblJUVCAm IzQzOyBjbGFtcChsYXN0Um91bmRNaW5SVFQgLyAxNikpPGJyPg0KPGJyPg0KVGhlIExpbnV4IGlt cGxlbWVudGF0aW9uIGZyb20gdGhlIEh5c3RhcnQgYXV0aG9yIFNhbmd0YWUgSGEgaW4gMjAwOCB1 c2VkIHRoZSBhcHByb2FjaCAocHNldWRvY29kZSk6PGJyPg0KPGJyPg0KJm5ic3A7IGlmIChjdXJy ZW50Um91bmRNaW5SVFQmZ3Q7IGxpZmV0aW1lTWluUlRUICYjNDM7IGNsYW1wKGxpZmV0aW1lTWlu UlRUIC8gMTYpKTxicj4NCjxicj4NCkVyaWMgRHVtYXpldCBjaGFuZ2VkIHRoZSBMaW51eCBhcHBy b2FjaCBpbiAyMDE0IHRvIHVzZSBhIGRpZmZlcmVudCBjb25zdGFudCBzY2FsaW5nIGZhY3RvciAo YWxzbyBwc2V1ZG9jb2RlKTo8YnI+DQo8YnI+DQombmJzcDsgaWYgKGN1cnJlbnRSb3VuZE1pblJU VCZndDsgbGlmZXRpbWVNaW5SVFQgJiM0MzsgY2xhbXAobGlmZXRpbWVNaW5SVFQgLyA4KSk8YnI+ DQo8YnI+DQpJIGFtIGN1cmlvdXMgYWJvdXQgdGhlIHJhdGlvbmFsZSBmb3I6PGJyPg0KPGJyPg0K KGEpIFVzaW5nIGFuIFJUVCB0aHJlc2hvbGQgZm9yIGV4aXRpbmcgc2xvdy1zdGFydCB0aGF0IGlz IGJhc2VkIG9uIGN1cnJlbnRSb3VuZE1pblJUVC84LCByYXRoZXIgdGhhbiBiZWluZyBwdXJlbHkg YSBmdW5jdGlvbiBvZiB0aGUgUlRUIHZhbHVlcyBmcm9tIHByZXZpb3VzIHJvdW5kcyAoYXMgaW4g dGhlIEh5c3RhcnQgcGFwZXIpIG9yIHRoZSBsaWZldGltZSBvZiB0aGUgY29ubmVjdGlvbiAoYXMg aW4gTGludXgpPzxicj4NCjxicj4NCihiKSBVc2luZyBhIGZ1bmN0aW9uIG9mIGxhc3RSb3VuZE1p blJUVCBhbmQgY3VycmVudFJvdW5kTWluUlRUIGZvciB0aGUgZXhpdCB0aHJlc2hvbGQsIHJhdGhl ciB0aGFuIGEgZnVuY3Rpb24gb2YgdGhlIG1pbiBSVFQgb3ZlciB0aGUgbGlmZXRpbWUgb2YgdGhl IGNvbm5lY3Rpb24gKCZxdW90O2xpZmV0aW1lTWluUlRUJnF1b3Q7IGluIG15IHBzZXVkb2NvZGUs IGFib3ZlKT88YnI+DQpJcyB0aGUgcmF0aW9uYWxlIGhlcmUgcGFydGx5IHRvIGRlYWwgd2l0aCBm bHVjdHVhdGlvbnMgaW4gUlRUIGR1ZSB0byBjZWxsdWxhci93aWZpL0RPQ1NJUyBwYXRocyB3aXRo IG5vaXN5IFJUVHM/PGJyPg0KPGJyPg0KQW55IGJhY2tncm91bmQgb24gdGhlIG1vdGl2YXRpb24g d291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciwgb3IgcGVyaGFwcyB0byBpbmNsdWRlIGluIGZ1 dHVyZSBkcmFmdHMuPGJyPg0KPGJyPg0KKDIpIFRoZSBMaW1pdGVkIFNsb3ctU3RhcnQgYXBwcm9h Y2ggZGVzY3JpYmVkIGluIHRoZSBkcmFmdCBzZWVtcyB0byBib2lsIGRvd24gdG8gaW5jcmVhc2lu ZyBjd25kIGJ5IHJvdWdobHkgc3N0aHJlc2gvNCBlYWNoIHJvdW5kIHRyaXAuPGJyPg0KSXQgZG9l cyBzZWVtIGxpa2UgdGhhdCB3b3VsZCBiZSBjb25zaWRlcmFibHkgZmFzdGVyIHRoYW4gUmVubyBv ciBDVUJJQyB3b3VsZCBub3JtYWxseSBncm93IGluIGNvbmdlc3Rpb24gYXZvaWRhbmNlLCBmb3Ig dGhlIGZpcnN0IGZldyBzZWNvbmRzIGFmdGVyIGV4aXRpbmcgc2xvdyBzdGFydC4gQnV0IGl0IGRv ZXMgc2VlbSB0byBiZSBlc3NlbnRpYWxseSBqdXN0IGEgbGFyZ2UgYWRkaXRpdmUgaW5jcmVhc2Uu IEFuZCBzbyBpdCB3b3VsZCBzZWVtIHRoYXQNCiBpZiBDVUJJQyB3ZXJlIGluc3RlYWQgaW4gaXRz IG5hdGl2ZSBDVUJJQyBjb25nZXN0aW9uIGF2b2lkYW5jZSBpbnN0ZWFkIG9mIGxpbWl0ZWQgc2xv dy1zdGFydCwgdGhlbiBDVUJJQyB3b3VsZCBldmVudHVhbGx5IChlLmcuIGFmdGVyIGEgZmV3IHNl Y29uZHMpIHRlbmQgdG8gcmVhY2ggdGhlIHJhcGlkLWdyb3d0aCBjb252ZXggcG9ydGlvbiBvZiB0 aGUgY3ViaWMgY3VydmUsIGFuZCBldmVudHVhbGx5IGdyb3cgbXVjaCBmYXN0ZXIgKGV2ZW50dWFs bHkNCiByZWFjaGluZyBleHBvbmVudGlhbCBncm93dGggb2YgMS41eCBwZXIgcm91bmQgdHJpcCku IEkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIGFkdmFudGFnZW91cyBmb3IgQ1VCSUMgY29ubmVjdGlv bnMgZXhpdGluZyBIeVN0YXJ0JiM0MzsmIzQzOyB0byB1c2UgYSZuYnNwOyBzdHJhdGVneSBvZiBn cm93aW5nIHRoZSBjd25kIHVzaW5nIHRoZSBtYXhpbXVtIG9mIHRoZSBzY2hlZHVsZSBjYWxjdWxh dGVkIHVzaW5nIGxpbWl0ZWQgc2xvdy1zdGFydCBhbmQgdGhlIHNjaGVkdWxlDQogY2FsY3VsYXRl ZCB1c2luZyB0aGUgbm9ybWFsIENVQklDIGNvbmdlc3Rpb24gYXZvaWRhbmNlIGxvZ2ljLiBUaGF0 IHNlZW1zIGxpa2UgaXQgbWlnaHQgaGF2ZSB0aGUgcG90ZW50aWFsIHRvIG1pdGlnYXRlIHBlcmZv cm1hbmNlIGlzc3VlcyBmb3IgQ1VCSUMgY29ubmVjdGlvbnMgdGhhdCBzcHVyaW91c2x5IGV4aXQg c2xvdy1zdGFydCB0b28gc29vbj88YnI+DQo8YnI+DQpiZXN0IHJlZ2FyZHMsPGJyPg0KbmVhbDxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KdGNwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0YT0wMiU3 QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYTlmYzc2OTBhYTE3NDMxZTc0ZTAwOGQ3MDRj MDY0OWQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTgz MDk2Njg3MzEyMTExJmFtcDtzZGF0YT1Ub1I2cWFTdWhLS0JHaEVId2Zwd1RmT292a0tLVE9DSFJC bzJ0NTlWMUs0JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7YW1wO2RhdGE9MDIlN0Mw MSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2NmMDA4Y2Q0YTNhZTQxZTg3ZTdkMDhkNzA0N2Yy YzMzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4Mjgx NjU3ODUyMjUzNyZhbXA7YW1wO3NkYXRhPTBTanF0MkZXejFyS1RxcGx5JTJGTUpJekdlbGV5b2xX V05PYkw1OEtkQ3htNCUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW2PR2101MB1049F44BDAA89FC27D4576D8B6C40MW2PR2101MB1049_-- From nobody Mon Jul 22 16:49: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 BCFA1120048 for ; Mon, 22 Jul 2019 16:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 csJ_41fj-2aX for ; Mon, 22 Jul 2019 16:49:38 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 E6CD5120045 for ; Mon, 22 Jul 2019 16:49:37 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id d79so29792630qke.11 for ; Mon, 22 Jul 2019 16:49:37 -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=hbld2l0dYaTrDzeulyMKKCmMboiz9EwcaEhi+/qi2uw=; b=xW3+LcKxhrzoA0Tel54f8kXYAz9BHLTYE1HwSRdAhTRqeyp+cc6GFFXOlBXEfGiqeY 8HyBDQM1ymQRsXHAryApEREIWLHnJpPv1Xya6hK/8aCv1d9Ja3Wks96iC0rj3qpc/NIk b85ZloA1ptAfo3RYhkzNTxQo2k6XBWP02iOAPX8qkCbh5Aw7vW4Od6/cQtS6sIz9ExV4 qmraY9fkisW7Jb9xkEhZtAqce2UdemJcFKSiXljKt8ptDX+8Xuh3DUjB/DXuT5zCtV2M SPNzmmqvzpW60Hj5mk79doMs7r3ND9kzqsAZh0gRAI4L/tmy1wOf7+WIV1/gvWw5r3Og hb2A== 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=hbld2l0dYaTrDzeulyMKKCmMboiz9EwcaEhi+/qi2uw=; b=XRxRyIcUNfQ1mt6C37TxAPPGM6IHryvM1XKwcfv933757WfXq+tv068jhmZCRg88mn uZiDxBArivRtx4A2ZOi2lV3rBawJjfOBjX2DLA7wYNM0WvISUgqcLJl/srvwm1E0NgHl Ab0cqhSz2k9ZdIBsf2aN+qCm2C9JqL0B2P0yG0J2kjtsH5WoKij7FYVrpeKcaml5tON5 4QpGkXUJmYDAnbk5KMv4BRWabLSawNqvJKlvqSG6lP5K9+hMtuNYuARVfEZVN8gPqWll h6aK5sWnQiAiqjic2ZSyKuXid2wpbNfg1Xb2KvDeUumTEuII6lzaTjl2QY4na1sHw9u7 WhwQ== X-Gm-Message-State: APjAAAWVtxDsRR7uC14nJ54CNca9uJyg60xHMUXpqOU7Paq7Bb4sSIHD qwTaJ+OW5UO9MzFuLv5Hqxy86k8A X-Google-Smtp-Source: APXvYqzxD0j2rJNtmQjjmqYAJDVn2fQxXKU6fsQCDmGC9hOoO9ygDbphsIFA7PWPyePitd1jgZpjWA== X-Received: by 2002:a37:f511:: with SMTP id l17mr44010832qkk.99.1563839376839; Mon, 22 Jul 2019 16:49:36 -0700 (PDT) Received: from [192.168.1.14] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id w25sm16419606qto.87.2019.07.22.16.49.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 16:49:36 -0700 (PDT) To: "Scharf, Michael" Cc: "tcpm@ietf.org Extensions" References: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de> From: Wesley Eddy Message-ID: <82fda516-59f9-6156-5a08-bd1ada18ac1d@mti-systems.com> Date: Mon, 22 Jul 2019 19:49:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-rfc793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 22 Jul 2019 23:49:41 -0000 Hi Michael, thanks for the review. All of your suggestions look pretty good to me, and I'll plan to apply them this week, except for the errata one, which seems like more of an open question at the moment. For historical interest, I did a little homework on the mysterious acronym list "SVCs, UUOs, EMTs" refers to, and I think they are: - SVC = Supervisor Call (IBM S/360) - UUO = Unimplemented User Operations (DEC-10 system monitor call) - EMT = Emulator Trap (PDP-11) In any case, I agree with you that the sentence is more clear to a modern reader just by not including the mention of these examples! On 7/21/2019 10:27 AM, Scharf, Michael wrote: > Hi Wes, > > I went through draft-ietf-tcpm-rfc793bis-13 in the airplane. Here are some minor observations, basically editorial: > > * Section 3.6 explains why the document uses the terms "security level" and "compartment" and in what specific context this may matter. However, these terms are used earlier in the document. I believe it could be useful to add a forward reference earlier in the document to Section 3.6 (and Appendix A.1), in particular for implementers who do not implement this. For instance, maybe one could add a forward reference in Section 3.2 Terminology, where these terms seem to be used for the first time. > > * Section 3.7.4 defines the Nagle algorithm. The exact same definition is repeated in 3.8.6.2.1 (except for a reference). It is not clear to me why the definition must be repeated in 3.8.6.2.1. > > * Section 3.8 states: "The notation used is similar to most procedure or function calls in high level languages, but this usage is not meant to rule out trap type service calls (e.g., SVCs, UUOs, EMTs)." The acronyms SVCs, UUOs and EMTs have not been expanded in RFC 793. I wonder if I am really the only person who is not really familiar with those acronyms? In any case, I believe that "(e.g., SVCs, UUOs, EMTs)" could just be removed from the document. > > * I wonder if Erratas should added to the references, in particular if there is an explicit reference to their content. An example would be Errata ID 4772, which is cited like an RFC. Probably this is a formal question to the IESG or the RFC editor... Anyway, I don't know the answer, but it is something we could probably try to find out. > > * The Glossary includes terms that are not used in the document. I wonder if we really need to keep entries that maybe mattered in the original RFC 793 only. Actually, I don't even understand why RFC 793 included some entries (e.g., "1822", "leader"), as they do not even show up in the document body of RFC 793. > > Finally, I want to note that the document by and large looks good to me and I really encourage others to read it, too. > > Thanks > > Michael From nobody Tue Jul 23 04:29: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 14B5F1201E7 for ; Tue, 23 Jul 2019 04:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv7TW927lgfG for ; Tue, 23 Jul 2019 04:29:31 -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 D9A601201F0 for ; Tue, 23 Jul 2019 04:29:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 55D1225A12; Tue, 23 Jul 2019 13:29:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563881360; bh=kZ6/r73dnAbiXFtNAqNkoBIahV5NWKYdZ5bT0VpWWjg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=z0hHZx4/XdcmWN12qsiwVG74DxtLtloAkqGFb/Fki2TElReXSA+xFUlJTFYeDm5gt yE7BPF86Hb0RqMor+YW1qSACXLa5xqr4Xw+Zb1EwiBAWNzD2MbWISJtAg/2LXml/O7 wO1TiE+QSbOOMhkQBNougJswRJK1ajH/WOSA4RwI= 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 l6TMaD2Bl2K6; Tue, 23 Jul 2019 13:29:19 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 23 Jul 2019 13:29:19 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 23 Jul 2019 13:29:19 +0200 From: "Scharf, Michael" To: Wesley Eddy CC: "tcpm@ietf.org Extensions" Thread-Topic: Some comments on draft-ietf-tcpm-rfc793bis Thread-Index: AdU/y0QHaugjFL0hTAywGUTGNy0axgBDBYCAABxUN6A= Date: Tue, 23 Jul 2019 11:29:17 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3C3F4B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de> <82fda516-59f9-6156-5a08-bd1ada18ac1d@mti-systems.com> In-Reply-To: <82fda516-59f9-6156-5a08-bd1ada18ac1d@mti-systems.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-rfc793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 23 Jul 2019 11:29:33 -0000 SSBhZ3JlZSB0aGF0IHdlIGNhbiBsZWF2ZSB0aGUgZXJyYXRhIGNpdGF0aW9uIHN0eWxlIGFzIGlz LiBUaGUgUkZDIGVkaXRvciBtYXkgaGF2ZSB0byBzb3J0IHRoaXMgb3V0Lg0KDQpCVFcsIEkgaGF2 ZSB0cmllZCB0byByZXZlcnNlIGVuZ2luZWVyICJTVkMiIG15c2VsZiBhbmQgY2FtZSB0byB0aGUg c2FtZSBjb25jbHVzaW9uLCBidXQgdGhlbiBJIGdhdmUgdXAuIA0KDQpUaGFua3MNCg0KTWljaGFl bA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdlc2xleSBFZGR5IDx3 ZXNAbXRpLXN5c3RlbXMuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDIzLCAyMDE5IDE6NTAg QU0NCj4gVG86IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRl Pg0KPiBDYzogdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIDx0Y3BtQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBSZTogU29tZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzDQo+IA0K PiBIaSBNaWNoYWVsLCB0aGFua3MgZm9yIHRoZSByZXZpZXcuDQo+IA0KPiBBbGwgb2YgeW91ciBz dWdnZXN0aW9ucyBsb29rIHByZXR0eSBnb29kIHRvIG1lLCBhbmQgSSdsbCBwbGFuIHRvIGFwcGx5 DQo+IHRoZW0gdGhpcyB3ZWVrLCBleGNlcHQgZm9yIHRoZSBlcnJhdGEgb25lLCB3aGljaCBzZWVt cyBsaWtlIG1vcmUgb2YgYW4NCj4gb3BlbiBxdWVzdGlvbiBhdCB0aGUgbW9tZW50Lg0KPiANCj4g Rm9yIGhpc3RvcmljYWwgaW50ZXJlc3QsIEkgZGlkIGEgbGl0dGxlIGhvbWV3b3JrIG9uIHRoZSBt eXN0ZXJpb3VzDQo+IGFjcm9ueW0gbGlzdCAiU1ZDcywgVVVPcywgRU1UcyIgcmVmZXJzIHRvLCBh bmQgSSB0aGluayB0aGV5IGFyZToNCj4gDQo+IC0gU1ZDID0gU3VwZXJ2aXNvciBDYWxsIChJQk0g Uy8zNjApDQo+IA0KPiAtIFVVTyA9IFVuaW1wbGVtZW50ZWQgVXNlciBPcGVyYXRpb25zIChERUMt MTAgc3lzdGVtIG1vbml0b3IgY2FsbCkNCj4gDQo+IC0gRU1UID0gRW11bGF0b3IgVHJhcCAoUERQ LTExKQ0KPiANCj4gSW4gYW55IGNhc2UsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgc2VudGVu Y2UgaXMgbW9yZSBjbGVhciB0byBhDQo+IG1vZGVybiByZWFkZXIganVzdCBieSBub3QgaW5jbHVk aW5nIHRoZSBtZW50aW9uIG9mIHRoZXNlIGV4YW1wbGVzIQ0KPiANCj4gDQo+IA0KPiBPbiA3LzIx LzIwMTkgMTA6MjcgQU0sIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCj4gPiBIaSBXZXMsDQo+ID4N Cj4gPiBJIHdlbnQgdGhyb3VnaCBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTEzIGluIHRoZSBh aXJwbGFuZS4gSGVyZSBhcmUgc29tZQ0KPiBtaW5vciBvYnNlcnZhdGlvbnMsIGJhc2ljYWxseSBl ZGl0b3JpYWw6DQo+ID4NCj4gPiAqIFNlY3Rpb24gMy42IGV4cGxhaW5zIHdoeSB0aGUgZG9jdW1l bnQgdXNlcyB0aGUgdGVybXMgInNlY3VyaXR5IGxldmVsIg0KPiBhbmQgImNvbXBhcnRtZW50IiBh bmQgaW4gd2hhdCBzcGVjaWZpYyBjb250ZXh0IHRoaXMgbWF5IG1hdHRlci4gSG93ZXZlciwNCj4g dGhlc2UgdGVybXMgYXJlIHVzZWQgZWFybGllciBpbiB0aGUgZG9jdW1lbnQuIEkgYmVsaWV2ZSBp dCBjb3VsZCBiZSB1c2VmdWwgdG8NCj4gYWRkIGEgZm9yd2FyZCByZWZlcmVuY2UgZWFybGllciBp biB0aGUgZG9jdW1lbnQgdG8gU2VjdGlvbiAzLjYgKGFuZA0KPiBBcHBlbmRpeCBBLjEpLCBpbiBw YXJ0aWN1bGFyIGZvciBpbXBsZW1lbnRlcnMgd2hvIGRvIG5vdCBpbXBsZW1lbnQgdGhpcy4gRm9y DQo+IGluc3RhbmNlLCBtYXliZSBvbmUgY291bGQgYWRkIGEgZm9yd2FyZCByZWZlcmVuY2UgaW4g U2VjdGlvbiAzLjINCj4gVGVybWlub2xvZ3ksIHdoZXJlIHRoZXNlIHRlcm1zIHNlZW0gdG8gYmUg dXNlZCBmb3IgdGhlIGZpcnN0IHRpbWUuDQo+ID4NCj4gPiAqIFNlY3Rpb24gMy43LjQgZGVmaW5l cyB0aGUgTmFnbGUgYWxnb3JpdGhtLiBUaGUgZXhhY3Qgc2FtZSBkZWZpbml0aW9uIGlzDQo+IHJl cGVhdGVkIGluIDMuOC42LjIuMSAoZXhjZXB0IGZvciBhIHJlZmVyZW5jZSkuIEl0IGlzIG5vdCBj bGVhciB0byBtZSB3aHkgdGhlDQo+IGRlZmluaXRpb24gbXVzdCBiZSByZXBlYXRlZCBpbiAzLjgu Ni4yLjEuDQo+ID4NCj4gPiAqIFNlY3Rpb24gMy44IHN0YXRlczogIlRoZSBub3RhdGlvbiB1c2Vk IGlzIHNpbWlsYXIgdG8gbW9zdCBwcm9jZWR1cmUgb3INCj4gZnVuY3Rpb24gY2FsbHMgaW4gaGln aCBsZXZlbCBsYW5ndWFnZXMsIGJ1dCB0aGlzIHVzYWdlIGlzIG5vdCBtZWFudCB0byBydWxlIG91 dA0KPiB0cmFwIHR5cGUgc2VydmljZSBjYWxscyAoZS5nLiwgU1ZDcywgVVVPcywgRU1UcykuIiBU aGUgYWNyb255bXMgU1ZDcywgVVVPcw0KPiBhbmQgRU1UcyBoYXZlIG5vdCBiZWVuIGV4cGFuZGVk IGluIFJGQyA3OTMuIEkgd29uZGVyIGlmIEkgYW0gcmVhbGx5IHRoZQ0KPiBvbmx5IHBlcnNvbiB3 aG8gaXMgbm90IHJlYWxseSBmYW1pbGlhciB3aXRoIHRob3NlIGFjcm9ueW1zPyBJbiBhbnkgY2Fz ZSwgSQ0KPiBiZWxpZXZlIHRoYXQgIihlLmcuLCBTVkNzLCBVVU9zLCBFTVRzKSIgY291bGQganVz dCBiZSByZW1vdmVkIGZyb20gdGhlDQo+IGRvY3VtZW50Lg0KPiA+DQo+ID4gKiBJIHdvbmRlciBp ZiBFcnJhdGFzIHNob3VsZCBhZGRlZCB0byB0aGUgcmVmZXJlbmNlcywgaW4gcGFydGljdWxhciBp ZiB0aGVyZSBpcw0KPiBhbiBleHBsaWNpdCByZWZlcmVuY2UgdG8gdGhlaXIgY29udGVudC4gQW4g ZXhhbXBsZSB3b3VsZCBiZSBFcnJhdGEgSUQgNDc3MiwNCj4gd2hpY2ggaXMgY2l0ZWQgbGlrZSBh biBSRkMuIFByb2JhYmx5IHRoaXMgaXMgYSBmb3JtYWwgcXVlc3Rpb24gdG8gdGhlIElFU0cgb3Ig dGhlDQo+IFJGQyBlZGl0b3IuLi4gQW55d2F5LCBJIGRvbid0IGtub3cgdGhlIGFuc3dlciwgYnV0 IGl0IGlzIHNvbWV0aGluZyB3ZSBjb3VsZA0KPiBwcm9iYWJseSB0cnkgdG8gZmluZCBvdXQuDQo+ ID4NCj4gPiAqIFRoZSBHbG9zc2FyeSBpbmNsdWRlcyB0ZXJtcyB0aGF0IGFyZSBub3QgdXNlZCBp biB0aGUgZG9jdW1lbnQuIEkgd29uZGVyDQo+IGlmIHdlIHJlYWxseSBuZWVkIHRvIGtlZXAgZW50 cmllcyB0aGF0IG1heWJlIG1hdHRlcmVkIGluIHRoZSBvcmlnaW5hbCBSRkMgNzkzDQo+IG9ubHku IEFjdHVhbGx5LCBJIGRvbid0IGV2ZW4gdW5kZXJzdGFuZCB3aHkgUkZDIDc5MyBpbmNsdWRlZCBz b21lIGVudHJpZXMNCj4gKGUuZy4sICIxODIyIiwgImxlYWRlciIpLCBhcyB0aGV5IGRvIG5vdCBl dmVuIHNob3cgdXAgaW4gdGhlIGRvY3VtZW50IGJvZHkNCj4gb2YgUkZDIDc5My4NCj4gPg0KPiA+ IEZpbmFsbHksIEkgd2FudCB0byBub3RlIHRoYXQgdGhlIGRvY3VtZW50IGJ5IGFuZCBsYXJnZSBs b29rcyBnb29kIHRvIG1lDQo+IGFuZCBJIHJlYWxseSBlbmNvdXJhZ2Ugb3RoZXJzIHRvIHJlYWQg aXQsIHRvby4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+DQo+ID4gTWljaGFlbA0K From nobody Thu Jul 25 11:20: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 F1198120198; Thu, 25 Jul 2019 11:20:10 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piX12O2hRbhY; Thu, 25 Jul 2019 11:20:07 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E23120183; Thu, 25 Jul 2019 11:20:07 -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=byacMvIpwO1ixGGAaMSpuxBvsY8AvT9obkpqT5raZHI=; b=xrwvQ2asO2Tkgr7rvHNnQ309s1 hPyoANTRyW3W3RJ67bTHbtJU+WpbN3XZ004TdjGub+5kPW5oIbGD2KGHaQOI8EvRq39aowu3BKD3x EYUmndqDsmDyaokWtjiSZTtfniaKZ4hsVJ8QpaiwLFtn39j0Obl1hxIq2M614fNJ8U4vGMQ53lc/9 xcoKWjHlfSSvM5ntPX3doDMzfl5k6rmrIRpzkVk4z0t5zQDvUJH0ajYy96pUlz49kxWZ2z6s1+4RG pxbLQA3WkXzIN2J6R6+qH6O7+krrDYKJHx76gnZlXY07OEcgTIAo2H6+6gnxs33Z3+v+8xeARlBd1 SEadWHxg==; Received: from dhcp-9572.meeting.ietf.org ([31.133.149.114]:47536) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hqiLU-0003aS-DC; Thu, 25 Jul 2019 19:20:04 +0100 To: rgrimes@freebsd.org Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" References: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> From: Bob Briscoe Message-ID: Date: Thu, 25 Jul 2019 14:20:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:20:11 -0000 Rod, On 12/07/2019 15:39, Rodney W. Grimes wrote: >> Rod, >> >> This draft appears to be focused on obtaining a TCP header bit for SCE. > Yes, that is correct. > >> As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. > I specifically did not do what Accurate Ecn attempts as that requires > a TCP option negotiation at connection establishment to negotiate the > overloading of other TCP header bits. SCE only needs 1 new bit, and > does not alter the behavior of any current bits. Just to correct this slightly - in AccECN, there is no explicit TCP option negotiation. Negotiating use of the 3 header bits also implicitly states that the endpoints might have implemented the TCP option. However, it's not mandatory to send the option (it is recommended), and it's not mandatory to even implement the logic to read in the option (that is highly recommended). Reason: the protocol has to be able to work even if the option is stripped on the path. > > This proposal (TCPSCE) does not in any way effect the current use of > any of the other bits, and use of the NS bit should be fully backwards > compatible and ignored by pre SCE implementations and does not require > a TCP option negotiation. > > I have to get additional data but have been lead to understand that > adding a tcp option and doing that negotiation is going to cause a > great deal of pain in the ability to deploy accurate ecn as it is > currently designed due to middle box inspection and handling. There's already been concern about burning TCP header codepoints, which might use up space that prevents something in future. The idea of AccECN is to enable generic more accurate feedback. It was based on a protracted requirements-gathering exercise [RFC7560], and lots of compromising along the way. The idea was to have a generic wire protocol with a dumb receiver, so that the same feedback protocol could support multiple needs for feedback by different TCP congestion control algorithms. So a fairly inefficient re-use of the 'NS' TCP header flag for one particular experiment is very unlikely to fly, particularly when the experiment it supports doesn't satisfy all the requirements in 7560. For instance, I think the reason the tcpsce draft discusses multiple ways of doing the feedback is that, in the presence of pure ACK loss (which is often due to deliberate ACK thinning), none of the three solutions preserve reliable delivery of the ACK signal. In the case of Single ACK (4.1), the additional ACK load would be unacceptable. In the case of immediate ACKing of an IP-SCE (not delaying the ACK - S.4.2), it introduces bias (i.e. a higher proportion of ESCE ACKs to non-ESCE), so it becomes hard/impossible for the sender to reverse engineer what congestion feedback level was intended. In the case of dithering (4.3), the congestion signal frequently becomes deferred (and there may not be a next packet for some time). The requirements [RFC7560] recognise that this is a multi-dimensional compromise so any solution had to explain the rationale for its particular choices. However, I don't think this solution is anywhere near as efficient in its use of the limited bit-space as many of the other rejected AccECN proposals have been, let alone the currently chosen one. Bob > > Regards, > Rod > >> Thanks, --David >> >>> -----Original Message----- >>> From: tsvwg On Behalf Of Rodney W. Grimes >>> Sent: Monday, July 8, 2019 8:07 PM >>> To: tcpm@ietf.org; tsvwg@ietf.org >>> Subject: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce- >>> 00.txt >>> >>> >>> [EXTERNAL EMAIL] >>> >>> I have posted a new version with updated proper tcpm working group >>> name of draft-grimes-tcpm-tcpsce-00 >>> (formerly draft-grimes-tcpmwg-tcpsce-00.txt) >>> >>> This is first cut at how SCE works in TCP >>> >>> Cross posting this to both tsvwg and tcpm due to overlap >>> >>> >>>> A new version of I-D, draft-grimes-tcpm-tcpsce-00.txt >>>> has been successfully submitted by Rodney W. Grimes and posted to the >>>> IETF repository. >>>> >>>> Name: draft-grimes-tcpm-tcpsce >>>> Revision: 00 >>>> Title: Some Congestion Experienced in TCP >>>> Document date: 2019-07-08 >>>> Group: Individual Submission >>>> Pages: 5 >>>> URL: https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce- >>> 00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/ >>>> Htmlized: https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-00 >>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-grimes-tcpm- >>> tcpsce >>>> >>>> Abstract: >>>> This memo classifies a TCP code point ESCE ("Echo Some Congestion >>>> Experienced") for use in feedback of IP code point SCE ("Some >>>> Congestion Experienced"). >>> -- >>> Rod Grimes rgrimes@freebsd.org >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jul 25 11:42: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 873A0120198; Thu, 25 Jul 2019 11:41:50 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaETscFNL2qp; Thu, 25 Jul 2019 11:41: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 713DD120191; Thu, 25 Jul 2019 11:41: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=6OP/Lntt11VO0jUQMa4Dwmix2HzSFnl/gYdtA8cCj9U=; b=RfFlRAKpLRkts9ZSrvzYj9VeKv gA/A1/UHvq6oVUh6+BdUelaKO1tdJCvWvll6tQWO34a3ASwKIMQVq2agjkZBe4H3YG7FUof2r55Q4 7jbkBeV1W8QWWOPXCA7Kkp6VnKDtl+Jb+qkomZQgbhSeZoHD7PvefZDr8CdgZ1aP2MLT3HMVHfdT2 NRtUi2/wCiaVwMtPOTpD1nfoCi9bpjkqRjqKDJivhe1izOexhYxlvdzrKOMnAPw+4OkCVYBQNijQ2 CKA59xm9BZ5HWMHt+vhX9SuxoHkFj3loV+GGeGL8x660YhRFY3PEAp2+kr76JljSLRyjeQIF5l5y5 O3BwDybw==; Received: from dhcp-9572.meeting.ietf.org ([31.133.149.114]:48218) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hqigU-0006oU-EV; Thu, 25 Jul 2019 19:41:46 +0100 To: Jonathan Morton , "Scharf, Michael" Cc: "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> <6EC6417807D9754DA64F3087E2E2E03E2D3C0A43@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: Date: Thu, 25 Jul 2019 14:41:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:41:51 -0000 Jonathan, On 22/07/2019 10:48, Jonathan Morton wrote: >> On 21 Jul, 2019, at 9:01 pm, Scharf, Michael wrote: >> >> Please be aware that there is also draft-ietf-tcpm-generalized-ecn-04, which in the current version has a dependency on draft-ietf-tcpm-accurate-ecn for certain cases. >> >> Just to state the obvious: These documents are work in progress in TCPM and TCPM always welcomes feedback. > I just skimmed through it to remind myself of certain details. Most of it only applies once AccECN has completed negotiation, so the same arguments apply. Actually in 2 out of 7 cases, not "most". See table 1 in the spec, which is intended for people who skim. > > I do however note that SYN is described as the most important packet to protect with ECN, and this is of course sent before AccECN negotiation has completed. Further, if the SYN-ACK then indicates that AccECN is *not* supported by the remote end - which would be the case for both an SCE endpoint and any conventional one - a conservative IW of 1 segment SHOULD be conservatively selected, with no modification for the increasingly common IW10 case (the default for current versions of Linux). This incurs a flow completion time delay of approximately 3 RTTs, which could be perceptible to end users. The draft explains: the reduction to IW1 is in the client to server direction. It cites measurement studies that show it's unusual to get >1 initial packet in that direction anyway. And the reduction to 1 is only a SHOULD. An implementation could choose 2 for instance. When new to the IETF, it's even more important to read the draft before sending critique (cos you won't have heard all the previous discussion). Otherwise it burns busy people's time on the list unnecessarily. > > A less extreme response may be justified here, given that the strongest signal that may have been missed by the lack of ECN feedback is a CE mark, for which the most conservative TCP response is to halve the cwnd. So for an IW4 sender, the IW should be reduced to 2, and for an IW10 sender, the IW should be reduced to 5. This would reduce the flow completion penalty to 1 RTT when encountering a non-AccECN endpoint. Again, pls read the rationale for fall-back to IW1 in the draft. (There's a whole rationale section after the normative text section, with linked referenced from each section of it). Briefly, if you get a CE, it implies the queue was up to it's marking threshold 1 RTT ago, presumably with traffic from another flow(s). So adding more than 1 packet is likely to be pointless and counterproductive for them and you. But this is only a SHOULD, cos experiments might prove IW1 is unnecessary (if anyone is motivated to bother because they have an app that starts with >1 request data packet). Bob > > - Jonathan Morton > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jul 25 11:54: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 32C3D1201E9; Thu, 25 Jul 2019 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-uwV6NV-80F; Thu, 25 Jul 2019 11:53:48 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 908AC120191; Thu, 25 Jul 2019 11:53:48 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id m23so34415190vso.1; Thu, 25 Jul 2019 11:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TvszhvUR4ndmu5p7GvuMIfOhk5j4UgWxqRGe3davLaE=; b=jB1QHYexjiPQCoPQcUssXfTRHFdbLKatxuudvrD65tKslgHz3RGRpAHvFNm0/zwbJ6 VHQCKhPGr2qZC7JQT54SWvZNcC7iBL1xq5EmQ+ZJpI/tj7mcJnqDF9fwKAGyywUGDPrJ JMWcBg1q3fXuBmadEfGuCQDm/tf4zpr4gZW42pICov3+559YQZWaaUYeQb68uLUxRpA0 Hq8HFdZO0k3tU8NPINMHuurvK+fVOvDJquu4/Burmze/Tv1cwMMRJyX8g2jojQCbMcTG kf6/rwLl7E6R5VctNcY3cDWjvI9m+QD3t1phfS8C/eP8SC2hkYKL8LHsvZJSrR7zMYjA Ip1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TvszhvUR4ndmu5p7GvuMIfOhk5j4UgWxqRGe3davLaE=; b=lVoiQe71Uc+T0pxPW7gs0I4ShHf7E2wCOIK1DcFtIPxArI4XWZCTtb2mq93gli8NLt C5PSz9XLDRUZxkKMQBcrUZh9D/YTQbKSwkZ8LVP1RTQqaHvYfBS3aq8CeiTq6x1hpZhn MuZ5jsnKH8WucFD4Uh4CxRaMG3JxTo/oDMjA81P2vD3kVbQHIVLgAXjoP0nSnckqRNcl yqr/S/Hs3MEZrHN4KEXsEPXCBUj/OAjivwNQr/CzJRdYrO1RhYW/dNBc8f15vFy6hbeD YEz8xRong98ZRmYSVeHtmUNEKNlv91qQb2Ft8uhvMCWEakfPveiu/mZECgc8owcE8mA+ h4Wg== X-Gm-Message-State: APjAAAU7GQpyP4gV/LGBXzVbZj6mcdROdrOoQ4pQZ7WwmaAhKazggDpK OFRuqzHp2c8X0T2XPQj5P/iAEZCF X-Google-Smtp-Source: APXvYqwdVqcVwPz0EBJZ/g1D59o+PtixhnBooHndaV8MEFyxchspBKFqqlNo4VDZaPqvv0dHwXV6MA== X-Received: by 2002:a67:b14c:: with SMTP id z12mr54165251vsl.11.1564080827602; Thu, 25 Jul 2019 11:53:47 -0700 (PDT) Received: from jonathartonsmbp.lan (173-246-8-242.qc.cable.ebox.net. [173.246.8.242]) by smtp.gmail.com with ESMTPSA id f140sm35957849vka.36.2019.07.25.11.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 11:53:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Thu, 25 Jul 2019 14:53:45 -0400 Cc: rgrimes@freebsd.org, "tcpm@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <89B2FD3D-4C10-489A-9867-538BABF3E521@gmail.com> References: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:54:00 -0000 > On 25 Jul, 2019, at 2:20 pm, Bob Briscoe wrote: >=20 > The idea was to have a generic wire protocol with a dumb receiver, so = that the same feedback protocol could support multiple needs for = feedback by different TCP congestion control algorithms. >=20 > So a fairly inefficient re-use of the 'NS' TCP header flag for one = particular experiment is very unlikely to fly, particularly when the = experiment it supports doesn't satisfy all the requirements in 7560. AccECN burns the same bit to provide higher fidelity feedback of CE, = without addressing our need to feed back the distinction between ECT(1) = and ECT(0) at all (unless the TCP Option is used). Since higher = fidelity feedback of CE is not useful for SCE, using NS in this way is = actually more efficient for us. Happily, AccECN and SCE can coexist on = different flows, thanks to the fact that AccECN does have a negotiation = phase which SCE can naturally reject. > For instance, I think the reason the tcpsce draft discusses multiple = ways of doing the feedback is that, in the presence of pure ACK loss = (which is often due to deliberate ACK thinning), none of the three = solutions preserve reliable delivery of the ACK signal. In SCE, *reliable* feedback of SCE signals is not actually required, = both because the control loop is naturally stable, and because = RFC-3168's CE feedback *is* reliable and thus offers a safe fallback. = Of course we understand that the design constraints for L4S' feedback = mechanism were different. Ack thinning is also something we have explicitly considered, given that = Cake includes an optional ack-filter which does exactly that. (We have, = for example, added consideration of the NS bit to Cake's ack-filter, = which was a trivial patch.) Mathematically, the most extreme errors = possible in either direction, due to ack thinning, are easily corrected = during subsequent RTTs. - Jonathan Morton From nobody Thu Jul 25 13:06: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 294851201F8; Thu, 25 Jul 2019 13:06:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amlGAIG2fagu; Thu, 25 Jul 2019 13:06:33 -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 14CD21201EC; Thu, 25 Jul 2019 13:06:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 2D20625A19; Thu, 25 Jul 2019 22:06:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1564085191; bh=pegGRKVy25CpdGeQfMzAjiiVHOvtnj+f3DNfiESXlF0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bvYKTB60WDUi+iWCgSU+e6KcjIehPsMmqt9znY80m9f105V/kmXgnOno21/OAoNSG lUcMHUAofRH6w9n8xuM0Wqrc1pe+22WxcN6ZCEx9KllZjEnjoVX0SB8cTAHvZtmJ/l nmql1NVci5kl8/v9pVMeUFj13i/bfCMwhIGZcS7k= 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 ILVT4qYFes99; Thu, 25 Jul 2019 22:06:30 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 25 Jul 2019 22:06:30 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 25 Jul 2019 22:06:29 +0200 From: "Scharf, Michael" To: Bob Briscoe , Jonathan Morton CC: "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt Thread-Index: AQHVQxiePohoWEl9KE+uYb+QgVUmZKbbwGLw Date: Thu, 25 Jul 2019 20:06:29 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3C9D1C@rznt8114.rznt.rzdir.fht-esslingen.de> References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> <6EC6417807D9754DA64F3087E2E2E03E2D3C0A43@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:06:35 -0000 PiA+IEkgZG8gaG93ZXZlciBub3RlIHRoYXQgU1lOIGlzIGRlc2NyaWJlZCBhcyB0aGUgbW9zdCBp bXBvcnRhbnQgcGFja2V0IHRvDQo+IHByb3RlY3Qgd2l0aCBFQ04sIGFuZCB0aGlzIGlzIG9mIGNv dXJzZSBzZW50IGJlZm9yZSBBY2NFQ04gbmVnb3RpYXRpb24gaGFzDQo+IGNvbXBsZXRlZC4gIEZ1 cnRoZXIsIGlmIHRoZSBTWU4tQUNLIHRoZW4gaW5kaWNhdGVzIHRoYXQgQWNjRUNOIGlzICpub3Qq DQo+IHN1cHBvcnRlZCBieSB0aGUgcmVtb3RlIGVuZCAtIHdoaWNoIHdvdWxkIGJlIHRoZSBjYXNl IGZvciBib3RoIGFuIFNDRQ0KPiBlbmRwb2ludCBhbmQgYW55IGNvbnZlbnRpb25hbCBvbmUgLSBh IGNvbnNlcnZhdGl2ZSBJVyBvZiAxIHNlZ21lbnQgU0hPVUxEDQo+IGJlIGNvbnNlcnZhdGl2ZWx5 IHNlbGVjdGVkLCB3aXRoIG5vIG1vZGlmaWNhdGlvbiBmb3IgdGhlIGluY3JlYXNpbmdseSBjb21t b24NCj4gSVcxMCBjYXNlICh0aGUgZGVmYXVsdCBmb3IgY3VycmVudCB2ZXJzaW9ucyBvZiBMaW51 eCkuICBUaGlzIGluY3VycyBhIGZsb3cNCj4gY29tcGxldGlvbiB0aW1lIGRlbGF5IG9mIGFwcHJv eGltYXRlbHkgMyBSVFRzLCB3aGljaCBjb3VsZCBiZSBwZXJjZXB0aWJsZSB0bw0KPiBlbmQgdXNl cnMuDQo+IFRoZSBkcmFmdCBleHBsYWluczogdGhlIHJlZHVjdGlvbiB0byBJVzEgaXMgaW4gdGhl IGNsaWVudCB0byBzZXJ2ZXINCj4gZGlyZWN0aW9uLiBJdCBjaXRlcyBtZWFzdXJlbWVudCBzdHVk aWVzIHRoYXQgc2hvdyBpdCdzIHVudXN1YWwgdG8gZ2V0ID4xDQo+IGluaXRpYWwgcGFja2V0IGlu IHRoYXQgZGlyZWN0aW9uIGFueXdheS4gQW5kIHRoZSByZWR1Y3Rpb24gdG8gMSBpcyBvbmx5DQo+ IGEgU0hPVUxELiBBbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBjaG9vc2UgMiBmb3IgaW5zdGFuY2Uu DQo+IA0KPiBXaGVuIG5ldyB0byB0aGUgSUVURiwgaXQncyBldmVuIG1vcmUgaW1wb3J0YW50IHRv IHJlYWQgdGhlIGRyYWZ0IGJlZm9yZQ0KPiBzZW5kaW5nIGNyaXRpcXVlIChjb3MgeW91IHdvbid0 IGhhdmUgaGVhcmQgYWxsIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uKS4NCj4gT3RoZXJ3aXNlIGl0 IGJ1cm5zIGJ1c3kgcGVvcGxlJ3MgdGltZSBvbiB0aGUgbGlzdCB1bm5lY2Vzc2FyaWx5Lg0KDQpJ J2QgbGlrZSB0byByZW1pbmQgcGVvcGxlIHRoYXQgY29tbWVudHMgZnJvbSBwZW9wbGUgbmV3IHRv IHRoZSBJRVRGIF9hcmVfIHdlbGNvbWUgaW4gVENQTSBhbmQgZWxzZXdoZXJlIGluIHRoZSBJRVRG Lg0KDQpNaWNoYWVsIChhcyBjaGFpcikNCg== From nobody Thu Jul 25 13:16:04 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6721201FA; Thu, 25 Jul 2019 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=Y/Wqywar; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Z4tfgGB0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfUfStu6VAUh; Thu, 25 Jul 2019 13:15:59 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32471201DB; Thu, 25 Jul 2019 13:15:59 -0700 (PDT) Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6PK9gNx024814; Thu, 25 Jul 2019 16:14:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=ufmw8afxQijUVE+FGKtRIgtlY5lKaAuxfr4s2Ii4aRw=; b=Y/Wqywarafo12yCr/Y9LmoHBxOz/H4E6lBU2bwr3cVSinaTJVXOpsucUCiQZ3lj8OQKu 9EUnz2PWmfgPilZhNqgQiVlCbukH5Weg1UPIgau3u1puxSoBdh8HMHgw2McgQJQY/hdu OpLH0OVfjeVusAWigMfQ4wUn0VGucsJVZsAWuYZKLecG17gRzWtzHYsfBOiwHhcvmI4T NH+AuN3gecGbzxtwcIzEVcHVGdF3M7bwAstb95bKRTBu5WIrEHMWhKB4i/1Xgpc/yfsd D0Qm6CqKOJrDUjJPUd0VMaYANfYb24q5OUEheIj0zmWnFNt+LVoGhnSW8aYCufywRpOI Xg== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2tyfb694c4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2019 16:14:09 -0400 Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6PKCW1G132052; Thu, 25 Jul 2019 16:14:09 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2tyhy995r4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jul 2019 16:14:09 -0400 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6PKDwvq018357 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jul 2019 16:14:08 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x6PKDwvq018357 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1564085648; bh=uMCDCulZyAgYywH2yXKBLI9neQs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Z4tfgGB0cxFbI/uOMdYb17fpXz691lhTspbctmmfPVOQwRAfpy3d/3ldPQ5vR6xfg fwugBDlzQInSRvIVMrvYPVcR4PwnMSnwiSuQsLIUE9NgMyuEu7ziQE8ctTjdsTg9Wz 6Q44oXYmY0n/ywi2eKWJ6OYdrjRpuBrZ1hOy+rxY= Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd05.lss.emc.com (RSA Interceptor); Thu, 25 Jul 2019 16:13:22 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6PKDMxB025638 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 25 Jul 2019 16:13:22 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0439.000; Thu, 25 Jul 2019 16:13:21 -0400 From: "Black, David" To: "Scharf, Michael" , Bob Briscoe , Jonathan Morton CC: "Rodney W. Grimes" , "tcpm@ietf.org" , "tsvwg@ietf.org" , "Black, David" Thread-Topic: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt Thread-Index: AQHVQCkS5HDO7wV1tEWIFV3qScWBCabW+9SAgAT4HgCAABeugP//vqLw Date: Thu, 25 Jul 2019 20:13:21 +0000 Message-ID: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <1468777263.2671021.1563730029999@mail.yahoo.com> <6EC6417807D9754DA64F3087E2E2E03E2D3C0A43@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D3C9D1C@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3C9D1C@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-25T20:13:20.6110532Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=827 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907250241 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=896 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907250240 Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:16:02 -0000 PiBbRVhURVJOQUwgRU1BSUxdDQo+IA0KPiA+ID4gSSBkbyBob3dldmVyIG5vdGUgdGhhdCBTWU4g aXMgZGVzY3JpYmVkIGFzIHRoZSBtb3N0IGltcG9ydGFudCBwYWNrZXQgdG8NCj4gPiBwcm90ZWN0 IHdpdGggRUNOLCBhbmQgdGhpcyBpcyBvZiBjb3Vyc2Ugc2VudCBiZWZvcmUgQWNjRUNOIG5lZ290 aWF0aW9uIGhhcw0KPiA+IGNvbXBsZXRlZC4gIEZ1cnRoZXIsIGlmIHRoZSBTWU4tQUNLIHRoZW4g aW5kaWNhdGVzIHRoYXQgQWNjRUNOIGlzICpub3QqDQo+ID4gc3VwcG9ydGVkIGJ5IHRoZSByZW1v dGUgZW5kIC0gd2hpY2ggd291bGQgYmUgdGhlIGNhc2UgZm9yIGJvdGggYW4gU0NFDQo+ID4gZW5k cG9pbnQgYW5kIGFueSBjb252ZW50aW9uYWwgb25lIC0gYSBjb25zZXJ2YXRpdmUgSVcgb2YgMSBz ZWdtZW50IFNIT1VMRA0KPiA+IGJlIGNvbnNlcnZhdGl2ZWx5IHNlbGVjdGVkLCB3aXRoIG5vIG1v ZGlmaWNhdGlvbiBmb3IgdGhlIGluY3JlYXNpbmdseSBjb21tb24NCj4gPiBJVzEwIGNhc2UgKHRo ZSBkZWZhdWx0IGZvciBjdXJyZW50IHZlcnNpb25zIG9mIExpbnV4KS4gIFRoaXMgaW5jdXJzIGEg Zmxvdw0KPiA+IGNvbXBsZXRpb24gdGltZSBkZWxheSBvZiBhcHByb3hpbWF0ZWx5IDMgUlRUcywg d2hpY2ggY291bGQgYmUgcGVyY2VwdGlibGUgdG8NCj4gPiBlbmQgdXNlcnMuDQo+ID4gVGhlIGRy YWZ0IGV4cGxhaW5zOiB0aGUgcmVkdWN0aW9uIHRvIElXMSBpcyBpbiB0aGUgY2xpZW50IHRvIHNl cnZlcg0KPiA+IGRpcmVjdGlvbi4gSXQgY2l0ZXMgbWVhc3VyZW1lbnQgc3R1ZGllcyB0aGF0IHNo b3cgaXQncyB1bnVzdWFsIHRvIGdldCA+MQ0KPiA+IGluaXRpYWwgcGFja2V0IGluIHRoYXQgZGly ZWN0aW9uIGFueXdheS4gQW5kIHRoZSByZWR1Y3Rpb24gdG8gMSBpcyBvbmx5DQo+ID4gYSBTSE9V TEQuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGNob29zZSAyIGZvciBpbnN0YW5jZS4NCj4gPg0K PiA+IFdoZW4gbmV3IHRvIHRoZSBJRVRGLCBpdCdzIGV2ZW4gbW9yZSBpbXBvcnRhbnQgdG8gcmVh ZCB0aGUgZHJhZnQgYmVmb3JlDQo+ID4gc2VuZGluZyBjcml0aXF1ZSAoY29zIHlvdSB3b24ndCBo YXZlIGhlYXJkIGFsbCB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbikuDQo+ID4gT3RoZXJ3aXNlIGl0 IGJ1cm5zIGJ1c3kgcGVvcGxlJ3MgdGltZSBvbiB0aGUgbGlzdCB1bm5lY2Vzc2FyaWx5Lg0KPiAN Cj4gSSdkIGxpa2UgdG8gcmVtaW5kIHBlb3BsZSB0aGF0IGNvbW1lbnRzIGZyb20gcGVvcGxlIG5l dyB0byB0aGUgSUVURiBfYXJlXw0KPiB3ZWxjb21lIGluIFRDUE0gYW5kIGVsc2V3aGVyZSBpbiB0 aGUgSUVURi4NCj4gDQo+IE1pY2hhZWwgKGFzIGNoYWlyKQ0KDQpbRGF2aWQ+XSArMSAoYXMgYSBU U1ZXRyBjaGFpcikNCg== From nobody Thu Jul 25 13:27:39 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD562120276; Thu, 25 Jul 2019 13:27:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aJD7z656CLN; Thu, 25 Jul 2019 13:27:23 -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 F1390120279; Thu, 25 Jul 2019 13:27:22 -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=bDd6tiwC9rJ8PiN5t67Is0YpX1/gH9eZHo7ceDWvYVQ=; b=x2BNxfKrf2F/fT5FEiDIjPWPTQ 1ST0Tyc3BhwqI+sKDWDOrDCmg7iTiASqMCUN0DCsJiitcv9GmkMlUzybUUcr6n9/ZXF/tji6RMvj+ gomiqqNuMrYeoGW7/PBCG6C1kwYRL6Ba9JfmVV4YZlSLO8Zan677c2CgQh2q628DpQAIbRrAjxhdz Le9xHygVvC85h5d8V2q6+h+Y86JYZkUkFShXr8++NZ0oZ3Thkd8uxT/LsW0AUBA+kveoyJKtAm8Gv HqGsYLeQTNyAHVQgQguAvh3jyKzyBHlwWL+Zl31dLyaCm9ttnySyPlA9Bu+v5lZENmbrueVw1bXoF GMh4LhEg==; Received: from dhcp-9572.meeting.ietf.org ([31.133.149.114]:51306) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hqkKe-0006Qc-UE; Thu, 25 Jul 2019 21:27:21 +0100 To: Jonathan Morton Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" References: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> <89B2FD3D-4C10-489A-9867-538BABF3E521@gmail.com> From: Bob Briscoe Message-ID: <80a6f25b-9bb7-2812-eccb-15cc06772ab7@bobbriscoe.net> Date: Thu, 25 Jul 2019 16:27:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <89B2FD3D-4C10-489A-9867-538BABF3E521@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:27:31 -0000 Jonathan, On 25/07/2019 14:53, Jonathan Morton wrote: >> On 25 Jul, 2019, at 2:20 pm, Bob Briscoe wrote: >> >> The idea was to have a generic wire protocol with a dumb receiver, so that the same feedback protocol could support multiple needs for feedback by different TCP congestion control algorithms. >> >> So a fairly inefficient re-use of the 'NS' TCP header flag for one particular experiment is very unlikely to fly, particularly when the experiment it supports doesn't satisfy all the requirements in 7560. > AccECN burns the same bit to provide higher fidelity feedback of CE, without addressing our need to feed back the distinction between ECT(1) and ECT(0) at all (unless the TCP Option is used). Since higher fidelity feedback of CE is not useful for SCE, using NS in this way is actually more efficient for us. As you say, AccECN does support SCE - with the option. That was because it was generally agreed that accuracy of the CE signal was paramount, rather than trying to do two things with 3 bits and under-achieving for both. We did have another scheme with 5 & 3 codepoints in the 3 bits for two counters - look back over the draft history. But the WG decided simplicity was also important in a CC protocol, cos lack of bugs is also important. > Happily, AccECN and SCE can coexist on different flows, thanks to the fact that AccECN does have a negotiation phase which SCE can naturally reject. You will find there is resistance to starting to use the NS flag after having negotiated RFC3168 ECN feedback, but without any explicit negotiation. You will probably be asked how a future experiment would be able to use the NS flag if your experiment fails (assuming it is adopted as IETF work in the first place). You are walking into a world of bit scarcity. > >> For instance, I think the reason the tcpsce draft discusses multiple ways of doing the feedback is that, in the presence of pure ACK loss (which is often due to deliberate ACK thinning), none of the three solutions preserve reliable delivery of the ACK signal. > In SCE, *reliable* feedback of SCE signals is not actually required, both because the control loop is naturally stable, and because RFC-3168's CE feedback *is* reliable and thus offers a safe fallback. Of course we understand that the design constraints for L4S' feedback mechanism were different. My point wasn't so much about safety, it was about about accuracy and particularly biased error. The essence of low latency congestion control is keeping the queue low without losing utilization, which requires accuracy. If your feedback has a biased but unknown error, it's really hard to accurately converging towards a target. > > Ack thinning is also something we have explicitly considered, given that Cake includes an optional ack-filter which does exactly that. (We have, for example, added consideration of the NS bit to Cake's ack-filter, which was a trivial patch.) Mathematically, the most extreme errors possible in either direction, due to ack thinning, are easily corrected during subsequent RTTs. Exactly - if your feedback has a biased error, you will usually miss the target and try again in the next round. No point continuing this discussion - I'm just saying you'll need to see what happens in reality when the feedback is thinned. Bob > > - Jonathan Morton > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jul 26 01:55:47 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55711202E8; Fri, 26 Jul 2019 01:55:46 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ycy_MVuX8Rut; Fri, 26 Jul 2019 01:55:44 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E471202C5; Fri, 26 Jul 2019 01:55:44 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6Q8svPe027811; Fri, 26 Jul 2019 01:54:57 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6Q8svGR027810; Fri, 26 Jul 2019 01:54:57 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201907260854.x6Q8svGR027810@gndrsh.dnsmgr.net> In-Reply-To: <80a6f25b-9bb7-2812-eccb-15cc06772ab7@bobbriscoe.net> To: Bob Briscoe Date: Fri, 26 Jul 2019 01:54:57 -0700 (PDT) CC: Jonathan Morton , "tcpm@ietf.org" , "tsvwg@ietf.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 08:55:47 -0000 Bob, Responding to specifics of draft-grimes-tcpm-tcpsce-00.txt conversation in this thread as its author. > Jonathan, > > On 25/07/2019 14:53, Jonathan Morton wrote: > >> On 25 Jul, 2019, at 2:20 pm, Bob Briscoe wrote: > >> > >> The idea was to have a generic wire protocol with a dumb receiver, so that the same feedback protocol could support multiple needs for feedback by different TCP congestion control algorithms. > >> > >> So a fairly inefficient re-use of the 'NS' TCP header flag for one particular experiment is very unlikely to fly, particularly when the experiment it supports doesn't satisfy all the requirements in 7560. > > AccECN burns the same bit to provide higher fidelity feedback of CE, without addressing our need to feed back the distinction between ECT(1) and ECT(0) at all (unless the TCP Option is used). Since higher fidelity feedback of CE is not useful for SCE, using NS in this way is actually more efficient for us. > As you say, AccECN does support SCE - with the option. That was because > it was generally agreed that accuracy of the CE signal was paramount, > rather than trying to do two things with 3 bits and under-achieving for > both. It supports TCPSCE only in the sense that once AccECN TWH fails to find a L4S endpoint it does fall back to ECN as defined in RFC3168 which TCPSCE builds upon by reuse of the NS bit which was freed up by RFC8311 (to provide a feedback path for the higher fadelity SCE forward mark.) Further more by using this fall back position it means that none of the remaining AccENC TWH code points that exist today would need to be consumed in an attempt to negotiate this use. Given that many of the 8 code points created by doing the L4S TWH modifications are already consumed by L4S and that if you do the modified L4S handshake you gain access to all of the ECN TCP layer bits I feel it would be wasteful to consume that also limited resource for a single bit access to NS vs a possible future 3 bit access to (NS, ECE, CWR) > > We did have another scheme with 5 & 3 codepoints in the 3 bits for two > counters - look back over the draft history. But the WG decided > simplicity was also important in a CC protocol, cos lack of bugs is also > important. Intresting end phrase "lack of bugs is also important", I shall simply state that SCE and SCETCP as running code is a significantly small amount of code and the fact that a prototype working implementation was completed in ~24 man hours speaks to its simplicty and elagance of design. Though I would not qualify that as Internet deployable code, it was adaquate such that we could conduct experiments and debug the IP layer SCE marking code being implemented in a Linux versioned middle box. > > Happily, AccECN and SCE can coexist on different flows, thanks to the fact that AccECN does have a negotiation phase which SCE can naturally reject. > You will find there is resistance to starting to use the NS flag after > having negotiated RFC3168 ECN feedback, but without any explicit > negotiation. You will probably be asked how a future experiment would be > able to use the NS flag if your experiment fails (assuming it is adopted > as IETF work in the first place). You are walking into a world of bit > scarcity. See above, we are leaving the remaining AccECN TCP TWH code points open for future override of NS/ACE, ECE, and CWR rather than consume the code points left in that TWH to consome 1 bit in what is effectely an unused code point in the TWH (fall back to RFC3168 ECN). > > > > >> For instance, I think the reason the tcpsce draft discusses multiple ways of doing the feedback is that, in the presence of pure ACK loss (which is often due to deliberate ACK thinning), none of the three solutions preserve reliable delivery of the ACK signal. > > In SCE, *reliable* feedback of SCE signals is not actually required, both because the control loop is naturally stable, and because RFC-3168's CE feedback *is* reliable and thus offers a safe fallback. Of course we understand that the design constraints for L4S' feedback mechanism were different. > My point wasn't so much about safety, it was about about accuracy and > particularly biased error. The essence of low latency congestion control > is keeping the queue low without losing utilization, which requires > accuracy. If your feedback has a biased but unknown error, it's really > hard to accurately converging towards a target. We have found no issues in our testing thus far that would indicated that either of the (small) error amount or bias direction has a significant impact on the convergence rate or target of the closed loop system. Including doing a random drop of ack packet test. I can agree that the higher the accuracy of this feedback the better, but the solution is robust as designed. Much as you do not need super high accuracy input to a steering wheel to keep a car centered in its curving lane. I would not qualify this as "really hard to accurately converge", if it was most closed loop control loop systems would fail. If on the other hand it was open loop then the accuracy would need to be near perfect, is that the issue your trying to raise? > > > > > Ack thinning is also something we have explicitly considered, given that Cake includes an optional ack-filter which does exactly that. (We have, for example, added consideration of the NS bit to Cake's ack-filter, which was a trivial patch.) Mathematically, the most extreme errors possible in either direction, due to ack thinning, are easily corrected during subsequent RTTs. > Exactly - if your feedback has a biased error, you will usually miss the > target and try again in the next round. No point continuing this > discussion - I'm just saying you'll need to see what happens in reality > when the feedback is thinned. We are aware of the ack thinning concerns, and do plan to fully evaluate that as a potential problem, though to date our experiments indicate it is minimally impacting. There is also all the discussion going on about maybe ack thinning is not such a grand idea on its own merits. > > - Jonathan Morton > Bob Briscoe http://bobbriscoe.net/ -- Rod Grimes rgrimes@freebsd.org From nobody Fri Jul 26 06:06: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 9414112021D for ; Fri, 26 Jul 2019 06:06:34 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM9Yns2G-pVK for ; Fri, 26 Jul 2019 06:06:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C6F12012B for ; Fri, 26 Jul 2019 06:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564146390; bh=XpkHrlKGTgYnsoB3CzbrH935kDwhD4/BzaDXsU0LFhE=; h=X-UI-Sender-Class:Subject:References:To:From:Date:In-Reply-To; b=EFJxRf1z1fBC3RMXLgMMds+YvEf8VwGwagil92M+GYizJnhsivSoCxhRGjwi6hChb Z4d8GxlZMNqgtiSoy4bLHHCJVKHRK1hdoiwtSz8MUjJ7SZEJRVJhHiPVlAZpObT83O eGNlhErViraZlAZfxNsCOfrVnUTBhXg5GdsgkwM0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.18.210] ([66.171.165.154]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MWgND-1hsnCX2Fsx-00Xr94 for ; Fri, 26 Jul 2019 15:06:30 +0200 References: <46ecf9af-afb5-2d68-34e9-7d492c889920@gmx.at> To: "tcpm@ietf.org" From: "Scheffenegger, Richard" X-Forwarded-Message-Id: <46ecf9af-afb5-2d68-34e9-7d492c889920@gmx.at> Message-ID: Date: Fri, 26 Jul 2019 09:06:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <46ecf9af-afb5-2d68-34e9-7d492c889920@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:WWki5i8cyBpvwEyYJxejY95nHzv1t/ps6yIk0ud39bDdZ6aULwE 4RhZzScsyOly/nQxI56GPlh1cET+cBClyHEVlN4FSEizZYleke3M2jH/P8/saFPF5IFH3Ij 9tribNBJsaxJlKJ0CJICl6lY2nznK4s2DkyXw1yVfGzWoCXabGg3PzcZhpKyMEZQ4D1BHNm U/Vm6SQoJ8hE8Ec3zku+w== X-UI-Out-Filterresults: notjunk:1;V03:K0:027EeF6ESZI=:+kVjbjBnYyr2omXup7CGU+ PQxE8aqE9Mm4HF0eSouznZPWVWQi0t3ymI2u4ZZZYQqGxNhS/vbjHNGlttNwRuXav0+spsHZn aelhZFmu+V9O5otuWmaA4cFcUDuV6WNfYb5RPPyjkF2jLjXNecLP09zuA9j0oWy4f+ffX6K9r 0tMQuCGKaqz0o/jY481+N5uBSjO4I0kX7jqn1F3mzJypnOLbgh6IkjOPN5FPVwQMU6s+ZwG4T etWbtLBhpmYpUknXXEqu2b4ZKLSfXvBPHay0s2mVS4NsHx6Xt0wLrzl6u4wMKahD0bI05rd+g S28NZeWVYSlxmCmhu57wlVYK+GXBdh8I/s+j7+PXNA2Td3EvBTSqIIwgSmtie8ain5iG30emM TqoJEcgp5JyamdWZl+D2cLjWseY0mkrO/JqiAuWfXk9M70oy5qw04wzkgxfESQOiz5PCXBDtk GlJvRJByoY4K7G/9WM8EaEO4LilbHK5kQedGugZjQw2f/C9lPiC2DQPKET2NLSnFo4YkxwoeX bCszjkdy1rW3XQtvFqBVqaEuUhMNbHdgikn5p0IWsxmAVpu8FV715T8OSkN5dqv0ZFKosF5kl 08Hvc2hycpteLasMvkkVLQP8amg6AIYojKwRaL9Ogqc79DRkUChV8G1lYrWbtMu9O2hIITdas Pm8InigmoMeNpwRsA2Coo9MY6eHJUX1ZVGqNfwIzDZUaV5SPfhMSne+2R+W1o99G9s8G847U4 fSgPOeEFqOVyyE+Op9BzC93/cSq90Z4SVF9uFZ0Kzjv4v/LQ6+1Lb9TD+tNZv2M3A5lid6MOi kk7gEUGszkacKd5aQ6nEGD80ESWVWnTmvUcNqhNnDgHvTcbkrsNFpxFZzFKbegzgoXV11TDnW UEYzbMvZlHTLhcE0PAzK0Y2b97KxT421L/MAXuMHlvXMaJNauU8rPJ6h92uaX1BCeHVu5pKNO QpoTAo9G2IincnMRFGsIeBh6oXaFrJNVnwomhVntz7Rgtcj5TmDEKgJuVIzSdbbvNQOL00ow/ egcBrmyyjCaFFZ66iTr8oZfjn6J2e+6dJGqkoaH8ksKMGr3XDMhhHzn9tct/kBLScnfLcqsh7 YSW0BR9t1+z6EeFjxr7GSe0XO/URiXTIC6u Archived-At: Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 13:06:34 -0000 Hi, tl;dnr: I would like to have a discussion around the architecture of SCE first, before talking about the specific details of the signaling scheme. Nevertheless, I try to (again, after Bob) raise some concerns around the currently proposed scheme nevertheless. To chime in, I would like to take a step back in this discussion and understand the fundamental issues trying to be solved here. I have not yet fully understood the rationale for SCE, requiring two distinct, different CE signals. To me, it appears that the implicit design choice of SCE was for a router to add a "SCE" signal without any classification, if a particular flow does actually support SCE or not. That way, downstream routers from the SCE-enabled router can still add additional CE information - or the SCE router can give a signal of higher magnitude, if the endpoints ignored SCE - as would be initially be the norm. In comparison, the SCE signal appears to be functionally equivalent with the CE signal in the full L4S architecture (ECN++, ECT1-marked, AccECN feedback, separate Queues in routers) - where the end points expicitly inform the network of this change in the semantic of the CE signal, by virtue of an expicit signal (ECT1, or a DiffServ Codepoint, as currently being discussed). Effectively, in the L4S architecture, an individual CE mark carries much less "weight" than a 3168 CE mark - but a router is explicitly informed, which of the two "weights" a particular flow would work with. Now, some observations around the currently proposed SCE feedback scheme: I've read through both https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/ and https://datatracker.ietf.org/doc/draft-heist-tsvwg-sce-one-and-two-flow-te= sts Regarding the SCE signaling, my main feedback would be that the immediate ACKing when the receiver observes a ECT1 (or a change of state from CE to non-CE in the case of DCTCP) is brittle. It also "ossifies" the average proportion of ACKs vs data - while offload NICs try to get away with as few ACKs as possible (e.g. one per TSO/LRO/GRO superframe, which may be some 10s of packets - also Ack thinning, Ack compression, Ack loss). Early on during AccECN, we had a signaling strategy to reflect two codepoint-counters back for both ECT1 and CE, which was already pointed out by Bob. The idea was to split the 8 possible codepoints in a way to allow more reliable feedback without a 3168-like handshake method. As CE was deemed more important than ECT1, we had 3 codepoints assigned to the ECT1 counter (to signal a modulo 3 count of the number of received ECT1 marks) and 5 codepoints to a CE counter (modulo 5). A counter change would be reflected by inserting the associated codepoint into the next returned ACK. Otherwise, the two counters would be signaled alternatively (one ACK - however many data segments apart - would have the CE-related codepoint, the next ACK the ECT1 related codepoint). If both counters changed in between ACKs, CE would take precedence. During simulation of loss patterns (ack thinning), that approach showed dramatically better capability to reliably signal both counters back, except under the most extreme conditions. Obviously, different assignments of the codepoints would also be possible (e.g. 4 codepoints to CE, and 4 to ECT1; or even 3 CE, 3 ECT1, 2 ECT0...) depending on the situation. Again, the main benefit under steady state would be to allow some ACK thinning or longer gaps in delayed ACKs (while also allowing some ACK loss as well), making the feedback signal path much less brittle... And I also want to point out, that with the current AccECN draft, the ship has not yet sailed in the sense that we no longer can do any alternative experiments with a different feedback schema. The AccECN draft clearly states, that future extension is possible. On the , only the combinations of <0,0,0> (no-ecn), <0,1,1> (3168 ecn), and <1,1,1> (accecn) are explicitly used. A variant of the AccECN handshake can be used, to negotiate for a different receiver-side behavior - while a receiver conforming to the current accecn draft would at least provide reliabe CE information. I will look into the scenarios of SCE (which IMHO should be divorced from a specific feedback schema - it's really an additional, less dramatic signal from the network about congestion, than 3168 CE. On a high level, the observation that a ramped probability marking provides some benefits over a step-change probability matches what has been reported before from other researchers. Or to summarize: The step-change in marking from 0% to 100% at a specific threshold of instantaneous queue depth, as described in DCTCP, is not the most effective way... Am 26.07.2019 um 04:54 schrieb Rodney W. Grimes: > Bob, > > Responding to specifics of draft-grimes-tcpm-tcpsce-00.txt > conversation in this thread as its author. > >> Jonathan, >> >> On 25/07/2019 14:53, Jonathan Morton wrote: >>>> On 25 Jul, 2019, at 2:20 pm, Bob Briscoe wrote: >>>> >>>> The idea was to have a generic wire protocol with a dumb receiver, so= that the same feedback protocol could support multiple needs for feedback= by different TCP congestion control algorithms. >>>> >>>> So a fairly inefficient re-use of the 'NS' TCP header flag for one pa= rticular experiment is very unlikely to fly, particularly when the experim= ent it supports doesn't satisfy all the requirements in 7560. >>> AccECN burns the same bit to provide higher fidelity feedback of CE, w= ithout addressing our need to feed back the distinction between ECT(1) and= ECT(0) at all (unless the TCP Option is used). Since higher fidelity fee= dback of CE is not useful for SCE, using NS in this way is actually more e= fficient for us. >> As you say, AccECN does support SCE - with the option. That was because >> it was generally agreed that accuracy of the CE signal was paramount, >> rather than trying to do two things with 3 bits and under-achieving for >> both. > > It supports TCPSCE only in the sense that once AccECN TWH fails > to find a L4S endpoint it does fall back to ECN as defined in > RFC3168 which TCPSCE builds upon by reuse of the NS bit which > was freed up by RFC8311 (to provide a feedback path for the > higher fadelity SCE forward mark.) > > Further more by using this fall back position it means that > none of the remaining AccENC TWH code points that exist today > would need to be consumed in an attempt to negotiate this use. > > Given that many of the 8 code points created by doing the L4S > TWH modifications are already consumed by L4S and that if you > do the modified L4S handshake you gain access to all of the > ECN TCP layer bits I feel it would be wasteful to consume that > also limited resource for a single bit access to NS vs a possible > future 3 bit access to (NS, ECE, CWR) > >> >> We did have another scheme with 5 & 3 codepoints in the 3 bits for two >> counters - look back over the draft history. But the WG decided >> simplicity was also important in a CC protocol, cos lack of bugs is als= o >> important. > > Intresting end phrase "lack of bugs is also important", I shall simply > state that SCE and SCETCP as running code is a significantly small amoun= t > of code and the fact that a prototype working implementation was complet= ed > in ~24 man hours speaks to its simplicty and elagance of design. > > Though I would not qualify that as Internet deployable code, it was > adaquate such that we could conduct experiments and debug the IP > layer SCE marking code being implemented in a Linux versioned middle box= . > >>> Happily, AccECN and SCE can coexist on different flows, thanks to t= he fact that AccECN does have a negotiation phase which SCE can naturally = reject. >> You will find there is resistance to starting to use the NS flag after >> having negotiated RFC3168 ECN feedback, but without any explicit >> negotiation. You will probably be asked how a future experiment would b= e >> able to use the NS flag if your experiment fails (assuming it is adopte= d >> as IETF work in the first place). You are walking into a world of bit >> scarcity. > > See above, we are leaving the remaining AccECN TCP TWH code points > open for future override of NS/ACE, ECE, and CWR rather than consume > the code points left in that TWH to consome 1 bit in what is effectely > an unused code point in the TWH (fall back to RFC3168 ECN). > > >> >>> >>>> For instance, I think the reason the tcpsce draft discusses multiple = ways of doing the feedback is that, in the presence of pure ACK loss (whic= h is often due to deliberate ACK thinning), none of the three solutions pr= eserve reliable delivery of the ACK signal. >>> In SCE, *reliable* feedback of SCE signals is not actually required, b= oth because the control loop is naturally stable, and because RFC-3168's C= E feedback *is* reliable and thus offers a safe fallback. Of course we un= derstand that the design constraints for L4S' feedback mechanism were diff= erent. >> My point wasn't so much about safety, it was about about accuracy and >> particularly biased error. The essence of low latency congestion contro= l >> is keeping the queue low without losing utilization, which requires >> accuracy. If your feedback has a biased but unknown error, it's really >> hard to accurately converging towards a target. > > We have found no issues in our testing thus far that would indicated > that either of the (small) error amount or bias direction has a signific= ant > impact on the convergence rate or target of the closed loop system. > Including doing a random drop of ack packet test. I can agree that the > higher the accuracy of this feedback the better, but the solution is rob= ust > as designed. Much as you do not need super high accuracy input to > a steering wheel to keep a car centered in its curving lane. > > I would not qualify this as "really hard to accurately converge", > if it was most closed loop control loop systems would fail. If > on the other hand it was open loop then the accuracy would need > to be near perfect, is that the issue your trying to raise? > >> >>> >>> Ack thinning is also something we have explicitly considered, given th= at Cake includes an optional ack-filter which does exactly that. (We have= , for example, added consideration of the NS bit to Cake's ack-filter, whi= ch was a trivial patch.) Mathematically, the most extreme errors possible= in either direction, due to ack thinning, are easily corrected during sub= sequent RTTs. >> Exactly - if your feedback has a biased error, you will usually miss th= e >> target and try again in the next round. No point continuing this >> discussion - I'm just saying you'll need to see what happens in reality >> when the feedback is thinned. > > We are aware of the ack thinning concerns, and do plan to fully evaluate > that as a potential problem, though to date our experiments indicate it > is minimally impacting. There is also all the discussion going on about > maybe ack thinning is not such a grand idea on its own merits. > >>> - Jonathan Morton >> Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jul 26 08:17:33 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8712015B for ; Fri, 26 Jul 2019 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhsmmIWPlDJR for ; Fri, 26 Jul 2019 08:17: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 209DD1201C8 for ; Fri, 26 Jul 2019 08:17:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7A08325A19 for ; Fri, 26 Jul 2019 17:17:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1564154242; bh=MQegyP3DHJHGj9dhwODAdPTpFY+q+WDQYJXrwq4z4KA=; h=From:To:Subject:Date:From; b=k5CY/NZz/arPI0++kvuG0Ypr2UVzTpJwqkxafYnMTsJJsB9sX7k/pQzkTaYNYJQ0g FAgkJcPfGkgXfSa9NElNsIfHIU6qiD7VXurbsmeFAi6VKnfTGIf37c5WQeECceDGOw 5TKn/Yh6KFcsR1Lo/FPqrVmoTrhMPOqnOEL9WVpk= 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 agx2RQpTAzaP for ; Fri, 26 Jul 2019 17:17:21 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Fri, 26 Jul 2019 17:17:21 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 26 Jul 2019 17:17:21 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: Please review 793bis! Thread-Index: AdVDxBaWqg1nKqsFQCmaSvOixpeJnw== Date: Fri, 26 Jul 2019 15:17:20 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@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] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 26 Jul 2019 15:17:32 -0000 Hi all, As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis in o= rder to complete this important TCPM milestone. The draft can be found at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 If you care about TCP (after all you have decided to subscribe the TCPM lis= t for some reason, no?), please try to find some cycles and please have a l= ook at this document. Thanks Michael From nobody Sat Jul 27 18:44: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 1AF5C120047 for ; Sat, 27 Jul 2019 18:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbwKaDdbO48m for ; Sat, 27 Jul 2019 18:44:00 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5466F1200CD for ; Sat, 27 Jul 2019 18:44:00 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6S1h0rw010458; Sat, 27 Jul 2019 18:43:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=/D4geg4VaTOUfuT7hV+aP94jG5Mga5rq3ipNqnbMrdE=; b=Fv6qs+X9FLzTEA9joefzvKvkuy9Q8PNocjqhGV5w4x/2yvIDky14+t8/QaTRRjV1Rzdu zs3VHd0ezHMEMDzDuuXL34RzmKAYxiJXNtVZx/oG6cmRSkUj9CSVgd5Bhqvcu9jDe+5M BbAXHoQS6AF0Rkqo+Ep+WdX81OW08QpdOMT2BO1IKkDHKjpCJH31b1rMkV6r4vcNHtvi jfLRNKZFyabYDFeoFPidkCXRCQ10o0rGui/z8umb/oB/gup/I6X8vYqP7zdsclAUFU8o O+WAnv+Zdo0Mcttya+GD/jh1LNIVbsjhsgHKEstb70phP1a8bkMT9MHzMSuEmFwVRZjl AA== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2u0nj0tyjh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 27 Jul 2019 18:43:54 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PVB004FHWT6MC10@mr2-mtap-s02.rno.apple.com>; Sat, 27 Jul 2019 18:43:54 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PVB00B00WNJZC00@nwk-mmpp-sz12.apple.com>; Sat, 27 Jul 2019 18:43:54 -0700 (PDT) X-Va-A: X-Va-T-CD: 117aa55c2a658cd4023c3a43898c6033 X-Va-E-CD: 69be58a359e0ce403bce9bb83fb8fd92 X-Va-R-CD: 619c007249ad5d72124eaeedc31aa69f X-Va-CD: 0 X-Va-ID: 4a942f39-c2f2-4ebd-bdf5-4cc9ebc9024c X-V-A: X-V-T-CD: 117aa55c2a658cd4023c3a43898c6033 X-V-E-CD: 69be58a359e0ce403bce9bb83fb8fd92 X-V-R-CD: 619c007249ad5d72124eaeedc31aa69f X-V-CD: 0 X-V-ID: 42808d99-6bbb-4da1-8286-30024349938d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-27_18:,, signatures=0 Received: from [17.235.29.98] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PVB00M5PWT4RB30@nwk-mmpp-sz12.apple.com>; Sat, 27 Jul 2019 18:43:54 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Sat, 27 Jul 2019 21:43:46 -0400 References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" , "tcpm@ietf.org" In-reply-to: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> Message-id: <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-27_18:, , signatures=0 Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jul 2019 01:44:03 -0000 Hi Michael, Thanks for the note about this (indeed important!) document. I = unfortunately had a conflict for tcpm, so missed the recent meeting, but = I do have some questions about what the group wants to see in reviews of = this document. As expected, much of the text remains unchanged from RFC793. While I = understand and agree that it is a non-goal to change any behavior, = reading the document does still feel like it is out of place amongst = current RFCs from a terminology and organizational standpoint. If this = is going to be published as a full STD document, it would be great to = have something that also makes the reading clearer and easier for people = new to TCP. Specifically, as some people are now working on = implementations of TCP for user space stacks or minimal IoT devices, a = clean reference would be a fantastic asset. Some initial examples of changes that came to mind: - Structure; there is both a Terminology section (3.2) relatively early = on, and a glossary (3.11) near the end. It seems more typical nowadays = to have a terminology section up front, and just refer inline to = supporting documents (like IP, for example). - Many of the RFCs referenced are the older or obsoleted versions - Consistency and freshness; some of the terminology feels dated, such = as "the local and remote socket numbers" for referring to what is called = "port numbers" elsewhere in the document and in current parlance. There's a lot of possible work to be done here, so before people embark = on such reviews, can you clarify which of these categories of input are = useful, and would be incorporated? Best Tommy > On Jul 26, 2019, at 11:17 AM, Scharf, Michael = wrote: >=20 > Hi all, >=20 > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis = in order to complete this important TCPM milestone. The draft can be = found at: >=20 > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 >=20 > If you care about TCP (after all you have decided to subscribe the = TCPM list for some reason, no?), please try to find some cycles and = please have a look at this document. >=20 > Thanks >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Jul 27 19:07: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 171331200D5 for ; Sat, 27 Jul 2019 19:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArCWxP3IYisI for ; Sat, 27 Jul 2019 19:07:10 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D575120047 for ; Sat, 27 Jul 2019 19:07:10 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id 65so42910906oid.13 for ; Sat, 27 Jul 2019 19:07:10 -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=qobWVkLL87KHEi5RdMAfhRU3vEnz89tdorQU/FFCTl8=; b=UqwD1rpt1ubUrwFZa3cF0GuKT4EiVWapt48xfd4Q6BcPIVGqa1hoZDMi1VDicYkeE3 NcxdnDMaO6IA/2jFo9O2mv36MyounX8gY+YAgFljrPKltVmeJmiNpuLbFn3vzDRJM1DO PtUJ8q2PMJh+/ZbCE+O9IbytVR6dzWzrFsk0fK0ZHx6z2u34XBqvU49uPQGmJM5fDpE1 MLIssTAfajzYwz3XUiZqoLHYtbCH+kHhC02r04rGBSihP7AYi5qiCms3ekEK1tpN+dUx xibKF3wWBcmICOxSjP5RVO/PzEHIbGc+aMiE6+KMgHdPmA5EXpMPj5v4h+wQcFJyKAsr eTew== 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=qobWVkLL87KHEi5RdMAfhRU3vEnz89tdorQU/FFCTl8=; b=sBqqDIjQZAXZKjTX6GOgxlmd+QY+4yi+2kUrgU2RmyAq50Jcwht/hqP7iQ4s5WfLfL FTivFDUUB1vL403XhBaI9AUVCjLwm5dmtqallz8hOAaBCGvU4Ls4FvvlQ3/dbAEjQmyU FVwGG87hl1Tsb2TNsntHkVAgBY4Ao3/M+jYl+H/Nh7I6e2cc+WY77VaSPxUo/Tf8BuG3 hKXgJ6M4Zk1PvasvDte9ArZ15Ytm9h6Ud8ENAGOK8VW0kz7IkFqDc5lMufbp9qd2ABYa I3lDP2d0K29nKPuiY6EhRFlPjjoUMzojTUSQKaj3GlRD170un2TCHSHfu0xUpWPNT0Qy RHlQ== X-Gm-Message-State: APjAAAVzUlRNTT+FR4AyFiRQghO9l6Lkrfjqm8IRjUcvrk4IGi2ECt+A uL4tPRSVWTIK3/wala0hNHe1W3myvZMPwBjZL3A= X-Google-Smtp-Source: APXvYqzDkQAwUKOSQ+mCTxUBjNelBVrCDPOwZ9Nn+wCgX4NbsWLI9DyqvqFCfxdpje4hcIEszdwWyhojmEchSBZJkyY= X-Received: by 2002:aca:b406:: with SMTP id d6mr49983847oif.173.1564279629666; Sat, 27 Jul 2019 19:07:09 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> In-Reply-To: <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> From: Tim Wicinski Date: Sat, 27 Jul 2019 22:06:58 -0400 Message-ID: To: Tommy Pauly Cc: "Scharf, Michael" , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a7ddb5058eb43b56" Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jul 2019 02:07:13 -0000 --000000000000a7ddb5058eb43b56 Content-Type: text/plain; charset="UTF-8" Tommy For Implementation advice, I would refer people to the TCP Roadmap document (rfc7414) which feels to me to be a better location. rfc7414 (or what may be the best location) should be spelled out more clearly to readers. I noticed on reading through the document structure, there are references to RFC793, yet the document is being Obsoleted. If we're obsoleting an entire document, is it wise to refer back to it? Does that confuse a casual reader? If there are references to the 793, such as in Section 2, I think it should be included. Tim On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly wrote: > Hi Michael, > > Thanks for the note about this (indeed important!) document. I > unfortunately had a conflict for tcpm, so missed the recent meeting, but I > do have some questions about what the group wants to see in reviews of this > document. > > As expected, much of the text remains unchanged from RFC793. While I > understand and agree that it is a non-goal to change any behavior, reading > the document does still feel like it is out of place amongst current RFCs > from a terminology and organizational standpoint. If this is going to be > published as a full STD document, it would be great to have something that > also makes the reading clearer and easier for people new to TCP. > Specifically, as some people are now working on implementations of TCP for > user space stacks or minimal IoT devices, a clean reference would be a > fantastic asset. > > Some initial examples of changes that came to mind: > > - Structure; there is both a Terminology section (3.2) relatively early > on, and a glossary (3.11) near the end. It seems more typical nowadays to > have a terminology section up front, and just refer inline to supporting > documents (like IP, for example). > - Many of the RFCs referenced are the older or obsoleted versions > - Consistency and freshness; some of the terminology feels dated, such as > "the local and remote socket numbers" for referring to what is called "port > numbers" elsewhere in the document and in current parlance. > > There's a lot of possible work to be done here, so before people embark on > such reviews, can you clarify which of these categories of input are > useful, and would be incorporated? > > Best > Tommy > > > On Jul 26, 2019, at 11:17 AM, Scharf, Michael < > Michael.Scharf@hs-esslingen.de> wrote: > > > > Hi all, > > > > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis > in order to complete this important TCPM milestone. The draft can be found > at: > > > > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 > > > > If you care about TCP (after all you have decided to subscribe the TCPM > list for some reason, no?), please try to find some cycles and please have > a look at this document. > > > > Thanks > > > > Michael > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000a7ddb5058eb43b56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tommy

For Implementation advice, I would refer peop= le to the TCP Roadmap document (rfc7414) which feels to me to be a better l= ocation.=C2=A0
rfc7414 (or what may be the best location) should = be spelled out more clearly to readers.

I noti= ced on reading through the document structure, there are references to RFC7= 93, yet the document is being Obsoleted.=C2=A0
If we're obsol= eting an entire document, is it wise to refer back to it?=C2=A0 Does that c= onfuse a casual reader? =C2=A0 If there are references to the=C2=A0
793, such=
 as in Section 2, I think it should be included. 

Tim


<= br>

On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly <= tpauly=3D40apple.com@dmarc.ie= tf.org> wrote:
Hi Michael,

Thanks for the note about this (indeed important!) document. I unfortunatel= y had a conflict for tcpm, so missed the recent meeting, but I do have some= questions about what the group wants to see in reviews of this document.
As expected, much of the text remains unchanged from RFC793. While I unders= tand and agree that it is a non-goal to change any behavior, reading the do= cument does still feel like it is out of place amongst current RFCs from a = terminology and organizational standpoint. If this is going to be published= as a full STD document, it would be great to have something that also make= s the reading clearer and easier for people new to TCP. Specifically, as so= me people are now working on implementations of TCP for user space stacks o= r minimal IoT devices, a clean reference would be a fantastic asset.

Some initial examples of changes that came to mind:

- Structure; there is both a Terminology section (3.2) relatively early on,= and a glossary (3.11) near the end. It seems more typical nowadays to have= a terminology section up front, and just refer inline to supporting docume= nts (like IP, for example).
- Many of the RFCs referenced are the older or obsoleted versions
- Consistency and freshness; some of the terminology feels dated, such as &= quot;the local and remote socket numbers" for referring to what is cal= led "port numbers" elsewhere in the document and in current parla= nce.

There's a lot of possible work to be done here, so before people embark= on such reviews, can you clarify which of these categories of input are us= eful, and would be incorporated?

Best
Tommy

> On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs-esslingen= .de> wrote:
>
> Hi all,
>
> As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis= in order to complete this important TCPM milestone. The draft can be found= at:
>
> https://tools.ietf.org/html/draft-ietf-= tcpm-rfc793bis-13
>
> If you care about TCP (after all you have decided to subscribe the TCP= M list for some reason, no?), please try to find some cycles and please hav= e a look at this document.
>
> Thanks
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000a7ddb5058eb43b56-- From nobody Sun Jul 28 02:58: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 9FA77120127 for ; Sun, 28 Jul 2019 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcuvSjCKhRAB for ; Sun, 28 Jul 2019 02:58:00 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 924D812012B for ; Sun, 28 Jul 2019 02:58:00 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6S9vlVf025050; Sun, 28 Jul 2019 02:57:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=SInhn6C8ZNY3H/eTwrCzjqEKjlW/TPOKOkWl5HuL+rk=; b=qIfX4NLxZNHRRrY5rAFjxe14QGK9Xz0I9FBRkePu/mOf0ExcTEo54GH+Iys5J6riv5nM FarSrATtedy+gT9KHF/oD0Swg+EoVds3nWG4Mg+pHCje8hFy+yCn74WrvbQ7xYcswsR+ PxOz5N7c77iRbq+L1iVntm1kOSQO3alzysyHe6le7d8g9dJRxnWBdt5ObP6RLPBHH0UO 3VljVGVEdKG4nJlpM0YXh3bv/+EaBGi6WV8hAIjSQyUMcwI0plb4SC7zpXR6DkWWeMgb RaZ+ol3V/O0gZIFdq9vbMuasjhzxuY4TOafWDD1/7LMwA2rd9DL7jgR7q4WeHYXyYrOQ VQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2u0k9r0u0q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 28 Jul 2019 02:57:57 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PVC00HGBJOKWZ40@ma1-mtap-s03.corp.apple.com>; Sun, 28 Jul 2019 02:57:57 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PVC00M00JM41200@nwk-mmpp-sz12.apple.com>; Sun, 28 Jul 2019 02:57:56 -0700 (PDT) X-Va-A: X-Va-T-CD: 5849e56780e9b915ed7e1028c762dea6 X-Va-E-CD: 69be58a359e0ce403bce9bb83fb8fd92 X-Va-R-CD: 619c007249ad5d72124eaeedc31aa69f X-Va-CD: 0 X-Va-ID: f73ab304-9b7e-446a-a849-9d8e917db8f7 X-V-A: X-V-T-CD: 5849e56780e9b915ed7e1028c762dea6 X-V-E-CD: 69be58a359e0ce403bce9bb83fb8fd92 X-V-R-CD: 619c007249ad5d72124eaeedc31aa69f X-V-CD: 0 X-V-ID: 000f1887-d9a3-4979-91ab-a89897327a5c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-28_05:,, signatures=0 Received: from [17.235.41.99] (unknown [17.235.41.99]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PVC000HOJOJ7G20@nwk-mmpp-sz12.apple.com>; Sun, 28 Jul 2019 02:57:55 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary=Apple-Mail-F376E3E2-1E35-4EFC-855D-A7CD98FAAC14 Content-transfer-encoding: 7bit From: Tommy Pauly MIME-version: 1.0 (1.0) Date: Sun, 28 Jul 2019 05:57:53 -0400 Message-id: References: Cc: Tommy Pauly , "tcpm@ietf.org" In-reply-to: To: Tim Wicinski X-Mailer: iPhone Mail (17A5534f) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-28_05:, , signatures=0 Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jul 2019 09:58:03 -0000 --Apple-Mail-F376E3E2-1E35-4EFC-855D-A7CD98FAAC14 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tim, > On Jul 27, 2019, at 10:07 PM, Tim Wicinski wrote: >=20 > =EF=BB=BF > Tommy >=20 > For Implementation advice, I would refer people to the TCP Roadmap documen= t (rfc7414) which feels to me to be a better location.=20 > rfc7414 (or what may be the best location) should be spelled out more clea= rly to readers. Indeed! I was not suggesting that there be any implementation guidance in th= is document. Rather, I was suggesting that modernizing some of the structure= and terminology would make the document more easily accessible to readers.=20= >=20 > I noticed on reading through the document structure, there are references t= o RFC793, yet the document is being Obsoleted.=20 > If we're obsoleting an entire document, is it wise to refer back to it? D= oes that confuse a casual reader? If there are references to the=20 > 793, such as in Section 2, I think it should be included.=20 >=20 Right. I assume these references would need to be updated to refer within th= is document, as a link to an interior anchor point.=20 Tommy > Tim >=20 >=20 >=20 >=20 >> On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly wrote: >> Hi Michael, >>=20 >> Thanks for the note about this (indeed important!) document. I unfortunat= ely had a conflict for tcpm, so missed the recent meeting, but I do have som= e questions about what the group wants to see in reviews of this document. >>=20 >> As expected, much of the text remains unchanged from RFC793. While I unde= rstand and agree that it is a non-goal to change any behavior, reading the d= ocument does still feel like it is out of place amongst current RFCs from a t= erminology and organizational standpoint. If this is going to be published a= s a full STD document, it would be great to have something that also makes t= he reading clearer and easier for people new to TCP. Specifically, as some p= eople are now working on implementations of TCP for user space stacks or min= imal IoT devices, a clean reference would be a fantastic asset. >>=20 >> Some initial examples of changes that came to mind: >>=20 >> - Structure; there is both a Terminology section (3.2) relatively early o= n, and a glossary (3.11) near the end. It seems more typical nowadays to hav= e a terminology section up front, and just refer inline to supporting docume= nts (like IP, for example). >> - Many of the RFCs referenced are the older or obsoleted versions >> - Consistency and freshness; some of the terminology feels dated, such as= "the local and remote socket numbers" for referring to what is called "port= numbers" elsewhere in the document and in current parlance. >>=20 >> There's a lot of possible work to be done here, so before people embark o= n such reviews, can you clarify which of these categories of input are usefu= l, and would be incorporated? >>=20 >> Best >> Tommy >>=20 >> > On Jul 26, 2019, at 11:17 AM, Scharf, Michael wrote: >> >=20 >> > Hi all, >> >=20 >> > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis i= n order to complete this important TCPM milestone. The draft can be found at= : >> >=20 >> > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 >> >=20 >> > If you care about TCP (after all you have decided to subscribe the TCPM= list for some reason, no?), please try to find some cycles and please have a= look at this document. >> >=20 >> > Thanks >> >=20 >> > Michael >> >=20 >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-F376E3E2-1E35-4EFC-855D-A7CD98FAAC14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tim,

On Jul 27, 2019, at 10:07 PM, Tim Wicinski <tjw.ietf@gmail.com> wro= te:

=EF= =BB=BF
To= mmy

For Implementation advice, I would refer p= eople to the TCP Roadmap document (rfc7414) which feels to me to be a better= location. 
rfc7414 (or what may be the best location) should= be spelled out more clearly to readers.

Indeed! I was not suggesting that there be a= ny implementation guidance in this document. Rather, I was suggesting that m= odernizing some of the structure and terminology would make the document mor= e easily accessible to readers. 

I noticed on reading through the document structure, there= are references to RFC793, yet the document is being Obsoleted. 
<= div>If we're obsoleting an entire document, is it wise to refer back to it?&= nbsp; Does that confuse a casual reader?   If there are references to t= he 
793, such as in Section 2, I think it should be included.


Right. I assume th= ese references would need to be updated to refer within this document, as a l= ink to an interior anchor point. 

Tommy
<= br>
Tim



=

On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote= :
Hi Michael,

Thanks for the note about this (indeed important!) document. I unfortunately= had a conflict for tcpm, so missed the recent meeting, but I do have some q= uestions about what the group wants to see in reviews of this document.

As expected, much of the text remains unchanged from RFC793. While I underst= and and agree that it is a non-goal to change any behavior, reading the docu= ment does still feel like it is out of place amongst current RFCs from a ter= minology and organizational standpoint. If this is going to be published as a= full STD document, it would be great to have something that also makes the r= eading clearer and easier for people new to TCP. Specifically, as some peopl= e are now working on implementations of TCP for user space stacks or minimal= IoT devices, a clean reference would be a fantastic asset.

Some initial examples of changes that came to mind:

- Structure; there is both a Terminology section (3.2) relatively early on, a= nd a glossary (3.11) near the end. It seems more typical nowadays to have a t= erminology section up front, and just refer inline to supporting documents (= like IP, for example).
- Many of the RFCs referenced are the older or obsoleted versions
- Consistency and freshness; some of the terminology feels dated, such as "t= he local and remote socket numbers" for referring to what is called "port nu= mbers" elsewhere in the document and in current parlance.

There's a lot of possible work to be done here, so before people embark on s= uch reviews, can you clarify which of these categories of input are useful, a= nd would be incorporated?

Best
Tommy

> On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs-esslingen..= de> wrote:
>
> Hi all,
>
> As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis i= n order to complete this important TCPM milestone. The draft can be found at= :
>
> https://tools.ietf.org/html/draft-ietf-tc= pm-rfc793bis-13
>
> If you care about TCP (after all you have decided to subscribe the TCPM= list for some reason, no?), please try to find some cycles and please have a= look at this document.
>
> Thanks
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm m= ailing list
tcpm@ietf.org
https://www.ietf.o= rg/mailman/listinfo/tcpm
= --Apple-Mail-F376E3E2-1E35-4EFC-855D-A7CD98FAAC14-- From nobody Sun Jul 28 04:21:55 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B00F120139 for ; Sun, 28 Jul 2019 04:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwK7a2_9fgf8 for ; Sun, 28 Jul 2019 04:21:52 -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 1BAB11200E7 for ; Sun, 28 Jul 2019 04:21:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1884925A1E; Sun, 28 Jul 2019 13:21:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1564312910; bh=ydWGpmj6SyOg0ZJkIrgHdc9ngwADCqJaWqM3YJI23V8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=EKMhpdFDnslABzKQu3Lgt0TYYAhWpTMQk/AN0gIAO/iCChiFKHg8Lu5F2rDFDYk7q 1URfUvXGn/u3p3HZJSc9eLhLMAldiV5viK/l2solaGtZj+4IVga3NvNSU3ziQ2IGcn IwpL2C3xGaPoCaSoZxZ7qCHytW2yeTHZSLTuWZu0= 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 5Dr4jT0uNMWQ; Sun, 28 Jul 2019 13:21:48 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 28 Jul 2019 13:21:48 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 28 Jul 2019 13:21:48 +0200 From: "Scharf, Michael" To: Tommy Pauly , "tcpm@ietf.org" Thread-Topic: [tcpm] Please review 793bis! Thread-Index: AdVDxBaWqg1nKqsFQCmaSvOixpeJnwBEQsEAABhg9Fk= Date: Sun, 28 Jul 2019 11:21:48 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3CD44B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de>, <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> In-Reply-To: <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3CD44Brznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 Jul 2019 11:21:54 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3CD44Brznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tommy, _any_ feedback is welcome. This is a -bis document and it is not intended to change the TCP standards.= Within that limit, we should try to come up with the best document we can.= The document is owned by the working group. The question what changes will= be incorporated is up to the working group as a whole. On that, I have not= more to say than any other contributor to TCPM=85 Personally, I think that your points are all valid concerns and I can think= of ways this can be addressed (at least partially) without disrupting the = document. But I=92ll leave it to the document editor to comment on the impa= ct. In a nutshell, I believe your input falls within the very useful categories= . Please continue. For instance, if there are other terms that may be outda= ted, flag them and let us know. Thanks a lot! Michael Von: Tommy Pauly Gesendet: Sonntag, 28. Juli 2019 03:44 An: Scharf, Michael; tcpm@ietf.org Betreff: Re: [tcpm] Please review 793bis! Hi Michael, Thanks for the note about this (indeed important!) document. I unfortunatel= y had a conflict for tcpm, so missed the recent meeting, but I do have some= questions about what the group wants to see in reviews of this document. As expected, much of the text remains unchanged from RFC793. While I unders= tand and agree that it is a non-goal to change any behavior, reading the do= cument does still feel like it is out of place amongst current RFCs from a = terminology and organizational standpoint. If this is going to be published= as a full STD document, it would be great to have something that also make= s the reading clearer and easier for people new to TCP. Specifically, as so= me people are now working on implementations of TCP for user space stacks o= r minimal IoT devices, a clean reference would be a fantastic asset. Some initial examples of changes that came to mind: - Structure; there is both a Terminology section (3.2) relatively early on,= and a glossary (3.11) near the end. It seems more typical nowadays to have= a terminology section up front, and just refer inline to supporting docume= nts (like IP, for example). - Many of the RFCs referenced are the older or obsoleted versions - Consistency and freshness; some of the terminology feels dated, such as "= the local and remote socket numbers" for referring to what is called "port = numbers" elsewhere in the document and in current parlance. There's a lot of possible work to be done here, so before people embark on = such reviews, can you clarify which of these categories of input are useful= , and would be incorporated? Best Tommy > On Jul 26, 2019, at 11:17 AM, Scharf, Michael wrote: > > Hi all, > > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis in= order to complete this important TCPM milestone. The draft can be found at= : > > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 > > If you care about TCP (after all you have decided to subscribe the TCPM l= ist for some reason, no?), please try to find some cycles and please have a= look at this document. > > Thanks > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --_000_6EC6417807D9754DA64F3087E2E2E03E2D3CD44Brznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Tommy,

 

_any_ feedback is welcome.

 

This is a -bis document and it is not intended to = change the TCP standards. Within that limit, we should try to come up with = the best document we can. The document is owned by the working group. The q= uestion what changes will be incorporated is up to the working group as a whole. On that, I have not more to say tha= n any other contributor to TCPM=85

 

Personally, I think that your points are all valid= concerns and I can think of ways this can be addressed (at least partially= ) without disrupting the document. But I=92ll leave it to the document edit= or to comment on the impact.

 

In a nutshell, I believe your input falls within t= he very useful categories. Please continue. For instance, if there are othe= r terms that may be outdated, flag them and let us know.

 

Thanks a lot!

 

Michael

 

Von: Tommy Pauly
Gesendet: Sonntag, 28. Juli 2019 03:44
An: Scharf, Michae= l; tcpm@ietf.org
Betreff: Re: [tcpm] Please review 793bis!

 

Hi Michael,

Thanks for the note about this (indeed important!) document. I unfortunatel= y had a conflict for tcpm, so missed the recent meeting, but I do have some= questions about what the group wants to see in reviews of this document.
As expected, much of the text remains unchanged from RFC793. While I unders= tand and agree that it is a non-goal to change any behavior, reading the do= cument does still feel like it is out of place amongst current RFCs from a = terminology and organizational standpoint. If this is going to be published as a full STD document, it would be great= to have something that also makes the reading clearer and easier for peopl= e new to TCP. Specifically, as some people are now working on implementatio= ns of TCP for user space stacks or minimal IoT devices, a clean reference would be a fantastic asset.

Some initial examples of changes that came to mind:

- Structure; there is both a Terminology section (3.2) relatively early on,= and a glossary (3.11) near the end. It seems more typical nowadays to have= a terminology section up front, and just refer inline to supporting docume= nts (like IP, for example).
- Many of the RFCs referenced are the older or obsoleted versions
- Consistency and freshness; some of the terminology feels dated, such as &= quot;the local and remote socket numbers" for referring to what is cal= led "port numbers" elsewhere in the document and in current parla= nce.

There's a lot of possible work to be done here, so before people embark on = such reviews, can you clarify which of these categories of input are useful= , and would be incorporated?

Best
Tommy

> On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs-es= slingen.de> wrote:
>
> Hi all,
>
> As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis= in order to complete this important TCPM milestone. The draft can be found= at:
>
> h= ttps://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13
>
> If you care about TCP (after all you have decided to subscribe the TCP= M list for some reason, no?), please try to find some cycles and please hav= e a look at this document.
>
> Thanks
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.iet= f.org/mailman/listinfo/tcpm

 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3CD44Brznt8114rzntrzd_-- From nobody Mon Jul 29 02:35: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 5AB411200F8 for ; Mon, 29 Jul 2019 02:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3gr7ZJbkr0Dx for ; Mon, 29 Jul 2019 02:35:33 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21717120018 for ; Mon, 29 Jul 2019 02:35:33 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 45xvgR28W2z35XS; Mon, 29 Jul 2019 11:35:31 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 45xvgR148yzCqkj; Mon, 29 Jul 2019 11:35:31 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 29 Jul 2019 11:35:30 +0200 From: To: "Scharf, Michael" , "tcpm@ietf.org" Thread-Topic: Please review 793bis! Thread-Index: AdVDxBaWqg1nKqsFQCmaSvOixpeJnwCKuSXw Date: Mon, 29 Jul 2019 09:35:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330312EA496@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@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.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jul 2019 09:35:35 -0000 Hi all,=20 Please find below some very minor comments to enhance the readability of th= e document: * Consider moving Section 2.1 to be listed under Section 3. * Rsrvd - Reserved: s/Reserved/Unassigned. This is to be aligned with http= s://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a special m= eaning: "Reserved: Not assigned and not available for assignment.") * Add a pointer to the "TCP Header Flags" registry: https://www.iana.org/as= signments/tcp-header-flags/tcp-header-flags.xhtml =20 * Add an IANA action to update the above registry to include all TCP flags,= not only those in 3168. Also, the description text in that page should be = reworked, IMHO. Unassigned bits should also be indicated as such in that pa= ge. I would like to have those referenced in that page rather than having docum= ents requiring access to these bits to duplicate the effort: see for exampl= e RFC8519 (look for "reserved" and "flags" in Page 33). * Position titles right after figure #, e.g.,=20 OLD: TCP Header Format Note that one tick mark represents one bit position. Figure 1 NEW: Note that one tick mark represents one bit position. Figure 1: TCP Header Format * Introduce some notations used in the document (and a pointer to Appendix = B), e.g.,=20 The window size MUST be treated as an unsigned number, or else large window sizes will appear like negative windows and TCP will now work (MUST-1) . It is RECOMMENDED that implementations will ^^^^^^^^ reserve 32-bit fields for the send and receive window sizes in the connection record and do all window computations with 32 bits (REC- ^^^^ 1 ). Idem for SHLD-, etc.=20 * Section 3.1 OLD: The checksum also covers a pseudo header conceptually prefixed to the TCP header. The pseudo header is 96 bits for IPv4 and 320 bits for IPv6. For IPv4, this pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. NEW: The checksum also covers a pseudo header conceptually prefixed to the TCP header. The pseudo header is 96 bits for IPv4 and 320 bits for IPv6. For IPv4, this pseudo header contains the Source Address, the Destination Address, the Protocol (PTCL), and TCP length. ^^^^^^=20 * Section 3.1: Add missing figure legend, e.g.,=20 +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | PTCL | TCP Length | +--------+--------+--------+--------+ * Section 3.3: OLD:=20 The synchronization requires each side to send it's own initial NEW: The synchronization requires each side to send its own initial =20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael > Envoy=E9=A0: vendredi 26 juillet 2019 17:17 > =C0=A0: tcpm@ietf.org > Objet=A0: [tcpm] Please review 793bis! >=20 > Hi all, >=20 > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis in > order to complete this important TCPM milestone. The draft can be found > at: >=20 > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 >=20 > If you care about TCP (after all you have decided to subscribe the TCPM > list for some reason, no?), please try to find some cycles and please hav= e > a look at this document. >=20 > Thanks >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jul 29 11:53:52 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CCB12001E for ; Mon, 29 Jul 2019 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPi_PevE8miQ for ; Mon, 29 Jul 2019 11:53:48 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 25AB412001A for ; Mon, 29 Jul 2019 11:53:48 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id j5so118243140ioj.8 for ; Mon, 29 Jul 2019 11:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Eh641ODxZBC3hTwd840ISvbjTLuvaH/Go2SVh86C1TQ=; b=wDYaQA21GidmcoVRflbzzvAcH6xB+Sk+N4sPKDpeQyluLJSFeDFMOydoUi6x86xyAN GAylfTcMKgluyPcgMXUrZdyNPfF5QaFX6qnJjLh9LeqkSM0gldSZ+jcV5ThJOUGozVUG OfnuhIPCyI5cNA5vlHDWr8/X3sKHqtUeZwmAHqutWA7JOwC4GyIvrrj+dTA2TTPU4FiJ 7IIFK+GkNQlo0Fm+8Ja9urIvU8mnLm18FSHFXeCVvXHnbKUw+IBt6ZZe160e93QR7TeO SKq5tljJgKsEItUPbO+v/NS/5fHd13YBSMQCwxq3nEq/G9IG3MNxnZco+lJ0XpAzBhgE D9gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Eh641ODxZBC3hTwd840ISvbjTLuvaH/Go2SVh86C1TQ=; b=CbMVSif2im3A+Fh9+awq6l0SQTwZu4jvvW9Gbvb1urD3IEmyNHO8culWp/2m3Q6g9O F/076drU2CecTVmowvrrEnKzxS0x2w5V9xNDN5hIk4KhOraIi3SvCV+WSxVZfsQtyTqo N2kvgCmS9TFRwtDttB5N+pBZiZBnrFTbyVNvQXmhE39HyRMjEt+Fs6s2vRyuOc5IHiZw kWdTnLZBRG7mdUXG8fjynGGe46hjBknOoIeStqeyKWwqbmKwowVtn1DDaYundrsBBueG pJsA7MziMsE+eacm0C0UDY+xdjcmhwt1fbBS6FIfNLixlbz/a/sXOl30F8PyNfUEs2Go qvCg== X-Gm-Message-State: APjAAAVxcmIXxGehQdaxlWsee4gJQ//P8qi6obzWr9otVvnsHL69uVO+ boe7oNg+j+lxRlD58HA5A05w/z0/ X-Google-Smtp-Source: APXvYqz/3OP/SunfMI5UNV2b9bxn0wngyXC+YyRYPzObvDPeveBqiLXtZo2669XLXKJIlieIC4r+mQ== X-Received: by 2002:a05:6602:2248:: with SMTP id o8mr37526183ioo.90.1564426427175; Mon, 29 Jul 2019 11:53:47 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id p63sm62262651iof.45.2019.07.29.11.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 11:53:46 -0700 (PDT) To: Tommy Pauly , "Scharf, Michael" , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> From: Wesley Eddy Message-ID: <3c742459-a280-17b3-c5b3-a3be3b9cb7c5@mti-systems.com> Date: Mon, 29 Jul 2019 14:53:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jul 2019 18:53:51 -0000 Thanks for looking at this, and trying to figure out how to make it feel less dated. I fully agree with you that people doing new implementations are one of the important targets for doing this work.  When we initially adopted it, we mentioned IoT and userspace code as being likely to "get it wrong" if people needed to slog through 793 + 1122 + errata (if they even found them) + all the other relevant RFCs coming later that make little tweaks here and there. At high level, I think purely editorial changes are "ok", but we need to be vigilant that they're actually purely editorial!  (actually, one of your suggestions below is not quite technically correct, so it is a good example of how this is harder than it seems and innocent mistakes are easy to creep in ... I have tried to avoid it as much as possible for exactly this reason) More specific thoughts on your examples below: On 7/27/2019 9:43 PM, Tommy Pauly wrote: > Some initial examples of changes that came to mind: > > - Structure; there is both a Terminology section (3.2) relatively early on, and a glossary (3.11) near the end. It seems more typical nowadays to have a terminology section up front, and just refer inline to supporting documents (like IP, for example). These are a bit different, and the section 3.2 labelled "terminology" really is more of a quick overview of a few of the variables that reoccur frequently, along with the state machine states.  It could be split into subsections like "Key Connection State Variables" and "State Machine Overview", if that would be more clear (and that would be purely editorial).  The glossary is more like an actual terminology section ... whether it goes up front or not is not something I have a strong opinion on. Personally, I have never liked the style in some more recent RFCs where terms are defined before a reader has much clue what they're relevant to, so have slight preference to leave it alone at the end. > - Many of the RFCs referenced are the older or obsoleted versions Those cases should probably be fixed, unless there is a reason for them.  If you indicate them, I'll happily make updates. > - Consistency and freshness; some of the terminology feels dated, such as "the local and remote socket numbers" for referring to what is called "port numbers" elsewhere in the document and in current parlance. That's a case of not rewriting text from 793/1122.  Do you think it would confuse anyone? To correct you though, the socket numbers are not just the port numbers, they also include the IP addresses.  That might be something good to put in the glossary?  It's explained in RFC 793 at top of page 5 (but this was a section of 793 that we originally decided to leave out, because it was very basic content that people working in the Internet protocols today learn from textbooks - that they didn't have in 1981, so was in the RFC, and it would be harder to update accurately with regard to all the things that have changed in IP, link layers, other transports, etc, in the meantime). From nobody Mon Jul 29 11:59:59 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114FA120019 for ; Mon, 29 Jul 2019 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNTTHf9lWXN7 for ; Mon, 29 Jul 2019 11:59:53 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 2CA4012001E for ; Mon, 29 Jul 2019 11:59:53 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id f4so122454686ioh.6 for ; Mon, 29 Jul 2019 11:59:53 -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-language; bh=Ye45tICwVItkN5JesGGWILJxdBvfuW3ex1FRHYrkIpw=; b=fYEY49eYCH9bpUnoZhyTlLzMadT+LExrqecVkHj3dQicwH2/eBjmn6ucNDBNQnkoFQ zE58SAGQuJQ3G/qMgWJR2K53cAlhRXADv4CfavqRtvL8bFBEJMINWUHSn5vGa4zq2POo BBGAFvHmZ1JSIW6QYj5YsqCEdkk1iL/EdjGoMZwZwT/H+30f0fU7cx7h5NEMDQAimslB iz1GQfcn8NZ5E2GF8osUVyb+eCCB6uH/9VO7P1822nAu9ph857ldnuVh4Tu9TY2CozWM XtZ89fzpHMTpu+wQUzfq8ddiKk9DMyCyWXHEVfk8tPNA+oSMUqIt5aGg5up7+KSkSTSm pwbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Ye45tICwVItkN5JesGGWILJxdBvfuW3ex1FRHYrkIpw=; b=iYOFETSBB1y3rwTBQP9OpxwfQjYkkyn14pWXP1f5pINmnqo7bfv9YYi0IhutOt0fxG l24bO4WzimsSEwZJDHJ5OzvAOf1tDmVZePRRyxv3YNnFhDbQ1Cn7X6e/dcRwjfLtdGnn p+rdPkbZliSQTMjwcLb8XcyBHUKuSFGI1t5IsUJsF5Civr6V6v1GvC9bC5MsFKCP0TXr sbw9LaMTpe5pfgam21pWxBT9I5SRCDzoOcpTThT2mij18wZnAlAYKIe01pcUCYFvSnYs 9LNOSJEDm3aifUfxCaU9Vfkx9nExFH7RL29lt4XpelFyPwg4W+GvMqKb8Ptv6w11aVlo j1Xg== X-Gm-Message-State: APjAAAWXB1nocRfpbwkXGCK6A2+GP0uHC++dNtnY9I69BigibBJ+D4KM wZSlXKpHPrbUlQimyQeRge6hn2wV X-Google-Smtp-Source: APXvYqy9cBB7RP3IMRMuCKszJVJZjNgVtQbl06c/8/OtKsJcvulkj3h30OOr0JNnlJ65zMP2wxAtFg== X-Received: by 2002:a5d:9a04:: with SMTP id s4mr106077984iol.19.1564426792197; Mon, 29 Jul 2019 11:59:52 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id z17sm84039131iol.73.2019.07.29.11.59.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 11:59:50 -0700 (PDT) To: Tim Wicinski , Tommy Pauly Cc: "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> From: Wesley Eddy Message-ID: <7d37be26-70fc-5303-c5bf-3d379585648f@mti-systems.com> Date: Mon, 29 Jul 2019 14:59:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5203128012013CA862665E55" Content-Language: en-US Archived-At: Subject: Re: [tcpm] Please review 793bis! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 29 Jul 2019 18:59:56 -0000 This is a multi-part message in MIME format. --------------5203128012013CA862665E55 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tim, I think I agree with the spirit of what you're saying, but am unsure what you suggest changing. The abstract and introduction are pretty verbose about the relation to 793 (why it's being obsoleted) and the history (in what ways it's now obsolete), and there are pointers to the TCP roadmap in sections 1 and 2. Do we need to say things differently somehow?  Any suggestions are welcome. On 7/27/2019 10:06 PM, Tim Wicinski wrote: > Tommy > > For Implementation advice, I would refer people to the TCP Roadmap > document (rfc7414) which feels to me to be a better location. > rfc7414 (or what may be the best location) should be spelled out more > clearly to readers. > > I noticed on reading through the document structure, there are > references to RFC793, yet the document is being Obsoleted. > If we're obsoleting an entire document, is it wise to refer back to > it?  Does that confuse a casual reader? If there are references to the > 793, such as in Section 2, I think it should be included. > Tim > > > > On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly > > wrote: > > Hi Michael, > > Thanks for the note about this (indeed important!) document. I > unfortunately had a conflict for tcpm, so missed the recent > meeting, but I do have some questions about what the group wants > to see in reviews of this document. > > As expected, much of the text remains unchanged from RFC793. While > I understand and agree that it is a non-goal to change any > behavior, reading the document does still feel like it is out of > place amongst current RFCs from a terminology and organizational > standpoint. If this is going to be published as a full STD > document, it would be great to have something that also makes the > reading clearer and easier for people new to TCP. Specifically, as > some people are now working on implementations of TCP for user > space stacks or minimal IoT devices, a clean reference would be a > fantastic asset. > > Some initial examples of changes that came to mind: > > - Structure; there is both a Terminology section (3.2) relatively > early on, and a glossary (3.11) near the end. It seems more > typical nowadays to have a terminology section up front, and just > refer inline to supporting documents (like IP, for example). > - Many of the RFCs referenced are the older or obsoleted versions > - Consistency and freshness; some of the terminology feels dated, > such as "the local and remote socket numbers" for referring to > what is called "port numbers" elsewhere in the document and in > current parlance. > > There's a lot of possible work to be done here, so before people > embark on such reviews, can you clarify which of these categories > of input are useful, and would be incorporated? > > Best > Tommy > > > On Jul 26, 2019, at 11:17 AM, Scharf, Michael > > wrote: > > > > Hi all, > > > > As discussed at IETF 105, we need reviews of > draft-ietf-tcpm-rfc793bis in order to complete this important TCPM > milestone. The draft can be found at: > > > > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 > > > > If you care about TCP (after all you have decided to subscribe > the TCPM list for some reason, no?), please try to find some > cycles and please have a look at this document. > > > > Thanks > > > > Michael > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------5203128012013CA862665E55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Tim, I think I agree with the spirit of what you're saying, but am unsure what you suggest changing.

The abstract and introduction are pretty verbose about the relation to 793 (why it's being obsoleted) and the history (in what ways it's now obsolete), and there are pointers to the TCP roadmap in sections 1 and 2.

Do we need to say things differently somehow?  Any suggestions are welcome.


On 7/27/2019 10:06 PM, Tim Wicinski wrote:
Tommy

For Implementation advice, I would refer people to the TCP Roadmap document (rfc7414) which feels to me to be a better location. 
rfc7414 (or what may be the best location) should be spelled out more clearly to readers.

I noticed on reading through the document structure, there are references to RFC793, yet the document is being Obsoleted. 
If we're obsoleting an entire document, is it wise to refer back to it?  Does that confuse a casual reader?   If there are references to the 
793, such as in Section 2, I think it should be included. 

                
Tim

                

              

              


              

              


              

            

          

        

      

      

      

        
On Sat, Jul 27, 2019 at 9:44
          PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
          wrote:

        

        
Hi
          Michael,

          

          Thanks for the note about this (indeed important!) document. I
          unfortunately had a conflict for tcpm, so missed the recent
          meeting, but I do have some questions about what the group
          wants to see in reviews of this document.

          

          As expected, much of the text remains unchanged from RFC793.
          While I understand and agree that it is a non-goal to change
          any behavior, reading the document does still feel like it is
          out of place amongst current RFCs from a terminology and
          organizational standpoint. If this is going to be published as
          a full STD document, it would be great to have something that
          also makes the reading clearer and easier for people new to
          TCP. Specifically, as some people are now working on
          implementations of TCP for user space stacks or minimal IoT
          devices, a clean reference would be a fantastic asset.

          

          Some initial examples of changes that came to mind:

          

          - Structure; there is both a Terminology section (3.2)
          relatively early on, and a glossary (3.11) near the end. It
          seems more typical nowadays to have a terminology section up
          front, and just refer inline to supporting documents (like IP,
          for example).

          - Many of the RFCs referenced are the older or obsoleted
          versions

          - Consistency and freshness; some of the terminology feels
          dated, such as "the local and remote socket numbers" for
          referring to what is called "port numbers" elsewhere in the
          document and in current parlance.

          

          There's a lot of possible work to be done here, so before
          people embark on such reviews, can you clarify which of these
          categories of input are useful, and would be incorporated?

          

          Best

          Tommy

          

          > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs-esslingen..de>
          wrote:

          > 

          > Hi all,

          > 

          > As discussed at IETF 105, we need reviews of
          draft-ietf-tcpm-rfc793bis in order to complete this important
          TCPM milestone. The draft can be found at:

          > 

          > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13

          > 

          > If you care about TCP (after all you have decided to
          subscribe the TCPM list for some reason, no?), please try to
          find some cycles and please have a look at this document.

          > 

          > Thanks

          > 

          > Michael

          > 

          > _______________________________________________

          > tcpm mailing list

          > tcpm@ietf.org

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

          

          _______________________________________________

          tcpm mailing list

          tcpm@ietf.org

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

        

      

      

      

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


    

  


--------------5203128012013CA862665E55--


From nobody Mon Jul 29 12:06: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 9FD2E120019 for ; Mon, 29 Jul 2019 12:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxv7F97l2ywl for ; Mon, 29 Jul 2019 12:06:46 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1944E12001A for ; Mon, 29 Jul 2019 12:06:46 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6TJ6eF1062720; Mon, 29 Jul 2019 12:06:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=8DzQX8F13yPtXrqNJZtoZrp/vSv8mnfd5zH0XiU3ETM=; b=tmlBjdp0WjBqXk9t9okXgJG5TUslxpjxZg9EOx/WXriSOo6ASWYnYJLx0zzU8x3Iek1I lToGZSiTU+3hbB4lPBHjYD2Q+t0AfBcveh4qjmbUiFNw/JQ42wfLKBV4VURVHmy75AJY Fq5K7tgQ0RI75CXRT79bKcBeeV90GvYbGfqwOICtsd1WLW/1iOInTK0VFQ5WZ5Uatg1l i0bVFU9SxlWPkfRaoyC6XG1SDz06L0pubwNdweZ2n3C1yfE5QxjXuDLp+Yiebs/zDZlM 34l1DKP7lvf3ErzQN+0fz2hjtzsP20dRhW1VOu6tcsMs9jsSj3EnOgc2wg+1p7yskwh0 Gw== 
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2u0n91vmj2-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jul 2019 12:06:41 -0700
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPS id <0PVF0087N3R3LW00@ma1-mtap-s03.corp.apple.com>; Mon, 29 Jul 2019 12:06:39 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) id <0PVF007003QVJI00@nwk-mmpp-sz12.apple.com>; Mon, 29 Jul 2019 12:06:39 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: 920b67be76b6a75641fdfd4ea90c4da9
X-Va-E-CD: 69be58a359e0ce403bce9bb83fb8fd92
X-Va-R-CD: 619c007249ad5d72124eaeedc31aa69f
X-Va-CD: 0
X-Va-ID: c9ff08f1-7e6b-4cc0-84a8-0ddefc877279
X-V-A: 
X-V-T-CD: 920b67be76b6a75641fdfd4ea90c4da9
X-V-E-CD: 69be58a359e0ce403bce9bb83fb8fd92
X-V-R-CD: 619c007249ad5d72124eaeedc31aa69f
X-V-CD: 0
X-V-ID: e389869b-bfb5-4a80-a923-7cce0e800c42
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-29_09:,, signatures=0
Received: from [17.234.85.221] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May  7 2019)) with ESMTPSA id <0PVF00B303R21A90@nwk-mmpp-sz12.apple.com>; Mon, 29 Jul 2019 12:06:39 -0700 (PDT)
Sender: tpauly@apple.com
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
From: Tommy Pauly 
In-reply-to: <3c742459-a280-17b3-c5b3-a3be3b9cb7c5@mti-systems.com>
Date: Mon, 29 Jul 2019 12:06:32 -0700
Cc: "Scharf, Michael" , "tcpm@ietf.org" 
Content-transfer-encoding: quoted-printable
Message-id: 
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> <3c742459-a280-17b3-c5b3-a3be3b9cb7c5@mti-systems.com>
To: Wesley Eddy 
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-29_09:, , signatures=0
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Jul 2019 19:06:49 -0000

> On Jul 29, 2019, at 11:53 AM, Wesley Eddy  wrote:
>=20
> Thanks for looking at this, and trying to figure out how to make it =
feel less dated.
>=20
> I fully agree with you that people doing new implementations are one =
of the important targets for doing this work.  When we initially adopted =
it, we mentioned IoT and userspace code as being likely to "get it =
wrong" if people needed to slog through 793 + 1122 + errata (if they =
even found them) + all the other relevant RFCs coming later that make =
little tweaks here and there.
>=20
> At high level, I think purely editorial changes are "ok", but we need =
to be vigilant that they're actually purely editorial!  (actually, one =
of your suggestions below is not quite technically correct, so it is a =
good example of how this is harder than it seems and innocent mistakes =
are easy to creep in ... I have tried to avoid it as much as possible =
for exactly this reason)

Yes, I absolutely agree that it's critical to make sure that the =
editorial changes don't change the meaning. These are good opportunities =
to tease apart the terminology for things that may be confusing to a =
current audience, as is the example you cite.

>=20
> More specific thoughts on your examples below:
>=20
>=20
> On 7/27/2019 9:43 PM, Tommy Pauly wrote:
>> Some initial examples of changes that came to mind:
>>=20
>> - Structure; there is both a Terminology section (3.2) relatively =
early on, and a glossary (3.11) near the end. It seems more typical =
nowadays to have a terminology section up front, and just refer inline =
to supporting documents (like IP, for example).
>=20
> These are a bit different, and the section 3.2 labelled "terminology" =
really is more of a quick overview of a few of the variables that =
reoccur frequently, along with the state machine states.  It could be =
split into subsections like "Key Connection State Variables" and "State =
Machine Overview", if that would be more clear (and that would be purely =
editorial).  The glossary is more like an actual terminology section ... =
whether it goes up front or not is not something I have a strong opinion =
on. Personally, I have never liked the style in some more recent RFCs =
where terms are defined before a reader has much clue what they're =
relevant to, so have slight preference to leave it alone at the end.

+1 to splitting up the terminology section into subsections with titles.

I do agree that just placing the full glossary at the front would be a =
bit much. Usually, the terminology up front is most useful for defining =
the most common terms that would otherwise lead to misinterpretation. =
For example, terms that the glossary defines that are otherwise generic, =
like "connection", may be good to just define in a rigorous manner up =
front as what "connection" means in this document.

Some of the other glossary entries are already in the terminology =
section, like RCV.NXT... it's possible they're not needed twice.

A couple of the glossary entries likely should just be RFC =
references=E2=80=94such as for FTP and IP.

>=20
>=20
>> - Many of the RFCs referenced are the older or obsoleted versions
>=20
> Those cases should probably be fixed, unless there is a reason for =
them.  If you indicate them, I'll happily make updates.

I can run through these in a review pass, yes.
>=20
>=20
>> - Consistency and freshness; some of the terminology feels dated, =
such as "the local and remote socket numbers" for referring to what is =
called "port numbers" elsewhere in the document and in current parlance.
>=20
> That's a case of not rewriting text from 793/1122.  Do you think it =
would confuse anyone?

Yes, I think it is a bit confusing, since it is not a clear definition =
in the current version of the document, and doesn't reference anything =
else. It's fairly particular to the environment in which TCP was =
implemented when designed.
>=20
> To correct you though, the socket numbers are not just the port =
numbers, they also include the IP addresses.  That might be something =
good to put in the glossary?  It's explained in RFC 793 at top of page 5 =
(but this was a section of 793 that we originally decided to leave out, =
because it was very basic content that people working in the Internet =
protocols today learn from textbooks - that they didn't have in 1981, so =
was in the RFC, and it would be harder to update accurately with regard =
to all the things that have changed in IP, link layers, other =
transports, etc, in the meantime).

That's a great clarification to make. I don't see exactly how the =
previous explanation in RFC 793 on page 5 introduces the concept of a =
"socket number" particularly. I get that a local socket structure =
contains both the local/remote ports and addresses, and there is also a =
local fd number allocated to the socket, but there generally isn't just =
one "remote socket number" that represents both a port and address in my =
experience.

Elaborating the text to say that the TCB contains the local address, =
local port, remote address, and remote port, would be the most clear, I =
would argue.

>=20
>=20


From nobody Mon Jul 29 12:29:11 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3976512002F for ; Mon, 29 Jul 2019 12:29:09 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MMgpTmHttbei for ; Mon, 29 Jul 2019 12:29:07 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13FC12002E for ; Mon, 29 Jul 2019 12:29:06 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id l12so46148337oil.1 for ; Mon, 29 Jul 2019 12:29:06 -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=mZj9Ak1pGD8mqfVu2Y3/PpX+ifzUmqdK+6WsDo1Gq+Y=; b=reLYroX1/rNhyLZKml36Gt6fq6pU19cNIAok9tByOhzA+914ItDB1oeaTqutyyqKVz FRuS2boBhM+65rFuMh1/tQsV6/Bj4pNX4SxsI3RcKehQ7t3XXEtw+W/cApWI5d5Dk3qn cmXj+L3ct6woh9hDbDL84HaD/mnO96B0LXpaM5TM5esLGoHDqDolOvGdxsGqW/ATrXl8 /p9Z2A95Ma3mXKebxSRs+0IGbeLI7/pD6KNcqWmwEgkHYclCgVruGNC8U3NdtWptYpvf avAkjpwSP543X4GD43Z4p2lKl+XPa48dQUTfXWEjAKke3M3h5Fc6Lrt0kI+T1hIsHQzW 8+Xw==
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=mZj9Ak1pGD8mqfVu2Y3/PpX+ifzUmqdK+6WsDo1Gq+Y=; b=P9M1TI00hTY6QW0yDes1r9Hn/aOmoM8tlcfidmSjrmxf4loc9F1FxbJ2+qXFVM4lhP eW8AetSHrgDhSJpzozKldKQkNqdvutOeY/pfsuNPvrxVzCibbV0jGIwhPsYNLPG2OitD 3bFIdmzpIs+SGTQELLm17Zk5rb/i27pgUID+JCZzaT16N8ylzerCTFMtWUDnQMvcUe15 g3y8dQVIPx5Y5b02L+9jFVJRWeMHYlyH+G1c9+fxmi98cENdAYU0dCt1ILFiAsoLCJks vtZwW5YjO22jpNpHx4DcVGFq8UnBvL1U5eJf/1CskE71TwgwXLpg8a00UAWzHgj5Kc+z 0FCQ==
X-Gm-Message-State: APjAAAWCpGLNEqqVl1aAKY6S1YoFakxU/qH3a6S9WaAAvfa9Yw9KbhzS 7io6ED5Sn6F2IMDx6bDIoJWJb8F6DugxJ9AHrYw=
X-Google-Smtp-Source: APXvYqw/x+Fzy7E0TKtx42qzWZx+Oda+epwaeTvQa/PbVIwROcO2YZiT182B8/bC0YFDDHydLDTsBzGm35mcKysjv/s=
X-Received: by 2002:aca:b406:: with SMTP id d6mr54349714oif.173.1564428546204;  Mon, 29 Jul 2019 12:29:06 -0700 (PDT)
MIME-Version: 1.0
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com>  <7d37be26-70fc-5303-c5bf-3d379585648f@mti-systems.com>
In-Reply-To: <7d37be26-70fc-5303-c5bf-3d379585648f@mti-systems.com>
From: Tim Wicinski 
Date: Mon, 29 Jul 2019 15:28:55 -0400
Message-ID: 
To: Wesley Eddy 
Cc: Tommy Pauly , "tcpm@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c5e8b2058ed6e7fd"
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Jul 2019 19:29:09 -0000

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

Wes

I've been staring at this one sentence

   It does not replicate or attempt to update the introduction
   and philosophy content in RFC 793
 (sections 1

and 2 
of *that*
   document).


The 793 link is the link to 793, but sections 1 & 2 are linked to this
document.
Is the intention to link to the older document, or to the -bis document?
That would help clear up "that document" or "this document" to me.

Back in Section 1:


    RFC 793  and other updates also contain
   informative and descriptive text for human readers to understand
   aspects of the protocol design and operation.  This document does not
   attempt to alter or update this informative text, and is focused only
   on updating the normative protocol specification.



in DNSOP we struggled with this same question recently with 2845-bis
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
Initially, the idea was to make as few a changes as possible to the
document,
just make minor fixes.  But it became clear part of the reason there was an
issue with implementation was poor wording in the original document.
Sadly, I have no simple answers.

On Mon, Jul 29, 2019 at 2:59 PM Wesley Eddy  wrote:

> Hi Tim, I think I agree with the spirit of what you're saying, but am
> unsure what you suggest changing.
>
> The abstract and introduction are pretty verbose about the relation to 793
> (why it's being obsoleted) and the history (in what ways it's now
> obsolete), and there are pointers to the TCP roadmap in sections 1 and 2.
>
> Do we need to say things differently somehow?  Any suggestions are welcome.
>
>
> On 7/27/2019 10:06 PM, Tim Wicinski wrote:
>
> Tommy
>
> For Implementation advice, I would refer people to the TCP Roadmap
> document (rfc7414) which feels to me to be a better location.
> rfc7414 (or what may be the best location) should be spelled out more
> clearly to readers.
>
> I noticed on reading through the document structure, there are references
> to RFC793, yet the document is being Obsoleted.
> If we're obsoleting an entire document, is it wise to refer back to it?
> Does that confuse a casual reader?   If there are references to the
>
> 793, such as in Section 2, I think it should be included.
>
> Tim
>
>
>
>
> On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly  40apple.com@dmarc.ietf.org> wrote:
>
>> Hi Michael,
>>
>> Thanks for the note about this (indeed important!) document. I
>> unfortunately had a conflict for tcpm, so missed the recent meeting, but I
>> do have some questions about what the group wants to see in reviews of this
>> document.
>>
>> As expected, much of the text remains unchanged from RFC793. While I
>> understand and agree that it is a non-goal to change any behavior, reading
>> the document does still feel like it is out of place amongst current RFCs
>> from a terminology and organizational standpoint. If this is going to be
>> published as a full STD document, it would be great to have something that
>> also makes the reading clearer and easier for people new to TCP.
>> Specifically, as some people are now working on implementations of TCP for
>> user space stacks or minimal IoT devices, a clean reference would be a
>> fantastic asset.
>>
>> Some initial examples of changes that came to mind:
>>
>> - Structure; there is both a Terminology section (3.2) relatively early
>> on, and a glossary (3.11) near the end. It seems more typical nowadays to
>> have a terminology section up front, and just refer inline to supporting
>> documents (like IP, for example).
>> - Many of the RFCs referenced are the older or obsoleted versions
>> - Consistency and freshness; some of the terminology feels dated, such as
>> "the local and remote socket numbers" for referring to what is called "port
>> numbers" elsewhere in the document and in current parlance.
>>
>> There's a lot of possible work to be done here, so before people embark
>> on such reviews, can you clarify which of these categories of input are
>> useful, and would be incorporated?
>>
>> Best
>> Tommy
>>
>> > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <
>> Michael.Scharf@hs-esslingen..de > wrote:
>> >
>> > Hi all,
>> >
>> > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis
>> in order to complete this important TCPM milestone. The draft can be found
>> at:
>> >
>> > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13
>> >
>> > If you care about TCP (after all you have decided to subscribe the TCPM
>> list for some reason, no?), please try to find some cycles and please have
>> a look at this document.
>> >
>> > Thanks
>> >
>> > Michael
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
> _______________________________________________
> tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm
>
>

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


Wes
I've been staring at this one sentence=C2=A0
=

   It does not replicate or attempt to update the introduction
   and philosophy content in RFC 793 (sections 1 and 2 of that
   document). 

The 793 link is the link to 793, but sections 1 & 2 a=
re linked to this document. 
Is the intention to link to the older docum=
ent, or to the -bis document? 
That would help clear up "that docum=
ent" or "this document" to me.

Back in Section 1: 
  =
  RFC 793 and other upda=
tes also contain
   informative and descriptive text for human readers to understand
   aspects of the protocol design and operation.  This document does not
   attempt to alter or update this informative text, and is focused only
   on updating the normative protocol specification.


in DNSOP=
 we struggled with this same question recently with 2845-bis 
https://dat=
atracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
Initially, the id=
ea was to make as few a changes as possible to the document, 
just make =
minor fixes.=C2=A0 But it became clear part of the reason there was an 
=
issue with implementation was poor wording in the original document. 
=

Sadly, I have no simple answers.=C2=A0
On Mon, =
Jul 29, 2019 at 2:59 PM Wesley Eddy <wes@mti-systems.com> wrote:

 =20
   =20
 =20
  

    
Hi Tim, I think I agree with the spirit of what you're saying,
      but am unsure what you suggest changing.

    
The abstract and introduction are pretty verbose about the
      relation to 793 (why it's being obsoleted) and the history (in
      what ways it's now obsolete), and there are pointers to the TCP
      roadmap in sections 1 and 2.

    
Do we need to say things differently somehow?=C2=A0 Any suggestions
      are welcome.

    

    


    

    
On 7/27/2019=
 10:06 PM, Tim Wicinski
      wrote:

    

    

     =20
      

        

          

            
Tommy

            


              
For Implementation advice, I would refer people to
                the TCP Roadmap document (rfc7414) which feels to me to
                be a better location.=C2=A0

              
rfc7414 (or what may be the best location) should be
                spelled out more clearly to readers.

              

              


              

              
I noticed on reading through the document structure,
                there are references to RFC793, yet the document is
                being Obsoleted.=C2=A0

              
If we're obsoleting an entire document, is it wise t=
o
                refer back to it?=C2=A0 Does that confuse a casual reader? =
=C2=A0
                If there are references to the=C2=A0

              

                
793, such as in Section 2, I think it shoul=
d be included. 

                

                
Tim

                

              

              


              

              


              

            

          

        

      

      

      

        
On Sat, Jul 27, 2019 at 9:44
          PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
          wrote:

        

        
Hi
          Michael,

          

          Thanks for the note about this (indeed important!) document. I
          unfortunately had a conflict for tcpm, so missed the recent
          meeting, but I do have some questions about what the group
          wants to see in reviews of this document.

          

          As expected, much of the text remains unchanged from RFC793.
          While I understand and agree that it is a non-goal to change
          any behavior, reading the document does still feel like it is
          out of place amongst current RFCs from a terminology and
          organizational standpoint. If this is going to be published as
          a full STD document, it would be great to have something that
          also makes the reading clearer and easier for people new to
          TCP. Specifically, as some people are now working on
          implementations of TCP for user space stacks or minimal IoT
          devices, a clean reference would be a fantastic asset.

          

          Some initial examples of changes that came to mind:

          

          - Structure; there is both a Terminology section (3.2)
          relatively early on, and a glossary (3.11) near the end. It
          seems more typical nowadays to have a terminology section up
          front, and just refer inline to supporting documents (like IP,
          for example).

          - Many of the RFCs referenced are the older or obsoleted
          versions

          - Consistency and freshness; some of the terminology feels
          dated, such as "the local and remote socket numbers" fo=
r
          referring to what is called "port numbers" elsewhere in=
 the
          document and in current parlance.

          

          There's a lot of possible work to be done here, so before
          people embark on such reviews, can you clarify which of these
          categories of input are useful, and would be incorporated?

          

          Best

          Tommy

          

          > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs=
-esslingen..de>
          wrote:

          > 

          > Hi all,

          > 

          > As discussed at IETF 105, we need reviews of
          draft-ietf-tcpm-rfc793bis in order to complete this important
          TCPM milestone. The draft can be found at:

          > 

          > https://tools.ietf.org/html/d=
raft-ietf-tcpm-rfc793bis-13

          > 

          > If you care about TCP (after all you have decided to
          subscribe the TCPM list for some reason, no?), please try to
          find some cycles and please have a look at this document.

          > 

          > Thanks

          > 

          > Michael

          > 

          > _______________________________________________

          > tcpm mailing list

          > tcpm@ietf=
.org

          > https://www.ietf.org/mailman/listinfo/tcp=
m

          

          _______________________________________________

          tcpm mailing list

          tcpm@ietf.org<=
/a>

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

      

      

      
=


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


    

  





--000000000000c5e8b2058ed6e7fd--


From nobody Mon Jul 29 12:32: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 6D4D012002F for ; Mon, 29 Jul 2019 12:32:02 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdrs6VDoyNRo for ; Mon, 29 Jul 2019 12:31:59 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ACC120025 for ; Mon, 29 Jul 2019 12:31:59 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id j19so25284019otq.2 for ; Mon, 29 Jul 2019 12:31:59 -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=0vaZjmJa4cCgDXwEMfJkSx5v6gTKs+WaUI0RSYAOJuA=; b=bjIWH1uYRK6fK9glYirMelptg0ZArL309hUJdSWZVxTFqMoLbRduh8Jq6ANHRycVaR dXqCAmG5HGTbPkkJyALpOQBmnUKFYX6VqsXGq2aZxXB04VHRRI/Zv1Z+78Hri09NmuxV EcYGItho8NYYbg+V+lrbUvoa4kjlNcSDU1NY4ZcT5fP1N5fWy8UsU07VDEKSzVVa/Nvp DAJ8eXGHOLeQqBMNrwZ8mG5SkS0pKMUu6GxtIxn8Rp900ub902hlg2507N8CIyT+GgBC 2+DV934+7s7vyj6sjQ+DP9ZykJcz0VD6DDWE6w7/yBZ5WX1BCiO2IVT6BTe0Dl1xm+xu yKMg==
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=0vaZjmJa4cCgDXwEMfJkSx5v6gTKs+WaUI0RSYAOJuA=; b=KgCJfaBfZNZoU2kKJxap6zC2aFonmSYJqRsUAqNhswRNAAqVw9bl3xxhLB4THA34Ke gqUvBg/5PVIjwS53ylDRyc0VBvqWcz7O5+TXpmVtgRkJlVs1p+EJstRxjt+aufH0wv2b HqCGtZaOlppVhKOvGFVjFNgRgGepEcOFdta6XdK7+G46J9vtVgjsEBiJ4xWXJnSA6q/o Cy6kpzjxBY6Tu4BZ8v13yP//JM/GGbrA+bpxUqM74pYa7xfQDqKMyiB6uNdI0o0VzjWU ZoGbM/00FHple4pPaQvENZ9XW6AT6r8NEw+Yqwm6j5YFNuHFT724DzV9U02jha6V9ZEG s5YQ==
X-Gm-Message-State: APjAAAUe2/oGfSAPAQtbfj1lLBFljqD9posatYAsI3P8sQJeGV/18jAZ /ve2N1vbgErM4wSE/hWR3mWs8LOuhNDZJLa1XVBBmg==
X-Google-Smtp-Source: APXvYqxDynxntraKdgZa4FuW2HQQlVRtxspgu/4F5rLJBzLXjA9iq0/CG35fw+lQkVig2SzHKp7MXuH5p/hhep5Se+4=
X-Received: by 2002:a05:6830:1250:: with SMTP id s16mr13661272otp.158.1564428718818;  Mon, 29 Jul 2019 12:31:58 -0700 (PDT)
MIME-Version: 1.0
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com>  <7d37be26-70fc-5303-c5bf-3d379585648f@mti-systems.com> 
In-Reply-To: 
From: Tim Wicinski 
Date: Mon, 29 Jul 2019 15:31:48 -0400
Message-ID: 
To: Wesley Eddy 
Cc: Tommy Pauly , "tcpm@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000000fc8c4058ed6f2a2"
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Jul 2019 19:32:02 -0000

--0000000000000fc8c4058ed6f2a2
Content-Type: text/plain; charset="UTF-8"

And I don't want to bike shed all the non-normative language.
So I'm going to chew on this for awhile.

Tim


On Mon, Jul 29, 2019 at 3:28 PM Tim Wicinski  wrote:

> Wes
>
> I've been staring at this one sentence
>
>    It does not replicate or attempt to update the introduction
>    and philosophy content in RFC 793  (sections 1  and 2  of *that*
>    document).
>
>
> The 793 link is the link to 793, but sections 1 & 2 are linked to this
> document.
> Is the intention to link to the older document, or to the -bis document?
> That would help clear up "that document" or "this document" to me.
>
> Back in Section 1:
>
>
>     RFC 793  and other updates also contain
>    informative and descriptive text for human readers to understand
>    aspects of the protocol design and operation.  This document does not
>    attempt to alter or update this informative text, and is focused only
>    on updating the normative protocol specification.
>
>
>
> in DNSOP we struggled with this same question recently with 2845-bis
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
> Initially, the idea was to make as few a changes as possible to the
> document,
> just make minor fixes.  But it became clear part of the reason there was
> an
> issue with implementation was poor wording in the original document.
> Sadly, I have no simple answers.
>
> On Mon, Jul 29, 2019 at 2:59 PM Wesley Eddy  wrote:
>
>> Hi Tim, I think I agree with the spirit of what you're saying, but am
>> unsure what you suggest changing.
>>
>> The abstract and introduction are pretty verbose about the relation to
>> 793 (why it's being obsoleted) and the history (in what ways it's now
>> obsolete), and there are pointers to the TCP roadmap in sections 1 and 2.
>>
>> Do we need to say things differently somehow?  Any suggestions are
>> welcome.
>>
>>
>> On 7/27/2019 10:06 PM, Tim Wicinski wrote:
>>
>> Tommy
>>
>> For Implementation advice, I would refer people to the TCP Roadmap
>> document (rfc7414) which feels to me to be a better location.
>> rfc7414 (or what may be the best location) should be spelled out more
>> clearly to readers.
>>
>> I noticed on reading through the document structure, there are references
>> to RFC793, yet the document is being Obsoleted.
>> If we're obsoleting an entire document, is it wise to refer back to it?
>> Does that confuse a casual reader?   If there are references to the
>>
>> 793, such as in Section 2, I think it should be included.
>>
>> Tim
>>
>>
>>
>>
>> On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly > 40apple.com@dmarc.ietf.org> wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for the note about this (indeed important!) document. I
>>> unfortunately had a conflict for tcpm, so missed the recent meeting, but I
>>> do have some questions about what the group wants to see in reviews of this
>>> document.
>>>
>>> As expected, much of the text remains unchanged from RFC793. While I
>>> understand and agree that it is a non-goal to change any behavior, reading
>>> the document does still feel like it is out of place amongst current RFCs
>>> from a terminology and organizational standpoint. If this is going to be
>>> published as a full STD document, it would be great to have something that
>>> also makes the reading clearer and easier for people new to TCP.
>>> Specifically, as some people are now working on implementations of TCP for
>>> user space stacks or minimal IoT devices, a clean reference would be a
>>> fantastic asset.
>>>
>>> Some initial examples of changes that came to mind:
>>>
>>> - Structure; there is both a Terminology section (3.2) relatively early
>>> on, and a glossary (3.11) near the end. It seems more typical nowadays to
>>> have a terminology section up front, and just refer inline to supporting
>>> documents (like IP, for example).
>>> - Many of the RFCs referenced are the older or obsoleted versions
>>> - Consistency and freshness; some of the terminology feels dated, such
>>> as "the local and remote socket numbers" for referring to what is called
>>> "port numbers" elsewhere in the document and in current parlance.
>>>
>>> There's a lot of possible work to be done here, so before people embark
>>> on such reviews, can you clarify which of these categories of input are
>>> useful, and would be incorporated?
>>>
>>> Best
>>> Tommy
>>>
>>> > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <
>>> Michael.Scharf@hs-esslingen..de > wrote:
>>> >
>>> > Hi all,
>>> >
>>> > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis
>>> in order to complete this important TCPM milestone. The draft can be found
>>> at:
>>> >
>>> > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13
>>> >
>>> > If you care about TCP (after all you have decided to subscribe the
>>> TCPM list for some reason, no?), please try to find some cycles and please
>>> have a look at this document.
>>> >
>>> > Thanks
>>> >
>>> > Michael
>>> >
>>> > _______________________________________________
>>> > tcpm mailing list
>>> > tcpm@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>
>> _______________________________________________
>> tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm
>>
>>

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


And I don't want to bike shed all the non-normative la=
nguage. =C2=A0
So I'm going to chew on this for awhile.=C2=A0
=


Tim


On Mon, Jul 29, 2019 at 3:28 PM=
 Tim Wicinski <tjw.ietf@gmail.com<=
/a>> wrote:
=

Wes

I've been star=
ing at this one sentence=C2=A0

   =
It does not replicate or attempt to update the introduction
   and philosophy content in RFC 793 (sections 1 and 2 of that
   document). 

The 793 link is the link to 7=
93, but sections 1 & 2 are linked to this document. 
Is the intentio=
n to link to the older document, or to the -bis document? 
That would he=
lp clear up "that document" or "this document" to me.
Back in Section 1: 

    RFC 793 and other updates also contain
   informative and descriptive text for human readers to understand
   aspects of the protocol design and operation.  This document does not
   attempt to alter or update this informative text, and is focused only
   on updating the normative protocol specification.


in DNSOP we struggled with this same question recently =
with 2845-bis 
https://datatracker.ietf.org/doc/draft-i=
etf-dnsop-rfc2845bis/
Initially, the idea was to make as few a chang=
es as possible to the document, 
just make minor fixes.=C2=A0 But it bec=
ame clear part of the reason there was an 
issue with implementation was=
 poor wording in the original document. 
Sadly, I have no simple =
answers.=C2=A0

=

On Mon, Jul 29, 2019 at 2:59 PM Wesle=
y Eddy <wes@mti=
-systems.com> wrote:

 =20
   =20
 =20
  

    
Hi Tim, I think I agree with the spirit of what you're saying,
      but am unsure what you suggest changing.

    
The abstract and introduction are pretty verbose about the
      relation to 793 (why it's being obsoleted) and the history (in
      what ways it's now obsolete), and there are pointers to the TCP
      roadmap in sections 1 and 2.

    
Do we need to say things differently somehow?=C2=A0 Any suggestions
      are welcome.

    

    


    

    
On 7/27/2019 10:06 PM, Tim Wicinski
      wrote:

    

    

     =20
      

        

          

            
Tommy

            


              
For Implementation advice, I would refer people to
                the TCP Roadmap document (rfc7414) which feels to me to
                be a better location.=C2=A0

              
rfc7414 (or what may be the best location) should be
                spelled out more clearly to readers.

              

              


              

              
I noticed on reading through the document structure,
                there are references to RFC793, yet the document is
                being Obsoleted.=C2=A0

              
If we're obsoleting an entire document, is it wise t=
o
                refer back to it?=C2=A0 Does that confuse a casual reader? =
=C2=A0
                If there are references to the=C2=A0

              

                
793, such as in=
 Section 2, I think it should be included. 

                

                
Tim

                

              

              


              

              


              

            

          

        

      

      

      

        
On Sat, Jul 27, 2019 at 9:44
          PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
          wrote:

        

        
Hi
          Michael,

          

          Thanks for the note about this (indeed important!) document. I
          unfortunately had a conflict for tcpm, so missed the recent
          meeting, but I do have some questions about what the group
          wants to see in reviews of this document.

          

          As expected, much of the text remains unchanged from RFC793.
          While I understand and agree that it is a non-goal to change
          any behavior, reading the document does still feel like it is
          out of place amongst current RFCs from a terminology and
          organizational standpoint. If this is going to be published as
          a full STD document, it would be great to have something that
          also makes the reading clearer and easier for people new to
          TCP. Specifically, as some people are now working on
          implementations of TCP for user space stacks or minimal IoT
          devices, a clean reference would be a fantastic asset.

          

          Some initial examples of changes that came to mind:

          

          - Structure; there is both a Terminology section (3.2)
          relatively early on, and a glossary (3.11) near the end. It
          seems more typical nowadays to have a terminology section up
          front, and just refer inline to supporting documents (like IP,
          for example).

          - Many of the RFCs referenced are the older or obsoleted
          versions

          - Consistency and freshness; some of the terminology feels
          dated, such as "the local and remote socket numbers" fo=
r
          referring to what is called "port numbers" elsewhere in=
 the
          document and in current parlance.

          

          There's a lot of possible work to be done here, so before
          people embark on such reviews, can you clarify which of these
          categories of input are useful, and would be incorporated?

          

          Best

          Tommy

          

          > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs=
-esslingen..de>
          wrote:

          > 

          > Hi all,

          > 

          > As discussed at IETF 105, we need reviews of
          draft-ietf-tcpm-rfc793bis in order to complete this important
          TCPM milestone. The draft can be found at:

          > 

          > https://tools.ietf.org/html/d=
raft-ietf-tcpm-rfc793bis-13

          > 

          > If you care about TCP (after all you have decided to
          subscribe the TCPM list for some reason, no?), please try to
          find some cycles and please have a look at this document.

          > 

          > Thanks

          > 

          > Michael

          > 

          > _______________________________________________

          > tcpm mailing list

          > tcpm@ietf=
.org

          > https://www.ietf.org/mailman/listinfo/tcp=
m

          

          _______________________________________________

          tcpm mailing list

          tcpm@ietf.org<=
/a>

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

      

      

      

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


    

  







--0000000000000fc8c4058ed6f2a2--


From nobody Mon Jul 29 12:33: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 A5C3712002E for ; Mon, 29 Jul 2019 12:33: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 G9Ou8O-RijYW for ; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 A75C5120025 for ; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id h6so36108047iom.7 for ; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=g/pxeUs/6XHNYqvrpdRxZML7b+91Wc7zW7IcNFeOGWg=; b=gfo5/nJxB7L4msuZ23FoZZfXH3w2d/26vQVqdLTND0su8jIN7HHYRKGv5217GgfpWF jSOtoIdq2KzXvmV7GbGEz8MwPqdM6gVXU1n5tblGqxYdBHRT5GXuXUCjcIqKrc4GqN+y B2R+dqqm/M+QzTYx7p0INYjMpGsK/N5mrRdUN2grJhnC5fwxFAMefHXGzyrqqjK57kar a2ngjMksgvmB60DoA8VFt7JPTb11iAHCRjTxt839P3scvdDAlM0Tj0tPnTssiBN2fBiK 7/mC8TFe/b89Pi6y92srpyaWW0HkqXB5AKiap47iTbvXtExplFwPFHiE2NTjudBJQUSx TdEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=g/pxeUs/6XHNYqvrpdRxZML7b+91Wc7zW7IcNFeOGWg=; b=fsERnfYy5SDPQCJ0p/Coa8QNf1H5tFr6fJ5lmfIOhoejIGxE0iQnaMpTwvCC4ZyC2I tjroCCRqpz2f8xk/lfCjr2k4oBgfeXIFGN/WTe8VfAfJjtSE1DxkN3p/6XisJCC+DZe9 D0SKNLPddhRS2+bl6vQIQml/I43U0N4V+in3IpRuyOhAWFoGxHiOQN1EKZhNCCDjtH6Z uKu3AdZfe7+WzskHS4x5u1A0WWnntHv8JSs0RR8ukoLyWvfuUSUflXt2lexbY1lQSk6s taBjXmTV5WcFNcuNOV9AGb6krxoa52n/UOb18BE1K/K9oR7OelivJCW1pSyw4zFWATW0 q90w==
X-Gm-Message-State: APjAAAWSEqGj7PKoD4UxAR8ocKWmuIG7ep65NYPtycpBxVhRZOkm2dGA 21gMac80xrOw022DBiYHeMk=
X-Google-Smtp-Source: APXvYqynwGPNZnClDJbNhOBpLoRlDqDWvG9OAFQa1/oMv0BPdiUha3wwGadDF7KPnxtcghUC8cBnHg==
X-Received: by 2002:a6b:8bcb:: with SMTP id n194mr3002921iod.194.1564428819008;  Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id b3sm53318415iot.23.2019.07.29.12.33.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 12:33:38 -0700 (PDT)
To: tcpm@ietf.org, mohamed.boucadair@orange.com
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312EA496@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Wesley Eddy 
Message-ID: 
Date: Mon, 29 Jul 2019 15:33:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312EA496@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Jul 2019 19:33:42 -0000

Many thanks for your comments; my thoughts are below:

On 7/29/2019 5:35 AM, mohamed.boucadair@orange.com wrote:
> Hi all,
>
> Please find below some very minor comments to enhance the readability of the document:
>
> * Consider moving Section 2.1 to be listed under Section 3.

Either way is fine with me; does anyone have strong preference? The 
section numbering is closer to the original 793 numbering currently, and 
this would probably bump that, but that is a very trivial concern.


> * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned with https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a special meaning: "Reserved:  Not assigned and not available for assignment.")

Thanks; I'll have to look at this in all cases and make sure we "do the 
right thing".  I hadn't really been aware of 8126.


> * Add a pointer to the "TCP Header Flags" registry: https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
>
> * Add an IANA action to update the above registry to include all TCP flags, not only those in 3168. Also, the description text in that page should be reworked, IMHO. Unassigned bits should also be indicated as such in that page.
>
> I would like to have those referenced in that page rather than having documents requiring access to these bits to duplicate the effort: see for example  RFC8519 (look for "reserved" and "flags" in Page 33).

Good point.  3168 created the registry, but then didn't fully populate 
it with the bits that 793 had defined.


> * Position titles right after figure #, e.g.,
>
> OLD:
>
>                                 TCP Header Format
>
>               Note that one tick mark represents one bit position.
>
>                                   Figure 1
>
> NEW:
>
>               Note that one tick mark represents one bit position.
>
>                                   Figure 1: TCP Header Format

Also a good idea ... I will make this change, unless anyone shouts.


> * Introduce some notations used in the document (and a pointer to Appendix B), e.g.,
>
>       The window size MUST be treated as an unsigned number, or else
>       large window sizes will appear like negative windows and TCP will
>       now work (MUST-1) .  It is RECOMMENDED that implementations will
>                ^^^^^^^^
>       reserve 32-bit fields for the send and receive window sizes in the
>       connection record and do all window computations with 32 bits (REC-
>                                                                      ^^^^
>       1 ).
>
> Idem for SHLD-, etc.

Good point.  It seems like explaining this in the introduction will work.


> * Section 3.1
>
> OLD:
>
>       The checksum also covers a pseudo header conceptually prefixed to
>       the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
>       for IPv6.  For IPv4, this pseudo header contains the Source
>       Address, the Destination Address, the Protocol, and TCP length.
>
> NEW:
>       The checksum also covers a pseudo header conceptually prefixed to
>       the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
>       for IPv6.  For IPv4, this pseudo header contains the Source
>       Address, the Destination Address, the Protocol (PTCL), and TCP length.
>                                                      ^^^^^^
>
> * Section 3.1: Add missing figure legend, e.g.,
>
>                     +--------+--------+--------+--------+
>                     |           Source Address          |
>                     +--------+--------+--------+--------+
>                     |         Destination Address       |
>                     +--------+--------+--------+--------+
>                     |  zero  |  PTCL  |    TCP Length   |
>                     +--------+--------+--------+--------+
>
> * Section 3.3:
>
> OLD:
>   The synchronization requires each side to send it's own initial
>
> NEW:
>   The synchronization requires each side to send its own initial

Many thanks; all of the above suggestions look good to me.



From nobody Mon Jul 29 12:49:57 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24212003F for ; Mon, 29 Jul 2019 12:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 TFPhF_MXKmyZ for ; Mon, 29 Jul 2019 12:49:53 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 6400912002F for ; Mon, 29 Jul 2019 12:49:53 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id j5so118613137ioj.8 for ; Mon, 29 Jul 2019 12:49:53 -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-language; bh=A91kA79eUPrrf9SQK49yebniiE9gLaDjrZCAJknIY/8=; b=TJA6zovrBWe2ota4YIAsUi0uc25AkMvFnwoVQxui3jmGlqaKxkm6eJaXv7gyPHPwEK PJcv3kwRBnz39JhskqHvz3RfKNDGe+4HVfNhhpwZ09Irt7VZB7yy2PtLR0lsiiqiUZ8q PsfdlsUpV9H6Wi1UcacfymIORgbO07TTOBEoUjJ4/4qtQmKK1cGwMopHHiBm0s8igv8z UExPzVKI1sum8ZITQmkLijW9GoY9hcoXs8lcK6HMJk/TZ1b0iGXQ3MRbOZQnVmFIlnKB hqWvTqc4MqhRK0e4n6/PhO1yjKbEGd1K/t4P1wJkwpC6VUWlt5JFQSkWwC07xmet80A3 Av0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=A91kA79eUPrrf9SQK49yebniiE9gLaDjrZCAJknIY/8=; b=ebdzopnq9HPjIsSSCZPNRsSXkNZD/fIkYiHKlkXceDHR8cXy7WT6N8oTchakmpJYb9 Cn1yKlY9oX+L+t59DxQYjGR2Tyyn7wTQzjQo7cV0RQGEHPp+5Sr1PshvAKNB0012Q5nV Hpbf0F5xZik5C5uCM574jqjrwuRMW4ucn3i/OLsIIzRS+4GMTh/GRmOh1t8pcxss3mIY AiXP9gPgy9qW/E6PVIzvYEohU7DEfH7rOYN9Cb/3Gw8oX4VQ6Mbn4bLRRQBfxQlDHNhE QGyeH2ADSMxAs1rdgfIdttUHx5bkOfknrSoBgf+0LjKTtl1W5zL1rl22rMZLmxgdiaMH 3OWg==
X-Gm-Message-State: APjAAAUSQxigd6myP/DnRm+q7eLgemkwmxR8sElX03+C8rG8Nf/6ms64 24EGyFob6j/pFaLHr0G7+JpuZNQn
X-Google-Smtp-Source: APXvYqyRaiqoS+Bk2Ef76WLvTP1MriaIKkwOQmbskpeu4Xbl3yecEdhR+EMcUeh2AMcJlZzKFaCZNw==
X-Received: by 2002:a05:6638:38a:: with SMTP id y10mr118777981jap.104.1564429792562;  Mon, 29 Jul 2019 12:49:52 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id i3sm53445204ion.9.2019.07.29.12.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 12:49:51 -0700 (PDT)
To: Tim Wicinski 
Cc: Tommy Pauly , "tcpm@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com>  <7d37be26-70fc-5303-c5bf-3d379585648f@mti-systems.com> 
From: Wesley Eddy 
Message-ID: <784d1729-5fbb-7182-d5ce-e5090e427b50@mti-systems.com>
Date: Mon, 29 Jul 2019 15:49:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FAEEFF705CEAA9A821B6F154"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Jul 2019 19:49:55 -0000

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

On 7/29/2019 3:28 PM, Tim Wicinski wrote:
> Wes
>
> I've been staring at this one sentence
>
>     It does not replicate or attempt to update the introduction
>     and philosophy content inRFC 793    (sections1    and2    of*that*
>     document).
> The 793 link is the link to 793, but sections 1 & 2 are linked to this 
> document.
> Is the intention to link to the older document, or to the -bis document?
> That would help clear up "that document" or "this document" to me.
>
Aha! So, that hyperlinking appears to be a crazy thing that the IETF web 
tool for presenting HTML incorrectly inferred.  The XML source does not 
contain hyperlinks for those numbers.  Not sure how to fix ...



> Back in Section 1:
>      RFC 793    and other updates also contain
>     informative and descriptive text for human readers to understand
>     aspects of the protocol design and operation.  This document does not
>     attempt to alter or update this informative text, and is focused only
>     on updating the normative protocol specification.
>
> in DNSOP we struggled with this same question recently with 2845-bis
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
> Initially, the idea was to make as few a changes as possible to the 
> document,
> just make minor fixes.  But it became clear part of the reason there 
> was an
> issue with implementation was poor wording in the original document.
> Sadly, I have no simple answers.
>
Thanks for the perspective ... I'm hopeful that the most problematic 
parts of 793 in this regard have been fixed already in 1122 and 
elsewhere, and that by pasting in those updates, we've already handled 
them, but I guess will have to assess on a case-by-case basis.




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


  
    
  
  
    
On 7/29/2019 3:28 PM, Tim Wicinski
      wrote:

    

    

      
      

        

          

            
Wes
              


              

              
I've been staring at this one sentence 

              


              

              

                
   It does not replicate or attempt to update the introduction
   and philosophy content in RFC 793 (sections 1 and 2 of that
   document). 

                

                The 793 link is the link to 793, but sections 1 & 2
                are linked to this document. 

                Is the intention to link to the older document, or to
                the -bis document? 

                That would help clear up "that document" or "this
                document" to me.

                

              

            

          

        

      

    

    
Aha! So, that hyperlinking appears to be a crazy thing that the
      IETF web tool for presenting HTML incorrectly inferred.  The XML
      source does not contain hyperlinks for those numbers.  Not sure
      how to fix ...

    

    


    

    


    

    

      

        

          

            

              
Back in Section 1:
                

                
    RFC 793 and other updates also contain
   informative and descriptive text for human readers to understand
   aspects of the protocol design and operation.  This document does not
   attempt to alter or update this informative text, and is focused only
   on updating the normative protocol specification.

                

                

                in DNSOP we struggled with this same question recently
                with 2845-bis 

                https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/

                Initially, the idea was to make as few a changes as
                possible to the document, 

                just make minor fixes.  But it became clear part of the
                reason there was an 

                issue with implementation was poor wording in the
                original document. 

              
Sadly, I have no simple answers. 

            

          

        

      

      

    

    
Thanks for the perspective ... I'm hopeful that the most
      problematic parts of 793 in this regard have been fixed already in
      1122 and elsewhere, and that by pasting in those updates, we've
      already handled them, but I guess will have to assess on a
      case-by-case basis.

    

    


    

    

  


--------------FAEEFF705CEAA9A821B6F154--


From nobody Mon Jul 29 13:35:49 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72F120045 for ; Mon, 29 Jul 2019 13:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9jBCDpHyBVg for ; Mon, 29 Jul 2019 13:35:45 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6311C120043 for ; Mon, 29 Jul 2019 13:35:45 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6TKZhpk045946; Mon, 29 Jul 2019 13:35:43 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6TKZhQx045945; Mon, 29 Jul 2019 13:35:43 -0700 (PDT) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201907292035.x6TKZhQx045945@gndrsh.dnsmgr.net>
In-Reply-To: 
To: Wesley Eddy 
Date: Mon, 29 Jul 2019 13:35:43 -0700 (PDT)
CC: tcpm@ietf.org, mohamed.boucadair@orange.com
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Jul 2019 20:35:47 -0000

> Many thanks for your comments; my thoughts are below:
> 
> On 7/29/2019 5:35 AM, mohamed.boucadair@orange.com wrote:
> > Hi all,
> >
> > Please find below some very minor comments to enhance the readability of the document:
> >
> > * Consider moving Section 2.1 to be listed under Section 3.
> 
> Either way is fine with me; does anyone have strong preference? The 
> section numbering is closer to the original 793 numbering currently, and 
> this would probably bump that, but that is a very trivial concern.

I would counter that section renumbering breaks all external
references to this document by section number and should probably
be avoided at all cost.

As an example if someone wrote someplace "See section 2.1 of rfc793",
that reference would be broken, other than the new document is called
rfc793bis, that may be lost on the seeker of the information.

A search of the RFCs for section references to 793 could be attempted.

> > * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned with https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a special meaning: "Reserved:  Not assigned and not available for assignment.")
> 
> Thanks; I'll have to look at this in all cases and make sure we "do the 
> right thing".? I hadn't really been aware of 8126.

Though I am new here and may be wrong on this,
8126 is about IANA considerations and should, if I am
reading it correctly, only be apply to text in the IANA
consideration section of an RFC and not to the whole
body of it.

I especially do not like the definition of
Reserved as stated in 8126, that is more than reserved,
it is immutable.  But that is for the topic of another
draft.

> 
> > * Add a pointer to the "TCP Header Flags" registry: https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
> >
> > * Add an IANA action to update the above registry to include all TCP flags, not only those in 3168. Also, the description text in that page should be reworked, IMHO. Unassigned bits should also be indicated as such in that page.
> >
> > I would like to have those referenced in that page rather than having documents requiring access to these bits to duplicate the effort: see for example  RFC8519 (look for "reserved" and "flags" in Page 33).
> 
> Good point.? 3168 created the registry, but then didn't fully populate 
> it with the bits that 793 had defined.

This is probably of historical cause, 793 being a very early RFC.
It would be wrong of 3168 to populate anything
other than 3168 bits, but I see 793bis as populating
the other bits of TCP as a proper and needed update.

> > * Position titles right after figure #, e.g.,
> >
> > OLD:
> >
> >                                 TCP Header Format
> >
> >               Note that one tick mark represents one bit position.
> >
> >                                   Figure 1
> >
> > NEW:
> >
> >               Note that one tick mark represents one bit position.
> >
> >                                   Figure 1: TCP Header Format
> 
> Also a good idea ... I will make this change, unless anyone shouts.
> 
> 
> > * Introduce some notations used in the document (and a pointer to Appendix B), e.g.,
> >
> >       The window size MUST be treated as an unsigned number, or else
> >       large window sizes will appear like negative windows and TCP will
> >       now work (MUST-1) .  It is RECOMMENDED that implementations will
> >                ^^^^^^^^
> >       reserve 32-bit fields for the send and receive window sizes in the
> >       connection record and do all window computations with 32 bits (REC-
> >                                                                      ^^^^
> >       1 ).
> >
> > Idem for SHLD-, etc.
> 
> Good point.? It seems like explaining this in the introduction will work.
> 
> 
> > * Section 3.1
> >
> > OLD:
> >
> >       The checksum also covers a pseudo header conceptually prefixed to
> >       the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
> >       for IPv6.  For IPv4, this pseudo header contains the Source
> >       Address, the Destination Address, the Protocol, and TCP length.
> >
> > NEW:
> >       The checksum also covers a pseudo header conceptually prefixed to
> >       the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
> >       for IPv6.  For IPv4, this pseudo header contains the Source
> >       Address, the Destination Address, the Protocol (PTCL), and TCP length.
> >                                                      ^^^^^^
> >
> > * Section 3.1: Add missing figure legend, e.g.,
> >
> >                     +--------+--------+--------+--------+
> >                     |           Source Address          |
> >                     +--------+--------+--------+--------+
> >                     |         Destination Address       |
> >                     +--------+--------+--------+--------+
> >                     |  zero  |  PTCL  |    TCP Length   |
> >                     +--------+--------+--------+--------+
> >
> > * Section 3.3:
> >
> > OLD:
> >   The synchronization requires each side to send it's own initial
> >
> > NEW:
> >   The synchronization requires each side to send its own initial
> 
> Many thanks; all of the above suggestions look good to me.

Indeed.

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

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Mon Jul 29 22:38:45 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCA312006A for ; Mon, 29 Jul 2019 22:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJuturY81Th1 for ; Mon, 29 Jul 2019 22:38:41 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 D074A120052 for ; Mon, 29 Jul 2019 22:38:40 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 45yQMg0BMSz8wmd; Tue, 30 Jul 2019 07:38:39 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 45yQMf6LqgzCqkw; Tue, 30 Jul 2019 07:38:38 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 07:38:38 +0200
From: 
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, Wesley Eddy 
CC: "tcpm@ietf.org" 
Thread-Topic: [tcpm] Please review 793bis!
Thread-Index: AQHVRk01H/RbH/CiUUSAB9diEB6K9KbinZTA
Date: Tue, 30 Jul 2019 05:38:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312EAD42@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References:  <201907292035.x6TKZhQx045945@gndrsh.dnsmgr.net>
In-Reply-To: <201907292035.x6TKZhQx045945@gndrsh.dnsmgr.net>
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] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 30 Jul 2019 05:38:43 -0000

Hi Rodney,=20

Please see iline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Rodney W. Grimes [mailto:4bone@gndrsh.dnsmgr.net]
> Envoy=E9=A0: lundi 29 juillet 2019 22:36
> =C0=A0: Wesley Eddy
> Cc=A0: tcpm@ietf.org; BOUCADAIR Mohamed TGI/OLN
> Objet=A0: Re: [tcpm] Please review 793bis!
>=20
> > Many thanks for your comments; my thoughts are below:
> >
> > On 7/29/2019 5:35 AM, mohamed.boucadair@orange.com wrote:
> > > Hi all,
> > >
> > > Please find below some very minor comments to enhance the readability
> of the document:
> > >
> > > * Consider moving Section 2.1 to be listed under Section 3.
> >
> > Either way is fine with me; does anyone have strong preference? The
> > section numbering is closer to the original 793 numbering currently, an=
d
> > this would probably bump that, but that is a very trivial concern.
>=20
> I would counter that section renumbering breaks all external
> references to this document by section number and should probably
> be avoided at all cost.
>=20
> As an example if someone wrote someplace "See section 2.1 of rfc793",
> that reference would be broken, other than the new document is called
> rfc793bis, that may be lost on the seeker of the information.

[Med] Hmm, there is no such 2.1 in RFC793:

RFC793

1.  INTRODUCTION ..................................................... 1

  1.1  Motivation .................................................... 1
  1.2  Scope ......................................................... 2
  1.3  About This Document ........................................... 2
  1.4  Interfaces .................................................... 3
  1.5  Operation ..................................................... 3

2.  PHILOSOPHY ....................................................... 7

  2.1  Elements of the Internetwork System ........................... 7
  2.2  Model of Operation ............................................ 7
  2.3  The Host Environment .......................................... 8
  2.4  Interfaces .................................................... 9
  2.5  Relation to Other Protocols ................................... 9
  2.6  Reliable Communication ........................................ 9
  2.7  Connection Establishment and Clearing ........................ 10
  2.8  Data Communication ........................................... 12
  2.9  Precedence and Security ...................................... 13
  2.10 Robustness Principle ......................................... 13

3.  FUNCTIONAL SPECIFICATION ........................................ 15


RFC793bis

   1.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Key TCP Concepts  . . . . . . . . . . . . . . . . . . . .   5
   3.  Functional Specification  . . . . . . . . . . . . . . . . . .   5

I think that Wes tried to preserve the overall structure of Section 3. =20

>=20
> A search of the RFCs for section references to 793 could be attempted.
>=20
> > > * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned wit=
h
> https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a
> special meaning: "Reserved:  Not assigned and not available for
> assignment.")
> >
> > Thanks; I'll have to look at this in all cases and make sure we "do the
> > right thing".? I hadn't really been aware of 8126.
>=20
> Though I am new here and may be wrong on this,
> 8126 is about IANA considerations and should, if I am
> reading it correctly, only be apply to text in the IANA
> consideration section of an RFC and not to the whole
> body of it.

[Med] It will be weird to use "Reserved" in the main text and "Unassigned" =
in the IANA section. Following RFC8126 would be my favorite here.  =20

>=20
> I especially do not like the definition of
> Reserved as stated in 8126, that is more than reserved,
> it is immutable.  But that is for the topic of another
> draft.
>=20
> >
> > > * Add a pointer to the "TCP Header Flags" registry:
> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
> > >
> > > * Add an IANA action to update the above registry to include all TCP
> flags, not only those in 3168. Also, the description text in that page
> should be reworked, IMHO. Unassigned bits should also be indicated as suc=
h
> in that page.
> > >
> > > I would like to have those referenced in that page rather than having
> documents requiring access to these bits to duplicate the effort: see for
> example  RFC8519 (look for "reserved" and "flags" in Page 33).
> >
> > Good point.? 3168 created the registry, but then didn't fully populate
> > it with the bits that 793 had defined.
>=20
> This is probably of historical cause, 793 being a very early RFC.
> It would be wrong of 3168 to populate anything

[Med] There is nothing wrong with another RFC than 793 to create and initia=
lize the flags registry.=20

> other than 3168 bits, but I see 793bis as populating
> the other bits of TCP as a proper and needed update.

[Med] Hence the need to fix the registry rather than leaving it incomplete.

>=20
> > > * Position titles right after figure #, e.g.,
> > >
> > > OLD:
> > >
> > >                                 TCP Header Format
> > >
> > >               Note that one tick mark represents one bit position.
> > >
> > >                                   Figure 1
> > >
> > > NEW:
> > >
> > >               Note that one tick mark represents one bit position.
> > >
> > >                                   Figure 1: TCP Header Format
> >
> > Also a good idea ... I will make this change, unless anyone shouts.
> >
> >
> > > * Introduce some notations used in the document (and a pointer to
> Appendix B), e.g.,
> > >
> > >       The window size MUST be treated as an unsigned number, or else
> > >       large window sizes will appear like negative windows and TCP
> will
> > >       now work (MUST-1) .  It is RECOMMENDED that implementations wil=
l
> > >                ^^^^^^^^
> > >       reserve 32-bit fields for the send and receive window sizes in
> the
> > >       connection record and do all window computations with 32 bits
> (REC-
> > >
> ^^^^
> > >       1 ).
> > >
> > > Idem for SHLD-, etc.
> >
> > Good point.? It seems like explaining this in the introduction will
> work.
> >
> >
> > > * Section 3.1
> > >
> > > OLD:
> > >
> > >       The checksum also covers a pseudo header conceptually prefixed
> to
> > >       the TCP header.  The pseudo header is 96 bits for IPv4 and 320
> bits
> > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > >       Address, the Destination Address, the Protocol, and TCP length.
> > >
> > > NEW:
> > >       The checksum also covers a pseudo header conceptually prefixed
> to
> > >       the TCP header.  The pseudo header is 96 bits for IPv4 and 320
> bits
> > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > >       Address, the Destination Address, the Protocol (PTCL), and TCP
> length.
> > >                                                      ^^^^^^
> > >
> > > * Section 3.1: Add missing figure legend, e.g.,
> > >
> > >                     +--------+--------+--------+--------+
> > >                     |           Source Address          |
> > >                     +--------+--------+--------+--------+
> > >                     |         Destination Address       |
> > >                     +--------+--------+--------+--------+
> > >                     |  zero  |  PTCL  |    TCP Length   |
> > >                     +--------+--------+--------+--------+
> > >
> > > * Section 3.3:
> > >
> > > OLD:
> > >   The synchronization requires each side to send it's own initial
> > >
> > > NEW:
> > >   The synchronization requires each side to send its own initial
> >
> > Many thanks; all of the above suggestions look good to me.
>=20
> Indeed.
>=20
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>=20
> --
> Rod Grimes
> rgrimes@freebsd.org


From nobody Tue Jul 30 06:09:42 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CE012013D for ; Tue, 30 Jul 2019 06:09:41 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-yQgFdTzZu0 for ; Tue, 30 Jul 2019 06:09:39 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0893F12010D for ; Tue, 30 Jul 2019 06:09:33 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6UD9VDw049399; Tue, 30 Jul 2019 06:09:31 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6UD9UvH049398; Tue, 30 Jul 2019 06:09:30 -0700 (PDT) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201907301309.x6UD9UvH049398@gndrsh.dnsmgr.net>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312EAD42@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
Date: Tue, 30 Jul 2019 06:09:30 -0700 (PDT)
CC: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, Wesley Eddy , "tcpm@ietf.org" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 30 Jul 2019 13:09:41 -0000

Hello Med,
Replied inline, trying to get this style, so pardon any
mistakes I may be making.

Regards,
Rod

> Hi Rodney, 
> 
> Please see iline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De?: Rodney W. Grimes [mailto:4bone@gndrsh.dnsmgr.net]
> > Envoy??: lundi 29 juillet 2019 22:36
> > ??: Wesley Eddy
> > Cc?: tcpm@ietf.org; BOUCADAIR Mohamed TGI/OLN
> > Objet?: Re: [tcpm] Please review 793bis!
> > 
> > > Many thanks for your comments; my thoughts are below:
> > >
> > > On 7/29/2019 5:35 AM, mohamed.boucadair@orange.com wrote:
> > > > Hi all,
> > > >
> > > > Please find below some very minor comments to enhance the readability
> > of the document:
> > > >
> > > > * Consider moving Section 2.1 to be listed under Section 3.

 [RWG] If infact the author "moves" section 2.1 to be under 3
in the draft in effect 2.1 would either go away, or become
something different.

> > >
> > > Either way is fine with me; does anyone have strong preference? The
> > > section numbering is closer to the original 793 numbering currently, and
> > > this would probably bump that, but that is a very trivial concern.
> > 
> > I would counter that section renumbering breaks all external
> > references to this document by section number and should probably
> > be avoided at all cost.
> > 
> > As an example if someone wrote someplace "See section 2.1 of rfc793",
> > that reference would be broken, other than the new document is called
> > rfc793bis, that may be lost on the seeker of the information.
> 
> [Med] Hmm, there is no such 2.1 in RFC793:

 [RWG] Perhaps another cup of coffee?  :-)
 
> RFC793
> 
> 1.  INTRODUCTION ..................................................... 1
> 
>   1.1  Motivation .................................................... 1
>   1.2  Scope ......................................................... 2
>   1.3  About This Document ........................................... 2
>   1.4  Interfaces .................................................... 3
>   1.5  Operation ..................................................... 3
> 
> 2.  PHILOSOPHY ....................................................... 7
> 
>   2.1  Elements of the Internetwork System ........................... 7

 [RWG] This does look to be a section 2.1 to me, did you miss it?

>   2.2  Model of Operation ............................................ 7
>   2.3  The Host Environment .......................................... 8
>   2.4  Interfaces .................................................... 9
>   2.5  Relation to Other Protocols ................................... 9
>   2.6  Reliable Communication ........................................ 9
>   2.7  Connection Establishment and Clearing ........................ 10
>   2.8  Data Communication ........................................... 12
>   2.9  Precedence and Security ...................................... 13
>   2.10 Robustness Principle ......................................... 13
> 
> 3.  FUNCTIONAL SPECIFICATION ........................................ 15
> 
> 
> RFC793bis
> 
>    1.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   3
>    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
>      2.1.  Key TCP Concepts  . . . . . . . . . . . . . . . . . . . .   5
>    3.  Functional Specification  . . . . . . . . . . . . . . . . . .   5
> 
> I think that Wes tried to preserve the overall structure of Section 3.  

 [RWG] I am concerned about historical references to this document in
such things as code, text books, and other RFC's, but without solid
evidence to that effect I have little ground to stand on.

On the other hand I should further investigate:
./sys/netinet/tcp_fsm.h: * Per RFC793, September, 1981.
./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria for accepting SYN packets");
./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria for accepting RST packets");
./sys/netinet/tcp_input.c:               * is equivalent to the smoothing algorithm in rfc793 with
./sys/netinet/tcp_input.c:               * equivalent to rfc793 smoothing with an alpha of .75
./sys/netinet/tcp_input.c:               * rfc793's wired-in beta.
./sys/netinet/tcp_syncache.c:    * See RFC 793 page 65, section SEGMENT ARRIVES.
./sys/netinet/tcp_syncache.c:    * RFC 793 page 37:

I do understand that the document name is changing, but how to make
it clear to a person reading the code above and pulling up 793bis that they
should be looking to 793 is unclear to me at this point in time.

Is it possible to use the datatracker to see the changes
from rfc793 to rfc793bis?

What about a section on "what has changed, added, and/or removed",
usually when a specification evolves over time there is a history
section that itemizes the changes.  This may be asking for far too
much in this case though.

> > 
> > A search of the RFCs for section references to 793 could be attempted.
> > 
> > > > * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned with
> > https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a
> > special meaning: "Reserved:  Not assigned and not available for
> > assignment.")
> > >
> > > Thanks; I'll have to look at this in all cases and make sure we "do the
> > > right thing".? I hadn't really been aware of 8126.
> > 
> > Though I am new here and may be wrong on this,
> > 8126 is about IANA considerations and should, if I am
> > reading it correctly, only be apply to text in the IANA
> > consideration section of an RFC and not to the whole
> > body of it.
> 
> [Med] It will be weird to use "Reserved" in the main text and "Unassigned" in the IANA section. Following RFC8126 would be my favorite here.   

 [RWG] Have it read "Unassigned" in the spec that has almost 40
years of running code that call it rsrvd is of equal
concern from an implementers standpoint.  Any attempt
to back port RFC8126 language into the prior 8000 RFC's seems
difficult.

Should RFC8126 apply to any RFC prior to it unless
explicitly stated in the header of RFC8126?  Or is it the
fact that chrnologically RFC793bis is after 8126 that should
be applied here.  That would require one to have a date order
of issue index to the rfcs?

> 
> > 
> > I especially do not like the definition of
> > Reserved as stated in 8126, that is more than reserved,
> > it is immutable.  But that is for the topic of another
> > draft.
> > 
> > >
> > > > * Add a pointer to the "TCP Header Flags" registry:
> > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
> > > >
> > > > * Add an IANA action to update the above registry to include all TCP
> > flags, not only those in 3168. Also, the description text in that page
> > should be reworked, IMHO. Unassigned bits should also be indicated as such
> > in that page.
> > > >
> > > > I would like to have those referenced in that page rather than having
> > documents requiring access to these bits to duplicate the effort: see for
> > example  RFC8519 (look for "reserved" and "flags" in Page 33).
> > >
> > > Good point.? 3168 created the registry, but then didn't fully populate
> > > it with the bits that 793 had defined.
> > 
> > This is probably of historical cause, 793 being a very early RFC.
> > It would be wrong of 3168 to populate anything
> 
> [Med] There is nothing wrong with another RFC than 793 to create and initialize the flags registry. 

 [RWG] I think it would be incorrect to do so, it would surely mess up 
the presentation of information in the:
https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
page which has back references to the RFC that had the IANA consideration.

If rfc3168 had populated say the SYN code point, the reference at IANA would
be to rfc3168 and yet in that RFC I would find little information on
the definition of the SYN flag.

> 
> > other than 3168 bits, but I see 793bis as populating
> > the other bits of TCP as a proper and needed update.
> 
> [Med] Hence the need to fix the registry rather than leaving it incomplete.
 [RWG] We fully agree on that

> 
> > 
> > > > * Position titles right after figure #, e.g.,
> > > >
> > > > OLD:
> > > >
> > > >                                 TCP Header Format
> > > >
> > > >               Note that one tick mark represents one bit position.
> > > >
> > > >                                   Figure 1
> > > >
> > > > NEW:
> > > >
> > > >               Note that one tick mark represents one bit position.
> > > >
> > > >                                   Figure 1: TCP Header Format
> > >
> > > Also a good idea ... I will make this change, unless anyone shouts.
> > >
> > >
> > > > * Introduce some notations used in the document (and a pointer to
> > Appendix B), e.g.,
> > > >
> > > >       The window size MUST be treated as an unsigned number, or else
> > > >       large window sizes will appear like negative windows and TCP
> > will
> > > >       now work (MUST-1) .  It is RECOMMENDED that implementations will
> > > >                ^^^^^^^^
> > > >       reserve 32-bit fields for the send and receive window sizes in
> > the
> > > >       connection record and do all window computations with 32 bits
> > (REC-
> > > >
> > ^^^^
> > > >       1 ).
> > > >
> > > > Idem for SHLD-, etc.
> > >
> > > Good point.? It seems like explaining this in the introduction will
> > work.
> > >
> > >
> > > > * Section 3.1
> > > >
> > > > OLD:
> > > >
> > > >       The checksum also covers a pseudo header conceptually prefixed
> > to
> > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and 320
> > bits
> > > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > > >       Address, the Destination Address, the Protocol, and TCP length.
> > > >
> > > > NEW:
> > > >       The checksum also covers a pseudo header conceptually prefixed
> > to
> > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and 320
> > bits
> > > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > > >       Address, the Destination Address, the Protocol (PTCL), and TCP
> > length.
> > > >                                                      ^^^^^^
> > > >
> > > > * Section 3.1: Add missing figure legend, e.g.,
> > > >
> > > >                     +--------+--------+--------+--------+
> > > >                     |           Source Address          |
> > > >                     +--------+--------+--------+--------+
> > > >                     |         Destination Address       |
> > > >                     +--------+--------+--------+--------+
> > > >                     |  zero  |  PTCL  |    TCP Length   |
> > > >                     +--------+--------+--------+--------+
> > > >
> > > > * Section 3.3:
> > > >
> > > > OLD:
> > > >   The synchronization requires each side to send it's own initial
> > > >
> > > > NEW:
> > > >   The synchronization requires each side to send its own initial
> > >
> > > Many thanks; all of the above suggestions look good to me.
> > 
> > Indeed.
> > 
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > 
> > --
> > Rod Grimes
> > rgrimes@freebsd.org

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Tue Jul 30 07:21: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 A5425120187 for ; Tue, 30 Jul 2019 07:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4vIdrHuXdrI for ; Tue, 30 Jul 2019 07:21:36 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 EF32B120191 for ; Tue, 30 Jul 2019 07:21:34 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 45ydz13DlXz5vcB; Tue, 30 Jul 2019 16:21:33 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 45ydz12JCqzCqkS; Tue, 30 Jul 2019 16:21:33 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 16:21:33 +0200
From: 
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
CC: Wesley Eddy , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Please review 793bis!
Thread-Index: AQHVRtgPWRbqJY2yX0OPldMPnq75UabjLLKg
Date: Tue, 30 Jul 2019 14:21:32 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312EB1DB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330312EAD42@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <201907301309.x6UD9UvH049398@gndrsh.dnsmgr.net>
In-Reply-To: <201907301309.x6UD9UvH049398@gndrsh.dnsmgr.net>
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] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 30 Jul 2019 14:21:40 -0000

Re-,

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Rodney W. Grimes [mailto:4bone@gndrsh.dnsmgr.net]
> Envoy=E9=A0: mardi 30 juillet 2019 15:10
> =C0=A0: BOUCADAIR Mohamed TGI/OLN
> Cc=A0: Rodney W. Grimes; Wesley Eddy; tcpm@ietf.org
> Objet=A0: Re: [tcpm] Please review 793bis!
>=20
> Hello Med,
> Replied inline, trying to get this style, so pardon any
> mistakes I may be making.
>=20
> Regards,
> Rod
>=20
> > Hi Rodney,
> >
> > Please see iline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De?: Rodney W. Grimes [mailto:4bone@gndrsh.dnsmgr.net]
> > > Envoy??: lundi 29 juillet 2019 22:36
> > > ??: Wesley Eddy
> > > Cc?: tcpm@ietf.org; BOUCADAIR Mohamed TGI/OLN
> > > Objet?: Re: [tcpm] Please review 793bis!
> > >
> > > > Many thanks for your comments; my thoughts are below:
> > > >
> > > > On 7/29/2019 5:35 AM, mohamed.boucadair@orange.com wrote:
> > > > > Hi all,
> > > > >
> > > > > Please find below some very minor comments to enhance the
> readability
> > > of the document:
> > > > >
> > > > > * Consider moving Section 2.1 to be listed under Section 3.
>=20
>  [RWG] If infact the author "moves" section 2.1 to be under 3
> in the draft in effect 2.1 would either go away, or become
> something different.
>=20
> > > >
> > > > Either way is fine with me; does anyone have strong preference? The
> > > > section numbering is closer to the original 793 numbering currently=
,
> and
> > > > this would probably bump that, but that is a very trivial concern.
> > >
> > > I would counter that section renumbering breaks all external
> > > references to this document by section number and should probably
> > > be avoided at all cost.
> > >
> > > As an example if someone wrote someplace "See section 2.1 of rfc793",
> > > that reference would be broken, other than the new document is called
> > > rfc793bis, that may be lost on the seeker of the information.
> >
> > [Med] Hmm, there is no such 2.1 in RFC793:
>=20
>  [RWG] Perhaps another cup of coffee?  :-)

[Med] I meant there is no "such" text in 793. See below ...

>=20
> > RFC793
> >
> > 1.  INTRODUCTION ..................................................... =
1
> >
> >   1.1  Motivation .................................................... =
1
> >   1.2  Scope ......................................................... =
2
> >   1.3  About This Document ........................................... =
2
> >   1.4  Interfaces .................................................... =
3
> >   1.5  Operation ..................................................... =
3
> >
> > 2.  PHILOSOPHY ....................................................... =
7
> >
> >   2.1  Elements of the Internetwork System ........................... =
7
>=20
>  [RWG] This does look to be a section 2.1 to me, did you miss it?

[Med] No. The new text in 2.1 of 793bis has nothing to do with this one. If=
 you used to cite that section from 793, then that citation will be broken =
when RFC793bis will be published.=20

>=20
> >   2.2  Model of Operation ............................................ =
7
> >   2.3  The Host Environment .......................................... =
8
> >   2.4  Interfaces .................................................... =
9
> >   2.5  Relation to Other Protocols ................................... =
9
> >   2.6  Reliable Communication ........................................ =
9
> >   2.7  Connection Establishment and Clearing ........................ 1=
0
> >   2.8  Data Communication ........................................... 1=
2
> >   2.9  Precedence and Security ...................................... 1=
3
> >   2.10 Robustness Principle ......................................... 1=
3
> >
> > 3.  FUNCTIONAL SPECIFICATION ........................................ 1=
5
> >
> >
> > RFC793bis
> >
> >    1.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   =
3
> >    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   =
4
> >      2.1.  Key TCP Concepts  . . . . . . . . . . . . . . . . . . . .   =
5
> >    3.  Functional Specification  . . . . . . . . . . . . . . . . . .   =
5
> >
> > I think that Wes tried to preserve the overall structure of Section 3.
>=20
>  [RWG] I am concerned about historical references to this document in
> such things as code, text books, and other RFC's, but without solid
> evidence to that effect I have little ground to stand on.

[Med] Your concern is a valid one. There is a trade-off out there: readabil=
ity vs. how to easily identify changes.

>=20
> On the other hand I should further investigate:
> ./sys/netinet/tcp_fsm.h: * Per RFC793, September, 1981.
> ./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria
> for accepting SYN packets");
> ./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria
> for accepting RST packets");
> ./sys/netinet/tcp_input.c:               * is equivalent to the smoothing
> algorithm in rfc793 with
> ./sys/netinet/tcp_input.c:               * equivalent to rfc793 smoothing
> with an alpha of .75
> ./sys/netinet/tcp_input.c:               * rfc793's wired-in beta.
> ./sys/netinet/tcp_syncache.c:    * See RFC 793 page 65, section SEGMENT
> ARRIVES.
> ./sys/netinet/tcp_syncache.c:    * RFC 793 page 37:
>=20
> I do understand that the document name is changing, but how to make
> it clear to a person reading the code above and pulling up 793bis that
> they
> should be looking to 793 is unclear to me at this point in time.
>=20
> Is it possible to use the datatracker to see the changes
> from rfc793 to rfc793bis?

[Med] I'm afraid the diff provided by the datatracker is not helpful: https=
://www.ietf.org/rfcdiff?url1=3Drfc793&url2=3Ddraft-ietf-tcpm-rfc793bis-13.=
=20

>=20
> What about a section on "what has changed, added, and/or removed",

[Med] There is already one: Please refer to https://tools.ietf.org/html/dra=
ft-ietf-tcpm-rfc793bis-13#section-4  =20

> usually when a specification evolves over time there is a history
> section that itemizes the changes.  This may be asking for far too
> much in this case though.
>=20
> > >
> > > A search of the RFCs for section references to 793 could be attempted=
.
> > >
> > > > > * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned
> with
> > > https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a
> > > special meaning: "Reserved:  Not assigned and not available for
> > > assignment.")
> > > >
> > > > Thanks; I'll have to look at this in all cases and make sure we "do
> the
> > > > right thing".? I hadn't really been aware of 8126.
> > >
> > > Though I am new here and may be wrong on this,
> > > 8126 is about IANA considerations and should, if I am
> > > reading it correctly, only be apply to text in the IANA
> > > consideration section of an RFC and not to the whole
> > > body of it.
> >
> > [Med] It will be weird to use "Reserved" in the main text and
> "Unassigned" in the IANA section. Following RFC8126 would be my favorite
> here.
>=20
>  [RWG] Have it read "Unassigned" in the spec that has almost 40
> years of running code that call it rsrvd is of equal
> concern from an implementers standpoint.  Any attempt
> to back port RFC8126 language into the prior 8000 RFC's seems
> difficult.

[Med] The name of the field can be maintained as it is. No need to change i=
t to "UUUU". The change will be in the main text, e.g.,:

OLD:=20

   Rsrvd - Reserved:  4 bits

     Reserved for future use.  Must be zero in generated segments and
     must be ignored in received segments, if corresponding future
     features are unimplemented by the sending or receiving host.

NEW:

   Rsrvd - Unassigned:  4 bits

     Not assigned, and available for assignment.  MUST be zero in generated=
 segments and
     MUST be ignored in received segments, if corresponding future
     features are unimplemented by the sending or receiving host.

And in the IANA section:

NEW:
  New flags bits can be assigned via Standards Action [RFC8126].


>=20
> Should RFC8126 apply to any RFC prior to it unless
> explicitly stated in the header of RFC8126?  Or is it the
> fact that chrnologically RFC793bis is after 8126 that should
> be applied here.  That would require one to have a date order
> of issue index to the rfcs?

[Med] Given that there are pending IANA actions to fix the tcp flags regist=
ry, RFC8126 language should be followed.

>=20
> >
> > >
> > > I especially do not like the definition of
> > > Reserved as stated in 8126, that is more than reserved,
> > > it is immutable.  But that is for the topic of another
> > > draft.
> > >
> > > >
> > > > > * Add a pointer to the "TCP Header Flags" registry:
> > > https://www.iana.org/assignments/tcp-header-flags/tcp-header-
> flags.xhtml
> > > > >
> > > > > * Add an IANA action to update the above registry to include all
> TCP
> > > flags, not only those in 3168. Also, the description text in that pag=
e
> > > should be reworked, IMHO. Unassigned bits should also be indicated as
> such
> > > in that page.
> > > > >
> > > > > I would like to have those referenced in that page rather than
> having
> > > documents requiring access to these bits to duplicate the effort: see
> for
> > > example  RFC8519 (look for "reserved" and "flags" in Page 33).
> > > >
> > > > Good point.? 3168 created the registry, but then didn't fully
> populate
> > > > it with the bits that 793 had defined.
> > >
> > > This is probably of historical cause, 793 being a very early RFC.
> > > It would be wrong of 3168 to populate anything
> >
> > [Med] There is nothing wrong with another RFC than 793 to create and
> initialize the flags registry.
>=20
>  [RWG] I think it would be incorrect to do so, it would surely mess up
> the presentation of information in the:
> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
> page which has back references to the RFC that had the IANA consideration=
.
>=20
> If rfc3168 had populated say the SYN code point, the reference at IANA
> would
> be to rfc3168 and yet in that RFC I would find little information on
> the definition of the SYN flag.

[Med] The reference clause of the SYN in such case will need to point to RF=
C793, not RFC3168. This is straightforward. =20

>=20
> >
> > > other than 3168 bits, but I see 793bis as populating
> > > the other bits of TCP as a proper and needed update.
> >
> > [Med] Hence the need to fix the registry rather than leaving it
> incomplete.
>  [RWG] We fully agree on that

[Med] Great! Thanks.

>=20
> >
> > >
> > > > > * Position titles right after figure #, e.g.,
> > > > >
> > > > > OLD:
> > > > >
> > > > >                                 TCP Header Format
> > > > >
> > > > >               Note that one tick mark represents one bit position=
.
> > > > >
> > > > >                                   Figure 1
> > > > >
> > > > > NEW:
> > > > >
> > > > >               Note that one tick mark represents one bit position=
.
> > > > >
> > > > >                                   Figure 1: TCP Header Format
> > > >
> > > > Also a good idea ... I will make this change, unless anyone shouts.
> > > >
> > > >
> > > > > * Introduce some notations used in the document (and a pointer to
> > > Appendix B), e.g.,
> > > > >
> > > > >       The window size MUST be treated as an unsigned number, or
> else
> > > > >       large window sizes will appear like negative windows and TC=
P
> > > will
> > > > >       now work (MUST-1) .  It is RECOMMENDED that implementations
> will
> > > > >                ^^^^^^^^
> > > > >       reserve 32-bit fields for the send and receive window sizes
> in
> > > the
> > > > >       connection record and do all window computations with 32
> bits
> > > (REC-
> > > > >
> > > ^^^^
> > > > >       1 ).
> > > > >
> > > > > Idem for SHLD-, etc.
> > > >
> > > > Good point.? It seems like explaining this in the introduction will
> > > work.
> > > >
> > > >
> > > > > * Section 3.1
> > > > >
> > > > > OLD:
> > > > >
> > > > >       The checksum also covers a pseudo header conceptually
> prefixed
> > > to
> > > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and
> 320
> > > bits
> > > > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > > > >       Address, the Destination Address, the Protocol, and TCP
> length.
> > > > >
> > > > > NEW:
> > > > >       The checksum also covers a pseudo header conceptually
> prefixed
> > > to
> > > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and
> 320
> > > bits
> > > > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > > > >       Address, the Destination Address, the Protocol (PTCL), and
> TCP
> > > length.
> > > > >                                                      ^^^^^^
> > > > >
> > > > > * Section 3.1: Add missing figure legend, e.g.,
> > > > >
> > > > >                     +--------+--------+--------+--------+
> > > > >                     |           Source Address          |
> > > > >                     +--------+--------+--------+--------+
> > > > >                     |         Destination Address       |
> > > > >                     +--------+--------+--------+--------+
> > > > >                     |  zero  |  PTCL  |    TCP Length   |
> > > > >                     +--------+--------+--------+--------+
> > > > >
> > > > > * Section 3.3:
> > > > >
> > > > > OLD:
> > > > >   The synchronization requires each side to send it's own initial
> > > > >
> > > > > NEW:
> > > > >   The synchronization requires each side to send its own initial
> > > >
> > > > Many thanks; all of the above suggestions look good to me.
> > >
> > > Indeed.
> > >
> > > > _______________________________________________
> > > > tcpm mailing list
> > > > tcpm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> > > --
> > > Rod Grimes
> > > rgrimes@freebsd.org
>=20
> --
> Rod Grimes
> rgrimes@freebsd.org


From nobody Tue Jul 30 10:47:17 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 C5857120089; Tue, 30 Jul 2019 10:47:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tcpm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <156450882771.14172.10175930421514149218@ietfa.amsl.com>
Date: Tue, 30 Jul 2019 10:47:07 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-14.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jul 2019 17:47:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-14.txt
	Pages           : 104
	Date            : 2019-07-30

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

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



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

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

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


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

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


From nobody Tue Jul 30 10:56: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 3AACF1201F3 for ; Tue, 30 Jul 2019 10:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW72ejEj8eJc for ; Tue, 30 Jul 2019 10:56:43 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 527171201ED for ; Tue, 30 Jul 2019 10:56:43 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id j6so10380345ioa.5 for ; Tue, 30 Jul 2019 10:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=d0XjghlW4S8XxCoOB3qAFQ/B6P3Pugncgb6Y66/tQSg=; b=yndK57sbu53+2iPraXq5db0nJIndLsS4s5q4niiOVsGIiuH3TYjxot/TxLRDdzLwmv mHqqieaJhgjsGgwmDD8i87YEYCLBVrQvmC/C6mkP3Og8Jb0BF0gyMCSJRCX6cE9PeaaS gk11KIjvmurwV4wCG/SwP/FJIVP8k6r+LWifKQeK9EN0QLXLt7JkuMV/Up9S9SqDRnNq K4vmRkx+caOxkjQp8VgY9VNhlCPtrDIss+jwnx06cJhVFuNsvR3vJcO9JFjC4NSn+37T yV9REm0qWio8qEcjJ5xbXJCFkPSBw7EByTXF+GNpBM7ANUrUUFFlHQiumxCPFS7ZJnqq lmHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=d0XjghlW4S8XxCoOB3qAFQ/B6P3Pugncgb6Y66/tQSg=; b=f+8ClROuYS4TSY8YXyiJ6LmS2XONV0mLiVE3vqr8A5S9qfpF+hecBXjxn3F/mSoLAZ UMBZkqt7Dtjt1LIjOMxpfbLzeNBhPROAWkBSmHdLANFnWAW1UwyO+lfVD2for3Wv//D4 2I+fLJAsfxfL3CcRY63ucRpQp67z5Iwv33GY2W0U7vnO9XCgPoOsULq62Vamr1AX8R54 2Q8n5ELVyTZ5dDY13+36o66mISarwDQ0K327bW0uuvwOJrvyVavOKm+WvMKyPdOlGjpW kH6MBQixlAxECzbD/tQ6D8Qyu1slVZkC45AYqYMwjItS27WL5feBcrKhrh1nGHA8dylb 9D/A==
X-Gm-Message-State: APjAAAWUYqVsAfUPk7U1nWdwI5sQqNLnCKxWtCocRDpZ+IFSi9awXKNO DxkccdsBo1raqzyWogvWORDKa9m7
X-Google-Smtp-Source: APXvYqzflNAU5J9ah6Okfo7EcBv12xFIIPnuVUMWOVLClXQZeMjUuWAVgREHxxWXMIn5hS0uuIHq9w==
X-Received: by 2002:a5e:d618:: with SMTP id w24mr19791417iom.73.1564509402505;  Tue, 30 Jul 2019 10:56:42 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id e22sm49855080iob.66.2019.07.30.10.56.41 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 10:56:41 -0700 (PDT)
References: <156450882804.14172.17458284787319017749.idtracker@ietfa.amsl.com>
To: tcpm IETF list 
From: Wesley Eddy 
X-Forwarded-Message-Id: <156450882804.14172.17458284787319017749.idtracker@ietfa.amsl.com>
Message-ID: <10a8eba2-0d55-bd5d-ad22-4884f485a3de@mti-systems.com>
Date: Tue, 30 Jul 2019 13:56:39 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <156450882804.14172.17458284787319017749.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------46C7CFE1476C865BA66146F4"
Content-Language: en-US
Archived-At: 
Subject: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jul 2019 17:56:46 -0000

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

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

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

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

- Did not yet move section 2.1.

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



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





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

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

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

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




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

The IETF Secretariat


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


  

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

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

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

    

    
- Did not yet move section 2.1.

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

    

    


      

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

        
          

            Subject:
            
            New Version Notification for
              draft-ietf-tcpm-rfc793bis-14.txt
          

          

            Date: 
            Tue, 30 Jul 2019 10:47:08 -0700
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Wesley M. Eddy <wes@mti-systems.com>, Wesley Eddy
              <wes@mti-systems.com>
          

        
      

      

      

      

      A new version of I-D, draft-ietf-tcpm-rfc793bis-14.txt

      has been successfully submitted by Wesley M. Eddy and posted to
      the

      IETF repository.

      

      Name: draft-ietf-tcpm-rfc793bis

      Revision: 14

      Title: Transmission Control Protocol Specification

      Document date: 2019-07-30

      Group: tcpm

      Pages: 104

      URL:
      https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc793bis-14.txt

      Status:
      https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

      Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14

      Htmlized:
      https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis

      Diff:
      https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-14

      

      Abstract:

      This document specifies the Internet's Transmission Control
      Protocol

      (TCP). TCP is an important transport layer protocol in the
      Internet

      stack, and has continuously evolved over decades of use and growth
      of

      the Internet. Over this time, a number of changes have been made
      to

      TCP as it was specified in RFC 793, though these have only been

      documented in a piecemeal fashion. This document collects and
      brings

      those changes together with the protocol specification from RFC
      793.

      This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,

      6528, and 6691 that updated parts of RFC 793. It updates RFC 1122,

      and should be considered as a replacement for the portions of that

      document dealing with TCP requirements. It updates RFC 5961 due to
      a

      small clarification in reset handling while in the SYN-RECEIVED

      state.

      

      RFC EDITOR NOTE: If approved for publication as an RFC, this
      should

      be marked additionally as "STD: 7" and replace RFC 793 in that
      role.

      

      

      

      

      Please note that it may take a couple of minutes from the time of
      submission

      until the htmlized version and diff are available at
      tools.ietf.org.

      

      The IETF Secretariat

      

    

  


--------------46C7CFE1476C865BA66146F4--


From nobody Tue Jul 30 12:09:00 2019
Return-Path: <4bone@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900312010F for ; Tue, 30 Jul 2019 12:08:58 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUToJljmL76N for ; Tue, 30 Jul 2019 12:08:55 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CF5120119 for ; Tue, 30 Jul 2019 12:08:55 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6UJ8sE5050849; Tue, 30 Jul 2019 12:08:54 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6UJ8rWr050848; Tue, 30 Jul 2019 12:08:53 -0700 (PDT) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201907301908.x6UJ8rWr050848@gndrsh.dnsmgr.net>
In-Reply-To: <10a8eba2-0d55-bd5d-ad22-4884f485a3de@mti-systems.com>
To: Wesley Eddy 
Date: Tue, 30 Jul 2019 12:08:53 -0700 (PDT)
CC: tcpm IETF list 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jul 2019 19:08:58 -0000

Comments in Line,

> Hello, this incorporates some small cleanups that accumulated prior to 
> the IETF meeting, as well as some of the feedback received since then on 
> the mailing list.
> 
> A couple specific things not yet done (because it doesn't look like we 
> converged on the list yet):
> 
> - Did not yet change reserved bits to "unassigned" (nor indicate them in 
> the IANA considerations section).? Rod Grimes has a good point about 
> these being very commonly referred to as "the reserved bits" in other 
> places.? I'm thinking we could add a note to say that in IANA terms 
> they're "Unassigned" to add the clarity that Mohamed is advocating, but 
> not change the name?

 [rwg] I support this as a reasonable compromise.

> 
> - Did not yet move section 2.1.

Given the extensive self contained list of changes already included
in this document I retract my assertions that this may not be the
best thing to do.

> 
> - Did not yet remove the note about my confusion on MUST vs SHOULD 
> regarding reporting of excessive retransmissions in RFC 1122 (will 
> confirm on the mailing list the "no change" proposal that was suggested 
> at the meeting)
> 
> 
> 
> -------- Forwarded Message --------
> Subject: 	New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
> Date: 	Tue, 30 Jul 2019 10:47:08 -0700
> From: 	internet-drafts@ietf.org
> To: 	Wesley M. Eddy , Wesley Eddy 
> 
> 
> 
> 
> 
> A new version of I-D, draft-ietf-tcpm-rfc793bis-14.txt
> has been successfully submitted by Wesley M. Eddy and posted to the
> IETF repository.
> 
> Name: draft-ietf-tcpm-rfc793bis
> Revision: 14
> Title: Transmission Control Protocol Specification
> Document date: 2019-07-30
> Group: tcpm
> Pages: 104
> URL: https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc793bis-14.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
> Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-14
> 
> Abstract:
> This document specifies the Internet's Transmission Control Protocol
> (TCP). TCP is an important transport layer protocol in the Internet
> stack, and has continuously evolved over decades of use and growth of
> the Internet. Over this time, a number of changes have been made to
> TCP as it was specified in RFC 793, though these have only been
> documented in a piecemeal fashion. This document collects and brings
> those changes together with the protocol specification from RFC 793.
> This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
> 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122,
> and should be considered as a replacement for the portions of that
> document dealing with TCP requirements. It updates RFC 5961 due to a
> small clarification in reset handling while in the SYN-RECEIVED
> state.
> 
> RFC EDITOR NOTE: If approved for publication as an RFC, this should
> be marked additionally as "STD: 7" and replace RFC 793 in that role.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

-- 
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Tue Jul 30 22:43: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 494E212007C for ; Tue, 30 Jul 2019 22:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 AjMV7u2AWY-R for ; Tue, 30 Jul 2019 22:43:00 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 445DC120045 for ; Tue, 30 Jul 2019 22:43:00 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 45z2QB15BLz108J; Wed, 31 Jul 2019 07:42:58 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 45z2QB07RGzDq7X; Wed, 31 Jul 2019 07:42:58 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 07:42:57 +0200
From: 
To: Wesley Eddy , tcpm IETF list 
Thread-Topic: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
Thread-Index: AQHVRwAuECMnSR1inEOUmPcvcqh2dabkM0GA
Date: Wed, 31 Jul 2019 05:42:57 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312EB6CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <156450882804.14172.17458284787319017749.idtracker@ietfa.amsl.com> <10a8eba2-0d55-bd5d-ad22-4884f485a3de@mti-systems.com>
In-Reply-To: <10a8eba2-0d55-bd5d-ad22-4884f485a3de@mti-systems.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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330312EB6CEOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jul 2019 05:43:03 -0000

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

SGkgV2VzLA0KDQpZb3VyIHN1Z2dlc3Rpb24gb24gcmVzZXJ2ZWQgYml0cyB3b3JrcyBmb3IgbWUu
IFRoYW5rcy4NCg0KQXMgd2UgYXJlIHRoZXJlIGFyZSwgSSBzdWdnZXN0IHRvIGFkZCBhIHNlY29u
ZCBhY3Rpb24gYXNraW5nIElBTkEgdG8gbW92ZSB0aGUgKG9ycGhhbikgVENQIGZsYWcgcmVnaXN0
cnkgdG8gYmUgYSBzdWItcmVnaXN0cnkgdW5kZXIgdGhlIGdsb2JhbCDigJxUcmFuc21pc3Npb24g
Q29udHJvbCBQcm90b2NvbCAoVENQKSBQYXJhbWV0ZXJz4oCdIChodHRwczovL3d3dy5pYW5hLm9y
Zy9hc3NpZ25tZW50cy90Y3AtcGFyYW1ldGVycy90Y3AtcGFyYW1ldGVycy54aHRtbCkuDQoNCkFs
c28sIGFkZCB0byB0aGUgZHJhZnQgYSByZW1pbmRlciB0aGF0IOKAnHJlc2VydmVkIGJpdHPigJ0g
YXJlIGFzc2lnbmVkIGZvbGxvd2luZyBTdGFuZGFyZCBBY3Rpb24gYXMgcGVyIFNlY3Rpb24gOS4y
IG9mIFJGQyAyNzgwLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiB0Y3BtIFttYWlsdG86dGNwbS1i
b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFdlc2xleSBFZGR5DQpFbnZvecOpIDogbWFy
ZGkgMzAganVpbGxldCAyMDE5IDE5OjU3DQrDgCA6IHRjcG0gSUVURiBsaXN0DQpPYmpldCA6IFt0
Y3BtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJm
Yzc5M2Jpcy0xNC50eHQNCg0KDQpIZWxsbywgdGhpcyBpbmNvcnBvcmF0ZXMgc29tZSBzbWFsbCBj
bGVhbnVwcyB0aGF0IGFjY3VtdWxhdGVkIHByaW9yIHRvIHRoZSBJRVRGIG1lZXRpbmcsIGFzIHdl
bGwgYXMgc29tZSBvZiB0aGUgZmVlZGJhY2sgcmVjZWl2ZWQgc2luY2UgdGhlbiBvbiB0aGUgbWFp
bGluZyBsaXN0Lg0KDQpBIGNvdXBsZSBzcGVjaWZpYyB0aGluZ3Mgbm90IHlldCBkb25lIChiZWNh
dXNlIGl0IGRvZXNuJ3QgbG9vayBsaWtlIHdlIGNvbnZlcmdlZCBvbiB0aGUgbGlzdCB5ZXQpOg0K
DQotIERpZCBub3QgeWV0IGNoYW5nZSByZXNlcnZlZCBiaXRzIHRvICJ1bmFzc2lnbmVkIiAobm9y
IGluZGljYXRlIHRoZW0gaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbikuICBSb2Qg
R3JpbWVzIGhhcyBhIGdvb2QgcG9pbnQgYWJvdXQgdGhlc2UgYmVpbmcgdmVyeSBjb21tb25seSBy
ZWZlcnJlZCB0byBhcyAidGhlIHJlc2VydmVkIGJpdHMiIGluIG90aGVyIHBsYWNlcy4gIEknbSB0
aGlua2luZyB3ZSBjb3VsZCBhZGQgYSBub3RlIHRvIHNheSB0aGF0IGluIElBTkEgdGVybXMgdGhl
eSdyZSAiVW5hc3NpZ25lZCIgdG8gYWRkIHRoZSBjbGFyaXR5IHRoYXQgTW9oYW1lZCBpcyBhZHZv
Y2F0aW5nLCBidXQgbm90IGNoYW5nZSB0aGUgbmFtZT8NCg0KLSBEaWQgbm90IHlldCBtb3ZlIHNl
Y3Rpb24gMi4xLg0KDQotIERpZCBub3QgeWV0IHJlbW92ZSB0aGUgbm90ZSBhYm91dCBteSBjb25m
dXNpb24gb24gTVVTVCB2cyBTSE9VTEQgcmVnYXJkaW5nIHJlcG9ydGluZyBvZiBleGNlc3NpdmUg
cmV0cmFuc21pc3Npb25zIGluIFJGQyAxMTIyICh3aWxsIGNvbmZpcm0gb24gdGhlIG1haWxpbmcg
bGlzdCB0aGUgIm5vIGNoYW5nZSIgcHJvcG9zYWwgdGhhdCB3YXMgc3VnZ2VzdGVkIGF0IHRoZSBt
ZWV0aW5nKQ0KDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0
Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNi
aXMtMTQudHh0DQoNCkRhdGU6DQoNClR1ZSwgMzAgSnVsIDIwMTkgMTA6NDc6MDggLTA3MDANCg0K
RnJvbToNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmc+DQoNClRvOg0KDQpXZXNsZXkgTS4gRWRkeSA8d2VzQG10aS1zeXN0ZW1zLmNvbT48
bWFpbHRvOndlc0BtdGktc3lzdGVtcy5jb20+LCBXZXNsZXkgRWRkeSA8d2VzQG10aS1zeXN0ZW1z
LmNvbT48bWFpbHRvOndlc0BtdGktc3lzdGVtcy5jb20+DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24g
b2YgSS1ELCBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0LnR4dA0KaGFzIGJlZW4gc3VjY2Vz
c2Z1bGx5IHN1Ym1pdHRlZCBieSBXZXNsZXkgTS4gRWRkeSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU
RiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzDQpSZXZpc2lv
bjogMTQNClRpdGxlOiBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCBTcGVjaWZpY2F0aW9u
DQpEb2N1bWVudCBkYXRlOiAyMDE5LTA3LTMwDQpHcm91cDogdGNwbQ0KUGFnZXM6IDEwNA0KVVJM
OiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi10Y3BtLXJm
Yzc5M2Jpcy0xNC50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy8NCkh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNA0KSHRtbGl6ZWQ6IGh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcw0K
RGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGNwbS1y
ZmM3OTNiaXMtMTQNCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgSW50
ZXJuZXQncyBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbA0KKFRDUCkuIFRDUCBpcyBhbiBp
bXBvcnRhbnQgdHJhbnNwb3J0IGxheWVyIHByb3RvY29sIGluIHRoZSBJbnRlcm5ldA0Kc3RhY2ss
IGFuZCBoYXMgY29udGludW91c2x5IGV2b2x2ZWQgb3ZlciBkZWNhZGVzIG9mIHVzZSBhbmQgZ3Jv
d3RoIG9mDQp0aGUgSW50ZXJuZXQuIE92ZXIgdGhpcyB0aW1lLCBhIG51bWJlciBvZiBjaGFuZ2Vz
IGhhdmUgYmVlbiBtYWRlIHRvDQpUQ1AgYXMgaXQgd2FzIHNwZWNpZmllZCBpbiBSRkMgNzkzLCB0
aG91Z2ggdGhlc2UgaGF2ZSBvbmx5IGJlZW4NCmRvY3VtZW50ZWQgaW4gYSBwaWVjZW1lYWwgZmFz
aGlvbi4gVGhpcyBkb2N1bWVudCBjb2xsZWN0cyBhbmQgYnJpbmdzDQp0aG9zZSBjaGFuZ2VzIHRv
Z2V0aGVyIHdpdGggdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gZnJvbSBSRkMgNzkzLg0KVGhp
cyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDc5MywgYXMgd2VsbCBhcyA4NzksIDI4NzMsIDYwOTMs
IDY0MjksDQo2NTI4LCBhbmQgNjY5MSB0aGF0IHVwZGF0ZWQgcGFydHMgb2YgUkZDIDc5My4gSXQg
dXBkYXRlcyBSRkMgMTEyMiwNCmFuZCBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyBhIHJlcGxhY2Vt
ZW50IGZvciB0aGUgcG9ydGlvbnMgb2YgdGhhdA0KZG9jdW1lbnQgZGVhbGluZyB3aXRoIFRDUCBy
ZXF1aXJlbWVudHMuIEl0IHVwZGF0ZXMgUkZDIDU5NjEgZHVlIHRvIGENCnNtYWxsIGNsYXJpZmlj
YXRpb24gaW4gcmVzZXQgaGFuZGxpbmcgd2hpbGUgaW4gdGhlIFNZTi1SRUNFSVZFRA0Kc3RhdGUu
DQoNClJGQyBFRElUT1IgTk9URTogSWYgYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJG
QywgdGhpcyBzaG91bGQNCmJlIG1hcmtlZCBhZGRpdGlvbmFsbHkgYXMgIlNURDogNyIgYW5kIHJl
cGxhY2UgUkZDIDc5MyBpbiB0aGF0IHJvbGUuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg
bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N
CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v
bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s
b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp
Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy
aWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn
cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h
cmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJ
bWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6
YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdl
aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVw
dCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBXZXMsDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3VyIHN1Z2dlc3Rpb24gb24gcmVzZXJ2ZWQgYml0
cyB3b3JrcyBmb3IgbWUuIFRoYW5rcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyB3ZSBhcmUgdGhlcmUgYXJlLCBJIHN1Z2dlc3QgdG8gYWRk
IGEgc2Vjb25kIGFjdGlvbiBhc2tpbmcgSUFOQSB0byBtb3ZlIHRoZSAob3JwaGFuKSBUQ1AgZmxh
ZyByZWdpc3RyeSB0byBiZSBhIHN1Yi1yZWdpc3RyeSB1bmRlciB0aGUgZ2xvYmFsIOKAnFRyYW5z
bWlzc2lvbg0KIENvbnRyb2wgUHJvdG9jb2wgKFRDUCkgUGFyYW1ldGVyc+KAnSAoPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdGNwLXBhcmFtZXRlcnMvdGNwLXBhcmFt
ZXRlcnMueGh0bWwiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1wYXJhbWV0
ZXJzL3RjcC1wYXJhbWV0ZXJzLnhodG1sPC9hPikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkFsc28sIGFkZCB0byB0aGUgZHJhZnQgYSByZW1pbmRl
ciB0aGF0IOKAnHJlc2VydmVkIGJpdHPigJ0gYXJlIGFzc2lnbmVkIGZvbGxvd2luZyBTdGFuZGFy
ZCBBY3Rpb24gYXMgcGVyIFNlY3Rpb24gOS4yIG9mIFJGQyAyNzgwLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi
bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y
OmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41
cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj
bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0Bp
ZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFdlc2xleSBFZGR5PGJyPg0KPGI+RW52b3nD
qSZuYnNwOzo8L2I+IG1hcmRpIDMwIGp1aWxsZXQgMjAxOSAxOTo1Nzxicj4NCjxiPsOAJm5ic3A7
OjwvYj4gdGNwbSBJRVRGIGxpc3Q8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFt0Y3BtXSBGd2Q6
IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0x
NC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5IZWxsbywgdGhpcyBpbmNvcnBvcmF0
ZXMgc29tZSBzbWFsbCBjbGVhbnVwcyB0aGF0IGFjY3VtdWxhdGVkIHByaW9yIHRvIHRoZSBJRVRG
IG1lZXRpbmcsIGFzIHdlbGwgYXMgc29tZSBvZiB0aGUgZmVlZGJhY2sgcmVjZWl2ZWQgc2luY2Ug
dGhlbiBvbiB0aGUgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHA+QSBjb3VwbGUgc3Bl
Y2lmaWMgdGhpbmdzIG5vdCB5ZXQgZG9uZSAoYmVjYXVzZSBpdCBkb2Vzbid0IGxvb2sgbGlrZSB3
ZSBjb252ZXJnZWQgb24gdGhlIGxpc3QgeWV0KTo8bzpwPjwvbzpwPjwvcD4NCjxwPi0gRGlkIG5v
dCB5ZXQgY2hhbmdlIHJlc2VydmVkIGJpdHMgdG8gJnF1b3Q7dW5hc3NpZ25lZCZxdW90OyAobm9y
IGluZGljYXRlIHRoZW0gaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbikuJm5ic3A7
IFJvZCBHcmltZXMgaGFzIGEgZ29vZCBwb2ludCBhYm91dCB0aGVzZSBiZWluZyB2ZXJ5IGNvbW1v
bmx5IHJlZmVycmVkIHRvIGFzICZxdW90O3RoZSByZXNlcnZlZCBiaXRzJnF1b3Q7IGluIG90aGVy
IHBsYWNlcy4mbmJzcDsgSSdtIHRoaW5raW5nIHdlIGNvdWxkIGFkZCBhIG5vdGUNCiB0byBzYXkg
dGhhdCBpbiBJQU5BIHRlcm1zIHRoZXkncmUgJnF1b3Q7VW5hc3NpZ25lZCZxdW90OyB0byBhZGQg
dGhlIGNsYXJpdHkgdGhhdCBNb2hhbWVkIGlzIGFkdm9jYXRpbmcsIGJ1dCBub3QgY2hhbmdlIHRo
ZSBuYW1lPzxvOnA+PC9vOnA+PC9wPg0KPHA+LSBEaWQgbm90IHlldCBtb3ZlIHNlY3Rpb24gMi4x
LjxvOnA+PC9vOnA+PC9wPg0KPHA+LSBEaWQgbm90IHlldCByZW1vdmUgdGhlIG5vdGUgYWJvdXQg
bXkgY29uZnVzaW9uIG9uIE1VU1QgdnMgU0hPVUxEIHJlZ2FyZGluZyByZXBvcnRpbmcgb2YgZXhj
ZXNzaXZlIHJldHJhbnNtaXNzaW9ucyBpbiBSRkMgMTEyMiAod2lsbCBjb25maXJtIG9uIHRoZSBt
YWlsaW5nIGxpc3QgdGhlICZxdW90O25vIGNoYW5nZSZxdW90OyBwcm9wb3NhbCB0aGF0IHdhcyBz
dWdnZXN0ZWQgYXQgdGhlIG1lZXRpbmcpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0t
LS0gPG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9
IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg
bm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdo
dCI+PGI+U3ViamVjdDogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk
ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV3IFZlcnNpb24g
Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0LnR4dDxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBz
dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp
Z249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPG86cD48L286cD48
L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VHVlLCAzMCBKdWwgMjAxOSAxMDo0NzowOCAtMDcwMDxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBz
dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp
Z249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RnJvbTogPG86cD48L286cD48
L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv
dHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20g
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i
dGV4dC1hbGlnbjpyaWdodCI+PGI+VG86IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQg
c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldl
c2xleSBNLiBFZGR5IDxhIGhyZWY9Im1haWx0bzp3ZXNAbXRpLXN5c3RlbXMuY29tIj4mbHQ7d2Vz
QG10aS1zeXN0ZW1zLmNvbSZndDs8L2E+LCBXZXNsZXkgRWRkeQ0KPGEgaHJlZj0ibWFpbHRvOndl
c0BtdGktc3lzdGVtcy5jb20iPiZsdDt3ZXNAbXRpLXN5c3RlbXMuY29tJmd0OzwvYT48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCkEg
bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0LnR4dDxicj4N
CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VzbGV5IE0uIEVkZHkgYW5kIHBv
c3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogZHJhZnQt
aWV0Zi10Y3BtLXJmYzc5M2Jpczxicj4NClJldmlzaW9uOiAxNDxicj4NClRpdGxlOiBUcmFuc21p
c3Npb24gQ29udHJvbCBQcm90b2NvbCBTcGVjaWZpY2F0aW9uPGJyPg0KRG9jdW1lbnQgZGF0ZTog
MjAxOS0wNy0zMDxicj4NCkdyb3VwOiB0Y3BtPGJyPg0KUGFnZXM6IDEwNDxicj4NClVSTDogPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGNw
bS1yZmM3OTNiaXMtMTQudHh0Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0LnR4dDwvYT48YnI+DQpTdGF0dXM6IDxhIGhy
ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGNwbS1yZmM3
OTNiaXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRjcG0t
cmZjNzkzYmlzLzwvYT48YnI+DQpIdG1saXplZDogPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQiPmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0PC9hPjxicj4NCkh0bWxpemVk
OiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll
dGYtdGNwbS1yZmM3OTNiaXMiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt
bC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzPC9hPjxicj4NCkRpZmY6IDxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10Y3BtLXJmYzc5
M2Jpcy0xNDwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQpUaGlzIGRvY3VtZW50IHNwZWNp
ZmllcyB0aGUgSW50ZXJuZXQncyBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbDxicj4NCihU
Q1ApLiBUQ1AgaXMgYW4gaW1wb3J0YW50IHRyYW5zcG9ydCBsYXllciBwcm90b2NvbCBpbiB0aGUg
SW50ZXJuZXQ8YnI+DQpzdGFjaywgYW5kIGhhcyBjb250aW51b3VzbHkgZXZvbHZlZCBvdmVyIGRl
Y2FkZXMgb2YgdXNlIGFuZCBncm93dGggb2Y8YnI+DQp0aGUgSW50ZXJuZXQuIE92ZXIgdGhpcyB0
aW1lLCBhIG51bWJlciBvZiBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHRvPGJyPg0KVENQIGFzIGl0
IHdhcyBzcGVjaWZpZWQgaW4gUkZDIDc5MywgdGhvdWdoIHRoZXNlIGhhdmUgb25seSBiZWVuPGJy
Pg0KZG9jdW1lbnRlZCBpbiBhIHBpZWNlbWVhbCBmYXNoaW9uLiBUaGlzIGRvY3VtZW50IGNvbGxl
Y3RzIGFuZCBicmluZ3M8YnI+DQp0aG9zZSBjaGFuZ2VzIHRvZ2V0aGVyIHdpdGggdGhlIHByb3Rv
Y29sIHNwZWNpZmljYXRpb24gZnJvbSBSRkMgNzkzLjxicj4NClRoaXMgZG9jdW1lbnQgb2Jzb2xl
dGVzIFJGQyA3OTMsIGFzIHdlbGwgYXMgODc5LCAyODczLCA2MDkzLCA2NDI5LDxicj4NCjY1Mjgs
IGFuZCA2NjkxIHRoYXQgdXBkYXRlZCBwYXJ0cyBvZiBSRkMgNzkzLiBJdCB1cGRhdGVzIFJGQyAx
MTIyLDxicj4NCmFuZCBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyBhIHJlcGxhY2VtZW50IGZvciB0
aGUgcG9ydGlvbnMgb2YgdGhhdDxicj4NCmRvY3VtZW50IGRlYWxpbmcgd2l0aCBUQ1AgcmVxdWly
ZW1lbnRzLiBJdCB1cGRhdGVzIFJGQyA1OTYxIGR1ZSB0byBhPGJyPg0Kc21hbGwgY2xhcmlmaWNh
dGlvbiBpbiByZXNldCBoYW5kbGluZyB3aGlsZSBpbiB0aGUgU1lOLVJFQ0VJVkVEPGJyPg0Kc3Rh
dGUuPGJyPg0KPGJyPg0KUkZDIEVESVRPUiBOT1RFOiBJZiBhcHByb3ZlZCBmb3IgcHVibGljYXRp
b24gYXMgYW4gUkZDLCB0aGlzIHNob3VsZDxicj4NCmJlIG1hcmtlZCBhZGRpdGlvbmFsbHkgYXMg
JnF1b3Q7U1REOiA3JnF1b3Q7IGFuZCByZXBsYWNlIFJGQyA3OTMgaW4gdGhhdCByb2xlLjxicj4N
Cjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj
b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0
aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu
b3JnLjxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_787AE7BB302AE849A7480A190F8B9330312EB6CEOPEXCAUBMA2corp_--


From nobody Tue Jul 30 23:27: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 24F7F120045 for ; Tue, 30 Jul 2019 23:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 x-5H68F8eoLe for ; Tue, 30 Jul 2019 23:26:56 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B99120047 for ; Tue, 30 Jul 2019 23:26:56 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45z3Nt3fmFz1yTK; Wed, 31 Jul 2019 08:26:54 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 45z3Nn3Yn9z1xpd; Wed, 31 Jul 2019 08:26:49 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 08:26:49 +0200
From: 
To: Wesley Eddy , "tcpm@ietf.org" 
Thread-Topic: draft-ietf-tcpm-rfc793bis-14: options
Thread-Index: AdVHaOyfFT4y52/eSTyZVP4emuLd+g==
Date: Wed, 31 Jul 2019 06:26:48 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jul 2019 06:26:58 -0000

Hi Wes,=20

Below some comments about the options as described in Section 3.1:=20

* Consider adding some text to ACK the TCP option space problem. Adding a p=
ointer to EDO as * an example * (without recommending it) of how to extend =
the space for non-SYNs would be useful.
* Add an explicit statement about 253/254 as being reserved for experiments=
 with a strong recommendation to make use of shared ExIDs.=20
* What about obsoleting (?) 6994 and incorporating its main contribution as=
 part of 793bis?

Cheers,
Med

> -----Message d'origine-----
> De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de
> internet-drafts@ietf.org
> Envoy=E9=A0: mardi 30 juillet 2019 19:47
> =C0=A0: i-d-announce@ietf.org
> Cc=A0: tcpm@ietf.org
> Objet=A0: I-D Action: draft-ietf-tcpm-rfc793bis-14.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           : Transmission Control Protocol Specification
>         Author          : Wesley M. Eddy
> 	Filename        : draft-ietf-tcpm-rfc793bis-14.txt
> 	Pages           : 104
> 	Date            : 2019-07-30
>=20
> Abstract:
>    This document specifies the Internet's Transmission Control Protocol
>    (TCP).  TCP is an important transport layer protocol in the Internet
>    stack, and has continuously evolved over decades of use and growth of
>    the Internet.  Over this time, a number of changes have been made to
>    TCP as it was specified in RFC 793, though these have only been
>    documented in a piecemeal fashion.  This document collects and brings
>    those changes together with the protocol specification from RFC 793.
>    This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
>    6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
>    and should be considered as a replacement for the portions of that
>    document dealing with TCP requirements.  It updates RFC 5961 due to a
>    small clarification in reset handling while in the SYN-RECEIVED
>    state.
>=20
>    RFC EDITOR NOTE: If approved for publication as an RFC, this should
>    be marked additionally as "STD: 7" and replace RFC 793 in that role.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-14
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-14
>=20
>=20
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Tue Jul 30 23:58: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 71308120052 for ; Tue, 30 Jul 2019 23:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gGqS5uo6jk4P for ; Tue, 30 Jul 2019 23:58:34 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 A6E3312001B for ; Tue, 30 Jul 2019 23:58:33 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45z45M6wKkz1010; Wed, 31 Jul 2019 08:58:31 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 45z45M6FQYzDq85; Wed, 31 Jul 2019 08:58:31 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 08:58:31 +0200
From: 
To: Wesley Eddy , "tcpm@ietf.org" 
Thread-Topic: draft-ietf-tcpm-rfc793bis-14: Section 3.4
Thread-Index: AdVHbVmgxKjaWGDtTrKw8iUTgk+X9A==
Date: Wed, 31 Jul 2019 06:58:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312EB757@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] draft-ietf-tcpm-rfc793bis-14: Section 3.4
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 31 Jul 2019 06:58:37 -0000

Re-,

Can we update this text as follows:=20

OLD:

   Several examples of connection initiation follow.  Although these
   examples do not show connection synchronization using data-carrying
   segments, this is perfectly legitimate, so long as the receiving TCP
   doesn't deliver the data to the user until it is clear the data is
   valid (i.e., the data must be buffered at the receiver until the
          ^^^^           ^^^^^^^
   connection reaches the ESTABLISHED state).  The three-way handshake
                                           ^^^^
   reduces the possibility of false connections.  It is the
   implementation of a trade-off between memory and messages to provide
   information for this checking.

NEW:

   Several examples of connection initiation follow.  Although these
   examples do not show connection synchronization using data-carrying
   segments, this is perfectly legitimate, so long as the receiving TCP
   doesn't deliver the data to the user until it is clear the data is
   valid (e.g., the data is buffered at the receiver until the
          ^^^^           ^^
   connection reaches the ESTABLISHED state given that the three-way handsh=
ake
                                            ^^^^^^^^^^^^
   reduces the possibility of false connections).  It is the
   implementation of a trade-off between memory and messages to provide
   information for this checking.


Rationale:=20
* The key requirement is: "doesn't deliver the data to the user until it is=
 clear the data is valid". This one is maintained as it is.=20
* Waiting for the 3HWS completion is only an example to fulfil the above re=
quirement.
* Allow for future 0-RTT validation methods without requiring an update to =
RFC793bis: For example, if TFO is promoted to Standard track, there won't b=
e a need to update RFC793bis.

Cheers,
Med

> -----Message d'origine-----
> De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de
> internet-drafts@ietf.org
> Envoy=E9=A0: mardi 30 juillet 2019 19:47
> =C0=A0: i-d-announce@ietf.org
> Cc=A0: tcpm@ietf.org
> Objet=A0: I-D Action: draft-ietf-tcpm-rfc793bis-14.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           : Transmission Control Protocol Specification
>         Author          : Wesley M. Eddy
> 	Filename        : draft-ietf-tcpm-rfc793bis-14.txt
> 	Pages           : 104
> 	Date            : 2019-07-30
>=20
> Abstract:
>    This document specifies the Internet's Transmission Control Protocol
>    (TCP).  TCP is an important transport layer protocol in the Internet
>    stack, and has continuously evolved over decades of use and growth of
>    the Internet.  Over this time, a number of changes have been made to
>    TCP as it was specified in RFC 793, though these have only been
>    documented in a piecemeal fashion.  This document collects and brings
>    those changes together with the protocol specification from RFC 793.
>    This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
>    6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
>    and should be considered as a replacement for the portions of that
>    document dealing with TCP requirements.  It updates RFC 5961 due to a
>    small clarification in reset handling while in the SYN-RECEIVED
>    state.
>=20
>    RFC EDITOR NOTE: If approved for publication as an RFC, this should
>    be marked additionally as "STD: 7" and replace RFC 793 in that role.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-14
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-14
>=20
>=20
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Wed Jul 31 03:26:30 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3131A12008C; Wed, 31 Jul 2019 03:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTx_8wi1drLN; Wed, 31 Jul 2019 03:26:25 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B302A12009C; Wed, 31 Jul 2019 03:26:24 -0700 (PDT)
Received: from tpw09926dag03e.domain1.systemhost.net (10.9.202.18) by RDW083A011ED67.bt.com (10.187.98.37) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 31 Jul 2019 11:31:42 +0100
Received: from tpw09926dag08h.domain1.systemhost.net (10.9.202.47) by tpw09926dag03e.domain1.systemhost.net (10.9.202.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 31 Jul 2019 11:26:19 +0100
Received: from RDW083A011ED67.bt.com (10.187.98.37) by tpw09926dag08h.domain1.systemhost.net (10.9.202.47) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 31 Jul 2019 11:26:19 +0100
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.53) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 31 Jul 2019 11:31:38 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S279nKvLHvLg+ENfDy6RdHACiA5fX9Y6fZTlr8hISmG/4BGXrUaXGZHKMJCsVvUxwr/ZWW+7/w3ykS/piiImE2eiHpFTTM91Nx3u9OHMbnZFMWIYK/A6W2cWvKwzG4vmlmwxS6Z+o63yLr3oSbNRUAezjGN6LfnbG+uz/W/JNr90oXuqMPz6c/wM4/6B8zP04tLquFUKo2dpGuSxkdxiYUP0WMDFYr3s/PwbaoSNyqHl9bdLGy7NyeQdKNH4KUolT4PU3VUSmy8ymYc1obCKTDmyOtvO/IIQ59KrSGd/iUl2IsWCkDI9SX5Eu82sZzStG7orJ/8ke5b+v6H3NnaW7w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iMtyJAO87o2XIDRHCbQ5fNZjWSz+orI//dxzjRUqOxo=; b=h5cSONCGzin04I9hm4Q1jWjCsAOpxz5G3Sq2IcHNvi+kG4zXRIjYFVraGHqHE2PpiPkAaYQHOyC7vAEke1JxKyhuQzjvKdK7ws2cfm5EGSBZTobOIv6AKMQjv7+WZwYn9U9HHm4vC8b8I532+IYEYkPyenYOqO5ZEPm2/y+6XtU1WmHjcxsrcJSGiQhbLQ3O0hzDkhEkg0W1MCdVTkev7vk1RdzKcOor7pxnsG07guSxNHTGxFAxCRhOg2MfslQkmbk2cU2Hxv47Yq7QI8A7RaOlaKyna3kpHtdHpQZDBgr03kBFmDBe73LHkKXJRrXIPDf1CpIhV9juH4v2bHNxRA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=bt.com;dmarc=pass action=none header.from=bt.com;dkim=pass header.d=bt.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iMtyJAO87o2XIDRHCbQ5fNZjWSz+orI//dxzjRUqOxo=; b=M7LrBltg63/j7jzcPTmf4gGyraOfHskzfgSUKHLe/yd/plGH3icV2z4Q+gvATLGiadPlrzhs8+oKb4CGbbB5OxBQrxLExQJAaJNVBUu+tl2Vm0awQETrsy0PscgV8Q7n/2vm8LO2IKlCaHsM+SE8JqOM8UgNDQDPdeadujVZ/PE=
Received: from CWXP123MB2583.GBRP123.PROD.OUTLOOK.COM (20.179.111.81) by CWXP123MB2661.GBRP123.PROD.OUTLOOK.COM (20.176.63.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Wed, 31 Jul 2019 10:26:16 +0000
Received: from CWXP123MB2583.GBRP123.PROD.OUTLOOK.COM ([fe80::cd8c:2aaf:b63b:3dcd]) by CWXP123MB2583.GBRP123.PROD.OUTLOOK.COM ([fe80::cd8c:2aaf:b63b:3dcd%3]) with mapi id 15.20.2115.005; Wed, 31 Jul 2019 10:26:16 +0000
From: 
To: , 
CC: 
Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09?
Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQ
Date: Wed, 31 Jul 2019 10:26:16 +0000
Message-ID: 
References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; 
x-originating-ip: [193.113.37.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dbd594fc-12d6-48a5-7e80-08d715a18560
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CWXP123MB2661; 
x-ms-traffictypediagnostic: CWXP123MB2661:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-antispam-2: 1
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 011579F31F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(39860400002)(346002)(199004)(189003)(13464003)(4326008)(476003)(6436002)(74316002)(25786009)(66066001)(6506007)(229853002)(53546011)(102836004)(26005)(11346002)(316002)(7736002)(71190400001)(71200400001)(446003)(256004)(486006)(14444005)(305945005)(86362001)(33656002)(66556008)(64756008)(66446008)(76176011)(8936002)(66946007)(8676002)(81166006)(76116006)(81156014)(478600001)(9686003)(6116002)(110136005)(6246003)(99286004)(66476007)(186003)(3846002)(14454004)(53936002)(5660300002)(66574012)(966005)(7696005)(52536014)(6306002)(55016002)(2501003)(68736007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:CWXP123MB2661; H:CWXP123MB2583.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Q3i3hs2s6jF8RLYZnFMAUuUVf8yJ8v3bofdR1oUNVn2EciqP1gDX3X4O6CkfboDhFQ6OACQOULBgi/ErfGTTo1UgFG97+8krPLwbp1VSRw101X6pU8lFo3etjLkeZucnYX7iWO8GRGNxy7Un10a60gubIc6CEw7bmlCbp6vGTYEFLODzL9xyZSRhMKSXzOHKf6eczFMCXeUxwZ5nhO4ao9AOjf5jtizQCoyhlQfX5VFFcUZHq0W/A2IdhBVk8mTeSE9vj/ov43d0A2jGFcfmrUeiUU6Id4VESXfgBHcI9JAeqLwZU5KFiwBQ1SdvUquSLPq/2Oxk819QRMuPmeFiUNy0pdFvo/7HZLwtbFyZCjBPkEflWD1lDeQD8T1VRasNTmeO5us/bd2MNUiuYX9eyKfAQA4HQ57ON0sTwJMY2Kw=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dbd594fc-12d6-48a5-7e80-08d715a18560
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 10:26:16.4707 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP123MB2661
X-OriginatorOrg: bt.com
Archived-At: 
Subject: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jul 2019 10:26:28 -0000

I think most of my comments are addressed. Here are some things I think cou=
ld still be clarified, plus a couple of extra questions that occurred to me=
 when I was checking the latest version.

Section 3.1
<>

This sentence seems to contradict itself (can something be both assumed and=
 have to be explicitly stated?). Maybe:-
In general this document assumes that the client initiates the connection (=
in other words, it is an outgoing connection); the scenario with an incomin=
g connection is discussed in a couple of places [references].=20

In Figure 1 I find the 'upstream' and 'downstream' labels a bit confusing (=
especially as the lines have arrowheads in both directions), and it is show=
n as the link between client and converter etc. I think it would be better =
to move lower down (ie separate from the actual link), something like:
-------> upstream direction (outgoing connections)
<------ downstream direction (incoming connections)

Figure 5 caption has a stray "(1)" that can be deleted

Above Figure 6
<>

Some comments:
The Client also listens on TCP port TBA (not just the converter)
Stress that ALL convert msgs start with the same header.
I think the "Clients send packets..." para is better re-arranged.

Question: there seems to be a contradiction. The text here says "Convert me=
ssages may appear only in syn, syn-ack, ack". But then in S3.2 it says "Thi=
s information is sent at the beginning of the bytestream, either directly i=
n the SYN+ACK or in a subsequent packet." (this information is "about the T=
CP options that were negotiated with the Server.") (Incidentally, in S3.2 e=
ssentially the same sentence is repeated two sentences later.)  is the idea=
 that SYN / syn-ack /ack is the 'normal' case, but can be in later pkts?

Question: the text says "Clients send packets that are eligible to the conv=
ersion service to the provisioned Transport Converter using TBA as destinat=
ion port number." Is this referring to the exchange of Convert protocol mes=
sages? Or is this referring to subsequent data that is actually sent to the=
 TBA port number? I think the text implies the latter, which I assume is no=
t correct.=20


Suggested text:-

<<
   This section defines the Convert protocol (Convert, for short) messages =
that are exchanged between a Client and a Transport Converter.

   Convert messages MUST be sent to TCP destination port TBA. Therefore, a =
Transport Converter and a Client listen on this TCP port for Convert messag=
es.
   Convert messages MAY appear in a SYN, SYN+ACK, or ACK or MAY appear in a=
 subsequent packet.
Convert messages MUST be included as the first bytes of the bytestream. =20
All Convert messages start with a common 32 bits long header (Section 4.1),=
 followed by one or more Convert TLVs (Type, Length, Value) (Section 4.2).
After a successful exchange of Convert messages, a TCP connection with TCP =
extension(s) is established between the Client and Transport Converter (for=
 instance, Multipath TCP), and a (normal) TCP connection is established bet=
ween the Transport Converter and other end host, with the Transport Convert=
er acting as an explicit proxy between the two connections (for instance, b=
etween MPTCP and TCP). =20
>>


Section 4.0, 4.2.6 etc
Various places say things like "the Unassigned field MUST be set to zero by=
 the transmitter and
   ignored by the receiver.  These bits are available for future use
   [RFC8126]."
Comment: I heard in ietf-105 about problems for extensibility of various pr=
otocols because implementations insist on all zeroes for fields, otherwise =
discard packets. The suggestion is to grease (which I think means that the =
senders set to random values and receivers MUST ignore)
Also, 'sender' rather than 'transmitter'

Figure 11
In the figure you have Value being optional in bits 16-31 and compulsory in=
 bits 32+. I think this should be the other way round.=20

Section 4.2.8
"This TLV has a variable length.  It appears after the Convert fixed-
   header in the bytestream returned by the Transport Converter."
Figure 19 doesn't show variable length. Must its length be a multiple of 32=
 bytes (padded if needed)? (I assume so, to be consistent with elsewhere.)
The second sentence could be deleted, since elsewhere text says the TLV(s) =
must be at the start of the bytestream. But if you keep the sentence I sugg=
est you say "appears _immediately_ after"=20

S6
"The case of a middlebox that removes the payload of SYN+ACKs (but the =20
       payload of SYN) can be detected by a Client."
Do you mean: but _not_ the payload of SYN?

<>
It would be really nice if somehow the material here that explains the desi=
gn rationale, and development from earlier approaches, could be kept. It's =
useful info, I think.=20

Best wishes,
phil

-----Original Message-----
From: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de]=20
Sent: 22 July 2019 09:01
To: Eardley,PL,Philip,TUD1 R 
Cc: tcpm-chairs@ietf.org
Subject: WGLC comments addressed in draft-ietf-tcpm-converters-09?

Hi Phil,

Could you please have a look at -09 and let me know if your WGLC comments a=
re addressed?

If not, please follow-up on the mailing list.

Thanks

Michael

-----Original Message-----
From: tcpm  On Behalf Of internet-drafts@ietf.org
Sent: Monday, July 22, 2019 8:04 AM
To: i-d-announce@ietf.org
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
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-09.txt
	Pages           : 47
	Date            : 2019-07-21

Abstract:
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP extensions such as
   Multipath TCP.  This proxy is designed to avoid inducing extra delay
   when involved in a network-assisted connection (that is, 0-RTT).

   This specification assumes an explicit model, where the proxy is
   explicitly configured on hosts.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-09


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

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

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


From nobody Wed Jul 31 05:22: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 62DBC12016C; Wed, 31 Jul 2019 05:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 njzb9-CyjyS5; Wed, 31 Jul 2019 05:22:02 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 0237F120153; Wed, 31 Jul 2019 05:22:02 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 45zCGc32R4zBs7R; Wed, 31 Jul 2019 14:22:00 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 45zCGc1gbGzCqkd; Wed, 31 Jul 2019 14:22:00 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 14:22:00 +0200
From: 
To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" 
CC: "tcpm-chairs@ietf.org" 
Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09?
Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llA=
Date: Wed, 31 Jul 2019 12:21:59 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> 
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jul 2019 12:22:06 -0000

Hi Phil,=20

Thank you for double checking.=20

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de
> philip.eardley@bt.com
> Envoy=E9=A0: mercredi 31 juillet 2019 12:26
> =C0=A0: Michael.Scharf@hs-esslingen.de; tcpm@ietf.org
> Cc=A0: tcpm-chairs@ietf.org
> Objet=A0: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converter=
s-
> 09?
>=20
> I think most of my comments are addressed. Here are some things I think
> could still be clarified, plus a couple of extra questions that occurred
> to me when I was checking the latest version.
>=20
> Section 3.1
> < assumes outgoing connections as default.>>
>=20
> This sentence seems to contradict itself (can something be both assumed
> and have to be explicitly stated?).

[Med] Yes. Consider for example the following text:

   "By default, the Transport Converter listens on TCP port number TBA
   for Convert protocol (Convert, for short) messages from Clients.

   Clients send packets that are eligible to the conversion service to
   the provisioned Transport Converter using TBA as destination port
   number.  Additional information is supplied by Clients to the
   Transport Converter by means of Convert messages as detailed in the
   following sub-sections."

It applies only for the outgoing connections.=20

 Maybe:-
> In general this document assumes that the client initiates the connection
> (in other words, it is an outgoing connection); the scenario with an
> incoming connection is discussed in a couple of places [references].

[Med] I can use this wording if you think it is better. =20

>=20
> In Figure 1 I find the 'upstream' and 'downstream' labels a bit confusing
> (especially as the lines have arrowheads in both directions), and it is
> shown as the link between client and converter etc. I think it would be
> better to move lower down (ie separate from the actual link), something
> like:
> -------> upstream direction (outgoing connections)
> <------ downstream direction (incoming connections)
>=20

[Med] Actually, upsteram and downstream are defined as follows:=20

   o  the upstream connection is the one between the Client and the
      Transport Converter.

   o  the downstream connection is between the Transport Converter and
      the Server.

This is independent of the connection direction.=20

> Figure 5 caption has a stray "(1)" that can be deleted

[Med] Fixed.

>=20
> Above Figure 6
> < I think ", eventually," should be deleted.
>=20
>=20

[Med] "eventually" is justified: cover the case of a converter configured i=
n an address preservation mode (e.g., IPv6). The destination IP address won=
't be rewritten in such case.  =20


> Section 3.2 / 3.3
> There are two paragraphs at the end of 3.2 and a bit more in 3.3
> discussing what happens when a connection ends with FIN and TCP RST etc. =
I
> think you should write a bit more about the MPTCP case - since there are
> subflow TCP RST and MP_FASTCLOSE cases to consider. A TCP RST on one MPTC=
P
> subflow presumably shouldn't trigger the Converter to close the TCP
> connection on its other interface.

[Med] Section 3.2 covers the generic TCP case. Hence, there is no need to d=
iscuss MPTCP specifics in that section.=20

I guess you are referring to this text in Section 3.3:=20

   Note that, if the TCP connection fails for some reason, the Converter
   tears down the Multipath TCP connection by transmitting a
   MP_FASTCLOSE.  Likewise, if the Multipath TCP connection ends with
   the transmission of DATA_FINs, the Converter terminates the TCP
   connection by using FIN segments.=20

The text covers exclusively the cases that lead to the termination of the u=
pstream/downstream connection.=20

Given that MPTCP spec says:=20

   "With MPTCP, the RST only has the scope of the
   subflow and will only close the concerned subflow but not affect the
   remaining subflows.  MPTCP's connection will stay alive at the data
   level, in order to permit break-before-make handover between
   subflows."

the subflow RST is not covered (as it does not terminate the MPTCP leg).=20

>=20
> Section 4 intro
>=20
> << This section describes the messages that are exchanged between a
>    Client and a Transport Converter.
>=20
>    By default, the Transport Converter listens on TCP port number TBA
>    for Convert protocol (Convert, for short) messages from Clients.
>=20
>    Clients send packets that are eligible to the conversion service to
>    the provisioned Transport Converter using TBA as destination port
>    number.  Additional information is supplied by Clients to the
>    Transport Converter by means of Convert messages as detailed in the
>    following sub-sections.
>=20
>    Convert messages may appear only in a SYN, SYN+ACK, or ACK.
>=20
>    Convert messages MUST be included as the first bytes of the
>    bytestream.  A Convert message starts with a 32 bits long fixed
>    header (Section 4.1) followed by one or more Convert TLVs (Type,
>    Length, Value) (Section 4.2).
> >>
>=20
> Some comments:
> The Client also listens on TCP port TBA (not just the converter)

[Med] The client will listen on the internal port number that it indicated =
when creating a mapping in the converter to allow for incoming connections.=
 This is needed to demux services hosted on the same client.=20

This is covered in this text:=20

   The Converter accepts the request by creating a TCP
   mapping (internal IP address, internal port number, external IP
   address, external port number).  The external IP address and external
   port number will be then advertised using an out-of-band mechanism so
   that remote hosts can initiate TCP connections to the Client via the
   Converter.  Note that the external and internal information may be
   the same.=20

> Stress that ALL convert msgs start with the same header.
> I think the "Clients send packets..." para is better re-arranged.
>=20
> Question: there seems to be a contradiction. The text here says "Convert
> messages may appear only in syn, syn-ack, ack". But then in S3.2 it says
> "This information is sent at the beginning of the bytestream, either
> directly in the SYN+ACK or in a subsequent packet." (this information is
> "about the TCP options that were negotiated with the Server.")
> (Incidentally, in S3.2 essentially the same sentence is repeated two
> sentences later.)  is the idea that SYN / syn-ack /ack is the 'normal'
> case, but can be in later pkts?

[Med] Good catch.=20

OLD:
   The Client sends a SYN destined to the Transport Converter.  The
   payload of this SYN contains the address and port number of the
   Server.  The Transport Converter does not reply immediately to this
   SYN.  It first tries to create a TCP connection towards the target
   Server.  If this upstream connection succeeds, the Transport
   Converter confirms the establishment of the connection to the Client
   by returning a SYN+ACK and the first bytes of the bytestream contain
   information about the TCP options that were negotiated with the
   Server.  This information is sent at the beginning of the bytestream,
   either directly in the SYN+ACK or in a subsequent packet.  For
   graphical reasons, the figures in this section show that the
   Transport Converter returns this information in the SYN+ACK packet.
   An implementation could also place this information in a packet that
   it sent shortly after the SYN+ACK.

NEW:
   The Client sends a SYN destined to the Transport Converter.  The
   payload of this SYN contains the address and port number of the
   Server.  The Transport Converter does not reply immediately to this
   SYN.  It first tries to create a TCP connection towards the target
   Server.  If this upstream connection succeeds, the Transport
   Converter confirms the establishment of the connection to the Client
   by returning a SYN+ACK and the first bytes of the bytestream contain
   information about the TCP options that were negotiated with the
   Server. =20


>=20
> Question: the text says "Clients send packets that are eligible to the
> conversion service to the provisioned Transport Converter using TBA as
> destination port number." Is this referring to the exchange of Convert
> protocol messages? Or is this referring to subsequent data that is
> actually sent to the TBA port number? I think the text implies the latter=
,
> which I assume is not correct.

[Med] This applies to all messages that cross the converter.=20

>=20
>=20
> Suggested text:-
>=20
> <<
>    This section defines the Convert protocol (Convert, for short) message=
s
> that are exchanged between a Client and a Transport Converter.
>=20
>    Convert messages MUST be sent to TCP destination port TBA. Therefore, =
a
> Transport Converter and a Client listen on this TCP port for Convert
> messages.

[Med] The initial wording is correct.=20

>    Convert messages MAY appear in a SYN, SYN+ACK, or ACK or MAY appear in
> a subsequent packet.

[Med] The initial wording is correct.=20

> Convert messages MUST be included as the first bytes of the bytestream.
> All Convert messages start with a common 32 bits long header (Section
> 4.1), followed by one or more Convert TLVs (Type, Length, Value) (Section
> 4.2).
> After a successful exchange of Convert messages, a TCP connection with TC=
P
> extension(s) is established between the Client and Transport Converter
> (for instance, Multipath TCP), and a (normal) TCP connection is
> established between the Transport Converter and other end host, with the
> Transport Converter acting as an explicit proxy between the two
> connections (for instance, between MPTCP and TCP).

[Med] No problem (even if the last sentence is already stated in previous s=
ections).=20

> >>
>=20
>=20
> Section 4.0, 4.2.6 etc
> Various places say things like "the Unassigned field MUST be set to zero
> by the transmitter and
>    ignored by the receiver.  These bits are available for future use
>    [RFC8126]."
> Comment: I heard in ietf-105 about problems for extensibility of various
> protocols because implementations insist on all zeroes for fields,
> otherwise discard packets. The suggestion is to grease (which I think
> means that the senders set to random values and receivers MUST ignore)

[Med] I don't see the value for doing this.  =20

> Also, 'sender' rather than 'transmitter'

[Med] Fixed. Thanks.=20

>=20
> Figure 11
> In the figure you have Value being optional in bits 16-31 and compulsory
> in bits 32+. I think this should be the other way round.

[Med] OK.

>=20
> Section 4.2.8
> "This TLV has a variable length.  It appears after the Convert fixed-
>    header in the bytestream returned by the Transport Converter."
> Figure 19 doesn't show variable length. Must its length be a multiple of
> 32 bytes (padded if needed)? (I assume so, to be consistent with
> elsewhere.)

[Med] Agree. Fixed the figure.=20

Padding is mentioned in the error description (when appropriate), e.g.,:=20

     "The
      list of unsupported TCP options MUST be padded with zeros to end
      on a 32 bits boundary. "

> The second sentence could be deleted, since elsewhere text says the TLV(s=
)
> must be at the start of the bytestream. But if you keep the sentence I
> suggest you say "appears _immediately_ after"
>=20

[Med] Deleted that sentence. No need to be redundant.=20

> S6
> "The case of a middlebox that removes the payload of SYN+ACKs (but the
>        payload of SYN) can be detected by a Client."
> Do you mean: but _not_ the payload of SYN?

[Med] Yes.=20

>=20
> <    This section to be removed before publication.>>
> It would be really nice if somehow the material here that explains the
> design rationale, and development from earlier approaches, could be kept.
> It's useful info, I think.

[Med] OK, added a new appendix to cover the key points.=20

>=20
> Best wishes,
> phil
>=20
> -----Original Message-----
> From: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de]
> Sent: 22 July 2019 09:01
> To: Eardley,PL,Philip,TUD1 R 
> Cc: tcpm-chairs@ietf.org
> Subject: WGLC comments addressed in draft-ietf-tcpm-converters-09?
>=20
> Hi Phil,
>=20
> Could you please have a look at -09 and let me know if your WGLC comments
> are addressed?
>=20
> If not, please follow-up on the mailing list.
>=20
> Thanks
>=20
> Michael
>=20
> -----Original Message-----
> From: tcpm  On Behalf Of internet-drafts@ietf.org
> Sent: Monday, July 22, 2019 8:04 AM
> To: i-d-announce@ietf.org
> Cc: tcpm@ietf.org
> Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-09.txt
>=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-09.txt
> 	Pages           : 47
> 	Date            : 2019-07-21
>=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
>=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-09
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-09
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-09
>=20
>=20
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Wed Jul 31 11:51: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 4FA8E12004F for ; Wed, 31 Jul 2019 11:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level: 
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwBiYLDEHzPo for ; Wed, 31 Jul 2019 11:51:02 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CE2120018 for ; Wed, 31 Jul 2019 11:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=+JyMLKmLbYmY3vhoYerNZPsCKjW5sXpqal2dc0UXyug=; b=FtBwW/nbc3IuUhimNsrzHNNW8 qvZ3cBmucDHS0/Z//m24meupBMojvKDKR/8rScRPCilWXo+zFtxJZtGyxAE0egduQImH0g8ySdJxe lBQJUmnx0tR9ADW+m8s0rmxYonJD08bMhcYf64MJD07R+RYwh1U9+BVSTAHUAZzXnrOdq27lm98LO KSCVsbdinZyNnLtkJkAgdvdt8fdA29rUHZo05xCz6msp+816u4/Ck+dolnmhNJZAm417YIMT/XLmh h+VN3nS9vx8iju6gdPVBvU7UDd17YFRVPpxTOJAEhD6xLl7hsbRVGSiLamgFpFxc2bkPI6WNPhoTn d/NGEIJQw==;
Received: from [::1] (port=39858 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1hstge-000e0k-H6; Wed, 31 Jul 2019 14:51:01 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_957b846743aead2908a0260c8cf33f40"
Date: Wed, 31 Jul 2019 11:50:56 -0700
From: Joe Touch 
To: mohamed.boucadair@orange.com
Cc: Wesley Eddy , tcpm@ietf.org
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Message-ID: 
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jul 2019 18:51:04 -0000

--=_957b846743aead2908a0260c8cf33f40
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

Based on the defined scope and approach of 793bis, as stated in its
intro: 

On 2019-07-30 23:26, mohamed.boucadair@orange.com wrote:

> Hi Wes, 
> 
> Below some comments about the options as described in Section 3.1: 
> 
> * Consider adding some text to ACK the TCP option space problem. Adding a pointer to EDO as * an example * (without recommending it) of how to extend the space for non-SYNs would be useful.

It would be useful to mention the ongoing work, but not to try to repeat
it. 

> * Add an explicit statement about 253/254 as being reserved for experiments with a strong recommendation to make use of shared ExIDs.

It would be useful to note their being assigned for that purpose (not
quite RESERVED) and to ref 6994 for further details. 

Given the focus of this updated is standards-track, it would be useful
to remind developers not to deploy options using those codepoints
outside carefully controlled experiments and that they are default to
being not enabled in any code not under direct control of the
developers. 

However... 

> * What about obsoleting (?) 6994 and incorporating its main contribution as part of 793bis?

I disagree. First, 6994 is not being obsoleted per se; second, others
refer to its approach for other similar experimental fields. It would be
a bad idea to try to "obsolete" it. 

I also don't think it's useful to include these details inside 793bis -
these are not details needed for standards-compliant operation (esp.
because they shouldn't be used for final standards-track options). 

IMO, 6994 is a lot like congestion control; OK, if not better, as a
separate doc. 

Joe 

> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de
>> internet-drafts@ietf.org
>> Envoyé : mardi 30 juillet 2019 19:47
>> À : i-d-announce@ietf.org
>> Cc : tcpm@ietf.org
>> Objet : I-D Action: draft-ietf-tcpm-rfc793bis-14.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the TCP Maintenance and Minor Extensions WG
>> of the IETF.
>> 
>> Title           : Transmission Control Protocol Specification
>> Author          : Wesley M. Eddy
>> Filename        : draft-ietf-tcpm-rfc793bis-14.txt
>> Pages           : 104
>> Date            : 2019-07-30
>> 
>> Abstract:
>> This document specifies the Internet's Transmission Control Protocol
>> (TCP).  TCP is an important transport layer protocol in the Internet
>> stack, and has continuously evolved over decades of use and growth of
>> the Internet.  Over this time, a number of changes have been made to
>> TCP as it was specified in RFC 793, though these have only been
>> documented in a piecemeal fashion.  This document collects and brings
>> those changes together with the protocol specification from RFC 793.
>> This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
>> 6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
>> and should be considered as a replacement for the portions of that
>> document dealing with TCP requirements.  It updates RFC 5961 due to a
>> small clarification in reset handling while in the SYN-RECEIVED
>> state.
>> 
>> RFC EDITOR NOTE: If approved for publication as an RFC, this should
>> be marked additionally as "STD: 7" and replace RFC 793 in that role.
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14
>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-14
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-14
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
--=_957b846743aead2908a0260c8cf33f40
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



Based on the defined scope and approach of 793bis, as stated in its intr=
o:


On 2019-07-30 23:26, mohamed.boucadair@orange.com wrote:




=
Hi Wes, 

 Below some comments about the options as described in =
Section 3.1: 

 * Consider adding some text to ACK the TCP option=
 space problem. Adding a pointer to EDO as * an example * (without recommen=
ding it) of how to extend the space for non-SYNs would be useful.




=
 


=
It would be useful to mention the ongoing work, but not to try to repeat it=
=2E


=
 




=
* Add an explicit statement about 253/254 as being reserved for experiments=
 with a strong recommendation to make use of shared ExIDs.




=
 


=
It would be useful to note their being assigned for that purpose (not quite=
 RESERVED) and to ref 6994 for further details.


=
 


=
Given the focus of this updated is standards-track, it would be useful to r=
emind developers not to deploy options using those codepoints outside caref=
ully controlled experiments and that they are default to being not enabled =
in any code not under direct control of the developers.


=
 


=
However...


=
 




=
* What about obsoleting (?) 6994 and incorporating its main contribution as=
 part of 793bis?




=
 


=
I disagree. First, 6994 is not being obsoleted per se; second, others refer=
 to its approach for other similar experimental fields. It would be a bad i=
dea to try to "obsolete" it.


=
 


=
I also don't think it's useful to include these details inside 793bis - the=
se are not details needed for standards-compliant operation (esp. because t=
hey shouldn't be used for final standards-track options).


=
 


=
IMO, 6994 is a lot like congestion control; OK, if not better, as a separat=
e doc.


=
 


=
Joe


=
 


=
 




=
 


=


 Cheers,
 Med



-----Message d'origine-----
 De : I-D-Announ=
ce [mailto:i-d-announce-bo=
unces@ietf.org] De la part de
internet-drafts@ietf.org
 Envoyé : mardi 30 ju=
illet 2019 19:47
 À : i-d-announce@ietf.org
 Cc : tcpm@ietf.org
 Objet : I-D Action: draft-ietf-tcpm-rf=
c793bis-14.txt


 A New Internet-Draft is available from the=
 on-line Internet-Drafts
 directories.
 This draft is a work item=
 of the TCP Maintenance and Minor Extensions WG
 of the IETF.
         Title    =
;       : Transmission Control Protocol =
Specification
         Author =
         : Wesley M. Eddy
     Filename       &nbs=
p;: draft-ietf-tcpm-rfc793bis-14.txt
     Pages &n=
bsp;         : 104
  =
;   Date         &nb=
sp;  : 2019-07-30

 Abstract:
    T=
his document specifies the Internet's Transmission Control Protocol
 &=
nbsp;  (TCP).  TCP is an important transport layer protocol =
in the Internet
    stack, and has continuously evolved=
 over decades of use and growth of
    the Internet. &n=
bsp;Over this time, a number of changes have been made to
   =
; TCP as it was specified in RFC 793, though these have only been
    documented in a piecemeal fashion.  This document =
collects and brings
    those changes together with the=
 protocol specification from RFC 793.
    This document=
 obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
   &nb=
sp;6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,=

    and should be considered as a replacement for the =
portions of that
    document dealing with TCP requirem=
ents.  It updates RFC 5961 due to a
    small clar=
ification in reset handling while in the SYN-RECEIVED
   &nb=
sp;state.

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



 =
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-r=
fc793bis/

 There are also htmlized versions available at:https://tools.ietf.org/html/draf=
t-ietf-tcpm-rfc793bis-14
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-14=


 A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u=
rl2=3Ddraft-ietf-tcpm-rfc793bis-14


 Please note that i=
t may take a couple of minutes from the time of
 submission
 unti=
l 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/

 ________________=
_______________________________
 I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announ=
ce
 Internet-Draft directories: http://www.ietf.org=
/shadow.html
 or ftp://ftp.ietf.org/ie=
tf/1shadow-sites.txt


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





--=_957b846743aead2908a0260c8cf33f40--


From nobody Wed Jul 31 14:22: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 C6DFF1200B7 for ; Wed, 31 Jul 2019 14:22: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdZhTwXGvwSH for ; Wed, 31 Jul 2019 14:22:02 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 D6C2012006D for ; Wed, 31 Jul 2019 14:22:01 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id h6so14355708iom.7 for ; Wed, 31 Jul 2019 14:22:01 -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-language; bh=vuutupEUqy3OFZUpsKChjdHa3uKhNTcytN/wVDYIpTI=; b=LoFW9w1UUwhNyTfxy7+rbhwB66bM8dbb/SWkVlRvWB8tl46YtJpdTClrqGR1ZumVA+ 8J2+y0SqdxbhG3KRuGOX9H6k6Cx3dSaPZP+UEDs8pDHY5Vfa5p9Pxwq35NzK1Lhoa2Ta rUrhhXvPBTBkbhKXACObPZa/GPSCKDbkbNYfZqAsXZSto9kJT/ZxY6BiS7fHFuFQ8b+W rtQwUhfAJqbsnj+aQp8XRW/iWKXfZe1C6aFgzKIuHV24OVlXK+z9c0bgW83Rp0KV5KDE Du5vdAD/Use69OvxHEX3C5+MxC2eXSuzD7/u1i88SF7H05ekKoEnW3iH+er3YpHPnRO7 Hazw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vuutupEUqy3OFZUpsKChjdHa3uKhNTcytN/wVDYIpTI=; b=TWmvaznkOnEhqcH7VoTJwBAy2iKxAQHBDRtWG6G65u5vWlgMctd8TQr8HkBfFUx8j3 bqkeyBKVQVDXtCEk08VdxD8SknYpoYEZJVYIwudMIU39dVXFmnxx+0G/9sEnsCMSd/Kw GB33lA+Ab5ut8VJrat5aIUhQ3FK3OLWRCS9MnXPRlICWe0VJRAls9qASG0J3rx9FoM3x FaazcCEs6zGHhkQYCPtfd2d8pJ3KNSYWfthCKuxNvnNFbSWQ1oQPs3MtM9VQmQUs8bQm RmizqJv7WrctKESxdTCt/Vrwg05yb+evbaudhx/GILS1iHIgF0cqSEqziJI3NsRMFvG2 L9RQ==
X-Gm-Message-State: APjAAAXLlpQMX0H/dm1g+GAdut3NncUCIUtsgOReZQurq8IvZ/3ilI/P XhJMQUb4Q0OzbsjNyulA+VP2nheI
X-Google-Smtp-Source: APXvYqzm4epgrA+1Sq/kEV8Dcj07ttmIriVMx0iwdC9jtGG6PDBUwHD8+DeKHMF7uCdNHexEM4wrrA==
X-Received: by 2002:a02:1948:: with SMTP id b69mr36845670jab.55.1564608120974;  Wed, 31 Jul 2019 14:22:00 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id p10sm86475011iob.54.2019.07.31.14.22.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 14:22:00 -0700 (PDT)
To: Joe Touch , mohamed.boucadair@orange.com
Cc: tcpm@ietf.org
References: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 
From: Wesley Eddy 
Message-ID: 
Date: Wed, 31 Jul 2019 17:21:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------28BAC8B6823966B02593BAA8"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jul 2019 21:22:05 -0000

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

With editor hat on, I fully agree with what Joe said.


On 7/31/2019 2:50 PM, Joe Touch wrote:
>
> Based on the defined scope and approach of 793bis, as stated in its intro:
>
> On 2019-07-30 23:26, mohamed.boucadair@orange.com wrote:
>
>> Hi Wes,
>>
>> Below some comments about the options as described in Section 3.1:
>>
>> * Consider adding some text to ACK the TCP option space problem. 
>> Adding a pointer to EDO as * an example * (without recommending it) 
>> of how to extend the space for non-SYNs would be useful.
> It would be useful to mention the ongoing work, but not to try to 
> repeat it.
>> * Add an explicit statement about 253/254 as being reserved for 
>> experiments with a strong recommendation to make use of shared ExIDs.
> It would be useful to note their being assigned for that purpose (not 
> quite RESERVED) and to ref 6994 for further details.
> Given the focus of this updated is standards-track, it would be useful 
> to remind developers not to deploy options using those codepoints 
> outside carefully controlled experiments and that they are default to 
> being not enabled in any code not under direct control of the developers.
> However...
>> * What about obsoleting (?) 6994 and incorporating its main 
>> contribution as part of 793bis?
> I disagree. First, 6994 is not being obsoleted per se; second, others 
> refer to its approach for other similar experimental fields. It would 
> be a bad idea to try to "obsolete" it.
> I also don't think it's useful to include these details inside 793bis 
> - these are not details needed for standards-compliant operation (esp. 
> because they shouldn't be used for final standards-track options).
> IMO, 6994 is a lot like congestion control; OK, if not better, as a 
> separate doc.
> Joe

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


  
    
  
  
    
With editor hat on, I fully agree with what Joe said.

    


    

    
On 7/31/2019 2:50 PM, Joe Touch wrote:

    

    

      
      
Based on the defined scope and approach of 793bis, as stated in
        its intro:

      
On 2019-07-30 23:26, mohamed.boucadair@orange.com wrote:

      

        
Hi Wes, 

          

          Below some comments about the options as described in Section
          3.1: 

          

          * Consider adding some text to ACK the TCP option space
          problem. Adding a pointer to EDO as * an example * (without
          recommending it) of how to extend the space for non-SYNs would
          be useful.

      

      
 

      
It would be useful to mention the ongoing work, but
        not to try to repeat it.

      
 

      

        
* Add an explicit statement about 253/254 as being
          reserved for experiments with a strong recommendation to make
          use of shared ExIDs.

      

      
 

      
It would be useful to note their being assigned for
        that purpose (not quite RESERVED) and to ref 6994 for further
        details.

      
 

      
Given the focus of this updated is standards-track,
        it would be useful to remind developers not to deploy options
        using those codepoints outside carefully controlled experiments
        and that they are default to being not enabled in any code not
        under direct control of the developers.

      
 

      
However...

      
 

      

        
* What about obsoleting (?) 6994 and incorporating
          its main contribution as part of 793bis?

      

      
 

      
I disagree. First, 6994 is not being obsoleted per
        se; second, others refer to its approach for other similar
        experimental fields. It would be a bad idea to try to "obsolete"
        it.

      
 

      
I also don't think it's useful to include these
        details inside 793bis - these are not details needed for
        standards-compliant operation (esp. because they shouldn't be
        used for final standards-track options).

      
 

      
IMO, 6994 is a lot like congestion control; OK, if
        not better, as a separate doc.

      
 

      
Joe

      
 

      
 

    

  


--------------28BAC8B6823966B02593BAA8--


From nobody Wed Jul 31 22:38: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 65C2912006B for ; Wed, 31 Jul 2019 22:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYozBxk5JYLU for ; Wed, 31 Jul 2019 22:38:50 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 8F2BF120059 for ; Wed, 31 Jul 2019 22:38:50 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45zfGw4kpkz1yj2; Thu,  1 Aug 2019 07:38:48 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 45zfGw3jJJzDq87; Thu,  1 Aug 2019 07:38:48 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 1 Aug 2019 07:38:48 +0200
From: 
To: Joe Touch 
CC: Wesley Eddy , "tcpm@ietf.org" 
Thread-Topic: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
Thread-Index: AQHVR9DoIsQIX4hpAESJdvivisWkpablvviA
Date: Thu, 1 Aug 2019 05:38:47 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312F7CAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330312EB710@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_787AE7BB302AE849A7480A190F8B9330312F7CAFOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Aug 2019 05:38:54 -0000

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

SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9l
IFRvdWNoIFttYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb21dDQpFbnZvecOpIDogbWVyY3JlZGkg
MzEganVpbGxldCAyMDE5IDIwOjUxDQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCkNj
IDogV2VzbGV5IEVkZHk7IHRjcG1AaWV0Zi5vcmcNCk9iamV0IDogUmU6IFt0Y3BtXSBkcmFmdC1p
ZXRmLXRjcG0tcmZjNzkzYmlzLTE0OiBvcHRpb25zDQoNCg0KQmFzZWQgb24gdGhlIGRlZmluZWQg
c2NvcGUgYW5kIGFwcHJvYWNoIG9mIDc5M2JpcywgYXMgc3RhdGVkIGluIGl0cyBpbnRybzoNCg0K
T24gMjAxOS0wNy0zMCAyMzoyNiwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN
CkhpIFdlcywNCg0KQmVsb3cgc29tZSBjb21tZW50cyBhYm91dCB0aGUgb3B0aW9ucyBhcyBkZXNj
cmliZWQgaW4gU2VjdGlvbiAzLjE6DQoNCiogQ29uc2lkZXIgYWRkaW5nIHNvbWUgdGV4dCB0byBB
Q0sgdGhlIFRDUCBvcHRpb24gc3BhY2UgcHJvYmxlbS4gQWRkaW5nIGEgcG9pbnRlciB0byBFRE8g
YXMgKiBhbiBleGFtcGxlICogKHdpdGhvdXQgcmVjb21tZW5kaW5nIGl0KSBvZiBob3cgdG8gZXh0
ZW5kIHRoZSBzcGFjZSBmb3Igbm9uLVNZTnMgd291bGQgYmUgdXNlZnVsLg0KDQpJdCB3b3VsZCBi
ZSB1c2VmdWwgdG8gbWVudGlvbiB0aGUgb25nb2luZyB3b3JrLCBidXQgbm90IHRvIHRyeSB0byBy
ZXBlYXQgaXQuDQoNCltNZWRdIFllcywgdGhpcyBpcyB3aGF0IEkgaGFkIGluIG1pbmQuDQoNCiog
QWRkIGFuIGV4cGxpY2l0IHN0YXRlbWVudCBhYm91dCAyNTMvMjU0IGFzIGJlaW5nIHJlc2VydmVk
IGZvciBleHBlcmltZW50cyB3aXRoIGEgc3Ryb25nIHJlY29tbWVuZGF0aW9uIHRvIG1ha2UgdXNl
IG9mIHNoYXJlZCBFeElEcy4NCg0KSXQgd291bGQgYmUgdXNlZnVsIHRvIG5vdGUgdGhlaXIgYmVp
bmcgYXNzaWduZWQgZm9yIHRoYXQgcHVycG9zZSAobm90IHF1aXRlIFJFU0VSVkVEKQ0KDQpbTWVk
XSBJbmRlZWQuDQoNCmFuZCB0byByZWYgNjk5NCBmb3IgZnVydGhlciBkZXRhaWxzLg0KDQpHaXZl
biB0aGUgZm9jdXMgb2YgdGhpcyB1cGRhdGVkIGlzIHN0YW5kYXJkcy10cmFjaywgaXQgd291bGQg
YmUgdXNlZnVsIHRvIHJlbWluZCBkZXZlbG9wZXJzIG5vdCB0byBkZXBsb3kgb3B0aW9ucyB1c2lu
ZyB0aG9zZSBjb2RlcG9pbnRzIG91dHNpZGUgY2FyZWZ1bGx5IGNvbnRyb2xsZWQgZXhwZXJpbWVu
dHMgYW5kIHRoYXQgdGhleSBhcmUgZGVmYXVsdCB0byBiZWluZyBub3QgZW5hYmxlZCBpbiBhbnkg
Y29kZSBub3QgdW5kZXIgZGlyZWN0IGNvbnRyb2wgb2YgdGhlIGRldmVsb3BlcnMuDQoNCltNZWRd
IFNvdW5kcyByZWFzb25hYmxlLg0KDQpIb3dldmVyLi4uDQoNCiogV2hhdCBhYm91dCBvYnNvbGV0
aW5nICg/KSA2OTk0IGFuZCBpbmNvcnBvcmF0aW5nIGl0cyBtYWluIGNvbnRyaWJ1dGlvbiBhcyBw
YXJ0IG9mIDc5M2Jpcz8NCg0KSSBkaXNhZ3JlZS4gRmlyc3QsIDY5OTQgaXMgbm90IGJlaW5nIG9i
c29sZXRlZCBwZXIgc2U7IHNlY29uZCwgb3RoZXJzIHJlZmVyIHRvIGl0cyBhcHByb2FjaCBmb3Ig
b3RoZXIgc2ltaWxhciBleHBlcmltZW50YWwgZmllbGRzLiBJdCB3b3VsZCBiZSBhIGJhZCBpZGVh
IHRvIHRyeSB0byAib2Jzb2xldGUiIGl0Lg0KDQpbTWVkXSBUaGlzIGlzIG5vdCBhIHByb2JsZW0u
IFRoZXNlIGRvY3VtZW50cyBjYW4gcmVmZXIgdG8gUkZDNzkzYmlzIChpZiB3ZSBnbyB0aGF0IHBh
dGgpLiBCVFcsIHBsZWFzZSBub3RlICg/KSBpbiBteSBpbml0aWFsIGNvbW1lbnQsIHNvIEnigJlt
IGZpbmUgaWYgdGhlIFdHIGRlY2lkZXMgdG8gbWFpbnRhaW4gaXQsIGJ1dCDigKYNCg0KSSBhbHNv
IGRvbid0IHRoaW5rIGl0J3MgdXNlZnVsIHRvIGluY2x1ZGUgdGhlc2UgZGV0YWlscyBpbnNpZGUg
NzkzYmlzDQoNCltNZWRdIFdoYXQgSSBoYWQgaW4gbWluZCBpcyB0byBpbXBvcnQgdGhlIG9wdGlv
biBsYXlvdXQgYW5kIGtleSBpbmZvcm1hdGlvbiBpbnRvIDc5M2Jpcy4gV2hhdCBJ4oCZbSBob3Bp
bmcgd2l0aCB0aGlzIGNoYW5nZSBpcyB0byBhdm9pZCBoYXZpbmcgZGlzY3Vzc2lvbiBzaW1pbGFy
IHRvIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGNwaW5jL2ZWQ25ydk1v
dVRkZUl1d1R5dG9CUk5tenRIVSAoZW5kIG9mIHRoZSBtZXNzYWdlKSBlYWNoIHRpbWUgYSBuZXcg
b3B0aW9uIGlzIGRpc2N1c3NlZC4NCg0KLSB0aGVzZSBhcmUgbm90IGRldGFpbHMgbmVlZGVkIGZv
ciBzdGFuZGFyZHMtY29tcGxpYW50IG9wZXJhdGlvbg0KDQpbTWVkXSBJ4oCZbSBub3Qgc3VyZSB0
byBwYXJzZSB0aGlzIGNvbW1lbnQuIFJGQzY5OTQgaXMgYSBzdGFuZGFyZCB0cmFjayBSRkMuDQoN
Cihlc3AuIGJlY2F1c2UgdGhleSBzaG91bGRuJ3QgYmUgdXNlZCBmb3IgZmluYWwgc3RhbmRhcmRz
LXRyYWNrIG9wdGlvbnMpLg0KDQpJTU8sIDY5OTQgaXMgYSBsb3QgbGlrZSBjb25nZXN0aW9uIGNv
bnRyb2w7IE9LLCBpZiBub3QgYmV0dGVyLCBhcyBhIHNlcGFyYXRlIGRvYy4NCg0KW01lZF0gVGhh
dOKAmXMgT0sgdG8gbWFpbnRhaW4gaXQsIGJ1dCB0aGVyZSBpcyBhIHZhbHVlIHRvIGV4dHJhY3Qg
dGhlIG1haW4gbWVzc2FnZXMgYW5kIGluY29ycG9yYXRlIHRoZW0gaW50byA3OTNiaXMuDQoNCg0K
Sm9lDQoNCg0KDQoNCg0KQ2hlZXJzLA0KTWVkDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t
LS0tDQpEZSA6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQgZGUN
CmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
Pg0KRW52b3nDqSA6IG1hcmRpIDMwIGp1aWxsZXQgMjAxOSAxOTo0Nw0Kw4AgOiBpLWQtYW5ub3Vu
Y2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjIDogdGNwbUBpZXRm
Lm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCk9iamV0IDogSS1EIEFjdGlvbjogZHJhZnQtaWV0
Zi10Y3BtLXJmYzc5M2Jpcy0xNC50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp
bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCmRpcmVjdG9yaWVzLg0KVGhp
cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVENQIE1haW50ZW5hbmNlIGFuZCBNaW5vciBF
eHRlbnNpb25zIFdHDQpvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBU
cmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCBTcGVjaWZpY2F0aW9uDQogICAgICAgIEF1dGhv
ciAgICAgICAgICA6IFdlc2xleSBNLiBFZGR5DQogICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQt
aWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNC50eHQNCiAgICBQYWdlcyAgICAgICAgICAgOiAxMDQNCiAg
ICBEYXRlICAgICAgICAgICAgOiAyMDE5LTA3LTMwDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1
bWVudCBzcGVjaWZpZXMgdGhlIEludGVybmV0J3MgVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9j
b2wNCiAgIChUQ1ApLiAgVENQIGlzIGFuIGltcG9ydGFudCB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9j
b2wgaW4gdGhlIEludGVybmV0DQogICBzdGFjaywgYW5kIGhhcyBjb250aW51b3VzbHkgZXZvbHZl
ZCBvdmVyIGRlY2FkZXMgb2YgdXNlIGFuZCBncm93dGggb2YNCiAgIHRoZSBJbnRlcm5ldC4gIE92
ZXIgdGhpcyB0aW1lLCBhIG51bWJlciBvZiBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHRvDQogICBU
Q1AgYXMgaXQgd2FzIHNwZWNpZmllZCBpbiBSRkMgNzkzLCB0aG91Z2ggdGhlc2UgaGF2ZSBvbmx5
IGJlZW4NCiAgIGRvY3VtZW50ZWQgaW4gYSBwaWVjZW1lYWwgZmFzaGlvbi4gIFRoaXMgZG9jdW1l
bnQgY29sbGVjdHMgYW5kIGJyaW5ncw0KICAgdGhvc2UgY2hhbmdlcyB0b2dldGhlciB3aXRoIHRo
ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZyb20gUkZDIDc5My4NCiAgIFRoaXMgZG9jdW1lbnQg
b2Jzb2xldGVzIFJGQyA3OTMsIGFzIHdlbGwgYXMgODc5LCAyODczLCA2MDkzLCA2NDI5LA0KICAg
NjUyOCwgYW5kIDY2OTEgdGhhdCB1cGRhdGVkIHBhcnRzIG9mIFJGQyA3OTMuICBJdCB1cGRhdGVz
IFJGQyAxMTIyLA0KICAgYW5kIHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIGEgcmVwbGFjZW1lbnQg
Zm9yIHRoZSBwb3J0aW9ucyBvZiB0aGF0DQogICBkb2N1bWVudCBkZWFsaW5nIHdpdGggVENQIHJl
cXVpcmVtZW50cy4gIEl0IHVwZGF0ZXMgUkZDIDU5NjEgZHVlIHRvIGENCiAgIHNtYWxsIGNsYXJp
ZmljYXRpb24gaW4gcmVzZXQgaGFuZGxpbmcgd2hpbGUgaW4gdGhlIFNZTi1SRUNFSVZFRA0KICAg
c3RhdGUuDQoNCiAgIFJGQyBFRElUT1IgTk9URTogSWYgYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9u
IGFzIGFuIFJGQywgdGhpcyBzaG91bGQNCiAgIGJlIG1hcmtlZCBhZGRpdGlvbmFsbHkgYXMgIlNU
RDogNyIgYW5kIHJlcGxhY2UgUkZDIDc5MyBpbiB0aGF0IHJvbGUuDQoNCg0KDQpUaGUgSUVURiBk
YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMvDQoNClRoZXJlIGFy
ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0DQpodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQNCg0KQSBk
aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQNCg0K
DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0
aGUgdGltZSBvZg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFy
ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3Jn
L2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRm
Lm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVz
OiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcv
aWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRv
OnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rj
cG0NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1
IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi
c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0
ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo
dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K
CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm
Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0
Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcw
Ljg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjpibGFjayI+SGkgSm9lLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ug
c2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVk
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s
b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0
LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJh
eWFscGhhLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAzMSBqdWls
bGV0IDIwMTkgMjA6NTE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRH
SS9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFdlc2xleSBFZGR5OyB0Y3BtQGlldGYub3JnPGJy
Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3RjcG1dIGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNi
aXMtMTQ6IG9wdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkJhc2VkIG9uIHRoZSBkZWZpbmVkIHNjb3BlIGFuZCBhcHByb2FjaCBv
ZiA3OTNiaXMsIGFzIHN0YXRlZCBpbiBpdHMgaW50cm86PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiAyMDE5LTA3LTMwIDIzOjI2LCBtb2hh
bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEu
NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdo
dDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IaSBXZXMsDQo8
YnI+DQo8YnI+DQpCZWxvdyBzb21lIGNvbW1lbnRzIGFib3V0IHRoZSBvcHRpb25zIGFzIGRlc2Ny
aWJlZCBpbiBTZWN0aW9uIDMuMTogPGJyPg0KPGJyPg0KKiBDb25zaWRlciBhZGRpbmcgc29tZSB0
ZXh0IHRvIEFDSyB0aGUgVENQIG9wdGlvbiBzcGFjZSBwcm9ibGVtLiBBZGRpbmcgYSBwb2ludGVy
IHRvIEVETyBhcyAqIGFuIGV4YW1wbGUgKiAod2l0aG91dCByZWNvbW1lbmRpbmcgaXQpIG9mIGhv
dyB0byBleHRlbmQgdGhlIHNwYWNlIGZvciBub24tU1lOcyB3b3VsZCBiZSB1c2VmdWwuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCB3b3VsZCBiZSB1c2Vm
dWwgdG8gbWVudGlvbiB0aGUgb25nb2luZyB3b3JrLCBidXQgbm90IHRvIHRyeSB0byByZXBlYXQg
aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN
ZWRdIFllcywgdGhpcyBpcyB3aGF0IEkgaGFkIGluIG1pbmQuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6
MGNtIDBjbSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY20iPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4qIEFkZCBhbiBleHBsaWNpdCBzdGF0
ZW1lbnQgYWJvdXQgMjUzLzI1NCBhcyBiZWluZyByZXNlcnZlZCBmb3IgZXhwZXJpbWVudHMgd2l0
aCBhIHN0cm9uZyByZWNvbW1lbmRhdGlvbiB0byBtYWtlIHVzZSBvZiBzaGFyZWQgRXhJRHMuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCB3b3VsZCBiZSB1
c2VmdWwgdG8gbm90ZSB0aGVpciBiZWluZyBhc3NpZ25lZCBmb3IgdGhhdCBwdXJwb3NlIChub3Qg
cXVpdGUgUkVTRVJWRUQpPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh
bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEluZGVlZC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YW5kIHRvIHJlZiA2OTk0IGZv
ciBmdXJ0aGVyIGRldGFpbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+R2l2ZW4gdGhlIGZvY3VzIG9mIHRoaXMgdXBkYXRlZCBpcyBzdGFuZGFyZHMtdHJhY2ss
IGl0IHdvdWxkIGJlIHVzZWZ1bCB0byByZW1pbmQgZGV2ZWxvcGVycyBub3QgdG8gZGVwbG95IG9w
dGlvbnMgdXNpbmcgdGhvc2UgY29kZXBvaW50cyBvdXRzaWRlIGNhcmVmdWxseSBjb250cm9sbGVk
IGV4cGVyaW1lbnRzIGFuZA0KIHRoYXQgdGhleSBhcmUgZGVmYXVsdCB0byBiZWluZyBub3QgZW5h
YmxlZCBpbiBhbnkgY29kZSBub3QgdW5kZXIgZGlyZWN0IGNvbnRyb2wgb2YgdGhlIGRldmVsb3Bl
cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7
Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBTb3VuZHMgcmVhc29uYWJsZS4NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93ZXZlci4uLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4qIFdoYXQgYWJvdXQgb2Jzb2xldGluZyAoPykgNjk5
NCBhbmQgaW5jb3Jwb3JhdGluZyBpdHMgbWFpbiBjb250cmlidXRpb24gYXMgcGFydCBvZiA3OTNi
aXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+SSBkaXNhZ3JlZS4gRmlyc3QsIDY5OTQgaXMgbm90IGJlaW5nIG9ic29sZXRlZCBwZXIg
c2U7IHNlY29uZCwgb3RoZXJzIHJlZmVyIHRvIGl0cyBhcHByb2FjaCBmb3Igb3RoZXIgc2ltaWxh
ciBleHBlcmltZW50YWwgZmllbGRzLiBJdCB3b3VsZCBiZSBhIGJhZCBpZGVhIHRvIHRyeSB0byAm
cXVvdDtvYnNvbGV0ZSZxdW90Ow0KIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGlzIGlzIG5vdCBhIHByb2JsZW0uIFRoZXNlIGRv
Y3VtZW50cyBjYW4gcmVmZXIgdG8gUkZDNzkzYmlzIChpZiB3ZSBnbyB0aGF0IHBhdGgpLiBCVFcs
IHBsZWFzZSBub3RlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4oPykgaW4gbXkgaW5p
dGlhbCBjb21tZW50LCBzbyBJ4oCZbSBmaW5lIGlmIHRoZSBXRyBkZWNpZGVzIHRvIG1haW50YWlu
IGl0LCBidXQg4oCmPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkg
YWxzbyBkb24ndCB0aGluayBpdCdzIHVzZWZ1bCB0byBpbmNsdWRlIHRoZXNlIGRldGFpbHMgaW5z
aWRlIDc5M2Jpcw0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv
bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdoYXQgSSBoYWQg
aW4gbWluZCBpcyB0byBpbXBvcnQgdGhlIG9wdGlvbiBsYXlvdXQgYW5kIGtleSBpbmZvcm1hdGlv
biBpbnRvIDc5M2Jpcy4gV2hhdCBJ4oCZbSBob3Bpbmcgd2l0aCB0aGlzIGNoYW5nZSBpcyB0byBh
dm9pZCBoYXZpbmcgZGlzY3Vzc2lvbiBzaW1pbGFyDQogdG8gPGEgaHJlZj0iaHR0cHM6Ly9tYWls
YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90Y3BpbmMvZlZDbnJ2TW91VGRlSXV3VHl0b0JSTm16
dEhVIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGNwaW5jL2ZWQ25y
dk1vdVRkZUl1d1R5dG9CUk5tenRIVTwvYT4gKGVuZCBvZiB0aGUgbWVzc2FnZSkgZWFjaCB0aW1l
IGEgbmV3IG9wdGlvbiBpcyBkaXNjdXNzZWQuICZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHRoZXNlIGFyZSBub3QgZGV0YWlscyBuZWVk
ZWQgZm9yIHN0YW5kYXJkcy1jb21wbGlhbnQgb3BlcmF0aW9uPHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6
YmxhY2siPltNZWRdIEnigJltIG5vdCBzdXJlIHRvIHBhcnNlIHRoaXMgY29tbWVudC4gUkZDNjk5
NCBpcyBhIHN0YW5kYXJkIHRyYWNrIFJGQy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4oZXNwLiBiZWNhdXNlIHRoZXkgc2hvdWxkbid0IGJlIHVzZWQgZm9yIGZpbmFs
IHN0YW5kYXJkcy10cmFjayBvcHRpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5JTU8sIDY5OTQgaXMgYSBsb3QgbGlrZSBjb25nZXN0aW9uIGNvbnRyb2w7
IE9LLCBpZiBub3QgYmV0dGVyLCBhcyBhIHNlcGFyYXRlIGRvYy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGF04oCZcyBPSyB0byBtYWludGFpbiBpdCwgYnV0
IHRoZXJlIGlzIGEgdmFsdWUgdG8gZXh0cmFjdCB0aGUgbWFpbiBtZXNzYWdlcyBhbmQgaW5jb3Jw
b3JhdGUgdGhlbSBpbnRvIDc5M2Jpcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Sm9lPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZG
IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1y
aWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCk1lZDxicj4NCjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQpEZSZuYnNwOzogSS1ELUFubm91bmNlIFtt
YWlsdG86PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIj5pLWQt
YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGU8YnI+DQo8YSBocmVm
PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmc8L2E+PGJyPg0KRW52b3nDqSZuYnNwOzogbWFyZGkgMzAganVpbGxldCAyMDE5IDE5OjQ3PGJy
Pg0Kw4AmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1h
bm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQpDYyZuYnNwOzogPGEgaHJlZj0ibWFpbHRvOnRjcG1A
aWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KT2JqZXQmbmJzcDs6IEktRCBBY3Rpb246
IGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBOZXcg
SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh
ZnRzPGJyPg0KZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0
aGUgVENQIE1haW50ZW5hbmNlIGFuZCBNaW5vciBFeHRlbnNpb25zIFdHPGJyPg0Kb2YgdGhlIElF
VEYuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7OiBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCBTcGVjaWZpY2F0
aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
QXV0aG9yICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzogV2VzbGV5IE0uIEVkZHk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtGaWxlbmFt
ZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYt
dGNwbS1yZmM3OTNiaXMtMTQudHh0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGFnZXMg
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7OiAxMDQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtEYXRlICZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAx
OS0wNy0zMDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMg
ZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBJbnRlcm5ldCdzIFRyYW5zbWlzc2lvbiBDb250cm9sIFBy
b3RvY29sPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7KFRDUCkuICZuYnNwO1RDUCBpcyBhbiBpbXBv
cnRhbnQgdHJhbnNwb3J0IGxheWVyIHByb3RvY29sIGluIHRoZSBJbnRlcm5ldDxicj4NCiZuYnNw
OyZuYnNwOyZuYnNwO3N0YWNrLCBhbmQgaGFzIGNvbnRpbnVvdXNseSBldm9sdmVkIG92ZXIgZGVj
YWRlcyBvZiB1c2UgYW5kIGdyb3d0aCBvZjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBJbnRl
cm5ldC4gJm5ic3A7T3ZlciB0aGlzIHRpbWUsIGEgbnVtYmVyIG9mIGNoYW5nZXMgaGF2ZSBiZWVu
IG1hZGUgdG88YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUQ1AgYXMgaXQgd2FzIHNwZWNpZmllZCBp
biBSRkMgNzkzLCB0aG91Z2ggdGhlc2UgaGF2ZSBvbmx5IGJlZW48YnI+DQombmJzcDsmbmJzcDsm
bmJzcDtkb2N1bWVudGVkIGluIGEgcGllY2VtZWFsIGZhc2hpb24uICZuYnNwO1RoaXMgZG9jdW1l
bnQgY29sbGVjdHMgYW5kIGJyaW5nczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3Rob3NlIGNoYW5n
ZXMgdG9nZXRoZXIgd2l0aCB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBmcm9tIFJGQyA3OTMu
PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDc5Mywg
YXMgd2VsbCBhcyA4NzksIDI4NzMsIDYwOTMsIDY0MjksPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7
NjUyOCwgYW5kIDY2OTEgdGhhdCB1cGRhdGVkIHBhcnRzIG9mIFJGQyA3OTMuICZuYnNwO0l0IHVw
ZGF0ZXMgUkZDIDExMjIsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIHNob3VsZCBiZSBjb25z
aWRlcmVkIGFzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBwb3J0aW9ucyBvZiB0aGF0PGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7ZG9jdW1lbnQgZGVhbGluZyB3aXRoIFRDUCByZXF1aXJlbWVudHMuICZu
YnNwO0l0IHVwZGF0ZXMgUkZDIDU5NjEgZHVlIHRvIGE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtz
bWFsbCBjbGFyaWZpY2F0aW9uIGluIHJlc2V0IGhhbmRsaW5nIHdoaWxlIGluIHRoZSBTWU4tUkVD
RUlWRUQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtzdGF0ZS48YnI+DQo8YnI+DQombmJzcDsmbmJz
cDsmbmJzcDtSRkMgRURJVE9SIE5PVEU6IElmIGFwcHJvdmVkIGZvciBwdWJsaWNhdGlvbiBhcyBh
biBSRkMsIHRoaXMgc2hvdWxkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YmUgbWFya2VkIGFkZGl0
aW9uYWxseSBhcyAmcXVvdDtTVEQ6IDcmcXVvdDsgYW5kIHJlcGxhY2UgUkZDIDc5MyBpbiB0aGF0
IHJvbGUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz
IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy8iIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRjcG0tcmZjNzkz
YmlzLzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFp
bGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNDwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGNwbS1y
ZmM3OTNiaXMtMTQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQ8L2E+PGJyPg0KPGJyPg0KQSBk
aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmZj
NzkzYmlzLTE0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91
cmwyPWRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQ8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxl
YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp
bWUgb2Y8YnI+DQpzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k
IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpJbnRlcm5l
dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEg
aHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5r
Ij5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYu
b3JnIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwvYT48YnI+
DQpJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y
Zy9zaGFkb3cuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFk
b3cuaHRtbDwvYT48YnI+DQpvciA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hh
ZG93LXNpdGVzLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz
aGFkb3ctc2l0ZXMudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCnRjcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv
OnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_787AE7BB302AE849A7480A190F8B9330312F7CAFOPEXCAUBMA2corp_--