From nobody Sat Oct 3 11:29:28 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AC53A09FF for ; Sat, 3 Oct 2020 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 9RWoUyOdwBJg for ; Sat, 3 Oct 2020 11:29:26 -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 D0C993A09FC for ; Sat, 3 Oct 2020 11:29:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8805A25A19 for ; Sat, 3 Oct 2020 20:29:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1601749763; bh=1LwT+0Yb4S6/+lR5Y9D58kiOpcc/qQKvb4zovUH8/6A=; h=From:To:Subject:Date:From; b=nuCIB7R6hrpBy9YTd40vUSheyj15FKZGMNgQ+nEtBrnajFdL/3zSx6gzMOKZLKd77 pRizfTOTfCsvMsgsp9JAALnuWuvNE7DZEOw2zqbYbsOqn3BGwEf/+UHKUAnzBjPzVI moSSJMDp7UmqPAjIwnn+Yz1jonr9Mopact/uaQWs= 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 oFfLnRok2FgC for ; Sat, 3 Oct 2020 20:29:22 +0200 (CEST) Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Sat, 3 Oct 2020 20:29:22 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Sat, 3 Oct 2020 20:29:22 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Sat, 3 Oct 2020 20:29:22 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org Extensions" Thread-Topic: WGLC for 793bis - REMINDER Thread-Index: AdaZssOdUC4rS3UwSx21/tgTZkZv7g== Date: Sat, 3 Oct 2020 18:29:22 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WGLC for 793bis - REMINDER X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 18:29:28 -0000 Hi all, This is a friendly reminder. Please have a look at 793bis! Thanks Michael > -----Original Message----- > From: tcpm On Behalf Of Scharf, Michael > Sent: Friday, September 18, 2020 2:12 PM > To: tcpm@ietf.org Extensions > Subject: [tcpm] WGLC for 793bis - REVIEW NEEDED >=20 > Dear TCPM contributors, >=20 > This e-mail starts a working group last call for draft-ietf-tcpm-rfc793bi= s-18. > Information about the document can be found at this link: >=20 > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ >=20 > For instance, the current version can be found at > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18. >=20 > When adopting draft-ietf-tcpm-rfc793bis, the TCPM working group > consensus was to limit the scope of 793bis to TCP changes that are specif= ied > either in standards-track RFCs or in verified errata. Also, the consensus= was > to focus on the base protocol and exclude mechanisms that can be specifie= d > separately (e.g., congestion control). As a result, 793bis should in prin= ciple > not contain anything new. Nonetheless, we all know that TCP is a complex > protocol and even small details of the specification matter a lot. >=20 > Given that 793bis will obsolete RFC 793, which is one of the most importa= nt > Internet Standards, this WGLC will run for *four weeks*, i.e., until Octo= ber > 16. >=20 > Therefore, *your* help is needed: PLEASE review 793bis in the next weeks! > The earlier, the better... >=20 > - Any comments or suggestions are important and highly appreciated. Even = if > you don't speak up often on the TCPM mailing list, please let us know if = you > have any feedback. >=20 > - Even if you read the document without finding any errors or issue, plea= se > let us know ("+1"). >=20 > - It is also perfectly fine to look only at a subset of the document, e.g= ., if you > are familiar with specific details of TCP. Partial reviews are welcome, t= oo. >=20 > - If you own TCP running code, you definitively should have a very close = look; > this document is supposed to be the new base specification of TCP. >=20 > RFC 793 lays the ground for all work in TCPM, and 793bis is probably one = of > the most important deliverables of TCPM. Please help us with completing > this milestone. >=20 > Thanks! >=20 > Michael Scharf > Yoshifumi Nishida > Michael Tuexen > (TCPM chairs) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Oct 11 10:33:07 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06AD3A0EEB for ; Sun, 11 Oct 2020 10:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 0e5UpYG4aoaa for ; Sun, 11 Oct 2020 10:33:04 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 E054C3A0EE9 for ; Sun, 11 Oct 2020 10:33:03 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id dn5so14513202edb.10 for ; Sun, 11 Oct 2020 10:33:03 -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=OYpeIlxuIb00dquG/B9F6htMRQ0LwYFMOvx7IooKv/U=; b=bPXSoqGOSDgxJjbENOd43p7U3v61o3u41ozi6uWG2AGPgJxqYna/4JSO4sIHILnyZu Z+o7i0ulRMI9UEVU9y4GcKGtTWotzhMiFAUsbfcBUZfY20Q74u8Iip2yVuZyZFlGYFHZ CWLnzM2uNMW1x+YPN3dN43s2ADrKW0cBZdL05ue1gfAHBDujAb+I/dqpdWvNLADeAdss lFWf546VWBbUQEQlQq04tAQn4dnmNlgH6ywphWsiHEhIXKreAqnLwjxqtpvkeofD09KC qnDd/yRXp+daG+IaqriMi50wKyHGkTe78yq9upx6aiZmMA0l1N1sNP/91DtTF9HIzhoN gyvQ== 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=OYpeIlxuIb00dquG/B9F6htMRQ0LwYFMOvx7IooKv/U=; b=Gq1d/fE8r409a+mkgUHCVvUmJuq0ysdHiA8klGa3BnfeId3ebZIEpaSUicr6kyraWt I+5I4zgJyL00MTUTXZVFhMiNzkACvvphTB1Cefu9gqV8xeZ8vS54Zmkx35wg0r0jWpNc JIz9Qa0ASkevZZM95kMgI0EvBpijX/QKJ4Hz62bg+aCVyItwf8uoUtCuhETNrQK9qQTn yOct5gEmWchoJegiL//Kp+yTlBtNP/E4z8QeowWexnzVbmKgPieojNeGi34HSHsOZ9j1 vAzrbj53gCuoUUx2WWe3zWOTgOgl4WPo1FtQMkwcbjY2l4sjKPwurNaIfKMbh7qDlHFl OT1A== X-Gm-Message-State: AOAM531WlsMsciXfBqK3AenKICGl4TYTtx5kmwDqDkMbCWp6wksxG5kS TOHH/tyHAdhWenNwg4RO0SC/LZiiPEhGV810fxz+/Wnz8YT14Q== X-Google-Smtp-Source: ABdhPJxVKDe7jFnoyLhNt8ok7bnTiq/oWf/ldu2Zcf0jOLI615hrC+hgWjy3IjdiGD+AhIxOwbBJiOjNU2+dU/90SK4= X-Received: by 2002:a05:6402:7c8:: with SMTP id u8mr10361882edy.153.1602437581972; Sun, 11 Oct 2020 10:33:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Sun, 11 Oct 2020 23:02:51 +0530 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] WGLC for 793bis - Review comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 17:33:06 -0000 This is an incredibly detailed work, covering protocol, implementation, and different scenarios aspects. The scenarios/context provided for "Quiet Time specification" and "Reset handling", were particularly interesting to note for me. Following are my comments: Section 3.1: "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)." [RJ] It should be "TCP will _not_ work (MUST-1)" ... I guess its a typo (?). Section 3.5.1: ... an application that has called CLOSE cannot continue to read data from the connection (MAY-1). [RJ] shouldn't this be that "an application that has called CLOSE _can_ continue to read data from the connection (MAY-1)"? ... Again I suppose it's a typo but want to make sure. Section 3.5.1: See [18] section 2.17 for discussion. [RJ] This reference is broken since section 2.17 no more exists. Section 2.1: ... with each TCP segment sent as an Internet Protocol (IP) datagram. [RJ] Even though recommended, it isn't necessary that each TCP segment be sent as a single IP datagram. Section 2.1: Anycast applications exist that successfully use TCP without modifications, though there is some risk of instability due to changes of lower-layer forwarding behavior. [RJ] A ref would help. Small Nits: Section 3.3: ...likelihood of reuse of ports and sequency numbers after reboots. [RJ] s/sequency/sequence Section 3.6.5: ...present IPv6 Node Requiements [RJ] s/Requiements/Requirements Best, Rahul On Sat, 3 Oct 2020 at 23:59, Scharf, Michael wrote: > > Hi all, > > This is a friendly reminder. Please have a look at 793bis! > > Thanks > > Michael > > > > -----Original Message----- > > From: tcpm On Behalf Of Scharf, Michael > > Sent: Friday, September 18, 2020 2:12 PM > > To: tcpm@ietf.org Extensions > > Subject: [tcpm] WGLC for 793bis - REVIEW NEEDED > > > > Dear TCPM contributors, > > > > This e-mail starts a working group last call for draft-ietf-tcpm-rfc793bis-18. > > Information about the document can be found at this link: > > > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > > > For instance, the current version can be found at > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18. > > > > When adopting draft-ietf-tcpm-rfc793bis, the TCPM working group > > consensus was to limit the scope of 793bis to TCP changes that are specified > > either in standards-track RFCs or in verified errata. Also, the consensus was > > to focus on the base protocol and exclude mechanisms that can be specified > > separately (e.g., congestion control). As a result, 793bis should in principle > > not contain anything new. Nonetheless, we all know that TCP is a complex > > protocol and even small details of the specification matter a lot. > > > > Given that 793bis will obsolete RFC 793, which is one of the most important > > Internet Standards, this WGLC will run for *four weeks*, i.e., until October > > 16. > > > > Therefore, *your* help is needed: PLEASE review 793bis in the next weeks! > > The earlier, the better... > > > > - Any comments or suggestions are important and highly appreciated. Even if > > you don't speak up often on the TCPM mailing list, please let us know if you > > have any feedback. > > > > - Even if you read the document without finding any errors or issue, please > > let us know ("+1"). > > > > - It is also perfectly fine to look only at a subset of the document, e.g., if you > > are familiar with specific details of TCP. Partial reviews are welcome, too. > > > > - If you own TCP running code, you definitively should have a very close look; > > this document is supposed to be the new base specification of TCP. > > > > RFC 793 lays the ground for all work in TCPM, and 793bis is probably one of > > the most important deliverables of TCPM. Please help us with completing > > this milestone. > > > > Thanks! > > > > Michael Scharf > > Yoshifumi Nishida > > Michael Tuexen > > (TCPM chairs) > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Oct 13 09:38:19 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35223A09BA for ; Tue, 13 Oct 2020 09:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, 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 3aJo6koIuVZh for ; Tue, 13 Oct 2020 09:38:16 -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 47C2E3A09BD for ; Tue, 13 Oct 2020 09:38:16 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id 67so23521905iob.8 for ; Tue, 13 Oct 2020 09:38:16 -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=7mNXdpIbBktfCXJHTJ8XXv3RinXy9yiCsSH5hr9/x9g=; b=DN9UY9UhBsGvBPyBGkFD42UuNSMb1dT/gc4JWAhdRxDl762HEkpp/gIasi9cxrPcFS XV6ieUdVezsVUuIlT21w3IbLui93LwN3Xw5G2QkKLgQCOHlJlAs97UFTFkuIGlX7SZHW +rbPHuDXCXEw01HuHAeTh9dlj3o8Mq0PAfdGcsYMdjDz45oUf4y7KMK6YtADeHxnEkCN vJSOCc8aKjqIApB6PCbR95YRYVL5GrHnUrFXf+E7Jy/52ftfhwtis0xazeT6aPc2sx2A r84Vzm0PCQbvjyzxsIGc6t46zP0Ts/xJSjMwT0wmZDPsC7EJ64yR8ZPfILBICZETAFVQ E0mw== 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=7mNXdpIbBktfCXJHTJ8XXv3RinXy9yiCsSH5hr9/x9g=; b=J8Wf1SMyln2VIF/IS3/Eiy36Q6+gOV9G/ASxJs8Fp0+U5IY/dkLJd4Uts9WzIJJiNn LjQn6Ydun0KY0s/rKAECaYxRyknm0IAinM3gQTUl8ScQgYX2+zLonIbm8di0w/6jzKqb DmGzw68Fooqsp3FtfyJCYhNcgKXMsZ1zVVbgFlry4C+Kr9V0uAtFNiw3XVn9TN1W6Y9P BkFcmhbPbKi42rVyk9pKnuSe0vTHaM943mKQqgPGEuj3vzZl4r3GR1U86t67Dl0dvoWu EI74SxTrAdD0jQpHO9K7LXucrbvdmhMjE84utguWSLMY4eeSRnRkyUtk8fUNQu75UjkJ vPGw== X-Gm-Message-State: AOAM5330qmCQcsJpDiSp0Cf4sNxiBWsAEzN5+Ue1Y9JEmrYgwCkpeMMH 123iOyx0XuIpqSQUVnwAilLd7IpVTQXmtiaI X-Google-Smtp-Source: ABdhPJxWDJnsvkZAzX5aSlCm9k/SqXy2b3zBoAGYNSyG8AWQFaoifIci+A7npZ5MkuGBBhHXA1YXqw== X-Received: by 2002:a5e:961a:: with SMTP id a26mr214147ioq.48.1602607094444; Tue, 13 Oct 2020 09:38:14 -0700 (PDT) Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id d21sm331218ioi.39.2020.10.13.09.38.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2020 09:38:13 -0700 (PDT) To: tcpm@ietf.org References: From: Wesley Eddy Message-ID: Date: Tue, 13 Oct 2020 12:38:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] WGLC for 793bis - Review comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 16:38:18 -0000 Thank you for the review and comments.  For the most part, these were easy to address in my working copy, but there I think the parts around half-duplex CLOSE shouldn't change.  Here are some responses to each, with more details: On 10/11/2020 1:32 PM, Rahul Jadhav wrote: > This is an incredibly detailed work, covering protocol, > implementation, and different scenarios aspects. The scenarios/context > provided for "Quiet Time specification" and "Reset handling", were > particularly interesting to note for me. Following are my comments: > > Section 3.1: "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)." > [RJ] It should be "TCP will _not_ work (MUST-1)" ... I guess its a typo (?). You're correct; I've now fixed this in the working copy. > Section 3.5.1: ... an application that has called CLOSE cannot > continue to read data from the connection (MAY-1). > [RJ] shouldn't this be that "an application that has called CLOSE > _can_ continue to read data from the connection (MAY-1)"? ... Again I > suppose it's a typo but want to make sure. This is in reference to the peculiar "half-duplex" implementation option for the CLOSE sequence.   The first paragraph of this section discusses the normal "full-duplex" option, and this second paragraph covers the half-duplex option.  So, this is actually correct as-written.  The RFC 2525 reference mentioned at the end of the section is clear on this. > Section 3.5.1: See [18] section 2.17 for discussion. > [RJ] This reference is broken since section 2.17 no more exists. It is actually RFC 2525 Section 2.17 (not section 2.17 of 793bis) that is referenced here.   The autogenerated hyperlink doesn't seem to understand that, but it's clear from the text at least. > Section 2.1: ... with each TCP segment sent as an Internet Protocol > (IP) datagram. > [RJ] Even though recommended, it isn't necessary that each TCP segment > be sent as a single IP datagram. Hmmm, this I don't know about.  Are you thinking of IP fragmentation? > Section 2.1: Anycast applications exist that successfully use TCP > without modifications, though there is some risk of instability due to > changes of lower-layer forwarding behavior. > [RJ] A ref would help. I think we can add a reference to RFC 7094 here to the document. https://tools.ietf.org/html/rfc7094 > Small Nits: > Section 3.3: ...likelihood of reuse of ports and sequency numbers after reboots. > [RJ] s/sequency/sequence ACK. > Section 3.6.5: ...present IPv6 Node Requiements > [RJ] s/Requiements/Requirements ACK. From nobody Tue Oct 13 12:41:19 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB79D3A10F2 for ; Tue, 13 Oct 2020 12:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, 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 2o-dbIAe_hBG for ; Tue, 13 Oct 2020 12:41:16 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 2BECA3A10EA for ; Tue, 13 Oct 2020 12:41:15 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id n6so1074663ioc.12 for ; Tue, 13 Oct 2020 12:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=8qyi2AFFbZIdfMhRcLlTDvB2fgynARKfi3U2nJuo6o8=; b=W2UB4tl3d8pDKRBz9Ok/zESsjz9SwxeNEqtHGm7weyYPj226oQW5KM5WAJ5eCRArnZ 6VAJ3h9gzpi9vfQDA9wHM/BSRAFVgr65nHhfBVP8NKO3cbNG7HIQiV/44hMH/btBb8op QYe8i68DavwpkzYrnKJE3Hbvsk93fj2s0m0BWSs0AlrKmaaT7TIPJEc+R/Wj4S7k5RGy VhQxXJJEqQerNfrl0BJTFsbizo+mUvIvGPXn0tYGpzBiLNXQvySTPKNE2SQ26Ug2v3Gw y9J66CxG8y1i/WO9z9tdZXoVagHDlv0iDD67695FuRLhwEZU6MC1abshPe5pn9xcpZzB 5Imw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8qyi2AFFbZIdfMhRcLlTDvB2fgynARKfi3U2nJuo6o8=; b=XHNoHN7z05bgIxLFBtpj0UQ4/TlwYXkI0Trfg6W0Thu/EyKnyVDVQGjBSNffQsJXdU BuJB61EHCd7Z4SvK5E65nSUI+ZbZbkQWBvxyEowue2voSMmaBWPvu+p1nP2IFfRT1piP /j16l+9JT1R+Lk3UmTz2uv7zZ6FTbfsEQZ4wIiK/JL4m2zw5mdP4WCmUe2dcUtkwGwVX hMmHBUSbLu9upqiczt6Gg/YTKJrHe7ZGxW5QdwRRKVtLmhaskI4ICT9htSN4EzyGbfe4 cEOCwJVCksCepDq9Td0goa0WqDZe5py+im+XmS3EvCrpxbqE6NWR1J0pKzzQKevVLYDd UVEQ== X-Gm-Message-State: AOAM532MkJsN4md9b8XuDkdioCDcGFWB+zxxufZQsBmlzUVpphlrSDFJ +LCPW/cXJvV6VTIn74C5NPYKOwTedTjx8B5k X-Google-Smtp-Source: ABdhPJzNQAmXXBGjwr5PE736gOFpRwpN4GUtXw+GgwIzDQFJ5LMBpYbWde6J44IkZ0bTSm7Dsd/zyg== X-Received: by 2002:a02:7b1d:: with SMTP id q29mr392830jac.118.1602618074763; Tue, 13 Oct 2020 12:41:14 -0700 (PDT) Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id e17sm689035ile.60.2020.10.13.12.41.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2020 12:41:13 -0700 (PDT) From: Wesley Eddy To: tcpm@ietf.org References: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Message-ID: <9d420a13-aeca-a434-d079-b9a697fa9073@mti-systems.com> Date: Tue, 13 Oct 2020 15:41:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@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] WGLC for 793bis - REVIEW NEEDED X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 13 Oct 2020 19:41:18 -0000 On 9/25/2020 9:52 AM, mohamed.boucadair@orange.com wrote: > Hi all, > > Wes already addressed my comments in previous versions of the spec. > > Please find some edits/nits/comments: > > * pdf:https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-tcpm-rfc793bis-18-rev%20Med.pdf > * doc:https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-tcpm-rfc793bis-18-rev%20Med.docx > > The document is almost ready to move forward. > > Many thanks to Wes for carrying this important work. Thank you for the detailed comments and corrections.  I've finished working through your suggested changes and had alternate suggestions on a small number of them below.  The remainder are mostly verbatim going into my working copy for the next draft revision, with the exception of some differences in reference styles from XML2RFC that are probably more of an RFC Editor decision on how to properly cite anyways. (1) On adding: "Multipath considerations are out of scope. The reader may refer to [RFC 8684]." How about instead mentioning this later on instead, where we mention congestion control and high-performance extensions, and saying "Multipath considerations for TCP are specified separately in [RFC 8684]." (2)  I like your suggestion of abbreviating three-way handshake to "3WHC".  Before I abbreviate this in a number of places, I wanted to give the list a chance to push back in the event that there's any concern about new acronyms. (3) You raised a question on the text: """ There MUST (MUST-33) be a way for the application to learn how much urgent data remains to be read from the connection, or at least to determine whether or not more urgent data remains to be read. """ Asking "This is local to the implem.  Why the normative language is used?".    This comes from 1122, and I think the intention is that when an application is choosing to use the urgent mechanism and is signaled that there is urgent data, it also needs to be able to figure out when it's read through all of the urgent data and can go back to it's non-urgent mode of handling input. From nobody Wed Oct 14 00:19:27 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4F3A13DC for ; Wed, 14 Oct 2020 00:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 T0ZxgJ8IqvwM for ; Wed, 14 Oct 2020 00:19:25 -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 5DC343A13DB for ; Wed, 14 Oct 2020 00:19:25 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4CB3gv4wkSz5wjg; Wed, 14 Oct 2020 09:19:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602659963; bh=IhBCz5J9EJPAJZ9/ebN/VNYCiXvKM1aeH34as6nOrac=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=uQYlTQt4wfm9e8gfAw/tY96EO9tsEZ97QiozUdEJuQDXP/CiY571LLwIVe+0zuIKc B/k5YdtJvTct3PSpT1UCycwzpjz1SgldZFBePat1iawxXLjZ8ZuN5YegBRpiRsboQr YlsG2Rf5PhsYgFQzQokKPmxGR0nDVAE4cffBGu05Xv0s15vQBDmD6jTUvZkUT+691H 7aIvap1qLYRXPsDdHJLkvZp/e62YplQ1zVPzBBEHM2set/u2RSZxkRywJ+4ztF1Bzk S/y37UWt8mlTskMTY21D76iiQVq2Lnij7sk6AKtCVXpp61oj1Au1XGmCmuAn7V7WqO +hwJJtA0zOcaw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4CB3gv44MLzFpYF; Wed, 14 Oct 2020 09:19:23 +0200 (CEST) From: To: Wesley Eddy , "tcpm@ietf.org" Thread-Topic: [tcpm] WGLC for 793bis - REVIEW NEEDED Thread-Index: AQHWoZjarSnxb+zaVUuvNI65mddUdqmWsEmg Date: Wed, 14 Oct 2020 07:19:23 +0000 Message-ID: <29425_1602659963_5F86A67B_29425_486_1_787AE7BB302AE849A7480A190F8B93303155FD52@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9d420a13-aeca-a434-d079-b9a697fa9073@mti-systems.com> In-Reply-To: <9d420a13-aeca-a434-d079-b9a697fa9073@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.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for 793bis - REVIEW NEEDED X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 14 Oct 2020 07:19:27 -0000 SGkgV2VzLCANCg0KKDEpIGxvb2tzIGdvb2QgdG8gbWUuIA0KDQpGb3IgKDMpLCB5b3UgbWF5IGNv bnNpZGVyIHR3ZWFraW5nIHRoZSB0ZXh0IHNvIHRoYXQgdGhlIHJlY28gaXMgb24gdGhlIFRDUCBp bXBsZW0sIG5vdCB0aGUgYXBwbGljYXRpb24uIA0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1l ZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB0Y3BtIFttYWlsdG86 dGNwbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFdlc2xleSBFZGR5DQo+IEVudm95 w6nCoDogbWFyZGkgMTMgb2N0b2JyZSAyMDIwIDIxOjQxDQo+IMOAwqA6IHRjcG1AaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUmU6IFt0Y3BtXSBXR0xDIGZvciA3OTNiaXMgLSBSRVZJRVcgTkVFREVEDQo+ IA0KPiBPbiA5LzI1LzIwMjAgOTo1MiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3 cm90ZToNCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBXZXMgYWxyZWFkeSBhZGRyZXNzZWQgbXkgY29t bWVudHMgaW4gcHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlDQo+IHNwZWMuDQo+ID4NCj4gPiBQbGVh c2UgZmluZCBzb21lIGVkaXRzL25pdHMvY29tbWVudHM6DQo+ID4NCj4gPiAqDQo+ID4gcGRmOmh0 dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFmdHMtDQo+IFJldmlld3MvYmxvYi9t YXN0ZXIvZHJhZnQNCj4gPiAtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xOC1yZXYlMjBNZWQucGRmDQo+ ID4gKg0KPiA+IGRvYzpodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL0lFVEYtRHJhZnRzLQ0K PiBSZXZpZXdzL3Jhdy9tYXN0ZXIvZHJhZnQtDQo+ID4gaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xOC1y ZXYlMjBNZWQuZG9jeA0KPiA+DQo+ID4gVGhlIGRvY3VtZW50IGlzIGFsbW9zdCByZWFkeSB0byBt b3ZlIGZvcndhcmQuDQo+ID4NCj4gPiBNYW55IHRoYW5rcyB0byBXZXMgZm9yIGNhcnJ5aW5nIHRo aXMgaW1wb3J0YW50IHdvcmsuDQo+IA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQg Y29tbWVudHMgYW5kIGNvcnJlY3Rpb25zLsKgIEkndmUgZmluaXNoZWQNCj4gd29ya2luZyB0aHJv dWdoIHlvdXIgc3VnZ2VzdGVkIGNoYW5nZXMgYW5kIGhhZCBhbHRlcm5hdGUgc3VnZ2VzdGlvbnMN Cj4gb24gYSBzbWFsbCBudW1iZXIgb2YgdGhlbSBiZWxvdy7CoCBUaGUgcmVtYWluZGVyIGFyZSBt b3N0bHkgdmVyYmF0aW0NCj4gZ29pbmcgaW50byBteSB3b3JraW5nIGNvcHkgZm9yIHRoZSBuZXh0 IGRyYWZ0IHJldmlzaW9uLCB3aXRoIHRoZQ0KPiBleGNlcHRpb24gb2Ygc29tZSBkaWZmZXJlbmNl cyBpbiByZWZlcmVuY2Ugc3R5bGVzIGZyb20gWE1MMlJGQyB0aGF0DQo+IGFyZSBwcm9iYWJseSBt b3JlIG9mIGFuIFJGQyBFZGl0b3IgZGVjaXNpb24gb24gaG93IHRvIHByb3Blcmx5IGNpdGUNCj4g YW55d2F5cy4NCj4gDQo+IA0KPiAoMSkgT24gYWRkaW5nOg0KPiANCj4gIk11bHRpcGF0aCBjb25z aWRlcmF0aW9ucyBhcmUgb3V0IG9mIHNjb3BlLiBUaGUgcmVhZGVyIG1heSByZWZlciB0bw0KPiBb UkZDIDg2ODRdLiINCj4gDQo+IEhvdyBhYm91dCBpbnN0ZWFkIG1lbnRpb25pbmcgdGhpcyBsYXRl ciBvbiBpbnN0ZWFkLCB3aGVyZSB3ZSBtZW50aW9uDQo+IGNvbmdlc3Rpb24gY29udHJvbCBhbmQg aGlnaC1wZXJmb3JtYW5jZSBleHRlbnNpb25zLCBhbmQgc2F5aW5nDQo+ICJNdWx0aXBhdGggY29u c2lkZXJhdGlvbnMgZm9yIFRDUCBhcmUgc3BlY2lmaWVkIHNlcGFyYXRlbHkgaW4gW1JGQw0KPiA4 Njg0XS4iDQo+IA0KPiANCj4gKDIpwqAgSSBsaWtlIHlvdXIgc3VnZ2VzdGlvbiBvZiBhYmJyZXZp YXRpbmcgdGhyZWUtd2F5IGhhbmRzaGFrZSB0bw0KPiAiM1dIQyIuwqAgQmVmb3JlIEkgYWJicmV2 aWF0ZSB0aGlzIGluIGEgbnVtYmVyIG9mIHBsYWNlcywgSSB3YW50ZWQgdG8NCj4gZ2l2ZSB0aGUg bGlzdCBhIGNoYW5jZSB0byBwdXNoIGJhY2sgaW4gdGhlIGV2ZW50IHRoYXQgdGhlcmUncyBhbnkN Cj4gY29uY2VybiBhYm91dCBuZXcgYWNyb255bXMuDQo+IA0KPiANCj4gKDMpIFlvdSByYWlzZWQg YSBxdWVzdGlvbiBvbiB0aGUgdGV4dDoNCj4gDQo+ICIiIg0KPiANCj4gVGhlcmUgTVVTVCAoTVVT VC0zMykgYmUgYSB3YXkgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBsZWFybiBob3cgbXVjaA0KPiB1 cmdlbnQgZGF0YSByZW1haW5zIHRvIGJlIHJlYWQgZnJvbSB0aGUgY29ubmVjdGlvbiwgb3IgYXQg bGVhc3QgdG8NCj4gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IG1vcmUgdXJnZW50IGRhdGEgcmVt YWlucyB0byBiZSByZWFkLg0KPiANCj4gIiIiDQo+IA0KPiBBc2tpbmcgIlRoaXMgaXMgbG9jYWwg dG8gdGhlIGltcGxlbS7CoCBXaHkgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpcw0KPiB1c2VkPyIu wqDCoMKgIFRoaXMgY29tZXMgZnJvbSAxMTIyLCBhbmQgSSB0aGluayB0aGUgaW50ZW50aW9uIGlz IHRoYXQNCj4gd2hlbiBhbiBhcHBsaWNhdGlvbiBpcyBjaG9vc2luZyB0byB1c2UgdGhlIHVyZ2Vu dCBtZWNoYW5pc20gYW5kIGlzDQo+IHNpZ25hbGVkIHRoYXQgdGhlcmUgaXMgdXJnZW50IGRhdGEs IGl0IGFsc28gbmVlZHMgdG8gYmUgYWJsZSB0bw0KPiBmaWd1cmUgb3V0IHdoZW4gaXQncyByZWFk IHRocm91Z2ggYWxsIG9mIHRoZSB1cmdlbnQgZGF0YSBhbmQgY2FuIGdvDQo+IGJhY2sgdG8gaXQn cyBub24tdXJnZW50IG1vZGUgb2YgaGFuZGxpbmcgaW5wdXQuDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxp c3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RjcG0NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Oct 14 08:59:24 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAD83A0F5D for ; Wed, 14 Oct 2020 08:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 zCBx57mYC1fs for ; Wed, 14 Oct 2020 08:59:21 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4CC383A0F75 for ; Wed, 14 Oct 2020 08:59:15 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id dn5so3666989edb.10 for ; Wed, 14 Oct 2020 08:59:15 -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=zufheUBDJVi87JIBrlQV8ur73mBP0adREy8f9yqKX8I=; b=CTJDDt4tatOaQwiJT43cSAOGOdcGiMTtLIaLj/h1quc/jWTSAUIEGbODpO1ihsFwDG axPRXs47YUGn2PQw3O3FGLfhFSzv/riDDDcRItyGfjKQWmBpkLwnj/Wn+J9LDpDfaacM RU8ni+KFtQRntVhpjbFhBc6nFdQBIz1td/Ff3Wbeis2+dUJbUMNSJamgt6SFATZTU5Ph NGVbqxkXTGvEFjvrYQchxkNzp/3xifzTQSiJixjFm21vOPoBAnq+pdOUuIUyacJD00fT uda8HcjcoN2g4ZxP+Exe5eN0pKrM/0+dR067tQ6i/crWHQ+aJitLuraz5kplOGTpofIZ lcGA== 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=zufheUBDJVi87JIBrlQV8ur73mBP0adREy8f9yqKX8I=; b=TwZi223r3bPl2n7fFo0q/diiROXmT6YBBCGz4QQLK+4TDFDKLu7IEFv8JDhfo7hhYl gH4CZ652ssOCqlQ8SOUYN0uCb7vqxLSrNIBq2UJYCjXLW2NXpcQk6ugzDSJr1SYgqo4X qblDqXIYjq5A20IzDScBKy2v9Kd3qNk8Zfz7bseODTN0vO4OzQW3lRTlka/0e5gzjAI9 fPTDfssA6FMUgGaCke15j+F5f5b06Eax5HeebJkVB8OCoOHp+xyIHLNMH+tWwWxcvgJc V8KSZArB3XL59hfDjEqlWnzh6qih4DKY+mwibFC0rbYLR9qF/5bjf3TspVQesKDKEpBO X/oQ== X-Gm-Message-State: AOAM533WN/Yq4etz+CXjZZDxbC7cUr+4dYoxlk+Wr7M0snlAjRJ2GYnI HLQK8WvQqLKJHVn3k6E4FFkDV3KG9FoaHgUZ8fo= X-Google-Smtp-Source: ABdhPJw3J7gLuSmLCCEkbzcEKTvUoSG53a3qL4lfX4XxgWa20kY0NEOWur+IVkCBw2eQT+iKMDb6JUuq2KsGP7kWMOs= X-Received: by 2002:a05:6402:7c8:: with SMTP id u8mr6111948edy.153.1602691153645; Wed, 14 Oct 2020 08:59:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Wed, 14 Oct 2020 21:29:02 +0530 Message-ID: To: Wesley Eddy Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] WGLC for 793bis - Review comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 15:59:23 -0000 Please find my comments inline. > > > Section 3.5.1: ... an application that has called CLOSE cannot > > continue to read data from the connection (MAY-1). > > [RJ] shouldn't this be that "an application that has called CLOSE > > _can_ continue to read data from the connection (MAY-1)"? ... Again I > > suppose it's a typo but want to make sure. > > This is in reference to the peculiar "half-duplex" implementation option > for the CLOSE sequence. The first paragraph of this section discusses > the normal "full-duplex" option, and this second paragraph covers the > half-duplex option. So, this is actually correct as-written. The RFC > 2525 reference mentioned at the end of the section is clear on this. > > > Section 3.5.1: See [18] section 2.17 for discussion. > > [RJ] This reference is broken since section 2.17 no more exists. > > It is actually RFC 2525 Section 2.17 (not section 2.17 of 793bis) that > is referenced here. The autogenerated hyperlink doesn't seem to > understand that, but it's clear from the text at least. After reading Section 2.17 of RFC 2525, the text was clear to me. > > > Section 2.1: ... with each TCP segment sent as an Internet Protocol > > (IP) datagram. > > [RJ] Even though recommended, it isn't necessary that each TCP segment > > be sent as a single IP datagram. > > Hmmm, this I don't know about. Are you thinking of IP fragmentation? [RJ] Yep, I had IP fragmentation in mind. > > > Section 2.1: Anycast applications exist that successfully use TCP > > without modifications, though there is some risk of instability due to > > changes of lower-layer forwarding behavior. > > [RJ] A ref would help. > > I think we can add a reference to RFC 7094 here to the document. > > https://tools.ietf.org/html/rfc7094 [RJ] Yes, this helps and I assume you are referring to Section 4.2 of RFC 7094. From nobody Wed Oct 14 10:39:06 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98B3A0A13 for ; Wed, 14 Oct 2020 10:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, 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 OMajVe4Cxy8x for ; Wed, 14 Oct 2020 10:39:02 -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 0C6A53A0A25 for ; Wed, 14 Oct 2020 10:39:01 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id l8so6254318ioh.11 for ; Wed, 14 Oct 2020 10:39: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=eHrczXyp4+KPxF5gwLErsuDX4GiMs5r0APRKizSbz5w=; b=KHSb6CcPWA/kqfWNhr7w2GTpyt4GMGDo1ddUbY4+d99XOMnjacsRXE5i667PQJLVJw BSlyGXbzeSdQpGCB/IBuS6Zdp3u4ushbkI2nh2VckGb3c0LxqSo3zqlXT3JNGu8v0GfO xNSRM4lBUw+zv00BGd3/M63g4OyAB/UKfV6pMesUHOqMR6rmxtbyaLjMH2JDHGfCpwKn AgXPQXU0Kid2sIvxAjL/zlbR5eRytYSwustgmBplNVJa6lL4wrtU4a5InDKfDfbSUGjK HnJbLrMTS1Rlz5J4DcVUoooZ1eu2vWOa1cDDa6Uz+Ih9so2EOk27LF6yykdUEYCJFlA/ Pt2Q== 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=eHrczXyp4+KPxF5gwLErsuDX4GiMs5r0APRKizSbz5w=; b=tt1reKpRMChqbXCXXCTPQCV8uMj4ZiBVr3Ydms3GXVS/nh7gv06ReQSymuwH1hbtXG yRzseW+bqm2e42y2BFM3btpKuNL1VBV9EDfawf6TGtsNkasRWolbUkgxsXye9YiEK3k0 bv9g72myWBdkyIsSQWHC2f0cXN67/jgWKmMY0HWmGn3ndK4hJYrZf+JJgjw4RqoSiS0D zc8BTUwMxfSXVZSfxfNJbXr/Wjpkm0/0WQWYfE7o2GBwnDMJN2AttWJgfJ1u3CwxAxNw HGT2zUK2NkUsi1/ZD/ON0CpLqBQJepvpGUaS+AhubC5gUD7XVLG+JRhX6TwqkRRWhlwH CCzw== X-Gm-Message-State: AOAM5313mdtixnQd6gYPPHyhBitmf2vrbpd/SEraZiFt9PBYm45lgEg3 sjgWs9kyyJ6ByHDqppxWfDvi3ug2zGyIVxRg X-Google-Smtp-Source: ABdhPJxNP+JxWxV/pKOt41qNgT3TzMvQOwy8kP+SDrH2MFS4nhKGcSHp+yAxmL39udGp/LrBficC3g== X-Received: by 2002:a6b:9046:: with SMTP id s67mr397893iod.8.1602697140783; Wed, 14 Oct 2020 10:39:00 -0700 (PDT) Received: from [192.168.1.114] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id v78sm36526ilk.20.2020.10.14.10.38.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 10:39:00 -0700 (PDT) To: Rahul Jadhav Cc: "tcpm@ietf.org Extensions" References: From: Wesley Eddy Message-ID: Date: Wed, 14 Oct 2020 13:38:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------69DD97AF02CDD8F196AAA877" Content-Language: en-US Archived-At: Subject: Re: [tcpm] WGLC for 793bis - Review comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 17:39:04 -0000 This is a multi-part message in MIME format. --------------69DD97AF02CDD8F196AAA877 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/14/2020 11:59 AM, Rahul Jadhav wrote: >>> Section 2.1: ... with each TCP segment sent as an Internet Protocol >>> (IP) datagram. >>> [RJ] Even though recommended, it isn't necessary that each TCP segment >>> be sent as a single IP datagram. >> Hmmm, this I don't know about. Are you thinking of IP fragmentation? > [RJ] Yep, I had IP fragmentation in mind. In this case, the segment still is contained in a single datagram before fragmentation and following reassembly, which are the points that the TCP implementation sees it. If people think it is somehow needs to be more clear, we could append some statement like "that may or may not be fragmented by IP", but personally I think this is distracting and not technically needed since the statement is true of any IP packet. --------------69DD97AF02CDD8F196AAA877 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 10/14/2020 11:59 AM, Rahul Jadhav wrote:
Section 2.1: ... with each TCP segment sent as an Internet Protocol
(IP) datagram.
[RJ] Even though recommended, it isn't necessary that each TCP segment
be sent as a single IP datagram.

Hmmm, this I don't know about.  Are you thinking of IP fragmentation?

[RJ] Yep, I had IP fragmentation in mind.

In this case, the segment still is contained in a single datagram before fragmentation and following reassembly, which are the points that the TCP implementation sees it.

If people think it is somehow needs to be more clear, we could append some statement like "that may or may not be fragmented by IP", but personally I think this is distracting and not technically needed since the statement is true of any IP packet.
--------------69DD97AF02CDD8F196AAA877-- From nobody Wed Oct 14 14:17:16 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA5F3A1094 for ; Wed, 14 Oct 2020 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, 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 iV3NjQSjU9PZ for ; Wed, 14 Oct 2020 14:17:13 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 6F8403A1091 for ; Wed, 14 Oct 2020 14:17:13 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id q1so1249874ilt.6 for ; Wed, 14 Oct 2020 14:17:13 -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=3s4hw+Z/AAsqwhEki4QQTuIlo8F30FX6zS4yFjuKb+U=; b=fYEFqOj/uZ924tpVKssjRN8z4ChyDO8x5L4r4l76xKYdT0a8NLJqD42jbl8q+xTbkP c3zTVYBAAjIusAfKB0oZYwdCcNzOaljej7hpt0z4Df7agmtf9+lAh/aTzn5wM8TIWfOE DpUdaaKm8Qwr9aFBzlC9Sf7iPcD5Pt3/QkEqsVEk9Gm+ehLHWk3n0Z9FPvwvPQxOd410 jH3LmCHavVQeA69F7MxAwqpE19PM3V3b4lfb/WzP0MD+ZovwL0rqncPIBQP1qjScIuQ9 ApN+ObLZVKSv3Pf2h83Yc+gGsIKzoTzw8nxs8icdbmhY4U5WfkkhJez88ITQLf92tBY+ +UKw== 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=3s4hw+Z/AAsqwhEki4QQTuIlo8F30FX6zS4yFjuKb+U=; b=Kx9kqYIYJW8KTeOpmtfx5CuFOX+TJvHVfXh8YQf1Nr7kUUeG9Cj6+P3WBCThAfQXxh 7kYnSVbcaLlCwzXEiBnYy2CBtkkPJnLp1TIUjQCMRnGgY0IorLOl9fsGZcQQEUBKcq60 N9joyrSkXVekP4riFTjljYMIoIU9aK5bfUWxwMik4n/ghH7+EAUBp8qk0lOWH8mq9oLI z8OMeyOkAprsOHvPKRIOZFUO9dvg0/uRfr38dHlKrtnmYJivIWeg22Xkuj6JdfyGCG8j pYC5wjMd7RgBVZfuz9bfIZbCHnhdg4E5fOWoUlFgXBw+CIIcB3B4XfvXyeBysYbW8qiC J0JA== X-Gm-Message-State: AOAM531AGmbg5KHwNv8YajQFi9u6HF8pfN1JCMghFDLvUKkc5ZDl7pJn LWbS/qL/ZjBYhLEVHE3v33yOUEIcUknjgWuw X-Google-Smtp-Source: ABdhPJxH9nrfPhaDNkzSMcFHskbb6iOs5eRQ55ptVMtO61TswYydiHk8ZljTDUdgl52BMyF/SM2Ejw== X-Received: by 2002:a92:85d5:: with SMTP id f204mr956485ilh.108.1602710231978; Wed, 14 Oct 2020 14:17:11 -0700 (PDT) Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id d14sm514771ilo.72.2020.10.14.14.17.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 14:17:10 -0700 (PDT) To: mohamed.boucadair@orange.com, "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9d420a13-aeca-a434-d079-b9a697fa9073@mti-systems.com> <29425_1602659963_5F86A67B_29425_486_1_787AE7BB302AE849A7480A190F8B93303155FD52@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Wesley Eddy Message-ID: <23cf0ef2-9516-5c74-1094-b49bee7d2e6b@mti-systems.com> Date: Wed, 14 Oct 2020 17:17:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <29425_1602659963_5F86A67B_29425_486_1_787AE7BB302AE849A7480A190F8B93303155FD52@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] WGLC for 793bis - REVIEW NEEDED X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 14 Oct 2020 21:17:15 -0000 On 10/14/2020 3:19 AM, mohamed.boucadair@orange.com wrote: > Hi Wes, > > (1) looks good to me. > > For (3), you may consider tweaking the text so that the reco is on the TCP implem, not the application. That makes sense.  In the working copy, I've changed the beginning of the sentence from: There MUST (MUST-33) be a way for the application to learn how much urgent data remains to be read from the connection, or at least to determine whether or not more urgent data remains to be read. to: The TCP implementation MUST (MUST-33) provide a way for the application to ... I think that addresses your point. From nobody Thu Oct 15 18:09:34 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5AD3A0D4F for ; Thu, 15 Oct 2020 18:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrllRogFwl1B for ; Thu, 15 Oct 2020 18:09:31 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78AB3A0CEC for ; Thu, 15 Oct 2020 18:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wJwz8mDIPzEm6B7pAbxWnyVyuVlSkCWUoXEtMIsBRwY=; b=KMC1CzWcwxUK/bbkn3GcU4TP6 IhaBw6YNelsVXNOMQpQthogosl2Ij96RglGHXnJpvqsZwJgh5lP/Qw6vxxobNjinrhR0gYrUFN/vX Hjq3KbvJs05hE1Z8NWDQZgNhfafBjoIdR8T7zOiIbjk4TaHDeo3k7ELMK4luxaD9oo4dEv1/BtcWq x8tdH/9aKuNPTdiKb+sUb8G+jerpd490B4eD4NlJuwdNeH81E8hhEgnU0MAisS6N1QdoQHVYIlRV6 M/HHHLv+2V0UnzqYyPIGuXEg7pCpUgRxuqWeZAZWa15TEJcXLNncPEhu0guffa0bD+YIK1MjoPm0l oCT2xnp6g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64950 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kTEFK-001WH0-PC; Thu, 15 Oct 2020 21:09:31 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <9d420a13-aeca-a434-d079-b9a697fa9073@mti-systems.com> Date: Thu, 15 Oct 2020 18:09:25 -0700 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7FBD3992-3BD1-4154-BAF5-97361BD78BCF@strayalpha.com> References: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9d420a13-aeca-a434-d079-b9a697fa9073@mti-systems.com> To: Wes Eddy X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] WGLC for 793bis - REVIEW NEEDED X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Oct 2020 01:09:33 -0000 Hi, all, > On Oct 13, 2020, at 12:41 PM, Wesley Eddy wrote: > ... > (2) I like your suggestion of abbreviating three-way handshake to = "3WHC".=20 Did you mean the more common =E2=80=9C3WHS=E2=80=9D? If not, what does the C stand for? Joe= From nobody Thu Oct 15 18:49:04 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EAD3A0E29 for ; Thu, 15 Oct 2020 18:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, 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 wN7pPFKdPEyw for ; Thu, 15 Oct 2020 18:49:01 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 96E763A0E1B for ; Thu, 15 Oct 2020 18:49:01 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id l16so832422ilt.13 for ; Thu, 15 Oct 2020 18:49: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-transfer-encoding:content-language; bh=RkpuLaIHO6Tr2M57HZNLVPR8Z26q4B3nB71qQkRsx4Y=; b=n992IVorfkcyRfySY3SV5YlYJOi6obxuPVed2bnLAUh/7uxIPe7RBHWXmGtVhqsFQO AypOrmZxfaq6prv+kMpR2mQnmukwB/FvDAGGyxDid9MlfUDfSgNnEj73YqPlYewc1lkz CwkI/UI3j57Ggevwq1xLFpkmZhheh7UB2Yto4jLgQq2F46Czx2XZbmOjmu6VSTRz7qxo u5ilo/zqoOnMahwoIF1DcYJ2uh/rqByFihdqiJ+7FV6Z6berf5NiyYmKXc/slxQo0Usi FOj+geE16qInrHp4HA2wMYUq4mkfmUGRqVrLMhAJNgaP5LgJo8v9AAVmmUYwcq97CmK0 rUEw== 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=RkpuLaIHO6Tr2M57HZNLVPR8Z26q4B3nB71qQkRsx4Y=; b=E6xO0X3Ey0+LLlK0o1O6vW+cE6z9hddXotkT4/CF6H3CcB27rTU4246S6+PR4GsPkT ex3mgcwK44X6/tOlgRFW5xrOu6Nvr1Yz9/ESfunR/ubypWpGgqTwGca7BZUjpXitoAvM mqWcmywTc7DaNbF5XzD28slV00aH3kLcJagAZByTSEli3MSgsa1FN0WEwzYLUqBuYrTV x5/dkwIx5hgAXyzeFGbGwx3L+gyEbcb8VPXPM49HLj5K/kkB/HqIL83ulKyuIOnz0+de bIdWI6iDeNLpULFCHvde8WCzzEUuzD/MmOtSmMba+doNIl6OaMp0OXHXbuc8i5jevAVK t0Xw== X-Gm-Message-State: AOAM533MKnZ058pZfNgUeDMYCXXLTbVn7cNvYP2MrVhukairIMER48Kg gSEJdcGIU4QTPuogD5wpWUCopvISha2TcZps X-Google-Smtp-Source: ABdhPJy3GnrQFTGyPGSFXOcJ2DYGPW+UbZ5p+PdwfztGWorcaATNJfbZtGN394ruRMNiXCqYd57FAQ== X-Received: by 2002:a05:6e02:c6:: with SMTP id r6mr979273ilq.184.1602812940568; Thu, 15 Oct 2020 18:49:00 -0700 (PDT) Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id f85sm821477ill.39.2020.10.15.18.48.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2020 18:48:59 -0700 (PDT) To: Joseph Touch Cc: tcpm@ietf.org References: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9d420a13-aeca-a434-d079-b9a697fa9073@mti-systems.com> <7FBD3992-3BD1-4154-BAF5-97361BD78BCF@strayalpha.com> From: Wesley Eddy Message-ID: Date: Thu, 15 Oct 2020 21:48:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <7FBD3992-3BD1-4154-BAF5-97361BD78BCF@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] WGLC for 793bis - REVIEW NEEDED X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Oct 2020 01:49:03 -0000 On 10/15/2020 9:09 PM, Joseph Touch wrote: > Hi, all, > >> On Oct 13, 2020, at 12:41 PM, Wesley Eddy wrote: >> ... >> (2) I like your suggestion of abbreviating three-way handshake to "3WHC". > Did you mean the more common “3WHS”? Yes, I mistyped.  Sorry! From nobody Thu Oct 15 18:54:57 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1A53A0E53 for ; Thu, 15 Oct 2020 18:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QGwNE9xReocE for ; Thu, 15 Oct 2020 18:54:53 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 24E973A0E4F for ; Thu, 15 Oct 2020 18:54:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A6HXDQ9Rcm0CzqpKXj0ePLSN0JiIkTRDwpHn/ZtqjpeNKvPKpuK3M2LpXomHwAnLMoTiLDbG1nT7r6m3FBY2vKDK3F92SPOSy0CLCrX7wP187ybjx4TaN3q7am4bKc3917gZy00ur8I0qQ8Ci2T6qreiRs/VDs9vRpcJAebIwQP6SrmBr9f3HW9LBrOs/gglpca94+lHqYR314kSbS6iSJZJ7BEKBVWwABoFudi7vBTB52zCnJvaatPNIS9IznDe26Tm6fBY25hFQ2+VRIjhbu1d+YyD3CN2mmJhbWko2/auklq3dDFIvOGmsTa+a6ITrIwKdPGkbX8NLoivW+GUCQ== 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=JU0oxFVEjCM4ziJukOhGXm5Jw/d3ob9UfJXLgHDC/ww=; b=BYnYHjPPiMpkpIxP8hF0UE3UXd4jFdxO+Sik+BjPOEOU25ujcbEplg1Ye0f6XMbPg2/xGg3U0CImybah/UrCjs27XMBHGqvjtC/h+UzJ/La6ZWUEvSJ2UaIBKF8D1mLdyM46EhIJKCJ1Asr2W7bVrat+hHsGwHyTMc1B/3UKAdhQfke9pv73NMDERY4lg6DiNpibsrjK4qsfnj/Nj7HmJWqypmMcQ1N1vhVf8/n24nsSAiUZJt9cWnT+ExpQ5QXcqaiH/e6cp4SMj6IPdwY+X3tbjDgUh4+7zImtpP2uIRcw172tO9J8buK7erjE52khS2HRNRVcPY1Iyk3rxaXUUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JU0oxFVEjCM4ziJukOhGXm5Jw/d3ob9UfJXLgHDC/ww=; b=dJEAHEZGA6b+AnIvRJY+x0xh1n7kLEr8PqBSA+zy6jmUZee1xuXJEuUT+AwbLDSefMKDxLdickDuvdhMl/1E2iv2WtZgMeTHIise6bMgi7XN1oTCSPh56E3+qRnMXg+tMD3fjUCRl3/lee0A80XYdt67vlopZLiQpvkD1VoAMm4= Received: from (2603:10b6:610:ad::14) by CH2PR00MB0843.namprd00.prod.outlook.com (2603:10b6:610:6f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3521.0; Fri, 16 Oct 2020 01:54:44 +0000 Received: from CH2PR00MB0728.namprd00.prod.outlook.com ([fe80::8a2:e6a:54f5:d662]) by CH2PR00MB0728.namprd00.prod.outlook.com ([fe80::8a2:e6a:54f5:d662%8]) with mapi id 15.20.3521.000; Fri, 16 Oct 2020 01:54:44 +0000 From: Praveen Balasubramanian To: "tcpm@ietf.org" Thread-Topic: WGLC review of draft-ietf-tcpm-rfc793bis-18 Thread-Index: AdajXxk8uequbu29QB+n5DRBKHdcew== Date: Fri, 16 Oct 2020 01:54:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=366faa20-1224-4122-9110-1f261cdafb59; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-16T01:15:52Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:a:95ce:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d65344f6-41d5-4aa0-7aba-08d871767433 x-ms-traffictypediagnostic: CH2PR00MB0843: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wqZbojkTjE7Yq8Q6czWMsEfMLzcgNyldqJYGeQBoYfriaWQCIvFWUq2cmBC2qWd6om/RiLZfDo0JLUO+hSsJp2oNzIxT80meAJEBBFQCUNyFBLuhF/btTM9w7ZigVYyzizp9SddNI6xAdikpfTjitW5EeXyEQe7D+cxJ0LQ+6ALXHxrgNGR1698FgKpGdY0zcOQ69FzrNNqPYo8sx3wfJSlmQOQdBoQxMzqHY5mN41+20sp/r7JuTw5PNBVV9fiQtEFe6jFt5r4khg1FpUWuwyIum9EN4eZxvsm4k2K32pA5j4wz+qmlyVrjpyhbh6MEIm3QGEjhDaOj8jODkanV8Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0728.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(54906003)(52536014)(107886003)(316002)(83380400001)(8990500004)(2906002)(10290500003)(66446008)(66556008)(64756008)(33656002)(66476007)(66946007)(76116006)(6506007)(71200400001)(8676002)(55016002)(9686003)(8936002)(478600001)(6916009)(186003)(5660300002)(86362001)(7696005)(82950400001)(4326008)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Kr6nu2YaqxorDxsbt2ogfG7vH3H+7zbb6CMJ6/QfIHy8Hi5O60RCUiWVwHN8Oncz+WecnFndOtt4IftCtqNNLZOi8qfyVqwgba92KZdP0MyPmhcrxmSUY12+UpcgNSw1pFN1TecoGjv3I0C1uIVJuM+5mcUPpGexbdi2nDlSq1f4ePnO+DmG1E/M/pUI+aTTLdtNiYOzZgw06HaIL9ABgbDn0wEVjQOXgfDb34o6l8q0kpVRsA4+C/XOCSmXcaf/R3KG+khnP6rYNQA4kdePsQZ/SUOc8KV8EmxcDil/QIVAUaMvQQ13nkmZUaHmR8RX+HPB2kC27+5g+TmEqKXopoQfrb1+s0layxWG+qJkzvCkf4jA47NN01yDOxjjSJyuBRpQDKBA1R2UJPqnhLegkWP4CC+lmyJwO7+4jLlv108D6hoAL1pLlI6jL48PLhwui2OhBeVnUqnioV+RcFMk6xvsvLYRSUbk9yNT0PwHMyTlHyse2sGJEy6Kk2xL+pAWlkyG7GrD0RkbUYXjbYqH0fMUVctN88/qKmxxCPgINpve99k0uUAyQBKwq59z57xvNp3PyZ5WqJV3HTcuu1Y+yFyN6LyYxnwHzRI02FGJrJG9NFT1kxS9FsW8aCASe80C1R4V+Re9S76A6FoJwFrWg1pNSJOwMH5ySBwZKM5TEpG0EYVkMA+YQ44YecrG/akcSgHPIay6rIclx2AmvTGqsQ== Content-Type: multipart/alternative; boundary="_000_CH2PR00MB072885B6E3337415A0F4EFB1B6031CH2PR00MB0728namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0728.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d65344f6-41d5-4aa0-7aba-08d871767433 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 01:54:43.8592 (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: KAvRWaFGACttJO6b52Jr82JZ1VG8s6bo2e9ojpgOEkVUuwB/yZDLF3fCHyl9PExhjdzYsrm0YI2R2/AIS6O8683JwS01AhwlsPMjdh+8i7A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0843 Archived-At: Subject: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Oct 2020 01:54:56 -0000 --_000_CH2PR00MB072885B6E3337415A0F4EFB1B6031CH2PR00MB0728namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following is a WGLC review of draft-ietf-tcpm-rfc793bis-18 by Matt, Yi, and= myself. Section 3.1 The control bits in the header include the RFC 3168 specified CWR and ECE. = It might be worth citing 3168 as well in the Abstract. It is quite a bit surprising that we don't include discussion of the SACK, = Timestamp, and Window Scaling options. Even if we don't describe the detail= s, the document should provide references to these almost universally deplo= yed options and recommend that hosts SHOULD implement them. At least the Ti= mestamp option is referred to multiple times in the text without any specif= ication of the format. Section 3.6.4 " If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the sending TCP endpoint buffers all user data (regardless of the PSH bit), until the outstanding data has been acknowledged or until the TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes). " This is slightly different from Nagle's description in RFC 896: " The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unacknowledged. " I.e., the original algorithm description in RFC 896 didn't include the "or = if a full-sized packet can be sent" part. This difference isn't mentioned i= n 793bis, it ought to be, along with a justification for the difference. Al= so there is no mention of the interaction problem between Nagle's algorithm= and delayed ACKs, either here or in the later section on delayed ACKs. Section 3.7.3 "However, the values of R1 and R2 may be different for SYN and data segments. In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes. The application can close the connection (i.e., give up on the open attempt) sooner, of course. " The MUST here is onerous for what is an ancient timeout value which modern = implementations don't adhere to. Recommend changing this to a SHOULD. Section 3.7.4 "Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval (MUST-26). " It's important to call out an additional condition - that sends are not alr= eady outstanding. When a send is outstanding, it is retransmitted and serve= s as an implicit liveness check. Section 3.7.2 "A TCP endpoint MUST implement RFC 5681 (MUST-19)." This requirement is onerous because RFC 5681 also specifies the NewReno con= gestion control algorithms. Modern implementations use other algorithms. We= should add clarifying text permitting experimentation and evolution of con= gestion control algorithms. It is also not required for interop. Editorial comments: " 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). " should be "not work". " Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is be possible for a TCP implementation to maintain a zero receive window while transmitting data and receiving ACKs. " Remove the "be". " The "Quiet Time" concept discussed below addresses this and the discussion of it is included for situations where it might be relevant, although it is not felt to be necessary in most current implementations. The problem have been more relevant earlier in the history of TCP. " The problem was more relevant " It is tempting for a TCP implementation to want to advertise the largest possible MSS " Remove "want to". "The TCP implementation will signal a user, even if no RECEIVEs are outstanding, that the remote peer has closed, so the user can terminate his side gracefully. " "The user may CLOSE the connection at any time on his own initiative " Suggestion to be gender neutral in the text. " For IPv4, RFC 1122 provides an IP-layer recommendation on the default effective MTU for sending to be less than or equal to 576 for destinations not directly connected. " Should at least be "recommendation for", but consider changing to something= more concise like "For IPv4, RFC 1122 recommends an IP-layer default effec= tive MTU less than or equal to 576 for destinations not directly connected.= " --_000_CH2PR00MB072885B6E3337415A0F4EFB1B6031CH2PR00MB0728namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following is a WGLC rev= iew of draft-ietf-tcpm-rfc793bis-18 by Matt, Yi, and myself.

 

 

Section 3.1<= /span>

The control bits in the= header include the RFC 3168 specified CWR and ECE. It might be worth citin= g 3168 as well in the Abstract.

 

It is quite a bit surpr= ising that we don't include discussion of the SACK, Timestamp, and Window S= caling options. Even if we don't describe the details, the document should = provide references to these almost universally deployed options and recommend that hosts SHOULD implement them. At least = the Timestamp option is referred to multiple times in the text without any = specification of the format.

 

Section 3.6.4

"

   If there i= s unacknowledged data (i.e., SND.NXT > SND.UNA), then the

   sending TC= P endpoint buffers all user data (regardless of the PSH

   bit), unti= l the outstanding data has been acknowledged or until the=

   TCP endpoi= nt can send a full-sized segment (Eff.snd.MSS bytes).

"

This is slightly differ= ent from Nagle's description in RFC 896:

"

The solution is to inhi= bit the sending of new TCP  segments  when

new  outgoing &nbs= p;data  arrives  from  the  user  if  any pre= viously

transmitted data on the= connection remains unacknowledged.

"

I.e., the original algo= rithm description in RFC 896 didn't include the "or if a full-sized pa= cket can be sent" part. This difference isn't mentioned in 793bis, it = ought to be, along with a justification for the difference. Also there is no mention of the interaction problem between Na= gle's algorithm and delayed ACKs, either here or in the later section on de= layed ACKs.

 

 

Section 3.7.3

 

“However, the val= ues of R1 and R2 may be different for SYN

    = ;        and data segments.  In par= ticular, R2 for a SYN segment MUST

    = ;        be set large enough to provide = retransmission of the segment

    = ;        for at least 3 minutes.  T= he application can close the

    = ;        connection (i.e., give up on th= e open attempt) sooner, of

    = ;        course.

“

The MUST here is onerou= s for what is an ancient timeout value which modern implementations donR= 17;t adhere to. Recommend changing this to a SHOULD.

 

Section 3.7.4

“Keep-alive packets MUST only be sent when no data or ack= nowledgement

   packets have been received for the connection with= in an interval

   (MUST-26).

“

It’s important to= call out an additional condition – that sends are not already outsta= nding. When a send is outstanding, it is retransmitted and serves as an imp= licit liveness check.

 

Section 3.7.2

 

“A TCP endpoint MUST implement RFC 5681 (MU= ST-19).”

This requirement is onerous because RFC 5681 also sp= ecifies the NewReno congestion control algorithms. Modern implementations u= se other algorithms. We should add clarifying text permitting experimentati= on and evolution of congestion control algorithms. It is also not required for interop.  

 

 

 

 

Editorial comments:<= o:p>

 

" 

     The w=
indow size MUST be treated as an unsigned number, or else
     large=
 window sizes will appear like negative windows and TCP will
     no=
w work (MUST-1).

"

should be "not wor= k".

 

" 

Note that when the receiv=
e window is zero no segments should be
   acceptable e=
xcept ACK segments.  Thus, it is be possible for a TCP
   implementati=
on to maintain a zero receive window while transmitting
   data and rec=
eiving ACKs.

"


Remove the "be&quo=
t;.


 


" 


The "Quiet Time"=
; concept discussed below addresses this and the


   discussion o=
f it is included for situations where it might be


   relevant, al=
though it is not felt to be necessary in most current


   implementati=
ons.  The problem have been more relevant earlier in the=



   history of T=
CP. 


"


The problem was m=
ore relevant


 =



" 


It is

   tempting for=
 a TCP implementation to want to advertise the largest

   possible MSS=



"=



Remove "want to&quo=
t;.


 


“The TCP implementation will signal a

   user, even if no RECEIVEs are outstanding, that th=
e remote peer has


   closed, so the user can terminate his side gracefu=
lly.


“


“The user may CLOSE the connection at any time on his own=



         initiative


“


Suggestion to be gender neutral in the text. 


 


" 


For IPv4, RFC 1122 provid=
es an IP-layer recommendation


   on the defau=
lt effective MTU for sending to be less than or equal to<=
/pre>

   576 for dest=
inations not directly connected.


"=



Should at least be "=
;recommendation for", but consider changing to something more concise =
like "For IPv4, RFC 1122 recommends an IP-layer default effective MTU =
less than or equal to 576 for destinations not directly
 connected."


 
--_000_CH2PR00MB072885B6E3337415A0F4EFB1B6031CH2PR00MB0728namp_-- From nobody Thu Oct 15 19:07:04 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AEE3A0E82 for ; Thu, 15 Oct 2020 19:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=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 gSdRZyvC_gG4 for ; Thu, 15 Oct 2020 19:07:00 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650114.outbound.protection.outlook.com [40.107.65.114]) (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 83F763A0E80 for ; Thu, 15 Oct 2020 19:07:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TMu2wbM+pcJOVyyye4OoJ7aNSjIN4P2xHLYsDMQBZTUv/YqXMMC7JOFkhg+DdX2pUD4jQHMWN5CrdIVbOtJs5mRU/A4eEOl+fCIjyK/NJRzIHyRm5JlVOC55D5hlBvBCkhdgR66EPLHEChh7k7CfPajMHaDoChJMcBP9myfwmnOAZtiMtNj2jjjt43t/d6rQbxgKZyjpwyjLIlkiZeSxHllr7ruWjfW32QAQuyK5IietTjIuXggQz7SYA9raZHzmL0nv/unWQ4WNjmmuqxtdoEFiqWHDo3oL2V8iGrbmyLJcfjza7AXmevNc98JcUPxYBRoKmNU8uPiqLT/kV61Ovw== 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=Sfn0eKZ8ZCEvSmu1Ky91fwumNajGuErbZQCXzc4SuII=; b=AU2feVnqO+HNrodjaxVcp+fn+VUY0Vn+oFAfjxxRW8j8VyguYlJOtwNqDkXgKhcrXTwo4CVS3AFyr7va/wEUSwLMT5PAb7kOKAx8OtDJEUzX0Ry5hnVxdzza/1Rz+esKYA3AYUZnX9R4HdG7oo3cVmenUOpMmBOoUt1BA+Q3SEMEno2kcMl6HNA4nVkYcGdiSdsECR/LXmzUynb7UWb2OVo9JsaBSIuFPoLsb+V5O8XQ/E6JnYm4Uh1Vu/vPdVHY0qNh5UfXAhw331vA+STMNHE9tO/tq+kepEVcx7KeEaWoLJoQtaLDw9rvp3MLmRw+2RqDf0uTt/CJorW3CiblPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sfn0eKZ8ZCEvSmu1Ky91fwumNajGuErbZQCXzc4SuII=; b=AxfpMowk5XJd/jXvZ+6xw8OBabnsVXnXyKY8TjAsP1NSe2YSflmZk0eNF2ls6pVEhZBXPGlJnoo2ptuhqmLtoOf9wr/8vD2Twqk2yZK8pfMmg9gkdUP+21/dDl/F4o+HC0RVrPXkDlveUBE3AJjb602Nvn7LH9Defb1K9kWu83M= Received: from (2603:10b6:610:ad::14) by CH2PR00MB0812.namprd00.prod.outlook.com (2603:10b6:610:6f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3515.0; Fri, 16 Oct 2020 02:06:54 +0000 Received: from CH2PR00MB0728.namprd00.prod.outlook.com ([fe80::8a2:e6a:54f5:d662]) by CH2PR00MB0728.namprd00.prod.outlook.com ([fe80::8a2:e6a:54f5:d662%8]) with mapi id 15.20.3521.000; Fri, 16 Oct 2020 02:06:54 +0000 From: Praveen Balasubramanian To: "tcpm@ietf.org" , Matt Olson , Yi Huang Thread-Topic: WGLC review of draft-ietf-tcpm-rfc793bis-18 Thread-Index: AdajXxk8uequbu29QB+n5DRBKHdcewAAci5Q Date: Fri, 16 Oct 2020 02:06:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=366faa20-1224-4122-9110-1f261cdafb59; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-16T01:15:52Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:a:95ce:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b46a7d4e-72c7-41d9-900d-08d871782760 x-ms-traffictypediagnostic: CH2PR00MB0812: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mSdLtAG3YFvn6g6Xua4tL7/B6ooikYJmAQhIRIfQb4imoo5Dfv62v18DKUhSQqr/VVghofQK2N+OBlH2Q/W6ss22W+R3/TrVToOeok5md6hpX3f00+sdT4s3SbCM257AwYL/kjXs4tSh5HfwQgip1pmxMzm+cWG1Vf04EZjb/lKmJ2qTNu7cbwxn7mfFM3lYnd/42M/dj50k7/l7UbhPZA2on9pUEb1U0ZSyR4BN2JqQTmfBzR8Ju9mgiz7NxFGU6p8pZ+UQTn9txL5M8/sZ1ar4fizdH5vkLQejCFcjQkZWJHCqzK3TwkQKpkpVYnushsUhosUesmjNDzZD1w7C1A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0728.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(8936002)(55016002)(478600001)(8676002)(2906002)(316002)(83380400001)(2940100002)(64756008)(110136005)(5660300002)(66476007)(10290500003)(66556008)(66446008)(52536014)(71200400001)(186003)(7696005)(6506007)(53546011)(9686003)(6636002)(86362001)(76116006)(82960400001)(82950400001)(33656002)(8990500004)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: R/B82gyQUIioYv+IhNl1GzDD0hc2982xxth07HLlz/cM5uI75+IZRNX4iJcBjVpGFia7zeMB8rLDgTju65GshO0ts5pmwCjTe+vKdlxDke6uDbioNKReMCD1sIPfd//YFA17SL4bfClUlllD0joJhsp1KPmT8JI4gNwM7Dn9k+RNj7qUR3SZsYhOFE2EV5oykEqUNEDrVlVpku1TxdVWOxL5UUgEep4RdBDYWyH9QlsGSRZSpGgNqcJcRWfa+CMWgt7sFzG6AZ4PtSuEgsJmsyUpKh0IkcklO5vUMGIJT8YHGY+AMZBXadEfxzfy8GTw1WsLzeKmficGwV7c2L164GViUgScljfo4ODkPZA987twcGu+BCF0MyaF+JuQra+v0taOtQdOvS5PFsDA+uIjN3tomxk3ddrOld3ZmhtP2YyqqmKM6fBQyUVpaLTdiBgdlc9UPAdRSd+vf3JJ9ei21+WFTKKWIMOwgM2Kej+ZdAI5dAr92susyz31wt9HjGvu9oxeyGNA321dK6FNKxWJadmeSX4Oj9uULKIYFzoghArKwKfdEWcpdU80S0oj4OzIlqI6N6ZNtYbxiK1rWtLUzXF8ItkY7y7Ucg9Xcex+e9z4NpBgOgZq8NMCfu+TPUe7mfeA/Qt7f60gpGm8ku2qI92qsFSOqKAvIMIQfv96RomU85EmP30ft6u9DkPH2YJMcZRuKX+wUX9TxmaLx6ag7A== Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0728DD8CB50540C41DE83D0FB6031CH2PR00MB0728namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0728.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b46a7d4e-72c7-41d9-900d-08d871782760 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 02:06:54.2304 (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: HKGagL3GRGz0dtSeB7RR8N99XVv49wVWK13iLWfyOLLbYsXdulivXXXbn3WyXLJtzF+0lBgAMADPcji/QbyVBOgJ4LIa3H2McOLzZQaH6ck= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0812 Archived-At: Subject: Re: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Oct 2020 02:07:03 -0000 --_000_CH2PR00MB0728DD8CB50540C41DE83D0FB6031CH2PR00MB0728namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding Matt and Yi to the To line as the first email removed the Cc line. From: tcpm On Behalf Of Praveen Balasubramanian Sent: Thursday, October 15, 2020 6:55 PM To: tcpm@ietf.org Subject: [EXTERNAL] [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18 Following is a WGLC review of draft-ietf-tcpm-rfc793bis-18 by Matt, Yi, and= myself. Section 3.1 The control bits in the header include the RFC 3168 specified CWR and ECE. = It might be worth citing 3168 as well in the Abstract. It is quite a bit surprising that we don't include discussion of the SACK, = Timestamp, and Window Scaling options. Even if we don't describe the detail= s, the document should provide references to these almost universally deplo= yed options and recommend that hosts SHOULD implement them. At least the Ti= mestamp option is referred to multiple times in the text without any specif= ication of the format. Section 3.6.4 " If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the sending TCP endpoint buffers all user data (regardless of the PSH bit), until the outstanding data has been acknowledged or until the TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes). " This is slightly different from Nagle's description in RFC 896: " The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unacknowledged. " I.e., the original algorithm description in RFC 896 didn't include the "or = if a full-sized packet can be sent" part. This difference isn't mentioned i= n 793bis, it ought to be, along with a justification for the difference. Al= so there is no mention of the interaction problem between Nagle's algorithm= and delayed ACKs, either here or in the later section on delayed ACKs. Section 3.7.3 "However, the values of R1 and R2 may be different for SYN and data segments. In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes. The application can close the connection (i.e., give up on the open attempt) sooner, of course. " The MUST here is onerous for what is an ancient timeout value which modern = implementations don't adhere to. Recommend changing this to a SHOULD. Section 3.7.4 "Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval (MUST-26). " It's important to call out an additional condition - that sends are not alr= eady outstanding. When a send is outstanding, it is retransmitted and serve= s as an implicit liveness check. Section 3.7.2 "A TCP endpoint MUST implement RFC 5681 (MUST-19)." This requirement is onerous because RFC 5681 also specifies the NewReno con= gestion control algorithms. Modern implementations use other algorithms. We= should add clarifying text permitting experimentation and evolution of con= gestion control algorithms. It is also not required for interop. Editorial comments: " 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). " should be "not work". " Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is be possible for a TCP implementation to maintain a zero receive window while transmitting data and receiving ACKs. " Remove the "be". " The "Quiet Time" concept discussed below addresses this and the discussion of it is included for situations where it might be relevant, although it is not felt to be necessary in most current implementations. The problem have been more relevant earlier in the history of TCP. " The problem was more relevant " It is tempting for a TCP implementation to want to advertise the largest possible MSS " Remove "want to". "The TCP implementation will signal a user, even if no RECEIVEs are outstanding, that the remote peer has closed, so the user can terminate his side gracefully. " "The user may CLOSE the connection at any time on his own initiative " Suggestion to be gender neutral in the text. " For IPv4, RFC 1122 provides an IP-layer recommendation on the default effective MTU for sending to be less than or equal to 576 for destinations not directly connected. " Should at least be "recommendation for", but consider changing to something= more concise like "For IPv4, RFC 1122 recommends an IP-layer default effec= tive MTU less than or equal to 576 for destinations not directly connected.= " --_000_CH2PR00MB0728DD8CB50540C41DE83D0FB6031CH2PR00MB0728namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adding Matt and Yi to the To line as the first email= removed the Cc line.

 

From: tcpm <tcpm-bounces@ietf.org> O= n Behalf Of Praveen Balasubramanian
Sent: Thursday, October 15, 2020 6:55 PM
To: tcpm@ietf.org
Subject: [EXTERNAL] [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-= 18

 

Following is a WGLC rev= iew of draft-ietf-tcpm-rfc793bis-18 by Matt, Yi, and myself.

 

 

Section 3.1<= /span>

The control bits in the= header include the RFC 3168 specified CWR and ECE. It might be worth citin= g 3168 as well in the Abstract.

 

It is quite a bit surpr= ising that we don't include discussion of the SACK, Timestamp, and Window S= caling options. Even if we don't describe the details, the document should = provide references to these almost universally deployed options and recommend that hosts SHOULD implement them. At least = the Timestamp option is referred to multiple times in the text without any = specification of the format.

 

Section 3.6.4

"

   If there i= s unacknowledged data (i.e., SND.NXT > SND.UNA), then the

   sending TC= P endpoint buffers all user data (regardless of the PSH

   bit), unti= l the outstanding data has been acknowledged or until the=

   TCP endpoi= nt can send a full-sized segment (Eff.snd.MSS bytes).

"

This is slightly differ= ent from Nagle's description in RFC 896:

"

The solution is to inhi= bit the sending of new TCP  segments  when

new  outgoing &nbs= p;data  arrives  from  the  user  if  any pre= viously

transmitted data on the= connection remains unacknowledged.

"

I.e., the original algo= rithm description in RFC 896 didn't include the "or if a full-sized pa= cket can be sent" part. This difference isn't mentioned in 793bis, it = ought to be, along with a justification for the difference. Also there is no mention of the interaction problem between Na= gle's algorithm and delayed ACKs, either here or in the later section on de= layed ACKs.

 

 

Section 3.7.3

 

“However, the val= ues of R1 and R2 may be different for SYN

    = ;        and data segments.  In par= ticular, R2 for a SYN segment MUST

    = ;        be set large enough to provide = retransmission of the segment

    = ;        for at least 3 minutes.  T= he application can close the

    = ;        connection (i.e., give up on th= e open attempt) sooner, of

    = ;        course.

“

The MUST here is onerou= s for what is an ancient timeout value which modern implementations donR= 17;t adhere to. Recommend changing this to a SHOULD.

 

Section 3.7.4

“Keep-alive packets MUST only be sent when no data or ack= nowledgement

   packets have been received for the connection with= in an interval

   (MUST-26).

“

It’s important to= call out an additional condition – that sends are not already outsta= nding. When a send is outstanding, it is retransmitted and serves as an imp= licit liveness check.

 

Section 3.7.2

 

“A TCP endpoint MUST implement RFC 5681 (MU= ST-19).”

This requirement is onerous because RFC 5681 also sp= ecifies the NewReno congestion control algorithms. Modern implementations u= se other algorithms. We should add clarifying text permitting experimentati= on and evolution of congestion control algorithms. It is also not required for interop.  

 

 

 

 

Editorial comments:<= o:p>

 

" 

     The w=
indow size MUST be treated as an unsigned number, or else
     large=
 window sizes will appear like negative windows and TCP will
     no=
w work (MUST-1).

"

should be "not wor= k".

 

" 

Note that when the receiv=
e window is zero no segments should be
   acceptable e=
xcept ACK segments.  Thus, it is be possible for a TCP
   implementati=
on to maintain a zero receive window while transmitting
   data and rec=
eiving ACKs.

"


Remove the "be&quo=
t;.


 


" 


The "Quiet Time"=
; concept discussed below addresses this and the


   discussion o=
f it is included for situations where it might be


   relevant, al=
though it is not felt to be necessary in most current


   implementati=
ons.  The problem have been more relevant earlier in the=



   history of T=
CP. 


"


The problem was m=
ore relevant


 =



" 


It is

   tempting for=
 a TCP implementation to want to advertise the largest

   possible MSS=



"=



Remove "want to&quo=
t;.


 


“The TCP implementation will signal a

   user, even if no RECEIVEs are outstanding, that th=
e remote peer has


   closed, so the user can terminate his side gracefu=
lly.


“


“The user may CLOSE the connection at any time on his own=



         initiative


“


Suggestion to be gender neutral in the text. 


 


" 


For IPv4, RFC 1122 provid=
es an IP-layer recommendation


   on the defau=
lt effective MTU for sending to be less than or equal to<=
/pre>

   576 for dest=
inations not directly connected.


"=



Should at least be "=
;recommendation for", but consider changing to something more concise =
like "For IPv4, RFC 1122 recommends an IP-layer default effective MTU =
less than or equal to 576 for destinations not directly
 connected."


 
--_000_CH2PR00MB0728DD8CB50540C41DE83D0FB6031CH2PR00MB0728namp_-- From nobody Sat Oct 17 18:56:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB413A12E5 for ; Sat, 17 Oct 2020 18:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 IVROfnMaN-ge for ; Sat, 17 Oct 2020 18:56:33 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 B9B203A12E4 for ; Sat, 17 Oct 2020 18:56:33 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id k21so8838817ioa.9 for ; Sat, 17 Oct 2020 18:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=1uLIvsBMmShmoz4YgR1WFUFeIHRdId1yd4hWFVtfOc0=; b=SoGqDYlYxyZ2fQ+8ve0jHmKPZWki56BHeB5ykwIuLlmetYnvtmd0KdI3Kj6sB/IHLw uuTnlrCkh/FG7Iy0wurEhXc62s8jqgJxsWtuuqVlLs+LiCeff/7wLZBlf7k08lnca0vh Pz5sLM8ay7oFQST4fqyJGJsWaNJ4iNbvgdtcL1b/rAgQfyVQ9l1Z3J5oNf45VXZOG12u gX1E1a7FeU2QUFiPUTb/BVkNfHz9MZm3vpKQrsyBWMWWzu1PdBlWXJWpD3bJ9up6gmU0 NkXLW++HFRH2o2M5eI1/7Xcg/TBep5xALA6RupR4Bhg44b5kP/g+6GW4C1/PkvGGAH7t 50gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1uLIvsBMmShmoz4YgR1WFUFeIHRdId1yd4hWFVtfOc0=; b=YukUjZAD/pRtw9PdMxa9j4A0/INtpuqA3ajElK/AaSM4vMLMLzIhotrtEUC2xO382K ntpMF13OQvfa+pxyfw0Mn2rEi58VpqKuWKetHTr6JHsjznM2LZ58H3nFhIbpF0kOaiaz lqkDaJX+GrrdJIrsI5GxI5yNso8x56RSEYCCVdJHEEwiX2uIMOmA9eUykkH5LYKSevjy B3KTJUNWWkhFcgCkAnuW2anrPjEO+Up8XyhJfuW/4epZnvdCZhJkVzrD8r9mIuiz336D L73ewAMsyiE2NGJqh3hYbwMhQUNx2BPb61u9sMvo9Q9PEUWa6zFlrIrTaE6epLO99qln aAAg== X-Gm-Message-State: AOAM532moKi+iJw1xGgRF+3cMZEghUDN+CRu0sdLsxU4yAywUbOBoto5 S3ZQn7P4QrPe2uPbGAXpqeP9bhcHh6sfnzNBhoUTaSk+Lxh5QQ== X-Google-Smtp-Source: ABdhPJzVGbB9n3WXH+1wH5hUzfjqn46v2ymwUVU4jTbHl8kgXPaMsH2Es+SFZaxhykRa9pgq8pManVoS+8nRF2bvWNc= X-Received: by 2002:a05:6638:218b:: with SMTP id s11mr7491337jaj.16.1602986192069; Sat, 17 Oct 2020 18:56:32 -0700 (PDT) MIME-Version: 1.0 From: Matt Mathis Date: Sat, 17 Oct 2020 18:56:20 -0700 Message-ID: To: tcpm IETF list Content-Type: multipart/alternative; boundary="0000000000008f4ba705b1e84ec3" Archived-At: Subject: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 01:56:35 -0000 --0000000000008f4ba705b1e84ec3 Content-Type: text/plain; charset="UTF-8" Following a discussion with the tcpm chairs, the authors of RFC6937 plan to introduce a .bis document to update PRR from Experimental to Proposed Standard. PRR is supported in one form or another in 3 major operating systems and has come to be very widely deployed over the last several years. There have been no changes to the base algorithms for PRR-CRB (Conservative Rate Bound) and PRR-SSRB (Slow Start Rate Bound). However PRR can be substantially improved by using a heuristic to dynamically switch between algorithms, depending on the presence of additional losses. We plan to present a candidate heuristic, however there has not been any deep studies of alternatives. This approach was first described in section 5.2. of Flach et al "An Internet-Wide Analysis of Traffic Policing" and has already been upstream for several years. I could use some editorial advice: RFC 6937 is too long and much too "tutorial" in tone. Does it work for RFC 6937.bis to state the algorithms in normative language, but to have non-normative references to RFC 6937 for context and background? Can somebody point me to a pair of existing RFC's that use this approach? How much explanation should remain in RFC 6937.bis? We are aiming to have something ready for the next tcpm meeting. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. --0000000000008f4ba705b1e84ec3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following a discussion with the tcpm chairs, the authors o= f=C2=A0RFC6937 plan to introduce a .bis document to update PRR from Experim= ental to Proposed Standard.=C2=A0 =C2=A0PRR is supported in one form or ano= ther in 3 major operating systems=C2=A0and has come to be very widely deplo= yed over the last several years.

There have been no chan= ges to the base algorithms=C2=A0for PRR-CRB (Conservative Rate Bound) and P= RR-SSRB (Slow Start Rate Bound).=C2=A0 However PRR can be substantially imp= roved by using a heuristic to dynamically switch between=C2=A0algorithms, d= epending on the presence of additional losses.=C2=A0 =C2=A0 We plan to pres= ent a candidate heuristic, however there has not been any deep studies of a= lternatives.=C2=A0 This approach was first described in section 5.2. of=C2= =A0Flach et = al "An Internet-Wide Analysis of Traffic Policing"=C2=A0and h= as already been upstream=C2=A0for several years.

I= could use some editorial advice:=C2=A0 RFC 6937 is too long and much too &= quot;tutorial" in tone.=C2=A0 =C2=A0Does it work for RFC 6937.bis to s= tate the algorithms=C2=A0in normative language, but to have non-normative r= eferences to=C2=A0RFC 6937 for context and background?=C2=A0 Can somebody p= oint me to a pair of existing RFC's that use this approach?=C2=A0 =C2= =A0How much explanation should remain in=C2=A0RFC 6937.bis?

<= /div>
We are aiming to have something ready for the next tcpm meeting.<= /div>

Thanks,
<= div dir=3D"ltr">--MM--
The best way to predict the future is to create i= t. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefully = measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too str= ong would be hypocritical and risks spiraling out of control;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mistaken for ta= cit approval.
--0000000000008f4ba705b1e84ec3-- From nobody Sun Oct 18 14:07:18 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A23A0C5F; Sun, 18 Oct 2020 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZWIj6bE2e1A; Sun, 18 Oct 2020 14:07:14 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 503AD3A0C55; Sun, 18 Oct 2020 14:07:10 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kUFtU-000Cuv-2c; Sun, 18 Oct 2020 23:07:08 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.12]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kUFtS-000B08-U0; Sun, 18 Oct 2020 23:07:08 +0200 From: Michael Welzl Message-Id: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_7CCE749E-EFB5-47AC-8F77-5C169DB7A1B4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Sun, 18 Oct 2020 23:07:05 +0200 In-Reply-To: Cc: tcpm IETF list To: Matt Mathis References: X-Mailer: Apple Mail (2.3445.104.17) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.12]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.001, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8ABED5429B589392FCC4A3F90F53AE1D3F065255 Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 21:07:17 -0000 --Apple-Mail=_7CCE749E-EFB5-47AC-8F77-5C169DB7A1B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Are there any known bad experiences with PRR at all? I like RFC 6937, as I appreciate that it's trying to do the right thing, = in the right way (and, as a side note, at least I did enjoy its = =E2=80=9Ctutorial=E2=80=9D tone writing style) =E2=80=A6 but I do think = that there may be situations where the RFC 6675 style reduction has an = advantage, as it allows the queue to drain for half an RTT before = sending again. We once saw consistent double drops upon entering FR/FR from CA in local = tests with a large queue (above a BDP), and ended up blaming PRR for it, = as it would detect loss (little loss) and quite immediately set the rate = to half of the previous rate, which (in case of an above-BDP bottleneck = queue) was still faster than the capacity limit. Then, the queue never = really got a chance to drain (it seemed), it filled up again, and there = was another loss. Now, one could argue that such long queues are not a = case to optimize for anyway, but e.g. Cubic=E2=80=99s backoff could show = the same behavior with a shorter queue. We didn=E2=80=99t investigate this deeper, and now I can=E2=80=99t be = say for sure if this really was PRR=E2=80=99s fault - but shortly after = this experience, I stumbled over this: https://www.ee.technion.ac.il/~isaac/p/sigcomm16_vcc_extended.pdf (long version of the VCC Sigcomm=E2=80=9916 paper) =E2=80=A6 which also finds double drops occuring as a result of PRR (see = appendix B). I have to admit that I don=E2=80=99t fully get the = discussion around ECN in this appendix; altogether, I=E2=80=99m not = really convinced there are hard facts about this being a =E2=80=9Cproblem= =E2=80=9D at all, but I thought it=E2=80=99d be worth bringing to the = group=E2=80=99s attention. Maybe someone has investigated this deeper = and found out if this is a real issue or not. Cheers, Michael > On Oct 18, 2020, at 3:56 AM, Matt Mathis = wrote: >=20 > Following a discussion with the tcpm chairs, the authors of RFC6937 = plan to introduce a .bis document to update PRR from Experimental to = Proposed Standard. PRR is supported in one form or another in 3 major = operating systems and has come to be very widely deployed over the last = several years. >=20 > There have been no changes to the base algorithms for PRR-CRB = (Conservative Rate Bound) and PRR-SSRB (Slow Start Rate Bound). However = PRR can be substantially improved by using a heuristic to dynamically = switch between algorithms, depending on the presence of additional = losses. We plan to present a candidate heuristic, however there has = not been any deep studies of alternatives. This approach was first = described in section 5.2. of Flach et al "An Internet-Wide Analysis of = Traffic Policing" = and has already been upstream for several years. >=20 > I could use some editorial advice: RFC 6937 is too long and much too = "tutorial" in tone. Does it work for RFC 6937.bis to state the = algorithms in normative language, but to have non-normative references = to RFC 6937 for context and background? Can somebody point me to a pair = of existing RFC's that use this approach? How much explanation should = remain in RFC 6937.bis? >=20 > We are aiming to have something ready for the next tcpm meeting. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > We must not tolerate intolerance; > however our response must be carefully measured:=20 > too strong would be hypocritical and risks spiraling out = of control; > too weak risks being mistaken for tacit approval. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_7CCE749E-EFB5-47AC-8F77-5C169DB7A1B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Are = there any known bad experiences with PRR at all?

I like RFC 6937, as I appreciate that = it's trying to do the right thing, in the right way (and, as a side = note, at least I did enjoy its =E2=80=9Ctutorial=E2=80=9D tone writing = style) =E2=80=A6 but I do think that there may be situations where the = RFC 6675 style reduction has an advantage, as it allows the queue to = drain for half an RTT before sending again.

We once saw consistent double drops = upon entering FR/FR from CA in local tests with a large queue (above a = BDP), and ended up blaming PRR for it, as it would detect loss (little = loss) and quite immediately set the rate to half of the previous rate, = which (in case of an above-BDP bottleneck queue) was still faster than = the capacity limit. Then, the queue never really got a chance to drain = (it seemed), it filled up again, and there was another loss. Now, one = could argue that such long queues are not a case to optimize for anyway, = but e.g. Cubic=E2=80=99s backoff could show the same behavior with a = shorter queue.

We didn=E2=80=99t investigate this deeper, and now I can=E2=80=99= t be say for sure if this really was PRR=E2=80=99s fault - but shortly = after this experience, I stumbled over this:
https://www.ee.technion.ac.il/~isaac/p/sigcomm16_vcc_extended.p= df
(long version of the VCC Sigcomm=E2=80=9916 = paper)

=E2=80=A6= which also finds double drops occuring as a result of PRR (see appendix = B).  I have to admit that I don=E2=80=99t fully get the discussion = around ECN in this appendix; altogether, I=E2=80=99m not really = convinced there are  hard facts about this being a =E2=80=9Cproblem=E2= =80=9D at all, but I thought it=E2=80=99d be worth bringing to the = group=E2=80=99s attention. Maybe someone has investigated this deeper = and found out if this is a real issue or not.

Cheers,
Michael


On Oct = 18, 2020, at 3:56 AM, Matt Mathis <mattmathis=3D40google.com@dmarc.ietf.org> = wrote:

Following a discussion with the tcpm chairs, the = authors of RFC6937 plan to introduce a .bis document to update PRR = from Experimental to Proposed Standard.   PRR is supported in = one form or another in 3 major operating systems and has come to be = very widely deployed over the last several years.

There have been no changes to the base = algorithms for PRR-CRB (Conservative Rate Bound) and PRR-SSRB (Slow = Start Rate Bound).  However PRR can be substantially improved by = using a heuristic to dynamically switch between algorithms, = depending on the presence of additional losses.    We plan to = present a candidate heuristic, however there has not been any deep = studies of alternatives.  This approach was first described in = section 5.2. of Flach et al "An Internet-Wide Analysis of Traffic = Policing" and has already been upstream for several = years.

I could = use some editorial advice:  RFC 6937 is too long and much too = "tutorial" in tone.   Does it work for RFC 6937.bis to state = the algorithms in normative language, but to have non-normative = references to RFC 6937 for context and background?  Can = somebody point me to a pair of existing RFC's that use this = approach?   How much explanation should remain in RFC = 6937.bis?

We = are aiming to have something ready for the next tcpm meeting.

Thanks,
--MM--
The best way to predict the future is to create it.  - = Alan Kay

We must not tolerate = intolerance;
      =  however our response must be carefully measured: 
            too strong would be = hypocritical and risks spiraling out of control;
            too weak risks = being mistaken for tacit = approval.
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_7CCE749E-EFB5-47AC-8F77-5C169DB7A1B4-- From nobody Mon Oct 19 04:23:30 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBC43A0B1C; Mon, 19 Oct 2020 04:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.286 X-Spam-Level: X-Spam-Status: No, score=0.286 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBIdjvAFDJl7; Mon, 19 Oct 2020 04:23:27 -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 AE2FF3A0B17; Mon, 19 Oct 2020 04:23:25 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:d93:f195:424:a8c] (unknown [IPv6:2a02:8109:1140:c3d:d93:f195:424:a8c]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 8D9ED721A6400; Mon, 19 Oct 2020 13:23:21 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_7F6C40EA-8E62-46D6-A2F2-235A0EDCAF81"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Mon, 19 Oct 2020 13:23:19 +0200 Cc: tcpm-chairs To: tcpm IETF list X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [tcpm] Agenda requests for TCPM@IETF109 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 11:23:29 -0000 --Apple-Mail=_7F6C40EA-8E62-46D6-A2F2-235A0EDCAF81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, according to the preliminary schedule for IETF 109 (online), TCPM is scheduled for Tuesday, November 17th, 2020, from 05:00 to 07:00 UTC. If you would like to present during this meeting, please provide by the end of Friday, October 30th, 2020: * Title of the presentation * Name of the presenter * Name of the Internet Draft * Time required (including Q/A) Please send us the slides for your presentations by Friday, November = 13th, 2020, latest. Best regards Michael --Apple-Mail=_7F6C40EA-8E62-46D6-A2F2-235A0EDCAF81 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 AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEw MTkxMTIzMTlaMC8GCSqGSIb3DQEJBDEiBCDbX7/cJaJYtLuKJA2OiyMdpsctfUudDPro3tLNKcIX gjCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAgJQeQVRX7mO1WWqwnDht1dVm2bC3 zdeGeiB7erU//0TYo0tnY7m6xm9lmJPmfPoqqhUXzO2oeP8a3scQOQs1wn6/h3XVmGl5WKjMaiai XWeMCL9tTq4hbje7TcMmJ0TBIj3TBnKhwW5VOmxt81UUZ/mtCArRZciXrOxTmEC8cW3W/B+hzRZ4 +FBvtg4yXzbPj+YiTTf5FicIE+hgvL9Dh3N5eq2pjcUg3GvHK2JXlpaEW2uSZf7DL0Z8yv0QgroC f2mB9GmjcrDmE77X0zbuooi/o3wdXSyNWoH0P9V9pWOH/bjacFJ65HzDYH/0UzLms+wSe3ugVBVM VgJ2fluEBgAAAAAAAA== --Apple-Mail=_7F6C40EA-8E62-46D6-A2F2-235A0EDCAF81-- From nobody Mon Oct 19 10:20:49 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E3D3A0E27 for ; Mon, 19 Oct 2020 10:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 IpHTYDfrrBoj for ; Mon, 19 Oct 2020 10:20:44 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 E2F363A10DC for ; Mon, 19 Oct 2020 10:20:25 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id z5so602593iob.1 for ; Mon, 19 Oct 2020 10:20:25 -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=zhIEdcZDFz4Be8teZ83k7hfyviYaRFvNCkxE/97+0pg=; b=BDoz46DHbA8hcShESCb/0QE7WTw3iCGuvNeFUbbZGl/zZ3QZIOBl4mCyf0HbyoCM8d Zrag7Tzs98TvPANOWGkv5JeapJvnWEDEXBCQ+YlyNo0GckCacEdDgNAxx6J4qiWtbWeA igA37YjDT2/2AbkeFPk9BjvFnlZNa/wrdwGwQSxYom5ADogszP3TttLmOqQdOHQP6Twg CP9ZP51so/MQWejH/zUx4Ai6yXZNer24b7SOeDX7Wb8qJEHPl3kJFliJ3KIdFqJ4ILAz kfp0NBpdNCRb22seayDWIKtJhZ/s14+TrrieLOluifCbbaY3xy04pS6jNLRQce6vZcVK o7QA== 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=zhIEdcZDFz4Be8teZ83k7hfyviYaRFvNCkxE/97+0pg=; b=dfdvXa4ivDJ7+vJRTGk5RjBqwz6id+Yc6PH6v5TlhqDck9Te53XlS2wgZYBDkck+9q vOrPhvpq70lud5E0G1fx/8WXFc9eDoJeZnNC4iUO3BjrPXgSHeZHsab07bDbos/kaTSw zJTKqtW7GAG6zElkCD1piOLNluNAEZCiXmOskCogSVHfNu/MkN/fsx88sScnWG+k++TP W2D+uh5WoA7p1vHxHodCGjRCFZ1ke5GcG96Khc0NetCKV/OorNFPs1+g8Gh2r41goofU aQH44AzDlnysVlObVmBoW0dCbbVgaobu2AtJixN+ewDk9LoOPFeT3BJ2DmyKlx7/510v eMow== X-Gm-Message-State: AOAM530iib/Kg4jpTRt0o2rYvMaNMGR7BFMTdVf2rQ+S+0kPyMTsVGQh LhbnBdnV5Wm6kSzNSY12v0OFNzmvk6NOFSCF6mA1uw== X-Google-Smtp-Source: ABdhPJzDz+kPmQKonlhUHrdg4k3cBdEg82J2p48TBuwD15BCGuCPDaioK3/qFfxOfLGMqmMGAg6PQ7QiFwThy3m2TMw= X-Received: by 2002:a5d:83cc:: with SMTP id u12mr366052ior.171.1603128024732; Mon, 19 Oct 2020 10:20:24 -0700 (PDT) MIME-Version: 1.0 References: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> In-Reply-To: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> From: Matt Mathis Date: Mon, 19 Oct 2020 10:20:13 -0700 Message-ID: To: Michael Welzl Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000071e6e205b209546d" Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 17:20:48 -0000 --00000000000071e6e205b209546d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The heuristic was designed to address the "double drops" that you noted. Both RFC 6675 and PRR-SSRB can be too aggressive in situations where there are burst losses that cause the flight size to fall below ssthresh. Sometimes these are ok, but they often cause lost retransmissions. The new heuristic is to prevent these situation from persisting. These situations are hard to reason about because they can not be caused by events that are modeled by simple queues. The Flatch paper is about token bucket policers which cause huge losses when they run out of tokens -- all without significant queues. Other potential events include bursty cross traffic from long RTT or non-responsive flows. With packet conservation, a single flow can not cause self inflicted losses that last more than one RTT, and thus can't cause lost retransmissions. If there are lost retransmissions something happened that is outside the scope a simple network model. While I agree that 6675's half RTT of silence reduces queue pressure, the responsibility for that really belongs to congestion control, which should not be controlling against queue full. The goal of PRR is to minimize the opportunities to lose the self clock by accurately controlling flightsize to the target set by the congestion control. The heuristic also helps in the situation where there was a large step change in the available bandwidth, and the CC can not possibly estimate the the correct flightsize quickly enough. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Sun, Oct 18, 2020 at 2:07 PM Michael Welzl wrote: > Hi, > > Are there any known bad experiences with PRR at all? > > I like RFC 6937, as I appreciate that it's trying to do the right thing, > in the right way (and, as a side note, at least I did enjoy its =E2=80=9C= tutorial=E2=80=9D > tone writing style) =E2=80=A6 but I do think that there may be situations= where the > RFC 6675 style reduction has an advantage, as it allows the queue to drai= n > for half an RTT before sending again. > > We once saw consistent double drops upon entering FR/FR from CA in local > tests with a large queue (above a BDP), and ended up blaming PRR for it, = as > it would detect loss (little loss) and quite immediately set the rate to > half of the previous rate, which (in case of an above-BDP bottleneck queu= e) > was still faster than the capacity limit. Then, the queue never really go= t > a chance to drain (it seemed), it filled up again, and there was another > loss. Now, one could argue that such long queues are not a case to optimi= ze > for anyway, but e.g. Cubic=E2=80=99s backoff could show the same behavior= with a > shorter queue. > > We didn=E2=80=99t investigate this deeper, and now I can=E2=80=99t be say= for sure if this > really was PRR=E2=80=99s fault - but shortly after this experience, I stu= mbled over > this: > https://www.ee.technion.ac.il/~isaac/p/sigcomm16_vcc_extended.pdf > (long version of the VCC Sigcomm=E2=80=9916 paper) > > =E2=80=A6 which also finds double drops occuring as a result of PRR (see = appendix > B). I have to admit that I don=E2=80=99t fully get the discussion around= ECN in > this appendix; altogether, I=E2=80=99m not really convinced there are ha= rd facts > about this being a =E2=80=9Cproblem=E2=80=9D at all, but I thought it=E2= =80=99d be worth bringing > to the group=E2=80=99s attention. Maybe someone has investigated this dee= per and > found out if this is a real issue or not. > > Cheers, > Michael > > > On Oct 18, 2020, at 3:56 AM, Matt Mathis < > mattmathis=3D40google.com@dmarc.ietf.org> wrote: > > Following a discussion with the tcpm chairs, the authors of RFC6937 plan > to introduce a .bis document to update PRR from Experimental to Proposed > Standard. PRR is supported in one form or another in 3 major operating > systems and has come to be very widely deployed over the last several yea= rs. > > There have been no changes to the base algorithms for PRR-CRB > (Conservative Rate Bound) and PRR-SSRB (Slow Start Rate Bound). However > PRR can be substantially improved by using a heuristic to dynamically > switch between algorithms, depending on the presence of additional losses= . > We plan to present a candidate heuristic, however there has not been an= y > deep studies of alternatives. This approach was first described in secti= on > 5.2. of Flach et al "An Internet-Wide Analysis of Traffic Policing" > and has already been > upstream for several years. > > I could use some editorial advice: RFC 6937 is too long and much too > "tutorial" in tone. Does it work for RFC 6937.bis to state the > algorithms in normative language, but to have non-normative references > to RFC 6937 for context and background? Can somebody point me to a pair = of > existing RFC's that use this approach? How much explanation should rema= in > in RFC 6937.bis? > > We are aiming to have something ready for the next tcpm meeting. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > We must not tolerate intolerance; > however our response must be carefully measured: > too strong would be hypocritical and risks spiraling out of > control; > too weak risks being mistaken for tacit approval. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --00000000000071e6e205b209546d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The heuristic was designed to address the "doubl= e drops" that you noted.=C2=A0 =C2=A0 Both RFC 6675 and PRR-SSRB can b= e too aggressive in situations=C2=A0where there are burst losses that cause= the flight size to fall below ssthresh.=C2=A0 Sometimes these are ok, but = they often cause lost retransmissions.=C2=A0 The new heuristic is to preven= t these situation from persisting.

These situation= s are hard to reason about=C2=A0because they can not be caused by events=C2= =A0that are modeled by simple queues.=C2=A0 The Flatch paper is about token= bucket policers which cause huge losses when they run out of tokens -- all= without significant queues.=C2=A0 Other potential events include bursty cr= oss traffic from long RTT or non-responsive flows.

With packet conservation, a single flow can not cause self inflicted losse= s that last more than one RTT, and thus can't cause lost retransmission= s.=C2=A0 =C2=A0 If there are lost retransmissions something=C2=A0happened t= hat is outside the scope a simple network model.

W= hile I agree that 6675's half RTT of silence reduces queue pressure, th= e responsibility for that really belongs to congestion control, which shoul= d not be controlling against queue full.=C2=A0 The goal of PRR is to minimi= ze the opportunities to lose the self clock by accurately controlling fligh= tsize to the target set by the congestion control.

The heuristic also helps in the situation where there was a large step cha= nge in the available bandwidth, and the CC can not possibly estimate the th= e correct flightsize quickly enough.=C2=A0

Thanks,=
--MM--
The be= st way to predict the future is to create it. =C2=A0- Alan Kay

We mu= st not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0however our response must be carefully measured:=C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypocritical and ris= ks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 too weak risks being mistaken for tacit approval.
<= /div>


On Sun, Oct 18, 2020 at 2:07 PM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Are there any known bad experienc= es with PRR at all?

I like RFC 6937, as I apprecia= te that it's trying to do the right thing, in the right way (and, as a = side note, at least I did enjoy its =E2=80=9Ctutorial=E2=80=9D tone writing= style) =E2=80=A6 but I do think that there may be situations where the RFC= 6675 style reduction has an advantage, as it allows the queue to drain for= half an RTT before sending again.

We once saw con= sistent double drops upon entering FR/FR from CA in local tests with a larg= e queue (above a BDP), and ended up blaming PRR for it, as it would detect = loss (little loss) and quite immediately set the rate to half of the previo= us rate, which (in case of an above-BDP bottleneck queue) was still faster = than the capacity limit. Then, the queue never really got a chance to drain= (it seemed), it filled up again, and there was another loss. Now, one coul= d argue that such long queues are not a case to optimize for anyway, but e.= g. Cubic=E2=80=99s backoff could show the same behavior with a shorter queu= e.

We didn=E2=80=99t investigate this deeper, and = now I can=E2=80=99t be say for sure if this really was PRR=E2=80=99s fault = - but shortly after this experience, I stumbled over this:
(long version of the VCC Sigcomm=E2=80=9916 paper)

=E2=80=A6 which also finds double drops occuring as a = result of PRR (see appendix B).=C2=A0 I have to admit that I don=E2=80=99t = fully get the discussion around ECN in this appendix; altogether, I=E2=80= =99m not really convinced there are =C2=A0hard facts about this being a =E2= =80=9Cproblem=E2=80=9D at all, but I thought it=E2=80=99d be worth bringing= to the group=E2=80=99s attention. Maybe someone has investigated this deep= er and found out if this is a real issue or not.

C= heers,
Michael


<= div>On Oct 18, 2020, at 3:56 AM, Matt Mathis <mattmathis=3D40google.c= om@dmarc.ietf.org> wrote:

Following a= discussion with the tcpm chairs, the authors of=C2=A0RFC6937 plan to intro= duce a .bis document to update PRR from Experimental to Proposed Standard.= =C2=A0 =C2=A0PRR is supported in one form or another in 3 major operating s= ystems=C2=A0and has come to be very widely deployed over the last several y= ears.

There have been no changes to the base algorithms= =C2=A0for PRR-CRB (Conservative Rate Bound) and PRR-SSRB (Slow Start Rate B= ound).=C2=A0 However PRR can be substantially improved by using a heuristic= to dynamically switch between=C2=A0algorithms, depending on the presence o= f additional losses.=C2=A0 =C2=A0 We plan to present a candidate heuristic,= however there has not been any deep studies of alternatives.=C2=A0 This ap= proach was first described in section 5.2. of=C2=A0Flach et al "= An Internet-Wide Analysis of Traffic Policing"=C2=A0and has alread= y been upstream=C2=A0for several years.

I could us= e some editorial advice:=C2=A0 RFC 6937 is too long and much too "tuto= rial" in tone.=C2=A0 =C2=A0Does it work for RFC 6937.bis to state the = algorithms=C2=A0in normative language, but to have non-normative references= to=C2=A0RFC 6937 for context and background?=C2=A0 Can somebody point me t= o a pair of existing RFC's that use this approach?=C2=A0 =C2=A0How much= explanation should remain in=C2=A0RFC 6937.bis?

W= e are aiming to have something ready for the next tcpm meeting.
<= br>
Thanks,
--MM--
The best way to predict the future is to creat= e it. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefull= y measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too s= trong would be hypocritical and risks spiraling out of control;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mistaken for= tacit approval.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://= www.ietf.org/mailman/listinfo/tcpm

--00000000000071e6e205b209546d-- From nobody Mon Oct 19 12:22:58 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7117C3A003F for ; Mon, 19 Oct 2020 12:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 rVgXkfNVTLEd for ; Mon, 19 Oct 2020 12:22:55 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 092013A0039 for ; Mon, 19 Oct 2020 12:22:55 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id q25so1102678ioh.4 for ; Mon, 19 Oct 2020 12:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CvaN0IhOolErHg5e5RK8cLh93uCpBytFPoOC3Y6XT2w=; b=S3do2AYk2Pyb4morxiLI0xC64YX4qYGWqkp84w3Hbt/wRuTLSqMxjzOBq6zXFk5y88 /iNTxwRSPnq0ftHUcp8wNK8tcTPDzqn1FkJPy27R2UgQBACmSRGPFJZcznadcf6tD2j5 J3JiW+R3tZZ2M7GPGJTrA8cA0Bfy1NtoGCDYyjoBpUnSWElYn9+YSSJWnSqdrODDu/pT PLF6kZZRZ+EmhVeL8Gwcc25yTxGgD9SZva3rRhrvzPenTwTcFwkf+tHcz1JkB+gDS8Fs +73Mlc+wQp48bPfFv2q9MIguGj6aL3/qL9UTO127gGfCDCWB41wWQvkG9WyvOgCTKuOE AM2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CvaN0IhOolErHg5e5RK8cLh93uCpBytFPoOC3Y6XT2w=; b=qLZZewtm6clSElQYtVEUtLAbEtU/GajpcvRIAoLyl/hdRGOW71Es1cEoe/FM3DC9dq ExB85Wnijfjs22RvXs1MZ+sY+w5ycH3ZSTe+iGGm7Iwv5O9MLFKmqi0g40he736VFaek tmvuj3uQSZUKrBFEJUYDO36CL/bq7/3bcJDnVUzoGLOTWxHYrSMF0Pmt322sq5f3R2tx FZvfkSmuAQb/TYnvjw2eX+WFpn3U0LlUgVupO+zQaxkQy+mxydMXK9SUdmZIjolzuzhX 0NBpwiSwJhrDq/9gFmv2IdGdB9f5OJ0kxW1wrJuiwFkC5zRwIcqhVW4wn8s2CMfltIiI h8kg== X-Gm-Message-State: AOAM533sfX//d8OfimpwXScWhgY3oLCbyVIlCWX/35RHa4vpD34R4r0p 4LxqbtJ6EacklqZ15VvBedYaEWuyA841i2QooyAavLhXKyUEXw== X-Google-Smtp-Source: ABdhPJy1hzUIuNr0ugrxIBYEqov3EtNkrXJApjaFYZvMMSB8nUyIs6L+e2eS9FMypPe8VMuSXhTzKOOoTFuwJKWQEvI= X-Received: by 2002:a02:b80f:: with SMTP id o15mr1216048jam.103.1603135374134; Mon, 19 Oct 2020 12:22:54 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Mon, 19 Oct 2020 12:22:43 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000080927105b20b0a18" Archived-At: Subject: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 19:22:56 -0000 --00000000000080927105b20b0a18 Content-Type: text/plain; charset="UTF-8" Hello tcpm, Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST consider all IP and TCP options when sizing payloads with respect to the advertised MSS option. I'm reviewing a document that advises that some endpoints may want to reduce their advertised MSS on IPv6 connections in case the peer isn't respecting that guidance. Is noncompliance with this provision a problem in the internet? Are there middleboxes injecting options that cause PMTU drops or fragmentation? I have not heard of such problems, but thought I'd check with the community to see if this precaution makes any sense at all. Thanks, Martin --00000000000080927105b20b0a18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello tcpm,

Section 4.2.2.6 of RFC 1122 is p= retty clear that the TCP sender MUST consider all IP and TCP options when s= izing payloads=C2=A0with respect to the advertised MSS option.
I'm reviewing a docu= ment that advises that some endpoints may want to reduce their advertis= ed MSS on IPv6 connections in case the peer isn't respecting that guida= nce. Is noncompliance with this provision a problem in the internet? Are th= ere middleboxes injecting options that cause PMTU drops or fragmentation?

I have not heard of such problems, but thought I= 9;d check with the community to see if this precaution makes any sense at a= ll.

Thanks,
Martin

<= div>
--00000000000080927105b20b0a18-- From nobody Mon Oct 19 12:37:22 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8AE3A08C5 for ; Mon, 19 Oct 2020 12:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJSZfkt9TDZh for ; Mon, 19 Oct 2020 12:37:13 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3143A084B for ; Mon, 19 Oct 2020 12:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vJp9HErCkuQPAEb0UGUGTF5poGos65Lt0Xm24Nui0Ss=; b=jebdFjMS9fAzB1SZNfHHptluv 020f5SIGolytQo6cShZI8G87D8Pb9RVTPwRIo+bM5zmxIgTtVxtTsPJb3xs49cQLF3hCRYOxiE0Xl +MUP826pJC5cUWrKXlg3Uv6zqmNx4OabsoZboaybLpM9o6RsYWGpGj9+r1F6BeoTc0kCU5+TXnqPd qo8exvOWXQT6mvmFOOVEzvFK9iL4H/PFr9zHNSz+tNyk+esyLd08rYKrBsXzLFHIJkUjhaeWHYB60 tz9rHxxb44gxJtHD9bS0U5fkaeGUGux5AyLJNQHpnlJuFGmiMCEWnP/XEoBrk35CsiIKx1ZblRKCv 3iErAhTeQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57936 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kUaxx-001ADG-42; Mon, 19 Oct 2020 15:37:13 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_E991EA8E-3DBF-4580-A21A-0510E4CA5229" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Mon, 19 Oct 2020 12:37:08 -0700 Cc: "tcpm@ietf.org Extensions" Message-Id: <0572D865-F831-4B3A-9A8B-6A9C4D154859@strayalpha.com> References: To: Martin Duke X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 19:37:21 -0000 --Apple-Mail=_E991EA8E-3DBF-4580-A21A-0510E4CA5229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See RFC 6691. Only the fixed headers are considered, NOT the options. Joe > On Oct 19, 2020, at 12:22 PM, Martin Duke = wrote: >=20 > Hello tcpm, >=20 > Section 4.2.2.6 of RFC 1122 = is pretty clear = that the TCP sender MUST consider all IP and TCP options when sizing = payloads with respect to the advertised MSS option. >=20 > I'm reviewing a document = that advises that some endpoints may want = to reduce their advertised MSS on IPv6 connections in case the peer = isn't respecting that guidance. Is noncompliance with this provision a = problem in the internet? Are there middleboxes injecting options that = cause PMTU drops or fragmentation? >=20 > I have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all. >=20 > Thanks, > Martin >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_E991EA8E-3DBF-4580-A21A-0510E4CA5229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii See = RFC 6691.

Only the = fixed headers are considered, NOT the options.

Joe

On Oct = 19, 2020, at 12:22 PM, Martin Duke <martin.h.duke@gmail.com> wrote:

Hello tcpm,

Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender = MUST consider all IP and TCP options when sizing payloads with = respect to the advertised MSS option.

I'm reviewing a document that = advises that some endpoints may want to reduce their advertised MSS on = IPv6 connections in case the peer isn't respecting that guidance. Is = noncompliance with this provision a problem in the internet? Are there = middleboxes injecting options that cause PMTU drops or = fragmentation?

I= have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all.

Thanks,
Martin


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

= --Apple-Mail=_E991EA8E-3DBF-4580-A21A-0510E4CA5229-- From nobody Mon Oct 19 12:44:38 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294D23A07F9 for ; Mon, 19 Oct 2020 12:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU2MgEhiVikI for ; Mon, 19 Oct 2020 12:44:34 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A864C3A07F5 for ; Mon, 19 Oct 2020 12:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OOX8qpzbK+pRaJ0kL1KJbdPdn4/Xtaw+wlkAsF9e9SA=; b=V5O+3uN5F368OOKuzmPBGVfU5 PsHH20H9WyaEQUaK9AsUauWvlLaxOfcKsy+uhaL3/R28zMEPY3HT8+2z9Z3D3wIKTojjqk0G5zAuZ NrNiVir7KHB4grhIivk0QR9kw4xquJFZ+1tpmsfSAoaGwRU5NcZFlmZEsiLSCzejUgyfRdr54I5JF /6/x0BN+tA09M+gna8mlARXOpa5AUJFqU3e8fNu7pEcGWF1pn9p3yYXyx3mPLDesJi93GAhe73aZI 3e0inNQYBeYySBKzV8eFZ/q7g07dS4V57d14ynTkWXhvrESkzmvXIfoEb7a/K4krQ464DdxtwDvca pHyDSTeew==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58098 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kUb53-001GzQ-PB; Mon, 19 Oct 2020 15:44:34 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_51B8CB0F-D03A-43E3-BDBE-8F5554F509CD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <0572D865-F831-4B3A-9A8B-6A9C4D154859@strayalpha.com> Date: Mon, 19 Oct 2020 12:44:29 -0700 Cc: "tcpm@ietf.org Extensions" Message-Id: <719D9BE6-3C5F-4121-B362-BD21FEDC941A@strayalpha.com> References: <0572D865-F831-4B3A-9A8B-6A9C4D154859@strayalpha.com> To: Martin Duke X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 19:44:36 -0000 --Apple-Mail=_51B8CB0F-D03A-43E3-BDBE-8F5554F509CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To be more clear: The MSS value in the TCP option reflects the FIXED headers only. The sending side uses that value, together with its knowledge of options = it adds, to reduce the size of the data sent to fit. Second guessing that information is problematic; sure, when something = gets through you can always try something smaller but that=E2=80=99s not = specific to TCP or anything else. Middleboxes should never make a packet larger under any circumstances. Joe > On Oct 19, 2020, at 12:37 PM, Joseph Touch = wrote: >=20 > See RFC 6691. >=20 > Only the fixed headers are considered, NOT the options. >=20 > Joe >=20 >> On Oct 19, 2020, at 12:22 PM, Martin Duke > wrote: >>=20 >> Hello tcpm, >>=20 >> Section 4.2.2.6 of RFC 1122 = is pretty clear = that the TCP sender MUST consider all IP and TCP options when sizing = payloads with respect to the advertised MSS option. >>=20 >> I'm reviewing a document = that advises that some endpoints may want = to reduce their advertised MSS on IPv6 connections in case the peer = isn't respecting that guidance. Is noncompliance with this provision a = problem in the internet? Are there middleboxes injecting options that = cause PMTU drops or fragmentation? >>=20 >> I have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all. >>=20 >> Thanks, >> Martin >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 --Apple-Mail=_51B8CB0F-D03A-43E3-BDBE-8F5554F509CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = be more clear:

The = MSS value in the TCP option reflects the FIXED headers only.

The sending side uses = that value, together with its knowledge of options it adds, to reduce = the size of the data sent to fit.

Second guessing that information is = problematic; sure, when something gets through you can always try = something smaller but that=E2=80=99s not specific to TCP or anything = else.

Middleboxes should never make a packet larger under any = circumstances.

Joe

On Oct = 19, 2020, at 12:37 PM, Joseph Touch <touch@strayalpha.com> wrote:

See RFC 6691.

Only the fixed headers = are considered, NOT the options.

Joe

On Oct = 19, 2020, at 12:22 PM, Martin Duke <martin.h.duke@gmail.com> wrote:

Hello tcpm,

Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender = MUST consider all IP and TCP options when sizing payloads with = respect to the advertised MSS option.

I'm reviewing a document that = advises that some endpoints may want to reduce their advertised MSS on = IPv6 connections in case the peer isn't respecting that guidance. Is = noncompliance with this provision a problem in the internet? Are there = middleboxes injecting options that cause PMTU drops or = fragmentation?

I= have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all.

Thanks,
Martin


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


= --Apple-Mail=_51B8CB0F-D03A-43E3-BDBE-8F5554F509CD-- From nobody Mon Oct 19 12:58:25 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3DB3A0836 for ; Mon, 19 Oct 2020 12:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFaUug0-1-lg for ; Mon, 19 Oct 2020 12:58:21 -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 0DB303A011B for ; Mon, 19 Oct 2020 12:58:20 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:f977:32:31fe:f519] (unknown [IPv6:2a02:8109:1140:c3d:f977:32:31fe:f519]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 67DC972329C02; Mon, 19 Oct 2020 21:58:16 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Michael Tuexen In-Reply-To: Date: Mon, 19 Oct 2020 21:58:15 +0200 Cc: "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> References: To: Martin Duke X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 19:58:24 -0000 > On 19. Oct 2020, at 21:22, Martin Duke = wrote: >=20 > Hello tcpm, >=20 > Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST = consider all IP and TCP options when sizing payloads with respect to the = advertised MSS option. >=20 > I'm reviewing a document that advises that some endpoints may want to = reduce their advertised MSS on IPv6 connections in case the peer isn't = respecting that guidance. Is noncompliance with this provision a problem = in the internet? Are there middleboxes injecting options that cause PMTU = drops or fragmentation? Hi Martin, the document you are reviewing says: An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than 1220 bytes. This assumes that the remote sender will use no TCP options, aside from possibly the MSS option, which is only used in the initial TCP SYN packet. The first sentence is correct. The second is not. I would suggest to = simply remove it. Then the text says: In order to accommodate unrequested TCP options that may be used by some TCP implementations, a constrained device may advertise an MSS smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that it is advised for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, the suggestion of advertising an MSS smaller than 1220 bytes is likely to be overcautious and its suitability should be considered carefully. I read this as "use a smaller MSS", but this is "likely to be overcautious and its suitability should be considered carefully." I think the careful consideration is to remove this paragraph. Best regards Michael >=20 > I have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all. >=20 > Thanks, > Martin >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Oct 19 13:51:03 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3B3A09C9 for ; Mon, 19 Oct 2020 13:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 gE43bgQ-f_wl for ; Mon, 19 Oct 2020 13:51:00 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 9FF303A09C3 for ; Mon, 19 Oct 2020 13:51:00 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id h21so1447482iob.10 for ; Mon, 19 Oct 2020 13:51: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=bPPDsQhgmkSUS/+YlPH/6MRZL0olFOyeD+ac0pE9mdA=; b=peGy8PVnvhzBzRe6khG1ZtAgDAL39T3YdJ0HAmehgEJYzcaLqoawzyg5b7zPqpuR8S 5KY/QQjiJMr2eL9eNy9aAxGJ7cxPVQeNkMttJLb7l+7Svb0HOFWK9fIhhXCeWM65oRz1 1gQZ+SzUW+xzwRgK00BsZ+SZypWiy3WGUZrsnxjN3MZMep11e5c25JZK5uctiaxjabO0 s0hsfLseXGXD/3P06kKanwzcnwcBZDWK9p/LTOB0aJvB/nABWRDOypXKNi0hPfVfS05r KM1pzL26LmibouBy5XKtErcx4uMd6icyMwXyKnOdS24DcjNTVapwjdPHz2DLr/KbFqqi lEIA== 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=bPPDsQhgmkSUS/+YlPH/6MRZL0olFOyeD+ac0pE9mdA=; b=OBHhcQDhyxfhMtMIyx3A2IQhI3Sr9f3r9LFfrbUQhiwiOp+mm2V5YpTnQFN8omNBDy H1MTisG3QQkYCpqXnCPrr7V+IIKcv3OxVHp7GKxrtEPz5N953l/oGiwefBYiw8wktGPK wZmWFe7khS7LMKlXPG7b1R+iXcd0MeJzKr0hS6SS7KisuY/Ime1Ugb1Ew8bdujOR3/cG 9J3b26rqkldXTjN5YlUBycCff8u+8V5gymeJulSTdMWa9Vd6gur9afJizUWAuyFPpT1t rBWzOIqmPNESH4m3BrM2hQeR3w7GK9DqBkHyNNdyZeoKRmmh2L06dvRvvw1oKOtYocGz el5w== X-Gm-Message-State: AOAM532Z2I3NfhF3lNfljNo7RD2N9h1ezmz5lWcaXscRhBuoLNXpZ68z 4E3ZWluRDS5BAo/xE3u+9yLK07YyleN3q4MIybfgK06qXM2DOQ== X-Google-Smtp-Source: ABdhPJwhgfdqyx4OyZJUNCeohAXwIGotku8Ln7O2IgnipgUP8ZbtZVqLKxnMwDyNG0DzoL9V1ihdx2WKjRbFNxJ8Cto= X-Received: by 2002:a5e:9913:: with SMTP id t19mr1050286ioj.95.1603140659959; Mon, 19 Oct 2020 13:50:59 -0700 (PDT) MIME-Version: 1.0 References: <0572D865-F831-4B3A-9A8B-6A9C4D154859@strayalpha.com> <719D9BE6-3C5F-4121-B362-BD21FEDC941A@strayalpha.com> In-Reply-To: <719D9BE6-3C5F-4121-B362-BD21FEDC941A@strayalpha.com> From: Martin Duke Date: Mon, 19 Oct 2020 13:50:53 -0700 Message-ID: To: Joseph Touch Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000008fdf4f05b20c4587" Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 20:51:02 -0000 --0000000000008fdf4f05b20c4587 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, I may have phrased it ambiguously but I understand the intent of 1122/6691 as you describe it. IOAM does add IPv6 options at times, although it should scrub them before it leaves the domain. Thanks Martin On Mon, Oct 19, 2020 at 12:44 PM Joseph Touch wrote: > To be more clear: > > The MSS value in the TCP option reflects the FIXED headers only. > > The sending side uses that value, together with its knowledge of options > it adds, to reduce the size of the data sent to fit. > > Second guessing that information is problematic; sure, when something get= s > through you can always try something smaller but that=E2=80=99s not speci= fic to TCP > or anything else. > > Middleboxes should never make a packet larger under any circumstances. > > Joe > > On Oct 19, 2020, at 12:37 PM, Joseph Touch wrote: > > See RFC 6691. > > Only the fixed headers are considered, NOT the options. > > Joe > > On Oct 19, 2020, at 12:22 PM, Martin Duke wrote= : > > Hello tcpm, > > Section 4.2.2.6 of RFC 1122 > is pretty clear > that the TCP sender MUST consider all IP and TCP options when sizing > payloads with respect to the advertised MSS option. > > I'm reviewing a document > > that advises that some endpoints may want to reduce their advertised MSS = on > IPv6 connections in case the peer isn't respecting that guidance. Is > noncompliance with this provision a problem in the internet? Are there > middleboxes injecting options that cause PMTU drops or fragmentation? > > I have not heard of such problems, but thought I'd check with the > community to see if this precaution makes any sense at all. > > Thanks, > Martin > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > --0000000000008fdf4f05b20c4587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

I may have phrased it ambiguous= ly but I understand the intent of 1122/6691 as you describe it.
<= br>
IOAM does add IPv6 options at times, although it should=C2=A0= scrub=C2=A0them=C2=A0before it leaves the domain.=C2=A0

Thanks
Martin

On Mon, Oct 19, 2020 at 12:44 PM Joseph = Touch <touch@strayalpha.com&= gt; wrote:
To be more clear:

T= he MSS value in the TCP option reflects the FIXED headers only.
<= br>
The sending side uses that value, together with its knowledge= of options it adds, to reduce the size of the data sent to fit.
=
Second guessing that information is problematic; sure, when = something gets through you can always try something smaller but that=E2=80= =99s not specific to TCP or anything else.

Middleb= oxes should never make a packet larger under any circumstances.
<= br>
Joe

On= Oct 19, 2020, at 12:37 PM, Joseph Touch <touch@strayalpha.com> wrote:

See RFC 6691.

Only the fixed headers are considered, NOT the options.

Joe

On Oct 19, 2020, at= 12:22 PM, Martin Duke <martin.h.duke@gmail.com> wrote:

Hello tcpm,

Section 4.2.2.6 of RFC 112= 2 is pretty clear that the TCP sender MUST consider all IP and TCP opti= ons when sizing payloads=C2=A0with respect to the advertised MSS option.

I'm reviewing a document that advises that some endpoints may w= ant to reduce their advertised MSS on IPv6 connections in case the peer isn= 't respecting that guidance. Is noncompliance with this provision a pro= blem in the internet? Are there middleboxes injecting options that cause PM= TU drops or fragmentation?

I have not heard of suc= h problems, but thought I'd check with the community to see if this pre= caution makes any sense at all.

Thanks,
= Martin


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


--0000000000008fdf4f05b20c4587-- From nobody Mon Oct 19 14:47:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D03A0B5A for ; Mon, 19 Oct 2020 14:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 atUN-3dbNuKj for ; Mon, 19 Oct 2020 14:47:34 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 B98433A0B59 for ; Mon, 19 Oct 2020 14:47:34 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kUd06-0003jP-Hm; Mon, 19 Oct 2020 23:47:30 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.12]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kUd05-000DPq-OF; Mon, 19 Oct 2020 23:47:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Michael Welzl In-Reply-To: Date: Mon, 19 Oct 2020 23:47:29 +0200 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <44DB6DE9-B150-4C2D-B516-A052D325370A@ifi.uio.no> References: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> To: Matt Mathis X-Mailer: Apple Mail (2.3445.104.17) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.12]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.043, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 54E761443882214297A6CE1F47C56EE47D3FF946 Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 21:47:37 -0000 Hi, In line: > On Oct 19, 2020, at 7:20 PM, Matt Mathis = wrote: >=20 > The heuristic was designed to address the "double drops" that you = noted. Both RFC 6675 and PRR-SSRB can be too aggressive in situations = where there are burst losses that cause the flight size to fall below = ssthresh. Sometimes these are ok, but they often cause lost = retransmissions. The new heuristic is to prevent these situation from = persisting. I get that, but what I=E2=80=99m concerned about is a case where pipe is = *not* below ssthresh, so the heuristics don=E2=80=99t even apply. It=E2=80= =99s enough to consider the =E2=80=9Cdiagram" on page 7, where it=E2=80=99= s clear that RFC 6675 takes a break from segment 4 to 11 but PRR (or = rate-halving) doesn=E2=80=99t. This is fine when the new rate is smaller = than the bottleneck=E2=80=99s capacity, but if it=E2=80=99s not, the = queue should just overflow again, I believe. (again, these are all more suspicions than anything else - I only have = indications, from our own experiments and the paper I pointed to, = nothing really clear that shows that this really happens; come to think = of it, it actually wouldn=E2=80=99t be hard for me to run a check in our = testbed=E2=80=A6 perhaps that would be better than making a fuss here = about something that may turn out to be nothing. Then again, maybe = it=E2=80=99s a good conversation to have anyway, just to see what the = thinking around this type of concern is.) > These situations are hard to reason about because they can not be = caused by events that are modeled by simple queues. The Flatch paper is = about token bucket policers which cause huge losses when they run out of = tokens -- all without significant queues. Other potential events = include bursty cross traffic from long RTT or non-responsive flows. Ok, but that=E2=80=99s not the case I mean, mine is simpler (above). = Even just a single packet loss would suffice for the situation I=E2=80=99m= talking about. > With packet conservation, a single flow can not cause self inflicted = losses that last more than one RTT, and thus can't cause lost = retransmissions. Hmmmmmm=E2=80=A6.. I doubt this; I think the backoff factor and queue = also play a role. The point is that the new cwnd may be too much, just = like the old was too much. > If there are lost retransmissions something happened that is = outside the scope a simple network model. >=20 > While I agree that 6675's half RTT of silence reduces queue pressure, = the responsibility for that really belongs to congestion control, which = should not be controlling against queue full. I agree with the thought, but in IETF terms I think that a recovery = mechanism in a PS RFC has to be compatible with RFC 5681 too. > The goal of PRR is to minimize the opportunities to lose the self = clock by accurately controlling flightsize to the target set by the = congestion control. >=20 > The heuristic also helps in the situation where there was a large step = change in the available bandwidth, and the CC can not possibly estimate = the the correct flightsize quickly enough.=20 I understand; generally, I don=E2=80=99t doubt that there are many good = aspects to PRR, and that it will work better than RFC 6675 in many = cases. The half-RTT-of-nothing pattern is just odd. So maybe what I=E2=80=99m worrying about is a corner case. But, as we = talk about proceeding to PS, I think it deserves a thought. Cheers, Michael From nobody Mon Oct 19 15:10:55 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B669C3A0C44 for ; Mon, 19 Oct 2020 15:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl44Po1vQr76 for ; Mon, 19 Oct 2020 15:10:52 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521CC3A0C3F for ; Mon, 19 Oct 2020 15:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zu6MT7t11gnLSxVJ4sCLBMsBwlfiYQFC8cPKgfnZAR4=; b=we70Awx++gNos7KLBk7giG0Uk Dp83ipbJD5Q1JwfSAGGtUaso8Og26nvkIEv90HNJwrLFKCxWaCONqzIlak9MdKGsuIJ2JI/YaXGS6 DrgmmuZ8zwlZvJSZrI15baOb3gSWkUwAayKqKl7JADSuKrMsWupZWgNIt6G0xQIt/AArEaXPN1Sf0 YBIaYNiZNUOddmaJbBdSLixZ+oXhuCnJqncKVhoHmR2Xg1ekuAC3w2jGD6eDiy8odErRuJjsR+ypg 2oOK/NuDwOpTvhfqmioBadysLi2fVFJJvvEQxiQmuz3kFJSzEsO74yB7PSFUVeOrWrSLVOIDZnKf8 +8AsFHvxg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58237 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kUdMb-003aFs-GL; Mon, 19 Oct 2020 18:10:50 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> Date: Mon, 19 Oct 2020 15:10:44 -0700 Cc: Martin Duke , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <878A12B3-E020-458F-A3E3-88F19D7A6476@strayalpha.com> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-0.2 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] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 22:10:54 -0000 Hi, all, I agree with Michael=E2=80=99s note below. The key to understanding it is this: - the party that sends the MSS indicates the MSS with fixed IP = and TCP headers - the party that receives the MSS and apples it would then = subtract *the options it adds* And no, nobody subtracts to account for Middleboxes adding options - = because they shouldn=E2=80=99t be doing that and doing so would = undermine nearly all of how path MTU and MSS works in the Internet. Joe > On Oct 19, 2020, at 12:58 PM, Michael Tuexen = wrote: >=20 >=20 >=20 >> On 19. Oct 2020, at 21:22, Martin Duke = wrote: >>=20 >> Hello tcpm, >>=20 >> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST = consider all IP and TCP options when sizing payloads with respect to the = advertised MSS option. >>=20 >> I'm reviewing a document that advises that some endpoints may want to = reduce their advertised MSS on IPv6 connections in case the peer isn't = respecting that guidance. Is noncompliance with this provision a problem = in the internet? Are there middleboxes injecting options that cause PMTU = drops or fragmentation? > Hi Martin, >=20 > the document you are reviewing says: >=20 > An IPv6 datagram size exceeding 1280 bytes can be avoided by setting > the TCP MSS not larger than 1220 bytes. This assumes that the = remote > sender will use no TCP options, aside from possibly the MSS option, > which is only used in the initial TCP SYN packet. >=20 > The first sentence is correct. The second is not. I would suggest to = simply > remove it. >=20 > Then the text says: >=20 > In order to accommodate unrequested TCP options that may be used by > some TCP implementations, a constrained device may advertise an MSS > smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note = that > it is advised for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. Therefore, the suggestion of > advertising an MSS smaller than 1220 bytes is likely to be > overcautious and its suitability should be considered carefully. >=20 > I read this as "use a smaller MSS", but this is "likely to be > overcautious and its suitability should be considered carefully." >=20 > I think the careful consideration is to remove this paragraph. >=20 > Best regards > Michael >=20 >=20 >=20 >=20 >>=20 >> I have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all. >>=20 >> Thanks, >> Martin >>=20 >>=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 Mon Oct 19 15:15:41 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE393A0CB0 for ; Mon, 19 Oct 2020 15:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rruJ6BVIQyI for ; Mon, 19 Oct 2020 15:15:38 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31FE3A0CA0 for ; Mon, 19 Oct 2020 15:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Us2ooXnXUzlK7QklanQxaqZ0gZZKhKu9FRtPdlFqKFM=; b=R77Mtkw3c8ZJzXE9D18TOVhHT DR+d0I0TvCmAqRnhE/BV05fll/I73B8A1ndefKN9CU31Z0W9UxV05vTI4X7G0sRyggPvoahEnrExf FXBvHk7Z2Gwla97g0g+OVsrf1/jq1XEadZ0dcPjGUSc5mLAHPd4+QcG7YnR0mObaZ++xEuzkBe8PO 62gxhImLV/1pf1zmIHqIQt+rXzB0nmE2YJLe/nQYGDW/hWv3V0ieQdBQUEjJdzDBQxbneeO3EFb75 eVUgTh9XhYKf8S0B1BuYifrV7QDmQGfvWTg26mle9D5cBGv+19qPxzZtjtGLEwBtMU1R0TPhgIAAY d5cdrRQbA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58283 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kUdRF-003eGG-RN; Mon, 19 Oct 2020 18:15:38 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_2CF3765F-3167-4E27-A132-AA513FEF1350" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Mon, 19 Oct 2020 15:15:33 -0700 Cc: "tcpm@ietf.org Extensions" Message-Id: <328DB0B6-4612-4737-A36D-FB26724EA4E5@strayalpha.com> References: <0572D865-F831-4B3A-9A8B-6A9C4D154859@strayalpha.com> <719D9BE6-3C5F-4121-B362-BD21FEDC941A@strayalpha.com> To: Martin Duke X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 22:15:41 -0000 --Apple-Mail=_2CF3765F-3167-4E27-A132-AA513FEF1350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Martin, > On Oct 19, 2020, at 1:50 PM, Martin Duke = wrote: >=20 > Hi Joe, >=20 > I may have phrased it ambiguously but I understand the intent of = 1122/6691 as you describe it. RFC6691 was written to clear up the ambiguity and conflicting info in = other docs. > IOAM does add IPv6 options at times, although it should scrub them = before it leaves the domain.=20 That is NOT OK.=20 I don=E2=80=99t know why its not very clear that this is incorrect, but = just to be clear: No subdomain should increase the size of a packet UNLESS it can = GUARANTEE that it supports *all types of* MTUs that are equivalently = LARGER than the minimums required as well as those reported outside the = domain. I.e., let=E2=80=99s say the domain adds 20 bytes. Then it CANNOT use = equipment that supports only 1280B path MTUs and 1500B reassembly MTUs; = it needs to have equipment throughout that supports at least 1300B path = MTUs and 1520B reassembly MTUs. Unless the subdomain has those guarantees, it can=E2=80=99t increase = packet sizes. Even then, it=E2=80=99s playing with space the endpoints = =E2=80=9Cown=E2=80=9D (e.g., of the limits of IPv4 or TCP option space), = and NO subdomain mods can make the increased packet size work. Overall, this is a VERY BAD IDEA and should NOT be endorsed by the IETF = in any way, shape, or form - including experimentally. Joe >=20 > Thanks > Martin >=20 > On Mon, Oct 19, 2020 at 12:44 PM Joseph Touch > wrote: > To be more clear: >=20 > The MSS value in the TCP option reflects the FIXED headers only. >=20 > The sending side uses that value, together with its knowledge of = options it adds, to reduce the size of the data sent to fit. >=20 > Second guessing that information is problematic; sure, when something = gets through you can always try something smaller but that=E2=80=99s not = specific to TCP or anything else. >=20 > Middleboxes should never make a packet larger under any circumstances. >=20 > Joe >=20 >> On Oct 19, 2020, at 12:37 PM, Joseph Touch > wrote: >>=20 >> See RFC 6691. >>=20 >> Only the fixed headers are considered, NOT the options. >>=20 >> Joe >>=20 >>> On Oct 19, 2020, at 12:22 PM, Martin Duke > wrote: >>>=20 >>> Hello tcpm, >>>=20 >>> Section 4.2.2.6 of RFC 1122 = is pretty clear = that the TCP sender MUST consider all IP and TCP options when sizing = payloads with respect to the advertised MSS option. >>>=20 >>> I'm reviewing a document = that advises that some endpoints may want = to reduce their advertised MSS on IPv6 connections in case the peer = isn't respecting that guidance. Is noncompliance with this provision a = problem in the internet? Are there middleboxes injecting options that = cause PMTU drops or fragmentation? >>>=20 >>> I have not heard of such problems, but thought I'd check with the = community to see if this precaution makes any sense at all. >>>=20 >>> Thanks, >>> Martin >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm = >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_2CF3765F-3167-4E27-A132-AA513FEF1350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Martin,

On Oct 19, 2020, at 1:50 PM, Martin Duke = <martin.h.duke@gmail.com> wrote:

Hi Joe,

I = may have phrased it ambiguously but I understand the intent of 1122/6691 = as you describe it.

RFC6691 was written to clear up the ambiguity and = conflicting info in other docs.

IOAM does add IPv6 options at times, although it = should scrub them before it leaves the = domain. 

That is NOT OK. 

I don=E2=80=99t know why its not very clear that = this is incorrect, but just to be clear:

No subdomain should increase the = size of a packet UNLESS it can GUARANTEE that it supports *all types of* = MTUs that are equivalently LARGER than the minimums required as well as = those reported outside the domain.

I.e., let=E2=80=99s say the domain adds 20 bytes. = Then it CANNOT use equipment that supports only 1280B path MTUs and = 1500B reassembly MTUs; it needs to have equipment throughout that = supports at least 1300B path MTUs and 1520B reassembly = MTUs.

Unless the subdomain has those = guarantees, it can=E2=80=99t increase packet sizes. Even then, it=E2=80=99= s playing with space the endpoints =E2=80=9Cown=E2=80=9D (e.g., of the = limits of IPv4 or TCP option space), and NO subdomain mods can make the = increased packet size work.

Overall, = this is a VERY BAD IDEA and should NOT be endorsed by the IETF in any = way, shape, or form - including experimentally.

Joe


Thanks
Martin

On Mon, Oct = 19, 2020 at 12:44 PM Joseph Touch <touch@strayalpha.com> wrote:
To be more clear:

The MSS value in the TCP option = reflects the FIXED headers only.

The sending side uses that value, = together with its knowledge of options it adds, to reduce the size of = the data sent to fit.

Second guessing that information is problematic; sure, when = something gets through you can always try something smaller but that=E2=80= =99s not specific to TCP or anything else.

Middleboxes should never make a packet = larger under any circumstances.

Joe

On Oct 19, 2020, at 12:37 PM, Joseph Touch = <touch@strayalpha.com> wrote:

See RFC = 6691.

Only the fixed = headers are considered, NOT the options.

Joe

On Oct = 19, 2020, at 12:22 PM, Martin Duke <martin.h.duke@gmail.com> wrote:

Hello tcpm,

Section 4.2.2.6 of RFC 1122 is pretty clear = that the TCP sender MUST consider all IP and TCP options when sizing = payloads with respect to the advertised MSS option.

I'm reviewing a = document that advises that some endpoints may want to reduce their = advertised MSS on IPv6 connections in case the peer isn't respecting = that guidance. Is noncompliance with this provision a problem in the = internet? Are there middleboxes injecting options that cause PMTU drops = or fragmentation?

I have not heard of such problems, but thought I'd check with = the community to see if this precaution makes any sense at = all.

Thanks,
Martin


_______________________________________________
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=_2CF3765F-3167-4E27-A132-AA513FEF1350-- From nobody Mon Oct 19 22:25:36 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADC33A0D39 for ; Mon, 19 Oct 2020 22:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 OjLbdp8r4tKZ for ; Mon, 19 Oct 2020 22:25:33 -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 D43853A0D86 for ; Mon, 19 Oct 2020 22:25:32 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id k21so1283170ioa.9 for ; Mon, 19 Oct 2020 22:25:32 -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=2W3XCqrpALL31MNbqqoXvUQrq0G9z6nK8N8XPUBoez0=; b=aA81MH5RGDIZxxTEEoLvxgNMB76uA9zyYnOgy26yvDKTNwjCRQz35V+wYWnvNHqfbx EUJhve16SYRCItt26GOE5Bwf8VLQuvRU9ViBU6gRILETrQ6zA3qbf+QksGfoYUMYdZei sC7mxrshrJRwFja01xxxn2hm+m1pDmGEYwLcMMLaHUsDQimREF1mqQ98OcS6Xck7WQtl V7CQ6DIcLMn45JEuy7WMDRz5GIZrPh3hJOwfkYp6Ot7b3HxBcBXoaPiAOeCPkQb4+14a bhP9B/eu4oU5K2ysuZ6iexmF+M+/dL5Wkq2g9RXhzDgxs1HL3YStZfPATTvQaro+W9FJ KIOg== 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=2W3XCqrpALL31MNbqqoXvUQrq0G9z6nK8N8XPUBoez0=; b=b3ckHs0d6hXx0xjG8CUKbTYScCCf3AEgU8x1/2wtoDQKrdXUOhDUQbzdoVMJTnqr4/ N8gSR9P16sVMDMQoUvnI2rLIxFGXxpKM0zN93sDu84yvvga59YN5YhPVQt+LMA2uCwIP iA6b6RwwHCPmJyw0BjcMBtRkU7whflnH86y2Zo00benNLy952+xJg9LaUm7revcZGXdQ VxRZzwV3+rbkhLFinKzJcFiGI59MuBFZoUhXBoOhZ5YI4JOIDQizQNHzPALOVq517yK0 fdvVSimtbe0vYnBx9tisJ6FWh0R6WqnHf9hjWtuWmACAFoVb9pP7gMMH6OnNDS5evYiU 4Qig== X-Gm-Message-State: AOAM533oybT9xH+stdVBcpj80xfBPMXX5kWqOEHbkUYdIu5GY/+FDJEe wz18+/ZHHM2gCvcyg3SrkTXyozIFswnpqtnr+lRLWw== X-Google-Smtp-Source: ABdhPJxqkNAi26ruG7YmvYpi6yIgA1FihEjlLSsH2cXNjHw7LPOROS4shu4C7z9XvO4f1LkBaObBzr8m6v4EvEZpACA= X-Received: by 2002:a6b:7c01:: with SMTP id m1mr931781iok.47.1603171531828; Mon, 19 Oct 2020 22:25:31 -0700 (PDT) MIME-Version: 1.0 References: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> <44DB6DE9-B150-4C2D-B516-A052D325370A@ifi.uio.no> In-Reply-To: <44DB6DE9-B150-4C2D-B516-A052D325370A@ifi.uio.no> From: Matt Mathis Date: Mon, 19 Oct 2020 22:25:19 -0700 Message-ID: To: Michael Welzl Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000ab859505b2137521" Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 05:25:35 -0000 --000000000000ab859505b2137521 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't understand the situation you are thinking about. If the bottleneck BW changes and it causes loss any loss, you would expect to see a whole RTT of periodic losses between the first detected loss, and the ACK from the first retransmission. If inflight (aka pipe) is larger than ssthresh, PRR will always send less data than has left the network. This is guaranteed by the conservative self clock and the "proportional" part of the algorithm. Yes it drains the queue slowly, and yes cross traffic can cause additional losses, but that is because the cross traffic is being too aggressive (e.g. the cross traffic has to still be increasing its instantaneous rate for some reason). Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Mon, Oct 19, 2020 at 2:47 PM Michael Welzl wrote: > Hi, > > In line: > > > On Oct 19, 2020, at 7:20 PM, Matt Mathis wrote: > > > > The heuristic was designed to address the "double drops" that you > noted. Both RFC 6675 and PRR-SSRB can be too aggressive in situations > where there are burst losses that cause the flight size to fall below > ssthresh. Sometimes these are ok, but they often cause lost > retransmissions. The new heuristic is to prevent these situation from > persisting. > > I get that, but what I=E2=80=99m concerned about is a case where pipe is = *not* > below ssthresh, so the heuristics don=E2=80=99t even apply. It=E2=80=99s = enough to consider > the =E2=80=9Cdiagram" on page 7, where it=E2=80=99s clear that RFC 6675 t= akes a break from > segment 4 to 11 but PRR (or rate-halving) doesn=E2=80=99t. This is fine w= hen the > new rate is smaller than the bottleneck=E2=80=99s capacity, but if it=E2= =80=99s not, the > queue should just overflow again, I believe. > > (again, these are all more suspicions than anything else - I only have > indications, from our own experiments and the paper I pointed to, nothing > really clear that shows that this really happens; come to think of it, it > actually wouldn=E2=80=99t be hard for me to run a check in our testbed=E2= =80=A6 perhaps > that would be better than making a fuss here about something that may tur= n > out to be nothing. Then again, maybe it=E2=80=99s a good conversation to = have > anyway, just to see what the thinking around this type of concern is.) > > > > These situations are hard to reason about because they can not be cause= d > by events that are modeled by simple queues. The Flatch paper is about > token bucket policers which cause huge losses when they run out of tokens > -- all without significant queues. Other potential events include bursty > cross traffic from long RTT or non-responsive flows. > > Ok, but that=E2=80=99s not the case I mean, mine is simpler (above). Even= just a > single packet loss would suffice for the situation I=E2=80=99m talking ab= out. > > > > With packet conservation, a single flow can not cause self inflicted > losses that last more than one RTT, and thus can't cause lost > retransmissions. > > Hmmmmmm=E2=80=A6.. I doubt this; I think the backoff factor and queue als= o play a > role. The point is that the new cwnd may be too much, just like the old w= as > too much. > > > > If there are lost retransmissions something happened that is outsid= e > the scope a simple network model. > > > > While I agree that 6675's half RTT of silence reduces queue pressure, > the responsibility for that really belongs to congestion control, which > should not be controlling against queue full. > > I agree with the thought, but in IETF terms I think that a recovery > mechanism in a PS RFC has to be compatible with RFC 5681 too. > > > > The goal of PRR is to minimize the opportunities to lose the self > clock by accurately controlling flightsize to the target set by the > congestion control. > > > > The heuristic also helps in the situation where there was a large step > change in the available bandwidth, and the CC can not possibly estimate t= he > the correct flightsize quickly enough. > > I understand; generally, I don=E2=80=99t doubt that there are many good a= spects to > PRR, and that it will work better than RFC 6675 in many cases. The > half-RTT-of-nothing pattern is just odd. > So maybe what I=E2=80=99m worrying about is a corner case. But, as we tal= k about > proceeding to PS, I think it deserves a thought. > > Cheers, > Michael > > --000000000000ab859505b2137521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't understand the situation you are thinking abou= t.=C2=A0 If the bottleneck BW changes and it causes loss any loss, you woul= d expect to see a whole RTT of periodic losses between the first detected l= oss, and the ACK from the first retransmission.=C2=A0 If inflight (aka pipe= ) is larger than ssthresh, PRR will always=C2=A0send less data than has lef= t the network.=C2=A0 This is guaranteed=C2=A0by the
conservative self c= lock and the "proportional" part of the algorithm.=C2=A0 Yes it d= rains the queue slowly, and yes cross traffic can cause additional losses, = but that is because the cross traffic is being too aggressive (e.g. the cro= ss traffic has to still be increasing its instantaneous rate for some reaso= n).

Thanks,
--MM--
The best way to predi= ct the future is to create it. =C2=A0- Alan Kay

We must not tolerate= intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our = response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 too strong would be hypocritical and risks spiraling o= ut of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak= risks being mistaken for tacit approval.


On Mon, Oct 19, 2020 at 2:47 PM Michael Welzl <michawe@ifi.uio.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi,

In line:

> On Oct 19, 2020, at 7:20 PM, Matt Mathis <mattmathis@google.com> wrote:
>
> The heuristic was designed to address the "double drops" tha= t you noted.=C2=A0 =C2=A0 Both RFC 6675 and PRR-SSRB can be too aggressive = in situations where there are burst losses that cause the flight size to fa= ll below ssthresh.=C2=A0 Sometimes these are ok, but they often cause lost = retransmissions.=C2=A0 The new heuristic is to prevent these situation from= persisting.

I get that, but what I=E2=80=99m concerned about is a case where pipe is *n= ot* below ssthresh, so the heuristics don=E2=80=99t even apply. It=E2=80=99= s enough to consider the =E2=80=9Cdiagram" on page 7, where it=E2=80= =99s clear that RFC 6675 takes a break from segment 4 to 11 but PRR (or rat= e-halving) doesn=E2=80=99t. This is fine when the new rate is smaller than = the bottleneck=E2=80=99s capacity, but if it=E2=80=99s not, the queue shoul= d just overflow again, I believe.

(again, these are all more suspicions than anything else - I only have indi= cations, from our own experiments and the paper I pointed to, nothing reall= y clear that shows that this really happens; come to think of it, it actual= ly wouldn=E2=80=99t be hard for me to run a check in our testbed=E2=80=A6 p= erhaps that would be better than making a fuss here about something that ma= y turn out to be nothing. Then again, maybe it=E2=80=99s a good conversatio= n to have anyway, just to see what the thinking around this type of concern= is.)


> These situations are hard to reason about because they can not be caus= ed by events that are modeled by simple queues.=C2=A0 The Flatch paper is a= bout token bucket policers which cause huge losses when they run out of tok= ens -- all without significant queues.=C2=A0 Other potential events include= bursty cross traffic from long RTT or non-responsive flows.

Ok, but that=E2=80=99s not the case I mean, mine is simpler (above). Even j= ust a single packet loss would suffice for the situation I=E2=80=99m talkin= g about.


> With packet conservation, a single flow can not cause self inflicted l= osses that last more than one RTT, and thus can't cause lost retransmis= sions.

Hmmmmmm=E2=80=A6.. I doubt this; I think the backoff factor and queue also = play a role. The point is that the new cwnd may be too much, just like the = old was too much.


>=C2=A0 =C2=A0 =C2=A0If there are lost retransmissions something happene= d that is outside the scope a simple network model.
>
> While I agree that 6675's half RTT of silence reduces queue pressu= re, the responsibility for that really belongs to congestion control, which= should not be controlling against queue full.

I agree with the thought, but in IETF terms I think that a recovery mechani= sm in a PS RFC has to be compatible with RFC 5681 too.


>=C2=A0 =C2=A0The goal of PRR is to minimize the opportunities to lose t= he self clock by accurately controlling flightsize to the target set by the= congestion control.
>
> The heuristic also helps in the situation where there was a large step= change in the available bandwidth, and the CC can not possibly estimate th= e the correct flightsize quickly enough.

I understand; generally, I don=E2=80=99t doubt that there are many good asp= ects to PRR, and that it will work better than RFC 6675 in many cases. The = half-RTT-of-nothing pattern is just odd.
So maybe what I=E2=80=99m worrying about is a corner case. But, as we talk = about proceeding to PS, I think it deserves a thought.

Cheers,
Michael

--000000000000ab859505b2137521-- From nobody Mon Oct 19 23:11:40 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3032F3A0FFB for ; Mon, 19 Oct 2020 23:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra_Sq7KN2QKH for ; Mon, 19 Oct 2020 23:11:37 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 D83A83A0FFA for ; Mon, 19 Oct 2020 23:11:36 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kUkru-000FkK-HT; Tue, 20 Oct 2020 08:11:34 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kUkrt-000Czo-L3; Tue, 20 Oct 2020 08:11:34 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Tue, 20 Oct 2020 08:11:32 +0200 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <365A684B-6AC8-4DF4-9312-A934423DE7BA@ifi.uio.no> References: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> <44DB6DE9-B150-4C2D-B516-A052D325370A@ifi.uio.no> To: Matt Mathis X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.027, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 862DD307F41DA3D37418306FEFEDC4AEC37A6631 Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 06:11:39 -0000 Hi again, You don't understand it because it doesn't make sense; I get it now, and = I was just wrong, I'm sorry. I've recently been thinking too much about a paced, non-ack-clocked = behavior, where things might indeed play out as I described, even with = an overshoot of only one segment. With ACK clocking, as you said, that can't happen. In fact, I can see it = become a problem only in one case: when the overshoot is so high that = setting back the cwnd won't save you, even with ack clocking. But I = think this translates exactly into "pipe < ssthresh", and this is the = case that the heuristics cover - which, as you said, were designed to = handle these double drops (*). So it all makes sense to me now, sorry = for this excursion into the land on nonsense. Case closed, go home = everyone, nothing to see here! :-) Cheers, Michael -- (*) In practice, I therefore think that these heuristics can play an = important role after the very first slow start. > On 20 Oct 2020, at 07:25, Matt Mathis wrote: >=20 > I don't understand the situation you are thinking about. If the = bottleneck BW changes and it causes loss any loss, you would expect to = see a whole RTT of periodic losses between the first detected loss, and = the ACK from the first retransmission. If inflight (aka pipe) is larger = than ssthresh, PRR will always send less data than has left the network. = This is guaranteed by the > conservative self clock and the "proportional" part of the algorithm. = Yes it drains the queue slowly, and yes cross traffic can cause = additional losses, but that is because the cross traffic is being too = aggressive (e.g. the cross traffic has to still be increasing its = instantaneous rate for some reason). >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > We must not tolerate intolerance; > however our response must be carefully measured:=20 > too strong would be hypocritical and risks spiraling out = of control; > too weak risks being mistaken for tacit approval. >=20 >=20 > On Mon, Oct 19, 2020 at 2:47 PM Michael Welzl = wrote: > Hi, >=20 > In line: >=20 > > On Oct 19, 2020, at 7:20 PM, Matt Mathis = wrote: > >=20 > > The heuristic was designed to address the "double drops" that you = noted. Both RFC 6675 and PRR-SSRB can be too aggressive in situations = where there are burst losses that cause the flight size to fall below = ssthresh. Sometimes these are ok, but they often cause lost = retransmissions. The new heuristic is to prevent these situation from = persisting. >=20 > I get that, but what I=E2=80=99m concerned about is a case where pipe = is *not* below ssthresh, so the heuristics don=E2=80=99t even apply. = It=E2=80=99s enough to consider the =E2=80=9Cdiagram" on page 7, where = it=E2=80=99s clear that RFC 6675 takes a break from segment 4 to 11 but = PRR (or rate-halving) doesn=E2=80=99t. This is fine when the new rate is = smaller than the bottleneck=E2=80=99s capacity, but if it=E2=80=99s not, = the queue should just overflow again, I believe. >=20 > (again, these are all more suspicions than anything else - I only have = indications, from our own experiments and the paper I pointed to, = nothing really clear that shows that this really happens; come to think = of it, it actually wouldn=E2=80=99t be hard for me to run a check in our = testbed=E2=80=A6 perhaps that would be better than making a fuss here = about something that may turn out to be nothing. Then again, maybe = it=E2=80=99s a good conversation to have anyway, just to see what the = thinking around this type of concern is.) >=20 >=20 > > These situations are hard to reason about because they can not be = caused by events that are modeled by simple queues. The Flatch paper is = about token bucket policers which cause huge losses when they run out of = tokens -- all without significant queues. Other potential events = include bursty cross traffic from long RTT or non-responsive flows. >=20 > Ok, but that=E2=80=99s not the case I mean, mine is simpler (above). = Even just a single packet loss would suffice for the situation I=E2=80=99m= talking about. >=20 >=20 > > With packet conservation, a single flow can not cause self inflicted = losses that last more than one RTT, and thus can't cause lost = retransmissions. >=20 > Hmmmmmm=E2=80=A6.. I doubt this; I think the backoff factor and queue = also play a role. The point is that the new cwnd may be too much, just = like the old was too much. >=20 >=20 > > If there are lost retransmissions something happened that is = outside the scope a simple network model. > >=20 > > While I agree that 6675's half RTT of silence reduces queue = pressure, the responsibility for that really belongs to congestion = control, which should not be controlling against queue full. >=20 > I agree with the thought, but in IETF terms I think that a recovery = mechanism in a PS RFC has to be compatible with RFC 5681 too. >=20 >=20 > > The goal of PRR is to minimize the opportunities to lose the self = clock by accurately controlling flightsize to the target set by the = congestion control. > >=20 > > The heuristic also helps in the situation where there was a large = step change in the available bandwidth, and the CC can not possibly = estimate the the correct flightsize quickly enough.=20 >=20 > I understand; generally, I don=E2=80=99t doubt that there are many = good aspects to PRR, and that it will work better than RFC 6675 in many = cases. The half-RTT-of-nothing pattern is just odd. > So maybe what I=E2=80=99m worrying about is a corner case. But, as we = talk about proceeding to PS, I think it deserves a thought. >=20 > Cheers, > Michael >=20 From nobody Tue Oct 20 02:11:31 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04533A0B22 for ; Tue, 20 Oct 2020 02:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, 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 igSoKscpLzwp for ; Tue, 20 Oct 2020 02:11:26 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A15493A0B0E for ; Tue, 20 Oct 2020 02:11:19 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3D03A1B0020A; Tue, 20 Oct 2020 10:10:46 +0100 (BST) To: Martin Duke , "tcpm@ietf.org Extensions" References: From: Gorry Fairhurst Message-ID: Date: Tue, 20 Oct 2020 10:10:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F61813159833A96C1BC8A056" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 09:11:30 -0000 This is a multi-part message in MIME format. --------------F61813159833A96C1BC8A056 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 19/10/2020 20:22, Martin Duke wrote: > Hello tcpm, > > Section 4.2.2.6 of RFC 1122 > is pretty > clear that the TCP sender MUST consider all IP and TCP options when > sizing payloads with respect to the advertised MSS option. > > I'm reviewing a document > > that advises that some endpoints may want to reduce their advertised > MSS on IPv6 connections in case the peer isn't respecting that > guidance. Is noncompliance with this provision a problem in the > internet? Are there middleboxes injecting options that cause PMTU > drops or fragmentation? > > I have not heard of such problems, but thought I'd check with the > community to see if this precaution makes any sense at all. > > Thanks, > Martin > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Hi Martin, While a server advertising a restricted MSS clearly reduces the TCP packet size, it seems to me to be a rather poor solution to the problem in general, and only works for TCP. If  it wants to say some advices, I think the IETF needs to consider current practice and the implications of this. I suspect the practice of clamping the IPv6 MSS at the server is already quite common, especially in IPv6 servers offering web content. MSS Clamping on-path is also common, but anyway I see some servers advertise an MSS much lower than permitted by the MTU. For example, see the section on MSS handling here: https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf This might be because of the reasons for this are cited in RFC8900. Gorry --------------F61813159833A96C1BC8A056 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 19/10/2020 20:22, Martin Duke wrote:
Hello tcpm,

Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST consider all IP and TCP options when sizing payloads with respect to the advertised MSS option.

I'm reviewing a document that advises that some endpoints may want to reduce their advertised MSS on IPv6 connections in case the peer isn't respecting that guidance. Is noncompliance with this provision a problem in the internet? Are there middleboxes injecting options that cause PMTU drops or fragmentation?

I have not heard of such problems, but thought I'd check with the community to see if this precaution makes any sense at all.

Thanks,
Martin


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

Hi Martin,

While a server advertising a restricted MSS clearly reduces the TCP packet size, it seems to me to be a rather poor solution to the problem in general, and only works for TCP.

If  it wants to say some advices, I think the IETF needs to consider current practice and the implications of this. I suspect the practice of clamping the IPv6 MSS at the server is already quite common, especially in IPv6 servers offering web content. MSS Clamping on-path is also common, but anyway I see some servers advertise an MSS much lower than permitted by the MTU. For example, see the section on MSS handling here:

https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf

This might be because of the reasons for this are cited in RFC8900.

Gorry

--------------F61813159833A96C1BC8A056-- From nobody Tue Oct 20 05:56:38 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3238A3A0AAD for ; Tue, 20 Oct 2020 05:56:37 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq4CYT9BDHkj for ; Tue, 20 Oct 2020 05:56:35 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2051.outbound.protection.outlook.com [40.107.20.51]) (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 DEF943A0AAA for ; Tue, 20 Oct 2020 05:56:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vuk4cvsf1sGV3JZLMDMutENyJvGxJzIPgzuV+lWJC9nElS+mYuMqu2pi9E6iwzN+w8FvSjZ06o8VmciXQWHu+Z6UByLIo5p5Bg/zTRiqpV/zVtFr4XFqcALSBNXcOtPzM/Fc0I6o7l4WwxT+yQ7G8i0rRidbYQnJzPy1AmMvE99AZOFdocEsbRFzM22iuVSwEkVIsreYhAEahu497a2jvfOFWrBwDY0C4lq4ksJFcREameVB0EnTHRMpJxJz71SuM0gtG/hjNJG/3IChqLEs3oKVvaQjU1rkrUGEV7NTuklCKRQSI+wcM72RsaBYPn9/MIl/6UMxs4VrDjjYfekimw== 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=cjaUClaXZ9MkPoJQ3JJf40kvcnBIoDopqZrXz9ZOh+0=; b=TNxGldN90uAke+lFePkMbkZU45KiR/ELuD706yxbWoRB8dAbxB3cxXmNLpL6OL36gjzFM/iclmhXRfepW7Sv8O0gcAmLaL7rUzsYJ5vw7v5BeN70AyXeiK/Uo2qiZhqvq/yGW80gBC+WEhucvvSyOuN9aSbZktm0Ambrrq0qoWAdmpSSQivhD375uAZPsCDBmyA5nUJ6QH7+mU1+5vcPr5vI24wvbVEWmL1RbE1gPDl71A/+d0/WcVVikNburgXi1L89B4rgtVU5DvDtxXPemuJ6wijK51tDW+olA4J8nol3BIP6uFzPkTzI8O/Xb4Q77eipeaIRDbyKcLavveXv+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cjaUClaXZ9MkPoJQ3JJf40kvcnBIoDopqZrXz9ZOh+0=; b=cy7KntghBNXg7jTNcDuJF6N4rIK9QUT7067rC4fcPZZzQ7U7mwE81o0Eeg38/HUd3VhS4GRV2vGpAq/eBVoT54x3jqs/XRk7iTX4Y1OcvijgBX0zEPXIFnPLBgnW8cKVvR5qhKOOdtCeVQRxOp3cZEl/1MCVPgA1woXWjzDZkEY= Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com (2603:10a6:208:19::10) by AM0PR07MB4724.eurprd07.prod.outlook.com (2603:10a6:208:7a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.11; Tue, 20 Oct 2020 12:56:32 +0000 Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::9820:af8a:cdbc:73b0]) by AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::9820:af8a:cdbc:73b0%7]) with mapi id 15.20.3499.017; Tue, 20 Oct 2020 12:56:30 +0000 From: Mirja Kuehlewind To: Gorry Fairhurst , Martin Duke , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Exceeding value in MSS option? Thread-Index: AQHWpk1JHhzQC0EVBEuWzc7YdR1mRamgNS6AgABgmYA= Date: Tue, 20 Oct 2020 12:56:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: erg.abdn.ac.uk; dkim=none (message not signed) header.d=none;erg.abdn.ac.uk; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.209.200.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d91f52b4-0dcb-4abc-12a8-08d874f790ea x-ms-traffictypediagnostic: AM0PR07MB4724: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8OqhDI+X/RUm0CKpr2VPvMIYKP3+pnvwF6KeaZV8pG9YhzyPFSCUZtCFq/FBba6gB4gvQdBeeCQGpo38gUQo0IT5fkli1mHa/qGrwG4tAL3COJLGEdmgH9n0yLBtZrnojTNDAd7IhiD+WtAYdSfcye4xt8rxbEWCH+UGGsSI3mCV6c9F0J9HJJQu/D0405KvzyJhFMsuiwicTEebmY87pAm+LWUtEn5Ho2bPvO9aqyiz4tSIDedJy7zOfWR+GrB8UC3MsBwJu995GW9X/Q4BYd4F6rwfnLVNVDqs2Pmpacks0sqzrVuxQtWHvjZ85O9VVCqUc66Ey25bOslD2iI0ZuCH/Fi60LWRDifTw5t2DcTlGHt8p9W9QwbmSC55oi1xb/vp2ZAol391Bj529KDfR4wWQEPB5i6DNp4fIt+mkPA0DJeY1gdUakmfRbr2C9qs1CLihG30VUBTQcmq4rFssQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3713.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(346002)(39860400002)(136003)(44832011)(36756003)(83380400001)(166002)(66574015)(110136005)(26005)(86362001)(2616005)(966005)(6512007)(478600001)(296002)(316002)(71200400001)(6506007)(53546011)(6486002)(8676002)(186003)(66476007)(66556008)(64756008)(66946007)(66446008)(2906002)(8936002)(76116006)(5660300002)(33656002)(15398625002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aRjJdfOQJa3/W+GvxvOAe8a9HM8t9Q29MaaqVW4QsWz/re1loYxjMkLN+ekBsSONOmfZu6QoXbEw2SsH+vLL7mkDBf8vJBCojyJx7238vS0/5Be4r5IAc++5XY2t9Tz5LqQxJSQcfQMgesj2ECEeRf3brkC9Ew0K8T0FdQF0TVn8K5XGiPLHNnIe0THZ6sYUqx5YX1O3ZcYwh75nsJTRD3hw2w5YlkpUdVxC4KboHxF/S5IkJ5iCSdsVPgmcOao4uboSl9RqL6xIOpPsUrASbUHUVDl2PIJUGeMfJoa8I5WgnzwbvNtTp7pP/FUDNKS3eUAuez8L5tJkLj9emh7KTCKQldF8vCYZe3HuDwluSMAJj89TK0eoPsfB3GoD62rXY47XpAiDiqkJaucp82aHpM6Z+wZ1il1wXtfT+aembDIPaGa6X8zeSEViVLU2SGxI/FCoBYUW4aE9uthae28HspsfdkieD42zMzHiv0AHGXXoO5PWEvIuIVm0hPZ+R23mu7JJYcVcL0+TJViRQXGzOag9aN4DrWDttUQ14WFl5bTSm65CExXks3v8l9PjJqv/rH140jJ+CqS5204ETlFZuJvgp6kJvT5DPjbOUVFn2awr5GSvnGPaKvNTVWqH475+T7h/XMQK8MR5nER+lODtWA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BB0640E4C7A94E1C9F29BD373A220BABericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3713.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d91f52b4-0dcb-4abc-12a8-08d874f790ea X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 12:56:30.8569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VeA/M1jltU9xiLQUn7kjCpdWKHblyFDz1oD76iVtQ4+2XkLyhJJRRm+Tt95ITWeBm5DMRtvUd9aH9+DTDip+cACcIA6aI8EZ1atbHJ86e0s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4724 Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 12:56:37 -0000 --_000_BB0640E4C7A94E1C9F29BD373A220BABericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLCBoaSBHb3JyeSwNCg0KSSB0aGluayBHb3JyeeKAmXMgcGFwZXIgZG9lcyBpbmRp Y2F0ZSB0aGF0IGF0IGxlYXN0IGZvciBNTVMgdGhlcmUgYXJlIG1pZGRsZWJveGVzIHRoYXQgYWRk IHRoaXMgb3B0aW9uLiBIb3dldmVyLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgZXZpZGVuY2Ug dGhhdCB0aGVyZSBpcyBhIGdlbmVyYWwgcHJvYmxlbSBhYm91dCBtaWRkbGVib3ggYWRkaW5nIG9w dGlvbiAocmF0aGVyIHRoYW4gcmVtb3ZpbmcgdGhlbSkuIEkgYWxzbyByZXZpZXdlZCB0aGUgZHJh ZnQgaW4gdHN2LWFydCByZXZpZXcgYW5kIGdpdmVuIHRoYXQgdGhleSBzYXkgaXTigJlzIGFjdHVh bGx5IG5vdCByZWNvbW1lbmRlZCBhbmQgc2hvdWxkIG9ubHkgYmUgZG9uZSB3aXRoIGNhcmUsIEkg dGhvdWdodCB0aGF0IHRleHQgaXMgb2theS4gSG93ZXZlciwgSSBndWVzcyB0aGVyZSBpcyByb29t IHRvIGltcHJvdmUgdGhlIHdvcmRpbmcgYW5kIGV4cGxhaW4gYSBiaXQgYmV0dGVyLCB3aGVuIGFu ZCBpZiB0aGlzIG1pZ2h0IGJlIGNvbnNpZGVyIG9yIG5vdC4NCg0KTWlyamENCg0KDQpGcm9tOiB0 Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBHb3JyeSBGYWlyaHVyc3Qg PGdvcnJ5QGVyZy5hYmRuLmFjLnVrPg0KRGF0ZTogVHVlc2RheSwgMjAuIE9jdG9iZXIgMjAyMCBh dCAxMToxMw0KVG86IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4sICJ0Y3Bt QGlldGYub3JnIEV4dGVuc2lvbnMiIDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0Y3Bt XSBFeGNlZWRpbmcgdmFsdWUgaW4gTVNTIG9wdGlvbj8NCg0KT24gMTkvMTAvMjAyMCAyMDoyMiwg TWFydGluIER1a2Ugd3JvdGU6DQpIZWxsbyB0Y3BtLA0KDQpTZWN0aW9uIDQuMi4yLjYgb2YgUkZD IDExMjI8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmMxMTIyI3BhZ2Ut ODU+IGlzIHByZXR0eSBjbGVhciB0aGF0IHRoZSBUQ1Agc2VuZGVyIE1VU1QgY29uc2lkZXIgYWxs IElQIGFuZCBUQ1Agb3B0aW9ucyB3aGVuIHNpemluZyBwYXlsb2FkcyB3aXRoIHJlc3BlY3QgdG8g dGhlIGFkdmVydGlzZWQgTVNTIG9wdGlvbi4NCg0KSSdtIHJldmlld2luZyBhIGRvY3VtZW50PGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1sd2lnLXRjcC1j b25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTExI3NlY3Rpb24tNC4xLjE+IHRoYXQgYWR2aXNlcyB0 aGF0IHNvbWUgZW5kcG9pbnRzIG1heSB3YW50IHRvIHJlZHVjZSB0aGVpciBhZHZlcnRpc2VkIE1T UyBvbiBJUHY2IGNvbm5lY3Rpb25zIGluIGNhc2UgdGhlIHBlZXIgaXNuJ3QgcmVzcGVjdGluZyB0 aGF0IGd1aWRhbmNlLiBJcyBub25jb21wbGlhbmNlIHdpdGggdGhpcyBwcm92aXNpb24gYSBwcm9i bGVtIGluIHRoZSBpbnRlcm5ldD8gQXJlIHRoZXJlIG1pZGRsZWJveGVzIGluamVjdGluZyBvcHRp b25zIHRoYXQgY2F1c2UgUE1UVSBkcm9wcyBvciBmcmFnbWVudGF0aW9uPw0KDQpJIGhhdmUgbm90 IGhlYXJkIG9mIHN1Y2ggcHJvYmxlbXMsIGJ1dCB0aG91Z2h0IEknZCBjaGVjayB3aXRoIHRoZSBj b21tdW5pdHkgdG8gc2VlIGlmIHRoaXMgcHJlY2F1dGlvbiBtYWtlcyBhbnkgc2Vuc2UgYXQgYWxs Lg0KDQpUaGFua3MsDQpNYXJ0aW4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KdGNwbSBtYWlsaW5nIGxpc3QNCg0KdGNwbUBpZXRmLm9y ZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y3BtDQoNCkhpIE1hcnRpbiwNCg0KV2hpbGUgYSBzZXJ2ZXIgYWR2ZXJ0aXNpbmcg YSByZXN0cmljdGVkIE1TUyBjbGVhcmx5IHJlZHVjZXMgdGhlIFRDUCBwYWNrZXQgc2l6ZSwgaXQg c2VlbXMgdG8gbWUgdG8gYmUgYSByYXRoZXIgcG9vciBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSBp biBnZW5lcmFsLCBhbmQgb25seSB3b3JrcyBmb3IgVENQLg0KDQpJZiAgaXQgd2FudHMgdG8gc2F5 IHNvbWUgYWR2aWNlcywgSSB0aGluayB0aGUgSUVURiBuZWVkcyB0byBjb25zaWRlciBjdXJyZW50 IHByYWN0aWNlIGFuZCB0aGUgaW1wbGljYXRpb25zIG9mIHRoaXMuIEkgc3VzcGVjdCB0aGUgcHJh Y3RpY2Ugb2YgY2xhbXBpbmcgdGhlIElQdjYgTVNTIGF0IHRoZSBzZXJ2ZXIgaXMgYWxyZWFkeSBx dWl0ZSBjb21tb24sIGVzcGVjaWFsbHkgaW4gSVB2NiBzZXJ2ZXJzIG9mZmVyaW5nIHdlYiBjb250 ZW50LiBNU1MgQ2xhbXBpbmcgb24tcGF0aCBpcyBhbHNvIGNvbW1vbiwgYnV0IGFueXdheSBJIHNl ZSBzb21lIHNlcnZlcnMgYWR2ZXJ0aXNlIGFuIE1TUyBtdWNoIGxvd2VyIHRoYW4gcGVybWl0dGVk IGJ5IHRoZSBNVFUuIEZvciBleGFtcGxlLCBzZWUgdGhlIHNlY3Rpb24gb24gTVNTIGhhbmRsaW5n IGhlcmU6DQoNCmh0dHBzOi8vdG1hLmlmaXAub3JnLzIwMTgvd3AtY29udGVudC91cGxvYWRzL3Np dGVzLzMvMjAxOC8wNi90bWEyMDE4X3BhcGVyNTcucGRmPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5 ZS5jb20vdjEvdXJsP2s9Yzk2NGE5MWYtOTdjNDEzNzEtYzk2NGU5ODQtODY2MDM4OTczYTE1LTRj NTM4MDA3MzIyZDgzOTImcT0xJmU9OGI3MmNiYzItNjgzYS00OTNiLWEwNzUtYzlkZjA2N2I4OGY3 JnU9aHR0cHMlM0ElMkYlMkZ0bWEuaWZpcC5vcmclMkYyMDE4JTJGd3AtY29udGVudCUyRnVwbG9h ZHMlMkZzaXRlcyUyRjMlMkYyMDE4JTJGMDYlMkZ0bWEyMDE4X3BhcGVyNTcucGRmPg0KDQpUaGlz IG1pZ2h0IGJlIGJlY2F1c2Ugb2YgdGhlIHJlYXNvbnMgZm9yIHRoaXMgYXJlIGNpdGVkIGluIFJG Qzg5MDAuDQoNCkdvcnJ5DQo= --_000_BB0640E4C7A94E1C9F29BD373A220BABericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F33163C04AFCC4AB5EE08DCC1C7B2F1@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iZW4tREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkg TWFydGluLCBoaSBHb3JyeSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIEdv cnJ54oCZcyBwYXBlciBkb2VzIGluZGljYXRlIHRoYXQgYXQgbGVhc3QgZm9yIE1NUyB0aGVyZSBh cmUgbWlkZGxlYm94ZXMgdGhhdCBhZGQgdGhpcyBvcHRpb24uIEhvd2V2ZXIsIEkgZG9u4oCZdCB0 aGluayB0aGVyZSBpcyBldmlkZW5jZSB0aGF0IHRoZXJlIGlzIGEgZ2VuZXJhbCBwcm9ibGVtIGFi b3V0IG1pZGRsZWJveA0KIGFkZGluZyBvcHRpb24gKHJhdGhlciB0aGFuIHJlbW92aW5nIHRoZW0p LiBJIGFsc28gcmV2aWV3ZWQgdGhlIGRyYWZ0IGluIHRzdi1hcnQgcmV2aWV3IGFuZCBnaXZlbiB0 aGF0IHRoZXkgc2F5IGl04oCZcyBhY3R1YWxseSBub3QgcmVjb21tZW5kZWQgYW5kIHNob3VsZCBv bmx5IGJlIGRvbmUgd2l0aCBjYXJlLCBJIHRob3VnaHQgdGhhdCB0ZXh0IGlzIG9rYXkuIEhvd2V2 ZXIsIEkgZ3Vlc3MgdGhlcmUgaXMgcm9vbSB0byBpbXByb3ZlIHRoZSB3b3JkaW5nDQogYW5kIGV4 cGxhaW4gYSBiaXQgYmV0dGVyLCB3aGVuIGFuZCBpZiB0aGlzIG1pZ2h0IGJlIGNvbnNpZGVyIG9y IG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NaXJqYTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj50Y3BtICZsdDt0 Y3BtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBHb3JyeSBGYWlyaHVyc3QgJmx0 O2dvcnJ5QGVyZy5hYmRuLmFjLnVrJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCAyMC4g T2N0b2JlciAyMDIwIGF0IDExOjEzPGJyPg0KPGI+VG86IDwvYj5NYXJ0aW4gRHVrZSAmbHQ7bWFy dGluLmguZHVrZUBnbWFpbC5jb20mZ3Q7LCAmcXVvdDt0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMm cXVvdDsgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbdGNw bV0gRXhjZWVkaW5nIHZhbHVlIGluIE1TUyBvcHRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAxOS8xMC8yMDIwIDIwOjIyLCBN YXJ0aW4gRHVrZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGVsbG8gdGNwbSwgPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5TZWN0aW9uIDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjMTEyMiNwYWdlLTg1Ij4N CjQuMi4yLjYgb2YgUkZDIDExMjI8L2E+IGlzIHByZXR0eSBjbGVhciB0aGF0IHRoZSBUQ1Agc2Vu ZGVyIE1VU1QgY29uc2lkZXIgYWxsIElQIGFuZCBUQ1Agb3B0aW9ucyB3aGVuIHNpemluZyBwYXls b2FkcyZuYnNwO3dpdGggcmVzcGVjdCB0byB0aGUgYWR2ZXJ0aXNlZCBNU1Mgb3B0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JJ20gcmV2aWV3 aW5nIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1sd2lnLXRjcC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTExI3NlY3Rpb24tNC4xLjEi Pg0KYSBkb2N1bWVudDwvYT4gdGhhdCBhZHZpc2VzIHRoYXQgc29tZSBlbmRwb2ludHMgbWF5IHdh bnQgdG8gcmVkdWNlIHRoZWlyIGFkdmVydGlzZWQgTVNTIG9uIElQdjYgY29ubmVjdGlvbnMgaW4g Y2FzZSB0aGUgcGVlciBpc24ndCByZXNwZWN0aW5nIHRoYXQgZ3VpZGFuY2UuIElzIG5vbmNvbXBs aWFuY2Ugd2l0aCB0aGlzIHByb3Zpc2lvbiBhIHByb2JsZW0gaW4gdGhlIGludGVybmV0PyBBcmUg dGhlcmUgbWlkZGxlYm94ZXMgaW5qZWN0aW5nIG9wdGlvbnMNCiB0aGF0IGNhdXNlIFBNVFUgZHJv cHMgb3IgZnJhZ21lbnRhdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SSBoYXZlIG5vdCBoZWFyZCBvZiBzdWNoIHByb2JsZW1zLCBidXQgdGhv dWdodCBJJ2QgY2hlY2sgd2l0aCB0aGUgY29tbXVuaXR5IHRvIHNlZSBpZiB0aGlzIHByZWNhdXRp b24gbWFrZXMgYW55IHNlbnNlIGF0IGFsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TWFydGlu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50Y3BtIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhy ZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBNYXJ0aW4sIDxicj4NCjxicj4NCldoaWxl IGEgc2VydmVyIGFkdmVydGlzaW5nIGEgcmVzdHJpY3RlZCBNU1MgY2xlYXJseSByZWR1Y2VzIHRo ZSBUQ1AgcGFja2V0IHNpemUsIGl0IHNlZW1zIHRvIG1lIHRvIGJlIGEgcmF0aGVyIHBvb3Igc29s dXRpb24gdG8gdGhlIHByb2JsZW0gaW4gZ2VuZXJhbCwgYW5kIG9ubHkgd29ya3MgZm9yIFRDUC4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYmbmJzcDsg aXQgd2FudHMgdG8gc2F5IHNvbWUgYWR2aWNlcywgSSB0aGluayB0aGUgSUVURiBuZWVkcyB0byBj b25zaWRlciBjdXJyZW50IHByYWN0aWNlIGFuZCB0aGUgaW1wbGljYXRpb25zIG9mIHRoaXMuIEkg c3VzcGVjdCB0aGUgcHJhY3RpY2Ugb2YgY2xhbXBpbmcgdGhlIElQdjYgTVNTIGF0IHRoZSBzZXJ2 ZXIgaXMgYWxyZWFkeSBxdWl0ZSBjb21tb24sIGVzcGVjaWFsbHkgaW4gSVB2NiBzZXJ2ZXJzDQog b2ZmZXJpbmcgd2ViIGNvbnRlbnQuIE1TUyBDbGFtcGluZyBvbi1wYXRoIGlzIGFsc28gY29tbW9u LCBidXQgYW55d2F5IEkgc2VlIHNvbWUgc2VydmVycyBhZHZlcnRpc2UgYW4gTVNTIG11Y2ggbG93 ZXIgdGhhbiBwZXJtaXR0ZWQgYnkgdGhlIE1UVS4gRm9yIGV4YW1wbGUsIHNlZSB0aGUgc2VjdGlv biBvbiBNU1MgaGFuZGxpbmcgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJs P2s9Yzk2NGE5MWYtOTdjNDEzNzEtYzk2NGU5ODQtODY2MDM4OTczYTE1LTRjNTM4MDA3MzIyZDgz OTImYW1wO3E9MSZhbXA7ZT04YjcyY2JjMi02ODNhLTQ5M2ItYTA3NS1jOWRmMDY3Yjg4ZjcmYW1w O3U9aHR0cHMlM0ElMkYlMkZ0bWEuaWZpcC5vcmclMkYyMDE4JTJGd3AtY29udGVudCUyRnVwbG9h ZHMlMkZzaXRlcyUyRjMlMkYyMDE4JTJGMDYlMkZ0bWEyMDE4X3BhcGVyNTcucGRmIj5odHRwczov L3RtYS5pZmlwLm9yZy8yMDE4L3dwLWNvbnRlbnQvdXBsb2Fkcy9zaXRlcy8zLzIwMTgvMDYvdG1h MjAxOF9wYXBlcjU3LnBkZjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPlRoaXMgbWlnaHQgYmUgYmVjYXVzZSBvZiB0aGUgcmVhc29ucyBmb3IgdGhpcyBh cmUgY2l0ZWQgaW4gUkZDODkwMC4NCjxicj4NCjxicj4NCkdvcnJ5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB0640E4C7A94E1C9F29BD373A220BABericssoncom_-- From nobody Tue Oct 20 08:03:12 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606F3A0FD8 for ; Tue, 20 Oct 2020 08:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtXueloDD98q for ; Tue, 20 Oct 2020 08:03:06 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id CFEE53A0FC9 for ; Tue, 20 Oct 2020 08:02:50 -0700 (PDT) Received: from [192.168.1.74] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A9C5D1B0020A; Tue, 20 Oct 2020 16:02:40 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-157AAB31-82A4-41CF-BE7F-F943DEB4D36C Content-Transfer-Encoding: 7bit From: Gorry Fairhurst Mime-Version: 1.0 (1.0) Date: Tue, 20 Oct 2020 16:02:39 +0100 Message-Id: <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk> References: Cc: Martin Duke , "tcpm@ietf.org Extensions" In-Reply-To: To: Mirja Kuehlewind X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 15:03:10 -0000 --Apple-Mail-157AAB31-82A4-41CF-BE7F-F943DEB4D36C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable See below... > On 20 Oct 2020, at 13:56, Mirja Kuehlewind = wrote: >=20 > =EF=BB=BF > Hi Martin, hi Gorry, > =20 > I think Gorry=E2=80=99s paper does indicate that at least for MSS, there a= re middleboxes that add this option. However, I don=E2=80=99t think there is= evidence that there is a general problem about middlebox adding option (rat= her than removing them). I also reviewed the draft in tsv-art review and giv= en that they say it=E2=80=99s actually not recommended and should only be do= ne with care, I thought that text is okay. However, I guess there is room to= improve the wording and explain a bit better, when and if this might be con= sider or not. > =20 > Mirja > =20 Right. This approach is not great for evolution of the size in future, but t= his use of MSS to restrict packet size has not broken the Internet - far fro= m it, it is probably the way connections currently avoid black holes. I susp= ect that any operator adding overhead will be aware of what they are doing, a= nd that If they do MSS clamping they will adjust that if needed, or just con= figure a bigger MTU within their network segment. Gorry > =20 > From: tcpm on behalf of Gorry Fairhurst > Date: Tuesday, 20. October 2020 at 11:13 > To: Martin Duke , "tcpm@ietf.org Extensions" > Subject: Re: [tcpm] Exceeding value in MSS option? > =20 > On 19/10/2020 20:22, Martin Duke wrote: > Hello tcpm, > =20 > Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST consi= der all IP and TCP options when sizing payloads with respect to the advertis= ed MSS option. > =20 > I'm reviewing a document that advises that some endpoints may want to redu= ce their advertised MSS on IPv6 connections in case the peer isn't respectin= g that guidance. Is noncompliance with this provision a problem in the inter= net? Are there middleboxes injecting options that cause PMTU drops or fragme= ntation? > =20 > I have not heard of such problems, but thought I'd check with the communit= y to see if this precaution makes any sense at all. > =20 > Thanks, > Martin > =20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > Hi Martin,=20 >=20 > While a server advertising a restricted MSS clearly reduces the TCP packet= size, it seems to me to be a rather poor solution to the problem in general= , and only works for TCP. >=20 > If it wants to say some advices, I think the IETF needs to consider curre= nt practice and the implications of this. I suspect the practice of clamping= the IPv6 MSS at the server is already quite common, especially in IPv6 serv= ers offering web content. MSS Clamping on-path is also common, but anyway I s= ee some servers advertise an MSS much lower than permitted by the MTU. For e= xample, see the section on MSS handling here: >=20 > https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper= 57.pdf >=20 > This might be because of the reasons for this are cited in RFC8900.=20 >=20 > Gorry --Apple-Mail-157AAB31-82A4-41CF-BE7F-F943DEB4D36C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
See below...

On 20 Oct 2020, at 13:56, Mirja Kuehl= ewind <mirja.kuehlewind@ericsson.com> wrote:

=EF=BB=BF

Hi Martin, hi Gorry,

 

I think Gorry=E2=80=99s paper does indicate that at least for MSS, ther= e are middleboxes that add this option. However, I don=E2=80=99t think there= is evidence that there is a general problem about middlebox adding option (rather than removing them). I also reviewed the draft in tsv= -art review and given that they say it=E2=80=99s actually not recommended an= d should only be done with care, I thought that text is okay. However, I gue= ss there is room to improve the wording and explain a bit better, when and if this might be consider or not.

 

Mirja

 

Right. This approa= ch is not great for evolution of the size in future, but this use of MSS to r= estrict packet size has not broken the Internet - far from it, it is probabl= y the way connections currently avoid black holes. I suspect that any operat= or adding overhead will be aware of what they are doing, and that If they do= MSS clamping they will adjust that if needed, or just configure a bigger MT= U within their network segment.

Gorry

 = ;

From: tcpm <tcpm-bounce= s@ietf.org> on behalf of Gorry Fairhurst <gorry@erg.abdn.ac.uk>
= Date: Tuesday, 20. October 2020 at 11:13
To: Martin Duke <martin.h.duke@gmail.com>, "tcpm@ietf.org Exten= sions" <tcpm@ietf.org>
Subject: Re: [tcpm] Exceeding value in MSS option?<= /p>

 

On 19/10/2020 20:22, Mar= tin Duke wrote:

Hello tcpm, <= /p>

 

Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST consider al= l IP and TCP options when sizing payloads with respect to the advertise= d MSS option.

 

I'm reviewing a document that advises that some endpoints may want to reduce their adv= ertised MSS on IPv6 connections in case the peer isn't respecting that guida= nce. Is noncompliance with this provision a problem in the internet? Are the= re middleboxes injecting options that cause PMTU drops or fragmentation?

 

I have not heard of such= problems, but thought I'd check with the community to see if this precautio= n makes any sense at all.

 

Thanks,

Martin

 



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

Hi Martin,

While a server advertising a restricted MSS clearly reduces the TCP packet s= ize, it seems to me to be a rather poor solution to the problem in general, a= nd only works for TCP.

If  it wants to say some advices, I thi= nk the IETF needs to consider current practice and the implications of this.= I suspect the practice of clamping the IPv6 MSS at the server is already qu= ite common, especially in IPv6 servers offering web content. MSS Clamping on-path is also common, but anyway I see= some servers advertise an MSS much lower than permitted by the MTU. For exa= mple, see the section on MSS handling here:

https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_pape= r57.pdf

This might be because of the reasons for thi= s are cited in RFC8900.

Gorry

= --Apple-Mail-157AAB31-82A4-41CF-BE7F-F943DEB4D36C-- From nobody Tue Oct 20 12:56:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8A83A1351 for ; Tue, 20 Oct 2020 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Cv3DD9B-fwQR for ; Tue, 20 Oct 2020 12:56: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 3D7753A105D for ; Tue, 20 Oct 2020 12:56:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1476025A1A; Tue, 20 Oct 2020 21:56:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603223791; bh=pyyl7z36rnNCycCkVPF0kf996al2nVMHukYEIDwRlDQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=S5bcwL+XTR0zAycOBPUN7FJAubTz+lM9MkNRrQfebR/H7QgxE+/isycciWo4sRISD V89w/A8+eie2XJx2w5rNHkvcTsvqmPuJbuYOnBehk9AM/Ag2iCSZXssylJaP7A5uiR 2V1IbntGFbdh3RVAqgIMRFbpjI8nBVpBd9hf3/Q0= 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 hMc4cu8U6dlX; Tue, 20 Oct 2020 21:56:30 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 20 Oct 2020 21:56:30 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 20 Oct 2020 21:56:29 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Tue, 20 Oct 2020 21:56:29 +0200 From: "Scharf, Michael" To: Michael Tuexen , Martin Duke CC: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Exceeding value in MSS option? Thread-Index: AQHWpk1K5yCW3VOIm02cl+MOJ34oLamfNjuAgAGnxdA= Date: Tue, 20 Oct 2020 19:56:29 +0000 Message-ID: <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> In-Reply-To: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 19:56:35 -0000 Hi all, Sorry for the delayed reply. More inline... > > On 19. Oct 2020, at 21:22, Martin Duke wrote: > > > > Hello tcpm, > > > > Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST > consider all IP and TCP options when sizing payloads with respect to the > advertised MSS option. > > > > I'm reviewing a document that advises that some endpoints may want to > reduce their advertised MSS on IPv6 connections in case the peer isn't > respecting that guidance. Is noncompliance with this provision a problem = in > the internet? Are there middleboxes injecting options that cause PMTU > drops or fragmentation? > Hi Martin, >=20 > the document you are reviewing says: >=20 > An IPv6 datagram size exceeding 1280 bytes can be avoided by setting > the TCP MSS not larger than 1220 bytes. This assumes that the remote > sender will use no TCP options, aside from possibly the MSS option, > which is only used in the initial TCP SYN packet. >=20 > The first sentence is correct. The second is not. I would suggest to simp= ly > remove it. The statements regarding the MSS were discussed and also rewritten many tim= es. And, sorry, apparently I have not carefully read the second sentence (b= ut, well, that sentence was also in the version of the draft that was last = called in TCPM...) Given this discussion now, I agree that the second sentence could probably = be removed. =20 > Then the text says: >=20 > In order to accommodate unrequested TCP options that may be used by > some TCP implementations, a constrained device may advertise an MSS > smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that > it is advised for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. Therefore, the suggestion of > advertising an MSS smaller than 1220 bytes is likely to be > overcautious and its suitability should be considered carefully. >=20 > I read this as "use a smaller MSS", but this is "likely to be > overcautious and its suitability should be considered carefully." >=20 > I think the careful consideration is to remove this paragraph. I am not sure if we should simply remove the whole paragraph, including e.g= . the reference to RFC 6691. Readers of this document may not be aware of R= FC 6691, so a pointer may be useful, no? Also, during the IETF last call th= ere was a discussion on MSS values significantly smaller than 1220 byte. Pe= ople apparently *do* think about smaller MSS values on constrained devices = and this document is a place to provide guidance to that community (as far = as possible). This specific wording came up in earlier reviews of the draft= , too. Thus, the final proposal "likely to be overcautious and its suitabil= ity should be considered carefully" is a result of several past discussions= . IMHO we should carefully consider changes to this statement... BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6) in= deed causes real-world problems on constrained devices, i.e., if in year 20= 20 there is any real-world benefit of an MSS smaller than 1220 byte. But, u= nfortunately, I don't have measurement data that would back a different sta= tement in the draft. Michael > Best regards > Michael >=20 >=20 >=20 >=20 > > > > I have not heard of such problems, but thought I'd check with the > community to see if this precaution makes any sense at all. > > > > Thanks, > > Martin > > > > > > _______________________________________________ > > 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 Tue Oct 20 12:58:12 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56793A1069 for ; Tue, 20 Oct 2020 12:58:11 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 y1_PdViLtupA for ; Tue, 20 Oct 2020 12:58:09 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04793A07B0 for ; Tue, 20 Oct 2020 12:58:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 08C0F25A1A; Tue, 20 Oct 2020 21:58:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603223887; bh=Q84c3xeu8rB4tyYdGyHGahuJ9Yo6k9aNXb+a30VABxs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=VR+V5u7d+lwANkgkJ3KVLrAceSsG0ak9P6XuLHEnkYELm9AflLzXWZUrvQgHN0QCw G/Qq/90FZhKpZT9YsoYufkSMEs3W5M9kyvhNm9ZlGHmyTBeJwXGiwJ4Y7+i71rWSz2 zStiKAy4rjIgFcejvbZuXoI9MQFiEy8GjfpZzTIQ= 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 TtcnAzQxZe-V; Tue, 20 Oct 2020 21:58:05 +0200 (CEST) Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 20 Oct 2020 21:58:05 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 20 Oct 2020 21:58:05 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Tue, 20 Oct 2020 21:58:05 +0200 From: "Scharf, Michael" To: Gorry Fairhurst , Mirja Kuehlewind CC: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Exceeding value in MSS option? Thread-Index: AQHWpk1K5yCW3VOIm02cl+MOJ34oLamgE6eAgAA/EwCAACM/gIAAZHQw Date: Tue, 20 Oct 2020 19:58:05 +0000 Message-ID: <9d7e505786df4e9d903734a6a2ee588d@hs-esslingen.de> References: <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk> In-Reply-To: <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: multipart/alternative; boundary="_000_9d7e505786df4e9d903734a6a2ee588dhsesslingende_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 19:58:12 -0000 --_000_9d7e505786df4e9d903734a6a2ee588dhsesslingende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3V0IG9mIG15IGhlYWQsIG1vc3QgY3VycmVudCByb3V0ZXIgb3BlcmF0aW5nIHN5c3RlbXMgc3Vw cG9ydCBNU1MgY2xhbXBpbmcsIGFuZCBhbGJlaXQgSSBoYXZlIG5vIG1lYXN1cmVtZW50IGRhdGEs IEnigJlkIGJlIHN1cnByaXNlZCBpZiB0aGF0IHJvdXRlciBmZWF0dXJlIGlzIG5vdCB3aWRlbHkg dXNlZC4NCg0KSWYgdGhlIG5ldHdvcmsgY2xhbXBzIHRoZSBNU1MsIGl0IG1heSBub3QgcmVhbGx5 IG1hdHRlciBpZiBhIGNvbm5lY3Rpb24gZW5kcG9pbnQgcGlja3MgYW4gTVNTIGxhcmdlciB0aGFu IHRoZSB2YWx1ZSBlbmZvcmNlZCBieSB0aGUgbmV0d29yay4gQnV0IEkgYW0gbm90IHN1cmUgaWYg ZHJhZnQtaWV0Zi1sd2lnLXRjcC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTExIHNob3VsZCBk aXNjdXNzIE1TUyBjbGFtcGluZyBhcyB0ZWNobmlxdWUuIEl0IGlzIG5vdCBhdCBhbGwgc3BlY2lm aWMgdG8gY29uc3RyYWluZWQgZGV2aWNlcy4NCg0KTWljaGFlbA0KDQoNCkZyb206IHRjcG0gPHRj cG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEdvcnJ5IEZhaXJodXJzdA0KU2VudDog VHVlc2RheSwgT2N0b2JlciAyMCwgMjAyMCA1OjAzIFBNDQpUbzogTWlyamEgS3VlaGxld2luZCA8 bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+DQpDYzogdGNwbUBpZXRmLm9yZyBFeHRlbnNp b25zIDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0Y3BtXSBFeGNlZWRpbmcgdmFsdWUg aW4gTVNTIG9wdGlvbj8NCg0KU2VlIGJlbG93Li4uDQoNCg0KT24gMjAgT2N0IDIwMjAsIGF0IDEz OjU2LCBNaXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTxtYWls dG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCu+7vw0KSGkgTWFydGlu LCBoaSBHb3JyeSwNCg0KSSB0aGluayBHb3JyeeKAmXMgcGFwZXIgZG9lcyBpbmRpY2F0ZSB0aGF0 IGF0IGxlYXN0IGZvciBNU1MsIHRoZXJlIGFyZSBtaWRkbGVib3hlcyB0aGF0IGFkZCB0aGlzIG9w dGlvbi4gSG93ZXZlciwgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGV2aWRlbmNlIHRoYXQgdGhl cmUgaXMgYSBnZW5lcmFsIHByb2JsZW0gYWJvdXQgbWlkZGxlYm94IGFkZGluZyBvcHRpb24gKHJh dGhlciB0aGFuIHJlbW92aW5nIHRoZW0pLiBJIGFsc28gcmV2aWV3ZWQgdGhlIGRyYWZ0IGluIHRz di1hcnQgcmV2aWV3IGFuZCBnaXZlbiB0aGF0IHRoZXkgc2F5IGl04oCZcyBhY3R1YWxseSBub3Qg cmVjb21tZW5kZWQgYW5kIHNob3VsZCBvbmx5IGJlIGRvbmUgd2l0aCBjYXJlLCBJIHRob3VnaHQg dGhhdCB0ZXh0IGlzIG9rYXkuIEhvd2V2ZXIsIEkgZ3Vlc3MgdGhlcmUgaXMgcm9vbSB0byBpbXBy b3ZlIHRoZSB3b3JkaW5nIGFuZCBleHBsYWluIGEgYml0IGJldHRlciwgd2hlbiBhbmQgaWYgdGhp cyBtaWdodCBiZSBjb25zaWRlciBvciBub3QuDQoNCk1pcmphDQoNClJpZ2h0LiBUaGlzIGFwcHJv YWNoIGlzIG5vdCBncmVhdCBmb3IgZXZvbHV0aW9uIG9mIHRoZSBzaXplIGluIGZ1dHVyZSwgYnV0 IHRoaXMgdXNlIG9mIE1TUyB0byByZXN0cmljdCBwYWNrZXQgc2l6ZSBoYXMgbm90IGJyb2tlbiB0 aGUgSW50ZXJuZXQgLSBmYXIgZnJvbSBpdCwgaXQgaXMgcHJvYmFibHkgdGhlIHdheSBjb25uZWN0 aW9ucyBjdXJyZW50bHkgYXZvaWQgYmxhY2sgaG9sZXMuIEkgc3VzcGVjdCB0aGF0IGFueSBvcGVy YXRvciBhZGRpbmcgb3ZlcmhlYWQgd2lsbCBiZSBhd2FyZSBvZiB3aGF0IHRoZXkgYXJlIGRvaW5n LCBhbmQgdGhhdCBJZiB0aGV5IGRvIE1TUyBjbGFtcGluZyB0aGV5IHdpbGwgYWRqdXN0IHRoYXQg aWYgbmVlZGVkLCBvciBqdXN0IGNvbmZpZ3VyZSBhIGJpZ2dlciBNVFUgd2l0aGluIHRoZWlyIG5l dHdvcmsgc2VnbWVudC4NCg0KR29ycnkNCg0KDQoNCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEdvcnJ5 IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFj LnVrPj4NCkRhdGU6IFR1ZXNkYXksIDIwLiBPY3RvYmVyIDIwMjAgYXQgMTE6MTMNClRvOiBNYXJ0 aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21h aWwuY29tPj4sICJ0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnM8bWFpbHRvOnRjcG1AaWV0Zi5vcmcl MjBFeHRlbnNpb25zPiIgPHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFt0Y3BtXSBFeGNlZWRpbmcgdmFsdWUgaW4gTVNTIG9wdGlvbj8NCg0KT24gMTkv MTAvMjAyMCAyMDoyMiwgTWFydGluIER1a2Ugd3JvdGU6DQpIZWxsbyB0Y3BtLA0KDQpTZWN0aW9u IDQuMi4yLjYgb2YgUkZDIDExMjI8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9yZmMxMTIyI3BhZ2UtODU+IGlzIHByZXR0eSBjbGVhciB0aGF0IHRoZSBUQ1Agc2VuZGVyIE1V U1QgY29uc2lkZXIgYWxsIElQIGFuZCBUQ1Agb3B0aW9ucyB3aGVuIHNpemluZyBwYXlsb2FkcyB3 aXRoIHJlc3BlY3QgdG8gdGhlIGFkdmVydGlzZWQgTVNTIG9wdGlvbi4NCg0KSSdtIHJldmlld2lu ZyBhIGRvY3VtZW50PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1sd2lnLXRjcC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTExI3NlY3Rpb24tNC4xLjE+ IHRoYXQgYWR2aXNlcyB0aGF0IHNvbWUgZW5kcG9pbnRzIG1heSB3YW50IHRvIHJlZHVjZSB0aGVp ciBhZHZlcnRpc2VkIE1TUyBvbiBJUHY2IGNvbm5lY3Rpb25zIGluIGNhc2UgdGhlIHBlZXIgaXNu J3QgcmVzcGVjdGluZyB0aGF0IGd1aWRhbmNlLiBJcyBub25jb21wbGlhbmNlIHdpdGggdGhpcyBw cm92aXNpb24gYSBwcm9ibGVtIGluIHRoZSBpbnRlcm5ldD8gQXJlIHRoZXJlIG1pZGRsZWJveGVz IGluamVjdGluZyBvcHRpb25zIHRoYXQgY2F1c2UgUE1UVSBkcm9wcyBvciBmcmFnbWVudGF0aW9u Pw0KDQpJIGhhdmUgbm90IGhlYXJkIG9mIHN1Y2ggcHJvYmxlbXMsIGJ1dCB0aG91Z2h0IEknZCBj aGVjayB3aXRoIHRoZSBjb21tdW5pdHkgdG8gc2VlIGlmIHRoaXMgcHJlY2F1dGlvbiBtYWtlcyBh bnkgc2Vuc2UgYXQgYWxsLg0KDQpUaGFua3MsDQpNYXJ0aW4NCg0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQp0Y3BtIG1haWxpbmcgbGlz dA0KDQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0KSGkgTWFydGluLA0KDQpXaGlsZSBhIHNl cnZlciBhZHZlcnRpc2luZyBhIHJlc3RyaWN0ZWQgTVNTIGNsZWFybHkgcmVkdWNlcyB0aGUgVENQ IHBhY2tldCBzaXplLCBpdCBzZWVtcyB0byBtZSB0byBiZSBhIHJhdGhlciBwb29yIHNvbHV0aW9u IHRvIHRoZSBwcm9ibGVtIGluIGdlbmVyYWwsIGFuZCBvbmx5IHdvcmtzIGZvciBUQ1AuDQoNCklm ICBpdCB3YW50cyB0byBzYXkgc29tZSBhZHZpY2VzLCBJIHRoaW5rIHRoZSBJRVRGIG5lZWRzIHRv IGNvbnNpZGVyIGN1cnJlbnQgcHJhY3RpY2UgYW5kIHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhpcy4g SSBzdXNwZWN0IHRoZSBwcmFjdGljZSBvZiBjbGFtcGluZyB0aGUgSVB2NiBNU1MgYXQgdGhlIHNl cnZlciBpcyBhbHJlYWR5IHF1aXRlIGNvbW1vbiwgZXNwZWNpYWxseSBpbiBJUHY2IHNlcnZlcnMg b2ZmZXJpbmcgd2ViIGNvbnRlbnQuIE1TUyBDbGFtcGluZyBvbi1wYXRoIGlzIGFsc28gY29tbW9u LCBidXQgYW55d2F5IEkgc2VlIHNvbWUgc2VydmVycyBhZHZlcnRpc2UgYW4gTVNTIG11Y2ggbG93 ZXIgdGhhbiBwZXJtaXR0ZWQgYnkgdGhlIE1UVS4gRm9yIGV4YW1wbGUsIHNlZSB0aGUgc2VjdGlv biBvbiBNU1MgaGFuZGxpbmcgaGVyZToNCg0KaHR0cHM6Ly90bWEuaWZpcC5vcmcvMjAxOC93cC1j b250ZW50L3VwbG9hZHMvc2l0ZXMvMy8yMDE4LzA2L3RtYTIwMThfcGFwZXI1Ny5wZGY8aHR0cHM6 Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1jOTY0YTkxZi05N2M0MTM3MS1jOTY0ZTk4 NC04NjYwMzg5NzNhMTUtNGM1MzgwMDczMjJkODM5MiZxPTEmZT04YjcyY2JjMi02ODNhLTQ5M2It YTA3NS1jOWRmMDY3Yjg4ZjcmdT1odHRwcyUzQSUyRiUyRnRtYS5pZmlwLm9yZyUyRjIwMTglMkZ3 cC1jb250ZW50JTJGdXBsb2FkcyUyRnNpdGVzJTJGMyUyRjIwMTglMkYwNiUyRnRtYTIwMThfcGFw ZXI1Ny5wZGY+DQoNClRoaXMgbWlnaHQgYmUgYmVjYXVzZSBvZiB0aGUgcmVhc29ucyBmb3IgdGhp cyBhcmUgY2l0ZWQgaW4gUkZDODkwMC4NCg0KR29ycnkNCg== --_000_9d7e505786df4e9d903734a6a2ee588dhsesslingende_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1h dGllcnQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFZv cmZvcm1hdGllcnRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNo biI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZv cm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9y bGFnZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5PdXQg b2YgbXkgaGVhZCwgbW9zdCBjdXJyZW50IHJvdXRlciBvcGVyYXRpbmcgc3lzdGVtcyBzdXBwb3J0 IE1TUyBjbGFtcGluZywgYW5kIGFsYmVpdCBJIGhhdmUgbm8gbWVhc3VyZW1lbnQgZGF0YSwgSeKA mWQgYmUgc3VycHJpc2VkIGlmIHRoYXQgcm91dGVyIGZlYXR1cmUgaXMgbm90IHdpZGVseSB1c2Vk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHRoZSBuZXR3b3JrIGNsYW1wcyB0 aGUgTVNTLCBpdCBtYXkgbm90IHJlYWxseSBtYXR0ZXIgaWYgYSBjb25uZWN0aW9uIGVuZHBvaW50 IHBpY2tzIGFuIE1TUyBsYXJnZXIgdGhhbiB0aGUgdmFsdWUgZW5mb3JjZWQgYnkgdGhlIG5ldHdv cmsuIEJ1dCBJIGFtIG5vdCBzdXJlIGlmIGRyYWZ0LWlldGYtbHdpZy10Y3AtY29uc3RyYWluZWQt bm9kZS1uZXR3b3Jrcy0xMQ0KIHNob3VsZCBkaXNjdXNzIE1TUyBjbGFtcGluZyBhcyB0ZWNobmlx dWUuIEl0IGlzIG5vdCBhdCBhbGwgc3BlY2lmaWMgdG8gY29uc3RyYWluZWQgZGV2aWNlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gdGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxm IE9mIDwvYj5Hb3JyeSBGYWlyaHVyc3Q8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2Jl ciAyMCwgMjAyMCA1OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBNaXJqYSBLdWVobGV3aW5kICZsdDtt aXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0 Zi5vcmcgRXh0ZW5zaW9ucyAmbHQ7dGNwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFt0Y3BtXSBFeGNlZWRpbmcgdmFsdWUgaW4gTVNTIG9wdGlvbj88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VlIGJlbG93Li4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ T24gMjAgT2N0IDIwMjAsIGF0IDEzOjU2LCBNaXJqYSBLdWVobGV3aW5kICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tIj48c3BhbiBsYW5nPSJF Ti1VUyI+bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+77u/IDxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBNYXJ0aW4s IGhpIEdvcnJ5LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIEdvcnJ54oCZcyBw YXBlciBkb2VzIGluZGljYXRlIHRoYXQgYXQgbGVhc3QgZm9yIE1TUywgdGhlcmUgYXJlIG1pZGRs ZWJveGVzIHRoYXQgYWRkIHRoaXMgb3B0aW9uLiBIb3dldmVyLCBJIGRvbuKAmXQgdGhpbmsgdGhl cmUgaXMgZXZpZGVuY2UgdGhhdCB0aGVyZSBpcyBhIGdlbmVyYWwgcHJvYmxlbSBhYm91dA0KIG1p ZGRsZWJveCBhZGRpbmcgb3B0aW9uIChyYXRoZXIgdGhhbiByZW1vdmluZyB0aGVtKS4gSSBhbHNv IHJldmlld2VkIHRoZSBkcmFmdCBpbiB0c3YtYXJ0IHJldmlldyBhbmQgZ2l2ZW4gdGhhdCB0aGV5 IHNheSBpdOKAmXMgYWN0dWFsbHkgbm90IHJlY29tbWVuZGVkIGFuZCBzaG91bGQgb25seSBiZSBk b25lIHdpdGggY2FyZSwgSSB0aG91Z2h0IHRoYXQgdGV4dCBpcyBva2F5LiBIb3dldmVyLCBJIGd1 ZXNzIHRoZXJlIGlzIHJvb20gdG8gaW1wcm92ZQ0KIHRoZSB3b3JkaW5nIGFuZCBleHBsYWluIGEg Yml0IGJldHRlciwgd2hlbiBhbmQgaWYgdGhpcyBtaWdodCBiZSBjb25zaWRlciBvciBub3QuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ TWlyamE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmlnaHQuIFRoaXMgYXBwcm9hY2ggaXMgbm90IGdyZWF0IGZv ciBldm9sdXRpb24gb2YgdGhlIHNpemUgaW4gZnV0dXJlLCBidXQgdGhpcyB1c2Ugb2YgTVNTIHRv IHJlc3RyaWN0IHBhY2tldCBzaXplIGhhcyBub3QgYnJva2VuIHRoZSBJbnRlcm5ldCAtIGZhciBm cm9tIGl0LCBpdCBpcyBwcm9iYWJseSB0aGUgd2F5IGNvbm5lY3Rpb25zIGN1cnJlbnRseSBhdm9p ZCBibGFjayBob2xlcy4NCiBJIHN1c3BlY3QgdGhhdCBhbnkgb3BlcmF0b3IgYWRkaW5nIG92ZXJo ZWFkIHdpbGwgYmUgYXdhcmUgb2Ygd2hhdCB0aGV5IGFyZSBkb2luZywgYW5kIHRoYXQgSWYgdGhl eSBkbyBNU1MgY2xhbXBpbmcgdGhleSB3aWxsIGFkanVzdCB0aGF0IGlmIG5lZWRlZCwgb3IganVz dCBjb25maWd1cmUgYSBiaWdnZXIgTVRVIHdpdGhpbiB0aGVpciBuZXR3b3JrIHNlZ21lbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R29ycnk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+dGNwbSAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+dGNwbS1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPiZndDsgb24gYmVoYWxmDQogb2YgR29ycnkgRmFpcmh1cnN0ICZsdDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgMjAuIE9jdG9iZXIgMjAyMCBhdCAxMToxMzxi cj4NCjxiPlRvOiA8L2I+TWFydGluIER1a2UgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFy dGluLmguZHVrZUBnbWFpbC5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0OywgJnF1b3Q7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnJTIwRXh0ZW5zaW9ucyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50Y3BtQGlldGYub3JnDQogRXh0ZW5z aW9uczwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mcXVvdDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRm Lm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50Y3BtQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFt0Y3BtXSBFeGNl ZWRpbmcgdmFsdWUgaW4gTVNTIG9wdGlvbj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gMTkvMTAvMjAyMCAy MDoyMiwgTWFydGluIER1a2Ugd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gdGNwbSwgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5TZWN0aW9uIDwvc3Bhbj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjMTEyMiNwYWdlLTg1Ij48c3BhbiBsYW5nPSJFTi1VUyI+ NC4yLjIuNiBvZiBSRkMgMTEyMjwvc3Bhbj48L2E+DQo8c3BhbiBsYW5nPSJFTi1VUyI+aXMgcHJl dHR5IGNsZWFyIHRoYXQgdGhlIFRDUCBzZW5kZXIgTVVTVCBjb25zaWRlciBhbGwgSVAgYW5kIFRD UCBvcHRpb25zIHdoZW4gc2l6aW5nIHBheWxvYWRzJm5ic3A7d2l0aCByZXNwZWN0IHRvIHRoZSBh ZHZlcnRpc2VkIE1TUyBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5JJ20gcmV2aWV3aW5nIDwvc3Bhbj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1sd2lnLXRjcC1jb25zdHJhaW5lZC1u b2RlLW5ldHdvcmtzLTExI3NlY3Rpb24tNC4xLjEiPjxzcGFuIGxhbmc9IkVOLVVTIj5hIGRvY3Vt ZW50PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+IHRoYXQgYWR2aXNlcyB0aGF0IHNvbWUg ZW5kcG9pbnRzIG1heSB3YW50IHRvIHJlZHVjZSB0aGVpciBhZHZlcnRpc2VkIE1TUyBvbiBJUHY2 IGNvbm5lY3Rpb25zDQogaW4gY2FzZSB0aGUgcGVlciBpc24ndCByZXNwZWN0aW5nIHRoYXQgZ3Vp ZGFuY2UuIElzIG5vbmNvbXBsaWFuY2Ugd2l0aCB0aGlzIHByb3Zpc2lvbiBhIHByb2JsZW0gaW4g dGhlIGludGVybmV0PyBBcmUgdGhlcmUgbWlkZGxlYm94ZXMgaW5qZWN0aW5nIG9wdGlvbnMgdGhh dCBjYXVzZSBQTVRVIGRyb3BzIG9yIGZyYWdtZW50YXRpb24/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgbm90IGhlYXJkIG9mIHN1Y2ggcHJvYmxl bXMsIGJ1dCB0aG91Z2h0IEknZCBjaGVjayB3aXRoIHRoZSBjb21tdW5pdHkgdG8gc2VlIGlmIHRo aXMgcHJlY2F1dGlvbiBtYWtlcyBhbnkgc2Vuc2UgYXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5NYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+dGNwbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5v cmciPjxzcGFuIGxhbmc9IkVOLVVTIj50Y3BtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGNwbSI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPkhpIE1hcnRpbiwgPGJyPg0KPGJyPg0KV2hpbGUgYSBzZXJ2ZXIgYWR2 ZXJ0aXNpbmcgYSByZXN0cmljdGVkIE1TUyBjbGVhcmx5IHJlZHVjZXMgdGhlIFRDUCBwYWNrZXQg c2l6ZSwgaXQgc2VlbXMgdG8gbWUgdG8gYmUgYSByYXRoZXIgcG9vciBzb2x1dGlvbiB0byB0aGUg cHJvYmxlbSBpbiBnZW5lcmFsLCBhbmQgb25seSB3b3JrcyBmb3IgVENQLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPklmJm5ic3A7IGl0IHdhbnRzIHRvIHNheSBzb21lIGFkdmljZXMsIEkgdGhpbmsgdGhlIElF VEYgbmVlZHMgdG8gY29uc2lkZXIgY3VycmVudCBwcmFjdGljZSBhbmQgdGhlIGltcGxpY2F0aW9u cyBvZiB0aGlzLiBJIHN1c3BlY3QgdGhlIHByYWN0aWNlIG9mIGNsYW1waW5nIHRoZSBJUHY2IE1T UyBhdCB0aGUgc2VydmVyIGlzIGFscmVhZHkgcXVpdGUgY29tbW9uLCBlc3BlY2lhbGx5DQogaW4g SVB2NiBzZXJ2ZXJzIG9mZmVyaW5nIHdlYiBjb250ZW50LiBNU1MgQ2xhbXBpbmcgb24tcGF0aCBp cyBhbHNvIGNvbW1vbiwgYnV0IGFueXdheSBJIHNlZSBzb21lIHNlcnZlcnMgYWR2ZXJ0aXNlIGFu IE1TUyBtdWNoIGxvd2VyIHRoYW4gcGVybWl0dGVkIGJ5IHRoZSBNVFUuIEZvciBleGFtcGxlLCBz ZWUgdGhlIHNlY3Rpb24gb24gTVNTIGhhbmRsaW5nIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0 Mi5maXJlZXllLmNvbS92MS91cmw/az1jOTY0YTkxZi05N2M0MTM3MS1jOTY0ZTk4NC04NjYwMzg5 NzNhMTUtNGM1MzgwMDczMjJkODM5MiZhbXA7cT0xJmFtcDtlPThiNzJjYmMyLTY4M2EtNDkzYi1h MDc1LWM5ZGYwNjdiODhmNyZhbXA7dT1odHRwcyUzQSUyRiUyRnRtYS5pZmlwLm9yZyUyRjIwMTgl MkZ3cC1jb250ZW50JTJGdXBsb2FkcyUyRnNpdGVzJTJGMyUyRjIwMTglMkYwNiUyRnRtYTIwMThf cGFwZXI1Ny5wZGYiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3RtYS5pZmlwLm9yZy8yMDE4 L3dwLWNvbnRlbnQvdXBsb2Fkcy9zaXRlcy8zLzIwMTgvMDYvdG1hMjAxOF9wYXBlcjU3LnBkZjwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIG1pZ2h0IGJl IGJlY2F1c2Ugb2YgdGhlIHJlYXNvbnMgZm9yIHRoaXMgYXJlIGNpdGVkIGluIFJGQzg5MDAuDQo8 YnI+DQo8YnI+DQo8L3NwYW4+R29ycnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9d7e505786df4e9d903734a6a2ee588dhsesslingende_-- From nobody Tue Oct 20 14:04:26 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF383A08FF for ; Tue, 20 Oct 2020 14:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE8i4aU1XKIH for ; Tue, 20 Oct 2020 14:04:23 -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 A7BC53A08C7 for ; Tue, 20 Oct 2020 14:04:21 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:cc91:5f1d:e9de:152f] (unknown [IPv6:2a02:8109:1140:c3d:cc91:5f1d:e9de:152f]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id C7A1D72329C02; Tue, 20 Oct 2020 23:04:18 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Michael Tuexen In-Reply-To: <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> Date: Tue, 20 Oct 2020 23:04:16 +0200 Cc: Martin Duke , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 21:04:25 -0000 > On 20. Oct 2020, at 21:56, Scharf, Michael = wrote: >=20 > Hi all, >=20 > Sorry for the delayed reply. More inline... >=20 >>> On 19. Oct 2020, at 21:22, Martin Duke = wrote: >>>=20 >>> Hello tcpm, >>>=20 >>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST >> consider all IP and TCP options when sizing payloads with respect to = the >> advertised MSS option. >>>=20 >>> I'm reviewing a document that advises that some endpoints may want = to >> reduce their advertised MSS on IPv6 connections in case the peer = isn't >> respecting that guidance. Is noncompliance with this provision a = problem in >> the internet? Are there middleboxes injecting options that cause PMTU >> drops or fragmentation? >> Hi Martin, >>=20 >> the document you are reviewing says: >>=20 >> An IPv6 datagram size exceeding 1280 bytes can be avoided by = setting >> the TCP MSS not larger than 1220 bytes. This assumes that the = remote >> sender will use no TCP options, aside from possibly the MSS option, >> which is only used in the initial TCP SYN packet. >>=20 >> The first sentence is correct. The second is not. I would suggest to = simply >> remove it. >=20 > The statements regarding the MSS were discussed and also rewritten = many times. And, sorry, apparently I have not carefully read the second = sentence (but, well, that sentence was also in the version of the draft = that was last called in TCPM...) >=20 > Given this discussion now, I agree that the second sentence could = probably be removed. >=20 >> Then the text says: >>=20 >> In order to accommodate unrequested TCP options that may be used by >> some TCP implementations, a constrained device may advertise an MSS >> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note = that >> it is advised for TCP implementations to consume payload space >> instead of increasing datagram size when including IP or TCP = options >> in an IP packet to be sent [RFC6691]. Therefore, the suggestion of >> advertising an MSS smaller than 1220 bytes is likely to be >> overcautious and its suitability should be considered carefully. >>=20 >> I read this as "use a smaller MSS", but this is "likely to be >> overcautious and its suitability should be considered carefully." >>=20 >> I think the careful consideration is to remove this paragraph. >=20 > I am not sure if we should simply remove the whole paragraph, = including e.g. the reference to RFC 6691. Readers The paragraph starts with: In order to accommodate unrequested TCP options that may be used by some TCP implementations, a constrained device may advertise an MSS smaller than 1220 bytes (e.g. not larger than 1200 bytes). I don't think the selection of the MSS should depend on TCP options. A TCP stack may send an MSS option with a value lower then 1220, but it should not do it due to any TCP options. That is the reason, why I suggested to remove the paragraph. Best regards Michael > of this document may not be aware of RFC 6691, so a pointer may be = useful, no? Also, during the IETF last call there was a discussion on = MSS values significantly smaller than 1220 byte. People apparently *do* = think about smaller MSS values on constrained devices and this document = is a place to provide guidance to that community (as far as possible). = This specific wording came up in earlier reviews of the draft, too. = Thus, the final proposal "likely to be overcautious and its suitability = should be considered carefully" is a result of several past discussions. = IMHO we should carefully consider changes to this statement... >=20 > BTW, personally, I really wonder if using an MSS of 1220 byte (for = IPv6) indeed causes real-world problems on constrained devices, i.e., if = in year 2020 there is any real-world benefit of an MSS smaller than 1220 = byte. But, unfortunately, I don't have measurement data that would back = a different statement in the draft. >=20 > Michael >=20 >> Best regards >> Michael >>=20 >>=20 >>=20 >>=20 >>>=20 >>> I have not heard of such problems, but thought I'd check with the >> community to see if this precaution makes any sense at all. >>>=20 >>> Thanks, >>> Martin >>>=20 >>>=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 Tue Oct 20 14:18:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F53A13B2 for ; Tue, 20 Oct 2020 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlywC9XoNqLc for ; Tue, 20 Oct 2020 14:18:34 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2992D3A13AD for ; Tue, 20 Oct 2020 14:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=34wfrVoMLEAYjgxns85/G/EkymsqgY8sb6uW26pesrA=; b=boIQQYyPkQ2Bq5mhc8T2tyNNN zEp0I1vDtSY18+YJf9f6uUcRu5lyY5akO7cNR8oZnJ1xBFWUb8HL1I0xNphWSYWXM59/NCon4159U h7ch1GvuT3wAwIyaxkQHNCpgbewhOYHJj25ER7v5bZLjIa+owOsOxafnuxiNcf9MGEDFtvdlTPc13 OWtC1qh6IIudJ6hNXdWBV1UWOCNDwSAHKeGLW7rUauUFAtnuAvNJsQQwZ35ovEWhPlhLKkD5sEeN4 S179x4AiVt0nkgKW3EP9X1eMsmdhJSAzaBi9ULL71zKdIgFs7UllmYAzzkUYZTeu+MfaR/bDYKWkn vR01K1S6g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60722 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kUz1S-003Yqh-UM; Tue, 20 Oct 2020 17:18:27 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> Date: Tue, 20 Oct 2020 14:18:22 -0700 Cc: "Scharf, Michael" , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 21:18:36 -0000 > On Oct 20, 2020, at 2:04 PM, Michael Tuexen = wrote: >=20 >> On 20. Oct 2020, at 21:56, Scharf, Michael = wrote: >>=20 >> ... >> I am not sure if we should simply remove the whole paragraph, = including e.g. the reference to RFC 6691. Readers > The paragraph starts with: >=20 > In order to accommodate unrequested TCP options that may be used by > some TCP implementations, a constrained device may advertise an MSS > smaller than 1220 bytes (e.g. not larger than 1200 bytes). What does =E2=80=9Cunrequested=E2=80=9D mean? It legitimately means = options users haven=E2=80=99t asked for but are enabled somehow = (default, OS override, etc.). But that=E2=80=99s already taken care of - the side sending MMS = indicates the value without considering options *because* it is the = other side that uses the MSS *and its knowledge of which options it is = adding, both at IP and TCP* to determine how much data payload room is = available. (And no, I still don=E2=80=99t think this should include a guess as to = =E2=80=9Chow much a middlebox will expand the packet=E2=80=9D). > I don't think the selection of the MSS should depend on TCP options. RFC6691 is very clear - it definitely should not. > A TCP stack may send an MSS option with a value lower then 1220, but > it should not do it due to any TCP options. Agreed. Joe From nobody Wed Oct 21 00:31:57 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A70A3A11EE for ; Wed, 21 Oct 2020 00:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 jaIaNrr5rZso for ; Wed, 21 Oct 2020 00:31:54 -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 F3F0B3A11EF for ; Wed, 21 Oct 2020 00:31:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id BEEDE25A1E; Wed, 21 Oct 2020 09:31:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603265511; bh=UlOeNk8FoF6IC3wPvZaEbUbPa7jlieSBYdvQUoJlMeE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Brq3C58dkhi57qr1wvvwDYRV28xDLDrnCA533HCdSfT01McagZxxizsS6f7k6t0uW dURlnbt7VWGa6ebrlwKDNgag/PwBsmTbuhIIwiNgdYXU6UHqI4zbEhBGRHVB4Mq7u9 6HYSBsvWZn2iZVgCD+vn914ClqD2Vn5dBxC6/5m4= 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 tZouyU7St5l8; Wed, 21 Oct 2020 09:31:50 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 21 Oct 2020 09:31:50 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 21 Oct 2020 09:31:50 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Wed, 21 Oct 2020 09:31:50 +0200 From: "Scharf, Michael" To: Michael Tuexen CC: Martin Duke , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Exceeding value in MSS option? Thread-Index: AQHWpk1K5yCW3VOIm02cl+MOJ34oLamfNjuAgAGnxdD///0BAIAAyrlw Date: Wed, 21 Oct 2020 07:31:50 +0000 Message-ID: <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> In-Reply-To: <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 07:31:56 -0000 > > On 20. Oct 2020, at 21:56, Scharf, Michael esslingen.de> wrote: > > > > Hi all, > > > > Sorry for the delayed reply. More inline... > > > >>> On 19. Oct 2020, at 21:22, Martin Duke > wrote: > >>> > >>> Hello tcpm, > >>> > >>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST > >> consider all IP and TCP options when sizing payloads with respect to t= he > >> advertised MSS option. > >>> > >>> I'm reviewing a document that advises that some endpoints may want to > >> reduce their advertised MSS on IPv6 connections in case the peer isn't > >> respecting that guidance. Is noncompliance with this provision a probl= em > in > >> the internet? Are there middleboxes injecting options that cause PMTU > >> drops or fragmentation? > >> Hi Martin, > >> > >> the document you are reviewing says: > >> > >> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting > >> the TCP MSS not larger than 1220 bytes. This assumes that the remot= e > >> sender will use no TCP options, aside from possibly the MSS option, > >> which is only used in the initial TCP SYN packet. > >> > >> The first sentence is correct. The second is not. I would suggest to s= imply > >> remove it. > > > > The statements regarding the MSS were discussed and also rewritten many > times. And, sorry, apparently I have not carefully read the second senten= ce > (but, well, that sentence was also in the version of the draft that was l= ast > called in TCPM...) > > > > Given this discussion now, I agree that the second sentence could proba= bly > be removed. > > > >> Then the text says: > >> > >> In order to accommodate unrequested TCP options that may be used by > >> some TCP implementations, a constrained device may advertise an MSS > >> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note tha= t > >> it is advised for TCP implementations to consume payload space > >> instead of increasing datagram size when including IP or TCP options > >> in an IP packet to be sent [RFC6691]. Therefore, the suggestion of > >> advertising an MSS smaller than 1220 bytes is likely to be > >> overcautious and its suitability should be considered carefully. > >> > >> I read this as "use a smaller MSS", but this is "likely to be > >> overcautious and its suitability should be considered carefully." > >> > >> I think the careful consideration is to remove this paragraph. > > > > I am not sure if we should simply remove the whole paragraph, including > e.g. the reference to RFC 6691. Readers > The paragraph starts with: >=20 > In order to accommodate unrequested TCP options that may be used by > some TCP implementations, a constrained device may advertise an MSS > smaller than 1220 bytes (e.g. not larger than 1200 bytes). >=20 > I don't think the selection of the MSS should depend on TCP options. > A TCP stack may send an MSS option with a value lower then 1220, but > it should not do it due to any TCP options. OK, thanks, now I actually get the point. Sorry, it was late yesterday. I a= gree. This is all what RFC 6691 is about. But I still wonder whether we should keep a reference to RFC 6691, given th= at this topic has repeatedly caused confusion. > That is the reason, why > I suggested to remove the paragraph. What about the following shorter paragraph with three sentences: An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than 1220 bytes. Note that it is advised for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, it is not required to advertise an MSS smaller than 1220 bytes in order to accommodate TCP options.=20 Would that be reasonable? Michael >=20 > Best regards > Michael >=20 > > of this document may not be aware of RFC 6691, so a pointer may be > useful, no? Also, during the IETF last call there was a discussion on MSS > values significantly smaller than 1220 byte. People apparently *do* think > about smaller MSS values on constrained devices and this document is a > place to provide guidance to that community (as far as possible). This sp= ecific > wording came up in earlier reviews of the draft, too. Thus, the final pro= posal > "likely to be overcautious and its suitability should be considered caref= ully" is > a result of several past discussions. IMHO we should carefully consider > changes to this statement... > > > > BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6= ) > indeed causes real-world problems on constrained devices, i.e., if in yea= r > 2020 there is any real-world benefit of an MSS smaller than 1220 byte. Bu= t, > unfortunately, I don't have measurement data that would back a different > statement in the draft. > > > > Michael > > > >> Best regards > >> Michael > >> > >> > >> > >> > >>> > >>> I have not heard of such problems, but thought I'd check with the > >> community to see if this precaution makes any sense at all. > >>> > >>> Thanks, > >>> Martin > >>> > >>> > >>> _______________________________________________ > >>> 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 Wed Oct 21 02:20:28 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F823A13EE for ; Wed, 21 Oct 2020 02:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HylP0bsAK1j for ; Wed, 21 Oct 2020 02:20:25 -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 D1C7B3A13ED for ; Wed, 21 Oct 2020 02:20:24 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:c439:9bc4:39b0:bf29] (unknown [IPv6:2a02:8109:1140:c3d:c439:9bc4:39b0:bf29]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id C8DE2721A642E; Wed, 21 Oct 2020 11:20:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Michael Tuexen In-Reply-To: <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> Date: Wed, 21 Oct 2020 11:20:19 +0200 Cc: Martin Duke , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <5EA759EB-3ECF-4889-BCFC-762E58EE7B64@lurchi.franken.de> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 09:20:28 -0000 > On 21. Oct 2020, at 09:31, Scharf, Michael = wrote: >=20 >>> On 20. Oct 2020, at 21:56, Scharf, Michael > esslingen.de> wrote: >>>=20 >>> Hi all, >>>=20 >>> Sorry for the delayed reply. More inline... >>>=20 >>>>> On 19. Oct 2020, at 21:22, Martin Duke >> wrote: >>>>>=20 >>>>> Hello tcpm, >>>>>=20 >>>>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender = MUST >>>> consider all IP and TCP options when sizing payloads with respect = to the >>>> advertised MSS option. >>>>>=20 >>>>> I'm reviewing a document that advises that some endpoints may want = to >>>> reduce their advertised MSS on IPv6 connections in case the peer = isn't >>>> respecting that guidance. Is noncompliance with this provision a = problem >> in >>>> the internet? Are there middleboxes injecting options that cause = PMTU >>>> drops or fragmentation? >>>> Hi Martin, >>>>=20 >>>> the document you are reviewing says: >>>>=20 >>>> An IPv6 datagram size exceeding 1280 bytes can be avoided by = setting >>>> the TCP MSS not larger than 1220 bytes. This assumes that the = remote >>>> sender will use no TCP options, aside from possibly the MSS = option, >>>> which is only used in the initial TCP SYN packet. >>>>=20 >>>> The first sentence is correct. The second is not. I would suggest = to simply >>>> remove it. >>>=20 >>> The statements regarding the MSS were discussed and also rewritten = many >> times. And, sorry, apparently I have not carefully read the second = sentence >> (but, well, that sentence was also in the version of the draft that = was last >> called in TCPM...) >>>=20 >>> Given this discussion now, I agree that the second sentence could = probably >> be removed. >>>=20 >>>> Then the text says: >>>>=20 >>>> In order to accommodate unrequested TCP options that may be used = by >>>> some TCP implementations, a constrained device may advertise an = MSS >>>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note = that >>>> it is advised for TCP implementations to consume payload space >>>> instead of increasing datagram size when including IP or TCP = options >>>> in an IP packet to be sent [RFC6691]. Therefore, the suggestion = of >>>> advertising an MSS smaller than 1220 bytes is likely to be >>>> overcautious and its suitability should be considered carefully. >>>>=20 >>>> I read this as "use a smaller MSS", but this is "likely to be >>>> overcautious and its suitability should be considered carefully." >>>>=20 >>>> I think the careful consideration is to remove this paragraph. >>>=20 >>> I am not sure if we should simply remove the whole paragraph, = including >> e.g. the reference to RFC 6691. Readers >> The paragraph starts with: >>=20 >> In order to accommodate unrequested TCP options that may be used by >> some TCP implementations, a constrained device may advertise an MSS >> smaller than 1220 bytes (e.g. not larger than 1200 bytes). >>=20 >> I don't think the selection of the MSS should depend on TCP options. >> A TCP stack may send an MSS option with a value lower then 1220, but >> it should not do it due to any TCP options. >=20 > OK, thanks, now I actually get the point. Sorry, it was late = yesterday. I agree. This is all what RFC 6691 is about. No problem. >=20 > But I still wonder whether we should keep a reference to RFC 6691, = given that this topic has repeatedly caused confusion. That makes sense. >=20 >> That is the reason, why >> I suggested to remove the paragraph. >=20 > What about the following shorter paragraph with three sentences: >=20 > An IPv6 datagram size exceeding 1280 bytes can be avoided by setting > the TCP MSS not larger than 1220 bytes. Note that > it is advised for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. Therefore, it is not required = to > advertise an MSS smaller than 1220 bytes in order to accommodate > TCP options.=20 >=20 > Would that be reasonable? Sounds reasonable. Much better than the original text. Best regards Michael >=20 > Michael >=20 >>=20 >> Best regards >> Michael >>=20 >>> of this document may not be aware of RFC 6691, so a pointer may be >> useful, no? Also, during the IETF last call there was a discussion on = MSS >> values significantly smaller than 1220 byte. People apparently *do* = think >> about smaller MSS values on constrained devices and this document is = a >> place to provide guidance to that community (as far as possible). = This specific >> wording came up in earlier reviews of the draft, too. Thus, the final = proposal >> "likely to be overcautious and its suitability should be considered = carefully" is >> a result of several past discussions. IMHO we should carefully = consider >> changes to this statement... >>>=20 >>> BTW, personally, I really wonder if using an MSS of 1220 byte (for = IPv6) >> indeed causes real-world problems on constrained devices, i.e., if in = year >> 2020 there is any real-world benefit of an MSS smaller than 1220 = byte. But, >> unfortunately, I don't have measurement data that would back a = different >> statement in the draft. >>>=20 >>> Michael >>>=20 >>>> Best regards >>>> Michael >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> I have not heard of such problems, but thought I'd check with the >>>> community to see if this precaution makes any sense at all. >>>>>=20 >>>>> Thanks, >>>>> Martin >>>>>=20 >>>>>=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 >=20 From nobody Wed Oct 21 02:28:47 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CB03A1484 for ; Wed, 21 Oct 2020 02:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 sQUe6pcQQDge for ; Wed, 21 Oct 2020 02:28:44 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFBF3A1481 for ; Wed, 21 Oct 2020 02:28:44 -0700 (PDT) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BBFC91B00115 for ; Wed, 21 Oct 2020 10:28:41 +0100 (BST) To: tcpm@ietf.org References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> <5EA759EB-3ECF-4889-BCFC-762E58EE7B64@lurchi.franken.de> From: Gorry Fairhurst Message-ID: <85802820-1fe2-bfef-85b8-f63c7925bba4@erg.abdn.ac.uk> Date: Wed, 21 Oct 2020 10:28:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5EA759EB-3ECF-4889-BCFC-762E58EE7B64@lurchi.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 09:28:47 -0000 On 21/10/2020 10:20, Michael Tuexen wrote: >> On 21. Oct 2020, at 09:31, Scharf, Michael wrote: >> >>>> On 20. Oct 2020, at 21:56, Scharf, Michael >> esslingen.de> wrote: >>>> Hi all, >>>> >>>> Sorry for the delayed reply. More inline... >>>> >>>>>> On 19. Oct 2020, at 21:22, Martin Duke >>> wrote: >>>>>> Hello tcpm, >>>>>> >>>>>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST >>>>> consider all IP and TCP options when sizing payloads with respect to the >>>>> advertised MSS option. >>>>>> I'm reviewing a document that advises that some endpoints may want to >>>>> reduce their advertised MSS on IPv6 connections in case the peer isn't >>>>> respecting that guidance. Is noncompliance with this provision a problem >>> in >>>>> the internet? Are there middleboxes injecting options that cause PMTU >>>>> drops or fragmentation? >>>>> Hi Martin, >>>>> >>>>> the document you are reviewing says: >>>>> >>>>> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >>>>> the TCP MSS not larger than 1220 bytes. This assumes that the remote >>>>> sender will use no TCP options, aside from possibly the MSS option, >>>>> which is only used in the initial TCP SYN packet. >>>>> >>>>> The first sentence is correct. The second is not. I would suggest to simply >>>>> remove it. >>>> The statements regarding the MSS were discussed and also rewritten many >>> times. And, sorry, apparently I have not carefully read the second sentence >>> (but, well, that sentence was also in the version of the draft that was last >>> called in TCPM...) >>>> Given this discussion now, I agree that the second sentence could probably >>> be removed. >>>>> Then the text says: >>>>> >>>>> In order to accommodate unrequested TCP options that may be used by >>>>> some TCP implementations, a constrained device may advertise an MSS >>>>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that >>>>> it is advised for TCP implementations to consume payload space >>>>> instead of increasing datagram size when including IP or TCP options >>>>> in an IP packet to be sent [RFC6691]. Therefore, the suggestion of >>>>> advertising an MSS smaller than 1220 bytes is likely to be >>>>> overcautious and its suitability should be considered carefully. >>>>> >>>>> I read this as "use a smaller MSS", but this is "likely to be >>>>> overcautious and its suitability should be considered carefully." >>>>> >>>>> I think the careful consideration is to remove this paragraph. >>>> I am not sure if we should simply remove the whole paragraph, including >>> e.g. the reference to RFC 6691. Readers >>> The paragraph starts with: >>> >>> In order to accommodate unrequested TCP options that may be used by >>> some TCP implementations, a constrained device may advertise an MSS >>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). >>> >>> I don't think the selection of the MSS should depend on TCP options. >>> A TCP stack may send an MSS option with a value lower then 1220, but >>> it should not do it due to any TCP options. >> OK, thanks, now I actually get the point. Sorry, it was late yesterday. I agree. This is all what RFC 6691 is about. > No problem. >> But I still wonder whether we should keep a reference to RFC 6691, given that this topic has repeatedly caused confusion. > That makes sense. >>> That is the reason, why >>> I suggested to remove the paragraph. >> What about the following shorter paragraph with three sentences: >> >> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >> the TCP MSS not larger than 1220 bytes. Note that >> it is advised for TCP implementations to consume payload space >> instead of increasing datagram size when including IP or TCP options >> in an IP packet to be sent [RFC6691]. Therefore, it is not required to >> advertise an MSS smaller than 1220 bytes in order to accommodate >> TCP options. >> >> Would that be reasonable? > Sounds reasonable. Much better than the original text. > > Best regards > Michael +1 Gorry >> Michael >> >>> Best regards >>> Michael >>> >>>> of this document may not be aware of RFC 6691, so a pointer may be >>> useful, no? Also, during the IETF last call there was a discussion on MSS >>> values significantly smaller than 1220 byte. People apparently *do* think >>> about smaller MSS values on constrained devices and this document is a >>> place to provide guidance to that community (as far as possible). This specific >>> wording came up in earlier reviews of the draft, too. Thus, the final proposal >>> "likely to be overcautious and its suitability should be considered carefully" is >>> a result of several past discussions. IMHO we should carefully consider >>> changes to this statement... >>>> BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6) >>> indeed causes real-world problems on constrained devices, i.e., if in year >>> 2020 there is any real-world benefit of an MSS smaller than 1220 byte. But, >>> unfortunately, I don't have measurement data that would back a different >>> statement in the draft. >>>> Michael >>>> >>>>> Best regards >>>>> Michael >>>>> >>>>> >>>>> >>>>> >>>>>> I have not heard of such problems, but thought I'd check with the >>>>> community to see if this precaution makes any sense at all. >>>>>> Thanks, >>>>>> Martin >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 -- G. Fairhurst, School of Engineering From nobody Wed Oct 21 02:38:48 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3DA3A14D6 for ; Wed, 21 Oct 2020 02:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 AX4XBCeB8yMB for ; Wed, 21 Oct 2020 02:38:45 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 57DCB3A14D5 for ; Wed, 21 Oct 2020 02:38:45 -0700 (PDT) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BBFC91B00115 for ; Wed, 21 Oct 2020 10:28:41 +0100 (BST) To: tcpm@ietf.org References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> <5EA759EB-3ECF-4889-BCFC-762E58EE7B64@lurchi.franken.de> From: Gorry Fairhurst Message-ID: <85802820-1fe2-bfef-85b8-f63c7925bba4@erg.abdn.ac.uk> Date: Wed, 21 Oct 2020 10:28:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5EA759EB-3ECF-4889-BCFC-762E58EE7B64@lurchi.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 09:38:48 -0000 On 21/10/2020 10:20, Michael Tuexen wrote: >> On 21. Oct 2020, at 09:31, Scharf, Michael wrote: >> >>>> On 20. Oct 2020, at 21:56, Scharf, Michael >> esslingen.de> wrote: >>>> Hi all, >>>> >>>> Sorry for the delayed reply. More inline... >>>> >>>>>> On 19. Oct 2020, at 21:22, Martin Duke >>> wrote: >>>>>> Hello tcpm, >>>>>> >>>>>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST >>>>> consider all IP and TCP options when sizing payloads with respect to the >>>>> advertised MSS option. >>>>>> I'm reviewing a document that advises that some endpoints may want to >>>>> reduce their advertised MSS on IPv6 connections in case the peer isn't >>>>> respecting that guidance. Is noncompliance with this provision a problem >>> in >>>>> the internet? Are there middleboxes injecting options that cause PMTU >>>>> drops or fragmentation? >>>>> Hi Martin, >>>>> >>>>> the document you are reviewing says: >>>>> >>>>> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >>>>> the TCP MSS not larger than 1220 bytes. This assumes that the remote >>>>> sender will use no TCP options, aside from possibly the MSS option, >>>>> which is only used in the initial TCP SYN packet. >>>>> >>>>> The first sentence is correct. The second is not. I would suggest to simply >>>>> remove it. >>>> The statements regarding the MSS were discussed and also rewritten many >>> times. And, sorry, apparently I have not carefully read the second sentence >>> (but, well, that sentence was also in the version of the draft that was last >>> called in TCPM...) >>>> Given this discussion now, I agree that the second sentence could probably >>> be removed. >>>>> Then the text says: >>>>> >>>>> In order to accommodate unrequested TCP options that may be used by >>>>> some TCP implementations, a constrained device may advertise an MSS >>>>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that >>>>> it is advised for TCP implementations to consume payload space >>>>> instead of increasing datagram size when including IP or TCP options >>>>> in an IP packet to be sent [RFC6691]. Therefore, the suggestion of >>>>> advertising an MSS smaller than 1220 bytes is likely to be >>>>> overcautious and its suitability should be considered carefully. >>>>> >>>>> I read this as "use a smaller MSS", but this is "likely to be >>>>> overcautious and its suitability should be considered carefully." >>>>> >>>>> I think the careful consideration is to remove this paragraph. >>>> I am not sure if we should simply remove the whole paragraph, including >>> e.g. the reference to RFC 6691. Readers >>> The paragraph starts with: >>> >>> In order to accommodate unrequested TCP options that may be used by >>> some TCP implementations, a constrained device may advertise an MSS >>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). >>> >>> I don't think the selection of the MSS should depend on TCP options. >>> A TCP stack may send an MSS option with a value lower then 1220, but >>> it should not do it due to any TCP options. >> OK, thanks, now I actually get the point. Sorry, it was late yesterday. I agree. This is all what RFC 6691 is about. > No problem. >> But I still wonder whether we should keep a reference to RFC 6691, given that this topic has repeatedly caused confusion. > That makes sense. >>> That is the reason, why >>> I suggested to remove the paragraph. >> What about the following shorter paragraph with three sentences: >> >> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >> the TCP MSS not larger than 1220 bytes. Note that >> it is advised for TCP implementations to consume payload space >> instead of increasing datagram size when including IP or TCP options >> in an IP packet to be sent [RFC6691]. Therefore, it is not required to >> advertise an MSS smaller than 1220 bytes in order to accommodate >> TCP options. >> >> Would that be reasonable? > Sounds reasonable. Much better than the original text. > > Best regards > Michael +1 Gorry >> Michael >> >>> Best regards >>> Michael >>> >>>> of this document may not be aware of RFC 6691, so a pointer may be >>> useful, no? Also, during the IETF last call there was a discussion on MSS >>> values significantly smaller than 1220 byte. People apparently *do* think >>> about smaller MSS values on constrained devices and this document is a >>> place to provide guidance to that community (as far as possible). This specific >>> wording came up in earlier reviews of the draft, too. Thus, the final proposal >>> "likely to be overcautious and its suitability should be considered carefully" is >>> a result of several past discussions. IMHO we should carefully consider >>> changes to this statement... >>>> BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6) >>> indeed causes real-world problems on constrained devices, i.e., if in year >>> 2020 there is any real-world benefit of an MSS smaller than 1220 byte. But, >>> unfortunately, I don't have measurement data that would back a different >>> statement in the draft. >>>> Michael >>>> >>>>> Best regards >>>>> Michael >>>>> >>>>> >>>>> >>>>> >>>>>> I have not heard of such problems, but thought I'd check with the >>>>> community to see if this precaution makes any sense at all. >>>>>> Thanks, >>>>>> Martin >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 -- G. Fairhurst, School of Engineering From nobody Wed Oct 21 03:04:30 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177B63A1598 for ; Wed, 21 Oct 2020 03:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfZMAokH6wH9 for ; Wed, 21 Oct 2020 03:04:27 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA2E3A159B for ; Wed, 21 Oct 2020 03:04:26 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 21 Oct 2020 13:04:09 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=ijobRNtAPiLFJWXAW JfzXfTOYq2egC0lo8cdC1tBOYk=; b=WcY2uW9kzNHbgxl6fVySwuCR7/cdHJwS+ HGs+8zT7Pv/4XLwleiAY6wy3wQURwP7aEExnPs/mYUUIhzCu3Ei7KXQbe9Ojmn93 S0u7Q6BOe+nqz/qLIjX04RN/9SzMuMOa9nakWaba6f6HLKQH4GkFzv1+eH0c13mv huu0csXGBY= Received: from hp8x-60 (85-76-65-98-nat.elisa-mobile.fi [85.76.65.98]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Wed, 21 Oct 2020 13:04:09 +0300 id 00000000005A01BC.000000005F900799.00000603 Date: Wed, 21 Oct 2020 13:04:09 +0300 (EEST) From: Markku Kojo To: Michael Scharf cc: Michael Tuexen , "tcpm@ietf.org Extensions" In-Reply-To: <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> Message-ID: References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 10:04:29 -0000 Hi, see inline. On Wed, 21 Oct 2020, Michael Scharf wrote: >>> On 20. Oct 2020, at 21:56, Scharf, Michael > esslingen.de> wrote: >>> >>> Hi all, >>> >>> Sorry for the delayed reply. More inline... >>> >>>>> On 19. Oct 2020, at 21:22, Martin Duke >> wrote: >>>>> >>>>> Hello tcpm, >>>>> >>>>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST >>>> consider all IP and TCP options when sizing payloads with respect to the >>>> advertised MSS option. >>>>> >>>>> I'm reviewing a document that advises that some endpoints may want to >>>> reduce their advertised MSS on IPv6 connections in case the peer isn't >>>> respecting that guidance. Is noncompliance with this provision a problem >> in >>>> the internet? Are there middleboxes injecting options that cause PMTU >>>> drops or fragmentation? >>>> Hi Martin, >>>> >>>> the document you are reviewing says: >>>> >>>> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >>>> the TCP MSS not larger than 1220 bytes. This assumes that the remote >>>> sender will use no TCP options, aside from possibly the MSS option, >>>> which is only used in the initial TCP SYN packet. >>>> >>>> The first sentence is correct. The second is not. I would suggest to simply >>>> remove it. >>> >>> The statements regarding the MSS were discussed and also rewritten many >> times. And, sorry, apparently I have not carefully read the second sentence >> (but, well, that sentence was also in the version of the draft that was last >> called in TCPM...) >>> >>> Given this discussion now, I agree that the second sentence could probably >> be removed. >>> >>>> Then the text says: >>>> >>>> In order to accommodate unrequested TCP options that may be used by >>>> some TCP implementations, a constrained device may advertise an MSS >>>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that >>>> it is advised for TCP implementations to consume payload space >>>> instead of increasing datagram size when including IP or TCP options >>>> in an IP packet to be sent [RFC6691]. Therefore, the suggestion of >>>> advertising an MSS smaller than 1220 bytes is likely to be >>>> overcautious and its suitability should be considered carefully. >>>> >>>> I read this as "use a smaller MSS", but this is "likely to be >>>> overcautious and its suitability should be considered carefully." >>>> >>>> I think the careful consideration is to remove this paragraph. >>> >>> I am not sure if we should simply remove the whole paragraph, including >> e.g. the reference to RFC 6691. Readers >> The paragraph starts with: >> >> In order to accommodate unrequested TCP options that may be used by >> some TCP implementations, a constrained device may advertise an MSS >> smaller than 1220 bytes (e.g. not larger than 1200 bytes). >> >> I don't think the selection of the MSS should depend on TCP options. >> A TCP stack may send an MSS option with a value lower then 1220, but >> it should not do it due to any TCP options. > > OK, thanks, now I actually get the point. Sorry, it was late yesterday. I agree. This is all what RFC 6691 is about. > > But I still wonder whether we should keep a reference to RFC 6691, given that this topic has repeatedly caused confusion. > >> That is the reason, why >> I suggested to remove the paragraph. > > What about the following shorter paragraph with three sentences: > > An IPv6 datagram size exceeding 1280 bytes can be avoided by setting > the TCP MSS not larger than 1220 bytes. Note that > it is advised for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. Therefore, it is not required to > advertise an MSS smaller than 1220 bytes in order to accommodate > TCP options. > > Would that be reasonable? That's much better but I would say it even more strongly because this is MUST in RFC 1122 as pointed out earlier: " ... Note that it is advised for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. ..." -> " ... Note that TCP implementations MUST consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC1122, RFC6691]. ..." OR (if RFC 2119 language is not used in this doc, and currently it is not used although section 2 exists): " ... Note that it is required for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC1122, RFC6691]. ..." BR, /Markku > Michael > >> >> Best regards >> Michael >> >>> of this document may not be aware of RFC 6691, so a pointer may be >> useful, no? Also, during the IETF last call there was a discussion on MSS >> values significantly smaller than 1220 byte. People apparently *do* think >> about smaller MSS values on constrained devices and this document is a >> place to provide guidance to that community (as far as possible). This specific >> wording came up in earlier reviews of the draft, too. Thus, the final proposal >> "likely to be overcautious and its suitability should be considered carefully" is >> a result of several past discussions. IMHO we should carefully consider >> changes to this statement... >>> >>> BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6) >> indeed causes real-world problems on constrained devices, i.e., if in year >> 2020 there is any real-world benefit of an MSS smaller than 1220 byte. But, >> unfortunately, I don't have measurement data that would back a different >> statement in the draft. >>> >>> Michael >>> >>>> Best regards >>>> Michael >>>> >>>> >>>> >>>> >>>>> >>>>> I have not heard of such problems, but thought I'd check with the >>>> community to see if this precaution makes any sense at all. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > From nobody Wed Oct 21 06:53:57 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E763A0BAD for ; Wed, 21 Oct 2020 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y-mVr1qJXZL for ; Wed, 21 Oct 2020 06:53:52 -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 7B49E3A0BA4 for ; Wed, 21 Oct 2020 06:53:52 -0700 (PDT) Received: from mbp.fritz.box (ip4d16e8c9.dynamic.kabel-deutschland.de [77.22.232.201]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 1787F722CD406; Wed, 21 Oct 2020 15:53:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Michael Tuexen In-Reply-To: Date: Wed, 21 Oct 2020 15:53:48 +0200 Cc: Michael Scharf , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <89E03CDC-9F5A-4B19-8EB2-520068DA9757@lurchi.franken.de> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> To: Markku Kojo X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 13:53:56 -0000 > On 21. Oct 2020, at 12:04, Markku Kojo wrote: >=20 > Hi, >=20 > see inline. >=20 > On Wed, 21 Oct 2020, Michael Scharf wrote: >=20 >>>> On 20. Oct 2020, at 21:56, Scharf, Michael >> esslingen.de> wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> Sorry for the delayed reply. More inline... >>>>=20 >>>>>> On 19. Oct 2020, at 21:22, Martin Duke >>> wrote: >>>>>>=20 >>>>>> Hello tcpm, >>>>>>=20 >>>>>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender = MUST >>>>> consider all IP and TCP options when sizing payloads with respect = to the >>>>> advertised MSS option. >>>>>>=20 >>>>>> I'm reviewing a document that advises that some endpoints may = want to >>>>> reduce their advertised MSS on IPv6 connections in case the peer = isn't >>>>> respecting that guidance. Is noncompliance with this provision a = problem >>> in >>>>> the internet? Are there middleboxes injecting options that cause = PMTU >>>>> drops or fragmentation? >>>>> Hi Martin, >>>>>=20 >>>>> the document you are reviewing says: >>>>>=20 >>>>> An IPv6 datagram size exceeding 1280 bytes can be avoided by = setting >>>>> the TCP MSS not larger than 1220 bytes. This assumes that the = remote >>>>> sender will use no TCP options, aside from possibly the MSS = option, >>>>> which is only used in the initial TCP SYN packet. >>>>>=20 >>>>> The first sentence is correct. The second is not. I would suggest = to simply >>>>> remove it. >>>>=20 >>>> The statements regarding the MSS were discussed and also rewritten = many >>> times. And, sorry, apparently I have not carefully read the second = sentence >>> (but, well, that sentence was also in the version of the draft that = was last >>> called in TCPM...) >>>>=20 >>>> Given this discussion now, I agree that the second sentence could = probably >>> be removed. >>>>=20 >>>>> Then the text says: >>>>>=20 >>>>> In order to accommodate unrequested TCP options that may be used = by >>>>> some TCP implementations, a constrained device may advertise an = MSS >>>>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note = that >>>>> it is advised for TCP implementations to consume payload space >>>>> instead of increasing datagram size when including IP or TCP = options >>>>> in an IP packet to be sent [RFC6691]. Therefore, the suggestion = of >>>>> advertising an MSS smaller than 1220 bytes is likely to be >>>>> overcautious and its suitability should be considered carefully. >>>>>=20 >>>>> I read this as "use a smaller MSS", but this is "likely to be >>>>> overcautious and its suitability should be considered carefully." >>>>>=20 >>>>> I think the careful consideration is to remove this paragraph. >>>>=20 >>>> I am not sure if we should simply remove the whole paragraph, = including >>> e.g. the reference to RFC 6691. Readers >>> The paragraph starts with: >>>=20 >>> In order to accommodate unrequested TCP options that may be used by >>> some TCP implementations, a constrained device may advertise an MSS >>> smaller than 1220 bytes (e.g. not larger than 1200 bytes). >>>=20 >>> I don't think the selection of the MSS should depend on TCP options. >>> A TCP stack may send an MSS option with a value lower then 1220, but >>> it should not do it due to any TCP options. >>=20 >> OK, thanks, now I actually get the point. Sorry, it was late = yesterday. I agree. This is all what RFC 6691 is about. >>=20 >> But I still wonder whether we should keep a reference to RFC 6691, = given that this topic has repeatedly caused confusion. >>=20 >>> That is the reason, why >>> I suggested to remove the paragraph. >>=20 >> What about the following shorter paragraph with three sentences: >>=20 >> An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >> the TCP MSS not larger than 1220 bytes. Note that >> it is advised for TCP implementations to consume payload space >> instead of increasing datagram size when including IP or TCP options >> in an IP packet to be sent [RFC6691]. Therefore, it is not required = to >> advertise an MSS smaller than 1220 bytes in order to accommodate >> TCP options. >>=20 >> Would that be reasonable? >=20 > That's much better but I would say it even more strongly because this = is MUST in RFC 1122 as pointed out earlier: >=20 > " ... > Note that > it is advised for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. > ..." >=20 > -> >=20 > " ... > Note that > TCP implementations MUST consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC1122, RFC6691]. > ..." >=20 > OR (if RFC 2119 language is not used in this doc, and currently it is = not used although section 2 exists): >=20 > " ... > Note that > it is required for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC1122, RFC6691]. > ..." >=20 I like these variants. Best regards Michael > BR, >=20 > /Markku >=20 >> Michael >>=20 >>>=20 >>> Best regards >>> Michael >>>=20 >>>> of this document may not be aware of RFC 6691, so a pointer may be >>> useful, no? Also, during the IETF last call there was a discussion = on MSS >>> values significantly smaller than 1220 byte. People apparently *do* = think >>> about smaller MSS values on constrained devices and this document is = a >>> place to provide guidance to that community (as far as possible). = This specific >>> wording came up in earlier reviews of the draft, too. Thus, the = final proposal >>> "likely to be overcautious and its suitability should be considered = carefully" is >>> a result of several past discussions. IMHO we should carefully = consider >>> changes to this statement... >>>>=20 >>>> BTW, personally, I really wonder if using an MSS of 1220 byte (for = IPv6) >>> indeed causes real-world problems on constrained devices, i.e., if = in year >>> 2020 there is any real-world benefit of an MSS smaller than 1220 = byte. But, >>> unfortunately, I don't have measurement data that would back a = different >>> statement in the draft. >>>>=20 >>>> Michael >>>>=20 >>>>> Best regards >>>>> Michael >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I have not heard of such problems, but thought I'd check with the >>>>> community to see if this precaution makes any sense at all. >>>>>>=20 >>>>>> Thanks, >>>>>> Martin >>>>>>=20 >>>>>>=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 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 From nobody Wed Oct 21 09:40:26 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689003A115D for ; Wed, 21 Oct 2020 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4811jJ02uHv for ; Wed, 21 Oct 2020 09:40:23 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4798C3A0AF9 for ; Wed, 21 Oct 2020 09:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rvPaEZyTRV1elw4NWU1neMfU48xNy7I34ec6+Mo2mi4=; b=ec6WMwDVH9WhtG2bAydhJkmKl 26LAmV+FoK9BITPZeKMBFN99Na80UP4AWf6ws687paF6+CG5XLm8EuacE7hP1GInyyrcsxklzTN9n tpTkXfOYgVFK92BfZHQvgJ2kTMrA+bE4jnO7Ms2p/KS7N7qRFodMtMFx7mUjQOpS60BFlDB82QIwp Dn3E2LLIKH2lvC66CdaKYHvSEiXPGFxZ+cHZYWckoPzIC7e7m+CrGmrFSRGN0T4u3EV3vtETmCVsd jHyGIzruCuYFY9jkVEnchAm+WLcAnFHg+2/Srye8HBFNCR+jDLffALg+9sxZ+wKlXyENcK9MEwjr+ Wbg6VtXZg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60959 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kVH9t-003saK-2j; Wed, 21 Oct 2020 12:40:21 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <89E03CDC-9F5A-4B19-8EB2-520068DA9757@lurchi.franken.de> Date: Wed, 21 Oct 2020 09:40:16 -0700 Cc: Markku Kojo , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <32B4896B-7E08-45C5-9FB8-1348B3430627@strayalpha.com> References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> <89E03CDC-9F5A-4B19-8EB2-520068DA9757@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 16:40:24 -0000 FWIW - when citing requirements established elsewhere, IMO it=E2=80=99s = always better to NOT repeat it as a requirement elsewhere. It makes = updates very difficult. I.e., avoid 2119 language when referring to an existing requirement and = clearly indicate that this is a summary (=E2=80=9Calready a = requirement=E2=80=9D), e.g.: --- Note that it is already a requirement that TCP implementations consume = payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. -- FWIW - I would avoid citing 1122 because the entire issue is addressed = definitely in 6691. Joe= From nobody Wed Oct 21 09:42:11 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40893A1311 for ; Wed, 21 Oct 2020 09:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 aUQVldjVn_cn for ; Wed, 21 Oct 2020 09:42:09 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 85C5F3A1310 for ; Wed, 21 Oct 2020 09:42:09 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id p9so3165191ilr.1 for ; Wed, 21 Oct 2020 09:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zFkanijl7unvltMXUkRxyrJkU9CJELdiKBXz8qqs544=; b=pN5/42+cLnkpFnoR3A/Eo4+3iNqw9Ugzyg8vcQIacTNXPCsChrgvSwS/It1nb483py rSqz1uItUpbbuzxSgvThFKzEyIM7JVjuIn3JOCWyA8bBbXqXCQiDB6iyYjeKkLCI+e/Y aC17yRKDx/HsrGTnVbXkzjvc7WQtoK60UdVBwv7iP9p8qg/U0M9ju8CLJEcXgcC9cdeg 7nLqOY1OnH7MZEnvR+MHyE9/IcJQCG4dHajwLVswgwhMDgRti1xEcIdHIR18pqLelR49 ZOsGqqzCF4Rc0bonePg7d8yHeEVukoQIztT0dJoIi2vzlOGUuvsHfzpYNNAZyF4fbquu Dtag== 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=zFkanijl7unvltMXUkRxyrJkU9CJELdiKBXz8qqs544=; b=hBCcQEF+6BGQW2Seu99dsVUJRIN0ignD8AiBCAB0mB1ZRoPqnNNRtqTxAAGK0rmdB6 cEWEy1+4i376dlqZtJ72x+xldtXYjKeJww8r9ZYStWoVbttYCxZrmqLwjJA0bKHD9KnA QsXgz3sFOHacbntwbNJC8fe97cKvTh54s2ONxg69NBFrphsnJe9XFVTwGLq7zHH/Kxpi NlzNNJ420H3ZQ7p0/XgLoSTF9R/nJjzE0mgoDBNAnnB81Njb9eyDSkMNhOmj2zbziP6+ LLoAdHfFzeeQ/bpHIKkJHs/bRFZzJkSL1/BTZEUWLZFbZm6bLcreV5xd0esyclcQS9Oa 2EwQ== X-Gm-Message-State: AOAM530cUtjNowXibT3BhlQNqFHwbZMPyVzX2arBTjiLNTfpZ7MGxfeh gQFDFeMa/ySCzQkoCYmF2pDwAQoY9XR4inLYxGvvkiRrVn8= X-Google-Smtp-Source: ABdhPJx1uy4J97GhSs5HwLxd/Bfw1CxHGaXPVcNYShUZpnQl9nWjlV0MyrrzWwuWQtcjf3D4f6xTYBQBD73tA0L+0HQ= X-Received: by 2002:a05:6e02:1388:: with SMTP id d8mr3092993ilo.272.1603298528855; Wed, 21 Oct 2020 09:42:08 -0700 (PDT) MIME-Version: 1.0 References: <78558F1C-9194-4797-BE22-E553E1412E46@lurchi.franken.de> <7ded391321f94d0fb90fb5296de9fe43@hs-esslingen.de> <6AEBE48D-11BC-4837-BDB1-13E93CE11C84@lurchi.franken.de> <9d31403a88944c5b97eedbe9a465de6d@hs-esslingen.de> <89E03CDC-9F5A-4B19-8EB2-520068DA9757@lurchi.franken.de> <32B4896B-7E08-45C5-9FB8-1348B3430627@strayalpha.com> In-Reply-To: <32B4896B-7E08-45C5-9FB8-1348B3430627@strayalpha.com> From: Martin Duke Date: Wed, 21 Oct 2020 09:41:58 -0700 Message-ID: To: Joseph Touch Cc: Michael Tuexen , "tcpm@ietf.org Extensions" , Markku Kojo Content-Type: multipart/alternative; boundary="000000000000480b7505b231073c" Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 16:42:11 -0000 --000000000000480b7505b231073c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OTOH 1122 is a standard and 6691 is Informational. On Wed, Oct 21, 2020 at 9:40 AM Joseph Touch wrote: > FWIW - when citing requirements established elsewhere, IMO it=E2=80=99s a= lways > better to NOT repeat it as a requirement elsewhere. It makes updates very > difficult. > > I.e., avoid 2119 language when referring to an existing requirement and > clearly indicate that this is a summary (=E2=80=9Calready a requirement= =E2=80=9D), e.g.: > > --- > Note that it is already a requirement that TCP implementations consume > payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. > -- > > FWIW - I would avoid citing 1122 because the entire issue is addressed > definitely in 6691. > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000480b7505b231073c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OTOH 1122 is a standard and 6691 is Informational.
On Wed, = Oct 21, 2020 at 9:40 AM Joseph Touch <touch@strayalpha.com> wrote:
FWIW - when citing requirements established elsew= here, IMO it=E2=80=99s always better to NOT repeat it as a requirement else= where. It makes updates very difficult.

I.e., avoid 2119 language when referring to an existing requirement and cle= arly indicate that this is a summary (=E2=80=9Calready a requirement=E2=80= =9D), e.g.:

---
Note that it is already a requirement that TCP implementations consume payl= oad space
instead of increasing datagram size when including IP or TCP options
in an IP packet to be sent [RFC6691].
--

FWIW - I would avoid citing 1122 because the entire issue is addressed defi= nitely in 6691.

Joe
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000480b7505b231073c-- From nobody Wed Oct 21 10:15:56 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E2E3A1281 for ; Wed, 21 Oct 2020 10:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y0JIqv-gSQs for ; Wed, 21 Oct 2020 10:15:53 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066E73A11A6 for ; Wed, 21 Oct 2020 10:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nslHlDtCijFuhhPTn/ovtH6eC4pxUTs0leqEkBySXo8=; b=jYZcjSEhYbc4fYTft5FNjPS+X9 i00/kXjbOMoKpNll91AUA1y+95c0e0xhPqBFynicLYLWCam/TjOIY30RUbWGl2HuPuBpD2qPqiIMW /K/LKYIMHP4usjbyKsxQcMI+uDea7uUuJOhnEx4SnSQuspiKuLLHgnradbBWyEyfV5bRp5ykLcIGk 1PQm7LjHtUfgpG7XPrl/2vBnmIcJDy3pFmKwQjKN1HlHks/1jeaodkcQcA9LNJJYCMB1UgZzzsCbe n8I2pryGUVGmIQFNRMi0lQ1UJmUcFA2fmG74Zfu0WFtxq3xF8OmHw8cInK9IIrAsjEHl6teOGpiT3 XKaTTRJg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50576 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kVHiB-000491-T3; Wed, 21 Oct 2020 13:15:48 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-1565C797-C066-41E9-8449-E39254AD1F18 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Wed, 21 Oct 2020 10:15:43 -0700 Cc: Michael Tuexen , "tcpm@ietf.org Extensions" , Markku Kojo Message-Id: <3D61EB13-B999-46A0-B525-1A4B053DB300@strayalpha.com> References: To: Martin Duke X-Mailer: iPhone Mail (18A8395) 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] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 17:15:55 -0000 --Apple-Mail-1565C797-C066-41E9-8449-E39254AD1F18 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable IMO let 6691 speak to that. Ie, as explained in 6691 > On Oct 21, 2020, at 9:42 AM, Martin Duke wrote: >=20 > =EF=BB=BF > OTOH 1122 is a standard and 6691 is Informational. >=20 >> On Wed, Oct 21, 2020 at 9:40 AM Joseph Touch wrote= : >> FWIW - when citing requirements established elsewhere, IMO it=E2=80=99s a= lways better to NOT repeat it as a requirement elsewhere. It makes updates v= ery difficult. >>=20 >> I.e., avoid 2119 language when referring to an existing requirement and c= learly indicate that this is a summary (=E2=80=9Calready a requirement=E2=80= =9D), e.g.: >>=20 >> --- >> Note that it is already a requirement that TCP implementations consume pa= yload space >> instead of increasing datagram size when including IP or TCP options >> in an IP packet to be sent [RFC6691]. >> -- >>=20 >> FWIW - I would avoid citing 1122 because the entire issue is addressed de= finitely in 6691. >>=20 >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-1565C797-C066-41E9-8449-E39254AD1F18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
IMO let 6691 speak to that= . Ie, as explained in 6691

On Oct 21, 2020, at 9:42 AM, Martin Duke <martin.h.duke@gmail.com> w= rote:

=EF= =BB=BF
OTOH 1122 is a standard and 6691 is Informational.
On W= ed, Oct 21, 2020 at 9:40 AM Joseph Touch <touch@strayalpha.com> wrote:
FWIW - when citing requirements established elsew= here, IMO it=E2=80=99s always better to NOT repeat it as a requirement elsew= here. It makes updates very difficult.

I.e., avoid 2119 language when referring to an existing requirement and clea= rly indicate that this is a summary (=E2=80=9Calready a requirement=E2=80=9D= ), e.g.:

---
Note that it is already a requirement that TCP implementations consume paylo= ad space
instead of increasing datagram size when including IP or TCP options
in an IP packet to be sent [RFC6691].
--

FWIW - I would avoid citing 1122 because the entire issue is addressed defin= itely in 6691.

Joe
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
= --Apple-Mail-1565C797-C066-41E9-8449-E39254AD1F18-- From nobody Thu Oct 22 04:58:53 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87B43A0A68 for ; Thu, 22 Oct 2020 04:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwSZOJz4aHem for ; Thu, 22 Oct 2020 04:58:50 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60068.outbound.protection.outlook.com [40.107.6.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 838BD3A09DA for ; Thu, 22 Oct 2020 04:58:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eCS2/mRMQx194POVYzWrYqV1TivaC7WOzVPOzQuD8dbP65lRAxsMJHbtWAnjNayQTTrUDS+RE4h+LbSAREMY7+b5Vvi4Dwhnie16TzYw9IpMvYxhDF+O4R7jMIOnQev8m8BerGj9YBko/o9FyB/04is1XY+wsbwGkK4Z9v9vpmHylvWAy9rXXcVccN3wyap9TofDu3q/6FPDEr3hiav6MZkWZvzgHeyJUUZ9zWutIwCFn6B3+2ypYMHwu2HRFt1IknXnWK5Om+ziXAdNwX2I5faMeMyYZXuHmBWkaB4NsCnY/sQw64+EUJZUzSGNJaAugMbjMtRi83+PXkjZlnoi/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=39jCINt+3/e1+qArUk+AWKglXJtsyGPPYrS6AWpGCyg=; b=mLcahPWUbreJ4tgpZjnPQSqKyUvYSQ1EXpFEvZN8J67ex2vw/bi5QyfIKpSEA8gPKH9Nf6gFWe4+45SxnlMZRnUqVV6Wpl4WioiJE1XN7V2x2+onYT4PAY4zgiMhyOQi40OgGzF+q14X7zIFlWb6Hn+tOF1cKxjepDjh90tTqD1XILX7nS1SR2LBq0XphXa38ux8/SzYdsP5GckBMwp+EZoTfcJuFCYHjnHzG+BVb5OaeYGNZ0wy1riE2IXWD4OT67ohwNMI020L5gg/XAsbrsSYUEwHbdqZvTaoz9ZjglJbG+K5BOCe01jm7L3i6fcXI5NSon0TggOqbk89TP5keQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=39jCINt+3/e1+qArUk+AWKglXJtsyGPPYrS6AWpGCyg=; b=PggkRQu+26ZcI6/pafaLAFUZkX6EHa2u9tgl+E7rt0mkS4cpGrwjqQi7SQVjMHleQOrHKd9mYzjPp3ToSKHq8opTJPPeMwADg6P654nb3GG/iFy+Rc8zXVTw+GkzEwmSJ/YetDp040htB0ykCbZN4Uq0u9TYJwEwPnKXr5RlBKw= Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com (2603:10a6:208:19::10) by AM0PR07MB4724.eurprd07.prod.outlook.com (2603:10a6:208:7a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.11; Thu, 22 Oct 2020 11:58:47 +0000 Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::9820:af8a:cdbc:73b0]) by AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::9820:af8a:cdbc:73b0%7]) with mapi id 15.20.3499.017; Thu, 22 Oct 2020 11:58:47 +0000 From: Mirja Kuehlewind To: Michael Welzl , Matt Mathis CC: tcpm IETF list Thread-Topic: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS Thread-Index: AQHWpPH0I9lXo03nJ0in9JRDhfrQ7amd21+AgAFS8oCAAEqsgIAAf+uAgAAM6gCAA6c1AA== Date: Thu, 22 Oct 2020 11:58:47 +0000 Message-ID: References: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> <44DB6DE9-B150-4C2D-B516-A052D325370A@ifi.uio.no> <365A684B-6AC8-4DF4-9312-A934423DE7BA@ifi.uio.no> In-Reply-To: <365A684B-6AC8-4DF4-9312-A934423DE7BA@ifi.uio.no> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: ifi.uio.no; dkim=none (message not signed) header.d=none;ifi.uio.no; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e713:1b00:4560:3a00:2be6:1f6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f985cd9-9071-418b-c7e0-08d87681d53c x-ms-traffictypediagnostic: AM0PR07MB4724: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V52Z+YZykodH3qQsVHPFHRvzxX6cfdQL+NT2555chw5eV4SAGdrm6aedIIAUsegYbbv9XiZVXDT/f0Tp59tXffxy/+MABOOrgqQJw0zwgc8wAZBBjpgH5AdF5a5Dt6oFDLeCC/D0Nye2vzwEjIlCbEDGF/M9TcEReM/1to96pq4BDynPz5/NVcI7O8KVVzwM4s+3bcPHViwyREEU3FUkuOxAMwy9dSbXEt0JMXkxElMWWmrRucg4DfUDMp2+wJM9n+yXt7eVm/JXuFf+5QDh1rcPuyA4s81bA/Xto2NidHApx45kPAe/yoCPPO3Be+i6TZw2A/MrNsJ3da5h18O+7OCtWK7mKyMQpK36qYlMgeFtu6aSSlIzRsv4kscZgKpbeYNEdNKieIwBkKPGc498vg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3713.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(8936002)(36756003)(478600001)(6506007)(8676002)(53546011)(44832011)(5660300002)(186003)(4326008)(966005)(2616005)(71200400001)(110136005)(316002)(76116006)(66446008)(64756008)(66476007)(66946007)(66556008)(83380400001)(86362001)(33656002)(6486002)(6512007)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fKgZLt36P5gORklI09Rda89knyFQLobSZ5yybe0MtGP64CzCOFaYNyAX1S769S08fTn8yyZVVoLXJPlaDofKMwl0b/k+2+UWinKBxAf3liC4ajArUbdXG9OaR3jDsvA5YMLwruPtHPxCuerMlRvrH1gH/3y2jXBGxgPklwU8fLPW06uPxB/0ykdXIyt6KfBmmSXZV73WXL07u92/nitWug7G67E9UX93byKArEsEMDfVSFB+YxtDC6Nz83rslee1iq5ui6/9PnTHcE4pIePuvu6N8ujrGwHwvlr76R9LJJekrPSVo5D12rY4j/aorGEcFW+yhqdCj4I+JSZZSr9lMRw+zDGUK4Tp2wk/sU/nSpKQGwu370xSoyhq8D0XzkB/4FFs9MpXbJTHZxn7uC3r7H0u9tldUHypa+DIoxLiuYZh6h3ab8Ul+lS0Wr2XGtsE1Rku/eUQ30F/LSaoomi8gzCI7uo4HWkvbK3fvG3C1glv7pUc0nuC83x7oCWMHaFuriesqMu6AdGtMYz5NPOqbtm6WbzQs7cZNBOAnQOpGmemx+bm2b/vQ/EWemf54UhxvGr05yjUFJwhUaRha1203P2lddJQaFzna2iJXWlfGz1xq+F/JzcrkCtnQyO4/2CEVJTNFxPbF+wNcxwQ4gqgnt25axFFcvY7VbWpo+lLGt4OdDj0vKcYILx8k80NSGh19vC63JitrLiet129BPT8jw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2134F1AD50C1444CBBABEEC20BF65058@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3713.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f985cd9-9071-418b-c7e0-08d87681d53c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2020 11:58:47.2534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jjeQQeZ9usNbahFQmhoe7xkfawQePZQg/xliODzCDjOGXNVwBBO2CIXtHPbJqglc5TKCvvhFAADavromOrEpn7hYN0CyJQUg5ILbmVCoI64= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4724 Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 11:58:52 -0000 SGkgTWljaGFlbCwgaGkgTWF0dCwNCg0KRnJpc3QgSSBsaWtlIHRvIG5vdGUgdGhhdCBJIHN1cHBv cnQgbW92aW5nIFJGQzY5MzcgdG8gUFMgYW5kIEknbSBoYXBweSB0byBzZWUgdGhhdCB0aGVyZSBp cyBhbiBhZGRpdGlvbmFsIGhldXJpc3RpYyB0byBhZGRyZXNzICJkb3VibGUgZHJvcHMiLiANCg0K WWVhcnMgYWdvIHdoZW4gd2Ugd29ya2VkIG9uIFJGQzY5MzcgaW4gdGNwbSwgSSBiZWxpZXZlIEkg b2JzZXJ2ZWQgYSBzaW1pbGFyIHByb2JsZW0gYWZ0ZXIgc2xvdyBzdGFydCwgd2hlcmUgc2xvdyBz dGFydCB3aWxsIG5vdCBvbmx5IGZpbGwgdGhlIHF1ZXVlIGJ1dCBvdmVyc2hvb3QgdG8gZG91Ymxl IHRoZSBjd25kLiBTbyB3aGVuIHlvdSAib25seSIgaGFsdmUgdGhlIGN3bmQgYXMgUFJSIGRvZXMg Y29ycmVjdGx5LCB5b3UgZW5kIHVwIHdpbGwgYSBmdWxsIHF1ZXVlIGFmdGVyIHJlY292ZXJ5IGFu ZCB5b3Ugd2lsbCBzZWUgYW5vdGhlciBjb25nZXN0aW9uIGV2ZW50IHNvb24gYWZ0ZXIuIFJhdGUg aGFsdmluZyBob3dldmVyIHdvdWxkIGVuZCB1cCB3aXRoIG9ubHkgMS80IG9mIHRoZSBjd25kIGFm dGVyIHJlY292ZXJ5IGFuZCByZXNwZWN0aXZlbHkgZW1wdHkgdGhlIHF1ZXVlLiBIb3dldmVyLCBp biB0aGUgZW5kIHRoZXJlIHdhcyBub3QgbXVjaCBvZiBhIGRpZmZlcmVuY2UgKHJlZ2FyZGluZyB0 aHJvdWdocHV0IGFuZCBudW1iZXIgb2YgbG9zc2VzKSwgb25seSBQUlIgd291bGQgYWN0dWFsbHkg a2VlcCB0aGUgcXVldWUgc2xpZ2h0bHkgbG9uZ2VyIGZ1bGwuLi4gaXMgdGhpcyBjYXNlIGFsc28g YWRkcmVzc2VkIGJ5IHRoaXMgaGV1cmlzdGljPw0KDQpNaXJqYQ0KDQoNCg0K77u/T24gMjAuMTAu MjAsIDA4OjExLCAidGNwbSBvbiBiZWhhbGYgb2YgTWljaGFlbCBXZWx6bCIgPHRjcG0tYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWljaGF3ZUBpZmkudWlvLm5vPiB3cm90ZToNCg0KICAg IEhpIGFnYWluLA0KDQogICAgWW91IGRvbid0IHVuZGVyc3RhbmQgaXQgYmVjYXVzZSBpdCBkb2Vz bid0IG1ha2Ugc2Vuc2U7IEkgZ2V0IGl0IG5vdywgYW5kIEkgd2FzIGp1c3Qgd3JvbmcsIEknbSBz b3JyeS4NCiAgICBJJ3ZlIHJlY2VudGx5IGJlZW4gdGhpbmtpbmcgdG9vIG11Y2ggYWJvdXQgYSBw YWNlZCwgbm9uLWFjay1jbG9ja2VkIGJlaGF2aW9yLCB3aGVyZSB0aGluZ3MgbWlnaHQgaW5kZWVk IHBsYXkgb3V0IGFzIEkgZGVzY3JpYmVkLCBldmVuIHdpdGggYW4gb3ZlcnNob290IG9mIG9ubHkg b25lIHNlZ21lbnQuDQoNCiAgICBXaXRoIEFDSyBjbG9ja2luZywgYXMgeW91IHNhaWQsIHRoYXQg Y2FuJ3QgaGFwcGVuLiBJbiBmYWN0LCBJIGNhbiBzZWUgaXQgYmVjb21lIGEgcHJvYmxlbSBvbmx5 IGluIG9uZSBjYXNlOiB3aGVuIHRoZSBvdmVyc2hvb3QgaXMgc28gaGlnaCB0aGF0IHNldHRpbmcg YmFjayB0aGUgY3duZCB3b24ndCBzYXZlIHlvdSwgZXZlbiB3aXRoIGFjayBjbG9ja2luZy4gQnV0 IEkgdGhpbmsgdGhpcyB0cmFuc2xhdGVzIGV4YWN0bHkgaW50byAicGlwZSA8IHNzdGhyZXNoIiwg YW5kIHRoaXMgaXMgdGhlIGNhc2UgdGhhdCB0aGUgaGV1cmlzdGljcyBjb3ZlciAtIHdoaWNoLCBh cyB5b3Ugc2FpZCwgd2VyZSBkZXNpZ25lZCB0byBoYW5kbGUgdGhlc2UgZG91YmxlIGRyb3BzICgq KS4gU28gaXQgYWxsIG1ha2VzIHNlbnNlIHRvIG1lIG5vdywgc29ycnkgZm9yIHRoaXMgZXhjdXJz aW9uIGludG8gdGhlIGxhbmQgb24gbm9uc2Vuc2UuIENhc2UgY2xvc2VkLCBnbyBob21lIGV2ZXJ5 b25lLCBub3RoaW5nIHRvIHNlZSBoZXJlISAgOi0pDQoNCiAgICBDaGVlcnMsDQogICAgTWljaGFl bA0KICAgIC0tDQogICAgKCopIEluIHByYWN0aWNlLCBJIHRoZXJlZm9yZSB0aGluayB0aGF0IHRo ZXNlIGhldXJpc3RpY3MgY2FuIHBsYXkgYW4gaW1wb3J0YW50IHJvbGUgYWZ0ZXIgdGhlIHZlcnkg Zmlyc3Qgc2xvdyBzdGFydC4NCg0KDQoNCiAgICA+IE9uIDIwIE9jdCAyMDIwLCBhdCAwNzoyNSwg TWF0dCBNYXRoaXMgPG1hdHRtYXRoaXNAZ29vZ2xlLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+ IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgc2l0dWF0aW9uIHlvdSBhcmUgdGhpbmtpbmcgYWJvdXQu ICBJZiB0aGUgYm90dGxlbmVjayBCVyBjaGFuZ2VzIGFuZCBpdCBjYXVzZXMgbG9zcyBhbnkgbG9z cywgeW91IHdvdWxkIGV4cGVjdCB0byBzZWUgYSB3aG9sZSBSVFQgb2YgcGVyaW9kaWMgbG9zc2Vz IGJldHdlZW4gdGhlIGZpcnN0IGRldGVjdGVkIGxvc3MsIGFuZCB0aGUgQUNLIGZyb20gdGhlIGZp cnN0IHJldHJhbnNtaXNzaW9uLiAgSWYgaW5mbGlnaHQgKGFrYSBwaXBlKSBpcyBsYXJnZXIgdGhh biBzc3RocmVzaCwgUFJSIHdpbGwgYWx3YXlzIHNlbmQgbGVzcyBkYXRhIHRoYW4gaGFzIGxlZnQg dGhlIG5ldHdvcmsuICBUaGlzIGlzIGd1YXJhbnRlZWQgYnkgdGhlDQogICAgPiBjb25zZXJ2YXRp dmUgc2VsZiBjbG9jayBhbmQgdGhlICJwcm9wb3J0aW9uYWwiIHBhcnQgb2YgdGhlIGFsZ29yaXRo bS4gIFllcyBpdCBkcmFpbnMgdGhlIHF1ZXVlIHNsb3dseSwgYW5kIHllcyBjcm9zcyB0cmFmZmlj IGNhbiBjYXVzZSBhZGRpdGlvbmFsIGxvc3NlcywgYnV0IHRoYXQgaXMgYmVjYXVzZSB0aGUgY3Jv c3MgdHJhZmZpYyBpcyBiZWluZyB0b28gYWdncmVzc2l2ZSAoZS5nLiB0aGUgY3Jvc3MgdHJhZmZp YyBoYXMgdG8gc3RpbGwgYmUgaW5jcmVhc2luZyBpdHMgaW5zdGFudGFuZW91cyByYXRlIGZvciBz b21lIHJlYXNvbikuDQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+IC0tTU0tLQ0KICAgID4g VGhlIGJlc3Qgd2F5IHRvIHByZWRpY3QgdGhlIGZ1dHVyZSBpcyB0byBjcmVhdGUgaXQuICAtIEFs YW4gS2F5DQogICAgPiANCiAgICA+IFdlIG11c3Qgbm90IHRvbGVyYXRlIGludG9sZXJhbmNlOw0K ICAgID4gICAgICAgIGhvd2V2ZXIgb3VyIHJlc3BvbnNlIG11c3QgYmUgY2FyZWZ1bGx5IG1lYXN1 cmVkOiANCiAgICA+ICAgICAgICAgICAgIHRvbyBzdHJvbmcgd291bGQgYmUgaHlwb2NyaXRpY2Fs IGFuZCByaXNrcyBzcGlyYWxpbmcgb3V0IG9mIGNvbnRyb2w7DQogICAgPiAgICAgICAgICAgICB0 b28gd2VhayByaXNrcyBiZWluZyBtaXN0YWtlbiBmb3IgdGFjaXQgYXBwcm92YWwuDQogICAgPiAN CiAgICA+IA0KICAgID4gT24gTW9uLCBPY3QgMTksIDIwMjAgYXQgMjo0NyBQTSBNaWNoYWVsIFdl bHpsIDxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KICAgID4gSGksDQogICAgPiANCiAgICA+ IEluIGxpbmU6DQogICAgPiANCiAgICA+ID4gT24gT2N0IDE5LCAyMDIwLCBhdCA3OjIwIFBNLCBN YXR0IE1hdGhpcyA8bWF0dG1hdGhpc0Bnb29nbGUuY29tPiB3cm90ZToNCiAgICA+ID4gDQogICAg PiA+IFRoZSBoZXVyaXN0aWMgd2FzIGRlc2lnbmVkIHRvIGFkZHJlc3MgdGhlICJkb3VibGUgZHJv cHMiIHRoYXQgeW91IG5vdGVkLiAgICBCb3RoIFJGQyA2Njc1IGFuZCBQUlItU1NSQiBjYW4gYmUg dG9vIGFnZ3Jlc3NpdmUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBhcmUgYnVyc3QgbG9zc2Vz IHRoYXQgY2F1c2UgdGhlIGZsaWdodCBzaXplIHRvIGZhbGwgYmVsb3cgc3N0aHJlc2guICBTb21l dGltZXMgdGhlc2UgYXJlIG9rLCBidXQgdGhleSBvZnRlbiBjYXVzZSBsb3N0IHJldHJhbnNtaXNz aW9ucy4gIFRoZSBuZXcgaGV1cmlzdGljIGlzIHRvIHByZXZlbnQgdGhlc2Ugc2l0dWF0aW9uIGZy b20gcGVyc2lzdGluZy4NCiAgICA+IA0KICAgID4gSSBnZXQgdGhhdCwgYnV0IHdoYXQgSeKAmW0g Y29uY2VybmVkIGFib3V0IGlzIGEgY2FzZSB3aGVyZSBwaXBlIGlzICpub3QqIGJlbG93IHNzdGhy ZXNoLCBzbyB0aGUgaGV1cmlzdGljcyBkb27igJl0IGV2ZW4gYXBwbHkuIEl04oCZcyBlbm91Z2gg dG8gY29uc2lkZXIgdGhlIOKAnGRpYWdyYW0iIG9uIHBhZ2UgNywgd2hlcmUgaXTigJlzIGNsZWFy IHRoYXQgUkZDIDY2NzUgdGFrZXMgYSBicmVhayBmcm9tIHNlZ21lbnQgNCB0byAxMSBidXQgUFJS IChvciByYXRlLWhhbHZpbmcpIGRvZXNu4oCZdC4gVGhpcyBpcyBmaW5lIHdoZW4gdGhlIG5ldyBy YXRlIGlzIHNtYWxsZXIgdGhhbiB0aGUgYm90dGxlbmVja+KAmXMgY2FwYWNpdHksIGJ1dCBpZiBp dOKAmXMgbm90LCB0aGUgcXVldWUgc2hvdWxkIGp1c3Qgb3ZlcmZsb3cgYWdhaW4sIEkgYmVsaWV2 ZS4NCiAgICA+IA0KICAgID4gKGFnYWluLCB0aGVzZSBhcmUgYWxsIG1vcmUgc3VzcGljaW9ucyB0 aGFuIGFueXRoaW5nIGVsc2UgLSBJIG9ubHkgaGF2ZSBpbmRpY2F0aW9ucywgZnJvbSBvdXIgb3du IGV4cGVyaW1lbnRzIGFuZCB0aGUgcGFwZXIgSSBwb2ludGVkIHRvLCBub3RoaW5nIHJlYWxseSBj bGVhciB0aGF0IHNob3dzIHRoYXQgdGhpcyByZWFsbHkgaGFwcGVuczsgY29tZSB0byB0aGluayBv ZiBpdCwgaXQgYWN0dWFsbHkgd291bGRu4oCZdCBiZSBoYXJkIGZvciBtZSB0byBydW4gYSBjaGVj ayBpbiBvdXIgdGVzdGJlZOKApiBwZXJoYXBzIHRoYXQgd291bGQgYmUgYmV0dGVyIHRoYW4gbWFr aW5nIGEgZnVzcyBoZXJlIGFib3V0IHNvbWV0aGluZyB0aGF0IG1heSB0dXJuIG91dCB0byBiZSBu b3RoaW5nLiBUaGVuIGFnYWluLCBtYXliZSBpdOKAmXMgYSBnb29kIGNvbnZlcnNhdGlvbiB0byBo YXZlIGFueXdheSwganVzdCB0byBzZWUgd2hhdCB0aGUgdGhpbmtpbmcgYXJvdW5kIHRoaXMgdHlw ZSBvZiBjb25jZXJuIGlzLikNCiAgICA+IA0KICAgID4gDQogICAgPiA+IFRoZXNlIHNpdHVhdGlv bnMgYXJlIGhhcmQgdG8gcmVhc29uIGFib3V0IGJlY2F1c2UgdGhleSBjYW4gbm90IGJlIGNhdXNl ZCBieSBldmVudHMgdGhhdCBhcmUgbW9kZWxlZCBieSBzaW1wbGUgcXVldWVzLiAgVGhlIEZsYXRj aCBwYXBlciBpcyBhYm91dCB0b2tlbiBidWNrZXQgcG9saWNlcnMgd2hpY2ggY2F1c2UgaHVnZSBs b3NzZXMgd2hlbiB0aGV5IHJ1biBvdXQgb2YgdG9rZW5zIC0tIGFsbCB3aXRob3V0IHNpZ25pZmlj YW50IHF1ZXVlcy4gIE90aGVyIHBvdGVudGlhbCBldmVudHMgaW5jbHVkZSBidXJzdHkgY3Jvc3Mg dHJhZmZpYyBmcm9tIGxvbmcgUlRUIG9yIG5vbi1yZXNwb25zaXZlIGZsb3dzLg0KICAgID4gDQog ICAgPiBPaywgYnV0IHRoYXTigJlzIG5vdCB0aGUgY2FzZSBJIG1lYW4sIG1pbmUgaXMgc2ltcGxl ciAoYWJvdmUpLiBFdmVuIGp1c3QgYSBzaW5nbGUgcGFja2V0IGxvc3Mgd291bGQgc3VmZmljZSBm b3IgdGhlIHNpdHVhdGlvbiBJ4oCZbSB0YWxraW5nIGFib3V0Lg0KICAgID4gDQogICAgPiANCiAg ICA+ID4gV2l0aCBwYWNrZXQgY29uc2VydmF0aW9uLCBhIHNpbmdsZSBmbG93IGNhbiBub3QgY2F1 c2Ugc2VsZiBpbmZsaWN0ZWQgbG9zc2VzIHRoYXQgbGFzdCBtb3JlIHRoYW4gb25lIFJUVCwgYW5k IHRodXMgY2FuJ3QgY2F1c2UgbG9zdCByZXRyYW5zbWlzc2lvbnMuDQogICAgPiANCiAgICA+IEht bW1tbW3igKYuLiBJIGRvdWJ0IHRoaXM7IEkgdGhpbmsgdGhlIGJhY2tvZmYgZmFjdG9yIGFuZCBx dWV1ZSBhbHNvIHBsYXkgYSByb2xlLiBUaGUgcG9pbnQgaXMgdGhhdCB0aGUgbmV3IGN3bmQgbWF5 IGJlIHRvbyBtdWNoLCBqdXN0IGxpa2UgdGhlIG9sZCB3YXMgdG9vIG11Y2guDQogICAgPiANCiAg ICA+IA0KICAgID4gPiAgICAgSWYgdGhlcmUgYXJlIGxvc3QgcmV0cmFuc21pc3Npb25zIHNvbWV0 aGluZyBoYXBwZW5lZCB0aGF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIGEgc2ltcGxlIG5ldHdvcmsg bW9kZWwuDQogICAgPiA+IA0KICAgID4gPiBXaGlsZSBJIGFncmVlIHRoYXQgNjY3NSdzIGhhbGYg UlRUIG9mIHNpbGVuY2UgcmVkdWNlcyBxdWV1ZSBwcmVzc3VyZSwgdGhlIHJlc3BvbnNpYmlsaXR5 IGZvciB0aGF0IHJlYWxseSBiZWxvbmdzIHRvIGNvbmdlc3Rpb24gY29udHJvbCwgd2hpY2ggc2hv dWxkIG5vdCBiZSBjb250cm9sbGluZyBhZ2FpbnN0IHF1ZXVlIGZ1bGwuDQogICAgPiANCiAgICA+ IEkgYWdyZWUgd2l0aCB0aGUgdGhvdWdodCwgYnV0IGluIElFVEYgdGVybXMgSSB0aGluayB0aGF0 IGEgcmVjb3ZlcnkgbWVjaGFuaXNtIGluIGEgUFMgUkZDIGhhcyB0byBiZSBjb21wYXRpYmxlIHdp dGggUkZDIDU2ODEgdG9vLg0KICAgID4gDQogICAgPiANCiAgICA+ID4gICBUaGUgZ29hbCBvZiBQ UlIgaXMgdG8gbWluaW1pemUgdGhlIG9wcG9ydHVuaXRpZXMgdG8gbG9zZSB0aGUgc2VsZiBjbG9j ayBieSBhY2N1cmF0ZWx5IGNvbnRyb2xsaW5nIGZsaWdodHNpemUgdG8gdGhlIHRhcmdldCBzZXQg YnkgdGhlIGNvbmdlc3Rpb24gY29udHJvbC4NCiAgICA+ID4gDQogICAgPiA+IFRoZSBoZXVyaXN0 aWMgYWxzbyBoZWxwcyBpbiB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZXJlIHdhcyBhIGxhcmdlIHN0 ZXAgY2hhbmdlIGluIHRoZSBhdmFpbGFibGUgYmFuZHdpZHRoLCBhbmQgdGhlIENDIGNhbiBub3Qg cG9zc2libHkgZXN0aW1hdGUgdGhlIHRoZSBjb3JyZWN0IGZsaWdodHNpemUgcXVpY2tseSBlbm91 Z2guIA0KICAgID4gDQogICAgPiBJIHVuZGVyc3RhbmQ7IGdlbmVyYWxseSwgSSBkb27igJl0IGRv dWJ0IHRoYXQgdGhlcmUgYXJlIG1hbnkgZ29vZCBhc3BlY3RzIHRvIFBSUiwgYW5kIHRoYXQgaXQg d2lsbCB3b3JrIGJldHRlciB0aGFuIFJGQyA2Njc1IGluIG1hbnkgY2FzZXMuIFRoZSBoYWxmLVJU VC1vZi1ub3RoaW5nIHBhdHRlcm4gaXMganVzdCBvZGQuDQogICAgPiBTbyBtYXliZSB3aGF0IEni gJltIHdvcnJ5aW5nIGFib3V0IGlzIGEgY29ybmVyIGNhc2UuIEJ1dCwgYXMgd2UgdGFsayBhYm91 dCBwcm9jZWVkaW5nIHRvIFBTLCBJIHRoaW5rIGl0IGRlc2VydmVzIGEgdGhvdWdodC4NCiAgICA+ IA0KICAgID4gQ2hlZXJzLA0KICAgID4gTWljaGFlbA0KICAgID4gDQoNCiAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHRjcG0gbWFpbGluZyBs aXN0DQogICAgdGNwbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGNwbQ0KDQo= From nobody Thu Oct 22 05:49:43 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC523A0B79 for ; Thu, 22 Oct 2020 05:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjncQvQYSlos for ; Thu, 22 Oct 2020 05:49:39 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 63F803A0B80 for ; Thu, 22 Oct 2020 05:49:14 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kVa1m-00017j-QW; Thu, 22 Oct 2020 14:49:10 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kVa1m-000DBW-9b; Thu, 22 Oct 2020 14:49:10 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Thu, 22 Oct 2020 14:49:09 +0200 Cc: Matt Mathis , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CE9D0F2-88B6-4736-99C8-1533F625ACAA@ifi.uio.no> <44DB6DE9-B150-4C2D-B516-A052D325370A@ifi.uio.no> <365A684B-6AC8-4DF4-9312-A934423DE7BA@ifi.uio.no> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.021, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3A40FC8E4879C9C1606F0BABA4869A1135A261FF Archived-At: Subject: Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 12:49:42 -0000 Hi, > On 22 Oct 2020, at 13:58, Mirja Kuehlewind = wrote: >=20 > Hi Michael, hi Matt, >=20 > Frist I like to note that I support moving RFC6937 to PS and I'm happy = to see that there is an additional heuristic to address "double drops".=20= >=20 > Years ago when we worked on RFC6937 in tcpm, I believe I observed a = similar problem after slow start, where slow start will not only fill = the queue but overshoot to double the cwnd. So when you "only" halve the = cwnd as PRR does correctly, you end up will a full queue after recovery = and you will see another congestion event soon after. Yes - that's a general problem that we're now experiencing, as we're = playing around with pacing ... halving cwnd sometimes works ok when = senders are *not* paced, because the bursts may cause a drop before cwnd = has even overshot to double - but with a fully paced sending behavior, = halving cwnd after slow start is really not enough of a back-off, I = think. > Rate halving however would end up with only 1/4 of the cwnd after = recovery and respectively empty the queue. However, in the end there was = not much of a difference (regarding throughput and number of losses), = only PRR would actually keep the queue slightly longer full... is this = case also addressed by this heuristic? I'm curious about this too. I also wonder - in the case that I was concerned about at first, where = there is little loss (e.g., only one packet): yes, ACK clocking will = then prevent a double drop from happening, but PRR is also more likely = than RFC 6675 to keep a queue full at this point, by avoiding the = half-RTT break that may have allowed the queue to drain. So I still have = my question: has anybody seen problems with this? Is it only always an = advantage? (I'm suspecting that it is, unless the queue is = unreasonably large or there is a large amount of statmux ... but I = wonder about data). Cheers, Michael From nobody Thu Oct 22 15:48:41 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37D3A0B08 for ; Thu, 22 Oct 2020 15:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsWpFs8hELZA for ; Thu, 22 Oct 2020 15:48:37 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51A93A0FC4 for ; Thu, 22 Oct 2020 15:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:Message-Id:Subject:Date:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wc+aTKiUj6+8gdftcJfk8MWkq7dJKZjvKEP7DrCkl9E=; b=gzZpadnA4oRhohLtcF8s9fAjGV SpLzpH3QWJXh2dM/dC3FeKG922HIjalcXeGv5X/7D+4nXmV0vy00VTPq9JOFc1UArABqCyO7CFPYe Lrg+qEvcb8ubrn6dxq1Sj1jo4j8BUrjwdfeBCyavv+8nWplr/syBkKxSTTIzOcuUi0KYD/YHJQMpw BCupxCTRM2NyJZFl0bX15GmYG3Lbbk39Ig/iR6n0KLevlkjaK30oo8JjuBcr3H6y49B2OR23bHhxm 5UopkBQoDoyu7nEoEjKjRyYhY9zkKSy862M2oJ+Vg8Vcy6TQ4Ovl/Rq3AJMK2OWMpfkNDtjr24qPn JHSGkW5A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64568 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kVjNE-0027Ps-LM; Thu, 22 Oct 2020 18:48:01 -0400 From: Joseph Touch Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 22 Oct 2020 15:47:56 -0700 Message-Id: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> To: "Extensions tcpm@ietf.org" X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [tcpm] A few comments on 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: Thu, 22 Oct 2020 22:48:39 -0000 Hi, all, Comments below, if still useful. Joe =E2=80=94=E2=80=94 Regarding RFC5961, we were very careful in the applicability statement = therein to limit the SHOULD recommendations with specific conditions and = MAY implement elsewhere. This update to 793 misrepresents those current = recommendations as SHOULD for everyone, e.g., here: A potential blind reset attack is described in RFC 5961 [32], with the mitigation that a TCP implementation SHOULD first check that the sequence number exactly matches RCV.NXT prior to executing the action in the next paragraph. That text should instead say =E2=80=9CMAY first check=E2=80=9D, adding, = if desired, "(SHOULD, under the conditions noted in RFC 5961)=E2=80=9D. = That corrected text belongs also in section 3.4 where reset processing = is discussed. =E2=80=94 All places that mention issuing a RST (including sec 3.4 and the state = machine) should note that the side issuing the RST ought to enter = TIME_WAIT - and explain why, as noted in: Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and Its = Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999.=20 =E2=80=94 =20 The following text should include a MUST, as shown below: (all TCP options except End of option list and No-Operation MUST have length fields) =E2=80=94 The following text should be preceded by an inline =E2=80=98heading=E2=80=99= as shown: Experimental TCP options Experimental TCP option values are defined in [22], and [39] describes the current recommended usage for these experimental values. =E2=80=94 The following text should be moved earlier in the section, because its = current location suggests it is related to the experimental options = discussion (and it is not): Note: There is ongoing work to extend the space available for TCP options, such as [53]. It might be appropriate to move this before the discussion of specific = options, for example. =E2=80=94 The definition of TIME-WAIT should describe its purpose as also = including avoiding delayed segments from previous connections affecting = new connections. =E2=80=94 I would strongly encourage reformatting to allow the TCP state machine = to avoid page break boundaries. It may also be useful to add a note that RST can be issued from any = state with a corresponding (implied) transition to TIME-WAIT; similarly, = receipt of RST from any state goes to LISTEN. These transitions are not = shown only because they would complicate the diagram. =E2=80=94 The following statement is false: The protocol places no restriction on a particular connection being used over and over again. Avoiding that happening too quickly in succession is one of the purposes = of TIME-WAIT. New ISNs are only PART of that protection (which means the = rest of this section needs revision to clarify this issue). =E2=80=94 The security of TCP is discussed incorrectly, IMO. The ISN discussion = and RST discussion, in particular, although trying to help protect = against off-path attacks, are only very tenuously considered = =E2=80=9Csecurity=E2=80=9D. There should be some other way of discussing = this and making sure that if TCP users need secure connections they need = to use TCP-AO or IPsec. =E2=80=94 The ISN clock statement with MUST seems to overreach. The previous text = talks about the use of clocks being recommended, but a MUST is much = stronger. The assertion needs more wiggle words or a more generous = definition of clock to avoid being used out of context to prevent simple = implementations on lightweight devices. =E2=80=94 end. From nobody Thu Oct 22 22:20:50 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFD63A11FE for ; Thu, 22 Oct 2020 22:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 TJqb-t-aGrfs for ; Thu, 22 Oct 2020 22:20:46 -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 6DBA53A11FD for ; Thu, 22 Oct 2020 22:20:46 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id h5so330905wrv.7 for ; Thu, 22 Oct 2020 22:20:46 -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; bh=FP/wQF3gp6jZqtaLZE1/gLSrVCaw12g2niNTQfKRFaM=; b=MggzyYe13VIJYSgNTDK5AbYEQu9lLAo6BChqjg170ft7q6lLDpvCTA39jmJXaM1U8M UnAptd6ZnxgyTvQ8w2W9VSQOSIDWjiCdBoJgLK0C/Hwz8yy5qC+g4bdb0Q5KGUM/Pd1z u5MWZ32lQAaMeZziT87GFDF643d19J3gAUehfOxVDqsWwBS/OSHub/Yzlr3YTWhmS8zF QSb0dfKgHQ4iT0q6qjmPNTt4E3o0rf/5Z+OK0oosKnsQLQBVo59p2mCeBIpn/jt1WZHZ sHEJap6Ky38TgDKgOvDMHqNqb1og/xDFWhZ2fDHVW1m9ZQuC+wctOVXsKGXLlArHmCoY y2wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FP/wQF3gp6jZqtaLZE1/gLSrVCaw12g2niNTQfKRFaM=; b=SL5oJyapJ35lf4k6qIf+mt8xxGVTlYs3AeUZNDdvstlKtkAVRMr1EO1iWMx0rabMwf 5tDpKSi301QSmT85J6N9XmoiDarmdPGKM1G+ejyiJeD+8xUZFbEFl7E+6MH4QUBAfb12 rb/X3NPudxHA0iRrnoXRi9STkFvPJpXiR4zHtfVpvRlCWMcG55o3jEU3a9SXavLhSXxk boMO+KbOYB41Qr+CUMeI8K3g9FTgFNyrBjNGK+beQNPwTb/Qq2uENLlgvM1r38mbmBPH 9qtul2t0VyLlc6Gjh29xq+HG7aYsBs6tDNwjrMDgOxefTCC27SZFlJV/HTp8F5MI9UxV VDJg== X-Gm-Message-State: AOAM531lEVPswdJe6jYrovtSF8f7N8JtMxmryiffrfsCQrTNBHgQ1c6t /GyUacoMoxAI70JCdWv/jzgb4Tu0MR0kkh6S9fHJ9nuRkdY= X-Google-Smtp-Source: ABdhPJzu6/6udrys6W9YAbECKv32W3wj7aXguCsElruYCOEcTWEqqinRWb6IXgmC17UTezgX8N7ml4sisBDtXEF8nrE= X-Received: by 2002:adf:f1c1:: with SMTP id z1mr604095wro.331.1603430444769; Thu, 22 Oct 2020 22:20:44 -0700 (PDT) MIME-Version: 1.0 References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> In-Reply-To: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> From: Juhamatti Kuusisaari Date: Fri, 23 Oct 2020 08:20:32 +0300 Message-ID: To: Joseph Touch , tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000015266205b24fbe49" Archived-At: Subject: Re: [tcpm] A few comments on 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, 23 Oct 2020 05:20:49 -0000 --00000000000015266205b24fbe49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Especially the last ISN clock MUST statement is something that I also consider quite restrictive for low end devices. If we cannot change it for bis, some minimum viable solution described in detail/referenced would be nice. -- Juhamatti pe 23. lokakuuta 2020 klo 1.49 Joseph Touch kirjoitti: > Hi, all, > > Comments below, if still useful. > > Joe > > =E2=80=94=E2=80=94 > > Regarding RFC5961, we were very careful in the applicability statement > therein to limit the SHOULD recommendations with specific conditions and > MAY implement elsewhere. This update to 793 misrepresents those current > recommendations as SHOULD for everyone, e.g., here: > > A potential blind reset attack is described in RFC 5961 > [32], with the mitigation that a TCP implementation > SHOULD first check that the sequence number exactly > matches RCV.NXT prior to executing the action in the next > paragraph. > > That text should instead say =E2=80=9CMAY first check=E2=80=9D, adding, i= f desired, > "(SHOULD, under the conditions noted in RFC 5961)=E2=80=9D. That correcte= d text > belongs also in section 3.4 where reset processing is discussed. > > =E2=80=94 > > All places that mention issuing a RST (including sec 3.4 and the state > machine) should note that the side issuing the RST ought to enter TIME_WA= IT > - and explain why, as noted in: > Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and Its > Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999. > > =E2=80=94 > > The following text should include a MUST, as shown below: > > (all TCP options except End of option list and No-Operation > MUST have length fields) > > =E2=80=94 > > The following text should be preceded by an inline =E2=80=98heading=E2=80= =99 as shown: > > Experimental TCP options > > Experimental TCP option values are defined in [22], and [39] > describes the current recommended usage for these experimental > values. > > =E2=80=94 > > The following text should be moved earlier in the section, because its > current location suggests it is related to the experimental options > discussion (and it is not): > > Note: There is ongoing work to extend the space available for > TCP options, such as [53]. > > It might be appropriate to move this before the discussion of specific > options, for example. > > =E2=80=94 > > The definition of TIME-WAIT should describe its purpose as also including > avoiding delayed segments from previous connections affecting new > connections. > > =E2=80=94 > > I would strongly encourage reformatting to allow the TCP state machine to > avoid page break boundaries. > > It may also be useful to add a note that RST can be issued from any state > with a corresponding (implied) transition to TIME-WAIT; similarly, receip= t > of RST from any state goes to LISTEN. These transitions are not shown onl= y > because they would complicate the diagram. > > =E2=80=94 > > The following statement is false: > > The protocol places no restriction on a particular connection being > used over and over again. > > Avoiding that happening too quickly in succession is one of the purposes > of TIME-WAIT. New ISNs are only PART of that protection (which means the > rest of this section needs revision to clarify this issue). > > =E2=80=94 > > The security of TCP is discussed incorrectly, IMO. The ISN discussion and > RST discussion, in particular, although trying to help protect against > off-path attacks, are only very tenuously considered =E2=80=9Csecurity=E2= =80=9D. There > should be some other way of discussing this and making sure that if TCP > users need secure connections they need to use TCP-AO or IPsec. > > =E2=80=94 > > The ISN clock statement with MUST seems to overreach. The previous text > talks about the use of clocks being recommended, but a MUST is much > stronger. The assertion needs more wiggle words or a more generous > definition of clock to avoid being used out of context to prevent simple > implementations on lightweight devices. > > =E2=80=94 > end. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000015266205b24fbe49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= br>
+1

Especially the last ISN clock MUST statement = is something that I also consider quite restrictive for low end devices. If= we cannot change it for bis, some minimum viable solution described in det= ail/referenced would be nice.

--<= /div>
=C2=A0 Juhamatti

pe 23. lokakuuta 2020 klo 1.49 Joseph Touch <touch@strayalpha.com> kirjoitti:
Hi, all,

Comments below, if still useful.

Joe

=E2=80=94=E2=80=94

Regarding RFC5961, we were very careful in the applicability statement ther= ein to limit the SHOULD recommendations with specific conditions and MAY im= plement elsewhere. This update to 793 misrepresents those current recommend= ations as SHOULD for everyone, e.g., here:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A potential blind re= set attack is described in RFC 5961
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[32], with the mitig= ation that a TCP implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD first check t= hat the sequence number exactly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matches RCV.NXT prio= r to executing the action in the next
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0paragraph.

That text should instead say =E2=80=9CMAY first check=E2=80=9D, adding, if = desired, "(SHOULD, under the conditions noted in RFC 5961)=E2=80=9D. T= hat corrected text belongs also in section 3.4 where reset processing is di= scussed.

=E2=80=94

All places that mention issuing a RST (including sec 3.4 and the state mach= ine) should note that the side issuing the RST ought to enter TIME_WAIT - a= nd explain why, as noted in:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Faber, T; Touch, J; Yue, W: The TIME-WAIT state= in TCP and Its Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1= 999.

=E2=80=94

The following text should include a MUST, as shown below:

=C2=A0 =C2=A0 (all TCP options except End of option list and No-Operation =C2=A0 =C2=A0 =C2=A0MUST have length fields)

=E2=80=94

The following text should be preceded by an inline =E2=80=98heading=E2=80= =99 as shown:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Experimental TCP options

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Experimental TCP option values are defined in [= 22], and [39]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 describes the current recommended usage for the= se experimental
=C2=A0 =C2=A0 =C2=A0 =C2=A0 values.

=E2=80=94

The following text should be moved earlier in the section, because its curr= ent location suggests it is related to the experimental options discussion = (and it is not):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note: There is ongoing work to extend the space= available for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP options, such as [53].

It might be appropriate to move this before the discussion of specific opti= ons, for example.

=E2=80=94

The definition of TIME-WAIT should describe its purpose as also including a= voiding delayed segments from previous connections affecting new connection= s.

=E2=80=94

I would strongly encourage reformatting to allow the TCP state machine to a= void page break boundaries.

It may also be useful to add a note that RST can be issued from any state w= ith a corresponding (implied) transition to TIME-WAIT; similarly, receipt o= f RST from any state goes to LISTEN. These transitions are not shown only b= ecause they would complicate the diagram.

=E2=80=94

The following statement is false:

=C2=A0 The protocol places no restriction on a particular connection being<= br> =C2=A0 =C2=A0used over and over again.

Avoiding that happening too quickly in succession is one of the purposes of= TIME-WAIT. New ISNs are only PART of that protection (which means the rest= of this section needs revision to clarify this issue).

=E2=80=94

The security of TCP is discussed incorrectly, IMO. The ISN discussion and R= ST discussion, in particular, although trying to help protect against off-p= ath attacks, are only very tenuously considered =E2=80=9Csecurity=E2=80=9D.= There should be some other way of discussing this and making sure that if = TCP users need secure connections they need to use TCP-AO or IPsec.

=E2=80=94

The ISN clock statement with MUST seems to overreach. The previous text tal= ks about the use of clocks being recommended, but a MUST is much stronger. = The assertion needs more wiggle words or a more generous definition of cloc= k to avoid being used out of context to prevent simple implementations on l= ightweight devices.

=E2=80=94
end.





_______________________________________________
tcpm mailing list
tcpm@= ietf.org
https://www.ietf.org/mailman/listinfo/tcpm<= br>
--00000000000015266205b24fbe49-- From nobody Thu Oct 22 23:33:23 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F853A02BB for ; Thu, 22 Oct 2020 23:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 OZQ18v0oXXpB for ; Thu, 22 Oct 2020 23:33:21 -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 25C893A0121 for ; Thu, 22 Oct 2020 23:33:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0E03F25A14; Fri, 23 Oct 2020 08:33:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603434798; bh=z2PQmJal81rWmUcSC8RhFX/jBdKvAz1Oq/hhKV26+zc=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Y17DbosQzBIkNhngD1dXo14o0FOQ7EelK47HCDOq6woIGgRXMe4ZOCPXb+fQzAxv4 oO0BLUBDP+U5/+I7g1soDYBhrgD+YA2aVD7EPPHRTpsmCHDnKgEZ2euYxhMwB2m3Kd oxvmy/PJlRKwha5e6rKOfcSSo2U9CRthZwQTcEJ0= 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 0XeZSmcEI01v; Fri, 23 Oct 2020 08:33:17 +0200 (CEST) Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 23 Oct 2020 08:33:17 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 23 Oct 2020 08:33:17 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Fri, 23 Oct 2020 08:33:17 +0200 From: "Scharf, Michael" To: Joseph Touch , "Extensions tcpm@ietf.org" Thread-Topic: [tcpm] A few comments on 793bis Thread-Index: AQHWqMWl8zUQPgGMZUSoXyiNh9DSJKmkunXw Date: Fri, 23 Oct 2020 06:33:17 +0000 Message-ID: <20a19efd5c274232953ee5c01fa9bf1b@hs-esslingen.de> References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> In-Reply-To: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] A few comments on 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, 23 Oct 2020 06:33:22 -0000 QWxsLA0KDQo+IENvbW1lbnRzIGJlbG93LCBpZiBzdGlsbCB1c2VmdWwuDQo+IA0KPiBKb2UNCg0K VGhhbmtzLCBKb2UuDQoNCkBhbGw6IENvbW1lbnRzIG9uIDc5M2JpcyBhcmUgc3RpbGwgdXNlZnVs LiBJIGhhdmUgbm90IGNvbmNsdWRlZCB0aGUgV0dMQyBzbyBmYXIsIGFzIEkgaG9wZSB0byBnZXQg c29tZSAibGF0ZSIgcmV2aWV3cy4NCg0KTm9uZXRoZWxlc3MsIHdlIGFscmVhZHkgaGF2ZSBzb21l IGV4Y2VsbGVudCByZXZpZXdzIGZvciA3OTNiaXMsIGkuZS4sIEkgcGxhbiB0byBjb25jbHVkZSB0 aGUgV0dMQyBzb29uLWlzaC4NCg0KVGh1cywgaWYgcmZjNzkzIGlzIHN0aWxsIG9uIHlvdXIgVE9E TyBsaXN0LCBwbGVhc2UgaHVycnkgdXAhDQoNCk1pY2hhZWwNCg== From nobody Fri Oct 23 01:37:56 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD3F3A0A62 for ; Fri, 23 Oct 2020 01:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=tele.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 UlCZmZpLyNVW for ; Fri, 23 Oct 2020 01:37:51 -0700 (PDT) Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 8B6813A0A60 for ; Fri, 23 Oct 2020 01:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From: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=Dtskecs7WRfazdceonoE64BPAZrj8g4QBNkg0QSzN3M=; b=b5Rm2IyHad9v7bBV2JopoVSKFw 8QDE5JyssaBykBP4kd8Zw1vdoTu85Nejz0/Ka6wEONdlds307WEEsLGJxN4WZ7Yhbu2GhYRXVH3Jc qRpj2GUNitxST3EqTsBG79GKGioXoVBn145sMlQIgj90GFlhHxVs/Q7r0MtdaEpBHcgAWfXrwxR9D JiXU2GQSrER1+LvxHJBp9Lc6fugMByidAnLi8gVl/mvYB77q177KUBXIx4oQkvDRCgl/FU1QQYd6u 0MV6WJlaB7byrCnV0mP2iHE4tywPlf4NnO82VLcDxzjqodJ3cSDLJ9DTJG98PTpHaqXhMo9auVlws hCapMNfQ==; Received: from pilt2.tele.no ([2001:700:800::21] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from ) id 1kVsa0-00006m-Vm; Fri, 23 Oct 2020 10:37:45 +0200 From: Frode Kileng To: Mirja Kuehlewind Cc: "tcpm@ietf.org Extensions" References: <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk> Message-ID: Date: Fri, 23 Oct 2020 10:37:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 08:37:55 -0000 Hi, please see below On 20 Oct 2020, at 13:56, Mirja Kuehlewind wrote: > Hi Martin, hi Gorry, > > I think Gorry’s paper does indicate that at least for MSS, there are > middleboxes that add this option. However, I don’t think there is > evidence that there is a general problem about middlebox adding option > (rather than removing them). I also reviewed the draft in tsv-art > review and given that they say it’s actually not recommended and > should only be done with care, I thought that text is okay. However, I > guess there is room to improve the wording and explain a bit better, > when and if this might be consider or not. > Although maybe not  a "general problem",  a study of MSS middlebox manipluation in  23 European and Asian mobile networks did reveal some issues: - 20 of 23 networks always inserts MSS. Value for IPv4 varies from 1360 to 1420 and the value typically seems to reflect  vendor defaults - The 3 network that didn't clamp MSS do reduce an end-point specified values  if it's higher than some network specific threshold - 2 Networks overrode a end-point specified lower MSS value and changed it to the higher network specific default! I.e. a potential source of problems. - 1 Network did not clamp if some other TCP options was used (MPTCP, TFO, etc)! Also a source of problems. I'm afraid that the results from this study has not been published. Best regards Frode Kileng From nobody Fri Oct 23 08:09:27 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0B83A0EC4 for ; Fri, 23 Oct 2020 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW6ftHk9YlsI for ; Fri, 23 Oct 2020 08:09:23 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23483A0EC2 for ; Fri, 23 Oct 2020 08:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oHv711ZAQV2UiukiFJQxwXW3kKc6Q57Sn1x2ckFUHMo=; b=dGQ1iWNdwRthOJ1fFw84ZMjc0 Vjcfe6td1YAcAtJOvnEii0QFEzE8LYcc8vel7yM8tjKSl/rJHf5Aq457KKGFLQT9WUr0eD8PQij92 qN4PXB0G6+UqDcmX3uc8cBEfhQQ8TPghOWUiTBFNM3iZvHC63xA2x52Z9zVNPIF4peQfluY78+Jod zUxHNuCOKEoDVNh8vCyVEF5n38AfjHq3G+8x5VHBXSvdvL6ZXm6BToQJDT0LGS2xvzppm6ubtrvMf /74M/W1evlgJCAvZCVWyD02qMWyxVv+D5G+CeoUXPIknzIVRHpWVtXhwK5uPdMC1GRtvz1HCCGhmE vdHLO39iw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64871 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kVygv-000S5W-I5; Fri, 23 Oct 2020 11:09:22 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_725E9FD3-8BE5-41D2-BE8C-A786DF0764D5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Fri, 23 Oct 2020 08:09:16 -0700 Cc: tcpm IETF list Message-Id: References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> To: Juhamatti Kuusisaari X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] A few comments on 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, 23 Oct 2020 15:09:26 -0000 --Apple-Mail=_725E9FD3-8BE5-41D2-BE8C-A786DF0764D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, I don=E2=80=99t know where the MUST for that came from. It=E2=80=99s= never been a MUST. The sad thing is how much of this doc rolls in the continued (IMO) = assault on TCP as needing =E2=80=9Csecurity=E2=80=9D protections somehow = integrated into its basic mechanisms. It continues a trend of mistaking = errors for attacks and mistaking unsecured TCP for a secure service. Joe > On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari = wrote: >=20 >=20 > +1 >=20 > Especially the last ISN clock MUST statement is something that I also = consider quite restrictive for low end devices. If we cannot change it = for bis, some minimum viable solution described in detail/referenced = would be nice. >=20 > -- > Juhamatti >=20 >=20 > pe 23. lokakuuta 2020 klo 1.49 Joseph Touch > kirjoitti: > Hi, all, >=20 > Comments below, if still useful. >=20 > Joe >=20 > =E2=80=94=E2=80=94 >=20 > Regarding RFC5961, we were very careful in the applicability statement = therein to limit the SHOULD recommendations with specific conditions and = MAY implement elsewhere. This update to 793 misrepresents those current = recommendations as SHOULD for everyone, e.g., here: >=20 > A potential blind reset attack is described in RFC 5961 > [32], with the mitigation that a TCP implementation > SHOULD first check that the sequence number exactly > matches RCV.NXT prior to executing the action in the = next > paragraph. >=20 > That text should instead say =E2=80=9CMAY first check=E2=80=9D, = adding, if desired, "(SHOULD, under the conditions noted in RFC = 5961)=E2=80=9D. That corrected text belongs also in section 3.4 where = reset processing is discussed. >=20 > =E2=80=94 >=20 > All places that mention issuing a RST (including sec 3.4 and the state = machine) should note that the side issuing the RST ought to enter = TIME_WAIT - and explain why, as noted in: > Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and Its = Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999.=20 >=20 > =E2=80=94 >=20 > The following text should include a MUST, as shown below: >=20 > (all TCP options except End of option list and No-Operation > MUST have length fields) >=20 > =E2=80=94 >=20 > The following text should be preceded by an inline =E2=80=98heading=E2=80= =99 as shown: >=20 > Experimental TCP options >=20 > Experimental TCP option values are defined in [22], and [39] > describes the current recommended usage for these experimental > values. >=20 > =E2=80=94 >=20 > The following text should be moved earlier in the section, because its = current location suggests it is related to the experimental options = discussion (and it is not): >=20 > Note: There is ongoing work to extend the space available for > TCP options, such as [53]. >=20 > It might be appropriate to move this before the discussion of specific = options, for example. >=20 > =E2=80=94 >=20 > The definition of TIME-WAIT should describe its purpose as also = including avoiding delayed segments from previous connections affecting = new connections. >=20 > =E2=80=94 >=20 > I would strongly encourage reformatting to allow the TCP state machine = to avoid page break boundaries. >=20 > It may also be useful to add a note that RST can be issued from any = state with a corresponding (implied) transition to TIME-WAIT; similarly, = receipt of RST from any state goes to LISTEN. These transitions are not = shown only because they would complicate the diagram. >=20 > =E2=80=94 >=20 > The following statement is false: >=20 > The protocol places no restriction on a particular connection being > used over and over again. >=20 > Avoiding that happening too quickly in succession is one of the = purposes of TIME-WAIT. New ISNs are only PART of that protection (which = means the rest of this section needs revision to clarify this issue). >=20 > =E2=80=94 >=20 > The security of TCP is discussed incorrectly, IMO. The ISN discussion = and RST discussion, in particular, although trying to help protect = against off-path attacks, are only very tenuously considered = =E2=80=9Csecurity=E2=80=9D. There should be some other way of discussing = this and making sure that if TCP users need secure connections they need = to use TCP-AO or IPsec. >=20 > =E2=80=94 >=20 > The ISN clock statement with MUST seems to overreach. The previous = text talks about the use of clocks being recommended, but a MUST is much = stronger. The assertion needs more wiggle words or a more generous = definition of clock to avoid being used out of context to prevent simple = implementations on lightweight devices. >=20 > =E2=80=94 > end. >=20 >=20 >=20 >=20 >=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=_725E9FD3-8BE5-41D2-BE8C-A786DF0764D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW,= I don=E2=80=99t know where the MUST for that came from. It=E2=80=99s = never been a MUST.

The= sad thing is how much of this doc rolls in the continued (IMO) assault = on TCP as needing =E2=80=9Csecurity=E2=80=9D protections somehow = integrated into its basic mechanisms. It continues a trend of mistaking = errors for attacks and mistaking unsecured TCP for a secure service.

Joe

On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari <juhamatk@gmail.com> = wrote:


+1

Especially the last ISN clock MUST statement is something = that I also consider quite restrictive for low end devices. If we cannot = change it for bis, some minimum viable solution described in = detail/referenced would be nice.

--
  = Juhamatti


pe 23. = lokakuuta 2020 klo 1.49 Joseph Touch <touch@strayalpha.com> kirjoitti:
Hi, all,

Comments below, if still useful.

Joe

=E2=80=94=E2=80=94

Regarding RFC5961, we were very careful in the applicability statement = therein to limit the SHOULD recommendations with specific conditions and = MAY implement elsewhere. This update to 793 misrepresents those current = recommendations as SHOULD for everyone, e.g., here:

               A potential blind = reset attack is described in RFC 5961
               [32], with the = mitigation that a TCP implementation
               SHOULD first = check that the sequence number exactly
               matches RCV.NXT = prior to executing the action in the next
               paragraph.

That text should instead say =E2=80=9CMAY first check=E2=80=9D, adding, = if desired, "(SHOULD, under the conditions noted in RFC 5961)=E2=80=9D. = That corrected text belongs also in section 3.4 where reset processing = is discussed.

=E2=80=94

All places that mention issuing a RST (including sec 3.4 and the state = machine) should note that the side issuing the RST ought to enter = TIME_WAIT - and explain why, as noted in:
        Faber, T; Touch, J; Yue, W: The TIME-WAIT = state in TCP and Its Effect on Busy Servers. In: Infocom, pp. 1573-1583, = IEEE, 1999.

=E2=80=94

The following text should include a MUST, as shown below:

    (all TCP options except End of option list and = No-Operation
     MUST have length fields)

=E2=80=94

The following text should be preceded by an inline =E2=80=98heading=E2=80=99= as shown:

        Experimental TCP options

        Experimental TCP option values are defined = in [22], and [39]
        describes the current recommended usage for = these experimental
        values.

=E2=80=94

The following text should be moved earlier in the section, because its = current location suggests it is related to the experimental options = discussion (and it is not):

        Note: There is ongoing work to extend the = space available for
        TCP options, such as [53].

It might be appropriate to move this before the discussion of specific = options, for example.

=E2=80=94

The definition of TIME-WAIT should describe its purpose as also = including avoiding delayed segments from previous connections affecting = new connections.

=E2=80=94

I would strongly encourage reformatting to allow the TCP state machine = to avoid page break boundaries.

It may also be useful to add a note that RST can be issued from any = state with a corresponding (implied) transition to TIME-WAIT; similarly, = receipt of RST from any state goes to LISTEN. These transitions are not = shown only because they would complicate the diagram.

=E2=80=94

The following statement is false:

  The protocol places no restriction on a particular connection = being
   used over and over again.

Avoiding that happening too quickly in succession is one of the purposes = of TIME-WAIT. New ISNs are only PART of that protection (which means the = rest of this section needs revision to clarify this issue).
=
=E2=80=94

The security of TCP is discussed incorrectly, IMO. The ISN discussion = and RST discussion, in particular, although trying to help protect = against off-path attacks, are only very tenuously considered = =E2=80=9Csecurity=E2=80=9D. There should be some other way of discussing = this and making sure that if TCP users need secure connections they need = to use TCP-AO or IPsec.

=E2=80=94

The ISN clock statement with MUST seems to overreach. The previous text = talks about the use of clocks being recommended, but a MUST is much = stronger. The assertion needs more wiggle words or a more generous = definition of clock to avoid being used out of context to prevent simple = implementations on lightweight devices.

=E2=80=94
end.





_______________________________________________
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=_725E9FD3-8BE5-41D2-BE8C-A786DF0764D5-- From nobody Fri Oct 23 08:11:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88E23A0ED7 for ; Fri, 23 Oct 2020 08:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ANipbOwFkK2 for ; Fri, 23 Oct 2020 08:11:34 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2ACB3A0ECA for ; Fri, 23 Oct 2020 08:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tE2x6RCi/U2EMCIsdUc3YFxqkzgvTECbQjtvl75Rzxw=; b=Sbyca3YIu61+9wsUp5l2pena5 U63wHzRzL5Pm93L3kCEwMUcpHpvQlEIMeL7UrRRgCWrjsOrj1idKB7iF167g68FE5jqN9wtMQXkbi y12ZZouXntwToMNcB7lVIoP8oM8APC0HKcVUTqkU0jlyzJ/Hmkj+E3yrh+O5InQe+DEKRKkfxCs3Y w0v3aixXOwciDyZWBkT++0QZ7JvCvLabZSXnoT/dRb2bOv/MdbAAo+HoS1t//KvfycdDFxppQODOW /pBzNvdZ/B/QlnX71bldxnjwRC3NkDCd5CY1SRy/gSGoIifG10/NoKhuhqwLPLR2WKCX6BSiZyIXX +Yf3vzFSA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64964 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kVyj3-000Tlk-6w; Fri, 23 Oct 2020 11:11:33 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_338B02D8-4CB3-4AD4-90BC-3DEE4346D69B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Fri, 23 Oct 2020 08:11:28 -0700 Cc: Mirja Kuehlewind , "tcpm@ietf.org Extensions" Message-Id: <246C6457-BF65-4B66-970A-FD6C95A98772@strayalpha.com> References: <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk> To: Frode Kileng X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Exceeding value in MSS option? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 15:11:36 -0000 --Apple-Mail=_338B02D8-4CB3-4AD4-90BC-3DEE4346D69B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 23, 2020, at 1:37 AM, Frode Kileng wrote: >=20 > Although maybe not a "general problem", a study of MSS middlebox = manipluation in 23 European and Asian mobile networks did reveal some = issues: >=20 > - 20 of 23 networks always inserts MSS. That IS a general problem, FWIW.=20 Besides being published, it should also be reported to the operators of = those networks as violating TCP specs. Joe= --Apple-Mail=_338B02D8-4CB3-4AD4-90BC-3DEE4346D69B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 23, 2020, at 1:37 AM, Frode Kileng <frodek@tele.no> = wrote:

Although maybe not  a = "general problem",  a study of MSS middlebox manipluation in  = 23 European and Asian mobile networks did reveal some issues:

- 20 of 23 networks always = inserts MSS.

That IS a general problem, FWIW. 
Besides being published, it should = also be reported to the operators of those networks as violating TCP = specs.

Joe
= --Apple-Mail=_338B02D8-4CB3-4AD4-90BC-3DEE4346D69B-- From nobody Fri Oct 23 08:23:15 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822933A0EF0 for ; Fri, 23 Oct 2020 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, 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=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 aCpfr9EK3QvW for ; Fri, 23 Oct 2020 08:23:11 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 C11423A0EEF for ; Fri, 23 Oct 2020 08:23:10 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id t20so850495qvv.8 for ; Fri, 23 Oct 2020 08:23:10 -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-language; bh=blv7wMz4to6yVa9biY72b+KdezZSBWdG6Dm+bTFUlA4=; b=qeivBuora+29ne1bSIYbFsJdJKFq0Gw4gRxCu+GNCU6WXNxmWAN+C21UE/0ldv/9X7 GAl8c9sad9DfPjZPDTrydm2TOomWPHmuZw0vUKxIyJGni/YYvEVbdAmXV4xRGjUWXlPJ eXdXsaRRJugPkQYoAdaDwdbwehFoPv+5SztqjTH58PFA8Epd5OOx5KH1EhoZhRZ8uQJ8 gsDWCYAUz1EMaCTwtokuTYoag/g2P86NydKsIW5fPOcFzWAfUhDJE9Dg4JVG2oqPOLJr gZ7Cr0AxMMRX/nWN5Vqf5viswCaCT4K6j9+pUHKtD+BJTF6EgnKkUWs2sE6gPCzqKjjp sNMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=blv7wMz4to6yVa9biY72b+KdezZSBWdG6Dm+bTFUlA4=; b=LT10iY2LmTaiHl7Jrd4tXx/5NAhYhjE6XrWE8epH6tFUBP0eMw+Y7T2qOq09o/Ii3u Bt7NI3Qv4p1KlwcVsC+DfIaDH8yMk59koE2GeJeP/5ae1XfwWWfbl9KWTvEuTD/xoZ6d 58JpqGuA05pyCEnpcMPAdwnSeYWPFJvApgDx7+WoTZupFjnHwBQpAvrOpnntFPxggl0R h9JwCPYEhXc7u/Z7rN4YBtrnyK8txW6FXis6I0ilYIBaOvYLhVqVKobtSQl912V71HIr tPtnLUSju83uvXxmq59SIXUcZecaaJBt/O86mFb36RCGx4mv/nbPw0ur6udFNW4m9pzA IomQ== X-Gm-Message-State: AOAM532eKoJ6yTNVPGbdk9/cmB76D5aOPwrztPVaYzAcaMNYzX7XcrGg fTEWU7uBZHq9sej09xSItKK3eRSeLWmoaaup X-Google-Smtp-Source: ABdhPJzbzYC64ojdqen6sqde46ao73DnRdXbMljmQtUMNHc7nKk0WI0yJqnWrVyX9Y/hRbOjACWj4g== X-Received: by 2002:ad4:46a8:: with SMTP id br8mr2893627qvb.24.1603466589223; Fri, 23 Oct 2020 08:23:09 -0700 (PDT) Received: from [192.168.1.114] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id o193sm952953qke.12.2020.10.23.08.23.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 08:23:08 -0700 (PDT) To: tcpm@ietf.org References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> From: Wesley Eddy Message-ID: Date: Fri, 23 Oct 2020 11:23:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------51C911F8D8C720CA40A040A5" Content-Language: en-US Archived-At: Subject: Re: [tcpm] A few comments on 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, 23 Oct 2020 15:23:14 -0000 This is a multi-part message in MIME format. --------------51C911F8D8C720CA40A040A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We are trying not to make up anything new for this document that wasn't already from prior RFCs, so if that has been done wrong, then we should fix it! In this case, I think the MUST comes from RFC1122 (4.2.2.9): A TCP MUST use the specified clock-driven selection of initial sequence numbers. And the text on this in 793bis is a merger of this and RFC 6528, as it says: This recommended algorithm is further described inRFC 6528 [36 ] and builds on the basic clock-driven algorithm fromRFC 793 . A TCP implementation MUST use a clock-driven selection of initial sequence numbers (MUST-8), and SHOULD generate its Initial Sequence Numbers with the expression: ... So, I could use help in understanding what to do here, without going against what has already been put down in 1122 and not relaxed since. On 10/23/2020 11:09 AM, Joseph Touch wrote: > FWIW, I don’t know where the MUST for that came from. It’s never been > a MUST. > > The sad thing is how much of this doc rolls in the continued (IMO) > assault on TCP as needing “security” protections somehow integrated > into its basic mechanisms. It continues a trend of mistaking errors > for attacks and mistaking unsecured TCP for a secure service. > > Joe > >> On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari >> > wrote: >> >> >> +1 >> >> Especially the last ISN clock MUST statement is something that I also >> consider quite restrictive for low end devices. If we cannot change >> it for bis, some minimum viable solution described in >> detail/referenced would be nice. >> >> -- >>   Juhamatti >> >> >> pe 23. lokakuuta 2020 klo 1.49 Joseph Touch > > kirjoitti: >> >> Hi, all, >> >> Comments below, if still useful. >> >> Joe >> >> —— >> >> Regarding RFC5961, we were very careful in the applicability >> statement therein to limit the SHOULD recommendations with >> specific conditions and MAY implement elsewhere. This update to >> 793 misrepresents those current recommendations as SHOULD for >> everyone, e.g., here: >> >>                A potential blind reset attack is described in RFC >> 5961 >>                [32], with the mitigation that a TCP implementation >>                SHOULD first check that the sequence number exactly >>                matches RCV.NXT prior to executing the action in >> the next >>                paragraph. >> >> That text should instead say “MAY first check”, adding, if >> desired, "(SHOULD, under the conditions noted in RFC 5961)”. That >> corrected text belongs also in section 3.4 where reset processing >> is discussed. >> >> — >> >> All places that mention issuing a RST (including sec 3.4 and the >> state machine) should note that the side issuing the RST ought to >> enter TIME_WAIT - and explain why, as noted in: >>         Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP >> and Its Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, >> 1999. >> >> — >> >> The following text should include a MUST, as shown below: >> >>     (all TCP options except End of option list and No-Operation >>      MUST have length fields) >> >> — >> >> The following text should be preceded by an inline ‘heading’ as >> shown: >> >>         Experimental TCP options >> >>         Experimental TCP option values are defined in [22], and [39] >>         describes the current recommended usage for these >> experimental >>         values. >> >> — >> >> The following text should be moved earlier in the section, >> because its current location suggests it is related to the >> experimental options discussion (and it is not): >> >>         Note: There is ongoing work to extend the space available for >>         TCP options, such as [53]. >> >> It might be appropriate to move this before the discussion of >> specific options, for example. >> >> — >> >> The definition of TIME-WAIT should describe its purpose as also >> including avoiding delayed segments from previous connections >> affecting new connections. >> >> — >> >> I would strongly encourage reformatting to allow the TCP state >> machine to avoid page break boundaries. >> >> It may also be useful to add a note that RST can be issued from >> any state with a corresponding (implied) transition to TIME-WAIT; >> similarly, receipt of RST from any state goes to LISTEN. These >> transitions are not shown only because they would complicate the >> diagram. >> >> — >> >> The following statement is false: >> >>   The protocol places no restriction on a particular connection being >>    used over and over again. >> >> Avoiding that happening too quickly in succession is one of the >> purposes of TIME-WAIT. New ISNs are only PART of that protection >> (which means the rest of this section needs revision to clarify >> this issue). >> >> — >> >> The security of TCP is discussed incorrectly, IMO. The ISN >> discussion and RST discussion, in particular, although trying to >> help protect against off-path attacks, are only very tenuously >> considered “security”. There should be some other way of >> discussing this and making sure that if TCP users need secure >> connections they need to use TCP-AO or IPsec. >> >> — >> >> The ISN clock statement with MUST seems to overreach. The >> previous text talks about the use of clocks being recommended, >> but a MUST is much stronger. The assertion needs more wiggle >> words or a more generous definition of clock to avoid being used >> out of context to prevent simple implementations on lightweight >> devices. >> >> — >> end. >> >> >> >> >> >> _______________________________________________ >> 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 --------------51C911F8D8C720CA40A040A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eT4NCiAgICA8cD5XZSBhcmUgdHJ5aW5nIG5vdCB0byBtYWtlIHVwIGFueXRoaW5nIG5ldyBm b3IgdGhpcyBkb2N1bWVudCB0aGF0DQogICAgICB3YXNuJ3QgYWxyZWFkeSBmcm9tIHByaW9y IFJGQ3MsIHNvIGlmIHRoYXQgaGFzIGJlZW4gZG9uZSB3cm9uZywNCiAgICAgIHRoZW4gd2Ug c2hvdWxkIGZpeCBpdCE8L3A+DQogICAgPHA+SW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoZSBN VVNUIGNvbWVzIGZyb20gUkZDMTEyMiAoNC4yLjIuOSk6PC9wPg0KICAgIDxwcmUgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdp ZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24t Y29sb3I6IGluaXRpYWw7IG92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiPiAgICAgICAgICAgIEEgVENQIE1VU1QgdXNlIHRoZSBzcGVjaWZpZWQg Y2xvY2stZHJpdmVuIHNlbGVjdGlvbiBvZg0KICAgICAgICAgICAgaW5pdGlhbCBzZXF1ZW5j ZSBudW1iZXJzLg0KDQo8L3ByZT4NCiAgICA8cD5BbmQgdGhlIHRleHQgb24gdGhpcyBpbiA3 OTNiaXMgaXMgYSBtZXJnZXIgb2YgdGhpcyBhbmQgUkZDIDY1MjgsDQogICAgICBhcyBpdCBz YXlzOjxicj4NCiAgICA8L3A+DQogICAgPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImJv eC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93OiBhdXRvOyBmb250LWZhbWlseTogJnF1 b3Q7UFQgTW9ubyZxdW90OywgTW9uYWNvLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTAuNXB0 OyBkaXNwbGF5OiBibG9jazsgcGFkZGluZzogMHB4IDBweCAxZW07IG1hcmdpbjogMHB4OyBs aW5lLWhlaWdodDogMS4xMjsgY29sb3I6IHJnYigwLCAwLCAwKTsgd29yZC1icmVhazogYnJl YWstYWxsOyBvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOyBiYWNrZ3JvdW5kLWNvbG9yOiB3 aGl0ZTsgYm9yZGVyOiAwcHg7IGJvcmRlci1yYWRpdXM6IDRweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7 IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPiAgIFRoaXMgcmVjb21tZW5kZWQg YWxnb3JpdGhtIGlzIGZ1cnRoZXIgZGVzY3JpYmVkIGluIDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNjUyOCIgc3R5bGU9ImJveC1zaXppbmc6 IGJvcmRlci1ib3g7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogcmdi KDYxLCAzNCwgMTc5KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5SRkMgNjUyODwv YT4gWzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xOCNyZWYtMzYiIHRpdGxlPSIiIGRhdGEtb3JpZ2lu YWwtdGl0bGU9IiZxdW90O0RlZmVuZGluZyBhZ2FpbnN0IFNlcXVlbmNlIE51bWJlciBBdHRh Y2tzJnF1b3Q7IiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgYmFja2dyb3VuZC1j b2xvcjogdHJhbnNwYXJlbnQ7IGNvbG9yOiByZ2IoNjEsIDM0LCAxNzkpOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiPjM2PC9hPl0gYW5kDQogICBidWlsZHMgb24gdGhlIGJhc2lj IGNsb2NrLWRyaXZlbiBhbGdvcml0aG0gZnJvbSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzc5MyIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRl ci1ib3g7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogcmdiKDYxLCAz NCwgMTc5KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5SRkMgNzkzPC9hPi4NCg0K ICAgQSBUQ1AgaW1wbGVtZW50YXRpb24gTVVTVCB1c2UgYSBjbG9jay1kcml2ZW4gc2VsZWN0 aW9uIG9mIGluaXRpYWwNCiAgIHNlcXVlbmNlIG51bWJlcnMgKE1VU1QtOCksIGFuZCBTSE9V TEQgZ2VuZXJhdGUgaXRzIEluaXRpYWwgU2VxdWVuY2UNCiAgIE51bWJlcnMgd2l0aCB0aGUg ZXhwcmVzc2lvbjoNCiAgIC4uLg0KPC9wcmU+DQogICAgPHA+U28sIEkgY291bGQgdXNlIGhl bHAgaW4gdW5kZXJzdGFuZGluZyB3aGF0IHRvIGRvIGhlcmUsIHdpdGhvdXQNCiAgICAgIGdv aW5nIGFnYWluc3Qgd2hhdCBoYXMgYWxyZWFkeSBiZWVuIHB1dCBkb3duIGluIDExMjIgYW5k IG5vdA0KICAgICAgcmVsYXhlZCBzaW5jZS48YnI+DQogICAgPC9wPg0KICAgIDxwcmUgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRp b24tY29sb3I6IGluaXRpYWw7IG92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsiPg0KDQo8L3ByZT4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w cmVmaXgiPk9uIDEwLzIzLzIwMjAgMTE6MDkgQU0sIEpvc2VwaCBUb3VjaA0KICAgICAgd3Jv dGU6PGJyPg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAg ICBjaXRlPSJtaWQ6RUVBNUY2NDktRkIzMS00MDQ5LTgwN0EtRTVENkY1REVENjI5QHN0cmF5 YWxwaGEuY29tIj4NCiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgICAgIEZXSVcsIEkgZG9u4oCZ dCBrbm93IHdoZXJlIHRoZSBNVVNUIGZvciB0aGF0IGNhbWUgZnJvbS4gSXTigJlzIG5ldmVy DQogICAgICBiZWVuIGEgTVVTVC4NCiAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2IGNsYXNzPSIiPlRoZSBzYWQgdGhpbmcgaXMg aG93IG11Y2ggb2YgdGhpcyBkb2Mgcm9sbHMgaW4gdGhlDQogICAgICAgIGNvbnRpbnVlZCAo SU1PKSBhc3NhdWx0IG9uIFRDUCBhcyBuZWVkaW5nIOKAnHNlY3VyaXR54oCdIHByb3RlY3Rp b25zDQogICAgICAgIHNvbWVob3cgaW50ZWdyYXRlZCBpbnRvIGl0cyBiYXNpYyBtZWNoYW5p c21zLiBJdCBjb250aW51ZXMgYQ0KICAgICAgICB0cmVuZCBvZiBtaXN0YWtpbmcgZXJyb3Jz IGZvciBhdHRhY2tzIGFuZCBtaXN0YWtpbmcgdW5zZWN1cmVkDQogICAgICAgIFRDUCBmb3Ig YSBzZWN1cmUgc2VydmljZS48YnIgY2xhc3M9IiI+DQogICAgICAgIDxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdiBjbGFzcz0iIj5K b2U8YnIgY2xhc3M9IiI+DQogICAgICAgICAgPGRpdj48YnIgY2xhc3M9IiI+DQogICAgICAg ICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAg PGRpdiBjbGFzcz0iIj5PbiBPY3QgMjIsIDIwMjAsIGF0IDEwOjIwIFBNLCBKdWhhbWF0dGkN CiAgICAgICAgICAgICAgICBLdXVzaXNhYXJpICZsdDs8YSBocmVmPSJtYWlsdG86anVoYW1h dGtAZ21haWwuY29tIg0KICAgICAgICAgICAgICAgICAgY2xhc3M9IiIgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj5qdWhhbWF0a0BnbWFpbC5jb208L2E+Jmd0Ow0KICAgICAgICAgICAgICAg IHdyb3RlOjwvZGl2Pg0KICAgICAgICAgICAgICA8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPg0KICAgICAgICAg ICAgICAgIDxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgIDxk aXYgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJhdXRvIiBzdHls ZT0iZm9udC1mYW1pbHk6c2Fucy1zZXJpZiINCiAgICAgICAgICAgICAgICAgICAgICBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICAgICAgICA8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImZvbnQtZmFtaWx5OnNhbnMt c2VyaWYiDQogICAgICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+KzE8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgICAgPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJmb250LWZhbWlseTpzYW5z LXNlcmlmIg0KICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXYg ZGlyPSJhdXRvIiBzdHlsZT0iZm9udC1mYW1pbHk6c2Fucy1zZXJpZiINCiAgICAgICAgICAg ICAgICAgICAgICBjbGFzcz0iIj5Fc3BlY2lhbGx5IHRoZSBsYXN0IElTTiBjbG9jayBNVVNU DQogICAgICAgICAgICAgICAgICAgICAgc3RhdGVtZW50IGlzIHNvbWV0aGluZyB0aGF0IEkg YWxzbyBjb25zaWRlciBxdWl0ZQ0KICAgICAgICAgICAgICAgICAgICAgIHJlc3RyaWN0aXZl IGZvciBsb3cgZW5kIGRldmljZXMuIElmIHdlIGNhbm5vdA0KICAgICAgICAgICAgICAgICAg ICAgIGNoYW5nZSBpdCBmb3IgYmlzLCBzb21lIG1pbmltdW0gdmlhYmxlIHNvbHV0aW9uDQog ICAgICAgICAgICAgICAgICAgICAgZGVzY3JpYmVkIGluIGRldGFpbC9yZWZlcmVuY2VkIHdv dWxkIGJlIG5pY2UuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJhdXRv IiBzdHlsZT0iZm9udC1mYW1pbHk6c2Fucy1zZXJpZiINCiAgICAgICAgICAgICAgICAgICAg ICBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K ICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImZvbnQtZmFtaWx5 OnNhbnMtc2VyaWYiDQogICAgICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+LS08L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJmb250LWZhbWls eTpzYW5zLXNlcmlmIg0KICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSIiPsKgIEp1aGFt YXR0aTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAg ICAgICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJs dHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5wZSAyMy4gbG9rYWt1dXRhDQogICAgICAgICAgICAg ICAgICAgICAgICAyMDIwIGtsbyAxLjQ5IEpvc2VwaCBUb3VjaCAmbHQ7PGENCiAgICAgICAg ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tIiBj bGFzcz0iIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRy dWUiPnRvdWNoQHN0cmF5YWxwaGEuY29tPC9hPiZndDsNCiAgICAgICAgICAgICAgICAgICAg ICAgIGtpcmpvaXR0aTo8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjDQogICAgICAgICAgICAgICAgICAgICAgICBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij5IaSwgYWxsLDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAg ICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIENvbW1l bnRzIGJlbG93LCBpZiBzdGlsbCB1c2VmdWwuPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAg ICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgSm9l PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAg4oCU4oCUPGJyIGNsYXNzPSIiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAg UmVnYXJkaW5nIFJGQzU5NjEsIHdlIHdlcmUgdmVyeSBjYXJlZnVsIGluIHRoZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgdGhlcmVpbiB0byBs aW1pdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgIFNIT1VMRCByZWNvbW1lbmRhdGlv bnMgd2l0aCBzcGVjaWZpYyBjb25kaXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBh bmQgTUFZIGltcGxlbWVudCBlbHNld2hlcmUuIFRoaXMgdXBkYXRlIHRvIDc5Mw0KICAgICAg ICAgICAgICAgICAgICAgICAgbWlzcmVwcmVzZW50cyB0aG9zZSBjdXJyZW50IHJlY29tbWVu ZGF0aW9ucyBhcw0KICAgICAgICAgICAgICAgICAgICAgICAgU0hPVUxEIGZvciBldmVyeW9u ZSwgZS5nLiwgaGVyZTo8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8 YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoEEgcG90ZW50aWFsIGJsaW5kIHJlc2V0IGF0dGFjayBpcw0KICAgICAgICAgICAg ICAgICAgICAgICAgZGVzY3JpYmVkIGluIFJGQyA1OTYxPGJyIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBbMzJdLCB3aXRoIHRo ZSBtaXRpZ2F0aW9uIHRoYXQgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgVENQIGltcGxl bWVudGF0aW9uPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBTSE9VTEQgZmlyc3QgY2hlY2sgdGhhdCB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgIHNlcXVlbmNlIG51bWJlciBleGFjdGx5PGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtYXRjaGVz IFJDVi5OWFQgcHJpb3IgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgIGV4ZWN1dGluZyB0 aGUgYWN0aW9uIGluIHRoZSBuZXh0PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwYXJhZ3JhcGguPGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgVGhhdCB0ZXh0IHNob3VsZCBpbnN0ZWFkIHNheSDigJxNQVkgZmlyc3QgY2hl Y2vigJ0sDQogICAgICAgICAgICAgICAgICAgICAgICBhZGRpbmcsIGlmIGRlc2lyZWQsICIo U0hPVUxELCB1bmRlciB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbmRpdGlvbnMg bm90ZWQgaW4gUkZDIDU5NjEp4oCdLiBUaGF0IGNvcnJlY3RlZA0KICAgICAgICAgICAgICAg ICAgICAgICAgdGV4dCBiZWxvbmdzIGFsc28gaW4gc2VjdGlvbiAzLjQgd2hlcmUgcmVzZXQN CiAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NpbmcgaXMgZGlzY3Vzc2VkLjxiciBj bGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAg ICAgICAgICAgICAgICAgICAgIOKAlDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAg ICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIEFsbCBwbGFj ZXMgdGhhdCBtZW50aW9uIGlzc3VpbmcgYSBSU1QgKGluY2x1ZGluZw0KICAgICAgICAgICAg ICAgICAgICAgICAgc2VjIDMuNCBhbmQgdGhlIHN0YXRlIG1hY2hpbmUpIHNob3VsZCBub3Rl IHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBzaWRlIGlzc3VpbmcgdGhlIFJT VCBvdWdodCB0byBlbnRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgVElNRV9XQUlUIC0g YW5kIGV4cGxhaW4gd2h5LCBhcyBub3RlZCBpbjo8YnINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoCBG YWJlciwgVDsgVG91Y2gsIEo7IFl1ZSwgVzogVGhlDQogICAgICAgICAgICAgICAgICAgICAg ICBUSU1FLVdBSVQgc3RhdGUgaW4gVENQIGFuZCBJdHMgRWZmZWN0IG9uIEJ1c3kNCiAgICAg ICAgICAgICAgICAgICAgICAgIFNlcnZlcnMuIEluOiBJbmZvY29tLCBwcC4gMTU3My0xNTgz LCBJRUVFLCAxOTk5Lg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAg ICAgICAgICAg4oCUPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJy IGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGZvbGxvd2luZyB0ZXh0 IHNob3VsZCBpbmNsdWRlIGEgTVVTVCwgYXMNCiAgICAgICAgICAgICAgICAgICAgICAgIHNo b3duIGJlbG93OjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiciBj bGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKgIChhbGwgVENQIG9wdGlv bnMgZXhjZXB0IEVuZCBvZiBvcHRpb24gbGlzdA0KICAgICAgICAgICAgICAgICAgICAgICAg YW5kIE5vLU9wZXJhdGlvbjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAg IMKgIMKgIMKgTVVTVCBoYXZlIGxlbmd0aCBmaWVsZHMpPGJyIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAg ICAg4oCUPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNz PSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGZvbGxvd2luZyB0ZXh0IHNob3Vs ZCBiZSBwcmVjZWRlZCBieSBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgaW5saW5lIOKA mGhlYWRpbmfigJkgYXMgc2hvd246PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAg wqAgRXhwZXJpbWVudGFsIFRDUCBvcHRpb25zPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAg ICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgwqAg wqAgwqAgwqAgRXhwZXJpbWVudGFsIFRDUCBvcHRpb24gdmFsdWVzIGFyZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgZGVmaW5lZCBpbiBbMjJdLCBhbmQgWzM5XTxiciBjbGFzcz0iIj4N CiAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKgIMKgIMKgIGRlc2NyaWJlcyB0aGUgY3Vy cmVudCByZWNvbW1lbmRlZCB1c2FnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgZm9yIHRo ZXNlIGV4cGVyaW1lbnRhbDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAg IMKgIMKgIMKgIMKgIHZhbHVlcy48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAg ICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICDigJQ8YnIgY2xh c3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAg ICAgICAgICAgICAgICAgICBUaGUgZm9sbG93aW5nIHRleHQgc2hvdWxkIGJlIG1vdmVkIGVh cmxpZXIgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBzZWN0aW9uLCBiZWNhdXNl IGl0cyBjdXJyZW50IGxvY2F0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICBzdWdnZXN0 cyBpdCBpcyByZWxhdGVkIHRvIHRoZSBleHBlcmltZW50YWwNCiAgICAgICAgICAgICAgICAg ICAgICAgIG9wdGlvbnMgZGlzY3Vzc2lvbiAoYW5kIGl0IGlzIG5vdCk6PGJyIGNsYXNzPSIi Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAg ICAgICAgICAgICAgwqAgwqAgwqAgwqAgTm90ZTogVGhlcmUgaXMgb25nb2luZyB3b3JrIHRv IGV4dGVuZA0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHNwYWNlIGF2YWlsYWJsZSBm b3I8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoCBU Q1Agb3B0aW9ucywgc3VjaCBhcyBbNTNdLjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAg ICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIEl0IG1p Z2h0IGJlIGFwcHJvcHJpYXRlIHRvIG1vdmUgdGhpcyBiZWZvcmUgdGhlDQogICAgICAgICAg ICAgICAgICAgICAgICBkaXNjdXNzaW9uIG9mIHNwZWNpZmljIG9wdGlvbnMsIGZvciBleGFt cGxlLjxicg0KICAgICAgICAgICAgICAgICAgICAgICAgICBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAg IOKAlDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0i Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBkZWZpbml0aW9uIG9mIFRJTUUtV0FJ VCBzaG91bGQgZGVzY3JpYmUgaXRzDQogICAgICAgICAgICAgICAgICAgICAgICBwdXJwb3Nl IGFzIGFsc28gaW5jbHVkaW5nIGF2b2lkaW5nIGRlbGF5ZWQNCiAgICAgICAgICAgICAgICAg ICAgICAgIHNlZ21lbnRzIGZyb20gcHJldmlvdXMgY29ubmVjdGlvbnMgYWZmZWN0aW5nIG5l dw0KICAgICAgICAgICAgICAgICAgICAgICAgY29ubmVjdGlvbnMuPGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAg ICAgICAgICAg4oCUPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJy IGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgSSB3b3VsZCBzdHJvbmdseSBl bmNvdXJhZ2UgcmVmb3JtYXR0aW5nIHRvIGFsbG93DQogICAgICAgICAgICAgICAgICAgICAg ICB0aGUgVENQIHN0YXRlIG1hY2hpbmUgdG8gYXZvaWQgcGFnZSBicmVhaw0KICAgICAgICAg ICAgICAgICAgICAgICAgYm91bmRhcmllcy48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAg ICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICBJdCBt YXkgYWxzbyBiZSB1c2VmdWwgdG8gYWRkIGEgbm90ZSB0aGF0IFJTVCBjYW4NCiAgICAgICAg ICAgICAgICAgICAgICAgIGJlIGlzc3VlZCBmcm9tIGFueSBzdGF0ZSB3aXRoIGEgY29ycmVz cG9uZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgKGltcGxpZWQpIHRyYW5zaXRpb24g dG8gVElNRS1XQUlUOyBzaW1pbGFybHksDQogICAgICAgICAgICAgICAgICAgICAgICByZWNl aXB0IG9mIFJTVCBmcm9tIGFueSBzdGF0ZSBnb2VzIHRvIExJU1RFTi4NCiAgICAgICAgICAg ICAgICAgICAgICAgIFRoZXNlIHRyYW5zaXRpb25zIGFyZSBub3Qgc2hvd24gb25seSBiZWNh dXNlDQogICAgICAgICAgICAgICAgICAgICAgICB0aGV5IHdvdWxkIGNvbXBsaWNhdGUgdGhl IGRpYWdyYW0uPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNs YXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAg4oCUPGJyIGNsYXNzPSIiPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgVGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaXMgZmFsc2U6PGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgwqAgVGhlIHByb3RvY29sIHBsYWNlcyBubyByZXN0cmljdGlvbiBvbiBhDQog ICAgICAgICAgICAgICAgICAgICAgICBwYXJ0aWN1bGFyIGNvbm5lY3Rpb24gYmVpbmc8YnIg Y2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICDCoCDCoHVzZWQgb3ZlciBhbmQg b3ZlciBhZ2Fpbi48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnIg Y2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICBBdm9pZGluZyB0aGF0IGhhcHBl bmluZyB0b28gcXVpY2tseSBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3VjY2Vzc2lv biBpcyBvbmUgb2YgdGhlIHB1cnBvc2VzIG9mIFRJTUUtV0FJVC4NCiAgICAgICAgICAgICAg ICAgICAgICAgIE5ldyBJU05zIGFyZSBvbmx5IFBBUlQgb2YgdGhhdCBwcm90ZWN0aW9uICh3 aGljaA0KICAgICAgICAgICAgICAgICAgICAgICAgbWVhbnMgdGhlIHJlc3Qgb2YgdGhpcyBz ZWN0aW9uIG5lZWRzIHJldmlzaW9uIHRvDQogICAgICAgICAgICAgICAgICAgICAgICBjbGFy aWZ5IHRoaXMgaXNzdWUpLjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAg IDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIOKAlDxiciBjbGFzcz0i Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAg ICAgICAgICAgICAgIFRoZSBzZWN1cml0eSBvZiBUQ1AgaXMgZGlzY3Vzc2VkIGluY29ycmVj dGx5LA0KICAgICAgICAgICAgICAgICAgICAgICAgSU1PLiBUaGUgSVNOIGRpc2N1c3Npb24g YW5kIFJTVCBkaXNjdXNzaW9uLCBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgcGFydGlj dWxhciwgYWx0aG91Z2ggdHJ5aW5nIHRvIGhlbHAgcHJvdGVjdA0KICAgICAgICAgICAgICAg ICAgICAgICAgYWdhaW5zdCBvZmYtcGF0aCBhdHRhY2tzLCBhcmUgb25seSB2ZXJ5DQogICAg ICAgICAgICAgICAgICAgICAgICB0ZW51b3VzbHkgY29uc2lkZXJlZCDigJxzZWN1cml0eeKA nS4gVGhlcmUgc2hvdWxkIGJlDQogICAgICAgICAgICAgICAgICAgICAgICBzb21lIG90aGVy IHdheSBvZiBkaXNjdXNzaW5nIHRoaXMgYW5kIG1ha2luZw0KICAgICAgICAgICAgICAgICAg ICAgICAgc3VyZSB0aGF0IGlmIFRDUCB1c2VycyBuZWVkIHNlY3VyZSBjb25uZWN0aW9ucw0K ICAgICAgICAgICAgICAgICAgICAgICAgdGhleSBuZWVkIHRvIHVzZSBUQ1AtQU8gb3IgSVBz ZWMuPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIi Pg0KICAgICAgICAgICAgICAgICAgICAgICAg4oCUPGJyIGNsYXNzPSIiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAg VGhlIElTTiBjbG9jayBzdGF0ZW1lbnQgd2l0aCBNVVNUIHNlZW1zIHRvDQogICAgICAgICAg ICAgICAgICAgICAgICBvdmVycmVhY2guIFRoZSBwcmV2aW91cyB0ZXh0IHRhbGtzIGFib3V0 IHRoZSB1c2UNCiAgICAgICAgICAgICAgICAgICAgICAgIG9mIGNsb2NrcyBiZWluZyByZWNv bW1lbmRlZCwgYnV0IGEgTVVTVCBpcyBtdWNoDQogICAgICAgICAgICAgICAgICAgICAgICBz dHJvbmdlci4gVGhlIGFzc2VydGlvbiBuZWVkcyBtb3JlIHdpZ2dsZSB3b3Jkcw0KICAgICAg ICAgICAgICAgICAgICAgICAgb3IgYSBtb3JlIGdlbmVyb3VzIGRlZmluaXRpb24gb2YgY2xv Y2sgdG8gYXZvaWQNCiAgICAgICAgICAgICAgICAgICAgICAgIGJlaW5nIHVzZWQgb3V0IG9m IGNvbnRleHQgdG8gcHJldmVudCBzaW1wbGUNCiAgICAgICAgICAgICAgICAgICAgICAgIGlt cGxlbWVudGF0aW9ucyBvbiBsaWdodHdlaWdodCBkZXZpY2VzLjxicg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiciBj bGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIOKAlDxiciBjbGFzcz0iIj4NCiAg ICAgICAgICAgICAgICAgICAgICAgIGVuZC48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAg ICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnIg Y2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAg ICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAg ICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIHRjcG0g bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGEg aHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAg ICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIGNsYXNzPSIiDQogICAgICAgICAg ICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+dGNwbUBpZXRmLm9yZzwv YT48YnINCiAgICAgICAgICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+DQogICAgICAgICAg ICAgICAgICAgICAgICA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iDQogICAgICAgICAgICAg ICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L2E+ PGJyDQogICAgICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSIiPg0KICAgICAgICAgICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicg0KICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAg dGNwbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgPGEgaHJl Zj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIGNsYXNzPSIiDQogICAgICAgICAgICAgICAgICBt b3otZG8tbm90LXNlbmQ9InRydWUiPnRjcG1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxiciBjbGFzcz0iIj4NCiAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICA8L2Rpdj4NCiAg ICAgIDwvZGl2Pg0KICAgICAgPGJyPg0KICAgICAgPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0 YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4NCiAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90 ZS1wcmUiIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFi YnJldmlhdGVkIiBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwv YT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0K ICA8L2JvZHk+DQo8L2h0bWw+DQo= --------------51C911F8D8C720CA40A040A5-- From nobody Fri Oct 23 13:37:18 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4473A03C9 for ; Fri, 23 Oct 2020 13:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, 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 GLZ6Bual0wOW for ; Fri, 23 Oct 2020 13:37:15 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 D6AB43A03EC for ; Fri, 23 Oct 2020 13:37:14 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id cv1so1430591qvb.2 for ; Fri, 23 Oct 2020 13:37:14 -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-language; bh=b3N5/5tzMAWayce8EslWo34KiGpRW/myBjmKGXf3/9c=; b=ab6648mPbh3BVVbZuO46U2a9YO0xFITcTb1SwsZc4xSeTv3DBWKdP+Z6aNsbs/w3Ry AZMvLXto4XAtQrwBndRDwF4dPbiUkopSOpe2vs8I26tgp93RNEkR/GyMbNTSo+SrvyxJ pv9AtqFWsrRrP3KwxI9fDZSE0dRx4YloAJ11kz6aR/kCy1iohGNQBOtyNAB2ReCJLJU2 S4rAc4Da6n7AlPEjmP/3sVsoikQcyf+Hps+70ZBOQ817k+ixbfCqMfxLxvttJCnfFmQ7 H4H1HiG3Iry/ZHDOmGZr0BGG/kF/jMioLz3BWs+nJb8kYyzTzHK5eu2htJ6Iqhyyme+2 WFcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=b3N5/5tzMAWayce8EslWo34KiGpRW/myBjmKGXf3/9c=; b=iQ8dtlYsc1l1x7xSxaaMBVHoiYqcTbOCBjSBkCQjVq6VRbG+ouiBme6kcTIoBkFLl/ GEe9K3NxDBqsE3tlnSzW3C3iEeCveQld22RVRkYvzmLZ0exq2ozX5xH85onsZb3JNqWq eD0k1HNnDp70LDIBYoQ8Vd2VZ8P8qRTAW5fEsxbFTtbMg/p96sVQvdYC5Vh32KohNxK5 GkxNfRGzfMsg/UQPH66rdK0/5c8uWbq+ZNpShkr2NTW5577etlQKbwmIRTyN8Irxt8V8 A/xgnG28RZLoGIy3SJsgXf3o1EOJNkLaeET4d6i/FnNQ6ExrO5OVoJLyhHeK+w1BAarE 9Fpg== X-Gm-Message-State: AOAM532E8HQJv88bSbT1z+rlfD3XZ3bH0ki414avnX2Pat9wUpFFCAkl 5OstxnGVkzXzMp8k6CDg61w2Jw== X-Google-Smtp-Source: ABdhPJwUT7oVCh+lmpCfdY1a8CjZdT8LBqJ2RafVP0wvJg+o0Ci/dVDKKvbhdyQNGsBnY7kLfyJJ5g== X-Received: by 2002:a0c:f64b:: with SMTP id s11mr894408qvm.47.1603485433576; Fri, 23 Oct 2020 13:37:13 -0700 (PDT) Received: from [192.168.1.114] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id o47sm1705318qtk.21.2020.10.23.13.37.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 13:37:12 -0700 (PDT) To: Praveen Balasubramanian , "tcpm@ietf.org" , Matt Olson , Yi Huang References: From: Wesley Eddy Message-ID: <8e59b58f-badd-2aac-fe2e-d40a9c78cc94@mti-systems.com> Date: Fri, 23 Oct 2020 16:37:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D20995A84CA5B8CAE1D591D4" Content-Language: en-US Archived-At: Subject: Re: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 20:37:17 -0000 This is a multi-part message in MIME format. --------------D20995A84CA5B8CAE1D591D4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thank you for this helpful review; here are my plans/thoughts on addressing your comments: On 10/15/2020 10:06 PM, Praveen Balasubramanian wrote: > > Section 3.1 > > The control bits in the header include the RFC 3168 specified CWR and > ECE. It might be worth citing 3168 as well in the Abstract. > Agreed; I'll do this in the next revision. > It is quite a bit surprising that we don't include discussion of the > SACK, Timestamp, and Window Scaling options. Even if we don't describe > the details, the document should provide references to these almost > universally deployed options and recommend that hosts SHOULD implement > them. At least the Timestamp option is referred to multiple times in > the text without any specification of the format. > This makes basically sense to me, and I'll plan to improve on it in the next revision. My plan is to prominently reference the specs that define those options, and say that they're recommended, but won't try to recreate their definitions here though. > Section 3.6.4 > > " > > If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the > > sending TCP endpoint buffers all user data (regardless of the PSH > > bit), until the outstanding data has been acknowledged or until the > > TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes). > > " > > This is slightly different from Nagle's description in RFC 896: > > " > > The solution is to inhibit the sending of new TCP segments when > > new outgoing data arrives from the user if any previously > > transmitted data on the connection remains unacknowledged. > > " > > I.e., the original algorithm description in RFC 896 didn't include the > "or if a full-sized packet can be sent" part. This difference isn't > mentioned in 793bis, it ought to be, along with a justification for > the difference. > This part is directly from RFC 1122 (Section 4.2.3.4), so I think it says the proper thing. > Also there is no mention of the interaction problem between Nagle's > algorithm and delayed ACKs, either here or in the later section on > delayed ACKs. > Very good point! Currently, the delayed ACK interaction w/ Nagle is only mentioned in Appendix A.3. I think, based on your comment, that we should add a mention of this in the main body when Nagle's algorithm is discussed, referring to A.3. > Section 3.7.3 > > However, the values of R1 and R2 may be different for SYN > > and data segments. In particular, R2 for a SYN segment *MUST* > > be set large enough to provide retransmission of the segment > > for at least 3 minutes. The application can close the > > connection (i.e., give up on the open attempt) sooner, of > > course. > > > > The MUST here is onerous for what is an ancient timeout value which > modern implementations dont adhere to. Recommend changing this to a > SHOULD. > While I agree, I think this will require some greater working group discussion. If the group and chairs agree, I'm happy to do this. > Section 3.7.4 > > Keep-alive packets MUST only be sent when no data or acknowledgement > > packets have been received for the connection within an interval > > (MUST-26). > > > > Its important to call out an additional condition that sends are > not already outstanding. When a send is outstanding, it is > retransmitted and serves as an implicit liveness check. > This is an excellent point, and I think it can be added in the next revision, unless there is any objections from the rest of the working group. > Section 3.7.2 > > /A TCP endpoint MUST implement RFC 5681 (MUST-19)./ > > This requirement is onerous because RFC 5681 also specifies the > NewReno congestion control algorithms. Modern implementations use > other algorithms. We should add clarifying text permitting > experimentation and evolution of congestion control algorithms. It is > also not required for interop. > This is a part where maybe we could use some more help/input on the exact wording. I think MUST implement some IETF standard congestion control is the right idea, but alternative algorithms that are administratively (or otherwise) managed on a host are also fine to implement and enable. If others agree, disagree, or have thoughts on how exactly to phrase this, I think it would help to hear from the working group. Finally, all of your editorial comments are now accounted for in my working copy, so thank you for those. --------------D20995A84CA5B8CAE1D591D4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thank you for this helpful review; here are my plans/thoughts on addressing your comments:


On 10/15/2020 10:06 PM, Praveen Balasubramanian wrote:

Section 3.1

The control bits in the header include the RFC 3168 specified CWR and ECE. It might be worth citing 3168 as well in the Abstract.

Agreed; I'll do this in the next revision.


It is quite a bit surprising that we don't include discussion of the SACK, Timestamp, and Window Scaling options. Even if we don't describe the details, the document should provide references to these almost universally deployed options and recommend that hosts SHOULD implement them. At least the Timestamp option is referred to multiple times in the text without any specification of the format.

This makes basically sense to me, and I'll plan to improve on it in the next revision. My plan is to prominently reference the specs that define those options, and say that they're recommended, but won't try to recreate their definitions here though.


Section 3.6.4

"

If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the

sending TCP endpoint buffers all user data (regardless of the PSH

bit), until the outstanding data has been acknowledged or until the

TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes).

"

This is slightly different from Nagle's description in RFC 896:

"

The solution is to inhibit the sending of new TCP segments when

new outgoing data arrives from the user if any previously

transmitted data on the connection remains unacknowledged.

"

I.e., the original algorithm description in RFC 896 didn't include the "or if a full-sized packet can be sent" part. This difference isn't mentioned in 793bis, it ought to be, along with a justification for the difference.

This part is directly from RFC 1122 (Section 4.2.3.4), so I think it says the proper thing.


Also there is no mention of the interaction problem between Nagle's algorithm and delayed ACKs, either here or in the later section on delayed ACKs.

Very good point! Currently, the delayed ACK interaction w/ Nagle is only mentioned in Appendix A.3. I think, based on your comment, that we should add a mention of this in the main body when Nagle's algorithm is discussed, referring to A.3.

Section 3.7.3

However, the values of R1 and R2 may be different for SYN

and data segments. In particular, R2 for a SYN segment MUST

be set large enough to provide retransmission of the segment

for at least 3 minutes. The application can close the

connection (i.e., give up on the open attempt) sooner, of

course.

The MUST here is onerous for what is an ancient timeout value which modern implementations dont adhere to. Recommend changing this to a SHOULD.

While I agree, I think this will require some greater working group discussion. If the group and chairs agree, I'm happy to do this.


Section 3.7.4

Keep-alive packets MUST only be sent when no data or acknowledgement

packets have been received for the connection within an interval

(MUST-26).

Its important to call out an additional condition that sends are not already outstanding. When a send is outstanding, it is retransmitted and serves as an implicit liveness check.

This is an excellent point, and I think it can be added in the next revision, unless there is any objections from the rest of the working group.


Section 3.7.2

A TCP endpoint MUST implement RFC 5681 (MUST-19).

This requirement is onerous because RFC 5681 also specifies the NewReno congestion control algorithms. Modern implementations use other algorithms. We should add clarifying text permitting experimentation and evolution of congestion control algorithms. It is also not required for interop.

This is a part where maybe we could use some more help/input on the exact wording.

I think MUST implement some IETF standard congestion control is the right idea, but alternative algorithms that are administratively (or otherwise) managed on a host are also fine to implement and enable. If others agree, disagree, or have thoughts on how exactly to phrase this, I think it would help to hear from the working group.


Finally, all of your editorial comments are now accounted for in my working copy, so thank you for those.


--------------D20995A84CA5B8CAE1D591D4-- From nobody Fri Oct 23 14:16:48 2020 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 A69AF3A0FD1; Fri, 23 Oct 2020 14:15:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, martin.h.duke@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774564.5087.12377557525740179624@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:45 -0700 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 109 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, 23 Oct 2020 21:15:48 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:00 requested) Tuesday, 17 November 2020, Session I 1200-1400 Room Name: Room 8 size: 508 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/tcpm.ics Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Technology Overlap: tsvwg quic taps tsvarea iccrg panrg webtrans masque Key Participant Conflict: netconf People who must be present: Yoshifumi Nishida Michael Tuexen Martin Duke Michael Scharf Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 23 14:45:05 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD83A0917 for ; Fri, 23 Oct 2020 14:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=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=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 asaBHem32CvG for ; Fri, 23 Oct 2020 14:45:00 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C6D3A09BA for ; Fri, 23 Oct 2020 14:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=68W605rwcLAn2+tfzHTGG2XzfhMOXaO/FyIPrtq6mhI=; b=wjoRJ9lwea54rNPP+e+vhs8jH 1KbHkXUNctUzLrKS79eh9X4t/Boe8WSS9VpRW6fqMZ5WoeFSyBJff8nBCLX1+PewICVQSGR46mS4I 2TbhVC2KLQJnCcH0FLH36Vu/B41hITrrrKVmcm5rGWXTXwej3I27cEpv8NkgaAHnp8TaHpJhpx9KI CCs9k8AyS6bq0SeWOa4OCDzUXZpGtWtLWn+uL9pDxhbH9eVn3P1Sa3ipKDC3gFN66SLSPMinR9au0 DZsZqTyb0Ft5gGUla2jChYjHBVjsS3fVtdSFW4n3WrCD+xBCi+YiSoeLMzoMUoqNcnau+MG81M2e6 umznEZJ8Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49758 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kW4p5-002Zsf-2j; Fri, 23 Oct 2020 17:42:12 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_BCED0EE0-15AB-4E45-AB92-366137F89E80" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Fri, 23 Oct 2020 14:42:06 -0700 Cc: tcpm@ietf.org Message-Id: References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com> To: Wes Eddy X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] A few comments on 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, 23 Oct 2020 21:45:03 -0000 --Apple-Mail=_BCED0EE0-15AB-4E45-AB92-366137F89E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The trouble is that RFC1122 makes this claim while citing RFC793, which, = at best, says: When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds.=20 The key here is =E2=80=9Cpossibly fictitious=E2=80=9D. Another key is = that the clock increments ROUGHLY - not precisely. Finally, nothing = addresses whether this clock persists after reboot. What we want to avoid is text that implies either a realtime clock or = even persistent state across connections that might not be available. =E2=80=9CThe specified clock-driven=E2=80=9D is not the same as =E2=80=9Ca= clock-driven=E2=80=9D. RFC793 has too many wiggle words that aren=E2=80=99= t included here to have the current text stand alone. I=E2=80=99d suggest that 793-bis needs something as follows: TCP Initial Sequence Numbers are based on a number sequence that = monotonically increases until it wraps and wraps infrequently, known = loosely as a =E2=80=9Cclock=E2=80=9D. This clock is a 32-bit counter = that typically increments at least once every roughly 4ms, although it = is neither realtime nor precise, and need not persist across reboots. A TCP implementation MUST use a clock-driven selection of initial sequence numbers (MUST-8) as specified above, and SHOULD generate its = Initial Sequence Numbers with the expression: Joe > On Oct 23, 2020, at 8:23 AM, Wesley Eddy wrote: >=20 > We are trying not to make up anything new for this document that = wasn't already from prior RFCs, so if that has been done wrong, then we = should fix it! >=20 > In this case, I think the MUST comes from RFC1122 (4.2.2.9): >=20 > A TCP MUST use the specified clock-driven selection of > initial sequence numbers. >=20 > And the text on this in 793bis is a merger of this and RFC 6528, as it = says: >=20 > This recommended algorithm is further described in RFC 6528 = [36 = ] and > builds on the basic clock-driven algorithm from RFC 793 = . >=20 > A TCP implementation MUST use a clock-driven selection of initial > sequence numbers (MUST-8), and SHOULD generate its Initial Sequence > Numbers with the expression: > ... > So, I could use help in understanding what to do here, without going = against what has already been put down in 1122 and not relaxed since. >=20 >=20 > On 10/23/2020 11:09 AM, Joseph Touch wrote: >> FWIW, I don=E2=80=99t know where the MUST for that came from. It=E2=80=99= s never been a MUST. >>=20 >> The sad thing is how much of this doc rolls in the continued (IMO) = assault on TCP as needing =E2=80=9Csecurity=E2=80=9D protections somehow = integrated into its basic mechanisms. It continues a trend of mistaking = errors for attacks and mistaking unsecured TCP for a secure service. >>=20 >> Joe >>=20 >>> On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari = > wrote: >>>=20 >>>=20 >>> +1 >>>=20 >>> Especially the last ISN clock MUST statement is something that I = also consider quite restrictive for low end devices. If we cannot change = it for bis, some minimum viable solution described in detail/referenced = would be nice. >>>=20 >>> -- >>> Juhamatti >>>=20 >>>=20 >>> pe 23. lokakuuta 2020 klo 1.49 Joseph Touch > kirjoitti: >>> Hi, all, >>>=20 >>> Comments below, if still useful. >>>=20 >>> Joe >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> Regarding RFC5961, we were very careful in the applicability = statement therein to limit the SHOULD recommendations with specific = conditions and MAY implement elsewhere. This update to 793 misrepresents = those current recommendations as SHOULD for everyone, e.g., here: >>>=20 >>> A potential blind reset attack is described in RFC = 5961 >>> [32], with the mitigation that a TCP implementation >>> SHOULD first check that the sequence number exactly >>> matches RCV.NXT prior to executing the action in the = next >>> paragraph. >>>=20 >>> That text should instead say =E2=80=9CMAY first check=E2=80=9D, = adding, if desired, "(SHOULD, under the conditions noted in RFC = 5961)=E2=80=9D. That corrected text belongs also in section 3.4 where = reset processing is discussed. >>>=20 >>> =E2=80=94 >>>=20 >>> All places that mention issuing a RST (including sec 3.4 and the = state machine) should note that the side issuing the RST ought to enter = TIME_WAIT - and explain why, as noted in: >>> Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and = Its Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999.=20 >>>=20 >>> =E2=80=94 >>>=20 >>> The following text should include a MUST, as shown below: >>>=20 >>> (all TCP options except End of option list and No-Operation >>> MUST have length fields) >>>=20 >>> =E2=80=94 >>>=20 >>> The following text should be preceded by an inline =E2=80=98heading=E2= =80=99 as shown: >>>=20 >>> Experimental TCP options >>>=20 >>> Experimental TCP option values are defined in [22], and [39] >>> describes the current recommended usage for these = experimental >>> values. >>>=20 >>> =E2=80=94 >>>=20 >>> The following text should be moved earlier in the section, because = its current location suggests it is related to the experimental options = discussion (and it is not): >>>=20 >>> Note: There is ongoing work to extend the space available = for >>> TCP options, such as [53]. >>>=20 >>> It might be appropriate to move this before the discussion of = specific options, for example. >>>=20 >>> =E2=80=94 >>>=20 >>> The definition of TIME-WAIT should describe its purpose as also = including avoiding delayed segments from previous connections affecting = new connections. >>>=20 >>> =E2=80=94 >>>=20 >>> I would strongly encourage reformatting to allow the TCP state = machine to avoid page break boundaries. >>>=20 >>> It may also be useful to add a note that RST can be issued from any = state with a corresponding (implied) transition to TIME-WAIT; similarly, = receipt of RST from any state goes to LISTEN. These transitions are not = shown only because they would complicate the diagram. >>>=20 >>> =E2=80=94 >>>=20 >>> The following statement is false: >>>=20 >>> The protocol places no restriction on a particular connection = being >>> used over and over again. >>>=20 >>> Avoiding that happening too quickly in succession is one of the = purposes of TIME-WAIT. New ISNs are only PART of that protection (which = means the rest of this section needs revision to clarify this issue). >>>=20 >>> =E2=80=94 >>>=20 >>> The security of TCP is discussed incorrectly, IMO. The ISN = discussion and RST discussion, in particular, although trying to help = protect against off-path attacks, are only very tenuously considered = =E2=80=9Csecurity=E2=80=9D. There should be some other way of discussing = this and making sure that if TCP users need secure connections they need = to use TCP-AO or IPsec. >>>=20 >>> =E2=80=94 >>>=20 >>> The ISN clock statement with MUST seems to overreach. The previous = text talks about the use of clocks being recommended, but a MUST is much = stronger. The assertion needs more wiggle words or a more generous = definition of clock to avoid being used out of context to prevent simple = implementations on lightweight devices. >>>=20 >>> =E2=80=94 >>> end. >>>=20 >>>=20 >>>=20 >>>=20 >>>=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 = >>=20 >>=20 >>=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=_BCED0EE0-15AB-4E45-AB92-366137F89E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = trouble is that RFC1122 makes this claim while citing RFC793, which, at = best, says:

  When new connections are =
created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds.

The key here is =E2=80=9Cpossibly fictitious=E2=80=9D. = Another key is that the clock increments ROUGHLY - not precisely. = Finally, nothing addresses whether this clock persists after = reboot.

What = we want to avoid is text that implies either a realtime clock or even = persistent state across connections that might not be = available.

=E2=80=9CThe specified clock-driven=E2=80=9D is not the same = as =E2=80=9Ca clock-driven=E2=80=9D. RFC793 has too many wiggle words = that aren=E2=80=99t included here to have the current text stand = alone.

I=E2=80=99= d suggest that 793-bis needs something as follows:


  =  TCP Initial Sequence Numbers are based on a number sequence that = monotonically increases until it wraps and wraps infrequently, known = loosely as a =E2=80=9Cclock=E2=80=9D. This clock is a 32-bit = counter that typically increments at least once every roughly 4ms, = although it is neither realtime nor precise, and need not persist across = reboots.

   A TCP = implementation MUST use a clock-driven selection of initial
   sequence numbers (MUST-8) as specified = above, and SHOULD generate its Initial Sequence
   Numbers with =
the expression:

Joe

On Oct 23, 2020, at 8:23 AM, = Wesley Eddy <wes@mti-systems.com> wrote:

=20 =20

We are trying not to make up anything = new for this document that wasn't already from prior RFCs, so if that has been done wrong, then we should fix it!

In this case, I think the = MUST comes from RFC1122 (4.2.2.9):

           =
 A TCP MUST use the specified clock-driven selection of
            initial sequence numbers.

And the text on this in 793bis is a merger of this = and RFC 6528, as it says:

   This recommended algorithm is =
further described in RFC 6528 =
[36] and
   builds on the basic clock-driven algorithm from RFC 793.

   A TCP implementation MUST use a clock-driven selection of initial
   sequence numbers (MUST-8), and SHOULD generate its Initial Sequence
   Numbers with the expression:
   ...

So, I could use help in understanding what to do = here, without going against what has already been put down in 1122 and not relaxed since.


    
On 10/23/2020 11:09 AM, Joseph Touch
      wrote:

    

    

      
      FWIW, I don=E2=80=99t know where the MUST for that came from. =
It=E2=80=99s never
      been a MUST.
      


      

      
The sad thing is how much of this doc rolls in the
        continued (IMO) assault on TCP as needing =E2=80=9Csecurity=E2=80=9D=
 protections
        somehow integrated into its basic mechanisms. It continues a
        trend of mistaking errors for attacks and mistaking unsecured
        TCP for a secure service.

        


        

        
Joe

          


            

              
On Oct 22, 2020, at 10:20 PM, Juhamatti
                Kuusisaari <juhamatk@gmail.com>
                wrote:

              

              

                

                  

                    


                    

                    
+1

                    


                    

                    
Especially the last ISN clock MUST
                      statement is something that I also consider quite
                      restrictive for low end devices. If we cannot
                      change it for bis, some minimum viable solution
                      described in detail/referenced would be =
nice.

                    


                    

                    
--

                    
  Juhamatti

                    

                    

                    

                      
pe 23. =
lokakuuta
                        2020 klo 1.49 Joseph Touch <touch@strayalpha.com>
                        kirjoitti:

                      

                      
Hi, all,

                        

                        Comments below, if still useful.

                        

                        Joe

                        

                        =E2=80=94=E2=80=94

                        

                        Regarding RFC5961, we were very careful in the
                        applicability statement therein to limit the
                        SHOULD recommendations with specific conditions
                        and MAY implement elsewhere. This update to 793
                        misrepresents those current recommendations as
                        SHOULD for everyone, e.g., here:

                        

                                      =
 A potential blind reset attack is
                        described in RFC 5961

                                      =
 [32], with the mitigation that a
                        TCP implementation

                                      =
 SHOULD first check that the
                        sequence number exactly

                                      =
 matches RCV.NXT prior to
                        executing the action in the next

                                      =
 paragraph.

                        

                        That text should instead say =E2=80=9CMAY first =
check=E2=80=9D,
                        adding, if desired, "(SHOULD, under the
                        conditions noted in RFC 5961)=E2=80=9D. That =
corrected
                        text belongs also in section 3.4 where reset
                        processing is discussed.

                        

                        =E2=80=94

                        

                        All places that mention issuing a RST (including
                        sec 3.4 and the state machine) should note that
                        the side issuing the RST ought to enter
                        TIME_WAIT - and explain why, as noted in:

                                Faber, T; Touch, J; =
Yue, W: The
                        TIME-WAIT state in TCP and Its Effect on Busy
                        Servers. In: Infocom, pp. 1573-1583, IEEE, 1999.
                        

                        

                        =E2=80=94

                        

                        The following text should include a MUST, as
                        shown below:

                        

                            (all TCP options except End of =
option list
                        and No-Operation

                             MUST have length fields)

                        

                        =E2=80=94

                        

                        The following text should be preceded by an
                        inline =E2=80=98heading=E2=80=99 as shown:

                        

                                Experimental TCP =
options

                        

                                Experimental TCP =
option values are
                        defined in [22], and [39]

                                describes the =
current recommended usage
                        for these experimental

                                values.
=

                        

                        =E2=80=94

                        

                        The following text should be moved earlier in
                        the section, because its current location
                        suggests it is related to the experimental
                        options discussion (and it is not):
=

                        

                                Note: There is =
ongoing work to extend
                        the space available for

                                TCP options, such as =
[53].

                        

                        It might be appropriate to move this before the
                        discussion of specific options, for example.

                        

                        =E2=80=94

                        

                        The definition of TIME-WAIT should describe its
                        purpose as also including avoiding delayed
                        segments from previous connections affecting new
                        connections.

                        

                        =E2=80=94

                        

                        I would strongly encourage reformatting to allow
                        the TCP state machine to avoid page break
                        boundaries.

                        

                        It may also be useful to add a note that RST can
                        be issued from any state with a corresponding
                        (implied) transition to TIME-WAIT; similarly,
                        receipt of RST from any state goes to LISTEN.
                        These transitions are not shown only because
                        they would complicate the diagram.

                        

                        =E2=80=94

                        

                        The following statement is false:

                        

                          The protocol places no restriction on a
                        particular connection being

                           used over and over again.

                        

                        Avoiding that happening too quickly in
                        succession is one of the purposes of TIME-WAIT.
                        New ISNs are only PART of that protection (which
                        means the rest of this section needs revision to
                        clarify this issue).

                        

                        =E2=80=94

                        

                        The security of TCP is discussed incorrectly,
                        IMO. The ISN discussion and RST discussion, in
                        particular, although trying to help protect
                        against off-path attacks, are only very
                        tenuously considered =E2=80=9Csecurity=E2=80=9D. =
There should be
                        some other way of discussing this and making
                        sure that if TCP users need secure connections
                        they need to use TCP-AO or IPsec.

                        

                        =E2=80=94

                        

                        The ISN clock statement with MUST seems to
                        overreach. The previous text talks about the use
                        of clocks being recommended, but a MUST is much
                        stronger. The assertion needs more wiggle words
                        or a more generous definition of clock to avoid
                        being used out of context to prevent simple
                        implementations on lightweight devices.

                        

                        =E2=80=94

                        end.

                        

                        

                        

                        

                        

                        =
_______________________________________________

                        tcpm mailing list

                        tcpm@ietf.org

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

                    

                  

                

                _______________________________________________

                tcpm mailing list

                tcpm@ietf.org

                https://www.ietf.org/m=
ailman/listinfo/tcpm

              

            

          

          

        

      

      

      

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


    

  


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

=

--Apple-Mail=_BCED0EE0-15AB-4E45-AB92-366137F89E80--


From nobody Sat Oct 24 01:49:06 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A45E3A0B32 for ; Sat, 24 Oct 2020 01:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6_TurVjvGm6 for ; Sat, 24 Oct 2020 01:49:02 -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 F0FA93A0AEE for ; Sat, 24 Oct 2020 01:49:01 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 839AF25A27; Sat, 24 Oct 2020 10:48:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603529339; bh=OFxhzujUIO7KlKpTZHlKlwWWfE0yok6byC4wzjNVUio=; h=From:To:Subject:Date:References:In-Reply-To:From; b=MkaxnMEv3M8YUpwvrbI88PENvng82q0Fj22m39GjityoDQy5tLxk/wITsQtWTzN/A 9E8si9XlsMZ2LK2/B5HikJG0ZeUi0W9UYHqy5G8fS+cZmBTYa/d590TrVM2mEpNwaY kqRwbt+TpOx0xIiy1tnhL0bxPLp6QNCeXbnwp3bQ=
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 VUc45PLOeOxX; Sat, 24 Oct 2020 10:48:58 +0200 (CEST)
Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sat, 24 Oct 2020 10:48:58 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Sat, 24 Oct 2020 10:48:58 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Sat, 24 Oct 2020 10:48:58 +0200
From: "Scharf, Michael" 
To: Wesley Eddy , Praveen Balasubramanian , "tcpm@ietf.org" , "Matt Olson" , Yi Huang 
Thread-Topic: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18
Thread-Index: AdajXxk8uequbu29QB+n5DRBKHdcewAAci5QAYKou4AAHSTecA==
Date: Sat, 24 Oct 2020 08:48:58 +0000
Message-ID: <73083c48b3ed4285a79f711034c3b2d8@hs-esslingen.de>
References:   <8e59b58f-badd-2aac-fe2e-d40a9c78cc94@mti-systems.com>
In-Reply-To: <8e59b58f-badd-2aac-fe2e-d40a9c78cc94@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.140.248]
Content-Type: multipart/alternative; boundary="_000_73083c48b3ed4285a79f711034c3b2d8hsesslingende_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Oct 2020 08:49:04 -0000

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

Regarding...

>> Section 3.7.3
 >>
>> "However, the values of R1 and R2 may be different for SYN
>>            and data segments.  In particular, R2 for a SYN segment MUST
>>            be set large enough to provide retransmission of the segment
>>            for at least 3 minutes.  The application can close the
>>            connection (i.e., give up on the open attempt) sooner, of
>>            course.
>> "
>> The MUST here is onerous for what is an ancient timeout value which mode=
rn implementations don't adhere to. Recommend changing this to a SHOULD.
>
> While I agree, I think this will require some greater working group discu=
ssion.  If the group and chairs agree, I'm happy to do this.

This MUST is in RFC 1122, i.e., using SHOULD would be a modification to RFC=
 1122. If we change the wording, I think we need to clearly document that c=
hange, e.g. in Section 8, possibly with an explanation.

Personally (i.e., with no hat), I agree that this MUST could be changed to =
a SHOULD, if the change is properly documented.

I have also thought about other wordings to work around this capital letter=
 MUST, but I haven't found a good alternative so far.

Michael

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











Regarding…



 


>> Section 3.7.3



 >>


>> “However, the values of R1 and R2 may be different for=
 SYN


>>          &=
nbsp; and data segments.  In particular, R2 for a SYN segment MUST


>>          &=
nbsp; be set large enough to provide retransmission of the segment


>>          &=
nbsp; for at least 3 minutes.  The application can close the


>>          &=
nbsp; connection (i.e., give up on the open attempt) sooner, of<=
/span>


>>          &=
nbsp; course.


>> “


>> The MUST here is onerous for what is an ancient timeout valu=
e which modern implementations don’t adhere to. Recommend changing th=
is to a SHOULD.


> 


> While I agree, I think this will require some greater working gr=
oup discussion.  If the group and chairs agree, I'm happy to do this.<=
o:p>


 


This MUST is in RFC 1122, i.e., using SHOULD would be a modification =
to RFC 1122. If we change the wording, I think we need to clearly document =
that change, e.g. in Section 8, possibly
 with an explanation.


 


Personally (i.e., with no hat), I agree that this MUST could be chang=
ed to a SHOULD, if the change is properly documented.


 


I have also thought about other wordings to work around this capital =
letter MUST, but I haven’t found a good alternative so far.


 


Michael






--_000_73083c48b3ed4285a79f711034c3b2d8hsesslingende_--


From nobody Sat Oct 24 07:51:08 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAC73A0C55 for ; Sat, 24 Oct 2020 07:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 Od80gB9RWy1H for ; Sat, 24 Oct 2020 07:51:00 -0700 (PDT)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 390C63A0C53 for ; Sat, 24 Oct 2020 07:51:00 -0700 (PDT)
Received: by mail-wr1-x443.google.com with SMTP id i1so6208327wro.1 for ; Sat, 24 Oct 2020 07:51: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:content-transfer-encoding; bh=Jbvfxt6uWfFMEfh0MGu3fum4a5kZ/iZsOzitMFwtgj8=; b=SgWsYemktn0bU0iE46nSJWOs41MCyAn40pdme4Rb+Ol/U0B/9KAbS22AnDCGpRKGVL xeuM+G6rZQem509CIKp8jy+/C27zvc8OB9ufN9/rhGisY6ofD1O1ePH4M32opw37g/Ox TLLF9kpy++Z7wxHQ3r1fKNX7nGfFL0RYN0ilkj/NYlDum4XiO/omTrIl+VBrdRPYQeUP QaplS8PDQSpdBm15JyulWIvpsrGgi0RR2dOfUmO1sUvoqtSTkn+T3KmOK1JCYxX1ZgPk MrwFjXyztYlkQ9320UiD4aou1NvYafqohaQR1W1/XRt5nZyE4ny/AVnRTltwNfrnUUhR MwKw==
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=Jbvfxt6uWfFMEfh0MGu3fum4a5kZ/iZsOzitMFwtgj8=; b=E5VUQQhTVGCU0mYz1s/ksyMUQFl1bmBNOEQPOfwcyPoFbcMoqSYJqqEi2Ljt8CvIdC 59Td6fojVUR/PPx/fCX+Xrf8LmbEUM/3poWSmXx7rj4xClDFpHGlYF/jqcPG6nVCPT7N 5CFK/DulTaqcRZbiwKumBIobHX8zrCOBcG5ZCiZt4DgesThYlH/aMyZyvRHSJ0vQrFx4 208Ywzj3UrWCn32zfvfDDbI6Z0vRwlbA3jzHN8iv0l5SzR20L1/ar9y8kQEVhJ6g1Yoe R1t3MnEi6muDERBg0l3QAYIklkIwu79NU4EPlxnF4U52IcqrJpMVy24YBdBKjMUWWHZj v5YQ==
X-Gm-Message-State: AOAM533O1HfZITPq3qeNLpo5vtyH4r8b06v9jWlKG9gardDnAVZTOfkg kGVQ7g7dcX0g6j94JTkBgoYDJcDOFPl6amd48sS/GY/pyfk8Rg==
X-Google-Smtp-Source: ABdhPJzhMRE+FAGrwo/K5x4FTQdVuP7VsCmirIvxGfEw5CMO/oUPI0NmNGBsOtTCdTxzZO8endOn/hHwWkFYX4MIxCY=
X-Received: by 2002:adf:a31c:: with SMTP id c28mr8470580wrb.351.1603551058639;  Sat, 24 Oct 2020 07:50:58 -0700 (PDT)
MIME-Version: 1.0
References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com>    
In-Reply-To: 
From: Juhamatti Kuusisaari 
Date: Sat, 24 Oct 2020 17:50:46 +0300
Message-ID: 
To: Joseph Touch 
Cc: Wes Eddy , tcpm IETF list 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tcpm] A few comments on 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: Sat, 24 Oct 2020 14:51:07 -0000

For the reference I was missing, here is roughly how FreeBSD does it [1]:

"
 * Implementation details:
 *
 * Time is based off the system timer, and is corrected so that it
 * increases by one megabyte per second.  This allows for proper
 * recycling on high speed LANs while still leaving over an hour
 * before rollover.
 *
 * As reading the *exact* system time is too expensive to be done
 * whenever setting up a TCP connection, we increment the time
 * offset in two ways.  First, a small random positive increment
 * is added to isn_offset for each connection that is set up.
 * Second, the function tcp_isn_tick fires once per clock tick
 * and increments isn_offset as necessary so that sequence numbers
 * are incremented at approximately ISN_BYTES_PER_SECOND.  The
 * random positive increments serve only to ensure that the same
 * exact sequence number is never sent out twice (as could otherwise
 * happen when a port is recycled in less than the system tick
 * interval.)
"
where
#define ISN_BYTES_PER_SECOND 1048576

This not quite how it works with the latest version as there
isn_offset is updated on the fly instead of a separate function call
for every tick (i.e. the comment should be updated), which is a better
approach indeed. Based on this, I'd say there are simple references
for clock-driven functionality easily available, maybe we do not need
to add them to the bis.

--
 Juhamatti

[1] https://svnweb.freebsd.org/base/stable/12/sys/netinet/tcp_subr.c?revisi=
on=3D366565&view=3Dco

On Sat, 24 Oct 2020 at 00:45, Joseph Touch  wrote:
>
> The trouble is that RFC1122 makes this claim while citing RFC793, which, =
at best, says:
>
>   When new connections are created,
>   an initial sequence number (ISN) generator is employed which selects a
>   new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
>   bit clock whose low order bit is incremented roughly every 4
>   microseconds.
>
>
> The key here is =E2=80=9Cpossibly fictitious=E2=80=9D. Another key is tha=
t the clock increments ROUGHLY - not precisely. Finally, nothing addresses =
whether this clock persists after reboot.
>
> What we want to avoid is text that implies either a realtime clock or eve=
n persistent state across connections that might not be available.
>
> =E2=80=9CThe specified clock-driven=E2=80=9D is not the same as =E2=80=9C=
a clock-driven=E2=80=9D. RFC793 has too many wiggle words that aren=E2=80=
=99t included here to have the current text stand alone.
>
> I=E2=80=99d suggest that 793-bis needs something as follows:
>
>
>    TCP Initial Sequence Numbers are based on a number sequence that monot=
onically increases until it wraps and wraps infrequently, known loosely as =
a =E2=80=9Cclock=E2=80=9D. This clock is a 32-bit counter that typically in=
crements at least once every roughly 4ms, although it is neither realtime n=
or precise, and need not persist across reboots.
>
>    A TCP implementation MUST use a clock-driven selection of initial
>    sequence numbers (MUST-8) as specified above, and SHOULD generate its =
Initial Sequence
>
>    Numbers with the expression:
>
>
> Joe
>
> On Oct 23, 2020, at 8:23 AM, Wesley Eddy  wrote:
>
> We are trying not to make up anything new for this document that wasn't a=
lready from prior RFCs, so if that has been done wrong, then we should fix =
it!
>
> In this case, I think the MUST comes from RFC1122 (4.2.2.9):
>
>             A TCP MUST use the specified clock-driven selection of
>             initial sequence numbers.
>
> And the text on this in 793bis is a merger of this and RFC 6528, as it sa=
ys:
>
>    This recommended algorithm is further described in RFC 6528 [36] and
>    builds on the basic clock-driven algorithm from RFC 793.
>
>    A TCP implementation MUST use a clock-driven selection of initial
>    sequence numbers (MUST-8), and SHOULD generate its Initial Sequence
>    Numbers with the expression:
>    ...
>
> So, I could use help in understanding what to do here, without going agai=
nst what has already been put down in 1122 and not relaxed since.
>
> On 10/23/2020 11:09 AM, Joseph Touch wrote:
>
> FWIW, I don=E2=80=99t know where the MUST for that came from. It=E2=80=99=
s never been a MUST.
>
> The sad thing is how much of this doc rolls in the continued (IMO) assaul=
t on TCP as needing =E2=80=9Csecurity=E2=80=9D protections somehow integrat=
ed into its basic mechanisms. It continues a trend of mistaking errors for =
attacks and mistaking unsecured TCP for a secure service.
>
> Joe
>
> On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari  w=
rote:
>
>
> +1
>
> Especially the last ISN clock MUST statement is something that I also con=
sider quite restrictive for low end devices. If we cannot change it for bis=
, some minimum viable solution described in detail/referenced would be nice=
.
>
> --
>   Juhamatti
>
>
> pe 23. lokakuuta 2020 klo 1.49 Joseph Touch  kirjoi=
tti:
>>
>> Hi, all,
>>
>> Comments below, if still useful.
>>
>> Joe
>>
>> =E2=80=94=E2=80=94
>>
>> Regarding RFC5961, we were very careful in the applicability statement t=
herein to limit the SHOULD recommendations with specific conditions and MAY=
 implement elsewhere. This update to 793 misrepresents those current recomm=
endations as SHOULD for everyone, e.g., here:
>>
>>                A potential blind reset attack is described in RFC 5961
>>                [32], with the mitigation that a TCP implementation
>>                SHOULD first check that the sequence number exactly
>>                matches RCV.NXT prior to executing the action in the next
>>                paragraph.
>>
>> That text should instead say =E2=80=9CMAY first check=E2=80=9D, adding, =
if desired, "(SHOULD, under the conditions noted in RFC 5961)=E2=80=9D. Tha=
t corrected text belongs also in section 3.4 where reset processing is disc=
ussed.
>>
>> =E2=80=94
>>
>> All places that mention issuing a RST (including sec 3.4 and the state m=
achine) should note that the side issuing the RST ought to enter TIME_WAIT =
- and explain why, as noted in:
>>         Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and Its E=
ffect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999.
>>
>> =E2=80=94
>>
>> The following text should include a MUST, as shown below:
>>
>>     (all TCP options except End of option list and No-Operation
>>      MUST have length fields)
>>
>> =E2=80=94
>>
>> The following text should be preceded by an inline =E2=80=98heading=E2=
=80=99 as shown:
>>
>>         Experimental TCP options
>>
>>         Experimental TCP option values are defined in [22], and [39]
>>         describes the current recommended usage for these experimental
>>         values.
>>
>> =E2=80=94
>>
>> The following text should be moved earlier in the section, because its c=
urrent location suggests it is related to the experimental options discussi=
on (and it is not):
>>
>>         Note: There is ongoing work to extend the space available for
>>         TCP options, such as [53].
>>
>> It might be appropriate to move this before the discussion of specific o=
ptions, for example.
>>
>> =E2=80=94
>>
>> The definition of TIME-WAIT should describe its purpose as also includin=
g avoiding delayed segments from previous connections affecting new connect=
ions.
>>
>> =E2=80=94
>>
>> I would strongly encourage reformatting to allow the TCP state machine t=
o avoid page break boundaries.
>>
>> It may also be useful to add a note that RST can be issued from any stat=
e with a corresponding (implied) transition to TIME-WAIT; similarly, receip=
t of RST from any state goes to LISTEN. These transitions are not shown onl=
y because they would complicate the diagram.
>>
>> =E2=80=94
>>
>> The following statement is false:
>>
>>   The protocol places no restriction on a particular connection being
>>    used over and over again.
>>
>> Avoiding that happening too quickly in succession is one of the purposes=
 of TIME-WAIT. New ISNs are only PART of that protection (which means the r=
est of this section needs revision to clarify this issue).
>>
>> =E2=80=94
>>
>> The security of TCP is discussed incorrectly, IMO. The ISN discussion an=
d RST discussion, in particular, although trying to help protect against of=
f-path attacks, are only very tenuously considered =E2=80=9Csecurity=E2=80=
=9D. There should be some other way of discussing this and making sure that=
 if TCP users need secure connections they need to use TCP-AO or IPsec.
>>
>> =E2=80=94
>>
>> The ISN clock statement with MUST seems to overreach. The previous text =
talks about the use of clocks being recommended, but a MUST is much stronge=
r. The assertion needs more wiggle words or a more generous definition of c=
lock to avoid being used out of context to prevent simple implementations o=
n lightweight devices.
>>
>> =E2=80=94
>> end.
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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 Oct 26 00:53:00 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41B03A19AD for ; Mon, 26 Oct 2020 00:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level: 
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=tele.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 rJiyAV91-g2H for ; Mon, 26 Oct 2020 00:52:55 -0700 (PDT)
Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 7C7753A19AE for ; Mon, 26 Oct 2020 00:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; 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=Fw9cs85c7eLpHjAHk/jwks38Y88OPJBM6ohhNRKFF20=; b=qf/uA5pRIc58tnuCX3MsqWs2oM NRPrqKXrRr7gqJfrjfUhd6jQSK7kkl2zH9gvhLfQfs+SREcWrqDl5+SzsOg5A92SeEaEilf8AuwBq UajOw3FiNElDTPL+2ddpYeMWrlpmmqtssRCdpsFcWVpXRGUUhtJtbZX+QbHwvKB50SHmM755dJQRd ZfQsuVNS6mUU9zVj3W1Jz4zczQmnJCkEz9zltChbNGLchzV0whAK+qxSDY6EYk+uBKM7tp9I3xQxt VBkoHhQqlzn8li/RYU1m/3XVv7CkdvNuGgR7QpdXSdo4cSrrc8YOy3khYp/oQxmJoCO1p90DYZJjw Enmc3UZA==;
Received: from pilt2.tele.no ([2001:700:800::21] helo=[127.0.0.1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from ) id 1kWxJA-0004yi-Hu; Mon, 26 Oct 2020 08:52:48 +0100
To: Joseph Touch 
Cc: Mirja Kuehlewind , "tcpm@ietf.org Extensions" 
References:  <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk>  <246C6457-BF65-4B66-970A-FD6C95A98772@strayalpha.com>
From: Frode Kileng 
Message-ID: 
Date: Mon, 26 Oct 2020 08:52:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <246C6457-BF65-4B66-970A-FD6C95A98772@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2020 07:52:59 -0000

On 23/10/2020 17:11, Joseph Touch wrote:
>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > > wrote:
>>
>> Although maybe not  a "general problem",  a study of MSS middlebox 
>> manipluation in  23 European and Asian mobile networks did reveal 
>> some issues:
>>
>> - 20 of 23 networks always inserts MSS.
>
> That IS a general problem, FWIW.
>
> Besides being published, it should also be reported to the operators 
> of those networks as violating TCP specs.

Do you mean as in "layering violation" or is it explicitly stated in an 
RFC that MSS clamping is not allowed.

Anyway, since stopping this practice is likely to cause extensive 
fragmentation of TCP segments, mobile networks will continue this 
despite "violating TCP specs". At least until the networks fully support 
jumbo frames.

(The motivation for MSS clamping is the tunneling overhead in the mobile 
core of the networks. Within the core, the MSS is clamped to take into 
consideration the size of the  GTP-U header and potential additional 
ipsec headers. The GTP-U header is variable size and is at least 40 
bytes for IPv4 and 60 for IPv6. In addition it may include vendor or 
mobile operator specific extension headers. I do not now why networks 
don't reduce the MTU size instead. My understanding of the 3GPP specs is 
that this is suggested but could not find out how this is provisioned to 
the terminals for IPv4. I've only seen one mobile network that 
provisioned the terminals with a MTU lower than 1500 bytes. But their 
MTU size of 1464 for for IPv4 and IPv6 did not seem reflect the GTP-U 
tunnel.)


Regards

Frode Kileng






From nobody Mon Oct 26 02:34:51 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44F63A1A05 for ; Mon, 26 Oct 2020 02:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.613
X-Spam-Level: 
X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1lhHGkKEEXH for ; Mon, 26 Oct 2020 02:34:47 -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 4C9EC3A1A03 for ; Mon, 26 Oct 2020 02:34:46 -0700 (PDT)
Received: from [IPv6:2a02:8109:1140:c3d:a026:2f8:6534:ca25] (unknown [IPv6:2a02:8109:1140:c3d:a026:2f8:6534:ca25]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 77E207799D350; Mon, 26 Oct 2020 10:34:42 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Michael Tuexen 
In-Reply-To: 
Date: Mon, 26 Oct 2020 10:34:41 +0100
Cc: Joseph Touch , "tcpm@ietf.org Extensions" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C8105AE-483B-463F-8EBC-D00199974976@lurchi.franken.de>
References:  <247D753D-DA2C-47EF-9C38-C2B5E274FD8F@erg.abdn.ac.uk>  <246C6457-BF65-4B66-970A-FD6C95A98772@strayalpha.com> 
To: Frode Kileng 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2020 09:34:50 -0000

> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>=20
>=20
>=20
> On 23/10/2020 17:11, Joseph Touch wrote:
>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>>>=20
>>> Although maybe not  a "general problem",  a study of MSS middlebox =
manipluation in  23 European and Asian mobile networks did reveal some =
issues:
>>>=20
>>> - 20 of 23 networks always inserts MSS.
>>=20
>> That IS a general problem, FWIW.
>>=20
>> Besides being published, it should also be reported to the operators =
of those networks as violating TCP specs.
>=20
> Do you mean as in "layering violation" or is it explicitly stated in =
an RFC that MSS clamping is not allowed.
I think we should differentiate two issues:
(a) a middlebox which reduces the MSS already in an SYN/SYN-ACK =
segement.
(b) a middlebox which adds an MSS option, which wasn't there in the =
SYN/SYN-ACK segment.

(a) is the typical MSS clamping you are referring to and it is used to =
mitigate MTU issues.
(b) is a problem in my view and referred to in the statement 'always =
inserts'.

Best regards
Michael
>=20
> Anyway, since stopping this practice is likely to cause extensive =
fragmentation of TCP segments, mobile networks will continue this =
despite "violating TCP specs". At least until the networks fully support =
jumbo frames.
>=20
> (The motivation for MSS clamping is the tunneling overhead in the =
mobile core of the networks. Within the core, the MSS is clamped to take =
into consideration the size of the  GTP-U header and potential =
additional ipsec headers. The GTP-U header is variable size and is at =
least 40 bytes for IPv4 and 60 for IPv6. In addition it may include =
vendor or mobile operator specific extension headers. I do not now why =
networks don't reduce the MTU size instead. My understanding of the 3GPP =
specs is that this is suggested but could not find out how this is =
provisioned to the terminals for IPv4. I've only seen one mobile network =
that provisioned the terminals with a MTU lower than 1500 bytes. But =
their MTU size of 1464 for for IPv4 and IPv6 did not seem reflect the =
GTP-U tunnel.)
>=20
>=20
> Regards
>=20
> Frode Kileng
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Mon Oct 26 07:24:44 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900BF3A0BB9 for ; Mon, 26 Oct 2020 07:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcJAS_EWfUGK for ; Mon, 26 Oct 2020 07:24:41 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106113A0BB6 for ; Mon, 26 Oct 2020 07:24:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=r3rkoI7uJG/wfEuJ0qQdhIa8a/PUmOHFSvUwpi/aRwc=; b=wK4RaclrRti8JL3kMsPMCD8PNQ UQOFO9pu5n4cC/xbs+SnIAo+0JkYW4bsNsNxtr364ZKua64h7G7IPf/stbaxS36Cvs7GXK+toXIjk rO+vV0k9GtyTaY2upmYkt19ef0W5fY/2G4uySoCKY8vgDvEFAwF3/yk9X7GDuqpEbK7aNmQGNlwLH RXIXx7ZeiGSwtscOLaIM2Kkk1IJ1nadt4ASKduqo63q4siOMvLeLDnUMP2ppr8lIc04yAMJ/ryTXo +CGrMj7mOzIIXF5CHppnCwgN8iX2CwcOKfr7CPfZLfa/VBF3CI2BCLUOm6LLoGKM127cihcAepGmz xjkmdGuA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55371 helo=[192.168.1.13]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kX3QH-003iLK-Nx; Mon, 26 Oct 2020 10:24:38 -0400
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch 
In-Reply-To: <9C8105AE-483B-463F-8EBC-D00199974976@lurchi.franken.de>
Date: Mon, 26 Oct 2020 07:24:32 -0700
Cc: Frode Kileng , "tcpm@ietf.org Extensions" 
Message-Id: <64E62006-FF20-42E0-83CB-12C622135251@strayalpha.com>
References: <9C8105AE-483B-463F-8EBC-D00199974976@lurchi.franken.de>
To: Michael Tuexen 
X-Mailer: iPad Mail (18A8395)
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] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2020 14:24:43 -0000

> On Oct 26, 2020, at 2:35 AM, Michael Tuexen  wrote:
>=20
> =EF=BB=BF
>>=20
>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>>=20
>>=20
>>=20
>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>>>>>=20
>>>>> Although maybe not  a "general problem",  a study of MSS middlebox man=
ipluation in  23 European and Asian mobile networks did reveal some issues:
>>>>>=20
>>>>> - 20 of 23 networks always inserts MSS.
>>>=20
>>> That IS a general problem, FWIW.
>>>=20
>>> Besides being published, it should also be reported to the operators of t=
hose networks as violating TCP specs.
>>=20
>> Do you mean as in "layering violation" or is it explicitly stated in an R=
FC that MSS clamping is not allowed.
> I think we should differentiate two issues:
> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK segement.
> (b) a middlebox which adds an MSS option, which wasn't there in the SYN/SY=
N-ACK segment.

You can if you want; I do not. Both are violations of TCP processing, whose h=
eaders aren=E2=80=99t permitted to be altered in flight. Saying it=E2=80=99s=
 for the good of the endpoints doesn=E2=80=99t change the issue that it shou=
ld be reported and fixed as an error.

If TCP is given an MSS by the other end of a connection and packets don=E2=80=
=99t get through, it can always lower the segment sizes it sends - the is wh=
at PLPMTUD does.=20

Joe=


From nobody Mon Oct 26 08:45:42 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E993A0C70 for ; Mon, 26 Oct 2020 08:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Level: 
X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_DNSWL_BLOCKED=0.001, 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=tele.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 LMjgqOaoyNZx for ; Mon, 26 Oct 2020 08:45:36 -0700 (PDT)
Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 644F73A0C96 for ; Mon, 26 Oct 2020 08:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; 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=6fWlGzCPYs3WpbqbBJ0/zjSp0IQ8LTKxoErkIf+LlLY=; b=S93dzls0MFkCIHtTF3t0adPYC4 orUnT7WUpQ/mFBz+yzKhh4o+xTSEQntZAa0H9UmsR8ywVsmblqd3xLcnI93mDbA2vSCfG4XiX2vzj QD9x7JCFrRIVIAO7AQmLHgkYMmAQTSg+45T+sviAybjd642CweGjc5gxQgSELC11lmwNDDjqjtIdI 5KahCGAW8WLMiPxi8EmnK1rVrcUDn5qa2XMJZNGfwXkPkOw9d+Y74xO1RFfwFxlyUByyMzy1hXt7W 5LGKq5n9I1uxMOpDGeSAcADny/ZuLxpLERRzOUbGCVlzSXRLZNzzKQ9Vt/JaGCwrqvq/kQ+EyXEig oq8zjn5A==;
Received: from pilt2.tele.no ([2001:700:800::21] helo=[127.0.0.1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from ) id 1kX4gZ-0005Ee-GT; Mon, 26 Oct 2020 16:45:27 +0100
To: Joe Touch , Michael Tuexen 
Cc: "tcpm@ietf.org Extensions" 
References: <9C8105AE-483B-463F-8EBC-D00199974976@lurchi.franken.de> <64E62006-FF20-42E0-83CB-12C622135251@strayalpha.com>
From: Frode Kileng 
Message-ID: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no>
Date: Mon, 26 Oct 2020 16:45:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <64E62006-FF20-42E0-83CB-12C622135251@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2020 15:45:41 -0000

On 26/10/2020 15:24, Joe Touch wrote:
>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen  wrote:
>>
>>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>>>
>>>
>>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>>>>>>
>>>>>> Although maybe not  a "general problem",  a study of MSS middlebox manipluation in  23 European and Asian mobile networks did reveal some issues:
>>>>>>
>>>>>> - 20 of 23 networks always inserts MSS.
>>>> That IS a general problem, FWIW.
>>>>
>>>> Besides being published, it should also be reported to the operators of those networks as violating TCP specs.
>>> Do you mean as in "layering violation" or is it explicitly stated in an RFC that MSS clamping is not allowed.
>> I think we should differentiate two issues:
>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK segement.
>> (b) a middlebox which adds an MSS option, which wasn't there in the SYN/SYN-ACK segment.
> You can if you want; I do not. Both are violations of TCP processing, whose headers aren’t permitted to be altered in flight. Saying it’s for the good of the endpoints doesn’t change the issue that it should be reported and fixed as an error.
>
> If TCP is given an MSS by the other end of a connection and packets don’t get through, it can always lower the segment sizes it sends - the is what PLPMTUD does.

I think there may be other more important fights out there than 
convincing ~90% of the world mobile network operators and their vendors 
that a practice solving potential black-holing and typically improves 
performance should stop because it's a layering violation. For example 
that 2/3rd of the mobile networks I tested have a TCP Proxy and over 70% 
of such networks breaks MPTCP, TFO or ECN.


Regards

Frode Kileng



From nobody Mon Oct 26 09:55:44 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AC03A0D2A for ; Mon, 26 Oct 2020 09:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEAatfZnOWgr for ; Mon, 26 Oct 2020 09:55:42 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCEE3A0D25 for ; Mon, 26 Oct 2020 09:55:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FAKJDNxWafcuQMqcVGxKOyVMHJ2kaAVng4cR9VqLQxI=; b=HWNCOrPT1qGY2jq9IwcUA36VfL v7ioYLAXzPqF6w3VFHSSSLXW+qSTTF0ao4q+d7xX8cMSOZG6HXnYYFHoC6e58ho+RnQcfyVZs5i/h K3dBOaOznm0ljSiFdvs8kVqqiyWHTpuHVZeJt5/MnjuCvFSZgQAfOMjSBxEjPCP/nxa5iz3PY8FLl k2Vv9g6p6eIpI4Kbm0hF9AdpZgLmZeA1EMIkscl19DzB7jvdr7uiSRnCKAZgKcoP1ipYviq8AP/oT B+hR+XTk17sJl5JJQL6Su/fg8vBIuM1DSevpqrXDUnfURtzT9bctxmEqogPW4tYD1gd/XhmvCJFlF oMU4rbhg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59905 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kX5mP-001cHA-Qj; Mon, 26 Oct 2020 12:55:38 -0400
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch 
In-Reply-To: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no>
Date: Mon, 26 Oct 2020 09:55:32 -0700
Cc: Michael Tuexen , "tcpm@ietf.org Extensions" 
Message-Id: <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com>
References: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no>
To: Frode Kileng 
X-Mailer: iPhone Mail (18A8395)
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] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2020 16:55:43 -0000

Given how many of us are using VPNs, it=E2=80=99s a shame they don=E2=80=99t=
 work without this.  I guess users of those nets have to shut down their Sky=
pes and other services over VPNs, because, according to you, it doesn=E2=80=99=
t work.=20

Joe

> On Oct 26, 2020, at 8:46 AM, Frode Kileng  wrote:
>=20
> =EF=BB=BFOn 26/10/2020 15:24, Joe Touch wrote:
>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen  wrote:
>>>=20
>>>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>>>>=20
>>>>=20
>>>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>>>>>>>=20
>>>>>>> Although maybe not  a "general problem",  a study of MSS middlebox m=
anipluation in  23 European and Asian mobile networks did reveal some issues=
:
>>>>>>>=20
>>>>>>> - 20 of 23 networks always inserts MSS.
>>>>> That IS a general problem, FWIW.
>>>>>=20
>>>>> Besides being published, it should also be reported to the operators o=
f those networks as violating TCP specs.
>>>> Do you mean as in "layering violation" or is it explicitly stated in an=
 RFC that MSS clamping is not allowed.
>>> I think we should differentiate two issues:
>>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK segement=
.
>>> (b) a middlebox which adds an MSS option, which wasn't there in the SYN/=
SYN-ACK segment.
>> You can if you want; I do not. Both are violations of TCP processing, who=
se headers aren=E2=80=99t permitted to be altered in flight. Saying it=E2=80=
=99s for the good of the endpoints doesn=E2=80=99t change the issue that it s=
hould be reported and fixed as an error.
>>=20
>> If TCP is given an MSS by the other end of a connection and packets don=E2=
=80=99t get through, it can always lower the segment sizes it sends - the is=
 what PLPMTUD does.
>=20
> I think there may be other more important fights out there than convincing=
 ~90% of the world mobile network operators and their vendors that a practic=
e solving potential black-holing and typically improves performance should s=
top because it's a layering violation. For example that 2/3rd of the mobile n=
etworks I tested have a TCP Proxy and over 70% of such networks breaks MPTCP=
, TFO or ECN.
>=20
>=20
> Regards
>=20
> Frode Kileng
>=20
>=20


From nobody Mon Oct 26 10:32:10 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183FD3A0DE7 for ; Mon, 26 Oct 2020 10:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level: 
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, 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 Y_dxDZRudKUU for ; Mon, 26 Oct 2020 10:32:07 -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 7ACFB3A0DEE for ; Mon, 26 Oct 2020 10:32:06 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id m65so7292995qte.11 for ; Mon, 26 Oct 2020 10:32:06 -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=UTj3nUxbwLoHBcnjduAyKcBG+H2SuUQcSZQX9KOqLsk=; b=fHznu2XH3oyMxJzIPDYGizsxFrhZNGAU4DIr9Nbbht947hHHnHxrz59ufGa1sCFfIv sKKiT4m4KLUhAsJBds3eJ0GXFhd53lTQEaAeqD1fhSoMJCbOobjX9TGDdADwYSO+/RdC zwZl2zX14yUNLf4+mrWx6vcczAR5XHiA0Y6Jq2G5LFhiHkHy2g8pFanJnu90LXzoq4Ag Kj35nsX9XD30IC/m1YcABumZAp5zoDpVtqemQZtL9JdLX6VwSVUMTTkX1H+OHDELUJlK 8gCg++vDNMOYtTzxCLzdWolVwXQ02XpY0P4vkZrphTZFlFRLBMapt1YXH+FcBzc2YevO Pf6w==
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=UTj3nUxbwLoHBcnjduAyKcBG+H2SuUQcSZQX9KOqLsk=; b=TEyehfyuwRxDNyxbv7Sf3+SahLkZla6+ZGJDPCOJXuCGgpt2pJUgXDC5zaEarvs4Dr GG+uMsZtlEDLsxpFI1jQMYmvvhyleOdumuUrzJaAAWt0IucGTl7c8jAJd3mFIBzJpm74 JRfRMEGVK6l2Fd7j+g2WsruWkm1Pwpy26hqvpE2K6Rai4Xdpp8b/Z7QXFAXo6MTUBbhB UDJlqQi8jB5IruvJ5H6LJkliEtx+lTrjlNYWnXY9BpSTwsmgj7cXDw+fYWwwv7lPa7KS UGQ93XiYdvrHtQDVXmmVn1Sf5UygKmlOJBk+O6L5RV+4bMIoNAB2eIlyK/J6xmhVZYkY b6uw==
X-Gm-Message-State: AOAM532fihu+DQwfw+ronZjz4lF32LYWKrFLSZXQCP/y/KqMK+ZYZyOl 8XBV328PhJsylp0Ejcsf8hEu5IV7JGAT2vd6
X-Google-Smtp-Source: ABdhPJyp3hliXiYQ2DnJvGP/BeLjpzxSrVxYVqUcj4i+1X5BXnfPOuMeqcURF94K24A2JdeWjAUqhA==
X-Received: by 2002:ac8:365d:: with SMTP id n29mr18880412qtb.237.1603733525034;  Mon, 26 Oct 2020 10:32:05 -0700 (PDT)
Received: from [192.168.1.114] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id p23sm6867466qkm.126.2020.10.26.10.31.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 10:32:04 -0700 (PDT)
To: Joseph Touch 
Cc: tcpm@ietf.org
References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com>    
From: Wesley Eddy 
Message-ID: <3debd957-0710-a682-b234-71442eec539a@mti-systems.com>
Date: Mon, 26 Oct 2020 13:31:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1E3AFF3FC3D5563BAB8E1F3B"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] A few comments on 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, 26 Oct 2020 17:32:09 -0000

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

On 10/23/2020 5:42 PM, Joseph Touch wrote:
> ...
>
> I’d suggest that 793-bis needs something as follows:
>
>
>    TCP Initial Sequence Numbers are based on a number sequence that 
> monotonically increases until it wraps and wraps infrequently, known 
> loosely as a “clock”. This clock is a 32-bit counter that typically 
> increments at least once every roughly 4ms, although it is neither 
> realtime nor precise, and need not persist across reboots.
>
>    A TCP implementation MUST use a clock-driven selection of initial
>    sequence numbers (MUST-8) as specified above, and SHOULD generate 
> its Initial Sequence
>     Numbers with the expression:
>
Just a nit-pick, but it should be "microseconds" rather than "ms"; 
otherwise, I totally agree there are some good clarifications here.

I'd like to hybridize your recommendation with the more specific 
estimate of the wrapping period into:

    TCP Initial Sequence Numbers are generated from a number sequence
    that monotonically increases until it wraps, known loosely as
    a “clock”. This clock is a 32-bit counter that typically increments
    at least once every roughly 4 microseconds, although it is neither
    assumed to be realtime nor precise, and need not persist across
    reboots.  The clock component is intended to insure that with a
    Maximum Segment Lifetime (MSL), generated ISNs will be unique, since
    it cycles approximately every 4.55 hours, which is much longer than
    the MSL.

    A TCP implementation MUST use a clock-driven selection of
    initialsequence numbers (MUST-8) as specified above, and SHOULD
    generate its Initial Sequence Numbers with the expression:  ...

How does this sound to you?



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


  
    
  
  
    
On 10/23/2020 5:42 PM, Joseph Touch
      wrote:

    

    

      
      ...
      

        


        

        
I’d suggest that 793-bis needs something as
          follows:

        


        

        


        

        
   TCP Initial
                Sequence Numbers are based on a number sequence that
                monotonically increases until it wraps and wraps
                infrequently, known loosely as a “clock”. This clock is
                a 32-bit counter that typically increments at least once
                every roughly 4ms, although it is neither realtime nor
                precise, and need not persist across reboots.

        


          

        
   A TCP implementation
            MUST use a clock-driven selection of initial

             sequence numbers
            (MUST-8) as specified above, and SHOULD generate its Initial
            Sequence

          

            
   Numbers with the expression:


          

          

        

      

    

    
Just a nit-pick, but it should be "microseconds" rather than
      "ms"; otherwise, I totally agree there are some good
      clarifications here.

    

    
I'd like to hybridize your recommendation with the more specific
      estimate of the wrapping period into:

    

      
TCP Initial Sequence Numbers are generated from a
              number sequence that monotonically increases until it
              wraps, known loosely as a “clock”. This clock is a 32-bit
              counter that typically increments at least once every
              roughly 4 microseconds, although it is neither assumed to
              be realtime nor precise, and need not persist across
              reboots.  The clock component is intended to insure that
              with a Maximum Segment Lifetime (MSL), generated ISNs will
              be unique, since it cycles approximately every 4.55 hours,
              which is much longer than the MSL.

      
A TCP
                  implementation MUST use a clock-driven selection of
                  initial sequence numbers
                  (MUST-8) as specified above, and SHOULD generate its
                  Initial Sequence Numbers
          with the expression:  ...

    

    
How does this sound to you?

    


    

  


--------------1E3AFF3FC3D5563BAB8E1F3B--


From nobody Mon Oct 26 10:41:01 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74853A0B60 for ; Mon, 26 Oct 2020 10:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMJGh-OBjObz for ; Mon, 26 Oct 2020 10:40:53 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BB13A0DED for ; Mon, 26 Oct 2020 10:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=scB4pIlZVFjIieqqU7rEOfHBJNo4tsYEAXTBsheWvBs=; b=57vPNM73h9dhYwS2is6LFcF0k I01+GW5i00JNT9j6keS22NtjWZJttN9rj1cHHnN7HvoTGPbRJEYdBDXxhc82NhsHHhrJtHqFSkc4C Zl+WXVtLrYim1um1vyFW+qi730KvvzxmpkLKHmF+AgQxilI7wG7zm6/jKSuweSKWoNf6VKREst3wk yY0s3Q5wkb2R4btTu3hZmSt1KCOFByRO+omqYQOqLhp7C7USqpK/tWsSscEq7iogNhwU0zOdTllic WDjYrfHmOmvey4z1HS1zI4ZzYrs/f8kumrLtV4alR+7R9wsitC+bg0I9gsbiQ8POQ19Fsi2IJJNOC VYH99m0pg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63418 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kX6U9-002Osg-Nt; Mon, 26 Oct 2020 13:40:50 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_762A6E3E-9F82-4A21-830A-6717117AACFD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <3debd957-0710-a682-b234-71442eec539a@mti-systems.com>
Date: Mon, 26 Oct 2020 10:40:44 -0700
Cc: tcpm@ietf.org
Message-Id: 
References: <77B766C3-2895-40AD-82DF-EC318C65B909@strayalpha.com>     <3debd957-0710-a682-b234-71442eec539a@mti-systems.com>
To: Wes Eddy 
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] A few comments on 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, 26 Oct 2020 17:41:00 -0000

--Apple-Mail=_762A6E3E-9F82-4A21-830A-6717117AACFD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Wes,

> On Oct 26, 2020, at 10:31 AM, Wesley Eddy  wrote:
>=20
> On 10/23/2020 5:42 PM, Joseph Touch wrote:
>> ...
>>=20
>> I=E2=80=99d suggest that 793-bis needs something as follows:
>>=20
>>=20
>>    TCP Initial Sequence Numbers are based on a number sequence that =
monotonically increases until it wraps and wraps infrequently, known =
loosely as a =E2=80=9Cclock=E2=80=9D. This clock is a 32-bit counter =
that typically increments at least once every roughly 4ms, although it =
is neither realtime nor precise, and need not persist across reboots.
>>=20
>>    A TCP implementation MUST use a clock-driven selection of initial
>>    sequence numbers (MUST-8) as specified above, and SHOULD generate =
its Initial Sequence
>>    Numbers with the expression:
>>=20
> Just a nit-pick, but it should be "microseconds" rather than "ms"; =
otherwise, I totally agree there are some good clarifications here.
>=20
Agreed (it should have been =E2=80=9Cus=E2=80=9D above).
> I'd like to hybridize your recommendation with the more specific =
estimate of the wrapping period into:
>=20
> TCP Initial Sequence Numbers are generated from a number sequence that =
monotonically increases until it wraps, known loosely as a =E2=80=9Cclock=E2=
=80=9D. This clock is a 32-bit counter that typically increments at =
least once every roughly 4 microseconds, although it is neither assumed =
to be realtime nor precise, and need not persist across reboots.  The =
clock component is intended to insure that with a Maximum Segment =
Lifetime (MSL), generated ISNs will be unique, since it cycles =
approximately every 4.55 hours, which is much longer than the MSL.
>=20
> A TCP implementation MUST use a clock-driven selection of initial =
sequence numbers (MUST-8) as specified above, and SHOULD generate its =
Initial Sequence Numbers with the expression:  ...
>=20
I=E2=80=99d suggest, just to be careful for IoT implementations:

	A TCP implementation MUST use the above type of =E2=80=9Cclock=E2=80=
=9D for clock-driven selection=E2=80=A6

Otherwise, looks good.

Joe=

--Apple-Mail=_762A6E3E-9F82-4A21-830A-6717117AACFD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, =
Wes,

On Oct 26, 2020, at 10:31 AM, Wesley Eddy =
<wes@mti-systems.com> wrote:


 =20
    
 =20
  

    
On 10/23/2020 5:42 PM, Joseph Touch
      wrote:

    

    

      
      ...
      

        


        

        
I=E2=80=99d suggest that 793-bis needs something =
as
          follows:

        


        

        


        

        
   TCP Initial
                Sequence Numbers are based on a number sequence that
                monotonically increases until it wraps and wraps
                infrequently, known loosely as a =E2=80=9Cclock=E2=80=
=9D. This clock is
                a 32-bit counter that typically increments at least once
                every roughly 4ms, although it is neither realtime nor
                precise, and need not persist across =
reboots.

        


          

        
   A TCP =
implementation
            MUST use a clock-driven selection of initial

             sequence =
numbers
            (MUST-8) as specified above, and SHOULD generate its Initial
            Sequence

          

            
   Numbers with =
the expression:


          

          

        

      

    
Just a nit-pick, but it should be =
"microseconds" rather than
      "ms"; otherwise, I totally agree there are some good
      clarifications here.
Agreed (it should have been =
=E2=80=9Cus=E2=80=9D above).

    
I'd like to hybridize your recommendation with the =
more specific
      estimate of the wrapping period into:

    
TCP Initial Sequence Numbers are generated from a
              number sequence that monotonically increases until it
              wraps, known loosely as a =E2=80=9Cclock=E2=80=9D. =
This clock is a 32-bit
              counter that typically increments at least once every
              roughly 4 microseconds, although it is neither assumed to
              be realtime nor precise, and need not persist across
              reboots.  The clock component is intended to insure =
that
              with a Maximum Segment Lifetime (MSL), generated ISNs will
              be unique, since it cycles approximately every 4.55 hours,
              which is much longer than the =
MSL.
A TCP
                  implementation MUST use a clock-driven selection of
                  initial sequence numbers
                  (MUST-8) as specified above, and SHOULD generate its
                  Initial Sequence Numbers
          with the expression:  =
...
I=E2=80=99d =
suggest, just to be careful for IoT implementations:

	A TCP implementation MUST use the =
above type of =E2=80=9Cclock=E2=80=9D for clock-driven =
selection=E2=80=A6

Otherwise, looks =
good.

Joe
=

--Apple-Mail=_762A6E3E-9F82-4A21-830A-6717117AACFD--


From nobody Mon Oct 26 23:35:26 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE78D3A15C8 for ; Mon, 26 Oct 2020 23:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level: 
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=tele.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 BmsTmPrwJak4 for ; Mon, 26 Oct 2020 23:35:21 -0700 (PDT)
Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 2426F3A15EC for ; Mon, 26 Oct 2020 23:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; 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=4lJvQaIGuSSElGjSJy3RVAvRr/M9DiwMXbuuyhuMQOM=; b=aZ4aZahEQct3eM6vP7NGn3CZtW HEseaYeA5y6FKsnGL+bYonqOR93Vx56LnRj2IEFx30BBTiTtRS/wrFp9laF3pmPyt1cwc9SFV5o4S H5VopNDW7MCuDLUE12F4pKkuJoWh+rWLVnZf1W4P0z7IDOTdM4/H0bk2SyGtV3sls06j+q1XIOL1l xKHRc6gnirE1Ecrppx3VGQNcUXWTCTLdux39cVg2dTRvre4sYi+qNIspbpxOVTJhuQ6KncH2Rr3lO mvKDc7Rx+M20tMpSVJmukTBYJ16wACJhT1LUNEv0LE9MveWZHDx7eTx+t9EE6kHeUdnhk2VMoaJHg AoY4FbfQ==;
Received: from pilt2.tele.no ([2001:700:800::21] helo=[127.0.0.1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from ) id 1kXIZb-0005qc-Of; Tue, 27 Oct 2020 07:35:11 +0100
To: Joe Touch 
Cc: Michael Tuexen , "tcpm@ietf.org Extensions" 
References: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no> <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com>
From: Frode Kileng 
Message-ID: <77ae4653-ff07-ae23-aba3-e0660791a2f9@tele.no>
Date: Tue, 27 Oct 2020 07:35:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2020 06:35:24 -0000

I do not defending this practice, just trying to communicate their 
rationale and that there may be other more important fights out there. 
But I do understand that operators are cautious as I've seen an example 
of how fragmentation triggered an anti-DDoS feature in a firewall 
causing traffic from a large number of mobiles to halt.

Frode

On 26/10/2020 17:55, Joe Touch wrote:
> Given how many of us are using VPNs, it’s a shame they don’t work without this.  I guess users of those nets have to shut down their Skypes and other services over VPNs, because, according to you, it doesn’t work.
>
> Joe
>
>> On Oct 26, 2020, at 8:46 AM, Frode Kileng  wrote:
>>
>> On 26/10/2020 15:24, Joe Touch wrote:
>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen  wrote:
>>>>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>>>>>
>>>>>
>>>>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>>>>>>>>
>>>>>>>> Although maybe not  a "general problem",  a study of MSS middlebox manipluation in  23 European and Asian mobile networks did reveal some issues:
>>>>>>>>
>>>>>>>> - 20 of 23 networks always inserts MSS.
>>>>>> That IS a general problem, FWIW.
>>>>>>
>>>>>> Besides being published, it should also be reported to the operators of those networks as violating TCP specs.
>>>>> Do you mean as in "layering violation" or is it explicitly stated in an RFC that MSS clamping is not allowed.
>>>> I think we should differentiate two issues:
>>>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK segement.
>>>> (b) a middlebox which adds an MSS option, which wasn't there in the SYN/SYN-ACK segment.
>>> You can if you want; I do not. Both are violations of TCP processing, whose headers aren’t permitted to be altered in flight. Saying it’s for the good of the endpoints doesn’t change the issue that it should be reported and fixed as an error.
>>>
>>> If TCP is given an MSS by the other end of a connection and packets don’t get through, it can always lower the segment sizes it sends - the is what PLPMTUD does.
>> I think there may be other more important fights out there than convincing ~90% of the world mobile network operators and their vendors that a practice solving potential black-holing and typically improves performance should stop because it's a layering violation. For example that 2/3rd of the mobile networks I tested have a TCP Proxy and over 70% of such networks breaks MPTCP, TFO or ECN.
>>
>>
>> Regards
>>
>> Frode Kileng
>>
>>


From nobody Tue Oct 27 05:35:58 2020
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 57D5B3A0408; Tue, 27 Oct 2020 05:35:52 -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: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <160380215231.12643.15441692678290990557@ietfa.amsl.com>
Date: Tue, 27 Oct 2020 05:35:52 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 27 Oct 2020 12:35:52 -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 (TCP) Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
	Pages           : 109
	Date            : 2020-10-27

Abstract:
   This document specifies the Transmission Control Protocol (TCP).  TCP
   is an important transport layer protocol in the Internet protocol
   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 RFCs 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 also updates RFC
   5961 by adding a small clarification in reset handling while in the
   SYN-RECEIVED state.  The TCP header control bits from RFC 793 have
   also been updated based on RFC 3168.

   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-19
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-19

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


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 Oct 27 06:15:17 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656853A0982 for ; Tue, 27 Oct 2020 06:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 hqzTc4tO471Z for ; Tue, 27 Oct 2020 06:15:14 -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 9832A3A0977 for ; Tue, 27 Oct 2020 06:15:14 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4CLByT0QMLz10D4 for ; Tue, 27 Oct 2020 14:15:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603804513; bh=2r29fFkqJu1BOKF3aJfyaRuRcurcQ8dmFJR0HiWfmMI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dnoE/wcM3a7fYg4r7QrLXWTFsF+GnHCoMcXNgMrEKvZ/Mhu3qLYMeYrR4NAj/FFeu G7qZdvvgM6vEtulTpRarzzOXBYuRuY9d5OT4S59SWXreEJio+3YM9mq/AEGuA5RR+Q 86kDr/eGyhpQrzqyIO4IFCZrtRadqf65JwXlRB8BVJyzkTuJaXipbgjEhhso9um2Ct AATBhwYH4vYo/NkEAcScQBuu5lLsO0FLLfqgmUoy+itcaLx0MDCsqK9Rk/uGqTjJ3r 6Ae0THq9+QL03HKi8lIw3I2mkHNA5f2+NJmiFl08qj8Lp1+ODzcSk3q/iOmi5TjzEi V1+a0oKSjXLEw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4CLByS6p6Bz1xpW for ; Tue, 27 Oct 2020 14:15:12 +0100 (CET)
From: 
To: "tcpm@ietf.org" 
Thread-Topic: I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
Thread-Index: AQHWrF2+rR7y50ISu06goQjQUIz/XKmral1Q
Date: Tue, 27 Oct 2020 13:15:12 +0000
Message-ID: <27267_1603804512_5F981D60_27267_50_6_787AE7BB302AE849A7480A190F8B9330315677AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>
In-Reply-To: <160380215231.12643.15441692678290990557@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-rfc793bis-19.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, 27 Oct 2020 13:15:16 -0000

Hi all,=20

I like the changes. Thank you for taking care of this, Wes.=20

I do still think the MSS part of MUST-4 is redundant with MUST-14 (and othe=
r reco in 3.6.1).=20

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 27 octobre 2020 13:36
> =C0=A0: i-d-announce@ietf.org
> Cc=A0: tcpm@ietf.org
> Objet=A0: I-D Action: draft-ietf-tcpm-rfc793bis-19.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 (TCP)
> Specification
>         Author          : Wesley M. Eddy
> 	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
> 	Pages           : 109
> 	Date            : 2020-10-27
>=20
> Abstract:
>    This document specifies the Transmission Control Protocol (TCP).
> TCP
>    is an important transport layer protocol in the Internet protocol
>    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 RFCs 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 also updates RFC
>    5961 by adding a small clarification in reset handling while in
> the
>    SYN-RECEIVED state.  The TCP header control bits from RFC 793
> have
>    also been updated based on RFC 3168.
>=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
> 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-19
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-19
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-19
>=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
>=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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Tue Oct 27 08:25:31 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642BA3A0E70 for ; Tue, 27 Oct 2020 08:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo2rsYHShtgA for ; Tue, 27 Oct 2020 08:25:26 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1F23A0E6A for ; Tue, 27 Oct 2020 08:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eZgPUb/KDLZofzxVOSjCvzkoVDKpqxsS+UMqLlrqwik=; b=Zj3XTZ5WFJ7oL6MuqWmgIq+QH K8psGiCcVDerSUXEVXmVTANPFZTA0qtN6203dPdcTiFPqm+6AMbr8F/E8ANKu82VpayUu8KgQMkPa T/m7uqCOYKD0B6IMCxLHVoUc02U8v98HgfPXIwReBTYjOIrrRrSF/Gdwcr2ROic7Pp+VluP1PeWEG VHlUvWMzv/a9j1fK+03AlnDjappBVoyjfRpCcIF+s2khLP5+1XrZNZ/UoACd0jXNJer1dzIrlvYNo vs0KVE1comIh3gEkCa91axz6UzdBVZnKDqmN8aFfBTxcxDHvUFQsapi/J/IODVitV6WoFNaWxoHTs s2C99t9mg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64645 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kXQqe-000Q8W-1Z; Tue, 27 Oct 2020 11:25:24 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <77ae4653-ff07-ae23-aba3-e0660791a2f9@tele.no>
Date: Tue, 27 Oct 2020 08:25:19 -0700
Cc: Michael Tuexen , "tcpm@ietf.org Extensions" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no> <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com> <77ae4653-ff07-ae23-aba3-e0660791a2f9@tele.no>
To: Frode Kileng 
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2020 15:25:29 -0000

So the real question is why tunneled packets didn=E2=80=99t trigger the =
same issue - isn=E2=80=99t it?

Or are you implying that tunneled traffic shouldn=E2=80=99t be =
supported?

There are deeper issues going on here. We should avoid being glib about =
how =E2=80=9Cbest=E2=80=9D to do things that shouldn=E2=80=99t be done =
in the first place.

Joe

> On Oct 26, 2020, at 11:35 PM, Frode Kileng  wrote:
>=20
> I do not defending this practice, just trying to communicate their =
rationale and that there may be other more important fights out there. =
But I do understand that operators are cautious as I've seen an example =
of how fragmentation triggered an anti-DDoS feature in a firewall =
causing traffic from a large number of mobiles to halt.
>=20
> Frode
>=20
> On 26/10/2020 17:55, Joe Touch wrote:
>> Given how many of us are using VPNs, it=E2=80=99s a shame they =
don=E2=80=99t work without this.  I guess users of those nets have to =
shut down their Skypes and other services over VPNs, because, according =
to you, it doesn=E2=80=99t work.
>>=20
>> Joe
>>=20
>>> On Oct 26, 2020, at 8:46 AM, Frode Kileng  wrote:
>>>=20
>>> =EF=BB=BFOn 26/10/2020 15:24, Joe Touch wrote:
>>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen =
 wrote:
>>>>>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>>>>>>=20
>>>>>>=20
>>>>>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>>>>>>>>>=20
>>>>>>>>> Although maybe not  a "general problem",  a study of MSS =
middlebox manipluation in  23 European and Asian mobile networks did =
reveal some issues:
>>>>>>>>>=20
>>>>>>>>> - 20 of 23 networks always inserts MSS.
>>>>>>> That IS a general problem, FWIW.
>>>>>>>=20
>>>>>>> Besides being published, it should also be reported to the =
operators of those networks as violating TCP specs.
>>>>>> Do you mean as in "layering violation" or is it explicitly stated =
in an RFC that MSS clamping is not allowed.
>>>>> I think we should differentiate two issues:
>>>>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK =
segement.
>>>>> (b) a middlebox which adds an MSS option, which wasn't there in =
the SYN/SYN-ACK segment.
>>>> You can if you want; I do not. Both are violations of TCP =
processing, whose headers aren=E2=80=99t permitted to be altered in =
flight. Saying it=E2=80=99s for the good of the endpoints doesn=E2=80=99t =
change the issue that it should be reported and fixed as an error.
>>>>=20
>>>> If TCP is given an MSS by the other end of a connection and packets =
don=E2=80=99t get through, it can always lower the segment sizes it =
sends - the is what PLPMTUD does.
>>> I think there may be other more important fights out there than =
convincing ~90% of the world mobile network operators and their vendors =
that a practice solving potential black-holing and typically improves =
performance should stop because it's a layering violation. For example =
that 2/3rd of the mobile networks I tested have a TCP Proxy and over 70% =
of such networks breaks MPTCP, TFO or ECN.
>>>=20
>>>=20
>>> Regards
>>>=20
>>> Frode Kileng
>>>=20
>>>=20
>=20


From nobody Tue Oct 27 11:27:42 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099253A1482; Tue, 27 Oct 2020 11:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHwsRgABYAYj; Tue, 27 Oct 2020 11:27:32 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCFC3A146E; Tue, 27 Oct 2020 11:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g2eBzDw6cTh9OvZn2jFzByO3u+pz+E/6T6KIgz5ZY/s=; b=4s9uR8yFVok3Ts4MV6B1VV4b0 Aok4MN0w1sXVvVndtBDG1WxIe005f2yqCCPYB5XSpsM7trOgXWOM6F99dPILXqI2m7PE27mmc0YgW IntAB32ju4okGklX43wzQFGg5ccK/QPMiXPsRAW1hHmkM7AgyL5KlxVvdIc2XjOeXzc7xTrzv4XWp f+5aHqY7tp5Qbhk8S3gzLnYqryPu6G7pHrT5N66qbP/gwLmz71iUd5BUWTH2yXMjsYa1bmZxoNmAF Oa0ZwYpqnZ15kP3UN6XWzlKtrM5Q3Qh9ZcnHaH4mgLEfmzOyLiwpJMRAT2JBG022HMgCu1bHWT/6G hmouoGOsQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:65535 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kXTgu-003Keo-BS; Tue, 27 Oct 2020 14:27:32 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <160380215231.12643.15441692678290990557@ietfa.amsl.com>
Date: Tue, 27 Oct 2020 11:27:27 -0700
Cc: i-d-announce@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>
To: "Extensions tcpm@ietf.org" 
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 27 Oct 2020 18:27:41 -0000

Looks good to me too, but one question:

The update below that is already in -19 doesn=E2=80=99t include a =
MUST-##. I didn=E2=80=99t know if that was expected, but FYI.

Joe

> On Oct 22, 2020, at 3:47 PM, Joseph Touch  =
wrote:
>=20
> The following text should include a MUST, as shown below:
>=20
>    (all TCP options except End of option list and No-Operation
>     MUST have length fields)

-------

> On Oct 27, 2020, at 5:35 AM, internet-drafts@ietf.org wrote:
>=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 (TCP) =
Specification
>        Author          : Wesley M. Eddy
> 	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
> 	Pages           : 109
> 	Date            : 2020-10-27


From nobody Tue Oct 27 14:51:48 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F713A1455 for ; Tue, 27 Oct 2020 14:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9Qfb92APEwWi for ; Tue, 27 Oct 2020 14:51:43 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFB73A14CC for ; Tue, 27 Oct 2020 14:51:43 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id n5so2898796ile.7 for ; Tue, 27 Oct 2020 14:51:43 -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=U8yXjY2ZRi08e41fr7HLNrkEH4R9UO6qRmMFQarwDCU=; b=rp0x3Q3p2TXA9adoX0kuYIbr9xOrw9xnfBVYNd5YLyjzf5I75n0olI0CX5pVM7k7CL fEIPb+P4KEO/oGmEeZi/dwfefoqCCNY1OWk41mNOcCBUfoqUQwRt+KF5NqT5pe/eI1In /yWYI3CuV/zBdcAYwycflQcufqI8x2oMIKx3N0V8tSF/X7eGthoP7yd/o7cmXu7e+XiW gbmpyRxsg7nR1MiBv0zpQXzs4aUXlUOfJoHY8CM5rSJgC7P491llu270WlKVk2SEierV EKMCj3F7skxALwXF0a+GZDh4lOkG5kRbYUI+7Kmn4Ywh3Nxp9ID/YoPMF6+WmnjE2arw E94w==
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=U8yXjY2ZRi08e41fr7HLNrkEH4R9UO6qRmMFQarwDCU=; b=LAxSoh54pp4Pe5J8iXHvsgziYqK7dTdEV4OQEDWedXA4Ih4qv7/FEi0JOvU7pK6oh5 U6JgQ1lOuNDlfLe5y7qQ51FePzgtFyFrpSfc0k9F/Snm9EtaDpewvKiaPUsGZjUw4Hgg rriDZC76FcStaHmV9D4VVQtRFaisPQImf2vlAbtwn/hmziaSKKrtzCGM9kFIgaAOl7sl BeWIq0P/KRq/3eeOxsO7VT0WF/l2T67KnfcbROeVPIgpu7IbjSNOk0pBK5bgdkL5mzFa pQp0Nukdgb7L8zgViDlfFE5/7F6z0mj6u+c7gyWQmHQZvWJyu7LEsfAqUhs6OiossIrj OCFg==
X-Gm-Message-State: AOAM531woqKHYPWBx9SmLHv1giSH3R2QCKlUWQLxh4JPL3H4BcbJii9J Mu5qu4qwjk4EcqM/5BxnIK6XqkblvXOkBRoRc/CWwfCfZuQ=
X-Google-Smtp-Source: ABdhPJxpYGc2SvQC6snW4nIrFhsqDuWcC6e2ikGj5lHZCSADBeKq+g1bJSE9+VwBH5XRNCkJmPMwZ0A54eUWE6dAGdc=
X-Received: by 2002:a05:6e02:786:: with SMTP id q6mr3663457ils.208.1603835502836;  Tue, 27 Oct 2020 14:51:42 -0700 (PDT)
MIME-Version: 1.0
References: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no> <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com> <77ae4653-ff07-ae23-aba3-e0660791a2f9@tele.no> 
In-Reply-To: 
From: Steven Sommars 
Date: Tue, 27 Oct 2020 16:51:31 -0500
Message-ID: 
To: Joseph Touch 
Cc: Frode Kileng , Michael Tuexen ,  "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="0000000000006cc22c05b2ae0d07"
Archived-At: 
Subject: Re: [tcpm] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2020 21:51:46 -0000

--0000000000006cc22c05b2ae0d07
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Much of today's mobile traffic IP traffic is GTP (GPRS Tunneling protocol)
tunneled within the core network (per the 3GPP specifications).   There can
be one or two back-to-back  bidirectional  tunnels between the base station
and the PGW/GGSN (gateways to the Internet).   The 3GIP IP MTU requirements
weren't very clear at the time, but we interpreted the requirement to be a
1500-byte subscriber IP MTU.     For those portions of the core network
that used IP/ATM (AAL5), transport of a ~1540 byte tunneled packet (IP
MTU + about 40 bytes for GTP/IPv4 header) was  usually provided.   [I'm
using 40 bytes for simplicity, could be smaller or larger.]  Ethernet was
cheaper and more readily available, so transport of 1540 byte packets was
needed.  [I'll skip other headers that are often used: VLAN, MPLS, etc.]
   The cellular carriers often leased IP/Ethernet transport and at times
only ~1500 byte MTUs were available.

If the IP/Ethernet transport network supports sufficiently large IP MTUs,
life is simpler.   If not, how does one stuff 1540 bytes into a 1500 byte
packet?
- Avoid core network IP fragmentation.    I'll list some of the options &
their drawbacks.
        -   Resegment TCP (e.g., proxy).    =3D=3D=3D  many drawbacks
        -   Fragment subscriber packet  (ignore DF bit)    =3D=3D=3D   many
drawbacks
        -   Drop packets that would require fragmentation (PMTUD).  =3D=3D=
=3D
PMTU black hole was an issue
        -   Signal to the subscriber device that the IP MTU should be
reduced.   =3D=3D=3D   This was proposed in 3GPP starting in the late 1990'=
s, but
I don't know what happened.
        -   Insert/Alter TCP MSS option during SYN/ACK.   =3D=3D=3D   Not
strictly legal, but it typically worked well.
- Implement core network IP fragmentation/reassembly.   Done correctly this
is undetectable by the subscriber- or server-side.   However,
        -   Transport network bandwidth requirements increased slightly.
        -    IP reassembly can be resource intensive.    [I've seen
performance drop by over 100x when IP reassembly was needed on some older
hardware.]
        -    IP reassembly may fail.
        -    Fragmentation and reassembly may trigger missequencing.

Is TCPM the right forum for discussing these end-to-end principle related
items?   RFC3234 has a somewhat dated (2002) middlebox taxonomy.





On Tue, Oct 27, 2020 at 10:25 AM Joseph Touch  wrote:

> So the real question is why tunneled packets didn=E2=80=99t trigger the s=
ame issue
> - isn=E2=80=99t it?
>
> Or are you implying that tunneled traffic shouldn=E2=80=99t be supported?
>
> There are deeper issues going on here. We should avoid being glib about
> how =E2=80=9Cbest=E2=80=9D to do things that shouldn=E2=80=99t be done in=
 the first place.
>
> Joe
>
> > On Oct 26, 2020, at 11:35 PM, Frode Kileng  wrote:
> >
> > I do not defending this practice, just trying to communicate their
> rationale and that there may be other more important fights out there. Bu=
t
> I do understand that operators are cautious as I've seen an example of ho=
w
> fragmentation triggered an anti-DDoS feature in a firewall causing traffi=
c
> from a large number of mobiles to halt.
> >
> > Frode
> >
> > On 26/10/2020 17:55, Joe Touch wrote:
> >> Given how many of us are using VPNs, it=E2=80=99s a shame they don=E2=
=80=99t work
> without this.  I guess users of those nets have to shut down their Skypes
> and other services over VPNs, because, according to you, it doesn=E2=80=
=99t work.
> >>
> >> Joe
> >>
> >>> On Oct 26, 2020, at 8:46 AM, Frode Kileng  wrote:
> >>>
> >>> =EF=BB=BFOn 26/10/2020 15:24, Joe Touch wrote:
> >>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen <
> Michael.Tuexen@lurchi.franken.de> wrote:
> >>>>>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 23/10/2020 17:11, Joseph Touch wrote:
> >>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng  > wrote:
> >>>>>>>>>
> >>>>>>>>> Although maybe not  a "general problem",  a study of MSS
> middlebox manipluation in  23 European and Asian mobile networks did reve=
al
> some issues:
> >>>>>>>>>
> >>>>>>>>> - 20 of 23 networks always inserts MSS.
> >>>>>>> That IS a general problem, FWIW.
> >>>>>>>
> >>>>>>> Besides being published, it should also be reported to the
> operators of those networks as violating TCP specs.
> >>>>>> Do you mean as in "layering violation" or is it explicitly stated
> in an RFC that MSS clamping is not allowed.
> >>>>> I think we should differentiate two issues:
> >>>>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK
> segement.
> >>>>> (b) a middlebox which adds an MSS option, which wasn't there in the
> SYN/SYN-ACK segment.
> >>>> You can if you want; I do not. Both are violations of TCP processing=
,
> whose headers aren=E2=80=99t permitted to be altered in flight. Saying it=
=E2=80=99s for the
> good of the endpoints doesn=E2=80=99t change the issue that it should be =
reported
> and fixed as an error.
> >>>>
> >>>> If TCP is given an MSS by the other end of a connection and packets
> don=E2=80=99t get through, it can always lower the segment sizes it sends=
 - the is
> what PLPMTUD does.
> >>> I think there may be other more important fights out there than
> convincing ~90% of the world mobile network operators and their vendors
> that a practice solving potential black-holing and typically improves
> performance should stop because it's a layering violation. For example th=
at
> 2/3rd of the mobile networks I tested have a TCP Proxy and over 70% of su=
ch
> networks breaks MPTCP, TFO or ECN.
> >>>
> >>>
> >>> Regards
> >>>
> >>> Frode Kileng
> >>>
> >>>
> >
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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


Much of today's mobile traffic IP traffic is GTP (GPRS=
 Tunneling protocol) tunneled within the core network (per the 3GPP specifi=
cations).=C2=A0 =C2=A0There can be one or two back-to-back=C2=A0 bidirectio=
nal=C2=A0 tunnels between the base station and the  PGW/GGSN (gateways to t=
he Internet).=C2=A0 =C2=A0The 3GIP IP MTU requirements weren't very cle=
ar at the time, but we interpreted the requirement to be a 1500-byte subscr=
iber IP MTU.=C2=A0 =C2=A0 =C2=A0For those portions of the core network that=
 used IP/ATM (AAL5), transport of a ~1540 byte tunneled packet (IP MTU=C2=
=A0+ about 40 bytes for GTP/IPv4 header) was=C2=A0 usually provided.=C2=A0 =
=C2=A0[I'm using 40 bytes for simplicity, could be smaller or larger.]=
=C2=A0 Ethernet was cheaper and more readily available, so transport of 154=
0 byte packets was needed.=C2=A0 [I'll skip other headers that are ofte=
n used: VLAN, MPLS, etc.]=C2=A0 =C2=A0 =C2=A0 =C2=A0The cellular carriers o=
ften leased IP/Ethernet transport and at times only ~1500 byte MTUs were av=
ailable.=C2=A0=C2=A0

If the IP/Ethernet transport networ=
k supports sufficiently large IP MTUs, life is simpler.=C2=A0 =C2=A0If not,=
 how does one stuff 1540 bytes into a 1500 byte packet?=C2=A0 =C2=A0
<=
div>- Avoid core network IP fragmentation.=C2=A0 =C2=A0

I'll list some of the options & their drawbacks.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0Resegment TCP (e.g., p=
roxy).=C2=A0 =C2=A0 =3D=3D=3D=C2=A0 many drawbacks
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 -=C2=A0 =C2=A0Fragment subscriber packet=C2=A0 (ignore DF bit=
)=C2=A0 =C2=A0 =3D=3D=3D=C2=A0 =C2=A0many drawbacks
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 -=C2=A0 =C2=A0Drop packets that would require fragmentation =
(PMTUD).=C2=A0 =3D=3D=3D=C2=A0 PMTU black hole was an issue
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0Signal to the subscriber device that=
 the IP MTU should be reduced.=C2=A0 =C2=A0=3D=3D=3D=C2=A0 =C2=A0This was p=
roposed in 3GPP starting in the late 1990's, but I don't know what =
happened.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0Insert/Alter =
TCP MSS option during SYN/ACK.=C2=A0 =C2=A0=3D=3D=3D=C2=A0 =C2=A0Not strict=
ly legal, but it typically worked well.
- Implement core network =
IP fragmentation/reassembly.=C2=A0 =C2=A0Done correctly this is undetectabl=
e by the subscriber- or server-side.=C2=A0 =C2=A0However,
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0Transport network bandwidth requirements=
 increased slightly.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 I=
P reassembly can be resource intensive.=C2=A0 =C2=A0 [I've seen perform=
ance drop by over 100x when IP reassembly was needed on some older hardware=
.]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 IP reassembly may f=
ail.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 Fragmentation and=
 reassembly may trigger missequencing.
=C2=A0
Is TCPM t=
he right forum for discussing these end-to-end principle related items?=C2=
=A0 =C2=A0RFC3234 has a somewhat dated (2002) middlebox taxonomy.





On Tue, Oct 27, 202=
0 at 10:25 AM Joseph Touch <touc=
h@strayalpha.com> wrote:
So the real question is why tunneled packets didn=E2=80=99t=
 trigger the same issue - isn=E2=80=99t it?



Or are you implying that tunneled traffic shouldn=E2=80=99t be supported?


There are deeper issues going on here. We should avoid being glib about how=
 =E2=80=9Cbest=E2=80=9D to do things that shouldn=E2=80=99t be done in the =
first place.



Joe



> On Oct 26, 2020, at 11:35 PM, Frode Kileng <frodek@tele.no> wrote:

> 

> I do not defending this practice, just trying to communicate their rat=
ionale and that there may be other more important fights out there. But I d=
o understand that operators are cautious as I've seen an example of how=
 fragmentation triggered an anti-DDoS feature in a firewall causing traffic=
 from a large number of mobiles to halt.

> 

> Frode

> 

> On 26/10/2020 17:55, Joe Touch wrote:

>> Given how many of us are using VPNs, it=E2=80=99s a shame they don=
=E2=80=99t work without this.=C2=A0 I guess users of those nets have to shu=
t down their Skypes and other services over VPNs, because, according to you=
, it doesn=E2=80=99t work.

>> 

>> Joe

>> 

>>> On Oct 26, 2020, at 8:46 AM, Frode Kileng <frodek@tele.no> wrote:

>>> 

>>> =EF=BB=BFOn 26/10/2020 15:24, Joe Touch wrote:

>>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen <Michael=
.Tuexen@lurchi.franken.de> wrote:

>>>>>> On 26. Oct 2020, at 08:52, Frode Kileng <frodek@tele.no> wrote:=


>>>>>> 

>>>>>> 

>>>>>> On 23/10/2020 17:11, Joseph Touch wrote:

>>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kil=
eng <frodek@tele.no<=
/a> <mailto:frodek@t=
ele.no>> wrote:

>>>>>>>>> 

>>>>>>>>> Although maybe not=C2=A0 a "gener=
al problem",=C2=A0 a study of MSS middlebox manipluation in=C2=A0 23 E=
uropean and Asian mobile networks did reveal some issues:

>>>>>>>>> 

>>>>>>>>> - 20 of 23 networks always inserts MSS=
.

>>>>>>> That IS a general problem, FWIW.

>>>>>>> 

>>>>>>> Besides being published, it should also be rep=
orted to the operators of those networks as violating TCP specs.

>>>>>> Do you mean as in "layering violation" o=
r is it explicitly stated in an RFC that MSS clamping is not allowed.

>>>>> I think we should differentiate two issues:

>>>>> (a) a middlebox which reduces the MSS already in an SY=
N/SYN-ACK segement.

>>>>> (b) a middlebox which adds an MSS option, which wasn&#=
39;t there in the SYN/SYN-ACK segment.

>>>> You can if you want; I do not. Both are violations of TCP =
processing, whose headers aren=E2=80=99t permitted to be altered in flight.=
 Saying it=E2=80=99s for the good of the endpoints doesn=E2=80=99t change t=
he issue that it should be reported and fixed as an error.

>>>> 

>>>> If TCP is given an MSS by the other end of a connection an=
d packets don=E2=80=99t get through, it can always lower the segment sizes =
it sends - the is what PLPMTUD does.

>>> I think there may be other more important fights out there tha=
n convincing ~90% of the world mobile network operators and their vendors t=
hat a practice solving potential black-holing and typically improves perfor=
mance should stop because it's a layering violation. For example that 2=
/3rd of the mobile networks I tested have a TCP Proxy and over 70% of such =
networks breaks MPTCP, TFO or ECN.

>>> 

>>> 

>>> Regards

>>> 

>>> Frode Kileng

>>> 

>>> 

> 



_______________________________________________

tcpm mailing list

tcpm@ietf.org

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




--0000000000006cc22c05b2ae0d07--


From nobody Tue Oct 27 15:28:26 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402753A15A6 for ; Tue, 27 Oct 2020 15:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.317
X-Spam-Level: 
X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am7v0IWFBW2g for ; Tue, 27 Oct 2020 15:28:20 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D99C3A15C4 for ; Tue, 27 Oct 2020 15:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uEqIxL0kOTiTJ0s4Hb4RWU+4fdJk3vgHE8s9rS2G534=; b=M0af0rDBOktlkhECdAHF7gA0xs 2RR6CRav5ps4lY2J37Lw+BZ9u1qzz+wEfl1tOEq2cw6KNeVjqCncOyxAM5zLqgfTEyEr9V5VY6Ekx gc3A4VGzm5fnWoEXiWvsfHtC7ekaW5x2/YZQiJfJ/moNDw9Vb9zi8cjvn59sL2Utu33wWzF51IAHj W2QZ+M+JxMxIZjuyoTZXb+gQn43/Dg0W1er/vEgTCEoTGK0vkhxcMXF8dX+3Gis3/EfB9lDtQPsgU yXO9n5xXuxXTBaPMYWjPVy+Et9cJxa2Y+uvFtZbDmHhDpC9D7pPyFA4N6yrLpc/oP7L8favbr9Dyg Gx08poHA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62233 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kXXRs-002nny-21; Tue, 27 Oct 2020 18:28:17 -0400
Content-Type: multipart/alternative; boundary=Apple-Mail-0F796794-1CFD-4135-A968-B9F3ABBE5587
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Joe Touch 
In-Reply-To: 
Date: Tue, 27 Oct 2020 15:28:11 -0700
Cc: Michael Tuexen , "tcpm@ietf.org Extensions" 
Message-Id: <1CDD590A-83D0-4F96-9354-F66653D3CA12@strayalpha.com>
References: 
To: Steven Sommars 
X-Mailer: iPhone Mail (18A8395)
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] Exceeding value in MSS option?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2020 22:28:22 -0000

--Apple-Mail-0F796794-1CFD-4135-A968-B9F3ABBE5587
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

These issues have been addressed at length in intarea and tsvwg. It wouldn=E2=
=80=99t hurt if the end systems used PLPMTUD, but fragmentation support in G=
RE and other tunnels is also supported.=20

Ultimately, if you tunnel and cannot guarantee end system cooperation, frag/=
reassembly is on you.=20

Joe

> On Oct 27, 2020, at 2:52 PM, Steven Sommars  wr=
ote:
>=20
> =EF=BB=BF
> Much of today's mobile traffic IP traffic is GTP (GPRS Tunneling protocol)=
 tunneled within the core network (per the 3GPP specifications).   There can=
 be one or two back-to-back  bidirectional  tunnels between the base station=
 and the PGW/GGSN (gateways to the Internet).   The 3GIP IP MTU requirements=
 weren't very clear at the time, but we interpreted the requirement to be a 1=
500-byte subscriber IP MTU.     For those portions of the core network that u=
sed IP/ATM (AAL5), transport of a ~1540 byte tunneled packet (IP MTU + about=
 40 bytes for GTP/IPv4 header) was  usually provided.   [I'm using 40 bytes f=
or simplicity, could be smaller or larger.]  Ethernet was cheaper and more r=
eadily available, so transport of 1540 byte packets was needed.  [I'll skip o=
ther headers that are often used: VLAN, MPLS, etc.]       The cellular carri=
ers often leased IP/Ethernet transport and at times only ~1500 byte MTUs wer=
e available. =20
>=20
> If the IP/Ethernet transport network supports sufficiently large IP MTUs, l=
ife is simpler.   If not, how does one stuff 1540 bytes into a 1500 byte pac=
ket?  =20
> - Avoid core network IP fragmentation.    I'll list some of the options & t=
heir drawbacks.
>         -   Resegment TCP (e.g., proxy).    =3D=3D=3D  many drawbacks
>         -   Fragment subscriber packet  (ignore DF bit)    =3D=3D=3D   man=
y drawbacks
>         -   Drop packets that would require fragmentation (PMTUD).  =3D=3D=
=3D  PMTU black hole was an issue
>         -   Signal to the subscriber device that the IP MTU should be redu=
ced.   =3D=3D=3D   This was proposed in 3GPP starting in the late 1990's, bu=
t I don't know what happened.
>         -   Insert/Alter TCP MSS option during SYN/ACK.   =3D=3D=3D   Not s=
trictly legal, but it typically worked well.
> - Implement core network IP fragmentation/reassembly.   Done correctly thi=
s is undetectable by the subscriber- or server-side.   However,
>         -   Transport network bandwidth requirements increased slightly.
>         -    IP reassembly can be resource intensive.    [I've seen perfor=
mance drop by over 100x when IP reassembly was needed on some older hardware=
.]
>         -    IP reassembly may fail.
>         -    Fragmentation and reassembly may trigger missequencing.
> =20
> Is TCPM the right forum for discussing these end-to-end principle related i=
tems?   RFC3234 has a somewhat dated (2002) middlebox taxonomy.
>=20
>=20
>=20
>=20
>=20
>> On Tue, Oct 27, 2020 at 10:25 AM Joseph Touch  wrot=
e:
>> So the real question is why tunneled packets didn=E2=80=99t trigger the s=
ame issue - isn=E2=80=99t it?
>>=20
>> Or are you implying that tunneled traffic shouldn=E2=80=99t be supported?=

>>=20
>> There are deeper issues going on here. We should avoid being glib about h=
ow =E2=80=9Cbest=E2=80=9D to do things that shouldn=E2=80=99t be done in the=
 first place.
>>=20
>> Joe
>>=20
>> > On Oct 26, 2020, at 11:35 PM, Frode Kileng  wrote:
>> >=20
>> > I do not defending this practice, just trying to communicate their rati=
onale and that there may be other more important fights out there. But I do u=
nderstand that operators are cautious as I've seen an example of how fragmen=
tation triggered an anti-DDoS feature in a firewall causing traffic from a l=
arge number of mobiles to halt.
>> >=20
>> > Frode
>> >=20
>> > On 26/10/2020 17:55, Joe Touch wrote:
>> >> Given how many of us are using VPNs, it=E2=80=99s a shame they don=E2=80=
=99t work without this.  I guess users of those nets have to shut down their=
 Skypes and other services over VPNs, because, according to you, it doesn=E2=
=80=99t work.
>> >>=20
>> >> Joe
>> >>=20
>> >>> On Oct 26, 2020, at 8:46 AM, Frode Kileng  wrote:
>> >>>=20
>> >>> =EF=BB=BFOn 26/10/2020 15:24, Joe Touch wrote:
>> >>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen  wrote:
>> >>>>>> On 26. Oct 2020, at 08:52, Frode Kileng  wrote:
>> >>>>>>=20
>> >>>>>>=20
>> >>>>>> On 23/10/2020 17:11, Joseph Touch wrote:
>> >>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng > wrote:
>> >>>>>>>>>=20
>> >>>>>>>>> Although maybe not  a "general problem",  a study of MSS middle=
box manipluation in  23 European and Asian mobile networks did reveal some i=
ssues:
>> >>>>>>>>>=20
>> >>>>>>>>> - 20 of 23 networks always inserts MSS.
>> >>>>>>> That IS a general problem, FWIW.
>> >>>>>>>=20
>> >>>>>>> Besides being published, it should also be reported to the operat=
ors of those networks as violating TCP specs.
>> >>>>>> Do you mean as in "layering violation" or is it explicitly stated i=
n an RFC that MSS clamping is not allowed.
>> >>>>> I think we should differentiate two issues:
>> >>>>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK seg=
ement.
>> >>>>> (b) a middlebox which adds an MSS option, which wasn't there in the=
 SYN/SYN-ACK segment.
>> >>>> You can if you want; I do not. Both are violations of TCP processing=
, whose headers aren=E2=80=99t permitted to be altered in flight. Saying it=E2=
=80=99s for the good of the endpoints doesn=E2=80=99t change the issue that i=
t should be reported and fixed as an error.
>> >>>>=20
>> >>>> If TCP is given an MSS by the other end of a connection and packets d=
on=E2=80=99t get through, it can always lower the segment sizes it sends - t=
he is what PLPMTUD does.
>> >>> I think there may be other more important fights out there than convi=
ncing ~90% of the world mobile network operators and their vendors that a pr=
actice solving potential black-holing and typically improves performance sho=
uld stop because it's a layering violation. For example that 2/3rd of the mo=
bile networks I tested have a TCP Proxy and over 70% of such networks breaks=
 MPTCP, TFO or ECN.
>> >>>=20
>> >>>=20
>> >>> Regards
>> >>>=20
>> >>> Frode Kileng
>> >>>=20
>> >>>=20
>> >=20
>>=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-0F796794-1CFD-4135-A968-B9F3ABBE5587
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


These issues have been add=
ressed at length in intarea and tsvwg. It wouldn=E2=80=99t hurt if the end s=
ystems used PLPMTUD, but fragmentation support in GRE and other tunnels is a=
lso supported. 

Ultima=
tely, if you tunnel and cannot guarantee end system cooperation, frag/reasse=
mbly is on you. 

Joe

On Oct 27, 2020, at 2:52 P=
M, Steven Sommars <stevesommarsntp@gmail.com> wrote:

=EF=BB=BF
Much of today's mobile traffic IP traffic is GTP (GPRS Tunneling protocol)=
 tunneled within the core network (per the 3GPP specifications).   =
;There can be one or two back-to-back  bidirectional  tunnels betw=
een the base station and the  PGW/GGSN (gateways to the Internet).  &nb=
sp;The 3GIP IP MTU requirements weren't very clear at the time, but we inter=
preted the requirement to be a 1500-byte subscriber IP MTU.    &nb=
sp;For those portions of the core network that used IP/ATM (AAL5), transport=
 of a ~1540 byte tunneled packet (IP MTU + about 40 bytes for GTP/IPv4 h=
eader) was  usually provided.   [I'm using 40 bytes for simpl=
icity, could be smaller or larger.]  Ethernet was cheaper and more read=
ily available, so transport of 1540 byte packets was needed.  [I'll ski=
p other headers that are often used: VLAN, MPLS, etc.]      &=
nbsp;The cellular carriers often leased IP/Ethernet transport and at times o=
nly ~1500 byte MTUs were available.  

If the IP=
/Ethernet transport network supports sufficiently large IP MTUs, life is sim=
pler.   If not, how does one stuff 1540 bytes into a 1500 byte pac=
ket?   
- Avoid core network IP fragmentation.  &nb=
sp;

I'll list some of the options & their drawbacks.


        -   Resegment TCP (e.g., pr=
oxy).    =3D=3D=3D  many drawbacks
    &n=
bsp;   -   Fragment subscriber packet  (ignore DF bit)&n=
bsp;   =3D=3D=3D   many drawbacks
    &nb=
sp;   -   Drop packets that would require fragmentation (PMTU=
D).  =3D=3D=3D  PMTU black hole was an issue
  &nbs=
p;     -   Signal to the subscriber device that the IP M=
TU should be reduced.   =3D=3D=3D   This was proposed in=
 3GPP starting in the late 1990's, but I don't know what happened.
        -   Insert/Alter TCP MSS option durin=
g SYN/ACK.   =3D=3D=3D   Not strictly legal, but it typi=
cally worked well.
- Implement core network IP fragmentation/reass=
embly.   Done correctly this is undetectable by the subscriber- or=
 server-side.   However,
        -&n=
bsp;  Transport network bandwidth requirements increased slightly.
        -    IP reassembly can be resour=
ce intensive.    [I've seen performance drop by over 100x when IP r=
eassembly was needed on some older hardware.]
     =
   -    IP reassembly may fail.
     =
;   -    Fragmentation and reassembly may trigger missequenci=
ng.
 
Is TCPM the right forum for discussing these e=
nd-to-end principle related items?   RFC3234 has a somewhat dated (=
2002) middlebox taxonomy.



<=
br>

On Tue, Oct 27, 2020 at 10:25 AM Joseph Touch <touch@strayalpha.com> wrote:
So the real question is why tun=
neled packets didn=E2=80=99t trigger the same issue - isn=E2=80=99t it?



Or are you implying that tunneled traffic shouldn=E2=80=99t be supported?


There are deeper issues going on here. We should avoid being glib about how =E2=
=80=9Cbest=E2=80=9D to do things that shouldn=E2=80=99t be done in the first=
 place.



Joe



> On Oct 26, 2020, at 11:35 PM, Frode Kileng <frodek@tele.no> wrote:

> 

> I do not defending this practice, just trying to communicate their rati=
onale and that there may be other more important fights out there. But I do u=
nderstand that operators are cautious as I've seen an example of how fragmen=
tation triggered an anti-DDoS feature in a firewall causing traffic from a l=
arge number of mobiles to halt.

> 

> Frode

> 

> On 26/10/2020 17:55, Joe Touch wrote:

>> Given how many of us are using VPNs, it=E2=80=99s a shame they don=E2=
=80=99t work without this.  I guess users of those nets have to shut do=
wn their Skypes and other services over VPNs, because, according to you, it d=
oesn=E2=80=99t work.

>> 

>> Joe

>> 

>>> On Oct 26, 2020, at 8:46 AM, Frode Kileng <frodek@tele.no> wrote:

>>> 

>>> =EF=BB=BFOn 26/10/2020 15:24, Joe Touch wrote:

>>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen <Michael.Tu=
exen@lurchi.franken.de> wrote:

>>>>>> On 26. Oct 2020, at 08:52, Frode Kileng <frodek@tele.no> wrote:
>>>>>> 

>>>>>> 

>>>>>> On 23/10/2020 17:11, Joseph Touch wrote:

>>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kile=
ng <frodek@tele.no <mailto:frodek@tele=
.no>> wrote:

>>>>>>>>> 

>>>>>>>>> Although maybe not  a "general pro=
blem",  a study of MSS middlebox manipluation in  23 European and A=
sian mobile networks did reveal some issues:

>>>>>>>>> 

>>>>>>>>> - 20 of 23 networks always inserts MSS.=


>>>>>>> That IS a general problem, FWIW.

>>>>>>> 

>>>>>>> Besides being published, it should also be repo=
rted to the operators of those networks as violating TCP specs.

>>>>>> Do you mean as in "layering violation" or is it exp=
licitly stated in an RFC that MSS clamping is not allowed.

>>>>> I think we should differentiate two issues:

>>>>> (a) a middlebox which reduces the MSS already in an SYN=
/SYN-ACK segement.

>>>>> (b) a middlebox which adds an MSS option, which wasn't t=
here in the SYN/SYN-ACK segment.

>>>> You can if you want; I do not. Both are violations of TCP p=
rocessing, whose headers aren=E2=80=99t permitted to be altered in flight. S=
aying it=E2=80=99s for the good of the endpoints doesn=E2=80=99t change the i=
ssue that it should be reported and fixed as an error.

>>>> 

>>>> If TCP is given an MSS by the other end of a connection and=
 packets don=E2=80=99t get through, it can always lower the segment sizes it=
 sends - the is what PLPMTUD does.

>>> I think there may be other more important fights out there than=
 convincing ~90% of the world mobile network operators and their vendors tha=
t a practice solving potential black-holing and typically improves performan=
ce should stop because it's a layering violation. For example that 2/3rd of t=
he mobile networks I tested have a TCP Proxy and over 70% of such networks b=
reaks MPTCP, TFO or ECN.

>>> 

>>> 

>>> Regards

>>> 

>>> Frode Kileng

>>> 

>>> 

> 



_______________________________________________

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-0F796794-1CFD-4135-A968-B9F3ABBE5587--


From nobody Tue Oct 27 16:01:01 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5F3A03C9 for ; Tue, 27 Oct 2020 16:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level: 
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.247, 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 DrVAOxFX3RyR for ; Tue, 27 Oct 2020 16:00:58 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 5FF3D3A03F2 for ; Tue, 27 Oct 2020 16:00:58 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id j129so2925406qke.5 for ; Tue, 27 Oct 2020 16:00:58 -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=b0NGy4JyxMqDPEZdRUctcE4HzF8giEQlmzmyHC/i/jo=; b=a1WOa4yd2YtU09j+zZmDf+Af+r+fKOAVjOqlKoaJh51lIi9rhbEfdzuTWeswGGCXR0 oTx5lczCcMBE4z/bz46XO0bSLPOEejfH1OOzByLg2Hnu57nWbbWBEnagt35bTPPLHYG2 AN+P1dWeEBYcLJTZ+4oY6Izmnw2X21f6FISO7OlI0gvlgje0jtlMdftG/2qMdHtgb3ZN 7lDdQL1/rMZvEEfgSUKfKL4xW+kliKpgZKBMnt361Qqt8m4MKuX4iqvlGUBsUSJFMx4d dE1bRrjywu8LPKIgoHMSFZkyqRrf3TLO24qdKJ0oxf0h7S140cnc3yW1UbZgEo9YxeEQ oeiQ==
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=b0NGy4JyxMqDPEZdRUctcE4HzF8giEQlmzmyHC/i/jo=; b=iaV7ioNLBL7jVY2zSPMrusuCdclUJjBFzav1DQ+J0F3adwxrr6g7Fbni7vIef21LRu MwbM/6YBv4I+xJoi5QQf1rBQ0y4lHzfDO1fYD6u86f4OpIR7fbDthivhaGikaHC9d8do PuWOOxOQjkaitrzV22dQ18ApmCTb1eoPiMqi3CJ0YOvjKuxstCm5bOeYS4jWhgsDIs96 FMrkC2d3D6x31CPRJBH2iKVsW1GuZtS/z3/Ou73UkDxJ/CqeJKGmv7XQ7w3VdvTlhWlE gKusPWb6CfoyTL43T+HScO+6XHgUvrySOsWWbggyLZY78baEUodO/DBY3l4X1pKUh/Mw cm7g==
X-Gm-Message-State: AOAM531Rmj05hwNVeH6uK5VZPPB3HrcsZXSzU/to2jK8c97ntxIlVehC cZNYjepvtI1KYIMCaQ6ov3aAQh7IBN+I0Tz3
X-Google-Smtp-Source: ABdhPJx9rpDO2HuLtse+5zvqjcxHHMf6rW60iVguTKTATOOx4p38wIXs5+op+RlUD2jPI1ghS6Q7eQ==
X-Received: by 2002:a37:68d0:: with SMTP id d199mr4807635qkc.408.1603839656867;  Tue, 27 Oct 2020 16:00:56 -0700 (PDT)
Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id 79sm1755627qkl.42.2020.10.27.16.00.55 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 16:00:55 -0700 (PDT)
To: tcpm@ietf.org
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com> 
From: Wesley Eddy 
Message-ID: <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com>
Date: Tue, 27 Oct 2020 19:00:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 27 Oct 2020 23:01:00 -0000

I meant to explain this one to the list, but was side-tracked earlier, 
and you've beat me to it :)

When adding that text, I'd noticed that the "MUST" is applicable to 
other specs that define options (saying they need to include the length 
field), but isn't exactly something that you would check an 
implementation against for conformance (since it would just implement 
the options as properly specified).

If people think it makes sense to number it and add to the checklist, 
that's totally fine with me, but it didn't seem very meaningful.


On 10/27/2020 2:27 PM, Joseph Touch wrote:
> Looks good to me too, but one question:
>
> The update below that is already in -19 doesn’t include a MUST-##. I didn’t know if that was expected, but FYI.
>
> Joe
>
>> On Oct 22, 2020, at 3:47 PM, Joseph Touch  wrote:
>>
>> The following text should include a MUST, as shown below:
>>
>>     (all TCP options except End of option list and No-Operation
>>      MUST have length fields)
> -------
>
>> On Oct 27, 2020, at 5:35 AM, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>>
>>         Title           : Transmission Control Protocol (TCP) Specification
>>         Author          : Wesley M. Eddy
>> 	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
>> 	Pages           : 109
>> 	Date            : 2020-10-27
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Tue Oct 27 16:11:20 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57643A0407 for ; Tue, 27 Oct 2020 16:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level: 
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.247, 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 TxHQ8RidJBBn for ; Tue, 27 Oct 2020 16:11:17 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 30B753A005F for ; Tue, 27 Oct 2020 16:11:17 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id p45so2191865qtb.5 for ; Tue, 27 Oct 2020 16:11:17 -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=3veVRPoXy6OIEJv7pYpMRIsGFgSuOPQi/P+h+9mLfJQ=; b=hoWK/py6nrMhFi4hPRMVZ48K3rXy0W9QIFbTrjjhSu4cVFbvAJoB2918KqexeH1V8i qSFFp/zFonqkuGGL7zMEud/86XNUzElCa5Vj7lO2NBQtVcHuLhve4QcTbRa6sYCWjuvW PXZ1PgSqmGNJM1/lKE8k+ZyX/3sR8AidLYhAsTH/XLCs2a4GXcrG3rnBoGGtehaMRFFY h/FCp3nS6YvQZqlzu3sXkGq2flF5LuOU8v/QdhV54ZC14pDSQ4a4IucayvNbcWgbsL6Q x87dyFRwT2EAqkn+EikTf7HnUgXqy+Bj2uiR+6eJglX8CK54r1Z6/LC2locEK6nuwgpT KKzA==
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=3veVRPoXy6OIEJv7pYpMRIsGFgSuOPQi/P+h+9mLfJQ=; b=cTEZrtJvKL3hyw/goEcEuwHvVJ8rL5rJox0wju8xnTT/VSi1ktQoSy5VHO3FOakbeT /5k7PL+WcD4//Y4oLTwHrIOEYLUbC1XkUDNW6msSPEuMD66CD/XHqYKC/hC8jDn9R3u8 tsZ9DR1yB3QL8s7JObkyzwj3PWEdTe7iOt3z+sDITpc+h8JjFfuaeEgIHZ3Xj5XWmuGk ECDChRjJiUt/b45udu1Ui5pv7IGJ8ry9tGa8XQ1q38WAfxkKvctLgJTW4U1mGRc0O782 lGzz5fmvMLqvATOno2pcn5wvnBW+E7bfgMuHMgnfIb4D8m7xN0gQYAar4h7OtnRe5T3c Uq1w==
X-Gm-Message-State: AOAM531hE0A0PKo6aEIa1ab86QKAA0xRnDA6bd/bPSo+ciGiOzsgt0ZO RiSa8tBYKRcrzLyZ9l8HVJRUNE/BGgWMO9Wk
X-Google-Smtp-Source: ABdhPJyfUL8hs10bSk8olOlegxLEhswjK2YUjreNYAWq4xtSyMZPifajlwGlF0a1pLKSrFrD608xpA==
X-Received: by 2002:aed:2ba6:: with SMTP id e35mr4685684qtd.251.1603840275753;  Tue, 27 Oct 2020 16:11:15 -0700 (PDT)
Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id 6sm1747632qtz.31.2020.10.27.16.11.12 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 16:11:15 -0700 (PDT)
To: tcpm@ietf.org
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com> <27267_1603804512_5F981D60_27267_50_6_787AE7BB302AE849A7480A190F8B9330315677AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Wesley Eddy 
Message-ID: <162ca4c0-5501-a905-8e0f-b90bb0b2cf33@mti-systems.com>
Date: Tue, 27 Oct 2020 19:11:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <27267_1603804512_5F981D60_27267_50_6_787AE7BB302AE849A7480A190F8B9330315677AB@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] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 27 Oct 2020 23:11:19 -0000

On 10/27/2020 9:15 AM, mohamed.boucadair@orange.com wrote:
> Hi all,
>
> I like the changes. Thank you for taking care of this, Wes.
>
> I do still think the MSS part of MUST-4 is redundant with MUST-14 (and other reco in 3.6.1).

I agree those seem redundant.  For reference, one is saying the 
mandatory option set must be supported, and another is saying that 
sending and receiving the MSS option must be supported.  MSS is one of 
the mandatory options, so this is just something more specific that's 
implied by supporting the mandatory set.

If people think this is a problem, I'm happy to de-duplicate these 
(though renumbering doesn't seem like it will be a very fun editing task!).



From nobody Tue Oct 27 23:25:05 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6583A0FC9 for ; Tue, 27 Oct 2020 23:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 u9nX1VNpBNnU for ; Tue, 27 Oct 2020 23:25:02 -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 6BC433A0FC7 for ; Tue, 27 Oct 2020 23:25:02 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 4CLdpj02trz4wl5;  Wed, 28 Oct 2020 07:25:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603866301; bh=wlvtVanhKaHW/rml9A2DMLhhZhG7XF7d5ahu8MHeIYE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LgyPqEi6IIX3AGszARqQ3C737ZOhdog16+MEMiwxG9uZozVV9h9v0NeZtvhFbXBEo ohr3BlF/sg8nmSWj1yT8xAWeEBl4nfb/OzHsXLJV0mDTdVJtd3dAuRI/K1AuPyJPSw Y4CEui/ZkaOBqkEFDLCyeq7Bf+++E3ycVIFWu1EPhX/o+sD8+9hkQYhfM54U6lBrDi cZSmtR+U1IVX/QPp26AsgWCz4azjLZQIi7/cjoO6w4CmPreKveORtB1lS/qV/PeK0A 9BmmQ6WRsMaxckyuQ/7kVVPij5ndndszuzSLfrHALRbtbCgZ7QULiz3KHSohcxVn6u ITAys9VxUpjRg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4CLdph6CZNzDq7Y;  Wed, 28 Oct 2020 07:25:00 +0100 (CET)
From: 
To: Wesley Eddy , "tcpm@ietf.org" 
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
Thread-Index: AQHWrLZz4DcCwHBZTU+FXpMnRm2g/amsiqQw
Date: Wed, 28 Oct 2020 06:25:00 +0000
Message-ID: <22249_1603866300_5F990EBC_22249_74_1_787AE7BB302AE849A7480A190F8B9330315680CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com> <27267_1603804512_5F981D60_27267_50_6_787AE7BB302AE849A7480A190F8B9330315677AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <162ca4c0-5501-a905-8e0f-b90bb0b2cf33@mti-systems.com>
In-Reply-To: <162ca4c0-5501-a905-8e0f-b90bb0b2cf33@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 28 Oct 2020 06:25:04 -0000

SGkgV2VzLCANCg0KV2hhdCBpcyBtZWFudCBieSAiTVNTIHN1cHBvcnQiIGlzIGFjdHVhbGx5IHdo
YXQgaXMgc3BlY2lmaWVkIGluIDMuNi4xLiANCg0KT25lIHdheSB0byBhdm9pZCB0cm91YmxlcyB3
aXRoIHJlbnVtYmVyaW5nIGlzIHRvIGFkZCBhIHBvaW50ZXIgdG8gc2VjdGlvbiAzLjYuMSByaWdo
dCBhZnRlciBNVVNULTQgdG8gc3RhdGUgdGhpcy4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t
TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2Vz
QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFdlc2xleSBFZGR5DQo+IEVudm95w6nCoDogbWVyY3Jl
ZGkgMjggb2N0b2JyZSAyMDIwIDAwOjExDQo+IMOAwqA6IHRjcG1AaWV0Zi5vcmcNCj4gT2JqZXTC
oDogUmU6IFt0Y3BtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE5LnR4
dA0KPiANCj4gT24gMTAvMjcvMjAyMCA5OjE1IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu
Y29tIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IEkgbGlrZSB0aGUgY2hhbmdlcy4gVGhh
bmsgeW91IGZvciB0YWtpbmcgY2FyZSBvZiB0aGlzLCBXZXMuDQo+ID4NCj4gPiBJIGRvIHN0aWxs
IHRoaW5rIHRoZSBNU1MgcGFydCBvZiBNVVNULTQgaXMgcmVkdW5kYW50IHdpdGggTVVTVC0xNA0K
PiAoYW5kIG90aGVyIHJlY28gaW4gMy42LjEpLg0KPiANCj4gSSBhZ3JlZSB0aG9zZSBzZWVtIHJl
ZHVuZGFudC7CoCBGb3IgcmVmZXJlbmNlLCBvbmUgaXMgc2F5aW5nIHRoZQ0KPiBtYW5kYXRvcnkg
b3B0aW9uIHNldCBtdXN0IGJlIHN1cHBvcnRlZCwgYW5kIGFub3RoZXIgaXMgc2F5aW5nIHRoYXQN
Cj4gc2VuZGluZyBhbmQgcmVjZWl2aW5nIHRoZSBNU1Mgb3B0aW9uIG11c3QgYmUgc3VwcG9ydGVk
LsKgIE1TUyBpcyBvbmUNCj4gb2YgdGhlIG1hbmRhdG9yeSBvcHRpb25zLCBzbyB0aGlzIGlzIGp1
c3Qgc29tZXRoaW5nIG1vcmUgc3BlY2lmaWMNCj4gdGhhdCdzIGltcGxpZWQgYnkgc3VwcG9ydGlu
ZyB0aGUgbWFuZGF0b3J5IHNldC4NCj4gDQo+IElmIHBlb3BsZSB0aGluayB0aGlzIGlzIGEgcHJv
YmxlbSwgSSdtIGhhcHB5IHRvIGRlLWR1cGxpY2F0ZSB0aGVzZQ0KPiAodGhvdWdoIHJlbnVtYmVy
aW5nIGRvZXNuJ3Qgc2VlbSBsaWtlIGl0IHdpbGwgYmUgYSB2ZXJ5IGZ1biBlZGl0aW5nDQo+IHRh
c2shKS4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug
ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj
b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy
ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91
cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph
IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz
LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0
aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg
ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp
bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg
YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg
c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt
YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo
YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK


From nobody Wed Oct 28 00:12:05 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D1D3A101A for ; Wed, 28 Oct 2020 00:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 UR4lo4lFndC8 for ; Wed, 28 Oct 2020 00:12:03 -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 2A82F3A1019 for ; Wed, 28 Oct 2020 00:12:03 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4CLfrx5Mz8z1ykt; Wed, 28 Oct 2020 08:12:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603869121; bh=uZHsiqYlkOBeQcJ39Nufu4hxzlUrdqyaGoGeGxaQ6RQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=a+ubC+JLSnNKZQy87ESoRejjW30ULbUObWNSLKREMwQRRFbNW4j3UY+etHpNlcQnO 9lSwu72dBzihkeIwvWLJiFZ6Ko5MS420+7AbV3pKHp+PqwbUrsWCigzmPFw7QlS83e +QHTri4bsRnc6mUucFK+hiejBW0mc2GNw0PUKM9FtmcIT6njt0NpPrLitc4miUwiz4 VmL1TokuWhc2lBWHjNzldXSwBTVOog4hN88Y+h7KDEx7lyZ0a546sGgJDkYq0SMQmo UkVVpMQloZEBoFRo/r+5HXRHIFpI1dmTf68zYXoF3jYz5YuT/mgdPiJmfvyfd9oN+X YFJ3CYFsStDcQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4CLfrx4hQxz1xpB; Wed, 28 Oct 2020 08:12:01 +0100 (CET)
From: 
To: Wesley Eddy , "tcpm@ietf.org" 
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
Thread-Index: AQHWrI8Q4DcCwHBZTU+FXpMnRm2g/amsACkAgACXg+A=
Date: Wed, 28 Oct 2020 07:12:01 +0000
Message-ID: <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com>
In-Reply-To: <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 28 Oct 2020 07:12:05 -0000

UmUtLA0KDQpJIGFncmVlIHdpdGggV2VzIHRoYXQgdGhpcyBvbmUgZG9lcyBub3QgbmVlZCB0byBi
ZSBudW1iZXJlZC4gSSB3b3VsZCBldmVuIHJlbW92ZSB0aGF0IHNlbnRlbmNlIGFzIHRoZSBzcGVj
cyBkZWZpbmluZyB0aGUgb3B0aW9ucyB3aWxsIGNhbGwgb3V0IHRoZSBsZWdhbCBsZW5ndGguIA0K
DQpJZiB0aGUgdGV4dCBpcyBtYWludGFpbmVkLCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIHNob3Vs
ZCBiZSByZW1vdmVkIGZvciB0aGUgaW50ZXJuYWwgY29uc2lzdGVuY3kgb2YgdGhlIGRvY3VtZW50
Og0KDQo9PQ0KICAgRWFjaCB1c2Ugb2YgUkZDIDIxMTkga2V5d29yZHMgaW4gdGhlIGRvY3VtZW50
IGlzIGluZGl2aWR1YWxseSBsYWJlbGxlZA0KICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e
Xl5eDQogICBhbmQgcmVmZXJlbmNlZCBpbiBBcHBlbmRpeCBCIHRoYXQgc3VtbWFyaXplcyBpbXBs
ZW1lbnRhdGlvbg0KICAgcmVxdWlyZW1lbnRzLg0KPT0NCg0KT0xEOg0KKGFsbCBUQ1Agb3B0aW9u
cyBleGNlcHQgRW5kIG9mIG9wdGlvbiBsaXN0IGFuZCBOby1PcGVyYXRpb24NCiAgICAgTVVTVCBo
YXZlIGxlbmd0aCBmaWVsZHMpDQoNCk5FVzoNCihhbGwgVENQIG9wdGlvbnMgZXhjZXB0IEVuZCBv
ZiBvcHRpb24gbGlzdCBhbmQgTm8tT3BlcmF0aW9uDQogICAgIGhhdmUgbGVuZ3RoIGZpZWxkcykN
Cg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6
IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgV2VzbGV5
IEVkZHkNCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAyOCBvY3RvYnJlIDIwMjAgMDA6MDENCj4gw4DC
oDogdGNwbUBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtdGNwbS1yZmM3OTNiaXMtMTkudHh0DQo+IA0KPiBJIG1lYW50IHRvIGV4cGxhaW4gdGhp
cyBvbmUgdG8gdGhlIGxpc3QsIGJ1dCB3YXMgc2lkZS10cmFja2VkDQo+IGVhcmxpZXIsIGFuZCB5
b3UndmUgYmVhdCBtZSB0byBpdCA6KQ0KPiANCj4gV2hlbiBhZGRpbmcgdGhhdCB0ZXh0LCBJJ2Qg
bm90aWNlZCB0aGF0IHRoZSAiTVVTVCIgaXMgYXBwbGljYWJsZSB0bw0KPiBvdGhlciBzcGVjcyB0
aGF0IGRlZmluZSBvcHRpb25zIChzYXlpbmcgdGhleSBuZWVkIHRvIGluY2x1ZGUgdGhlDQo+IGxl
bmd0aCBmaWVsZCksIGJ1dCBpc24ndCBleGFjdGx5IHNvbWV0aGluZyB0aGF0IHlvdSB3b3VsZCBj
aGVjayBhbg0KPiBpbXBsZW1lbnRhdGlvbiBhZ2FpbnN0IGZvciBjb25mb3JtYW5jZSAoc2luY2Ug
aXQgd291bGQganVzdA0KPiBpbXBsZW1lbnQgdGhlIG9wdGlvbnMgYXMgcHJvcGVybHkgc3BlY2lm
aWVkKS4NCj4gDQo+IElmIHBlb3BsZSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBudW1iZXIgaXQg
YW5kIGFkZCB0byB0aGUNCj4gY2hlY2tsaXN0LCB0aGF0J3MgdG90YWxseSBmaW5lIHdpdGggbWUs
IGJ1dCBpdCBkaWRuJ3Qgc2VlbSB2ZXJ5DQo+IG1lYW5pbmdmdWwuDQo+IA0KPiANCj4gT24gMTAv
MjcvMjAyMCAyOjI3IFBNLCBKb3NlcGggVG91Y2ggd3JvdGU6DQo+ID4gTG9va3MgZ29vZCB0byBt
ZSB0b28sIGJ1dCBvbmUgcXVlc3Rpb246DQo+ID4NCj4gPiBUaGUgdXBkYXRlIGJlbG93IHRoYXQg
aXMgYWxyZWFkeSBpbiAtMTkgZG9lc27igJl0IGluY2x1ZGUgYSBNVVNULSMjLg0KPiBJIGRpZG7i
gJl0IGtub3cgaWYgdGhhdCB3YXMgZXhwZWN0ZWQsIGJ1dCBGWUkuDQo+ID4NCj4gPiBKb2UNCj4g
Pg0KPiA+PiBPbiBPY3QgMjIsIDIwMjAsIGF0IDM6NDcgUE0sIEpvc2VwaCBUb3VjaCA8dG91Y2hA
c3RyYXlhbHBoYS5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+PiBUaGUgZm9sbG93aW5nIHRleHQg
c2hvdWxkIGluY2x1ZGUgYSBNVVNULCBhcyBzaG93biBiZWxvdzoNCj4gPj4NCj4gPj4gICAgIChh
bGwgVENQIG9wdGlvbnMgZXhjZXB0IEVuZCBvZiBvcHRpb24gbGlzdCBhbmQgTm8tT3BlcmF0aW9u
DQo+ID4+ICAgICAgTVVTVCBoYXZlIGxlbmd0aCBmaWVsZHMpDQo+ID4gLS0tLS0tLQ0KPiA+DQo+
ID4+IE9uIE9jdCAyNywgMjAyMCwgYXQgNTozNSBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
IHdyb3RlOg0KPiA+Pg0KPiA+Pg0KPiA+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi
bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC0NCj4gRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+
PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUQ1AgTWFpbnRlbmFuY2UgYW5kIE1p
bm9yDQo+IEV4dGVuc2lvbnMgV0cgb2YgdGhlIElFVEYuDQo+ID4+DQo+ID4+ICAgICAgICAgVGl0
bGUgICAgICAgICAgIDogVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wgKFRDUCkNCj4gU3Bl
Y2lmaWNhdGlvbg0KPiA+PiAgICAgICAgIEF1dGhvciAgICAgICAgICA6IFdlc2xleSBNLiBFZGR5
DQo+ID4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE5LnR4
dA0KPiA+PiAJUGFnZXMgICAgICAgICAgIDogMTA5DQo+ID4+IAlEYXRlICAgICAgICAgICAgOiAy
MDIwLTEwLTI3DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0
DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by90Y3BtDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu
dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll
ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl
IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz
IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl
c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp
ZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu
IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl
Y3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp
ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug
aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n
ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=


From nobody Wed Oct 28 05:10:57 2020
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 593593A005F; Wed, 28 Oct 2020 05:10:52 -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: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <160388705230.8906.502159472425535763@ietfa.amsl.com>
Date: Wed, 28 Oct 2020 05:10:52 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-06.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2020 12:10:52 -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-06.txt
	Pages           : 46
	Date            : 2020-10-28

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-06
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-06

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


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

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



From nobody Wed Oct 28 05:47:37 2020
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 D21543A0A82; Wed, 28 Oct 2020 05:47:31 -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: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <160388925181.18695.7892567372446756190@ietfa.amsl.com>
Date: Wed, 28 Oct 2020 05:47:31 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2020 12:47:32 -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-12.txt
	Pages           : 58
	Date            : 2020-10-28

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 a 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.  The resulting extra space is exploited to feed back the IP-
   ECN field received during the 3-way handshake as well.  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-12
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-12

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


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

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



From nobody Wed Oct 28 06:03:38 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619563A0F61 for ; Wed, 28 Oct 2020 06:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level: 
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_FAIL=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 So7MsK7hy1MH for ; Wed, 28 Oct 2020 06:03:34 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 511253A0F2E for ; Wed, 28 Oct 2020 06:03:34 -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:Cc:From:References: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=vbGVdDrf1KnLUHqj5K7/71A7p/cvxU1MF0c+wwmY/AE=; b=TJFD0yJ11D/XSngqdFh/IT9L7d IGrhh6/WEwQK1sCO2rIVvyvlBI1vmo5ymrNYMSwCiyAXYXYfCwXCZryA25pWY2d9xZGvgRbP3r21C taajuy+W52XMhyk4kAS10gAI6qglWswvd9Y7gN8vwHaArNKf9ZRt3o7hDJ/KOlQIqkn9InNDW8lOU 5PkbScajaNo2hFT0inRTpUMCvSlcMfW1dJGP70LlXnISwViGAlL9V4IuidZXCr/4Li6PFV2pSC9rN vDUkGkILwlJl9hjgvYUzv5TBGWbYa0/It5vFh2BXZt2E4Z679F3UNQyuN2Z/wXH/bkwPmejwBiZOO b4UIw/Pw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:49088 helo=[192.168.1.3]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kXl6y-00DTFq-Ae; Wed, 28 Oct 2020 13:03:32 +0000
To: tcpm@ietf.org
References: <160388925181.18695.7892567372446756190@ietfa.amsl.com>
From: Bob Briscoe 
Cc: Mirja Kuehlewind , "Scheffenegger, Richard" 
Message-ID: <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net>
Date: Wed, 28 Oct 2020 13:03:31 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <160388925181.18695.7892567372446756190@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
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: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.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, 28 Oct 2020 13:03:36 -0000

TCPM folks,

Back in May'20, it was decided to hold back the AccECN (and the ECN++) 
drafts for a while until the position on L4S in tsvwg was clearer. There 
is no formal dependency on the L4S drafts in tsvwg, but it made sense 
not to burn codepoints without more certainty.

I've just refreshed the AccECN and the ECN++ drafts, which had expired.

I included the following minor changes to AccECN, which you can see via 
the diff link below, but in summary:
* moved wrongly categorized "action if unwilling to provide f/b" to the 
group of bullets relevant to the receiver
* removed refs to long-expired ecn-fallback draft
* fixed table 1 after xml2rfc changed formatting

Thanks to those who pointed these out.

No changes to ECN++ other than update of some refs.

Cheers


Bob

On 28/10/2020 12:47, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>
>          Title           : More Accurate ECN Feedback in TCP
>          Authors         : Bob Briscoe
>                            Mirja Kühlewind
>                            Richard Scheffenegger
> 	Filename        : draft-ietf-tcpm-accurate-ecn-12.txt
> 	Pages           : 58
> 	Date            : 2020-10-28
>
> 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 a 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.  The resulting extra space is exploited to feed back the IP-
>     ECN field received during the 3-way handshake as well.  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-12
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-12
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
                PRIVILEGED AND CONFIDENTIAL


From nobody Wed Oct 28 08:14:18 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C0A3A0A4F for ; Wed, 28 Oct 2020 08:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUJvhmPfEFsv for ; Wed, 28 Oct 2020 08:14:15 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E227E3A0858 for ; Wed, 28 Oct 2020 08:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TirPX3mQK8vXCx1dx2WaWcHJsnq4TagYGMRhziGXSDM=; b=z31VZUbJHbLqPDHjEaHj5ggxb TYiVI+kqUxILfNkSXUupQTcCAe3zjF/jvJ9ThFtPAnzV0nyDEhFaw47qFeDe+XRPpCDNtZcIsr5jC w/FUdc1NSvcYlIJzD+NXQJYMTjbbCSFuooHefZ7BLL48lwg660A4pV12iEgd8vfIEKduyMLZwlU1o DtVdWIQcvQxt+zRTZx7h1P/XA/tyVG204MIbWou9YDbDPZtGi44+ybQavrL9m/alDbq5ElWNfIdXP QFn6ucSeDApjU50ZaWEhE/QYG4JA4CzkZsKMVJvrhwlb513MR7xARAJ+sDVWNjLYYMZja9vKFB7b0 lIT5srHwQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49813 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kXn9O-000ryF-6p; Wed, 28 Oct 2020 11:14:15 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 28 Oct 2020 08:14:09 -0700
Cc: Wes Eddy , "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-0.2
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] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 28 Oct 2020 15:14:18 -0000

FWIW, here=E2=80=99s the issue:

- TCP relies on the fact that ALL *new* options MUST include the length =
field.

That=E2=80=99s a design constraint on extensions. It=E2=80=99s not =
merely asserted when each new option is defined.

If that requirement is not established, then TCP has *no way* to know =
how many bytes to jump over in a SYN to ignore options it does not =
support.

So this document absolutely needs this requirement - perhaps reworded to =
be more clear that ONLY the options defined herein with fixed length can =
omit that field.

Joe

> On Oct 28, 2020, at 12:12 AM, mohamed.boucadair@orange.com wrote:
>=20
> Re-,
>=20
> I agree with Wes that this one does not need to be numbered. I would =
even remove that sentence as the specs defining the options will call =
out the legal length.=20
>=20
> If the text is maintained, the normative language should be removed =
for the internal consistency of the document:
>=20
> =3D=3D
>   Each use of RFC 2119 keywords in the document is individually =
labelled
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   and referenced in Appendix B that summarizes implementation
>   requirements.
> =3D=3D
>=20
> OLD:
> (all TCP options except End of option list and No-Operation
>     MUST have length fields)
>=20
> NEW:
> (all TCP options except End of option list and No-Operation
>     have length fields)
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Wesley Eddy
>> Envoy=C3=A9 : mercredi 28 octobre 2020 00:01
>> =C3=80 : tcpm@ietf.org
>> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
>>=20
>> I meant to explain this one to the list, but was side-tracked
>> earlier, and you've beat me to it :)
>>=20
>> When adding that text, I'd noticed that the "MUST" is applicable to
>> other specs that define options (saying they need to include the
>> length field), but isn't exactly something that you would check an
>> implementation against for conformance (since it would just
>> implement the options as properly specified).
>>=20
>> If people think it makes sense to number it and add to the
>> checklist, that's totally fine with me, but it didn't seem very
>> meaningful.
>>=20
>>=20
>> On 10/27/2020 2:27 PM, Joseph Touch wrote:
>>> Looks good to me too, but one question:
>>>=20
>>> The update below that is already in -19 doesn=E2=80=99t include a =
MUST-##.
>> I didn=E2=80=99t know if that was expected, but FYI.
>>>=20
>>> Joe
>>>=20
>>>> On Oct 22, 2020, at 3:47 PM, Joseph Touch 
>> wrote:
>>>>=20
>>>> The following text should include a MUST, as shown below:
>>>>=20
>>>>    (all TCP options except End of option list and No-Operation
>>>>     MUST have length fields)
>>> -------
>>>=20
>>>> On Oct 27, 2020, at 5:35 AM, internet-drafts@ietf.org wrote:
>>>>=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 (TCP)
>> Specification
>>>>        Author          : Wesley M. Eddy
>>>> 	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
>>>> 	Pages           : 109
>>>> 	Date            : 2020-10-27
>>> _______________________________________________
>>> 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
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Wed Oct 28 08:56:04 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425173A03FA for ; Wed, 28 Oct 2020 08:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 frcBK_c_hjMr for ; Wed, 28 Oct 2020 08:56:00 -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 253603A03F4 for ; Wed, 28 Oct 2020 08:55:59 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3C62A25A12; Wed, 28 Oct 2020 16:55:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603900558; bh=Sd+ggwKtE4TT3VhfqX40X/s96OZgELfQdJWqKiQTP78=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=fSGVlkWtvOpf02MoLKjtHIDb1tSU9masCLh57lsqwSPlOINL4iIUd7u8BwGcvJtvk t8rzIB5osQCyoTpZDD7pcxMhDdjNz7+oxgmeV/kw4Bp4k0AA6ghwrPzIG0CCMMOJTP zh4XjejIxeaDnRlfTKWVoGzdYl4ZR5yBUkhvE8qk=
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 WL1OO9ihO6CS; Wed, 28 Oct 2020 16:55:57 +0100 (CET)
Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 28 Oct 2020 16:55:57 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 28 Oct 2020 16:55:56 +0100
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Wed, 28 Oct 2020 16:55:56 +0100
From: "Scharf, Michael" 
To: Bob Briscoe , "tcpm@ietf.org" 
CC: "Scheffenegger, Richard" , "Mirja Kuehlewind" 
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
Thread-Index: AQHWrSirbyhXzTEgHki+65A0IwlFJqms6mOAgAA0Y5A=
Date: Wed, 28 Oct 2020 15:55:56 +0000
Message-ID: <3c8de57b23994824b6c51cf5d7fba7ec@hs-esslingen.de>
References: <160388925181.18695.7892567372446756190@ietfa.amsl.com> <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net>
In-Reply-To: <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.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, 28 Oct 2020 15:56:03 -0000

SGkgQm9iLA0KDQpXaGF0IGlzIHRoZSBmdXR1cmUgcGxhbiByZWdhcmRpbmcgdGhlIG9wdGlvbiBl
bmNvZGluZyBwcm9wb3NlZCBieSB0aGUgYXV0aG9ycz8NCg0KVGhpcyBoYXMgYmVlbiBkaXNjdXNz
ZWQgaW4gcGFzdCBtZWV0aW5ncyBhbmQgb24gdGhlIGxpc3QsIGZvciBpbnN0YW5jZTogaHR0cHM6
Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90Y3BtL3pvLTFPUjBuUmZoSG9jWDh5dlR2
cEM0Qk5Nby8NCg0KSSBoYXZlIGV4cGxhaW5lZCBzZXZlcmFsIHRpbWVzIG15IHB1c2hiYWNrIGFn
YWluc3QgdGhlIGVuY29kaW5nIGN1cnJlbnRseSBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LCBt
b3N0IG5vdGFibHkgdGhlIHJlcXVpcmVtZW50IHRvIGtlZXAgc3RhdGUgaW4gdGhlIGVuZHBvaW50
cyB0byBkZWNvZGUgdGhlIGZvcm1hdCBvZiBhIFRDUCBvcHRpb24uIEkgaGF2ZSBub3QgY2hhbmdl
ZCBteSBtaW5kLg0KDQpJIGhhdmUgYWxzbyBtZW50aW9uZWQgdGhhdCwgZm9yIGluc3RhbmNlLCB0
d28gb3B0aW9uIGNvZGVwb2ludHMgd291bGQgSU1ITyBiZSBhIGJldHRlciBlbmdpbmVlcmluZyBh
cHByb2FjaCAoIktJU1MgcHJpbmNpcGxlIikuIFRoYXQgd291bGQgYmUgYSB2ZXJ5IHNpbXBsZSBj
aGFuZ2UgdG8gdGhlIGNvbnRlbnQgdG8gdGhlIGRvY3VtZW50LiBOZWVkbGVzcyB0byBzYXkgdGhh
dCB0aGVyZSBhcmUgb3RoZXIgYWx0ZXJuYXRpdmVzIGZvciBtYXJzaGFsbGluZyBwYXJhbWV0ZXJz
IGluIGFuIHVuYW1iaWdvdXMgd2F5Lg0KDQpUaGVyZSBoYXZlIGJlZW4gb3RoZXIgcmVsYXRlZCBj
b21tZW50cywgZS5nLiBmcm9tIElscG8uDQoNCkJlc3QgcmVnYXJkcw0KDQpNaWNoYWVsICh3aXRo
IG5vIGhhdCkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0Y3BtIDx0
Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCb2IgQnJpc2NvZQ0KPiBTZW50OiBX
ZWRuZXNkYXksIE9jdG9iZXIgMjgsIDIwMjAgMjowNCBQTQ0KPiBUbzogdGNwbUBpZXRmLm9yZw0K
PiBDYzogU2NoZWZmZW5lZ2dlciwgUmljaGFyZCA8UmljaGFyZC5TY2hlZmZlbmVnZ2VyQG5ldGFw
cC5jb20+OyBNaXJqYQ0KPiBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0Pg0KPiBTdWJq
ZWN0OiBSZTogW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24t
MTIudHh0DQo+IA0KPiBUQ1BNIGZvbGtzLA0KPiANCj4gQmFjayBpbiBNYXknMjAsIGl0IHdhcyBk
ZWNpZGVkIHRvIGhvbGQgYmFjayB0aGUgQWNjRUNOIChhbmQgdGhlIEVDTisrKQ0KPiBkcmFmdHMg
Zm9yIGEgd2hpbGUgdW50aWwgdGhlIHBvc2l0aW9uIG9uIEw0UyBpbiB0c3Z3ZyB3YXMgY2xlYXJl
ci4gVGhlcmUNCj4gaXMgbm8gZm9ybWFsIGRlcGVuZGVuY3kgb24gdGhlIEw0UyBkcmFmdHMgaW4g
dHN2d2csIGJ1dCBpdCBtYWRlIHNlbnNlDQo+IG5vdCB0byBidXJuIGNvZGVwb2ludHMgd2l0aG91
dCBtb3JlIGNlcnRhaW50eS4NCj4gDQo+IEkndmUganVzdCByZWZyZXNoZWQgdGhlIEFjY0VDTiBh
bmQgdGhlIEVDTisrIGRyYWZ0cywgd2hpY2ggaGFkIGV4cGlyZWQuDQo+IA0KPiBJIGluY2x1ZGVk
IHRoZSBmb2xsb3dpbmcgbWlub3IgY2hhbmdlcyB0byBBY2NFQ04sIHdoaWNoIHlvdSBjYW4gc2Vl
IHZpYQ0KPiB0aGUgZGlmZiBsaW5rIGJlbG93LCBidXQgaW4gc3VtbWFyeToNCj4gKiBtb3ZlZCB3
cm9uZ2x5IGNhdGVnb3JpemVkICJhY3Rpb24gaWYgdW53aWxsaW5nIHRvIHByb3ZpZGUgZi9iIiB0
byB0aGUNCj4gZ3JvdXAgb2YgYnVsbGV0cyByZWxldmFudCB0byB0aGUgcmVjZWl2ZXINCj4gKiBy
ZW1vdmVkIHJlZnMgdG8gbG9uZy1leHBpcmVkIGVjbi1mYWxsYmFjayBkcmFmdA0KPiAqIGZpeGVk
IHRhYmxlIDEgYWZ0ZXIgeG1sMnJmYyBjaGFuZ2VkIGZvcm1hdHRpbmcNCj4gDQo+IFRoYW5rcyB0
byB0aG9zZSB3aG8gcG9pbnRlZCB0aGVzZSBvdXQuDQo+IA0KPiBObyBjaGFuZ2VzIHRvIEVDTisr
IG90aGVyIHRoYW4gdXBkYXRlIG9mIHNvbWUgcmVmcy4NCj4gDQo+IENoZWVycw0KPiANCj4gDQo+
IEJvYg0KPiANCj4gT24gMjgvMTAvMjAyMCAxMjo0NywgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
IHdyb3RlOg0KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv
bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlzIGEg
d29yayBpdGVtIG9mIHRoZSBUQ1AgTWFpbnRlbmFuY2UgYW5kIE1pbm9yIEV4dGVuc2lvbnMgV0cg
b2YNCj4gdGhlIElFVEYuDQo+ID4NCj4gPiAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNb3Jl
IEFjY3VyYXRlIEVDTiBGZWVkYmFjayBpbiBUQ1ANCj4gPiAgICAgICAgICBBdXRob3JzICAgICAg
ICAgOiBCb2IgQnJpc2NvZQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pcmphIEvD
vGhsZXdpbmQNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSaWNoYXJkIFNjaGVmZmVu
ZWdnZXINCj4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVj
bi0xMi50eHQNCj4gPiAJUGFnZXMgICAgICAgICAgIDogNTgNCj4gPiAJRGF0ZSAgICAgICAgICAg
IDogMjAyMC0xMC0yOA0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgIEV4cGxpY2l0IENvbmdl
c3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIGlzIGEgbWVjaGFuaXNtIHdoZXJlIG5ldHdvcmsNCj4g
PiAgICAgbm9kZXMgY2FuIG1hcmsgSVAgcGFja2V0cyBpbnN0ZWFkIG9mIGRyb3BwaW5nIHRoZW0g
dG8gaW5kaWNhdGUNCj4gPiAgICAgaW5jaXBpZW50IGNvbmdlc3Rpb24gdG8gdGhlIGVuZC1wb2lu
dHMuICBSZWNlaXZlcnMgd2l0aCBhbiBFQ04tDQo+ID4gICAgIGNhcGFibGUgdHJhbnNwb3J0IHBy
b3RvY29sIGZlZWQgYmFjayB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBzZW5kZXIuDQo+ID4gICAg
IEVDTiBpcyBzcGVjaWZpZWQgZm9yIFRDUCBpbiBzdWNoIGEgd2F5IHRoYXQgb25seSBvbmUgZmVl
ZGJhY2sgc2lnbmFsDQo+ID4gICAgIGNhbiBiZSB0cmFuc21pdHRlZCBwZXIgUm91bmQtVHJpcCBU
aW1lIChSVFQpLiAgUmVjZW50IG5ldyBUQ1ANCj4gPiAgICAgbWVjaGFuaXNtcyBsaWtlIENvbmdl
c3Rpb24gRXhwb3N1cmUgKENvbkV4KSwgRGF0YSBDZW50ZXIgVENQIChEQ1RDUCkNCj4gPiAgICAg
b3IgTG93IExhdGVuY3kgTG93IExvc3MgU2NhbGFibGUgVGhyb3VnaHB1dCAoTDRTKSBuZWVkIG1v
cmUgYWNjdXJhdGUNCj4gPiAgICAgRUNOIGZlZWRiYWNrIGluZm9ybWF0aW9uIHdoZW5ldmVyIG1v
cmUgdGhhbiBvbmUgbWFya2luZyBpcyByZWNlaXZlZA0KPiA+ICAgICBpbiBvbmUgUlRULiAgVGhp
cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzY2hlbWUgdG8gcHJvdmlkZSBtb3JlIHRoYW4NCj4gPiAg
ICAgb25lIGZlZWRiYWNrIHNpZ25hbCBwZXIgUlRUIGluIHRoZSBUQ1AgaGVhZGVyLiAgR2l2ZW4g
VENQIGhlYWRlcg0KPiA+ICAgICBzcGFjZSBpcyBzY2FyY2UsIGl0IGFsbG9jYXRlcyBhIHJlc2Vy
dmVkIGhlYWRlciBiaXQsIHRoYXQgd2FzDQo+ID4gICAgIHByZXZpb3VzbHkgdXNlZCBmb3IgdGhl
IEVDTi1Ob25jZSB3aGljaCBoYXMgbm93IGJlZW4gZGVjbGFyZWQNCj4gPiAgICAgaGlzdG9yaWMu
ICBJdCBhbHNvIG92ZXJsb2FkcyB0aGUgdHdvIGV4aXN0aW5nIEVDTiBmbGFncyBpbiB0aGUgVENQ
DQo+ID4gICAgIGhlYWRlci4gIFRoZSByZXN1bHRpbmcgZXh0cmEgc3BhY2UgaXMgZXhwbG9pdGVk
IHRvIGZlZWQgYmFjayB0aGUgSVAtDQo+ID4gICAgIEVDTiBmaWVsZCByZWNlaXZlZCBkdXJpbmcg
dGhlIDMtd2F5IGhhbmRzaGFrZSBhcyB3ZWxsLiAgU3VwcGxlbWVudGFyeQ0KPiA+ICAgICBmZWVk
YmFjayBpbmZvcm1hdGlvbiBjYW4gb3B0aW9uYWxseSBiZSBwcm92aWRlZCBpbiBhIG5ldyBUQ1Ag
b3B0aW9uLA0KPiA+ICAgICB3aGljaCBpcyBuZXZlciB1c2VkIG9uIHRoZSBUQ1AgU1lOLg0KPiA+
DQo+ID4NCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm
dCBpczoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRj
cG0tYWNjdXJhdGUtZWNuLw0KPiA+DQo+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lv
bnMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTEyDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTEyDQo+ID4NCj4gPiBBIGRp
ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24t
MTINCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv
ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiA+IHVudGlsIHRoZSBodG1s
aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+
ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG
VFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPg0KPiA+
DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
PiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gDQo+IC0tDQo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQm9i
IEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2Uu
bmV0Lw0KPiAgICAgICAgICAgICAgICAgUFJJVklMRUdFRCBBTkQgQ09ORklERU5USUFMDQo+IA0K
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3Bt
IG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdGNwbQ0K


From nobody Wed Oct 28 08:56:35 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F84E3A099F for ; Wed, 28 Oct 2020 08:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 pCOEPFgqTXVs for ; Wed, 28 Oct 2020 08:56:27 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913633A09A3 for ; Wed, 28 Oct 2020 08:56:25 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4CLtV02cb4z8t3R; Wed, 28 Oct 2020 16:56:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603900584; bh=QsMnwa8/B3xPXC12TVI3unUv56Sd0s/ePFBjzmpzF9w=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Zg494xRb69Lf6ePfY4rDQeMKHU3FnW12+zMdW7z2D7hB2egEuTEiiiIBqqD2CiyYa JZ8FjxWptrtDBMbLYgxuM04kRl4qU8lNTNBZ/rvGdwANCZYqlEnw1DFCXWOYQ4qOgE X/b4aShZ+NKxYV6Hru7trMS6XFmIOOTyHF2PWYtgDSQbtDdi6ogWQfB6RKajuOcJyZ Y3XZugpxLG7GV75x+5hjCHtSHjsIsN28eqPsGJHRwfDQAfp4CPwb/m7vmYZF4ndc6G pqMw7xwpHigpxqKPnOPwjuiNQ6So2W/L6PBhZ05+RB9eESN7RMVPCECowNsxmWtC7a UA///90bQmBhg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CLtV01grmzCql4; Wed, 28 Oct 2020 16:56:24 +0100 (CET)
From: 
To: Joseph Touch 
CC: Wes Eddy , "tcpm@ietf.org" 
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
Thread-Index: AQHWrT0CvRbAJP2s0Uitm1snb0/Bu6mtJwIw
Date: Wed, 28 Oct 2020 15:56:23 +0000
Message-ID: <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@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.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 28 Oct 2020 15:56:35 -0000

SGkgSm9lLCANCg0KSSB3YXMgYXNzdW1pbmcgdGhhdCAiY2FzZSAyIiBpcyB1c2VkIGZvciBkZWZp
bmluZyBuZXcgb3B0aW9ucy4gSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBzYXkgdGhpcyBleHBsaWNp
dGx5IGluIHRoZSBkb2MuDQoNClRoYW5rcy4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz
c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb3NlcGggVG91Y2ggW21haWx0bzp0b3VjaEBz
dHJheWFscGhhLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAyOCBvY3RvYnJlIDIwMjAgMTY6
MTQNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJA
b3JhbmdlLmNvbT4NCj4gQ2PCoDogV2VzIEVkZHkgPHdlc0BtdGktc3lzdGVtcy5jb20+OyB0Y3Bt
QGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbdGNwbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10
Y3BtLXJmYzc5M2Jpcy0xOS50eHQNCj4gDQo+IEZXSVcsIGhlcmXigJlzIHRoZSBpc3N1ZToNCj4g
DQo+IC0gVENQIHJlbGllcyBvbiB0aGUgZmFjdCB0aGF0IEFMTCAqbmV3KiBvcHRpb25zIE1VU1Qg
aW5jbHVkZSB0aGUNCj4gbGVuZ3RoIGZpZWxkLg0KPiANCj4gVGhhdOKAmXMgYSBkZXNpZ24gY29u
c3RyYWludCBvbiBleHRlbnNpb25zLiBJdOKAmXMgbm90IG1lcmVseSBhc3NlcnRlZA0KPiB3aGVu
IGVhY2ggbmV3IG9wdGlvbiBpcyBkZWZpbmVkLg0KPiANCj4gSWYgdGhhdCByZXF1aXJlbWVudCBp
cyBub3QgZXN0YWJsaXNoZWQsIHRoZW4gVENQIGhhcyAqbm8gd2F5KiB0bw0KPiBrbm93IGhvdyBt
YW55IGJ5dGVzIHRvIGp1bXAgb3ZlciBpbiBhIFNZTiB0byBpZ25vcmUgb3B0aW9ucyBpdCBkb2Vz
DQo+IG5vdCBzdXBwb3J0Lg0KPiANCj4gU28gdGhpcyBkb2N1bWVudCBhYnNvbHV0ZWx5IG5lZWRz
IHRoaXMgcmVxdWlyZW1lbnQgLSBwZXJoYXBzDQo+IHJld29yZGVkIHRvIGJlIG1vcmUgY2xlYXIg
dGhhdCBPTkxZIHRoZSBvcHRpb25zIGRlZmluZWQgaGVyZWluIHdpdGgNCj4gZml4ZWQgbGVuZ3Ro
IGNhbiBvbWl0IHRoYXQgZmllbGQuDQo+IA0KPiBKb2UNCj4gDQo+ID4gT24gT2N0IDI4LCAyMDIw
LCBhdCAxMjoxMiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPg0K
PiA+IFJlLSwNCj4gPg0KPiA+IEkgYWdyZWUgd2l0aCBXZXMgdGhhdCB0aGlzIG9uZSBkb2VzIG5v
dCBuZWVkIHRvIGJlIG51bWJlcmVkLiBJDQo+IHdvdWxkIGV2ZW4gcmVtb3ZlIHRoYXQgc2VudGVu
Y2UgYXMgdGhlIHNwZWNzIGRlZmluaW5nIHRoZSBvcHRpb25zDQo+IHdpbGwgY2FsbCBvdXQgdGhl
IGxlZ2FsIGxlbmd0aC4NCj4gPg0KPiA+IElmIHRoZSB0ZXh0IGlzIG1haW50YWluZWQsIHRoZSBu
b3JtYXRpdmUgbGFuZ3VhZ2Ugc2hvdWxkIGJlDQo+IHJlbW92ZWQgZm9yIHRoZSBpbnRlcm5hbCBj
b25zaXN0ZW5jeSBvZiB0aGUgZG9jdW1lbnQ6DQo+ID4NCj4gPiA9PQ0KPiA+ICAgRWFjaCB1c2Ug
b2YgUkZDIDIxMTkga2V5d29yZHMgaW4gdGhlIGRvY3VtZW50IGlzIGluZGl2aWR1YWxseQ0KPiBs
YWJlbGxlZA0KPiA+ICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4gICBhbmQg
cmVmZXJlbmNlZCBpbiBBcHBlbmRpeCBCIHRoYXQgc3VtbWFyaXplcyBpbXBsZW1lbnRhdGlvbg0K
PiA+ICAgcmVxdWlyZW1lbnRzLg0KPiA+ID09DQo+ID4NCj4gPiBPTEQ6DQo+ID4gKGFsbCBUQ1Ag
b3B0aW9ucyBleGNlcHQgRW5kIG9mIG9wdGlvbiBsaXN0IGFuZCBOby1PcGVyYXRpb24NCj4gPiAg
ICAgTVVTVCBoYXZlIGxlbmd0aCBmaWVsZHMpDQo+ID4NCj4gPiBORVc6DQo+ID4gKGFsbCBUQ1Ag
b3B0aW9ucyBleGNlcHQgRW5kIG9mIG9wdGlvbiBsaXN0IGFuZCBOby1PcGVyYXRpb24NCj4gPiAg
ICAgaGF2ZSBsZW5ndGggZmllbGRzKQ0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+
ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZSA6IHRjcG0gW21haWx0bzp0
Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgV2VzbGV5DQo+IEVkZHkNCj4gPj4g
RW52b3nDqSA6IG1lcmNyZWRpIDI4IG9jdG9icmUgMjAyMCAwMDowMSDDgCA6IHRjcG1AaWV0Zi5v
cmcgT2JqZXQgOg0KPiBSZToNCj4gPj4gW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNw
bS1yZmM3OTNiaXMtMTkudHh0DQo+ID4+DQo+ID4+IEkgbWVhbnQgdG8gZXhwbGFpbiB0aGlzIG9u
ZSB0byB0aGUgbGlzdCwgYnV0IHdhcyBzaWRlLXRyYWNrZWQNCj4gPj4gZWFybGllciwgYW5kIHlv
dSd2ZSBiZWF0IG1lIHRvIGl0IDopDQo+ID4+DQo+ID4+IFdoZW4gYWRkaW5nIHRoYXQgdGV4dCwg
SSdkIG5vdGljZWQgdGhhdCB0aGUgIk1VU1QiIGlzIGFwcGxpY2FibGUNCj4gdG8NCj4gPj4gb3Ro
ZXIgc3BlY3MgdGhhdCBkZWZpbmUgb3B0aW9ucyAoc2F5aW5nIHRoZXkgbmVlZCB0byBpbmNsdWRl
IHRoZQ0KPiA+PiBsZW5ndGggZmllbGQpLCBidXQgaXNuJ3QgZXhhY3RseSBzb21ldGhpbmcgdGhh
dCB5b3Ugd291bGQgY2hlY2sNCj4gYW4NCj4gPj4gaW1wbGVtZW50YXRpb24gYWdhaW5zdCBmb3Ig
Y29uZm9ybWFuY2UgKHNpbmNlIGl0IHdvdWxkIGp1c3QNCj4gaW1wbGVtZW50DQo+ID4+IHRoZSBv
cHRpb25zIGFzIHByb3Blcmx5IHNwZWNpZmllZCkuDQo+ID4+DQo+ID4+IElmIHBlb3BsZSB0aGlu
ayBpdCBtYWtlcyBzZW5zZSB0byBudW1iZXIgaXQgYW5kIGFkZCB0byB0aGUNCj4gY2hlY2tsaXN0
LA0KPiA+PiB0aGF0J3MgdG90YWxseSBmaW5lIHdpdGggbWUsIGJ1dCBpdCBkaWRuJ3Qgc2VlbSB2
ZXJ5IG1lYW5pbmdmdWwuDQo+ID4+DQo+ID4+DQo+ID4+IE9uIDEwLzI3LzIwMjAgMjoyNyBQTSwg
Sm9zZXBoIFRvdWNoIHdyb3RlOg0KPiA+Pj4gTG9va3MgZ29vZCB0byBtZSB0b28sIGJ1dCBvbmUg
cXVlc3Rpb246DQo+ID4+Pg0KPiA+Pj4gVGhlIHVwZGF0ZSBiZWxvdyB0aGF0IGlzIGFscmVhZHkg
aW4gLTE5IGRvZXNu4oCZdCBpbmNsdWRlIGEgTVVTVC0NCj4gIyMuDQo+ID4+IEkgZGlkbuKAmXQg
a25vdyBpZiB0aGF0IHdhcyBleHBlY3RlZCwgYnV0IEZZSS4NCj4gPj4+DQo+ID4+PiBKb2UNCj4g
Pj4+DQo+ID4+Pj4gT24gT2N0IDIyLCAyMDIwLCBhdCAzOjQ3IFBNLCBKb3NlcGggVG91Y2gNCj4g
PHRvdWNoQHN0cmF5YWxwaGEuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+IFRoZSBm
b2xsb3dpbmcgdGV4dCBzaG91bGQgaW5jbHVkZSBhIE1VU1QsIGFzIHNob3duIGJlbG93Og0KPiA+
Pj4+DQo+ID4+Pj4gICAgKGFsbCBUQ1Agb3B0aW9ucyBleGNlcHQgRW5kIG9mIG9wdGlvbiBsaXN0
IGFuZCBOby1PcGVyYXRpb24NCj4gPj4+PiAgICAgTVVTVCBoYXZlIGxlbmd0aCBmaWVsZHMpDQo+
ID4+PiAtLS0tLS0tDQo+ID4+Pg0KPiA+Pj4+IE9uIE9jdCAyNywgMjAyMCwgYXQgNTozNSBBTSwg
aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBB
IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l
dC0NCj4gPj4gRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr
IGl0ZW0gb2YgdGhlIFRDUCBNYWludGVuYW5jZSBhbmQgTWlub3INCj4gPj4gRXh0ZW5zaW9ucyBX
RyBvZiB0aGUgSUVURi4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBU
cmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCAoVENQKQ0KPiA+PiBTcGVjaWZpY2F0aW9uDQo+
ID4+Pj4gICAgICAgIEF1dGhvciAgICAgICAgICA6IFdlc2xleSBNLiBFZGR5DQo+ID4+Pj4gCUZp
bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTkudHh0DQo+ID4+Pj4g
CVBhZ2VzICAgICAgICAgICA6IDEwOQ0KPiA+Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDIwLTEw
LTI3DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiA+Pj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPj4+IHRjcG1AaWV0Zi5vcmcNCj4gPj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+Pg0KPiA+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiB0Y3BtIG1h
aWxpbmcgbGlzdA0KPiA+PiB0Y3BtQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX18NCj4g
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
Pg0KPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg
ZGVzIGluZm9ybWF0aW9ucw0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg
bmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+IGRpZmZ1c2VzLA0KPiA+IGV4cGxvaXRlcyBvdSBj
b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlDQo+IG1lc3NhZ2UN
Cj4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBs
ZSBkZXRydWlyZQ0KPiBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg
ZWxlY3Ryb25pcXVlcyBldGFudA0KPiBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2Ug
ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZQ0KPiBtZXNzYWdlIGEgZXRlIGFsdGVy
ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4NCj4gPiBUaGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gPiBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxk
DQo+IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0
aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlcg0KPiBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLg0KPiA+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs
aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4gaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC4NCj4gPiBUaGFuayB5b3UuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4g
dGNwbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
dGNwbQ0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu
dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll
ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl
IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz
IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl
c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp
ZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu
IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl
Y3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp
ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug
aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n
ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=


From nobody Wed Oct 28 10:17:27 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E203A0925 for ; Wed, 28 Oct 2020 10:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level: 
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_FAIL=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 3c4auIhWlVCZ for ; Wed, 28 Oct 2020 10:17:24 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 022BE3A08DC for ; Wed, 28 Oct 2020 10:17:23 -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=DGGGjJz6pNMQnAgqLnT56M45JZrTeQvwoYerx+H7JDA=; b=kcHN+s+2d2EQQSgw6HT9KEjydt R4z+kLXyiAje286MoilhHnPtnvCvdfEOKGVZTJW9SDqMA0FYR16Cy3Vu7oysaPOrQTtj0o+r3IEG8 w84OLH92tyHrUEieznsMjBW0VIaNHIhKiZpyah/u/zBEOJcor8Lv9j1YU4k8Ij/fQZdoYdOZlel44 LHEhiKSl3GBM2DYRAhyhJXcCnig57pUVNsQVl/xJRueD+ifxYkgVTp28jyxXtRuoZSr21RzjFfVWE uwUPqcXABNCkm+1r9S3j3vz8mUgyiA0X0UhciVkp4GBp+339Gb1u/SbbnRNLQYtcMxiDxPFez8MwA b3tnRQFg==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:49766 helo=[192.168.1.3]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kXp4b-00EInK-OY; Wed, 28 Oct 2020 17:17:21 +0000
To: "Scharf, Michael" , "tcpm@ietf.org" 
Cc: "Scheffenegger, Richard" , Mirja Kuehlewind 
References: <160388925181.18695.7892567372446756190@ietfa.amsl.com> <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net> <3c8de57b23994824b6c51cf5d7fba7ec@hs-esslingen.de>
From: Bob Briscoe 
Message-ID: <5dd8f210-2fe2-bd9b-5e69-4a87016f5416@bobbriscoe.net>
Date: Wed, 28 Oct 2020 17:17:20 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <3c8de57b23994824b6c51cf5d7fba7ec@hs-esslingen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
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: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.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, 28 Oct 2020 17:17:26 -0000

Michael,

On 28/10/2020 15:55, Scharf, Michael wrote:
> Hi Bob,
>
> What is the future plan regarding the option encoding proposed by the authors?
>
> This has been discussed in past meetings and on the list, for instance: https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo/
>
> I have explained several times my pushback against the encoding currently described in the document, most notably the requirement to keep state in the endpoints to decode the format of a TCP option. I have not changed my mind.
>
> I have also mentioned that, for instance, two option codepoints would IMHO be a better engineering approach ("KISS principle"). That would be a very simple change to the content to the document. Needless to say that there are other alternatives for marshalling parameters in an unambigous way.

[BB] Whoops. In my head I had already shifted to your scheme with 
two-option kinds. But I see that, in the draft,  I haven't. Whoops - 
that was a bug in my ToDo list processing. Sorry about that. I'll submit 
another draft before the deadline with that scheme replacing the current 
one.

I've just found some other entries in my ToDo list for this draft which 
I missed as well. I'll include them too.

Sorry again.


Bob

>
> There have been other related comments, e.g. from Ilpo.
>
> Best regards
>
> Michael (with no hat)
>
>> -----Original Message-----
>> From: tcpm  On Behalf Of Bob Briscoe
>> Sent: Wednesday, October 28, 2020 2:04 PM
>> To: tcpm@ietf.org
>> Cc: Scheffenegger, Richard ; Mirja
>> Kuehlewind 
>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
>>
>> TCPM folks,
>>
>> Back in May'20, it was decided to hold back the AccECN (and the ECN++)
>> drafts for a while until the position on L4S in tsvwg was clearer. There
>> is no formal dependency on the L4S drafts in tsvwg, but it made sense
>> not to burn codepoints without more certainty.
>>
>> I've just refreshed the AccECN and the ECN++ drafts, which had expired.
>>
>> I included the following minor changes to AccECN, which you can see via
>> the diff link below, but in summary:
>> * moved wrongly categorized "action if unwilling to provide f/b" to the
>> group of bullets relevant to the receiver
>> * removed refs to long-expired ecn-fallback draft
>> * fixed table 1 after xml2rfc changed formatting
>>
>> Thanks to those who pointed these out.
>>
>> No changes to ECN++ other than update of some refs.
>>
>> Cheers
>>
>>
>> Bob
>>
>> On 28/10/2020 12:47, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the TCP Maintenance and Minor Extensions WG of
>> the IETF.
>>>           Title           : More Accurate ECN Feedback in TCP
>>>           Authors         : Bob Briscoe
>>>                             Mirja Kühlewind
>>>                             Richard Scheffenegger
>>> 	Filename        : draft-ietf-tcpm-accurate-ecn-12.txt
>>> 	Pages           : 58
>>> 	Date            : 2020-10-28
>>>
>>> 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 a 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.  The resulting extra space is exploited to feed back the IP-
>>>      ECN field received during the 3-way handshake as well.  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-12
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-12
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-12
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>                  PRIVILEGED AND CONFIDENTIAL
>>
>> _______________________________________________
>> 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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
                PRIVILEGED AND CONFIDENTIAL


From nobody Wed Oct 28 10:58:36 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92B63A0A99 for ; Wed, 28 Oct 2020 10:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85yfyPMBlbX3 for ; Wed, 28 Oct 2020 10:58:32 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34B43A0A97 for ; Wed, 28 Oct 2020 10:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xg4laLbr+tlvINbVzzHDiprflZE32Ghj9+kac+dHKyw=; b=oCSv2f0ShJDiO/iSD3o5rA3A4 kGpfVlZtQV2s4XnEbLdSErQ9PnwzB+3mfBbc0yr8P9BAubj/gbxlcTCGANd9yALFCXXf8UTk8jy/a 9X2HiEY0TaGgB8/N3DWbX2M6bQu/Myb28H0KODJTWvh3X/EawH+g7AU2XC/gbZxMUbALcWAVPooMA ke5D67Y+SvwdBYm46Wv0deLtyrjNgKuy8IqtVHdu+gpOFYjKzsbQ2AttcvdayHfGYDkhkHXnpwXfw ZSu3jmcTADM2mvBduejmLlgz9uZ83fHOGQpL8zVwu6IrRXw0JI28XCB+uiDS1tIbcayFg/bIq9/Xd PuEPhdSCQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50176 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kXpiL-003LZi-Oy; Wed, 28 Oct 2020 13:58:30 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 28 Oct 2020 10:58:25 -0700
Cc: "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-0.2
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] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 28 Oct 2020 17:58:35 -0000

Right - that=E2=80=99s the point of the text below - including where it =
appears.=20

Perhaps more strictly, we should say =E2=80=9CAll future options MUST =
use the kind/length format=E2=80=9D. But it does need a number =
(MUST-##).

Joe

> On Oct 28, 2020, at 8:56 AM, mohamed.boucadair@orange.com wrote:
>=20
> Hi Joe,=20
>=20
> I was assuming that "case 2" is used for defining new options. I agree =
that we should say this explicitly in the doc.
>=20
> Thanks.=20
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Joseph Touch [mailto:touch@strayalpha.com]
>> Envoy=C3=A9 : mercredi 28 octobre 2020 16:14
>> =C3=80 : BOUCADAIR Mohamed TGI/OLN 
>> Cc : Wes Eddy ; tcpm@ietf.org
>> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
>>=20
>> FWIW, here=E2=80=99s the issue:
>>=20
>> - TCP relies on the fact that ALL *new* options MUST include the
>> length field.
>>=20
>> That=E2=80=99s a design constraint on extensions. It=E2=80=99s not =
merely asserted
>> when each new option is defined.
>>=20
>> If that requirement is not established, then TCP has *no way* to
>> know how many bytes to jump over in a SYN to ignore options it does
>> not support.
>>=20
>> So this document absolutely needs this requirement - perhaps
>> reworded to be more clear that ONLY the options defined herein with
>> fixed length can omit that field.
>>=20
>> Joe
>>=20
>>> On Oct 28, 2020, at 12:12 AM, mohamed.boucadair@orange.com wrote:
>>>=20
>>> Re-,
>>>=20
>>> I agree with Wes that this one does not need to be numbered. I
>> would even remove that sentence as the specs defining the options
>> will call out the legal length.
>>>=20
>>> If the text is maintained, the normative language should be
>> removed for the internal consistency of the document:
>>>=20
>>> =3D=3D
>>>  Each use of RFC 2119 keywords in the document is individually
>> labelled
>>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>  and referenced in Appendix B that summarizes implementation
>>>  requirements.
>>> =3D=3D
>>>=20
>>> OLD:
>>> (all TCP options except End of option list and No-Operation
>>>    MUST have length fields)
>>>=20
>>> NEW:
>>> (all TCP options except End of option list and No-Operation
>>>    have length fields)
>>>=20
>>> Cheers,
>>> Med
>>>=20
>>>> -----Message d'origine-----
>>>> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Wesley
>> Eddy
>>>> Envoy=C3=A9 : mercredi 28 octobre 2020 00:01 =C3=80 : tcpm@ietf.org =
Objet :
>> Re:
>>>> [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
>>>>=20
>>>> I meant to explain this one to the list, but was side-tracked
>>>> earlier, and you've beat me to it :)
>>>>=20
>>>> When adding that text, I'd noticed that the "MUST" is applicable
>> to
>>>> other specs that define options (saying they need to include the
>>>> length field), but isn't exactly something that you would check
>> an
>>>> implementation against for conformance (since it would just
>> implement
>>>> the options as properly specified).
>>>>=20
>>>> If people think it makes sense to number it and add to the
>> checklist,
>>>> that's totally fine with me, but it didn't seem very meaningful.
>>>>=20
>>>>=20
>>>> On 10/27/2020 2:27 PM, Joseph Touch wrote:
>>>>> Looks good to me too, but one question:
>>>>>=20
>>>>> The update below that is already in -19 doesn=E2=80=99t include a =
MUST-
>> ##.
>>>> I didn=E2=80=99t know if that was expected, but FYI.
>>>>>=20
>>>>> Joe
>>>>>=20
>>>>>> On Oct 22, 2020, at 3:47 PM, Joseph Touch
>> 
>>>> wrote:
>>>>>>=20
>>>>>> The following text should include a MUST, as shown below:
>>>>>>=20
>>>>>>   (all TCP options except End of option list and No-Operation
>>>>>>    MUST have length fields)
>>>>> -------
>>>>>=20
>>>>>> On Oct 27, 2020, at 5:35 AM, internet-drafts@ietf.org wrote:
>>>>>>=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 (TCP)
>>>> Specification
>>>>>>       Author          : Wesley M. Eddy
>>>>>> 	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
>>>>>> 	Pages           : 109
>>>>>> 	Date            : 2020-10-27
>>>>> _______________________________________________
>>>>> 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
>>>=20
>>>=20
>> ____________________________________________________________________
>> __
>>> ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>> diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce
>> message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire
>> ainsi que les pieces jointes. Les messages electroniques etant
>> susceptibles d'alteration, Orange decline toute responsabilite si ce
>> message a ete altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender
>> and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that
>> have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Wed Oct 28 19:44:23 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF493A0944 for ; Wed, 28 Oct 2020 19:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Z6SXdFTdQI5F for ; Wed, 28 Oct 2020 19:44:20 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640108.outbound.protection.outlook.com [40.107.64.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D925A3A0920 for ; Wed, 28 Oct 2020 19:44:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FF6WdxvhdxHppD9/xhibyN7gQt79OeDYx0j54zEkYOGak2RBkKxVJzWh8h5MV3YYyQBMnHv+PyQp28CX+r5AhXXwLM4PTIkAq3HXuTCvc7v48DYFMxIY+rZVHgZw700Ei5oOLCHbIhkaL+OnmOatVIE0VdNvcsFKBslAF2O3ysytbBIMY+JI+tk10dekAtiTq//oCQPikuPdRY2ukazY3rBBhl+cnH/by7N52t7JFGu0rT9L0vCrTHD19RIVl69Y6TegxpxI6WmFVckBNd8Kb5tJVNbFIHc/eoYVR4YnxHWxxqosNWR0bk1olt0Ps5bZMapOqHU8ajTmCZ8UZ6dbMw==
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=yEQv2XfjgFeL4luevg73l3kET1ujrcWsoHMpW5XrPME=; b=gDMDwGVJ6tMUbBIwMCSAvxCw1Zg55p6BEnMX7GiwF4UaKR7BveBoZ8YGN3POfxpav83vcQqIWc4TeL8m3VhFQOuodiEKbvTwD34gJAiE2DB/9Rf78Tg/snXeih4IAq8j9FDQPpUpC6SzjBUqV/mYEBFcvVzYw63QgPU9ODZeaHaevxIhRZTs7pPOZkEvNNib3dDUx4cqb1fpwOWyyW3LEVbqBg8ZYWOMvZ37Bsi7z6TFeAB0UeO3gQUUyEYV1HeIOIPsLy/ZMZxI0deLdo5xpbIpLabUiA5NHGjoQ1TEig32E6EixkZ2BbpksTR1yyj2YLfVogwbAb0aaoMvfIeWtA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yEQv2XfjgFeL4luevg73l3kET1ujrcWsoHMpW5XrPME=; b=VI9AlCsMU+zMykYCze5Yi1rlQGFnLuwfY/R9NzG1Ok58pJl92SYcRAUHVNkU1wcl85tCC1WWWhgw2UpHrcuFwMR+k/gRnYk9YafLgAe//7F4XaekbYgLsaelbORXqYg3eHLve9S73mM0NzDx2kGQQ0sdb+YqmAR8BD4IsrYgeHc=
Received: from (2603:10b6:208:3a::11) by MN2PR00MB0479.namprd00.prod.outlook.com (2603:10b6:208:c6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3557.0; Thu, 29 Oct 2020 02:44:17 +0000
Received: from MN2PR00MB0639.namprd00.prod.outlook.com ([fe80::ed5d:f11d:bdbb:faaf]) by MN2PR00MB0639.namprd00.prod.outlook.com ([fe80::ed5d:f11d:bdbb:faaf%6]) with mapi id 15.20.3563.000; Thu, 29 Oct 2020 02:44:17 +0000
From: Praveen Balasubramanian 
To: Wesley Eddy , "tcpm@ietf.org" , Matt Olson , Yi Huang 
Thread-Topic: [EXTERNAL] Re: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18
Thread-Index: AdajXxk8uequbu29QB+n5DRBKHdcewAAci5QAYbZnYABB/nQ4A==
Date: Thu, 29 Oct 2020 02:44:17 +0000
Message-ID: 
References:   <8e59b58f-badd-2aac-fe2e-d40a9c78cc94@mti-systems.com>
In-Reply-To: <8e59b58f-badd-2aac-fe2e-d40a9c78cc94@mti-systems.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_ActionId=c78256dc-0ff2-4afb-91a3-fdaa2504a2b6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-29T02:35:38Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: mti-systems.com; dkim=none (message not signed) header.d=none;mti-systems.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:7:95d1:3f73:f682:d302]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4768f9e1-82fe-480c-8845-08d87bb487f4
x-ms-traffictypediagnostic: MN2PR00MB0479:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xPFt+lTlzvOe4zM4ufjVDDy+yQPJWfxCcXzjVu3TAFkwb03qckyY9bjcCpAHjQgyb3dhZokvvdIRjA3dBcPWzXRHVeeGgz8w8MnfXzRqS5434n7OVAijQIQPVL2o1bDovo/lizhvDzYjfHbyzM6rVfaTakcY7OjWHGCQhIsOU4h8YAvxm6NF6aZKZkhPCwcUKhVO8NX7WVad3ni8gHAGYfk2k+qDGQMXxMkWLqUXRx5SFQD80wmQIHZ795qrwfW5AKAtjnAG8a0IYEllrZoVltje55tvD2yn+5e7AXrozNH8sDn4d3+ZbOc5SYXCVtvAAWHamHUN/FJHRxSSknOoDw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0639.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(316002)(76116006)(5660300002)(52536014)(110136005)(8990500004)(66946007)(66446008)(66556008)(64756008)(7696005)(66476007)(8936002)(83380400001)(6636002)(6506007)(53546011)(9686003)(55016002)(186003)(10290500003)(86362001)(478600001)(8676002)(82950400001)(82960400001)(2906002)(33656002)(71200400001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: QsU0xLu67vAUvWrXHxGLiqGIefy8QZX6Q58EwWkUYS27/VCaPeJIYMQ3lOkdIu7ohVlBYqFKafA+AS+hDcm1FHJtC7RfW3SFGyAbsYAYE5009SwSB3lkb0Ds3eBiN16zaVLndFJtiyaE2Ab8SdTGn6n2DFWgu8gIBZGS9/PSlyb5JZYw2M+a5Jmi7IIYYKRGw3xJBi7E9zt7Zl9wTBEaB/Bco4kua2nVRrah2oboU3jBG8YzVGFx2giEkDPoSrZ8AzhW+oijCqlodOga2krrH6TEF/84eqUCdsZuXsqfQGe8hp3mBJRr4RpZLfkGUWvJS3zdq8qTHcPjVJMmODR6X9EgdJBZbBerjhjrIQxrDDuejcKpFEpVWYGu0YVdeyCT60giLPF74mzIG/DgLB26PCbrgWMs+6Bqv6sI78T/yS9N6p42RI6n0CNljHJhwN4dx5wfSzEBaUzYMvXnvLNAOU5agXG6TidkKPT7ijUyI7j1QVsczJ2rcfkZj80LOSrBbspRH9AjncTxuDkPeGXDvcQx3ysSeuMsyK+rphU53kCXPK8hzY1B74Wn3eG6yNM/1gJEckCNKDuV5iYQjsP5VF5K89RpHOtSLZUiFSuSF4SC2bjZ4gLUzeAgyGqGQ3F3JFsNHTtSObp38XEiN2HOgNU/lCr7e0puLLm8e6No7JHMVn9yL+OfYxMM/ZDIzUs9Wk5x/dHshzwzvnEKIrCRug==
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06397FA1D9D6F08370FA3BB0B6141MN2PR00MB0639namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0639.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4768f9e1-82fe-480c-8845-08d87bb487f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2020 02:44:17.5586 (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: s+fdo8AAzMcd4m3hvOp+Hl43TaBh62PzinC/pr06BJ9cXAPQEna9Fjx1jETiCKVK8MJhzv04PiPtcYp/D1TFBfZUpbXfA9rMD8M+b9lW0wg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0479
Archived-At: 
Subject: Re: [tcpm] [EXTERNAL] Re: WGLC review of draft-ietf-tcpm-rfc793bis-18
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Oct 2020 02:44:22 -0000

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

In draft 19:

Section 2. There is a typo retransmion -> retransmission. I would suggest r=
unning this document through a spell checker.

Section 3.1. "Additional RFCs define some other commonly used options that =
are recommended to implement." --> I think we need stronger language here. =
The following commonly used options SHOULD be supported.

Please bring up the SYN timeout MUST requirement of 3 minutes and the flexi=
bility of using other congestion controllers (other than Reno as in RFC 568=
1) up for working group discussion.

Thanks

From: Wesley Eddy 
Sent: Friday, October 23, 2020 1:37 PM
To: Praveen Balasubramanian ; tcpm@ietf.org; Matt Olso=
n ; Yi Huang 
Subject: [EXTERNAL] Re: [tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18


Thank you for this helpful review; here are my plans/thoughts on addressing=
 your comments:


On 10/15/2020 10:06 PM, Praveen Balasubramanian wrote:

Section 3.1

The control bits in the header include the RFC 3168 specified CWR and ECE. =
It might be worth citing 3168 as well in the Abstract.

Agreed; I'll do this in the next revision.





It is quite a bit surprising that we don't include discussion of the SACK, =
Timestamp, and Window Scaling options. Even if we don't describe the detail=
s, the document should provide references to these almost universally deplo=
yed options and recommend that hosts SHOULD implement them. At least the Ti=
mestamp option is referred to multiple times in the text without any specif=
ication of the format.

This makes basically sense to me, and I'll plan to improve on it in the nex=
t revision.  My plan is to prominently reference the specs that define thos=
e options, and say that they're recommended, but won't try to recreate thei=
r definitions here though.



Section 3.6.4

"

   If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the

   sending TCP endpoint buffers all user data (regardless of the PSH

   bit), until the outstanding data has been acknowledged or until the

   TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes).

"

This is slightly different from Nagle's description in RFC 896:

"

The solution is to inhibit the sending of new TCP  segments  when

new  outgoing  data  arrives  from  the  user  if  any previously

transmitted data on the connection remains unacknowledged.

"

I.e., the original algorithm description in RFC 896 didn't include the "or =
if a full-sized packet can be sent" part. This difference isn't mentioned i=
n 793bis, it ought to be, along with a justification for the difference.

This part is directly from RFC 1122 (Section 4.2.3.4), so I think it says t=
he proper thing.



Also there is no mention of the interaction problem between Nagle's algorit=
hm and delayed ACKs, either here or in the later section on delayed ACKs.

Very good point!  Currently, the delayed ACK interaction w/ Nagle is only m=
entioned in Appendix A.3.  I think, based on your comment, that we should a=
dd a mention of this in the main body when Nagle's algorithm is discussed, =
referring to A.3.



Section 3.7.3



"However, the values of R1 and R2 may be different for SYN

            and data segments.  In particular, R2 for a SYN segment MUST

            be set large enough to provide retransmission of the segment

            for at least 3 minutes.  The application can close the

            connection (i.e., give up on the open attempt) sooner, of

            course.

"

The MUST here is onerous for what is an ancient timeout value which modern =
implementations don't adhere to. Recommend changing this to a SHOULD.

While I agree, I think this will require some greater working group discuss=
ion.  If the group and chairs agree, I'm happy to do this.



Section 3.7.4
"Keep-alive packets MUST only be sent when no data or acknowledgement
   packets have been received for the connection within an interval
   (MUST-26).

"

It's important to call out an additional condition - that sends are not alr=
eady outstanding. When a send is outstanding, it is retransmitted and serve=
s as an implicit liveness check.

This is an excellent point, and I think it can be added in the next revisio=
n, unless there is any objections from the rest of the working group.



Section 3.7.2


"A TCP endpoint MUST implement RFC 5681 (MUST-19)."
This requirement is onerous because RFC 5681 also specifies the NewReno con=
gestion control algorithms. Modern implementations use other algorithms. We=
 should add clarifying text permitting experimentation and evolution of con=
gestion control algorithms. It is also not required for interop.

This is a part where maybe we could use some more help/input on the exact w=
ording.

I think MUST implement some IETF standard congestion control is the right i=
dea, but alternative algorithms that are administratively (or otherwise) ma=
naged on a host are also fine to implement and enable.  If others agree, di=
sagree, or have thoughts on how exactly to phrase this, I think it would he=
lp to hear from the working group.



Finally, all of your editorial comments are now accounted for in my working=
 copy, so thank you for those.



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











In draft 19:


 


Section 2. There is a typo retransmion -> retrans=
mission. I would suggest running this document through a spell checker.


 


Section 3.1. “Additional RFCs define some othe=
r commonly used options that are recommended to implement.”
à I think we need stron=
ger language here. The following commonly used options SHOULD be supported.



 


Please bring up the SYN timeout MUST requirement of =
3 minutes and the flexibility of using other congestion controllers (other =
than Reno as in RFC 5681) up for working group discussion.



 


Thanks


 






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

Sent: Friday, October 23, 2020 1:37 PM

To: Praveen Balasubramanian <pravb@microsoft.com>; tcpm@ietf.o=
rg; Matt Olson <maolson@microsoft.com>; Yi Huang <huanyi@microsoft=
.com>

Subject: [EXTERNAL] Re: [tcpm] WGLC review of draft-ietf-tcpm-rfc793=
bis-18






 


Thank you for this helpful review; here are my plans/thoughts on address=
ing your comments:


 




On 10/15/2020 10:06 PM, Praveen Balasubramanian wrot=
e:








Section 3.1=



The control bits in the=
 header include the RFC 3168 specified CWR and ECE. It might be worth citin=
g 3168 as well in the Abstract.







Agreed; I'll do this in the next revision.


 






 


It is quite a bit surpr=
ising that we don't include discussion of the SACK, Timestamp, and Window S=
caling options. Even if we don't describe the details, the document should =
provide references to these almost universally
 deployed options and recommend that hosts SHOULD implement them. At least =
the Timestamp option is referred to multiple times in the text without any =
specification of the format.






This makes basically sense to me, and I'll plan to improve on it in the =
next revision.  My plan is to prominently reference the specs that def=
ine those options, and say that they're recommended, but won't try to recre=
ate their definitions here though.


 






Section 3.6.4


" 


   If there i=
s unacknowledged data (i.e., SND.NXT > SND.UNA), then the


   sending TC=
P endpoint buffers all user data (regardless of the PSH

   bit), unti=
l the outstanding data has been acknowledged or until the=



   TCP endpoi=
nt can send a full-sized segment (Eff.snd.MSS bytes).


"


This is slightly differ=
ent from Nagle's description in RFC 896:


" 


The solution is to inhi=
bit the sending of new TCP  segments  when


new  outgoing &nbs=
p;data  arrives  from  the  user  if  any pre=
viously


transmitted data on the=
 connection remains unacknowledged.


"


I.e., the original algo=
rithm description in RFC 896 didn't include the "or if a full-sized pa=
cket can be sent" part. This difference isn't mentioned in 793bis, it =
ought to be, along with a justification for the
 difference. 






This part is directly from RFC 1122 (Section 4.2.3.4), so I think it say=
s the proper thing.


 






Also there is no mentio=
n of the interaction problem between Nagle's algorithm and delayed ACKs, ei=
ther here or in the later section on delayed ACKs.






Very good point!  Currently, the delayed ACK interaction w/ Nagle i=
s only mentioned in Appendix A.3.  I think, based on your comment, tha=
t we should add a mention of this in the main body when Nagle's algorithm i=
s discussed, referring to A.3.


  






Section 3.7.3 


 


“However, the val=
ues of R1 and R2 may be different for SYN


    =
;        and data segments.  In par=
ticular, R2 for a SYN segment
MUST


    =
;        be set large enough to provide =
retransmission of the segment


    =
;        for at least 3 minutes.  T=
he application can close the


    =
;        connection (i.e., give up on th=
e open attempt) sooner, of


    =
;        course.


“


The MUST here is onerou=
s for what is an ancient timeout value which modern implementations donR=
17;t adhere to. Recommend changing this to a SHOULD.






While I agree, I think this will require some greater working group disc=
ussion.  If the group and chairs agree, I'm happy to do this.


 






Section 3.7.4


“Keep-alive packets MUST only be sent when no data or acknowledg=
ement


   packets have been received for the connection within an i=
nterval


   (MUST-26).


“


It’s important to=
 call out an additional condition – that sends are not already outsta=
nding. When a send is outstanding, it is retransmitted and serves as an imp=
licit liveness check.






This is an excellent point, and I think it can be added in the next revi=
sion, unless there is any objections from the rest of the working group.


 






Section 3.7.2


 


“A TCP endpoint MUST implement RFC 5681 (MUST-19).=
221;


This requirement is onerous because RFC 5681 also specifies the Ne=
wReno congestion control algorithms. Modern implementations use other algor=
ithms. We should add clarifying text
 permitting experimentation and evolution of congestion control algorithms.=
 It is also not required for interop.  






This is a part where maybe we could use some more help/input on the exac=
t wording.


I think MUST implement some IETF standard congestion control is the righ=
t idea, but alternative algorithms that are administratively (or otherwise)=
 managed on a host are also fine to implement and enable.  If others a=
gree, disagree, or have thoughts on how
 exactly to phrase this, I think it would help to hear from the working gro=
up.


 


Finally, all of your editorial comments are now accounted for in my work=
ing copy, so thank you for those.


 






--_000_MN2PR00MB06397FA1D9D6F08370FA3BB0B6141MN2PR00MB0639namp_--


From nobody Thu Oct 29 00:46:34 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9CE3A0B72 for ; Thu, 29 Oct 2020 00:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 pEqyYjaHYFcM for ; Thu, 29 Oct 2020 00:46:32 -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 154173A0AF7 for ; Thu, 29 Oct 2020 00:46:32 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4CMHZG45GGz5vs6; Thu, 29 Oct 2020 08:46:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603957590; bh=IVbGVMLjrYU9UsHOWgGILHBd94G1bn998k69nhkaDCs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Xdyfkja5DALlLh3m2nZ1mcgo5E9CvX44Z+ze4IWaww14YBVrRoXALTI6F2ZyoT8Uj cc89VPE2cg8EEO6nxttyC4QoFeq3ZtOnj0iI8eZ0WojQXzC+GBKi90rE/y5pn1d6TY 3vuzlXeHqrums0/o0l81ukjBLxwTjRLn9W/Vr5kvMVsnAXe6zhLawFRfIu5YsEOV74 yL6t/BwZJb4b7jD7sMhmtFqJzKjbM/vvf76U/6RlD4DKbGAD+V8qZn4zFjqIdCZt1K hGsLYO0/4liztbHT6u+TuXP4P+OW/GbzjAo1bCXHCITVLcewgjeuqUUdbJ1WlL9uJt +yp1YirorlW2A==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4CMHZG37jdz3wbj; Thu, 29 Oct 2020 08:46:30 +0100 (CET)
From: 
To: Joseph Touch 
CC: "tcpm@ietf.org" 
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
Thread-Index: AQHWrVP1GmQNezgGaUiTI243ShHdT6muLtHQ
Date: Thu, 29 Oct 2020 07:46:29 +0000
Message-ID: <30943_1603957590_5F9A7356_30943_42_8_787AE7BB302AE849A7480A190F8B933031568EA8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 29 Oct 2020 07:46:33 -0000

SGkgSm9lLA0KDQpJIHdvdWxkIHBlcnNvbmFsbHkgbGVhdmUgd2l0aCB0aGUgZm9sbG93aW5nOg0K
DQpPTEQ6IA0KICAgICAgICBDYXNlIDE6IEEgc2luZ2xlIG9jdGV0IG9mIG9wdGlvbi1raW5kLg0K
DQogICAgICAgIENhc2UgMjogQW4gb2N0ZXQgb2Ygb3B0aW9uLWtpbmQgKEtpbmQpLCBhbiBvY3Rl
dCBvZiBvcHRpb24tDQogICAgICAgIGxlbmd0aCwgYW5kIHRoZSBhY3R1YWwgb3B0aW9uLWRhdGEg
b2N0ZXRzLg0KDQpORVc6DQogICAgICAgIENhc2UgMTogQSBzaW5nbGUgb2N0ZXQgb2Ygb3B0aW9u
LWtpbmQuIFRoaXMgY2FzZSBpcyANCiAgICAgICAgZXhjbHVzaXZlbHkgcmVzZXJ2ZWQgdG8gIkVu
ZCBvZiBvcHRpb24gTGlzdCIgYW5kICJOby1PcGVyYXRpb24iDQogICAgICAgIGRlZmluZWQgaW4g
dGhpcyBkb2N1bWVudC4gDQoNCiAgICAgICAgQ2FzZSAyOiBBbiBvY3RldCBvZiBvcHRpb24ta2lu
ZCAoS2luZCksIGFuIG9jdGV0IG9mIG9wdGlvbi0NCiAgICAgICAgbGVuZ3RoLCBhbmQgdGhlIGFj
dHVhbCBvcHRpb24tZGF0YSBvY3RldHMuIFRoaXMgbGF5b3V0IGhhcyB0byBiZSANCiAgICAgICAg
dXNlZCB3aGVuIGRlZmluaW5nIGZ1dHVyZSBvcHRpb25zLiAgDQoNCkNoZWVycywNCk1lZA0KDQo+
IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb3NlcGggVG91Y2ggW21haWx0
bzp0b3VjaEBzdHJheWFscGhhLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAyOCBvY3RvYnJl
IDIwMjAgMTg6NTgNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5i
b3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gQ2PCoDogdGNwbUBpZXRmLm9yZw0KPiBPYmpldMKgOiBS
ZTogW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTkudHh0DQo+
IA0KPiBSaWdodCAtIHRoYXTigJlzIHRoZSBwb2ludCBvZiB0aGUgdGV4dCBiZWxvdyAtIGluY2x1
ZGluZyB3aGVyZSBpdA0KPiBhcHBlYXJzLg0KPiANCj4gUGVyaGFwcyBtb3JlIHN0cmljdGx5LCB3
ZSBzaG91bGQgc2F5IOKAnEFsbCBmdXR1cmUgb3B0aW9ucyBNVVNUIHVzZQ0KPiB0aGUga2luZC9s
ZW5ndGggZm9ybWF04oCdLiBCdXQgaXQgZG9lcyBuZWVkIGEgbnVtYmVyIChNVVNULSMjKS4NCj4g
DQo+IEpvZQ0KPiANCj4gPiBPbiBPY3QgMjgsIDIwMjAsIGF0IDg6NTYgQU0sIG1vaGFtZWQuYm91
Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4NCj4gPiBIaSBKb2UsDQo+ID4NCj4gPiBJIHdh
cyBhc3N1bWluZyB0aGF0ICJjYXNlIDIiIGlzIHVzZWQgZm9yIGRlZmluaW5nIG5ldyBvcHRpb25z
LiBJDQo+IGFncmVlIHRoYXQgd2Ugc2hvdWxkIHNheSB0aGlzIGV4cGxpY2l0bHkgaW4gdGhlIGRv
Yy4NCj4gPg0KPiA+IFRoYW5rcy4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQgDQoNCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl
cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2
ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv
cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs
ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl
cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw
dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg
c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK
VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs
IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuClRoYW5rIHlvdS4KCg==


From nobody Thu Oct 29 03:13:57 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6653A091B; Thu, 29 Oct 2020 03:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level: 
X-Spam-Status: No, score=-2.095 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, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIsKAb-GBm7P; Thu, 29 Oct 2020 03:13:54 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 E28E43A0112; Thu, 29 Oct 2020 03:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1603966433; x=1635502433; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=x56yHukJWt6pCj34WOmSvE7uBpt8Y7QcFGfm0ImaENw=; b=sH1TYIeogK0T4OtLsAPNXKvJ/V3PtddFGya+PBm+cyutFyoo+nJ+rx3s MagT/9oJh1JM8k67oyaWBBDtfJs2lFiU91Lkn26yM7wAMobySOhXVC+n2 GW+oKHASm4OG40XpxyZMFz+KFBMbz4Zjm1uG8Gv3BF1YJpy+2IYpcx7Ih mF1BktumHjLYJ5LthKXIVRxBY98xednmzahJAE1MuRdlvORelakjQ6J37 ekCg9ApO3AMFxa93mU+7anO0OphVJz+ll4DN7ZhPALgnV4t6qb83WJQDV cF42o8bqUeJ6RUjwcYs1m6+m6tSMcgegeNnvQo00hSIbPw8lA96HrhfZd Q==;
IronPort-SDR: FIFG9lzvycI6oiG0+8v/9NgqaWYa3lxodCZ1qq0MWtL71fZqRH+PQRSz4YgCZYy7pHzeeCkgXx +lFG7con2xow==
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 29 Oct 2020 11:13:50 +0100
IronPort-SDR: useQInOI3lh1AqC2pukS1B+Ynpj+JY9+t1B1OaY87Ius+hxFiy7o0KULwgR1quLCrgPoj8yiq4 prWX+v3jJDo7qbSIV1cZUWBo8S2pcbFtc=
X-IronPort-AV: E=Sophos;i="5.77,429,1596492000"; d="scan'208";a="219842138"
X-MGA-submission: =?us-ascii?q?MDHxHswLb4eFLBVJn30WH6SNnH4kaauwB3oBWW?= =?us-ascii?q?GL5IqVzMvLtxWpO1LiQ0riCg0YKN++YWBDbUEyK+ltoi9oLSmI+wUe16?= =?us-ascii?q?Bi3RQgbURcLBNPhY3kGfDe4Bd/hfCgfx93z5O7lUilh/uDAsptodSNOA?= =?us-ascii?q?g+2c+cdDmhIYhWNk/+vxVQjQ=3D=3D?=
Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 29 Oct 2020 11:13:50 +0100
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Oct 2020 11:13:50 +0100
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 29 Oct 2020 11:13:50 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.20) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Oct 2020 11:13:49 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j5jSDVsKe8gl0b5304aYOVV3X8ERxmF9V8HDRO21XLwFa+7+8/vejf24GIG8jq/0XP7BhpwnHVdnIKwHQCF6XYNUlE0O9vrEtb7wHmJrC4Tjph3XvSwESusJXWX52uOIZH0sdHtzYvKdC3NM0EENUPJ/nBRXOwvgOv9McW1W+PQ02I8CkVwyaBgWoWyBI2+zWEjnOr8FFcBbMiX54qn+nf6lCAv2qRffQMpkGBMjpkHMV82mGW55M140GpWpXPqnPrgkR5A2pzp0izPG6m1vyoqSr3Np0RJ407H6XI8SZjcpKLOlvty3ulZHCujELSYYHEKELIvDfiMVs5ri0R0GBQ==
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=x56yHukJWt6pCj34WOmSvE7uBpt8Y7QcFGfm0ImaENw=; b=QyAtAiaItLyBwTvjT0BOgrKlWCQGzkYxjSgX8OwDem2E2HLV2UxyxvQrBmxjJ0J2YD9sqe4rGmbScEUNRLwsWg2lLn0o+tBqGF+SsR3S8B3u1ERaFKi6F8WxByH8+RGhaGlf1WThIcD96QKjuLD5LeAaw0X4CAHUmC71Rpj79osgJxAU0N2fQXV8+3GPffjxZyojN4vNK9e7pbW7+uo9JpWtmrHQh9Yk6O4rV2WQLzivQFdMbLpU4VOJqhUU2XSCA2vpYY/BxLjLBKJThWzTtIOFZSqFacwq+G1ybLwRMuMn+cLRFihgWITztm8mDkDHVAr/Iq314vCm2xcOJQIbqQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:b::12) by LEJPR01MB0010.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Thu, 29 Oct 2020 10:13:49 +0000
Received: from LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE ([fe80::cd90:d2c4:eccf:600a]) by LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE ([fe80::cd90:d2c4:eccf:600a%5]) with mapi id 15.20.3477.033; Thu, 29 Oct 2020 10:13:49 +0000
From: 
To: , , 
Thread-Topic: MPTCP RobE
Thread-Index: Adat14Qs9LlNljS0SE+s1uwEYxjReQ==
Date: Thu, 29 Oct 2020 10:13:48 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be38025f-6dc3-48e1-ca77-08d87bf35419
x-ms-traffictypediagnostic: LEJPR01MB0010:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 55Gs+Q8yjV4hSXN0lGuixcfj+9zINsaQSDFva9CXsAZsj/z9UXc5PJGv8VjIU3BfcCKZG9izSsLImN5ifsQidGUCVE16THzI67k6XckB5RGcoeECR6KjF6WempN5SZbWqHn83SZvqATzbfcJvnxdzA6/bZeEc6ZQ3U4aKKmFk8qNOvXBRRuj/wEBwr/JD1GelbC8+w3izIosturTEDUF6YM6QcEWtuenISWrx42JT58sEuc+LPHeTB4z4/Ug4ba2zNnKCrg+3isxfkrrY2LczkiBJ5UwiUnmEDyhdAm9RxxWeNtL/4PMyt14Ue9gT1iuTJiIp0w2FQ/zY87uuL24IAkpJh/XqY6a5lK/h5cvQ20=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE;  SFS:(136003)(366004)(346002)(39860400002)(396003)(376002)(55016002)(76116006)(66446008)(9686003)(66556008)(66476007)(186003)(66946007)(64756008)(966005)(7116003)(7696005)(478600001)(26005)(110136005)(83380400001)(5660300002)(8936002)(8676002)(2906002)(3480700007)(4326008)(86362001)(316002)(71200400001)(33656002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: 073P7Cv3S9xiIfSpNYwOL/2mXGF2JuUiDMAxZfLDSVQX1JdPY7IWnr+G7kVW+Se+F47x4kWVFusZAZ5IE4RAwccYxSAijSpg5HyKzZPP828La4mWQelfPPwHFY7oGDInCFXrDLXwdNg1NzMHoLEXINDs8wgDodWM7lkyq95C4jK/RzbXu0pvOA+8T4izOrEjnLb/suNam18AM9H1l+3nmN3ykC50BY7SGHYY9Ze4hI0T8ieg52DhICX835S5qovPo6gPj69kDdphTkII5NO1v6h/nUVM6EQiIq1El9vPxtPb9XTdmPbd1OEDw9FsahE0HJT1rS0zUEdCjVQz0w4yS4ZwkSboQj1InpBAyhlMK6tyF8BCpicgYwGaDtzxITV5iP3IOSirGpkd8Ya2DVo4WU83Y56jj337sthp0oC8U/ZUO6QcsN80lp4Phk8EdlFNwxBn5h4bX6c0iyCzc3yI9LHZJdlcVJc3RHz4GMh5hcYdkrFKSRsdZQIAHbc2onaEXyTEX5LmcmHgu+UmSKNAAkfEhNg/k3Y66AjAr+ZVO3UcfB2IPA1SxOxkQIp9568SUeNJzaoiz4tBkzx43LYrlLdULZvIwVQGfIDODAZ1pxMpIbTZHd+HjAcSLvpP2nrEvyPi7cLgAOyZ2svTC5+HAQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE
X-MS-Exchange-CrossTenant-Network-Message-Id: be38025f-6dc3-48e1-ca77-08d87bf35419
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2020 10:13:48.9681 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wmgKImQzpaa1OeE7E8fHCK1WcXAMMwN7ek7l28Xn6fdixO4K+G9Z/ISdRPG855k4XDyCnlqDPP05+AOhXxNt+w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0010
X-TM-SNTS-SMTP: AC8019A14031A708508EF5E45EE62DCBA6160D34C726BE575F610A1CB21F4E6B2000:8
X-OriginatorOrg: telekom.de
Archived-At: 
Subject: [tcpm] MPTCP RobE
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: 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, 29 Oct 2020 10:13:56 -0000

Dear MPTCP enthusiasts,

as one of the authors of https://datatracker.ietf.org/doc/draft-amend-tcpm-=
mptcp-robe/, I kindly request feedback from you, in particular however from=
 the RFC6824/8684 authors and MPTCP implementers.

With MPTCP RobE (Robust Establishment) we address the lack of MPTCP to reli=
ably setup a MPTCP session, when the selected path for the initial session =
setup is malfunctioned. The MPTCP RFCs does not give any guidelines for thi=
s particular problem and it is left to the implementer to take care. For th=
at we propose and compare different strategies in the draft document, separ=
ated by their demand on MPTCP protocol changes. Apart from that our claim i=
s, that with these proposals compared to MPTCP, no additional security flaw=
s are raised and any potential computational overhead is minimized.

As we have presented at IETF 108 our progress (https://www.ietf.org/proceed=
ings/108/slides/slides-108-tcpm-draft-amend-tcpm-mptcp-robe-00-00) in terms=
 of the draft document, but moreover results from a mobile phone prototype =
over commercial Wi-Fi and cellular access, we aim for adoption at TCPM as s=
oon as possible. In that sense it would be very valuable to get your feedba=
ck, so that we can incorporate this in our considerations.

If you like to directly contribute to the draft document you will find the =
source at https://github.com/markusa/ietf-mptcp-robe.

Br

Markus


From nobody Thu Oct 29 09:29:49 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789743A0115 for ; Thu, 29 Oct 2020 09:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyw38dOtWGlt for ; Thu, 29 Oct 2020 09:29:46 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AF73A00D8 for ; Thu, 29 Oct 2020 09:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kSK+ydRDCyA64kgAW3NyCB/sW6fKo2P5mQPENpg5SmA=; b=1GxHxektZoWZBgWswNLfjem7j vQVdUNeeQZdKqJaIHbe4zRUaJyTI+wIU6xIndGh4iv5mYdmcG/G0JJfcfoZFBVK4g3qeiv3THywDa oyQtkJAj2x4Go1rvt7kqQwS5A9euKJ0iCYl+1bju+4m7rhl/eCW81v//O7ruU4rg1sDTS4WQPeTuX 3wRfh2AMsQG9hu5FD7Iq6iU9tNPgyStW1v/jR65CU+a4jnrtC2dFP4faZ/m5VIvEZY8rxEp96EfQh Mm7Lm8tQNe0BoT6JsjtyWjtV7+LUbIvwfkK9YtzbVGpbDUvXWyVnRVr7yeXQKDvuzz1/aPyaVscu4 Z/w/yR9Lw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50555 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kYAo1-0029yA-Dl; Thu, 29 Oct 2020 12:29:46 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA941BE5-2C18-47D8-878D-FAA232B33325"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <30943_1603957590_5F9A7356_30943_42_8_787AE7BB302AE849A7480A190F8B933031568EA8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 29 Oct 2020 09:29:40 -0700
Cc: "tcpm@ietf.org" 
Message-Id: <9F69A210-EC5D-4963-A10D-AB077A1374AE@strayalpha.com>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <30943_1603957590_5F9A7356_30943_42_8_787AE7BB302AE849A7480A190F8B933031568EA8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 29 Oct 2020 16:29:49 -0000

--Apple-Mail=_FA941BE5-2C18-47D8-878D-FAA232B33325
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Med,

I disagree.

TCP correctness relies on its ability to process unknown options. The =
requirement needs to be a MUST, =E2=80=9Chave to=E2=80=9D should never =
appear in an RFC when describing a protocol function.

It is a strict, testable implementation requirement that ensures that =
all future options are processed correctly. It also is a design =
requirement on new options (or at least a hurdle they need to overcome, =
as with TCP-opt-ext).

Wiggle words like =E2=80=9Cexclusively reserved=E2=80=9D and =E2=80=9Chas =
to be used=E2=80=9D are insufficient. This sort of constraint is exactly =
what MUST addresses.

Joe

> On Oct 29, 2020, at 12:46 AM,  =
 wrote:
>=20
> Hi Joe,
>=20
> I would personally leave with the following:
>=20
> OLD:=20
>        Case 1: A single octet of option-kind.
>=20
>        Case 2: An octet of option-kind (Kind), an octet of option-
>        length, and the actual option-data octets.
>=20
> NEW:
>        Case 1: A single octet of option-kind. This case is=20
>        exclusively reserved to "End of option List" and "No-Operation"
>        defined in this document.=20
>=20
>        Case 2: An octet of option-kind (Kind), an octet of option-
>        length, and the actual option-data octets. This layout has to =
be=20
>        used when defining future options. =20
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Joseph Touch [mailto:touch@strayalpha.com]
>> Envoy=C3=A9 : mercredi 28 octobre 2020 18:58
>> =C3=80 : BOUCADAIR Mohamed TGI/OLN 
>> Cc : tcpm@ietf.org
>> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
>>=20
>> Right - that=E2=80=99s the point of the text below - including where =
it
>> appears.
>>=20
>> Perhaps more strictly, we should say =E2=80=9CAll future options MUST =
use
>> the kind/length format=E2=80=9D. But it does need a number (MUST-##).
>>=20
>> Joe
>>=20
>>> On Oct 28, 2020, at 8:56 AM, mohamed.boucadair@orange.com wrote:
>>>=20
>>> Hi Joe,
>>>=20
>>> I was assuming that "case 2" is used for defining new options. I
>> agree that we should say this explicitly in the doc.
>>>=20
>>> Thanks.
>>>=20
>>> Cheers,
>>> Med=20
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org 
> https://www.ietf.org/mailman/listinfo/tcpm =


--Apple-Mail=_FA941BE5-2C18-47D8-878D-FAA232B33325
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, =
Med,

I =
disagree.

TCP =
correctness relies on its ability to process unknown options. The =
requirement needs to be a MUST, =E2=80=9Chave to=E2=80=9D should never =
appear in an RFC when describing a protocol function.

It is a strict, testable =
implementation requirement that ensures that all future options are =
processed correctly. It also is a design requirement on new options (or =
at least a hurdle they need to overcome, as with TCP-opt-ext).

Wiggle words like =
=E2=80=9Cexclusively reserved=E2=80=9D and =E2=80=9Chas to be used=E2=80=9D=
 are insufficient. This sort of constraint is exactly what MUST =
addresses.

Joe

On Oct 29, 2020, at 12:46 AM, =
<mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:

Hi Joe,

I would personally leave with =
the following:

OLD: 
       Case 1: A single =
octet of option-kind.

       Case 2: An octet of =
option-kind (Kind), an octet of option-
       length, and the =
actual option-data octets.

NEW:
       Case 1: A single =
octet of option-kind. This case is 
       exclusively =
reserved to "End of option List" and "No-Operation"
       defined in this =
document. 

       Case 2: An octet of =
option-kind (Kind), an octet of option-
       length, and the =
actual option-data octets. This layout has to be 
       used when defining =
future options.  

Cheers,
Med

-----Message d'origine-----
De : Joseph Touch [mailto:touch@strayalpha.com]
Envoy=C3=A9&nbs=
p;: mercredi 28 octobre 2020 18:58
=C3=80 : BOUCADAIR =
Mohamed TGI/OLN <mohamed.boucadair@orange.com>
Cc : =
tcpm@ietf.org
Objet : Re: [tcpm] I-D Action: =
draft-ietf-tcpm-rfc793bis-19.txt

Right - =
that=E2=80=99s the point of the text below - including where it
appears.

Perhaps more strictly, =
we should say =E2=80=9CAll future options MUST use
the =
kind/length format=E2=80=9D. But it does need a number (MUST-##).

Joe

On Oct 28, 2020, at 8:56 AM, mohamed.boucadair@orange.com wrote:

Hi Joe,

I was assuming that =
"case 2" is used for defining new options. I
agree that we should say this explicitly in the =
doc.

Thanks.

Cheers,
Med 


_______________________________________________________________=
__________________________________________________________

Ce message et ses pieces jointes =
peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.

This message =
and its attachments may contain confidential or privileged information =
that may be protected by law;
they should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please notify the =
sender and delete this message and its attachments.
As emails may be altered, Orange =
is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.

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

=

--Apple-Mail=_FA941BE5-2C18-47D8-878D-FAA232B33325--


From nobody Fri Oct 30 02:38:38 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA36A3A0B10 for ; Fri, 30 Oct 2020 02:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level: 
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 lzlDFRlWBf8J for ; Fri, 30 Oct 2020 02:38:34 -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 BB7413A0365 for ; Fri, 30 Oct 2020 02:38:33 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4CMy1413j6zBrgv; Fri, 30 Oct 2020 10:38:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604050712; bh=eqVH5S6GoUBxj6jz84uYSL5m9QLzJw9L3U4Stic92II=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=k7AP6WzDs6lWq8BNKtL3GYBkAU06+IE1Xjw+63kHM3okvlYDFhXUw+6HjL2I3gCwg rt1ssbDFhZ7cfd6BhEGX/uz7Y+6yC4AlFE7uq7k6T0vu/reVlmrDLVBM9gplu/qxfE 4ZM9HL9WYS0UlddNIZxAA0fYoeddhzCWtMI0SBYE2N6qMbrtYOnfE/TmEiBcLpbhSd ldhmxxxvOV1ynwEYxYJYN3phSiMhCZ1VNx7M6yShtrxtLsuazd9Id3gT+8FI3kXFxH Ao4Xxax2NmGWwlwp8UXC85GjQwQnKZ1xsmBYVKsPMHEwTu6FPgTSCn8QqgfYN1In9S M0NVeylOFGDpg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4CMy1407HSz3wc5; Fri, 30 Oct 2020 10:38:32 +0100 (CET)
From: 
To: Joseph Touch 
CC: "tcpm@ietf.org" 
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
Thread-Index: AQHWrhC5H9pyY0IAXEeAxcnzHXPRLqmv438w
Date: Fri, 30 Oct 2020 09:38:31 +0000
Message-ID: <30219_1604050712_5F9BDF18_30219_473_2_787AE7BB302AE849A7480A190F8B93303156AEDF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <30943_1603957590_5F9A7356_30943_42_8_787AE7BB302AE849A7480A190F8B933031568EA8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9F69A210-EC5D-4963-A10D-AB077A1374AE@strayalpha.com>
In-Reply-To: <9F69A210-EC5D-4963-A10D-AB077A1374AE@strayalpha.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.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303156AEDFOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 30 Oct 2020 09:38:36 -0000

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

SGkgSm9lLA0KDQpZb3UgbWFkZSBmYWlyIHBvaW50cywgYnV0IG9uZSBvZiB0aGUgcmVhc29ucyBJ
IHRoaW5rIHdlIGNhbiBhdm9pZCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGhlcmUgaXMgdGhhdCBw
cmFjdGljYWxseSBuZXcgb3B0aW9ucyBhcmUgbGlrZWx5IHRvIGJlIGRlZmluZWQgZmlyc3QgZm9s
bG93aW5nIHRoZSBsYXlvdXQgaW4gUkZDIDY5OTQuIFRoYXQgb25lIHJlcXVpcmVzIGEgbGVuZ3Ro
IHRvIGJlIHByZXNlbnQuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEpvc2VwaCBUb3VjaCBbbWFp
bHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tXQ0KRW52b3nDqSA6IGpldWRpIDI5IG9jdG9icmUgMjAy
MCAxNzozMA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFp
ckBvcmFuZ2UuY29tPg0KQ2MgOiB0Y3BtQGlldGYub3JnDQpPYmpldCA6IFJlOiBbdGNwbV0gSS1E
IEFjdGlvbjogZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xOS50eHQNCg0KSGksIE1lZCwNCg0K
SSBkaXNhZ3JlZS4NCg0KVENQIGNvcnJlY3RuZXNzIHJlbGllcyBvbiBpdHMgYWJpbGl0eSB0byBw
cm9jZXNzIHVua25vd24gb3B0aW9ucy4gVGhlIHJlcXVpcmVtZW50IG5lZWRzIHRvIGJlIGEgTVVT
VCwg4oCcaGF2ZSB0b+KAnSBzaG91bGQgbmV2ZXIgYXBwZWFyIGluIGFuIFJGQyB3aGVuIGRlc2Ny
aWJpbmcgYSBwcm90b2NvbCBmdW5jdGlvbi4NCg0KSXQgaXMgYSBzdHJpY3QsIHRlc3RhYmxlIGlt
cGxlbWVudGF0aW9uIHJlcXVpcmVtZW50IHRoYXQgZW5zdXJlcyB0aGF0IGFsbCBmdXR1cmUgb3B0
aW9ucyBhcmUgcHJvY2Vzc2VkIGNvcnJlY3RseS4gSXQgYWxzbyBpcyBhIGRlc2lnbiByZXF1aXJl
bWVudCBvbiBuZXcgb3B0aW9ucyAob3IgYXQgbGVhc3QgYSBodXJkbGUgdGhleSBuZWVkIHRvIG92
ZXJjb21lLCBhcyB3aXRoIFRDUC1vcHQtZXh0KS4NCg0KV2lnZ2xlIHdvcmRzIGxpa2Ug4oCcZXhj
bHVzaXZlbHkgcmVzZXJ2ZWTigJ0gYW5kIOKAnGhhcyB0byBiZSB1c2Vk4oCdIGFyZSBpbnN1ZmZp
Y2llbnQuIFRoaXMgc29ydCBvZiBjb25zdHJhaW50IGlzIGV4YWN0bHkgd2hhdCBNVVNUIGFkZHJl
c3Nlcy4NCg0KSm9lDQoNCg0KT24gT2N0IDI5LCAyMDIwLCBhdCAxMjo0NiBBTSwgPG1vaGFtZWQu
Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+
PiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA
b3JhbmdlLmNvbT4+IHdyb3RlOg0KDQpIaSBKb2UsDQoNCkkgd291bGQgcGVyc29uYWxseSBsZWF2
ZSB3aXRoIHRoZSBmb2xsb3dpbmc6DQoNCk9MRDoNCiAgICAgICBDYXNlIDE6IEEgc2luZ2xlIG9j
dGV0IG9mIG9wdGlvbi1raW5kLg0KDQogICAgICAgQ2FzZSAyOiBBbiBvY3RldCBvZiBvcHRpb24t
a2luZCAoS2luZCksIGFuIG9jdGV0IG9mIG9wdGlvbi0NCiAgICAgICBsZW5ndGgsIGFuZCB0aGUg
YWN0dWFsIG9wdGlvbi1kYXRhIG9jdGV0cy4NCg0KTkVXOg0KICAgICAgIENhc2UgMTogQSBzaW5n
bGUgb2N0ZXQgb2Ygb3B0aW9uLWtpbmQuIFRoaXMgY2FzZSBpcw0KICAgICAgIGV4Y2x1c2l2ZWx5
IHJlc2VydmVkIHRvICJFbmQgb2Ygb3B0aW9uIExpc3QiIGFuZCAiTm8tT3BlcmF0aW9uIg0KICAg
ICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgICAgIENhc2UgMjogQW4gb2N0ZXQg
b2Ygb3B0aW9uLWtpbmQgKEtpbmQpLCBhbiBvY3RldCBvZiBvcHRpb24tDQogICAgICAgbGVuZ3Ro
LCBhbmQgdGhlIGFjdHVhbCBvcHRpb24tZGF0YSBvY3RldHMuIFRoaXMgbGF5b3V0IGhhcyB0byBi
ZQ0KICAgICAgIHVzZWQgd2hlbiBkZWZpbmluZyBmdXR1cmUgb3B0aW9ucy4NCg0KQ2hlZXJzLA0K
TWVkDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IEpvc2VwaCBUb3VjaCBb
bWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tXQ0KRW52b3nDqSA6IG1lcmNyZWRpIDI4IG9jdG9i
cmUgMjAyMCAxODo1OA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4N
CkNjIDogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFt0
Y3BtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE5LnR4dA0KDQpSaWdo
dCAtIHRoYXTigJlzIHRoZSBwb2ludCBvZiB0aGUgdGV4dCBiZWxvdyAtIGluY2x1ZGluZyB3aGVy
ZSBpdA0KYXBwZWFycy4NCg0KUGVyaGFwcyBtb3JlIHN0cmljdGx5LCB3ZSBzaG91bGQgc2F5IOKA
nEFsbCBmdXR1cmUgb3B0aW9ucyBNVVNUIHVzZQ0KdGhlIGtpbmQvbGVuZ3RoIGZvcm1hdOKAnS4g
QnV0IGl0IGRvZXMgbmVlZCBhIG51bWJlciAoTVVTVC0jIykuDQoNCkpvZQ0KDQoNCk9uIE9jdCAy
OCwgMjAyMCwgYXQgODo1NiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86
bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCkhpIEpvZSwNCg0KSSB3YXMg
YXNzdW1pbmcgdGhhdCAiY2FzZSAyIiBpcyB1c2VkIGZvciBkZWZpbmluZyBuZXcgb3B0aW9ucy4g
SQ0KYWdyZWUgdGhhdCB3ZSBzaG91bGQgc2F5IHRoaXMgZXhwbGljaXRseSBpbiB0aGUgZG9jLg0K
DQoNClRoYW5rcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0
IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u
ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJl
IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz
IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQph
IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz
LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0
aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh
IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2Ug
YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl
ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQg
bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u
DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5
IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4N
CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh
Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5r
IHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD
ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv
cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv
bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp
b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg
c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj
ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz
IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug
bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt
ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy
aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz
aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz
YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu
b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l
bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt
ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo
YW5rIHlvdS4KCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt
c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdl
aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg
bm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky
LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+SGkgSm9lLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+WW91IG1hZGUgZmFpciBwb2ludHMsIGJ1dCBvbmUgb2YgdGhlIHJlYXNvbnMgSSB0aGlu
ayB3ZSBjYW4gYXZvaWQgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBoZXJlIGlzIHRoYXQgcHJhY3Rp
Y2FsbHkgbmV3IG9wdGlvbnMgYXJlDQogbGlrZWx5IHRvIGJlIGRlZmluZWQgZmlyc3QgZm9sbG93
aW5nIHRoZSBsYXlvdXQgaW4gUkZDIDY5OTQuIFRoYXQgb25lIHJlcXVpcmVzIGEgbGVuZ3RoIHRv
IGJlIHByZXNlbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBK
b3NlcGggVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbV0NCjxicj4NCjxiPkVudm95
w6kmbmJzcDs6PC9iPiBqZXVkaSAyOSBvY3RvYnJlIDIwMjAgMTc6MzA8YnI+DQo8Yj7DgCZuYnNw
Ozo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9y
YW5nZS5jb20mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiB0Y3BtQGlldGYub3JnPGJyPg0KPGI+
T2JqZXQmbmJzcDs6PC9iPiBSZTogW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNwbS1y
ZmM3OTNiaXMtMTkudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SGksIE1lZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgZGlzYWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRDUCBjb3JyZWN0bmVzcyByZWxpZXMgb24gaXRzIGFiaWxpdHkgdG8gcHJv
Y2VzcyB1bmtub3duIG9wdGlvbnMuIFRoZSByZXF1aXJlbWVudCBuZWVkcyB0byBiZSBhIE1VU1Qs
IOKAnGhhdmUgdG/igJ0gc2hvdWxkIG5ldmVyIGFwcGVhciBpbiBhbiBSRkMgd2hlbiBkZXNjcmli
aW5nIGEgcHJvdG9jb2wgZnVuY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGEgc3RyaWN0LCB0ZXN0YWJsZSBpbXBsZW1lbnRh
dGlvbiByZXF1aXJlbWVudCB0aGF0IGVuc3VyZXMgdGhhdCBhbGwgZnV0dXJlIG9wdGlvbnMgYXJl
IHByb2Nlc3NlZCBjb3JyZWN0bHkuIEl0IGFsc28gaXMgYSBkZXNpZ24gcmVxdWlyZW1lbnQgb24g
bmV3IG9wdGlvbnMgKG9yIGF0IGxlYXN0IGEgaHVyZGxlIHRoZXkgbmVlZCB0byBvdmVyY29tZSwg
YXMgd2l0aCBUQ1Atb3B0LWV4dCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPldpZ2dsZSB3b3JkcyBsaWtlIOKAnGV4Y2x1c2l2ZWx5IHJlc2Vy
dmVk4oCdIGFuZCDigJxoYXMgdG8gYmUgdXNlZOKAnSBhcmUgaW5zdWZmaWNpZW50LiBUaGlzIHNv
cnQgb2YgY29uc3RyYWludCBpcyBleGFjdGx5IHdoYXQgTVVTVCBhZGRyZXNzZXMuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
T2N0IDI5LCAyMDIwLCBhdCAxMjo0NiBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsg
Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVk
LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvZSw8YnI+DQo8YnI+DQpJ
IHdvdWxkIHBlcnNvbmFsbHkgbGVhdmUgd2l0aCB0aGUgZm9sbG93aW5nOjxicj4NCjxicj4NCk9M
RDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q2FzZSAxOiBBIHNpbmds
ZSBvY3RldCBvZiBvcHRpb24ta2luZC48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDtDYXNlIDI6IEFuIG9jdGV0IG9mIG9wdGlvbi1raW5kIChLaW5k
KSwgYW4gb2N0ZXQgb2Ygb3B0aW9uLTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO2xlbmd0aCwgYW5kIHRoZSBhY3R1YWwgb3B0aW9uLWRhdGEgb2N0ZXRzLjxi
cj4NCjxicj4NCk5FVzo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtDYXNlIDE6IEEgc2luZ2xlIG9jdGV0IG9mIG9wdGlvbi1raW5kLiBUaGlzIGNhc2UgaXM8
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXhjbHVzaXZlbHkgcmVzZXJ2
ZWQgdG8gJnF1b3Q7RW5kIG9mIG9wdGlvbiBMaXN0JnF1b3Q7IGFuZCAmcXVvdDtOby1PcGVyYXRp
b24mcXVvdDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtk
ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO0Nhc2UgMjogQW4gb2N0ZXQgb2Ygb3B0aW9uLWtpbmQgKEtpbmQpLCBhbiBv
Y3RldCBvZiBvcHRpb24tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7bGVuZ3RoLCBhbmQgdGhlIGFjdHVhbCBvcHRpb24tZGF0YSBvY3RldHMuIFRoaXMgbGF5
b3V0IGhhcyB0byBiZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2Vk
IHdoZW4gZGVmaW5pbmcgZnV0dXJlIG9wdGlvbnMuICZuYnNwOzxicj4NCjxicj4NCkNoZWVycyw8
YnI+DQpNZWQ8YnI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12
YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0tLS1NZXNzYWdl
IGQnb3JpZ2luZS0tLS0tPGJyPg0KRGUmbmJzcDs6IEpvc2VwaCBUb3VjaCBbPGEgaHJlZj0ibWFp
bHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tIj5tYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb208L2E+
XTxicj4NCkVudm95w6kmbmJzcDs6IG1lcmNyZWRpIDI4IG9jdG9icmUgMjAyMCAxODo1ODxicj4N
CsOAJm5ic3A7OiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOICZsdDs8YSBocmVmPSJtYWlsdG86
bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv
bTwvYT4mZ3Q7PGJyPg0KQ2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50
Y3BtQGlldGYub3JnPC9hPjxicj4NCk9iamV0Jm5ic3A7OiBSZTogW3RjcG1dIEktRCBBY3Rpb246
IGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTkudHh0PGJyPg0KPGJyPg0KUmlnaHQgLSB0aGF0
4oCZcyB0aGUgcG9pbnQgb2YgdGhlIHRleHQgYmVsb3cgLSBpbmNsdWRpbmcgd2hlcmUgaXQ8YnI+
DQphcHBlYXJzLjxicj4NCjxicj4NClBlcmhhcHMgbW9yZSBzdHJpY3RseSwgd2Ugc2hvdWxkIHNh
eSDigJxBbGwgZnV0dXJlIG9wdGlvbnMgTVVTVCB1c2U8YnI+DQp0aGUga2luZC9sZW5ndGggZm9y
bWF04oCdLiBCdXQgaXQgZG9lcyBuZWVkIGEgbnVtYmVyIChNVVNULSMjKS48YnI+DQo8YnI+DQpK
b2U8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE9jdCAyOCwgMjAyMCwgYXQgODo1NiBBTSwN
CjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8YnI+DQo8YnI+DQpIaSBKb2UsPGJyPg0KPGJy
Pg0KSSB3YXMgYXNzdW1pbmcgdGhhdCAmcXVvdDtjYXNlIDImcXVvdDsgaXMgdXNlZCBmb3IgZGVm
aW5pbmcgbmV3IG9wdGlvbnMuIEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5hZ3JlZSB0aGF0IHdlIHNo
b3VsZCBzYXkgdGhpcyBleHBsaWNpdGx5IGluIHRoZSBkb2MuPGJyPg0KPGJyPg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48
YnI+DQpUaGFua3MuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCk1lZDxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KQ2UgbWVzc2FnZSBldCBz
ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp
ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPg0KcGFzIGV0
cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv
dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8
YnI+DQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq
b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh
bHRlcmF0aW9uLDxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl
IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8
YnI+DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl
bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg
bGF3Ozxicj4NCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg
d2l0aG91dCBhdXRob3Jpc2F0aW9uLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h
aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz
c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg
T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk
LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPGJyPg0KPGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0Y3BtIG1haWxp
bmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+dGNwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy
Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
dGNwbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby90Y3BtPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll
Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll
bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz
LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj
dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0
ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz
YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n
ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl
LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u
IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli
dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k
IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi
ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl
ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_787AE7BB302AE849A7480A190F8B93303156AEDFOPEXCAUBMA2corp_--


From nobody Fri Oct 30 09:33:44 2020
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E353A1019 for ; Fri, 30 Oct 2020 09:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y65v3J44wgV for ; Fri, 30 Oct 2020 09:33:41 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB5F3A1016 for ; Fri, 30 Oct 2020 09:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ej1XtKGVB9lf4uCWPniJuZayOSqlAcdllE5ntMifTJ4=; b=M0+GTi2bS7Gf5GMpQQ3J6wCiw TxtnINSDIfWy2LYiIFJL4ZslMg+v+VvWMhPKaPFstvnKMpNamAMbMM9o/od9uumWBsUgQMmmEfVXG 4c0gEpKsqcpG2w3eZylOKw2sI8oF01ihMzPPk3sJcg/RLoJgaRVX9nH6/01lgRen7LbL70p7bC/V+ 5vWmVb2taK7X9tJso7qjpU4RE/gXo96kD5vdirbBMlbGB2/ldibFmj7XWxo8/1ANA/xICZXp1ZLB1 2DhwloviDuXpXbEEc3nyzcJSXjc2DZ0K0SXLX3K76fr4daEwM2TFMuocFRg0uehlk2cUD9PKB4ArQ /Er+N66Tg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51721 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kYXLM-002ihW-56; Fri, 30 Oct 2020 12:33:41 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B065409-8943-4D71-BB17-4436E1BE567E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch 
In-Reply-To: <30219_1604050712_5F9BDF18_30219_473_2_787AE7BB302AE849A7480A190F8B93303156AEDF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Fri, 30 Oct 2020 09:33:35 -0700
Cc: "tcpm@ietf.org" 
Message-Id: <7472F873-6FDE-4EE8-B964-00F12AF789A3@strayalpha.com>
References: <160380215231.12643.15441692678290990557@ietfa.amsl.com>  <64caaf62-c6fc-b9b3-27d3-303aa8160e4f@mti-systems.com> <23860_1603869121_5F9919C1_23860_473_1_787AE7BB302AE849A7480A190F8B933031568163@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <23695_1603900584_5F9994A8_23695_407_1_787AE7BB302AE849A7480A190F8B93303156882D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>  <30943_1603957590_5F9A7356_30943_42_8_787AE7BB302AE849A7480A190F8B933031568EA8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9F69A210-EC5D-4963-A10D-AB077A1374AE@strayalpha.com> <30219_1604050712_5F9BDF18_30219_473_2_787AE7BB302AE849A7480A190F8B93303156AEDF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.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, 30 Oct 2020 16:33:44 -0000

--Apple-Mail=_9B065409-8943-4D71-BB17-4436E1BE567E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Med,

RFC6994 applies only to experimental options. This doc still needs to =
indicate the constraint on use of the standards-track (at least as =
typically required) code points.

Those options were assigned most recently in March of this past year =
(MPTCP) and May 2019 (even though Experimental).

Joe

> On Oct 30, 2020, at 2:38 AM,  =
 wrote:
>=20
> Hi Joe,
> =20
> You made fair points, but one of the reasons I think we can avoid the =
normative language here is that practically new options are likely to be =
defined first following the layout in RFC 6994. That one requires a =
length to be present.
> =20
> Cheers,
> Med
> =20
> De : Joseph Touch [mailto:touch@strayalpha.com]=20
> Envoy=C3=A9 : jeudi 29 octobre 2020 17:30
> =C3=80 : BOUCADAIR Mohamed TGI/OLN 
> Cc : tcpm@ietf.org
> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
> =20
> Hi, Med,
> =20
> I disagree.
> =20
> TCP correctness relies on its ability to process unknown options. The =
requirement needs to be a MUST, =E2=80=9Chave to=E2=80=9D should never =
appear in an RFC when describing a protocol function.
> =20
> It is a strict, testable implementation requirement that ensures that =
all future options are processed correctly. It also is a design =
requirement on new options (or at least a hurdle they need to overcome, =
as with TCP-opt-ext).
> =20
> Wiggle words like =E2=80=9Cexclusively reserved=E2=80=9D and =E2=80=9Cha=
s to be used=E2=80=9D are insufficient. This sort of constraint is =
exactly what MUST addresses.
> =20
> Joe
>=20
>=20
> On Oct 29, 2020, at 12:46 AM, > > wrote:
> =20
> Hi Joe,
>=20
> I would personally leave with the following:
>=20
> OLD:=20
>        Case 1: A single octet of option-kind.
>=20
>        Case 2: An octet of option-kind (Kind), an octet of option-
>        length, and the actual option-data octets.
>=20
> NEW:
>        Case 1: A single octet of option-kind. This case is=20
>        exclusively reserved to "End of option List" and "No-Operation"
>        defined in this document.=20
>=20
>        Case 2: An octet of option-kind (Kind), an octet of option-
>        length, and the actual option-data octets. This layout has to =
be=20
>        used when defining future options. =20
>=20
> Cheers,
> Med
>=20
>=20
> -----Message d'origine-----
> De : Joseph Touch [mailto:touch@strayalpha.com =
]
> Envoy=C3=A9 : mercredi 28 octobre 2020 18:58
> =C3=80 : BOUCADAIR Mohamed TGI/OLN >
> Cc : tcpm@ietf.org 
> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
>=20
> Right - that=E2=80=99s the point of the text below - including where =
it
> appears.
>=20
> Perhaps more strictly, we should say =E2=80=9CAll future options MUST =
use
> the kind/length format=E2=80=9D. But it does need a number (MUST-##).
>=20
> Joe
>=20
>=20
> On Oct 28, 2020, at 8:56 AM, mohamed.boucadair@orange.com =
 wrote:
>=20
> Hi Joe,
>=20
> I was assuming that "case 2" is used for defining new options. I
> agree that we should say this explicitly in the doc.
>=20
>=20
> Thanks.
>=20
> Cheers,
> Med=20
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org 
> https://www.ietf.org/mailman/listinfo/tcpm =

> =20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--Apple-Mail=_9B065409-8943-4D71-BB17-4436E1BE567E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, =
Med,

RFC6994 applies =
only to experimental options. This doc still needs to indicate the =
constraint on use of the standards-track (at least as typically =
required) code points.

Those options were assigned most recently in March of this =
past year (MPTCP) and May 2019 (even though Experimental).

Joe
On Oct =
30, 2020, at 2:38 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:










Hi Joe,

 
You made fair points, =
but one of the reasons I think we can avoid the normative language here =
is that practically new options are
 likely to be defined first following the layout in RFC 6994. That one =
requires a length to be present.

 
Cheers,
Med
 






De : Joseph Touch [mailto:touch@strayalpha.com]


Envoy=C3=A9 : jeudi 29 octobre 2020 17:30

=C3=80 : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>

Cc : tcpm@ietf.org

Objet : Re: [tcpm] I-D Action: =
draft-ietf-tcpm-rfc793bis-19.txt




 
Hi, Med,


 




I disagree.




 




TCP correctness relies on its =
ability to process unknown options. The requirement needs to be a MUST, =
=E2=80=9Chave to=E2=80=9D should never appear in an RFC when describing =
a protocol function.




 




It is a strict, testable =
implementation requirement that ensures that all future options are =
processed correctly. It also is a design requirement on new options (or =
at least a hurdle they need to overcome, as with TCP-opt-ext).




 




Wiggle words like =E2=80=9Cexclusiv=
ely reserved=E2=80=9D and =E2=80=9Chas to be used=E2=80=9D are =
insufficient. This sort of constraint is exactly what MUST =
addresses.




 




Joe















On Oct 29, 2020, at 12:46 AM, =
<mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:


 


Hi Joe,



I would personally leave with the following:



OLD: 

       Case 1: A single octet of =
option-kind.



       Case 2: An octet of =
option-kind (Kind), an octet of option-

       length, and the actual =
option-data octets.



NEW:

       Case 1: A single octet of =
option-kind. This case is 

       exclusively reserved to "End =
of option List" and "No-Operation"

       defined in this document. 



       Case 2: An octet of =
option-kind (Kind), an octet of option-

       length, and the actual =
option-data octets. This layout has to be 

       used when defining future =
options.  



Cheers,

Med








-----Message d'origine-----

De : Joseph Touch [mailto:touch@strayalpha.com]

Envoy=C3=A9 : mercredi 28 octobre 2020 18:58

=C3=80 : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>

Cc : tcpm@ietf.org
Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt



Right - that=E2=80=99s the point of the text below - including where =
it

appears.



Perhaps more strictly, we should say =E2=80=9CAll future options MUST =
use

the kind/length format=E2=80=9D. But it does need a number (MUST-##).



Joe








On Oct 28, 2020, at 8:56 AM,
mohamed.boucadair@orange.com wrote:



Hi Joe,



I was assuming that "case 2" is used for defining new options. I


agree that we should say this explicitly in the doc.








Thanks.



Cheers,

Med 








=
__________________________________________________________________________=
_______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.



This message and its attachments may contain confidential or privileged =
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and =
delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.

Thank you.



_______________________________________________

tcpm mailing list

tcpm@ietf.org

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






 








_______________________________________________________________=
__________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.



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

=

--Apple-Mail=_9B065409-8943-4D71-BB17-4436E1BE567E--


From nobody Fri Oct 30 10:04:11 2020
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 EED423A0CBB; Fri, 30 Oct 2020 10:04:09 -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: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <160407744987.30256.18191482261214707117@ietfa.amsl.com>
Date: Fri, 30 Oct 2020 10:04:09 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2020 17:04:10 -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           : YANG Model for Transmission Control Protocol (TCP) Configuration
        Authors         : Michael Scharf
                          Vishal Murgai
                          Mahesh Jethanandani
	Filename        : draft-ietf-tcpm-yang-tcp-00.txt
	Pages           : 19
	Date            : 2020-10-29

Abstract:
   This document specifies a YANG model for TCP on devices that are
   configured by network management protocols.  The YANG model defines a
   container for all TCP connections and groupings of some of the
   parameters that can be imported and used in TCP implementations or by
   other models that need to configure TCP parameters.  The model
   includes definitions from YANG Groupings for TCP Client and TCP
   Servers (I-D.ietf-netconf-tcp-client-server).  The model is NMDA (RFC
   8342) compliant.


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

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


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/