• Plain UDP
• No congestion control
• Best effort (No QoS)
• No guarantee of delivery
• Significant traffic

Reliability is important in some cases (File transfers)

• Needs congestion control (Like TCP)
• Needs delivery guarantees
• But not necessarily like those of unicast TCP
• Any reliable multicast solution must avoid generating significant control traffic
• Any solution must be scalable

• TCP: connection oriented
• Supports congestion control and flow control
• Sender driven congestion control
• UDL: Connectionless
• No inherent flow or congestion control
• Applications can use RTP to reduce characteristics of the transmission
• RTP includes sequence numbers, timestamps
• Can use RTCP messages back to the sender to inform it of the reception quality
• Sender can then choose to adapt encoding quality/rate

• Pretty Good Multicast
• Older Cisco method, with few variants
• Uses Negative Acknowledgements (NACKs)
• NORM
• NACK-based approach
• FLUTE
• Layered coding and receiver-based congestion control

• Cisco approach
• Recipient can ask for retransmission
• If client loses data, it sends a NACK 
• Subnet router issues a NACK confirmation (NCF)
• Local client may see the NCF and retransmit data
• Else NACK is passed upstream
• Eventually goes back to the multicast source
• Retransmission is again sent to everyone (Other clients ignore repeated data)
• PGM-CC added "TCP-like capability"
• Observes NACKs and backs off rate for whole group to bandwidth of the slowest receiver

• File delivery over UNICAST transport
• Supports ASM, SSM, IPv4 IPv6
• Unidirectional data transport
• Reliable distribution to a large number of receivers
• Uses Asynchronous Layered Coding (ALC)
• Defines transport of arbitrary binary files
• Uses Layered Coding Transport (LCT)

• Asynchronous Layered Coding Transport
• Receivers can experience different quality without the need for sender to replicate information in the different layers
• Multiple rate delivery to receivers using multiple channels
• "Wave and Equation Based Rate Control" (WEBRC)
• Receiver-driven congestion control
• Receiver chooses which channels to use
• Forward Error Correction
• Recovers from "Small" loss by sending extra data - adds an overhead, but compensated by use of multicast

• ALC is a session-based protocol
• Each session contains a number of channels
• One channel is delivered to one multicast group
• File Delivery Table (FDT) defines transmission parameters
• ALC/LCT can transmit multiple objects per session
• An object is a FDT instance or a file
• LCT adds its own header which includes:
• Transport Session Identifier (TSI)
• Which allows a session to be defined by a source IP, TSI
• The source IP may be an intermediate NAT IP
• For a session transmitting multiple objects
• Differentiate objects with Transmission Object Identifier (TOI)

• Transmission Session ID (TSI)
• Transport Object ID
• Congestion Control Information
• Sender Current Time
• Expected Residual Time
• Time the session will be continued for
• Session Last Change (SLC)
• Last time that objects were changed in the session

A FDT includes XML:

• URI
• File Type (Media type)
• File size, in octets
• Content encoding method
• Transmitted file may be smaller than original file
• Security properties
• XML digital signature (XML-DSig)
• Allows receiver to verify identity of sender
• Receivers keep a database of received FDTs

• ALC transmits objects over LCT channels
• Object is either 
• A file (TOI > 0)
• FDT Instance (TOI is 0)
• If receiver joins a group mid-session it could get packets with TOI > 0 before receiving any FDT Instance information
• Could choose to buffer/store that, or wait for the FDT
• Each receiver maintains a FDT Instance database

• Receiver needs to know in advance
• Source IP and number of channels in session
• Destination IP addresses and port numbers
• Session TSI
• Plus other information (e.g. congestion control)
• Can be defined with a Session Description Protocol (SDP)
• This can be acquired via many methods e.g.
• Session Announcement Protocol (SAP)
• Session Initiation Protocol (SIP)
• Via website
• Similar issue to discovering muliticast content in general
• With this information it can then run FLUTE

• Receiver obtains the file delivery session description
• This happens outside the FLUTE protocol
• Receiver joins channel(s)
• Receiver starts receiving LCT packets
• It checks the TSI to ensure they are for its session
• If so, receiver de-multiplexes packets using TOI
• Receiver eventually recovers a full object
• If a file, use encoding info to reconstruct, run MD5 check
• If an FDT instance, add to database

• ALC/LCT uses multiple mechanisms to provide receiver-driven congestion control
• Receiver needs to adapt to available bandwidth
• Aim is to behave more "TCP like"
• Typically use multiple rate channels
• Receivers choose which channels to receive
• Note that multicast is only received in a subnet if at least one receiver is joined to that channel
• (FLUTE doesn't discuss receiver co-operation)

• Wave and Equation Based Rate Control
• Rate congestion control for data delivery
• Requires no feedback from receiver to sender
• Thus completely receiver-driven congestion control
• All decisions to join/leave groups are taken by receiver
• Can deliver data to each receiver at best rate for each receiver from single sender
• A slow receiver does not slow down other receivers
• Includes a base channel, and a number of extra "wave" channels
• Each wave channel starts at high rate then slows down
• Each wave is at a different point in the delivery period

• A receiver joins the base channel
• It measures congestion control parameters while receiving data
• Delay, loss, etc
• Acts accordingly to measures
• It can increase reception rate by joining additional wave cahnnels in a sequence, lowest to highest
• The earlier a channel is joined, the higher the rate
• In doing so, it can take a "slow start" approach
• It can decrease the rate by not joining a new channel

• FEC can be used to provide reliability for IP multicast 
• Sender encodes message in a redundant way using an error correcting code
• Data stream is tranformed such that reconstruction of a data object does not depend on the reception of specific data packets
• Allows receiver to detect and correct the errors
• FEC is applied to whole data packets
• Encode P packets into N datagrams to be sent, where N >> K
• Cost is the need for greater bandwidth

• Video Files
• First channel might give black and white
• second colour
• three give HDTV
• FDT file objects could be whole TV programs
• Weather map
• Receiver may join a subset of channels until it has enough packets to recover the object
• Can adapt channel(s) used to receive the new map more quickly, bandwidth permitting
• May stay tuned for new session descriptions

• The receiver will join channel(s) to receive the multicast content
• It will know when a full object has ben received
• It can then leave the channel(s)
• FEC can handle a "small" amount of packet loss
• Receiver may stay "tuned" over multiple repeats of the content to receive all parts
• If the file is very large, is not repeated and loss occurs greater than FEC can handle, then a file repair service is required
• This can be provided by different server(s) to the multicast content

• A file repair service is implemented for DVB-H (handled digital video broadcast) use of FLUTE
• Receiver waits until multicast transmission is finished
• Then waits an additional random back-off period
• Then sends file repair requests for its missing data segments
• The repair service uses HTTP GET requests
• Servers may respond with unicast
• Or may respond with new session information such that receivers can receive the repair by multicast

• Back to the Blizzard problem - 10M clients, 1GB game update
• In theory you could use either approach for file distribution
• Reliable multicast
• One sender (seed) distributes FDT
• Typically the whole file is one object
• Receiver adapt to links to join channel(s)
• Data is multicast persistently while receivers come/go, can scale up to any number of receivers
• BitTorrent
• Can be fully decentralised, e.g. use DHT
• By default breaks file into chunks
• Nodes swarm to exchange chunks using TCP
• Transfers may send same data over same links but file exchange is bound to certain time