From: Mohsen BANAN-Public
<public(_at_)mohsen(_dot_)banan(_dot_)1(_dot_)byname(_dot_)net>
...
There is a genuine need for a reliable efficient transport that
accommodates *short* and *occasional* exchanges.
There are many occasions where UDP is too little and TCP is too much.
I've often heard that from telephant advocates, but I've never seen
anything plausible from them. It's not that I can't believe it, since
I'm currenting coding something that needs more than UDP and less than
TCP, and that involves short and often only occassional exchanges. Such
applications have been common in the IP world for decades. The problem
is that the new wireless folks talk only about ridiculous applications
such as WWW browsing using screens with 60x80 pixels were each pixel is
one whole dark grey vs. light grey bit.
IETF/IESG/IAB folks keep saying TCP is good enough for everything.
You're not listening or you're listening to the wrong I* folks. No
one with a clue says TCP is good enough for everything or even that
TCP and UDP are good enough for everything. Perhaps your complaint
is that acknowledging the limits of TCP doesn't confer automatic
support for the latest consortium braincloud.
Maybe you could get sympathy from the former ATM advocates here, who
in the early 1990's told us that IP was obsolete and would soon be
replaced by ATM to the desktop. Or the ISO-OSI advocates of the mid- and
late 1980s. Both groups had a lot of telephant employees and suppliers.
And they interfere with the work of others addressing the efficient
applications domain.
And how do they interfere with anything except foolish advertising
and advocacy that is obviously contrary to reality?
I've argued forceful elsewhere against the religion that says that the
ends of the IP path must be defined as the webphones. There is just as
much silliness as WAP in trying to make HTTP/TCP/IP run on the last 1000
bit/sec, 1E5 BER wireless 500 meters to 1 MHz computers with 1000 pixel
screens. WAP is based on the right insight given those bogus limits, but
amazingly backwards. It's as if the telephants are afraid of the obvious
solution, which involves them running real computers and treating webphones
as semi-dumb terminals.
...
Efficient application protocols is a new topic for most. Go to your
favorite RFC repository and search for "efficient" in the title field.
See what you get. We are now moving beyond "Simple Protocols," and
"Efficient Protocols" are in big demand.
That's more of an observation about the evolution of standards outfits
than the current market, computers, or anything else. The later works of
committees are always at best bigger and usually much worse than merely
bigger. It becomes silly even to insiders to claim their efforts are
"simple." "Efficient" is more nebulous. Thus the great protocol disasters
have all been paragons of efficiency. Consider the ISO OSI suite and FDDI.
...
While the right implementations of TCP are just fine for transfer of
larger pieces of information in most (if not all) wireless
environments, transfer of occasional short messages is a different
matter.
Yes, TCP is not always the right solution. This is has not been news to
anyone with any sense for more than 20 years. Can't you name several
familiar applications that fit your profile? Isn't DNS about the "transfer
of occasional short messages?" Other old examples include PPP (LCP),
NTP, NNTP (for reading not feeds), and many RPC applications including
YP/NIS.
...
In order to do anything beter than 5 PDU exchanges we need something
other than TCP. The combination of ESRO and EMSD can do the job in 3 PDU
exchanges most of the time. EMSD (Efficient Mail Submission and
Delivery) has been published as RFC-2524. More information on the
above example is available at http://www.emsd.org/
I disagree with your packet counts, but never mind. You're solving the
60x80x1 resolution webphone problem of the 20th Century, and no one with
any sense cares. (And no one notices that you're solving it with protocols
you say are "efficient" instead of "simple," have amazingly long
descriptions, and packet formats with lots of "unused" bits.)
When webphones have enough screen real estate to be usable, they'll need
enough raw bandwidth to paint their Mpixel displays, and then you're in
the familiar regime of Internet of 1995 - 2005, and you don't want WAP.
On the other hand, if webphones never have more than several 100 monochrome
pixels, they'll never be used for anything useful to more than a handful
of people, and you still don't want WAP.
Talk a walk on the wild side, and see what the general public says about
the new webphones with their uselessly tiny screens. Do some engineering
to estimate the minimum required resolution, or just look at the
"palm-top"products that have been mentioned here.
But who cares? You're not going to convince me to run out and get a
lobotomy. And if you did, so what. As I said before, WAP will fail on
its on merits.
Furthermore, one can not afford 9 bytes to encode "Subject: " in wide
area wireless environments. Those days are over.
...
but you can afford to encode advertising in those same wide area wireless
environments?--sheesh!
Can you really not imagine any sort of UDP or TCP payload compression?
Do you really not see the cost of "Subject: " for 1200-9600 bit/sec modem
links, which is to say why PPP CCP has existed for most of 10 years and
why v.42bis has existed for a lot longer?
Why is it that the ads I see for future webphones talk about links 8 times
fatter than the Internet *backbone* of a few years ago? Why is it that
advertisement and reports of current webphones talk about 14 kbit/sec?
Why do you seem to think that 14 kbit/sec is a lot less than the 1200-9600
bit/sec of the not so distant Internet past?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com