> On 26 May, 2015, at 14:31, Mikael Abrahamsson <[email protected]> wrote: > > I just read https://lwn.net/Articles/645115/ about CDG congestion control. > > After reading the article, I am left wondering how this kind of congestion > control mechanisms handles being exposed to a token bucket policer: > > http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html > > With this kind of rate limiting, there is never any buffering or increase in > latency, you're only seeing packet drops, no other congestion signal. > > Anyone have any insight?
It doesn’t have to be a policer - most properly-configured AQMs also start to mark or drop packets before significant extra delay can be measured by the endpoints, which is why LEDBAT behaves like a conventional TCP under AQM. I would hope that CDG responds appropriately to ECN marks, even if it assumes packet loss might not be congestion-related. I happen to believe that the ultimate goal of zero induced delay can *only* be achieved using a combination of network and endpoint intelligence, not one or the other alone. Lots of work has been done so far on endpoint intelligence, using the assumption that the network uses only dumb FIFOs (which is, at present, a reasonable observation). CDG is merely another example of this. - Jonathan Morton _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
