Re: TCP persist timer min and max values (specified in RFC?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Fall wrote:

> 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?

>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: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]