Re: [aqm] Please review: Benefits and Pitfalls of using ECN
On 3/11/2015 4:10 PM, go...@erg.abdn.ac.uk wrote: Alas, due to a slight technical mistake by me, we missed the ID deadline. So I have posted an interim version here: http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.txt http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml I've reviewed this copy and have some comments, one larger and the rest smaller. Large comment: I (personally) really do not like using the word pitfall in this document, given that we want people to use ECN, and not scare them about this list of pitfalls that await them the day they start using it. We could call these operational difficulties that have been encountered or challenges due to misbehaving network devices and endpoints. I worry about someone that doesn't have time to carefully read and consider all the benefits and whether they outweigh the pitfalls, and may not fully grok that the pitfalls have known mitigations and will hopefully go away over time. We *should* be more clear that there are mitigations and that plenty of nodes are able to use ECN happily today because it is implemented in the major OSes and network devices. For instance, there is no mention of things like ECN blackhole detection, and measurements of this, such as: http://conferences.sigcomm.org/imc/2011/docs/p171.pdf We *definitely* need to stress that bleaching, lying, and cheating behaviors are non-conformant, in some cases may be from legacy code, and should be expected to go away over time rather than proliferate, because these behaviors will cause problems for the growing critical mass of conforming nodes. So, in summary, I would really suggest that we go through the document searching for every instance of pitfall and try to be more gentle, and even change the title just to The Benefits of Using Explicit Congestion Notification (ECN). There is way more text in the document about benefits than pitfalls anyways, and I think we could consider the section discussing pitfalls as just fairly presenting possible challenges to successfully using ECN. That's just my opinion ... I'd be curious what others think. Small comments: - In section 1, paragraph 3, I suggest changing the text: where the exact combination of AQM/ECN algorithms is generally not known by the transport endpoints. to: where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints. Since the document is for people that might not be familiar with this, it seems worth rewording so they don't think it's somehow bad or suboptimal that the endpoints don't know if AQM or ECN is supported within the network. - section 1, paragraph 4, I suggest changing: that would otherwise have been dropped to: that would otherwise have been dropped if the application or transport did not support ECN I think this kind of wording will emphasize that they need to make sure they're enabling it at the endpoint. - section 2, paragraph 3 should be changed: Applications that experience congestion in such endpoints to: Applications that experience congestion in such network devices Even smaller comments: - section 1, paragraph 2, forward - forwards - section 1, paragraph 2, this packet - packets - section 1, paragraph 3, The focus of this document is on usage of ECN to: The focus of this document is on usage of ECN by transport and application flows - section 2, paragraph 2, I think the ECN RFC (3168) could also be cited in addition to 2309bis for the recommended behavior for network devices -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Please review: Benefits and Pitfalls of using ECN
On 17/03/2015 15:11, Wesley Eddy wrote: On 3/11/2015 4:10 PM, go...@erg.abdn.ac.uk wrote: Alas, due to a slight technical mistake by me, we missed the ID deadline. So I have posted an interim version here: http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.txt http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml I've reviewed this copy and have some comments, one larger and the rest smaller. Large comment: I (personally) really do not like using the word pitfall in this document, given that we want people to use ECN, and not scare them about this list of pitfalls that await them the day they start using it. We could call these operational difficulties that have been encountered or challenges due to misbehaving network devices and endpoints. I worry about someone that doesn't have time to carefully read and consider all the benefits and whether they outweigh the pitfalls, and may not fully grok that the pitfalls have known mitigations and will hopefully go away over time. We *should* be more clear that there are mitigations and that plenty of nodes are able to use ECN happily today because it is implemented in the major OSes and network devices. See below. For instance, there is no mention of things like ECN blackhole detection, and measurements of this, such as: http://conferences.sigcomm.org/imc/2011/docs/p171.pdf OK - Happy to cite this. We *definitely* need to stress that bleaching, lying, and cheating behaviors are non-conformant, in some cases may be from legacy code, and should be expected to go away over time rather than proliferate, because these behaviors will cause problems for the growing critical mass of conforming nodes. Agree, we can emphasise this. So, in summary, I would really suggest that we go through the document searching for every instance of pitfall and try to be more gentle, and even change the title just to The Benefits of Using Explicit Congestion Notification (ECN). There is way more text in the document about benefits than pitfalls anyways, and I think we could consider the section discussing pitfalls as just fairly presenting possible challenges to successfully using ECN. That's just my opinion ... I'd be curious what others think. Personally, I'd be really happy to do rework this language. I would also like to revert the title (to just say benefits, as in the original Individual ID submission), I believe we changed the title in response to comments from the group, but this was at a time when we had not describe some of the realities of deploying ECN. I'd like to think these have been addressed, and revert to the original title. Note: If any people prefer to keep the pitfall word, then send an email asap - and give me some advice, otherwise I'll likely follow the edits suggested above. Small comments: - In section 1, paragraph 3, I suggest changing the text: where the exact combination of AQM/ECN algorithms is generally not known by the transport endpoints. to: where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints. Agree. Since the document is for people that might not be familiar with this, it seems worth rewording so they don't think it's somehow bad or suboptimal that the endpoints don't know if AQM or ECN is supported within the network. - section 1, paragraph 4, I suggest changing: that would otherwise have been dropped to: that would otherwise have been dropped if the application or transport did not support ECN Agree. I think this kind of wording will emphasize that they need to make sure they're enabling it at the endpoint. - section 2, paragraph 3 should be changed: Applications that experience congestion in such endpoints to: Applications that experience congestion in such network devices Oh dear, yes will fix -- or we could just say experience congestion? Even smaller comments: - section 1, paragraph 2, forward - forwards - section 1, paragraph 2, this packet - packets - section 1, paragraph 3, The focus of this document is on usage of ECN to: The focus of this document is on usage of ECN by transport and application flows - section 2, paragraph 2, I think the ECN RFC (3168) could also be cited in addition to 2309bis for the recommended behavior for network devices I'll also fix these in the draft before we upload. Gorry ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] review of CoDel -00 draft
I reviewed and have some comments on the CoDel draft: http://tools.ietf.org/html/draft-ietf-aqm-codel-00 1) I believe it would be a good idea to tie the goals listed in section 1 (in the bullet list on page 4) to the AQM guidelines from the RFC-to-be of draft-ietf-aqm-recommendation. Largely, the CoDel goals were brought into that rather than being pulled from it, but it will be good to provide a sentence or so that ties the working group documents and material together. 2) In the discussion of sojourn time as a metric (section 3.1) and using the minimum time to separate good queue from bad queue, it struck me that there is some parallel between this and the way that LEDBAT works in using the delta from the minimum as indication of queues (and congestion) building. It may be worth noting or expanding on delay-based CC in endpoints and in-network. 3) Since the algorithm and pseudocode has been published a few places before, it would be good to draw attention to a section that notes any changes or differences between what will be published in this RFC and any other revisions of the pseudocode floating around the net (or clearly note if there aren't any). In generally, it's very readable and I think it would serve as a clear basis for implementing the algorithm, so would be happy to see it go forward quickly through this working group to become an RFC. Small / editorial comments: - The abstract has [TSVBB2011] which doesn't seem to actually exist as a reference - The abstract could really be trimmed to just the 2nd paragraph, as the first is just background that's in the Introduction anyways - The (covered in another draft) at the end of section 1 can be replaced with a real reference (there's already one later in the draft in 4.6) -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
