Hi Gorry, hi Michael,
to catch up with this: I think most of my comments were addressed. Especially
the
restructuring and removing of all normative language is good. Thanks!
The one point I'm still not super happy with is section 3.6 and 3.6.1. I don't
think it reflects the problems and opportunities of using a different AQM and
different congestion control for ECN accordingly. If I see this correctly, you
didn't
change the text very much and I think that the current text is just not fully
correct.
The main issue is that the text sounds like if you have accECN, you can just go
ahead
and implement a different congestion control. However, if you use something like
DCTCP on the Internet, you'd be very aggressive and push away other traffic.
Therefore we should be more careful what we say here. I'm not even sure if this
should be discussed in the 'Benefits' section, but I do think it's important to
mention in this doc. Maybe we can also ask Bob Briscoe what he think should be
in
this section because he has been very actively working on this recently.
The other smaller point is that I'd like to see more explicitly mentioned
somewhere that ECN does not always help with tail loss because often the queue
simply is too short if a large burst is sent. (Therefore avoiding burst might
still be useful).
These are the two points I'd like to see better addressed from my review
comments. However, based on the other comments on the list, I think there are
more people who agree with me that this document sounds extremely positive and
it should more explicitly also address potentially negative consequences. Those
things are mentioned in the document but from my point of view are rather
hidden as
a reasoning for a recommendation. Therefore I would like to see some further
restructuring of the document. This is not the same than the original
'pitfalls'
section was like because that section actually also tried to give recommendation
instead of just documenting things. However, that's nothing that is for me to
decide;
maybe we should discuss this again in the next meeting (because I think the
mailing list
discussion did not really led to a conclusion...?)...?
Further, I have to say, I'm personally not super happy with sections 3-5.
Even though the normative language was removed, it still tries to give
recommendations instead of just summarizing what other docs hopefully already
recommend. Further there seems to be still quite a bit of redundancy which, if
removed, would probably improve readability. At the same time on other points
the "recommendations" are still too high level to actually be really useful,
from my point of view; e.g. see section 5 'Prerequisites for network
endpoints...": This basically says (in 3 bullets) that the used transport must
implement ECN to use ECN. That's rather obvious for me. However, it does not say
more useful things like: it should still implement the ECN SYN fallback as
specified
in RFC3168 because this cases actually still happens and that e.g. Apple has a
smaller RTO for SYNs with ECN which seems actual useful. Another things we've
just discovered while implementing this fallback for Linux was that it is
actually
not clear which state TCP should be in if a second SYN without ECN was send but
a
SYNACK with ECN is received. I think those things would be interesting if
recommendations
are given. However, this might need additional expertise from different people
that can bring
in more experience in implementing ECN and therefore I'm not sure if this doc
should
give any recommendations. That's another point that might need to be discuss at
the
next meeting (or a separate discussion on this should be started at the mailing
list).
All in all, if there is/would be consensus to move the document forward as it
is,
I'm in principle also fine with that expect that I'd would still like to see a
few changes in
section 2.6/2.6.1. However, I personally think there is more discussion needed
to what the scope
and purpose of this document is.
Mirja
On 05.05.2015 20:49, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Active Queue Management and Packet
Scheduling Working Group of the IETF.
Title : The Benefits of using Explicit Congestion
Notification (ECN)
Authors : Godred Fairhurst
Michael Welzl
Filename : draft-ietf-aqm-ecn-benefits-04.txt
Pages : 17
Date : 2015-05-05
Abstract:
The goal of this document is to describe the potential benefits when
applications use a transport that enables Explicit Congestion
Notification (ECN). The document outlines the principal gains in
terms of increased throughput, reduced delay and other benefits when
ECN is used over network paths that include equipment that supports
ECN-marking. It also describes methods that can help successful
deployment of ECN. It does not propose new algorithms to use ECN,
nor does it describe the details of implementation of ECN in endpoint
devices (Internet hosts), routers or other network devices.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-ecn-benefits-04
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
--
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland
Room ETZ G93
phone: +41 44 63 26932
email: [email protected]
------------------------------------------
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
