From nobody Tue Feb 2 02:08:35 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9891A3A18FE; Tue, 2 Feb 2021 02:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb_RrxjdsA07; Tue, 2 Feb 2021 02:08:31 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 AF31B3A18FB; Tue, 2 Feb 2021 02:08:28 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:b0a8:2ece:191:5755] (unknown [IPv6:2a00:ac00:4000:400:b0a8:2ece:191:5755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 786C4600057; Tue, 2 Feb 2021 12:08:19 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1612260499; bh=u7gHg4xz/Wuofe25YG6QACxH/X4zn548IhTpHoAR/wo=; h=From:Subject:Date:References:Cc:To; b=uDuROJfKOXlwp3A4+6Kb3EBEy4bchhmwdKcNMevOdFNpv7bYlw9ET4xf5/+o1yG6j diVYAd6ghzDLzjc3iiRV2i7jAvJ0At4kzQKHBztQyLhIxIuB7HtNA7QaInptztZXXC XQ1h7s9zE/BanN380vzbGe2OoXo4kja/GdFo4ths= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_38EA99B5-601F-4D79-A3A8-8E1B6C1A0437"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 2 Feb 2021 12:08:17 +0200 References: <161225937724.27313.818157708316341405@ietfa.amsl.com> Cc: draft-eggert-tcpm-rfc8312bis@ietf.org, vidhi_goel@apple.com, Injong Rhee To: tcpm IETF list Message-Id: X-MailScanner-ID: 786C4600057.A0FB2 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-eggert-tcpm-rfc8312bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 10:08:34 -0000 --Apple-Mail=_38EA99B5-601F-4D79-A3A8-8E1B6C1A0437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we just submitted the -01 version of the CUBIC bis document. While the document still needs some editorial work to reflect the = significant increase in deployment CUBIC has seen since 8312 was = published, it otherwise rolls in all the algorithm changes that have = been made to CUBIC since. Therefore, we'd like to ask the WG to determine if this is ready for = adoption. > Name: draft-eggert-tcpm-rfc8312bis > Revision: 01 > Title: CUBIC for Fast Long-Distance Networks > Document date: 2021-02-02 > Group: Individual Submission > Pages: 26 > URL: = https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-01.txt > Status: = https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/ > Html: = https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-01.html > Htmlized: = https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-eggert-tcpm-rfc8312bis-01 Thanks, Lars --Apple-Mail=_38EA99B5-601F-4D79-A3A8-8E1B6C1A0437 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmAZJJEACgkQVLXDCb9w wVe1dQ/6Ajo6IoH3y8PyRSn3cqNUYAUTiD/SfJu4cpPGse8VhHiIosaM2AWJqJlG 8agvsE9B9cYGqHLdzZ09oK6a8k6yUM+wJTDM4g4/UpXs5JGveAiPUlarPJKlOm1T 30cFoy9d/ls39vvvz4Ozi2qKietuT9fdCWF4P6xP+UAw5Kmm/pPSuiiMXGsWRfY8 yPQv5UgdgrKrQLpN2KQFGhFIkBX5I0BQkGgesH5mYebvnw/P75fSDOGT8Y6a6ypN GXsd02ezKNTlCXBDh5SlWJk8ywrZqb6tTC845fbd4Qz6FBZKEPg44FuGkIUsWoa+ 0dM/8bSIcuT3t3+U2PfISP9/N0Z96wCPlS007dXDSxj0fgfiPimR3EWECsNY+yoT 2BNIFbPJvqAFSKUa6xnkCjRlyzW1QkRMteC2bExqvnegNbmv7tuEx8fe1r9zTEVP glSenwWgGs/xPgixrNSeSlMZ3EPQYpAKgDPow289FrQcH//656Stq9BAqQr6fJLM yb2vBNJdeQ3IidkbSz+QJAU/QBx11WkyKVtxicUZd4cD58lUsthocRY6g9hAVzA3 7zfHYN7ifRc47rdyqngYZa6ZgSfOsA9Ciual+na13Kw8wM8d6zFk846HOBggn/T9 2sWFKo/4TLpFq0I64/DDrbAmJDnaPUrrWmuutUjwPZY2hNrHpuo= =Vpck -----END PGP SIGNATURE----- --Apple-Mail=_38EA99B5-601F-4D79-A3A8-8E1B6C1A0437-- From nobody Tue Feb 2 12:29:06 2021 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 C32313A07E2 for ; Tue, 2 Feb 2021 12:29:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161229774378.16717.14002054841152178919@ietfa.amsl.com> Date: Tue, 02 Feb 2021 12:29:03 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 20:29:04 -0000 Changed milestone "Submit RFC6937bis document to the IESG for publication as a Proposed Standard RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Tue Feb 2 13:33:49 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5872C3A0A5E; Tue, 2 Feb 2021 13:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hiFQJpBCY6TX; Tue, 2 Feb 2021 13:33:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1921F3A0A3F; Tue, 2 Feb 2021 13:33:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 25A32F40737; Tue, 2 Feb 2021 13:33:31 -0800 (PST) To: ananth.nantha@yahoo.com, gregory.ietf@gmail.com, ekr@rtfm.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: martin.h.duke@gmail.com, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210202213331.25A32F40737@rfc-editor.org> Date: Tue, 2 Feb 2021 13:33:31 -0800 (PST) Archived-At: Subject: [tcpm] [Errata Held for Document Update] RFC5926 (6413) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 21:33:47 -0000 The following errata report has been held for document update for RFC5926, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6413 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ananth Rajadurai Date Reported: 2021-01-28 Held by: Martin Duke (IESG) Section: 3.1.1.2 Original Text ------------- In section 3.1.1.2 Page 8, figure 1, +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + KDF-AES-128-CMAC + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + Input : MK (Master_Key, the variable-length shared secret) + + : I (Input, i.e., the input data of the PRF) + + : MKlen (length of MK in octets) + + : len (length of M in octets) + + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + + + +-------------------------------------------------------------------+ Corrected Text -------------- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + KDF-AES-128-CMAC + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + Input : MK (Master_Key, the variable-length shared secret) + + : I (Input, i.e., the input data of the PRF) + + : MKlen (length of MK in octets) + + : len (length of I in octets) + + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + + + +-------------------------------------------------------------------+ Notes ----- In Input, "len" is described as (length of "M' in octets), but there is no "M" in the input, but it is supposed to mention the length of the Input Data "I", so it should be (length of "I" in octets) -------------------------------------- RFC5926 (draft-ietf-tcpm-tcp-ao-crypto-03) -------------------------------------- Title : Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) Publication Date : June 2010 Author(s) : G. Lebovitz, E. Rescorla Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Feb 2 23:12:36 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980FB3A1512 for ; Tue, 2 Feb 2021 23:12:33 -0800 (PST) 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 kG-Jda7g0ogi for ; Tue, 2 Feb 2021 23:12:29 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 9A3CC3A1510 for ; Tue, 2 Feb 2021 23:12:29 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id r13so6797629qvm.11 for ; Tue, 02 Feb 2021 23:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=08h0TYdAjy5qM4bUmSZ4cWiNAYLwrZi09csY8btzhug=; b=RNn8sJ+CW7ArXXiNk0wtem/3WzAiUkdKg53tdG9ytTUgUkKhMA9GvMuu5doF0LF+xO iiCtYjxsoIVP86KAzRZvs1hpv03mz1+mPvdZejPcnUn6KHcw993FzAaPxJ19e5U1cB4O LFBzPrGc10/juHbr2iwq/suWXC+quJc3iR9do83sFEEEtuypfRwjkdJft6GGh1qJk9vT PivSLSGj9gcexhREyHW0GWXXGhZIERHNjzoZBfCjwnFWjAcpqH/l/ctArrAmB8JPMxUB 441GEzaYkdZPKqv5e5YEtsXo53TmCL7/edgRaHu31stQB0EA00HOmmRc0k1sbnyX+6c8 PVkQ== 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=08h0TYdAjy5qM4bUmSZ4cWiNAYLwrZi09csY8btzhug=; b=S8D+u0KPoyeTd2cECWN2X3BoKuezlxRksuXe7H4+BlNDufsag7jaq9+G7vhd/b3I7w O0LZGB4tPqb6X9/okNxGqD/wANK7vd1XTWpT0gwVH/4wgBNcMgS4GtvwdNppEaMz93i9 LWdHZQR89V3RmjsggBeaZXf2f1h2lrh8XD9F2BTQ3BgV8q6ICkB75rTYBpOxSQD/96e9 t2o5di7hX9omHIju8hW0OZPUVdnvsegKc0XLUX3gmO2G9h5aGo/zMs+v8JeNbWjSDj5R 3K69MAZ+LkL2RquvUfspYd9ES/9wg4WQJXblNBJgvtvCAH/970mYwKn9ztwBa2WJ5wi3 EVdg== X-Gm-Message-State: AOAM531NS6U+2cvIxa5a+xIH1RnrXZKYCH5D8GuNRmv+Yyl//qStEGmX 0JnipThC3V6genXhYbm/qIIk65cfvlFGUFhrYTmTsCm+ X-Google-Smtp-Source: ABdhPJzFQ8Ti78OKRINbnha7u8H7GJWls+cf4wAaJvauZQYpddf4F4NRHYwzX7miNmzBDE4j8QVDawLnIUuHvYJyn94= X-Received: by 2002:ad4:5445:: with SMTP id h5mr1697729qvt.22.1612336348315; Tue, 02 Feb 2021 23:12:28 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> In-Reply-To: <161233469809.31214.294457730576935197@ietfa.amsl.com> From: Yoshifumi Nishida Date: Tue, 2 Feb 2021 23:12:17 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000004cc3c605ba694fb5" Archived-At: Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 07:12:34 -0000 --0000000000004cc3c605ba694fb5 Content-Type: text/plain; charset="UTF-8" Hi folks, I prepared a draft for SYN option space extensions. I know this is a difficult issue in TCP and has been discussed for a long time. But, I'm thinking that it might be a good time to discuss it again. Key ideas of the draft are the followings. 1: drastic changes in TCP's spec will not be required (it does not require updating TCP header format nor using multiple SYN packets or additional SYN-like packets) 2: utilize the option negotiation schemes in mptcp for generic purposes. so, I think it can be considered middlebox friendly. 3: it has some limitations (e.g it can only extend around 30-40 bytes for SYN option space). But, if it's combined with EDO, we can use more option space. (depends on how EDO draft will progress, though) Please let me know if you have any questions or comments or suggestions. Thank you so much! -- Yoshi ---------- Forwarded message --------- From: Date: Tue, Feb 2, 2021 at 10:45 PM Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Aggregated Option for SYN Option Space Extension Author : Yoshifumi Nishida Filename : draft-nishida-tcpm-agg-syn-ext-00.txt Pages : 14 Date : 2021-02-02 Abstract: TCP option space is scarce resource as its max length is limited to 40 bytes. This limitation becomes more significant in SYN segments as all options used in a connection should be exchanged during SYN negotiations. This document proposes a new SYN option negotiation scheme that provide a feature to compress TCP options in SYN segments and provide more option space. The proposed scheme does not update the format of TCP header nor transmit any additional SYN or SYN-like segments so that it has lower risks for middlebox interventions. In addition, by combining another proposal for option space extension, it is possible to provide further option space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-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/ _______________________________________________ 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 --0000000000004cc3c605ba694fb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I prepared a draft for SYN op= tion space extensions.
I know this is a difficult issue in TCP an= d has been discussed for a long time.=C2=A0
But, I'm thinking= that it might be a good time to discuss it again.

Key ideas of the draft are the=C2=A0followings.
1: drastic chang= es in TCP's spec will not be required=C2=A0
=C2=A0 =C2=A0 (it= does not require updating TCP header format nor using multiple SYN packets= or additional SYN-like packets)
2: utilize the option negotiatio= n schemes in mptcp for generic purposes. so, I think it can be considered m= iddlebox friendly.
3: it has some limitations=C2=A0(e.g it can on= ly extend around 30-40 bytes for SYN option space). But, if it's combin= ed with EDO, we can use more option space.
=C2=A0 =C2=A0 (depends= on how EDO draft will progress, though)

Please le= t me know if you have any questions or comments or suggestions.
<= br>
Thank you so much!
--
Yoshi
=C2= =A0

---------- Forwarded message ---------
From: = <internet-= drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Sub= ject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Aggregated Option for SYN Option Space Extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-agg-syn-ext-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-02-02

Abstract:
=C2=A0 =C2=A0TCP option space is scarce resource as its max length is limit= ed to
=C2=A0 =C2=A040 bytes.=C2=A0 This limitation becomes more significant in SY= N segments
=C2=A0 =C2=A0as all options used in a connection should be exchanged during= SYN
=C2=A0 =C2=A0negotiations.=C2=A0 This document proposes a new SYN option ne= gotiation
=C2=A0 =C2=A0scheme that provide a feature to compress TCP options in SYN s= egments
=C2=A0 =C2=A0and provide more option space.=C2=A0 The proposed scheme does = not update
=C2=A0 =C2=A0the format of TCP header nor transmit any additional SYN or SY= N-like
=C2=A0 =C2=A0segments so that it has lower risks for middlebox intervention= s.=C2=A0 In
=C2=A0 =C2=A0addition, by combining another proposal for option space exten= sion,
=C2=A0 =C2=A0it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-nishida-tcpm-agg-syn-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishi= da-tcpm-agg-syn-ext-00
https://datatracker.ietf.org/= doc/html/draft-nishida-tcpm-agg-syn-ext-00


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

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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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
--0000000000004cc3c605ba694fb5-- From nobody Wed Feb 3 16:46:25 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD423A0D1C for ; Wed, 3 Feb 2021 16:46:23 -0800 (PST) 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 uoaq7oG5tq8E for ; Wed, 3 Feb 2021 16:46:21 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.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 542873A0D20 for ; Wed, 3 Feb 2021 16:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TrNajIMXsAlCcR2p40vJ5P60wT+CJkICMr903yaod6Q=; b=gy5K/+In2DVsmpjhei3Tommu3 NddWJsNXY2B0CygAiukS9aGJkYCRdo4rFUGEnCBmJe/doPWABsVex90SEAhpnpP3CFpWVUhdjHJW7 9ymLGjuTUrW3iimkIsuySWFU9X+vgzvJEbeUY+mqE8xM6HBVawsiaQNOfmeqcFukNTgDUMlYDsFWO Qf0+b0SJXcyFX90HDYf5Ignb33OUjSSmYXhZSvV3Q7OkOP9zvr5TIopjjAAmGJoEbTH5Lkj/cR9qq fGtcZlqDMxbrGEWRbNAMah9/ow2oerTkTAPKrIa+BvQf+FWdeCxV0qhs1gCjtF6aeJgBd0vwrku57 h6bYJm4xg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63710 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 1l7Sml-001IvC-AP; Wed, 03 Feb 2021 19:46:20 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_CF7202C5-93A7-40B7-ABBA-DEDFB5A20CB8" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: Date: Wed, 3 Feb 2021 16:46:15 -0800 Cc: "tcpm@ietf.org Extensions" Message-Id: <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> References: <161233469809.31214.294457730576935197@ietfa.amsl.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.40.0.2.32) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 00:46:24 -0000 --Apple-Mail=_CF7202C5-93A7-40B7-ABBA-DEDFB5A20CB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Yoshi, > On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida = wrote: >=20 > Hi folks, >=20 > I prepared a draft for SYN option space extensions. > I know this is a difficult issue in TCP and has been discussed for a = long time.=20 > But, I'm thinking that it might be a good time to discuss it again. The proposal has two parts, which are (AFAICT) separable: A. Aggregated options B. Adding more option space in the 3rd packet of a 3WHS (A) is fine, although the most significant issue is legacy interaction. (B) is no longer extending the SYN; it=E2=80=99s actually just post-SYN = activation of new options.=20 > Key ideas of the draft are the followings. > 1: drastic changes in TCP's spec will not be required=20 > (it does not require updating TCP header format nor using multiple = SYN packets or additional SYN-like packets) Post-SYN activation of new options is quite a drastic change.=20 Nevermind the question of what happens to data in the SYN, which = normally MUST be passed to the application at the receiver after the = final ACK is received, but here MUST NOT. And the data that might go in = the other direction in the 3rd message with the ACK. Basically, you=E2=80=99re proposing to change the 3WHS to a 5WHS, which = is a lot more significant and complex than described here (there are a = lot of failure modes not addressed, for one). > 2: utilize the option negotiation schemes in mptcp for generic = purposes. so, I think it can be considered middlebox friendly. MPTCP is negotiating variants of an option that is already active = (AFAICT); that=E2=80=99s not the same as activating new options. > 3: it has some limitations (e.g it can only extend around 30-40 bytes = for SYN option space). But, if it's combined with EDO, we can use more = option space. > (depends on how EDO draft will progress, though) If you have EDO, then just negotiate it and activate options after the = connection is established. But that=E2=80=99s not the problem at hand - = the problem is activation of options in the SYN. AFAICT, this does not = do that. Joe >=20 > Please let me know if you have any questions or comments or = suggestions. >=20 > Thank you so much! > -- > Yoshi > =20 >=20 > ---------- Forwarded message --------- > From: > > Date: Tue, Feb 2, 2021 at 10:45 PM > Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt > To: > >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Aggregated Option for SYN Option Space = Extension > Author : Yoshifumi Nishida > Filename : draft-nishida-tcpm-agg-syn-ext-00.txt > Pages : 14 > Date : 2021-02-02 >=20 > Abstract: > TCP option space is scarce resource as its max length is limited to > 40 bytes. This limitation becomes more significant in SYN segments > as all options used in a connection should be exchanged during SYN > negotiations. This document proposes a new SYN option negotiation > scheme that provide a feature to compress TCP options in SYN = segments > and provide more option space. The proposed scheme does not update > the format of TCP header nor transmit any additional SYN or = SYN-like > segments so that it has lower risks for middlebox interventions. = In > addition, by combining another proposal for option space extension, > it is possible to provide further option space. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 = > = https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00 = >=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 = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_CF7202C5-93A7-40B7-ABBA-DEDFB5A20CB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Yoshi,

On Feb 2, 2021, at 11:12 PM, = Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

Hi folks,

I= prepared a draft for SYN option space extensions.
I = know this is a difficult issue in TCP and has been discussed for a long = time. 
But, I'm thinking that it might be a = good time to discuss it again.

The proposal has two parts, which are (AFAICT) = separable:
A. Aggregated options
B. Adding more = option space in the 3rd packet of a 3WHS

(A) is fine, although the most significant issue = is legacy interaction.

(B) is no = longer extending the SYN; it=E2=80=99s actually just post-SYN activation = of new options. 

Key= ideas of the draft are the followings.
1: = drastic changes in TCP's spec will not be required 
    (it does not require updating TCP header format = nor using multiple SYN packets or additional SYN-like = packets)

Post-SYN activation of new options is quite a = drastic change. 

Nevermind the = question of what happens to data in the SYN, which normally MUST be = passed to the application at the receiver after the final ACK is = received, but here MUST NOT. And the data that might go in the other = direction in the 3rd message with the ACK.

Basically, you=E2=80=99re proposing to change the = 3WHS to a 5WHS, which is a lot more significant and complex than = described here (there are a lot of failure modes not addressed, for = one).

2: = utilize the option negotiation schemes in mptcp for generic purposes. = so, I think it can be considered middlebox = friendly.

MPTCP is negotiating variants of an option that is = already active (AFAICT); that=E2=80=99s not the same as activating new = options.

3: it has some = limitations (e.g it can only extend around 30-40 bytes for SYN = option space). But, if it's combined with EDO, we can use more option = space.
    (depends on how EDO draft will = progress, though)

If you have EDO, then just negotiate it and = activate options after the connection is established. But that=E2=80=99s = not the problem at hand - the problem is activation of options in the = SYN. AFAICT, this does not do that.

Joe

Please let me know if you have any = questions or comments or suggestions.

Thank you so much!
--
Yoshi
 

---------- = Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D = Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts = directories.


        Title          =  : Aggregated Option for SYN Option Space Extension
        Author          : = Yoshifumi Nishida
        Filename        : = draft-nishida-tcpm-agg-syn-ext-00.txt
        Pages          =  : 14
        Date          =   : 2021-02-02

Abstract:
   TCP option space is scarce resource as its max length is = limited to
   40 bytes.  This limitation becomes more significant in = SYN segments
   as all options used in a connection should be exchanged = during SYN
   negotiations.  This document proposes a new SYN option = negotiation
   scheme that provide a feature to compress TCP options in = SYN segments
   and provide more option space.  The proposed scheme = does not update
   the format of TCP header nor transmit any additional SYN or = SYN-like
   segments so that it has lower risks for middlebox = interventions.  In
   addition, by combining another proposal for option space = extension,
   it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext= /

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00
https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-sy= n-ext-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/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_CF7202C5-93A7-40B7-ABBA-DEDFB5A20CB8-- From nobody Wed Feb 3 23:02:31 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACBF3A1304 for ; Wed, 3 Feb 2021 23:02:28 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 9q5JCr55oEke for ; Wed, 3 Feb 2021 23:02:26 -0800 (PST) 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 838D23A12AD for ; Wed, 3 Feb 2021 23:02:26 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id o18so1685160qtp.10 for ; Wed, 03 Feb 2021 23:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qJajuKKtpSZJ5zaN/PBKNJs7nMNfag1TDVstLU9F+nc=; b=gfzJBuRflbN6+AiwsYbOl+Ho/gF4p2QCY/KBiBFzvvINwf+6ntO4fsfQZuh+CrQVIU CdrRtprGOWxFpBWyTPrVoN9PPEsiikoHCsgRQ+T1EI2f2gfYQ7g0gbRcMnW4owJXK4Qn xnGnoz1KZ1LS7lEg7UGFSYgURtZyQok6M/Ya5IDvtSljUKEGKpBT6zAMOR96tgUlW8hi vMmiA+949F+87cIdlAOlYqi+jy+/TY4mZ9C3OzYy1/ReYm+2eEFdGLJQgCCO/jPKx1Na mxu6T9m/3/cxAXd9TD1LBZ1mN9Y0+1ZEbzZyqj8ddmnyIoS54ke6wR+zdlQCYIfUN4Vt 4MIQ== 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=qJajuKKtpSZJ5zaN/PBKNJs7nMNfag1TDVstLU9F+nc=; b=EDYNQdjzzcKSdYlN7X2q79+GloCzb1ZpiTm6TcfiCyg0fuV3kVdUDbW8LWI67CCVyY fLU46zoPqOSZLQQCaq2vAq3akY/Cyrw8BKg92H8krOlslnifEZP6rtwifFtteT1CooPX HkJN+KEJ34gcwYJbRY8qX6ad8xkiPw/a9WOTPDyUJcAmKryK2tkSiAHVGRvCz7I14HAG tbeFE3Q6PJZnOqv2fwUb3nOC081OdXQB3CDKq+UagsigvKfUKBrB7QzKkErz8n2py932 b5mtIXXxGVIUJR8WVovtLbZpoUr6EORXLVFfBUfwunF+w5lzM+3gs4pEiMXddcfkX7fM 2L0g== X-Gm-Message-State: AOAM5314cAwQ6aV/KGfgBiy58/EFyOAjpA6+V+PkLJwGvKs+tv7Lhp6t Eik8MwQUPz+o7eNzeQ5zNuQsnrt8YVwFVXr1ucs= X-Google-Smtp-Source: ABdhPJz1iXih5T5ipeuMVGoeTScmz7F0OGZONX6onwCpJ8XSAcKnObYOK6vieDzGG/T14iHntwcBgwuqUJgTBLJFBqc= X-Received: by 2002:ac8:4911:: with SMTP id e17mr1402019qtq.190.1612422143983; Wed, 03 Feb 2021 23:02:23 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> In-Reply-To: <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> From: Yoshifumi Nishida Date: Wed, 3 Feb 2021 23:02:12 -0800 Message-ID: To: Joseph Touch Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000001ec35005ba7d49b2" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 07:02:29 -0000 --0000000000001ec35005ba7d49b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, Thanks for reading the draft. I put my comments in lines. On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch wrote: > Hi, Yoshi, > > On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida wrote= : > > Hi folks, > > I prepared a draft for SYN option space extensions. > I know this is a difficult issue in TCP and has been discussed for a long > time. > But, I'm thinking that it might be a good time to discuss it again. > > > The proposal has two parts, which are (AFAICT) separable: > A. Aggregated options > B. Adding more option space in the 3rd packet of a 3WHS > Right. both can be used supplementarily. > (A) is fine, although the most significant issue is legacy interaction. > > (B) is no longer extending the SYN; it=E2=80=99s actually just post-SYN a= ctivation > of new options. > In my view, all options are negotiated during SYN exchange. There's no post SYN activation. They are just additional information for the features already negotiated during SYN exchanges. > Key ideas of the draft are the followings. > 1: drastic changes in TCP's spec will not be required > (it does not require updating TCP header format nor using multiple SY= N > packets or additional SYN-like packets) > > > Post-SYN activation of new options is quite a drastic change. > > Nevermind the question of what happens to data in the SYN, which normally > MUST be passed to the application at the receiver after the final ACK is > received, but here MUST NOT. And the data that might go in the other > direction in the 3rd message with the ACK. > > Basically, you=E2=80=99re proposing to change the 3WHS to a 5WHS, which i= s a lot > more significant and complex than described here (there are a lot of > failure modes not addressed, for one). > RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It can be varied depending on how much extra option space is needed. MPTCP adopts 4WHS for its negotiation. In my view, the draft just extends the idea. Hence, I am thinking the degree of the complexity would be more or less the same. At least, I don't think it will be too complex to implement. 2: utilize the option negotiation schemes in mptcp for generic purposes. > so, I think it can be considered middlebox friendly. > > > MPTCP is negotiating variants of an option that is already active > (AFAICT); that=E2=80=99s not the same as activating new options. > My understanding for MPTCP is similar and I think this draft does the same things. (from my point of view) If you see significant differences between them, could you elaborate a bit= ? > 3: it has some limitations (e.g it can only extend around 30-40 bytes for > SYN option space). But, if it's combined with EDO, we can use more option > space. > (depends on how EDO draft will progress, though) > > > If you have EDO, then just negotiate it and activate options after the > connection is established. But that=E2=80=99s not the problem at hand - t= he problem > is activation of options in the SYN. AFAICT, this does not do that. > I think the negotiation scheme for EDO is simple. it needs to send 1 bit information to indicate the activation of the feature. This can be done during SYN exchange. So, I thought it's fine to use this feature in the 3rd segment. Or, are there any risks? Thanks for the lots of detailed comments. -- Yoshi > > Please let me know if you have any questions or comments or suggestions. > > Thank you so much! > -- > Yoshi > > > ---------- Forwarded message --------- > From: > Date: Tue, Feb 2, 2021 at 10:45 PM > Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt > To: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Aggregated Option for SYN Option Space Extensio= n > Author : Yoshifumi Nishida > Filename : draft-nishida-tcpm-agg-syn-ext-00.txt > Pages : 14 > Date : 2021-02-02 > > Abstract: > TCP option space is scarce resource as its max length is limited to > 40 bytes. This limitation becomes more significant in SYN segments > as all options used in a connection should be exchanged during SYN > negotiations. This document proposes a new SYN option negotiation > scheme that provide a feature to compress TCP options in SYN segments > and provide more option space. The proposed scheme does not update > the format of TCP header nor transmit any additional SYN or SYN-like > segments so that it has lower risks for middlebox interventions. In > addition, by combining another proposal for option space extension, > it is possible to provide further option space. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 > https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-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/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --0000000000001ec35005ba7d49b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for reading t= he draft. I put my comments in lines.

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 3, 2021 at 4:46 PM Joseph = Touch <touch@strayalpha.com&= gt; wrote:
Hi, Yoshi,

On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

Hi folks,

I = prepared a draft for SYN option space extensions.
I know this is = a difficult issue in TCP and has been discussed for a long time.=C2=A0
But, I'm thinking that it might be a good time to discuss it agai= n.

The proposal has two p= arts, which are (AFAICT) separable:
A. Aggregated options
B. Adding more option space in the 3rd packet of a 3WHS

Right. both can be used suppl= ementarily.
=C2=A0
(A= ) is fine, although the most significant issue is legacy interaction.
=

(B) is no longer extending the SYN; it=E2=80=99s actual= ly just post-SYN activation of new options.=C2=A0

In my view, all options are negotiated= =C2=A0during SYN exchange. There's no post SYN activation.=C2=A0
<= div>They are just additional information for the features already negotiate= d during SYN exchanges.
=C2=A0
Key ideas of the dr= aft are the=C2=A0followings.
1: drastic changes in TCP's spec= will not be required=C2=A0
=C2=A0 =C2=A0 (it does not require up= dating TCP header format nor using multiple SYN packets or additional SYN-l= ike packets)

Post-SYN act= ivation of new options is quite a drastic change.=C2=A0

Nevermind the question of what happens to data in the SYN, which norm= ally MUST be passed to the application at the receiver after the final ACK = is received, but here MUST NOT. And the data that might go in the other dir= ection in the 3rd message with the ACK.

Basically,= you=E2=80=99re proposing to change the 3WHS to a 5WHS, which is a lot more= significant and complex than described here (there are a lot of failure mo= des not addressed, for one).

RIght. To be precise, the draft supports 3WHS, 4WHS and 5WH= S. It can be varied depending=C2=A0on how much extra option space is needed= .
MPTCP adopts 4WHS for its negotiation. In my view, the draft ju= st extends the idea.=C2=A0
Hence, I am thinking the degree of the= complexity would be more or less the same. At least, I don't think it = will be too complex to implement.

= 2: utilize the option negotiation schemes in mptcp for generic purposes. so= , I think it can be considered middlebox friendly.

MPTCP is negotiating variants of an option that i= s already active (AFAICT); that=E2=80=99s not the same as activating new op= tions.

My und= erstanding=C2=A0for MPTCP is similar and I think this draft does the same t= hings. (from my point of view)
=C2=A0If you see significant diffe= rences between them, could you elaborate a bit?
=
3: it has so= me limitations=C2=A0(e.g it can only extend around 30-40 bytes for SYN opti= on space). But, if it's combined with EDO, we can use more option space= .
=C2=A0 =C2=A0 (depends on how EDO draft will progress, though)<= /div>

If you have EDO, then jus= t negotiate it and activate options after the connection is established. Bu= t that=E2=80=99s not the problem at hand - the problem is activation of opt= ions in the SYN. AFAICT, this does not do that.

I think the negotiation scheme for EDO i= s simple. it needs to send 1 bit information to indicate the activation of = the feature.=C2=A0
This can be done during SYN exchange. So, I th= ought it's fine to use this feature in the 3rd segment. Or, are there a= ny risks?

Thanks for the lots of detailed comments= .
--
Yoshi




<= /div>
Please let me know if you have any questions or comments or sugge= stions.

Thank you so much!
--
= Yoshi
=C2=A0

---------- Forwarded message ---------
From: = <internet-drafts@ietf.org>
Date: Tue, Feb 2, 20= 21 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.tx= t
To: <i-= d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Aggregated Option for SYN Option Space Extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-agg-syn-ext-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-02-02

Abstract:
=C2=A0 =C2=A0TCP option space is scarce resource as its max length is limit= ed to
=C2=A0 =C2=A040 bytes.=C2=A0 This limitation becomes more significant in SY= N segments
=C2=A0 =C2=A0as all options used in a connection should be exchanged during= SYN
=C2=A0 =C2=A0negotiations.=C2=A0 This document proposes a new SYN option ne= gotiation
=C2=A0 =C2=A0scheme that provide a feature to compress TCP options in SYN s= egments
=C2=A0 =C2=A0and provide more option space.=C2=A0 The proposed scheme does = not update
=C2=A0 =C2=A0the format of TCP header nor transmit any additional SYN or SY= N-like
=C2=A0 =C2=A0segments so that it has lower risks for middlebox intervention= s.=C2=A0 In
=C2=A0 =C2=A0addition, by combining another proposal for option space exten= sion,
=C2=A0 =C2=A0it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-nishida-tcpm-agg-syn-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishi= da-tcpm-agg-syn-ext-00
https://datatracker.ietf.org/= doc/html/draft-nishida-tcpm-agg-syn-ext-00


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

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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://= www.ietf.org/mailman/listinfo/tcpm

--0000000000001ec35005ba7d49b2-- From nobody Thu Feb 4 12:07:54 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929463A17A2 for ; Thu, 4 Feb 2021 12:07:52 -0800 (PST) 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 Ad_ipeLHBtiE for ; Thu, 4 Feb 2021 12:07:50 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.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 949E43A17A4 for ; Thu, 4 Feb 2021 12:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2E7Fne+TolnAmuEjZSz77YCN5sV7fUbc437w7xQYhgY=; b=f/BAHEbOzZPk7kwqeyVSTXS8u ila7hGa1u9s5JhIIIxRpTL1QCmIYtcwaPRdBhtgNkGrIsddzFKHPHzwyveph6fw6pY8XjUV36l8R4 UYvbbqNCM3bX5ObxAAWKET5ntUCS5ajVkIQmrdo1pShY0AI9j2/Z9/9tYjNLzocAt0bwivBtd68ZK EoBRGhsV6yy0trKWhkaJNUqiicTofY+ZiSnx4b2BWWzlFaARSt2KCUUkvobScDfuV85QkHG/sxOAg JNuBBTo9SBwTdFDO5w9vRdw+hXyk0K2Ng7XBcWKRzmZnZHQsiH4OejAEdsL7eGLy4JDO0OXJiPZ48 X8OMS7qGw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59758 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 1l7kun-001pkX-AR; Thu, 04 Feb 2021 15:07:50 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_988B4B32-6849-460F-8CDE-E0EC4C9E0B36" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: Date: Thu, 4 Feb 2021 12:07:45 -0800 Cc: "tcpm@ietf.org Extensions" Message-Id: <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.40.0.2.32) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:07:53 -0000 --Apple-Mail=_988B4B32-6849-460F-8CDE-E0EC4C9E0B36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Yoshifumi, > On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida = wrote: >=20 > Hi Joe, >=20 > Thanks for reading the draft. I put my comments in lines. >=20 > On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch > wrote: > Hi, Yoshi, >=20 >> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida > wrote: >>=20 >> Hi folks, >>=20 >> I prepared a draft for SYN option space extensions. >> I know this is a difficult issue in TCP and has been discussed for a = long time.=20 >> But, I'm thinking that it might be a good time to discuss it again. >=20 > The proposal has two parts, which are (AFAICT) separable: > A. Aggregated options > B. Adding more option space in the 3rd packet of a 3WHS >=20 > Right. both can be used supplementarily. > =20 > (A) is fine, although the most significant issue is legacy = interaction. >=20 > (B) is no longer extending the SYN; it=E2=80=99s actually just = post-SYN activation of new options.=20 >=20 > In my view, all options are negotiated during SYN exchange. There's no = post SYN activation.=20 > They are just additional information for the features already = negotiated during SYN exchanges. I disagree; you=E2=80=99re suggesting putting NEW options in packets = that don=E2=80=99t have a SYN. In that sense, it=E2=80=99s similar to my = proposal, which uses a segment with no SYN and no ACK bit (the = out-of-band segment). However, the problem is with the first SYN-ACK you send back. That is = typically a confirmation of all options supported so the rest of the = connection can commence, even for MPTCP. In your case, the exchange = continues. This not only adds multiple RTTs to the open, it interferes = with data sent in the SYN, data sent with the SYN-ACK, and fast-open for = sure; it could also be a problem with many other options that don=E2=80=99= t make sense in subsequent segments due to the way they need to = coordinate info that is used in the SYN-ACK or other ACK segments (e.g., = TCP-AO comes to mind). At a first cut, the doc needs to address this, e.g., saying that: - if any user data is included before the option exchange is = completed, it has to be delayed until it completes - how to handle options that are first seen after the SYN MPTCP can define its own behavior for this, but your doc = cannot redefine that for other options=20 >> Key ideas of the draft are the followings. >> 1: drastic changes in TCP's spec will not be required=20 >> (it does not require updating TCP header format nor using = multiple SYN packets or additional SYN-like packets) >=20 > Post-SYN activation of new options is quite a drastic change.=20 >=20 > Nevermind the question of what happens to data in the SYN, which = normally MUST be passed to the application at the receiver after the = final ACK is received, but here MUST NOT. And the data that might go in = the other direction in the 3rd message with the ACK. >=20 > Basically, you=E2=80=99re proposing to change the 3WHS to a 5WHS, = which is a lot more significant and complex than described here (there = are a lot of failure modes not addressed, for one). >=20 > RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It can = be varied depending on how much extra option space is needed. > MPTCP adopts 4WHS for its negotiation. In my view, the draft just = extends the idea.=20 MPTCP adopts 4WHS for *its* options, which is its prerogative. You=E2=80=99= re attempting to define 4WHS and 4WHS semantics for *all* options, which = I don=E2=80=99t think is viable. > Hence, I am thinking the degree of the complexity would be more or = less the same. At least, I don't think it will be too complex to = implement. >=20 >> 2: utilize the option negotiation schemes in mptcp for generic = purposes. so, I think it can be considered middlebox friendly. >=20 > MPTCP is negotiating variants of an option that is already active = (AFAICT); that=E2=80=99s not the same as activating new options. >=20 > My understanding for MPTCP is similar and I think this draft does the = same things. (from my point of view) > If you see significant differences between them, could you elaborate = a bit? See above. >> 3: it has some limitations (e.g it can only extend around 30-40 bytes = for SYN option space). But, if it's combined with EDO, we can use more = option space. >> (depends on how EDO draft will progress, though) >=20 > If you have EDO, then just negotiate it and activate options after the = connection is established. But that=E2=80=99s not the problem at hand - = the problem is activation of options in the SYN. AFAICT, this does not = do that. >=20 > I think the negotiation scheme for EDO is simple. it needs to send 1 = bit information to indicate the activation of the feature.=20 > This can be done during SYN exchange. So, I thought it's fine to use = this feature in the 3rd segment. Or, are there any risks? I do think that if EDO is negotiated in the SYN then you can use it in = all subsequent segments (that=E2=80=99s already how it=E2=80=99s = defined). I don=E2=80=99t think it adds any risks here that aren=E2=80=99t= already part of EDO. Joe --Apple-Mail=_988B4B32-6849-460F-8CDE-E0EC4C9E0B36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Yoshifumi,

On Feb 3, 2021, at 11:02 PM, Yoshifumi = Nishida <nsd.ietf@gmail.com> wrote:

Hi Joe,

Thanks for reading the draft. I put my = comments in lines.

On Wed, Feb 3, 2021 at 4:46 PM Joseph = Touch <touch@strayalpha.com> wrote:
Hi, Yoshi,

On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

Hi folks,

I prepared a draft for SYN option space = extensions.
I know this is a difficult issue in TCP = and has been discussed for a long time. 
But, = I'm thinking that it might be a good time to discuss it = again.

The proposal has two parts, which are = (AFAICT) separable:
A. Aggregated options
B. Adding more option space in the 3rd packet of a = 3WHS

Right. both can be used = supplementarily.
 
(A) is fine, although the most significant = issue is legacy interaction.

(B) is no longer extending the SYN; = it=E2=80=99s actually just post-SYN activation of new = options. 

In my view, all options = are negotiated during SYN exchange. There's no post SYN = activation. 
They are just additional = information for the features already negotiated during SYN = exchanges.

I disagree; you=E2=80=99re suggesting putting NEW = options in packets that don=E2=80=99t have a SYN. In that sense, it=E2=80=99= s similar to my proposal, which uses a segment with no SYN and no ACK = bit (the out-of-band segment).

However, the problem is with the first SYN-ACK you = send back. That is typically a confirmation of all options supported so = the rest of the connection can commence, even for MPTCP. In your case, = the exchange continues. This not only adds multiple RTTs to the open, it = interferes with data sent in the SYN, data sent with the SYN-ACK, and = fast-open for sure; it could also be a problem with many other options = that don=E2=80=99t make sense in subsequent segments due to the way they = need to coordinate info that is used in the SYN-ACK or other ACK = segments (e.g., TCP-AO comes to mind).

At a first cut, the doc needs to address this, = e.g., saying that:
- if any user data is included = before the option exchange is completed, it has to be delayed until it = completes
- how to handle options that are = first seen after the SYN
MPTCP can define its own = behavior for this, but your doc cannot redefine that for other = options 

Key ideas of the draft are = the followings.
1: drastic changes in TCP's = spec will not be required 
    (it = does not require updating TCP header format nor using multiple SYN = packets or additional SYN-like = packets)

Post-SYN activation of new options is = quite a drastic change. 

Nevermind the question of what happens = to data in the SYN, which normally MUST be passed to the application at = the receiver after the final ACK is received, but here MUST NOT. And the = data that might go in the other direction in the 3rd message with the = ACK.

Basically, = you=E2=80=99re proposing to change the 3WHS to a 5WHS, which is a lot = more significant and complex than described here (there are a lot of = failure modes not addressed, for = one).

RIght. To be precise, the draft = supports 3WHS, 4WHS and 5WHS. It can be varied depending on how = much extra option space is needed.
MPTCP adopts = 4WHS for its negotiation. In my view, the draft just extends the = idea. 

MPTCP adopts 4WHS for *its* options, which is its = prerogative. You=E2=80=99re attempting to define 4WHS and 4WHS semantics = for *all* options, which I don=E2=80=99t think is viable.

Hence, I am = thinking the degree of the complexity would be more or less the same. At = least, I don't think it will be too complex to implement.

2: utilize the = option negotiation schemes in mptcp for generic purposes. so, I think it = can be considered middlebox friendly.

MPTCP is negotiating = variants of an option that is already active (AFAICT); that=E2=80=99s = not the same as activating new = options.

My understanding for MPTCP is = similar and I think this draft does the same things. (from my point of = view)
 If you see significant differences = between them, could you elaborate a = bit?

See = above.

3: it has some = limitations (e.g it can only extend around 30-40 bytes for SYN = option space). But, if it's combined with EDO, we can use more option = space.
    (depends on how EDO draft will = progress, though)

If you have EDO, then just negotiate it = and activate options after the connection is established. But that=E2=80=99= s not the problem at hand - the problem is activation of options in the = SYN. AFAICT, this does not do = that.

I think the negotiation scheme for EDO = is simple. it needs to send 1 bit information to indicate the activation = of the feature. 
This can be done during SYN = exchange. So, I thought it's fine to use this feature in the 3rd = segment. Or, are there any risks?

I do think that if EDO is negotiated in the SYN = then you can use it in all subsequent segments (that=E2=80=99s already = how it=E2=80=99s defined). I don=E2=80=99t think it adds any risks here = that aren=E2=80=99t already part of EDO.

Joe

= --Apple-Mail=_988B4B32-6849-460F-8CDE-E0EC4C9E0B36-- From nobody Thu Feb 4 12:35:12 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56513A17D8 for ; Thu, 4 Feb 2021 12:35:06 -0800 (PST) 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 keqF5Lgp1lhr for ; Thu, 4 Feb 2021 12:35:04 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.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 154DB3A17D3 for ; Thu, 4 Feb 2021 12:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=in87zrXRBEU6Xjf+yNE3lRvy1Q6r1SbeoozgYhIBHyI=; b=dyzzUQQTLBDkNNIsbUosuejdI Ei4Z7myns4fHZL9sXCWipykAas9KrjjTbHZJ3zi0mjxwl3ex/ZQ2GnEWyDkVqONhlyytdWUuR/od/ u5z/vmYyKCieyzTAC9VZxfyRXEqzKbYj4tyEpORVwegRgme0V+GeHOG4fftUqpEYizy9rKqgdI8mp jfAq79dh1D603m4PIuWd6kzKiosGwgPHPFZn0xkb9GBnT/oz5c1t8pIYjbNha+62bOHse2cAsiLtI LjJxg92hj38FHgN9Ki3a2nKDTNZz1Xd3KLYgalLIK/OzcVXwoYtfEB6oAQh0M7S3Islw5vyqLe/0L hrqtBmWxQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60632 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 1l7lL8-002JZ9-Ls; Thu, 04 Feb 2021 15:35:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> Date: Thu, 4 Feb 2021 12:34:58 -0800 Cc: "tcpm@ietf.org Extensions" Message-Id: References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.40.0.2.32) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:35:07 -0000 --Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, I would have called this more =E2=80=9Cdelayed option = negotiation=E2=80=9D than its current title. The core issue as I see it is atomicity of options; there are many = options that interact with others that cannot be delayed this way. And = if option negotiation is delayed, the issue of what to do with data in = the meantime. So overall, it could be a generally useful addition, but is quite = distinct in capability and impact on both options and TCP than the = previous attempted solutions. Joe > On Feb 4, 2021, at 12:07 PM, Joseph Touch = wrote: >=20 > Hi, Yoshifumi, >=20 >> On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida > wrote: >>=20 >> Hi Joe, >>=20 >> Thanks for reading the draft. I put my comments in lines. >>=20 >> On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch > wrote: >> Hi, Yoshi, >>=20 >>> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida > wrote: >>>=20 >>> Hi folks, >>>=20 >>> I prepared a draft for SYN option space extensions. >>> I know this is a difficult issue in TCP and has been discussed for a = long time.=20 >>> But, I'm thinking that it might be a good time to discuss it again. >>=20 >> The proposal has two parts, which are (AFAICT) separable: >> A. Aggregated options >> B. Adding more option space in the 3rd packet of a 3WHS >>=20 >> Right. both can be used supplementarily. >> =20 >> (A) is fine, although the most significant issue is legacy = interaction. >>=20 >> (B) is no longer extending the SYN; it=E2=80=99s actually just = post-SYN activation of new options.=20 >>=20 >> In my view, all options are negotiated during SYN exchange. There's = no post SYN activation.=20 >> They are just additional information for the features already = negotiated during SYN exchanges. >=20 > I disagree; you=E2=80=99re suggesting putting NEW options in packets = that don=E2=80=99t have a SYN. In that sense, it=E2=80=99s similar to my = proposal, which uses a segment with no SYN and no ACK bit (the = out-of-band segment). >=20 > However, the problem is with the first SYN-ACK you send back. That is = typically a confirmation of all options supported so the rest of the = connection can commence, even for MPTCP. In your case, the exchange = continues. This not only adds multiple RTTs to the open, it interferes = with data sent in the SYN, data sent with the SYN-ACK, and fast-open for = sure; it could also be a problem with many other options that don=E2=80=99= t make sense in subsequent segments due to the way they need to = coordinate info that is used in the SYN-ACK or other ACK segments (e.g., = TCP-AO comes to mind). >=20 > At a first cut, the doc needs to address this, e.g., saying that: > - if any user data is included before the option exchange is = completed, it has to be delayed until it completes > - how to handle options that are first seen after the SYN > MPTCP can define its own behavior for this, but your doc = cannot redefine that for other options=20 >=20 >>> Key ideas of the draft are the followings. >>> 1: drastic changes in TCP's spec will not be required=20 >>> (it does not require updating TCP header format nor using = multiple SYN packets or additional SYN-like packets) >>=20 >> Post-SYN activation of new options is quite a drastic change.=20 >>=20 >> Nevermind the question of what happens to data in the SYN, which = normally MUST be passed to the application at the receiver after the = final ACK is received, but here MUST NOT. And the data that might go in = the other direction in the 3rd message with the ACK. >>=20 >> Basically, you=E2=80=99re proposing to change the 3WHS to a 5WHS, = which is a lot more significant and complex than described here (there = are a lot of failure modes not addressed, for one). >>=20 >> RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It can = be varied depending on how much extra option space is needed. >> MPTCP adopts 4WHS for its negotiation. In my view, the draft just = extends the idea.=20 >=20 > MPTCP adopts 4WHS for *its* options, which is its prerogative. = You=E2=80=99re attempting to define 4WHS and 4WHS semantics for *all* = options, which I don=E2=80=99t think is viable. >=20 >> Hence, I am thinking the degree of the complexity would be more or = less the same. At least, I don't think it will be too complex to = implement. >>=20 >>> 2: utilize the option negotiation schemes in mptcp for generic = purposes. so, I think it can be considered middlebox friendly. >>=20 >> MPTCP is negotiating variants of an option that is already active = (AFAICT); that=E2=80=99s not the same as activating new options. >>=20 >> My understanding for MPTCP is similar and I think this draft does the = same things. (from my point of view) >> If you see significant differences between them, could you elaborate = a bit? >=20 > See above. >=20 >>> 3: it has some limitations (e.g it can only extend around 30-40 = bytes for SYN option space). But, if it's combined with EDO, we can use = more option space. >>> (depends on how EDO draft will progress, though) >>=20 >> If you have EDO, then just negotiate it and activate options after = the connection is established. But that=E2=80=99s not the problem at = hand - the problem is activation of options in the SYN. AFAICT, this = does not do that. >>=20 >> I think the negotiation scheme for EDO is simple. it needs to send 1 = bit information to indicate the activation of the feature.=20 >> This can be done during SYN exchange. So, I thought it's fine to use = this feature in the 3rd segment. Or, are there any risks? >=20 > I do think that if EDO is negotiated in the SYN then you can use it in = all subsequent segments (that=E2=80=99s already how it=E2=80=99s = defined). I don=E2=80=99t think it adds any risks here that aren=E2=80=99t= already part of EDO. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW,= I would have called this more =E2=80=9Cdelayed option negotiation=E2=80=9D= than its current title.

The core issue as I see it is atomicity of options; there are = many options that interact with others that cannot be delayed this way. = And if option negotiation is delayed, the issue of what to do with data = in the meantime.

So overall, it could be a generally useful addition, but is = quite distinct in capability and impact on both options and TCP than the = previous attempted solutions.

Joe

On Feb = 4, 2021, at 12:07 PM, Joseph Touch <touch@strayalpha.com> wrote:

Hi, Yoshifumi,

On Feb 3, 2021, at 11:02 PM, Yoshifumi = Nishida <nsd.ietf@gmail.com> wrote:

Hi Joe,

Thanks for reading the draft. I put my = comments in lines.

On Wed, Feb 3, 2021 at 4:46 PM Joseph = Touch <touch@strayalpha.com> wrote:
Hi, Yoshi,

On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

Hi folks,

I prepared a draft for SYN option space = extensions.
I know this is a difficult issue in TCP = and has been discussed for a long time. 
But, = I'm thinking that it might be a good time to discuss it = again.

The proposal has two parts, which are = (AFAICT) separable:
A. Aggregated options
B. Adding more option space in the 3rd packet of a = 3WHS

Right. both can be used = supplementarily.
 
(A) is fine, although the most significant = issue is legacy interaction.

(B) is no longer extending the SYN; = it=E2=80=99s actually just post-SYN activation of new = options. 

In my view, all options = are negotiated during SYN exchange. There's no post SYN = activation. 
They are just additional = information for the features already negotiated during SYN = exchanges.

I disagree; you=E2=80=99re suggesting = putting NEW options in packets that don=E2=80=99t have a SYN. In that = sense, it=E2=80=99s similar to my proposal, which uses a segment with no = SYN and no ACK bit (the out-of-band segment).

However, the problem is with the first = SYN-ACK you send back. That is typically a confirmation of all options = supported so the rest of the connection can commence, even for MPTCP. In = your case, the exchange continues. This not only adds multiple RTTs to = the open, it interferes with data sent in the SYN, data sent with the = SYN-ACK, and fast-open for sure; it could also be a problem with many = other options that don=E2=80=99t make sense in subsequent segments due = to the way they need to coordinate info that is used in the SYN-ACK or = other ACK segments (e.g., TCP-AO comes to mind).

At a first cut, the doc needs to = address this, e.g., saying that:
- if any = user data is included before the option exchange is completed, it has to = be delayed until it completes
- how to = handle options that are first seen after the SYN
= MPTCP can define its own behavior for this, but your doc cannot = redefine that for other options 

Key ideas of the draft are = the followings.
1: drastic changes in TCP's = spec will not be required 
    (it = does not require updating TCP header format nor using multiple SYN = packets or additional SYN-like = packets)

Post-SYN activation of new options is = quite a drastic change. 

Nevermind the question of what happens = to data in the SYN, which normally MUST be passed to the application at = the receiver after the final ACK is received, but here MUST NOT. And the = data that might go in the other direction in the 3rd message with the = ACK.

Basically, = you=E2=80=99re proposing to change the 3WHS to a 5WHS, which is a lot = more significant and complex than described here (there are a lot of = failure modes not addressed, for = one).

RIght. To be precise, the draft = supports 3WHS, 4WHS and 5WHS. It can be varied depending on how = much extra option space is needed.
MPTCP adopts = 4WHS for its negotiation. In my view, the draft just extends the = idea. 

MPTCP adopts 4WHS for *its* options, = which is its prerogative. You=E2=80=99re attempting to define 4WHS and = 4WHS semantics for *all* options, which I don=E2=80=99t think is = viable.

Hence, = I am thinking the degree of the complexity would be more or less the = same. At least, I don't think it will be too complex to = implement.

2: utilize the = option negotiation schemes in mptcp for generic purposes. so, I think it = can be considered middlebox friendly.

MPTCP is negotiating = variants of an option that is already active (AFAICT); that=E2=80=99s = not the same as activating new = options.

My understanding for MPTCP is = similar and I think this draft does the same things. (from my point of = view)
 If you see significant differences = between them, could you elaborate a = bit?

See above.

3: it has some = limitations (e.g it can only extend around 30-40 bytes for SYN = option space). But, if it's combined with EDO, we can use more option = space.
    (depends on how EDO draft will = progress, though)

If you have EDO, then just negotiate it = and activate options after the connection is established. But that=E2=80=99= s not the problem at hand - the problem is activation of options in the = SYN. AFAICT, this does not do = that.

I think the negotiation scheme for EDO = is simple. it needs to send 1 bit information to indicate the activation = of the feature. 
This can be done during SYN = exchange. So, I thought it's fine to use this feature in the 3rd = segment. Or, are there any risks?

I do think that if EDO = is negotiated in the SYN then you can use it in all subsequent segments = (that=E2=80=99s already how it=E2=80=99s defined). I don=E2=80=99t think = it adds any risks here that aren=E2=80=99t already part of = EDO.

Joe

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

= --Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45-- From nobody Thu Feb 4 22:51:13 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3E93A1CB3 for ; Thu, 4 Feb 2021 22:51:11 -0800 (PST) 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 2alIFImET_1Q for ; Thu, 4 Feb 2021 22:51:08 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 3C16F3A1CB2 for ; Thu, 4 Feb 2021 22:51:08 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id h16so4281779qth.11 for ; Thu, 04 Feb 2021 22:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqYmpMfhm3A0hyoVJlHPOlmB90vDQVzxVDthrnxW988=; b=miyFpUb4+Ux/ocDJez/EHCo/8TesYIZ7ryhg2lrUn7RZuKBXQffaDek08kz+HfMetW G+MCqTB96MCplo5SSt/KtBJ2HWic4Yp24v5p+TKwufIG123a8YKUwyyeYxVfQt9ArvI5 f87bWwKZik6rZbMwtwm2Um0SAMmiNkseSeUiAEZyYluPnTSGq00TWPEYHAuZ9sIUg6kW ZxV3HYsCpZfXU+j+cZSPxoo94Gw0/CGgleqzr0m/0j853+szQlTr9mdNUDBdm58bJQAp tl3DzsT534fFE2EbBvdHIaqjnVA6I2MQsuBCM3vtYGN2cUx/NPNt6ORugFX3UhMQsqVd 1iSg== 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=qqYmpMfhm3A0hyoVJlHPOlmB90vDQVzxVDthrnxW988=; b=iO2nYQeD6Bv0S9hEa/UCJ0lHY5tT67UScm2UoOJwLjXpL7P0iFCnYDj1cCaKEs9pBe OXaaWAb+nbjr1nJ9h83DS12gZp4jKrJw4Ie5jP7IGLn0VeLOxXwo+Vj0QpiZu+rbDxsA HfAaxY1zxlZDmkM8K5dZsMjhkci8BBPpqBwRwTZ5ynWUWNTtC+SbVCbwZS9TL+hMM/+s 9ZZ6fWG9j2VM41SXklDMYJ7oz6oQ/hhyOvDTD2u6wgBBiNO0JzSRR8w8V9Oit9u95kWu hI+/mnZPMVJVzMT8D8+s1AYL4e066++nfgXWYEEInTaAgsZBi1igH6TufiUf6BSPq9r/ L7iw== X-Gm-Message-State: AOAM530bK20dRZJ/zcwUAB00KwL80EAvh1EbTIlck8Aqi/7r3gcW+Nhf U/xAjxlqb5u9A82UL6iS6e7ME/HriMNWG8+RJGY= X-Google-Smtp-Source: ABdhPJxuU/JBaNpPdKQ5HyVROGgHAErYUSINH4WFBtidp8wnSyPNvia7+6NOCFIPzFhUycza4OayV+fneLkM09p9FC4= X-Received: by 2002:ac8:1184:: with SMTP id d4mr2986486qtj.103.1612507867009; Thu, 04 Feb 2021 22:51:07 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> In-Reply-To: From: Yoshifumi Nishida Date: Thu, 4 Feb 2021 22:50:55 -0800 Message-ID: To: Joseph Touch Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000009c55d305ba913e8f" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 06:51:12 -0000 --0000000000009c55d305ba913e8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, On Thu, Feb 4, 2021 at 12:35 PM Joseph Touch wrote: > FWIW, I would have called this more =E2=80=9Cdelayed option negotiation= =E2=80=9D than its > current title. > OK. It seems it makes sense. Thanks for the suggestion. I will think about updating the title. I also would like to hear from people if there're other thoughts. > The core issue as I see it is atomicity of options; there are many option= s > that interact with others that cannot be delayed this way. And if option > negotiation is delayed, the issue of what to do with data in the meantime= . > > So overall, it could be a generally useful addition, but is quite distinc= t > in capability and impact on both options and TCP than the previous > attempted solutions. > I basically agree with you here. In my view, the previous approaches such as yours try to provide complete solutions to SYN option space, which can lead to very long discussions from my observations. Instead, the draft tries to provide a solution that has several limitations, but it can reduce complexity and the risk of middlebox issues. Also, we have similar precedence for this approach. The main focus of the draft is to support newly defined options rather than existing options. Especially, the ones that use EXID as they tend to consume more space. One of my concerns is scarce SYN option space discourages people from developing and using new features. As you mentioned, some options are difficult to be delayed. Section 5.3 describes this limitation and explains that TFO or AO cannot be supported with this. But, I think this approach is still useful as some options will not be affected even though the negotiations are delayed a bit. For example, if you want to send special feedbacks on some events by using a certain options, you don't need to hold data transfer for the feature. Or, in some cases, delays can be acceptable in order to use new features. Thanks, -- Yoshi > > On Feb 4, 2021, at 12:07 PM, Joseph Touch wrote: > > Hi, Yoshifumi, > > On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida wrote= : > > Hi Joe, > > Thanks for reading the draft. I put my comments in lines. > > On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch wrote: > >> Hi, Yoshi, >> >> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida >> wrote: >> >> Hi folks, >> >> I prepared a draft for SYN option space extensions. >> I know this is a difficult issue in TCP and has been discussed for a lon= g >> time. >> But, I'm thinking that it might be a good time to discuss it again. >> >> >> The proposal has two parts, which are (AFAICT) separable: >> A. Aggregated options >> B. Adding more option space in the 3rd packet of a 3WHS >> > > Right. both can be used supplementarily. > > >> (A) is fine, although the most significant issue is legacy interaction. >> >> (B) is no longer extending the SYN; it=E2=80=99s actually just post-SYN >> activation of new options. >> > > In my view, all options are negotiated during SYN exchange. There's no > post SYN activation. > They are just additional information for the features already negotiated > during SYN exchanges. > > > I disagree; you=E2=80=99re suggesting putting NEW options in packets that= don=E2=80=99t > have a SYN. In that sense, it=E2=80=99s similar to my proposal, which use= s a > segment with no SYN and no ACK bit (the out-of-band segment). > > However, the problem is with the first SYN-ACK you send back. That is > typically a confirmation of all options supported so the rest of the > connection can commence, even for MPTCP. In your case, the exchange > continues. This not only adds multiple RTTs to the open, it interferes wi= th > data sent in the SYN, data sent with the SYN-ACK, and fast-open for sure; > it could also be a problem with many other options that don=E2=80=99t mak= e sense in > subsequent segments due to the way they need to coordinate info that is > used in the SYN-ACK or other ACK segments (e.g., TCP-AO comes to mind). > > At a first cut, the doc needs to address this, e.g., saying that: > - if any user data is included before the option exchange is completed, i= t > has to be delayed until it completes > - how to handle options that are first seen after the SYN > MPTCP can define its own behavior for this, but your doc cannot redefine > that for other options > > Key ideas of the draft are the followings. >> 1: drastic changes in TCP's spec will not be required >> (it does not require updating TCP header format nor using multiple >> SYN packets or additional SYN-like packets) >> >> >> Post-SYN activation of new options is quite a drastic change. >> >> Nevermind the question of what happens to data in the SYN, which normall= y >> MUST be passed to the application at the receiver after the final ACK is >> received, but here MUST NOT. And the data that might go in the other >> direction in the 3rd message with the ACK. >> >> Basically, you=E2=80=99re proposing to change the 3WHS to a 5WHS, which = is a lot >> more significant and complex than described here (there are a lot of >> failure modes not addressed, for one). >> > > RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It can be > varied depending on how much extra option space is needed. > MPTCP adopts 4WHS for its negotiation. In my view, the draft just extends > the idea. > > > MPTCP adopts 4WHS for *its* options, which is its prerogative. You=E2=80= =99re > attempting to define 4WHS and 4WHS semantics for *all* options, which I > don=E2=80=99t think is viable. > > Hence, I am thinking the degree of the complexity would be more or less > the same. At least, I don't think it will be too complex to implement. > > 2: utilize the option negotiation schemes in mptcp for generic purposes. >> so, I think it can be considered middlebox friendly. >> >> >> MPTCP is negotiating variants of an option that is already active >> (AFAICT); that=E2=80=99s not the same as activating new options. >> > > My understanding for MPTCP is similar and I think this draft does the sam= e > things. (from my point of view) > If you see significant differences between them, could you elaborate a > bit? > > > See above. > > 3: it has some limitations (e.g it can only extend around 30-40 bytes for >> SYN option space). But, if it's combined with EDO, we can use more optio= n >> space. >> (depends on how EDO draft will progress, though) >> >> >> If you have EDO, then just negotiate it and activate options after the >> connection is established. But that=E2=80=99s not the problem at hand - = the problem >> is activation of options in the SYN. AFAICT, this does not do that. >> > > I think the negotiation scheme for EDO is simple. it needs to send 1 bit > information to indicate the activation of the feature. > This can be done during SYN exchange. So, I thought it's fine to use this > feature in the 3rd segment. Or, are there any risks? > > > I do think that if EDO is negotiated in the SYN then you can use it in al= l > subsequent segments (that=E2=80=99s already how it=E2=80=99s defined). I = don=E2=80=99t think it > adds any risks here that aren=E2=80=99t already part of EDO. > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --0000000000009c55d305ba913e8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Thu, Feb 4, 2021 at 12:35 PM Joseph Touch = <touch@strayalpha.com> wr= ote:
FWIW, I would have called this more =E2=80= =9Cdelayed option negotiation=E2=80=9D than its current title.

OK. It seems it makes sense. Thanks for the=C2=A0= suggestion. I will think about updating the title.
I also would l= ike to hear from people if there're other thoughts.
=C2=A0
The core issue as I see it is atomicity of options= ; there are many options that interact with others that cannot be delayed t= his way. And if option negotiation is delayed, the issue of what to do with= data in the meantime.

So overall, it could be a g= enerally useful addition, but is quite distinct in capability and impact on= both options and TCP than the previous attempted solutions.

I basically agree with you=C2=A0here.=C2=A0
In my view, the previous approaches such as yours try to provide c= omplete solutions=C2=A0to SYN option space, which can lead to very long dis= cussions from my observations.
Instead, the draft tries to provid= e a solution that has several limitations, but it can reduce=C2=A0complexit= y and the risk of middlebox issues. Also, we have similar precedence for th= is approach.

The=C2=A0main focus of the draft is t= o support newly defined options rather than existing options. Especially, t= he ones that use EXID as they tend to consume more space.
One of = my concerns=C2=A0is scarce SYN option space discourages people from develop= ing and using new features.

As you mentioned, some= options are difficult to be delayed. Section 5.3 describes this limitation= and explains that TFO or AO cannot be supported with this.
But, = I think this approach is still useful as some options will not be affected = even though the negotiations are delayed a bit.=C2=A0
For example= , if you want to send special=C2=A0feedbacks on some events by using a cert= ain options, you don't need to hold data transfer for the feature.
Or, in some cases, delays can be acceptable in order to use new = features.=C2=A0

Thanks,
--
Yoshi=C2=A0

=C2=A0

On Feb 4, 2021= , at 12:07 PM, Joseph Touch <touch@strayalpha.com> wrote:

Hi, Yoshifumi,

On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida <nsd.ietf@gmail.com>= wrote:

Hi Joe,

Thanks for reading the draft. I put my comments in lines.

On Wed, Feb 3, 2= 021 at 4:46 PM Joseph Touch <touch@strayalpha.com> wrote:
Hi, Yoshi,

On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida <= ;nsd.ietf@gmail.com= > wrote:

Hi folks,

I prepared a draft for SYN option space extensions.
I know this = is a difficult issue in TCP and has been discussed for a long time.=C2=A0
But, I'm thinking that it might be a good time to discuss it a= gain.

The proposal has tw= o parts, which are (AFAICT) separable:
A. Aggregated options
B. Adding more option space in the 3rd packet of a 3WHS

Right. both can be used su= pplementarily.
=C2=A0
(A) is fine, although the most signifi= cant issue is legacy interaction.

(B) is no longer= extending the SYN; it=E2=80=99s actually just post-SYN activation of new o= ptions.=C2=A0

In my view, all options are negotiated=C2=A0during SYN exchange. There'= ;s no post SYN activation.=C2=A0
They are just additional informa= tion for the features already negotiated during SYN exchanges.
<= /div>

I disagree; you=E2=80=99re sugg= esting putting NEW options in packets that don=E2=80=99t have a SYN. In tha= t sense, it=E2=80=99s similar to my proposal, which uses a segment with no = SYN and no ACK bit (the out-of-band segment).

Howe= ver, the problem is with the first SYN-ACK you send back. That is typically= a confirmation of all options supported so the rest of the connection can = commence, even for MPTCP. In your case, the exchange continues. This not on= ly adds multiple RTTs to the open, it interferes with data sent in the SYN,= data sent with the SYN-ACK, and fast-open for sure; it could also be a pro= blem with many other options that don=E2=80=99t make sense in subsequent se= gments due to the way they need to coordinate info that is used in the SYN-= ACK or other ACK segments (e.g., TCP-AO comes to mind).

At a first cut, the doc needs to address this, e.g., saying that:
- if any user data is i= ncluded before the option exchange is completed, it has to be delayed until= it completes
- how = to handle options that are first seen after the SYN
MPTCP can define its own behavior for th= is, but your doc cannot redefine that for other options=C2=A0
Key ideas of the draft ar= e the=C2=A0followings.
1: drastic changes in TCP's spec will = not be required=C2=A0
=C2=A0 =C2=A0 (it does not require updating= TCP header format nor using multiple SYN packets or additional SYN-like pa= ckets)

Post-SYN activatio= n of new options is quite a drastic change.=C2=A0

= Nevermind the question of what happens to data in the SYN, which normally M= UST be passed to the application at the receiver after the final ACK is rec= eived, but here MUST NOT. And the data that might go in the other direction= in the 3rd message with the ACK.

Basically, you= =E2=80=99re proposing to change the 3WHS to a 5WHS, which is a lot more sig= nificant and complex than described here (there are a lot of failure modes = not addressed, for one).
RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. I= t can be varied depending=C2=A0on how much extra option space is needed.
MPTCP adopts 4WHS for its negotiation. In my view, the draft just e= xtends the idea.=C2=A0

MP= TCP adopts 4WHS for *its* options, which is its prerogative. You=E2=80=99re= attempting to define 4WHS and 4WHS semantics for *all* options, which I do= n=E2=80=99t think is viable.

Hence, I am thinking the degree of th= e complexity would be more or less the same. At least, I don't think it= will be too complex to implement.

2: utilize the option negotiation sc= hemes in mptcp for generic purposes. so, I think it can be considered middl= ebox friendly.

MPTCP is n= egotiating variants of an option that is already active (AFAICT); that=E2= =80=99s not the same as activating new options.

My understanding=C2=A0for MPTCP is simil= ar and I think this draft does the same things. (from my point of view)
=C2=A0If you see significant differences between them, could you ela= borate a bit?

See above.<= /div>
<= blockquote type=3D"cite">
3: it has some limitati= ons=C2=A0(e.g it can only extend around 30-40 bytes for SYN option space). = But, if it's combined with EDO, we can use more option space.
=C2=A0 =C2=A0 (depends on how EDO draft will progress, though)
=

If you have EDO, then just negotiate= it and activate options after the connection is established. But that=E2= =80=99s not the problem at hand - the problem is activation of options in t= he SYN. AFAICT, this does not do that.

I think the negotiation scheme for EDO is simple.= it needs to send 1 bit information to indicate the activation of the featu= re.=C2=A0
This can be done during SYN exchange. So, I thought it&= #39;s fine to use this feature in the 3rd segment. Or, are there any risks?=

I do think that if EDO i= s negotiated in the SYN then you can use it in all subsequent segments (tha= t=E2=80=99s already how it=E2=80=99s defined). I don=E2=80=99t think it add= s any risks here that aren=E2=80=99t already part of EDO.

Joe

_______________________________= ________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/t= cpm

--0000000000009c55d305ba913e8f-- From nobody Sun Feb 7 17:01:24 2021 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 7E0793A0D7C; Sun, 7 Feb 2021 17:01:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161274608246.10975.9762681883669159913@ietfa.amsl.com> Date: Sun, 07 Feb 2021 17:01:22 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 01:01:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-08.txt Pages : 34 Date : 2021-02-07 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 7 17:42:02 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436F73A0E07; Sun, 7 Feb 2021 17:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 Ho7YIJAVxuCr; Sun, 7 Feb 2021 17:41:58 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D172F3A0E06; Sun, 7 Feb 2021 17:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ce1+UHUZ6oqlvvnd3+9ThpJ8o8hPByHVcgsMQiRQhnM=; b=nBtijvFDS0aE86oclMTEoQMWbw h9VC9JENn36M6sUfE+4VzoPTC7/eyFYn0Q/9haYoXqLU7OC2O3p7LnKjYkrExUQMDZwcmY38iLWKv OaIGqsEc4CV9C/hRkdWCVJFSiq5HEMCbbCwZge43bgmETE3Qa1dmDfGEDKPVgXevH03cwCUVmppzj BOGwP6SDnFKqgdo2BxqlMQsVldS3jkQvNndtExOU94EUqnuipkjM4nqTXwTngH5GasmroDbnU0kaG TEtx4WDjg87L1JwtvVx8C75l1qXZ4EdMjE1Ya1gGPsq0+M1CZr6luP4Cm0NZ3d+QtkgBTKBzufuZq zaivOmEg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:65398 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l8vYn-003Cav-HL; Sun, 07 Feb 2021 20:41:58 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: <161274608246.10975.9762681883669159913@ietfa.amsl.com> Date: Sun, 7 Feb 2021 17:41:53 -0800 Cc: i-d-announce@ietf.org Message-Id: <932AACE6-F602-4A0C-9924-BD24FF37655D@strayalpha.com> References: <161274608246.10975.9762681883669159913@ietfa.amsl.com> To: tcpm@ietf.org X-Mailer: iPhone Mail (18D52) 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-2140bis-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 01:42:00 -0000 Updated based on AD feedback.=20 > On Feb 7, 2021, at 5:01 PM, internet-drafts@ietf.org wrote: >=20 > =EF=BB=BF > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the TCP Maintenance and Minor Extensions WG o= f the IETF. >=20 > Title : TCP Control Block Interdependence > Authors : Joe Touch > Michael Welzl > Safiqul Islam > Filename : draft-ietf-tcpm-2140bis-08.txt > Pages : 34 > Date : 2021-02-07 >=20 > Abstract: > This memo provides guidance to TCP implementers that are intended to > help improve convergence to steady-state operation without affecting > interoperability. It updates and replaces RFC 2140's description of > interdependent TCP control blocks and the ways that part of TCP > state can be shared among similar concurrent or consecutive > connections. TCP state includes a combination of parameters, such as > connection state, current round-trip time estimates, congestion > control information, and process information. Most of this state is > maintained on a per-connection basis in the TCP Control Block (TCB), > but implementations can (and do) share certain TCB information > across connections to the same host. Such sharing is intended to > improve overall transient transport performance, while maintaining > backward-compatibility with existing implementations. The sharing > described herein is limited to only the TCB initialization and so > has no effect on the long-term behavior of TCP after a connection > has been established. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-08 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-2140bis-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > 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 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 8 08:26:04 2021 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 9ECB73A10F3; Mon, 8 Feb 2021 08:25:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk CC: Michael Scharf , draft-ietf-tcpm-2140bis@ietf.org, martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161280155900.25752.17787129729481516177@ietfa.amsl.com> Date: Mon, 08 Feb 2021 08:25:59 -0800 Archived-At: Subject: [tcpm] Last Call: (TCP Control Block Interdependence) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 16:26:00 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Control Block Interdependence' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-02-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 8 09:00:17 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4F43A129D for ; Mon, 8 Feb 2021 09:00:16 -0800 (PST) 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 UgDnR7oPAsV6 for ; Mon, 8 Feb 2021 09:00:14 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93773A1332 for ; Mon, 8 Feb 2021 09:00:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AE42025A15; Mon, 8 Feb 2021 18:00:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1612803611; bh=jMqHNFHx3jkYa83tOTZMHZQEmQyPx0OaSNiGcuMeZ74=; h=From:To:CC:Subject:Date:From; b=OkkwfMA+VAPUWl03j6iIdqB1BhirJMzRs52RQdsvGnHyQMDiqyLT1LqBNRwBxETXW CcLOzW3oB5IAHuj87YQloXMIDodsF3rlt9W3EZYDaO4F46X76N9Cq009IEIW1nJmrc f6sSqbxg3OmpEvKxiAUs1vSZ65wQMhYEu6IHuiXw= 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 aX5P8ySMEPbC; Mon, 8 Feb 2021 18:00:08 +0100 (CET) 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; Mon, 8 Feb 2021 18:00:08 +0100 (CET) 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; Mon, 8 Feb 2021 18:00:07 +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; Mon, 8 Feb 2021 18:00:07 +0100 From: "Scharf, Michael" To: tcpm IETF list Thread-Topic: 793bis ready to go? Thread-Index: Adb+OMcXKdPjASFKQc+5zg7FPT9zRw== Date: Mon, 8 Feb 2021 17:00:07 +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] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 17:00:16 -0000 Dear all, draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to Wes,= all WGLC feedback should be reflected in this version. A link to a complet= e diff can be found below. During WGLC, there has been quite some discussion on the exact wording on c= ongestion control. The suggested text in version -20 is copied below: 3.7.2. TCP Congestion Control RFC 2914 [7] explains the importance of congestion control for the Internet. RFC 1122 required implementation of Van Jacobson's congestion control algorithms slow start with congestion avoidance together with exponential back-off for successive RTO values for the same segment. RFC 2581 provided IETF Standards Track description of slow start and congestion avoidance, along with fast retransmit and fast recovery. RFC 5681 is the current description of these algorithms and is the current Standards Track specification providing guidelines for TCP congestion control. RFC 6298 describes exponential back-off of RTO values, including keeping the backed-off value until a subsequent segment with new data has been sent and acknowledged. A TCP endpoint MUST implement the basic congestion control algorithms slow start, congestion avoidance, and exponential back-off of RTO to avoid creating congestion collapse conditions (MUST-19). RFC 5681 and RFC 6298 describe the basic algorithms on the IETF Standards Track that are broadly applicable. Multiple other suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. An endpoint may implement such alternative algorithms provided that the algorithms are conformant with the TCP specifications from the IETF Standards Track as described in RFC 2914, RFC 5033 [10], and RFC 8961 [15]. Explicit Congestion Notification (ECN) was defined in RFC 3168 and is an IETF Standards Track enhancement that has many benefits [50]. A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- 8). As document shepherd I ask everybody - specifically all TCPM contributors w= ho have commented on congestion control - to carefully review this proposed= wording within the next few days. If there are any issues with this sugges= ted resolution of the WGLC, please speak up! If the TCPM working group is fine with version -20, 793bis would be ready t= o go. Thanks Michael -----Original Message----- From: I-D-Announce On Behalf Of internet-dr= afts@ietf.org Sent: Thursday, January 21, 2021 7:02 PM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions WG of= the IETF. Title : Transmission Control Protocol (TCP) Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-20.txt Pages : 110 Date : 2021-01-21 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 8 09:19:51 2021 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 5C7313A109C; Mon, 8 Feb 2021 09:19:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161280478533.15052.5687917084607152154@ietfa.amsl.com> Date: Mon, 08 Feb 2021 09:19:45 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 17:19:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-09.txt Pages : 34 Date : 2021-02-08 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 8 09:29:30 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F513A13A5; Mon, 8 Feb 2021 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 GAI_zTHHovNy; Mon, 8 Feb 2021 09:29:22 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106B13A13A3; Mon, 8 Feb 2021 09:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=N5bZ+B0XWJ0EAdSj3nYmUiOmoqB/X8Uazkb+msiAk4M=; b=UBSocFkReoFhHbY5UAmRsv1FqK NvgReMDJ6AyAg95EMfcP8cy7+3vVp7hmSaE299CHO1DEeQp9uN/einM/BlP1Avy7MPsBepo8D2lHw 8irjRcHN73VBorzgwoiAlW3sNuzJom2C0F4naXf/mSNPai7AcK7LIDw72xJrQF5dSNjQbTPCzFvXV 9Ar+nfzBlR5/vCdj9XOhagpq/DYBVQrpLJjOMu6GsNg8W9wxipEWD5J5pzntBY2it+Zmt7eoO/cyM tAdKCgWAFI+f2bSBkowenkterfOrA8m04LDkEv03djsVQYobrXa9FpUoy4pDJCHErQ47KkR3tHHc/ ngM3Prvg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60146 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l9ALZ-003PLw-SC; Mon, 08 Feb 2021 12:29:18 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: <161280155900.25752.17787129729481516177@ietfa.amsl.com> Date: Mon, 8 Feb 2021 09:29:13 -0800 Cc: IETF-Announce , tcpm@ietf.org, tcpm-chairs@ietf.org, draft-ietf-tcpm-2140bis@ietf.org Message-Id: <84875938-03F5-405E-B7A7-9CEFD7D46231@strayalpha.com> References: <161280155900.25752.17787129729481516177@ietfa.amsl.com> To: last-call@ietf.org X-Mailer: iPhone Mail (18D52) 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] Last Call: (TCP Control Block Interdependence) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 17:29:24 -0000 Please use -09 as it fixes a few typos.=20 > On Feb 8, 2021, at 8:27 AM, The IESG wrote: >=20 > =EF=BB=BF > The IESG has received a request from the TCP Maintenance and Minor Extensi= ons > WG (tcpm) to consider the following document: - 'TCP Control Block > Interdependence' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits fina= l > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-02-22. Exceptionally, comments ma= y > be sent to iesg@ietf.org instead. In either case, please retain the beginn= ing > of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This memo provides guidance to TCP implementers that are intended to > help improve convergence to steady-state operation without affecting > interoperability. It updates and replaces RFC 2140's description of > interdependent TCP control blocks and the ways that part of TCP > state can be shared among similar concurrent or consecutive > connections. TCP state includes a combination of parameters, such as > connection state, current round-trip time estimates, congestion > control information, and process information. Most of this state is > maintained on a per-connection basis in the TCP Control Block (TCB), > but implementations can (and do) share certain TCB information > across connections to the same host. Such sharing is intended to > improve overall transient transport performance, while maintaining > backward-compatibility with existing implementations. The sharing > described herein is limited to only the TCB initialization and so > has no effect on the long-term behavior of TCP after a connection > has been established. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ >=20 >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 8 13:03:51 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603123A15EE; Mon, 8 Feb 2021 13:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ1PdkQVYKOu; Mon, 8 Feb 2021 13:03:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 996103A15ED; Mon, 8 Feb 2021 13:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612818222; bh=HJYzH+Ar4fizK+Np6H7S66BO8gcfEFQSj/vBCq1dkcs=; h=X-UI-Sender-Class:To:From:Subject:Date; b=hIsO9y4axf9fVgUH7yNDhJNnG2SGFWdM6mXRe8F5u8p1LNx10WfKfrAszlMIZleH7 p7XrN6EUObvvOi1wYHd2w3UjhBXANTdkuLNiny7wcPF22yfWUXeHzC9fYv6YlPvoI7 uxDpxuiMTTpBDhSxhdqj7sa+ObmqX1hEdnuD5u3o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N6bjy-1lzNpq2MJS-0183kc; Mon, 08 Feb 2021 22:03:42 +0100 To: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org From: "Scheffenegger, Richard" Message-ID: Date: Mon, 8 Feb 2021 22:03:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:fginRENVMnGmgF9PE7mv9Blqmp15voqfggxAV5W4/Sx75PhdNS4 yNrUqEn7nlOQt1ltGsoTkGMmTpxecsdlnLY9VHqYkWvZLNm4oIN9FQHnvZNseOYfKkEVznD Qz8D+5ve/TXQMFI4fp2XPuXXNXlNrdIwMa5oBIjrjGmaOKWOu8aFgKS5GRuXuGD1KygjB3E 9YfzV87oC1JX99QdZgsAg== X-UI-Out-Filterresults: notjunk:1;V03:K0:TNhyHa4uFC0=:f2BCtAWBRBHI0ju8/jBPAM jNT7lYfP0we3xrS/wPoBm0lvnZ5yHOKOJaCeOYl90P3ROPL6M/LOnOWTtm6tuRRpWg6Z8SNA2 e1ftVzxumF/MpeWYeF5BO0tN9Rz6SciSz8LwIq04OcLaIlcp6P8sJzEgfF0Lx58uszhso4BCt PQTE8uB6qGXDqaH3+f8sligC1EZmZhV5bAaUGtldIajwLyzd64fn+PstVwBOIf+X68+zXh1Ug 9NI+4Ygdjb1A3luGDtYV1Htv4H84D2ydGhR02j430N0yL4pOyCN1ZGZgT3DRsFbeBRM9amYWr pRXg/DzGwBKuQ93VVF8PzpDtBoec31R6RN54wo0xCDq9n4LySKUrTDrXQRaDGdxrRhuXYUsZO bozH6Crh3zf4QAvJWAaMx2HWH6gyT7KIvWQQc420TCPtlqxYqgNgfxmXJpEfK6tjQ5NsNwCjK /mlnK6keIOBPfbNbv9V+mrewFHdjzrlntP+AnCxiDUkSol5Q8qWCxA+t2txoeGmRuyGxiSedv HmgFYx6xKZOSrcn/S/CptX5E5uPRMhuNMT0oYX4O3uIg+tYe7JlTUpTRIwtLPv3uHqI0egbam 5+mPob59jaeU22x9IRqBNIU7qcYTz4y/8r7yLqVlRhQhHcvMmPGRobJ/BcEQlFYdYMAG5kaXm aBxpJS82P8JZEcYWN2fFgYj/cMeRw2BXn1A57ArpsJf/9fU/ySAOSMBNsYWB3VtgWIYEepK5p Sxc/V/tJT9Hm0oW0pMDqPqqXQo/+XGlw0H2Xv6FdeC741kUhAOx8b8IgWkiMVWL+8PDOAGL1s sWSxakZpj+8yp+CzFiU/0hKH832VpJrToysTz45ZZB4k7Ak0c0mBg7F4GjiPomIXDLqoySj3U mUitFvAcd4JBcWgiXCxA== Archived-At: Subject: [tcpm] ECN++ control packet handling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 21:03:50 -0000 Hi Bob, Marcelo, While working on the ecn++ code for fbsd patch, I found that the codepath for dealing with out-of-window, past-established and non-listening ports is actually quite different there. Casually glancing over the draft for ecn++, I didn=E2=80=99t find a refere= nce specifically about the handling of RST (non-listening port, vs. closing session etc). This may need a hint in the security section, that an implementation should ensure, that control packets are always sent out with similar headers, regardless of the TCP state machine. Otherwise, you could potentially leak information (eg. Recently in-use ports) which may be a clue to malicious players=E2=80=A6 Richard Scheffenegger From nobody Mon Feb 8 13:47:04 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4FF3A163A for ; Mon, 8 Feb 2021 13:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acAswoxe54rJ for ; Mon, 8 Feb 2021 13:47:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 1F0DD3A1639 for ; Mon, 8 Feb 2021 13:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612820809; bh=slbcVXbUF9lBJYcA2d2TU98nmQVPH8urCGjjRaeu5aM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=TpxxrW0nVAU/svt9/kyCP3na5sfQ957w3ty6SuAIo2qcOzIGoDL88H3O2uw/dPPo8 L2NbIo3LKWncGH2mkrwb6fGORmbOH1xH9CGZG7j0F7QOsjAd/5tZhIt/A0joVWmeBj Ck7LqU6TSP4vQL8eEKFYlEhBGsED/uTo/ZTxBpCM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mkpap-1ld2wx2RYN-00mI3J; Mon, 08 Feb 2021 22:46:49 +0100 To: Yoshifumi Nishida , Joseph Touch Cc: "tcpm@ietf.org Extensions" References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> From: "Scheffenegger, Richard" Message-ID: <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> Date: Mon, 8 Feb 2021 22:46:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ahbjLN2VdfX+WJfEVlQUYznJ7i2DJJgO03gawldn52u6fDaAJ5W IK5JLVg41ySa16zjm9SbVsRLrMJ/CLThxj+SRZc+/cjCHrxOKgsBTm8Etc24h/+6WDURs7M KtH/uWM3lDVj24WgBneOyTj1SFBrllrSILTJakRo3gDwhTHidHevKRAV6yNl/Ejy7ShlVJV 52YNj0Q2Kh2NRaJvhtCpw== X-UI-Out-Filterresults: notjunk:1;V03:K0:4lwHCm/8UME=:fohzwnqFwpjOcBwpTX+sgT bFziw/HjTVSxJXne8eJmpe6+0uQCbPF/WLdnSdzWB0WrmamE88dCBV65Wiru3dgMROM42SMpP rEWNzuKgvR4MUOydq9aKrZH+PHGN+5jciiRsOd3ipFABvpm3FX9AXgLLsGrZlhI9rjSi1N9vW IbtBW0qvWF4Gq7CpdhenMgx/LcyKr/vW2bAldm4kBMfVK/eRTkYhyRghnb58iCBEDS8EtZs4d r/dw6cmTG7o8tjOaXdqMoCVCpTtlGqzPOxKB1mOrmp/LhlnhHrKc142+ziWOICygCvEJIzBhg R5QEOIhN8W2JRedsGDzafNGAslJGrIUlEnmomtFwmNAvhg56mwyf7afhkRbINru8cDp4qHIhG 17pvc8zxVPi78g8pGYuMCZ/ninO4feEZt7j3J86emdQ6JeyZjfqEM7IjE3CKjXowv+QEUlomT fzcNiBI6wkLNxmNzbKupVLRHOj09v7ahqRA4m7/L0GqFs8drLu6V+GTuM6REAG4RsaX1mmZLH PUD2vURIwfUhtDvYytYlxVaVnO3q1ee7aoOjSzuU0iVWjfY/Xunn5xeNNfMAeqyQnE12H0GGt bFysdGUcNMWbFbfExFB4mgIddw5Pvpd7RjKc+LkbKMuqWH4oI6KlVefFYoGuHFcieoe5d5g3H 37c925B8/Zsaf8G1+CjdsHh6z1t1gLFOfhpOqqo89EoMCmKutyXTMZYWSk3Pwr2JLEovilWj6 KmgejVK1H9WL0Eni/2VZ1xQxQSQEG+59Z9STv+5ecG170Bf514pOxScuGZ/L5zyTMfqlwC2Hh 4PSd2gMDfcNoRiJOltwMwJLvGvMBfxZrL3a7vlmRcFYzlLNwam8979IDzJ9mOHdex9tbwG1o8 F67hFzSceDkn99zp71Bg== Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 21:47:03 -0000 Hi Yoshi, Sorry to nitpick - in your draft, you mention that some hosts reflect back unknown tcp options, which is why you are using different GID mappings between SYN and SYN,ACK. I did read about this behavior concerning TCP header flags / reserved bits - but have not come across a paper where this behavior is described for unknown TCP options (or I may have missed that aspect in the various studies around TCP option investigations done by MPTCP and other groups). Also, I am lost in seeing how changing the GID association helps prevent a misinterpretation. if the client sends out SYN [GID1, GID2] and the suggested unknown option reflector comes back with SYN,ACK [GID2, GID3] (with the same GID bits), you still have an overlap and a potential false negotiation, not? The main issue about backwards compatibilty that Joe mentioned, still persists; this approach may have some utility when two hosts have repeated connections with each other, so that on subsequent connections, only the abbreviation is exchanged. Best regards, Richard Am 05.02.2021 um 07:50 schrieb Yoshifumi Nishida: > Hi Joe, > > On Thu, Feb 4, 2021 at 12:35 PM Joseph Touch > wrote: > > FWIW, I would have called this more =E2=80=9Cdelayed option negotiat= ion=E2=80=9D > than its current title. > > > OK. It seems it makes sense. Thanks for the=C2=A0suggestion. I will thin= k > about updating the title. > I also would like to hear from people if there're other thoughts. > > The core issue as I see it is atomicity of options; there are many > options that interact with others that cannot be delayed this way. > And if option negotiation is delayed, the issue of what to do with > data in the meantime. > > So overall, it could be a generally useful addition, but is quite > distinct in capability and impact on both options and TCP than the > previous attempted solutions. > > > I basically agree with you=C2=A0here. > In my view, the previous approaches such as yours try to provide > complete solutions=C2=A0to SYN option space, which can lead to very long > discussions from my observations. > Instead, the draft tries to provide a solution that has several > limitations, but it can reduce=C2=A0complexity and the risk of middlebox > issues. Also, we have similar precedence for this approach. > > The=C2=A0main focus of the draft is to support newly defined options rat= her > than existing options. Especially, the ones that use EXID as they tend > to consume more space. > One of my concerns=C2=A0is scarce SYN option space discourages people fr= om > developing and using new features. > > As you mentioned, some options are difficult to be delayed. Section 5.3 > describes this limitation and explains that TFO or AO cannot be > supported with this. > But, I think this approach is still useful as some options will not be > affected even though the negotiations are delayed a bit. > For example, if you want to send special=C2=A0feedbacks on some events b= y > using a certain options, you don't need to hold data transfer for the > feature. > Or, in some cases, delays can be acceptable in order to use new features= . > > Thanks, > -- > Yoshi > > >> On Feb 4, 2021, at 12:07 PM, Joseph Touch > > wrote: >> >> Hi, Yoshifumi, >> >>> On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida >>> > wrote: >>> >>> Hi Joe, >>> >>> Thanks for reading the draft. I put my comments in lines. >>> >>> On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch >> > wrote: >>> >>> Hi, Yoshi, >>> >>>> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida >>>> > wrote: >>>> >>>> Hi folks, >>>> >>>> I prepared a draft for SYN option space extensions. >>>> I know this is a difficult issue in TCP and has been >>>> discussed for a long time. >>>> But, I'm thinking that it might be a good time to discuss it >>>> again. >>> >>> The proposal has two parts, which are (AFAICT) separable: >>> A. Aggregated options >>> B. Adding more option space in the 3rd packet of a 3WHS >>> >>> >>> Right. both can be used supplementarily. >>> >>> (A) is fine, although the most significant issue is legacy >>> interaction. >>> >>> (B) is no longer extending the SYN; it=E2=80=99s actually just >>> post-SYN activation of new options. >>> >>> >>> In my view, all options are negotiated=C2=A0during SYN exchange. >>> There's no post SYN activation. >>> They are just additional information for the features already >>> negotiated during SYN exchanges. >> >> I disagree; you=E2=80=99re suggesting putting NEW options in packet= s that >> don=E2=80=99t have a SYN. In that sense, it=E2=80=99s similar to my= proposal, >> which uses a segment with no SYN and no ACK bit (the out-of-band >> segment). >> >> However, the problem is with the first SYN-ACK you send back. That >> is typically a confirmation of all options supported so the rest >> of the connection can commence, even for MPTCP. In your case, the >> exchange continues. This not only adds multiple RTTs to the open, >> it interferes with data sent in the SYN, data sent with the >> SYN-ACK, and fast-open for sure; it could also be a problem with >> many other options that don=E2=80=99t make sense in subsequent segm= ents >> due to the way they need to coordinate info that is used in the >> SYN-ACK or other ACK segments (e.g., TCP-AO comes to mind). >> >> At a first cut, the doc needs to address this, e.g., saying that: >> - if any user data is included before the option exchange is >> completed, it has to be delayed until it completes >> - how to handle options that are first seen after the SYN >> MPTCP can define its own behavior for this, but your doc cannot >> redefine that for other options >> >>>> Key ideas of the draft are the=C2=A0followings. >>>> 1: drastic changes in TCP's spec will not be required >>>> =C2=A0 =C2=A0 (it does not require updating TCP header format= nor >>>> using multiple SYN packets or additional SYN-like packets) >>> >>> Post-SYN activation of new options is quite a drastic change. >>> >>> Nevermind the question of what happens to data in the SYN, >>> which normally MUST be passed to the application at the >>> receiver after the final ACK is received, but here MUST NOT. >>> And the data that might go in the other direction in the 3rd >>> message with the ACK. >>> >>> Basically, you=E2=80=99re proposing to change the 3WHS to a 5W= HS, >>> which is a lot more significant and complex than described >>> here (there are a lot of failure modes not addressed, for one)= . >>> >>> >>> RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It >>> can be varied depending=C2=A0on how much extra option space is nee= ded. >>> MPTCP adopts 4WHS for its negotiation. In my view, the draft just >>> extends the idea. >> >> MPTCP adopts 4WHS for *its* options, which is its prerogative. >> You=E2=80=99re attempting to define 4WHS and 4WHS semantics for *al= l* >> options, which I don=E2=80=99t think is viable. >> >>> Hence, I am thinking the degree of the complexity would be more >>> or less the same. At least, I don't think it will be too complex >>> to implement. >>> >>>> 2: utilize the option negotiation schemes in mptcp for >>>> generic purposes. so, I think it can be considered middlebox >>>> friendly. >>> >>> MPTCP is negotiating variants of an option that is already >>> active (AFAICT); that=E2=80=99s not the same as activating new= options. >>> >>> >>> My understanding=C2=A0for MPTCP is similar and I think this draft = does >>> the same things. (from my point of view) >>> =C2=A0If you see significant differences between them, could you >>> elaborate a bit? >> >> See above. >> >>>> 3: it has some limitations=C2=A0(e.g it can only extend aroun= d >>>> 30-40 bytes for SYN option space). But, if it's combined >>>> with EDO, we can use more option space. >>>> =C2=A0 =C2=A0 (depends on how EDO draft will progress, though= ) >>> >>> If you have EDO, then just negotiate it and activate options >>> after the connection is established. But that=E2=80=99s not th= e >>> problem at hand - the problem is activation of options in the >>> SYN. AFAICT, this does not do that. >>> >>> >>> I think the negotiation scheme for EDO is simple. it needs to >>> send 1 bit information to indicate the activation of the feature. >>> This can be done during SYN exchange. So, I thought it's fine to >>> use this feature in the 3rd segment. Or, are there any risks? >> >> I do think that if EDO is negotiated in the SYN then you can use >> it in all subsequent segments (that=E2=80=99s already how it=E2=80= =99s defined). I >> don=E2=80=99t think it adds any risks here that aren=E2=80=99t alre= ady part of EDO. >> >> Joe >> >> _______________________________________________ >> 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 Feb 8 13:54:48 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3D3A1639 for ; Mon, 8 Feb 2021 13:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBCr33o1Ndqx for ; Mon, 8 Feb 2021 13:54:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 5D57C3A0FFD for ; Mon, 8 Feb 2021 13:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612821279; bh=LOVCIodFafoUdROve69GkZQaiZr/UfIyyHeQcSMP2wA=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=bDFShcIRqjPggbWj587G9jPB0ZBhVSt+Hp+g6Sd8tC8JUb72EOvHfH+3QTDC1uxjD UWDOjs1eOzsIVihQQT7AfdmdSiI3/3zBlV6aAr6LYmYDjGacMQlK2tj7wBLrhoS36Q z6KsyerJHeLrx9g57SsFeyYeetBX1IATDP1v8mzw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MN5if-1lRjFD2Ebd-00J1Jd; Mon, 08 Feb 2021 22:54:38 +0100 To: Yoshifumi Nishida , tcpm IETF list References: From: "Scheffenegger, Richard" Message-ID: Date: Mon, 8 Feb 2021 22:54:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:jl4QG8nXLAl6vZNfVw8+W1XjhVqfM6MiueET/hTJwK+o2A01bPC z0DJXOJBG9IkrQ1nD/9EbqyhizPHSmKLA2bkwRDkpfs822HOcWRSuSGyN8dwN++n/0VXxKU 68a0J8OatEtJ3MIqEmqHakCBcOUOpnPBQiBIF/bdSjJ/DFVBtiAPQeyFIFxAAaic44YcAZn dd5kZcMb5PgBtlFN867aA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Lc4my5LvrEI=:N+JbVsg+1pBNDed9+XNBNZ RbF5N4BjTwKypSbMOpDBf2pa95TLaAoOpg9VI55qNBfX71R9wb3DiJUOR0Oxf4a1snKn+CRyL nb0lrzFnRVHrjyRiXmTrl6bIphwXi/cqIKM5Nbm13fO6sxn3D9Lgq4lMo86uNy55mXkZefokS 9rPSelqntEtoHmgwmcTJAH/deRR4SrBShz23eOSwFM85Tk6qLpLLvIRz2oMw32t1pIJQ/0rOP rP6GQ9CQhrXZtZ5F93L8RawBarHzSjOLcwsfizZnctN5Lwgk3gFPgZmmmiJ6cuowPin3uy6CH 1Rs3iNXptcq1v6bZ45eSLmudJ+F9DkVCgoSWy86G5lcgPChSX8AIX7cIu0n708X8BcwwcfxdM grp4jHhiEgBMQZlQtIRu75Rtsuqw7PbC5zSbRc5lftq6yTdinf5T1vjn+mfbm30I0eyyGPwRx SQNb4E9Tx1zyU88H7NjMQmwJPxIL8vsYwgneussyKoUsBb6eRZ9zTdczh/aZl/sYjJGJjsasP S7lqyGItn/swuVKRD9hqRAS0A8EP8zAG/DDeMMmmpHQFGJIW/3RDnZW++864E4k9L+wM9fiT+ uRaauxAu57eh0URyacVDTtJuibuC4X/6D1nLwv4TKQn7EEJQL/r0gz7l+rlyd93xj0bdPcTh1 sRpWkZaZFZYM+ntNQGt1Oo3JUa1dSCOz4kKcTBPO//XUYUFPdOrqVqyOE3YlZhfv/3YfhZ8Mj gPYk9NtqJ4ZK1s6Ei3iYjZcEY71X/AYkFyIIZRq2nUCI33PyrWEFf/bALlCkTZUt6MidrYFdK U/1btMcmjVIGKUhNdC8MkrRA/lEMfssBX2wOOh+jvarH6hf9smSGliQHySp12HvDYSLDW3N67 bolf4YF2XtIHbyLla47g== Archived-At: Subject: Re: [tcpm] Request for feedback on WG Adoption of RFC6937bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 21:54:47 -0000 FWIW, PRR has been included in FBSD13 as default. That implementation my be a bit rough at the edges - the particular case to deal with "broken" token-bucket traffic policers mentioned by Matt using an automatic heustric is not in, and if encountered, need to be dealt with manually. Richard Am 30.11.2020 um 19:12 schrieb Yoshifumi Nishida: > Hi folks, > > This mail starts a WG adoption call for RFC6937bis draft. > As we've already seen positive supports for this work, we are not asking > people who already expressed their opinions this time. (but, if you want > to do it for some reason, please go ahead) > However, if you haven't done it yet, especially if you're against it, we > would like to encourage you to provide feedback. > > We are thinking that the intended status of the doc will be PS based on > the feedback we've seen so far. But, if you have opinions on it, please > let us know. > > Thank you so much, > -- > Yoshi on behalf of tcpm co-chairs > > > On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis > > wrote: > > The authors of PRR would like to update PRR to Proposed Standard > status.=C2=A0 This entails introducing a new document as an tcpm wor= k item. > > *Please indicate (non) support and/or comment.* > > For more details see the tcpm meeting materials from IETF 109 > minutes: > https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-= 00 > > slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 > > > There were about four "I support this work" remarks at the mic (not > recorded in the minutes), and about as many in the Meetecho chat. > > Abridged IETF/tcpm/PRRbis slides: > -- > PRR =C2=A0recap (RFC6937 experimental) > PRR is a special congestion control effective only during fast recov= ery > > * When inflight >=3D ssthresh, send at loss_beta*rate_before_loss > (e.g. loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cub= ic) > * When inflight < ssthresh, send at the same or twice the > delivery_rate (more later) > * Used by all congestion control modules in Linux during fast reco= very > o Can be more dominant than the actual C.C. for lossy flows > that=E2=80=99re in fast recovery constantly (e.g. video stre= aming > through policers) > > -- > Current Status > > * > > PRR is widely deployed > > o > > At least three major OSs: Linux, Windows, (NetFlix) BSD > > o > > Vast majority of Web traffic for years > > * > > No changes to algorithms published in RFC 6937 > > o > > PRR-CRB - Conservative Reduction Bound - strict packet > conversion during loss recovery > > o > > PRR-SSRB - Slowstart Reduction Bound - one extra segment per > ACK during loss recovery > > * > > 2015 Heuristic to dynamically select which reduction bound > > o > > Only use PRR-SSRB when making good forward progress > > + > > ACKs that advanced snd.una and report no new losses > > o > > Resolves some pathological cases with token bucket policers > > + > > CC estimates ssthresh before it can possibly measure the > token rate > > + > > The heuristic makes the best of a bad situation > > -- > Tentative path forward > > * > > Adopt as a tcpm work item > > * > > Update the text > > o > > Normative RFC 2119 language > > o > > Add MAY use the heuristic... > > o > > Trim redundant and obsolete language > > + > > RFC 6937 repeats itself and is much longer than necessar= y > > + > > Focus on what an implementer needs to know > > + > > Use non-normative references to RFC 6937 for prior > measurement work, etc > > Thanks, > --MM-- > The best way to predict 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 m= easured: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypoc= ritical and risks spiraling > out of control; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mist= aken for tacit approval. > _______________________________________________ > 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 Feb 8 14:15:54 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5563D3A1668 for ; Mon, 8 Feb 2021 14:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCu13g4VzWJ7 for ; Mon, 8 Feb 2021 14:15:50 -0800 (PST) Received: from rommie.caida.org (rommie.caida.org [192.172.226.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2629F3A1665 for ; Mon, 8 Feb 2021 14:15:50 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rommie.caida.org (Postfix) with ESMTPSA id B102A2C1639; Mon, 8 Feb 2021 14:15:49 -0800 (PST) Received: by sorcerer.cms.waikato.ac.nz (Postfix, from userid 1001) id 9B75812C07D8; Tue, 9 Feb 2021 11:15:45 +1300 (NZDT) Date: Tue, 9 Feb 2021 11:15:45 +1300 From: Matthew Luckie To: "Scheffenegger, Richard" Cc: "tcpm@ietf.org Extensions" Message-ID: References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AgUBslABGt2kcf2G" Content-Disposition: inline In-Reply-To: <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:15:51 -0000 --AgUBslABGt2kcf2G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Richard, On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote: > Hi Yoshi, >=20 > Sorry to nitpick - in your draft, you mention that some hosts reflect > back unknown tcp options, which is why you are using different GID > mappings between SYN and SYN,ACK. >=20 > I did read about this behavior concerning TCP header flags / reserved > bits - but have not come across a paper where this behavior is described > for unknown TCP options (or I may have missed that aspect in the various > studies around TCP option investigations done by MPTCP and other groups). There is some discussion of systems that seem to reflect TCP options here: http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_multip= ath_tcp.html Matthew --AgUBslABGt2kcf2G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTXPLTkr00GLuDVs20rK4MpIRAAYAUCYCG4CQAKCRArK4MpIRAA YE5sAKC4iup761B3AJS9DnO93kXYInhyTgCfbPBgNQH6gTbd0nbs0IEyoJ8JcLI= =6CLU -----END PGP SIGNATURE----- --AgUBslABGt2kcf2G-- From nobody Mon Feb 8 14:27:32 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0903A0E2A; Mon, 8 Feb 2021 14:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm6r3twsZuZY; Mon, 8 Feb 2021 14:27:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 6A49E3A0E22; Mon, 8 Feb 2021 14:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612823241; bh=wrPvSXoKGGVOCMZr7Zlg9AV5YGj5nQeYTh+bTluBkbQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=goIskflmdA5x3QKTgAl+Pa7SPY/T7YYXQjEJULrmqiNXxtivXfAToD5ppV11Lwi5y OgF01yqxEe+cikBjjDEZ93tctw95U5E+rYXBKpn1gDnj915rYtHvZo+B4ACM/3fdct l6CNMKkZBKKt0BAQqM3ArB6RtwdKlcyYxaHjMSfA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQe5u-1lWwWc1ZWI-00NiDd; Mon, 08 Feb 2021 23:27:21 +0100 To: tcpm@ietf.org, draft-ietf-tcpm-prr-rfc6937bis@ietf.org References: <161060871994.10783.1247396842504892132@ietfa.amsl.com> From: "Scheffenegger, Richard" Message-ID: Date: Mon, 8 Feb 2021 23:27:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <161060871994.10783.1247396842504892132@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:vPIQPpsTJco1klfkR0gysHR/Rz6CvfUiaJBxAdyQiZ3NZNMrVbb XZa5VWMp+e/s50NW1Qg+kNWikyVho77VK2ED7bvMjzoIzLHvfuZaix44cb20uF7XqjDy7HD xA/Z9PPgWz9bR7tmdFsK9H2NgPasKV03zHw327tUt9b1/VlmgKmHgyqb3kghvt0oQvz/5EL EyMKqghPtHcz1rzAMecwg== X-UI-Out-Filterresults: notjunk:1;V03:K0:n0HgsDEK7aw=:z8lKh/ttym17PHsTyHzjpq 2R3G4Zc7wO8+WOKPHq2jDtC96RMjhJmWnCg7kvAORmNMWG9j/4zcvKo7hXUubb7yG3p/ewm+5 ert/+s1WgsRuisUBqBaic6SvvqxFvbxFTRc8y9ri0CH563SAWQNLcfD4FuWgUXL0mXuU4E69k Y8ajXdNfER+w7nOfOw5eYqFKbwjbi1n5LQg0JXaWLS2UTR/duH4rIvFNpyjPCBQIGD2kz0DkZ Jqp4vochf5NoKqA+oFg/vjmFlbWER0rVza7Tt/BHlTtK0imNo1lFy+S9+WiZP2+0pDnAVjJOb B4VUJelltz7VoLS5EHGVoUPL9mv4IF9pd0NvIuomBrQn2pbsF7ZKythoOSjPwWleEJm2GcLYn enZm6Bhy++pqfbo4j2tMzYHR3P5mZSkzrExZyeWD08MFHVc9Eu5xJG3Jp5gi1Y97ZFeiPEdZD ledtDVRtBchfeZ2fcm+tem1GnYBbBfbkTM5YA8f+owLOqy3H1FcOW6m/brO2CAwYe3/TC47km u0sLsnz4Gy7wNFsJsQ/JwHwt2n03xDQ64pir5toI+od1opku0RdWCi8NW3TK/HFgZSn4V+E3M tCx61o+vfEZwUwoFIg1skfaNGPnop0PGYpc6PYXlFsuyUg0+WGpmt6f40VLTs36eOK7Zl2P4k 0TOaSn8eEaeTVXq3FyNc7bMq8xFw4uc0jEyBGqArwD07AHOoPZqMU86YLYR/vi96vMxIwLyJ1 cAc9JAnYD8IKHZJmR2a4/Kn1X2yGoyuqBjLp75kAqJq/O5Q5KGoEt18UwELXNtcvp/SEXjGwd RRhwY5Q0ZBlO+fI90T3oSbZp91eOzYC4pazB+ik1zZmbQewIS/SABA/z1t2w9i7s9FO3wFKQA kwzRLbeFm5tSxEpDCQMg== Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:27:30 -0000 Hi Matt, Yuchung, Nandita, The heuristic to switch between PRR-CRB and PRR-SSRB is only mentioned in section 1 (intro to bis). Perhaps the actual pseudocode and text in secion 4 (algo) should also be expanded to contain this. From an implementers viewpoint, the paragraph about the heuristic (as well as my conversation with Matt about this) left me wondering, if this needs additional state, or how to achive this (e.g. tracking changes to the SACK scoreboard - if an additional "hole" got accounted even when snd.una advances, for example. one nit: In the para for the definition of "SACKd", there is one instance where the "SACK blocks" got changed to "sack blocks". Its the only instance of lowercase SACK. Best regards, Richard Am 14.01.2021 um 08:18 schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG= of the IETF. > > Title : Proportional Rate Reduction for TCP > Authors : Matt Mathis > Nandita Dukkipati > Yuchung Cheng > Filename : draft-ietf-tcpm-prr-rfc6937bis-00.txt > Pages : 19 > Date : 2021-01-13 > > Abstract: > This document updates the Proportional Rate Reduction (PRR) algorith= m > described as experimental in RFC 6937 to standards track. PRR > potentially replaces the Fast Recovery and Rate-Halving algorithms. > All of these algorithms regulate the amount of data sent by TCP or > other transport protocol during loss recovery. PRR more accurately > regulates the actual flight size through recovery such that at the > end of recovery it will be as close as possible to the ssthresh, as > determined by the congestion control algorithm. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-prr-rfc6937bis-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-00 > > > Please note that it may take a couple of minutes from the time of submis= sion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Feb 8 14:43:06 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9D73A16EE for ; Mon, 8 Feb 2021 14:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=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 8K3cMRd2prtn for ; Mon, 8 Feb 2021 14:42:57 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5113A16AE for ; Mon, 8 Feb 2021 14:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7IyuURYXaQdjUC2KkfuiCXnZmLt2+cIqVjgw0ACA+AY=; b=ygCUM55KvnQI9haIy/6pnz4/Ld B0AtUDjnQodi7aizb5fuUubdgfpWrE2QDgc9m4l+c7nWte+wr6K/ABSRqtc028CP4ZVJCxP28Qay9 DCIDRp+1NckayrCT0Awk8NZe4SrcLTTUYuaVQ45YKm6vuNbUi7yHNEggQQyTDAQdj9O62rwMLTnlz EQOoZUBh70r76DcxQuuXZ30pTM+GtTp1zwxYIqQox5gTzcKaWiJTBsSEHnFJfKfv0bMoViHPRYm22 nQWdXNXQPwToXz1iANqKFIWPpBLhMttWOKu4XpQF/WbCsmUzJBFetldDcwL8lkOvtoeT5rerdS9ai fovn3LLg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61187 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l9FF4-000KJE-94; Mon, 08 Feb 2021 17:42:54 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Mon, 8 Feb 2021 14:42:49 -0800 Cc: "Scheffenegger, Richard" , "tcpm@ietf.org Extensions" Message-Id: References: To: Matthew Luckie X-Mailer: iPhone Mail (18D52) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:43:04 -0000 That sounds like a very serious bug. It would be important to get it fixed b= efore we all waste time trying to adapt to it.=20 Joe > On Feb 8, 2021, at 2:16 PM, Matthew Luckie wrote: >=20 > =EF=BB=BFHi Richard, >=20 >> On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote: >> Hi Yoshi, >>=20 >> Sorry to nitpick - in your draft, you mention that some hosts reflect >> back unknown tcp options, which is why you are using different GID >> mappings between SYN and SYN,ACK. >>=20 >> I did read about this behavior concerning TCP header flags / reserved >> bits - but have not come across a paper where this behavior is described >> for unknown TCP options (or I may have missed that aspect in the various >> studies around TCP option investigations done by MPTCP and other groups).= >=20 > There is some discussion of systems that seem to reflect TCP options here:= >=20 > http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_multi= path_tcp.html >=20 > Matthew_______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 8 14:49:22 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCC63A166E for ; Mon, 8 Feb 2021 14:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmrQdrdUaHsj for ; Mon, 8 Feb 2021 14:49:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8603A0E89 for ; Mon, 8 Feb 2021 14:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612824553; bh=W3p04sFnm6V2gHQuoW9n4LGdfw2ZWEaziDzzD9qSqcA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=a2Cje1/0/APo598R53ieV99hqevLh5g7Rlb3xaZej99ciQl/h9SFu8BckDVgOZh2w QFDWPux4YCZIEZiyniIZ75AZGTyLGJplC0/6XNr8N/j4rMIO75T5yIjF9Ed5v30syB U8c3qltLHwVfSYI8bP1ZeuhUyX6/LEHMQwsVm9/o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZkpb-1lNpVv2lNv-00WnBf; Mon, 08 Feb 2021 23:49:12 +0100 To: Matthew Luckie Cc: "tcpm@ietf.org Extensions" References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> From: "Scheffenegger, Richard" Message-ID: Date: Mon, 8 Feb 2021 23:49:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:b9XDBH57FniKBPYA8upJYubwjMebuvtQsjSLjhqoM5Umv4bzQT9 bL1tgKMhhP5CCp6WL6d8T2h+lYLKNSYoC0ACqw45UrO4E0lE0g1aocGaI9ZXy/0HdypYueA ZqKjmb9Dna8/ped5oiZHcwCsT7sgJVgMWKjSrzj0HUVSbZcj9J9CPEgPh6iLYYs74S0coev bNUFGq3ym0/lDy2TLco/g== X-UI-Out-Filterresults: notjunk:1;V03:K0:4B5sCh3K8sI=:bxfqnpR4F7aZpYvQF7HMEZ 4cODflxGT9L0hZ9T0eXB5/l/PNTsr7s4foMUrjrCCOgsuFW/cM6Z1eDah4kWBQbjzA4sTZ/jd phKwjqUbk2OWNZNBvsYsxm55hv1qu0USfn5ZEqK1vPzKflmq5HwkT6xjvnwecfah0e0xPw/+x zuHW3ccT5ptHMM5jDKxk9W7LVT9UEB9p4JFllH+RSYpZn7OI5+7Hjkq1C+tlKNBteinVoc6jf iBZh1aXrCzlzwVIDA1nr9PP7EM13uJQ+RDxyukY4Ue3iRv8zuRtsjZe9xUmGrKhkBd4gsp3Sq +v14NuH7m/ukmizNzqr/Cpv80JXBQDQBub/J8i2wlnnenXgctwxMbi8EgoCVTFPWfQkgeb6K+ enKa9T4aU8TaK+Z7bk8csqkDtsOTqVSkxL+HxQGo9vrVmH+FFKb3Nrz1vtVOQMKeuXSZvBqBy wt31j4bRqR97/hGn73WJvbtBJLXbb++kCu9gQOvOKAaizmxX8gD/mEB2qkIlm95/5fVZyuSRo VgICGpKt+6yemS/ME2tY2xngT2pgIepB+KXYZ6TIuGHjIfu14OnCgLwwMRHZD4xqa70O91tlu wcz70rFrWdOrIAXC98LbXUtrw0z9TB2mxdiPvhpg+S2/vHp0vwCHgOM9X2bLO5VCZeSDvAXxI 2wiV1lLIaRo54NZx4ewLeNTFbMUwIia645UsLPMsKQqjew6pd0hHvoeo0hiviaeNFRMCEwSgc GE7Vq3p1rbBqPhwKQMyPhQZUAx1Ww/908LswnklgsI/S7/JOVIhBfgojtZl6wg0c3twIVwV9R toLWU/s2j2Y0P2ewkeXaRcWLj+4L3uu0wwy/oZPIGbYHr2LKPt/f8G7xcFEtHoIfqX3pF9jfR zvMMdiMtXc014tZ2zShA== Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:49:20 -0000 Thanks! Still, without additional constraints my simplistic reading of how the GID value mapping to groups doesn't seem to address such collisions entirely.. Also, some options are not necessarily negotiated, but only indicated - thus a constraint that corresponding bits of the group may only be set in a , when they where present in the is not sufficient. One constraint I could come up with would be to require the server to reflect back "empty" (all zero option flags) blocks received from the client, in case a bitstream collision would otherwise happen e.g. client wants to signal option flag 7 of group 2, while server wants to send back option flag 7 of group 1 (but not flag 7 of group 2), the current draft would allow a "valid" exchange that looks like a reflection. With the above, additional constraint, the server would have to return an all-zero block for group 2 also, and may NOT skip over that... Best regards, Richard Am 08.02.2021 um 23:15 schrieb Matthew Luckie: > Hi Richard, > > On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote: >> Hi Yoshi, >> >> Sorry to nitpick - in your draft, you mention that some hosts reflect >> back unknown tcp options, which is why you are using different GID >> mappings between SYN and SYN,ACK. >> >> I did read about this behavior concerning TCP header flags / reserved >> bits - but have not come across a paper where this behavior is describe= d >> for unknown TCP options (or I may have missed that aspect in the variou= s >> studies around TCP option investigations done by MPTCP and other groups= ). > > There is some discussion of systems that seem to reflect TCP options her= e: > > http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_mul= tipath_tcp.html > > Matthew > From nobody Mon Feb 8 14:51:34 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0423A168F for ; Mon, 8 Feb 2021 14:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvNj4Tx0JcE5 for ; Mon, 8 Feb 2021 14:51:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6750A3A168B for ; Mon, 8 Feb 2021 14:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612824668; bh=jD36R8aPP1Sb7EISou1vy1PnFte13kmkH5FPW8xUWJ0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=BHg0hgvtwyMB0ZrTcD3+2WzF0Bd/JRakb50XWRj+uNQKZ7QhyT8Z0H2jJChmVopz7 lrN+0AZTcqERBv1ptVEPBzDc5qF9iKTgszsGW4LHDYjuzV/Fwk118RtzR4SSZp0ora 7LfLS+Sy2tRNZ273YN4QlI+FS6w9Ve34fZ1s1bf4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N7i8Y-1lw2dq28zS-014iSZ; Mon, 08 Feb 2021 23:51:08 +0100 To: Joe Touch , Matthew Luckie Cc: "tcpm@ietf.org Extensions" References: From: "Scheffenegger, Richard" Message-ID: <7185f861-bd66-d157-714e-e3b10e6d40e3@gmx.at> Date: Mon, 8 Feb 2021 23:51:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:R8ED8XdNmFX8QZShMv85OvlzFzeKSv3o1iQALwSUGxkm+YdLD9G 6UXa0Dm0Uk8goIXb8NQUyC0JK5pZRu0q1aDSYVyZfAU/jmx+np0zEC2H4EvRc9KsOm31O7f G7FiwBCLeNsE1QQiylszU06dH4s22KCrECjVoXDyDNEaBb090Rn21yQ4oxE7syXJcszq6qq 0FTGGP8PThUEXUX/fpcaA== X-UI-Out-Filterresults: notjunk:1;V03:K0:YszkrmDNZQ4=:kINs/Hq5mWBw8kv47Ck4ND 0VBTTojY5FhUk2+WxNQnNqxbexDAN7VZkTVeTGYYcffjZxO+qcGtgcf0aVg2gl2qTFvAqRY/E U3+9VFxHcB30wqN5CAgllNZ7W7KhNzt7M4oZjoZYlDbG/8hMOBgdiHFza+4fivLDzDgW8ZH/l JEjLsiqu0qMdxlw31J4VgyUfoCTzhbwl0WLm8ROhmiDRo674WrCIGRSUhZR0KUPn55oHpHHeh m2S9C7Q0wel/hMF7JNWOLA+tdZxTywM0iFfYC6NGWPdqplG9yRa15iNLVO2h3WQQs/07EcS6M KZ46MMz/AA379lznW+Cng2rGmFNdnnXRU9OE8tIGBkCHmVnfVvW5b6mt8oF8q76wsd1/hkBS4 WFiPBNrQAAfDBc1yXt4N08i5kHEaC/BLacDbXMJv1RlH2nUXY0IrAuO9eIa3AWDoi4U59qKXG YVYuddElDwtReumED9+mygi8liKba/KtHid0GmDjXMQF82W5gnP1RWBVKcGPjT8YaOQfhoX6M MVLAjaWEw8qLrYWjd3BxmMDdlB9h2wFu32sjKLJi+OeCX09E48aQk17OXF1p9IZkM0RkzxNPO 97kgv69lGGvdfIHfDhNl/iEsyj514BQZHPmnwJHVOn7amHh+3K37RLVxlXeB786r0E0IFw1Gc PtJnUh9MrM90oZ5BZyEMrmwo6SUZCN7GNsT8ewhyD/lBBqHZYS8TurD0btCD65OBPUcyKMp0Z y/tvNKGiNsTe/HnSQ1wKvpVyS4PH/umJOhog+UcwNV57smKkQ+jAf7W3bnxFVQr1ywL0qCJno 55xDxErFdvMnKnwFgJWEKeyRT/AiUHIEPWxTWWTT8EVfGeTwNbhzZpaU7jwaN42LjJqfVwAzm x07Ba3EFLUKUTEzG0E1Q== Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:51:33 -0000 Reading the referenced MPTCP documents and surveys, "we" already have... Am 08.02.2021 um 23:42 schrieb Joe Touch: > That sounds like a very serious bug. It would be important to get it fix= ed before we all waste time trying to adapt to it. > > Joe > >> On Feb 8, 2021, at 2:16 PM, Matthew Luckie wrote: >> >> =EF=BB=BFHi Richard, >> >>> On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote= : >>> Hi Yoshi, >>> >>> Sorry to nitpick - in your draft, you mention that some hosts reflect >>> back unknown tcp options, which is why you are using different GID >>> mappings between SYN and SYN,ACK. >>> >>> I did read about this behavior concerning TCP header flags / reserved >>> bits - but have not come across a paper where this behavior is describ= ed >>> for unknown TCP options (or I may have missed that aspect in the vario= us >>> studies around TCP option investigations done by MPTCP and other group= s). >> >> There is some discussion of systems that seem to reflect TCP options he= re: >> >> http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_mu= ltipath_tcp.html >> >> Matthew_______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Feb 8 23:16:38 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DF33A1209 for ; Mon, 8 Feb 2021 23:16:28 -0800 (PST) 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 K8cBCJ21w-_K for ; Mon, 8 Feb 2021 23:16:27 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 0BD783A11E8 for ; Mon, 8 Feb 2021 23:16:26 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id r77so17051057qka.12 for ; Mon, 08 Feb 2021 23:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J6Wuc0Kptd0c7ig+gdXnJPRS3BtpvUmD43INXsvjC6c=; b=gfK1rwNVJjva2Jms+iHJXamwqIo7MIJWJCOw0EbsH5mYhKAz6v3Gn2HWhNf/AzSrw4 i8zHRTSni0WvgVF0n5SiGw3TI9Ohq0quBduB7FHfYV63gSO7GCc+DLag30V1rQWXdak3 hzqbcKBd5ZxAy5CM2mDku+d3NEEV4zKrY6STrdf+D0QBNw2s0gLshK8FU19pFqRESdGI qiFiOS5yHWqy7DWLjzEgB0C/lZcSbO52T/OMmohSOmF018EDgp28c0UZXIkBiX2iw1O2 fh6HKi1p2OfBiKwWHJYr+WML2yQzX2cFquZcDkufy6eoJ3eKpyEDBxkWDkIriq5jgMQd DVbQ== 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=J6Wuc0Kptd0c7ig+gdXnJPRS3BtpvUmD43INXsvjC6c=; b=Zg1hDx5dT0pC/JX0OmIZ79byosbCR2D/JEj6a3UrMMSDDSrIC/CSyCJ0d7CBrTkFSK KEgZ09JGR2Isz4dqYBSuEJeX3gAH8OUYZxLAPUvb3v3DB4gU/OlDq0vkwhtkv4XwfgAk AfUqfAPfiJ6Wbs0fnmJ6AGCXm/qeN6PTTzABa76+eg4ILvNJ9eSMD3WI6bWBVBduUEZV 6iiac7LNn/V2IvE/eakfpyeGLAtiRxmedQos9hjw7CBVoRwlVbiko+3twg++46kMvRah 1b99jL9ZwKHt8vquCdLU29dndQHJvGpG1nU6sRBnht+4bKDecj/7zc4rbeRYRQv1DEx5 PD5w== X-Gm-Message-State: AOAM5338NqJTJW2XA3lInpqU8XGOJyVpOJbg62RVMdP85oxQwOxTdq0Y h9SZXLQjAfNNrCX3GElv0plfnjKSd7KPKIBQB3A= X-Google-Smtp-Source: ABdhPJxLKymtUv6Evaiv1/IxqB3L7CGahlNLeianewQ7ozmyvi89Nhoj7q4thA6CN9bFwk9fPoNQRLQBBW6ZwqHv6do= X-Received: by 2002:a05:620a:745:: with SMTP id i5mr21020510qki.321.1612854986043; Mon, 08 Feb 2021 23:16:26 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> In-Reply-To: From: Yoshifumi Nishida Date: Mon, 8 Feb 2021 23:16:14 -0800 Message-ID: To: "Scheffenegger, Richard" Cc: Matthew Luckie , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000084736005bae21080" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 07:16:36 -0000 --00000000000084736005bae21080 Content-Type: text/plain; charset="UTF-8" Hi Richard, On Mon, Feb 8, 2021 at 2:49 PM Scheffenegger, Richard wrote: > Thanks! > > Still, without additional constraints my simplistic reading of how the > GID value mapping to groups doesn't seem to address such collisions > entirely.. > > Also, some options are not necessarily negotiated, but only indicated - > thus a constraint that corresponding bits of the group may only be set > in a , when they where present in the is not sufficient. > > One constraint I could come up with would be to require the server to > reflect back "empty" (all zero option flags) blocks received from the > client, in case a bitstream collision would otherwise happen > > > e.g. client wants to signal option flag 7 of group 2, while server wants > to send back option flag 7 of group 1 (but not flag 7 of group 2), the > current draft would allow a "valid" exchange that looks like a reflection. > > With the above, additional constraint, the server would have to return > an all-zero block for group 2 also, and may NOT skip over that... > I see your points. Thanks for pointing out an interesting case. In such case, I might want to use the extension block (GID=3 in SYN, GID=0 in SYN/ACK) defined in the draft. If server wants to send group IDs that didn't exist in the agg option in SYN, it needs to attach an extension block as well. So, in your case, sender sends back GID=1 with flag 7 and GID=3 with a certain bit on (TBD). I think this can be used as a proof that this is not a reflection. Thanks, -- Yoshi --00000000000084736005bae21080 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Mon, Feb 8, 2021 at 2:49 PM = Scheffenegger, Richard <rs.ietf@gmx.at= > wrote:
= Thanks!

Still, without additional constraints my simplistic reading of how the
GID value mapping to groups doesn't seem to address such collisions
entirely..

Also, some options are not necessarily negotiated, but only indicated -
thus a constraint that corresponding bits of the group may only be set
in a <SYN,ACK>, when they where present in the <SYN> is not suf= ficient.

One constraint I could come up with would be to require=C2=A0 the server to=
reflect back "empty" (all zero option flags) blocks received from= the
client, in case a bitstream collision would otherwise happen


e.g. client wants to signal option flag 7 of group 2, while server wants to send back option flag 7 of group 1 (but not flag 7 of group 2), the
current draft would allow a "valid" exchange that looks like a re= flection.

With the above, additional constraint, the server would have to return
an all-zero block for group 2 also, and may NOT skip over that...

I see your points. Thanks for pointing out an in= teresting case.

In such case, I might want to use = the extension block (GID=3D3 in SYN, GID=3D0 in SYN/ACK) defined in the dra= ft.
If server wants to send group IDs that didn't exist in th= e agg option in SYN, it needs to attach an extension block as well.

So, in your case, sender sends back GID=3D1 with flag 7 a= nd GID=3D3 with a certain bit on (TBD).=C2=A0
I think this can be= used as a proof that this is not a reflection.

Th= anks,
--
Yoshi

--00000000000084736005bae21080-- From nobody Tue Feb 9 00:36:07 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B316F3A12AE for ; Tue, 9 Feb 2021 00:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJzkpx6FDUXk for ; Tue, 9 Feb 2021 00:36:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 617FC3A12AC for ; Tue, 9 Feb 2021 00:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612859758; bh=LOVCIodFafoUdROve69GkZQaiZr/UfIyyHeQcSMP2wA=; h=X-UI-Sender-Class:From:Subject:To:References:Date:In-Reply-To; b=bxWZiLFHaaQS7G4Tayt5kLbL8r8umPeDXN0Lks8qZAa7AocEdPrisXQ3og3u8/9HZ iFmj6HlF6OTMBPctz2dQWT3GGmUrrfSjIbZht9vUW+5m22plGv8YWY7UEnlIxqq80r adwyur9Bvt+FNIP7G/xBYjGHecAQdidjWs2Cq5n0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.138]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M2wL0-1lCgoj2lUS-003OgR; Tue, 09 Feb 2021 09:35:58 +0100 From: "Scheffenegger, Richard" To: Yoshifumi Nishida , tcpm IETF list References: Message-ID: <53b0114f-054f-3814-eb04-d55f360bd52d@gmx.at> Date: Tue, 9 Feb 2021 09:35:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Ed3Q0Ne7azC/s7mLHmp/gr8wXji9KorpU23N//anDYemjnq4Smr ctybndC7bVJSx4c/qRUIHqLMsxKq7tWZKfOUycHeaEhWpl7tg0qEZQ9r6WGWr28LkDkmN32 tmD6Auh2uA+WNcCFkyavFQ+Lqc4PNPwSt4w7sKFF9C0LKACexVEYH0chlR6o+mnD/5IBHDn ailV1HueEDMxdIgqnqUHQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:MRcdDLhNbOM=:OK9w6O/X2gBAbOdJemIuSh A/pdL7f/jpgJ6eFoRP9gcuHSuhbwSSvADaV+h5mTZbY2OJOlpMH8cHfv0wSRIdeRXbBfkha31 W1zyY0ZFLUndbqM6uZEbGUeXJDqkUxJbpJ16LcAb2dEXxN4Rt7kB5gIQhiV2GO3OLUItnROmN velt9QbOcZNw9Cy/TfvAVUh/QLBglrzBBfGoI4GVcmrIHtEh52cAFicVL8RJAnhR0Pm7P3VLa r7ytF7jjx26vMLEnnh/xj0qpfeDKpQjfc/hWEmu6UjwOYEdt3WR8BDoqnYu3u0IocUvImhd8n DiKgHFQJDAM5UngZvHDz/pgQl5czuzJMQQxmcSqKifTBgvqjgSv+gd4roJrk06o6sFgKWwIqI mAS4uxVSYRX5tE32WbSS6g3Jdw0WFnhHAJOiM0yRjqZrP1KhccHdEbhKxS8tBF+X+6Al6HBXc ta9SxufC4uh1OnVVjYQucRb4PDkJIEuDLFvHZOjYod4mSJd08Aqr4B6M4i3w2cjzeqnb1A+HD ZNPyskQRZSldl1+lAT8RuONq8bgszp7PFdJcwAu/FKdMAKHRcaQ7rgEyzlqAFDq8+LeehhGZu dP4aer211ZG0VomQ5xDcueg4QDc0xqFelFsXicqZ0spvo+u9tCghR/zFh/kGSlcb1c3dDH/vl TO1EsXUWpfa75iKB9+ZymONpHvdlxe2E81bLH2kd3WEzxHJJvRmNGSQioH3XuANFAx5jiI8br 3z6LkIDvBKNuKqw3ywgUyoSeVC8TXsHtBiTULgZB/0WvN/asjaEnZgnArfBv+Ri7bAgVb5J/s Dhnla7zfgrxIYMfvzRiC5IPb0FzFyBBytp6sPEDuXua5of77LhGfWx/vNRo26viAij/phCLBY 4ipqbeeZCr5umgLX+xjQ== Archived-At: Subject: Re: [tcpm] Request for feedback on WG Adoption of RFC6937bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 08:36:06 -0000 FWIW, PRR has been included in FBSD13 as default. That implementation my be a bit rough at the edges - the particular case to deal with "broken" token-bucket traffic policers mentioned by Matt using an automatic heustric is not in, and if encountered, need to be dealt with manually. Richard Am 30.11.2020 um 19:12 schrieb Yoshifumi Nishida: > Hi folks, > > This mail starts a WG adoption call for RFC6937bis draft. > As we've already seen positive supports for this work, we are not asking > people who already expressed their opinions this time. (but, if you want > to do it for some reason, please go ahead) > However, if you haven't done it yet, especially if you're against it, we > would like to encourage you to provide feedback. > > We are thinking that the intended status of the doc will be PS based on > the feedback we've seen so far. But, if you have opinions on it, please > let us know. > > Thank you so much, > -- > Yoshi on behalf of tcpm co-chairs > > > On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis > > wrote: > > The authors of PRR would like to update PRR to Proposed Standard > status.=C2=A0 This entails introducing a new document as an tcpm wor= k item. > > *Please indicate (non) support and/or comment.* > > For more details see the tcpm meeting materials from IETF 109 > minutes: > https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-= 00 > > slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 > > > There were about four "I support this work" remarks at the mic (not > recorded in the minutes), and about as many in the Meetecho chat. > > Abridged IETF/tcpm/PRRbis slides: > -- > PRR =C2=A0recap (RFC6937 experimental) > PRR is a special congestion control effective only during fast recov= ery > > * When inflight >=3D ssthresh, send at loss_beta*rate_before_loss > (e.g. loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cub= ic) > * When inflight < ssthresh, send at the same or twice the > delivery_rate (more later) > * Used by all congestion control modules in Linux during fast reco= very > o Can be more dominant than the actual C.C. for lossy flows > that=E2=80=99re in fast recovery constantly (e.g. video stre= aming > through policers) > > -- > Current Status > > * > > PRR is widely deployed > > o > > At least three major OSs: Linux, Windows, (NetFlix) BSD > > o > > Vast majority of Web traffic for years > > * > > No changes to algorithms published in RFC 6937 > > o > > PRR-CRB - Conservative Reduction Bound - strict packet > conversion during loss recovery > > o > > PRR-SSRB - Slowstart Reduction Bound - one extra segment per > ACK during loss recovery > > * > > 2015 Heuristic to dynamically select which reduction bound > > o > > Only use PRR-SSRB when making good forward progress > > + > > ACKs that advanced snd.una and report no new losses > > o > > Resolves some pathological cases with token bucket policers > > + > > CC estimates ssthresh before it can possibly measure the > token rate > > + > > The heuristic makes the best of a bad situation > > -- > Tentative path forward > > * > > Adopt as a tcpm work item > > * > > Update the text > > o > > Normative RFC 2119 language > > o > > Add MAY use the heuristic... > > o > > Trim redundant and obsolete language > > + > > RFC 6937 repeats itself and is much longer than necessar= y > > + > > Focus on what an implementer needs to know > > + > > Use non-normative references to RFC 6937 for prior > measurement work, etc > > Thanks, > --MM-- > The best way to predict 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 m= easured: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypoc= ritical and risks spiraling > out of control; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mist= aken for tacit approval. > _______________________________________________ > 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 Feb 9 00:52:53 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DE3A12D1 for ; Tue, 9 Feb 2021 00:52:51 -0800 (PST) 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 5n7DhG4YXTXR for ; Tue, 9 Feb 2021 00:52:50 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 E822D3A12D8 for ; Tue, 9 Feb 2021 00:52:49 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id p12so3414036qvv.5 for ; Tue, 09 Feb 2021 00:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Dchyc7YcEbWbCXoP2rR96LKGVQ3jBryFFCu2pTbrnps=; b=ajXW2Tpg9O9ZjE83t/ZrOE91RozSBI7vakW/458vVSk/lJ0MK41vY6bWONE5Vvoleo 7t1OCPGAxelPMiFEspa9OveOiFOiVGb9u6Esm8dPhEbBcFUnLihGO7tUXa3nXLZuh0Bb P0wO5P0kfVXZplVcGoVrTocN7oO5KiiUdbVM0v5Y3Y9c1CWsZEkunuCSInos7J4MwOW4 CstoTfWpaYj2Dk6XcLq7Vm24DsQR1OBxh0P6r2hjUyitpu/YhUE76TFUeG2vna8DO5ym vJIhpDAHKbtSsrTGK43nvTOpo9hmS2BMBIEDxjpOP0NBKZSSn+/VZbMnue8C8PS8Hr0K bt5w== 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=Dchyc7YcEbWbCXoP2rR96LKGVQ3jBryFFCu2pTbrnps=; b=q7zOmHDcZeVWyeJ9TZy05a/gR9NlmagVMcfEuZgI6qgRE/hor21B400TTU6nPmD0J+ k58MJH7I5mdGCfLAY10cyEkB7tcAAhMfWTHNyNR7Hf4cztWRlcT7d5a0HkVSsK75z/hC 6ELIOR7NSWXr+qV0XcFWU6aPMEFvXYoOI0jVQGb4mE4VUPqKtD9Ad9TKQaWxWiDglZqz ncf1/hiA/Vs0gCtWva9+/Nhc47mPnnPsGpHDtUxHoMspNOs4stQNdKHtriusHZccMqjF 8/eT0V8oqPB12BggLLz/oB95XIfKXg51bHCy27ZCbl+io5sQwKgPtQd0nSh9B5i0JJdw yTpQ== X-Gm-Message-State: AOAM530/tv3SUYJRoUTnRfMQdHJtGAc07H/hULKJg6iCO0E+8AB4XKEs kcjmBn8M2vjNDMExuEnx2g+V3+KgXiveHinj6KFnf0bd4tE= X-Google-Smtp-Source: ABdhPJznOZzCLKBlrH126wwMcvR0Qi3ScDiLbyU8Xn1F1aGsGrzzHpfiLhvCkXlJuG95HUBmgaM0N/vzDTLKpaieCTo= X-Received: by 2002:a05:6214:592:: with SMTP id bx18mr19928660qvb.32.1612860768573; Tue, 09 Feb 2021 00:52:48 -0800 (PST) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Tue, 9 Feb 2021 00:52:37 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000002edb5505bae369c2" Archived-At: Subject: [tcpm] Agenda requests for TCPM@IETF110 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 08:52:52 -0000 --0000000000002edb5505bae369c2 Content-Type: text/plain; charset="UTF-8" Hello, As it's shown in the current agenda ( https://datatracker.ietf.org/meeting/110/agenda.html) we are planning to have a WG meeting on March 12 (Fri) 12:00 - 14:00 UTC. If you are planning to present something, please let the chairs know the following information by Feb 21. * Title and draft name * Presenter's name * Total time (including Q/A) BTW, please note that the current schedule is still preliminary and might be changed. Thanks, -- tcpm co-chairs --0000000000002edb5505bae369c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

As it's shown in the current=C2=A0agenda=C2=A0(https://d= atatracker.ietf.org/meeting/110/agenda.html) we are planning to have a = WG meeting on March 12 (Fri) 12:00 - 14:00 UTC.
If you are planning to p= resent something, please let the chairs know the following information by F= eb 21.

* Title and draft name
* Presenter's name
* Total t= ime (including Q/A)

BTW, please note that the current schedule is st= ill preliminary and might be changed.=C2=A0

Thanks,
= --
tcpm co-chairs
--0000000000002edb5505bae369c2-- From nobody Tue Feb 9 02:13:40 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5943A1490 for ; Tue, 9 Feb 2021 02:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0asL-2rAmFPh for ; Tue, 9 Feb 2021 02:13:37 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55623A148C for ; Tue, 9 Feb 2021 02:13:37 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 119A966x034589; Tue, 9 Feb 2021 02:13:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2eujsRmebsWgUWtnKqC0D5LBCfwxLj6cjTXMCw+ykxo=; b=njK4UwBYfuvaEsDxFggy0NjG05G96lH2beCjxRzGC6IOpKP9JSuU+09eVOn4CYPUv4wG 351FdbHDM0IyKnu3T/1gvBy3EmKcEWSjASgIkEAK88Ehs7w6jktKAKhg+gA7Y8ceQMjV YlX8zxA9hb6cJuipfaRcm6hssf37PJn862ALti7A8tfINZmXHKBCdGqEvz3RQ/xZTG3L aEdFVXEPiGZ5KA3OmM2yivvuEdWdGDms429GhDp5iZA80+HluU+CtphWt59LvQq2p0Pw DwGoXzIDBQrCzg7lco3PNWVgGzywJwU/MlMb64ohMLSO+MWA16I/6LOp0lZJlw14shl6 +w== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 36hrnwgv5m-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 09 Feb 2021 02:13:36 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QO900JVWB2NKPE0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 09 Feb 2021 02:13:35 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QO900U00AIRVB00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 09 Feb 2021 02:13:35 -0800 (PST) X-Va-A: X-Va-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f X-Va-E-CD: ffc18a3e6cb77d96a0903836e7676d16 X-Va-R-CD: 72837468f2787ec3737ccef554998b67 X-Va-CD: 0 X-Va-ID: d8714b0f-d612-47bd-b788-407e6064e8d1 X-V-A: X-V-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f X-V-E-CD: ffc18a3e6cb77d96a0903836e7676d16 X-V-R-CD: 72837468f2787ec3737ccef554998b67 X-V-CD: 0 X-V-ID: 51f80a65-fb86-456b-80f5-8b9487bea50a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-09_03:2021-02-09, 2021-02-09 signatures=0 Received: from [17.11.132.204] (unknown [17.11.132.204]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QO900ZZKB2MLK00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 09 Feb 2021 02:13:35 -0800 (PST) From: Vidhi Goel Message-id: <2F8FD4F6-2DEC-4780-8A6F-57A5879D90B0@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_570CCF58-6B00-4B3B-8925-86235E57DCBB" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 09 Feb 2021 02:13:34 -0800 In-reply-to: Cc: "tcpm@ietf.org Extensions" To: Yoshifumi Nishida References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-09_03:2021-02-09, 2021-02-09 signatures=0 Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM@IETF110 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 10:13:39 -0000 --Apple-Mail=_570CCF58-6B00-4B3B-8925-86235E57DCBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello TCPM chairs, We would like to present the updates to CUBIC RFC 8312 which includes = all the algorithmic changes based on current industry best practices. > * Title and draft name Updates to CUBIC RFC 8312 - draft-eggert-tcpm-rfc8312bis-01 > * Presenter's name Vidhi Goel > * Total time (including Q/A) 15 mins Thanks, Vidhi > On Feb 9, 2021, at 12:52 AM, Yoshifumi Nishida = wrote: >=20 > Hello, >=20 > As it's shown in the current agenda = (https://datatracker.ietf.org/meeting/110/agenda.html = ) we are planning = to have a WG meeting on March 12 (Fri) 12:00 - 14:00 UTC. > If you are planning to present something, please let the chairs know = the following information by Feb 21. >=20 > * Title and draft name > * Presenter's name > * Total time (including Q/A) >=20 > BTW, please note that the current schedule is still preliminary and = might be changed.=20 >=20 > Thanks, > -- > tcpm co-chairs > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_570CCF58-6B00-4B3B-8925-86235E57DCBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello= TCPM chairs,

We = would like to present the updates to CUBIC RFC 8312 which includes all = the algorithmic changes based on current industry best = practices.
* Title and draft = name
Updates to CUBIC RFC 8312 - = draft-eggert-tcpm-rfc8312bis-01

* Presenter's name
Vidhi Goel

* Total time (including = Q/A)
15 mins


Thanks,
Vidhi

On Feb = 9, 2021, at 12:52 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> = wrote:

Hello,

As it's shown = in the current agenda (https://datatracker.ietf.org/meeting/110/agenda.html) we = are planning to have a WG meeting on March 12 (Fri) 12:00 - 14:00 = UTC.
If you are planning to present something, please let = the chairs know the following information by Feb 21.

* Title and draft name
* Presenter's name
* Total time (including Q/A)

BTW, = please note that the current schedule is still preliminary and might be = changed. 

Thanks,
--
tcpm = co-chairs
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_570CCF58-6B00-4B3B-8925-86235E57DCBB-- From nobody Tue Feb 9 07:49:00 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4728A3A0E7F; Tue, 9 Feb 2021 07:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzf6u5t6L8Sb; Tue, 9 Feb 2021 07:48:56 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 1A7373A0E4B; Tue, 9 Feb 2021 07:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SX4YueNZikv3e41Z3J1Ix2CsbEmSBLHyzqqm29MlFsI=; b=79UHRn/87IBOy79TzkSj1ItlF T0UjvqsLIQIZoFnXmCLg/DFV1zPV55FNF+dfz39oH+6pgfrZHQ/FvET6ZSl/mUmNbt8zltd6lWJPP PZD8HoaiQBGEZ7ZzM+C+2kZoXm1VzAfAAtpsUesoyvVekSNgMHESN+f2oA54NSy2YP6tsQVuZh3gj T4dtfCYRtVq8hBEm9ZeWW2+5SkrGW00xJqmzvjG4QOtOUaP8c0P7oX77kHNfbF2nSEBIIuLAfCSMT s9rtQQ/WnxY15T1a8HhRjhGkUUFMUrDF0A6S18spQ6PxbRCynZ5mRbHGnnj2suvNkR5MljYOo/Kqb J+3pb6Bfw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:47862 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l9VG2-0006Yp-1u; Tue, 09 Feb 2021 15:48:54 +0000 To: "Scheffenegger, Richard" References: From: Bob Briscoe Cc: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org Message-ID: <391747b3-b513-1063-ba6a-5011d5ef0b0c@bobbriscoe.net> Date: Tue, 9 Feb 2021 15:48:52 +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: Content-Type: multipart/alternative; boundary="------------36BD4DBD4350BADC1EFAF0CF" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] ECN++ control packet handling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 15:48:58 -0000 This is a multi-part message in MIME format. --------------36BD4DBD4350BADC1EFAF0CF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Richard, Good point. Thanks for noticing this potential implementation pit-fall. In my local copy of the ECN++ draft I have added the following to the end of "3.2.6 RST (Send)": + Implementers SHOULD ensure that RST packets (and control packets + generally) are always sent out with the same ECN field regardless of + the TCP state machine. Otherwise the ECN field could reveal internal + TCP state. For instance, the ECN field on a RST ought not to reveal + any distinction between a non-listening port, a recently in-use + port, and a closed session port. And I've added this to the end of Security Considerations: + Section 3.2.6 on sending TCP RSTs points out + that implementers need to take care to ensure that the ECN field on a + RST does not depend on TCP's state machine. Otherwise the internal + information revealed could be of use to potential attackers. This point + applies more generally to all control packets, not just RSTs. Do you think that's correct / sufficient? Cheers Bob On 08/02/2021 21:03, Scheffenegger, Richard wrote: > Hi Bob, Marcelo, > > While working on the ecn++ code for fbsd patch, I found that the > codepath for dealing with out-of-window, past-established and > non-listening ports is actually quite different there. > > Casually glancing over the draft for ecn++, I didn’t find a reference > specifically about the handling of RST (non-listening port, vs. closing > session etc). > > This may need a hint in the security section, that an implementation > should ensure, that control packets are always sent out with similar > headers, regardless of the TCP state machine. Otherwise, you could > potentially leak information (eg. Recently in-use ports) which may be a > clue to malicious players… > > > Richard Scheffenegger > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------36BD4DBD4350BADC1EFAF0CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Richard,

Good point. Thanks for noticing this potential implementation pit-fall.

In my local copy of the ECN++ draft I have added the following to the end of "3.2.6 RST (Send)":

+ Implementers SHOULD ensure that RST packets (and control packets

+ generally) are always sent out with the same ECN field regardless of

+ the TCP state machine. Otherwise the ECN field could reveal internal

+ TCP state. For instance, the ECN field on a RST ought not to reveal

+ any distinction between a non-listening port, a recently in-use

+ port, and a closed session port.

And I've added this to the end of Security Considerations:

+ Section 3.2.6 on sending TCP RSTs points out

+ that implementers need to take care to ensure that the ECN field on a

+ RST does not depend on TCP's state machine. Otherwise the internal

+ information revealed could be of use to potential attackers. This point

+ applies more generally to all control packets, not just RSTs.

Do you think that's correct / sufficient?

Cheers

Bob

On 08/02/2021 21:03, Scheffenegger, Richard wrote:
Hi Bob, Marcelo,

While working on the ecn++ code for fbsd patch, I found that the
codepath for dealing with out-of-window, past-established and
non-listening ports is actually quite different there.

Casually glancing over the draft for ecn++, I didn’t find a reference
specifically about the handling of RST (non-listening port, vs. closing
session etc).

This may need a hint in the security section, that an implementation
should ensure, that control packets are always sent out with similar
headers, regardless of the TCP state machine. Otherwise, you could
potentially leak information (eg. Recently in-use ports) which may be a
clue to malicious players…


Richard Scheffenegger

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------36BD4DBD4350BADC1EFAF0CF-- From nobody Tue Feb 9 08:58:10 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E31A3A0E02 for ; Tue, 9 Feb 2021 08:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 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.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id effMUEDaUtEi for ; Tue, 9 Feb 2021 08:58:06 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 E986D3A0C30 for ; Tue, 9 Feb 2021 08:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aqKomORfDxEF1sfrnCSYi6K0dzLXgYMM2BYz8eOZEac=; b=p6PolUSfKGuREeyJE8Av4wkznA Vz6RmZRgxX4ZCsmGH9wNrVHXz/2N2EYTV4P0LGRcfRSaPPe2+lqz287HEA0jy9jkEUWyb6ZGRHCKx VN5hbsMFR/T5IJiXAREnCg7VWyxwQ2EyQDFIcVTG/YzjO3+IMuqCCQ/IEOkVxW5Sgfqnw7OodvyxJ 2ikS6B13oe+2JF9p8GClXulAvhLGnlvC51QN1LATMPpTUdwBIH7haMdIx0NN0DYPbRbUuRoE4nRtW vSmR/UiJFlTG2UXgoHUFfJcph5cyEig/WBeuJ+csdEEMSANYTC9EU+Qak5SQAJ0DwmEksDDk/d4Y3 3Rx5Z+Fg==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:48182 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l9WKx-0001UM-DD; Tue, 09 Feb 2021 16:58:03 +0000 To: "Scheffenegger, Richard" , Mirja Kuehlewind , "Scharf, Michael" Cc: tcpm IETF list References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> From: Bob Briscoe Message-ID: <381499f5-3333-08c5-2ffd-fba77e027795@bobbriscoe.net> Date: Tue, 9 Feb 2021 16:58:02 +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: 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 - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 16:58:10 -0000 Richard, I just noticed I missed the last para of the old email from you below. Response inline, tagged [BB]... On 23/11/2020 12:42, Scheffenegger, Richard wrote: > I am also in favor of using two distinct option codes. > > However, > >> Or I guess we could say that only one option should be used for a connection. > I am opposed to this - with two option codes, a sender should be free to choose whichever he prevers at any one point; For example, if the sender a segment (e.g. may be the receiver side) has to update the EE1 couter, but also convey SACK information, it would be good to use the one, where the EE1 field is first, and omit all remaining fields; > > Later in the same connection, that very same host may choose to update the CE field together with some SACK information, and use the other codepoint in order to preserve as much TCP option space for the SACK option... [BB] I agree with you here (and disagree with Mirja below). The nice thing about 2 options kinds is they are self-describing, so they can be stateless (for instance, consider the code you would have to otherwise add for when a host switches to a different congestion control module - a lot of complexity despite being unlikely to happen). > > > As for extensibility: I would want to avoid that topic, and just specifiy the three correct supported lengths here, and not mention (other than ignoring "odd" fractionals of the 3-byte wide counters) what happens with other lengths... [BB] A protocol spec should surely say what to do with unexpected inputs. Not specifying this is one of the main reasons we have such trouble changing things later - because we discover some implementers handled the unexpected in different ways to others (e.g. ignore, vs RST the connection), and others only handled expected inputs and didn't even think to check for anything else. So, I believe we have to either say "reset the connection" or "ignore", in response to an unexpected option length. I figure that, if there's no harm in ignoring something unexpected, then why not ("liberal in what you receive" principle). Earlier in this thread, Michael Scharf pointed out that there is some potential harm here (covert channel of up to 29B), but I pointed out that TCP/IP has plenty of other ways of creating covert channels, so we're not really adding to any problem here. But I did say that we would highlight the covert channel in the Security Considerations section, so the Sec Area has a chance to object. If it raises as serious concern, then we should switch from "ignore" to "reset", But I doubt it will. Cheers Bob > > > Richard Scheffenegger > > -----Ursprüngliche Nachricht----- > Von: Mirja Kuehlewind > Gesendet: Montag, 23. November 2020 12:39 > An: Neal Cardwell ; Scharf, Michael ; Bob Briscoe > Cc: Yoshifumi Nishida ; tcpm IETF list ; Scheffenegger, Richard ; Michael Tuexen ; tcpm-chairs@ietf.org > Betreff: Re: [tcpm] AccECN field order > > NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > Hi all, > > I think I also support two options as this is the most simple solution. > > We probably need to look at section 3.2.3.2. (Path Traversal of the AccECN Option) again, as I think this section assumes mostly one option. Or I guess we could say that only one option should be used for a connection. > > Regarding use of the option length for extensibility. I know new options are hard to deploy but that’s the extensibility mechanism we have with TCP. Not sure we want to invent a new now. If we think we need more extensibility for AccECN for any reason, we should specify valid option length values that include a flags field now. > > Mirja > > > >> On 18. Nov 2020, at 01:03, Neal Cardwell wrote: >> >> As someone who contributes to a TCP implementation, I would put in a vote for the "Two Option Kinds" proposal outlined in slide 6 here: >> >> >> https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor >> e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica >> tion-01#page=6 >> >> This approach has the virtue of simplicity, which hopefully may help avoid middlebox bugs, speed standardization and development, and ease the process of maintaining fast and stable implementations. >> >> neal >> >> >> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael wrote: >> Inline some comments [ms]. >> >> >> >> Given that I don’t ask for any text chances, I’ll not follow-up forever in this discussion. I don’t own running code and a lot of encoding details mainly affect an implementation. >> >> >> >> IMHO the rest of the WG has to think about the option design more than >> me. So, this is mostly about triggering a discussion… >> >> >> >> From: Bob Briscoe >> Sent: Tuesday, November 17, 2020 1:20 PM >> To: Scharf, Michael ; Yoshifumi >> Nishida >> Cc: Michael Tuexen ; tcpm-chairs@ietf.org; >> Mirja Kuehlewind ; Scheffenegger, Richard >> ; tcpm IETF list >> Subject: Re: AccECN field order >> >> >> >> Michael, >> >> On 17/11/2020 08:10, Scharf, Michael wrote: >> >> Bob, >> >> >> >> I am fine with the two option kinds proposed in -13, but I don’t buy your arguments why this encoding is better than others. >> >> >> >> Most importantly, I don’t think that your “forward compatibility” argument is a very compelling reason for two codepoints. All proposals I am aware of have their pros and cons. And I am not aware of a really comprehensive discussion. At least neither the e-mail below nor today’s meeting discuss all tradeoffs I would investigate. >> >> >> [BB] You're right - the discussion below is useful and necessary. >> >> >> >> >> >> For instance, the benefit of the length encoding variant would be to consume only one TCP option codepoint now. If we decided later to that a flag byte is needed (say, at the end), a follow-up proposed standard could specify another option format with that flag byte, using a second codepoint. >> >> >> [BB] >> * The new codepoint would require years to deploy (including in proxies) before it works e2e. >> >> >> >> [ms] That may depend *a lot* on the environment. In environments where ECN can get deployed today, say in datacenters, rolling out a new kernel version may perhaps not be the biggest operational challenge. Also, proxies may not be a significant problem in some of those cases. Deployment roadmaps are very hard to predict. >> >> >> * Whereas the 'forward compatibility' approach tries to ensure that AccECN implementations that are being built today will be ready to interwork with a future extension. >> * In contrast, if your hypothetical new AccECN codepoint did need to be deployed later, it would need to include a fall-back to the current AccECN option when one peer doesn't understand the new codepoint. >> >> >> >> [ms] This is a reasonable point, albeit not a particularly strong one, >> given that the option is not really required for basic >> interoperability. Also, a hypothetical follow-up standard could >> include a way to explicitly request the option… >> >> >> * Fall-back would need to avoid a second round of handshake (given >> this is for low latency), which would only work reliably with an >> option on the SYN (because the 3rd ACK is unreliable) >> >> >> >> [ms] I can’t follow. If an endpoint is unhappy with getting AccECN option “A” from a peer, I could send a “please send me the better AccECN option B” after the 3-WHS. It could be an upgrade, not a fallback. Also, at this point we don’t know what option B would be and in which context it would be needed. Maybe other protocol features would require negotiation, too. IMHO it is a solvable problem. >> >> >> * AccECN has so far avoided using any SYN option space, which is important given that is the scarcest resource. >> >> >> >> [ms] Yep, but as long as no proposal needs SYN options, this is nothing that would make one solution better than another. >> >> These days, extending TCP is like playing chess - we have to think multiple moves ahead! >> >> >> >> [ms] There is one fundamental difference between chess and TCP: In chess you precisely know the current situation and can predict all potential moves in advance (albeit there are a lot). However, we don’t know the future evolution of TCP, ECN and the Internet as a whole, nor future requirements. If we try to engineer a TCP extension for some potential future, we may figure out later that reality is different from what we designed for. As much as I appreciate your attempts to predict the future, it would be a big surprise to me if you could correctly predict what TCP will be in 10 years from now. So, instead of trying to write specifications that take into account future requirements, which are in fact just unknown, it is more important for me to write effective, efficient and secure specifications for what is currently known for sure. >> >> >> >> [ms] I *don’t* know for sure whether the current AccECN option will be needed, but I see quite some evidence that support of the AccECN option(s) is not a top priority these days. That is also something to think about when designing the details. >> >> >> >> I need to learn to articulate onto the list all my reasons for rejecting certain parts of the design space. Sorry about that. >> >> Yes, I admit, the current proposal is at the cost of burning two TCP option codepoints. However, you said yourself when you proposed this approach, that they are not (currently) a scarce resource. Certainly not as scarce as option space. I just checked: roughly 15% of the option codepoint allocation space has been used so far. So that's where I would suggest we compromise first. >> >> [ms] I made a similar calculation some years ago and came to a similar conclusion. Investing two codepoints for AccECN is something we can probably afford. But nonetheless we have to reason carefully why it is really worth the effort. >> >> >> >> >> Regarding the resulting codepoint consumption (two option kinds) and the addition of a flag byte, this approach would basically end up with the same result as the current proposal in -13 plus some hypothetical future addition leveraging the length field beyond the currently known use. >> >> >> >> And, yes, the length encoding variant may be less flexible and/or consume some more bits in some cases, but on the plus side it only needs one codepoint now – and given that it is entirely unclear whether any AccECN option will indeed be widely used in future, this is a big plus. The fact that implementers are quite silent on the option design is not a good sign. >> >> >> [BB] Here's another possibility then. >> >> a) [K|L| EE1B | ECEB | EE0B ] >> b) [K|L| EE1B | ECEB | EE0B |F] if F = 0bXXXXXXX0 >> c) [K|L| EE0B | ECEB | EE1B |F] if F = 0bXXXXXXX1 >> >> We'd have to decide which order alternative (a) takes. I've picked EE1B first only 'cos you're right that there is not currently as much pressure (on the public Internet) for AccECN with ECT(0). >> >> ==Legend== >> K: Kind (1B) >> L: Length (1B) >> ExxB: Echo xx byte counter >> F: Flags (1B) >> >> Alternatives a) and b) are equivalent, at least while the only allocated flag is for field order. >> However, alternative b) is available in case other flags are allocated >> in future The flags byte can only be omitted if (L % 3 == 2). >> The flags byte is considered present if (L % 3) == 0. >> >> Forward compatibility: Options with (L % 3 == 1) MUST be assumed to include a flags byte, and current implementations ignore the last byte. >> >> The flags byte is optional to implement (even if the AccECN option is >> implemented) If the server includes a flags byte on the SYN/ACK but the client does not include one on the 3rd ACK or the first data packet, the server assumes the client does not implement the flags byte and uses only alternative a) for the remainder of the connection. >> >> >> [ms] I am not sure if we need that, but I take this as existence proof that other encodings are possible. Personally, I think that other solutions would be doable if you took one bit from one or multiple counters for format encoding. At least for some of the byte counters I don’t think taking one bit for other purposes would result in an Internet congestion collapse… But, I have already said that the -13 proposal works for me, so I’ll not try to come up with another variant myself. >> >> >> >> To me, one potential difference between two proposals would be incremental deployment. The proposal in -13 only has an advantage if middleboxes such as firewalls will indeed pass TCP options with a format that contains content beyond the (first) Accurate ECN standard (i.e., currently unused length values). IMHO it is too early to know whether firewalls would indeed allow this in future. >> >> >> >> From a security perspective, it is not clear to me whether allowing arbitrary unspecified bytes in a TCP option is a good idea *at all*. It will be interesting to hear the opinion from SEC area on that. Personally, I am not convinced that this really makes sense, but I my concerns are not strong enough to formally push back. I’ll leave it to others to think about whether this is a bug or a feature. >> >> >> [BB] Well, let's first try to deal with security ourselves: >> * Octets that are explicitly declared as part of an option cannot be used for a buffer overflow attack. I don't really need to, but I could add the following text to the forward compatibility wording: >> A receiver considers octets beyond those it uses, but within the specified length, as if they are padding. >> * And such octets cannot be any different from the current ability of a sender to add padding. So there's no new attack possible here. >> * And there's no need to specify a max length for any AccECN Option, which would just unnecessarily limit flexibility. >> >> [ms] I have more thought about the covert channel that some unspecified bytes in a standards track TCP option could offer… In particular if the AccECN option gets widely deployed and used, would some malicious users find those bytes useful? For what? For instance, what in the AccECN protocol design prevents use of these “padding” bytes as super-cookie? To me, it is much more important to think about abuse of whatever we standardize *now*, instead of engineering for some entirely unknown future. I am not a security expert, but I suggest a careful analysis of any security implications of the AccECN option. We seldomly specify new TCP options and malicious users will certainly look for “opportunities” in the spec. So far, I don’t know whether that whole idea of forward compatibility is a feature or a bug. >> >> >> >> Michael >> >> >> >> Maybe one lesson learnt is that the document could have a non-normative appendix that explains the rationale for the finally picked TCP option encoding. That may also help if there are further questions whether two codepoints are really required, e.g. by the IESG (if two codepoints are still the design after WGLC). At least for past TCP option codepoint allocations I recall some discussions late in the IETF process. In those past cases, good arguments in an appendix and running code has helped a lot. >> >> >> [BB] I can do that. Appx B is already similar, giving Design Rationale for the ACE field. >> >> >> Bob >> >> >> >> >> >> Michael >> >> >> >> >> >> >> >> From: Bob Briscoe >> Sent: Tuesday, November 17, 2020 6:10 AM >> To: Scharf, Michael ; Yoshifumi >> Nishida >> Cc: Michael Tuexen ; tcpm-chairs@ietf.org; >> Mirja Kuehlewind ; Scheffenegger, Richard >> ; tcpm IETF list >> Subject: Re: AccECN field order >> >> >> >> Michael, >> >> On 16/11/2020 17:36, Scharf, Michael wrote: >> >> Bob, >> >> >> >> One proposal using the length field with *one option codepoint only* >> is detailed in: >> https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo >> / >> >> >> >> It is the third option mentioned in this e-mail. One example would be to use option length values 5/8/11 for one encoding type and option length values 6/9/12 for the other encoding type (i.e., order of fields). Or one could use some other combination of length values – the only requirement is that a certain value for the option length is only used by one of the option formats. In that approach, the value of the length field would thus directly describe the encoding of the option. Unless I miss something, this would work and it would just require one option codepoint. >> >> >> >> Thus, alternatives to two option codepoints exist and I have explained them on the list in March 2020. >> >> >> OK, sorry, yes, I remember this now. >> >> As I will explain in the AccECN status update talk today in virtual Bangkok, the draft has made provision for different length values than 5/8/11. It says existing implementations MUST accept length values other than those currently defined. But then read in as many whole 3-byte fields as they can. >> >> This can be used to add a flags byte on the end in future, for extensibility. Or any other form of extensibility the WG might decide in the future. >> >> I know a flags byte at the end seems odd compared to at the beginning. But (if decided it's needed in future) it's reasonably easy to implement by reading the whole option, then processing the last byte, before reading the rest of the option. >> >> I believe you will agree that this is a better way to utilize different lengths. >> >> And thank you for repeatedly emphasizing that you're happy with the 2-kind scheme, or other alternatives. >> >> >> Bob >> >> >> >> >> >> >> Anyway, I don’t really care how the options are encoded as long as the receiver doesn’t need per-connection state for decoding a TCP option. So, personally, I would be fine with using e.g. the length field as described in my old e-mail. Or an additional flag byte. And one could come up with further encodings, e.g., by using one or a few bits as a short “type” field for each counter. This is all about protocol engineering. And all these variants have their pros and cons. >> >> >> >> I am also fine with using two option codepoints as specified in -13; this is probably the approach that consumes the least number of bits. >> >> >> >> Michael (w/o any hat) >> >> >> >> >> >> >> >> From: Bob Briscoe >> Sent: Monday, November 16, 2020 5:52 PM >> To: Yoshifumi Nishida >> Cc: Scharf, Michael ; Michael Tuexen >> ; tcpm-chairs@ietf.org; Mirja Kuehlewind >> ; Scheffenegger, Richard >> ; tcpm IETF list >> Subject: AccECN field order >> >> >> >> Yoshi, (adding the tcpm list in cc) >> >> On 05/11/2020 06:58, Yoshifumi Nishida wrote: >> >> Hi Bob, >> >> >> >> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe wrote: >> >> Yoshi, >> >> On 04/11/2020 06:51, Yoshifumi Nishida wrote: >> >> Hi, folks, >> >> >> >> >> >> >> In my understanding, I'm not sure if we settled down on using two option kinds or encoding schemes for 24bits fields in acc ecn draft. >> >> So, I think there're still something to be clarified and hope things will be settled at the meeting. >> >> >> [BB] I know a WG can change it's mind at any time. But I'd rather we just clarified what a previous decision was, to avoid the need to keep re-opening discussion on a question that have been decided then changed three different ways already. >> >> My memory is not so good these days. I trusted that Michael S remembered the decision correctly, and I seem to remember that decision being made. >> I've just checked the minutes of the last interim: >> >> https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 >> 1600/ and they mention Michael's proposal to use two kinds, but don't >> record any decision. >> The jabber log gives no clues about any decision. >> >> I can't find an audio or video recording. Can you point me at one? >> >> >> >> I thought that it's because there was no clear decision at the meeting. >> >> But, you can check https://www.youtube.com/watch?v=KsB0_Nb8-kA >> >> Please let us know if you have any questions or opinions with regard to this. >> >> >> [BB] I checked the Youtube link you sent below. >> >> First I think we're agreed no-one was fighting for us to keep the previous way we did this (using the initial value of the field to set the order for the connection). >> In my presentation I said there was strong resistance from Michael to do it a different way. >> (also, offlist, the co-authors including me also didn't like this so >> much. And Ilpo said it made the implementation complex.) >> >> Then came the question of what we do instead. There were three alternative proposals: >> a) use 2 option kinds >> b) add a flags byte >> c) somehow use the length field maybe >> >> Michael raised (c) in the meeting as a possibility, but no-one could think how to distinguish two options of the same length but a different field order using the length field. Michael said he'd post any ideas to the list if he could think of any, but that didn't happen. >> >> So we're left choosing between (a) and (b). >> I said in the meeting (and on the list when discussing with Ilpo) that I'd be happy to go with (b), but only if there was another use for a flag. Because it would consume 1B more options space in many packets, which is a scarce resource. >> >> Ilpo had a proposed use for another flag (to help synch counters after a loss), but I think the discussion about it ended that it wouldn't be helpful, 'cos the way it worked depended on itself (circular logic). >> >> In conclusion, I don't think there was an explicit decision to go with 2 option kinds, but it ended up as the 'last person standing'. >> I like it. It's simple. And apparently option kinds are not such a scarce resource. >> >> Perhaps we can ratify this in the WG tomorrow. >> >> >> Bob >> >> >> >> >> >> >> >> Thanks, >> >> -- >> >> Yoshi >> >> >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Feb 9 09:56:27 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD393A10A9 for ; Tue, 9 Feb 2021 09:56:25 -0800 (PST) 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 KgBDg7fGiRya for ; Tue, 9 Feb 2021 09:56:22 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B043A10A7 for ; Tue, 9 Feb 2021 09:56:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B90BF25A1D; Tue, 9 Feb 2021 18:56:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1612893379; bh=vihPv+PJyBrztSNBnWoYpkpB5/XLRwb9KUyFgeXLPn4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AuITkppEPLSBhQeTrHf8E4S84Rk8Qy/H6Qrn0zE29O1e0+XIse0Lc1RP6uY2si0mR SF9feUBK/dNuoULHT2G0sVBvsf71exNkiTy9AnFpsmF8JSjjkPGWS+vH3srmqiOMTI QddNgzD+GGbYanx+iNXbiZD9GIvioWcd8IekYuD4= 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 6LMugjWasSx4; Tue, 9 Feb 2021 18:56:17 +0100 (CET) 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, 9 Feb 2021 18:56:17 +0100 (CET) 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, 9 Feb 2021 18:56:17 +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; Tue, 9 Feb 2021 18:56:17 +0100 From: "Scharf, Michael" To: Bob Briscoe , "Scheffenegger, Richard" , Mirja Kuehlewind CC: tcpm IETF list Thread-Topic: AW: [tcpm] AccECN field order Thread-Index: AQHWvDjFKAN34ufmsUi0uesNI2lMmanK+nPQgAC8GACAADPpcIAARE2AgAAktJCAAJ/vgIAIndMAgAAR3oCAet0pAIAAEa7g Date: Tue, 9 Feb 2021 17:56:17 +0000 Message-ID: References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <381499f5-3333-08c5-2ffd-fba77e027795@bobbriscoe.net> In-Reply-To: <381499f5-3333-08c5-2ffd-fba77e027795@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] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 17:56:26 -0000 Qm9iLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJvYiBCcmlzY29l IDxpZXRmQGJvYmJyaXNjb2UubmV0Pg0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA5LCAyMDIx IDU6NTggUE0NCj4gVG86IFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQgPFJpY2hhcmQuU2NoZWZmZW5l Z2dlckBuZXRhcHAuY29tPjsgTWlyamENCj4gS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5l dD47IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtDQo+IGVzc2xpbmdlbi5kZT4N Cj4gQ2M6IHRjcG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogQVc6 IFt0Y3BtXSBBY2NFQ04gZmllbGQgb3JkZXINCj4gDQo+IFJpY2hhcmQsDQo+IA0KPiBJIGp1c3Qg bm90aWNlZCBJIG1pc3NlZCB0aGUgbGFzdCBwYXJhIG9mIHRoZSBvbGQgZW1haWwgZnJvbSB5b3Ug YmVsb3cuDQo+IFJlc3BvbnNlIGlubGluZSwgdGFnZ2VkIFtCQl0uLi4NCj4gDQo+IE9uIDIzLzEx LzIwMjAgMTI6NDIsIFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQgd3JvdGU6DQo+ID4gSSBhbSBhbHNv IGluIGZhdm9yIG9mIHVzaW5nIHR3byBkaXN0aW5jdCBvcHRpb24gY29kZXMuDQo+ID4NCj4gPiBI b3dldmVyLA0KPiA+DQo+ID4+IE9yIEkgZ3Vlc3Mgd2UgY291bGQgc2F5IHRoYXQgb25seSBvbmUg b3B0aW9uIHNob3VsZCBiZSB1c2VkIGZvciBhDQo+IGNvbm5lY3Rpb24uDQo+ID4gSSBhbSBvcHBv c2VkIHRvIHRoaXMgLSB3aXRoIHR3byBvcHRpb24gY29kZXMsIGEgc2VuZGVyIHNob3VsZCBiZSBm cmVlIHRvDQo+IGNob29zZSB3aGljaGV2ZXIgaGUgcHJldmVycyBhdCBhbnkgb25lIHBvaW50OyBG b3IgZXhhbXBsZSwgaWYgdGhlIHNlbmRlciBhDQo+IHNlZ21lbnQgKGUuZy4gbWF5IGJlIHRoZSBy ZWNlaXZlciBzaWRlKSAgaGFzIHRvIHVwZGF0ZSB0aGUgRUUxIGNvdXRlciwgYnV0DQo+IGFsc28g Y29udmV5IFNBQ0sgaW5mb3JtYXRpb24sIGl0IHdvdWxkIGJlIGdvb2QgdG8gdXNlIHRoZSBvbmUs IHdoZXJlIHRoZQ0KPiBFRTEgZmllbGQgaXMgZmlyc3QsIGFuZCBvbWl0IGFsbCByZW1haW5pbmcg ZmllbGRzOw0KPiA+DQo+ID4gTGF0ZXIgaW4gdGhlIHNhbWUgY29ubmVjdGlvbiwgdGhhdCB2ZXJ5 IHNhbWUgaG9zdCBtYXkgY2hvb3NlIHRvIHVwZGF0ZQ0KPiB0aGUgQ0UgZmllbGQgdG9nZXRoZXIg d2l0aCBzb21lIFNBQ0sgaW5mb3JtYXRpb24sIGFuZCB1c2UgdGhlIG90aGVyDQo+IGNvZGVwb2lu dCBpbiBvcmRlciB0byBwcmVzZXJ2ZSBhcyBtdWNoIFRDUCBvcHRpb24gc3BhY2UgZm9yIHRoZSBT QUNLDQo+IG9wdGlvbi4uLg0KPiANCj4gW0JCXSBJIGFncmVlIHdpdGggeW91IGhlcmUgKGFuZCBk aXNhZ3JlZSB3aXRoIE1pcmphIGJlbG93KS4gVGhlIG5pY2UNCj4gdGhpbmcgYWJvdXQgMiBvcHRp b25zIGtpbmRzIGlzIHRoZXkgYXJlIHNlbGYtZGVzY3JpYmluZywgc28gdGhleSBjYW4gYmUNCj4g c3RhdGVsZXNzIChmb3IgaW5zdGFuY2UsIGNvbnNpZGVyIHRoZSBjb2RlIHlvdSB3b3VsZCBoYXZl IHRvIG90aGVyd2lzZQ0KPiBhZGQgZm9yIHdoZW4gYSBob3N0IHN3aXRjaGVzIHRvIGEgZGlmZmVy ZW50IGNvbmdlc3Rpb24gY29udHJvbCBtb2R1bGUgLQ0KPiBhIGxvdCBvZiBjb21wbGV4aXR5IGRl c3BpdGUgYmVpbmcgdW5saWtlbHkgdG8gaGFwcGVuKS4NCj4gDQo+ID4NCj4gPg0KPiA+IEFzIGZv ciBleHRlbnNpYmlsaXR5OiBJIHdvdWxkIHdhbnQgdG8gYXZvaWQgdGhhdCB0b3BpYywgYW5kIGp1 c3Qgc3BlY2lmaXkgdGhlDQo+IHRocmVlIGNvcnJlY3Qgc3VwcG9ydGVkIGxlbmd0aHMgaGVyZSwg YW5kIG5vdCBtZW50aW9uIChvdGhlciB0aGFuIGlnbm9yaW5nDQo+ICJvZGQiIGZyYWN0aW9uYWxz IG9mIHRoZSAzLWJ5dGUgd2lkZSBjb3VudGVycykgd2hhdCBoYXBwZW5zIHdpdGggb3RoZXINCj4g bGVuZ3Rocy4uLg0KPiANCj4gW0JCXSBBIHByb3RvY29sIHNwZWMgc2hvdWxkIHN1cmVseSBzYXkg d2hhdCB0byBkbyB3aXRoIHVuZXhwZWN0ZWQNCj4gaW5wdXRzLiBOb3Qgc3BlY2lmeWluZyB0aGlz IGlzIG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIHdlIGhhdmUgc3VjaA0KPiB0cm91YmxlIGNoYW5n aW5nIHRoaW5ncyBsYXRlciAtIGJlY2F1c2Ugd2UgZGlzY292ZXIgc29tZSBpbXBsZW1lbnRlcnMN Cj4gaGFuZGxlZCB0aGUgdW5leHBlY3RlZCBpbiBkaWZmZXJlbnQgd2F5cyB0byBvdGhlcnMgKGUu Zy4gaWdub3JlLCB2cyBSU1QNCj4gdGhlIGNvbm5lY3Rpb24pLCBhbmQgb3RoZXJzIG9ubHkgaGFu ZGxlZCBleHBlY3RlZCBpbnB1dHMgYW5kIGRpZG4ndCBldmVuDQo+IHRoaW5rIHRvIGNoZWNrIGZv ciBhbnl0aGluZyBlbHNlLg0KPiANCj4gU28sIEkgYmVsaWV2ZSB3ZSBoYXZlIHRvIGVpdGhlciBz YXkgInJlc2V0IHRoZSBjb25uZWN0aW9uIiBvciAiaWdub3JlIiwNCj4gaW4gcmVzcG9uc2UgdG8g YW4gdW5leHBlY3RlZCBvcHRpb24gbGVuZ3RoLiBJIGZpZ3VyZSB0aGF0LCBpZiB0aGVyZSdzIG5v DQo+IGhhcm0gaW4gaWdub3Jpbmcgc29tZXRoaW5nIHVuZXhwZWN0ZWQsIHRoZW4gd2h5IG5vdCAo ImxpYmVyYWwgaW4gd2hhdA0KPiB5b3UgcmVjZWl2ZSIgcHJpbmNpcGxlKS4NCj4gDQo+IEVhcmxp ZXIgaW4gdGhpcyB0aHJlYWQsIE1pY2hhZWwgU2NoYXJmIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUg aXMgc29tZQ0KPiBwb3RlbnRpYWwgaGFybSBoZXJlIChjb3ZlcnQgY2hhbm5lbCBvZiB1cCB0byAy OUIpLCBidXQgSSBwb2ludGVkIG91dA0KPiB0aGF0IFRDUC9JUCBoYXMgcGxlbnR5IG9mIG90aGVy IHdheXMgb2YgY3JlYXRpbmcgY292ZXJ0IGNoYW5uZWxzLCBzbw0KPiB3ZSdyZSBub3QgcmVhbGx5 IGFkZGluZyB0byBhbnkgcHJvYmxlbSBoZXJlLiBCdXQgSSBkaWQgc2F5IHRoYXQgd2Ugd291bGQN Cj4gaGlnaGxpZ2h0IHRoZSBjb3ZlcnQgY2hhbm5lbCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiwgc28NCj4gdGhlIFNlYyBBcmVhIGhhcyBhIGNoYW5jZSB0byBvYmplY3Qu IElmIGl0IHJhaXNlcyBhcyBzZXJpb3VzIGNvbmNlcm4sDQo+IHRoZW4gd2Ugc2hvdWxkIHN3aXRj aCBmcm9tICJpZ25vcmUiIHRvICJyZXNldCIsIEJ1dCBJIGRvdWJ0IGl0IHdpbGwuDQoNCkkgdGhp bmsgd2UgZmlyc3QgaGF2ZSB0byBjb21lIHRvIHRoZSBjb25jbHVzaW9uICppbnNpZGUqIFRDUE0g d2hldGhlciBzdWNoIGEgbmV3IGNvdmVydCBjaGFubmVsIGlzIGFjdHVhbGx5IGFjY2VwdGFibGUu DQoNCkV4aXN0aW5nIGNvdmVydCBjaGFubmVscyBkbyBub3QgYXQgYWxsIGltcGx5IHRoYXQgYSBu ZXcgY292ZXJ0IGNoYW5uZWwgaXMgYSBnb29kIGlkZWEgKGFuZCwgSU1ITywgMjlCIHBlciBwYWNr ZXQgaXMgYSBsb3QpLiBOZXR3b3JrIGFkbWluaXN0cmF0b3JzIGFuZCBvcGVyYXRvcnMga25vdyBo b3cgdG8gZGVhbCB3aXRoIHRoZSBleGlzdGluZyBwcm9ibGVtcyBpbiBUQ1AvSVAuIEFkZGluZyBh bnkgbmV3IHNlY3VyaXR5IGlzc3VlIG5lZWRzIGNhcmVmdWwgcmVhc29uaW5nLg0KIA0KQXMgaW5k aXZpZHVhbCBjb250cmlidXRvciB0byBUQ1BNLCBJIGJlbGlldmUgdGhhdCB0aGlzIGNvdmVydCBj aGFubmVsIG11c3QganVzdCBiZSByZW1vdmVkIGZyb20gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUg ZHJhZnQuIEF0IGxlYXN0IEkgZG9uJ3QgbmVlZCBvdGhlciBvcGluaW9ucyB0byBjb21lIHRvIHRo aXMgcGVyc29uYWwgY29uY2x1c2lvbi4NCg0KSWYgdGhpcyB3YXMgbGVzcyBvYnZpb3VzIG90aGVy cyBpbiB0aGUgV0csIFRDUE0gY291bGQgYXNrIGZvciBhbiBlYXJseSBTRUNESVIgcmV2aWV3IHRv IGdldCBmdXJ0aGVyIGd1aWRhbmNlIEFTQVAuIFRoZW4gdGhpcyBxdWVzdGlvbiBjYW4gYmUgc29y dGVkIG91dCB3aGlsZSB3ZSBmaW5pc2ggdGhlIHByb3RvY29sLg0KDQpJZiBUQ1BNIG5lZWRzIGFu eSBleHRlcm5hbCBpbnB1dCBvbiBjb3ZlcnQgY2hhbm5lbHMsIEkgdGhpbmsgYW4gZWFybHkgU0VD RElSIHJldmlldyB3b3VsZCBiZSBhIG11Y2ggYmV0dGVyIGFwcHJvYWNoIGNvbXBhcmVkIHRvIGhh dmluZyBhIHNlY3VyaXR5IGRpc2N1c3Npb24gZHVyaW5nIElFVEYgbGFzdCBjYWxsLiBXZSBhcmUg aGVyZSBkaXNjdXNzaW5nIGEgc3RhbmRhcmRzIHRyYWNrIGV4dGVuc2lvbiBvZiBvbmUgb2YgdGhl IGNvcmUgSW50ZXJuZXQgcHJvdG9jb2xzLiBJbiBzdWNoIGEgY2FzZSwgYXQgbGVhc3QgaW4gbXkg dmlldyBvbiBJRVRGIHByb2Nlc3Nlcywgb3RoZXIgSUVURiBhcmVhcyBjYW4gZXhwZWN0IHRoYXQg VENQTSB0aWVzIHRvIGRlYWwgd2l0aCBrbm93biBvcGVuIGlzc3VlcyB3aXRoaW4gdGhlIFdHIGFz IGZhciBhcyBwb3NzaWJsZSwgaS5lLiwgYmVmb3JlIHRoZXkgc2VlIGEgInN0YWJsZSIgc3BlY2lm aWNhdGlvbiBpbiB0aGUgSUVURiBsYXN0IGNhbGwuDQoNCkluIGEgbnV0c2hlbGw6DQoNCi0xIG9u IGxlYXZpbmcgdGhpcyBxdWVzdGlvbiBvcGVuIHVudGlsIElFVEYgbGFzdCBjYWxsDQoNCk1pY2hh ZWwNCg0KDQoNCj4gDQo+IENoZWVycw0KPiANCj4gDQo+IA0KPiBCb2INCj4gDQo+ID4NCj4gPg0K PiA+IFJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KPiA+DQo+ID4gLS0tLS1VcnNwcsO8bmdsaWNoZSBO YWNocmljaHQtLS0tLQ0KPiA+IFZvbjogTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5k Lm5ldD4NCj4gPiBHZXNlbmRldDogTW9udGFnLCAyMy4gTm92ZW1iZXIgMjAyMCAxMjozOQ0KPiA+ IEFuOiBOZWFsIENhcmR3ZWxsIDxuY2FyZHdlbGxAZ29vZ2xlLmNvbT47IFNjaGFyZiwgTWljaGFl bA0KPiA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgQm9iIEJyaXNjb2UgPGlldGZA Ym9iYnJpc2NvZS5uZXQ+DQo+ID4gQ2M6IFlvc2hpZnVtaSBOaXNoaWRhIDxuc2QuaWV0ZkBnbWFp bC5jb20+OyB0Y3BtIElFVEYgbGlzdA0KPiA8dGNwbUBpZXRmLm9yZz47IFNjaGVmZmVuZWdnZXIs IFJpY2hhcmQNCj4gPFJpY2hhcmQuU2NoZWZmZW5lZ2dlckBuZXRhcHAuY29tPjsgTWljaGFlbCBU dWV4ZW4gPHR1ZXhlbkBmaC0NCj4gbXVlbnN0ZXIuZGU+OyB0Y3BtLWNoYWlyc0BpZXRmLm9yZw0K PiA+IEJldHJlZmY6IFJlOiBbdGNwbV0gQWNjRUNOIGZpZWxkIG9yZGVyDQo+ID4NCj4gPiBOZXRB cHAgU2VjdXJpdHkgV0FSTklORzogVGhpcyBpcyBhbiBleHRlcm5hbCBlbWFpbC4gRG8gbm90IGNs aWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhl IHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcw0KPiBzYWZlLg0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gSSB0aGluayBJIGFsc28gc3VwcG9ydCB0d28gb3B0 aW9ucyBhcyB0aGlzIGlzIHRoZSBtb3N0IHNpbXBsZSBzb2x1dGlvbi4NCj4gPg0KPiA+IFdlIHBy b2JhYmx5IG5lZWQgdG8gbG9vayBhdCBzZWN0aW9uIDMuMi4zLjIuIChQYXRoIFRyYXZlcnNhbCBv ZiB0aGUgQWNjRUNODQo+IE9wdGlvbikgYWdhaW4sIGFzIEkgdGhpbmsgdGhpcyBzZWN0aW9uIGFz c3VtZXMgbW9zdGx5IG9uZSBvcHRpb24uIE9yIEkgZ3Vlc3MNCj4gd2UgY291bGQgc2F5IHRoYXQg b25seSBvbmUgb3B0aW9uIHNob3VsZCBiZSB1c2VkIGZvciBhIGNvbm5lY3Rpb24uDQo+ID4NCj4g PiBSZWdhcmRpbmcgdXNlIG9mIHRoZSBvcHRpb24gbGVuZ3RoIGZvciBleHRlbnNpYmlsaXR5LiBJ IGtub3cgbmV3IG9wdGlvbnMgYXJlDQo+IGhhcmQgdG8gZGVwbG95IGJ1dCB0aGF04oCZcyB0aGUg ZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gd2UgaGF2ZSB3aXRoIFRDUC4gTm90DQo+IHN1cmUgd2Ug d2FudCB0byBpbnZlbnQgYSBuZXcgbm93LiBJZiB3ZSB0aGluayB3ZSBuZWVkIG1vcmUgZXh0ZW5z aWJpbGl0eQ0KPiBmb3IgQWNjRUNOIGZvciBhbnkgcmVhc29uLCB3ZSBzaG91bGQgc3BlY2lmeSB2 YWxpZCBvcHRpb24gbGVuZ3RoIHZhbHVlcyB0aGF0DQo+IGluY2x1ZGUgYSBmbGFncyBmaWVsZCBu b3cuDQo+ID4NCj4gPiBNaXJqYQ0KPiA+DQo+ID4NCj4gPg0KPiA+PiBPbiAxOC4gTm92IDIwMjAs IGF0IDAxOjAzLCBOZWFsIENhcmR3ZWxsIDxuY2FyZHdlbGxAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+ ID4+DQo+ID4+IEFzIHNvbWVvbmUgd2hvIGNvbnRyaWJ1dGVzIHRvIGEgVENQIGltcGxlbWVudGF0 aW9uLCBJIHdvdWxkIHB1dCBpbiBhDQo+IHZvdGUgZm9yIHRoZSAiVHdvIE9wdGlvbiBLaW5kcyIg cHJvcG9zYWwgb3V0bGluZWQgaW4gc2xpZGUgNiBoZXJlOg0KPiA+Pg0KPiA+Pg0KPiA+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA5L21hdGVyaWFscy9zbGlkZXMtMTA5 LXRjcG0tbW9yDQo+ID4+IGUtYWNjdXJhdGUtZWNuLWZlZWRiYWNrLWluLXRjcC1lY24tYWRkaW5n LWV4cGxpY2l0LWNvbmdlc3Rpb24tbm90aWZpY2ENCj4gPj4gdGlvbi0wMSNwYWdlPTYNCj4gPj4N Cj4gPj4gVGhpcyBhcHByb2FjaCBoYXMgdGhlIHZpcnR1ZSBvZiBzaW1wbGljaXR5LCB3aGljaCBo b3BlZnVsbHkgbWF5IGhlbHAgYXZvaWQNCj4gbWlkZGxlYm94IGJ1Z3MsIHNwZWVkIHN0YW5kYXJk aXphdGlvbiBhbmQgZGV2ZWxvcG1lbnQsIGFuZCBlYXNlIHRoZQ0KPiBwcm9jZXNzIG9mIG1haW50 YWluaW5nIGZhc3QgYW5kIHN0YWJsZSBpbXBsZW1lbnRhdGlvbnMuDQo+ID4+DQo+ID4+IG5lYWwN Cj4gPj4NCj4gPj4NCj4gPj4gT24gVHVlLCBOb3YgMTcsIDIwMjAgYXQgOToyNSBBTSBTY2hhcmYs IE1pY2hhZWwgPE1pY2hhZWwuU2NoYXJmQGhzLQ0KPiBlc3NsaW5nZW4uZGU+IHdyb3RlOg0KPiA+ PiBJbmxpbmUgc29tZSBjb21tZW50cyBbbXNdLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBHaXZl biB0aGF0IEkgZG9u4oCZdCBhc2sgZm9yIGFueSB0ZXh0IGNoYW5jZXMsIEnigJlsbCBub3QgZm9s bG93LXVwIGZvcmV2ZXIgaW4gdGhpcw0KPiBkaXNjdXNzaW9uLiBJIGRvbuKAmXQgb3duIHJ1bm5p bmcgY29kZSBhbmQgYSBsb3Qgb2YgZW5jb2RpbmcgZGV0YWlscyBtYWlubHkNCj4gYWZmZWN0IGFu IGltcGxlbWVudGF0aW9uLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBJTUhPIHRoZSByZXN0IG9m IHRoZSBXRyBoYXMgdG8gdGhpbmsgYWJvdXQgdGhlIG9wdGlvbiBkZXNpZ24gbW9yZSB0aGFuDQo+ ID4+IG1lLiBTbywgdGhpcyBpcyBtb3N0bHkgYWJvdXQgdHJpZ2dlcmluZyBhIGRpc2N1c3Npb27i gKYNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gRnJvbTogQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJp c2NvZS5uZXQ+DQo+ID4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAyMDIwIDE6MjAgUE0N Cj4gPj4gVG86IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRl PjsgWW9zaGlmdW1pDQo+ID4+IE5pc2hpZGEgPG5zZC5pZXRmQGdtYWlsLmNvbT4NCj4gPj4gQ2M6 IE1pY2hhZWwgVHVleGVuIDx0dWV4ZW5AZmgtbXVlbnN0ZXIuZGU+OyB0Y3BtLWNoYWlyc0BpZXRm Lm9yZzsNCj4gPj4gTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD47IFNjaGVm ZmVuZWdnZXIsIFJpY2hhcmQNCj4gPj4gPFJpY2hhcmQuU2NoZWZmZW5lZ2dlckBuZXRhcHAuY29t PjsgdGNwbSBJRVRGIGxpc3QgPHRjcG1AaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBBY2NF Q04gZmllbGQgb3JkZXINCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gTWljaGFlbCwNCj4gPj4NCj4g Pj4gT24gMTcvMTEvMjAyMCAwODoxMCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KPiA+Pg0KPiA+ PiBCb2IsDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEkgYW0gZmluZSB3aXRoIHRoZSB0d28gb3B0 aW9uIGtpbmRzIHByb3Bvc2VkIGluIC0xMywgYnV0IEkgZG9u4oCZdCBidXkgeW91cg0KPiBhcmd1 bWVudHMgd2h5IHRoaXMgZW5jb2RpbmcgaXMgYmV0dGVyIHRoYW4gb3RoZXJzLg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+PiBNb3N0IGltcG9ydGFudGx5LCBJIGRvbuKAmXQgdGhpbmsgdGhhdCB5b3Vy IOKAnGZvcndhcmQgY29tcGF0aWJpbGl0eeKAnQ0KPiBhcmd1bWVudCBpcyBhIHZlcnkgY29tcGVs bGluZyByZWFzb24gZm9yIHR3byBjb2RlcG9pbnRzLiBBbGwgcHJvcG9zYWxzIEkgYW0NCj4gYXdh cmUgb2YgaGF2ZSB0aGVpciBwcm9zIGFuZCBjb25zLiBBbmQgSSBhbSBub3QgYXdhcmUgb2YgYSBy ZWFsbHkNCj4gY29tcHJlaGVuc2l2ZSBkaXNjdXNzaW9uLiBBdCBsZWFzdCBuZWl0aGVyIHRoZSBl LW1haWwgYmVsb3cgbm9yIHRvZGF54oCZcw0KPiBtZWV0aW5nIGRpc2N1c3MgYWxsIHRyYWRlb2Zm cyBJIHdvdWxkIGludmVzdGlnYXRlLg0KPiA+Pg0KPiA+Pg0KPiA+PiBbQkJdIFlvdSdyZSByaWdo dCAtIHRoZSBkaXNjdXNzaW9uIGJlbG93IGlzIHVzZWZ1bCBhbmQgbmVjZXNzYXJ5Lg0KPiA+Pg0K PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBGb3IgaW5zdGFuY2UsIHRoZSBiZW5lZml0IG9m IHRoZSBsZW5ndGggZW5jb2RpbmcgdmFyaWFudCB3b3VsZCBiZSB0bw0KPiBjb25zdW1lIG9ubHkg b25lIFRDUCBvcHRpb24gY29kZXBvaW50IG5vdy4gSWYgd2UgZGVjaWRlZCBsYXRlciB0byB0aGF0 IGENCj4gZmxhZyBieXRlIGlzIG5lZWRlZCAoc2F5LCBhdCB0aGUgZW5kKSwgYSBmb2xsb3ctdXAg cHJvcG9zZWQgc3RhbmRhcmQgY291bGQNCj4gc3BlY2lmeSBhbm90aGVyIG9wdGlvbiBmb3JtYXQg d2l0aCB0aGF0IGZsYWcgYnl0ZSwgdXNpbmcgYSBzZWNvbmQgY29kZXBvaW50Lg0KPiA+Pg0KPiA+ Pg0KPiA+PiBbQkJdDQo+ID4+ICogVGhlIG5ldyBjb2RlcG9pbnQgd291bGQgcmVxdWlyZSB5ZWFy cyB0byBkZXBsb3kgKGluY2x1ZGluZyBpbiBwcm94aWVzKQ0KPiBiZWZvcmUgaXQgd29ya3MgZTJl Lg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBbbXNdIFRoYXQgbWF5IGRlcGVuZCAqYSBsb3QqIG9u IHRoZSBlbnZpcm9ubWVudC4gSW4gZW52aXJvbm1lbnRzDQo+IHdoZXJlIEVDTiBjYW4gZ2V0IGRl cGxveWVkIHRvZGF5LCBzYXkgaW4gZGF0YWNlbnRlcnMsIHJvbGxpbmcgb3V0IGEgbmV3DQo+IGtl cm5lbCB2ZXJzaW9uIG1heSBwZXJoYXBzIG5vdCBiZSB0aGUgYmlnZ2VzdCBvcGVyYXRpb25hbCBj aGFsbGVuZ2UuIEFsc28sDQo+IHByb3hpZXMgbWF5IG5vdCBiZSBhIHNpZ25pZmljYW50IHByb2Js ZW0gaW4gc29tZSBvZiB0aG9zZSBjYXNlcy4gRGVwbG95bWVudA0KPiByb2FkbWFwcyBhcmUgdmVy eSBoYXJkIHRvIHByZWRpY3QuDQo+ID4+DQo+ID4+DQo+ID4+ICogV2hlcmVhcyB0aGUgJ2Zvcndh cmQgY29tcGF0aWJpbGl0eScgYXBwcm9hY2ggdHJpZXMgdG8gZW5zdXJlIHRoYXQNCj4gQWNjRUNO IGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBiZWluZyBidWlsdCB0b2RheSB3aWxsIGJlIHJlYWR5 IHRvIGludGVyd29yaw0KPiB3aXRoIGEgZnV0dXJlIGV4dGVuc2lvbi4NCj4gPj4gKiBJbiBjb250 cmFzdCwgaWYgeW91ciBoeXBvdGhldGljYWwgbmV3IEFjY0VDTiBjb2RlcG9pbnQgZGlkIG5lZWQg dG8gYmUNCj4gZGVwbG95ZWQgbGF0ZXIsIGl0IHdvdWxkIG5lZWQgdG8gaW5jbHVkZSBhIGZhbGwt YmFjayB0byB0aGUgY3VycmVudCBBY2NFQ04NCj4gb3B0aW9uIHdoZW4gb25lIHBlZXIgZG9lc24n dCB1bmRlcnN0YW5kIHRoZSBuZXcgY29kZXBvaW50Lg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBb bXNdIFRoaXMgaXMgYSByZWFzb25hYmxlIHBvaW50LCBhbGJlaXQgbm90IGEgcGFydGljdWxhcmx5 IHN0cm9uZyBvbmUsDQo+ID4+IGdpdmVuIHRoYXQgdGhlIG9wdGlvbiBpcyBub3QgcmVhbGx5IHJl cXVpcmVkIGZvciBiYXNpYw0KPiA+PiBpbnRlcm9wZXJhYmlsaXR5LiBBbHNvLCBhIGh5cG90aGV0 aWNhbCBmb2xsb3ctdXAgc3RhbmRhcmQgY291bGQNCj4gPj4gaW5jbHVkZSBhIHdheSB0byBleHBs aWNpdGx5IHJlcXVlc3QgdGhlIG9wdGlvbuKApg0KPiA+Pg0KPiA+Pg0KPiA+PiAqIEZhbGwtYmFj ayB3b3VsZCBuZWVkIHRvIGF2b2lkIGEgc2Vjb25kIHJvdW5kIG9mIGhhbmRzaGFrZSAoZ2l2ZW4N Cj4gPj4gdGhpcyBpcyBmb3IgbG93IGxhdGVuY3kpLCB3aGljaCB3b3VsZCBvbmx5IHdvcmsgcmVs aWFibHkgd2l0aCBhbg0KPiA+PiBvcHRpb24gb24gdGhlIFNZTiAoYmVjYXVzZSB0aGUgM3JkIEFD SyBpcyB1bnJlbGlhYmxlKQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBbbXNdIEkgY2Fu4oCZdCBm b2xsb3cuIElmIGFuIGVuZHBvaW50IGlzIHVuaGFwcHkgd2l0aCBnZXR0aW5nIEFjY0VDTiBvcHRp b24NCj4g4oCcQeKAnSBmcm9tIGEgcGVlciwgSSBjb3VsZCBzZW5kIGEg4oCccGxlYXNlIHNlbmQg bWUgdGhlIGJldHRlciBBY2NFQ04gb3B0aW9uIELigJ0NCj4gYWZ0ZXIgdGhlIDMtV0hTLiBJdCBj b3VsZCBiZSBhbiB1cGdyYWRlLCBub3QgYSBmYWxsYmFjay4gQWxzbywgYXQgdGhpcyBwb2ludCB3 ZQ0KPiBkb27igJl0IGtub3cgd2hhdCBvcHRpb24gQiB3b3VsZCBiZSBhbmQgaW4gd2hpY2ggY29u dGV4dCBpdCB3b3VsZCBiZQ0KPiBuZWVkZWQuIE1heWJlIG90aGVyIHByb3RvY29sIGZlYXR1cmVz IHdvdWxkIHJlcXVpcmUgbmVnb3RpYXRpb24sIHRvby4NCj4gSU1ITyBpdCBpcyBhIHNvbHZhYmxl IHByb2JsZW0uDQo+ID4+DQo+ID4+DQo+ID4+ICogQWNjRUNOIGhhcyBzbyBmYXIgYXZvaWRlZCB1 c2luZyBhbnkgU1lOIG9wdGlvbiBzcGFjZSwgd2hpY2ggaXMNCj4gaW1wb3J0YW50IGdpdmVuIHRo YXQgaXMgdGhlIHNjYXJjZXN0IHJlc291cmNlLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBbbXNd IFllcCwgYnV0IGFzIGxvbmcgYXMgbm8gcHJvcG9zYWwgbmVlZHMgU1lOIG9wdGlvbnMsIHRoaXMg aXMgbm90aGluZw0KPiB0aGF0IHdvdWxkIG1ha2Ugb25lIHNvbHV0aW9uIGJldHRlciB0aGFuIGFu b3RoZXIuDQo+ID4+DQo+ID4+IFRoZXNlIGRheXMsIGV4dGVuZGluZyBUQ1AgaXMgbGlrZSBwbGF5 aW5nIGNoZXNzIC0gd2UgaGF2ZSB0byB0aGluayBtdWx0aXBsZQ0KPiBtb3ZlcyBhaGVhZCENCj4g Pj4NCj4gPj4NCj4gPj4NCj4gPj4gW21zXSBUaGVyZSBpcyBvbmUgZnVuZGFtZW50YWwgZGlmZmVy ZW5jZSBiZXR3ZWVuIGNoZXNzIGFuZCBUQ1A6IEluDQo+IGNoZXNzIHlvdSBwcmVjaXNlbHkga25v dyB0aGUgY3VycmVudCBzaXR1YXRpb24gYW5kIGNhbiBwcmVkaWN0IGFsbCBwb3RlbnRpYWwNCj4g bW92ZXMgaW4gYWR2YW5jZSAoYWxiZWl0IHRoZXJlIGFyZSBhIGxvdCkuIEhvd2V2ZXIsIHdlIGRv buKAmXQga25vdyB0aGUNCj4gZnV0dXJlIGV2b2x1dGlvbiBvZiBUQ1AsIEVDTiBhbmQgdGhlIElu dGVybmV0IGFzIGEgd2hvbGUsIG5vciBmdXR1cmUNCj4gcmVxdWlyZW1lbnRzLiBJZiB3ZSB0cnkg dG8gZW5naW5lZXIgYSBUQ1AgZXh0ZW5zaW9uIGZvciBzb21lIHBvdGVudGlhbA0KPiBmdXR1cmUs IHdlIG1heSBmaWd1cmUgb3V0IGxhdGVyIHRoYXQgcmVhbGl0eSBpcyBkaWZmZXJlbnQgZnJvbSB3 aGF0IHdlDQo+IGRlc2lnbmVkIGZvci4gQXMgbXVjaCBhcyBJIGFwcHJlY2lhdGUgeW91ciBhdHRl bXB0cyB0byBwcmVkaWN0IHRoZSBmdXR1cmUsIGl0DQo+IHdvdWxkIGJlIGEgYmlnIHN1cnByaXNl IHRvIG1lIGlmIHlvdSBjb3VsZCBjb3JyZWN0bHkgcHJlZGljdCB3aGF0IFRDUCB3aWxsIGJlIGlu DQo+IDEwIHllYXJzIGZyb20gbm93LiBTbywgaW5zdGVhZCBvZiB0cnlpbmcgdG8gd3JpdGUgc3Bl Y2lmaWNhdGlvbnMgdGhhdCB0YWtlIGludG8NCj4gYWNjb3VudCBmdXR1cmUgcmVxdWlyZW1lbnRz LCB3aGljaCBhcmUgaW4gZmFjdCBqdXN0IHVua25vd24sIGl0IGlzIG1vcmUNCj4gaW1wb3J0YW50 IGZvciBtZSB0byB3cml0ZSBlZmZlY3RpdmUsIGVmZmljaWVudCBhbmQgc2VjdXJlIHNwZWNpZmlj YXRpb25zIGZvcg0KPiB3aGF0IGlzIGN1cnJlbnRseSBrbm93biBmb3Igc3VyZS4NCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4gW21zXSBJICpkb27igJl0KiBrbm93IGZvciBzdXJlIHdoZXRoZXIgdGhl IGN1cnJlbnQgQWNjRUNOIG9wdGlvbiB3aWxsIGJlDQo+IG5lZWRlZCwgYnV0IEkgc2VlIHF1aXRl IHNvbWUgZXZpZGVuY2UgdGhhdCBzdXBwb3J0IG9mIHRoZSBBY2NFQ04gb3B0aW9uKHMpDQo+IGlz IG5vdCBhIHRvcCBwcmlvcml0eSB0aGVzZSBkYXlzLiBUaGF0IGlzIGFsc28gc29tZXRoaW5nIHRv IHRoaW5rIGFib3V0IHdoZW4NCj4gZGVzaWduaW5nIHRoZSBkZXRhaWxzLg0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+PiBJIG5lZWQgdG8gbGVhcm4gdG8gYXJ0aWN1bGF0ZSBvbnRvIHRoZSBsaXN0IGFs bCBteSByZWFzb25zIGZvciByZWplY3RpbmcNCj4gY2VydGFpbiBwYXJ0cyBvZiB0aGUgZGVzaWdu IHNwYWNlLiBTb3JyeSBhYm91dCB0aGF0Lg0KPiA+Pg0KPiA+PiBZZXMsIEkgYWRtaXQsIHRoZSBj dXJyZW50IHByb3Bvc2FsIGlzIGF0IHRoZSBjb3N0IG9mIGJ1cm5pbmcgdHdvIFRDUCBvcHRpb24N Cj4gY29kZXBvaW50cy4gSG93ZXZlciwgeW91IHNhaWQgeW91cnNlbGYgd2hlbiB5b3UgcHJvcG9z ZWQgdGhpcyBhcHByb2FjaCwNCj4gdGhhdCB0aGV5IGFyZSBub3QgKGN1cnJlbnRseSkgYSBzY2Fy Y2UgcmVzb3VyY2UuIENlcnRhaW5seSBub3QgYXMgc2NhcmNlIGFzDQo+IG9wdGlvbiBzcGFjZS4g SSBqdXN0IGNoZWNrZWQ6IHJvdWdobHkgMTUlIG9mIHRoZSBvcHRpb24gY29kZXBvaW50IGFsbG9j YXRpb24NCj4gc3BhY2UgaGFzIGJlZW4gdXNlZCBzbyBmYXIuIFNvIHRoYXQncyB3aGVyZSBJIHdv dWxkIHN1Z2dlc3Qgd2UgY29tcHJvbWlzZQ0KPiBmaXJzdC4NCj4gPj4NCj4gPj4gW21zXSBJIG1h ZGUgYSBzaW1pbGFyIGNhbGN1bGF0aW9uIHNvbWUgeWVhcnMgYWdvIGFuZCBjYW1lIHRvIGEgc2lt aWxhcg0KPiBjb25jbHVzaW9uLiBJbnZlc3RpbmcgdHdvIGNvZGVwb2ludHMgZm9yIEFjY0VDTiBp cyBzb21ldGhpbmcgd2UgY2FuDQo+IHByb2JhYmx5IGFmZm9yZC4gQnV0IG5vbmV0aGVsZXNzIHdl IGhhdmUgdG8gcmVhc29uIGNhcmVmdWxseSB3aHkgaXQgaXMgcmVhbGx5DQo+IHdvcnRoIHRoZSBl ZmZvcnQuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFJlZ2FyZGluZyB0aGUgcmVzdWx0 aW5nIGNvZGVwb2ludCBjb25zdW1wdGlvbiAodHdvIG9wdGlvbiBraW5kcykgYW5kDQo+IHRoZSBh ZGRpdGlvbiBvZiBhIGZsYWcgYnl0ZSwgdGhpcyBhcHByb2FjaCB3b3VsZCBiYXNpY2FsbHkgZW5k IHVwIHdpdGggdGhlDQo+IHNhbWUgcmVzdWx0IGFzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGluIC0x MyBwbHVzIHNvbWUgaHlwb3RoZXRpY2FsIGZ1dHVyZQ0KPiBhZGRpdGlvbiBsZXZlcmFnaW5nIHRo ZSBsZW5ndGggZmllbGQgYmV5b25kIHRoZSBjdXJyZW50bHkga25vd24gdXNlLg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+PiBBbmQsIHllcywgdGhlIGxlbmd0aCBlbmNvZGluZyB2YXJpYW50IG1heSBi ZSBsZXNzIGZsZXhpYmxlIGFuZC9vcg0KPiBjb25zdW1lIHNvbWUgbW9yZSBiaXRzIGluIHNvbWUg Y2FzZXMsIGJ1dCBvbiB0aGUgcGx1cyBzaWRlIGl0IG9ubHkgbmVlZHMNCj4gb25lIGNvZGVwb2lu dCBub3cg4oCTIGFuZCBnaXZlbiB0aGF0IGl0IGlzIGVudGlyZWx5IHVuY2xlYXIgd2hldGhlciBh bnkNCj4gQWNjRUNOIG9wdGlvbiB3aWxsIGluZGVlZCBiZSB3aWRlbHkgdXNlZCBpbiBmdXR1cmUs IHRoaXMgaXMgYSBiaWcgcGx1cy4gVGhlIGZhY3QNCj4gdGhhdCBpbXBsZW1lbnRlcnMgYXJlIHF1 aXRlIHNpbGVudCBvbiB0aGUgb3B0aW9uIGRlc2lnbiBpcyBub3QgYSBnb29kIHNpZ24uDQo+ID4+ DQo+ID4+DQo+ID4+IFtCQl0gSGVyZSdzIGFub3RoZXIgcG9zc2liaWxpdHkgdGhlbi4NCj4gPj4N Cj4gPj4gYSkgW0t8THwgRUUxQiB8IEVDRUIgfCBFRTBCIF0NCj4gPj4gYikgW0t8THwgRUUxQiB8 IEVDRUIgfCBFRTBCIHxGXSAgICBpZiBGID0gMGJYWFhYWFhYMA0KPiA+PiBjKSBbS3xMfCBFRTBC IHwgRUNFQiB8IEVFMUIgfEZdICAgIGlmIEYgPSAwYlhYWFhYWFgxDQo+ID4+DQo+ID4+IFdlJ2Qg aGF2ZSB0byBkZWNpZGUgd2hpY2ggb3JkZXIgYWx0ZXJuYXRpdmUgKGEpIHRha2VzLiBJJ3ZlIHBp Y2tlZCBFRTFCDQo+IGZpcnN0IG9ubHkgJ2NvcyB5b3UncmUgcmlnaHQgdGhhdCB0aGVyZSBpcyBu b3QgY3VycmVudGx5IGFzIG11Y2ggcHJlc3N1cmUgKG9uIHRoZQ0KPiBwdWJsaWMgSW50ZXJuZXQp IGZvciBBY2NFQ04gd2l0aCBFQ1QoMCkuDQo+ID4+DQo+ID4+ID09TGVnZW5kPT0NCj4gPj4gSzog ICAgS2luZCAoMUIpDQo+ID4+IEw6ICAgIExlbmd0aCAoMUIpDQo+ID4+IEV4eEI6IEVjaG8geHgg Ynl0ZSBjb3VudGVyDQo+ID4+IEY6ICAgIEZsYWdzICgxQikNCj4gPj4NCj4gPj4gQWx0ZXJuYXRp dmVzIGEpIGFuZCBiKSBhcmUgZXF1aXZhbGVudCwgYXQgbGVhc3Qgd2hpbGUgdGhlIG9ubHkgYWxs b2NhdGVkIGZsYWcNCj4gaXMgZm9yIGZpZWxkIG9yZGVyLg0KPiA+PiBIb3dldmVyLCBhbHRlcm5h dGl2ZSBiKSBpcyBhdmFpbGFibGUgaW4gY2FzZSBvdGhlciBmbGFncyBhcmUgYWxsb2NhdGVkDQo+ ID4+IGluIGZ1dHVyZSBUaGUgZmxhZ3MgYnl0ZSBjYW4gb25seSBiZSBvbWl0dGVkIGlmIChMICUg MyA9PSAyKS4NCj4gPj4gVGhlIGZsYWdzIGJ5dGUgaXMgY29uc2lkZXJlZCBwcmVzZW50IGlmIChM ICUgMykgPT0gMC4NCj4gPj4NCj4gPj4gRm9yd2FyZCBjb21wYXRpYmlsaXR5OiBPcHRpb25zIHdp dGggKEwgJSAzID09IDEpIE1VU1QgYmUgYXNzdW1lZCB0bw0KPiBpbmNsdWRlIGEgZmxhZ3MgYnl0 ZSwgYW5kIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGlnbm9yZSB0aGUgbGFzdCBieXRlLg0KPiA+ Pg0KPiA+PiBUaGUgZmxhZ3MgYnl0ZSBpcyBvcHRpb25hbCB0byBpbXBsZW1lbnQgKGV2ZW4gaWYg dGhlIEFjY0VDTiBvcHRpb24gaXMNCj4gPj4gaW1wbGVtZW50ZWQpIElmIHRoZSBzZXJ2ZXIgaW5j bHVkZXMgYSBmbGFncyBieXRlIG9uIHRoZSBTWU4vQUNLIGJ1dCB0aGUNCj4gY2xpZW50IGRvZXMg bm90IGluY2x1ZGUgb25lIG9uIHRoZSAzcmQgQUNLIG9yIHRoZSBmaXJzdCBkYXRhIHBhY2tldCwg dGhlIHNlcnZlcg0KPiBhc3N1bWVzIHRoZSBjbGllbnQgZG9lcyBub3QgaW1wbGVtZW50IHRoZSBm bGFncyBieXRlIGFuZCB1c2VzIG9ubHkNCj4gYWx0ZXJuYXRpdmUgYSkgZm9yIHRoZSByZW1haW5k ZXIgb2YgdGhlIGNvbm5lY3Rpb24uDQo+ID4+DQo+ID4+DQo+ID4+IFttc10gSSBhbSBub3Qgc3Vy ZSBpZiB3ZSBuZWVkIHRoYXQsIGJ1dCBJIHRha2UgdGhpcyBhcyBleGlzdGVuY2UgcHJvb2YgdGhh dA0KPiBvdGhlciBlbmNvZGluZ3MgYXJlIHBvc3NpYmxlLiBQZXJzb25hbGx5LCBJIHRoaW5rIHRo YXQgb3RoZXIgc29sdXRpb25zIHdvdWxkDQo+IGJlIGRvYWJsZSBpZiB5b3UgdG9vayBvbmUgYml0 IGZyb20gb25lIG9yIG11bHRpcGxlIGNvdW50ZXJzIGZvciBmb3JtYXQNCj4gZW5jb2RpbmcuIEF0 IGxlYXN0IGZvciBzb21lIG9mIHRoZSBieXRlIGNvdW50ZXJzIEkgZG9u4oCZdCB0aGluayB0YWtp bmcgb25lIGJpdA0KPiBmb3Igb3RoZXIgcHVycG9zZXMgd291bGQgcmVzdWx0IGluIGFuIEludGVy bmV0IGNvbmdlc3Rpb24gY29sbGFwc2XigKYgQnV0LCBJDQo+IGhhdmUgYWxyZWFkeSBzYWlkIHRo YXQgdGhlIC0xMyBwcm9wb3NhbCB3b3JrcyBmb3IgbWUsIHNvIEnigJlsbCBub3QgdHJ5IHRvIGNv bWUNCj4gdXAgd2l0aCBhbm90aGVyIHZhcmlhbnQgbXlzZWxmLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0K PiA+PiBUbyBtZSwgb25lIHBvdGVudGlhbCBkaWZmZXJlbmNlIGJldHdlZW4gdHdvIHByb3Bvc2Fs cyB3b3VsZCBiZQ0KPiBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LiBUaGUgcHJvcG9zYWwgaW4gLTEz IG9ubHkgaGFzIGFuIGFkdmFudGFnZSBpZg0KPiBtaWRkbGVib3hlcyBzdWNoIGFzIGZpcmV3YWxs cyB3aWxsIGluZGVlZCBwYXNzIFRDUCBvcHRpb25zIHdpdGggYSBmb3JtYXQgdGhhdA0KPiBjb250 YWlucyBjb250ZW50IGJleW9uZCB0aGUgKGZpcnN0KSBBY2N1cmF0ZSBFQ04gc3RhbmRhcmQgKGku ZS4sIGN1cnJlbnRseQ0KPiB1bnVzZWQgbGVuZ3RoIHZhbHVlcykuIElNSE8gaXQgaXMgdG9vIGVh cmx5IHRvIGtub3cgd2hldGhlciBmaXJld2FsbHMgd291bGQNCj4gaW5kZWVkIGFsbG93IHRoaXMg aW4gZnV0dXJlLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgRnJvbSBhIHNlY3VyaXR5IHBlcnNw ZWN0aXZlLCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciBhbGxvd2luZw0KPiBhcmJpdHJh cnkgdW5zcGVjaWZpZWQgYnl0ZXMgaW4gYSBUQ1Agb3B0aW9uIGlzIGEgZ29vZCBpZGVhICphdCBh bGwqLiBJdCB3aWxsIGJlDQo+IGludGVyZXN0aW5nIHRvIGhlYXIgdGhlIG9waW5pb24gZnJvbSBT RUMgYXJlYSBvbiB0aGF0LiBQZXJzb25hbGx5LCBJIGFtIG5vdA0KPiBjb252aW5jZWQgdGhhdCB0 aGlzIHJlYWxseSBtYWtlcyBzZW5zZSwgYnV0IEkgbXkgY29uY2VybnMgYXJlIG5vdCBzdHJvbmcN Cj4gZW5vdWdoIHRvIGZvcm1hbGx5IHB1c2ggYmFjay4gSeKAmWxsIGxlYXZlIGl0IHRvIG90aGVy cyB0byB0aGluayBhYm91dCB3aGV0aGVyDQo+IHRoaXMgaXMgYSBidWcgb3IgYSBmZWF0dXJlLg0K PiA+Pg0KPiA+Pg0KPiA+PiBbQkJdIFdlbGwsIGxldCdzIGZpcnN0IHRyeSB0byBkZWFsIHdpdGgg c2VjdXJpdHkgb3Vyc2VsdmVzOg0KPiA+PiAqIE9jdGV0cyB0aGF0IGFyZSBleHBsaWNpdGx5IGRl Y2xhcmVkIGFzIHBhcnQgb2YgYW4gb3B0aW9uIGNhbm5vdCBiZSB1c2VkDQo+IGZvciBhIGJ1ZmZl ciBvdmVyZmxvdyBhdHRhY2suIEkgZG9uJ3QgcmVhbGx5IG5lZWQgdG8sIGJ1dCBJIGNvdWxkIGFk ZCB0aGUNCj4gZm9sbG93aW5nIHRleHQgdG8gdGhlIGZvcndhcmQgY29tcGF0aWJpbGl0eSB3b3Jk aW5nOg0KPiA+PiAgICAgIEEgcmVjZWl2ZXIgY29uc2lkZXJzIG9jdGV0cyBiZXlvbmQgdGhvc2Ug aXQgdXNlcywgYnV0IHdpdGhpbiB0aGUNCj4gc3BlY2lmaWVkIGxlbmd0aCwgYXMgaWYgdGhleSBh cmUgcGFkZGluZy4NCj4gPj4gKiBBbmQgc3VjaCBvY3RldHMgY2Fubm90IGJlIGFueSBkaWZmZXJl bnQgZnJvbSB0aGUgY3VycmVudCBhYmlsaXR5IG9mIGENCj4gc2VuZGVyIHRvIGFkZCBwYWRkaW5n LiBTbyB0aGVyZSdzIG5vIG5ldyBhdHRhY2sgcG9zc2libGUgaGVyZS4NCj4gPj4gKiBBbmQgdGhl cmUncyBubyBuZWVkIHRvIHNwZWNpZnkgYSBtYXggbGVuZ3RoIGZvciBhbnkgQWNjRUNOIE9wdGlv biwNCj4gd2hpY2ggd291bGQganVzdCB1bm5lY2Vzc2FyaWx5IGxpbWl0IGZsZXhpYmlsaXR5Lg0K PiA+Pg0KPiA+PiBbbXNdIEkgaGF2ZSBtb3JlIHRob3VnaHQgYWJvdXQgdGhlIGNvdmVydCBjaGFu bmVsIHRoYXQgc29tZSB1bnNwZWNpZmllZA0KPiBieXRlcyBpbiBhIHN0YW5kYXJkcyB0cmFjayBU Q1Agb3B0aW9uIGNvdWxkIG9mZmVy4oCmIEluIHBhcnRpY3VsYXIgaWYgdGhlIEFjY0VDTg0KPiBv cHRpb24gZ2V0cyB3aWRlbHkgZGVwbG95ZWQgYW5kIHVzZWQsIHdvdWxkIHNvbWUgbWFsaWNpb3Vz IHVzZXJzIGZpbmQNCj4gdGhvc2UgYnl0ZXMgdXNlZnVsPyBGb3Igd2hhdD8gRm9yIGluc3RhbmNl LCB3aGF0IGluIHRoZSBBY2NFQ04gcHJvdG9jb2wNCj4gZGVzaWduIHByZXZlbnRzIHVzZSBvZiB0 aGVzZSDigJxwYWRkaW5n4oCdIGJ5dGVzIGFzIHN1cGVyLWNvb2tpZT8gVG8gbWUsIGl0IGlzDQo+ IG11Y2ggbW9yZSBpbXBvcnRhbnQgdG8gdGhpbmsgYWJvdXQgYWJ1c2Ugb2Ygd2hhdGV2ZXIgd2Ug c3RhbmRhcmRpemUNCj4gKm5vdyosIGluc3RlYWQgb2YgZW5naW5lZXJpbmcgZm9yIHNvbWUgZW50 aXJlbHkgdW5rbm93biBmdXR1cmUuIEkgYW0gbm90IGENCj4gc2VjdXJpdHkgZXhwZXJ0LCBidXQg SSBzdWdnZXN0IGEgY2FyZWZ1bCBhbmFseXNpcyBvZiBhbnkgc2VjdXJpdHkgaW1wbGljYXRpb25z IG9mDQo+IHRoZSBBY2NFQ04gb3B0aW9uLiBXZSBzZWxkb21seSBzcGVjaWZ5IG5ldyBUQ1Agb3B0 aW9ucyBhbmQgbWFsaWNpb3VzDQo+IHVzZXJzIHdpbGwgY2VydGFpbmx5IGxvb2sgZm9yIOKAnG9w cG9ydHVuaXRpZXPigJ0gaW4gdGhlIHNwZWMuIFNvIGZhciwgSSBkb27igJl0IGtub3cNCj4gd2hl dGhlciB0aGF0IHdob2xlIGlkZWEgb2YgZm9yd2FyZCBjb21wYXRpYmlsaXR5IGlzIGEgZmVhdHVy ZSBvciBhIGJ1Zy4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gTWljaGFlbA0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+PiBNYXliZSBvbmUgbGVzc29uIGxlYXJudCBpcyB0aGF0IHRoZSBkb2N1bWVudCBj b3VsZCBoYXZlIGEgbm9uLQ0KPiBub3JtYXRpdmUgYXBwZW5kaXggdGhhdCBleHBsYWlucyB0aGUg cmF0aW9uYWxlIGZvciB0aGUgZmluYWxseSBwaWNrZWQgVENQDQo+IG9wdGlvbiBlbmNvZGluZy4g VGhhdCBtYXkgYWxzbyBoZWxwIGlmIHRoZXJlIGFyZSBmdXJ0aGVyIHF1ZXN0aW9ucyB3aGV0aGVy DQo+IHR3byBjb2RlcG9pbnRzIGFyZSByZWFsbHkgcmVxdWlyZWQsIGUuZy4gYnkgdGhlIElFU0cg KGlmIHR3byBjb2RlcG9pbnRzIGFyZQ0KPiBzdGlsbCB0aGUgZGVzaWduIGFmdGVyIFdHTEMpLiBB dCBsZWFzdCBmb3IgcGFzdCBUQ1Agb3B0aW9uIGNvZGVwb2ludCBhbGxvY2F0aW9ucw0KPiBJIHJl Y2FsbCBzb21lIGRpc2N1c3Npb25zIGxhdGUgaW4gdGhlIElFVEYgcHJvY2Vzcy4gSW4gdGhvc2Ug cGFzdCBjYXNlcywgZ29vZA0KPiBhcmd1bWVudHMgaW4gYW4gYXBwZW5kaXggYW5kIHJ1bm5pbmcg Y29kZSBoYXMgaGVscGVkIGEgbG90Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBbQkJdIEkgY2FuIGRvIHRo YXQuIEFwcHggQiBpcyBhbHJlYWR5IHNpbWlsYXIsIGdpdmluZyBEZXNpZ24gUmF0aW9uYWxlIGZv ciB0aGUNCj4gQUNFIGZpZWxkLg0KPiA+Pg0KPiA+Pg0KPiA+PiBCb2INCj4gPj4NCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4NCj4gPj4gTWljaGFlbA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBGcm9tOiBCb2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5l dD4NCj4gPj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTcsIDIwMjAgNjoxMCBBTQ0KPiA+PiBU bzogU2NoYXJmLCBNaWNoYWVsIDxNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU+OyBZb3No aWZ1bWkNCj4gPj4gTmlzaGlkYSA8bnNkLmlldGZAZ21haWwuY29tPg0KPiA+PiBDYzogTWljaGFl bCBUdWV4ZW4gPHR1ZXhlbkBmaC1tdWVuc3Rlci5kZT47IHRjcG0tY2hhaXJzQGlldGYub3JnOw0K PiA+PiBNaXJqYSBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsgU2NoZWZmZW5lZ2dl ciwgUmljaGFyZA0KPiA+PiA8UmljaGFyZC5TY2hlZmZlbmVnZ2VyQG5ldGFwcC5jb20+OyB0Y3Bt IElFVEYgbGlzdCA8dGNwbUBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IEFjY0VDTiBmaWVs ZCBvcmRlcg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBNaWNoYWVsLA0KPiA+Pg0KPiA+PiBPbiAx Ni8xMS8yMDIwIDE3OjM2LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6DQo+ID4+DQo+ID4+IEJvYiwN Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT25lIHByb3Bvc2FsIHVzaW5nIHRoZSBsZW5ndGggZmll bGQgd2l0aCAqb25lIG9wdGlvbiBjb2RlcG9pbnQgb25seSoNCj4gPj4gaXMgZGV0YWlsZWQgaW46 DQo+ID4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGNwbS96by0NCj4g MU9SMG5SZmhIb2NYOHl2VHZwQzRCTk1vDQo+ID4+IC8NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4g SXQgaXMgdGhlIHRoaXJkIG9wdGlvbiBtZW50aW9uZWQgaW4gdGhpcyBlLW1haWwuIE9uZSBleGFt cGxlIHdvdWxkIGJlIHRvDQo+IHVzZSBvcHRpb24gbGVuZ3RoIHZhbHVlcyA1LzgvMTEgZm9yIG9u ZSBlbmNvZGluZyB0eXBlIGFuZCBvcHRpb24gbGVuZ3RoDQo+IHZhbHVlcyA2LzkvMTIgZm9yIHRo ZSBvdGhlciBlbmNvZGluZyB0eXBlIChpLmUuLCBvcmRlciBvZiBmaWVsZHMpLiBPciBvbmUgY291 bGQNCj4gdXNlIHNvbWUgb3RoZXIgY29tYmluYXRpb24gb2YgbGVuZ3RoIHZhbHVlcyDigJMgdGhl IG9ubHkgcmVxdWlyZW1lbnQgaXMgdGhhdCBhDQo+IGNlcnRhaW4gdmFsdWUgZm9yIHRoZSBvcHRp b24gbGVuZ3RoIGlzIG9ubHkgdXNlZCBieSBvbmUgb2YgdGhlIG9wdGlvbiBmb3JtYXRzLg0KPiBJ biB0aGF0IGFwcHJvYWNoLCB0aGUgdmFsdWUgb2YgdGhlIGxlbmd0aCBmaWVsZCB3b3VsZCB0aHVz IGRpcmVjdGx5IGRlc2NyaWJlDQo+IHRoZSBlbmNvZGluZyBvZiB0aGUgb3B0aW9uLiBVbmxlc3Mg SSBtaXNzIHNvbWV0aGluZywgdGhpcyB3b3VsZCB3b3JrIGFuZCBpdA0KPiB3b3VsZCBqdXN0IHJl cXVpcmUgb25lIG9wdGlvbiBjb2RlcG9pbnQuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFRodXMs IGFsdGVybmF0aXZlcyB0byB0d28gb3B0aW9uIGNvZGVwb2ludHMgZXhpc3QgYW5kIEkgaGF2ZSBl eHBsYWluZWQNCj4gdGhlbSBvbiB0aGUgbGlzdCBpbiBNYXJjaCAyMDIwLg0KPiA+Pg0KPiA+Pg0K PiA+PiBPSywgc29ycnksIHllcywgSSByZW1lbWJlciB0aGlzIG5vdy4NCj4gPj4NCj4gPj4gQXMg SSB3aWxsIGV4cGxhaW4gaW4gdGhlIEFjY0VDTiBzdGF0dXMgdXBkYXRlIHRhbGsgdG9kYXkgaW4g dmlydHVhbCBCYW5na29rLA0KPiB0aGUgZHJhZnQgaGFzIG1hZGUgcHJvdmlzaW9uIGZvciBkaWZm ZXJlbnQgbGVuZ3RoIHZhbHVlcyB0aGFuIDUvOC8xMS4gSXQgc2F5cw0KPiBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMgTVVTVCBhY2NlcHQgbGVuZ3RoIHZhbHVlcyBvdGhlciB0aGFuIHRob3NlDQo+ IGN1cnJlbnRseSBkZWZpbmVkLiBCdXQgdGhlbiByZWFkIGluIGFzIG1hbnkgd2hvbGUgMy1ieXRl IGZpZWxkcyBhcyB0aGV5IGNhbi4NCj4gPj4NCj4gPj4gVGhpcyBjYW4gYmUgdXNlZCB0byBhZGQg YSBmbGFncyBieXRlIG9uIHRoZSBlbmQgaW4gZnV0dXJlLCBmb3IgZXh0ZW5zaWJpbGl0eS4NCj4g T3IgYW55IG90aGVyIGZvcm0gb2YgZXh0ZW5zaWJpbGl0eSB0aGUgV0cgbWlnaHQgZGVjaWRlIGlu IHRoZSBmdXR1cmUuDQo+ID4+DQo+ID4+IEkga25vdyBhIGZsYWdzIGJ5dGUgYXQgdGhlIGVuZCBz ZWVtcyBvZGQgY29tcGFyZWQgdG8gYXQgdGhlIGJlZ2lubmluZy4NCj4gQnV0IChpZiBkZWNpZGVk IGl0J3MgbmVlZGVkIGluIGZ1dHVyZSkgaXQncyByZWFzb25hYmx5IGVhc3kgdG8gaW1wbGVtZW50 IGJ5DQo+IHJlYWRpbmcgdGhlIHdob2xlIG9wdGlvbiwgdGhlbiBwcm9jZXNzaW5nIHRoZSBsYXN0 IGJ5dGUsIGJlZm9yZSByZWFkaW5nIHRoZQ0KPiByZXN0IG9mIHRoZSBvcHRpb24uDQo+ID4+DQo+ ID4+IEkgYmVsaWV2ZSB5b3Ugd2lsbCBhZ3JlZSB0aGF0IHRoaXMgaXMgYSBiZXR0ZXIgd2F5IHRv IHV0aWxpemUgZGlmZmVyZW50IGxlbmd0aHMuDQo+ID4+DQo+ID4+IEFuZCB0aGFuayB5b3UgZm9y IHJlcGVhdGVkbHkgZW1waGFzaXppbmcgdGhhdCB5b3UncmUgaGFwcHkgd2l0aCB0aGUgMi0NCj4g a2luZCBzY2hlbWUsIG9yIG90aGVyIGFsdGVybmF0aXZlcy4NCj4gPj4NCj4gPj4NCj4gPj4gQm9i DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEFueXdheSwgSSBkb27i gJl0IHJlYWxseSBjYXJlIGhvdyB0aGUgb3B0aW9ucyBhcmUgZW5jb2RlZCBhcyBsb25nIGFzIHRo ZQ0KPiByZWNlaXZlciBkb2VzbuKAmXQgbmVlZCBwZXItY29ubmVjdGlvbiBzdGF0ZSBmb3IgZGVj b2RpbmcgYSBUQ1Agb3B0aW9uLiBTbywNCj4gcGVyc29uYWxseSwgSSB3b3VsZCBiZSBmaW5lIHdp dGggdXNpbmcgZS5nLiB0aGUgbGVuZ3RoIGZpZWxkIGFzIGRlc2NyaWJlZCBpbiBteQ0KPiBvbGQg ZS1tYWlsLiBPciBhbiBhZGRpdGlvbmFsIGZsYWcgYnl0ZS4gQW5kIG9uZSBjb3VsZCBjb21lIHVw IHdpdGggZnVydGhlcg0KPiBlbmNvZGluZ3MsIGUuZy4sIGJ5IHVzaW5nIG9uZSBvciBhIGZldyBi aXRzIGFzIGEgc2hvcnQg4oCcdHlwZeKAnSBmaWVsZCBmb3IgZWFjaA0KPiBjb3VudGVyLiBUaGlz IGlzIGFsbCBhYm91dCBwcm90b2NvbCBlbmdpbmVlcmluZy4gQW5kIGFsbCB0aGVzZSB2YXJpYW50 cyBoYXZlDQo+IHRoZWlyIHByb3MgYW5kIGNvbnMuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEkg YW0gYWxzbyBmaW5lIHdpdGggdXNpbmcgdHdvIG9wdGlvbiBjb2RlcG9pbnRzIGFzIHNwZWNpZmll ZCBpbiAtMTM7IHRoaXMgaXMNCj4gcHJvYmFibHkgdGhlIGFwcHJvYWNoIHRoYXQgY29uc3VtZXMg dGhlIGxlYXN0IG51bWJlciBvZiBiaXRzLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBNaWNoYWVs ICh3L28gYW55IGhhdCkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4gRnJvbTogQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5uZXQ+DQo+ID4+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMTYsIDIwMjAgNTo1MiBQTQ0KPiA+PiBUbzogWW9zaGlmdW1pIE5p c2hpZGEgPG5zZC5pZXRmQGdtYWlsLmNvbT4NCj4gPj4gQ2M6IFNjaGFyZiwgTWljaGFlbCA8TWlj aGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgTWljaGFlbCBUdWV4ZW4NCj4gPj4gPHR1ZXhl bkBmaC1tdWVuc3Rlci5kZT47IHRjcG0tY2hhaXJzQGlldGYub3JnOyBNaXJqYSBLdWVobGV3aW5k DQo+ID4+IDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsgU2NoZWZmZW5lZ2dlciwgUmljaGFyZA0KPiA+ PiA8UmljaGFyZC5TY2hlZmZlbmVnZ2VyQG5ldGFwcC5jb20+OyB0Y3BtIElFVEYgbGlzdCA8dGNw bUBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogQWNjRUNOIGZpZWxkIG9yZGVyDQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+IFlvc2hpLCAoYWRkaW5nIHRoZSB0Y3BtIGxpc3QgaW4gY2MpDQo+ID4+DQo+ ID4+IE9uIDA1LzExLzIwMjAgMDY6NTgsIFlvc2hpZnVtaSBOaXNoaWRhIHdyb3RlOg0KPiA+Pg0K PiA+PiBIaSBCb2IsDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIFdlZCwgTm92IDQsIDIwMjAg YXQgMzoyOSBQTSBCb2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD4NCj4gd3JvdGU6DQo+ ID4+DQo+ID4+IFlvc2hpLA0KPiA+Pg0KPiA+PiBPbiAwNC8xMS8yMDIwIDA2OjUxLCBZb3NoaWZ1 bWkgTmlzaGlkYSB3cm90ZToNCj4gPj4NCj4gPj4gSGksIGZvbGtzLA0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBJbiBteSB1bmRlcnN0YW5kaW5nLCBJJ20gbm90IHN1 cmUgaWYgd2Ugc2V0dGxlZCBkb3duIG9uIHVzaW5nIHR3byBvcHRpb24NCj4ga2luZHMgb3IgZW5j b2Rpbmcgc2NoZW1lcyBmb3IgMjRiaXRzIGZpZWxkcyBpbiBhY2MgZWNuIGRyYWZ0Lg0KPiA+Pg0K PiA+PiBTbywgSSB0aGluayB0aGVyZSdyZSBzdGlsbCBzb21ldGhpbmcgdG8gYmUgY2xhcmlmaWVk IGFuZCBob3BlIHRoaW5ncyB3aWxsIGJlDQo+IHNldHRsZWQgYXQgdGhlIG1lZXRpbmcuDQo+ID4+ DQo+ID4+DQo+ID4+IFtCQl0gSSBrbm93IGEgV0cgY2FuIGNoYW5nZSBpdCdzIG1pbmQgYXQgYW55 IHRpbWUuIEJ1dCBJJ2QgcmF0aGVyIHdlIGp1c3QNCj4gY2xhcmlmaWVkIHdoYXQgYSBwcmV2aW91 cyBkZWNpc2lvbiB3YXMsIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGtlZXAgcmUtb3BlbmluZw0KPiBk aXNjdXNzaW9uIG9uIGEgcXVlc3Rpb24gdGhhdCBoYXZlIGJlZW4gZGVjaWRlZCB0aGVuIGNoYW5n ZWQgdGhyZWUNCj4gZGlmZmVyZW50IHdheXMgYWxyZWFkeS4NCj4gPj4NCj4gPj4gTXkgbWVtb3J5 IGlzIG5vdCBzbyBnb29kIHRoZXNlIGRheXMuIEkgdHJ1c3RlZCB0aGF0IE1pY2hhZWwgUw0KPiBy ZW1lbWJlcmVkIHRoZSBkZWNpc2lvbiBjb3JyZWN0bHksIGFuZCBJIHNlZW0gdG8gcmVtZW1iZXIg dGhhdCBkZWNpc2lvbg0KPiBiZWluZyBtYWRlLg0KPiA+PiBJJ3ZlIGp1c3QgY2hlY2tlZCB0aGUg bWludXRlcyBvZiB0aGUgbGFzdCBpbnRlcmltOg0KPiA+Pg0KPiA+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9taW51dGVzLWludGVyaW0tMjAyMC10Y3BtLTAxLTIwMjAwNDI5DQo+ ID4+IDE2MDAvIGFuZCB0aGV5IG1lbnRpb24gTWljaGFlbCdzIHByb3Bvc2FsIHRvIHVzZSB0d28g a2luZHMsIGJ1dCBkb24ndA0KPiA+PiByZWNvcmQgYW55IGRlY2lzaW9uLg0KPiA+PiBUaGUgamFi YmVyIGxvZyBnaXZlcyBubyBjbHVlcyBhYm91dCBhbnkgZGVjaXNpb24uDQo+ID4+DQo+ID4+IEkg Y2FuJ3QgZmluZCBhbiBhdWRpbyBvciB2aWRlbyByZWNvcmRpbmcuIENhbiB5b3UgcG9pbnQgbWUg YXQgb25lPw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBJIHRob3VnaHQgdGhhdCBpdCdzIGJlY2F1 c2UgdGhlcmUgd2FzIG5vIGNsZWFyIGRlY2lzaW9uIGF0IHRoZSBtZWV0aW5nLg0KPiA+Pg0KPiA+ PiBCdXQsIHlvdSBjYW4gY2hlY2sgaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1Lc0Iw X05iOC1rQQ0KPiA+Pg0KPiA+PiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IHF1 ZXN0aW9ucyBvciBvcGluaW9ucyB3aXRoIHJlZ2FyZCB0bw0KPiB0aGlzLg0KPiA+Pg0KPiA+Pg0K PiA+PiBbQkJdIEkgY2hlY2tlZCB0aGUgWW91dHViZSBsaW5rIHlvdSBzZW50IGJlbG93Lg0KPiA+ Pg0KPiA+PiBGaXJzdCBJIHRoaW5rIHdlJ3JlIGFncmVlZCBuby1vbmUgd2FzIGZpZ2h0aW5nIGZv ciB1cyB0byBrZWVwIHRoZSBwcmV2aW91cw0KPiB3YXkgd2UgZGlkIHRoaXMgKHVzaW5nIHRoZSBp bml0aWFsIHZhbHVlIG9mIHRoZSBmaWVsZCB0byBzZXQgdGhlIG9yZGVyIGZvciB0aGUNCj4gY29u bmVjdGlvbikuDQo+ID4+IEluIG15IHByZXNlbnRhdGlvbiBJIHNhaWQgdGhlcmUgd2FzIHN0cm9u ZyByZXNpc3RhbmNlIGZyb20gTWljaGFlbCB0byBkbyBpdA0KPiBhIGRpZmZlcmVudCB3YXkuDQo+ ID4+IChhbHNvLCBvZmZsaXN0LCB0aGUgY28tYXV0aG9ycyBpbmNsdWRpbmcgbWUgYWxzbyBkaWRu J3QgbGlrZSB0aGlzIHNvDQo+ID4+IG11Y2guIEFuZCBJbHBvIHNhaWQgaXQgbWFkZSB0aGUgaW1w bGVtZW50YXRpb24gY29tcGxleC4pDQo+ID4+DQo+ID4+IFRoZW4gY2FtZSB0aGUgcXVlc3Rpb24g b2Ygd2hhdCB3ZSBkbyBpbnN0ZWFkLiBUaGVyZSB3ZXJlIHRocmVlDQo+IGFsdGVybmF0aXZlIHBy b3Bvc2FsczoNCj4gPj4gYSkgdXNlIDIgb3B0aW9uIGtpbmRzDQo+ID4+IGIpIGFkZCBhIGZsYWdz IGJ5dGUNCj4gPj4gYykgc29tZWhvdyB1c2UgdGhlIGxlbmd0aCBmaWVsZCBtYXliZQ0KPiA+Pg0K PiA+PiBNaWNoYWVsIHJhaXNlZCAoYykgaW4gdGhlIG1lZXRpbmcgYXMgYSBwb3NzaWJpbGl0eSwg YnV0IG5vLW9uZSBjb3VsZCB0aGluaw0KPiBob3cgdG8gZGlzdGluZ3Vpc2ggdHdvIG9wdGlvbnMg b2YgdGhlIHNhbWUgbGVuZ3RoIGJ1dCBhIGRpZmZlcmVudCBmaWVsZCBvcmRlcg0KPiB1c2luZyB0 aGUgbGVuZ3RoIGZpZWxkLiBNaWNoYWVsIHNhaWQgaGUnZCBwb3N0IGFueSBpZGVhcyB0byB0aGUg bGlzdCBpZiBoZSBjb3VsZA0KPiB0aGluayBvZiBhbnksIGJ1dCB0aGF0IGRpZG4ndCBoYXBwZW4u DQo+ID4+DQo+ID4+IFNvIHdlJ3JlIGxlZnQgY2hvb3NpbmcgYmV0d2VlbiAoYSkgYW5kIChiKS4N Cj4gPj4gSSBzYWlkIGluIHRoZSBtZWV0aW5nIChhbmQgb24gdGhlIGxpc3Qgd2hlbiBkaXNjdXNz aW5nIHdpdGggSWxwbykgdGhhdCBJJ2QgYmUNCj4gaGFwcHkgdG8gZ28gd2l0aCAoYiksIGJ1dCBv bmx5IGlmIHRoZXJlIHdhcyBhbm90aGVyIHVzZSBmb3IgYSBmbGFnLiBCZWNhdXNlIGl0DQo+IHdv dWxkIGNvbnN1bWUgMUIgbW9yZSBvcHRpb25zIHNwYWNlIGluIG1hbnkgcGFja2V0cywgd2hpY2gg aXMgYSBzY2FyY2UNCj4gcmVzb3VyY2UuDQo+ID4+DQo+ID4+IElscG8gaGFkIGEgcHJvcG9zZWQg dXNlIGZvciBhbm90aGVyIGZsYWcgKHRvIGhlbHAgc3luY2ggY291bnRlcnMgYWZ0ZXIgYQ0KPiBs b3NzKSwgYnV0IEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gYWJvdXQgaXQgZW5kZWQgdGhhdCBpdCB3 b3VsZG4ndCBiZSBoZWxwZnVsLCAnY29zDQo+IHRoZSB3YXkgaXQgd29ya2VkIGRlcGVuZGVkIG9u IGl0c2VsZiAoY2lyY3VsYXIgbG9naWMpLg0KPiA+Pg0KPiA+PiBJbiBjb25jbHVzaW9uLCBJIGRv bid0IHRoaW5rIHRoZXJlIHdhcyBhbiBleHBsaWNpdCBkZWNpc2lvbiB0byBnbyB3aXRoIDINCj4g b3B0aW9uIGtpbmRzLCBidXQgaXQgZW5kZWQgdXAgYXMgdGhlICdsYXN0IHBlcnNvbiBzdGFuZGlu ZycuDQo+ID4+IEkgbGlrZSBpdC4gSXQncyBzaW1wbGUuIEFuZCBhcHBhcmVudGx5IG9wdGlvbiBr aW5kcyBhcmUgbm90IHN1Y2ggYSBzY2FyY2UNCj4gcmVzb3VyY2UuDQo+ID4+DQo+ID4+IFBlcmhh cHMgd2UgY2FuIHJhdGlmeSB0aGlzIGluIHRoZSBXRyB0b21vcnJvdy4NCj4gPj4NCj4gPj4NCj4g Pj4gQm9iDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFRo YW5rcywNCj4gPj4NCj4gPj4gLS0NCj4gPj4NCj4gPj4gWW9zaGkNCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX18NCj4gPj4gQm9i IEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2Uu bmV0Lw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLQ0KPiA+Pg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19f Xw0KPiA+PiBCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8v Ym9iYnJpc2NvZS5uZXQvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g X19fX19fDQo+ID4+IEJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0 dHA6Ly9ib2JicmlzY29lLm5ldC8NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPj4gdGNwbUBpZXRm Lm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4g DQo+IC0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gX19fX19fDQo+IEJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K From nobody Tue Feb 9 11:30:35 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD9B3A1196; Tue, 9 Feb 2021 11:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV_w52M24JAb; Tue, 9 Feb 2021 11:30:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A27AC3A1193; Tue, 9 Feb 2021 11:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612898982; bh=dSBTs4xEv6MutSuRhxv1iPHhxY6wvGOH/j70dez9i+E=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jUmMhAsEo2J79vOrRkLq0kMFVBHnCPSWSEEwSte3OgHfLp5sCQPD/UCzyzfjkMy5t LKr5DwpTeOwPDOwWjmW3A2dbRRgjLwSgFIgehIqf6AjHZYvuK9FxKfUGwBHbpDJJ+O 8oC8us+nwShncXanN67Yi1ZAjJVATyh3arhzTKFk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.129.138]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLi8g-1lR5aY2HGi-00HbeD; Tue, 09 Feb 2021 20:29:42 +0100 To: Bob Briscoe Cc: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org References: <391747b3-b513-1063-ba6a-5011d5ef0b0c@bobbriscoe.net> From: "Scheffenegger, Richard" Message-ID: <9e2d2db1-d93f-1ffb-770c-4c23d7388b50@gmx.at> Date: Tue, 9 Feb 2021 20:29:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <391747b3-b513-1063-ba6a-5011d5ef0b0c@bobbriscoe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:67Z/OCIBIdHOBxgesJelwZ8eqWuEIaH/dJque49u6rPF39fAAOG 3x53Xqti1WfBv9T3JN6UotxEdyvfxZCdIKZIhaoQNITqKzHH0bXKD5Uije9Yqh25rYM4djb eNSrji+KfsjRxOHYZqz+prdtWYpdSwEQwJmrAtFUSUfJ780D/EQmpKtMONjx/SWMRmiHoYZ EJQ65KXY3JEORBJAPr/Lg== X-UI-Out-Filterresults: notjunk:1;V03:K0:4aMPd3gCFho=:qdCyM4jeCPVQERPU2ROq1a uQBuw7YkMAy4p0APGP3oWzlt24Mn89r8kWqWSLAygfEmi/XR/Psjn5RsGVQ0A2HB1U1a8PU7x IAU7Nxl9ZcoQDxJrCrLsbmRFmpUM+AW1pLBkc7X6NXroIifLPHWYpDYGjsFN7bHiKoemZ0+1I gwe/Hh/P//aq/fuFj04Omli/2O24kY+9ym9tVPBj/AuX9AlTdVWse7FnrkxUk7F+XtIMkU5S6 L2Gl0vwc1mU9hxOcqUz604Kxxa4npDZ/1qQcS6pRaB9nH5CbK0oH86fVhamDQBNc87POZUrmJ mOWIQQQBIcEIWOtwLgpiYPGApAvvnSSGS4NmtJzmtnNElL7cnom6PDqDNcv9QJCN+JeIfPbeq 0Gzg193wQzv7ExysAh5VOImP9+5g8COwYhUoKV2GHNcirLHbM0DZ2tKdPksEn+mmTVL22iYNs vlEYchjm/aH7PMSlfIQ7ACh1mmhY8NLp38ofIr+11f484csvrqrrmegMkdNob8A+liJt6FNz5 rPuj7VlUg+2csbsZS31R8A1CdLBHXYwm+WJ0gNXu4Jx++qb799DyDEP0FMjOz+20OAmV8kIQy NyVJ0Xtej5IxfLM93ywQ1ibuP2xKCIHRL1tuHI+9teNlJHuTSBu4vfR9diNIwqUI7t+a7dwxI 13c5q8ZiOj6sijqXuhRP9pqA/jhbl3Im0jc+7jcPr5V1nooXlL1q/FWnTqTz6fYtzazrzKCD+ fKUPX6seCSpLHre+yUptPpyu+bTsU556b4R2SzHQy12HRZMvQOTJ0LeFzm9HmVL0OnHZj3brd S8n5IQRuMaRy7gytNMucIZwLL8yYqsZHW5qSGq2IeIHgqNWqMXIMKXVXvGI2KpSi75m/ds/9F hCwx2xonfHdqGwlVKeTQ== Archived-At: Subject: Re: [tcpm] ECN++ control packet handling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 19:30:34 -0000 Sounds good to me! Thanks for the quick turnaround! Best regards, Richard Am 09.02.2021 um 16:48 schrieb Bob Briscoe: > Richard, > > Good point. Thanks for noticing this potential implementation pit-fall. > > In my local copy of the ECN++ draft I have added the following to the > end of "3.2.6 RST (Send)": > > + Implementers SHOULD ensure that RST packets (and control packets > > + generally) are always sent out with the same ECN field regardless of > > + the TCP state machine. Otherwise the ECN field could reveal internal > > + TCP state. For instance, the ECN field on a RST ought not to reveal > > + any distinction between a non-listening port, a recently in-use > > + port, and a closed session port. > > And I've added this to the end of Security Considerations: > > + Section 3.2.6 on sending TCP RSTs points out > > + that implementers need to take care to ensure that the ECN field on a > > + RST does not depend on TCP's state machine. Otherwise the internal > > + information revealed could be of use to potential attackers. This poin= t > > + applies more generally to all control packets, not just RSTs. > > Do you think that's correct / sufficient? > > Cheers > > Bob > > On 08/02/2021 21:03, Scheffenegger, Richard wrote: >> Hi Bob, Marcelo, >> >> While working on the ecn++ code for fbsd patch, I found that the >> codepath for dealing with out-of-window, past-established and >> non-listening ports is actually quite different there. >> >> Casually glancing over the draft for ecn++, I didn=E2=80=99t find a ref= erence >> specifically about the handling of RST (non-listening port, vs. closing >> session etc). >> >> This may need a hint in the security section, that an implementation >> should ensure, that control packets are always sent out with similar >> headers, regardless of the TCP state machine. Otherwise, you could >> potentially leak information (eg. Recently in-use ports) which may be a >> clue to malicious players=E2=80=A6 >> >> >> Richard Scheffenegger >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > From nobody Tue Feb 9 17:14:23 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5590E3A1118 for ; Tue, 9 Feb 2021 17:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl9e3PBFUgah for ; Tue, 9 Feb 2021 17:14:19 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A6D3A1116 for ; Tue, 9 Feb 2021 17:14:18 -0800 (PST) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Db1sN5Fxxz67lyl; Wed, 10 Feb 2021 09:10:32 +0800 (CST) Received: from fraeml795-chm.china.huawei.com (10.206.15.16) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Feb 2021 02:14:12 +0100 Received: from fraeml795-chm.china.huawei.com (10.206.15.16) by fraeml795-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Feb 2021 02:14:12 +0100 Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by fraeml795-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 10 Feb 2021 02:14:12 +0100 Received: from DGGEMM514-MBS.china.huawei.com ([169.254.3.180]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0509.000; Wed, 10 Feb 2021 09:14:04 +0800 From: Kangjiao To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" CC: Liangqiandeng Thread-Topic: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt Thread-Index: AQHW+fwAzocl9W3Fpky4agCZWo0PP6pQnyjQ Date: Wed, 10 Feb 2021 01:14:04 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> References: <161233469809.31214.294457730576935197@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.102.89] Content-Type: multipart/alternative; boundary="_000_719A2C1D4AC73847B6E1BF21DF1545EAE5E77372dggemm514mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 01:14:21 -0000 --_000_719A2C1D4AC73847B6E1BF21DF1545EAE5E77372dggemm514mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNCkkgd3JvdGUgYSBkcmFmdCB0byBwcm9wb3NlIGFuIGlkZWEgZm9yIE1QVENQ IHN1YnR5cGUgY2FwYWJpbGl0eSBleGNoYW5nZSBkdXJpbmcgTVBUQ1AgaGFuZHNoYWtlLiAgV2Ug dGhpbmssIGluIE1QVENQLCBzb21lIG9wdGlvbnMgYXJlIG1hbmRhdG9yeSBidXQgc29tZSBvcHRp b25zIGNhbiBiZSBzZXQgYXMgb3B0aW9uYWwgb25lcy4gU28gYW4gZXhjaGFuZ2UgbWVjaGFuaXNt IG9mIGFjdHVhbCBjYXBhYmlsaXR5IGJldHdlZW4gYm90aCBwYXJ0aWVzIGFyZSBuZWVkZWQuDQoN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWth bmctdGNwbS1zdWJ0eXBlLWNhcGFiaWxpdHktZXhjaGFuZ2UtMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2FuZy10Y3BtLXN1YnR5 cGUtY2FwYWJpbGl0eS1leGNoYW5nZS8NCkh0bWw6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWthbmctdGNwbS1zdWJ0eXBlLWNhcGFiaWxpdHktZXhjaGFu Z2UtMDAuaHRtbA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1rYW5nLXRjcG0tc3VidHlwZS1jYXBhYmlsaXR5LWV4Y2hhbmdlLTAwDQoNCldoZW4gSSBy ZWFkIHlvdXIgZHJhZnQsIEkgdGhpbmsgbWF5YmUgb3VyIGFib3ZlIHdvcmsgaGF2ZSBzb21lIHJl bGV2YW5jZSB0byB5b3VyIHN1Z2dlc3Rpb25zLiBJZiB5b3UgdGhpbmsgaXQnbGwgaGVscCB3aXRo IHRoaXMgd29yaywgSSBob3BlIHdlIGNhbiBkaXNjdXNzIHRoaXMgbmV3IG5lZ290aWF0aW9uIG1l Y2hhbmlzbSBmb3IgcmVsYXRlZCBvcHRpb25zIGFuZCBzdWJ0eXBlcy4gVGhhbmtzDQoNCkJlc3Qg d2lzaGVzLA0KSmlhbw0KDQpGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5pc2hpZGENClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMywgMjAyMSAzOjEyIFBNDQpUbzogdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIDx0Y3BtQGll dGYub3JnPg0KU3ViamVjdDogW3RjcG1dIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtbmlzaGlkYS10 Y3BtLWFnZy1zeW4tZXh0LTAwLnR4dA0KDQpIaSBmb2xrcywNCg0KSSBwcmVwYXJlZCBhIGRyYWZ0 IGZvciBTWU4gb3B0aW9uIHNwYWNlIGV4dGVuc2lvbnMuDQpJIGtub3cgdGhpcyBpcyBhIGRpZmZp Y3VsdCBpc3N1ZSBpbiBUQ1AgYW5kIGhhcyBiZWVuIGRpc2N1c3NlZCBmb3IgYSBsb25nIHRpbWUu DQpCdXQsIEknbSB0aGlua2luZyB0aGF0IGl0IG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIGRpc2N1 c3MgaXQgYWdhaW4uDQoNCktleSBpZGVhcyBvZiB0aGUgZHJhZnQgYXJlIHRoZSBmb2xsb3dpbmdz Lg0KMTogZHJhc3RpYyBjaGFuZ2VzIGluIFRDUCdzIHNwZWMgd2lsbCBub3QgYmUgcmVxdWlyZWQN CiAgICAoaXQgZG9lcyBub3QgcmVxdWlyZSB1cGRhdGluZyBUQ1AgaGVhZGVyIGZvcm1hdCBub3Ig dXNpbmcgbXVsdGlwbGUgU1lOIHBhY2tldHMgb3IgYWRkaXRpb25hbCBTWU4tbGlrZSBwYWNrZXRz KQ0KMjogdXRpbGl6ZSB0aGUgb3B0aW9uIG5lZ290aWF0aW9uIHNjaGVtZXMgaW4gbXB0Y3AgZm9y IGdlbmVyaWMgcHVycG9zZXMuIHNvLCBJIHRoaW5rIGl0IGNhbiBiZSBjb25zaWRlcmVkIG1pZGRs ZWJveCBmcmllbmRseS4NCjM6IGl0IGhhcyBzb21lIGxpbWl0YXRpb25zIChlLmcgaXQgY2FuIG9u bHkgZXh0ZW5kIGFyb3VuZCAzMC00MCBieXRlcyBmb3IgU1lOIG9wdGlvbiBzcGFjZSkuIEJ1dCwg aWYgaXQncyBjb21iaW5lZCB3aXRoIEVETywgd2UgY2FuIHVzZSBtb3JlIG9wdGlvbiBzcGFjZS4N CiAgICAoZGVwZW5kcyBvbiBob3cgRURPIGRyYWZ0IHdpbGwgcHJvZ3Jlc3MsIHRob3VnaCkNCg0K UGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgb3IgY29tbWVudHMg b3Igc3VnZ2VzdGlvbnMuDQoNClRoYW5rIHlvdSBzbyBtdWNoIQ0KLS0NCllvc2hpDQoNCg0KLS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBUdWUs IEZlYiAyLCAyMDIxIGF0IDEwOjQ1IFBNDQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1uaXNo aWRhLXRjcG0tYWdnLXN5bi1leHQtMDAudHh0DQpUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZzxt YWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPj4NCg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEFnZ3JlZ2F0ZWQgT3B0aW9uIGZvciBT WU4gT3B0aW9uIFNwYWNlIEV4dGVuc2lvbg0KICAgICAgICBBdXRob3IgICAgICAgICAgOiBZb3No aWZ1bWkgTmlzaGlkYQ0KICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1uaXNoaWRhLXRj cG0tYWdnLXN5bi1leHQtMDAudHh0DQogICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE0DQogICAg ICAgIERhdGUgICAgICAgICAgICA6IDIwMjEtMDItMDINCg0KQWJzdHJhY3Q6DQogICBUQ1Agb3B0 aW9uIHNwYWNlIGlzIHNjYXJjZSByZXNvdXJjZSBhcyBpdHMgbWF4IGxlbmd0aCBpcyBsaW1pdGVk IHRvDQogICA0MCBieXRlcy4gIFRoaXMgbGltaXRhdGlvbiBiZWNvbWVzIG1vcmUgc2lnbmlmaWNh bnQgaW4gU1lOIHNlZ21lbnRzDQogICBhcyBhbGwgb3B0aW9ucyB1c2VkIGluIGEgY29ubmVjdGlv biBzaG91bGQgYmUgZXhjaGFuZ2VkIGR1cmluZyBTWU4NCiAgIG5lZ290aWF0aW9ucy4gIFRoaXMg ZG9jdW1lbnQgcHJvcG9zZXMgYSBuZXcgU1lOIG9wdGlvbiBuZWdvdGlhdGlvbg0KICAgc2NoZW1l IHRoYXQgcHJvdmlkZSBhIGZlYXR1cmUgdG8gY29tcHJlc3MgVENQIG9wdGlvbnMgaW4gU1lOIHNl Z21lbnRzDQogICBhbmQgcHJvdmlkZSBtb3JlIG9wdGlvbiBzcGFjZS4gIFRoZSBwcm9wb3NlZCBz Y2hlbWUgZG9lcyBub3QgdXBkYXRlDQogICB0aGUgZm9ybWF0IG9mIFRDUCBoZWFkZXIgbm9yIHRy YW5zbWl0IGFueSBhZGRpdGlvbmFsIFNZTiBvciBTWU4tbGlrZQ0KICAgc2VnbWVudHMgc28gdGhh dCBpdCBoYXMgbG93ZXIgcmlza3MgZm9yIG1pZGRsZWJveCBpbnRlcnZlbnRpb25zLiAgSW4NCiAg IGFkZGl0aW9uLCBieSBjb21iaW5pbmcgYW5vdGhlciBwcm9wb3NhbCBmb3Igb3B0aW9uIHNwYWNl IGV4dGVuc2lvbiwNCiAgIGl0IGlzIHBvc3NpYmxlIHRvIHByb3ZpZGUgZnVydGhlciBvcHRpb24g c3BhY2UuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXNoaWRhLXRj cG0tYWdnLXN5bi1leHQvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWls YWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXNoaWRhLXRjcG0t YWdnLXN5bi1leHQtMDANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtbmlzaGlkYS10Y3BtLWFnZy1zeW4tZXh0LTAwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0 Zi5vcmc8bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmll czogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0Kb3IgZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg== --_000_719A2C1D4AC73847B6E1BF21DF1545EAE5E77372dggemm514mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgWW9zaGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd3JvdGUgYSBk cmFmdCB0byBwcm9wb3NlIGFuIGlkZWEgZm9yIE1QVENQIHN1YnR5cGUgY2FwYWJpbGl0eSBleGNo YW5nZSBkdXJpbmcgTVBUQ1AgaGFuZHNoYWtlLiZuYnNwOyBXZSB0aGluaywgaW4gTVBUQ1AsIHNv bWUgb3B0aW9ucyBhcmUgbWFuZGF0b3J5DQogYnV0IHNvbWUgb3B0aW9ucyBjYW4gYmUgc2V0IGFz IG9wdGlvbmFsIG9uZXMuIFNvIGFuIGV4Y2hhbmdlIG1lY2hhbmlzbSBvZiBhY3R1YWwgY2FwYWJp bGl0eSBiZXR3ZWVuIGJvdGggcGFydGllcyBhcmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5VUkw6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQta2FuZy10Y3BtLXN1 YnR5cGUtY2FwYWJpbGl0eS1leGNoYW5nZS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2FuZy10Y3BtLXN1 YnR5cGUtY2FwYWJpbGl0eS1leGNoYW5nZS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pkh0bWw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQta2FuZy10Y3Bt LXN1YnR5cGUtY2FwYWJpbGl0eS1leGNoYW5nZS0wMC5odG1sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthbmctdGNwbS1zdWJ0eXBlLWNhcGFi aWxpdHktZXhjaGFuZ2UtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hlbiBJIHJlYWQgeW91ciBkcmFmdCwgSSB0 aGluayBtYXliZSBvdXIgYWJvdmUgd29yayBoYXZlIHNvbWUgcmVsZXZhbmNlIHRvIHlvdXIgc3Vn Z2VzdGlvbnMuIElmIHlvdSB0aGluayBpdCdsbCBoZWxwIHdpdGggdGhpcyB3b3JrLCBJIGhvcGUg d2UgY2FuDQogZGlzY3VzcyB0aGlzIG5ldyBuZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9yIHJlbGF0 ZWQgb3B0aW9ucyBhbmQgc3VidHlwZXMuIFRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IHdpc2hlcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppYW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Zb3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDMsIDIwMjEgMzoxMiBQTTxicj4NCjxiPlRvOjwv Yj4gdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zICZsdDt0Y3BtQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBbdGNwbV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1uaXNoaWRhLXRjcG0t YWdnLXN5bi1leHQtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkg cHJlcGFyZWQgYSBkcmFmdCBmb3IgU1lOIG9wdGlvbiBzcGFjZSBleHRlbnNpb25zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIGtub3cgdGhpcyBpcyBhIGRpZmZpY3VsdCBpc3N1ZSBpbiBUQ1AgYW5k IGhhcyBiZWVuIGRpc2N1c3NlZCBmb3IgYSBsb25nIHRpbWUuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkJ1dCwgSSdtIHRoaW5raW5nIHRoYXQgaXQgbWlnaHQgYmUgYSBnb29kIHRpbWUgdG8g ZGlzY3VzcyBpdCBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPktleSBpZGVhcyBvZiB0aGUgZHJhZnQgYXJlIHRoZSZuYnNwO2ZvbGxvd2luZ3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjE6IGRyYXN0aWMgY2hhbmdlcyBpbiBUQ1AncyBzcGVjIHdp bGwgbm90IGJlIHJlcXVpcmVkJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJz cDsgKGl0IGRvZXMgbm90IHJlcXVpcmUgdXBkYXRpbmcgVENQIGhlYWRlciBmb3JtYXQgbm9yIHVz aW5nIG11bHRpcGxlIFNZTiBwYWNrZXRzIG9yIGFkZGl0aW9uYWwgU1lOLWxpa2UgcGFja2V0cyk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+MjogdXRpbGl6ZSB0aGUgb3B0aW9uIG5lZ290aWF0aW9uIHNj aGVtZXMgaW4gbXB0Y3AgZm9yIGdlbmVyaWMgcHVycG9zZXMuIHNvLCBJIHRoaW5rIGl0IGNhbiBi ZSBjb25zaWRlcmVkIG1pZGRsZWJveCBmcmllbmRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Mzog aXQgaGFzIHNvbWUgbGltaXRhdGlvbnMmbmJzcDsoZS5nIGl0IGNhbiBvbmx5IGV4dGVuZCBhcm91 bmQgMzAtNDAgYnl0ZXMgZm9yIFNZTiBvcHRpb24gc3BhY2UpLiBCdXQsIGlmIGl0J3MgY29tYmlu ZWQgd2l0aCBFRE8sIHdlIGNhbiB1c2UgbW9yZSBvcHRpb24gc3BhY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyAmbmJzcDsgKGRlcGVuZHMgb24gaG93IEVETyBkcmFmdCB3aWxsIHByb2dy ZXNzLCB0aG91Z2gpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5QbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBjb21t ZW50cyBvciBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoYW5rIHlvdSBzbyBtdWNoITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3NoaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogVHVlLCBGZWIgMiwgMjAyMSBhdCAxMDo0NSBQ TTxicj4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LW5pc2hpZGEtdGNwbS1hZ2ctc3luLWV4 dC0wMC50eHQ8YnI+DQpUbzogJmx0OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogQWdncmVnYXRlZCBPcHRpb24gZm9yIFNZTiBPcHRp b24gU3BhY2UgRXh0ZW5zaW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhv ciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBZb3NoaWZ1bWkgTmlzaGlkYTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IGRyYWZ0LW5pc2hpZGEtdGNwbS1hZ2ctc3luLWV4dC0wMC50eHQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogMTQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0 ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMS0wMi0wMjxi cj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUQ1Agb3B0aW9uIHNwYWNlIGlz IHNjYXJjZSByZXNvdXJjZSBhcyBpdHMgbWF4IGxlbmd0aCBpcyBsaW1pdGVkIHRvPGJyPg0KJm5i c3A7ICZuYnNwOzQwIGJ5dGVzLiZuYnNwOyBUaGlzIGxpbWl0YXRpb24gYmVjb21lcyBtb3JlIHNp Z25pZmljYW50IGluIFNZTiBzZWdtZW50czxicj4NCiZuYnNwOyAmbmJzcDthcyBhbGwgb3B0aW9u cyB1c2VkIGluIGEgY29ubmVjdGlvbiBzaG91bGQgYmUgZXhjaGFuZ2VkIGR1cmluZyBTWU48YnI+ DQombmJzcDsgJm5ic3A7bmVnb3RpYXRpb25zLiZuYnNwOyBUaGlzIGRvY3VtZW50IHByb3Bvc2Vz IGEgbmV3IFNZTiBvcHRpb24gbmVnb3RpYXRpb248YnI+DQombmJzcDsgJm5ic3A7c2NoZW1lIHRo YXQgcHJvdmlkZSBhIGZlYXR1cmUgdG8gY29tcHJlc3MgVENQIG9wdGlvbnMgaW4gU1lOIHNlZ21l bnRzPGJyPg0KJm5ic3A7ICZuYnNwO2FuZCBwcm92aWRlIG1vcmUgb3B0aW9uIHNwYWNlLiZuYnNw OyBUaGUgcHJvcG9zZWQgc2NoZW1lIGRvZXMgbm90IHVwZGF0ZTxicj4NCiZuYnNwOyAmbmJzcDt0 aGUgZm9ybWF0IG9mIFRDUCBoZWFkZXIgbm9yIHRyYW5zbWl0IGFueSBhZGRpdGlvbmFsIFNZTiBv ciBTWU4tbGlrZTxicj4NCiZuYnNwOyAmbmJzcDtzZWdtZW50cyBzbyB0aGF0IGl0IGhhcyBsb3dl ciByaXNrcyBmb3IgbWlkZGxlYm94IGludGVydmVudGlvbnMuJm5ic3A7IEluPGJyPg0KJm5ic3A7 ICZuYnNwO2FkZGl0aW9uLCBieSBjb21iaW5pbmcgYW5vdGhlciBwcm9wb3NhbCBmb3Igb3B0aW9u IHNwYWNlIGV4dGVuc2lvbiw8YnI+DQombmJzcDsgJm5ic3A7aXQgaXMgcG9zc2libGUgdG8gcHJv dmlkZSBmdXJ0aGVyIG9wdGlvbiBzcGFjZS48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXNoaWRhLXRjcG0tYWdnLXN5bi1l eHQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbmlzaGlkYS10Y3BtLWFnZy1zeW4tZXh0LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxz byBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5pc2hpZGEtdGNwbS1hZ2ctc3luLWV4dC0wMCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXNoaWRhLXRj cG0tYWdnLXN5bi1leHQtMDA8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1uaXNoaWRhLXRjcG0tYWdnLXN5bi1leHQtMDAiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW5p c2hpZGEtdGNwbS1hZ2ctc3luLWV4dC0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8 L2E+PGJyPg0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvc2hhZG93Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWw8L2E+PGJyPg0Kb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ll dGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcv aWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_719A2C1D4AC73847B6E1BF21DF1545EAE5E77372dggemm514mbschi_-- From nobody Wed Feb 10 02:28:49 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60343A046B for ; Wed, 10 Feb 2021 02:28:46 -0800 (PST) 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 z8IcqkF0ZYF6 for ; Wed, 10 Feb 2021 02:28:44 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 6E6133A00C4 for ; Wed, 10 Feb 2021 02:28:44 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id a1so546739qvd.13 for ; Wed, 10 Feb 2021 02:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EiMhINt/KA8fldi3TuKjGeztzD1Z9gT0dduQ7KE4bfc=; b=s/p2Ck7m7dS+GcGN9thwTrVtM5pQV48dNvDg37sc9Mr09gbOZfkWj1JW2rdInZ5rUA WFDCiMh++AHkCQkJYisNxMkVlWAzdNB16WjJY/4MxTu/bC65QAj+yamKjnEzkXVpnCok JpBTA0HNLcICKIOEXygaW5xb99Gb1deWVCs9ylUYNTxiiPl8A7YpfD/g1rncK2e1E+HI u8b/pKuB8zgrIBBYb1apfQkKgTBn4EU7y3GJySRlF94bP20UMmG2U21D8w/Gcj2RhrYz yO2TZn16iSAJrbSxO9uGkXuCetEtxwoqnb4WxyytJ9S3viaw5sC6jF8v81iBmJd6w7oV 44+w== 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=EiMhINt/KA8fldi3TuKjGeztzD1Z9gT0dduQ7KE4bfc=; b=H98vqfxuoO0mtpp5I/cCC2VYD7UciQaVI1VOc/Efl2R4oC0saf5sF8A3GUARd4DIK+ U8c1aJtEenyR58VgoClbmsI11oTIWiMtnOSsor2sou07e9rgKeHSIhavD3ymIqISff2m dOWDNZk6m7/NRdHsFvkzLwc2VJUQmyHs+JVG9FT9UDgnzH7AiPFqPiIFpggsz2YP8+EA DVsaYuTZdZ2nXil0wIlyEFYGF8+Ca17V4yrOUbbhZHLo93GzJJGwHC0eM1y1J6X+XyNW f0evnm16dO0/jHGIRvxhy0VYdoGpqr8l9c4P3MV8E8TTSt6Eid9VZQRZpDbmn7YnVbhT LaBw== X-Gm-Message-State: AOAM533yxpcothRL4PWBP2n6VxIfUil9w5uPrXih3Mw/UNbndjmNxfL/ wEJx2a67co4itEDucGY/HqTSc+o8MqAh9Y5P0Fg= X-Google-Smtp-Source: ABdhPJwRsZevObAOW3w4eMnt0d6Cx8aWDsNhLHK/U1hHara5iBR+XBr+M+Wd+2pG/DdQXnycuSI3Y9cmwRxEC9eA7Q8= X-Received: by 2002:ad4:40c6:: with SMTP id x6mr2113601qvp.10.1612952923387; Wed, 10 Feb 2021 02:28:43 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> In-Reply-To: <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> From: Yoshifumi Nishida Date: Wed, 10 Feb 2021 02:28:32 -0800 Message-ID: To: Kangjiao Cc: "tcpm@ietf.org Extensions" , Liangqiandeng Content-Type: multipart/alternative; boundary="00000000000009bb2f05baf8de6f" Archived-At: Subject: Re: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 10:28:47 -0000 --00000000000009bb2f05baf8de6f Content-Type: text/plain; charset="UTF-8" Hi Kangjiao, OK. I think it has some similarities. I will think about this further and will get back to you. -- Yoshi On Tue, Feb 9, 2021 at 5:14 PM Kangjiao wrote: > Hi Yoshi, > > > > I wrote a draft to propose an idea for MPTCP subtype capability exchange > during MPTCP handshake. We think, in MPTCP, some options are mandatory but > some options can be set as optional ones. So an exchange mechanism of > actual capability between both parties are needed. > > > > URL: > https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exchange/ > > Html: > https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-00.html > > Htmlized: > https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange-00 > > > > When I read your draft, I think maybe our above work have some relevance > to your suggestions. If you think it'll help with this work, I hope we can > discuss this new negotiation mechanism for related options and subtypes. > Thanks > > > > Best wishes, > > Jiao > > > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Yoshifumi > Nishida > *Sent:* Wednesday, February 3, 2021 3:12 PM > *To:* tcpm@ietf.org Extensions > *Subject:* [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt > > > > Hi folks, > > > > I prepared a draft for SYN option space extensions. > > I know this is a difficult issue in TCP and has been discussed for a long > time. > > But, I'm thinking that it might be a good time to discuss it again. > > > > Key ideas of the draft are the followings. > > 1: drastic changes in TCP's spec will not be required > > (it does not require updating TCP header format nor using multiple SYN > packets or additional SYN-like packets) > > 2: utilize the option negotiation schemes in mptcp for generic purposes. > so, I think it can be considered middlebox friendly. > > 3: it has some limitations (e.g it can only extend around 30-40 bytes for > SYN option space). But, if it's combined with EDO, we can use more option > space. > > (depends on how EDO draft will progress, though) > > > > Please let me know if you have any questions or comments or suggestions. > > > > Thank you so much! > > -- > > Yoshi > > > > > > ---------- Forwarded message --------- > From: > Date: Tue, Feb 2, 2021 at 10:45 PM > Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt > To: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Aggregated Option for SYN Option Space Extension > Author : Yoshifumi Nishida > Filename : draft-nishida-tcpm-agg-syn-ext-00.txt > Pages : 14 > Date : 2021-02-02 > > Abstract: > TCP option space is scarce resource as its max length is limited to > 40 bytes. This limitation becomes more significant in SYN segments > as all options used in a connection should be exchanged during SYN > negotiations. This document proposes a new SYN option negotiation > scheme that provide a feature to compress TCP options in SYN segments > and provide more option space. The proposed scheme does not update > the format of TCP header nor transmit any additional SYN or SYN-like > segments so that it has lower risks for middlebox interventions. In > addition, by combining another proposal for option space extension, > it is possible to provide further option space. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 > https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-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/ > > > _______________________________________________ > 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 > --00000000000009bb2f05baf8de6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Kangjiao,

OK. I thin= k it has some similarities. I will think about this further and will get ba= ck to you.
--
Yoshi

On Tue, Feb 9, 2021 at 5:14 PM Kangj= iao <kangjiao@huawei.com> = wrote:

Hi Yoshi,

=C2=A0=

I wrote a draft to propose = an idea for MPTCP subtype capability exchange during MPTCP handshake.=C2=A0= We think, in MPTCP, some options are mandatory but some options can be set as optional ones. So an exchange mechanism of = actual capability between both parties are needed.

=C2=A0=

URL:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability= -exchange-00.txt

Status:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://dat= atracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exchange/

Html:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exch= ange-00.html

Htmlized:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 https://tools.ietf.org/htm= l/draft-kang-tcpm-subtype-capability-exchange-00

=C2=A0=

When I read your draft, I t= hink maybe our above work have some relevance to your suggestions. If you t= hink it'll help with this work, I hope we can discuss this new negotiation mechanism for related options and subtypes. T= hanks

=C2=A0=

Best wishes,<= /span>

Jiao

=C2=A0=

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Wednesday, February 3, 2021 3:12 PM
To: tcpm@ietf.org= Extensions <tcpm= @ietf.org>
Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.t= xt

=C2=A0

Hi folks,<= /p>

=C2=A0

I prepared a draft for SYN opti= on space extensions.

I know this is a difficult issu= e in TCP and has been discussed for a long time.=C2=A0=

But, I'm thinking that it m= ight be a good time to discuss it again.

=C2=A0

Key ideas of the draft are the= =C2=A0followings.

1: drastic changes in TCP's= spec will not be required=C2=A0

=C2=A0 =C2=A0 (it does not requ= ire updating TCP header format nor using multiple SYN packets or additional= SYN-like packets)

2: utilize the option negotiati= on schemes in mptcp for generic purposes. so, I think it can be considered = middlebox friendly.

3: it has some limitations=C2= =A0(e.g it can only extend around 30-40 bytes for SYN option space). But, i= f it's combined with EDO, we can use more option space.

=C2=A0 =C2=A0 (depends on how E= DO draft will progress, though)

=C2=A0

Please let me know if you have = any questions or comments or suggestions.

=C2=A0

Thank you so much!

--

Yoshi

=C2=A0

=C2=A0

---------- Forwarded message --= -------
From: <int= ernet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-anno= unce@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Aggregated Option for SYN Option Space Extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-agg-syn-ext-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-02-02

Abstract:
=C2=A0 =C2=A0TCP option space is scarce resource as its max length is limit= ed to
=C2=A0 =C2=A040 bytes.=C2=A0 This limitation becomes more significant in SY= N segments
=C2=A0 =C2=A0as all options used in a connection should be exchanged during= SYN
=C2=A0 =C2=A0negotiations.=C2=A0 This document proposes a new SYN option ne= gotiation
=C2=A0 =C2=A0scheme that provide a feature to compress TCP options in SYN s= egments
=C2=A0 =C2=A0and provide more option space.=C2=A0 The proposed scheme does = not update
=C2=A0 =C2=A0the format of TCP header nor transmit any additional SYN or SY= N-like
=C2=A0 =C2=A0segments so that it has lower risks for middlebox intervention= s.=C2=A0 In
=C2=A0 =C2=A0addition, by combining another proposal for option space exten= sion,
=C2=A0 =C2=A0it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg= -syn-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext= -00
https://datatracker.ietf.org/doc/html/draft-nish= ida-tcpm-agg-syn-ext-00


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

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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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

--00000000000009bb2f05baf8de6f-- From nobody Wed Feb 10 04:25:04 2021 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 103BC3A0E48 for ; Wed, 10 Feb 2021 04:25:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161295990205.22710.7579168104787651783@ietfa.amsl.com> Date: Wed, 10 Feb 2021 04:25:02 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:25:02 -0000 Changed milestone "Submit RFC793bis document to the IESG for publication as Internet Standard", added draft-ietf-tcpm-rfc793bis to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 04:27:04 2021 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 5EEFE3A0E43 for ; Wed, 10 Feb 2021 04:27:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161296002237.29021.1720624556454797781@ietfa.amsl.com> Date: Wed, 10 Feb 2021 04:27:02 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:27:02 -0000 Changed milestone "Submit a document on modifying slow start to avoid large tail drops as a Proposed Standard RFC", added draft-ietf-tcpm-hystartplusplus to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 04:30:11 2021 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 71F703A0FAD for ; Wed, 10 Feb 2021 04:30:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161296020545.28489.5614088363628035666@ietfa.amsl.com> Date: Wed, 10 Feb 2021 04:30:05 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:30:10 -0000 Changed milestone "Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC", added draft-ietf-tcpm-tcp-edo to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 04:32:01 2021 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 6A3483A0E5A for ; Wed, 10 Feb 2021 04:32:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161296032041.28489.2616101269134569147@ietfa.amsl.com> Date: Wed, 10 Feb 2021 04:32:00 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:32:00 -0000 Changed milestone "Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC", added draft-ietf-tcpm-accurate-ecn to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 04:32:39 2021 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 D82163A0ECE for ; Wed, 10 Feb 2021 04:32:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161296035684.31377.16087023117855842384@ietfa.amsl.com> Date: Wed, 10 Feb 2021 04:32:36 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:32:38 -0000 Changed milestone "Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC", added draft-ietf-tcpm-generalized-ecn to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 04:39:07 2021 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 125A33A0EA7 for ; Wed, 10 Feb 2021 04:39:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161296074605.8216.15290769241233929251@ietfa.amsl.com> Date: Wed, 10 Feb 2021 04:39:06 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:39:06 -0000 Changed milestone "Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as a Proposed Standard RFC", added draft-ietf-tcpm-rack to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 07:55:13 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7F3A0E37 for ; Wed, 10 Feb 2021 07:55:11 -0800 (PST) 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, 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=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 Zl93QHLnwBqe for ; Wed, 10 Feb 2021 07:55:09 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F4B3A0E25 for ; Wed, 10 Feb 2021 07:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q8BlBi9Egaxwfyi7Cc7fSSY06fVRCQEg2WmH9HhXhsA=; b=hXujadNdoZ6WMQ1Y5Fqabz/CB iEKRbUnIGfVUKiYVjVzeoXlBrjrEGAVVOSRfDQP5bxnjLFWu3rfp6YSwwt9nXvVmueY8ATcIuP+a0 NJ8x8k1z/VSEBksaD3FhtG7wJ8K79qrm/jYRpeLiTT0kIaFYrjXKDpJv/hae+crUeO4S1pDJWY4+7 pgDHODEp4jnZFJE3NdFoR7AwGxc+IBGT8pwGEdivpUKWVjY0LeHdjQOFCjnS7BQx3pr6dfVJhrocY oiNU8/M+tb1vxs8ybY8qpPyvBCMzPEMHECwNgIKAteYsTc8S138orYCUrJU7NZOdhLSsdBRQjWcpC 6PDF2caSQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64702 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 1l9rpN-003Hcw-8A; Wed, 10 Feb 2021 10:54:58 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_4B373B8A-DC89-4D47-B630-BB536624266C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Wed, 10 Feb 2021 07:54:52 -0800 Cc: Kangjiao , "tcpm@ietf.org Extensions" , Liangqiandeng Message-Id: References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.60.0.2.21) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 15:55:12 -0000 --Apple-Mail=_4B373B8A-DC89-4D47-B630-BB536624266C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, all, FWIW, my view is that: - it MAY be reasonable for an option to negotiate parameters after the = TWHS BUT this can be VERY difficult, esp. because the negotiation = needs to account for segment loss and reordering - a new option CANNOT provide that opportunity for existing options those existing options were defined assuming establishment = during the TWHS - a new option CANNOT provide that opportunity for new options UNLESS = THEY EXPLICITLY ALLOW IT So the proposed mechanism does not appear to extend the option space in = a general sense, either for existing or all future options.=20 Joe > On Feb 10, 2021, at 2:28 AM, Yoshifumi Nishida = wrote: >=20 > Hi Kangjiao, >=20 > OK. I think it has some similarities. I will think about this further = and will get back to you. > -- > Yoshi >=20 > On Tue, Feb 9, 2021 at 5:14 PM Kangjiao > wrote: > Hi Yoshi, >=20 > =20 >=20 > I wrote a draft to propose an idea for MPTCP subtype capability = exchange during MPTCP handshake. We think, in MPTCP, some options are = mandatory but some options can be set as optional ones. So an exchange = mechanism of actual capability between both parties are needed. >=20 > =20 >=20 > URL: = https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchang= e-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exchan= ge/ = > Html: = https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchang= e-00.html = > Htmlized: = https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange-00= = > =20 >=20 > When I read your draft, I think maybe our above work have some = relevance to your suggestions. If you think it'll help with this work, I = hope we can discuss this new negotiation mechanism for related options = and subtypes. Thanks >=20 > =20 >=20 > Best wishes, >=20 > Jiao >=20 > =20 >=20 > From: tcpm [mailto:tcpm-bounces@ietf.org = ] On Behalf Of Yoshifumi Nishida > Sent: Wednesday, February 3, 2021 3:12 PM > To: tcpm@ietf.org Extensions > > Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt >=20 > =20 >=20 > Hi folks, >=20 > =20 >=20 > I prepared a draft for SYN option space extensions. >=20 > I know this is a difficult issue in TCP and has been discussed for a = long time.=20 >=20 > But, I'm thinking that it might be a good time to discuss it again. >=20 > =20 >=20 > Key ideas of the draft are the followings. >=20 > 1: drastic changes in TCP's spec will not be required=20 >=20 > (it does not require updating TCP header format nor using multiple = SYN packets or additional SYN-like packets) >=20 > 2: utilize the option negotiation schemes in mptcp for generic = purposes. so, I think it can be considered middlebox friendly. >=20 > 3: it has some limitations (e.g it can only extend around 30-40 bytes = for SYN option space). But, if it's combined with EDO, we can use more = option space. >=20 > (depends on how EDO draft will progress, though) >=20 > =20 >=20 > Please let me know if you have any questions or comments or = suggestions. >=20 > =20 >=20 > Thank you so much! >=20 > -- >=20 > Yoshi >=20 > =20 >=20 > =20 >=20 > ---------- Forwarded message --------- > From: > > Date: Tue, Feb 2, 2021 at 10:45 PM > Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt > To: > >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Aggregated Option for SYN Option Space = Extension > Author : Yoshifumi Nishida > Filename : draft-nishida-tcpm-agg-syn-ext-00.txt > Pages : 14 > Date : 2021-02-02 >=20 > Abstract: > TCP option space is scarce resource as its max length is limited to > 40 bytes. This limitation becomes more significant in SYN segments > as all options used in a connection should be exchanged during SYN > negotiations. This document proposes a new SYN option negotiation > scheme that provide a feature to compress TCP options in SYN = segments > and provide more option space. The proposed scheme does not update > the format of TCP header nor transmit any additional SYN or = SYN-like > segments so that it has lower risks for middlebox interventions. = In > addition, by combining another proposal for option space extension, > it is possible to provide further option space. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 = > = https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00 = >=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 = _______________________________= ________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_4B373B8A-DC89-4D47-B630-BB536624266C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = all,

FWIW, my view = is that:

- it = MAY be reasonable for an option to negotiate parameters after the = TWHS
BUT this can be VERY difficult, = esp. because the negotiation needs to account for segment loss and = reordering

- a = new option CANNOT provide that opportunity for existing = options
those existing options were = defined assuming establishment during the TWHS

- a new option CANNOT provide that = opportunity for new options UNLESS THEY EXPLICITLY ALLOW IT

So the proposed = mechanism does not appear to extend the option space in a general sense, = either for existing or all future options. 

Joe

On Feb 10, 2021, at 2:28 AM, Yoshifumi = Nishida <nsd.ietf@gmail.com> wrote:

Hi Kangjiao,

OK. I think it has some similarities. I = will think about this further and will get back to you.
--
Yoshi

On Tue, Feb = 9, 2021 at 5:14 PM Kangjiao <kangjiao@huawei.com> wrote:

Hi Yoshi,

 

I wrote a draft to propose an idea for MPTCP subtype = capability exchange during MPTCP handshake.  We think, in MPTCP, = some options are mandatory but some options can be set as optional ones. So an exchange mechanism = of actual capability between both parties are needed.

 

URL:          = ;  https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capabil= ity-exchange-00.txt

Status:         = https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capabi= lity-exchange/

Html:         &nbs= p; https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capabil= ity-exchange-00.html

Htmlized:       https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-= exchange-00

 

When I read your draft, I think maybe our above work = have some relevance to your suggestions. If you think it'll help with = this work, I hope we can discuss this new negotiation mechanism for related options and = subtypes. Thanks

 

Best wishes,

Jiao

 

From: tcpm = [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Wednesday, February 3, 2021 3:12 PM
= To: tcpm@ietf.org Extensions <tcpm@ietf.org>
Subject: [tcpm] Fwd: I-D Action: = draft-nishida-tcpm-agg-syn-ext-00.txt

 

Hi = folks,

 

I = prepared a draft for SYN option space extensions.

I = know this is a difficult issue in TCP and has been discussed for a long = time. 

But, I'm thinking that it might be a good time to discuss it = again.

 

Key= ideas of the draft are the followings.

1: = drastic changes in TCP's spec will not be required 

    (it does not require updating TCP header format = nor using multiple SYN packets or additional SYN-like packets)

2: = utilize the option negotiation schemes in mptcp for generic purposes. = so, I think it can be considered middlebox friendly.

3: = it has some limitations (e.g it can only extend around 30-40 bytes = for SYN option space). But, if it's combined with EDO, we can use more = option space.

    (depends on how EDO draft will progress, = though)

 

Please let me know if you have any questions or comments or = suggestions.

 

Thank you so much!

--

Yoshi

 

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-announce@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts = directories.


        Title          =  : Aggregated Option for SYN Option Space Extension
        Author          : = Yoshifumi Nishida
        Filename        : = draft-nishida-tcpm-agg-syn-ext-00.txt
        Pages          =  : 14
        Date          =   : 2021-02-02

Abstract:
   TCP option space is scarce resource as its max length is = limited to
   40 bytes.  This limitation becomes more significant in = SYN segments
   as all options used in a connection should be exchanged = during SYN
   negotiations.  This document proposes a new SYN option = negotiation
   scheme that provide a feature to compress TCP options in = SYN segments
   and provide more option space.  The proposed scheme = does not update
   the format of TCP header nor transmit any additional SYN or = SYN-like
   segments so that it has lower risks for middlebox = interventions.  In
   addition, by combining another proposal for option space = extension,
   it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext= /

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00
https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-sy= n-ext-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/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

= --Apple-Mail=_4B373B8A-DC89-4D47-B630-BB536624266C-- From nobody Wed Feb 10 09:21:56 2021 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 B75AB3A1079 for ; Wed, 10 Feb 2021 09:21:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161297771573.8854.14041765566795545647@ietfa.amsl.com> Date: Wed, 10 Feb 2021 09:21:55 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 17:21:56 -0000 Changed milestone "Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC", set due date to December 2021 from August 2020. Changed milestone "Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC", set due date to January 2022 from September 2020. Changed milestone "Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC", set due date to November 2022 from November 2020. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Feb 10 16:14:49 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0CF3A086E for ; Wed, 10 Feb 2021 16:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, 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 p81G99oD00f8 for ; Wed, 10 Feb 2021 16:14:46 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF9A3A0867 for ; Wed, 10 Feb 2021 16:14:46 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id y134so3504484wmd.3 for ; Wed, 10 Feb 2021 16:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UkhnibpgPowfUSLz8Koeo/R4KsHutQEdVXOrFfrtGvE=; b=iEVD35LuPed4HjHt0gpvapysHi8uWxevCCGhkxIZ9oe3bzHogDek9ersA4fEC82jZx tK9nG3oKy74aFQlNejewbwW3drG2tlgcv/UzovGhxeJKd4yOAC2BQboQHODg+vAhZ5wT pgx95z0AIx7C0S34Kr7AvL/+mWBxk4RrTOxPwUphgZ/4xlB1/KlQaM/X+OX5J7RUgW9G jkH8v9ay+o7MF5A5ScKtapWuVZRjct5akn6klF4OLHWVu3mVGhUQ3lSuWbePQnQd0qaP mHtL03ZbPudj6I62fKZQ14hChG1b2xOTm5LrvvPWqcP3V4NnxcKOGdJPfKtediH5zJAV Dzxg== 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=UkhnibpgPowfUSLz8Koeo/R4KsHutQEdVXOrFfrtGvE=; b=X14oEu9dgFJ32og2aPHDtoW0q6iicL77D8MUWxDG5DVbtYqai6/9NHazFogIVmvaib zx6+fIawLndAx3Gp7FqJUuQeqFQAWnJzboM7Dw1pFtWZ54Z8NpJC9pRl1e7x8xpR5qyZ ze3UkMZQqqEEP5Z/77Ze+WMXsZ8j4pIkinQEGZf46BxDjoxX7W2VG5/MQN2irR0UgRHw Ov9tHGJONINg3EC+p9CQ2CIhJ5pXpK/qqfFSujn0vDJxOW9NtoxRYZS8TD0KL1ZFAdBd Ck6CM6/9p0Oet7b1juFFIwj6gQidfivRUEU+K/rCIfYObBVoyV9TwpbZDL0xNsltcVOP 9kwg== X-Gm-Message-State: AOAM5335JuGIgCDVIMl5m4nYapuCpEsW09sPX+zPk+vF4rvW6I5OTUOU HyWCDxNYjxMBtv6DLujf2PxxiEjW8JyrBM9a4dzfag== X-Google-Smtp-Source: ABdhPJxWFgKdGuGbnKQBeLA06hhhD7ZkMLC6oOGaV5bXYC2YrgoIhCf2L2/+/6RFcVZq8X7gACkzXxLCfZb2J3eZCzQ= X-Received: by 2002:a7b:c852:: with SMTP id c18mr1742923wml.118.1613002484002; Wed, 10 Feb 2021 16:14:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 10 Feb 2021 16:14:05 -0800 Message-ID: To: "Scharf, Michael" Cc: tcpm IETF list , Neal Cardwell Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 Feb 2021 00:14:49 -0000 I think it's ready. Kudos to Wes for the N-years-long effort to put this together! Minor: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.= 7.4 The less clear part is the wording of "idle connections". Idleness can be interpreted in several ways: no recent rx, tx, or both {on the wire | on socket interface}. It'd be good to define more clearly. AFAIK implementations have different definitions already leading to different KA behaviors. On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael wrote: > > Dear all, > > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to We= s, all WGLC feedback should be reflected in this version. A link to a compl= ete diff can be found below. > > During WGLC, there has been quite some discussion on the exact wording on= congestion control. The suggested text in version -20 is copied below: > > 3.7.2. TCP Congestion Control > > RFC 2914 [7] explains the importance of congestion control for the > Internet. > > RFC 1122 required implementation of Van Jacobson's congestion control > algorithms slow start with congestion avoidance together with > exponential back-off for successive RTO values for the same segment. > RFC 2581 provided IETF Standards Track description of slow start and > congestion avoidance, along with fast retransmit and fast recovery. > RFC 5681 is the current description of these algorithms and is the > current Standards Track specification providing guidelines for TCP > congestion control. RFC 6298 describes exponential back-off of RTO > values, including keeping the backed-off value until a subsequent > segment with new data has been sent and acknowledged. > > A TCP endpoint MUST implement the basic congestion control algorithms > slow start, congestion avoidance, and exponential back-off of RTO to > avoid creating congestion collapse conditions (MUST-19). RFC 5681 > and RFC 6298 describe the basic algorithms on the IETF Standards > Track that are broadly applicable. Multiple other suitable > algorithms exist and have been widely used. Many TCP implementations > support a set of alternative algorithms that can be configured for > use on the endpoint. An endpoint may implement such alternative > algorithms provided that the algorithms are conformant with the TCP > specifications from the IETF Standards Track as described in RFC > 2914, RFC 5033 [10], and RFC 8961 [15]. > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > an IETF Standards Track enhancement that has many benefits [50]. > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > 8). > > As document shepherd I ask everybody - specifically all TCPM contributors= who have commented on congestion control - to carefully review this propos= ed wording within the next few days. If there are any issues with this sugg= ested resolution of the WGLC, please speak up! > > If the TCPM working group is fine with version -20, 793bis would be ready= to go. > > Thanks > > Michael > > > -----Original Message----- > From: I-D-Announce On Behalf Of internet-= drafts@ietf.org > Sent: Thursday, January 21, 2021 7:02 PM > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG = of the IETF. > > Title : Transmission Control Protocol (TCP) Specificati= on > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-20.txt > Pages : 110 > Date : 2021-01-21 > > 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-20 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-20 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Feb 10 16:33:42 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC03A0C83 for ; Wed, 10 Feb 2021 16:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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=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 gX81iJyiOm5N for ; Wed, 10 Feb 2021 16:33:38 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640127.outbound.protection.outlook.com [40.107.64.127]) (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 6CB2C3A0C77 for ; Wed, 10 Feb 2021 16:33:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nKTCSF4cZZtz3aYVbeXgyxFAKY77m0gZ3Ws/C46o9noRlrBPAy2rGKQnVKRUsHYXKFadypjJVXRlvYXhzDD1uYKPNXGP6h9oDLcKx5GlsjaFz6wc0kWCbt4mj2q1cXydu/tXU+Mafb6dnvWBcBFwvn3hkNOlxrDzWvQjPW+QMP2SH5fTRNi3ZApw+ZWOuZfeTYmitAmAHufDOxShts7vQL1Ww+5IvsRFlFL8l1quJWWA//HqvZV3KuGmhmERDfVXgs/hQ99/uL6ui60M4sTyO5AT8fl4BnvR8ReWDFor9IBUokqaqdzHdyXn8bcYzfdwteXSRB1WXyWNviUunoK8pA== 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=hB/k2Ms0DTjYGabYMkuPHCf1+AsOuOSQjoEilZy4H1M=; b=jc7FWxl1QLyEGda9J/b0+9HyTW7XPTIWEmDwNnHjcR1UCIw9v+oEA31PxwhjmkQpIi2GoB3qamd2ofRf23x+g2dCZuujtXIdWBj0q2FTkIUCOQRXyzArXFptWgOdvGL7ZQ/MbGzsIZqRp5kz+Z2iRbtOZQuRJ83NyGYSU1I27Qai1SGd5O/N+k0hIkhqow4Jn2EjWD2q+WcRxE5+7/cmNLapgkcl41hQR4tUV1ZyM2vPbiz+mD6GYKKKzPjr+jEGhkTMkH43ps0ErSHDK8igAP8Gnam56wfkgeeqVWGsNieZmLIjRRJsdN/NwIOdAZZUKMt23MmwlBeFC6CZAp25eQ== 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=hB/k2Ms0DTjYGabYMkuPHCf1+AsOuOSQjoEilZy4H1M=; b=gEyJtGD8zgQdkdmYeyPT2Jhi9vQ0A92HrGWJfxLwsrq6Af2RBdOpA9RtDqmGpWsMN5sYJLz3Ft7HQdGT4aBF/84szOluBX6XY1l8C8rEUFdG2DxxnzImRYzVXP+6sSDYYVLipLW/XXn7lCAhyQUcH06XTVUKQg77zevDzmBdjag= Received: from CO2PR00MB0168.namprd00.prod.outlook.com (2603:10b6:102:15::21) by CO1PR00MB0980.namprd00.prod.outlook.com (2603:10b6:303:96::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3886.0; Thu, 11 Feb 2021 00:33:17 +0000 Received: from CO2PR00MB0168.namprd00.prod.outlook.com ([fe80::a4ee:cc05:4ea2:fe2b]) by CO2PR00MB0168.namprd00.prod.outlook.com ([fe80::a4ee:cc05:4ea2:fe2b%7]) with mapi id 15.20.3887.000; Thu, 11 Feb 2021 00:33:17 +0000 From: Praveen Balasubramanian To: "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" Thread-Topic: 793bis ready to go? Thread-Index: Adb+OMcXKdPjASFKQc+5zg7FPT9zRwB1KQnQ Date: Thu, 11 Feb 2021 00:33:17 +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=b62d227f-4cd2-452e-808d-3dc46e497f40; 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=2021-02-11T00:32:46Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: hs-esslingen.de; dkim=none (message not signed) header.d=none;hs-esslingen.de; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f:95c9:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 04e60eda-1cbd-4b0d-635f-08d8ce24a033 x-ms-traffictypediagnostic: CO1PR00MB0980: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: k0AI5knhBlNbHwq4ExlJqwaFq72QltgM/Nzn8H9Ef6tBuzZLfNFLq8XgrrY/HPgU1W2CQMXNTYAtm8u+zvgH5DjhckfVBtuE01462F26isaTb6DMPW43yeh/Hx+MmluS4VTpyFtrMzYjXU49/FfWbifb5YvgNIUTCT/VOr9TAwrJkc6ZkS77GwD9tLNNcKU3dcWRbAMo2IL6ZSm7QYulG6GQAIdup4eamYQ5Q/I6YWIdEvatiEKiR6b1q314SG8gg/RL6kcK0loZKJLdnno+7s5/MTVKNQZh89ZJuPdhXgneUOQwle1MdJKlDV+k+MsVI2x2GXd4bqwq471aNFa+EdQFWEbnk7f1I13VHZQ8QRvNW1HkmjEL6Sir9E0A0KarDURa6rLF3XX5dHnVBIpLIl+f+WLeZgwiX8xO2/l605u0L1ho0PWW0RvrutLVv3cFj1uDDRmrGA5BuNvi4DUj5hGRB/sdfagDY3DwEVGebGpzju+YXztFaHIbe9uKAznGrjk1YadReUgCR7co6Wye9hyrdYMWADD74cIV+9ZA5KBydUnUwr5rMVXLqNrOXCtnkVY402X41sFH4PcfalUMPV+IbyP1w8IjvMtxTiiLz8U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO2PR00MB0168.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(376002)(39860400002)(136003)(33656002)(186003)(86362001)(52536014)(83380400001)(66946007)(8936002)(71200400001)(2906002)(6506007)(64756008)(66556008)(66446008)(76116006)(5660300002)(53546011)(66574015)(66476007)(478600001)(7696005)(82950400001)(82960400001)(10290500003)(316002)(110136005)(8676002)(966005)(9686003)(8990500004)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?HU8c3v37yV+tRQBZID69/c09E8fl0UMhxYIfZDot6/tqSkNXD8qkOn72E5nf?= =?us-ascii?Q?PRiSyHujVo4rGJ82em4uR8SpBeFQ7X3dgAicEgkw0aWLPej3HdL8uUDYoxtI?= =?us-ascii?Q?Z3Pxyf+OxZ/haJeFT9e0rlEipFkZcbc3FYf2CXtHeTsUsyqJ/4ebaCURbkdk?= =?us-ascii?Q?8XNabbyGBsxtv3NXNh2AoUGrIhw+ae/FfNeU3lUQXr+8LzkwEKrAImcDWzjA?= =?us-ascii?Q?VUb3jX73f1TTMvA0z+FaJ1oKCQBEeiB4p0oW64zh/Ay79RwNk2lSE1SOW6L2?= =?us-ascii?Q?bUpAT6QFq1EgI5SSI2qFsUlYj/opSze+zUw+i9NTQ0E9+UOTu7t9P/Djz2as?= =?us-ascii?Q?IAkhEKrYJEx7Ti855KMQofFM5a+Su5B3EOFchHdwctrMc13QCbLzOmcmE8mN?= =?us-ascii?Q?cAydKusoJitlE0IaqPtEB9gtpqQxwOZoV3B4oys6jWHoDyG3XSF8kHJvFNXy?= =?us-ascii?Q?0X9p4fxres0x/0YX5exc/DIN9+pT31XEyalWtUmVEiWxfiYW1QNpgGfWbh/8?= =?us-ascii?Q?fLwe1tLksSxCnG5ogxxZOFWGhPl3XKoL50/TIfd/0shADY5xR3DALh6MtQwo?= =?us-ascii?Q?DTOcCQXl3m2KO87LkGHoePd4g3AtrogZELDVH6X0FMCwHObxufiY5CAPGDwb?= =?us-ascii?Q?EPu7TLMw+JWE9oTGE/EA+4fet5NuF5XPHWDfr1wxl4iJgkxYCD1VpQyixGgB?= =?us-ascii?Q?R8vjN7Ow6f6jO12jz6ggBBbvO+YCqUcXsp4BxqJLhLqWdCmQu/zs95eqKFLB?= =?us-ascii?Q?YGzGoJ+Jf+Po6rEzLXAisExn3pUwTpgwcN3K+C6q1Hqy3Q1ElH6Ww3h3VfBl?= =?us-ascii?Q?cpNzlY6QE/9cMiKu7n5THYCMjZZx7RJFiTnEXZGc1ncdwLv/1sqZG1u5YsT6?= =?us-ascii?Q?0K/Z35nT59RgjrQy8T0XAAzLUNMwpENJGX2tQSWn6VgByorEBQK76i58R8Ux?= =?us-ascii?Q?ly4lhQ0gyugaVCnBHegYXTLuv2D0i0wAnJaU31tLbUjsekytmQIhqHv9PC3h?= =?us-ascii?Q?SvUvbEipt+BKHo3v46j5LSS2P7WJYUqtUhp6Q9Osbz2CgutfLhaPcKfc3Oig?= =?us-ascii?Q?xXF+BqMW2o5eSvAnqEm38lbbl/bhpxzKIlzvFnc8+d0U5gDmKZP7+SyiVmKP?= =?us-ascii?Q?xGEfEfGh3Jn00Dx9sAhIYOAD+z+sS2o2sog4+3kMxneNPOCZSBKGLSuL0Ir3?= =?us-ascii?Q?/5AfTs12ugNkKgnNgjp4GUXiqJx+fpE4x6AtQQwe2j1gRfqEMrACmgj+BpAg?= =?us-ascii?Q?7fJ6p0VpzAmJhQuoj2mJeGCb48VY8hD9AEQ+w3w4yzCS6JBLyC4/NnJdksJl?= =?us-ascii?Q?66ryMUdbLz9qMDaEGDQ/1k8I8dGwkz55xVot3ytuX5cfFLpZk88ys3JhHqln?= =?us-ascii?Q?fxJmddtywT9Apo5+qpOic8wp/qJA?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO2PR00MB0168.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04e60eda-1cbd-4b0d-635f-08d8ce24a033 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 00:33:17.3032 (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: AqHturiFkxLUpJZp6jJjRo7a8nxCEVhOrvCLPwo6NW1RzqE7AsjXvuIi4wQgd0iWgaAWVTjVYQTTSyPvlqwTPW0L/HQcGrurHkAPsQhdvu0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR00MB0980 Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 Feb 2021 00:33:41 -0000 The new text on congestion control looks good to me. Thanks! -----Original Message----- From: tcpm On Behalf Of Scharf, Michael Sent: Monday, February 8, 2021 9:00 AM To: tcpm IETF list Subject: [EXTERNAL] [tcpm] 793bis ready to go? Dear all, draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to Wes,= all WGLC feedback should be reflected in this version. A link to a complet= e diff can be found below. During WGLC, there has been quite some discussion on the exact wording on c= ongestion control. The suggested text in version -20 is copied below: 3.7.2. TCP Congestion Control RFC 2914 [7] explains the importance of congestion control for the Internet. RFC 1122 required implementation of Van Jacobson's congestion control algorithms slow start with congestion avoidance together with exponential back-off for successive RTO values for the same segment. RFC 2581 provided IETF Standards Track description of slow start and congestion avoidance, along with fast retransmit and fast recovery. RFC 5681 is the current description of these algorithms and is the current Standards Track specification providing guidelines for TCP congestion control. RFC 6298 describes exponential back-off of RTO values, including keeping the backed-off value until a subsequent segment with new data has been sent and acknowledged. A TCP endpoint MUST implement the basic congestion control algorithms slow start, congestion avoidance, and exponential back-off of RTO to avoid creating congestion collapse conditions (MUST-19). RFC 5681 and RFC 6298 describe the basic algorithms on the IETF Standards Track that are broadly applicable. Multiple other suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. An endpoint may implement such alternative algorithms provided that the algorithms are conformant with the TCP specifications from the IETF Standards Track as described in RFC 2914, RFC 5033 [10], and RFC 8961 [15]. Explicit Congestion Notification (ECN) was defined in RFC 3168 and is an IETF Standards Track enhancement that has many benefits [50]. A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- 8). As document shepherd I ask everybody - specifically all TCPM contributors w= ho have commented on congestion control - to carefully review this proposed= wording within the next few days. If there are any issues with this sugges= ted resolution of the WGLC, please speak up! If the TCPM working group is fine with version -20, 793bis would be ready t= o go. Thanks Michael -----Original Message----- From: I-D-Announce On Behalf Of internet-dr= afts@ietf.org Sent: Thursday, January 21, 2021 7:02 PM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions WG of= the IETF. Title : Transmission Control Protocol (TCP) Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-20.txt Pages : 110 Date : 2021-01-21 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://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-tcpm-rfc793bis%2F&data=3D04%7C01%7Cpra= vb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C637484005105023530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi= MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata= =3D%2B%2Fnf5AfiOwW4PZPhtsSHFCnbRVMr%2FJm93crEUHDnYI8%3D&reserved=3D0 There are also htmlized versions available at: https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-ietf-tcpm-rfc793bis-20&data=3D04%7C01%7Cpravb%40= microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C637484005105023530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL= jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DBh= TeT76PMXuFVHNFfHqvt%2FDSBjNO3L1f%2BE371FYlOos%3D&reserved=3D0 https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-tcpm-rfc793bis-20&data=3D04%7C0= 1%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f1= 41af91ab2d7cd011db47%7C1%7C0%7C637484005105023530%7CUnknown%7CTWFpbGZsb3d8e= yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DHgfUOg8gyzOO5Eox2qQFaOEKE4LBUT9Vr5Z7jO5LfSU%3D&reserved=3D0 A diff from the previous version is available at: https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-ietf-tcpm-rfc793bis-20&data=3D04%7C01%7C= pravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af= 91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sd= ata=3DyKJ3SXtv%2F0kuNXM%2BqRr7CiAOzmFqT1xzSLbMgx%2FTRYo%3D&reserved=3D0 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://nam06.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.ietf.= org%2Finternet-drafts%2F&data=3D04%7C01%7Cpravb%40microsoft.com%7Cc71f0= d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63= 7484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz= IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlepBojFHU0gmFdbX5dXzZMK= 4SqEhrRGVwB8jFhGvgdk%3D&reserved=3D0 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=3D04%7C01%7Cpravb%40micr= osoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011= db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DgbaTue= D1oZCj48owt5KHKUHGqf6NwiEZuuwvvoMJyQk%3D&reserved=3D0 Internet-Draft directories: https://nam06.safelinks.protection.outlook.com/= ?url=3Dhttp%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=3D04%7C01%7Cpravb%4= 0microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7= cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dv= MmLSaybns3dvCyFYBEYetOXiQK1rVrlKix3NnBg7HE%3D&reserved=3D0 or https://nam06.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.ie= tf.org%2Fietf%2F1shadow-sites.txt&data=3D04%7C01%7Cpravb%40microsoft.co= m%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Da8WU5cGZzUnk11= uO9oF9twtuRiKleFJW%2BwS2S%2ByPdUU%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft.co= m%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Decsv4xXHJXAeg4= yJJ14vpJnrnVIhibLqYi0La91DTwg%3D&reserved=3D0 From nobody Wed Feb 10 21:23:11 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9123A11C1 for ; Wed, 10 Feb 2021 21:23:10 -0800 (PST) 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 L8BZr_qwNFak for ; Wed, 10 Feb 2021 21:23:07 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7343A11BF for ; Wed, 10 Feb 2021 21:23:07 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id o186so2406775vso.1 for ; Wed, 10 Feb 2021 21:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rvDner9/K3P16uPlgn8O9IHCTYcil1ZNu+IzmHzuuZA=; b=uSIkn8HK4Mjcg8q9uQICqUVrqEVdln+6OZJGCRfDuMmpl53pNbCP5ZkeTvpFmG2Q29 20gsm6QxGaIuzeLOD6eILjKM7au42yM9qdb1R/+gBwLXhLE00kh+h+xq4FnGODEP8coW VBGP5hHnThyQyQbdhlJUDG4FTxz3yswcT4FEy6YyqpUwJnabZiBVfzcGuHbQeXuFnzy+ /I6aNIxwE2Wv4R3nAEoH1T0z7Y05EcVzVN1xIeGekWKI0RnXBhX4K059XLoOBt1JiWtS FTT/dgPsbChOCM3vyTwal8SebWeVHsYZiVP5teMkkzVe285oomox+0QUoWbLWl/iMvA3 ak3w== 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=rvDner9/K3P16uPlgn8O9IHCTYcil1ZNu+IzmHzuuZA=; b=V4OsGVHvlkQaGntmara3m+7NvVRMNdvOijv2qAjgH8iTcNM+rItSme1clOYte/kpAq YY2E9vtrkEXAJlUCuYw2Ix34/siXGTun7vbE8aEvPl1x207V19Kofhdfkxp11tFbbVXj zw0AF6WCncM7fge95fJ8KXD1YIp4fzebWP9N00UdtSKNfr7zLPx0rl1T7PvihZry/cjW FhAhMMrPPUOslg9ZofvI72V0LeDDtFkziCZ9cAib2ijgIbtFEk1zjV7+qBuekHPg5Lmf 7dGPqAIKHFg0/ZyYcTSFunHi0jiTXdq3t6Xl0uU3kvepow5CuvugwTosI6G0Ojtx1TPj fUMQ== X-Gm-Message-State: AOAM532nteH1+0qiwHBatewjqLgfMx0r2Xng66p50ZonwPICkvbL0JpB ZhvTFZxSwAFnNNL5wYO7TuPjIHNsWcOkMt1onrhcKQ== X-Google-Smtp-Source: ABdhPJzgGYxIZZLpFJXDTZty0WKFupWoQHM93Con5mAgVpr2Ct4+EOM0Uo5jyAT845CPGagMhTFyRO4qCOcUUvYDSvo= X-Received: by 2002:a67:c82:: with SMTP id 124mr4032870vsm.54.1613020984843; Wed, 10 Feb 2021 21:23:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Thu, 11 Feb 2021 00:22:48 -0500 Message-ID: To: Yuchung Cheng Cc: "Scharf, Michael" , tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000d196ec05bb08b6af" Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 Feb 2021 05:23:10 -0000 --000000000000d196ec05bb08b6af Content-Type: text/plain; charset="UTF-8" The wording in the Congestion Control section looks great to me. > Minor: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 I agree with Yuchung that it would be nice to clarify what is meant by "idle" connections (in the pre-existing text), with respect to keep-alives. It seems at least the historical behavior for two of the major implementations out there interpret this in different ways, and this has caused some confusion in the developer community about what semantics to expect from TCP keep-alives. I guess the rfc793bis-20 draft does have some nice new text (that does not seem to be in RFC793 or RFC1122) that seems to shed some light on this: Keep-alive packets MUST only be sent when no sent data is outstanding, and no data or acknowledgement packets have been received for the connection within an interval (MUST-26). That sentence helps quite a bit. It seems to correspond to the last 20 years of Linux TCP keep-alive behavior, but not the BSD behavior (at least BSD TCP as documented in Stevens volume 2; I have not checked more recent BSD kernels). And, yes, thank you, Wes for all your years of effort on this! neal On Wed, Feb 10, 2021 at 7:14 PM Yuchung Cheng wrote: > I think it's ready. Kudos to Wes for the N-years-long effort to put > this together! > > Minor: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 > > The less clear part is the wording of "idle connections". Idleness can > be interpreted in several ways: no recent rx, tx, or both {on the wire > | on socket interface}. It'd be good to define more clearly. AFAIK > implementations have different definitions already leading to > different KA behaviors. > > > > > On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael > wrote: > > > > Dear all, > > > > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to > Wes, all WGLC feedback should be reflected in this version. A link to a > complete diff can be found below. > > > > During WGLC, there has been quite some discussion on the exact wording > on congestion control. The suggested text in version -20 is copied below: > > > > 3.7.2. TCP Congestion Control > > > > RFC 2914 [7] explains the importance of congestion control for the > > Internet. > > > > RFC 1122 required implementation of Van Jacobson's congestion control > > algorithms slow start with congestion avoidance together with > > exponential back-off for successive RTO values for the same segment. > > RFC 2581 provided IETF Standards Track description of slow start and > > congestion avoidance, along with fast retransmit and fast recovery. > > RFC 5681 is the current description of these algorithms and is the > > current Standards Track specification providing guidelines for TCP > > congestion control. RFC 6298 describes exponential back-off of RTO > > values, including keeping the backed-off value until a subsequent > > segment with new data has been sent and acknowledged. > > > > A TCP endpoint MUST implement the basic congestion control algorithms > > slow start, congestion avoidance, and exponential back-off of RTO to > > avoid creating congestion collapse conditions (MUST-19). RFC 5681 > > and RFC 6298 describe the basic algorithms on the IETF Standards > > Track that are broadly applicable. Multiple other suitable > > algorithms exist and have been widely used. Many TCP implementations > > support a set of alternative algorithms that can be configured for > > use on the endpoint. An endpoint may implement such alternative > > algorithms provided that the algorithms are conformant with the TCP > > specifications from the IETF Standards Track as described in RFC > > 2914, RFC 5033 [10], and RFC 8961 [15]. > > > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > > an IETF Standards Track enhancement that has many benefits [50]. > > > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > > 8). > > > > As document shepherd I ask everybody - specifically all TCPM > contributors who have commented on congestion control - to carefully review > this proposed wording within the next few days. If there are any issues > with this suggested resolution of the WGLC, please speak up! > > > > If the TCPM working group is fine with version -20, 793bis would be > ready to go. > > > > Thanks > > > > Michael > > > > > > -----Original Message----- > > From: I-D-Announce On Behalf Of > internet-drafts@ietf.org > > Sent: Thursday, January 21, 2021 7:02 PM > > To: i-d-announce@ietf.org > > Cc: tcpm@ietf.org > > Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the TCP Maintenance and Minor Extensions WG > of the IETF. > > > > Title : Transmission Control Protocol (TCP) > Specification > > Author : Wesley M. Eddy > > Filename : draft-ietf-tcpm-rfc793bis-20.txt > > Pages : 110 > > Date : 2021-01-21 > > > > 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-20 > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000d196ec05bb08b6af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The wording in the Congestion Control section looks great = to me.


I agree with Yuchung that it wo= uld be nice to clarify what is meant by "idle" connections (in th= e pre-existing text), with respect to keep-alives. It seems at least the hi= storical behavior for two of the major implementations out there interpret = this in different ways, and this has caused some confusion in the developer= community about what semantics to expect from TCP keep-alives. I guess the= =C2=A0rfc793bis-20 draft does have some nice new text (that does not seem t= o be in RFC793 or RFC1122) that seems to shed some light on this:

   Keep=
-alive packets MUST only be sent when no sent data is
   outstanding, and no data or acknowledgement packets have been
   received for the connection within an interval (MUST-26).

That sentence helps quite a bit. It seems to correspond to= the last 20 years of Linux TCP keep-alive behavior, but not the BSD behavi= or (at least BSD TCP as documented in Stevens volume 2; I have not checked = more recent=C2=A0BSD kernels).

And, yes, thank you= , Wes for all your years of effort on this!

neal



On Wed, Feb 10, 2021 at 7:14 PM Yuchung C= heng <ycheng@google.com> wro= te:
I think it&#= 39;s ready. Kudos to Wes for the N-years-long effort to put
this together!

Minor:=C2=A0 https://tools.iet= f.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4

The less clear part is the wording of "idle connections". Idlenes= s can
be interpreted in several ways: no recent rx, tx, or both {on the wire
| on socket interface}. It'd be good to define more clearly. AFAIK
implementations have different definitions already leading to
different KA behaviors.




On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael
<Mic= hael.Scharf@hs-esslingen.de> wrote:
>
> Dear all,
>
> draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to= Wes, all WGLC feedback should be reflected in this version. A link to a co= mplete diff can be found below.
>
> During WGLC, there has been quite some discussion on the exact wording= on congestion control. The suggested text in version -20 is copied below:<= br> >
> 3.7.2.=C2=A0 TCP Congestion Control
>
>=C2=A0 =C2=A0 RFC 2914 [7] explains the importance of congestion contro= l for the
>=C2=A0 =C2=A0 Internet.
>
>=C2=A0 =C2=A0 RFC 1122 required implementation of Van Jacobson's co= ngestion control
>=C2=A0 =C2=A0 algorithms slow start with congestion avoidance together = with
>=C2=A0 =C2=A0 exponential back-off for successive RTO values for the sa= me segment.
>=C2=A0 =C2=A0 RFC 2581 provided IETF Standards Track description of slo= w start and
>=C2=A0 =C2=A0 congestion avoidance, along with fast retransmit and fast= recovery.
>=C2=A0 =C2=A0 RFC 5681 is the current description of these algorithms a= nd is the
>=C2=A0 =C2=A0 current Standards Track specification providing guideline= s for TCP
>=C2=A0 =C2=A0 congestion control.=C2=A0 RFC 6298 describes exponential = back-off of RTO
>=C2=A0 =C2=A0 values, including keeping the backed-off value until a su= bsequent
>=C2=A0 =C2=A0 segment with new data has been sent and acknowledged.
>
>=C2=A0 =C2=A0 A TCP endpoint MUST implement the basic congestion contro= l algorithms
>=C2=A0 =C2=A0 slow start, congestion avoidance, and exponential back-of= f of RTO to
>=C2=A0 =C2=A0 avoid creating congestion collapse conditions (MUST-19).= =C2=A0 RFC 5681
>=C2=A0 =C2=A0 and RFC 6298 describe the basic algorithms on the IETF St= andards
>=C2=A0 =C2=A0 Track that are broadly applicable.=C2=A0 Multiple other s= uitable
>=C2=A0 =C2=A0 algorithms exist and have been widely used.=C2=A0 Many TC= P implementations
>=C2=A0 =C2=A0 support a set of alternative algorithms that can be confi= gured for
>=C2=A0 =C2=A0 use on the endpoint.=C2=A0 An endpoint may implement such= alternative
>=C2=A0 =C2=A0 algorithms provided that the algorithms are conformant wi= th the TCP
>=C2=A0 =C2=A0 specifications from the IETF Standards Track as described= in RFC
>=C2=A0 =C2=A0 2914, RFC 5033 [10], and RFC 8961 [15].
>
>=C2=A0 =C2=A0 Explicit Congestion Notification (ECN) was defined in RFC= 3168 and is
>=C2=A0 =C2=A0 an IETF Standards Track enhancement that has many benefit= s [50].
>
>=C2=A0 =C2=A0 A TCP endpoint SHOULD implement ECN as described in RFC 3= 168 (SHLD-
>=C2=A0 =C2=A0 8).
>
> As document shepherd I ask everybody - specifically all TCPM contribut= ors who have commented on congestion control - to carefully review this pro= posed wording within the next few days. If there are any issues with this s= uggested resolution of the WGLC, please speak up!
>
> If the TCPM working group is fine with version -20, 793bis would be re= ady to go.
>
> Thanks
>
> Michael
>
>
> -----Original Message-----
> From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of internet-drafts@i= etf.org
> Sent: Thursday, January 21, 2021 7:02 PM
> To: i-d-ann= ounce@ietf.org
> Cc: tcpm@ietf.org
> Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the TCP Maintenance and Minor Extensions = WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Transmission Control Protocol (TCP) Specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Wesley M. Eddy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-tcpm-rfc793bis-20.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 110
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2021-01-21
>
> Abstract:
>=C2=A0 =C2=A0 This document specifies the Transmission Control Protocol= (TCP).=C2=A0 TCP
>=C2=A0 =C2=A0 is an important transport layer protocol in the Internet = protocol
>=C2=A0 =C2=A0 stack, and has continuously evolved over decades of use a= nd growth of
>=C2=A0 =C2=A0 the Internet.=C2=A0 Over this time, a number of changes h= ave been made to
>=C2=A0 =C2=A0 TCP as it was specified in RFC 793, though these have onl= y been
>=C2=A0 =C2=A0 documented in a piecemeal fashion.=C2=A0 This document co= llects and brings
>=C2=A0 =C2=A0 those changes together with the protocol specification fr= om RFC 793.
>=C2=A0 =C2=A0 This document obsoletes RFC 793, as well as RFCs 879, 287= 3, 6093,
>=C2=A0 =C2=A0 6429, 6528, and 6691 that updated parts of RFC 793.=C2=A0= It updates RFC
>=C2=A0 =C2=A0 1122, and should be considered as a replacement for the p= ortions of
>=C2=A0 =C2=A0 that document dealing with TCP requirements.=C2=A0 It als= o updates RFC
>=C2=A0 =C2=A0 5961 by adding a small clarification in reset handling wh= ile in the
>=C2=A0 =C2=A0 SYN-RECEIVED state.=C2=A0 The TCP header control bits fro= m RFC 793 have
>=C2=A0 =C2=A0 also been updated based on RFC 3168.
>
>=C2=A0 =C2=A0 RFC EDITOR NOTE: If approved for publication as an RFC, t= his should
>=C2=A0 =C2=A0 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/dra= ft-ietf-tcpm-rfc793bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-= tcpm-rfc793bis-20
> https://datatracker.ietf.org/= doc/html/draft-ietf-tcpm-rfc793bis-20
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-tcpm-rfc793bis-20
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
--000000000000d196ec05bb08b6af-- From nobody Thu Feb 11 01:06:06 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF573A13D5 for ; Thu, 11 Feb 2021 01:06:05 -0800 (PST) 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 xxJFq_a0fYK7 for ; Thu, 11 Feb 2021 01:06:01 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 200CB3A13D4 for ; Thu, 11 Feb 2021 01:06:01 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id t18so2210532qvn.8 for ; Thu, 11 Feb 2021 01:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rzMC/L15dsPKMYVp3hQb/BWhwQ2r7l7ZLICmriFwcoc=; b=ut++Lc3MSv1bIk2SHTgks35l4XYzC9rtXCLrRooez7WtbhNSVXu+DrGIDuKL2NbjuR gLQp3CimDNqx7D6msB2k7rzCw/xLzzLVSYqiH+Gje035k7HSYP7UzSMmys4HXI+4C3kw IKUSYcqjVSgo11QTXtN6gKD/x9QTlINeEEshFWviyxJ1zZ888fobmhWnylGKZbQebviu 6yHwzHnRMK3/OPEkGy/AasyojFnqruM+DObVHBWshfCzL7rW/J1ej+AWaNkUWkPm9UiK uFUBF/ppmbN2X2LIGcQgNw4L+G5JlOxxaM6qP/WnjtrZWZbWQLJMcDFS3GoMthqOJ/4s X1Rw== 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=rzMC/L15dsPKMYVp3hQb/BWhwQ2r7l7ZLICmriFwcoc=; b=F1j5eCEZX4Q6lGXo0BmPLv5hnNx6xGVW9OGZ45AH8PTGy32QpOXDVpBJlj1+qhORxM vTCX5kbvIU4hO+RyzOXeHjZGGEXjejWseDe/7LJ59ENiu/x+mAWEQY11aTBDh9PIlA9T U6Hh5VSISYg7ELDzYmG2KS2JG5Duw9+1dhw05VAd8iuAGDWfP4Drw/z5Rq+tg5/WKzU2 Y81h/RZexFZWyho4xZYWBGDoVj3WYXcGYh/DykIkH7SxyZ80+nZmydnReGYEltV9OVVG oElA3fbKAdEfPhXOb0NqdIm12lSmji1pGEQq3c31QcU32Ovya1k23WQgbwEv8PohRw2w FDUQ== X-Gm-Message-State: AOAM533hej92Af1tsrcvyNMun0VcK4nKvXrGiSPoao+sIVHp0h+180Mm iQNBzokuWyl8zRn86s2XJyhkXVjkJJKYQTgkQnc= X-Google-Smtp-Source: ABdhPJxm7mWwJiSmNOyGNujlTolT3zBGiMQ0KSPBxZk3XoxIBgAcy7S50xQ5LBRB+E6KAgM+2W9bYbJxKIIlTEBPp88= X-Received: by 2002:ad4:4390:: with SMTP id s16mr303140qvr.10.1613034358268; Thu, 11 Feb 2021 01:05:58 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> In-Reply-To: From: Yoshifumi Nishida Date: Thu, 11 Feb 2021 01:05:47 -0800 Message-ID: To: Joseph Touch Cc: Kangjiao , "tcpm@ietf.org Extensions" , Liangqiandeng Content-Type: multipart/alternative; boundary="000000000000ef699805bb0bd3c8" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 09:06:06 -0000 --000000000000ef699805bb0bd3c8 Content-Type: text/plain; charset="UTF-8" Hi Joe, On Wed, Feb 10, 2021 at 7:55 AM Joseph Touch wrote: > Hi, all, > > FWIW, my view is that: > > - it MAY be reasonable for an option to negotiate parameters after the TWHS > BUT this can be VERY difficult, esp. because the negotiation needs to > account for segment loss and reordering > > - a new option CANNOT provide that opportunity for existing options > those existing options were defined assuming establishment during the TWHS > > - a new option CANNOT provide that opportunity for new options UNLESS THEY > EXPLICITLY ALLOW IT > I won't disagree with them, but I have a few comments on them. - When we try to define new options, I think we cannot ignore option space size in today's TCP. If there's risk that the option cannot be fit into SYN, protocol designers can think about adopting this approach. Otherwise, they will have to give up using the option or sacrifice some of existing options in some situations. I'm not sure if it's very difficult to negotiate parameters after TWHS because it has already been done in MPTCP. - Not all new options need to negotiate parameters. For example,draft-gomez-tcpm-ack-rate-request or draft-ietf-tcpm-tcp-edo. For these cases, their options can be put into the aggregated option in SYN, which can save some space without any difficulties. - I think we can think about updating existing options to support this approach. At least, I think it's not impossible. But, I guess we should focus on using this for new options at first. Thanks, -- Yoshi > On Feb 10, 2021, at 2:28 AM, Yoshifumi Nishida wrote: > > Hi Kangjiao, > > OK. I think it has some similarities. I will think about this further and > will get back to you. > -- > Yoshi > > On Tue, Feb 9, 2021 at 5:14 PM Kangjiao wrote: > >> Hi Yoshi, >> >> >> >> I wrote a draft to propose an idea for MPTCP subtype capability exchange >> during MPTCP handshake. We think, in MPTCP, some options are mandatory but >> some options can be set as optional ones. So an exchange mechanism of >> actual capability between both parties are needed. >> >> >> >> URL: >> https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exchange/ >> >> Html: >> https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-00.html >> >> Htmlized: >> https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange-00 >> >> >> >> When I read your draft, I think maybe our above work have some relevance >> to your suggestions. If you think it'll help with this work, I hope we can >> discuss this new negotiation mechanism for related options and subtypes. >> Thanks >> >> >> >> Best wishes, >> >> Jiao >> >> >> >> *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Yoshifumi >> Nishida >> *Sent:* Wednesday, February 3, 2021 3:12 PM >> *To:* tcpm@ietf.org Extensions >> *Subject:* [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt >> >> >> >> Hi folks, >> >> >> >> I prepared a draft for SYN option space extensions. >> >> I know this is a difficult issue in TCP and has been discussed for a long >> time. >> >> But, I'm thinking that it might be a good time to discuss it again. >> >> >> >> Key ideas of the draft are the followings. >> >> 1: drastic changes in TCP's spec will not be required >> >> (it does not require updating TCP header format nor using multiple >> SYN packets or additional SYN-like packets) >> >> 2: utilize the option negotiation schemes in mptcp for generic purposes. >> so, I think it can be considered middlebox friendly. >> >> 3: it has some limitations (e.g it can only extend around 30-40 bytes for >> SYN option space). But, if it's combined with EDO, we can use more option >> space. >> >> (depends on how EDO draft will progress, though) >> >> >> >> Please let me know if you have any questions or comments or suggestions. >> >> >> >> Thank you so much! >> >> -- >> >> Yoshi >> >> >> >> >> >> ---------- Forwarded message --------- >> From: >> Date: Tue, Feb 2, 2021 at 10:45 PM >> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt >> To: >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Aggregated Option for SYN Option Space Extension >> Author : Yoshifumi Nishida >> Filename : draft-nishida-tcpm-agg-syn-ext-00.txt >> Pages : 14 >> Date : 2021-02-02 >> >> Abstract: >> TCP option space is scarce resource as its max length is limited to >> 40 bytes. This limitation becomes more significant in SYN segments >> as all options used in a connection should be exchanged during SYN >> negotiations. This document proposes a new SYN option negotiation >> scheme that provide a feature to compress TCP options in SYN segments >> and provide more option space. The proposed scheme does not update >> the format of TCP header nor transmit any additional SYN or SYN-like >> segments so that it has lower risks for middlebox interventions. In >> addition, by combining another proposal for option space extension, >> it is possible to provide further option space. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 >> https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-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/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --000000000000ef699805bb0bd3c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Wed, Feb 10, 2021 at 7:55 AM Jos= eph Touch <touch@strayalpha.com<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">Hi, all,

FWIW, = my view is that:

- it MAY be reasonable for an opt= ion to negotiate parameters after the TWHS
BUT this can be VERY difficult, esp. because the neg= otiation needs to account for segment loss and reordering

- a new option CANNOT provide that opportunity for existing options=
those existing opti= ons were defined assuming establishment during the TWHS

- a new option CANNOT provide that opportunity for new options UNLESS= THEY EXPLICITLY ALLOW IT




<= 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=C2=A0Kangjiao,

OK. I th= ink it has some similarities. I will think about this further and will get = back to you.
--
Yoshi

On Tue, Feb 9, 2021 at 5:14 PM Kan= gjiao <kangjiao= @huawei.com> wrote:

Hi Yoshi,

=C2=A0

I wrote a d= raft to propose an idea for MPTCP subtype capability exchange during MPTCP = handshake.=C2=A0 We think, in MPTCP, some options are mandatory but some options can be set as optional ones. So an exchange mechanism of = actual capability between both parties are needed.

=

=C2=A0=

URL:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capabil= ity-exchange-00.txt

Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 https://datatracker.ietf.org/doc/draft= -kang-tcpm-subtype-capability-exchange/

Html:=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ht= tps://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-0= 0.html

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exc= hange-00

=C2=A0

When I read your draft, I think maybe our above work have so= me relevance to your suggestions. If you think it'll help with this wor= k, I hope we can discuss this new negotiation mechanism for related options and subtypes. T= hanks

=C2=A0

Best wishes,

Jiao

=C2=A0

= From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Wednesday, February 3, 2021 3:12 PM
To: tcpm@ietf.org= Extensions <tcpm= @ietf.org>
Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.t= xt

=C2=A0

Hi folks,

=C2=A0

I prepared a draft for SYN= option space extensions.

I know this is a difficult= issue in TCP and has been discussed for a long time.=C2=A0

But, I'm thinking that= it might be a good time to discuss it again.

=C2=A0

Key ideas of the draft are= the=C2=A0followings.

1: drastic changes in TCP&= #39;s spec will not be required=C2=A0

=C2=A0 =C2=A0 (it does not= require updating TCP header format nor using multiple SYN packets or addit= ional SYN-like packets)

2: utilize the option nego= tiation schemes in mptcp for generic purposes. so, I think it can be consid= ered middlebox friendly.

3: it has some limitations= =C2=A0(e.g it can only extend around 30-40 bytes for SYN option space). But= , if it's combined with EDO, we can use more option space.

=C2=A0 =C2=A0 (depends on = how EDO draft will progress, though)

=C2=A0

Please let me know if you = have any questions or comments or suggestions.

=C2=A0

Thank you so much!<= u>

--

Yoshi=

=C2=A0

=C2=A0

---------- Forwarded messa= ge ---------
From: <int= ernet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-anno= unce@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Aggregated Option for SYN Option Space Extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-agg-syn-ext-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-02-02

Abstract:
=C2=A0 =C2=A0TCP option space is scarce resource as its max length is limit= ed to
=C2=A0 =C2=A040 bytes.=C2=A0 This limitation becomes more significant in SY= N segments
=C2=A0 =C2=A0as all options used in a connection should be exchanged during= SYN
=C2=A0 =C2=A0negotiations.=C2=A0 This document proposes a new SYN option ne= gotiation
=C2=A0 =C2=A0scheme that provide a feature to compress TCP options in SYN s= egments
=C2=A0 =C2=A0and provide more option space.=C2=A0 The proposed scheme does = not update
=C2=A0 =C2=A0the format of TCP header nor transmit any additional SYN or SY= N-like
=C2=A0 =C2=A0segments so that it has lower risks for middlebox intervention= s.=C2=A0 In
=C2=A0 =C2=A0addition, by combining another proposal for option space exten= sion,
=C2=A0 =C2=A0it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg= -syn-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext= -00
https://datatracker.ietf.org/doc/html/draft-nish= ida-tcpm-agg-syn-ext-00


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

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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

--000000000000ef699805bb0bd3c8-- From nobody Thu Feb 11 09:40:07 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984CE3A17D7 for ; Thu, 11 Feb 2021 09:40:05 -0800 (PST) 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, HTML_MESSAGE=0.001, 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=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 vhkPE-vQ_K0y for ; Thu, 11 Feb 2021 09:40:03 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C6D3A17D6 for ; Thu, 11 Feb 2021 09:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8iKyeFY0dE8xmHk5zfVBq8w7DAasWF9kAlvwh+KyHNM=; b=r4i4ZbCYLZz33LajtpqoHGQC9 qJnkZuHdBSKKWFHNWlVoNqWm+ncLkByyHXGb0byUBpeLeWrVz0fpji/gZrhf5v53oDsvg9SL7U3J9 LBfroKYukYZVqeSxegvGmquxapmCV9bIppp/8nKeGRsa1aoyiDENVclfFYLg4z/o3cJPdrfpEb+Vj Lw7RIjciZD5sFUHRkBdNnSqHYcNA/5lVs6GmbMLacaKHqHx+7Kxa5v8Avv17S5L3ju1HeOJfRk0d0 yre3GIxO9NhBCoFX+fPjVNIwXeyR84ZPsa2l1uU7DzJt6UAZnNHetgLYcxprDuVUKt7sX0KyJvta+ LzWdJ5NnQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61195 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 1lAFwW-001Ea7-2C; Thu, 11 Feb 2021 12:39:57 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_671F5342-598B-4E31-A563-EACFD886EBD4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Thu, 11 Feb 2021 09:39:51 -0800 Cc: "tcpm@ietf.org Extensions" , Liangqiandeng Message-Id: References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.60.0.2.21) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 17:40:06 -0000 --Apple-Mail=_671F5342-598B-4E31-A563-EACFD886EBD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Yoshifumi, > On Feb 11, 2021, at 1:05 AM, Yoshifumi Nishida = wrote: >=20 > Hi Joe, >=20 > On Wed, Feb 10, 2021 at 7:55 AM Joseph Touch > wrote: > Hi, all, >=20 > FWIW, my view is that: >=20 > - it MAY be reasonable for an option to negotiate parameters after the = TWHS > BUT this can be VERY difficult, esp. because the negotiation = needs to account for segment loss and reordering >=20 > - a new option CANNOT provide that opportunity for existing options > those existing options were defined assuming establishment = during the TWHS >=20 > - a new option CANNOT provide that opportunity for new options UNLESS = THEY EXPLICITLY ALLOW IT >=20 > I won't disagree with them, but I have a few comments on them. >=20 > - When we try to define new options, I think we cannot ignore option = space size in today's TCP. =20 > If there's risk that the option cannot be fit into SYN, protocol = designers can think about adopting this approach.=20 I think that applies more to the =E2=80=9Ccompressed=E2=80=9D version = than the other part, but compressed options work only for initially flag = (on/off) options with no parameters in the SYN. > Otherwise, they will have to give up using the option or sacrifice = some of existing options in some situations. > I'm not sure if it's very difficult to negotiate parameters after = TWHS because it has already been done in MPTCP. =20 It has been done *within the option*, not as a general case available to = option designers. Those are quite different. > - Not all new options need to negotiate parameters. For = example,draft-gomez-tcpm-ack-rate-request or draft-ietf-tcpm-tcp-edo. > For these cases, their options can be put into the aggregated option = in SYN, which can save some space without any difficulties. Agreed; again, that separates the compressed aspect from other aspects. = Perhaps creating a single compressed option for the next N such = SYN-=E2=80=9Cflag=E2=80=9D options would be useful. > - I think we can think about updating existing options to support this = approach. At least, I think it's not impossible.=20 Updating options is likely to be much more difficult than creating new = ones, which is itself difficult... > But, I guess we should focus on using this for new options at first. Agreed - but again, I=E2=80=99d suggest that all the above applies more = to a single =E2=80=9Cflag options=E2=80=9D option for new options only. That could be done to support the next 16 such flag options options in = one word-aligned option. I don=E2=80=99t know that it would be worth = trying to optimize beyond 16 of those, though. And I do NOT think that this option should waste space trying to game = devices that ignorantly reflect SYN options in SYN-ACK. The definition = in TCP and most such options stands - if an option is reflected in a = SYN-ACK, it is deemed supported. Joe >> On Feb 10, 2021, at 2:28 AM, Yoshifumi Nishida > wrote: >>=20 >> Hi Kangjiao, >>=20 >> OK. I think it has some similarities. I will think about this further = and will get back to you. >> -- >> Yoshi >>=20 >> On Tue, Feb 9, 2021 at 5:14 PM Kangjiao > wrote: >> Hi Yoshi, >>=20 >> =20 >>=20 >> I wrote a draft to propose an idea for MPTCP subtype capability = exchange during MPTCP handshake. We think, in MPTCP, some options are = mandatory but some options can be set as optional ones. So an exchange = mechanism of actual capability between both parties are needed. >>=20 >> =20 >>=20 >> URL: = https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchang= e-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exchan= ge/ = >> Html: = https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchang= e-00.html = >> Htmlized: = https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange-00= = >> =20 >>=20 >> When I read your draft, I think maybe our above work have some = relevance to your suggestions. If you think it'll help with this work, I = hope we can discuss this new negotiation mechanism for related options = and subtypes. Thanks >>=20 >> =20 >>=20 >> Best wishes, >>=20 >> Jiao >>=20 >> =20 >>=20 >> From: tcpm [mailto:tcpm-bounces@ietf.org = ] On Behalf Of Yoshifumi Nishida >> Sent: Wednesday, February 3, 2021 3:12 PM >> To: tcpm@ietf.org Extensions > >> Subject: [tcpm] Fwd: I-D Action: = draft-nishida-tcpm-agg-syn-ext-00.txt >>=20 >> =20 >>=20 >> Hi folks, >>=20 >> =20 >>=20 >> I prepared a draft for SYN option space extensions. >>=20 >> I know this is a difficult issue in TCP and has been discussed for a = long time.=20 >>=20 >> But, I'm thinking that it might be a good time to discuss it again. >>=20 >> =20 >>=20 >> Key ideas of the draft are the followings. >>=20 >> 1: drastic changes in TCP's spec will not be required=20 >>=20 >> (it does not require updating TCP header format nor using = multiple SYN packets or additional SYN-like packets) >>=20 >> 2: utilize the option negotiation schemes in mptcp for generic = purposes. so, I think it can be considered middlebox friendly. >>=20 >> 3: it has some limitations (e.g it can only extend around 30-40 bytes = for SYN option space). But, if it's combined with EDO, we can use more = option space. >>=20 >> (depends on how EDO draft will progress, though) >>=20 >> =20 >>=20 >> Please let me know if you have any questions or comments or = suggestions. >>=20 >> =20 >>=20 >> Thank you so much! >>=20 >> -- >>=20 >> Yoshi >>=20 >> =20 >>=20 >> =20 >>=20 >> ---------- Forwarded message --------- >> From: > >> Date: Tue, Feb 2, 2021 at 10:45 PM >> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt >> To: > >>=20 >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Aggregated Option for SYN Option Space = Extension >> Author : Yoshifumi Nishida >> Filename : draft-nishida-tcpm-agg-syn-ext-00.txt >> Pages : 14 >> Date : 2021-02-02 >>=20 >> Abstract: >> TCP option space is scarce resource as its max length is limited = to >> 40 bytes. This limitation becomes more significant in SYN = segments >> as all options used in a connection should be exchanged during SYN >> negotiations. This document proposes a new SYN option negotiation >> scheme that provide a feature to compress TCP options in SYN = segments >> and provide more option space. The proposed scheme does not = update >> the format of TCP header nor transmit any additional SYN or = SYN-like >> segments so that it has lower risks for middlebox interventions. = In >> addition, by combining another proposal for option space = extension, >> it is possible to provide further option space. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 = >> = https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00 = >>=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 = _______________________________= ________________ >> 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 --Apple-Mail=_671F5342-598B-4E31-A563-EACFD886EBD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Yoshifumi,

On Feb 11, 2021, at 1:05 AM, Yoshifumi = Nishida <nsd.ietf@gmail.com> wrote:

Hi Joe,

On Wed, Feb 10, 2021 at 7:55 AM Joseph Touch <touch@strayalpha.com> wrote:
Hi, all,

FWIW, my view is that:

- it MAY be reasonable for an option to = negotiate parameters after the TWHS
BUT this can be = VERY difficult, esp. because the negotiation needs to account for = segment loss and reordering

- a new option CANNOT provide that opportunity for existing = options
those existing options were defined assuming = establishment during the TWHS

- a new option CANNOT provide that = opportunity for new options UNLESS THEY EXPLICITLY ALLOW = IT

I won't disagree with them, but I have a few comments on = them.

- When = we try to define new options, I think we cannot ignore option = space size in today's TCP.  
  If = there's risk that the option cannot be fit into SYN, protocol designers = can think about adopting this = approach. 

I think that applies more to the =E2=80=9Ccompressed= =E2=80=9D version than the other part, but compressed options work only = for initially flag (on/off) options with no parameters in the = SYN.

  Otherwise, they will have to give up using the = option or sacrifice some of existing options in some = situations.
  I'm not sure if it's very = difficult to negotiate parameters after TWHS because it has already = been done in = MPTCP.  

It has been done *within the option*, not as a = general case available to option designers. Those are quite = different.

- Not all new options need to negotiate parameters. For = example,draft-gomez-tcpm-ack-rate-request or = draft-ietf-tcpm-tcp-edo.
  For these cases, = their options can be put into the aggregated option in SYN, which can = save some space without any = difficulties.

Agreed; again, that separates the compressed = aspect from other aspects. Perhaps creating a single compressed option = for the next N such SYN-=E2=80=9Cflag=E2=80=9D options would be = useful.

- I think we can think about updating existing options to = support this approach. At least, I think it's not = impossible. 

Updating options is likely to be much more = difficult than creating new ones, which is itself difficult...

  = But, I guess we should focus on using this for new options at = first.

Agreed - but again, I=E2=80=99d suggest that all the = above applies more to a single =E2=80=9Cflag options=E2=80=9D option for = new options only.

That could be done = to support the next 16 such flag options options in one word-aligned = option. I don=E2=80=99t know that it would be worth trying to optimize = beyond 16 of those, though.

And I do = NOT think that this option should waste space trying to game devices = that ignorantly reflect SYN options in SYN-ACK. The definition in TCP = and most such options stands - if an option is reflected in a SYN-ACK, = it is deemed supported.

Joe


On Feb 10, 2021, at 2:28 AM, = Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

Hi Kangjiao,

OK. I think it has some similarities. I = will think about this further and will get back to you.
--
Yoshi

On Tue, Feb = 9, 2021 at 5:14 PM Kangjiao <kangjiao@huawei.com> wrote:

Hi Yoshi,

 

I wrote a draft to propose an idea for MPTCP subtype = capability exchange during MPTCP handshake.  We think, in MPTCP, = some options are mandatory but some options can be set as optional ones. So an exchange mechanism = of actual capability between both parties are needed.

 

URL:          = ;  https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capabil= ity-exchange-00.txt

Status:         = https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capabi= lity-exchange/

Html:         &nbs= p; https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capabil= ity-exchange-00.html

Htmlized:       https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-= exchange-00

 

When I read your draft, I think maybe our above work = have some relevance to your suggestions. If you think it'll help with = this work, I hope we can discuss this new negotiation mechanism for related options and = subtypes. Thanks

 

Best wishes,

Jiao

 

From: tcpm = [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Wednesday, February 3, 2021 3:12 PM
= To: tcpm@ietf.org Extensions <tcpm@ietf.org>
Subject: [tcpm] Fwd: I-D Action: = draft-nishida-tcpm-agg-syn-ext-00.txt

 

Hi = folks,

 

I = prepared a draft for SYN option space extensions.

I = know this is a difficult issue in TCP and has been discussed for a long = time. 

But, I'm thinking that it might be a good time to discuss it = again.

 

Key= ideas of the draft are the followings.

1: = drastic changes in TCP's spec will not be required 

    (it does not require updating TCP header format = nor using multiple SYN packets or additional SYN-like packets)

2: = utilize the option negotiation schemes in mptcp for generic purposes. = so, I think it can be considered middlebox friendly.

3: = it has some limitations (e.g it can only extend around 30-40 bytes = for SYN option space). But, if it's combined with EDO, we can use more = option space.

    (depends on how EDO draft will progress, = though)

 

Please let me know if you have any questions or comments or = suggestions.

 

Thank you so much!

--

Yoshi

 

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-announce@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts = directories.


        Title          =  : Aggregated Option for SYN Option Space Extension
        Author          : = Yoshifumi Nishida
        Filename        : = draft-nishida-tcpm-agg-syn-ext-00.txt
        Pages          =  : 14
        Date          =   : 2021-02-02

Abstract:
   TCP option space is scarce resource as its max length is = limited to
   40 bytes.  This limitation becomes more significant in = SYN segments
   as all options used in a connection should be exchanged = during SYN
   negotiations.  This document proposes a new SYN option = negotiation
   scheme that provide a feature to compress TCP options in = SYN segments
   and provide more option space.  The proposed scheme = does not update
   the format of TCP header nor transmit any additional SYN or = SYN-like
   segments so that it has lower risks for middlebox = interventions.  In
   addition, by combining another proposal for option space = extension,
   it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext= /

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00
https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-sy= n-ext-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/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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

= --Apple-Mail=_671F5342-598B-4E31-A563-EACFD886EBD4-- From nobody Thu Feb 11 13:33:45 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DE93A0AD1 for ; Thu, 11 Feb 2021 13:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 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.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNEJTDCw1ZIm for ; Thu, 11 Feb 2021 13:33:40 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 139143A09A5 for ; Thu, 11 Feb 2021 13:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yK0uog51+qhfUva8pHkXNYGoE6Nlmv0Y0PmqZWpzwyU=; b=QaZmV3QB2ZLzsCV6Rmxe0+aEWv S0BIhR/QMBPlCHjP/3lUsplz6XXyC+JBoAno13vTpCP+Y6El+0PCVTnxxqM2tr8p+AQV+q8+ex7JG Xib9pc1eFLki6Q49gN50gu0TJP4h1jI8eM4CIcM5JpR0IlCOkO1CbGeQTF6TQD9KooS/VeXAAVWnt KIxnOUO/KqyP5JUoFv7sIgb2nPBgUv04YAc2vO4l6Oj7gG2lO49S6mteH4B0ZjBED2hhe3MRBr1y0 WdA8cK/by29umud+rRtY3YrgvqhYxQQRbOCP3TcuK4bXS0kYhNaptzN3rCBL1G4igySjGnpkJ0hMn n3BMYbnQ==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:49586 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lAJak-0006ci-MX; Thu, 11 Feb 2021 21:33:38 +0000 To: "Scharf, Michael" , "Scheffenegger, Richard" , Mirja Kuehlewind Cc: tcpm IETF list References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <381499f5-3333-08c5-2ffd-fba77e027795@bobbriscoe.net> From: Bob Briscoe Message-ID: <1e61a7d3-b6be-d995-4fc2-777bc2d5d5fe@bobbriscoe.net> Date: Thu, 11 Feb 2021 21:33:36 +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: 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 - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 Feb 2021 21:33:44 -0000 On 09/02/2021 17:56, Scharf, Michael wrote: > Bob, > >> -----Original Message----- >> From: Bob Briscoe >> Sent: Tuesday, February 9, 2021 5:58 PM >> To: Scheffenegger, Richard ; Mirja >> Kuehlewind ; Scharf, Michael > esslingen.de> >> Cc: tcpm IETF list >> Subject: Re: AW: [tcpm] AccECN field order >> >> Richard, >> >> I just noticed I missed the last para of the old email from you below. >> Response inline, tagged [BB]... >> >> On 23/11/2020 12:42, Scheffenegger, Richard wrote: >>> I am also in favor of using two distinct option codes. >>> >>> However, >>> >>>> Or I guess we could say that only one option should be used for a >> connection. >>> I am opposed to this - with two option codes, a sender should be free to >> choose whichever he prevers at any one point; For example, if the sender a >> segment (e.g. may be the receiver side) has to update the EE1 couter, but >> also convey SACK information, it would be good to use the one, where the >> EE1 field is first, and omit all remaining fields; >>> Later in the same connection, that very same host may choose to update >> the CE field together with some SACK information, and use the other >> codepoint in order to preserve as much TCP option space for the SACK >> option... >> >> [BB] I agree with you here (and disagree with Mirja below). The nice >> thing about 2 options kinds is they are self-describing, so they can be >> stateless (for instance, consider the code you would have to otherwise >> add for when a host switches to a different congestion control module - >> a lot of complexity despite being unlikely to happen). >> >>> >>> As for extensibility: I would want to avoid that topic, and just specifiy the >> three correct supported lengths here, and not mention (other than ignoring >> "odd" fractionals of the 3-byte wide counters) what happens with other >> lengths... >> >> [BB] A protocol spec should surely say what to do with unexpected >> inputs. Not specifying this is one of the main reasons we have such >> trouble changing things later - because we discover some implementers >> handled the unexpected in different ways to others (e.g. ignore, vs RST >> the connection), and others only handled expected inputs and didn't even >> think to check for anything else. >> >> So, I believe we have to either say "reset the connection" or "ignore", >> in response to an unexpected option length. I figure that, if there's no >> harm in ignoring something unexpected, then why not ("liberal in what >> you receive" principle). >> >> Earlier in this thread, Michael Scharf pointed out that there is some >> potential harm here (covert channel of up to 29B), but I pointed out >> that TCP/IP has plenty of other ways of creating covert channels, so >> we're not really adding to any problem here. But I did say that we would >> highlight the covert channel in the Security Considerations section, so >> the Sec Area has a chance to object. If it raises as serious concern, >> then we should switch from "ignore" to "reset", But I doubt it will. > I think we first have to come to the conclusion *inside* TCPM whether such a new covert channel is actually acceptable. > > Existing covert channels do not at all imply that a new covert channel is a good idea (and, IMHO, 29B per packet is a lot). Network administrators and operators know how to deal with the existing problems in TCP/IP. Adding any new security issue needs careful reasoning. > > As individual contributor to TCPM, I believe that this covert channel must just be removed from the next version of the draft. At least I don't need other opinions to come to this personal conclusion. > > If this was less obvious others in the WG, TCPM could ask for an early SECDIR review to get further guidance ASAP. Then this question can be sorted out while we finish the protocol. > > If TCPM needs any external input on covert channels, I think an early SECDIR review would be a much better approach compared to having a security discussion during IETF last call. We are here discussing a standards track extension of one of the core Internet protocols. In such a case, at least in my view on IETF processes, other IETF areas can expect that TCPM ties to deal with known open issues within the WG as far as possible, i.e., before they see a "stable" specification in the IETF last call. > > In a nutshell: > > -1 on leaving this question open until IETF last call [BB] That's a perfectly reasonable process proposal. I just wanted to add that there are not just 2 choices: the WG (with advice from SEC area if necessary) is free to limit the bandwidth of this covert channel anywhere between 0 and 29B per packet by simply limiting how much extensibility the protocol allows the option length field to offer, with a 0B covert channel corresponding to no extensibility. Bob > > Michael > > > >> Cheers >> >> >> >> Bob >> >>> >>> Richard Scheffenegger >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Mirja Kuehlewind >>> Gesendet: Montag, 23. November 2020 12:39 >>> An: Neal Cardwell ; Scharf, Michael >> ; Bob Briscoe >>> Cc: Yoshifumi Nishida ; tcpm IETF list >> ; Scheffenegger, Richard >> ; Michael Tuexen > muenster.de>; tcpm-chairs@ietf.org >>> Betreff: Re: [tcpm] AccECN field order >>> >>> NetApp Security WARNING: This is an external email. Do not click links or >> open attachments unless you recognize the sender and know the content is >> safe. >>> >>> >>> >>> Hi all, >>> >>> I think I also support two options as this is the most simple solution. >>> >>> We probably need to look at section 3.2.3.2. (Path Traversal of the AccECN >> Option) again, as I think this section assumes mostly one option. Or I guess >> we could say that only one option should be used for a connection. >>> Regarding use of the option length for extensibility. I know new options are >> hard to deploy but that’s the extensibility mechanism we have with TCP. Not >> sure we want to invent a new now. If we think we need more extensibility >> for AccECN for any reason, we should specify valid option length values that >> include a flags field now. >>> Mirja >>> >>> >>> >>>> On 18. Nov 2020, at 01:03, Neal Cardwell wrote: >>>> >>>> As someone who contributes to a TCP implementation, I would put in a >> vote for the "Two Option Kinds" proposal outlined in slide 6 here: >>>> >>>> https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor >>>> e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica >>>> tion-01#page=6 >>>> >>>> This approach has the virtue of simplicity, which hopefully may help avoid >> middlebox bugs, speed standardization and development, and ease the >> process of maintaining fast and stable implementations. >>>> neal >>>> >>>> >>>> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael > esslingen.de> wrote: >>>> Inline some comments [ms]. >>>> >>>> >>>> >>>> Given that I don’t ask for any text chances, I’ll not follow-up forever in this >> discussion. I don’t own running code and a lot of encoding details mainly >> affect an implementation. >>>> >>>> >>>> IMHO the rest of the WG has to think about the option design more than >>>> me. So, this is mostly about triggering a discussion… >>>> >>>> >>>> >>>> From: Bob Briscoe >>>> Sent: Tuesday, November 17, 2020 1:20 PM >>>> To: Scharf, Michael ; Yoshifumi >>>> Nishida >>>> Cc: Michael Tuexen ; tcpm-chairs@ietf.org; >>>> Mirja Kuehlewind ; Scheffenegger, Richard >>>> ; tcpm IETF list >>>> Subject: Re: AccECN field order >>>> >>>> >>>> >>>> Michael, >>>> >>>> On 17/11/2020 08:10, Scharf, Michael wrote: >>>> >>>> Bob, >>>> >>>> >>>> >>>> I am fine with the two option kinds proposed in -13, but I don’t buy your >> arguments why this encoding is better than others. >>>> >>>> >>>> Most importantly, I don’t think that your “forward compatibility” >> argument is a very compelling reason for two codepoints. All proposals I am >> aware of have their pros and cons. And I am not aware of a really >> comprehensive discussion. At least neither the e-mail below nor today’s >> meeting discuss all tradeoffs I would investigate. >>>> >>>> [BB] You're right - the discussion below is useful and necessary. >>>> >>>> >>>> >>>> >>>> >>>> For instance, the benefit of the length encoding variant would be to >> consume only one TCP option codepoint now. If we decided later to that a >> flag byte is needed (say, at the end), a follow-up proposed standard could >> specify another option format with that flag byte, using a second codepoint. >>>> >>>> [BB] >>>> * The new codepoint would require years to deploy (including in proxies) >> before it works e2e. >>>> >>>> >>>> [ms] That may depend *a lot* on the environment. In environments >> where ECN can get deployed today, say in datacenters, rolling out a new >> kernel version may perhaps not be the biggest operational challenge. Also, >> proxies may not be a significant problem in some of those cases. Deployment >> roadmaps are very hard to predict. >>>> >>>> * Whereas the 'forward compatibility' approach tries to ensure that >> AccECN implementations that are being built today will be ready to interwork >> with a future extension. >>>> * In contrast, if your hypothetical new AccECN codepoint did need to be >> deployed later, it would need to include a fall-back to the current AccECN >> option when one peer doesn't understand the new codepoint. >>>> >>>> >>>> [ms] This is a reasonable point, albeit not a particularly strong one, >>>> given that the option is not really required for basic >>>> interoperability. Also, a hypothetical follow-up standard could >>>> include a way to explicitly request the option… >>>> >>>> >>>> * Fall-back would need to avoid a second round of handshake (given >>>> this is for low latency), which would only work reliably with an >>>> option on the SYN (because the 3rd ACK is unreliable) >>>> >>>> >>>> >>>> [ms] I can’t follow. If an endpoint is unhappy with getting AccECN option >> “A” from a peer, I could send a “please send me the better AccECN option B” >> after the 3-WHS. It could be an upgrade, not a fallback. Also, at this point we >> don’t know what option B would be and in which context it would be >> needed. Maybe other protocol features would require negotiation, too. >> IMHO it is a solvable problem. >>>> >>>> * AccECN has so far avoided using any SYN option space, which is >> important given that is the scarcest resource. >>>> >>>> >>>> [ms] Yep, but as long as no proposal needs SYN options, this is nothing >> that would make one solution better than another. >>>> These days, extending TCP is like playing chess - we have to think multiple >> moves ahead! >>>> >>>> >>>> [ms] There is one fundamental difference between chess and TCP: In >> chess you precisely know the current situation and can predict all potential >> moves in advance (albeit there are a lot). However, we don’t know the >> future evolution of TCP, ECN and the Internet as a whole, nor future >> requirements. If we try to engineer a TCP extension for some potential >> future, we may figure out later that reality is different from what we >> designed for. As much as I appreciate your attempts to predict the future, it >> would be a big surprise to me if you could correctly predict what TCP will be in >> 10 years from now. So, instead of trying to write specifications that take into >> account future requirements, which are in fact just unknown, it is more >> important for me to write effective, efficient and secure specifications for >> what is currently known for sure. >>>> >>>> >>>> [ms] I *don’t* know for sure whether the current AccECN option will be >> needed, but I see quite some evidence that support of the AccECN option(s) >> is not a top priority these days. That is also something to think about when >> designing the details. >>>> >>>> >>>> I need to learn to articulate onto the list all my reasons for rejecting >> certain parts of the design space. Sorry about that. >>>> Yes, I admit, the current proposal is at the cost of burning two TCP option >> codepoints. However, you said yourself when you proposed this approach, >> that they are not (currently) a scarce resource. Certainly not as scarce as >> option space. I just checked: roughly 15% of the option codepoint allocation >> space has been used so far. So that's where I would suggest we compromise >> first. >>>> [ms] I made a similar calculation some years ago and came to a similar >> conclusion. Investing two codepoints for AccECN is something we can >> probably afford. But nonetheless we have to reason carefully why it is really >> worth the effort. >>>> >>>> >>>> >>>> Regarding the resulting codepoint consumption (two option kinds) and >> the addition of a flag byte, this approach would basically end up with the >> same result as the current proposal in -13 plus some hypothetical future >> addition leveraging the length field beyond the currently known use. >>>> >>>> >>>> And, yes, the length encoding variant may be less flexible and/or >> consume some more bits in some cases, but on the plus side it only needs >> one codepoint now – and given that it is entirely unclear whether any >> AccECN option will indeed be widely used in future, this is a big plus. The fact >> that implementers are quite silent on the option design is not a good sign. >>>> >>>> [BB] Here's another possibility then. >>>> >>>> a) [K|L| EE1B | ECEB | EE0B ] >>>> b) [K|L| EE1B | ECEB | EE0B |F] if F = 0bXXXXXXX0 >>>> c) [K|L| EE0B | ECEB | EE1B |F] if F = 0bXXXXXXX1 >>>> >>>> We'd have to decide which order alternative (a) takes. I've picked EE1B >> first only 'cos you're right that there is not currently as much pressure (on the >> public Internet) for AccECN with ECT(0). >>>> ==Legend== >>>> K: Kind (1B) >>>> L: Length (1B) >>>> ExxB: Echo xx byte counter >>>> F: Flags (1B) >>>> >>>> Alternatives a) and b) are equivalent, at least while the only allocated flag >> is for field order. >>>> However, alternative b) is available in case other flags are allocated >>>> in future The flags byte can only be omitted if (L % 3 == 2). >>>> The flags byte is considered present if (L % 3) == 0. >>>> >>>> Forward compatibility: Options with (L % 3 == 1) MUST be assumed to >> include a flags byte, and current implementations ignore the last byte. >>>> The flags byte is optional to implement (even if the AccECN option is >>>> implemented) If the server includes a flags byte on the SYN/ACK but the >> client does not include one on the 3rd ACK or the first data packet, the server >> assumes the client does not implement the flags byte and uses only >> alternative a) for the remainder of the connection. >>>> >>>> [ms] I am not sure if we need that, but I take this as existence proof that >> other encodings are possible. Personally, I think that other solutions would >> be doable if you took one bit from one or multiple counters for format >> encoding. At least for some of the byte counters I don’t think taking one bit >> for other purposes would result in an Internet congestion collapse… But, I >> have already said that the -13 proposal works for me, so I’ll not try to come >> up with another variant myself. >>>> >>>> >>>> To me, one potential difference between two proposals would be >> incremental deployment. The proposal in -13 only has an advantage if >> middleboxes such as firewalls will indeed pass TCP options with a format that >> contains content beyond the (first) Accurate ECN standard (i.e., currently >> unused length values). IMHO it is too early to know whether firewalls would >> indeed allow this in future. >>>> >>>> >>>> From a security perspective, it is not clear to me whether allowing >> arbitrary unspecified bytes in a TCP option is a good idea *at all*. It will be >> interesting to hear the opinion from SEC area on that. Personally, I am not >> convinced that this really makes sense, but I my concerns are not strong >> enough to formally push back. I’ll leave it to others to think about whether >> this is a bug or a feature. >>>> >>>> [BB] Well, let's first try to deal with security ourselves: >>>> * Octets that are explicitly declared as part of an option cannot be used >> for a buffer overflow attack. I don't really need to, but I could add the >> following text to the forward compatibility wording: >>>> A receiver considers octets beyond those it uses, but within the >> specified length, as if they are padding. >>>> * And such octets cannot be any different from the current ability of a >> sender to add padding. So there's no new attack possible here. >>>> * And there's no need to specify a max length for any AccECN Option, >> which would just unnecessarily limit flexibility. >>>> [ms] I have more thought about the covert channel that some unspecified >> bytes in a standards track TCP option could offer… In particular if the AccECN >> option gets widely deployed and used, would some malicious users find >> those bytes useful? For what? For instance, what in the AccECN protocol >> design prevents use of these “padding” bytes as super-cookie? To me, it is >> much more important to think about abuse of whatever we standardize >> *now*, instead of engineering for some entirely unknown future. I am not a >> security expert, but I suggest a careful analysis of any security implications of >> the AccECN option. We seldomly specify new TCP options and malicious >> users will certainly look for “opportunities” in the spec. So far, I don’t know >> whether that whole idea of forward compatibility is a feature or a bug. >>>> >>>> >>>> Michael >>>> >>>> >>>> >>>> Maybe one lesson learnt is that the document could have a non- >> normative appendix that explains the rationale for the finally picked TCP >> option encoding. That may also help if there are further questions whether >> two codepoints are really required, e.g. by the IESG (if two codepoints are >> still the design after WGLC). At least for past TCP option codepoint allocations >> I recall some discussions late in the IETF process. In those past cases, good >> arguments in an appendix and running code has helped a lot. >>>> >>>> [BB] I can do that. Appx B is already similar, giving Design Rationale for the >> ACE field. >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> >>>> Michael >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: Bob Briscoe >>>> Sent: Tuesday, November 17, 2020 6:10 AM >>>> To: Scharf, Michael ; Yoshifumi >>>> Nishida >>>> Cc: Michael Tuexen ; tcpm-chairs@ietf.org; >>>> Mirja Kuehlewind ; Scheffenegger, Richard >>>> ; tcpm IETF list >>>> Subject: Re: AccECN field order >>>> >>>> >>>> >>>> Michael, >>>> >>>> On 16/11/2020 17:36, Scharf, Michael wrote: >>>> >>>> Bob, >>>> >>>> >>>> >>>> One proposal using the length field with *one option codepoint only* >>>> is detailed in: >>>> https://mailarchive.ietf.org/arch/msg/tcpm/zo- >> 1OR0nRfhHocX8yvTvpC4BNMo >>>> / >>>> >>>> >>>> >>>> It is the third option mentioned in this e-mail. One example would be to >> use option length values 5/8/11 for one encoding type and option length >> values 6/9/12 for the other encoding type (i.e., order of fields). Or one could >> use some other combination of length values – the only requirement is that a >> certain value for the option length is only used by one of the option formats. >> In that approach, the value of the length field would thus directly describe >> the encoding of the option. Unless I miss something, this would work and it >> would just require one option codepoint. >>>> >>>> >>>> Thus, alternatives to two option codepoints exist and I have explained >> them on the list in March 2020. >>>> >>>> OK, sorry, yes, I remember this now. >>>> >>>> As I will explain in the AccECN status update talk today in virtual Bangkok, >> the draft has made provision for different length values than 5/8/11. It says >> existing implementations MUST accept length values other than those >> currently defined. But then read in as many whole 3-byte fields as they can. >>>> This can be used to add a flags byte on the end in future, for extensibility. >> Or any other form of extensibility the WG might decide in the future. >>>> I know a flags byte at the end seems odd compared to at the beginning. >> But (if decided it's needed in future) it's reasonably easy to implement by >> reading the whole option, then processing the last byte, before reading the >> rest of the option. >>>> I believe you will agree that this is a better way to utilize different lengths. >>>> >>>> And thank you for repeatedly emphasizing that you're happy with the 2- >> kind scheme, or other alternatives. >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> >>>> >>>> Anyway, I don’t really care how the options are encoded as long as the >> receiver doesn’t need per-connection state for decoding a TCP option. So, >> personally, I would be fine with using e.g. the length field as described in my >> old e-mail. Or an additional flag byte. And one could come up with further >> encodings, e.g., by using one or a few bits as a short “type” field for each >> counter. This is all about protocol engineering. And all these variants have >> their pros and cons. >>>> >>>> >>>> I am also fine with using two option codepoints as specified in -13; this is >> probably the approach that consumes the least number of bits. >>>> >>>> >>>> Michael (w/o any hat) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: Bob Briscoe >>>> Sent: Monday, November 16, 2020 5:52 PM >>>> To: Yoshifumi Nishida >>>> Cc: Scharf, Michael ; Michael Tuexen >>>> ; tcpm-chairs@ietf.org; Mirja Kuehlewind >>>> ; Scheffenegger, Richard >>>> ; tcpm IETF list >>>> Subject: AccECN field order >>>> >>>> >>>> >>>> Yoshi, (adding the tcpm list in cc) >>>> >>>> On 05/11/2020 06:58, Yoshifumi Nishida wrote: >>>> >>>> Hi Bob, >>>> >>>> >>>> >>>> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe >> wrote: >>>> Yoshi, >>>> >>>> On 04/11/2020 06:51, Yoshifumi Nishida wrote: >>>> >>>> Hi, folks, >>>> >>>> >>>> >>>> >>>> >>>> >>>> In my understanding, I'm not sure if we settled down on using two option >> kinds or encoding schemes for 24bits fields in acc ecn draft. >>>> So, I think there're still something to be clarified and hope things will be >> settled at the meeting. >>>> >>>> [BB] I know a WG can change it's mind at any time. But I'd rather we just >> clarified what a previous decision was, to avoid the need to keep re-opening >> discussion on a question that have been decided then changed three >> different ways already. >>>> My memory is not so good these days. I trusted that Michael S >> remembered the decision correctly, and I seem to remember that decision >> being made. >>>> I've just checked the minutes of the last interim: >>>> >>>> https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 >>>> 1600/ and they mention Michael's proposal to use two kinds, but don't >>>> record any decision. >>>> The jabber log gives no clues about any decision. >>>> >>>> I can't find an audio or video recording. Can you point me at one? >>>> >>>> >>>> >>>> I thought that it's because there was no clear decision at the meeting. >>>> >>>> But, you can check https://www.youtube.com/watch?v=KsB0_Nb8-kA >>>> >>>> Please let us know if you have any questions or opinions with regard to >> this. >>>> >>>> [BB] I checked the Youtube link you sent below. >>>> >>>> First I think we're agreed no-one was fighting for us to keep the previous >> way we did this (using the initial value of the field to set the order for the >> connection). >>>> In my presentation I said there was strong resistance from Michael to do it >> a different way. >>>> (also, offlist, the co-authors including me also didn't like this so >>>> much. And Ilpo said it made the implementation complex.) >>>> >>>> Then came the question of what we do instead. There were three >> alternative proposals: >>>> a) use 2 option kinds >>>> b) add a flags byte >>>> c) somehow use the length field maybe >>>> >>>> Michael raised (c) in the meeting as a possibility, but no-one could think >> how to distinguish two options of the same length but a different field order >> using the length field. Michael said he'd post any ideas to the list if he could >> think of any, but that didn't happen. >>>> So we're left choosing between (a) and (b). >>>> I said in the meeting (and on the list when discussing with Ilpo) that I'd be >> happy to go with (b), but only if there was another use for a flag. Because it >> would consume 1B more options space in many packets, which is a scarce >> resource. >>>> Ilpo had a proposed use for another flag (to help synch counters after a >> loss), but I think the discussion about it ended that it wouldn't be helpful, 'cos >> the way it worked depended on itself (circular logic). >>>> In conclusion, I don't think there was an explicit decision to go with 2 >> option kinds, but it ended up as the 'last person standing'. >>>> I like it. It's simple. And apparently option kinds are not such a scarce >> resource. >>>> Perhaps we can ratify this in the WG tomorrow. >>>> >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -- >>>> >>>> Yoshi >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >> __________________________________________________________ >> ______ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> >>>> >>>> >>>> >>>> -- >>>> >> __________________________________________________________ >> ______ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> >>>> >>>> >>>> -- >>>> >> __________________________________________________________ >> ______ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> -- >> __________________________________________________________ >> ______ >> Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Feb 12 07:19:39 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913443A1667 for ; Fri, 12 Feb 2021 07:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 yEccU-Gy0C6H for ; Fri, 12 Feb 2021 07:19:34 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3383A1657 for ; Fri, 12 Feb 2021 07:19:33 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:d16c:2458:32da:4617] (unknown [IPv6:2a02:8109:1140:c3d:d16c:2458:32da:4617]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 58E2B721BE030; Fri, 12 Feb 2021 16:19:29 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Michael Tuexen In-Reply-To: Date: Fri, 12 Feb 2021 16:19:26 +0100 Cc: Yuchung Cheng , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> References: To: Neal Cardwell X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:19:38 -0000 > On 11. Feb 2021, at 06:22, Neal Cardwell = wrote: >=20 > The wording in the Congestion Control section looks great to me. >=20 > > Minor: = https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 >=20 > I agree with Yuchung that it would be nice to clarify what is meant by = "idle" connections (in the pre-existing text), with respect to = keep-alives. It seems at least the historical behavior for two of the = major implementations out there interpret this in different ways, and = this has caused some confusion in the developer community about what = semantics to expect from TCP keep-alives. I guess the rfc793bis-20 draft = does have some nice new text (that does not seem to be in RFC793 or = RFC1122) that seems to shed some light on this: >=20 > Keep-alive packets MUST only be sent when no sent data is > outstanding, and no data or acknowledgement packets have been > received for the connection within an interval (MUST-26). >=20 >=20 > That sentence helps quite a bit. It seems to correspond to the last 20 = years of Linux TCP keep-alive behavior, but not the BSD behavior (at = least BSD TCP as documented in Stevens volume 2; I have not checked more = recent BSD kernels). Can elaborate what Linux behaviour you are referring to an what BSD = behaviour you are referring to? Best regards Michael >=20 > And, yes, thank you, Wes for all your years of effort on this! >=20 > neal >=20 >=20 >=20 > On Wed, Feb 10, 2021 at 7:14 PM Yuchung Cheng = wrote: > I think it's ready. Kudos to Wes for the N-years-long effort to put > this together! >=20 > Minor: = https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 >=20 > The less clear part is the wording of "idle connections". Idleness can > be interpreted in several ways: no recent rx, tx, or both {on the wire > | on socket interface}. It'd be good to define more clearly. AFAIK > implementations have different definitions already leading to > different KA behaviors. >=20 >=20 >=20 >=20 > On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael > wrote: > > > > Dear all, > > > > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According = to Wes, all WGLC feedback should be reflected in this version. A link to = a complete diff can be found below. > > > > During WGLC, there has been quite some discussion on the exact = wording on congestion control. The suggested text in version -20 is = copied below: > > > > 3.7.2. TCP Congestion Control > > > > RFC 2914 [7] explains the importance of congestion control for = the > > Internet. > > > > RFC 1122 required implementation of Van Jacobson's congestion = control > > algorithms slow start with congestion avoidance together with > > exponential back-off for successive RTO values for the same = segment. > > RFC 2581 provided IETF Standards Track description of slow start = and > > congestion avoidance, along with fast retransmit and fast = recovery. > > RFC 5681 is the current description of these algorithms and is = the > > current Standards Track specification providing guidelines for = TCP > > congestion control. RFC 6298 describes exponential back-off of = RTO > > values, including keeping the backed-off value until a subsequent > > segment with new data has been sent and acknowledged. > > > > A TCP endpoint MUST implement the basic congestion control = algorithms > > slow start, congestion avoidance, and exponential back-off of RTO = to > > avoid creating congestion collapse conditions (MUST-19). RFC = 5681 > > and RFC 6298 describe the basic algorithms on the IETF Standards > > Track that are broadly applicable. Multiple other suitable > > algorithms exist and have been widely used. Many TCP = implementations > > support a set of alternative algorithms that can be configured = for > > use on the endpoint. An endpoint may implement such alternative > > algorithms provided that the algorithms are conformant with the = TCP > > specifications from the IETF Standards Track as described in RFC > > 2914, RFC 5033 [10], and RFC 8961 [15]. > > > > Explicit Congestion Notification (ECN) was defined in RFC 3168 = and is > > an IETF Standards Track enhancement that has many benefits [50]. > > > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 = (SHLD- > > 8). > > > > As document shepherd I ask everybody - specifically all TCPM = contributors who have commented on congestion control - to carefully = review this proposed wording within the next few days. If there are any = issues with this suggested resolution of the WGLC, please speak up! > > > > If the TCPM working group is fine with version -20, 793bis would be = ready to go. > > > > Thanks > > > > Michael > > > > > > -----Original Message----- > > From: I-D-Announce On Behalf Of = internet-drafts@ietf.org > > Sent: Thursday, January 21, 2021 7:02 PM > > To: i-d-announce@ietf.org > > Cc: tcpm@ietf.org > > Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the TCP Maintenance and Minor = Extensions WG of the IETF. > > > > Title : Transmission Control Protocol (TCP) = Specification > > Author : Wesley M. Eddy > > Filename : draft-ietf-tcpm-rfc793bis-20.txt > > Pages : 110 > > Date : 2021-01-21 > > > > 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-20 > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Feb 12 07:53:19 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6693A1767 for ; Fri, 12 Feb 2021 07:53:17 -0800 (PST) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLVRvfGcBFyp for ; Fri, 12 Feb 2021 07:53:13 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5203A17AA for ; Fri, 12 Feb 2021 07:53:11 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id f6so9748537ioz.5 for ; Fri, 12 Feb 2021 07:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dFO9mzhG3Z3pS5zAyNg4f0bYeM2JaEbtxEQzQJpQLcU=; b=DzuoX+iypNauQmeiXT5ezuKY+P7kEeZHBjFRKHWYP0igHj00gWDEj7OKOdCk7ptIav yiLWpzIYRyoK2sMb8Omyd/7nEMx7wtcbBbPVlrg4UMNvQHoNnfDurbhk+QeAn7JfsB8u UZ0QKN5ORazGE59+78jnxkN2ijofk/7bt4dgiUZ6TwZWMsZCBGHe50Xr14XaedRQiyYO 4Ki9l02PFFfi2+SoFDJttFNfKQHkCGuz6GEjLcEOGiX8zrZNlMDGeZ/hFInNm/LSIMzf IV/Zq//f+l/HwbwGR7Nv7/y8Ne17BHB41a8+TkZ/ND0cadgejiIGNNQcaK0BIWRk7tc0 92zQ== 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=dFO9mzhG3Z3pS5zAyNg4f0bYeM2JaEbtxEQzQJpQLcU=; b=NGXlsX8B/+Oxkx9/qQjqUD5uTBBse9s4WKaixO3MVFgb/Z//87d/kmkrwb/McvTJ00 wjJ1+x17iGjEKWH2jRM4xWBC07ZlUHJ5BH3lz8r/w8xiyK36/p1q71CUUbz5qkDEcq+m gI3G1w5YZNtJ2nzinKmNFy7+nda7/sy6+lp8NOU3IozAVtkettw6xlkAw9TFc1Kyep4R 0ScZn2oZeKtnnR4WPHSNfYFzv9nCCQgS07l68DpZkqIfZaNMRqR9d9fhM4I+qMTSYguo DWTzPRv2jWLkqojd0zp0y7nM40p+P+GkAgUFwZaOUFwB4BJGLCkB2lgZwQzG5GSYsnI1 NNew== X-Gm-Message-State: AOAM533OP1zfDusyGrZoCT/Z09J0ga0SfRs/EhVMuwhLNJwHPAjH1Sup kqojG5BVpPMzL4DfWIOUdWUXS2W82ZOJf+sKTwxvv15NTpE= X-Google-Smtp-Source: ABdhPJzvKpJag+nqOSMG8tk+kn+fxKqIp+LEqTMgTv40iLFwH0S1gGyY4hqsGxAysvQzCmRkweyugouQorTOgBr1DvE= X-Received: by 2002:a05:6638:11a:: with SMTP id x26mr3267700jao.121.1613145190400; Fri, 12 Feb 2021 07:53:10 -0800 (PST) MIME-Version: 1.0 References: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> In-Reply-To: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> From: Martin Duke Date: Fri, 12 Feb 2021 07:52:58 -0800 Message-ID: To: Michael Tuexen Cc: Neal Cardwell , tcpm IETF list Content-Type: multipart/alternative; boundary="0000000000000b872a05bb25a2df" Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:53:17 -0000 --0000000000000b872a05bb25a2df Content-Type: text/plain; charset="UTF-8" I agree that the congestion control text skillfully threads the needle between Standards Track and reality. Well done! On Fri, Feb 12, 2021 at 7:19 AM Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > > On 11. Feb 2021, at 06:22, Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > > > > The wording in the Congestion Control section looks great to me. > > > > > Minor: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 > > > > I agree with Yuchung that it would be nice to clarify what is meant by > "idle" connections (in the pre-existing text), with respect to keep-alives. > It seems at least the historical behavior for two of the major > implementations out there interpret this in different ways, and this has > caused some confusion in the developer community about what semantics to > expect from TCP keep-alives. I guess the rfc793bis-20 draft does have some > nice new text (that does not seem to be in RFC793 or RFC1122) that seems to > shed some light on this: > > > > Keep-alive packets MUST only be sent when no sent data is > > outstanding, and no data or acknowledgement packets have been > > received for the connection within an interval (MUST-26). > > > > > > That sentence helps quite a bit. It seems to correspond to the last 20 > years of Linux TCP keep-alive behavior, but not the BSD behavior (at least > BSD TCP as documented in Stevens volume 2; I have not checked more recent > BSD kernels). > Can elaborate what Linux behaviour you are referring to an what BSD > behaviour you are referring to? > > Best regards > Michael > > > > And, yes, thank you, Wes for all your years of effort on this! > > > > neal > > > > > > > > On Wed, Feb 10, 2021 at 7:14 PM Yuchung Cheng wrote: > > I think it's ready. Kudos to Wes for the N-years-long effort to put > > this together! > > > > Minor: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 > > > > The less clear part is the wording of "idle connections". Idleness can > > be interpreted in several ways: no recent rx, tx, or both {on the wire > > | on socket interface}. It'd be good to define more clearly. AFAIK > > implementations have different definitions already leading to > > different KA behaviors. > > > > > > > > > > On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael > > wrote: > > > > > > Dear all, > > > > > > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to > Wes, all WGLC feedback should be reflected in this version. A link to a > complete diff can be found below. > > > > > > During WGLC, there has been quite some discussion on the exact wording > on congestion control. The suggested text in version -20 is copied below: > > > > > > 3.7.2. TCP Congestion Control > > > > > > RFC 2914 [7] explains the importance of congestion control for the > > > Internet. > > > > > > RFC 1122 required implementation of Van Jacobson's congestion > control > > > algorithms slow start with congestion avoidance together with > > > exponential back-off for successive RTO values for the same segment. > > > RFC 2581 provided IETF Standards Track description of slow start and > > > congestion avoidance, along with fast retransmit and fast recovery. > > > RFC 5681 is the current description of these algorithms and is the > > > current Standards Track specification providing guidelines for TCP > > > congestion control. RFC 6298 describes exponential back-off of RTO > > > values, including keeping the backed-off value until a subsequent > > > segment with new data has been sent and acknowledged. > > > > > > A TCP endpoint MUST implement the basic congestion control > algorithms > > > slow start, congestion avoidance, and exponential back-off of RTO to > > > avoid creating congestion collapse conditions (MUST-19). RFC 5681 > > > and RFC 6298 describe the basic algorithms on the IETF Standards > > > Track that are broadly applicable. Multiple other suitable > > > algorithms exist and have been widely used. Many TCP > implementations > > > support a set of alternative algorithms that can be configured for > > > use on the endpoint. An endpoint may implement such alternative > > > algorithms provided that the algorithms are conformant with the TCP > > > specifications from the IETF Standards Track as described in RFC > > > 2914, RFC 5033 [10], and RFC 8961 [15]. > > > > > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and > is > > > an IETF Standards Track enhancement that has many benefits [50]. > > > > > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > > > 8). > > > > > > As document shepherd I ask everybody - specifically all TCPM > contributors who have commented on congestion control - to carefully review > this proposed wording within the next few days. If there are any issues > with this suggested resolution of the WGLC, please speak up! > > > > > > If the TCPM working group is fine with version -20, 793bis would be > ready to go. > > > > > > Thanks > > > > > > Michael > > > > > > > > > -----Original Message----- > > > From: I-D-Announce On Behalf Of > internet-drafts@ietf.org > > > Sent: Thursday, January 21, 2021 7:02 PM > > > To: i-d-announce@ietf.org > > > Cc: tcpm@ietf.org > > > Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the TCP Maintenance and Minor Extensions > WG of the IETF. > > > > > > Title : Transmission Control Protocol (TCP) > Specification > > > Author : Wesley M. Eddy > > > Filename : draft-ietf-tcpm-rfc793bis-20.txt > > > Pages : 110 > > > Date : 2021-01-21 > > > > > > 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-20 > > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-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. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > > 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 > --0000000000000b872a05bb25a2df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that the congestion control text skillfully thread= s the needle between Standards Track and reality. Well done!

<= div class=3D"gmail_quote">
On Fri, Feb= 12, 2021 at 7:19 AM Michael Tuexen <Michael.Tuexen@lurchi.franken.de> 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">> On 11. Feb 2021, at 0= 6:22, Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
>
> The wording in the Congestion Control section looks great to me.
>
> > Minor:=C2=A0 https:/= /tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
>
> I agree with Yuchung that it would be nice to clarify what is meant by= "idle" connections (in the pre-existing text), with respect to k= eep-alives. It seems at least the historical behavior for two of the major = implementations out there interpret this in different ways, and this has ca= used some confusion in the developer community about what semantics to expe= ct from TCP keep-alives. I guess the rfc793bis-20 draft does have some nice= new text (that does not seem to be in RFC793 or RFC1122) that seems to she= d some light on this:
>
>=C2=A0 =C2=A0 Keep-alive packets MUST only be sent when no sent data is=
>=C2=A0 =C2=A0 outstanding, and no data or acknowledgement packets have = been
>=C2=A0 =C2=A0 received for the connection within an interval (MUST-26).=
>
>
> That sentence helps quite a bit. It seems to correspond to the last 20= years of Linux TCP keep-alive behavior, but not the BSD behavior (at least= BSD TCP as documented in Stevens volume 2; I have not checked more recent = BSD kernels).
Can elaborate what Linux behaviour you are referring to an what BSD behavio= ur you are referring to?

Best regards
Michael
>
> And, yes, thank you, Wes for all your years of effort on this!
>
> neal
>
>
>
> On Wed, Feb 10, 2021 at 7:14 PM Yuchung Cheng <ycheng@google.com> wrote:
> I think it's ready. Kudos to Wes for the N-years-long effort to pu= t
> this together!
>
> Minor:=C2=A0 https://tool= s.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
>
> The less clear part is the wording of "idle connections". Id= leness can
> be interpreted in several ways: no recent rx, tx, or both {on the wire=
> | on socket interface}. It'd be good to define more clearly. AFAIK=
> implementations have different definitions already leading to
> different KA behaviors.
>
>
>
>
> On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael
> <Michael.Scharf@hs-esslingen.de> wrote:
> >
> > Dear all,
> >
> > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. Accordi= ng to Wes, all WGLC feedback should be reflected in this version. A link to= a complete diff can be found below.
> >
> > During WGLC, there has been quite some discussion on the exact wo= rding on congestion control. The suggested text in version -20 is copied be= low:
> >
> > 3.7.2.=C2=A0 TCP Congestion Control
> >
> >=C2=A0 =C2=A0 RFC 2914 [7] explains the importance of congestion c= ontrol for the
> >=C2=A0 =C2=A0 Internet.
> >
> >=C2=A0 =C2=A0 RFC 1122 required implementation of Van Jacobson'= ;s congestion control
> >=C2=A0 =C2=A0 algorithms slow start with congestion avoidance toge= ther with
> >=C2=A0 =C2=A0 exponential back-off for successive RTO values for t= he same segment.
> >=C2=A0 =C2=A0 RFC 2581 provided IETF Standards Track description o= f slow start and
> >=C2=A0 =C2=A0 congestion avoidance, along with fast retransmit and= fast recovery.
> >=C2=A0 =C2=A0 RFC 5681 is the current description of these algorit= hms and is the
> >=C2=A0 =C2=A0 current Standards Track specification providing guid= elines for TCP
> >=C2=A0 =C2=A0 congestion control.=C2=A0 RFC 6298 describes exponen= tial back-off of RTO
> >=C2=A0 =C2=A0 values, including keeping the backed-off value until= a subsequent
> >=C2=A0 =C2=A0 segment with new data has been sent and acknowledged= .
> >
> >=C2=A0 =C2=A0 A TCP endpoint MUST implement the basic congestion c= ontrol algorithms
> >=C2=A0 =C2=A0 slow start, congestion avoidance, and exponential ba= ck-off of RTO to
> >=C2=A0 =C2=A0 avoid creating congestion collapse conditions (MUST-= 19).=C2=A0 RFC 5681
> >=C2=A0 =C2=A0 and RFC 6298 describe the basic algorithms on the IE= TF Standards
> >=C2=A0 =C2=A0 Track that are broadly applicable.=C2=A0 Multiple ot= her suitable
> >=C2=A0 =C2=A0 algorithms exist and have been widely used.=C2=A0 Ma= ny TCP implementations
> >=C2=A0 =C2=A0 support a set of alternative algorithms that can be = configured for
> >=C2=A0 =C2=A0 use on the endpoint.=C2=A0 An endpoint may implement= such alternative
> >=C2=A0 =C2=A0 algorithms provided that the algorithms are conforma= nt with the TCP
> >=C2=A0 =C2=A0 specifications from the IETF Standards Track as desc= ribed in RFC
> >=C2=A0 =C2=A0 2914, RFC 5033 [10], and RFC 8961 [15].
> >
> >=C2=A0 =C2=A0 Explicit Congestion Notification (ECN) was defined i= n RFC 3168 and is
> >=C2=A0 =C2=A0 an IETF Standards Track enhancement that has many be= nefits [50].
> >
> >=C2=A0 =C2=A0 A TCP endpoint SHOULD implement ECN as described in = RFC 3168 (SHLD-
> >=C2=A0 =C2=A0 8).
> >
> > As document shepherd I ask everybody - specifically all TCPM cont= ributors who have commented on congestion control - to carefully review thi= s proposed wording within the next few days. If there are any issues with t= his suggested resolution of the WGLC, please speak up!
> >
> > If the TCPM working group is fine with version -20, 793bis would = be ready to go.
> >
> > Thanks
> >
> > Michael
> >
> >
> > -----Original Message-----
> > From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of= internet-dra= fts@ietf.org
> > Sent: Thursday, January 21, 2021 7:02 PM
> > To: i-= d-announce@ietf.org
> > Cc: tcpm@ietf.= org
> > Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> > This draft is a work item of the TCP Maintenance and Minor Extens= ions WG of the IETF.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Transmission Control Protocol (TCP) Specification
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Wesley M. Eddy
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-tcpm-rfc793bis-20.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: 110
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2021-01-21
> >
> > Abstract:
> >=C2=A0 =C2=A0 This document specifies the Transmission Control Pro= tocol (TCP).=C2=A0 TCP
> >=C2=A0 =C2=A0 is an important transport layer protocol in the Inte= rnet protocol
> >=C2=A0 =C2=A0 stack, and has continuously evolved over decades of = use and growth of
> >=C2=A0 =C2=A0 the Internet.=C2=A0 Over this time, a number of chan= ges have been made to
> >=C2=A0 =C2=A0 TCP as it was specified in RFC 793, though these hav= e only been
> >=C2=A0 =C2=A0 documented in a piecemeal fashion.=C2=A0 This docume= nt collects and brings
> >=C2=A0 =C2=A0 those changes together with the protocol specificati= on from RFC 793.
> >=C2=A0 =C2=A0 This document obsoletes RFC 793, as well as RFCs 879= , 2873, 6093,
> >=C2=A0 =C2=A0 6429, 6528, and 6691 that updated parts of RFC 793.= =C2=A0 It updates RFC
> >=C2=A0 =C2=A0 1122, and should be considered as a replacement for = the portions of
> >=C2=A0 =C2=A0 that document dealing with TCP requirements.=C2=A0 I= t also updates RFC
> >=C2=A0 =C2=A0 5961 by adding a small clarification in reset handli= ng while in the
> >=C2=A0 =C2=A0 SYN-RECEIVED state.=C2=A0 The TCP header control bit= s from RFC 793 have
> >=C2=A0 =C2=A0 also been updated based on RFC 3168.
> >
> >=C2=A0 =C2=A0 RFC EDITOR NOTE: If approved for publication as an R= FC, this should
> >=C2=A0 =C2=A0 be marked additionally as "STD: 7" and rep= lace RFC 793 in that role.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/do= c/draft-ietf-tcpm-rfc793bis/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-= ietf-tcpm-rfc793bis-20
> > https://datatracker.ietf= .org/doc/html/draft-ietf-tcpm-rfc793bis-20
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-tcpm-rfc793bis-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.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-An= nounce@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<= br> > >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000000b872a05bb25a2df-- From nobody Fri Feb 12 09:49:58 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01133A1829 for ; Fri, 12 Feb 2021 09:49:56 -0800 (PST) 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 egVhyqghXD4Q for ; Fri, 12 Feb 2021 09:49:51 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 E6CAC3A1828 for ; Fri, 12 Feb 2021 09:49:50 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id y10so147660qvo.6 for ; Fri, 12 Feb 2021 09:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w+yogIKnfA5V4L7lz7V5MSZ8ZSJ3k+tF3oHwAv+UAuM=; b=VOpctL3Axv2k19TU/i4mIw2FNTWGYSKIw/rS7B4qr4p8FpEsw2UnGUSz9xaNswzjgb zlZdsxdS7IJPY1k475RLCC44bnYLJPO89iFG8mlHytCi7FW5MUkRhWBzesjWfI7bEih4 4XQUDHrJAIisqwWEoSxRNP+jpCFEhNtppvHUskL+iNQ/lzM843j09ZOwkS++PXJYJhuM pVTBS79WQz3EP3XNe9lyfPYnv4Ps6epXtouij/qrdPhB4WUuQ/2rzVX0ZPc9djGzy2e+ 49nkOorjVwTM8ZfAsNJ9A0jrkwCwNvLRg20e+yxstm+d2sbF7QH0gh9sW7fLVcJ9rrAL 0jPg== 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=w+yogIKnfA5V4L7lz7V5MSZ8ZSJ3k+tF3oHwAv+UAuM=; b=ttsppXjtdMVN18KJNovOHmz+Drnku+8TfpvWHq8wd+eYMOGV0xg1nN16gxdsb/zWdW 5lyOzkz5+ek+W4DUXVxl8UUW6m8wo68F3onOZrMguhtJhqmlPYc5I/x8UxunzxiaJniz 0JO5xwdI9awVR0GMGpqo1QMuwJF6A2s+A0n0DN7trQ6Oig2JMsAQoqSCviN/1oIdFaZW qOjleKV1nzdJWKToLOnDRvA1BdElfAhmCSdH6Zq4Ht+WzxpZwyi/VsfZEk+I09yhObi0 TBf+bUK8duCzaQnLp8wDf+c7b3aiefZp+356JzqkY7i6EbGCBFagLb9g9NMntwrNpgGS zvdA== X-Gm-Message-State: AOAM531bNbyqj1Qrrm7X568Wf28CFH499W7MMN37hslY0lugF2q7+j3X 7WBmc0V2uid2YncznNjESEdB4vyR5jXFjtx/ptI= X-Google-Smtp-Source: ABdhPJxk0ou4LXQW0NUrx7LXAgG+Kbc3soMLQFuuDdhN/izNQDKecwT9VxW89+Mn+LqU5BoHhFqBpYZ4UgiV0pKfJ1Q= X-Received: by 2002:ad4:4390:: with SMTP id s16mr3458530qvr.10.1613152189803; Fri, 12 Feb 2021 09:49:49 -0800 (PST) MIME-Version: 1.0 References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <381499f5-3333-08c5-2ffd-fba77e027795@bobbriscoe.net> <1e61a7d3-b6be-d995-4fc2-777bc2d5d5fe@bobbriscoe.net> In-Reply-To: <1e61a7d3-b6be-d995-4fc2-777bc2d5d5fe@bobbriscoe.net> From: Yoshifumi Nishida Date: Fri, 12 Feb 2021 09:49:38 -0800 Message-ID: To: Bob Briscoe Cc: "Scharf, Michael" , "Scheffenegger, Richard" , Mirja Kuehlewind , tcpm IETF list Content-Type: multipart/alternative; boundary="0000000000003def6a05bb2743fc" Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 17:49:57 -0000 --0000000000003def6a05bb2743fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 11, 2021 at 1:33 PM Bob Briscoe wrote: > > > On 09/02/2021 17:56, Scharf, Michael wrote: > > Bob, > > > >> -----Original Message----- > >> From: Bob Briscoe > >> Sent: Tuesday, February 9, 2021 5:58 PM > >> To: Scheffenegger, Richard ; Mirja > >> Kuehlewind ; Scharf, Michael >> esslingen.de> > >> Cc: tcpm IETF list > >> Subject: Re: AW: [tcpm] AccECN field order > >> > >> Richard, > >> > >> I just noticed I missed the last para of the old email from you below. > >> Response inline, tagged [BB]... > >> > >> On 23/11/2020 12:42, Scheffenegger, Richard wrote: > >>> I am also in favor of using two distinct option codes. > >>> > >>> However, > >>> > >>>> Or I guess we could say that only one option should be used for a > >> connection. > >>> I am opposed to this - with two option codes, a sender should be free > to > >> choose whichever he prevers at any one point; For example, if the > sender a > >> segment (e.g. may be the receiver side) has to update the EE1 couter, > but > >> also convey SACK information, it would be good to use the one, where t= he > >> EE1 field is first, and omit all remaining fields; > >>> Later in the same connection, that very same host may choose to updat= e > >> the CE field together with some SACK information, and use the other > >> codepoint in order to preserve as much TCP option space for the SACK > >> option... > >> > >> [BB] I agree with you here (and disagree with Mirja below). The nice > >> thing about 2 options kinds is they are self-describing, so they can b= e > >> stateless (for instance, consider the code you would have to otherwise > >> add for when a host switches to a different congestion control module = - > >> a lot of complexity despite being unlikely to happen). > >> > >>> > >>> As for extensibility: I would want to avoid that topic, and just > specifiy the > >> three correct supported lengths here, and not mention (other than > ignoring > >> "odd" fractionals of the 3-byte wide counters) what happens with other > >> lengths... > >> > >> [BB] A protocol spec should surely say what to do with unexpected > >> inputs. Not specifying this is one of the main reasons we have such > >> trouble changing things later - because we discover some implementers > >> handled the unexpected in different ways to others (e.g. ignore, vs RS= T > >> the connection), and others only handled expected inputs and didn't ev= en > >> think to check for anything else. > >> > >> So, I believe we have to either say "reset the connection" or "ignore"= , > >> in response to an unexpected option length. I figure that, if there's = no > >> harm in ignoring something unexpected, then why not ("liberal in what > >> you receive" principle). > >> > >> Earlier in this thread, Michael Scharf pointed out that there is some > >> potential harm here (covert channel of up to 29B), but I pointed out > >> that TCP/IP has plenty of other ways of creating covert channels, so > >> we're not really adding to any problem here. But I did say that we wou= ld > >> highlight the covert channel in the Security Considerations section, s= o > >> the Sec Area has a chance to object. If it raises as serious concern, > >> then we should switch from "ignore" to "reset", But I doubt it will. > > I think we first have to come to the conclusion *inside* TCPM whether > such a new covert channel is actually acceptable. > > > > Existing covert channels do not at all imply that a new covert channel > is a good idea (and, IMHO, 29B per packet is a lot). Network administrato= rs > and operators know how to deal with the existing problems in TCP/IP. Addi= ng > any new security issue needs careful reasoning. > > > > As individual contributor to TCPM, I believe that this covert channel > must just be removed from the next version of the draft. At least I don't > need other opinions to come to this personal conclusion. > > > > If this was less obvious others in the WG, TCPM could ask for an early > SECDIR review to get further guidance ASAP. Then this question can be > sorted out while we finish the protocol. > > > > If TCPM needs any external input on covert channels, I think an early > SECDIR review would be a much better approach compared to having a securi= ty > discussion during IETF last call. We are here discussing a standards trac= k > extension of one of the core Internet protocols. In such a case, at least > in my view on IETF processes, other IETF areas can expect that TCPM ties = to > deal with known open issues within the WG as far as possible, i.e., befor= e > they see a "stable" specification in the IETF last call. > > > > In a nutshell: > > > > -1 on leaving this question open until IETF last call > > [BB] That's a perfectly reasonable process proposal. > > I just wanted to add that there are not just 2 choices: the WG (with > advice from SEC area if necessary) is free to limit the bandwidth of > this covert channel anywhere between 0 and 29B per packet by simply > limiting how much extensibility the protocol allows the option length > field to offer, with a 0B covert channel corresponding to no extensibilit= y. > OK. Michael.S abstains from the decision for SECDIR review, but other co-chairs think this is an important point to be checked. So, if there's no specific opposition, we would like to ask for SECDIR review before WGLC. Do authors want to update the draft beforehand to add some more clarifications or are there any other thoughts on this? Thanks, -- Yoshi > >>> > >>> -----Urspr=C3=BCngliche Nachricht----- > >>> Von: Mirja Kuehlewind > >>> Gesendet: Montag, 23. November 2020 12:39 > >>> An: Neal Cardwell ; Scharf, Michael > >> ; Bob Briscoe > >>> Cc: Yoshifumi Nishida ; tcpm IETF list > >> ; Scheffenegger, Richard > >> ; Michael Tuexen >> muenster.de>; tcpm-chairs@ietf.org > >>> Betreff: Re: [tcpm] AccECN field order > >>> > >>> NetApp Security WARNING: This is an external email. Do not click link= s > or > >> open attachments unless you recognize the sender and know the content = is > >> safe. > >>> > >>> > >>> > >>> Hi all, > >>> > >>> I think I also support two options as this is the most simple solutio= n. > >>> > >>> We probably need to look at section 3.2.3.2. (Path Traversal of the > AccECN > >> Option) again, as I think this section assumes mostly one option. Or I > guess > >> we could say that only one option should be used for a connection. > >>> Regarding use of the option length for extensibility. I know new > options are > >> hard to deploy but that=E2=80=99s the extensibility mechanism we have = with TCP. > Not > >> sure we want to invent a new now. If we think we need more extensibili= ty > >> for AccECN for any reason, we should specify valid option length value= s > that > >> include a flags field now. > >>> Mirja > >>> > >>> > >>> > >>>> On 18. Nov 2020, at 01:03, Neal Cardwell > wrote: > >>>> > >>>> As someone who contributes to a TCP implementation, I would put in a > >> vote for the "Two Option Kinds" proposal outlined in slide 6 here: > >>>> > >>>> > https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor > >>>> e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifi= ca > >>>> tion-01#page=3D6 > >>>> > >>>> This approach has the virtue of simplicity, which hopefully may help > avoid > >> middlebox bugs, speed standardization and development, and ease the > >> process of maintaining fast and stable implementations. > >>>> neal > >>>> > >>>> > >>>> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael >> esslingen.de> wrote: > >>>> Inline some comments [ms]. > >>>> > >>>> > >>>> > >>>> Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll no= t follow-up > forever in this > >> discussion. I don=E2=80=99t own running code and a lot of encoding det= ails > mainly > >> affect an implementation. > >>>> > >>>> > >>>> IMHO the rest of the WG has to think about the option design more th= an > >>>> me. So, this is mostly about triggering a discussion=E2=80=A6 > >>>> > >>>> > >>>> > >>>> From: Bob Briscoe > >>>> Sent: Tuesday, November 17, 2020 1:20 PM > >>>> To: Scharf, Michael ; Yoshifumi > >>>> Nishida > >>>> Cc: Michael Tuexen ; tcpm-chairs@ietf.org; > >>>> Mirja Kuehlewind ; Scheffenegger, Richard > >>>> ; tcpm IETF list > >>>> Subject: Re: AccECN field order > >>>> > >>>> > >>>> > >>>> Michael, > >>>> > >>>> On 17/11/2020 08:10, Scharf, Michael wrote: > >>>> > >>>> Bob, > >>>> > >>>> > >>>> > >>>> I am fine with the two option kinds proposed in -13, but I don=E2=80= =99t buy > your > >> arguments why this encoding is better than others. > >>>> > >>>> > >>>> Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward c= ompatibility=E2=80=9D > >> argument is a very compelling reason for two codepoints. All proposals > I am > >> aware of have their pros and cons. And I am not aware of a really > >> comprehensive discussion. At least neither the e-mail below nor today= =E2=80=99s > >> meeting discuss all tradeoffs I would investigate. > >>>> > >>>> [BB] You're right - the discussion below is useful and necessary. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> For instance, the benefit of the length encoding variant would be to > >> consume only one TCP option codepoint now. If we decided later to that= a > >> flag byte is needed (say, at the end), a follow-up proposed standard > could > >> specify another option format with that flag byte, using a second > codepoint. > >>>> > >>>> [BB] > >>>> * The new codepoint would require years to deploy (including in > proxies) > >> before it works e2e. > >>>> > >>>> > >>>> [ms] That may depend *a lot* on the environment. In environments > >> where ECN can get deployed today, say in datacenters, rolling out a ne= w > >> kernel version may perhaps not be the biggest operational challenge. > Also, > >> proxies may not be a significant problem in some of those cases. > Deployment > >> roadmaps are very hard to predict. > >>>> > >>>> * Whereas the 'forward compatibility' approach tries to ensure that > >> AccECN implementations that are being built today will be ready to > interwork > >> with a future extension. > >>>> * In contrast, if your hypothetical new AccECN codepoint did need to > be > >> deployed later, it would need to include a fall-back to the current > AccECN > >> option when one peer doesn't understand the new codepoint. > >>>> > >>>> > >>>> [ms] This is a reasonable point, albeit not a particularly strong on= e, > >>>> given that the option is not really required for basic > >>>> interoperability. Also, a hypothetical follow-up standard could > >>>> include a way to explicitly request the option=E2=80=A6 > >>>> > >>>> > >>>> * Fall-back would need to avoid a second round of handshake (given > >>>> this is for low latency), which would only work reliably with an > >>>> option on the SYN (because the 3rd ACK is unreliable) > >>>> > >>>> > >>>> > >>>> [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting = AccECN > option > >> =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cplease send m= e the better AccECN > option B=E2=80=9D > >> after the 3-WHS. It could be an upgrade, not a fallback. Also, at this > point we > >> don=E2=80=99t know what option B would be and in which context it woul= d be > >> needed. Maybe other protocol features would require negotiation, too. > >> IMHO it is a solvable problem. > >>>> > >>>> * AccECN has so far avoided using any SYN option space, which is > >> important given that is the scarcest resource. > >>>> > >>>> > >>>> [ms] Yep, but as long as no proposal needs SYN options, this is > nothing > >> that would make one solution better than another. > >>>> These days, extending TCP is like playing chess - we have to think > multiple > >> moves ahead! > >>>> > >>>> > >>>> [ms] There is one fundamental difference between chess and TCP: In > >> chess you precisely know the current situation and can predict all > potential > >> moves in advance (albeit there are a lot). However, we don=E2=80=99t k= now the > >> future evolution of TCP, ECN and the Internet as a whole, nor future > >> requirements. If we try to engineer a TCP extension for some potential > >> future, we may figure out later that reality is different from what we > >> designed for. As much as I appreciate your attempts to predict the > future, it > >> would be a big surprise to me if you could correctly predict what TCP > will be in > >> 10 years from now. So, instead of trying to write specifications that > take into > >> account future requirements, which are in fact just unknown, it is mor= e > >> important for me to write effective, efficient and secure > specifications for > >> what is currently known for sure. > >>>> > >>>> > >>>> [ms] I *don=E2=80=99t* know for sure whether the current AccECN opti= on will be > >> needed, but I see quite some evidence that support of the AccECN > option(s) > >> is not a top priority these days. That is also something to think abou= t > when > >> designing the details. > >>>> > >>>> > >>>> I need to learn to articulate onto the list all my reasons for > rejecting > >> certain parts of the design space. Sorry about that. > >>>> Yes, I admit, the current proposal is at the cost of burning two TCP > option > >> codepoints. However, you said yourself when you proposed this approach= , > >> that they are not (currently) a scarce resource. Certainly not as > scarce as > >> option space. I just checked: roughly 15% of the option codepoint > allocation > >> space has been used so far. So that's where I would suggest we > compromise > >> first. > >>>> [ms] I made a similar calculation some years ago and came to a simil= ar > >> conclusion. Investing two codepoints for AccECN is something we can > >> probably afford. But nonetheless we have to reason carefully why it is > really > >> worth the effort. > >>>> > >>>> > >>>> > >>>> Regarding the resulting codepoint consumption (two option kinds) and > >> the addition of a flag byte, this approach would basically end up with > the > >> same result as the current proposal in -13 plus some hypothetical futu= re > >> addition leveraging the length field beyond the currently known use. > >>>> > >>>> > >>>> And, yes, the length encoding variant may be less flexible and/or > >> consume some more bits in some cases, but on the plus side it only nee= ds > >> one codepoint now =E2=80=93 and given that it is entirely unclear whet= her any > >> AccECN option will indeed be widely used in future, this is a big plus= . > The fact > >> that implementers are quite silent on the option design is not a good > sign. > >>>> > >>>> [BB] Here's another possibility then. > >>>> > >>>> a) [K|L| EE1B | ECEB | EE0B ] > >>>> b) [K|L| EE1B | ECEB | EE0B |F] if F =3D 0bXXXXXXX0 > >>>> c) [K|L| EE0B | ECEB | EE1B |F] if F =3D 0bXXXXXXX1 > >>>> > >>>> We'd have to decide which order alternative (a) takes. I've picked > EE1B > >> first only 'cos you're right that there is not currently as much > pressure (on the > >> public Internet) for AccECN with ECT(0). > >>>> =3D=3DLegend=3D=3D > >>>> K: Kind (1B) > >>>> L: Length (1B) > >>>> ExxB: Echo xx byte counter > >>>> F: Flags (1B) > >>>> > >>>> Alternatives a) and b) are equivalent, at least while the only > allocated flag > >> is for field order. > >>>> However, alternative b) is available in case other flags are allocat= ed > >>>> in future The flags byte can only be omitted if (L % 3 =3D=3D 2). > >>>> The flags byte is considered present if (L % 3) =3D=3D 0. > >>>> > >>>> Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be assumed= to > >> include a flags byte, and current implementations ignore the last byte= . > >>>> The flags byte is optional to implement (even if the AccECN option i= s > >>>> implemented) If the server includes a flags byte on the SYN/ACK but > the > >> client does not include one on the 3rd ACK or the first data packet, > the server > >> assumes the client does not implement the flags byte and uses only > >> alternative a) for the remainder of the connection. > >>>> > >>>> [ms] I am not sure if we need that, but I take this as existence > proof that > >> other encodings are possible. Personally, I think that other solutions > would > >> be doable if you took one bit from one or multiple counters for format > >> encoding. At least for some of the byte counters I don=E2=80=99t think= taking > one bit > >> for other purposes would result in an Internet congestion collapse=E2= =80=A6 > But, I > >> have already said that the -13 proposal works for me, so I=E2=80=99ll = not try > to come > >> up with another variant myself. > >>>> > >>>> > >>>> To me, one potential difference between two proposals would be > >> incremental deployment. The proposal in -13 only has an advantage if > >> middleboxes such as firewalls will indeed pass TCP options with a > format that > >> contains content beyond the (first) Accurate ECN standard (i.e., > currently > >> unused length values). IMHO it is too early to know whether firewalls > would > >> indeed allow this in future. > >>>> > >>>> > >>>> From a security perspective, it is not clear to me whether allowin= g > >> arbitrary unspecified bytes in a TCP option is a good idea *at all*. I= t > will be > >> interesting to hear the opinion from SEC area on that. Personally, I a= m > not > >> convinced that this really makes sense, but I my concerns are not stro= ng > >> enough to formally push back. I=E2=80=99ll leave it to others to think= about > whether > >> this is a bug or a feature. > >>>> > >>>> [BB] Well, let's first try to deal with security ourselves: > >>>> * Octets that are explicitly declared as part of an option cannot be > used > >> for a buffer overflow attack. I don't really need to, but I could add > the > >> following text to the forward compatibility wording: > >>>> A receiver considers octets beyond those it uses, but within t= he > >> specified length, as if they are padding. > >>>> * And such octets cannot be any different from the current ability o= f > a > >> sender to add padding. So there's no new attack possible here. > >>>> * And there's no need to specify a max length for any AccECN Option, > >> which would just unnecessarily limit flexibility. > >>>> [ms] I have more thought about the covert channel that some > unspecified > >> bytes in a standards track TCP option could offer=E2=80=A6 In particul= ar if the > AccECN > >> option gets widely deployed and used, would some malicious users find > >> those bytes useful? For what? For instance, what in the AccECN protoco= l > >> design prevents use of these =E2=80=9Cpadding=E2=80=9D bytes as super-= cookie? To me, it > is > >> much more important to think about abuse of whatever we standardize > >> *now*, instead of engineering for some entirely unknown future. I am > not a > >> security expert, but I suggest a careful analysis of any security > implications of > >> the AccECN option. We seldomly specify new TCP options and malicious > >> users will certainly look for =E2=80=9Copportunities=E2=80=9D in the s= pec. So far, I > don=E2=80=99t know > >> whether that whole idea of forward compatibility is a feature or a bug= . > >>>> > >>>> > >>>> Michael > >>>> > >>>> > >>>> > >>>> Maybe one lesson learnt is that the document could have a non- > >> normative appendix that explains the rationale for the finally picked > TCP > >> option encoding. That may also help if there are further questions > whether > >> two codepoints are really required, e.g. by the IESG (if two codepoint= s > are > >> still the design after WGLC). At least for past TCP option codepoint > allocations > >> I recall some discussions late in the IETF process. In those past > cases, good > >> arguments in an appendix and running code has helped a lot. > >>>> > >>>> [BB] I can do that. Appx B is already similar, giving Design > Rationale for the > >> ACE field. > >>>> > >>>> Bob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Michael > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> From: Bob Briscoe > >>>> Sent: Tuesday, November 17, 2020 6:10 AM > >>>> To: Scharf, Michael ; Yoshifumi > >>>> Nishida > >>>> Cc: Michael Tuexen ; tcpm-chairs@ietf.org; > >>>> Mirja Kuehlewind ; Scheffenegger, Richard > >>>> ; tcpm IETF list > >>>> Subject: Re: AccECN field order > >>>> > >>>> > >>>> > >>>> Michael, > >>>> > >>>> On 16/11/2020 17:36, Scharf, Michael wrote: > >>>> > >>>> Bob, > >>>> > >>>> > >>>> > >>>> One proposal using the length field with *one option codepoint only* > >>>> is detailed in: > >>>> https://mailarchive.ietf.org/arch/msg/tcpm/zo- > >> 1OR0nRfhHocX8yvTvpC4BNMo > >>>> / > >>>> > >>>> > >>>> > >>>> It is the third option mentioned in this e-mail. One example would b= e > to > >> use option length values 5/8/11 for one encoding type and option lengt= h > >> values 6/9/12 for the other encoding type (i.e., order of fields). Or > one could > >> use some other combination of length values =E2=80=93 the only require= ment is > that a > >> certain value for the option length is only used by one of the option > formats. > >> In that approach, the value of the length field would thus directly > describe > >> the encoding of the option. Unless I miss something, this would work > and it > >> would just require one option codepoint. > >>>> > >>>> > >>>> Thus, alternatives to two option codepoints exist and I have explain= ed > >> them on the list in March 2020. > >>>> > >>>> OK, sorry, yes, I remember this now. > >>>> > >>>> As I will explain in the AccECN status update talk today in virtual > Bangkok, > >> the draft has made provision for different length values than 5/8/11. > It says > >> existing implementations MUST accept length values other than those > >> currently defined. But then read in as many whole 3-byte fields as the= y > can. > >>>> This can be used to add a flags byte on the end in future, for > extensibility. > >> Or any other form of extensibility the WG might decide in the future. > >>>> I know a flags byte at the end seems odd compared to at the beginnin= g. > >> But (if decided it's needed in future) it's reasonably easy to > implement by > >> reading the whole option, then processing the last byte, before readin= g > the > >> rest of the option. > >>>> I believe you will agree that this is a better way to utilize > different lengths. > >>>> > >>>> And thank you for repeatedly emphasizing that you're happy with the = 2- > >> kind scheme, or other alternatives. > >>>> > >>>> Bob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Anyway, I don=E2=80=99t really care how the options are encoded as l= ong as the > >> receiver doesn=E2=80=99t need per-connection state for decoding a TCP = option. > So, > >> personally, I would be fine with using e.g. the length field as > described in my > >> old e-mail. Or an additional flag byte. And one could come up with > further > >> encodings, e.g., by using one or a few bits as a short =E2=80=9Ctype= =E2=80=9D field for > each > >> counter. This is all about protocol engineering. And all these variant= s > have > >> their pros and cons. > >>>> > >>>> > >>>> I am also fine with using two option codepoints as specified in -13; > this is > >> probably the approach that consumes the least number of bits. > >>>> > >>>> > >>>> Michael (w/o any hat) > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> From: Bob Briscoe > >>>> Sent: Monday, November 16, 2020 5:52 PM > >>>> To: Yoshifumi Nishida > >>>> Cc: Scharf, Michael ; Michael Tuexen > >>>> ; tcpm-chairs@ietf.org; Mirja Kuehlewind > >>>> ; Scheffenegger, Richard > >>>> ; tcpm IETF list > >>>> Subject: AccECN field order > >>>> > >>>> > >>>> > >>>> Yoshi, (adding the tcpm list in cc) > >>>> > >>>> On 05/11/2020 06:58, Yoshifumi Nishida wrote: > >>>> > >>>> Hi Bob, > >>>> > >>>> > >>>> > >>>> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe > >> wrote: > >>>> Yoshi, > >>>> > >>>> On 04/11/2020 06:51, Yoshifumi Nishida wrote: > >>>> > >>>> Hi, folks, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> In my understanding, I'm not sure if we settled down on using two > option > >> kinds or encoding schemes for 24bits fields in acc ecn draft. > >>>> So, I think there're still something to be clarified and hope things > will be > >> settled at the meeting. > >>>> > >>>> [BB] I know a WG can change it's mind at any time. But I'd rather we > just > >> clarified what a previous decision was, to avoid the need to keep > re-opening > >> discussion on a question that have been decided then changed three > >> different ways already. > >>>> My memory is not so good these days. I trusted that Michael S > >> remembered the decision correctly, and I seem to remember that decisio= n > >> being made. > >>>> I've just checked the minutes of the last interim: > >>>> > >>>> > https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 > >>>> 1600/ and they mention Michael's proposal to use two kinds, but don'= t > >>>> record any decision. > >>>> The jabber log gives no clues about any decision. > >>>> > >>>> I can't find an audio or video recording. Can you point me at one? > >>>> > >>>> > >>>> > >>>> I thought that it's because there was no clear decision at the > meeting. > >>>> > >>>> But, you can check https://www.youtube.com/watch?v=3DKsB0_Nb8-kA > >>>> > >>>> Please let us know if you have any questions or opinions with regard > to > >> this. > >>>> > >>>> [BB] I checked the Youtube link you sent below. > >>>> > >>>> First I think we're agreed no-one was fighting for us to keep the > previous > >> way we did this (using the initial value of the field to set the order > for the > >> connection). > >>>> In my presentation I said there was strong resistance from Michael t= o > do it > >> a different way. > >>>> (also, offlist, the co-authors including me also didn't like this so > >>>> much. And Ilpo said it made the implementation complex.) > >>>> > >>>> Then came the question of what we do instead. There were three > >> alternative proposals: > >>>> a) use 2 option kinds > >>>> b) add a flags byte > >>>> c) somehow use the length field maybe > >>>> > >>>> Michael raised (c) in the meeting as a possibility, but no-one could > think > >> how to distinguish two options of the same length but a different fiel= d > order > >> using the length field. Michael said he'd post any ideas to the list i= f > he could > >> think of any, but that didn't happen. > >>>> So we're left choosing between (a) and (b). > >>>> I said in the meeting (and on the list when discussing with Ilpo) > that I'd be > >> happy to go with (b), but only if there was another use for a flag. > Because it > >> would consume 1B more options space in many packets, which is a scarce > >> resource. > >>>> Ilpo had a proposed use for another flag (to help synch counters > after a > >> loss), but I think the discussion about it ended that it wouldn't be > helpful, 'cos > >> the way it worked depended on itself (circular logic). > >>>> In conclusion, I don't think there was an explicit decision to go > with 2 > >> option kinds, but it ended up as the 'last person standing'. > >>>> I like it. It's simple. And apparently option kinds are not such a > scarce > >> resource. > >>>> Perhaps we can ratify this in the WG tomorrow. > >>>> > >>>> > >>>> Bob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> -- > >>>> > >>>> Yoshi > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> __________________________________________________________ > >> ______ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> __________________________________________________________ > >> ______ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> __________________________________________________________ > >> ______ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >> -- > >> __________________________________________________________ > >> ______ > >> Bob Briscoe http://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000003def6a05bb2743fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Feb 11, 2021 at 1:33 PM Bob Briscoe <ietf@bobbriscoe.net= > wrote:


On 09/02/2021 17:56, Scharf, Michael wrote:
> Bob,
>
>> -----Original Message-----
>> From: Bob Briscoe <ietf@bobbriscoe.net>
>> Sent: Tuesday, February 9, 2021 5:58 PM
>> To: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>= ; Mirja
>> Kuehlewind <ietf@kuehlewind.net>; Scharf, Michael <Michael.Scharf@hs- >> esslingen.de>
>> Cc: tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: AW: [tcpm] AccECN field order
>>
>> Richard,
>>
>> I just noticed I missed the last para of the old email from you be= low.
>> Response inline, tagged [BB]...
>>
>> On 23/11/2020 12:42, Scheffenegger, Richard wrote:
>>> I am also in favor of using two distinct option codes.
>>>
>>> However,
>>>
>>>> Or I guess we could say that only one option should be use= d for a
>> connection.
>>> I am opposed to this - with two option codes, a sender should = be free to
>> choose whichever he prevers at any one point; For example, if the = sender a
>> segment (e.g. may be the receiver side)=C2=A0 has to update the EE= 1 couter, but
>> also convey SACK information, it would be good to use the one, whe= re the
>> EE1 field is first, and omit all remaining fields;
>>> Later in the same connection, that very same host may choose t= o update
>> the CE field together with some SACK information, and use the othe= r
>> codepoint in order to preserve as much TCP option space for the SA= CK
>> option...
>>
>> [BB] I agree with you here (and disagree with Mirja below). The ni= ce
>> thing about 2 options kinds is they are self-describing, so they c= an be
>> stateless (for instance, consider the code you would have to other= wise
>> add for when a host switches to a different congestion control mod= ule -
>> a lot of complexity despite being unlikely to happen).
>>
>>>
>>> As for extensibility: I would want to avoid that topic, and ju= st specifiy the
>> three correct supported lengths here, and not mention (other than = ignoring
>> "odd" fractionals of the 3-byte wide counters) what happ= ens with other
>> lengths...
>>
>> [BB] A protocol spec should surely say what to do with unexpected<= br> >> inputs. Not specifying this is one of the main reasons we have suc= h
>> trouble changing things later - because we discover some implement= ers
>> handled the unexpected in different ways to others (e.g. ignore, v= s RST
>> the connection), and others only handled expected inputs and didn&= #39;t even
>> think to check for anything else.
>>
>> So, I believe we have to either say "reset the connection&quo= t; or "ignore",
>> in response to an unexpected option length. I figure that, if ther= e's no
>> harm in ignoring something unexpected, then why not ("liberal= in what
>> you receive" principle).
>>
>> Earlier in this thread, Michael Scharf pointed out that there is s= ome
>> potential harm here (covert channel of up to 29B), but I pointed o= ut
>> that TCP/IP has plenty of other ways of creating covert channels, = so
>> we're not really adding to any problem here. But I did say tha= t we would
>> highlight the covert channel in the Security Considerations sectio= n, so
>> the Sec Area has a chance to object. If it raises as serious conce= rn,
>> then we should switch from "ignore" to "reset"= , But I doubt it will.
> I think we first have to come to the conclusion *inside* TCPM whether = such a new covert channel is actually acceptable.
>
> Existing covert channels do not at all imply that a new covert channel= is a good idea (and, IMHO, 29B per packet is a lot). Network administrator= s and operators know how to deal with the existing problems in TCP/IP. Addi= ng any new security issue needs careful reasoning.
>=C2=A0 =C2=A0
> As individual contributor to TCPM, I believe that this covert channel = must just be removed from the next version of the draft. At least I don'= ;t need other opinions to come to this personal conclusion.
>
> If this was less obvious others in the WG, TCPM could ask for an early= SECDIR review to get further guidance ASAP. Then this question can be sort= ed out while we finish the protocol.
>
> If TCPM needs any external input on covert channels, I think an early = SECDIR review would be a much better approach compared to having a security= discussion during IETF last call. We are here discussing a standards track= extension of one of the core Internet protocols. In such a case, at least = in my view on IETF processes, other IETF areas can expect that TCPM ties to= deal with known open issues within the WG as far as possible, i.e., before= they see a "stable" specification in the IETF last call.
>
> In a nutshell:
>
> -1 on leaving this question open until IETF last call

[BB] That's a perfectly reasonable process proposal.

I just wanted to add that there are not just 2 choices: the WG (with
advice from SEC area if necessary) is free to limit the bandwidth of
this covert channel anywhere between 0 and 29B per packet by simply
limiting how much extensibility the protocol allows the option length
field to offer, with a 0B covert channel corresponding to no extensibility.=

OK. Michael.S abstains from the decisi= on for SECDIR review, but other co-chairs think this is an important point = to be checked.
So, if there's no specific=C2=A0opposition, we= would like to ask for SECDIR review before WGLC.=C2=A0

Do authors want to update the draft beforehand to add some more clari= fications or are there any other thoughts on this?

Thanks,
--
Yoshi


=C2=A0
>>>
>>> -----Urspr=C3=BCngliche Nachricht-----
>>> Von: Mirja Kuehlewind <ietf@kuehlewind.net>
>>> Gesendet: Montag, 23. November 2020 12:39
>>> An: Neal Cardwell <ncardwell@google.com>; Scharf, Michael
>> <Michael.Scharf@hs-esslingen.de>; Bob Briscoe <ietf@bobbriscoe.net>
>>> Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm IETF list
>> <tcpm@ietf.o= rg>; Scheffenegger, Richard
>> <Richard.Scheffenegger@netapp.com>; Michael Tuexen <tuexen= @fh-
>> muenster.de>; tcpm-chairs@ietf.org
>>> Betreff: Re: [tcpm] AccECN field order
>>>
>>> NetApp Security WARNING: This is an external email. Do not cli= ck links or
>> open attachments unless you recognize the sender and know the cont= ent is
>> safe.
>>>
>>>
>>>
>>> Hi all,
>>>
>>> I think I also support two options as this is the most simple = solution.
>>>
>>> We probably need to look at section 3.2.3.2. (Path Traversal o= f the AccECN
>> Option) again, as I think this section assumes mostly one option. = Or I guess
>> we could say that only one option should be used for a connection.=
>>> Regarding use of the option length for extensibility. I know n= ew options are
>> hard to deploy but that=E2=80=99s the extensibility mechanism we h= ave with TCP. Not
>> sure we want to invent a new now. If we think we need more extensi= bility
>> for AccECN for any reason, we should specify valid option length v= alues that
>> include a flags field now.
>>> Mirja
>>>
>>>
>>>
>>>> On 18. Nov 2020, at 01:03, Neal Cardwell <ncardwell@google.com> w= rote:
>>>>
>>>> As someone who contributes to a TCP implementation, I woul= d put in a
>> vote for the "Two Option Kinds" proposal outlined in sli= de 6 here:
>>>>
>>>> https://datat= racker.ietf.org/meeting/109/materials/slides-109-tcpm-mor
>>>> e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congest= ion-notifica
>>>> tion-01#page=3D6
>>>>
>>>> This approach has the virtue of simplicity, which hopefull= y may help avoid
>> middlebox bugs, speed standardization and development, and ease th= e
>> process of maintaining fast and stable implementations.
>>>> neal
>>>>
>>>>
>>>> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael <Michae= l.Scharf@hs-
>> esslingen.de> wrote:
>>>> Inline some comments [ms].
>>>>
>>>>
>>>>
>>>> Given that I don=E2=80=99t ask for any text chances, I=E2= =80=99ll not follow-up forever in this
>> discussion. I don=E2=80=99t own running code and a lot of encoding= details mainly
>> affect an implementation.
>>>>
>>>>
>>>> IMHO the rest of the WG has to think about the option desi= gn more than
>>>> me. So, this is mostly about triggering a discussion=E2=80= =A6
>>>>
>>>>
>>>>
>>>> From: Bob Briscoe <ietf@bobbriscoe.net>
>>>> Sent: Tuesday, November 17, 2020 1:20 PM
>>>> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Y= oshifumi
>>>> Nishida <nsd.ietf@gmail.com>
>>>> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
>>>> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, Richard
>>>> <Richard.Scheffenegger@netapp.com>; tcpm IETF list &l= t;tcpm@ietf.org><= br> >>>> Subject: Re: AccECN field order
>>>>
>>>>
>>>>
>>>> Michael,
>>>>
>>>> On 17/11/2020 08:10, Scharf, Michael wrote:
>>>>
>>>> Bob,
>>>>
>>>>
>>>>
>>>> I am fine with the two option kinds proposed in -13, but I= don=E2=80=99t buy your
>> arguments why this encoding is better than others.
>>>>
>>>>
>>>> Most importantly, I don=E2=80=99t think that your =E2=80= =9Cforward compatibility=E2=80=9D
>> argument is a very compelling reason for two codepoints. All propo= sals I am
>> aware of have their pros and cons. And I am not aware of a really<= br> >> comprehensive discussion. At least neither the e-mail below nor to= day=E2=80=99s
>> meeting discuss all tradeoffs I would investigate.
>>>>
>>>> [BB] You're right - the discussion below is useful and= necessary.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> For instance, the benefit of the length encoding variant w= ould be to
>> consume only one TCP option codepoint now. If we decided later to = that a
>> flag byte is needed (say, at the end), a follow-up proposed standa= rd could
>> specify another option format with that flag byte, using a second = codepoint.
>>>>
>>>> [BB]
>>>> * The new codepoint would require years to deploy (includi= ng in proxies)
>> before it works e2e.
>>>>
>>>>
>>>> [ms] That may depend *a lot* on the environment. In enviro= nments
>> where ECN can get deployed today, say in datacenters, rolling out = a new
>> kernel version may perhaps not be the biggest operational challeng= e. Also,
>> proxies may not be a significant problem in some of those cases. D= eployment
>> roadmaps are very hard to predict.
>>>>
>>>> * Whereas the 'forward compatibility' approach tri= es to ensure that
>> AccECN implementations that are being built today will be ready to= interwork
>> with a future extension.
>>>> * In contrast, if your hypothetical new AccECN codepoint d= id need to be
>> deployed later, it would need to include a fall-back to the curren= t AccECN
>> option when one peer doesn't understand the new codepoint.
>>>>
>>>>
>>>> [ms] This is a reasonable point, albeit not a particularly= strong one,
>>>> given that the option is not really required for basic
>>>> interoperability. Also, a hypothetical follow-up standard = could
>>>> include a way to explicitly request the option=E2=80=A6 >>>>
>>>>
>>>> * Fall-back would need to avoid a second round of handshak= e (given
>>>> this is for low latency), which would only work reliably w= ith an
>>>> option on the SYN (because the 3rd ACK is unreliable)
>>>>
>>>>
>>>>
>>>> [ms] I can=E2=80=99t follow. If an endpoint is unhappy wit= h getting AccECN option
>> =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cplease se= nd me the better AccECN option B=E2=80=9D
>> after the 3-WHS. It could be an upgrade, not a fallback. Also, at = this point we
>> don=E2=80=99t know what option B would be and in which context it = would be
>> needed. Maybe other protocol features would require negotiation, t= oo.
>> IMHO it is a solvable problem.
>>>>
>>>> * AccECN has so far avoided using any SYN option space, wh= ich is
>> important given that is the scarcest resource.
>>>>
>>>>
>>>> [ms] Yep, but as long as no proposal needs SYN options, th= is is nothing
>> that would make one solution better than another.
>>>> These days, extending TCP is like playing chess - we have = to think multiple
>> moves ahead!
>>>>
>>>>
>>>> [ms] There is one fundamental difference between chess and= TCP: In
>> chess you precisely know the current situation and can predict all= potential
>> moves in advance (albeit there are a lot). However, we don=E2=80= =99t know the
>> future evolution of TCP, ECN and the Internet as a whole, nor futu= re
>> requirements. If we try to engineer a TCP extension for some poten= tial
>> future, we may figure out later that reality is different from wha= t we
>> designed for. As much as I appreciate your attempts to predict the= future, it
>> would be a big surprise to me if you could correctly predict what = TCP will be in
>> 10 years from now. So, instead of trying to write specifications t= hat take into
>> account future requirements, which are in fact just unknown, it is= more
>> important for me to write effective, efficient and secure specific= ations for
>> what is currently known for sure.
>>>>
>>>>
>>>> [ms] I *don=E2=80=99t* know for sure whether the current A= ccECN option will be
>> needed, but I see quite some evidence that support of the AccECN o= ption(s)
>> is not a top priority these days. That is also something to think = about when
>> designing the details.
>>>>
>>>>
>>>> I need to learn to articulate onto the list all my reasons= for rejecting
>> certain parts of the design space. Sorry about that.
>>>> Yes, I admit, the current proposal is at the cost of burni= ng two TCP option
>> codepoints. However, you said yourself when you proposed this appr= oach,
>> that they are not (currently) a scarce resource. Certainly not as = scarce as
>> option space. I just checked: roughly 15% of the option codepoint = allocation
>> space has been used so far. So that's where I would suggest we= compromise
>> first.
>>>> [ms] I made a similar calculation some years ago and came = to a similar
>> conclusion. Investing two codepoints for AccECN is something we ca= n
>> probably afford. But nonetheless we have to reason carefully why i= t is really
>> worth the effort.
>>>>
>>>>
>>>>
>>>> Regarding the resulting codepoint consumption (two option = kinds) and
>> the addition of a flag byte, this approach would basically end up = with the
>> same result as the current proposal in -13 plus some hypothetical = future
>> addition leveraging the length field beyond the currently known us= e.
>>>>
>>>>
>>>> And, yes, the length encoding variant may be less flexible= and/or
>> consume some more bits in some cases, but on the plus side it only= needs
>> one codepoint now =E2=80=93 and given that it is entirely unclear = whether any
>> AccECN option will indeed be widely used in future, this is a big = plus. The fact
>> that implementers are quite silent on the option design is not a g= ood sign.
>>>>
>>>> [BB] Here's another possibility then.
>>>>
>>>> a) [K|L| EE1B | ECEB | EE0B ]
>>>> b) [K|L| EE1B | ECEB | EE0B |F]=C2=A0 =C2=A0 if F =3D 0bXX= XXXXX0
>>>> c) [K|L| EE0B | ECEB | EE1B |F]=C2=A0 =C2=A0 if F =3D 0bXX= XXXXX1
>>>>
>>>> We'd have to decide which order alternative (a) takes.= I've picked EE1B
>> first only 'cos you're right that there is not currently a= s much pressure (on the
>> public Internet) for AccECN with ECT(0).
>>>> =3D=3DLegend=3D=3D
>>>> K:=C2=A0 =C2=A0 Kind (1B)
>>>> L:=C2=A0 =C2=A0 Length (1B)
>>>> ExxB: Echo xx byte counter
>>>> F:=C2=A0 =C2=A0 Flags (1B)
>>>>
>>>> Alternatives a) and b) are equivalent, at least while the = only allocated flag
>> is for field order.
>>>> However, alternative b) is available in case other flags a= re allocated
>>>> in future The flags byte can only be omitted if (L % 3 =3D= =3D 2).
>>>> The flags byte is considered present if (L % 3) =3D=3D 0.<= br> >>>>
>>>> Forward compatibility: Options with (L % 3 =3D=3D 1) MUST = be assumed to
>> include a flags byte, and current implementations ignore the last = byte.
>>>> The flags byte is optional to implement (even if the AccEC= N option is
>>>> implemented) If the server includes a flags byte on the SY= N/ACK but the
>> client does not include one on the 3rd ACK or the first data packe= t, the server
>> assumes the client does not implement the flags byte and uses only=
>> alternative a) for the remainder of the connection.
>>>>
>>>> [ms] I am not sure if we need that, but I take this as exi= stence proof that
>> other encodings are possible. Personally, I think that other solut= ions would
>> be doable if you took one bit from one or multiple counters for fo= rmat
>> encoding. At least for some of the byte counters I don=E2=80=99t t= hink taking one bit
>> for other purposes would result in an Internet congestion collapse= =E2=80=A6 But, I
>> have already said that the -13 proposal works for me, so I=E2=80= =99ll not try to come
>> up with another variant myself.
>>>>
>>>>
>>>> To me, one potential difference between two proposals woul= d be
>> incremental deployment. The proposal in -13 only has an advantage = if
>> middleboxes such as firewalls will indeed pass TCP options with a = format that
>> contains content beyond the (first) Accurate ECN standard (i.e., c= urrently
>> unused length values). IMHO it is too early to know whether firewa= lls would
>> indeed allow this in future.
>>>>
>>>>
>>>>=C2=A0 =C2=A0From a security perspective, it is not clear t= o me whether allowing
>> arbitrary unspecified bytes in a TCP option is a good idea *at all= *. It will be
>> interesting to hear the opinion from SEC area on that. Personally,= I am not
>> convinced that this really makes sense, but I my concerns are not = strong
>> enough to formally push back. I=E2=80=99ll leave it to others to t= hink about whether
>> this is a bug or a feature.
>>>>
>>>> [BB] Well, let's first try to deal with security ourse= lves:
>>>> * Octets that are explicitly declared as part of an option= cannot be used
>> for a buffer overflow attack. I don't really need to, but I co= uld add the
>> following text to the forward compatibility wording:
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0A receiver considers octets beyo= nd those it uses, but within the
>> specified length, as if they are padding.
>>>> * And such octets cannot be any different from the current= ability of a
>> sender to add padding. So there's no new attack possible here.=
>>>> * And there's no need to specify a max length for any = AccECN Option,
>> which would just unnecessarily limit flexibility.
>>>> [ms] I have more thought about the covert channel that som= e unspecified
>> bytes in a standards track TCP option could offer=E2=80=A6 In part= icular if the AccECN
>> option gets widely deployed and used, would some malicious users f= ind
>> those bytes useful? For what? For instance, what in the AccECN pro= tocol
>> design prevents use of these =E2=80=9Cpadding=E2=80=9D bytes as su= per-cookie? To me, it is
>> much more important to think about abuse of whatever we standardiz= e
>> *now*, instead of engineering for some entirely unknown future. I = am not a
>> security expert, but I suggest a careful analysis of any security = implications of
>> the AccECN option. We seldomly specify new TCP options and malicio= us
>> users will certainly look for =E2=80=9Copportunities=E2=80=9D in t= he spec. So far, I don=E2=80=99t know
>> whether that whole idea of forward compatibility is a feature or a= bug.
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> Maybe one lesson learnt is that the document could have a = non-
>> normative appendix that explains the rationale for the finally pic= ked TCP
>> option encoding. That may also help if there are further questions= whether
>> two codepoints are really required, e.g. by the IESG (if two codep= oints are
>> still the design after WGLC). At least for past TCP option codepoi= nt allocations
>> I recall some discussions late in the IETF process. In those past = cases, good
>> arguments in an appendix and running code has helped a lot.
>>>>
>>>> [BB] I can do that. Appx B is already similar, giving Desi= gn Rationale for the
>> ACE field.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Bob Briscoe <ietf@bobbriscoe.net>
>>>> Sent: Tuesday, November 17, 2020 6:10 AM
>>>> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Y= oshifumi
>>>> Nishida <nsd.ietf@gmail.com>
>>>> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
>>>> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, Richard
>>>> <Richard.Scheffenegger@netapp.com>; tcpm IETF list &l= t;tcpm@ietf.org><= br> >>>> Subject: Re: AccECN field order
>>>>
>>>>
>>>>
>>>> Michael,
>>>>
>>>> On 16/11/2020 17:36, Scharf, Michael wrote:
>>>>
>>>> Bob,
>>>>
>>>>
>>>>
>>>> One proposal using the length field with *one option codep= oint only*
>>>> is detailed in:
>>>> https://mailarchive.ietf.org/arch/msg= /tcpm/zo-
>> 1OR0nRfhHocX8yvTvpC4BNMo
>>>> /
>>>>
>>>>
>>>>
>>>> It is the third option mentioned in this e-mail. One examp= le would be to
>> use option length values 5/8/11 for one encoding type and option l= ength
>> values 6/9/12 for the other encoding type (i.e., order of fields).= Or one could
>> use some other combination of length values =E2=80=93 the only req= uirement is that a
>> certain value for the option length is only used by one of the opt= ion formats.
>> In that approach, the value of the length field would thus directl= y describe
>> the encoding of the option. Unless I miss something, this would wo= rk and it
>> would just require one option codepoint.
>>>>
>>>>
>>>> Thus, alternatives to two option codepoints exist and I ha= ve explained
>> them on the list in March 2020.
>>>>
>>>> OK, sorry, yes, I remember this now.
>>>>
>>>> As I will explain in the AccECN status update talk today i= n virtual Bangkok,
>> the draft has made provision for different length values than 5/8/= 11. It says
>> existing implementations MUST accept length values other than thos= e
>> currently defined. But then read in as many whole 3-byte fields as= they can.
>>>> This can be used to add a flags byte on the end in future,= for extensibility.
>> Or any other form of extensibility the WG might decide in the futu= re.
>>>> I know a flags byte at the end seems odd compared to at th= e beginning.
>> But (if decided it's needed in future) it's reasonably eas= y to implement by
>> reading the whole option, then processing the last byte, before re= ading the
>> rest of the option.
>>>> I believe you will agree that this is a better way to util= ize different lengths.
>>>>
>>>> And thank you for repeatedly emphasizing that you're h= appy with the 2-
>> kind scheme, or other alternatives.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Anyway, I don=E2=80=99t really care how the options are en= coded as long as the
>> receiver doesn=E2=80=99t need per-connection state for decoding a = TCP option. So,
>> personally, I would be fine with using e.g. the length field as de= scribed in my
>> old e-mail. Or an additional flag byte. And one could come up with= further
>> encodings, e.g., by using one or a few bits as a short =E2=80=9Cty= pe=E2=80=9D field for each
>> counter. This is all about protocol engineering. And all these var= iants have
>> their pros and cons.
>>>>
>>>>
>>>> I am also fine with using two option codepoints as specifi= ed in -13; this is
>> probably the approach that consumes the least number of bits.
>>>>
>>>>
>>>> Michael (w/o any hat)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Bob Briscoe <ietf@bobbriscoe.net>
>>>> Sent: Monday, November 16, 2020 5:52 PM
>>>> To: Yoshifumi Nishida <nsd.ietf@gmail.com>
>>>> Cc: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; M= ichael Tuexen
>>>> <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org; Mirja Kuehlewind
>>>> <ietf@kuehlewind.net>; Scheffenegger, Richard
>>>> <Richard.Scheffenegger@netapp.com>; tcpm IETF list &l= t;tcpm@ietf.org><= br> >>>> Subject: AccECN field order
>>>>
>>>>
>>>>
>>>> Yoshi, (adding the tcpm list in cc)
>>>>
>>>> On 05/11/2020 06:58, Yoshifumi Nishida wrote:
>>>>
>>>> Hi Bob,
>>>>
>>>>
>>>>
>>>> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe <ietf@bobbriscoe.net> >> wrote:
>>>> Yoshi,
>>>>
>>>> On 04/11/2020 06:51, Yoshifumi Nishida wrote:
>>>>
>>>> Hi, folks,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In my understanding, I'm not sure if we settled down o= n using two option
>> kinds or encoding schemes for 24bits fields in acc ecn draft.
>>>> So, I think there're still something to be clarified a= nd hope things will be
>> settled at the meeting.
>>>>
>>>> [BB] I know a WG can change it's mind at any time. But= I'd rather we just
>> clarified what a previous decision was, to avoid the need to keep = re-opening
>> discussion on a question that have been decided then changed three=
>> different ways already.
>>>> My memory is not so good these days. I trusted that Michae= l S
>> remembered the decision correctly, and I seem to remember that dec= ision
>> being made.
>>>> I've just checked the minutes of the last interim:
>>>>
>>>> https://datat= racker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429
>>>> 1600/ and they mention Michael's proposal to use two k= inds, but don't
>>>> record any decision.
>>>> The jabber log gives no clues about any decision.
>>>>
>>>> I can't find an audio or video recording. Can you poin= t me at one?
>>>>
>>>>
>>>>
>>>> I thought that it's because there was no clear decisio= n at the meeting.
>>>>
>>>> But, you can check https://www.youtube= .com/watch?v=3DKsB0_Nb8-kA
>>>>
>>>> Please let us know if you have any questions or opinions w= ith regard to
>> this.
>>>>
>>>> [BB] I checked the Youtube link you sent below.
>>>>
>>>> First I think we're agreed no-one was fighting for us = to keep the previous
>> way we did this (using the initial value of the field to set the o= rder for the
>> connection).
>>>> In my presentation I said there was strong resistance from= Michael to do it
>> a different way.
>>>> (also, offlist, the co-authors including me also didn'= t like this so
>>>> much. And Ilpo said it made the implementation complex.) >>>>
>>>> Then came the question of what we do instead. There were t= hree
>> alternative proposals:
>>>> a) use 2 option kinds
>>>> b) add a flags byte
>>>> c) somehow use the length field maybe
>>>>
>>>> Michael raised (c) in the meeting as a possibility, but no= -one could think
>> how to distinguish two options of the same length but a different = field order
>> using the length field. Michael said he'd post any ideas to th= e list if he could
>> think of any, but that didn't happen.
>>>> So we're left choosing between (a) and (b).
>>>> I said in the meeting (and on the list when discussing wit= h Ilpo) that I'd be
>> happy to go with (b), but only if there was another use for a flag= . Because it
>> would consume 1B more options space in many packets, which is a sc= arce
>> resource.
>>>> Ilpo had a proposed use for another flag (to help synch co= unters after a
>> loss), but I think the discussion about it ended that it wouldn= 9;t be helpful, 'cos
>> the way it worked depended on itself (circular logic).
>>>> In conclusion, I don't think there was an explicit dec= ision to go with 2
>> option kinds, but it ended up as the 'last person standing'= ;.
>>>> I like it. It's simple. And apparently option kinds ar= e not such a scarce
>> resource.
>>>> Perhaps we can ratify this in the WG tomorrow.
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>>
>>>> Yoshi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>> __________________________________________________________
>> ______
>>>> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bob= briscoe.net/
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>> __________________________________________________________
>> ______
>>>> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bob= briscoe.net/
>>>>
>>>>
>>>>
>>>> --
>>>>
>> __________________________________________________________
>> ______
>>>> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bob= briscoe.net/
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ie= tf.org
>>>> https://www.ietf.org/mailman/listinfo/tcp= m
>> --
>> __________________________________________________________
>> ______
>> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=

--
________________________________________________________________
Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000003def6a05bb2743fc-- From nobody Fri Feb 12 09:52:29 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379293A1831 for ; Fri, 12 Feb 2021 09:52:28 -0800 (PST) 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 nResPW5llSvH for ; Fri, 12 Feb 2021 09:52:25 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 9EB143A182F for ; Fri, 12 Feb 2021 09:52:25 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id a1so127759qvd.13 for ; Fri, 12 Feb 2021 09:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VRjHdsw0zgrKX43dnGp7MIZbmbyxjHNCiY7qDI+tjdg=; b=luqqmW0pps9ulcMQJWC02fxVWGO2jV1SxVZq6uMXTMHqQzmig/yvJC7O36NOcxog6h 9gRnSN1e84TTf+60oQJ9JF+ltQlP7VRmg2wZ2wzTVfJAY5B98avsGumiOIUnRWnTu2LV Ghy1jBQEw6eZ22zJ7sNasntfupuGSp0TdnM48mnXCl6dtaDj8Zc+P/C9s97xuiU7iEAQ prXksL7pZ2Dpplab/gvf9v6OBbvt8w1NdtW1yjiu1ekwPJ19ua9K0cLWNYP+vtar2Jr9 zIwx+9uavpT5Y2xsuRXSHJ4xIOq64MxjK+7DxvF3VESYku2BTMgUf+HDdzHQk/zqLBr2 I60g== 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=VRjHdsw0zgrKX43dnGp7MIZbmbyxjHNCiY7qDI+tjdg=; b=LYiLTWWlQsfIc2aSl16qAA8UhuJNMYH0dseBrqeYf6Q4LphOf+SqYTbabELwDJlbnX nLVa0PfF+MUoE9a44mXQJui3jICtL2rS9q6cf080Gr+czJqX9RySQc8teiTKxe6dH4+x 7cV+bBPFo/p1pRBydrS4DN1/GUflNgIEzcASXFNpCcZxEYuuY3x0sU3QjImEg21/yzpy tFtMGTngrJCCiFwZrqTeLfN/4/zZ1NRdF7IBw+bnYhLRaqLtR9CdrXInt6mgEcBxYxFl FINloeQjh0qgDegqeDVmnZQKHPc0Vy237/qbO7xZfw6SqwDCAjbs1OZkIKmvf7bn+uG8 JaLg== X-Gm-Message-State: AOAM533ofkSW/1ouV0wPhFrKxhqkS+/yEbsewVS+F1JZoNEMz8y8lIDM scaFCMHo9TWXp/YwGxscpOpOtHaiMIVE7LQXNNZAk6KL X-Google-Smtp-Source: ABdhPJyXhW8AZgjKF1PwcnQofcrgI1pCH/3OqvumfXoKzCVYx7jIOAtuOTwQIyw1F7S1WGgVtLRV+nEdkuAFC4bBmoc= X-Received: by 2002:a0c:e90c:: with SMTP id a12mr3525530qvo.32.1613152344789; Fri, 12 Feb 2021 09:52:24 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> In-Reply-To: From: Yoshifumi Nishida Date: Fri, 12 Feb 2021 09:52:13 -0800 Message-ID: To: Joseph Touch Cc: "tcpm@ietf.org Extensions" , Liangqiandeng Content-Type: multipart/alternative; boundary="0000000000007ad56e05bb274c39" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 17:52:28 -0000 --0000000000007ad56e05bb274c39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, On Thu, Feb 11, 2021 at 9:40 AM Joseph Touch wrote: > Hi, Yoshifumi, > > On Feb 11, 2021, at 1:05 AM, Yoshifumi Nishida wrote= : > > Hi Joe, > > On Wed, Feb 10, 2021 at 7:55 AM Joseph Touch wrote= : > >> Hi, all, >> >> FWIW, my view is that: >> >> - it MAY be reasonable for an option to negotiate parameters after the >> TWHS >> BUT this can be VERY difficult, esp. because the negotiation needs to >> account for segment loss and reordering >> >> - a new option CANNOT provide that opportunity for existing options >> those existing options were defined assuming establishment during the TW= HS >> >> - a new option CANNOT provide that opportunity for new options UNLESS >> THEY EXPLICITLY ALLOW IT >> > > I won't disagree with them, but I have a few comments on them. > > - When we try to define new options, I think we cannot ignore option spac= e > size in today's TCP. > If there's risk that the option cannot be fit into SYN, protocol > designers can think about adopting this approach. > > > I think that applies more to the =E2=80=9Ccompressed=E2=80=9D version tha= n the other part, > but compressed options work only for initially flag (on/off) options with > no parameters in the SYN. > > Otherwise, they will have to give up using the option or sacrifice some > of existing options in some situations. > I'm not sure if it's very difficult to negotiate parameters after TWHS > because it has already been done in MPTCP. > > > It has been done *within the option*, not as a general case available to > option designers. Those are quite different. > > - Not all new options need to negotiate parameters. For > example,draft-gomez-tcpm-ack-rate-request or draft-ietf-tcpm-tcp-edo. > For these cases, their options can be put into the aggregated option in > SYN, which can save some space without any difficulties. > > > Agreed; again, that separates the compressed aspect from other aspects. > Perhaps creating a single compressed option for the next N such SYN-=E2= =80=9Cflag=E2=80=9D > options would be useful. > > - I think we can think about updating existing options to support this > approach. At least, I think it's not impossible. > > > Updating options is likely to be much more difficult than creating new > ones, which is itself difficult... > > But, I guess we should focus on using this for new options at first. > > > Agreed - but again, I=E2=80=99d suggest that all the above applies more t= o a > single =E2=80=9Cflag options=E2=80=9D option for new options only. > > That could be done to support the next 16 such flag options options in on= e > word-aligned option. I don=E2=80=99t know that it would be worth trying t= o optimize > beyond 16 of those, though. > > And I do NOT think that this option should waste space trying to game > devices that ignorantly reflect SYN options in SYN-ACK. The definition in > TCP and most such options stands - if an option is reflected in a SYN-ACK= , > it is deemed supported. > OK. So, in my understanding, what you're suggesting are the followings. - Aggregated options would be useful. but, the format can be simple 4 bytes length option that can accomodate 16 options. - The tricks to avoid reflecting options in SYN ACK will not be needed because it's the receiver's responsibility. - Delayed negotiation might be possible. But, no generic framework is needed. Each option should be designed for its own way to support it. But, once thing I am wondering is that we can still combine Aggregated options and delayed negotiation even with this one. if you are meaning options not appeared in SYN cannot be used in the following segments, I think accecn option might be a precedent for this. Thanks, -- Yoshi > On Feb 10, 2021, at 2:28 AM, Yoshifumi Nishida wrote= : >> >> Hi Kangjiao, >> >> OK. I think it has some similarities. I will think about this further an= d >> will get back to you. >> -- >> Yoshi >> >> On Tue, Feb 9, 2021 at 5:14 PM Kangjiao wrote: >> >>> Hi Yoshi, >>> >>> >>> >>> I wrote a draft to propose an idea for MPTCP subtype capability exchang= e >>> during MPTCP handshake. We think, in MPTCP, some options are mandatory= but >>> some options can be set as optional ones. So an exchange mechanism of >>> actual capability between both parties are needed. >>> >>> >>> >>> URL: >>> https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exch= ange-00.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exc= hange/ >>> >>> Html: >>> https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exch= ange-00.html >>> >>> Htmlized: >>> https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange= -00 >>> >>> >>> >>> When I read your draft, I think maybe our above work have some relevanc= e >>> to your suggestions. If you think it'll help with this work, I hope we = can >>> discuss this new negotiation mechanism for related options and subtypes= . >>> Thanks >>> >>> >>> >>> Best wishes, >>> >>> Jiao >>> >>> >>> >>> *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Yoshifumi >>> Nishida >>> *Sent:* Wednesday, February 3, 2021 3:12 PM >>> *To:* tcpm@ietf.org Extensions >>> *Subject:* [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.tx= t >>> >>> >>> >>> Hi folks, >>> >>> >>> >>> I prepared a draft for SYN option space extensions. >>> >>> I know this is a difficult issue in TCP and has been discussed for a >>> long time. >>> >>> But, I'm thinking that it might be a good time to discuss it again. >>> >>> >>> >>> Key ideas of the draft are the followings. >>> >>> 1: drastic changes in TCP's spec will not be required >>> >>> (it does not require updating TCP header format nor using multiple >>> SYN packets or additional SYN-like packets) >>> >>> 2: utilize the option negotiation schemes in mptcp for generic purposes= . >>> so, I think it can be considered middlebox friendly. >>> >>> 3: it has some limitations (e.g it can only extend around 30-40 bytes >>> for SYN option space). But, if it's combined with EDO, we can use more >>> option space. >>> >>> (depends on how EDO draft will progress, though) >>> >>> >>> >>> Please let me know if you have any questions or comments or suggestions= . >>> >>> >>> >>> Thank you so much! >>> >>> -- >>> >>> Yoshi >>> >>> >>> >>> >>> >>> ---------- Forwarded message --------- >>> From: >>> Date: Tue, Feb 2, 2021 at 10:45 PM >>> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt >>> To: >>> >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Aggregated Option for SYN Option Space >>> Extension >>> Author : Yoshifumi Nishida >>> Filename : draft-nishida-tcpm-agg-syn-ext-00.txt >>> Pages : 14 >>> Date : 2021-02-02 >>> >>> Abstract: >>> TCP option space is scarce resource as its max length is limited to >>> 40 bytes. This limitation becomes more significant in SYN segments >>> as all options used in a connection should be exchanged during SYN >>> negotiations. This document proposes a new SYN option negotiation >>> scheme that provide a feature to compress TCP options in SYN segment= s >>> and provide more option space. The proposed scheme does not update >>> the format of TCP header nor transmit any additional SYN or SYN-like >>> segments so that it has lower risks for middlebox interventions. In >>> addition, by combining another proposal for option space extension, >>> it is possible to provide further option space. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 >>> https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-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/ >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --0000000000007ad56e05bb274c39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Thu, Feb 11, 2021 at 9:40 AM Joseph Touch = <touch@strayal= pha.com> wrote:
Hi, Yoshifumi,

On Fe= b 11, 2021, at 1:05 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

=
Hi Joe,

On Wed, Feb 10, 2021 at 7:55 AM Jos= eph Touch <tou= ch@strayalpha.com> wrote:
Hi, all,

FWIW, my view is that:

- it MAY be reasonable for an option to negotiate pa= rameters after the TWHS
BUT this can be VERY difficult, esp. because the negotiation needs to a= ccount for segment loss and reordering

- a new opt= ion CANNOT provide that opportunity for existing options
those existing options were defined as= suming establishment during the TWHS

- a new optio= n CANNOT provide that opportunity for new options UNLESS THEY EXPLICITLY AL= LOW IT

I won't disagree wit= h them, but I have a few comments on them.

- When = we=C2=A0try to define new options, I think we=C2=A0cannot ignore option spa= ce size in today's TCP.=C2=A0=C2=A0
=C2=A0 If there's ris= k that the option cannot be fit into SYN, protocol designers can think abou= t adopting this approach.=C2=A0
I think that applies more to the =E2=80=9Ccompressed=E2=80=9D = version than the other part, but compressed options work only for initially= flag (on/off) options with no parameters in the SYN.

=C2=A0 = Otherwise, they=C2=A0will have to give up using the option or sacrifice=C2= =A0some of existing options in some situations.
=C2=A0 I'm no= t sure if it's very difficult to negotiate parameters after TWHS becaus= e it has=C2=A0already been done in MPTCP.=C2=A0=C2=A0

It has been done *within the option*, no= t as a general case available to option designers. Those are quite differen= t.

- Not all new options need to negotiate parameters. For ex= ample,draft-gomez-tcpm-ack-rate-request or draft-ietf-tcpm-tcp-edo.
=C2=A0 For these cases, their options can be put into the aggregated opt= ion in SYN, which can save some space without any difficulties.
=

Agreed; again, that separates = the compressed aspect from other aspects. Perhaps creating a single compres= sed option for the next N such SYN-=E2=80=9Cflag=E2=80=9D options would be = useful.

- I think we can think about updating existing option= s to support this approach. At least, I think it's not impossible.=C2= =A0

Updating option= s is likely to be much more difficult than creating new ones, which is itse= lf difficult...

=C2=A0 But, I guess we should focus on using = this for new=C2=A0options at first.

Agreed - but again, I=E2=80=99d suggest that all the above appl= ies more to a single =E2=80=9Cflag options=E2=80=9D option for new options = only.

That could be done to support the next 16 su= ch flag options options in one word-aligned option. I don=E2=80=99t know th= at it would be worth trying to optimize beyond 16 of those, though.

And I do NOT think that this option should waste space tr= ying to game devices that ignorantly reflect SYN options in SYN-ACK. The de= finition in TCP and most such options stands - if an option is reflected in= a SYN-ACK, it is deemed supported.

=
OK. So, in my understanding, what you're suggesting are the follow= ings.

- Aggregated options would be useful. but, t= he format can be simple 4 bytes length option that can accomodate 16 option= s.
- The tricks to avoid reflecting options in SYN ACK will not b= e needed because it's the receiver's responsibility.
- De= layed negotiation might be possible. But, no generic framework is needed. E= ach option should be designed for its own way to support it.

=
But, once thing I am wondering is that we can still combine Aggr= egated options and delayed negotiation even with this one.
if you= are meaning options not appeared in SYN cannot be used in the following se= gments, I think accecn option might be a precedent=C2=A0for this.=C2=A0=C2= =A0

Thanks,
--
Yoshi



On Feb 10, 2021, at 2:28 AM, Yoshifum= i Nishida <nsd.i= etf@gmail.com> wrote:

Hi=C2=A0Ka= ngjiao,

OK. I think it has some similarities. I wi= ll think about this further and will get back to you.
--
Yoshi

On Tue, Feb 9, 2021 at 5:14 PM Kangjiao <kangjiao@huawei.com> wrote:

Hi Yoshi,

=C2=A0

I wrote a d= raft to propose an idea for MPTCP subtype capability exchange during MPTCP = handshake.=C2=A0 We think, in MPTCP, some options are mandatory but some options can be set as optional ones. So an exchange mechanism of = actual capability between both parties are needed.

=

=C2=A0=

URL:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capabil= ity-exchange-00.txt

Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 https://datatracker.ietf.org/doc/draft= -kang-tcpm-subtype-capability-exchange/

Html:=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ht= tps://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-0= 0.html

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exc= hange-00

=C2=A0

When I read your draft, I think maybe our above work have so= me relevance to your suggestions. If you think it'll help with this wor= k, I hope we can discuss this new negotiation mechanism for related options and subtypes. T= hanks

=C2=A0

Best wishes,

Jiao

=C2=A0

= From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Wednesday, February 3, 2021 3:12 PM
To: tcpm@ietf.org= Extensions <tcpm= @ietf.org>
Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.t= xt

=C2=A0

Hi folks,

=C2=A0

I prepared a draft for SYN= option space extensions.

I know this is a difficult= issue in TCP and has been discussed for a long time.=C2=A0

But, I'm thinking that= it might be a good time to discuss it again.

=C2=A0

Key ideas of the draft are= the=C2=A0followings.

1: drastic changes in TCP&= #39;s spec will not be required=C2=A0

=C2=A0 =C2=A0 (it does not= require updating TCP header format nor using multiple SYN packets or addit= ional SYN-like packets)

2: utilize the option nego= tiation schemes in mptcp for generic purposes. so, I think it can be consid= ered middlebox friendly.

3: it has some limitations= =C2=A0(e.g it can only extend around 30-40 bytes for SYN option space). But= , if it's combined with EDO, we can use more option space.

=C2=A0 =C2=A0 (depends on = how EDO draft will progress, though)

=C2=A0

Please let me know if you = have any questions or comments or suggestions.

=C2=A0

Thank you so much!<= u>

--

Yoshi=

=C2=A0

=C2=A0

---------- Forwarded messa= ge ---------
From: <int= ernet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <i-d-anno= unce@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Aggregated Option for SYN Option Space Extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-agg-syn-ext-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-02-02

Abstract:
=C2=A0 =C2=A0TCP option space is scarce resource as its max length is limit= ed to
=C2=A0 =C2=A040 bytes.=C2=A0 This limitation becomes more significant in SY= N segments
=C2=A0 =C2=A0as all options used in a connection should be exchanged during= SYN
=C2=A0 =C2=A0negotiations.=C2=A0 This document proposes a new SYN option ne= gotiation
=C2=A0 =C2=A0scheme that provide a feature to compress TCP options in SYN s= egments
=C2=A0 =C2=A0and provide more option space.=C2=A0 The proposed scheme does = not update
=C2=A0 =C2=A0the format of TCP header nor transmit any additional SYN or SY= N-like
=C2=A0 =C2=A0segments so that it has lower risks for middlebox intervention= s.=C2=A0 In
=C2=A0 =C2=A0addition, by combining another proposal for option space exten= sion,
=C2=A0 =C2=A0it is possible to provide further option space.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg= -syn-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext= -00
https://datatracker.ietf.org/doc/html/draft-nish= ida-tcpm-agg-syn-ext-00


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

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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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

--0000000000007ad56e05bb274c39-- From nobody Fri Feb 12 15:05:59 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260873A1085 for ; Fri, 12 Feb 2021 15:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlZ6lpUInpj2 for ; Fri, 12 Feb 2021 15:05:52 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 07E6B3A1082 for ; Fri, 12 Feb 2021 15:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kwmZRzYY7acFF4PcgrcfmKA1t2vqOJqw6lKbNua3CBo=; b=Y+aiSjRk46wHP6fT9QJSoteHh HOV1vExAaZNoZyuSPiTMDXR3UEG/ShIh+Affp4reCXZA3OI5tf/qiMXoWBNdV2FyEQ4uT7520OX7q egTwox2PNeuRmM1OWaXmDKTP6K4/CI2CPyM55USaHXdISyUBMVnKq4HjaqFiOyruLHMTq71UaTGxW xlYr+J3eJVcdkp8Jqbw8nPS6ql5RnBBx98B6oPBxAZfHnKSstmM5c1YrVGz12jXGO5c69HywFFEnh 6o33oZiKNLwwuqtNJ2xifuHX+hUCbD2Y6Fky4USrlgA2q088F+17YKZtjayDErsaL8IhnF+jrmMg5 aThWFfb2A==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:53264 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lAhVU-0000hv-C4; Fri, 12 Feb 2021 23:05:48 +0000 To: Yoshifumi Nishida Cc: "Scharf, Michael" , "Scheffenegger, Richard" , Mirja Kuehlewind , tcpm IETF list References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <381499f5-3333-08c5-2ffd-fba77e027795@bobbriscoe.net> <1e61a7d3-b6be-d995-4fc2-777bc2d5d5fe@bobbriscoe.net> From: Bob Briscoe Message-ID: <298c8924-c751-8f08-0caa-6d5eeaf293ac@bobbriscoe.net> Date: Fri, 12 Feb 2021 23:05:39 +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: Content-Type: multipart/alternative; boundary="------------6069E2D629E3E8D77A6261B3" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 23:05:58 -0000 This is a multi-part message in MIME format. --------------6069E2D629E3E8D77A6261B3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yoshi, On 12/02/2021 17:49, Yoshifumi Nishida wrote: > > On Thu, Feb 11, 2021 at 1:33 PM Bob Briscoe > wrote: > > > > On 09/02/2021 17:56, Scharf, Michael wrote: > > Bob, > > > >> -----Original Message----- > >> From: Bob Briscoe > > >> Sent: Tuesday, February 9, 2021 5:58 PM > >> To: Scheffenegger, Richard >; Mirja > >> Kuehlewind >; > Scharf, Michael >> esslingen.de > > >> Cc: tcpm IETF list > > >> Subject: Re: AW: [tcpm] AccECN field order > >> > >> Richard, > >> > >> I just noticed I missed the last para of the old email from you > below. > >> Response inline, tagged [BB]... > >> > >> On 23/11/2020 12:42, Scheffenegger, Richard wrote: > >>> I am also in favor of using two distinct option codes. > >>> > >>> However, > >>> > >>>> Or I guess we could say that only one option should be used for a > >> connection. > >>> I am opposed to this - with two option codes, a sender should > be free to > >> choose whichever he prevers at any one point; For example, if > the sender a > >> segment (e.g. may be the receiver side)  has to update the EE1 > couter, but > >> also convey SACK information, it would be good to use the one, > where the > >> EE1 field is first, and omit all remaining fields; > >>> Later in the same connection, that very same host may choose > to update > >> the CE field together with some SACK information, and use the other > >> codepoint in order to preserve as much TCP option space for the > SACK > >> option... > >> > >> [BB] I agree with you here (and disagree with Mirja below). The > nice > >> thing about 2 options kinds is they are self-describing, so > they can be > >> stateless (for instance, consider the code you would have to > otherwise > >> add for when a host switches to a different congestion control > module - > >> a lot of complexity despite being unlikely to happen). > >> > >>> > >>> As for extensibility: I would want to avoid that topic, and > just specifiy the > >> three correct supported lengths here, and not mention (other > than ignoring > >> "odd" fractionals of the 3-byte wide counters) what happens > with other > >> lengths... > >> > >> [BB] A protocol spec should surely say what to do with unexpected > >> inputs. Not specifying this is one of the main reasons we have such > >> trouble changing things later - because we discover some > implementers > >> handled the unexpected in different ways to others (e.g. > ignore, vs RST > >> the connection), and others only handled expected inputs and > didn't even > >> think to check for anything else. > >> > >> So, I believe we have to either say "reset the connection" or > "ignore", > >> in response to an unexpected option length. I figure that, if > there's no > >> harm in ignoring something unexpected, then why not ("liberal > in what > >> you receive" principle). > >> > >> Earlier in this thread, Michael Scharf pointed out that there > is some > >> potential harm here (covert channel of up to 29B), but I > pointed out > >> that TCP/IP has plenty of other ways of creating covert > channels, so > >> we're not really adding to any problem here. But I did say that > we would > >> highlight the covert channel in the Security Considerations > section, so > >> the Sec Area has a chance to object. If it raises as serious > concern, > >> then we should switch from "ignore" to "reset", But I doubt it > will. > > I think we first have to come to the conclusion *inside* TCPM > whether such a new covert channel is actually acceptable. > > > > Existing covert channels do not at all imply that a new covert > channel is a good idea (and, IMHO, 29B per packet is a lot). > Network administrators and operators know how to deal with the > existing problems in TCP/IP. Adding any new security issue needs > careful reasoning. > > > > As individual contributor to TCPM, I believe that this covert > channel must just be removed from the next version of the draft. > At least I don't need other opinions to come to this personal > conclusion. > > > > If this was less obvious others in the WG, TCPM could ask for an > early SECDIR review to get further guidance ASAP. Then this > question can be sorted out while we finish the protocol. > > > > If TCPM needs any external input on covert channels, I think an > early SECDIR review would be a much better approach compared to > having a security discussion during IETF last call. We are here > discussing a standards track extension of one of the core Internet > protocols. In such a case, at least in my view on IETF processes, > other IETF areas can expect that TCPM ties to deal with known open > issues within the WG as far as possible, i.e., before they see a > "stable" specification in the IETF last call. > > > > In a nutshell: > > > > -1 on leaving this question open until IETF last call > > [BB] That's a perfectly reasonable process proposal. > > I just wanted to add that there are not just 2 choices: the WG (with > advice from SEC area if necessary) is free to limit the bandwidth of > this covert channel anywhere between 0 and 29B per packet by simply > limiting how much extensibility the protocol allows the option length > field to offer, with a 0B covert channel corresponding to no > extensibility. > > > OK. Michael.S abstains from the decision for SECDIR review, but other > co-chairs think this is an important point to be checked. > So, if there's no specific opposition, we would like to ask for SECDIR > review before WGLC. > > Do authors want to update the draft beforehand to add some more > clarifications or are there any other thoughts on this? [BB] The current draft could probably go to SECDIR review as it is. However, I have a few edits already done in my local copy, and a todo list of a few more, which I could try to get done in the next few days. Then I'll post a rev. So I guess it might as well wait a few days for those updates. Agree? Bob > > Thanks, > -- > Yoshi > > > >>> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Mirja Kuehlewind > > >>> Gesendet: Montag, 23. November 2020 12:39 > >>> An: Neal Cardwell >; Scharf, Michael > >> >; Bob Briscoe > > > >>> Cc: Yoshifumi Nishida >; tcpm IETF list > >> >; Scheffenegger, Richard > >> >; Michael Tuexen >> muenster.de >; tcpm-chairs@ietf.org > > >>> Betreff: Re: [tcpm] AccECN field order > >>> > >>> NetApp Security WARNING: This is an external email. Do not > click links or > >> open attachments unless you recognize the sender and know the > content is > >> safe. > >>> > >>> > >>> > >>> Hi all, > >>> > >>> I think I also support two options as this is the most simple > solution. > >>> > >>> We probably need to look at section 3.2.3.2. (Path Traversal > of the AccECN > >> Option) again, as I think this section assumes mostly one > option. Or I guess > >> we could say that only one option should be used for a connection. > >>> Regarding use of the option length for extensibility. I know > new options are > >> hard to deploy but that’s the extensibility mechanism we have > with TCP. Not > >> sure we want to invent a new now. If we think we need more > extensibility > >> for AccECN for any reason, we should specify valid option > length values that > >> include a flags field now. > >>> Mirja > >>> > >>> > >>> > >>>> On 18. Nov 2020, at 01:03, Neal Cardwell > > wrote: > >>>> > >>>> As someone who contributes to a TCP implementation, I would > put in a > >> vote for the "Two Option Kinds" proposal outlined in slide 6 here: > >>>> > >>>> > https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor > >>>> > e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica > >>>> tion-01#page=6 > >>>> > >>>> This approach has the virtue of simplicity, which hopefully > may help avoid > >> middlebox bugs, speed standardization and development, and ease the > >> process of maintaining fast and stable implementations. > >>>> neal > >>>> > >>>> > >>>> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael > >> esslingen.de > wrote: > >>>> Inline some comments [ms]. > >>>> > >>>> > >>>> > >>>> Given that I don’t ask for any text chances, I’ll not > follow-up forever in this > >> discussion. I don’t own running code and a lot of encoding > details mainly > >> affect an implementation. > >>>> > >>>> > >>>> IMHO the rest of the WG has to think about the option design > more than > >>>> me. So, this is mostly about triggering a discussion… > >>>> > >>>> > >>>> > >>>> From: Bob Briscoe > > >>>> Sent: Tuesday, November 17, 2020 1:20 PM > >>>> To: Scharf, Michael >; Yoshifumi > >>>> Nishida > > >>>> Cc: Michael Tuexen >; tcpm-chairs@ietf.org > ; > >>>> Mirja Kuehlewind >; Scheffenegger, Richard > >>>> >; tcpm IETF list > > > >>>> Subject: Re: AccECN field order > >>>> > >>>> > >>>> > >>>> Michael, > >>>> > >>>> On 17/11/2020 08:10, Scharf, Michael wrote: > >>>> > >>>> Bob, > >>>> > >>>> > >>>> > >>>> I am fine with the two option kinds proposed in -13, but I > don’t buy your > >> arguments why this encoding is better than others. > >>>> > >>>> > >>>> Most importantly, I don’t think that your “forward compatibility” > >> argument is a very compelling reason for two codepoints. All > proposals I am > >> aware of have their pros and cons. And I am not aware of a really > >> comprehensive discussion. At least neither the e-mail below nor > today’s > >> meeting discuss all tradeoffs I would investigate. > >>>> > >>>> [BB] You're right - the discussion below is useful and necessary. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> For instance, the benefit of the length encoding variant > would be to > >> consume only one TCP option codepoint now. If we decided later > to that a > >> flag byte is needed (say, at the end), a follow-up proposed > standard could > >> specify another option format with that flag byte, using a > second codepoint. > >>>> > >>>> [BB] > >>>> * The new codepoint would require years to deploy (including > in proxies) > >> before it works e2e. > >>>> > >>>> > >>>> [ms] That may depend *a lot* on the environment. In environments > >> where ECN can get deployed today, say in datacenters, rolling > out a new > >> kernel version may perhaps not be the biggest operational > challenge. Also, > >> proxies may not be a significant problem in some of those > cases. Deployment > >> roadmaps are very hard to predict. > >>>> > >>>> * Whereas the 'forward compatibility' approach tries to > ensure that > >> AccECN implementations that are being built today will be ready > to interwork > >> with a future extension. > >>>> * In contrast, if your hypothetical new AccECN codepoint did > need to be > >> deployed later, it would need to include a fall-back to the > current AccECN > >> option when one peer doesn't understand the new codepoint. > >>>> > >>>> > >>>> [ms] This is a reasonable point, albeit not a particularly > strong one, > >>>> given that the option is not really required for basic > >>>> interoperability. Also, a hypothetical follow-up standard could > >>>> include a way to explicitly request the option… > >>>> > >>>> > >>>> * Fall-back would need to avoid a second round of handshake > (given > >>>> this is for low latency), which would only work reliably with an > >>>> option on the SYN (because the 3rd ACK is unreliable) > >>>> > >>>> > >>>> > >>>> [ms] I can’t follow. If an endpoint is unhappy with getting > AccECN option > >> “A” from a peer, I could send a “please send me the better > AccECN option B” > >> after the 3-WHS. It could be an upgrade, not a fallback. Also, > at this point we > >> don’t know what option B would be and in which context it would be > >> needed. Maybe other protocol features would require > negotiation, too. > >> IMHO it is a solvable problem. > >>>> > >>>> * AccECN has so far avoided using any SYN option space, which is > >> important given that is the scarcest resource. > >>>> > >>>> > >>>> [ms] Yep, but as long as no proposal needs SYN options, this > is nothing > >> that would make one solution better than another. > >>>> These days, extending TCP is like playing chess - we have to > think multiple > >> moves ahead! > >>>> > >>>> > >>>> [ms] There is one fundamental difference between chess and > TCP: In > >> chess you precisely know the current situation and can predict > all potential > >> moves in advance (albeit there are a lot). However, we don’t > know the > >> future evolution of TCP, ECN and the Internet as a whole, nor > future > >> requirements. If we try to engineer a TCP extension for some > potential > >> future, we may figure out later that reality is different from > what we > >> designed for. As much as I appreciate your attempts to predict > the future, it > >> would be a big surprise to me if you could correctly predict > what TCP will be in > >> 10 years from now. So, instead of trying to write > specifications that take into > >> account future requirements, which are in fact just unknown, it > is more > >> important for me to write effective, efficient and secure > specifications for > >> what is currently known for sure. > >>>> > >>>> > >>>> [ms] I *don’t* know for sure whether the current AccECN > option will be > >> needed, but I see quite some evidence that support of the > AccECN option(s) > >> is not a top priority these days. That is also something to > think about when > >> designing the details. > >>>> > >>>> > >>>> I need to learn to articulate onto the list all my reasons > for rejecting > >> certain parts of the design space. Sorry about that. > >>>> Yes, I admit, the current proposal is at the cost of burning > two TCP option > >> codepoints. However, you said yourself when you proposed this > approach, > >> that they are not (currently) a scarce resource. Certainly not > as scarce as > >> option space. I just checked: roughly 15% of the option > codepoint allocation > >> space has been used so far. So that's where I would suggest we > compromise > >> first. > >>>> [ms] I made a similar calculation some years ago and came to > a similar > >> conclusion. Investing two codepoints for AccECN is something we can > >> probably afford. But nonetheless we have to reason carefully > why it is really > >> worth the effort. > >>>> > >>>> > >>>> > >>>> Regarding the resulting codepoint consumption (two option > kinds) and > >> the addition of a flag byte, this approach would basically end > up with the > >> same result as the current proposal in -13 plus some > hypothetical future > >> addition leveraging the length field beyond the currently known > use. > >>>> > >>>> > >>>> And, yes, the length encoding variant may be less flexible and/or > >> consume some more bits in some cases, but on the plus side it > only needs > >> one codepoint now – and given that it is entirely unclear > whether any > >> AccECN option will indeed be widely used in future, this is a > big plus. The fact > >> that implementers are quite silent on the option design is not > a good sign. > >>>> > >>>> [BB] Here's another possibility then. > >>>> > >>>> a) [K|L| EE1B | ECEB | EE0B ] > >>>> b) [K|L| EE1B | ECEB | EE0B |F]    if F = 0bXXXXXXX0 > >>>> c) [K|L| EE0B | ECEB | EE1B |F]    if F = 0bXXXXXXX1 > >>>> > >>>> We'd have to decide which order alternative (a) takes. I've > picked EE1B > >> first only 'cos you're right that there is not currently as > much pressure (on the > >> public Internet) for AccECN with ECT(0). > >>>> ==Legend== > >>>> K:    Kind (1B) > >>>> L:    Length (1B) > >>>> ExxB: Echo xx byte counter > >>>> F:    Flags (1B) > >>>> > >>>> Alternatives a) and b) are equivalent, at least while the > only allocated flag > >> is for field order. > >>>> However, alternative b) is available in case other flags are > allocated > >>>> in future The flags byte can only be omitted if (L % 3 == 2). > >>>> The flags byte is considered present if (L % 3) == 0. > >>>> > >>>> Forward compatibility: Options with (L % 3 == 1) MUST be > assumed to > >> include a flags byte, and current implementations ignore the > last byte. > >>>> The flags byte is optional to implement (even if the AccECN > option is > >>>> implemented) If the server includes a flags byte on the > SYN/ACK but the > >> client does not include one on the 3rd ACK or the first data > packet, the server > >> assumes the client does not implement the flags byte and uses only > >> alternative a) for the remainder of the connection. > >>>> > >>>> [ms] I am not sure if we need that, but I take this as > existence proof that > >> other encodings are possible. Personally, I think that other > solutions would > >> be doable if you took one bit from one or multiple counters for > format > >> encoding. At least for some of the byte counters I don’t think > taking one bit > >> for other purposes would result in an Internet congestion > collapse… But, I > >> have already said that the -13 proposal works for me, so I’ll > not try to come > >> up with another variant myself. > >>>> > >>>> > >>>> To me, one potential difference between two proposals would be > >> incremental deployment. The proposal in -13 only has an > advantage if > >> middleboxes such as firewalls will indeed pass TCP options with > a format that > >> contains content beyond the (first) Accurate ECN standard > (i.e., currently > >> unused length values). IMHO it is too early to know whether > firewalls would > >> indeed allow this in future. > >>>> > >>>> > >>>>   From a security perspective, it is not clear to me whether > allowing > >> arbitrary unspecified bytes in a TCP option is a good idea *at > all*. It will be > >> interesting to hear the opinion from SEC area on that. > Personally, I am not > >> convinced that this really makes sense, but I my concerns are > not strong > >> enough to formally push back. I’ll leave it to others to think > about whether > >> this is a bug or a feature. > >>>> > >>>> [BB] Well, let's first try to deal with security ourselves: > >>>> * Octets that are explicitly declared as part of an option > cannot be used > >> for a buffer overflow attack. I don't really need to, but I > could add the > >> following text to the forward compatibility wording: > >>>>       A receiver considers octets beyond those it uses, but > within the > >> specified length, as if they are padding. > >>>> * And such octets cannot be any different from the current > ability of a > >> sender to add padding. So there's no new attack possible here. > >>>> * And there's no need to specify a max length for any AccECN > Option, > >> which would just unnecessarily limit flexibility. > >>>> [ms] I have more thought about the covert channel that some > unspecified > >> bytes in a standards track TCP option could offer… In > particular if the AccECN > >> option gets widely deployed and used, would some malicious > users find > >> those bytes useful? For what? For instance, what in the AccECN > protocol > >> design prevents use of these “padding” bytes as super-cookie? > To me, it is > >> much more important to think about abuse of whatever we standardize > >> *now*, instead of engineering for some entirely unknown future. > I am not a > >> security expert, but I suggest a careful analysis of any > security implications of > >> the AccECN option. We seldomly specify new TCP options and > malicious > >> users will certainly look for “opportunities” in the spec. So > far, I don’t know > >> whether that whole idea of forward compatibility is a feature > or a bug. > >>>> > >>>> > >>>> Michael > >>>> > >>>> > >>>> > >>>> Maybe one lesson learnt is that the document could have a non- > >> normative appendix that explains the rationale for the finally > picked TCP > >> option encoding. That may also help if there are further > questions whether > >> two codepoints are really required, e.g. by the IESG (if two > codepoints are > >> still the design after WGLC). At least for past TCP option > codepoint allocations > >> I recall some discussions late in the IETF process. In those > past cases, good > >> arguments in an appendix and running code has helped a lot. > >>>> > >>>> [BB] I can do that. Appx B is already similar, giving Design > Rationale for the > >> ACE field. > >>>> > >>>> Bob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Michael > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> From: Bob Briscoe > > >>>> Sent: Tuesday, November 17, 2020 6:10 AM > >>>> To: Scharf, Michael >; Yoshifumi > >>>> Nishida > > >>>> Cc: Michael Tuexen >; tcpm-chairs@ietf.org > ; > >>>> Mirja Kuehlewind >; Scheffenegger, Richard > >>>> >; tcpm IETF list > > > >>>> Subject: Re: AccECN field order > >>>> > >>>> > >>>> > >>>> Michael, > >>>> > >>>> On 16/11/2020 17:36, Scharf, Michael wrote: > >>>> > >>>> Bob, > >>>> > >>>> > >>>> > >>>> One proposal using the length field with *one option > codepoint only* > >>>> is detailed in: > >>>> https://mailarchive.ietf.org/arch/msg/tcpm/zo- > >> 1OR0nRfhHocX8yvTvpC4BNMo > >>>> / > >>>> > >>>> > >>>> > >>>> It is the third option mentioned in this e-mail. One example > would be to > >> use option length values 5/8/11 for one encoding type and > option length > >> values 6/9/12 for the other encoding type (i.e., order of > fields). Or one could > >> use some other combination of length values – the only > requirement is that a > >> certain value for the option length is only used by one of the > option formats. > >> In that approach, the value of the length field would thus > directly describe > >> the encoding of the option. Unless I miss something, this would > work and it > >> would just require one option codepoint. > >>>> > >>>> > >>>> Thus, alternatives to two option codepoints exist and I have > explained > >> them on the list in March 2020. > >>>> > >>>> OK, sorry, yes, I remember this now. > >>>> > >>>> As I will explain in the AccECN status update talk today in > virtual Bangkok, > >> the draft has made provision for different length values than > 5/8/11. It says > >> existing implementations MUST accept length values other than those > >> currently defined. But then read in as many whole 3-byte fields > as they can. > >>>> This can be used to add a flags byte on the end in future, > for extensibility. > >> Or any other form of extensibility the WG might decide in the > future. > >>>> I know a flags byte at the end seems odd compared to at the > beginning. > >> But (if decided it's needed in future) it's reasonably easy to > implement by > >> reading the whole option, then processing the last byte, before > reading the > >> rest of the option. > >>>> I believe you will agree that this is a better way to utilize > different lengths. > >>>> > >>>> And thank you for repeatedly emphasizing that you're happy > with the 2- > >> kind scheme, or other alternatives. > >>>> > >>>> Bob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Anyway, I don’t really care how the options are encoded as > long as the > >> receiver doesn’t need per-connection state for decoding a TCP > option. So, > >> personally, I would be fine with using e.g. the length field as > described in my > >> old e-mail. Or an additional flag byte. And one could come up > with further > >> encodings, e.g., by using one or a few bits as a short “type” > field for each > >> counter. This is all about protocol engineering. And all these > variants have > >> their pros and cons. > >>>> > >>>> > >>>> I am also fine with using two option codepoints as specified > in -13; this is > >> probably the approach that consumes the least number of bits. > >>>> > >>>> > >>>> Michael (w/o any hat) > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> From: Bob Briscoe > > >>>> Sent: Monday, November 16, 2020 5:52 PM > >>>> To: Yoshifumi Nishida > > >>>> Cc: Scharf, Michael >; Michael Tuexen > >>>> >; > tcpm-chairs@ietf.org ; Mirja Kuehlewind > >>>> >; > Scheffenegger, Richard > >>>> >; tcpm IETF list > > > >>>> Subject: AccECN field order > >>>> > >>>> > >>>> > >>>> Yoshi, (adding the tcpm list in cc) > >>>> > >>>> On 05/11/2020 06:58, Yoshifumi Nishida wrote: > >>>> > >>>> Hi Bob, > >>>> > >>>> > >>>> > >>>> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe > > > >> wrote: > >>>> Yoshi, > >>>> > >>>> On 04/11/2020 06:51, Yoshifumi Nishida wrote: > >>>> > >>>> Hi, folks, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> In my understanding, I'm not sure if we settled down on using > two option > >> kinds or encoding schemes for 24bits fields in acc ecn draft. > >>>> So, I think there're still something to be clarified and hope > things will be > >> settled at the meeting. > >>>> > >>>> [BB] I know a WG can change it's mind at any time. But I'd > rather we just > >> clarified what a previous decision was, to avoid the need to > keep re-opening > >> discussion on a question that have been decided then changed three > >> different ways already. > >>>> My memory is not so good these days. I trusted that Michael S > >> remembered the decision correctly, and I seem to remember that > decision > >> being made. > >>>> I've just checked the minutes of the last interim: > >>>> > >>>> > https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 > >>>> 1600/ and they mention Michael's proposal to use two kinds, > but don't > >>>> record any decision. > >>>> The jabber log gives no clues about any decision. > >>>> > >>>> I can't find an audio or video recording. Can you point me at > one? > >>>> > >>>> > >>>> > >>>> I thought that it's because there was no clear decision at > the meeting. > >>>> > >>>> But, you can check https://www.youtube.com/watch?v=KsB0_Nb8-kA > >>>> > >>>> Please let us know if you have any questions or opinions with > regard to > >> this. > >>>> > >>>> [BB] I checked the Youtube link you sent below. > >>>> > >>>> First I think we're agreed no-one was fighting for us to keep > the previous > >> way we did this (using the initial value of the field to set > the order for the > >> connection). > >>>> In my presentation I said there was strong resistance from > Michael to do it > >> a different way. > >>>> (also, offlist, the co-authors including me also didn't like > this so > >>>> much. And Ilpo said it made the implementation complex.) > >>>> > >>>> Then came the question of what we do instead. There were three > >> alternative proposals: > >>>> a) use 2 option kinds > >>>> b) add a flags byte > >>>> c) somehow use the length field maybe > >>>> > >>>> Michael raised (c) in the meeting as a possibility, but > no-one could think > >> how to distinguish two options of the same length but a > different field order > >> using the length field. Michael said he'd post any ideas to the > list if he could > >> think of any, but that didn't happen. > >>>> So we're left choosing between (a) and (b). > >>>> I said in the meeting (and on the list when discussing with > Ilpo) that I'd be > >> happy to go with (b), but only if there was another use for a > flag. Because it > >> would consume 1B more options space in many packets, which is a > scarce > >> resource. > >>>> Ilpo had a proposed use for another flag (to help synch > counters after a > >> loss), but I think the discussion about it ended that it > wouldn't be helpful, 'cos > >> the way it worked depended on itself (circular logic). > >>>> In conclusion, I don't think there was an explicit decision > to go with 2 > >> option kinds, but it ended up as the 'last person standing'. > >>>> I like it. It's simple. And apparently option kinds are not > such a scarce > >> resource. > >>>> Perhaps we can ratify this in the WG tomorrow. > >>>> > >>>> > >>>> Bob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> -- > >>>> > >>>> Yoshi > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> __________________________________________________________ > >> ______ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> __________________________________________________________ > >> ______ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> __________________________________________________________ > >> ______ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >> -- > >> __________________________________________________________ > >> ______ > >> Bob Briscoe http://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------6069E2D629E3E8D77A6261B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yoshi,

On 12/02/2021 17:49, Yoshifumi Nishida wrote:

On Thu, Feb 11, 2021 at 1:33 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:


On 09/02/2021 17:56, Scharf, Michael wrote:
> Bob,
>
>> -----Original Message-----
>> From: Bob Briscoe <ietf@bobbriscoe.net>
>> Sent: Tuesday, February 9, 2021 5:58 PM
>> To: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>; Mirja
>> Kuehlewind <ietf@kuehlewind.net>; Scharf, Michael <Michael.Scharf@hs-
>> esslingen.de>
>> Cc: tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: AW: [tcpm] AccECN field order
>>
>> Richard,
>>
>> I just noticed I missed the last para of the old email from you below.
>> Response inline, tagged [BB]...
>>
>> On 23/11/2020 12:42, Scheffenegger, Richard wrote:
>>> I am also in favor of using two distinct option codes.
>>>
>>> However,
>>>
>>>> Or I guess we could say that only one option should be used for a
>> connection.
>>> I am opposed to this - with two option codes, a sender should be free to
>> choose whichever he prevers at any one point; For example, if the sender a
>> segment (e.g. may be the receiver side)  has to update the EE1 couter, but
>> also convey SACK information, it would be good to use the one, where the
>> EE1 field is first, and omit all remaining fields;
>>> Later in the same connection, that very same host may choose to update
>> the CE field together with some SACK information, and use the other
>> codepoint in order to preserve as much TCP option space for the SACK
>> option...
>>
>> [BB] I agree with you here (and disagree with Mirja below). The nice
>> thing about 2 options kinds is they are self-describing, so they can be
>> stateless (for instance, consider the code you would have to otherwise
>> add for when a host switches to a different congestion control module -
>> a lot of complexity despite being unlikely to happen).
>>
>>>
>>> As for extensibility: I would want to avoid that topic, and just specifiy the
>> three correct supported lengths here, and not mention (other than ignoring
>> "odd" fractionals of the 3-byte wide counters) what happens with other
>> lengths...
>>
>> [BB] A protocol spec should surely say what to do with unexpected
>> inputs. Not specifying this is one of the main reasons we have such
>> trouble changing things later - because we discover some implementers
>> handled the unexpected in different ways to others (e.g. ignore, vs RST
>> the connection), and others only handled expected inputs and didn't even
>> think to check for anything else.
>>
>> So, I believe we have to either say "reset the connection" or "ignore",
>> in response to an unexpected option length. I figure that, if there's no
>> harm in ignoring something unexpected, then why not ("liberal in what
>> you receive" principle).
>>
>> Earlier in this thread, Michael Scharf pointed out that there is some
>> potential harm here (covert channel of up to 29B), but I pointed out
>> that TCP/IP has plenty of other ways of creating covert channels, so
>> we're not really adding to any problem here. But I did say that we would
>> highlight the covert channel in the Security Considerations section, so
>> the Sec Area has a chance to object. If it raises as serious concern,
>> then we should switch from "ignore" to "reset", But I doubt it will.
> I think we first have to come to the conclusion *inside* TCPM whether such a new covert channel is actually acceptable.
>
> Existing covert channels do not at all imply that a new covert channel is a good idea (and, IMHO, 29B per packet is a lot). Network administrators and operators know how to deal with the existing problems in TCP/IP. Adding any new security issue needs careful reasoning.
>   
> As individual contributor to TCPM, I believe that this covert channel must just be removed from the next version of the draft. At least I don't need other opinions to come to this personal conclusion.
>
> If this was less obvious others in the WG, TCPM could ask for an early SECDIR review to get further guidance ASAP. Then this question can be sorted out while we finish the protocol.
>
> If TCPM needs any external input on covert channels, I think an early SECDIR review would be a much better approach compared to having a security discussion during IETF last call. We are here discussing a standards track extension of one of the core Internet protocols. In such a case, at least in my view on IETF processes, other IETF areas can expect that TCPM ties to deal with known open issues within the WG as far as possible, i.e., before they see a "stable" specification in the IETF last call.
>
> In a nutshell:
>
> -1 on leaving this question open until IETF last call

[BB] That's a perfectly reasonable process proposal.

I just wanted to add that there are not just 2 choices: the WG (with
advice from SEC area if necessary) is free to limit the bandwidth of
this covert channel anywhere between 0 and 29B per packet by simply
limiting how much extensibility the protocol allows the option length
field to offer, with a 0B covert channel corresponding to no extensibility.

OK. Michael.S abstains from the decision for SECDIR review, but other co-chairs think this is an important point to be checked.
So, if there's no specific opposition, we would like to ask for SECDIR review before WGLC. 

Do authors want to update the draft beforehand to add some more clarifications or are there any other thoughts on this?

[BB] The current draft could probably go to SECDIR review as it is. However, I have a few edits already done in my local copy, and a todo list of a few more, which I could try to get done in the next few days. Then I'll post a rev. So I guess it might as well wait a few days for those updates.

Agree?

Bob


Thanks,
--
Yoshi


 
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Mirja Kuehlewind <ietf@kuehlewind.net>
>>> Gesendet: Montag, 23. November 2020 12:39
>>> An: Neal Cardwell <ncardwell@google.com>; Scharf, Michael
>> <Michael.Scharf@hs-esslingen.de>; Bob Briscoe <ietf@bobbriscoe.net>
>>> Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm IETF list
>> <tcpm@ietf.org>; Scheffenegger, Richard
>> <Richard.Scheffenegger@netapp.com>; Michael Tuexen <tuexen@fh-
>> muenster.de>; tcpm-chairs@ietf.org
>>> Betreff: Re: [tcpm] AccECN field order
>>>
>>> NetApp Security WARNING: This is an external email. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>>>
>>>
>>>
>>> Hi all,
>>>
>>> I think I also support two options as this is the most simple solution.
>>>
>>> We probably need to look at section 3.2.3.2. (Path Traversal of the AccECN
>> Option) again, as I think this section assumes mostly one option. Or I guess
>> we could say that only one option should be used for a connection.
>>> Regarding use of the option length for extensibility. I know new options are
>> hard to deploy but that’s the extensibility mechanism we have with TCP. Not
>> sure we want to invent a new now. If we think we need more extensibility
>> for AccECN for any reason, we should specify valid option length values that
>> include a flags field now.
>>> Mirja
>>>
>>>
>>>
>>>> On 18. Nov 2020, at 01:03, Neal Cardwell <ncardwell@google.com> wrote:
>>>>
>>>> As someone who contributes to a TCP implementation, I would put in a
>> vote for the "Two Option Kinds" proposal outlined in slide 6 here:
>>>>
>>>> https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor
>>>> e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica
>>>> tion-01#page=6
>>>>
>>>> This approach has the virtue of simplicity, which hopefully may help avoid
>> middlebox bugs, speed standardization and development, and ease the
>> process of maintaining fast and stable implementations.
>>>> neal
>>>>
>>>>
>>>> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael <Michael.Scharf@hs-
>> esslingen.de> wrote:
>>>> Inline some comments [ms].
>>>>
>>>>
>>>>
>>>> Given that I don’t ask for any text chances, I’ll not follow-up forever in this
>> discussion. I don’t own running code and a lot of encoding details mainly
>> affect an implementation.
>>>>
>>>>
>>>> IMHO the rest of the WG has to think about the option design more than
>>>> me. So, this is mostly about triggering a discussion…
>>>>
>>>>
>>>>
>>>> From: Bob Briscoe <ietf@bobbriscoe.net>
>>>> Sent: Tuesday, November 17, 2020 1:20 PM
>>>> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi
>>>> Nishida <nsd.ietf@gmail.com>
>>>> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
>>>> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, Richard
>>>> <Richard.Scheffenegger@netapp.com>; tcpm IETF list <tcpm@ietf.org>
>>>> Subject: Re: AccECN field order
>>>>
>>>>
>>>>
>>>> Michael,
>>>>
>>>> On 17/11/2020 08:10, Scharf, Michael wrote:
>>>>
>>>> Bob,
>>>>
>>>>
>>>>
>>>> I am fine with the two option kinds proposed in -13, but I don’t buy your
>> arguments why this encoding is better than others.
>>>>
>>>>
>>>> Most importantly, I don’t think that your “forward compatibility”
>> argument is a very compelling reason for two codepoints. All proposals I am
>> aware of have their pros and cons. And I am not aware of a really
>> comprehensive discussion. At least neither the e-mail below nor today’s
>> meeting discuss all tradeoffs I would investigate.
>>>>
>>>> [BB] You're right - the discussion below is useful and necessary.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> For instance, the benefit of the length encoding variant would be to
>> consume only one TCP option codepoint now. If we decided later to that a
>> flag byte is needed (say, at the end), a follow-up proposed standard could
>> specify another option format with that flag byte, using a second codepoint.
>>>>
>>>> [BB]
>>>> * The new codepoint would require years to deploy (including in proxies)
>> before it works e2e.
>>>>
>>>>
>>>> [ms] That may depend *a lot* on the environment. In environments
>> where ECN can get deployed today, say in datacenters, rolling out a new
>> kernel version may perhaps not be the biggest operational challenge. Also,
>> proxies may not be a significant problem in some of those cases. Deployment
>> roadmaps are very hard to predict.
>>>>
>>>> * Whereas the 'forward compatibility' approach tries to ensure that
>> AccECN implementations that are being built today will be ready to interwork
>> with a future extension.
>>>> * In contrast, if your hypothetical new AccECN codepoint did need to be
>> deployed later, it would need to include a fall-back to the current AccECN
>> option when one peer doesn't understand the new codepoint.
>>>>
>>>>
>>>> [ms] This is a reasonable point, albeit not a particularly strong one,
>>>> given that the option is not really required for basic
>>>> interoperability. Also, a hypothetical follow-up standard could
>>>> include a way to explicitly request the option…
>>>>
>>>>
>>>> * Fall-back would need to avoid a second round of handshake (given
>>>> this is for low latency), which would only work reliably with an
>>>> option on the SYN (because the 3rd ACK is unreliable)
>>>>
>>>>
>>>>
>>>> [ms] I can’t follow. If an endpoint is unhappy with getting AccECN option
>> “A” from a peer, I could send a “please send me the better AccECN option B”
>> after the 3-WHS. It could be an upgrade, not a fallback. Also, at this point we
>> don’t know what option B would be and in which context it would be
>> needed. Maybe other protocol features would require negotiation, too.
>> IMHO it is a solvable problem.
>>>>
>>>> * AccECN has so far avoided using any SYN option space, which is
>> important given that is the scarcest resource.
>>>>
>>>>
>>>> [ms] Yep, but as long as no proposal needs SYN options, this is nothing
>> that would make one solution better than another.
>>>> These days, extending TCP is like playing chess - we have to think multiple
>> moves ahead!
>>>>
>>>>
>>>> [ms] There is one fundamental difference between chess and TCP: In
>> chess you precisely know the current situation and can predict all potential
>> moves in advance (albeit there are a lot). However, we don’t know the
>> future evolution of TCP, ECN and the Internet as a whole, nor future
>> requirements. If we try to engineer a TCP extension for some potential
>> future, we may figure out later that reality is different from what we
>> designed for. As much as I appreciate your attempts to predict the future, it
>> would be a big surprise to me if you could correctly predict what TCP will be in
>> 10 years from now. So, instead of trying to write specifications that take into
>> account future requirements, which are in fact just unknown, it is more
>> important for me to write effective, efficient and secure specifications for
>> what is currently known for sure.
>>>>
>>>>
>>>> [ms] I *don’t* know for sure whether the current AccECN option will be
>> needed, but I see quite some evidence that support of the AccECN option(s)
>> is not a top priority these days. That is also something to think about when
>> designing the details.
>>>>
>>>>
>>>> I need to learn to articulate onto the list all my reasons for rejecting
>> certain parts of the design space. Sorry about that.
>>>> Yes, I admit, the current proposal is at the cost of burning two TCP option
>> codepoints. However, you said yourself when you proposed this approach,
>> that they are not (currently) a scarce resource. Certainly not as scarce as
>> option space. I just checked: roughly 15% of the option codepoint allocation
>> space has been used so far. So that's where I would suggest we compromise
>> first.
>>>> [ms] I made a similar calculation some years ago and came to a similar
>> conclusion. Investing two codepoints for AccECN is something we can
>> probably afford. But nonetheless we have to reason carefully why it is really
>> worth the effort.
>>>>
>>>>
>>>>
>>>> Regarding the resulting codepoint consumption (two option kinds) and
>> the addition of a flag byte, this approach would basically end up with the
>> same result as the current proposal in -13 plus some hypothetical future
>> addition leveraging the length field beyond the currently known use.
>>>>
>>>>
>>>> And, yes, the length encoding variant may be less flexible and/or
>> consume some more bits in some cases, but on the plus side it only needs
>> one codepoint now – and given that it is entirely unclear whether any
>> AccECN option will indeed be widely used in future, this is a big plus. The fact
>> that implementers are quite silent on the option design is not a good sign.
>>>>
>>>> [BB] Here's another possibility then.
>>>>
>>>> a) [K|L| EE1B | ECEB | EE0B ]
>>>> b) [K|L| EE1B | ECEB | EE0B |F]    if F = 0bXXXXXXX0
>>>> c) [K|L| EE0B | ECEB | EE1B |F]    if F = 0bXXXXXXX1
>>>>
>>>> We'd have to decide which order alternative (a) takes. I've picked EE1B
>> first only 'cos you're right that there is not currently as much pressure (on the
>> public Internet) for AccECN with ECT(0).
>>>> ==Legend==
>>>> K:    Kind (1B)
>>>> L:    Length (1B)
>>>> ExxB: Echo xx byte counter
>>>> F:    Flags (1B)
>>>>
>>>> Alternatives a) and b) are equivalent, at least while the only allocated flag
>> is for field order.
>>>> However, alternative b) is available in case other flags are allocated
>>>> in future The flags byte can only be omitted if (L % 3 == 2).
>>>> The flags byte is considered present if (L % 3) == 0.
>>>>
>>>> Forward compatibility: Options with (L % 3 == 1) MUST be assumed to
>> include a flags byte, and current implementations ignore the last byte.
>>>> The flags byte is optional to implement (even if the AccECN option is
>>>> implemented) If the server includes a flags byte on the SYN/ACK but the
>> client does not include one on the 3rd ACK or the first data packet, the server
>> assumes the client does not implement the flags byte and uses only
>> alternative a) for the remainder of the connection.
>>>>
>>>> [ms] I am not sure if we need that, but I take this as existence proof that
>> other encodings are possible. Personally, I think that other solutions would
>> be doable if you took one bit from one or multiple counters for format
>> encoding. At least for some of the byte counters I don’t think taking one bit
>> for other purposes would result in an Internet congestion collapse… But, I
>> have already said that the -13 proposal works for me, so I’ll not try to come
>> up with another variant myself.
>>>>
>>>>
>>>> To me, one potential difference between two proposals would be
>> incremental deployment. The proposal in -13 only has an advantage if
>> middleboxes such as firewalls will indeed pass TCP options with a format that
>> contains content beyond the (first) Accurate ECN standard (i.e., currently
>> unused length values). IMHO it is too early to know whether firewalls would
>> indeed allow this in future.
>>>>
>>>>
>>>>   From a security perspective, it is not clear to me whether allowing
>> arbitrary unspecified bytes in a TCP option is a good idea *at all*. It will be
>> interesting to hear the opinion from SEC area on that. Personally, I am not
>> convinced that this really makes sense, but I my concerns are not strong
>> enough to formally push back. I’ll leave it to others to think about whether
>> this is a bug or a feature.
>>>>
>>>> [BB] Well, let's first try to deal with security ourselves:
>>>> * Octets that are explicitly declared as part of an option cannot be used
>> for a buffer overflow attack. I don't really need to, but I could add the
>> following text to the forward compatibility wording:
>>>>       A receiver considers octets beyond those it uses, but within the
>> specified length, as if they are padding.
>>>> * And such octets cannot be any different from the current ability of a
>> sender to add padding. So there's no new attack possible here.
>>>> * And there's no need to specify a max length for any AccECN Option,
>> which would just unnecessarily limit flexibility.
>>>> [ms] I have more thought about the covert channel that some unspecified
>> bytes in a standards track TCP option could offer… In particular if the AccECN
>> option gets widely deployed and used, would some malicious users find
>> those bytes useful? For what? For instance, what in the AccECN protocol
>> design prevents use of these “padding” bytes as super-cookie? To me, it is
>> much more important to think about abuse of whatever we standardize
>> *now*, instead of engineering for some entirely unknown future. I am not a
>> security expert, but I suggest a careful analysis of any security implications of
>> the AccECN option. We seldomly specify new TCP options and malicious
>> users will certainly look for “opportunities” in the spec. So far, I don’t know
>> whether that whole idea of forward compatibility is a feature or a bug.
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> Maybe one lesson learnt is that the document could have a non-
>> normative appendix that explains the rationale for the finally picked TCP
>> option encoding. That may also help if there are further questions whether
>> two codepoints are really required, e.g. by the IESG (if two codepoints are
>> still the design after WGLC). At least for past TCP option codepoint allocations
>> I recall some discussions late in the IETF process. In those past cases, good
>> arguments in an appendix and running code has helped a lot.
>>>>
>>>> [BB] I can do that. Appx B is already similar, giving Design Rationale for the
>> ACE field.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Bob Briscoe <ietf@bobbriscoe.net>
>>>> Sent: Tuesday, November 17, 2020 6:10 AM
>>>> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi
>>>> Nishida <nsd.ietf@gmail.com>
>>>> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
>>>> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, Richard
>>>> <Richard.Scheffenegger@netapp.com>; tcpm IETF list <tcpm@ietf.org>
>>>> Subject: Re: AccECN field order
>>>>
>>>>
>>>>
>>>> Michael,
>>>>
>>>> On 16/11/2020 17:36, Scharf, Michael wrote:
>>>>
>>>> Bob,
>>>>
>>>>
>>>>
>>>> One proposal using the length field with *one option codepoint only*
>>>> is detailed in:
>>>> https://mailarchive.ietf.org/arch/msg/tcpm/zo-
>> 1OR0nRfhHocX8yvTvpC4BNMo
>>>> /
>>>>
>>>>
>>>>
>>>> It is the third option mentioned in this e-mail. One example would be to
>> use option length values 5/8/11 for one encoding type and option length
>> values 6/9/12 for the other encoding type (i.e., order of fields). Or one could
>> use some other combination of length values – the only requirement is that a
>> certain value for the option length is only used by one of the option formats.
>> In that approach, the value of the length field would thus directly describe
>> the encoding of the option. Unless I miss something, this would work and it
>> would just require one option codepoint.
>>>>
>>>>
>>>> Thus, alternatives to two option codepoints exist and I have explained
>> them on the list in March 2020.
>>>>
>>>> OK, sorry, yes, I remember this now.
>>>>
>>>> As I will explain in the AccECN status update talk today in virtual Bangkok,
>> the draft has made provision for different length values than 5/8/11. It says
>> existing implementations MUST accept length values other than those
>> currently defined. But then read in as many whole 3-byte fields as they can.
>>>> This can be used to add a flags byte on the end in future, for extensibility.
>> Or any other form of extensibility the WG might decide in the future.
>>>> I know a flags byte at the end seems odd compared to at the beginning.
>> But (if decided it's needed in future) it's reasonably easy to implement by
>> reading the whole option, then processing the last byte, before reading the
>> rest of the option.
>>>> I believe you will agree that this is a better way to utilize different lengths.
>>>>
>>>> And thank you for repeatedly emphasizing that you're happy with the 2-
>> kind scheme, or other alternatives.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Anyway, I don’t really care how the options are encoded as long as the
>> receiver doesn’t need per-connection state for decoding a TCP option. So,
>> personally, I would be fine with using e.g. the length field as described in my
>> old e-mail. Or an additional flag byte. And one could come up with further
>> encodings, e.g., by using one or a few bits as a short “type” field for each
>> counter. This is all about protocol engineering. And all these variants have
>> their pros and cons.
>>>>
>>>>
>>>> I am also fine with using two option codepoints as specified in -13; this is
>> probably the approach that consumes the least number of bits.
>>>>
>>>>
>>>> Michael (w/o any hat)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Bob Briscoe <ietf@bobbriscoe.net>
>>>> Sent: Monday, November 16, 2020 5:52 PM
>>>> To: Yoshifumi Nishida <nsd.ietf@gmail.com>
>>>> Cc: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Michael Tuexen
>>>> <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org; Mirja Kuehlewind
>>>> <ietf@kuehlewind.net>; Scheffenegger, Richard
>>>> <Richard.Scheffenegger@netapp.com>; tcpm IETF list <tcpm@ietf.org>
>>>> Subject: AccECN field order
>>>>
>>>>
>>>>
>>>> Yoshi, (adding the tcpm list in cc)
>>>>
>>>> On 05/11/2020 06:58, Yoshifumi Nishida wrote:
>>>>
>>>> Hi Bob,
>>>>
>>>>
>>>>
>>>> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe <ietf@bobbriscoe.net>
>> wrote:
>>>> Yoshi,
>>>>
>>>> On 04/11/2020 06:51, Yoshifumi Nishida wrote:
>>>>
>>>> Hi, folks,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In my understanding, I'm not sure if we settled down on using two option
>> kinds or encoding schemes for 24bits fields in acc ecn draft.
>>>> So, I think there're still something to be clarified and hope things will be
>> settled at the meeting.
>>>>
>>>> [BB] I know a WG can change it's mind at any time. But I'd rather we just
>> clarified what a previous decision was, to avoid the need to keep re-opening
>> discussion on a question that have been decided then changed three
>> different ways already.
>>>> My memory is not so good these days. I trusted that Michael S
>> remembered the decision correctly, and I seem to remember that decision
>> being made.
>>>> I've just checked the minutes of the last interim:
>>>>
>>>> https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429
>>>> 1600/ and they mention Michael's proposal to use two kinds, but don't
>>>> record any decision.
>>>> The jabber log gives no clues about any decision.
>>>>
>>>> I can't find an audio or video recording. Can you point me at one?
>>>>
>>>>
>>>>
>>>> I thought that it's because there was no clear decision at the meeting.
>>>>
>>>> But, you can check https://www.youtube.com/watch?v=KsB0_Nb8-kA
>>>>
>>>> Please let us know if you have any questions or opinions with regard to
>> this.
>>>>
>>>> [BB] I checked the Youtube link you sent below.
>>>>
>>>> First I think we're agreed no-one was fighting for us to keep the previous
>> way we did this (using the initial value of the field to set the order for the
>> connection).
>>>> In my presentation I said there was strong resistance from Michael to do it
>> a different way.
>>>> (also, offlist, the co-authors including me also didn't like this so
>>>> much. And Ilpo said it made the implementation complex.)
>>>>
>>>> Then came the question of what we do instead. There were three
>> alternative proposals:
>>>> a) use 2 option kinds
>>>> b) add a flags byte
>>>> c) somehow use the length field maybe
>>>>
>>>> Michael raised (c) in the meeting as a possibility, but no-one could think
>> how to distinguish two options of the same length but a different field order
>> using the length field. Michael said he'd post any ideas to the list if he could
>> think of any, but that didn't happen.
>>>> So we're left choosing between (a) and (b).
>>>> I said in the meeting (and on the list when discussing with Ilpo) that I'd be
>> happy to go with (b), but only if there was another use for a flag. Because it
>> would consume 1B more options space in many packets, which is a scarce
>> resource.
>>>> Ilpo had a proposed use for another flag (to help synch counters after a
>> loss), but I think the discussion about it ended that it wouldn't be helpful, 'cos
>> the way it worked depended on itself (circular logic).
>>>> In conclusion, I don't think there was an explicit decision to go with 2
>> option kinds, but it ended up as the 'last person standing'.
>>>> I like it. It's simple. And apparently option kinds are not such a scarce
>> resource.
>>>> Perhaps we can ratify this in the WG tomorrow.
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>>
>>>> Yoshi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>> __________________________________________________________
>> ______
>>>> Bob Briscoe                               http://bobbriscoe.net/
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>> __________________________________________________________
>> ______
>>>> Bob Briscoe                               http://bobbriscoe.net/
>>>>
>>>>
>>>>
>>>> --
>>>>
>> __________________________________________________________
>> ______
>>>> Bob Briscoe                               http://bobbriscoe.net/
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>> --
>> __________________________________________________________
>> ______
>> Bob Briscoe                               http://bobbriscoe.net/

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

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------6069E2D629E3E8D77A6261B3-- From nobody Fri Feb 12 16:33:49 2021 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 3949B3A1154; Fri, 12 Feb 2021 16:33:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: martin.h.duke@gmail.com, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317639817.31337.1240736425724634576@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:18 -0800 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 110 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: Sat, 13 Feb 2021 00:33:19 -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) Friday, 12 March 2021, Session I 1300-1500 Room Name: Room 8 size: 508 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/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: Martin Duke Michael Scharf Michael Tuexen Yoshifumi Nishida Resources Requested: Special Requests: Please avoid Tuesday (March 9) --------------------------------------------------------- From nobody Fri Feb 12 20:45:08 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF213A0D4A for ; Fri, 12 Feb 2021 20:45:06 -0800 (PST) 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, 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=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 xPGTltC2KUNG for ; Fri, 12 Feb 2021 20:45:04 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37D03A0D48 for ; Fri, 12 Feb 2021 20:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LkGT/LOKs1q28F82018CjPpRQaC/E0OweRYPMfMKnWM=; b=AazxhrXBl5gzc3VbaYG35exnW CMISMIcGzMm0XwtDm9QQm8LTRYRtNXkM23HeBbDK52JskS7RbWIFX/zAVsExpFJoTXKp6G1cXuqfb RDe0PlZn4rEh7YQ6NS49684WZeKUN3532x4TmjMs14SuXQAU02tisSSQJ35IOCBegqGFrJWEUzP/J NsFJB4UWyuwSjc5ltokJcZwtFt7fvuuZ/g5k1WbQ4avmjpojF/A3kCVkB61dorjbvZcs/33I0eToH UdfWQpSxZ2OXkCpjUm2fhxXOgDQIslANM5OkZ+s9+eO8Ex4Nm6cleN1PMSc59hSwGJ+MF9Ag+TEta ulPtGIwyQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64041 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 1lAmnf-000z4y-1g; Fri, 12 Feb 2021 23:45:00 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_72F1FAC9-4960-49FE-B38E-0A24B95FFBA3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Fri, 12 Feb 2021 20:44:54 -0800 Cc: "tcpm@ietf.org Extensions" , Liangqiandeng Message-Id: <13954E42-57C2-468E-BE12-517659A6CEF9@strayalpha.com> References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.60.0.2.21) 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-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 04:45:06 -0000 --Apple-Mail=_72F1FAC9-4960-49FE-B38E-0A24B95FFBA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 12, 2021, at 9:52 AM, Yoshifumi Nishida = wrote: >=20 > OK. So, in my understanding, what you're suggesting are the = followings. >=20 > - Aggregated options would be useful. but, the format can be simple 4 = bytes length option that can accomodate 16 options. Yes, > - The tricks to avoid reflecting options in SYN ACK will not be needed = because it's the receiver's responsibility. Yes. > - Delayed negotiation might be possible. But, no generic framework is = needed. Each option should be designed for its own way to support it. Yes. > But, once thing I am wondering is that we can still combine Aggregated = options and delayed negotiation even with this one. Delayed negotiation is a completely separate and very complicated issue. = It=E2=80=99s not as simple as =E2=80=9Cdo it later=E2=80=9D; in the = TWHS, the sequence of messages is defined. Elsewhere, messages can come = out of order - at which point the meaning of options with respect to = that order has to be defined. That=E2=80=99s a can of worms and = completely independent of whether aggregated options are supported. > if you are meaning options not appeared in SYN cannot be used in the = following segments, I think accecn option might be a precedent for this. = =20 Accecn may not appear in an option explicitly, but it is communicated = using SYN flags. That=E2=80=99s very close to what the compressed = options achieves. I.e., the option value itself need not appear in the SYN, but the use of = that option *is* signaled using the SYN/SYN-ACK, either way. Again, doing that negotiaton after the TWHS is a separate and more = complex issue that I believe should be defined for each option (even if = you want to define it for a separate post-SYN aggregate option); it = can=E2=80=99t be generalized for existing options. Joe --Apple-Mail=_72F1FAC9-4960-49FE-B38E-0A24B95FFBA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 12, 2021, at 9:52 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> = wrote:

OK. So, in my understanding, what = you're suggesting are the followings.

- = Aggregated options would be useful. but, the format can be simple 4 = bytes length option that can accomodate 16 = options.

Yes,

- The tricks to avoid reflecting = options in SYN ACK will not be needed because it's the receiver's = responsibility.

Yes.

- Delayed negotiation might be = possible. But, no generic framework is needed. Each option should be = designed for its own way to support it.

Yes.

But, once thing I am wondering is = that we can still combine Aggregated options and delayed negotiation = even with this one.

Delayed negotiation is a completely separate and = very complicated issue. It=E2=80=99s not as simple as =E2=80=9Cdo it = later=E2=80=9D; in the TWHS, the sequence of messages is defined. = Elsewhere, messages can come out of order - at which point the meaning = of options with respect to that order has to be defined. That=E2=80=99s = a can of worms and completely independent of whether aggregated options = are supported.

if you are meaning options not = appeared in SYN cannot be used in the following segments, I think accecn = option might be a precedent for = this.  

Accecn= may not appear in an option explicitly, but it is communicated using = SYN flags. That=E2=80=99s very close to what the compressed options = achieves.

I.e., the option value = itself need not appear in the SYN, but the use of that option *is* = signaled using the SYN/SYN-ACK, either way.

Again, doing that negotiaton after the TWHS is a = separate and more complex issue that I believe should be defined for = each option (even if you want to define it for a separate post-SYN = aggregate option); it can=E2=80=99t be generalized for existing = options.

Joe

= --Apple-Mail=_72F1FAC9-4960-49FE-B38E-0A24B95FFBA3-- From nobody Sat Feb 13 07:12:51 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285E43A0B44 for ; Sat, 13 Feb 2021 07:12:50 -0800 (PST) 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 4TBaycBP9nOG for ; Sat, 13 Feb 2021 07:12:48 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 640F53A0B20 for ; Sat, 13 Feb 2021 07:12:48 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id a11so1178015vsm.7 for ; Sat, 13 Feb 2021 07:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mr/qjiYuLZLCjq/PlswHrICThn/yVf+N7kYLPca1frY=; b=vG/9s/C1XZwR0mIqbhLwUkTbb/fjq0JpA6AAAbo0Tpes74tE2Gv1Qv/f/KU+nbWkNo ov3jeS71afqaLBIk6DCe3B2wT5brvuv6ZLA8NmGjNOlqQOUnbdnjD6QQC0DSSxeEmtwu CXyYNTjPqHSCEyDMfl984i+GJvJT/lvkWlDkeH5Rp7ddelXpFh515bBYd29mk/Wjq1ba USNpnY6U6qjbD0aOV7N/UjVZ9a4EpU3DyMPVnUMkQ6SGq82hDOPVHaKBM0hG2D+LHdAm ZEAZUxr/b+QZ0AIs7C5Tq3J6N8XIYdetsbrRgRjQtKT7Qbm9gymVrYdGbYOuHnDZxWKz DAEw== 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=mr/qjiYuLZLCjq/PlswHrICThn/yVf+N7kYLPca1frY=; b=Yl6SHS79SpRTAEarimBon9yfK+3OQdPvd1Q71whYw9mW32/gKs6ngmXEijg4Tc3O0p LdYgo1TLquoz3VhWD+VAE+91f8DyUbv4jzn+pCuyHmAAmNRLPEof5MtTz9BFPzMgHt+0 3JkGjVkfhIJFcdNONjuX0Hcqbrll47cqdv0jrRP9cx18OcDHPc25GkEBaWmf//W7Ojy4 BESuEeQT31VlPOxN7/gfnhux/3Ve5Kv8iwY5R9zlOA+ZquJwUgfS1oByPu7SyR7g/eFB X7jn1PTvpTi8APeRvycTfwePdb+hhE/7vrSD9MUMXqg0t9K00BbDxUI6ejbOIOBoM0Uo 9X0g== X-Gm-Message-State: AOAM53156mpPb1oSmdrDz6DaJdIuWYLTvIXuxbjkwvHwPwAXVDrcaT1L hmGiR9bXCffkU7D/3+UiXBnuMoVHLLEJYqCfrnO8vw== X-Google-Smtp-Source: ABdhPJw6Qe35HtVLokPXZMWdH2w8EtektLZ6X8McxBUeLK7p4E9k7cd5dNj1P9wTcUw4yV2lg/VlxgRbe2N0sydx3Sg= X-Received: by 2002:a05:6102:833:: with SMTP id k19mr4734212vsb.16.1613229165403; Sat, 13 Feb 2021 07:12:45 -0800 (PST) MIME-Version: 1.0 References: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> In-Reply-To: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> From: Neal Cardwell Date: Sat, 13 Feb 2021 10:12:28 -0500 Message-ID: To: Michael Tuexen Cc: Yuchung Cheng , tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000592ba505bb392f92" Archived-At: Subject: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 13 Feb 2021 15:12:50 -0000 --000000000000592ba505bb392f92 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 12, 2021 at 10:19 AM Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > > On 11. Feb 2021, at 06:22, Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > > > > The wording in the Congestion Control section looks great to me. > > > > > Minor: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4 > > > > I agree with Yuchung that it would be nice to clarify what is meant by > "idle" connections (in the pre-existing text), with respect to keep-alives. > It seems at least the historical behavior for two of the major > implementations out there interpret this in different ways, and this has > caused some confusion in the developer community about what semantics to > expect from TCP keep-alives. I guess the rfc793bis-20 draft does have some > nice new text (that does not seem to be in RFC793 or RFC1122) that seems to > shed some light on this: > > > > Keep-alive packets MUST only be sent when no sent data is > > outstanding, and no data or acknowledgement packets have been > > received for the connection within an interval (MUST-26). > > > > > > That sentence helps quite a bit. It seems to correspond to the last 20 > years of Linux TCP keep-alive behavior, but not the BSD behavior (at least > BSD TCP as documented in Stevens volume 2; I have not checked more recent > BSD kernels). > Can elaborate what Linux behaviour you are referring to an what BSD > behaviour you are referring to? BSD: My reading of the behavior in older BSD releases (BSD-4_2 [1983] through BSD-4_4_Lite2 [1995], or Stevens volume 2 [1995]) is that a TCP endpoint resets the keep-alive timer (tp->t_timer[TCPT_KEEP]) to its full keep-alive interval upon receiving a packet, and then when the timer fires it sends a keep-alive probe packet (case TCPT_KEEP in tcp_timers() in tcp_timer.c). When that keep-alive timer fires it seems to send a keep-alive packet irrespective of whether the TCP endpoint currently has data outstanding in the network, or is sending ZWP packets. Linux: Starting in Linux 2.3.41 in Jan 2000, and continuing through current releases, the Linux TCP keep-alive timer code in tcp_keepalive_timer() has two simple extra checks introduced: https://elixir.bootlin.com/linux/2.3.41/source/net/ipv4/tcp_timer.c#L729 The checks basically say that if the keep-alive timer goes off but the TCP endpoint has data outstanding in the network (RTO timer is set), or outgoing data queued and waiting for a non-zero receive window (ZWP timer is set), then the code merely resets the keep-alive timer, and short-circuits all the keep-alive processing that would send a keep-alive probe packet or check to see if the connection should be torn down. This behavior is similar to the rfc793bis-20 text, "Keep-alive packets MUST only be sent when no sent data is outstanding", except that it also skips sending a keep-alive when the sender is in the process of sending repeated zero window probes (which would also serve to tell whether the remote endpoint is reachable). best, neal --000000000000592ba505bb392f92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 12, 2021 at 10:19 AM Michael = Tuexen <Michael.Tuex= en@lurchi.franken.de> wrote:
> On 11. Feb 2021, at 06:= 22, Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
>
> The wording in the Congestion Control section looks great to me.
>
> > Minor:=C2=A0 https:/= /tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
>
> I agree with Yuchung that it would be nice to clarify what is meant by= "idle" connections (in the pre-existing text), with respect to k= eep-alives. It seems at least the historical behavior for two of the major = implementations out there interpret this in different ways, and this has ca= used some confusion in the developer community about what semantics to expe= ct from TCP keep-alives. I guess the rfc793bis-20 draft does have some nice= new text (that does not seem to be in RFC793 or RFC1122) that seems to she= d some light on this:
>
>=C2=A0 =C2=A0 Keep-alive packets MUST only be sent when no sent data is=
>=C2=A0 =C2=A0 outstanding, and no data or acknowledgement packets have = been
>=C2=A0 =C2=A0 received for the connection within an interval (MUST-26).=
>
>
> That sentence helps quite a bit. It seems to correspond to the last 20= years of Linux TCP keep-alive behavior, but not the BSD behavior (at least= BSD TCP as documented in Stevens volume 2; I have not checked more recent = BSD kernels).
Can elaborate what Linux behaviour you are referring to an what BSD behavio= ur you are referring to?

BSD: My reading of= the behavior in older BSD releases (BSD-4_2 [1983] through=C2=A0BSD-4_4_Li= te2 [1995], or Stevens volume 2 [1995]) is that a TCP endpoint resets the k= eep-alive timer (tp->t_timer[TCPT_KEEP]) to its full keep-alive interval= upon receiving a packet, and then when the timer fires it sends a keep-ali= ve probe packet (case TCPT_KEEP in=C2=A0tcp_timers() in tcp_timer.c). When = that keep-alive timer fires it seems to send a keep-alive packet irrespecti= ve of whether the TCP endpoint currently has data outstanding in the networ= k, or is sending ZWP packets.

Linux: Starting in L= inux 2.3.41 in Jan 2000, and continuing through current releases, the Linux= TCP keep-alive timer code in tcp_keepalive_timer() has two simple extra ch= ecks introduced:
The checks basi= cally say that if the keep-alive timer goes off but the TCP endpoint has da= ta outstanding in the network (RTO timer is set), or outgoing data queued a= nd waiting for a non-zero receive window (ZWP timer is set), then the code = merely resets the keep-alive timer, and short-circuits all the keep-alive p= rocessing that would send a keep-alive probe packet or check to see if the = connection should be torn down. This behavior is similar to the=C2=A0rfc793= bis-20 text,=C2=A0 "Keep-alive packets MUST only be sent when no sent = data is=C2=A0 outstanding", except that it also skips sending a keep-a= live when the sender is in the process of sending repeated zero window prob= es (which would also serve to tell whether the remote endpoint is reachable= ).

best,
neal

<= br>




<= br>


=C2=A0
--000000000000592ba505bb392f92-- From nobody Sun Feb 14 22:28:05 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CAD3A0BFC for ; Sun, 14 Feb 2021 22:28:03 -0800 (PST) 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 lI5gf_B7idp8 for ; Sun, 14 Feb 2021 22:28:00 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 B0E953A0BFA for ; Sun, 14 Feb 2021 22:28:00 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id t62so5531591qke.7 for ; Sun, 14 Feb 2021 22:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WQdHRCEHEWpjqSj9QOAygbg0Gk75IkPAXSaY0byzUHg=; b=Sbmr3Z1QRXPtqWCzo0FKT4sHGxKM6rAkw0MZUrcmftvzIQWcl1+47+csjyjmsf4FzF 6VWcZpkRzEd0D8KulFOj5KLW7ImjwngweTQ4ovBA8NU09Z/uVlnIaN6MbqJXAiSv1sLe TnhqUCBfTGPJeAmWXlclAPMWa7mnNORwkZ3bmgQR7LBfM9MEAolIuiS9SxWYuL+M2kqj 2hrBfmP70aLg9xk7jSV41qU/ZQimJdqGqOAEooZ3TsWe9BB87dGy7uUPRolIkwS6M8cn gZz2wEsYsIPsFH8OuhpBaNUcd/5Rjqy/HEVkFC/DwpguQG2NbvAnjGLP8YzyDSygM1IS /dKg== 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=WQdHRCEHEWpjqSj9QOAygbg0Gk75IkPAXSaY0byzUHg=; b=njSthNV+3m2uBSVDrZ1Frm3zKqL+Fsk1TaW10wVss1kl588xsdVpjRlW1YWAPR2lXq 4YQJU+v1cHEhxKtEWfXbk/PejVlhBWDXbTDqrGfoJvEV2zy/qZTbvCMmcO1sBMijLf+U kdy7lfv97WGoSPunm8bAJfrYEUUTIX04EFR2udSLV52JlWXXWaM6lz9Gq0d69KySi2n6 qvC/JgArpAJjnt8xT1WP7rnO7WMlCcdrwd0EegVgblxuxGRktNA1y7TFpxBTX6IiF5Zd h7Cqo6PFHEM29zNVsH+Op+iXp33YY7xpmA3v41M8wQD2gr3PfeQtyPQQ2d7pP9eWf+ID YkXA== X-Gm-Message-State: AOAM531k0+N5gotDvnf4nF+mW7C7NCstcQ/NOoctptWP7JLKHEZggca0 SwKRX29mve4yzhIVeimiE2vucOPDLe8SkOQ7bTg= X-Google-Smtp-Source: ABdhPJwNcW3PuwinTsloIh0a++nHXCPtbbbKeSh5oeE4f+7U6hKl02oZZNfs0Q/eflwMDw25If+JshJXewRij28+s5I= X-Received: by 2002:a37:542:: with SMTP id 63mr13841970qkf.8.1613370479716; Sun, 14 Feb 2021 22:27:59 -0800 (PST) MIME-Version: 1.0 References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <381499f5-3333-08c5-2ffd-fba77e027795@bobbriscoe.net> <1e61a7d3-b6be-d995-4fc2-777bc2d5d5fe@bobbriscoe.net> <298c8924-c751-8f08-0caa-6d5eeaf293ac@bobbriscoe.net> In-Reply-To: <298c8924-c751-8f08-0caa-6d5eeaf293ac@bobbriscoe.net> From: Yoshifumi Nishida Date: Sun, 14 Feb 2021 22:27:48 -0800 Message-ID: To: Bob Briscoe Cc: "Scharf, Michael" , "Scheffenegger, Richard" , Mirja Kuehlewind , tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000055abff05bb5a169c" Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 15 Feb 2021 06:28:03 -0000 --00000000000055abff05bb5a169c Content-Type: text/plain; charset="UTF-8" On Fri, Feb 12, 2021 at 3:05 PM Bob Briscoe wrote: > Yoshi, > > On 12/02/2021 17:49, Yoshifumi Nishida wrote: > > > On Thu, Feb 11, 2021 at 1:33 PM Bob Briscoe wrote: > >> >> >> On 09/02/2021 17:56, Scharf, Michael wrote: >> > Bob, >> > >> >> -----Original Message----- >> >> From: Bob Briscoe >> >> Sent: Tuesday, February 9, 2021 5:58 PM >> >> To: Scheffenegger, Richard ; Mirja >> >> Kuehlewind ; Scharf, Michael > >> esslingen.de> >> >> Cc: tcpm IETF list >> >> Subject: Re: AW: [tcpm] AccECN field order >> >> >> >> Richard, >> >> >> >> I just noticed I missed the last para of the old email from you below. >> >> Response inline, tagged [BB]... >> >> >> >> On 23/11/2020 12:42, Scheffenegger, Richard wrote: >> >>> I am also in favor of using two distinct option codes. >> >>> >> >>> However, >> >>> >> >>>> Or I guess we could say that only one option should be used for a >> >> connection. >> >>> I am opposed to this - with two option codes, a sender should be free >> to >> >> choose whichever he prevers at any one point; For example, if the >> sender a >> >> segment (e.g. may be the receiver side) has to update the EE1 couter, >> but >> >> also convey SACK information, it would be good to use the one, where >> the >> >> EE1 field is first, and omit all remaining fields; >> >>> Later in the same connection, that very same host may choose to update >> >> the CE field together with some SACK information, and use the other >> >> codepoint in order to preserve as much TCP option space for the SACK >> >> option... >> >> >> >> [BB] I agree with you here (and disagree with Mirja below). The nice >> >> thing about 2 options kinds is they are self-describing, so they can be >> >> stateless (for instance, consider the code you would have to otherwise >> >> add for when a host switches to a different congestion control module - >> >> a lot of complexity despite being unlikely to happen). >> >> >> >>> >> >>> As for extensibility: I would want to avoid that topic, and just >> specifiy the >> >> three correct supported lengths here, and not mention (other than >> ignoring >> >> "odd" fractionals of the 3-byte wide counters) what happens with other >> >> lengths... >> >> >> >> [BB] A protocol spec should surely say what to do with unexpected >> >> inputs. Not specifying this is one of the main reasons we have such >> >> trouble changing things later - because we discover some implementers >> >> handled the unexpected in different ways to others (e.g. ignore, vs RST >> >> the connection), and others only handled expected inputs and didn't >> even >> >> think to check for anything else. >> >> >> >> So, I believe we have to either say "reset the connection" or "ignore", >> >> in response to an unexpected option length. I figure that, if there's >> no >> >> harm in ignoring something unexpected, then why not ("liberal in what >> >> you receive" principle). >> >> >> >> Earlier in this thread, Michael Scharf pointed out that there is some >> >> potential harm here (covert channel of up to 29B), but I pointed out >> >> that TCP/IP has plenty of other ways of creating covert channels, so >> >> we're not really adding to any problem here. But I did say that we >> would >> >> highlight the covert channel in the Security Considerations section, so >> >> the Sec Area has a chance to object. If it raises as serious concern, >> >> then we should switch from "ignore" to "reset", But I doubt it will. >> > I think we first have to come to the conclusion *inside* TCPM whether >> such a new covert channel is actually acceptable. >> > >> > Existing covert channels do not at all imply that a new covert channel >> is a good idea (and, IMHO, 29B per packet is a lot). Network administrators >> and operators know how to deal with the existing problems in TCP/IP. Adding >> any new security issue needs careful reasoning. >> > >> > As individual contributor to TCPM, I believe that this covert channel >> must just be removed from the next version of the draft. At least I don't >> need other opinions to come to this personal conclusion. >> > >> > If this was less obvious others in the WG, TCPM could ask for an early >> SECDIR review to get further guidance ASAP. Then this question can be >> sorted out while we finish the protocol. >> > >> > If TCPM needs any external input on covert channels, I think an early >> SECDIR review would be a much better approach compared to having a security >> discussion during IETF last call. We are here discussing a standards track >> extension of one of the core Internet protocols. In such a case, at least >> in my view on IETF processes, other IETF areas can expect that TCPM ties to >> deal with known open issues within the WG as far as possible, i.e., before >> they see a "stable" specification in the IETF last call. >> > >> > In a nutshell: >> > >> > -1 on leaving this question open until IETF last call >> >> [BB] That's a perfectly reasonable process proposal. >> >> I just wanted to add that there are not just 2 choices: the WG (with >> advice from SEC area if necessary) is free to limit the bandwidth of >> this covert channel anywhere between 0 and 29B per packet by simply >> limiting how much extensibility the protocol allows the option length >> field to offer, with a 0B covert channel corresponding to no >> extensibility. >> > > OK. Michael.S abstains from the decision for SECDIR review, but other > co-chairs think this is an important point to be checked. > So, if there's no specific opposition, we would like to ask for SECDIR > review before WGLC. > > Do authors want to update the draft beforehand to add some more > clarifications or are there any other thoughts on this? > > > [BB] The current draft could probably go to SECDIR review as it is. > However, I have a few edits already done in my local copy, and a todo list > of a few more, which I could try to get done in the next few days. Then > I'll post a rev. So I guess it might as well wait a few days for those > updates. > > Agree? > Yes, works for me. Thank you so much! -- Yoshi --00000000000055abff05bb5a169c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 12, 2021 at 3:05 PM Bob B= riscoe <ietf@bobbriscoe.net&g= t; wrote:
=20 =20 =20
Yoshi,

On 12/02/2021 17:49, Yoshifumi Nishida wrote:
=20

On Thu, Feb 11, 2021 at 1:3= 3 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:


On 09/02/2021 17:56, Scharf, Michael wrote:
> Bob,
>
>> -----Original Message-----
>> From: Bob Briscoe <ietf@bobbriscoe.net>
>> Sent: Tuesday, February 9, 2021 5:58 PM
>> To: Scheffenegger, Richard <Richard.Scheffenegger@netapp= .com>; Mirja
>> Kuehlewind <ietf@kuehlewind.net>; Scharf, Michael <Michael.Scharf@hs-
>> esslingen.de>
>> Cc: tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: AW: [tcpm] AccECN field order
>>
>> Richard,
>>
>> I just noticed I missed the last para of the old email from you below.
>> Response inline, tagged [BB]...
>>
>> On 23/11/2020 12:42, Scheffenegger, Richard wrote:
>>> I am also in favor of using two distinct option codes.
>>>
>>> However,
>>>
>>>> Or I guess we could say that only one option should be used for a
>> connection.
>>> I am opposed to this - with two option codes, a sender should be free to
>> choose whichever he prevers at any one point; For example, if the sender a
>> segment (e.g. may be the receiver side)=C2=A0 has to update the EE1 couter, but
>> also convey SACK information, it would be good to use the one, where the
>> EE1 field is first, and omit all remaining fields;
>>> Later in the same connection, that very same host may choose to update
>> the CE field together with some SACK information, and use the other
>> codepoint in order to preserve as much TCP option space for the SACK
>> option...
>>
>> [BB] I agree with you here (and disagree with Mirja below). The nice
>> thing about 2 options kinds is they are self-describing, so they can be
>> stateless (for instance, consider the code you would have to otherwise
>> add for when a host switches to a different congestion control module -
>> a lot of complexity despite being unlikely to happen).
>>
>>>
>>> As for extensibility: I would want to avoid that topic, and just specifiy the
>> three correct supported lengths here, and not mention (other than ignoring
>> "odd" fractionals of the 3-byte wide counter= s) what happens with other
>> lengths...
>>
>> [BB] A protocol spec should surely say what to do with unexpected
>> inputs. Not specifying this is one of the main reasons we have such
>> trouble changing things later - because we discover some implementers
>> handled the unexpected in different ways to others (e.g. ignore, vs RST
>> the connection), and others only handled expected inputs and didn't even
>> think to check for anything else.
>>
>> So, I believe we have to either say "reset the connection" or "ignore",
>> in response to an unexpected option length. I figure that, if there's no
>> harm in ignoring something unexpected, then why not ("liberal in what
>> you receive" principle).
>>
>> Earlier in this thread, Michael Scharf pointed out that there is some
>> potential harm here (covert channel of up to 29B), but I pointed out
>> that TCP/IP has plenty of other ways of creating covert channels, so
>> we're not really adding to any problem here. But I did say that we would
>> highlight the covert channel in the Security Considerations section, so
>> the Sec Area has a chance to object. If it raises as serious concern,
>> then we should switch from "ignore" to "= ;reset", But I doubt it will.
> I think we first have to come to the conclusion *inside* TCPM whether such a new covert channel is actually acceptable.
>
> Existing covert channels do not at all imply that a new covert channel is a good idea (and, IMHO, 29B per packet is a lot). Network administrators and operators know how to deal with the existing problems in TCP/IP. Adding any new security issue needs careful reasoning.
>=C2=A0 =C2=A0
> As individual contributor to TCPM, I believe that this covert channel must just be removed from the next version of the draft. At least I don't need other opinions to come to this personal conclusion.
>
> If this was less obvious others in the WG, TCPM could ask for an early SECDIR review to get further guidance ASAP. Then this question can be sorted out while we finish the protocol.
>
> If TCPM needs any external input on covert channels, I think an early SECDIR review would be a much better approach compared to having a security discussion during IETF last call. We are here discussing a standards track extension of one of the core Internet protocols. In such a case, at least in my view on IETF processes, other IETF areas can expect that TCPM ties to deal with known open issues within the WG as far as possible, i.e., before they see a "stable" specification in the IETF last call.
>
> In a nutshell:
>
> -1 on leaving this question open until IETF last call

[BB] That's a perfectly reasonable process proposal.

I just wanted to add that there are not just 2 choices: the WG (with
advice from SEC area if necessary) is free to limit the bandwidth of
this covert channel anywhere between 0 and 29B per packet by simply
limiting how much extensibility the protocol allows the option length
field to offer, with a 0B covert channel corresponding to no extensibility.

OK. Michael.S abstains from the decision for SECDIR review, but other co-chairs think this is an important point to be checked.
So, if there's no specific=C2=A0opposition, we would lik= e to ask for SECDIR review before WGLC.=C2=A0

Do authors want to update the draft beforehand to add some more clarifications or are there any other thoughts on this?

[BB] The current draft could probably go to SECDIR review as it is. However, I have a few edits already done in my local copy, and a todo list of a few more, which I could try to get done in the next few days. Then I'll post a rev. So I guess it might as well wait a few days for those updates.

Agree?

Yes, works for me.
Thank you so much!
--
Yoshi=C2=A0
--00000000000055abff05bb5a169c-- From nobody Tue Feb 16 00:58:12 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85733A10CA for ; Tue, 16 Feb 2021 00:58:10 -0800 (PST) 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 q8OWjLSUL1bJ for ; Tue, 16 Feb 2021 00:58:09 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0373A10C5 for ; Tue, 16 Feb 2021 00:58:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B1E3E25A24; Tue, 16 Feb 2021 09:58:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1613465886; bh=FJKtqcuJnc7++I4zAJEZYhgHdyz44M+jP8nV1ZISuS4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=wcQGm+bNti7nFXEAMNaaADX2u/KRo8I/MIKfE0yzu/usbAF3Aw+75i3IApatQScSz 1FA7JuVhdPkvruHmGe+4cJfpItadRrdK54VtEJrL5BDQVkUkRG7BKI/ZxtUjFpotG+ cV3UsXEm8Wwcjc7zj25dVgfuQWd3xSlqIA7Ig58U= 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 1otm_9susr7x; Tue, 16 Feb 2021 09:58:02 +0100 (CET) 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, 16 Feb 2021 09:58:02 +0100 (CET) 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.2176.2; Tue, 16 Feb 2021 09:58:02 +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.2176.002; Tue, 16 Feb 2021 09:58:02 +0100 From: "Scharf, Michael" To: Michael Tuexen , Neal Cardwell CC: tcpm IETF list Thread-Topic: [tcpm] 793bis ready to go? Thread-Index: Adb+OMcXKdPjASFKQc+5zg7FPT9zRwByaXyAAArIJQAARyDrAAC93P1g Date: Tue, 16 Feb 2021 08:58:02 +0000 Message-ID: <8f556136c1e0409d9f88c4153dae070d@hs-esslingen.de> References: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> In-Reply-To: <6D674614-847D-4600-9DE5-7FFD29043C7F@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] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Feb 2021 08:58:11 -0000 > > > Minor: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#sect= ion- > 3.7.4 > > > > I agree with Yuchung that it would be nice to clarify what is meant by = "idle" > connections (in the pre-existing text), with respect to keep-alives. It s= eems > at least the historical behavior for two of the major implementations out > there interpret this in different ways, and this has caused some confusio= n in > the developer community about what semantics to expect from TCP keep- > alives. I guess the rfc793bis-20 draft does have some nice new text (that > does not seem to be in RFC793 or RFC1122) that seems to shed some light o= n > this: > > > > Keep-alive packets MUST only be sent when no sent data is > > outstanding, and no data or acknowledgement packets have been > > received for the connection within an interval (MUST-26). > > > > > > That sentence helps quite a bit. It seems to correspond to the last 20 = years > of Linux TCP keep-alive behavior, but not the BSD behavior (at least BSD = TCP > as documented in Stevens volume 2; I have not checked more recent BSD > kernels). > Can elaborate what Linux behaviour you are referring to an what BSD > behaviour you are referring to? I'd also be interested in more details. Unfortunately, I am not familiar wi= th BSD. For what it is worth, RFC 1122 Section 4.2.3.6 "TCP Keep-Alives" states: Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. So, the latter part of the sentence originates from RFC 1122. Could somebody comment on whether recent BSD stacks would deviate from the = proposed text in 793bis? That would be an important insight! Michael From nobody Tue Feb 16 01:03:42 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E94D3A10E2 for ; Tue, 16 Feb 2021 01:03:41 -0800 (PST) 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=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 DjJiMVpM8oBU for ; Tue, 16 Feb 2021 01:03:39 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FD43A10DC for ; Tue, 16 Feb 2021 01:03:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 289D425A18; Tue, 16 Feb 2021 10:03:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1613466217; bh=mDpHhHnsEMDP5Sgo2BI09/cFZ7kwSsaNg9KBqSCzuW4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=FUGgTKEHQPM/C25XVATHuBTnCEitnfx+NaIy5kJtBtkCWOqoGwfmvRFUMbgI0srOF ItsAShifeEPvDQ7Fp9e3zU9yxS4IspANnK2AlZ/Gq0JrcQLxDUBF2fjqYwyCLgiMzr bfRXNi9aFCF0DA4HOjKSmNLCaCMqvfO6WDlh0rVw= 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 mHtTzcSy2_wH; Tue, 16 Feb 2021 10:03:35 +0100 (CET) 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, 16 Feb 2021 10:03:35 +0100 (CET) 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.2176.2; Tue, 16 Feb 2021 10:03:35 +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.2176.002; Tue, 16 Feb 2021 10:03:35 +0100 From: "Scharf, Michael" To: Neal Cardwell , Michael Tuexen CC: tcpm IETF list Thread-Topic: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?) Thread-Index: AQHXAhq8eiQ4bgp7kk2AmYui70jrzapagGoA Date: Tue, 16 Feb 2021 09:03:35 +0000 Message-ID: <882be5a399ea4427a4879a4a485152f2@hs-esslingen.de> References: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: multipart/alternative; boundary="_000_882be5a399ea4427a4879a4a485152f2hsesslingende_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Feb 2021 09:03:41 -0000 --_000_882be5a399ea4427a4879a4a485152f2hsesslingende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXBwYXJlbnRseSwgSSBnb3QgY29uZnVzZWQgYnkgdGhlIGhlYWRsaW5lIHdoZW4gc2VuZGluZyBt eSBwcmV2aW91cyBlLW1haWwuIFNvcnJ5IGFib3V0IHRoYXQuDQoNCk5vbmV0aGVsZXNzLCBJIHRo aW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCBpZiBzb21lYm9keSBmYW1pbGlhciB3aXRoIHRoZSBCU0Qg c3RhY2sgY291bGQgcmV2aWV3IHRoZSBjdXJyZW50IHdvcmRpbmcgaW4gNzkzYmlz4oCmDQoNCk1p Y2hhZWwNCg0KDQoNCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIE5lYWwgQ2FyZHdlbGwNClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAxMywgMjAyMSA0OjEy IFBNDQpUbzogTWljaGFlbCBUdWV4ZW4gPE1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRl Pg0KQ2M6IHRjcG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogW3RjcG1dIG1l YW5pbmcgb2YgImlkbGUiIGZvciBUQ1AgS2VlcC1BbGl2ZXMgKHdhczogNzkzYmlzIHJlYWR5IHRv IGdvPykNCg0KT24gRnJpLCBGZWIgMTIsIDIwMjEgYXQgMTA6MTkgQU0gTWljaGFlbCBUdWV4ZW4g PE1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlPG1haWx0bzpNaWNoYWVsLlR1ZXhlbkBs dXJjaGkuZnJhbmtlbi5kZT4+IHdyb3RlOg0KPiBPbiAxMS4gRmViIDIwMjEsIGF0IDA2OjIyLCBO ZWFsIENhcmR3ZWxsIDxuY2FyZHdlbGw9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4NCj4gVGhlIHdvcmRpbmcg aW4gdGhlIENvbmdlc3Rpb24gQ29udHJvbCBzZWN0aW9uIGxvb2tzIGdyZWF0IHRvIG1lLg0KPg0K PiA+IE1pbm9yOiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1y ZmM3OTNiaXMtMjAjc2VjdGlvbi0zLjcuNA0KPg0KPiBJIGFncmVlIHdpdGggWXVjaHVuZyB0aGF0 IGl0IHdvdWxkIGJlIG5pY2UgdG8gY2xhcmlmeSB3aGF0IGlzIG1lYW50IGJ5ICJpZGxlIiBjb25u ZWN0aW9ucyAoaW4gdGhlIHByZS1leGlzdGluZyB0ZXh0KSwgd2l0aCByZXNwZWN0IHRvIGtlZXAt YWxpdmVzLiBJdCBzZWVtcyBhdCBsZWFzdCB0aGUgaGlzdG9yaWNhbCBiZWhhdmlvciBmb3IgdHdv IG9mIHRoZSBtYWpvciBpbXBsZW1lbnRhdGlvbnMgb3V0IHRoZXJlIGludGVycHJldCB0aGlzIGlu IGRpZmZlcmVudCB3YXlzLCBhbmQgdGhpcyBoYXMgY2F1c2VkIHNvbWUgY29uZnVzaW9uIGluIHRo ZSBkZXZlbG9wZXIgY29tbXVuaXR5IGFib3V0IHdoYXQgc2VtYW50aWNzIHRvIGV4cGVjdCBmcm9t IFRDUCBrZWVwLWFsaXZlcy4gSSBndWVzcyB0aGUgcmZjNzkzYmlzLTIwIGRyYWZ0IGRvZXMgaGF2 ZSBzb21lIG5pY2UgbmV3IHRleHQgKHRoYXQgZG9lcyBub3Qgc2VlbSB0byBiZSBpbiBSRkM3OTMg b3IgUkZDMTEyMikgdGhhdCBzZWVtcyB0byBzaGVkIHNvbWUgbGlnaHQgb24gdGhpczoNCj4NCj4g ICAgS2VlcC1hbGl2ZSBwYWNrZXRzIE1VU1Qgb25seSBiZSBzZW50IHdoZW4gbm8gc2VudCBkYXRh IGlzDQo+ICAgIG91dHN0YW5kaW5nLCBhbmQgbm8gZGF0YSBvciBhY2tub3dsZWRnZW1lbnQgcGFj a2V0cyBoYXZlIGJlZW4NCj4gICAgcmVjZWl2ZWQgZm9yIHRoZSBjb25uZWN0aW9uIHdpdGhpbiBh biBpbnRlcnZhbCAoTVVTVC0yNikuDQo+DQo+DQo+IFRoYXQgc2VudGVuY2UgaGVscHMgcXVpdGUg YSBiaXQuIEl0IHNlZW1zIHRvIGNvcnJlc3BvbmQgdG8gdGhlIGxhc3QgMjAgeWVhcnMgb2YgTGlu dXggVENQIGtlZXAtYWxpdmUgYmVoYXZpb3IsIGJ1dCBub3QgdGhlIEJTRCBiZWhhdmlvciAoYXQg bGVhc3QgQlNEIFRDUCBhcyBkb2N1bWVudGVkIGluIFN0ZXZlbnMgdm9sdW1lIDI7IEkgaGF2ZSBu b3QgY2hlY2tlZCBtb3JlIHJlY2VudCBCU0Qga2VybmVscykuDQpDYW4gZWxhYm9yYXRlIHdoYXQg TGludXggYmVoYXZpb3VyIHlvdSBhcmUgcmVmZXJyaW5nIHRvIGFuIHdoYXQgQlNEIGJlaGF2aW91 ciB5b3UgYXJlIHJlZmVycmluZyB0bz8NCg0KQlNEOiBNeSByZWFkaW5nIG9mIHRoZSBiZWhhdmlv ciBpbiBvbGRlciBCU0QgcmVsZWFzZXMgKEJTRC00XzIgWzE5ODNdIHRocm91Z2ggQlNELTRfNF9M aXRlMiBbMTk5NV0sIG9yIFN0ZXZlbnMgdm9sdW1lIDIgWzE5OTVdKSBpcyB0aGF0IGEgVENQIGVu ZHBvaW50IHJlc2V0cyB0aGUga2VlcC1hbGl2ZSB0aW1lciAodHAtPnRfdGltZXJbVENQVF9LRUVQ XSkgdG8gaXRzIGZ1bGwga2VlcC1hbGl2ZSBpbnRlcnZhbCB1cG9uIHJlY2VpdmluZyBhIHBhY2tl dCwgYW5kIHRoZW4gd2hlbiB0aGUgdGltZXIgZmlyZXMgaXQgc2VuZHMgYSBrZWVwLWFsaXZlIHBy b2JlIHBhY2tldCAoY2FzZSBUQ1BUX0tFRVAgaW4gdGNwX3RpbWVycygpIGluIHRjcF90aW1lci5j KS4gV2hlbiB0aGF0IGtlZXAtYWxpdmUgdGltZXIgZmlyZXMgaXQgc2VlbXMgdG8gc2VuZCBhIGtl ZXAtYWxpdmUgcGFja2V0IGlycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIHRoZSBUQ1AgZW5kcG9pbnQg Y3VycmVudGx5IGhhcyBkYXRhIG91dHN0YW5kaW5nIGluIHRoZSBuZXR3b3JrLCBvciBpcyBzZW5k aW5nIFpXUCBwYWNrZXRzLg0KDQpMaW51eDogU3RhcnRpbmcgaW4gTGludXggMi4zLjQxIGluIEph biAyMDAwLCBhbmQgY29udGludWluZyB0aHJvdWdoIGN1cnJlbnQgcmVsZWFzZXMsIHRoZSBMaW51 eCBUQ1Aga2VlcC1hbGl2ZSB0aW1lciBjb2RlIGluIHRjcF9rZWVwYWxpdmVfdGltZXIoKSBoYXMg dHdvIHNpbXBsZSBleHRyYSBjaGVja3MgaW50cm9kdWNlZDoNCiAgaHR0cHM6Ly9lbGl4aXIuYm9v dGxpbi5jb20vbGludXgvMi4zLjQxL3NvdXJjZS9uZXQvaXB2NC90Y3BfdGltZXIuYyNMNzI5DQpU aGUgY2hlY2tzIGJhc2ljYWxseSBzYXkgdGhhdCBpZiB0aGUga2VlcC1hbGl2ZSB0aW1lciBnb2Vz IG9mZiBidXQgdGhlIFRDUCBlbmRwb2ludCBoYXMgZGF0YSBvdXRzdGFuZGluZyBpbiB0aGUgbmV0 d29yayAoUlRPIHRpbWVyIGlzIHNldCksIG9yIG91dGdvaW5nIGRhdGEgcXVldWVkIGFuZCB3YWl0 aW5nIGZvciBhIG5vbi16ZXJvIHJlY2VpdmUgd2luZG93IChaV1AgdGltZXIgaXMgc2V0KSwgdGhl biB0aGUgY29kZSBtZXJlbHkgcmVzZXRzIHRoZSBrZWVwLWFsaXZlIHRpbWVyLCBhbmQgc2hvcnQt Y2lyY3VpdHMgYWxsIHRoZSBrZWVwLWFsaXZlIHByb2Nlc3NpbmcgdGhhdCB3b3VsZCBzZW5kIGEg a2VlcC1hbGl2ZSBwcm9iZSBwYWNrZXQgb3IgY2hlY2sgdG8gc2VlIGlmIHRoZSBjb25uZWN0aW9u IHNob3VsZCBiZSB0b3JuIGRvd24uIFRoaXMgYmVoYXZpb3IgaXMgc2ltaWxhciB0byB0aGUgcmZj NzkzYmlzLTIwIHRleHQsICAiS2VlcC1hbGl2ZSBwYWNrZXRzIE1VU1Qgb25seSBiZSBzZW50IHdo ZW4gbm8gc2VudCBkYXRhIGlzICBvdXRzdGFuZGluZyIsIGV4Y2VwdCB0aGF0IGl0IGFsc28gc2tp cHMgc2VuZGluZyBhIGtlZXAtYWxpdmUgd2hlbiB0aGUgc2VuZGVyIGlzIGluIHRoZSBwcm9jZXNz IG9mIHNlbmRpbmcgcmVwZWF0ZWQgemVybyB3aW5kb3cgcHJvYmVzICh3aGljaCB3b3VsZCBhbHNv IHNlcnZlIHRvIHRlbGwgd2hldGhlciB0aGUgcmVtb3RlIGVuZHBvaW50IGlzIHJlYWNoYWJsZSku DQoNCmJlc3QsDQpuZWFsDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg== --_000_882be5a399ea4427a4879a4a485152f2hsesslingende_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXBwYXJlbnRseSwg SSBnb3QgY29uZnVzZWQgYnkgdGhlIGhlYWRsaW5lIHdoZW4gc2VuZGluZyBteSBwcmV2aW91cyBl LW1haWwuIFNvcnJ5IGFib3V0IHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Tm9uZXRoZWxlc3MsIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIGlmIHNvbWVib2R5IGZhbWls aWFyIHdpdGggdGhlIEJTRCBzdGFjayBjb3VsZCByZXZpZXcgdGhlIGN1cnJlbnQgd29yZGluZyBp biA3OTNiaXPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NaWNoYWVsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gdGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYub3Jn Jmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTmVhbCBDYXJkd2VsbDxicj4NCjxiPlNlbnQ6PC9i PiBTYXR1cmRheSwgRmVicnVhcnkgMTMsIDIwMjEgNDoxMiBQTTxicj4NCjxiPlRvOjwvYj4gTWlj aGFlbCBUdWV4ZW4gJmx0O01pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlJmd0Ozxicj4N CjxiPkNjOjwvYj4gdGNwbSBJRVRGIGxpc3QgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFt0Y3BtXSBtZWFuaW5nIG9mICZxdW90O2lkbGUmcXVvdDsgZm9yIFRDUCBL ZWVwLUFsaXZlcyAod2FzOiA3OTNiaXMgcmVhZHkgdG8gZ28/KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxMiwgMjAyMSBh dCAxMDoxOSBBTSBNaWNoYWVsIFR1ZXhlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuVHVl eGVuQGx1cmNoaS5mcmFua2VuLmRlIj5NaWNoYWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgT24gMTEuIEZlYiAyMDIxLCBhdCAwNjoyMiwgTmVh bCBDYXJkd2VsbCAmbHQ7bmNhcmR3ZWxsPTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHdvcmRpbmcgaW4gdGhlIENv bmdlc3Rpb24gQ29udHJvbCBzZWN0aW9uIGxvb2tzIGdyZWF0IHRvIG1lLjxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IE1pbm9yOiZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0yMCNzZWN0aW9uLTMuNy40IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJm Yzc5M2Jpcy0yMCNzZWN0aW9uLTMuNy40PC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFncmVl IHdpdGggWXVjaHVuZyB0aGF0IGl0IHdvdWxkIGJlIG5pY2UgdG8gY2xhcmlmeSB3aGF0IGlzIG1l YW50IGJ5ICZxdW90O2lkbGUmcXVvdDsgY29ubmVjdGlvbnMgKGluIHRoZSBwcmUtZXhpc3Rpbmcg dGV4dCksIHdpdGggcmVzcGVjdCB0byBrZWVwLWFsaXZlcy4gSXQgc2VlbXMgYXQgbGVhc3QgdGhl IGhpc3RvcmljYWwgYmVoYXZpb3IgZm9yIHR3byBvZiB0aGUgbWFqb3IgaW1wbGVtZW50YXRpb25z IG91dCB0aGVyZSBpbnRlcnByZXQgdGhpcyBpbiBkaWZmZXJlbnQNCiB3YXlzLCBhbmQgdGhpcyBo YXMgY2F1c2VkIHNvbWUgY29uZnVzaW9uIGluIHRoZSBkZXZlbG9wZXIgY29tbXVuaXR5IGFib3V0 IHdoYXQgc2VtYW50aWNzIHRvIGV4cGVjdCBmcm9tIFRDUCBrZWVwLWFsaXZlcy4gSSBndWVzcyB0 aGUgcmZjNzkzYmlzLTIwIGRyYWZ0IGRvZXMgaGF2ZSBzb21lIG5pY2UgbmV3IHRleHQgKHRoYXQg ZG9lcyBub3Qgc2VlbSB0byBiZSBpbiBSRkM3OTMgb3IgUkZDMTEyMikgdGhhdCBzZWVtcyB0byBz aGVkIHNvbWUgbGlnaHQNCiBvbiB0aGlzOjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgS2VlcC1hbGl2ZSBwYWNrZXRzIE1VU1Qgb25seSBiZSBzZW50IHdoZW4gbm8gc2VudCBkYXRh IGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgb3V0c3RhbmRpbmcsIGFuZCBubyBkYXRhIG9yIGFj a25vd2xlZGdlbWVudCBwYWNrZXRzIGhhdmUgYmVlbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJl Y2VpdmVkIGZvciB0aGUgY29ubmVjdGlvbiB3aXRoaW4gYW4gaW50ZXJ2YWwgKE1VU1QtMjYpLjxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQgc2VudGVuY2UgaGVscHMgcXVpdGUg YSBiaXQuIEl0IHNlZW1zIHRvIGNvcnJlc3BvbmQgdG8gdGhlIGxhc3QgMjAgeWVhcnMgb2YgTGlu dXggVENQIGtlZXAtYWxpdmUgYmVoYXZpb3IsIGJ1dCBub3QgdGhlIEJTRCBiZWhhdmlvciAoYXQg bGVhc3QgQlNEIFRDUCBhcyBkb2N1bWVudGVkIGluIFN0ZXZlbnMgdm9sdW1lIDI7IEkgaGF2ZSBu b3QgY2hlY2tlZCBtb3JlIHJlY2VudCBCU0Qga2VybmVscykuPGJyPg0KQ2FuIGVsYWJvcmF0ZSB3 aGF0IExpbnV4IGJlaGF2aW91ciB5b3UgYXJlIHJlZmVycmluZyB0byBhbiB3aGF0IEJTRCBiZWhh dmlvdXIgeW91IGFyZSByZWZlcnJpbmcgdG8/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CU0Q6IE15IHJlYWRpbmcgb2YgdGhlIGJl aGF2aW9yIGluIG9sZGVyIEJTRCByZWxlYXNlcyAoQlNELTRfMiBbMTk4M10gdGhyb3VnaCZuYnNw O0JTRC00XzRfTGl0ZTIgWzE5OTVdLCBvciBTdGV2ZW5zIHZvbHVtZSAyIFsxOTk1XSkgaXMgdGhh dCBhIFRDUCBlbmRwb2ludCByZXNldHMgdGhlIGtlZXAtYWxpdmUgdGltZXIgKHRwLSZndDt0X3Rp bWVyW1RDUFRfS0VFUF0pIHRvIGl0cyBmdWxsIGtlZXAtYWxpdmUgaW50ZXJ2YWwNCiB1cG9uIHJl Y2VpdmluZyBhIHBhY2tldCwgYW5kIHRoZW4gd2hlbiB0aGUgdGltZXIgZmlyZXMgaXQgc2VuZHMg YSBrZWVwLWFsaXZlIHByb2JlIHBhY2tldCAoY2FzZSBUQ1BUX0tFRVAgaW4mbmJzcDt0Y3BfdGlt ZXJzKCkgaW4gdGNwX3RpbWVyLmMpLiBXaGVuIHRoYXQga2VlcC1hbGl2ZSB0aW1lciBmaXJlcyBp dCBzZWVtcyB0byBzZW5kIGEga2VlcC1hbGl2ZSBwYWNrZXQgaXJyZXNwZWN0aXZlIG9mIHdoZXRo ZXIgdGhlIFRDUCBlbmRwb2ludCBjdXJyZW50bHkNCiBoYXMgZGF0YSBvdXRzdGFuZGluZyBpbiB0 aGUgbmV0d29yaywgb3IgaXMgc2VuZGluZyBaV1AgcGFja2V0cy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGludXg6IFN0YXJ0aW5nIGluIExp bnV4IDIuMy40MSBpbiBKYW4gMjAwMCwgYW5kIGNvbnRpbnVpbmcgdGhyb3VnaCBjdXJyZW50IHJl bGVhc2VzLCB0aGUgTGludXggVENQIGtlZXAtYWxpdmUgdGltZXIgY29kZSBpbiB0Y3Bfa2VlcGFs aXZlX3RpbWVyKCkgaGFzIHR3byBzaW1wbGUgZXh0cmEgY2hlY2tzIGludHJvZHVjZWQ6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgvMi4zLjQxL3NvdXJjZS9uZXQv aXB2NC90Y3BfdGltZXIuYyNMNzI5Ij4NCmh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4 LzIuMy40MS9zb3VyY2UvbmV0L2lwdjQvdGNwX3RpbWVyLmMjTDcyOTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGVja3MgYmFzaWNh bGx5IHNheSB0aGF0IGlmIHRoZSBrZWVwLWFsaXZlIHRpbWVyIGdvZXMgb2ZmIGJ1dCB0aGUgVENQ IGVuZHBvaW50IGhhcyBkYXRhIG91dHN0YW5kaW5nIGluIHRoZSBuZXR3b3JrIChSVE8gdGltZXIg aXMgc2V0KSwgb3Igb3V0Z29pbmcgZGF0YSBxdWV1ZWQgYW5kIHdhaXRpbmcgZm9yIGEgbm9uLXpl cm8gcmVjZWl2ZSB3aW5kb3cgKFpXUCB0aW1lciBpcyBzZXQpLCB0aGVuIHRoZSBjb2RlDQogbWVy ZWx5IHJlc2V0cyB0aGUga2VlcC1hbGl2ZSB0aW1lciwgYW5kIHNob3J0LWNpcmN1aXRzIGFsbCB0 aGUga2VlcC1hbGl2ZSBwcm9jZXNzaW5nIHRoYXQgd291bGQgc2VuZCBhIGtlZXAtYWxpdmUgcHJv YmUgcGFja2V0IG9yIGNoZWNrIHRvIHNlZSBpZiB0aGUgY29ubmVjdGlvbiBzaG91bGQgYmUgdG9y biBkb3duLiBUaGlzIGJlaGF2aW9yIGlzIHNpbWlsYXIgdG8gdGhlJm5ic3A7cmZjNzkzYmlzLTIw IHRleHQsJm5ic3A7ICZxdW90O0tlZXAtYWxpdmUgcGFja2V0cyBNVVNUDQogb25seSBiZSBzZW50 IHdoZW4gbm8gc2VudCBkYXRhIGlzJm5ic3A7IG91dHN0YW5kaW5nJnF1b3Q7LCBleGNlcHQgdGhh dCBpdCBhbHNvIHNraXBzIHNlbmRpbmcgYSBrZWVwLWFsaXZlIHdoZW4gdGhlIHNlbmRlciBpcyBp biB0aGUgcHJvY2VzcyBvZiBzZW5kaW5nIHJlcGVhdGVkIHplcm8gd2luZG93IHByb2JlcyAod2hp Y2ggd291bGQgYWxzbyBzZXJ2ZSB0byB0ZWxsIHdoZXRoZXIgdGhlIHJlbW90ZSBlbmRwb2ludCBp cyByZWFjaGFibGUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5iZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+bmVhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_882be5a399ea4427a4879a4a485152f2hsesslingende_-- From nobody Tue Feb 16 01:40:48 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A963A1142 for ; Tue, 16 Feb 2021 01:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 o975h7-TZv2y for ; Tue, 16 Feb 2021 01:40:45 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6230F3A1141 for ; Tue, 16 Feb 2021 01:40:45 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id u25so14792057lfc.2 for ; Tue, 16 Feb 2021 01:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A999Rv6RS2i3jJ0JBJ/4KsrqNMCKrfmfkaHfdTOTGYQ=; b=CEj3hNeAT/eL9ICn0gSUyidKp9rrjvG+mmJkSs2Jl2+xqwG+JJlu7nGReWF6Vqt2eJ yvqoBnawcHO7bNOKb3t+vCIk4ZmKYoNT3R5H++1xXiBeGqpzii+/E8duhEWLyk+h+vkV wEqt2R11WBARIGq4TKCqsdXv4CcGvfzA2Oam4YhAkerfNS2wcrZhduWJoil/uZUCcbpO whw1tu6hhJ0bxyA/03ZQ4MP/bSZxDemq4R95lPdwkKeeZ0opixA0ddwtPdsoMVmN4oFR YVLZcN4HPjwdw9BFmmxA7tpqQqmVi67MM33RJJQzv7HwZmOY3eaHBa+N76mQ9NBTYKqM aQ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A999Rv6RS2i3jJ0JBJ/4KsrqNMCKrfmfkaHfdTOTGYQ=; b=k+yBrPrd9iUTukBvgFkJHtgnT7AvZPhatpC9Aze7GMPUTTV1jWZ9IHH1XcLsrePEBT Nnb2soa0zfDB3Y5cXkcmfmz10zGdq8pnWtyY7fwWBconvee5fb6PGoruLnSqc/PzzQzy 5m9IBrHjkYEjzFL1tSq4mJuLJwie+r6XD42Xp6awUGZrjS8JpMJkATVNiXSbaMirZiBQ f/M1Uv/RUGptzIjNULr0NRXbY8x+m13Bh3dFkZuZG+3/K0CFrqM1RIOkxVb3Vr9HpGAW ji6hWHtR7PPMahkI2+rLe0lOR82OIM+gzMRH55zpNXhuSzanJAF1D9AvL7KAqq1Y9aok hdew== X-Gm-Message-State: AOAM531FNQKakBCvd2SKsedtq5uwsU/MkBR9jJJ5ZHCxFl0lZhXbfNYH UY9lpZvA5PALoal5JXdPEPU= X-Google-Smtp-Source: ABdhPJwDhwyAIwn43ctpyb5FBjZTvom7/ygSF9qzEGGYjKsVOVczBH12tCkEm5II8HLk+7Um8p4M7g== X-Received: by 2002:ac2:5b89:: with SMTP id o9mr11596487lfn.54.1613468443542; Tue, 16 Feb 2021 01:40:43 -0800 (PST) Received: from jonathartonsmbp.lan (188-67-254-178.bb.dnainternet.fi. [188.67.254.178]) by smtp.gmail.com with ESMTPSA id f20sm3093527lfk.188.2021.02.16.01.40.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 01:40:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Tue, 16 Feb 2021 11:40:41 +0200 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <085E60F6-B396-4AB2-8BAE-BF615AD51825@gmail.com> References: To: "Scharf, Michael" X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Feb 2021 09:40:47 -0000 > On 8 Feb, 2021, at 7:00 pm, Scharf, Michael = wrote: >=20 > A TCP endpoint MUST implement the basic congestion control = algorithms > slow start, congestion avoidance, and exponential back-off of RTO to > avoid creating congestion collapse conditions (MUST-19). RFC 5681 > and RFC 6298 describe the basic algorithms on the IETF Standards > Track that are broadly applicable. Multiple other suitable > algorithms exist and have been widely used. Many TCP = implementations > support a set of alternative algorithms that can be configured for > use on the endpoint. An endpoint may implement such alternative > algorithms provided that the algorithms are conformant with the TCP > specifications from the IETF Standards Track as described in RFC > 2914, RFC 5033 [10], and RFC 8961 [15]. I agree that this is substantially the right approach. One quibble is = that the word "may" is used, but not capitalised and given a = corresponding MAY-X entry in Appendix B. I think it would be = appropriate to do so here, in the last sentence above. - Jonathan Morton= From nobody Tue Feb 16 03:49:05 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E773A0958; Tue, 16 Feb 2021 03:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkYuX1fUCuom; Tue, 16 Feb 2021 03:49:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9CF5E3A0957; Tue, 16 Feb 2021 03:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613476126; bh=JST8xN2xSqhHo4K0qKa64rMO3vImmgv6orTXdZxa+js=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gi00h9V+T6kYY/+bVIwBZEeBvPFiUTJthKM0VHwfYWk0oGuAnY1NywtMzJEHb8S48 GPOKLFjEvvX1bp4jXGFBws6iXw9ZLv10S5uRg25J1ZT2omA5oqYdprpf4DlTtO5qyV YJbs8XBwbqZFTKACEYHylHKsjj55XQuArdWs61Xs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.106] ([185.236.167.136]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTzfG-1lKGbM0rpq-00R2Qi; Tue, 16 Feb 2021 12:48:46 +0100 To: "Scharf, Michael" , Neal Cardwell , Michael Tuexen Cc: tcpm IETF list , freebsd-transport@freebsd.org References: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> <882be5a399ea4427a4879a4a485152f2@hs-esslingen.de> From: "Scheffenegger, Richard" Message-ID: <27952497-a9fa-5f97-c923-d78fa9add0dc@gmx.at> Date: Tue, 16 Feb 2021 12:48:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <882be5a399ea4427a4879a4a485152f2@hs-esslingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:1hPWqzxGYolmaur0RSfGTRJ9pxxxP7qpyOUY7Ll1CojJpF/cYfw XeGWVxqAefrHcnUx3U2H9H39+jnYpwzjB3IVjz1qv7KEaXb1QdRTSuYE4JOknn/PmOPHdWX ps7zrHlMLy3N/dBZg0sBJImDrCMU9f0srS9SA6oca9p7EZa5jiMXd6OAhikI82Y4qGphPg0 hAkV6xja97hOkoSQXJ8dw== X-UI-Out-Filterresults: notjunk:1;V03:K0:55SJ2kiWqvc=:uT0jASjrCpqg6g5u+Tduum D83c0crY17xPpkSuYk87Rfi/ZrcNxOYmxxbSfs7ZSiDW7aViOBaOlnHF/TaoGseg5GpJ4BIKs N+J40eMXZaY/P8Kw+EGQ8fymj+93eMZM8YAGerKEwjxNnN23XBpIfm2WRRLnSfPBx5IFawo4B mSvb93wgD0oeGDE2P4eHyA06empESbejAdfkMTqa8SQafAqsrTuTADEg/+djrrvKpxLzLEgCB 6jA/ccVum1vIWuuvn2csYECJF/ETnqU4IenidEzCqmN1M1WTVxKjPt6OEsvkl4LQwMVrkNENh B+KMA1By/uaKZ9ai98j3LanzVSZ2tZs23B1YSZxVNAuz1LGA7a8MTXo/xbtlw6xVViVNXkNfj cTug4NxEIdyohcxNj1chVaoJ0XJJ181t4pr59oWplrSebVPXTChhej/wUr99wC5s1wa347y3J mOd8qLKQD1gnTQ4qTbA4u2DvCaSm/8bOE+QIITQiEBmDclr/Hldu0y+AjqIDVTRkmWs9IreYj HrSXTBzEMtnKgttJeCE5DVoIDjeplL4NWHVZA+Rl4Mi4mBWEn1fI3RObJz30F2ALOZQaWfQXv LOT0Bn0WRhR0NK3ECFksiA+/NzNkd3oYvEvKflSkVNP8etvfGMayWzxgbSk2Q97LtrrsNI69N zjj/WpymnxBTHdHKu8mo9GJ7HZms+oUGVSJpc3lgTnmgWbJT54pMF+knFp6MCifNGvYo5bsi3 a4FteL/uxdXnUqDbPPnYwWTikPV1ZP5ugJtSSV7D4K/SATMAfysOwM0L5z6kkSwPHehaNFZC7 ySrFl3Oh9jbxoCBen3sYKUsrSITGUO8HHAD3pOEqtLqe7wkghojmjK1bj4dBhKY+/GqTzqrjB 0qK9ok5eSissSE+n6XPg== Archived-At: Subject: Re: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Feb 2021 11:49:04 -0000 I think the wording in 793bis is reasonable. Also, I am not aware of a deviation from this behavior in any recent BSD kernels - OTOH it is hard to get to a point with outstanding data, when the keepalive timer fires (the outstanding data will have been retransmitted by means of the RTO timer firing multiple times, and the session most likely having been closed well before keepalive would become relevant. A quick inspection of the code appears to implement the 2nd half of the statement "verbatim", relying on the much shorter RTO timers to deal with the first half. Strictly speaking, a socket could be configured with TCP_KEEPIDLE set to 1 sec, which could potentially cause the keepalive timer to fire prior to the expiration of all RTO attempts. Best regards, Richard Am 16.02.2021 um 10:03 schrieb Scharf, Michael: > Apparently, I got confused by the headline when sending my previous > e-mail. Sorry about that. > > Nonetheless, I think it would be useful if somebody familiar with the > BSD stack could review the current wording in 793bis=E2=80=A6 > > Michael > > *From:* tcpm *On Behalf Of * Neal Cardwell > *Sent:* Saturday, February 13, 2021 4:12 PM > *To:* Michael Tuexen > *Cc:* tcpm IETF list > *Subject:* [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis > ready to go?) > > On Fri, Feb 12, 2021 at 10:19 AM Michael Tuexen > > wrote: > > > On 11. Feb 2021, at 06:22, Neal Cardwell > > wrote: > > > > The wording in the Congestion Control section looks great to me. > > > > > Minor: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7= .4 > > > > > I agree with Yuchung that it would be nice to clarify what is > meant by "idle" connections (in the pre-existing text), with respect > to keep-alives. It seems at least the historical behavior for two of > the major implementations out there interpret this in different > ways, and this has caused some confusion in the developer community > about what semantics to expect from TCP keep-alives. I guess the > rfc793bis-20 draft does have some nice new text (that does not seem > to be in RFC793 or RFC1122) that seems to shed some light on this: > > > >=C2=A0 =C2=A0 Keep-alive packets MUST only be sent when no sent da= ta is > >=C2=A0 =C2=A0 outstanding, and no data or acknowledgement packets = have been > >=C2=A0 =C2=A0 received for the connection within an interval (MUST= -26). > > > > > > That sentence helps quite a bit. It seems to correspond to the > last 20 years of Linux TCP keep-alive behavior, but not the BSD > behavior (at least BSD TCP as documented in Stevens volume 2; I have > not checked more recent BSD kernels). > Can elaborate what Linux behaviour you are referring to an what BSD > behaviour you are referring to? > > BSD: My reading of the behavior in older BSD releases (BSD-4_2 [1983] > through=C2=A0BSD-4_4_Lite2 [1995], or Stevens volume 2 [1995]) is that a= TCP > endpoint resets the keep-alive timer (tp->t_timer[TCPT_KEEP]) to its > full keep-alive interval upon receiving a packet, and then when the > timer fires it sends a keep-alive probe packet (case TCPT_KEEP > in=C2=A0tcp_timers() in tcp_timer.c). When that keep-alive timer fires i= t > seems to send a keep-alive packet irrespective of whether the TCP > endpoint currently has data outstanding in the network, or is sending > ZWP packets. > > Linux: Starting in Linux 2.3.41 in Jan 2000, and continuing through > current releases, the Linux TCP keep-alive timer code in > tcp_keepalive_timer() has two simple extra checks introduced: > > https://elixir.bootlin.com/linux/2.3.41/source/net/ipv4/tcp_timer.c#L729 > > > The checks basically say that if the keep-alive timer goes off but the > TCP endpoint has data outstanding in the network (RTO timer is set), or > outgoing data queued and waiting for a non-zero receive window (ZWP > timer is set), then the code merely resets the keep-alive timer, and > short-circuits all the keep-alive processing that would send a > keep-alive probe packet or check to see if the connection should be torn > down. This behavior is similar to the=C2=A0rfc793bis-20 text,=C2=A0 "Kee= p-alive > packets MUST only be sent when no sent data is=C2=A0 outstanding", excep= t > that it also skips sending a keep-alive when the sender is in the > process of sending repeated zero window probes (which would also serve > to tell whether the remote endpoint is reachable). > > best, > > neal > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Feb 16 06:13:02 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39EA3A0D3D for ; Tue, 16 Feb 2021 06:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 iKJpLVUDc_pu for ; Tue, 16 Feb 2021 06:12:57 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E863A0D3C for ; Tue, 16 Feb 2021 06:12:56 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Tue, 16 Feb 2021 16:12:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=gKiiSRO5Ic3B13hA3 jTbrQtJlfadg5rqhXhdsHmqtk8=; b=iiFw6u72iCqCwRvMe3RzRywfMIzvHEWNa DyBC1MrJfyYL75kCLaoL2STs7Et7Ln0qPbVduBzjOt8YiT+6NfJHKvCPU2Kmua7e rFwidy868Nr7EKsrMnorZFV5qZM0b/SUp9UTsP9dioFDW/mnmz794sxuHP9W6nti M9CAvets7I= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Tue, 16 Feb 2021 16:12:51 +0200 id 00000000005A1C68.00000000602BD2E3.00001CC0 Date: Tue, 16 Feb 2021 16:12:50 +0200 (EET) From: Markku Kojo To: Michael Scharf cc: tcpm IETF list In-Reply-To: Message-ID: References: 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] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 16 Feb 2021 14:13:00 -0000 The CC test looks good. Just two minor things: one editorial and another small addition to address exponential backoff more accurately and correctly. See inline. On Mon, 8 Feb 2021, Michael Scharf wrote: > Dear all, > > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to Wes, all WGLC feedback should be reflected in this version. A link to a complete diff can be found below. > > During WGLC, there has been quite some discussion on the exact wording on congestion control. The suggested text in version -20 is copied below: > > 3.7.2. TCP Congestion Control > > RFC 2914 [7] explains the importance of congestion control for the > Internet. > > RFC 1122 required implementation of Van Jacobson's congestion control > algorithms slow start with congestion avoidance together with Here "SS with CA together with ..." reads a bit odd to me. But not sure as a non-native speaker. Would it possibly read better if changed to(?): "algorithms slow start and congestion avoidance together with exponential back-off ..." OR: "algorithms slow start, congestion avoidance, and exponential back-off ..." > exponential back-off for successive RTO values for the same segment. > RFC 2581 provided IETF Standards Track description of slow start and > congestion avoidance, along with fast retransmit and fast recovery. > RFC 5681 is the current description of these algorithms and is the > current Standards Track specification providing guidelines for TCP > congestion control. RFC 6298 describes exponential back-off of RTO > values, including keeping the backed-off value until a subsequent > segment with new data has been sent and acknowledged. It would be useful to make the last sentence unambiguous as per Karn's original specification: "segment with new data has been sent and acknowledged without retransmission." Thanks, /Markku > A TCP endpoint MUST implement the basic congestion control algorithms > slow start, congestion avoidance, and exponential back-off of RTO to > avoid creating congestion collapse conditions (MUST-19). RFC 5681 > and RFC 6298 describe the basic algorithms on the IETF Standards > Track that are broadly applicable. Multiple other suitable > algorithms exist and have been widely used. Many TCP implementations > support a set of alternative algorithms that can be configured for > use on the endpoint. An endpoint may implement such alternative > algorithms provided that the algorithms are conformant with the TCP > specifications from the IETF Standards Track as described in RFC > 2914, RFC 5033 [10], and RFC 8961 [15]. > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > an IETF Standards Track enhancement that has many benefits [50]. > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > 8). > > As document shepherd I ask everybody - specifically all TCPM contributors who have commented on congestion control - to carefully review this proposed wording within the next few days. If there are any issues with this suggested resolution of the WGLC, please speak up! > > If the TCPM working group is fine with version -20, 793bis would be ready to go. > > Thanks > > Michael > > > -----Original Message----- > From: I-D-Announce On Behalf Of internet-drafts@ietf.org > Sent: Thursday, January 21, 2021 7:02 PM > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. > > Title : Transmission Control Protocol (TCP) Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-20.txt > Pages : 110 > Date : 2021-01-21 > > 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-20 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Feb 16 12:33:55 2021 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 5FFF33A10BF; Tue, 16 Feb 2021 12:33:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161350762933.6467.7665402654665318814@ietfa.amsl.com> Date: Tue, 16 Feb 2021 12:33:49 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-07.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, 16 Feb 2021 20:33:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-07.txt Pages : 47 Date : 2021-02-16 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 16 13:00:59 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D53A1117 for ; Tue, 16 Feb 2021 13:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBI_RqaXdcFd for ; Tue, 16 Feb 2021 13:00:55 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 33F7A3A1115 for ; Tue, 16 Feb 2021 12:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID: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=GTWNWXQt7AAFo37pKwidEEMGLXRwbBI0gTFc7dBJDdg=; b=IgwyEoPIujhVLJneGjHZ+bJ7bU HDHaf8EWGRugqP3EcOphxIwTk/dzdoTzFEh3LtVzS5mBAtAwSExkJUoNQg2g/yH95DjxTLpeYlwco XZ0nH3O2hR1bGXu7w2aQhLZgJrpupdGXc02hla3zKxzZrL8Q0qrTLnk+f3/DU0PbNDbKWi6O9PtMN eEaeCnNSD1Z/tqGampSs5rg3PR/VGikxWKi/ovlNp+1aSoHmcYGeyAJqDGC17iDvkKCawCg6yPGig EGco4hN8pI4gjf/ibwgWmNp0YDkwcTAYIJQTh/1R1661zxU8zKETQM7eFntUKRNq/ntYGqpxeNaRs mJvbdQZg==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:33706 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lC7RC-00081o-Bb; Tue, 16 Feb 2021 20:59:14 +0000 To: tcpm IETF list References: <161350762975.6467.4450142603887419175@ietfa.amsl.com> From: Bob Briscoe Message-ID: Date: Tue, 16 Feb 2021 20:59:11 +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: <161350762975.6467.4450142603887419175@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 - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [tcpm] Summary of diff for draft-ietf-tcpm-generalized-ecn-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 21:00:57 -0000 tcpm-ers, I've just submitted a new rev of the ECN++ draft for the experimental track. The draft and diff are linked below as always. Here's a brief bullet list of the main changes. No significant changes, as would be expected at this stage. But thanks for the useful comments that led to these, particularly those from Richard with the benefit of his implementation experience in FreeBSD. * S.1 Intro     Called out in the text (not just the header block) that this draft obsoletes RFC 5562 (aka ECN+) and explained why (ECN++ is a superset). * S.3.2.6  RST (Send)     Advised how not to leak internals of TCP state machine by marking all packets of each type consistently     (and ack'd Richard Schef.) * S.3.3.2. SYN (Receive)     When recommending servers accept SYNs with non-zero IP/ECN, more precise advice on detecting ECN mangling     (following offlist discussion with Mirja). * S.4.4.1.  Mechanisms to Respond to CE-Marked Pure ACKs    More precise wording for the rationale on feedback of congestion markings on pure ACKs Regards Bob On 16/02/2021 20:33, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-tcpm-generalized-ecn-07.txt > has been successfully submitted by Bob Briscoe and posted to the > IETF repository. > > Name: draft-ietf-tcpm-generalized-ecn > Revision: 07 > Title: ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets > Document date: 2021-02-16 > Group: tcpm > Pages: 47 > URL: https://www.ietf.org/archive/id/draft-ietf-tcpm-generalized-ecn-07.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn > Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-07 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-07 > > 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. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Feb 17 02:35:32 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14373A18EE for ; Wed, 17 Feb 2021 02:35:30 -0800 (PST) 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 uwSTKHhX5k4O for ; Wed, 17 Feb 2021 02:35:29 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 CEF483A18EF for ; Wed, 17 Feb 2021 02:35:28 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id h16so9096511qth.11 for ; Wed, 17 Feb 2021 02:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1snWD8BXuTL5u3GGPuVUdYb0StS+E+OeMQzy0lbEXNY=; b=vNBYyUZmw1CNWQyRTnwsazHm6X6tQ6nLKDZ4G3iAPLM4p2gVj7khNEmRVqUHPoB68u n9Ok33/bqie5Sy1xUU0JmtKVPesvPh7vIcnWwoRSc/uhehHk8WgTH1k/PO2xQ3LScVGK yacb2IM85VARklLGnPhytOAE/hf8RCwpQD6u/S/i1wS7a3LfczNXlkODP1/jpfe0b2Ac NOI1VMzNr497WHSsaKIZO1QO6vlakMn1Zjk7pKs4xMaRccX+0YF6gLvGE+8xx37WyNW9 nJ/yUqBjjfqFY1zYKqsjSmYf72cP89IPoMhvmGt9brzPIeSm8Etj0TY8J5Mt7WaDg4UB 2cXQ== 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=1snWD8BXuTL5u3GGPuVUdYb0StS+E+OeMQzy0lbEXNY=; b=qTvzdK+29037emu3VQATEZJ5hYrC9t96zdAX0ssGgvaqATCPWeHGCCnHxW7rPnY4IA phmLnKKJI+hT1SEmSyWqDAXnRTXN/51chB2m8HzvPn+aPMKyrKAK5e46qH49QtTgW+a6 7Ctp9WqaqVfEnyzPhQGK/XtnkaDotvJ8O7KMXQ6483gd9bheMWFBjDu6sYHnekSC0605 eVlBlWBa+9qimp2uNkS9dnu9UDQofJ0uzMMS62rsoh7R/hPwMScKxJL7cSV7LWOqoFgd SVS5V9N7NC66sl6y4Dst65t7OX+eO7F9e5KArVAnff88mymakH5+1saT+NPO+SlvKs6B 90cQ== X-Gm-Message-State: AOAM531ofUIFVkQOaiag4vIuXPRgyyTaNn2X6S3xG1D14Qjm3RKg8fZd mFUx81eVKGYgH9b+o7MPDGUuFv37LV3KW/nDo1A= X-Google-Smtp-Source: ABdhPJwhYQf/44AGDFr+D9Rswht9DQWO3fmgPp8Qb8KCi4/9JAZfFY1GZm6L5IAw/d48jbKgTYK7qb2kmZJnhSIceus= X-Received: by 2002:ac8:4911:: with SMTP id e17mr23618636qtq.190.1613558127678; Wed, 17 Feb 2021 02:35:27 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5E77372@dggemm514-mbs.china.huawei.com> <13954E42-57C2-468E-BE12-517659A6CEF9@strayalpha.com> In-Reply-To: <13954E42-57C2-468E-BE12-517659A6CEF9@strayalpha.com> From: Yoshifumi Nishida Date: Wed, 17 Feb 2021 02:35:16 -0800 Message-ID: To: Joseph Touch Cc: "tcpm@ietf.org Extensions" , Liangqiandeng Content-Type: multipart/alternative; boundary="000000000000065b5705bb85c764" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 10:35:31 -0000 --000000000000065b5705bb85c764 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, On Fri, Feb 12, 2021 at 8:45 PM Joseph Touch wrote: > > > On Feb 12, 2021, at 9:52 AM, Yoshifumi Nishida wrote= : > > OK. So, in my understanding, what you're suggesting are the followings. > > - Aggregated options would be useful. but, the format can be simple 4 > bytes length option that can accomodate 16 options. > > > Yes, > > - The tricks to avoid reflecting options in SYN ACK will not be needed > because it's the receiver's responsibility. > > > Yes. > > - Delayed negotiation might be possible. But, no generic framework is > needed. Each option should be designed for its own way to support it. > > > Yes. > > But, once thing I am wondering is that we can still combine Aggregated > options and delayed negotiation even with this one. > > > Delayed negotiation is a completely separate and very complicated issue. > It=E2=80=99s not as simple as =E2=80=9Cdo it later=E2=80=9D; in the TWHS,= the sequence of messages > is defined. Elsewhere, messages can come out of order - at which point th= e > meaning of options with respect to that order has to be defined. That=E2= =80=99s a > can of worms and completely independent of whether aggregated options are > supported. > > if you are meaning options not appeared in SYN cannot be used in the > following segments, I think accecn option might be a precedent for this. > > > Accecn may not appear in an option explicitly, but it is communicated > using SYN flags. That=E2=80=99s very close to what the compressed options= achieves. > > I.e., the option value itself need not appear in the SYN, but the use of > that option *is* signaled using the SYN/SYN-ACK, either way. > > Again, doing that negotiaton after the TWHS is a separate and more comple= x > issue that I believe should be defined for each option (even if you want = to > define it for a separate post-SYN aggregate option); it can=E2=80=99t be > generalized for existing options. > OK. I think I understand your viewpoints. Thanks for the explanation. However, I still have different views on them. I've re-read the mptcp specs, but, the design of option negotiation scheme in the doc looks to me not mptcp-specific and simply aims to exchange additional info reliably. Also, I still think it's possible to combine aggregate option and delayed negotiation scheme. It can be separated, but I don't see issues even if it's combined. But, anyway, at this point I don't think I have enough evidence to convince you. I will think about this further. Also, if possible, I would like to hear other people's options. Thanks, -- Yoshi --000000000000065b5705bb85c764 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Fri, Feb 12, 2021 at 8:45 PM Jos= eph Touch <tou= ch@strayalpha.com> wrote:


On Feb 12= , 2021, at 9:52 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

OK. So, in my understanding, what you're suggesting ar= e the followings.

= - Aggregated options would be useful. but, the format can be simple 4 bytes= length option that can accomodate 16 options.

Yes,

- The tricks to avoid reflecting options in SYN ACK will not be need= ed because it's the receiver's responsibility.

Yes.

- Delayed negotiation might be possible. But, no generic fra= mework is needed. Each option should be designed for its own way to support= it.

Yes.

But, once thing I am wondering is t= hat we can still combine Aggregated options and delayed negotiation even wi= th this one.

Delayed negotiatio= n is a completely separate and very complicated issue. It=E2=80=99s not as = simple as =E2=80=9Cdo it later=E2=80=9D; in the TWHS, the sequence of messa= ges is defined. Elsewhere, messages can come out of order - at which point = the meaning of options with respect to that order has to be defined. That= =E2=80=99s a can of worms and completely independent of whether aggregated = options are supported.

if you are meaning options not appeared in SYN cannot be used in= the following segments, I think accecn option might be a precedent=C2=A0fo= r this.=C2=A0=C2=A0

Accecn may not a= ppear in an option explicitly, but it is communicated using SYN flags. That= =E2=80=99s very close to what the compressed options achieves.
I.e., the option value itself need not appear in the SYN, but = the use of that option *is* signaled using the SYN/SYN-ACK, either way.

Again, doing that negotiaton after the TWHS is a sepa= rate and more complex issue that I believe should be defined for each optio= n (even if you want to define it for a separate post-SYN aggregate option);= it can=E2=80=99t be generalized for existing options.

OK. I think I understand your viewpoints. Thanks fo= r the explanation.
However, I still have different views on them.= =C2=A0
I've re-read the mptcp specs, but, the design of optio= n negotiation scheme in the doc looks to me not mptcp-specific and simply a= ims to exchange additional info reliably.=C2=A0
Also, I still thi= nk it's possible to combine aggregate option and delayed negotiation sc= heme. It can be separated, but I don't see issues even if it's comb= ined.

But, anyway, at this point I don't think= I have enough evidence=C2=A0to convince you.=C2=A0
I will think = about this further. Also, if possible, I would like to hear other people= 9;s options.

Thanks,
--
Yoshi<= /div>
--000000000000065b5705bb85c764-- From nobody Wed Feb 17 08:25:29 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478473A1BDA; Wed, 17 Feb 2021 08:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEmJfzqQg-cc; Wed, 17 Feb 2021 08:25:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 245FF3A1B7A; Wed, 17 Feb 2021 08:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613579115; bh=Ce3Z1B8FpDZFmhx9aEbhyZMjLY+5N2FYzFCSjpYaqPI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=WwWerrriTffuUzkwwFzFgdvrx5PX/EFN5rp5GCvGBiHPmi5/Eo4i3Yz7qwfsLw3pa bhdk8CfPToZJBFvoxMUtZ3cTebdF7NcS5sNfzB2YCgySfnyaniqsolYoz9wTsVvvbk 97hddQUkiXxjtqa0+yqdwkSw8gBkTU50qSXpweZo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.131.45]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJE6L-1lS1Tc2cW3-00KdCk; Wed, 17 Feb 2021 17:25:15 +0100 To: tcpm@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org References: <161350762933.6467.7665402654665318814@ietfa.amsl.com> From: "Scheffenegger, Richard" Message-ID: <319a9c3f-b616-bdbc-a6bc-a8de6924654e@gmx.at> Date: Wed, 17 Feb 2021 17:25:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <161350762933.6467.7665402654665318814@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8cj6+wB7yUTvfB9vhtYW4jc1xRLwKMtDvPE04XIlNXR75hOI34M 5/3CtfP6/rHIiJZstH89ND2fPYA1k1oSzvIwDMzZ8vgTKFj1GwYCu7iwklpLOP/qZk3yySn DEp6Ifa2zbzKTBIKMBEGrLBUiRmpiOPqNSrdWo+agqxzrmryJq5VNe148IahTFjjI/o/thT fNvCXZYsTa+H8SPmBkhVA== X-UI-Out-Filterresults: notjunk:1;V03:K0:492gf4YN/mI=:FENbia7SvaivsSFQtnsTeI WiUwqLVIuJk9Ym0lSlso7WMsj5enuh7M0mgKl7eFZXah6lC1uo8QmMJ3jFifK/Kv1abgQ2as8 4mzJ8WLU6HDztwp1YQQ6jJK+jXDrhaFEeucBNBde+sw+mbB/9C59PNHXhnqMV0+8RD03aGoB1 Ux/NEwASfIrt0ZTp2xKGuGlDRbbSfndqIX/J6DASDFpx1RFByOPSPjhn5NdaWHc7VBMnClLqi XiRqyucG9faVF5Ve20qDAR7jW4uPqRcLVj1BW6sVwLYMGQDeIzY30qIu3UyY1M2SefzopCM7+ Jpdd4zzt5CtLUhAmVYE5QnY84UCYhBAEz7JNzXa27wDtqXWyH1dIKLRbQ5MAphqPsnkiTnP5i 1UCJ1AS9Fb7IwFwb4Mj/6VacPpcjJPg3w74Uj1wJeZnc2/p8RiTmTi9Y13mxhUdxRKdW6tEt+ g9CmNqzWvsbrvaR6mz4bzpmbq647uQG3aL/HaxT9FKrvc0Jq5WxL7D/TIsGoO9YXySuztzA5x EJ/dTt5NI+Goi8X1WDVoI4KGAP0DEQiVb90e4IM5OZovKpu5sXNeJwEoojf1NPiA/BmH07pEr wwZIVueisCC60kOUxNlccpIb7o4VkwBqhqOfc+9CitwS4gvnlV+aq91nmMauAlrOfvCR/j1Cb CbtInXfNLWNniEDYTIXo6JF0hdd08Smq5DLVM/SqVN/pDINQP616egDUQ9G48NCfxCkTeKSco y2Gs1e24BhY/Obgy9tHCX6FJsmaS7bIfxWisHnV5+iOenc13YDCBMKkITjNmmZkPrDJGt8gJG 2iM/L+M3eSNWiXXrbOsdbgKenEgWoEdrB4z4Q/JAA/7PCjOZIj28MrtS/XO1P60e36zBHmhPV udkrPrQhcUBWKe5Dzsjw== Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 16:25:27 -0000 Bob, thank you for the update. I've read the new version, and believe the updated wording does improve the readability. Also, I like seeing the updated references and measurements. Best regards, Richard Am 16.02.2021 um 21:33 schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG= of the IETF. > > Title : ECN++: Adding Explicit Congestion Notificatio= n (ECN) to TCP Control Packets > Authors : Marcelo Bagnulo > Bob Briscoe > Filename : draft-ietf-tcpm-generalized-ecn-07.txt > Pages : 47 > Date : 2021-02-16 > > Abstract: > This document describes an experimental modification to ECN when use= d > 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-07 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-generalized-ecn-07 > > > Please note that it may take a couple of minutes from the time of submis= sion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Feb 17 08:47:20 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF6D3A1B64 for ; Wed, 17 Feb 2021 08:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuLnejcmRcc7 for ; Wed, 17 Feb 2021 08:47:15 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id ACD113A1B67 for ; Wed, 17 Feb 2021 08:47:15 -0800 (PST) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0CA031B001D6; Wed, 17 Feb 2021 16:47:08 +0000 (GMT) To: tcpm IETF list Cc: Mirja Kuehlewind , Bob Briscoe References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> <95ACEF0A-61F9-44E7-8BD9-8C1FADCD2583@strayalpha.com> From: Gorry Fairhurst Message-ID: <9167ba8a-dd99-7af1-3559-b4993a73d9b2@erg.abdn.ac.uk> Date: Wed, 17 Feb 2021 16:47:07 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [tcpm] Coming back to my comments on AccECN wrt ACK Filtering X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 16:47:19 -0000 Bob, After the last IETF I promised to try simplify the comment on the new ACK Filtering text in ACCECN. I've included what the current draft says, and marked comments in the text as ">GF>" to try and be more specific about which words attracted the alst round of feedback: 3.3.3.  Requirements for TCP ACK Filtering    A node that implements ACK filtering (aka. thinning or coalescing)    and itself also implements ECN marking will not need to filter ACKs    from connections that use AccECN feedback.  Therefore, such a node    SHOULD detect connections that have negotiated the use of AccECN    feedback during the handshake (see Table 2) and it SHOULD preserve    the timing of each ACK (if it coalesced ACKs it would not be AccECN-    compliant, but the requirement is stated as a "SHOULD" in order to    allow leeway for pre-existing ACK filtering functions to be brought    into line). >GF> What does that "SHOULD" really mean? As far as I know, many devices that have RFC3449-like behaviours operate over links that have some specific property that changes the packet timing (perhaps half-duple; or transmission aligned to assigned time slots, or whatever). I therefore don’t understand “preserve timing”.    A node that implements ACK filtering and does not itself implement    ECN marking does not need to treat AccECN connections any differently    from other TCP connections. Nonetheless, it is RECOMMENDED that such    nodes implement ECN marking and comply with the requirements of the    previoius >GF> Typo     paragraph.  This should be a better way than ACK filtering    to improve the performance of AccECN TCP connections.    The rationale for these requirements is that AccECN feedback provides    sufficient information to a data receiver for it to be able to    monitor ECN marking of the ACKs it has sent, so that it can thin the    ACK stream itself.  This will eventually mean that ACK filtering in    the network gives no performance advantage.  Then TCP will be able to    maintain its own control over ACK coalescing.  This will also allow    the TCP Data Sender to use the timing of ACK arrivals to more    reliably infer further information about the path congestion level. >GF> /This will eventually mean/This might eventually mean/:  because I think tis is an aspiration and maybe some nodes can use ECN to control ACK feedback, but is this always true? Given that link transmission can be very variable, and in the case of ACKs often becomes a limit per-packet rather than per-byte for typical data packets, I’m unsure how the implementation of ECN-marking against a variable jitter/capacity would interact with the capacity fluctuations from sharing media, or other physical layer propagation variations. I suggest this is an ambition rather than it necessarily being true that this will be better than any ACK Filtering method or FQ-style mitigation.    Note that the specification of AccECN in TCP does not presume to rely    on the above ACK filtering behaviour in the network, because it has    to be robust against pre-existing network nodes that still filter    AccECN ACKs, and robust against ACK loss during overload.    Section 5.2.1 of [RFC3449] gives best current practice on ACK    filtering (aka. thinning or coalescing).  It gives no advice on ACKs    carrying ECN feedback,  because at the time is said that "ECN remain    areas of ongoing research".  This section updates that advice for a    TCP connection that supports AccECN feedback. >GF> RFC3449 does however already note:    “Appropriate treatment is also needed to preserve correct operation of ECN feedback (carried in the TCP header) [RFC3168].“, which you could say you are now expanding upon. >GF> I think the next section also hekps explains why ACK Filtering is less needed, if a sender uses offload, and reduces its ACK rate, then the -albeit *slightly* larger- AccECN ACKs are less frequent, and therefore can be expected to be less problematic. Gorry From nobody Thu Feb 18 06:00:14 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013F33A1252; Thu, 18 Feb 2021 06:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A-bHuv62hD6; Thu, 18 Feb 2021 06:00:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952543A1234; Thu, 18 Feb 2021 06:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613656798; bh=X6is0+chGoqTDkd592HUcfHPYmE2EsGTVt0zRVzOYFc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fy98eXIXBe5rEFb4kd8MOpApXFBFh9YjwPpbhcy34eaHztlx/gnTVMn7wy8RjP12v LtPNL2r8xq7ud13bnPU9lp6ZmgewH9wRGKNILwQzs+4IPFRwfe1iUDr/bZjb/SkWDC vRzjrADrk5qdCm6g3E0D+mM9K340xMleCduJMkZA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.106] ([185.236.167.136]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6lpG-1lDHXM0PBG-008I0T; Thu, 18 Feb 2021 14:59:58 +0100 To: Markku Kojo , Michael Scharf , Wesley Eddy , tuexen@fh-muenster.de Cc: tcpm IETF list References: From: "Scheffenegger, Richard" Message-ID: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> Date: Thu, 18 Feb 2021 14:59:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:MSE/j3iiDDuCb+KV2dLCrhNtTLyIDcG6nYJpfNPsoJeFFUcipbY EnxG+W95TUoG6YMLshRRsZoJbY8yexYE5+OnJFa7faiCXyl2v+yKx21Fn0HGmE8cmZZHPw7 k0Sc5HdqA2LydX71bRezkheYbRDm+ZKLqkppAgpr0/+HBUtJgmbJZBnos03SIKJ4WVD7EWZ U7YsR5Z3/WGcGv8zCenrg== X-UI-Out-Filterresults: notjunk:1;V03:K0:7ALn6zMJ6tM=:RQmLw7XUi1SFWCbw32FIEb CWa7xbvzf7aEqHkDpBRpAxHMbmoOFqapLo92h8R5fKy0z66DrGvs03VCHHpUDX9ydbna5pF6y lZLSFBCts11OyLx56LsEPwuwrgtXc72pdT7fOZE5pRBT+ihhy6D1c7BoQPq4PkE/81+GMnCdK 5C0/qRczAJAum+rJ0G0lwUOLx7XeqQcUtXss0tDbZ7Q2XOnWze5NWuQMg+t8U/zQJRLvUIS9c AS+NUUGJeNIwK0VRht5uxBGUog4jsYQVEZDVXaxrGEI4cGbijT0rkp0GQyavjICkfYrgCAm5o /TCk3BaBAjaNhqMtszQV1mmJKZtDCAOZ1+WcQBWhQjEnjkq4/7gKpTZiwbW/o35U10VMj12G/ jQSuyRLTrqEW0r4yeI/kBmHUd1UNE4eJ7JM2oe+U6Qjy4uffVCYNcSDMp0Oh3bNO+TF8g3W1V 7OduDb9rWOoneg8LqF3Ib7Vbs/lWLt8VBN0uphzzZEXMnxHIEzgcuKlW8KP91qHW+RFW3pgLR Q6q0gH81alWMUPwPlTO8++oZ/yF/drIyIzu3qstIbQELLrYv1gfHA4xxq7eXIHySARvQD5/eB zvYuzBLfLf+I8gP5zzy66ovQLrVRnSd8wjs5i3IbqQCycx6GEwmHxqHrWCDx/q6HFExdiF7Pr Xi+bOX+3PZ4HoCtVDKY4+ce1GhzUN32e2ICEPPJIO2Tg6ZwatZVjnLcunt0Lm7PYRBf+6JslL pY/dhkBiMcp9W5Hy+RzLqkp9YSzYzfotlBLDNJ8wEPaL6KE+wzXuQrG4qQfYWN0V+4azZoaEl HF2dCkJIPL9d5Wgpt33+0RG3bmt5J87c/IRl6aJqgBzQnI7AteFsbrhMoQFg+hoMk2vtzdPnH P9ImHERkOk4JHhFxeg1Q== Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 Feb 2021 14:00:12 -0000 One more nit, around dealing with data-in-SYN,ACK 793bis (page 71) has this text, which unfortunately doesn have any RFC2119 language. But in short, it seems to require the transmission of a pure ACK just for the SYN bit, and a 2nd ACK right afterwards (step 6) to acknowledge the data. The FBSD implementation was found to skip over the ACK-only-the-SYN intermediate step (which must be acceptable, as that ACK may get lost in the network), sending out only the cummulative ACK for SYN and data, after having transitioned into ESTABLISHED. But strictly speaking, this behavior is a deviation from 793 / 793bis. Perhaps a "and should send it" would do, to allow this behavior, conserving one pure ACK... Best regards, Richard If the state is SYN-SENT then first check the ACK bit If the ACK bit is set : : fourth check the SYN bit This step should be reached only if the ACK is ok, or there is no ACK, and it the segment did not contain a RST. If the SYN bit is on and the security/compartment is >>> acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there is an ACK), and any segments on the retransmission queue that are thereby acknowledged should be removed. If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment >>> and send it. Data or controls that were queued for transmission may be included. If there are other controls or text in the segment then continue processing at the sixth step below where the URG bit is checked, otherwise return. From nobody Fri Feb 19 09:44:07 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F923A1377 for ; Fri, 19 Feb 2021 09:43:58 -0800 (PST) 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 4IZNk2bzjokj for ; Fri, 19 Feb 2021 09:43:57 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209B63A1383 for ; Fri, 19 Feb 2021 09:43:45 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id x20so2931430oie.3 for ; Fri, 19 Feb 2021 09:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R17y+bZMLZRdujSFKn4I/AxOKmb+JsJ/1TW7iVvuHB8=; b=Z3DTb8yb2gLeniBDdcqpGYCWCecmZ1vY4OvmhzxrGhI/P3eDc4Hubfl23NYdoAjB6O xMMWFPaJTfUWpvrZyLXP1UsUfFi17RjX4ckiZFUOtgVEpxby90gZbUyWBNjFMeFp1v1i 6Kq5adhxY5MTls2KU+dLxbcVYN1ftBwyJqal05r9lsErukpZ0/b3an8pxNsNNL+O+zS7 yf1ExZJzpWHMx9McyFx5Qu0EUqajpcZayaMWwwMAlb2iNYy9UC/2yvt/uoL+Iq6GlUeK 2OJeFza3WgAwU1MYnbCuOY1lfE3rXJBS9RGTrjIuI+hN2blItrJdSAL8NoLiEUpRds9d 4SFg== 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=R17y+bZMLZRdujSFKn4I/AxOKmb+JsJ/1TW7iVvuHB8=; b=lJaPdQQzBYQUiPHep1W5F+TkYOJjU5ZilLSVUl2MZ2bgdwp3i0pJ/LmKtDkVLv89lA yA6KfzOfZj9fg6qJj1vWhyqClc4do+LvtIufjoUPqDsGkvIFXg6M65e424rjCSG+fODZ airgl/0dkG2lHNTUsCPCh0ea5qSuvLTmPIy/ynbdUD1VLpoVmHzMChIjVnRIrRnvtikI ZT9gNwsu2lfjbhNfyZ2+3AAbaoq5JveOFGj06E6jERA8KWm7UrH+M5zvH00cpVxohgU8 RbF4/fjb6YXFGPDnN6Q2eaVuPLTan+1GbzGbbJmdkPLU1a4zITFA8Br/bvs+gtud7IYM vqxA== X-Gm-Message-State: AOAM533xBpamLdBU+gC25nYHiONdY7tMD6AusmSkyeYrnsbz+7PFGf8Z dlyN46vRbtiL1hlbsHTC6v4kOOxpuBG0O13OLZ4= X-Google-Smtp-Source: ABdhPJwArC790DcG/Tl0HhhK8MGH9YNAWPKFLxXEfcBjln6L6gaxbMKwCpT5dDBYP7DLn+NWWS8bVuQQoyWVUUb8ZmY= X-Received: by 2002:a05:6808:b1a:: with SMTP id s26mr7458477oij.128.1613756624397; Fri, 19 Feb 2021 09:43:44 -0800 (PST) MIME-Version: 1.0 References: <2F8FD4F6-2DEC-4780-8A6F-57A5879D90B0@apple.com> In-Reply-To: <2F8FD4F6-2DEC-4780-8A6F-57A5879D90B0@apple.com> From: Alexander Azimov Date: Fri, 19 Feb 2021 20:43:33 +0300 Message-ID: To: Vidhi Goel Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000059e68205bbb3fe34" Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM@IETF110 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:44:04 -0000 --00000000000059e68205bbb3fe34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear chairs, I would like to reserve 15 minutes to discuss the RTO-dependent flow label generation. As far as I know, there is no document at the moment. =D0=B2=D1=82, 9 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 13:13, Vidhi = Goel : > Hello TCPM chairs, > > We would like to present the updates to CUBIC RFC 8312 which includes all > the algorithmic changes based on current industry best practices. > > * Title and draft name > > Updates to CUBIC RFC 8312 - draft-eggert-tcpm-rfc8312bis-01 > > * Presenter's name > > Vidhi Goel > > * Total time (including Q/A) > > 15 mins > > > Thanks, > Vidhi > > On Feb 9, 2021, at 12:52 AM, Yoshifumi Nishida wrote= : > > Hello, > > As it's shown in the current agenda ( > https://datatracker.ietf.org/meeting/110/agenda.html) we are planning to > have a WG meeting on March 12 (Fri) 12:00 - 14:00 UTC. > If you are planning to present something, please let the chairs know the > following information by Feb 21. > > * Title and draft name > * Presenter's name > * Total time (including Q/A) > > BTW, please note that the current schedule is still preliminary and might > be changed. > > Thanks, > -- > tcpm co-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 > --=20 Best regards, Alexander Azimov --00000000000059e68205bbb3fe34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear chairs,

I would like to reserve 15= minutes to discuss the RTO-dependent flow label generation.=C2=A0
As far as I know, there is no document at the moment.

=D0=B2=D1=82, 9 = =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 13:13, Vidhi Goel <vidhi_g= oel=3D40app= le.com@dmarc.ietf.org>:
Hello TCPM chairs,

We would like to = present the updates to CUBIC RFC 8312 which includes all the algorithmic ch= anges based on current=C2=A0industry best = practices.
* Title and draft name
Updates to CUBIC RFC 8312 - draft-eggert-tcpm-rfc8312bis-01
=
* Presenter's name
=
Vidhi Goel

*= Total time (including Q/A)
15 mins


Thanks,
Vidhi

On Feb 9, 2021, at 12:52 AM, Yoshifumi Nishida <nsd.ietf@gmail.com>= wrote:

Hello,

As it's shown in t= he current=C2=A0agenda=C2=A0(https:= //datatracker.ietf.org/meeting/110/agenda.html) we are planning to have= a WG meeting on March 12 (Fri) 12:00 - 14:00 UTC.
If you are planning t= o present something, please let the chairs know the following information b= y Feb 21.

* Title and draft name
* Presenter's name
* Tota= l time (including Q/A)

BTW, please note that the current schedule is= still preliminary and might be changed.=C2=A0

Thanks,
--
tcpm co-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


--
Best regards,
Alexander Azimov
--00000000000059e68205bbb3fe34-- From nobody Fri Feb 19 10:51:05 2021 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 D0F5B3A1352; Fri, 19 Feb 2021 10:50:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Theresa Enghardt via Datatracker To: Cc: draft-ietf-tcpm-2140bis.all@ietf.org, last-call@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161376065979.10659.16021515616726523967@ietfa.amsl.com> Reply-To: Theresa Enghardt Date: Fri, 19 Feb 2021 10:50:59 -0800 Archived-At: Subject: [tcpm] Genart last call review of draft-ietf-tcpm-2140bis-09 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, 19 Feb 2021 18:51:00 -0000 Reviewer: Theresa Enghardt Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tcpm-2140bis-09 Reviewer: Theresa Enghardt Review Date: 2021-02-19 IETF LC End Date: 2021-02-22 IESG Telechat date: Not scheduled for a telechat Summary: This document is fairly clear and concise, however there are a few minor issues and nits that should be addressed before publishing. Major issues: None. Minor issues: Abstract: "This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability." I think it'd be good to clarify what "steady-state operation" or "steady-state behavior" means in this context, either here or in the introduction where this term is used again. Assuming both terms refer to the same concept, please consider unifying the terms. Introduction: "Path information shared across SYN destination port numbers assumes that TCP segments having the same host-pair experience the same path properties, irrespective of TCP port numbers." Does this mean that one should rather avoid sharing information between connections with different SYN destination port numbers? If there is a recommendation, I think it'd be good to be explicit about it. If no recommendation is being made, maybe the doc should state that these are assumptions that implementers should be aware of. I think it's also worth noting that, even if connections share the same host-pair and SYN destination port numbers, paths and path conditions can always change over time. It'd be good to put in a reference to Section 8.1 here, where there's more discussion about these assumptions. 4. The TCP Control Block (TCB) As Appendix B mentions that it may be unsafe to share other state, perhaps it's good to add a sentence about this here and refer to Appendix B for more details. "One class is clearly host-pair dependent (#, e.g., MSS, MMS, PMTU, RTT)..." Please consider adding a brief explanation why it's "clearly" host-pair dependent. Discussion on this could also be added to Section 8.1 and then refered to here. Also, isn't this information path-dependent rather than host-dependent? If the doc is making an assumption about host pairs and paths here, please make it explicit. 6.1 Initialization of the new TCB In the table "TEMPORAL SHARING - TCB Initialization", "or not cached" is added for old_MMS_S and old_MMS_R, but not for other information in this table. Please consider adding a brief explanation and/or clarifying this point here. Is there any notion on information being outdated or expiring, as path conditions might change over time? "Note that PMTU feedback is cached at the IP layer" - Is this true even with PLPMTUD? I think it's worth putting in a brief clarification of whether this depends on the mechanism, as PMTUD and PLPMTUD are explicitly introduced in Section 3. 7.2. Updates to the new TCB Here, the row with old_PMTU and curr_PMTU says "PMTUD+ / PLPMTUD". In Section 6.2, a similar row only says "PMTUD+". Is this intentional, i.e., with PLPMTU, can PMTU only be shared with Temporal Sharing and not with Ensemble Sharing? 8. Compatibility Issues What kind of compatibility is meant here? Is it compatibility between implementations? If not, please consider renaming this section, e.g., to "Issues with TCB information sharing". 8.1. Traversing the same network path "When TCB information is shared across different SYN destination ports, path-related information can be incorrect" Please consider adding an explanation here. Why is this true specifically for SYN destination ports? 11. Updates to RFC 2140 "addressing RSS in both the send and receive direction" RSS is not defined in this doc. 12. Security Considerations "These presented implementation methods do not have additional ramifications for explicit attacks." What are explicit attacks, and are denial-of-service attacks not explicit? "TCB sharing may be susceptible to denial-of-service attacks […]" Please consider clarifying the attack scenario here: Is it that an attacker opens many connections, and then each new connection gets state from the other ones, so the denial-of-service attack's impact is increased due to TCB sharing? Is there a potential for a denial-of-service attack preventing TCB sharing? Can there be any privacy implications of sharing connection state, e.g., between connections of different applications, or within the same application such as between browser tabs? Nits/editorial comments: 3. Terminology: Some terms appear to be named inconsistenly: MMS_S uses "_S" suffix, but sendMSS uses "send" prefix to denote send direction. Can these be unified? There is a definition for both "cwnd" and "sendcwnd". Are these the same? Later, Section 4 uses "snd_cwnd". Should this be "sendcwnd" instead? Typo: "to discovery the PMTU" → "to discover the PMTU" RWIN is spelled in all-caps, cwnd is lower case. Can these be unified? 6.3 Discussion "Caching MMS_R and MMS_S may be of little direct value as they are reported by the local IP stack anyway." The same statement has already been made at the very beginning of this subsection. Please consider removing the redundant statement. For a better overview, maybe it would help if these discussion points/considerations were grouped by the TCB value being discussed, and possibly provided as a list? 7.3 Discussion "Current TCP implementations initialize it to four segments as standard [rfc3390] and 10 segments experimentally [RFC6928]." Duplicate information - the same statement has already been made in the previous paragraph. Please consider removing the redundant statement and/or restructuring the text here. From nobody Sat Feb 20 12:56:12 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AC73A0CD3 for ; Sat, 20 Feb 2021 12:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665, 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 MfJ2-wTDzXvM for ; Sat, 20 Feb 2021 12:56:06 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B353A0CCC for ; Sat, 20 Feb 2021 12:56:06 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510] (unknown [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6E1E372246348; Sat, 20 Feb 2021 21:56:01 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: tuexen@fh-muenster.de In-Reply-To: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> Date: Sat, 20 Feb 2021 21:56:00 +0100 Cc: Markku Kojo , Michael Scharf , Wesley Eddy , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Feb 2021 20:56:11 -0000 > On 18. Feb 2021, at 14:59, Scheffenegger, Richard = wrote: >=20 > One more nit, around dealing with data-in-SYN,ACK >=20 > 793bis (page 71) has this text, which unfortunately doesn have any > RFC2119 language. >=20 > But in short, it seems to require the transmission of a pure ACK just > for the SYN bit, and a 2nd ACK right afterwards (step 6) to = acknowledge > the data. >=20 > The FBSD implementation was found to skip over the ACK-only-the-SYN > intermediate step (which must be acceptable, as that ACK may get lost = in > the network), sending out only the cummulative ACK for SYN and data, > after having transitioned into ESTABLISHED. Hi, I really prefer the FreeBSD behaviour. A TCP stack should not need to = send two segments at the same time when handling the event of a single = segment reception. Best regards Michael, as an individual >=20 > But strictly speaking, this behavior is a deviation from 793 / 793bis. >=20 > Perhaps a "and should send it" would do, to allow this behavior, > conserving one pure ACK... >=20 > Best regards, > Richard >=20 >=20 >=20 > If the state is SYN-SENT then >=20 > first check the ACK bit >=20 > If the ACK bit is set > : > : > fourth check the SYN bit >=20 > This step should be reached only if the ACK is ok, or there > is no ACK, and it the segment did not contain a RST. >=20 > If the SYN bit is on and the security/compartment is > >>> acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set = to > SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if > there is an ACK), and any segments on the retransmission > queue that are thereby acknowledged should be removed. >=20 > If SND.UNA > ISS (our SYN has been ACKed), change the > connection state to ESTABLISHED, form an ACK segment >=20 > >>> >=20 > and send it. Data or controls that were queued for > transmission may be included. If there are other controls > or text in the segment then continue processing at the sixth > step below where the URG bit is checked, otherwise return. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Feb 20 13:37:57 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992F43A0DC0 for ; Sat, 20 Feb 2021 13:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 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, HAS_X_OUTGOING_SPAM_STAT=2.339, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 L5iGaZEtrWHE for ; Sat, 20 Feb 2021 13:37:54 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809ED3A0DBC for ; Sat, 20 Feb 2021 13:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FWmRKMfox2tFV8Pwrm8nbAriiOZxTOCgF0gLX+BK0Os=; b=cRKBvquqpv7Jq/tc5vruReDPm /EWUbIAK1TMATfH3pn8T85nGXshsNq7uUjzrZGOd8sKPeUKTmyOhAqMX5wZo3Ag+BW2vaE+27nj5G KAm36yubcuz/RjVz7iNtrpM0zQwtswmo/rtVJxUZF9v6de+tm/0lA7HTWhiwQqgbK5W7P6r595XbT WgD6MqrIs7/3ipAjyGwHjWCThkrZ3VtrrIPKrth0/3kzUTDDZhc5nEE8wm+1IMX+MYHh9cqCUJYd8 R6aTdlQ7sF4bBwYbBkfFLQbBzXuYv1wlxrtJTnOYtaU5oiPuUmAic0qUIX3oQVKKJFzwopdrIDLUA 3HlOWWyJA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55515 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 1lDZwi-001rJ0-BO; Sat, 20 Feb 2021 16:37:53 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> Date: Sat, 20 Feb 2021 13:37:47 -0800 Cc: "Scheffenegger, Richard" , tcpm IETF list , Markku Kojo Content-Transfer-Encoding: quoted-printable Message-Id: <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> To: Michael Tuexen X-Mailer: Apple Mail (2.3654.60.0.2.21) 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] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Feb 2021 21:37:56 -0000 Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t = appear to fix this; it will end up sending the SYN-ACK of the received = data *and a second ACK* at the end of the sixth step. Joe > On Feb 20, 2021, at 12:56 PM, tuexen@fh-muenster.de wrote: >=20 >> On 18. Feb 2021, at 14:59, Scheffenegger, Richard = wrote: >>=20 >> One more nit, around dealing with data-in-SYN,ACK >>=20 >> 793bis (page 71) has this text, which unfortunately doesn have any >> RFC2119 language. >>=20 >> But in short, it seems to require the transmission of a pure ACK just >> for the SYN bit, and a 2nd ACK right afterwards (step 6) to = acknowledge >> the data. >>=20 >> The FBSD implementation was found to skip over the ACK-only-the-SYN >> intermediate step (which must be acceptable, as that ACK may get lost = in >> the network), sending out only the cummulative ACK for SYN and data, >> after having transitioned into ESTABLISHED. > Hi, >=20 > I really prefer the FreeBSD behaviour. A TCP stack should not need to = send > two segments at the same time when handling the event of a single = segment reception. >=20 > Best regards > Michael, as an individual >>=20 >> But strictly speaking, this behavior is a deviation from 793 / = 793bis. >>=20 >> Perhaps a "and should send it" would do, to allow this behavior, >> conserving one pure ACK... >>=20 >> Best regards, >> Richard >>=20 >>=20 >>=20 >> If the state is SYN-SENT then >>=20 >> first check the ACK bit >>=20 >> If the ACK bit is set >> : >> : >> fourth check the SYN bit >>=20 >> This step should be reached only if the ACK is ok, or there >> is no ACK, and it the segment did not contain a RST. >>=20 >> If the SYN bit is on and the security/compartment is >>>>> acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to >> SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if >> there is an ACK), and any segments on the retransmission >> queue that are thereby acknowledged should be removed. >>=20 >> If SND.UNA > ISS (our SYN has been ACKed), change the >> connection state to ESTABLISHED, form an ACK segment >>=20 >>>>> >>=20 >> and send it. Data or controls that were queued for >> transmission may be included. If there are other controls >> or text in the segment then continue processing at the sixth >> step below where the URG bit is checked, otherwise return. >>=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 Sat Feb 20 13:53:47 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532F3A0E2A for ; Sat, 20 Feb 2021 13:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_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 asfiUP67mGbl for ; Sat, 20 Feb 2021 13:53:43 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0EC23A0E2E for ; Sat, 20 Feb 2021 13:53:42 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510] (unknown [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 703D472246348; Sat, 20 Feb 2021 22:53:38 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Michael Tuexen In-Reply-To: <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> Date: Sat, 20 Feb 2021 22:53:38 +0100 Cc: tcpm IETF list , Markku Kojo Content-Transfer-Encoding: quoted-printable Message-Id: <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> To: Joseph Touch X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Feb 2021 21:53:45 -0000 > On 20. Feb 2021, at 22:37, Joseph Touch wrote: >=20 > Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t = appear to fix this; it will end up sending the SYN-ACK of the received = data *and a second ACK* at the end of the sixth step. I think the idea of Richard is that if the text is If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment and should send it. Then NOT following the should, but only send the ACK at the end of step = 6. Wouldn't that work? Best regards Michael >=20 > Joe >=20 >> On Feb 20, 2021, at 12:56 PM, tuexen@fh-muenster.de wrote: >>=20 >>> On 18. Feb 2021, at 14:59, Scheffenegger, Richard = wrote: >>>=20 >>> One more nit, around dealing with data-in-SYN,ACK >>>=20 >>> 793bis (page 71) has this text, which unfortunately doesn have any >>> RFC2119 language. >>>=20 >>> But in short, it seems to require the transmission of a pure ACK = just >>> for the SYN bit, and a 2nd ACK right afterwards (step 6) to = acknowledge >>> the data. >>>=20 >>> The FBSD implementation was found to skip over the ACK-only-the-SYN >>> intermediate step (which must be acceptable, as that ACK may get = lost in >>> the network), sending out only the cummulative ACK for SYN and data, >>> after having transitioned into ESTABLISHED. >> Hi, >>=20 >> I really prefer the FreeBSD behaviour. A TCP stack should not need to = send >> two segments at the same time when handling the event of a single = segment reception. >>=20 >> Best regards >> Michael, as an individual >>>=20 >>> But strictly speaking, this behavior is a deviation from 793 / = 793bis. >>>=20 >>> Perhaps a "and should send it" would do, to allow this behavior, >>> conserving one pure ACK... >>>=20 >>> Best regards, >>> Richard >>>=20 >>>=20 >>>=20 >>> If the state is SYN-SENT then >>>=20 >>> first check the ACK bit >>>=20 >>> If the ACK bit is set >>> : >>> : >>> fourth check the SYN bit >>>=20 >>> This step should be reached only if the ACK is ok, or there >>> is no ACK, and it the segment did not contain a RST. >>>=20 >>> If the SYN bit is on and the security/compartment is >>>>>> acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to >>> SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if >>> there is an ACK), and any segments on the retransmission >>> queue that are thereby acknowledged should be removed. >>>=20 >>> If SND.UNA > ISS (our SYN has been ACKed), change the >>> connection state to ESTABLISHED, form an ACK segment >>>=20 >>>>>> >>>=20 >>> and send it. Data or controls that were queued for >>> transmission may be included. If there are other controls >>> or text in the segment then continue processing at the sixth >>> step below where the URG bit is checked, otherwise return. >>>=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 From nobody Sat Feb 20 18:21:55 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFE53A126C; Sat, 20 Feb 2021 18:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 75sZ8MN7DzxP; Sat, 20 Feb 2021 18:21:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10CF3A1268; Sat, 20 Feb 2021 18:21:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 70330F40744; Sat, 20 Feb 2021 18:21:41 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, tcpm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210221022141.70330F40744@rfc-editor.org> Date: Sat, 20 Feb 2021 18:21:41 -0800 (PST) Archived-At: Subject: [tcpm] =?utf-8?q?RFC_8985_on_The_RACK-TLP_Loss_Detection_Algorit?= =?utf-8?q?hm_for_TCP?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 02:21:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8985 Title: The RACK-TLP Loss Detection Algorithm for TCP Author: Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha Status: Standards Track Stream: IETF Date: February 2021 Mailbox: ycheng@google.com, ncardwell@google.com, nanditad@google.com, priyarjha@google.com Pages: 29 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-rack-15.txt URL: https://www.rfc-editor.org/info/rfc8985 DOI: 10.17487/RFC8985 This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Feb 21 06:33:54 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA55B3A0A02; Sun, 21 Feb 2021 06:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFPeJVM7rADP; Sun, 21 Feb 2021 06:33:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C273A0A0B; Sun, 21 Feb 2021 06:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613918009; bh=8arydKN4Abz82AXJ3ylPiL7prsGqgPk1zKJRucHtTgU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V08lX5ReyZgA8S3QyuKz6U093z/492FMJrw57lIHh9HRTFi5qAUlYWJ0/Yv8jCqYA Ri7OL6PqBBRbcwCD2tXnrcKgQL0+lBDr1lQ15zt0Kx9NbhTTnJjhddzufwYvSm9KYZ xTs8aKNDl7xF8jb44WW/yf29bqm/0mwqVHbXCUgc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([77.119.130.38]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8XPt-1lrl3g0i5B-014Trv; Sun, 21 Feb 2021 15:33:29 +0100 To: Michael Tuexen , Joseph Touch Cc: tcpm IETF list , Markku Kojo References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> From: "Scheffenegger, Richard" Message-ID: <985e67f8-e1b8-36c6-f5a7-cce3f786727e@gmx.at> Date: Sun, 21 Feb 2021 15:33:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:SwCLcYd1p2cuDEUs1meMkE+ymJyyhs9SXRRZIIdAWb8BgPAleUw KEeff+Nh8SuIw5qUL4+f0VO2xgBMRZf507SAsqBpyFMoQWvDds2ASpRLt/ArX7qZkLKWua1 NR28Cq0JVEXleh/yXnwpG7wTSc+GQEuVXv7Sl2fAcP0y+l4d9k/WC+6oUTIdqRuuYfyaK9N aFonUwbCJl8tzXkcwdLFg== X-UI-Out-Filterresults: notjunk:1;V03:K0:XFdx9HvVzgo=:aRONfOH7rc2oXW5rnHW2Dn swVr9gfO7sR6fLdFrgUz8JIq1LDv+O+kK9vWGsiS3HbUZFdYygpc47Gjn+X/gxdnOBN4NXwGA dQZBNDs8S8g5sm2eI6Z3+scjNeTcdAbx5Zs+MBaZjlBapOGQEfHLo9qPcZWSTpLtRb43Sc2kq +twFTsqc2E6dQ4+j/753CMIkYJ+T4TGepXL7+0Acn7AGMbeTs3Mf/N7yv8PBtFeeEatfdgRKO SWqU6zeXQCzVf+H8QcxC0cKYVVWLdkmyhxToUTKF11v27pBE+BnCfHJQI3no42UFPJaRe3pd/ tOANs/OquXpRGnzCFBKFWQTVBIQrWovnXKKRxAglwPUO5eDUU611eKNvH/Dmh731vrb33Ej/r 0vqu6R9+4S1XBUc2teoVDRAdyXz10UGupOYAewofZZ1KnrI90u/X9YgxdjevSc6Qqtv4cPdp1 WpAnhg2SU4KKhn/mnEi/uAwjkdEkzAlU0SGDuW9kU+fLEfu8Dlgufj8I3EwVROyzuP7zExton 2BRoEMKgTgOkJXNoFSUDVm6GnulmqtTV6g4XZCePDTIVLeNbiCb+5VT96Jfwrk0P+7m1EJrZJ CS3Ov1hVSndOg2DJbBG976f+4aWBI/cKP9MNr2hNhpY/4h5GO+Iw0uBp0AGp+BWHcDAFAdJku khLydVDP7R9jaFaWt+thxTduXST/ASvPJb8zU2gjNsuyjGUkWKBnESAjllSgzhHxWjcL14yCl pnwHCFpjhkMUpFBqdYGNkFtzWdecGA9jYkocRcoJlh/FgW2z1dapvIUqAXoP05DH49tHvNXjK 3ISvsfpxQdNL/9kU2sBPhkapMzROj8qAcqgUAYIdVEraxNSiyTgMAuwAYMmsosAZRXIt/RTTN Afu9RSz7XTs/b59At/8w== Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 14:33:53 -0000 Well, making the transmission of the ACK-only-the-SYN optional when data is present, which needs to be ACK'd anyway.. That way, current FBSD and Linux behaviour both would comply with 793bis, while I agree with Michael T. that the behavior of FBSD is more efficient. Richard Am 20.02.2021 um 22:53 schrieb Michael Tuexen: > > >> On 20. Feb 2021, at 22:37, Joseph Touch wrote: >> >> Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t = appear to fix this; it will end up sending the SYN-ACK of the received dat= a *and a second ACK* at the end of the sixth step. > I think the idea of Richard is that if the text is > > If SND.UNA > ISS (our SYN has been ACKed), change the > connection state to ESTABLISHED, form an ACK segment > > and should send it. > > Then NOT following the should, but only send the ACK at the end of step = 6. > Wouldn't that work? > > Best regards > Michael >> >> Joe >> >>> On Feb 20, 2021, at 12:56 PM, tuexen@fh-muenster.de wrote: >>> >>>> On 18. Feb 2021, at 14:59, Scheffenegger, Richard wr= ote: >>>> >>>> One more nit, around dealing with data-in-SYN,ACK >>>> >>>> 793bis (page 71) has this text, which unfortunately doesn have any >>>> RFC2119 language. >>>> >>>> But in short, it seems to require the transmission of a pure ACK just >>>> for the SYN bit, and a 2nd ACK right afterwards (step 6) to acknowled= ge >>>> the data. >>>> >>>> The FBSD implementation was found to skip over the ACK-only-the-SYN >>>> intermediate step (which must be acceptable, as that ACK may get lost= in >>>> the network), sending out only the cummulative ACK for SYN and data, >>>> after having transitioned into ESTABLISHED. >>> Hi, >>> >>> I really prefer the FreeBSD behaviour. A TCP stack should not need to = send >>> two segments at the same time when handling the event of a single segm= ent reception. >>> >>> Best regards >>> Michael, as an individual >>>> >>>> But strictly speaking, this behavior is a deviation from 793 / 793bis= . >>>> >>>> Perhaps a "and should send it" would do, to allow this behavior, >>>> conserving one pure ACK... >>>> >>>> Best regards, >>>> Richard >>>> >>>> >>>> >>>> If the state is SYN-SENT then >>>> >>>> first check the ACK bit >>>> >>>> If the ACK bit is set >>>> : >>>> : >>>> fourth check the SYN bit >>>> >>>> This step should be reached only if the ACK is ok, or there >>>> is no ACK, and it the segment did not contain a RST. >>>> >>>> If the SYN bit is on and the security/compartment is >>>>>>> acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to >>>> SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if >>>> there is an ACK), and any segments on the retransmission >>>> queue that are thereby acknowledged should be removed. >>>> >>>> If SND.UNA > ISS (our SYN has been ACKed), change the >>>> connection state to ESTABLISHED, form an ACK segment >>>> >>>>>>> >>>> >>>> and send it. Data or controls that were queued for >>>> transmission may be included. If there are other controls >>>> or text in the segment then continue processing at the sixth >>>> step below where the URG bit is checked, otherwise return. >>>> >>>> _______________________________________________ >>>> 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 Sun Feb 21 10:07:07 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202013A0DFB for ; Sun, 21 Feb 2021 10:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, 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 zNOyZApjB1Tq for ; Sun, 21 Feb 2021 10:07:03 -0800 (PST) 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 0BA8A3A0DF3 for ; Sun, 21 Feb 2021 10:07:02 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510] (unknown [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id BDA9E7220F400; Sun, 21 Feb 2021 19:06:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Michael Tuexen In-Reply-To: <985e67f8-e1b8-36c6-f5a7-cce3f786727e@gmx.at> Date: Sun, 21 Feb 2021 19:06:58 +0100 Cc: Joseph Touch , tcpm IETF list , Markku Kojo Content-Transfer-Encoding: quoted-printable Message-Id: References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> <985e67f8-e1b8-36c6-f5a7-cce3f786727e@gmx.at> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 18:07:06 -0000 > On 21. Feb 2021, at 15:33, Scheffenegger, Richard = wrote: >=20 >=20 > Well, making the transmission of the ACK-only-the-SYN optional when = data > is present, which needs to be ACK'd anyway.. >=20 > That way, current FBSD and Linux behaviour both would comply with > 793bis, while I agree with Michael T. that the behavior of FBSD is = more > efficient. Hi Richard, I'm not sure about your statement about compliance of the Linux stack. My testing show that the following packetdrill scripts succeeds: 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) =3D 3 +0.000 fcntl(3, F_GETFL) =3D 0x2 (flags O_RDWR) +0.000 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) =3D 0 +0.000 connect(3, ..., ...) =3D -1 EINPROGRESS (Operation now in = progress) +0.000 > S 0:0(0) win 64240 +0.050 < S. 0:512(512) ack 1 win 65535 +0.000 > . 1:1(0) ack 1 win 64240 +0.000 recv(3, ..., 1024, 0) =3D -1 EWOULDBLOCK (Operation would block) +0.000 close(3) =3D 0 +0.000 > F. 1:1(0) ack 1 win 64240 +0.000 < F. 1:1(0) ack 2 win 65535 +0.000 > . 2:2(0) ack 2 win 64239 This means that the data on the SYN-ACK is simply dropped. I don't think this is the handling described in RFC 793. MacOS handles the case similar to FreeBSD. Best regards Michael=20 >=20 > Richard >=20 > Am 20.02.2021 um 22:53 schrieb Michael Tuexen: >>=20 >>=20 >>> On 20. Feb 2021, at 22:37, Joseph Touch = wrote: >>>=20 >>> Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t= appear to fix this; it will end up sending the SYN-ACK of the received = data *and a second ACK* at the end of the sixth step. >> I think the idea of Richard is that if the text is >>=20 >> If SND.UNA > ISS (our SYN has been ACKed), change the >> connection state to ESTABLISHED, form an ACK segment >> >> and should send it. >>=20 >> Then NOT following the should, but only send the ACK at the end of = step 6. >> Wouldn't that work? >>=20 >> Best regards >> Michael >>>=20 >>> Joe >>>=20 >>>> On Feb 20, 2021, at 12:56 PM, tuexen@fh-muenster.de wrote: >>>>=20 >>>>> On 18. Feb 2021, at 14:59, Scheffenegger, Richard = wrote: >>>>>=20 >>>>> One more nit, around dealing with data-in-SYN,ACK >>>>>=20 >>>>> 793bis (page 71) has this text, which unfortunately doesn have any >>>>> RFC2119 language. >>>>>=20 >>>>> But in short, it seems to require the transmission of a pure ACK = just >>>>> for the SYN bit, and a 2nd ACK right afterwards (step 6) to = acknowledge >>>>> the data. >>>>>=20 >>>>> The FBSD implementation was found to skip over the = ACK-only-the-SYN >>>>> intermediate step (which must be acceptable, as that ACK may get = lost in >>>>> the network), sending out only the cummulative ACK for SYN and = data, >>>>> after having transitioned into ESTABLISHED. >>>> Hi, >>>>=20 >>>> I really prefer the FreeBSD behaviour. A TCP stack should not need = to send >>>> two segments at the same time when handling the event of a single = segment reception. >>>>=20 >>>> Best regards >>>> Michael, as an individual >>>>>=20 >>>>> But strictly speaking, this behavior is a deviation from 793 / = 793bis. >>>>>=20 >>>>> Perhaps a "and should send it" would do, to allow this behavior, >>>>> conserving one pure ACK... >>>>>=20 >>>>> Best regards, >>>>> Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> If the state is SYN-SENT then >>>>>=20 >>>>> first check the ACK bit >>>>>=20 >>>>> If the ACK bit is set >>>>> : >>>>> : >>>>> fourth check the SYN bit >>>>>=20 >>>>> This step should be reached only if the ACK is ok, or = there >>>>> is no ACK, and it the segment did not contain a RST. >>>>>=20 >>>>> If the SYN bit is on and the security/compartment is >>>>>>>> acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set = to >>>>> SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if >>>>> there is an ACK), and any segments on the retransmission >>>>> queue that are thereby acknowledged should be removed. >>>>>=20 >>>>> If SND.UNA > ISS (our SYN has been ACKed), change the >>>>> connection state to ESTABLISHED, form an ACK segment >>>>>=20 >>>>>>>> >>>>>=20 >>>>> and send it. Data or controls that were queued for >>>>> transmission may be included. If there are other = controls >>>>> or text in the segment then continue processing at the sixth >>>>> step below where the URG bit is checked, otherwise = return. >>>>>=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 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 From nobody Sun Feb 21 10:38:33 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1CA3A0E65 for ; Sun, 21 Feb 2021 10:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 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, HAS_X_OUTGOING_SPAM_STAT=2.339, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 AM2d-cElom5y for ; Sun, 21 Feb 2021 10:38:30 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499F23A0E63 for ; Sun, 21 Feb 2021 10:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fv6jDAzA6KPTwOWj6bfp6MLrms+uWw0idfYKGGR79ds=; b=iqbwT++RdIFnTx2hu2bysOvaN WvpuTqLwCbuEapJmnecM4EvZcBJ2p4Ro/E5srtcieIgaG2fBzFyN6KdRwS3cx54ZyQ5w6N+/r8gdK KqfTrNZLTeGNJXgsuWRVUCSA2bTKebfuNXw4tMT+LyHFtnSyPvFa7uVYrDBi1zffq+Whw0RrENELt s8+cdOZMR4NYyQU+FOQv2yHbBpC2rQzBCThGmxHBtp5r6yRSaVyTiB6n/GI7SjZA9u4g7O0zYrQAB cjAYragBpQ0iNxOFPNWbqyjnV4cDT2EdTSTRDe6vh4ufRY/GmIVIpxoK5+gOqxkD+iWUScXSeWerT Cy6grhUyA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57299 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 1lDtca-000Fc4-B7; Sun, 21 Feb 2021 13:38:25 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_5C0AE96A-48E8-4243-8FCD-5CEA7D8FD6EF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> Date: Sun, 21 Feb 2021 10:38:19 -0800 Cc: tcpm IETF list , Markku Kojo Message-Id: References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.3654.60.0.2.21) 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] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 18:38:31 -0000 --Apple-Mail=_5C0AE96A-48E8-4243-8FCD-5CEA7D8FD6EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 20, 2021, at 1:53 PM, Michael Tuexen = wrote: >=20 >=20 >=20 >> On 20. Feb 2021, at 22:37, Joseph Touch wrote: >>=20 >> Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t = appear to fix this; it will end up sending the SYN-ACK of the received = data *and a second ACK* at the end of the sixth step. > I think the idea of Richard is that if the text is >=20 > If SND.UNA > ISS (our SYN has been ACKed), change the > connection state to ESTABLISHED, form an ACK segment > > and should send it. >=20 > Then NOT following the should, but only send the ACK at the end of = step 6. > Wouldn't that work? FWIW, I think the case of combining the bare ACK with the ACK of the = received SYN-ACK data is already covered in the sixth step below in the = following text: This acknowledgment should be piggybacked on a segment being transmitted if possible without incurring undue delay. If this needs to be made more explicit, here=E2=80=99s my suggestion: OLD: If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment and send it. Data or controls which were queued for transmission may be included. If there are other controls or text in the segment then continue processing at the sixth step below where the URG bit is checked, otherwise return. NEW: If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment Data or controls which were queued for transmission MAY be included in this segment. If there are no=20= other controls or text in the segment then send the ACK segment=20= and return. Otherwise, continue processing at the sixth step = below=20 where the URG bit is checked, either sending the ACK segment now = or=20 piggybacking it with the response from that continued processing (as noted therein). Joe= --Apple-Mail=_5C0AE96A-48E8-4243-8FCD-5CEA7D8FD6EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 20, 2021, at 1:53 PM, Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote:



On 20. = Feb 2021, at 22:37, Joseph Touch <touch@strayalpha.com> wrote:

Even if you prefer the FreeBSD variant, the text below = doesn=E2=80=99t appear to fix this; it will end up sending the SYN-ACK = of the received data *and a second ACK* at the end of the sixth step.
I think the idea of Richard is that if the text = is

=         If SND.UNA > ISS (our = SYN has been ACKed), change the
=         connection state to = ESTABLISHED, form an ACK segment
=         <SEQ=3DSND.NXT><A= CK=3DRCV.NXT><CTL=3DACK>
=         and should send it.

Then NOT following the should, but only send = the ACK at the end of step 6.
Wouldn't that work?

FWIW, I = think the case of combining the bare ACK with the ACK of the received = SYN-ACK data is already covered in the sixth step below in the following = text:

        This acknowledgment =
should be piggybacked on a segment being
        transmitted if possible without incurring undue delay.

If this needs to be made = more explicit, here=E2=80=99s my suggestion:

OLD:

        If SND.UNA > =
ISS (our SYN has been ACKed), change the connection
        state to ESTABLISHED, form an ACK segment

          <SEQ=3DSND.NXT><ACK=3DRCV.NXT><CTL=3DACK>

        and send it.  Data or controls which were queued for
        transmission may be included.  If there are other controls or
        text in the segment then continue processing at the sixth step
        below where the URG bit is checked, otherwise return.


NEW:

        If SND.UNA > ISS (our SYN has been =
ACKed), change the connection
        state to ESTABLISHED, form an ACK segment

          <SEQ=3DSND.NXT><ACK=3DRCV.NXT><CTL=3DACK>

        Data or controls which were queued for
     =
   transmission MAY be included in this segment.  If there are =
no 
	other controls or text in the =
segment then send the ACK segment 
	and =
return. Otherwise, continue processing at the sixth step =
below 
	where the URG bit is checked, =
either sending the ACK segment now or 
	=
piggybacking it with the response from that continued =
processing
	(as noted =
therein).

Joe
= --Apple-Mail=_5C0AE96A-48E8-4243-8FCD-5CEA7D8FD6EF-- From nobody Sun Feb 21 11:15:49 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5F83A0F49 for ; Sun, 21 Feb 2021 11:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, 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 FxdTXVT-AMLx for ; Sun, 21 Feb 2021 11:15:37 -0800 (PST) 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 1B19F3A0EFC for ; Sun, 21 Feb 2021 11:15:36 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:f5a7:3dfe:da1f:48b8] (unknown [IPv6:2a02:8109:1140:c3d:f5a7:3dfe:da1f:48b8]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id C50CD7220F400; Sun, 21 Feb 2021 20:15:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Michael Tuexen In-Reply-To: Date: Sun, 21 Feb 2021 20:15:30 +0100 Cc: tcpm IETF list , Markku Kojo Content-Transfer-Encoding: quoted-printable Message-Id: References: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de> To: Joseph Touch X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 19:15:46 -0000 > On 21. Feb 2021, at 19:38, Joseph Touch wrote: >=20 > On Feb 20, 2021, at 1:53 PM, Michael Tuexen = wrote: >>=20 >>=20 >>=20 >>> On 20. Feb 2021, at 22:37, Joseph Touch = wrote: >>>=20 >>> Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t= appear to fix this; it will end up sending the SYN-ACK of the received = data *and a second ACK* at the end of the sixth step. >> I think the idea of Richard is that if the text is >>=20 >> If SND.UNA > ISS (our SYN has been ACKed), change the >> connection state to ESTABLISHED, form an ACK segment >> >> and should send it. >>=20 >> Then NOT following the should, but only send the ACK at the end of = step 6. >> Wouldn't that work? >=20 > FWIW, I think the case of combining the bare ACK with the ACK of the = received SYN-ACK data is already covered in the sixth step below in the = following text: >=20 > This acknowledgment should be piggybacked on a segment being > transmitted if possible without incurring undue delay. >=20 I agree, this covers it. But it would be good to have it a bit more = explicit. >=20 > If this needs to be made more explicit, here=E2=80=99s my suggestion: >=20 > OLD: >=20 > If SND.UNA > ISS (our SYN has been ACKed), change the = connection > state to ESTABLISHED, form an ACK segment >=20 > >=20 > and send it. Data or controls which were queued for > transmission may be included. If there are other controls or > text in the segment then continue processing at the sixth step > below where the URG bit is checked, otherwise return. >=20 >=20 >=20 > NEW: >=20 > If SND.UNA > ISS (our SYN has been ACKed), change the = connection > state to ESTABLISHED, form an ACK segment >=20 > >=20 > Data or controls which were queued for >=20 > transmission MAY be included in this segment. If there are no=20= > other controls or text in the segment then send the ACK segment=20= Maybe: other controls or text in the received segment then send the = ACK segment=20 > and return. Otherwise, continue processing at the sixth step = below=20 > where the URG bit is checked, either sending the ACK segment now = or=20 > piggybacking it with the response from that continued processing > (as noted therein). I like your proposal (maybe with the above suggestion). Best regards Michael >=20 > Joe From nobody Sun Feb 21 11:39:51 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0F3A1028 for ; Sun, 21 Feb 2021 11:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 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, HAS_X_OUTGOING_SPAM_STAT=2.339, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BoCT2M4hxRDU for ; Sun, 21 Feb 2021 11:39:45 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222EC3A0FFA for ; Sun, 21 Feb 2021 11:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VsgK2cSCN03uxvEtp1wsDRW6Vh47lNqK+T5Rt0RLmjg=; b=GwHE5wq7lulpkBUSMv71jitIIg t+IUIF+olsMRLBdFX4Ro/yOvSgB8x0qnAXdgtkC0ab/OZ2hb4Vo/PFOB5WLML9SU1Bth2XSoHhxBs 4qJ6DKLeq0chZneeLFyfSyOrC2DcCrgq9zcMJ2RGdc3H40jBrp6AZOuW36ux4MHUUCfNUNT6gtksT bSHJjM77Em/3FKwfD31+YVNuHt1w4b+9Yvob/dRP/AzL+iHsNO6eXdpOl8lXCTAT/VilO7eCw1RNg Hh6v57vIycjdeAAp3bfq+XARhCJCp45IVMCsOZKQcb2NISuJyPD+ZLqHdYpQsTLKLWTVC//qDfFz7 dfL845QA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55595 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lDuZr-001Fih-GX; Sun, 21 Feb 2021 14:39:40 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Sun, 21 Feb 2021 11:39:34 -0800 Cc: tcpm IETF list , Markku Kojo Message-Id: <37D123C4-03F5-4D14-84C2-849C5B7B94F1@strayalpha.com> References: To: Michael Tuexen X-Mailer: iPhone Mail (18D52) 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] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 19:39:50 -0000 Works for me.=20 > On Feb 21, 2021, at 11:16 AM, Michael Tuexen wrote: >=20 > =EF=BB=BF >>=20 >> On 21. Feb 2021, at 19:38, Joseph Touch wrote: >>=20 >>> On Feb 20, 2021, at 1:53 PM, Michael Tuexen wrote: >>>=20 >>>=20 >>>=20 >>>> On 20. Feb 2021, at 22:37, Joseph Touch wrote: >>>>=20 >>>> Even if you prefer the FreeBSD variant, the text below doesn=E2=80=99t a= ppear to fix this; it will end up sending the SYN-ACK of the received data *= and a second ACK* at the end of the sixth step. >>> I think the idea of Richard is that if the text is >>>=20 >>> If SND.UNA > ISS (our SYN has been ACKed), change the >>> connection state to ESTABLISHED, form an ACK segment >>> >>> and should send it. >>>=20 >>> Then NOT following the should, but only send the ACK at the end of step 6= . >>> Wouldn't that work? >>=20 >> FWIW, I think the case of combining the bare ACK with the ACK of the rece= ived SYN-ACK data is already covered in the sixth step below in the followin= g text: >>=20 >> This acknowledgment should be piggybacked on a segment being >> transmitted if possible without incurring undue delay. >>=20 > I agree, this covers it. But it would be good to have it a bit more explic= it. >>=20 >> If this needs to be made more explicit, here=E2=80=99s my suggestion: >>=20 >> OLD: >>=20 >> If SND.UNA > ISS (our SYN has been ACKed), change the connection >> state to ESTABLISHED, form an ACK segment >>=20 >> >>=20 >> and send it. Data or controls which were queued for >> transmission may be included. If there are other controls or >> text in the segment then continue processing at the sixth step >> below where the URG bit is checked, otherwise return. >>=20 >>=20 >>=20 >> NEW: >>=20 >> If SND.UNA > ISS (our SYN has been ACKed), change the connection >> state to ESTABLISHED, form an ACK segment >>=20 >> >>=20 >> Data or controls which were queued for >>=20 >> transmission MAY be included in this segment. If there are no=20 >> other controls or text in the segment then send the ACK segment=20 > Maybe: > other controls or text in the received segment then send the ACK s= egment=20 >> and return. Otherwise, continue processing at the sixth step below=20 >> where the URG bit is checked, either sending the ACK segment now or=20= >> piggybacking it with the response from that continued processing >> (as noted therein). > I like your proposal (maybe with the above suggestion). >=20 > Best regards > Michael >>=20 >> Joe >=20 From nobody Mon Feb 22 00:54:46 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA34D3A0FC7 for ; Mon, 22 Feb 2021 00:54:45 -0800 (PST) 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, 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 (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4Aw9cIvkwX7 for ; Mon, 22 Feb 2021 00:54:44 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 3A4C43A0F44 for ; Mon, 22 Feb 2021 00:54:44 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:5c0c:b274:4b3c:19f4] (unknown [IPv6:2a00:ac00:4000:400:5c0c:b274:4b3c:19f4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 5EF1360030D for ; Mon, 22 Feb 2021 10:54:33 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1613984073; bh=az3lI+BBqeavE87SDdy4d7r6U5S3sgCezJ+YLzALvF8=; h=From:Subject:References:To:Date; b=eJCHxW6gZn+KmsL+sNr9qOcFGVF7Ra8GvkhbNBk7lCU5jnSt+u38T+gwo9BTTwdOI a3VZI2OZ01FfpbB33bEuQwB/mCkcI+mYvbqpEOLoE+Gk0T14+9vTyEzqsaoz1rDxWI 52dCQ20qni6m8UjEpMt6e3tIDuA3b0C29TjH0KXc= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_6A125901-1F34-4DDE-8E13-ABC470EC1CD1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> To: tcpm IETF list Date: Mon, 22 Feb 2021 10:54:31 +0200 X-MailScanner-ID: 5EF1360030D.A2FE3 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 08:54:46 -0000 --Apple-Mail=_6A125901-1F34-4DDE-8E13-ABC470EC1CD1 Content-Type: multipart/alternative; boundary="Apple-Mail=_7634A050-EBBA-444C-88C8-2160AE6BA515" --Apple-Mail=_7634A050-EBBA-444C-88C8-2160AE6BA515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we just submitted the -02 version of the CUBIC bis document. This version incorporates the major editorial changes we wanted to make. We'd like to ask the WG to determine if this is ready for adoption. = Vidhi has asked for a presentation slot during IETF-110 for this ID, but = the adoption discussion IMO doesn't need to wait. Thanks, Lars > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-eggert-tcpm-rfc8312bis-02.txt > Date: February 22, 2021 at 10:49:39 GMT+2 > To: "Injong Rhee" , "Lars Eggert" = , "Lisong Xu" , "Sangtae Ha" = , "Vidhi Goel" >=20 >=20 > A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt > has been successfully submitted by Lars Eggert and posted to the > IETF repository. >=20 > Name: draft-eggert-tcpm-rfc8312bis > Revision: 02 > Title: CUBIC for Fast and Long-Distance Networks > Document date: 2021-02-22 > Group: Individual Submission > Pages: 27 > URL: = https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt > Status: = https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/ > Html: = https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html > Htmlized: = https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-eggert-tcpm-rfc8312bis-02 >=20 > Abstract: > CUBIC is an extension to the traditional TCP standards. It differs > from the traditional TCP standards only in the congestion control > algorithm on the sender side. In particular, it uses a cubic > function instead of a linear window increase function of the > traditional TCP standards to improve scalability and stability under > fast and long-distance networks. CUBIC has been adopted as the > default TCP congestion control algorithm by Linux, Windows, and = Apple > stacks. >=20 > This document updates the specification of CUBIC to include > algorithmic improvements based on these implementations and recent > academic work. Based on the extensive deployment experience with > CUBIC, it also moves the specification to the Standards Track, > obsoleting [RFC8312]. >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 --Apple-Mail=_7634A050-EBBA-444C-88C8-2160AE6BA515 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

we just submitted = the -02 version of the CUBIC bis document.

This version incorporates the major editorial changes we = wanted to make.

We'd = like to ask the WG to determine if this is ready for adoption. Vidhi has = asked for a presentation slot during IETF-110 for this ID, but the = adoption discussion IMO doesn't need to wait.

Thanks,
Lars


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-eggert-tcpm-rfc8312bis-02.txt
Date: = February 22, 2021 at 10:49:39 = GMT+2
To: = "Injong Rhee" <injongrhee@gmail.com>, "Lars Eggert" <lars@eggert.org>, = "Lisong Xu" <xu@unl.edu>, "Sangtae Ha" <sangtae.ha@colorado.edu>, "Vidhi Goel" <vidhi_goel@apple.com>


A new version = of I-D, draft-eggert-tcpm-rfc8312bis-02.txt
has been = successfully submitted by Lars Eggert and posted to the
IETF= repository.

Name: = draft-eggert-tcpm-rfc8312bis
Revision: 02
Title:= = CUBIC for Fast and Long-Distance Networks
Document = date: = 2021-02-22
Group: Individual Submission
Pages:= = 27
URL: =            https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02= .txt
Status: =         https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/<= /a>
Html: =           https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02= .html
Htmlized:       https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-eggert-tcpm-rfc8312bi= s-02

Abstract:
=   CUBIC is an extension to the traditional TCP standards. =  It differs
  from the traditional TCP = standards only in the congestion control
=   algorithm on the sender side.  In particular, it uses a = cubic
  function instead of a linear window = increase function of the
  traditional TCP = standards to improve scalability and stability under
=   fast and long-distance networks.  CUBIC has been = adopted as the
  default TCP congestion control = algorithm by Linux, Windows, and Apple
=   stacks.

  This = document updates the specification of CUBIC to include
=   algorithmic improvements based on these implementations and = recent
  academic work.  Based on the = extensive deployment experience with
  CUBIC, = it also moves the specification to the Standards Track,
=   obsoleting [RFC8312].




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

The IETF Secretariat



= --Apple-Mail=_7634A050-EBBA-444C-88C8-2160AE6BA515-- --Apple-Mail=_6A125901-1F34-4DDE-8E13-ABC470EC1CD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmAzcUcACgkQVLXDCb9w wVfDMA/+OmGbqKcxcAa26pwmEi9YgH1wHmXKf2HEWMKbGnchEhIX2iEfFwCuCJX7 0moOyOfjMUU7Ha9u1tKCU/QtAK4yhAkYpt9umDx2IRmWAM+3jOXJJPeszuNmocf/ dCseXOnVdJSguZSKGeH0InNQ5p0aBCMyMCZPIWczVIWsYojIxXQol0SwWCPKTc75 FmJXlzN2wkCym/m47sR115flit2GWWb7lYF9H9TBdDzyZIprt87LdZKdm87WTTDz OhZ/yF18HkD/Zd1pvWNOAi+cuorr/sXJuex5+74XUtzlmsSIFthVfTmYv6AsuzJ4 UWi3euH+FYMFIFm7S1bH8zTLh3rxXXy4kOfh+hgRc//XM7EyR/OwGuut+/67+CdV v1dAkijpN94HJi9iHImysAdqaX6sFQVFbeeMjWKk27Iq1pxiA2CH6PczESv3ctF3 Z432/9aA2cHBCZQieuhgWYTAFrCdkYMuwvAgaRlRj1D1n61ohlU6tFkc6oStMJAn nwQa8t4yLhQJrHjGrvAAXZdIzV0cagedZY2Dk4HPGK1dpmKsIhe2YtOVwcRK7wEe mWioXFhFAVZyl9RdSsHofHcy8Q83CBtdB4ddHxtk9S1QM8rmtzS4rX09dArOtZcP 5swjB8QsW7hJo0mBN7FZrMmRKkuQv5dBK6dHSHeid4zv7OTEHqk= =Em2g -----END PGP SIGNATURE----- --Apple-Mail=_6A125901-1F34-4DDE-8E13-ABC470EC1CD1-- From nobody Mon Feb 22 02:18:02 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84CD3A124F; Mon, 22 Feb 2021 02:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufcCjQ6KzVa0; Mon, 22 Feb 2021 02:17:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 3B12B3A124D; Mon, 22 Feb 2021 02:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613989056; bh=S8Px7+1jL7UAOwjcXBUGL33o+wmLJJTnnuD5REww+ew=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=RkDtDJ4eWwewuh923ciAegjfodh5VRe6ZwF48qvu9JgloUioXVFKofVJsI7/Aan9B uHTvpeeYGmuB3RZ3JRdRdfyMcpwmywd0wwWACxHtacD5HrzZj57oOeJMA9qbskr9Gl NxU+bGnizvPDuYbDfxQl3dyvXBVpECpZDFsNLua0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.129.182]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1Hdq-1lFnFC04zq-002ojn; Mon, 22 Feb 2021 11:17:36 +0100 To: Joe Touch , Michael Tuexen Cc: tcpm IETF list , Markku Kojo References: <37D123C4-03F5-4D14-84C2-849C5B7B94F1@strayalpha.com> From: "Scheffenegger, Richard" Message-ID: <35688a2b-a802-7092-46b8-6e18090123de@gmx.at> Date: Mon, 22 Feb 2021 11:17:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <37D123C4-03F5-4D14-84C2-849C5B7B94F1@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:x/4LuTcQ7e7vEYnT/mxwISoZnBru37i/hmd/At0Q1WU97flz+x4 /z0gtdJHIOk0++Gtduu6ZvXW1y2Tx4Bj5hH7xeNiqkBU4lhE5Etex7DwXFSkgV5IVcg3EOE HwntTQmpmUVq5oJZQaPb3Xx5d9nc34wDN+sj9Rmsj8NjvgU02+LzFwF2E7plwuaZfwx939X WsdsKQFuHc9/C+DQfWfhA== X-UI-Out-Filterresults: notjunk:1;V03:K0:qAvoHa9sEaI=:MgQgjC+IBAojcvmO/tuRmM yjQNtGW8XTtilg55FZHflgtECwTjfKxpgZFbp4UXRw2YqDKO1cpphlqSJsKxAESrtG6gl1BNI LyLZ1h4CrmQPvRYWcTfFbYohWMVH5EZ1UqAcx+ofdFO95DLfkKTdWDJnB2MK/Q9EQqUsXs+86 yvZgrGdcCi2eWtAGcAM6RYnngZ66KQEWgOG9gdHyT0Ql11+olFIoAIL0ALz+wkiI0mMoxm/OW MMYZZw5Urzh2GR7eeSsjSv5Ziskdx+PkeuZfZPjP1Q1xJQaLlybMqpqOpiMCfTBHxRrCwcRz2 fEFzcRNLPVi3yPUYTSLF0Oz7onwcUR9zV+UUIPJVmevOs86HZrA+xiUpyBjqYbXl5190iykNa E/+HeinfzwIaIxeaYajQ6AKQPJCH9d76Q4uBmQ55nRXJO3QIvn3oYur9SUHDzSiLuvvwBD89m HcpgZc8uHZVx6eIQz9Dbrw4DB8F2/AQrQwk9A8gTW7OiQGQ2ngwErIyovpaUUX0PNP7UHHkoH 7yzhMklSLcuuLduKXUAOgyEo1CMMLV8FbxX9AwdrqBO94xaVtBkJ6wbeKI/nc0ztbcPzFhiqu zwrFgiP+WGkSEZ3akuQ3XNpoxTjTGqBP3vqvNNW20df/6j4PZpH5hWwzuqFrZ44noMbo/89ti uIOx536f1noT4cooT7IKhjEnAzBPlTeAoQMSVhPXjtGGZTb+DAvr1QTRDUOEXVg31vop4IBA6 TfwAvBX7/pHGMYxwrvtZCBDKofiWvyJKujEE+tdhhr0/NlEuqtkEVCn50HELeknYf5TubWpem XdZkZEjZBKnbR2FPPhZZHQl7D8n1M07zICTPksl2aCCTklsZ69INIa+dwFYFR9Bh92QH4ox47 Y/4aqSgsLYVbmKGJLIdg== Archived-At: Subject: Re: [tcpm] 793bis ready to go? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 10:18:01 -0000 I also like the word-smithing the two of you came up with. That text reads exactly like what I would like to know in that instance, where I to implement the behavior. Thanks! Am 21.02.2021 um 20:39 schrieb Joe Touch: > Works for me. > >> On Feb 21, 2021, at 11:16 AM, Michael Tuexen wrote: >> >> =EF=BB=BF >>> >>> On 21. Feb 2021, at 19:38, Joseph Touch wrote: >>> >>>> On Feb 20, 2021, at 1:53 PM, Michael Tuexen wrote: >>>> >>>> >>>> >>>>> On 20. Feb 2021, at 22:37, Joseph Touch wrote= : >>>>> >>>>> Even if you prefer the FreeBSD variant, the text below doesn=E2=80= =99t appear to fix this; it will end up sending the SYN-ACK of the receive= d data *and a second ACK* at the end of the sixth step. >>>> I think the idea of Richard is that if the text is >>>> >>>> If SND.UNA > ISS (our SYN has been ACKed), change the >>>> connection state to ESTABLISHED, form an ACK segment >>>> >>>> and should send it. >>>> >>>> Then NOT following the should, but only send the ACK at the end of st= ep 6. >>>> Wouldn't that work? >>> >>> FWIW, I think the case of combining the bare ACK with the ACK of the r= eceived SYN-ACK data is already covered in the sixth step below in the fol= lowing text: >>> >>> This acknowledgment should be piggybacked on a segment being >>> transmitted if possible without incurring undue delay. >>> >> I agree, this covers it. But it would be good to have it a bit more exp= licit. >>> >>> If this needs to be made more explicit, here=E2=80=99s my suggestion: >>> >>> OLD: >>> >>> If SND.UNA > ISS (our SYN has been ACKed), change the connecti= on >>> state to ESTABLISHED, form an ACK segment >>> >>> >>> >>> and send it. Data or controls which were queued for >>> transmission may be included. If there are other controls or >>> text in the segment then continue processing at the sixth step >>> below where the URG bit is checked, otherwise return. >>> >>> >>> >>> NEW: >>> >>> If SND.UNA > ISS (our SYN has been ACKed), change the connecti= on >>> state to ESTABLISHED, form an ACK segment >>> >>> >>> >>> Data or controls which were queued for >>> >>> transmission MAY be included in this segment. If there are no >>> other controls or text in the segment then send the ACK segment >> Maybe: >> other controls or text in the received segment then send the A= CK segment >>> and return. Otherwise, continue processing at the sixth step below >>> where the URG bit is checked, either sending the ACK segment now o= r >>> piggybacking it with the response from that continued processing >>> (as noted therein). >> I like your proposal (maybe with the above suggestion). >> >> Best regards >> Michael >>> >>> Joe >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Feb 22 02:21:07 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514613A13F2 for ; Mon, 22 Feb 2021 02:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaxwWDsBgrd6 for ; Mon, 22 Feb 2021 02:20:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A9D4B3A135F for ; Mon, 22 Feb 2021 02:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613989212; bh=zKOCD2tBOylMERL0K2IDepMyHVIzWz05VQz9GDlmk4M=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=cxGkwsK576CLXMQkcGFO0RMKvNbnISrhJ0dpVGH73j9XVkJgJnDq/RCkCROcowOSM jzoHhSBmWFlE1t8R3J75jHJFmjs8s62t5yofrDUvvHJlOkfTRck2ChkUfROhXoqTcI AKcNpTXc1kmaQaG8AAROJSuiPXaY5OYoNzDq9G30= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.129.182]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQvD5-1lRgpH1bJn-00NzOy; Mon, 22 Feb 2021 11:20:12 +0100 To: Lars Eggert , tcpm IETF list References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> From: "Scheffenegger, Richard" Message-ID: <3a6f9e55-9193-18e1-af60-cbed17571f4f@gmx.at> Date: Mon, 22 Feb 2021 11:20:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Le2T7kbNrMVFUVuBJHK1152uK+5bP8RHBQdWlq1QZvSCEi8HLYD 4T1lLpV/P0/nUaqcuMsr3wUAQfyLupgX4Rd92CRrXUi2Gw8f+3bEoMHHy4n1oFA4KDrPKiz UAGu1zMeLCM7zNdHIranj15V9/Op99StSEv06JPPAeHR8QW9rwKyO6wta9SjywEE6xP57aZ XGNgbV+fo+v+DeiJarFjg== X-UI-Out-Filterresults: notjunk:1;V03:K0:I+9MfTUBjhc=:jsehvEqrbM+yTKFoYRtQNi DrRrzrA3W8QGPrTtW31G2aHsEotMzJEYkV7+y0ak1xFv1x+4lKVwQp9mHwXjCx1DLT7lolg0x +hBriPGB7yt8WyG7yEFNufNMuoBhoMTG+WOHYuQIKVy/ZN9Ok2RjhQ689TGu4bYCkH+vbTdQZ PBnuLVMfIPxbOv3LzWDbbc6nGF8IwJ9lroYdp2A6ostO1E7KYFR5T4OaN+TJEw/hMH/p4ncZM b3mG9P0hEnc/TD9MOIhDddNJFEzPbNkR8u3nvLZuogWvLVzcptVLfAiK0mrbOYaHsNApdfA0l Zs+sUYSEVgOd0Qt60toNx/aU6WA7CipAhfhzaZGy/rsMfvBfQkBmxjfw478Fuo3asLK76AE55 wXRBORcPSpLm6AvA79t1Nj25ITdaTflURetdSBUYQ0AL9po59bBCMu3H05oEVRVy9NqSkJ8xa Lu++95MzZuVjqMi+6wqFQwPtLrc5lvevCBqsz9MgkdH0EG5ikjsRaaE9rZm4v91sy027Mgrxy aeWq/kSTE4lLM8seDZNalZd5kTEZjZ9XNAIlgQ1bPP7eMFoG3WJ+8YV/z2QJvEt7dIt0Ylft+ IINZWnvZdNkxcgjOloh3uJsYZA6Gh0nDlYsV7X+vOXBou2fhIplzRzbmCwzw5e2RdMqQia4uk Rp3LRLdq2elBKOpYu+A86Z3/apIGZuzj6EX+YU4Elrb+vl2YjtwfLN9YUX2+okS3cjew2jwYx S4sLz/R7E0G1fCVhvnWpd2S7XffG/oXmhroAnGjifGPwXhlbEpgcIe9WGR1fY1BTc8q5GgGg6 u3aaPJ3WTZpX5VHpkZjUTXkITRB3mQD2nrMda9n8HAJ27+FtWGEzmkkM11AOowtFqOKvXmUvI GwG+LDSe6sUP+tcZdBVA== Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 10:21:06 -0000 I am absolutely in favor to adopt this draft. Like in the recent example of PRR (6937bis), I would like to see that widely deployed mechanisms are also reflected by a standards-track RFC, not only experimental. Richard Am 22.02.2021 um 09:54 schrieb Lars Eggert: > Hi, > > we just submitted the -02 version of the CUBIC bis document. > > This version=A0incorporates the major editorial changes we wanted to mak= e. > > We'd like to ask the WG to determine if this is ready for adoption. > Vidhi has asked for a presentation slot during IETF-110 for this ID, but > the adoption discussion IMO doesn't need to wait. > > Thanks, > Lars > > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-eggert-tcpm-rfc8312bis-02.txt* >> *Date: *February 22, 2021 at 10:49:39 GMT+2 >> *To: *"Injong Rhee" > >, "Lars Eggert" > >, "Lisong Xu" > >, "Sangtae Ha" > >, "Vidhi Goel" > > >> >> >> A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt >> has been successfully submitted by Lars Eggert and posted to the >> IETF repository. >> >> Name:draft-eggert-tcpm-rfc8312bis >> Revision:02 >> Title:CUBIC for Fast and Long-Distance Networks >> Document date:2021-02-22 >> Group:Individual Submission >> Pages:27 >> URL: >> https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt >> >> Status: https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/ >> >> Html: >> https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html >> >> Htmlized: https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 >> >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-eggert-tcpm-rfc8312bis-02 >> >> >> Abstract: >> =A0=A0CUBIC is an extension to the traditional TCP standards. =A0It dif= fers >> =A0=A0from the traditional TCP standards only in the congestion control >> =A0=A0algorithm on the sender side. =A0In particular, it uses a cubic >> =A0=A0function instead of a linear window increase function of the >> =A0=A0traditional TCP standards to improve scalability and stability un= der >> =A0=A0fast and long-distance networks. =A0CUBIC has been adopted as the >> =A0=A0default TCP congestion control algorithm by Linux, Windows, and A= pple >> =A0=A0stacks. >> >> =A0=A0This document updates the specification of CUBIC to include >> =A0=A0algorithmic improvements based on these implementations and recen= t >> =A0=A0academic work. =A0Based on the extensive deployment experience wi= th >> =A0=A0CUBIC, it also moves the specification to the Standards Track, >> =A0=A0obsoleting [RFC8312]. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Feb 22 02:46:13 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA643A1334 for ; Mon, 22 Feb 2021 02:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 Li6woSOpUmRs for ; Mon, 22 Feb 2021 02:46:06 -0800 (PST) Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [IPv6:2a00:8a60:1:e501::5:47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33243A13A2 for ; Mon, 22 Feb 2021 02:46:02 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CcAwD5ijNg/xUN4oliHAEBAQEBAQcBA?= =?us-ascii?q?RIBAQQEAQFAgU+BU4E5FYFBCgGENpEzJQOIe4IokScLAQEBAQEBAQEBCAEdDQg?= =?us-ascii?q?CBAEBhE0CF4F2AiU4EwIQAQEGAQEBAQEGBIZSDYZEAQEBAwEBASEROgsFCwIBC?= =?us-ascii?q?A4KAgImAgICJQsVEAIEDgWCawGCZiABDq0ldoEyhD8BgRiDY4EIgQ4qhn2GRCa?= =?us-ascii?q?CHoE4DAMNgiI1PoJdAQEBgV6DFjSCKwSBS4EXTFEBAVsYEhiBFBqQJINPpV4Hg?= =?us-ascii?q?WyBEok+j2WCdQMfgzGBNI5gMo9Nn36SIIQ5AgQCBAUCFoFrgXpxTyoBgj4JRxc?= =?us-ascii?q?CDY4rFohhhUVzAjYCBgEJAQEDCXyKCAGBDgEB?= X-IPAS-Result: =?us-ascii?q?A2CcAwD5ijNg/xUN4oliHAEBAQEBAQcBARIBAQQEAQFAgU+?= =?us-ascii?q?BU4E5FYFBCgGENpEzJQOIe4IokScLAQEBAQEBAQEBCAEdDQgCBAEBhE0CF4F2A?= =?us-ascii?q?iU4EwIQAQEGAQEBAQEGBIZSDYZEAQEBAwEBASEROgsFCwIBCA4KAgImAgICJQs?= =?us-ascii?q?VEAIEDgWCawGCZiABDq0ldoEyhD8BgRiDY4EIgQ4qhn2GRCaCHoE4DAMNgiI1P?= =?us-ascii?q?oJdAQEBgV6DFjSCKwSBS4EXTFEBAVsYEhiBFBqQJINPpV4HgWyBEok+j2WCdQM?= =?us-ascii?q?fgzGBNI5gMo9Nn36SIIQ5AgQCBAUCFoFrgXpxTyoBgj4JRxcCDY4rFohhhUVzA?= =?us-ascii?q?jYCBgEJAQEDCXyKCAGBDgEB?= X-IronPort-AV: E=Sophos;i="5.81,197,1610406000"; d="scan'208";a="136040737" Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 22 Feb 2021 11:46:00 +0100 Received: from hermes-mbx.win.comsys.rwth-aachen.de (hermes-mbx.win.comsys.rwth-aachen.de [137.226.13.41]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id 31093C09C0; Mon, 22 Feb 2021 11:46:00 +0100 (CET) Received: from HERMES-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::41) by HERMES-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 22 Feb 2021 11:45:59 +0100 Received: from HERMES-MBX.win.comsys.rwth-aachen.de ([fe80::e198:7509:269a:ddb6]) by HERMES-MBX.win.comsys.rwth-aachen.de ([fe80::e198:7509:269a:ddb6%11]) with mapi id 15.01.2106.002; Mon, 22 Feb 2021 11:45:59 +0100 From: =?utf-8?B?SmFuIFLDvHRo?= To: Matthew Luckie CC: "Scheffenegger, Richard" , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt Thread-Index: AQHW+o8yGOYm9cbOy0arauEwq/YkeKpHgXAAgADbe4CAAAebAIAArBiAgAWxSYCAAAgbgIAVP+uA Date: Mon, 22 Feb 2021 10:45:59 +0000 Message-ID: <04723570-93E7-4BB8-821E-BC3672A42F15@comsys.rwth-aachen.de> References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.226.13.22] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 10:46:11 -0000 SGkgZXZlcnlvbmUsDQoNCm1heWJlIEkgY2FuIGFkZCB0byB0aGUgbWVhc3VyZW1lbnRzIHRoYXQg TWF0dGhldyBjaXRlZC4NCldlIHBlcmZvcm1lZCB0aGVzZSBvbmx5IG9uY2UuIEJ1dCB3ZSBhcmUg ZG9pbmcgb3RoZXIgbWVhc3VyZW1lbnRzIHRoYXQgd2UgZG8gbW9yZSBmcmVxdWVudGx5Lg0KDQpG cm9tIHRoZXNlIEkgY2FuIHJlcG9ydCBmdXJ0aGVyIG51bWJlcnMgdGhhdCB3ZSBuZXZlciBnb3Qg YXJvdW5kIHRvIGFjdHVhbGx5IHB1Ymxpc2guDQoNCldlIGxvb2sgZm9yIFRGTyBzdXBwb3J0IG9u IHBvcnQgODAgYW5kIHdlIHNlbmQgVEZPIGNvb2tpZSByZXF1ZXN0cyB0byBhbGwgb2YgSVB2NC4N CldlIGdldCByb3VnaGx5IDMuMk0gdmFsaWQgcmVwbGllcyB3aXRoIFRGTyBjb29raWVzIChhcyBv ZiBsYXRlIDIwMTkpLCB3aGljaCByb3NlIGZyb20gNTAwayAobWlkIDIwMTcpLg0KDQpSZWdhcmRp bmcgdGhlIG1pcnJvcmVkIG9wdGlvbnMsIHdlIHNlZSBhcm91bmQgNzBrIC0gODBrIGVtcHR5IGNv b2tpZSByZXBsaWVzIChlc3NlbnRpYWxseSwgd2UgZ2V0IG91ciBjb29raWUgcmVxdWVzdCBiYWNr KSB0aGF0IGhhdmUgdGhlIHNhbWUgYmVoYXZpb3IgYXMgb3V0bGluZWQgaW4gT2xpdmllcuKAmXMg YmxvZ3Bvc3QsIHRoaXMgbnVtYmVyIGlzIHJhdGhlciBzdGFibGUsIHNvbWV0aW1lcyAxMGsgbW9y ZSBvciBsZXNzLg0KVGhpcyBiZWhhdmlvciBpcyBmb2N1c3NlZCBvbiBJUHMgcmVzaWRpbmcgaW4g Q2hpbmVzZSBhdXRvbm9tb3VzIHN5c3RlbXMuDQpPdXIgYXNzdW1wdGlvbiBoYXMgYWx3YXlzIGJl ZW4gdGhhdCB0aGlzIG1pcnJvcmluZyBpcyBwZXJmb3JtZWQgYnkgc29tZSBtaWRkbGVib3ggYW5k IG5vdCBhbiBlbmQtaG9zdC4NCg0KSWYgdGhlcmUgaXMgaW50ZXJlc3QsIEkgY2FuIHBlcmZvcm0g dGhlc2UgbWVhc3VyZW1lbnRzIHdpdGggYW4gdW5hc3NpZ25lZCBUQ1Agb3B0aW9uIG51bWJlci4N Cg0KQmVzdA0KIEphbg0KDQoNCj4gT24gOC4gRmViIDIwMjEsIGF0IDIzOjE1LCBNYXR0aGV3IEx1 Y2tpZSA8bWpsQGNhaWRhLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBSaWNoYXJkLA0KPiANCj4gT24g TW9uLCBGZWIgMDgsIDIwMjEgYXQgMTA6NDY6NDVQTSArMDEwMCwgU2NoZWZmZW5lZ2dlciwgUmlj aGFyZCB3cm90ZToNCj4+IEhpIFlvc2hpLA0KPj4gDQo+PiBTb3JyeSB0byBuaXRwaWNrIC0gaW4g eW91ciBkcmFmdCwgeW91IG1lbnRpb24gdGhhdCBzb21lIGhvc3RzIHJlZmxlY3QNCj4+IGJhY2sg dW5rbm93biB0Y3Agb3B0aW9ucywgd2hpY2ggaXMgd2h5IHlvdSBhcmUgdXNpbmcgZGlmZmVyZW50 IEdJRA0KPj4gbWFwcGluZ3MgYmV0d2VlbiBTWU4gYW5kIFNZTixBQ0suDQo+PiANCj4+IEkgZGlk IHJlYWQgYWJvdXQgdGhpcyBiZWhhdmlvciBjb25jZXJuaW5nIFRDUCBoZWFkZXIgZmxhZ3MgLyBy ZXNlcnZlZA0KPj4gYml0cyAtIGJ1dCBoYXZlIG5vdCBjb21lIGFjcm9zcyBhIHBhcGVyIHdoZXJl IHRoaXMgYmVoYXZpb3IgaXMgZGVzY3JpYmVkDQo+PiBmb3IgdW5rbm93biBUQ1Agb3B0aW9ucyAo b3IgSSBtYXkgaGF2ZSBtaXNzZWQgdGhhdCBhc3BlY3QgaW4gdGhlIHZhcmlvdXMNCj4+IHN0dWRp ZXMgYXJvdW5kIFRDUCBvcHRpb24gaW52ZXN0aWdhdGlvbnMgZG9uZSBieSBNUFRDUCBhbmQgb3Ro ZXIgZ3JvdXBzKS4NCj4gDQo+IFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBvZiBzeXN0ZW1zIHRo YXQgc2VlbSB0byByZWZsZWN0IFRDUCBvcHRpb25zIGhlcmU6DQo+IA0KPiBodHRwOi8vYmxvZy5t dWx0aXBhdGgtdGNwLm9yZy9ibG9nL2h0bWwvMjAxOC8xMi8xOS93aGljaF9zZXJ2ZXJzX3VzZV9t dWx0aXBhdGhfdGNwLmh0bWwNCj4gDQo+IE1hdHRoZXdfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQo= From nobody Mon Feb 22 07:20:05 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F23A0C56 for ; Mon, 22 Feb 2021 07:20:04 -0800 (PST) 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 k5y9HaN_mvvC for ; Mon, 22 Feb 2021 07:20:02 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 B952F3A0C4E for ; Mon, 22 Feb 2021 07:16:10 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id j188so2892382vke.13 for ; Mon, 22 Feb 2021 07:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dp72kGiIl36lQDmBkNs76IAdXqp5OQgw2KswQR4ns2g=; b=Oy6d2TMVly2SuRIpio1LdnbEJ6hDNWOaBI3oeHcd3epYYogQnZdRBYrKZCr04E4Ewy 8ymKmK9Kr9yrko8NqN1Z3rVfGyQaA5vhj4nG+URLUjVdV0FCLie0EdhRvreaDMH1HIxy B/9WYOJR8TFg6CGpyYesfV99Zn3AARwRLcPYuCLN9Qo+gPJ2jub7NCIVuESSohjPOAm3 YrVWL0OdJSj+Yq8lNrX9FHDdTtp05bwVzLEHtkgh/TboMh88+1neKCUvWiliKGtdMRTc 9dUp24vN0E8wmqVtYBAWLoZ0za2PU3Ezd2X62DsOJVWidZHqWiwlfx47Xtn5A2bBsGG+ kFLQ== 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=dp72kGiIl36lQDmBkNs76IAdXqp5OQgw2KswQR4ns2g=; b=tDIiFzIMjYIRe/Ug8CLAwuXLdsdYCYds2To2k64DslAbFCSVS1RtiZrOozwdV3xwCi TjRTdNxjEzCLDfusPDEJm0ALo5v3aLFlOWafBOWZaNKxOUaSA5y5q7M/EGQ/pdrTe3pV 7ak83mLwvbzfXJc6c5Vxi2mr/QNpax0xq64/JSimvkHOVljfquoOzBBeBtGv4cvvtmvV mMZeMTZ0XaD/Nd+/UAo0rxQfj3r7q86+tjVGp/K4OKJJzcW3HXMBvDTfYpRN3qP8XEyI ClaN/jPQPCzBjmSZab73XBJ6HZIxDmapScuWCHQ65uyGyYLeRu62dSfz0QP3VRupqPYW O+jw== X-Gm-Message-State: AOAM530hLigQylN43xt5zEpyIkz8AZfuGaYxSeClKR99X7D2PVKHTY45 l/OQcV1wz5b5SOy5CA22n8XfD+yq2XQm0OIQ5VY6tQ== X-Google-Smtp-Source: ABdhPJwZ+CWx45tVbrSGd6xda6hHQdfbeJ1EozIYuRREUHL+TncG08T43h88kiu6zawNPzSsdiIQav9atbb0L/qxkEI= X-Received: by 2002:a1f:c1c4:: with SMTP id r187mr7862035vkf.14.1614006969385; Mon, 22 Feb 2021 07:16:09 -0800 (PST) MIME-Version: 1.0 References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <3a6f9e55-9193-18e1-af60-cbed17571f4f@gmx.at> In-Reply-To: <3a6f9e55-9193-18e1-af60-cbed17571f4f@gmx.at> From: Neal Cardwell Date: Mon, 22 Feb 2021 10:15:52 -0500 Message-ID: To: "Scheffenegger, Richard" Cc: Lars Eggert , tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000013dbe405bbee48b6" Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 15:20:05 -0000 --00000000000013dbe405bbee48b6 Content-Type: text/plain; charset="UTF-8" I also support WG adoption for this draft; this has some important updates relative to RFC8312. best, neal On Mon, Feb 22, 2021 at 5:23 AM Scheffenegger, Richard wrote: > > I am absolutely in favor to adopt this draft. > > Like in the recent example of PRR (6937bis), I would like to see that > widely deployed mechanisms are also reflected by a standards-track RFC, > not only experimental. > > Richard > > > Am 22.02.2021 um 09:54 schrieb Lars Eggert: > > Hi, > > > > we just submitted the -02 version of the CUBIC bis document. > > > > This version incorporates the major editorial changes we wanted to make. > > > > We'd like to ask the WG to determine if this is ready for adoption. > > Vidhi has asked for a presentation slot during IETF-110 for this ID, but > > the adoption discussion IMO doesn't need to wait. > > > > Thanks, > > Lars > > > > > >> Begin forwarded message: > >> > >> *From: *internet-drafts@ietf.org > >> *Subject: **New Version Notification for > >> draft-eggert-tcpm-rfc8312bis-02.txt* > >> *Date: *February 22, 2021 at 10:49:39 GMT+2 > >> *To: *"Injong Rhee" >> >, "Lars Eggert" >> >, "Lisong Xu" >> >, "Sangtae Ha" >> >, "Vidhi Goel" >> > > >> > >> > >> A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt > >> has been successfully submitted by Lars Eggert and posted to the > >> IETF repository. > >> > >> Name:draft-eggert-tcpm-rfc8312bis > >> Revision:02 > >> Title:CUBIC for Fast and Long-Distance Networks > >> Document date:2021-02-22 > >> Group:Individual Submission > >> Pages:27 > >> URL: > >> https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt > >> > >> Status: https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/ > >> > >> Html: > >> https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html > >> > >> Htmlized: https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 > >> > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=draft-eggert-tcpm-rfc8312bis-02 > >> > >> > >> Abstract: > >> CUBIC is an extension to the traditional TCP standards. It differs > >> from the traditional TCP standards only in the congestion control > >> algorithm on the sender side. In particular, it uses a cubic > >> function instead of a linear window increase function of the > >> traditional TCP standards to improve scalability and stability under > >> fast and long-distance networks. CUBIC has been adopted as the > >> default TCP congestion control algorithm by Linux, Windows, and Apple > >> stacks. > >> > >> This document updates the specification of CUBIC to include > >> algorithmic improvements based on these implementations and recent > >> academic work. Based on the extensive deployment experience with > >> CUBIC, it also moves the specification to the Standards Track, > >> obsoleting [RFC8312]. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org > >> . > >> > >> The IETF Secretariat > >> > >> > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000013dbe405bbee48b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support WG adoption for this draft; this has some i= mportant updates relative to RFC8312.

best,
neal


On Mon, Feb 22, 2021 at 5:23 AM Scheffenegger, R= ichard <rs.ietf@gmx.at> wrote:<= br>

I am absolutely in favor to adopt this draft.

Like in the recent example of PRR (6937bis), I would like to see that
widely deployed mechanisms are also reflected by a standards-track RFC,
not only experimental.

Richard


Am 22.02.2021 um 09:54 schrieb Lars Eggert:
> Hi,
>
> we just submitted the -02 version of the CUBIC bis document.
>
> This version=C2=A0incorporates the major editorial changes we wanted t= o make.
>
> We'd like to ask the WG to determine if this is ready for adoption= .
> Vidhi has asked for a presentation slot during IETF-110 for this ID, b= ut
> the adoption discussion IMO doesn't need to wait.
>
> Thanks,
> Lars
>
>
>> Begin forwarded message:
>>
>> *From: *internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> *Subject: **New Version Notification for
>> draft-eggert-tcpm-rfc8312bis-02.txt*
>> *Date: *February 22, 2021 at 10:49:39 GMT+2
>> *To: *"Injong Rhee" <injongrhee@gmail.com
>> <mailto:injongrhee@gmail.com>>, "Lars Eggert" <lars@eggert.org
>> <mailto:la= rs@eggert.org>>, "Lisong Xu" <xu@unl.edu
>> <mailto:xu@unl.= edu>>, "Sangtae Ha" <sangtae.ha@colorado.edu
>> <mailto:sangtae.ha@colorado.edu>>, "Vidhi Goel" <vidhi_goel@apple.com
>> <mailto:vidhi_goel@apple.com>>
>>
>>
>> A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt
>> has been successfully submitted by Lars Eggert and posted to the >> IETF repository.
>>
>> Name:draft-eggert-tcpm-rfc8312bis
>> Revision:02
>> Title:CUBIC for Fast and Long-Distance Networks
>> Document date:2021-02-22
>> Group:Individual Submission
>> Pages:27
>> URL:
>> https://www.ietf.org/arc= hive/id/draft-eggert-tcpm-rfc8312bis-02.txt
>> <https://www.ietf.org= /archive/id/draft-eggert-tcpm-rfc8312bis-02.txt>
>> Status: https://datatracker.i= etf.org/doc/draft-eggert-tcpm-rfc8312bis/
>> <https://datatracker.ietf.= org/doc/draft-eggert-tcpm-rfc8312bis/>
>> Html:
>> https://www.ietf.org/ar= chive/id/draft-eggert-tcpm-rfc8312bis-02.html
>> <https://www.ietf.or= g/archive/id/draft-eggert-tcpm-rfc8312bis-02.html>
>> Htmlized: https://tools.ietf.org= /html/draft-eggert-tcpm-rfc8312bis-02
>> <https://tools.ietf.org/html/= draft-eggert-tcpm-rfc8312bis-02>
>> Diff:
>> https://www.ietf.org/rfc= diff?url2=3Ddraft-eggert-tcpm-rfc8312bis-02
>> <https://www.ietf.org= /rfcdiff?url2=3Ddraft-eggert-tcpm-rfc8312bis-02>
>>
>> Abstract:
>> =C2=A0=C2=A0CUBIC is an extension to the traditional TCP standards= .=C2=A0 It differs
>> =C2=A0=C2=A0from the traditional TCP standards only in the congest= ion control
>> =C2=A0=C2=A0algorithm on the sender side.=C2=A0 In particular, it = uses a cubic
>> =C2=A0=C2=A0function instead of a linear window increase function = of the
>> =C2=A0=C2=A0traditional TCP standards to improve scalability and s= tability under
>> =C2=A0=C2=A0fast and long-distance networks.=C2=A0 CUBIC has been = adopted as the
>> =C2=A0=C2=A0default TCP congestion control algorithm by Linux, Win= dows, and Apple
>> =C2=A0=C2=A0stacks.
>>
>> =C2=A0=C2=A0This document updates the specification of CUBIC to in= clude
>> =C2=A0=C2=A0algorithmic improvements based on these implementation= s and recent
>> =C2=A0=C2=A0academic work.=C2=A0 Based on the extensive deployment= experience with
>> =C2=A0=C2=A0CUBIC, it also moves the specification to the Standard= s Track,
>> =C2=A0=C2=A0obsoleting [RFC8312].
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>
>
> _______________________________________________
> 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
--00000000000013dbe405bbee48b6-- From nobody Mon Feb 22 07:57:59 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811FF3A1D36 for ; Mon, 22 Feb 2021 07:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEZhqkpVTRvC for ; Mon, 22 Feb 2021 07:57:56 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 3022D3A1C98 for ; Mon, 22 Feb 2021 07:57:56 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:5c0c:b274:4b3c:19f4] (unknown [IPv6:2a00:ac00:4000:400:5c0c:b274:4b3c:19f4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id AA89960030D; Mon, 22 Feb 2021 17:57:46 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1614009466; bh=j3rVbNhLg3oFs0hsIUVtB29z57mhwxGrM0zo2VWjPUU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=i0PzGZXk/+KR00Q/0It29YPUMDG590jnyV2tmoS6p5YBZZpzW7LTlmvyC9cQMWTqm OAVfoiK3UfR4+FMefPHmQ9ody3HMilk77Co7E5hI0ssz0/nN0k/aZZS2hbVy9DRoEH aPOIGNsKmdYsWMJ4buZ6V2jGQzteJU/4uwm58mHs= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9221B2DF-DAEF-412E-A5E0-656A55CE4868"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 22 Feb 2021 17:57:46 +0200 In-Reply-To: <3a6f9e55-9193-18e1-af60-cbed17571f4f@gmx.at> Cc: tcpm IETF list To: "Scheffenegger, Richard" References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <3a6f9e55-9193-18e1-af60-cbed17571f4f@gmx.at> X-MailScanner-ID: AA89960030D.A13C0 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 15:57:58 -0000 --Apple-Mail=_9221B2DF-DAEF-412E-A5E0-656A55CE4868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2021-2-22, at 12:20, Scheffenegger, Richard wrote: > Like in the recent example of PRR (6937bis), I would like to see that > widely deployed mechanisms are also reflected by a standards-track = RFC, > not only experimental. Agreed, and we are targeting this for PS at the moment for this reason = (whether the community agrees with this remains to be seen). Lars --Apple-Mail=_9221B2DF-DAEF-412E-A5E0-656A55CE4868 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmAz1HoACgkQVLXDCb9w wVfLxw/9EzFWIsteQfTUmyytelai/VyW1tElAcc6z19Ixhk0shnlvoeCD1ynGsxy 6VuTyYhPnV/Ijvp+eMhg/6QlT8lUTubjNr3CTHkedg8yC8SBEhjrEyPvI+Tpv2co SV3mN9qrwzV/v/LEAvbGT0+xYBrxSKHvY4A1Z6NBu6B7Gr04Kiqvv9Pnlfmgvr4/ +9OvtTIgvlcA4KjJhuosRzpAtVELQ0Uhm6XO1KJb9H+25gfKwLcEkt9TZMdvTc0f wNYUmuX4YRlpbEDvO89PcuwPe9pOsllmwAlkm33sXvklb1Zq8LIjwW+4DViiQeWa HTARnexF+tsHc7XHXZemG63+gbXJZq9xI57HvQjcjh4Ls5VxW7iP5xLpglP1p1j6 oogR9nxytgW2ssP5D9U+A+C1oaCJ0aZJRmc6A3R0vIEsqigRcDXVk6V2ueBctIdA xD+VE6AoiCBGstwdfHdPg8fdwWudTdKdwE21NN1ajN6mbq5rOYyRmU3Y5649hSVY ZUokHpjEDFA/mF7e8SCM4CHS+JIiLQJY+BK+NjOll5JaxMVoWlenQc6EPvvjzLc/ i8fXaovLkGQKdNeH0/WFZGLRQ863koK7pvvQtmJxmVi88hfIb6lqOitkrDbpgQ3j GdZTFTUSE+LmUdDB8ow3uf1Z3KXv1dLX5KQmyS8jsIRLKZgTjEA= =0qPd -----END PGP SIGNATURE----- --Apple-Mail=_9221B2DF-DAEF-412E-A5E0-656A55CE4868-- From nobody Mon Feb 22 14:51:36 2021 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 311CF3A239D; Mon, 22 Feb 2021 14:51:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161403428413.22042.205772629562934735@ietfa.amsl.com> Date: Mon, 22 Feb 2021 14:51:24 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 22:51:31 -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 : Proportional Rate Reduction for TCP Authors : Matt Mathis Nandita Dukkipati Yuchung Cheng Filename : draft-ietf-tcpm-prr-rfc6937bis-01.txt Pages : 18 Date : 2021-02-22 Abstract: This document updates the experimental Proportional Rate Reduction (PRR) algorithm, described RFC 6937, to standards track. PRR potentially replaces the Fast Recovery and Rate-Halving algorithms. All of these algorithms regulate the amount of data sent by TCP or other transport protocol during loss recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the ssthresh, as determined by the congestion control algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-prr-rfc6937bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-prr-rfc6937bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 14:59:31 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77553A2182 for ; Mon, 22 Feb 2021 14:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBPBfJPc6ytn for ; Mon, 22 Feb 2021 14:59:20 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 92F663A2667 for ; Mon, 22 Feb 2021 14:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=txJCRwxSTPkBNXlGHzGThwJgQxWZDxmazVP0K8sjDSQ=; b=SJJHz7T6rZ+zea7A79Mb8lDxY +Wen7IeUrHVjLLY9ZjmExC6DVBQk4CRgsofZe4g7YkDK4WXT6tWyFZI/bvVUuyutzYjZ9ZYO1bykL gxIymgWlhcdG8UumHWi19qt3nUHtEMpLuNwEgt2NgjVaAdxBhAD7KTIzMlKyH4ugnFgJW19VjnVFA C4AOnrIIzB8SUVt4PhcytaWpPfsf2oWGmRdFIFi+L4G8hN6+xjiO/3NBh2+WNi7NgmN2KZnlRtUbl +pIElC2XEZnpHYj/rU0Rs0F3LfbPc5oL3q0vcIekQjLelci+5GwIn3Q0Cu6SkMMyZAA3slPCVbNTx xvHEQEdLQ==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:55728 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lEK8J-00041b-Qw; Mon, 22 Feb 2021 22:56:51 +0000 To: Gorry Fairhurst , tcpm IETF list Cc: Mirja Kuehlewind References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> <95ACEF0A-61F9-44E7-8BD9-8C1FADCD2583@strayalpha.com> <9167ba8a-dd99-7af1-3559-b4993a73d9b2@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: Date: Mon, 22 Feb 2021 22:56:51 +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: <9167ba8a-dd99-7af1-3559-b4993a73d9b2@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------30AC2CFCA19B797871212455" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Coming back to my comments on AccECN wrt ACK Filtering X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 22:59:23 -0000 This is a multi-part message in MIME format. --------------30AC2CFCA19B797871212455 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Gorry, Thank you (as always) for checking this. Inline [BB]... On 17/02/2021 16:47, Gorry Fairhurst wrote: > Bob, > > After the last IETF I promised to try simplify the comment on the new > ACK Filtering text in ACCECN. > > I've included what the current draft says, and marked comments in the > text as ">GF>" to try and be more specific about which words attracted > the alst round of feedback: > > 3.3.3.  Requirements for TCP ACK Filtering > >    A node that implements ACK filtering (aka. thinning or coalescing) >    and itself also implements ECN marking will not need to filter ACKs >    from connections that use AccECN feedback.  Therefore, such a node >    SHOULD detect connections that have negotiated the use of AccECN >    feedback during the handshake (see Table 2) and it SHOULD preserve >    the timing of each ACK (if it coalesced ACKs it would not be AccECN- >    compliant, but the requirement is stated as a "SHOULD" in order to >    allow leeway for pre-existing ACK filtering functions to be brought >    into line). > > >GF> What does that "SHOULD" really mean? As far as I know, many > devices that have RFC3449-like behaviours operate over links that have > some specific property that changes the packet timing (perhaps > half-duple; or transmission aligned to assigned time slots, or > whatever). I therefore don’t understand “preserve timing”. [BB] Sorry, that was hung over text from a previous way of saying it. Here's the sentence with improvements: Therefore, such a node SHOULD detect connections that are using AccECN feedback and it SHOULD refrain from filtering the ACKs of such connections... You'll notice I've removed the mention of using the handshake to detect use of AccECN. Being less prescriptive allows a node to use whatever heuristics will work, if the designer can think of soemthing better. > >    A node that implements ACK filtering and does not itself implement >    ECN marking does not need to treat AccECN connections any differently >    from other TCP connections. > Nonetheless, it is RECOMMENDED that such >    nodes implement ECN marking and comply with the requirements of the >    previoius > > >GF> Typo > >     paragraph.  This should be a better way than ACK filtering >    to improve the performance of AccECN TCP connections. > >    The rationale for these requirements is that AccECN feedback provides >    sufficient information to a data receiver for it to be able to >    monitor ECN marking of the ACKs it has sent, so that it can thin the >    ACK stream itself.  This will eventually mean that ACK filtering in >    the network gives no performance advantage.  Then TCP will be able to >    maintain its own control over ACK coalescing.  This will also allow >    the TCP Data Sender to use the timing of ACK arrivals to more >    reliably infer further information about the path congestion level. > > >GF> /This will eventually mean/This might eventually mean/:  because > I think tis is an aspiration and maybe some nodes can use ECN to > control ACK feedback, but is this always true? Given that link > transmission can be very variable, and in the case of ACKs often > becomes a limit per-packet rather than per-byte for typical data > packets, I’m unsure how the implementation of ECN-marking against a > variable jitter/capacity would interact with the capacity fluctuations > from sharing media, or other physical layer propagation variations. I > suggest this is an ambition rather than it necessarily being true that > this will be better than any ACK Filtering method or FQ-style mitigation. [BB] Agree. I've used "This could eventually mean". Slightly less vague IMO. > >    Note that the specification of AccECN in TCP does not presume to rely >    on the above ACK filtering behaviour in the network, because it has >    to be robust against pre-existing network nodes that still filter >    AccECN ACKs, and robust against ACK loss during overload. > >    Section 5.2.1 of [RFC3449] gives best current practice on ACK >    filtering (aka. thinning or coalescing).  It gives no advice on ACKs >    carrying ECN feedback,  because at the time is said that "ECN remain >    areas of ongoing research".  This section updates that advice for a >    TCP connection that supports AccECN feedback. > > >GF> RFC3449 does however already note:    “Appropriate treatment is > also needed to preserve correct operation of ECN feedback (carried in > the TCP header) [RFC3168].“, which you could say you are now expanding > upon. [BB] I've added the following parenthesis: ...It gives no advice on ACKs carrying ECN feedback (other than that filtering ought to preserve the correct operation of ECN feedback), because at the time... > > >GF> I think the next section also hekps explains why ACK Filtering is > less needed, if a sender uses offload, and reduces its ACK rate, then > the -albeit *slightly* larger- AccECN ACKs are less frequent, and > therefore can be expected to be less problematic. [BB] Thanks for all this (I got the typos too). Cheers Bob > > Gorry > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------30AC2CFCA19B797871212455 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Gorry,

Thank you (as always) for checking this. Inline [BB]...

On 17/02/2021 16:47, Gorry Fairhurst wrote:
Bob,

After the last IETF I promised to try simplify the comment on the new ACK Filtering text in ACCECN.

I've included what the current draft says, and marked comments in the text as ">GF>" to try and be more specific about which words attracted the alst round of feedback:

3.3.3.  Requirements for TCP ACK Filtering

   A node that implements ACK filtering (aka. thinning or coalescing)
   and itself also implements ECN marking will not need to filter ACKs
   from connections that use AccECN feedback.  Therefore, such a node
   SHOULD detect connections that have negotiated the use of AccECN
   feedback during the handshake (see Table 2) and it SHOULD preserve
   the timing of each ACK (if it coalesced ACKs it would not be AccECN-
   compliant, but the requirement is stated as a "SHOULD" in order to
   allow leeway for pre-existing ACK filtering functions to be brought
   into line).

>GF> What does that "SHOULD" really mean? As far as I know, many devices that have RFC3449-like behaviours operate over links that have some specific property that changes the packet timing (perhaps half-duple; or transmission aligned to assigned time slots, or whatever). I therefore don’t understand “preserve timing”.

[BB] Sorry, that was hung over text from a previous way of saying it. Here's the sentence with improvements:

                                             Therefore, such a node
   SHOULD detect connections that are using AccECN feedback and it
   SHOULD refrain from filtering the ACKs of such connections...

You'll notice I've removed the mention of using the handshake to detect use of AccECN. Being less prescriptive allows a node to use whatever heuristics will work, if the designer can think of soemthing better.



   A node that implements ACK filtering and does not itself implement
   ECN marking does not need to treat AccECN connections any differently
   from other TCP connections.
Nonetheless, it is RECOMMENDED that such
   nodes implement ECN marking and comply with the requirements of the
   previoius

>GF> Typo

    paragraph.  This should be a better way than ACK filtering
   to improve the performance of AccECN TCP connections.

   The rationale for these requirements is that AccECN feedback provides
   sufficient information to a data receiver for it to be able to
   monitor ECN marking of the ACKs it has sent, so that it can thin the
   ACK stream itself.  This will eventually mean that ACK filtering in
   the network gives no performance advantage.  Then TCP will be able to
   maintain its own control over ACK coalescing.  This will also allow
   the TCP Data Sender to use the timing of ACK arrivals to more
   reliably infer further information about the path congestion level.

>GF> /This will eventually mean/This might eventually mean/:  because I think tis is an aspiration and maybe some nodes can use ECN to control ACK feedback, but is this always true? Given that link transmission can be very variable, and in the case of ACKs often becomes a limit per-packet rather than per-byte for typical data packets, I’m unsure how the implementation of ECN-marking against a variable jitter/capacity would interact with the capacity fluctuations from sharing media, or other physical layer propagation variations. I suggest this is an ambition rather than it necessarily being true that this will be better than any ACK Filtering method or FQ-style mitigation.

[BB] Agree. I've used "This could eventually mean". Slightly less vague IMO.


   Note that the specification of AccECN in TCP does not presume to rely
   on the above ACK filtering behaviour in the network, because it has
   to be robust against pre-existing network nodes that still filter
   AccECN ACKs, and robust against ACK loss during overload.

   Section 5.2.1 of [RFC3449] gives best current practice on ACK
   filtering (aka. thinning or coalescing).  It gives no advice on ACKs
   carrying ECN feedback,  because at the time is said that "ECN remain
   areas of ongoing research".  This section updates that advice for a
   TCP connection that supports AccECN feedback.

>GF> RFC3449 does however already note:    “Appropriate treatment is also needed to preserve correct operation of ECN feedback (carried in the TCP header) [RFC3168].“, which you could say you are now expanding upon.

[BB] I've added the following parenthesis:

               ...It gives no advice on ACKs
   carrying ECN feedback (other than that filtering ought to preserve
   the correct operation of ECN feedback), because at the time...

>GF> I think the next section also hekps explains why ACK Filtering is less needed, if a sender uses offload, and reduces its ACK rate, then the -albeit *slightly* larger- AccECN ACKs are less frequent, and therefore can be expected to be less problematic.

[BB] Thanks for all this (I got the typos too).

Cheers



Bob


Gorry 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------30AC2CFCA19B797871212455-- From nobody Mon Feb 22 15:49:18 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721B73A222C; Mon, 22 Feb 2021 15:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LzRtWq9M5SY; Mon, 22 Feb 2021 15:49:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 AA20B3A21AF; Mon, 22 Feb 2021 15:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614037717; bh=+G0S/zafLBi/5GqHxWOwiGP2WBp/iLFIQh8U6YXsCsc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=bL8cPhbEKnjQBVkiGVQ+ed0r2Itm6b2JEfdhFsAX+4jq8jpzmh3iABaqCpC/68GBE BtNTMVSl8k0ZUcXycDZC9AguuRSRAYHBqOPZniK/1HAP3FsxYie7VAezHRri1LvMMI 5XCDPyt30KJgkQTum9CATW+2Il2dDKsmCx0206eY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.115.128.90]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlf0U-1lfSER1Oss-00ilNJ; Tue, 23 Feb 2021 00:48:37 +0100 To: tcpm@ietf.org, draft-ietf-tcpm-prr-rfc6937bis.authors@ietf.org References: <161403428413.22042.205772629562934735@ietfa.amsl.com> From: "Scheffenegger, Richard" Message-ID: <7e134864-a450-451a-b357-569904a1c750@gmx.at> Date: Tue, 23 Feb 2021 00:48:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <161403428413.22042.205772629562934735@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:/pH5qB2Z/Pu3g9c0k3NRK8Ezz+XSgD7SHAifrVL2bjwIC1S8Xb+ 3StIOl4cN6uiPyrX/G65MoZTjT+RBPIzni1tuutDuVH++sjE+c/5VCmtiy3qp4RBVeGeNks e5OOd2Wk0FRaSj97MH2QdHPvLy6t02I8VOLY1e27OMR60uQh/4FfHtlPINpXWMKqLghC5aT RQDmMoUgejGqB4XO+7y7Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:bGAamuNHekw=:fkhE4IAvBdRY/oi8ekPPH0 nIYyrUd/4WGAWXX4R71zDjeCE8S9ve2DdWve/kwagNufl0YcvppiS1Ag26oAdZNSm34Zax/yD z9LNN8LxDdnqSACU/66kBNavxIBQX5W7epHMq6yCD+vYamZmNdn1WMgmcrnUineynzLvdu+99 wW5KeOQJbvU8wn2b1Z+WgQkHlnpibset5KgPURrN4bZAk76cfJTGtaCm7FZCS3pqnC6cjvR6z CRctcvsbrDIFY1KYKYzt3sOjn6MP5PB8N4RvQsxiwIQ33AmA6LJBFnGu4zGuH+x/+Fau1SJNw dHAHcsHs6RTxxDB61KXT/a1BuBL8QVhLFdKCvDpcz9m8UqiOr5/Y7io7kVg4/euUTqyOh6hOH rEElwhxZTlSljjVWSEpaNcS3XDsTDQVizPTV+sDLl+FNbLjjXYLlNRQw9MonKM/bTb3rFareM v5841pf5nXCkvPtyq/hSpkwp6F3rSIhyWtPBXm8U47xaTTkJIdWoNw4bKMsGXt/NjAHT22wOK x6X4YmzyTGe30xhurzmTjMeqxAoZWHI40jyUHZyf9gINq5bW0B5/GBl9gEM4i1oXRLyHzkes9 JpduvJGAKR+hAKMwZTU8P3mG5C03dfThQa0yehVIyOxcEPRntOUasM2zs132eEIST6LGawuOp OE4YmNcsTY8rIxOtwBrR10QgcgctVr9rKGDKixR/og6os7degkjZstrCb+NV+w09shFB3sZxw 4qovIomoi0H2zE9oUaz5TLcBMGA+7gyieoZGKGFzU3/Ok6hGZCEfrgXBj2J41Q0JybV4AIjYD fhz2k73UzcRN4T72dcjHD1KQexREPhAW9prpxbAvVhK9290e9K89MWar40JOVZFcaU/d51MxT /Q780LmwcW3d9sugLYcw== Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 23:49:17 -0000 Hi, Nit (Freudian slip?): Section 3, 1st para has "BBR-SSRB". Guess the hamming distance between the TLA BBR and PRR is too small :) Also, after having worked on that code lately, I don't think I fully agree with the wording in the statement here .... "recommended to use BBR-SSRB by default. For all of the environments explored in earlier PRR -> research, the new heuristic is consistent with the old -> recommendation." Reason being that the heuristic - as I understand it currently, before reading further into -01 - effectively switches to PRR-CRB during the first window after loss always (once pipe < ssthresh), and only enables PRR-SSRB in the 2nd window, when snd.una advances again after the retransmission(s) are delivered to the client. The prior recommendation was to generally use PRR-SSRB, critically also in the first window, when snd.una does not advance yet - provided pipe was smaller than ssthresh. And by that possibly increasing cwnd already. I guess the heuristic, as described, would never be in SSRB mode during the first window of loss recovery - unless the criterial is extended (e.g. advance of snd.fack [although not specified in the RFC series] without indication of additional loss (additional holes in the scoreboard)= . Also, LRD is mentioned in the text, but unless I am mistaken, RACK may be the only variant of TCP in the RFC series, where that is specified. Perhaps a short paragraph about the merit of the heuristic, when lost retransmission detection is not available (and a RTO will be needed in any case some time later) would be good. After all, assuming SACK, successfully retransmitting as many packets during the initial loss recovery epoch should help drive goodput up a little faster, and minimize the number of packets that RTO needs to recover, correct? Overall I like this 6937bis text! Best regards, Richard Am 22.02.2021 um 23:51 schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG= of the IETF. > > Title : Proportional Rate Reduction for TCP > Authors : Matt Mathis > Nandita Dukkipati > Yuchung Cheng > Filename : draft-ietf-tcpm-prr-rfc6937bis-01.txt > Pages : 18 > Date : 2021-02-22 > > Abstract: > This document updates the experimental Proportional Rate Reduction > (PRR) algorithm, described RFC 6937, to standards track. PRR > potentially replaces the Fast Recovery and Rate-Halving algorithms. > All of these algorithms regulate the amount of data sent by TCP or > other transport protocol during loss recovery. PRR accurately > regulates the actual flight size through recovery such that at the > end of recovery it will be as close as possible to the ssthresh, as > determined by the congestion control algorithm. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-prr-rfc6937bis-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-prr-rfc6937bis-01 > > > Please note that it may take a couple of minutes from the time of submis= sion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Feb 22 15:53:44 2021 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 AB2D03A21BE; Mon, 22 Feb 2021 15:53:27 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161403800764.17730.9265295789123341515@ietfa.amsl.com> Date: Mon, 22 Feb 2021 15:53:27 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 23:53:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : More Accurate ECN Feedback in TCP Authors : Bob Briscoe Mirja Kühlewind Richard Scheffenegger Filename : draft-ietf-tcpm-accurate-ecn-14.txt Pages : 59 Date : 2021-02-22 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 16:12:11 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B963A21D0 for ; Mon, 22 Feb 2021 16:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOC-drXROOBm for ; Mon, 22 Feb 2021 16:12:06 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.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 D7AD63A21CF for ; Mon, 22 Feb 2021 16:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DK3ACIUfgv6F1ygJQ10SZqYes8azMBnGoIvtEymXGqo=; b=CGElCLOx5mVLvGmldfSbBvMph QFjVPByEl9fHbnX/wTpWVRuvafA1zMEOeaB6nVDiZV2alkBKVPBNTv04ng7TrfAAg/DxOhOCiZqWm +x/wReg8i5F77JfjRmyyqxH0sxpZwCaRArA6IJt0LXJ60ysQS0PNU8FVzWFBJjeT4pnTsLRroFSFS iTxy9gVBvBHMd+/Lyd7xd5IRrzDanzlCsb7x26KNiEquUDqpj4wP/zsmqSMi9SX7nGXhXBBwRAWu8 8AFxSS1nLLl/P0omENf7jFYa4H3PW6S8jm0VbD3x6SwuFVH8f1/O/73h46h0A4bZUloZDFUJPMXMQ c/DOGLZNw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:56070 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lELJ3-0002sL-Bx; Tue, 23 Feb 2021 00:12:01 +0000 To: "Scheffenegger, Richard" , Mirja Kuehlewind Cc: tcpm IETF list , Richard Scheffenegger , Yoshifumi Nishada References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> From: Bob Briscoe Message-ID: Date: Tue, 23 Feb 2021 00:12:00 +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: <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> Content-Type: multipart/alternative; boundary="------------9AFC5D1F5DB8AC7C93F3708F" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Possible error in accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 00:12:08 -0000 This is a multi-part message in MIME format. --------------9AFC5D1F5DB8AC7C93F3708F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mirja, Richard, Yoshi, I just posted a new rev of AccECN for a number of other reasons, and realized we hadn't converged on an answer to the tricky problem in this old thread from Nov'20. For now, the text says the following (which I've justified below, but I don't think it's the solution yet), and I've asked Richard & Mirja if we (as co-authors) can act as a little design team to thrash out this problem in the next few days. 3.2.2.5.1. Data Receiver Safety Procedures An AccECN Data Receiver: o SHOULD immediately send an ACK whenever a data packet marked CE arrives after the previous packet was not CE. o MUST immediately send an ACK once 'n' CE marks have arrived since the previous ACK, where 'n' SHOULD be 2 and MUST be in the range 2 to 6 inclusive. Justification for first bullet: The aim is to trigger an ACK on a transition from non-CE to CE, but only when the latest packet is a data packet. Cases where the previous packet was a CE-marked pure ACK and therefore not ACK'd ought to be picked up by the 2nd bullet, not the first. Similarly, if there's CE-marked packets (data or pure ACKs) that haven't been ACKd yet, and the next data packet is not CE-marked, I think the first bullet is still correct, and the second rule will pick up cases with enough CE marks. The second bullet is more tricky. I've added Richard's suggesting of flooring 'n' at 2. But made no other changes. That's deliberate, 'cos I think it's sufficient to allow ACK CC to be added, but not to preclude it. And I think the danger of being interpreted as DupACKs shouldn't apply if there's no outstanding data. I know I'm wrong in those odd cases I mentioned when new data might cross the ACKs in the other direction. But I don't think that's going to cause too much harm. However, I'm probably very wrong. Somehow I feel we haven't got a good model to check all the possibilities. Bob On 17/11/2020 08:48, Scheffenegger, Richard wrote: > > See my suggestion; The critical requirement for the 2nd bullet point is, > to have n > 1 for pure, CE-marked ACKs. The exponential decay, after how > many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop, strongly > depends on "n", so the recommendation should be to use a higher value of > n in the case where you only observe a stream of pure ACKs (with or > without marks; only those marked would account against "n" though). > > In the case of data packets mixed in, you don't want to delay > excessively, thus "n" may be choosen lower... > > Richard > > > > Am 10.11.2020 um 17:38 schrieb Bob Briscoe: >> >> Moving on to the second bullet... >>>> The second bullet doesn't consider the possibility that the 'n'th CE >>>> mark might arrive on a pure ACK. Then, the wording as it stands says >>>> the Data Receiver MUST immediately ACK a pure ACK. I know TCP never >>>> ACKs a pure ACK, but I'm not actually sure it does any harm to do so >>>> in this case (it cannot cause an infinite loop of ACKs). However, >>>> given it would be unorthodox, we maybe ought to rule it out by >>>> rewording anyway? >>> [MK] I think we also can leave this as it is because if that ’n’ >>> packet is a pure ACK that still means that you have unacked data >>> packets with CE marks and you should trigger an ACK for those packet >>> now (rather than waiting for the delayed ACK timer to expire). However >>> this case is less important. Also we should probably make sure that >>> this doesn’t apply if there are only pure ACKs with CE marks, maybe by >>> add “if unacknowledged data are outstanding” or something. >> >> [BB] By the end of your last para you start to realize that, if the n'th >> CE mark arrives on pure ACK, it doesn't say anything about whether the >> previous (n-1) CE marks were on data or pure ACKs. >> >> Consider another common scenario; a server delivering chunks of video >> over a high BDP path (e.g. 500 packets per RTT), and going idle between >> times (perhaps in response to an "exceeded high watermark" data packet >> from the server). Now consider the possibility that the reverse path >> bottleneck builds a queue during each chunk, and starts CE marking >> towards the end of each chunk. Then, after the server stops sending a >> chunk, it continues to see a couple of hundred CE-marked pure ACKs >> arriving. >> >> However, by your proposed rule, it doesn't send any feedback, 'cos it >> has no data to acknowledge. So the client cannot regulate its ACK >> stream. That's just tough, 'cos the client will stop sending more pure >> ACKs after it has received the last data, which is before any later >> feedback from the server can reach it. >> >> However, if the client later sends a data packet that the server can >> acknowledge (e.g. "a low watermark" message), the server's ACE counter >> will have wrapped dozens of times, and the client won't be able to work >> out how many. That doesn't matter if a few round trips have elapsed - >> the congestion info will have become stale. But it does matter if it's >> fairly soon. >> >> Instead, if we keep the text of the second bullet... if the server's 'n' >> was 2, it would send a pure ACK for every other pure ACK it received. >> But, what if these pure ACKs from the server were also CE-marked? Then >> the client would feed back pure ACKs using its 'n'. This regression >> would eventually die out, but I don't like it. >> >> This conversation about the second bullet presumes AccECN is being used >> for ACK congestion control. I'm not comfortable with writing anything >> specific about ACK congestion control into a draft on the standards >> track. But I don't want to preclude AccECN being used for ACK CC. >> >> >> I believe the second bullet needs something changed to limit the ACKing >> of pure ACKs. However, before we put effort into wordsmithing, I'd like >> to hear whether you agree with the general idea of not defining what to >> do for ACK CC, but not precluding it. >> >> Cheers >> >> >> >> >> Bob >> >>> >>> Mirja >>> >>> >>> >>>> Thoughts anyone? >>>> >>>> >>>> Bob >>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe >>>> http://bobbriscoe.net/ >>> _______________________________________________ >>> 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/ --------------9AFC5D1F5DB8AC7C93F3708F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mirja, Richard, Yoshi,

I just posted a new rev of AccECN for a number of other reasons, and realized we hadn't converged on an answer to the tricky problem in this old thread from Nov'20. For now, the text says the following (which I've justified below, but I don't think it's the solution yet), and I've asked Richard & Mirja if we (as co-authors) can act as a little design team to thrash out this problem in the next few days.

3.2.2.5.1.  Data Receiver Safety Procedures

   An AccECN Data Receiver:

   o  SHOULD immediately send an ACK whenever a data packet marked CE
      arrives after the previous packet was not CE.

   o  MUST immediately send an ACK once 'n' CE marks have arrived since
      the previous ACK, where 'n' SHOULD be 2 and MUST be in the range 2
      to 6 inclusive.

Justification for first bullet: The aim is to trigger an ACK on a transition from non-CE to CE, but only when the latest packet is a data packet. Cases where the previous packet was a CE-marked pure ACK and therefore not ACK'd ought to be picked up by the 2nd bullet, not the first. Similarly, if there's CE-marked packets (data or pure ACKs) that haven't been ACKd yet, and the next data packet is not CE-marked, I think the first bullet is still correct, and the second rule will pick up cases with enough CE marks.

The second bullet is more tricky. I've added Richard's suggesting of flooring 'n' at 2. But made no other changes. That's deliberate, 'cos I think it's sufficient to allow ACK CC to be added, but not to preclude it. And I think the danger of being interpreted as DupACKs shouldn't apply if there's no outstanding data. I know I'm wrong in those odd cases I mentioned when new data might cross the ACKs in the other direction. But I don't think that's going to cause too much harm.

However, I'm probably very wrong. Somehow I feel we haven't got a good model to check all the possibilities.


Bob



On 17/11/2020 08:48, Scheffenegger, Richard wrote:

See my suggestion; The critical requirement for the 2nd bullet point is,
to have n > 1 for pure, CE-marked ACKs. The exponential decay, after how
many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop, strongly
depends on "n", so the recommendation should be to use a higher value of
n in the case where you only observe a stream of pure ACKs (with or
without marks; only those marked would account against "n" though).

In the case of data packets mixed in, you don't want to delay
excessively, thus "n" may be choosen lower...

Richard



Am 10.11.2020 um 17:38 schrieb Bob Briscoe:

Moving on to the second bullet...
The second bullet doesn't consider the possibility that the 'n'th CE
mark might arrive on a pure ACK. Then, the wording as it stands says
the Data Receiver MUST immediately ACK a pure ACK. I know TCP never
ACKs a pure ACK, but I'm not actually sure it does any harm to do so
in this case (it cannot cause an infinite loop of ACKs). However,
given it would be unorthodox, we maybe ought to rule it out by
rewording anyway?
[MK] I think we also can leave this as it is because if that ’n’
packet is a pure ACK that still means that you have unacked data
packets with CE marks and you should trigger an ACK for those packet
now (rather than waiting for the delayed ACK timer to expire). However
this case is less important. Also we should probably make sure that
this doesn’t apply if there are only pure ACKs with CE marks, maybe by
add “if unacknowledged data are outstanding” or something.

[BB] By the end of your last para you start to realize that, if the n'th
CE mark arrives on pure ACK, it doesn't say anything about whether the
previous (n-1) CE marks were on data or pure ACKs.

Consider another common scenario; a server delivering chunks of video
over a high BDP path (e.g. 500 packets per RTT), and going idle between
times (perhaps in response to an "exceeded high watermark" data packet
from the server). Now consider the possibility that the reverse path
bottleneck builds a queue during each chunk, and starts CE marking
towards the end of each chunk. Then, after the server stops sending a
chunk, it continues to see a couple of hundred CE-marked pure ACKs
arriving.

However, by your proposed rule, it doesn't send any feedback, 'cos it
has no data to acknowledge. So the client cannot regulate its ACK
stream. That's just tough, 'cos the client will stop sending more pure
ACKs after it has received the last data, which is before any later
feedback from the server can reach it.

However, if the client later sends a data packet that the server can
acknowledge (e.g. "a low watermark" message), the server's ACE counter
will have wrapped dozens of times, and the client won't be able to work
out how many. That doesn't matter if a few round trips have elapsed -
the congestion info will have become stale. But it does matter if it's
fairly soon.

Instead, if we keep the text of the second bullet... if the server's 'n'
was 2, it would send a pure ACK for every other pure ACK it received.
But, what if these pure ACKs from the server were also CE-marked? Then
the client would feed back pure ACKs using its 'n'. This regression
would eventually die out, but I don't like it.

This conversation about the second bullet presumes AccECN is being used
for ACK congestion control. I'm not comfortable with writing anything
specific about ACK congestion control into a draft on the standards
track. But I don't want to preclude AccECN being used for ACK CC.


I believe the second bullet needs something changed to limit the ACKing
of pure ACKs. However, before we put effort into wordsmithing, I'd like
to hear whether you agree with the general idea of not defining what to
do for ACK CC, but not precluding it.

Cheers




Bob


Mirja



Thoughts anyone?


Bob

--
________________________________________________________________
Bob Briscoe
http://bobbriscoe.net/
_______________________________________________
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/
--------------9AFC5D1F5DB8AC7C93F3708F-- From nobody Wed Feb 24 02:00:45 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1159C3A130E for ; Wed, 24 Feb 2021 02:00:43 -0800 (PST) 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 haq1d4jCBsd4 for ; Wed, 24 Feb 2021 02:00:41 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D35E03A130D for ; Wed, 24 Feb 2021 02:00:40 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id w19so1513591qki.13 for ; Wed, 24 Feb 2021 02:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1sv90p1Bbdmxoo2bqqFoLaYEfkXAMb7gy0rrSLMhVBg=; b=dpX0yc+A3ZuAxUl8ehoQnGGbzryHfCyEyzFCG6LwcT1qu9jj9KKmyjQQICiFYFIIz9 FY4c84alVhNvaFdjK+mbOYEDsUqL145WHUVrLu2CIr0RT6bAa+nf24EXSYF+yyuSHoi8 kH2iQ6lmLJ1cicaJUZ13txeUN12d3Bfv9O+h9Tbx0bOhw22VxdGrC/ulW1pTJSe7wJG4 OW22lWt8pHgAEKB7MR9mCsueArw/6Dd22SQoEsvNEQUeHidGJcoy4n5r3cqWY7g6sP4C Tt5JITjfIHNwclycGXjmZHxI2wQCY5JpkL5wXvWzEaezMLkjFm4uZNVEwK/Cu9d0L1IL tEVQ== 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=1sv90p1Bbdmxoo2bqqFoLaYEfkXAMb7gy0rrSLMhVBg=; b=BL8pH+uKiWRciFVl6ZV16YXcBKnKEoAg9TeFeQgxckrRH5kUW2aDJZcP26/Fmlw1Th Sx5ZnJuJMxaNwRMeGbQw8e6p3rrn2ydxBMU1AgFbTqWiCV3HzqDxLF+ZwBhxb9py/+r7 yC1oHwfku6CCBpETA0FWSDhn0JTkLvINNfOI+k8tXSJQn+pv4l5H0smnUD4XBmqICKM8 VhIErxWTz2/lb6n9b6AZvTw+NM8aVQlrVlG//eNtZ8AqQElD24BpEXPPAJL+MPUuVSDV inNECVhrqcJzOXdZ8JgqJZIaTOcJDn/92PSH9/t3V0gPwYXF6lBsecvmn1H0AHW7eNeN BQJA== X-Gm-Message-State: AOAM531bOJRQGxVWEOkxJKKnzp9rAR87g/AJwHwXrQaLZ4Ru+09oiIqx YYz1+/MgFT26TojN7gZ26s+Qyf23tVb39V69V2ygyS3y X-Google-Smtp-Source: ABdhPJyQHhTwrC6A+FEExhS98YxbKrZRUGmCo2+Ze/ah7EVpvgsP8Bhh0UAQKHXnzyc/3BmY5oOfYtxmqc6u/z400Aw= X-Received: by 2002:a05:620a:941:: with SMTP id w1mr765940qkw.484.1614160839801; Wed, 24 Feb 2021 02:00:39 -0800 (PST) MIME-Version: 1.0 References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> <04723570-93E7-4BB8-821E-BC3672A42F15@comsys.rwth-aachen.de> In-Reply-To: <04723570-93E7-4BB8-821E-BC3672A42F15@comsys.rwth-aachen.de> From: Yoshifumi Nishida Date: Wed, 24 Feb 2021 02:00:28 -0800 Message-ID: To: =?UTF-8?B?SmFuIFLDvHRo?= Cc: Matthew Luckie , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000777c6305bc121b51" Archived-At: Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 10:00:43 -0000 --000000000000777c6305bc121b51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, Thanks for providing very interesting information. I am guessing the ratio is not very high, but it's a good proof that we've still seen such nodes. (probably connection split middleboxes as you mentioned) Thanks for sharing! -- Yoshi On Mon, Feb 22, 2021 at 2:46 AM Jan R=C3=BCth wrote: > Hi everyone, > > maybe I can add to the measurements that Matthew cited. > We performed these only once. But we are doing other measurements that we > do more frequently. > > From these I can report further numbers that we never got around to > actually publish. > > We look for TFO support on port 80 and we send TFO cookie requests to all > of IPv4. > We get roughly 3.2M valid replies with TFO cookies (as of late 2019), > which rose from 500k (mid 2017). > > Regarding the mirrored options, we see around 70k - 80k empty cookie > replies (essentially, we get our cookie request back) that have the same > behavior as outlined in Olivier=E2=80=99s blogpost, this number is rather= stable, > sometimes 10k more or less. > This behavior is focussed on IPs residing in Chinese autonomous systems. > Our assumption has always been that this mirroring is performed by some > middlebox and not an end-host. > > If there is interest, I can perform these measurements with an unassigned > TCP option number. > > Best > Jan > > > > On 8. Feb 2021, at 23:15, Matthew Luckie wrote: > > > > Hi Richard, > > > > On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote: > >> Hi Yoshi, > >> > >> Sorry to nitpick - in your draft, you mention that some hosts reflect > >> back unknown tcp options, which is why you are using different GID > >> mappings between SYN and SYN,ACK. > >> > >> I did read about this behavior concerning TCP header flags / reserved > >> bits - but have not come across a paper where this behavior is describ= ed > >> for unknown TCP options (or I may have missed that aspect in the vario= us > >> studies around TCP option investigations done by MPTCP and other > groups). > > > > There is some discussion of systems that seem to reflect TCP options > here: > > > > > http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_mult= ipath_tcp.html > > > > Matthew_______________________________________________ > > 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 > --000000000000777c6305bc121b51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,

Thanks for providing= very interesting information.
I am guessing the ratio is not very hig= h, but it's a good proof that we've still seen such nodes. (probabl= y connection split middleboxes as you mentioned)
Thanks for sharing!
--
Yoshi=C2=A0=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 22, 2021 at 2:46 AM Jan R= =C3=BCth <Jan.Rueth@c= omsys.rwth-aachen.de> wrote:
Hi everyone,

maybe I can add to the measurements that Matthew cited.
We performed these only once. But we are doing other measurements that we d= o more frequently.

>From these I can report further numbers that we never got around to actuall= y publish.

We look for TFO support on port 80 and we send TFO cookie requests to all o= f IPv4.
We get roughly 3.2M valid replies with TFO cookies (as of late 2019), which= rose from 500k (mid 2017).

Regarding the mirrored options, we see around 70k - 80k empty cookie replie= s (essentially, we get our cookie request back) that have the same behavior= as outlined in Olivier=E2=80=99s blogpost, this number is rather stable, s= ometimes 10k more or less.
This behavior is focussed on IPs residing in Chinese autonomous systems. Our assumption has always been that this mirroring is performed by some mid= dlebox and not an end-host.

If there is interest, I can perform these measurements with an unassigned T= CP option number.

Best
=C2=A0Jan


> On 8. Feb 2021, at 23:15, Matthew Luckie <mjl@caida.org> wrote:
>
> Hi Richard,
>
> On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote= :
>> Hi Yoshi,
>>
>> Sorry to nitpick - in your draft, you mention that some hosts refl= ect
>> back unknown tcp options, which is why you are using different GID=
>> mappings between SYN and SYN,ACK.
>>
>> I did read about this behavior concerning TCP header flags / reser= ved
>> bits - but have not come across a paper where this behavior is des= cribed
>> for unknown TCP options (or I may have missed that aspect in the v= arious
>> studies around TCP option investigations done by MPTCP and other g= roups).
>
> There is some discussion of systems that seem to reflect TCP options h= ere:
>
> http://b= log.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_multipath_tcp.= html
>
> Matthew_______________________________________________
> 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
--000000000000777c6305bc121b51-- From nobody Wed Feb 24 02:03:47 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0AC3A1352 for ; Wed, 24 Feb 2021 02:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuQ-ICq9WuHt for ; Wed, 24 Feb 2021 02:03:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 D35B43A1333 for ; Wed, 24 Feb 2021 02:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614160959; bh=YvRj7v3gniIBF2PTJRISF6mRiVEoNo4d6lRzCQzR/II=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=D2FdJ34wGz0PMvQfSFqX3AV+T4O3t4/in7uCvLtaY3hswpx9OKwzXY+IEYL38BZ38 dISm71elxmofgxKneDzZgY9FKIvijYbkY1AMN/C3m29EwM0O+sBbgB5lfiAbeBDbpv T7KORm33fr6qnhqLgJB412X9lAxMR1wW9YWbCWWg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.165.130.59]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0G1d-1m06C80xSZ-00xNcB; Wed, 24 Feb 2021 11:02:39 +0100 To: Bob Briscoe , Mirja Kuehlewind Cc: tcpm IETF list , Richard Scheffenegger , Yoshifumi Nishada References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> From: "Scheffenegger, Richard" Message-ID: <042d369a-ac8e-4b4a-df36-a3dc7811f64a@gmx.at> Date: Wed, 24 Feb 2021 11:02:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:laze/FOM3o0mkNeCzSlWwdScEchTtOGAah8U8lA4VXf70eCjwdk bdMYojzDFYxKd0txXleUovdUJtmSheQWMJtQWwt2kY5vis1SwYSxARwB5/kCjbv2vHB05lm lO+/512Fq16zBwgzMFqt6dL2vEYsyPMZW8KvsnhGOksy6i5IQL9NL5rHmuk7AICSPaLMKY4 gmiUBH1zMgPuet2werklg== X-UI-Out-Filterresults: notjunk:1;V03:K0:OATqHj+lnZ8=:MAtPR6o8HsUKA6lfy1apFn Mx+DpcPIrOahg9+GIQixnV+NDO3ZGrezPvPurnVb6Kh+klAaMeO9N9ByiHlM+MvyPan1lOeYl T7AcPPbUCxpf40Qf90GW/SBOtPEM4MJxAQf4jyuomFTuoMD9G+LjY7xbPbnfIKNmy7KrvRvA2 yuHWJezpICyQsD4JdGRqeQMoYM2MyNAOf7/VGeU7UvNCHAJ0iXw+mv4Y2PaFlp8LX2G5hzAdx 5K+7Q+JXGIphvSY0We0LVK2wGu1T7PPLgEeZeQHi6m9hdBY4CueCnKpjZaOQ2PodBgt2HPtz6 /mlSXAMJmqiPadHIqHBTMx1QorlPSEmsfh9QrOFL7OLtQRgE+u9p1FLnEpPgaf6vYvngnsr92 S63i3FNxdLkvKrbgOift3wMYEx/HFtxOwbORdITamFLoDzjWrGxbAeBWncYMziWRpgn0AYQXv pdS9Fw+MYCPWACRjIVF86rVPezpdmW2LOEC7ze7/n7B6MxV6slVJsM6UTb5xV/vH/++HSNG06 B+jghueNpA/1QiDiyymvMxgxJQptc6nRwy3FB0bzlBS1mUYY6Hx3reXEUpSDEX9ASh7Fdb8NS ESK4n+Z6nxQUuc+X0hkR2EGjcVGc3L1aNPB6I+jy7z9HIGDG56eGIzXz7E4+0VFWlmLOQdtpO ARR8im64w0XWrtOxhLlMHP7QJX1csq1R7r90YAbbKROhSUvfSICwcJvNAg7n+pm66bQRxswQn 5oCf0VclZZx/2Gq63dApWqt7xLZe0YChKFA8LWmHOjcfoTegaj5UpnpLhhy/oRBXPLQmMkOye V2xHtNtopYSJKUxWjCkFOeMjZCsDR/UsMPGUDUqq0ILb/0Yr/ABqaLh3QydukidGSMSNPYSor EVq7npy6fcTHpadyOwNg== Archived-At: Subject: Re: [tcpm] Possible error in accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 10:03:45 -0000 Hi Bob, unless there is ACK duplication going on, I don't see how the current text would cause any issues. The only aspect I would emphasize is, that in the 2nd case, "n" MUST NOT be as low as one, as that may cause a ACK-triggering-ACK when the path exhibits a pathological misconfiguration, where all packets get CE marked. As long as a smaller numer of ACKs ("n" >=3D 2) carry a sum of CE marks seen from received frames, any such pathological paths would possible trigger a few rounds of ACKs, but these will eventually die down, correct? Do you have a different scenario in mind? Richard Am 23.02.2021 um 01:12 schrieb Bob Briscoe: > Mirja, Richard, Yoshi, > > I just posted a new rev of AccECN for a number of other reasons, and > realized we hadn't converged on an answer to the tricky problem in this > old thread from Nov'20. For now, the text says the following (which I've > justified below, but I don't think it's the solution yet), and I've > asked Richard & Mirja if we (as co-authors) can act as a little design > team to thrash out this problem in the next few days. > > 3.2.2.5.1. Data Receiver Safety Procedures > > An AccECN Data Receiver: > > o SHOULD immediately send an ACK whenever a data packet marked CE > arrives after the previous packet was not CE. > > o MUST immediately send an ACK once 'n' CE marks have arrived since > the previous ACK, where 'n' SHOULD be 2 and MUST be in the range = 2 > to 6 inclusive. > > > Justification for first bullet: The aim is to trigger an ACK on a > transition from non-CE to CE, but only when the latest packet is a data > packet. Cases where the previous packet was a CE-marked pure ACK and > therefore not ACK'd ought to be picked up by the 2nd bullet, not the > first. Similarly, if there's CE-marked packets (data or pure ACKs) that > haven't been ACKd yet, and the next data packet is not CE-marked, I > think the first bullet is still correct, and the second rule will pick > up cases with enough CE marks. > > The second bullet is more tricky. I've added Richard's suggesting of > flooring 'n' at 2. But made no other changes. That's deliberate, 'cos I > think it's sufficient to allow ACK CC to be added, but not to preclude > it. And I think the danger of being interpreted as DupACKs shouldn't > apply if there's no outstanding data. I know I'm wrong in those odd > cases I mentioned when new data might cross the ACKs in the other > direction. But I don't think that's going to cause too much harm. > > However, I'm probably very wrong. Somehow I feel we haven't got a good > model to check all the possibilities. > > > Bob > > > > On 17/11/2020 08:48, Scheffenegger, Richard wrote: >> >> See my suggestion; The critical requirement for the 2nd bullet point is= , >> to have n > 1 for pure, CE-marked ACKs. The exponential decay, after ho= w >> many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop, strongly >> depends on "n", so the recommendation should be to use a higher value o= f >> n in the case where you only observe a stream of pure ACKs (with or >> without marks; only those marked would account against "n" though). >> >> In the case of data packets mixed in, you don't want to delay >> excessively, thus "n" may be choosen lower... >> >> Richard >> >> >> >> Am 10.11.2020 um 17:38 schrieb Bob Briscoe: >>> >>> Moving on to the second bullet... >>>>> The second bullet doesn't consider the possibility that the 'n'th CE >>>>> mark might arrive on a pure ACK. Then, the wording as it stands says >>>>> the Data Receiver MUST immediately ACK a pure ACK. I know TCP never >>>>> ACKs a pure ACK, but I'm not actually sure it does any harm to do so >>>>> in this case (it cannot cause an infinite loop of ACKs). However, >>>>> given it would be unorthodox, we maybe ought to rule it out by >>>>> rewording anyway? >>>> [MK] I think we also can leave this as it is because if that =E2=80= =99n=E2=80=99 >>>> packet is a pure ACK that still means that you have unacked data >>>> packets with CE marks and you should trigger an ACK for those packet >>>> now (rather than waiting for the delayed ACK timer to expire). Howeve= r >>>> this case is less important. Also we should probably make sure that >>>> this doesn=E2=80=99t apply if there are only pure ACKs with CE marks,= maybe by >>>> add =E2=80=9Cif unacknowledged data are outstanding=E2=80=9D or somet= hing. >>> >>> [BB] By the end of your last para you start to realize that, if the n'= th >>> CE mark arrives on pure ACK, it doesn't say anything about whether the >>> previous (n-1) CE marks were on data or pure ACKs. >>> >>> Consider another common scenario; a server delivering chunks of video >>> over a high BDP path (e.g. 500 packets per RTT), and going idle betwee= n >>> times (perhaps in response to an "exceeded high watermark" data packet >>> from the server). Now consider the possibility that the reverse path >>> bottleneck builds a queue during each chunk, and starts CE marking >>> towards the end of each chunk. Then, after the server stops sending a >>> chunk, it continues to see a couple of hundred CE-marked pure ACKs >>> arriving. >>> >>> However, by your proposed rule, it doesn't send any feedback, 'cos it >>> has no data to acknowledge. So the client cannot regulate its ACK >>> stream. That's just tough, 'cos the client will stop sending more pure >>> ACKs after it has received the last data, which is before any later >>> feedback from the server can reach it. >>> >>> However, if the client later sends a data packet that the server can >>> acknowledge (e.g. "a low watermark" message), the server's ACE counter >>> will have wrapped dozens of times, and the client won't be able to wor= k >>> out how many. That doesn't matter if a few round trips have elapsed - >>> the congestion info will have become stale. But it does matter if it's >>> fairly soon. >>> >>> Instead, if we keep the text of the second bullet... if the server's '= n' >>> was 2, it would send a pure ACK for every other pure ACK it received. >>> But, what if these pure ACKs from the server were also CE-marked? Then >>> the client would feed back pure ACKs using its 'n'. This regression >>> would eventually die out, but I don't like it. >>> >>> This conversation about the second bullet presumes AccECN is being use= d >>> for ACK congestion control. I'm not comfortable with writing anything >>> specific about ACK congestion control into a draft on the standards >>> track. But I don't want to preclude AccECN being used for ACK CC. >>> >>> >>> I believe the second bullet needs something changed to limit the ACKin= g >>> of pure ACKs. However, before we put effort into wordsmithing, I'd lik= e >>> to hear whether you agree with the general idea of not defining what t= o >>> do for ACK CC, but not precluding it. >>> >>> Cheers >>> >>> >>> >>> >>> Bob >>> >>>> >>>> Mirja >>>> >>>> >>>> >>>>> Thoughts anyone? >>>>> >>>>> >>>>> Bob >>>>> >>>>> -- >>>>> ________________________________________________________________ >>>>> Bob Briscoe >>>>> http://bobbriscoe.net/ >>>> _______________________________________________ >>>> 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 Briscoehttp://bobbriscoe.net/ > From nobody Wed Feb 24 02:03:54 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4553A137D for ; Wed, 24 Feb 2021 02:03:47 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 jquGULmxlZ-V for ; Wed, 24 Feb 2021 02:03:44 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8023A1321 for ; Wed, 24 Feb 2021 02:03:43 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id c1so1012924qtc.1 for ; Wed, 24 Feb 2021 02:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7OGGpgaOotM/2pyPw8YZkXirksIDXQ9RMBf4KoAn45U=; b=LmIR/ucw4GvQOg5TmwlvFuy7uZhpaOC+OgMakwEHMPFHHMP7w/x+YiXmErYpWdf41X O3M1GfA5EzsDENQaoCr8WXABWbCqj7v3cQ+j/y5zFmhxvqHgC8EZhCQ7JyswYqoBEe3W HyozLk+JXVQRF2fu7i2iT4u1M7W6QscbyeswHC9ytNGfkqT4g1irm5Zo5ZgMjUnADvvm MdtqBg9l7ucVD3cMLqZktc7rJWJECy+G2ndJIit0PhMtK/bSRSga6ZXhL4MCDBUTl/7X /i0fuKbn6r8H73s/3N5Q35TUEN1z03G8R0N33PcclYYc4H+Bpv8t21qyCPqrBXrEfbxl tGkw== 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=7OGGpgaOotM/2pyPw8YZkXirksIDXQ9RMBf4KoAn45U=; b=tJpdmKY/CPGdQm4rOZBUEYqaIZEs/c2jbFdAoVMtDSTmF7R2BB7xlyRW4dWGFKb6eW M0S1y9C4cSwo/PulQvD3ZlGjYE0H4G1IJFKw7r0Wn9lRot2N1EvmYOZXMtMF6q31I65i hs3EuZ6MwiZ87J8/7Upf7UKzOTzSK93YgT3MW1cf6wrW+2C3igdlyBGsQqvovIqQBLAJ 0Tfys2JZcPVqQ64/jOhqad2QnWkT2U8R32kKEw45TKYYsTzoUVaG0Az59PMwWs+m4ReF 9yi4gmrkTjiy8JSMZ7PFlixKJXkkBUlcS7J46siQ5Bm60J8/JvHwXe74UQJV0pD57erw 0OJA== X-Gm-Message-State: AOAM531XdGtzPd1cSGgg9hFvrI6OXjlXAY6kdN2a4Ni48DWfCaCYUzTj UOWRSjgMvqZXzyTSx/uuE2fFJKpEMO4Ze0kgOqVz0cEv X-Google-Smtp-Source: ABdhPJwLLv1oQOrtfOxN0nplF6oaewcHr4yFFyRppoyr/hMv7y89lJriPCey92Oqyow874wiyqxOJLxVhAOXhdrCip8= X-Received: by 2002:ac8:350c:: with SMTP id y12mr9614465qtb.190.1614161022903; Wed, 24 Feb 2021 02:03:42 -0800 (PST) MIME-Version: 1.0 References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> In-Reply-To: From: Yoshifumi Nishida Date: Wed, 24 Feb 2021 02:03:31 -0800 Message-ID: To: Bob Briscoe Cc: "Scheffenegger, Richard" , Mirja Kuehlewind , Yoshifumi Nishada , tcpm IETF list , Richard Scheffenegger Content-Type: multipart/alternative; boundary="0000000000006168c205bc12266d" Archived-At: Subject: Re: [tcpm] Possible error in accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 10:03:52 -0000 --0000000000006168c205bc12266d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, On Mon, Feb 22, 2021 at 4:12 PM Bob Briscoe wrote= : > Mirja, Richard, Yoshi, > > I just posted a new rev of AccECN for a number of other reasons, and > realized we hadn't converged on an answer to the tricky problem in this o= ld > thread from Nov'20. For now, the text says the following (which I've > justified below, but I don't think it's the solution yet), and I've asked > Richard & Mirja if we (as co-authors) can act as a little design team to > thrash out this problem in the next few days. > > 3.2.2.5.1. Data Receiver Safety Procedures > > An AccECN Data Receiver: > > o SHOULD immediately send an ACK whenever a data packet marked CE > arrives after the previous packet was not CE. > > o MUST immediately send an ACK once 'n' CE marks have arrived since > the previous ACK, where 'n' SHOULD be 2 and MUST be in the range 2 > to 6 inclusive. > > > Justification for first bullet: The aim is to trigger an ACK on a > transition from non-CE to CE, but only when the latest packet is a data > packet. Cases where the previous packet was a CE-marked pure ACK and > therefore not ACK'd ought to be picked up by the 2nd bullet, not the firs= t. > Similarly, if there's CE-marked packets (data or pure ACKs) that haven't > been ACKd yet, and the next data packet is not CE-marked, I think the fir= st > bullet is still correct, and the second rule will pick up cases with enou= gh > CE marks. > > The second bullet is more tricky. I've added Richard's suggesting of > flooring 'n' at 2. But made no other changes. That's deliberate, 'cos I > think it's sufficient to allow ACK CC to be added, but not to preclude it= . > And I think the danger of being interpreted as DupACKs shouldn't apply if > there's no outstanding data. I know I'm wrong in those odd cases I > mentioned when new data might cross the ACKs in the other direction. But = I > don't think that's going to cause too much harm. > > This might be too pathological, but I'm thinking about a certain extreme example.. In my understanding, let's say a node sends 50 ACKs for some reasons and all ACKs have CE marks, then its peer sends back 25 ACKs. If these 25 ACKs have CE marks as well, it can generate another 12 ACKs, and so on. If this understanding is correct, I'm not sure if this is a good behavior. I am thinking we had better do something here such as don't send an ACK if the correspond ACKs carries accecn signals. Also, I think it's hard to tell there's no outstanding data from the receiver side. Let's say a sender send some data packets after sending 10 acks, and the receiver sends back 5 acks as the 10 ACKs have CE marks. In this case, they look like dup acks from the sender's point of view. I know this is a rare case, though. -- Yoshi > On 17/11/2020 08:48, Scheffenegger, Richard wrote: > > > See my suggestion; The critical requirement for the 2nd bullet point is, > to have n > 1 for pure, CE-marked ACKs. The exponential decay, after how > many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop, strongly > depends on "n", so the recommendation should be to use a higher value of > n in the case where you only observe a stream of pure ACKs (with or > without marks; only those marked would account against "n" though). > > In the case of data packets mixed in, you don't want to delay > excessively, thus "n" may be choosen lower... > > Richard > > > > Am 10.11.2020 um 17:38 schrieb Bob Briscoe: > > > Moving on to the second bullet... > > The second bullet doesn't consider the possibility that the 'n'th CE > mark might arrive on a pure ACK. Then, the wording as it stands says > the Data Receiver MUST immediately ACK a pure ACK. I know TCP never > ACKs a pure ACK, but I'm not actually sure it does any harm to do so > in this case (it cannot cause an infinite loop of ACKs). However, > given it would be unorthodox, we maybe ought to rule it out by > rewording anyway? > > [MK] I think we also can leave this as it is because if that =E2=80=99n= =E2=80=99 > packet is a pure ACK that still means that you have unacked data > packets with CE marks and you should trigger an ACK for those packet > now (rather than waiting for the delayed ACK timer to expire). However > this case is less important. Also we should probably make sure that > this doesn=E2=80=99t apply if there are only pure ACKs with CE marks, may= be by > add =E2=80=9Cif unacknowledged data are outstanding=E2=80=9D or something= . > > > [BB] By the end of your last para you start to realize that, if the n'th > CE mark arrives on pure ACK, it doesn't say anything about whether the > previous (n-1) CE marks were on data or pure ACKs. > > Consider another common scenario; a server delivering chunks of video > over a high BDP path (e.g. 500 packets per RTT), and going idle between > times (perhaps in response to an "exceeded high watermark" data packet > from the server). Now consider the possibility that the reverse path > bottleneck builds a queue during each chunk, and starts CE marking > towards the end of each chunk. Then, after the server stops sending a > chunk, it continues to see a couple of hundred CE-marked pure ACKs > arriving. > > However, by your proposed rule, it doesn't send any feedback, 'cos it > has no data to acknowledge. So the client cannot regulate its ACK > stream. That's just tough, 'cos the client will stop sending more pure > ACKs after it has received the last data, which is before any later > feedback from the server can reach it. > > However, if the client later sends a data packet that the server can > acknowledge (e.g. "a low watermark" message), the server's ACE counter > will have wrapped dozens of times, and the client won't be able to work > out how many. That doesn't matter if a few round trips have elapsed - > the congestion info will have become stale. But it does matter if it's > fairly soon. > > Instead, if we keep the text of the second bullet... if the server's 'n' > was 2, it would send a pure ACK for every other pure ACK it received. > But, what if these pure ACKs from the server were also CE-marked? Then > the client would feed back pure ACKs using its 'n'. This regression > would eventually die out, but I don't like it. > > This conversation about the second bullet presumes AccECN is being used > for ACK congestion control. I'm not comfortable with writing anything > specific about ACK congestion control into a draft on the standards > track. But I don't want to preclude AccECN being used for ACK CC. > > > I believe the second bullet needs something changed to limit the ACKing > of pure ACKs. However, before we put effort into wordsmithing, I'd like > to hear whether you agree with the general idea of not defining what to > do for ACK CC, but not precluding it. > > Cheers > > > > > Bob > > > Mirja > > > > Thoughts anyone? > > > Bob > > -- > ________________________________________________________________ > Bob Briscoe > http://bobbriscoe.net/ > > _______________________________________________ > 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/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000006168c205bc12266d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,


On Mon, Feb 22, 2021= at 4:12 PM Bob Briscoe <research@bobbriscoe.net> wrote:
=20 =20 =20
Mirja, Richard, Yoshi,

I just posted a new rev of AccECN for a number of other reasons, and realized we hadn't converged on an answer to the tricky problem in this old thread from Nov'20. For now, the text says the following (which I've justified below, but I don't think it's the sol= ution yet), and I've asked Richard & Mirja if we (as co-authors) can act as a little design team to thrash out this problem in the next few days.

3.2.2.5.1.  Data Receiver Safety Procedures

   An AccECN Data Receiver:

   o  SHOULD immediately send an ACK whenever a data packet marked CE
      arrives after the previous packet was not CE.

   o  MUST immediately send an ACK once 'n' CE marks have arrived s=
ince
      the previous ACK, where 'n' SHOULD be 2 and MUST be in the ra=
nge 2
      to 6 inclusive.

Justification for first bullet: The aim is to trigger an ACK on a transition from non-CE to CE, but only when the latest packet is a data packet. Cases where the previous packet was a CE-marked pure ACK and therefore not ACK'd ought to be picked up by the 2nd bullet= , not the first. Similarly, if there's CE-marked packets (data or pur= e ACKs) that haven't been ACKd yet, and the next data packet is not CE-marked, I think the first bullet is still correct, and the second rule will pick up cases with enough CE marks.

The second bullet is more tricky. I've added Richard's suggesti= ng of flooring 'n' at 2. But made no other changes. That's delibe= rate, 'cos I think it's sufficient to allow ACK CC to be added, but n= ot to preclude it. And I think the danger of being interpreted as DupACKs shouldn't apply if there's no outstanding data. I know I'm = wrong in those odd cases I mentioned when new data might cross the ACKs in the other direction. But I don't think that's going to cause to= o much harm.

This might be too pathological, but I'm= thinking about a certain extreme example..
In my understanding, = let's say a node sends 50 ACKs for some reasons and all ACKs have CE ma= rks, then its peer sends back 25 ACKs.
If these 25 ACKs have = CE marks as well, it can generate another 12 ACKs, and so on.
If = this understanding is correct, I'm not sure if this is a good behavior.= =C2=A0
I am thinking we had better do something here such as don&= #39;t send an ACK if the correspond ACKs carries accecn signals.
<= div>
Also, I think it's hard to tell there's no outst= anding data from the receiver side.=C2=A0
Let's say a sender = send some data packets after sending 10 acks, and the receiver sends back 5= acks as the 10 ACKs have CE marks.=C2=A0
In this case, they=C2= =A0look like dup acks from the sender's point of view.=C2=A0 I know thi= s is a rare case, though.

--
Yoshi
=



On 17/11/2020 08:48, Scheffenegger, Richard wrote:

See my suggestion; The critical requirement for the 2nd bullet point is,
to have n > 1 for pure, CE-marked ACKs. The exponential decay, after how
many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop, strongly
depends on "n", so the recommendation should be to use a hi= gher value of
n in the case where you only observe a stream of pure ACKs (with or
without marks; only those marked would account against "n" though).

In the case of data packets mixed in, you don't want to delay
excessively, thus "n" may be choosen lower...

Richard



Am 10.11.2020 um 17:38 schrieb Bob Briscoe:

Moving on to the second bullet...
The second bullet doesn't consider = the possibility that the 'n'th CE
mark might arrive on a pure ACK. Then, the wording as it stands says
the Data Receiver MUST immediately ACK a pure ACK. I know TCP never
ACKs a pure ACK, but I'm not actually sure it does any harm to do so
in this case (it cannot cause an infinite loop of ACKs). However,
given it would be unorthodox, we maybe ought to rule it out by
rewording anyway?
[MK] I think we also can leave this as it is because if that =E2=80=99n=E2=80=99
packet is a pure ACK that still means that you have unacked data
packets with CE marks and you should trigger an ACK for those packet
now (rather than waiting for the delayed ACK timer to expire). However
this case is less important. Also we should probably make sure that
this doesn=E2=80=99t apply if there are only pure ACKs with CE ma= rks, maybe by
add =E2=80=9Cif unacknowledged data are outstanding=E2=80=9D or s= omething.

[BB] By the end of your last para you start to realize that, if the n'th
CE mark arrives on pure ACK, it doesn't say anything about whether the
previous (n-1) CE marks were on data or pure ACKs.

Consider another common scenario; a server delivering chunks of video
over a high BDP path (e.g. 500 packets per RTT), and going idle between
times (perhaps in response to an "exceeded high watermark"= ; data packet
from the server). Now consider the possibility that the reverse path
bottleneck builds a queue during each chunk, and starts CE marking
towards the end of each chunk. Then, after the server stops sending a
chunk, it continues to see a couple of hundred CE-marked pure ACKs
arriving.

However, by your proposed rule, it doesn't send any feedback, 'cos it
has no data to acknowledge. So the client cannot regulate its ACK
stream. That's just tough, 'cos the client will stop sendin= g more pure
ACKs after it has received the last data, which is before any later
feedback from the server can reach it.

However, if the client later sends a data packet that the server can
acknowledge (e.g. "a low watermark" message), the server&= #39;s ACE counter
will have wrapped dozens of times, and the client won't be able to work
out how many. That doesn't matter if a few round trips have elapsed -
the congestion info will have become stale. But it does matter if it's
fairly soon.

Instead, if we keep the text of the second bullet... if the server's 'n'
was 2, it would send a pure ACK for every other pure ACK it received.
But, what if these pure ACKs from the server were also CE-marked? Then
the client would feed back pure ACKs using its 'n'. This regression
would eventually die out, but I don't like it.

This conversation about the second bullet presumes AccECN is being used
for ACK congestion control. I'm not comfortable with writing anything
specific about ACK congestion control into a draft on the standards
track. But I don't want to preclude AccECN being used for ACK CC.


I believe the second bullet needs something changed to limit the ACKing
of pure ACKs. However, before we put effort into wordsmithing, I'd like
to hear whether you agree with the general idea of not defining what to
do for ACK CC, but not precluding it.

Cheers




Bob


Mirja



Thoughts anyone?


Bob

--
________________________________________________________________
Bob Briscoe
http://bob= briscoe.net/
_______________________________________________
tcpm mailing list
tcpm@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tcpm


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

--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000006168c205bc12266d-- From nobody Wed Feb 24 05:31:02 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060093A15AF for ; Wed, 24 Feb 2021 05:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRrh37wfcND1 for ; Wed, 24 Feb 2021 05:30:59 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 3D08E3A15B1 for ; Wed, 24 Feb 2021 05:30:59 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:e1a1:46bc:bd4c:6188] (unknown [IPv6:2a00:ac00:4000:400:e1a1:46bc:bd4c:6188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id B0FD060030E for ; Wed, 24 Feb 2021 15:30:51 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1614173451; bh=FFURJFMPUqXVljcXNEHNZFj4cnwyk03ShQnVtRy8+/o=; h=From:Subject:Date:References:To:In-Reply-To; b=UOR5Tu6uM1L46LPfeXlnN9KBNW5p/GVPDzQJ4ffFwb9FgjHVAvuLgqI3rExIwc3IS yhn7Xl2DKReA3FMjGIND4qFJshfxCNZXEDbi3YIolLbjCM1q7+zIkzjSRfOMAQXIzb TteF99YfJnhJkSnIYAKOIOqolIzBuAVti+Ih6Go8= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_A6A29C89-DD61-4876-96AF-ACF2C5155246"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Feb 2021 15:30:50 +0200 References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> To: tcpm IETF list In-Reply-To: <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> Message-Id: <8AE4FBCD-70D4-41B8-8ED0-F65FD7A454C1@eggert.org> X-MailScanner-ID: B0FD060030E.A0D3D X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 13:31:01 -0000 --Apple-Mail=_A6A29C89-DD61-4876-96AF-ACF2C5155246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-2-22, at 10:54, Lars Eggert wrote: > We'd like to ask the WG to determine if this is ready for adoption. would a WG chair please acknowledge the request and let us know whether = an adoption call will be done? Thanks, Lars --Apple-Mail=_A6A29C89-DD61-4876-96AF-ACF2C5155246 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmA2VQoACgkQVLXDCb9w wVc0jg/+Po3JsxfTiFrZwXL1AxWMY+KGC0xla7jphUtrWPnpGhnKCCXFKeJwyOg1 2VFQMR0aTBqTGOXu0q7PqNH2+5GDVsR65kThty518uOsxpMVULY3qV0yo/eXoaK1 pQuKzu5Avmf+FhSSlbnfG3kpBiFYBVG6W4Kl03IJwZE6Ol6P9NnaXbKiHc2qANOE l+gOqypSw0KzN4dCl9iquI7IvGZTGQKaJQLr5K/RzXJKbcPIbIyCN1iSYWrDp2Oj lBSgun9nW+m9BiTseEHkMG2LaJdVSBJkaLJp0RWzV2Jypj4o6HZqlpPbD9lRjlw/ BnleoQR9ebWV4P3tieDkSaiNNIiI+sEy4Saz5epyf89VuQPs0A7yzkLnK2SY6gsf gGm0K0mwOYIdnBXSTKTE41+8LoDGoM+CrNR+T7JQOtvsLgTIAoJo4VvTRBt0NSdl deRyv6K53Ia/Ouocd8I6/oQ12VIl3om0Kotq7I47A59RBgmI3qjqWGK5rgN5Ufwy +0JToCfyeZ77PJtmxxLOTEUBiVokq+/hqrdoZj+imaxt0XLxqtt6xmiFpcQMU21u Yb+bWntsBbiq05UaucFh08ExvUpw4pBGLkbqhNFQRfz59QVfRGcNOSbD55RCdNZU hI9zoEU+UUm20m1Ig4WHnmBvYuS6acRq3UoGpK1Re1EIQPH51KI= =GJac -----END PGP SIGNATURE----- --Apple-Mail=_A6A29C89-DD61-4876-96AF-ACF2C5155246-- From nobody Wed Feb 24 06:04:08 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400AD3A160F for ; Wed, 24 Feb 2021 06:04:07 -0800 (PST) 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, 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=heistp.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZzmcVpBY8Qa for ; Wed, 24 Feb 2021 06:04:05 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666573A160E for ; Wed, 24 Feb 2021 06:04:05 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id l13so1921393wmg.5 for ; Wed, 24 Feb 2021 06:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=j3okCq5H3Y9ALIeYjwHRSwZnN9vKhlIpQSCuJcr+3EQ=; b=JkS76RwiHPv7GVm6boq5sprH01Ujlwgu1bQjTN91m5ulisZPNVcIpTjqo5zueR/xhk vEtKiC34OlzxjnpxwK7sVc5s/370zTfPfppvLu8mpgyJsROS2U7HDf0Fr1FfWyTXOSHs YKA2DRZwtMfnnFVHrkH+/2WDWt0ygf/vetCXYTeUvPlp+Zil8VjPv6+wJbfZbtUotO1O X2JWmHega2BZEF5VVRichERT+gxYCHONEqVY+47xtdI5lcp4ykQfHpBMxaLeHoccNphR NzPntt0uvsYEQRXOUZC85CzHpV5VPPY4dMZv5Ef87yGbKvgGgl0PqDPmU438YvKT4syi PPow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=j3okCq5H3Y9ALIeYjwHRSwZnN9vKhlIpQSCuJcr+3EQ=; b=nQxgNoY16gXBzmWoVz/Nl1cMprBL7APIr469+bvnqqhKKuYWTcCg41T5kGAvRRHwY6 CSmsYqFqeeldRDx1p4JzTpRoSyOpoI+M/xYDHIR6pih0PV8SOvKbgi1NWMZ1OAp88RL+ dcQrTKB/9N3/XBaPmgo99jHEJnedfEB9pPcepX1AlrBrP4sNR/UKCIzwhVgPx+lzevwh j0DK9pBJLBWl6ut4sjABnIRtLhb2Kk4fPZJkEIfaArAPDwFJTKZyg+47Hk3Me+za0GkK VMpgL/yC420YKWu1QWqiBa89LlmMMsUD0T4CRtZW5rCUE0lRa0uduo02Pl4+fmyoY2aD PPvQ== X-Gm-Message-State: AOAM533rhgcwARlhtEed+3TcyjREFW/mkmj1VMaejP2OwaG9H1ZM17yH CZRfnPvbTQ/RDv1Zj8byzxYhqA== X-Google-Smtp-Source: ABdhPJwjOjeJwlXumCzMKPkpisRpk8pGZICO0FbNYkdBfzQk9uOk4FoJo2cvyg9nXwmTB1WgMJtB7Q== X-Received: by 2002:a05:600c:4e8b:: with SMTP id f11mr3803314wmq.43.1614175443626; Wed, 24 Feb 2021 06:04:03 -0800 (PST) Received: from [10.72.0.88] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id h17sm3005111wrt.74.2021.02.24.06.04.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Feb 2021 06:04:03 -0800 (PST) Message-ID: <07c14ca8fbec0af016b58c7522ee654e603c748a.camel@heistp.net> From: Pete Heist To: Lars Eggert , tcpm IETF list Date: Wed, 24 Feb 2021 15:04:02 +0100 In-Reply-To: <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 14:04:07 -0000 I would support adoption of this draft. It should help to have documentation for a CCA that's been in active use for so many years, not least to support related CC work. Regards, Pete On Mon, 2021-02-22 at 10:54 +0200, Lars Eggert wrote: > Hi, > > we just submitted the -02 version of the CUBIC bis document. > > This version incorporates the major editorial changes we wanted to > make. > > We'd like to ask the WG to determine if this is ready for adoption. > Vidhi has asked for a presentation slot during IETF-110 for this ID, > but the adoption discussion IMO doesn't need to wait. > > Thanks, > Lars > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-eggert-tcpm-rfc8312bis- > > 02.txt > > Date: February 22, 2021 at 10:49:39 GMT+2 > > To: "Injong Rhee" , "Lars Eggert" > > , "Lisong Xu" , "Sangtae Ha" > > , "Vidhi Goel" > > > > > > A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt > > has been successfully submitted by Lars Eggert and posted to the > > IETF repository. > > > > Name: draft-eggert-tcpm-rfc8312bis > > Revision: 02 > > Title: CUBIC for Fast and Long-Distance Networks > > Document date: 2021-02-22 > > Group: Individual Submission > > Pages: 27 > > URL: > >            https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt > > Status: > >         https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/ > > Html: > >           https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html > > Htmlized: > >       https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 > > Diff: > >           https://www.ietf.org/rfcdiff?url2=draft-eggert-tcpm-rfc8312bis-02 > > > > Abstract: > >    CUBIC is an extension to the traditional TCP standards.  It > > differs > >    from the traditional TCP standards only in the congestion > > control > >    algorithm on the sender side.  In particular, it uses a cubic > >    function instead of a linear window increase function of the > >    traditional TCP standards to improve scalability and stability > > under > >    fast and long-distance networks.  CUBIC has been adopted as the > >    default TCP congestion control algorithm by Linux, Windows, and > > Apple > >    stacks. > > > >    This document updates the specification of CUBIC to include > >    algorithmic improvements based on these implementations and > > recent > >    academic work.  Based on the extensive deployment experience > > with > >    CUBIC, it also moves the specification to the Standards Track, > >    obsoleting [RFC8312]. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at > > tools.ietf.org. > > > > The IETF Secretariat > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Feb 24 06:14:49 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ADE3A1642 for ; Wed, 24 Feb 2021 06:14:46 -0800 (PST) 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 6T-zd-dYO4UD for ; Wed, 24 Feb 2021 06:14:44 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 78D4C3A162F for ; Wed, 24 Feb 2021 06:14:44 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id a2so1446267qtw.12 for ; Wed, 24 Feb 2021 06:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DvTO1bvev8HYZIab3Bl7w7PPU5cJ5rbIOmctU7ZDwsk=; b=Id7Z8gY0rsscD5j4xsOPYX7UyNfLOaI3HmNC5xpQxN+8VjW6hG7ClAULrNpzlwc2pj entw2flld7xzNqZg0U5mEmX1J56oJugU+70x+ymF+gFPAZI5fL6qeD/vRWPSydBRxANV /9X0R7Fj1o81YWJPWVeM8MYFLtlNfpfxWhtWcdxWGTFpn7bUDwc6xHYNEFSrWshSQvL7 r2tHysOp1A4hSMohyTm6scCdsHyA7E4jNIaBBvSeDe92qft/aetjbpvf/SH0bUf1Mt4y 4GbuniCyg6wRgQGGUz5Do19OSG1ZmIzS8W/5TjMR9luoJ8n1pSFXXcWmZ94o4YvokmYF u1Ng== 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=DvTO1bvev8HYZIab3Bl7w7PPU5cJ5rbIOmctU7ZDwsk=; b=QhoW97f2lfggU2KgbJDlGFlTGNsiApHu/XaqFF4jN3Rn12a1Mxn4TRAtwXnVd3pJIH nvf4v9LeLtnxJmjDjRHq+2JqY2VQa5nH+z6IKsqOpWWzKQyJ//6Djw/nsIx/aq/EEMMC SM12aJNFJXTS5iuFKiB838CYu8aoRK1D/FTP83NvsNCNe1BS6758TSD2SL8nrIif2gDo cTzbnyEmG81GNTJcJM+fwj59Fla64di1eqwAm6Cy8Ax/zrck7UAjBFt3ec7Iaa+Z5xBH /llkqAOohkhgYzLqyFNKPdF8Nn2JnFVQ9EJ1Pj9EpZoq+ChHjbMXh6YeN64+nTskTRYo rv3w== X-Gm-Message-State: AOAM530RMbHFjGlNhwe0Sfpn+F5ZQ3b1adHKJJ3QuJ/vzwZYIiWQbE0x 59DbFzyZCYzwctRGH+rekiw5oPXyau5q/ZuY3EI= X-Google-Smtp-Source: ABdhPJyhdlzLhPVS3qb2XjQ9VfgfMmVsMWRo9yQpoCVBnofRbkLT3Auy1IH2XcuVdyeHH8iUeERhNXUifp+y0SuV93Y= X-Received: by 2002:aed:3201:: with SMTP id y1mr15761917qtd.106.1614176083404; Wed, 24 Feb 2021 06:14:43 -0800 (PST) MIME-Version: 1.0 References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <07c14ca8fbec0af016b58c7522ee654e603c748a.camel@heistp.net> In-Reply-To: <07c14ca8fbec0af016b58c7522ee654e603c748a.camel@heistp.net> From: Loganaden Velvindron Date: Wed, 24 Feb 2021 18:14:32 +0400 Message-ID: To: Pete Heist Cc: Lars Eggert , tcpm IETF list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 14:14:46 -0000 I also support moving this document forward. On Wed, Feb 24, 2021 at 6:04 PM Pete Heist wrote: > > I would support adoption of this draft. It should help to have > documentation for a CCA that's been in active use for so many years, > not least to support related CC work. > > Regards, > Pete > > On Mon, 2021-02-22 at 10:54 +0200, Lars Eggert wrote: > > Hi, > > > > we just submitted the -02 version of the CUBIC bis document. > > > > This version incorporates the major editorial changes we wanted to > > make. > > > > We'd like to ask the WG to determine if this is ready for adoption. > > Vidhi has asked for a presentation slot during IETF-110 for this ID, > > but the adoption discussion IMO doesn't need to wait. > > > > Thanks, > > Lars > > > > > > > Begin forwarded message: > > > > > > From: internet-drafts@ietf.org > > > Subject: New Version Notification for draft-eggert-tcpm-rfc8312bis- > > > 02.txt > > > Date: February 22, 2021 at 10:49:39 GMT+2 > > > To: "Injong Rhee" , "Lars Eggert" > > > , "Lisong Xu" , "Sangtae Ha" > > > , "Vidhi Goel" > > > > > > > > > A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt > > > has been successfully submitted by Lars Eggert and posted to the > > > IETF repository. > > > > > > Name: draft-eggert-tcpm-rfc8312bis > > > Revision: 02 > > > Title: CUBIC for Fast and Long-Distance Networks > > > Document date: 2021-02-22 > > > Group: Individual Submission > > > Pages: 27 > > > URL: > > > https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/ > > > Html: > > > https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html > > > Htmlized: > > > https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 > > > Diff: > > > https://www.ietf.org/rfcdiff?url2=draft-eggert-tcpm-rfc8312bis-02 > > > > > > Abstract: > > > CUBIC is an extension to the traditional TCP standards. It > > > differs > > > from the traditional TCP standards only in the congestion > > > control > > > algorithm on the sender side. In particular, it uses a cubic > > > function instead of a linear window increase function of the > > > traditional TCP standards to improve scalability and stability > > > under > > > fast and long-distance networks. CUBIC has been adopted as the > > > default TCP congestion control algorithm by Linux, Windows, and > > > Apple > > > stacks. > > > > > > This document updates the specification of CUBIC to include > > > algorithmic improvements based on these implementations and > > > recent > > > academic work. Based on the extensive deployment experience > > > with > > > CUBIC, it also moves the specification to the Standards Track, > > > obsoleting [RFC8312]. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Feb 24 09:00:59 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3EE3A1815 for ; Wed, 24 Feb 2021 09:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=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 EiKnJ-ilUvGS for ; Wed, 24 Feb 2021 09:00:57 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69D63A1813 for ; Wed, 24 Feb 2021 09:00:56 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id r23so3231267ljh.1 for ; Wed, 24 Feb 2021 09:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RhgxyKCq9Gdb6Yxekc3Z+bstTydspYqfR38UAkw1U+k=; b=DcwICBdTM7URTfOpE8Wf75phm6OEo+TycG0WMJySHmjuqykMElWlqlkGY/NGvL2Ikr y/0xgQtKp0F25JLqLthhR9IDL97bDgQDOhQhDQezmkp+b9IovZ8esZ96HM66Nh/n2RRf 7rx3oAu0m0+KY7tqUYBVXAISj03stsxcMg7C4HDAnVESDkXQ73GJOkOtSn1hK8vgq+bL YYAK5TgsmDX7FlfrYXESpuIiMTGShqc0GxFPUzO2VX0Du1iSmLW4FgU9Mp8Dvn6JnwSs chVfSAiFt9fPstcz8UedTvH7s3O9MsTfVHpGsufC6WZMYKCbbU3W0YxoNftjCHRWHwGY AQEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RhgxyKCq9Gdb6Yxekc3Z+bstTydspYqfR38UAkw1U+k=; b=ByGqzzJ69XAXRbJeVfZhM1I8YDmz5q1n45iOoOXhy8NZvZiYHZXAeiav710jMe550A U58TRig6qP/8DZz2Hsd6kNawNfi5/dufaW29Z0L4vLavHlY2ObDDLOy9WiILgaDuK+pj OgHCDbUfuBoDQsMZcKyEAGMJemspUAza9SLdYiwbXtjH6o3vKUhqJAfUdS17oPc/4UHb GzXSaBcwl8iPHqHwvIcswRxYB95YqUkgIXaM3dIARswp6k7nu+OfvE72CuOFedAJKvIX TVlEeHaYysLmYEcKeJgHAbdgZUpggdMNg5kP0zfTp9Jl5FzXh5mgcZFJbZOHuBk4BzCw hqqg== X-Gm-Message-State: AOAM531jif/3tmTVJN3bHh+736SFC0SUSrdV/As0MxqroSutSrh6cBw6 xjSJtjdLdWvTKIJraRotqb4= X-Google-Smtp-Source: ABdhPJzohyP3hFKrzAXwZ86rQ7JjYQ+Mb8p1Y668Yc4iaU3SS/Gmjm6MIJuXC8VWC4TG9SAN34XFUA== X-Received: by 2002:a05:651c:509:: with SMTP id o9mr20176161ljp.369.1614186054779; Wed, 24 Feb 2021 09:00:54 -0800 (PST) Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id d4sm179532lfs.45.2021.02.24.09.00.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Feb 2021 09:00:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Wed, 24 Feb 2021 19:00:52 +0200 Cc: "Scheffenegger, Richard" , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <3a6f9e55-9193-18e1-af60-cbed17571f4f@gmx.at> To: Lars Eggert X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 17:00:58 -0000 > On 22 Feb, 2021, at 5:57 pm, Lars Eggert wrote: >=20 > Agreed, and we are targeting this for PS at the moment for this reason = (whether the community agrees with this remains to be seen). I support adoption on this basis, and look forward to the review = process. - Jonathan Morton= From nobody Wed Feb 24 10:33:58 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30B3A183A for ; Wed, 24 Feb 2021 10:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HJtpZV4bi69 for ; Wed, 24 Feb 2021 10:33:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 B34B33A197D for ; Wed, 24 Feb 2021 10:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614191576; bh=7Lr0CeQBWKj8J9W3MmDMxPobMoS/z178qtSM4QnSljk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=j4sFwe/JBESuWSY/4wFi2hB4qFa0dwwcLM3HKUOe0TE+T/TaQbarwsvK8KyGPzmiS Ttnb4pk+XLyH03eNv1RXhPFe4mbxmzpQozIIXTZn8k4RpZjsvLy3za+h/I32CXU+W9 5m1MhvfosJgJPGOhmbxAcWdoS+1wxuUABksvthg0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([91.141.1.227]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McY8d-1lpPa10cvd-00d01R; Wed, 24 Feb 2021 19:32:56 +0100 To: Yoshifumi Nishida , Bob Briscoe Cc: Mirja Kuehlewind , Yoshifumi Nishada , tcpm IETF list , Richard Scheffenegger References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> From: "Scheffenegger, Richard" Message-ID: <8151fdef-ae78-80f3-adfc-d40db878ac8e@gmx.at> Date: Wed, 24 Feb 2021 19:32:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:YpKADUI1EmowLDeRr8kLqcpgz8Tk4NMYIRbAcpmKN5zbsr4dsST M4EIQw6bh9rnVB7nhgBlJ1hYGu0TlQVPoCMTCn2G+za/77CQLRjAVkitAWdHlPtCHujaghr N8rKWAId0rBpO+G61XHlMfgtPzhkf26Kl9jupiUPUBVnG4QMho834yq4PnyoNgpahIrTda/ GnsnUcSZ+S5kko5UWyLaQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:jb4PM/Wy5k0=:FJP2iO8RE71MZH+wpyinZA 8ryJlsNPGY2lCnyBh9frGo+xgxuh3vjsj2BdEa5cgLb6IZCPNjlPc5yprU2y0LsLiv+HnYZCO axbrD1dIrrGcrQiGcEwrqd2G4ibT1hyTLp/HqDseVWgvk2o8KOf2cWiDEl+PUdDgO4Fr0MyUQ rxdf6QH01Zn/0lQwVT3vvEGAWHPy3g685049xCJeEHUVnVfq0aeHFMNU0oXMXIlh3YMXiV/FO lUvl+R0BMMJlKMh6ZaZug33UaFS6kaSwg9Rmcjr9jVc69MBdrzOWmoSPMM2ikgiBG6mwv/yAv FEOA39fzI6f65UQWH8r33w3QVRnDd1TSPVtGV6aPH6eZltsp19/He2rCkAaq74uD71BXnrekM pEf69rN4dSBP9OqIxOPtf4Tca09TsThUpqbB664mi5icHkn0eDZq33SDAthPUVcIeeksZWZpA dRGx/07EbB9II/MjtYkfxW8mWJ+KLK6twMtnuX6BQWFL2okCPzSJLL9yemW8r9W9njkXClrsO DhJKH8yzNvFNUpi1aJtBy2KpOfOh6KR0150uprI0Civ/Vw6e5zTkvP1Vdum/XXacKLQKb1isQ 1rnr7jLF+CgD89tyszx0DQqnuNey5hZ+EGfGGCwUD23mUItq2R6EsPKi+7eAKhDfTZv4q+ORA D4zB2Yj1HkG3eJKw8WfgKKsfD0oNv5YLUaKzpAvfGze2d0rSXQp30F8HkiJN3jQdb6fc3zQhs OMSJ/jKcM5pEBetV7cSiXhPLffnzuuB83clNtKxQd8+AehrQLPnqv5qbSjCFLJaNp/Rr4fci9 Nw9sd3RLBsjwemIxEL4v3TwM7KAFRTNPcL5sIF9P5O26HBaIomzV0LuUO0uLpWI5i5OZYvUOq o4Awy6d7sH9cWLRqRayw== Archived-At: Subject: Re: [tcpm] Possible error in accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 18:33:57 -0000 Hi Yoshi, A valid concern. Two ways to remediate these at least to some extent: a) used a "n" higher than 2 (e.g. 6) b) refrain from sending the ACK for n CE immediately, but hold off for either the delayed ack timeout, or the n+1'th receipt of CE, or a valid data segment by that time. While this would not fully rule out any possibilty of an inadvertend DupAck, it significantly reduces the time window when this may happen. Also, if an implementation uses other clues (e.g. TS opt, SACK negotiated but not present in the ACKs incrementing the CE.P ), ambiguity can be further reduced. However, I feel that these optimizations may overburden the definition of the mechanism. Best regards, Richard Am 24.02.2021 um 11:03 schrieb Yoshifumi Nishida: > Hi Bob, > > > On Mon, Feb 22, 2021 at 4:12 PM Bob Briscoe > wrote: > > Mirja, Richard, Yoshi, > > I just posted a new rev of AccECN for a number of other reasons, and > realized we hadn't converged on an answer to the tricky problem in > this old thread from Nov'20. For now, the text says the following > (which I've justified below, but I don't think it's the solution > yet), and I've asked Richard & Mirja if we (as co-authors) can act > as a little design team to thrash out this problem in the next few d= ays. > > 3.2.2.5.1. Data Receiver Safety Procedures > > An AccECN Data Receiver: > > o SHOULD immediately send an ACK whenever a data packet marked = CE > arrives after the previous packet was not CE. > > o MUST immediately send an ACK once 'n' CE marks have arrived s= ince > the previous ACK, where 'n' SHOULD be 2 and MUST be in the ra= nge 2 > to 6 inclusive. > > > Justification for first bullet: The aim is to trigger an ACK on a > transition from non-CE to CE, but only when the latest packet is a > data packet. Cases where the previous packet was a CE-marked pure > ACK and therefore not ACK'd ought to be picked up by the 2nd bullet, > not the first. Similarly, if there's CE-marked packets (data or pure > ACKs) that haven't been ACKd yet, and the next data packet is not > CE-marked, I think the first bullet is still correct, and the second > rule will pick up cases with enough CE marks. > > The second bullet is more tricky. I've added Richard's suggesting of > flooring 'n' at 2. But made no other changes. That's deliberate, > 'cos I think it's sufficient to allow ACK CC to be added, but not to > preclude it. And I think the danger of being interpreted as DupACKs > shouldn't apply if there's no outstanding data. I know I'm wrong in > those odd cases I mentioned when new data might cross the ACKs in > the other direction. But I don't think that's going to cause too > much harm. > > This might be too pathological, but I'm thinking about a certain extreme > example.. > In my understanding, let's say a node sends 50 ACKs for some reasons and > all ACKs have CE marks, then its peer sends back 25 ACKs. > If these 25 ACKs have CE marks as well, it can generate another 12 ACKs, > and so on. > If this understanding is correct, I'm not sure if this is a good behavio= r. > I am thinking we had better do something here such as don't send an ACK > if the correspond ACKs carries accecn signals. > > Also, I think it's hard to tell there's no outstanding data from the > receiver side. > Let's say a sender send some data packets after sending 10 acks, and the > receiver sends back 5 acks as the 10 ACKs have CE marks. > In this case, they=C2=A0look like dup acks from the sender's point of vi= ew. > I know this is a rare case, though. > > -- > Yoshi > > > > On 17/11/2020 08:48, Scheffenegger, Richard wrote: >> >> See my suggestion; The critical requirement for the 2nd bullet >> point is, >> to have n > 1 for pure, CE-marked ACKs. The exponential decay, >> after how >> many ACKs triggered by CE-marked ACKs these ACK-for-ACK stop, >> strongly >> depends on "n", so the recommendation should be to use a higher >> value of >> n in the case where you only observe a stream of pure ACKs (with or >> without marks; only those marked would account against "n" though). >> >> In the case of data packets mixed in, you don't want to delay >> excessively, thus "n" may be choosen lower... >> >> Richard >> >> >> >> Am 10.11.2020 um 17:38 schrieb Bob Briscoe: >>> >>> Moving on to the second bullet... >>>>> The second bullet doesn't consider the possibility that the >>>>> 'n'th CE >>>>> mark might arrive on a pure ACK. Then, the wording as it stands >>>>> says >>>>> the Data Receiver MUST immediately ACK a pure ACK. I know TCP >>>>> never >>>>> ACKs a pure ACK, but I'm not actually sure it does any harm to >>>>> do so >>>>> in this case (it cannot cause an infinite loop of ACKs). However= , >>>>> given it would be unorthodox, we maybe ought to rule it out by >>>>> rewording anyway? >>>> [MK] I think we also can leave this as it is because if that =E2= =80=99n=E2=80=99 >>>> packet is a pure ACK that still means that you have unacked data >>>> packets with CE marks and you should trigger an ACK for those >>>> packet >>>> now (rather than waiting for the delayed ACK timer to expire). >>>> However >>>> this case is less important. Also we should probably make sure th= at >>>> this doesn=E2=80=99t apply if there are only pure ACKs with CE ma= rks, >>>> maybe by >>>> add =E2=80=9Cif unacknowledged data are outstanding=E2=80=9D or s= omething. >>> >>> [BB] By the end of your last para you start to realize that, if >>> the n'th >>> CE mark arrives on pure ACK, it doesn't say anything about >>> whether the >>> previous (n-1) CE marks were on data or pure ACKs. >>> >>> Consider another common scenario; a server delivering chunks of >>> video >>> over a high BDP path (e.g. 500 packets per RTT), and going idle >>> between >>> times (perhaps in response to an "exceeded high watermark" data >>> packet >>> from the server). Now consider the possibility that the reverse pa= th >>> bottleneck builds a queue during each chunk, and starts CE marking >>> towards the end of each chunk. Then, after the server stops >>> sending a >>> chunk, it continues to see a couple of hundred CE-marked pure ACKs >>> arriving. >>> >>> However, by your proposed rule, it doesn't send any feedback, >>> 'cos it >>> has no data to acknowledge. So the client cannot regulate its ACK >>> stream. That's just tough, 'cos the client will stop sending more >>> pure >>> ACKs after it has received the last data, which is before any late= r >>> feedback from the server can reach it. >>> >>> However, if the client later sends a data packet that the server c= an >>> acknowledge (e.g. "a low watermark" message), the server's ACE >>> counter >>> will have wrapped dozens of times, and the client won't be able >>> to work >>> out how many. That doesn't matter if a few round trips have >>> elapsed - >>> the congestion info will have become stale. But it does matter if >>> it's >>> fairly soon. >>> >>> Instead, if we keep the text of the second bullet... if the >>> server's 'n' >>> was 2, it would send a pure ACK for every other pure ACK it >>> received. >>> But, what if these pure ACKs from the server were also CE-marked? >>> Then >>> the client would feed back pure ACKs using its 'n'. This regressio= n >>> would eventually die out, but I don't like it. >>> >>> This conversation about the second bullet presumes AccECN is >>> being used >>> for ACK congestion control. I'm not comfortable with writing >>> anything >>> specific about ACK congestion control into a draft on the standard= s >>> track. But I don't want to preclude AccECN being used for ACK CC. >>> >>> >>> I believe the second bullet needs something changed to limit the >>> ACKing >>> of pure ACKs. However, before we put effort into wordsmithing, >>> I'd like >>> to hear whether you agree with the general idea of not defining >>> what to >>> do for ACK CC, but not precluding it. >>> >>> Cheers >>> >>> >>> >>> >>> Bob >>> >>>> >>>> Mirja >>>> >>>> >>>> >>>>> Thoughts anyone? >>>>> >>>>> >>>>> Bob >>>>> >>>>> -- >>>>> ________________________________________________________________ >>>>> Bob Briscoe >>>>> http://bobbriscoe.net/ >>>> _______________________________________________ >>>> 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 Briscoehttp://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Wed Feb 24 10:47:57 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA253A19B1 for ; Wed, 24 Feb 2021 10:47:56 -0800 (PST) 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 lBYQerXBXkDd for ; Wed, 24 Feb 2021 10:47:54 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CE43A19B0 for ; Wed, 24 Feb 2021 10:47:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9FD8B25A16; Wed, 24 Feb 2021 19:47:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1614192472; bh=BI2zutXjFK5RClzxPX1aanX+qFRdaXLazufLpOLR3xE=; h=From:To:Subject:Date:References:In-Reply-To:From; b=H5PxR63bi9jsRVQeHHXQSP3x4i5ztz/x/g/SYp4bbL3m8I/VtXtCQ0r7YWHhcMwSM DLcJJOvA6YKuRZmx08cPLdIibJO4USwut7wT/A2UpZUVEYoKSlM4EeEPKl6+Fq9kri YSBEr/n3WRP8bEPMOonaSd5DLYQVafIbunjERU1E= 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 OT1oVSKHXENS; Wed, 24 Feb 2021 19:47:51 +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, 24 Feb 2021 19:47:51 +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.2176.2; Wed, 24 Feb 2021 19:47:50 +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.2176.004; Wed, 24 Feb 2021 19:47:50 +0100 From: "Scharf, Michael" To: Lars Eggert , tcpm IETF list Thread-Topic: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt Thread-Index: AQHXCrFUu0V1xwQ27U2fZ1so0oykn6pnntLw Date: Wed, 24 Feb 2021 18:47:50 +0000 Message-ID: References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <8AE4FBCD-70D4-41B8-8ED0-F65FD7A454C1@eggert.org> In-Reply-To: <8AE4FBCD-70D4-41B8-8ED0-F65FD7A454C1@eggert.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002F_01D70AE5.EE01E890" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 18:47:57 -0000 ------=_NextPart_000_002F_01D70AE5.EE01E890 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Lars, > -----Original Message----- > From: tcpm On Behalf Of Lars Eggert > Sent: Wednesday, February 24, 2021 2:31 PM > To: tcpm IETF list > Subject: Re: [tcpm] New Version Notification for > draft-eggert-tcpm-rfc8312bis- > 02.txt > > Hi, > > On 2021-2-22, at 10:54, Lars Eggert wrote: > > We'd like to ask the WG to determine if this is ready for adoption. > > would a WG chair please acknowledge the request and let us know whether an > adoption call will be done? The chairs will get back - obviously. However, the DelACK principle should not be a big surprise ;-) Until the DelACK timer expires, three foods for thought: 1/ Version -02 was submitted 2 days ago and at least I *always* read drafts entirely before any formal action. A large number of drafts was submitted in the last days as well, i.e., my reading list is not empty. And at least I do have a day job, too. 2/ The TCPM chairs live in different time zones and usually sync before decisions. The RTT may be 12h+X. 3/ I am not sure whether we have to seriously discuss *whether* to adopt a widely implemented specification. But there could be some questions on the *how*. For instance, would ICCRG have to be in the loop? How about use beyond TCP, e.g., would a syncing with the QUIC WG make sense (you may actually have a better understanding on that than me)? And are there any TCP RFCs that assume that only a single standard congestion control exist and that would perhaps have to be updated? Maybe the TCPM chairs have to do some homework that cannot be completed easily within 2 days? Michael PS: As individual contributor, I obviously support adoption. ------=_NextPart_000_002F_01D70AE5.EE01E890 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUQzCCA8Mw ggKroAMCAQICAQEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSswKQYDVQQKDCJULVN5 c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5c3RlbXMgVHJ1c3Qg Q2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAyMB4XDTA4MTAwMTEw NDAxNFoXDTMzMTAwMTIzNTk1OVowgYIxCzAJBgNVBAYTAkRFMSswKQYDVQQKDCJULVN5c3RlbXMg RW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVy MSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAyMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAql/aG1/oc5Hl2lz0ouZH5fNoVWAFHQKks5tZ8x6KrzSt/A3C2UgZ7mmP ySD8IaoHGe2wXKxlx1/tAnx7fC0b1rq5gMIYghaE+mawCMZUI4HkzblJP/ZPbjdIKDgPxb7naHD9 OZdN0seYkVCqxESzI305R+lSYtYSk163MZZCBft2px6j9cL86XrFbKlxT+rLeLxgr8fe9NnLvn4z pW6Ug/A0+iGr6o5yoD+k3jBb74ZNapVbQ0SoEBUc5QFXxZjx5gYokaogxbdTJlFDsgsRlVjhwA92 2cCNfIHzcnCeb/4ajtlfNcaybzR8vkhP4lo519ideJ6fhj4DXhmLRKLVxwIDAQABo0IwQDAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUv1kgNgB5oKAia4zV8mHSuCzL gkowDQYJKoZIhvcNAQELBQADggEBADEDomELH3TocjbGbflNnvoiqOGBVs/Nu5/qq5EZOK+qfBVN 87ajjaX0jvZEqafoIZWtPgBiFojwArr8YSPmM5swems2YnutBCOEWGXi2yuK5yVTN2JTX7zaAWIp oqYnceY6In7Bbx2VcCBKBzTf6v8VgOW613rYW3V8BXopR35AqDETd81AO7RRR3ouEeNHEd6dZtCL 1VRm+oNV6nzCKYkb6W+zzuIFhMkvPniFYm7JX8F4Y3RYwEgYDJk566TMGrV5Wo0VnNgUDfZ6B1fH IoMFLTybJSY9GLOpQ3zIyKtkjw6jv5wbnTDb2tAZLqo88fszgHbkza0ZTwUnjhOhbsIwggUSMIID +qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSswKQYDVQQK DCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5c3RlbXMg VHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAyMB4XDTE2 MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQKEzxWZXJl aW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4x EDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN 6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZ N7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDc Nb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9 s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKG MUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba 1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/ BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYG Z4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUHMAGG IGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIwDQYJKoZI hvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6dl2e6BiC lmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+hFvu+c+Z 6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWST1k+kEcQ SrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7h0S2EQvV DFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKADAgECAgcb Y7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNV BAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHpl cyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNz dWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZ ojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNM Zj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhf ZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08WkVK usqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQD AgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNVHQ4EFgQU azqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIMz+EwgY8G A1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1j YS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYIKwYBBQUH MAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+ aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFq PnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dG dfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISo KTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuE GMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2Kgt dRXYShjqFu9VNCIaE40GMIIFsjCCBJqgAwIBAgIMI/viJVKSOmtM0W1AMA0GCSqGSIb3DQEBCwUA MIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERl dXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTIwMTIxODA4MTMxMVoXDTIzMTIxODA4 MTMxMVowRTELMAkGA1UEBhMCREUxHTAbBgNVBAoMFEhvY2hzY2h1bGUgRXNzbGluZ2VuMRcwFQYD VQQDDA5NaWNoYWVsIFNjaGFyZjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9SHEr 2Rs3bBtBgJuVYVqTID1hx3CGaTe4w1wyr49AoUHjr2WDvXTJb3ZQbIITkxllcWQ0vPLJkjfQ+k8z WaUZdVBN3TP0A8D5tAtoFjF3QQ4zgJbyO7bUVjl1oq2ENj9iwR84I2jmKTC+RoWIwuNjRNwFy7oB gNp7t+xJv52gCsglJnqfc0IresBkG2xY+OnBTWtXHxKaR4RaInOGbR0vLQGPHgpPouQzQTMzMFoK Q4ykq5bzwf09MEsD86M7KXFQP6o8za6cMCj/fpUKgyLGFd9QLItKOtWHq1Ko8BBjcLahHSmORp0L shk0B9BLxmwRtQoug9PfIzAbPJTKn7MCAwEAAaOCAlcwggJTMD4GA1UdIAQ3MDUwDwYNKwYBBAGB rSGCLAEBBDAQBg4rBgEEAYGtIYIsAQEECDAQBg4rBgEEAYGtIYIsAgEECDAJBgNVHRMEAjAAMA4G A1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFEkV E0rtKcQiFAJH003k3dDYMFE8MB8GA1UdIwQYMBaAFGs6mIv58lOJ2uCtsjIeCR/oqjt0MCkGA1Ud EQQiMCCBHm1pY2hhZWwuc2NoYXJmQGhzLWVzc2xpbmdlbi5kZTCBjQYDVR0fBIGFMIGCMD+gPaA7 hjlodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5j cmwwP6A9oDuGOWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY3Js L2NhY3JsLmNybDCB2wYIKwYBBQUHAQEEgc4wgcswMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBj YS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBJBggrBgEFBQcwAoY9aHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBJBggrBgEFBQcwAoY9 aHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAUxgSTwDOYsAoqIF7vrwhSbPQ42nyfLHWdmjlWFq1bA6B nRhSYnK+6CGz6q1MVMS74hk3NyUjHa5KUkPpVC/0nA9Y/gFsHT/8ogqLs71vr8HVtxzKSFTymmhR HVIQoOKrzaP4VxD0hKf2krAJLVj78o9qBOBcwpr8xnRDRLe5fQJx3YFlu7lDecj1Ncx10Rwy1ZBe Yh8YeEpWot1fYF4krmrjIcZ+jnr0zrE4y0qZbq4FrcSAEj/+0+m1OCEgB6IPdKstr89VCX2/35Ls GgqVpK6GA+MiTxVlGwAsTZ9maOBC/t5PKaAAC2bWJzZdAT4oHro3RBwRSZT6m/vua2u1ZzGCBCMw ggQfAgEBMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5n IGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJ MSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwj++IlUpI6a0zRbUAwCQYF Kw4DAhoFAKCCAlkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEw MjI0MTg0NzQ4WjAjBgkqhkiG9w0BCQQxFgQUw8U/dxOPBQYVYsusZXQsHKZF2PQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwga8GCSsGAQQBgjcQBDGBoTCBnjCBjTELMAkGA1UE BhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9y c2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVp biBHbG9iYWwgSXNzdWluZyBDQQIMI/viJVKSOmtM0W1AMIGxBgsqhkiG9w0BCRACCzGBoaCBnjCB jTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0 c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwc REZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMI/viJVKSOmtM0W1AMA0GCSqGSIb3DQEBAQUA BIIBAFnJ0arR7gMHi+ZtZW8VXkrxOMRBZMO3u80qqDVyS556g4G2CTMVbWSUbkYFVA/rgadRequS E+ZWSMsmJKZCS9GNdkyWAP6KZLJ8bVBcmJiNxBdQ4bbiZad72jHK2NM9QAIrBmcutp70boZBhq52 GEfJVoGRQtejG+gw694IfMkM5XF9CIg+LOUulmETt6s8gJjxhXGdEt+UTwesTUQRP+Yzi31ZWVbk tlj4osiV+34sfghGkhn72hq2oYUlAIZlYvS0+qqhRhE9ftseE8p5Aatk6BedZJQmgOrDo6qm3rHl jMq+kehNqvdu7borKUAu9XE0Zr6PJJ2YlHiq4Z3RBRYAAAAAAAA= ------=_NextPart_000_002F_01D70AE5.EE01E890-- From nobody Wed Feb 24 11:47:19 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCE43A1A86 for ; Wed, 24 Feb 2021 11:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEBSoGdsvuhN for ; Wed, 24 Feb 2021 11:47:10 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 0D73C3A1AB5 for ; Wed, 24 Feb 2021 11:47:09 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:a01f:7513:87e9:8a39] (unknown [IPv6:2a00:ac00:4000:400:a01f:7513:87e9:8a39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id AE99B60030E; Wed, 24 Feb 2021 21:46:49 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1614196009; bh=w9ZLSGB7L9GgRlZ3Q6s3XpSEcKIxNfhLX8U5vimEOb8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=PreXBjirBp2lhlA2WmRxjsc20AiiI8NTTv8EKddE7NSaWdGCCTRJqVLMn8cI3GDN0 OPEp32XU8UJhBCH7jr9gDfKjseUTeJHObzRr9sA+M4V+A9C2UUCak5bX8DdWK7HwkV 8ykpk+yYF5nZxjhhQEjwR+X4BbDbFqdF47GME5zQ= From: Lars Eggert Message-Id: <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_63E307F4-2E89-4739-AE23-79A7787EE51E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Feb 2021 21:46:49 +0200 In-Reply-To: Cc: tcpm IETF list To: "Scharf, Michael" References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <8AE4FBCD-70D4-41B8-8ED0-F65FD7A454C1@eggert.org> X-MailScanner-ID: AE99B60030E.A2AEF X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 19:47:18 -0000 --Apple-Mail=_63E307F4-2E89-4739-AE23-79A7787EE51E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-2-24, at 20:47, Scharf, Michael = wrote: > 1/ Version -02 was submitted 2 days ago and at least I *always* read = drafts > entirely before any formal action. A large number of drafts was = submitted in > the last days as well, i.e., my reading list is not empty. And at = least I do > have a day job, too. understood. I did make the same request when -01 was posted already, = hence I was wondering if it had fallen through the cracks. > 3/ I am not sure whether we have to seriously discuss *whether* to = adopt a > widely implemented specification. But there could be some questions on = the > *how*. For instance, would ICCRG have to be in the loop? They could, but I don't know if they have to. IIRC we run new CC schemes = by them for review, but this isn't really one of those. > How about use beyond > TCP, e.g., would a syncing with the QUIC WG make sense (you may = actually have > a better understanding on that than me)? We have https://github.com/NTAP/rfc8312bis/issues/45 open for that. It = not clear at this time whether any additional text is needed to explain = more about how QUIC would use CUBIC, a bunch of changes were made = already to this purpose. > And are there any TCP RFCs that > assume that only a single standard congestion control exist and that = would > perhaps have to be updated? I'm sure there are a bunch of TCP specs that only cite NewReno, but = that's probably OK? I'm not sure if finding and updating them just to = say "you may also use CUBIC" is all that worthwhile. Also, we didn't do = this for 8312 (or any other experimental/informational CC scheme) so = it's not clear why we'd do so for 8312bis. Thanks, Lars --Apple-Mail=_63E307F4-2E89-4739-AE23-79A7787EE51E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmA2rSkACgkQVLXDCb9w wVdjvRAAlpGit857EZ2Omgi/sZ0/QepGa8cZcn3XxtDUtgTZ1wvbd95IiqRZV19F nuoargkiqIPhMWmwsYxlxUxtxPT2gxRYM6awLZBgYsZTAPC7zOm4ZWygANLrDeWI UVXY8IaB91d+/qlGtYBG/7IzPyk1AXF97L1If2m96OqaY9T8wlUfaDdzjuwtArvx 8Cb/7s9U69w5cnSqae+m5ojLD83J10qNOqeI0SVcOD0DMgP5gjeiHE2UCOZf8/9M Y8sDp5OB1RT4x1p01OqO6bcablrdgHghvdivNTRDEz3snTIIqzAZzm8BcDUGWNb3 YGW1qsLlqZ2QkoSq1Wlwyg2aUXNu8G8R61PChRz+Un9lUjVp/ZlZiNBj2RQGX/kr UxxOwIVmdn6YO8B4EJ0j3128RnupxaviWbFYX4J1Z40MnVAyMIHkiKzWVErrc+8Y ZthV2IERMah/RbuPEPzmaaVUoMKDYHpfdbdp8/pb4hCamo+VU8ieiPh+eOrFX7Vf CqiUHLbXjCaCHjt9FYxkPisUMACGzXdoxQnau8YO5LAp29vzZmoGirpw7RTLnkEI oaJM7BjHhI6M4QRfd3YUGC+mjVjT4oeZeVOonPy8qV8FkGOhxEke77H6opumVMAN P1Ox9XPtC3CgUR6f8o83Y6Cc07UA1rj5rgYzFD0x3N9l9apA4uA= =Tq7X -----END PGP SIGNATURE----- --Apple-Mail=_63E307F4-2E89-4739-AE23-79A7787EE51E-- From nobody Wed Feb 24 12:27:22 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4749B3A1AD3 for ; Wed, 24 Feb 2021 12:27:20 -0800 (PST) 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 mrW9vAR-SQZY for ; Wed, 24 Feb 2021 12:27:18 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032373A1AD2 for ; Wed, 24 Feb 2021 12:27:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 57BC825A15; Wed, 24 Feb 2021 21:27:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1614198435; bh=G/OIOjGYZ2OSV47trU5yZgpQ4VXV6LFQ1GvnDDSH1cE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=jnQteFQbUt4ec445NECFs29Tkhn6sgk0fmL/avljvHNCm2vis/+OGIjR4X+aiK1y4 4oqAGzT5Duy+LHGd3ggK0ivuJs7n63QUEaVfawCj7RxgnmOJVWRmRSwl9Ip7qGi/f0 SQXP72I1l6zeCGoMK2KUXNjsvUrTRw9BMdVwJyIM= 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 V4-zNUhI1imA; Wed, 24 Feb 2021 21:27:14 +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, 24 Feb 2021 21:27:14 +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.2176.2; Wed, 24 Feb 2021 21:27:14 +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.2176.004; Wed, 24 Feb 2021 21:27:14 +0100 From: "Scharf, Michael" To: Lars Eggert CC: tcpm IETF list Thread-Topic: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt Thread-Index: AQHXCrFUu0V1xwQ27U2fZ1so0oykn6pnntLwgAAGnICAABIkQA== Date: Wed, 24 Feb 2021 20:27:13 +0000 Message-ID: <03d53edab59b43db8fdacb1449395f2b@hs-esslingen.de> References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <8AE4FBCD-70D4-41B8-8ED0-F65FD7A454C1@eggert.org> <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org> In-Reply-To: <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org> 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] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 20:27:20 -0000 > > How about use beyond > > TCP, e.g., would a syncing with the QUIC WG make sense (you may actuall= y > have > > a better understanding on that than me)? >=20 > We have https://github.com/NTAP/rfc8312bis/issues/45 open for that. It no= t > clear at this time whether any additional text is needed to explain more > about how QUIC would use CUBIC, a bunch of changes were made already to > this purpose. The chair-ish question is whether the QUIC WG needs to be in the loop in a = more formal way. The TCPM charter states: TCP's congestion control algorithms are the model followed by other IETF transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. In other related cases, TCPM has decided during WG adoption to run a joint = WGLC with TSVWG. We could decide to do something similarly in this case, e.= g., a joint WGLC with the QUIC WG. That is something that would probably ha= ve to be agreed upon in the TCPM adoption call. But I am unsure; the expert= ise may be in the TCPM community anyway... Please feel free to chime in... > > And are there any TCP RFCs that > > assume that only a single standard congestion control exist and that wo= uld > > perhaps have to be updated? >=20 > I'm sure there are a bunch of TCP specs that only cite NewReno, but that'= s > probably OK? I'm not sure if finding and updating them just to say "you m= ay > also use CUBIC" is all that worthwhile. Also, we didn't do this for 8312 = (or any > other experimental/informational CC scheme) so it's not clear why we'd do > so for 8312bis. The new congestion control text in 793bis probably helps here. Maybe the wo= rding in 793bis is just sufficient. But I haven't looked at the details. I = guess a lot of old text was written under the assumption that there is *one= * standard congestion control algorithm only. Unlike earlier CC schemes, 83= 12bis on standards track changes that. Now we have at leas two. It would be= better to understand the implications early. Michael From nobody Wed Feb 24 13:20:54 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEE63A1BFF for ; Wed, 24 Feb 2021 13:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6rRKQngxAfN for ; Wed, 24 Feb 2021 13:20:45 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 D918A3A1BF2 for ; Wed, 24 Feb 2021 13:20:44 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:a548:cb36:fecb:8dea] (unknown [IPv6:2a00:ac00:4000:400:a548:cb36:fecb:8dea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 6661A60030E; Wed, 24 Feb 2021 23:20:36 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1614201636; bh=XlHF7OJvgIHb8dW9dWbVozmLcMGtN4bQM5CFo/QMwV0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=We7taVlTjAeT//VBL5XzfI4Edsu9n8hva7rGCW5YlOK5O6j77CuFh4+cSmB1XO3mv HcRdQCRvrdixrJCOxDFXelCkSgHhWZtp5kMq2k4SaQfdocj74PGr4/Ko/nTwe65bId J8kuToHTFs1YTUjQmd5HIL8Pslz2LK3V3Bz5T2/k= From: Lars Eggert Message-Id: <995E2207-A731-4C75-A2D2-21088AB8B4D7@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B03251DA-4684-4C71-86BD-50A5EDC2A399"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Feb 2021 23:20:34 +0200 In-Reply-To: <03d53edab59b43db8fdacb1449395f2b@hs-esslingen.de> Cc: tcpm IETF list To: "Scharf, Michael" References: <161398377991.29967.7361793221575196028@ietfa.amsl.com> <91381C80-C49D-47F4-BA59-776625089A0D@eggert.org> <8AE4FBCD-70D4-41B8-8ED0-F65FD7A454C1@eggert.org> <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org> <03d53edab59b43db8fdacb1449395f2b@hs-esslingen.de> X-MailScanner-ID: 6661A60030E.A0213 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.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, 24 Feb 2021 21:20:53 -0000 --Apple-Mail=_B03251DA-4684-4C71-86BD-50A5EDC2A399 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-2-24, at 22:27, Scharf, Michael = wrote: > In other related cases, TCPM has decided during WG adoption to run a = joint WGLC with TSVWG. We could decide to do something similarly in this = case, e.g., a joint WGLC with the QUIC WG. That is something that would = probably have to be agreed upon in the TCPM adoption call. But I am = unsure; the expertise may be in the TCPM community anyway... Please feel = free to chime in... we certainly can, there are no downsides IMO. I'd be surprised if we saw = significant feedback that we'd otherwise not see though. > The new congestion control text in 793bis probably helps here. Maybe = the wording in 793bis is just sufficient. But I haven't looked at the = details. I guess a lot of old text was written under the assumption that = there is *one* standard congestion control algorithm only. Unlike = earlier CC schemes, 8312bis on standards track changes that. Now we have = at leas two. It would be better to understand the implications early. I think the text in 793bis is fine as-is. If we're still making changes = to that, we could add some text about CUBIC being a specific suitable = alternative, but I see no strong reason to argue for that. Thanks, Lars --Apple-Mail=_B03251DA-4684-4C71-86BD-50A5EDC2A399 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmA2wyIACgkQVLXDCb9w wVeE/Q/+OI/y7HWG58boBvPcZ/EeuN21kPiSGK3BwMVnH10Ya1CbGizwQB/he6iJ bT16X6HAaOaW4gfqym1f09JtvOsiMolAcZOF6RBow/tRY4HBwEZAqFoeyNPx/7w8 JR+mwSIh0kuiDhq7RFvTOwEQJ/QHsTrCoRI7AzcZR8sEnaPs9NzgParlZNeRUsJo fE1F65HT3rE66c+elSspzzof4vOeOst1Zp65I4pda97Vaa5jl1fC0FIu2gvlNdC9 kdONo9Ho311FEDXAx2LqTTblurbb0MCi99Ngkm0Qu0Syxeml/KW3hDDwTVVwdqKb 114vxzZqiUOv7vDjl/iRzsFDyiFwRPehcU2nMIGF9cbc9/NqpNWJuK6Lc04PZL1a Dp2S4a7XozKNO1Cgkeso15A6prTGNUNjBKRNTDVQlJJSvRfN/VnWlnPZYG/PPp3d a5TsFBGlsPAX/SBS7NqyIpkBwN6z9v5WXynnyLvYoGK9xNYZWvDFU76FVvsHFyax pUcpm+wcDDmyhjWFMi/JWKgJBZoYpno1PA6k8ze9hv5GDbptgBV5XyvemTR19Vh2 eS18Tyxd40+JLVLVdoLTh/ugQar5MPzNmvUrG46QRRzTYkU8tyFUBhU57qSv7jQO aogKKSyzG7r9i1e+2OlHqGLF61Wx0b4gi+kAuAKNiB6fWQLKNjU= =EPkq -----END PGP SIGNATURE----- --Apple-Mail=_B03251DA-4684-4C71-86BD-50A5EDC2A399-- From nobody Thu Feb 25 05:54:24 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D723A15A6 for ; Thu, 25 Feb 2021 05:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhDbj9iwQ5a5 for ; Thu, 25 Feb 2021 05:54:21 -0800 (PST) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570F93A19EA for ; Thu, 25 Feb 2021 05:54:20 -0800 (PST) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 11PDsBCg025846; Thu, 25 Feb 2021 05:54:11 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 11PDsBsn025845; Thu, 25 Feb 2021 05:54:11 -0800 (PST) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202102251354.11PDsBsn025845@gndrsh.dnsmgr.net> In-Reply-To: <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org> To: Lars Eggert Date: Thu, 25 Feb 2021 05:54:11 -0800 (PST) CC: "Scharf, Michael" , tcpm IETF list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 13:54:23 -0000 Hello Lars, WG members, One comment inline below marked [RWG] > Hi, > > On 2021-2-24, at 20:47, Scharf, Michael wrote: > > 1/ Version -02 was submitted 2 days ago and at least I *always* read drafts > > entirely before any formal action. A large number of drafts was submitted in > > the last days as well, i.e., my reading list is not empty. And at least I do > > have a day job, too. > > understood. I did make the same request when -01 was posted already, hence I was wondering if it had fallen through the cracks. > > > 3/ I am not sure whether we have to seriously discuss *whether* to adopt a > > widely implemented specification. But there could be some questions on the > > *how*. For instance, would ICCRG have to be in the loop? > > They could, but I don't know if they have to. IIRC we run new CC schemes by them for review, but this isn't really one of those. > > > How about use beyond > > TCP, e.g., would a syncing with the QUIC WG make sense (you may actually have > > a better understanding on that than me)? > > We have https://github.com/NTAP/rfc8312bis/issues/45 open for that. It not clear at this time whether any additional text is needed to explain more about how QUIC would use CUBIC, a bunch of changes were made already to this purpose. > > > And are there any TCP RFCs that > > assume that only a single standard congestion control exist and that would > > perhaps have to be updated? > > I'm sure there are a bunch of TCP specs that only cite NewReno, but that's probably OK? I'm not sure if finding and updating them just to say "you may also use CUBIC" is all that worthwhile. Also, we didn't do this for 8312 (or any other experimental/informational CC scheme) so it's not clear why we'd do so for 8312bis. [RWG] I think the difference here that may warrant at least some updates to some RFC's is that CUBIC is moving to a PS. So any existing STD or PS that is affected by the fact there is now a new CC at PS level should be updated to reflect that availability. Regards, Rod > Thanks, > Lars > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.org From nobody Thu Feb 25 11:25:46 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A563A1F70 for ; Thu, 25 Feb 2021 11:25:38 -0800 (PST) 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 105G9rIrABJ6 for ; Thu, 25 Feb 2021 11:25:36 -0800 (PST) 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 10BD03A1F2D for ; Thu, 25 Feb 2021 11:25:32 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id n14so7124511iog.3 for ; Thu, 25 Feb 2021 11:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Limo5beTcjR31R1ZuPzQCgm0J/zbk2XAoVQLAsQ5lfs=; b=OS3+MoLbAl2poOk+bX2zJdu6qSFc1dDQfM359NfOnzzyZiGc3184HzEEmAtcC7LHd5 fv+t7TAyMPNxArgeKT9WfPo0bdBw8vMR2Fdw6EphjD9Gyw7XLMY0n8u1jUzHDMf5RyN2 TrEIxRzmom6fvP+0goN/tPTpdbUd0HuVgsfXSg9KBODsjRS3Po0ozBQJxSw5DkKjVB/g zKJkcYyO5t2mWMc6idSHNMO9ykwp6BErqxlpbZ6nhoxV2QQcEaeUxR75IZMMlpdgEEAO U3YGAae/PG2bSDGffazx3jyDuLrobbOa/zKOqn4W1XkrMhzwW2L4hej048WPIt2F/7uF pgZw== 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=Limo5beTcjR31R1ZuPzQCgm0J/zbk2XAoVQLAsQ5lfs=; b=k158YUlD+FI/GigM47YgiBIb8v8Byo9OD65vbqKZg6syexOfCYvjPpCWqbTr598i86 hCKeht/vtUT4TeGdVESLHpqt2tw1MZwasDCcS/uBFZ8gdr2ahY2r3dR4CxxHv/RM3LC0 U0PDE0xlSi2zBgHwfJf5XD1AVpA1Qw9kwHaWe1guc2w7G1ofW4RdlOinhqV4W7gUE2NH l0Gry4xmiDuMs4Vru2WbGYGzUh3gpp6sFAJ8vKYE53SFnyfsRCrx/usc5wEdOpHbvfxk WxIa5bNlYsDfseINX+a9EZW4hdx/r/jkaKU6oS7Y1wtuAmJitBa+4tAQYn8H5ntz1YBs PK5A== X-Gm-Message-State: AOAM533DTNwXPIEDhe/gpk8jMX4HpQ6FfQ6esCf+QAW8v4wV0WsVpmi3 DcrVwVpg2aX0zhXEJNu4kPCZVq+3LNXueTLRIx4= X-Google-Smtp-Source: ABdhPJzKCfkOaHWAoaUjObl8PCY+ntAWuKW1xj3c6mEgU7ST1eo47Ut2O8Ad85EILlvGa06BLgSel1ND/+5rQV2IBio= X-Received: by 2002:a02:860f:: with SMTP id e15mr4737801jai.121.1614281131333; Thu, 25 Feb 2021 11:25:31 -0800 (PST) MIME-Version: 1.0 References: <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org> <202102251354.11PDsBsn025845@gndrsh.dnsmgr.net> In-Reply-To: <202102251354.11PDsBsn025845@gndrsh.dnsmgr.net> From: Martin Duke Date: Thu, 25 Feb 2021 11:25:20 -0800 Message-ID: To: "Rodney W. Grimes" Cc: Lars Eggert , tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000669ec005bc2e1df7" Archived-At: Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 19:25:45 -0000 --000000000000669ec005bc2e1df7 Content-Type: text/plain; charset="UTF-8" IMO a courtesy notice to QUIC, TSVWG, and ICCRG should be sufficient to alert all potentially interested parties to come to TCPM if they want to mix it up on this subject. Obviously we should also periodically update these groups as the document evolves. On Thu, Feb 25, 2021 at 5:54 AM Rodney W. Grimes wrote: > Hello Lars, WG members, > One comment inline below marked [RWG] > > > Hi, > > > > On 2021-2-24, at 20:47, Scharf, Michael > wrote: > > > 1/ Version -02 was submitted 2 days ago and at least I *always* read > drafts > > > entirely before any formal action. A large number of drafts was > submitted in > > > the last days as well, i.e., my reading list is not empty. And at > least I do > > > have a day job, too. > > > > understood. I did make the same request when -01 was posted already, > hence I was wondering if it had fallen through the cracks. > > > > > 3/ I am not sure whether we have to seriously discuss *whether* to > adopt a > > > widely implemented specification. But there could be some questions on > the > > > *how*. For instance, would ICCRG have to be in the loop? > > > > They could, but I don't know if they have to. IIRC we run new CC schemes > by them for review, but this isn't really one of those. > > > > > How about use beyond > > > TCP, e.g., would a syncing with the QUIC WG make sense (you may > actually have > > > a better understanding on that than me)? > > > > We have https://github.com/NTAP/rfc8312bis/issues/45 open for that. It > not clear at this time whether any additional text is needed to explain > more about how QUIC would use CUBIC, a bunch of changes were made already > to this purpose. > > > > > And are there any TCP RFCs that > > > assume that only a single standard congestion control exist and that > would > > > perhaps have to be updated? > > > > I'm sure there are a bunch of TCP specs that only cite NewReno, but > that's probably OK? I'm not sure if finding and updating them just to say > "you may also use CUBIC" is all that worthwhile. Also, we didn't do this > for 8312 (or any other experimental/informational CC scheme) so it's not > clear why we'd do so for 8312bis. > > [RWG] I think the difference here that may warrant at least some updates > to some RFC's is that CUBIC is moving to a PS. So any existing STD or PS > that is affected by the fact there is now a new CC at PS level should be > updated to reflect that availability. > > Regards, > Rod > > > Thanks, > > Lars > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > -- > Rod Grimes > rgrimes@freebsd.org > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000669ec005bc2e1df7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IMO a courtesy notice to QUIC, TSVWG, and ICCRG shoul= d be sufficient to alert all potentially interested parties to come to TCPM= if they want to mix it up on this subject.

Obviou= sly we should also periodically update these groups as the document evolves= .

On Thu, Feb 25, 2021 at 5:54 AM Rodney W. Grimes <ietf@gndrsh.dnsmgr.net> wrote:
Hello Lars, WG members= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 One comment inline below marked [RWG]

> Hi,
>
> On 2021-2-24, at 20:47, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> > 1/ Version -02 was submitted 2 days ago and at least I *always* r= ead drafts
> > entirely before any formal action. A large number of drafts was s= ubmitted in
> > the last days as well, i.e., my reading list is not empty. And at= least I do
> > have a day job, too.
>
> understood. I did make the same request when -01 was posted already, h= ence I was wondering if it had fallen through the cracks.
>
> > 3/ I am not sure whether we have to seriously discuss *whether* t= o adopt a
> > widely implemented specification. But there could be some questio= ns on the
> > *how*. For instance, would ICCRG have to be in the loop?
>
> They could, but I don't know if they have to. IIRC we run new CC s= chemes by them for review, but this isn't really one of those.
>
> > How about use beyond
> > TCP, e.g., would a syncing with the QUIC WG make sense (you may a= ctually have
> > a better understanding on that than me)?
>
> We have https://github.com/NTAP/rfc8312bis/issues= /45 open for that. It not clear at this time whether any additional tex= t is needed to explain more about how QUIC would use CUBIC, a bunch of chan= ges were made already to this purpose.
>
> > And are there any TCP RFCs that
> > assume that only a single standard congestion control exist and t= hat would
> > perhaps have to be updated?
>
> I'm sure there are a bunch of TCP specs that only cite NewReno, bu= t that's probably OK? I'm not sure if finding and updating them jus= t to say "you may also use CUBIC" is all that worthwhile. Also, w= e didn't do this for 8312 (or any other experimental/informational CC s= cheme) so it's not clear why we'd do so for 8312bis.

=C2=A0[RWG] I think the difference here that may warrant at least some upda= tes to some RFC's is that CUBIC is moving to a PS.=C2=A0 So any existin= g STD or PS that is affected by the fact there is now a new CC at PS level = should be updated to reflect that availability.

Regards,
Rod

> Thanks,
> Lars
>


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

--
Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000669ec005bc2e1df7-- From nobody Thu Feb 25 13:44:47 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3687F3A0BFD; Thu, 25 Feb 2021 13:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665, 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 4QCAE6h2BXck; Thu, 25 Feb 2021 13:44:41 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9053A0BFC; Thu, 25 Feb 2021 13:44:39 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:501:db77:ef42:1a77] (unknown [IPv6:2a02:8109:1140:c3d:501:db77:ef42:1a77]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id BA20F7220B822; Thu, 25 Feb 2021 22:44:36 +0100 (CET) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_0C0B2E96-3EA8-4762-B56E-4EB81EABB6A0"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Thu, 25 Feb 2021 22:44:33 +0100 Cc: draft-eggert-tcpm-rfc8312bis@ietf.org To: tcpm IETF list X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [tcpm] Request for feedback on WG adoption of draft-eggert-tcpm-rfc8312bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 21:44:45 -0000 --Apple-Mail=_0C0B2E96-3EA8-4762-B56E-4EB81EABB6A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, this mail starts a two week WG adoption call for https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 The intended status would be PS. So I would like to solicit feedback regarding support for or objections = against the adoption of the document as a WG document in TCPM, if it hasn't been = already sent to the list. Please provide feedback before March 11th. Best regards Michael --Apple-Mail=_0C0B2E96-3EA8-4762-B56E-4EB81EABB6A0 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 AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAy MjUyMTQ0MzNaMC8GCSqGSIb3DQEJBDEiBCAQUjERcwoEdtjSdSEXHYKJbvpppqHRX1+jyoYQcfXb 3zCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEApyR3kIbh7AUABrcRiX+FJCSy+kOk eD5kgF8HSPB+57NXukYkoQ9c+Cpf5fUhxw+ycE3XxTHS1vBNYVXualUMibhMtLUmrCRiPsX+VZGf IqIsAbsSIxnyJa8Z3XPwd1bW1L0tGDkil3gSFQacPAy6Xeazi2+Drv1fb61uANYzPnC2NO/7qluo mICX8+RgwxtsVbwmyp6v9tpDjP7vsLMu50d8P+kKuzmLgcwW55xXKCjDQBjMY9Rm9WuDml1qJH9q tObFADFevKPBZoZ0CqMf50nSxPqFtdXsuZ4GMEKGFXgIQFbNo/BPIQKOYj4FQdOQ/ZUeQGWaPKLt 4dueNn8eHwAAAAAAAA== --Apple-Mail=_0C0B2E96-3EA8-4762-B56E-4EB81EABB6A0-- From nobody Thu Feb 25 14:41:19 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78E83A0DD8 for ; Thu, 25 Feb 2021 14:41:16 -0800 (PST) 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 njzF0Fe_9CJz for ; Thu, 25 Feb 2021 14:41:15 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 47D8B3A0DC2 for ; Thu, 25 Feb 2021 14:41:15 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id t1so2635751qvj.8 for ; Thu, 25 Feb 2021 14:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zGmpmTAsc9Q5nBJ92FhRbIIzwtSdOgO1uqrGekBVNSo=; b=XMBKJOf6fQ4nzTGIh9FOHTr2N64L+gcj6DqpIDxocrJviBYRAIgKvnnFthAkxW6yzB O6EwmYIWcWRNYZ+BSHY6rYrtL41kPMRk+Q/8fm94rUWazwL9XoVOz3zAFIISTSo6NSFh LaO8fMLA5B+iInd308Hu55E5W1xxvHRWx6W+bDZYb6c+UY7J72xfoUhkTl5pbptl5M4T kvy8YgggCRi65izouuKA5oy728RgM9Ncns/XiN6i/tRAz5zmeSIhP4phf27Pj/WugnWK goVYrEgdOpSRh/eZySz+ZjUIoE0s8diYbk6+zuDzeaDCtk70DAftllFrw01F5X2FamKb PPbw== 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=zGmpmTAsc9Q5nBJ92FhRbIIzwtSdOgO1uqrGekBVNSo=; b=bgO2Whwa6FDzN6UH5zXj3yB2pD/se9zxeeOHs+yJoBepBQ8sM5zSccVaSlo+QBr2Ow jXfLQ5t8wzSnL6FW4wTnlCcb4POiohSJKWAVWXo+5yqaZgYTb9iXenXcFDGLoV1jjMNA 1LJExOOmHqAvpEfLrM/Z5OLlnVxe7LRbrL+wb/+OPLGOCN0Citc22OWw39FIAcNPqbqj sS4shyNt3/1ZKmz/MJ87arTNcuWDZEQCH+M4NIba9ZKzoPcL81dV8KvhC5IJSG+gZlxs pMHwvwI5UMyq4n878AmjnoQQKSRJPQaFT0Dqltue7O/OUdvbN198KDj8jwq1hfvj0lvj Rj7g== X-Gm-Message-State: AOAM533wTw9H9ShVy+1The8tJWWOMfdlDJVRurzEcCrZUhTxCG0ecBGt UZbE8LtIATYCXUJl5bkvfylm6Y6KHk5mJwAGOeRE1crPwWA= X-Google-Smtp-Source: ABdhPJxf1JGe9zB5vUnB8sjRXvg4QoDuQjC8DOYCCOsq/55sXtDMWY43c7UAmgar0DWWYTtGN1fz2ZnsK5fQZwpnrS4= X-Received: by 2002:ad4:4d49:: with SMTP id m9mr5071512qvm.10.1614292873914; Thu, 25 Feb 2021 14:41:13 -0800 (PST) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Thu, 25 Feb 2021 14:41:02 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000502c6505bc30d91d" Archived-At: Subject: [tcpm] Draft agenda for 110th meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 22:41:17 -0000 --000000000000502c6505bc30d91d Content-Type: text/plain; charset="UTF-8" Hi, I just uploaded a draft agenda for the 110th meeting. Please check https://datatracker.ietf.org/doc/agenda-110-tcpm/ to check it. Also, please note the agenda might be updated due to several factors. We're currently discussing adopting 8321bis draft, but even if it's adopted before the meeting, it won't affect the order of the presentation. If you have any questions or comments, please let the chairs know. Thanks, -- Yoshi on behalf of tcpm co-chairs --000000000000502c6505bc30d91d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I just uploaded a draft agenda for = the 110th=C2=A0meeting.
Also, please note the agenda might be u= pdated due to several factors.
=C2=A0
We're cur= rently discussing=C2=A0adopting 8321bis draft, but even if it's adopted= before the=C2=A0meeting, it won't affect the order of the presentation= .

If you have any questions or comments, please le= t the chairs know.

Thanks,
--
= Yoshi on behalf of tcpm co-chairs

--000000000000502c6505bc30d91d-- From nobody Thu Feb 25 16:00:11 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE213A120E; Thu, 25 Feb 2021 16:00:10 -0800 (PST) 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 lovZ1zjJzlo1; Thu, 25 Feb 2021 16:00:08 -0800 (PST) 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 97A853A120A; Thu, 25 Feb 2021 16:00:08 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id f20so7845415ioo.10; Thu, 25 Feb 2021 16:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3A9YNajhzU8s+5J/Z+uD7zqOiMewDnyN+hVHiFFuqEc=; b=WnuTHM3jkIDJsNa8CjT9cExiKnPMgYUjck/j36Si6WNzuMSE6UcRJQtBPqVCNHrL3j udB+ktI5iirNfzrAi6CUkaoPMOfN6KbtJNvfd2tNI0RgkhMcRmSpX+jzR7DidxwqrhaE M2Cpd1vx+ATRLA5JbC4HpPq5lxDO1oRv7bz+G/hf8YT9P65s5o/Vt52u1sJE4YrHUKF1 /W5skRzDeu323Ky/4j47FaxyS8iERpnYZSCtoF6XeeSmuLbI16BTMXMOETQOPkx46lYY s1hPfePKeQtRNbDXM0GscxQX6G+jHYYvOWainU/3CJ8tip2YNFi6e1RC8UXavwLsQYA5 d31A== 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=3A9YNajhzU8s+5J/Z+uD7zqOiMewDnyN+hVHiFFuqEc=; b=XlNtzhVlURSJD25WA4iVOxhUTkf+biIH9WrSrW0QXI7QU1+YhNmqK7goOgLzLOCleV kiw3auMyr5S36Ge7oyF5cKpWimcVsvZC6jJ2tnz/yTyqr4PAqYGp5aNtX47dKt14gFXW 4vJxrlkxPizD6drmiZzb+5BCS79R2hGF2xRCB6ms69n5CFV1L5kjr3a/8V2sJMoyOwYU sTLU9VeU7VJtqPhmUxhPbqUPB8EoMcqi2ZE1/TCBzpJW8LAXvf8GH/y79zQI1E3/59hJ 6BetAuwDTj8aWh/6vv68DOoSE3D1b+6o6WFcuPO6SOgahF9Xyg92DEKib8WD0GNAUgrp WyvA== X-Gm-Message-State: AOAM533w4MK9QeOi3f9NFq6Zqwg5a/ihNTE5sbe9VnGY94NBRMh0eF7y tS7+bx8r7cgn+O4Jti5SOw3KW/g6NqOv/rNvv8a38UDENNQ= X-Google-Smtp-Source: ABdhPJybTWz8q6NYlpKqSPKp99e2tvkwTkO0xdFgn0rnP4IbSZhCrCQTyo3kMeo5VEnN/6yl6RJpkbqM0ARhBEz/cuE= X-Received: by 2002:a5d:818f:: with SMTP id u15mr453060ion.95.1614297607763; Thu, 25 Feb 2021 16:00:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Thu, 25 Feb 2021 15:59:56 -0800 Message-ID: To: Michael Tuexen Cc: tcpm IETF list , draft-eggert-tcpm-rfc8312bis@ietf.org Content-Type: multipart/alternative; boundary="00000000000078ff3505bc31f394" Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-eggert-tcpm-rfc8312bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 00:00:10 -0000 --00000000000078ff3505bc31f394 Content-Type: text/plain; charset="UTF-8" as an individual, I support adoption. On Thu, Feb 25, 2021 at 1:44 PM Michael Tuexen wrote: > Dear all, > > this mail starts a two week WG adoption call for > https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 > The intended status would be PS. > > So I would like to solicit feedback regarding support for or objections > against the > adoption of the document as a WG document in TCPM, if it hasn't been > already sent to > the list. > > Please provide feedback before March 11th. > > Best regards > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000078ff3505bc31f394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
as an individual, I support adoption.

On Thu, Feb 25, 2= 021 at 1:44 PM Michael Tuexen <= tuexen@fh-muenster.de> wrote:
Dear all,

this mail starts a two week WG adoption call for
https://tools.ietf.org/html/draft-eggert-= tcpm-rfc8312bis-02
The intended status would be PS.

So I would like to solicit feedback regarding support for or objections aga= inst the
adoption of the document as a WG document in TCPM, if it hasn't been al= ready sent to
the list.

Please provide feedback before March 11th.

Best regards
Michael
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000078ff3505bc31f394-- From nobody Thu Feb 25 19:10:50 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5575A3A16B4; Thu, 25 Feb 2021 19:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_xVt7dVTgEt; Thu, 25 Feb 2021 19:10:47 -0800 (PST) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545BA3A16BA; Thu, 25 Feb 2021 19:10:46 -0800 (PST) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 11Q3Aewc028379; Thu, 25 Feb 2021 19:10:40 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 11Q3AeAJ028378; Thu, 25 Feb 2021 19:10:40 -0800 (PST) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202102260310.11Q3AeAJ028378@gndrsh.dnsmgr.net> In-Reply-To: To: Michael Tuexen Date: Thu, 25 Feb 2021 19:10:40 -0800 (PST) CC: tcpm IETF list , draft-eggert-tcpm-rfc8312bis@ietf.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-eggert-tcpm-rfc8312bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 03:10:48 -0000 > Dear all, > > this mail starts a two week WG adoption call for > https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02 > The intended status would be PS. > > So I would like to solicit feedback regarding support for or objections against the > adoption of the document as a WG document in TCPM, if it hasn't been already sent to > the list. > > Please provide feedback before March 11th. I would like to see this work adopted and support the upgrading of CUBIC from Experimental to Proposed Standard. Regards, Rod > Best regards > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.org From nobody Fri Feb 26 01:20:23 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9F3A0D7D for ; Fri, 26 Feb 2021 01:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, 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 8TYt8vbvfpNX for ; Fri, 26 Feb 2021 01:20:21 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.83]) (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 A80C33A0D29 for ; Fri, 26 Feb 2021 01:20:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f43q3tQOfjin4UoJjdKTRmpGkMxVbEC8fOnvfWvAioAiWcnBrQ0HeuhrTa40rKpSn0sfQ6mvF86ZaxayTeiYu9LF51Sz+agRCvqf42UhyAhw65ehlux5wshOeEBy0b46VLjfr+GWXJ/eAHzrG9fgN37uCyIKxB6ZFP+vEObeDwRc8jP5OdJGGR/AGaLuKBMp86Ams7BkbzwG3gkuUGfwSZ/Yfrv6XWdmkulmle2w/kdkYxy/OYdQrU6d1bk22FeAd7nsOGyfK6pKKDbDQG+5rBcX7Awva7X8xn+0mLKqe/g4Y2dkDbbMTxJhzRhVpIlVITWvDBHLWB+lDbDgci6a6A== 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=lbL50/aoZIAzxaX8KsBzXlCuLGNjUdOOUBu0ihDQT04=; b=g50uyvf6ydYSvIvb1H9sy6+7/EsF2tYAqkGun8gQ4P9VAP3NBElcx+EzWXozMGwsez10a8wmk7WijcR1y5HVpTgpbi7V3CYs+LTNCjgSZOL3lX9MnTMdcwrVXeZn6OX0M3bPdIYn8v9EUkrK3WDTWyIHf/BzLpfN59N9ffw4///ofj+NJOlWsNiPPohKiYuV0ygCXcwVldGPRj0w+eCfEaSREJnGNbd/kEq1mGPR3p7oIs4LXu0CpgYiTJitEfWlqhutIU6etMAigj9sHxdKWUb+ouXvkF0wgayAKxjA7poXeeM4+tIKaAwm9tgMfHG/Wq1Tf1oGMkj0ahiY5bEnmQ== 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=lbL50/aoZIAzxaX8KsBzXlCuLGNjUdOOUBu0ihDQT04=; b=jcyzact6RWN/MU0EliBliDcFxQm3ockQm+tRFOsEgP4ZP+vY5hIHZQQuiU6i/aZ3T3F0GZjr6VsYhu7/EE00HX64aAoXQdIblo0OA0IrMgCDXLEur/y+JpRqW/KS9MJ24/QFMhiKFNx7quij6T1Owezgf3wM8pxBRtgh8FiL0iU= Received: from AM0PR07MB3939.eurprd07.prod.outlook.com (2603:10a6:208:40::14) by AM8PR07MB7521.eurprd07.prod.outlook.com (2603:10a6:20b:24c::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.9; Fri, 26 Feb 2021 09:20:18 +0000 Received: from AM0PR07MB3939.eurprd07.prod.outlook.com ([fe80::3dcd:3a09:9479:a61f]) by AM0PR07MB3939.eurprd07.prod.outlook.com ([fe80::3dcd:3a09:9479:a61f%4]) with mapi id 15.20.3912.009; Fri, 26 Feb 2021 09:20:18 +0000 From: Mirja Kuehlewind To: Michael Tuexen , tcpm IETF list Thread-Topic: [tcpm] Request for feedback on WG adoption of draft-eggert-tcpm-rfc8312bis-02 Thread-Index: AQHXC796ep0QMfEws0CgjpX6Rh3lQapqOnQA Date: Fri, 26 Feb 2021 09:20:17 +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.45.21011103 authentication-results: fh-muenster.de; dkim=none (message not signed) header.d=none;fh-muenster.de; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e71f:e600:9992:511:a5a6:6a1b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df799d00-5bc2-4a03-96d4-08d8da37bbf1 x-ms-traffictypediagnostic: AM8PR07MB7521: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OpQTdYLOgwAiRbnMsknonO3jjQ2SYPjngN5hAE7NGSkjNcWN8a+AfrrSgYSMX+bg1qHVS0UAnAHO2+6cOp/ZZ7z8WrU31mWitHqdX+toIF2hdrRjFqKHaeI0PqPBwIObd1DyC1ATJpxeHIwkLRWM/HAGM1N/ebQJ6GdhOOgFBTmc0GJLRRWtARrwX78uWI2zE/0fWRTaY8MQUaVCjjfre7XX5i+rnGjkU2Z7TU8wTg/3vnVrViu1hW8Vb768BPI/nIX/LjsxVk/A9bEyUgu3kkGZe1KqlYEsn9N/Cx+cnebY3EOfubP5YU3CGXxchgRLTVPhUyTfq3jA7/Ybr5ipXBy0+zucWm53tJRaztgnTd33VnpQzQJNz8NBL6dLu8ulxYQNKvgeW4OEpvuGCmk6BPARodTxjjrxIiVOjOPwo+HsmMEKSbQi6yeaFsV/KCXLKiNGJw19n8XjWi71gK4+oBHZXB6Ojz5SLI4NVPPKQsgzy7sy9bc2VD+btUesoTwI5fugZpnLY2XVlM3r1ZKcaccRQdRvOfbF6SkKTXeP35wBGEE+9S5gY21LzL1VJgT5BKHUUF9CU8ioPxhFwjreAlKTExX0ZkyNInV8DWcrCM6S6hEFCz/qnrcUELsjuyl1PmC1DywWKHnNBbrn2LJq3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3939.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(346002)(39860400002)(376002)(64756008)(8936002)(66476007)(66556008)(66946007)(44832011)(478600001)(83380400001)(2906002)(66446008)(76116006)(71200400001)(5660300002)(966005)(36756003)(8676002)(4744005)(6486002)(33656002)(86362001)(186003)(6512007)(2616005)(6506007)(110136005)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?dlExT3djcXpSQnBEVTZpanlzTm5kUjdVVFVKQTFUUk9ON1RVYmRGWlYrVkM2?= =?utf-8?B?YUUwYUw0cUpSUnlnSHdpRFFabUFJYjMxSkt6cGtwVXRuY0dCYUFRdXB5ZGt3?= =?utf-8?B?aTU5dTgyTldaRzRSempFYUVuTG9wbGR3MGZkdlRYVVhYRzJGaWlRWFhqQWJp?= =?utf-8?B?MURnZ3Z0WkhLQXJDRjU3ZzJDQTBzYXBtZ0gvc004VlluajRHVUJ5OTFEREM0?= =?utf-8?B?QjUrcmZyQ0hRQUJKeTIwczRQZzByZllPbFFxaEowMzVQdnBFWEVud0xjaFZI?= =?utf-8?B?bzZqOUVVZVZxTkZwYisrZmQ5VWNLTEhRTHZRZWtGWHZxQjhpNG53NUxBZVNl?= =?utf-8?B?emhxWjVmQkRKR2RuRWNCZzJRakp5c3c1YkE2OGk0SHJYbm5vUVc4L2F3R093?= =?utf-8?B?L3lTdlAyV1pHa05XcWRJeVc5SjU5ZFNwRDFYUndNd2NIcStZdFZlMmxLblFX?= =?utf-8?B?NVJTNEFyMmowUTZWbXFHcGtzZkVEU0hXSm05Z0UxMWJrazlGeiszeTdYSGJm?= =?utf-8?B?RklKYlBpaFpJNUFEdTdyb3ZsRW9KSG1yZ1pFZHk5OXpYZmpJZmtUQUxIQmVs?= =?utf-8?B?TWRtWVA5NUQ0QWlZWnJteEFVRmhqZDNhcDBQSkJMVlZDbXRnbmlMSGF1cFB5?= =?utf-8?B?cjhHWjZkNytoWjdJN3hMd2hXeDFVOGdrbDVJR2lJVU94eGJjbUgvaWQwdm54?= =?utf-8?B?T1ZScnJWVTVpZjhLT0l5VWxVRzhUTzZGelhTV3Y5NnI0dnhhQkF2bStjSC9v?= =?utf-8?B?R1c2eXVEd1Mzd0wwMk82MFoyVXdFK0g0MzhHb3VXeHhSSXIrVUV6WHhETG45?= =?utf-8?B?R0NvYUtGaVlYcDZTVFh6eUFINFN6ZWJKYnFrNHpkSWdFZWlHeDZKcy9rNzFu?= =?utf-8?B?bDBMYWdrQlVwVGJDbWQwT3JQenhUREYwdFI3dGZQWTlMemJUM3h2OEpBN1M0?= =?utf-8?B?SW5xMksrR21uZ0hnOFZCZWl2WFlwL2lzWWhsNFl5bHM3S2M0MFBXb1VZT2g0?= =?utf-8?B?RG82SktSTnpZRHVLZG5Qb0FJSWdwZ1VaZDhtMHZpMzI2N0duQ1NLVnFmZlBH?= =?utf-8?B?M2h4N01qT1krNkxXTUYzY3Z6bzgrL1NrRHZ6MFA5RjJseW1Bczl2R0VSd2xN?= =?utf-8?B?dGZxcCt1ZVJJVnhtdjQxZzUvZkNhejIwWmtzcGJ1Y3Z0TG1aMC9lcG4xSFo1?= =?utf-8?B?clJxd08zcTBFZ2FMMSs1b2FmU1FVVmVMbWMrUllmRmF0Y1hjdm1UeWpLRFVK?= =?utf-8?B?RnYyd1hMWkdUNUpudXRsdEFYTm95bHlSdS9lTlEyMXliLzFTRWpFbU9WRngx?= =?utf-8?B?WFFEL0Q5d3FsOE1HUVUyT0dCVGJ5azJQdzZVeU0xS3lGcEwzNVpCNVduTWNk?= =?utf-8?B?Y2pHd0VPdVhyeWhQT1QvL0RicWxhRlkrcmpERVBCV0padFR5YWhxUWVpYURk?= =?utf-8?B?bk5XS21OSHhPSTh2cHJ6U0NKY0JxcGZzZmxFcmZZSmx2WW5PdDB5Ky9JcE5B?= =?utf-8?B?RGZqNWs1VSs5cVdXWTU2UTRJU2cvOG5tSGVURThRcGNrSExYd3V1UG41TGxR?= =?utf-8?B?UGlxeTNKTVhLRm1FaHlzTmNRb1N5Vjl2UDREZDJqWmJ0dWJGd0NaL3ZXUy9i?= =?utf-8?B?Nm5kaDJXTHVYSlpYRUFRS05uUW9vRHlFc1puRW9YemdnTkhmaDhkNEhVbUt1?= =?utf-8?B?c2FmQlVzTEdKWXBNZm44UC9razJ1TUhmNm9EdE1kaGNuRDlnakFVOTByNnFX?= =?utf-8?B?YmZML09oMUZvYWVkL0trVGpRVGFNV1lPeFNkVmRhcllicHdqcVRpMTU2MUlU?= =?utf-8?B?d3VuRTMweXlVeEwvK0l1YjA1aVBUZjBYL0pRTE41MDdaRUVSb2lBUzdyK3ow?= =?utf-8?Q?epoQGYJnp/T0B?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <733073AC850BB34A9205A79240A06050@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: AM0PR07MB3939.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: df799d00-5bc2-4a03-96d4-08d8da37bbf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 09:20:18.3364 (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: fKNUH5S9lVw1FRxZ5/117Xizu71XM9eM5KGuI84+etBPzeo7XdpkWESxVFhxXE/Yn37BfmodA0Cli+5+P03gMIx+o+qWcdceYVXIQqhwsyk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB7521 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-eggert-tcpm-rfc8312bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 09:20:23 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLg0KDQrvu79PbiAyNS4wMi4yMSwgMjI6NDUsICJ0Y3BtIG9uIGJl aGFsZiBvZiBNaWNoYWVsIFR1ZXhlbiIgPHRjcG0tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgdHVleGVuQGZoLW11ZW5zdGVyLmRlPiB3cm90ZToNCg0KICAgIERlYXIgYWxsLA0KDQogICAg dGhpcyBtYWlsIHN0YXJ0cyBhIHR3byB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yDQogICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVnZ2VydC10Y3BtLXJmYzgzMTJiaXMtMDIN CiAgICBUaGUgaW50ZW5kZWQgc3RhdHVzIHdvdWxkIGJlIFBTLg0KDQogICAgU28gSSB3b3VsZCBs aWtlIHRvIHNvbGljaXQgZmVlZGJhY2sgcmVnYXJkaW5nIHN1cHBvcnQgZm9yIG9yIG9iamVjdGlv bnMgYWdhaW5zdCB0aGUNCiAgICBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQgYXMgYSBXRyBkb2N1 bWVudCBpbiBUQ1BNLCBpZiBpdCBoYXNuJ3QgYmVlbiBhbHJlYWR5IHNlbnQgdG8NCiAgICB0aGUg bGlzdC4NCg0KICAgIFBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIGJlZm9yZSBNYXJjaCAxMXRoLg0K DQogICAgQmVzdCByZWdhcmRzDQogICAgTWljaGFlbA0KDQo= From nobody Fri Feb 26 05:22:39 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20E3A08A5 for ; Fri, 26 Feb 2021 05:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VySMijtPdh7 for ; Fri, 26 Feb 2021 05:22:35 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C16E3A089C for ; Fri, 26 Feb 2021 05:22:34 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 11QDMTII002344; Fri, 26 Feb 2021 14:22:29 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id E7A791D53C1; Fri, 26 Feb 2021 14:22:28 +0100 (CET) Received: from 83.53.211.205 by webmail.entel.upc.edu with HTTP; Fri, 26 Feb 2021 14:22:28 +0100 Message-ID: Date: Fri, 26 Feb 2021 14:22:28 +0100 From: "Carles Gomez Montenegro" To: tcpm@ietf.org Cc: jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: Delayed for 00:12:42 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 26 Feb 2021 14:22:29 +0100 (CET) Archived-At: Subject: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-rate-request-02.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 13:22:38 -0000 Dear TCPM WG, As it can be seen below, we recently updated the TCP ACK Rate Request (TARR) option draft. Main changes: - There are now two formats: a shorter one to announce support of the TARR option, and a larger one which conveys the value of R, among others. The two formats can be distinguished by the "Length" field value (while keeping the same "Kind" value). - In the second format, the Ignore Order field is now reduced to just 1 bit, and "R" is reduced to 7 bits. Therefore, the total format size decreases from 7 bytes to 6 bytes. - We added content in the security considerations section. Also, after submission of the draft, we contacted IANA to request allocation of ExID 0x00AC (aiming to somehow allude to "ACK") for the option, as it is an RFC 6994-style experimental TCP option. The ExID value has already been allocated: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids Comments are welcome! Thanks, Carles (on behalf of the authors) ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-gomez-tcpm-ack-rate-request-02.txt From: internet-drafts@ietf.org Date: Fri, February 19, 2021 3:30 pm To: "Carles Gomez" "Jon Crowcroft" -------------------------------------------------------------------------- A new version of I-D, draft-gomez-tcpm-ack-rate-request-02.txt has been successfully submitted by Carles Gomez and posted to the IETF repository. Name: draft-gomez-tcpm-ack-rate-request Revision: 02 Title: TCP ACK Rate Request Option Document date: 2021-02-19 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gomez-tcpm-ack-rate-request-02.txt Status: https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-rate-request/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-rate-request Htmlized: https://tools.ietf.org/html/draft-gomez-tcpm-ack-rate-request-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-gomez-tcpm-ack-rate-request-02 Abstract: TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to indicate the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Feb 26 09:34:25 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA403A1376 for ; Fri, 26 Feb 2021 09:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, 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_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 NWRnLhjIqBy2 for ; Fri, 26 Feb 2021 09:34:22 -0800 (PST) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 2E9123A1377 for ; Fri, 26 Feb 2021 09:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1614360844; x=1645896844; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/e7Yu8UDr3vUaQBGKtV+CqIqLTy0XsvQYXaYgFatmww=; b=D+KE2zhGiKnicGN7huExIPMtA91xTS79Ik8W8qHeXfl3OIyAxbdeq2en TDBJS7h1jKhsxL8NYPKTsEYClglEXFFW5V6xXyY12rkL3JSwipr6sEzSh r32C7/Undmz3OLkDpEHt0AfgUP7wZFP9YT4KqdwWoaDCfVPUWRkCwpl1+ iFcvJewFnkooRPH30A1ddMsoLtWjUSJEdxHATTz+df1g1jZegALIcaI+t +nHB+5V8LkOmjnHpCV5f8Z2b0kV4eA295yIVVmTGf5NQFzMN7Qp1TzRfn ckRzX5CNSbtTfNsvcjj4ksVxmvfxMfiqPnk7LJMjbSzfjE6LYfcCxav8h w==; IronPort-SDR: yi1qktLwqc+ibvetKjC2wIflo4B+2dbqwBUS6Un7gB3T8hkXWUNoroZapp6b3DWUBikWl8Vh6V gW6pl6ahOFNQ== Received: from qdefcs.de.t-internal.com ([10.171.254.41]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 26 Feb 2021 18:34:00 +0100 IronPort-SDR: hgAFNXWvre/yEmKk47JedqLWzgOhXo8U7ixaQeT0Rgmqb3yy4518nf3tyP+1qTPcYEwIsYwq8e zeK0IbE7nGyAcWSzSOGsDJnXRFzPs6AOM= X-IronPort-AV: E=Sophos;i="5.81,209,1610406000"; d="scan'208";a="288844079" X-MGA-submission: =?us-ascii?q?MDGYTWJdCUePi7M+KxDO04Bw+BHgOOGDl4S22x?= =?us-ascii?q?qZkau8xEBo59yMJYvE2mrIFOcKd87Uq8T/tl6XHxhqNhg4d/nIX4IKeS?= =?us-ascii?q?YzKwz9hf7472yG15GsnHff6Jxoei0qGY8lNXxRoFHd5hVUyYptGtRVmq?= =?us-ascii?q?LyIZ7Hi+76O/oweyAsCFvHHA=3D=3D?= Received: from he105717.emea1.cds.t-internal.com ([10.169.118.53]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 26 Feb 2021 18:34:00 +0100 Received: from HE105711.EMEA1.cds.t-internal.com (10.169.118.42) by HE105717.emea1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Feb 2021 18:34:00 +0100 Received: from HE105712.EMEA1.cds.t-internal.com (10.169.118.43) by HE105711.emea1.cds.t-internal.com (10.169.118.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Feb 2021 18:33:59 +0100 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105712.EMEA1.cds.t-internal.com (10.169.118.43) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 26 Feb 2021 18:33:59 +0100 Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.172) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Feb 2021 18:33:58 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S1pPI/vsC469zOjrg8KsAoZhbmALNkN3GeonSoyqjZxvmiHFJy0BplxVrbLLG1yDAUEVWKg50VMKOswlHr+jQ6gk070U1CvikM1QHP3ibZzk1pvwxwdQ/zbmWJCuTxsR6DN4Cou6v9BU3aP3+v35aqAsXTp7i6T+68wtJgsg0yirtoxUl6qm10iHFm2HXDNjcIzhNkfWvS7bOuXN9rZBYqZZ0g6UvBhrKCv4ToEcL2IMslfrPMxqwfqNGT736iS72tOK9Rr3VUsJ6h4s9yvYDv2P6Vy6bKhzy9EBMnemlNyfHu9NVA3tL66S/8ZZceUsAB1tae+r/HNzbqn7vp0kkw== 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=/e7Yu8UDr3vUaQBGKtV+CqIqLTy0XsvQYXaYgFatmww=; b=OcrIy4fTj+Q6xMfckeVpGKP8+ibAi8iOXB6bmD3m5mdKIKGbLZZvpJI276SVFJ9RzBtWfLon2zd4JiZquIa2UIAXPydI/AKSGXvkDFTNe0Mxr+0DYNCPaLQpsfwbQNgfBy4V4gntv0yF2AFZHsQkokR5sJpMXT1cGpWhE9iGyOx01pDAChfa+eEzXw4Lm4WMPwuFFtb18Tm4FC1xqLJjsKJbc3QgU3iuwQq3BY7geI9xxIkgYUPZ3Xw/xGyf9MrPVmMDE7U4QzdNtez7SGPLaTr9ukiijkiKDHeYmuERYuRTu5f9b0sDXRvp52yZhGnVr12spB7ayka4ODVz02y8RA== 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 FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c::9) by FR2P281MB0203.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Fri, 26 Feb 2021 17:33:58 +0000 Received: from FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM ([fe80::4065:5dca:1a05:d8e8]) by FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM ([fe80::4065:5dca:1a05:d8e8%6]) with mapi id 15.20.3912.009; Fri, 26 Feb 2021 17:33:58 +0000 From: To: Thread-Topic: [tcpm] MPTCP RobE licensing declaration update Thread-Index: AdcMT303fSiytLNzRTKJgCtX0W+KzA== Date: Fri, 26 Feb 2021 17:33:58 +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: 7a817ab3-eac3-4d2d-4e61-08d8da7cb2c9 x-ms-traffictypediagnostic: FR2P281MB0203: x-ms-exchange-minimumurldomainage: openinventionnetwork.com#5603 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: 5FTjHiIVZ8iCCRKkGfLxI1iM4eIjHQlUfk+vYI99SSnckOmejSKxO0oZdtXbKoy7CxLV2pIbE8pccDhlBjQPZ9fKgXeVDERwmMyDty0Zhi1EwsGcom6MJ3RxSvjeUfCCeilgjtQE7m1erGhRH92rfWiig6kNyfyUZistR/FGg3oTJiUann6JXu+7U9Gof4kReECXVji0ANYhHWo0K5xkGADWK/hW39brxYH7WIYMpfLW38kARWl3agZaxnAZ/Ix8vhmVCbCyQLUA9pKKg2sRVes/a3KoM1QOgfS/DqXaOxhSvBq6G6uW4qfS70C0ZVYKQ3E+1JV5PSNTwMB/IKc65NvWSD979ydOysQBmYkt7MrBzEvffEVjMk8w8JOskwqCQVCI2kVuGzCbRZjF87u2BzvwM2VCgGcW56yXcPapkVxKiqVdUdM9VxOSfxoJEfysWhgrCeRgnIjUldrkDgPb3XMj+/e3f8+kdDnpqkGcGrcRRBPrmZdBnFs+IG08CDN4tieL3Fc6Ey3Hvk3iNpqro3fFDsSFNvY6pMWs8tkg1RQQtxMpoEhDbgTQA+eq2tUGajBqzc4od1QhMgzuUZfgf1uX1YQBaIntjaF8Ro+xqmA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(39860400002)(136003)(366004)(376002)(396003)(33656002)(6916009)(5660300002)(316002)(83380400001)(8936002)(86362001)(64756008)(2906002)(26005)(478600001)(966005)(15650500001)(55016002)(52536014)(8676002)(186003)(71200400001)(4326008)(76116006)(9686003)(7696005)(66556008)(66476007)(6506007)(66446008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?cWcH/Wpl3mkIw0lEcNj2wapCnn7HN10mQlLZuY0NIOlDJvOnruTcto3Ck1oR?= =?us-ascii?Q?qiSRPHyScmq8W3K1QjmZ8W/OUIlR7qq2QE2w7YK+rqs8Oc20p7f1RbBrQrU+?= =?us-ascii?Q?UwYkYlPJvCRWGWClS7Uk86UnCoQV3O9n/TL9oihEZq/L0oi7NWgK/C9YQnf6?= =?us-ascii?Q?VZm0lht9gizhabIOTARx5754E9z1hLj/o1w2jW1jPqnIY3rxZ/7H0n0WRKge?= =?us-ascii?Q?0Bz+5lIztauUfVSCaSKS0qKVT879OobspFEszS+JpIbpipHCEAhl8ToEcKSa?= =?us-ascii?Q?SQ/mTjgfKFcqanL/Njjqui0OiGl5DGcXk6pQLB5QAtt+PdecyPWWSDLl2o5U?= =?us-ascii?Q?B+54bcZdcSIkdsiRNZIt+B8Owh/jij36MbEAF9zciX7bDLumv2ff7PkgvmoM?= =?us-ascii?Q?U8A3aXQfFCHqnn62YQPtM27y3lBQ3MCKh2IvupSTEW6A/FBicnuLPFO2Q1Bb?= =?us-ascii?Q?oPLqJmPyiifS7+eULQVlVgZkyDaSf2+Rn615QEgEEZvHI0i++REwRrQOJAhO?= =?us-ascii?Q?H12PriAYW8ImP4H0jmG/ADT6523Kd/t52m1rsnWnIgFa8q1rWidNgH1YSHH1?= =?us-ascii?Q?ttPnG6BV4wkdBtYDZ7C794cpTKHeFc3OS4nSw+x0IRFp5/JvZxpFCy6u0jfn?= =?us-ascii?Q?we3vWFWKtHhL7DwFDoJMLQ8qZEWIt1bgbEZvNXDbZc+1oewylrBFFEOVCJo4?= =?us-ascii?Q?JgTmJ680KzQXLgjExO5Vwq4LR1EfTY9D9fUSaEnOhnmaEzpanQQBOXNkhLUQ?= =?us-ascii?Q?dHvahVGa8MphN8QYKi3yFS07ldba8B5faL5ox8hSLCwVa2GIKv/ufyxxwNES?= =?us-ascii?Q?A7MsMkflwrq2D5q20oU/iUGAobCQe1fFRLUQ5TDT0yxb0H+QtSBmXiNE9w27?= =?us-ascii?Q?oUIJOOcODEV0Hrb4bh4E1ZGC4mVW4FN/KtiAOFy6yjwBCYPhf06wYWL+q3Ul?= =?us-ascii?Q?LHh9v41ha9pl899fCZF2W1s+53yLkOGocN/I7NRpl9fifUQfSJTlTLMS//O9?= =?us-ascii?Q?fpdjhFxM9PaP+vHlvEt4i5fiw4M/vSsRHvaSx4cYMgw9RGF13HnCYwtNHZoj?= =?us-ascii?Q?8/Ikf6HfpzxrjegCQ/Kcq3uY774e8rcu0HGQE0eD0xlFAgKigWrX5W5GeYid?= =?us-ascii?Q?TaQiFRTaqnngkhyNYeZSDQZmxkxnfadrVpyxnqxzm+7+SR0NR3sBW4yrKpOA?= =?us-ascii?Q?nHz7J0BsyvJ3nYXA2gd4L1d6D1rPsDbVJEififoX5kuix3jDf8I/b4ce+UuI?= =?us-ascii?Q?6Iy/t5JYYWoWgkitgZaFCBZagPWZz5Ittds2CBPZ4KBh0g7t9z3S4jxFxCy+?= =?us-ascii?Q?vtUyFsK4TRhfEkO8gBJCzk03?= 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: FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7a817ab3-eac3-4d2d-4e61-08d8da7cb2c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 17:33:58.2664 (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: WbdxcYSqlKeMa1G+xmpZgEh5zT2qVuDHlU906O0xFia22PW21TJEL8nlFFGKzQITH3UHWbHhd94vQUNV1Gs3Jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0203 X-TM-SNTS-SMTP: 0F45D526FAF65704B10EA3911E232FF4065C03B7D13775CC6BDB1B8A4C724C8A2000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: [tcpm] MPTCP RobE licensing declaration update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 17:34:24 -0000 Dear all, according to the last IETF discussion, we can give some update on the IPR l= icensing declaration and the question if people can implement this in an op= en source implementation. Short recap: MPTCP RobE draft proposes four different solutions, namely Rob= E_IPS, RobE_TIMER, RobE_SIM and RobE_eSIM, while the latter naturally evolv= es from the RobE_SIM. Huawei has already published the RobE_IPS as parts of their open source dis= closures and can be found under https://consumer.huawei.com/en/opensource/detail/?siteCode=3Dworldwide&prod= uctCode=3DSmartphones&fileType=3DopenSourceSoftware&pageSize=3D10&curPage= =3D1 Internal prototypes for RobE_TIMER and RobE_SIM exists at Huawei. Based on = your feedback, they would consider publishing this open source as well, if = this helps to work around the question above. It should be considered, that Huawei is part of the openinventionnetwork (O= IN) and if Huawei discloses the RobE as part of the Linux Kernel, the facto= r of OIN community should be further considered (https://openinventionnetwo= rk.com/). OIN has 3,300+ community members (including Huawei), each of whic= h has signed an OIN License Agreement. By signing the agreement, each of th= e members formally commit to share their Linux System patents and applicati= ons with all OIN community members free of charge (i.e., royalty-free) worl= dwide. Furthermore any publication of RobE within the Linux Kernel is subje= ct to the GPLv2. We rely on your feedback... Br Markus & Jiao