It is great to see some detailed comments from you looking afresh at
this. Please see below for initial replies.
>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.
>
GF/MW: We looked at both approaches, and revised to include "drawbacks" as
well, but then the list discussion seemed to favour focusing on the
"benefits", since deployment issues could change with time. I suggest we
remove the sentence about "problems" from 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".
>
GF/MW: We need to add REF to AQM recommendations [RFC2309.bis].
>
GF/MW: We'd agree, and be happy to remove "(potential)" from section 1
para 1.
>
>Can we have a reference to AQM in the second paragraph? What is the
>difference between a router and a middle box?
>
GF/MW: This echoes what is said in the AQM Recommendations draft: "The
mechanisms described in this document may be implemented in
network devices on the path between end-points that include routers,
switches, and other network middleboxes." - The difference may be in the
eyes of the beholder - all are network devices that can deploy AQM.
>
>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.
>
GF/MW: I agree policiers and other methods can track congestion state and
set a CE-mark. I'm OK with some change to "queue builds", but do not yet
understand the difference between "interface queue size increases", except
that would seem to limit only to an interface. It is OK with us to remove
"as the queue builds".
>
>What if there are several queues? I'd like the last part to not be
included at all.
>
>I suggest we add this sentence after the next para also, to balance this:
>"An endpoint that receives a congestion mark
> causes a congestion control reaction at the sender to reduce
> the maximum rate permitted by the endpoint."
>
>Also, is the document really saying that ECN should be done before
incurring loss for non-ECN traffic? The current wording can be
interpreted as such.
>
GF/MW: It enables marking before the point where a drop-tail queue would
have dropped. The ID intentionally does not describe how to implement or
to evaluate if this is done "fairly". The suggested sentence seems to be
unnecessary because it echoes what is in RFC3168, to some degree, but also
uses phrasing that can be misleading, by saying: "maximum rate permitted".
>
>Fourth pararaph. I have no idea what "incipient" means. I looked it up.
Can we use the word "developing" or some other synonym?
>
GF/MW: OK this came from the list discussion. This term has already been
used in early discussion of RED marking (e.g.,
ftp://ftp.ee.lbl.gov/papers/early.pdf) It was used in RFC 2481, and is
used several times in RFC 3168. I suggest we add some explanatory words
(e.g., "where congestion is beginning to be experienced")
>
>2.2. Here we have incipient again, and isn't drop or CE marking an
>indicator of actual congestion, not just developing/incipient congestion?
>
GF/MW: See above, one advantage of talking about "incipient" congestion is
we avoid talking about "mild" or "initial" or some other term that could
perhaps be misconstrued. It is is congestion, but reported when first
discovered.
>
>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?
>
GF/MW: We don't see more options than:
* Declare them as not complying with current use
* Go and fix those that can be fixed, and live with the others until in
the future they are finally replaced.
- I'm not sure what extra there is to say about this, apart from to
verify the operation across the path (as in section 4.1).
>
GF/MW: The phrase:
"A network device should therefore not remark an ECT(0) or ECT(1) mark to
zero [RFC2309.bis]."
- This deployment issue is consistent with the intention of RFC 2309.bis,
but is not specifically called-out in RFC2309.bis, and this reference
needs to be removed.
>
>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.
>
GF/MW: We think this change should be made.
>
>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).
>
GF/MW: We could certainly add text, how about adding something like:
>
After:
A network device should therefore not remark an ECT(0) or ECT(1) mark to
zero
Add:
This can result in packets that were originally marked as
ECN-capable being dropped by ECN-capable network devices further
along the path. This eliminates the advantage of enabling ECN.
>
And after:
Such a packet has already received ECN
treatment in the network, and remarking it would then hide the
congestion signal from the endpoints.
Add:
The endpoint will then be unaware of the signalled congestion, and
will only trigger a congestion response later if the congested
queue drops a packet. Note that ECN-enabled
networks devices need to drop excessive traffic [Section
4.2.1 of RFC2309.bis] even when this is marked as ECN-capable.
This eliminates the advantage of enabling ECN, and could slow
down the response to congestion compared to using AQM, but is not
expected to be worse than drop-tail performance.
>
>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]
>
We plan another revision of this document based on the received comments.
Please let us know if we have understood correctly.
Gorry & Michael
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
