Hi, Thanks for your feedback! More below:
On 11. aug. 2014, at 20:19, Dave Taht <dave.t...@gmail.com> wrote: > On Mon, Aug 11, 2014 at 7:48 AM, Wesley Eddy <w...@mti-systems.com> wrote: >> This draft has been discussed a bit here and in TSVWG: >> >> http://tools.ietf.org/html/draft-welzl-ecn-benefits-01 >> >> As I understand, the IAB has also discussed it a bit, and would >> be happy if this was something that an IETF working group >> published. I believe the TSVWG chairs also discussed this and >> would be fine if the AQM working group adopted it. >> >> That said, there have only been a small number of mail list >> comments here about it, and we (unfortunately) didn't devote >> much of any meeting time to it in Toronto. >> >> So, *please* let us know your thoughts on this in the next few >> weeks. I believe we would try to complete it relatively quickly >> (e.g. 6 months) as an Informational RFC, assuming there is >> consensus and AD approval to add the milestone. >> >> I personally would like to see some stronger support for it from >> this working group in order to feel good about adopting it, though >> I think it is correct and may be "motherhood and apple pie" to >> many of us. > > I don't share the relentless optimism of this document, and would > like it - or a competing document - to go into the potential negatives. > > examples of this include the TOS washing problem bob alluded to > in one of the tsvwg meetings (the monday one), This is an interesting point. I was somewhat torn about this document myself, in that it recommends to "turn on ECN", but doesn't say how - personally, in fact, I'd not want to recommend using it like it's been used on up to now, but I also have no clear recommendation yet. Meanwhile, we (authors) have agreed that we'd rather stay away from recommending to "turn on ECN", but rather use the document to recommend to "be compatible" with it - i.e. *not* wash the TOS bits, and if you're a server, correctly reflect the bits. This makes the TOS washing problem not a negative point of ECN, but the behavior that the document recommends against. > the impact on > competing flows, This gets into the specific congestion control response to ECN, and the rules for ECN-marking. We try to stay away from such specifics in this document because we don't want to recommend one particular behavior here. I'd agree that not going into such specifics is wrong for a document that recommends to "turn on ECN", but we intend to no longer do that. > the problem of unresponsive agents or other > misuse, the deprecation (?) of the nonce mechanism, Not deprecated (yet?) AFAIK. > and how to > properly switch between marking and dropping in an aqm. > There are also the possibilities in new uses for ecn (for example, in > the original rmcat nada proposal), in usages on local links in routing > protocols, and in new protocols such as quic, etc. Again, specific congestion control reactions. Cheers, Michael
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
