EMSD Efficiency

Contents

List of Figures

List of Tables

Abstract

Efficient Mail Submission & Delivery (EMSD) [1] is designed to provide SMTP-over-TCP functionality with reduced overhead via EMSD-over-UDP. Reliability is achieved using the Efficient Short Remote Operations Services 3-way handshake protocol. In this study, we compare the overhead incurred by using EMSD as compared to other Email protocols, and demonstrate EMSD’s efficiency advantage. We use a Sniffer to capture the actual packets sent and received from a User Agent (UA), and count the number of bytes in the IP layer and above. These provide a reasonable figure when the UA is sending/receiving messages over an airlink.

Preface

This article was originally published in October 1996. It is being included in the Manifesto, essentially unchanged from its original form.

1 Introduction

We provide here an overview of both SMTP and EMSD, to compare and contrast their features and to lay the groundwork for analysis of the experimental results in Sections ?? and ??.

1.0.1 SMTP

According to RFC 821[3], the objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. The SMTP design is based on the following model of communication:

As the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP, which may be either the ultimate destination or an intermediate.

Following this, the sender-SMTP sends a MAIL command indicating the sender of the mail. If the receiver-SMTP can accept mail it responds with an OK reply. The sender-SMTP then sends a RCPT command identifying a recipient of the mail. If the receiver-SMTP can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The sender-SMTP and receiver-SMTP may negotiate several recipients. When the recipients have been negotiated, the sender-SMTP sends the mail data, terminating with a special sequence. If the receiver-SMTP successfully processes the mail data it responds with an OK reply. Note that the dialog is purposely lock-step, one-at-a-time.

SMTP provides two mechanisms for the transmission of mail: directly from the sending user’s host to the receiving user’s host when the two host are connected to the same transport service, or via one or more relay SMTP-servers when the source and destination hosts are not connected to the same transport service. The mail commands and replies have a rigid syntax. Replies also have a numeric code.

Thus it can be seen that for the exchange of any one message with SMTP, a number of transactions must be completed. EMSD attempts to improve efficiency by cutting down on this number and simplifying the process for the case of short messages.

1.1 Efficient Mail Submission & Delivery

The EMSD specifications define the protocols between an EMSD Device and an EMSD Server. EMSD requires ESROS (Efficient Short - Remote Operation Services) [2]. The EMSD-P&FS consist of two independent components: Efficient Mail Submission & Delivery Protocol (EMSD-P) and EMSD Format Standards (EMSD-FS).

EMSD-FS is responsible for defining the format of a limited size interpersonal message. It defines the ”Content” encoding (Header + Body) and the end-to-end envelope. It relies on EMSD-P for the transfer of the content to its recipients.

EMSD-P is responsible for wrapping a limited size message in a point-to-point envelope and submitting or delivering it. EMSD-P performs the envelope encoding and relies on the services of ESROS for transporting the envelope. Some of the services of EMSD-P include message originator authentication and optional message segmentation and re-assembly. The Efficient Mail Submission & Delivery Protocols are designed with three high level goals:

• Define the new ”world” of Efficient Mail Submission & Delivery
• Define a remote operations service that can handle messaging and other standard networking applications
• Make Efficient Mail Submission & Delivery an extension of the existing internetworking world

These goals will prevent, whenever possible, the expense and associated problems of ”re-inventing the wheel.” The EMSD Protocols make heavy use of existing technology:

• RFC-822
• ASN.1
• Basic Encoding Rules
• X.400 and Internet e-mail

These technologies have been thoroughly tested and have proven to be reliable solutions for the problems they address (e.g. message format, reliable message delivery, encoding and compacting). The EMSD Specifications allow for users who enjoy the advantages of this new technology and at the same time want be connected to the rest of the existing messaging world.

2 Study Overview

We have chosen to compare the efficiency of using EMSD to the efficiency obtained by other submission and delivery protocols in this study. While it is debatable whether EMSD can be placed at the same level as the test protocols, we nonetheless feel that a study such as this is quite useful and provides a common denominator to discuss various aspects of EMSD performance.

The experiments cover both submission (from a mobile unit) and delivery (to a mobile unit). Under submission we looked at comparing EMSD and SMTP. The delivery experiments tested EMSD vs. SMTP, POP, and IMAP. In all cases a single uniform test message was relayed between two devices (a recipient or sender, and a mail server) and the data traffic recorded. Although you cannot compare EMSD directly to any one messaging protocol, because each protocol is designed to perform a specific function, you can compare the results obtained by each messaging solution. The following table illustrates the functions supported by each protocol. Note that EMSD is the most like SMTP.

3 Submission

Please refer to Figure 1 below, which shows the setup for the following two submission experiments in detail. The experimental setup involves:

At Site One:

• A ”sender”: Toshiba Laptop running Windows 3.1 and Chameleon Winsock TCP/IP stack from NetManage
• A ”receiver”: Sun Sparc running Solaris 2.4
• A ”mail server”: Sun Sparc running Solaris 2.4
• A sniffer that monitors packet movement at the juncture of the above three devices, recording two-way traffic

At Site Two:

• A Message Test Center: Sun Sparc running Solaris 2.4.

The two setups are linked to each other over a number of routers across the Internet.

In both cases below, we are interested exclusively in analyzing the recorded data between the sender laptop and the Unix mail server (in the case of SMTP submission), or the EMSD Message Test Center (in the case of EMSD submission). Thus the ”receiver” shown below, although necessary to submit the message, does not enter into our study picture directly.

3.1 SMTP Submission from PC to Unix

3.1.1 Message Submission Process

Message was submitted from the Laptop to the Unix mail server. To submit a message from the laptop, Netscape’s Mail User Agent on Windows 3.1 was utilized. From the file menu on Netscape, ”New Mail Message” was selected, popping up a mail window. The message was typed in, a recipient (the ”receiver” in Figure 1) was specified, and ”Send” was then clicked. The sniffer recorded the exchange of data between the sender and the mail server that was ¡nwestmail.nwest.airdata.com¿ implementing sendmail.

3.1.2 Protocol Trace

The following is the protocol trace recorded by the sniffer. After TCP synchronization and acknowledgment, a virtual circuit is established between the sender’s Netscape Mail User Agent and sendmail on the mail server, and data is exchanged after specifying the sender and recipient addresses.

3.1.3 Measurement Results

3.2 EMSD Submission from PC to Unix

3.2.1 Message Submission Process

The message was submitted from the laptop using Neda’s EMSD Mail User Agent version 0.9 on Windows 3.1, to Neda’s EMSD Message Test Center. EMSD-Pine version 3.91 was used to submit the message from the laptop. After invoking Pine, and typing ”C”, a new message was composed and then sent via ¡CTRL X¿. A direct connection was then established between the EMSD Mail User Agent on the laptop and the EMSD Message Test Center, and the message was relayed. The sniffer recorded exchange of data between the sender and Neda’s EMSD Message Test Center which was ¡emsd.neda.com¿ implementing ESROS.

3.2.2 Protocol Trace

The following is the protocol trace recorded by the sniffer. As compared to the SMTP protocol trace in section 3.1.2, you can see the exchange is quite brief.

3.2.3 Measurement Results

Total IP Packet bytes: 307

Message Length (header + body): 206

Total Overhead (EMSD header + UDP header + IP header): 101

Total IP bytes in the case of EMSD submission as compared to SMTP submission is down by a factor of 6; the header count is down by a factor of 2.6; and total overhead is down by a factor of 14, representing major savings in data traffic.

3.2.4 Message as Received

The # text below is provided as comments and does not appear in the received message.

4 Delivery

Similar to the submission experiments above, we also conducted analogous delivery tests. The first experiment on SMTP delivery is essentially the complement of the SMTP submission experiment described above, and uses the same setup as in Figure 1. The second and third delivery experiments are with POP and IMAP servers and are described in their corresponding sections below. The final experiment is on EMSD delivery and also uses the same setup as in Figure 1. We then compare the performance of EMSD delivery versus the other three delivery methods.

4.1 SMTP Delivery from Unix to Unix

Please refer to Figure 1 above for this experiment.

4.1.1 Message Delivery Process

The message was delivered to the Unix receiver from the Unix mail server. Both were implementing sendmail and the message was delivered via standard SMTP. The sniffer recorded the exchange of data between the recipient and the mail server, which was ¡nwestmail.nwest.airdata.com¿.

4.1.2 Protocol Trace

The following is the protocol trace recorded by the sniffer. After TCP synchronization and acknowledgment, a virtual circuit is established between the recipient’s Mail User Agent and sendmail on the mail server, and data is exchanged after specifying the sender and recipient addresses.

4.1.3 Measurement Results

Total IP Packet bytes: 1778

Message Length (header + body): 301

Total Overhead (TCP header + IP header): 1477

4.1.4 Message as Received

4.2 Message Delivery via POP Mailbox

Please refer to Figure 2 below, which shows the setup for the following two delivery experiments in detail. The experimental setup at Neda Communications involves the following:

• A POP Server: Sun Sparc running Solaris 2.4.
• An IMAP Server: Sun Sparc running Solaris 2.4.
• A ”receiver”: IBM Thinkpad Laptop running Microsoft TCP/IP on Windows 95
• A sniffer that monitors packet movement at the juncture of the above three devices, recording two-way traffic

4.2.1 Message Delivery Process

The message was delivered to the laptop from the POP server. After invoking Microsoft’s Internet Explorer 3.0 on the laptop and bringing up MS Internet Mail, the new message was automatically retrieved from the POP server. The sniffer recorded traffic data between the POP server and the recipient.

4.2.2 Protocol Trace

4.2.3 Measurement Results

Total IP Packet bytes: 2731

Message Length (header+body): 561

Total Overhead: 2170

4.2.4 Message as Received

4.3 Message Delivery via IMAP Mailbox

Please refer to Figure 2 above for the experimental setup.

4.3.1 Message Delivery Process

Message was delivered to the laptop from the IMAP server. After invoking PC-Pine, the new message was automatically retrieved from the IMAP server. The sniffer recorded traffic data between the IMAP server and the recipient.

4.3.2 Protocol Trace

4.3.3 Measurement Results

Total IP Packet bytes: 3593

Message Length (header+body): 833

Total Overhead: 2760

4.3.4 Message as Received

4.4 EMSD Delivery from Unix to PC

Please refer to Figure 2 above for this experiment.

4.4.1 Message Delivery Process

The message was delivered to the laptop, running Neda’s EMSD Mail User Agent version 0.9 on Windows 3.1, from Neda’s EMSD Message Test Center. The sniffer recorded exchange of data between the recipient and Neda’s EMSD Message Test Center which was ¡emsd.neda.com¿ implementing ESROS.

4.4.2 Protocol Trace

4.4.3 Measurement Results

Total IP Packet bytes: 387

Message Length (header+body): 299

Total Overhead: 88

Comparing EMSD delivery with SMTP delivery we see that total IP packets in the case of EMSD delivery is down by a factor of 4.6, and total overhead is down by a factor of 16.8.

In the case of POP retrieval, total IP bytes in the case of EMSD delivery is down by a factor of 7, and total overhead is down by a factor of 24.7.

Finally for IMAP delivery, total IP packets in the case of EMSD delivery is down by a factor of 9.3, and total overhead is down by a factor of 31.4.

4.4.4 Message as Received and Decoded

5 Results Summary

The following paragraphs summarize the results obtained above. Results indicate that EMSD compares very favorably to other message transfer mechanisms.

6 Conclusion

Results of the experiments show the dramatic efficiency gain of EMSD over all the other protocols under test.

However, it should be noted that EMSD was specifically designed for efficient short messaging in the context of mobile wireless devices, and thus from inception was meant to be more efficient than protocols designed to handle a wider variety of messages. Deployment and use of EMSD similarly is geared towards messaging scenarios that are a subset of the current global messaging world, such as palmtop devices exchanging messages over an airlink. At the other extreme, in a traditional office environment, concerns like efficient use of communications infrastructure and maximizing the battery life of the devices do not necessarily apply to tethered devices plugged to a standard wall outlet and a high speed (non-air) networking infrastructure.

Within its own domain, EMSD does its job efficiently and admirably and as is clear from the results of this study, is a highly competitive alternative to other messaging protocols.

7 Acknowledgments

This study was performed with the support and assistance of AT&T Wireless Services.

8 Appendix: DLC, IP, TCP, UDP Headers

References