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

[[e-mail]]

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
>