Re: Mobile Multimedia Messaging Service
Patrik, Thank you for your reply: ... guidelines for TCP operation during indefinite wireless link downtime I think this must be syncronized with the work of the PILC wg. See http://www.ietf.org/html.charters/pilc-charter.html Yes, the next document milestone from PLIC seems to have been delayed: Done Draft on asymmetric network paths. Oct 99 Draft of TCP Over Wireless document to the IESG as BCP Nov 99 Document on low bandwidth links to IESG for publication as BCP. Does anyone know who is supposed to be working on the PLIC Wireless document? The closest I could find was: http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/index.html Cheers, James
The LEAP Manifesto -- Executive Summary
The Lightweight Efficient Application Protocol (LEAP) Manifesto Shaping the Future of Mobile Wireless Applications Industry A Call to Action EXECUTIVE SUMMARY Mohsen Banan [EMAIL PROTECTED] Version 0.5 July 17, 2000 Copyright (c)2000 Mohsen Banan. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Contents 1 Executive Summary 1.1 Technological Scope 1.2 Efficiency is the Key Requirement 1.3 Conventional Origins of Protocols 1.4 Expect the Unexpected 1.5 Our Solution 1.6 A Brief History of LEAP 1.7 Making Our Solution Widespread 1.8 Complete and Ready 1.9 Getting the Complete Manifesto 1 Executive Summary Until now, the Internet has been largely based upon simple protocols. However, the era of simple protocols is now over. The new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality places an entirely new set of requirements on the underlying communications protocols: they must now provide the power efficiency demanded by hand-held wireless devices, together with the bandwidth efficiency demanded by wide area wireless networks. It is now time for a new generation of protocols to be implemented, designed to address the need for performance, rather than simplicity. The industry-wide adoption of this new generation of powerful and efficient protocols will have enormous consequences. Protocols addressing the correct requirements will become the lynchpin of a huge new industry. The stakes are enormous, and ferocious competition is to be expected within all segments of the industry. All manner of wild claims and misrepresentations are also to be expected. At the time of writing, the main claimant to the protocol throne is the Wireless Applications Protocol, or WAP. However, WAP will eventually prove to be entirely inadequate to the role being claimed for it. We have designed a set of protocols, the Lightweight Efficient Application Protocols, or LEAP, which we believe is destined to displace WAP and become the de facto industry standard. These protocols, published as Internet RFC 2524 and RFC 2188, are designed to address all the technical requirements of the industry, and are oriented towards providing the greatest benefit to the industry and the consumer. This manifesto is about our vision of the future of the Mobile and Wireless Applications Industry. In the remainder of the manifesto we present the details of our vision, and we justify our claims. We justify our assertion that the industry needs a new generation of protocols, we explain why our protocols fulfil this need, and we describe how and why these protocols will achieve dominance. The protocols are free, open and in place. Open-source software implementations of the protocols are being made available for all major platforms. The combination of free protocols and open-source software ensures acceptance of the protocols in the Internet mainstream. There can be no stopping this. 1.1 Technological Scope Most of our discussion throughout this Manifesto is framed in terms of a particular technology, namely, Mobile Messaging. It is important to bear in mind, however, that Mobile Messaging is just one aspect of a broader technology: Mobile Consumer Data Communications. Mobile Consumer Data Communications refers to the general ability of an end-user to send and receive digital data at a hand-held device via a wireless network. This technology includes Mobile Messaging as a special case, but also includes other wireless data transfer capabilities such as general Internet access, web browsing, etc. Much of the discussion set forth in this Manifesto applies with equal force to all mobile data communications applications, not just that of messaging. However, it is currently well understood that the dominant application for mobile data communications is, in fact, Mobile Messaging, not web browsing or other Internet applications. Therefore throughout this Manifesto we will focus our attention on the messaging application. Though our discussion will be framed in terms of Mobile Messaging, the reader should bear in mind that the same principles apply to all forms of mobile data communications. 1.2 Efficiency is the Key Requirement -- Engineering is the art of making intelligent trade-offs between conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power
Multimedia EMSD? (was Re: Mobile Multimedia Messaging Service)
Mohsen, Thank you for your message: A large body of work exists which addresses the Mobile Messaging area LEAP: Lightweight and Efficient Application Protocol. ... Those who want to build good things and move forward fast, can evaluate the merits of LEAP and participate in its evolution and enhancement. The starting point URL is: http://www.leapforum.org/ Would you confirm, please, that the LEAP Efficient Mail Submission and Delivery protocol (EMSD) is capable of MIME messages with multimedia content? I am concerned that the string "multipart" does not appear on: http://www.emsd.org/dataCom/emsd/emsdRfcs/emsdp-rfc/split/node10.html Cheers, James
RE: Multimedia EMSD? (was Re: Mobile Multimedia Messaging Service)
Hi, We don't need yet-another mail delivery protocol by some new forum. We have already e.g. SIP which is capable of carrying MIME messages, including multipart and which supports capability negotiation. -- Petri -Original Message- From: EXT James P. Salsman [mailto:[EMAIL PROTECTED]] Sent: 18. September 2000 11:55 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Multimedia EMSD? (was Re: Mobile Multimedia Messaging Service) Mohsen, Thank you for your message: A large body of work exists which addresses the Mobile Messaging area LEAP: Lightweight and Efficient Application Protocol. ... Those who want to build good things and move forward fast, can evaluate the merits of LEAP and participate in its evolution and enhancement. The starting point URL is: http://www.leapforum.org/ Would you confirm, please, that the LEAP Efficient Mail Submission and Delivery protocol (EMSD) is capable of MIME messages with multimedia content? I am concerned that the string "multipart" does not appear on: http://www.emsd.org/dataCom/emsd/emsdRfcs/emsdp-rfc/split/node10.html Cheers, James
Re: Multimedia EMSD? (was Re: Mobile Multimedia Messaging Service)
On Mon, 18 Sep 2000 01:55:21 -0700 (PDT), "James P. Salsman" [EMAIL PROTECTED] said: Those who want to build good things and move forward fast, can evaluate the merits of LEAP and participate in its evolution and enhancement. The starting point URL is: http://www.leapforum.org/ James Would you confirm, please, that the LEAP Efficient Mail Submission and James Delivery protocol (EMSD) is capable of MIME messages with multimedia James content? Confirmed. Please see sections 6.2.1 and 6.2.2 of RFC-2524, pages (58-62). James I am concerned that the string "multipart" does not appear on: James http://www.emsd.org/dataCom/emsd/emsdRfcs/emsdp-rfc/split/node10.html "multipart" as a string, is a value. Structure of the Body is through MIME. ...Mohsen.
Re: pilc minutes for IETF 48
Here are some questions about the plic minutes: http://pilc.grc.nasa.gov/pilc/list/archive/0967.html TCP over Wireless draft. The working group charter specifies that PILC will produce a 'TCP over Wireless' RFC that is a meta list of the existing PILC recommendations. This was reported in Adelaide as being completed in October 1999 because Aaron had confused it with the LTN draft. Actually, it requires some work. Gabe Montenegro has volunteered to sync up with the WAP forum to see if we can build this document on a work in progress that already exists in that body. The document should be only 3 or 4 pages long and should go to wg last call by January 2001. Gabe noted that there is currently no buy in by the WAP forum as yet, he will attend a forum meeting in September and try to resolve. Several members of WAP were in the room and volunteered to assist if needed. Is this WAP "work in progress" available for public inspection and review? If not, would someone who can see it please abstract it and post (anonymously if need be) please? Does any WAP product use TCP at all? Discussion on DoCoMo draft (draft-inamura-docomo-00.txt) http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt Aaron noted that DoCoMo would like to publish this as informational RFC, but we don't want to get in a mode of publishing RFCs each time someone does this and requested input from the group. I would certainly support doing anything that would encourage DoCoMo to use end-to-end Internet protocols, and if they are as close as that draft suggests, publishing it as an Information RFC might help them provide TCP application services more easily. A speaker noted that the recommendations are pretty generic and suggested the working group use this as a starting point for the TCP over wireless document, or as an appendix to this document. Aaron suggested it might be necessary to take the simulation results out in order to use this document for the TCP over wireless document. Another speaker suggested using path MTU discovery instead of fixing it at 1500. Question: Maybe your tcp stack in the Opnet simulator is not the best TCP. Have you run this on real stacks, rather than on a simulator. Imaura - yes they have, but no published results. Aaron noted that another alternative was that the DoCoMo would be sent forth as informational, and would not be a recommendation. Tim Shepard asked why would one want to disseminate this information? Doesn't seem to make sense to have multiples of TCP/some link technology. Is this advice on how to tune TCP for the handset? Response from author: yes. Comment: This shows that tcp stack works over wireless error prone links. Comment: Doesn't think these results are any different from what a modern TCP stack does anyway. I think the TCP parameters and resulting behavior might be more different than typical TCP stacks than whoever made that comment might think. There seems to be a lack of understanding about the parameters involved, and most if not all of the important ones are at least touched on in the DoCoMo I-D and the documents it cites. Gabe: This is similar to what was done in ecn document What is the ecn document? Question: What bandwidth was used in the simulations? Imaura: 384kbs Comment: Doesn't think this is realistic, since this is only the rate if you are the only one in the cell. WAP is designed to use slower links. WAP is designed as if Moore's Law didn't exist. Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) http://search.ietf.org/internet-drafts/draft-magret-pilc-lltcp-00.txt Comment: this is probably not a good idea -- leads to ICMP flooding. Is there any evidence to back this comment up? It seems that ICMP traffic is specifically addressed by Magret and Yang. Also, if there is a long outage you do want to go through slow start again, because the network has changed. There are better link level solutions to this problem. Like what? Thanks. Cheers, James
Re: Mobile Multimedia Messaging Service
These documents would become de facto standards (although they won't have had the standards-review) and they would break the paradigm of Internet-Drafts (which is "don't implement"). May I respectfully resubmit "don't implement" as: "Please understand that any experience you gain implementing this draft will be a valuable input to the standards process and that your and others input may cause the protocol to change substantially before it becomes a standard" or, more succicently, "Don't whine when this changes". regards, Ted
Re: Mobile Multimedia Messaging Service
Mohsen BANAN-Public wrote: Remember the web (http, ...)? What was IETF's role in Internet's main modern application? You mean aside from MIME? -- Eliot Lear [EMAIL PROTECTED]
Re: Mobile Multimedia Messaging Service
Mohsen; James (1) End-to-End Internet Services for Mobile Devices James Scope: Specifications and interoperability guidelines for James end-to-end mobile IP connection and transport services required James for support of standard Internet messaging ... The beauty of the Internet End-to-End model is that people don't have to wait for the IETF to create a working group, a charter, a chair, , blessings, to move forward. Yes, in this case, people are using different URLs already. It is solved at the so far end of communication that it works even with iMODE or WAP without the Internet end-to-end model. What was IETF's role in Internet's main modern application? The role is to delay IANA resigtration trying to keep influential power on application protocols but resulting only to make IANA registration less important. As far as the domain of Internet services for mobile devices go, the key issue is "Efficiency". No. It is wrong to assume that bandwidth for mobile devices is limited forever. Simplicity is the key issue. Masataka Ohta
Re: pilc minutes for IETF 48
Reiner, Thanks for your reply: ... There seems to be a lack of understanding about the parameters involved, and most if not all of the important ones are at least touched on in the DoCoMo I-D and the documents it cites. You need to be more precise. Which parameters are you talking about? These from http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt FeatureParameter/Recommendation RFC/Status --- MTU size 1500B N/A Window size 64KB RFC 793 Standard Initial window2 mss RFC 2581 Proposed Standard Initial windowup to 4380BRFC 2414 Experimental Use of SACK Recommend RFC 2018 Proposed Standard So, given the ECN-like properties of Radio Link Control -- 3G TS 25.322; which also seems to be incorporated in current versions of GSM -- http://webapp.etsi.org/action/OP/OP2929/en_301349v080400o.pdf -- is there really any need to add explicit link condition adaptation at the TCP or ICMP protocol levels? I don't want to be in a position of advocating the change or addition of anything to those protocols unless absolutely necessary. As far as robust wireless TCP goes, you are absolutely right that good service requires a maximum RTO shorter than the standard 64 seconds. What is that value in your TCP-Eiffel? And one parameter that the DoCoMo draft doesn't mention (perhaps it goes without saying to most people) is a total retransmit timeout much longer than the typical 2-9 minutes. Again, what do you use; an hour? Cheers, James P.S. Please keep at least [EMAIL PROTECTED] in on this, as the lack of ubiquitous wireless TCP is related to Mobile Multimedia Messaging applications.
