Re: Rechartering QUIC for Post Version 1 Work

[Christian Huitema <[e-mail]>]

On 1/29/2021 12:24 AM, Lars Eggert wrote:
> Hi,
>
> On 2021-1-29, at 2:03, Spencer Dawkins at IETF <[e-mail]> 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