[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