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

[Yoshifumi Nishida <[e-mail]>]

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]> wrote:

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