- VoIP Survivor - http://blog.radvision.com/voipsurvivor -
NetSense 101 Part 2: Packet-loss-based Bandwidth Estimation
Posted By Tsahi Levent-Levi On August 18, 2011 @ 12:02 pm In Technology | No Comments
[This the second part of a series of several posts about bandwidth estimation for IP based video calling.]
Bandwidth. We don’t have enough of it. And video calling devices need to know how much of it is available. That’s at least the gist of what I’ve written in why we need bandwidth estimation .
How do you estimate it today in most cases? Using packet loss information.
When two endpoints are engaged in a video call, they send RTP  packets with the actual compressed media in them. In parallel to the RTP, there’s an additional protocol called RTCP  that is used. RTCP takes care of sending control information between the endpoints that relates to the RTP media: how many packets were sent, received, lost, etc.
This information can then be used by the sender or the receiver of the media to change his behavior in real time.
In most systems, the decision is left to the receiver – he is the one that receives the data and is aware to some extent on how the link is behaving.
The receiver will be monitoring the incoming media, and if he sees that there are just too many packet losses (a heuristic that is different between vendors), it will estimate how much effective bandwidth it has and from that information ask the sender of that media to reduce the bitrate on one of the media channels. This in turn, will reduce the quality of the encoded data, reduce the frame-rate or the resolution – again, based on the sender’s own internal policies.
The diagram below illustrates the flow the receiver will use for the bandwidth estimation algorithm.
While this is the “industry standard”, there are a few soft spots with this solution that I want to point:
So you see: there are things we can improve. The main thing being able to “know” the available bandwidth before congestion occurs. While we haven’t yet developed our prophetic module here in RADVISION, we actually did come close when we talk about bandwidth estimation; but this will be the topic of my next post: how do we estimate bandwidth based on network delays.
Article printed from VoIP Survivor: http://blog.radvision.com/voipsurvivor
URL to article: http://blog.radvision.com/voipsurvivor/2011/08/18/netsense-101-part-2-packet-loss-based-bandwidth-estimation/
URLs in this post:
 NetSense 101: Why do we need bandwidth estimation?: http://blog.radvision.com/voipsurvivor/2011/08/11/netsense-101-part-1-why-do-we-need-bandwidth-estimation/
 NetSense 101: Delay-based Bandwidth Estimation: http://blog.radvision.com/voipsurvivor/2011/08/24/netsense-101-part-3-delay-based-bandwidth-estimation/
 NetSense 101: Q&A: http://blog.radvision.com/voipsurvivor/2011/08/31/netsense-101-part-4-qa/
 RTP: http://community.radvision.com/glossary/RTP/
 RTCP: http://community.radvision.com/glossary/RTCP/
 congestion and corruption types of packet losses: http://blog.radvision.com/voipsurvivor/2010/09/30/the-three-types-of-packet-losses/
 bufferbloat problem: http://en.wikipedia.org/wiki/Bufferbloat
 I-frames: http://community.radvision.com/glossary/Intra_Frame/
Copyright © 2010 RADVISION Blogs Network. All rights reserved.