Subject: Rechartering QUIC for Post Version 1 Work

From: Lucas Pardue <[email-masked]>
Date: Tue, 26 Jan 2021 16:45:23 +0000

Hello,

As you will be aware, the base-draft documents comprising QUIC version 1
are making steady progress through the IESG review process. Building from
that, we expect the Applicability and Manageability drafts to be stable and
fresh, and ready for WG last call soon. Furthermore, we also expect some
effort to get directed towards the three adopted extensions: Load
Balancers, Version Negotiation, and Datagram.

With the WG nearing the delivery of its first major milestones, we're in a
bit of a natural transition period. Now is a good time to look again at the
WG charter and consider where else we might choose to direct focus. We
anticipate QUIC version 1 to generate interest, deployment experience, and
new ideas for extensions. The Chairs and responsible AD would like to
position the QUIC WG as the focal point for any QUIC-related work in the
IETF, especially with respect to protocol maintenance and evolution. We
believe a recharter will make it clear what is in scope for the WG to work
on next. Being a focal point, however, does not mean that *all*
QUIC-related work should be done in this WG. For example, new application
protocol mappings can likely be successfully done in the appropriate ART WG
with little interaction required.

As you may have noticed, draft-iyengar-quic-delayed-ack,
draft-marx-qlog-event-definitions-quic-h3, and
draft-thomson-quic-bit-grease have,  based on interest to date, been marked
as candidates for adoption by the WG. However, our current charter prevents
us from formally adopting such work. The intention of the new charter is,
among other things, to allow the WG to formally adopt and develop these
drafts.

The Chairs have worked with the responsible AD and current document editors
to prepare a new draft charter for the QUIC WG post version 1. We invite
the WG to review this charter at
https://github.com/quicwg/wg-materials/blob/recharter/charter/charter.md
and file issues or suggestions on GitHub. For convenience, the text as of
commit 9471611 is reflected below:

QUIC Working Group Charter

The QUIC WG originated the specifications describing version 1 of QUIC, a
UDP-based, stream-multiplexing, encrypted transport protocol.

The WG acts as the focal point for any QUIC-related work in the IETF. It is
chartered to pursue work in the areas detailed below.

The first area of work is maintenance and evolution of the existing QUIC
specifications:

   -

   Maintenance and evolution of the QUIC base specifications that describe
   its invariants, core transport mechanisms, security and privacy, loss
   detection and recovery, congestion control, version and extension
   negotiation, etc. This includes the specification of new versions of QUIC,
   if necessary.
   -

   Maintenance and evolution of the specifications of QUIC extensions.

Maintenance and evolution work needs to be strongly motivated by existing
or ongoing production deployments of QUIC at scale, and needs to carefully
consider its impact on the diverse set of applications that have adopted
QUIC as a transport.

The second area of work is supporting the deployability of QUIC, which
includes specifications and documents, such as it applicability and
manageability statements, improved operation with load balancers, the
specification of a logging format and schemas for QUIC and HTTP/3 endpoints
(qlog), etc.

The third area of work is the specification of new extensions to QUIC.
Extensions intended for Standards Track need to have general applicability
to multiple application protocols. The WG may also decide to publish
extensions as Informational or Experimental documents, e.g., to allow
vendors to publicly document deployed proprietary extensions or to enable
wider experimentation with new protocol features.

Specifications describing how new or existing application protocols use the
QUIC transport layer do not need to be specified in the QUIC WG. The QUIC
WG will collaborate with other groups that define such application
protocols that intend to use QUIC. New mappings might require QUIC
extensions and it may be efficient to define these alongside the mapping
specifications. Groups that define application protocols using QUIC, or
extensions to QUIC in support of those protocols, are requested to consult
with the QUIC WG and seek review of proposals. This is intended to reduce
the possibility of duplicate work and/or conflicts with other extensions.

The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the QPACK
header compression scheme. These specifications are now maintained in the
HTTP WG.

Defining new congestion control schemes is explicitly out of scope for the
WG. However, new QUIC extensions that support development and
experimentation with new congestion control schemes may fall under the
third work area.
Cheers,
Lars, Lucas and Matt
QUIC WG Chairs

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 26 Jan 2021 12:00:48 -0500

> among other things, to allow the WG to formally adopt and develop these

--- 8< --- snip --- 8< ---

> specification of a logging format and schemas for QUIC and HTTP/3 endpoints

It would make the charter broader if the particular work areas were not
itemized here.  This way, a future work item, such as the (or "a") loss
bits extension (which obviosly addresses deployability concerns), cannot
be shut down with: "it is not in the second area items list and thus the
WG is not chartered to work on it."

  - Dmitri.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Jan 2021 19:03:57 +0200

Hi,

> WG is not chartered to work on it."

that list is prefaced with "such as", which intends to express that those are non-exclusive examples. Do you have a suggestion how to make that clearer?

Thanks,
Lars

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 26 Jan 2021 12:09:32 -0500

On Tue, Jan 26, 2021 at 07:03:57PM +0200, Lars Eggert wrote:
> that list is prefaced with "such as", which intends to express that
> those are non-exclusive examples. Do you have a suggestion how to make
> that clearer?

I would dispense with examples and use precedent.  That is, the second
work area is listed simply as "QUIC deployability" in the charter.  Then,
the WG picks up (say) the load balancer draft based on the applicability
of the "deployability" rule.  This establishes precedent what types of
work items the deployability work area covers.  The precedent is used in
the future to figure out which new work items are applicable and which
are not.

  - Dmitri.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 26 Jan 2021 17:27:11 +0000

Hi Dmitri,

> the future to figure out which new work items are applicable and which

my 2c as an individual:

The Applicability, Manageability and Load Balancer documents are all
already adopted by the QUIC WG, under current or previous charters. They
address the work area of deployability. Arguably, they help *use* the QUIC
protocol rather than extend or modify it. A loss bits specification
possibly requires extension of the QUIC protocol, with the intent to
improve manageability. Such work is likely to span the extension and
deployability work areas.

Waiting for the new documents to get proposed and adopted, as a new
precedent for future work in this area doesn't IMO help much. We already
have precedents, which I trust the WG to be capable of applying without
being too literal.

Cheers,
Lucas

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 26 Jan 2021 13:48:15 -0500

OK, hopefully that's how it works out in the end.

Thanks,

  - Dmitri.

---

From: Ian Swett <[email-masked]>
Date: Tue, 26 Jan 2021 16:00:18 -0500

In the past, I felt there was quite a bit of resistance to accepting new
documents not explicitly listed in the charter, which makes me share some
of Dmitri's concerns.

Mentioning qlog specifically made me a bit nervous, because the other
examples were worded broadly enough that they could encompass different
drafts if needed.

Minus that concern, LGTM.

---

From: David Schinazi <[email-masked]>
Date: Tue, 26 Jan 2021 13:53:10 -0800

I'm supportive of the overall direction of this rechartering, with some
concerns though:

1) multipath is not mentioned in this charter - based on the conversations
we've had over the past months, I think we should be explicit about whether
multipath is in or out of scope

2) +1 to Ian and Dmitri's comments about mentioning current examples in a
way that seems to preclude other extensions, we could remove the examples
to help clarify

3) I was surprised by "Extensions intended for Standards Track need to have
general applicability to multiple application protocols." and I don't think
our charter should preclude these. We shouldn't ban standard-track
protocols that require a QUIC extension to function properly. Perhaps
another way we could phrase this would be to say that "The QUIC WG is only
chartered to work on extensions that have general applicability to multiple
application protocols. Extensions that are specific to an application
protocol should be defined in the WG responsible for that protocol, in
consultation with the QUIC WG." -- without stating anything about Standards
track.

4) It seems off to me to simultaneously declare HTTP/3 logging in-scope and
HTTP/3 out-of-scope. I think qlog is useful, but if we want to use it
outside of the QUIC transport protocol then maybe it should live in another
WG.

5) "Maintenance and evolution of the QUIC base specifications" isn't very
clear to me - does that mean that working on future versions of QUIC is in
or out of scope?

David

On Tue, Jan 26, 2021 at 1:00 PM Ian Swett <ianswett=
[email-masked]> wrote:

> On Tue, Jan 26, 2021 at 1:48 PM Dmitri Tikhonov <
> [email-masked]> wrote:
>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 Jan 2021 00:56:19 +0000

Hi David,

Thanks for the feedback. I've responded in-line, and some of that text
responds to points Ian raised too.

> multipath is in or out of scope

The intention was that the new charter would allow the group, as the focal
point for QUIC-related things, to consider work such as multipath QUIC. The
guidance for discussion of multipath is still the same as Lars' sent to the
WG in November [1]. To borrow a bit of that, we still feel it premature to
adopt an proposal as a work item.

There's an interesting contrast between this point and your second point.
It seems there's a balance between being specific and appearing not open to
new ideas.

> way that seems to preclude other extensions, we could remove the examples

(previously I commented as an individual, but now with a chair hat on) If 3
people have the same comment, it's likely a sign that some polishing up of
the text would help. Specific suggestions always appreciated.

> 3) I was surprised by "Extensions intended for Standards Track need to
> have general applicability to multiple application protocols." and I don't
> think our charter should preclude these. We shouldn't ban standard-track

I'd like Lars or Magnus to respond to this point too. IIUC the intention of
the text is to say that QUIC transport extensions that wish to be adopted
by this group under Standards Track, should apply broadly. An extension
designed for only one specific use, and which the authors do not wish to
spend time considering design changes that would permit more-general usage,
isn't a great use of the WGs time trying to standardise. However, the QUIC
WG is a good venue to catalog such work as Informational or Experimental. I
don't believe we want to prevent QUIC extensions that are specific to a use
from being developed as Standards Track elsewhere in the IETF.

> 4) It seems off to me to simultaneously declare HTTP/3 logging in-scope
> and HTTP/3 out-of-scope. I think qlog is useful, but if we want to use it

That's one (fair) interpretation. The intent here is to make it clear that
the QUIC WG no longer owns the HTTP/3 application mapping, as always
intended. qlog doesn't change protocols so working on that falls into the
deployment working area. I expect a large part of the QUIC WG population,
to start with, will be made up of deployers of HTTP/3. So while there has
been some discussion on the most suitable home for qlog and splitting the
drafts up [2], keeping them developed in a single WG would seem like the
best way to channel effort and attention of active deployers. If others
have a strong sense that is not the case they should speak up.

> clear to me - does that mean that working on future versions of QUIC is in

The full paragraph states:

" Maintenance and evolution of the QUIC base specifications that describe
its invariants, core transport mechanisms, security and privacy, loss
detection and recovery, congestion control, version and extension
negotiation, etc. This includes the specification of new versions of QUIC,
if necessary."

I think that's clear but if you have some suggestions to improve it we'll
take a look.

Cheers,
Lucas

[1] -
https://mailarchive.ietf.org/arch/msg/quic/rcPf7u9AHIGwNr6j0ZqrqFujVvk/
[2] -
https://mailarchive.ietf.org/arch/msg/quic/yv9FFyXItsKK6m-5I5eRE6jnqR8/

---

From: David Schinazi <[email-masked]>
Date: Tue, 26 Jan 2021 17:21:05 -0800

Thanks for your reply, Lucas. Responses inline.

On Tue, Jan 26, 2021 at 4:56 PM Lucas Pardue <[email-masked]>
wrote:

>> 1) multipath is not mentioned in this charter - based on the
>> conversations we've had over the past months, I think we should be explicit
>> about whether multipath is in or out of scope
>>
>

I see your point, I'm OK with not precluding multipath as long as the
guidance from November still holds. But then again, a recharter could be
seen as invalidating prior charter-related decisions so being explicit
could be useful here.

>From my perspective, multipath was important enough of a topic to warrant
its own interim a few months back which isn't true of any of our extensions
- so I guess that's where I'd draw the line in terms of mentioning
something or not?

> (previously I commented as an individual, but now with a chair hat on) If
> 3 people have the same comment, it's likely a sign that some polishing up
> of the text would help. Specific suggestions always appreciated.
>

I liked Dmitri's proposal to remove the examples. If we want to include
examples that are in scope, I'd suggest also including examples of what's
not in scope to make it clear that neither list is exhaustive.

> I'd like Lars or Magnus to respond to this point too. IIUC the intention
> of the text is to say that QUIC transport extensions that wish to be
> adopted by this group under Standards Track, should apply broadly. An
> extension designed for only one specific use, and which the authors do not
> wish to spend time considering design changes that would permit
> more-general usage, isn't a great use of the WGs time trying to
> standardise. However, the QUIC WG is a good venue to catalog such work as
> Informational or Experimental. I don't believe we want to prevent QUIC
> extensions that are specific to a use from being developed as Standards
> Track elsewhere in the IETF.
>

I love bikeshedding document tracks as much as the next person, but I don't
think that needs to be litigated in the charter - the charter should help
us decide what we allocate WG time for - if an extension is not seen as
valuable by the WG, I don't think it's worth it to spend WG time to publish
it as experimental or informational. Either we care about the extension or
we don't, right?

> have a strong sense that is not the case they should speak up.

Members of the QUIC implementers community have been attending other
QUIC-adjacent working groups, so I don't think placing them in QUIC will
impact implementation energy. I'd even argue that placing these in QUIC
might constrain them to QUIC instead of also encouraging other protocols.
If someone were to write a draft about how to use qlog with SCTP, would it
belong in the QUIC WG?

> I think that's clear but if you have some suggestions to improve it we'll

Nope, that is very clear - I must have missed it which is my fault.
Apologies.

But now I'm realizing that the "if necessary" in that last sentence might
be interpreted differently by various folks when we start wondering what
features should go into QUIC v2. I'd suggest just removing the "if
necessary".

David

Cheers,

---

From: Matt Joras <[email-masked]>
Date: Tue, 26 Jan 2021 18:08:03 -0800

Hi all,

Some responses inline about the example listing, extension tracks,
multipath, and qlog.

On Tue, Jan 26, 2021 at 5:21 PM David Schinazi <[email-masked]>
wrote:

>> The intention was that the new charter would allow the group, as the
>> focal point for QUIC-related things, to consider work such as multipath
>> QUIC. The guidance for discussion of multipath is still the same as Lars'
>> sent to the WG in November [1]. To borrow a bit of that, we still feel it
>> premature to adopt an proposal as a work item.
>>
>

In my view codifying any particular position on multipath in the charter is
problematic (as we've experienced with the existing charter) and could be
seen as a firm commitment to adopting those work items immediately along
with the rechartering. The proposed text gives us the flexibility to adopt
and prioritize multipath work as we see fit without implying that it is
immediately necessary.

> not in scope to make it clear that neither list is exhaustive.

I'm not sure that listing more examples is going to age particularly well
or aid in making it clear what types of work the WG should or should not be
taking up. If you read the language of the proposed charter and compare it
to the current one you'll note that the proposed text isn't as strongly
implying that the WG will take up any particular work. That being said, I
agree that since 3 people have had the same interpretation we should
probably do something about this section, possibly removing the examples
entirely.

> I love bikeshedding document tracks as much as the next person, but I
> don't think that needs to be litigated in the charter - the charter should
> help us decide what we allocate WG time for - if an extension is not seen
> as valuable by the WG, I don't think it's worth it to spend WG time to
> publish it as experimental or informational. Either we care about the
> extension or we don't, right?
>

I believe the vision for this charter, as Lucas has mentioned as well, is
for the QUIC WG to be the focal point at the IETF for QUIC work. QUIC work
does not have to be standards-track in order for it to have value or
relevance (i.e. for us to "care" about it). If we do not make allowances
for this kind of work in the charter we would be denying them a venue at
the IETF at all, which seems a waste. I tend to agree with the notion that
we shouldn't adopt standards-track extensions until there is indication
they have wide applicability, but we can certainly give them some WG time.
This allows for cataloging and incubation in a single working group which
could always lead to drafts eventually being adopted as standards-track
work, given appropriate interest.

>> That's one (fair) interpretation. The intent here is to make it clear
>> that the QUIC WG no longer owns the HTTP/3 application mapping, as always

Qlog is presently being developed primarily by QUIC implementers with an
interest in exposing QUIC-specific events and also events for the existing
application mapping (HTTP/3). The interest is primarily driven by aiding in
the operation of QUIC applications in real deployments. As such I think it
makes the most sense for it to be a WG item in the same way that the
applicability and manageability drafts are WG items. That said, as qlog
matures and if it garners interest outside of QUIC (e.g. HTTP/2 or WebRTC
or some other protocol wants to start using it) then it may warrant its own
WG or having qlog work for those drafts move into their working groups. The
organization of such work is not really relevant right now though, as
there's a lot of work to be done on qlog before we need to worry about how
it fits in the broader IETF ecosystem. Interested parties like Robin will
work in parallel to gauge interest across the IETF, and in the meantime we
can get to work on the existing drafts.

>> " Maintenance and evolution of the QUIC base specifications that
>> describe its invariants, core transport mechanisms, security and privacy,
>> loss detection and recovery, congestion control, version and extension
Matt Joras

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Jan 2021 08:36:06 +0000

Another interesting one..

If did partially-reliable HTTP (which would absolutely require QUIC stuff), where would that live?
-=R

From: QUIC <[email-masked]> on behalf of David Schinazi <[email-masked]>
Date: Tuesday, January 26, 2021 at 5:21 PM
To: Lucas Pardue <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Rechartering QUIC for Post Version 1 Work

On Tue, Jan 26, 2021 at 4:56 PM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

Thanks for the feedback. I've responded in-line, and some of that text responds to points Ian raised too.

On Tue, Jan 26, 2021 at 9:54 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
I'm supportive of the overall direction of this rechartering, with some concerns though:

1) multipath is not mentioned in this charter - based on the conversations we've had over the past months, I think we should be explicit about whether multipath is in or out of scope

The intention was that the new charter would allow the group, as the focal point for QUIC-related things, to consider work such as multipath QUIC. The guidance for discussion of multipath is still the same as Lars' sent to the WG in November [1]. To borrow a bit of that, we still feel it premature to adopt an proposal as a work item.

I see your point, I'm OK with not precluding multipath as long as the guidance from November still holds. But then again, a recharter could be seen as invalidating prior charter-related decisions so being explicit could be useful here.

There's an interesting contrast between this point and your second point. It seems there's a balance between being specific and appearing not open to new ideas.

From my perspective, multipath was important enough of a topic to warrant its own interim a few months back which isn't true of any of our extensions - so I guess that's where I'd draw the line in terms of mentioning something or not?

2) +1 to Ian and Dmitri's comments about mentioning current examples in a way that seems to preclude other extensions, we could remove the examples to help clarify

(previously I commented as an individual, but now with a chair hat on) If 3 people have the same comment, it's likely a sign that some polishing up of the text would help. Specific suggestions always appreciated.

I liked Dmitri's proposal to remove the examples. If we want to include examples that are in scope, I'd suggest also including examples of what's not in scope to make it clear that neither list is exhaustive.

3) I was surprised by "Extensions intended for Standards Track need to have general applicability to multiple application protocols." and I don't think our charter should preclude these. We shouldn't ban standard-track protocols that require a QUIC extension to function properly. Perhaps another way we could phrase this would be to say that "The QUIC WG is only chartered to work on extensions that have general applicability to multiple application protocols. Extensions that are specific to an application protocol should be defined in the WG responsible for that protocol, in consultation with the QUIC WG." -- without stating anything about Standards track.

I'd like Lars or Magnus to respond to this point too. IIUC the intention of the text is to say that QUIC transport extensions that wish to be adopted by this group under Standards Track, should apply broadly. An extension designed for only one specific use, and which the authors do not wish to spend time considering design changes that would permit more-general usage, isn't a great use of the WGs time trying to standardise. However, the QUIC WG is a good venue to catalog such work as Informational or Experimental. I don't believe we want to prevent QUIC extensions that are specific to a use from being developed as Standards Track elsewhere in the IETF.

I love bikeshedding document tracks as much as the next person, but I don't think that needs to be litigated in the charter - the charter should help us decide what we allocate WG time for - if an extension is not seen as valuable by the WG, I don't think it's worth it to spend WG time to publish it as experimental or informational. Either we care about the extension or we don't, right?

4) It seems off to me to simultaneously declare HTTP/3 logging in-scope and HTTP/3 out-of-scope. I think qlog is useful, but if we want to use it outside of the QUIC transport protocol then maybe it should live in another WG.

That's one (fair) interpretation. The intent here is to make it clear that the QUIC WG no longer owns the HTTP/3 application mapping, as always intended. qlog doesn't change protocols so working on that falls into the deployment working area. I expect a large part of the QUIC WG population, to start with, will be made up of deployers of HTTP/3. So while there has been some discussion on the most suitable home for qlog and splitting the drafts up [2], keeping them developed in a single WG would seem like the best way to channel effort and attention of active deployers. If others have a strong sense that is not the case they should speak up.

Members of the QUIC implementers community have been attending other QUIC-adjacent working groups, so I don't think placing them in QUIC will impact implementation energy. I'd even argue that placing these in QUIC might constrain them to QUIC instead of also encouraging other protocols. If someone were to write a draft about how to use qlog with SCTP, would it belong in the QUIC WG?

5) "Maintenance and evolution of the QUIC base specifications" isn't very clear to me - does that mean that working on future versions of QUIC is in or out of scope?

" Maintenance and evolution of the QUIC base specifications that describe its invariants, core transport mechanisms, security and privacy, loss detection and recovery, congestion control, version and extension negotiation, etc. This includes the specification of new versions of QUIC, if necessary."

I think that's clear but if you have some suggestions to improve it we'll take a look.

Nope, that is very clear - I must have missed it which is my fault. Apologies.

But now I'm realizing that the "if necessary" in that last sentence might be interpreted differently by various folks when we start wondering what features should go into QUIC v2. I'd suggest just removing the "if necessary".

David

Cheers,
Lucas

[1] - https://mailarchive.ietf.org/arch/msg/quic/rcPf7u9AHIGwNr6j0ZqrqFujVvk/<https://mailarchive.ietf.org/arch/msg/quic/rcPf7u9AHIGwNr6j0ZqrqFujVvk/>
[2] - https://mailarchive.ietf.org/arch/msg/quic/yv9FFyXItsKK6m-5I5eRE6jnqR8/<https://mailarchive.ietf.org/arch/msg/quic/yv9FFyXItsKK6m-5I5eRE6jnqR8/>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Jan 2021 10:15:20 -0600

> multipath is in or out of scope

+1

I think it should be explicitly mentioned. I don't see why not?

Behcet

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 Jan 2021 15:08:52 +0200

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: Ian Swett <[email-masked]>
Date: Thu, 28 Jan 2021 12:45:13 -0500

Thanks Lars, the updated version looks good to me.

On Thu, Jan 28, 2021 at 8:09 AM 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.
>
> - 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
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 28 Jan 2021 10:30:36 -0800

Thanks Lars, this PR addresses my concerns - I'm happy with this updated
version of the charter.

David

---

From: Roberto Peon <[email-masked]>
Date: Thu, 28 Jan 2021 19:30:07 +0000

Hey Lars!

What would your answer be on where partially-reliable HTTP work would be homed (where it mostly requires QUIC changes, and may require some HTTP changes)?
-=R

On 1/28/21, 5:09 AM, "QUIC on behalf of Lars Eggert" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thanks,
    Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Jan 2021 18:03:44 -0600

I left a comment on the PR about a broader issue that might be useful for
me to bring to the mailing list.

Please see below.

Best,

Spencer

On Thu, Jan 28, 2021 at 1:30 PM Roberto Peon <fenix=[email-masked]>
wrote:

> Hey Lars!
>
> What would your answer be on where partially-reliable HTTP work would be
> homed (where it mostly requires QUIC changes, and may require some HTTP
> changes)?
> -=R
>
>
> On 1/28/21, 5:09 AM, "QUIC on behalf of Lars Eggert" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi,
>
>     - 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
>     Please let me know if this is clearer, and should be merged into the
> text for the continuation of the discussion.
>

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?

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.

In addition to just being nice to other people, I'd kind of expect that
review will happen eventually for any QUIC extension that makes it to
Publication Requested status in its own working group and goes for IETF
Last Call, whether the review happens because a TSVART reviewer is
assigned, or because some QUIC expert saw the Last Call announcement and
became curious. But that's about as late as Late Surprises ever get.

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"?
Do the right thing, of course.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Jan 2021 18:22:10 -0600

Hi, Matt,

On Tue, Jan 26, 2021 at 8:08 PM Matt Joras <[email-masked]> wrote:

> In my view codifying any particular position on multipath in the charter
> is problematic (as we've experienced with the existing charter) and could
> be seen as a firm commitment to adopting those work items immediately along

That's probably true, but it's worth pointing out that removing any mention
of multipath from the charter also sends a message (it's not just what the
charter says now, but what the deltas are). But, moving on ...

Please allow me to up-level a bit (and this may also be relevant for my
comment a few minutes ago, about other groups specifying QUIC usages that
at some point start to require QUIC extensions).

Where I thought we were after November on multipath, was that the chairs
(and the working group) wanted to have conversations about proposed
multipath work in the QUIC working group, but didn't want to have anything
that looked like a commitment to adopt a proposal before people presented
their implementation and deployment experiences.

(Any of the chairs can correct me on that, of course, including you)

Would saying something like that help with multipath, or partially reliable
HTTP (as Roberto asked about), or <insert random proposed extension here>?

Best,

Spencer

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2021 10:17:56 +0200

Hi,

> What would your answer be on where partially-reliable HTTP work would be homed (where it mostly requires QUIC changes, and may require some HTTP changes)?

without having discussed this with my co-chairs:

The H3 changes should live in the HTTP WG.

If partially-reliable HTTP also needs a new QUIC extension, the new charter envisions two options:

One would be to do the QUIC extension in the HTTP WG as well, with some sort of frequent collaboration/review with the QUIC WG. This would probably the preferred approach if that QUIC extension is really only applicable to partially-reliable HTTP.

If however the QUIC extension to support partially-reliable HTTP has broader applicability to other applications, i.e., establishes something like a generic partially-reliable QUIC transport service, that'd argue for doing this work in the QUIC WG instead, and collaborate with HTTP to make sure their needs are met.

Does this make sense? Does the proposed charter text read that way to you?

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2021 10:24:11 +0200

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://github.com/quicwg/wg-materials/pull/192/files#r566650407

Thanks,
Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Jan 2021 16:21:53 +0000

Hi,

So yes this charter is a significant departure from previous QUIC charters. It
goes from be very specific for exactly what the WG should work with to be much
wider paint the allowed scope for the WG. 

The main reason for this change is to force a recharter for every individual
document the WG main want to adopt and work on. 

On Tue, 2021-01-26 at 17:21 -0800, David Schinazi wrote:
> > > we've had over the past months, I think we should be explicit about
> > > whether multipath is in or out of scope
> > > 
> > 
> I see your point, I'm OK with not precluding multipath as long as the guidance
> from November still holds. But then again, a recharter could be seen as
> invalidating prior charter-related decisions so being explicit could be useful
> here.

To be explicit, from my perspecitve this charter will allow the WG to adopt work
on multipath extensions for QUIC. 

> 
> > There's an interesting contrast between this point and your second point. It
> > seems there's a balance between being specific and appearing not open to new
> > ideas.
> > 
> 
> From my perspective, multipath was important enough of a topic to warrant its
> own interim a few months back which isn't true of any of our extensions - so I
> guess that's where I'd draw the line in terms of mentioning something or not?
>  
> examples that are in scope, I'd suggest also including examples of what's not
> in scope to make it clear that neither list is exhaustive.

Will think about this. Listing things that we know the wg will work on at this
stage is easy. List things that would be out of scope but not that far out of
scoep that it is to obvious is not necessarily easy. 

> > > chartered to work on extensions that have general applicability to
> > > multiple application protocols. Extensions that are specific to an
> > > application protocol should be defined in the WG responsible for that
> > > protocol, in consultation with the QUIC WG." -- without stating anything
> > > about Standards track.
> > > 
> > 
> > the text is to say that QUIC transport extensions that wish to be adopted by
> > this group under Standards Track, should apply broadly. An extension
> think that needs to be litigated in the charter - the charter should help us
> decide what we allocate WG time for - if an extension is not seen as valuable
> by the WG, I don't think it's worth it to spend WG time to publish it as
> experimental or informational. Either we care about the extension or we don't,
> right?

I think there was a point of making it clear that an experimental specification
for an extension could make sense when it is not obvious that this is the best
choice and where maybe more wide implementation experience is needed. In these
cases experimental specs can be good. 

I don't necessarily think informational for proprieatary extensions is necessary
worth the WG effort. QUIC and its code point registries are flexible enough that
for most proprietary extensions can publish it where where they desire and
register the code points. 

> > > outside of the QUIC transport protocol then maybe it should live in
> > > another WG.
> > > 
> > 
> > deployment working area. I expect a large part of the QUIC WG population, to
> > start with, will be made up of deployers of HTTP/3. So while there has been
> > some discussion on the most suitable home for qlog and splitting the drafts
> > up [2], keeping them developed in a single WG would seem like the best way
> > to channel effort and attention of active deployers. If others have a strong
> > sense that is not the case they should speak up.
> > 
> 
> Members of the QUIC implementers community have been attending other QUIC-
> adjacent working groups, so I don't think placing them in QUIC will impact
> implementation energy. I'd even argue that placing these in QUIC might
> constrain them to QUIC instead of also encouraging other protocols. If someone
> were to write a draft about how to use qlog with SCTP, would it belong in the
> QUIC WG?

So I have considered this a fair amount what to do with QLOG. It is obious that
the format could be generally applicable to many protocols. However, where it
has significant usage and experience is with QUIC. We have asked around a bit,
and my conclusion so far is that it is not worth spending a year running BOFs
and trying to figure out if this is needs its own WG or not, and which protocol
actually want to define events for the general format. Thus, I think the road to
most easily get a general format and a QUIC event description for it is to just
simply start doing it. That way if someone wants to do an SCTP next year, they
can do it in TSVWG and just reference the format spec done by QUIC.

I hope that answers that question. 

> But now I'm realizing that the "if necessary" in that last sentence might be
> interpreted differently by various folks when we start wondering what features
> should go into QUIC v2. I'd suggest just removing the "if necessary".

Okay, I think we can remove those two words.

Cheers

Magnus Westerlund

---

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Jan 2021 09:50:04 -0800

> 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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 29 Jan 2021 20:44:11 +0000

Yup, that is what I was hoping to hear.
WFM!
-=R

On 1/29/21, 12:18 AM, "Lars Eggert" <[email-masked]> wrote:

    Hi,

    Thanks,
    Lars