RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution?

This is why slow start won't work.  The media starts with constant
rate.  If you have to slow start, you have to either drop packets
or you have to buffer them, and as I have pointed out, once
you buffer CBR, you keep it.  The delay introduced is worse than
the buffer, so you will drop packets to make slow start, and clip
the "hello". 

What you are saying, it seems to me, is that we have solved 
existing problems by deploying slow start.  All the 
applications so far have judged slow start as acceptable.  
Along comes real time interactive media, and we say sorry,
slow start is not acceptable.

And you want to claim then that our applications can't be 
used on the Internet?

I would say that you haven't a prayer of stopping us.

We can address congestion collapse another way, so you can't 
use that as an excuse over why we need to move off of UDP.  
I think those of us with real time interactive media are 
very willing to adopt additional congestion control mechanisms 
that attempt to deal with "fairness" (which is not viewed the 
same way by TCP and real time media), so long as they don't 
destroy the app.  However, we aren't likely to adopt anything 
replacing UDP if it does destroy the app.

Brian

> -----Original Message-----
> From: Mark Allman [mailto:mallman@icir.org]
> Sent: Monday, December 08, 2003 10:00 AM
> To: Rosen, Brian
> Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org
> Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
> distribution? 
> 
> 
> 
> (gluing together two things that I can't get to jive together in my
> head) 
> 
> > A typical RTT on the internet these days is 50-100 ms.  If you
> > experience 30% loss in the first 3 RTTs of voice, you will clip the
> > "hello" pretty badly.  If it's 7-8 RTTs, you will definitely have a
> > very poor experience.
> 
> I do not understand where this 30% loss number comes from.  If a host
> experiences 30% loss the network is *quite* congested (recent
> measurments I have done show that loss rate over 10% are very rare in
> the Internet) or the connection is crossing a very ratty error-prone
> link.  I think the latter is unlikely in the general case.  So, how
> would this:
> 
> > Yep; bang! 0 to 4Mbit in two packets.
> 
> be useful?  If you're already clipping "hello" then this is going to
> provide a very lousy experience, right?
> 
> Others have said it already, so I'll just briefly agree: In a
> best-effort network I do not think any particular flow (TCP or DCCP or
> UDP or SCTP or whatever) should be able to just start sending 
> at a "high
> rate" (where "high rate" is undefined, but 4Mbps is certainly 
> high).  I
> think it would not be terribly difficult to show that such behavior
> could easily cause problems (to competing TCP, to competing streaming
> flows and to the flow that is doing this "instant on").  Slow start is
> the current consensus for how to start from zero.  Could 
> there be other
> schemes?  Sure.  Are those here and fully fleshed out such 
> that we could
> even consider them as potential solutions?  Not right now.  
> 
> My hunch is that sending DCCP (/anything) through without 
> slow start is
> not going to work (i.e., I think consensus would be against 
> that).  So,
> if your app can't deal with that then I think we might be stuck ...  A
> more general wondering of mine is how many streaming apps require this
> "instant on" behavior (i.e., is your app an anomaly or is 
> there a whole
> class of apps that want instant-on over best-effort networks?)?
> 
> Thanks!
> 
> allman
> 
> 
> --
> Mark Allman -- ICIR -- http://www.icir.org/mallman/
> 
> _______________________________________________
> dccp IETF mailing list: dccp@ietf.org
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
> 

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt