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

[Yoshifumi Nishida <[e-mail]>]

On Mon, Feb 5, 2024 at 8:25 AM Neal Cardwell <[e-mail]> wrote:

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

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