[Iccrg] IETF plenary: fast timescales

[Woundy, Richard]

> Ok, you were overselling the cable tv access layer. The reasoning
still stands.

Actually, edge congestion was fairly uncommon, so I would disagree with
your characterization.

It was the manner in which Comcast reacted to those congestion events
(resets of P2P session) that needed to change.

Moving from the topic of Comcast to more general discussion, let me
discuss your original points:

> Also, the best and easiest way (which is also net neutral) to solve
congestion is to make sure that the heavy users either mark their
packets as low priority (or it can be marked for them by means of having
a different type of subscription) and queue accordingly

We've described a similar system which is deployed in Comcast today; see
<https://datatracker.ietf.org/doc/draft-livingood-woundy-congestion-mgmt
/>, especially section 7.

But the core issue (with respect to the conversation about Conex) is in
how you define "heavy users". Is it by volume of recent traffic? If
someone sends a large volume of traffic into the network, but doesn't
cause congestion, should they be penalized? The Conex premise is to
identify "heavy users" by their contribution to congestion, not by their
volume of traffic.

> Congestion is rare because bad performance is not tolerated by the end
users and they switch providers.

Keeping congestion rare is my goal too.

-- Rich

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
Sent: Wednesday, August 11, 2010 1:40 PM
To: Woundy, Richard
Cc: iccrg at cs.ucl.ac.uk; joelja at bogus.com
Subject: RE: [Iccrg] IETF plenary: fast timescales

On Wed, 11 Aug 2010, Woundy, Richard wrote:

> Thanks for the (fake) sympathy. Comcast wasn't congesting its core -- 
> but hey, believe what you want.

Ok, you were overselling the cable tv access layer. The reasoning still 
stands.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se