Re: [Webtransport] Demultiplexing in case of unreliable datagrams

Virat --

The Http3Transport would be used along with HTTP/3 datagrams, as described
in https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram

In Section 2 of that document, you will notice the addition of a flow
identifier:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Flow Identifier (i)                     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 HTTP/3 Datagram Payload (*)                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 3 describes how the flow identifier is to be allocated:

   Implementations of HTTP/3 that support the DATAGRAM extension MUST
   provide a flow identifier allocation service.  That service will
   allow applications co-located with HTTP/3 to request a unique flow
   identifier that they can subsequently use for their own purposes.
   The HTTP/3 implementation will then parse the flow identifier of
   incoming DATAGRAM frames and use it to deliver the frame to the
   appropriate application.

So in the case of a pooled Http3Transport, the flow identifier would
allow the datagrams to be de-multiplexed to the correct application.

In the event that an individual application utilizes multiple
datagrams flows, that application would need to include an additional
identifier within the "Datagram Payload".

Make sense?

On Tue, Jun 16, 2020 at 11:48 AM virat tara <virattara@gmail.com> wrote:

> Hi David,
>
> Thanks for the reply, I was talking in the context of this draft
> draft-ietf-webtrans-overview-00
> <https://tools.ietf.org/html/draft-ietf-webtrans-overview-00> (sorry for
> not mentioning it earlier) which mentions pooling as a property of the
> WebTransport. Actually, I was studying the ongoing work in WebTransport but
> didn't go through draft-vvv-webtransport-quic since it was expired. But
> yeah I got it now.
>
> I found 4 drafts related to this work.
> 1. draft-ietf-webtrans-overview-00
> 2. draft-vvv-webtransport-quic-01 / draft-vvv-webtransport-http3-01
> 3. draft-kinnear-webtransport-http2-00
>
> Where drafts under 2nd point are up for discussion as to which one to keep.
>
> Thanks,
> Virat
>
> On Tue, Jun 16, 2020 at 10:13 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> Hi Virat,
>>
>> What are you trying to demultiplex? draft-vvv-webtransport-quic  (as
>> currently specified) will create a new QUIC connection per
>> QuicTransport object, so there is no need to demultiplex between them. If
>> you would like to demultiplex different flows of datagrams in your own
>> application, then you can add a demultiplexing identifier of some kind at
>> the start of your application payload.
>>
>> Hope this helps,
>> David
>>
>> On Mon, Jun 15, 2020 at 10:52 AM virat tara <virattara@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> In *Section 6* "Transport Properties" there is a point mentioning
>>> Pooling Support. In case of unreliable datagrams, how will demultiplexing
>>> be done on the receiver end? Streams, on the other hand, have a unique
>>> stream ID. I found a draft (draft-schinazi-quic-h3-datagram-03
>>> <https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-03>) that
>>> accomplishes this on HTTP/3 but since WebTransport will have its own
>>> dedicated connection as mentioned in *Section 1.1 *"Background" how
>>> will this be taken forward?
>>>
>>> Thanks,
>>> Virat
>>> --
>>> Webtransport mailing list
>>> Webtransport@ietf.org
>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>
>> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>