Re: [Webtransport] Comment(s) on draft-vvv-webtransport-quic and draft-vvv-webtransport-http3

[Victor Vasiliev <[e-mail]>]

On Tue, Nov 19, 2019 at 6:33 AM Bernard Aboba <[e-mail]>
wrote:

> There are a few differences between QuicTransport and Http3Transport that
> caught my attention.
>
> 1. 0-RTT.  Section 3.3 says "0-RTT support in QuicTransport is OPTIONAL"
> whereas draft-vvv-webtransport-http3 Section 4.3 indicates "Http3Transport
> does not support 0-RTT".  Currently the WebTransport API has no support for
> this (optional) feature.
>

Indeed.  I would not be surprised if we could add 0-RTT support into the
API, but that is somewhat of a complex endeavor.


> 2. Session IDs and Pooling. draft-vvv-webtransport-http3 Section 3
> describes the Session ID (a hop-by-hop property) and the table in Section 7
> indicates that pooling is supported.  There is no equivalent in
> QuicTransport, which does not support pooling as noted in Section 7 of
> draft-vvv-webtransport-quic.
>
> webtransport-http3 Section 5 notes that "Session IDs are used to
> demultiplex streams and datagrams belonging to different Http3Transport
> sessions".  Section 3 says "session IDs SHOULD NOT be exposed to the
> application".
>
> This made me wonder under what circumstances session IDs might be exposed,
> and also whether there were situations where a session ID or pooling might
> make sense for QuicTransport.  Could a QuicTransport ever need to be
> demultiplexed in the same way as an Http3Transport?
>

I can imagine exposing session ID as a part of a debugging interface.  The
main problem is that they are not that useful.

I don't believe pooling QuicTransports would be useful.  It would make
things like stats really hard to do.


> NITs
>
> 1.
>
> Would be good to indicate where comments can be sent.  Presumably this
> would be to [e-mail] or a github repo.
>

Fixed.

  -- Victor.