Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | garrison-santana |
View: | 43 times |
Download: | 0 times |
Last ClassCOReL: Algorithm for totally-ordered multicast in an asynchronous environment, in face of network partitions and process failures.
MotivationWhy Multicast?
Reduce network and host overhead for multi-destination delivery
Interesting applicationsConferencing etc
Ideal Multicast Protocol
Scalable
Reliable
Low join and data propagation latency
Easy to join and leave groups
Robust unknown destination delivery
Multicast Protocols for a LAN
LANs like Ethernet support Efficient broadcast delivery Large space of multicast addresses
Extended LANs pose interesting problems like
Additional routing and traffic costs may limit Scalability
Low delay, delivery with high probability etc difficult to achieve
Extension to routing to support multi-destination delivery
Multicast routing Protocols for WANs
Extending some unicast routing protocols ?
Single spanning tree routing (of extended LAN bridges)
Distance vector routing (used in internetworks)
Link state routing (used in internetworks)
Single-Spanning-Tree multicast routing
Bridges restrict all traffic to a spanning tree by
forbidding loops in the physical topologyOr running a distributed algorithm among the
bridges to compute a spanning tree
If groups members periodically issue membership packets then the bridges could learn the branches leading to the group members
SSTM (3)
If a packet arrives with a Multicast source address(?): record the
arrival branch and an associated age of zero in a table entry for that multicast address
Multicast destination address: Forward a copy of the packet out every out-going branch (except the arrival branch) recorded in the corresponding table entry (if absent discard the packet).
SSTM(3)
Periodically increment the age fields of all multicast table entries.
If an age field reaches an expiry threshold Texpire delete the associated outgoing-branch from the table entry.
If no outgoing-branches remain, delete the entire entry.
Multicast Protocols for WANs
IP multicastSRM (Scalable Reliable Multicast)RMTP (Reliable Multicast Transport Protocol)PGM (Pragmatic General Multicast)Bimodal multicast (Next class)
IP MulticastTransmission of IP datagram to a host group
Best-effort delivery (neither the delivery nor the order is guaranteed)
Membership of a host group is dynamic.
Host group may be permanent or transient
IP Multicast(2)Multicast routers handle forwarding of IP multicast datagrams.Host transmits an IP multicast datagram as a local network multicastIf TTL > 1 then multicast router(s) forward it to other networks that have members of the destination group.Attached multicast router completes delivery of the datagram as a local multicast.
SRMALF (Application Level Framing) + LWS (Light-Weight Sessions)ALF: includes application semantics in the design of that application’s protocol.Assumptions made in wb’s reliable multicast design
Data names unique and persistent Source-ID’s are persistent There is no distinction between senders and
receivers IP multicast datagram delivery is available
SRM(2)No requirement for ordered deliveryMost operators are idempotent except some like delete.A receiver uses timestamps on the drawing operations to determine the rendering orderThis captures temporal causality at a level appropriate for the application.
SRM(3)Each member sends periodic session messages. These are required to:
Advertise sequence number of active page for active sources
Determine current participants of the session
Detect lossesEstimate one-way distance between nodes
SRM(4)When Host A detects a loss it schedules a repair request at a random time in future.
When request timer expires A sends a request for missing data and doubles the request timer to wait for the data
When Host B receives a request, makes a randomized wait and multicasts the repair data unless it receives the repair during this period.
SRM(5)Wait periods are randomly chosen from a uniform distribution on an interval.Interval length is dependent on one-way delay and some parametersThese parameters could be chosen based on topology and n/w conditionsPartitioning and normal departure are indistinguishable.No ordering guaranteed.
SRM(6): Extreme Topologies
Deterministic suppression:•exactly one NACK;•exactly one repair.
Probabilistic suppression:•at most g-1 requests•as the length of the interval is increased expected no. of requests decreases but expected delay increases.
SRM(7) Performance much better if local recovery is possible (no need to multicast to everybody).
Solutions:•TTL-based scoping•Separate multicast group for recovery•Administrative scoping
RMTPUses DRs to avoid ACK implosion.
DR caches received data, processes and emits ACKs.
DRs statically chosen for a given multicast session.
RMTP(2)After initial setup sender starts transmitting data.On receiving a data packet receiver starts emitting ACKs at Tack interval.Connection termination is timer basedRetransmission is either unicast or multicast based on the number of errorsLagging receivers can catch up by sending immediate transmission requests
RMTP(3)Window-based flow control mechanism
Ws <= Wr
Senders window advance is determined by the slowest receiverTo avoid redundant transmission ACKs should not be sent frequently. Solution: Measure RTT to AP dynamically.
RMTP(4)Receivers can join any time. Need to buffer entire file during the session. A two-level cache mechanism is used
Experiencing congestion: Decreases congestion window size (to 1 in the worst case). Later increases it linearly.
Receiver dynamically chooses a DR as its AP (least upstream in the multicast tree).
RMTP(5)Session Manager
Detects network partitioning and node crashes and takes necessary actions
Sets the maximum transmission rateProvides sender and receiver with the
required connection parametersChooses DRs
RMTP(6)Scalable because
State information at each node is independent of number of nodes.
Receiver driven approach.Uses DRs to distribute responsibilities of
process ACKs and performing retransmissions.
Reliable delivery not guaranteed when nodes voluntarily or involuntarily leave a multicast group.
PGMWorkable solution for multicast applications with basic reliability requirements!Receiver either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss.No notion of group membership. Members may join and leave anytime.Use NACKs for repair and reliability. But dispense with PACK and use alternate buffer management strategies (like timeouts).
PGM(2)Runs over a datagram multicast protocol like IP multicastSource multicasts sequenced data packets and receivers unicast selective NACKs (repeats until it receives a NCF).
N/W elements forward NAKs hop-by-hop to the source and confirm each hop by multicasting a NCF.Repairs provided by the source or Designated Local Repairer in response to a NAK.
PGM(3)Source path messages (SPMs) are used by a source to establish source path state in n/w elements. This ensures that NAKs returns from a receiver to a source on the reverse of the distribution path.Only one NACK per (receiver, packet) is propagated upwards.Sender or DLR sends RDATA in response to a NACK. RDATA retraces the path of NACKs.