search

ietf-wg-tsvwg / tsvwg

1 stars 0 forks source link

Terminology improvements #27

Open ietf-svn-bot opened 4 years ago

ietf-svn-bot commented 4 years ago

owner:draft-ietf-tsvwg-l4s-arch@ietf.org type_defect | by wes@mti-systems.com

Use of terms "traditional", "classic", and "legacy" should be carefully checked.

See Michael Scharf's comment: https://mailarchive.ietf.org/arch/msg/tsvwg/8_gdxerN-99oou9ILas5OKl8viU

Issue migrated from trac:27 at 2022-01-31 12:36:01 +0000

ietf-svn-bot commented 4 years ago

@jholland@akamai.com commented

Also perhaps worth noting was a comment about reducing "hype" in the text, giving examples from the abstract:

ietf-svn-bot commented 4 years ago

@g.white@cablelabs.com commented

In response to Michael Scharf's comment, there was quite a bit of discussion on the mailing list, and no clear consensus to remove the word "classic". As a compromise, it was proposed to eliminate the usage of the term "classic TCP", but to continue to use "classic congestion control", defined to mean 'Reno-friendly'. These changes were made in the Feb 2020 updates of the drafts.

The term "traditional" appears to be used appropriately in the current drafts ("DCTCP uses the traditional TCP Reno additive increase" and "Traditionally ultra-low latency has only been available for a few selected low rate applications").

The term "legacy" is used once in DualQ to refer to senders that are not compliant with RFC8311. It is used 5 times in L4s-Arch. These instances probably need a final scrub.

The drafts were also revised in Feb & March 2020 in an attempt to eliminate hype.

It would be good to get feedback from WG participants on the status of this issue. Can this be closed, or is there still concern about the terminology?

ietf-svn-bot commented 4 years ago

@g.white@cablelabs.com changed _comment0 which not transferred by tractive