Re: [PATCH 2/3] net: TCP thin linear timeouts

From: Andreas Petlund
Date: Thu Nov 05 2009 - 08:37:32 EST

William Allen Simpson wrote:
>> 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....
>> 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: 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

Best regards,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at