Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Airborne Networking wikipedia , lookup
TCP congestion control wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Deep packet inspection wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Telecommunications Industry Association (TIA) TR-30.1/01-07-051 Baltimore, MD, 16-20 July, 2001 COMMITTEE CONTRIBUTION Technical Committee TR30 Meeting SOURCE: The 3Com Corp. Cisco Systems, Inc. Texas Instruments TITLE: MoIP Reliable Transport Requirements and Evaluation DISTRIBUTION: Meeting attendees CONTACT: Jim Renkel (3Com) Voice: +1.847.342.6766 Fax: +1.847.342.6785 E-mail: [email protected] Herb Wildfeuer (Cisco Systems) Voice: +1.805.961.3620 E-mail: [email protected] Adrian Zakrzewski (Texas Instruments) Voice: +1.301.515.6636 E-mail: [email protected] ________________________________ 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. Copyright Statement The contributors grant a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text contained in this contribution and any modifications thereof in the creation of a TIA standards publication, to copyright in TIA's name any standards publication even though it may include portions of this contribution, and at TIA's sole discretion to permit others to reproduce in whole or in part the resulting TIA standards publication. Intellectual Property Statement The individuals preparing this contribution know of patents, the use of which may be essential to a standard resulting in whole or in part from this contribution. Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 Table of Contents 1 Introduction ...........................................................................................................................................................3 1.1 Reliable Transport Reference Model .............................................................................................................4 2 Requirements for a Reliable Transport Protocol for MoIP ....................................................................................5 2.1 Requirements Agreed to as Primary Requirements .......................................................................................5 2.1.1 Point-to-point and Two-way ......................................................................................................................5 2.1.2 Packet-based ..............................................................................................................................................5 2.1.3 Graceful co-existence with RTP and UDP/TL ..........................................................................................6 2.1.4 Error-detecting and error-correcting, non-corrupting, non-erasing, and non-duplicating ..........................7 2.1.5 Error correction by retransmission.............................................................................................................7 2.1.6 Expedited delivery .....................................................................................................................................8 2.1.7 Sequenced delivery ....................................................................................................................................8 2.1.8 Selectively Destructive ..............................................................................................................................9 2.1.9 Low latency ............................................................................................................................................. 10 2.1.10 Transmit bandwidth limiting................................................................................................................ 11 2.1.11 Bandwidth efficient.............................................................................................................................. 11 2.1.12 Windowed flow control ....................................................................................................................... 12 2.1.13 Light-weight ........................................................................................................................................ 12 2.2 Requirements Agreed to, but NOT Agreed to as Primary or Secondary ..................................................... 13 2.2.1 Instrumented ............................................................................................................................................ 13 2.2.2 Forward error correction .......................................................................................................................... 13 2.3 Requirements Agreed to as Secondary Requirements ................................................................................. 14 2.3.1 Error correction by continuous transmission ........................................................................................... 14 2.3.2 Explicit flow control ................................................................................................................................ 14 2.3.3 Robust under congestion, congestion control, and transmit bandwidth limiting ..................................... 15 2.3.4 Fairness .................................................................................................................................................... 15 3 Evaluation of Protocols against the Requirements .............................................................................................. 16 3.1 Requirements Agreed to as Primary Requirements ..................................................................................... 17 3.2 Requirements Agreed to, but NOT Agreed to as Primary or Secondary ..................................................... 17 3.3 Requirements Agreed to as Secondary Requirements ................................................................................. 18 4 Proposed Issues and Agreements for V.moip ...................................................................................................... 19 Table of Figures Figure 1 - One-way, point-to-point reliable transport model .........................................................................................4 Table of Tables Table 1 - Transport protocol requirements agreed to as primary requirements ........................................................... 17 Table 2 - Transport protocol requirements agreed to as either primary of secondary requirements ............................ 17 Table 3 - Transport protocol requirements agreed to as secondary requirements........................................................ 18 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 2 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 1 Introduction Within the development of V.moip, a need has been recognized, in at least some MoIP scenarios, for a reliable transport protocol through the IP network connecting the MoIP gateways. This contribution presents requirements for a such a protocol and an evaluation of some protocols according to those requirements, to the extent that the contributing companies could agree on them. This means that the requirements and evaluations presented here may not be complete, or correct, or either, because: no contributing company knew of a particular requirement for discussion, and the requirement may become apparent after further investigation of a reliable transport protocol for MoIP; the contributing companies could not agree on the requirement, in which case contributing companies may make individual contributions giving their views; a contributing company felt it could not raise a requirement at this time because of as yet undisclosed intellectual property, in which case the company may make an individual contribution disclosing its intellectual property. This contribution consists of three subsequent sections: the agreed to requirements for a reliable transport protocol for MoIP; an evaluation of some protocols against those requirements; and proposed issues and agreements for the V.moip work. Within the requirements section, requirements are presented in two sub-sections as being: requirements that the joint contributors could agree were primary requirements, i.e., requirements that a transport protocol absolutely must satisfy in order to be usable with MoIP; requirements that the joint contributors could agree to as requirements, but could NOT agree to as being primary or secondary requirements; and requirements that the joint contributors could agree were secondary requirements, i.e., requirements that a transport protocol may optionally satisfy in satisfying a primary requirement, or if satisfied would assist in the satisfaction of one or more primary requirements. Within each requirements sub-section, each requirement or group of related requirements is presented by: zero or more definitions of terms that are used in the statement of the requirement(s), the terms being defined given in italics; the requirement(s), given in bold; 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. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 3 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 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 oneway, 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: Source Transmitter Application data flow Reliable Transport Protocol Sink Receiver Figure 1 - One-way, point-to-point reliable transport model 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 requirements given below. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 4 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2 Requirements for a Reliable Transport Protocol for MoIP 2.1 Requirements Agreed to as Primary 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 it involves two entities. A session is multi-point iff it invloves 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. 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 MUST support two-way, point-to-point sessions; it MAY support one-way sessions, or multi-point sessions, or both, but it need not. Comments: Most connections between modems through the PSTN are analogous to two-way, point-to-point sessions. Exceptionally, they may be one-way, or multi-cast, or both. Two-way, point-to-point connections between modems are within the scope of V.moip. One-way, or multicast, or both, sessions appear to be beyond the scope of V.moip. 2.1.2 Packet-based Definitions: A transport mechanism (protocol, session) is packet based 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. The transport mechanism (protocol, session) is stream based (not packet based) if it receives from one entity and delivers to the remote entity a stream of bytes without preserving the packet structure of the data. Requirements: The transport protocol used with MoIP MUST be packet based. Comments: If the transport protocol (mechanism, session) is stream based (not packet based), the V.moip protocol will have to include mechanisms for the source to “frame” its PDUs (protocol data units) within the transport mechanism 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 5 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 “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 co-existence with RTP and UDP/TL Definitions: A packet-based transport mechanism (protocol, session) is said to gracefully co-exist with RTP (UDP/TL) iff the transport mechanism can be used within the same session being used for RTP (UDP/TL). Note: the co-existence of 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 gracefully coexists with RTP based voice, and MAY gracefully coexists with UDP/TL for facsimile. Comments: MoIP must function in a packet-based network that also supports voice and facsimile transport. Transitions between voice, facsimile, 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. 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-exisitence” 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. Since transition for voice to modem (and visa-versa) is expected to be the most common type media transition, with transition for facsimile to modem (and visa-versa) unlikely, priority is given to the graceful co-existence with RTP. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 6 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.1.4 Error-detecting and error-correcting, non-corrupting, non-erasing, and nonduplicating Definitions: A packet-based transport mechanism (protocol, session) 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 packet-based transport mechanism (protocol, session) 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 packet-based transport mechanism (protocol, session) 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, i.e., it has not been detected to be in error. A packet-based transport mechanism (protocol, session) 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 packet-based transport mechanism (protocol, session) 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 nonduplicating; it MAY provide error detection above and beyond that provided by the underlying IP-based packet network, but it need not. Comments: 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 packet-based transport mechanism (protocol, session) 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 recovery by retransmission. Comments: Ultimately, this is the only mechanism by which very high reliability can be achieved economically. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 7 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.1.6 Expedited delivery Definitions: Delivery of a PDU within a packet-based session is expedited if, at the request of the source, the PDU can and should if possible 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 packet-based 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 requirement 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. 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 packet-based transport mechanism (protocol, session) 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 sink 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. Alternately to delivering the packets to the sink in the order they were given to the transmitter by the source, the sink 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. Note that the contributors could not agree among themselves whether sequence MUST or only MAY be preserved across expedited and normal data taken together. This, if required, would be a stronger requirement than that stated above. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 8 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.1.8 Selectively Destructive Definitions: A packet-based transport mechanism (protocol, session) is selectively destructive iff the source can trigger the discarding of in-transit data previously requested for transmission. Requirements: The transport protocol used with MoIP MUST be selectively destructive. Comments: Supporting some V.42 operations, such as destructive breaks, requires the transport mechanism used for MoIP to be selectively destructive. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 9 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.1.9 Low latency Definitions: A packet-based reliable transport mechanism (protocol, session) is 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; 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 is low latency iff p>=t. Requirements: The transport protocol used with MoIP MUST be 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. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 10 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.1.10 Transmit bandwidth limiting Definitions: A packet-based transport mechanism (protocol, session) is transmit bandwidth limiting iff the application that uses the transport mechanism can define a bandwidth value which is not exceeded by the transport mechanism. 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 packet-based transport mechanism (protocol, session) is bandwidth efficient if the total amount of network bandwidth used is small with respect to the amount of application data being carried. For the MoIP application, the transport mechanism 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. 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. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 11 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.1.12 Windowed flow control Definitions: A packet-based transport mechanism (protocol, session) uses windowed flow control iff there is a limit on the number of unacknowledged blocks 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 blocks that the receiver will discard because, e.g., it doesn’t have a buffer in which to place them. The discarding of blocks for this reason would contribute to bandwidth inefficiency. 2.1.13 Light-weight Definitions: A packet-based transport mechanism (protocol, session) 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 more than one protocol is compared. Requirements: The transport protocol used with MoIP MUST be light-weight. Comments: “Light-weight” attempts to capture in some sense or another the cost of implementing and operating the protocol. Low cost is desirable in MoIP implementations and operations. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 12 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.2 Requirements Agreed to, but NOT Agreed to as Primary or Secondary 2.2.1 Instrumented Definitions: A packet-based transport mechanism (protocol, session) 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. Requirements: 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 packet-based transport mechanism (protocol, session) 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. Requirements: 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 can, in general, not 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. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 13 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.3 Requirements Agreed to as Secondary Requirements 2.3.1 Error correction by continuous transmission Definitions: A packet-based transport mechanism (protocol, session) employs error correction by continuous transmission iff it continuously retransmits a packet until its receipt is acknowledged. Requirements: 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.3.2 Explicit flow control Definitions: A packet-based transport mechanism (protocol, session) 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: 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. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 14 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 2.3.3 Robust under congestion, congestion control, and transmit bandwidth limiting Definitions: A packet-based transport mechanism (protocol, session) 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. Requirements: 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 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.3.4 Fairness Definitions: A packet-based transport mechanism (protocol, session) 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. Requirements: 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 band-width to each call, fairness is not an issue for them. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 15 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 3 Evaluation of Protocols against the Requirements The following three subsections contain tables, the rows of which list the requirements that were: agreed to as primary requirements; agreed to as requirements without agreement as to being primary or secondary; and agreed to as secondary requirements. Within each table, the columns give an indication of whether or not: V.42 / MNP4 satisfies the requirement 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 satisfy the requirement. Within each cell at the intersection of a row and column: a “Y” indicates the row’s requirement exists in the column’s application or is satisfied by the column’s protocol; an “N” indicates that the row’s requirement does not exist in the column’s application or is not satisfied by the column’s protocol; a “-” indicates that the row’s requirement is not relevant to the column’s application or protocol; a “?” indicates that none of the joint contributors had a view as to whether or not the row’s requirement exists in the column’s application or is satisfied by the column’s protocol; and a “*” indicates that the joint contributors had differing views as to whether or not the row’s requirement exists in the column’s application or is satisfied by the column’s protocol; 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 16 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 3.1 Requirements Agreed to as Primary Requirements Primary V.42 / UDP Requirement MNP4 MoIP IP TCP UDP TL RTP Point-to-point Y Y Y Y Y Y Y Multi-point N Y N Y N Y One-way Y Y Y Two-way Y Y Y Y Packet-based N Y Y N Y Y Y Graceful coexistence with: RTP Y Y N Y N Y UDP/TL N N N N Y N Error detecting Y Y N Y Y Y Y Error correcting Y Y N Y N Y N Error correction Y Y Y N by retransmission Non-corrupting Y Y Y Y Y Y Y Non-erasing Y Y N Y N Y N Non-duplicating Y Y N Y N Y N Expedited delivery Y Y N N N N N Sequenced delivery Y Y N Y N N Y Selectively Y Y N N N N N destructive Low latency Y Y Y N Y Y Y Transmit bandwidth Y Y Y * * limiting Bandwidth efficient Y Y N N Y Windowed flow Y Y N Y N N N control Light weight Y Y * Y Y “Y” when payload type field added to SPRT header (future contribution will detail.) RTP FEC Y Y Y Y Y RTP REC Y Y Y Y Y SPRT Y N Y Y Y N Y N N Y N Y Y Y N1 N Y Y Y Y N N N Y N Y Y N N Y N Y Y Y Y Y Y Y * Y * * * Y N Y N * Y Y Y * Table 1 - Transport protocol requirements agreed to as primary requirements 3.2 Requirements Agreed to, but NOT Agreed to as Primary or Secondary Primary or Secondary Requirement Instrumented Forward error correction V.42 / MNP4 MoIP IP TCP UDP UDP TL RTP RTP FEC RTP REC SPRT N N Y Y N - N N N - N Y Y - Y Y Y - N N Table 2 - Transport protocol requirements agreed to as either primary of secondary requirements 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 17 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 3.3 Requirements Agreed to as Secondary Requirements Secondary Requirement Error correction by continuous transmission Explicit flow control Robust under: Congestion Congestion control Transmit bandwidth limiting Fairness V.42 / MNP4 N MoIP N IP - TCP N UDP - UDP TL Y RTP - RTP FEC N RTP REC N SPRT N Y Y N N N N N N N N - Y Y - Y Y N N N N N N N N N N *1 *1 - Y - Y N Y Y N N Y - Y - Y N N N N N *1 Congestion control and fairness mechanisms for SPRT are implementation specific Table 3 - Transport protocol requirements agreed to as secondary requirements 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 18 Telecommunications Industry Association (TIA) Baltimore, MD, 16-20 July, 2001 4 Proposed Issues and Agreements for V.moip Based on the above, we propose the following questions and agreements for V.moip: Item Number Status Item Description 4.4.1 Agreed (07/01) 4.4.1.1 Open 4.4.1.2 Agreed (07/01) that the transport layer MUST: support point-to-point two-way sessions, be packet based; gracefully co-exist with RTP; be error detecting and correcting; use error correction by retransmission; non-corrupting, -erasing, and -duplicating; support expedited and sequenced delivery, and selective destruction; be low latency and transmit bandwidth limiting; be light weight and bandwidth efficient; support windowed flow control; and NOT use error correction by continuous transmission. Should the transport layer: be instrumented; and use forward error-correction? that the transport layer MAY, but need not: support explicit flow control; be robust under congestion, congestion control, and transmit bandwidth limiting; be fair. 3Com Corp., Cisco Systems, Inc., and Texas Instruments MoIP Reliable Transport Requirements and Evaluation TR-30.1/01-07-051 Reference(s) PCM01-020 TR-30.1/01-07-051 PCM01-020 TR-30.1/01-07-051 PCM01-020 TR-30.1/01-07-051 19