[SUGGESTION] ECN match/target

[Oskar Andreasson]

Hi all,

I have a brief suggestion for a match/target which I am unable to to =
write myself of many reasons, mainly that I am a very very lousy coder =
=3D). If someone is already working on this, disregard from this mail.

What I would like to propose is an ECN match/target. During the last =
days, I've read through a couple of RFC's and that's where this request =
stems from. If anyone else finds this interesting and has a little bit =
better coding habit than I... Basically, I have read or at least scanned =
through RFC 1323, 2018, 2883, 2884 and 3168 and I believe this is =
possible after thinking it through, but I hope anyone else can comment =
on feasibility.

First off, I have yet to finish up on reading RFC 3168 so I am not quite =
sure if what I would like to propose will break current standards but =
... =3D)

I would first of all like to see a match that makes it possible to match =
packets based on their ECN values as described in RFC 3168, or possibly =
on any value that the ECN field may take.=20

I would also like to see a target that lets us set the ECN values. As =
with the FTOS and TOS targets, I would generally believe the TOS type of =
match would be better (ie, it would block the user from setting =
ridiculous values that are more or less not valid according to RFC =
3168.).=20

AFAIK, this would include the following settings:

00 Not-ECT
01 ECN Capable Transport(1)
10 ECN Capable Transport(0)
11 Congestion Experiences (CE)

These extensions would make it possible for us to:

1) Reset all ECN enabled packets leaving a specific network or going to =
a specific network.
2) We can use this match to match packets leaving the firewall and =
possibly do specific routing to get around misbehaving routers/firewalls =
blocking ECN enabled packets.
3) Possibly mark packets based on their CE values and make it slant over =
to other routes. Ie, we receive CE packets and we can then set a special =
mark on packets and hence give another route higher priority. Another =
solution would be to use some sort of userspace queue which would =
rewrite the routing entries to give another route higher priority.

A huge set of other possibilities? Of course, we would also be able to =
ECN enable our local networks without worrying about other networks such =
as the Internet. According to RFC 2884 this should give approximately =
20-60% better throughput under moderate through heavy congestion, if I =
am not totally off=3D). Packets destined for the Internet could then be =
reset to Non-ECT. On larger networks this could possibly be of some =
interest...

Any comments on this, am I totally off or is this actually possible =
without breaking all protocols available? Anyone willing to undertake a =
project like this?

Have a nice day,

Oskar Andreasson
http://www.boingworld.com
http://people.unix-fu.org/andreasson/
mailto: blueflux@koffein.net