I've been pondering this commit and wonder if we're throwing out baby
with bathwater:

https://github.com/dtaht/sch_cake/commit/90e792115f10fa2a31327208302e66c0ab3f2251

The original code, to paraphrase in something resembling English went:

1. I've just enqueud a packet & Oh sh*t we're over our q_disc buffer
limit, we'd better do something about it, hmmm
2. Whilst we're over this limit, go look through our flows (cake_drop)
and kill something, if that something was in the same flow as the thing
we just enqueued then set a flag 'cos these guys are part of the
problem!  Keep track of how many things we killed.
3 Now we're below the limit and finished killing packets, return back to
our caller - if we killed stuff in the same flow the caller is sending,
then return 'NET_XMIT_CN' (we're congested), else just say 'happy as Larry'

 *//* NET_XMIT_CN is special. It does not guarantee that this packet is
lost. It/*
*/* indicates that the device will soon be dropping packets, or already
drops/*
*/* some packets of the same priority; prompting us to send less
aggressively. *//*

What I do agree looked odd in the original code was the 'dropped -
same_flow':  We haven't dropped any more or fewer packets just 'cos we
found one or more in 'the same flow'.

-        qdisc_tree_decrease_qlen(sch, dropped - same_flow);  <--????????
+        qdisc_tree_decrease_qlen(sch, dropped);

Incidentally, a search of 'NET_XMIT_CN' turned up
http://www.bufferbloat.net/issues/398.pdf