[Mep-dev] TCP Performance Issues
Paul Williamson
paul@mustbeart.com
Mon, 24 Nov 2008 18:39:49 -0800
------=_Part_187511_11545934.1227580790019
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Mon, Nov 24, 2008 at 3:16 PM, Phil Karn <karn@philkarn.net> wrote:
> 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.
>
Unfortunately, that's impossible in the large scale. Radio equipment gets
turned off. RF paths come and go. Antennas get re-pointed to talk to a
different station. Any of these things, and dozens of others you can think
of, will cause the packet loss rate to jump to 100% on a particular link for
an arbitrary and unpredictable duration. In a perfect world, we'd have
protocols to cope with this.
Routing is a partial solution, but any link drop-out has the potential to
cause a network partition, so it's not a complete solution.
Since the network partition may be of any duration, the best we can do is
some flavor of store-and-forward. Which flavor is best will depend on the
application. It's pretty obvious that for live video, or even live voice or
text chat, no kind of upper-layer store-and-forward solution is going to be
appropriate. It should be equally obvious that for other applications, like
distribution of recorded video programs, a long delay would be relatively
painless.
I have only a tiny familiarity with the DTN proposals, but my impression is
that they're intended to solve a similar set of problems: long outages and
intermittent connectivity. The bandwidth-delay product is not the right
concept for modeling these scenarios.
73 -Paul
kb5mu@amsat.org
------=_Part_187511_11545934.1227580790019
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div class="gmail_quote">On Mon, Nov 24, 2008 at 3:16 PM, Phil Karn <span dir="ltr"><<a href="mailto:karn@philkarn.net">karn@philkarn.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>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.</div></div></blockquote><div><br>
</div><div>Unfortunately, that's impossible in the large scale. Radio equipment gets turned off. RF paths come and go. Antennas get re-pointed to talk to a different station. Any of these things, and dozens of others you can think of, will cause the packet loss rate to jump to 100% on a particular link for an arbitrary and unpredictable duration. In a perfect world, we'd have protocols to cope with this.</div>
<div><br></div><div>Routing is a partial solution, but any link drop-out has the potential to cause a network partition, so it's not a complete solution.</div><div><br></div><div>Since the network partition may be of any duration, the best we can do is some flavor of store-and-forward. Which flavor is best will depend on the application. It's pretty obvious that for live video, or even live voice or text chat, no kind of upper-layer store-and-forward solution is going to be appropriate. It should be equally obvious that for other applications, like distribution of recorded video programs, a long delay would be relatively painless.</div>
<div><br></div><div>I have only a tiny familiarity with the DTN proposals, but my impression is that they're intended to solve a similar set of problems: long outages and intermittent connectivity. The bandwidth-delay product is not the right concept for modeling these scenarios.</div>
<div><br></div><div>73 -Paul</div><div><a href="mailto:kb5mu@amsat.org">kb5mu@amsat.org</a></div><div><br></div></div>
------=_Part_187511_11545934.1227580790019--