Subject: Re: Rechartering QUIC for Post Version 1 Work

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 Feb 2021 08:39:49 +0000

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 <
> > [email-masked]> 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
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 1 Feb 2021 10:58:45 -0500

Maybe I am not reading this properly but the 1st area includes:

  Maintenance and evolution of the specifications
  of QUIC extensions.

and the 3rd includes:

  The third area of work is the specification of
  new extensions to QUIC.

Is the 1st about the extensions that we know about now and the 3rd is about ones we don’t know about yet?

spt

> On Jan 28, 2021, at 08:08, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 
> I've prepared https://github.com/quicwg/wg-materials/pull/192 in an attempt to address the comments received on the charter update.
> 
> - remove "if necessary" to make it more clear that the WG may do a new version of QUIC
> 
> - talk more generally about "a logging format" and tweak the wording for the second work area, to make it more clear that the listed things are non-exclusive examples of work items
> 
> - take David Schinazi's advice and remove the text about standards track
> 
> Please let me know if this is clearer, and should be merged into the text for the continuation of the discussion.
> 
> Thanks,
> Lars

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Feb 2021 10:01:13 -0600

+1 to all points Magnus made.

I don't see anything that should be changed.

Huitema is saying that:

If the above refers to multipath quic, remember that we had a
mpquic proposal already longtime ago. Also TCP had mptcp solution.
So out of all that expertise build up, it is not surprising people keep
coming up newer solutions.

Behcet

On Mon, Feb 1, 2021 at 2:40 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> 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.
>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 1 Feb 2021 18:45:56 +0200

Hi,

> Is the 1st about the extensions that we know about now and the 3rd is about ones we don’t know about yet?

that was the thinking. Do you think it makes more sense to merge the extensions stuff into one area?

Thanks,
Lars

---

From: Sean Turner <[email-masked]>
Date: Wed, 3 Feb 2021 11:39:51 -0500

> On Feb 1, 2021, at 11:45, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 

Not sure you need to combine them because the WG should maintain it’s work product, but maybe do this in the first bullet?

Maintenance and evolution of the existing WG-specified QUIC extensions.

spt

---

From: Lars Eggert <[email-masked]>
Date: Thu, 4 Feb 2021 16:48:04 +0200

Hi,

> Maintenance and evolution of the existing WG-specified QUIC extensions.

thanks for the suggestion. A slight rephrasing of this is now in https://github.com/quicwg/wg-materials/pull/196

Thanks,
Lars