Andrew Mcgregor <[email protected]> wrote: > > Andrew McGregor: If you find yourself in that situation, there are > approaches. In exists deploments where you have a different ECN inside the > DC then outside torward the internet. > > Should read something like "If you're trying to enable ECN in a large > content provider, you can find the routers that cause you problems and > disable ECN toward the subnets behind them.
(I'm not arguing that you didn't say that...) "Finding" such routers isn't trivial. :^( Identifying subnets behind them is even less trivial. :^( > It can be a more serious issue to deal with mark-equals-drop ECN on > the outside and early-onset ECN on the inside, since traffic often > crosses the same switches in both cases." I wish you'd find a clearer way of saying this -- in some follow-up thread on this list. I am left scratching my head as to what you're suggesting we _do_ about this (even if these cases were easy to distinguish). I would like to simply enable ECN on a mostly-vanilla webserver; and use packet-filtering _if_ I learn of a complete disaster somewhere: otherwise letting the chips fall where they may. IMHO, a router which simply clears ECN isn't a problem I need to worry about. Even a router which drops CE-marked packets isn't worth worrying about for a vanilla web-page. OTOH, a router which drops all ECN-enabled packets is major damage which needs public humiliation. (So I'm not in a big hurry to hide its broken behavior.) This issue clearly deserves discussion (though I'm not in any hurry to convert others to my views). Perhaps there is a better list for such discussion, but it's not obvious where else to hold it... -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
