reliable multicast irma
TRANSCRIPT
-
8/13/2019 Reliable Multicast IRMA
1/33
IRMA = Illinois Reliable Multicast Architecture
-
8/13/2019 Reliable Multicast IRMA
2/33
Recent years have witnessed a tremendous increase in the use of
commerce, web access, software distribution, multimedia,communication. These a lications re uire reliable data transmission from a
sender to multiple receivers reliable multicast transmission. While it is possible to establish multiple unicast TCP connections
and accomplish such data transmissions between each sender-rece ver pa r, t s approac as two st nct sa vantages: it involves duplicating packet transmissions for connections which may
potentially be able to share common links, and it re uires an a lication-level s nchronization between the sender and
the receiver set.For these reasons, reliable multicast is gaining popularity as ahighly desirable feature of the future Internet.
-
8/13/2019 Reliable Multicast IRMA
3/33
The goal of IRMA is to provide an architecture thatuarantees reliable se uenced and loosel s nchronized
delivery of multicast streams with support for flow control andcongestion control.
us, oes no requ re en os s o ns a newsoftware, the reliable multicast infrastructure makes the
TCP/IP protocol stack at the end hosts believe that thecommunication is unicast, while in fact, multiple receivers canparticipate in the reliable reception of the data.
additional functionality in a subset of the multicast routers inthe multicast tree.
-
8/13/2019 Reliable Multicast IRMA
4/33
Use TCP to provide reliability.
stack at the end hosts. -
routers to implement efficient routing for multicast
packets and ACKs.
-
8/13/2019 Reliable Multicast IRMA
5/33
Authors adopted their approach for three main reasons: ,
congestion control and flow control have already beenextensively studied in the context of unicast TCPcommunication and can be effectivel extended to multicastcommunication.
For practical reasons, widespread deployment of a new protocoltakes time, and requires showing demonstrable robustness ande c ency over a arge set o comp ex scenar os n t e nternet.
Most contemporary approaches treat reliable multicast as aspecialized service which needs to be instantiated in participating
ubiquitous service for a large number of hosts in the Internetmerely by adding functionality to a relatively small subset ofmulticast routers.
-
8/13/2019 Reliable Multicast IRMA
6/33
There are three key issues in supporting reliable multicast:
The semantics of reliable multicast NAK-based versus ACK-based architectures
Loss recovery mechanisms
-
8/13/2019 Reliable Multicast IRMA
7/33
There are three classes of reliable multicast semantics.
tr ct re a ty w t oose sync ron zat on:Data recept on s
synchronized among receivers, the reliability semantics can be end-to-end & the transmission rate of a multicast session is constrained
time. This end-to-end semantics is desirable as it provides better
robustness since it allows for intermediate node failures without.
Partial reliability with loose synchronization: Some applicationssend heterogeneous data traffic with partial reliability requirements
- . ., .In this case, an ideal multicast protocol should ensure that reliable
packets are guaranteed in-sequence delivery, and slow receivers donot stall the entire multicast session.
-
8/13/2019 Reliable Multicast IRMA
8/33
Strict/partial reliability with no synchronization:If theheterogeneity in a multicast group is high, then split-connection semantics
with no synchronization among receivers is suitable. By caching the datastream at some intermediate network nodes, we can also allow late joinrece vers o ca c up rom e s ar o e mu cas sess on as we assupporting split-connection semantics.
T e es gners o IRMA ave c osen t e rst re a ty semant cs(Strict reliability with loose synchronization) in order to supporta lications with stron reliabilit re uirements.
-
8/13/2019 Reliable Multicast IRMA
9/33
Several contemporary approaches have argued for a NAK basedreliabilit scheme with NAK su ression because it avoids the
feedback implosion problem. NAK-based schemes work well if theNAK-channel is reliable, otherwise the NAK-based schemes will not
NAK-based schemes require an infinite buffer at the sender in order toguaran ee correc opera on w e - ase sc emes can guaran eereliable transmission with bounded buffers.
The designers of IRMA have adopted an ACK-based approach inIRMA since they concluded that it is more suitable for the Internetenvironment.
-
8/13/2019 Reliable Multicast IRMA
10/33
How and where does recovery of lost packets take place?
There are three possible solutions depending on who isresponsible for the retransmission:
en er- n t ate sc eme
Local server-initiated scheme
-
-
8/13/2019 Reliable Multicast IRMA
11/33
In sender initiated recovery, ACKs go all the way back
to the sender, which then retransmits the lost packet. In local server initiated recovery, some intermediate
no e n t e mu t cast tree ca e , a repa r server, cac esdata packets, and retransmits packets locally without
.
In receiver-initiated recovery, any receiver who hasreceived and cached a acket can issue a local
retransmission upon hearing a loss notification for thepacket. This option does not work with standard TCP.
-
8/13/2019 Reliable Multicast IRMA
12/33
Sender
Root Router
router index i
Intermediate Router
Leaf Router
User host
host index j
-
8/13/2019 Reliable Multicast IRMA
13/33
Sender
Packet Flow and ACK Aggregation
packetAck
u1 u2 u3 u4 u5
-
8/13/2019 Reliable Multicast IRMA
14/33
Every router i has the following data structures
parent(i) single upstream parent router
ackseq_no(i)ACK seq_no of the slowest child
awnd(i) advertised windowdup_no(i) number of duplicate ACKS
cached_seq(i) used for local repair and is equal to the
cached by router i
-
8/13/2019 Reliable Multicast IRMA
15/33
For every childj of router i, // j belongs to child(i) ackseq_no(j) / last ACK sequence number
dup_no(j) // number of duplicate ACKs
awnd(j) // advertised window
cached_seq(j) // cashed sequence number
ackseq_no(i) = Min{ackseq_no(j)}
awnd(i) = Min{ackseq_no(j)+awnd(j)} - ackseq_no(i)
where j belongs to child(i)
dup_no(i) = Max{dup_no(j) | ackseq_no(j) = ackseq_no(i)} cached_seq = Max{cached_seq(i) , min{cached_seq(j)} }
-
8/13/2019 Reliable Multicast IRMA
16/33
Updating ackseq_no andawnd
Routeri
has four children with the following (ackseq_no , awnd) values
Child 1 (50, 20) ; Child 2(55, 20) ; Child 3 (53,20); Child 4 (54,15)
70
55
53
75
73
54 69
Router i 50 19
ackseq_no of router i is determined by the slowest child and awnd of router i
is determined by the child whose advertised window has the least reach.
ackseq_no(i) = Min{ 50, 55, 53, 54} = 50awnd(i) = Min{70, 75, 73, 69} - 50 = 69 50 = 19
ac seq_no = n ac seq_no c ,
awnd(i) = Min{ackseq_no(j)+awnd(j) | j
child (i)} - ackseq_no(i)
-
8/13/2019 Reliable Multicast IRMA
17/33
Sender
dup_no(i) = Max{dup_no(j) | ackseq_no(j) = ackseq_no(i)}
R
_
is 41 and there are two
children U1 and U2
having the slowest ACK
R41
41
2
sequence num er o .
The dup_no of R5 is the
highest dup_no of the two
children i.e. du no ofackseq_no
ac seq_no
dup_no
R5 R6
2 43
1
_
U2.dup_no
u1 u3 u4 u5u2
41
1
41
2
43
0
44
0
43
1ackseq_nodup_no
-
8/13/2019 Reliable Multicast IRMA
18/33
Multicast packet travels downstream
Sender
R
Source Destination
156.23.1.7 224.17.9.2
R
R5
-
8/13/2019 Reliable Multicast IRMA
19/33
Aggregated ACKs travel upstream
Sender
R
Source Destination
156.23.1.7 224.17.9.2
R
R5
u3 u5u2
Ack AggregationTakes Place
-
8/13/2019 Reliable Multicast IRMA
20/33
Sender
Packet Transmission and ACK Aggregation
-
8/13/2019 Reliable Multicast IRMA
21/33
Sender
State of R5 is
ackseq_no = 41
du no = 1
R
_
Source Destination
156.23.1.7 224.17.9.2
R
41
1ackseq_no
dup_no
R51 43
1
_
dup_no
u1 u3 u4 u5u2
41
1
42
0
43
0
44
0
43
1
ackseq_nodup_no
-
8/13/2019 Reliable Multicast IRMA
22/33
Sender
State of R5 is
ackseq_no = 41
R
_
User U1 sends new ACKackseq_no = 43Source Destination
156.23.1.7 224.17.9.2
R
41
1
ackseq_no
dup_no
R51 43
1
ac seq_no
dup_no
u1 u3 u4 u5u2
43
0
42
0
43
0
44
0
43
1
ackseq_nodup_no
-
8/13/2019 Reliable Multicast IRMA
23/33
Sender
Router R5 updates its state to
ackseq_no = 42
=
R
_
This reflects the new slowest
child U2 Source Destination156.23.1.7 224.17.9.2
R
41
1
ackseq_nodup_no
R50
43
1
_dup_no
u1 u3 u4 u5u2
43
0
42
0
43
0
44
0
43
1
ackseq_nodup_no
-
8/13/2019 Reliable Multicast IRMA
24/33
Sender
Router R3 updates i ts state to
ackseq_no = 42
=
R
_
This reflects the updated state
of the slowest child R5 Source Destination156.23.1.7 224.17.9.2
R
42
0
ackseq_no
dup_no
R50
43
1
_
dup_no
u1 u3 u4 u5u2
43
0
42
0
43
0
44
0
43
1
ackseq_nodup_no
-
8/13/2019 Reliable Multicast IRMA
25/33
As in TCP fast retransmit, if a repair server receives an ACK notificationwith three duplicate ACKs, it will initiate fast retransmit.
However, it also propagates the duplicate ACK count unchanged upstream
because local recovery should not interfere with the fast retransmit/fastrecovery mechanism of the sender TCP (to preserve end-to-end semantics)
There is a problem with the above approach: if there are two repair serversalong a path on the multicast tree, the higher level repair server will always
retransmit packets to the lower level repair server even though the lattersever may a rea y ave e pac e s cac e .
This problem is solved by using two variables in router i: cached_seq(i) is the highest sequence number cached by router i
c _cac e _seqs e owes sequence num er cac e a e su ree o rou er
Router i reports to its parent the maximum of cached_seq(i) andchild_cached_seq.
cac e _seq = ax cac e _seq , m n cac e _seq
-
8/13/2019 Reliable Multicast IRMA
26/33
SenderExample 1:
R
When router R3 sends an ACK
to router R1, it reports thevalue of its cached_seq as 50
R
42
47
ackseq_nocached_seq
R553 50
_cached_seq
u1 u3 u4 u5u2
43
0
42
0
43
0
44
0
43
0
ackseq_nocached_seq
-
8/13/2019 Reliable Multicast IRMA
27/33
SenderExample 2:
R
When router R3 sends an ACK
to router R1, it reports thevalue of its cached_seq as 55
R
42
55
ackseq_nocached_seq
R553 50
_cached_seq
u1 u3 u4 u5u2
43
0
42
0
43
0
44
0
43
0
ackseq_nocached_seq
-
8/13/2019 Reliable Multicast IRMA
28/33
Receiving ACK (src, dest, ackseq_no, awnd, dup_no, cached_seq)
// Update state of child jackseq_no(j) = ACK.ackseq_no; awnd(j) = ACK.awnd
= =_ . _ _ . _
// Update state of router i
Update ackseq_no(i), dup_no(i), awnd(i) // Use equations described earlier
If state of i has chan ed send ACK to arent i
// Perform local repair by fast retransmission of lost packet to child j
If (Repair router & ACK.dup_no == 3 & ACK.cached_seq < ACK.ack_seqno &
cached_seq(i) >= ACK.ackseq_no)
{Retransmit the packet whose sequence no == ACK.ackseq_no}If (Repair router & child j is the slowest child)
{ update cache as appropriate }
-
8/13/2019 Reliable Multicast IRMA
29/33
Reception of ACK (src, dest, ackseq_no, awnd)
// src is and dest is i ACK from host has two arameters
// Update state of child j
If (ACK.ackseq_no == ackseq_no(j)) { dup_no(j)++};elseif (ACK.ackseq_no > ackseq_no(j))
ac seq_no = .ac seq_no, up_no = e se ex nva ;awnd(j) = ACK.awnd;cached_seq(j) = 0; //
// Update state of router iUpdate ackseq_no(i), dup_no(i), awnd(i) // Use equations described earlierIf state of i has changed, send ACK to parent(i)
Note: If the leaf router is a repair router, additional code should be
added to do fast retransmission and cache maintenance if needed.
-
8/13/2019 Reliable Multicast IRMA
30/33
Receiving ACK (src, dest, ackseq_no, awnd, dup_no, cached_seq)
/ src is j and dest is i ; ACK from router j has four parameters
// Update state of child j
ackseq_no(j) = ACK. ackseq_no
awnd(j) = ACK.awnd
dup_no(j) = ACK.dup_no
=_ . _
// Update state of root router i
Update ackseq_no(i), dup_no(i), awnd(i)
If (state of i has changed){send a normal TCP ACK or multiple ACKs to the sender host}
Perform local recover if needed
Note: normal TCP ACK has two parameters: ackseq_no and awnd
-
8/13/2019 Reliable Multicast IRMA
31/33
The senderA with unicast addressa initiates the connection request bysendin a SYN acket with the multicast destination addressm.
The root multicast router in the subnet of A picks up this packet andforwards it to the nodes in the downstream multicast tree.
downstream.
When a leaf multicast router receives the multicast SYN packet, it picks alocall uni ue class E address e then creates a d namic association for
and replaces the source address of the SYN packet,a , with theclass E address e, (i.e., a e ).
Source Destination
=156.23.1.7 m 224.17.9.2
This slide is for information
-
8/13/2019 Reliable Multicast IRMA
32/33
This is required because the leaf router must trap the SYN+ACK responsesrom e rece vers n or er o aggrega e em an orwar e aggrega e
SYN+ACK to the source. The modified SYN packet is locally multicast to all receivers in the
su ne . ac rece ver respon s w a pac e w es na onaddress e.
The SYN+ACK packet gets picked up by the local multicast router, which. .,back up the upstream tree to the root roouter.
The root router then unicasts the packet back to the sender A.
This slide is for information
-
8/13/2019 Reliable Multicast IRMA
33/33
Dynamic Joins: details are given in the paper.
Dynamic Leave: the leaf router removes the receiver from itslocal receiver set. If the local receiver set is now empty, then
.details are given in the paper.