## 3 Research Method
### Container Networking
The DNS service of different CO frameworks can be classified according to several features which are described in the \"service discovery and external access\" sub-aspect. All CO frameworks, except Aurora, support this approach (see Table 2), but Docker Swarm alone and Marathon provide only container IP networking but no service IP load balancing [31]. _Host port networking_. Here, (i) services are identified by means of _a stable DNS name_; (ii) container ports are exposed via a host port--here containers can run in _host mode_ (i.e., share the network stack of the underlying host) or _bridge mode_ (which is less performant but more secure than host mode because of the intermediate virtual bridge; (iii) in the internal DNS service, the IP addresses of the nodes on which a container of the service is deployed are registered as a list of A records and these records are returned according to the _DNS round robin_ scheme; (iv) it is also possible to register exposed host ports as SRV records. Docker Swarm integrated mode [119], Mesos+Aurora [120], Mesos+Marathon [121] and DC/OS [117] fully support this third approach. _Host ports conflict management_. A common problem with host ports networking is that containers with the same host port cannot be scheduled on the same node and therefore the number of scheduled containers with the same host port is limited to the number of nodes in the cluster. For these reasons, host ports are not recommended by Kubernetes [122] except for very specific use cases such as running CO plugins as global containers (see Section 4.4) on every node of the cluster. _Dynamic allocation of host ports_. To deal with host port conflicts at the same node, host ports for a container are preferably dynamically allocated so that every allocated host port is guaranteed to be unique within the cluster. Such dynamic allocation can be requested in the API object specification of a container in Docker Swarm integrated mode [123], Aurora [124] and Marathon [125]. Note that dynamic allocation of host ports also requires that the containerized application is reconfigured via a custom Docker ENTRYPOINT so that the default port of the application is changed to the dynamically allocated host port (see Section 4.4). _Management of statically specified host port conflicts on the same node_. For those applications where dynamically changing the default port is not possible or too cumbersome, or those CO frameworks that do not support dynamic host port allocation, it is still possible for a container to statically reserve a particular port: * in Docker Swarm integrated mode [126], host ports are centrally managed at the service level such that requests for creating a new service with an already allocated host port is a priori rejected * in Kubernetes [127], the default scheduler policy (see Section 4.1) ensures that containers are automatically scheduled on nodes where the requested host port is still available. There is no specific support for reservation of host ports in the other CO frameworks. As a workaround, scheduling constraints (see Section 4.6) can be specified per container in order to ensure that containers with the same host port are scheduled on different nodes. **Plugin architecture for network services. **  
_Network plugin architecture._ In order to support different network implementations, all CO frameworks support a common interface and composition framework for network plugins. What network plugin is preferred by an application depends on various contextual parameters such as the underlying cloud provider network, the desired performance, desired routing topology, etc. The implementation of routing mesh and/or virtual network can be customized to accommodate performance requirements of the containerized applications. The involved customizations include the implementation of the local virtual bridge, the virtual overlay network software, and the distributed load balancer. For more details, we refer to the technical report [31], Section 4.3.1.