 So our next talk is about tourist, a reliable internet stream transport, a promising new protocol. Please welcome Kiran. Thank you for the introduction, Christophe. If you want to email me or send me a horrible tweet, you can tweet me there. So we would like to introduce wrist and more. First of all, what are the goals of what wrist is trying to achieve? And the goals of wrist are low latency video between generally professional devices or point to point video or point to multi-point video, not necessarily to end users during the production process often. So not in a browser but between different video devices that are not browser based at a really low latency. And the goal is really to have packet recovery on a lossy network. It says internet but this could also be a lossy one of some sort, may not necessarily be the internet. It could be a wireless link, for example, between two different places. And the other kind of goal is backwards compatibility. So at the moment, pretty much all of this stuff is done with a transport stream in UDP. And the goal of what they're trying to achieve in wrist is to do that, to have some level of backwards compatibility. So you could send to a non-risk-able device and it will at least operate normally. It may not be able to gain the benefits of wrist but it will still work. So the backgrounds of this, who came up with wrist, this is unusually at an open source event. This is a specification written by a closed industry form of manufacturers but there's a bright side I'll talk about in a minute. And they have an interest in, there's a lot of this reliable internet streaming kind of technology already done in a proprietary domain at the moment. So there's lots of different proprietary protocols that people use and they want the ability to have something open standard based and ideally building on IETF. You can see that they've gone and done their own thing a little bit here for rightly or wrongly but the idea is to build on existing IETF standards which are free and open source and published. And so wrist was published in October of 2018 and what was unusual actually is wrist was published under a creative commons license. So usually most things in broadcast are designed actually to keep people out to actually gate keep a bit like for scientific publishing industry. It's exactly the same phenomenon. Things are kept behind paywalls, they're kept behind secrecy designed to make sure only a few people can implement it and a few people can understand it. And if you were here in the last presentation and it's not Willem's fault because Willem is trying to improve things but he used a lot of acronyms and a lot of terms and this is all deliberately or otherwise there to make it not possible for people to understand. So that only a few people can understand this and make a lot of money out of it and not have open source implementation. So this is actually, although lots of the process was bad from an open source standpoint, publishing under a creative commons license is a big deal because it lets people actually understand and implement this and find the problems instead of you know living in acronym soup where things are closed and yeah. So why not TCP is the question that's obvious and I can't go into this because you could write a book about this. This is a whole research field in itself but at least to begin with traditional TCP drop transmission rate with packet loss. There's lots of work in other dev rooms you can find out about how they're changing that and actually in our use case we don't generally have throughput drops per se and I talk about how that might be different later but generally we just have random packet loss, packet loss because of switch capacities, packet loss for other reasons and we don't necessarily want, this is usually a constant bit rate transport stream and we want still constant throughput and we just want random packet loss to be fixed. UDP itself has native support for multicast so I mentioned for example if you had a WAN it's very common to multicast traffic across that WAN in a closed environment. It's quite easy then to have specific receivers request retransmits as a result so a particular receiver can go and you could have a single sender sending to hundreds of different devices and each receiver could go and request a retransmit in a multicast environment quite easily if they happen to be lost on a particular network segment. Backwards compatibility as I mentioned again, want to send risk streams to existing devices. It's also a lot easier in UDP land to do multi-parting to send traffic down multiple internet connections and also the other interesting thing about UDP itself is, and this is becoming more common for example on the web with protocols like Qwik or HTTP3 now, let's the application handle all the congestion control decisions and that means people can do all sorts of interesting things. You're not curtailed by the legacy of the kernel that the sender or receiver is using which you may not be able to change in some cases. So what did people use currently? Really actually really really basic 1990s technology forward error correction and this is an example of it, 7022-1, really really basic in this case. So it's built around the idea of these packet groups in rows and columns. So I don't know if you can see the colors very well but row FEC is shown in blue and as a packet is lost across a row that's corrected using the FEC packet and same with the columns. So if a packet's lost in a column the red packet can be used as a very simple XOR operation can be used to correct a packet. But the biggest problem is those matrices have bounded size and you can't handle any loss larger than the matrix. So retransmits or the other solution to this. So there's already existing open source software that does this. It's a problem certain people have been trying to solve since 2007. Aggregate RTP from Videolan was one of them. To be honest the author did it when it wasn't cool. No one was really doing this at the time. This was considered an auto-fay and now it's quite commonplace. Aggregate RTP is an example of such that. It lets you aggregate links but also as a side effect has retransmission built in. There's also as of last year SRT from I think it's a Canadian company, High Vision. It's a pretty monolithic code base I would say. It does the same thing. It does retransmits. Quite bizarrely I would say personally they've built it around a file transfer application and then added live. The big downside is it supports single link at the moment. My understanding that someone can shoot me if I'm wrong is they have a proprietary element that does multiple links but shoot me if I'm wrong. One big advantage it has built an encryption that is a big thing. And to be fair to them it's a very complex code base and people have asked for a specification and they actually wrote one to my shock and it's actually 89 pages and exceptionally detailed. It's a very complex protocol and to be fair to them if someone actually had to, you know, not all people sat down and actually wrote this thing which is amazing. And as I mentioned before various other proprietary solutions and they're all some variants of the FEC I showed before. Hopefully something more advanced than this 1990 stuff so there's much more advanced FEC out there that has much better protection and retransmissions. So they're mixing some kind of solution around that. I forgot to mention before the other downside of FEC is there's quite a lot of overhead. So if you don't actually have loss you can waste up to I think 25% overhead just adding these matrices that you won't actually end up using. So sort of a quick primer to RTP, a real-time transport protocol and RTCP, it's a real-time control protocol. I think that's right. These are the main protocols used for UDP based live video for example webRTCs and some of the example uses RTP for other applications. So usually the main traffic is sent on port N and then N plus one is for the control and feedback data. So what the sender does is periodically send RTCP packets on port N plus one to keep state. And I'll have an example of that in a minute. And then the receiver responds using receiver report RTCP packets. And it's grandly described as natural reversal but it's not really natural reversal per se. As I'll show in a second this is a standard functionality of NAT. And what's useful is this RTP and RTCP can be over multiple links. So main content usually video goes over the main port N and RTCP over N plus one. So this diagram shows NAT traversal quote-unquote inaction. The sender sends RTP feeds. Usually the sender is behind a firewall so I can rock up somewhere like FOSTEM as hopefully this will be able to show. Plug in that's usually NATed and receivers are usually in a sort of central facility where port forwarding and firewall, you know, access control rules can be done. So sender sends a feed down port N. RTCP packets go across on N plus one to the receiver behind the firewall. The receiver then swaps the source port and destination port, sends a return messages back to the external NATed source port. And as a result the stateful NAT passes it through. So this actually surprises a lot of people when they realize you can do that. But this is exactly how DNS works. So you do DNS, when you do DNS it sends a UDB packet out to a DNS server. You're on that at home assuming you're using 1.1.1 or 8.8.8. Not your router's DNS. You send out UDB packet to one of those DNS servers and it responds in exactly the same fashion. So that's why I was saying it's a bit grand to call this NAT traversal. This is basic NAT functionality. But some people seem to think this is a bit, yeah, this seems to be traversal based. So, acknowledgments. And so again, RTP 101, sorry if you're already aware of this, every RTP packet has a sequence number. So it has a number that increments for every packet. Unfortunately, it's 16 bits. Probably the RTP developers back in the 90s couldn't really foresee actually bandwidth is quite high. So 16 bits actually wraps around pretty quickly these days, certainly on high bit rate video, very, very quickly in uncompressed video. So there's an example of what a negative acknowledgement looks like. So this is not like TCP where there are acts in general. This is just negative acknowledgment. So packets which aren't received are requested for retransmission. And I'll show you a bit more about that in a minute. So first packet comes through, second one fails, the receiver then requests a retransmit and the sender then transmits it back. And I'll explain to have a signaling works in a second. So there's two types of negative acknowledgement message. The first of which is a bit mask. This is already itf standardized already exists for I think decades probably. And it uses a base sequence number. The bits in bold are just the codes to identify that type of RTP packet uses a base sequence number and a bit mask. So in in this example, the base of 100 is lost. And then there's a 16 bit mass sharing how the next following 16 bit packets whether they've been received or they've been lost. And then you just come you just add more and more of the bottom fields along to add to show to show up subsequent packets being lost. And this is really useful for just random packet loss, the odd couple here and there. And then they've gone now and decided to do their own thing a bit and implemented ranges. So this is where you have a range. So if you say I lose 100 packets, this this field, this kind of packet designed to signal ranges at very low, very, very quickly. So they've used application specific type 204. And there's a ASCII string RST to signal that. And you can see that they're losing packets at the bottom. So I think it starts at 100 to lose 19 packets. To be honest, this is kind of pointless. This is over engineering. If if you've lost that many packets to begin with, the overhead of had adding a few more of these isn't going to sort of be consequential, because you're going to have to retransmit so much, you're going to save a few bytes for sending a range packet. But so what, you're going to have to send huge amounts of it back anyway. It's not as if the return channel is going to be busy. And so how does the receiver know when it's received a retransmission as opposed to remain? They've done this in a really bizarre way. So the SSRC, I think is the source. It's basically, I forget the acronym now, but it's essentially an identifier for the source. And what they've done to signal a retransmission is set the lowest significant bit of the SSRC to one, which is a really bizarre way of doing it because there's already an existing standard, RFC 4588, which you can look up and you can see there's already a way of signaling exactly how it should have been done. So they've come up with this hack to do it. But as long as the decoder then knows what the retransmission is, so it looks at the LSB and says, oh, it's one, so it's a retransmission, then it can then it can figure out its retransmission and put the packets straight into its buffer where it needs to be. And then the rest of it, as I mentioned, becomes application-specific. So the rate at which the receiver requests retransmits, that's completely implementation defined, so it means people can do all sorts of weird trickery if they wanted to. There's a whole bunch of problems that are just completely independently defined. How to handle, so let's say the connectivity cuts for a second or two seconds and you have to retransmit tens of thousands of packets. How do you handle this thundering herd response? And that's an implementation defined problem. That's not even sure how you could really explain it in the protocol itself. So implementation-wise, there's two open source ones that I know of. There might be some others. There's U-Pipe, which in the example directory, hopefully, I will take the risk of the live demo and show you that. And there's VLC in, I think, 4.0, which has the risk protocol. And there's a bunch of proprietary solutions. A video flows Xe, and I think some hardware ones. So we've tested all four of those in combination and they can talk and request free transmits and they work fine. The hardware ones, if someone wants to give me some hardware to test, yeah, sure. Future work. Encryption. So you could already do encryption at a different layer. So you could run a VPN between your devices, for example. That works perfectly fine. But you may also want to do encryption in the protocol itself. And this will probably be DTLS. Null packet removal in the protocol. So lots of streams have null packets. If the content's not difficult, it's still padded to CBR. And you'll see in a minute most of the streams that I'll show on the demo will be null packets because they're just one solid color. Bit rate changes. So there can be a point where the actual link throughput capacity drops and you'll want to actually change the encoder's bit rates. So how do you signal that? There's already your IETF work to do this because in video conferencing this is already a thing. Pull mode. I'm not sure if they want to do that as part of the protocol, but I mentioned the decoder needs port forwarding. You could have a situation where your encoder is actually not in front of a file. Your decoder's behind that. And how do you get the protocol to work without port forwarding? And there's various things, for example, VLC can do this already with RTP via, I think, RTSP. But that needs to kind of be implemented a bit differently. They also then want to, then the bottom bit is for when they're going a bit crazy. Scalable video, for those who aren't aware, Scalable video is when you have a video stream that allows you to lose data but still be recovered sort of a lower resolution copy or a lower frame rate copy. This is really nice in theory. It doesn't work in practice. It's often easier just as you see now on the web, for example, just encode the video at multiple bit rates and switch. People have tried Scalable video. I'm surprised they're reviving this 2000-era technology because very few people can do it right. It's very, very complex to implement and the benefits kind of aren't there often. Then this is where they go really, really crazy. Retransmissions on uncompressed video. So VLM told you all about the complexities of doing uncompressed video and all these crazy rules. And now they want to add retransmissions to that. So already in the tens of gigabits of range and now you want to add, they want to add retransmissions for some reason. This is where I think they're slightly losing the plot of it. Right, this is always the tricky bit. Live demo. Over the foster M Wi-Fi, could we actually get a sleeve? This is, well, I think the hardest bit of the live demo is will the HDMI work? Or will we be using X-Randar? So I did cheat a bit and in hindsight, maybe the cheating was, I have, oh, yeah. Kind of, not sure why it's showing a quarter of the screen, but so be it. Oh no, I think it's just resized and the VLC hasn't gone and resized itself. But anyway, so I was hoping to cheat when we did cheat by using a VPN. But what we discovered kind of during testing is most VPNs are using Y guard in this case, but a lot of VPNs can't handle pumping 50 megabits of UDP traffic through them. They just collapse. So, no, no bit, no, but we want to show, I want to show the command line as well. I just forget about the corner. So, I actually want that. Right, so, expand that a bit. So you can actually see is it correcting packets as we speak, which is good. This is one of those fancy touchpads. There we go. That's exactly what I want to see. So, the sender, so this is a U-pipe based encoder in the office and a, the U-pipe example decode receiver here and then that's being pumped into VLC for testing. So what you can see is the sender and receiver are estimating round trip times, no, no, they're calculating round trip times throughout the process. So every, I think it's every second and as a result the receiver is using that to figure out how many retransmissions it can send within the bounds of latency that's configured. So I think it's configured to one second latency, if I recall correctly, or maybe three. Yeah, so unfortunately when I want to talk about repairs, it's actually stopped repairing but it was repairing a lot before. So you connect you and you'll see a ton of green terminal input but you'll see it send retransmissions and you'll see that it's actually lost nothing, which is quite good. I think the stream is 10 megabits or did you cheat and lower it? Yeah, it's 10. It's still 10 megabits but the intention was to do 50 and really saturate the Wi-Fi but that probably would have killed all your other devices but never mind. I thought doing any repairs but you should be able to see it send repairs packets if it was repairing but Solve's Law, when I want to talk about repairs, it doesn't and when was, well isn't it like, it was, it was, there we go, there it's doing some repairs. So you can see that it's found, it's found holes between 996-8 and 194 and it's requesting retransmissions and gradually repairing them. It's found another hole and it sent another retransmission but so and you can also see since I have 21 seconds left so since I think we configured it to one second that that gives me about, I have about a 20 millisecond ping to the office so that gives me 50 different attempts roughly to retransmit so there's a very good chance I'll be able to get that packet back. So like them have kind of worked which is yeah that's great. Anyway, thanks a lot. Any question? In your future work items slide there was no mention of any sort of multicast or multi-routing. Is that stuff that they're considering and it's just way far off or do they consider that out of the domain? What do you mean by multi-route? So it's about multiple links that's already supported so that's already part of the protocol, it recommends you send the retransmit down, the retransmit down both links and you duplicate the retransmit down both links and it's again implementation defined how you want to balance the links that's completely up to the way the sender and receiver want to do it and that's using. And multicasting? Already supported again at the beginning so the receivers, a multicast receiver requests retransmissions from its source and it's recommended, actually I think you have to do it that way, you have to include your retransmissions in the multicast so that all receivers can benefit from the retransmission, because the chances are if let's say there's a trunk line, you know, there's loss on a particular fiber line in that part of the world the chances are there's quite a few receivers that have actually lost the packet so all of all receivers can benefit from it. Thank you. Somebody over there? No but for the online audience? Yeah I forgot to repeat the question, sorry. So the question before was about multicast and multi-linked. Question, is this protocol also designed with 5G in mind like where you can have network slicing and set up different quality of service levels? I'm not the expert on 5G, there are people in the room who are where is Remy, I'm looking to look at him but I can't see him. Is there? No but it supports UDP so it's UDP so you can set the type of service and diff serve flags which is what people do. Because it would have been nice if it would have been aligned with actually like the network link and what you're going to use. You can set yeah and from what I understand from 5G is because you have low latency on 5G. Yeah I think you could you could if the operator would sign the right commercial agreement with you to support TRS and diff serve they could follow the rules theoretically that should be possible and it was marketed also possible for 4G and it never happened but so we'll see I believe for 5G supports multicast their projects 5G media project but I look at having multicast links over 5G. 4G if I understand correctly for EMBMS some kind of multicast but that was not widely deployed so it's more of a theory versus practice problem but yes it's you could do it I think with toss and diff serve surely. Have you done benchmarks against existing retransmit based type things like SRT like you mentioned or quick. Yes we have but I think we saw from what I understand from this is what Raphael told me I actually I forgot the last slide actually which is thanks to Raphael and because it's on the wrong the producer but thanks to my colleagues for doing this work. So we have done some testing and from what I understand we are as good as if not better but this was I only got the data literally yesterday no literally this morning so I haven't verified it myself so. Other questions? No? Thanks. Well thank you Kiran.