From: moeller0 <moeller0@gmx.de>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] de-natting & host fairness
Date: Mon, 26 Sep 2016 10:54:09 +0200 [thread overview]
Message-ID: <F103DA51-A615-4902-A3B9-66BD61F7CB3B@gmx.de> (raw)
In-Reply-To: <3a99770e-6350-471f-72b6-b209d7d77d75@darbyshire-bryant.me.uk>
Hi Kevin,
this is like the missing puzzle piece, if you solved this, most home users might end up deep in your debt (without them realizing it of course).
Question, if I enable this on my link how will it deal with the typical differences between IPv4 and IPv6? I believe that the situation I have at home, NAT for IPv4 but no NAT for IPv6 (or if NAT, at least NAT with identifying last 64 bits of the IPv6 addresses, no port remapping games) is quite common now a days. I assume it will do the right thing for IPv4 but will it still do the right thing for IPv6 flows as well? And what if for $DEITY’s sake someone would insist on using a port-remapping NAT on IPv6?
If, what I assume it will do the right thing by default, I would vote for enabling this by default and introduce keywords to disable this if required (in what I assume to be one of cake’s main ideas use reasonable defaults that in general do the right thing, but also allow crazy stuff if need be).
Do you have any idea how expensive this is computationally? I realize that this is a tad hard to measure as cake will not simply reduce the available bandwidth when running out of CPU cycles but first will allow the latency to increase.
Best Regards
Sebastian
> On Sep 26, 2016, at 05:20 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
> Greetings!
>
> A while back I started on a quest to make cake 'nat' aware as the lack of host fairness in a typical home router environment was the only thing that prevented cake from being the ultimate qdisc in my opinion. This involves dealing with conntrack which on egress is easy (the kernel fills in a data structure for us), ingress is less clear. I hacked something together but wasn't really happy with it.
>
> Another github user 'tegularius' presented some beautifully crafted code that did the lookups in a much neater way. Originally it too had an 'ingress' lookup problem. This was worked on and I hacked some conditional 'denat' options into cake & tc.
>
> For your 'delight' a denat cake https://github.com/kdarbyshirebryant/sch_cake/tree/natoptions along with a matching tc https://github.com/kdarbyshirebryant/tc-adv/tree/denat
>
> Typically I use 'dual-srchost srcnat' options on the egress interface, with 'dual-dsthost dstnat' in the ingress ifb interface. In *brief* testing, bandwidth is shared fairly between hosts, and fairly by flow within each host. And it's not crashed yet.
>
> Kevin
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
next prev parent reply other threads:[~2016-09-26 8:54 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 3:20 Kevin Darbyshire-Bryant
2016-09-26 3:54 ` Dave Taht
2016-09-26 5:11 ` Dave Taht
2016-09-26 8:54 ` moeller0 [this message]
2016-09-26 13:02 ` Kevin Darbyshire-Bryant
2016-09-26 13:28 ` moeller0
2016-09-26 14:06 ` Kevin Darbyshire-Bryant
2016-09-26 14:30 ` Jonathan Morton
2016-09-26 15:23 ` moeller0
2016-09-27 1:52 ` Noah Causin
2016-09-27 2:32 ` Kevin Darbyshire-Bryant
2016-09-27 4:20 ` Noah Causin
2016-09-27 14:52 ` Noah Causin
2016-09-27 15:28 ` Kevin Darbyshire-Bryant
2016-09-27 20:40 ` Noah Causin
2016-09-27 20:44 ` Jonathan Morton
[not found] ` <CAA93jw6rPE8aAGEiqf7jp3hc1J0ThrVer8PFmFLPBqANdtEixg@mail.gmail.com>
2016-09-27 20:58 ` Noah Causin
2016-09-28 4:38 ` Kevin Darbyshire-Bryant
2016-09-28 5:08 ` Noah Causin
2016-09-27 23:08 ` Jonathan Morton
2016-09-28 2:56 ` Kevin Darbyshire-Bryant
2016-09-28 3:06 ` Jonathan Morton
2016-09-28 3:33 ` Kevin Darbyshire-Bryant
2016-09-28 3:49 ` Jonathan Morton
2016-09-28 6:07 ` Kevin Darbyshire-Bryant
2016-09-28 11:08 ` Kevin Darbyshire-Bryant
2016-09-28 11:49 ` Dave Taht
2016-09-28 14:11 ` Kevin Darbyshire-Bryant
2016-09-28 5:56 ` Sebastian Moeller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F103DA51-A615-4902-A3B9-66BD61F7CB3B@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox