Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

From: Phil Karn ([email protected])
Date: Thu Apr 02 1998 - 17:23:09 EST


>I've been approached by folks in the wireless/mobile areas who would like
>to get similar mind-share for end-to-end solutions, but who are afraid
>they will be told their environment is too "crappy" and that they should
>clean it up.

Speaking as a wireless person, I actually *agree* that many radio
environments are "crappy" and should be cleaned up without hacking
TCP.

I do not oppose enhancing TCP when necessary to extend its operational
range, e.g., to cover longer round trip delays or lower bandwidths,
when these are unavoidable limits of the underlying media.

But when it is possible to clean up a channel, I see no reason to
burden TCP with its problems. Reliability is the main example; with
forward error correction and link layer retransmission, many radio
links can be brought up to wire line quality.

FEC can reduce the error rate on a geostationary satellite link to
virtually nothing. Put enough buffering on the link driving the
satellite channel to make queue overflows rare, and you no longer need
SACK. You *do* still need window scaling, because FEC can't do
anything about the speed of light.

Another example is the CDMA cellular data service I've been working on
at Qualcomm. The channel looks something like an ATM stream, only
about 4 decimal orders of magnitude slower, with 4 different
fixed-size cells (the largest of which is smaller than an ATM cell),
and a raw cell loss rate typically around 1-2%. As you can imagine,
TCP falls over and dies on a channel like this.

So I designed a simple, lightweight radio link protocol specifically
to carry PPP/IP packets with selective retransmission of dropped
frames. The protocol isn't designed to be bulletproof, nor does it
have to be. It merely reduces the raw packet loss rate to a level that
ordinary TCP handles quite nicely. Problem solved with no changes to
TCP.

So the well-designed radio channel really isn't all that much
different from a wired connection. Both tend to work either perfectly
or not at all. A wireless channel may spend more time in the latter
state than most wired channels (except perhaps for cable modems!), but
that's about it.

Phil



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:38 EST