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

[Yoshifumi Nishida <[e-mail]>]

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
>