Re: Rechartering QUIC for Post Version 1 Work

[Behcet Sarikaya <[e-mail]>]

+1 to all points Magnus made.

I don't see anything that should be changed.

Huitema is saying that:

That's what worries about the charter. How do we match the time scale of
standardization with the potentially high speed of defining them?

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=
[e-mail]> wrote:

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