From nobody Mon Aug 2 06:06: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 8A08D3A1CC6 for ; Mon, 2 Aug 2021 06:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGL645dc1RFm for ; Mon, 2 Aug 2021 06:06:42 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 DEFE43A1CC5 for ; Mon, 2 Aug 2021 06:06:42 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id t3so17411042plg.9 for ; Mon, 02 Aug 2021 06:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9gCd1mfBxJIg6qmd1zowClPfBeOV/m+cBvT7uYTshik=; b=DeK7HzHLTGrTDxSxof01oF67ZkX8dfhg6i1iPjz+L5+Fo0tXNQpiqjXecJqHUSUxs1 YOGjtrDRf8cc9EV2g6oecukO/ItmrCIDpjDU0oTXLKmeFaaSj3Vbu8/twEfjnMybFLp4 4Z4ZOLWCRQkc3iUX65/jkXW8JKN4MTnVsZc/6qf/3IMZckk06Vge2f78yRh3g2PyEg0O +52xWSM0+rLOPrD5orxDGsBcEHcuWtPAbkNMShf0AWDuNet2TUEvn0oUxdyZJd80+K7Y GgLt6YtVY99uvooSL1ERWD6oOwhb21W5PMGyD5+iQLlW2qwdCSVskacsLobpudzsRcoR thRQ== 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=9gCd1mfBxJIg6qmd1zowClPfBeOV/m+cBvT7uYTshik=; b=Z6AAX9LTrgUvzPBppSpD39a3bisEMIu8eiymHQs8JGJClBOynwNqlPjvo49PkBJ5kM VOSiXOXOSko/SranRwU3J6SWaBgXvJuRVHFjRzdWSp6MBRq44SXnlmRjpRJVHkESfyDO hw2NcGIlhq2pQKCkrVJ3Cl3ITnDI6PPLRRXOePUPh5gpTJmdHMw58sfVlkVvHk0dIz3X Wgt0W/wqb1mtmcI9J4UA393xwkzY9CZ4EDH+xxrsV5INuHQ8rlyumU6Q6SaQz+T0tIML PtH9JmNWsuv6lrt8xBr0Ss/3Jg5NAt2nDsOXqotGEFMolZUFb28svXN8RLoeTRQwovZD wnpg== X-Gm-Message-State: AOAM533g2W/2k4ByIbUEegJZ0N02Aj/iN0ygUdVx+fswOWn0t0x5e45O xQEiWTcblEnU5DxUZdqZBpRb3pljVtxxlD8zm0ud8XI6W2Y= X-Google-Smtp-Source: ABdhPJwpPw/xdfOJWIou0qs904crY3ZxQpu8r02/ca6a3M1qq+YKbeWLEww/zVhJgUW5TaCnBhZqTS18y5fXSPo7XUw= X-Received: by 2002:a65:5186:: with SMTP id h6mr2124894pgq.62.1627909601143; Mon, 02 Aug 2021 06:06:41 -0700 (PDT) MIME-Version: 1.0 From: Muthu Arul Mozhi Perumal Date: Mon, 2 Aug 2021 18:36:29 +0530 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="00000000000080ae9905c8933d14" Archived-At: Subject: [tcpm] Question on crypto algo usage for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 13:06:48 -0000 --00000000000080ae9905c8933d14 Content-Type: text/plain; charset="UTF-8" Hi, Section 3.1.1 of RFC 5926 describes how to derive the traffic key of desired length to be used for the MAC calculation, especially when the KDF_alg produces fewer bits than the key length required for the MAC_alg. The output of multiple PRF invocations is simply concatenated. For the Traffic_Key, values of multiple PRF invocations are concatenated and truncated as needed to create a Traffic_Key of the desired length. For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit internal PRF to generate 320 bits of data, one would execute the PRF twice, once with i=1 and once with i=2. The result would be the entire output of the first invocation concatenated with the second invocation. For example, Traffic_Key = KDF_alg(Master_Key, 1 || Label || Context || Output_length) || KDF_alg(Master_Key, 2 || Label || Context || Output_length) If the number of bits required is not an exact multiple of the output size of the PRF, then the output of the final invocation of the PRF is truncated as necessary. The question I have is, what if the first invocation of the above PRF itself produces more bits than the key length required by the MAC calculation. Should the output of the first invocation be truncated? For e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 as the KDF_alg, should the output of the foll. be truncated to 128 bits (since it would produce a 160 bit output whereas AES-128-CMAC requires a 128-bit key)? KDF_alg(Master_Key, 1 || Label || Context || Output_length) Regards, Muthu --00000000000080ae9905c8933d14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Section 3.1.1 of RFC 5926 describes how to derive the tra= ffic key of desired length to be used for the MAC calculation, especially w= hen the KDF_alg produces fewer bits than the key length required=C2=A0for t= he MAC_alg.

<snip&g= t;
   The output of multiple PRF invocations is simply concatenated.  For<=
/pre>
   the Traffic_Key=
, values of multiple PRF invocations are concatenated
   and truncated as needed to create a =
Traffic_Key of the desired
   length.  For instance, if one were using KDF_HMAC_SHA1, which u=
ses a
   160-bit i=
nternal PRF to generate 320 bits of data, one would execute
   the PRF twice, once with i=3D1=
 and once with i=3D2.  The result would be
   the entire output of the first invocation conca=
tenated with the
 =
  second invocation.  For example,

  Traffic_Key =3D
=
          KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||
          KDF_alg(Ma=
ster_Key, 2 || Label || Context || Output_length)

   If the number of bits required is not an exact multiple of the output
   size of the PRF, =
then the output of the final invocation of the PRF
   is truncated as necessary.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small"></snip>

The question I have is, what if the first invocation of the above= PRF itself produces more bits than the key length required by the MAC calc= ulation. Should the output of the first invocation be truncated? For e.g. i= f one were to use AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 as the K= DF_alg, should the output of the foll. be truncated to 128 bits (since it w= ould produce a 160 bit output whereas AES-128-CMAC requires a 128-bit key)?=
KDF_alg(Master_Key, 1 || Label || Context || Outpu= t_length)

Regards,=
Muthu
--00000000000080ae9905c8933d14-- From nobody Mon Aug 2 09:42:37 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 D6AF83A0D36; Mon, 2 Aug 2021 09:42:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <162792254476.7538.14926067183839727195@ietfa.amsl.com> Date: Mon, 02 Aug 2021 09:42:24 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 16:42:26 -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-08.txt Pages : 47 Date : 2021-08-02 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 2 09:55:03 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 CCCAB3A0E37; Mon, 2 Aug 2021 09:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtx3_QXcHtXS; Mon, 2 Aug 2021 09:54:56 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 24E6E3A0E3A; Mon, 2 Aug 2021 09:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=XZ8+HGUo4W1TSBXqGu9wNC44995gVpWPIUcdYB0ipkg=; b=LNhEv+Jt/LsBauh0+mS+4hgFzG 5GMGAcbVOU9RhZ21364N5BjBUE1xvFbkyjwStrBrMsMBAqt86go7tKFeU9zCT/MOEG3RoKUp7ZrtX voC3F1E8f3PG646OYKB/0ctjKuIkSgbaT21ktqHcu4lfeQ04NJqezTzK9WxZzrXMRkSJ3oXCV5LdZ BUKM4kDQVhnzoMonrlOak2WWMhdNRyZ9DFnU84xXVSUTXaStGgw14OqEM038lLENfikUHyaBDps8w 9iwSnNubTtUzkM+fnVqR4n0EIOYuRCyh6SASkvlXBC8w7x0FmWyr/Sh5kG/aKwF5Yo/9PSbSw+u/W 1oGmgDlw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:45038 helo=[192.168.1.10]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mAbDL-0002O5-TA; Mon, 02 Aug 2021 17:54:53 +0100 To: tcpm@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org References: <162792254476.7538.14926067183839727195@ietfa.amsl.com> From: Bob Briscoe Message-ID: <9ae4f231-2fcb-9295-8dd0-b527be9773ba@bobbriscoe.net> Date: Mon, 2 Aug 2021 17:54:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <162792254476.7538.14926067183839727195@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu 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.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-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, 02 Aug 2021 16:55:02 -0000 Folks, This update is just a refresh. Only the refs are updated. The draft is in a holding pattern, waiting for AccECN. Bob On 02/08/2021 17:42, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. > > Title : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets > Authors : Marcelo Bagnulo > Bob Briscoe > Filename : draft-ietf-tcpm-generalized-ecn-08.txt > Pages : 47 > Date : 2021-08-02 > > 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 is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Aug 2 11:03: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 8CEA13A136E for ; Mon, 2 Aug 2021 11:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ycFysFxf66r for ; Mon, 2 Aug 2021 11:03:07 -0700 (PDT) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (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 D5C063A1340 for ; Mon, 2 Aug 2021 11:03:07 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id n16so18497610oij.2 for ; Mon, 02 Aug 2021 11:03:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=R9U+bmt68GlzGDZBwuAQDdPXoUa7/USRVrnXmpaHB6I=; b=bK/N8qUzHQajMydn0mLLZgrjWfKDs5a7YnHYQjktma5V/8Zr0gC/wTZx/wrb+Jo/km FvTwX01eWVnSgO6iK3IZzsSiWR4vgqAD4n3qBWglI+NxCcSvqNe1/CDZ/driFMkopoD8 P+qAH/UUwrm4FzyitxRN8dRF5JMVZW+sgsQ27AXAWLq5I39hALdLmBBmlK/GTE5qxEli KXmPQxum9Io+fqkeXkr/uagZMH4VGm3fhSfpfjn1Q95XNODOv3ui20I11c7697dsgFNX rba2qQS2c07h8oPVd7mv/u6ohDfARtmuGd4sQsdPSzpwiWAjYFAgJCAQ8x90gDgSHfIa M4iQ== X-Gm-Message-State: AOAM530O9RODJi5iihb/PvgPfhZ+Nm7fddxgLz9RfGod+NRo5mxwjz4r gGJWECmUyUppV8IdF55D06ljCw== X-Google-Smtp-Source: ABdhPJzMbuAwBoGVJySoizdFbIjYhK40t7yZBaRxVrnsOJGEth+L0d0IVGmbTKK8RUw3KG64HDoueg== X-Received: by 2002:a05:6808:1508:: with SMTP id u8mr11885774oiw.170.1627927386947; Mon, 02 Aug 2021 11:03:06 -0700 (PDT) Received: from [192.168.1.208] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id bi18sm64845oib.54.2021.08.02.11.03.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Aug 2021 11:03:05 -0700 (PDT) From: "Mark Allman" To: "Vidhi Goel" Cc: "Yuchung Cheng" , "Neal Cardwell" , Extensions Date: Mon, 02 Aug 2021 14:03:03 -0400 X-Mailer: MailMate (1.13.2r5673) Message-ID: <756432D9-4331-454D-82EB-346CF54A355E@icir.org> In-Reply-To: References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_7EE1EE75-028A-4A42-AB33-477186506F6C_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 18:03:22 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_7EE1EE75-028A-4A42-AB33-477186506F6C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > =E2=80=9CThis document RECOMMENDS using mechanisms like Pacing to cont= rol > how many bytes are sent to the network at a point of time. But if > it is not possible to implement pacing, an implementation MAY > implicitly pace their traffic by applying a limit L to the > increase in congestion window per ACK during slow start. In > modern stacks, acknowledgments are aggregated for various reason, > CPU optimization, reducing network load etc. Hence it is common > for a sender to receive an aggregated ACK that acknowledges more > than 2 segments. For example, a stack that implements GRO could > aggregate packets up to 64Kbytes or ~44 segments before passing > on to the TCP layer and this would result in a single ACK to be > generated by the TCP stack. Given that an initial window of 10 > packets in current deployments has been working fine, the draft > makes a recommendation to set L=3D10 during slow start. This would > mean that with every ACK, we are probing for a new capacity by > sending 10 packets in addition to the previously discovered > capacity. Implementations MAY choose to set a lower limit if they > believe an increase of 10 is too aggressive." > > Does this sound like what we would like to say? Not really, IMO. I think a few things here ... - I agree that if pacing is in play that we don't need to worry about an L. - I think the above L=3D10 reasoning is at best pretty weak. Just because IW=3D10 works OK once / connection does not mean continually sending "10 more" will work out OK. It may. It may not. But, the above sort of coupling between IW-10 and L=3D10 seems highly tenuous without any sort of data. - The real issue with picking a number is that it is so hard to reason about because the behavior All Depends. E.g., consider something like IW=3D10. We know that will allow 10 or fewer segments to be pumped into the network when the connection starts. That's pretty easy to reason about / understand. But, with L=3D10 we might have bursts anywhere from 2 packets to cwnd+10 packets on every ACK---depending on how the ACKs are stretched. And, cwnd isn't a constant. So, if the idea is to somehow limit bursting then sometimes we're limiting to X and others to Y and still others to Z. It's an inconsistent mess. Making L something arbitrary without evidence seems like a bad path to me. - Of course, by making L=3D10 a MAY we're effectively saying "no L, anywhere" anyways. If we're going to define an L it should be a SHOULD unless there is pacing. - Somewhat related to the above, it isn't clear what "10 more" is more than in qualitative terms, as well. Say an ACK rolls in that covers 10 packets. How were those packets sent? Were they sent a back-to-back burst so "10 more" is in fact a back-to-back burst that is 10 more than previously (or, 2x)? Or, did we send those 10 packets in 5 little bursts of 2 packets each so that "10 more" is actually 18 more than the previous burst size---a 10x increase? Of course, it could be BOTH for the same ACK! I.e., the segments were sent 2 at a time and aggregated somewhere in the middle. This lack of clarity again makes the choice of L feel pretty arbitrary. I agree we can elide L if pacing is in place. But, twiddling with L by feel is crude and will produce an inconsistent approach to bursts that doesn't seem to me to be particularly helpful because we don't really grok the implications. allman --=_MailMate_7EE1EE75-028A-4A42-AB33-477186506F6C_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCYQgzVxEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizk7bAJ98sI75RrVkXLMXsgxXYhmTHTB/cwCgkhsM CuzOfly8wAjqsJpP8goaIfE= =Mm49 -----END PGP SIGNATURE----- --=_MailMate_7EE1EE75-028A-4A42-AB33-477186506F6C_=-- From nobody Mon Aug 2 15:02: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 E16903A1E6B for ; Mon, 2 Aug 2021 15:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 GTh9brbaOx09 for ; Mon, 2 Aug 2021 15:02:02 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCEC3A1E69 for ; Mon, 2 Aug 2021 15:02:02 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id p5so23124238wro.7 for ; Mon, 02 Aug 2021 15:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BivLKVOKBddBdWQJdWrS2LbXbK/DK/KQSfV5JiGptCE=; b=q/pAzXkLDxoie3BeKc1aytn19oZgyhHLF6bid0JrahOyOxX+xZ7j5s60o62elF/uzS FZ3+EWQwh1KRWN8KDGiCkiC6qsCVkkRUFbyAi+GiGWaywcJU4TyTs80w/6to9pkkX1kj zl8MXhRk+B5GoY9N6jk435J7L/q49iWT0/HHNYWsAfGS4TCJJAmKHoHmQCPqt0w0mqL9 X6kkfqol3et0TWdXy1LVttknZJCfDBO9+KzqM/uKelNqTfwtgiZuuFRILmXXerH4kOW8 QKnx3qNkpaRr+4AjlUNeeU5MLFAfTUS3lDw8QoKvbR6U574MlSfMPm+B9f4b7hDOq6QO upHw== 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=BivLKVOKBddBdWQJdWrS2LbXbK/DK/KQSfV5JiGptCE=; b=XrGEiNeo2Nu80hfL3PB5PWoxTZOGCWHdrSTiEGHhgp77Yal5/9RnlL8S+5FBrVGgXr znk+A9hBQs3Drt0ALQl35rpDfiO+aaJF1/L6MIpHYDu0NKOgx+DioZ1nB0KG+qvjWlQE hvjmn+qGG1lCo3Ic4kZObwDqOVGJCkTb71YeF7Zsg16Id/9JYPBCafb+7Zy77wXPaFTm SDVmQv2EeyRLdTpe0X0m/iQZY4DDV2FGEhu6ht1/loIsXdfdQVxJqan1yxKGSSuE8LdI gttF67x20s/VUWGY5g7EGDRy7DozznNkdmJ62sY28YjlMd1XOWgbLWqxHrOpcB24HEJd +OKw== X-Gm-Message-State: AOAM533Gyx6u71/ZLZkgp14o+NGL7KUM4lKjiRWn6V0BPK1jS87t+sED H9GlIYSCaS91odQecrAq7VNmJeVtst2tPvqXkH0CvA== X-Google-Smtp-Source: ABdhPJy9NWmD+j/Qs+48u1BKwGa9cPwXgtofGTUPb37uOPXHTuGy7jyi/k6L3ywTXZVUNpgswtsykmIQwAgLi8y+ptk= X-Received: by 2002:adf:cd86:: with SMTP id q6mr19393958wrj.422.1627941715361; Mon, 02 Aug 2021 15:01:55 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> In-Reply-To: <756432D9-4331-454D-82EB-346CF54A355E@icir.org> From: Yuchung Cheng Date: Mon, 2 Aug 2021 15:01:18 -0700 Message-ID: To: Mark Allman Cc: Vidhi Goel , Neal Cardwell , Extensions Content-Type: multipart/alternative; boundary="000000000000a91d9505c89ab7b7" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:02:08 -0000 --000000000000a91d9505c89ab7b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The choice of L=3D10 is fairly arbitrary -- just like IW10. But what's the show-stopper we should be concerned about, in the big picture of having an interoperable and performant Internet. The fact is that Linux CC has long moved to infinite L since 2031, with or without pacing, for slow-start and congestion avoidance. Windows is using 8 for hystart++. We can go through 100 rounds of what's a more scientific L with more experiments. In the end a bigger L causes higher burst and risks more losses and queues. That number and stats would continue to change https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D9cd981dcf174d26805a032aefa791436da709bee https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D814d488c61260521b1b3cc97063700a5a6667c8f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 Many people have 100Mbps broadband, and stretched ACKs reaching a degree of hundreds MTUs due to various bunching to improve performance. ABC L=3D2 is really an inappropriate outdated limit. On Mon, Aug 2, 2021 at 11:03 AM Mark Allman wrote: > > > =E2=80=9CThis document RECOMMENDS using mechanisms like Pacing to cont= rol > > how many bytes are sent to the network at a point of time. But if > > it is not possible to implement pacing, an implementation MAY > > implicitly pace their traffic by applying a limit L to the > > increase in congestion window per ACK during slow start. In > > modern stacks, acknowledgments are aggregated for various reason, > > CPU optimization, reducing network load etc. Hence it is common > > for a sender to receive an aggregated ACK that acknowledges more > > than 2 segments. For example, a stack that implements GRO could > > aggregate packets up to 64Kbytes or ~44 segments before passing > > on to the TCP layer and this would result in a single ACK to be > > generated by the TCP stack. Given that an initial window of 10 > > packets in current deployments has been working fine, the draft > > makes a recommendation to set L=3D10 during slow start. This would > > mean that with every ACK, we are probing for a new capacity by > > sending 10 packets in addition to the previously discovered > > capacity. Implementations MAY choose to set a lower limit if they > > believe an increase of 10 is too aggressive." > > > > Does this sound like what we would like to say? > > Not really, IMO. I think a few things here ... > > - I agree that if pacing is in play that we don't need to worry > about an L. > > - I think the above L=3D10 reasoning is at best pretty weak. Just > because IW=3D10 works OK once / connection does not mean > continually sending "10 more" will work out OK. It may. It may > not. But, the above sort of coupling between IW-10 and L=3D10 > seems highly tenuous without any sort of data. > > - The real issue with picking a number is that it is so hard to > reason about because the behavior All Depends. E.g., consider > something like IW=3D10. We know that will allow 10 or fewer > segments to be pumped into the network when the connection > starts. That's pretty easy to reason about / understand. But, > with L=3D10 we might have bursts anywhere from 2 packets to > cwnd+10 packets on every ACK---depending on how the ACKs are > stretched. And, cwnd isn't a constant. So, if the idea is to > somehow limit bursting then sometimes we're limiting to X and > others to Y and still others to Z. It's an inconsistent mess. > Making L something arbitrary without evidence seems like a bad > path to me. > > - Of course, by making L=3D10 a MAY we're effectively saying "no L, > anywhere" anyways. If we're going to define an L it should be a > SHOULD unless there is pacing. > > - Somewhat related to the above, it isn't clear what "10 more" is > more than in qualitative terms, as well. Say an ACK rolls in > that covers 10 packets. How were those packets sent? Were they > sent a back-to-back burst so "10 more" is in fact a back-to-back > burst that is 10 more than previously (or, 2x)? Or, did we send > those 10 packets in 5 little bursts of 2 packets each so that > "10 more" is actually 18 more than the previous burst size---a > 10x increase? Of course, it could be BOTH for the same ACK! > I.e., the segments were sent 2 at a time and aggregated > somewhere in the middle. This lack of clarity again makes the > choice of L feel pretty arbitrary. > > I agree we can elide L if pacing is in place. But, twiddling with L > by feel is crude and will produce an inconsistent approach to bursts > that doesn't seem to me to be particularly helpful because we don't > really grok the implications. > > allman > --000000000000a91d9505c89ab7b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The choice of L=3D10 is fairly arbitrary -- just like= IW10. But what's the show-stopper we should be concerned about, in the= big picture of having an interoperable and performant Internet.
=
The fact is that Linux=C2=A0CC has long moved to infinite=C2= =A0L since 2031, with or without pacing, for slow-start and congestion avoi= dance. Windows is using 8 for hystart++. We can go through 100 rounds of wh= at's a more scientific L with more <big-CDN> experiments. In the = end a bigger L causes higher burst and risks more losses and queues. That n= umber and stats would continue to change




>=C2=A0 =E2=80=9CThis document RECOMMENDS using mechanisms like Pacing t= o control
>=C2=A0 how many bytes are sent to the network at a point of time. But i= f
>=C2=A0 it is not possible to implement pacing, an implementation MAY >=C2=A0 implicitly pace their traffic by applying a limit L to the
>=C2=A0 increase in congestion window per ACK during slow start. In
>=C2=A0 modern stacks, acknowledgments are aggregated for various reason= ,
>=C2=A0 CPU optimization, reducing network load etc. Hence it is common<= br> >=C2=A0 for a sender to receive an aggregated ACK that acknowledges more=
>=C2=A0 than 2 segments. For example, a stack that implements GRO could<= br> >=C2=A0 aggregate packets up to 64Kbytes or ~44 segments before passing<= br> >=C2=A0 on to the TCP layer and this would result in a single ACK to be<= br> >=C2=A0 generated by the TCP stack. Given that an initial window of 10 >=C2=A0 packets in current deployments has been working fine, the draft<= br> >=C2=A0 makes a recommendation to set L=3D10 during slow start. This wou= ld
>=C2=A0 mean that with every ACK, we are probing for a new capacity by >=C2=A0 sending 10 packets in addition to the previously discovered
>=C2=A0 capacity. Implementations MAY choose to set a lower limit if the= y
>=C2=A0 believe an increase of 10 is too aggressive."
>
> Does this sound like what we would like to say?

Not really, IMO.=C2=A0 I think a few things here ...

=C2=A0 - I agree that if pacing is in play that we don't need to worry<= br> =C2=A0 =C2=A0 about an L.

=C2=A0 - I think the above L=3D10 reasoning is at best pretty weak.=C2=A0 J= ust
=C2=A0 =C2=A0 because IW=3D10 works OK once / connection does not mean
=C2=A0 =C2=A0 continually sending "10 more" will work out OK.=C2= =A0 It may.=C2=A0 It may
=C2=A0 =C2=A0 not.=C2=A0 But, the above sort of coupling between IW-10 and = L=3D10
=C2=A0 =C2=A0 seems highly tenuous without any sort of data.

=C2=A0 - The real issue with picking a number is that it is so hard to
=C2=A0 =C2=A0 reason about because the behavior All Depends.=C2=A0 E.g., co= nsider
=C2=A0 =C2=A0 something like IW=3D10.=C2=A0 We know that will allow 10 or f= ewer
=C2=A0 =C2=A0 segments to be pumped into the network when the connection =C2=A0 =C2=A0 starts.=C2=A0 That's pretty easy to reason about / unders= tand.=C2=A0 But,
=C2=A0 =C2=A0 with L=3D10 we might have bursts anywhere from 2 packets to =C2=A0 =C2=A0 cwnd+10 packets on every ACK---depending on how the ACKs are<= br> =C2=A0 =C2=A0 stretched.=C2=A0 And, cwnd isn't a constant.=C2=A0 So, if= the idea is to
=C2=A0 =C2=A0 somehow limit bursting then sometimes we're limiting to X= and
=C2=A0 =C2=A0 others to Y and still others to Z.=C2=A0 It's an inconsis= tent mess.
=C2=A0 =C2=A0 Making L something arbitrary without evidence seems like a ba= d
=C2=A0 =C2=A0 path to me.

=C2=A0 - Of course, by making L=3D10 a MAY we're effectively saying &qu= ot;no L,
=C2=A0 =C2=A0 anywhere" anyways.=C2=A0 If we're going to define an= L it should be a
=C2=A0 =C2=A0 SHOULD unless there is pacing.

=C2=A0 - Somewhat related to the above, it isn't clear what "10 mo= re" is
=C2=A0 =C2=A0 more than in qualitative terms, as well.=C2=A0 Say an ACK rol= ls in
=C2=A0 =C2=A0 that covers 10 packets.=C2=A0 How were those packets sent?=C2= =A0 Were they
=C2=A0 =C2=A0 sent a back-to-back burst so "10 more" is in fact a= back-to-back
=C2=A0 =C2=A0 burst that is 10 more than previously (or, 2x)?=C2=A0 Or, did= we send
=C2=A0 =C2=A0 those 10 packets in 5 little bursts of 2 packets each so that=
=C2=A0 =C2=A0 "10 more" is actually 18 more than the previous bur= st size---a
=C2=A0 =C2=A0 10x increase?=C2=A0 Of course, it could be BOTH for the same = ACK!
=C2=A0 =C2=A0 I.e., the segments were sent 2 at a time and aggregated
=C2=A0 =C2=A0 somewhere in the middle.=C2=A0 This lack of clarity again mak= es the
=C2=A0 =C2=A0 choice of L feel pretty arbitrary.

I agree we can elide L if pacing is in place.=C2=A0 But, twiddling with L by feel is crude and will produce an inconsistent approach to bursts
that doesn't seem to me to be particularly helpful because we don't=
really grok the implications.

allman
--000000000000a91d9505c89ab7b7-- From nobody Mon Aug 2 15:03:43 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 F37A63A1E6D for ; Mon, 2 Aug 2021 15:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 JNgkwMbbgCmH for ; Mon, 2 Aug 2021 15:03:36 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 5D72C3A1E6B for ; Mon, 2 Aug 2021 15:03:36 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id c9so2840150wri.8 for ; Mon, 02 Aug 2021 15:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q5pRtvXuaftl++0tFF3rxhViLYj3YNX1DEXHq1brC2c=; b=hR12TzSQQ+9QUc4lXIfFAXznahUrmRxdmUZcmFcwoMhEhyq2yryPouZvtPnZNE12JF q/UNz116HdQZtIKx4FrUABG6G5wuQn6kEN8DP3hctIyiEr3pq9lLoyELBjEbt1KnE/2V YG+P76Q7oHfIOC/FVsFBoLiUphvbNe1WCZBVZcuaCF4lyf4NZFgmceruUj4Va6+R5htg 5J0RTpSruX68P7flT9lKrBUCWAsYc2ZlHwyB1xQEt4FX3fS8r0b8yaM1R5QR3fiDoM9v 0WJSrB7Y8VIoNH2kHY5XNdRdKMsbqIF2CVVY3+sB7j+AwKtwD/Na4vPMqs7Xsna3P0+Q OUxA== 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=q5pRtvXuaftl++0tFF3rxhViLYj3YNX1DEXHq1brC2c=; b=jEOuhZwLj6cOEqDHA+RlhHk9wjBfGBIXTFd493ZtCLnJ00bOLqnBLQ188bvmcvVoHn gUL0N9+56zSfIF1uOmdzJJPejA2WioB6J/Io4fr8eBrRYFYL5QrguWbJ0oR8AA/m3kIO sUtz/bK4UJK9n6LHxfyFNrW2/EPvlSLdDem/MfK/SnbJAWQbQ/0HYedHXL4567sSEX5s X5tcXdY2naEXhG6HvKUQqTWGsNEzhgKbqqVXzF3+x7V9QpodcTaggoI+B1fsupgF1F9P PpffB0h2qAoUyDXl9pViF74LxQ+UUweQlaWulfy7jUHjm2ffms1uVL4mULPDPcopAbQN NXEQ== X-Gm-Message-State: AOAM531jjcN15oLZwPS0R7IBcKpDXp20tApqZfVCEzhMbcrHZRHXQKj0 8esR1jDVDG0r5XaoNkRSy69hhpDAWHDk81yEMxmj2w== X-Google-Smtp-Source: ABdhPJx4ee7Um0juGw4ZkLYYT0ffIHIdiKQ+1WplqMqnKz3XX/PLi7/vrP9f42rDAjsPL10oEamZUjLzcfaHf3HIzFA= X-Received: by 2002:adf:8169:: with SMTP id 96mr19340474wrm.424.1627941809546; Mon, 02 Aug 2021 15:03:29 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> In-Reply-To: <756432D9-4331-454D-82EB-346CF54A355E@icir.org> From: Yuchung Cheng Date: Mon, 2 Aug 2021 15:02:52 -0700 Message-ID: To: Mark Allman Cc: Vidhi Goel , Neal Cardwell , Extensions Content-Type: multipart/alternative; boundary="0000000000004651de05c89abd40" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:03:42 -0000 --0000000000004651de05c89abd40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The fact is that Linux CC has long moved to infinite L since 2013* On Mon, Aug 2, 2021 at 11:03 AM Mark Allman wrote: > > > =E2=80=9CThis document RECOMMENDS using mechanisms like Pacing to cont= rol > > how many bytes are sent to the network at a point of time. But if > > it is not possible to implement pacing, an implementation MAY > > implicitly pace their traffic by applying a limit L to the > > increase in congestion window per ACK during slow start. In > > modern stacks, acknowledgments are aggregated for various reason, > > CPU optimization, reducing network load etc. Hence it is common > > for a sender to receive an aggregated ACK that acknowledges more > > than 2 segments. For example, a stack that implements GRO could > > aggregate packets up to 64Kbytes or ~44 segments before passing > > on to the TCP layer and this would result in a single ACK to be > > generated by the TCP stack. Given that an initial window of 10 > > packets in current deployments has been working fine, the draft > > makes a recommendation to set L=3D10 during slow start. This would > > mean that with every ACK, we are probing for a new capacity by > > sending 10 packets in addition to the previously discovered > > capacity. Implementations MAY choose to set a lower limit if they > > believe an increase of 10 is too aggressive." > > > > Does this sound like what we would like to say? > > Not really, IMO. I think a few things here ... > > - I agree that if pacing is in play that we don't need to worry > about an L. > > - I think the above L=3D10 reasoning is at best pretty weak. Just > because IW=3D10 works OK once / connection does not mean > continually sending "10 more" will work out OK. It may. It may > not. But, the above sort of coupling between IW-10 and L=3D10 > seems highly tenuous without any sort of data. > > - The real issue with picking a number is that it is so hard to > reason about because the behavior All Depends. E.g., consider > something like IW=3D10. We know that will allow 10 or fewer > segments to be pumped into the network when the connection > starts. That's pretty easy to reason about / understand. But, > with L=3D10 we might have bursts anywhere from 2 packets to > cwnd+10 packets on every ACK---depending on how the ACKs are > stretched. And, cwnd isn't a constant. So, if the idea is to > somehow limit bursting then sometimes we're limiting to X and > others to Y and still others to Z. It's an inconsistent mess. > Making L something arbitrary without evidence seems like a bad > path to me. > > - Of course, by making L=3D10 a MAY we're effectively saying "no L, > anywhere" anyways. If we're going to define an L it should be a > SHOULD unless there is pacing. > > - Somewhat related to the above, it isn't clear what "10 more" is > more than in qualitative terms, as well. Say an ACK rolls in > that covers 10 packets. How were those packets sent? Were they > sent a back-to-back burst so "10 more" is in fact a back-to-back > burst that is 10 more than previously (or, 2x)? Or, did we send > those 10 packets in 5 little bursts of 2 packets each so that > "10 more" is actually 18 more than the previous burst size---a > 10x increase? Of course, it could be BOTH for the same ACK! > I.e., the segments were sent 2 at a time and aggregated > somewhere in the middle. This lack of clarity again makes the > choice of L feel pretty arbitrary. > > I agree we can elide L if pacing is in place. But, twiddling with L > by feel is crude and will produce an inconsistent approach to bursts > that doesn't seem to me to be particularly helpful because we don't > really grok the implications. > > allman > --0000000000004651de05c89abd40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The fact is that Linux=C2=A0CC has long moved to infinite= =C2=A0L since 2013*

On Mon, Aug 2, 2021 at 11:03 AM Mark Allman <mallman@icir.org> wrote:

>=C2=A0 =E2=80=9CThis document RECOMMENDS using mechanisms like Pacing t= o control
>=C2=A0 how many bytes are sent to the network at a point of time. But i= f
>=C2=A0 it is not possible to implement pacing, an implementation MAY >=C2=A0 implicitly pace their traffic by applying a limit L to the
>=C2=A0 increase in congestion window per ACK during slow start. In
>=C2=A0 modern stacks, acknowledgments are aggregated for various reason= ,
>=C2=A0 CPU optimization, reducing network load etc. Hence it is common<= br> >=C2=A0 for a sender to receive an aggregated ACK that acknowledges more=
>=C2=A0 than 2 segments. For example, a stack that implements GRO could<= br> >=C2=A0 aggregate packets up to 64Kbytes or ~44 segments before passing<= br> >=C2=A0 on to the TCP layer and this would result in a single ACK to be<= br> >=C2=A0 generated by the TCP stack. Given that an initial window of 10 >=C2=A0 packets in current deployments has been working fine, the draft<= br> >=C2=A0 makes a recommendation to set L=3D10 during slow start. This wou= ld
>=C2=A0 mean that with every ACK, we are probing for a new capacity by >=C2=A0 sending 10 packets in addition to the previously discovered
>=C2=A0 capacity. Implementations MAY choose to set a lower limit if the= y
>=C2=A0 believe an increase of 10 is too aggressive."
>
> Does this sound like what we would like to say?

Not really, IMO.=C2=A0 I think a few things here ...

=C2=A0 - I agree that if pacing is in play that we don't need to worry<= br> =C2=A0 =C2=A0 about an L.

=C2=A0 - I think the above L=3D10 reasoning is at best pretty weak.=C2=A0 J= ust
=C2=A0 =C2=A0 because IW=3D10 works OK once / connection does not mean
=C2=A0 =C2=A0 continually sending "10 more" will work out OK.=C2= =A0 It may.=C2=A0 It may
=C2=A0 =C2=A0 not.=C2=A0 But, the above sort of coupling between IW-10 and = L=3D10
=C2=A0 =C2=A0 seems highly tenuous without any sort of data.

=C2=A0 - The real issue with picking a number is that it is so hard to
=C2=A0 =C2=A0 reason about because the behavior All Depends.=C2=A0 E.g., co= nsider
=C2=A0 =C2=A0 something like IW=3D10.=C2=A0 We know that will allow 10 or f= ewer
=C2=A0 =C2=A0 segments to be pumped into the network when the connection =C2=A0 =C2=A0 starts.=C2=A0 That's pretty easy to reason about / unders= tand.=C2=A0 But,
=C2=A0 =C2=A0 with L=3D10 we might have bursts anywhere from 2 packets to =C2=A0 =C2=A0 cwnd+10 packets on every ACK---depending on how the ACKs are<= br> =C2=A0 =C2=A0 stretched.=C2=A0 And, cwnd isn't a constant.=C2=A0 So, if= the idea is to
=C2=A0 =C2=A0 somehow limit bursting then sometimes we're limiting to X= and
=C2=A0 =C2=A0 others to Y and still others to Z.=C2=A0 It's an inconsis= tent mess.
=C2=A0 =C2=A0 Making L something arbitrary without evidence seems like a ba= d
=C2=A0 =C2=A0 path to me.

=C2=A0 - Of course, by making L=3D10 a MAY we're effectively saying &qu= ot;no L,
=C2=A0 =C2=A0 anywhere" anyways.=C2=A0 If we're going to define an= L it should be a
=C2=A0 =C2=A0 SHOULD unless there is pacing.

=C2=A0 - Somewhat related to the above, it isn't clear what "10 mo= re" is
=C2=A0 =C2=A0 more than in qualitative terms, as well.=C2=A0 Say an ACK rol= ls in
=C2=A0 =C2=A0 that covers 10 packets.=C2=A0 How were those packets sent?=C2= =A0 Were they
=C2=A0 =C2=A0 sent a back-to-back burst so "10 more" is in fact a= back-to-back
=C2=A0 =C2=A0 burst that is 10 more than previously (or, 2x)?=C2=A0 Or, did= we send
=C2=A0 =C2=A0 those 10 packets in 5 little bursts of 2 packets each so that=
=C2=A0 =C2=A0 "10 more" is actually 18 more than the previous bur= st size---a
=C2=A0 =C2=A0 10x increase?=C2=A0 Of course, it could be BOTH for the same = ACK!
=C2=A0 =C2=A0 I.e., the segments were sent 2 at a time and aggregated
=C2=A0 =C2=A0 somewhere in the middle.=C2=A0 This lack of clarity again mak= es the
=C2=A0 =C2=A0 choice of L feel pretty arbitrary.

I agree we can elide L if pacing is in place.=C2=A0 But, twiddling with L by feel is crude and will produce an inconsistent approach to bursts
that doesn't seem to me to be particularly helpful because we don't=
really grok the implications.

allman
--0000000000004651de05c89abd40-- From nobody Mon Aug 2 15:37: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 7428A3A1F60 for ; Mon, 2 Aug 2021 15:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 iMLx5ejSDJ3w for ; Mon, 2 Aug 2021 15:37:03 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 7E0F73A1F58 for ; Mon, 2 Aug 2021 15:37:03 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id 19-20020a9d08930000b02904b98d90c82cso19008204otf.5 for ; Mon, 02 Aug 2021 15:37:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=lZmnhYC0o0rptmiRxpXFug0CveWfFE8xZgQ9f+ZCOpU=; b=NdvB3oaSNQzHBjCFiYKnbvftgzt6IOfBy7yrr6076NLd03XHUtwRTAhUIpv++P+foc zQ7vCAYr9i2QhGXFiVjFQlDE2YwRSY6sc7yulVzkPjTkjN6Ik2KbJvJ5z+HR+Ipf1KIX l+mWX4uyqD7rfBwLiydXdZeRwAPXvJP/tHOktw90laiqplII+Jn8/WaPsy0kqWcLXnix V0QTUUR5CzKlk7b9CX7tC4h4+R6/NDTBaS0qzeaAI6DMWAT+2qx5c2TVACtlTmnfOv2R GqznKfCqo15AcFRnRUcpjEiFstZVc/L+YbvZlXghk05go3SdZZ64ATT36fjn9WFrZniG lrWg== X-Gm-Message-State: AOAM530gKET2Xxf7snlJezziFF1ZCJYygoumXLeKT07Z4Y3sKmn4Q58U fQ86cqklyoGAymQpNcb8u3ckdQ== X-Google-Smtp-Source: ABdhPJyp4kjeEhITBaG/MHEl/eSLo4lAY7qn7dN2HSp+DJq64LZpY5EAUPIb8WqcxMJOJqlyjHYOZw== X-Received: by 2002:a9d:3a49:: with SMTP id j67mr14374608otc.114.1627943822576; Mon, 02 Aug 2021 15:37:02 -0700 (PDT) Received: from [192.168.1.208] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id r1sm1965762ooi.21.2021.08.02.15.37.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Aug 2021 15:37:01 -0700 (PDT) From: "Mark Allman" To: "Yuchung Cheng" Cc: "Vidhi Goel" , "Neal Cardwell" , Extensions Date: Mon, 02 Aug 2021 18:36:59 -0400 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_51DB9368-A7E2-4E66-BED2-3CC48D2BEEE3_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:37:10 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_51DB9368-A7E2-4E66-BED2-3CC48D2BEEE3_= Content-Type: text/plain > The fact is that Linux CC has long moved to infinite L since 2031, So, if our experience is with L=\infinity and it is demonstrably OK why don't we say *THAT* instead of "make L=5 or L=10"? I would submit that it makes more sense to leverage experience than it does to make things up. allman --=_MailMate_51DB9368-A7E2-4E66-BED2-3CC48D2BEEE3_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCYQhzixEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizqouAJ9nXi5UXJsH/jNOgOtKoa8Tszl9CACZAcwj zQIuryQJuLz9vLLZ53KE4co= =GwJB -----END PGP SIGNATURE----- --=_MailMate_51DB9368-A7E2-4E66-BED2-3CC48D2BEEE3_=-- From nobody Mon Aug 2 15:46: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 AB7143A1FD6 for ; Mon, 2 Aug 2021 15:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 lLpooWO9tARz for ; Mon, 2 Aug 2021 15:46:18 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 F22403A1FD5 for ; Mon, 2 Aug 2021 15:46:17 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id l34-20020a05600c1d22b02902573c214807so468112wms.2 for ; Mon, 02 Aug 2021 15:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FyyrhLS4dH7mC6TGDcf8Lwyp4vkM4i3KdS9yM7Dc6FM=; b=JI9itEllJJagcCVzgMKIEBb25829roEEoOdE7U7X+nuOyNS85n9LAGzg3YSIdH6R8N aeJ5Xve3j1lnpalrA8XdjYgAJ/IsQIP29h1qJ6ec+jN+tAOouKteC1UpvqoZ2c7dPDbz 9zlxY0n+0DPc3BFczcDv8RsWMqTNBQnN4ujcPIqdWV9Q6Ru3K8+LoC1HIoj4cjw3OHYf W/48womhH4/UKTv6mOKrHfGzSMEk2zGAOGSnWgpj0gOUgMleqM70Owzb0Q1XP6LG2xQ3 e9JrSXciPo/+5hBhJj4Y/QHVhiefL/Fwo7Z0PFnqz6q2pNhvGzZ/6NEZG1Aq8lH8U/WR ZZwA== 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=FyyrhLS4dH7mC6TGDcf8Lwyp4vkM4i3KdS9yM7Dc6FM=; b=ny2nx0OQe2bZ+C3An11SCQtcdXzFTG0SaCP1Ub+doUMvp9IA67BhVJe5NT3wswtNbR R3vhQs6f3CKdISlke1ay7Z4Ij27j7OaNNouWGh3mUp4M+LRHS6QHkrESS1YQcz0py9C/ RBpN33bBunlLvdWteGlpow4gvWtZPJyPrtXrKSbdUcJWU5SG5JE7wu9hES9w9bxbMEZH VahB1PKNkN6xVuZbrS/X0pEUD7ogRTfo8m+itS3rPMsxAccLFVL9ZUum5z23rwJZvwFy 93agnvdMIiNhaw+yvo0p3TcDQDJiuhg4pHixRF4gwNSYdOZoGvYZp8CVgB4tkGuXpmSk osSQ== X-Gm-Message-State: AOAM533oqJmIkzYvdwWHh9GB/RAhowPvs5WvuMam6Mxs9a4gaH1NS4Bc zkKDcDJ4zkTUFASvk5ENuj/Z6WLjDDogvAASBGF/4g== X-Google-Smtp-Source: ABdhPJz/uLJIOLyHlOs/gKOFkRDBsdm5DoIjQ3usJwi4shxsnDIkfgmcSe0vlLYPP0gPZ747Fmo83FzeyAe7j88r8Xg= X-Received: by 2002:a7b:ce10:: with SMTP id m16mr1030083wmc.75.1627944375659; Mon, 02 Aug 2021 15:46:15 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> In-Reply-To: From: Yuchung Cheng Date: Mon, 2 Aug 2021 15:45:37 -0700 Message-ID: To: Mark Allman Cc: Vidhi Goel , Neal Cardwell , Extensions Content-Type: multipart/alternative; boundary="0000000000003a2c2605c89b5652" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:46:23 -0000 --0000000000003a2c2605c89b5652 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: > > > The fact is that Linux CC has long moved to infinite L since 2031, > > So, if our experience is with L=\infinity and it is demonstrably OK > why don't we say *THAT* instead of "make L=5 or L=10"? I would > submit that it makes more sense to leverage experience than it does to make things up. > +1 > > allman > --0000000000003a2c2605c89b5652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org> wrote:
=

> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0
to make things up.
+1
=C2=A0

allman
--0000000000003a2c2605c89b5652-- From nobody Mon Aug 2 15:49: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 EA3763A1D80 for ; Mon, 2 Aug 2021 15:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-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 fOQmbePTmJxX for ; Mon, 2 Aug 2021 15:49:27 -0700 (PDT) Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6E73A132A for ; Mon, 2 Aug 2021 15:49:26 -0700 (PDT) Received: from dlang-laptop (unknown [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id C71E21000A1; Mon, 2 Aug 2021 15:49:21 -0700 (PDT) Date: Mon, 2 Aug 2021 15:49:21 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Yuchung Cheng cc: Mark Allman , Extensions In-Reply-To: Message-ID: References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============5007449498460556053==" Archived-At: Subject: Re: [tcpm] =?iso8859-7?q?Linux_doesn=A2t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:49:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============5007449498460556053== Content-Type: text/plain; format=flowed; charset=US-ASCII I believe that Linux also defaults to fq_codel to manage congestion at it's interface (doesn't help if the bottleneck is a router, unless it's also running Linux) I don't rememberhen that went it, but it's been several years, may actually go back to 2013 as well. David Lang On Mon, 2 Aug 2021, Yuchung Cheng wrote: > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: > >> >>> The fact is that Linux CC has long moved to infinite L since 2031, >> >> So, if our experience is with L=\infinity and it is demonstrably OK >> why don't we say *THAT* instead of "make L=5 or L=10"? I would >> submit that it makes more sense to leverage experience than it does > > to make things up. >> > +1 > > >> >> allman >> > --===============5007449498460556053== Content-Type: text/plain; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============5007449498460556053==-- From nobody Mon Aug 2 15:57: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 F3BFE3A201D for ; Mon, 2 Aug 2021 15:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 V43_07Fpu35B for ; Mon, 2 Aug 2021 15:56:58 -0700 (PDT) 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 6D5FD3A2018 for ; Mon, 2 Aug 2021 15:56:58 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id j19so10446018vso.0 for ; Mon, 02 Aug 2021 15:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EKuwqmDzgKrcQSmQrmNj9GHLTZiwkKPWIk4c1JFSWIE=; b=iwnlhHlOVxVvOChQ8GW4+0+u7X5pxvNIHwLJOikNqQoCd2vkgDBr/mViKpMVE3Mph1 W8II+BEgOO/rsdV+soKpZTJz+KiFCBwFaz8XS8dTHGz6MxQzJkSGsOOd6KCMxVmtQqf8 S9HXJBMGOahiMDn2adnLgni3hdQcgnTeR3GcCbe6Ml1f6bvkCZJYh2YGhq6zZDIZfNOO ACTPOlTZuBb4yaBWaH3Hs7HCUB3gkXdO9ZvPj1e4+adKJwyQjUFjecWNOa2qZ4oXhvk9 bAsTnZWBlE809XiNG0jCrlK6tkIb6MJ0+uIWHRshL0QR7JTMSk0IbNOhKhVGQ+xexqZC 9NQQ== 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=EKuwqmDzgKrcQSmQrmNj9GHLTZiwkKPWIk4c1JFSWIE=; b=jwVrsrumcVctQV1EqZxYmDMrLDflSaw7bmDkI8zkB/+D2qnorcXW9/pipeqcdpyImu 02HJf+gDEDULDpnPSNBC4hSuLhUxr3G4MWgBlrA1LjeGHI8nUc7ojWfdkyaa2Bawaays F7TZGDlsYQkWSi72BkTW75niTJo9dyFVefk9rlXNdyFdkMhTO0QnSbRtnJ8kMhqiDglQ u383GNdzZqx3JXMzSXGsccZ6KeTbszAsfs4h7NbXO856Nd7Nhrun9USiSz+iigKDMyJD S5fqvEP3Y0LZUANWOKWW/Uqp4ni+RyRvJkJQw5T5m5J1yMHr10gmL4XRwfcH/aV6Um6z bEKg== X-Gm-Message-State: AOAM530Zwv4+aiY/Qq2ZgOx4J5QaXq/Ak1Dg38V+sepb8CO9Fqs7itpH dkm4TukIi2N3pkx2sLi62mgPnk04hoM4vVlEzvZzgA== X-Google-Smtp-Source: ABdhPJz8uoPtAe0w+KvE4h3+4QsbsfCFc+cuTBcshM1d7BSNvyfgVbECYFMBXHBpM6eYQalxOkCLkJs4iRhS49uuG/Q= X-Received: by 2002:a67:7f09:: with SMTP id a9mr12571353vsd.52.1627945016428; Mon, 02 Aug 2021 15:56:56 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> In-Reply-To: From: Neal Cardwell Date: Mon, 2 Aug 2021 18:56:39 -0400 Message-ID: To: Yuchung Cheng Cc: Mark Allman , Vidhi Goel , Extensions Content-Type: multipart/alternative; boundary="0000000000006b9a7105c89b7cb0" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:57:03 -0000 --0000000000006b9a7105c89b7cb0 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 2, 2021 at 6:46 PM Yuchung Cheng wrote: > > > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: > >> >> > The fact is that Linux CC has long moved to infinite L since 2031, >> >> So, if our experience is with L=\infinity and it is demonstrably OK >> why don't we say *THAT* instead of "make L=5 or L=10"? I would >> submit that it makes more sense to leverage experience than it does > > to make things up. >> > +1 > Yes, I agree that would be a great approach to take. neal --0000000000006b9a7105c89b7cb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 6:46 PM Yuchun= g Cheng <ycheng@google.com> = wrote:


On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org> wrote:=

> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0
to make things up.
+1

Yes, I agree that would be a great approach to take.

neal


--0000000000006b9a7105c89b7cb0-- From nobody Mon Aug 2 16:02:15 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 32E773A2034 for ; Mon, 2 Aug 2021 16:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=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 zeApbukSa1eU for ; Mon, 2 Aug 2021 16:02:08 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 52F2D3A202D for ; Mon, 2 Aug 2021 16:02:08 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 172Mwq6s027837; Mon, 2 Aug 2021 16:02:03 -0700 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=cn2mf+WeN7AmRLaugqdFaoRUlcqCCRswHcAnBb25rUg=; b=Y/vpOL2RptlmyWkAvx8ZLjXtqpvxEef7dupgFxXM8puZ7tpXDF2QhlvszQIfA3awyQ5j YLY4Q5zKwOnyHBB81EcvO255zeSEhccJ4UfjzoOUYV378eIxf11dg3tx9i44icHXorRy UfGzWXOOZ4fulScf40PD4Z0RHmxf1ulw8y2XY/SLuPhkJSyAZEQnYblXuwEICygQ6Nvr o5ra2uo0o5eNv+WVD78Fd80N08g20bL73cD8SfcHt1SMbSZuMqcbbj8J9JY8wfycvMy2 ADlZL+/pBXrFgxPbm4hCI9BKvhsuRZ7KB8V0J7lokpud88eOJeFQIVAff4s2AEWAOIDC LQ== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3a5219amwr-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 02 Aug 2021 16:02:03 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QX800AHWINEU140@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 02 Aug 2021 16:02:03 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QX800K00IKYIU00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 02 Aug 2021 16:02:02 -0700 (PDT) X-Va-A: X-Va-T-CD: 2d682d06d4452f7f842383a701a46700 X-Va-E-CD: 8ad83cf34a8c3732cb73dea81270d36d X-Va-R-CD: 2eec4d4b333905bf2498bde820845c7b X-Va-CD: 0 X-Va-ID: fd43eb25-8f38-4483-a16a-99c126eb7c1c X-V-A: X-V-T-CD: 2d682d06d4452f7f842383a701a46700 X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b X-V-CD: 0 X-V-ID: 275add98-7917-4267-bcbc-495e339528c2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-02_07:2021-08-02, 2021-08-02 signatures=0 Received: from smtpclient.apple (unknown [17.234.77.243]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QX800KK2IND3200@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 02 Aug 2021 16:02:02 -0700 (PDT) From: Vidhi Goel Message-id: <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_12BC5114-13BC-4AB3-B6AD-5F203F28E8B6" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Mon, 02 Aug 2021 16:02:01 -0700 In-reply-to: Cc: Yuchung Cheng , Mark Allman , Extensions To: Neal Cardwell References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-02_07:2021-08-02, 2021-08-02 signatures=0 Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 23:02:13 -0000 --Apple-Mail=_12BC5114-13BC-4AB3-B6AD-5F203F28E8B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman > wrote: >=20 > > The fact is that Linux CC has long moved to infinite L since 2031, >=20 > So, if our experience is with L=3D\infinity and it is demonstrably OK > why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would > submit that it makes more sense to leverage experience than it does=20 > to make things up. > +1 >=20 > Yes, I agree that would be a great approach to take. So, we are saying it is fine to ignore L completely and simply increase = cwnd by bytes_acked during slow start? And if this causes large bursts = to be sent out (when an implementation doesn=E2=80=99t do pacing), that = is fine?=20 - Vidhi > On Aug 2, 2021, at 3:56 PM, Neal Cardwell = wrote: >=20 >=20 >=20 > On Mon, Aug 2, 2021 at 6:46 PM Yuchung Cheng > wrote: >=20 >=20 > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman > wrote: >=20 > > The fact is that Linux CC has long moved to infinite L since 2031, >=20 > So, if our experience is with L=3D\infinity and it is demonstrably OK > why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would > submit that it makes more sense to leverage experience than it does=20 > to make things up. > +1 >=20 > Yes, I agree that would be a great approach to take. >=20 > neal >=20 >=20 --Apple-Mail=_12BC5114-13BC-4AB3-B6AD-5F203F28E8B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mon, Aug = 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org> wrote:

> The fact is that Linux CC has long moved to infinite L = since 2031,

So, if our experience is with = L=3D\infinity and it is demonstrably OK
why don't we say = *THAT* instead of "make L=3D5 or L=3D10"?  I would
submit that it makes more sense to leverage experience than = it does 
to make things up.
+1

Yes, I agree that would be a great = approach to take.

So, we are saying it is fine to ignore L completely and = simply increase cwnd by bytes_acked during slow start? And if this = causes large bursts to be sent out (when an implementation doesn=E2=80=99t= do pacing), that is fine? 

-
Vidhi

On Aug = 2, 2021, at 3:56 PM, Neal Cardwell <ncardwell@google.com> wrote:



On Mon, Aug 2, 2021 at 6:46 PM Yuchung Cheng <ycheng@google.com> = wrote:


On Mon, Aug = 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org> wrote:

> The fact is that Linux CC has long moved to infinite L since = 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?  I = would
submit that it makes more sense to leverage experience than it = does 
to make things up.
+1

Yes, I agree that would be a great = approach to take.

neal



= --Apple-Mail=_12BC5114-13BC-4AB3-B6AD-5F203F28E8B6-- From nobody Mon Aug 2 16:04:43 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 048FB3A203C; Mon, 2 Aug 2021 16:04:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sarah Banks via Datatracker To: Cc: draft-ietf-tcpm-rfc793bis.all@ietf.org, last-call@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162794548097.12686.15693645370976846299@ietfa.amsl.com> Reply-To: Sarah Banks Date: Mon, 02 Aug 2021 16:04:41 -0700 Archived-At: Subject: [tcpm] Opsdir last call review of draft-ietf-tcpm-rfc793bis-24 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, 02 Aug 2021 23:04:41 -0000 Reviewer: Sarah Banks Review result: Ready I’ve reviewed the draft and have no concerns or changes to raise. Since the draft is replacing RFC 793 and chunks of other documents I found this a bit awkward, but no more awkward than the spaghetti soup that is TCP across any number of drafts today, anyhow. Nits is taking forever to run; I’d encourage the authors to ensure nits is clean. Otherwise, the draft is good to go. Thanks, Sarah From nobody Mon Aug 2 16:18: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 B1D4E3A20CA for ; Mon, 2 Aug 2021 16:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 j4neQKw36qKW for ; Mon, 2 Aug 2021 16:18:40 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 4DA373A20C8 for ; Mon, 2 Aug 2021 16:18:40 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id f27so4184714vsp.8 for ; Mon, 02 Aug 2021 16:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HyMStJbvRMg/LsnHjMMhApaZaFOgs+4hqBI4nzgDuu8=; b=o72K6K29EcY/H9YgoxhVVWY6fzbFOE4srNqt+H6uPpPg9saJUoeLlxQJ+rmc737BPQ c5+0uOdNbN48odI66RTb3VycIvx+HgM5kpsykx6+cJVEc+wZSizkuSQkg4GZd9UPfC1T NXx9+Xi8neHHCJi1dsWZ53+ngSfeTotgLO9uDcQ0hZqfl9VkLp5wOXmOXb3eOmBfsKry 0svrd+6wPG/0CL+XfF/LuhPe+gKBFSV1z9c5vFdLhAL2wVeRxeX7I8JxKCoJxAjClraV P3EEKaXHJ0DGxi76TBFQWyozKokvDyfA5dRv3IN6jV2VDUkL8syxlz4VTQ5mMHOkgANt qjUw== 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=HyMStJbvRMg/LsnHjMMhApaZaFOgs+4hqBI4nzgDuu8=; b=jVd0Z5qcFuThBRPNoRhE6sbMROIndhKA1Gk5i9DSvo/HUkE3rpVf+XkD5SGbRKqGPu sCrRjn5Xr/sWV8/cT1UEY6Usp6X+yZzDRJkyBrYvD21cY8Tq59Mxg0j/38RyPDYZuQWY 39qLZf7PNAlswSksO1YwHb1kfB3eXEC6hHhb3gWGv5PGKgIZcDzi131Ny6hjHkJ6ogJr uAe3VCUd2OxFgfpLXchWNsGrtMavyCXVpmmAcGgavTO/zsOZ5RwjmULy4pxLzWm9H4lZ Xd1R4lgH3NdHMlQVPg6cp95n4m7XLFa6Uwsy8c6qXP+f0w/qCnkzKr+foIonrdGnDlJ+ yNEA== X-Gm-Message-State: AOAM5309AckXsYeP0rNsXzj1HDPnT8W5pp57S50agTDd4Gf/GXqEKIuJ Hsei0a0yL1e+w7KyMbc5GjOKvYC2h5JDudzWYK5WXw== X-Google-Smtp-Source: ABdhPJyq0dgRlZ9vcdfGlJJ9o/7vv/JHOluEf6W7d+XcB/dMBzsonE2MxX1h+uO4GKdJXETvsUh+1iWxPya/kIcm9Dg= X-Received: by 2002:a67:7f09:: with SMTP id a9mr12627041vsd.52.1627946318418; Mon, 02 Aug 2021 16:18:38 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> From: Neal Cardwell Date: Mon, 2 Aug 2021 19:18:21 -0400 Message-ID: To: Vidhi Goel Cc: Yuchung Cheng , Mark Allman , Extensions Content-Type: multipart/alternative; boundary="000000000000064d5f05c89bcaf3" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 23:18:46 -0000 --000000000000064d5f05c89bcaf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel wrote: > > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >> >>> >>> > The fact is that Linux CC has long moved to infinite L since 2031, >>> >>> So, if our experience is with L=3D\infinity and it is demonstrably OK >>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>> submit that it makes more sense to leverage experience than it does >> >> to make things up. >>> >> +1 >> > > Yes, I agree that would be a great approach to take. > > > So, we are saying it is fine to ignore L completely and simply increase > cwnd by bytes_acked during slow start? And if this causes large bursts to > be sent out (when an implementation doesn=E2=80=99t do pacing), that is f= ine? > Yes, I think that is the proposal on the table, and it sounds good to me. A rationale would be: (1) Implementations SHOULD pace (RFC 7661). (2) Implementations that don't pace will generally be causing large bursts for many different reasons anyway (data and/or ACK aggregation in the network or end hosts), restart from idle,...) so having a constant L does not provide enough protection from bursts to justify the cost in reduced performance (in the form of slower slow-start). In support of this, experience with this as the default behavior in Linux TCP over the 2013-2021 period suggests this works well enough in practice. neal --000000000000064d5f05c89bcaf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 7:02 PM Vidhi = Goel <vidhi_goel@apple.com&g= t; wrote:

--000000000000064d5f05c89bcaf3-- From nobody Mon Aug 2 16:25: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 85BF03A2102 for ; Mon, 2 Aug 2021 16:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 uizajkbFhbwu for ; Mon, 2 Aug 2021 16:25:54 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 C9CE03A2101 for ; Mon, 2 Aug 2021 16:25:53 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id m12so18477577wru.12 for ; Mon, 02 Aug 2021 16:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RA1ZhoTAERb8+idyvlf7cWT6rMavURWYOUjvIiI4raM=; b=N/d6tn3GBe+1Z9ON9TsB4E92CLxEd32ACgOnHoxYEjso+gSIlp4mVK2Q16Tt3zRxrw kOYUVaH3K4sH03+2wkYoyp2DgHauPwwEW/RYUC7u8fv8+/q5HvHgsvp9cltXc3+PTI8J zIR1pK3d0ywt9/lpejckcOIsGhm1j6pDpMsbE2VQsfYPoZQq3ZpCdbw7wSjfv1SWobEQ RL2yhVVSCG/iLcO/KxOSvtVOI7p/3tYUwvAKWiWN51yLKw0N1PQUJV4xp0UscBYc7u5l CbczaNvNOYk2vjD2QcwOvtmjB7px+6kJPecmQSWHYl46uqLPrJobI2M4pK8JVCEhY5gm 8H+Q== 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=RA1ZhoTAERb8+idyvlf7cWT6rMavURWYOUjvIiI4raM=; b=iTH5wBcc7GCXNe++1rbGdheBSfwucyDcZCCpGyi+CtqFmH3n0Kd8E9cP7DIVBarEX+ BRe/KbedV+ZKJ/WpXhaV3qXFKT9Uil54kGNi1vYfFZPC3T4xLFlxFEDY7pm4wkGx6mnJ 7WJvvqSq1aDGu//cQi+WnWiMXScdKppH2i/BTk9LGO+5LNYFlzBlaq7qVB9kp7jCK5bw EUOkhEujR705wUwfKBkA8HWqlSrg8LWj6zS6OWu13g9cUwQxfmXKW6NrZ0guJw/c0nlA qeOGOtLxWf24HtBQoVB1f7Ki25YMz6rp/ErsixI6vQXTM5SO0bHVSlNkHKJ1Gp75WD3Y VuEA== X-Gm-Message-State: AOAM530vM4Dt+CdtDVct2bMo/7fqdjbvdyU4QLg3/j6mD3NzmJ2Ff+c1 jDUbuUOrkj2GxVjGttUkjd5LyeeGmCKdVS+sRc/pEA== X-Google-Smtp-Source: ABdhPJxVcXeq7EWCX5/cSvl5C/xrXYBGo3C4tj2QvyUKExzurVZ+scv+F7Xk4w7VnuQSo4WGcfP8os2aU/7QtXtSK6E= X-Received: by 2002:adf:8169:: with SMTP id 96mr19559537wrm.424.1627946751718; Mon, 02 Aug 2021 16:25:51 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: From: Yuchung Cheng Date: Mon, 2 Aug 2021 16:25:14 -0700 Message-ID: To: Neal Cardwell Cc: Vidhi Goel , Mark Allman , Extensions Content-Type: multipart/alternative; boundary="000000000000d9e03905c89be30e" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 23:25:59 -0000 --000000000000d9e03905c89be30e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 2, 2021 at 4:18 PM Neal Cardwell wrote: > > > On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel wrote: > >> >> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >>> >>>> >>>> > The fact is that Linux CC has long moved to infinite L since 2031, >>>> >>>> So, if our experience is with L=3D\infinity and it is demonstrably OK >>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>>> submit that it makes more sense to leverage experience than it does >>> >>> to make things up. >>>> >>> +1 >>> >> >> Yes, I agree that would be a great approach to take. >> >> >> So, we are saying it is fine to ignore L completely and simply increase >> cwnd by bytes_acked during slow start? And if this causes large bursts t= o >> be sent out (when an implementation doesn=E2=80=99t do pacing), that is = fine? >> > > Yes, I think that is the proposal on the table, and it sounds good to me. > > A rationale would be: > > (1) Implementations SHOULD pace (RFC 7661). > > (2) Implementations that don't pace will generally be causing large burst= s > for many different reasons anyway (data and/or ACK aggregation in the > network or end hosts), restart from idle,...) so having a constant L does > not provide enough protection from bursts to justify the cost in reduced > performance (in the form of slower slow-start). In support of this, > experience with this as the default behavior in Linux TCP over the > 2013-2021 period suggests this works well enough in practice. > One simple example is: Let's consider a sender receiving 1. one stretch ACK acking 100 packets due to ACK decimation vs 2. 50 ACKs each acking 2 MSS within 0.1ms due to ACK compression (2) still forms a sizable burst even with ACK clocking due to timing compression. > > neal > > > --000000000000d9e03905c89be30e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 4:18 PM Neal C= ardwell <ncardwell@google.com> wrote:


On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goe= l <vidhi_goel@= apple.com> wrote:

<= div class=3D"gmail_quote">
On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org> wrote:
=

> The fact is that= Linux CC has long moved to infinite L since 2031,

So, if our experi= ence is with L=3D\infinity and it is demonstrably OK
why don't we sa= y *THAT* instead of "make L=3D5 or L=3D10"?=C2=A0 I would
subm= it that it makes more sense to leverage experience than it does=C2=A0
to make things up.=
+1

= Yes, I agree that would be a great approach to take.

So, we are saying it is fine to ignore L completely = and simply increase cwnd by bytes_acked during slow start? And if this caus= es large bursts to be sent out (when an implementation doesn=E2=80=99t do p= acing), that is fine?=C2=A0

Yes, I th= ink that is the proposal on the table, and it sounds good to me.
=
A rationale would be:

(1) Implement= ations SHOULD pace (RFC 7661).

(2) Implementations= that don't pace will generally be causing large bursts for many differ= ent reasons anyway (data and/or ACK aggregation in the network or end hosts= ), restart from idle,...) so having a constant L does not provide enough pr= otection from bursts to justify the cost in reduced performance=C2=A0(in th= e form of slower slow-start). In support of this, experience with this as t= he default behavior in Linux TCP over the=C2=A0 2013-2021 period suggests t= his works well enough in practice.
One s= imple example is:

Let's consider a sender receiving
1. one stretch ACK acking 100 packets due to ACK decimation
vs=
2. 50 ACKs each acking 2 MSS within 0.1ms due to ACK compression=

(2) still forms a sizable burst even with ACK clo= cking due to timing compression.
=C2=A0

neal

=C2=A0
--000000000000d9e03905c89be30e-- From nobody Mon Aug 2 17:46: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 5EA343A2353 for ; Mon, 2 Aug 2021 17:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 lUETfSR26sA8 for ; Mon, 2 Aug 2021 17:46:21 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (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 C2E903A2357 for ; Mon, 2 Aug 2021 17:46:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=URpPPNFnu7+Nkl65qsCw7RKDNL9UTX55kcKnHL3e6SFVcqLDwGrfmh3MpC9ngj9RFe3oUHlIK64NlIjTea3RdfqHW4Aj3/sg5vJgBa4dPpBXPALgsyQwSl41Xq4rXpzNvp6dMP4DGhPVVbXSvCWVA9HpT4suzwcNWHiC/qr3O7G6FwNjwil4QUwShN2fgz0ZimkN95Z6YhoQir8bdltNHB8GGEUwj1hAu/NhQf/R7p8UkrxXUhO0b7LM9/Hol3GAh8h7MtUh9Lr+avrhTecYvs5CUDN4ahkqz+CSd/Qt1UKujUNUA080glTad/vIl0gb5+I/YpUqbgcNGA0PPlULWA== 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=cdzKlrG5Y+Tx3CUuFh2VhMRWnDHMNYzHAesMP8VRYzs=; b=oWl5Lxo/T9ohz7BkBssHGCH/m3cq4Igsl4hcBsTi26tQFlGlgQi1kvMllsHN8kc3qGJmFLHT0E9c2qznkXu88JQYfJbG4Z9e4hbAAb+lmTSSGDSIw9FJiRDNozueAbossAijfofDH9UqABZW0cIafmDIM5Ti8696dn//8qD8X0di0kMh5k+Qe+vb/BSc23hXP9YBRDzcM+nC7tjvVJuz4Q1fywvMzq238RJXLO1sfqqpNLSCwaLm0DnzPuICrOfWEhuEOsOSumOsWRBx/YWo79ueNn2nCYt3OKtQX6+6XeM5GePGkc+H3t7acDUzbFDzI0UnPXVXXQXkCDs7oIuHaw== 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=cdzKlrG5Y+Tx3CUuFh2VhMRWnDHMNYzHAesMP8VRYzs=; b=jUai2bqJ3hsnWnxTT9/y+m4FfbIPI7xZtVAwXW/ZEZiosEJ0J4VwPIctJJ2vb0Rw72IWnEa1dOqLIwT1elSp6+2GP6xdhMg9bsk73YqP6GJwpdsJ3B+kcKiDv2u889oo1W1DqMoJUjv+Mp/Iig3lqdwGAvL1z6sVEA+lH+fTXso= Received: from PH0PR00MB1030.namprd00.prod.outlook.com (2603:10b6:510:48::7) by PH0PR00MB0981.namprd00.prod.outlook.com (2603:10b6:510:37::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4424.0; Tue, 3 Aug 2021 00:46:15 +0000 Received: from PH0PR00MB1030.namprd00.prod.outlook.com ([fe80::1123:3957:e983:ce92]) by PH0PR00MB1030.namprd00.prod.outlook.com ([fe80::1123:3957:e983:ce92%6]) with mapi id 15.20.4429.000; Tue, 3 Aug 2021 00:46:15 +0000 From: Praveen Balasubramanian To: "ncardwell=40google.com@dmarc.ietf.org" , "vidhi_goel@apple.com" CC: "tcpm@ietf.org" , "mallman@icir.org" Thread-Topic: =?utf-8?B?W0VYVEVSTkFMXSBSZTogW3RjcG1dIExpbnV4IGRvZXNu4oCZdCBpbXBsZW1l?= =?utf-8?Q?nt_RFC3465?= Thread-Index: AQHXg/VmIGQ1NXlS/Uqlnv2gvav8R6tZ5ikAgAAP/4CAAAfJgIAAFFQAgABT2oCAAAfpAIAAR2EAgAXT8oCAAEKRAIAACfiAgAACaoCAAAMVgIAAAYCAgAAEkICAABM14A== Date: Tue, 3 Aug 2021 00:46:15 +0000 Message-ID: References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b89cfd66-8008-4f6e-a422-6144fe6ed115; 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-08-03T00:27:05Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eeda92c5-89fd-44c6-640a-08d956181986 x-ms-traffictypediagnostic: PH0PR00MB0981: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /Jgf0rgr1ynOQtHXb8pl29JeTT0/lMEBZd8oI9We9dkTBfUNj7FU9uj1fRAipChn+ftEywdsTDQaCGlv8E1499NXw1nF46Tqrvz4L/d6z47Cr9Vk66HojOzgpdfS08OWE7JJ4peU3YxJT1WLsuqIc4MPHg/acKGO9jG7va1sYO5pQYnnfrX5QAZqI4RExKUfdkoGlx+oBfsTaLnth3W1+OJPeYhjlonkAbgnTX8fReIq6EYLjNsXsKKn2WIrknzLpYfRsmH9w53d8BWMXs9fjsGY64RKN9B1NkRGyJx1gvrP/QBOts/ij0WV36MrlWvzPMrS0I9310qyWUus8Pbn4ru0B0OeWAyur78PLveLrrbFkwRpsqpk9w0/vqtFFWZQesOY+i3hRDME3xodCSJHDZ4Fns9CAvuTN/3OA9t1BUjZ6mTzZ/t0ERAt6lzQm6ptkL9cyBSFn1sA7TLQgpI6vCUVa0t6D3N8WQZQE8UylZpI9AI868ZUCOzH0Nr9LenfV8nrKdEpViRn0/r1AOCwcb5v1v6+jxe+VljyHpqD4+62FZBi4aKCWkjVF3S8ddMJo8rxwL8OnpbIvcw42cZvFCK9mxNJAWT3UHApgjgpY5yEBOYa70YdMrhXv/vWDgzCpmpgyc+lR5DIgs9NEc4ulE2R4xA36YyiPUzs28Rt5EY2UeOCCQ9xYddIJlhcwDoWrPWjoPy7NE1BsHTGVshEJQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR00MB1030.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(122000001)(508600001)(83380400001)(9686003)(38070700005)(110136005)(38100700002)(186003)(33656002)(8990500004)(7696005)(82950400001)(54906003)(5660300002)(82960400001)(6506007)(55016002)(71200400001)(66946007)(76116006)(66556008)(53546011)(316002)(10290500003)(52536014)(8936002)(66476007)(64756008)(66446008)(4326008)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OGlXZmJoeDJSMlFvVVdBUVA4d082cWpldXIyMEtiODlYME81b1lLQmpkaGUw?= =?utf-8?B?VnBlU1VwWlAzT0Q2YUxaQS9tQ2oyRTJhU3R2SDVqdWozQ1dxR3FqYWlxZXFL?= =?utf-8?B?d0FpMjlBYXpPQWNLWDNVWFN5UVJzMmtaK2VsY2ZUcjZYdDZrdGhmSkdXRXZ5?= =?utf-8?B?dnhBcFV5ZUthdEkybG5mdkh2ZE9JK09RazAwcEJrOHVEN0wvOEZiUjl5MDhK?= =?utf-8?B?YzBwR3FzQmFTdnkvWllTYmVsODAwK25JUUR6YVlPRlZzNWk3MTFOeFQxZ0Mz?= =?utf-8?B?a1Iza3gxaXNYYVpmdkVmZC8vSlZRbENaSXFDSHRVaU9YS01jSWNPK1g1OVIz?= =?utf-8?B?cG1zK05mNUw5MCs1S3NVczdzejJpUHZNWVpqaERQMHArNHUyb3pNbUtMczNF?= =?utf-8?B?bWFDQk40S2ROQ21wS2Vid2c0c29zblA0bTk4UUJkeEV4QUEzc2NFRHJDc3I4?= =?utf-8?B?MGd2amN1anJsb252Zy9oTHFsMEZjSFR1YkdNV3F2OWJ0a3J3WDYvQzlzeXlx?= =?utf-8?B?MTNFaHBRSUtlbjhzb1luRXVsWWkvdytzV09rVktiSDFSaHZVSHdFK1l0bE90?= =?utf-8?B?bUJEL3VyTFZxRG9xWm12M0Z0YUx5YWEwVHhPVEo1dTQ1VnRuYi81U2s5S3JK?= =?utf-8?B?Nlp3eSsrM0dlVGpNbERUZ1JzMEh5TVFZWitXYUZ1dDA4S011Ny8yYlVIWkZ1?= =?utf-8?B?dlR5QUVqYjYvRmU0Tkk1N3Q2WHZ2V1U4bjdIeW0zcU5mMWpSSUVwaFNkcmJ1?= =?utf-8?B?bHA0QmlaOUFDMFllSTZVazZUTFpuYVhXRWZZNXRJbWc0ZEttaWttL1lIZ2Qx?= =?utf-8?B?bDRrRXVJVk55ckFjTCttRWNCWXNvM0tUN2VKL3I3bTlxVHFHTTdqVGVOWmR4?= =?utf-8?B?ZkI4WFVUWWtrcThVbHZJQXRyWTQ1TmFNUFNMMjFnSUpScWtwMVZLUTBtUWc2?= =?utf-8?B?aFFuSHpDZ3p0S3I0VE5NTFlBNmtkTk5NbkxkNGllTE9xMTBzY1dvL0srZmdF?= =?utf-8?B?RUFMWGVxbTcxejVWMUNReFkvQXYzNHcrU1pQb2grWnpVTFdhRlNvNWd1eTJP?= =?utf-8?B?WVZ6SlM5Q09JWC9MYTlwTzl0LzZ1dmZ2RVRYa3dYR1ZFQTNVUG51UElFVjhw?= =?utf-8?B?cU1tY1V3dlM0b1MwRkVra2RJbU5aRUtNZTYwdlY1U0FaUjhNMzdxbUlNbzJX?= =?utf-8?B?WWJkUkdQbXpYYUlrcHNSRFRQMGViLzNpSXZEd2dsTzFSRjNHU2RNcjZNbVVj?= =?utf-8?B?OVhpYUxNL2dhKzNGc01sUm1yNmJSNG9hdXQ5eThTa0hCa08rbnR0M0IrM1JK?= =?utf-8?B?SDJiK0NsT2lVWW1McUZGdlU2c1hqM0tGUXBZeXRhRHdGajV3MGdmZUJCQ0N4?= =?utf-8?B?anN3QzdudGcxRmJlMFhFN0JlNnF6a3NKMERPakFLTWwzVnRISXpVTk56bjhQ?= =?utf-8?B?S09WOXhyV1lUVTB4b2JwTmxGbmJNWGk2WTQwakRTZHdZaTAvaFZWcVI5VHQx?= =?utf-8?B?eHFneUIxeDFpOTBIWWUzOTlGa2EybXFmOVdZYUlRSFhRVFJsRGtyeWxNbm1r?= =?utf-8?B?RHlxcFJvR1h3ZmMyVVpCTmFjMkxFZ3Z4dGcwS2RoOFhweDdRRVEzcDg2L3pY?= =?utf-8?B?TUNEdXNCbllqSEdUbHNWUnRnMklEdkxwZWwwdjBRcWU5eGxFQkhSM2RSUzJu?= =?utf-8?B?ajlCaTdJdEhuY01IandZVUR4a29Ea3FlYkM4ckR6OHY3Y3VSUjJKR1VmK1NX?= =?utf-8?B?TGRvTG84eTRpSDNqV2hXNTFMT0NpaXBTT2ZFM1dDampvUjg4TU1haGxpdTFX?= =?utf-8?B?N0Z3c0Z5eWVnS0Z0YlVMRnNobkF5Z1Zob3F5TXJydHlRUTBuc09idTV2bW85?= =?utf-8?Q?CtYLOlbADDCHZ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PH0PR00MB10302B312DB96B8A6324C55FB6F09PH0PR00MB1030namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR00MB1030.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eeda92c5-89fd-44c6-640a-08d956181986 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 00:46:15.5554 (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: Em+epCCKmcYvq3M0gZXb018VMw6IwrKDRaof6VlX2PsoB59MQOhetX6TPpRa5Ij6VY7PGmWRe3l5qnZO2Wm5dtwBwKHBxIfiO1fbyyhBXns= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR00MB0981 Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A__Linux_doesn=E2=80=99t_imp?= =?utf-8?q?lement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 00:46:25 -0000 --_000_PH0PR00MB10302B312DB96B8A6324C55FB6F09PH0PR00MB1030namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gZXhwZXJpbWVudHMgYSBmZXcgeWVhcnMgYWdvIG9uIERDIG5ldHdvcmtzLCB2YWx1ZXMgb3Zl ciBMPTggcmVzdWx0ZWQgaW4gYSBub3RpY2VhYmxlIGluY3JlYXNlIGluIHBhY2tldCBkcm9wcyBh bmQgcmV0cmFuc21pc3Npb25zICh3aXRob3V0IHBhY2luZykuIFdpbmRvd3MgVENQIGhhcyBiZWVu IHVzaW5nIEw9OCBmb3IgbWFueSB5ZWFycyBub3cuIElmIHdlIGRvIHdhbnQgdG8gc3BlY2lmeSBh IGZhbGxiYWNrIEwgdmFsdWUgZm9yIGltcGxlbWVudGF0aW9ucyB0aGF0IGNhbm5vdCBwYWNlLCBt eSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHVzZSB0aGUgdmFsdWUgOC4NCg0KTmVhbCwgYXJlIHRo ZXJlIGNhc2VzIHdoZXJlIExpbnV4IGlzIG9yIGNhbiBiZSBkZXBsb3llZCB3aXRoIGluZmluaXRl IEwgYW5kIG5vIHBhY2luZz8NCg0KRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgTmVhbCBDYXJkd2VsbA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMiwgMjAyMSA0 OjE4IFBNDQpUbzogVmlkaGkgR29lbCA8dmlkaGlfZ29lbEBhcHBsZS5jb20+DQpDYzogRXh0ZW5z aW9ucyA8dGNwbUBpZXRmLm9yZz47IE1hcmsgQWxsbWFuIDxtYWxsbWFuQGljaXIub3JnPg0KU3Vi amVjdDogW0VYVEVSTkFMXSBSZTogW3RjcG1dIExpbnV4IGRvZXNu4oCZdCBpbXBsZW1lbnQgUkZD MzQ2NQ0KDQoNCg0KT24gTW9uLCBBdWcgMiwgMjAyMSBhdCA3OjAyIFBNIFZpZGhpIEdvZWwgPHZp ZGhpX2dvZWxAYXBwbGUuY29tPG1haWx0bzp2aWRoaV9nb2VsQGFwcGxlLmNvbT4+IHdyb3RlOg0K DQpPbiBNb24sIEF1ZyAyLCAyMDIxIGF0IDM6MzcgUE0gTWFyayBBbGxtYW4gPG1hbGxtYW5AaWNp ci5vcmc8bWFpbHRvOm1hbGxtYW5AaWNpci5vcmc+PiB3cm90ZToNCg0KPiBUaGUgZmFjdCBpcyB0 aGF0IExpbnV4IENDIGhhcyBsb25nIG1vdmVkIHRvIGluZmluaXRlIEwgc2luY2UgMjAzMSwNCg0K U28sIGlmIG91ciBleHBlcmllbmNlIGlzIHdpdGggTD1caW5maW5pdHkgYW5kIGl0IGlzIGRlbW9u c3RyYWJseSBPSw0Kd2h5IGRvbid0IHdlIHNheSAqVEhBVCogaW5zdGVhZCBvZiAibWFrZSBMPTUg b3IgTD0xMCI/ICBJIHdvdWxkDQpzdWJtaXQgdGhhdCBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIGxl dmVyYWdlIGV4cGVyaWVuY2UgdGhhbiBpdCBkb2VzDQp0byBtYWtlIHRoaW5ncyB1cC4NCisxDQoN ClllcywgSSBhZ3JlZSB0aGF0IHdvdWxkIGJlIGEgZ3JlYXQgYXBwcm9hY2ggdG8gdGFrZS4NCg0K U28sIHdlIGFyZSBzYXlpbmcgaXQgaXMgZmluZSB0byBpZ25vcmUgTCBjb21wbGV0ZWx5IGFuZCBz aW1wbHkgaW5jcmVhc2UgY3duZCBieSBieXRlc19hY2tlZCBkdXJpbmcgc2xvdyBzdGFydD8gQW5k IGlmIHRoaXMgY2F1c2VzIGxhcmdlIGJ1cnN0cyB0byBiZSBzZW50IG91dCAod2hlbiBhbiBpbXBs ZW1lbnRhdGlvbiBkb2VzbuKAmXQgZG8gcGFjaW5nKSwgdGhhdCBpcyBmaW5lPw0KDQpZZXMsIEkg dGhpbmsgdGhhdCBpcyB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLCBhbmQgaXQgc291bmRzIGdv b2QgdG8gbWUuDQoNCkEgcmF0aW9uYWxlIHdvdWxkIGJlOg0KDQooMSkgSW1wbGVtZW50YXRpb25z IFNIT1VMRCBwYWNlIChSRkMgNzY2MSkuDQoNCigyKSBJbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24n dCBwYWNlIHdpbGwgZ2VuZXJhbGx5IGJlIGNhdXNpbmcgbGFyZ2UgYnVyc3RzIGZvciBtYW55IGRp ZmZlcmVudCByZWFzb25zIGFueXdheSAoZGF0YSBhbmQvb3IgQUNLIGFnZ3JlZ2F0aW9uIGluIHRo ZSBuZXR3b3JrIG9yIGVuZCBob3N0cyksIHJlc3RhcnQgZnJvbSBpZGxlLC4uLikgc28gaGF2aW5n IGEgY29uc3RhbnQgTCBkb2VzIG5vdCBwcm92aWRlIGVub3VnaCBwcm90ZWN0aW9uIGZyb20gYnVy c3RzIHRvIGp1c3RpZnkgdGhlIGNvc3QgaW4gcmVkdWNlZCBwZXJmb3JtYW5jZSAoaW4gdGhlIGZv cm0gb2Ygc2xvd2VyIHNsb3ctc3RhcnQpLiBJbiBzdXBwb3J0IG9mIHRoaXMsIGV4cGVyaWVuY2Ug d2l0aCB0aGlzIGFzIHRoZSBkZWZhdWx0IGJlaGF2aW9yIGluIExpbnV4IFRDUCBvdmVyIHRoZSAg MjAxMy0yMDIxIHBlcmlvZCBzdWdnZXN0cyB0aGlzIHdvcmtzIHdlbGwgZW5vdWdoIGluIHByYWN0 aWNlLg0KDQpuZWFsDQoNCg0K --_000_PH0PR00MB10302B312DB96B8A6324C55FB6F09PH0PR00MB1030namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiBleHBlcmltZW50cyBhIGZldyB5ZWFycyBhZ28gb24gREMgbmV0d29ya3MsIHZh bHVlcyBvdmVyIEw9OCByZXN1bHRlZCBpbiBhIG5vdGljZWFibGUgaW5jcmVhc2UgaW4gcGFja2V0 IGRyb3BzIGFuZCByZXRyYW5zbWlzc2lvbnMgKHdpdGhvdXQgcGFjaW5nKS4gV2luZG93cyBUQ1Ag aGFzIGJlZW4gdXNpbmcgTD04IGZvciBtYW55IHllYXJzIG5vdy4gSWYgd2UgZG8gd2FudCB0byBz cGVjaWZ5IGEgZmFsbGJhY2sNCiBMIHZhbHVlIGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW5u b3QgcGFjZSwgbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byB1c2UgdGhlIHZhbHVlIDguPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk5lYWwsIGFyZSB0aGVyZSBjYXNlcyB3aGVyZSBMaW51eCBpcyBv ciBjYW4gYmUgZGVwbG95ZWQgd2l0aCBpbmZpbml0ZSBMIGFuZCBubyBwYWNpbmc/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiB0 Y3BtICZsdDt0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpO ZWFsIENhcmR3ZWxsPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDIsIDIwMjEgNDox OCBQTTxicj4NCjxiPlRvOjwvYj4gVmlkaGkgR29lbCAmbHQ7dmlkaGlfZ29lbEBhcHBsZS5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBFeHRlbnNpb25zICZsdDt0Y3BtQGlldGYub3JnJmd0OzsgTWFy ayBBbGxtYW4gJmx0O21hbGxtYW5AaWNpci5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtF WFRFUk5BTF0gUmU6IFt0Y3BtXSBMaW51eCBkb2VzbuKAmXQgaW1wbGVtZW50IFJGQzM0NjU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgMiwgMjAy MSBhdCA3OjAyIFBNIFZpZGhpIEdvZWwgJmx0OzxhIGhyZWY9Im1haWx0bzp2aWRoaV9nb2VsQGFw cGxlLmNvbSI+dmlkaGlfZ29lbEBhcHBsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBB dWcgMiwgMjAyMSBhdCAzOjM3IFBNIE1hcmsgQWxsbWFuICZsdDs8YSBocmVmPSJtYWlsdG86bWFs bG1hbkBpY2lyLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbGxtYW5AaWNpci5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCiZndDsgVGhlIGZhY3QgaXMgdGhhdCBMaW51eCBDQyBoYXMgbG9uZyBtb3Zl ZCB0byBpbmZpbml0ZSBMIHNpbmNlIDIwMzEsPGJyPg0KPGJyPg0KU28sIGlmIG91ciBleHBlcmll bmNlIGlzIHdpdGggTD1caW5maW5pdHkgYW5kIGl0IGlzIGRlbW9uc3RyYWJseSBPSzxicj4NCndo eSBkb24ndCB3ZSBzYXkgKlRIQVQqIGluc3RlYWQgb2YgJnF1b3Q7bWFrZSBMPTUgb3IgTD0xMCZx dW90Oz8mbmJzcDsgSSB3b3VsZDxicj4NCnN1Ym1pdCB0aGF0IGl0IG1ha2VzIG1vcmUgc2Vuc2Ug dG8gbGV2ZXJhZ2UgZXhwZXJpZW5jZSB0aGFuIGl0IGRvZXMmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBtYWtl IHRoaW5ncyB1cC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4rMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIGFncmVl IHRoYXQgd291bGQgYmUgYSBncmVhdCBhcHByb2FjaCB0byB0YWtlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Tbywgd2UgYXJlIHNheWluZyBpdCBpcyBmaW5lIHRvIGlnbm9yZSBMIGNvbXBsZXRlbHkg YW5kIHNpbXBseSBpbmNyZWFzZSBjd25kIGJ5IGJ5dGVzX2Fja2VkIGR1cmluZyBzbG93IHN0YXJ0 PyBBbmQgaWYgdGhpcyBjYXVzZXMgbGFyZ2UgYnVyc3RzIHRvIGJlIHNlbnQgb3V0ICh3aGVuIGFu IGltcGxlbWVudGF0aW9uIGRvZXNu4oCZdCBkbyBwYWNpbmcpLCB0aGF0IGlzIGZpbmU/Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlllcywgSSB0aGluayB0aGF0IGlzIHRoZSBwcm9wb3NhbCBvbiB0aGUgdGFi bGUsIGFuZCBpdCBzb3VuZHMgZ29vZCB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSByYXRpb25hbGUgd291bGQgYmU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigxKSBJbXBsZW1l bnRhdGlvbnMgU0hPVUxEIHBhY2UgKFJGQyA3NjYxKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDIpIEltcGxlbWVudGF0aW9ucyB0aGF0IGRv bid0IHBhY2Ugd2lsbCBnZW5lcmFsbHkgYmUgY2F1c2luZyBsYXJnZSBidXJzdHMgZm9yIG1hbnkg ZGlmZmVyZW50IHJlYXNvbnMgYW55d2F5IChkYXRhIGFuZC9vciBBQ0sgYWdncmVnYXRpb24gaW4g dGhlIG5ldHdvcmsgb3IgZW5kIGhvc3RzKSwgcmVzdGFydCBmcm9tIGlkbGUsLi4uKSBzbyBoYXZp bmcgYSBjb25zdGFudCBMIGRvZXMgbm90IHByb3ZpZGUgZW5vdWdoDQogcHJvdGVjdGlvbiBmcm9t IGJ1cnN0cyB0byBqdXN0aWZ5IHRoZSBjb3N0IGluIHJlZHVjZWQgcGVyZm9ybWFuY2UmbmJzcDso aW4gdGhlIGZvcm0gb2Ygc2xvd2VyIHNsb3ctc3RhcnQpLiBJbiBzdXBwb3J0IG9mIHRoaXMsIGV4 cGVyaWVuY2Ugd2l0aCB0aGlzIGFzIHRoZSBkZWZhdWx0IGJlaGF2aW9yIGluIExpbnV4IFRDUCBv dmVyIHRoZSZuYnNwOyAyMDEzLTIwMjEgcGVyaW9kIHN1Z2dlc3RzIHRoaXMgd29ya3Mgd2VsbCBl bm91Z2ggaW4gcHJhY3RpY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPm5lYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_PH0PR00MB10302B312DB96B8A6324C55FB6F09PH0PR00MB1030namp_-- From nobody Mon Aug 2 17:53: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 77E3C3A0063 for ; Mon, 2 Aug 2021 17:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbXhUhyi82nS for ; Mon, 2 Aug 2021 17:53:31 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 7D04F3A005B for ; Mon, 2 Aug 2021 17:53:31 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id t25so5767234uar.13 for ; Mon, 02 Aug 2021 17:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jNEL0j8JyOsbjq/ahAHt7k2cU7aQPw0tMkwBZNhcKEM=; b=G8BudGsCmBbueu5P8Px15ksDHBRE49xXoMiUTONItpVJY0noJtzlv9E7aNIcum7vyy gnzQTB2pfB8+GHw63DHyRO86DwG28PrJmVl96pvLyGaPJf4+dJZuoZeS9ZMJ+kPDzrS7 CX+E+vWU9VjuHim2cnBGevjsJh4CgZtoYcczlKR2hOPZNGKccDVioM9nNPS5WdweXzmI YmBoUMZ9dM3qJuH9OI7DArvz64qaoSUhEdODVL+ZGD3VHn3amWUAgGwvrHayKfpDef5B qn/svQu2ORVEKhVqHbB1XQndK+425Y4dgbobuLWq0eYuFLHGMKeBjAhA3koraEOKsI6y NW4w== 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=jNEL0j8JyOsbjq/ahAHt7k2cU7aQPw0tMkwBZNhcKEM=; b=CFL1WzpHIPoBfgSdShy4A9A40+neDNUeo9qAcc8h5MzO65OHKFw3HsUVNH1MXYB1Wt j6FTV2vVvO8x41FoZgWNjLG6hmViiVIPvGAOZFeTvUdBw1V2DI67Pza0Huz6++lfycs3 QONq+K3weNoiJ5LCkkzCIv3TAGciL95IXOQK25jNG/Xb/9BSeumC1HvMI1HhSJRmryg4 NVyipD3ft2xidlgdrMQPvy/yFiF104rI55M3PmMjZUmCKvD04FSlMrZa5wICU+OgRB9T wFROmWeWRUii6HgKJhMI++DjwGnLieGx7s/fMCInqeou32q9oVCR4Pdc3wjP8l8h5DAn TD7w== X-Gm-Message-State: AOAM532STqC3Pz8ge2d8iKLKw+1b8OeS87KZom7pbsTq4JBjiecHsc4p E5v44MPW/Uo5c4Tx13JFrn+pMsgW7BQc1bf6zByUUg== X-Google-Smtp-Source: ABdhPJxEiOdaPR4C34ASAT3GcoEoJwTwIsd2LplsF+MeHqPa9k4vbGdIj6VekbDSCww1im6g9xbSkzjSsW9EPlcS2xE= X-Received: by 2002:ab0:71d6:: with SMTP id n22mr12905706uao.65.1627952009617; Mon, 02 Aug 2021 17:53:29 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: From: Neal Cardwell Date: Mon, 2 Aug 2021 20:52:42 -0400 Message-ID: To: Praveen Balasubramanian Cc: "vidhi_goel@apple.com" , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="0000000000003f074f05c89d1d56" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A__Linux_doesn=E2=80=99t_imp?= =?utf-8?q?lement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 00:53:37 -0000 --0000000000003f074f05c89d1d56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian wrote: > In experiments a few years ago on DC networks, values over L=3D8 resulted= in > a noticeable increase in packet drops and retransmissions (without pacing= ). > Windows TCP has been using L=3D8 for many years now. If we do want to spe= cify > a fallback L value for implementations that cannot pace, my suggestion > would be to use the value 8. > > > > Neal, are there cases where Linux is or can be deployed with infinite L > and no pacing? > Yes, "infinite L and no pacing" is the default behavior for Linux TCP, starting in 2013 for slow-start and then starting in 2015 for congestion avoidance. Yuchung pasted the URLs for the exact Linux commits above, which are: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D9cd981dcf174d26805a032aefa791436da709bee https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D814d488c61260521b1b3cc97063700a5a6667c8f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 But I understand that not everyone is in a position to read GPL-licensed code. :-) best regards, neal > > > *From:* tcpm *On Behalf Of * Neal Cardwell > *Sent:* Monday, August 2, 2021 4:18 PM > *To:* Vidhi Goel > *Cc:* Extensions ; Mark Allman > *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC3465 > > > > > > > > On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel wrote: > > > > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: > > > > The fact is that Linux CC has long moved to infinite L since 2031, > > So, if our experience is with L=3D\infinity and it is demonstrably OK > why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would > submit that it makes more sense to leverage experience than it does > > to make things up. > > +1 > > > > Yes, I agree that would be a great approach to take. > > > > So, we are saying it is fine to ignore L completely and simply increase > cwnd by bytes_acked during slow start? And if this causes large bursts to > be sent out (when an implementation doesn=E2=80=99t do pacing), that is f= ine? > > > > Yes, I think that is the proposal on the table, and it sounds good to me. > > > > A rationale would be: > > > > (1) Implementations SHOULD pace (RFC 7661). > > > > (2) Implementations that don't pace will generally be causing large burst= s > for many different reasons anyway (data and/or ACK aggregation in the > network or end hosts), restart from idle,...) so having a constant L does > not provide enough protection from bursts to justify the cost in reduced > performance (in the form of slower slow-start). In support of this, > experience with this as the default behavior in Linux TCP over the > 2013-2021 period suggests this works well enough in practice. > > > > neal > > > > > --0000000000003f074f05c89d1d56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 8:46 PM Pravee= n Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, value= s over L=3D8 resulted in a noticeable increase in packet drops and retransm= issions (without pacing). Windows TCP has been using L=3D8 for many years n= ow. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0

Neal, are there cases where Linux is or can be deplo= yed with infinite L and no pacing?


Yes, "infinite L and no pacing" is the default behavior f= or Linux TCP, starting in 2013 for slow-start and then starting in 2015 for= congestion avoidance.

Yuchung pasted the URLs for= the exact Linux commits above, which are:


But I understand that not everyone = is in a position to read GPL-licensed code. :-)

be= st regards,
neal

=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <vidhi_goel@apple.com> wrote:

=C2=A0

Yes, I think that is the proposal on the table, and = it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).

=C2=A0

(2) Implementations that don't pace will general= ly be causing large bursts for many different reasons anyway (data and/or A= CK aggregation in the network or end hosts), restart from idle,...) so havi= ng a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

--0000000000003f074f05c89d1d56-- From nobody Mon Aug 2 18:13: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 1E9733A0765 for ; Mon, 2 Aug 2021 18:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6y81BtYuRSE for ; Mon, 2 Aug 2021 18:12:58 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBE83A0755 for ; Mon, 2 Aug 2021 18:12:57 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id l34-20020a05600c1d22b02902573c214807so605944wms.2 for ; Mon, 02 Aug 2021 18:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QEBLPXZ7/M0bPvbF1d+Hti+t5/AoM2WSL08Y+BsD4pw=; b=EcbDbLNQTpLMWV3CtOphXpTsPMiF9szwCKWrYk+NskaaF7PQfaAQuUXxTic9MBqGAs Lzn4oQq11nQRQCqthgwYzHI11+1snxChCiS3jzu4zs1mynkK2UmdV0zfN42PDM3pPbw7 N4lYPz4I5YzQlVCdPvaEKcQisEWa7SbrKGZUCuxOpuZmmNm+2ZpKNt5iRJV9JS69Lc2H H5ujiaOkdTVTVTas2f7+NSsSm18UwbvTcR1ezlWy+XketbQvlyYWqyCCchN4uI7rHPmT 8TEwsi5EdWn/or8yMaYPz2vbgnjk+X9HrAsvhBbeP1aNp2iyA/HThfkhOf5vbVQwhvAE ijvA== 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=QEBLPXZ7/M0bPvbF1d+Hti+t5/AoM2WSL08Y+BsD4pw=; b=G4kiXcMgTofq0vXkLR3qn4QsqKyvIlkhmruBRdX86E8zsWX+OGZSbSHEaC+5rYH9Cc 3PYj74S91deiKoSYtFI7xrDmk9aNdXDGto3KR8jO54/x5+ZaDcB97UJ86n2UvxfExcwO iNbAi4d51LKbm2ziPjyy+6Aav17dZe9OQh8xG5JFEArzkiMV+x8RudweCI8QymBTTVU6 JMqyccAvSX/a3rO4bznZVeqnfhkDgrEWz+TSaGuQnx8iWJsLnXkgdKIBcH/JvUCc1Ax+ b2VTx4IYwjEruJepaFPxW7XEQrTQ6vLujg00O9YYQDZvo7n74ON9PnXXwYr4OW2S9s3e HiWA== X-Gm-Message-State: AOAM531yTeA0rshxaI5lzk1NzXowzrJYGwms4LNybRYOVwm6ObC7V84R 8LxlamTqKWfzZKx9ZvdsEzDz0eSVyexK8m6fuedgOw== X-Google-Smtp-Source: ABdhPJyk9Msr+NBy5dFYZ+dg4/O8GMU8dzUqXfs9an/67yqc1IsTivOki45sOTgVKnR4Fl2j3v4x9dDoWrR/rCT8IYA= X-Received: by 2002:a1c:f206:: with SMTP id s6mr18794049wmc.102.1627953174209; Mon, 02 Aug 2021 18:12:54 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: From: Yuchung Cheng Date: Mon, 2 Aug 2021 18:12:16 -0700 Message-ID: To: Neal Cardwell Cc: Praveen Balasubramanian , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="000000000000a941fc05c89d62bd" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 01:13:03 -0000 --000000000000a941fc05c89d62bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell wrote: > > > On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian 40microsoft.com@dmarc.ietf.org> wrote: > >> In experiments a few years ago on DC networks, values over L=3D8 resulte= d >> in a noticeable increase in packet drops and retransmissions (without >> pacing). Windows TCP has been using L=3D8 for many years now. If we do w= ant >> to specify a fallback L value for implementations that cannot pace, my >> suggestion would be to use the value 8. >> >> >> >> Neal, are there cases where Linux is or can be deployed with infinite L >> and no pacing? >> > > Yes, "infinite L and no pacing" is the default behavior for Linux TCP, > starting in 2013 for slow-start and then starting in 2015 for congestion > avoidance. > To be more clear: both fq_pacing and TCP pacing have been disabled by default in Linux upstream. We do not know how much Linux senders enable them today besides the Google servers. Regarding L =3D 8, to avoid another round of why or why not. We could say inf-L causes line-rate burst up to the stretched ACK degree so put a comfortable L if you prefer, then mention implementation practice like yours. At the end of the day it's ad-hoc (or "art") and subject to change. It might be sensible to cap at cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of ACKs. > > > Yuchung pasted the URLs for the exact Linux commits above, which are: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D9cd981dcf174d26805a032aefa791436da709bee > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D814d488c61260521b1b3cc97063700a5a6667c8f > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 > > But I understand that not everyone is in a position to read GPL-licensed > code. :-) > > best regards, > neal > > > >> >> >> *From:* tcpm *On Behalf Of * Neal Cardwell >> *Sent:* Monday, August 2, 2021 4:18 PM >> *To:* Vidhi Goel >> *Cc:* Extensions ; Mark Allman >> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC3465 >> >> >> >> >> >> >> >> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel wrote: >> >> >> >> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >> >> >> > The fact is that Linux CC has long moved to infinite L since 2031, >> >> So, if our experience is with L=3D\infinity and it is demonstrably OK >> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >> submit that it makes more sense to leverage experience than it does >> >> to make things up. >> >> +1 >> >> >> >> Yes, I agree that would be a great approach to take. >> >> >> >> So, we are saying it is fine to ignore L completely and simply increase >> cwnd by bytes_acked during slow start? And if this causes large bursts t= o >> be sent out (when an implementation doesn=E2=80=99t do pacing), that is = fine? >> >> >> >> Yes, I think that is the proposal on the table, and it sounds good to me= . >> >> >> >> A rationale would be: >> >> >> >> (1) Implementations SHOULD pace (RFC 7661). >> >> >> >> (2) Implementations that don't pace will generally be causing large >> bursts for many different reasons anyway (data and/or ACK aggregation in >> the network or end hosts), restart from idle,...) so having a constant L >> does not provide enough protection from bursts to justify the cost in >> reduced performance (in the form of slower slow-start). In support of th= is, >> experience with this as the default behavior in Linux TCP over the >> 2013-2021 period suggests this works well enough in practice. >> >> >> >> neal >> >> >> >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000a941fc05c89d62bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 5:53 PM Neal C= ardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
=

On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=3D40microsoft= .com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, value= s over L=3D8 resulted in a noticeable increase in packet drops and retransm= issions (without pacing). Windows TCP has been using L=3D8 for many years n= ow. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0

Neal, are there cases where Linux is or can be deplo= yed with infinite L and no pacing?


Yes, "infinite L and no pacing" is the default behavior f= or Linux TCP, starting in 2013 for slow-start and then starting in 2015 for= congestion avoidance.
To be more clear:= both fq_pacing and TCP pacing have been disabled by default in Linux upstr= eam. We do not know how much Linux senders enable them today besides the Go= ogle servers.

Regarding L =3D 8, to avoid another = round of why or why not. We could say inf-L causes line-rate burst up to th= e stretched ACK degree so put a comfortable L if you prefer, then mention i= mplementation practice like yours. At the end of the day it's ad-hoc (o= r "art") and subject to change. It might be sensible to cap at cw= nd to disincentivize receivers / middle-boxes bunching up 10 rounds of ACKs= .

= =C2=A0
Yuchung pasted the URLs for = the exact Linux commits above, which are:


But I understand that not everyone i= s in a position to read GPL-licensed code. :-)

bes= t regards,
neal

=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <vidhi_goel@apple.com> wrote:

=C2=A0

Yes, I think that is the proposal on the table, and = it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).

=C2=A0

(2) Implementations that don't pace will general= ly be causing large bursts for many different reasons anyway (data and/or A= CK aggregation in the network or end hosts), restart from idle,...) so havi= ng a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000a941fc05c89d62bd-- From nobody Tue Aug 3 09:42: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 344203A298B for ; Tue, 3 Aug 2021 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 1ClJ1oH3I_HE for ; Tue, 3 Aug 2021 09:42:41 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 ADA6E3A2980 for ; Tue, 3 Aug 2021 09:42:41 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id x17so6594726wmc.5 for ; Tue, 03 Aug 2021 09:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1QNOCGUP0Z0IWNOLaPMUe+WWuta8HYDMgnRLRjxnDow=; b=QXjTTUdbsRO3whHBV2RdFKkg9P5jlGtfooiGwsSSzK9PBPeWoXnwSQyt19eJDHb+6m ieKH42BMXFkSrrwvy2A42d5L77JU2t8nGJxf3dWAoSWqMuUV0o6K3TJphP9/vowK/GeZ P8BLoPAcbsvsWoBU8M/ElbXFndusVxYYFkRqvNjdoXvIzuLHCJL89DO8JwoH9lfCKZVA CS/WdciiI7iNdu6cAbfzDfAiWVSRF2iPRrG9pEHKZyIfA8WtC7bf/c8rU6m3H7b+HwzG hZvGiulj3BUGVe0af1RCCzqA9XLqoZlzwA9ZHel0dOnKBr5yuoo2GjztEHDV/E8f1bUQ g6vA== 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=1QNOCGUP0Z0IWNOLaPMUe+WWuta8HYDMgnRLRjxnDow=; b=NbXl8A6HG6SvwCK4AuETvpjKgcebQB5iJgJmkPit0ePbzFui+qtZaFeMPD1i2d4ZSK Jssc1rTzdSZCmKX4AQ8sB3j2b7QCCye/SihgxRvzohiuTP6htvYMwz9Aq5h4U4Uh7bVT Sb8+h0QwmJuK5tpwh0mVDySJ30U9strV+l7vhXgcFGZ54+EkbDAV93uYuFIAPXbzx69F x+qfrI4Mt4GTGf4QZg2yfTNpBmC0SCy3cgjrkyxEWGcv/QHpPxiY0JcxW86w6whtTHUf xqyXefk7hnY2gpqsd0VRd2Bi/qOSrz6XCW5RRg9vRiolIqno2aCd4w0f0wsyYh8vdt4A KR4g== X-Gm-Message-State: AOAM533Z5Gd4b8inZ54wFO0YU+nm9vCivBCZdpcNzw6u009C4DNd7QuM Bb6SXiGg7IYZVrC06MHscVCEp72lbhbgeX1VihZuCq3n5L4= X-Google-Smtp-Source: ABdhPJzoxlgYTyx3Y18M33gYcwz4Gk4mLvnOhFDIRxLtV+Cr6OdYeVW4Vb3lsUZf8DgdPb5XSvu83bIVn/qyl8SCPwA= X-Received: by 2002:a1c:2784:: with SMTP id n126mr3620473wmn.32.1628008958255; Tue, 03 Aug 2021 09:42:38 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: From: Yuchung Cheng Date: Tue, 3 Aug 2021 09:42:00 -0700 Message-ID: To: Neal Cardwell Cc: Praveen Balasubramanian , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="000000000000a6d03b05c8aa5f6d" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 16:42:47 -0000 --000000000000a6d03b05c8aa5f6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng wrote: > > > On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > >> >> >> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian > 40microsoft.com@dmarc.ietf.org> wrote: >> >>> In experiments a few years ago on DC networks, values over L=3D8 result= ed >>> in a noticeable increase in packet drops and retransmissions (without >>> pacing). Windows TCP has been using L=3D8 for many years now. If we do = want >>> to specify a fallback L value for implementations that cannot pace, my >>> suggestion would be to use the value 8. >>> >>> >>> >>> Neal, are there cases where Linux is or can be deployed with infinite L >>> and no pacing? >>> >> >> Yes, "infinite L and no pacing" is the default behavior for Linux TCP, >> starting in 2013 for slow-start and then starting in 2015 for congestion >> avoidance. >> > To be more clear: both fq_pacing and TCP pacing have been disabled by > default in Linux upstream. We do not know how much Linux senders enable > them today besides the Google servers. > > Regarding L =3D 8, to avoid another round of why or why not. We could say > inf-L causes line-rate burst up to the stretched ACK degree so put a > comfortable L if you prefer, then mention implementation practice like > yours. At the end of the day it's ad-hoc (or "art") and subject to change= . > It might be sensible to cap at cwnd to disincentivize receivers / > middle-boxes bunching up 10 rounds of ACKs. > Sorry please ignore my previous message about the cwnd cap. It is completely unnecessary -- since with ack-clocking and appropriate counting, a correct sender would never release more than a cwnd-worth of data. I was imagining the multiple application-limited burst could let the receiver keep holding up ACKs, but that can never exceed a cwnd worth of data. > >> > >> Yuchung pasted the URLs for the exact Linux commits above, which are: >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi= t/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi= t/?id=3D9cd981dcf174d26805a032aefa791436da709bee >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi= t/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi= t/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi= t/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >> >> But I understand that not everyone is in a position to read GPL-licensed >> code. :-) >> >> best regards, >> neal >> >> >> >>> >>> >>> *From:* tcpm *On Behalf Of * Neal Cardwell >>> *Sent:* Monday, August 2, 2021 4:18 PM >>> *To:* Vidhi Goel >>> *Cc:* Extensions ; Mark Allman >>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC346= 5 >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel wrote: >>> >>> >>> >>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >>> >>> >>> > The fact is that Linux CC has long moved to infinite L since 2031, >>> >>> So, if our experience is with L=3D\infinity and it is demonstrably OK >>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>> submit that it makes more sense to leverage experience than it does >>> >>> to make things up. >>> >>> +1 >>> >>> >>> >>> Yes, I agree that would be a great approach to take. >>> >>> >>> >>> So, we are saying it is fine to ignore L completely and simply increase >>> cwnd by bytes_acked during slow start? And if this causes large bursts = to >>> be sent out (when an implementation doesn=E2=80=99t do pacing), that is= fine? >>> >>> >>> >>> Yes, I think that is the proposal on the table, and it sounds good to m= e. >>> >>> >>> >>> A rationale would be: >>> >>> >>> >>> (1) Implementations SHOULD pace (RFC 7661). >>> >>> >>> >>> (2) Implementations that don't pace will generally be causing large >>> bursts for many different reasons anyway (data and/or ACK aggregation i= n >>> the network or end hosts), restart from idle,...) so having a constant = L >>> does not provide enough protection from bursts to justify the cost in >>> reduced performance (in the form of slower slow-start). In support of t= his, >>> experience with this as the default behavior in Linux TCP over the >>> 2013-2021 period suggests this works well enough in practice. >>> >>> >>> >>> neal >>> >>> >>> >>> >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > --000000000000a6d03b05c8aa5f6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 6:12 PM Yuchun= g Cheng <ycheng@google.com> = wrote:


On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell = <ncardwell=3D40google.com@dmarc.ietf.org> wrote:


On M= on, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=3D40microsoft.com@dma= rc.ietf.org> wrote:

In experiments a few years ago on DC networks, value= s over L=3D8 resulted in a noticeable increase in packet drops and retransm= issions (without pacing). Windows TCP has been using L=3D8 for many years n= ow. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0

Neal, are there cases where Linux is or can be deplo= yed with infinite L and no pacing?


Yes, "infinite L and no pacing" is the default behavior f= or Linux TCP, starting in 2013 for slow-start and then starting in 2015 for= congestion avoidance.
To be more clear:= both fq_pacing and TCP pacing have been disabled by default in Linux upstr= eam. We do not know how much Linux senders enable them today besides the Go= ogle servers.

Regarding L =3D 8, to avoid another = round of why or why not. We could say inf-L causes line-rate burst up to th= e stretched ACK degree so put a comfortable L if you prefer, then mention i= mplementation practice like yours. At the end of the day it's ad-hoc (o= r "art") and subject to change. It might be sensible to cap at cw= nd to disincentivize receivers / middle-boxes bunching up 10 rounds of ACKs= .
Sorry please ignore my previous me= ssage about the cwnd cap. It is completely unnecessary -- since with ack-cl= ocking and appropriate counting, a correct sender would never release more = than a cwnd-worth of data. I was imagining the multiple application-limited= burst could let the receiver keep holding up ACKs, but that can never exce= ed a cwnd worth of data.
=C2=A0

=C2=A0
Yuchung pasted the URLs for the exact= Linux commits above, which are:


But I understand that not everyone is in a po= sition to read GPL-licensed code. :-)

best regards= ,
neal

=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <vidhi_goel@apple.com> wrote:

=C2=A0

Yes, I think that is the proposal on the table, and = it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).

=C2=A0

(2) Implementations that don't pace will general= ly be causing large bursts for many different reasons anyway (data and/or A= CK aggregation in the network or end hosts), restart from idle,...) so havi= ng a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000a6d03b05c8aa5f6d-- From nobody Tue Aug 3 20:19: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 D5B323A3F43 for ; Tue, 3 Aug 2021 20:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz5V7dOQvWMF for ; Tue, 3 Aug 2021 20:18:58 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D889B3A3F39 for ; Tue, 3 Aug 2021 20:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KQJIaMzGRvYUQ7QnrdqVmACtjKgedrF4OxVQ6URQu/Y=; b=c5rmXjJnGMYZfqFsUz2qymJDif rYLBWznCnd9XZTwAmxQm9P0hFxeysYgLKb9vRhhdnQsGoCAusv8c7l6jh0LjryUvO3ttOv6pDYfMn DbMKsPT4zGI17VdP784DM8iyDBjmsG6ZhhseMCjY84fHue5CW9Tj5WZCSMjnhjnS4T4QSdskjjCS1 yo/goUMXCL4CkM1zYpo/ws2Aj8YOcOmczWmDNUBMgMIRgADQMIf0rWCtd8XQ92DLwsPTw2fweDF/5 Nk5VjXp1oH2JA0ppxswJAJJa8T6KKOX3vZXqTiaf6ydsSk6C/IDOLzQ+0h4Sj8AgzVRLS1b0iWpP6 E6HbaJlw==; Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:54338 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mB7Qj-001qIl-Eg; Tue, 03 Aug 2021 23:18:58 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_3840A6AD-71BA-4128-A80E-504B238846A9" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Joseph Touch In-Reply-To: Date: Tue, 3 Aug 2021 20:18:52 -0700 Cc: "tcpm@ietf.org Extensions" Message-Id: References: To: Muthu Arul Mozhi Perumal X-Mailer: Apple Mail (2.3654.120.0.1.13) 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] Question on crypto algo usage for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 Aug 2021 03:19:03 -0000 --Apple-Mail=_3840A6AD-71BA-4128-A80E-504B238846A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I would post this to the security area WG for better feedback, given = it=E2=80=99s only transport in its use by TCP. My view is that this is not particularly unambiguous, as noted below. Joe > On Aug 2, 2021, at 6:06 AM, Muthu Arul Mozhi Perumal = wrote: >=20 > Hi, >=20 > Section 3.1.1 of RFC 5926 describes how to derive the traffic key of = desired length to be used for the MAC calculation, especially when the = KDF_alg produces fewer bits than the key length required for the = MAC_alg. >=20 > > The output of multiple PRF invocations is simply concatenated. For > the Traffic_Key, values of multiple PRF invocations are = concatenated > and truncated as needed to create a Traffic_Key of the desired > length. For instance, if one were using KDF_HMAC_SHA1, which uses = a > 160-bit internal PRF to generate 320 bits of data, one would = execute > the PRF twice, once with i=3D1 and once with i=3D2. The result = would be > the entire output of the first invocation concatenated with the > second invocation. For example, >=20 > Traffic_Key =3D > KDF_alg(Master_Key, 1 || Label || Context || Output_length) = || > KDF_alg(Master_Key, 2 || Label || Context || Output_length) >=20 > If the number of bits required is not an exact multiple of the = output > size of the PRF, then the output of the final invocation of the PRF > is truncated as necessary. > >=20 > The question I have is, what if the first invocation of the above PRF = itself produces more bits than the key length required by the MAC = calculation. Should the output of the first invocation be truncated? In that case, the first invocation of PRF is also the =E2=80=9Cfinal=E2=80= =9D invocation, as mentioned in the last paragraph, because you have = enough bits. So yes, then you truncate. > For e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and = KDF_HMAC_SHA1 as the KDF_alg, should the output of the foll. be = truncated to 128 bits (since it would produce a 160 bit output whereas = AES-128-CMAC requires a 128-bit key)? > KDF_alg(Master_Key, 1 || Label || Context || Output_length) Yes; I don=E2=80=99t understand why this seems unambiguous. >=20 > Regards, > Muthu > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_3840A6AD-71BA-4128-A80E-504B238846A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

I would post = this to the security area WG for better feedback, given it=E2=80=99s = only transport in its use by TCP.

My view is that this is not = particularly unambiguous, as noted below.

Joe

On = Aug 2, 2021, at 6:06 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

Hi,
=

Section = 3.1.1 of RFC 5926 describes how to derive the traffic key of desired = length to be used for the MAC calculation, especially when the KDF_alg = produces fewer bits than the key length required for the = MAC_alg.

<snip&= gt;
   The output of multiple PRF =
invocations is simply concatenated.  For
   the Traffic_Key, values of multiple PRF =
invocations are concatenated
   and truncated as needed to create a Traffic_Key =
of the desired
   =
length.  For instance, if one were using KDF_HMAC_SHA1, which uses =
a
   160-bit =
internal PRF to generate 320 bits of data, one would execute
   the PRF twice, once with i=3D1=
 and once with i=3D2.  The result would be
   the entire output of the =
first invocation concatenated with the
   second invocation.  For example,

  Traffic_Key =3D
    =
      KDF_alg(Master_Key, 1 || Label || Context || Output_length) =
||
          =
KDF_alg(Master_Key, 2 || Label || Context || Output_length)

   If the number of bits required is not an exact multiple of the =
output
   size of the =
PRF, then the output of the final invocation of the PRF
   is truncated as =
necessary.
</snip= >

The = question I have is, what if the first invocation of the above PRF itself = produces more bits than the key length required by the MAC calculation. = Should the output of the first invocation be truncated? =

In that = case, the first invocation of PRF is also the =E2=80=9Cfinal=E2=80=9D = invocation, as mentioned in the last paragraph, because you have enough = bits. So yes, then you truncate.

For = e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 = as the KDF_alg, should the output of the foll. be truncated to 128 bits = (since it would produce a 160 bit output whereas AES-128-CMAC requires a = 128-bit key)?
KDF_alg(M= aster_Key, 1 || Label || Context || Output_length)

Yes; I don=E2=80=99t understand why this seems = unambiguous.


Regards,<= /div>
Muthu
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_3840A6AD-71BA-4128-A80E-504B238846A9-- From nobody Tue Aug 3 21:38: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 D7BEF3A09DB for ; Tue, 3 Aug 2021 21:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 lfI3pVqikRO1 for ; Tue, 3 Aug 2021 21:38:38 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 257C83A09D8 for ; Tue, 3 Aug 2021 21:38:37 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id j1so1230562pjv.3 for ; Tue, 03 Aug 2021 21:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZIkp85ARvYRX5j9ScderQnB/wzDqsasMg1BM4IU41mU=; b=cdN8I2PrKGCHNFMBHMIMNRE68eAaTMDGBbJ9/Ffx/9CnVsYT0sxand3m7bzI2ozM/6 8LRFPkXo2N9w3mrXy5hmzxJMts+s/UzyYm2i+saU3/8uv7faT7lb9wnSNUBfkIWZqPxF 237ZLf1W8JZdsX2l8dtqK0/pSeorbDxHr1zQXQcC8JvjuIuRS0V0GdiHdrEie41+LUBH EccZgDMKROl+3eGo8si+2YARO8ERYVoeXmRzdR3+1fXNQE6Dn3/lL1We6p/zNZykBjnk gPXHBDQ+OeVxEVE/6TRbHcLUYEJMwlrZ1hdT7Bi1OLHLN5vI5q7WZDreSu1OlZ+4a5ED Y6Wg== 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=ZIkp85ARvYRX5j9ScderQnB/wzDqsasMg1BM4IU41mU=; b=Xxv/AG0ab+89mfH2BobFxyKjOnMGVQOOB1Us4Kr5oknwGPNZcVB6uO/nxKqTQxl4OJ Js2Gfdp+IVy+vChg+iojxmMQj23qtpH6M1tAQCEeeke5FoMQmDlnTEg2UyvFC6CZitkF TZMAL9NHD3RI1L7i/BuNpcM3vkRXPMqrxrBOAtuDrRqOh6tMbOj5536T3EMIinrLLgaN Hflgl2aQYF+sXp52hhW2XQWdEVHDDyAGPuJ73hrMzhj8MGQRrB8jTxv1FgTFREO3N9J7 bBiPU66YZNNXWSuhxzFp/G/NuedgsNKBFQ/0tHfy3DERQFCUefyE4IZZf7RSE4QK3wwD oviw== X-Gm-Message-State: AOAM53061iqxX684/Zf9H0ADvFVVrlme6He+z4YkICIRyD5HSBu9v/Xy Ups9haGSjWAxHKOgs28eV5CmNg5/5/i3eTTukzuuR/1nnf4= X-Google-Smtp-Source: ABdhPJzIgZ0oCr4UTzzM7XlJbvqq6Y/zF9gAwBPLPAvR2b9ne77jxFlIIvOBfRPxu8bzYsRyQjw7yXK1A8qaWjWhetg= X-Received: by 2002:a05:6a00:1713:b029:332:7eca:41a1 with SMTP id h19-20020a056a001713b02903327eca41a1mr25627415pfc.26.1628051916895; Tue, 03 Aug 2021 21:38:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muthu Arul Mozhi Perumal Date: Wed, 4 Aug 2021 10:08:25 +0530 Message-ID: To: Joseph Touch Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000002eb95105c8b460f0" Archived-At: Subject: Re: [tcpm] Question on crypto algo usage for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 Aug 2021 04:38:43 -0000 --0000000000002eb95105c8b460f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, Thanks for your response. I agree this follows logically, but wanted to check if anyone has a different opinion since it impacts interoperability. Perhaps, if we ever take up rfc5926bis, we could add a clarification note.. Regards, Muthu On Wed, Aug 4, 2021 at 8:48 AM Joseph Touch wrote: > Hi all, > > I would post this to the security area WG for better feedback, given it= =E2=80=99s > only transport in its use by TCP. > > My view is that this is not particularly unambiguous, as noted below. > > Joe > > On Aug 2, 2021, at 6:06 AM, Muthu Arul Mozhi Perumal > wrote: > > Hi, > > Section 3.1.1 of RFC 5926 describes how to derive the traffic key of > desired length to be used for the MAC calculation, especially when the > KDF_alg produces fewer bits than the key length required for the MAC_alg. > > > > The output of multiple PRF invocations is simply concatenated. For > > the Traffic_Key, values of multiple PRF invocations are concatenated > > and truncated as needed to create a Traffic_Key of the desired > > length. For instance, if one were using KDF_HMAC_SHA1, which uses a > > 160-bit internal PRF to generate 320 bits of data, one would execute > > the PRF twice, once with i=3D1 and once with i=3D2. The result would = be > > the entire output of the first invocation concatenated with the > > second invocation. For example, > > Traffic_Key =3D > > KDF_alg(Master_Key, 1 || Label || Context || Output_length) || > > KDF_alg(Master_Key, 2 || Label || Context || Output_length) > > If the number of bits required is not an exact multiple of the output > > size of the PRF, then the output of the final invocation of the PRF > > is truncated as necessary. > > > > The question I have is, what if the first invocation of the above PRF > itself produces more bits than the key length required by the MAC > calculation. Should the output of the first invocation be truncated? > > > In that case, the first invocation of PRF is also the =E2=80=9Cfinal=E2= =80=9D invocation, > as mentioned in the last paragraph, because you have enough bits. So yes, > then you truncate. > > For e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and > KDF_HMAC_SHA1 as the KDF_alg, should the output of the foll. be truncated > to 128 bits (since it would produce a 160 bit output whereas AES-128-CMAC > requires a 128-bit key)? > KDF_alg(Master_Key, 1 || Label || Context || Output_length) > > > Yes; I don=E2=80=99t understand why this seems unambiguous. > > > Regards, > Muthu > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --0000000000002eb95105c8b460f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for your response. I agree th= is follows logically, but wanted to check if anyone has a different opinion= since it impacts interoperability. Perhaps, if we ever take up rfc5926bis,= we could add a clarification note..

Regards,
Muthu

On Wed, Aug 4, 2= 021 at 8:48 AM Joseph Touch <tou= ch@strayalpha.com> wrote:
Hi all,

=
I would post this to the security area WG for better feedback, g= iven it=E2=80=99s only transport in its use by TCP.

My view is that this is not particularly unambiguous, as noted below.

Joe

On Aug 2, 2021, at 6:06 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote= :

Hi,

Section 3.1.1 of RFC 5926 describes ho= w to derive the traffic key of desired length to be used for the MAC calcul= ation, especially when the KDF_alg produces fewer bits than the key length = required=C2=A0for the MAC_alg.

<snip>
   The output o=
f multiple PRF invocations is simply concatenated.  For
   =
the Traffic_Key, values of multiple PRF invocations are concatenated
<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page"> and truncated as needed to create a Traffic_Key of the desired= 
   length.  For instance, if one were using KDF_HMAC_SHA1,=
 which uses a
   160-bit internal PRF to generate 320 bits =
of data, one would execute
   the PRF twice, once with i=3D=
1 and once with i=3D2.  The result would be
   the entire o=
utput of the first invocation concatenated with the
   seco=
nd invocation.  For example,

  Traffic_Key =3D
          KDF_alg(Master_Key, 1 || Label =
|| Context || Output_length) ||
          KDF_alg(Master_Ke=
y, 2 || Label || Context || Output_length)

   If the number of bits required is not an exact multiple of the output
   size of the PRF, then the output of the final invocation o=
f the PRF
   is truncated as necessary.
</snip>=

The question I have is, what if the first invocation of the above PRF= itself produces more bits than the key length required by the MAC calculat= ion. Should the output of the first invocation be truncated?

In that case, the first invocation of = PRF is also the =E2=80=9Cfinal=E2=80=9D invocation, as mentioned in the las= t paragraph, because you have enough bits. So yes, then you truncate.
=
For e.g. if one were to use = AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 as the KDF_alg, should the= output of the foll. be truncated to 128 bits (since it would produce a 160= bit output whereas AES-128-CMAC requires a 128-bit key)?
KDF_alg(Master_= Key, 1 || Label || Context || Output_length)

Yes; I don=E2=80=99t understand why this seems unam= biguous.

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

--0000000000002eb95105c8b460f0-- From nobody Fri Aug 6 12:54:41 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 782823A13D9 for ; Fri, 6 Aug 2021 12:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N59LkXbTnK30 for ; Fri, 6 Aug 2021 12:54:35 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 8FBAC3A13CA for ; Fri, 6 Aug 2021 12:54:31 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id m12so12415285wru.12 for ; Fri, 06 Aug 2021 12:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=06Pon2QBCWSot8PslbNQItE0UN34qDLlNZyELGYlxpE=; b=dbZkDDBvX9BCtbs3ia2gUTGJjrToPC0yPLnklVS4GsWZlEmolO0bUkVz/lkAyPr/8d 4ZuDHUxNZZwHgWOV4mKOOjtuWwfOCsmVHNNWeAOzlYAbTtIjYeSHFKiJcoqQfhLgbGjR 8i8VaFX4jst90bJ/tcapGtX4eJzDcO4Dq3z48Zti22FEjnPH51QKis0/WnuqpTv0Yyav o912u2bmAO5yEDEPcxfVTpVkdQvEKw6Vwq7tOdvi6o1MBL0jU2twtJ3o7yc06Z5K81hw EP32u0QKHksKOdtooMSJPyosFFArW5HEfffPdrNrY9wZmZYTBUU5LcjyHGSkU6womZdu GpfA== 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=06Pon2QBCWSot8PslbNQItE0UN34qDLlNZyELGYlxpE=; b=M5u6mR6kaqipR3D3rHZvETxGZyhA7N5gf0KyzJd76WkstsXAyTf+4XbYC0TIzmymyW RtfTcULBFheQB+Z/4GwGoZVlbvniG2w2iUCP44f7VWcg6Kd9UItDmbpjNSZrC+DBhZTy DoGFFr/KJzYWQNFCJnIb8TQGJnFy7Lr6rJ5gCnnG0LV6w5rISq5UviRgD7Hnn1x+V0ip m+0dyjc2Cz6dC5IAVUnCYTSoIRSxKSkfs7adDWHsWCelFSwYqe5vwAAIraa9W2wPz1h3 7oOo1vKx+jnqpmP1BjTRSjHIEU6SAddH1gT2/g5faQo1DbB27gVtl7E0NH4cmlFEvm9E 6jgg== X-Gm-Message-State: AOAM5323J+vcyYMw+3oKENVW0YvbrshYJ/9vUIa//Nsj4lJCvDV5equa jpOKeoCv3KLRPmDQJZZq1a6z/jIh+uCZ828EAsv1qUfstw467A== X-Google-Smtp-Source: ABdhPJyibC4J8V95k4kSHivQT0QCHKyGrdkdQqC5JqgiT+t3wCe0mw869NPxrMkIeRfqOoFc0eDNkbMlg6ohMpmmsV0= X-Received: by 2002:adf:e107:: with SMTP id t7mr12529031wrz.165.1628279668749; Fri, 06 Aug 2021 12:54:28 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> In-Reply-To: From: Yuchung Cheng Date: Fri, 6 Aug 2021 12:53:51 -0700 Message-ID: To: Neal Cardwell Cc: Praveen Balasubramanian , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="00000000000040d5a605c8e9671c" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 06 Aug 2021 19:54:40 -0000 --00000000000040d5a605c8e9671c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi WG I have been wondering if we (=3D IETF) should just update RFC5681 directly, instead of another RFC3465-bis with experimental status. Appropriate byte counting is essential but the RFC5681 of L=3D1 is detrimental. There are far more people who read RFC5681 to implement the new stack instead of RFC3465. So we should fold the experimental RFC3465 updates into RFC5681 directly, and obsolete RFC3465. This is orthogonal to the final value of L :-) On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng wrote: > > > On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng wrote: > >> >> >> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell > 40google.com@dmarc.ietf.org> wrote: >> >>> >>> >>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >> 40microsoft.com@dmarc.ietf.org> wrote: >>> >>>> In experiments a few years ago on DC networks, values over L=3D8 resul= ted >>>> in a noticeable increase in packet drops and retransmissions (without >>>> pacing). Windows TCP has been using L=3D8 for many years now. If we do= want >>>> to specify a fallback L value for implementations that cannot pace, my >>>> suggestion would be to use the value 8. >>>> >>>> >>>> >>>> Neal, are there cases where Linux is or can be deployed with infinite = L >>>> and no pacing? >>>> >>> >>> Yes, "infinite L and no pacing" is the default behavior for Linux TCP, >>> starting in 2013 for slow-start and then starting in 2015 for congestio= n >>> avoidance. >>> >> To be more clear: both fq_pacing and TCP pacing have been disabled by >> default in Linux upstream. We do not know how much Linux senders enable >> them today besides the Google servers. >> >> Regarding L =3D 8, to avoid another round of why or why not. We could sa= y >> inf-L causes line-rate burst up to the stretched ACK degree so put a >> comfortable L if you prefer, then mention implementation practice like >> yours. At the end of the day it's ad-hoc (or "art") and subject to chang= e. >> It might be sensible to cap at cwnd to disincentivize receivers / >> middle-boxes bunching up 10 rounds of ACKs. >> > Sorry please ignore my previous message about the cwnd cap. It is > completely unnecessary -- since with ack-clocking and appropriate countin= g, > a correct sender would never release more than a cwnd-worth of data. I wa= s > imagining the multiple application-limited burst could let the receiver > keep holding up ACKs, but that can never exceed a cwnd worth of data. > > >> >>> >> >>> Yuchung pasted the URLs for the exact Linux commits above, which are: >>> >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>> >>> But I understand that not everyone is in a position to read GPL-license= d >>> code. :-) >>> >>> best regards, >>> neal >>> >>> >>> >>>> >>>> >>>> *From:* tcpm *On Behalf Of * Neal Cardwell >>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>> *To:* Vidhi Goel >>>> *Cc:* Extensions ; Mark Allman >>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel wrote= : >>>> >>>> >>>> >>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >>>> >>>> >>>> > The fact is that Linux CC has long moved to infinite L since 2031, >>>> >>>> So, if our experience is with L=3D\infinity and it is demonstrably OK >>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>>> submit that it makes more sense to leverage experience than it does >>>> >>>> to make things up. >>>> >>>> +1 >>>> >>>> >>>> >>>> Yes, I agree that would be a great approach to take. >>>> >>>> >>>> >>>> So, we are saying it is fine to ignore L completely and simply increas= e >>>> cwnd by bytes_acked during slow start? And if this causes large bursts= to >>>> be sent out (when an implementation doesn=E2=80=99t do pacing), that i= s fine? >>>> >>>> >>>> >>>> Yes, I think that is the proposal on the table, and it sounds good to >>>> me. >>>> >>>> >>>> >>>> A rationale would be: >>>> >>>> >>>> >>>> (1) Implementations SHOULD pace (RFC 7661). >>>> >>>> >>>> >>>> (2) Implementations that don't pace will generally be causing large >>>> bursts for many different reasons anyway (data and/or ACK aggregation = in >>>> the network or end hosts), restart from idle,...) so having a constant= L >>>> does not provide enough protection from bursts to justify the cost in >>>> reduced performance (in the form of slower slow-start). In support of = this, >>>> experience with this as the default behavior in Linux TCP over the >>>> 2013-2021 period suggests this works well enough in practice. >>>> >>>> >>>> >>>> neal >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> --00000000000040d5a605c8e9671c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG

I=C2=A0have=C2=A0been wonder= ing if we (=3D IETF) should just update RFC5681 directly, instead of anothe= r RFC3465-bis with experimental status.

Appropriat= e byte counting is essential but the RFC5681 of L=3D1 is detrimental. There= are far more people who read RFC5681 to implement the new stack instead of= RFC3465. So we should fold the experimental RFC3465 updates into RFC5681 d= irectly, and obsolete RFC3465.

This is ortho= gonal=C2=A0to the final value of L :-)


<= div>

On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell <ncardwell= =3D40googl= e.com@dmarc.ietf.org> wrote:


=C2=A0
Yuchung pasted the URLs for the exact= Linux commits above, which are:


But I understand that not everyone is in a po= sition to read GPL-licensed code. :-)

best regards= ,
neal

=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <vidhi_goel@apple.com> wrote:

=C2=A0

Yes, I think that is the proposal on the table, and = it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).

=C2=A0

(2) Implementations that don't pace will general= ly be causing large bursts for many different reasons anyway (data and/or A= CK aggregation in the network or end hosts), restart from idle,...) so havi= ng a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000040d5a605c8e9671c-- From nobody Fri Aug 6 12:59: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 D8F363A1415 for ; Fri, 6 Aug 2021 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzfYElxNUqOY for ; Fri, 6 Aug 2021 12:59:43 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 667313A1413 for ; Fri, 6 Aug 2021 12:59:43 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 176JbZca016919; Fri, 6 Aug 2021 12:59:40 -0700 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=ytFHMdr0T1kDnIa5tPWctaadBsRkOr8dpn4uf6wnTAI=; b=cNDrDCtmuWJVLaiC8F2kRptp50vYNg849sMsLAweWZcTV+KdR0QFKKxCRC4jyWY1y/hK oohCLz8IKIoaj+GKqn9MTWQ3pJsFcDiLBAbtGz+HKUmlB80O80pbmC32tKQKJLEo5nmm lbrekSgkPPpFHkWAkhEhnEIaHvJndHBLCcqIq5O4jVS6HUKg8Ayv783TNikjKkX3x1AA UcxV+Cjt8yRuin0c8PXstNKsB51IM2cXy/k9UPLXMnpczIdw0QSjzGjRYcK3SJePbVUQ GbPMyFDl3dQ8zIHpec0zvGC5PECRxLeZ9d9zj8e20kLYrC5m5KfLAMwF5smxQG6DZ0zG AQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3a55gwrhke-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 06 Aug 2021 12:59:40 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXF004J1OVF3R30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 06 Aug 2021 12:59:39 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QXF00Q00OSAKR00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 06 Aug 2021 12:59:39 -0700 (PDT) X-Va-A: X-Va-T-CD: 637c60740750869fdac3fa3bd3c9b6e8 X-Va-E-CD: 0356cfd288405c7383fa735d89592edc X-Va-R-CD: 776b594e15c7bc14f32f514fb67ec3c1 X-Va-CD: 0 X-Va-ID: a5c29d9b-84ef-4a68-8735-546473599155 X-V-A: X-V-T-CD: 637c60740750869fdac3fa3bd3c9b6e8 X-V-E-CD: 0356cfd288405c7383fa735d89592edc X-V-R-CD: 776b594e15c7bc14f32f514fb67ec3c1 X-V-CD: 0 X-V-ID: 2cf2987e-4b84-40d5-ad67-2926c7b0896f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-06_06:2021-08-06, 2021-08-06 signatures=0 Received: from smtpclient.apple (unknown [17.11.36.131]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXF00S2LOVERA00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 06 Aug 2021 12:59:39 -0700 (PDT) From: Vidhi Goel Message-id: <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_149BCDAC-FDEB-4935-9700-63929DFAB64D"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Fri, 06 Aug 2021 12:59:38 -0700 In-reply-to: Cc: Neal Cardwell , Praveen Balasubramanian , "tcpm@ietf.org" , "mallman@icir.org" To: Yuchung Cheng References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-06_06:2021-08-06, 2021-08-06 signatures=0 Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 06 Aug 2021 19:59:48 -0000 --Apple-Mail=_149BCDAC-FDEB-4935-9700-63929DFAB64D Content-Type: multipart/alternative; boundary="Apple-Mail=_5DAAEBED-56DC-42DB-B5D3-385698C11694" --Apple-Mail=_5DAAEBED-56DC-42DB-B5D3-385698C11694 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Yuchung=E2=80=99s suggestion for all the reasons he = provided. And its better to have it at one place. Vidhi > On Aug 6, 2021, at 12:53 PM, Yuchung Cheng = wrote: >=20 > Hi WG >=20 > I have been wondering if we (=3D IETF) should just update RFC5681 = directly, instead of another RFC3465-bis with experimental status. >=20 > Appropriate byte counting is essential but the RFC5681 of L=3D1 is = detrimental. There are far more people who read RFC5681 to implement the = new stack instead of RFC3465. So we should fold the experimental RFC3465 = updates into RFC5681 directly, and obsolete RFC3465. >=20 > This is orthogonal to the final value of L :-) >=20 >=20 >=20 >=20 > On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng > wrote: >=20 >=20 > On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng > wrote: >=20 >=20 > On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell = > wrote: >=20 >=20 > On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian = > wrote: > In experiments a few years ago on DC networks, values over L=3D8 = resulted in a noticeable increase in packet drops and retransmissions = (without pacing). Windows TCP has been using L=3D8 for many years now. = If we do want to specify a fallback L value for implementations that = cannot pace, my suggestion would be to use the value 8. >=20 > =20 >=20 > Neal, are there cases where Linux is or can be deployed with infinite = L and no pacing? >=20 >=20 > Yes, "infinite L and no pacing" is the default behavior for Linux TCP, = starting in 2013 for slow-start and then starting in 2015 for congestion = avoidance. > To be more clear: both fq_pacing and TCP pacing have been disabled by = default in Linux upstream. We do not know how much Linux senders enable = them today besides the Google servers. >=20 > Regarding L =3D 8, to avoid another round of why or why not. We could = say inf-L causes line-rate burst up to the stretched ACK degree so put a = comfortable L if you prefer, then mention implementation practice like = yours. At the end of the day it's ad-hoc (or "art") and subject to = change. It might be sensible to cap at cwnd to disincentivize receivers = / middle-boxes bunching up 10 rounds of ACKs. > Sorry please ignore my previous message about the cwnd cap. It is = completely unnecessary -- since with ack-clocking and appropriate = counting, a correct sender would never release more than a cwnd-worth of = data. I was imagining the multiple application-limited burst could let = the receiver keep holding up ACKs, but that can never exceed a cwnd = worth of data. > =20 >=20 > =20 > Yuchung pasted the URLs for the exact Linux commits above, which are: >=20 > = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 = > = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3D9cd981dcf174d26805a032aefa791436da709bee = > = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f = > = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3D814d488c61260521b1b3cc97063700a5a6667c8f = > = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 = >=20 > But I understand that not everyone is in a position to read = GPL-licensed code. :-) >=20 > best regards, > neal >=20 > =20 > =20 >=20 > From: tcpm > On = Behalf Of Neal Cardwell > Sent: Monday, August 2, 2021 4:18 PM > To: Vidhi Goel > > Cc: Extensions >; Mark Allman = > > Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC3465 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel > wrote: >=20 > =20 >=20 > On Mon, Aug 2, 2021 at 3:37 PM Mark Allman > wrote: >=20 >=20 > > The fact is that Linux CC has long moved to infinite L since 2031, >=20 > So, if our experience is with L=3D\infinity and it is demonstrably OK > why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would > submit that it makes more sense to leverage experience than it does=20 >=20 > to make things up. >=20 > +1 >=20 > =20 >=20 > Yes, I agree that would be a great approach to take. >=20 > =20 >=20 > So, we are saying it is fine to ignore L completely and simply = increase cwnd by bytes_acked during slow start? And if this causes large = bursts to be sent out (when an implementation doesn=E2=80=99t do = pacing), that is fine?=20 >=20 > =20 >=20 > Yes, I think that is the proposal on the table, and it sounds good to = me. >=20 > =20 >=20 > A rationale would be: >=20 > =20 >=20 > (1) Implementations SHOULD pace (RFC 7661). >=20 > =20 >=20 > (2) Implementations that don't pace will generally be causing large = bursts for many different reasons anyway (data and/or ACK aggregation in = the network or end hosts), restart from idle,...) so having a constant L = does not provide enough protection from bursts to justify the cost in = reduced performance (in the form of slower slow-start). In support of = this, experience with this as the default behavior in Linux TCP over the = 2013-2021 period suggests this works well enough in practice. >=20 > =20 >=20 > neal >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_5DAAEBED-56DC-42DB-B5D3-385698C11694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Yuchung=E2=80=99s suggestion for all the reasons he provided. = And its better to have it at one place.

Vidhi

On Aug = 6, 2021, at 12:53 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:

Hi WG

I have been wondering if we (=3D IETF) should just = update RFC5681 directly, instead of another RFC3465-bis with = experimental status.

Appropriate byte counting is essential but the RFC5681 of L=3D1= is detrimental. There are far more people who read RFC5681 to implement = the new stack instead of RFC3465. So we should fold the experimental = RFC3465 updates into RFC5681 directly, and obsolete = RFC3465.

This is orthogonal to the final value of L :-)




On Tue, Aug = 3, 2021 at 9:42 AM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug = 2, 2021 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug = 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug = 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on = DC networks, values over L=3D8 resulted in a noticeable increase in = packet drops and retransmissions (without pacing). Windows TCP has been = using L=3D8 for many years now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to = use the value 8.

 

Neal, are there cases where Linux is or can be = deployed with infinite L and no pacing?


Yes, "infinite L and no = pacing" is the default behavior for Linux TCP, starting in 2013 for = slow-start and then starting in 2015 for congestion = avoidance.
To be more = clear: both fq_pacing and TCP pacing have been disabled by default in = Linux upstream. We do not know how much Linux senders enable them today = besides the Google servers.

Regarding L =3D 8, to avoid another round of why or why not. = We could say inf-L causes line-rate burst up to the stretched ACK degree = so put a comfortable L if you prefer, then mention implementation = practice like yours. At the end of the day it's ad-hoc (or "art") and = subject to change. It might be sensible to cap at cwnd to disincentivize = receivers / middle-boxes bunching up 10 rounds of ACKs.
Sorry please = ignore my previous message about the cwnd cap. It is completely = unnecessary -- since with ack-clocking and appropriate counting, a = correct sender would never release more than a cwnd-worth of data. I was = imagining the multiple application-limited burst could let the receiver = keep holding up ACKs, but that can never exceed a cwnd worth of = data.
 

 
Yuchung = pasted the URLs for the exact Linux commits above, which are:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D9cd981dcf174d26805a032aefa791436da709bee
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930
<= div class=3D"">
But I understand = that not everyone is in a position to read GPL-licensed code. = :-)

best = regards,
neal

 

 

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t = implement RFC3465

 

 

 

On Mon, Aug 2, 2021 at 7:02 PM = Vidhi Goel <vidhi_goel@apple.com> wrote:

 

On Mon, Aug 2, 2021 at 3:37 PM = Mark Allman <mallman@icir.org> wrote:


> The fact is that Linux CC has long moved to infinite L since = 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?  I = would
submit that it makes more sense to leverage experience than it = does 

to make things up.

+1

 

Yes, I agree that would be a = great approach to take.

 

So, we are saying it is fine to ignore L = completely and simply increase cwnd by bytes_acked during slow start? = And if this causes large bursts to be sent out (when an implementation = doesn=E2=80=99t do pacing), that is fine? 

 

Yes, I think that is the proposal = on the table, and it sounds good to me.

 

A rationale would be:

 

(1) Implementations SHOULD pace = (RFC 7661).

 

(2) Implementations that don't = pace will generally be causing large bursts for many different reasons = anyway (data and/or ACK aggregation in the network or end hosts), = restart from idle,...) so having a constant L does not provide enough protection from bursts to justify the cost in reduced = performance (in the form of slower slow-start). In support of this, = experience with this as the default behavior in Linux TCP over the  = 2013-2021 period suggests this works well enough in practice.

 

neal

 

 

_______________________________________________
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=_5DAAEBED-56DC-42DB-B5D3-385698C11694-- --Apple-Mail=_149BCDAC-FDEB-4935-9700-63929DFAB64D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgwNjE5 NTkzOFowLwYJKoZIhvcNAQkEMSIEICb2WztVaDmuG3kW8nB+VIFUgY9CsOq5TUHGmIiQHQjvMIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAHsrya459u8coFnQIiKWMHszGu/ZBKgqNt960MnvJZItDbLHKOEw2N9E qPu0j00BnkplN33TvjslMBh5QPPcJC1aWt6Ev319QNQ/9LP7Q8QZY4YgooD2VhN7vpzNBDAt7LAb Zj2V4+q46LU9iKa1Pk9zkn/nyzET8rZYzjZTJSSdKsQK66ICjMtg58LGVPzeQl3KILziAW4DMZkj utsSa3eywCoB7Ab/UBYhLN5wM9UYkes293pR/zCRPFfq1gY9TODgNAFZyxlcrl/6ymcFHud0e6AC sKv75eIztOrb9fwgsgWfKr6pYImHNPAwB9vzT/pUqfotN56515+PLgueoI0AAAAAAAA= --Apple-Mail=_149BCDAC-FDEB-4935-9700-63929DFAB64D-- From nobody Sat Aug 7 07:57: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 F07943A3D43 for ; Sat, 7 Aug 2021 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 UA1CO496GEJD for ; Sat, 7 Aug 2021 07:57:29 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 10E0B3A3D3E for ; Sat, 7 Aug 2021 07:57:28 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id x144so7204413vsx.3 for ; Sat, 07 Aug 2021 07:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4U+07tvSqFRjDMHW/QCcftxWaDY7WVV4AYpOhopmjfQ=; b=pUP5BciLu93BTtfqbj770GAlCyZ/Rd8Fhw7x04ZrIWnZajPTcX3NYcmvCEPKGafPO9 IiUKWM/0ZdR3eJgpvccjhwJDpcWyLibLa41v1Sm5fDxsCsg0HeNS99Dnpg5pYfQhj+RG YQNMORqHC5F3bOkzdEUuLdjpVkexAssFKUrdMCTLSHgB8mh4DcQFGXoqvSi49nrPe9vy uZ1MfQVwD4y3UhYTvmOp/jlb7PgBz8Kty0akmq+lNc852RL5ZLj+7wsuoTRivHbwTSyO r9Z2q7nBdZqiwn5jpAZ1qKtQ9VMW5TImFyud1aTHgM8t1/eCduEFxiALhYCNJXqgBztx TnLA== 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=4U+07tvSqFRjDMHW/QCcftxWaDY7WVV4AYpOhopmjfQ=; b=XxHz+WoBn+gsZGovHPwtatsCNFwSdfPsIfo3Q0GMFotbE9sgjpTwEGhq5NQ6yy4/JC RGwffonBVVNa9asbosGlHXDQ45J4pF5yMtILBhhqnCdbPgf6oUpMdQ3UvB646ejNDjG7 As65pZbysv9M3jHaHO5qpHoAj8qaRxLkecTxaHdqnrk0l0Nf+l+gwbz4pczmNsGCB4MO lPdGB3RobfoyjSiVc5/dU3hJc34VpJ5uN6liIxFZWS4Hl/qQik91N34c/RlmxmhGeSHu JDDb60KIBuc4fJQQrXlVwXCUepjY4Kt7pV5kt6m4SKQoPkFqpaqsq0pBqO8NU7dF8qkq bggw== X-Gm-Message-State: AOAM533yxpxZO8TFrYQf25znxdQuUhcB/CBFMhaTu4Rreja4KZ0+AKeM Gbmb4SKr4wAixg2ZZfu5RIu2E6/BcZuBVr9LkouEPQ== X-Google-Smtp-Source: ABdhPJylLS1LqLYAOAMCf0vcc9EwNjkx5c8oWt3RLivXgFtyzcxk9usEsSwc8Ejw6kmLm+rRysqeVBCh4auZBjAQL5g= X-Received: by 2002:a67:2442:: with SMTP id k63mr12526286vsk.16.1628348247169; Sat, 07 Aug 2021 07:57:27 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> In-Reply-To: <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> From: Neal Cardwell Date: Sat, 7 Aug 2021 10:57:10 -0400 Message-ID: To: Vidhi Goel Cc: Yuchung Cheng , Praveen Balasubramanian , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="000000000000d84e6c05c8f95e9b" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 07 Aug 2021 14:57:34 -0000 --000000000000d84e6c05c8f95e9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also agree with Yuchung=E2=80=99s suggestion, for all of the reasons he p= rovided. best, neal On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel wrote: > I agree with Yuchung=E2=80=99s suggestion for all the reasons he provided= . And its > better to have it at one place. > > Vidhi > > On Aug 6, 2021, at 12:53 PM, Yuchung Cheng < > ycheng=3D40google.com@dmarc.ietf.org> wrote: > > Hi WG > > I have been wondering if we (=3D IETF) should just update RFC5681 directl= y, > instead of another RFC3465-bis with experimental status. > > Appropriate byte counting is essential but the RFC5681 of L=3D1 is > detrimental. There are far more people who read RFC5681 to implement the > new stack instead of RFC3465. So we should fold the experimental RFC3465 > updates into RFC5681 directly, and obsolete RFC3465. > > This is orthogonal to the final value of L :-) > > > > > On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng wrote: > >> >> >> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng wrote: >> >>> >>> >>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell >> 40google.com@dmarc.ietf.org> wrote: >>> >>>> >>>> >>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >>> 40microsoft.com@dmarc.ietf.org> wrote: >>>> >>>>> In experiments a few years ago on DC networks, values over L=3D8 >>>>> resulted in a noticeable increase in packet drops and retransmissions >>>>> (without pacing). Windows TCP has been using L=3D8 for many years now= . If we >>>>> do want to specify a fallback L value for implementations that cannot= pace, >>>>> my suggestion would be to use the value 8. >>>>> >>>>> >>>>> >>>>> Neal, are there cases where Linux is or can be deployed with infinite >>>>> L and no pacing? >>>>> >>>> >>>> Yes, "infinite L and no pacing" is the default behavior for Linux TCP, >>>> starting in 2013 for slow-start and then starting in 2015 for congesti= on >>>> avoidance. >>>> >>> To be more clear: both fq_pacing and TCP pacing have been disabled by >>> default in Linux upstream. We do not know how much Linux senders enable >>> them today besides the Google servers. >>> >>> Regarding L =3D 8, to avoid another round of why or why not. We could s= ay >>> inf-L causes line-rate burst up to the stretched ACK degree so put a >>> comfortable L if you prefer, then mention implementation practice like >>> yours. At the end of the day it's ad-hoc (or "art") and subject to chan= ge. >>> It might be sensible to cap at cwnd to disincentivize receivers / >>> middle-boxes bunching up 10 rounds of ACKs. >>> >> Sorry please ignore my previous message about the cwnd cap. It is >> completely unnecessary -- since with ack-clocking and appropriate counti= ng, >> a correct sender would never release more than a cwnd-worth of data. I w= as >> imagining the multiple application-limited burst could let the receiver >> keep holding up ACKs, but that can never exceed a cwnd worth of data. >> >> >>> >>>> >>> >>>> Yuchung pasted the URLs for the exact Linux commits above, which are: >>>> >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com= mit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com= mit/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com= mit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com= mit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com= mit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>>> >>>> But I understand that not everyone is in a position to read >>>> GPL-licensed code. :-) >>>> >>>> best regards, >>>> neal >>>> >>>> >>>> >>>>> >>>>> >>>>> *From:* tcpm *On Behalf Of * Neal Cardwell >>>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>>> *To:* Vidhi Goel >>>>> *Cc:* Extensions ; Mark Allman >>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC3= 465 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >>>>> >>>>> >>>>> > The fact is that Linux CC has long moved to infinite L since 2031, >>>>> >>>>> So, if our experience is with L=3D\infinity and it is demonstrably OK >>>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>>>> submit that it makes more sense to leverage experience than it does >>>>> >>>>> to make things up. >>>>> >>>>> +1 >>>>> >>>>> >>>>> >>>>> Yes, I agree that would be a great approach to take. >>>>> >>>>> >>>>> >>>>> So, we are saying it is fine to ignore L completely and simply >>>>> increase cwnd by bytes_acked during slow start? And if this causes la= rge >>>>> bursts to be sent out (when an implementation doesn=E2=80=99t do paci= ng), that is >>>>> fine? >>>>> >>>>> >>>>> >>>>> Yes, I think that is the proposal on the table, and it sounds good to >>>>> me. >>>>> >>>>> >>>>> >>>>> A rationale would be: >>>>> >>>>> >>>>> >>>>> (1) Implementations SHOULD pace (RFC 7661). >>>>> >>>>> >>>>> >>>>> (2) Implementations that don't pace will generally be causing large >>>>> bursts for many different reasons anyway (data and/or ACK aggregation= in >>>>> the network or end hosts), restart from idle,...) so having a constan= t L >>>>> does not provide enough protection from bursts to justify the cost in >>>>> reduced performance (in the form of slower slow-start). In support of= this, >>>>> experience with this as the default behavior in Linux TCP over the >>>>> 2013-2021 period suggests this works well enough in practice. >>>>> >>>>> >>>>> >>>>> neal >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 > > > --000000000000d84e6c05c8f95e9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also agree with Yuchung=E2=80=99s suggestion, for all of= the reasons he provided.

best,
neal
=


On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel <vidhi_goel=3D= 40apple.com@dmarc.ietf.org> wrote:
I agree with Yuchung=E2=80=99s sugge= stion for all the reasons he provided. And its better to have it at one pla= ce.

Vidhi


Hi WG

I=C2=A0have=C2=A0been wondering if we (=3D IETF) should just update R= FC5681 directly, instead of another RFC3465-bis with experimental status.

Appropriate byte counting is essential but the RFC5= 681 of L=3D1 is detrimental. There are far more people who read RFC5681 to = implement the new stack instead of RFC3465. So we should fold the experimen= tal RFC3465 updates into RFC5681 directly, and obsolete RFC3465.

This is orthogonal=C2=A0to the final value of L :-)




On Tue, Aug 3, 2021 at 9:42= AM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug 2, 202= 1 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:

On Mon, = Aug 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org&= gt; wrote:


On Mon, Aug 2, 2021 at 8:46 PM Praveen Bal= asubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, = values over L=3D8 resulted in a noticeable increase in packet drops and ret= ransmissions (without pacing). Windows TCP has been using L=3D8 for many ye= ars now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0=

Neal, are there cases where Linux is or can be d= eployed with infinite L and no pacing?

Yes, "infinite L and no pacing" is the default behavi= or for Linux TCP, starting in 2013 for slow-start and then starting in 2015= for congestion avoidance.
To be more cl= ear: both fq_pacing and TCP pacing have been disabled by default in Linux u= pstream. We do not know how much Linux senders enable them today besides th= e Google servers.

Regarding L =3D 8, to avoid anot= her round of why or why not. We could say inf-L causes line-rate burst up t= o the stretched ACK degree so put a comfortable L if you prefer, then menti= on implementation practice like yours. At the end of the day it's ad-ho= c (or "art") and subject to change. It might be sensible to cap a= t cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of = ACKs.
Sorry please ignore my previou= s message about the cwnd cap. It is completely unnecessary -- since with ac= k-clocking and appropriate counting, a correct sender would never release m= ore than a cwnd-worth of data. I was imagining the multiple application-lim= ited burst could let the receiver keep holding up ACKs, but that can never = exceed a cwnd worth of data.
=C2=A0
=

=C2= =A0
Yuchung pasted the URLs for the= exact Linux commits above, which are:


But I understand that not everyone is i= n a position to read GPL-licensed code. :-)

best r= egards,
neal

=C2=A0

=C2=A0

= From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <<= a href=3D"mailto:vidhi_goel@apple.com" target=3D"_blank">vidhi_goel@apple.c= om> wrote:

=C2=A0

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <= mallman@icir.org&= gt; wrote:


> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0

to make things up.<= /u>

+1

=C2=A0

Yes, I agree that would be a great approach to = take.

=C2=A0

So, we are saying it is fine to ignore L compl= etely and simply increase cwnd by bytes_acked during slow start? And if thi= s causes large bursts to be sent out (when an implementation doesn=E2=80=99= t do pacing), that is fine?=C2=A0

=C2=A0

Yes, I think that is the proposal on the table,= and it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).<= /u>

=C2=A0

(2) Implementations that don't pace will ge= nerally be causing large bursts for many different reasons anyway (data and= /or ACK aggregation in the network or end hosts), restart from idle,...) so= having a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
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

--000000000000d84e6c05c8f95e9b-- From nobody Mon Aug 9 01:41: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 7996E3A0978 for ; Mon, 9 Aug 2021 01:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 mKwBHvpaAOZP for ; Mon, 9 Aug 2021 01:41:00 -0700 (PDT) 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 C97D63A097E for ; Mon, 9 Aug 2021 01:40:59 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id w10so11874752qtj.3 for ; Mon, 09 Aug 2021 01:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4eXc5bZJELQ0u8i1A6nxJK8rWTzirNkqoWfozGm28gg=; b=LpbNxBCZAQPuhBGY7duFWWXij8BRs4W5aubSm9VTMaT4UdzEdH98uSXK6lQL8lL+U+ WIQ6F3rYr1CDcrnNwCCJeC52OZAzk2zrmJAilKNYvC/Ul2UVNv8vJ+Lg8VrXQGZJIwNM zwxOXg0GO5AdiHPRiLukx6Oir8XzfSrZCcf8+9jP6o9fm/TTZtqFIqFK6YAS8/4Uk5Ci dDr9w8TlKOVpK8IxJV47aIlg6OFOdhnEJUht/t9rNdJeafY+o5JxdnICs8glE/C/O9tG Ba3KNqL6g5iRepqfcVBYExJ9Bs0VBsjutm6782dZMKfLiWXUxXmb5B9bDtYWHBCZBmEM G8sQ== 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=4eXc5bZJELQ0u8i1A6nxJK8rWTzirNkqoWfozGm28gg=; b=lndUoIHxwXfQ86Ku7L4XpRcwCDtO5amWWuLcFVEzw6aX6cFUw/ip7Ta+3efHVsrdO9 D4YPxiCEcjxENPt/1CdQDsVi5V7h84g+wiAcFxeQap5ffmY91PQ9Ba4FcO8M8SK1Eohc A5Xrv3fzxlpXX6eJyXZ8NYP7uw7ajt4GxmvLlRCFlwN0gjfswI81gvYMCffd1jZ9B5wl 4jdZ2MyPyS+CivEDl83z20VntV3MUZpbBUeZ3VzOA3bjQWV3SxM5yuIJKn81OxMQC7bU UbimsoFyFANIEnEVWvfXBpCuuL+lADcrjAGPckabzwaBh03Vacrp9BR7nHYOG2zfgGkB eWmw== X-Gm-Message-State: AOAM531q/6WqW6fCh8k5Q4jae3mMp2w335HF1zbc2DhcbtGB09j0WhyG vktHWQRXW8s+1/Ovy3mayYRQlHbzs60lDZQf51I= X-Google-Smtp-Source: ABdhPJxidwVKAnenpt42HGkGfrCNNPSXccF9vbZjJDmtVi3715TkRRKPAUfVfVjo6hs1/xG56Qf/Kua6N8XWuQPhTnU= X-Received: by 2002:a05:622a:283:: with SMTP id z3mr19144231qtw.312.1628498456760; Mon, 09 Aug 2021 01:40:56 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> In-Reply-To: From: Yoshifumi Nishida Date: Mon, 9 Aug 2021 01:40:45 -0700 Message-ID: To: Neal Cardwell Cc: Vidhi Goel , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="0000000000000855ce05c91c58d2" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 08:41:05 -0000 --0000000000000855ce05c91c58d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't have a strong opinion on this yet, But, if we *could* move in this direction, it might be good to think about the IW explanation in RFC5681 as well? if we do this, we might not need to discuss promoting RFC6928. -- Yoshi On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell wrote: > I also agree with Yuchung=E2=80=99s suggestion, for all of the reasons he= provided. > > best, > neal > > > On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel 40apple.com@dmarc.ietf.org> wrote: > >> I agree with Yuchung=E2=80=99s suggestion for all the reasons he provide= d. And >> its better to have it at one place. >> >> Vidhi >> >> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng < >> ycheng=3D40google.com@dmarc.ietf.org> wrote: >> >> Hi WG >> >> I have been wondering if we (=3D IETF) should just update RFC5681 direct= ly, >> instead of another RFC3465-bis with experimental status. >> >> Appropriate byte counting is essential but the RFC5681 of L=3D1 is >> detrimental. There are far more people who read RFC5681 to implement the >> new stack instead of RFC3465. So we should fold the experimental RFC3465 >> updates into RFC5681 directly, and obsolete RFC3465. >> >> This is orthogonal to the final value of L :-) >> >> >> >> >> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng wrote: >> >>> >>> >>> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng wrote: >>> >>>> >>>> >>>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell >>> 40google.com@dmarc.ietf.org> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >>>> 40microsoft.com@dmarc.ietf.org> wrote: >>>>> >>>>>> In experiments a few years ago on DC networks, values over L=3D8 >>>>>> resulted in a noticeable increase in packet drops and retransmission= s >>>>>> (without pacing). Windows TCP has been using L=3D8 for many years no= w. If we >>>>>> do want to specify a fallback L value for implementations that canno= t pace, >>>>>> my suggestion would be to use the value 8. >>>>>> >>>>>> >>>>>> >>>>>> Neal, are there cases where Linux is or can be deployed with infinit= e >>>>>> L and no pacing? >>>>>> >>>>> >>>>> Yes, "infinite L and no pacing" is the default behavior for Linux TCP= , >>>>> starting in 2013 for slow-start and then starting in 2015 for congest= ion >>>>> avoidance. >>>>> >>>> To be more clear: both fq_pacing and TCP pacing have been disabled by >>>> default in Linux upstream. We do not know how much Linux senders enabl= e >>>> them today besides the Google servers. >>>> >>>> Regarding L =3D 8, to avoid another round of why or why not. We could = say >>>> inf-L causes line-rate burst up to the stretched ACK degree so put a >>>> comfortable L if you prefer, then mention implementation practice like >>>> yours. At the end of the day it's ad-hoc (or "art") and subject to cha= nge. >>>> It might be sensible to cap at cwnd to disincentivize receivers / >>>> middle-boxes bunching up 10 rounds of ACKs. >>>> >>> Sorry please ignore my previous message about the cwnd cap. It is >>> completely unnecessary -- since with ack-clocking and appropriate count= ing, >>> a correct sender would never release more than a cwnd-worth of data. I = was >>> imagining the multiple application-limited burst could let the receiver >>> keep holding up ACKs, but that can never exceed a cwnd worth of data. >>> >>> >>>> >>>>> >>>> >>>>> Yuchung pasted the URLs for the exact Linux commits above, which are: >>>>> >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>>>> >>>>> But I understand that not everyone is in a position to read >>>>> GPL-licensed code. :-) >>>>> >>>>> best regards, >>>>> neal >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> *From:* tcpm *On Behalf Of * Neal Cardwell >>>>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>>>> *To:* Vidhi Goel >>>>>> *Cc:* Extensions ; Mark Allman >>>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC= 3465 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote: >>>>>> >>>>>> >>>>>> > The fact is that Linux CC has long moved to infinite L since 2031, >>>>>> >>>>>> So, if our experience is with L=3D\infinity and it is demonstrably O= K >>>>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>>>>> submit that it makes more sense to leverage experience than it does >>>>>> >>>>>> to make things up. >>>>>> >>>>>> +1 >>>>>> >>>>>> >>>>>> >>>>>> Yes, I agree that would be a great approach to take. >>>>>> >>>>>> >>>>>> >>>>>> So, we are saying it is fine to ignore L completely and simply >>>>>> increase cwnd by bytes_acked during slow start? And if this causes l= arge >>>>>> bursts to be sent out (when an implementation doesn=E2=80=99t do pac= ing), that is >>>>>> fine? >>>>>> >>>>>> >>>>>> >>>>>> Yes, I think that is the proposal on the table, and it sounds good t= o >>>>>> me. >>>>>> >>>>>> >>>>>> >>>>>> A rationale would be: >>>>>> >>>>>> >>>>>> >>>>>> (1) Implementations SHOULD pace (RFC 7661). >>>>>> >>>>>> >>>>>> >>>>>> (2) Implementations that don't pace will generally be causing large >>>>>> bursts for many different reasons anyway (data and/or ACK aggregatio= n in >>>>>> the network or end hosts), restart from idle,...) so having a consta= nt L >>>>>> does not provide enough protection from bursts to justify the cost i= n >>>>>> reduced performance (in the form of slower slow-start). In support o= f this, >>>>>> experience with this as the default behavior in Linux TCP over the >>>>>> 2013-2021 period suggests this works well enough in practice. >>>>>> >>>>>> >>>>>> >>>>>> neal >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 > --0000000000000855ce05c91c58d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have=C2=A0a strong opinion=C2=A0on this y= et, But, if we *could* move in this direction, it might be good to think ab= out the IW explanation in RFC5681 as well?
if we do this, we migh= t not need to discuss promoting RFC6928.
--
Yoshi
=

On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org>= wrote:
I also agree with Yuchung=E2=80=99s suggestion, for all of the rea= sons he provided.

best,
neal

On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel <vidhi_goel=3D40apple.com@dmarc.= ietf.org> wrote:
I agree with Yuchung=E2=80=99s suggestion for all the reasons = he provided. And its better to have it at one place.

Vid= hi

On Aug 6, 2021, at 12:53 PM, = Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:
<= br>
Hi WG

I=C2=A0have=C2=A0bee= n wondering if we (=3D IETF) should just update RFC5681 directly, instead o= f another RFC3465-bis with experimental status.

Ap= propriate byte counting is essential but the RFC5681 of L=3D1 is detrimenta= l. There are far more people who read RFC5681 to implement the new stack in= stead of RFC3465. So we should fold the experimental RFC3465 updates into R= FC5681 directly, and obsolete RFC3465.

This = is orthogonal=C2=A0to the final value of L :-)



On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng <ycheng@google.com>= ; wrote:


On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng= <ycheng@google.c= om> wrote:


On Mon, Aug 2, 2021 at 5:53 PM Neal= Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=3D40microso= ft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, = values over L=3D8 resulted in a noticeable increase in packet drops and ret= ransmissions (without pacing). Windows TCP has been using L=3D8 for many ye= ars now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0=

Neal, are there cases where Linux is or can be d= eployed with infinite L and no pacing?

Yes, "infinite L and no pacing" is the default behavi= or for Linux TCP, starting in 2013 for slow-start and then starting in 2015= for congestion avoidance.
To be more cl= ear: both fq_pacing and TCP pacing have been disabled by default in Linux u= pstream. We do not know how much Linux senders enable them today besides th= e Google servers.

Regarding L =3D 8, to avoid anot= her round of why or why not. We could say inf-L causes line-rate burst up t= o the stretched ACK degree so put a comfortable L if you prefer, then menti= on implementation practice like yours. At the end of the day it's ad-ho= c (or "art") and subject to change. It might be sensible to cap a= t cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of = ACKs.
Sorry please ignore my previou= s message about the cwnd cap. It is completely unnecessary -- since with ac= k-clocking and appropriate counting, a correct sender would never release m= ore than a cwnd-worth of data. I was imagining the multiple application-lim= ited burst could let the receiver keep holding up ACKs, but that can never = exceed a cwnd worth of data.
=C2=A0
=

=C2= =A0
Yuchung pasted the URLs for the= exact Linux commits above, which are:


But I understand that not everyone is i= n a position to read GPL-licensed code. :-)

best r= egards,
neal

=C2=A0

=C2=A0

= From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <<= a href=3D"mailto:vidhi_goel@apple.com" target=3D"_blank">vidhi_goel@apple.c= om> wrote:

=C2=A0

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <= mallman@icir.org&= gt; wrote:


> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0

to make things up.<= /u>

+1

=C2=A0

Yes, I agree that would be a great approach to = take.

=C2=A0

So, we are saying it is fine to ignore L compl= etely and simply increase cwnd by bytes_acked during slow start? And if thi= s causes large bursts to be sent out (when an implementation doesn=E2=80=99= t do pacing), that is fine?=C2=A0

=C2=A0

Yes, I think that is the proposal on the table,= and it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).<= /u>

=C2=A0

(2) Implementations that don't pace will ge= nerally be causing large bursts for many different reasons anyway (data and= /or ACK aggregation in the network or end hosts), restart from idle,...) so= having a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
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
--0000000000000855ce05c91c58d2-- From nobody Mon Aug 9 09:38: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 9244B3A097E for ; Mon, 9 Aug 2021 09:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-GxLuWYDrMH for ; Mon, 9 Aug 2021 09:38:52 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 243F53A0978 for ; Mon, 9 Aug 2021 09:38:52 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id l11-20020a7bcf0b0000b0290253545c2997so441859wmg.4 for ; Mon, 09 Aug 2021 09:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MAJ2ZYWoEAAUGp3VcHM2BI6FpuLuYYL6tWRMQuwZF88=; b=hnFcbWhBTgQ4N3FADEpV5N5ZaVhOXgRWezaPsbDBuUUDPbnLwyrk3wTzcDf/+g+hvF KCR4Ahd2+k3Xa/+sIt6ZD+TBKDDoQLM+MvWP+fR8YGuDXI2D0eLjJu+7FmznpcphAMwO ygAMfDEKUAFIt5eEjN4jTeqFSqmOiP8ZeV/tXQ5zMG7ZRCrSowY+RUEtLVNcS69MG0fd YylNTJwrXa39MdqJRrEA09uEZAHfS7tInxh4H5i3EkMGUjl7OxXr1XoCqU1tTUKkxGx2 pgcc3sHu/5Tn70CaBWqb238Ape2gY7s+fa11zzoJOc6nUdKwCsbvhqS7iv/gnZeGnQYV jvrg== 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=MAJ2ZYWoEAAUGp3VcHM2BI6FpuLuYYL6tWRMQuwZF88=; b=GL0hIFbYRfc3VgV2ApXr6v1uAeteAODny1dvmUTnhZugUXWhnlqhX58KAJmHBazjQq 7bOpxZtMLbmJiREcX9MBdzFMwK0QNWtd2fMgxrcwKrsbRItVJt6PQ/TmLIv/9jPt9SW6 V0z9ty3iT/irlI1a8jvJAEkKrGR0lXQkOY/GDP6lBwh6tDjK8PDZe3ikSeIhIR+Stsg6 1BRawW8dFYHvkCxrP9vkN0UIGoEdbkNBALJ1LVP3hIDLYbRQb2jloYF9xDfhXNB8cLBr Y4BJTV9PX3jpBp23c1M0CS4byEgDdaJtKb+zux5kwi/iF7flZ/EQVSbxZ1zFaXgXvKhT OL6w== X-Gm-Message-State: AOAM5332ue61cYQNjGymR+jRBGNBZpjnR0XCtg6n6STtnMKONH4F0LBE Nstw6MO8vWSqt9AOGUSF5IxKhM3dq7h2P4OldMWgvA== X-Google-Smtp-Source: ABdhPJz0FrkZCXaYZ+fG2d/omwOA7xLXdI7IAPlgaKUx8D1ctD8YiVtMeABeEip2IXJcHo6TBGWtGNgUUrjzr7fC+gc= X-Received: by 2002:a1c:f206:: with SMTP id s6mr17349957wmc.102.1628527128912; Mon, 09 Aug 2021 09:38:48 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> In-Reply-To: From: Yuchung Cheng Date: Mon, 9 Aug 2021 09:38:10 -0700 Message-ID: To: Yoshifumi Nishida Cc: Neal Cardwell , Vidhi Goel , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="00000000000007404d05c92305d6" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 16:38:57 -0000 --00000000000007404d05c92305d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry I don't understand your suggestion. Is that related to ABC? could you explain more On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida wrote= : > I don't have a strong opinion on this yet, But, if we *could* move in thi= s > direction, it might be good to think about the IW explanation in RFC5681 = as > well? > if we do this, we might not need to discuss promoting RFC6928. > -- > Yoshi > > On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > >> I also agree with Yuchung=E2=80=99s suggestion, for all of the reasons h= e >> provided. >> >> best, >> neal >> >> >> On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel > 40apple.com@dmarc.ietf.org> wrote: >> >>> I agree with Yuchung=E2=80=99s suggestion for all the reasons he provid= ed. And >>> its better to have it at one place. >>> >>> Vidhi >>> >>> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng < >>> ycheng=3D40google.com@dmarc.ietf.org> wrote: >>> >>> Hi WG >>> >>> I have been wondering if we (=3D IETF) should just update RFC5681 >>> directly, instead of another RFC3465-bis with experimental status. >>> >>> Appropriate byte counting is essential but the RFC5681 of L=3D1 is >>> detrimental. There are far more people who read RFC5681 to implement th= e >>> new stack instead of RFC3465. So we should fold the experimental RFC346= 5 >>> updates into RFC5681 directly, and obsolete RFC3465. >>> >>> This is orthogonal to the final value of L :-) >>> >>> >>> >>> >>> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng wrote: >>> >>>> >>>> >>>> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng wrote= : >>>> >>>>> >>>>> >>>>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell >>>> 40google.com@dmarc.ietf.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >>>>> 40microsoft.com@dmarc.ietf.org> wrote: >>>>>> >>>>>>> In experiments a few years ago on DC networks, values over L=3D8 >>>>>>> resulted in a noticeable increase in packet drops and retransmissio= ns >>>>>>> (without pacing). Windows TCP has been using L=3D8 for many years n= ow. If we >>>>>>> do want to specify a fallback L value for implementations that cann= ot pace, >>>>>>> my suggestion would be to use the value 8. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Neal, are there cases where Linux is or can be deployed with >>>>>>> infinite L and no pacing? >>>>>>> >>>>>> >>>>>> Yes, "infinite L and no pacing" is the default behavior for Linux >>>>>> TCP, starting in 2013 for slow-start and then starting in 2015 for >>>>>> congestion avoidance. >>>>>> >>>>> To be more clear: both fq_pacing and TCP pacing have been disabled by >>>>> default in Linux upstream. We do not know how much Linux senders enab= le >>>>> them today besides the Google servers. >>>>> >>>>> Regarding L =3D 8, to avoid another round of why or why not. We could >>>>> say inf-L causes line-rate burst up to the stretched ACK degree so pu= t a >>>>> comfortable L if you prefer, then mention implementation practice lik= e >>>>> yours. At the end of the day it's ad-hoc (or "art") and subject to ch= ange. >>>>> It might be sensible to cap at cwnd to disincentivize receivers / >>>>> middle-boxes bunching up 10 rounds of ACKs. >>>>> >>>> Sorry please ignore my previous message about the cwnd cap. It is >>>> completely unnecessary -- since with ack-clocking and appropriate coun= ting, >>>> a correct sender would never release more than a cwnd-worth of data. I= was >>>> imagining the multiple application-limited burst could let the receive= r >>>> keep holding up ACKs, but that can never exceed a cwnd worth of data. >>>> >>>> >>>>> >>>>>> >>>>> >>>>>> Yuchung pasted the URLs for the exact Linux commits above, which are= : >>>>>> >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c= ommit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c= ommit/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c= ommit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c= ommit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c= ommit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>>>>> >>>>>> But I understand that not everyone is in a position to read >>>>>> GPL-licensed code. :-) >>>>>> >>>>>> best regards, >>>>>> neal >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* tcpm *On Behalf Of * Neal Cardwell >>>>>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>>>>> *To:* Vidhi Goel >>>>>>> *Cc:* Extensions ; Mark Allman >>>>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RF= C3465 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman wrote= : >>>>>>> >>>>>>> >>>>>>> > The fact is that Linux CC has long moved to infinite L since 2031= , >>>>>>> >>>>>>> So, if our experience is with L=3D\infinity and it is demonstrably = OK >>>>>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >>>>>>> submit that it makes more sense to leverage experience than it does >>>>>>> >>>>>>> to make things up. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, I agree that would be a great approach to take. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So, we are saying it is fine to ignore L completely and simply >>>>>>> increase cwnd by bytes_acked during slow start? And if this causes = large >>>>>>> bursts to be sent out (when an implementation doesn=E2=80=99t do pa= cing), that is >>>>>>> fine? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, I think that is the proposal on the table, and it sounds good >>>>>>> to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> A rationale would be: >>>>>>> >>>>>>> >>>>>>> >>>>>>> (1) Implementations SHOULD pace (RFC 7661). >>>>>>> >>>>>>> >>>>>>> >>>>>>> (2) Implementations that don't pace will generally be causing large >>>>>>> bursts for many different reasons anyway (data and/or ACK aggregati= on in >>>>>>> the network or end hosts), restart from idle,...) so having a const= ant L >>>>>>> does not provide enough protection from bursts to justify the cost = in >>>>>>> reduced performance (in the form of slower slow-start). In support = of this, >>>>>>> experience with this as the default behavior in Linux TCP over the >>>>>>> 2013-2021 period suggests this works well enough in practice. >>>>>>> >>>>>>> >>>>>>> >>>>>>> neal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 > --00000000000007404d05c92305d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry I don't understand your suggestion. Is that rela= ted to ABC? could you explain more

On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi = Nishida <nsd.ietf@gmail.com>= ; wrote:
I don't have=C2=A0a strong opinion=C2=A0on this yet, But= , if we *could* move in this direction, it might be good to think about the= IW explanation in RFC5681 as well?
if we do this, we might not n= eed to discuss promoting RFC6928.
--
Yoshi
On= Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.or= g> wrote:
I also agree with Yuchung=E2=80=99s suggestion, for all o= f the reasons he provided.

best,
neal


On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel <vidhi_goel=3D= 40apple.com= @dmarc.ietf.org> wrote:
I agree with Yuchung=E2=80=99s suggestion for all the r= easons he provided. And its better to have it at one place.

<= div>Vidhi

On Aug 6, 2021, at 12:= 53 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:=

Hi WG

I=C2=A0have= =C2=A0been wondering if we (=3D IETF) should just update RFC5681 directly, = instead of another RFC3465-bis with experimental status.

Appropriate byte counting is essential but the RFC5681 of L=3D1 is d= etrimental. There are far more people who read RFC5681 to implement the new= stack instead of RFC3465. So we should fold the experimental RFC3465 updat= es into RFC5681 directly, and obsolete RFC3465.

<= div>This is orthogonal=C2=A0to the final value of L :-)




On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng= <ycheng@google.c= om> wrote:


On Mon, Aug 2, 2021 at 6:12 PM Yuch= ung Cheng <ycheng= @google.com> wrote:


On Mon, Aug 2, 2021 at 5:5= 3 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <= pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, = values over L=3D8 resulted in a noticeable increase in packet drops and ret= ransmissions (without pacing). Windows TCP has been using L=3D8 for many ye= ars now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0=

Neal, are there cases where Linux is or can be d= eployed with infinite L and no pacing?

Yes, "infinite L and no pacing" is the default behavi= or for Linux TCP, starting in 2013 for slow-start and then starting in 2015= for congestion avoidance.
To be more cl= ear: both fq_pacing and TCP pacing have been disabled by default in Linux u= pstream. We do not know how much Linux senders enable them today besides th= e Google servers.

Regarding L =3D 8, to avoid anot= her round of why or why not. We could say inf-L causes line-rate burst up t= o the stretched ACK degree so put a comfortable L if you prefer, then menti= on implementation practice like yours. At the end of the day it's ad-ho= c (or "art") and subject to change. It might be sensible to cap a= t cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of = ACKs.
Sorry please ignore my previou= s message about the cwnd cap. It is completely unnecessary -- since with ac= k-clocking and appropriate counting, a correct sender would never release m= ore than a cwnd-worth of data. I was imagining the multiple application-lim= ited burst could let the receiver keep holding up ACKs, but that can never = exceed a cwnd worth of data.
=C2=A0
=

=C2= =A0
Yuchung pasted the URLs for the= exact Linux commits above, which are:


But I understand that not everyone is i= n a position to read GPL-licensed code. :-)

best r= egards,
neal

=C2=A0

=C2=A0

= From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <<= a href=3D"mailto:vidhi_goel@apple.com" target=3D"_blank">vidhi_goel@apple.c= om> wrote:

=C2=A0

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <= mallman@icir.org&= gt; wrote:


> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0

to make things up.<= /u>

+1

=C2=A0

Yes, I agree that would be a great approach to = take.

=C2=A0

So, we are saying it is fine to ignore L compl= etely and simply increase cwnd by bytes_acked during slow start? And if thi= s causes large bursts to be sent out (when an implementation doesn=E2=80=99= t do pacing), that is fine?=C2=A0

=C2=A0

Yes, I think that is the proposal on the table,= and it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).<= /u>

=C2=A0

(2) Implementations that don't pace will ge= nerally be causing large bursts for many different reasons anyway (data and= /or ACK aggregation in the network or end hosts), restart from idle,...) so= having a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
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
--00000000000007404d05c92305d6-- From nobody Mon Aug 9 09:53: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 53C503A0AD4 for ; Mon, 9 Aug 2021 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 UQGuQDTIhKRl for ; Mon, 9 Aug 2021 09:53:40 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 377663A0A97 for ; Mon, 9 Aug 2021 09:53:40 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id m39so2041159uad.9 for ; Mon, 09 Aug 2021 09:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wqGGM/h4TaV4M7BEwBHbu/YWBOYo1g4uVFnQYdj0Ru4=; b=hRUIxNTUOCaGJe4w8xtimg3v3N7u1PfGpQJ+rf6MeMtOmGcfrqYU1TJzXz0S5m8kTQ dEibqdQ53WpzUAvIWy2U2fZ7fzKeA33QSUvENp7A1bOLXQIdhzs/QIvvUsqTuwCbOzdG ZRwsfCcWg8ovD78cVl7HRpeiD66nS+LXfkuSJC8wVsAFAJJzRJxOGDcOggOz/G7awn9b rlkLwo5wgHZ+tohlfady1hVXXnJfO56wNsFQmihAlwo6XRu83yqG9e5m5JZL1M0+AMiw XotIiTknx+kwhx1sFYgr8Bk9wLaAu0V2QMB9sgfgjx8tn9Y/uArOQHYHGJ+YYWLdUfF7 yFZw== 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=wqGGM/h4TaV4M7BEwBHbu/YWBOYo1g4uVFnQYdj0Ru4=; b=EHHQPADOY2s94BDYqIX6uPbr3x9jYEGHWaIFOZgYqtPqI/oQlluzzhpi28I/H0oq1d SHxxqWVmz7yY1nL7KadYCsz3XD3dOj5djKBKjNxBSh1CDW9pWiEFr7jhmwMjpj8PlgdX mNpTgyyksvUpEHwcPXo21Lk7SuB9cFudTxbyhBCJuwflAEC+9o1HwsC6JMJ7//fbgoZq ewMbhZX/A+qOX38W4wIm2azQQQ20bJSvCgAhGZQ+d+6MOP3BbfLjUxj7MZ5jhZ1yFST0 VKSCZbFqFnEvhTHxdxpXFCGQdLer0nUBvrSyR7o66UqPP+4ftJR1NMb2gCjZ+fg7aZRb gcSQ== X-Gm-Message-State: AOAM5317c50BwC7lyH/t/Ca4aKtwm9lcK4sgZipdHXcfvJaEZNthfIJx bHtuK1Q5hf989uFNDNGzR7aYiPB+kkgzqCZ0OoEnYA== X-Google-Smtp-Source: ABdhPJw+GM+Hm3TaJPM6E7T4jrRaETlNNFqBAHUPV2yZIwI080W2OzrJXc1J54PxnJ2ILaMS7sNQbcW2G49tNUK/M0s= X-Received: by 2002:a9f:2e08:: with SMTP id t8mr6127057uaj.33.1628528017854; Mon, 09 Aug 2021 09:53:37 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> In-Reply-To: From: Neal Cardwell Date: Mon, 9 Aug 2021 12:53:20 -0400 Message-ID: To: Yuchung Cheng Cc: Yoshifumi Nishida , Vidhi Goel , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="000000000000036ad605c9233a89" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 16:53:53 -0000 --000000000000036ad605c9233a89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Yoshifumi is suggesting that if the WG re-spins RFC5681 then in addition to folding in discussion of ABC/RFC3465 the RFC5681bis could also include the IW10 content in RFC6928. That could help save time in avoiding promoting RFC6928 from experimental to proposed standard. That sounds reasonable to me as well. Although the initial window is a somewhat independent issue that might evolve independently from the congestion algorithm itself, so I can imagine advantages to keeping it separate. neal On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng wrote: > Sorry I don't understand your suggestion. Is that related to ABC? could > you explain more > > On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida > wrote: > >> I don't have a strong opinion on this yet, But, if we *could* move in >> this direction, it might be good to think about the IW explanation in >> RFC5681 as well? >> if we do this, we might not need to discuss promoting RFC6928. >> -- >> Yoshi >> >> On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell > 40google.com@dmarc.ietf.org> wrote: >> >>> I also agree with Yuchung=E2=80=99s suggestion, for all of the reasons = he >>> provided. >>> >>> best, >>> neal >>> >>> >>> On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel >> 40apple.com@dmarc.ietf.org> wrote: >>> >>>> I agree with Yuchung=E2=80=99s suggestion for all the reasons he provi= ded. And >>>> its better to have it at one place. >>>> >>>> Vidhi >>>> >>>> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng < >>>> ycheng=3D40google.com@dmarc.ietf.org> wrote: >>>> >>>> Hi WG >>>> >>>> I have been wondering if we (=3D IETF) should just update RFC5681 >>>> directly, instead of another RFC3465-bis with experimental status. >>>> >>>> Appropriate byte counting is essential but the RFC5681 of L=3D1 is >>>> detrimental. There are far more people who read RFC5681 to implement t= he >>>> new stack instead of RFC3465. So we should fold the experimental RFC34= 65 >>>> updates into RFC5681 directly, and obsolete RFC3465. >>>> >>>> This is orthogonal to the final value of L :-) >>>> >>>> >>>> >>>> >>>> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng wrote= : >>>> >>>>> >>>>> >>>>> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell >>>>> 40google.com@dmarc.ietf.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >>>>>> 40microsoft.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>>> In experiments a few years ago on DC networks, values over L=3D8 >>>>>>>> resulted in a noticeable increase in packet drops and retransmissi= ons >>>>>>>> (without pacing). Windows TCP has been using L=3D8 for many years = now. If we >>>>>>>> do want to specify a fallback L value for implementations that can= not pace, >>>>>>>> my suggestion would be to use the value 8. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Neal, are there cases where Linux is or can be deployed with >>>>>>>> infinite L and no pacing? >>>>>>>> >>>>>>> >>>>>>> Yes, "infinite L and no pacing" is the default behavior for Linux >>>>>>> TCP, starting in 2013 for slow-start and then starting in 2015 for >>>>>>> congestion avoidance. >>>>>>> >>>>>> To be more clear: both fq_pacing and TCP pacing have been disabled b= y >>>>>> default in Linux upstream. We do not know how much Linux senders ena= ble >>>>>> them today besides the Google servers. >>>>>> >>>>>> Regarding L =3D 8, to avoid another round of why or why not. We coul= d >>>>>> say inf-L causes line-rate burst up to the stretched ACK degree so p= ut a >>>>>> comfortable L if you prefer, then mention implementation practice li= ke >>>>>> yours. At the end of the day it's ad-hoc (or "art") and subject to c= hange. >>>>>> It might be sensible to cap at cwnd to disincentivize receivers / >>>>>> middle-boxes bunching up 10 rounds of ACKs. >>>>>> >>>>> Sorry please ignore my previous message about the cwnd cap. It is >>>>> completely unnecessary -- since with ack-clocking and appropriate cou= nting, >>>>> a correct sender would never release more than a cwnd-worth of data. = I was >>>>> imagining the multiple application-limited burst could let the receiv= er >>>>> keep holding up ACKs, but that can never exceed a cwnd worth of data. >>>>> >>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> Yuchung pasted the URLs for the exact Linux commits above, which ar= e: >>>>>>> >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= commit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= commit/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= commit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= commit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= commit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>>>>>> >>>>>>> But I understand that not everyone is in a position to read >>>>>>> GPL-licensed code. :-) >>>>>>> >>>>>>> best regards, >>>>>>> neal >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* tcpm *On Behalf Of * Neal Cardwell >>>>>>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>>>>>> *To:* Vidhi Goel >>>>>>>> *Cc:* Extensions ; Mark Allman >>>>>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement R= FC3465 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> > The fact is that Linux CC has long moved to infinite L since 203= 1, >>>>>>>> >>>>>>>> So, if our experience is with L=3D\infinity and it is demonstrably= OK >>>>>>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I woul= d >>>>>>>> submit that it makes more sense to leverage experience than it doe= s >>>>>>>> >>>>>>>> to make things up. >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, I agree that would be a great approach to take. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So, we are saying it is fine to ignore L completely and simply >>>>>>>> increase cwnd by bytes_acked during slow start? And if this causes= large >>>>>>>> bursts to be sent out (when an implementation doesn=E2=80=99t do p= acing), that is >>>>>>>> fine? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, I think that is the proposal on the table, and it sounds good >>>>>>>> to me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A rationale would be: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (1) Implementations SHOULD pace (RFC 7661). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (2) Implementations that don't pace will generally be causing larg= e >>>>>>>> bursts for many different reasons anyway (data and/or ACK aggregat= ion in >>>>>>>> the network or end hosts), restart from idle,...) so having a cons= tant L >>>>>>>> does not provide enough protection from bursts to justify the cost= in >>>>>>>> reduced performance (in the form of slower slow-start). In support= of this, >>>>>>>> experience with this as the default behavior in Linux TCP over the >>>>>>>> 2013-2021 period suggests this works well enough in practice. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> neal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> > --000000000000036ad605c9233a89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Yoshifumi is suggesting that if the WG re-spins = =C2=A0RFC5681 then in addition to folding in discussion of ABC/RFC3465 the = RFC5681bis=C2=A0could also include the IW10 content in RFC6928. That could = help save time in avoiding promoting RFC6928 from experimental to proposed = standard.

That sounds reasonable to me as well. Alth= ough the initial window is a somewhat independent issue that might evolve i= ndependently from the congestion algorithm itself, so I can imagine advanta= ges to keeping it separate.

neal


On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote= :
Sorry I don't understand your suggestion. Is that related to ABC? co= uld you explain more

On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
I don't have=C2=A0a strong opinion=C2=A0on this yet,= But, if we *could* move in this direction, it might be good to think about= the IW explanation in RFC5681 as well?
if we do this, we might n= ot need to discuss promoting RFC6928.
--
Yoshi

On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell <ncardwell=3D40google.com@dmarc.iet= f.org> wrote:
I also agree with Yuchung=E2=80=99s suggestion, for a= ll of the reasons he provided.

best,
neal<= /div>


On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel <vidhi_goe= l=3D40apple= .com@dmarc.ietf.org> wrote:
I agree with Yuchung=E2=80=99s suggestion for all t= he reasons he provided. And its better to have it at one place.

Vidhi

On Aug 6, 2021, at= 12:53 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wr= ote:

Hi WG

I=C2=A0ha= ve=C2=A0been wondering if we (=3D IETF) should just update RFC5681 directly= , instead of another RFC3465-bis with experimental status.

Appropriate byte counting is essential but the RFC5681 of L=3D1 is= detrimental. There are far more people who read RFC5681 to implement the n= ew stack instead of RFC3465. So we should fold the experimental RFC3465 upd= ates into RFC5681 directly, and obsolete RFC3465.

This is orthogonal=C2=A0to the final value of L :-)




On Tue, Aug 3, 2021 at 9:42 AM Yuchung Che= ng <ycheng@google= .com> wrote:


On Mon, Aug 2, 2021 at 6:12 PM Yu= chung Cheng <yche= ng@google.com> wrote:


On Mon, Aug 2, 2021 at 5= :53 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <= ;pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, = values over L=3D8 resulted in a noticeable increase in packet drops and ret= ransmissions (without pacing). Windows TCP has been using L=3D8 for many ye= ars now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0=

Neal, are there cases where Linux is or can be d= eployed with infinite L and no pacing?

Yes, "infinite L and no pacing" is the default behavi= or for Linux TCP, starting in 2013 for slow-start and then starting in 2015= for congestion avoidance.
To be more cl= ear: both fq_pacing and TCP pacing have been disabled by default in Linux u= pstream. We do not know how much Linux senders enable them today besides th= e Google servers.

Regarding L =3D 8, to avoid anot= her round of why or why not. We could say inf-L causes line-rate burst up t= o the stretched ACK degree so put a comfortable L if you prefer, then menti= on implementation practice like yours. At the end of the day it's ad-ho= c (or "art") and subject to change. It might be sensible to cap a= t cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of = ACKs.
Sorry please ignore my previou= s message about the cwnd cap. It is completely unnecessary -- since with ac= k-clocking and appropriate counting, a correct sender would never release m= ore than a cwnd-worth of data. I was imagining the multiple application-lim= ited burst could let the receiver keep holding up ACKs, but that can never = exceed a cwnd worth of data.
=C2=A0
=

=C2= =A0
Yuchung pasted the URLs for the= exact Linux commits above, which are:


But I understand that not everyone is i= n a position to read GPL-licensed code. :-)

best r= egards,
neal

=C2=A0

=C2=A0

= From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <<= a href=3D"mailto:vidhi_goel@apple.com" target=3D"_blank">vidhi_goel@apple.c= om> wrote:

=C2=A0

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <= mallman@icir.org&= gt; wrote:


> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0

to make things up.<= /u>

+1

=C2=A0

Yes, I agree that would be a great approach to = take.

=C2=A0

So, we are saying it is fine to ignore L compl= etely and simply increase cwnd by bytes_acked during slow start? And if thi= s causes large bursts to be sent out (when an implementation doesn=E2=80=99= t do pacing), that is fine?=C2=A0

=C2=A0

Yes, I think that is the proposal on the table,= and it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).<= /u>

=C2=A0

(2) Implementations that don't pace will ge= nerally be causing large bursts for many different reasons anyway (data and= /or ACK aggregation in the network or end hosts), restart from idle,...) so= having a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
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
--000000000000036ad605c9233a89-- From nobody Mon Aug 9 10:05: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 EC15E3A0B5E for ; Mon, 9 Aug 2021 10:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 g5HVxY8j-vC1 for ; Mon, 9 Aug 2021 10:05:40 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 EE67E3A0B45 for ; Mon, 9 Aug 2021 10:05:39 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id v10-20020a9d604a0000b02904fa9613b53dso7770408otj.6 for ; Mon, 09 Aug 2021 10:05:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=jz+qyZu8sQg1eSeP3YJXxcy4WpLLbw+EVv3T03ohJkI=; b=Xzm9s7ocg6xzCkMGvjC2GTsH9ZfBs9yqQBWK8E6r7m+DZ4kvLBCuaGxO30ugX6wftH eEotz8cERIUW3PrRibkEBU61EWM48Z71FVkq+YqsgB3HOUByMS0NzKjSqDTYf6P21hIm oWrF9c6OMYRkox0oA56hEOqk1628ZwEPaYmTlMwhjPeaU2/NZhc3C6AY6UHXOiVF0+LE ts5XcpvPPckXhXCE4M/XaaCCIIRSGs5UJ8b37tjUrKorshTlCog8tdtUa63uugEF50Gb XGDwooz+ym7ZThziUm4xOHDnHMAT+uU3OXdPlHuKe6yQd2qfzhPZHvG2evtjKZ/4A8fU 6QnQ== X-Gm-Message-State: AOAM530ndyDvazM+FFZ8MpmPMdN++6dmadYoeu7BlLMdNDW7JrPhklz+ dSQgxfKiQN2RnYiEIyIwPV3NH+9xqhCBLdcG X-Google-Smtp-Source: ABdhPJw+inI2zi0ceYuTtcBiNqd/ArasEcfBEk+sYP3vrNB6bw+7bmjZppPJ0e/10WPY98PCMRltzg== X-Received: by 2002:a9d:7cc5:: with SMTP id r5mr4363084otn.55.1628528739151; Mon, 09 Aug 2021 10:05:39 -0700 (PDT) Received: from [192.168.1.208] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id d11sm2886966ooh.8.2021.08.09.10.05.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Aug 2021 10:05:38 -0700 (PDT) From: "Mark Allman" To: "Neal Cardwell" Cc: "Vidhi Goel" , "Yuchung Cheng" , Extensions Date: Mon, 09 Aug 2021 13:05:35 -0400 X-Mailer: MailMate (1.13.2r5673) Message-ID: <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> In-Reply-To: References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_087DB947-9239-428B-8FA5-2B95B531C25C_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 17:05:45 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_087DB947-9239-428B-8FA5-2B95B531C25C_= Content-Type: text/plain > (2) Implementations that don't pace will generally be causing > large bursts for many different reasons anyway (data and/or ACK > aggregation in the network or end hosts), restart from idle,...) > so having a constant L does not provide enough protection from > bursts to justify the cost in reduced performance (in the form of > slower slow-start). In support of this, experience with this as > the default behavior in Linux TCP over the 2013-2021 period > suggests this works well enough in practice. I think at some point someone should put some meat on the bones of "suggests this works well enough in practice". It isn't enough for linux to have implemented this. Or, even had it turned on. E.g., if L=\infinity yet receivers ACK every other packet then there is an effective L of 2. We see lots of people saying this scenario isn't the prevalent scenario these days. If that's true then it should be easy to provide a summary of experience with L=\infinity. This would all just seem better with some concrete experience rather than the quite hand wavy statements we've seen so far. allman --=_MailMate_087DB947-9239-428B-8FA5-2B95B531C25C_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCYRFgXxEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizm79AKCcngxEvEyqVFFCFqHFfvTfP+CwpACeOORZ VyRFlpRQHHgtY+TSSCWiVhw= =m75P -----END PGP SIGNATURE----- --=_MailMate_087DB947-9239-428B-8FA5-2B95B531C25C_=-- From nobody Mon Aug 9 10:07: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 0BEE33A0BC9 for ; Mon, 9 Aug 2021 10:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 HBYg5Kins9iJ for ; Mon, 9 Aug 2021 10:07:31 -0700 (PDT) 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 148D93A0BE3 for ; Mon, 9 Aug 2021 10:07:28 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id em4so9379039qvb.0 for ; Mon, 09 Aug 2021 10:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wV0oERuGoJhhX3rcdOy+7qYfdEqPTPtlv2o3AnTdE10=; b=FQXBbhl2QRNOoOkVYwrt9NjHcmL5K8bXu7dt5+nBd3l2PmknML1RQGQ846QFwf2rpQ oOBhCwnsyG2BGNJI9+Erw4Io/0ErofN5Atp6KrTKBlxQTIYQhe4iY/Zuh5G7bq9BjiS1 tDEiXqEw1bn+OFz6F5CnyYNlRlE2kvQEffSE72elAXW7CM3fNCbjU/XbGOVgYugqw6FA goHz+qUY7Vst17oDpl15LbqgYmQ8+VP22SgPuDajCHc3weSce16pNsllf5SxV+cG/ak5 fwP0D9b5J8HVOHGH3QPvc5Z3rnxojODVWM5Y9DKACAR3sRBniYbHI617KfqKlDE9cvom bwTA== 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=wV0oERuGoJhhX3rcdOy+7qYfdEqPTPtlv2o3AnTdE10=; b=IecKTpz/QjFdipyfrfagOPAZRM+74RE0iT50+O+NYjxRUABBxvItJE6TCCmUweJjQH 5onBu6IQKvZAyeDodrZZZB7ylzBCF66fBjavKqOVmxl65xfLvjItjUSXwDelPuJdqPhj szsf1LM8jpWA08eRfhsP0QcaZjcvz3gH4YGR9Kr0WmNXiznZ/NVC8LkmYNgg1dBAp09R L7dfNXpCqW0eLpImHaEB420Ti5QY0lntH0VsJW5Jib1PwAZZ/n6D5uLy13VRpSsAinLu V9fewf4WRqvJldxB6qLx7C7TIRWCnVl3l7E83D2dcuTsKmMuVNXkXXahBpn9PweU28MT bOnw== X-Gm-Message-State: AOAM531AqtGY1dxTucmV3vBU0TPzlviSEc9lyaRGEYsNOiQatPbv8EuZ BuALDYfwIBYWC0HgQ4Mc5IWYU4FVfxvQWZLGRYQ= X-Google-Smtp-Source: ABdhPJxBe5YLILukM+KngrV3/H6bp3odPct/uHBte1LAjzZIgA+TJr2+moDyUP0KSmVk/PX4c4wJeV+qBDLWiRNe38c= X-Received: by 2002:ad4:5bc7:: with SMTP id t7mr24551222qvt.10.1628528845457; Mon, 09 Aug 2021 10:07:25 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> In-Reply-To: From: Yoshifumi Nishida Date: Mon, 9 Aug 2021 10:07:13 -0700 Message-ID: To: Neal Cardwell Cc: Yuchung Cheng , Vidhi Goel , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="000000000000570a5005c9236b65" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 17:07:43 -0000 --000000000000570a5005c9236b65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that was my intention. Sorry for being unclear. I thought updating RFC5681 could be impactful. So, if it would happen, I would like to make sure we won't have another update for a long time. -- Yoshi On Mon, Aug 9, 2021 at 9:53 AM Neal Cardwell wrote: > I think Yoshifumi is suggesting that if the WG re-spins RFC5681 then in > addition to folding in discussion of ABC/RFC3465 the RFC5681bis could als= o > include the IW10 content in RFC6928. That could help save time in avoidin= g > promoting RFC6928 from experimental to proposed standard. > > That sounds reasonable to me as well. Although the initial window is a > somewhat independent issue that might evolve independently from the > congestion algorithm itself, so I can imagine advantages to keeping it > separate. > > neal > > > On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng 40google.com@dmarc.ietf.org> wrote: > >> Sorry I don't understand your suggestion. Is that related to ABC? could >> you explain more >> >> On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida >> wrote: >> >>> I don't have a strong opinion on this yet, But, if we *could* move in >>> this direction, it might be good to think about the IW explanation in >>> RFC5681 as well? >>> if we do this, we might not need to discuss promoting RFC6928. >>> -- >>> Yoshi >>> >>> On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell >> 40google.com@dmarc.ietf.org> wrote: >>> >>>> I also agree with Yuchung=E2=80=99s suggestion, for all of the reasons= he >>>> provided. >>>> >>>> best, >>>> neal >>>> >>>> >>>> On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel >>> 40apple.com@dmarc.ietf.org> wrote: >>>> >>>>> I agree with Yuchung=E2=80=99s suggestion for all the reasons he prov= ided. And >>>>> its better to have it at one place. >>>>> >>>>> Vidhi >>>>> >>>>> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng < >>>>> ycheng=3D40google.com@dmarc.ietf.org> wrote: >>>>> >>>>> Hi WG >>>>> >>>>> I have been wondering if we (=3D IETF) should just update RFC5681 >>>>> directly, instead of another RFC3465-bis with experimental status. >>>>> >>>>> Appropriate byte counting is essential but the RFC5681 of L=3D1 is >>>>> detrimental. There are far more people who read RFC5681 to implement = the >>>>> new stack instead of RFC3465. So we should fold the experimental RFC3= 465 >>>>> updates into RFC5681 directly, and obsolete RFC3465. >>>>> >>>>> This is orthogonal to the final value of L :-) >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell >>>>>> 40google.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >>>>>>> 40microsoft.com@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> In experiments a few years ago on DC networks, values over L=3D8 >>>>>>>>> resulted in a noticeable increase in packet drops and retransmiss= ions >>>>>>>>> (without pacing). Windows TCP has been using L=3D8 for many years= now. If we >>>>>>>>> do want to specify a fallback L value for implementations that ca= nnot pace, >>>>>>>>> my suggestion would be to use the value 8. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Neal, are there cases where Linux is or can be deployed with >>>>>>>>> infinite L and no pacing? >>>>>>>>> >>>>>>>> >>>>>>>> Yes, "infinite L and no pacing" is the default behavior for Linux >>>>>>>> TCP, starting in 2013 for slow-start and then starting in 2015 for >>>>>>>> congestion avoidance. >>>>>>>> >>>>>>> To be more clear: both fq_pacing and TCP pacing have been disabled >>>>>>> by default in Linux upstream. We do not know how much Linux senders= enable >>>>>>> them today besides the Google servers. >>>>>>> >>>>>>> Regarding L =3D 8, to avoid another round of why or why not. We cou= ld >>>>>>> say inf-L causes line-rate burst up to the stretched ACK degree so = put a >>>>>>> comfortable L if you prefer, then mention implementation practice l= ike >>>>>>> yours. At the end of the day it's ad-hoc (or "art") and subject to = change. >>>>>>> It might be sensible to cap at cwnd to disincentivize receivers / >>>>>>> middle-boxes bunching up 10 rounds of ACKs. >>>>>>> >>>>>> Sorry please ignore my previous message about the cwnd cap. It is >>>>>> completely unnecessary -- since with ack-clocking and appropriate co= unting, >>>>>> a correct sender would never release more than a cwnd-worth of data.= I was >>>>>> imagining the multiple application-limited burst could let the recei= ver >>>>>> keep holding up ACKs, but that can never exceed a cwnd worth of data= . >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Yuchung pasted the URLs for the exact Linux commits above, which >>>>>>>> are: >>>>>>>> >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= /commit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= /commit/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= /commit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= /commit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= /commit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>>>>>>> >>>>>>>> But I understand that not everyone is in a position to read >>>>>>>> GPL-licensed code. :-) >>>>>>>> >>>>>>>> best regards, >>>>>>>> neal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* tcpm *On Behalf Of * Neal Cardwel= l >>>>>>>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>>>>>>> *To:* Vidhi Goel >>>>>>>>> *Cc:* Extensions ; Mark Allman >>>>>>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement = RFC3465 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> > The fact is that Linux CC has long moved to infinite L since >>>>>>>>> 2031, >>>>>>>>> >>>>>>>>> So, if our experience is with L=3D\infinity and it is demonstrabl= y OK >>>>>>>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I wou= ld >>>>>>>>> submit that it makes more sense to leverage experience than it >>>>>>>>> does >>>>>>>>> >>>>>>>>> to make things up. >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, I agree that would be a great approach to take. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> So, we are saying it is fine to ignore L completely and simply >>>>>>>>> increase cwnd by bytes_acked during slow start? And if this cause= s large >>>>>>>>> bursts to be sent out (when an implementation doesn=E2=80=99t do = pacing), that is >>>>>>>>> fine? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, I think that is the proposal on the table, and it sounds goo= d >>>>>>>>> to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A rationale would be: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (1) Implementations SHOULD pace (RFC 7661). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (2) Implementations that don't pace will generally be causing >>>>>>>>> large bursts for many different reasons anyway (data and/or ACK a= ggregation >>>>>>>>> in the network or end hosts), restart from idle,...) so having a = constant L >>>>>>>>> does not provide enough protection from bursts to justify the cos= t in >>>>>>>>> reduced performance (in the form of slower slow-start). In suppor= t of this, >>>>>>>>> experience with this as the default behavior in Linux TCP over th= e >>>>>>>>> 2013-2021 period suggests this works well enough in practice. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> neal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> >> --000000000000570a5005c9236b65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, that was my intention. Sorry for being unclear.<= /div>
I thought updating RFC5681 could be impactful. So, if it would ha= ppen, I would like to make sure we won't have another update=C2=A0for a= long time.
--
Yoshi

On Mon, Aug 9, 2021 at 9:53 AM Neal= Cardwell <ncardwell@google.com<= /a>> wrote:
<= div dir=3D"ltr">I think Yoshifumi is suggesting that if the WG re-spins =C2= =A0RFC5681 then in addition to folding in discussion of ABC/RFC3465 the RFC= 5681bis=C2=A0could also include the IW10 content in RFC6928. That could hel= p save time in avoiding promoting RFC6928 from experimental to proposed sta= ndard.

That sounds reasonable to me as well. Althoug= h the initial window is a somewhat independent issue that might evolve inde= pendently from the congestion algorithm itself, so I can imagine advantages= to keeping it separate.

neal

=

= On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.or= g> wrote:
Sorry I don't understand your suggestion. Is that rel= ated to ABC? could you explain more

On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi= Nishida <nsd.ie= tf@gmail.com> wrote:
I don't have=C2=A0a strong opinion=C2= =A0on this yet, But, if we *could* move in this direction, it might be good= to think about the IW explanation in RFC5681 as well?
if we do t= his, we might not need to discuss promoting RFC6928.
--
Yoshi

On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell <ncardwell= =3D40googl= e.com@dmarc.ietf.org> wrote:
I also agree with Yuchung=E2=80=99s su= ggestion, for all of the reasons he provided.

best,<= /div>
neal


On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goe= l <vidhi_goel=3D40apple.com@dmarc.ietf.org> wrote:
I agree with Yuchung=E2=80=99s sugge= stion for all the reasons he provided. And its better to have it at one pla= ce.

Vidhi

On = Aug 6, 2021, at 12:53 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf= .org> wrote:

Hi WG

I=C2=A0have=C2=A0been wondering if we (=3D IETF) should just update R= FC5681 directly, instead of another RFC3465-bis with experimental status.

Appropriate byte counting is essential but the RFC5= 681 of L=3D1 is detrimental. There are far more people who read RFC5681 to = implement the new stack instead of RFC3465. So we should fold the experimen= tal RFC3465 updates into RFC5681 directly, and obsolete RFC3465.

This is orthogonal=C2=A0to the final value of L :-)




On Tue, Aug 3, 2021 at 9:42= AM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug 2, 202= 1 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:

On Mon, = Aug 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org&= gt; wrote:


On Mon, Aug 2, 2021 at 8:46 PM Praveen Bal= asubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, = values over L=3D8 resulted in a noticeable increase in packet drops and ret= ransmissions (without pacing). Windows TCP has been using L=3D8 for many ye= ars now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0=

Neal, are there cases where Linux is or can be d= eployed with infinite L and no pacing?

Yes, "infinite L and no pacing" is the default behavi= or for Linux TCP, starting in 2013 for slow-start and then starting in 2015= for congestion avoidance.
To be more cl= ear: both fq_pacing and TCP pacing have been disabled by default in Linux u= pstream. We do not know how much Linux senders enable them today besides th= e Google servers.

Regarding L =3D 8, to avoid anot= her round of why or why not. We could say inf-L causes line-rate burst up t= o the stretched ACK degree so put a comfortable L if you prefer, then menti= on implementation practice like yours. At the end of the day it's ad-ho= c (or "art") and subject to change. It might be sensible to cap a= t cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of = ACKs.
Sorry please ignore my previou= s message about the cwnd cap. It is completely unnecessary -- since with ac= k-clocking and appropriate counting, a correct sender would never release m= ore than a cwnd-worth of data. I was imagining the multiple application-lim= ited burst could let the receiver keep holding up ACKs, but that can never = exceed a cwnd worth of data.
=C2=A0
=

=C2= =A0
Yuchung pasted the URLs for the= exact Linux commits above, which are:


But I understand that not everyone is i= n a position to read GPL-licensed code. :-)

best r= egards,
neal

=C2=A0

=C2=A0

= From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <<= a href=3D"mailto:vidhi_goel@apple.com" target=3D"_blank">vidhi_goel@apple.c= om> wrote:

=C2=A0

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <= mallman@icir.org&= gt; wrote:


> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0

to make things up.<= /u>

+1

=C2=A0

Yes, I agree that would be a great approach to = take.

=C2=A0

So, we are saying it is fine to ignore L compl= etely and simply increase cwnd by bytes_acked during slow start? And if thi= s causes large bursts to be sent out (when an implementation doesn=E2=80=99= t do pacing), that is fine?=C2=A0

=C2=A0

Yes, I think that is the proposal on the table,= and it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).<= /u>

=C2=A0

(2) Implementations that don't pace will ge= nerally be causing large bursts for many different reasons anyway (data and= /or ACK aggregation in the network or end hosts), restart from idle,...) so= having a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
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
--000000000000570a5005c9236b65-- From nobody Mon Aug 9 13:33: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 E6AF33A1638 for ; Mon, 9 Aug 2021 13:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_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=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 xaJKCpt8jb7a for ; Mon, 9 Aug 2021 13:33:01 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (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 D72A33A163A for ; Mon, 9 Aug 2021 13:33:01 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 179KR8wH010618; Mon, 9 Aug 2021 13:32:57 -0700 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=kF3wPcpIvxBRF9CpaVCxns8nuH8iDP+9D6IitEoYLaw=; b=BMAwuAbs2F076DX/nT78rq+PWUIE/RYMhfjsEeXwLYPziDgbjqGtmBm7LeTJEOU9t24/ qjBokZ5C4OwgwnGDVrcqJzUBLbJgey/UwHCtaZt/gcX1HXolIljdhB6tqXsBRSo7dVZ8 m/es1cm9rJt5IGM1gnTrGoiDAFZUztDDCvFpALPsgXq+xYi0BBikKQ3s04N7ew6/3/4C Qa469azwDJKs4RbqWVtmbnvewESaTHTzNd2mZqKibAeSuk14O5gvW/YsgG6j0SCQWT8y G6r8rWNR6ximoK4MYoGJMIU/ROLBDSpElK29B5+dXaWgrc3hnCLC7cQWC8S0uCj389iZ 4g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3a9p12af9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 09 Aug 2021 13:32:57 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXL00OJFAEXSZB0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Mon, 09 Aug 2021 13:32:57 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QXL00B00A1HHM00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 09 Aug 2021 13:32:57 -0700 (PDT) X-Va-A: X-Va-T-CD: 4342cc198967e1bbf37df5636e61c00f X-Va-E-CD: 0356cfd288405c7383fa735d89592edc X-Va-R-CD: 776b594e15c7bc14f32f514fb67ec3c1 X-Va-CD: 0 X-Va-ID: 06d4068f-2e17-4c8a-966b-dfa59ba7fdd0 X-V-A: X-V-T-CD: 4342cc198967e1bbf37df5636e61c00f X-V-E-CD: 0356cfd288405c7383fa735d89592edc X-V-R-CD: 776b594e15c7bc14f32f514fb67ec3c1 X-V-CD: 0 X-V-ID: 6e2743de-d660-4aa8-858f-7f1614b7899b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-09_08:2021-08-06, 2021-08-09 signatures=0 Received: from smtpclient.apple (unknown [17.11.82.71]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXL00XR5AETIR00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 09 Aug 2021 13:32:56 -0700 (PDT) From: Vidhi Goel Message-id: <54F87CD1-061E-48FE-8512-BFC0E2E4F96B@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_033730BD-F118-4B15-82A6-6793F9524119"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Mon, 09 Aug 2021 13:32:52 -0700 In-reply-to: Cc: Yuchung Cheng , "tcpm@ietf.org" , "mallman@icir.org" To: Yoshifumi Nishida , Neal Cardwell References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-09_08:2021-08-06, 2021-08-09 signatures=0 Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 20:33:09 -0000 --Apple-Mail=_033730BD-F118-4B15-82A6-6793F9524119 Content-Type: multipart/alternative; boundary="Apple-Mail=_D962A944-E2BE-4C65-AF13-2B383333F59A" --Apple-Mail=_D962A944-E2BE-4C65-AF13-2B383333F59A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I also like Yoshi=E2=80=99s suggestion to fold the initial window into = RFC5681-bis. > That sounds reasonable to me as well. Although the initial window is a = somewhat independent issue that might evolve independently from the = congestion algorithm itself, so I can imagine advantages to keeping it = separate. I think Initial Window is not independent from congestion control = module, because lets say in future with higher BDPs we decide to set = IW=3D1000, then the congestion control algorithm should be able to = immediately detect congestion, if any, even at the start of the = connection and for such a high initial value, probably requires other = ways to detect congestion besides packet loss. Yes, it is separate from how the algorithm works itself, but still = deciding the initial value depends a lot on the congestion control = algorithm. Thanks, Vidhi > On Aug 9, 2021, at 10:07 AM, Yoshifumi Nishida = wrote: >=20 > Yes, that was my intention. Sorry for being unclear. > I thought updating RFC5681 could be impactful. So, if it would happen, = I would like to make sure we won't have another update for a long time. > -- > Yoshi >=20 > On Mon, Aug 9, 2021 at 9:53 AM Neal Cardwell > wrote: > I think Yoshifumi is suggesting that if the WG re-spins RFC5681 then = in addition to folding in discussion of ABC/RFC3465 the RFC5681bis could = also include the IW10 content in RFC6928. That could help save time in = avoiding promoting RFC6928 from experimental to proposed standard. >=20 > That sounds reasonable to me as well. Although the initial window is a = somewhat independent issue that might evolve independently from the = congestion algorithm itself, so I can imagine advantages to keeping it = separate. >=20 > neal >=20 >=20 > On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng = > wrote: > Sorry I don't understand your suggestion. Is that related to ABC? = could you explain more >=20 > On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida > wrote: > I don't have a strong opinion on this yet, But, if we *could* move in = this direction, it might be good to think about the IW explanation in = RFC5681 as well? > if we do this, we might not need to discuss promoting RFC6928. > -- > Yoshi >=20 > On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell = > wrote: > I also agree with Yuchung=E2=80=99s suggestion, for all of the reasons = he provided. >=20 > best, > neal >=20 >=20 > On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel = > wrote: > I agree with Yuchung=E2=80=99s suggestion for all the reasons he = provided. And its better to have it at one place. >=20 > Vidhi >=20 >> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng = > wrote: >>=20 >> Hi WG >>=20 >> I have been wondering if we (=3D IETF) should just update RFC5681 = directly, instead of another RFC3465-bis with experimental status. >>=20 >> Appropriate byte counting is essential but the RFC5681 of L=3D1 is = detrimental. There are far more people who read RFC5681 to implement the = new stack instead of RFC3465. So we should fold the experimental RFC3465 = updates into RFC5681 directly, and obsolete RFC3465. >>=20 >> This is orthogonal to the final value of L :-) >>=20 >>=20 >>=20 >>=20 >> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng > wrote: >>=20 >>=20 >> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng > wrote: >>=20 >>=20 >> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell = > wrote: >>=20 >>=20 >> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian = > wrote: >> In experiments a few years ago on DC networks, values over L=3D8 = resulted in a noticeable increase in packet drops and retransmissions = (without pacing). Windows TCP has been using L=3D8 for many years now. = If we do want to specify a fallback L value for implementations that = cannot pace, my suggestion would be to use the value 8. >>=20 >> =20 >>=20 >> Neal, are there cases where Linux is or can be deployed with infinite = L and no pacing? >>=20 >>=20 >> Yes, "infinite L and no pacing" is the default behavior for Linux = TCP, starting in 2013 for slow-start and then starting in 2015 for = congestion avoidance. >> To be more clear: both fq_pacing and TCP pacing have been disabled by = default in Linux upstream. We do not know how much Linux senders enable = them today besides the Google servers. >>=20 >> Regarding L =3D 8, to avoid another round of why or why not. We could = say inf-L causes line-rate burst up to the stretched ACK degree so put a = comfortable L if you prefer, then mention implementation practice like = yours. At the end of the day it's ad-hoc (or "art") and subject to = change. It might be sensible to cap at cwnd to disincentivize receivers = / middle-boxes bunching up 10 rounds of ACKs. >> Sorry please ignore my previous message about the cwnd cap. It is = completely unnecessary -- since with ack-clocking and appropriate = counting, a correct sender would never release more than a cwnd-worth of = data. I was imagining the multiple application-limited burst could let = the receiver keep holding up ACKs, but that can never exceed a cwnd = worth of data. >> =20 >>=20 >> =20 >> Yuchung pasted the URLs for the exact Linux commits above, which are: >>=20 >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 = >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3D9cd981dcf174d26805a032aefa791436da709bee = >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f = >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3D814d488c61260521b1b3cc97063700a5a6667c8f = >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 = >>=20 >> But I understand that not everyone is in a position to read = GPL-licensed code. :-) >>=20 >> best regards, >> neal >>=20 >> =20 >> =20 >>=20 >> From: tcpm > On = Behalf Of Neal Cardwell >> Sent: Monday, August 2, 2021 4:18 PM >> To: Vidhi Goel > >> Cc: Extensions >; Mark Allman = > >> Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement = RFC3465 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel > wrote: >>=20 >> =20 >>=20 >> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman > wrote: >>=20 >>=20 >> > The fact is that Linux CC has long moved to infinite L since 2031, >>=20 >> So, if our experience is with L=3D\infinity and it is demonstrably OK >> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I would >> submit that it makes more sense to leverage experience than it does=20= >>=20 >> to make things up. >>=20 >> +1 >>=20 >> =20 >>=20 >> Yes, I agree that would be a great approach to take. >>=20 >> =20 >>=20 >> So, we are saying it is fine to ignore L completely and simply = increase cwnd by bytes_acked during slow start? And if this causes large = bursts to be sent out (when an implementation doesn=E2=80=99t do = pacing), that is fine?=20 >>=20 >> =20 >>=20 >> Yes, I think that is the proposal on the table, and it sounds good to = me. >>=20 >> =20 >>=20 >> A rationale would be: >>=20 >> =20 >>=20 >> (1) Implementations SHOULD pace (RFC 7661). >>=20 >> =20 >>=20 >> (2) Implementations that don't pace will generally be causing large = bursts for many different reasons anyway (data and/or ACK aggregation in = the network or end hosts), restart from idle,...) so having a constant L = does not provide enough protection from bursts to justify the cost in = reduced performance (in the form of slower slow-start). In support of = this, experience with this as the default behavior in Linux TCP over the = 2013-2021 period suggests this works well enough in practice. >>=20 >> =20 >>=20 >> neal >>=20 >> =20 >>=20 >> =20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = >=20 > _______________________________________________ > 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=_D962A944-E2BE-4C65-AF13-2B383333F59A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = also like Yoshi=E2=80=99s suggestion to fold the initial window into = RFC5681-bis.

That = sounds reasonable to me as well. Although the initial window is a = somewhat independent issue that might evolve independently from the = congestion algorithm itself, so I can imagine advantages to keeping it = separate.

I think Initial Window is not = independent from congestion control module, because lets say in future = with higher BDPs we decide to set IW=3D1000, then the congestion control = algorithm should be able to immediately detect congestion, if any, even = at the start of the connection and for such a high initial value, = probably requires other ways to detect congestion besides packet = loss.
Yes, it is separate from how the algorithm = works itself, but still deciding the initial value depends a lot on the = congestion control algorithm.

Thanks,
Vidhi

On Aug 9, 2021, at 10:07 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> = wrote:

Yes, that was my intention. Sorry = for being unclear.
I thought updating RFC5681 could = be impactful. So, if it would happen, I would like to make sure we won't = have another update for a long time.
--
Yoshi

On Mon, Aug = 9, 2021 at 9:53 AM Neal Cardwell <ncardwell@google.com> wrote:
I think = Yoshifumi is suggesting that if the WG re-spins  RFC5681 then in = addition to folding in discussion of ABC/RFC3465 the = RFC5681bis could also include the IW10 content in RFC6928. That = could help save time in avoiding promoting RFC6928 from experimental to = proposed standard.

That sounds reasonable to me as well. Although the initial = window is a somewhat independent issue that might evolve independently = from the congestion algorithm itself, so I can imagine advantages to = keeping it separate.

neal


On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng = <ycheng=3D40google.com@dmarc.ietf.org> = wrote:
Sorry I = don't understand your suggestion. Is that related to ABC? could you = explain more

On Mon, Aug 9, 2021 at 1:41 AM = Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
I don't have a strong opinion on this yet, But, if = we *could* move in this direction, it might be good to think about the = IW explanation in RFC5681 as well?
if we do this, = we might not need to discuss promoting RFC6928.
--
Yoshi

On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell = <ncardwell=3D40google.com@dmarc.ietf.org> = wrote:
I also = agree with Yuchung=E2=80=99s suggestion, for all of the reasons he = provided.

best,
neal


On Fri, Aug 6, 2021 at 3:59 PM Vidhi = Goel <vidhi_goel=3D40apple.com@dmarc.ietf.org> = wrote:
I agree with = Yuchung=E2=80=99s suggestion for all the reasons he provided. And its = better to have it at one place.

Vidhi

On Aug 6, 2021, at 12:53 PM, = Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> = wrote:

Hi = WG

I have been wondering if we (=3D IETF) should just = update RFC5681 directly, instead of another RFC3465-bis with = experimental status.

Appropriate byte counting is essential but the RFC5681 of L=3D1= is detrimental. There are far more people who read RFC5681 to implement = the new stack instead of RFC3465. So we should fold the experimental = RFC3465 updates into RFC5681 directly, and obsolete = RFC3465.

This is orthogonal to the final value of L :-)




On Tue, Aug = 3, 2021 at 9:42 AM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug = 2, 2021 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug = 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug = 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on = DC networks, values over L=3D8 resulted in a noticeable increase in = packet drops and retransmissions (without pacing). Windows TCP has been = using L=3D8 for many years now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to = use the value 8.

 

Neal, are there cases where Linux is or can be = deployed with infinite L and no pacing?


Yes, "infinite L and no = pacing" is the default behavior for Linux TCP, starting in 2013 for = slow-start and then starting in 2015 for congestion = avoidance.
To be more = clear: both fq_pacing and TCP pacing have been disabled by default in = Linux upstream. We do not know how much Linux senders enable them today = besides the Google servers.

Regarding L =3D 8, to avoid another round of why or why not. = We could say inf-L causes line-rate burst up to the stretched ACK degree = so put a comfortable L if you prefer, then mention implementation = practice like yours. At the end of the day it's ad-hoc (or "art") and = subject to change. It might be sensible to cap at cwnd to disincentivize = receivers / middle-boxes bunching up 10 rounds of ACKs.
Sorry please = ignore my previous message about the cwnd cap. It is completely = unnecessary -- since with ack-clocking and appropriate counting, a = correct sender would never release more than a cwnd-worth of data. I was = imagining the multiple application-limited burst could let the receiver = keep holding up ACKs, but that can never exceed a cwnd worth of = data.
 

 
Yuchung = pasted the URLs for the exact Linux commits above, which are:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D9cd981dcf174d26805a032aefa791436da709bee
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930
<= div class=3D"">
But I understand = that not everyone is in a position to read GPL-licensed code. = :-)

best = regards,
neal

 

 

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t = implement RFC3465

 

 

 

On Mon, Aug 2, 2021 at 7:02 PM = Vidhi Goel <vidhi_goel@apple.com> wrote:

 

On Mon, Aug 2, 2021 at 3:37 PM = Mark Allman <mallman@icir.org> wrote:


> The fact is that Linux CC has long moved to infinite L since = 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?  I = would
submit that it makes more sense to leverage experience than it = does 

to make things up.

+1

 

Yes, I agree that would be a = great approach to take.

 

So, we are saying it is fine to ignore L = completely and simply increase cwnd by bytes_acked during slow start? = And if this causes large bursts to be sent out (when an implementation = doesn=E2=80=99t do pacing), that is fine? 

 

Yes, I think that is the proposal = on the table, and it sounds good to me.

 

A rationale would be:

 

(1) Implementations SHOULD pace = (RFC 7661).

 

(2) Implementations that don't = pace will generally be causing large bursts for many different reasons = anyway (data and/or ACK aggregation in the network or end hosts), = restart from idle,...) so having a constant L does not provide enough protection from bursts to justify the cost in reduced = performance (in the form of slower slow-start). In support of this, = experience with this as the default behavior in Linux TCP over the  = 2013-2021 period suggests this works well enough in practice.

 

neal

 

 

_______________________________________________
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

= --Apple-Mail=_D962A944-E2BE-4C65-AF13-2B383333F59A-- --Apple-Mail=_033730BD-F118-4B15-82A6-6793F9524119 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgwOTIw MzI1MlowLwYJKoZIhvcNAQkEMSIEIBJN0iJOjmU9dGgU3xip7IbvpdozYjk1SO36Q77TZpLRMIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAFd7EpHz/J84hCORvs6fQ3LIoO0mPkhEsvfzBGIOBSF5bBlS59wcq67N eXTyrdei9UXmG9cFonZ/6/JhhQdOVgZB7jcjXWBWZlv2WnHu4icjfh6MexZnh8TAtqd/JUiVlhi8 ehneuZxWGgpiJ/35l9ClxFmf+olCSzUCgyP3zuItufp78cZrIWRfqE5BjK7GMg+b98evgbiLsDN4 q+r1ji50KELwNrw/MugJ2k+QPeTHSlow4VghxfGnyN7Fyo5xQR+1X9Y5/2ttfpm8a3xKVr47BrA+ DzzNyzXtOV9DlRKr5rMTtdIjWR2pfJowE1VEr3xJO4UlQxOs4/iDzhf1QlQAAAAAAAA= --Apple-Mail=_033730BD-F118-4B15-82A6-6793F9524119-- From nobody Mon Aug 9 13:48:21 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 C5F663A16AF for ; Mon, 9 Aug 2021 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrRO7LO_wyne for ; Mon, 9 Aug 2021 13:48:14 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 EE21F3A16C9 for ; Mon, 9 Aug 2021 13:48:13 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id h24-20020a1ccc180000b029022e0571d1a0so912084wmb.5 for ; Mon, 09 Aug 2021 13:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hFI3TtC4ZkCQrc0clo/4IAUbSLubwMLaHCMSZqUpK1w=; b=nFKV+9Cht9wUZGvtMyG0TjMjZT8ySuvsdu6qbA9Z1Kg9neZOHz5eAjr/qNSOU3hNPO HkQ25e3wKeg9CvNlLPwx8rtf/sEA3q5cW9yltiqgX+4iu7DZ0vdKkMoWuYQaITfMVpU/ RLwuJYuw7hltCCFoe4Z89UYiHyXOXqU+p5PKbVjxjI22e//dpJVHdFLD7Ohgq2mPhA3h LiN5faIFbJ2QG09Z0DxaMvNqTg93shNAg9IICbhyYuB8QMmm7yqa1BUeJyl33gnrkBsG 0O2Dvj34Ypm3hIWcze4ra11NQ2H7Rlsi6pra5D6zzMssoTBSoWR3dzRJqYZ1E7hMfWeh hC9A== 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=hFI3TtC4ZkCQrc0clo/4IAUbSLubwMLaHCMSZqUpK1w=; b=kfda4L8c8iLEr5Tb/v39o82E7Tdl7GhzEivtn0ZNOT7xOwxKQpkizFAaGAieNwpXki SOuv03Jzej9UA/aGR/0xJgKDnDJ06KynQeiQHbnjQoMEOLPPKOdkTZXLF3vtKXd6wgvj 61/9KZt3l/BkKzHbJXTY4Rz8HXBJyqKFHNH+eRrhPkZPlHGNWAG09uhMOlT8lj4rFydg OVBeGLen06dPtt2Qt28KGOJUdLNLT7sN7EkCEi2yXe/8zlWzBTr2oWfoFCEd05aUJoSt DulLdLkk8nQX8xI0rCkx4UrLvHQxXFup9G346BpJCuy1mCgC89jYbU5JuqbhhNWJhsoO et2Q== X-Gm-Message-State: AOAM530j1TcJ4g5+vneUlP4LTkA/xJciRfBbs8/sRaNhKNUcE2ngylUe 662dNCFYE3vbfiooqO4ESabJKu7BR+ljSJ1x53W3hQ== X-Google-Smtp-Source: ABdhPJxcrlwxdJHu5noeQS7xiToCUYpZYWqgvsuF/7FG3rzTs+tlDStXekxMkVctYgqwuzmF88p3IVxUL1zq+upPVTg= X-Received: by 2002:a05:600c:4145:: with SMTP id h5mr347765wmm.7.1628542087196; Mon, 09 Aug 2021 13:48:07 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <13E800C6-8113-451E-9604-D67C6D45A5DF@apple.com> <54F87CD1-061E-48FE-8512-BFC0E2E4F96B@apple.com> In-Reply-To: <54F87CD1-061E-48FE-8512-BFC0E2E4F96B@apple.com> From: Yuchung Cheng Date: Mon, 9 Aug 2021 13:47:29 -0700 Message-ID: To: Vidhi Goel Cc: Yoshifumi Nishida , Neal Cardwell , "tcpm@ietf.org" , "mallman@icir.org" Content-Type: multipart/alternative; boundary="0000000000009c8f9105c9268009" Archived-At: Subject: Re: [tcpm] =?utf-8?q?=5BEXTERNAL=5D_Re=3A_Linux_doesn=E2=80=99t_impl?= =?utf-8?q?ement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 20:48:20 -0000 --0000000000009c8f9105c9268009 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to Yoshifumi's proposal as well. On Mon, Aug 9, 2021 at 1:33 PM Vidhi Goel wrote: > I also like Yoshi=E2=80=99s suggestion to fold the initial window into RF= C5681-bis. > > That sounds reasonable to me as well. Although the initial window is a >> somewhat independent issue that might evolve independently from the >> congestion algorithm itself, so I can imagine advantages to keeping it >> separate. >> > > I think Initial Window is not independent from congestion control module, > because lets say in future with higher BDPs we decide to set IW=3D1000, t= hen > the congestion control algorithm should be able to immediately detect > congestion, if any, even at the start of the connection and for such a hi= gh > initial value, probably requires other ways to detect congestion besides > packet loss. > Yes, it is separate from how the algorithm works itself, but still > deciding the initial value depends a lot on the congestion control > algorithm. > > Thanks, > Vidhi > > On Aug 9, 2021, at 10:07 AM, Yoshifumi Nishida wrote= : > > Yes, that was my intention. Sorry for being unclear. > I thought updating RFC5681 could be impactful. So, if it would happen, I > would like to make sure we won't have another update for a long time. > -- > Yoshi > > On Mon, Aug 9, 2021 at 9:53 AM Neal Cardwell wrote= : > >> I think Yoshifumi is suggesting that if the WG re-spins RFC5681 then in >> addition to folding in discussion of ABC/RFC3465 the RFC5681bis could al= so >> include the IW10 content in RFC6928. That could help save time in avoidi= ng >> promoting RFC6928 from experimental to proposed standard. >> >> That sounds reasonable to me as well. Although the initial window is a >> somewhat independent issue that might evolve independently from the >> congestion algorithm itself, so I can imagine advantages to keeping it >> separate. >> >> neal >> >> >> On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng > 40google.com@dmarc.ietf.org> wrote: >> >>> Sorry I don't understand your suggestion. Is that related to ABC? could >>> you explain more >>> >>> On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida >>> wrote: >>> >>>> I don't have a strong opinion on this yet, But, if we *could* move in >>>> this direction, it might be good to think about the IW explanation in >>>> RFC5681 as well? >>>> if we do this, we might not need to discuss promoting RFC6928. >>>> -- >>>> Yoshi >>>> >>>> On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell >>> 40google.com@dmarc.ietf.org> wrote: >>>> >>>>> I also agree with Yuchung=E2=80=99s suggestion, for all of the reason= s he >>>>> provided. >>>>> >>>>> best, >>>>> neal >>>>> >>>>> >>>>> On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel >>>> 40apple.com@dmarc.ietf.org> wrote: >>>>> >>>>>> I agree with Yuchung=E2=80=99s suggestion for all the reasons he pro= vided. >>>>>> And its better to have it at one place. >>>>>> >>>>>> Vidhi >>>>>> >>>>>> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng < >>>>>> ycheng=3D40google.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Hi WG >>>>>> >>>>>> I have been wondering if we (=3D IETF) should just update RFC5681 >>>>>> directly, instead of another RFC3465-bis with experimental status. >>>>>> >>>>>> Appropriate byte counting is essential but the RFC5681 of L=3D1 is >>>>>> detrimental. There are far more people who read RFC5681 to implement= the >>>>>> new stack instead of RFC3465. So we should fold the experimental RFC= 3465 >>>>>> updates into RFC5681 directly, and obsolete RFC3465. >>>>>> >>>>>> This is orthogonal to the final value of L :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell >>>>>>> 40google.com@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian >>>>>>>> 40microsoft.com@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>>> In experiments a few years ago on DC networks, values over L=3D8 >>>>>>>>>> resulted in a noticeable increase in packet drops and retransmis= sions >>>>>>>>>> (without pacing). Windows TCP has been using L=3D8 for many year= s now. If we >>>>>>>>>> do want to specify a fallback L value for implementations that c= annot pace, >>>>>>>>>> my suggestion would be to use the value 8. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Neal, are there cases where Linux is or can be deployed with >>>>>>>>>> infinite L and no pacing? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, "infinite L and no pacing" is the default behavior for Linux >>>>>>>>> TCP, starting in 2013 for slow-start and then starting in 2015 fo= r >>>>>>>>> congestion avoidance. >>>>>>>>> >>>>>>>> To be more clear: both fq_pacing and TCP pacing have been disabled >>>>>>>> by default in Linux upstream. We do not know how much Linux sender= s enable >>>>>>>> them today besides the Google servers. >>>>>>>> >>>>>>>> Regarding L =3D 8, to avoid another round of why or why not. We co= uld >>>>>>>> say inf-L causes line-rate burst up to the stretched ACK degree so= put a >>>>>>>> comfortable L if you prefer, then mention implementation practice = like >>>>>>>> yours. At the end of the day it's ad-hoc (or "art") and subject to= change. >>>>>>>> It might be sensible to cap at cwnd to disincentivize receivers / >>>>>>>> middle-boxes bunching up 10 rounds of ACKs. >>>>>>>> >>>>>>> Sorry please ignore my previous message about the cwnd cap. It is >>>>>>> completely unnecessary -- since with ack-clocking and appropriate c= ounting, >>>>>>> a correct sender would never release more than a cwnd-worth of data= . I was >>>>>>> imagining the multiple application-limited burst could let the rece= iver >>>>>>> keep holding up ACKs, but that can never exceed a cwnd worth of dat= a. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Yuchung pasted the URLs for the exact Linux commits above, which >>>>>>>>> are: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/commit/?id=3D9f9843a751d0a2057f9f3d313886e7e5e6ebaac9 >>>>>>>>> >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/commit/?id=3D9cd981dcf174d26805a032aefa791436da709bee >>>>>>>>> >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/commit/?id=3Dc22bdca94782f05b9337d8548bde51b2f38ef17f >>>>>>>>> >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/commit/?id=3D814d488c61260521b1b3cc97063700a5a6667c8f >>>>>>>>> >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/commit/?id=3De73ebb0881ea5534ce606c1d71b4ac44db5c6930 >>>>>>>>> >>>>>>>>> But I understand that not everyone is in a position to read >>>>>>>>> GPL-licensed code. :-) >>>>>>>>> >>>>>>>>> best regards, >>>>>>>>> neal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* tcpm *On Behalf Of * Neal >>>>>>>>>> Cardwell >>>>>>>>>> *Sent:* Monday, August 2, 2021 4:18 PM >>>>>>>>>> *To:* Vidhi Goel >>>>>>>>>> *Cc:* Extensions ; Mark Allman >>>>>>>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement= RFC3465 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > The fact is that Linux CC has long moved to infinite L since >>>>>>>>>> 2031, >>>>>>>>>> >>>>>>>>>> So, if our experience is with L=3D\infinity and it is demonstrab= ly >>>>>>>>>> OK >>>>>>>>>> why don't we say *THAT* instead of "make L=3D5 or L=3D10"? I wo= uld >>>>>>>>>> submit that it makes more sense to leverage experience than it >>>>>>>>>> does >>>>>>>>>> >>>>>>>>>> to make things up. >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, I agree that would be a great approach to take. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So, we are saying it is fine to ignore L completely and simply >>>>>>>>>> increase cwnd by bytes_acked during slow start? And if this caus= es large >>>>>>>>>> bursts to be sent out (when an implementation doesn=E2=80=99t do= pacing), that is >>>>>>>>>> fine? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, I think that is the proposal on the table, and it sounds >>>>>>>>>> good to me. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A rationale would be: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (1) Implementations SHOULD pace (RFC 7661). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (2) Implementations that don't pace will generally be causing >>>>>>>>>> large bursts for many different reasons anyway (data and/or ACK = aggregation >>>>>>>>>> in the network or end hosts), restart from idle,...) so having a= constant L >>>>>>>>>> does not provide enough protection from bursts to justify the co= st in >>>>>>>>>> reduced performance (in the form of slower slow-start). In suppo= rt of this, >>>>>>>>>> experience with this as the default behavior in Linux TCP over t= he >>>>>>>>>> 2013-2021 period suggests this works well enough in practice. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> neal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> >>> > --0000000000009c8f9105c9268009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to Yoshifumi's proposal as well.

=


On Mon, Aug 9, 2021 at 1:33 PM Vidhi Goel <vidhi_goel=3D= 40apple.com= @dmarc.ietf.org> wrote:
I also like Yoshi=E2=80=99s suggestion to fold the init= ial window into RFC5681-bis.

<= div dir=3D"ltr">
That sounds reasonable to me as wel= l. Although the initial window is a somewhat independent issue that might e= volve independently from the congestion algorithm itself, so I can imagine = advantages to keeping it separate.

I think Initial Window is not independent from cong= estion control module, because lets say in future with higher BDPs we decid= e to set IW=3D1000, then the congestion control algorithm should be able to= immediately detect congestion, if any, even at the start of the connection= and for such a high initial value, probably requires other ways to detect = congestion besides packet loss.
Yes, it is separate from how the = algorithm works itself, but still deciding the initial value depends a lot = on the congestion control algorithm.

Thanks,
=
Vidhi

On Aug 9, 2021, at 10= :07 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

Yes, that was my intention. Sorry for being unclear.
I tho= ught updating RFC5681 could be impactful. So, if it would happen, I would l= ike to make sure we won't have another update=C2=A0for a long time.
--
Yoshi

On Mon, Aug 9, 2021 at 9:53 AM Neal Cardwell <<= a href=3D"mailto:ncardwell@google.com" target=3D"_blank">ncardwell@google.c= om> wrote:
I think Yoshifumi is suggesting that if the WG re-spins = =C2=A0RFC5681 then in addition to folding in discussion of ABC/RFC3465 the = RFC5681bis=C2=A0could also include the IW10 content in RFC6928. That could = help save time in avoiding promoting RFC6928 from experimental to proposed = standard.

That sounds reasonable to me as well. Alth= ough the initial window is a somewhat independent issue that might evolve i= ndependently from the congestion algorithm itself, so I can imagine advanta= ges to keeping it separate.

neal


On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf= .org> wrote:
Sorry I don't understand your suggestion. Is that = related to ABC? could you explain more

=
On Mon, Aug 9, 2021 at 1:41 AM Yoshif= umi Nishida <nsd= .ietf@gmail.com> wrote:
I don't have=C2=A0a strong opinion= =C2=A0on this yet, But, if we *could* move in this direction, it might be g= ood to think about the IW explanation in RFC5681 as well?
if we d= o this, we might not need to discuss promoting RFC6928.
--
<= div>Yoshi

On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell <ncardw= ell=3D40go= ogle.com@dmarc.ietf.org> wrote:
I also agree with Yuchung=E2=80=99s= suggestion, for all of the reasons he provided.

bes= t,
neal


=
On Fri, Aug 6, 2021 at 3:59 PM Vidhi = Goel <vidhi_goel=3D40apple.com@dmarc.ietf.org> wrote:
I agree with Yuchung=E2=80=99s s= uggestion for all the reasons he provided. And its better to have it at one= place.

Vidhi

On Aug 6, 2021, at 12:53 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.= ietf.org> wrote:

Hi WG

=
I=C2=A0have=C2=A0been wondering if we (=3D IETF) should just upda= te RFC5681 directly, instead of another RFC3465-bis with experimental statu= s.

Appropriate byte counting is essential but the = RFC5681 of L=3D1 is detrimental. There are far more people who read RFC5681= to implement the new stack instead of RFC3465. So we should fold the exper= imental RFC3465 updates into RFC5681 directly, and obsolete RFC3465.
<= /div>

This is orthogonal=C2=A0to the final value of L :-= )




On Tue, Aug 3, 2021 at = 9:42 AM Yuchung Cheng <ycheng@google.com> wrote:


On Mon, Aug 2,= 2021 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:


On M= on, Aug 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org<= /a>> wrote:
<= div dir=3D"ltr">


<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 2, 2021 at 8:46 PM Praveen= Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

In experiments a few years ago on DC networks, = values over L=3D8 resulted in a noticeable increase in packet drops and ret= ransmissions (without pacing). Windows TCP has been using L=3D8 for many ye= ars now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to us= e the value 8.

=C2=A0=

Neal, are there cases where Linux is or can be d= eployed with infinite L and no pacing?

Yes, "infinite L and no pacing" is the default behavi= or for Linux TCP, starting in 2013 for slow-start and then starting in 2015= for congestion avoidance.
To be more cl= ear: both fq_pacing and TCP pacing have been disabled by default in Linux u= pstream. We do not know how much Linux senders enable them today besides th= e Google servers.

Regarding L =3D 8, to avoid anot= her round of why or why not. We could say inf-L causes line-rate burst up t= o the stretched ACK degree so put a comfortable L if you prefer, then menti= on implementation practice like yours. At the end of the day it's ad-ho= c (or "art") and subject to change. It might be sensible to cap a= t cwnd to disincentivize receivers / middle-boxes bunching up 10 rounds of = ACKs.
Sorry please ignore my previou= s message about the cwnd cap. It is completely unnecessary -- since with ac= k-clocking and appropriate counting, a correct sender would never release m= ore than a cwnd-worth of data. I was imagining the multiple application-lim= ited burst could let the receiver keep holding up ACKs, but that can never = exceed a cwnd worth of data.
=C2=A0
=

=C2= =A0
Yuchung pasted the URLs for the= exact Linux commits above, which are:


But I understand that not everyone is i= n a position to read GPL-licensed code. :-)

best r= egards,
neal

=C2=A0

=C2=A0

= From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn=E2=80=99t implement RFC34= 65

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <<= a href=3D"mailto:vidhi_goel@apple.com" target=3D"_blank">vidhi_goel@apple.c= om> wrote:

=C2=A0

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <= mallman@icir.org&= gt; wrote:


> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=3D\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=3D5 or L=3D10"?=C2= =A0 I would
submit that it makes more sense to leverage experience than it does=C2=A0

to make things up.<= /u>

+1

=C2=A0

Yes, I agree that would be a great approach to = take.

=C2=A0

So, we are saying it is fine to ignore L compl= etely and simply increase cwnd by bytes_acked during slow start? And if thi= s causes large bursts to be sent out (when an implementation doesn=E2=80=99= t do pacing), that is fine?=C2=A0

=C2=A0

Yes, I think that is the proposal on the table,= and it sounds good to me.

=C2=A0

A rationale would be:

=C2=A0

(1) Implementations SHOULD pace (RFC 7661).<= /u>

=C2=A0

(2) Implementations that don't pace will ge= nerally be causing large bursts for many different reasons anyway (data and= /or ACK aggregation in the network or end hosts), restart from idle,...) so= having a constant L does not provide enough protection from bursts to justify the cost in reduced performance=C2=A0(in= the form of slower slow-start). In support of this, experience with this a= s the default behavior in Linux TCP over the=C2=A0 2013-2021 period suggest= s this works well enough in practice.

=C2=A0

neal

=C2=A0

=C2=A0

_______________________________________________
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

--0000000000009c8f9105c9268009-- From nobody Mon Aug 9 13:53: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 C4F783A1752 for ; Mon, 9 Aug 2021 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 xpNPP7bktgCp for ; Mon, 9 Aug 2021 13:53:21 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 4D9703A172E for ; Mon, 9 Aug 2021 13:53:21 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id b13so23151026wrs.3 for ; Mon, 09 Aug 2021 13:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=owNTbNlPXVehr7gEOFq9kUT19AMlWvkQfWIWl/6ZCOk=; b=Q/U7ZlQ5BVpjlaI7100J5XKBJPY42ZPvgiNYoGikY2gnaF9R9LhEb0AVfsj8faYGo/ k2dOsu+s71YzizbDA9eWgmqiVZAdBf/woWOAIgE28pe36U9omg4hPrLli4U4yeNt499F dC3mAisGxdsheRnyBJHm3KRgTkldc+L+tWaOr7sDFu9sOWJZ3/Bh2rQswGXQMFJTY3ax jiL7AfLg1Si7YM2oI1U9UPiszz0tvVyFgC1VJLlKeiLgFvhr0Bat/JIJWt49+7mz9UQo GeodOpr98qiKcqnpoggR9zVA9ilS+wzvZkkLZAJIVRcUJI7qY8FxVSigoE9xHZz3lV14 jIfQ== 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=owNTbNlPXVehr7gEOFq9kUT19AMlWvkQfWIWl/6ZCOk=; b=t5POck6xL7wt9QZHxxvP2R8Wyt0IDQQER0DrmGsTVYsVa9rTAC3MXBMCel1XoS4TJ6 LOmY1t8b0CW7Q6vUNd8HluKYuFDG2yhsndUIzJNPo85NKa/Wl4O1Yo2Z3s6QiNkMdltR SIp4lgZ2mXycmWkZmZHKeEEE6x6pgVTBtjd3eFEbEN6cpfXsZOFFAdM5uE8dfJtCbFzh /tcoEh5reLSA7GFYEekWehuKKSHI9bDeP10DzuU0vOzHgbYDqAlY/s0cKlI/H8TFvVio DY/YEZxf3XaMxViDGHQhjG7PG9vL7W0EIs54oIu4N3NUuzf53yeWFfpj359G6me0VtbE HaoA== X-Gm-Message-State: AOAM533lc97xRcaIurrpq43IsLUuiOtcpRJ2NjtL2a5pYp+GVPibOTcs BipQ5Obo9J/nJxUiiEo+B0vbpwreLjrLZPdmy+MQsA== X-Google-Smtp-Source: ABdhPJwZ0Lzf807LGJvAg1K/ztYDR+8DB2N/6DraXzu5iohC7/zDnnl87NrHM/DFnCp7vLjqqh+HtBNQfb7NTBUUakE= X-Received: by 2002:adf:e107:: with SMTP id t7mr27174903wrz.165.1628542397754; Mon, 09 Aug 2021 13:53:17 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> In-Reply-To: <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> From: Yuchung Cheng Date: Mon, 9 Aug 2021 13:52:40 -0700 Message-ID: To: Mark Allman Cc: Neal Cardwell , Vidhi Goel , Extensions Content-Type: multipart/alternative; boundary="0000000000001f483f05c926937e" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Aug 2021 20:53:28 -0000 --0000000000001f483f05c926937e Content-Type: text/plain; charset="UTF-8" On Mon, Aug 9, 2021 at 10:05 AM Mark Allman wrote: > > > (2) Implementations that don't pace will generally be causing > > large bursts for many different reasons anyway (data and/or ACK > > aggregation in the network or end hosts), restart from idle,...) > > so having a constant L does not provide enough protection from > > bursts to justify the cost in reduced performance (in the form of > > slower slow-start). In support of this, experience with this as > > the default behavior in Linux TCP over the 2013-2021 period > > suggests this works well enough in practice. > > I think at some point someone should put some meat on the bones of > "suggests this works well enough in practice". > Good point. We could add anecdotal words on the degree of stretched ACK. Maybe we can also cite priori discussions on ACK compression / decimation a couple years ago in tcpm / tsvwg. Are there research papers on stretch ACK degrees too? > It isn't enough for linux to have implemented this. Or, even had it > turned on. E.g., if L=\infinity yet receivers ACK every other > packet then there is an effective L of 2. We see lots of people > saying this scenario isn't the prevalent scenario these days. If > that's true then it should be easy to provide a summary of > experience with L=\infinity. > > This would all just seem better with some concrete experience rather > than the quite hand wavy statements we've seen so far. > > allman > --0000000000001f483f05c926937e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 9, 2021 at 10:05 AM Mark = Allman <mallman@icir.org> wro= te:

> (2) Implementations that don't pace will generally be causing
> large bursts for many different reasons anyway (data and/or ACK
> aggregation in the network or end hosts), restart from idle,...)
> so having a constant L does not provide enough protection from
> bursts to justify the cost in reduced performance (in the form of
> slower slow-start). In support of this, experience with this as
> the default behavior in Linux TCP over the 2013-2021 period
> suggests this works well enough in practice.

I think at some point someone should put some meat on the bones of
"suggests this works well enough in practice".
Good point. We could add anecdotal words on the degree of stretched ACK.=

Maybe we can also cite priori discussions on ACK = compression / decimation a couple years ago in tcpm / tsvwg. Are there rese= arch papers on stretch ACK degrees too?


It isn't enough for linux to have implemented this.=C2=A0 Or, even had = it
turned on.=C2=A0 E.g., if L=3D\infinity yet receivers ACK every other
packet then there is an effective L of 2.=C2=A0 We see lots of people
saying this scenario isn't the prevalent scenario these days.=C2=A0 If<= br> that's true then it should be easy to provide a summary of
experience with L=3D\infinity.

This would all just seem better with some concrete experience rather
than the quite hand wavy statements we've seen so far.

allman
--0000000000001f483f05c926937e-- From nobody Tue Aug 10 08:04: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 3896C3A0E9B for ; Tue, 10 Aug 2021 08:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (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 nefk6jSI8wow for ; Tue, 10 Aug 2021 08:04:11 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47513A0E8E for ; Tue, 10 Aug 2021 08:04:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 87B6A25A1C for ; Tue, 10 Aug 2021 17:04:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1628607844; bh=0PuF21IGmPuantER80ZL7c7ROm+ZROPViOS93g/Nom0=; h=From:To:Subject:Date:From; b=IP3QfooruV5hmoUn3rt1TMo/TfApsnXWcwo8iT5VbJYRt+NG4e93uQ9ogvwaVBN2M 8UVV/Htu6ViH4DODllfWJLDF8pRV3YsHwt3Vn64YbRXUjn0KXhz9RurRx5s2350FGc TRZCsGm4em4n9pGSsLjaZgR1+4AZXv2wg5QbFTO0= 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 eelu3NjY_7AG for ; Tue, 10 Aug 2021 17:04:03 +0200 (CEST) Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Tue, 10 Aug 2021 17:04:03 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Tue, 10 Aug 2021 17:04:03 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Tue, 10 Aug 2021 17:04:03 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: (Prototype) running code for draft-ietf-tcpm-yang-tcp Thread-Index: AdeN+PTyzHCWbntdSMGiO//yz2xyhg== Date: Tue, 10 Aug 2021 15:04:03 +0000 Message-ID: <02263da169f247818bbeafd80326190b@hs-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] (Prototype) running code for draft-ietf-tcpm-yang-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: Tue, 10 Aug 2021 15:04:17 -0000 Hi all, As already mentioned in the past, Martin Mager and Simon Bauer have develop= ed a NETCONF server for the YANG model defined in draft-ietf-tcpm-yang-tcp.= This prototype implementation was developed during a student research proj= ect at the University of Applied Sciences in Esslingen.=20 The used operating systems are Ubuntu Linux and QNX. Not implemented are at= tributes related to TCP-AO (and MD5). The source code is now public: https://github.com/mager-m/ietf-tcp-research= -project Best regards Michael From nobody Tue Aug 10 08:55:41 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 DE8473A113E for ; Tue, 10 Aug 2021 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4BgZtmgLL7vE for ; Tue, 10 Aug 2021 08:55:34 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::615]) (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 0FAEC3A1209 for ; Tue, 10 Aug 2021 08:55:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iPGwF3PsRXJaQHZ18E3Le+R8hSIJMa6Z0b37XqBKwOtIUi57z0oTNhdJylXdxZ5cut4HK6bY9gAG2/CEyXZplvLJqcMLsqqA2ugz9S0tAF8ATgbbLp/Q3z0iNg9dOxvYEo9e72fC4o2Ot8DPfRpYmPWPzZDmKhXBR+XHI/5SrXBLuaJvfQ3fS+fcDUxUsXeJ/UXCsc7xsIUo32+0pfT70R95b7jEZwL3GJTa2saCkMhfNHthrXvmwwBpNBu0CjqWrZTU1r2k+ZoZr573H3y8+U2utBAGkSQcxM/wfHWm1FtJkjiAka59T8NSfn7enyLAZ0YVfmvNbce0odR4PLnh+A== 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=XAjerxfKuJJzOh01N/VaKEGjQ14zs03Fh1mvMF9F82g=; b=MRUtrL+1va5ISMqNpuxRmUt65tkEtm/VlKu/G0Rq/qH0IpXiTAzKScRlJaZ12Yv91IMQcPRNzg1dJu7qCgWeDqYQgExllNKN9rpPtC1ILgbajCWGknthjrfE56nRlwUKdeN5C49aAsqQn5VNwFg3D/rnWxCIF3ahiIhQFnIbAWwcMxDHkgjmjechJznQNaiKV1yhUfDgn/mPq7Cbnc3Vz5VZYnIUaDTRbQlZSzsP5LpAWthXj535AdZ+mqQ+lGbpVBhMFUrE7aW5pFlYqBOUrD+owUZ51A8N3hcB5I2GrCVre2R4KIRQc9aJMgxpeG+kuSLj0zvfBETHuDp/mqY9yg== 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=XAjerxfKuJJzOh01N/VaKEGjQ14zs03Fh1mvMF9F82g=; b=il9v6X2tDt/wj0dQkBpJ5WKP3IsXVzeQQqwwqOOhrmK0d24yQ0EUqyPfwzXTcBRoLwUV7LFKIxr3DerCKbUpMl4BuDOLOG7GXm3rZGzp5UwNBQYoN1zWw7aNFbOukWsrn+8KFJ1fJ49CSF9YVlKEPDQJMI/lIfMcvyQJNMqvc60= Received: from PAXPR07MB7806.eurprd07.prod.outlook.com (2603:10a6:102:13a::19) by PR3PR07MB6636.eurprd07.prod.outlook.com (2603:10a6:102:60::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.10; Tue, 10 Aug 2021 15:55:30 +0000 Received: from PAXPR07MB7806.eurprd07.prod.outlook.com ([fe80::38f5:4ee6:4b7e:62ce]) by PAXPR07MB7806.eurprd07.prod.outlook.com ([fe80::38f5:4ee6:4b7e:62ce%8]) with mapi id 15.20.4415.013; Tue, 10 Aug 2021 15:55:30 +0000 From: Mirja Kuehlewind To: Yuchung Cheng , Mark Allman CC: Extensions Thread-Topic: =?utf-8?B?W3RjcG1dIExpbnV4IGRvZXNu4oCZdCBpbXBsZW1lbnQgUkZDMzQ2NQ==?= Thread-Index: AQHVlCWT4RoDQdZBzUWpFjHFl22kjqd9ODKAgArkU4CAFwRfAIO9oXwAgAEDaQCAAA//gIAAB8mAgAAUVACAAFPagIAAB+kAgABHYACABdPzgIAAQpAAgAAJ+YCAAAJpgIAAAxWAgAABgICAAASRgIAKmCuAgAA/cgCAAWDUgA== Date: Tue, 10 Aug 2021 15:55:29 +0000 Message-ID: <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eaeda8a0-abdb-497a-d324-08d95c174752 x-ms-traffictypediagnostic: PR3PR07MB6636: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y69CIfyEBYU48AMfj5DzsA9+hJQu7syo1FgzDTBsWgYIdxWH/vndYvgGWAvVHpvO3hx+TKuNPa3aIkfe7qxw53LbJackqrOUDvJ518blsbQ+RnkxvEt5qycgjleTCTQuGIRqxAUgwKowwmXvsCQgIFbYrA3wwpvWxksQh7AtIAjK7eN/1ZpqfOuqVXQ5aTpxY44AVXFr/PhbuV/DsL4Fxg7Jl5RwRHMY0TPXVnw2pWViV7fUE+yO1awQpht0AlIlNWIdAs6r+Wt7RloIiHuNIcx9SA6qfWGY/zfhHXsj6GFQ+WQbNB8MO1kzVRlnTUODZAz48kF+8UzNR9MLdwmmgiTg8umCwzDzdanR5YkMCphJDGrXf8bWmtCj7WTbbDiERmlv5w8f11cP/FyvyFASE2NAoSoGg64pZsmZnS4IVKwwv0hxiAUO6fb8N9cUOCy245mlHfC2xT4Ay+xXJthk58SH+weW764a1xPTeEl+MPLsCg653ABvByiEDC5V3xZyaEuJaw1aDtwJ/hO30YIpjQxmJzK6p9jpjn4AOMrG4ZmG3bxH2a60rht3nEqWh+eTYYM23w2h2av9bPoqMQAbr0DzuTwB+YZscDnXR2Lv47TO/pNH29O1JVPKM0JpdxZrMB/FnumWy3lkrqQqLtmqHCJ0P3qQFbAXzAG6aRvw3Eq5evsBwN2yAYkW26M3fQdFGf0FakrkYk3EjAYxZL9Gb/9JPILD/2fNwNUVgpCBNVfCC/6lkWx2UvorkQimlblObhCS76IWXMg2SCAY+4BYNJLXZXqjIZvDEMTe6zFE59P5YDtgbqg6bMARaOcyEpEV x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAXPR07MB7806.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(66476007)(66556008)(66946007)(76116006)(66446008)(64756008)(166002)(86362001)(5660300002)(36756003)(122000001)(33656002)(38100700002)(186003)(2906002)(38070700005)(316002)(110136005)(8936002)(6486002)(2616005)(966005)(44832011)(508600001)(6512007)(6506007)(4326008)(53546011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?d0VHQWNGWWJBd29XRDBlallvY1lBWEhzTEI1azBzVWUvYnR0cXZvbnNDVTlm?= =?utf-8?B?MTZQUDFNWU40QVFRTkpKcStsb2lDcS81R1Y5Q3lkN3QvM2lBTzZVR2pxZFF5?= =?utf-8?B?a0pzVWs1VTljK0xhSjVTbEFTbHZFZHRSdlF4QlcxNFA5ZDd4cS9XVndORWRi?= =?utf-8?B?cEdXdkM1cDkwQlpjaGFKTGxnOENBSjVvWDI3aWRJSzBVNzBuUTFVN1BMRUF1?= =?utf-8?B?WHB0MzZTSHQrUUtFWjNLanY2QWxKemZOYjVUSjZ5TFR1WExMQTN5REdHZnBh?= =?utf-8?B?RDM2SVdWWVdPaXFVbXlJaWFqS2tnWmFJalpPTGxYTHMyUjFUZXFHUXdOUmhz?= =?utf-8?B?NitDZFB2aUFLZ3A3MkI2MkczRHYwcTdRN0RCd3R6dnBWM2NMUmpiVUNpT0s2?= =?utf-8?B?czRQSnd2ZkpSZ1g5dHZXemZlbk5TaWtqVlEzZzJVSC9LVUtSZHNGVzJVVkkr?= =?utf-8?B?U1ZiZG44RFRYTjhaLzI4ZU9wUzlJaGVYK25uS2FsbVZNRWRRTUp6VG9ZdWZj?= =?utf-8?B?K2ZueldLSDJ0Zm5GczBlengzVlVjdkxMaVI5dFBScHVtQ1Y0NDcyaitVTnM3?= =?utf-8?B?SmZ1TFJCVVNWbTN6aGNhRFhOS2ZCU29xd25uMUdVOHhsSkxlMWVvWmFJUkZC?= =?utf-8?B?cWc0elZEczN5QnFFT2dvN0JzdVhMVHljdWFXbFFZU2xCSlpDTytidXV6cHlw?= =?utf-8?B?eUNncUlJNUlBN1FFQkE2STZtVzF4VWt4RkYxWVNpRjcxcDN2WVJuZitpcHBJ?= =?utf-8?B?YkY5Z21UMHBjVjZML3JGam40RUE4aWJDZ1ZtN3BkS1Q2SmpwNHhDMzloZnpZ?= =?utf-8?B?VC9BV0VXaDQxK0xHUGJTeFk3YjM2M3V3ZTZaWE90clJtNHoxWVRUanRvaEZq?= =?utf-8?B?c1AxMVBEd1Y4RGdDaUMrUG1HcTVTTkxQV3FWRTNFRi9BTFNRUGUvNkFpa0Nu?= =?utf-8?B?d2Y3Y0psMzRkczkvdGRmZG91ZTRpZlVEc0VodjdCU2hNdFlSY0txVDFCbml3?= =?utf-8?B?ODRxcXRFMDUvYUZyZi9tQzZjb2dyMzNjWTVZQkpPQXJObEVqOU1WYXNKWmps?= =?utf-8?B?dkpGTXl0NHRqKzI3M1VwM0NwcUFnYzdPY25QRWhjSWhWcDJNeWpWYVAxUUVJ?= =?utf-8?B?c3g4b1JwV1c3L1F5dG90dDdKQXF4b0dCdkRmV25rTVpUMjRnNWxUV05PeEZI?= =?utf-8?B?Vkc4ZlI2SnlIWFlPYWlBSTYyYzZqT0l5cDA5Qk5TMi9wT2lyUXNkQURqNWtH?= =?utf-8?B?MW5jeUx3elhxT215RE9keEZGM25NUGNvc2dwYnJXMEhtcUN1UFQwaWxNaWpx?= =?utf-8?B?eGdZaW1EcjhTdzdWWVJMY1hlME9BazE4bkRwYU1UTXUycnhUdnc3Sk9SUTQw?= =?utf-8?B?ajlZVGh1REkxZ2JNMGxGL0ErenVnZmpZcFRST1UyRXQ5RUZIa1ExU1VjcFBi?= =?utf-8?B?QU5veHN6bjE3NC9KZnpmYlVBRWEwTkJzbUFLWkJTekF0Y3JUM1RyeWxSTzVL?= =?utf-8?B?cDJ1cWJRR3BQZEJ0SEhoc1pCM2pZSVhIdWRNZVZkVHJ0Q1RBMC9jM2RlU2lV?= =?utf-8?B?N0x1c2ZkSldBWkdHNUtBam1VRE9UZHo4cmhNZWNaMDZUQ1VrR24rU1FlOXNR?= =?utf-8?B?V1d1cFlmQ0VwTUc0dnQ1R3RUR0lKWk0vcVBTbUxPbmZCTVgwZlhZQW44Tlpy?= =?utf-8?B?ZEIxSkpCWnNjR2Z6WTJRd2poOW44enUreCtMVkQ3MFpHWnRhcSt5aUl2aHRw?= =?utf-8?B?amYyVEJnWlI1eUYyV2dVN3B3NkJaYktxMUMxeDFIek9uWi9TajFER3puWi9D?= =?utf-8?B?R29NOFhnU3hUSUNwcmM5OEN5bUtHVnFZMWxhd1dTSFJGVzlGVVAwOFpSQTdu?= =?utf-8?Q?QxWCfhnlj/dH8?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4A5AA064CAC943198E42463B3E1FAA1Eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAXPR07MB7806.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eaeda8a0-abdb-497a-d324-08d95c174752 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 15:55:29.9194 (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: HQQ59Upnh15vuP7RNZJq9e/rF6jgjBqddjMR7ycmS4DIyg0+m08kEiYzEYFMA8lDlHR1NI+2d2BbgV1Hp1RK/MVBP6zFZtVI2nFyVZRPBn4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB6636 Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 10 Aug 2021 15:55:40 -0000 --_000_4A5AA064CAC943198E42463B3E1FAA1Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2lnY29tbSBwYXBlciBmcm9tIDIwMTU6DQoNCmh0dHA6Ly93d3cuc2lnY29tbS5vcmcvc2l0ZXMv ZGVmYXVsdC9maWxlcy9jY3IvcGFwZXJzLzIwMTUvSnVseS8wMDAwMDAwLTAwMDAwMDIucGRmDQoN ClRoZXnigJl2ZSBvYnNlcnZlZCAxMS0yMiUgb2YgY29ubmVjdGlvbnMgd2l0aCBzdHJldGNoZWQg QUNLcywgYWNr4oCZaW5nIG1vc3RseSB1cCB0byA2IHBhY2tldHPigKYuDQoNCg0KDQpGcm9tOiB0 Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBZdWNodW5nIENoZW5nIDx5 Y2hlbmc9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogTW9uZGF5LCA5LiBBdWd1 c3QgMjAyMSBhdCAyMjo1Mw0KVG86IE1hcmsgQWxsbWFuIDxtYWxsbWFuQGljaXIub3JnPg0KQ2M6 IEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIExpbnV4IGRv ZXNu4oCZdCBpbXBsZW1lbnQgUkZDMzQ2NQ0KDQoNCg0KT24gTW9uLCBBdWcgOSwgMjAyMSBhdCAx MDowNSBBTSBNYXJrIEFsbG1hbiA8bWFsbG1hbkBpY2lyLm9yZzxtYWlsdG86bWFsbG1hbkBpY2ly Lm9yZz4+IHdyb3RlOg0KDQo+ICgyKSBJbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24ndCBwYWNlIHdp bGwgZ2VuZXJhbGx5IGJlIGNhdXNpbmcNCj4gbGFyZ2UgYnVyc3RzIGZvciBtYW55IGRpZmZlcmVu dCByZWFzb25zIGFueXdheSAoZGF0YSBhbmQvb3IgQUNLDQo+IGFnZ3JlZ2F0aW9uIGluIHRoZSBu ZXR3b3JrIG9yIGVuZCBob3N0cyksIHJlc3RhcnQgZnJvbSBpZGxlLC4uLikNCj4gc28gaGF2aW5n IGEgY29uc3RhbnQgTCBkb2VzIG5vdCBwcm92aWRlIGVub3VnaCBwcm90ZWN0aW9uIGZyb20NCj4g YnVyc3RzIHRvIGp1c3RpZnkgdGhlIGNvc3QgaW4gcmVkdWNlZCBwZXJmb3JtYW5jZSAoaW4gdGhl IGZvcm0gb2YNCj4gc2xvd2VyIHNsb3ctc3RhcnQpLiBJbiBzdXBwb3J0IG9mIHRoaXMsIGV4cGVy aWVuY2Ugd2l0aCB0aGlzIGFzDQo+IHRoZSBkZWZhdWx0IGJlaGF2aW9yIGluIExpbnV4IFRDUCBv dmVyIHRoZSAyMDEzLTIwMjEgcGVyaW9kDQo+IHN1Z2dlc3RzIHRoaXMgd29ya3Mgd2VsbCBlbm91 Z2ggaW4gcHJhY3RpY2UuDQoNCkkgdGhpbmsgYXQgc29tZSBwb2ludCBzb21lb25lIHNob3VsZCBw dXQgc29tZSBtZWF0IG9uIHRoZSBib25lcyBvZg0KInN1Z2dlc3RzIHRoaXMgd29ya3Mgd2VsbCBl bm91Z2ggaW4gcHJhY3RpY2UiLg0KR29vZCBwb2ludC4gV2UgY291bGQgYWRkIGFuZWNkb3RhbCB3 b3JkcyBvbiB0aGUgZGVncmVlIG9mIHN0cmV0Y2hlZCBBQ0suDQoNCk1heWJlIHdlIGNhbiBhbHNv IGNpdGUgcHJpb3JpIGRpc2N1c3Npb25zIG9uIEFDSyBjb21wcmVzc2lvbiAvIGRlY2ltYXRpb24g YSBjb3VwbGUgeWVhcnMgYWdvIGluIHRjcG0gLyB0c3Z3Zy4gQXJlIHRoZXJlIHJlc2VhcmNoIHBh cGVycyBvbiBzdHJldGNoIEFDSyBkZWdyZWVzIHRvbz8NCg0KDQpJdCBpc24ndCBlbm91Z2ggZm9y IGxpbnV4IHRvIGhhdmUgaW1wbGVtZW50ZWQgdGhpcy4gIE9yLCBldmVuIGhhZCBpdA0KdHVybmVk IG9uLiAgRS5nLiwgaWYgTD1caW5maW5pdHkgeWV0IHJlY2VpdmVycyBBQ0sgZXZlcnkgb3RoZXIN CnBhY2tldCB0aGVuIHRoZXJlIGlzIGFuIGVmZmVjdGl2ZSBMIG9mIDIuICBXZSBzZWUgbG90cyBv ZiBwZW9wbGUNCnNheWluZyB0aGlzIHNjZW5hcmlvIGlzbid0IHRoZSBwcmV2YWxlbnQgc2NlbmFy aW8gdGhlc2UgZGF5cy4gIElmDQp0aGF0J3MgdHJ1ZSB0aGVuIGl0IHNob3VsZCBiZSBlYXN5IHRv IHByb3ZpZGUgYSBzdW1tYXJ5IG9mDQpleHBlcmllbmNlIHdpdGggTD1caW5maW5pdHkuDQoNClRo aXMgd291bGQgYWxsIGp1c3Qgc2VlbSBiZXR0ZXIgd2l0aCBzb21lIGNvbmNyZXRlIGV4cGVyaWVu Y2UgcmF0aGVyDQp0aGFuIHRoZSBxdWl0ZSBoYW5kIHdhdnkgc3RhdGVtZW50cyB3ZSd2ZSBzZWVu IHNvIGZhci4NCg0KYWxsbWFuDQo= --_000_4A5AA064CAC943198E42463B3E1FAA1Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1ERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TaWdjb21tIHBhcGVyIGZyb20gMjAxNToNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2lnY29tbS5vcmcv c2l0ZXMvZGVmYXVsdC9maWxlcy9jY3IvcGFwZXJzLzIwMTUvSnVseS8wMDAwMDAwLTAwMDAwMDIu cGRmIj5odHRwOi8vd3d3LnNpZ2NvbW0ub3JnL3NpdGVzL2RlZmF1bHQvZmlsZXMvY2NyL3BhcGVy cy8yMDE1L0p1bHkvMDAwMDAwMC0wMDAwMDAyLnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGV54oCZdmUgb2JzZXJ2ZWQgMTEtMjIlIG9mIGNvbm5lY3Rpb25zIHdpdGgg c3RyZXRjaGVkIEFDS3MsIGFja+KAmWluZyBtb3N0bHkgdXAgdG8gNiBwYWNrZXRz4oCmLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+dGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgWXVjaHVu ZyBDaGVuZyAmbHQ7eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+TW9uZGF5LCA5LiBBdWd1c3QgMjAyMSBhdCAyMjo1Mzxicj4NCjxiPlRvOiA8 L2I+TWFyayBBbGxtYW4gJmx0O21hbGxtYW5AaWNpci5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5F eHRlbnNpb25zICZsdDt0Y3BtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W3RjcG1dIExpbnV4IGRvZXNu4oCZdCBpbXBsZW1lbnQgUkZDMzQ2NTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gTW9uLCBBdWcgOSwg MjAyMSBhdCAxMDowNSBBTSBNYXJrIEFsbG1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbGxtYW5A aWNpci5vcmciPm1hbGxtYW5AaWNpci5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxicj4NCiZndDsgKDIpIEltcGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IHBh Y2Ugd2lsbCBnZW5lcmFsbHkgYmUgY2F1c2luZzxicj4NCiZndDsgbGFyZ2UgYnVyc3RzIGZvciBt YW55IGRpZmZlcmVudCByZWFzb25zIGFueXdheSAoZGF0YSBhbmQvb3IgQUNLPGJyPg0KJmd0OyBh Z2dyZWdhdGlvbiBpbiB0aGUgbmV0d29yayBvciBlbmQgaG9zdHMpLCByZXN0YXJ0IGZyb20gaWRs ZSwuLi4pPGJyPg0KJmd0OyBzbyBoYXZpbmcgYSBjb25zdGFudCBMIGRvZXMgbm90IHByb3ZpZGUg ZW5vdWdoIHByb3RlY3Rpb24gZnJvbTxicj4NCiZndDsgYnVyc3RzIHRvIGp1c3RpZnkgdGhlIGNv c3QgaW4gcmVkdWNlZCBwZXJmb3JtYW5jZSAoaW4gdGhlIGZvcm0gb2Y8YnI+DQomZ3Q7IHNsb3dl ciBzbG93LXN0YXJ0KS4gSW4gc3VwcG9ydCBvZiB0aGlzLCBleHBlcmllbmNlIHdpdGggdGhpcyBh czxicj4NCiZndDsgdGhlIGRlZmF1bHQgYmVoYXZpb3IgaW4gTGludXggVENQIG92ZXIgdGhlIDIw MTMtMjAyMSBwZXJpb2Q8YnI+DQomZ3Q7IHN1Z2dlc3RzIHRoaXMgd29ya3Mgd2VsbCBlbm91Z2gg aW4gcHJhY3RpY2UuPGJyPg0KPGJyPg0KSSB0aGluayBhdCBzb21lIHBvaW50IHNvbWVvbmUgc2hv dWxkIHB1dCBzb21lIG1lYXQgb24gdGhlIGJvbmVzIG9mPGJyPg0KJnF1b3Q7c3VnZ2VzdHMgdGhp cyB3b3JrcyB3ZWxsIGVub3VnaCBpbiBwcmFjdGljZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5Hb29kIHBvaW50LiBXZSBjb3VsZCBhZGQgYW5lY2RvdGFsIHdvcmRzIG9uIHRo ZSBkZWdyZWUgb2Ygc3RyZXRjaGVkIEFDSy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TWF5YmUgd2UgY2FuIGFsc28gY2l0ZSBwcmlvcmkgZGlzY3Vz c2lvbnMgb24gQUNLIGNvbXByZXNzaW9uIC8gZGVjaW1hdGlvbiBhIGNvdXBsZSB5ZWFycyBhZ28g aW4gdGNwbSAvIHRzdndnLiBBcmUgdGhlcmUgcmVzZWFyY2ggcGFwZXJzIG9uIHN0cmV0Y2ggQUNL IGRlZ3JlZXMgdG9vPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48YnI+DQpJdCBpc24ndCBlbm91Z2ggZm9yIGxpbnV4IHRvIGhhdmUgaW1w bGVtZW50ZWQgdGhpcy4mbmJzcDsgT3IsIGV2ZW4gaGFkIGl0PGJyPg0KdHVybmVkIG9uLiZuYnNw OyBFLmcuLCBpZiBMPVxpbmZpbml0eSB5ZXQgcmVjZWl2ZXJzIEFDSyBldmVyeSBvdGhlcjxicj4N CnBhY2tldCB0aGVuIHRoZXJlIGlzIGFuIGVmZmVjdGl2ZSBMIG9mIDIuJm5ic3A7IFdlIHNlZSBs b3RzIG9mIHBlb3BsZTxicj4NCnNheWluZyB0aGlzIHNjZW5hcmlvIGlzbid0IHRoZSBwcmV2YWxl bnQgc2NlbmFyaW8gdGhlc2UgZGF5cy4mbmJzcDsgSWY8YnI+DQp0aGF0J3MgdHJ1ZSB0aGVuIGl0 IHNob3VsZCBiZSBlYXN5IHRvIHByb3ZpZGUgYSBzdW1tYXJ5IG9mPGJyPg0KZXhwZXJpZW5jZSB3 aXRoIEw9XGluZmluaXR5Ljxicj4NCjxicj4NClRoaXMgd291bGQgYWxsIGp1c3Qgc2VlbSBiZXR0 ZXIgd2l0aCBzb21lIGNvbmNyZXRlIGV4cGVyaWVuY2UgcmF0aGVyPGJyPg0KdGhhbiB0aGUgcXVp dGUgaGFuZCB3YXZ5IHN0YXRlbWVudHMgd2UndmUgc2VlbiBzbyBmYXIuPGJyPg0KPGJyPg0KYWxs bWFuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A5AA064CAC943198E42463B3E1FAA1Eericssoncom_-- From nobody Thu Aug 12 11:11: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 E3E983A4502 for ; Thu, 12 Aug 2021 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtp_6Rk0SVGQ for ; Thu, 12 Aug 2021 11:10:55 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 13EFD3A44FF for ; Thu, 12 Aug 2021 11:10:55 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id i9so7937169ilk.9 for ; Thu, 12 Aug 2021 11:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/3GhVJZyGgXmPKQjTCK/0CE1fKRChpMmPbdxDc0/xw=; b=QyMCuw7Tol/YkGnNTWpQrSDfrKWbDE5UQsP937pqC+hTTv/eBxWCcXtNW/ZL1jqOS0 x2Q9PE5Yzt5tZn4TFCEEfJ4Q21uFqrHktf0l/M9XoCIo9/kyr4lmIE+DGKwCF7ay9gua K48fEgUk9WkIQ27x3ESIuCPypqv937bjB7Yw6GLEqKSiyBlAr3JiBZ0UD2wmC2+L621b bFTUEQPuVVViyCVsTO7zg9eDgLeNfRb81vSHBoI4r4tNIyYuaaV/OhKh9/xUoksJf1Jj z1UrAFqReTy+nr7+oq0Ie0RlVOszGblt5fAACD1ADRwuxWMKPiaHoZq7DUzBMF/d5Vfr Zv1w== 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=B/3GhVJZyGgXmPKQjTCK/0CE1fKRChpMmPbdxDc0/xw=; b=LCMcuzsieJmjAboN5d2ajam/r0+sgiHj7jrS3a0SySWLC4D85pbY5NmU6s1jonSGix XcACvO4ZquCM4NS63gnhR8Xxd5gP/Uo3cDHDig2FeromsHSKEnVWZq9b3tYiEzFdMXPr dKEbCZuTcMSulttWq3SeuLopyY30v4lFVEbNxXi7oKrouFtb3IUKTL8noMd+l0yWJIjt Oc3q2uafJv2VZdDxPHRcPB5Et77rjp8RwoitSBFGzFVjKChSOTC2leqotfupGJ8/PuaJ YLpwqvp07vv9aOVfPI3zGA/KVe1/fgKtlfRt+B6sSztjeYWOsi3QWnR51p/zV4gZdkmx at+w== X-Gm-Message-State: AOAM531LBJdhtbmOH7/5oHNA0ngOoMdo4bhaUivEekwuCAt2kf/Vowe9 NUcEzKWlFoK8M2z9Ls1walj0bxs3aEB5pWx0Ncw= X-Google-Smtp-Source: ABdhPJz/w7x455x2/qeuJ2o6hCuqT07O9dA6hvyCPGp5Gfd3xyVMgu92V2EZ50VEBvfsWY9a281vVv4x1LfbiebIfew= X-Received: by 2002:a92:cd8a:: with SMTP id r10mr3657226ilb.287.1628791853289; Thu, 12 Aug 2021 11:10:53 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> In-Reply-To: <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> From: Martin Duke Date: Thu, 12 Aug 2021 11:10:42 -0700 Message-ID: To: Mirja Kuehlewind Cc: Yuchung Cheng , Mark Allman , Extensions Content-Type: multipart/alternative; boundary="000000000000d4160605c960a708" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 18:11:01 -0000 --000000000000d4160605c960a708 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With AD hat on, If I understand the current document state correctly, the current ABC guidance we have is RFC3465 (Experimental): L=3D2 RFC5681 (PS): L=3D1 There are a few PS drafts floating around that use byte counting in some form and would benefit from a standards-track reference in this case. 1. The most comprehensive solution would be a 3465bis PS doc that obsoletes 3465 and updates 5681 with L=3D Infinity, 8, or whatever number the group decides on. If we agree this is the right thing to do and someone has the energy to drop 3465bis-00, then let's do so to have a basis of discussion. 2. If there is no such energy, or there are contentious issues that will draw out the process to get this to RFC, than I can initiate a review of upgrading 3465 to PS directly. I think we all agree this would be an improvement on the status quo, but isn't worth doing if 3465bis is going to happen quickly. 3. There might be interest in a more generalized 5681bis, but my instinct is that this is a bigger job that will delay the most urgently needed update -- which is not to say that we shouldn't do that document too. 4. However, I don't think it would be too much of a stretch to rope in an IW update (6928bis) in 3465bis, if it doesn't add too much time. It all fits in with the general theme of the maximum allowable burst on the internet in the absence of any sort of pacing (ack-driven or stack-enforced). The most useful thing right now would be for people to either (1) disagree with any of my 4 points above or (2) or volunteer to write 3465bis-00. Martin On Tue, Aug 10, 2021 at 8:55 AM Mirja Kuehlewind wrote: > Sigcomm paper from 2015: > > > > > http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0= 000002.pdf > > > > They=E2=80=99ve observed 11-22% of connections with stretched ACKs, ack= =E2=80=99ing mostly > up to 6 packets=E2=80=A6. > > > > > > > > *From: *tcpm on behalf of Yuchung Cheng 40google.com@dmarc.ietf.org> > *Date: *Monday, 9. August 2021 at 22:53 > *To: *Mark Allman > *Cc: *Extensions > *Subject: *Re: [tcpm] Linux doesn=E2=80=99t implement RFC3465 > > > > > > > > On Mon, Aug 9, 2021 at 10:05 AM Mark Allman wrote: > > > > (2) Implementations that don't pace will generally be causing > > large bursts for many different reasons anyway (data and/or ACK > > aggregation in the network or end hosts), restart from idle,...) > > so having a constant L does not provide enough protection from > > bursts to justify the cost in reduced performance (in the form of > > slower slow-start). In support of this, experience with this as > > the default behavior in Linux TCP over the 2013-2021 period > > suggests this works well enough in practice. > > I think at some point someone should put some meat on the bones of > "suggests this works well enough in practice". > > Good point. We could add anecdotal words on the degree of stretched ACK. > > > > Maybe we can also cite priori discussions on ACK compression / decimation > a couple years ago in tcpm / tsvwg. Are there research papers on stretch > ACK degrees too? > > > > > It isn't enough for linux to have implemented this. Or, even had it > turned on. E.g., if L=3D\infinity yet receivers ACK every other > packet then there is an effective L of 2. We see lots of people > saying this scenario isn't the prevalent scenario these days. If > that's true then it should be easy to provide a summary of > experience with L=3D\infinity. > > This would all just seem better with some concrete experience rather > than the quite hand wavy statements we've seen so far. > > allman > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000d4160605c960a708 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With AD hat on,

If I und= erstand the current document state correctly, the current ABC guidance we h= ave is

RFC3465 (Experimental): L=3D2
RFC= 5681 (PS): L=3D1

There are a few PS drafts floatin= g around that use byte counting in some form and would benefit from a stand= ards-track reference in this case.

1. The most com= prehensive solution would be a 3465bis PS doc that obsoletes 3465 and updat= es 5681 with L=3D Infinity, 8, or whatever number the group decides on. If = we agree this is the right thing to do and someone has the energy to drop 3= 465bis-00, then let's do so to have a basis of discussion.
2. If there is no such energy, or there are contentious issues= that will draw out the process to get this to RFC, than I can initiate a r= eview of upgrading 3465 to PS directly. I think we all agree this would be = an improvement on the status quo, but isn't worth doing if 3465bis is g= oing to happen quickly.

3. There might be interest= in a more generalized 5681bis, but my instinct is that this is a bigger jo= b that will delay the most urgently needed update -- which is not to say th= at we shouldn't do that document too.

4. Howev= er, I don't think it would be too much of a stretch to rope in an IW up= date (6928bis) in 3465bis, if it doesn't add too much time. It all fits= in with the general theme of the maximum allowable burst on the internet i= n the absence of any sort of pacing (ack-driven or stack-enforced).

The most useful thing right now would be for people t= o either (1) disagree with any of my 4 points above or (2) or volunteer to = write 3465bis-00.

Martin

On Tue, Aug = 10, 2021 at 8:55 AM Mirja Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> wro= te:

Sigcomm paper from 2015:

=C2=A0

http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/000= 0000-0000002.pdf

=C2=A0

They=E2=80=99ve observed 11-22%= of connections with stretched ACKs, ack=E2=80=99ing mostly up to 6 packets= =E2=80=A6.

=C2=A0

=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org>= ; on behalf of Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org>
Date: Monday, 9. August 2021 at 22:53
To: Mark Allman <mallman@icir.org>
Cc: Extensions <tcpm@ietf.org>
Subject: Re: [tcpm] Linux doesn=E2=80=99t implement RFC3465

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 9, 2021 at 10= :05 AM Mark Allman <mallman@icir.org> wrote:


> (2) Implementations that don't pace will generally be causing
> large bursts for many different reasons anyway (data and/or ACK
> aggregation in the network or end hosts), restart from idle,...)
> so having a constant L does not provide enough protection from
> bursts to justify the cost in reduced performance (in the form of
> slower slow-start). In support of this, experience with this as
> the default behavior in Linux TCP over the 2013-2021 period
> suggests this works well enough in practice.

I think at some point someone should put some meat on the bones of
"suggests this works well enough in practice".

Good point. We could add = anecdotal words on the degree of stretched ACK.

=C2=A0

Maybe we can also cite pr= iori discussions on ACK compression / decimation a couple years ago in tcpm= / tsvwg. Are there research papers on stretch ACK degrees too?

=C2=A0


It isn't enough for linux to have implemented this.=C2=A0 Or, even had = it
turned on.=C2=A0 E.g., if L=3D\infinity yet receivers ACK every other
packet then there is an effective L of 2.=C2=A0 We see lots of people
saying this scenario isn't the prevalent scenario these days.=C2=A0 If<= br> that's true then it should be easy to provide a summary of
experience with L=3D\infinity.

This would all just seem better with some concrete experience rather
than the quite hand wavy statements we've seen so far.

allman

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000d4160605c960a708-- From nobody Thu Aug 12 11:34: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 F38B23A4565 for ; Thu, 12 Aug 2021 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy8hqODm42AO for ; Thu, 12 Aug 2021 11:34:38 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 C3A1A3A45BD for ; Thu, 12 Aug 2021 11:34:38 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 17CIS9VG014900; Thu, 12 Aug 2021 11:34:30 -0700 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=W+rJoFBJo5zJ3I3seJMoUNZ/yqH2RxbOEkLB6sEp0yU=; b=DSlgryX3FXw5gC75fE4OPsss/M0qpBqIPaleWh86JMG4+quLTFCdv+LeFicXAqbEXZjE NwVfborEkIRV2jVlixXg0lYdI6f64twJ5tozGqPMbhbvHVXPjxKKyFmDAO5k6DY4atsZ Q2ojgWLHzmVJj3Ap6fVjbEOHGT1r0BZP0dFB/W0Mx9b+XW7VBZFFDXGT939oRBsfQhiq AhY0Q3tLnRJIoj/1BGn2xsqdCwMMLlZvX8s6VsaELnJovHhJDAQBuRPXsS3tio3fqKqy +JpB3wsNLPwBeZ0EPyzsiRw/5bx4FDEatXIH2/PT4L1m7rFTp1ffPCpeChLjIirWSrcP KA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3a9s5wvq9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Aug 2021 11:34:30 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXQ004Y8OXIC900@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 12 Aug 2021 11:34:30 -0700 (PDT) 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.9.20210415 64bit (built Apr 15 2021)) id <0QXQ00H00OF4BZ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 12 Aug 2021 11:34:30 -0700 (PDT) X-Va-A: X-Va-T-CD: 1c81ee2767b4be5bac0682a8445e85fc X-Va-E-CD: 8ad83cf34a8c3732cb73dea81270d36d X-Va-R-CD: 2eec4d4b333905bf2498bde820845c7b X-Va-CD: 0 X-Va-ID: df998e0d-1f88-4cc9-b517-a406f6b121e5 X-V-A: X-V-T-CD: 1c81ee2767b4be5bac0682a8445e85fc X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b X-V-CD: 0 X-V-ID: b0890670-d0ca-4730-9b46-d5eb4c3d5dc8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-12_06:2021-08-12, 2021-08-12 signatures=0 Received: from smtpclient.apple (unknown [17.234.111.4]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXQ00072OXHTU00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 12 Aug 2021 11:34:29 -0700 (PDT) From: Vidhi Goel Message-id: <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_D5D519F6-32E2-4C0A-B37F-7A8736E3FA24"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Thu, 12 Aug 2021 11:34:28 -0700 In-reply-to: Cc: Mirja Kuehlewind , Extensions , Mark Allman To: Martin Duke , Yuchung Cheng , Neal Cardwell References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-12_05:2021-08-12, 2021-08-12 signatures=0 Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 18:34:44 -0000 --Apple-Mail=_D5D519F6-32E2-4C0A-B37F-7A8736E3FA24 Content-Type: multipart/alternative; boundary="Apple-Mail=_7D970C24-46B2-4E37-A301-B2BEE9A90787" --Apple-Mail=_7D970C24-46B2-4E37-A301-B2BEE9A90787 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Martin for mentioning the different available options. > If I understand the current document state correctly, the current ABC = guidance we have is >=20 > RFC3465 (Experimental): L=3D2 > RFC5681 (PS): L=3D1 I want to note that the guidance in 3465 is a MUST while in 5681 is a = RECOMMEND. > 1. The most comprehensive solution would be a 3465bis PS doc that = obsoletes 3465 and updates 5681 with L=3D Infinity, 8, or whatever = number the group decides on. If we agree this is the right thing to do = and someone has the energy to drop 3465bis-00, then let's do so to have = a basis of discussion. I created a GitHub repo https://github.com/goelvidhi/rfc3465-bis = with the current text of = 3465. Neal and Yuchung have mentioned that they would be willing to = contribute. (Neal, Yuchung, please correct me if I misunderstood). > 2. If there is no such energy, or there are contentious issues that = will draw out the process to get this to RFC, than I can initiate a = review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis is = going to happen quickly. I don=E2=80=99t think 3465 can be upgraded to PS as-is. > 3. There might be interest in a more generalized 5681bis, but my = instinct is that this is a bigger job that will delay the most urgently = needed update -- which is not to say that we shouldn't do that document = too. Yeah, it could delay the simpler and important update to 3465. I am ok = with going either way - 5681-bis or 3465-bis whichever could likely make = faster progress. > 4. However, I don't think it would be too much of a stretch to rope in = an IW update (6928bis) in 3465bis, if it doesn't add too much time. It = all fits in with the general theme of the maximum allowable burst on the = internet in the absence of any sort of pacing (ack-driven or = stack-enforced). Personally, I like the structure of 6928 more than 3465. Is it possible = to rope in ABC (3465) in a 6928bis and change the title - Would like to = hear more from the authors of both the RFCs. Thanks, Vidhi > On Aug 12, 2021, at 11:10 AM, Martin Duke = wrote: >=20 > With AD hat on, >=20 > If I understand the current document state correctly, the current ABC = guidance we have is >=20 > RFC3465 (Experimental): L=3D2 > RFC5681 (PS): L=3D1 >=20 > There are a few PS drafts floating around that use byte counting in = some form and would benefit from a standards-track reference in this = case. >=20 > 1. The most comprehensive solution would be a 3465bis PS doc that = obsoletes 3465 and updates 5681 with L=3D Infinity, 8, or whatever = number the group decides on. If we agree this is the right thing to do = and someone has the energy to drop 3465bis-00, then let's do so to have = a basis of discussion. >=20 > 2. If there is no such energy, or there are contentious issues that = will draw out the process to get this to RFC, than I can initiate a = review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis is = going to happen quickly. >=20 > 3. There might be interest in a more generalized 5681bis, but my = instinct is that this is a bigger job that will delay the most urgently = needed update -- which is not to say that we shouldn't do that document = too. >=20 > 4. However, I don't think it would be too much of a stretch to rope in = an IW update (6928bis) in 3465bis, if it doesn't add too much time. It = all fits in with the general theme of the maximum allowable burst on the = internet in the absence of any sort of pacing (ack-driven or = stack-enforced). >=20 > The most useful thing right now would be for people to either (1) = disagree with any of my 4 points above or (2) or volunteer to write = 3465bis-00. >=20 > Martin >=20 > On Tue, Aug 10, 2021 at 8:55 AM Mirja Kuehlewind = > wrote: > Sigcomm paper from 2015: >=20 > =20 >=20 > = http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-00= 00002.pdf = > =20 >=20 > They=E2=80=99ve observed 11-22% of connections with stretched ACKs, = ack=E2=80=99ing mostly up to 6 packets=E2=80=A6. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: tcpm > on = behalf of Yuchung Cheng > > Date: Monday, 9. August 2021 at 22:53 > To: Mark Allman > > Cc: Extensions > > Subject: Re: [tcpm] Linux doesn=E2=80=99t implement RFC3465 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Mon, Aug 9, 2021 at 10:05 AM Mark Allman > wrote: >=20 >=20 > > (2) Implementations that don't pace will generally be causing > > large bursts for many different reasons anyway (data and/or ACK > > aggregation in the network or end hosts), restart from idle,...) > > so having a constant L does not provide enough protection from > > bursts to justify the cost in reduced performance (in the form of > > slower slow-start). In support of this, experience with this as > > the default behavior in Linux TCP over the 2013-2021 period > > suggests this works well enough in practice. >=20 > I think at some point someone should put some meat on the bones of > "suggests this works well enough in practice". >=20 > Good point. We could add anecdotal words on the degree of stretched = ACK. >=20 > =20 >=20 > Maybe we can also cite priori discussions on ACK compression / = decimation a couple years ago in tcpm / tsvwg. Are there research papers = on stretch ACK degrees too? >=20 > =20 >=20 >=20 > It isn't enough for linux to have implemented this. Or, even had it > turned on. E.g., if L=3D\infinity yet receivers ACK every other > packet then there is an effective L of 2. We see lots of people > saying this scenario isn't the prevalent scenario these days. If > that's true then it should be easy to provide a summary of > experience with L=3D\infinity. >=20 > This would all just seem better with some concrete experience rather > than the quite hand wavy statements we've seen so far. >=20 > allman >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_7D970C24-46B2-4E37-A301-B2BEE9A90787 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Martin for mentioning the different available = options.

If = I understand the current document state correctly, the current ABC = guidance we have is

RFC3465 (Experimental): L=3D2
RFC5681 = (PS): L=3D1

I= want to note that the guidance in 3465 is a MUST while in 5681 is a = RECOMMEND.

1. The most comprehensive solution would be a = 3465bis PS doc that obsoletes 3465 and updates 5681 with L=3D Infinity, = 8, or whatever number the group decides on. If we agree this is the = right thing to do and someone has the energy to drop 3465bis-00, then = let's do so to have a basis of discussion.

I created a GitHub repo https://github.com/goelvidhi/rfc3465-bis with the = current text of 3465. Neal and Yuchung have mentioned that they would be = willing to contribute. (Neal, Yuchung, please correct me if I = misunderstood).

2. If there is no such energy, or there are = contentious issues that will draw out the process to get this to RFC, = than I can initiate a review of upgrading 3465 to PS directly. I think = we all agree this would be an improvement on the status quo, but isn't = worth doing if 3465bis is going to happen = quickly.

I = don=E2=80=99t think 3465 can be upgraded to PS as-is.

3. There might be = interest in a more generalized 5681bis, but my instinct is that this is = a bigger job that will delay the most urgently needed update -- which is = not to say that we shouldn't do that document = too.

Yeah, = it could delay the simpler and important update to 3465. I am ok with = going either way - 5681-bis or 3465-bis whichever could likely make = faster progress.

4. However, I don't think it would be too = much of a stretch to rope in an IW update (6928bis) in 3465bis, if it = doesn't add too much time. It all fits in with the general theme of the = maximum allowable burst on the internet in the absence of any sort of = pacing (ack-driven or stack-enforced).

Personally, I like the structure of 6928 more than 3465. Is = it possible to rope in ABC (3465) in a 6928bis and change the title - = Would like to hear more from the authors of both the RFCs.

Thanks,
Vidhi

On Aug 12, 2021, at 11:10 AM, = Martin Duke <martin.h.duke@gmail.com> wrote:

With AD hat on,

If I understand the = current document state correctly, the current ABC guidance we have = is

RFC3465 = (Experimental): L=3D2
RFC5681 (PS): L=3D1

There are a few PS = drafts floating around that use byte counting in some form and would = benefit from a standards-track reference in this case.

1. The most = comprehensive solution would be a 3465bis PS doc that obsoletes 3465 and = updates 5681 with L=3D Infinity, 8, or whatever number the group decides = on. If we agree this is the right thing to do and someone has the energy = to drop 3465bis-00, then let's do so to have a basis of = discussion.

2. = If there is no such energy, or there are contentious issues that will = draw out the process to get this to RFC, than I can initiate a review of = upgrading 3465 to PS directly. I think we all agree this would be an = improvement on the status quo, but isn't worth doing if 3465bis is going = to happen quickly.

3. There might be interest in a more generalized 5681bis, but = my instinct is that this is a bigger job that will delay the most = urgently needed update -- which is not to say that we shouldn't do that = document too.

4.= However, I don't think it would be too much of a stretch to rope in an = IW update (6928bis) in 3465bis, if it doesn't add too much time. It all = fits in with the general theme of the maximum allowable burst on the = internet in the absence of any sort of pacing (ack-driven or = stack-enforced).

The most useful thing right now would = be for people to either (1) disagree with any of my 4 points above or = (2) or volunteer to write 3465bis-00.

Martin

On Tue, Aug 10, 2021 at 8:55 AM Mirja = Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> wrote:

Sigcomm paper from = 2015:

 

http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July= /0000000-0000002.pdf

 

They=E2=80=99ve = observed 11-22% of connections with stretched ACKs, ack=E2=80=99ing = mostly up to 6 packets=E2=80=A6.

 

 

 

From: tcpm <tcpm-bounces@ietf.org> on behalf of Yuchung Cheng = <ycheng=3D40google.com@dmarc.ietf.org>
Date: Monday, 9. August 2021 at 22:53
To: Mark Allman <mallman@icir.org>
Cc: Extensions <tcpm@ietf.org>
Subject: Re: [tcpm] Linux doesn=E2=80=99t implement = RFC3465

 

 

 

On = Mon, Aug 9, 2021 at 10:05 AM Mark Allman <mallman@icir.org> wrote:


> (2) Implementations that don't pace will generally be causing
> large bursts for many different reasons anyway (data and/or ACK
> aggregation in the network or end hosts), restart from idle,...)
> so having a constant L does not provide enough protection from
> bursts to justify the cost in reduced performance (in the form = of
> slower slow-start). In support of this, experience with this as
> the default behavior in Linux TCP over the 2013-2021 period
> suggests this works well enough in practice.

I think at some point someone should put some meat on the bones of
"suggests this works well enough in practice".

Good = point. We could add anecdotal words on the degree of stretched ACK.

 

Maybe = we can also cite priori discussions on ACK compression / decimation a = couple years ago in tcpm / tsvwg. Are there research papers on stretch = ACK degrees too?

 


It isn't enough for linux to have implemented this.  Or, even had = it
turned on.  E.g., if L=3D\infinity yet receivers ACK every other
packet then there is an effective L of 2.  We see lots of people
saying this scenario isn't the prevalent scenario these days.  = If
that's true then it should be easy to provide a summary of
experience with L=3D\infinity.

This would all just seem better with some concrete experience rather
than the quite hand wavy statements we've seen so far.

allman

_______________________________________________
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=_7D970C24-46B2-4E37-A301-B2BEE9A90787-- --Apple-Mail=_D5D519F6-32E2-4C0A-B37F-7A8736E3FA24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgxMjE4 MzQyOFowLwYJKoZIhvcNAQkEMSIEINQGBlnpP6HtSzuQ/7dhOG4BBEoFM+nghGgGQRNQowtQMIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAI9e3RsDFGkPVfBRKs/yqapsgNYvusmnaSvL//anE12N/fFY/uAbo1eG GTLdzY9VnVdVHRg/zsUBOXZV7I+x5NRritwU2cd7lOLBpSkDsuxZX/KG+AiKYTd/kHpxxthVSS+b ZIA9xfy633GbgNXT/2Eh5r5/UJYyvnHgO8Im8X9d69h1SKJ1LRR3tUeSEVm1IcnPaFDakBYOMrKa BgTquB3bTEgWkCq8f3Be+yJPOSWl7H+foKwCXfcFsL7PKQRzC1+iZ/rlkESJo6dqLIUfAxDDnAzo LSqsQ81tJ9dV0csCguFfEBRC9ngMo4xHlAVnONFMRmu3cx9rfhi+VZB/G4cAAAAAAAA= --Apple-Mail=_D5D519F6-32E2-4C0A-B37F-7A8736E3FA24-- From nobody Thu Aug 12 11:39:16 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 552EA3A45DB for ; Thu, 12 Aug 2021 11:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 cFPchqG8C5cT for ; Thu, 12 Aug 2021 11:39:13 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DBC3A45D9 for ; Thu, 12 Aug 2021 11:39:13 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id e186so9673642iof.12 for ; Thu, 12 Aug 2021 11:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T5yVBa57gqT8f4zIJ1csMIHD4oGRpIcCGyRRl3rMVd4=; b=SWMC4yocE6FxBuEfg1hr4/fNZxZyBNxUGN/uIwLYUD//zkUAW6iyIpYmTExypqwHZ4 wzKH2tUsaraJIHA3chTFouRjpqgsYl2anzrCmBzpDugA2kCVbrqu3QkgaQDd2xqPK3hR Iz6Pv2fhki/e3jWRWdF+uY1KEpLQFiDdG9+bibwgH4kR/PXjVhEeGxgCf49m7L3kxVIq rQkMMvFUbMntQjGb1VH0ljaEnjnYKuyrnYprg73PnwfXxzXGKQhpYAN42OGSnMgKkMre K/2IzvRLC5HQ1KpNWPCHDpnertYlkU9eNmOmAa2ex/Ekdf76K3znjfSLdDQngWQRgBYX pjwg== 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=T5yVBa57gqT8f4zIJ1csMIHD4oGRpIcCGyRRl3rMVd4=; b=sTUjnVnXqzj8aS99wUceDYgAhHdKCsGOED95kyBTcY4z9jUxXvQ6t38MCwI1VhDqO1 i19hg1XxcupE1h7/Zl7qfepixcY60+M9gCBpTdVu72XVb/f+/7V/6CaNyp8n7koSDE2E AvEcFX49Y9ysKrYEuWAz9eLHWue3gm+lW9g9f5WodqV8YSJEjPP8OSkjy4vMyVsFO9Ed ltKHwzETNQEp7NHPWwm1IF3s6E4ur1QUwwEM6IUstWo6dlRK625eC0zkrHH23ME/Q+A0 1b98UkuN0voqeBcGUxDXCJ8q0uwQEhlGaQgky4Kdfls0grwaR2nvoydcCXBuwVFsS0Xr NzNQ== X-Gm-Message-State: AOAM533CH1BcbraP7zdwJvUvKPLHaTdLm1Yndizg4OcSBePiIEbvQZUu mHdqTsuGsx1eEjR7KsXWQJs21MEPsVaJYk2sewY= X-Google-Smtp-Source: ABdhPJx8nTCOC3kSQ8aZByZ/F7jQI+NxcCmX+JSygZrFMrwcnP8ALZr2gdNK2KEcTUctcD4LUE6O17CllZLMprDAoiw= X-Received: by 2002:a05:6602:2595:: with SMTP id p21mr4114287ioo.51.1628793551783; Thu, 12 Aug 2021 11:39:11 -0700 (PDT) MIME-Version: 1.0 References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com> In-Reply-To: <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com> From: Martin Duke Date: Thu, 12 Aug 2021 11:39:00 -0700 Message-ID: To: Vidhi Goel Cc: Yuchung Cheng , Neal Cardwell , Mirja Kuehlewind , Extensions , Mark Allman Content-Type: multipart/alternative; boundary="000000000000110e4a05c9610d84" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 18:39:14 -0000 --000000000000110e4a05c9610d84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel wrote: > 2. If there is no such energy, or there are contentious issues that will > draw out the process to get this to RFC, than I can initiate a review of > upgrading 3465 to PS directly. I think we all agree this would be an > improvement on the status quo, but isn't worth doing if 3465bis is going = to > happen quickly. > > > I don=E2=80=99t think 3465 can be upgraded to PS as-is. > Why not? > Personally, I like the structure of 6928 more than 3465. Is it possible t= o > rope in ABC (3465) in a 6928bis and > change the title - Would like to hear more from the authors of both the > RFCs. > It will take a bit more editorial work, but there's no reason a single document can't obsolete both RFCs. > > Thanks, > Vidhi > Thanks for writing a draft. That will move things along. --000000000000110e4a05c9610d84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 12, 2021 at 11:34 AM Vidh= i Goel <vidhi_goel@apple.com= > wrote:
2. If there is no such energy, or there are contentious iss= ues that will draw out the process to get this to RFC, than I can initiate = a review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis i= s going to happen quickly.

I don=E2= =80=99t think 3465 can be upgraded to PS as-is.

Why not?
=C2=A0
<= div>
Personally, I like the structure of 69= 28 more than 3465. Is it possible to rope in ABC (3465) in a 6928bis and
change the title - Would like to hear more from the auth= ors of both the RFCs.

It will take a bit more editorial work, but there's no reason = a single document can't obsolete both RFCs.
=C2=A0
<= 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">

Thanks,
Vidhi

T= hanks for writing a draft. That will move things along.
=C2= =A0

--000000000000110e4a05c9610d84-- From nobody Thu Aug 12 11:44: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 7CF553A45FA for ; Thu, 12 Aug 2021 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2L_CSQPA7-Y for ; Thu, 12 Aug 2021 11:44:44 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 2FAE23A45FC for ; Thu, 12 Aug 2021 11:44:44 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 17CIcMPe012452; Thu, 12 Aug 2021 11:44:36 -0700 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=AJVHEMFCSt/dRwsjEhlhx3NY+5pzlg6HBeIiiOxkc3I=; b=whZhxxy3Fazhy1+8VXFwrNRhPVchrSV5DKKuHZ+bKU+/gzxceO9fe3p9B+PmQoAFsFHj VU6mZ4wBVKCSbQSev2Hx6VdmRDyNNEh2SLznjvtiJqS1OKUw74leqyGkx8hZ49RzeNJ0 Ox2xWc6DYRv7M+4d5Kt7TG6UKdxfn8xgyiNY5559JYn7jrvvMpqkScFGy9FPwkdZuCS0 HNwFP32qeRvrDe6Sq5AT4X0u0GSVMRcc3SyKQUgP1kmXXKsmEEV8SbQnVcrbF0a0Co93 Ie8dBuYNRfKfeD221ogI0JVGubNy5p4RgJULA1oIk4DObWWbYORjxjXYvFNCpZXGu2Zm PA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3a9s5wvv76-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Aug 2021 11:44:36 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXQ00142PEBKGC0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 12 Aug 2021 11:44:35 -0700 (PDT) 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.9.20210415 64bit (built Apr 15 2021)) id <0QXQ00K00P2TDE00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 12 Aug 2021 11:44:35 -0700 (PDT) X-Va-A: X-Va-T-CD: 8d45deca0a60b8e84b634a23cb93b003 X-Va-E-CD: 8ad83cf34a8c3732cb73dea81270d36d X-Va-R-CD: 2eec4d4b333905bf2498bde820845c7b X-Va-CD: 0 X-Va-ID: 566adc51-a99a-4c0b-8671-e0e2aa8c2de3 X-V-A: X-V-T-CD: 8d45deca0a60b8e84b634a23cb93b003 X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b X-V-CD: 0 X-V-ID: 8232465e-5e87-45ac-99e8-ebc3af6b3551 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-12_06:2021-08-12, 2021-08-12 signatures=0 Received: from smtpclient.apple (unknown [17.234.111.4]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXQ000NCPEATU00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 12 Aug 2021 11:44:34 -0700 (PDT) From: Vidhi Goel Message-id: <409938D1-CF12-4238-8641-C24C173B2E33@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_CFF5B9CD-6B9F-45A7-BF49-5E8A92EA617C"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Thu, 12 Aug 2021 11:44:34 -0700 In-reply-to: Cc: Yuchung Cheng , Neal Cardwell , Mirja Kuehlewind , Extensions , Mark Allman To: Martin Duke References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-12_06:2021-08-12, 2021-08-12 signatures=0 Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 18:44:49 -0000 --Apple-Mail=_CFF5B9CD-6B9F-45A7-BF49-5E8A92EA617C Content-Type: multipart/alternative; boundary="Apple-Mail=_AF7B0F37-728C-437D-8399-7716C80D0888" --Apple-Mail=_AF7B0F37-728C-437D-8399-7716C80D0888 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel > wrote: >> 2. If there is no such energy, or there are contentious issues that = will draw out the process to get this to RFC, than I can initiate a = review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis is = going to happen quickly. >=20 > I don=E2=80=99t think 3465 can be upgraded to PS as-is. >=20 > Why not? Because L=3D2 as MUST is too constrained for high BDPs and most stacks = don=E2=80=99t even follow that. > On Aug 12, 2021, at 11:39 AM, Martin Duke = wrote: >=20 >=20 >=20 > On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel > wrote: >> 2. If there is no such energy, or there are contentious issues that = will draw out the process to get this to RFC, than I can initiate a = review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis is = going to happen quickly. >=20 > I don=E2=80=99t think 3465 can be upgraded to PS as-is. >=20 > Why not? > =20 > Personally, I like the structure of 6928 more than 3465. Is it = possible to rope in ABC (3465) in a 6928bis and=20 > change the title - Would like to hear more from the authors of both = the RFCs. >=20 > It will take a bit more editorial work, but there's no reason a single = document can't obsolete both RFCs. > =20 >=20 > Thanks, > Vidhi >=20 > Thanks for writing a draft. That will move things along. > =20 >=20 --Apple-Mail=_AF7B0F37-728C-437D-8399-7716C80D0888 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel <vidhi_goel@apple.com> wrote:
2. = If there is no such energy, or there are contentious issues that will = draw out the process to get this to RFC, than I can initiate a review of = upgrading 3465 to PS directly. I think we all agree this would be an = improvement on the status quo, but isn't worth doing if 3465bis is going = to happen quickly.

I don=E2=80=99t think 3465 can be upgraded to PS = as-is.

Why not?

Because L=3D2 as MUST is too constrained for high BDPs = and most stacks don=E2=80=99t even follow that.


On Aug 12, 2021, at 11:39 AM, = Martin Duke <martin.h.duke@gmail.com> wrote:



On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel <vidhi_goel@apple.com> wrote:
2. If there is no = such energy, or there are contentious issues that will draw out the = process to get this to RFC, than I can initiate a review of upgrading = 3465 to PS directly. I think we all agree this would be an improvement = on the status quo, but isn't worth doing if 3465bis is going to happen = quickly.

I = don=E2=80=99t think 3465 can be upgraded to PS = as-is.

Why not?
 
Personally, I like the = structure of 6928 more than 3465. Is it possible to rope in ABC (3465) = in a 6928bis and
change the title - Would like to hear more = from the authors of both the = RFCs.

It will take a bit more editorial work, = but there's no reason a single document can't obsolete both RFCs.
 

Thanks,
Vidhi

Thanks for writing a = draft. That will move things along.
 


= --Apple-Mail=_AF7B0F37-728C-437D-8399-7716C80D0888-- --Apple-Mail=_CFF5B9CD-6B9F-45A7-BF49-5E8A92EA617C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgxMjE4 NDQzNFowLwYJKoZIhvcNAQkEMSIEIE5AA2uV4CEZtDEZJi1GPxZwDE6oyy8b1rrKJ/TNRwFzMIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAKk2oS05cCsZk4iPX4cXoToB0B+tz9yshIY2liTQI7mCujOLjj24tHha oms7q7dWyZIbjSpyrF0YAUgMVojE5zhQo09PRM5OMYEddijYqK3my5ZhQpknzlGldT7rH9F+I/rT SJ7U0SdR48blfVDibRSXVd6Yamgy7Jqe/V2IBD9Au1UbMoxww1cvyJbmxYFm4MzHI0HmjEEzj4cg FesJWQRmqnCQNGHwkNlyoVDZFdjzoPVY384+F67UNi9wldZpP3jIlqETVqwEJkHlDfzqHwPAmo70 vtHi4bRwnPh/ZlrARADs53nSCUUcqoK4RqsDMW2CzUnIZPmcfe/efp/3bPkAAAAAAAA= --Apple-Mail=_CFF5B9CD-6B9F-45A7-BF49-5E8A92EA617C-- From nobody Thu Aug 12 11:55: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 B56973A464A for ; Thu, 12 Aug 2021 11:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 4LXDbn5NGQjc for ; Thu, 12 Aug 2021 11:55:50 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDA73A464E for ; Thu, 12 Aug 2021 11:55:49 -0700 (PDT) Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 6229F7220B805; Thu, 12 Aug 2021 20:55:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Michael Tuexen In-Reply-To: <409938D1-CF12-4238-8641-C24C173B2E33@apple.com> Date: Thu, 12 Aug 2021 20:55:40 +0200 Cc: Martin Duke , Yuchung Cheng , Extensions , Mirja Kuehlewind , Mark Allman Content-Transfer-Encoding: quoted-printable Message-Id: <9D606388-C6C3-4ADD-B9E0-7B1F69D296ED@lurchi.franken.de> References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com> <409938D1-CF12-4238-8641-C24C173B2E33@apple.com> To: Vidhi Goel X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 18:55:55 -0000 > On 12. Aug 2021, at 20:44, Vidhi Goel = wrote: >=20 >> On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel = wrote: >>> 2. If there is no such energy, or there are contentious issues that = will draw out the process to get this to RFC, than I can initiate a = review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis is = going to happen quickly. >>=20 >> I don=E2=80=99t think 3465 can be upgraded to PS as-is. >>=20 >> Why not? >=20 > Because L=3D2 as MUST is too constrained for high BDPs and most stacks = don=E2=80=99t even follow that. My reading is: * However, ABC with L=3D1*SMSS bytes is more conservative in a number of key ways (as discussed in the next section) and therefore, this document suggests that even though with L=3D1*SMSS bytes TCP stacks will see little performance change, ABC SHOULD be used. * This document specifies that TCP implementations MAY use L=3D2*SMSS bytes and MUST NOT use L > 2*SMSS bytes. * The exception to the above suggestion is during a slow start phase that follows a retransmission timeout (RTO). In this situation, a TCP MUST use L=3D1*SMSS So I don't think saying L =3D 2 is a MUST is a summary. For me it is = more important that it says MUST NOT be larger than 2. Best regards Michael >=20 >=20 >> On Aug 12, 2021, at 11:39 AM, Martin Duke = wrote: >>=20 >>=20 >>=20 >> On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel = wrote: >>> 2. If there is no such energy, or there are contentious issues that = will draw out the process to get this to RFC, than I can initiate a = review of upgrading 3465 to PS directly. I think we all agree this would = be an improvement on the status quo, but isn't worth doing if 3465bis is = going to happen quickly. >>=20 >> I don=E2=80=99t think 3465 can be upgraded to PS as-is. >>=20 >> Why not? >> =20 >> Personally, I like the structure of 6928 more than 3465. Is it = possible to rope in ABC (3465) in a 6928bis and=20 >> change the title - Would like to hear more from the authors of both = the RFCs. >>=20 >> It will take a bit more editorial work, but there's no reason a = single document can't obsolete both RFCs. >> =20 >>=20 >> Thanks, >> Vidhi >>=20 >> Thanks for writing a draft. That will move things along. >> =20 >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Aug 12 12:06: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 717BA3A468B for ; Thu, 12 Aug 2021 12:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIs76XnreyQJ for ; Thu, 12 Aug 2021 12:06:24 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 252A23A4689 for ; Thu, 12 Aug 2021 12:06:24 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id be20so11905324oib.8 for ; Thu, 12 Aug 2021 12:06:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=zbufhXqzgVrw7aiJEyHqrX0+jnL6pbh3yttiSn+Xihg=; b=CE0WCXm1VyghujcMLZ3QEqvMqVBJgcA/sCsN8uy2GZzsi7VhgfW+oqBZbx1Sm+5v27 8wUIG+0qaggy16FBeohDOt2IyCef6wKRhbNdmYZ/gmX6q7dX7WwpCPD8L+5LKJQJeeX8 FTj8iCLA68uvZFr86KexiYFiZRdfKRMZoXw89vjoMmh/RN+EHdQJ2UuvZB5pYLkLexj6 n45fG2CqZoATOxwFYrU7Lqlm3Lg+oH7p6OOAZQw6PYLksLviTsJ4OLt6nX9zAraxscDG foNSSn0N9bl3pKyMtz0g+if8cNm428FCKq6KaJM5dnKlcJB3HMH2JmTCeibySEbbiGyW oIyw== X-Gm-Message-State: AOAM530US2K+sVQD4sqZ6LFlkiPXxYuEEn1ulr5CK9YaF1u3gV5cra7u T7R2ZFTPLB+eP7YNApcJ0wiEzQ== X-Google-Smtp-Source: ABdhPJxVDWS7rumqyhmtQlDhaYJzbix+gc14u+PNqYskdrWAWALth9KS3RxZY4xeiMMwroViY/eVEA== X-Received: by 2002:aca:400a:: with SMTP id n10mr4633703oia.127.1628795183470; Thu, 12 Aug 2021 12:06:23 -0700 (PDT) Received: from [192.168.1.208] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id 45sm834537otm.43.2021.08.12.12.06.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Aug 2021 12:06:22 -0700 (PDT) From: "Mark Allman" To: "Martin Duke" Cc: "Mirja Kuehlewind" , "Yuchung Cheng" , Extensions Date: Thu, 12 Aug 2021 15:06:20 -0400 X-Mailer: MailMate (1.13.2r5673) Message-ID: <66DA3C67-BED1-4B15-BA1D-01F4775E58D4@icir.org> In-Reply-To: References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_1E117BB0-2C59-4C72-A438-FD095FA3C4D8_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 19:06:31 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_1E117BB0-2C59-4C72-A438-FD095FA3C4D8_= Content-Type: text/plain > If I understand the current document state correctly, the current ABC > guidance we have is > > RFC3465 (Experimental): L=2 > RFC5681 (PS): L=1 Yep. > 1. The most comprehensive solution would be a 3465bis PS doc that > obsoletes 3465 and updates 5681 with L= Infinity, 8, or > whatever number the group decides on. If we agree this is the > right thing to do and someone has the energy to drop > 3465bis-00, then let's do so to have a basis of discussion. Approach-wise this is OK. But, there are issues here ... - First, we could probably move to L=2 pretty easily (as standard). We have been using byte counting with standard delayed ACKs for a long time in stacks that do not use an L. So, we have effectively been living with this. - Moving to L > 2 (5, 10, \infinity) would seem to me to require someone to make the case that we have experience that suggests this is OK. Or, that we have some suggestions that we could run at experimental L>2 for a while. There have been a bunch of folks saying that we understand L > 2 works fine, but in pretty hand-wavy, mailing list sorts of ways. I.e., there are stretch ACKs. Or, there is an implementation with an L. Or, there are offload systems that aggregate packets/ACKs. When we haven't seen---that I am aware of---is a discussion that shows L > 2 is a good idea. Or, that it isn't a bad idea. It seems to me that the usual way these things get advanced is to offer some tangible / concrete assessment that says "hey, this is perhaps a reasonable thing to change". - I am not saying we shouldn't change L. Perhaps we should. E.g., with pacing it seems like a no-brainer. I am just saying that the case hasn't even been attempted. > 3. There might be interest in a more generalized 5681bis, but my > instinct is that this is a bigger job that will delay the most > urgently needed update -- which is not to say that we shouldn't > do that document too. I think a very scoped 5681bis could be done quickly. If it is a change to L and/or a change to IW we can use the 6298 model and make the very tiny text change and add an appendix that justifies the change. So, the normative text of the RFC changes very little. > 4. However, I don't think it would be too much of a stretch to rope in an > IW update (6928bis) in 3465bis, if it doesn't add too much time. It all > fits in with the general theme of the maximum allowable burst on the > internet in the absence of any sort of pacing (ack-driven or > stack-enforced). Hm. Well. Hm. I'd have to think about that one. I do think that just defining some general burst limit could prove to be thorny. E.g., if you said the max burst size was 10 so IW=10 would be fine then would a stretch ACK that covered 20 packets only be able to liberate 10 packets? Or, if we said a stretch ACK could liberate 20 packets would that imply an IW of 20 packets? And, do we really draw no distinction between what we can send into an unknown network and what we can send into a network we have probed enough to have some idea about? This seems difficult. allman --=_MailMate_1E117BB0-2C59-4C72-A438-FD095FA3C4D8_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCYRVxLBEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizkYPAJ0d7QEpsdVnKXoMSprXN8QHorTPwwCeJeeH ujUBCR6oNiT103PSVWKYQKQ= =r89/ -----END PGP SIGNATURE----- --=_MailMate_1E117BB0-2C59-4C72-A438-FD095FA3C4D8_=-- From nobody Wed Aug 18 01:32: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 0A2BA3A0D27; Wed, 18 Aug 2021 01:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 Sa0msxWq1-3Y; Wed, 18 Aug 2021 01:32:54 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 0CB1A3A0D25; Wed, 18 Aug 2021 01:32:53 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id t68so2095138qkf.8; Wed, 18 Aug 2021 01:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=otJXQonvaJX9EQ++VxevVrAJPH0/rKvssrctZhc+L84=; b=PLQsXBxcNbZZXP1Nm41iBKv39ZmCClFZf1/9DC1ojJ5+QqOqH8VYoYLsLD+pR06+DF Wu9c20mGTLHoKsWnrwUd46MqSbnUCMLRJntm5e7wLKZOECClH1N3McKtEskI5R09e4iO F6hpdqyOcuAU0uYmiYI2AbGoZXx76ZEOfIsj2mm/AFF4a2p90hDItm8IBX+WcpltMbNK /aY0f7L2g1n4q2m5FJxubSz9xhzkeZIg0Z8jRCQq1dCuOIoW8vtL/CwVF6hdZFBpJbpH Jnm2X8tZ7m7BVegj55guNjVRVbO02T/kx5apgNOzzMl60aIMMe2D0zxX0L3isVEiWCfL FAXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=otJXQonvaJX9EQ++VxevVrAJPH0/rKvssrctZhc+L84=; b=fhmgVqk7vDshUUwLfgMCEsj+nTYr+PpnXMFENRAGzRM1bxYXNDQFpQnQ3HlnhdAufg nYAkvNygkQyY74oLC074mQJ6DZ0RyyCQ/lob06dhwO2AT3R6gdoW13Mq/Sa16lZYjH9f keJ1SX+jzrBH4vFp47LiKEf+H9DjsUICFSp5hrIN7DyPoyK97jOn3GJthPjtXtee09bO FrbIUKdKtmvVC2nwpS6iUJbwvLgJVOsQAPtOQAdaucLduPrUM1ezAYHaABPMLFIXtLAq sOnshNxYHbEL8kzXf+9NM57h4ma07CFd6OeNN0Mw9KwsJTlcerGepHNHNzA4Cv5m0X+l pjCQ== X-Gm-Message-State: AOAM531pp3yatHYKGE2lfpN6RcMzZ5kf1kfyiNY9hWVB0/T+HxY3i1Ej HMKhpRpZRzFAPNA/K4UynCPDlHsZiCyxN+lyhd5IOxDX X-Google-Smtp-Source: ABdhPJw2nSTJZk5hR+64bwSLdZ6UjHbTd3OkclRHeXh+QEL0vGqov80mZxzbR66HIAUHvSrIdmPLC1vsksVqNtoO2k0= X-Received: by 2002:a05:620a:17a9:: with SMTP id ay41mr8266152qkb.454.1629275572085; Wed, 18 Aug 2021 01:32:52 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Wed, 18 Aug 2021 01:32:41 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Cc: tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000b7278c05c9d147d5" Archived-At: Subject: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 08:32:57 -0000 --000000000000b7278c05c9d147d5 Content-Type: text/plain; charset="UTF-8" Hi, The chairs think 8312bis draft is in good shape and it's ready for submission. We know we had some discussions on how to handle ABC draft in the draft during the last WG meeting and there are on-going related discussions on the ML. However, we still think we can proceed with the draft as the relevance between the draft and the current discussions is not very high. If anyone has different thoughts on this, please let us know. Otherwise, we will prepare a writeup soon and submit it to IESG. Thanks, -- Yoshi --000000000000b7278c05c9d147d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The chairs think 8312bis draft is in good sha= pe and it's ready for submission.
We know we had some discuss= ions on how to handle ABC draft in the draft during the last WG meeting and= there are on-going related discussions on the ML.
However, we st= ill think we can proceed with the draft as the relevance=C2=A0between=C2=A0= the draft and the current discussions is not very high.

If anyone has different thoughts on this, please let us know.
Otherwise, we will prepare a writeup soon and submit it to IESG.

Thanks,
--
Yoshi
--000000000000b7278c05c9d147d5-- From nobody Thu Aug 19 09:00:27 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 328A53A21CB; Thu, 19 Aug 2021 09:00:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francis Dupont via Datatracker To: Cc: draft-ietf-tcpm-rfc793bis.all@ietf.org, last-call@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162938881515.25728.6614973558649060815@ietfa.amsl.com> Reply-To: Francis Dupont Date: Thu, 19 Aug 2021 09:00:15 -0700 Archived-At: Subject: [tcpm] Genart last call partial review of draft-ietf-tcpm-rfc793bis-24 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: Thu, 19 Aug 2021 16:00:16 -0000 Review is partially done. Another assignment may be needed to complete it. Reviewer: Francis Dupont 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-rfc793bis-24 Reviewer: Francis Dupont Review Date: 2021-08-18 IETF LC End Date: 2021-08-02 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Nits Major issues: None Minor issues: None Nits/editorial comments: Only editorial comments: there are a lot of inconsistencies on US/UK spelling for instance acknowledgment vs acknowledgement, or e.g., vs e.g.. These should be addressed by the RFC Ediror. Note there is an i.e, (vs correct i.e.,) in 3.8.6.2.1. page 47. I did not fully verify the technical details mainly because I review I-Ds in public transports so without the whole collection of merged RFCs and errata. In fact I only checked the figure 5 section 3.3.2 page 17 because an arrow missed from it in the original RFC: this is addressed by the note 2 (I compared with the fixed state transition diagram of the TCP/IP Illustrated volume 2). There is a small note for the IESG in section 5 page 92 in the very last paragraph about a PERPASS/privacy review. Regards From nobody Mon Aug 23 01:43: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 E648B3A14E3; Mon, 23 Aug 2021 01:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 CcToroZPFT0X; Mon, 23 Aug 2021 01:43:54 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 BE73B3A14D1; Mon, 23 Aug 2021 01:43:53 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id j9so9230762qvt.4; Mon, 23 Aug 2021 01:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rb5bjDrM8Vi6dokDu7nIS6oNVETsPvL/kYTYF/oP4Sw=; b=Q4k1pdljsD1BwsLjWYzxxOVjxyUKSPkVyWdlJp4U+8XzYo8IZxmkBTqYnpUSQx4yoM x8LfPWhBTyQeprbJw6d++c3QYukXjosCBGFA6/2hwCbuWX/AX3WPeAIasr4kr2PqdLDn WePiHiFVDpLQCXs/pV4noCvRVdx88hIkUO7DcRSkYmHuag0v3BZrTjObbS7LK7QRh83B 9q4w+C6CzAqDZ5P4aJuIkS1VJqkBz6y0HJKgI/zksPWHr8ojJPKv+Sz4oq0xEAO/WepX t4baghPZG1wuNbX8OkdORTLqMSXJHQQlZLVvqcT/MmJr1f7QfDe3j+vEV6QJTUvKBPZx cH4g== 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=rb5bjDrM8Vi6dokDu7nIS6oNVETsPvL/kYTYF/oP4Sw=; b=e1Q/JQQVbnyPJZHzvAt8cL/3T5z5Zc4UKIxuAqDUlj9a7GcXE4KhiWqxezkz+HmMwT 418ToZuyKrfg2fHZ5j+Z2CEpVA1LDmL3IiBwF9mzYDy+1/xhBtp/FNJvQSc9+7T36HKY EmKAa5nZHf6bAuQR2xFXLysfN66Uf3CgD/1vsvubvhTVsA5sqKfTPlDO/cPncHzsl9hi Y36QUG/BG/4fPRzQXl0edDHeP8ywkOqsCo8I450HVaAcAYXYPIvMA3eOWgbInGyTy4P2 YWJACadNi/JreuVpQ1nny3kEnUBMAIP2LwmRmYoYOs+SCJTisOZ7RxC/H2hUtm2Vqmsx vdlg== X-Gm-Message-State: AOAM532K7m0+PWoKmQ28gS+q2v8bG8ziJT3OT9tMBiLWeCKeuKieZ2SN HL0bUmueYmVCNHM4kC4a5X7dsXqvMmWN+wXcJ/X6FN6i+xc= X-Google-Smtp-Source: ABdhPJwnVh1EavRA+6Ew7uVmV1Si4OZrnDavYt8Q+mloPjuZieTLFKOIq/SGk8Efr+1c97DdiE/qC0I42oWP03tL498= X-Received: by 2002:ad4:4b61:: with SMTP id m1mr442260qvx.32.1629708230232; Mon, 23 Aug 2021 01:43:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Mon, 23 Aug 2021 01:43:39 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Cc: tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000268dbe05ca3604db" Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 23 Aug 2021 08:43:57 -0000 --000000000000268dbe05ca3604db Content-Type: text/plain; charset="UTF-8" Hi authors, I start preparing the write-up for 8312bis draft to submit it to IESG. In order for this, could each of you provide the answer for the following question? 7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Thanks, -- Yoshi On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida wrote: > Hi, > The chairs think 8312bis draft is in good shape and it's ready for > submission. > We know we had some discussions on how to handle ABC draft in the draft > during the last WG meeting and there are on-going related discussions on > the ML. > However, we still think we can proceed with the draft as the > relevance between the draft and the current discussions is not very high. > > If anyone has different thoughts on this, please let us know. > Otherwise, we will prepare a writeup soon and submit it to IESG. > > Thanks, > -- > Yoshi > --000000000000268dbe05ca3604db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi authors,

I start preparin= g the write-up for 8312bis=C2=A0draft to submit it to IESG.
In or= der for this, could each of you provide the answer for the following=C2=A0q= uestion?

7) Has each author confirmed that any and= all appropriate IPR disclosures required for full conformance with the pro= visions of BCP 78 and BCP 79 have already been filed.=C2=A0
=C2= =A0 =C2=A0 If not, explain why?

Thanks,
<= div>--
Yoshi

On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida <= ;nsd.ietf@gmail.com> wrote:
H= i,
The chairs think 8312bis draft is in good shape and it's re= ady for submission.
We know we had some discussions on how to han= dle ABC draft in the draft during the last WG meeting and there are on-goin= g related discussions on the ML.
However, we still think we can p= roceed with the draft as the relevance=C2=A0between=C2=A0the draft and the = current discussions is not very high.

If any= one has different thoughts on this, please let us know.
Otherwise= , we will prepare a writeup soon and submit it to IESG.

Thanks,
--
Yoshi
--000000000000268dbe05ca3604db-- From nobody Mon Aug 23 01:47:26 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 D90683A1552; Mon, 23 Aug 2021 01:47:10 -0700 (PDT) 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 93xLxAZTIO-x; Mon, 23 Aug 2021 01:47:02 -0700 (PDT) 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 24F4D3A1547; Mon, 23 Aug 2021 01:47:02 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1815:5480:b768:b865]) (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 0D016600370; Mon, 23 Aug 2021 11:46:53 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629708414; bh=9NfdlAgj+zLdiPxutuY7M8V81wsEQRR9trWMB89P5ac=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=AaaZC1jHd64lAKbYqKvfeBPrv9UwAeLblIG0anUjfOKsbh9dGZbNPGSRw+egx3nKA KRb0xsF8zmlvrOUNZMspweqvjKvm4L0i1gvsRHRqcnAT4a81EpRKOyOE2kg8B/u9UC Y+HoNVEpZQkVLkC0C4wxnx2f8XCTX7/Se16GqX1A= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FF23FBE6-8CE4-439A-BC23-5FB4AECD8BBE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 23 Aug 2021 11:46:51 +0300 In-Reply-To: Cc: "tcpm@ietf.org Extensions" , tcpm-chairs To: Yoshifumi Nishida References: X-MailScanner-ID: 0D016600370.A00B8 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 23 Aug 2021 08:47:23 -0000 --Apple-Mail=_FF23FBE6-8CE4-439A-BC23-5FB4AECD8BBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2021-8-23, at 11:43, Yoshifumi Nishida wrote: > 7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. Confirmed (for myself). Thanks, Lars --Apple-Mail=_FF23FBE6-8CE4-439A-BC23-5FB4AECD8BBE 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEjYHsACgkQVLXDCb9w wVfF6w//WdzEZN8YDXPh6vMSqIN9jnl1UPg3U5/4TPalIDXkFmd4SOSvnvljYmo1 TDTjxetXB6UqW4B0d0XxroGTdQy2sqhxK21trmKobcvnY6xifjXmxNKtMLBzptp9 ZERgR6951OlUGgJx8+4RHWPLUgNxAoI7PgO5EAL11wAyqYK+yvJdSyh4/2VXXmTx 7mEbR5EGA24eOz3aA8+dQMz+sfi1SXSE2IeYy/Ujh7kSSW2JBSWUjIbfR7SGgrDu COUBeYuHH6/PoivDzjzsBvZvk7DDk3s/QewuxPwFOq+5k++1Yx9bW60eJdN9ZWoL 1SASkDlB8yWL8qw+R98AmhyGubtLdOeRSx2b/+Ui4h2zfBWzthxDOACxAYgPG45B Hmq5XyBCh7lqqnAAVrSi0TsV4o0Cg+UoLFn1PunCazeWCiRyyr1Wr6dAe5RmgObH BoHKmeAZV42AsVx+f6SGFSVJNv7WwqZBwjVeN82Bi4KQuHr50JyYUlgGFzwIJZ1l 8L5Nv5bajCaXmnwWBXM+YxOxxYpVeCfTO0pyj5mz52aQRFYYTEfuHOYifHWHbrfl 5H4PTsJUu/qfZFtSmiiQDOHp9ASi42V1s5vU08Bqm5eQZIJbTUA19uDAuNq6xLbV sztFCQnG/3nV6q4vIA4UTBXRmpNHeoWGbbyGPP1o7wsw6FhjmiE= =UxjL -----END PGP SIGNATURE----- --Apple-Mail=_FF23FBE6-8CE4-439A-BC23-5FB4AECD8BBE-- From nobody Mon Aug 23 23:21: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 9E6B83A02F7; Mon, 23 Aug 2021 23:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_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=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 sQbyyAH5gbmo; Mon, 23 Aug 2021 23:21:32 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 8115B3A00DB; Mon, 23 Aug 2021 23:21:31 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 17O6HFDj025135; Mon, 23 Aug 2021 23:21:30 -0700 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=RYnQtveAyhglfSm54SVAk+TuZaWBesFewc2YjvYCeM0=; b=EcteqMXgNNqECSlj+d9MM/oAJl52tjjX81TppW6k9peOAvL2BgyJ2PwwIBPn+EucubXE jGPJwax3y5VfT2zrXhNoMtRjdpw8MXIP6qznVRX7ObWv0rAdKx/Q1LUr6No4quPv8SEZ 61u29hJ2M2uMDSVSdoQNdd13I0WHKe7dFEApGTckhEQ6IWHGaj1FYeTvy0u7Bx7MTS1Q /7QweDPfk0StMXTg0DrAvBvOCrCBWdS4BFRo0Lh/3yLJSqUW2yksN5ChaBLjeO51sOKF GtXQb3R7lzl7c/KPZHEaoofmHJfV+x9dyQA0lPfTr/yWw835gvmJ+9qWEmELCcfmKN4T Sw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3ajw09y05x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Aug 2021 23:21:30 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QYB00XVAYZSUHC0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 23 Aug 2021 23:21:28 -0700 (PDT) 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.9.20210415 64bit (built Apr 15 2021)) id <0QYB00R00YPE8P00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 23 Aug 2021 23:21:28 -0700 (PDT) X-Va-A: X-Va-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f X-Va-E-CD: adbc7d1ec27a9ce510496a25fc3bbf38 X-Va-R-CD: b76cc16daaabaa6566928e6dad6db350 X-Va-CD: 0 X-Va-ID: 1cdfa024-2179-4944-80aa-bb8ca65c2d83 X-V-A: X-V-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f X-V-E-CD: adbc7d1ec27a9ce510496a25fc3bbf38 X-V-R-CD: b76cc16daaabaa6566928e6dad6db350 X-V-CD: 0 X-V-ID: bc892e54-6973-4899-a69f-ead58516d03f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-24_01:2021-08-23, 2021-08-23 signatures=0 Received: from smtpclient.apple (unknown [17.11.185.201]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QYB00RGLYZS1X00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 23 Aug 2021 23:21:28 -0700 (PDT) From: Vidhi Goel Message-id: <9EB63B1D-1339-402B-9FA3-27B804D1EBCB@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_003AB0A2-4B26-4EDA-B262-707C3157CFF8"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Mon, 23 Aug 2021 23:21:28 -0700 In-reply-to: Cc: "tcpm@ietf.org Extensions" , tcpm-chairs To: Yoshifumi Nishida References: X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-24_01:2021-08-23, 2021-08-23 signatures=0 Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 24 Aug 2021 06:21:48 -0000 --Apple-Mail=_003AB0A2-4B26-4EDA-B262-707C3157CFF8 Content-Type: multipart/alternative; boundary="Apple-Mail=_32FFEF66-D137-4F7F-8149-591BFDB7B907" --Apple-Mail=_32FFEF66-D137-4F7F-8149-591BFDB7B907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed.=20 Confirmed from my end. Thanks, Vidhi > On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida = wrote: >=20 > Hi authors, >=20 > I start preparing the write-up for 8312bis draft to submit it to IESG. > In order for this, could each of you provide the answer for the = following question? >=20 > 7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed.=20 > If not, explain why? >=20 > Thanks, > -- > Yoshi >=20 > On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida > wrote: > Hi, > The chairs think 8312bis draft is in good shape and it's ready for = submission. > We know we had some discussions on how to handle ABC draft in the = draft during the last WG meeting and there are on-going related = discussions on the ML. > However, we still think we can proceed with the draft as the relevance = between the draft and the current discussions is not very high. >=20 > If anyone has different thoughts on this, please let us know. > Otherwise, we will prepare a writeup soon and submit it to IESG. >=20 > Thanks, > -- > Yoshi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_32FFEF66-D137-4F7F-8149-591BFDB7B907 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
7) Has each author confirmed that any and all = appropriate IPR disclosures required for full conformance with the = provisions of BCP 78 and BCP 79 have already been = filed. 

Confirmed from my end.

Thanks,
Vidhi

On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> = wrote:

Hi authors,

I start preparing the = write-up for 8312bis draft to submit it to IESG.
In order for this, could each of you provide the answer for = the following question?

7) Has each author confirmed that any = and all appropriate IPR disclosures required for full conformance with = the provisions of BCP 78 and BCP 79 have already been = filed. 
    If not, explain why?

Thanks,
--
Yoshi

On Wed, Aug 18, 2021 at 1:32 AM = Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi,
The chairs think 8312bis draft is in good = shape and it's ready for submission.
We know we had = some discussions on how to handle ABC draft in the draft during the last = WG meeting and there are on-going related discussions on the = ML.
However, we still think we can proceed with the = draft as the relevance between the draft and the current = discussions is not very high.

If anyone has different thoughts = on this, please let us know.
Otherwise, we will = prepare a writeup soon and submit it to IESG.

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

= --Apple-Mail=_32FFEF66-D137-4F7F-8149-591BFDB7B907-- --Apple-Mail=_003AB0A2-4B26-4EDA-B262-707C3157CFF8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgyNDA2 MjEyOFowLwYJKoZIhvcNAQkEMSIEIAQyaniYOWzoTTh/ZdEwVzZMEsL9LAFYVXyEfVPtekWYMIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAJ4v+QaKb2wxg7VGRkIcgFH9+9tBMWcEtZXI3PZdiBkmcb/59OSjTkDD nj7Q3JHgOsxP+OIbNcWfmJxnCVykYPK6YVWKFcqlJI9JwHAoxc4zCxXebthzXKKig3Gv7JBkJ5If ipkJ73Mfzxq6uglp1LqEE5UYNXA3Mcb8yuzXGkGhP2Id9IkbtrL7OZKCfkjDtsbqnv+Lq/96gDFe 7GUrUrI52abJPWV9s9D6rqlkqOseyZf+HDbq5ZaB2MB4AEtOGdMvA3Un7y/KVOFH35RiXsaqLryK pxUDLh2S/2iZQ2x2hKxehfDyhsoP4EIkzk/MNCUGg9GWDMs2cILMIbxZdGsAAAAAAAA= --Apple-Mail=_003AB0A2-4B26-4EDA-B262-707C3157CFF8-- From nobody Tue Aug 24 10:40: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 4D41A3A0883; Tue, 24 Aug 2021 10:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_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=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 aSbGOwfLIzib; Tue, 24 Aug 2021 10:40:18 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (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 7544C3A087E; Tue, 24 Aug 2021 10:40:18 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 17OHXCDf023191; Tue, 24 Aug 2021 10:40:16 -0700 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=Let5jPIFeVX04CveXSOh7O6kSeTlzJsGU9RZwTfa0WQ=; b=p9pVMwXO8PjLNYxFaL1sRWmZqfqAuP4TguXynS7GXuHeapf9Msvn5axzetRCcGrScunU czi62ppD0ydqZ+2tu1dlr5y8/5iB9bNhkRizrzPTWdkKpU5z3uDWIjxsIpc8z9sXp81u DnkVpjvZ6HKAwIrGBDTpq6NY48O0UBqxeNse9iTPhrySroO4p5jlaThatvarWhmhHNdf DzXWGYVjqBsHnOwaPWS8S7yrY8sCC6KBJjKhbWxHwzzCfsfQjXk9u7MWQVQ36tIGi3O3 gke85VebRpbGF1ehVXaX29FdP3GNF6LH7r9W/dPcKqY+Nfy+EJY4W8guCd0FofJGnAO4 BQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3akhfjbex3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Aug 2021 10:40:16 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QYC00QGDUF468A0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 24 Aug 2021 10:40:16 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QYC00O00UCEW700@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 24 Aug 2021 10:40:16 -0700 (PDT) X-Va-A: X-Va-T-CD: d1d9163fce249ff31ca51556dadc265c X-Va-E-CD: adbc7d1ec27a9ce510496a25fc3bbf38 X-Va-R-CD: b76cc16daaabaa6566928e6dad6db350 X-Va-CD: 0 X-Va-ID: 428a9cee-fc72-4e36-b440-4689d9cc6653 X-V-A: X-V-T-CD: d1d9163fce249ff31ca51556dadc265c X-V-E-CD: adbc7d1ec27a9ce510496a25fc3bbf38 X-V-R-CD: b76cc16daaabaa6566928e6dad6db350 X-V-CD: 0 X-V-ID: 11389426-1bae-492f-a037-e3db7159eb03 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-24_05:2021-08-24, 2021-08-24 signatures=0 Received: from smtpclient.apple (unknown [17.11.163.28]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QYC00E95UF2EF00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 24 Aug 2021 10:40:16 -0700 (PDT) From: Vidhi Goel Message-id: Content-type: multipart/signed; boundary="Apple-Mail=_885075EB-97C3-49F4-93A9-70950C50F4FD"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Tue, 24 Aug 2021 10:40:14 -0700 In-reply-to: <9EB63B1D-1339-402B-9FA3-27B804D1EBCB@apple.com> Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , tcpm-chairs To: Lisong Xu , Injong Rhee , Sangtae Ha References: <9EB63B1D-1339-402B-9FA3-27B804D1EBCB@apple.com> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-24_05:2021-08-24, 2021-08-24 signatures=0 Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 24 Aug 2021 17:40:25 -0000 --Apple-Mail=_885075EB-97C3-49F4-93A9-70950C50F4FD Content-Type: multipart/alternative; boundary="Apple-Mail=_79D8DFE9-8CAC-45BC-8AD9-5A3EBD6DB0E1" --Apple-Mail=_79D8DFE9-8CAC-45BC-8AD9-5A3EBD6DB0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +Lisong, Injong and Sangtae. >> 7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed.=20 >> If not, explain why? Could you reply to that email providing your individual confirmation = about IPR disclosure? Thanks, Vidhi > On Aug 23, 2021, at 11:21 PM, Vidhi Goel = wrote: >=20 >> 7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed.=20 >=20 > Confirmed from my end. >=20 > Thanks, > Vidhi >=20 >> On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida > wrote: >>=20 >> Hi authors, >>=20 >> I start preparing the write-up for 8312bis draft to submit it to = IESG. >> In order for this, could each of you provide the answer for the = following question? >>=20 >> 7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed.=20 >> If not, explain why? >>=20 >> Thanks, >> -- >> Yoshi >>=20 >> On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida > wrote: >> Hi, >> The chairs think 8312bis draft is in good shape and it's ready for = submission. >> We know we had some discussions on how to handle ABC draft in the = draft during the last WG meeting and there are on-going related = discussions on the ML. >> However, we still think we can proceed with the draft as the = relevance between the draft and the current discussions is not very = high. >>=20 >> If anyone has different thoughts on this, please let us know. >> Otherwise, we will prepare a writeup soon and submit it to IESG. >>=20 >> Thanks, >> -- >> Yoshi >> _______________________________________________ >> 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=_79D8DFE9-8CAC-45BC-8AD9-5A3EBD6DB0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +Lisong, Injong and Sangtae.

7) Has each author confirmed that = any and all appropriate IPR disclosures required for full conformance = with the provisions of BCP 78 and BCP 79 have already been = filed. 
    If not, explain = why?
Could you reply to that = email providing your individual confirmation about IPR = disclosure?

Thanks,
Vidhi


On Aug = 23, 2021, at 11:21 PM, Vidhi Goel <vidhi_goel=3D40apple.com@dmarc.ietf.org> = wrote:

7) = Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. 
Confirmed from my end.

Thanks,
Vidhi

On Aug 23, 2021, at 1:43 AM, Yoshifumi = Nishida <nsd.ietf@gmail.com> wrote:

Hi authors,

I start preparing the write-up for = 8312bis draft to submit it to IESG.
In order = for this, could each of you provide the answer for the = following question?

7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. 
  =   If not, explain why?

Thanks,
--
Yoshi

On Wed, Aug 18, 2021 at 1:32 AM = Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi,
The chairs think 8312bis draft is in good = shape and it's ready for submission.
We know we had = some discussions on how to handle ABC draft in the draft during the last = WG meeting and there are on-going related discussions on the = ML.
However, we still think we can proceed with the = draft as the relevance between the draft and the current = discussions is not very high.

If anyone has different thoughts = on this, please let us know.
Otherwise, we will = prepare a writeup soon and submit it to IESG.

Thanks,
--
Yoshi
_______________________________________________
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=_79D8DFE9-8CAC-45BC-8AD9-5A3EBD6DB0E1-- --Apple-Mail=_885075EB-97C3-49F4-93A9-70950C50F4FD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgyNDE3 NDAxNFowLwYJKoZIhvcNAQkEMSIEIAdQu9XFxg3Z6PUq3HhIY/fmMrgR3pAYb2gVxw1Rdzy1MIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAE52V3HExFJK86jKm9+/1P0QTql2lZEgTaSXpo4Ofc6+1TsuJ5n17aU9 ywXJqXbREmcCOWRDwlKM6BOSn1SXv+EZ8KAnU9xptdvAzlQuZb7aB+vgml43ujvxmxVYOLDtyMDD S8jKijDBR5/UE3Q+sAefQ9Ho9vu3XwTjjgl7Z6fELxZzT/4uTUqsHuiqy9lOK3JqDU9WS9AfFL+I DWiOwkLTAi98ATMYHxihZQPB1EQ6imYte1YTE3UpEgK9JG6qwFi5tP8njeUg1EztgMNvckV/RIfA 0VDZb8W2QUkdxz7Hejm4OD01H5tT8jxyeagcqcT8tNZZHOQrAW0eP53Iy4UAAAAAAAA= --Apple-Mail=_885075EB-97C3-49F4-93A9-70950C50F4FD-- From nobody Tue Aug 24 18:58: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 6E2AE3A1E75; Tue, 24 Aug 2021 18:58:43 -0700 (PDT) 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unl.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCtNKihHb17o; Tue, 24 Aug 2021 18:58:38 -0700 (PDT) Received: from mx0b-00246402.pphosted.com (mx0b-00246402.pphosted.com [148.163.143.147]) (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 CBFFB3A1E73; Tue, 24 Aug 2021 18:58:37 -0700 (PDT) Received: from pps.filterd (m0136271.ppops.net [127.0.0.1]) by mx0a-00246402.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 17P1qD5p010222; Tue, 24 Aug 2021 20:58:33 -0500 Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam07lp2048.outbound.protection.outlook.com [104.47.56.48]) by mx0a-00246402.pphosted.com with ESMTP id 3an7cjs6wr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Aug 2021 20:58:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oTsD/YtQsGagICTPgZPC3rFCJ1gtrcYzYdDwbFVSYXwMhJ1BPwQ/smHgvSYyRfKTMh1EQGQcOEbi1jeZfGYyeRnKoksYvR100qPOWxf3H3Heg3RQCrY8b50br8s8dR35AxUFq8CNLEqz9MePUW0OYjWLz7/VmKq1qeiPk/fTKSLQwuqPeN6R1r7UGloQFrMZZLjcP6dTdYbjei+Xa59+Ap62AcmWHImda5xf8YMV98bXuFBq+E9YjWIncqDMFrZY35in7gXp9eC3GWqlcTh4PbXSRgs6mZE1gtcDwzpVPGBs7TW96ITtZHjnQwOOs3QrsqkOyql8tDKEJT24E8TIsg== 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=h9Lb7gMHOJtZI60udU1/IVtdEl1ghRsNHSB3BYzXirA=; b=SJgjNPKpEAwzkle9w6pNVr37lJPqdKdy4GWPhGUYJvcrewxNuvZGxZbf2BhnVcK033hof/RrzPQPPEzOiBQaQA9oWUBVh3OKIVXzpb41H6KI8s4ltyXGeHlVFdcezkBgKmbSdVpMWTojVTJlgvHEf0Cu6T4F2S6bfVxhMDkIn6s4PRqBzB34WL+07nhDJs9NFTc2lwGsS5nnSf/D3PzmKf9PF7G9yBUpobZj8pa1wBsPYFA9r3N2K1yeb/Zc6oVmXsW+SYblEOKpMr35iPDUu9razAs/eSyusx8BbE7TEiThawn+PTs8ubriSXlQlL6zdhmy4l67y7HGaQkb4llPyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=unl.edu; dmarc=pass action=none header.from=unl.edu; dkim=pass header.d=unl.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unl.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h9Lb7gMHOJtZI60udU1/IVtdEl1ghRsNHSB3BYzXirA=; b=g7+X1BUDSZ5//PabzhP3758ti1P2goSOtG1ZvSW7IQCpKCpSC+CRw0kdEBaQKfL3ADEDRLbDu4bdZG0zVoZTSvVpbgz1kEj5J7KCsc03LmvewLdkOCsu4M0b1Fdg3StjQmZaxvYk+j+qkatkeH8msy1qneJaj86EInJbDTR3/bM= Received: from SN6PR08MB3933.namprd08.prod.outlook.com (2603:10b6:805:21::19) by SA2PR08MB6633.namprd08.prod.outlook.com (2603:10b6:806:114::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Wed, 25 Aug 2021 01:58:31 +0000 Received: from SN6PR08MB3933.namprd08.prod.outlook.com ([fe80::45ec:2b81:8d04:8652]) by SN6PR08MB3933.namprd08.prod.outlook.com ([fe80::45ec:2b81:8d04:8652%7]) with mapi id 15.20.4457.017; Wed, 25 Aug 2021 01:58:31 +0000 From: Lisong Xu To: Vidhi Goel , Injong Rhee , Sangtae Ha CC: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , tcpm-chairs Thread-Topic: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 Thread-Index: AQHXmVSvXAeu+C39qE+O8eKvK+LibQ== Date: Wed, 25 Aug 2021 01:58:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: apple.com; dkim=none (message not signed) header.d=none;apple.com; dmarc=none action=none header.from=unl.edu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f174c7c3-1541-4a26-c5c0-08d9676bd727 x-ms-traffictypediagnostic: SA2PR08MB6633: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kjaPju+YsySVpRjyncBh6Hl77Nk3X0EWuJRoBwSnSYc/T60P8MHfEdfIFS4LujmMrXHiC1eidZAu4Wb2p40xLxLxPFkuKWUZq3IwoJh23BjatCASrYxkdMa76eZ5e+bBofTh4cs36PM/EPFyb2sbu593NI2jr0lFeeYukST3eCFwox0fBRDLpKh16yo/6niCaNbI2uNJ6tf+w3JrxfTlqvGv7SEvuSRvh1QM0lQPkKr+KxCGcBYSMgCjYWTnABPwoFDf+IhLBpLAfDYxat3b78ll8EJ+5+CcqM2JkaQEfXDMOMKdqlmyj9F5LZrWDT4gLSBDefrcSelrrhWZE1jeBpQwErtxe3UuZ2C9NRSKTQ5nQ2bxdtQgLpb6Cv60bQBXQtqT+9XLtP+qCf7X0IWjZMH0T2qeYUNMr5DLrw9yHGVv4cxahZHiRNUyggsHSwewi/sLpGUk0Wxit763izLjsH/HDTfmDBJN6IwQoET23mKVfpwQi8J473jn2hAp3n4jtiAjda/0pg1G5AuV8TSR2Hj7e1sMz/LVS//T5vY+Okme/aej44YaExOtXD/baZBuvlY21qk+JOynmgts0up4rBH/Izro++SbM4fRzo8g74Gs3esEZ2EddCqx/WZ1cH/M/8ZUiqPuKk02HD2b/3NAChsM8nkDHhQSQ4NjnEReU8yedkWMkBIcFDUCOaj/2zk7TkXE/JQkuWmrBpaX16SQp2ruxNoFDFeXXsgAyy/CmenJa/AR4pKQIzbCy1p2/nqPkF1NdXXgznoj+8rpQbOdHZ8cuIPYgWHEp9f03A0DuPU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR08MB3933.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(33656002)(7696005)(966005)(86362001)(75432002)(55016002)(110136005)(2906002)(26005)(508600001)(9686003)(122000001)(53546011)(786003)(76116006)(316002)(186003)(71200400001)(19627405001)(6506007)(38100700002)(64756008)(5660300002)(8676002)(166002)(83380400001)(52536014)(66946007)(54906003)(91956017)(66476007)(66446008)(66556008)(8936002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?P3qIOJCzsS8z90By8lFW22ULXJBl+y67hIxvAjPn7Ix4WKE8fqvzgBbWL2?= =?iso-8859-1?Q?tzRIGsk7jodfmihZMpsQWsx1wAOexmSKbfnxrv1ie0rOeJET8lpxg+B/7g?= =?iso-8859-1?Q?pFDioOVSRORR9u75ZMu7wPhsrIutBQE33gd4XU3DYeYV0io6aMF3ZYPl0R?= =?iso-8859-1?Q?H42fwLGO/sGyrYZ4AS6FH8mQrKftGUZnaCSnHIuSQrjWKATSnZ6CEHoEix?= =?iso-8859-1?Q?AtPLJMXI6Wtka4YZsizMvdM7gQq4Th55LR9hPD3ypwosJwy0ThLzNLOvlF?= =?iso-8859-1?Q?UDXt15yd0MpcbeQPJ24z/Lkb6/x5CbXYq6lM6a+B+dhbXMHA64kUW/3VH2?= =?iso-8859-1?Q?95pEmc3mTKfYyS7tEtxhWzoGGhDDdPbEigKOEw9IjiH/uCliDrAQelVX31?= =?iso-8859-1?Q?Wp36KCqUcH5vedZaHgLmm2HUR7YdIVd/KWwqo7qBhQ2iCSQI6ssMWTgPzl?= =?iso-8859-1?Q?JINjJUBpOPUCJ0OI7VTrpP0ZmrwRr7vb5RYWoZF7t1krQtziKOCNHxcLDQ?= =?iso-8859-1?Q?sDSRx7sG+iVapRY113+1Mvytc74lrDDW8hGdzNRnKOBT3xyD9N5nNDZUeU?= =?iso-8859-1?Q?WuWymo2E8HeN4l2gF9dOW0Q0zqiIVRNIHViMEpTQIWvlUNGZDLxipV3zCn?= =?iso-8859-1?Q?h0nOX0J3NWxw+CldGP98wrRNjp8bdtktljS5FSjiFhlj75d8cLcUlrAe2D?= =?iso-8859-1?Q?4ywlxA4Cu+RAjnQptbUqmF5imvdw6uffrvsdeJipQCT7jm44YTqcLq8Pgi?= =?iso-8859-1?Q?ZUu8BTxCm51PttOJlkH6nWTwf4RV+LWeBGkL1fbvWBlx4CVMRaU03fBuFH?= =?iso-8859-1?Q?kP0hBUX8DGM84JlrYDr8FWB81iPtPLQ4br8GNoBRKV/zaxuBgLAZRPjt2s?= =?iso-8859-1?Q?l4/0KoPZnMl2Zi1qL2InSnTFGLXyOcWGvbfcI6VOUMH6T9Antix5ULD8wI?= =?iso-8859-1?Q?HOXn3MjteHxQ74/pWE2dnMAZC1vkg3sQYQiY9Qqlcz1FTixp3m+U9i1QDM?= =?iso-8859-1?Q?6y8Nfsq1cAD8FfTeu2bBoqXyK9LL30Z5RsEg3oucXtRspI/droS37UB+z1?= =?iso-8859-1?Q?TpOc4IzfNA/yUHKb0J6LMLKwU/v+/TDX+GraAXkSC+q3BbYNT2+bA8QTir?= =?iso-8859-1?Q?MHLlx8qqVGEOP3lsszH7i/imgfaPPlmELvPkX9oGXP6Cm/3hmbQq6nZwl+?= =?iso-8859-1?Q?InmuAf17yguz3ylVBT1e+SGEv2KOQ00lgEl8ZSNacxtBcxcV/X+GJ6vpj1?= =?iso-8859-1?Q?3SNcM4Xw39P065Sr/bk4Uy7d0hrnsLoV/Jgy4P4/kY92AV7/puX6vC9mls?= =?iso-8859-1?Q?/4A5NkSNxzabfve8l/je+VI4tCWc1NbtsSUPc7cmIcvVDZaBm2q7ubaaZZ?= =?iso-8859-1?Q?Jiy6e+Dqo7?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR08MB3933F2267B75F45426F38BBCDAC69SN6PR08MB3933namp_" MIME-Version: 1.0 X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR08MB3933.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f174c7c3-1541-4a26-c5c0-08d9676bd727 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2021 01:58:31.6446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fddb01ad-4983-436e-ab35-1af043b818c9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kUmbnhUQxJm4skGi5ul9spiBHANejiBv5A7t970eM027puP57wM1NXFh1m643MkV X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR08MB6633 X-Proofpoint-ORIG-GUID: e7YiMPectKOWRRa_ce2fhMllhu07QPK7 X-Proofpoint-GUID: e7YiMPectKOWRRa_ce2fhMllhu07QPK7 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 mlxlogscore=794 mlxscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108250010 Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 25 Aug 2021 01:58:44 -0000 --_000_SN6PR08MB3933F2267B75F45426F38BBCDAC69SN6PR08MB3933namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you, Vidhi! Yes, confirmed for me. Lisong ________________________________ From: Vidhi Goel Sent: Tuesday, August 24, 2021 12:40 PM To: Lisong Xu; Injong Rhee; Sangtae Ha Cc: Yoshifumi Nishida; tcpm@ietf.org Extensions; tcpm-chairs Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 Non-NU Email ________________________________ +Lisong, Injong and Sangtae. 7) Has each author confirmed that any and all appropriate IPR disclosures r= equired for full conformance with the provisions of BCP 78 and BCP 79 have = already been filed. If not, explain why? Could you reply to that email providing your individual confirmation about = IPR disclosure? Thanks, Vidhi On Aug 23, 2021, at 11:21 PM, Vidhi Goel > wrote: 7) Has each author confirmed that any and all appropriate IPR disclosures r= equired for full conformance with the provisions of BCP 78 and BCP 79 have = already been filed. Confirmed from my end. Thanks, Vidhi On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida > wrote: Hi authors, I start preparing the write-up for 8312bis draft to submit it to IESG. In order for this, could each of you provide the answer for the following q= uestion? 7) Has each author confirmed that any and all appropriate IPR disclosures r= equired for full conformance with the provisions of BCP 78 and BCP 79 have = already been filed. If not, explain why? Thanks, -- Yoshi On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida > wrote: Hi, The chairs think 8312bis draft is in good shape and it's ready for submissi= on. We know we had some discussions on how to handle ABC draft in the draft dur= ing the last WG meeting and there are on-going related discussions on the M= L. However, we still think we can proceed with the draft as the relevance betw= een the draft and the current discussions is not very high. If anyone has different thoughts on this, please let us know. Otherwise, we will prepare a writeup soon and submit it to IESG. Thanks, -- Yoshi _______________________________________________ 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 --_000_SN6PR08MB3933F2267B75F45426F38BBCDAC69SN6PR08MB3933namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you, Vidhi!

Yes, confirmed for me. 
Lisong


From: Vidhi Goel
Sent: Tuesday, August 24, 2021 12:40 PM
To: Lisong Xu; Injong Rhee; Sangtae Ha
Cc: Yoshifumi Nishida; tcpm@ietf.org Extensions; tcpm-chairs
Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-0= 3

Non-NU Email
+Lisong, Injong and Sangtae.

7) Has each author confirmed that any and all appropriate I= PR disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. 
    If not, explain why?
Could you reply to that email providing your individual confirma= tion about IPR disclosure?

Thanks,
Vidhi


On Aug 23, 2021, at 11:21 PM, Vidhi Goel <vidhi_goel=3D40apple= .com@dmarc.ietf.org> wrote:

7) Has each author confirmed that any and all appropriate I= PR disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. 

Confirmed from my end.

Thanks,
Vidhi

On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:<= /div>
Hi authors,

I start preparing the write-up for 8312bis draft to su= bmit it to IESG.
In order for this, could each of you provide the answer for= the following question?

7) Has each author confirmed that any and all appropriate I= PR disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. 
    If not, explain why?

Thanks,
--
Yoshi

On Wed, Aug 18, 2021 at 1:32 AM Yos= hifumi Nishida <nsd.ietf= @gmail.com> wrote:
Hi,
The chairs think 8312bis draft is in good shape and it's re= ady for submission.
We know we had some discussions on how to handle ABC draft = in the draft during the last WG meeting and there are on-going related disc= ussions on the ML.
However, we still think we can proceed with the draft as th= e relevance between the draft and the current discussions is not = very high.

If anyone has different thoughts on this, please let us kno= w.
Otherwise, we will prepare a writeup soon and submit it to = IESG.

Thanks,
--
Yoshi
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tcpm

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

--_000_SN6PR08MB3933F2267B75F45426F38BBCDAC69SN6PR08MB3933namp_-- From nobody Tue Aug 24 19:04:37 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 A1A983A1E9E; Tue, 24 Aug 2021 19:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=colorado.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N0eETjaRat1; Tue, 24 Aug 2021 19:04:29 -0700 (PDT) Received: from ipmx5.colorado.edu (ipmx5.colorado.edu [128.138.128.235]) (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 17FC63A1E9B; Tue, 24 Aug 2021 19:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorado.edu; l=8784; q=dns/txt; s=IPMX-SMTP; t=1629857069; h=mime-version:references:in-reply-to:date:message-id: subject:to:cc:from; bh=dm+mgDJCjlgyPezD/cbcgPbzFbEh06YdzryxFNIOS8w=; b=EHLpdjqNFSh/9/A38IQM9jV7o6yJie05ikh3oJTHir+K3q8T/GXdYgBe JTmsALLOrB4j/l9oVt9bBO6+6LSj2sfuhjoUnvFy8ilBr1xbRdYmfMMQG vHRquU1CrI17He+Ix3hxmrRwc2BoYRYVbwgzTNRrDbwwG4svESNvs0gXw vHO2vuPOvQ2qiZiGkyDot4S3fJj52qfJXDLY3opNT5JS6FE5euvxj5MHL bKMmuvmmY/zQcmXs2ILNAM/MIzST5B3oqzj7i8jo22fqMkHom8eAsUCwb vSwelGc6vHomLUMvMtvcQTzaZcslygewxHjF270laGpC/0nKpUX2xNlsv w==; IronPort-SDR: IwUDSuChytl68EvV8W3EFGjbR8u5+ZswPCAJSGcc3vV8uEsixUvF08LOjeQHhuoMlCCazX3GJR Xd5pdJJ9oV0kndEOP4ff/SSubJHa0TgV0= From: Sangtae Ha IronPort-HdrOrdr: A9a23:uIfTlqBC733BMGXlHemI55DYdb4zR+YMi2TDGXoBLyC9E/bo7v xG885rtiMc5AxwZJhko7G90cq7Lk80l6QFhLX5VI3KNGLbUSmTQr2KhrGSpwEIdReOkdK1Fp 0LT4FOTPP1BVh+yeDg4Ae5FN4khP2K6rqhi+ub71oFd3AJV0it1WpE48+gfnFLeA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AaAADdoyVhfyzeVdFaDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggYGAQELAYEigX9WbIRHgR6PawOKXopkhjEUgWgCCQEBAQE?= =?us-ascii?q?BAQEBAQkqAQoMBAEBhGoCgisCJTUIDgECBAEBAQEDAgwBAQYBAQEBAQEFBBQ?= =?us-ascii?q?BAQ0LEAg4QGRogU+BdAs0DYZCAQEBAQIBAQEQEUsLBQsLCwYEAQEBKgICIQE?= =?us-ascii?q?FDQEFARQIBhMiglCCVQMOIQ+daYEEPYo4eoExgQGHIQ1OAQkNgV0GgToBhws?= =?us-ascii?q?BAYZoJxCBVUSBFTaCcz6CIEIBAQKBKQESASmDD4JkBIYvHipDEFsLZg4EBh4?= =?us-ascii?q?CdpE2BIJ8AYtnin+RQF4HDoMfgUKXMYVmLINli2SGAZEupg2VQhAjgT8BZD5?= =?us-ascii?q?wck4xBoIyTQECAQINAQICAwECAQIJAQEClyOFBWQlMAI2AgYBCgEBAwmOfwE?= =?us-ascii?q?B?= X-IPAS-Result: =?us-ascii?q?A2AaAADdoyVhfyzeVdFaDg4BAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?gYGAQELAYEigX9WbIRHgR6PawOKXopkhjEUgWgCCQEBAQEBAQEBAQkqAQoMB?= =?us-ascii?q?AEBhGoCgisCJTUIDgECBAEBAQEDAgwBAQYBAQEBAQEFBBQBAQ0LEAg4QGRog?= =?us-ascii?q?U+BdAs0DYZCAQEBAQIBAQEQEUsLBQsLCwYEAQEBKgICIQEFDQEFARQIBhMig?= =?us-ascii?q?lCCVQMOIQ+daYEEPYo4eoExgQGHIQ1OAQkNgV0GgToBhwsBAYZoJxCBVUSBF?= =?us-ascii?q?TaCcz6CIEIBAQKBKQESASmDD4JkBIYvHipDEFsLZg4EBh4CdpE2BIJ8AYtni?= =?us-ascii?q?n+RQF4HDoMfgUKXMYVmLINli2SGAZEupg2VQhAjgT8BZD5wck4xBoIyTQECA?= =?us-ascii?q?QINAQICAwECAQIJAQEClyOFBWQlMAI2AgYBCgEBAwmOfwEB?= X-IronPort-AV: E=Sophos; i="5.84,349,1620712800"; d="scan'208,217"; a="48664347" Received: from mail-ua1-f44.google.com ([209.85.222.44]) by smtp.colorado.edu with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2021 20:04:27 -0600 Received: by mail-ua1-f44.google.com with SMTP id 90so13696861uax.5; Tue, 24 Aug 2021 19:04:27 -0700 (PDT) X-Gm-Message-State: AOAM532leQFt9fKDxq+GjmkLgpQYWLpn30Tk6CgcxWWTQPnENpiDX5C7 jGG+OAdlMVRlRKbeEWGd5wH0t1ZGgYEyMQKru/I= X-Google-Smtp-Source: ABdhPJy7n4e6oQtAuatsiw/EFBkBW62twatk6lNdto8IrdGbbDk70h7PNhsCxMxaEgfbY34Xg5FJ3MbPJsU3sw5PM/0= X-Received: by 2002:a05:6102:5f4:: with SMTP id w20mr30133959vsf.34.1629857066590; Tue, 24 Aug 2021 19:04:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 24 Aug 2021 20:04:15 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Lisong Xu Cc: Injong Rhee , Sangtae Ha , Vidhi Goel , Yoshifumi Nishida , tcpm-chairs , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000007d282205ca58abe0" Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 25 Aug 2021 02:04:35 -0000 --0000000000007d282205ca58abe0 Content-Type: text/plain; charset="UTF-8" Confirmed from my end too. Best, Sangtae On Tue, Aug 24, 2021 at 7:58 PM Lisong Xu wrote: > Thank you, Vidhi! > > Yes, confirmed for me. > Lisong > > > ------------------------------ > *From:* Vidhi Goel > *Sent:* Tuesday, August 24, 2021 12:40 PM > *To:* Lisong Xu; Injong Rhee; Sangtae Ha > *Cc:* Yoshifumi Nishida; tcpm@ietf.org Extensions; tcpm-chairs > *Subject:* Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 > > Non-NU Email > ------------------------------ > +Lisong, Injong and Sangtae. > > 7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > If not, explain why? > > Could you reply to that email providing your individual confirmation about > IPR disclosure? > > Thanks, > Vidhi > > > On Aug 23, 2021, at 11:21 PM, Vidhi Goel < > vidhi_goel=40apple.com@dmarc.ietf.org> wrote: > > 7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > > > Confirmed from my end. > > Thanks, > Vidhi > > On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida wrote: > > Hi authors, > > I start preparing the write-up for 8312bis draft to submit it to IESG. > In order for this, could each of you provide the answer for the > following question? > > 7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > If not, explain why? > > Thanks, > -- > Yoshi > > On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida > wrote: > > Hi, > The chairs think 8312bis draft is in good shape and it's ready for > submission. > We know we had some discussions on how to handle ABC draft in the draft > during the last WG meeting and there are on-going related discussions on > the ML. > However, we still think we can proceed with the draft as the > relevance between the draft and the current discussions is not very high. > > If anyone has different thoughts on this, please let us know. > Otherwise, we will prepare a writeup soon and submit it to IESG. > > Thanks, > -- > Yoshi > > _______________________________________________ > 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 > > > --0000000000007d282205ca58abe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Confirmed from my end too.

Best,
Sangtae

On Tue, Aug 24, 2021 at 7:58 PM Lisong Xu <xu@unl.edu> wrote:
Thank you, Vidhi!

Yes, confirmed for me.=C2=A0
Lisong


From: Vidhi Goel
Sent: Tuesday, August 24, 2021 12:40 PM
To: Lisong Xu; Injong Rhee; Sangtae Ha
Cc: Yoshifumi Nishida; tcpm@ietf.org Extensions; tcpm-chairs
Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-0= 3

Non-NU Email
+Lisong, Injong and Sangtae.

7) Has each author confirmed that any and all appropriate IPR disclosu= res required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed.=C2=A0
=C2=A0 =C2=A0 If not, explain why?
Could you reply to that email=C2=A0provi= ding your individual confirmation=C2=A0about IPR disclosure?<= br>

Thanks,
Vidhi


On Aug 23, 2021, at 11:21 PM, Vidhi Goel <vidhi_goel=3D40apple.com@dmarc.ietf.org> wrote:

7) Has each author confirmed that any and all appropriate IPR disclosu= res required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed.=C2=A0

Confirmed from my end.

Thanks,
Vidhi

On Aug 23, 2021, at 1:43 AM, Yoshifumi Nishida <nsd.ietf@g= mail.com> wrote:

Hi authors,

I start preparing the write-up for 8312bis=C2=A0draft to submit it to = IESG.
In order for this, could each of you provide the answer for the follow= ing=C2=A0question?

7) Has each author confirmed that any and all appropriate IPR disclosu= res required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed.=C2=A0
=C2=A0 =C2=A0 If not, explain why?

Thanks,
--
Yoshi

On Wed, Aug 18, 2021 at 1:32 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi,
The chairs think 8312bis draft is in good shape and it's ready for= submission.
We know we had some discussions on how to handle ABC draft in the draf= t during the last WG meeting and there are on-going related discussions on = the ML.
However, we still think we can proceed with the draft as the relevance= =C2=A0between=C2=A0the draft and the current discussions is not very high.<= /div>

If anyone has different thoughts on this, please let us know.
Otherwise, we will prepare a writeup soon and submit it to IESG.

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

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

--0000000000007d282205ca58abe0-- From nobody Fri Aug 27 00:34:18 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 3D3193A213E; Fri, 27 Aug 2021 00:34:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <163004965615.16873.15739938735579059515@ietfa.amsl.com> Date: Fri, 27 Aug 2021 00:34:16 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc8312bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 07:34:17 -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 : CUBIC for Fast and Long-Distance Networks Authors : Lisong Xu Sangtae Ha Injong Rhee Vidhi Goel Lars Eggert Filename : draft-ietf-tcpm-rfc8312bis-04.txt Pages : 29 Date : 2021-08-27 Abstract: CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of the linear window increase function on the sender side to improve scalability and stability over fast and long- distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the 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 RFC 8312. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 27 03:52: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 27C353A2DA5 for ; Fri, 27 Aug 2021 03:52:48 -0700 (PDT) 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, 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 wMWr0KF12rHw for ; Fri, 27 Aug 2021 03:52:43 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928E03A2DA9 for ; Fri, 27 Aug 2021 03:52:43 -0700 (PDT) Received: from smtp.freedom.nl (unknown [10.10.3.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id C26E960FA8 for ; Fri, 27 Aug 2021 10:52:34 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.127.71]) by soverin.net To: tcpm@ietf.org From: Geert Jan de Groot Message-ID: <9caba130-cebc-3235-8eac-7ff08fa3809c@ymbk.nl> Date: Fri, 27 Aug 2021 12:52:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] 793bis: question on TCP RTO timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 10:52:48 -0000 Hi folks, I do apologise for bringing up this question this late in the game, but lab tests are not pretty.. The issue is on 793bis section 3.8.1: the RTO timer. The 793bis document correctly points to RFC1122, RFC2988, RFC6298. RFC6298 (and 2988) describe: (2.4) Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second. I now have discussions with an embedded OS manufacturer who clamps the RTO timer at 1 second, even if the network delay and SRTT is much smaller (say, two hosts connecting over a typical 1000BASE-T network). That means that if a single packet is lost, the TCP connection freezes for one second because it needs the RTO-timer to trigger which is one second, minimal, per requirement RFC6298/2.4 above. Put like this, a connection pushing 1gbit/sec traffic freezes for one second if a single packet is dropped and the OS manufacturer claims this is correct. My feeling says it isn't - we measure SRTT for a reason, a packet dropped is simply a signal to lower bandwith (congestion) but not to freeze traffic for a second waiting for RTO to trigger. However, reading the draft and 6298/2988 I can't definitively fault the OS for their one second freeze. Before sending this to the list, for fear of kicking up dust, I asked Wesley and he referred to RFC8961, which suggests to use the RTT, with exponential backoff, to estimate the RTO timer value without the one second minimal value of RFC6298. I wonder what the list thinks. When the one-second rule was first mentioned, networks were significantly slower than they are today, and it only seems logical that timers based on traffic (with appropiate backoff measures) make more sense than a one second timer. Clue appreciated, Geert Jan From nobody Fri Aug 27 05:22: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 13A143A10A0 for ; Fri, 27 Aug 2021 05:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 3b1Dtl_JzrKy for ; Fri, 27 Aug 2021 05:22:24 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A15D3A109E for ; Fri, 27 Aug 2021 05:22:23 -0700 (PDT) Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id A16DC7220BFA1; Fri, 27 Aug 2021 14:22:15 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Michael Tuexen In-Reply-To: <9caba130-cebc-3235-8eac-7ff08fa3809c@ymbk.nl> Date: Fri, 27 Aug 2021 14:22:15 +0200 Cc: Extensions Content-Transfer-Encoding: quoted-printable Message-Id: <32F34C85-A125-40AC-993C-BC5A86204A93@lurchi.franken.de> References: <9caba130-cebc-3235-8eac-7ff08fa3809c@ymbk.nl> To: Geert Jan de Groot X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [tcpm] 793bis: question on TCP RTO timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 12:22:30 -0000 > On 27. Aug 2021, at 12:52, Geert Jan de Groot = wrote: >=20 > Hi folks, >=20 > I do apologise for bringing up this question this late in the game, = but lab tests are not pretty.. >=20 > The issue is on 793bis section 3.8.1: the RTO timer. The 793bis = document correctly points to RFC1122, RFC2988, RFC6298. >=20 > RFC6298 (and 2988) describe: > (2.4) Whenever RTO is computed, if it is less than 1 second, then = the > RTO SHOULD be rounded up to 1 second. >=20 > I now have discussions with an embedded OS manufacturer who clamps the = RTO timer at 1 second, even if the network delay and SRTT is much = smaller (say, two hosts connecting over a typical 1000BASE-T network). = That means that if a single packet is lost, the TCP connection freezes = for one second because it needs the RTO-timer to trigger which is one = second, minimal, per requirement RFC6298/2.4 above. Can't you use fast retransmission to recover from the loss? What about = using RACK? Best regards Michael >=20 > Put like this, a connection pushing 1gbit/sec traffic freezes for one = second if a single packet is dropped and the OS manufacturer claims this = is correct. My feeling says it isn't - we measure SRTT for a reason, a = packet dropped is simply a signal to lower bandwith (congestion) but not = to freeze traffic for a second waiting for RTO to trigger. However, = reading the draft and 6298/2988 I can't definitively fault the OS for = their one second freeze. >=20 > Before sending this to the list, for fear of kicking up dust, I asked = Wesley and he referred to RFC8961, which suggests to use the RTT, with = exponential backoff, to estimate the RTO timer value without the one = second minimal value of RFC6298. >=20 > I wonder what the list thinks. When the one-second rule was first = mentioned, networks were significantly slower than they are today, and = it only seems logical that timers based on traffic (with appropiate = backoff measures) make more sense than a one second timer. >=20 > Clue appreciated, >=20 > Geert Jan >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Aug 30 09:33: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 39BAE3A18BB; Mon, 30 Aug 2021 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mLgIWWxLL2qp; Mon, 30 Aug 2021 09:33:30 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70873A18B7; Mon, 30 Aug 2021 09:33:28 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Mon, 30 Aug 2021 19:33:17 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=YrvZ48 pO0CVuTTVMRiFJfnOyViuHCi5mL8r3oWUTK0o=; b=AAQLLNd7DTE+lCTh6b58Ja /BLeUD1mIUimt4GvaMp3pfNMlZufm5oxZAG8xc09OnDWUVSgXDmwuNSfMqTyjK3s Z2kF0mSwIEPUP7mf+lKmdfp1gbdRkfUkoAV6NdrmEWuJSAGEW0riffJ9bL2IGSTQ dqINrzlSVXj7+5dotQpcA= Received: from hp8x-60 (openvpn-tun-3-3.fe.helsinki.fi [128.214.204.179]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Mon, 30 Aug 2021 19:33:17 +0300 id 00000000005A014E.00000000612D084D.00000162 Date: Mon, 30 Aug 2021 19:33:16 +0300 (EEST) From: Markku Kojo To: Yoshifumi Nishida cc: "tcpm@ietf.org Extensions" , tcpm-chairs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-380-1630341197-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Aug 2021 16:33:37 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-380-1630341197-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi Yoshi, all, On Wed, 18 Aug 2021, Yoshifumi Nishida wrote: > Hi,The chairs think 8312bis draft is in good shape and it's ready for s= ubmission. > We know we had some discussions on how to handle ABC draft in the draft = during the > last WG meeting and there are on-going related discussions on the ML. > However, we still think we can proceed with the draft as the relevance=C2= =A0between=C2=A0the > draft and the current discussions is not very high. >=20 > If anyone has different thoughts on this, please let us know. > Otherwise, we will prepare a writeup soon and submit it to IESG. My sincere apologies as this comes very late in the process but I was not=20 able to follow IETF mailing list at the time of WGLC nor during=20 the recent weeks, and I couldn't attend IETF 111. I took a look at the draft and some statements of it seemed to be in=20 conflict with other Standards Track RFCs. I believe the tcpm=20 wg should look more closer to these to avoid publishing conflicting=20 guidance in different Standards Track RFCs. In addition, there are some=20 issues I am concerned about. 1. ECN a) The draft modifies RFC 3168 when ECE arrives and would result in cwnd < 2 MSS by setting a lower bound of 2 MSS for cwnd (only ssthresh is supposed to have a lower bound of 2 MSS). This is in conflict with RFC 3168, RFC 5033, and RFC 2914 which require "full backoff", that is, a sender must continue decreasing sending rate as long as congestion persists. This is a fundamental property for any congestion control mechanism. For ECN, RFC 3168 (sec 6.1.2) requires that cwnd is halved until the minimum cwnd of one MSS is received, and then the sender continues reducing sending rate by using a timer with exponential backoff, if more ECE-echo packets keep on arriving. This implementation bug has been long with Linux and is present in other stacks as well and should get corrected ASAP with appropriate advise in all published RFCs, instead of replicating the bug in the RFC series. b) RFC 8311 (sec 4.1) allows modifying the TCP-sender response to ECE for experimental purposes only. Has there been any discussion with tsvwg in that modifying the TCP-response to ECE in CUBIC is conflict with RFC 8311 as CUBIC is currently intended to become a Standards Track RFC? c) ABE (RFC 8511) is currently the only experimental RFC to modify the TCP-sender response to ECE. ABE allows modifying multiplicative decrease factor only for AIMD TCP and only when ECE arrives in congestion avoidance, that is, not when the sender is in slow-start. Applying a decrease factor of 0.7 (or higher) when a congestion singnal arrives and ends the initial slow start would be inconsiderate because it extends the convergence time from the slow-start overshoot. ABE has found that using a larger decrease factor yields performance improvement when applied in congestion avoidance, but not otherwise. Do we have data that would support different findings with CUBIC? 2. Slow-Start Overshoot w/ loss-based congestion conrol The larger decrease factor of 0.7 seems unadviseable also if used in the initial slow start with loss based congestion control (w/ Not-ECT traffic); packets start getting dropped when a TCP sender has increased cwnd in slow start such that the available network bandwidth and buffering capacity at the bottleneck is filled, but the TCP sender continues sending more packets for one RTT doubling cwnd and hence also the number of packets inflight before the congestion signal reaches the sender. Now, even if the sender uses the standard decrease factor of 0.5, the cwnd gets reduced only to a value that equals to the cwnd just before (or around) the congestion point. That is, the network is still full when the sender enters fast recovery but we do not expect more drops during fast recovery in a deterministic model. Only in congestion avoidance after the recovery, the sender increases cwnd again and gets a packet drop that takes the sender to a normal sawtooth cycle in an ideal case. So, the convergence time from slow-start is expexted to be fast though in reality loss recovery does not always work ideally with such many drops in a window of data. However, if the sender applies decrease factor of 0.7, it continues in fast recovery with a 40% higher cwnd than what is the available network capacity. This is very likely to result in significant number of packet losses during fast recovery, and very likely to result in loss of retransmissions. So, it is no wonder that so many people have been very concerned about the slow-start overshoot and the problems it creates. It is very obvious that applying decrease factor of 0.7 in the initial slow start is likely to extend the convergence time from the slow-start overshoot significantly. Or, do we have data that shows that such concern is unnecessary? Also, a number of new loss-recovery mechanisms have been introduced maybe mainly because of this? I would hesitate recommending decrease factor of 0.7 when a congestion event occurs during the initial slow start. 3. RACK (and QUIC) The draft states that RACK (and QUIC loss detection) can be used with CUBIC to detect losses. However, it seems to have gone unnoticed that RACK may also detect loss of a retransmission in which case the congestion control response is required to be taken twice, i.e., ssthresh and cwnd must be lowered again (MUST in RFC 5681 Sec. 4.3). Once RACK got published all new congestion controls and updates to existing RFCs must include this essential congestion control response, if the congestion control mechanism intends to use RACK for loss detection. This draft does not have any such requirement nor does it specify how this is done? 4. Fairness to AIMD congestion control The equation on page 12 to derive increase factor =CE=B1 that cubic intends to achieve the same average window as AIMD TCP seems to have its origins in a preliminary paper that states that the authors do not have an explanation to the discrepancy between their AIMD model and experimental results, which clearly deviate. It seems to have gone unnoticed that the equation assumes equal drop probability for the different values of the increase factor and multiplicative decrease factor but the drop probability changes when these factors change. The equations for the drop probability / the # of packets in one congestion epoch are available in the original paper and one can easily verify this. Therefore, the equations used in CUBIC are not correct and seem to underestimate _W_est_ for AIMD TCP, resulting in moving away from AIMD-Friendly region too early. This gives CUBIC unjustified advantage over AIMD TCP particularly in environments with low level of statistical multiplexing. With high level of multiplexing, drop probability goes higher and differences in the drop probablilities tend to get small. On the other hand, with such high level of competition, the theoretical equations may not be that valid anymore. 5. Contribution to buffer bloat and slower convergence due to larger decrease factor This draft uses a larger cwnd decrease factor, resulting in larger average cwnd and buffer occupation. This means that it is likely to contribute significantly to buffer bloat, particularly when considering also the use of concave increase function in the beginning of the congestion avoidance that keeps the cwnd close to maximum most of the time as carefully explained in the draft. This means that CUBIC keeps also buffer bloated router queues very efficiently full at all times. Currently the draft does mention the slower convergence speed as the only side effect for the larger decrease factor and does not discuss the contribution to buffer bloat. It would be important to assess this together with measurement data to back up any observations. Do we have data in different environments, including buffer-bloated environments that show how much effect CUBIC has compared to AIMD TCP? And, how does larger decrease function impact convergence speed, particularly in buffer-bloated environments. Many people have complained that window-based (TCP) congestion control drives buffer bloat. Of course, also the current standard AIMD TCP tends to fill in the buffer-bloated queues but it unlikely does it as effectively as CUBIC? This would be good to understand better. 6. Citing Experimental RFCs as if being a part of CUBIC The draft says that CUBIC MAY implement DSACK [RFC3708], limited slow start [RFC 3742], [RFC7661] and hybrid slow start [cites a paper]. Aren't the first three down references? Not sure if it is appropriate for a Stds Track document to cite experimental work or a paper like this even though it's a MAY. 7. Discussion I regret to say that the discussion in Sec 5. brings up surprisingly=20 little data to back up the claims that are made. Given the long=20 deployment experience that is emphasised in the draft, there, however, is=20 little evidence (measurement data) summarised and cited to back up the=20 claims. "There is a long deployment experience" does not provide=20 any evidence as such. There should be a lot of studies with measurement=20 data accumulated over the years that would support the assertions in the=20 doc. Or, is there? Sec 5.1 In this subsection, one should show the impact of CUBIC when=20 competing with AIMD TCP. The numbers in tables are derived from analytical models that give average window size with fixed random=20 loss probabilities and unlimited bandwidth. That is not the same as when=20 flows are combeting in the same congested bottleneck that builds a queue. Loss probabilities for different flows are likely to be different=20 especially at lower levels of statistical multiplexing. The first para of sec 5.1 does not sound like true. Simply looking at the=20 original CUBIC paper [HRX08] reveals that CUBIC dominates AIMD TCP (SACK=20 TCP) in the regions where SACK TCP alone is able to fully utilize the=20 available bandwidth (Figure 10 c up until 200 Mbps, and to some extent in=20 Fig 10 a with 40 ms delay). And =C3=ADn all cases where SACK TCP alone is = not=20 able to utilize all available b/w, CUBIC steals multiple times more b/w=20 from SACK TCP than what SACK TCP is not able to utilize. Figures 5 and 6=20 tell the same story. Has something changed and/or is there possibly data=20 that provides alternative evidence. In addition, the recommended value for constant C and the two alternative=20 values presented in the draft are the same as in the original paper. It=20 would be interesting to see if there has been any experimentation with=20 different values and what might be the outcome? Sec 5.3 Any experimental data to summarize and cite? Sec 5.4 The text correctly states that CUBIC fills queues faster than AIMD TCP=20 and increases the risk of standing queues. Then it proposes queue sizing=20 and AQM as a solution, which is odd. Applying AQM to keep the queues=20 shorter of course decreases the RTT (delay) seen but it does not help=20 with standing queues (they remain standing but are just shorter). Sec 5.5 Setting lower bound of 2 MSS for cwnd with ECN may result in symptoms of=20 congestion collapse with certain specific conditions, e.g., if the actual=20 (physical) queue size is very large and there is a mix of ECN-capable=20 (ECT) and not ECN-capable flows. When the number of ECN capable flows=20 increase the start starving the not ECN-capable flows as ECT flows stop=20 responding to congestion and start increasing the queue such that AQM has=20 to drop almost all not ECT packets. Sec 5.6 Competing CUBIC flows will converge but it happens very slowly and=20 requires a large amount of data to send, i.e., short flows are more=20 unlikely to live long enough to converge. This seems to be case at least=20 according to the results in original paper [HRX08, Fig 4 b]. Summary and citing some performance data would be very useful and much=20 more convincing. Sec 5.8 The MUST NOT requirement would be much better placed with other=20 specifications in Sec 4 and would benefit from more accurate description. Sec 5.9 The statement made here is not convincing and is likely to be incorrect.=20 E.g., CUBIC with larger decrease factor would most likely release=20 capacity notably slower than AIMD TCP if there is sudden congestion. 8. The draft says in the intro that CUBIC is to be regarded as *current=20 standard* for TCP congestion control. It sounds a bit like it would=20 obsolete RFC 5681 which is not the intent. RFC 5681 still has its=20 specific role as the document that gives the baseline and generic=20 guidelines for TCP (and other) congestion control. Instead, I think this document should articulate very carefully its role=20 among the congestion control algorithms. How, I am not sure. Maybe=20 simply as an alternative for RFC5681 congestion avoidance and=20 multiplicative decrease. Please note also that when specifying these algorithms this document is in direct conflict with a MUST in RFC5681 which says: "however, a TCP=20 MUST NOT be more aggressive than the following algorithms allow (that is,=20 MUST NOT send data when the value of cwnd computed by the following=20 algorithms would not allow the data to be sent)." Therefore, the draft should make this differentation very clear maybe=20 already in the abstract and justify the deviations much better than it=20 currently does (accompanied with evidence =3D data). This is very importa= nt=20 i order to make a convincing case why it is ok for this doc to deviate=20 from the current Standards Track TCP normative statements. Misc comments: _epoch_start_: needs more accurate and consistent definition when the=20 exactly the epoch starts. Is it when congestion event occurs or when=20 TSP sender enters congestion avoidance first time after an congestion=20 event. If it is different in different scenarios that would be good to=20 present systematically. In many occassions: "(upon receiving) an ACK" -> "(upon receiving) a new ACK" On page 13: " the sender MAY employ a Fast Recovery algorithm to gradually adjust the congestion window to its new reduced _ssthresh_ value." I assume this is aiming at saying that something similar to PRR MAY be=20 used to reduce cwnd. This, however, is somewhat vaguely said and using=20 fasr recovery is misleading. We need to remember also that it might not=20 be trivial to have it right. So, dunno whether it would be useful to drop=20 this. Best regards, /Markku --=_script-380-1630341197-0001-2-- From nobody Tue Aug 31 04:10: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 93C5C3A0A5E; Tue, 31 Aug 2021 04:10:33 -0700 (PDT) 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 VHhdtgCUdMFs; Tue, 31 Aug 2021 04:10:27 -0700 (PDT) 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 ECC6D3A0A4D; Tue, 31 Aug 2021 04:10:26 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1d1f:3f58:e36a:a55c]) (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 61EDA600373; Tue, 31 Aug 2021 14:10:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1630408208; bh=kTq3rZARETgo57nLRpXTH+QBFp5frp2QuK5dUwPEVas=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lazJkXaAX1CUYINvhrL1PGO1RBN4vxMUjIPBp4bIIuYBwU7TCediCL/Krfep/swWp 9eOZjFot+tsHo3tZo9b4swofg6W2C060nq/IL8eODv1svn2b936ppcCM6b9cbrz8rl ZlEZ184QiFyNgZoV3p1vejcMvgwb6GhT9eLguAbU= From: Lars Eggert Message-Id: <37C22CF4-611E-4663-B88B-02AED2AF630B@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_04408EAD-D009-4744-8D76-2C88F5503850"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 14:10:07 +0300 In-Reply-To: Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , tcpm-chairs To: Markku Kojo References: X-MailScanner-ID: 61EDA600373.AFC6C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 31 Aug 2021 11:10:34 -0000 --Apple-Mail=_04408EAD-D009-4744-8D76-2C88F5503850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Markku, On 2021-8-30, at 19:33, Markku Kojo = wrote: > My sincere apologies as this comes very late in the process but I was = not able to follow IETF mailing list at the time of WGLC nor during the = recent weeks, and I couldn't attend IETF 111. it's always a bit disappointing to get a long review just when you = thought you were done, but it will lead to a better document in the end = - so thank you for your review! We've created a bunch of GitHub issues based on the issues you = identified, and will work on resolutions there. Do you have a GitHub ID = we can use to tag you? > 1. ECN >=20 > a) The draft modifies RFC 3168 when ECE arrives and would result ... https://github.com/NTAP/rfc8312bis/issues/83 > b) RFC 8311 (sec 4.1) allows modifying the TCP-sender response to ... https://github.com/NTAP/rfc8312bis/issues/84 > c) ABE (RFC 8511) is currently the only experimental RFC to modify ... https://github.com/NTAP/rfc8312bis/issues/85 > 2. Slow-Start Overshoot w/ loss-based congestion conrol ... https://github.com/NTAP/rfc8312bis/issues/86 > 3. RACK (and QUIC) ... https://github.com/NTAP/rfc8312bis/issues/87 > 4. Fairness to AIMD congestion control ... https://github.com/NTAP/rfc8312bis/issues/88 > 5. Contribution to buffer bloat and slower convergence due to > larger decrease factor ... https://github.com/NTAP/rfc8312bis/issues/89 > 6. Citing Experimental RFCs as if being a part of CUBIC ... https://github.com/NTAP/rfc8312bis/issues/90 > 7. Discussion ... https://github.com/NTAP/rfc8312bis/issues/91 > Sec 5.1 ... https://github.com/NTAP/rfc8312bis/issues/92 > Sec 5.3 ... https://github.com/NTAP/rfc8312bis/issues/93 > Sec 5.4 ... https://github.com/NTAP/rfc8312bis/issues/94 > Sec 5.5 ... https://github.com/NTAP/rfc8312bis/issues/95 > Sec 5.6 ... https://github.com/NTAP/rfc8312bis/issues/96 > Sec 5.8 ... https://github.com/NTAP/rfc8312bis/issues/97 > Sec 5.9 ... https://github.com/NTAP/rfc8312bis/issues/98 > 8. The draft says in the intro that CUBIC is to be regarded as = *current standard* for TCP ... https://github.com/NTAP/rfc8312bis/issues/99 > Misc comments: >=20 > _epoch_start_: needs more accurate and consistent definition when the = exactly the epoch ... https://github.com/NTAP/rfc8312bis/issues/100 > In many occassions: > "(upon receiving) an ACK" -> "(upon receiving) a new ACK" https://github.com/NTAP/rfc8312bis/issues/101 > On page 13: https://github.com/NTAP/rfc8312bis/issues/102 Thanks, Lars --Apple-Mail=_04408EAD-D009-4744-8D76-2C88F5503850 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEuDg8ACgkQVLXDCb9w wVc3vhAAlBvF4yeyQLCiSySCxhf8OC1JXNyOqloLjk2mp9dhDGXC1Upqm8inSO7z wHrwqTYoFpUkvMY9lz+Pz+NtRKMyMLdAbmR42DTtGCjDYH2gT3GoG4BsIiO3hcF2 mwlHIGPBJHo01jYWboOcv5pS/aTqxeQu1VY3fdA7BD4cT92/1QA6Uakgj5+B8K0I UA0mHiGnapw23pHgih+e2VMS7R+vKXKg7ga1IHCjHLe4o7nNdBMlPvyFxZ/Wa/R0 y1yphe3XpHAkbUG+RlYUS5YYqRWnp+No/4+mrk+rzuTuVo/ZLSHfmobRtojAmkb7 0zAQdilDUG6hJJd7kyAxe0Y7TKaMIWGjPSkILRECVOSPsGQ/eGqW80lG3i9p633o n2FwCglXpItNmhBuLz5MU540+R61ZefnqPKGKnyeRP4JYgA6cb10u1vJCXtw1Xn9 QkGmj8rI69D8iaLMcEb7Q/BbDmFJmfcpGFKY8hBhDa3lM/DoNu4bGCv8SBh/Q15e 2XA/6nHfw2PLduWfjnp36P3mSGJJdp4DoSUkRt9+N+MzpBbaoBcW43OyYMPBE6zJ gJi8s5MCCn+M1RAj1yQ8Dq01b3C0AYzayPnuRfMDCN67VhX/GWuSfxutFonQaWH5 MZzvOvMblk+c4Dt6ugfuPBFc3sw5OUeqNo/62iICUAT5pH/zSDE= =EEYx -----END PGP SIGNATURE----- --Apple-Mail=_04408EAD-D009-4744-8D76-2C88F5503850--