Hi Greg et.al., (chair hat off)
> I don't have a lot of confidence that I can recommend something to be > burned into silicon at this point (and doing it in software is a non- > starter). The "turned on or off by operators later" would be a given, but > if implemented based on what we know now, I don't have a lot of confidence > that the switch would be ever set to the "turned on" state. I can't > recommend that vendors add gates for a feature that my intuition tells me > would never be used. If separately configurable means something that > would increase the probability of the feature being used, then that's > great, but what specifically are we talking about? It could be a lot of > gates. So, as I am not a HW guy, how many gates does one need for (W)RED, PIE, CoDel? Apparently, as state needs to be kept separately for ECN and non-ECN flows, additional memory plus some way of switching between which memory is used for what packet is necessary; however, the hardcoded algos should be the same (as far as some tuneables are stored in memory instead of hardwired gates). > Also, you've suggested *not* differentiating between "classic ECN" and > "immediate ECN" in the ECT flags, but this is just a suggestion at this > point. Again, not something I feel confident about taking for granted. > We'll continue to track this discussion though. As Bob pointed out in another email, classic ECN will react to any number of marks within one RTT (of that particular flow) with only a single halving of the congestion window. Most other transports that have been modeled after TCP/ECN will behave similarly. Immediate ECN will react to each mark to a smaller extent, and only a full window (RTT) of marks will reduce the window by half. Thus immediate ECN would be much more aggressive when used with traditional RED, ie. push the AQM to higher marking probabilities. One venue that presents itself here, of course, is to use 2nd order effect - i.e. the exact marking pattern - to achive reasonable fairness between transports making use of immediate and classic reactions. However, I can not say offhand, if this would be a practical method (may require too much state in the scheduling/aqm, including fine grained flow separation). > However, it seemed to me that what you were proposing was to move the > intelligence to the transport, and keep the queue simple. In that regard, > would a very simple threshold: always mark when instantaneous queue > exceeds the threshold, never mark when it doesn¹t, be an acceptable way to > do things? > > This would be easily implementable, and could be straightforwardly > combined (I think) with any AQM that is controlling drops (including > CoDel). That is what DCTCP currently does. However, a simple step function is incompatible with classic ECN. While reading Bob's earlier comment on classic vs immediate ECN, I thought that probably an exponential increase in marking probability, above a specific threshold (lower than drop) could "autotune" to a reasonable marking rate, without necessarily locking classic out when immediate is used. If the linear/step function employed with RED (and shown on Bobs slides) is a good enough approximation needs to be verified. However, the details will probably also depend on the mixure of number of classic vs. immediate ECN flows at the bottleneck, and their respective RTTs... Finally, as the gateways (switches) cannot rely on ECN to work (either on the required timescales, as the RTT is too large for small buffers, or the transport/sender is not reacting), even ECN traffic has to be exposed to drops - and ideally here not to the tail-drop variant. Richard Scheffenegger _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
