[Mep-dev] TCP Performance Issues
Phil Karn
karn@ka9q.net
Mon, 24 Nov 2008 15:16:03 -0800
------=_Part_116325_4550032.1227568563552
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Mon, Nov 24, 2008 at 9:14 AM, Timothy J. Salo <salo@saloits.com> wrote:
>
>
> Latency, in and of itself and in the absence of errors, is
> pretty much _not_ an issue for TCP. People have made
> TCP run at full speed over 622 Mbps GEO satellite links.
> (See Mark Allman's work with the ACTS High Data Rate
> terminal.) All you need is a modern TCP implementation
> (with the window-scale option and a few other pieces),
> perhaps some tuning of the end hosts, and an end-to-end
> path with a very low error rate. Google "TCP satellite"
> for over two million Web pages on this topic.
Correct.
> This leads to the question: How can you make TCP perform
> well over lossy paths that may also have high latencies?
>
> The first answer is to reduce the packet-loss loss rate on
> the path, or more precisely, on each link in the path.
> See, for example, RFC 3819, "Advice for Internet
> Subnetwork Designers" (edited by Phil Karn).
Yup. :-)
> Another approach is to use a performance-enhancing proxy
> (PEP). PEPs essentially break the end-to-end TCP connection
> into several concatenated connections.
Do ***NOT*** do this. I wish I had a nickle for every grad student project
I've seen that does this. It's a very bad idea. It breaks the end-to-end
nature of TCP, upsets how it does flow control, and violates assumptions the
application can ordinarily make about how TCP behaves.
As Tim says, just make sure that the network packet loss rate is reasonably
low and that your TCP can handle the bandwidth-delay product and you'll be
fine.
------=_Part_116325_4550032.1227568563552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div class="gmail_quote">On Mon, Nov 24, 2008 at 9:14 AM, Timothy J. Salo <span dir="ltr"><<a href="mailto:salo@saloits.com">salo@saloits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Latency, in and of itself and in the absence of errors, is<br>
pretty much _not_ an issue for TCP. People have made<br>
TCP run at full speed over 622 Mbps GEO satellite links.<br>
(See Mark Allman's work with the ACTS High Data Rate<br>
terminal.) All you need is a modern TCP implementation<br>
(with the window-scale option and a few other pieces),<br>
perhaps some tuning of the end hosts, and an end-to-end<br>
path with a very low error rate. Google "TCP satellite"<br>
for over two million Web pages on this topic.</blockquote><div><br>Correct.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This leads to the question: How can you make TCP perform<br>
well over lossy paths that may also have high latencies?<br>
<br>
The first answer is to reduce the packet-loss loss rate on<br>
the path, or more precisely, on each link in the path.<br>
See, for example, RFC 3819, "Advice for Internet<br>
Subnetwork Designers" (edited by Phil Karn).</blockquote><div><br>Yup. :-)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another approach is to use a performance-enhancing proxy<br>
(PEP). PEPs essentially break the end-to-end TCP connection<br>
into several concatenated connections.</blockquote><div><br>Do ***NOT*** do this. I wish I had a nickle for every grad student project I've seen that does this. It's a very bad idea. It breaks the end-to-end nature of TCP, upsets how it does flow control, and violates assumptions the application can ordinarily make about how TCP behaves.<br>
<br>As Tim says, just make sure that the network packet loss rate is reasonably low and that your TCP can handle the bandwidth-delay product and you'll be fine.<br> </div></div><br>
------=_Part_116325_4550032.1227568563552--