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

From: "Black, David" <[email-masked]>
Date: Wed, 13 Nov 2019 16:15:02 +0000

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.

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of Bob Briscoe
Sent: Wednesday, November 13, 2019 5:00 AM
To: Scharf, Michael; Wesley Eddy; Rodney W. Grimes
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] [tcpm] L4S status tracking

[EXTERNAL EMAIL]
Michael,

I see the problem. Nearly all the occurrences of 'Classic TCP' are in the appendix that was written v early on, when the focus was only TCP. That text was not written by me, and I haven't got round to editing it for consistency. However, there are 4 occurrences of "'Classic' TCP" in the abstract and intro, which I will also fix.

Can you say which "David's proposal" you mean please?

Bob
On 11/11/2019 23:10, Scharf, Michael wrote:
OK, so we seem to make some progress at least regarding the term 'classic' TCP. As mentioned before, I personally would find the term 'Classic' QUIC very confusing and you cannot avoid that if you talk about 'Classic' TCP, IMHO. So, it seems better to avoid that terminology for all transport protocols. For the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms 'classic' and 'TCP' back-to-back is used 11 times as far as I can see.

Regarding congestion control, I'd like to emphasize that David's proposal would also work well for me, i.e., characterizing the congestion control by functional properties. This avoids all issues regarding whether something will supersede something else (including the issue that EXP is just an experiment that won't update or replace any PS document).

Michael

From: Bob Briscoe <[email-masked]><mailto:[email-masked]>
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael <[email-masked]><mailto:[email-masked]>; Wesley Eddy <[email-masked]><mailto:[email-masked]>; Rodney W. Grimes <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,
On 07/11/2019 08:11, Scharf, Michael wrote:
... and just to show that _my_ concern would be trivial to address by small editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an incremental migration path so that normal TCP traffic classified in the 'Classic' service of L4S will be no worse off" would already work for me.  It just takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service class (and, e.g., "normal" sounds better to me), but in the context of a service class, "classic" could actually work for me, if TSVWG really wants that name with strong consensus. I don't care how about names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whatever else is done in the fast path of a router to implement low latency service.

I only object to specific terminology such as 'Classic' TCP or 'Classic' congestion control because I don't think that 'classic' is a proper characterization for TCPM standards or TCP/IP stack behavior not aligned with whatever L4S believes the bright future shall be.
I thought I had already agreed to remove 'TCP' from all instances of 'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' in the first place. Because it's the congestion controls that are relevant in L4S drafts, not the protocols.

Bob

Whether such small rewording address fully the concerns from others may be a different question.

Michael

From: Wesley Eddy <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael <[email-masked]><mailto:[email-masked]>; Bob Briscoe <[email-masked]><mailto:[email-masked]>; Rodney W. Grimes <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with the term "Classic" for TCP and TCPM-specified congestion control when more than 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all context of TCP and congestion control (as far as it is owned by TCPM), including the reference above. BTW, "normal" as suggested would also work for me. So, you have plenty of options for other terms.

If Dave+Michael's suggestion of replacing "classic" with "normal" is agreable to others, this seems like a good way forward to me.  It should be easy enough to explain in other SDOs that classic and normal mean the same thing, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negative connotations to it.  However, for the sake of working group progress, I think we just need to pick something that seems the least terrible and agree to move on.)

--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/

--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 13 Nov 2019 19:05:19 +0200

> On 13 Nov, 2019, at 6:15 pm, Black, David <[email-masked]> wrote:
> 
> 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:

Specifically CE marking or loss.  SCE marking can orthogonally elicit a DCTCP-style 1/p-class or an SCE-specific 1/(p*sqrt(p)) class of response, overlaid on the normal 1/sqrt(p) response to CE.

To give these a more intuitively recognisable face, may I suggest:

- "MD" for Multiplicative Decrease, for the traditional 1/sqrt(p)-class TCP response.

- "DCTCP" for the 1/p-class response introduced by that scheme.

- "ELR" for Explicit Load Regulation, for SCE's preferred 1/(p*sqrt(p))-class response.

ELR was an early name considered for SCE, using a control element commonly found in diesel locomotives (known as a Load Regulator) as inspiration.  This generally has a slow adjustment mode for small disturbances from steady state, and a fast adjustment mode for larger disturbances.  The MD response corresponds to the fast adjustment mode, and the ELR response with the traditional linear cwnd growth correspond to the slow adjustment mode.  Since SCE refers specifically to the signalling method, we can use ELR to avoid confusion when referring to the response function.

Incidentally, another way of writing the above formulae is as an exponent to p:

- p^-0.5 is 1/sqrt(p)

- p^-1 is 1/p

- p^-1.5 is 1/(p*sqrt(p))

The above may also be more readable, if not as familiar to non-mathematicians.

 - Jonathan Morton

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 13 Nov 2019 12:43:52 -0500

On 11/13/2019 11:15 AM, Black, David wrote:
> 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.
>
> 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.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 13 Nov 2019 10:07:34 -0800 (PST)

> > We are dealing with two classes of congestion controls. ?For lack of 
> > protocol throughput is proportional to where ?p? is the loss and/or 
>  ?? 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                                                 [email-masked]

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 13 Nov 2019 20:19:10 +0200

> On 13 Nov, 2019, at 7:43 pm, Wesley Eddy <[email-masked]> wrote:
> 
> "Scalable" is the term we've been using in the L4S documents for 1/p, defined in l4s-arch as:
> 
>       the level (probability) of congestion signals.

Unfortunately, the term "scalable" sounds like a marketing term to me.  I would prefer to support terms with some obvious technical basis.  In my experience, DCTCP is closely associated with this response function, and is often used as shorthand for it.

 - Jonathan Morton

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 13 Nov 2019 20:31:37 +0000

> -----Original Message-----
> From: Jonathan Morton <[email-masked]>
> Sent: Wednesday, November 13, 2019 7:19 PM
> To: Wesley Eddy <[email-masked]>
> Cc: Black, David <[email-masked]>; Bob Briscoe <[email-masked]>;
> Scharf, Michael <[email-masked]>; Rodney W. Grimes
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S
> status tracking)
> 
> Unfortunately, the term "scalable" sounds like a marketing term to me.  I would
> prefer to support terms with some obvious technical basis.  In my experience,
> DCTCP is closely associated with this response function, and is often used as
> shorthand for it.

At least the wording "'less unscalable' Cubic" in draft-ietf-tsvwg-ecn-l4s-id-08 is a marketing term to me. Unscalable has a negative connotation to me (as non-native speaker).

If "scalable" shall be used, IMHO a similar term with positive connotation has to be used for 1/sqrt(p) congestion control. An example would be 'high-speed congestion control' for CUBIC. That term is IMHO relatively well established in the IETF. But I am not sure if we should really go down that road.

The benefit of using terms with a technical or mathematical foundation is that we don't have to argue whether 'scalable' outperforms 'high-speed'. And I believe avoiding such controversy could help with finishing this discussion.

My 2 cents

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Nov 2019 23:49:43 +0000

David, Wes,

On 13/11/2019 17:43, Wesley Eddy wrote:
>> 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) only describes the worst case that the coupled dualq AQM is 
designed to allow for. It includes cubic in it's reno-friendly regime, 
as well as beyond that. It includes compound and a whole host of 
slightly more aggressive congestion control variants than Reno, as well 
as ABE variants of each. It includes the proprietary congestion 
controllers used in Skype, Hangouts, Facetime, Zoom, Whereby, etc. It 
includes rmcat congestion controllers.

So I wouldn't want to use a name that implied everything in this class 
obeyed (or had to obey) a 1/sqrt law.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Nov 2019 23:58:18 +0000

David, Wes, [sry, I omitted to include the 'Bob adds:' para below]

[Bob adds:] Here's a link to plots of the congestion response functions 
for a selection of congestion controllers that I prepared years ago. 
They are all what has been defined as Classic, except DCTCP and Scalable 
TCP (which is not just a scalable TCP, but the protocol that calls 
itself Scalable TCP):
     http://bobbriscoe.net/projects/latency/responseFns.pdf
Recovery time is the average time the congestion control takes to induce 
one loss after its responded to a previous one. You can see it's 
invariant for the scalable controllers.

Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/