Re: [tcpm] A question about PRR/loss recovery

Yuchung Cheng <ycheng@google.com> Mon, 19 April 2021 16:55 UTC

MIME-Version: 1.0
References: <MN2PR00MB08779B864962711A2F35F2F4C34C9@MN2PR00MB0877.namprd00.prod.outlook.com> <CADVnQy=2rC4N84DDMV-Ovo8v_wNZ3i_fd4AkXzCYY2W0cdcqnQ@mail.gmail.com>
In-Reply-To: <CADVnQy=2rC4N84DDMV-Ovo8v_wNZ3i_fd4AkXzCYY2W0cdcqnQ@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 19 Apr 2021 09:55:16 -0700
Message-ID: <CAK6E8=cn=7=amNg93o=X9+jVSjXALetkgJM7q+dXQ2WLVORJNA@mail.gmail.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>, Nandita Dukkipati <nanditad@google.com>
Content-Type: multipart/alternative; boundary="000000000000e1085d05c05633fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/-MKplwByjQCl_pGozSpckJf6hwg>
Subject: Re: [tcpm] A question about PRR/loss recovery
Precedence: list

I think the current PRR RFC is fairly clear about cwnd computation and it
should be used for both retransmits and new data (so both implicitly use
sndcnt). Having limited-transmit (i.e. new-data) only follow the
(unmodified) cwnd would break PRR substantially -- the packet conservation
principle is not really implemented. I suppose it's easy to fix Windows
code?

On Fri, Apr 16, 2021 at 12:44 PM Neal Cardwell <ncardwell@google.com> wrote:

>
>
> On Fri, Apr 16, 2021 at 3:08 PM Yi Huang <huanyi=
> 40microsoft.com@dmarc.ietf.org> wrote:
>
>> Hi tcpm and PRR authors,
>>
>>
>>
>> We are revisiting PRR implementation in Windows and I noticed there might
>> be a problem in our implementation (and it is actually not specific to PRR).
>>
>>
>>
>> PRR algorithm computes a sndcnt on each ACK during loss recovery and thus
>> use it to accurately regulate bytes in-flight.
>>
>>
>>
>> In the RFC (6937 or bis), I see this statement and note “local” and
>> “response to each ACK”.
>>
>>    We introduce a local variable "sndcnt", which indicates exactly how
>>
>>    many bytes should be sent in response to each ACK.
>>
>>
>>
>> In Windows’ TCP implementation, new data can be also sent out inline
>> during loss recovery from app send context (app calling send()) and they
>> are not regulated by sndcnt/PRR. Instead, we just check if CWND allows us
>> to send in this case. So, effectively, we use two variables controlling the
>> number of bytes in flight during loss recovery, i.e. sndcnt and CWND. It
>> apparently seems a bad behavior because it ignores PRR’s sendcnt but I just
>> want to double check with the PRR authors and the community.
>>
>>
> Thanks for the note.
>
> I believe that approach runs contrary to the intent of the PRR
> spec/algorithm.
>
> Implicit in the end of the algorithm in
> https://tools.ietf.org/html/rfc6937#section-3 is the following line (in
> pseudocode):
>
>   cwnd = pipe + sndcnt
>
> That is what the Linux TCP implementation of the PRR algorithm does. That
> way there is only one variable (cwnd) controlling the number of bytes in
> flight during loss recovery. Effectively, this allows the PRR algorithm
> decision to persist, in case there is no data available to send at the
> instant the ACK arrives.
>
> Perhaps the update to the PRR RFC can make this explicit?
>
> best,
> neal
>
>

[tcpm] A question about PRR/loss recovery Yi Huang
Re: [tcpm] A question about PRR/loss recovery Neal Cardwell
Re: [tcpm] A question about PRR/loss recovery Yuchung Cheng
Re: [tcpm] [EXTERNAL] Re: A question about PRR/lo… Yi Huang