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

From: Matt Mathis <[email-masked]>
Date: Fri, 13 Jul 2012 15:04:19 -0700

Sorry I didn't get back on this sooner:  I incorporated your changes
as suggested, except as detailed below.     The new draft will be
posted "Real Soon Now."

I believe it will be ready to advance.   Formal WGLC next?

On Tue, Mar 20, 2012 at 10:14 PM, Yoshifumi Nishida
<[email-masked]> wrote:
> 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.

Perhaps the examples would have been simpler, but PRR is
"philosophically aligned" with limited transmit, and it would have
been sort of odd not to use it.

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

I think you are correct.   The psuedo code matches our actual code and
causes us to forfeit an opportunity to send one segment slightly
earlier than we do.   However, we have chosen not to make this change
in the document because it would invalidate our measurement
experiment.    To preserve the integrity of our experimental process
we would either need to remove the results or re-do them.

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

Yep, but we didn't change it.

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

cwnd is not used (and made the text more prominent.)

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

limit = DeliverdData+SMSS
which is 2 for ACKs 18 and 19.

> 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

See above.   Think of prr_delivered - prr_out as the bank: they
reflect the cumulative totals since the beginning of recovery.  By
themselves they won't let you grow pipe.   The DeliveredData term, on
the other hand, is unconstrained by the past and lets you grow
inflight by one MSS on every ACK.

> Editorial Comments:

[snip - thanks]

(Except RFC 3042 is only used informatively.)

> Regards,
> --
> Yoshifumi Nishida

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 18 Jul 2012 00:35:53 -0700

Hi Matt,

Thanks for the detailed clarification.
I agree with the most of your comments, but just one thing....

> earlier than we do.

I see the situation. But, you don't need to explore (or encourage
exploring) the latter case (pipe >= ssthresh) for future experiments? The
latter case seems to be a bit more optimal with regard to spacing packets
although it might be minor.

Thanks,
--
Yoshifumi Nishida