Re: [Cerowrt-devel] cerowrt 3.6.9-5

[Dave Taht <dave.taht@gmail.com>]

On Mon, Dec 10, 2012 at 1:00 AM, Michael Richardson <mcr@sandelman.ca> wrote:
>
>>>>>> "Dave" == Dave Taht <dave.taht@gmail.com> writes:
>     Dave> I go back, however, to worrying about encapsulated traffic (such as
>     Dave> vpn) that might need to ignore classification in order to
>     Dave> preserve the
>     Dave> stream boundries....
>
> What do you mean here?

I worry about encapsulating protocols copying the inner TOS/Diffserv
bits to the outer IP header. Using a shaper that is aware of these
bits would end up delivering packets that depend on a sequential
encrypted stream out of order.

I went looking into it a bit and it looks not to be a problem with
openvpn, gre, and ike, as the protocols are not defined to do that.
6in4 is OK as it's pretty stateless... I think the other ipv6
encapsulating protocols should be fine too.

(what actually happens in the real world has to be looked at, though)

My head explodes when trying to understand AH and ipsec (strongswan),
however, and I'd rather set up one and look at packets than try to
understand the code. ENOTIME... and that leaves ipip etherip and
encap, and l2tp left to look at.

I'm also growing interested in protocols we could no longer use in the
NAT era, but can in the ipv6 era (even with npt66), like sctp, and
hip.... (100+ others elided), and also ones that are heavily used
outside of conventional networking, like dccp.

Then there's various forms of multicast...

As happy as I am with fq_codel and it's upcoming successors, I keep
looking for things that will break if we flipped a switch tomorrow and
converted linux over to it!

For example, it would make sense to FQ packets entering the
ipsec/openvpn portions of the stack somehow, and it is suboptimal to
penalize vpn streams over all others.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html