Subject: [tcpm] Review of draft-ietf-tcpm-proportional-rate-reduction-01

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 20 Mar 2012 22:14:51 -0700

Hi, I reviewed draft-ietf-tcpm-proportional-rate-reduction-01.
I think this is valid and useful idea. I would like to support publishing
it to do more broad experiments.
Below are my comments on the draft.
Please check and update if you agree with them.

Technical Comments

  1: This is just out of my curiosity and I know there's no major
difference,
     but is there any reasons to use Limited Transmit in the examples in
Section 3.1?
     I just personally thought these examples might be a bit simpler if you
just use RFC3517 logic only.
     (You don't have to count packets transmitted by limited transmit for
pipe calculation)
     But, this is a really minor point. Please keep it if you prefer.

  2: I have a question in the pseudo code in Section 3.

        if (pipe > ssthresh)  {

     Is this supposed to be like this?

        if (pipe >= ssthresh)  {

     Otherwise, if pipe equals to ssthresh, sndcnt will be zero.

  3: If the assumption above is correct, I think the example in Page 6:

 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  N
   RB:                                                          s  s

      will be something like this. Is this correct?

 PRR
   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
   RB:                                                             s

   BTW, is there any reason that there is no cwnd data for PRR in the
figures?

  4: In the following case,

PRR-CRB
  ack#   X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
  pipe:                                              19 19  4  4  4
  sent:                                               N  N  R  R  R
  RB:                                                       f  f  f

     I think PRR_CRB works like this way and this is understandable.

          ack #: 17 18 19
  prr_delivered:  1  2  3
  prr_out:        0  1  2
  limit:          1  1  1
  sndcnt:         1  1  1

     However, in the following case, I think the parameters change like
this way according to the logic in Section 3.
     This result doesn't match the explanation in the draft. Am I
misunderstanding something?

PRR-SSRB
  ack#   X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
  pipe:                                              19 19  4  5  6
  sent:                                               N  N 2R 2R 2R
  RB:                                                       d  d  d

          ack #: 17 18 19
  prr_delivered:  1  2  3
  prr_out:        0  2  4
  limit:          2  1  1
  sndcnt:         2  1  1

  5: Is 'DeliveredData' necessary in the following equation?
     I couldn't come up with good examples. But, I might miss something..

     limit = MAX(prr_delivered - prr_out, DeliveredData) + MSS

Editorial Comments:

 Page 7:

   -> There is no explanation for 'f' and 'd' in the figure.
      I guess this is transmission triggered by PRR+CRB and PRR+SSRB,
      but, please confirm this.

 Page 10:

   .. limited transmit [RFC3742] ..

   -> I guess this doesn't mean Limited Slow Start and should be RFC3042.
      Please confirm this.

 Page 12:

   Reference

   -> I think you can put RFC2018, 3517, 3042 and 5681 into Normative
References and put others into Informative References.

Typos:

    Total bytes delivered during recov ->   Total bytes delivered during
recovery

    FlightSize at the start of recov ->  FlightSize at the start of recovery

    sshthresh -> ssthresh

Regards,
--
Yoshifumi Nishida