[Iccrg] IETF plenary: fast timescales
swmike at swm.pp.se
Thu Aug 12 07:58:07 BST 2010
On Wed, 11 Aug 2010, Woundy, Richard wrote:
> It was the manner in which Comcast reacted to those congestion events
> (resets of P2P session) that needed to change.
Yes. My opinion is that it's ok for an ISP to drop and/or delay packets,
and change/reset DSCP values. Spoofing packets or otherwise change content
of packets on the customers behalf is something that should require the
customers' express wish and acceptance of this behaviour (WAN acceleration
> We've described a similar system which is deployed in Comcast today; see
> />, especially section 7.
While I on principle disagree with these kinds of systems, I can accept
them as a stop-gap measure until more capacity can be added. I think the
new system (detecting high users and re-marking their traffic so they get
a lower share of the total traffic on the CMTS segment) is a sound one.
> 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.
It's my opinion that this kind of system needs to be transparent (the user
knows and understands what's going on) and non-discriminating, and should
also give the best user experience possible under congestion.
For instance, on my own home connection I guarantee 25% of capacity to
packets that are less than 200 bytes in size (mainly to make sure my
ACKs/VoIP and ssh packets get thru), 25% to TCP/UDP packets destined or
sourced from a few ports (typically dns/ssh etc) and then I fair-queue the
rest. This works well and gives me extremely low latency for interactive
applications even though I have several TCP sessions running that fill up
the link completely. Fair-queue is a feature present in Cisco cpu based
platforms and keeps a kind of state for TCP flows so this doesn't really
scale, but it's also not really needed, the packet size/L4 information is
quite enough to give good interactive performance.
On the topic of who is a "heavy user" that's a good question and not
something that can be universally answered in a single way. My opinion is
that you're on the right track where you're looking at who is contributing
to congestion right now and not historically, and that one should mainly
aim at stopping prolonged congestion to low users (subsecond congestion
doesn't hurt as much interactively), so identifying people who sent a lot
of traffic during the past 5 minutes and identifying that congestion
occurred, then if prolonged congestion is likely to be happening again in
the next 5 minutes lower the priority of the high user traffic so they get
lower priority on access to the shared access bandwidth. If per-packet
differentiation can be done, the TCP file transfer sessions of the heavy
users might not even affect their interactive sessions (especially if
they're going in the other direction of the big data packets).
One recommendation from this group should also be that CPE (for instance
ADSL2+ routers) manufacturers are able to do intelligent queuing in the
upstream direction of their devices. I don't know how many times people
have complained that they can't get any decent download speed while they
are uploading. Their speed is limited by their ACKs being stuck 1-2
seconds in the FIFO outgoing buffer going upstream. Even really simple
queuing as I described above would really improve interactive performance.
Mikael Abrahamsson email: swmike at swm.pp.se
More information about the Iccrg