William Allen Simpson wrote:

quoted

Further blue-skying...

If SACK were also enabled, it would seem that only loss of the last
segment in the "thin train" would be an issue?  Presumably, the thin
stream receiver would be in a position to detect this, perhaps with an
application-level timeout. Whether then it would suffice to allow the
receiving app to make a setsockopt() call to force an extra ACK or two
I'm not sure.  Perhaps if the thin-stream had a semi-aggressive
"heartbeat" going...

Heartbeats are the usual solution for gaming.  Handles a host of
issues, including detection of clients that have become unreachable.

(No, these are not the same as TCP keep-alives.)

Beside my code in the field and widespread discussion, I know that Paul
Francis had several related papers a decade or so ago.  My memory is that
younger game coders weren't particularly avid readers....

quoted

But it does seem that it should be possible to deal with this sort of
thing without having to make wholesale changes to TCP's RTO policies
and whatnot?

Yep.

We recognise the possibility of increasing the aggressiveness of application 
send rate in order to counteract the effect of thin streams on retransmission 
latency. Applications are by nature uninformed about the state of the layers 
below. To work around the fast-retransmit latency problems, an application 
would have to keep a very aggressive heartbeat rate even though there is no 
data to send, thus spamming the network with unneeded traffic.

To exemplify this, let's choose an SSH session from this set of statistics:
http://folk.uio.no/apetlund/lktmp/thin_apps_table.pdf. This thin stream has 
an averge packet interarrival time of 323ms. The application developer would 
have to consider how many "duds" to send in order to ensure a low 
retransmission latency. Let's say he considers RTTs lower than 60ms harmless, 
he would need to send more than 4 packets per 60ms. This would mean a 
heartbeat rate of one packet each 15ms. Considering this, the aggressively 
heartbeated application would send 67 packets per second compared to 3 in 
the original stream.

By including thin-stream semantics into the TCP code, informed decisions 
can be made to minimise the overhead while still reducing the retransmission 
latency.

Best regards,
Andreas