[tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06

[Gorry Fairhurst <[e-mail]>]

The document looks in good shape, and seemed easy to read to me.

Here are a few comments on the latest draft, really relating to
congestion-control and increased state.

Best wishes,
 
Gorry

In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by Default):
There may also be drawbacks in this approach --- e.g. this creates
additional host state, and could also establish additional context state for
other devices along the network path (NAT. Firewall, link compressors,
encryption devices, etc).

Similarly, section 5 does not speak of the effects of a non-standard
approach on the network. One question I have relates to the behaviour of a
parallel and/or successive strategy to exploit multiple IP bindings. If I
understand, this opens a (potentially) large number of connections, to see
which succeeds. This seems to me to be injecting extra SYN packets into the
network, and therefore can potentially waste network resources.
 
If these connections are in series, each is opened one after another, after
a "fixed" time (i.e. not exponentially backed-off)... which generates more
state or more packets/rtt than using the standard algorithm.
 
When connections are opened in parallel, this is even more noted.  In an
extreme case, this could look like a syn-attack or lead to congestion-based
loss.  Are these concerns valid? Is this only used for a single IPv4 and an
equivalent IPv6 address? Are there limitations that would mitigate these
effects if I had many candidate addresses?
 

----

The remaining comments are editorial, for the author to consider in their
next rev:
 
INTRODUCTION, paragraph 14:
- Could consider to tighten English a little.

CURRENT:
    This document describes a non-standard, but widely implemented,
    modification to TCP's handling of ICMP soft error messages, that
    rejects pending connection-requests when those error messages are
    received.  This behavior reduces the likelihood of long delays
    between connection establishment attempts that may arise in a number
    of scenarios, including one in which dual stack nodes that have IPv6
    enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
    environments.
SUGGESTION:
    This document describes a non-standard, but widely implemented,
    modification to TCP's handling of ICMP soft error messages, which
    rejects pending connection-requests when these error messages are
    received.  This behavior reduces the likelihood of long delays
    between connection establishment attempts that may arise in a number
    of scenarios, including one in which dual stack nodes that have IPv6
    enabled by default are deployed in IPv4, or mixed IPv4 and IPv6
    environments.

Section 1., paragraph 2:
    In the Internet architecture, the Internet Control Message Protocol
    (ICMP) [RFC0792] is one fault isolation technique to report network
    error conditions to the hosts sending datagrams over the network.

- Add the IPv6 ICMP reference too here?


Section 3.2., paragraph 1:
- Language could perhaps be improved.
CURRENT:
    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
    [I-D.ietf-v6ops-v6onbydefault].

SUGGESTION:

    A particular scenario in which the problems outlined above
    can occur regularly arises where dual stack nodes (with IPv6 enabled
    by default) are deployed in IPv4 or mixed IPv4 and IPv6 environments,
    and the IPv6 connectivity is non-existent.
    [I-D.ietf-v6ops-v6onbydefault].

Section 4.1., paragraph 0:
Could Add: Section 5 discusses drawbacks to changing this behaviour.


Section 4.2., paragraph 1:
- Language could perhaps be improved.
OLD:
    A more conservative approach than simply treating soft errors as hard
    errors as described above would be to abort a connection in the SYN-
    SENT or SYN-RECEIVED states only after an ICMP Destination
    Unreachable has been received a specified number of times, and the
    SYN segment has been retransmitted more than some specified number of
    times.

SUGGESTION:
    An approach that is more conservative than simply treating soft errors
    as hard
    errors, as described above, would be to abort a connection in the SYN-
    SENT or SYN-RECEIVED states only after an ICMP Destination
    Unreachable has been received a specified number of times, and the
    SYN segment has been retransmitted more than some specified number of
    times.

Section 5, paragraph 1:
- Capital E?
CURRENT:
    +----------------------------------+--------------------------------+
    |   Time Exceeded (codes 0 and 1)  |  Time exceeded (codes 0 and 1) |
                                               ^

Section 5.3., paragraph 1:
CURRENT:
    Some NATs respond to an unsolicited inbound SYN segment with an ICMP
    soft error message.  If the system sending the unsolicited SYN
    segment implements the workaround described in this document, it will
    abort the connection upon receipt of the ICMP error message, thus
    probably preventing TCP's simultaneous open through the NAT from
    succeeding.  However, it must be stressed that those NATs described
    in this section are not BEHAVE-compliant, and therefore should
    implement REQ-4 of [I-D.ietf-behave-tcp] instead.

SUGGESTION:
    Some NATs respond to an unsolicited inbound SYN segment with an ICMP
    soft error message.  If the system sending the unsolicited SYN
    segment implements the workaround described in this document, it will
    abort the connection upon receipt of the ICMP error message, thus
    probably preventing TCP's simultaneous open through the NAT from
    succeeding.  However, it must be stressed that the NATs described
    in this section are not BEHAVE-compliant, and therefore should
    implement REQ-4 of [I-D.ietf-behave-tcp] instead.



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