[Iccrg] IETF plenary: fast timescales
Woundy, Richard
Richard_Woundy at cable.comcast.com
Wed Aug 11 17:07:41 BST 2010
>> Up until about a year ago, this was becoming more acute with ever
>> rising P2P traffic, motivating the recent actions from Comcast.
> Poor comcast. Err.. no, the other way around, poor users who actually
try
> to use the bw comcast promised them. Again, if you're congesting the
core
Thanks for the (fake) sympathy. Comcast wasn't congesting its core --
but hey, believe what you want.
-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On
Behalf Of Mikael Abrahamsson
Sent: Wednesday, August 11, 2010 11:32 AM
To: iccrg at cs.ucl.ac.uk
Cc: joelja at bogus.com
Subject: Re: [Iccrg] IETF plenary: fast timescales
On Wed, 11 Aug 2010, ken carlberg wrote:
> lucky you. try spending time in South America, where economics still
> puts a significant downward pressure on traffic between tiered
providers
> egressing a country/region. Or, try other spots along the pacific
rim.
> Point being that the entire Internet doesn't have the luxury of
> significant over provisioning -- which was the point of one of the
> speakers.
You don't need to significantly overprovision, you need to assure that
at
whatever bw/pricepoint you choose, you can afford to upgrade the network
if the customers actually use the bandwidth they buy. If you can't,
you're
doing it wrong. Don't blame the users for actually using the access
bandwidth you're giving them.
If you don't want them to use bw for prolonged periods of time, use
CIR/PIR in your policer and allow 30 second bursts, then police it to
the
lower level where you're not congesting your core.
Again, ISPs who congest their core are cheating their users.
> and speaking of which, one tool you didn't mention is MPLS (aka,
traffic
> engineering). This is done in part because one can't over-provision
to
> satisfy the sum capacity of all leaf links.
You don't need to, you just need to provision enough so that the
statistical probability of congestion is extremely low. Congesting for
hours on end every day is not a "oops, something went wrong"-event, it's
cheating the customers.
> Up until about a year ago, this was becoming more acute with ever
> rising P2P traffic, motivating the recent actions from Comcast.
Poor comcast. Err.. no, the other way around, poor users who actually
try
to use the bw comcast promised them. Again, if you're congesting the
core
you've sold more to your customers than you can handle, so you either
need
to upgrade or lower the speed per user. This of course would mean not
being competitive in the market, so instead of doing the right thing,
they
chose to skimp on the bw actually delivered.
> you make some good points, and I would agree that barring the back-hoe
> problem (or other disasters that damage infrastructure), one should
> mostly see congestion closer towards the customer access links. But I
> would just contend that the picture you paint isn't complete.
It's not complete for some people, but I contend that these people are
trying to sell high and deliver low, and that's not ok. Their customers
need to be able to see what's going on, we shouldn't let them get away
with it.
--
Mikael Abrahamsson email: swmike at swm.pp.se
_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
More information about the Iccrg
mailing list