[lkml]   [2010]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[net-next PATCH v4 1/3] net: TCP thin-stream detection
    Major changes: Added thin-stream info in new file:

    Signed-off-by: Andreas Petlund <>
    Documentation/networking/tcp-thin.txt | 47 +++++++++++++++++++++++++++++++++
    include/net/tcp.h | 7 +++++
    2 files changed, 54 insertions(+), 0 deletions(-)
    create mode 100644 Documentation/networking/tcp-thin.txt

    diff --git a/Documentation/networking/tcp-thin.txt b/Documentation/networking/tcp-thin.txt
    new file mode 100644
    index 0000000..151e229
    --- /dev/null
    +++ b/Documentation/networking/tcp-thin.txt
    @@ -0,0 +1,47 @@
    +Thin-streams and TCP
    +A wide range of Internet-based services that use reliable transport
    +protocols display what we call thin-stream properties. This means
    +that the application sends data with such a low rate that the
    +retransmission mechanisms of the transport protocol are not fully
    +effective. In time-dependent scenarios (like online games, control
    +systems, stock trading etc.) where the user experience depends
    +on the data delivery latency, packet loss can be devastating for
    +the service quality. Extreme latencies are caused by TCP's
    +dependency on the arrival of new data from the application to trigger
    +retransmissions effectively through fast retransmit instead of
    +waiting for long timeouts.
    +After analysing a large number of time-dependent interactive
    +applications, we have seen that they often produce thin streams
    +and also stay with this traffic pattern throughout its entire
    +lifespan. The combination of time-dependency and the fact that the
    +streams provoke high latencies when using TCP is unfortunate.
    +In order to reduce application-layer latency when packets are lost,
    +a set of mechanisms has been made, which address these latency issues
    +for thin streams. In short, if the kernel detects a thin stream,
    +the retransmission mechanisms are modified in the following manner:
    +1) If the stream is thin, fast retransmit on the first dupACK.
    +2) If the stream is thin, do not apply exponential backoff.
    +These enhancements are applied only if the stream is detected as
    +thin. This is accomplished by defining a threshold for the number
    +of packets in flight. If there are less than 4 packets in flight,
    +fast retransmissions can not be triggered, and the stream is prone
    +to experience high retransmission latencies.
    +Since these mechanisms are targeted at time-dependent applications,
    +they must be specifically activated by the application using the
    +tcp_thin_linear_timeouts and tcp_thin_dupack sysctls. Both
    +modifications are turned off by default.
    +More information on the modifications, as well as a wide range of
    +experimental data can be found here:
    +"Improving latency for interactive, thin-stream applications over
    +reliable transport"
    diff --git a/include/net/tcp.h b/include/net/tcp.h
    index 87d164b..e5e2056 100644
    --- a/include/net/tcp.h
    +++ b/include/net/tcp.h
    @@ -1386,6 +1386,13 @@ static inline void tcp_highest_sack_combine(struct sock *sk,
    tcp_sk(sk)->highest_sack = new;

    +/* Determines whether this is a thin stream (which may suffer from
    + * increased latency). Used to trigger latency-reducing mechanisms.*/
    +static inline unsigned int tcp_stream_is_thin(struct tcp_sock *tp)
    + return tp->packets_out < 4 && !tcp_in_initial_slowstart(tp);
    /* /proc */
    enum tcp_seq_states {

     \ /
      Last update: 2010-02-16 15:43    [W:0.025 / U:9.604 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site