Well, there's a lot of people at the IETF who really want to do other things with ECN, but it seems like the simple version is far too aggressive.
So, I think the desirable properties are something like: 1) Allow ECN flows to achieve the same or slightly higher throughput to maintain an incentive to deploy it. 2) Still drop ECN flows eventually to avoid too much queue buildup. 3) Account somehow for the fact that marking takes longer to control the queue (but we don't know how much longer). Maybe mark ECN instead of dropping, but if we end up trying to mark/drop twice in one round, drop the later packets? Oh, and ECN nonce deployment is negligible, to the extent that there are proposals in the IETF to reuse the bits for other things, and there is no pushback on that. Andrew On 4/08/2012, at 10:30 PM, Eric Dumazet <[email protected]> wrote: > On Sat, 2012-08-04 at 20:06 -0700, Andrew McGregor wrote: >> Well, thanks Eric for trying it. >> >> Hmm. How was I that wrong? Because I was supporting that idea. >> >> Time to think. > > No problem Andrew ;) > > Its seems ECN is not well enough understood. > > ECN marking a packet has the same effect for the sender : reducing cwnd > exactly like a packet drop. Only difference is avoiding the > retransmit[s]. > > It cannot be used only to send a 'small' warning, while other competing > non ECN flows have no signal. > > As far as packet schedulers are concerned, there should be no difference > in ECN marking and dropping a packet. I believe linux packet schedulers > are fine in this area. > > Now, there are fundamental issues with ECN itself, out of Codel scope, > thats for sure. > > How widely has been RFC 3540 deployed, anybody knows ? > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
