[Standards] Coping with low bandwidth channels in Jingle

[Paul Witty]

Paul Witty wrote:
> Peter Saint-Andre wrote:
>> 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='juliet at capulet.com/balcony'
>>     id='active1'
>>     to='romeo at montague.net/orchard'
>>     type='set'>
>>   <jingle xmlns='urn:xmpp:tmp:jingle'>
>>           action='session-info'
>>           initiator='romeo at montague.net/orchard'
>>           sid='a73sjjvkla37jfea'>
>>     <packet-loss xmlns='urn:xmpp:tmp:jingle:apps:audio-rtp:info'/>
>>   </jingle>
>> </iq>
>>
>>   
> I'd have to question the namespace, as the message is relevant on 
> video rather than audio channels.  Apart from that, it seems fair 
> enough, although if multiple video channels are open (as seems to be 
> permitted by the spec), it may only be necessary to send a keyframe on 
> one of those channels, so specifying the channel experiencing packet 
> loss could offer a saving in bandwidth.  Presumably the spec will say 
> that a client receiving such a message must either return an iq_error, 
> or must send an iq_result and send a keyframe over the video channel?
>
And to reply to myself, receiving packet loss does not imply the 
bandwidth should be dropped.  A single dropped packet can mess up the 
video sufficiently that a new keyframe is needed, but if 99.9% of the 
packets are coming through just fine, we shouldn't lower the bandwidth, 
so requests for keyframes should be distinct from, and not imply, a 
change in the advertised receive bandwidth.

-- 

Paul