Re: [Webtransport] Choosing the Transport

[Victor Vasiliev <[e-mail]>]

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

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

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.


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

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.


> On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson <[e-mail]> wrote:
>
>> 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.
>>
>> --
>> Webtransport mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>