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

[Victor Vasiliev <[e-mail]>]

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.