Michael Sparks
2005-01-04 11:53:58 UTC
On Friday 31 Dec 2004 20:00, xiph-rtp-***@xiph.org wrote:
...
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 :) ]
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).
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.
Regards,
Michael.
...
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 :) ]
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 aVorbis 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.
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).
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.
Have a happy New Year and all the best for 2005.
Likewise, and good luck to everyone in their respective projects :)Regards,
Michael.
--
Michael Sparks, Senior R&D Engineer, Digital Media Group
***@rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP
This e-mail may contain personal views which are not the views of the BBC.
Michael Sparks, Senior R&D Engineer, Digital Media Group
***@rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP
This e-mail may contain personal views which are not the views of the BBC.