[OT]Re: RTP Was: [vorbis] icecast2

[Marshall Eubanks]

Hi;

Gregory Maxwell wrote:
> 
> On Tue, Mar 06, 2001 at 08:47:13PM -0500, Marshall Eubanks wrote:
> > Gregory Maxwell wrote:
> > >
> > > On Tue, Mar 06, 2001 at 07:56:06PM +0100, Smörk wrote:
> > > > >Also there were rumors around a while back that icecast2 would support
> > > > >rtsp and possibly real. Is there any strength in these rumors?
> > > >
> > > > I'm not a icecast developer, but I think it's not unlikely that icecast
> > > > will support rtp. I don't see a reason why it should support RealMedia
> > > > streams? It's more likely, that there is is a Ogg/Vorbis plugin for the
> > > > RealPlayer.
> > >
> > > 'rtsp' (what the orignal poster said) is in IETF standard (RFC 2326), not
> > > just some propritary RealMedia standard. That said, icecast doesn't support
> > > it, but most likely because it's overkill.
> > >
> > > 'rtp' what you said, is also a IETF standard (1889).. Icecast doesn't do RTP
> > > because icecast is unicast (RTP is overkill for unicast and not widely used
> > > for that). Vorbis multicast (done by icecast or otherwise) will use RTP.
> >
> > RTP is useful for UDP, whether unicast or multicast. Any tcp based streaming
> > will be subject to TCP's slow start and congestion control, which causes the
> > annoying "rebuffering" of TCP unicast streaming. FWIW we plan to switch
> > our unicast streams to RTP/UDP in the near future.
> 
> It should be noted that the people responcible for backbone traffic
> engineering are becoming progressivly more annoyed with protocols that are

The people I know who run backbones want more traffic. The backbones are very
far from congestive collapse.

> not TCP-compatible (be it games, multimedia, file getters which use a large
> number of TCP connections).  The internet can not sustain a sizeable
> population of flows which do not at least use effective exponential backoff
> without collapse.
> 
> For a glimpse of the future, observe what this ALTQ implimentation can do
> with buckets judged to be suffcently not-TCP-like
> http://www.eecs.umich.edu/~wuchang/blue/ .
> 

RED is dead - see Christophe Diot's NANOG-21 presentation - 
http://www.nanog.org/mtg-0102/diot.html

Is BLUE actually adopted anywhere ?

> Slowstart is obviously stupid for multimedia. But simply dumping congestion
> control and avoidance is not an option.
> 
> --- >8 ----

It is far from clear that UDP streaming flows _should_ be made TCP like, and it is also
far from clear that this would be "fair" in any meaningful sense. TCP flow control is 
based on notions (such as filling the pipe for a RTT) that
just don't map well into UDP streaming, ESPECIALLY for multicast.

I would be wary of any scheme purely supported by ns - many simulations are too simplistic and show, e.g., oscillatory behavior not
seen in the commodity Internet. 

This does not mean that streaming congestion control is not going to be necessary as streaming flows come
to dominate Internet traffic; there are a lot of good "layered" schemes proposed
to achieve this. (I find VORBIS very interesting in this regard.) 
I might point out that the TCP congestive collapse of the 1980's was not
predicted much in advance AFAIK. In the IETF I have urged that the obvious simple steps be taken now, and
that complicated and unproven solutions be resisted, but I'm generally in a minority of order 1 :).

                                   Regards
                                   Marshall Eubanks

P.S. Here are some interesting recent papers

[Jeffay, 1999] Towards a Better-Than-Best-Effort Forwarding Service for Multimedia Flows,  K. Jeffay, IEEE Multimedia, 6, 84-88,
1999. The "long" version is available from 
http://www.cs.unc.edu/~jeffay/papers/IEEE-MM-99-long.pdf

http://www.ieee-infocom.org/2000/papers/74.pdf
ftp://ftp.cs.utexas.edu/pub/techreports/tr00-23.ps.Z

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 410
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : tme at on-the-i.com     http://www.on-the-i.com

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.