Re: Rechartering QUIC for Post Version 1 Work

[Matt Joras <[e-mail]>]

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

> Thanks for your reply, Lucas. Responses inline.
>
> On Tue, Jan 26, 2021 at 4:56 PM Lucas Pardue <[e-mail]>
> 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 <[e-mail]>
>> 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?
>

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.


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

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.


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

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.


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

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.


> 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?
>>>
>>
>> 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.
>>
>
> 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/
>> [2] -
>> https://mailarchive.ietf.org/arch/msg/quic/yv9FFyXItsKK6m-5I5eRE6jnqR8/
>>
>
Matt Joras