A flow-isolating AQM such as fq_codel would be able to deal with different flows responding differently to CE.
The problem is that core and semi-core network nodes don't have the resources to do flow isolation at line rate, or (equivalently) they deal with too many simultaneous flows to make a meaningful flow isolation scheme practically implementable. This, I assume, is where the dual queue proposal comes in. Fundamentally, dual queue needs to be able to identify the packets belonging to each queue. DSCP is a non-starter because it doesn't, in practice, survive end to end. I'm wary of using the ECN field for the same purpose - it could work, but promotimg CE packets from classic ECN flows could result in spurious retransmissions due to reordering. Simply using the presence of ECN capability is also a bad idea, because Apple's imminent deployment of classic ECN to millions of end hosts will break that assumption. A more robust deployment option would be to use a new transport protocol ID. Then it wouldn't be TCP any more, and you can throw away some cruft while you're at it. I'll leave the problems with that idea to your fertile imaginations. As a gentle reminder, ELR is designed to solve the same problem while avoiding these deployment problems. It does "burn" ECT(1), but for a good cause and - crucially - doesn't require the network to be aware of it before endpoints can safely turn it on. - Jonathan Morton
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
