Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 2

[Markku Kojo <[e-mail]>]

Hi all,

below please find proposed text to solve the Issue 2 a). I will propose 
text to solve 2 b) once we have come to conclusion with 2 a). For 
description and arguments for issues 2 a) and 2 b), please see the 
original issue descriptions below.

Sec 4.6. Multiplicative Decrease

Old:
    The parameter Beta__cubic_ SHOULD be set to 0.7, which is different
    from the multiplicative decrease factor used in [RFC5681] (and
    [RFC6675]) during fast recovery.


New:
    If the sender is not in slow start when the congestion event is
    detected, the parameter Beta__cubic_ SHOULD be set to 0.7, which
    is different from the multiplicative decrease factor used in
    [RFC5681] (and [RFC6675].
    This change is justified in the Reno-friendly region during
    congestion avoidance because a CUBIC sender compensates the higher
    multiplicative decrease factor than that of Reno by applying
    a lower additive increase factor during congestion avoidance.

    However, if the sender is in slow start when the congestion event is
    detected, the parameter Beta__cubic_ MUST be set to 0.5 [Jacob88].
    This results in the sender continuing to transmit data at the maximum
    rate that the slow start determined to be available for the flow.
    Using Beta__cubic_ with a value larger than 0.5 when the congestion
    event is detected in slow start would result in an overagressive send
    rate where the sender injects excess packets into the network and
    each such packet is guaranteed to be dropped or force a packet from
    a competing flow to be dropped at a tail-drop bottleneck router.
    Furthermore, injecting such undelivered packets 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]


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

Thanks,

/Markku

On Tue, 14 Jun 2022, Markku Kojo wrote:

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