I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tcpm-tcp-soft-errors-08.txt
Reviewer: David L. Black
Review Date: 21 August 2008
IETF LC End Date: 26 August 2008
Summary:
This draft is on the right track, but has open issues, described
in the review.
Comments:
This is a good draft reporting on problems encountered in practice
with TCP's handling of ICMP errors and what has been done about
them. This draft has received extensive discussion in the Transport
Area, and I believe it is wise to defer to the Transport Area decision
that this draft will not make any changes to the TCP standard.
While the draft is in generally good shape, I did find three open
issues:
(1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead.
Relevant portions of that draft should be reproduced or otherwise
explained in Section 3.2. As part of doing this, please state
whether trying v6 and v4 connections in parallel is a good idea or
not and why.
(2) Section 4.1 describes a mechanism from RFC 3168 that retransmits a
modified SYN when an RST is received in response to an ECN-setup SYN,
and suggests that this mechanism is applicable to ICMP errors received
in response to an ECN-setup SYN. This mechanism was specified in
RFC 3168 because there were known deployed middleboxes with this
problem-causing RST behavior, and the mechanism was necessary to deal
with them. Are there any known middleboxes that send an ICMP error
in response to a SYN that signals ECN capability?
- If yes, state the specific ICMP error(s) that is(are) used and limit
the recommendation to the actual error(s).
- If no, remove this entire RFC 3168 discussion as speculative, or
describe it as a possible response should this problem scenario
ever arise in practice.
(3) Section 5.3 describes a NAT behavior that causes a host TCP problem
and then suggests changing the NAT to fix it. While that's a good idea
in an ideal world (and needs to be stated in the draft), in practice,
deployed NATs have to be dealt with as-is. In addition to recommending
fixing the NAT, please discuss what could be done when the NAT cannot
be fixed.
Nits:
Section 1 - reduce generality of this text.
OLD:
This document analyzes the fault recovery strategy of TCP [RFC0793],
and the problems that may arise due to TCP's reaction to ICMP soft
errors.
NEW:
This document analyzes problems that may arise due to TCP [RFC0793]
fault recovery reactions to ICMP soft errors.
It would be good to provide the text expansion of the codes in
Figure 1, as was done in the text before the figure.
In section 4, please provide the expansion of TCPM WG (TCP Maintenance
Working Group).
idnits 2.08.10 ran clean.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf