On Mon, Nov 26, 2001 at 02:47:00PM -0500, Garrett Wollman wrote: > <<On Mon, 26 Nov 2001 08:43:56 -0600 (CST), Jonathan Lemon <[EMAIL PROTECTED]> >said: > > > Unfortunately, this is not calculated; we still rely on a static > > (default 30sec) MSL quiet period. Ideally, it should be possible to > > set MSL based on some multiple of RTT for the connection, and default > > to a hard coded value if there are not enough samples to calculate RTT. > > There is no way to `calculate' the maximum segment lifetime unless you > are omniscient. It is assumed to be 30 seconds, but in reality can be > much, much more. (As a result, TCP is theoretically broken, but the > situations in which this happens are rare enough to be masked by other > events.) The RTT gives you the *critical path length* of the graph; > it does not have anything to do with the MSL except for trivial > (two-node) networks.
MSL is the maximum time that the segment is assumed to exist in the network; in practice I would interpret this to mean the maximal amount of time it takes to travel from one node endpoint to another, taking into account congestion, route changes, and queuing delay. As you said, there is no way to reliably calculate this value, since the delay is theortically unbounded; in fact RFC 793 sets it at 120 seconds. However, my assertion is that in most cases, the true MSL for segments on a given connection will tend to be tied to some multiple of the RTT; that is, there exists a strong correlation between the two. Packets can be held up for an arbitrarily long length of time, but I would imagine that the number of active segments after (say) 10*RTT would not be significantly different than the number after 30 seconds. Note that it is quite possible I'm wrong in this assertion, though. :-) -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
