> On 5 Oct, 2016, at 16:59, Toke Høiland-Jørgensen <[email protected]> wrote: > > UDP floods are a concern, of > course, but CoDel doesn't deal well with those at all, so you'd probably > want a different mechanism for that.
Cake happens to have addressed the UDP flood problem by combining Codel with BLUE. I call the combination COBALT. BLUE acts on a percentage-drop basis, which makes it much better at handling unbounded flood traffic compared to Codel’s drops-per-second basis. The way BLUE works means that it doesn’t kick in until Codel has demonstrated complete inability to control the flow, which usually means it’s an “unresponsive” flow (ie. it doesn’t respect normal congestion control signals). The two therefore work together very naturally. It would also be reasonable to have the packet drops associated with BLUE at enqueue time (ie. at the tail of the queue), so that they do not occupy encryption bandwidth needlessly. Codel could still act at the queue head, which is the best position to send congestion signals from. Cake doesn’t split the actions like that, but it doesn’t have a particular need to. I think it’s definitely a good idea to have separate Codel (and BLUE) state per flow, which means they *do* need to be disambiguated at the place the drops occur. Putting the queue ID in the cb along with the enqueue time seems like a sensible way to do it. This would mean that sparse flows both don’t get signalled to unnecessarily, and don’t disrupt the sojourn-time pattern of bulk flows. - Jonathan Morton _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
