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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Dec 2003 13:47:37 -0500

Henning had a message on these threads that pointed out that in
conferencing,
you don't send until you talk.  On a conference with 100 participants, you
only see 1-4 or so actually sending, but which 1-4 changes, sometimes
rapidly.
You can't slow start them when they start talking or you clip.

Another example is Push To Talk.

Another example of non-interactive media is channel surfing.
This one depends somewhat on implementation, but many implementations
have different channels coming from different servers.  

I don't want to seem unwilling to change our app, I am very willing
to change the app to better work on the Internet, but not if it
destroys the user experience.  I don't see a way to do that 
without modifying TCP.  If you assume TCP is fixed, and you need 
media apps to live with TCP as it is, I don't see how to do that, 
but I'm certainly eager to be shown how. 

My app is the 4M app, and there aren't many of us at the moment,
but if you saw it, you'd want it, and there is no reason it shouldn't
work on the Internet.  It does now, after a fashion.

And, as I've pointed out, since these kinds of apps represent much higher
revenue per bit that the TCP-type apps, it's much more likely that the
network operators would deploy TCP stompers than media stompers.
YMMV.

Brian

> -----Original Message-----
> From: Mark Allman [mailto:[email-masked]]
> Sent: Monday, December 08, 2003 11:36 AM
> To: Rosen, Brian
> Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
> Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
> dis tribution? 
> 
> 
>  
> > 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?
> > 
> > I would say that you haven't a prayer of stopping us.
> 
> 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.
> 
> 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.
> 
> allman
> 
> 
> --
> Mark Allman -- ICIR -- http://www.icir.org/mallman/
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Eddie Kohler <[email-masked]>
Date: Mon, 08 Dec 2003 17:49:55 -0800

Brian:
> I am very willing to change the app to better work on the Internet,

News to me. What kinds of changes are you willing to make?

Henning:
> - single subscriber bottlenecks, such as my DSL uplink; there, it should 
> be my decision as to whether I'd like to trash my TCP performance to 
> benefit UDP or not - I paid for that link.

> - multiple subscriber, but local bottlenecks, e.g., the access link 
> owned by the business or university.

> - bottlenecks elsewhere: there, session-level instantaneous fairness is 
> probably the best we can do.

Of course a single flow might encounter multiple bottlenecks.  In
well-provisioned backbones there may or may not be loss, but a lot of the
world doesn't work that way, and best-effort backbones probably won't grow
monotonically less lossy over time.

Eddie

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 Dec 2003 17:01:54 -0500

Brian-

> And, as I've pointed out, since these kinds of apps represent much
> higher revenue per bit that the TCP-type apps, it's much more likely
> that the network operators would deploy TCP stompers than media
> stompers.  YMMV.

I saw your assertion in response to Sally a while back in this thread.

But, I think we have a disconnect.  I am generally thinking in terms of
best-effort networks (as I think Sally was).  Further, a network that
has no priorities or traffic classes, but rather just tries its hardest
to get all the data across.  This is the kind of network where
congestion control is important.  And, this is the kind of network where
I think you'll see "stompers" that attempt to surpress flows that are
attempting to use a disproportionate amount of the bandwdith (whether
that be streaming or mis-behaving TCP or ddos floods or whatever).

Your claim above does not match my model of a best effort network.
I.e., if people are willing to pay more for the traffic of some
particular app and you provision appropriately then you no longer have
just a dumb best-effort network.  If you can engineer a network and
provision appropriately then by all means use UDP and go from zero to
4Mbps instantly.  However, I don't see that as supporting the assertion
that DCCP can't be used for streaming across best-effort networks that
are not engineered to give different levels of support to different
classes of traffic.

allman