Re: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-05.txt

On Wed, Jan 31, 2024 at 11:04 AM <rs.ietf=40gmx.at@dmarc.ietf.org> wrote:

>
> Hi,
>
> I'm slightly surprised that PRR removes any specific mentioned to the
> SACK loss recovery (with already SACKed data) vs. non-SACK loss
> recovery. The wording changed in section 5 makes it more ambigious if
> delivered data (SACKed) at the initialization of PRR loss recovery
> should be included or not...
>
> This is the one technical change in this revision; excluding SACKed data
> on entering PRR loss recovery, doesn't that either add complexity
> (tracking what SACKed / retransmitted / lost data was at the start of
> PRR and excluding this subsequently), or inflate the transmission
> opportunities when SndCnd is calculated?
>

Good points. What do folks think of the following proposed edits:

proposed edit 1:
---
Old version from version 05:
  RecoverFS is the number of unacknowledged bytes upon entering fast
recovery, and as such it remains constant during a given fast recovery
episode..

Proposed:
  Upon entering fast recovery, PRR initializes RecoverFS to the value of
"pipe", the sender's estimate of the number of bytes outstanding in the
network, where "pipe" is computed as specified in RFC 6675. RecoverFS
remains constant during a given fast recovery episode.

proposed edit 2:
---
Old version from version 05:
  RecoverFS = snd.nxt - snd.una // FlightSize right before recovery

Proposed:

   pipe = (RFC 6675 pipe algorithm)

   RecoverFS = pipe              // RFC 6675 pipe before recovery

> Also, there are a few nits:
>
> Double Dot (..) last in 3rd to last paragraph in section 5 (RecoverFS).
>

Thanks. This typo will be fixed in the next rev.

> Spurious "Figure 1" in section 6  - it's not clear why these initial
> values need to be a Figure.
>

Thanks. I've made proposed edits in the source doc so that the pseudocode
segments should no longer be notated as figures.

neal

>
> Best regards,
>     Richard
>
>
> Am 30.01.2024 um 02:43 schrieb internet-drafts@ietf.org:
> > Internet-Draft draft-ietf-tcpm-prr-rfc6937bis-05.txt is now available.
> It is a
> > work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the
> IETF.
> >
> >     Title:   Proportional Rate Reduction for TCP
> >     Authors: Matt Mathis
> >              Nandita Dukkipati
> >              Yuchung Cheng
> >              Neal Cardwell
> >     Name:    draft-ietf-tcpm-prr-rfc6937bis-05.txt
> >     Pages:   17
> >     Dates:   2024-01-29
> >
> > Abstract:
> >
> >     This document updates the experimental Proportional Rate Reduction
> >     (PRR) algorithm, described RFC 6937, to standards track.  PRR
> >     provides logic to regulate the amount of data sent by TCP or other
> >     transport protocols during fast recovery.  PRR accurately regulates
> >     the actual flight size through recovery such that at the end of
> >     recovery it will be as close as possible to the slow start threshold
> >     (ssthresh), as determined by the congestion control algorithm.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-tcpm-prr-rfc6937bis-05.html
> >
> > A diff from the previous version is available at:
> >
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-05
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > 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
>