Re: [Coin] Draft on Transport Protocol Issues
Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de> Wed, 02 October 2019 12:31 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 6517D12000F for <coin@ietfa.amsl.com>; Wed, 2 Oct 2019 05:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 18noIXVkh_Hr for <coin@ietfa.amsl.com>; Wed, 2 Oct 2019 05:31:24 -0700 (PDT)
Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [134.130.5.47]) (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 38B1F120019 for <coin@irtf.org>; Wed, 2 Oct 2019 05:31:24 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2CtBQAcmJRd/xUN4olcAQkcAQEBBAEBDAQBAYFngRwvJC9ZFFYvKgqEGGKQAJk5gWcJAQEBAQEBAQEBCBgBCgoCAQGEQAIXgiUjOBMCDAEBBQEBAQEBBQRthS0MhUwCAQMBASEwGwIEBRACAQgOBC0DAgICJQsUAw4CBAoEBRSDDgGBHW0BDrABgTKIeoFIgTSFFoU1D4EXHYFYP4ERJx+CHi4+gmEBgSYJAQcBCgELKyeCTzKCJgSJPIMfEj8CgjaFMJcpbgeBPmdpj06EXBuCOIdOg36LNad6gTI3ImdxTSRPKgGCQQlHEBSBWxeEA4RhgR+EIHQBgSiNRQ4XgQsBgSIBAQ
X-IPAS-Result: A2CtBQAcmJRd/xUN4olcAQkcAQEBBAEBDAQBAYFngRwvJC9ZFFYvKgqEGGKQAJk5gWcJAQEBAQEBAQEBCBgBCgoCAQGEQAIXgiUjOBMCDAEBBQEBAQEBBQRthS0MhUwCAQMBASEwGwIEBRACAQgOBC0DAgICJQsUAw4CBAoEBRSDDgGBHW0BDrABgTKIeoFIgTSFFoU1D4EXHYFYP4ERJx+CHi4+gmEBgSYJAQcBCgELKyeCTzKCJgSJPIMfEj8CgjaFMJcpbgeBPmdpj06EXBuCOIdOg36LNad6gTI3ImdxTSRPKgGCQQlHEBSBWxeEA4RhgR+EIHQBgSiNRQ4XgQsBgSIBAQ
X-IronPort-AV: E=Sophos; i="5.64,574,1559512800"; d="scan'208,217"; a="91269935"
Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 02 Oct 2019 14:31:21 +0200
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 EE1B141EE7; Wed, 2 Oct 2019 14:31:21 +0200 (CEST)
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Oct 2019 14:31:21 +0200
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; Wed, 2 Oct 2019 14:31:21 +0200
From: Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de>
To: Dirk Kutscher <ietf@dkutscher.net>
CC: "coin@irtf.org" <coin@irtf.org>, Jan Rüth <Jan.Rueth@comsys.rwth-aachen.de>, Klaus <Klaus@comsys.rwth-aachen.de>
Thread-Topic: [Coin] Draft on Transport Protocol Issues
Thread-Index: AQHVd4WYRAdvvTmse0mSs2YjZEh8TadF5DgAgAFFzAA=
Date: Wed, 02 Oct 2019 12:31:21 +0000
Message-ID: <262F0D57-2F19-444F-A4A9-CC33DF8A37FD@comsys.rwth-aachen.de>
References: <70DD21AC-E207-4115-B13A-B45C62168BC9@comsys.rwth-aachen.de> <9124FDB6-7F3E-4696-AFF4-A2B5ABB6E2E3@dkutscher.net>
In-Reply-To: <9124FDB6-7F3E-4696-AFF4-A2B5ABB6E2E3@dkutscher.net>
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: [134.61.176.139]
Content-Type: multipart/alternative; boundary="_000_262F0D572F19444FA4A9CC33DF8A37FDcomsysrwthaachende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/IKMB17bHERgCttM_btQakqsPjGY>
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: Wed, 02 Oct 2019 12:31:29 -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 <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] Draft on Transport Protocol Issues Ike Kunze
- Re: [Coin] Draft on Transport Protocol Issues Dirk Kutscher
- Re: [Coin] Draft on Transport Protocol Issues Jon Crowcroft
- Re: [Coin] Draft on Transport Protocol Issues Ike Kunze
- Re: [Coin] Draft on Transport Protocol Issues Ike Kunze
- [Coin] 答复: Draft on Transport Protocol Issues Hejianfei (Jeffrey)
- Re: [Coin] 答复: Draft on Transport Protocol Issues Marie-Jose Montpetit
- Re: [Coin] Draft on Transport Protocol Issues Ike Kunze
- Re: [Coin] Draft on Transport Protocol Issues Marie-Jose Montpetit
- Re: [Coin] Draft on Transport Protocol Issues Marie-Jose Montpetit
- Re: [Coin] Draft on Transport Protocol Issues Ike Kunze