WEBVTT slide-1 00:00:01.440 --> 00:00:03.140 Hello, my name is Will Law. 2 00:00:03.140 --> 00:00:04.936 I work at Akamai and I co-chair 3 00:00:04.936 --> 00:00:08.170 the W3C WebTransport Working Group, 4 00:00:08.170 --> 00:00:11.810 along with Jan-Ivar Bruaroey from Mozilla. 5 00:00:11.810 --> 00:00:14.420 I want to talk to you today about WebTransport. 6 00:00:14.420 --> 00:00:16.160 The story of WebTransport and the actions 7 00:00:16.160 --> 00:00:17.170 of our Working Group 8 00:00:17.170 --> 00:00:20.790 are intimately tied to that of real-time data. slide-2 00:00:20.790 --> 00:00:23.310 So, I'd like to start with looking at the applications 10 00:00:23.310 --> 00:00:26.250 we might want to build on the web around real time data, 11 00:00:26.250 --> 00:00:28.270 and then perhaps motivate for you 12 00:00:28.270 --> 00:00:32.600 why we've needed to develop and work on WebTransport. next-2.1 00:00:32.600 --> 00:00:34.730 So some of the data applications spring to mind, 14 00:00:34.730 --> 00:00:36.690 obviously the video conferencing solutions 15 00:00:36.690 --> 00:00:39.200 that many of us access each day. 16 00:00:39.200 --> 00:00:41.270 We'd like to build them using web tools 17 00:00:41.270 --> 00:00:46.270 with perhaps improved performance, privacy, and simplicity. next-2.2 00:00:46.460 --> 00:00:49.520 Game play and orchestration of game play data 19 00:00:49.520 --> 00:00:51.110 is another interesting field. 20 00:00:51.110 --> 00:00:53.170 This data has to move very quickly 21 00:00:53.170 --> 00:00:56.300 between players and between the orchestration server. next-2.3 00:00:56.300 --> 00:00:58.390 There's also cloud game streaming in which the game 23 00:00:58.390 --> 00:01:00.390 is being rendered on the edge server 24 00:01:00.390 --> 00:01:04.720 and transmitted as a video stream up to the thin client. next-2.4 00:01:04.720 --> 00:01:06.590 There's also low latency video delivery. 26 00:01:06.590 --> 00:01:07.840 This can be sports or news, 27 00:01:07.840 --> 00:01:10.460 our traditional broadcast type applications, 28 00:01:10.460 --> 00:01:12.130 and then perhaps the least attractive, 29 00:01:12.130 --> 00:01:14.860 but still important, cases of industrial cameras, next-2.5 00:01:14.860 --> 00:01:17.030 security cameras, for example. 31 00:01:17.030 --> 00:01:20.770 There's a lot of IOT sensor and analytics data 32 00:01:20.770 --> 00:01:23.000 that's moving, especially sequential data. 33 00:01:23.000 --> 00:01:26.443 An example of that would be vehicle location. next-2.6 00:01:27.530 --> 00:01:28.970 Pub/sub messaging platforms, 35 00:01:28.970 --> 00:01:31.310 another interesting application for real-time data. 36 00:01:31.310 --> 00:01:35.130 This data has to be reliable and in many cases ordered, 37 00:01:35.130 --> 00:01:36.910 but it's small in size compared to the video 38 00:01:36.910 --> 00:01:38.980 of the prior use cases. next-2.7 00:01:38.980 --> 00:01:40.380 And then interesting use case 40 00:01:40.380 --> 00:01:42.140 around real-time speech translation. 41 00:01:42.140 --> 00:01:42.973 For example, 42 00:01:42.973 --> 00:01:45.960 my audio bytes could be being sent to a cloud service 43 00:01:45.960 --> 00:01:49.010 and we could get a stream of translated text characters 44 00:01:49.010 --> 00:01:49.943 in return. slide-3 00:01:51.370 --> 00:01:53.900 Now, we have existing protocols on the web 46 00:01:53.900 --> 00:01:54.860 and in fact 47 00:01:54.860 --> 00:01:56.882 let's look at these and see how they might apply 48 00:01:56.882 --> 00:01:58.990 to build those real-time use cases 49 00:01:58.990 --> 00:02:00.933 that we talked about previously. next-3.1 00:02:01.840 --> 00:02:04.646 We have HTTP 1, 2, and 3 now. 51 00:02:04.646 --> 00:02:07.140 These are excellent protocols. 52 00:02:07.140 --> 00:02:09.320 They've been in place for over two decades 53 00:02:09.320 --> 00:02:11.220 and they've scaled tremendously, 54 00:02:11.220 --> 00:02:12.684 but they're primarily file-based. 55 00:02:12.684 --> 00:02:14.070 You either get an object, 56 00:02:14.070 --> 00:02:17.190 you post an object that can be used 57 00:02:17.190 --> 00:02:19.900 to handle sequential flows, but they're non-optimum. 58 00:02:19.900 --> 00:02:23.160 For those sequential flows of real-time data, next-3.2 00:02:23.160 --> 00:02:24.399 we have two other protocols; 60 00:02:24.399 --> 00:02:26.610 WebSocket and WebRTC. 61 00:02:26.610 --> 00:02:28.770 WebRTC is a collection or a stack 62 00:02:28.770 --> 00:02:30.380 of many different protocols 63 00:02:30.380 --> 00:02:33.370 that work together to provide the capabilities 64 00:02:33.370 --> 00:02:35.980 of peer-to-peer based communication. 65 00:02:35.980 --> 00:02:37.801 Now if we look at WebSockets, 66 00:02:37.801 --> 00:02:39.300 it's a good protocol. next-3.3 00:02:39.300 --> 00:02:40.910 One of the problems, however, 68 00:02:40.910 --> 00:02:43.430 is that it exhibits head of line blocking. 69 00:02:43.430 --> 00:02:46.220 And this means it's not a great application 70 00:02:46.220 --> 00:02:50.150 for ultra low latency or real time data transport. next-3.4 00:02:50.150 --> 00:02:54.610 WebRTC is also built upon a foundation of P2P 72 00:02:54.610 --> 00:02:55.860 and many times 73 00:02:55.860 --> 00:02:59.750 we want the capabilities of components within WebRTC 74 00:02:59.750 --> 00:03:02.160 but we don't necessarily want or need 75 00:03:02.160 --> 00:03:04.483 to use the entire stack that comes with it. slide-4 00:03:07.440 --> 00:03:08.930 Relevant to this discussion is 77 00:03:08.930 --> 00:03:11.280 talk about specialization and unbundling. 78 00:03:11.280 --> 00:03:13.200 And bear with me while I give you an analogy here 79 00:03:13.200 --> 00:03:15.110 and then I'll get back to WebRTC. next-4.1 00:03:15.110 --> 00:03:17.160 So let's imagine you go to the car dealership 81 00:03:17.160 --> 00:03:17.993 and you buy a car. 82 00:03:17.993 --> 00:03:21.770 That car is a lot of complex engineering built for you. 83 00:03:21.770 --> 00:03:22.870 It all works together. 84 00:03:22.870 --> 00:03:24.572 You can get into it without understanding 85 00:03:24.572 --> 00:03:28.160 how it works and drive off, and it will be reliable. next-4.2 00:03:28.160 --> 00:03:32.530 However, if we could decompose that car into its components, 87 00:03:32.530 --> 00:03:35.740 say the electronics, the chassis, the engine, the tires, next-4.3 00:03:35.740 --> 00:03:38.700 then we could build specialized versions of that car, 89 00:03:38.700 --> 00:03:40.880 each a better fit for their use case, 90 00:03:40.880 --> 00:03:42.723 than the one size fits all car. slide-5 00:03:43.690 --> 00:03:46.610 So let's take this notion of unbundling for specialization 92 00:03:46.610 --> 00:03:47.443 and look at 93 00:03:47.443 --> 00:03:50.340 can we unbundle what's inside WebRTC? 94 00:03:50.340 --> 00:03:51.200 If we could do that, 95 00:03:51.200 --> 00:03:54.840 we could build really specialized real-time applications. next-5.1 00:03:54.840 --> 00:03:56.420 But for that to happen 97 00:03:56.420 --> 00:03:57.870 we need flexible codec support 98 00:03:57.870 --> 00:04:00.610 because codecs are baked into the WebRTC stack. 99 00:04:00.610 --> 00:04:01.443 And for that 100 00:04:01.443 --> 00:04:04.340 we have the W3C Web Codecs initiative. 101 00:04:04.340 --> 00:04:05.173 And in fact 102 00:04:05.173 --> 00:04:06.270 I believe there's an update being given 103 00:04:06.270 --> 00:04:09.060 at the same AC meeting on that. next-5.2 00:04:09.060 --> 00:04:10.940 We have a need for computer intensive logic, 105 00:04:10.940 --> 00:04:12.410 especially around encoding. 106 00:04:12.410 --> 00:04:14.633 For that we have W3C WebAssembly. next-5.3 00:04:15.740 --> 00:04:17.810 We need peer to peer connection establishment, 108 00:04:17.810 --> 00:04:21.060 but there's not really a good alternative for that, 109 00:04:21.060 --> 00:04:22.160 but we can avoid it 110 00:04:22.160 --> 00:04:24.500 because most of the applications out there, 111 00:04:24.500 --> 00:04:26.290 even the video conferencing ones, 112 00:04:26.290 --> 00:04:28.870 in fact, operate in a client-to-server mode. 113 00:04:28.870 --> 00:04:30.870 So, we carry a lot of overhead for establishing 114 00:04:30.870 --> 00:04:32.780 a P2P connection when in fact, 115 00:04:32.780 --> 00:04:35.230 we could have been a much faster, simpler connection 116 00:04:35.230 --> 00:04:37.180 between a client and a server. 117 00:04:37.180 --> 00:04:38.013 And then lastly, next-5.4 00:04:38.013 --> 00:04:41.070 we need a way to send secure streams of real-time data. 119 00:04:41.070 --> 00:04:45.100 And that brings us to a new standardized real-time transport 120 00:04:45.100 --> 00:04:46.193 for the web. slide-6 00:04:48.280 --> 00:04:51.500 So the aspiration of WebTransport is to address 122 00:04:51.500 --> 00:04:54.625 the real-time data problem for the internet. 123 00:04:54.625 --> 00:04:56.670 WebTransport is a transport protocol 124 00:04:56.670 --> 00:05:00.150 that's specified by the IETF and a web API 125 00:05:00.150 --> 00:05:02.550 that's specified here at the W3C 126 00:05:02.550 --> 00:05:05.810 that enables clients operating under the web security model 127 00:05:05.810 --> 00:05:07.840 to communicate with a remote server 128 00:05:07.840 --> 00:05:11.033 using a secure multiplexed real-time transport. 129 00:05:11.905 --> 00:05:13.390 WebTransport out of the box 130 00:05:13.390 --> 00:05:15.770 will give you multiple unidirectional 131 00:05:15.770 --> 00:05:19.890 and bi-directional streams of reliable and ordered data. 132 00:05:19.890 --> 00:05:22.910 I'm going to explain in a separate slide what that means. 133 00:05:22.910 --> 00:05:27.030 It also gives you an unreliable flow of UDP-like datagrams. 134 00:05:27.030 --> 00:05:30.490 Now these are not exactly the datagrams that are in UDP; 135 00:05:30.490 --> 00:05:32.550 the datagrams within WebTransport differ 136 00:05:32.550 --> 00:05:33.940 in that they're encrypted 137 00:05:33.940 --> 00:05:36.380 and that they're subject to congestion control. 138 00:05:36.380 --> 00:05:39.393 They do carry data payloads of approximately the same size. 139 00:05:40.540 --> 00:05:42.804 And WebTransport is designed to operate 140 00:05:42.804 --> 00:05:46.590 over HTTP/3 with a fallback to HTTP/2. 141 00:05:46.590 --> 00:05:48.290 So if the data flow encounters 142 00:05:48.290 --> 00:05:51.030 a network that can not support QUIC, for example, 143 00:05:51.030 --> 00:05:53.450 then your application will still continue to work, 144 00:05:53.450 --> 00:05:56.000 even though it might work a little slower. 145 00:05:56.000 --> 00:05:57.970 The network stack of WebTransport is shown 146 00:05:57.970 --> 00:05:59.110 in the upper right. 147 00:05:59.110 --> 00:06:00.890 You can see that WebTransport is built 148 00:06:00.890 --> 00:06:05.590 on top of HTTP3Transport itself built on top of HTTP/3, 149 00:06:05.590 --> 00:06:07.370 which is built on top of QUIC, 150 00:06:07.370 --> 00:06:09.570 which incorporates TLS 1.3 151 00:06:09.570 --> 00:06:13.053 and all built on top of the UDP for global compatibility. slide-7 00:06:15.170 --> 00:06:17.510 The WebTransport modes are interesting, 153 00:06:17.510 --> 00:06:18.790 the transfer modes rather, 154 00:06:18.790 --> 00:06:20.900 and I want to briefly explain and highlight 155 00:06:20.900 --> 00:06:22.450 some differences between them. 156 00:06:22.450 --> 00:06:26.129 So let's model our WebTransport connection as a pipe 157 00:06:26.129 --> 00:06:28.300 between a server on the left 158 00:06:28.300 --> 00:06:30.000 and the client on the right. 159 00:06:30.000 --> 00:06:30.920 And within this pipe 160 00:06:30.920 --> 00:06:33.050 I'm sending streams of data. 161 00:06:33.050 --> 00:06:33.883 The first stream, 162 00:06:33.883 --> 00:06:34.716 stream number one, 163 00:06:34.716 --> 00:06:37.180 I'm putting objects in numbered one, two, and three, 164 00:06:37.180 --> 00:06:38.440 from the server. 165 00:06:38.440 --> 00:06:39.410 And on the client side 166 00:06:39.410 --> 00:06:42.240 I receive them in the same order that they were sent. 167 00:06:42.240 --> 00:06:45.760 So this is ordered and reliable flow within the stream. 168 00:06:45.760 --> 00:06:47.590 Within the datagrams, 169 00:06:47.590 --> 00:06:50.310 I'm putting in much smaller objects, four, five and six. 170 00:06:50.310 --> 00:06:52.730 And on the client I'm only receiving six and four 171 00:06:52.730 --> 00:06:54.040 and I've lost one. 172 00:06:54.040 --> 00:06:56.770 So this is unordered and unreliable flow, 173 00:06:56.770 --> 00:06:57.960 but it's very fast, 174 00:06:57.960 --> 00:07:00.620 which is the attraction of datagrams. 175 00:07:00.620 --> 00:07:03.350 The last two examples, streams two and three, 176 00:07:03.350 --> 00:07:05.850 I am sharding a set of purple objects, 177 00:07:05.850 --> 00:07:08.560 seven, eight, nine and 10 across the two streams. 178 00:07:08.560 --> 00:07:09.394 We noticed that 179 00:07:09.394 --> 00:07:12.470 as the client receives them in stream number two, 180 00:07:12.470 --> 00:07:13.985 they arrive in order, 181 00:07:13.985 --> 00:07:15.617 and they're reliable. 182 00:07:15.617 --> 00:07:19.380 However, the order is not guaranteed between streams. 183 00:07:19.380 --> 00:07:21.680 We refer to this mode as partial reliability, 184 00:07:21.680 --> 00:07:24.980 and it turns out to be very useful for sending video frames, 185 00:07:24.980 --> 00:07:25.813 for example, 186 00:07:25.813 --> 00:07:27.610 because it avoids head of line blocking 187 00:07:27.610 --> 00:07:29.953 within any one particular stream. slide-8 00:07:32.800 --> 00:07:34.890 So, there is an API that exists for this. 189 00:07:34.890 --> 00:07:36.440 It's quite exciting. 190 00:07:36.440 --> 00:07:38.440 So, we can access all of this functionality next-8.1 00:07:38.440 --> 00:07:40.760 from within a browser user agent. 192 00:07:40.760 --> 00:07:42.500 The API URL is given here 193 00:07:42.500 --> 00:07:45.920 and it's in public Working Draft status as we speak. next-8.2 00:07:45.920 --> 00:07:48.010 It is offered on the secure context only 195 00:07:48.010 --> 00:07:50.651 as are most modern APIs, 196 00:07:50.651 --> 00:07:54.323 especially those concerning audio and video. next-8.3 00:07:55.180 --> 00:07:58.400 The API leverages modern web platform primitives 198 00:07:58.400 --> 00:07:59.760 such as streams and promises, 199 00:07:59.760 --> 00:08:02.730 and it works well with programming functions 200 00:08:02.730 --> 00:08:04.400 such as async and await 201 00:08:04.400 --> 00:08:06.270 which programmers prefer. next-8.4 00:08:06.270 --> 00:08:07.760 The URLs, in case you're interested, 203 00:08:07.760 --> 00:08:09.030 for a WebTransport connection 204 00:08:09.030 --> 00:08:12.140 must begin with HTTPS for the protocol designator. 205 00:08:12.140 --> 00:08:14.170 And they also must specify the port 206 00:08:14.170 --> 00:08:17.060 that is being connected to on the server side. 207 00:08:17.060 --> 00:08:19.223 It is a client-initiated connection. next-8.5 00:08:22.130 --> 00:08:23.750 And lastly it can run in Web Workers, 209 00:08:23.750 --> 00:08:24.700 which is quite exciting. 210 00:08:24.700 --> 00:08:27.190 It allows us to develop multithreaded applications 211 00:08:27.190 --> 00:08:29.253 which can deliver higher performance. slide-9 00:08:31.510 --> 00:08:33.720 I'm going to show you four code examples now. 213 00:08:33.720 --> 00:08:35.850 You may not write code yourself, 214 00:08:35.850 --> 00:08:36.760 but even if you don't, 215 00:08:36.760 --> 00:08:38.480 you can take away with you the notion 216 00:08:38.480 --> 00:08:40.664 that it's a relatively simple API 217 00:08:40.664 --> 00:08:43.890 that exposes some quite powerful features. 218 00:08:43.890 --> 00:08:44.850 In our first example 219 00:08:44.850 --> 00:08:47.410 we want to send a buffer of datagrams. 220 00:08:47.410 --> 00:08:49.210 So, in my yellow code block 221 00:08:49.210 --> 00:08:52.410 I basically instantiate my WebTransport connection. 222 00:08:52.410 --> 00:08:53.680 In the pink block 223 00:08:53.680 --> 00:08:56.800 I wait for a writer on the datagrams object 224 00:08:56.800 --> 00:08:58.290 and once the writer is available 225 00:08:58.290 --> 00:09:00.340 I loop through my datagram array 226 00:09:00.340 --> 00:09:03.060 and I write my datagrams into that writer; 227 00:09:03.060 --> 00:09:04.793 relatively simple. slide-10 00:09:07.220 --> 00:09:08.640 On the receiving side then, 229 00:09:08.640 --> 00:09:11.786 even simpler; instantiate my WebTransport connection. 230 00:09:11.786 --> 00:09:13.956 And then in the pink 231 00:09:13.956 --> 00:09:16.830 I access the readable object on the datagrams interface 232 00:09:16.830 --> 00:09:18.970 of the WebTransport instance 233 00:09:18.970 --> 00:09:21.570 and I'm simply able to process my datagrams 234 00:09:21.570 --> 00:09:22.803 as they are received. slide-11 00:09:25.210 --> 00:09:27.480 Now, what if I want to send data over stream 236 00:09:27.480 --> 00:09:28.620 instead of over datagrams? 237 00:09:28.620 --> 00:09:29.453 Well, in this case, 238 00:09:29.453 --> 00:09:30.286 in the yellow 239 00:09:30.286 --> 00:09:32.700 I create my WebTransport connection once again. 240 00:09:32.700 --> 00:09:34.877 I create a unidirectional stream 241 00:09:34.877 --> 00:09:37.480 and I could have created a bi-directional stream as well. 242 00:09:37.480 --> 00:09:40.650 Bi-directional streams are simply unidirectional streams 243 00:09:40.650 --> 00:09:41.863 in opposite directions. 244 00:09:43.200 --> 00:09:46.110 I get a writer on that unidirectional stream. 245 00:09:46.110 --> 00:09:47.590 I write my data object to it, 246 00:09:47.590 --> 00:09:48.990 and then I close the writer. slide-12 00:09:51.220 --> 00:09:53.620 And the last code example shows receiving that stream 248 00:09:53.620 --> 00:09:55.700 on the other end and perhaps leveraging piping, 249 00:09:55.700 --> 00:09:57.490 which is quite exciting. 250 00:09:57.490 --> 00:09:59.070 So in this hypothetical example 251 00:09:59.070 --> 00:10:01.330 we create our WebTransport connection 252 00:10:01.330 --> 00:10:03.170 and then we await an incoming stream. 253 00:10:03.170 --> 00:10:06.394 We're going to process these incoming streams one by one. 254 00:10:06.394 --> 00:10:08.710 I await the readable object, 255 00:10:08.710 --> 00:10:11.650 readable interface on the unidirectional stream, 256 00:10:11.650 --> 00:10:14.750 and then I'm able to pipe the incoming data, 257 00:10:14.750 --> 00:10:16.730 in this case through a text decoder stream, 258 00:10:16.730 --> 00:10:17.563 so again, 259 00:10:17.563 --> 00:10:18.396 an array of bytes, 260 00:10:18.396 --> 00:10:19.950 it's transferred into an array of characters, 261 00:10:19.950 --> 00:10:22.630 and I then pipe those into a destination 262 00:10:22.630 --> 00:10:24.260 that can handle that stream of characters. 263 00:10:24.260 --> 00:10:26.793 It might be a closed caption display, for example. 264 00:10:28.660 --> 00:10:29.493 So all in all, 265 00:10:29.493 --> 00:10:30.930 a readily accessible API 266 00:10:30.930 --> 00:10:33.510 that I think people will be quite excited to use. slide-13 00:10:33.510 --> 00:10:35.010 We encourage you to give it a try. 268 00:10:35.010 --> 00:10:37.180 We have some server examples now; 269 00:10:37.180 --> 00:10:40.080 the AIOQuic open-source library 270 00:10:40.080 --> 00:10:42.440 will be used as a basis for the Web Platform Tests, 271 00:10:42.440 --> 00:10:44.950 and a link to a server example there 272 00:10:44.950 --> 00:10:47.510 if you want to experiment with WebTransport. 273 00:10:47.510 --> 00:10:49.070 Google Chrome has also stood up 274 00:10:49.070 --> 00:10:52.080 a separate WebTransport server example 275 00:10:52.080 --> 00:10:53.700 leveraging the same library. 276 00:10:53.700 --> 00:10:54.830 And on the client side, 277 00:10:54.830 --> 00:10:57.790 Chrome has supported an origin trial of WebTransports 278 00:10:57.790 --> 00:10:59.079 since 84. 279 00:10:59.079 --> 00:11:03.970 So there's a public relatively simple demo 280 00:11:03.970 --> 00:11:05.850 as I show a screenshot on the right, 281 00:11:05.850 --> 00:11:07.993 along with links to a client demo. slide-14 00:11:10.690 --> 00:11:13.200 The status as of September, 2021: 283 00:11:13.200 --> 00:11:15.770 Chrome had signaled intent to ship WebTransport 284 00:11:15.770 --> 00:11:18.960 around the November 21 timeframe. 285 00:11:18.960 --> 00:11:20.380 Firefox are implementing 286 00:11:20.380 --> 00:11:23.180 but have not yet announced a release date. 287 00:11:23.180 --> 00:11:24.490 There's going to be an echo server, 288 00:11:24.490 --> 00:11:26.940 a simple server available for Web Platform Tests. 289 00:11:26.940 --> 00:11:28.730 This will be publicly accessible 290 00:11:28.730 --> 00:11:31.930 and it should be available very shortly. 291 00:11:31.930 --> 00:11:33.740 And we encourage experimentation; 292 00:11:33.740 --> 00:11:35.070 this is the perfect time, 293 00:11:35.070 --> 00:11:36.330 especially on the API side, 294 00:11:36.330 --> 00:11:38.490 to get our group feedback. 295 00:11:38.490 --> 00:11:40.970 You can file a GitHub issue at the link provided 296 00:11:40.970 --> 00:11:41.920 in the slides here. slide-15 00:11:44.120 --> 00:11:45.070 In summary then, 298 00:11:45.070 --> 00:11:46.610 WebTransport is addressing 299 00:11:46.610 --> 00:11:49.960 or solving the real-time data problem for the internet. 300 00:11:49.960 --> 00:11:53.970 It's a collaboration between the IETF and the W3C. 301 00:11:53.970 --> 00:11:56.860 It gives you unidirectional, bi-directional streams of data, 302 00:11:56.860 --> 00:12:00.870 as well as an unreliable flow of UDP-like datagrams. 303 00:12:00.870 --> 00:12:04.110 It uses modern web platforms features and primitives, 304 00:12:04.110 --> 00:12:07.140 and we have an API available in Working Draft status, 305 00:12:07.140 --> 00:12:09.610 and we encourage you to experiment with it 306 00:12:09.610 --> 00:12:11.250 and provide us feedback. 307 00:12:11.250 --> 00:12:12.930 We look forward to building something great 308 00:12:12.930 --> 00:12:15.290 for real-time data on the web. 309 00:12:15.290 --> 00:12:16.123 Thank you.