On 28/04/2015 14:34, John Leslie wrote:
Gorry Fairhurst <[email protected]> wrote:
To: Mikael Abrahamsson <[email protected]>, "[email protected]" <[email protected]>
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.
This text is a bit confusing -- I had to read it three times to
get (I think) your point. Perhaps:
"
" This would negate the advantages of ECN for congestion which may
" occur later in the path, in that an ECN-capable network device would
" not be able to forward the packet with congestion signaled by "CE".
Putting the effect first seems easier to read...
Also, the forwarding node later in the path might have signaled
congestion via "CE" at an earlier threshhold than it would drop
packets.
I agree and so we will improve the words.
However, I'm not keen on delving into what happens if (and when)
thresholds differ (or the AQM algorithm is different).
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.
I'm still failing (after five readings) to extract a clear meaning. :^(
We will look at simpler words.
There are several points:
- clearing a "CE" marking destroys the congestion signal. Barring some
extraordinary programming, this would make an ECN-enabled flow
unresponsive.
It would be less responsive than an ECN-enabled flow should be and could
congest a queue - perhaps negating all benefits - but unresponsive? - I
hope not, if it really contributes to congestion the queue should
finally drop and the flow adapt before congestion collapse.
- with an unresponsive flow, the congested node _might_ reach a level
of congestion requiring tail-drop. But it also might not. :^(
Could be so.
- _if_ a receiver added a way to observe this abuse (possibly by
having the sender set an occasional "CE" mark before sending the
packet), the responsiveness would still be degraded. Besides,
there's really no chance that _all_ flows would ever be programmed
to do this.
Yes, there are ways to be smart.
Myself, I see no reason to add text to cover all of these: I think
text covering the first point is sufficient.
--
John Leslie <[email protected]>
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
Gorry & Michael
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
