NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information

 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ NNSquad ] Re: NYT: Differing views on Time Warner'sBandwidth Cap Experiment


> This need not be a case of wealth
> transfers only - there can be value creation as well. In one simple
> world with a zero-sum-game, for every penny charged for over-usage, the
> average bill for others should go down commensurately.
> 
> A first Q to me is to what extent is or isn't this a zero-sum game?

In the US companies have a fiduciary responsibility to make as much money as
they can for their stockholders.  If you think Time Warner, or any ISP, will
reduce the price for Internet access for the "average Joe" who uses minimal
bandwidth to something that is comparable to India (even with exchange rates
and cost of living calculations included) you are mistaken.  The ONLY reason
why Time Warner is doing this is because it is a chance for them to make
more money.

You can have your opinion of what SHOULD and should not happen, but
realistically this is not how business in the US works.  Especially not in
the telephone / cable / DSL markets.  I have no special knowledge of this,
it is common knowledge.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697
  

> -----Original Message-----
> From: nnsquad-bounces+freimer=ctiusa.com@nnsquad.org [mailto:nnsquad-
> bounces+freimer=ctiusa.com@nnsquad.org] On Behalf Of Rahul Tongia
> Sent: Friday, January 18, 2008 12:59 PM
> To: Barry Gold
> Cc: Lauren Weinstein; nnsquad@nnsquad.org
> Subject: [ NNSquad ] Re: NYT: Differing views on Time Warner'sBandwidth
> Cap Experiment
> 
> As someone who's spent lots of time internationally, there are many
> tiered pricing plans for DSL. All you can use are often MUCH more
> expensive. BUT, the entry plans are dramatically cheaper, e.g.,
> $2-6/month in India.
> 
> So, if only a few percent of people are using up "too much" bandwidth
> perhaps a solution would involve congestion pricing and/or graceful
> degradation only for those who go above reasonable fair use caps.  Is
> there too much complexity in this? If I want to download something huge,
> there should be ways for the system/network to signal "off-peak"
> pricing. I think we need some new protocols/tweaks/out-of-channel
> signalling for that.  Given these are all happening on the last mile, it
> shouldn't be hard to program that in (in a layered, scalable, manner).
> 
> There are parallels in the power industry, where I use kWh any time of
> day (as a retail consumer) for the same price. If I knew, with minimal
> effort or better, automatically, when things were not only peak but
> expected to peak, I and my appliances could behave a little better (to
> the extent there's a win-win). Everyone can benefit if there is less
> peak capacity required. Of course, I need to see the numbers more (and
> we don't have transparency on this).   This need not be a case of wealth
> transfers only - there can be value creation as well. In one simple
> world with a zero-sum-game, for every penny charged for over-usage, the
> average bill for others should go down commensurately.
> 
> A first Q to me is to what extent is or isn't this a zero-sum game?
> 
> Rahul
> 
> ************************************************************************
> Rahul Tongia, Ph.D.
> Senior Systems Scientist
> 
> Program in Computation, Organizations, and Society (COS)
> School of Computer Science (ISR) /
> Dept. of Engineering & Public Policy
> 
> Carnegie Mellon University
> Pittsburgh, PA 15213 USA
> tel: 412-268-5619
> fax: 412-268-2338
> email: tongia@cmu.edu
> http://www.cs.cmu.edu/~rtongia
> 
> 
> 
> Barry Gold wrote:
> > Lauren Weinstein wrote:
> >> http://bits.blogs.nytimes.com/2008/01/17/time-warner-download-too-much-
> and-you-might-pay-30-a-movie/?ref=technology
> >>
> >
> > This is beyond stupid, and I hope TW gets smacked down by its customers
> > if and when they try this.  See my earlier post on what customers want.
> >
> > Item 1: No surprises.  A $30 surcharge on their bill is going to result
> > in a very unhappy user.  I know what Time Warner is thinking: when the
> > user sees a $30 surcharge on his cable bill, he'll buy a higher service
> > tier and we make more money.  Well, it's a lot more likely that the user
> > will
> >   a) Switch to satellite, DSL, or any other competitor he can find,
> >   b) Write his city councilman about turning the city into a hotspot
> > (some small cities already are)
> >   c) write his congressman about regulating cable prices.
> >
> > So the *best* likely scenario is that TW loses a customer.  Other
> > possibilities include losing a whole city of customers, or being turned
> > into a regulated utility like phone and electric service used to be (and
> > natural gas still is).  That's a nice niche, you always make a
> > guaranteed profit -- but your profits are pretty strictly limited.
> >
> > I hope TW and Comcast wise up, because frankly I *like* the current
> > (nearly) unregulated market.  But if they keep trying stunts like this,
> > they will feel like Wile E. Coyote when the anvil falls on him.
> >
> > I can hear Brett and others asking, so what _should_ we do when we have
> > one customer who uses 100 times as much as our average.  Answer:
> > graceful degradation.  Slow him down.  This can be done manually -- you
> > notice that user X is using more than most, so you re-program his cable
> > modem to a lower bit rate, and/or drop some of the packets destined for
> > him.  Or you can just make it automatic - the system notices when a
> > customer is using a large amount of bandwidth over a period of time, and
> > takes steps.
> >
> > And as I said elsewhere, I would favor allowing ISPs to modify the TCP
> > headers to reduce the window, even though strictly speaking it's a
> > violation of the protocol -- that header is supposed to be for
> > communication between the end-points.  But until we get protocol stacks
> > that actually _pay attention_ to Source Quench, I think this would be a
> > good way to limit bandwidth consumption.
> >

Attachment: smime.p7s
Description: S/MIME cryptographic signature