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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Dec 2003 11:06:14 -0500

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:[email-masked]]
> Sent: Monday, December 08, 2003 10:00 AM
> To: Rosen, Brian
> Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
> 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: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2003 18:07:20 +0100

Hi,

> And, I'd still love to hear from others as to whether this "instant-on"
> is a requirement across the board or whether you're a special case.

Okay, my view on this topic about the instant-on is the following.

Streaming applications, i.e. with buffers, should do reasonably well 
with a slow start as it will most likely only effect the initial 
buffering delay.

When it comes to interactive real-time applications, i.e. without 
buffers, I think the Brian's view is mostly correct. All applications in 
this area does need to try to transmit at there lowest supported 
bit-rate initially. Then the question is what the lowest bit-rate is. It 
is not 4 mbit as somebody claimed for a high-rate conferencing 
application. Because in that case there exist techniques that will allow 
one to use a slow starting type of performance, which trades initial 
video quality against bandwidth during the slow start. For the 4 mbit 
video stream the initial bit-rate may be 256-512 kbits or possibly even 
lower. This will be a very coarse quality. but as one continues to 
transmit during the slow start and discover more bit-rate one can 
increase the quality. And I don't see this as having the same user 
problems as bit-rate switching is claimed to have. I think that any user 
of a circuit switched video telephony client are rather used to this 
behaviour, when major changes in video happens.

It will be a bigger problem for certain high quality audio codecs that 
are used. If the codec does not support to do bit-rate/quality 
trade-offs then it probably not very suitable for usage in these best 
effort networks. There exist codecs that will allow reasonable bit-rate 
steps to be used.

I think that the realistic thing in this environment is to be reasonable 
in both directions. I think that one has to understand that one a best 
effort network the media apps can't continue to behave irresponsible and 
simply blast away with UDP. It is better to start accept the fact that 
there will be need for a trade off. Then, if one needs to blast away, 
then one needs to develop more solutions or use resource reservation.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 Dec 2003 11:36:29 -0500

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

No, I was not saying that slow start has solved all the problems.  Are
there potential other methods to do startup?  Certainly there are.  Are
there new reasons to think about different ways to startup?  Probably.
But, I don't think any new startup method is currently baked enough
(and, certainly I don't think any of them have been introduced in the
IETF as baked and ready to go).  That does not mean that I think slow
start is the way to go forever.  That is just a pragmatic statement of
my feeling that the consensus of the community is that slow start is the
way to initiate transmission in the current best-effort Internet.

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

Look, I'm not trying to pick a fight.  This Internet thing is a big
cooperative.  You are writing an app.  I cannot stop you from writing it
or running it on the public Internet.  But, if the app does bad things
to networks then the operators can and will do something about it.
(E.g., look at what has been done to p2p stuff on college campuses.)
And, we know that CBR UDP apps have the potential to do a bunch of
damage.  So, it seems that DCCP has its place.

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

"Destroy the app" is one end of the spectrum, I think.  "Not impact the
app at all" is the other.  And, the answer is likely somewhere in
between. 

In the end, congestion control is not about getting exactly what each
app desires.  It's about keeping the network working in a reasonable
fashion so that all the apps get reasonable performance.

allman