[Webtransport] My thoughts on protocol selection

[Martin Thomson <[e-mail]>]

As the interim is at a time that is hazardous to my health, I thought I would share my opinions via email ahead of the meeting.  I will try to be provide explicit positions and rationale for those positions.

The goal is to choose which protocols will support the API.  We've been presented with a matrix of 4 options.  On one axis, there are two UDP/QUIC-based options and two TCP-based options.  On the other, there are two options that pool webtransport communications (with itself or HTTP), and two options that require a new connection for each session/context/thingie.  I understand that the non-pooled TCP option is less well defined than other options.

My preference is to select a non-pooled option with a websocket-based fallback.  I can live with a pooled approach.

I can see the merits of a pooled approach, both in terms of flexibility, transport use, and other factors.  However, I think that the primary advantage of a non-pooled option is simplicity.  Implementation complexity is only a small piece, I'm mostly concerned about ensuring that this is a good fit for the sorts of deployment architectures that are used by most web developers.  My own experience deploying websockets, though admittedly a little dated now, shows that most developers don't share infrastructure with web hosting.   Furthermore, there are more complications to deal with if we touch HTTP: managing inter-protocol prioritization, which would be necessary to address in a pooled context, is non-trivial both from a protocol design perspective and challenging to deploy; identifying connections with URIs in websockets turned out to be a major problem; and likely other issues.  I'm confident that the complexities of a pooled approach can be overcome, but I tend to think that that choice would disproportionately privilege entities with greater engineering resources.  It would also take longer to standardize.

At the time I write this, Victor hasn't filled in his argument for why a non-pooled protocol implementation is like a pooled implementation, so I can't respond to that directly.  Implementation of webtransport in a browser is likely as weird and atypical as anything else in browser-land, so I'm not anticipating anything revelatory.

No doubt there is a lot more ground to cover here.  Intermediation options for websockets are poor (though not non-existent despite some assertions I've heard) and webtransport is almost certainly the same.  I acknowledge the fact that not addressing pooling could push toward proprietary load balancing/aggregation designs.  However, the primary problem is not lack of intermediation designs at the protocol layer, but the inability of intermediaries to interact with the semantics of the data that is being exchanged.  This is a problem at a level that this working group is not able to deal with.  We should be prepared to deal with any lower-layer intermediation options that arise as we learn more about how this is being deployed, but that is all.

I think that fallback is necessary.  It is true that many large entities and incumbents will have existing infrastructure that they can fall back on, such that they can treat webtransport as just a way to access a better-performing transport.  However, not providing fallback would mean that we're making a deliberate decision to privilege those parties.  As much as not dealing with TCP would be easy, I have become convinced that to not provide a fallback would also be irresponsible.

The specific shape of fallback I am thinking of is a websocket connection that uses a newly defined "webtransport" (or "wt") subprotocol.  This subprotocol will need new affordances for unidirectional streams and datagrams and some way to manage layering streams over the message-based abstraction.  Neither of those should be particularly difficult to manage.

I am opposed to developing more than the two protocols necessary for high performance (UDP) and fallback (TCP).  I'm prepared for time to prove me wrong, but I would prefer to come to that realization through experience.

In reviewing slides, I see that Victor has proposed a new URI scheme.  I think that this is sensible.  Not so much for the stated reasons, which are fine, but more because it means we can use SVCB.  We might even consider disallowing the use of A/AAAA with this new protocol.  The one problem I might anticipate with that is difficulty of doing local testing, but we're already hard-wiring localhost in other ways.

(Thanks to Bernard for sharing the unfinished slides with me ahead of time.)

---
Separately, the W3C group met last week and discussed requirements.  This is my recollection of the list, which is likely incomplete/wrong to some extent.

The group that met would like to ensure that datagram transport, or a simulation thereof, is available in all options.  Though performance degradation might occur in TCP, that is better than not having the mechanism.  Unless there is a stream-based substitute for datagrams (which I think would not be a good idea), connection attempts should fail if the QUIC datagram extension cannot be negotiated.

(The API will likely include a flag to disable fallback, but that is not necessarily a protocol-level concern.)

Some anti-requirements: The protocol MUST NOT carry HTTP state mechanisms: cookies, authentication.  The protocol MUST NOT use the same client-based certificates as HTTP.  Webtransport will need some way to integrate with CSP and other policy mechanisms, but that doesn't mean that it needs to inherit the state management burdens of HTTP on the web.

There was also a lot of discussion about bandwidth estimation for video delivery, but I think that the conclusion was that it was hard and it might need to be something we table for the moment.