Re: [tcpm] comments on draft-ietf-tcpm-prr-rfc6937bis-01

[Yoshifumi Nishida <[e-mail]>]

Hi Yuchung,

Got it. Thanks for the clarification.
--
Yoshi

On Sat, Sep 17, 2022 at 4:32 PM Yuchung Cheng <[e-mail]> wrote:

> hi Yoshifumi,
>
> yes we already explain the values are before any transmission because we
> think it illustrates the "sent" behaviour better.  see the 2nd paragraph of
> the examples section
> "The top line indicates the transmitted segment
>    number triggering the ACKs, with an X for the lost segment.  "cwnd"
>    and "pipe" indicate the values of these algorithms after processing
>    each returning ACK but before further (re)transmission."
>
> On Wed, Sep 14, 2022 at 10:44 AM Yoshifumi Nishida <[e-mail]>
> wrote:
>
>> Hi Yuchung,
>>
>> Sorry for my very slow response and thanks for addressing my comments.
>> They look good to me.
>> One remaining minor comment I have is the values in the examples in
>> Section 7 such as the below.
>>
>> I think I understand the values there, but it seems that the values for
>> cwnd and pipe are the values in the period between after a new ACK segment
>> arrives and before sending something.
>> I am wondering it might be good to use the value for after sending
>> segments (when all steps has finished) or might need to add more
>> explanations about it.
>>
>> >    RFC 6675
>> >    ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>> >    cwnd:    20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
>> >    pipe:    19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10
>> >    sent:     N  N  R                          N  N  N  N  N  N  N  N
>> >
>>
>> Thanks,
>> --
>> Yoshi
>>
>> On Thu, Aug 4, 2022 at 8:07 AM Yuchung Cheng <[e-mail]> wrote:
>>
>>> To clarify, all these fixes are in
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-02
>>>
>>> My previous email was responding to Yoshifumi's question in the last
>>> tcpm meeting: did -02 address my comments?
>>>
>>> On Thu, Aug 4, 2022 at 10:00 AM Yuchung Cheng <[e-mail]> wrote:
>>> >
>>> > Hi Yoshifumi
>>> >
>>> > On Wed, Feb 9, 2022 at 11:30 AM Yoshifumi Nishida <[e-mail]>
>>> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I have the following comments on draft-ietf-tcpm-prr-rfc6937bis-01
>>> > >
>>> > > 1: Page 5
>>> > >     "but recommended to use BBR-SSRB"
>>> > >       -> PRR-SSRB?
>>> > fixed
>>> >
>>> > >
>>> > > 2: Page 7
>>> > >     "and do what? @@@@"
>>> > >       -> Please add more texts or remove this.
>>> >
>>> > New text to replace the "do what"
>>> > "Without SACK,
>>> >
>>> >    DeliveredData is the change in snd.una for a partial ACK or 1 MSS
>>> >    worth of bytes for a DUPACK.
>>> >
>>> >    Note that without SACK, a poorly-behaved receiver that returns
>>> >    extraneous DUPACKs as depicted in [Savage99] can artificially
>>> inflate
>>> >    DeliveredData.  As a mitigation, PRR disallows incrementing
>>> >    DeliveredData when the total bytes delivered exceeds the outstanding
>>> >    data upon recovery (i.e., RecoverFS).
>>> > "
>>> >
>>> > >
>>> > > 3: Page 8:
>>> > >    """
>>> > >       prr_delivered = 0         // Total bytes delivered during
>>> recovery
>>> > >
>>> > >       prr_out = 0               // Total bytes sent during recovery
>>> > >
>>> > >    """
>>> > >      -> I personally think "during recovery" might be a bit
>>> ambiguous. I think it would be better to clarify
>>> > >         whether this includes a packet sent by fast retransmit or
>>> not.
>>> >
>>> > The following subroutine should be clear on that it includes
>>> retransmission
>>> >
>>> > On any data transmission or retransmission:
>>> >       prr_out += (data sent)
>>> >
>>> >
>>> > >
>>> > > 4: Page 8:
>>> > >   " pipe = (RFC 6675 pipe algorithm) "
>>> > >
>>> > >      -> The algorithm here seems to depend on SACK, but the draft
>>> also states:
>>> > >         "It is most accurate and more easily implemented with SACK
>>> [RFC2018], but does not require SACK."
>>> > >          I think It is not clear how this algorithm works without
>>> SACK.
>>> > Great catch -- we define the non-SACK algorithm now in the pseudo and
>>> > clarify in section 5
>>> >
>>> >    On every ACK starting or during the recovery:
>>> >       DeliveredData = bytes newly cumulatively acknowledged
>>> >       if (SACK is used) {
>>> >          DeliveredData += bytes newly selectively acknowledged
>>> >       } else if (ACK is a DUPACK and prr_delivered < RecoverFS) {
>>> >          DeliveredData += MSS
>>> >       }
>>> >
>>> >
>>> > >
>>> > > 5: Section 7 Page 9
>>> > >      Why all examples shown here use Limited Transmit even though
>>> PRR doesn't require it?
>>> > >      I think there should be some explanations for it even if
>>> there's no strong reason.
>>> >
>>> > We did mention that we assume RFC3042 in our section 7: "We also
>>> > assume standard Fast Retransmit and Limited Transmit [RFC3042], ... ".
>>> > We use it because it's a standard track RFC and really helps ack
>>> clocking
>>> >
>>> > >
>>> > >
>>> > > 6: Page 10:
>>> > >      It seems that the pipe size in the figure is different from
>>> what RFC6675 calculates because Section 5 (4.2) in RFC6675 mentions
>>> > >     "
>>> > >
>>> > >       note that [RFC5681] requires that any
>>> > >       segments sent as part of the Limited Transmit mechanism not
>>> > >       be counted in FlightSize for the purpose of the above
>>> > >       equation.
>>> > >
>>> > >
>>> > >
>>> > >     Hence, I think the pipe size would be something like this if it
>>> follows RFC6675.
>>> > >
>>> > >     Please let me know if I miss something.
>>> > >
>>> > >
>>> > > 6675
>>> > >    ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>>> > >    cwnd:    20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
>>> > >    pipe:    19 19 19 18 17 16 15 14 13 12 11 10 09 09 09 09 09 09 09
>>> > >    sent:     N  N  R                             N  N  N  N  N  N  N
>>> > >
>>> > >
>>> > > PRR
>>> > >
>>> > >    ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>>> > >    pipe:    19 19 18 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
>>> > >    sent:     N  N  R     N     N     N     N     N     N     N
>>> > Thanks for catching this. Yes we've updated -bis 02 to correct the
>>> > pipe size of PRR to match RFC6675 in the initial phase of recovery.
>>> >
>>> >    RFC 6675
>>> >    ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>>> >    cwnd:    20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
>>> >    pipe:    19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10
>>> >    sent:     N  N  R                          N  N  N  N  N  N  N  N
>>> >
>>> >
>>> >    PRR
>>> >    ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>>> >    cwnd:    20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
>>> >    pipe:    19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10
>>> >    sent:     N  N  R     N     N     N     N     N     N     N     N
>>> >
>>> >
>>> >
>>> >
>>> > >
>>> > >
>>> > >
>>> > > 6675
>>> > >
>>> > >    ack#   X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
>>> > >    cwnd:                                              20 20 10 10 10
>>> > >    pipe:                                              19 19  4 10 10
>>> > >    sent:                                               N  N 6R  R  R
>>> > >
>>> > >
>>> > > Thanks,
>>> > > --
>>> > > Yoshi
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > tcpm mailing list
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>