ietf
[Top] [All Lists]

Re: Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt

2008-09-18 08:43:58
Hi,

I believe the gen-art comments need to be discussed before this  
document can move before the IESG.

Lars

On 2008-8-21, at 23:30, ext Black_David(_at_)emc(_dot_)com wrote:

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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt, Lars Eggert <=