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

[Yoshifumi Nishida <[e-mail]>]

Hi Neal,

On Wed, Jan 31, 2024 at 8:43 AM Neal Cardwell <ncardwell=
[e-mail]> wrote:

>
>
> On Wed, Jan 31, 2024 at 11:04 AM <rs.ietf=[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)
--
Yoshi