Skip to main content

Last Call Review of draft-ietf-tcpm-accecn-reqs-07
review-ietf-tcpm-accecn-reqs-07-genart-lc-carpenter-2014-11-25-00

Request Review of draft-ietf-tcpm-accecn-reqs
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-12-04
Requested 2014-11-20
Authors Mirja Kühlewind , Richard Scheffenegger , Bob Briscoe
I-D last updated 2014-11-25
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 Last Call 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 2014-11-25
review-ietf-tcpm-accecn-reqs-07-genart-lc-carpenter-2014-11-25-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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tcpm-accecn-reqs-07.txt
Reviewer: Brian Carpenter
Review Date: 2014-11-25
IETF LC End Date: 2014-12-04
IESG Telechat date:

Summary: Almost ready
--------

Comment:
--------

This is a well written document.


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.