CoNEXT 2013 Student Workshop: Datacenter — Virtual Network Session

Traffic pattern based Virtual Network Embedding 

Authors: Andreas Blenk (Institute for Communication Networks, Technische Universität München, Germany), Wolfgang Kellerer (Institute for Communication Networks, Technische Universität München, Germany)

Presenter: Andreas Blenk

The paper focuses mainly on Virtual Network Embedding algorithms for Virtual Networks whose demand is changing according to the traffic patterns in order to provide high performance and resource efficiency.

Existing works try to optimise the embedding for load and reconfigurations while assuming that the demands of the virtual networks are fixed.  We propose a VNE algorithm based on Mixed Integer Linear Programming that looks ahead and finds a balance between an instantaneously optimal embedding and cost caused by future reconfigurations. The algorithm assumes that the changes of future virtual network demands are predictable as they may reoccur on a regular basis.

They conducted simulations with randomly varying number of nodes for the Poland IP network. They compare the results for three VNE scenarios namely, (1) pure load balancing, (2) consider load balancing and reconfigurations, and (3) consider load balancing, reconfigurations and traffic patterns.  Their results show that considering trafficc patterns decreases migrations while it does not diminish the link utilisation. Consequently, VNE algorithms should consider the trade of between migrations and utilization according to the impact of reconfigurations.

Q: What is the scalability of the network of MILP?

A: It's not very high, need some heuristics for larger networks

Q: What rate of changes that can be accommodated by the proposed mechanism?

A: depends on size of virtual networks, 

Q: Is exploiting diurnal trend for prediction a viable solution?

A: It's part of future work, can use machine learning

Virtualizing National Broadband Access Infrastructure 

Authors: Hassan Habibi Gharakheili (University of New South Wales), Vijay Sivaraman (University of New South Wales)

Presenter: Vijay Sivaraman

The authors of the paper focus on National Broadband Network of Australia which aims to provide 100 Mbps to over 93% of households in the country and considered the issue of virtualising and sharing the physical public network. The public network differs from a private network in the following ways: (1)It provides only wholesale  connectivity (layer-2 circuits) and Retail Service Provider (RSP) offers layer 3 services to the end users, and (2) allows the end user to have multiple RSPs per household. So the challenge here is finding the right set of interfaces in between the three entities namely Infrastructure operator, end users and RSPs to facilitate virtualisation and sharing .

The Benefits of virtualisation are as follows:

RSPs:

• Better performance
• dynamic capacity planing
• pay-as-you go dynamic provisioning

End-User: 

• several RSPs per household
• several services at lower unbundled cost
• customise the quality

Infrastructure Operatior: 

• More efficient usage of network resources

The authors perform a simulation study based on the data they collected from UNSW wifi network with 30 Access Points and 8500 user sessions in total. In this study they evaluated fraction of unhappy user sessions and cost saving per RSP. Their preliminary results show that virtualisation reduces the RSP cost by 70% while allowing to have 90% happy sessions. The results also indicate that it needs time scale and bandwidth granularity tuning.

Q: As a user, is it a layer-2 or layer-3 virtualisation?

A: Layer 2 ,Each user will get a VLAN and they will run their web related services on top of it.

Q: Does NBN support mobility?

A: At the current stage it doesn't offer any mobility. 

Q: RSP will save money, what is the incentive for NBN?

A: It's difficult to say unless we have a pricing model in place

Q: What happens if there is a competition in between RSPs?

A: It based on pricing model

Q: How do you see users paying for different RSPs?

A: Currently it's payable for a single RSP, but for multiple RSPs it may be, line rental (base price) + usage (quota).

Or else we can have a broker in the middle, who can aggregate the RSPs, do the slicing and billing

Q: Would the service provider takes up this model, if so far the model is only used in Australia?

A: It would be good to experiment in one country to see how it works if content providers directly deals with the customer and then deploy in other countries as well.

Q: Any difference between SDN and broadband networks?

A: Completely different, when SDN is used in data centre under your control, but in Broadband Networks, there are three entities (RSP, users and government) and we have to come up with the right set of interfaces.

Towards Impactful Routing Research: Running Your Own (Emulated) AS on the (Real) Internet 

Authors: Brandon Schlinker (University of Southern California), Kyriakos Zarifis (University of Southern California), Italo Cunha (Universidade Federal de Minas Gerais), Nick Feamster (Georgia Institute of Technology), Ethan Katz-Bassett (University of Southern California), Minlan Yu (University of Southern California)

Presenter: Brandon Schlinker

The authors propose a testbed for use by operators and re- searchers wishing to examine the characteristics of inter- domain routing schemes.

The testbed also allows the emulated networks to advertise routes and exchange traffic with the real Internet. The testbed enables experiments to have complete control over the network topology. In addition, experiments can exchange routes and traffic with ISPs in multiple peering locations across the Internet, enabling experiments which emulate complex, geographically distributed networks.

The testbed provides operators and researchers with the ability to easily emulate complex autonomous system topologies while facilitating the exchange of routes and traffic with peers in Internet eXchange Points (IXPs) around the world. Thus, the testbed enables even a large ISP to emulate all aspects of their network infrastructure, including the complexities of their peering policies.

Q: Have you considered any adversarial model?

A: Consider route flapping, doesn't impact the proposed mechanism. Consider prefix hijacking,  which BGP is designed to withstand.

Q: Can you measure paths to the emulated network?

A: It's possible to perform. 

Q:  You considered multiple private AS in one Mininet, can you put it in different machines?

A: Yes, by advertising prefixes into BGP multiplexers

Q: If you want to work with BGP, you don't have much freedom to change, what do you think about it?

A: True, We have to deal with how to have different scenarios

Q: What sort of usage model can be used?

A: provide more resources to gain more

Parallel Routing on Multi-Core Routers for Big Data Transfer 

Authors: Ahmet Soran (University of Nevada Reno), Furkan Mustafa Akdemir (Bilkent University), Murat Yuksel (University of Nevada Reno)

Presenter: Ahmet Soran

The authors considered big-data is being transferred and address the issue of using multi-core routers effectively and efficient to route such transfers. The authors propose a parallel routing architecture that explicitly considers multi-core routers and employs shortest-path calculations. The basic idea is to virtually slice the router topology into and assign them to a separate router core, which calculates a shortest path on the assigned slice.

The design goal of parallel routing is to generate virtual slices that yield the most diverse and non-overlapping shortest paths possible. The authors try Graph based and Flow based approaches in their simulation study and and evaluated the heuristics on the Sprintlink topology of the Rocketfuel dataset. They test their heuristics against the ground truth, namely single shortest path case. Their preliminary results show that  parallel routing heuristics achieve higher throughput against the single core routing. 

Q: What sort of challenges on parallelising path routers?

A: transforming parallelisation into 2 different problems, 1) slicing and 2) load balancing

Q: Will the data from the same flow be split?

A: Yes

Q: Have you talked to Network Operators to get an idea of multi-core routers?

A: Yes, we are planing to run experiments in their network.

Q: You used Rocketfuel Topology which is not accurate, what is your comment?

A: Parallel routing perform better

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.

CoNext HotMiddlebox: Analysis and Topology-based Traversal of Cascaded Large Scale NATs

Andreas Müller, Florian Wohlfart, and Georg Carle (TU Munich)

Presenter: Andreas Müller

There is no more free /8 block in IPv4. What can we do until IPv6 take over ? Large scale NAT deployment is a solution. Problem for ISPs, they run out of addresses but they have to still provide access to IPv4 content as well as the new IPv6 content. Operators deploy cascaded NATs to use private IP addresses between the CPE and the Large Scale NAT in the operator’s network. Another solution also exists where only one NAT is used in the operator network.

The goal of the paper is to detect such cascade NATs. Control based solution like UPnP are not an option when you have multiple levels of NAT so a behavior-based solution (Hole punching) has a higher success rate but is difficult to apply with cascaded NAT at the provider.

Main goals:

- Learn about LSN deployment, find an algorithm to detect stateful middleboxes on the path

- Improve LSN traversal by using those informations

The main contribution of the paper is the LSN discovery algorithm based on a software deployed in the client and the server, treating the intermediates nodes (the topology) as a blackbox.

The algorithm is roughly as follows (more detailed in the paper):

- establish multiple mappings (UDP)

- traceroute to count #hops

- remove mapping: UDP: timeout, TCP: RST.

- count number of hops and detect stateful middleboxes

- Iterate until reach all hops on the path.

The authors implemented a UDP-based algorithm (NAT-analyzer) and asked people to run from various type of networks. Over 4810 tested connections, 93% completed all the general tests where 53% completed the new topology analysis algorithm.

Results for UPnP:

- 30% of the tested hosts had UPnP enabled;

- in 26.5% of these connections there is a difference between the UPnP IP address and the public address (LSN ?);

- Stange: public IP address used by UPnP maybe due to a HTTP proxy (not sure)?

- Cascade NAT in operators are mainly present in LTE networks (~50% of the 1% cases);

The presenter showed some results using the algorithm based on hole punching. There were some issues due to operators blocking ICMP (40% in DSL).

As a conclusion, LSN as one way for the transition to IPv6 but it breaks existing traversal solutions.

Q: What was the largest number of NATs ?

A: Around 5 (not sure). Maybe due to biased results that were difficult to understand.

Q: Have you found middleboxes that would break the TTL ?

A: there are middleboxes that just doesn’t decrement the TTL

Q: How you do when timeout are differents on cascade NAT.

A: send probe from server to client with a TTL.

Q: Did you find any pooling, with nat and some path that appeared and disappeared

A: No.

CoNext HotMiddlebox: Are TCP Extensions Middlebox-proof?

Benjamin Hesmans, Fabien Duchene, Christoph Paasch, Gregory Detal, and Olivier Bonaventure (Universite catholique de Louvain)

Presenter: Benjamin Hesmans

The end to end principle does not work anymore, a middlebox will probably modify your segments. As a study conducted by J. Cherry shows, in today’s networks middleboxes are highly present especially in enterprise networks where there is as much middleboxes as routers or switches. By modifying the content of the packet, middleboxes can impact performances. The paper propose to evaluate the impact of middleboxes on TCP extensions’ performances.

The proposed methodology is cyclic and is bootstrapped from existing middleboxes in the literature. The main part of the methodology is to run TCP extensions against modelled middleboxes. To do this, the authors propose MBtest, which is a netkit (UML) based tool, composed of click elements modeling some middleboxes behaviors. The author show an example where he modeled a middlebox that randomize the TCP sequence numbers but not the sequence number present in the Selective Acknowledgment (SACK) option. Such middlebox has an important impact on the goodput of applications: with SACK the performances are worse than without which is counter intuitive.

The authors also evaluate the behavior of MPTCP which is the first extension designed with middleboxes in mind. They evaluate if MPTCP in different scenarios: NAT, remove option, randomization of the TCP sequence number, segment splitting and coalescing. In most cases, MPTCP works (It sometimes fallback which is normal). Only one corner case. The author also show a case, detect by deploying MPTCP on the wild, where FTP in active mode cause a fallback and adds a large delay.

Lessons learned:

- TCP options can not assume that the TCP header fields are unchanged during transit

- TCP options cannot assume that an option sent is always received

- Payload size modification is unsafe

Questions:

Q: The UCL had a measurement study, where TCP breaks in the wild (Is it Still Possible to Extend TCP? at IMC). Are the measurement conclusion the same?

A: The paper is more focused on MPTCP and based on modeled middleboxes.

Q: Are you planning to extend to more protocols or more middleboxes ?

A: New protocols is easy. For middleboxes we don’t know yet if we will pursue the work.

CoNEXT HotMiddlebox: SymNet: Static Checking for Stateful Networks

Authors: Radu Stonescu, Matei Popovici, Lorina Negreanu, and Costin Raiciu

Presenter: Radu Stonescu

Middleboxes are everywhere, NFV, In-Networking Processing,... So, reasoning about the network behavior is increasingly difficult.

SymNET answers the question, on on how the packet will be forwarded and which and how the header-fields will change through symbolic execution.
SymNET takes click-configurations as input, parses the click-config and generates a network model. Finally this can then be analyzed.

Conclusion:
SymNET can analyze stateful network, do reachability tests and loop detection.


Q: What does a "flag" mean? Is it inside the packet-header or only part of SymNET?
A: SymNET is modelling a set of values, and these "flags" are inside SymNET on a per-packet basis.

Q: Does the firewall has to communicate with SymNET?
A: SymNET has to know exactly what the firewall does. The firewall's behavior is completly known a-priori.

Q: What about asymmetric paths?
A: That's not an issue for SymNET, it can handle asymmetric paths.

Q: Can this model a caching proxy?
A: SymNET assumes that two flows are independent, so this would not be possible with a caching proxy.

CoNEXT'13 Student workshop: Best Paper Session

ndn||mem an Architecture to Alleviate the Memory Bottleneck for Named Data Networking

Authors: M. Rezazad,Y.C. Tay

Presenter: M. Rezazad

This paper proposes a new architecture for NDN to alleviate the performance bottleneck caused by the high usage of memory in NDN architecture. 

In NDN, the name represents the content instead of the location of the data source, and the application basically follows the publish/subscribe paradigm. The contents are cached in the routers. In this architecture, the main concern is that since high speed memory is not affordable yet, the content searching may slow down the overall system performance. 

The authors propose four ideas to reduce the problem. First, parallel search in FIB and PIT. Second, under the assumption that FIB is a big slow memory, the routing information of the first data chunks can be cached in FIBcache for the later interests to use. Third, under the assumption that data chunks are likely to physically reside on the same node, if the previous chunk is not found in the CS, the following interests can skip the CS search step. Finally, the authors change the content caching policy (CCNdn) to only caching part of a file in a file at each router along the path. Since the head of a file is assumed more popular than the tail, it is suggested the head is saved at routers closer to the requester.

The new architecture is evaluated through simulations and the results show that the proposed architecture is more scalable in terms of memory search compared to the current NDN architectures.

Q: How do you debug NDN network?

A: This is an open issue. Currently there is no device for that.

Q: can we assume the content is in one server? (replication of data) what if there are multiple servers? How do we decide number of hops? 

A: It is the routing algorithm problem. In NDN it is assumed the packet will be forwarded to the shortest path resource. After the search the path can be used by another interest. 

Q: do you support content replication at all?

A: content replication is for CDN. 

Don't Trust Traceroute (Completely) 

Authors: Pietro Marchetta, Valerio Persico, Ethan Katz-Bassett, Antonio Pescapè

Presenter: P. Marchetta

The main message of this paper is not to trust Traceroute. The presenter first introduced the basic concept of Traceroute. Traceroute currently has many limitations, such as its capability of detecting anonymous, hidden routers, and also its probing overhead. In this paper, the authors focuses on the problem at IP level view.

The major problem is that Traceroute discovers "interfaces" rather than "routers". Because of that, in practive Traceroute may detect false path changes. The presenter showed an example where Traceroute reports a path change at second hop while it turns out only the interface is changed on the same router. In the evaluation using 721k paths, it is found that 32% of the paths have not changed at the IP level while Traceroute reported path changes.

Another problem is the load-balanced path over estimation. Routers may split the traffic in different paths. That is, multiple IP level paths may be identified by Traceroute even though the forwarding path is the same.

Q: Are you building on top of Traceroute?

CoNEXT 2013 Student Workshop: Mobile and Apps Session

Leveraging Diversity to Optimize Performance in Mobile Networks

Author: M. Zubair Shafiq

Presenter: M. Zubair Shafiq

Mobile data traffic volume increases rapidly due to the increase in the subscriber base, improving network connection speed and improving capabilities of modern smartphone. The paper show how mobile network operators can leverage the device diversity and geospatial diversity to improve performance (traffic models and radio resource allocations). 

Firstly network operators can improve the performance by tuning Radio Resource Control (RRC) state machine inactivity timers for cell sectors with distinct traffic profiles. For example, more efficient radio resource utilization can be achieved by reducing RRC inactivity timers in cell sectors belonging to delay tolerant applications. These ideas are validated by conducting trace-driven simulations of users's RRC state machine using the logs collected at the radio network controllers from an operational mobile network. The result shows 1-2 seconds shorter RRC timeouts. Secondly, network operators can customize the workload models for mobile video streaming for different device types to improve these models. To do this, the author clusters similar devices type together and refine models for individual devices. 

Q&A session

Q: What is the traffic characteristics? And what type of user traffic?

A: The traffic is during the day social networking and considered both upload and download.

Q: How do you obtain the experiments?

A: The data is collected near a big stadium, hence there are many users when there is an event and lower number of users otherwise.

Q: What if we increase timeout value?

A: It can increase the performance but only for small population.

Q: How is the timeout tradeoff in term of promotion delay?

A: Optimal tradeoff for promotion delay is with lower timeout.

Exposing and Mitigating Privacy Loss in Crowdsourced Survey Platforms

Authors: Thivya Kandappu, Vijay Sivaraman, Arik Friedman and Roksana Boreli

Presenter: Thivya Kandappu

Existing crowdsourcing survey platforms can profile users based on the surveys that they participate in. First, the work demonstrates that de-anoymizing users and obtain sensitive private information can be done easily using crowdsourcing survey platforms. Second, the authors design, prototype and evaluate Loki, a crowdsourcing survey platform that allow users to control their privacy loss using at-source obfuscation.

The authors demonstrate that de-anonymize users of crowd sourcing survey platforms is easy by launching a series of surveys in Amazon Mechanical Turk. The first three surveys allows the authors to obtain different information from the surveys. The authors can de-anonymize 72 out of 400 users. Using a fourth survey which discusses the smoking habit, the authors can infer the respiratory health of 18 out of 72 de-anonymize users. In the fifth survey, which asked whether the users would participate in the surveys if they knew that they could be profiled. 73 out of 100 users that took this survey indicated that they would not participate if they knew that they can be profiled.

Loki obfuscate the user's true response according to the privacy setting that the user chooses. The authors performed a preliminary evaluations by trialling the system with 131 volunteers. By comparing the results with a trusted third party and  by comparing the ratings across the various privacy bins in the system, the authors show that the error is sufficiently small to make inferences even with a relatively small sample size.

Q&A session

Q: If you obfuscate the data, can you trust the data obtained?

A: The idea is to try to maintain the average of the aggregated value, such that the data obtained is still relevant.

A Base Station Congestion-Dependent Pricing Scheme for Cellular Data Network 

Authors: Agripino Gabriel M. Damasceno, Raquel Aparecida de Freitas Mini, Humberto Torres Marques-Neto

Presenter: Agripino Gabriel M. Damascenon

Time-based pricing scheme can be used to improve the management of the resources even with the increasing mobile Internet traffic generated in cellular networks. However, time-based pricing can be unfair to the users outside the congestion areas during network peak periods, where different base station have different workload. The paper presents a pricing scheme that use base stations' historical workload and the constant monitoring of users' sensitivity to applied prices to differentiate pricing to control the geographical congestion in the ISP network. 

The scheme uses several thresholds to determine the price. As a part of the ongoing work, the authors are simulating the proposed pricing scheme. The preliminary results show that the the scheme is able to reduce the utilisation in the peak time and hence make the network is more profitable in off peak.

Q&A session

Q: What is the pricing model?

A: Incentive-based pricing model.

Linearly Scalable Crowdsourced Media Broadcasting in the Mobile Cloud 

Authors: Joshua Joy, Nagendra Babu, Christine Kuo, Hiral Kapadia, Mario Gerla

Presenter: Joshua Joy

The volume of data, especially images, increases as users are constantly capturing and sharing images on their mobile devices. Deduplication is a compression technique which eliminate duplicate copies of repeating data, by storing redundant data only once. However, deduplication does not work on images. The authors introduce storage mechanism to achieve deduplication for similar images with different screen size and resolution to address the demands of increased image sharing in the mobile cloud (e.g.,  vehicular cloud). 

The mechanism stores the original image and calculate the transform to similar images and enable on-demand image transformation using lineage tree of meta-file, which stores the different version and image resolutions. When comparing the proposed storage utilization results with the results from opendedup, a file system that performs in-line block-level reduplication, the authors found that the proposed solution outperforms opendedup when 90% of the images to be stored can be generated by the files already in the system. In addition the proposed mechanism runs faster than opendedup when storing multiple similar images since the proposed mechanism only transfer meta-files.

Q&A session

Q: Can you give more detail about the mechanism?

A: Performing deduplication of images is a search problem.

Q: How heavy is proposed deduplication process?

A: The proposed deduplication is not as heavy as opendedup.

Q: What kind of traffic? Upload or download?

A: The focus is on download.

Q: What happen when we have multiple users?

A: It's a part of future works.

CoNext13 Student Workshop. Best Papers Session

ndn||mem an Architecture to Alleviate the Memory Bottleneck for Named Data Networking
Authors: M. Rezazad,Y.C. Tay

Presenter: M. Rezazad

New memory architecture for NDN (Name Data Networking), which is one of the candidate for future internet architectures. The presenter first gave brief overview of the NDN including main concepts such as name for content rather than location of the content, publish/subscribe phenomena and caching content in the routers.

The main goal of this work is to improve memory search delay as it is one of the major concerns of the current NDN architecture. The authors propose four stage strategies under their new memory architecture.

1. Parallel search - in FIB (Forwarding Interest Base) and PIT (Pending Interest Table) tables
2. FIBcache - Routing information of the interest of the first data chunks can be used for the rest of the chunks by caching them in FIB and PIT.
3. Bypass CS - If data n is found in the CS table, it is likely data n+1 can be found there. Therefore, it is possible to bypass CS by using hop distance
4. Content Caching Policy (CCndn) - Cache only part of a file in a router by segmenting file in pieces and distribute pieces along the path.

The authors have evaluated this through simulations and showed that the proposed architecture can tolerate more traffic due to the time saved during the memory search compared to the standard NDN architectures.

Q: Is it possible to apply Traceroute in NDN context?

A: In NDN,  location is not important, I can’t see why the finding location is important and the authors explains basics about NDN.

Q: Related to the same question, How do you debug NDN network? 

A: This is not a finished research I would say. Parc institute adding some algorithms to do similar kind of analysis.

Q: A question about replication of content in routers in NDN. Do we need to research all routers to get one content? 

A: It is a problem of the routing algorithms, and the author explained how NDN routing works. CDN makes content localised and it is different from content caching in NDN.

 Don't Trust Traceroute (Completely) 

Authors: Pietro Marchetta, Valerio Persico, Ethan Katz-Bassett, Antonio Pescapè

Presenter: P. Marchetta

The message of this paper is not to trust Traceroute too much. The presenter gave an introduction to the trace route protocol and its practical utility followed by its limitations and mainly focused on limitations on IP level-view. Traceroute is designed in such a way that it detects interfaces rather than actual routers, which creates two main limitations.

• False path changes - detect interface changes as path changes

This scenario has been evaluated using 721k paths collected by 4 PlanetLab nodes for 2 days. The most interesting finding was that 32% of the paths changed at the IP level.

• Load-balanced path over estimation

Routers usually split the traffic in different paths. Sometimes, even though the forwarding path is the same, Traceroute suggests multiple forwarding packets. From the same data set, the authors show that 14% of the routes with multiple IP level paths identified by the Traceroute turned out to be unique paths.Then the presenter explained how this is possible. Tracroute may report outgoing interface according to the RFC. 

Finally, the presenter conclude with set of future work highlighting that this is early stage research. Some future work are What is the actual magnitude of the phenomenon?, analysing wider data set, revisiting stability, etc..

Q: Your analysis are based on alias level - How do you mange error?

We had limitations of coverage, accuracy and also it was not possible to apply to a large scale. We applied the used techniques several times to remove as much as false positives. However, still there might be some errors.

Q:xx

A: Explain about the behaviour of false multiple path detection.

Q: Who are the primary stake holders? Are you building on top of Traceroute?

A: xx

CoNext HotMiddlebox: FlowOS: A Flow-based Platform for Middleboxes

Mehdi Bezahaf, Abdul Alim, Laurent Mathy

Presenter: Laurent Mathy

We have middleboxes everywhere. Many of them of proprietary and difficult to upgrade. The problem of focus is here can we just expose substreams of flows and get a high level abstraction of traffic for programming and management purposes. 

bytestreams are IP bytes, a TCP byestream is just IP payload and similarly app streams only include tcp part. the goal is to get these abstraction and simplify building of middlebox functionalities. We should do so without copying data, deal with packet reordering and packet loss and duplicate packets. The module should be processing a flow sequentially and concurrently We need support flow migration and support for inter process communication. A stream is a sequence of bytes such as application data of a connection. The architecture deploys a processing routine for each NIC. In input processing we would like to handle packet reordering effects. After decoding packets we will have virtual byte streams. FlowOS packets encapsulate protocol effects. Stream Pointer APIs enables us not to deal with details of sk_buff and be agnostic to that. 

Middleboxes are run as a thread of a kernel module. Only read-only processig modules are allowed to process a flow concurrently. This makes synchronization simple and low cost. The last-stage processing modules release data to the TX handler. An example of a peice of code on top of FlowOS that simplifies programming. Early results show promising throughput on a small number of sessions.

Q) What does the first data structure achive?

A) identifies level. 

Q) Where was this implemented?

A) Linux kernel. Processing modules are just threads.

Q) Is this a static module chain in the compile time?

A) For now, yes. 

Q) Can we just focus on the problem of difficulty of accounting? 

A) You could have a simple TCP solution. But the problem is with intricacies of TCP such as sequence number etc. 

Q) Regarding end pointer, why should they be fixed at the end of packets?

A) Because we are processing packets in the buffer. The painter helps identify the boundaries in sk_buff.

CoNext HotMiddlebox: Towards Minimalistic, Virtualized Content Caches with Minicache

Simon Kuenzer, Joao Martins, Mohamed Ahmed, Felipe Huici

Presenter: Simon Kuenzer

Virtualized content cache is the topic of this current work. The motivation is the recent traffic analysis: e.g., 57% is video traffic. The projection is 69% by 2017. The issue is that using TCP for transmitting video does not perform well especially in long distance. So CDNs such as Akamai try to cache content near the customer. The drawback with this approach is that CDNs need to invest in ISPs to deploy content caches. So CDNs has started deploying micro data centers for themselves. Virtualized content caches require fast instantiable content caches.

The goal is to build is virtualized content cache using XEN. Both the kernel and user spaces parts are instrumented. The performance results w.r.t. throughput show that the throughput drops significantly when block I/O is done in kernel space over user space. The main reason for this drop is the intermediary layers. From Linux to Dom0 there is only a small drop. But the drop to the case of using DomU is significant.

The early prototype of minicache is presented. The throughput evaluation shows that the prototype can match the line rate. 

So in conclusion we can build a small (5MB) machine that boots in 30 milliseconds and can packetize data from block device and fill a 10Gbps rate. The next step would be adding support for HTTP servers, add filesystem to MiniOS/Minicache and optimize MiniOS's blkfron driver, and add scalability requirements for supporting more VMs and CPUs.

Q) your group is working on clickOS. what is different between clickOS and minicache?

A) Different use cases. Here the goal is a performant content delivery. Here also we need to work on different protocols such as HTTP. For example content caches and stacks are missing in clickOS but are needed here.

Q) The future work list seems scary as they might violate minimal increments. 

A) Still it is more minimalistic as compared to Linux. Because it is more specialized geared toward high performance.

Q) re the above question: any comparison in terms of lines of code etc?

A) We'll compute that, but will be an order of magnitude smaller than linux VM.

CoNEXT HotMiddlebox: Evolving the Internet with Connection Acrobatics

Authors: Catalin Nicutar, Christoph Paasch, Marcelo Bagnulo, Costin Raiciu

Presenter: Costin Raiciu

Middleboxes/Firewalls are deployed everywhere on the Internet, and they break the end-to-end principle making it hard to debug your networking problems. Content Provider Middleboxes (e.g., Google Global Cache) has problems with mobile clients, as a suboptimal content-cache server is kept when the host moves.

Thus, making middleboxes explicit will help to solve this, as the end-host is aware of the middlebox. Further, moving the endpoint of a connection will improve content provider's service quality for mobile clients. Any kind of mobility mechanism (MobileIP, LISP, shim6,...) allows to achieve the above.

With Multipath TCP, we can also achieve this. The advantage with MPTCP is that it has already deployment-success (cfr. Apple iOS7).

• Moving the middle of a connection: Using MPTCP's "ADD_ADDR"-message it is possible to redirect a connection through another middlebox.
• Moving the end of a connection: With the "ADD_ADDR"-message and some state-synchronization between the servers allows to move the end of a connection. State-synchronization through:
• VM migration - state is moved with the VM
• Moving before the application accepts the connection - So, no application-state to migrate. Allows for DoS-protection/load-balancing on a server.

Conclusion:

Connection acrobatics add flexibility to the Internet and is deployable today with MPTCP clients.

Q: You want to allow MitM-attacks:

A: Well, MitM is already there today.

Q: MPTCP is not absolutly necessary to achieve the redirection. Simply address-rewriting achieves the same.

A: Yes, any mobility-mechanism can be used.

Q: This seems like a hammer in the search for a nail - is it really necessary to make middleboxes explicit, and would a provider really want to expose its middleboxes?

A: If you have end-to-end encryption (TCPcrypt,....) and an ISP wants to redirect through a middlebox, you will need this explicit middlebox-redirection. This will move the "power" back to the end-user.

CoNEXT HotMiddlebox: Multipath TCP in the Middle(Box)

Gregory Detal, Christoph Paasch, and Olivier Bonaventure (Universite catholique de Louvain) Paper link

Presenter: Gregory Detal

Nowadays device have multiple interfaces, having LTE, WiFi and ethernet at the same time.
As a end user you expect seamless mobility between connections established on those interfaces,  but as TCP is linked to a single IP address, a TCP connection will fail when the address change.

(demonstration showing a mobile device streaming a video when the WiFi is lost, the streaming ends)

MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows.
To do this MPTCP establish regular TCP connections, adding some signaling to be able to reorder the packets.

MPTCP as been implemented by Apple in iOS 7 (for Siri).

TCP extensions adoption take time, especially on the server side, for instance in took 15 years for the SACK extension.

To accelerate the deployment of this new extension the authors propose a converter that will act at the transport layer.

Putting that converter in the edge of the newtork, the converter allow to offer MPTCP service provided by "regular TCP servers".

(demonstration showing a mobile device streaming a video when the WiFi is lost, the streaming continues)

This converter is implemented into the linux kernel for optimized performances. The evaluation was conducted using a client having 2x10Gps links to the converter, the converter having a single 10Gps link to the server. The applications used are nerperf and weighttp. The evaluation was made comparing the performances of the converter acting as a router or as a converter. The evolution showed that the converter is highly efficient, always close to the performance we can get when doing MPTCP end to end.

Conclusion:
MPTCP is an important extension
MPTCP brings many advantages to end users (especially on smartphones)
The MPTCP converter allows users to take advantage of MPTCP quickly

Questions:

Q: Other success stories besides Apple?
A: Yes, Intel is also looking at it, Citrix created a mptcp-enabled middlebox (used by Apple). Apple has still the major deployment (more that hundreds of millions of user).

Q: MPTCP looks like SCTP, what's the differences:
A: SCTP was more difficult to deploy, even if it's a cleaner approach MPTCP solved the deployment problem.

Q: What are the incentive for this use cas
A: Basically mobile operators wants to offload their 3G traffic on the WiFi. 4G networks will be overloaded by 2020.

Q: Challenges of the implementations ? Why not other solutions in user space ?
A: no TCP stack available in solutions such as netmap. The current MPTCP stack of Linux is performant and stable. The challenges was mainly to integrate within the Linux stack efficiently.

Q: Is it not better to have MPTCP from end to end as the converter is acting as a choke point ?
A: Sure, but in the smartphone environment we expect that the choke points will be located at the client access networks (3G, WiFi) so there should not impact end to end performance but going through a converter. We also looked at solutions to fallback when the server is MPTCP allowing the client to establish direct subflows to the server and thus benefit from MPTCP end to end. This was not published in this paper due to lack of space.