MAC addresses, hostnames, and DHCP

[Kevin D. Clark]

Ben Scott writes:
> On 12/2/05, Bill McGonigle wrote:
>> >   However, there are some caveats.  If any traffic occurs (payload, or
>> > SSH control traffic like rekeying, keep-alive, etc.), TCP (or higher
>> > level protocols) may time out before the IP layer finishes coming back
>> > up.  This is especially likely if you're using SSH to tunnel X11.
>>
>> There seems to be a two-minute window where you can get away with this.
>>  TCP sees it as packet loss.  I forget why 120 seconds is a magic
>> number - something either in the spec/defaults for TCP packet retries.
>
>   2 minutes is the default TCP... MSL (maximum segment life) or RTT
> (re-transmission timeout).  I can't remember which, but I rember that
> RTT = 2 * MSL.  IIRC, the 2 minute figure was somewhat arbitrary, but
> based on some accurate real-world experience, and was noted somewhere
> else as meaning "FTP to Mars" would not be possible, but noted
> somewhere else as changeable, so FTP to Mars would be possible, or
> something.  My memory is fuzzy.  :)
>
>   Of course, that only comes into play if TCP is trying to transmit
> data -- hence the "idle" part.  If data isn't flowing, then you can
> unplug the cable for hours and nothing will notice.  Other protocols
> often have their own timeouts as well (such as the SSH keep-alives,
> which become "make-deads" in that case).

Hmm.  This is all very interesting.  Really.  I have some comments:

1:  The two-minute window thing is interesting and I for one wouldn't
mind seeing some packet dumps from the wild.  

2:  TCP doesn't have any keepalives by default, and when it does, the
time period for these are typically in the range of *hours*.

3:  In the context of TCP, RTT typically refers to Round Trip Time.

3a  TCP mostly uses RTT to figure out how much stuff it can
efficiently jam into the pipe.

4:  The two minute timer that I believe that you are referring to
related to TCP's TIME_WAIT state, a state that TCP connections go into
after a connection is closed.  The "two minutes" is a typical default
MSL.

5:  The TIME_WAIT state mostly exists to ensure that route-flapped
packets get properly ignored.  TCP implementations typically put
connections in the TIME_WAIT state for 2*MSL seconds in order to drain
the network of this cruft.

5a:  I posted a big long gory explanation of the TIME_WAIT state on
this mailing list a while ago if you want more info on TIME_WAIT.

6:  I can't recall any other "two minute" timer associated with TCP
other than the one associated with the TIME_WAIT state.

7:  If the SSH connection really is in the TIME_WAIT state, then it
must be because the SSH client/server moved the connection to that
state (indirectly, of course).

8:  OTOH, if the SSH connection really is timing out after exactly two
minutes but the state of the connection wasn't in the TIME_WAIT state
in the preceeding seconds, this suggests to me that there is more of an
application-layer timeout going on here, because TCP will almost
certainly retry for more than two minutes.  After all, it is a general
purpose reliable transport protocol.


So, this is very interesting behavior.

FIN, ACK, FIN, ACK.

--kevin
-- 
GnuPG ID: B280F24E

C/C++/Perl/Network/Linux/etc. guy looking for work.  
Contact for info.