<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">> Hi Jonathan,</div><div class="gmail_extra">> </div><div class="gmail_extra">> On June 12, 2015 9:14:02 PM GMT+02:00, Jonathan Morton <chromatix99 at <a href="http://gmail.com">gmail.com</a>> wrote:</div><div class="gmail_extra">> >We have a test in Flent which tries to exercise this case: 50 flows in one</div><div class="gmail_extra">> >direction and 1 in the other, all TCP. Where the 50 flows are on the narrow</div><div class="gmail_extra">> >side of an asymmetric link, it is possible to see just what happens when</div><div class="gmail_extra">> >there isn't enough bandwidth for the acks of the single opposing flow.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> >What I see is that acks behave like an unresponsive flow in themselves, but</div><div class="gmail_extra">> >one that is reasonably tolerant to loss (more so than to delay). On a</div><div class="gmail_extra">> >standard AQM, the many flows end up yielding to the acks; on a</div><div class="gmail_extra">> >flow-isolating AQM, the acks are restricted to a fair (1/51) share, but</div><div class="gmail_extra">> >enough of them are dropped to (eventually) let the opposing flow get most</div><div class="gmail_extra">> >of the available bandwidth on its side. But on an FQ without AQM, acks</div><div class="gmail_extra">> >don't get dropped so they get delayed instead, and the opposing flow will</div><div class="gmail_extra">> >be ack clocked to a limited bandwidth until the ack queue overflows.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> >Cake ends up causing odd behaviour this way. I have a suspicion about why</div><div class="gmail_extra">> >one of the weirder effects shows up - it has to get so aggressive about</div><div class="gmail_extra">> >dropping acks that the count variable for that queue wraps around.</div><div class="gmail_extra">> >Implementing saturating arithmetic there might help.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> >There is a proposed TCP extension for ack congestion control, which allows</div><div class="gmail_extra">> >the ack ratio to be varied in response to ack losses. This would be a</div><div class="gmail_extra">> >cleaner way to achieve the same effect, and would allow enabling ECN on the</div><div class="gmail_extra">> >acks, but it's highly experimental.</div><div class="gmail_extra">> </div><div class="gmail_extra">>        This is reducing the ACK-rate to make losses less likely, but at the same time it makes a single loss more costly, so whether this is a win depends on whether the sparser ACK flow has a much higher probability to pass trough the congested link. I wonder what percentage of an ACK flow can be dropped without slowing the sender?</div><div class="gmail_extra">> </div><div class="gmail_extra">> ></div><div class="gmail_extra">> >- Jonathan Morton</div><div class="gmail_extra"><br></div><div class="gmail_extra">I also question the general usefulness of sparser ACK flows just to accommodate hyper-asymmetrical connections. The main causes of these issues are old DSL techs or DOCSIS rollouts that haven't fully switched to DOCSIS3. Many cable companies claim to be DOCSIS3 because their downstream is 3.0, but their upstream is 2.0 because 3.0 requires old line-filters to be replaced with newer ones that open up some low frequency channels. Once these channels get opened up, assuming fiber doesn't get their first, there will be a lot more available upstream bandwidth, assuming the ISPs provision it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Modern OSs already support naggle to be toggled on/off for a given TCP flow. Maybe a change to the algorithm to detect TCP RTTs above a threshhold or certain patterns in lost ACKs to trigger increasing the number of packets naggle coalesces for ACKs. My understanding of naggle is it take two parameters, a window and a max number. I think the default window is something like 100ms and the default max coalesced ACKs are two. But you can modify either value. So technically ACK rates can already be modified, it's just not done dynamically, but the feature already exists. Instead of making further changes to TCP, educate people on how to change their TCP settings?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I could see this making strange issues with really low RTTs where the RTT is lower than the naggle window making for a small receive window. Because TCP implementations have a minimum of 2 segments, it matches with naggle's default to combine two ACKs. If you suddenly decided to combine 3 segments, two segments get sent, the other side receives the segments but does not ACK them because it's waiting for a 3rd. The other side does not send any more segments because it's waiting for an ACK. You suddenly get these strange pulses based on the naggle window.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Because naggle's combine matches perfectly with the minimum outstanding segments, this corner case does not exist. But I'll leave this to people more knowledgeable than me. Just thinking out loud here.</div></div></div>