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

[Yoshifumi Nishida <[e-mail]>]

Hi folks,

Thanks for the inputs. I started preparing a write up for this draft as it
seems that we've reached a consensus here.

In order for the write-up, I would like to check the current status of the
implementations.
I believe linux already supports 6937bis logic and FreeBSD as well.
Do we have other implementations?

Thanks,
--
Yoshi


On Tue, Feb 6, 2024 at 12:06 PM <[e-mail]> wrote:

>
> I concur; RFC6675 pipe() effectively returns snd.max (HighData) -
> snd.una (HighACK), which may be proplematic right after an RTO has
> happened (when snd.nxt != snd.max). But in the general case (non-RTO),
> RFC6675 pipe returns the correct value.
>
> But I found that for PRR, using snd.max after an RTO seems to be the
> reasonable choice, as it will try to recover up to that point which was
> previously transmitted, in the PRR "pacing" fashion...
>
> Richard
>
>
>
> Am 05.02.2024 um 17:25 schrieb Neal Cardwell:
> >
> >
> > On Mon, Feb 5, 2024 at 12:04 AM Yoshifumi Nishida <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Neal,
> >
> >     On Wed, Jan 31, 2024 at 8:43 AM Neal Cardwell
> >     <ncardwell=[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >
> >
> >
> >         On Wed, Jan 31, 2024 at 11:04 AM
> >         <rs.ietf=[e-mail]
> >         <mailto:[e-mail]>> 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
> >
> >
> >     Hmm. but, if SACK is not used, can we use pipe?
> >     Wouldn't it be something like this?
> >
> >     pipe = (SACK is used)?(RFC 6675 pipe algorithm):(snd_nxt - snd.usa)
> >
> >
> > Why not use pipe for non-SACK connections? AFAICT the pipe definition
> > can be used for non-SACK connections.
> >
> > If we take the RFC 6675 definition of pipe literally, then for non-SACK
> > connections AFAICT IsLost (S1) returns false for every packet between
> > SND.UNA and SND.NXT, so that pipe will be SND.NXT - SND.UNA? And that
> > would match the answer from this proposed logic, AFAICT?
> >
> > If we take the notion of pipe semantically, then for non-SACK
> > connections AFAICT this encourages TCP implementations to initialize
> > RecoverFS to their estimate of the amount of data outstanding in the
> > network. Implementations may have a non-SACK notion of pipe that is
> > better than SND.NXT - SND.UNA. For example, Linux TCP has a non-SACK
> > pipe estimate that, upon entry to fast recovery, would be esssentially
> > SND.NXT - SND.UNA - (num_dupacks_received*SMSS). That's a better (more
> > accurate) value to use than SND.NXT - SND.UNA .
> >
> > best regards,
> > neal
> >
> >
> >
> >     --
> >     Yoshi
> >
>