From nobody Mon Nov 14 13:51:22 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCCCC14F721 for ; Mon, 14 Nov 2022 13:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.596 X-Spam-Level: X-Spam-Status: No, score=-17.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ca41RMbuVn0 for ; Mon, 14 Nov 2022 13:51:16 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5127EC14F724 for ; Mon, 14 Nov 2022 13:51:16 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id a11-20020a05600c2d4b00b003cf6f5fd9f1so8966706wmg.2 for ; Mon, 14 Nov 2022 13:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pRSuB1Hl7icY6qjuDC4Jb6M6npoZ1jIU4JCh8luZI3M=; b=NLuobqYTttpmn/agklxtl1J+8tRdf8A9zQngcqvAIQRholM3UoIDIYMC6gGUEWVQ1O VkRbW8aO+jCjOCcnxrCLT/kM0wQyjdyxlAScozL8YIiGxobChh+B3qZGlGB4Opo+ZE3Z WDDpqB91YF+CxN7sSzJkk3+n8UfdjDBO00V554znwIpCNldLJLwYvhZVww+pIDaTWYkS x0BvLMJnK34lDh+F+lQMbSF7/ISUOF0TI/YpL1YWzlq7nzQs8WcerZuDsVwPhSY0vTyY TIYc/r3XgEY79foEuSGOxzY8InvT5j5nYyNBD11vSRO7prrt5ptI5Ep3hqhw0yFC6Xkl 1xwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pRSuB1Hl7icY6qjuDC4Jb6M6npoZ1jIU4JCh8luZI3M=; b=rmK7KRyJ+pgyBSutsVPQ9ZS5DZtu1qoYRhTqN7Z/o0AIVNSAvDnQ6GefSiXqiH5SBA wFV44IQ5tnvP1/F3eINQwZNRmG6HcNipGcjTG4TBT4hBXI02n1EW3ELJp9Ocnd8fofP4 5YkGwarg42JCcljBJ2f5lOMNO+y4b2m1u6dgpkP+1JvQkShcB4kRwUkWbBVOxxzNunKv DQ5gtr4t/GyHn3c49HUtL4zwq33QmBl2jm4SkGi0H4KLzoyAcxfsXY4JL+PPgNgtJ6PI 39qkr+CC/ZkJPVORMkKMtsz9a19r0yTUAScyUywkq1d0Z+Yw6mo+w3AhLvCh51JQ6pFc tFBA== X-Gm-Message-State: ANoB5pkBzNLY1H/u2B5hk+/KeyVKj02WnYPexbWIvSB2vXruDmk/9/jJ TrENvlrg1hGLwrxdDDj95dssDbbS037pnkTfP1dwBA== X-Google-Smtp-Source: AA0mqf6QDGzqL503QnJ4z0EfTuNh30Zt/oLAxPw3gZKkfqohOQAvIx34l/v7x29LSFt6PApcVyThdD1L3PbeqNrA4FY= X-Received: by 2002:a1c:7912:0:b0:3cf:7959:d8be with SMTP id l18-20020a1c7912000000b003cf7959d8bemr9878442wme.85.1668462673616; Mon, 14 Nov 2022 13:51:13 -0800 (PST) MIME-Version: 1.0 References: <161060871994.10783.1247396842504892132@ietfa.amsl.com> <7c527d72-2f48-b39e-9f09-0f22e9c865f2@gmx.at> In-Reply-To: From: Yuchung Cheng Date: Mon, 14 Nov 2022 13:50:36 -0800 Message-ID: To: Neal Cardwell Cc: Yuchung Cheng , rscheff@freebsd.org, tcpm@ietf.org, draft-ietf-tcpm-prr-rfc6937bis@ietf.org, "Semke, Jeff" Content-Type: multipart/alternative; boundary="000000000000fc207205ed753c74" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.39 Precedence: 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, 14 Nov 2022 21:51:20 -0000 --000000000000fc207205ed753c74 Content-Type: text/plain; charset="UTF-8" Looks great to me. Thanks for the suggestions On Mon, Nov 14, 2022 at 1:42 PM Neal Cardwell wrote: > On Mon, Nov 14, 2022 at 3:43 PM Yuchung Cheng 40google.com@dmarc.ietf.org> wrote: > >> On Wed, Nov 9, 2022 at 3:13 PM Scheffenegger, Richard >> wrote: >> > >> > Chairs, >> > >> > Matt, Yuchung, >> > >> > This is a summary of my Read of 6937bis-02. >> > >> > I found mostly editorial only nit-picks, and a few clarification >> > questions - if my read of the heuristic is correct now. >> > >> > In short, I'm happy with the document, there are few editorial nits; I >> > would like a very concrete example of a SafeACK, even though the last >> > and final description appears to confirm what I assumed a SafeACK would >> > be. But then again, still not 100% sure. >> > >> > Reason for my question: "does not indicate prior fast retransmit has >> > been lost" may indicate only partial ACKs which do *not* shrink a SACK >> > hole *from the right*, or create a new SACK hole (e.g. splitting an old >> > one) are elegible... But partial ACKs on non-SACK sessions would always >> > be elegible? >> >> see my reply below >> >> > >> > The forced fast retransmit may not be reflected in the PRR packet >> > diagram - unless I didn't quite understand the values there... >> >> The examples do not include force retransmit examples. We'd clarify >> that in the description of the examples to clarify. >> >> > >> > Thanks for doing this important work! >> Thanks for the detailed review! >> >> >> > >> > Other than the above (SafeAck), all my comments from 8.Feb 2021 and >> > 23.Feb.2021 appear to have been addressed. >> > >> > Best regards, >> > Richard >> > >> > >> > >> > Abstract: >> > >> > > PRR potentially replaces the Fast Recovery to regulate >> > >> > missing noun "Fast Recovery algorithm" (excessive deletion btwn -01/-02. >> > >> > Also, the abbreviations PRR, ssthresh are mentioned again in >> > Introduction, so maybe leave the bracketed acronym out in the abstract. >> > >> > Sec 1 - maybe reference to RACK-TLP with LRD when LRD is mentioned the >> > first time; the reference is further down below currently. There are >> > other ways to do LRD (with SACK), but not in the RFC series. >> > >> > Sec 2 - [6675] is not a link. >> > >> > Sec 5 - update rfc793 to 9293? >> >> will address the nits above in the next rev. thanks >> >> > >> > SafeACK - missing what "and the ACK does not indicate >> > further losses." actually means. No new SACK block ? (new sack >> > scoreboard hole)? >> > >> > Sec 6 - SafeACK again: "and the ACK does not indicate >> > further losses." (concrete example?) >> > >> > >> > Sec 7, PRR example... You describe the forced fast retransmit on the >> > first transmission oppty. Shouldn't that shift the "N" transmissions >> > here one notch to the left? (The ACK for "4"). >> > >> > PRR >> > ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 >> > cwnd: 20 20 19 19 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10 >> > pipe: 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 >> > sent: N N R N N N N N N N N >> no because forced retransmit only applies when the fast recovery >> starts (i.e. prr_out = 0). by ack #4, prr_out is already 1 due to the >> first "R". >> >> > >> > Sec 9 - SafeAck seems to indicate, when SACK is in use, that no new SACK >> > range is included (adding a new hole to the scoreboard). However, in a >> > non-SACK case, due to the lack of this knowledge, wouldn't be all >> > partial ACKs be considered to be SafeACKs? >> >> Yes when SACK is not used SafeACK will be true for all partial ACKs. >> To clarify better, we'd add LRD requirement on SACK and non-SACK sup >> >> The current wording in the section "Changes from RFC 6937 is less >> clear. We'd revise from >> "For TCP, when the latest ACK advances snd.una and does not indicate >> prior fast retransmit has been lost" >> to >> "For TCP, when the latest ACK advances snd.una and does not indicate >> further new packet losses on both SACK and NonSACK" >> > > FWIW, for this sentence I find the "on both SACK and NonSACK" phrasing a > bit unclear. WDYT about something like: > > Current (prr-rfc6937bis-02): > > The largest change since [RFC6937 ] is the introduction of a new > heuristic that uses good recovery progress (For TCP, when the latest > ACK advances snd.una and does not indicate prior fast retransmit has > been lost) to select which Reduction Bound. > > > Suggested: > > The largest change since [RFC6937 ] is the introduction of a new > "safeACK" heuristic that assesses recovery progress to select the > > Reduction Bound. For TCP, an ACK is deemed a "safeACK" when > > processing the ACK advances SND.UNA without the loss detection > > algorithm detecting any new packet losses (this heuristic > > applies to both SACK and non-SACK connections). > > > neal > > > --000000000000fc207205ed753c74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks great to me. Thanks for the suggestions
On Mon, N= ov 14, 2022 at 1:42 PM Neal Cardwell <ncardwell@google.com> wrote:
On Mon, Nov 14,= 2022 at 3:43 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote= :
On Wed, Nov 9, 2022 at 3:13 PM Scheffenegger, Richard <rs.ietf@gmx.at> wrot= e:
>
> Chairs,
>
> Matt, Yuchung,
>
> This is a summary of my Read of 6937bis-02.
>
> I found mostly editorial only nit-picks, and a few clarification
> questions - if my read of the heuristic is correct now.
>
> In short, I'm happy with the document, there are few editorial nit= s; I
> would like a very concrete example of a SafeACK, even though the last<= br> > and final description appears to confirm what I assumed a SafeACK woul= d
> be. But then again, still not 100% sure.
>
> Reason for my question: "does not indicate prior fast retransmit = has
> been lost" may indicate only partial ACKs which do *not* shrink a= SACK
> hole *from the right*, or create a new SACK hole (e.g. splitting an ol= d
> one) are elegible... But partial ACKs on non-SACK sessions would alway= s
> be elegible?

see my reply below

>
> The forced fast retransmit may not be reflected in the PRR packet
> diagram - unless I didn't quite understand the values there...

The examples do not include force retransmit examples. We'd clarify
that in the description of the examples to clarify.

>
> Thanks for doing this important work!
Thanks for the detailed review!


>
> Other than the above (SafeAck), all my comments from 8.Feb 2021 and > 23.Feb.2021 appear to have been addressed.
>
> Best regards,
>=C2=A0 =C2=A0 =C2=A0Richard
>
>
>
> Abstract:
>
>=C2=A0 > PRR potentially replaces the Fast Recovery to regulate
>
> missing noun "Fast Recovery algorithm" (excessive deletion b= twn -01/-02.
>
> Also, the abbreviations PRR, ssthresh are mentioned again in
> Introduction, so maybe leave the bracketed acronym out in the abstract= .
>
> Sec 1 - maybe reference to RACK-TLP with LRD when LRD is mentioned the=
> first time; the reference is further down below currently. There are > other ways to do LRD (with SACK), but not in the RFC series.
>
> Sec 2 - [6675] is not a link.
>
> Sec 5 - update rfc793 to 9293?

will address the nits above in the next rev. thanks

>
> SafeACK - missing what "and the ACK does not indicate
>=C2=A0 =C2=A0 =C2=A0further losses." actually means. No new SACK b= lock ? (new sack
> scoreboard hole)?
>
> Sec 6 - SafeACK again: "and the ACK does not indicate
>=C2=A0 =C2=A0 =C2=A0further losses." (concrete example?)
>
>
> Sec 7, PRR example... You describe the forced fast retransmit on the > first transmission oppty. Shouldn't that shift the "N" t= ransmissions
> here one notch to the left? (The ACK for "4").
>
> PRR
>=C2=A0 =C2=A0 =C2=A0ack#=C2=A0 =C2=A0X=C2=A0 1=C2=A0 2=C2=A0 3=C2=A0 4= =C2=A0 5=C2=A0 6=C2=A0 7=C2=A0 8=C2=A0 9 10 11 12 13 14 15 16 17 18 19
>=C2=A0 =C2=A0 =C2=A0cwnd:=C2=A0 =C2=A0 20 20 19 19 18 17 17 16 16 15 15= 14 14 13 13 12 12 11 10
>=C2=A0 =C2=A0 =C2=A0pipe:=C2=A0 =C2=A0 19 19 18 18 17 17 16 16 15 15 14= 14 13 13 12 12 11 11 10
>=C2=A0 =C2=A0 =C2=A0sent:=C2=A0 =C2=A0 =C2=A0N=C2=A0 N=C2=A0 R=C2=A0 N= =C2=A0 =C2=A0 =C2=A0 =C2=A0 N=C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2=A0N=C2= =A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 = =C2=A0N
no because forced retransmit only applies when the fast recovery
starts (i.e. prr_out =3D 0). by ack #4, prr_out is already 1 due to the
first "R".

>
> Sec 9 - SafeAck seems to indicate, when SACK is in use, that no new SA= CK
> range is included (adding a new hole to the scoreboard). However, in a=
> non-SACK case, due to the lack of this knowledge, wouldn't be all<= br> > partial ACKs be considered to be SafeACKs?

Yes when SACK is not used SafeACK will be true for all partial ACKs.
To clarify better, we'd add LRD requirement on SACK and non-SACK sup
The current wording in the section "Changes from RFC 6937 is less
clear. We'd revise from
"For TCP, when the latest ACK advances snd.una and does not indicate prior fast retransmit has been lost"
to
"For TCP, when the latest ACK advances snd.una and does not indicate further new packet losses on both SACK and NonSACK"

FWIW, for this sentence I find the "on both SACK and= NonSACK" phrasing a bit unclear. WDYT about something like:

Current (prr-rfc6937bis-02):

   The largest change since [RFC6937] is the introduction of a n=
ew
   heuristic that uses good recovery progress (For TCP, when the latest
   ACK advances snd.una and does not indicate prior fast retransmit has
   been lost) to select which Reduction Bound.

Suggested:

   The largest change since [RFC6937] is the introduction of a new
   "safeACK" heuristic that assesses recovery progress to select =
the
   Reduction Bound. For TCP, an ACK is=
 deemed a "safeACK" when
   proc=
essing the ACK advances SND.UNA without the loss detection
   algorithm detecting any new packet losses (this heuris=
tic
   applies to both SACK and non-SACK c=
onnections).

neal

= --000000000000fc207205ed753c74--