Hello, my name is Will Law.

I work at Akamai and I co-chair the W3C WebTransport Working Group, along with Jan-Ivar Bruaroey from Mozilla.

I want to talk to you today about WebTransport.

The story of WebTransport and the actions of our Working Group are intimately tied to that of real-time data.

So, I'd like to start with looking at the applications we might want to build on the web around real time data, and then perhaps motivate for you why we've needed to develop and work on WebTransport.

So some of the data applications spring to mind, obviously the video conferencing solutions that many of us access each day.

We'd like to build them using web tools with perhaps improved performance, privacy, and simplicity.

Game play and orchestration of game play data is another interesting field.

This data has to move very quickly between players and between the orchestration server.

There's also cloud game streaming in which the game is being rendered on the edge server and transmitted as a video stream up to the thin client.

There's also low latency video delivery.

This can be sports or news, our traditional broadcast type applications, and then perhaps the least attractive, but still important, cases of industrial cameras, security cameras, for example.

There's a lot of IOT sensor and analytics data that's moving, especially sequential data.

An example of that would be vehicle location.

Pub/sub messaging platforms, another interesting application for real-time data.

This data has to be reliable and in many cases ordered, but it's small in size compared to the video of the prior use cases.

And then interesting use case around real-time speech translation.

For example, my audio bytes could be being sent to a cloud service and we could get a stream of translated text characters in return.

Now, we have existing protocols on the web and in fact let's look at these and see how they might apply to build those real-time use cases that we talked about previously.

We have HTTP 1, 2, and 3 now.

These are excellent protocols.

They've been in place for over two decades and they've scaled tremendously, but they're primarily file-based.

You either get an object, you post an object that can be used to handle sequential flows, but they're non-optimum.

For those sequential flows of real-time data, we have two other protocols; WebSocket and WebRTC.

WebRTC is a collection or a stack of many different protocols that work together to provide the capabilities of peer-to-peer based communication.

Now if we look at WebSockets, it's a good protocol.

One of the problems, however, is that it exhibits head of line blocking.

And this means it's not a great application for ultra low latency or real time data transport.

WebRTC is also built upon a foundation of P2P and many times we want the capabilities of components within WebRTC but we don't necessarily want or need to use the entire stack that comes with it.

Relevant to this discussion is talk about specialization and unbundling.

And bear with me while I give you an analogy here and then I'll get back to WebRTC.

So let's imagine you go to the car dealership and you buy a car.

That car is a lot of complex engineering built for you.

It all works together.

You can get into it without understanding how it works and drive off, and it will be reliable.

However, if we could decompose that car into its components, say the electronics, the chassis, the engine, the tires, then we could build specialized versions of that car, each a better fit for their use case, than the one size fits all car.

So let's take this notion of unbundling for specialization and look at can we unbundle what's inside WebRTC?

If we could do that, we could build really specialized real-time applications.

But for that to happen we need flexible codec support because codecs are baked into the WebRTC stack.

And for that we have the W3C Web Codecs initiative.

And in fact I believe there's an update being given at the same AC meeting on that.

We have a need for computer intensive logic, especially around encoding.

For that we have W3C WebAssembly.

We need peer to peer connection establishment, but there's not really a good alternative for that, but we can avoid it because most of the applications out there, even the video conferencing ones, in fact, operate in a client-to-server mode.

So, we carry a lot of overhead for establishing a P2P connection when in fact, we could have been a much faster, simpler connection between a client and a server.

And then lastly, we need a way to send secure streams of real-time data.

And that brings us to a new standardized real-time transport for the web.

So the aspiration of WebTransport is to address the real-time data problem for the internet.

WebTransport is a transport protocol that's specified by the IETF and a web API that's specified here at the W3C that enables clients operating under the web security model to communicate with a remote server using a secure multiplexed real-time transport.

WebTransport out of the box will give you multiple unidirectional and bi-directional streams of reliable and ordered data.

I'm going to explain in a separate slide what that means.

It also gives you an unreliable flow of UDP-like datagrams.

Now these are not exactly the datagrams that are in UDP; the datagrams within WebTransport differ in that they're encrypted and that they're subject to congestion control.

They do carry data payloads of approximately the same size.

And WebTransport is designed to operate over HTTP/3 with a fallback to HTTP/2.

So if the data flow encounters a network that can not support QUIC, for example, then your application will still continue to work, even though it might work a little slower.

The network stack of WebTransport is shown in the upper right.

You can see that WebTransport is built on top of HTTP3Transport itself built on top of HTTP/3, which is built on top of QUIC, which incorporates TLS 1.3 and all built on top of the UDP for global compatibility.

The WebTransport modes are interesting, the transfer modes rather, and I want to briefly explain and highlight some differences between them.

So let's model our WebTransport connection as a pipe between a server on the left and the client on the right.

And within this pipe I'm sending streams of data.

The first stream, stream number one, I'm putting objects in numbered one, two, and three, from the server.

And on the client side I receive them in the same order that they were sent.

So this is ordered and reliable flow within the stream.

Within the datagrams, I'm putting in much smaller objects, four, five and six.

And on the client I'm only receiving six and four and I've lost one.

So this is unordered and unreliable flow, but it's very fast, which is the attraction of datagrams.

The last two examples, streams two and three, I am sharding a set of purple objects, seven, eight, nine and 10 across the two streams.

We noticed that as the client receives them in stream number two, they arrive in order, and they're reliable.

However, the order is not guaranteed between streams.

We refer to this mode as partial reliability, and it turns out to be very useful for sending video frames, for example, because it avoids head of line blocking within any one particular stream.

So, there is an API that exists for this.

It's quite exciting.

So, we can access all of this functionality from within a browser user agent.

The API URL is given here and it's in public Working Draft status as we speak.

It is offered on the secure context only as are most modern APIs, especially those concerning audio and video.

The API leverages modern web platform primitives such as streams and promises, and it works well with programming functions such as async and await which programmers prefer.

The URLs, in case you're interested, for a WebTransport connection must begin with HTTPS for the protocol designator.

And they also must specify the port that is being connected to on the server side.

It is a client-initiated connection.

And lastly it can run in Web Workers, which is quite exciting.

It allows us to develop multithreaded applications which can deliver higher performance.

I'm going to show you four code examples now.

You may not write code yourself, but even if you don't, you can take away with you the notion that it's a relatively simple API that exposes some quite powerful features.

In our first example we want to send a buffer of datagrams.

So, in my yellow code block I basically instantiate my WebTransport connection.

In the pink block I wait for a writer on the datagrams object and once the writer is available I loop through my datagram array and I write my datagrams into that writer; relatively simple.

On the receiving side then, even simpler; instantiate my WebTransport connection.

And then in the pink I access the readable object on the datagrams interface of the WebTransport instance and I'm simply able to process my datagrams as they are received.

Now, what if I want to send data over stream instead of over datagrams?

Well, in this case, in the yellow I create my WebTransport connection once again.

I create a unidirectional stream and I could have created a bi-directional stream as well.

Bi-directional streams are simply unidirectional streams in opposite directions.

I get a writer on that unidirectional stream.

I write my data object to it, and then I close the writer.

And the last code example shows receiving that stream on the other end and perhaps leveraging piping, which is quite exciting.

So in this hypothetical example we create our WebTransport connection and then we await an incoming stream.

We're going to process these incoming streams one by one.

I await the readable object, readable interface on the unidirectional stream, and then I'm able to pipe the incoming data, in this case through a text decoder stream, so again, an array of bytes, it's transferred into an array of characters, and I then pipe those into a destination that can handle that stream of characters.

It might be a closed caption display, for example.

So all in all, a readily accessible API that I think people will be quite excited to use.

We encourage you to give it a try.

We have some server examples now; the AIOQuic open-source library will be used as a basis for the Web Platform Tests, and a link to a server example there if you want to experiment with WebTransport.

Google Chrome has also stood up a separate WebTransport server example leveraging the same library.

And on the client side, Chrome has supported an origin trial of WebTransports since 84.

So there's a public relatively simple demo as I show a screenshot on the right, along with links to a client demo.

The status as of September, 2021: Chrome had signaled intent to ship WebTransport around the November 21 timeframe.

Firefox are implementing but have not yet announced a release date.

There's going to be an echo server, a simple server available for Web Platform Tests.

This will be publicly accessible and it should be available very shortly.

And we encourage experimentation; this is the perfect time, especially on the API side, to get our group feedback.

You can file a GitHub issue at the link provided in the slides here.

In summary then, WebTransport is addressing or solving the real-time data problem for the internet.

It's a collaboration between the IETF and the W3C.

It gives you unidirectional, bi-directional streams of data, as well as an unreliable flow of UDP-like datagrams.

It uses modern web platforms features and primitives, and we have an API available in Working Draft status, and we encourage you to experiment with it and provide us feedback.

We look forward to building something great for real-time data on the web.

Thank you.