Re: [Coin] Draft on Transport Protocol Issues

Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de> Tue, 05 November 2019 14:56 UTC

Return-Path: <Ike.Kunze@comsys.rwth-aachen.de>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF911200B1 for <coin@ietfa.amsl.com>; Tue, 5 Nov 2019 06:56:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.687
X-Spam-Level:
X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RpWmQVAQnGc for <coin@ietfa.amsl.com>; Tue, 5 Nov 2019 06:56:01 -0800 (PST)
Received: from mail-out-4.itc.rwth-aachen.de (mail-out-4.itc.rwth-aachen.de [134.130.5.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FBD12013C for <coin@irtf.org>; Tue, 5 Nov 2019 06:55:20 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AOCACkfMFd/xUN4olcAQkcAQEBAQEHAQERAQQEAQGBfoEcLyQFLFkTWC8qCoQfYZA/mUCBZwkBAQEBAQEBAQEIGAEKCgIBAYMKcUUCF4N3JDgTAg4BAQUBAQEBAQUEbYU3DIVSAgEBAgEBGAkwFAEEAgIEAgMQAgEGAhImAQYDAgICJQsUAw4CBAoEBRQHAYMGAYF5fgEOlAebcYEyhDkBgRSDKoFIgTaFGoU2D4EXHYFYP4ERJx+BTlAuPoJXCwEBAYEkCQEHAQoBCxsQHwiCUjKCLASJTIMmEj8CgjeFPIk5jhduB4E/aG6GJ4lAhGcbgjyHW4QFi02WcZFWgTI3ImdxTSRPDQkUAYJBCUcRFIFVgQ0wF4EEAQiCdjeDbzuBH4QfAXQBAYEmjh8OF4ELAS5fAQE
X-IPAS-Result: A2AOCACkfMFd/xUN4olcAQkcAQEBAQEHAQERAQQEAQGBfoEcLyQFLFkTWC8qCoQfYZA/mUCBZwkBAQEBAQEBAQEIGAEKCgIBAYMKcUUCF4N3JDgTAg4BAQUBAQEBAQUEbYU3DIVSAgEBAgEBGAkwFAEEAgIEAgMQAgEGAhImAQYDAgICJQsUAw4CBAoEBRQHAYMGAYF5fgEOlAebcYEyhDkBgRSDKoFIgTaFGoU2D4EXHYFYP4ERJx+BTlAuPoJXCwEBAYEkCQEHAQoBCxsQHwiCUjKCLASJTIMmEj8CgjeFPIk5jhduB4E/aG6GJ4lAhGcbgjyHW4QFi02WcZFWgTI3ImdxTSRPDQkUAYJBCUcRFIFVgQ0wF4EEAQiCdjeDbzuBH4QfAXQBAYEmjh8OF4ELAS5fAQE
X-IronPort-AV: E=Sophos; i="5.68,271,1569276000"; d="scan'208,217"; a="56699654"
Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-4.itc.rwth-aachen.de with ESMTP; 05 Nov 2019 14:47:44 +0100
Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id 43F14423CF; Tue, 5 Nov 2019 14:47:43 +0100 (CET)
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 5 Nov 2019 14:47:42 +0100
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1130.005; Tue, 5 Nov 2019 14:47:42 +0100
From: Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
CC: Klaus <Klaus@comsys.rwth-aachen.de>, "coin@irtf.org" <coin@irtf.org>
Thread-Topic: [Coin] Draft on Transport Protocol Issues
Thread-Index: AQHVkzpt800/4EICNUGCDB2J83tsYKd7QXAAgAFGhQA=
Date: Tue, 05 Nov 2019 13:47:42 +0000
Message-ID: <718DC5BD-9EC3-48EB-B135-1A078AC07C6E@comsys.rwth-aachen.de>
References: <70DD21AC-E207-4115-B13A-B45C62168BC9@comsys.rwth-aachen.de> <9124FDB6-7F3E-4696-AFF4-A2B5ABB6E2E3@dkutscher.net> <262F0D57-2F19-444F-A4A9-CC33DF8A37FD@comsys.rwth-aachen.de> <AB07990D3CAE53419132AB701C45693CD7BA0C61@dggeml529-mbx.china.huawei.com> <CAPjWiCSzt+0JUeqtQWAZNq=P6aZTQ0v8Nj-PnOwDEVSAvS=DLg@mail.gmail.com> <BD947B09-47DB-4FF2-B531-8C358CAFB405@comsys.rwth-aachen.de> <CAPjWiCTnZAeRDDgwTiJyaKtNm1iRv4i-=9oX1neu5Nv+Xpzw4A@mail.gmail.com>
In-Reply-To: <CAPjWiCTnZAeRDDgwTiJyaKtNm1iRv4i-=9oX1neu5Nv+Xpzw4A@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.226.59.4]
Content-Type: multipart/alternative; boundary="_000_718DC5BD9EC348EBB1351A078AC07C6Ecomsysrwthaachende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/cJ_oBfIsIQBnTHCwJaEVNbeL1Dc>
Subject: Re: [Coin] Draft on Transport Protocol Issues
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 14:56:06 -0000

Hi Marie-José,

okay, great.
Then we will prepare a short presentation and you can add us to the agenda.

Best,
Ike
--
Ike Kunze, M.Sc.
Researcher, Ph.D. Student

COMSYS - Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55
52074 Aachen, Germany
Tel: +49 241 80-21422
ike.kunze@comsys.rwth-aachen.de<mailto:ike.kunze@comsys.rwth-aachen.de>
http://www.comsys.rwth-aachen.de/team/ike-kunze/

Am 04.11.2019 um 19:19 schrieb Marie-Jose Montpetit <marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>:

I had a quick look at the draft. I could have detailed comments later but it is a topic that we had flagged from the beginning and I think raising it is good.

So I would recommend a short presentation.

mjm
Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com<mailto:mariejose@mjmontpetit.com>
mariejo@mit.edu<mailto:mariejo@mit.edu>


On November 4, 2019 at 1:05:24 PM, Ike Kunze (ike.kunze@comsys.rwth-aachen.de<mailto:ike.kunze@comsys.rwth-aachen.de>) wrote:

Hi Marie-José,

thanks for the offer.
We actually wanted to have offline discussions first, but if you think that discussing the transport issues
in a larger forum during the COIN meeting makes sense, Klaus could do a short presentation as he will be in Singapore.
Have a look at the draft [1] first, before deciding if it makes sense to add it to the agenda.

Best,
Ike

[1] https://www.ietf.org/id/draft-kunze-coinrg-transport-issues-00.txt
--
Ike Kunze, M.Sc.
Researcher, Ph.D. Student

COMSYS - Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55
52074 Aachen, Germany
Tel: +49 241 80-21422
ike.kunze@comsys.rwth-aachen.de<mailto:ike.kunze@comsys.rwth-aachen.de>
http://www.comsys.rwth-aachen.de/team/ike-kunze/

Am 04.11.2019 um 12:15 schrieb Marie-Jose Montpetit <marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>:

Ike:

I gather you or a team member will want to present there transport issues at the meeting? Should we add you to the agenda?

Jeffrey: is this also something you would like to present?

mjm

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com<mailto:mariejose@mjmontpetit.com>
mariejo@mit.edu<mailto:mariejo@mit.edu>


On November 4, 2019 at 3:57:59 AM, Hejianfei (Jeffrey) (jeffrey.he@huawei.com<mailto:jeffrey.he@huawei.com>) wrote:
Hi Ike,
(chair hat off)
Some (late) thoughts about your ideas on transport protocol issues(thank you for raising them).

1, Data plane abstraction: ICN or session style?
I see two potential alternatives for in-net compute. One is “ICN-style”, e.g. two examples below..
                http://www.named-function.net<http://www.named-function.net/>,
https://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-31.pdf
In that world, “end-to-end” is totally different with traditional TCP/IP network, so the questions for the transport are also different.
The other way is “session-style”, to explore if we can continue to use the traditional network notions such as session, address etc. The ConvergeCast in some textbooks is close to in-net compute, although I am not sure if they have successful implementations in real world. Reference:http://www.cs.yale.edu/homes/aspnes/pinewiki/ConvergeCast.html.
As I told my friends in ICN community, I am happy to see ICN coming true. But I am also interested if “session-style” can work for in-net compute. There are already some ad hoc implementations, however too early to say if we can generalize them.

2, Pain and gain
As you listed correctly and clearly, the traditional transport can’t fit well with in-net compute. We need to modify. At least two functions of transport are usually required in my view: reliability(dealing with the packet loss) and rate control( dealing with the congestion). Even these two basic requirements are challenging in the context of in-net compute. For example, the packet loss should be considered in two cases: before the compute and after. Further, as you pointed out, generally, for the network devices to compute on the packets, they should be able to identify the service instance( correlated packets from different sources), the demarcation of “operators” and “operands” inside the packets.
The paper (https://arxiv.org/abs/1903.06701) implements above UDP, while my team is trying to implement at “message” layer with RoCEv2 NIC.
I think it is probably feasible in principle, certainly it is not easy. The question is if the cost can be justified by enough gain.
In the LAN scenarios like DCN, the way to justify is clear based on my discussion with some colleagues working on distributed systems. For example, for the AI case, if the solution can increase the training speed by 20%, it is enough for them to adopt a new network solution, since the total cost of networks is less than 10% in the whole solution(high performance GPUs are very expensive) and lifecycle of switches are also becoming shorter inside DC.
Different scenarios may have different answers: DCN, industrial networks, carrier’s networks (WAN or metro net to connect the edge computing).

Just my two cents,
Jeffrey

发件人: Coin [mailto:coin-bounces@irtf.org<mailto:coin-bounces@irtf.org>] 代表 Ike Kunze
发送时间: 2019年10月2日 20:31
收件人: Dirk Kutscher <ietf@dkutscher.net<mailto:ietf@dkutscher.net>>
抄送: Jan Rüth <Jan.Rueth@comsys.rwth-aachen.de<mailto:Jan.Rueth@comsys.rwth-aachen.de>>; Klaus <Klaus@comsys.rwth-aachen.de<mailto:Klaus@comsys.rwth-aachen.de>>; coin@irtf.org<mailto:coin@irtf.org>
主题: Re: [Coin] Draft on Transport Protocol Issues

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 <ietf@dkutscher.net<mailto:ietf@dkutscher.net>>:

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
ike.kunze@comsys.rwth-aachen.de<mailto:ike.kunze@comsys.rwth-aachen.de>
http://www.comsys.rwth-aachen.de/team/ike-kunze/

--
Coin mailing list
Coin@irtf.org<mailto:Coin@irtf.org>
https://www.irtf.org/mailman/listinfo/coin

--
Coin mailing list
Coin@irtf.org<mailto:Coin@irtf.org>
https://www.irtf..org/mailman/listinfo/coin<https://www.irtf.org/mailman/listinfo/coin>
--
Coin mailing list
Coin@irtf.org<mailto:Coin@irtf.org>
https://www.irtf.org/mailman/listinfo/coin