Re: [Coin] Draft on Transport Protocol Issues

[Jon Crowcroft <[e-mail]>]

cross reference the TAPS WG who do tons of useful work in this space:)

On Mon, Sep 30, 2019 at 12:53 PM Ike Kunze <[e-mail]>
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
>


-- 
please donate to this good cause that I'm supporting through October
https://www.gosober.org.uk/users/jonathan-crowcroft