Download 2 Requirements for a Reliable Transport Protocol for MoIP

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