(I have read Michael's reply to this, but I'll respond here.)

Dave Taht <[email protected]> wrote:
> On Mon, Aug 11, 2014 at 7:48 AM, Wesley Eddy <[email protected]> wrote:
> 
>> This draft has been discussed a bit here and in TSVWG:
>> http://tools.ietf.org/html/draft-welzl-ecn-benefits-01

   I do think this is the right place to discuss it.

>> 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.

   Thus, I am in favor of adopting it, with the understanding that
it will see significant changes during our discussion.

> I don't share the relentless optimism of this document, and would
> like it - or a competing document - to go into the potential negatives.

   I think it should concentrate on what its name says: the benefits
of ECN, both now and in an expected future; but that it should also
at least mention downsides this WG sees: and that it should avoid any
recommendation stronger than "make ECN available to consenting
applications".

> examples of this include the TOS washing problem bob alluded to
> in one of the tsvwg meetings (the monday one),

   This definitely deserves mention.

> the impact on competing flows,

   That might have to go into a companion document. I think this
document could try to describe the bounds of such issues, but not
the details.

> the problem of unresponsive agents or other misuse,

   I'm not sure what Dave is alluding to here...

> the deprecation (?) of the nonce mechanism,

   I don't accept it as a given that the nonce should be deprecated;
though I do think that discussion will come up.

> and how to properly switch between marking and dropping in an aqm.

   I doubt this document will go into much detail there. Basically,
IMHO, an AQM should mark well before dropping becomes necessary; and
when dropping becomes necessary, ECN-capable packets should be dropped
essentially as often as non-ECN-capable packets.

   I'm not sure this document should say much about that, though...

> 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.

   Sounds like interesting reading, Dave -- do you want to send pointers?

--
John Leslie <[email protected]>

_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to