Network protocols

Protocols used in networking such as TCP or IP.

On rate limitation mechanisms for TCP throughput: a longitudinal analysis

richard's picture Submitted by richard on

Journal Paper
Computer Networks

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.

FLICK: Developing and Running Application-Specific Network Services

richard's picture Submitted by richard on

Conference paper
USENIX ATC

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.

FLICK: Developing and Running Application-Specific Network Services

richard's picture Submitted by richard on

Conference presentation
Location: 
USENIX ATC
Slides: 
PDF icon rgc_usenix_atc_2016.pdf
Comments: 

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.

Multichannel Cross-Layer Routing for Sensor Networks

richard's picture Submitted by richard on

Conference paper
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).

TCP in the wild

richard's picture Submitted by richard on

Invited talk
Location: 
Kings College London
Slides: 
PDF icon kcl_tcp_2014.pdf
Comments: 

This talk is essentially the same as that delivered in Cambridge two months earlier (alas no progress on this research for that period).

The research is based on two papers:
A longitudinal analysis of Internet rate limitations -- http://www.richardclegg.org/tcp_rate_infocom_2014
and
On the relationship between fundamental measurements in TCP flows -- http://www.richardclegg.org/tcp_limitations_icc_2013

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.

Software-defined network support for transport resilience

richard's picture Submitted by richard on

Journal Paper
IEEE/IFIP Network Operations and Management Symposium

This paper is a development of the earlier ideas in PREFLEX -- http://www.richardclegg.org/node/18

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.

Pages

Subscribe to RSS - Network protocols