Transcript Slides - TERENA Networking Conference 2005

On the use of Reliable Multicast for
Content Distribution
Vassilis Chatzigiannakis
[email protected]
Content Distribution Networks




Used for delivering data inexpensively in
terms of network bandwidth
One origin Server
One or more levels of secondary servers
CDNs may operate in two different modes
–
–
content replication (mirrors,rsync)
caching (squid)
A typical CDN
The problem




Need for inexpensive distribution of data
Automated data distribution required
Data transfer must be reliable
Easy management of replication servers
Our Solution



Based on multicast/unicast for the control
and signaling
Based on reliable multicast for the
transmission of data.
Content delivery to the clients is optimized
through a DNS redirection mechanism.
Reliable Multicast


IP Multicast/UDP does not provide reliable
transmission
There are many reliable multicast protocols
depending on specific application
requirements
–
–
–
–
Number of receivers,
Number of senders,
Timely delivery,
Reliable delivery
Types of Reliable multicast protocols


Sender-Initiated
Receiver-Initiated

Tree-Based
Ring-Based

Forward Error Correction

Forward Error Correction




Reliable packet transmission without feedback from
the receivers
Data is divided in logical blocks
Every logical block is divided in N-K packets. The
sender adds K repair packets and transmits N
packets to the receivers
Only N-K packets are needed from the receiver to
successfully reconstruct the original data
Pros and Cons Of FEC
+
No feedback needed from the receivers
+
Great Scalability
-
Sender transmits extra plus traffic
If network conditions deteriorate more than
expected, data may not be reliably delivered
Decoding is computationally heavy, throughput is
worse than in unicast transmission
-
-
Architecture
Server synchronization
 Common multicast group for messaging
 Use of reliable multicast for data distribution
 For every new file uploaded an ADV is
transmitted
 Receivers respond with ACK messages
 When all receivers acknowledge
transmission ends
Architecture (2)



Signaling may be done in unicast as well
All servers are equal (No master). Data may
be uploaded in any of the servers
Deletion of files also possible
Architecture (3)
ADVs
<ADV>
<Server>
cache1.att.sch.gr
</Server>
<File>
<Filename>patch_2342.zip</Filename>
<FileId>124132234552</FileId>
<Bytes>12344123</Bytes>
<MultiCastGroup>230.0.0.1/2323
</MulticastGroup>
<CreationDate>1068799580710</CreationDate>
</File>
<Signature>aab464e7ad7029c18a3a6751ce02137d66516e93b24a7f4986132c2b88f8f0d7dd60
c829216aa8b61fe0c68decd5ef9dec8ecba0f9f3d36ad7b81a03e
</Signature>
</ADV>
ACKs
<ACK>
<Receiver>
cache3.thes.sch.gr
</Receiver >
<File>
<Filename>patch_2342.zip</Filename>
<FileId>124132234552</FileId>
<Progress>53%</Progress>
<CreationDate>1068799580710</CreationDate>
</File>
<Signature>aab464e7ad7029c18a3a6751ce02137d66516e93b24a7f4986
132c2b88f8f0d7dd60c829216aa8b61fe0c68decd5ef9dec8ecba0f9f3d3
6ad7b81a03e
</Signature>
</ACK>
Security Considerations




Secure the CDN against modification of data
and signaling messages.
Use of Anti-spoofing techniques checking the
source IP in multicast packets (ACLs)
Use of digital signatures in ADVs and ACKs
FEC encoding/decoding secures data
against modification
Implementation





The prototype is implemented in JAVA
Installed on fourteen core servers of the EDUNet
infrastructure
EduNet is the Greek scholar network, each school
connects via ADSL or ISDN to the network
(http://www.sch.gr)
The module that handles file transfer is based on
MCLv2.99
DNS redirection is based on BIND Views feature
Implementation (2)
MCL
(http://www.inrialpes.fr/planete/people/roca/mcl/ldpc_infos.html)
 a software library based on ALC and FEC
 provides the API for reliable multicast bulk data
transfers
 C code, connected with JAVA via JNI
Future Work





Examining the possibility of extending
multicast communication to end-user
delivery.
Requires a replication server in each school
PUSH model
Automatic download of patches and
documents
End-to-end availability of multicast required
Conclusions





Decrease of network resource utilization deriving
from the use of multicast
Balanced use of server resources achieved through
DNS redirection
Any server may be used as origin server, there is no
single point of failure
Automated distribution of data
Fool-proof against non-permanent network failure
Questions