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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Dec 2003 17:57:18 -0500

Mark

The reality of networks these days is that plain jane best effort 
Internet doesn't make much money.  Premium services do.  So the 
trend, which is clearly not universal, but is pretty obvious, 
is that SPs are trying to bring new bandwidth users onto their 
networks where the extra bandwidth is not just more bits, but 
for which they can charge for service beyond best effort packet.

Voice is one of those services, and video is one of those 
services.  You don't see a whole lot of investment these days 
in plain Internet service, and you do in voice/video over IP 
networks.  So, while there are pure play best effort operators 
out there, and they will be there, the money is in the premium 
services.  Even if an ISP does not directly provide premium 
services, other SPs will, using the underlying packet carrier
as the pipe, and the USERS of the premium services will yell 
loudly if their premium services are not delivering what they 
pay for.  If a customer of voice/video service gets told that 
his pipe provider is intentionally degrading his service, what 
do you think he will do with his pipe business?

Everyone agrees, I think, the most desirable situation is 
one in which we have a true converged network, not overlay 
networks, not separate networks, for these new services.  
I'm sure that there will be a lot of overlay networks around 
for quite a while, because we don't have the mechanisms we are 
discussing here - ways for classic best effort TCP to co-exist 
well with real time media.  Everyone wins if we figure out good 
ways for this to happen.  Everyone loses if any SP starts 
intentionally degrading one kind of service to make another
kind of service work better.  That's why I don't think it's 
going to be common to stomp on media OR TCP.  Rather, I think 
everyone expects us to do our jobs well and make both kinds of 
streams work well together.

We aren't going to solve this problem with anything done on one side
folks; both sides are going to have to have new mechanisms.

Brian

> -----Original Message-----
> From: Mark Allman [mailto:[email-masked]]
> Sent: Monday, December 08, 2003 5:02 PM
> To: Rosen, Brian
> Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
> Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
> dis tribution? 
> 
> 
> 
> 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
> 
> 
> --
> 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: Henning Schulzrinne <[email-masked]>
Date: Mon, 08 Dec 2003 19:49:44 -0500

I think the whole notion of fairness and value also needs to be looked 
at in a more differentiated fashion. Some of this has been alluded to, 
by Mark and others, but there seem to be at least three bottleneck cases:

- 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. Having a queueing mechanism 
that ensures that TCP does not get starved, but can use available 
bandwidth, would seem to address most needs, without an explicit 
reservation mechanism. If I asked for an N Mb/s video stream, I 
presumably know what I was doing and really wanted this. If I don't like 
the webbrowsing speed while watching the video, I'll turn it off.

- multiple subscriber, but local bottlenecks, e.g., the access link 
owned by the business or university. Single-session TCP fairness makes 
very little sense since it simply encourages the use of multiple TCP 
sessions. Also, from a user experience perspective, why should 
instantaneous fairness be the right metric? I suspect that most people 
would consider long-term metrics as far more appropriate, e.g., their 
monthly bit budget. After all, this is what determines the overall 
expenditure of resources, at least for large multiplexing.

For example, at Columbia, we switched from limiting the instantaneous 
bandwidth available to dorms to a monthly bit budget. Exceed it, and get 
put into the low-priority queue. This seems to work pretty well and 
avoids having to distinguish 'good' from 'bad' traffic. I suspect that a 
simple end system or access router policer that rate-limits 
non-responsive traffic will do ok for large user populations. Thus, no 
sending of UDP at 100 Mb/s to the Internet or I2, but few applications 
seem to need that. This again requires no resource reservation if the 
traffic engineering can be made to work.

- bottlenecks elsewhere: there, session-level instantaneous fairness is 
probably the best we can do. However, US backbone providers claim very 
low average packet loss rates (below 1%), so it doesn't seem to be the 
network part throttling TCP at this point. If this is not true, we have 
a real problem that requires either an explicit business decision of the 
kind that Brian advocates or, conversely, penalty measures that 
discourage high-rate UDP flows.