Re: Rechartering QUIC for Post Version 1 Work

Behcet Sarikaya <sarikaya2012@gmail.com> Mon, 01 February 2021 16:01 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF27B3A1286 for <quic@ietfa.amsl.com>; Mon, 1 Feb 2021 08:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZaAr9hjHud0 for <quic@ietfa.amsl.com>; Mon, 1 Feb 2021 08:01:26 -0800 (PST)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209B93A1280 for <quic@ietf.org>; Mon, 1 Feb 2021 08:01:26 -0800 (PST)
Received: by mail-yb1-xb2c.google.com with SMTP id j84so4140086ybg.1 for <quic@ietf.org>; Mon, 01 Feb 2021 08:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=8LVXZ9zYdz3At6qBBZIVXM69xorA/6Br+HXOuUUjcw8=; b=XOyjT/XPMzslFw3g3FDGucCO+9DSMfpNTXb8XptPhKOQJno6XSOlXqrzPztce6vCW+ 24etYJO8FlXvbtIWcyYFWHva3hDg6TSBX8pn/xQuanetnLpYIUmqK/W7xGLKsl+Pg6Ep M6CYFw4WxJ1JlZI5kU7rzXZD9+V3zdviIOigipPq7OGHUmFjVsLGy7owAFVr0OgKn4l6 LlT42N6/Q1smWUky59G9Zpghgr+y2DlsSrukzNdMxReRN3oAKPVdYqECif6wW4LrANQa lLcbmI/udJhB8t0tOnMvGHNhqxIF6x7rp7H5jUanUmdGnNxiKHTOnno3BSMUPWgrUH11 XDgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=8LVXZ9zYdz3At6qBBZIVXM69xorA/6Br+HXOuUUjcw8=; b=CRSsr1hrILkFXkV0dQ0lzctsbPe6JYt//PoXDDFmD4bDsvj80/tRBmEdcObFyLEge7 lLlQh9IZGlFqo0q/TK+iZDU/E5X5x5c85chPn/YMl3c3mPTzu87bmJ3MbnoHT622SwqG vyb5ej3feFDtG885imOaIRtcEoSIgNivoztC+1YAwxAeABau/uNnaaJN6TRx/YJK4F+9 +dDllbrRC5zcH9xZD0URUvHH/WP3Fe/m7YszFrcjwQHldSFMVVduzCJNTxVLDLUqkbnu 9JYeKTSrNW0qtZG8rAq16HnNNEYybHvgwSc2zDE4pYTDNHNFsK8Yn+IfB7W8SUYDJR5Z Z0gg==
X-Gm-Message-State: AOAM530jsxQ327h/b86/W7MoqbPEcmfGsD6OjqncBOq+nVOnkHAf+nMp YMqhYut6Bb/d38tTf7ef6MON9a3UkSZZYhNDY0s=
X-Google-Smtp-Source: ABdhPJwcd7w2ZIDKE0/21QXCDrsUS5pIXbPZ93LQ8bcnsITX+CKbzawGeXo53HN12evgtj5qItLazstb+fK6QIlzW3c=
X-Received: by 2002:a5b:111:: with SMTP id 17mr26119654ybx.324.1612195285162; Mon, 01 Feb 2021 08:01:25 -0800 (PST)
MIME-Version: 1.0
References: <CALGR9oaXpZp87ujmkDAO6Tuy=m-s8qKDY9-azpm_PhVAMfkq9A@mail.gmail.com> <20210126170048.GB364092@okhta> <D01160E4-C89E-4DF5-B0A7-C5138E33D9C1@eggert.org> <20210126170932.GC364092@okhta> <CALGR9oaO8Q7TC9zyajM20gZkZPR1cRDSv-SeDqo0MfaQbgfAjg@mail.gmail.com> <20210126184815.GD364092@okhta> <CAKcm_gNXkCko=H3VofwnubMDctCN7Smx0LDbH-ruYcTk7S4kTg@mail.gmail.com> <CAPDSy+4kVyrvmkd8vDOzASV36Y2iR2HEGzrSkxXJaMmED6JDww@mail.gmail.com> <CAC8QAcc8E3G2r9tzggRgz5t8ZxeqpFu4dwg4bmoLH39DnBHV-Q@mail.gmail.com> <9D6FDFBB-77E1-4AB9-84C2-376690A026DC@eggert.org> <3CDD98E2-92D6-4E5B-838D-CD56BE5BBA1E@fb.com> <CAKKJt-fiH4-Q-jufVimGxutPnfBZ8TbX2xnYTSckmh3Bbmmwrg@mail.gmail.com> <A5E4F422-91C5-4FA2-BA86-7F291172562F@eggert.org> <95cf6788-9130-e814-412c-75675c43f19f@huitema.net> <3fb2d9a81ca0f97ce3a341c86dc9b14552314bea.camel@ericsson.com>
In-Reply-To: <3fb2d9a81ca0f97ce3a341c86dc9b14552314bea.camel@ericsson.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Mon, 1 Feb 2021 10:01:13 -0600
Message-ID: <CAC8QAce8GCA3sugUd8m4eL4hi1sNWxSEigVf3JpLf=BGreyo5g@mail.gmail.com>
Subject: Re: Rechartering QUIC for Post Version 1 Work
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
Cc: "huitema@huitema.net" <huitema@huitema.net>, "lars@eggert.org" <lars@eggert.org>, "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "fenix=40fb.com@dmarc.ietf.org" <fenix=40fb.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000047de6d05ba4877f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OJ8frLVYykdzwaqVrYjzc-aUrhc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2021 16:01:29 -0000

+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=
40ericsson.com@dmarc.ietf.org> 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 <
> > > spencerdawkins.ietf@gmail.com> 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
> >
>