Re: [tcpm] A new Internet draft for TCP Cubic - Version 05

[Yoshifumi Nishida <[e-mail]>]

Hi Lisong,

Thanks for the clarification. I am fine with the current draft as an INFO
doc.
I will prepare a write-up for this in a couple of days unless there's any
other last minute comments/questions.
--
Yoshi

On Wed, Jul 19, 2017 at 7:28 PM, Lisong Xu <[e-mail]> wrote:

> Hi Yoshi,
>
> The choice of 0.4 is a tradeoff between the aggressiveness (throughput)
> and tcp friendliness. It was manually selected based on our extensive
> experiments, and there is no magic formula for it :-)
>
> Thanks
>
> Lisong
>
> On 7/19/2017 6:43 PM, Yoshifumi Nishida wrote:
>
> Hi Lisong,
>
> Thank you so much for updating the draft and sorry for my very slow
> response.
> It looks almost good to me, but one thing I am still thinking is choosing
> the value for C.
> I still cannot see strong reason for C=0.4. It seems to me it could be 0.3
> or 0.5 or other values.
> Is there any design rationale here? Or, was it just heuristically
> determined?
> Sorry for a picky question, but I guess I might not be the only one..
>
> Thanks,
> --
> Yoshi
>
>
> On Mon, Jul 17, 2017 at 9:28 PM, Lisong Xu <[e-mail]> wrote:
>
>> Greetings,
>>
>> We just submitted a new Internet draft for TCP CUBIC available at the
>> following link
>>
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/
>>
>> In this version, we made the following changes based on the comments
>> received on [e-mail] between February 2017 and July 2017.
>>
>> * Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675
>>
>> * Section 4.2: more clearly explain TCP friendly region.
>> From "If W_cubic(t) is less than W_aimd(t), then the protocol is in the
>> TCP friendly region"
>> to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd
>> is greater than or less than W_max), then the protocol is in the TCP
>> friendly region"
>>
>> * New Section 4.8: Slow start behavior of CUBIC
>> "CUBIC MUST employ a slow start algorithm, when the cwnd is no more than
>> ssthresh.
>> Among the slow start algorithms, CUBIC MAY choose the standard TCP slow
>> start [RFC5681] in general networks,
>> or the limited slow start [RFC3742] or hybrid slow start [HR08] for
>> high-bandwidth and long-distance networks."
>>
>> * Section 4.6: more clearly explain fast convergence
>> Add "The fast convergence is designed for network environments with
>> multiple CUBIC flows. In network environments with only a single CUBIC flow
>> and without any other traffic, the fast convergence SHOULD be disabled."
>>
>> * Section 5.4: briefly mention the standing queue issue
>> "Because CUBIC is designed to be more aggressive (due to faster window
>> growth function and bigger multiplicative decrease factor) than Standard
>> TCP in fast and long distance networks, it can fill large drop-tail buffers
>> more quickly than Standard TCP and increase the risk of a standing
>> queue[KWAF16]. In this case, proper queue sizing and management [RFC7567]
>> could be used to reduce the packet queueing delay."
>>
>> * Section 5.8: revise the application limited flows
>> From "CUBIC does not raise its congestion window size if the flow is
>> currently limited by the application instead of the congestion window. In
>> cases of idle periods, t in Eq. 1 MUST NOT include the idle time;
>> otherwise, W_cubic(t) might be very high after restarting from a long idle
>> time."
>> to "CUBIC does not raise its congestion window size if the flow is
>> currently limited by the application instead of the congestion window. In
>> case of long periods when cwnd is not updated due to the application rate
>> limit, such as idle periods, t in Eq. 1 MUST NOT include these periods;
>> otherwise, W_cubic(t) might be very high after restarting from these
>> periods"
>>
>> Thanks
>>
>> Lisong
>>
>
>
>