kre,

| Alain Durand wrote:
| Reachability os one thing, but you may have to wait for TCP timeouts.
| RFC1122, section 4.2.3.5 TCP Connection Failures
| Says that the initial SYN has to wait at least 3 minutes...

> kre wrote:
> You're assuming that I am actually using a TCP SYN to
> detect reachability. That isn't the way it is done. We want
> to make things work well, not arbitrarily slow them down.

The problem is that the only way to _really_ test reachability is to
actually try. For example, if you can successfully ping a host it does
not mean that you can telnet to it (or the opposite: ICMP might be
blocked and it might be the best path). Or if you can open an http
connection on port 80 it does not mean that you can open an https one on
port 443 (because someone forgot to open the port) or the opposite
(because the network administrator wants to enforce an https-only web
server).

Note that I am not suggesting that the reachability discovery should be
application specific, but OTOH I don't really see how it can't be.

There might be a slippery slope that says to reduce the SYN delay, but
I'm not buying into it. Look at SMTP for example: if you open a
connection on port 25 to my mail server it is going to check your IP
against a number of spam lists before returning the ACK. This takes
time; if we put 100ms here it is broken.


What Alain refers to is one of the reasons I stated earlier that we will
continue to see split or dual-headed DNS, because if an app uses TCP as
the transport mechanism, we are looking at either a SYN to detect
reachability or at an app failure because the reachability detection
mechanism used ICMP or UDP. In either case, we are looking at
unacceptable delay. Delay leads to frustration. Frustration leads to
split-DNS.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to