<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 3, 2019, at 5:40 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" class="">chromatix99@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On 3 Mar, 2019, at 6:35 pm, Pete Heist <<a href="mailto:pete@heistp.net" class="">pete@heistp.net</a>> wrote:<br class=""><br class="">It almost seems like in ingress mode, dropped packets are being counted as bytes transferred, when they weren’t.<br class=""></blockquote><br class="">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.<br class=""><br class="">But that shouldn't affect fairness, only total throughput. Fairness is not handled by the shaper, but by the (very) extended DRR++ algorithm.<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">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. <a href="https://www.heistp.net/downloads/ingress_fairness/client/" class="">https://www.heistp.net/downloads/ingress_fairness/client/</a></div><div class=""><br class=""></div><div class="">IP 1, 16 down:<br class=""> 54968142 bytes transferred<br class=""> 5313 drops (according to tcp.analysis.lost_segment)<br class=""> 54968142 + 1514 * 5313 = 63012024<br class=""><br class="">IP 2, 1 down:<br class=""> 63769820 bytes transferred<br class=""> 61 drops (according to tcp.analysis.lost_segment)<br class=""> 63769820 + 1514 * 61 = 63862174</div><div class=""><br class=""></div><div class="">Knowing this though, maybe the current behavior is, after all, what we want. :)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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…</div><div class=""><br class=""></div></body></html>