Re: Rechartering QUIC for Post Version 1 Work

[Magnus Westerlund <[e-mail]>]

Hi Christian,

Regarding timeliness of work. I think in certain cases it will be almost
impossible for a standard to be timely for a need that exist directly and
involve a small number of players that can agree on either the functionality or
using a specific implemetnation. 

Having said this I think this charter on high level allow the QUIC WG to be as
flexible as possible to meet a demand for a functionality that is near term.
First of all the WG do not require rechartering to take on extensions indpendent
if they are standards track or experimental ones. Secondly, if something is
mature enough to at least consider it a reasonable working point by the WG then
I think publication can be fairly fast. An extension to an existing protocol
that only attempts to address a single thing usually go through the whole IETF
review and IESG evaluation fairly quickly. However, getting a document through
IETF process under a year is very fast, and below half a year is very unsual as
you know. 

My record for idea to publication is https://datatracker.ietf.org/doc/rfc4735/
which took 6 months. And it was actually approved after 3 months. But to be this fast the content must be very straightforward. 

But, I think a lot here are actually dependent on the WG's attitude. If the WG
is willing to publish quickly ideas that is sufficiently baked, and then do
later updates or repaclements to refine things when the experience has been
gained a lot can be done quickly. And here is where I think experimental can
actually help in many cases as it also signal to the rest of the IETF that this
is a snapshot of our current thinking, that may evolve as we use it more. 

However, I still think that complex proposals, like multipath is going to take
time because people have different ideas, there are multiple interlocking
mechanisms and likely new security aspects that needs careful considerations. 

Cheers

Magnus




On Fri, 2021-01-29 at 09:50 -0800, Christian Huitema wrote:
> 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://protect2.fireeye.com/v1/url?k=b7f3906d-e868a92e-b7f3d0f6-861fcb972bfc-8df3629d1fb67509&q=1&e=27c4d204-68b3-48b2-a1dc-d936a4f1f734&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fwg-materials%2Fpull%2F192%2Ffiles%23r566650407
> 
> 
> 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
>