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

[Yuchung Cheng <[e-mail]>]

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