Reliable Multicast Transport (rmt)

http://datatracker.ietf.org/wg/rmt/

rfc3269

Reliable Multicast Transport (RMT) protocols can be constructed in a variety of ways, some of which will work better for certain situations than others. It is believed that the requirements space for reliable multicast transport is sufficiently diverse that no one protocol can meet all the requirements [RFC2887]. However, it is also believed that there is sufficient commonality between the various approaches that it should be possible to define a number of building blocks [RFC3048] from which the various RMT protocols can be constructed.

rfc2887: The Reliable Multicast Design Space for Bulk Data Transfer

rfc2887

design space is large –

> restriction of design space by application constraints reduces it to solution space.
1. application contraints
  1. delivery confirmation
  2. constraining differences btw. receivers
  3. receiver set scalling
  4. reliability requirements
  5. time-bounded delivery
2. network contraints
  1. internet vs. intranet:
  2. return path: feedback from receivers: mcast, ucast, no feedback channel-forward error correction (FEC)
  3. Network assistance: entities on forwarding tree: distinguished receiving groups, servers, routers.
3. Good throughput mechanisms: packet loss affects congestion control and througput. Techniques used by RM to address packet loss: ACK, NACK, Redundancy.
  1. ACK based: small set of receivers.
    1. ring
    2. tree based ACK:
      
      scalable, reliable (than ring).
      
      algorithm deals with tree formation and maintainance.
      
      parent nodes aggregate feedback.
      
      feedback tree and data tree corellation: retransmission of lost packet. NOTE transport level router to support retranmission.
      
      how to aggregate ACK?: bundle all ACKs, list of ACK-ed nodes, combined ACK-NACK.
  2. NACK based: detects NOT-received paket and send NACK for that packet.
    1. pros: receiver takes care of reliability, reduced ACKs, no tree or ring topology formation. cons: senders has no info about receivers.
    2. NACK suppression: the difference btw. NACK-based protocols. 1 NACK to sender and 1 retransmission to receiver.
    3. * Different mechanisms: SRM, NTE, AAP, PGM and LMS.
    4. Replication: not always require explicit reliability. e.g., while user is typing not reliability is required but then the whole line must be reliably transferred.
    5. Paket-level FEC.
    6. Layered-FEC.
4. Congestion Control Mechanisms: 5 classes of single-sender mcast congestion control solutions:
  1. sender-controlled, one group;
  2. sender-controlled, multiple groups;
  3. receiver-controlled, one group;
  4. receiver-controlled layered organizations;
  5. router-based congestion control.
5. security considerations.
  - receiver set scaling does not affect source authentication and data integrity. But it affects data encryption, key distribution, re-keying.
  - DOS attack, flooding attack…
===== rfc3048: Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer =====
{

{tag>rfc3048}}

rfc5775 Asynchronous Layered Coding (ALC) Protocol Instantiation

rfc5775

Architecture Definition
ALC uses the LCT building block [RFC5651] to provide in-band session management functionality. ALC uses a multiple rate congestion control building block that is compliant with [RFC2357] to provide congestion control that is feedback free. Receivers adjust their reception rates individually by joining and leaving channels associated with the session. ALC uses the FEC building block [RFC5052] to provide reliability. The sender generates encoding symbols based on the object to be delivered using FEC codes and sends them in packets to channels associated with the session. Receivers simply wait for enough packets to arrive in order to reliably reconstruct the object. Thus, there is no request for retransmission of individual packets from receivers that miss packets in order to assure reliable reception of an object, and the packets and their rate of transmission out of the sender can be independent of the number and the individual reception experiences of the receivers.

rfc3170.txt IP Multicast Applications: Challenges and Solutions

rfc3170

Definition IP Mcast-enabled network

An “IP multicast-enabled network” provides end-to-end services in the

 IP network infrastructure to allow any IP host to send datagrams to
 an IP multicast address that any number of other IP hosts widely
 dispersed can receive.  There are two kinds of multicast-enabled networks available.  The
 first is based on the original multicast service model as defined in
 RFC 1112 [Deering].  In this model, a receiver simply joins the group
 and does not need to know the identity of the source(s).  This model
 is known by a number of names including Internet Standard Multicast
 (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc.
 The second kind of multicast modifies the original service model such
 that in addition to knowing the group address, a receiver must know
 the set of relevant sources.  This type of multicast is called Source
 Specific Multicast (SSM) [SSM].  It becomes the application's
 responsibility to know what kind of multicast capability the network
 provides.  Currently, the only way for an application to know the
 type of multicast is based on the group address.  If the group is in
 the 232/8 range, the application should assume SSM is the service
 model.  Otherwise, the application should assume source-generic
 multicast is the service model.

Multicasting over Overlay Networks – A Critical Review

M.F.M Firdhous

Abstract: Multicasting technology uses the minimum network resources to serve multiple clients by duplicating the data packets at the closest possible point to the clients. This way at most only one data packets travels down a network link at any one time irrespective of how many clients receive this packet. Traditionally multicasting has been implemented over a specialized network built using multicast routers. This kind of network has the drawback of requiring the deployment of special routers that are more expensive than ordinary routers. Recently there is new interest in delivering multicast traffic over application layer overlay networks. Application layer overlay networks though built on top of the physical network, behave like an independent virtual network made up of only logical links between the nodes. Several authors have proposed systems, mechanisms and protocols for the implementation of multicast media streaming over overlay networks. In this paper, the author takes a critical look at these systems and mechanism with special reference to their strengths and weaknesses.

Keywords – Multicasting; overlay networks; streaming media;

Table of Contents