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

[Gorry Fairhurst <[e-mail]>]

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


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



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