FW: ISPs slowing P2P traffic...

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Tue Jan 15 09:43:03 UTC 2008


On Tue, 15 Jan 2008 17:56:30 +0900
Adrian Chadd <adrian at creative.net.au> wrote:

> 
> On Tue, Jan 15, 2008, Mark Smith wrote:
> 
> > But the fat man isn't allowed to take up residence in the restaurant
> > and continously eat - he's only allowed to be there in bursts, like we
> > used to be able to assume people would use networks they're connected
> > to. "Left running" P2P is the fat man never leaving and never stopping
> > eating.
> 
> ffs, stop with the crappy analogies.
> 

They're accurate. No network, including the POTS, or the road
networks you drive your car on, are built to handle 100% concurrent use
by all devices that can access it. Data networks (for many, many years)
have been built on the assumption that the majority of attached devices
will only occasionally use it.

If you want to _guaranteed_ bandwidth to your house, 24x7, ask your
telco for the actual pricing for guaranteed Mbps - and you'll find that
the price per Mbps is around an order of magnitude higher than what
your residential or SOHO broadband Mbps is priced at. That because for
sustained load, the network costs are typically an order of magnitude
higher.

> The internet is like a badly designed commodity network. Built increasingly
> cheaper to deal with market pressures and unable to shift quickly to shifting
> technologies.
> 

That's because an absolute and fundamental design assumption is
changing - P2P changes the traffic profile from occasional bursty
traffic to a constant load. I'd be happy to build a network that can
sustain high throughput P2P from all attached devices concurrently - it
isn't hard - but it's costly in bandwidth and equipment. I'm not
against the idea of P2P a lot, because it distributes load for popular
content around the network, rather than creating "the slashdot effect".
It's the customers that are the problem - they won't pay $1000 per/Mbit
per month I'd need to be able to do it...

TCP is partly to blame. It attempts to suck up as much bandwidth as
available. That's great if you're attached to a network who's usage is
bursty, because if the network is idle, you get to use all it's
available capacity, and get the best network performance possible.
However, if your TCP is competing with everybody else's TCP, and you're
expecting "idle network" TCP performance - you'd better pony up money
for more total network bandwidth, or lower your throughput expectations.

Regards,
Mark.

-- 

        "Sheep are slow and tasty, and therefore must remain constantly
         alert."
                                   - Bruce Schneier, "Beyond Fear"



More information about the NANOG mailing list