Re: [p2pi] One more proposed definition of fairness...

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

On Jun 9, 2008, at 9:20 AM, Joe Touch wrote:
>>>
>> Actually, I disagree here, for the following reason:
>> a:  The endpoints have a proven in practice bad notion of  
>> fairness:  They have TCP flow fairness (which can and is abused by  
>> some users, who eg, transfer on many torrents simultaneously), or  
>> (with crap like Joost) no fairness at all.  Why should someone  
>> who's playing by the "rules" (a few TCP streams) have to compete  
>> against users who aren't (many TCP streams or UDP based volume  
>> protocols without congestion control)?
>> Flow rate fairness is not user fairness.
>
> Right. But what is enforced depends on what the user paid for...
>
>> b:  More importantly, in the flat rate pricing world, if a fairness  
>> mechanism which allocates traffic between users is such that 90% of  
>> the users DON'T experience significant long-term congestion, the  
>> ISP is actually properly provisioned, not underprovisioned.
>> It does not make economic sense to up capacity to serve just 5-10%  
>> heavy-tail of the users, as those 5-10% of the users aren't paying  
>> any more than the 90%.
>
> I don't care what "economic sense" it made for the ISP. If it sold  
> me X Mbps, it had better provide that. If there's upstream  
> congestion, that's another issue, of course. But if not, if you sell  
> me X Mbps, I had better get it.

Fairness only needs to be enforced when there is congestion.  So  
what's the problem?

No congestion, you get your X Mbps.  Your bits flow and you are happy.

With congestion, you get a defined fair allocation, averaged out over  
say, 1 second to 1 hour.

>> If this is the case, ISPs need to either prevent the heavy-tailed  
>> users from affecting the rest (fairness, app-discrimination, usage  
>> caps) or charge the heavy users more (usage-based pricing) to  
>> justify the cost of an expansion which only benefits these users.
>
> AND define what they're selling better. Don't sell me a gallon of  
> gas which is a gallon UNLESS there's a run on gasoline. I don't care  
> about *your* economic implications of heavy-tails on your  
> provisioning model. I care about getting what I paid for.
>
> Once I pay for X Mbps, you can throttle ALL my stuff, but not just  
> TCP, and not per-flow or anything else. If you do, you're not  
> selling me Internet access, you're selling me a single TCP  
> connection or somesuch, and nobody would buy that.

If you want X no matter what anyone else is doing, you buy business  
grade service with an SLA and lose statistical multiplexing.  Just be  
prepared for sticker shock.

There is a reason such a product is not sold to consumers: statistical  
multiplexing is a huge win in cost-savings, but it means you can only  
guarentee a number much MUCH smaller than X.  EG, Lariat is very open  
about their pricing and does provide such guarentees.  Going from a  
guarenteed 256 Kbps to a guarenteed 512 Kbps doubles your cost from  
$40 to $80 [1]!


If, instead, you REQUIRE that an ISP allocate a 16 Mbps channel for  
your exclusive usage, you would see the bill jump by 5x-10x easily.

So yes, you should care about your ISP's cost and business model.   
Even if they have a 50% profit margin, any change which would up their  
costs by a factor of 10, and they only passed on the actual costs,  
would see your bill jump by 5x!


Also, with all the pushback against fairness, I see way the ISPs want  
to go to bandwidth caps and bill-released bandwidth caps instead:  
Rather than trying to make the network work with the 5%ers, just cut  
off the 5%ers!

If it happens to disrupt video-on-demand services (which it will,  
bigtime), consider it a bonus.


[1] And its not like thats pure profit either.  Brett Glass is open  
about his own prices, and claims that it costs him $100/Mbps-month, so  
the MINIMUM price difference for the differentiation in service has to  
be at least $25.

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi