NACK-Oriented Reliable Multicast

Last updated • 16 min readFrom Wikipedia, The Free Encyclopedia

NACK-Oriented Reliable Multicast (NORM) is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.

Contents

NORM operates on top of the User Datagram Protocol (UDP), and ensures reliable communication based upon a negative acknowledgement (NACK), selective Automatic Repeat Request (ARQ) mechanism, as opposed to the positive acknowledgement (ACK) approach that the standard Transmission Control Protocol (TCP) uses. In other words, receivers using NORM only send feedback when they do not receive a packet, as opposed to the TCP model where receivers regularly acknowledge packet receipt as part of it protocol operation. This allows NORM to support large-scale receiver groups.

To support further scalability, NORM also employs packet erasure coding using forward error correction (FEC) codes coupled with suppression of redundant NACK feedback from the receiver group. Additionally, NORM can be configured to operate with “silent receivers” relying upon its packet erasure coding for high assurance delivery, thus operating as a broadcast-only protocol. The FEC can be configured to be used either reactively (with NACKing receivers) or proactively (silent receivers), or in a hybrid manner that allows tradeoffs in latency and network overhead.

Along with supporting reliable transport, NORM also provides TCP-compatible congestion control as well as end-to-end flow control. Unlike TCP, which uses the ACK mechanism for congestion control and flow control, NORM uses separate mechanisms for each. This allows for a wide variety of configurations to meet different application data delivery needs.

NORM also supports additional signaling mechanisms to facilitate session control, application-controlled positive acknowledgement, and other functions towards building complete point-to-point and group network communications applications that are highly robust and efficient.

Although NORM was developed primarily to support multicast group communication, it also supports unicast (point-to-point) data transfers.

Background

In the TCP/IP network model, the transport layer of the network (Layer 4) is responsible for the reliable transport of data. The TCP protocol is the principal means of ensuring reliable unicast (point-to-point) transport. TCP does this through an ACK mechanism.

With the ACK mechanism, data packets are sequentially numbered, and the sender does not send a packet in a sequence until it receives an acknowledgement (ACK) from the receiver that the previous packet has been successfully received. If the sender does not receive an ACK after a specified time period, it resends the associated packet. The sender will continue doing this until it receives an ACK (although beyond a certain point the sender will assume the connection has been lost and stop the session). This is loosely analogous to a human listener nodding his or her head and saying "uh-huh" in a one-on-one conversation between persons. (TCP's sister protocol, UDP, does not do this. UDP simply sends data packets over the network in a best effort manner and assumes the packets are well-received.)

An early problem noted with TCP's ACK mechanism was it did not work well in large multicast group communications. In multicast group communications, data packets are transmitted to a group of receivers simultaneously. In large multicast groups, the use of ACKs can create “ACK implosions,” in which a large number of simultaneous ACKs can overwhelm the sender. [1] This is loosely analogous to a large roomful of human listeners nodding their heads and saying "uh-huh" while a speaker is talking.

The Multicast Dissemination Protocol (MDP) [2] was an initial attempt to ensure reliability and to address the problem of ACK implosions through the use of NACKs. MDP used selective negative acknowledgement (NACK) to support reliability. Additionally, MDP implemented probabilistic techniques to suppress redundant NACKs in the multicast group (and thereby avoid NACK implosions).

MDP also used packet-level forward error correction coding concepts as a repair mechanism. Encoded parity repair packets were generally sent in response to repair requests by receivers. In this way no additional protocol overhead was added above selective retransmission methods. Additionally, MDP allowed the protocol to be optionally configured to send proactive repair packets in the original data transmission block.

MDP was a direct predecessor to NORM, with an initial IETF draft published in November 1996. [3] The National Aeronautics and Space Administration (NASA) adopted MDP for reliable file transfers during space missions. [4] , and the U.S. Army used in for tactical group messaging in its Force Battle Command Brigade and Below (FBCB2) system. [5]

Several other approaches to reliable multicast were being developed at approximately the same time, [6] and in April 1999, the IETF chartered the Reliable Multicast Transport Working Group (RMTWG) to standardize reliable multicast transport. [7]

The RMTWG pursued the strategy of developing building blocks and protocol instantiations. This strategy avoided a "one size fits all" protocol, which in turn could accommodate the large number of applications and types of applications that reliable multicast could support.

Building blocks were defined as “a set of easily-separable coarse-grained modular components that are common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.” [7] Initial building blocks included negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection

Protocol instantiations were defined as “specifications that define the necessary gluing logic and minimal additional functionality required to realize a working protocol from one or more building blocks.” [7] Those specifications would also include an abstract API that defined the interface between the protocol implementation and an application. Two protocol instantiations were chosen:

In July 2005 the NACK-based protocol building blocks and protocol instantiation were submitted as “Experimental” in RFC 3940, and in November 2009 “NACK-Oriented Reliable Multicast (NORM) Transport Protocol” was approved in RFC 5740. [8]

The RMTWG was disestablished in September 2013. [9]

NORM architectural constructs

The following architectural constructs are defined in RFC 5740 Section 2, Architecture Definition. [10]

The NORM message is the fundamental NORM architectural construct. A NORM message is contained in the data field of a UDP datagram.

A NORM object refers to one of the three different types of bulk data carried in a NORM message:

NORM_OBJECT_DATA refers to static computer memory data content, while NORM_OBJECT_FILE refers to computer storage files. Both message types provide reliable transport to finite blocks of content, but a distinction is made to allow receivers to determine what type of storage to allocate for the content of received messages.

The NORM_OBJECT_STREAM refers to streams (non-finite) of continuous data content. NORM supports reliable transport of streaming data similar to that of TCP, with an exception being that NORM receivers are able to join in the reception of stream content without regard for the point of time in the stream.

A NORM session refers to the exchange of information among two or more network hosts using NORM. Typically a NORM session takes place using pre-determined IP addresses and port numbers, which are usually associated with IP multicast group addresses that are determined prior to the session. These addresses may be determined using other protocols, such as the Session Description Protocol (SDP) [RFC 4566] or the Session Announcement Protocol (SAP) [RFC 2974]. Although NORM was specifically designed for multicast group communication, it supports unicast communication, also.

A fundamental assumption about a NORM session is that it will consist of a single transmitter communicating with a group of receivers. Multiple senders may operate in a given NORM session, although each receiver must maintain state for each sender.

A NORM node refers to an individual node taking part in a NORM session. Each node has a unique identifier. When a node transmits a NORM message, this identifier is noted as the source_id.

A NORM instance refers to an individual node in the context of a continuous segment of a NORM session. When a node joins a NORM session, it has a unique node identification as well as an instance identification. If the node leaves the session for any reason, and later rejoins the session, the node identification remains the same, but the instance identification changes. The current instance is noted as the instance_id.

NORM message structure

NORM has two general message classes, sender and receiver messages, that are defined in RFC 5740 Section 4, NORM Message Formats. [11] NORM sender message types are: NORM_DATA, NORM_INFO, and NORM_CMD. NORM receiver message types are: NORM_NACK, NORM_ACK, and NORM_REPORT.

All NORM messages consist of a mandatory common header, a message type header, and a payload (data) section. An optional extension field that specifies the error correction encoding being used, the congestion control algorithm, or other session management information, can be inserted between the header and payload sections.


Generic NORM Message Structure
0123
01234567012345670123456701234567
Common Message Header
Message Type Header
Optional Header Extensions
Payload


NORM Common Message Header

All NORM messages begin with the following common header, defined in RFC 5740, Section 4.1, NORM Common Message Header and Extension. [12]



0123
01234567012345670123456701234567
versiontypehdr_lensequence
source_id
version (4 bits)
The protocol version number.
type (4 bits)
The NORM message type (i.e., 1 = NORM_INFO, 2 = NORM_DATA, 3 = NORM_CMD, 4 = NORM_NACK, 5 = NORM_ACK, 6 = NORM_REPORT).
hdr_len (8 bits)
The number of 32-bit words that constitute the given message's header portion. This is used to identify the addition of header extensions. If the "hdr_len" value is greater than the base value for the given message type, it implies the presence of a header extension.
sequence (16 bits)
Serves two purposes (depending on the message type):
  • Allows receivers to maintain an estimate of packet loss to facilitate congestion control
  • Supports protection from message replay attacks of NORM_NACK or NORM_NACK messages.
source_id (32 bits)
The unique identify of the node that originated the message within the context of a given NORM session.

NORM_DATA Message Type

The NORM_DATA message, defined in RFC 5740 Section 4.2.1, is the most common message type transmitted by NORM senders. [13] NORM_DATA messages carry segmented data content for NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM types.

0123
01234567012345670123456701234567
versiontypehdr_lensequence
source_id
instance_idgrttbackoffgsize
flagsfec_idobject_transport_id
fed_payload_id
header_extensions (if applicable)
payload_length (see Note 1)payload_msg_start (see Note 1)
payload_offset (see Note 1)
payload_data
instance_id (16 bits)
A unique identification of the current instance of participation in the NORM session.
grtt (8 bits)
The sender's current estimate of group round-trip time.
backoff (4 bits)
A value used by receivers to determine the maximum backoff timer value when using timer-based NORM NACK feedback suppression mechanisms.
gsize (4 bits)
The sender's current estimate of group size.
flags (32 bits)
Binary flags providing information to assist the receiver in appropriately handling the payload.
fec_id
The FEC Encoding Identifier. This is described in the FEC Building Block document [RFC5052].
object_transport_id
A value assigned by the sender to NORM objects being transmitted that receivers use for transmissions and repair requests. It is increased in a monotonically incremental manner.
fec_payload_id
An identifier for the attached NORM_DATA payload content.
Note 1
payload_length, payload_msg, and payload_offset only pertain to NORM_OBJECT_STREAM content.

NORM_INFO Message Type

NORM_INFO messages, defined in RFC 5740 Section 4.2.2, allow optional, out-of-band data to be sent in association with the data content objects. [14] This allows receivers to determine the nature of the corresponding content being transmitted, which in turn allows application-level control of the receiver node's participation in the session.

The NORM_INFO content must fit into the payload portion of a single NORM message. Thus, it is considered atomic. An example of NORM_INFO use would be to send MIME-type information for the associated NORM data content. This would allow receivers to make decisions about their participation in the session.

0123
01234567012345670123456701234567
versiontypehdr_lensequence
source_id
instance_idgrttbackoffgsize
flagsfec_idobject_transport_id
header_extensions (if applicable)
payload_data


...


instance_id (16 bits)
A unique identification of the current instance of participation in the NORM session.
grtt (8 bits)
The sender's current estimate of group round-trip time.
backoff (4 bits)
A value used by receivers to determine the maximum backoff timer value when using timer-based NORM NACK feedback suppression mechanisms.
gsize (4 bits)
The sender's current estimate of group size.
flags (32 bits)
Binary flags providing information to assist the receiver in appropriately handling the payload.
fec_id
The FEC Encoding Identifier. This is described in the FEC Building Block document [RFC5052].
object_transport_id
A value assigned by the sender to NORM objects being transmitted that receivers use for transmissions and repair requests. It is increased in a monotonically incremental manner.

NORM_CMD Message Type

NORM_CMD messages, defined in RFC 5740 Section 4.2.3, are used to manage NORM sessions. [15] These messages serve to collect round-trip timing, gather and send data related to congestion control, synchronize repair windows, and make notifications of a sender's status. There is a core set of specified and enumerated NORM_CMD messages, as well as a range other available types for application-specific use.

0123
01234567012345670123456701234567
versiontypehdr_lensequence
source_id
instance_idgrttbackofgsize
flagsfec_idobject_transport_id
sub-typeNORM_CMD Content
NORM_CMD Content


...

instance_id (16 bits)
A unique identification of the current instance of participation in the NORM session.
grtt (8 bits)
The sender's current estimate of group round-trip time.
backoff (4 bits)
A value used by receivers to determine the maximum backoff timer value when using timer-based NORM NACK feedback suppression mechanisms.
gsize (4 bits)
The sender's current estimate of group size.
flags (32 bits)
Binary flags providing information to assist the receiver in appropriately handling the payload.
fec_id
The FEC Encoding Identifier. This is described in the FEC Building Block document [RFC5052].
object_transport_id
A value assigned by the sender to NormObjects being transmitted that receivers use for transmissions and repair requests. It is increased in a monotonically incremental manner.
sub_type (8 bits)
Indicates the type of command that follows.
NORM_CMD content

NORM_NACK Message Type

NORM_NACK messages, defined in RFC 5740 Section 4.3.1, are used primarily for receivers to request repairs of sender content. [16] Additionally, these messages contain fields to provide information to the sender(s) related to round-trip timing collection and congestion control.

0123
01234567012345670123456701234567
versiontypehdr_lensequence
source_id
server_id
instance_idreserved
grtt_response_sec
grtt_response_usec
header_extensions (if applicable)
nack_payload


...


server_id (32 bits)
The NORM sender to which the NORM_NACK message is destined.
instance_id (16 bits)
A unique identification of the current instance of participation in the NORM session.
reserved (16 bits)
For potential future NORM use
grtt_response_sec (32 bits)
An adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender.
grtt_response_usec (32 bits)
An adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender.
NACK_payload
The repair needs of the receiver with respect to the NORM sender indicated by the "server_id" field.

NORM_ACK Message Type

NORM_ACK messages, defined in RFC 5740 4.3.2, are used primarily to support congestion control operations and round-trip timing measurements. [17]

0123
01234567012345670123456701234567
versiontypehdr_lensequence
source_id
server_id
instance_idack_typeack_id
grtt_response_sec
grtt_response_usec
header_extensions (if applicable)
ack_payload (if applicable)
server_id (32 bits)
The NORM sender to which the NORM_ACK message is destined.
instance_id (16 bits)
A unique identification of the current instance of participation in the NORM session.
ack_type (8 bits)
The nature of the NORM_ACK message. This directly corresponds to the "ack_type" field of the NORM_CMD(ACK_REQ) message to which this acknowledgment applies.
ack_id (8 bits)
A sequence number so the sender can verify a received NORM_ACK message actually applies to a current acknowledgment request. The "ack_id" field is not used in the case of the NORM_ACK(CC) and NORM_ACK(FLUSH) acknowledgment types.
grtt_response_sec (32 bits)
An adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender.
grtt_response_usec (32 bits)
An adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender.
ack_payload (if applicable)
The "ack_payload" format is a function of the "ack_type".

NORM_REPORT Message Type

The NORM_REPORT message, discussed in RFC 5740 Section 4.4.1, is an optional message. [18] The format is currently undefined.

NORM Header Extensions

Optional header extensions, defined in RFC 5740 Section 4.1, follow the common header and the message-specific header, and they precede the payload (if there is one). [19] Header extensions typically carry information related to baseline FEC, congestion control operations, and other session management information. There are two types of header extensions: variable-length and fixed-length.

Variable-Length Header Extension
0123
01234567012345670123456701234567
het ≤ 127helHeader Extension Content
Header Extension Content


...

het (8 bits)
The header extension type. For variable-length header extensions, a value between 0 and 127 (inclusive).
hel (8 bits)
The header extension length. Indicates the length of the entire header extension.
header extension content
Varies depending on the purpose.


Fixed-Length Header Extension
0123
01234567012345670123456701234567
het ≥ 128reservedHeader Extension Content
het (8 bits)
The header extension type. For fixed-length header extensions, a value between 128 and 255 (inclusive).
reserved (8 bits)
Reserved for future use.
header extension content (16 bits)
Varies depending on purpose.

Protocol operation

General operations

The following general NORM protocol operation is described in RFC 5740 Section 5, Detailed Protocol Operation. [20]

1. Following the establishment of a NORM session, a sender segments a NORM object into an ordinally-numbered sequence. These segments are transmitted as NORM_DATA messages. In addition to data content, NORM_DATA messages are labelled with unique identifiers and FEC identifiers. The sender may also send out-of-band NORM_INFO messages associated with the NORM_DATA content that allow receivers to determine the nature of the corresponding content, which in turn allows application-level control of the receiver node's participation in the session.

At the same time, the sender periodically transmits NORM_CMD(CC) messages as needed to collect feedback information necessary for congestion control and other session management activities.

2. When receivers detect missing content from a sender, they may attempt repair using FEC mechanisms. Barring successful repairs, the receivers will send NORM_NACK messages to the sender. Using the ordinally-numbered sequence information, the receivers specify missing content.

3. As the sender receives NACKs, it aggregates repair requests and sends appropriate repairs associated with the ordinally-numbered sequence information.

4. When the sender reaches the end of a collection of repair requests, it transmits a NORM_CMD(FLUSH) message, indicating the temporary end of transmission.

Within the context of general operations, NORM has specific mechanisms to address session control, congestion control, flow control, reliability, and NACK management.

Session Control

Although NORM is not a connection-oriented protocol, like TCP, it does have both connection-oriented and connection-less characteristics. [21]

Unlike the connection-oriented TCP protocol, NORM does not establish a session with a setup mechanism (i.e., a three-way handshake). Rather, NORM uses predesignated port numbers and addresses that senders and receivers must know. This allows receivers to join ongoing NORM sessions, and it allows quick resumption of a session after a network outage.

At the same time, NORM senders and receivers maintain state to ensure reliable transfer, hence NORM is not totally connection-less.

A range of NORM_CMD message sub-types is reserved to support session control protocols that may be developed in the future.

Congestion Control

NORM uses a TCP-Friendly congestion control scheme that enables it to fairly share available bandwidth with TCP and other transport protocols. [22] Specifically, NORM's congestion control scheme uses a rate control procedure, and it is an adaptation of the TCP-Friendly Multicast Congestion Control [TFMCC] Protocol Specification approach described in RFC4654. This approach has been demonstrated to work well with TCP and multicast data flows.

The TFMCC congestion control approach is an equation-based approach. Sender transmission rates rely on the collection of packet loss estimates and round trip times that are collected with NORM_CMD(CC) messages. This information identifies bottlenecks and adjusts the sender rate to accommodate them.

As with TCP, the NORM congestion control scheme assumes packet loss is due to buffer overflows, and the sender consequently backs off it transmission rate when packet loss reaches a specified level. This can lead to limitations in wireless networks, where packet loss is often due to bit errors or contention.

Because NORM's rate control mechanism is separate from its other components, e.g., reliability mechanism, flow control mechanism, it can be replaced with an alternative algorithm and appropriate header extensions.

Flow Control

NORM has four options for flow control, which allows the NORM sender to manage the rate of transmission to NORM receivers to ensure the receivers are not overwhelmed. [23]

1. Explicit watermark. With this option the sender requests positive acknowledgement from a specific set of receivers regarding the successful reception of a designated point, or watermark, in the current transmission. If all the receivers acknowledge successful receipt of the watermark, the sender can continue sending new data.

2. Implicit watermark. This option is based on a lack of negative acknowledgement (NACK) repair requests from the receiver set. The sender uses the NORM_CMD(FLUSH) to alert receivers to NACK for any repairs needed through the indicated watermark. The sender then waits until the flushing has fully completed. If there was no NACK activity, the sender assumes the “watermark” completed and can continue sending new data.

3. Soft, timer-based flow control. This option holds transmit data and limits repair window advancement based on group round-trip timing (GRTT) and NACK activity. A minimum, adaptable time limit is set, after which the sender can continue sending new data. This time limit is based on the sender-estimated GRTT and lack of NACK activity.

4. Purposeful disabling. This option deliberately disables flow control mechanisms and allows the application to push transmission forward with newly enqueued data in a best effort manner.

Reliability

NORM ensures reliable transport through the use of two forward error correction coding schemes: systematic codes and non-systematic codes. These are discussed in RFC 5740 Section 2, Architecture Definition: [24]

With systematic codes, the sender transmits blocks of content followed by blocks of FEC.

With non-systematic codes, the sender encodes the content with FEC prior to transmission.

Both FEC coding schemes can be used in either a reactive or proactive manner. In both cases, FEC-based repair can be affected, which allows receivers to repair packets and thereby reduces the level of repair requests and repair transmissions.

Scalability and NACK management

NACK-oriented multicast communications are susceptible to NACK implosions. If a large number of receivers NACK simultaneously, this could overwhelm the sender as well as the entire network. NORM uses a NACK suppression mechanism, discussed in RFC 5740, Section 5.3, Receiver NACK Procedure, to prevent NACK implosions. [25]

When a receiver detects it is missing data from a sender's NORM transmissions, it initiates its NACK procedure:

NORM's NACK suppression mechanism, combined with its FEC mechanism, allows NORM multicast groups to scale to very large group sizes while maintaining reliability.

Reference Implementation

The United States Naval Research Laboratory maintains a freely-available, reference implementation of the NORM protocol on GitHub. This includes source code, a developer's guide, and a user's guide.

Normative RFC documents

See also

Related Research Articles

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address, for example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.

The RTP Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides out-of-band statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data itself.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

ZMODEM is an inline file transfer protocol developed by Chuck Forsberg in 1986, in a project funded by Telenet in order to improve file transfers on their X.25 network. In addition to dramatically improved performance compared to older protocols, ZMODEM offered restartable transfers, auto-start by the sender, an expanded 32-bit CRC, and control character quoting supporting 8-bit clean transfers, allowing it to be used on networks that would not pass control characters.

Transmission Control Protocol (TCP) uses a congestion control algorithm that includes various aspects of an additive increase/multiplicative decrease (AIMD) scheme, along with other schemes including slow start and congestion window (CWND), to achieve congestion avoidance. The TCP congestion-avoidance algorithm is the primary basis for congestion control in the Internet. Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. There are several variations and versions of the algorithm implemented in protocol stacks of operating systems of computers that connect to the Internet.

IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission. It is the IP-specific form of multicast and is used for streaming media and other network applications. It uses specially reserved multicast address blocks in IPv4 and IPv6.

Retransmission, essentially identical with automatic repeat request (ARQ), is the resending of packets which have been either damaged or lost. Retransmission is one of the basic mechanisms used by protocols operating over a packet switched computer network to provide reliable communication.

Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination. Packet loss is either caused by errors in data transmission, typically across wireless networks, or network congestion. Packet loss is measured as a percentage of packets lost with respect to packets sent.

Asynchronous Layered Coding (ALC) is an Internet protocol for content delivery in a reliable, massively scalable, multiple-rate, and congestion-controlled manner. Specified in RFC 5775, it is an IETF proposed standard.

The Stream Control Transmission Protocol (SCTP) has a simpler basic packet structure than TCP. Each consists of two basic sections:

  1. The common header, which occupies the first 12 bytes. In the adjacent diagram, this header is highlighted in blue.
  2. The data chunks, which form the remaining portion of the packet. In the diagram, the first chunk is highlighted in green and the last of N chunks (Chunk N) is highlighted in red. There are several types, including payload data and different control messages.

SMART Multicast is an experimental method of Secure Reliable IP Multicast. It allows a user to forward IP datagrams to an unlimited group of receivers. See the article on multicast for a general discussion of this subject - this article is specifically about SMART IP Multicast.

An IPv6 packet is the smallest message entity exchanged using Internet Protocol version 6 (IPv6). Packets consist of control information for addressing and routing and a payload of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level transport layer protocol, but may be data for an internet layer or link layer instead.

In data networking, telecommunications, and computer buses, an acknowledgment (ACK) is a signal that is passed between communicating processes, computers, or devices to signify acknowledgment, or receipt of message, as part of a communications protocol. The negative-acknowledgement is a signal that is sent to reject a previously received message or to indicate some kind of error. Acknowledgments and negative acknowledgments inform a sender of the receiver's state so that it can adjust its own state accordingly.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

A Scalable Reliable Multicast protocol is a reliable multicast framework for light-weight sessions and application level framing. The algorithms of this framework are efficient, robust, and scale well to both very large networks and very large sessions. Wb, the distributed whiteboard tool designed and implemented by McCanne and Jacobson, is the first application based on the Scalable Reliable Multicast framework.

References

  1. P.B. Danzig (Jan 1994). "Flow Control for Limited Buffer Multicast". IEEE Transactions on Software Engineering. 20 (1): 1–12. doi:10.1109/32.263751.
  2. J.P. Macker; P.B. Adamson (1999). "The multicast dissemination protocol (MDP) toolkit". MILCOM 1999. IEEE Military Communications. Conference Proceedings (Cat. No.99CH36341). IEEE Military Communications. Vol. 1. pp. 626–630. doi:10.1109/MILCOM.1999.822759. ISBN   0-7803-5538-5. S2CID   1742198.
  3. J. Macker; W. Dang (Nov 1996). The Multicast Dissemination Protocol (MDP) Framework (Technical report). IETF.
  4. J. Rash; E. Criscuolo; K. Hogie; R. Parise; J. Hennessy (Jan 2002). MDP: Reliable File Transfer for Space Missions (Technical report). NASA.
  5. J.P. Macker; P.B. Adamson (Dec 2010). Reliable Messaging for Tactical Group Communication. Military Communications Conference 2010. doi:10.1109/MILCOM.2010.5680397.
  6. Diot, C.; Dabbous, W.; Crowcroft, J. (April 1997). "Multipoint communication: A survey of protocols, functions, and mechanisms" (PDF). IEEE Journal on Selected Areas in Communications. 15 (3): 277–290. doi:10.1109/49.564128.
  7. 1 2 3 "IETF Reliable Multicast Working Group Charter" . Retrieved February 22, 2021.
  8. "IETF Reliable Multicast Working Group Documents".
  9. "IETF Reliable Multicast Working Group History" . Retrieved February 22, 2021.
  10. RFC 5740, Section 2, Architecture Definition
  11. RFC 5740, Section 4, Message Formats
  12. RFC 5740, Section 4.1, NORM Common Message Header and Extensions
  13. RFC 5740, Section 4.2.1, NORM_DATA Message
  14. RFC 5740, Section 4.2.2, NORM_INFO Message
  15. RFC 5740, Section 4.2.3, NORM_CMD Message
  16. RFC 5740, Section 4.3.1, NORM_NACK Message
  17. RFC 5740, Section 4.3.2, NORM_ACK Message
  18. RFC 5740, Section 4.4.1, NORM_REPORT Message
  19. RFC 5740, Section 4.1, Architecture Definition
  20. RFC 5740, Section 5, Detailed Protocol Operation
  21. J.P. Macker; P.B. Adamson (Dec 2010). Reliable Messaging for Tactical Group Communication. Military Communications Conference 2010. doi:10.1109/MILCOM.2010.5680397.
  22. J.P. Macker; P.B. Adamson (Dec 2010). Reliable Messaging for Tactical Group Communication. Military Communications Conference 2010. doi:10.1109/MILCOM.2010.5680397.
  23. J.P. Macker; P.B. Adamson (Dec 2010). Reliable Messaging for Tactical Group Communication. Military Communications Conference 2010. doi:10.1109/MILCOM.2010.5680397.
  24. RFC 5740, Section 2, Architecture Definition
  25. RFC 5740, Section 5.3, Receiver NACK Procedure

Further reading