On Fri, 24 Apr 2015, Wesley Eddy wrote:
To keep moving forward with the set of documents, we'd like to start
a Working Group Last Call on:
http://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
Please send any comments you have on this document to the list
by May 8th. Other than those raised in the thread Mirja has just
opened with her review, I'm not aware of any other open issues.
I have re-read this document as if I never read it before. Writing my
thoughts as I read it.
The title says "benefits" but the abstract states that the document will
talk about both benefits and potential problems. I therefore think the
title does not reflect the abstract.
1. Introduction: I don't understand the "(potential)", doesn't transport
always treat loss and CE marking as indications of congestion? Actually,
the way the introduction reads today one might interpret that TCP and SCTP
are "Internet transports" but UDP is not, because it's merely "transport".
Can we have a reference to AQM in the second paragraph? What is the
difference between a router and a middle box?
I don't like the first sentence in the 3rd paragraph, shouldn't it say
that the device "might mark instead of drop", and not say "as the queue
builds"? Because if we have a cisco-style policer, there is no queue but
instead a token-bucket rate limiter. I don't like "as the network queue
builds" anyhow, if it should stay, it should be rephrased to "interface
queue size increases" or something like that. What if there are several
queues? I'd like the last part to not be included at all. Also, is the
document really saying that ECN should be done before incuring loss for
non-ECN traffic? The current wording can be interpreted as such.
Fourth parahraph. I have no idea what "incipient" means. I looked it up.
Can we use the word "developing" or some other synonym?
2.2. Here we have incipient again, and isn't drop or CE marking an
indicator of actual congestion, not just developing/incipient congestion?
How do we stop older bleaching-boxes that do not understand ECN bits and
still bleach them, from just forwarding the packet even if CE=1? I
understand the must requirement and it makes sense, but I don't see how
this can be achieved with older equipment?
3.1. I would like to see text after 0.02 that says something like (1
packet in 50) or something like that, just for clarification, or that the
packet drop rate is 2%. It's not obvious that "the packet drop ratio is
0.02" means these things.
My summary: I would like to see some text on the downsides of having ECN
transport, ECN enabled routers and having middle box bleaching ECN bits,
thus removing the congestion signal. This downside, and the operational
problem that some old equipment just simply drop packets with ECN bits set
should be summarized the same way as the benfits. These are the only
drawbacks of enabling ECN that I can see, and potentially text describing
how to detect these problems could be added/extended (it's somewhat hinted
at currently).
Generally, I support the document, it's useful, provides good insight, and
is valuable to the community. Thanks for writing it!
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
