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

From: Lars Eggert <[email-masked]>
Date: Wed, 3 Dec 2008 11:07:45 +0200

On 2008-12-3, at 10:47, Fernando Gont wrote:
>>> (FYI, the draft originally aimed at Std. Track, and discussed other
>>> alternative  approaches for dealing with the problem of long delays
>>> between connection establishment attempts. Then we changed the draft
>>> category to "Informational", to simply document this behavior. At
>>> that point, the discussion of parallel connections and other
>>> approaches was dropped).
>>
>> I don't think just ignoring this problem is acceptable, but a  
>> reference
>> to a discussion of what can be done about it in that RFC or some  
>> other
>> document should suffice.
>
> I have produced a separate PDF document with such a discussion, and
> have provided a pointer to it in the Introduction. Please let me know
> if you think this addresses the issue you raised.
>
> WG: Is this okay with the working group, or is any other approach
> preferred rather than the one I hve taken to adderss David's comments?

Quick follow-up: I have suggested to Fernando the alternative of  
including a short section of text on just this issue in the document  
itself, instead of referencing a PDF that includes a lot of other test  
(the PDF is basically what used to be appendix A, which was removed  
based on WG feedback). But that is also not aligned with prior WG  
consensus, since it would move some text back that we had removed.

Basically, David's comment is asking for some text that WG consensus  
had removed from the document, and we need to come to an agreement on  
whether we want to revisit this consensus and add some text or point  
to another document, or if we want to tell David that he's on the  
rough side of the consensus.

Feedback, please?

Lars

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Dec 2008 06:28:59 -0300

>rough side of the consensus.

FWIW, my personal take is that adding a reference to that PDF can 
address David's comments without having to add text back to the I-D.

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Dec 2008 05:47:41 -0300

Hello, David,

>I don't think just ignoring this problem is acceptable, but a reference
>to a discussion of what can be done about it in that RFC or some other
>document should suffice.

[Discussion of ECN in Section 4.1]
>Try the following two paragraphs:
>
>      [RFC3168] states that a host that receives a RST in response to the
>      transmission of an ECN-setup SYN packet MAY resend a SYN with CWR
>and
>      ECE cleared.  This is meant to deal with faulty middle-boxes that
>      reject connections when a SYN segment has the ECE and CWR bits set.
>
>     Some faulty middle-boxes (e.g., firewalls) may reject connections
>     with an ICMP soft error of <XXX> instead of an RST.  Therefore a
>     system that processes ICMP error messages as hard errors when they
>     are received for a connection in any of the non-synchronized states,
>     MAY respond to an <XXX> ICMP error message received in response to a
>     SYN segment with the ECE and CWR bits set by retransmitting that SYN
>     segment with those bits cleared instead of abandoning the
>connection.
>
>The actual ICMP error or errors need to be filled in to replace <XXX>
>above.

I ended up including this text (which is the text you proposed, with 
a couple of slight modifications):

    [RFC3168] states that a host that receives a RST in response to the
    transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and
    ECE cleared.  This is meant to deal with faulty middle-boxes that
    reject connections when a SYN segment has the ECE and CWR bits set.
    Some faulty middle-boxes (e.g., firewalls) may reject connections
    with an ICMP soft error of type 3 (Destination Unreachable), code 0
    (net unreachable) or 1 (host unreachable), instead of an RST.
    Therefore a system that processes ICMP error messages as hard errors
    when they are received for a connection in any of the non-
    synchronized states could resend the SYN segment with the ECE and CWR
    bits cleared when an ICMP "net unreachable (type 3, code 0) or "host
    unreachable" (type 3, code 1) error message is received in response
    to a SYN segment that had these bits set.

(e.g., I s/MAY/could/, as this is not a Std track document)

> > >(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.
> >
> > There's not much that could be done. However, this would just break
> > TCP simultaneous opens, that are unlikely. (As a matter of fact,
> > there are even end-system implementations of TCP that do not support
> > simultaneous opens)
>
>Please add text stating that (only thing broken is TCP simultaneous
>opens,
>which is tolerable in many situations)..

This is the resulting text:

---- cut here ----
    In those scenarios in which such a non-BEHAVE-compliant NAT is
    deployed, TCP simultaneous open could fail.  While undesirable, this
    is tolerable in many situations.  For instance, a number of host
    implementations of TCP do not support TCP simultaneous opens.
    [Zuquete]
---- cut here ----

> > >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.
> >
> > I have not incorporated this change. But please let me know if you
> > feel strongly about it.
>
>I think the old wording seriously overstates the scope of the draft, but
>this is an editorial problem, not a technical one.  I would still prefer
>to see this changed.

Ok. I have applied the proposed change.

Please let me know if there are any remaining issues in the document.

Thanks so much!

Kind regards,