Subject: [tcpm] FW: TCP persist timer min and max values (specified in RFC?)

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 12 Aug 2010 11:48:36 -0500

Asked on the IETF main list; kevin is at [email-masked] for
replies:

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Kevin Fall
>Sent: Wednesday, August 11, 2010 10:31 PM
>To: [email-masked]
>Subject: TCP persist timer min and max values (specified in RFC?)
>
>
>Quick and simple question---
>
>I'm trying to determine whether the range for the TCP persist timer
>([5,60] seconds commonly) is specified by RFC, or instead more of a
>historical artifact based on implementation.  If it is specified by RFC,
>could somebody please point me at it?
>
>thanks,
>- K
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Aug 2010 09:47:41 -0300

Kevin Fall wrote:

> historical artifact based on implementation.  If it is specified by
> RFC, could somebody please point me at it?

>From Section 4.2.2.17 of RFC 1122:

>             The transmitting host SHOULD send the first zero-window
>             probe when a zero window has existed for the retransmission
>             timeout period (see Section 4.2.2.15), and SHOULD increase
>             exponentially the interval between successive probes.
> 
>             DISCUSSION:
>                  This procedure minimizes delay if the zero-window
>                  condition is due to a lost ACK segment containing a
>                  window-opening update.  Exponential backoff is
>                  recommended, possibly with some maximum interval not
>                  specified here.  This procedure is similar to that of
>                  the retransmission algorithm, and it may be possible to
>                  combine the two procedures in the implementation.

Then from Section 4.2.3.1 of the same RFC:

>             The recommended upper and lower bounds on the RTO are known
>             to be inadequate on large internets.  The lower bound SHOULD
>             be measured in fractions of a second (to accommodate high
>             speed LANs) and the upper bound should be 2*MSL, i.e., 240
>             seconds.

Thus that the range *is* specified by the RFC (not hardcoded, but
derived from the RTO).

Regarding the upper limit of the RTO (and hence the persist timer), in
theory it is derived from the MSL, which in turn is derived from the
recommended TTL (60). However, most implementations use different values
for the TTL (either 255 or a power of of 2, such as 64 or 128). This,
together with the fact that the TTL is assumed to be a hop limit (rather
than a time count) might leave some room for using a different upper
limit for the RTO (and hence the persist timer).

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1