Re: [tcpm] [tsvwg] L4S status tracking

[Bob Briscoe <[e-mail]>]

Rod,

On 06/11/2019 18:44, Rodney W. Grimes wrote:
> Bob,
> 	Reply inline with quoted text from draft as to "why" I,
> and probably others are having issues with Classic and your
> terminology.  All IMHO, of cource.
>
> Regards,
> Rod
>
>> Sebastien,
>>
>> On 06/11/2019 07:18, Sebastian Moeller wrote:
>>> Hi Bob,
>>>
>>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe <[e-mail]> wrote:
>>>> Michael, Rod,
>>>>
>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative
>>>> connotation than classic.
>>>           [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
>> Which is a good starting point, because that's what is intended. Plus it
>> already has a slightly positive natural meaning of "something robust
>> that has stood the test of time". Then it is defined precisely for the
>> context of each L4S doc, e.g.:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2
> Quoting the whole section inline: (WIth some markers added)
>
>     Classic service:  The 'Classic' service is intended for all the
>     ^A
>        behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
>        Compound, SCTP, etc).
>
>     Low-Latency, Low-Loss and Scalable (L4S) service:  The 'L4S' service
>        is intended for traffic from scalable congestion control
>        algorithms such as Data Center TCP.  But it is also more general--
>        it allows the set of congestion controls with similar scaling
>        properties to DCTCP to evolve (e.g.  Relentless TCP [Mathis09] and
>        the L4S variant of SCREAM for real-time media [RFC8298].
>
>        Both Classic and L4S services can cope with a proportion of
>             ^B
>        unresponsive or less-responsive traffic as well, as long as it
>        does not build a queue (e.g.  DNS, VoIP, game sync datagrams,
>        etc).
>
>     Classic ECN:  The original Explicit Congestion Notification (ECN)
>     ^A
>        protocol [RFC3168].
>
>
> Problem with these terminology definitions:
>
> Classic is used in the names of 2 terms, marked A above, and then
> used without any qualification in the definition of a third term,
> marked as B.  I believe the inference at B is that of "Classic Service".
[BB]
B isn't a third term. The term is 'Classic service' which was just 
defined earlier.

It's regular English that, "Both red and green services..." means "Both 
the red service and the green service..."

Nonetheless, this does make me realize that we need an extra sentence at 
the end of each definition to explain that other nouns can be qualified 
by 'L4S' or 'Classic'. E.g. queue, congestion control, codepoint, 
packet, flow.

> These terminology definintions are fuzzy, due to the use of words
> like "current".  Which current is that?  The date the draft was
> written, the date I am reading the draft?  This is a poor quality
> term definition.
[BB] (When 'currently' is used in an RFC or any text for that matter, 
I'm sure everyone always understands it to mean, "when this was written".)

However, you're right that 'currently' is actually incorrect here, 
because the definition needs to include any Reno-friendly behaviours 
introduced in future as well. Thx. All the L4S drafts use these 
definitions, so I'll remove 'currently' from them all.


> Since I can not put solid definitions of these terms in my mind
> when I read the draft I am always asking myself exactly what is
> "Classic" infering here?
>
> My head spins when I try to parse the above "term" "L4S service",
> and I can not build a solid model from the definition given.  It
> is self referential (L4S is L4S variant of SCREAM).  It has wording
> on what it can cope with.  For me this is not a definition of
> a term.
[BB] Good point. This is indeed not comprehensible without a definition 
of 'scalable congestion control', which we need to copy across from 
l4s-arch.

On "L4S variant of SCREAM", I don't believe it's self-referential, 'cos 
it's given in a list of examples, not as part of the definition. I had 
to call it that, because the variant doesn't have a name of its own.

However, this does make me realize that the use of SCTP as an example of 
a Classic behaviour is not right, because one could build a scalable 
congestion control into SCTP. In the list of examples of Classic 
behaviour I will change it to 'Reno-SCTP'.



>
>
> Now, having said that, let me at least try to resolve one of
> these terms.   There is actually no need to define "Classic ECN"
> as its above definitions is "RFC3168 ECN", exactly 2 words, or
> 11 characters  in length as well, thus the term is not needed
> and actually obfuscates the document.  I feel removeing all
> references to "CLassic ECN" and replacing them with "RFC3168 ECN"
> would make these drafts more understadable.
[BB] That's a possibility, and I use it sometimes. But many people use 
the term Classic ECN these days, probably because RFC3168 ECN requires 
the reader to remember yet another RFC number, which some people don't 
find easy. I'm not hearing a lot of resistance to the term 'Classic ECN'.

For instance, I find the names below are easier to read than the 
numbers, not just because they are shorter:
* 'RFC5681 congestion control' vs. 'Reno'.
* 'RFC8511 Cubic' vs. 'ABE-Cubic'?

Also, RFC3168 defined the response to ECN as equivalent to drop. So 
there is a useful (and deliberate) reinforcement of understanding in the 
association between Classic ECN and the Classic service (assuming we 
continue to use 'Classic' as the name for the service).

Thanks



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/