In Confine networks, distributed experiments can be executed on the same facilities as being used in parallel by the main CN (production network). Therefore it must be ensured that experiments do not interfere seriously with each other nor with the production network.
On the other hand, since Confine is aiming to enable community integrated network experiments, allowing some (controlled) level of interaction between the experiments and the main CN is also important.
This document describes the requirements for isolating and/or controlling sliver interactions over the shared network infrastructure (thus, sliver actions that go beyond the scope of a node).
In contrast, Slice isolation is focusing on resource consumption that has only node-local effects (limited to the scope of the node in which the sliver is operating).
The required isolation is tightly coupled to the types of interactions with the CN that are necessary for an experiment. Following a pessimistic apporoach, all experiments must be considered evil. Network isolation is responsible to ensure that such interactions can not disrupt the production network infrastructure or other experiments.
A number of experiments have been discussed during first months of confine project and (partly) outlined in Experiments. The following four Subsections identify _interaction_types_ that are discussed independently in the remainder of this document. An experiment will usually participate in several interaction types simultaneously.
All experimental network interactions must be controlled with respect to the bandwidth and airtime consumption which they demand from the shared network infrastructure. This interaction is discussed separately because:
All experiments must be controlled to protect privacy and sensitive data of CN users. This interaction is discussed separately because:
The production network and other concurrently operating experiments must be protected from experiments that are affecting common protocols behavior and resources like standard addresses and ports. This interaction is discussed separately because:
Experiments may target on the interactions with CN users. This interaction is discussed separately because:
It must be ensured that the amount of link capacity consumed by an experiment at any link in the network remains within limits so that other concurrently operating slices and the production network have a fair share.
Specific slices or the production network should be configurable with a higher priority to ensure minimal operation as long as possible.
In theory, this limitation must be re-enforced (on a per slice basis) at every hop. Therefore it must be possible to identify the originating slice at each router in the network. In contrary, the type of conveyed data inside the packets and related networking layer is not relevant here.
Another challenge lies in the dynamically changing link capacities of wireless networks. …
Researchers might be interested in real-time data from network interfaces. Such data could be interesting for later analysis or as real-time input for network protocols to cope with changing network and traffic characteristics.
Controlling data collection must be handled on a per-layer basis. It must be decided which type of information is considered sensitive and must be modified for anonymization or filtered.
For example MAC and IP addresses could reveal the person that has initiated a communication flow and thereby reveal location or usage patterns of individuals. However, if address fields would be anonymized, capturing usage of port numbers might be acceptable. On the other hand, real-time access to MAC address fields might be the main requirement for an experimental protocol where such information is only needed to trigger instant reactions and discarded immediately.
Deciding on appropiate policies for controlling data collection is also related to legal issues and privacy regulations in CN licenses. Feasibility, to implement appropiate control mechanisms, depends on desired policies and available anonymization techniques.
Confine testbed must allow experimentation with key network service (routing, DNS) and other protocol resources (address, port, channel assignments).
Isolation from production network and other experiments must be ensured depending on lowest accessed networking layer and used protocol resources.
Application-layer experiments based on udp/tcp communication can be considered non-conflicting if it can be ensured that IP addresses and port numbers used for this experiment are not conflicting with already allocated numbers for other key services. This is because communication between protocol instances is happening end-to-end and transparent for lower layers.
Firewall techniques can be used to filter usage of reserved addresses or port numbers
Further discussion about restrictiveness of firewall policies is required. For example: Would an experimental DNS service provided over standard ports but via a specific IP address be considered “potentially disruptive” because a CN user may accidentially use this DNS service for name resolution?
Overlay / Peer-to-peer networking, Application usability evaluation, Application optimization, Delay Tolerant Networking, Content distribution
Similar as Application Layer Experiments such experiments can be considered transparent for lower layers and require only modification on end devices.
Technically, New transport protocols in Linux can be implemented with raw sockets or by registering a new protocol in linux kernel as a kernel module. raw socket access can be controlled in LXC with the drop.capabilities option
Same as for Application Layer Experiments.
Transport-Protocol Optimization and Stitching
Experiments targeting on modification of core networking services, protocols, and allocated addresses.
(Hybrid) Routing Protocols, Multi-Topology Routing, Routing Security, Link layer Feedback to Routing Protocols
Experiments targeting on modification of core link-layer services, protocols, and allocated addresses.
However, in this case the SDN solution is less clean (more dirty) because isolation is happening in the same networking layer as the experiments.
Network Coding, Layer-2 Routing
Tx-power adaption, Tx-rate adaption
Researchers might be interested in the participation of CN users in their experiments to:
Interaction with CN users can be achieved with different approaches:
(eg: Test user-acceptance for an experimental file-sharing or distributed web-caching protocol).
Such option would allow CN user participation in experiments where normal routing via common CN routing protocols is explicitly NOT wanted.
Several open questions have been addressed in related Sections respectively.
CN: Community Network
CN users: person actively using CN infrastructure for networking services. Could be a passenger using a CN hot-spot.
CN infrastructure: used for community, isolated Confine cloud, and mixed (community and Confine cloud) network infrastructures