Re: [Webtransport] Demultiplexing in case of unreliable datagrams

[virat tara <[e-mail]>]

Got it, thanks!

On Wed, Jun 17, 2020 at 2:33 AM Bernard Aboba <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>
>>> --
>> Webtransport mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
>