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

[Kevin McArthur <kevin@stormtide.ca>]

Barry,

You need to read more critically. The $30/movie claim is like a $40,000 
dollar iPhone bill. Possible, but utterly ridiculous.

The success of this for TW will largely depend on how evil they want to 
be about it. In Canada for example, most ISPs cap at 60 gigs/mo -- with 
a sort of soft limit [we'll send you a threatening letter suggesting you 
upgrade if you go over]. Practically no-one is affected, and I've never 
heard anyone ever complain about a bandwidth surcharge. The top level 
plans are 100 gigs/mo -- but even at that level you're talking sub 
$100/mo service. The usual overage charge _if_ you have a top level 
plan, is around $1/gig. (Which if you do the math is about what you paid 
for the first 100 in your plan)

The sky didn't fall here, and it didn't start imposing 5gb/mo caps on 
people who torrent all day. As you point out below, people would jump 
ship if the price point wasn't right -- so TW will get this right.

What this is, from a NN perspective, is a whole lot better than the 
alternative of fuzzy caps and restricted service. Plus, if I can get rid 
of that TB/mo kid down the block (who should really have a t1 or better 
dedicated line), I'm going to be a happy subscriber.

As for 'slowing down' heavy users, thats not very transparent, and 
borders on false advertising. It's also bad for the ISPs because when 
said power users' internet starts going slow they will 1) speed test 2) 
call the isp and bitch 3) tell everyone how slow and crappy the service 
is. Not a great way to win customers, and not a great experience for the 
user. I can't see why so many people would have a problem with paying a 
fair price and getting what they pay for.

One thing is clear though, TW should fire it's PR department because 
they really dropped the ball on this one.

Kevin McArthur




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.