[Cake] Upstream submission of dual-mode fairness patch

[Pete Heist]

> On Mar 3, 2019, at 5:40 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 3 Mar, 2019, at 6:35 pm, Pete Heist <pete at heistp.net> wrote:
>> 
>> It almost seems like in ingress mode, dropped packets are being counted as bytes transferred, when they weren’t.
> 
> Well yes, that's the whole point - at least as far as the shaper is concerned.  Ingress mode is supposed to deal with the case where inbound packets have already traversed the bottleneck link *before* Cake gets to choose what to do with them.
> 
> But that shouldn't affect fairness, only total throughput.  Fairness is not handled by the shaper, but by the (very) extended DRR++ algorithm.


It should probably come as no surprise then that if I take pcaps from the client side and sum cumulative bytes transferred with 1514 * the number of drops (according to tcp.analysis.lost_segment), I get pretty close to the same value for each IP. I think that roughly confirms what we think is happening. https://www.heistp.net/downloads/ingress_fairness/client/ <https://www.heistp.net/downloads/ingress_fairness/client/>

IP 1, 16 down:
  54968142 bytes transferred
  5313 drops (according to tcp.analysis.lost_segment)
  54968142 + 1514 * 5313 = 63012024

IP 2, 1 down:
  63769820 bytes transferred
  61 drops (according to tcp.analysis.lost_segment)
  63769820 + 1514 * 61 = 63862174

Knowing this though, maybe the current behavior is, after all, what we want. :)

I mean, if a host has caused more drops with more simultaneous flows, then it has filled the pipe with that data, even if it’s been dropped to signal congestion. Should we penalize other hosts in order to equalize goodput for all hosts, regardless of how many flows they use? If a client wants to ensure that they aren’t “charged" for drops for fairness purposes, they can use ECN.

I think it’s subjective and I’m willing to be corrected or be convinced otherwise, but thanks for bringing me to this point though…

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20190303/d03a2ac1/attachment.html>