Changes between Version 4 and Version 5 of ReferenceGuide

Timestamp:

Oct 18, 2012 11:08:36 AM (12 years ago)

Author:

Ted Faber

Comment:

--

ReferenceGuide

@@ -43 +43 @@
   Override the site configuration and request nodes of ''type1'' (or ''type2'' etc.) as host nodes.
  {{{--end-node-shaping}}}::
-   Attempt to do end node traffic shaping even in containers connected by VDE switches.  This works with qemu nodes, but not process nodes.  Topologies that include both openvz nodes and qemu nodes that shape traffic should use this.
+   Attempt to do end node traffic shaping even in containers connected by VDE switches.  This works with qemu nodes, but not process nodes.  Topologies that include both openvz nodes and qemu nodes that shape traffic should use this.  See the [ReferenceGuide#Interconnections:VDEswitchesandlocalnetworking discussion below].
  {{{--vde-switch-shaping}}}::
-   Do traffic shaping in VDE switches.  Probably the default, but that is controlled in [ReferenceGuide#SiteConfigurationFile the site configuration].
+   Do traffic shaping in VDE switches.  Probably the default, but that is controlled in [ReferenceGuide#SiteConfigurationFile the site configuration]. See the [ReferenceGuide#Interconnections:VDEswitchesandlocalnetworking discussion below].
  {{{--openvz-diskspace}}}::
    Set the default openvz disk space size.  The suffixes G and M stand for gigabytes and megabytes.
@@ -122 +122 @@
 Network behavior changes - loss, delay, rate limits -  are introduced into a network of containers using one of two mechanisms: inserting elements into a VDE switch topology or end node traffic shaping.  Inserting elements into the VDE switch topology allows the system to modify the behavior for all packets passing through it.  Generally this means all packets to or from a host, as the container system inserts these elements in the path between the node and the switch.
 
-This figure shows 3 containers sharing a virtual LAN on a VED switch with no traffic shaping:
+This figure shows 3 containers sharing a virtual LAN (VLAN) on a VDE switch with no traffic shaping:
 
+[[Image(Unshaped.png)]]
 
+The blue containers connect to the switch and the switch has interconnected their VDE ports into the red shared VLAN.  To add delays to tow of the nodes on that VLAN, the following VDE switch configuration would be used:
 
-Openvz containers are interconnected through kernel networking directly to support their high efficiency, and because talking to another container implies leaving the physical machine.  They induce network delays through [http://www.linuxfoundation.org/collaborate/workgroups/networking/netem end node traffic shaping].
+[[Image(shaped.png)]]
 
-Qemu nodes can support either end node tra
+The VDE switch connects the containers with shaped traffic to the delay elements, not to the shared VLAN.  The delay elements are on the VLAN and delay all traffic passing through them.  The container system configures the delay elements to delay traffic symmetrically - traffic from the LAN and traffic from teh container are both delayed.  The VDE tools can be configured asymmetrically as well.  This is a very flexible way to interconnect containers.
+
+That flexibility incurs a cost in overhead.  Each delay element and the VDE switch is a process, do traffic passing from one delayed nodes to the other experiences 7 context switches: container -> switch, switch -> delay, delay -> switch, switch -> delay, delay -> switch, and switch -> container.
+
+The alternative mechanism is to do the traffic shaping inside the nodes, using [http://www.linuxfoundation.org/collaborate/workgroups/networking/netem linux traffic shaping].  In this case, traffic outbound from a container is delayed in the container for the full transit time to the next hop.  The next node does the same.  End-node shaping all happens in the kernel so it is relatively inexpensive at run time.
+
+Qemu nodes can make use of either end-node shaping or VDE shaping, and use VDE shaping by default.  The {{{--end-node-shaping}}} and {{{--vde-switch-shaping}}} options to {{{containerize.py}}} forces the choice in qemu.
+
+ViewOS processes can only use VDE shaping.  Their network stack emulation is not rich enough to include traffic shaping.
+
+Openvz nodes only use end-node traffic shaping.  They have no native VDE support so interconnecting openvz containers to VDE switches would include both extra kernel crossings and extra context switches.  Because a primary attraction of VDE switches is their efficiency, the containers system does not implement VDE interconnections to openvz.
+
+Similarly embedded physical nodes use only endnode traffic shaping, as routing outgoing traffic through a virtual switch infrastructure that just connects to its physical interfaces is at best confusing.
+
+Unfortunately, endnode traffic shaping and VDE shaping are incompatible.
+
+This is primarily of academic interest, unless a researcher wants to impose traffic shaping between containers using incompatible traffic shaping.  There needs to be an unshaped link between the two kinds of traffic shaping.