Re: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S status tracking)

[Wesley Eddy <[e-mail]>]

On 11/13/2019 11:15 AM, Black, David wrote:
>
> In more detail than I explained earlier: in this forum
>
> We are dealing with two classes of congestion controls.  For lack of 
> better terms the following class names are based on what the transport 
> protocol throughput is proportional to where ‘p’ is the loss and/or 
> congestion marking probability:
>
> - 1/sqrt(p)-class congestion controls: Includes most existing TCP 
> congestion control algorithms, e.g., NewReno, CUBIC.
>
> - 1/p-class congestion controls: Includes DCTCP congestion control.
>
> Keep in mind that p is a probability that is usually << 1 when 
> expressed as a decimal, e.g., p=0.01 represents a 1% loss/marking rate.
>
"Scalable" is the term we've been using in the L4S documents for 1/p, 
defined in l4s-arch as:

    Scalable Congestion Control:  A congestion control where the packet
       flow rate per round trip (the window) is inversely proportional to
       the level (probability) of congestion signals.  Then, as flow rate
       scales, the number of congestion signals per round trip remains
       invariant, maintaining the same degree of control.  For instance,
       DCTCP averages 2 congestion signals per round-trip whatever the
       flow rate.