Subject: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02

From: Greg White <[email-masked]>
Date: Tue, 13 Sep 2016 19:02:26 +0000

Seeing Marcelo’s comments prompted me to read the draft as well.  I have just a few comments, and also I found a couple of typos.

Comment 1:  Section 4.8 contains a lower case “should not”.  This seems like it should be a “SHOULD NOT”.

   In cases of idle periods, t in Eq. 1 SHOULD NOT include the
   idle time; otherwise, W_cubic(t) might be very high after restarting
   from a long idle time.

Comment 2:  Section 4.3 reads:

4.3.  Difficult Environments

   CUBIC is designed to remedy the poor performance of TCP in fast long-
   distance networks.  It is not designed for wireless networks.

Since a large proportion of TCP flows today cross a wireless link (WiFi or LTE), this statement and the heading seem kind of anachronistic.   Perhaps it would be better to describe what some of the concerns might be with operation across today’s networks that are likely to contain wireless links (if there are any), or state what properties of a wireless network would cause problems for CUBIC.

Comment 3: Section 4.5 states:

   In case that there is congestion collapse, CUBIC behaves likely
   standard TCP ...

I believe that the whole point of congestion avoidance algorithms such as CUBIC is to prevent congestion collapse.  (Also note the typo “likely” in that sentence.)  Maybe this would be better written as:

   With regard to the potential of causing congestion collapse,
   CUBIC behaves like standard TCP ...

Typo:

Section 3.2, first sentence reads:

  When receiving an ACK in congestion avoidance, we first check whether

   the protocol is in the TCP region or not.

I believe it should be:

   When receiving an ACK in congestion avoidance, we first check whether

   the protocol is in the TCP **friendly** region or not.

Best Regards,

Greg

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 13 Sep 2016 14:39:18 -0700

>    idle time; otherwise, W_cubic(t) might be very high after restarting
why SHOULD vs MUST? I can't think of any corner case that we'd want to
include the idle time.

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Lisong Xu <[email-masked]>
Date: Tue, 13 Sep 2016 21:24:23 -0500

Thanks, Greg, for your comments!

Lisong

On 9/13/2016 2:02 PM, Greg White wrote:
>
> Seeing Marcelo’s comments prompted me to read the draft as well.  I 
> have just a few comments, and also I found a couple of typos.
>
> Since a large proportion of TCP flows today cross a wireless link 
> (WiFi or LTE), this statement and the heading seem kind of 
> anachronistic.   Perhaps it would be better to describe what some of 
> the concerns might be with operation across today’s networks that are 
> likely to contain wireless links (if there are any), or state what 
> properties of a wireless network would cause problems for CUBIC.
>
> I believe that the whole point of congestion avoidance algorithms such 
> as CUBIC is to prevent congestion collapse.  (Also note the typo 
> “likely” in that sentence.)  Maybe this would be better written as:
>

---

From: Lisong Xu <[email-masked]>
Date: Tue, 13 Sep 2016 21:26:50 -0500

Thanks, Yuchung!  If the idle time is very short, it might be ok to 
include the idle time?
Lisong

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 13 Sep 2016 21:19:00 -0700

> Thanks, Yuchung!  If the idle time is very short, it might be ok to

Sure but to me a SHOULD means there is some legit cases where we would
include idle time. Since any system has finite timer granularity, the case
you mentioned does not violate MUST imo.

>>> Seeing Marcelo’s comments prompted me to read the draft as well.  I have
>>> just a few comments, and also I found a couple of typos.
>>>
>>>
>>>
>>>
>>>
>>> Since a large proportion of TCP flows today cross a wireless link (WiFi
>>> or LTE), this statement and the heading seem kind of anachronistic.
>>>  Perhaps it would be better to describe what some of the concerns might be
>>> with operation across today’s networks that are likely to contain wireless
>>> links (if there are any), or state what properties of a wireless network
>>> would cause problems for CUBIC.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> as CUBIC is to prevent congestion collapse.  (Also note the typo “likely”
>>> in that sentence.)  Maybe this would be better written as:
>>>
>>>
>>>

---

From: Lisong Xu <[email-masked]>
Date: Wed, 14 Sep 2016 09:30:15 -0500

Thanks, Yuchung. I think you are right that we should change it to "Must 
Not".

Lisong

On 9/13/2016 11:19 PM, Yuchung Cheng wrote:
>
>
> On Tue, Sep 13, 2016 at 7:26 PM, Lisong Xu <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thanks, Yuchung!  If the idle time is very short, it might be ok
>     to include the idle time?
>     Lisong
>
> include idle time. Since any system has finite timer granularity, the 
> case you mentioned does not violate MUST imo.
>
>
>
>
>         On Tue, Sep 13, 2016 at 12:02 PM, Greg White
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Seeing Marcelo’s comments prompted me to read the draft as
>             well.  I have just a few comments, and also I found a
>             couple of typos.
>
>
>
>
>
>             Comment 1:  Section 4.8 contains a lower case “should
>             not”.  This seems like it should be a “SHOULD NOT”.
>
>
>
>             Since a large proportion of TCP flows today cross a
>             wireless link (WiFi or LTE), this statement and the
>             heading seem kind of anachronistic.   Perhaps it would be
>             better to describe what some of the concerns might be with
>             operation across today’s networks that are likely to
>             contain wireless links (if there are any), or state what
>             I believe that the whole point of congestion avoidance
>             algorithms such as CUBIC is to prevent congestion
>             collapse.  (Also note the typo “likely” in that
>             sentence.)  Maybe this would be better written as:
>
>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/tcpm>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
>