MAC addresses, hostnames, and DHCP

[Thomas Charron]

On 12/2/05, Kevin D. Clark <kevin_d_clark at comcast.net> wrote:
>
> 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.


  120 seconds is the arbitrary number that the linux kernel clamps
retransmit times to.  RFC1122 specifies the RTO (Retransmittion Timeout)
should be at max 2x MSL.  Technically, it should max out at 4 minutes, but
I'd also be interested to see real world examples.  I haven't looked at what
various kernels/distros tune this value to be.

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*.


  Aye, most people refer to 'TCP Timeout', but what is typically infered is
RTO.

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.


  Yes, but RTT is also taken into consideration when stuffed in with nagel,
unless NODELAY was put into the socket call.

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.


  Could be, but I'm assuming it's refering to the default max MSL in the
kernel, 120 seconds.

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


  See above.  I THINK it's in tcp_timer.c, but it's been a while, I'm
tossing a guess out there.

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.


  RFC1122 is a fun read..  I remember the above becouse I was having fun
playing with sockets that could be run on a link that was down for an hour
or so.  Little practical use, but fun to play with.

  Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20051205/bd74a04e/attachment.html