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

[Joe Touch <[e-mail]>]

Gorry Fairhurst wrote:
> 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.

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

> 
> Gorry
> 
> 
> On 2/7/07 22:13, "Joe Touch" <[e-mail]> wrote:
> 
>>
>> Gorry Fairhurst wrote:
>>> 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?
>> 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
>>
>>> ----
>>>
>>> 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
> 

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

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