Subject: Re: [Coin] Draft on Transport Protocol Issues

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 01 Oct 2019 19:05:16 +0200

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: +49 241 80-21422
> [email-masked]
> http://www.comsys.rwth-aachen.de/team/ike-kunze/
>
> -- 
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 1 Oct 2019 18:52:50 +0100

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 <[email-masked]>
wrote:

> As suggested in Montreal, we at COMSYS would like to work on a draft to
> collect the implications of COIN
> 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
> Some, like TCP, establish a reliable connection on top of the unreliable
> network while others,
> In this overall context, we see several issues and challenges that arise
> when we combine traditional transport protocols with COIN:
>
> 1. Addressing:
> Instead of direct addressing of the end-hosts, indirection mechanisms are
> needed to route a packet along
> 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
> 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
> 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.
> ‘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
> 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.
>
> Except for the crypto aspect, all of the mentioned challenges are relevant
> for every transport protocol
> 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.
> When selecting a transport protocol for COIN, such advanced features have
> to be considered as well.
> be recovered if packets are, e.g., lost at the last stage of a chain of
> COIN elements.
> 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
> In the draft, we would like to present these challenges and more in more
> detail and also give our impression
> 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

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

---

From: Ike Kunze <[email-masked]>
Date: Wed, 2 Oct 2019 12:31:21 +0000

Hi Dirk,

thank you for your valuable feedback.
I agree with you in that we should not directly try to derive an overall COIN transport protocol/architecture, but as I said,
our goal is to collect and discuss general challenges which we face when deploying COIN elements.
I think that the building blocks that you mention could very well be a result of our discussions and could illustrate
how the challenges can be approached.

In this context, I think that categorizing different kinds of scenarios and interactions, as you propose, can help us to
identify which of the challenges might be solved using the same or similar building blocks.
However, I think that finding a suitable level of abstraction for the discussions will be challenging.

Whatever categorization we might choose here, dealing with authorizing and authenticating COIN elements
should be a focus of our discussions as this in fact is where the end-to-end principle that we always mention breaks.
We are very interested to hear about ideas how identifying the COIN elements might be possible.

Trying to solve a particular problem with experimental work is a nice suggestion.
Do you know of other work that could relate to or already tries to solve some of the problems here?

Best,
Ike

Am 01.10.2019 um 19:05 schrieb Dirk Kutscher <[email-masked]<mailto:[email-masked]>>:

Hi Ike,

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.

Dirk

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: +49 241 80-21422
[email-masked]<mailto:[email-masked]>
http://www.comsys.rwth-aachen.de/team/ike-kunze/

--
Coin mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/coin

---

From: Ike Kunze <[email-masked]>
Date: Wed, 2 Oct 2019 12:37:49 +0000

Hi Jon,

thanks for bringing this to our attention!
We’ll definitely talk to them and take a look at their work.

Best,
Ike

Am 01.10.2019 um 19:52 schrieb Jon Crowcroft <[email-masked]<mailto:[email-masked]>>:

On Mon, Sep 30, 2019 at 12:53 PM Ike Kunze <[email-masked]<mailto:[email-masked]>> wrote:
Hello list,

1. Addressing:

2. Flow granularity:

Best wishes,

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