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

[Yuchung Cheng <[e-mail]>]

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