Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

[Eric Rescorla <[e-mail]>]

On Tue, Feb 11, 2020 at 1:31 PM "Mirja Kühlewind (IETF)" <
[e-mail]> wrote:

> Hi David,
>
> I didn’t say that other groups cannot define extension. I did say that
> it’s the decision of the working group that maintains the protocol how to
> handle that and for Quic we didn’t have had that discussion yet.
>
> Examples for groups that explicitly define process for extending the
> protocol in their charter are dhc and 6man. As you can see different
> groups/protocols have different process and as we didn’t define anything
> yet for Quic, the working assumption for now should be that all extension
> work will be fine in the Quic group.
>

Well, the IANA considerations for QUIC transport seem fairly clear:

https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4

Most of the code points are assigned via Specification Required, so I don't
see why you would infer that all extensions happen within the QUIC WG.

-Ekr







> Mirja
>
>
> Am 11.02.2020 um 21:47 schrieb David Schinazi <[e-mail]>:
>
> 
> Hi Mirja,
>
> I'm not sure I agree with your interpretation. The fact that a WG is
> responsible for a protocol does not mean that other working groups
> cannot write extensions to that protocol.
>
> For example, the QUIC WG is defining the quic_transport_parameters
> TLS extension. That extension is not defined in the TLS WG.
> https://tools.ietf.org/html/draft-ietf-quic-tls-25#section-8.2
>
> Similarly, the ACME WG is defining the Cert-Not-Before HTTP
> header, not the HTTP WG.
> https://tools.ietf.org/html/draft-ietf-acme-star-11#section-6.7
>
> Additionally, MPTCP is an extension to TCP that was not
> defined in the TCPM WG. The list goes on.
>
> We don't yet have examples for QUIC as the QUIC IANA
> registries haven't been created yet, but I don't see why QUIC
> would be different from TLS, HTTP, or TCP.
>
> David
>
>
> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <[e-mail]>
> wrote:
>
>> Hi David,
>>
>> One more comment below.
>>
>> > On 6. Feb 2020, at 14:46, David Schinazi <[e-mail]>
>> wrote:
>> >
>> > Hi Magnus,
>> >
>> > I realized that some of our earlier replies were accidentally not sent
>> to
>> > the IESG list, for which I apologize.
>> >
>> > To summarize that discussion:
>> >
>> > - It is not our intention to build a new transport protocol here.
>> > The WEBTRANS WG would build application protocols that
>> > run over QUIC, or TLS/TCP. This would ensure we benefit
>> > from their security and congestion control properties.
>> > Here is a PR to the charter that should clarify this:
>> > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files
>> >
>> > - The WEBTRANS WG would not modify QUIC or HTTP.
>> > Any discussion of modifying those core protocols would
>> > happen in their existing respective working groups.
>> > However, discussion of extensions to these protocols could
>> > be allowed in this WG, as long as any document WGLC is
>> > also sent to the mailing list responsible for that protocol.
>>
>> I think this is not sufficient, at least not for QUIC. More discussion is
>> needed in the QUIC group on this but currently I think the assumption
>> should be that all extensions will be done within the QUIC group. So just
>> sending a WGLC there is not sufficient.
>>
>> More generally deciding on processes for other protocols/groups in this
>> charter is not appropriate. I’m not sure what the defined process is for
>> HTTP and TLS but that should be specified in their charter and not here.
>>
>> For QUIC, I would like to rather see that extension or modification are
>> out of scope for this group. Of course that doesn’t mean that this group
>> cannot talk about any extension but as soon as the group thinks an
>> extension is needed, it needs to go to the QUIC group and cannot just adapt
>> anything within WebTransport.
>>
>> Please also double-check what the right process is for TLS and HTTP. I
>> assume for TLS it's the same but for HTTP it might be different…?
>>
>> Mirja
>>
>>
>>
>> >
>> > Would that be an acceptable scope?
>> >
>> > Thanks,
>> > David
>> >
>> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev <[e-mail]>
>> wrote:
>> > I believe most of those have been addressed in David's PR, so I'll try
>> to reply
>> > primarily to those that I have something to add to.
>> >
>> > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker <
>> [e-mail]> wrote:
>> > Magnus Westerlund has entered the following ballot position for
>> > charter-ietf-webtrans-00-00: Block
>> >
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut this
>> > introductory paragraph, however.)
>> >
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/charter-ietf-webtrans/
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > BLOCK:
>> > ----------------------------------------------------------------------
>> >
>> >
>> > [snip]
>> >
>> > The group will also coordinate with related working groups within the
>> IETF,
>> > such as QUIC and HTTPBIS, as appropriate.
>> >
>> > With the current state of QUIC developement and HTTP/3 mapping
>> definition, i.e.
>> > still working on the initial version, I would like to have a more firm
>> wording
>> > that the WebTrans WG will actually have to take any requests for
>> extensions of
>> > HTTP/3 and QUIC to the relevant WG.
>> >
>> > While there are no extensions to QUIC among the proposed WG documents,
>> some of
>> > the drafts do extend HTTP using custom SETTINGS parameters (which is the
>> > intended HTTP extensibility mechanism).  I've hitherto assumed that
>> webtrans
>> > would work with HTTP experts in httpbis/quic to ensure that the proposed
>> > extensions are architecturally sound and follow best practices, but the
>> main
>> > bulk of work would be done in the new working group itself.
>> >
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > I also would appreciate if someone can clarify what stage of formality
>> the
>> > Web-Transport API has been adopted in W3C and is being worked on.
>> Trying to
>> > find anything about which group it belongs to on the W3C page didn't
>> give me
>> > any information. All I found is that there have been a workshop on game
>> > communication where this was discussed and raised in some discussions.
>> >
>> > It's a WICG draft, which basically means no formal status.  We had a
>> discussion
>> > session at TPAC last year, and I believe most people who'd be normally
>> involved
>> > are aware of it, but my current understanding is that the editors of
>> the W3C
>> > spec currently do not believe we have enough real-world implementation
>> > experience with the proposal to advance it further in the formal
>> process.
>> >
>> > Having lived through the WebRTC / RTCWeb interactions it would good to
>> know
>> > more how the interaction between the bodies are intended to work.
>> Especially as
>> > changes to the API can have significant impact on what work needs to
>> happen in
>> > the IETF.
>> >
>> > I mostly agree with Bernard here.  My plan was that the -overview doc
>> would
>> > list all of the protocol requirements and API expectations, acting as
>> > integration point between W3C and IETF specs.
>> >
>> > The current API draft does not include any discussion of priority.
>> However
>> > draft-vvv-webtrans-overview does mention priorities. As this API
>> appears to
>> > support multiple parallel transmissions and transfers I think at a
>> minimal a
>> > sender transport protocol scheduling or HTTP/3 priority  would be
>> likely to be
>> > part of the work. I also have to ask if this is likely to attempted to
>> be
>> > mapped also towards the network level, for example DSCPs? If any such
>> work is
>> > expected and intended I think that needs to be raised. Otherwise I
>> would assume
>> > that at most what this work will be to use the undefined APIs to HTTP/3
>> and
>> > QUIC to influence those protocol to perform stream priorities.
>> >
>> > This is mostly a gap in the API spec.  I've been meaning to write this
>> up
>> > further, but there's a lot of text to write.
>> >
>> > Before I elaborate further, I would like to point out that there are
>> two types
>> > of priorities here, and those are often confused:
>> > (1) Priorities that the application indicates to the transport layer
>> for the
>> >     purpose of scheduling writes.
>> > (2) Priorities that are communicated to the peer on the wire as a
>> hint...
>> >
>> > Most of the discussion in HTTPBIS and QUIC WGs was about #2.  I don't
>> believe
>> > any of the proposed drafts cover that topic, and I'd rather wait for
>> > quic/httpbis to come up with a mechanism first.
>> >
>> > The priorities mentioned in -overview are of the #1 kind.  Section 2.3
>> of
>> > draft-ietf-quic-transport-25 explicitly encourages implementations
>> (that would
>> > include the proposed Web APIs) to provide those:
>> >
>> > """
>> > [QUIC] relies on receiving priority information from the application
>> that uses
>> > QUIC.
>> >
>> > A QUIC implementation SHOULD provide ways in which an application can
>> indicate
>> > the relative priority of streams. When deciding which streams to
>> dedicate
>> > resources to, the implementation SHOULD use the information provided by
>> the
>> > application.
>> > """
>> >
>> > Besides, I don't believe we can avoid defining a write scheduling
>> mechanism in
>> > the API.  QUIC itself treats it as an implementation detail, but Web
>> APIs
>> > generally try really hard to avoid implementation-defined behavior.  If
>> > every browser had a completely different write scheduling approach,
>> > that could make the job of writing performant cross-browser code really
>> > difficult.
>> >
>> > Thanks,
>> >   Victor.
>> > --
>> > Webtransport mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/webtransport
>>
>> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>