From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by lists.bufferbloat.net (Postfix) with ESMTPS id 9A8123B2B0 for ; Thu, 14 Jan 2016 09:20:21 -0500 (EST) Received: from u-089-d091.biologie.uni-tuebingen.de ([134.2.89.91]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M82zV-1ZxOee3dU9-00vi0y; Thu, 14 Jan 2016 15:20:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <56941191.1010601@darbyshire-bryant.me.uk> Date: Thu, 14 Jan 2016 15:20:15 +0100 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <5693E8FA.4000803@darbyshire-bryant.me.uk> <56941191.1010601@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:rO/GSYa8l4LDKOzr7cLhOTVfQ/Mcxc2m81IASpkdOrN6c0wtVuZ UgcIQMN4nN81Ier780wv5sPJIf7AVi11ic99joE+3S4NEE05Cs3jYKYYcboI3vKyKN9Uyy1 NoQ9cBZ7IjGr+n15NRoyr3+zyUzc7vy2wyUGKE0NUNF7oPu1jQqqBWDE6zIuod91tRTAn81 LUVejzPPN8JReVdTfTZCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:VNT3SdeQTQM=:y/dBmOy8SRDs7kLbB6edDG IRogrL42BpnNogd6EcKTav+znZAZR9NpWmTK8oryVqZaw8GrlxvzYW1WFgCQNcRrvoZQC9G7P zlBmVp6DpbIayl/qs0lGGXdUzGJxQngwdvvYIKhfytWtkkiOqxNMQOrNqpWluRUHEy7UB+edC DSjgpG0BMlshSB5r3FZrTEcEJwMqxaAhZOXDibZcexA6TOLqRJ21cUCu61mhJLfwpVizowL7o mj3/Lc+8rUo4eqFRWEeP8SdxpHPCytJBnZhUplntaRATBXNZ4T6c4jExmATu9bml+jDz8AiI8 2q0vjPwrPrM0pDYWm6MLYn2IbnKgACp1XxhF2izgRndbY1DphaUJyv7EauXQMZ8EfiST0IRHm JbCZi19PhdBP2s7lGfvP9VTMLCNBFgmp83K7S07Q+8eO6wkMfjV88xoCKCv96V0tGEn9GToM7 NmSS6+M0DNlmc8p2d/l3w9Iy742ArWi160wD6WX8Z/pEnn48nR579yq9oZ8unDtOSMuYndZ6E MyEYv/tidyaS01LERvg0DIl6Xi3SSm04YxaHAmvPrTODzVJk7Kgc6mNvUyVxb9fEsJQZKNqOi q6fEmPRD5PPFtWKJouia+DWEtaW8VARAZchgaddQ+c/HQvBLUBcmRyOwec9jpo6kJWNSRpppd SYfWc1QH8IBesOzayEtG8D9DSqa13TT+00GmDFXFt+mGKn1hpgprQSxa6P4VsniJz7cIkDE9z hzDE+Gq48b/Jz6OudMAbvUOv4gZm4+T13Hkagyd+2C7DffLh1uFxTD2RGkilXBJVEWW9i2reC VQHIaL6 Subject: Re: [Cake] triple flow isolation X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:20:32 -0000 Hi Kevin, > On Jan 11, 2016, at 21:33 , Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 > On 11/01/16 18:16, moeller0 wrote: >> Hi Kevin, >>=20 >> I agree the triple mode seems under-documented ;) > Yes that's true but it is experimental after all - and I'm = experimenting > with it :-) >>> On Jan 11, 2016, at 18:40 , Kevin Darbyshire-Bryant = wrote: >>>=20 >>> Hello List, >>>=20 >>> I've been looking at latest 'triple flow isolation' features in = latest >>> cake git and find myself confused. It's very likely to be a >>> misunderstanding on my part, although if I'm confused I'm sure = others >>> will, sooner or later, fall into the same trap. >>>=20 >>> I thought that triple flow was a solution such that a host with many >>> elephant flows couldn't dominate the bandwidth consumption thus = starving >>> another host with just one elephant flow. I guess the typical = example >>> is a 'bittorrent' host pulling data from many places vs a host = pulling >>> data from a single place. My recent 'test' example was a host doing = 4 >>> simulatenous pulls of 9GByte+ files vs my wife downloading a movie = via >>> the TV box downstairs. The bandwidth was evenly divided by the 5 = flows, >>> however my host got 4/5ths of the share. I didn't think this was >>> supposed to happen with triple flow isolation? Ideally we'd both = get >>> 50% of the ISP bandwidth managed by my router (cake is running on = the >>> WAN facing interface to the ISP modem with appropriate bandwidth = limits set) >> I believe you would want src_host on egress and (post-NAT) = dat-host on ingress, assuming your goal is fairness by internal host, = not external hosts ;). Now the challenges are to get the post-NAT IP = addresses on ingress and how to counteract IPv6=E2=80=99s tendency to = grow incredible amounts of addresses by host. In theory all of this = could be solved with fairness by internal MAC addresses, except these = will only work in a shallow networks (as far as I understand). I would = argue that wifi aggregation has the same issue regarding IPv6, but I = digress... > Ah, yes, silly me - NAT. As you say pre-NAT internal source address = on > egress and post-NAT internal destination address on ingress. So the > shaping to work, cake needs to be on the wan interface but that's too > late to obtain the internal pre-NATed addresses. Oh dear. Help! So a quick and dirty test would be to set up sqm with cake on = the interface connecting the router SoC with its switch (aka LAN) then = you have access to the internal addresses for both egress and ingress. = Note that ingress and egress will be switched as compared to sqm on the = wan interface so adjust the shaper settings accordingly (ingress egress = are always from the view of the router, and on a LAN interface the = egress direction of the interface is the ingress/download direction from = the WAN). So, I would guess, destination address on egress and source = address on ingress as seen by sqm should do the trick then. This test will obviously only work if no additional traffic hits = the router besided WAN ans LAN, so no WLAN on the router for this = test=E2=80=A6 Or leave everything as is an run pure IPv6 tests, since I = believe openwrt does not do NAT6 by default=E2=80=A6 I am really curious how cake behaves in that setting... Best Regards Sebastian >=20 >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake