From nobody Mon Nov 14 13:42:01 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 214B6C14CF13 for ; Mon, 14 Nov 2022 13:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.597 X-Spam-Level: X-Spam-Status: No, score=-17.597 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZBGGATQQub69 for ; Mon, 14 Nov 2022 13:41:56 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 62C14C14CF05 for ; Mon, 14 Nov 2022 13:41:56 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id b124so12885469oia.4 for ; Mon, 14 Nov 2022 13:41:56 -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=osg9uFTDpYp9AAS0eyLWH4bWWkC/brad6CescM8m+w4=; b=ofWr/VUJdyaBpT/03K5gdUobLn3CnVmTlTLwM3GzdDhwbHhVbTOmuSZYDbAU//U73a q3/HBd2X75PEhWv0SC0AWcgHONRpjLWgnKu1gRyugW49+kBpCiq7DCl9Fm1scy1PQULc MdXS/iXygWZnnJ73PvzJ7nUyyrIYvYl4aFETNTFq+bybOPxNT6jcC1wvTaFw1RBo99an 1xlehpgtHrCd6rWDPf1+cvGp5uZS15Ggp94WVUDv7ABrRLh6pwSGPYs9lk+shUuUYdl7 yX8DQLrQ8+S3QugPFvyFzw4lxn0kKLUQoWQt4rT8ldBVxEWo6kSOJNX2Q3abzHMB3jSZ VsGw== 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=osg9uFTDpYp9AAS0eyLWH4bWWkC/brad6CescM8m+w4=; b=qCj2HyGWg2h9oWtjbEKsUJrR4ou2YRR0SXPPbr+m+xp+h3jJ28+pU8MRGmnuKI9Hpc ZVtjVIq2CRMVKdn+6mh9kRqIPJbMge6B8vsilWvxhfDDRrcbwaY/x3z7GI2rMz6/7XED bYFn1qcoZqNJSi2AZA2cGqVe8sd2xtED+YYs4cAy6laP3tdfv0+fGt8xNRxAGiyHxkRc 8aZvw4GAamBxkt+rh2YvrXeIjRlrEMze1H7WpxdXr5yuhHICqswmgLMw0IPhIyRKaAix 9q3CLX/wLV2fA50gobsEhAmI12w++nxVMKi53bSWzV39Yf2WOnrRGxAvOV0MiRX7VMpE FZFA== X-Gm-Message-State: ANoB5pmxH9cFvEl9IXdF8oj13cECICqpJVBlIrJz2Mi73iRgceApJY7Y gO7UjnWCC2aLlCTB3Q3xDMUdno9fra0OntVXuUCQkg== X-Google-Smtp-Source: AA0mqf57MPVfyrA7R28kWgZYJYPBSJDq+OL21vkBhRLYHjTymLS8hJ9FnUixztDlusYv3mZC507zdSSiW/VcRurVhB0= X-Received: by 2002:a54:4189:0:b0:35a:7461:8670 with SMTP id 9-20020a544189000000b0035a74618670mr6586661oiy.76.1668462115074; Mon, 14 Nov 2022 13:41:55 -0800 (PST) MIME-Version: 1.0 References: <161060871994.10783.1247396842504892132@ietfa.amsl.com> <7c527d72-2f48-b39e-9f09-0f22e9c865f2@gmx.at> In-Reply-To: From: Neal Cardwell Date: Mon, 14 Nov 2022 16:41:39 -0500 Message-ID: To: Yuchung Cheng Cc: rscheff@freebsd.org, tcpm@ietf.org, draft-ietf-tcpm-prr-rfc6937bis@ietf.org, "Semke, Jeff" Content-Type: multipart/alternative; boundary="000000000000b155c305ed751bf7" 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:42:00 -0000 --000000000000b155c305ed751bf7 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 14, 2022 at 3:43 PM Yuchung Cheng 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 --000000000000b155c305ed751bf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 14, 2022 at 3:43 PM Yuchung C= heng <ycheng=3D40google.c= om@dmarc.ietf.org> wrote:
On Wed, Nov 9, 2022 at 3:13 PM = Scheffenegger, Richard <rs.ietf@gmx.at> 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 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 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 introdu=
ction of a new
   "safeACK" heuristic that assesses recovery progress to select =
the
   Reduction B=
ound. For TCP, an ACK is deemed a "safeACK" when
   processing the ACK advances SN=
D.UNA without the loss detection
   algorithm detecting any new packet losses (this heuristic=

   applies to bot=
h SACK and non-SACK connections).

neal

--000000000000b155c305ed751bf7--