[Cake] dscp & tunneling

[Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

So there I was pondering the problem of getting the IPv6 DSCP coding
onto the outer IPv4 packets of my '6in4' tunnel (kindly provided for
free by Hurricane Electric) when I stumbled across this in a man page:


       ip tunnel { add | change | del | show | prl } [ NAME ]
               [ mode MODE ] [ remote ADDR ] [ local ADDR ]
               [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ] ]
               [ encaplimit ELIM ] [ ttl TTL ]
               [ tos TOS ] [ flowlabel FLOWLABEL ]
               [ prl-default ADDR ] [ prl-nodefault ADDR ] [ prl-delete
ADDR ]
               [ [no]pmtudisc ] [ dev PHYS_DEV ] [ dscp inherit ]

dscp inherit - just what I need!  Unfortunately it turns out it's for
'things being tunnelled over ipv6' and not 'ipv6 being tunnelled over
ipv4'.   Aaaarrghhh!  So close.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]



On 06/12/15 11:08, Kevin Darbyshire-Bryant wrote:
> So there I was pondering the problem of getting the IPv6 DSCP coding
> onto the outer IPv4 packets of my '6in4' tunnel (kindly provided for
> free by Hurricane Electric) when I stumbled across this in a man page:
>
>
>        ip tunnel { add | change | del | show | prl } [ NAME ]
>                [ mode MODE ] [ remote ADDR ] [ local ADDR ]
>                [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ] ]
>                [ encaplimit ELIM ] [ ttl TTL ]
>                [ tos TOS ] [ flowlabel FLOWLABEL ]
>                [ prl-default ADDR ] [ prl-nodefault ADDR ] [ prl-delete
> ADDR ]
>                [ [no]pmtudisc ] [ dev PHYS_DEV ] [ dscp inherit ]
>
> dscp inherit - just what I need!  Unfortunately it turns out it's for
> 'things being tunnelled over ipv6' and not 'ipv6 being tunnelled over
> ipv4'.   Aaaarrghhh!  So close.
Of course I'm a complete muppet!  This would be a fairly pointless
exercise as cake has already classified the tunnel as it's a single flow
(from my router to the tunnel server) and no amount of dscp bit fiddling
from inner to outer headers is going to make different parts of the
tunnel flow move to different cake tins.  Oh I am stupid.  Sigh.

I'm going to persist with my dscp 'dye' option (wash cleans, dye
'colours' the packets with certain dscp codes per tin - wash/dye -
geddit?  I'll fetch my coat)

>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] dscp & tunneling

[Dave Taht]

On Thu, Dec 10, 2015 at 12:18 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 06/12/15 11:08, Kevin Darbyshire-Bryant wrote:
>> So there I was pondering the problem of getting the IPv6 DSCP coding
>> onto the outer IPv4 packets of my '6in4' tunnel (kindly provided for
>> free by Hurricane Electric) when I stumbled across this in a man page:
>>
>>
>>        ip tunnel { add | change | del | show | prl } [ NAME ]
>>                [ mode MODE ] [ remote ADDR ] [ local ADDR ]
>>                [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ] ]
>>                [ encaplimit ELIM ] [ ttl TTL ]
>>                [ tos TOS ] [ flowlabel FLOWLABEL ]
>>                [ prl-default ADDR ] [ prl-nodefault ADDR ] [ prl-delete
>> ADDR ]
>>                [ [no]pmtudisc ] [ dev PHYS_DEV ] [ dscp inherit ]
>>
>> dscp inherit - just what I need!  Unfortunately it turns out it's for
>> 'things being tunnelled over ipv6' and not 'ipv6 being tunnelled over
>> ipv4'.   Aaaarrghhh!  So close.
> Of course I'm a complete muppet!  This would be a fairly pointless
> exercise as cake has already classified the tunnel as it's a single flow
> (from my router to the tunnel server) and no amount of dscp bit fiddling
> from inner to outer headers is going to make different parts of the
> tunnel flow move to different cake tins.  Oh I am stupid.  Sigh.

No... for the hashing part, the skb_dissect routines in the kernel
already pull apart the stuff inside ip, ipv6, and gre *version 0)
tunnels and give you a hash based on the inner headers. So you do end
up with more than one hashed flow in the ipv6 tunnel. (this was not
the case at least as far back as 3.6, but it was one of the first
things we fixed) - see approximately line 458 in
net/core/flow_dissector.c.

The dscp is hopefully, with inherit, copied back and forth correctly,
although it is worrisome on some other OSes regarding dealing with the
ecn bits.

VPNs like ipsec or openvpn are not handled this way, not enough data.
Arguably you could pull apart some forms of tinc (stalled out research
project) in a really sane way...

> I'm going to persist with my dscp 'dye' option (wash cleans, dye
> 'colours' the packets with certain dscp codes per tin - wash/dye -
> geddit?  I'll fetch my coat)
>
>>
>>
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]



On 10/12/15 11:45, Dave Taht wrote:
> On Thu, Dec 10, 2015 at 12:18 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>> On 06/12/15 11:08, Kevin Darbyshire-Bryant wrote:
>>> So there I was pondering the problem of getting the IPv6 DSCP coding
>>> onto the outer IPv4 packets of my '6in4' tunnel (kindly provided for
>>> free by Hurricane Electric) when I stumbled across this in a man page:
>>>
>>>
>>>        ip tunnel { add | change | del | show | prl } [ NAME ]
>>>                [ mode MODE ] [ remote ADDR ] [ local ADDR ]
>>>                [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ] ]
>>>                [ encaplimit ELIM ] [ ttl TTL ]
>>>                [ tos TOS ] [ flowlabel FLOWLABEL ]
>>>                [ prl-default ADDR ] [ prl-nodefault ADDR ] [ prl-delete
>>> ADDR ]
>>>                [ [no]pmtudisc ] [ dev PHYS_DEV ] [ dscp inherit ]
>>>
>>> dscp inherit - just what I need!  Unfortunately it turns out it's for
>>> 'things being tunnelled over ipv6' and not 'ipv6 being tunnelled over
>>> ipv4'.   Aaaarrghhh!  So close.
>> Of course I'm a complete muppet!  This would be a fairly pointless
>> exercise as cake has already classified the tunnel as it's a single flow
>> (from my router to the tunnel server) and no amount of dscp bit fiddling
>> from inner to outer headers is going to make different parts of the
>> tunnel flow move to different cake tins.  Oh I am stupid.  Sigh.
> No... for the hashing part, the skb_dissect routines in the kernel
> already pull apart the stuff inside ip, ipv6, and gre *version 0)
> tunnels and give you a hash based on the inner headers. So you do end
> up with more than one hashed flow in the ipv6 tunnel. (this was not
> the case at least as far back as 3.6, but it was one of the first
> things we fixed) - see approximately line 458 in
> net/core/flow_dissector.c.
Ahh, ok.  And I've just confirmed this by running an ipv6 only 'rrul
with classification split' test, which shows a corresponding number of
'bulk flows' in line with the test.  Unfortunately.....
> The dscp is hopefully, with inherit, copied back and forth correctly,
> although it is worrisome on some other OSes regarding dealing with the
> ecn bits.
the same test shows all those flows going in the best effort tin and
nothing being split out according to dscp.  Things are split out
correctly with ipv4.  Assuming that my installation of flent is doing
the right thing (putting dscp on its outbound ipv6 packets) and knowing
that both flent & cake handle the ipv4 version of the test correctly and
that by the time 'cake' sees my tunnel it's all ipv4 outer packets
anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
place, at least for 6in4 'sit' tunnels :-(



>
> VPNs like ipsec or openvpn are not handled this way, not enough data.
> Arguably you could pull apart some forms of tinc (stalled out research
> project) in a really sane way...



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] dscp & tunneling

[Dave Taht]

On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:

> the same test shows all those flows going in the best effort tin and
> nothing being split out according to dscp.  Things are split out
> correctly with ipv4.  Assuming that my installation of flent is doing
> the right thing (putting dscp on its outbound ipv6 packets) and knowing
> that both flent & cake handle the ipv4 version of the test correctly and
> that by the time 'cake' sees my tunnel it's all ipv4 outer packets
> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
> place, at least for 6in4 'sit' tunnels :-(

Wireshark is your friend here.

It would not surprise me if dscp inherit had broken again, or, it was
borked on decapsulation. Not a widely tested feature, that.

I remember making it work several years ago, remember sort of seeing
the patches go upstream somewhere.... it was a long time ago.
>
>
>>
>> VPNs like ipsec or openvpn are not handled this way, not enough data.
>> Arguably you could pull apart some forms of tinc (stalled out research
>> project) in a really sane way...
>
>

Re: [Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]



On 10/12/15 12:22, Dave Taht wrote:
> On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>
>> the same test shows all those flows going in the best effort tin and
>> nothing being split out according to dscp.  Things are split out
>> correctly with ipv4.  Assuming that my installation of flent is doing
>> the right thing (putting dscp on its outbound ipv6 packets) and knowing
>> that both flent & cake handle the ipv4 version of the test correctly and
>> that by the time 'cake' sees my tunnel it's all ipv4 outer packets
>> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
>> place, at least for 6in4 'sit' tunnels :-(
> Wireshark is your friend here.
I shall befriend it once again :-)
>
> It would not surprise me if dscp inherit had broken again, or, it was
> borked on decapsulation. Not a widely tested feature, that.
I'm only 'testing' the encapsulation side...ipv6 into router, router
encapsulates into ipv6, cake then sits across 'eth0' the Internet facing
interface and isn't classifying the flows - and I swear this used to work.
>
> I remember making it work several years ago, remember sort of seeing
> the patches go upstream somewhere.... it was a long time ago.
Is there anyone lurking on this list, with the time, who can help me
with net/ipv6/sit.c?

It looks like this is the relevant area:  Need to see what
INET_ECN_encapsulate does (and where tos gets set)

        if (ttl == 0)
                ttl = iph6->hop_limit;
        tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));

        if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0) {
                ip_rt_put(rt);
                goto tx_error;
        }

        skb_set_inner_ipproto(skb, IPPROTO_IPV6);

        err = iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr,
                            protocol, tos, ttl, df,
                            !net_eq(tunnel->net, dev_net(dev)));
        iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
        return NETDEV_TX_OK;



>>
>>> VPNs like ipsec or openvpn are not handled this way, not enough data.
>>> Arguably you could pull apart some forms of tinc (stalled out research
>>> project) in a really sane way...
>>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]



On 10/12/15 12:35, Kevin Darbyshire-Bryant wrote:
>
> On 10/12/15 12:22, Dave Taht wrote:
>> On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant
>> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>>> the same test shows all those flows going in the best effort tin and
>>> nothing being split out according to dscp.  Things are split out
>>> correctly with ipv4.  Assuming that my installation of flent is doing
>>> the right thing (putting dscp on its outbound ipv6 packets) and knowing
>>> that both flent & cake handle the ipv4 version of the test correctly and
>>> that by the time 'cake' sees my tunnel it's all ipv4 outer packets
>>> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
>>> place, at least for 6in4 'sit' tunnels :-(
>> Wireshark is your friend here.
> I shall befriend it once again :-)
>> It would not surprise me if dscp inherit had broken again, or, it was
>> borked on decapsulation. Not a widely tested feature, that.
> I'm only 'testing' the encapsulation side...ipv6 into router, router
> encapsulates into ipv6, cake then sits across 'eth0' the Internet facing
> interface and isn't classifying the flows - and I swear this used to work.
>> I remember making it work several years ago, remember sort of seeing
>> the patches go upstream somewhere.... it was a long time ago.
> Is there anyone lurking on this list, with the time, who can help me
> with net/ipv6/sit.c?
>
> It looks like this is the relevant area:  Need to see what
> INET_ECN_encapsulate does (and where tos gets set)
>
>         if (ttl == 0)
>                 ttl = iph6->hop_limit;
>         tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));
>
>         if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0) {
>                 ip_rt_put(rt);
>                 goto tx_error;
>         }
>
>         skb_set_inner_ipproto(skb, IPPROTO_IPV6);
>
>         err = iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr,
>                             protocol, tos, ttl, df,
>                             !net_eq(tunnel->net, dev_net(dev)));
>         iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
>         return NETDEV_TX_OK;
Ahhh....further up...

        if (tos == 1)
                tos = ipv6_get_dsfield(iph6);

and further up still...

static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
                                     struct net_device *dev)
{
        struct ip_tunnel *tunnel = netdev_priv(dev);
        const struct iphdr  *tiph = &tunnel->parms.iph;
        const struct ipv6hdr *iph6 = ipv6_hdr(skb);
        u8     tos = tunnel->parms.iph.tos;


So how & who sets (or should be setting) iph.tos = 1?

Rabbit hole, rabbit hole......





[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] dscp & tunneling

[Dave Taht]

etags (or ctags) are friends here, as is cscope. I am in deep
gratitude to toke for supplying me a pretty good working .emacs.d set
of files for browsing code recently - I'd lost 20 years worth of
accumulated tools when my lab got stolen and don't do enough software
development today to justify sinking the time into making emacs sing
and dance anymore. That said, I don't understand 90% of all the cool
stuff he handed me...

in the linux kernel tree, do a make TAGS. then in emacs it's esc->. to
look up a symbol. There are ton of other things in cscope that are
pretty amazing. vi has similar interfaces as do eclipse.


On Thu, Dec 10, 2015 at 1:43 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 10/12/15 12:35, Kevin Darbyshire-Bryant wrote:
>>
>> On 10/12/15 12:22, Dave Taht wrote:
>>> On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant
>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>
>>>> the same test shows all those flows going in the best effort tin and
>>>> nothing being split out according to dscp.  Things are split out
>>>> correctly with ipv4.  Assuming that my installation of flent is doing
>>>> the right thing (putting dscp on its outbound ipv6 packets) and knowing
>>>> that both flent & cake handle the ipv4 version of the test correctly and
>>>> that by the time 'cake' sees my tunnel it's all ipv4 outer packets
>>>> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
>>>> place, at least for 6in4 'sit' tunnels :-(
>>> Wireshark is your friend here.
>> I shall befriend it once again :-)
>>> It would not surprise me if dscp inherit had broken again, or, it was
>>> borked on decapsulation. Not a widely tested feature, that.
>> I'm only 'testing' the encapsulation side...ipv6 into router, router
>> encapsulates into ipv6, cake then sits across 'eth0' the Internet facing
>> interface and isn't classifying the flows - and I swear this used to work.

I had it working 3 years back, yes, also.

>>> I remember making it work several years ago, remember sort of seeing
>>> the patches go upstream somewhere.... it was a long time ago.
>> Is there anyone lurking on this list, with the time, who can help me
>> with net/ipv6/sit.c?
>>
>> It looks like this is the relevant area:  Need to see what
>> INET_ECN_encapsulate does (and where tos gets set)
>>
>>         if (ttl == 0)
>>                 ttl = iph6->hop_limit;
>>         tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));
>>
>>         if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0) {
>>                 ip_rt_put(rt);
>>                 goto tx_error;
>>         }
>>
>>         skb_set_inner_ipproto(skb, IPPROTO_IPV6);
>>
>>         err = iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr,
>>                             protocol, tos, ttl, df,
>>                             !net_eq(tunnel->net, dev_net(dev)));
>>         iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
>>         return NETDEV_TX_OK;
> Ahhh....further up...
>
>         if (tos == 1)
>                 tos = ipv6_get_dsfield(iph6);
>
> and further up still...
>
> static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
>                                      struct net_device *dev)
> {
>         struct ip_tunnel *tunnel = netdev_priv(dev);
>         const struct iphdr  *tiph = &tunnel->parms.iph;
>         const struct ipv6hdr *iph6 = ipv6_hdr(skb);
>         u8     tos = tunnel->parms.iph.tos;
>
>
> So how & who sets (or should be setting) iph.tos = 1?
>
> Rabbit hole, rabbit hole......
>
>
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 4684 bytes --]



On 10/12/15 12:49, Dave Taht wrote:
> etags (or ctags) are friends here, as is cscope. I am in deep
> gratitude to toke for supplying me a pretty good working .emacs.d set
> of files for browsing code recently - I'd lost 20 years worth of
> accumulated tools when my lab got stolen and don't do enough software
> development today to justify sinking the time into making emacs sing
> and dance anymore. That said, I don't understand 90% of all the cool
> stuff he handed me...
>
> in the linux kernel tree, do a make TAGS. then in emacs it's esc->. to
> look up a symbol. There are ton of other things in cscope that are
> pretty amazing. vi has similar interfaces as do eclipse.
Well I'm beginning to get the vague whiff of a rat......

In iproute2 land 'iptunnel.c' is responsible for setting 'iph.tos'.

'ip tunnel' in openwrt land returns:

# ip tunnel
BusyBox v1.24.1 (2015-12-10 10:25:05 GMT) multi-call binary.

Usage: ip [OPTIONS] {address | route | link | rule} {COMMAND}

ip [OPTIONS] OBJECT {COMMAND}
where OBJECT := {address | route | link | rule}
OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }

First line gives a clue...this isn't real 'iproute2', this is busybox.

And a vaguely remember something going by on the openwrt commit list
about switching to 'busybox ip route' built-ins.

Does busybox understand the tos flag?

I can't prove it yet.  But it's one of those gut feels I get......


>
> On Thu, Dec 10, 2015 at 1:43 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>> On 10/12/15 12:35, Kevin Darbyshire-Bryant wrote:
>>> On 10/12/15 12:22, Dave Taht wrote:
>>>> On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant
>>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>>
>>>>> the same test shows all those flows going in the best effort tin and
>>>>> nothing being split out according to dscp.  Things are split out
>>>>> correctly with ipv4.  Assuming that my installation of flent is doing
>>>>> the right thing (putting dscp on its outbound ipv6 packets) and knowing
>>>>> that both flent & cake handle the ipv4 version of the test correctly and
>>>>> that by the time 'cake' sees my tunnel it's all ipv4 outer packets
>>>>> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
>>>>> place, at least for 6in4 'sit' tunnels :-(
>>>> Wireshark is your friend here.
>>> I shall befriend it once again :-)
>>>> It would not surprise me if dscp inherit had broken again, or, it was
>>>> borked on decapsulation. Not a widely tested feature, that.
>>> I'm only 'testing' the encapsulation side...ipv6 into router, router
>>> encapsulates into ipv6, cake then sits across 'eth0' the Internet facing
>>> interface and isn't classifying the flows - and I swear this used to work.
> I had it working 3 years back, yes, also.
>
>>>> I remember making it work several years ago, remember sort of seeing
>>>> the patches go upstream somewhere.... it was a long time ago.
>>> Is there anyone lurking on this list, with the time, who can help me
>>> with net/ipv6/sit.c?
>>>
>>> It looks like this is the relevant area:  Need to see what
>>> INET_ECN_encapsulate does (and where tos gets set)
>>>
>>>         if (ttl == 0)
>>>                 ttl = iph6->hop_limit;
>>>         tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));
>>>
>>>         if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0) {
>>>                 ip_rt_put(rt);
>>>                 goto tx_error;
>>>         }
>>>
>>>         skb_set_inner_ipproto(skb, IPPROTO_IPV6);
>>>
>>>         err = iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr,
>>>                             protocol, tos, ttl, df,
>>>                             !net_eq(tunnel->net, dev_net(dev)));
>>>         iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
>>>         return NETDEV_TX_OK;
>> Ahhh....further up...
>>
>>         if (tos == 1)
>>                 tos = ipv6_get_dsfield(iph6);
>>
>> and further up still...
>>
>> static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
>>                                      struct net_device *dev)
>> {
>>         struct ip_tunnel *tunnel = netdev_priv(dev);
>>         const struct iphdr  *tiph = &tunnel->parms.iph;
>>         const struct ipv6hdr *iph6 = ipv6_hdr(skb);
>>         u8     tos = tunnel->parms.iph.tos;
>>
>>
>> So how & who sets (or should be setting) iph.tos = 1?
>>
>> Rabbit hole, rabbit hole......
>>
>>
>>
>>
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] dscp & tunneling

[Jonathan Morton]

> On 10 Dec, 2015, at 13:18, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> This would be a fairly pointless
> exercise as cake has already classified the tunnel as it's a single flow
> (from my router to the tunnel server) and no amount of dscp bit fiddling
> from inner to outer headers is going to make different parts of the
> tunnel flow move to different cake tins.

Not true - Cake interprets the DSCP field *before* looking at flows.  There’s a separate flow system for each tin.

That’s on top of the magic that flow_dissect does.

 - Jonathan Morton

Re: [Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]



On 12/12/15 01:14, Jonathan Morton wrote:
>> On 10 Dec, 2015, at 13:18, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>>
>> This would be a fairly pointless
>> exercise as cake has already classified the tunnel as it's a single flow
>> (from my router to the tunnel server) and no amount of dscp bit fiddling
>> from inner to outer headers is going to make different parts of the
>> tunnel flow move to different cake tins.
> Not true - Cake interprets the DSCP field *before* looking at flows.  There’s a separate flow system for each tin.
>
> That’s on top of the magic that flow_dissect does.
>
>  - Jonathan Morton
>
Thank you Jonathan for distilling my idiocy down to one line :-)

The good thing is that a solution to the problem has been found....and
it was user configuration....that'll be me as the core problem again :-)

Kevin

PS: It's great to have you back!


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]