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

["Rodney W. Grimes" <[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.

Does reading this definition make anyone elses head hurt?

Flow rate per round trip?
How can one have a rate that is per round trip?
Can someone give me a dimensional analysis and tell me what the units are here?  bits per second per second is what I come up with.

Now "(the window)" is almost getting me there, perhaps "(the window size)"?

For me flow rate is not the right terminology here.

Furthermore, "the number of congestion signals per round trip remains invariant" is that really whats happening here?
For me that says it is a fixed value of some N, for DCTCP that N is 2, but for L4S, and SCE it is not invariant,
it is variant based on the number of packets in flight (the invariant *might* be the ratio or proportion of congestion signals (marks)
to packets, but even that is variant as the marking rate depends on the level of congestion.)

-- 
Rod Grimes                                                 [e-mail]