Hello, David,
> (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?
[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,
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf