Subject: [tcpm] WGLC for draft-ietf-tcpm-cubic-04

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 15 Feb 2017 01:13:30 -0800

Hello,

In addition to the dctcp draft, TCP chairs conclude that
draft-ietf-tcpm-cubic-04 is ready for WGLC as well and decided to initiate
the call.

The WGLC for this draft runs until * Friday March 3 *.
Please send your feedback to the ML.

BTW, the intended status of the draft is Informational.
The draft is available from the following URL.
https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04

Thanks,
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 28 Feb 2017 00:08:24 -0800

Hello,

I have the following comments on the draft.

1:  P3. ".. all Reno style TCP standards and their variants, including TCP
RENO, TCP NewReno, TCP-SACK, ..."
     -> It seems to me that RFC2018 doesn't fit into Reno style variants
very well as it doesn't include congestion control mechanism.  I personally
think it would be better to use RFC6675 here, but this is also a NewReno
variants (with SACK options). I am thinking that referring 6582 and 6675 as
TCP-NewReno might be an option.

2: P6. Section 4.1 ".. such as TCP-NewReno and TCP-SACK..."
    -> same as 1:, It seems to me that RFC2018 doesn't fit here very well.

3: P6. Section 4.1
    "beta_cubic" is used for Eq.2, but it is not mentioned which value
should be used here.
    It might be good to add something like "We will describe how to set
beta_cubic in 4.5"?

4: P7.
    It's not very clear to me what we should do if it's in TCP-friendly
region, but cwnd is larger than W_max. Do we apply TCP-friendly algorithm
or convex algorithm?
    I also think it's not clear what we should do during slow-start period.
(I think Marcelo made similar comments before.)

5: P9 Section 4.6
    Can't we simplify the code like this? Also, using 1.0 and 2.0 might be
better as beta_cubic is 0.7?

    If (W_max < W_last_max) {
        W_max = W_max * (1 + beta_cubic) / 2;
    }
    W_last_max = W_max;

6: P11 Section 5.1
    I understand that 0.4 is better than 0.04 or 4. But, I'm not very sure
why it's not 0.3 or 0.5.
    Is it possible to provide some rationale here?

7: P12 Section 5.5
    I personally think what is described here can be explained in
Introduction or Design principle section.
    Because this seems to be a part of fundamental concepts of CUBIC.

    Also, even If we create really aggressive window adjustment logic,
can't it cause congestion collapse?

8: P12 Section 5.8
    It might be fine, but using MUST in the discussion section may look a
bit confusing?

--
Yoshi