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

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