[RFC] ecn match ported to ipv6

[RFC] ecn match ported to ipv6

[Eric Dumazet]

Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
only.

Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
to net/netfilter/xt_ecn.c ?

I can probably do it but not before ~ten days, so if someone is
interested, this will please Dave ;)

Thanks

Fwd: [RFC] ecn match ported to ipv6

[Dave Taht]

---------- Forwarded message ----------
From: Dave Taht <dave.taht@gmail.com>
Date: Wed, Jun 8, 2011 at 9:47 AM
Subject: Re: [RFC] ecn match ported to ipv6
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>, Jan Engelhardt
<jengelh@medozas.de>, Netfilter Development Mailinglist
<netfilter-devel@vger.kernel.org>




On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
> only.
>
> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
> to net/netfilter/xt_ecn.c ?
>
> I can probably do it but not before ~ten days, so if someone is
> interested, this will please Dave ;)

The larger question I had was this

"iptables seems to think ecn can only be looked at in TCP streams, where (for
example), ecn bits can be copied to the outer header of a udp vpn
stream, and marked


when needed."

ECN is an ip level standard, not just a tcp one.

http://www.ietf.org/rfc/rfc3168.txt

Example of ECN on ipsec:

http://huchra.bufferbloat.net/~d/veryhappynetwork.png

Also ECN marking in various qdiscs like HTB as presently being
discussed on the bloat list

https://lists.bufferbloat.net/pipermail/bloat/2011-June/000555.html

and a truly crazy idea regarding combining DSCP with firewalling is here:

https://lists.bufferbloat.net/pipermail/bloat/2011-June/000558.html

To give some context as to what we've been up to regarding
bufferbloat, I have a test lab setup with a bunch of wndr3700v2
routers at georgia tech, and have pushed  every ecn and bufferbloat
related patch in linux head into the openwrt distro, and am playing
with all sorts of techniques now, with increasingly good results.

The 'uberwrt' project is in addition to the debloat-testing work
and has various subprojects... mostly targeting the wndr3700v2 and
nanostation M5 as these have a completely open source wireless and
wired stack.

http://www.bufferbloat.net/projects/uberwrt/wiki

--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net



--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] ecn match ported to ipv6

[Patrick McHardy]

On 08.06.2011 17:47, Dave Taht wrote:
> On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
>> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
>> only.
>>
>> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
>> to net/netfilter/xt_ecn.c ?
>>
>> I can probably do it but not before ~ten days, so if someone is
>> interested, this will please Dave ;)

That should be a relatively quick job, I'll give it a shot while
my dinner is cooking :)

> The larger question I had was this
> 
> "iptables seems to think ecn can only be looked at in TCP streams, where (for
> example), ecn bits can be copied to the outer header of a udp vpn
> stream, and marked
> 
> when needed."
> 
> ECN is an ip level standard, not just a tcp one.

That probably needs a new revision and is slightly more work, lets
begin by porting it to IPv6, then we can add this on top.

> http://www.ietf.org/rfc/rfc3168.txt
> 
> Example of ECN on ipsec:
> 
> http://huchra.bufferbloat.net/~d/veryhappynetwork.png
> 
> Also ECN marking in various qdiscs like HTB as presently being discussed on
> the bloat list
> 
> https://lists.bufferbloat.net/pipermail/bloat/2011-June/000555.html

I'd suggest to make this generic so other qdiscs can use it as well.

> and a truly crazy idea regarding combining DSCP with firewalling is here:
> 
> https://lists.bufferbloat.net/pipermail/bloat/2011-June/000558.html
> 
> To give some context as to what we've been up to regarding bufferbloat, I
> have a test lab setup with a bunch of wndr3700v2 routers at georgia tech,
> and have pushed  every ecn and bloat related patch in linux head into the
> openwrt distro, and am playing with all sorts of techniques now, with
> increasingly good results.
> 
> The 'uberwrt' project is in addition to the debloat-testing work
> and has various subprojects...
> 
> http://www.bufferbloat.net/projects/uberwrt/wiki
> 

Re: [RFC] ecn match ported to ipv6

[Jan Engelhardt]

On Wednesday 2011-06-08 19:32, Patrick McHardy wrote:

>On 08.06.2011 17:47, Dave Taht wrote:
>> On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> 
>>> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
>>> only.
>>>
>>> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
>>> to net/netfilter/xt_ecn.c ?
>>>
>>> I can probably do it but not before ~ten days, so if someone is
>>> interested, this will please Dave ;)
>
>That should be a relatively quick job, I'll give it a shot while
>my dinner is cooking :)
>
>> The larger question I had was this
>> 
>> "iptables seems to think ecn can only be looked at in TCP streams, where (for
>> example), ecn bits can be copied to the outer header of a udp vpn
>> stream, and marked
>> 
>> when needed."
>> 
>> ECN is an ip level standard, not just a tcp one.
>
>That probably needs a new revision and is slightly more work, lets
>begin by porting it to IPv6, then we can add this on top.

Moving it to xt_ecn first seems like producing a smaller patchset 
because you don't have to potentially duplicate the functions first. :)

Re: [RFC] ecn match ported to ipv6

[Patrick McHardy]

On 08.06.2011 22:50, Jan Engelhardt wrote:
> On Wednesday 2011-06-08 19:32, Patrick McHardy wrote:
> 
>> On 08.06.2011 17:47, Dave Taht wrote:
>>> On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>
>>>> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
>>>> only.
>>>>
>>>> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
>>>> to net/netfilter/xt_ecn.c ?
>>>>
>>>> I can probably do it but not before ~ten days, so if someone is
>>>> interested, this will please Dave ;)
>>
>> That should be a relatively quick job, I'll give it a shot while
>> my dinner is cooking :)
>>
>>> The larger question I had was this
>>>
>>> "iptables seems to think ecn can only be looked at in TCP streams, where (for
>>> example), ecn bits can be copied to the outer header of a udp vpn
>>> stream, and marked
>>>
>>> when needed."
>>>
>>> ECN is an ip level standard, not just a tcp one.
>>
>> That probably needs a new revision and is slightly more work, lets
>> begin by porting it to IPv6, then we can add this on top.
> 
> Moving it to xt_ecn first seems like producing a smaller patchset 
> because you don't have to potentially duplicate the functions first. :)

It actually already supports matching on IP header ECN bits:

[!] --ecn-ip-ect [0..3]	Match ECN codepoint in IPv4 header

Re: [RFC] ecn match ported to ipv6

[Dave Taht]

On Thu, Jun 9, 2011 at 2:17 AM, Patrick McHardy <kaber@trash.net> wrote:
> On 08.06.2011 22:50, Jan Engelhardt wrote:
>> On Wednesday 2011-06-08 19:32, Patrick McHardy wrote:
>>
>>> On 08.06.2011 17:47, Dave Taht wrote:
>>>> On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>
>>>>> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
>>>>> only.
>>>>>
>>>>> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
>>>>> to net/netfilter/xt_ecn.c ?
>>>>>
>>>>> I can probably do it but not before ~ten days, so if someone is
>>>>> interested, this will please Dave ;)
>>>
>>> That should be a relatively quick job, I'll give it a shot while
>>> my dinner is cooking :)
>>>
>>>> The larger question I had was this
>>>>
>>>> "iptables seems to think ecn can only be looked at in TCP streams, where (for
>>>> example), ecn bits can be copied to the outer header of a udp vpn
>>>> stream, and marked
>>>>
>>>> when needed."
>>>>
>>>> ECN is an ip level standard, not just a tcp one.
>>>
>>> That probably needs a new revision and is slightly more work, lets
>>> begin by porting it to IPv6, then we can add this on top.
>>
>> Moving it to xt_ecn first seems like producing a smaller patchset
>> because you don't have to potentially duplicate the functions first. :)
>
> It actually already supports matching on IP header ECN bits:
>
> [!] --ecn-ip-ect [0..3] Match ECN codepoint in IPv4 header
>

Sorry, my bad. It's even documented as existing.

So it's just a pair of convienence functions (
--ecn-ip-ece --ecn-ip-cwr )

and ipv6 iptables support for ECN that are MIA.

I'll argue that extending the blackhole-ing feature to also include ip

       --ecn-tcp-remove

might be good... although in my testing I have not found a blackhole
yet, they must still be out there.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] ecn match ported to ipv6

[Patrick McHardy]

On 09.06.2011 14:15, Dave Taht wrote:
> On Thu, Jun 9, 2011 at 2:17 AM, Patrick McHardy <kaber@trash.net> wrote:
>> On 08.06.2011 22:50, Jan Engelhardt wrote:
>>> On Wednesday 2011-06-08 19:32, Patrick McHardy wrote:
>>>
>>>> On 08.06.2011 17:47, Dave Taht wrote:
>>>>> On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>>
>>>>>> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4
>>>>>> only.
>>>>>>
>>>>>> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c
>>>>>> to net/netfilter/xt_ecn.c ?
>>>>>>
>>>>>> I can probably do it but not before ~ten days, so if someone is
>>>>>> interested, this will please Dave ;)
>>>>
>>>> That should be a relatively quick job, I'll give it a shot while
>>>> my dinner is cooking :)
>>>>
>>>>> The larger question I had was this
>>>>>
>>>>> "iptables seems to think ecn can only be looked at in TCP streams, where (for
>>>>> example), ecn bits can be copied to the outer header of a udp vpn
>>>>> stream, and marked
>>>>>
>>>>> when needed."
>>>>>
>>>>> ECN is an ip level standard, not just a tcp one.
>>>>
>>>> That probably needs a new revision and is slightly more work, lets
>>>> begin by porting it to IPv6, then we can add this on top.
>>>
>>> Moving it to xt_ecn first seems like producing a smaller patchset
>>> because you don't have to potentially duplicate the functions first. :)
>>
>> It actually already supports matching on IP header ECN bits:
>>
>> [!] --ecn-ip-ect [0..3] Match ECN codepoint in IPv4 header
>>
> 
> Sorry, my bad. It's even documented as existing.
> 
> So it's just a pair of convienence functions (
> --ecn-ip-ece --ecn-ip-cwr )

Yeah, that would make usage easier.

> and ipv6 iptables support for ECN that are MIA.

Sent out patches a few seconds ago.

> I'll argue that extending the blackhole-ing feature to also include ip
> 
>        --ecn-tcp-remove
> 
> might be good... although in my testing I have not found a blackhole
> yet, they must still be out there.

That would be the ECN target, not the match.