Draft: draft-ietf-mops-streaming-opcons

Commentary: From Please consider using the same wording for the title as for 6.2 and 6.1 ( nit ) Who is " we " in " We do have experience " ? While I share some concerns about deploying a new transport in user space as opposed to more stable and controlled kernel space , I wonder whether this paragraph is relevant in this document . Does it bring any value ? If no , then please remove it . 
 We 'll look at the date for CUBIC being enabled by default in the Linux kernel as " experience " . We 'll delete the paragraph as suggested . 
 was fixed elsewhere . 
 LGTM . I 'm almost sad to lose the ref to " Congestion Defense in Depth " , but I guess it makes good sense , that 's not a consensus position .
Paragraph (version A):
We do have experience with deploying new congestion controllers
without melting the Internet (CUBIC is one example), but the point
mentioned in tcp-behavior about TCP being implemented in operating
system kernels is also different with QUIC.  Although QUIC can be
implemented in operating system kernels, one of the design goals when
this work was chartered was "QUIC is expected to support rapid,
distributed development and testing of features", and to meet this
expectation, many implementers have chosen to implement QUIC in user
space, outside the operating system kernel, and to even distribute
QUIC libraries with their own applications.
Paragraph (version A):
The decision to deploy a new version of QUIC is relatively
uncontrolled, compared to other widely used transport protocols, and
this can include new transport behaviors that appear without much
notice except to the QUIC endpoints.  At IETF 105, Christian Huitema
and Brian Trammell presented a talk on "Congestion Defense in Depth"
CDiD, that explored potential concerns about new QUIC congestion
controllers being broadly deployed without the testing and
instrumentation that current major content providers routinely
include.  The sense of the room at IETF 105 was that the current
major content providers understood what is at stake when they deploy
new congestion controllers, but this presentation, and the related
discussion in TSVAREA minutes from IETF 105 (tsvarea-105, are still
worth a look for new and rapidly growing content providers.
Paragraph (version B):
The Internet community does have experience with deploying new
congestion controllers without melting the Internet.  As noted in
RFC8312, both the CUBIC congestion controller and its predecessor BIC
have significantly different behavior from Reno-style congestion
controllers such as TCP NewReno RFC6582, but both CUBIC and BIC were
added to the Linux kernel in order to allow experimentation and
analysis, and both were then selected as the default TCP congestion
controllers in Linux, and both were deployed globally.
Paragraph (version B):
The point mentioned in tcp-behavior about TCP congestion controllers
being implemented in operating system kernels is different with QUIC.
Although QUIC can be implemented in operating system kernels, one of
the design goals when this work was chartered was "QUIC is expected
to support rapid, distributed development and testing of features",
and to meet this expectation, many implementers have chosen to
implement QUIC in user space, outside the operating system kernel,
and to even distribute QUIC libraries with their own applications.
It is worth noting that streaming operators using HTTP/3, carried
over QUIC, can expect more frequent deployment of new congestion
controller behavior than has been the case with HTTP/1 and HTTP/2,
carried over TCP.