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

[Neal Cardwell <[e-mail]>]

On Mon, Feb 5, 2024 at 12:04 AM Yoshifumi Nishida <[e-mail]>
wrote:

> 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)
>

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
>
>
>