[Coin] Draft on Transport Protocol Issues

[Ike Kunze <[e-mail]>]

Hello list,

attention: long email incoming.
TL:DR: We would like to know if the transport protocol issues are of interest to the community 
and we are looking for collaborators to work on a corresponding draft.

As suggested in Montreal, we at COMSYS would like to work on a draft to collect the implications of COIN 
on transport protocols as well as challenges or obstacles that might hinder widespread deployment of COIN 
like the often-mentioned end-to-end principle.
In the meeting, we had the impression that the problems that we see are not clear to everyone which is why 
we would first like to briefly share our thoughts on the topic with the list to see if these considerations are 
of interest to the community in which case we would then proceed and start writing the actual draft. 

Today’s transport protocols offer a variety of functionality based on the notion that the network is to be treated
as an unreliable communication medium which does not alter the transmitted data 
(which, in practice, is not really true due to middleboxes). 
Some, like TCP, establish a reliable connection on top of the unreliable network while others, 
like UDP, simply transmit datagrams without a connection and without guarantees into the network.

In this overall context, we see several issues and challenges that arise when we combine traditional transport protocols with COIN:

1. Addressing: 
Traditionally, end-hosts directly address each other. 
With COIN, one host might want to specify which kind of functionality should be applied to the transmitted data
on the path and where or by whom it should be applied. 
Instead of direct addressing of the end-hosts, indirection mechanisms are needed to route a packet along 
a pre-defined or dynamically chosen path which realizes the desired functionality.
Related concepts which might be of use are Segment and Source Routing as well as (Service/Network) Function Chaining/Composition.

2. Flow granularity: 
Assuming that there is a suitable addressing scheme which allows to define which kinds of functionality 
should be applied to the transmitted data, a next question that arises is how the transmitted data 
is to be treated by the devices implementing the functionality. 
A TCP stream, for example, where the transmitted data is dynamically distributed across segments 
should perhaps be treated differently than UDP datagrams where the application defines how the data
is distributed across the distinct datagrams. 
Underlying this simple example lies the general question of how the data should be interpreted by the COIN elements: 
should every packet be treated (1) individually, (2) as part of a message where the content of surrounding  packets might be relevant 
or (3) as part of a byte stream where all previous packets need to be taken into consideration?

3. Security and Authentication: 
Assuming that there is a suitable addressing scheme and the COIN elements know how to treat the packets. 
In this case, data transmitted from host A to host B will now be altered on the way.
This, of course, opens the door for foul play as every middlebox, both (misbehaving) COIN elements and
‘traditional’ middleboxes, could simply start altering parts of the original data. 
What is needed is a mechanism so that the receiving host can verify (a) how and (b) by whom the data 
has been altered on the way, i.e., some form of authentication. 
Thinking a step further and considering developments such as QUIC where almost all transmitted data is encrypted, 
there is a need for concepts which allow to include security mechanisms like encryption into COIN frameworks.

4. Advanced Transport Features: 
Except for the crypto aspect, all of the mentioned challenges are relevant for every transport protocol 
as they define the interaction between the transport and COIN. 
This completely leaves out the fact that there is a significant difference in functionality between different transport protocols. 
UDP, for example, is a connectionless protocol which does not offer any reliability while TCP first sets up 
a dedicated connection and then ensures the successful transmission of all data. 
In addition to that it adds flow and congestion control to avoid overloading the receiving end-host and the network. 
When selecting a transport protocol for COIN, such advanced features have to be considered as well. 
For illustration, consider the simple retransmission mechanism of TCP. 
If we transfer this principle to a communication setting with COIN elements in between, it has to be defined how loss can 
be recovered if packets are, e.g., lost at the last stage of a chain of COIN elements. 
This question has been already worked on in the context of multicast transport protocols. 
Another angle on this aspect is that different COIN devices have different computational and storage capacities which could, 
for example, become interesting if they are supposed to embed into TCP for which they might be forced to hold some form 
of TCP’s state which might not be possible on each type of COIN element. 
The choice of devices could hence affect the types of transport protocols that can be operated on the COIN networks which
might make it necessary to define different classes of COIN-ready transport protocols.

In the draft, we would like to present these challenges and more in more detail and also give our impression
on how well they could be solved using existing transport protocols. 
Depending on our progress, we would then like to start working out design requirements for an “ideal” COIN transport protocol.

Please let us know if this topic is of general interest to the community in which case we would start working on the draft 
and please let us also know if you would like to join our efforts.

Best wishes,

Ike Kunze
-- 
Ike Kunze, M.Sc.
Researcher

COMSYS - Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55
52074 Aachen, Germany
Tel: [phone]
[e-mail]
http://www.comsys.rwth-aachen.de/team/ike-kunze/