[Iccrg] IETF plenary: fast timescales
Richard_Woundy at cable.comcast.com
Wed Aug 11 19:38:34 BST 2010
> Ok, you were overselling the cable tv access layer. The reasoning
Actually, edge congestion was fairly uncommon, so I would disagree with
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
/>, 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.
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
Mikael Abrahamsson email: swmike at swm.pp.se
More information about the Iccrg