1. On the use of Reliable Multicast for Content Distribution Vassilis Chatzigiannakis vhatzi@noc.ntua.gr

2. 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)

3. A typical CDN

4. The problem Need for inexpensive distribution of data Automated data distribution required Data transfer must be reliable Easy management of replication servers

5. 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.

6. 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

7. Types of Reliable multicast protocols Sender-Initiated Receiver-Initiated Tree-Based Ring-Based Forward Error Correction

8. 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

9. 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

10. 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

11. 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

12. Architecture (3)

13. ADVs cache1.att.sch.gr patch_2342.zip 124132234552 12344123 230.0.0.1/2323 1068799580710 aab464e7ad7029c18a3a6751ce02137d66516e93b24a7f4986132c2b88f8f0d7dd60 c829216aa8b61fe0c68decd5ef9dec8ecba0f9f3d36ad7b81a03e

14. ACKs cache3.thes.sch.gr patch_2342.zip 124132234552 53% 1068799580710 aab464e7ad7029c18a3a6751ce02137d66516e93b24a7f4986 132c2b88f8f0d7dd60c829216aa8b61fe0c68decd5ef9dec8ecba0f9f3d3 6ad7b81a03e

15. 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

16. 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

17. 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

18. 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

19. 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

20. Questions