Internet Draft J. Renkel Document: draft-renkel-moip-transport-00.txt 3Com H. Wildfeuer Cisco Systems August 2001 A. Zakrzewski Texas Instruments MoIP Reliable Transport Requirements and Evaluation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents requirements for a reliable packet network transport protocol that have been agreed to by the contributing parties, and an evaluation of some protocols against those requirements. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Abstract...........................................................2 1.0 Introduction...................................................2 1.1 Reliable Transport Reference Model.............................3 2.0 Requirements for a Reliable Transport Protocol for MoIP........4 2.1 Agreed Requirements............................................4 2.1.1 Point-to-point and Two-way................................4 2.1.2 Packet-preserving.........................................5 2.1.3 Graceful transitions to/from RTP..........................5 Renkel, et al. Informational [Page 1] MoIP Reliable Transport July 2001 Requirements and Evaluation 2.1.4 Error-detecting and error-correcting, non-corrupting, non- erasing, and non-duplicating....................................6 2.1.5 Error correction by retransmission........................7 2.1.6 Expedited delivery........................................7 2.1.7 Sequenced delivery........................................8 2.1.8 Selectively Destructive...................................8 2.1.9 Low latency...............................................9 2.1.10 Transmit bandwidth limiting.............................10 2.1.11 Bandwidth efficient.....................................10 2.1.12 Windowed flow control...................................10 2.1.13 Light-weight............................................11 2.2 Additional Requirements Under Consideration...................11 2.2.1 Instrumented.............................................11 2.2.2 Forward error correction.................................12 2.2.3 Error correction by continuous transmission..............12 2.2.4 Explicit flow control....................................13 2.2.5 Robust under congestion, congestion control, and transmit bandwidth limiting.............................................13 2.2.6 Fairness.................................................14 2.2.7 Graceful transitions to/from UDP/TL......................14 3.0 Evaluation of Protocols against the Requirements..............15 3.1 Protocol Characteristics Agreed to as Requirements............16 References........................................................17 Author's Addresses................................................17 Abstract This contribution presents requirements for a reliable packet network transport protocol that have been agreed to by the contributing parties, and an evaluation of some protocols against those requirements. 1.0 Introduction Within the development of V.moip (standard for Modem Over IP), a need has been recognized, in at least some MoIP scenarios, for a transport protocol through the IP network that meets a set of requirements as defined in this document. This contribution presents requirements for such a protocol and an evaluation of some protocols according to those requirements. Requirements and evaluations presented here may not be complete. This contribution consists of two subsequent sections: 1) The agreed to requirements and requirements under study for a suitably reliable transport protocol for MoIP; 2) An evaluation of some protocols against those requirements; Renkel, et al. Informational [Page 2] MoIP Reliable Transport July 2001 Requirements and Evaluation Within the requirements section, protocol characteristics are presented in two sub-sections as being: 1) Ones that have been identified by the contributors as requirements, i.e., requirements that a transport protocol absolutely must satisfy in order to be usable with MoIP; 2) Ones that are currently under study that have been identified as possible requirements. These possible requirements are provide for information only, and are not used for the protocol evaluation Within each requirements sub-section, each requirement or group of related requirements is presented by: 1) Zero or more definitions of terms that are used in the statement of the requirement(s), the terms being defined contained within quotations; 2) The requirement(s) and explanatory comments. The requirements statements are presented in conformance with IETF RFC 2119. In particular: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.1 Reliable Transport Reference Model While MoIP sessions are inherently two-way, point-to-point, it is convenient for the purposes here to consider a one-way, point-to- point communications model. When the requirements for this model have been identified and a protocol selected that satisfies them, the protocol can be folded or reflected back on itself to satisfy the two-way, point-to-point requirements of MoIP. Diagrammatically, the one-way, point-to-point model looks like: ---------- ---------- | | | | | | Application \| | | Source |---------------------/| Sink | | | Data Flow | | | | | | ---------- ---------- | /\ /\ | | | | | \/ | | \/ ----------- ---------- | | Reliable | | | | Transport Protocol \| | |Transmitter|---------------------/| Receiver | | |/ | | | |\---------------------| | ----------- ---------- Figure 1: One-way, point-to-point reliable transport model Renkel, et al. Informational [Page 3] MoIP Reliable Transport July 2001 Requirements and Evaluation In this model: - The source and the sink are two parts of a distributed application, in this case MoIP, that require reliable communications for their correct operation; - The transmitter and the receiver are two parts of a distributed reliable transport mechanism to be used by the distributed application; - The source and the transmitter are in one node, in this case an MoIP gateway or endpoint, of the distributed system; - The receiver and the sink are in another node, another MoIP gateway or endpoint, of the distributed system; - The application data flow is the information that must flow from the source to the sink to achieve the correct operation of the distributed application; - The reliable transport protocol is used by the transmitter and the receiver over an unreliable communications mechanism (Not show in the diagram, generally an IP-based packet network.) to achieve the reliable flow of application data needed by the application; - To transmit data to the sink, the source gives that data to the transmitter and the transmitter may provide feedback on the flow of that data; and - The data received by the receiver from the transmitter is given to the sink and the receiver may need feedback from the sink on the flow of that data. This model and components of it are referenced in the description of requirements given below. 2.0 Requirements for a Reliable Transport Protocol for MoIP 2.1 Agreed Requirements 2.1.1 Point-to-point and Two-way Definitions: A "session" is a connection through an IP-based network between two or more entities connected to the network for the purpose of transmitting data among the entities in the session through the network. A session is "point-to-point" iff (if and only if) it involves two entities. A session is "multi-point" iff it involves more than two entities. A session is "one-way" iff only one entity in the session may transmit data over the session, the data being received by all other entities. Renkel, et al. Informational [Page 4] MoIP Reliable Transport July 2001 Requirements and Evaluation A session is "two-way"" iff all entities in the session may transmit data over the session, the data being received by all other entities. Requirements: The transport protocol used with MoIP at a minimum MUST support two- way, point-to-point sessions Comments: Connections between modems through the PSTN are analogous to two- way, point-to-point sessions. One-way or multi-point sessions are beyond the scope of V.moip. 2.1.2 Packet-preserving Definitions: A transport protocol is "packet preserving" if it receives from one entity data structured as a packet consisting of one or more bytes and delivers the data to the remote entity with the packet structure preserved. Requirements: The transport protocol used with MoIP MUST be packet preserving. Comments: If the transport protocol is not packet preserving, the V.moip protocol will have to include mechanisms for the source to frame its PDUs (protocol data units) within the transport mechanism stream, so that the PDUs may be recovered by the sink. It is desirable to simplify the V.moip protocol and have the "framing" included in the transport protocol and hence provided by the transport mechanism. 2.1.3 Graceful transitions to/from RTP Definitions: A packet-preserving transport protocol is said to be able to "gracefully transition" to/from RTP iff the transport mechanism can be used within the same session of an instance of a voice call that utilizes RTP for voice. The protocols will not be required to operate simultaneously in the session at any given time during a call, but the ability to switch between the protocols in a low complexity manner is required. The straightforward ability to identify packets (differentiate them from RTP) is a desired characteristic of the protocol. Renkel, et al. Informational [Page 5] MoIP Reliable Transport July 2001 Requirements and Evaluation Note: the transitions to/from the two protocols may or may not require use of out of band signaling mechanisms. The out of band signaling mechanisms are out of the scope of this document. Requirements: The transport protocol used with MoIP MUST support graceful transitions to and from RTP based voice. Comments: MoIP must function in a packet-based network that also supports voice transport. Transitions between voice and modem transport need to happen within the same "call". RTP is a widely deployed protocol used for transport of voice through an IP based network. 2.1.4 Error-detecting and error-correcting, non-corrupting, non- erasing, and non-duplicating Definitions: A transport protocol is "error detecting" iff the receiver is capable of determining, with extremely high probability, whether or not a packet received from the transmitter is exactly the same as it was transmitted by the transmitter. A transport protocol is "error correcting" iff the receiver will by some means or another recover received packets that were determined to not be exactly the same as transmitted by the transmitter. A transport protocol is "non-corrupting" iff the data delivered to the sink by the receiver is, with extremely high probability, exactly the data given to the transmitter by the source. A transport protocol is "non-erasing" if all packets given to the transmitter by the source are delivered at least once to the sink by the receiver. A transport protocol is "non-duplicating" if all packets given to the transmitter by the source are delivered at most once to the sink by the receiver. Requirements: The transport protocol used with MoIP MUST be error correcting, non- corrupting, non-erasing, and non-duplicating; it MAY provide error detection above and beyond that assumed to be provided by the underlying IP-based packet network, but it need not. Comments: Renkel, et al. Informational [Page 6] MoIP Reliable Transport July 2001 Requirements and Evaluation Generally, the IP-based packet networks with which V.moip will be used provide sufficient error detection for MoIP’s purposes; thus the transport protocol need not provide any additional error detection. Generally, the IP-based packet networks with which V.moip will be used do not provide sufficient error correction, non- duplication, and non-erasure for MoIP’s purposes; thus the transport protocol must provide these capabilities. 2.1.5 Error correction by retransmission Definitions: A transport protocol uses "error correction by retransmission" iff blocks that are received in error or are not received are retransmitted to attempt to guarantee eventual delivery. Requirements: The transport protocol used with MoIP MUST use error correction by retransmission. Comments: Ultimately, this is the only mechanism by which very high reliability can be achieved economically. 2.1.6 Expedited delivery Definitions: Delivery of a PDU within a session is "expedited" if, at the request of the source, the PDU can be delivered as soon as possible to the sink by the receiver, irrespective of the order in which it was given to the transmitter by the source. Delivery of a PDU within a session is "normal" iff it is not expedited. Requirements: The transport protocol used with MoIP MUST support normal and expedited delivery. Comments: V.42 based modem connections via MoIP, in some scenarios, will require expedited delivery in the transport mechanism to support, e.g., V.42 expedited breaks. There does not appear to be a need for more than one level of expedited delivery, i.e., there does not appear to be a requirement for more than two priorities of delivery. Renkel, et al. Informational [Page 7] MoIP Reliable Transport July 2001 Requirements and Evaluation It is expected that MoIP sessions will request significantly more normal data to be transported than expedited data. The transport protocol/mechanism may take advantage of that in its design. 2.1.7 Sequenced delivery Definitions: A transport protocol is "sequenced" iff the order that received packets are given to the sink by the receiver is the same as the order packets are given to the transmitter by the source. Requirements: The transport protocol used with MoIP MUST support sequenced sessions; sequenced delivery MUST be maintained separately within expedited and normal data. Comments: A received will be in strict conformance with this requirement if it delivers to the sink packets received from the transmitter in the order that they were given to the transmitter by the source. Note that the sequence may not be preserved in the underlying IP-based packet network, hence the requirement on the transport protocol to recover the correct sequence. As an alternative to delivering the packets to the sink in the order they were given to the transmitter by the source, the receiver may deliver the packets to the sink out of order, but with extra information so that the sink can recover the correct order. The choice of delivering the packets to the sink in sequence, or potentially out of sequence but with extra information so that the sequence can be recovered, is an implementation issue between the receiver and the sink, and hence is outside the scope of V.moip and the reliable transport protocol. However, the reliable transport protocol MUST support and make possible sequenced or sequence- preserving delivery in the receiver. 2.1.8 Selectively Destructive Definitions: A transport protocol is "selectively destructive" iff the source can trigger the discard of data that has been given to the transmitter by the source and not delivered to the sink by the receiver. Requirements: The transport protocol used with MoIP MUST be selectively destructive. Comments: Renkel, et al. Informational [Page 8] MoIP Reliable Transport July 2001 Requirements and Evaluation Supporting some V.42 operations, such as destructive breaks, requires the transport mechanism used for MoIP to be selectively destructive. 2.1.9 Low latency Definitions: A reliable transport protocol has "low latency" iff it delivers a very high percentage of all packets within a given end-to-end time for given network conditions or impairments. Mathematically, let: "P" be a protocol; "L" be a latency; "N" be a set of network conditions or impairments consistent with a VoIP network; "p" be the probability that protocol P will deliver a packet with latency less than L under network conditions and impairments N; and "t" be a threshold for p. Then protocol P has low latency iff p>=t. Requirements: The transport protocol used with MoIP MUST have low latency. Comments: Modem connections through the PSTN are generally considered low latency with respect to the data throughputs they achieve, as compared to many sessions in packet networks with similar throughputs. Additionally, certain sequences between modems, particularly connection start-up sequences, have strict real-time requirements that must be met in MoIP sessions. Network conditions and impairments that are typically considered when determining low latency include: - the average network propagation delay including holding time in intermediate nodes; - the short-term variation (jitter) in the network propagation delay; - the long-term variation in propagation delay and jitter; - the time variant probability of a packet being lost or dropped by the network; - the time variant probability of a packet being delivered out of order; - the time variant level of congestion of the network; - congestion controls that may be imposed by the network under high levels of congestion; - transmit bandwidth limiting that may be imposed by the network; - etc. Renkel, et al. Informational [Page 9] MoIP Reliable Transport July 2001 Requirements and Evaluation 2.1.10 Transmit bandwidth limiting Definitions: A transport protocol is "transmit bandwidth limiting" iff the application that uses the transport protocol can predict a bandwidth value which will not be exceeded by the transport protocol. Requirements: The transport protocol used with MoIP MUST be transmit bandwidth limiting. Comments: An MoIP application might exist in a voice network that is based on QOS mechanisms that may require the application to use a limited amount of bandwidth. 2.1.11 Bandwidth efficient Definitions: A transport protocol is "bandwidth efficient" if the total amount of overhead (including that used for error correction) is small with respect to the amount of application data being carried. Requirements: The transport protocol used with MoIP MUST be bandwidth efficient. Comments: MoIP’s goal is the transport of modem signals over a packet network in a reliable manner. Modem signals can be transported using G.711 over RTP encoding, but will not achieve reliability due to packet loss and other network impairments. However, MoIP should not use more bandwidth to achieve that reliability than would have been used if MoIP were not used. For the MoIP application, the transport protocol may be considered "bandwidth efficient" if it can be used to transport high speed modulations (e.g. V.90) without requiring more bandwidth than used to transport these modulations using G.711 encoding over RTP. Other similar definitions may also be used. 2.1.12 Windowed flow control Definitions: Renkel, et al. Informational [Page 10] MoIP Reliable Transport July 2001 Requirements and Evaluation A transport protocol uses "windowed flow control" iff there is a limit on either the number of unacknowledged packets or the amount of unacknowledged data that have been transmitted at any given time. Requirements: The transport protocol used with MoIP MUST use windowed flow control. Comments: Without windowed flow control, a transmitter may transmit packets that the receiver will discard because, e.g., it doesn’t have a buffer in which to place them. The discarding of packets for this reason would contribute to bandwidth inefficiency. 2.1.13 Light-weight Definitions: A transport protocol is "light-weight" if, e.g., the number of PDUs defined in the protocol is small, the number of states in the state machines defining correct operation of the protocol is small, the total amount of overhead added by the protocol to the application data it is carrying is small with respect to the amount of application data being carried, etc. Note that this definition is subjective when it is applied to a single protocol, but may be made objective when comparing protocols. Requirements: The transport protocol used with MoIP MUST be light-weight. Comments: "Light-weight" attempts to capture in some sense the cost of implementing and operating the protocol. Low cost is desirable in MoIP implementations and operations. 2.2 Additional Requirements Under Consideration 2.2.1 Instrumented Definitions: A transport protocol is "instrumented" iff it includes a mechanism for the receiver to report to the transmitter conditions, statistics, etc., that are independent of any particular block to be transmitted but would be useful to the transmitter in achieving efficient reliable transport. Requirement under consideration: Renkel, et al. Informational [Page 11] MoIP Reliable Transport July 2001 Requirements and Evaluation The transport protocol used with MoIP MUST / MAY be instrumented. Comments: The specific conditions, statistics, etc., to be instrumented are TBD, but it generally accepted that instrumented protocols are or can be more efficient than uninstrumented protocols. Conditions, statistics, etc., that might be considered for instrumentation include average round-trip-delay, transit time variation or jitter, portion of transmitted packets that are lost in the underlying communications mechanism, average length of packet loss bursts, etc. 2.2.2 Forward error correction Definitions: A transport protocol employs "forward error correction" if it transmits additional data redundant to the application data it is transporting in anticipation of recovering from errors in the transmitted application data, rather than waiting for the transmission error to be detected. Requirement under consideration: The transport protocol used with MoIP MAY / MUST OPTIONALLY employ forward error correction. Comments: Forward error correction may achieve lower overall average latency than retransmission upon detection of transmission errors without using significantly more bandwidth to do so. Forward error correction cannot, in general, economically give the very high reliability required by MoIP, so the transport mechanism will have to resort to a retransmission mechanism to recover from some transmission errors. But judicious application of forward error correction can reduce the amount of retransmissions needed to a very small fraction of what would be required without forward error control, significantly reducing the overall average latency without significantly increasing required total bandwidth for a given amount of application data to be transported. 2.2.3 Error correction by continuous transmission Definitions: A transport protocol employs "error correction by continuous transmission" iff it continuously retransmits a packet until its receipt is acknowledged. Requirement under consideration: Renkel, et al. Informational [Page 12] MoIP Reliable Transport July 2001 Requirements and Evaluation The transport protocol used with MoIP MUST NOT employ error correction by continuous transmission. Comments: Error correction by continuous transmission is, in general, NOT bandwidth efficient. 2.2.4 Explicit flow control Definitions: A transport protocol employs "explicit flow control" iff it includes a mechanism that allows the receiver to request that the transmitter not transmit any new packets until requested otherwise by the receiver. Requirements under consideration: The transport protocol used with MoIP MAY employ explicit flow control. Comments: While the requirement for explicit flow control exists in the MoIP application, the requirement for explicit flow control in the reliable transport protocol is not yet determined: it may be sufficient to the application for the source to stop giving new packets to the transmitter upon request of the sink, i.e., the explicit flow control may be implemented entirely in the MoIP distributed application. 2.2.5 Robust under congestion, congestion control, and transmit bandwidth limiting Definitions: A transport protocol is "robust" under a given condition iff correct operation of the mechanism is preserved when parameters that define the condition are changed to the disadvantage of the mechanism. Requirement under consideration: The transport protocol used with MoIP MUST be robust under congestion, congestion control, and transmission rate limiting conditions. Comments: Reliable transport protocols used in IP-based packet networks must meet certain congestion control requirements (See IETF RFC 2914.). When those controls are imposed because of network congestion, the Renkel, et al. Informational [Page 13] MoIP Reliable Transport July 2001 Requirements and Evaluation transport protocol must maintain correct operation, as well as in the face of congestion itself. Similarly, sessions may be transmission rate limited in some IP- based packet networks, and the transport protocol must maintain correct operation if so limited. 2.2.6 Fairness Definitions: A transport protocol is "fair" if the congestion control mechanism of the transport protocol degrades the performance of the transport equitably among various flows that are similarly situated. Requirement under consideration: The transport protocol used with MoIP MAY be fair, but need not be. Comments: The MoIP application will be almost exclusively used in dedicated voice packet networks, not the public best-effort Internet. Because dedicated voice packet networks generally allocate dedicated bandwidth to each call, fairness is not an issue for them. 2.2.7 Graceful transitions to/from UDP/TL Definitions: A packet-preserving transport protocol is said to be able to "gracefully transition to/from" UDP/TL iff the transport mechanism can be used within the same session of an instance of a call that utilizes UDP/TL for transport of facsimile. The protocols will not be required to operate simultaneously in the session at any given time during a call, but the ability to switch between the protocols in a low complexity manner is required. The straightforward ability to identify packets (differentiate them from UDP/TL packets) is a desired characteristic of the protocol. Note: the transitions to/from the two protocols may or may not require use of out of band signaling mechanisms. The out of band signaling mechanisms are out of the scope of this document. Requirement under consideration: The transport protocol used with MoIP MAY support graceful transitions to and from UDP/TL based facsimile. Comments: Renkel, et al. Informational [Page 14] MoIP Reliable Transport July 2001 Requirements and Evaluation MoIP must function in a packet-based network that also supports facsimile transport. Transitions between facsimile and modem transport need to happen within the same "call". Facsimile can be carried as voice (over RTP) or in a demodulated form using facsimile relay. T.38 has defined two possible transport mechanisms for use with facsimile relay, UDP/TL or TCP. It is widely accepted that neither of the currently defined transport mechanisms for facsimile relay (UDP/TL and TCP) gracefully coexist with RTP given the definition of "graceful co-existence" we have in this document. It is therefore unlikely that a transport mechanism for MoIP will be able to gracefully co-exist with RTP and with UDP/TL. The procedure defining the protocol transition from RTP to the V.MOIP transport protocol and/or UDP/TL is not complete. The transition from RTP to V.moip transport protocol and vice-versa is considered the mandatory requirement and graceful transition must be provided. 3.0 Evaluation of Protocols against the Requirements Within each table, the columns give an indication of whether or not: - V.42 / MNP4 has the protocol characteristics in a circuit switched modem connection; - MoIP has that requirement for a reliable packet-switched network transport protocol; and - selected candidate protocols for use with MoIP as a reliable packet-switched network transport protocol that have these characteristics. Within each cell at the intersection of a row and column: - a "Y" indicates the row’s protocol characteristic exists in the column’s application or is satisfied by the column’s protocol; - an "N" indicates that the row’s protocol characteristic does not exist in the column’s application or is not satisfied by the column’s protocol; - a "-" indicates that the row’s protocol characteristic not relevant to the column’s application or protocol; - a "*" indicates that the row’s characteristic is currently under evaluation. Renkel, et al. Informational [Page 15] MoIP Reliable Transport July 2001 Requirements and Evaluation 3.1 Protocol Characteristics Agreed to as Requirements ---------------+-----+----+----+----+----+----+----+----+----+----+ Protocol | V.42| | | | | UDP| | RTP| RTP| | Characteristics|/MNP4|MoIP| IP | TCP| UDP| /TL| RTP| FEC| REC|SPRT| ---------------+-----+----+----+----+----+----+----+----+----+----+ Point-to-point | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Multi-point | N | - | Y | N | Y | N | Y | Y | Y | N | ---------------+-----+----+----+----+----+----+----+----+----+----+ One-way | - | - | Y | - | Y | - | Y | Y | Y | - | ---------------+-----+----+----+----+----+----+----+----+----+----+ Two-way | - | Y | Y | - | Y | - | Y | Y | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Packet- | | | | | | | | | | | Preserving | N | Y | Y | N | Y | Y | Y | Y | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Graceful | | | | | | | | | | | co-existence | | | | | | | | | | | with: | | | | | | | | | | | ---------------+-----+----+----+----+----+----+----+----+----+----+ RTP | - | Y | Y | N | Y | N | Y | Y | Y | * | ---------------+-----+----+----+----+----+----+----+----+----+----+ UDP/TL | - | N | N | N | N | Y | N | N | N | N | ---------------+-----+----+----+----+----+----+----+----+----+----+ Error detecting| Y | Y | N | Y | Y | Y | Y | Y | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Error | | | | | | | | | | | Correcting | Y | Y | N | Y | N | Y | N | N | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Error | | | | | | | | | | | correction by | | | | | | | | | | | retransmission| Y | Y | - | Y | | N | - | N | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Non-corrupting | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Non-erasing | Y | Y | N | Y | N | Y | N | N | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Non-duplicating| Y | Y | N | Y | N | Y | N | N | N | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Expedited | | | | | | | | | | | Delivery | Y | Y | N | N | N | N | N | N | N | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Sequenced | | | | | | | | | | | Delivery | Y | Y | N | Y | N | N | Y | Y | Y | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Table 1: Transport protocol characteristics agreed to as requirements Renkel, et al. Informational [Page 16] MoIP Reliable Transport July 2001 Requirements and Evaluation ---------------+-----+----+----+----+----+----+----+----+----+----+ Protocol | V.42| | | | | UDP| | RTP| RTP| | Characteristics|/MNP4|MoIP| IP | TCP| UDP| /TL| RTP| FEC| REC|SPRT| ---------------+-----+----+----+----+----+----+----+----+----+----+ Selectively | | | | | | | | | | | Destructive | Y | Y | N | N | N | N | N | N | N | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Low latency | Y | Y | Y | N | Y | Y | Y | Y | Y | * | ---------------+-----+----+----+----+----+----+----+----+----+----+ Transmit | | | | | | | | | | | bandwidth | | | | | | | | | | | limiting | Y | Y | - | Y | - | * | * | * | * | * | ---------------+-----+----+----+----+----+----+----+----+----+----+ Bandwidth | | | | | | | | | | | Efficient | Y | Y | - | N | - | N | Y | Y | Y | * | ---------------+-----+----+----+----+----+----+----+----+----+----+ Windowed flow | | | | | | | | | | | Control | Y | Y | N | Y | N | N | N | N | N | Y | ---------------+-----+----+----+----+----+----+----+----+----+----+ Light weight | Y | Y | - | * | - | Y | Y | Y | Y | * | ---------------+-----+----+----+----+----+----+----+----+----+----+ Table 1 (cont): Transport protocol characteristics agreed to as requirements References Author's Addresses Jim Renkel 3Com Phone: 1-847-342-6766 Email: James_Renkel@3com.com Herb Wildfeuer Cisco Systems 150 Castilian Drive Phone: 1-805-961-3620 Santa Barbara, CA USA Email: hwildfeu@cisco.com Adrian Zakrzewski Texas Instruments 20450 Century Blvd. Phone: 1-301-515-6636 Germantown, MD USA Email: azakrzewski@ti.com Renkel, et al. Informational [Page 17]