Tuesday, December 10, 2013

CoNEXT 2013 Student Workshop: Content

A study on cache suppression control according to content popularity for in-network guidance 
Hiroki Kawabata (Graduate School of System Informatics, Kobe University), Takaki Onizuka (Kobe University), Yumi Takaki (Graduate School of System Informatics, Kobe University), Chikara Ohata (Graduate School of System Informatics, Kobe University), Hisashi Tamaki (Graduate School of System Informatics, Kobe University)

The increase of large size of content leads to heavy content server loads and large amount of core network traffic. Content oriented network allows for in-network caching so there is efficient content delivery with caches. In previous work Mapping Server with Cache-location Resolution (MSCR) resolves the content server location and PCLs.

MSRC with cache suppression. Content popularity follows the Zipf-Mandelbrot distribution where the number of caches in the network follows almost the same distribution. When there is excess cache duplication this can be used to suppress cache creation. MSCR with Cache Suppression (MSCR/CS) controls cache creation according to popularity. The cache creation is has a control decision to determine whether to create the cache.

The popularity rank i is correlated according to the cache creation ratio of the Zipf-Mandlebrot. For the simulation settings, a 3 tier network topology with 50 content servers at the tier-3 domain, 913 users connected to a 3-tier router. There are a total of 10,000 files.

Proposed MSRC/CS supressing unnecesary cache creation. Eliminates excess cache duplication of high popular contents and cache duplication of low popular contents.




Content and Buffer Aware Scheduling for Video Delivery over LTE 
Ahmed Ahmedin (University of California, Davis), Kartik Pandit (University of California, Davis), Dipak Ghosal (University of California, Davis), Amitabha Ghosh (UtopiaCompression Corporation)

Addressing scaling video over LTE. Phones are used more than calls and video streaming is very important. Video scheduler problem where eNodeB has many nodes requesting video from it. All the clients are competing over resource M. All clients want streaming and high quality video. Scheduler should assign the resources to each user. The existing schedulers don't consider content.

Current schedulers for video streaming congestion occurs when all UEs request high quality videos. All the videos are treated equally and weak CQI users consumes higher resources to get same rate. No resources leads to buffer underflow and video freeze. Current downlink schedulers to not take UE buffer status into consideration.

H264 SVC scalable video coding uses a base layer and enhancement layer. More layers needs more bandwidth.

The PRB scheduler decides the profile level and the number of PRBs to be assigned to each user based on the UE’s
decoding capability, its buffer state, available number of PRBs, and link quality. The goal is to maximize the average video quality across all users, which we formulate as an integer linear program (ILP).

Content and buffer aware scheduler. Assign resources based on the content, buffered data, service type, and the required quality. The benefits are efficient resources utilization. The scehduler decides the profile level of the video that should be transmitted to every UE.

Future work is to apply to SDN.




A Selective Caching Scheme Based on Request History in Content-Centric Networks 
Takahiro Kawano (University of Kitakyushu), Masayoshi Shimamura (Tokyo Institute of Technology), Hiroyuki Koga (University of Kitakyushu)

Content-Centric Networks (CCNs) promise to deliver content in a better way than today’s Internet. In CCNs, efficient content delivery services can be achieved by using cache storage on routers. However, an effective caching scheme in CCNs is never established, because the communication
method in CCNs differs from that in traditional networks.

Content delivery over the network has been growing steadily. Content is segmented into multiple chunks which have a content identifier. Content routers can cache chunks in the content store when they are forwarded. Content can be effectively received from cached chunks on content routers (CRs). CRs decide algorithms for caching. An effective caching scheme is required. Traditional LRU can be used.

Problems on cache discard algorithms in CCN is that cache discard based usage staistics can't work well. Reduce time to receive content by selectively sorting the cache. The commonly used caching scheme is the Least Recently Used (LRU) algorithm where the least recently used data
is discarded when new data is received. However, if the number of forwarded chunks exceeds the CS capacity, the frequent cache updates of CS will decrease how much information can be used from stored chunks.


The proposed scheme uses the received history of request packets on CR to determine the CLN. Specifically, CR calculates the exponentially weighted moving average (EWMA) Ec of the number of received requests Rc for the chunk c. The weighted average is calculated to adapt to changes in content popularity.

If the threshold N to store the received chunk is equal to the CS capacity, the CS utilization efficiency will be good. This is because all of the CUNs can be stored in CS. That is, a stored chunk x with large Ex will not be discarded to store another received chunk y with small Ey in the cache update process.


The proposed scheme reduces the average number of hops compared to the traditional scheme which stores all of the forwarded chunks on CRs [1] over a wide range of the total number of chunks. This is because the proposed scheme can suppress unnecessary cache updates by not storing CLNs.






A Push-Enabling Scheme for Live Streaming System in Content-Centric Networking 
Kwangsoo Kim (Ajou University), Seungoh Choi (Ajou University), Seongmin Kim (Ajou University), Byeong-hee Roh (Ajou University)

Content-Centric Networking (CCN) is a promising candidate for Future Internet architecture. This pulling-based networking scheme has a weakness about live streaming due to their request method, which means every segment of contents should be requested by Interest, respectively and consequently. We propose an enabling scheme for push mechanism to CCN to overcome the ineffectiveness. Push Interest, which is not removed after delivering the segment, needs to be added to the network design.


Pushing is fundamentally blocks need to do a 3-way handshake. Need to migrate IP push to CCN and pushing is necessary condition in CCN.

In CCN, media file is divided into several segments where lots of packets should be generated. Works for streaming as seen in VoCCN whcih uses pipeline for efficiency.

Concept of channel where Persistent Interest (PI) makes a tree for ceertain content and the PI is not removed after matched data was forwarded to provide push service.

Propose push request , push confirm, push confirm, push interest, pushed data. Server sends push confim data. For the push interest, it is not removed when data is forwarded through the router. Push prefix indicating confirmed path and push req interst convering to push interest.  All keywords are placed before the content name. Push enabler packets with prefixes where the push confirm consumes push request and makes push interest.

Push association using push-enabler packet. Prevents malicious users from misusing the tree.








Q: Measuring cache popularity based on history, when you measure the popularity now though maybe its not anymore. Didn't consider the overhead of the history metadata. Maybe should increase the size of the memory or the LRU size.

A: MSRC is implemented in the domain web apps. So memory size can be solvable and there is also a distributed MSRC. Individual router case is not considered.

Q: Zipf is being used, though workload is different based on the routers. Edge router follows zipf. After edge routers, the distribution will not zipf though its not correct. Workload will be different from edge routers and the other routers.

A: N/A

Q: Why not sample requests to improve the LRU?

A: N/A

Q: Required coordination between network operators and providers, though they are two different entities. How to tradeoff between what is important from a business standpoint?

A: Use existing what is on the network. Youtube already has the different encodings. Network just needs quality for each layer. Don't need to know the name of the movies, just need the quality level. Server sends the table to the user, so the user forwards over the network. So protected by the network provider. Has to be application layer and work with network operator. Currently working with ATT.

Q: Rely on content provider to say what is required?

A: Rely on content provider for the response of the quality number.

Q: Why wouldn't the content provider lie?

A: Still prototype.



No comments:

Post a Comment