* [net-next PATCH v4 1/3] net: TCP thin-stream detection
@ 2010-02-16 14:40 Andreas Petlund
2010-02-18 0:32 ` David Miller
2010-02-21 10:21 ` Pavel Machek
0 siblings, 2 replies; 11+ messages in thread
From: Andreas Petlund @ 2010-02-16 14:40 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Ilpo Järvinen, Eric Dumazet, Arnd Hannemann, LKML,
shemminger, David Miller, william.allen.simpson, damian,
Eric W. Biederman
Major changes: Added thin-stream info in new file:
Documentation/networking/tcp-thin.txt
Signed-off-by: Andreas Petlund <apetlund@simula.no>
---
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 IOCTLS or the
+tcp_thin_linear_timeouts and tcp_thin_dupack sysctls. Both
+modifications are turned off by default.
+
+References
+==========
+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"
+http://simula.no/research/nd/publications/Simula.nd.477/simula_pdf_file
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 {
TCP_SEQ_STATE_LISTENING,
--
1.6.3.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection
2010-02-16 14:40 [net-next PATCH v4 1/3] net: TCP thin-stream detection Andreas Petlund
@ 2010-02-18 0:32 ` David Miller
2010-02-21 10:21 ` Pavel Machek
1 sibling, 0 replies; 11+ messages in thread
From: David Miller @ 2010-02-18 0:32 UTC (permalink / raw)
To: apetlund
Cc: netdev, ilpo.jarvinen, eric.dumazet, hannemann, linux-kernel,
shemminger, william.allen.simpson, damian, ebiederm
From: Andreas Petlund <apetlund@simula.no>
Date: Tue, 16 Feb 2010 15:40:32 +0100
>
> +/* 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 */
Please format comments:
/* Like this. */
or:
/* Like this.
* And this.
*/
Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection
2010-02-16 14:40 [net-next PATCH v4 1/3] net: TCP thin-stream detection Andreas Petlund
2010-02-18 0:32 ` David Miller
@ 2010-02-21 10:21 ` Pavel Machek
2010-02-21 11:23 ` Alexander Zimmermann
1 sibling, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2010-02-21 10:21 UTC (permalink / raw)
To: Andreas Petlund
Cc: netdev@vger.kernel.org, Ilpo J?rvinen, Eric Dumazet,
Arnd Hannemann, LKML, shemminger, David Miller,
william.allen.simpson, damian, Eric W. Biederman
Hi!
> +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.
2) seems very dangerous/unfair. If network congestion is caused just
by thin streams, will the network just fall apart?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection
2010-02-21 10:21 ` Pavel Machek
@ 2010-02-21 11:23 ` Alexander Zimmermann
[not found] ` <2EC47E8B-BC4C-4DAB-86ED-F702D67F8AD0@nokia.com>
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Zimmermann @ 2010-02-21 11:23 UTC (permalink / raw)
To: Pavel Machek, Andreas Petlund, lars.eggert
Cc: netdev, Ilpo J?rvinen, Eric Dumazet, Arnd Hannemann, LKML,
shemminger, David Miller, william.allen.simpson, Lukowski Damian,
Eric W. Biederman
Am 21.02.2010 um 11:21 schrieb Pavel Machek:
> Hi!
>
>> +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.
>
> 2) seems very dangerous/unfair. If network congestion is caused just
> by thin streams, will the network just fall apart?
and 1) can also be dangerous if we have reordering on the path.
I strongly suggest that we discuss Andreas' idea on IETF TCPM *before*
we integrate it in the kernel and enable it for everyone
Alex,
as an netdev reader and TCPM member
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-02-22 22:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-16 14:40 [net-next PATCH v4 1/3] net: TCP thin-stream detection Andreas Petlund
2010-02-18 0:32 ` David Miller
2010-02-21 10:21 ` Pavel Machek
2010-02-21 11:23 ` Alexander Zimmermann
[not found] ` <2EC47E8B-BC4C-4DAB-86ED-F702D67F8AD0@nokia.com>
[not found] ` <20100221.150311.193707249.davem@davemloft.net>
2010-02-22 6:41 ` Lars Eggert
2010-02-22 15:17 ` Andi Kleen
2010-02-22 15:35 ` Alexander Zimmermann
2010-02-22 15:40 ` Andreas Petlund
2010-02-22 15:51 ` Andreas Petlund
2010-02-22 16:06 ` Hagen Paul Pfeifer
2010-02-22 22:13 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).