Subject: Re: pilc minutes for IETF 48

From: Vernon Schryver <[email-masked]>
Date: Fri, 20 Oct 2000 12:24:36 -0600 (MDT)

> From: Bill Yeager <[email-masked]>

> ...
> | No matter how cool things seem to us, users do not tolerate the delays
> | implied by several 1700 ms round trips for DNS followed by 3 more round
> | trips to set up an HTTP/TCP/IP session just to get an airline schedule or
> | restaurant menu so they can start to place an order.
>
> Interesting. The experience on the AT&T Cellular-I CDPD network in the bay
> area was not that bad(9600 baud was what was managed). DNS + HTTP/TCP/IP took
> about 3 to 5 seconds on the average to set up. The connect was very quick.
> There was good user feed back. I would lay in bed at night, turn on my palm
> and read my email using HandWeb, with a servlet proxy, output presentation in
> compact HTML, manage the session between me and the email backend (IMAP, LDAP,
> SMTP). It was simple to use. Not much of a boot time, etc ... That was almost
> two years ago.

1700 ms was not my number.  I am not claiming that any wireless systems
have 1700 ms round trip delays, since I have no clue about such things
except what whose who know tell me.  I'm only reasoning from the stated
premises of others who say "X is required because Y," where Y is
consistently extremely long latency and very high error rates.

My fundamental point is that people can't have it both ways:

  1. (a) because radio links have 1700 ms delays and 30% packet loss rates
   (b) things must be done to and below TCP, such as 60 seconds of ARQ.
   (I think 30% loss rates were given by wireless experts in previous
   episodes of this discussion.  ~60 sec ARQ was recently mentioned.)

  2. the same links as in #1 will be used by 1,000,000,000's of happy end
   users of very interactive Internet applications that involve lots of
   data realsoonnow, notwithstanding the implications of 1700 ms delays.
   (1,000,000,000 is also not my number, but appeared in one of the
   earliest episodes.)

If you choose the premise #1(a), then you rule out the conclusions of #2.
If you believe in the conclusions of #2, then you cannot believe in the
premises of #1(a) or you believe they'll become invalid too soon to justify
doing the things repeatedly advocated in this mailing list.  If you don't
believe in #1(b), then you can't advocate #1(b).

It is possible to be sane and support #1(a) and #1(b), provided you give
up #2.  ARQ that retries for 64 seconds (again not my number) makes good
sense for some applications, although not for the applications that have
been advocated.  For example, a PDA with a mere 100 KByte could use such
a link to fetch email while the user is not paying attention, and later,
again in the background, send email responses.  In other words, such a
link can be used just as similar Telebit Trailblazers modem links were
used in the 1980s, and as far as users could tell, it would be as on-line
and interactive as talking to their ISP.

Unfortunately, there is too much telephant thinking in the wireless world
for such insights.  We are stuck with repetitions of #1 and #2, no matter
how crazy that seems.  Telcos and telco supplliers cannot admit the
possibility of smart customer premise equipment today any more than they
could during the Carterphone case 30+ years ago.  There is no hope of the
wireless telcos admitting that a telephone might be more than a very dumb
terminal.  Just as the repeated Ericson complaints and proposals of a few
years ago to disable PPP authentication were based on the belief that it
is impossible for CPE to compute anything in less than large parts of
minutes, the so called state of the art 3G phone is assumed to be little
smarter than a Western Electric 500C.

> Smart apps can manage latency when the net data being transferred is small(3
> or 4 segments). 

Yes, but applications that involve merely 3 or 4 TCP segments have nothing
to do with the issues at hand.  Again, if applications that put 4 or fewer
segments in flight at a time were relevant, then questions of ARQ for one
packet stalling packets or triggering TCP fast retransmissions would never
have come up.

Vernon Schryver    [email-masked]

---

From: Bill Yeager <[email-masked]>
Date: Fri, 20 Oct 2000 11:45:25 -0700 (PDT)

Hi Vernon,

I think we agree 100% about the underlying TCP issues. I do some work on this
link layer stuff too from time-to-time too. 

Do look at this URL. It tells you what is happening in the App world. I do
believe that the phone viewed as a dumb text terminal is dead or very quickly
dying. We are back in 1983 just before the Mac hit the markets and killed off
the desktop terminal business. The big companies that did not listen are no
longer in the business. 

Change is in the air. It's super stuff:

http://www.washingtonpost.com/wp-dyn/articles/A28462-2000Oct17.html

Bill