[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tcpm] TCP, multiple addresses and soft errors when connecting

At 04:52 05/03/2004 +0200, Pekka Savola wrote:

TCP timeouts when connecting to a destination, but when the
destination is unreachable (e.g., because you don't have global IPv6
routes, your first-hop router is not operational, the packets are sent
on-link by default, etc.), TCP does not abort the connectivity (and
try the next address quicker -- instead of waiting for the TCP
timeout).

Not sure if I got it right. Do you mean TCP does not abort the conectivity, and thus the *application* cannot try the next address quicker?



2.3.1.1 TCP Connection Termination
  One solution is for TCP to abort connections in SYN-SENT or
   SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable
   message.

But what if this scenario arises for all the addresses, because of a transient problem?
The application won't cycle again, and will return an error. And the *transient* problem could disappear perhaps 5 seconds later...

IMHO, if you had a "higher-level" connect(), this behavior would make sense, as you could handle the whole issue, in a transparent way to the application.

Does it really make sense to handle the whole connection establishment issue inside the app, instead of inside the API itself?

I think that if we're debating this, we're implicitly assuming that applications want to connect to say www.example.com, and not one specific IP address to which it maps to.

So why not implement such a "higher-level" connect(), and handle all the relevant issues inside the API?


  When [HOSTREQS] was written, most applications would mostly only try
   one address when establishing communication with a destination.  Not
   aborting a connection was a sane thing to do if re-trying a single
   address was a better alternative over quitting the application
   altogether. With IPv6, and especially on dual stack systems,
   destinations are often assigned multiple addresses (at least one IPv4
   and one IPv6 address), and applications iterate through destination
   addresses when attempting connections.

Doesn't the problem really have to do with having applications performing such a low-level action?

Just my two cents,


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org