> On 26 Apr 2020, at 14:53, David P. Reed <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
