On 1/29/2021 12:24 AM, Lars Eggert wrote:
Hi,
On 2021-1-29, at 2:03, Spencer Dawkins at IETF <[email protected]>
wrote:
I THINK I'm reading this as the QUIC working group requesting groups that
realize that their applications require QUIC extensions to consult with the
QUIC working group, and seek review. Is that the intention?
yes.
I'd expect that to be stronger, simply because (based on experiences with protocols like
SIP) popular protocols tend to collect applications from people who don't understand the
underlying protocol as well as the people who are responsible for the underlying
protocol. If you can say "but you can accomplish the same thing by using QUIC as it
is now", sooner rather than later, that would probably make everyone's lives simpler.
...
So, maybe that could say something like "are encouraged to consult with the QUIC WG
and obtain early review of proposals, thereby avoiding late surprises"?
I'm proposing a text change based on this suggestion in
https://github.com/quicwg/wg-materials/pull/192/files#r566650407
To Spencer's point, I shall observe that the extension mechanisms of
QUIC are in fact very powerful. Case in point, I just completed an
implementation of two multipath drafts in Picoquic, both keyed by the
negotiation of transport options. I also did study the "unreliable
deliveries" scenario, and it could certainly be deployed through the
parameter negotiation mechanism. The role of the IETF there is to
distinguish between experiments and standards.
Pretty much anyone with a keyboard and a github repo can fork one of the
open source implementations of QUIC and experiment with a new
functionality. The only downside is that if negotiation fails the
application has to live with the limitations of QUIC V1, such as single
path instead of multipath, or reliable delivery instead of immediate
delivery. To go from there to wide scale deployment, the supporters need
to convince enough other parties. Hence the need for some kind of standard.
There is an obvious role for the IETF there. In theory, going through
the standardization crucible will result in better extensions, avoid
replicating existing work, review security issues, etc. But I am worried
about time scales. The work on draft-liu-multipath-quic started in
October, and we see two implementations 4 months later, and we could see
coordinated deployments within a few more months. Compare that to the
median time of getting something done in an IETF WG, more than 3 years.
There are solid chances that by the time the WG concludes the industry
has already converged on a solution, redundancy with other standards be
damned.
That's what worries about the charter. How do we match the time scale of
standardization with the potentially high speed of defining them?
-- Christian Huitema
