Cost-efficient Content-distribution Techniques in the Internet for Mobile Devices

To view this page ensure that Adobe Flash Player version 9.0.124 or greater is installed.

Please login or register to make a comment!

Ghent University, Dept. of Information Technology 3 Broadband Communication Networks (IBCN) Gaston Crommenlaan 8 bus 201, 9050 Gent davy.dewinter@intec.ugent.be Cost-efficient Content-distribution Techniques in the Internet for Mobile Devices Davy De Winter, Filip De Turck, Joris Moreau, Bart Dhoedt, Piet Demeester Content Distribution Problems in the Internet New emerging technologies such as e-magazines and e- news programs lead to scenarios where a large amount of users want to download the same content in a very small time-window and in a reliable way. Existing server-architectures are not able to cope with this peak-loads in a cost-efficient way.

A thorough evaluation of these traditional architectures proved there is indeed a fundamental scalability problem. Most important metrics are the maximum number of requests/sec that can be handled and the time to download the content. Cost-efficient content-distribution techniques Scheduled off-peak download Reliable Multicast content distribution cFair d Peer to peer content distribution The main problem with classic architectures is the unicast- nature: there exists a one-to-one relationship between sender and receiver.

If there are 50000 users, the same content has to be sent 50000 times leading to high upload bandwidth requirements. With multicast, the content has to be injected only once in the network and it is ... more. less.

spread to all receivers that are interested. Currently IP-multicast is mostly used to spread streaming video content. Small packet losses are not problematic in such scenarios. File transfer however requires reliability, otherwise the file will be unusable. T est be d We are developing a multicast- architecture (connecting multicast- aware networks islands over the internet (layer 3)) with open-source flute implementations (layer 4 to 7) They add reliability to streams using error correction codes to cope with small packet losses. To handle late arrivals and large packet losses, the file can be continuously sent in a carrousel- mode. Making sure slow receivers are not a bottleneck for fast ones, the same data can be sent on different logical tunnels. A fast receiver can join multiple channels in order to re-assemble the file faster. These options are currently investigated and evaluated. Single Server Load-balancing Low request rate High delays Large Infrastructure costs We have evaluated webserver performance using Avalanche- emulators and Optiview- equipment to emulate a certain number of (HTTP or HTTPS) requests/sec. The delay and maximum number of requests/sec are influenced by the encryption- ciphersuite, the file size and access-network bandwidth. FileSize - SimUsers/sec - CPU Load 0 20 40 60 80 100 120 140 250KB 500KB 1MB 2MB 4MB 8MB FileSize SimUsers/sec (10 x) CPU Load(%) BW Unlimited CPU Load(%) BW ADSL Max. SimUsers/sec (x10) BW Unlimited Max. SimUsers/sec (x10) BW ADSL SimUsers/sec - Access Network BW 0 20 40 60 80 100 120 140 160 15 Mbit/s 1.5 Mbit/s 0.768 Mbit/s 0.384 Mbit/s 0.128 Mbit/s Access Network Bandwidth SimUsers/sec No Encryption EXP-RC4-MD5 DES-CBC-SHA DES-CBC3-SHA Relationship SimUsers/sec - # of servers 1 10 100 1000 10000 100000 1000000 100 200 400 800 1600 3200 6400 12800 25600 51200 SimUsers/sec # of servers 15 Mbit/s BW - No encryption (100 SimUsers/sec per server) 15 Mbit/s BW - EXP-RC4-MD5 (50 SimUsers/sec per server) 15 Mbit/s BW - DES-CBC-SHA (20 SimUsers/sec per server) 15 Mbit/s BW - DES-CBC3-SHA (20 SimUsers/sec per server) 1.5 Mbit/s BW - No encryption (70 SimUsers/sec per server) 1.5 Mbit/s BW - EXP-RC4-MD5 (40 SimUsers/sec per server) 1.5 Mbit/s BW - DES-CBC-SHA (20 SimUsers/sec per server) 1.5 Mbit/s BW - DES-CBC3-SHA (10 SimUsers/sec per server) The simplest option consists of a scheduled download- schema during off-peak moments (e.g. during the night). User devices poll the central server infrastructure and can start downloading the content, or they can receive a schedule for the next request attempt if no slots are available. Central Chord Ring With cSuperNodes d SuperNode Content part1 Content part2 Central Administration Node Finger Table Local Nodes Lookup Table Lookups Multiple Chord Rings In the second (more distributed) peer to peer solution, hosts are arranged in a Chord-ring. Due to consistent hashing, all pieces of the content are evenly distributed under participating nodes. In contrast with the original Chord, hosts are treated like content and vice versa, because the number of nodes is much higher than the number of files in this scenario The first peer to peer solution is a Napster-like model. New nodes joining the network have to download a piece of the content from other peers. A new node gets the addresses from a central server which keeps the other peers in a client queue. Once download traffic equals upload traffic, a peer leaves the client queue.

less