QUIC and WebRTC

0
174

In this session, Varun and Dan discuss some exciting new developments in the WebRTC standards space during TPAC 2017.

MP3 Download

Dan Burnett:
Hi, this is Dan Burnett with AllThingsRTC, and Varun Singh from callstats.io, and we’re here at the W3C TPAC meeting in California. This is where the WebRTC standards group meets. So we just spent literally the last two days doing that. I think it was a pretty good meeting.

Varun Singh:
It was an awesome meeting. We actually got a lot of stuff done. I think the major thing was the fact that we’re close to Candidate Recommendation for both the WebRTC Peer Connection and the Stats [API].

Dan Burnett:
Right. We officially had CR for the Peer Connection already, the first Candidate Recommendation … We may have to do another, but still it’s a big step, exactly.

Varun Singh:
Then, we think that, in the next year or less, we’ll be at Proposed Recommendation.

Dan Burnett:
Yes, I think there’s a very good chance of that.

Varun Singh:
And that’s basically a big milestone for us because, from now on in, only major bug fixes? If I understood correctly.

Dan Burnett:
That’s right.

Varun Singh:
And a lot more effort on testing.

Dan Burnett:
Yes, there are not supposed to be any major feature changes. It’s supposed to be mainly clarifications. I’m sure we’ll have some things we need to fix … Again, you know, bug related, that may change normative behavior, but it was really only supposed to be that and not feature changes.

Varun Singh:
And that will mainly come from the implementation experience.

Dan Burnett:
Yeah, that’s exactly right.

Varun Singh:
So most of those changes would be welcome for the community. And, I think the other bit is that Google announced the KITE testing platform …

Dan Burnett:
Yes, right.

Varun Singh:
Which is really cool … That means that we’ll get a consistent output from all browsers and operating systems to test against, and see if the browsers are compliant through the WebRTC spec.

Dan Burnett:
Right.

Varun Singh:
And I think there’s going to be significant effort also put in for the WebRTC statistics … If I understood correctly from the same folks at KITE.

And just to add that CallStats has volunteered to do an analysis of support for the statistics that are reported by the APIs across platforms, to make sure that the values that are reported are correct. And that’s going to happen as part of the run up to Proposed Recommendation, so I feel confident that we can get this done.

Dan Burnett:
Yeah, and KITE work is really great. I actually interviewed Alex on KITE too. It’s just some great work that’s happening all the way around, really, to make things finish up.

Varun Singh:
I think mad props to the community for coming together on getting this thing to the finishing … Well, not yet to the finishing point, but very close, we can see it.

Dan Burnett:
Yeah we’re finally getting more of the stability that people have been asking for, really, for WebRTC.

So towards the end of the day yesterday, there was an interesting discussion about QUIC that took some surprising turns. We were pretty amazed. What happened?

Varun Singh:
So the second half of yesterday was mainly reserved for thinking about the next steps.

Dan Burnett:
All the new stuff beyond 1.0.

Varun Singh:
Right. We agreed that we’re not going to touch 1.0 anymore … But brilliant ideas keep coming up.

Dan Burnett:
Sure.

Varun Singh:
And one of the things that the IETF has been working on for the last year, or 18 months, is the QUIC transport. And I think Peter Thatcher from Google came up with a proposal to have QUIC as a transport for WebRTC … Whatever we’re gonna call it.

The idea was that you could build a data channel on top of it … mainly about sending messages between browsers, peer-to-peer using the QUIC Transport.

Dan Burnett:
I think that was the context that he gave, that you can use QUIC to build data channels, and interestingly if you do that, you don’t need a Peer Connection to do it. If you have the transport…

Varun Singh:
There is the ICE transport, and you could run QUIC transport on top of the ICE transport.

Dan Burnett:
Right.

Varun Singh:
At least, the initial proposal was not to merge it with the Peer Connection just yet. If I understood correctly …

Dan Burnett:
Before we go any further, could you briefly describe QUIC? Maybe just a little bit about its history. At the IETF, it is the big hot topic right now. So why is it that people are excited about it? What is it that it does?

Varun Singh:
Yeah, QUIC has the same energy that we saw with WebRTC initially.
And like, a lot more vendors and people interested. So QUIC is about getting connections over UDP between a client and a server. And it was partly done by Google when they did the SPDY protocol. The genesis of the idea was to reduce page load times, and they utilize that. The page load time was an important measure … To get it really low and, like, get all the pieces of the whole stack from the browser all the way down through the stack really working together.

Dan Burnett:
Right.

Varun Singh:
And so, part of the SPDY proposal became H2, or HTTP version 2 … But only the HTTP parts of it. QUIC came as a proposal way back in 2012 or 2013 … that Google was working on a new transport below HTTP2, to replace TCP. And they wanted to do this over UDP.

One of the good things is that, over the last four years, WebRTC has made so much progress that we can actually say that a lot of the UDP connections can actually go through … And in this case, it’s client to server.

Dan Burnett:
Right.

Varun Singh:
So the success should be higher because you’re not doing peer-to-peer. So quickly about QUIC, is the fact that it’s HTTP2 … Underneath it would be the QUIC protocol, which is basically just, like, trying to replace TCP.

The beauty of the protocol is the fact that you can start a lot of streams … And basically can start a connection, and you say, like, “I’m gonna open a stream, gonna open another stream.” The idea is that if you have, like, hundreds of JPEGS, text, and things like that, you can open all the streams, and as you scroll through the webpage, you can utilize [the knowledge of the scrolling]. “Oh, this picture has not yet loaded.” Since the person’s gone past it, you can actually go and reset (cancel) it.

But that’s the thing — you can do better resource consumption, you can contextualize the HTTP part of your page in a way where you’d say, like, “I’m requesting for these things.” It gives you more control, you get snappier webpages, right? Better user experience.

So that work started almost a year ago, and it’s, like, moving really fast. People have multiple implementations, they get to pick off at the last idea. I think they did an interim since then … The next IETF is in a week from now, I think, yeah? At the end of this week?

Dan Burnett:
Yes, right. I fly to Singapore in just a couple of days for IETF, yeah.

Varun Singh:
You should get around the world trip.

Dan Burnett:
Yeah, right.

Varun Singh:
So, Peter basically went out and built the QUIC transport into Chrome, I think. And he runs an experiment on it. And I think what he showed was the fact that he could emulate a data channel with the QUIC transport as part of the work that he did in current Chrome, right?

So, and I think we were at the point in the day where we were saying, “Oh, this is cool,” this is something that we can do fairly quickly, and I think the group was behind the fact that Peter should basically go out and do this … Some caveats, but then people started thinking about, like, what more could we do about it, right? And …

Dan Burnett:
So I know that you and Peter, and Cullen Jennings from Cisco, were all really excited because you actually started thinking about other things you could do …

And actually, before we get to that, one of the other things that I think is interesting about QUIC is, you know, TCP and UDP don’t necessarily play well together on the Internet in terms of congestion. So maybe you could talk a little bit about that. I think that’s important for what you’re about to talk about.

Varun Singh:
So over the last 25, 30 years, we’ve built TCP, right? And one of the things with TCP has always been fairness … Like, whenever we come up with a new thing with TCP, like a new flavor, we always talk about how does it play well with the previous flavor of TCP … And that’s led us down a murky path where we have a lot of things happening with TCP, and people have monkey patched it too … And it’s optimized, it works really well. Their new congestion control, I think does the BBR, which Google announced earlier this year.

But, basically, the thing with TCP is it’s baked into the kernel. So, since it’s baked into the kernel, you cannot innovate it fast enough. If you come up with a new algorithm, you have to get it into a distribution. You basically go to the Linux maintainer and say, “Hey, can you add it?” … It takes a lot of effort to get it in as a default. So CUBIC, and BIC before it, they put in a lot of effort, and now they are the default pattern.

But if you want to deploy TCP at a faster rate, like, there are fixes that you want to do … There’s 4G now, there’s 5G coming… Network topologies are changing, people are doing different things. Access rates are different, so you wanna, like, keep it flexible for all these scenarios. And that takes a significant amount of effort.

And, with UDP, there’s always been the thing that if you do not do proper congestion control on UDP, then it can either starve TCP or TCP can kill UDP.

Part of QUIC, is the congestion control algorithm, which will come for free now as it will be part of the transport. But, it’s the same as data channels, as in you get it from …

Dan Burnett:
It almost sounds like a re-architecting of the Internet. I mean, doesn’t this break the OSI model? You know how you had UDP and TCP, and then, you add the secure version on top of that, and then you add flow control on top of DTLS, and so on. And now, instead, a lot of that stuff’s getting moved down into the lower layer.

Varun Singh:
So, just going back to the OSI model … I think we know that it’s been broken for a while, right?

Dan Burnett:
Fair enough.

Varun Singh:
As in, we had the HTTP model … HTTP, TCP, and everything below, right? And so, I think with QUIC, we keep some of the HTTP parts, while the TCP parts, which were now in the kernel, are actually now outside of it. They’re in user land, gives more control to, let’s say, a browser to modify it. Also lets other people build on top of that, right?

Dan Burnett:
So I’m gonna actually stop you for a sec … The term “user land” … Could you just say briefly what that is? Most people probably know, but the first time you encounter that term, you’re like, “What? What the heck is user land?”

Varun Singh:
Yeah, so when you build an operating system, all the things that are within the scope of the operating system is called the kernel land, and anything that runs on top of the operating system is called user land. So all our apps and everything that we build … like the browser… these are all user land. And user land has only very limited permissions in what it can do.

Dan Burnett:
Right. But in today’s Internet world, the line shifts as to exactly what could be considered user land.

Varun Singh:
Right. Of course the browser is in user land, but the apps that we write are on top of browsers quite often.

Dan Burnett:
Yes, right.

Varun Singh:
So they’re on user land anyway now. Some of the user land code is written by very smart people, so we are at a point where we do not have to trust the kernel guys to do the right thing, but we can also trust a lot more other people to do the right thing in terms of development. And the browsers are somewhat in that category.

Dan Burnett:
Okay. So what was it that you, Peter, and Cullen thought was so doable, so cool now?

Varun Singh:
Right, so …

Dan Burnett:
The conversation went through an interesting shift.

Varun Singh:
Right. Peter presented the fact that you could do data channels over QUIC, and it was not really part of the Peer Connection, but then, we were like, “Hey, we know QUIC goes over UDP, media goes over UDP, except QUIC’s congestion controlled, and most of the video that we do is congestion controlled, but outside of the transport,” right? So we can easily see of a way forward for us in terms of putting media, audio and video, on top of QUIC.

Dan Burnett:
Right.

Varun Singh:
And this idea is not very controversial because a couple of months ago, almost six months ago, Jörg and I — Jörg is my PhD advisor — we came up with a proposal with Colin Perkins and Roni Even, on doing RDP over QUIC.

So we just went through a mental exercise of how we would do the Real-time Transport Protocol over QUIC. I think the genesis of the idea was, like, “We already have a UDP transport, it has security on it, it’s encrypted end-to-end, whatever that end is.” RTP does a lot of things, and it’s anyway due …

Dan Burnett:
Due for rewrite?

Varun Singh:
And rewrites are difficult, right? Like, RTP’s a difficult protocol because it does not only this real time communication, it also does RTSP, or real time streaming. There’s multicast, sorry IPTV, like ChromeCast inside the house. There’re so many things that use RTP in different topologies and scenarios that changing it is not easy because invariably you’ll break something.

Dan Burnett:
And then feedback stuff’s been added … There are all kinds of things that have been layered on top … The error correction …

Varun Singh:
Right, so there’s a lot of things. Although we do know that RTP was built in the early 90s, and we’re in 2017 today, it’s 25, 30, years.

Dan Burnett:
It’s been a while.

Varun Singh:
It’s about time that we re-envisioned it, and at least said, “Okay, let’s build a better protocol for something that’s more relevant today,” right? And so we went through this exercise and we said, “To do RTP over QUIC, there are several things that we could do …” Since we went through that mental exercise already a few months ago, when Peter said that he had running code at this point in time that could already do data channels, I could see, and I think that’s what Cullen and Peter could also envision, running audio/video.

And even though Peter thought it would be controversial, the two independent people in the room who think that this is possible … It makes it really interesting for everyone else because at least we jumped on the opportunity of having this possibility explored.

Dan Burnett:
Right, and the three of you actually have pretty good understanding and history and background here, so this is not like, “Oh, that would be kind of a neat idea.” No, you actually think this could really work. So it’s worth discussing.

Varun Singh:
Right, and the other reason why we are really interested in QUIC, independent of RTP, is that our service CallStats runs on H2 already (HTTP2), and we’ve been following QUIC very, very closely. We also support GRPC. For us, it would be, from a skill point of view, an interesting exercise to see if QUIC would bring us a lot of savings in terms of resources, both on the infrastructure side, and also to maintain it.

We’ve been looking at it from a client server perspective, so it becomes easier for us to also think about it since we are a real time communications company. Merging it makes it easier for us as a company as well, because engineers working on the server side can also understand what is happening on the client side between peer-to-peer connections, right?

Dan Burnett:
Right, meaning client-to-client. That’s one of the things that’s so new about WebRTC … It’s not the traditional client server model, it is client-to-client, and you’re saying it applies there as well.

Varun Singh:
Right, and then it becomes easier for engineers who do not currently talk to each other about the technical challenges, to actually have a conversation. So for us, I see this as a big step forward.

Dan Burnett:
Sure. Now the conversation didn’t actually end there. It actually went on to talk about ICE.

Varun Singh:
Yeah. Do you wanna talk about Project Snowflake?

Dan Burnett:
Yeah, go ahead.

Varun Singh:
We’ve been working with ICE as a community for a long time, and …

Dan Burnett:
Wait, we who?

Varun Singh:
Like, the whole … The browsers, the vendors, the whole web community, including the IETF and the W3C, so this is something that we share in common today. And, I think when we started WebRTC, we wanted to shield some of the pain of setting up connections between browsers, away from the developer.

Dan Burnett:
Yeah, of course.

Varun Singh:
And over the years, the complexity of implementing this has been borne by the browser vendors, and the people who’ve been maintaining their RTC stack.

It’s not just the browsers, but also the SFUs, the MCUs … Everyone else who wanted to play inside the WebRTC ecosystem had to implement this. So it’s not just four or five teams around the world, the browser teams, but a bunch of people. And we’ve seen that everyone has a different understanding on how to optimize this going forward.

So, first we agreed on something, and we implemented it. I’m sure that you can get onto a different call where you can just discuss the scars of implementing ICE, right?

Dan Burnett:
It was a hassle, but it definitely has dealt with a lot of the problems that you have with NATs, firewalls, you know, private clouds, etc. that are just horrible for applications, and it made sense to try to solve that problem once, essentially, in a more intelligent way.

Varun Singh:
And we’ve written blog posts, and we’ve provided the WebRTC metrics support ourselves, and we’ve shown that connection failures have gown down over time.

So we are at a point where the connection failures are down, we need to put somewhat more infrastructure to get around some of the firewalls and NATs, and, as an industry, there were open source TURN servers, which are helping developers get the product out quicker, faster, more reliable, right?

And so, related to ICE … One of the things that we’ve seen at CallStats, and I can only speak to what we’ve seen, is that sometimes the connection that got set up is not exactly the one that will be the best for the end point.

And best can mean different things. … For example, you have a home connection, you have your Wifi and 3G, but your 3G might be the default one. Now maybe you’re a bit far away from your Wifi terminal, the signal strength is low, basically a local condition such that ICE could figure that out, and say, “Yeah, my signal strength’s lower, so maybe, unless it improves, I’m not gonna use this one.”

Dan Burnett:
So ICE will guarantee you a peer-to-peer connection if one is available, but that doesn’t mean it would guarantee you a good one, or a fast one.

Varun Singh:
Right, and there are a lot of people working on what good means, right? So I think one of the discussions that came about, even before we went into that meeting, was me expressing interest to explore a way where a third party cloud system such as CallStats could tell their end points which pipe to use.

But today, the API is a bit complex to do that. And it’s not easy … You would have to do filtering, and someone needs to give up control, and sometimes you wanna capture all of them, make sure that you get one or more connectivity options, because if the worst one is the only one, you need to use it. Once you have connectivity established over several of them, then you want to say, “Oh, pick this one … All of this set.”

Dan Burnett:
Right. Without losing what you have as your back up.

Varun Singh:
Right. And building something like this is … I wouldn’t say challenging … As a third party, of course, it’s challenging, but as a first party, a lot of people need to do this themselves and learn about doing it. But they don’t have enough control so some of it is doable, but not really obvious how.

Dan Burnett:
Yes, right. A lot of this stuff is esoteric, and it’s buried in the protocol stacks, right?

Varun Singh:
Yeah.

Dan Burnett:
First, putting a hook in is not necessarily easy, and then, explaining to somebody what that hook means and how to use it, is really tricky sometimes.

Varun Singh:
Right, and a lot of times, it’s like, do what I mean and not what I say. A lot of places, this is a challenge, really.

So I think Cullen’s proposal was “Scary ICE”, or something like that. He made a proposal where he said, “Why don’t the end points themselves, once they gather, decide which candidates they wanna check over and send the connectivity checks by hand from the JavaScript.” Then once an acknowledgement or response is received for a certain request, they would get an event, and the app would know it got a request on the far side, and the local side will also know, “Hey, the other side acted,” right? And this basically moves a lot of the complexity out of the browser into the hands of the JavaScript.

Dan Burnett:
Right. So basically, there are only a few functions that the browser handles, but the rest of what we know of as ICE today is just a JavaScript application.

Varun Singh:
Correct. So, a lot of the candidate management, and, “What do you want to do next? How do you want to pace your STUN request?” are not part of the browser anymore.

JavaScript can actually control this, can actually say, “Oh, you know, I’m on a 3G end point, and I want to send my STUN checks less often, or more often.” They can make that distinction just based on … Not based on the browser making that decision for them, but the …

Dan Burnett:
Based on their application needs or environment that they know about, or whatever …

Varun Singh:
Right, and this became a part of the discussion. It was something that we were interested in as well, it moved the envelope further. We believe that, as a community, we will get a lot more control over the API, and over the transaction of connectivity, and control over that.

Dan Burnett:
But it’s not just the control … I mean, shouldn’t it help with testing as well? And the complexity of those pieces?

Varun Singh:
Right. Assuming five or six people at each of these browser companies, I don’t know the exact number, put in the effort to build all this, it means they took on the responsibility of testing it, making sure it worked. But we know from first hand and second hand experiences that they’re still working really hard on the counter cases.

And counter cases are sometimes really hard to envision, but it becomes easier for developers to maintain this as a community, instead of five people at each of the browsers. With the same five people from those four browsers or six browsers, and five others, like, infrastructure vendors, you have a pool of, like, 50 people now, which can actually maintain a JavaScript version of ICE, or whatever you want to call it.

Dan Burnett:
Sure.

Varun Singh:
And so, I think we went through some naming exercises yesterday. Do you want to talk about … ?

Dan Burnett:
Yeah. Well, we were just trying to think about the ICE team, and for those of you who know the IETF, people in the IETF really have fun trying to come up with acronyms or names that could be considered clever. We were thinking this is kind of a light version of ICE, so I suggested “ICE chip”, and then you suggested …

Varun Singh:
We’ve had ICE for a long time, and I was wondering how we could incorporate snow in it, so when you said ICE chip, I was like, “Yeah, snow”, and I said “snowflake” and people loved it immediately I think.

Dan Burnett:
Yeah, it definitely stuck. So people started calling this “Project Snowflake.” Now, you know, “Project” because only a few people in a room were discussing it at W3C. But still, it’s interesting where this could go.

Varun Singh:
And the beauty of it is that two people independently can be on the same problem, coming together at an event serendipitously and basically converging on a solution, right?

Dan Burnett:
Yes.

Varun Singh:
Or starting of a solution.

Dan Burnett:
Or direction for it, right.

Varun Singh:
With more people I think we can get this off the ground, so I think it’s now going to come back to how much energy the community has; two people are never enough to take this forward.

We’ll of course get the ball rolling, but more people will need to say this is something that they would like as well to see happen. So there are people like all of you who are listening in, your opinions would be really useful for us as people who are building the next version of … And also, like, as input, as in coming and doing the work as well, right, so like …

Dan Burnett:
Along those lines, why does this matter? This was a fun discussion, and it felt like a detour, but an important one that could have longterm implications. WebRTC is fine, right? Why do you need this? What does this really do for you, building all these pieces on top of QUIC?

Varun Singh:
WebRTC was actually very important when it came about because, at the time, there were maybe ten, twenty, thirty apps, effectively different platforms, Adobe and so on and so forth, which had ways of doing communication. But they had their own ways of doing it.

So WebRTC was really important. And I think one of the biggest things that we achieved with WebRTC is a suite of protocols that we all agree as an industry.

Dan Burnett:
You’re talking about the plumbing pieces, right?

Varun Singh:
Yeah, the whole plumbing.

Dan Burnett:
Not even the JavaScript necessarily, right?

Varun Singh:
JavaScript was just a cherry on the top. Now we have APIs that we can use. But when we talk about H.264, we are like, “There’s so many profiles of that codec.” We agreed on which one we wanna do, right? Which one would be supported by all the browsers.

The same thing with SDP. There are so many variants of SDP, we said, “Oh, we can do some variants of it, and here are the options that we like, and here are the options that we do not like. These are the options that we should be exploring,” And …

Dan Burnett:
And some of the enhancements were things that people have been wanting to do for a long time. The notion of BUNDLE, and routing, sending all this traffic essentially over a small number of five-tuples.

Varun Singh:
Right. So, if you look at the whole stack, all the layers that we call the OSI, we standardize everything, right?

We standardize the DSCP code points that we use to mark the package? There are so many ways of marking the package.

We agreed on a few set of classes that we would use for real time traffic. So we agreed on that.

We agreed on how, before [IP]v6, we would traverse the NATs and the firewalls. How would we prioritize these candidates?

And if you go up the stack, you can see what profiles of RTP we are supporting, what header extensions, what receiver reports, or extension reports we’re supporting.

And if you go further up, like, in terms of security profiles, we support DTLS. Before you had four options at each level. Now we know, as an industry, if you wanna do real time communications, what exact things …

Dan Burnett:
This is what you do.

Varun Singh:
Yeah, and so we converged on something. Now, I think what we’re looking for … And I think this is alluding to your point, why was it interesting?

Dan Burnett:
Right, exactly.

Varun Singh:
It’s because now we are at a point where we’ve agreed on the first principles, so now we can start building on top of this first principle … sometimes relaxing what we already agreed on the first principle.

ICE is a very good example of where we all know what the first principle is, but we do not want to coordinate this across all end points at all the time. We want to give the JavaScript or the application developer some more control.

We also, over the years, have realized that JavaScript developers are really awesome, and can understand some of the complexity … And when they don’t understand some complexity, there’s some smart guy who will come out and write a JavaScript library, which other people depend on. And that complexity is then a community effort [to address].

Dan Burnett:
Some of the things that you were discussing as possibilities, it just wasn’t possible before to do this, right? It’s not until you had this highly optimized QUIC, really, that looked at round trip times, and things like that. Everything together is designed to be top-to-bottom optimized.

Varun Singh:
Right, and just going back to QUIC, QUIC’s come from a lot of effort over the last four, five years. Google’s been running it on the back end of YouTube, delivering videos over QUIC for a while so they can know how much success rate that connection between a client and server was.

Then WebRTC came up with their numbers of connectivity … They’re now quite similar, like, they’re 95 plus percentage connections on YouTube, and it falls over to TCP whenever it cannot get through. So the user actually does not feel frustrated.

I think we will have to think about similar things along those lines for WebRTC as well if you wanna do this; the major landmark of QUIC is congestion control transport for UDP. The assessment of how well it would work with UDP for real time traffic is yet to be determined, but the fact that it is in user land means that we can easily change it, or maybe control the type of congestion control.

Dan Burnett:
Right, and innovate in that space.

Varun Singh:
Right. And that can be led by the people who understand congestion control, understand real time traffic.

And for us who are working on the use of the transport, if that [other] problem’s handled by them, we can build more interesting apps by actually getting the raw video frames, or the encoded video frames, directly into the JavaScript and then having control over when to send those frames out … and then playing them back on the other side. So that would mean JavaScript would be doing everything that native application is capable of with respect to control.

Dan Burnett:
That’s pretty cool. I don’t know whether to ask you this question or make the statement, but I think it might be easy for someone to be worried that, “Wait a sec, they’re talking about something completely different. This sounds like whole new JavaScript APIs,” I mean, is WebRTC being thrown away, WebRTC 1.0?

Varun Singh:
No.

Dan Burnett:
No, of course not. This is all future functionality. So how is this likely to look? Perhaps the next version of WebRTC has some more hooks. Or maybe it actually goes further and it defines some of these other kinds of APIs? I’m asking you to speculate …

Varun Singh:
Now that we have the 1.0 working, I don’t think we’re going to break backwards compatibility, ever. I think what we’re gonna do, perhaps, is figure out a way, if you wanna do this, that would be under the layers … Like, the browser would still expose all the core functionality, and then the JavaScript would expose more of these functionalities, and people experiment with it, and then, at some point, maybe would feel confident enough that some of these things can be brought back into the 1.0 API so that the 1.0 would use the same APIs internally to … Like, you would structure them in some way that you call the new API as part of the one API.

Dan Burnett:
So it’s not like, “Oh no, you have to rewrite your whole application now.”

Varun Singh:
I would hope not, we put in a lot of effort in doing this. It would be really bad if people came out and say, use this new shiny thing, and exactly like the old shiny thing, is not shiny enough.

Dan Burnett:
In fact, it’s nowhere near done, right? I mean, this is an idea that was discussed yesterday, and it’s gonna take a while, right?

Varun Singh:
Right, and if you look at some of the “scary” proposals, they were small bite pieces on improving certain aspects. It was not a complete new proposal of, “Oh, we actually have to change everything”. It was like, “Oh, we wanna optimize just how we do connectivity, or control over connectivity.” And the second bit was, how do we actually send video over QUIC?

In most cases, with the Peer Connection, you don’t even have that control today. You create a sender, you create a transport, fires up by itself, and you basically associate tracks to senders, and that’s it, right? I think what is being proposed here could easily work with that model, because we were just changing small bits, optimizing them along the pipeline that people still don’t have control over.

Dan Burnett:
Just like any new thing, this is likely to take some years, probably, to get worked out, right?

Varun Singh:
I would say fair amount of time, but …

Dan Burnett:
Okay, maybe not as much time as WebRTC has taken to get to this point.

Varun Singh:
Right. If the QUIC transport’s already there, we have the first moving part …

Dan Burnett:
Right. But QUIC itself isn’t done in the IETF, right?

Varun Singh:
Right, there’s that bit as well. There’s features in QUIC that would be requested by the community doing real time communication over QUIC. There will be some flavors or features that are new too, they’re not currently available. We would need to revisit the idea of, “Do we wanna do RTP, or do we take this as an opportunity to reassess that?”, like, we could do a better format.

Dan Burnett:
Right, it doesn’t have to be RTP. It can be media, for whatever ‘media’ means today.

Varun Singh:
Yeah, and a new container. That container can be RTP, or it could be RTP lite. There’s still things that RTP did well, like, it does time stamp its stuff. It says, “All these group of packets belong to each other,” which may not be needed here because you could open streams for each frame. So some of those things will necessarily not be needed. But there are time stamps and packet sequence numbers, frame sequence numbers, so they’re things that are repeated, right? … Which you would want to include in there.

So I think it’s an exciting moment for us. It’s just been day one, so I think you’ll need to follow up more on the progress as we move forward.

Dan Burnett:
It’s unlikely that this was a waste of time. I think there was something that was realized that’s important, and will probably result in some good new work.

Varun Singh:
Yeah, and the fact that there were a lot more people interested in the proposals. People did not think that they were entirely bizarre.

Dan Burnett:
Yeah, often someone proposes something and four people go, “That’s ridiculous, and will never work.”

Varun Singh:
Right.

Dan Burnett:
And that’s not what happened, which is quite interesting.

Varun Singh:
Right. It even solved some of the things that I wanted in version one, like some more control. When you want a little bit more control, it’s always a trade off, but [with] these new features, we might actually get a lot more control. And I think that’s what we’ll have to assess as a community – how much control is good? What exactly are we giving access to in JavaScript?

Dan Burnett:
Right. And it’s not just control. It’s control in a hopefully cleaner manner.

Varun Singh:
Right. Where you do not have to guess what the browser may have been doing.

Dan Burnett:
Yes.

Varun Singh:
A lot of the times, today, it’s, “Oh, the browser’s doing this, so let’s write my code in a certain way because of that.”

Dan Burnett:
Right. So for people who are interested in this, it’s probably too early to say exactly where work is going to happen, but If someone watching and listening says, “You know, actually some of this sounds interesting, and I wanna pay attention to where it’s going,” where is work likely to happen, do you think?

Varun Singh:
I think the W3C mailing list, for WebRTC. I think this is where it’s gonna happen.

Dan Burnett:
So it’s not IETF?

Varun Singh:
I’ll hold my thought on that.

Dan Burnett:
That was a leading question, obviously, but I did hear some comments during that discussion that there might not be as much work needed in the IETF as one would think, in order to do this. And that’s really cool, actually. Because the more we can do in the user land and JavaScript space, the better.

Varun Singh:
Right. So I think one of the things that’s taken us so long with WebRTC was the fact that we used SDP, which was because we had a lot of experience with that.

Dan Burnett:
Right, there was a lot that was defined already. And there was a lot of experience.

Varun Singh:
I think figuring out how, or what, we actually wanted, because there were so many ways that one could express a certain thing, gave us this really complex language where we could express a lot of thoughts, but then we had to nail down what we really wanted for WebRTC 1.0.

So I think we’ve learned a lot in this process because we saw what the enrichment of a lot of features would be, and what are the exact features we want. So it will drill down to something that we understand very well.

I think one of the biggest reasons for ORTC and the NV work was to decouple ourselves from the SDP model. And I think that would still happen, and because of that I believe some of the IETF work that we’ve been doing would go away, right?

But of course, if you’re gonna send a packet on the network that needs to follow a certain structure, then other things on the network can observe it and play nicely with that.

Dan Burnett:
Sure.

Varun Singh:
So, if some part of the Project Snowflake would be a simpler ICE or, “Oh, actually, this is all we need of the mechanism,” that would have to still happen in IETF. And, I think that’s the important bit.

Dan Burnett:
Okay. Well, cool. It’s very exciting.

Varun Singh:
It was.

Dan Burnett:
It’ll be fun to see where this goes.

Varun Singh:
Yeah, and thank you for taking the opportunity to call me on. It’s always nice to speak to the community through this platform, AllThingsRTC. So really good, and good turnaround time, right? So we did this discussion yesterday, and we’re …

Dan Burnett:
We’re talking about it today, and hopefully have it out very, very soon.

Varun Singh:
It was a pleasure, Dan.

Dan Burnett:
Likewise. Thanks, and we’ll talk again.

Varun Singh:
Yeah, thank you.

Dan Burnett:
Alright, bye.

Varun Singh:
Bye bye.

Please also see Varun’s post on this topic here


http://www.allthingsrtc.org/wp-content/uploads/2017/05/webrtc-icon.png

Dr. Daniel Burnett has a history of almost 2 decades of experience with Web and Internet standards dealing with communications, having co-authored VoiceXML, MRCPv2, WebRTC, and many other standards. In creating AllThingsRTC, Dan aims to provide the innovators in the real-time communications space a forum for explaining the topics that really matter.