[Standards] Coping with low bandwidth channels in Jingle

Paul Witty paulrw at codian.com
Wed Feb 13 14:13:33 UTC 2008


Dave Cridland wrote:
> On Wed Feb 13 13:13:26 2008, Lauri Kaila wrote:
>> If I understood you, a client should know its network capacity. Then
>> it tells that infromation to the other end so they can agree on the
>> best media fromat that doesn't exceed the limit. But isn't it almost
>> impossible to know actual end-to-end bandwidth beforehand unless some
>> kind of QoS is present?
>
> Sometimes the user knows the bandwidth of the immediate upstream link. 
> Often, though, they don't - people usually know the advertized maximum 
> downlink bandwidth, but usually don't know either the upstream, nor 
> the actual bandwidth of either direction.
>
> The actual device may know it's immediate link rate. Sometimes, at 
> least - often actual link rates are deeply buried inside weird APIs, 
> and finding overhead, latency, and other somewhat related link 
> characteristics isn't usually possible.
>
> But there is indeed no practical way to know the end to end bandwidth 
> short of measuring it, and that measurement is quite tricky. There's a 
> very interesting paper on the subject of intermediate link measurement 
> by van Jacobson, actually. People interested in this sort of thing can 
> probably find it with a Google for pathchar, or download pchar (an 
> open source implementation). You'll note it takes several minutes for 
> each hop, and uses quite a bit of traffic to do so.
Fortunately, actually knowing the bandwidth is not necessary:

while (incoming_packet_loss)
{
    advertise_less_bandwidth();
    wait_for_a_bit();
}

-- 

Paul





More information about the Standards mailing list