[Iccrg] IETF plenary: fast timescales

[Mikael Abrahamsson]

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 
for instance).

> 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.

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).

Another topic:

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