ietf
[Top] [All Lists]

RE: WAP and IP

2000-06-23 17:40:02

On Thu, 22 Jun 2000 17:10:16 -0600 (MDT), Vernon Schryver 
<vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> said:

  >> From: Harald Tveit Alvestrand <Harald(_at_)Alvestrand(_dot_)no>
  >> ...
  >> >Add to
  >> >that even if there was enough bandwidth, small screen's on some of the
  >> >today's devices can't meaningfully display all contents of modern web
  >> >sites.
  >> 
  >> Neither can Lynx, a popular text-mode browser.
  >> 
  >> The fact is that the Internet was developed *in* and *for* the bandwidth 
  >> and display capabilities that WAP currently is claiming to be designed for.
  >> It just scaled well.

  Vernon> That bears repeating, although few of the WAP enthusiasts and other
  Vernon> advocates of fix TCP for QOS and modern radio telephone links will 
hear.

Perhaps the I* (IESG/IAB...) folks suffer from a similar hearing
problem.

Please listen:
 
 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.


IETF/IESG/IAB folks keep saying TCP is good enough for everything.
And they interfere with the work of others addressing the efficient
applications domain.
        
RFC-2188 (Efficient Short Remote Operations) is one solution to this
problem space.  http://www.esro.org/ deals with this topic in detail.

Much of the design rationale and trade-offs made in the design of ESRO
may not be obvious to those who are not willing to dig deep enough.
Those who want to discuss or challenge the ESRO design can join the
esro-spec mailing list by sending a message to
mailto:esro-spec-subscribe(_at_)lists(_dot_)esro(_dot_)org

ESRO addresses the same problem space as WTP. It may be worthwhile
mentioning that WAP's WTP appears to be related to previous work
that was published as LSROS (Limited Size Remote Operations) by the
CDPD Forum in 1995. I personally participated actively in the
development of LSROS.

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.

Much work has already been done on this front and there is no need for
the IETF/IESG/IAB to re-invent things just because the source of the
work is not under their control.

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.

In order to make some of this to fall into place, let me offer a
concrete example. Let's consider the problem space of Mobile Messaging
over wireless IP networks. Let's try to submit and deliver 10 short
but important email messages per day over a wide area wireless
network. This in fact is a very real problem.

Given the existing SMTP/IMAP/TCP technology the best you can do is a
minimum of 9 PDU exchanges per submission/delivery. Not very good at
all. The next step is what Dan J. Bernstein has done with QMTP and QMQP
which gets to a minimum of 5 PDU exchanges. That is as good as it
gets when using TCP. So why has QMTP... not been published as
an RFC? I understand Dan Bernstein did submit it for publication.

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/

In wide area wireless environments, where capacity is always limited and
precious, these 9-to-3 or 5-to-3 factors are significant enough to justify
something other than TCP for short and occasional exchanges.

Furthermore, one can not afford 9 bytes to encode "Subject: " in wide
area wireless environments. Those days are over.

Those who want to understand how EMSD and ESRO deal with congestion
control, flow control, scalability, and so on, should join the above
mentioned relevant mailing lists.


  Vernon> Still, all of this talk about WAP is irrelevant on the main IETF list.

I have always considered ietf(_at_)ietf(_dot_)org as a public forum of the
Internet technical community. Any consideration other than that is
likely to push things more in the "cult" direction.

Without anybody's interference the discussions of the past few days
have been evolving from WAP into a perfectly valid and legitimate
topic of obvious general interest to the Internet technical community.
That topic is Efficient Application Protocols.

  Vernon> The IETF is to WAP as the ISO or ITU is to TCP, or if you prefer, as
  Vernon> the IETF was to TP4.  Only moribund standards organizations have the
  Vernon> time and energy to spare for critiques of the fun and games in other
  Vernon> standards outfits and industry consortia.  WAP will fail on its own
  Vernon> merits and without the let, leave, or hindrance of the IETF.

Agreed.

The question is what will replace WAP, and what role can we play in
shaping the right replacement?

Will IETF/IESG/IAB play a significant role in shaping the future of
Efficient Application Protocols?

Is it unreasonable to say that in the area of Efficient Protocols
IETF/IESG/IAB is currently inexperienced and has little to offer?

Is it unreasonable to suppose that innovation and rapid progress on this
front might come from outside the IETF/IESG/IAB? After all, this is
what happened with the Web, PGP and many others.

We have put in place a framework where others who are interested in
working on a set of protocols which: 

  - have been published as Internet RFCs
  - conform full to the FPF patent-free principles
  - are maintained by open public working groups

The umbrella name for these protocols is:

  "Lightweight & Efficient Application Protocols (LEAP)"

The general interest forum for the protocols is:

    http://www.leapforum.org/


This work open. It is free. 
And it is taking place outside the IETF/IESG/IAB.


...Mohsen.




<Prev in Thread] Current Thread [Next in Thread>