Re: [p2pi] One thought on "leech killing"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [p2pi] One thought on "leech killing"



On Jun 2, 2008, at 1:16 PM, Robb Topolski wrote:
>
> Nicholas Weaver <nweaver at ICSI.Berkeley.EDU> wrote:
> > a) Is it ok for ISP traffic management be limited to solely
> > benefitting their customers or must it ignore behavior that benefits
> > the rest of the aggregate that have the effect of penalizing ALL  
> their
> > customers?
>
> I maintain that prolonged periods of congestion mean that you've  
> already failed to manage the network.  Trying to figure out which  
> bucket of water to throw out before another is ignoring the fact  
> that the boat is sinking.
>

Or you throw off the suitcases full of lead...

Your argument works when the congestion's cause is a large fraction of  
the user base.  But when it is a small fraction of the user base and  
you maintain flat-rate pricing, it makes far more economic sense to  
employ traffic management techniques to prevent the heavy users from  
impacting everyone else.


For example, Comcast's problem is very clear: DOCSIS, even DOCSIS 3,  
is a shared medium across a large group of users.  So unless they are  
willing to pull fiber to the home [1], there is no miracle bandwidth- 
fairy that can come and solve their congestion problem: they HAVE to  
allocate that bandwidth between users in a way which maximizes the  
benefit for the maximum percentage of customers.

And DOCSIS 3 is only 4x the bandwidth per channel of DOCSIS 2: the  
Japanese have shown that even 100 Mbps fiber-to-the-home can get  
congested with P2P traffic.




[1] The only way fiber to the home happens is either government  
subsidies or when a Telco wants to break into the cable-TV business by  
pulling fiber and then getting a statewide license (Verizon).


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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.