[Cake] dual-src/dsthost unfairness, only with bi-directional traffic

[Georgios Amanakis]

In my previous test the clients communicated to different flent
servers (flent-newark, flent-newark.bufferbloat.net). Iproute2 was
iproute2-ss4.18.0-4-openwrt. I will try to test on latest 4.20, will
take some time though.

I have the feeling we have discussed a similar issue in the past
(https://lists.bufferbloat.net/pipermail/cake/2017-November/002985.html).
I understand what Jonathan says. However I cannot explain why
*without* bidirectional traffic the "dual- host" mode behaves like
"src/dst-host", but *with* bidirectional traffic it behaves like
"triple-isolate".

The cake instances on the two interfaces are separate, right? So what
happens on one interface should not influence the other. Even with
bidirectional traffic the "dual- host" mode should still behave like
the "src/dst-host" mode in terms of host fairness, or not? At least
this is what I would intuitively expect.


On Thu, Jan 3, 2019 at 11:35 AM Pete Heist <pete at heistp.net> wrote:
>
>
> > On Jan 3, 2019, at 2:20 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> >
> > Pete Heist <pete at heistp.net> writes:
> >
> >> I’m not sure there’d be any way I can test fairness with iperf3 in UDP
> >> mode. We’d need something that has some congestion control feedback,
> >> right? Otherwise, I don’t think there are any rates I can choose to
> >> both reach saturation and not be severely punished. And if it has
> >> congestion control feedback, it has the ACK-like traffic we’re trying
> >> to avoid for the test. :)
> >
> > Try setting cake to 'interplanetary' - that should basically turn off
> > the AQM dropping...
>
> Ok, so long as we know that we’re not testing any possible interactions between AQM and host fairness, but we may learn more from it anyway. I’m using my client to server rig here (two APU2s on kernel 4.9.0-8), not the APU1 one-armed router middle box.
>
> So, basic single client rig tests (OK):
>
>         IP1 8-flow TCP up: 95.8
>         IP2 1-flow 48mbit UDP up: 48.0 (0% loss)
>         IP1 8-flow x 6mbit/flow = 48mbit UDP down: 48.0 (0% loss)
>         IP2 1-flow TCP down: 96.0
>
> Competition up (OK):
>
>         IP1 8-flow TCP up: 59.5
>         IP2 1-flow 48mbit UDP up: 36.7 (0% loss)
>                 Note: I don’t know why the UDP send rate slowed down here. It’s probably not the CPU, as it occurs at lower rates also. I’ll forge on.
>
> Competition down (not OK, high UDP loss):
>
>         IP1 1-flow TCP down: 53.3
>         IP2 8-flow x 6mbit/flow 48mbit UDP down: 8.6 (82% loss)
>                 Note: I have no idea what happened with the UDP loss rate here, so I’ll go back to a single IP1 UDP test.
>
> Back to single client (weird, still seeing loss):
>
>         IP2 8-flow x 6mbit/flow 48mbit UDP down: 48.0 (5.6% loss)
>
> Ok, I know that was working with no loss before. Stop and restart cake, then (loss stops after restart):
>
>         IP2 8-flow x 6mbit/flow 48mbit UDP down: 48.0 (0% loss)
>
> That’s better, now stop and restart cake and try the "competition down" test again (second trial):
>
>         IP1 1-flow TCP down: 55.3
>         IP2 8-flow x 6mbit/flow 48mbit UDP down: 5.8 (88% loss)
>                 Note: I have no idea what happened with the UDP loss rate here, so I’ll go back to a single IP1 UDP test.
>
> Since this rig hasn’t passed the two-host uni-directional test because of the high loss rate on the “competition down” test, I’m not going to go any further. I’ll rather go back to my one-armed router rig and send those results in a separate email.
>
> However, I consider it strange that I still see UDP loss after the "competition down” test has run and is completed, then it stops happening after restarting cake. That’s another issue I don’t have time to explore at the moment, unless someone has a good idea of what’s going on there.
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake