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

Tue May 30 18:04:57 PDT 2006

Why can't you just use RFC 3556 and specify no bandwidth for the RR packets?
I don't see why the Vorbis payload spec itself needs to address this. You
concerns appear to be an RTCP issue that is independent of payload format.

Aaron

On Tue, Feb 14, 2006 at 11:03:53AM -0000, Michael Sparks wrote:
> > 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.
> 
> 

> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp