Re: [Webtransport] Choosing the Transport

[virat tara <[e-mail]>]

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

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

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 <[e-mail]>
wrote:

> Virat said:
>
> "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".
>
> [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 <[e-mail]> wrote:
>
>> Hi Bernard,
>>
>>
>>> 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.
>>>
>>
>> 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.
>>
>> On Fri, Jul 24, 2020 at 7:12 AM 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.
>>>
>>> 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 <[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
>>>
>>