Re: [Coin] Draft on Transport Protocol Issues

["Dirk Kutscher" <[e-mail]>]

Hi Ike,

Thanks for these thoughts -- these are certainly relevant points IMO.

Nobody is going to stop if you offer writing up more details, but here 
are some suggestions from my side:

- if you talk about challenges, it would be most useful to describe the 
assumptions upfront. I.e., what is the COIN application, what is the 
environment?
- what typically works well is starting with some experimental work that 
tries to solve a particular problem — typically yields specific 
challenges.
- your list is really comprehensive (transport protocols, provenance 
verification etc.). What might work in the end is a “building 
blocks” approach (not a grand architecture) — just my thinking…
- the “middlebox” notion is IMO fundamentally wrong (as an 
intercepting device that is transparent to other entities). We may not 
need to know where a function resides, but we should know its identity 
to authorize access to our data. (I know that you are not suggesting it 
here.)
- if you want to spend some effort in analyzing challenges, a good first 
step could also be to categorize different kind of scenarios and 
interactions. For example, a distributed computing approach such as the 
one in our recent CFN paper could be different from pipelined processing 
system where every ADU has to pass every function in a sequence.

Happy to discuss more about this!

Dirk




On 30 Sep 2019, at 13:52, Ike Kunze wrote:

> 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/
>
> -- 
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin