Tcp progress timeout
ClosedPublic
Actions

Authored by rrs on Sep 26 2022, 3:17 PM.

Details

Reviewers

tuexen
glebius

Group Reviewers

transport

Commits

rG08af8aac2a61: Tcp progress timeout

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

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

rrs created this revision.Sep 26 2022, 3:17 PM

Herald added 1 blocking reviewer(s): transport. · View Herald TranscriptSep 26 2022, 3:17 PM

Herald added a subscriber: melifaro. · View Herald Transcript

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?

In D36716#833679, @tuexen 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.

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

In D36716#833839, @jtl wrote:

In D36716#833679, @tuexen 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.