Telechat Review of draft-ietf-tcpm-accecn-reqs-07
review-ietf-tcpm-accecn-reqs-07-genart-telechat-carpenter-2015-02-13-00
| Request | Review of | draft-ietf-tcpm-accecn-reqs |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | Telechat Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2015-02-17 | |
| Requested | 2015-02-12 | |
| Authors | Mirja Kühlewind , Richard Scheffenegger , Bob Briscoe | |
| I-D last updated | 2015-02-13 | |
| Completed reviews |
Genart Last Call review of -07
by Brian E. Carpenter
(diff)
Genart Telechat review of -07 by Brian E. Carpenter (diff) Opsdir Last Call review of -07 by Linda Dunbar (diff) |
|
| Assignment | Reviewer | Brian E. Carpenter |
| State | Completed | |
| Request | Telechat review on draft-ietf-tcpm-accecn-reqs by General Area Review Team (Gen-ART) Assigned | |
| Reviewed revision | 07 (document currently at 08) | |
| Result | Almost ready | |
| Completed | 2015-02-13 |
review-ietf-tcpm-accecn-reqs-07-genart-telechat-carpenter-2015-02-13-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tcpm-accecn-reqs-07.txt Reviewer: Brian Carpenter Review Date: 2015-02-13 IETF LC End Date: 2014-12-04 IESG Telechat date: 2015-02-19 Summary: Almost ready -------- Comment: -------- This is a well written document. However, I saw no response to my LC review (2014-11-25) so it is repeated below. Minor issues: ------------- There's quite a lot of discussion of the issues that would be caused by lost ACKs, but it's also stated that "(in the worst case, loss will still be available as a congestion signal of last resort)" and "However, it should be noted that ECN feedback is not the last resort against congestion collapse, because if there is insufficient response to ECN, loss will ensue, and TCP will still react appropriately to loss." This doesn't address the issue that on physically lossy networks (e.g. the networks that more and more user devices live on), TCP does *not* react appropriately to loss, because it treats it as a congestion signal, and slows down when that is completely the wrong thing to do. I think that the draft should recognise the fact that when a physically lossy network is involved, ACK loss will be a real issue at exactly the same time that conventional TCP is liable to misdiagnose congestion.