Re: [tcpm] [tsvwg] L4S status tracking

Michael,

Previously, I have been told not to use the term standard for RFCs that 
are not standards. RFC5681 is 'only' a draft standard. This is why, in 
the IETF at least, I avoid using the term "standard TCP congestion 
control". I generally call it Reno when referring to the congestion control.

I have never, to my knowledge, used the term classic TCP, or classic TCP 
congestion control.

And I rarely use the term legacy, and if I do I'm happy to have 
alternatives suggested.

I've checked the L4S drafts, and there is one phrase that I shall leave 
in ecn-l4s-id: "the traditional TCP Reno additive increase", because 
this is correctly used to mean the traditional increase (in numerous 
AIMD CCs), not traditional TCP. There was one other occurrence of 
"traditional TCP senders" in a whole para in an appendix that has just 
been deleted anyway. And in aqm-dualq-coupled there was one "legacy TCP 
flows" (changed to "Classic traffic" now in my local copy, using the 
defined term in all the L4S drafts).

l4s-arch is getting a complete make-over for terminology, so I will 
check that next.

inline...

On 23/08/2019 15:01, Scharf, Michael wrote:
>
> Hi Wes,
>
> I’d like to add a smaller item that is mostly editorial and can 
> hopefully be sorted just out by re-wording, albeit it may require a 
> careful analysis of all documents.
>
> As already noted in 
> https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY 
> <https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> 
> , I object to the terms „traditional TCP“ and also „classic TCP“ or 
> „legacy“ TCP when referring to a TCP implementation according to IETF 
> standards-track RFCs.
>
> To me as a non-native native speaker, all these terms have a negative 
> connotation. I also think this language is typical to marketing material.
>
You're entitled to your opinion but, as a native speaker, I don't think 
'classic' or 'traditional' are particularly pejorative, tho they can be 
when used in a context that intends them to be. They also mean "stood 
the test of time". I find 'legacy' has a connotation of marketing-speak, 
but it's not that bad.

This is an enduring problem when trying to improve on the good work that 
other people have done before you (which is the context of everything we 
are doing). We need a word that distinguishes the old from the new, but 
we don't want to completely trash the thing that has already been 
successful, but had its day.

Nonetheless, it is also important not to be too precious about past 
work. We all recognize that Reno TCP is unscalable and has problems. 
IMO, it is OK to describe technologies that have had their time with 
negative connotations. Indeed, you have been an author (with me) of an 
RFC on open issues in congestion control.

I notice you haven't suggested an alternative term for "the thing(s) we 
are trying to improve on". Not surprising, because it's difficult.

When we (the L4S developers) were first looking for a term for the 
non-L4S queue and the non-L4S service, we didn't want to use 'legacy' 
for the above reasons, but we did want to imply pre-existing, so we 
decided on 'classic', which we all felt had a generally neutral 
connotation, but said what we meant.

Finally, I do not want this issue to take up any time that would detract 
from technical issues.

Bob

> My prefered term when referring to TCP according to standards-track 
> specification is „standard TCP“. I would also be fine with other terms 
> as long as they are neutral and make clear that experiments do not 
> replace, deprecate, or outperform standards.
>
> Similarly, I think that term such as „classic“ is not appropriate for 
> the TCP standard congestion control („Reno“). As of today, this is the 
> TCP congestion control algorithm on standards track that has IETF 
> consensus. The term in the TCPM charter is „TCP standard congestion 
> control“. I also think that terms such as „Reno-compatible“ or the 
> like would be neutral.
>
> Note that I do not object to the terms „classic ECN“, „legacy ECN“, 
> „legacy AQM“ or the like, i.e., if the context is ECN and not 
> specifically TCP or the TCP congestion control. I believe it is up to 
> the TSVWG do decide if this term shall be used for compliance to RFC 
> 3168. I have no strong opinion on that. As far as I can see, most use 
> of the term „classic“ is in this context and I don’t ask for changes 
> in those cases.
>
> Some use of the term „Classic Service“ may also require careful review 
> to clearly separate it from TCP Standard behavior.
>
> Note that some use of the term „Classic TCP“ would probably also apply 
> to „Classic QUIC“ once the QUIC standard is finished. To me as a 
> non-native speaker, it would be really strange to use the term 
> „classic“ in the context of a brand-new transport protocol. IMHO in 
> that case the term „classic“ would be even more confusing.
>
> I also add the TCPM list in CC to ensure consistency.
>
> Thanks
>
> Michael (with no hat)
>
> *Von: *Wesley Eddy <mailto:wes@mti-systems.com>
> *Gesendet: *Sonntag, 11. August 2019 07:08
> *An: *tsvwg@ietf.org <mailto:tsvwg@ietf.org>
> *Betreff: *[tsvwg] L4S status tracking
>
> I created tickets in the TSVWG "trac" tool in order to help keep track
> of the individual things that look like they should be addressed in
> progressing L4S document set:
>
> https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1
>
> I'll try to update these based on the ongoing discussions, updates,
> etc., but it will make it very easy if you happen to mention the ticket
> numbers or some key words in threads and messages, when significant.
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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