Subject: Re: pilc minutes for IETF 48

From: Vernon Schryver <[email-masked]>
Date: Sun, 15 Oct 2000 16:44:27 -0600 (MDT)

> From: [email-masked]

> ...
> However, I'd like to point out one thing that Mr. Schryver and
> many Americans fail to recognize because they may not be witnessing
> the explosive growth and the convenience of sending short alpha-
> numeric messages (SMS).

From my prospective, it's not the "explosive growth of short messages,"
but the "return of short messages."  In the old days (staring in the 1960's
when I first used email), messages were what you could type in a few
seconds on a 10 char/sec model 35 or 33 TTY or 5 char/sec Flexowriter, and
did not have zillions of headers (such as X-Face for pity's sake!), not
to mention MBytes of spread sheets and pictures, fonts, cryptographic
signatures, and complete duplicates of the whole message expanded by
30-100% and encrypted in HTML.  Maybe I'm overstating things a little.
Informal email (i.e.  not to public mailing lists or netnews) was less than
500 but more than 100 bytes.

>                         The lesson is: many applications needn't be 
> interactive  ...

I guess I wasn't clear when I tried to say that 4X MSS worth of buffering
in radio base stations for short text messages that consist of far less
than one MSS is silly.

> But email, to cite one example, is NOT interactive. It's only so
> when you log on through your home phone line. But a cellular phone is
> not quite an ordinary phone. It is also a small computer and it's
> always connected (namely through the cellular control channels).
> Therefore, the idea is to deliver email directly to the mobile in
> which case latency is simply not an issue.

Yes, but "email" is not the really the issue either.  Do those "state of
the art" GSM phones with > 1700 ms of latency also have enough memory to
hold enough bits of email to worry about? Do they have even as much as 4X
MSS=6KBytes?
Are their screens big enough to allow you to read a message longer than
100 bytes?  Your message contained 1893 bytes of text.  Could you have
typed it on a cell phone keypad?  Could you have reviewed it for spelling
and grammar on a cell phone screen?  I couldn't.
Thus, whatever phone text messaging is, it's not modern email.

There are people with lots of real experience with the ultra-short text
messages (50X to 50,000X smaller than 21st Century SMTP) that seem to be
what the GSM and third generation phone people are talking about.  Instead
of using bulk transfer protocols such as TCP/IP, why not look at what the
pager people have been doing for decades?

>                                            Taking another example:
> ordering something doesn't necessarily require an immediate feedback 
> across the network, either.

No, if your order is not instantly acknowledged and you are like most
consumers, you will be very unhappy, will complain, and will try to cancel
or repeat the order.  And never mind how you were able to do the very
interactive job of getting enough information to place your order (e.g.
bus schedule or take-out restaurant menu) over a 1700 ms RTT link without
giving up in frustration.

> Finally, don't forget that a cellular phone is already equipped for
> interactive applications when the need arises: just use the voice 
> channel. Now, I'm not a firm believer in voice browsing in light of 
> all the time I've wasted in recorded-voice menu trees, but I do
> think the user experience could be made much more productive than
> what is commonplace now. And then there are call centers, of course.

That's very true, and it says volumes about the utility and wisdom of
worrying about how many MSS of buffer to put in base stations to make
HTTP/SMTP/TCP/IP work over links with 1700 ms latency.

> With all this, I am not saying you should not minimise delay and I am
> not saying that interactive applications are not important. All I am
> saying is that you shouldn't completely dismiss TCP for systems and 
> links where you can't meet the 500ms response time requirement. There
> may be uses even for that.

As I've repeatedly said, TCP was and even still is used on links with >500
ms latency.  It's just that 500 ms doesn't work for interactive
applications, and essentially all of the proposed uses of IP-to-GSM uses
are interactive, because those "state of the art" phones don't have enough
storage to do anything else.  Almost all of their storage is in the brain
of the user, which is another way of saying the proposed applications are
interactive.

The possible exception is email, but the keyboard, storage, and screen
real estate of phones means that phone-email is something very different
from what we are using here.  Who would want to read any of the messages
in this list on a cell phone's screen?  Who could have prepared even a
fragment of one on a cell phone?

Vernon Schryver    [email-masked]

---

From: Bill Yeager <[email-masked]>
Date: Mon, 16 Oct 2000 16:38:57 -0700 (PDT)

| The possible exception is email, but the keyboard, storage, and screen
| real estate of phones means that phone-email is something very different
| from what we are using here.  Who would want to read any of the messages
| in this list on a cell phone's screen?  Who could have prepared even a
| fragment of one on a cell phone?

Exactly the point. Most of those email users who use cell phones will send
very short messages to one another. And, when the messages are not short, ie,
not sent from a cell phone, then any smart email client using IMAP for example
will take advantage of the fetch partial commands and page email messages to
telephones in say, 256 byte chunks.

The above is not a fantasy. It works quite well even with HTTP proxy to a
(shall I dare say) WAP gateway. I did such a product to understand WAP and
wireless, and right, it convinced me that WAP MUST converge to the IETF
standards on the one hand, but that the email service was quite good on the
other hand. The same can be say wrt to calendar access.

We are not talking ftp here or even 4xMSS worth of data. I've used HTTP with
HandWeb on my Palm Pilot talking to a proxy [http <--> imap/smtp/ldap] using
servlets to output compact HTML on the CDPD network here in the bay area. I
could hold a WAP enable telephone in the other hand talking to the same proxy
that was also WML or HDML enabled. Equal performance because the application
was tailored to the device. App designers must be aware of the platform.

This same code has been running over GSM networks in Europe. It works well
because it was designed with the target device in mind. 

So, for example, one can provide the phone with a list of pre-defined
responses that can be set up on the phone or with a web interface. One finger
responses. Make short cuts, take advantage of the smarts in protocols like
IMAP for managing low-bandwidth high latency and noisy connections. 

USE TCP/IP end-2-end!!! That is what moves our industry forward. It is a
unifying force. 

Right, I've been involved in networking since the 60's too. DSN at Nasa-AMES
for the pioneer spacecrafts. Kermit was based on my code (ttyftp which I wrote
at Stanford in the late 70's) and the cisco routers were initially licensed
from Stanford as a derivative of my work, the Sumex-aim etherTip/router code.

And remember, real apps will soon be arriving to the phone. Smart apps. They
will initially require HTTP/TCP/IP end-2-end and soon after use protocols like
IMAP and SMTP. They will be light weight wrt to data use. And, they will use
SSL/TLS for security end-2-end. They will tolerate 2 seconds of RTT, and still
give a great user experience. THAT is cool, very cool.

Finally remember, WAP 2.0 is TCP/IP + basic XHTML + (I'm betting on SSL/TLS
when implemented). There will be required legacy support for WML. But, I'm
again betting on proxy rather than phone resident WML browers for a great deal
of the content.

All of the work in pilc has inspired this. Great arguments! Great results.

Thanks a lot,

Bill