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

[[e-mail]]

As just mentioned:

I found that using RFC6675 pipe() in both SACK and non-SACK cases, and
even additionally in the standard FastRecovery, as well as the special
RTO, followed by FastRecovery in quick succession (before snd.una has
acked snd.recover (RecoveryPoint), works quite ok.

In short: I don't think the document needs any special text around the
non-SACK, or the FR-after-RTO case.

Best regards,
   Richard


Am 06.02.2024 um 20:00 schrieb Yoshifumi Nishida:
> Hi Neal,
>
> Sounds good to me. I just would like to check if some folks have any
> opinions.
> If this is fine, we will think about submitting it to IESG.
> Thanks,
> --
> Yoshi
>
> On Mon, Feb 5, 2024 at 2:29 PM Neal Cardwell <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     On Mon, Feb 5, 2024 at 11:51 AM Yoshifumi Nishida
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>         On Mon, Feb 5, 2024 at 8:25 AM Neal Cardwell
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>             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 .
>
>
>         OK. I see your point. Thanks for the clarification.
>         Do we want to specify the better value for non-sack case than
>         the current one or leave it to implementations?
>
>
>     Good question. Matt and I chatted about this just now. We have
>     updated the proposed draft text describing RecoverFS so that it now
>     reads as:
>     ---
>     RecoverFS is the "recovery flight size", the number of bytes the
>     sender estimates are in flight in the network upon entering fast
>     recovery. PRR uses RecoverFS to compute a smooth sending rate. Upon
>     entering fast recovery, PRR initializes RecoverFS to the sender's
>     best estimate of the number of bytes outstanding in the network; for
>     connections with SACK this is typically "pipe" as specified in RFC
>     6675. RecoverFS remains constant during a given fast recovery episode.
>     ---
>
>     The initialization proposed pseudocode still reads as:
>     ---
>
>         pipe = (RFC 6675 pipe algorithm)
>         RecoverFS = pipe              // RFC 6675 pipe before recovery
>
>     ---
>
>     Our sense was that this approach is general enough to encompass both
>     SACK and non-SACK cases.
>
>     We could indeed spell out the pseudocode for the non-SACK case, but
>     we wanted to avoid specifying something that might accidentally
>     conflict with other standards, now or in the future.
>
>     How does that sound?
>
>     best regards,
>     neal
>