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

Yoshifumi Nishida <nsd.ietf@gmail.com> Wed, 09 February 2022 16:30 UTC

MIME-Version: 1.0
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 9 Feb 2022 08:30:22 -0800
Message-ID: <CAAK044TS==yvSf+ve22XVQGU2s2os2P8cqckLykmMb9XEa9MTw@mail.gmail.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bfb7b05d7985a1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/i57MWRpzwFVGPSyHb4jRf1Aeab4>
Subject: [tcpm] comments on draft-ietf-tcpm-prr-rfc6937bis-01
Precedence: list

Hi,

I have the following comments on draft-ietf-tcpm-prr-rfc6937bis-01

1: Page 5
    "but recommended to use BBR-SSRB"
      -> PRR-SSRB?

2: Page 7
    "and do what? @@@@"
      -> Please add more texts or remove this.

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.

4: Page 8:
  " pipe = (RFC 6675 <https://datatracker.ietf.org/doc/html/rfc6675> 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
<https://datatracker.ietf.org/doc/html/rfc2018>], but does not require
SACK."
         I think It is not clear how this algorithm works without SACK.

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.


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
<https://datatracker.ietf.org/doc/html/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



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] comments on draft-ietf-tcpm-prr-rfc6937bis… Yoshifumi Nishida