Re: Coping with low bandwidth channels in Jingle

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

Paul Witty wrote:
> 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();
> }

Ah, in that case an informational message might be more
appropriate
(just tell the other side that you're experiencing packet
loss):

<iq from='julietcapulet.com/balcony'
    id='active1'
    to='romeomontague.net/orchard'
    type='set'>
  <jingle xmlns='urnmpp:t
mp:jingle'>
          action='session-info'
          initiator='romeomontague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <packet-loss xmlns='urnmpp:t
mp:jingle:apps:audio-rtp:info'/>
  </jingle>
</iq>