This paper is a considerably expanded version of the INFOCOM paper.
Again it argues that TCP is no longer mainly controlled by loss and congestion but instead by algorithms and settings under the control of the sender or receiver deliberately or accidentally designed to restrict throughput for a variety of reasons (for example limiting video sending to the rate at which the viewer is watching).
It contains extended discussion of the methodology and in particular how flight and RTT data was extracted from passive traces.
This paper describes a system for middleboxes that process application level data -- that is reconstructed TCP flows not packets. The system consists of three parts:
1) A language specific to middleboxes that can quickly express data formats and how to process them but in a "safe" way that allows middleboxes to co-exist on the same physical hardware.
2) An abstraction, the task graph, that breaks middlebox logic into small, parallelisable logical units (tasks) connected by channels through which data flows.
3) A system that allows the compiled code to execute in a performant way.
This talk describes FLICK a system for the application-specific middlebox. It consists of three parts:
1) A domain specific language for the middlebox that allows easy development of typical middlebox functions.
2) An abstraction, the task graph, that allows the breaking of middlebox functions into easily parallelisable work units.
3) The system -- this implements the compiled language, handles TCP connections and memory management.
The whole system is comparable in speed to a specialist implementation.
Proc. of International Conference on Telecommunications
This paper looks at a new way to use multiple channels in ad-hoc sensor networks. It consists of two parts:
1) A protocol that allows a node, when sent a particular message, to attempt to change channel (reliably with a fall-back if the new channel is subject to interference).
2) An algorithm run at a single "command" node that selects which nodes should change channel according to a graph colouring problem.
The work is tested in simulation using Cooja (which simulates Contiki based sensor nodes).
The essential findings are that TCP is not working as we expect. The expected correlation between throughput and packet loss is not found. The correlation with delay (RTT) is as expected -- throughput proportional to 1/delay. A high correlation with flow length is found -- longer flows have higher throughput. However, this may be a sampling error due to the restricted length of the samples used.
The TCP flows studied are broken down by assumed cause where TCP mechanisms are thought not to be the primary cause for throughput:
1) Application limited -- an application decides to reduce its own flow by deliberately not sending data.
2) Host Window limited -- one or other host has a low maximum window size that restricts flow.
3) Advertised window limitation -- a middlebox or the receiver manipulates their advertised window size to reduce the flow.
More than half of TCP flows (and more than 80% of long flows) are limited by these mechanisms and not by traditional TCP mechanisms.
In this case the focus is resilience within a data centre. In particular resilience at the network layer. If several paths are available to a destination the system known as INFLEX can support fail over between paths seamlessly using OpenFlow. In this case the system is tested using Openvswitch.
This talk describes FLICK a system for the application-specific middlebox. It consists of three parts:
1) A domain specific language for the middlebox that allows easy development of typical middlebox functions.
2) An abstraction, the task graph, that allows the breaking of middlebox functions into easily parallelisable work units.
3) The system -- this implements the compiled language, handles TCP connections and memory management.
The whole system is comparable in speed to a specialist implementation.