COINRG I. Kunze
Internet-Draft K. Wehrle
Intended status: Informational RWTH Aachen University
Expires: May 7, 2020 November 04, 2019
Transport Protocol Issues of In-Network Computing Systems
draft-kunze-coinrg-transport-issues-00
Abstract
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. 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. These fundamental differences in functionality
have a significant impact on how COIN approaches can be designed and
implemented. Furthermore, traditional transport protocols are not
designed for the multi-party communication principles that underlie
many COIN approaches. This document discusses selected
characteristics of transport protocols which have to be adapted to
support COIN functionality.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Kunze & Wehrle Expires May 7, 2020 [Page 1]
Internet-Draft COIN Transport Issues November 2019
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flow granularity . . . . . . . . . . . . . . . . . . . . . . 4
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Advanced Transport Features . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
A fundamental design choice of the Internet is that the network
should be kept as simple as possible while complexity in the form of
processing should ideally be located at the edges of the network,
i.e., on end-hosts. This choice is reflected in the widely known
end-to-end principle which states that end-hosts directly address
each other and perform all relevant computations while the only
purpose of the network is to deliver the packets without modifying
them. Transport protocols are consequently designed to facilitate
the direct communication between end-hosts.
In practice, the end-to-end principle is often violated by
intransparent middleboxes which alter transmitted packets, e.g., by
dropping or changing header fields. Contrary to that, COIN
encourages explicit computations in the network which introduces an
intertwined complexity as the concrete computations on the end-hosts
critically depend on the functionality that is deployed in the
network. On another note, it challenges traditional end-to-end
transport protocols as they lack means for addressing in-network
computation entities and as they are generally not designed to
include more than two devices into a communication. Some of these
problems are already presented in [I-D.draft-kutscher-coinrg-dir-00].
This draft intends to discuss potential problems for traditional
transport protocols in more detail to raise questions that the COIN
community needs to solve before a widespread application of COIN
Kunze & Wehrle Expires May 7, 2020 [Page 2]
Internet-Draft COIN Transport Issues November 2019
functionality is sensible. Collaboration with other IRTF and IETF
groups, such as PANRG, the IETF transport area in general, or the
LOOPS BOF, can help in finding suitable solutions.
2. Addressing
The traditional addressing concept of the Internet are end-hosts
directly addressing each other, with all computational intelligence
residing at the network edges. As other COIN drafts, such as
[I-D.draft-montpetit-coin-xr-03],
[I-D.draft-he-coin-managed-networks-01] and
[I-D.draft-kunze-coin-industrial-use-cases-00], and extensive
publications, such as [DANG], [RUETH] and [SAPIO], in the last years
have shown, performing some computations within the network offers
the prospect of improved application performance. In systems like
data centers, which do not rely on the Internet and where the whole
network is under the control of the network operator, integrating
such functionality can be done by explicitly adjusting the
communication schemes within these fully controlled systems based on
the functionality that is executed in the network.
With a widespread application of COIN and a consequent increase in
computational capacities in the network, however, it might also
become viable to deploy functionality in the 'wild' Internet so that
everyday applications might also benefit from these computations. At
this point, it is no longer feasible to manually adjust the traffic
patterns or the applications to correctly incorporate changes made by
the network.
It might thus make sense to make it possible to specify which kind of
functionality should be applied to the transmitted data on the path
inside the network, maybe even where or by whom exactly the execution
should take place. Such functionality could for example be
implemented using an indirection mechanisms which routes a packet
along a pre-defined or dynamically chosen path which then realizes
the desired functionality. Related concepts which might be of use
are Segment and Source Routing as well as (Service/Network) Function
Chaining/Composition.
The main challenges/questions at this point are:
1. How should end-hosts address the functionality within the
network?
2. How exactly can the end-hosts influence where or by whom the
functionality is executed?
Kunze & Wehrle Expires May 7, 2020 [Page 3]
Internet-Draft COIN Transport Issues November 2019
3. How can devices which do not implement COIN functionality be
integrated into the systems without breaking the COIN or legacy
functionality?
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.
3. Flow granularity
Core networking hardware pipelines such as backbone switches serving
several tens of GBit/s are built to process incoming packets on a
per-packet basis, keeping little to no state between them. While
this is appropriate for the general task of forwarding packets, it
might not be sufficient for performing computations as related
information that is needed for the computations can be spread across
several packets. In a TCP stream, for example, data is dynamically
distributed across different segments which means that the data
needed for application-level computations might also be split up. In
contrast to that the content of UDP datagrams is defined by the
application itself which is why the datagrams could either be self-
contained or information can be cleverly distributed onto different
datagrams. The common scheme is that different transport protocols
induce different meanings to the packets that they send out which
needs to be accounted for in COIN elements as they have to know how
the received data is to be interpreted. There are at least three
options for this.
1. Every packet should be treated individually. This, above all,
perfectly meets the possibilities that are already offered by all
networking equipment.
2. Every packet should be treated as part of a message. In this
setting, the packet alone does not have enough information for
the computations. Instead, it is important to know the content
of the surrounding packets which together form the overall
message and might hence also be relevant for the computations.
3. Every packet should be treated as part of a byte stream. Here,
all previous packets and potentially even all following packets
need to be taken into consideration for the computations as the
current packet could, e.g., be the first of a group of packets, a
packet in the middle or the final packet of a sequence of
packets.
The flow granularity consequently has a significant impact on how
computations can be performed and where. Apart from how the COIN
Kunze & Wehrle Expires May 7, 2020 [Page 4]
Internet-Draft COIN Transport Issues November 2019
elements should treat the transmitted data, another important aspect
is how it can be ensured that the end-hosts know who has altered the
data and how.
4. Authentication
The realisation of COIN legitimizes and actively promotes that data
transmitted from one host to another can be altered on the way inside
the network. While this can be beneficial if implemented correctly,
it also opens the door for foul play as all intermediate network
elements - no matter if they are malicious or misbehaving by
accident, COIN elements, or 'traditional' middleboxes - could simply
start altering parts of the original data and thus potentially cause
harm to the end-hosts. What is consequently needed is a mechanism
with which the receiving host can verify (a) how and (b) by whom the
data has been altered on the way. In fact, these might very well be
two distinct mechanisms as one (a) only focusses on the changes that
are made to the data while (b) requires a scheme with which COIN
elements can be uniquely identified (could very well relate to
Section 2) and subsequently authenticated.
The challenges at this point are thus the following:
1. How are changes to the data within the network communicated to
the end-hosts?
2. How are the COIN elements that are responsible for the changes
communicated to the end-hosts?
3. How is it verified that indeed the proclaimed COIN elements have
performed the changes and not some impostor?
5. Security
Today, most, if not all, COIN concepts base on the fact that the data
is transmitted in plain text as this makes working on the data easy.
This is in contrast to a general development which sees more and more
security features added to communication protocols, nicely
highlighted by QUIC where the all payload data and almost all header
content (except for the spin bit) is already encrypted inside the
transport layer. This, in turn, makes COIN concepts infeasible in
settings where QUIC connections are used as the COIN elements do not
have access to any packet content. As waiving security features is
generally not acceptable, the widespread success of COIN might very
well also depend on how well security mechanisms like encryption can
be integrated into COIN frameworks.
Kunze & Wehrle Expires May 7, 2020 [Page 5]
Internet-Draft COIN Transport Issues November 2019
Together, the four aspects presented in Section 2 to Section 5 form a
set of fundamental properties that should be taken into account for a
basic transport-compatible realization of COIN. What is not yet
considered is the fact that different transport protocols typically
differ in functionality and thus have a significantly different
behavior. In the following, we briefly discuss select additional
transport features to create awareness for the multifaceted
interaction between the transport protocols and COIN elements.
6. Advanced Transport Features
There is a variety of transport features which are only supported in
some concrete transport implementations. Still, they have a
significant impact on the behavior and performance of the protocols.
One aspect is that some protocols offer reliability while others do
not. This is for example visible when comparing UDP, a
connectionless protocol without guarantees, to TCP which first sets
up a dedicated connection and then ensures the successful reception
of all data. When facing UDP transmissions, COIN elements
potentially have to cope with lost information while with TCP it is
fairly save to say that the packets will reach them at some point.
This, however, also makes it more difficult for COIN elements as TCP
retransmissions, which are issued once a packet has been detected as
lost, are sent drastically out of order with the original packet
sequence.
Thinking one step further, retransmissions are sent from the original
sender of the packet. In a communication setting with COIN elements
in between, resending the packet through the complete sequence of
elements might not be necessary if, e.g., a packet is lost at the
last stage of a sequence of COIN elements. Here, it might be enough
if this last element resends the packet, although this in turn means
that there have to be storage capabilities on the devices enabling
them to store a certain number of packets and have them ready for
retransmission. The general question, i.e., which of the nodes in
the sequence should actually do the retransmission, has already been
worked on in the context of multicast transport protocols.
Now focussing on the aspect of storage capabilities, it can be said
that different COIN devices have different computational and storage
capacities which can become a challenge if they have to hold some
packets (potentially for retransmission) or if they are supposed to
embed into TCP for which they might be forced to hold some form of
TCP's state. Consequently, it is very likely that not every form of
transport integration into COIN can be supported by every available
COIN platform. The choice of devices included into the communication
Kunze & Wehrle Expires May 7, 2020 [Page 6]
Internet-Draft COIN Transport Issues November 2019
will hence certainly affect the types of transport protocols that can
be operated on the COIN networks.
Another aspect is flow and congestion control to avoid overloading
the receiving end-host and the network; it is included in TCP, but
not in UDP, but has an impact on how the end-hosts can send their
data.
All in all, there is a wide range of non-essential transport features
which nonetheless offer improved performance in certain settings and
for certain application combinations. However, as presented, it is
likely that not all of the features/types of transport protocols can
be supported on every COIN element. A potential approach might be to
define different classes of COIN-ready transport protocols which can
then be deployed depending on the concretely available networking/
hardware elements.
7. Security Considerations
TBD
8. IANA Considerations
N/A
9. Conclusion
The advent of COIN comes with many new use cases and promises
improved solutions for various problems. It is, however, not
directly compatible with the end-to-end nature of transport
protocols. To enable a transport-based communication, it is thus
important to answer key questions regarding COIN and transport
protocols, some of which are raised in this document.
10. Informative References
[DANG] Dang, HT., "NetPaxos: Consensus at Network Speed", DOI:
10.1145/2774993.2774999, in SOSR, 2015.
[I-D.draft-he-coin-managed-networks-01]
He, J., Li, A., and M. Montpetit, "In-Network Computing
for Managed Networks: Use Cases and Research Challenges",
draft-he-coin-managed-networks-01 (work in progress), July
2019.
Kunze & Wehrle Expires May 7, 2020 [Page 7]
Internet-Draft COIN Transport Issues November 2019
[I-D.draft-kunze-coin-industrial-use-cases-00]
Kunze, I., Rueth, J., and K. Wehrle, "Industrial Use Cases
for In-Network Computing", draft-kunze-coin-industrial-
use-cases-00 (work in progress), July 2019.
[I-D.draft-kutscher-coinrg-dir-00]
Kutscher, D., Karkkainen, T., and J. Ott, "Directions for
Computing in the Network", draft-kutscher-coinrg-dir-00
(work in progress), July 2019.
[I-D.draft-montpetit-coin-xr-03]
Montpetit, M., "In Network Computing Enablers for Extended
Reality", draft-montpetit-coin-xr-03 (work in progress),
July 2019.
[RUETH] Rueth, J., "Towards In-Network Industrial Feedback
Control", DOI: 10.1145/3229591.3229592, in ACM SIGCOMM
NetCompute, August 2018.
[SAPIO] Sapio, A., "Scaling Distributed Machine Learning with In-
Network Aggregation", 2019,
<https://arxiv.org/abs/1903.06701>.
Authors' Addresses
Ike Kunze
RWTH Aachen University
Ahornstr. 55
Aachen D-50274
Germany
Phone: +49-241-80-21422
Email: kunze@comsys.rwth-aachen.de
Klaus Wehrle
RWTH Aachen University
Ahornstr. 55
Aachen D-50274
Germany
Phone: +49-241-80-21401
Email: wehrle@comsys.rwth-aachen.de
Kunze & Wehrle Expires May 7, 2020 [Page 8]