Subject: [Webtransport] Demultiplexing in case of unreliable datagrams

From: virat tara <[email-masked]>
Date: Mon, 15 Jun 2020 23:21:54 +0530

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 16 Jun 2020 09:43:13 -0700

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 <[email-masked]> wrote:

> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: virat tara <[email-masked]>
Date: Wed, 17 Jun 2020 00:17:43 +0530

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 <[email-masked]>
wrote:

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jun 2020 14:03:45 -0700

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 <[email-masked]> wrote:

>>> dedicated connection as mentioned in *Section 1.1 *"Background" how
>>> will this be taken forward?
>>>
>>> Thanks,
>>> Virat
>>> --

---

From: virat tara <[email-masked]>
Date: Wed, 17 Jun 2020 13:36:49 +0530

Got it, thanks!

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

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