[xiph-rtp] RE: Updated drafts available, please review (Luca Barbato)

[Michael Sparks]

> Subject: xiph-rtp Digest, Vol 17, Issue 1
> ...
> From: Luca Barbato <lu_zero at gentoo.org>
> Subject: [xiph-rtp] Updated drafts available, please review
> To: xiph-rtp at xiph.org
> 
> I'm going to submit the drafts the next Monday, please read and comment.
> There weren't any major changes in the latest weeks so I hope you will
> just pick some typos and still unclean paragraphs.

Just skipping through this to see if the concerns we'd had have been dealt
with, and noticed that the only reference to our (blocker) problem with using
this have been dealt with as follows:

=========================
7.  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.

   If a particular multicast session has a large number of participants
   care must be taken to prevent an RTCP feedback implosion, [10], in
   the event of congestion.
=========================

The lack of an ability for a sender to indicate that a client MUST
NOT send RTCP information, because we're not the slightest bit
interested in it and it will ONLY cause congestion means that
we're still unable to use this. I'm a little disappointed to see
this, but it doesn't preclude an alternate implementation that
doesn't cause problems in a large scale unidirectional streaming
environment.

Regarding the description as an RTCP feedback implosion, this is
inaccurate - the RTCP feedback is meant to be sent to all those
involved in the session. In a multicast environment, this is
problematic.

Our concerns about this have been raised several times, so I'll
assume that everyone else on the list is happy with this, and
not suggest the change I've mentioned above we would need in order
to use this  be made.

If you do, it opens up vorbis as an option for use over RTP by us
using this RFC. If you don't, we need to come up with something
that works for us, perhaps to feed into a later RFC. (After all,
nothing's permanent :)

However, given I'm more concerned about there being a standard that
we can all work forward from towards something suitable for niche's
including us (perhaps as a version 2, or alternate profile), there is
something in the draft which is problematic.

Specifically the reference for this same paragraph regarding congestion
control is this:

   [10]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
         "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
         Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
         progress).

This breaks a few no-no's.
   1) It's a reference to a draft - this is not ever considered
      acceptable in a final RFC.
   2) The draft expired early last year and has not been updated
      since - what's it's actual status? Rejected? 

I've found some work on simulation of this profile here:
   * http://www.ietf.org/internet-drafts/draft-burmeister-avt-rtcp-feedback-sim-06.txt

And it's summary paints a very nice picture...

   We have shown that for unicast and reasonable multicast scenarios, 
   feedback implosion does not happen.  The requirement that at 
   maximum 5% of the session bandwidth is used for RTCP is fulfilled 
   for all investigated scenarios. 

However, the simulations given are of toy systems with only a handful
of agents in the system. The largest number of participants was 16. (T16)
This is more than 3 orders of magnitude smaller than our average streaming
levels, and 6 orders of magnitude smaller than the streaming levels we would
expect to achieve via multicast.

(I was hoping, before I reached the section describing the sizes, that the
simulation sets would be more like 2, 16, 128, 1024, 65536, 1048576. Even
with the last of those, it would be preferable to step that up to 32x that
final figure)

I'd suggest finding an alternate reference. If you need some help, I'm
more than willing to help dig around for something more up-to-date (and
hopefully based on some more realistic network & group sizes)

Regards,


Michael (wishing he has something more positive to say)
--
Michael Sparks, Senior R&D Engineer, Digital Media Group
Michael.Sparks at rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system. 
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received. 
Further communication will signify your consent to this.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5479 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/xiph-rtp/attachments/20060214/1fe641b6/attachment.bin