[xiph-rtp] Section 6, Congestion (Re: xiph-rtp Digest, Vol 3, Issue 9)

[Phil Kerr]

Hi Michael,


Michael Sparks wrote:

>On Friday 31 Dec 2004 20:00, xiph-rtp-request at xiph.org wrote:
>...
>  
>
>>I've just updated the -04 Vorbis-RTP I-D.  Changes include:
>>    
>>
>
>Just reading the draft, and I've come across section 6:
>
>[ If I have specific comments on a section I'll start a separate thread in the
>hopes that's easier. I'll try and do them one at a time though :) ]
>  
>
No probs :)

>  
>
>>6.  Congestion Control
>>
>>   Vorbis clients SHOULD send regular receiver reports detailing
>>   congestion.  A mechanism for dynamically downgrading the stream,
>>   known as bitrate peeling, will allow for a graceful backing off of
>>   the stream bitrate.  This feature is not available at present so an
>>   alternative would be to redirect the client to a lower bitrate stream
>>   if one is available.
>>    
>>
>
>One issue here is that RRs are supposed to be sent to the session. In a
>multicast RTP session for an A/V conference (or similar application) this
>makes a lot of sense. In moderate scale unidirectional streaming using
>multicast it still makes sense.
>
>In the large scale unidirectional streaming case, this becomes problematic
>(unless you either don't implement this SHOULD or you don't send to the
>session - I doubt either can be guaranteed by this section).
>  
>
Although a large-scale unidirectional is more of an edge case for RTP 
usage, it's certainly a usage scenario that needs to be considered.

>Consider:
>
>   * Reciever report size: 128 bits
>   * Average dialup user connectivity: 40Kbits/s (40960 bits/s)
>   * Maximum Reciever Reports per second: 320 (assuming the unrealistic scenario of no __data__)
>   * Maximum suggested time period between Reciever Reports: 5 minutes - 300 seconds
>   * Number of Receiver Reports in suggested time period: 96000
>
>That suggests a maximum of 96000 people in a single session (unless you
>exclude dialup users). Whilst this may seem a large number this is just a
>factor of 2 (ish) away from the number of people who watched the BBC's
>online streaming live, concurrently, when Saddam's statue was being toppled.
>
>Given multicast is being deployed by more ISPs in the UK as the BBC makes
>more content available via multicast this is a real issue.  (From our
>perspective multicast is being deployed as a means of making traffic
>levels of 96K, 200K, 400K, 500K practical.)
>
>With broadband this becomes less of an issue, HOWEVER...:
>
>Average DSL user connectivity: 512Kbits/s (524288 bits/s)
>Assume multicast content bitrate: 370 kbit/s (this is the bit rate we
>multicasted at during the olympics)
>Remainder: 142 Kbits
>Number of Reciever reports: 142/40 * 96000 = 340000 (rounding down)
>
>Again I'm not suggesting this is going to be anywhere near the common case
>for Vorbis & RTP, however I would suggest it's worth considering. 340,000 isn't
>really such a large number from a large scale media provider. 
>
>Currently (obviously) we're using proprietary systems with proprietary
>protocols rather than open protocols in online streaming but in order for
>this to have the option to change, the protocol does need to scale to these
>levels. (Or use a different protocol of course :)
>
>Also, I'm not about to suggest that this section be removed, since receiver
>reports are used very effectively in a variety of applications, not just the
>specific example provided, (such as group clock sync) however I *would*
>suggest we need a way of flagging when such messages _MUST NOT_
>be sent. 
>
>I'm wary of suggesting any method of flagging this up at this stage however
>before hearing other people's opinions...
>
>You could argue that a "SHOULD" theoretically protects you against this, but
>personally I doubt this will be the case.
>  
>
The handling of RR's for a large number of session clients is tricky, as 
you rightly point out that you do not want to be swamped with this 
return data. Section 6.2 of RFC 3550 covers the details of handling this 
data and the SHOULD in the Congestion section of the Vorbis draft is 
governed by this (even though it does not explicitly point back to 
3550).  Something more explicit, or a direct reference to section 6.2 in 
3550, can be added.  This doesn't provide a guarantee of conformance, 
but at least this particular base has been covered.

>  
>
>>Have a happy New Year and all the best for 2005.
>>    
>>
>
>Likewise, and good luck to everyone in their respective projects :)
>
>Regards,
>
>
>Michael.
>  
>

Best regards

Phil