[tcpm] WGLC: TCP's Reaction to Soft Errors

[Gorry Fairhurst <[e-mail]>]

Review of: draft-ietf-tcpm-tcp-soft-errors-05.txt

I think this documents an important issue that has been around for some 
time and would like to support this  progression for publication as an 
informational RFC.

It is disappointing that the IETF could not reach consensus on this 
issue (I would have liked to have seen that happen), notwithstanding 
this, it seem to me to be very worthwhile to document what is 
implemented and offer guidance that relates it to existing 
specifications. IMHO, we should publish this.

Best wishes,

Gorry

---

Questions:

1) What happens if the SYN segment contains IP or TCP options that a
middlebox rejects (and issues an ICMP error code)... if we take the
variation of the algorithm, does it imply the sender tries a new IP 
address, or that it retries with a different option combination? Are 
there any side effects from this?

2) Normally TCP backs off its timer each SYN it sends for the same
connection. Does this imply that the sender still backs-off the timeout
value when it retries with a different IP address, or does it just start
with the initial time-out value? - In cases where there is congestion or
very long network path delays this could impact stability? or even 
prevent setting up the connection is specific topologies?

3) I do not understand this sentence, can you clarify?:
/([Shneiderman] and [Thadani] offer some insight into the interactive
systems)./


Editorial comments:

------------
- the abstract is hard to parse:
"   This document describes a non-standard, but widely implemented,
    modification to TCP's handling of ICMP soft error messages received
    in any of the non-synchronized states, that rejects connections
    experiencing those errors immediately. "

I find the first line of abstract a little hard to unravel.

The problem part is /that rejects connections experiencing those errors
immediately/

"   This document describes a non-standard, but widely implemented,
    modification to TCP's handling of ICMP soft error messages. This
immediately rejects connections that receive soft errors
    in any non-synchronized state.
------------
Section 2
---
Suggest change:
/Even though ICMPv6 didn't/
to
/Even though ICMPv6 did not/
---
/one could extrapolate the concept of soft errors to ICMPv6/
                                                            ^
- Insert a reference - to RFC2463?
---
Suggest change:
/ that's not signaled /
to
/ that is not signaled /
---
/to corresponding TCP instance/
    ^
- Insert "the"
---
Suggest change:
/won't change in/
to
/will not change in/
---
Suggest change:
/   before trying alternate addresses./
to
/   before trying an alternate address./
---
Suggest change:
/   A particular scenario in which the above sketched type of problem may
    occur regularly is that where dual stack nodes that have IPv6 enabled
    by default are deployed in IPv4 or mixed IPv4 and IPv6 environments,
    and the IPv6 connectivity is non-existent/
to
/  Dual stack nodes represent a case where the type of problem outlined
    above may regularly occur.  This arise when a dual stack node with IPv6
enabled
    by default is deployed in an IPv4 or a mixed IPv4 and IPv6 environments,
    and the IPv6 connectivity is non-existent./

---
/Unreachability Detection (NUD)/
                               ^
- Insert reference.
---
Section 6.1
/IP addresses in the list/
               ^^^^^^^^^^
- The list has not been mentioned previously in this section.
-----
Suggest change:
/attack---even if only slightly/
to:
/attack, even if only slightly/
---

The suggestion of making a table in section 2, noting the set of error 
codes in IPv4 and IPv6 ICMP messages seems a usrful additional, which I 
would encourage.

---

Finally in rev-03, I commented that "I see this document is INFO - yet 
it seems to include an RFC2119 declaration, and does not use keywords."

I was concerned that the document did NOT make BCP-Style 
recommendations. However, I now realise that you do cite keywords, which 
presumably should be interpretted as per RFC2119. A note to this effect 
would be OK. (I'm confessing that I may have previously given you wrong 
advice).


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm