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