From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by lists.bufferbloat.net (Postfix) with ESMTPS id 4BC843E5F6 for ; Wed, 23 Dec 2015 06:59:32 -0500 (EST) Received: by mail-lb0-x232.google.com with SMTP id bc4so45364006lbc.2 for ; Wed, 23 Dec 2015 03:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KY+qNEk8NF3VEcQFx7Qb1yY6nViUlVewQ7pIiJm2rOQ=; b=Q/ydxhw8W5iddZ/S3EBO851DFwY8zyEM+mpx6g+mhUHUVYLhf6Wn6xltsqgaUmV6wG Ek95CIEUr4XsClAiPEZdYBurKSQCYTwmj5c8DfyoLzcFtSZ6vxywsNp5aemtAaUG67+V DErTmSOK0ppk5QS2xIZ42nRiSb/7zyuOB9osI+EFFWkKu5Dxo/l1/I9NhC076uy5Cyie bNR9/EPV5zEX+Co5CB6R1c98g2BBcW3qjcBPKUX1Cd6CcZcNA7nwszgCKT2tkCngFNu2 FVAmQIHLXIi148wnUz84fHUdMBJaKRoDWzrQ81WrrlOOl9twzIWkdUluNzmzduhifz7l qr5w== X-Received: by 10.112.137.232 with SMTP id ql8mr9032957lbb.8.1450871970136; Wed, 23 Dec 2015 03:59:30 -0800 (PST) Received: from bass.home.chromatix.fi (37-33-99-74.bb.dnainternet.fi. [37.33.99.74]) by smtp.gmail.com with ESMTPSA id aa4sm6246153lbc.10.2015.12.23.03.59.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Dec 2015 03:59:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: <53905DAE-AEBB-42BA-9B87-2E58222D05EB@gmx.de> Date: Wed, 23 Dec 2015 13:59:26 +0200 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <47F36AAA-54E7-490D-B92C-8D6B934BE506@gmail.com> References: <03C8DFA1-4BA1-491C-96F9-F67F87A2EFBB@gmail.com> <57200484-FC7E-4DD9-9BE0-8278515FB70F@gmx.de> <53905DAE-AEBB-42BA-9B87-2E58222D05EB@gmx.de> To: moeller0 X-Mailer: Apple Mail (2.3112) Subject: Re: [Cake] Christmas Cake 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: Wed, 23 Dec 2015 11:59:32 -0000 >>> I=E2=80=99d like to see the results of testing the new = =E2=80=9Ctriple-isolation=E2=80=9D flag. It should pass all tests = involving one host-pair just as well as =E2=80=9Cflows=E2=80=9D does. = Additionally, it should share bandwidth fairly between multiple hosts on = either side of the link, regardless of any imbalance in the number of = flows involved. For example, one flow between A and B, two flows = between C and D, where both paths pass through the same Cake instance, = should result in each of C-D=E2=80=99s flows receiving half the = throughput of the A-B one. >>=20 >> Interesting, now I have a question (since reading the code only gets = my that far), the typical scenario people want is basically to enforce = per source host fairness on egress and per destination-host fairness on = ingress, because in a torrent swarm as far as I can see there will not = be multiple flows between internal_C and external_D, but rather between = internal_C and external_ALPHABET. And the stated goal often seems to be = fairness per internal host address. >=20 > To add to myself, multiple internal hosts accessing the same external = host should result in each flow using up to each host=E2=80=99s = bandwidth share. The test I outlined is only the simplest and most obvious one. Since I = haven=E2=80=99t run any serious, lab-style tests myself yet, I thought = it best to start simple. >> (In your description it is unclear what happens if internal C started = also talking to external E, will this increase C=E2=80=99s share of = bandwidth or not and what will be the bandwidth ratio of C2E as compared = to the C2D aggregate?) >>=20 >> Which of the three options will handle that well dual-X or = triple-iso? I intend the same per-host sharing to occur when the test is repeated = with A and C being the same host, and again when B and D are the same = host, but not both at the same time, obviously. The difference between dual-srchost, dual-dsthost and triple-isolate is = whether only one of these additional scenarios works, or both of them, = ie. dual-srchost ignores destination addresses for host-fairness = purposes (but not basic flow-isolation). The situation where A and C are also both talking to E is an interesting = one, especially since it can easily arise if E is, say, Steam or Windows = Update or suchlike (given some simplifying assumptions). The desired = results in =E2=80=9Cdual=E2=80=9D mode are hopefully obvious, whichever = way around you configure it; one way, the aggregate bandwidth of A and C = will be equalised, while the other way, B, D and E will be equalised, = with A and C=E2=80=99s shares of E depending on the relative number of = flows involved. But what happens in triple mode? I think what triple mode will do with that situation is to equalise B, D = and E in aggregate, and further will equalise A and C=E2=80=99s shares = of E, regardless of relative flow counts. At least, that=E2=80=99s what = it=E2=80=99s designed to do. All the above assumes that all this traffic is in the same priority = class (or that =E2=80=9Cbesteffort=E2=80=9D mode is in use) and is = saturating. Cake=E2=80=99s behaviour gets difficult to describe = concisely in other cases, but should be intuitively reasonable. There are other possible topologies, of course, but I think the above = are the interesting ones to test for now. It=E2=80=99s entirely likely = that some tweaking is still required, so I would appreciate whatever = help is forthcoming in setting up robust tests along those lines. - Jonathan Morton