Subject: [Webtransport] Choosing the Transport

From: Victor Vasiliev <[email-masked]>
Date: Wed, 22 Jul 2020 17:23:17 -0400

Hello everyone,

We recently adopted the overview draft
<https://tools.ietf.org/html/draft-ietf-webtrans-overview-00> that
describes the general requirements for and the model of WebTransport.
However, we haven't yet adopted any specific wire protocol proposals.
There are currently three of those presented to the working group:

   - QuicTransport
   <https://tools.ietf.org/html/draft-vvv-webtransport-quic-02>
   - Http2Transport
   <https://tools.ietf.org/html/draft-kinnear-webtransport-http2-01>
   - Http3Transport
   <https://tools.ietf.org/html/draft-vvv-webtransport-http3-02>
   - [hypothetical WebTransport over WebSocket]

Back when the original idea of WebTransport was forming, the hope was to
implement and ship all four of those, since they all fit different use
cases better.  After talking more to the people at IETF, it sounds like
four transports is a bit too much, and we should settle on two (one over
QUIC, and one over TCP).  The natural picks would be either Http3Transport
with Http2Transport as fallback (HttpTransport for short), or QuicTransport
with… *something* as a fallback.  Let’s look at the differences between
those two options.

*Differences*

The most substantial wire format difference between those two proposals is
the handshake.  QuicTransport originally did not have any handshake; we had
to add a bespoke handshake later in order to implement the Origin header,
and we also added a Path header later on.  We currently don’t have any form
of response headers, so if the server is unhappy with the origin or path
received, it has to close the connection with CONNECTION_CLOSE.  In
HttpTransport, we have regular HTTP header fields for both request and
response, meaning that the server can do things like return a 4xx/5xx for
an error.

During the connection itself, the difference is minimal: QuicTransport uses
streams and datagrams as-is, while Http3Transport prefixes everything with
an ID, since it is multiplexed with other HTTP traffic.  There might be a
question of whether prefixing can impose undesirable framing overhead; I
think if that ever becomes a serious problem, we can come up with some
extension to work this around.

If we decide that QuicTransport is a way to go, we’d have to add more
features into its handshake, since I suspect most people won’t be happy
with what’s in there right now (HTTP headers like Location or Forwarded
would be a good example of what people would end up needing in practice,
together with an ability to tag along arbitrary key-value metadata for
debugging purposes).  If we decide that HttpTransport is a way to go, we
would have to ensure that the result is easy for Web developers to use, and
that we understand the differences between it and regular HTTP.

>From the server complexity standpoint, I am not particularly worried about
either.  We’ve implemented QuicTransport in Chrome, and I wrote two servers
for it, in C++ and in Python; the Python one took about 100 lines of code.
Http2Transport has been implemented, in somewhat different forms, by both
Apple and Facebook, so we have practical experience with it too.  I was
previously concerned that having to implement HPACK/QPACK would be a burden
to the Web developers since those are more complex than what you’d
typically find in a WebSocket implementation, but now that we have a draft
to turn compression off
<https://tools.ietf.org/html/draft-vvv-httpbis-alps-00>, I’m less worried
about this.

There is a question of how much of the HTTP ecosystem we would be actually
getting by adopting HTTP.  It is true that basing WebTransport on HTTP does
not mean HTTP middleware would automatically implement it.  That said, we
do get a lot of useful features from HTTP, notably message routing and a
well-understood metadata format.  Everyone knows what a code 200 or 404 is,
and a lot of people have built their internal debugging/tracing tools based
on adding HTTP headers to things, and being able to easily port those to
WebTransport would be an asset.  I’ve seen some arguments that content
negotiation and caching might be applicable to certain classes of
WebTransport resources too (e.g. a live stream can be cached in the sense
that requesting a live stream is joining it), though those kinds of cases
would have to be content-specific and they do not generalize as nicely as
caching for regular HTTP resources.  An interesting point to note is that
WebTransport is always included programmatically (as opposed to being
navigated to or sourced via URL from HTML), thus alleviating the need for a
lot of otherwise useful HTTP headers.

*Questions*

While on the surface the question here is “which drafts should we adopt?”,
I would like to break this question down into two layers:

   1. Do we want to use the wire format in which we try to build minimally
   on top of QUIC (QuicTransport), or do we base it on HTTP?
   2. To what extent WebTransport connections act like HTTP connections?
   Do they have https URLs or a dedicated schema?  Which HTTP headers do and
   don’t work?

Regarding the first issue, I am increasingly leaning towards keeping only
the HTTP-based option. QuicTransport’s most appealing feature is its
simplicity; however, ever since we’ve had to add a header to communicate
the Web origin, there has been increasingly more and more reasons to add
new features to it, so even if we go that way, we’re probably going to end
up with something that’s a lot like HTTP.  Also, we know exactly how to do
TCP fallback in this case, so this removes a lot of design problems from
consideration.  Fixing complexity and other problems with HTTP is probably
more viable.

Regarding the second issue, I am not sure how much of it is in scope for
this working group.  While we do need to define a URL schema, and the
choice of schema will give us a lot of answer (by making WebTransport same
or different origin as HTTP), a lot of those questions have been
traditionally answered somewhere in Fetch spec, or simply not addressed in
the standards at all.  I am not quite sure what to do with those.

What do people think?

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Jul 2020 15:57:26 +1000

Thanks for the summary Victor, that really helps frame things.

There are other differences, I think, so it would be good to make sure that we've captured all the relevant ones before making a call.  And understanding all the implications of each is important.

The one that comes to mind is the way that fallbacks work.  In HTTP, you can imagine leaning heavily on the HTTP mechanisms for QUIC upgrade (or TCP fallback), like Alt-Svc and so forth.  The questions raised regarding non-uniform support for features are relevant here, so this isn't completely free.  In another scheme, you can code the fallback directly, even to the point of having it in the API: connect(quicTransport=quic-transport://..., webSocketTransport=wss://...).  In other words, a clean slate means that you have to build the features you want, but you don't necessarily have to deal with the baggage you might not.

I haven't formed an opinion on this yet.  I have a few concerns/wrinkles to add below though.

On Thu, Jul 23, 2020, at 07:23, Victor Vasiliev wrote:
> I was previously concerned that having to 
> implement HPACK/QPACK would be a burden to the Web developers since 
> those are more complex than what you’d typically find in a WebSocket 
> implementation, but now that we have a draft to turn compression off 
> <https://tools.ietf.org/html/draft-vvv-httpbis-alps-00>, I’m less 
> worried about this.

I think that suggests some additional complexities.  You have to implement all of that stack, and trust that browsers do so as well.  As we have learned, sourcing a new capability like this isn't necessarily free.  And this seems at least on-par with ALPN in terms of operational costs for server deployments.  Maybe it is less of a concern as webtransport endpoints are the only ones that need upgrading, but I don't see this as an easy solution.

> While on the surface the question here is “which drafts should we 
> adopt?”, I would like to break this question down into two layers:

I think that there is question zero: do we need to pick one set, or do we need to build all four protocols?

We have not seen sufficient justification for building four protocols rather than two, so I'm firmly in the "do less work camp" on this.

>  1. Do we want to use the wire format in which we try to build 
> minimally on top of QUIC (QuicTransport), or do we base it on HTTP?
> Do they have https URLs or a dedicated schema?  Which HTTP headers do 
> and don’t work?

I think that the answer to the second depends on the first.  As much as possible I would prefer NOT to mint new URI schemes, but that is much harder if you define a completely new protocol.  I think that an important question to resolve before this (1.5?) is how these connections integrate into the origin model.

---

From: virat tara <[email-masked]>
Date: Fri, 24 Jul 2020 00:03:20 +0530

Hi,

For an app that would use both regular HTTP calls and WebTransport, from
the server's perspective, won't using HttpTransport instead of a dedicated
connection like in QuicTransport help it to reduce the number of active
connections/sockets per client? Thus allowing it to serve more
distinct clients per server. Particularly for apps that make
occasional HTTP calls and heavily rely on a full-duplex protocol for the
rest of their working.

On Thu, Jul 23, 2020 at 2:53 AM Victor Vasiliev <vasilvv=
[email-masked]> wrote:

> received, it has to close the connection with CONNECTION_CLOSE..  In
> During the connection itself, the difference is minimal: QuicTransport
> uses streams and datagrams as-is, while Http3Transport prefixes everything
> with an ID, since it is multiplexed with other HTTP traffic.  There might
> be a question of whether prefixing can impose undesirable framing overhead;
> I think if that ever becomes a serious problem, we can come up with some
> Apple and Facebook, so we have practical experience with it too..  I was
> typically find in a WebSocket implementation, but now that we have a
> draft to turn compression off
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Jul 2020 09:57:48 +1000

On Fri, Jul 24, 2020, at 04:33, virat tara wrote:
> For an app that would use both regular HTTP calls and WebTransport, 
> from the server's perspective, won't using HttpTransport instead of a 
> dedicated connection like in QuicTransport help it to reduce the number 
> of active connections/sockets per client? Thus allowing it to serve 
> more distinct clients per server. Particularly for apps that make 
> occasional HTTP calls and heavily rely on a full-duplex protocol for 
> the rest of their working.

That's a good point.  My understanding of the HTTP mappings is that you can make several "instances" of the WebTransport thing in the one connection.  Even if you only have one WebTransport thing, you can still use the same connection for HTTP and the thing.  With a dedicated transport, it seems like you just have one.  

Of course that one is capable of a lot of concurrency, so you might be comfortable with not having multiple sessions, but I can imagine cases for sharing different logical contexts that can be split at a gateway.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Jul 2020 18:42:25 -0700

Martin said:

"That's a good point.  My understanding of the HTTP mappings is that you
can make several "instances" of the WebTransport thing in the one
connection."

[BA] Here is the current Http3Transport constructor:

[Exposed <https://heycam.github.io/webidl/#Exposed>=(Window,Worker)]interface
Http3Transport <https://wicg.github.io/web-transport/#http3transport>
{
  constructor(DOMString
<https://heycam.github.io/webidl/#idl-DOMString> url
<https://wicg.github.io/web-transport/#dom-http3transport-constructor-url-url>);
};

It only takes a url as an argument (like the WebSocket constructor).  So
the implication is that invoking the constructor creates a distinct QUIC
connection.  But using that QUIC connection, it is possible to create
multiple bi-directional or uni-directional streams or send datagrams in
either direction.  So "pooling" or other sharing of an Http3Transport is
already supported to a significant extent.

Martin said:
"Even if you only have one WebTransport thing, you can still use the same
connection for HTTP and the thing."

[BA]  Note that the Http3Transport  constructor doesn't have an optional
QuicTransport object as an argument, so that there's no way to "share" a
QUIC transport between Http3 (as used by say, fetch) and Http3Transport.

There is a reason why this isn't supported, even though it was something
that seemed quite desirable. HTTP/3 is very specific on how it uses Stream
IDs, so it would be quite tricky to have both the WebTransport and another
API like fetch sharing a QUIC connection.

On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson <[email-masked]> wrote:

> That's a good point.  My understanding of the HTTP mappings is that you
> can make several "instances" of the WebTransport thing in the one
> connection.  Even if you only have one WebTransport thing, you can still
> use the same connection for HTTP and the thing.  With a dedicated
> transport, it seems like you just have one.
>
> Of course that one is capable of a lot of concurrency, so you might be
> comfortable with not having multiple sessions, but I can imagine cases for
> sharing different logical contexts that can be split at a gateway.
>
> --

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Jul 2020 12:19:58 +1000

On Fri, Jul 24, 2020, at 11:42, Bernard Aboba wrote:
> It only takes a url as an argument (like the WebSocket constructor).  
> So the implication is that invoking the constructor creates a distinct 
> QUIC connection.  

How do you go from URL to a single connection?  fetch takes a single URL too, but those routinely use existing connections (in all protocol versions).

I also don't see the BlahTransport as having any inherent 1-1 mapping with connections.  If that is the case for Http[N]Transport, I would regard that as a design error.

> [BA]  Note that the Http3Transport  constructor doesn't have an 
> optional QuicTransport object as an argument, so that there's no way to 
> "share" a QUIC transport between Http3 (as used by say, fetch) and 
> Http3Transport.

Again, how did you get there?  I realize that there might be reasons why you might want to avoid sharing, like the rules we have for font fetching, but it doesn't naturally follow that you need a new connection for this.

> There is a reason why this isn't supported, even though it was 
> something that seemed quite desirable. HTTP/3 is very specific on how 
> it uses Stream IDs, so it would be quite tricky to have both the 
> WebTransport and another API like fetch sharing a QUIC connection. 

Now we're getting somewhere.  I agree that getting access to a bidirectional stream in HTTP/3 is tricky (and a unidirectional stream in HTTP/2 trickier), but surely these are spelling problems, not fundamental barriers to multiplexing.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 24 Jul 2020 01:04:06 -0400

On Thu, Jul 23, 2020 at 1:57 AM Martin Thomson <[email-masked]> wrote:

> There are other differences, I think, so it would be good to make sure
> that we've captured all the relevant ones before making a call.  And
> understanding all the implications of each is important.
>
> The one that comes to mind is the way that fallbacks work.  In HTTP, you
> can imagine leaning heavily on the HTTP mechanisms for QUIC upgrade (or TCP
> fallback), like Alt-Svc and so forth.  The questions raised regarding
> non-uniform support for features are relevant here, so this isn't
> completely free.  In another scheme, you can code the fallback directly,
> even to the point of having it in the API:
> connect(quicTransport=quic-transport://..., webSocketTransport=wss://...).
> In other words, a clean slate means that you have to build the features you
> want, but you don't necessarily have to deal with the baggage you might not.
>

What exactly do you mean by "non-uniform support for features"?

It's true that HttpTransport in its default state basically has to defer
the protocol choice to the browser, since the JavaScript code has no
visibility into the state of the socket pool.  I'll note, however, that
this is not an inherent property of the HTTP wire protocol itself, but
rather just the natural way we would treat this kind of URL by default
(which is why I split the two questions below the way I did).  You can
imagine adding extra options to connect() that would change this as needed.

> I think that suggests some additional complexities.  You have to implement
> all of that stack, and trust that browsers do so as well.  As we have
> learned, sourcing a new capability like this isn't necessarily free.  And
> this seems at least on-par with ALPN in terms of operational costs for
> server deployments.  Maybe it is less of a concern as webtransport
> endpoints are the only ones that need upgrading, but I don't see this as an
> easy solution.
>

That's true, though any HTTP extension of this kind would to some extent
rely on ALPS (or some other form of half-RTT settings), since otherwise you
have to pay a round-trip penalty by waiting for an indication that the
server actually supports ALPS.  Overall, I think that between this,
Accept-CH reliability draft, and other extensions, we would have to solve
the SETTINGS latency problem sooner or later anyways.

> We have not seen sufficient justification for building four protocols
> rather than two, so I'm firmly in the "do less work camp" on this.
>

I don't believe I've seen any enthusiasm for four protocols so far, which
is why I posed the first question as a binary choice.  Fortunately, even if
more interest becomes apparent down the road, WebTransport is
currently structured in a way that we can always add more.

> I think that the answer to the second depends on the first.  As much as
> possible I would prefer NOT to mint new URI schemes, but that is much
> harder if you define a completely new protocol.  I think that an important
> question to resolve before this (1.5?) is how these connections integrate
> into the origin model.

I think the "origin model" question is automatically answered by the URI
scheme, since that would tell us if WebTransport can be, in principle,
same-origin to a Web page.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Jul 2020 15:48:41 +1000

On Fri, Jul 24, 2020, at 15:04, Victor Vasiliev wrote:
> The questions raised regarding non-uniform support for features are relevant here, so this isn't completely free.
> 

Let's say that you like a particular extension to the protocol, but the server doesn't universally implement it across versions.  The worse case is where the extension works in one version, but not a protocol that you might otherwise prefer.  For instance, DATAGRAM support not being available in HTTP/3.

This is just a natural consequence of building protocols up piecemeal.  It's not a big deal, but it does tend to happen more with an existing protocol that you build on than a protocol you build from scratch.

> I think the "origin model" question is automatically answered by the 
> URI scheme, since that would tell us if WebTransport can be, in 
> principle, same-origin to a Web page.

I'm not sure that it is necessarily that simple.  This gets into the issues that Adam raised about cookies, and there are questions about CORS.  It probably makes sense to recognize this as being exempt from CORS preflight on the understanding that support for the protocol implies an acknowledgment that ambient authority is NOT sufficient for authorization, but we also have to consider what state from the target origin is carried across into the WebTransport session.  Maybe we don't provide a way to carry cookies, but can we share connections?  Or session tickets?  I see from Bernard's response that the current thinking is to avoid this by avoiding connection reuse entirely.  I'm not yet convinced that this is the right answer.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 24 Jul 2020 03:00:36 -0400

On Thu, Jul 23, 2020 at 9:42 PM Bernard Aboba <[email-masked]>
wrote:

> [Exposed <https://heycam.github.io/webidl/#Exposed>=(Window,Worker)]interface Http3Transport <https://wicg.github.io/web-transport/#http3transport> {
>   constructor(DOMString <https://heycam.github.io/webidl/#idl-DOMString> url <https://wicg.github.io/web-transport/#dom-http3transport-constructor-url-url>);
> };
>
>

Http3Transport supports that form of multiplexing using Session IDs:
https://tools.ietf.org/html/draft-vvv-webtransport-http3-02#section-4.3.
As Virat has pointed out, this helps to cut down on the number of
individual connections to an individual server, which is one of
HttpTransport's more compelling points.

> API like fetch sharing a QUIC connection.

Stream IDs are indeed a problem for HTTP-based transports, which is one of
the reasons we got rid of them in the API draft at some point.  Part of
this has to do with behavior across proxies, and part of this has to do
with accidental information disclosure about different-origin traffic on a
shared connection.  I've actually filed an issue about this that I want to
discuss at the upcoming meeting:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1

There are also lots of questions of how multiplexing interacts with
MAX_STREAM_ID and potential DoS concerns, and I am not sure we actually
address those in the draft right now.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 24 Jul 2020 03:38:57 -0400

On Fri, Jul 24, 2020 at 1:49 AM Martin Thomson <[email-masked]> wrote:

> > The questions raised regarding non-uniform support for features are
> relevant here, so this isn't completely free.
> >
> Let's say that you like a particular extension to the protocol, but the
> server doesn't universally implement it across versions.  The worse case is
> where the extension works in one version, but not a protocol that you might
> otherwise prefer.  For instance, DATAGRAM support not being available in
> HTTP/3.
>
> This is just a natural consequence of building protocols up piecemeal.
> It's not a big deal, but it does tend to happen more with an existing
> protocol that you build on than a protocol you build from scratch.
>

I think the draft currently defines DATAGRAM as a requirement for
WebTransport over HTTP/3, so the question here would be something among the
lines of "what do we do when we have an active HTTP/3 connection in the
pool, but it has no WT support?".  I agree there's a lot of ambiguity in
this space right now, and it kind of exists between protocol space and the
API space.

> I'm not sure that it is necessarily that simple.  This gets into the
> issues that Adam raised about cookies, and there are questions about CORS.
> It probably makes sense to recognize this as being exempt from CORS
> preflight on the understanding that support for the protocol implies an
> acknowledgment that ambient authority is NOT sufficient for authorization,
> but we also have to consider what state from the target origin is carried
> across into the WebTransport session.  Maybe we don't provide a way to
> carry cookies, but can we share connections?  Or session tickets?  I see
> from Bernard's response that the current thinking is to avoid this by
> avoiding connection reuse entirely.  I'm not yet convinced that this is the
> right answer.
>

I believe cookies are defined to be bound to a host-port tuple (since they
predate the origin model), meaning that the question is mostly just "do we
want to send them at all?", because the rules are otherwise clear.
Regarding CORS, I agree that a preflight is not necessary, and for what
it's worth, WebSocket does not do it already.
Sharing connections should probably follow the regular HTTP connection
reuse rules, which are nominally defined in RFC 7540
<https://tools.ietf.org/html/rfc7540#section-9.1>, but also depend on other
factors like the credentials mode
<https://fetch.spec.whatwg.org/#concept-request-credentials-mode> and
probably some other bespoke rules that aren't written down anywhere.
Session tickets in general are only bound by SNI, and for 0-RTT, by ALPN; I
don't think the behavior there depends on the application protocol in any
form.

---

From: virat tara <[email-masked]>
Date: Fri, 24 Jul 2020 17:00:24 +0530

Hi Bernard,

> Note that the Http3Transport  constructor doesn't have an optional

I got the impression that HTTP/3 calls like fetch and Http3Transport will
be able to share a connection from draft-vvv-webtransport-http3-02#section-1
<https://tools.ietf.org/html/draft-vvv-webtransport-http3-02#section-1> where
it says "Using the mechanism described here, multiple Http3Transport
instances can be multiplexed simultaneously with regular HTTP traffic on
the same HTTP/3 connection".

The ability to share a QUIC connection between HTTP3 (e.g. fetch) and
> WebTransport (via WebTransport API) has come up from time to time. Do you
> have a use case where this would be valuable?
>

An example would be an app where full-duplex communication is required only
at a particular step of the user flow (ex. taxi booking or food ordering
application), like at the time of live location sharing or chat support,
but the rest of the functionality requires only client to server API calls.
Some of these actions can be simultaneously performed by the user like live
location sharing + browsing through the app and thus making some fetch
calls.

One can argue that the fetch calls being stateless can be converted
into events to make them compatible with WebTransport. I think that's not a
simple decision to make once you have built up an application and later on
decide to incorporate a small feature that requires full duplex
communication on the same server. One can always resort to HTTP Long
Polling in such cases and I think this is one of the main reasons long
polling is still in use and not obsolete. RFC 8441
<https://tools.ietf.org/html/rfc8441> would have made it obsolete but it is
yet to be rolled out on major browsers.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Jul 2020 07:56:11 -0700

Martin said:

"How do you go from URL to a single connection?  fetch takes a single URL
too, but those routinely use existing connections (in all protocol
versions).

I also don't see the BlahTransport as having any inherent 1-1 mapping with
connections.  If that is the case for Http[N]Transport, I would regard that
as a design error."

[BA] Here is the text from Section 14.2.1 (Http3Transport)
<https://wicg.github.io/web-transport/#http3-transport-constructors>:

"

   1.

   Either establish an HTTP/3 connection or reuse an existing HTTP/3
   connection to the host specificed by the url, as specified in
   [WEB-TRANSPORT-HTTP3]
   <https://wicg.github.io/web-transport/#biblio-web-transport-http3>.
   2.

   If there is no such HTTP/3 connection to reuse and the establishment of
   a new HTTP/3 connection, set transport’s [[WebTransportState]]
   <https://wicg.github.io/web-transport/#dom-quictransport-webtransportstate-slot>
internal
   slot to "failed" and abort these steps."

So there is support for re-use, although it's not clear whether "reuse an
HTTP/3 connection" means to reuse a connection on which an
Http3Transport has been established, or whether any HTTP/3 connection to
the same host can be reused, enabling sharing between fetch and
Http3Transport (or maybe even with a QuicTransport).  I have filed an issue
to clarify this:
https://github.com/WICG/web-transport/issues/128

Note that in contrast, Section 8.2 (QuicTransport constructor)
<https://wicg.github.io/web-transport/#quic-transport-definition> says:

"Establish a QUIC connection to the address identified by parsedURL following
the procedures in [WEB-TRANSPORT-QUIC]
<https://wicg.github.io/web-transport/#biblio-web-transport-quic> section 3
and using clientOrigin as the "origin of the client" referenced in section
3.2.1. While establishing the connection, follow all of the parameters
specified in the options
<https://wicg.github.io/web-transport/#dom-quictransport-constructor-url-options-options>
."

So for QuicTransport there are no checks whether a QUIC connection has
already been established. So there is no support for sharing of connections
between QuicTransports.

IMHO, it would be useful to think through the pooling/sharing use cases to
make sure that we understand the requirements.

On Thu, Jul 23, 2020 at 7:20 PM Martin Thomson <[email-masked]> wrote:

> How do you go from URL to a single connection?  fetch takes a single URL
> too, but those routinely use existing connections (in all protocol
> versions).
>
> I also don't see the BlahTransport as having any inherent 1-1 mapping with
> connections.  If that is the case for Http[N]Transport, I would regard that
> as a design error.
>
> Again, how did you get there?  I realize that there might be reasons why
> you might want to avoid sharing, like the rules we have for font fetching,
> but it doesn't naturally follow that you need a new connection for this.
>
> Now we're getting somewhere.  I agree that getting access to a
> bidirectional stream in HTTP/3 is tricky (and a unidirectional stream in
> HTTP/2 trickier), but surely these are spelling problems, not fundamental
> barriers to multiplexing.
>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Jul 2020 09:10:44 -0700

Virat said:

"I got the impression that HTTP/3 calls like fetch and Http3Transport will

[BA] The WebTransport API spec seems to imply some (or maybe all) of this,
but there isn't any implementation experience AFAIK.

"An example would be an app where full-duplex communication is required
only at a particular step of the user flow (ex. taxi booking or food
ordering application), like at the time of live location sharing or chat
support, but the rest of the functionality requires only client to server
API calls. Some of these actions can be simultaneously performed by the
user like live location sharing + browsing through the app and thus making
some fetch calls."

[BA] Question: In this use case, is there an interaction between HTTP/3
traffic and WebTransport traffic?  For example, in the RIPT BOF there were
examples shown where an HTTP/3 Request elicited an HTTP/3 Response as well
as HTTP/3 datagram traffic from server to client.  The idea was to enable
SIP-like exchanges to occur within HTTP/3 so as to enable calling.

This would enable the taxi booking or food ordering application to allow
the user to talk to the taxi driver or submit their food order in a voice
call, using a single HTTP/3 Connection.

On Fri, Jul 24, 2020 at 4:30 AM virat tara <[email-masked]> wrote:

> be able to share a connection from
> draft-vvv-webtransport-http3-02#section-1
> An example would be an app where full-duplex communication is required
> only at a particular step of the user flow (ex. taxi booking or food
> ordering application), like at the time of live location sharing or chat
> support, but the rest of the functionality requires only client to server
> API calls. Some of these actions can be simultaneously performed by the
> user like live location sharing + browsing through the app and thus making
> some fetch calls.
>
> <https://tools.ietf.org/html/rfc8441> would have made it obsolete but it
> is yet to be rolled out on major browsers.
>

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 27 Jul 2020 16:57:50 +0900

Is this for web developers or non-web users?
WebSocket uses the Upgrade mechanism and uses HTTP headers, but doesn't
expose most of the information. For example, we don't expose the HTTP
status code to web developers. The only information it exposes to web
developers is
 - whether the connection is established
 - protocol (sec-websocket-protocol)
 - extensions (sec-websocket-extensions)
.

I'm a bit concerned about confusion we would see with having yet another
HTTP-like protocol. To what extent it is similar to HTTP is difficult, and
people would have diverse expectations I think, given the experience in
WebSocket.

---

From: virat tara <[email-masked]>
Date: Mon, 27 Jul 2020 14:22:03 +0530

>
> Bernard's question: In this use case, is there an interaction between
> HTTP/3 traffic and WebTransport traffic?  For example, in the RIPT BOF
> there were examples shown where an HTTP/3 Request elicited an HTTP/3
> Response as well as HTTP/3 datagram traffic from server to client.  The
> idea was to enable SIP-like exchanges to occur within HTTP/3 so as to
> enable calling.

No, there is no interaction between HTTP/3 traffic and WebTransport traffic
in my use case.

> call, using a single HTTP/3 Connection.

Yes, this can be another use case where sharing of connection between
HTTP/3 and Http3Transport (via RIPT) will be helpful.

On Sat, Jul 25, 2020 at 9:40 PM Bernard Aboba <[email-masked]>
wrote:

>>> "Even if you only have one WebTransport thing, you can still use the
>>> same connection for HTTP and the thing."
>>>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Jul 2020 13:12:37 -0700

"If we decide that QuicTransport is a way to go, we’d have to add more
features into its handshake, since I suspect most people won’t be happy
with what’s in there right now "

[BA] As Ted noted during the meeting, there are datagram use cases for
which "more features" may not be helpful or desirable. At the W3C Games
workshop, developers indicated a desire for "UDP for the Web", a way to
send small updates client/server or P2P.  Another "UDP for the Web"
scenarios is video ingest, uploading video from a camera or browser to a
server that would prefer not to have to implement ICE or WebRTC.

In those kind of scenarios, implementations may not even support all of
QuicTransport (e.g. only QUIC datagrams, not reliable streams).

So instead of starting from the assumption that "there can only be one",
would it be possible to start from the assumption that "simplicity is the
main feature" of QuicTransport, leaving the enhancements (and the bulk of
WG attention) on Http3/Http2Transport? This is what the IETF did with SLIP
(a non-standard) and PPP (standards track).

On Mon, Jul 27, 2020 at 12:58 AM Yutaka Hirano <yhirano=
[email-masked]> wrote:

>> The most substantial wire format difference between those two proposals
>> is the handshake.  QuicTransport originally did not have any handshake; we
>> had to add a bespoke handshake later in order to implement the Origin
>> header, and we also added a Path header later on.  We currently don’t have
>> any form of response headers, so if the server is unhappy with the origin
>> or path received, it has to close the connection with CONNECTION_CLOSE..
>> In HttpTransport, we have regular HTTP header fields for both request and
>> From the server complexity standpoint, I am not particularly worried
>> about either.  We’ve implemented QuicTransport in Chrome, and I wrote two
>> servers for it, in C++ and in Python; the Python one took about 100 lines
>> of code.  Http2Transport has been implemented, in somewhat different forms,
>> by both Apple and Facebook, so we have practical experience with it too..
>> I was previously concerned that having to implement HPACK/QPACK would be a
>> burden to the Web developers since those are more complex than what you’d
>> There is a question of how much of the HTTP ecosystem we would be
>> actually getting by adopting HTTP.  It is true that basing WebTransport on
>> HTTP does not mean HTTP middleware would automatically implement it.  That
>> said, we do get a lot of useful features from HTTP, notably message routing
>> and a well-understood metadata format.  Everyone knows what a code 200 or
>> 404 is, and a lot of people have built their internal debugging/tracing
>> tools based on adding HTTP headers to things, and being able to easily port
>> those to WebTransport would be an asset.  I’ve seen some arguments that
>> content negotiation and caching might be applicable to certain classes of
>>    2. To what extent WebTransport connections act like HTTP
>>    connections?  Do they have https URLs or a dedicated schema?  Which HTTP
>>    headers do and don’t work?
>>
>>
>> this working group..  While we do need to define a URL schema, and the