Networks are complex. Doubly so when you need to manage real-time communications on top of them.
Recently, I had the pleasure of being a part of a workshop we did for a large vendor. Part of the discussion covered the topic of dealing with unmanaged networks – networks where packet losses are a common phenomena. What we usually do in such a session is talk a bit about how packet loss degrades video quality and then go on to explain our SVC and NetSense technologies.
In this specific case, I noticed that people got confused between the different algorithms we employ and the reasons we had for using them. My guess is that others, who have joined some of our webinars, read our blogs or simply talked to a sales person or a product manager from RADVISION, might have gotten confused as well.
To try and make a bit of an order in this issue, here are 3 types of packet losses and how we deal with each kind.
Routers and switches that build up our Internet have their own limits. They can move around bits at a given speed. Try to push more through them, and they will “break”.
When this happens, we call it congestion. And to solve this they simply start dropping some of the packets you want to send.
How do you deal with it? You send less. In video calls, this is done by reducing the bitrate that is allocated for the video channels.
The tricky part with congestion is that it can happen at any time and in any place along the route of your packets to their destination – from your own WiFi access point, if multiple people are trying to use it, through your DSL or cable connection (if your child is downloading the latest movie out of bit torrent while you try to do a video call) to the Internet’s backbone – where you have no real control. This means that congestion is a dynamic thing – the available bandwidth that you will have may vary from second to second.
Therefore, estimating the available bandwidth at any given time is crucial, and so is adjusting the bandwidth being sent accordingly. That’s exactly what our NetSense technology is all about.
Data sent over networks can get corrupted. Especially when you are using wireless connections.
The packets you send can be dropped because they failed CRC checks (which result from bits being flipped inside the packets due to external reasons), collisions in the network and other mundane reasons.
Some networks might even have a kind of an inherent packet loss – DSL or WiFi connections can show a kind of “static” packet loss that you will experience no matter how much bandwidth you are using.
In such cases, the only thing you can do is to try and protect the data you are sending as much as possible, so that recovering from those packet losses will be easy. For signaling, this is done by simply retransmitting the information. For media, you will need to somehow conceal the effects caused by packet loss and/or send redundant data to use for on-the-fly recovery information when necessary – that’s what our SVC-based technology does.
There’s another kind of packet loss – one which occurs on the receiver side, within the application itself.
The network is jittery in nature – the data you send is not guaranteed to get to the other side in an orderly fashion. So someone receiving your data, internally, will buffer it and reorder it before using it, if he needs to process stuff in an orderly fashion (and so do everybody for voice and video communications).
For real-time media, if the data arrives too late (say a full second late, when usually you get it within 200 milliseconds), then you have nothing to do with it, as waiting for it would kill the user experience. In such a case, the only thing to do is to throw away the packet, causing packet loss.
What can you do about it?
- The sender can be a bit smarter in the way he sends data over the network and take the network’s characteristics into consideration.
- The receive needs to employ an adaptive jitter buffer to be able to adjust dynamically to the flow of incoming media, optimizing between latency and packet dropping.
How do we know which type we’re dealing with and adapt accordingly? Well, that’s part of what we do in the media engines of our various products – we try and analyze in real-time what is the exact type of packet losses that we experience (or are about to experience) and then act accordingly.
There’s also a good overview of the reasons that cause packet loss on Sagee’s blog. If this interests you, then I suggest you head over there to read a bit more.
If you really want to understand the intricacies of packet losses and how we deal with it, then an upcoming webinar that we’re hosting with TMCnet is just what you need: Making Real-time Video work over the Internet – register now. It’s free.