Mr. Andreasson,
--- Oskar Andreasson <[EMAIL PROTECTED]> wrote:
> 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 =). 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 ... =)
>
> 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.
>
> 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.).
>
> 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=). 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?
Harald Welte wrote an ECN target a few weeks ago and then got rid of it
because of a b0rKed design. I think DSCP does everything your ECN target/match
can do, and I think it does more as well (not sure about this). Perhaps if your
ECN target has a better design than Harald's, maybe he'll use yours ;)
>
> Have a nice day,
>
> Oskar Andreasson
Brad
=====
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
Alternate e-mail: [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
