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

[Neal Cardwell <[e-mail]>]

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

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

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