Page MenuHomeFreeBSD

Tcp progress timeout
ClosedPublic

Authored by rrs on Sep 26 2022, 3:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 28 2024, 1:15 PM
Unknown Object (File)
Jan 28 2024, 1:15 PM
Unknown Object (File)
Dec 20 2023, 6:43 AM
Unknown Object (File)
Dec 10 2023, 12:37 PM
Unknown Object (File)
Nov 8 2023, 5:41 PM
Unknown Object (File)
Nov 7 2023, 9:18 PM
Unknown Object (File)
Nov 6 2023, 3:09 PM
Unknown Object (File)
Oct 30 2023, 9:14 AM
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.