Subject: [Webtransport] Does WebTransport need a reliable, in-order message abstraction? (fwd)

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Jul 2020 08:40:22 -0700

For some reason this message did not make it to the list.

---------- Forwarded message ----------
From: Alan Frindell <[email-masked]>
To: Webtransport <[email-masked]>
Cc:
Bcc:
Date: Fri, 24 Jul 2020 21:30:45 +0000
Subject: Does WebTransport need a reliable, in-order message abstraction?

I was reviewing the WebSocket specification, and realized there is a gap
that is not currently covered in the overview of WebTransport: reliable,
in-order messages.

The three ways to send messages in WebTransport are:

1) message per datagram, which is unreliable and unordered (and has a lower
maximum size than WebSockets)

2) message per stream, which is reliable but not ordered

3) multiple messages per stream, which is reliable and ordered, but not
framed

A developer either needs to implement their own framing layer on top of a
WebTransport stream (perhaps WebSocket over WebTransport?), or use message
per stream and handle buffering and ordering of messages at a higher layer.

Is replacing WebSockets with WebTransport one of our goals?  If so, I think
we need to address the gap by adding this abstraction.  If not, we should
explicitly mention that this abstraction doesn’t exist, and instruct
developers to use WebSocket instead.

-Alan

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Jul 2020 17:08:57 -0700

Alan said: 

> Is replacing WebSockets with WebTransport one of our goals?  If so, I think we need to address the gap by adding this abstraction.  If not, we should explicitly mention that this abstraction doesn’t exist, and instruct developers to use WebSocket instead.

[BA] Thanks for bringing this up.

When we first started on what would become the RTCQuicTransport API, the goal was to support all the transport modes of the RTCDataChannel API, which was modelled after WebSockets. 

However, we realized that this required design of a framing protocol on top of QUIC reliable streams. After verifying that a simple framing protocol was implementable as a JS library on top of the RTCQuicTransport prototype, providing many of the services of RTCDataChannel, the “proof of concept” was considered done and since then not much has happened.

This is a good example of how things can fall between the cracks of protocol design and API design. “Assume we have a framing protocol designed in IETF....”

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 26 Jul 2020 01:23:30 +0100

I think this question identifies a pretty interesting dynamic between
WebSocket and WebTransport. There is some overlap with the thread about
what protocols/fallbacks we want to implement.

Given the prevalence of WebSocket today, one might want to incentivise
people to switch to the same capability over WebTransport, but what would
that look like? What's the upgrade path here for devs that use a wss scheme
today? Perhaps some mapping of WebSockets, as they are used today, into
WebTransport would aid uptake and avoid relegating WebSockets to always be
stuck in their own isolated TCP connection (because the rollout of
WebSockets over H2 is limited)

Cheers
Lucas

On Sun, Jul 26, 2020 at 1:09 AM Bernard Aboba <[email-masked]>
wrote:

> Alan said:
>
> Is replacing WebSockets with WebTransport one of our goals?  If so, I
> think we need to address the gap by adding this abstraction.  If not, we
> should explicitly mention that this abstraction doesn’t exist, and instruct
> When we first started on what would become the RTCQuicTransport API, the
> goal was to support all the transport modes of the RTCDataChannel API,
> which was modelled after WebSockets.
>
> However, we realized that this required design of a framing protocol on
> top of QUIC reliable streams. After verifying that a simple framing
> protocol was implementable as a JS library on top of the RTCQuicTransport
> prototype, providing many of the services of RTCDataChannel, the “proof of
> concept” was considered done and since then not much has happened.
>
> This is a good example of how things can fall between the cracks of
> protocol design and API design. “Assume we have a framing protocol designed
> in IETF....”
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Lennart Grahl <[email-masked]>
Date: Mon, 27 Jul 2020 10:16:23 +0200

> This is a good example of how things can fall between the cracks of protocol design and API design. “Assume we have a framing protocol designed in IETF....”

Perhaps a clearly defined framing protocol for WebTransport on top of
those protocols that need it is not a bad idea if it's simple and easily
negotiable. But beyond that, I urge to always think about the
entry-barrier for non-web implementations before adding more protocols.
Because that was one of the top arguments when it came to why supporting
data channels and SCTP in non-web implementations is a problem.

But back to the "message" feature: I did make a proposal on that to make
the API future-proof for message streams (i.e. stream of byte stream):
https://github.com/WICG/web-transport/issues/49
If we do have a framing protocol, then it can be easily combined with
the API proposal.

And I want to emphasize again on the naming in the API. So far, these
are all byte steams we're talking about in the WebTransport API but when
adding "message" streams, this isn't clear any more. To quote myself in
above linked issue:

> [...] I think it makes sense to incorporate the type of stream into the interface in general to avoid confusion in a dynamically typed language (what kind of stream is this? a stream of bananas?) [...]

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Jul 2020 05:21:05 -0700

Thanks, Lennart.

"And I want to emphasize again on the naming in the API. So far, these
are all byte steams we're talking about in the WebTransport API but when
adding "message" streams, this isn't clear any more. To quote myself in
above linked issue:

> [...] I think it makes sense to incorporate the type of stream into the
interface in general to avoid confusion in a dynamically typed language
(what kind of stream is this? a stream of bananas?) [...]"

[BA] This problem exists now in the API document, even without support for
messages.

For example, receiveStreams() returns a ReadableStream of receiveStreams;
receiveBidirectionalStreams() returns a ReadableStream of
BidirectionalStreams; readDatagrams() returns a ReadableStream of
Uint8Arrays.  Yet the WebIDL just says "ReadableStream", with no indication
of the kind of stream returned.

On Mon, Jul 27, 2020 at 1:16 AM Lennart Grahl <[email-masked]>
wrote:

> > [...] I think it makes sense to incorporate the type of stream into the
> interface in general to avoid confusion in a dynamically typed language
> (what kind of stream is this? a stream of bananas?) [...]
>
> --