| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 27 Oct 2009 17:28:34 +0100 From: Andreas Petlund <apetlund@...ula.no> To: netdev@...r.kernel.org CC: linux-kernel@...r.kernel.org, shemminger@...tta.com, ilpo.jarvinen@...sinki.fi, davem@...emloft.net Subject: [PATCH 0/3] net: TCP thin-stream latency-improving modifications This is a series of patches enabling non-intrusive, dynamically triggered modifications that improves retransmission latencies for thin streams. The patches are based on the original modifications posted in this RFC: http://article.gmane.org/gmane.linux.rt.user/3674/match= http://article.gmane.org/gmane.linux.kernel/779290/match= We have done our best to address the feedback from the RFC in the new patch set. TCP streams with high interarrival time between packets (thin streams) are often found to be produced by interactive/time-dependent applications. Such streams are not able to trigger fast retransmissions, since too few dupACKs are received before a retransmission by timeout occurs. Exponential backoff also leads to large delays. Since the applications producing such data patterns are very often time-dependent, this causes delays that are very disturbing for the application performance/experience. This set of patches introduce two simple modifications that improves the latencies for thin streams: 1) If the stream is thin, fast retransmit on the first dupACK. 2) If the stream is thin, do not apply exponential backoff. The modifications are only active if specifically enabled by syscontrol or iocontrol. If enabled, the thin-stream detection is dynamically triggering the modifications on and off based on the current number of packets in flight. Thus, regular (greedy) streams do not trigger the modifications. The modifications are thoroughly tested and found to improve retransmission latency considerably without negatively influencing fairness. This is also the case when very many streams using the modifications share a common bottleneck. We have also developed a bundling mechanism (see the RFC linked to above) that can be used in thin-stream scenarios where the packet sizes are small. This mechanism is more intrusive, and will be posted for the net-next tree when we have revised the design. For more information on time-dependent thin streams and the modifications, please refer to the articles linked to below: http://simula.no/research/networks/publications/Simula.ND.159/simula_pdf_file http://simula.no/research/networks/publications/Simula.ND.185/simula_pdf_file http://simula.no/research/networks/publications/Simula.ND.112/simula_pdf_file http://simula.no/research/networks/publications/Simula.ND.35/simula_pdf_file Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists