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

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 02 Jul 2007 11:31:54 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2007 13:13:51 -0700

> effects if I had many candidate addresses?

RFC1122 discusses the technique of trying multiple addresses, and it is
issue only when a DNS name resolves to multiple addresses. It would be
unusual for a large number of addresses to refer to the same host; in
many cases, there are only a small number for one host (typically for
IPv4 and IPv6), and the larger number is used for DNS rotation to
distribute load to a number of servers. There are exceptions, such as
where multiple IP addresses are used for shared web service -- though
that has fallen out of use as newer HTTP protocols determine the host in
the request (sending GET and the DNS name, in addition to the filename)
rather than only by the IP address (which was the only way compatible
with HTTP 1.0, e.g.).

Whether in serial or in parallel, methods to moderate the number of
outstanding SYNs are probably useful. But this isn't the focus of this
document anyway.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 02 Jul 2007 21:27:34 +0100

At Monday 02/07/2007 13:13 -0700, Joe Touch wrote:
>There are exceptions, such as

Care to elaborate?

Your claims don't match what e.g. RFC1945 specifies, or what HTTP 1.0 did.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2007 19:17:57 -0700

> Your claims don't match what e.g. RFC1945 specifies, or what HTTP 1.0 did.

In 1.0 http://www.abc.com/ means
	open a connection to an IP address www.abc.com resolves to
	then issue "GET /"

In 1.1, the same URL means
	open a connection to an IP address www.abc.com resolves to
	then issue "GET / HTTP/1.1 HOST: www.abc.com"

This helps when www.abc.com and www.def.com are on the same host. In
1.0, they had to have different IP addresses*, with servers listening on
port 80 specific to those IP addresses. The address isn't actually sent
(sorry that it was implied above).

*(they could have different ports, but I'm focusing on the common case
where the port isn't specified, e.g., for common public servers)

In 1.1, you could have a single server listening on both IP addresses,
with each HOST name bound to a different file root. The HOST option
could indicate which DNS name's root to use.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 03 Jul 2007 09:53:24 +0200

My observation was only that if a host repeatedly opens several TCP sessions
to search for a valid IP address (e.g. Attempting to try all IP addresses
that correspond to abc.com), then it *could* consume much more network &
host resources, than a host that opens a session to each address in turn,
with a backoff between each request.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Jul 2007 06:31:18 -0700

> with a backoff between each request.

That's true, but there aren't rules for either parallel or serial. I.e.,
a host that opens 2 each (v4, v6) in parallel (then sequences through v4
and v6) consumes less resources than one that opens 8 in serial. It's a
matter of rules governing how to try the sequence.

I.e., either one could swamp things, depending on how the application works.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 03 Jul 2007 14:52:45 +0100

>could indicate which DNS name's root to use.

Yes, the resolved IP address is never sent (unless it's already in the url.)

In http 1.1, you can have a single server listening on a single IP address that both DNS names resolve to.

In http 1.0, the context of name/address is implicit; in 1.1 it's explicitly given with Host:

L.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 3 Jul 2007 15:02:12 +0100 (BST)

OK.

I am not suggesting the document creates new rules or methods.
My suggestion is that the  author could consider if this should
or should not be documented (in the security considerations, for 
example). This is not a showstopper to me.

Gorry