[tcpm] CUBIC rfc8312bis / WGLC Issue 2

[Markku Kojo <[e-mail]>]

Hi all,

this thread starts the discussion on the issue 2: CUBIC is specified to 
use incorrect multiplicative-decrease factor for a congestion event that 
occurs when operating in slow start. And, applying HyStart++ does not 
remove the problem, it only mitigates it in some percentage of cases.

I think it is useful to discuss this in two phases: 2 a) and 2 b) below.
For anyone commenting/arguing on the part 2 b), it is important to first
acknowledge whether (s)he thinks the original design and logic by Van 
Jacobson is correct. If not, one should explain why Van's design logic is 
incorrect.

Issue 2 a)
----------

To begin with, let's but aside a potential use of HyStart++ (also assume 
tail drop router unless otherwise mentioned).

The use of an MD factor larger than 0.5 is against the theory and 
original design by Van Jacobson as explained in the congavoid paper 
[Jacob88]. Any MD factor value larger then 0.5 will result sending extra 
packets during Fast Recovery following the congestion event (drop). All 
extra packets will become dropped at a tail-drop bottleneck (if a lonely 
flow).

Note that at the time when the drop becomes signalled at the TCP sender, 
the size of the cwnd is double the available network capacity that slow 
start determined for the flow. That is, using MD=0.5 is already as 
aggressive as possible, leaving no slack. Therefore, if MD=0.7 is used, 
the TCP sender enters fast recovery with cwnd that is 40% larger that the 
determined network capacity and all excess packets are guaranteed to 
become dropped, or even worse, the excess packets are likely to force 
packets for any competing flows to become unfairly be dropped.

Moreover, if NewReno loss recovery is in use, a CUBIC sender will
operate overagressively for a very long time. For example, if the
available network capacity for the flow is 100 packets, cwnd will have
value 200 when the congestion is signalled and the CUBIC sender enters
fast recovery with cwnd=140 and injects 40 excess packets for each of
the subsequent 100 RTTs it stays in fast recovery, forcing 4000 packets to 
become inevitably and totally unnecessarily dropped.

Even worse, this behaviour of sending 'undelivered packets' is against
the congestion control principles as it creates a danger of congestion
collapse (of some degree) "by delivering packets through the network
that are dropped before reaching their ultimate destination." [RFC 2914]

Such undelivered packets unnecessarily eat capacity from other flows
sharing the path before the bottleneck.

RFC 2914 emphasises:

  "This is probably the largest unresolved danger with respect to
   congestion collapse in the Internet today."

It is very easy to envision a realistic network setup where this creates 
a degree of congestion collapse where a notable portion of useful network 
capacity is wasted due to the undelivered packets.


[Jacob88] V. Jacobson, Congestion avoidance and control, SIGCOMM '88.


Issue 2 b)
----------

The CUBIC draft suggests that HyStart++ should be used *everywhere* 
instead of the traditional Slow Start (see section 4.10).

Although the draft does not say it, seemingly the authors suggest using 
HyStart++ instead of traditional Slow Start in order to avoid the problem 
of over-aggressive behaviour discussed above. This, however, has several 
issues.

First. it is directly in conflict with HyStart++ specification which says 
that HyStart++ should be used only for the initial Slow Start. However, 
the overaggressive behaviour after slow start is also a potential problem 
with slow start during an RTO recovery; in case of sudden congestion that 
reduces available capacity for a flow down to a fraction of the currently 
available capacity, it is very likely that an RTO occurs. In such a case 
the RTO recovery in slow start inevitably overshoots and it is crucial 
for all flows not to be overaggressive.

Second, the experimental results for initial slow start in HyStart++ 
draft suggest that while HyStart++ achieves good results HyStart++ is 
unable to exit slow start early and avoid overshoot in a significant 
percentage of cases.

Given the above issues, the CUBIC draft must require that MD of 0.5 is 
used when the congestion event occurs while the sender is (still) in slow 
start. The use of MD=0.5 is an obvious stumble in the original CUBIC 
and the original CUBIC authors have already acknowledged this. It seems 
also obvious that instead of correcting the actual problem (use of MD 
other than 0.5), HyStart and HyStart++ have been proposed to address 
the design mistake. While HyStart++ is a useful method also when used 
with MD=0.5, when used alone it only mitigates the impact of the actual 
problem rather than solves the problem.

What should be done for the cases where HyStart++ exits slow start but
is not able to avoid (some level of) overshoot and dropped packets is 
IMO an open issue. Resolving it requires additional experiments and it 
should be resolved separately when we have more data. For now when we do 
not have enough data and understanding of the behaviour we should IMO 
follow the general IETF guideline "be conservative in what you send" and 
specify that MD = 0.5 should be used for a congestion event that occurs 
for a packet sent in slow start.

Thanks,

/Markku