> On 21 Jul, 2018, at 11:01 pm, Dave Taht <dave.t...@gmail.com> wrote: > > The cmts buffer fills more rapidly, particularly in slow start, while > presenting packets to the inbound shaper at 100mbit. cake starts > signalling, late, trying to achieve but at that point the apparent > RTTs are still growing rapidly (because of the buffer building up in > the cmts inflicting that RTT), so as fast as we signal, we've got such > a big buffer built up in the CMTS that tcp only sees one signal per > RTT which is mismatched against what cake is trying to thwart. The > pathology persists. > > the idea for bobbie was that the goal for codel is wrong for inbound > shaping, that instead of aiming for a rate, we needed to sum all the > overage over our rate and reduce that until it all drains from cmts > shaper.
Another possibility, which I've previously mentioned but haven't got around to implementing, is to give ECN more flexibility in signalling - so that it can indicate impending congestion as well as actual congestion. That is, as well as the present CE mark meaning "back off now", there may be softer signals carried on the dual encodings of ECT, meaning "ramp down now", "don't ramp up", and "ramp up only with caution". These signals can be given without delay, according to instantaneous conditions at the bottleneck, without needing to estimate path RTT. You could think of it as a version of DCTCP that can actually be deployed in the internet, because it doesn't destroy the existing meaning of CE. The main problem is with getting the endpoints (both receiver and sender) to recognise these new signals and react appropriately to them. Producing these signals at the AQM is relatively easy. I think I worked out a way to do it with the two padding bytes that normally accompany the Timestamp option in TCP - this requires replacing the Timestamp option with one that has the same semantics, but also carries the extra data about recent ECT marks, and doesn't require padding to be naturally aligned in the packet. This would give a way to halt slow-start when it reaches roughly the correct window size, instead of having it overshoot first. It would also give a way to gently control the cwnd to the ideal value while in steady-state, instead of oscillating around it. - Jonathan Morton _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
