Problems in implementation TCP UTO described in RFC 5482

Fang Wang wangfangcs at gmail.com
Mon May 25 16:19:30 UTC 2009


Hi!

    RFC 5482 specifies a new TCP option -- the TCP User Timeout Option
(UTO) -- that allows one end of a TCP connection to advertise its
current user timeout value. This information provides advice to the
other end of the connection to adapt its user timeout accordingly.
That means the user timeout which is fixed currently can be changed.
For more details about UTO, please read RFC 5482.
	
    The current user timeout is fact controled by retransmission times
and intervals in TCP stack, that's
1+2+4+8+16+32+64+64+64+64+64+64+64=511 seconds and 12 retransmissions
in total. After the last retransmission, it waits for another 64
seconds. Assume that a program set a 150 seconds user timeout, and of
course we use exponential backoff, so first six intervals is
1,2,4,8,16,32,64 seconds and the last interval is 23 seconds. Here is
the problem, after the last retransmission, we only waits for 23
seconds, that's not exponential backoff. And what if the last interval
is 1 second, that means the last retransmission is useless. One
alternative solution is reduce a retransmission and adjust the former
intervals, for example 1,2,4,8,16,32,65. Or just leave it alone. But I
think there may be some better ideas.

Regards,
Fang Wang


More information about the freebsd-net mailing list