Re: [Cake] Cake tin behaviour - discuss....

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

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



> On 26 Apr 2020, at 14:53, David P. Reed <dpreed@deepplum.com> wrote:
> 
> Very interesting. However, I'm curious about what is being "ping'ed" from outside.
> 
> I would bet that the ping comes in on your router interface and is reflected immediately back. Which would mean that it might not at all be going through the Cake layer. That depends on the details of your setup, which you didn't share.

The address being pinged from the external ‘ping box’ is that of the globally routable IPv6 WAN interface on my APU2 router.  The ping packet is going through 2 instances of cake, one on ingress (ifb4eth0), one on egress (eth0).

DSCP is applied to the packets by tc filter action act_ctinfo JUST before cake gets to see the packets.  I know DSCP is affecting cake tin selection because I see cake’s tin byte/packet counters adjust accordingly.  icmp/icmpv6 traffic is marked as BE by default AND also explicitly by some ip’n’tables rules that set it so.

> As you probably know, Cake works by packet shaping in the box where it runs, in the Linux stack. If the ping responder is on the ISP side of Cake, it will not be measuring lag-under-load *inside* cake.

I think I answered that above, however just for good measure, I’ve set up another ‘ping latency’ test to a box that is definitely on my LAN side, so it’ll go: ingress (cake) eth0 (wan) -> egress eth1 (lan) -> switches -> device under test -> ingress eth1 (lan) -> egress (cake) eth0 (wan)

Note that the DSCP applied by cake on egress is ignored by the ISP.  Similarly, it’s a very rare thing to see a non 0 DSCP come in from them.  I’m using DSCP ‘internally’ purely to provide CAKE with some traffic identification and hence clue as to how to shape it.

> 
> End-to-end lag-under-load on multiple paths sharing a bottleneck is the problem Cake was invented to solve. (Jonathan - you agree?) Yes, it will move that congestion "inside" itself, pulling it out of the bottleneck itself. There it drops and ECN's "as if" the bottleneck were working correctly, rather than being "bufferbloated".
> 
> So it would be interesting to learn more about the topology of your test to interpret this ping.  A more interesting ping would be along the fujl path that the other flows are taking. Your ISP can't provide that.

My question was trying to determine what cake was doing:

bandwidth / per host fairness / tin weighting or
bandwidth / tin weighting / per host fairness

I was expecting the latter and Jonathan has confirmed my expectation to be the correct one.  The results I saw under some circumstance appeared more toward the former, which boggled the mind.


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]