Page MenuHomeFreeBSD

Tcp progress timeout
ClosedPublic

Authored by rrs on Sep 26 2022, 3:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 12, 10:25 PM
Unknown Object (File)
Thu, Dec 12, 1:31 AM
Unknown Object (File)
Thu, Nov 28, 4:21 PM
Unknown Object (File)
Nov 25 2024, 3:57 AM
Unknown Object (File)
Nov 21 2024, 8:12 AM
Unknown Object (File)
Nov 20 2024, 10:00 PM
Unknown Object (File)
Nov 19 2024, 2:43 PM
Unknown Object (File)
Nov 18 2024, 8:12 PM
Subscribers

Details

Summary

Rack has had the ability to timeout connections that just sit idle automatically. This
feature of course is off by default and requires the user set it on (though the socket option
has been missing in tcp_usrreq.c). Lets get the progress timeout fully supported in
the base stack as well as rack.

Test Plan

Just create a connection that makes no progress. And after the set time the connection should close automagically.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

rrs requested review of this revision.Sep 26 2022, 3:17 PM

How does this relate to the TCP User Timeout from RFC 793/9293?

How does this relate to the TCP User Timeout from RFC 793/9293?

IIRC, TCP User Timeout controls the total amount of time for a send to be completely acknowledged from the remote side. This feature sets up a minimum timeout between ACKs that move snd_una by at least X bytes.

So, for example, if a user sends 1500 bytes with a TCP User Timeout of 30 seconds, the host would close the connection if anything less than 1500 bytes were acknowledged after 30 seconds.

Or, for example, if a user sends 1500 bytes with a MAXUNACKTIME (the feature in this review) of 5 seconds, the host would close the connection unless at least X bytes were acknowledged every 5 seconds, but with no overall time limit on when the entirety of the send must be ACKed.

IMO, the two features are complementary.

This will need a few more changes yet.. so its not yet complete.

In D36716#833839, @jtl wrote:

How does this relate to the TCP User Timeout from RFC 793/9293?

IIRC, TCP User Timeout controls the total amount of time for a send to be completely acknowledged from the remote side. This feature sets up a minimum timeout between ACKs that move snd_una by at least X bytes.

So, for example, if a user sends 1500 bytes with a TCP User Timeout of 30 seconds, the host would close the connection if anything less than 1500 bytes were acknowledged after 30 seconds.

Or, for example, if a user sends 1500 bytes with a MAXUNACKTIME (the feature in this review) of 5 seconds, the host would close the connection unless at least X bytes were acknowledged every 5 seconds, but with no overall time limit on when the entirety of the send must be ACKed.

IMO, the two features are complementary.

Thanks for the clarification, I agree.

This updates and gets some of the bits I missed previously.

Could you add a description of TCP_MAXUNACKTIME to the TCP man-page?

Add the man page entry that Michael requested :)

This revision is now accepted and ready to land.Sep 27 2022, 5:02 PM
share/man/man4/tcp.4
37

Don't forget to bump the date.

This revision was automatically updated to reflect the committed changes.