Skip to main content

Shepherd writeup
rfc8803-19

1. Summary

The document shepherd is Michael Scharf. The responsible Area Director is Mirja
Kuehlewind.

This document specifies an application proxy, called Transport Converter, to
assist the deployment of TCP extensions such as Multipath TCP. This proxy is
designed to avoid inducing extra delay when involved in a network-assisted
connection (that is, 0-RTT). This specification assumes an explicit model,
where the proxy is explicitly configured on hosts. The proxy can be installed
in managed networks by a network operator, for instance to help the deployment
of Multipath TCP.

While Multipath TCP is an important use case, the Convert Protocol can actually
be used for several TCP extensions. As the protocol is highly related to TCP
standards and not specific to Multipath TCP, it was decided to home this
document in the TCPM working group. The TCPM working group requests publication
as Experimental document because the protocol targets controlled environments
in which all network attachments are managed by the same administrative entity.

2. Review and Consensus

TCPM usually deals with end-to-end TCP extensions, not with proxies. A number
of active TCPM contributors also participate in the MPTCP working group, and
they have been the drivers of most of the TCPM discussions.

The document has been presented and discussed repeatedly in TCPM and as a
result the protocol has changed several times. One frequently discussed design
choice is whether and how to use TCP Fast Open (TFO). Appendix C explains the
rationale for the final solution. There have also been some discussions whether
such a proxy is really useful and needed. Some few contributors to the working
group were not convinced by the MPTCP use case. During WGLC, Philip Eardley
(chair of the MPTCP WG) has performed a comprehensive review, which was
subsequently addressed in a number of document updates. The shepherd has
reviewed the document before WGLC and verified that all WGLC comments are
addressed. In addition to that, several contributors from vendors and network
operators have explicitly expressed their support before and during WGLC. It
has also been mentioned that the protocol is of interest to 3GPP. In TCPM,
there is very strong but not unanimous support for publication as experimental
document.

There is at least one known implementation: Tessares has an open-sourced a
library (https://github.com/Tessares/libconvert) and a closed-source Hybrid
Access Gateway (HAG) that uses this library directly to act as an MPTCP
Converter. Korea Telekom (KT) has reported to TCPM the results of a PoC using
these implementations (see
https://tessares.pr.co/181810-kt-tessares-successfully-test-5g-low-latency-multi-radio-access-technology-in-a-commercial-5g-network).
Other vendors have also expressed interest, but there is no publicly known
second implementation.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

There is an IPR disclosure related to the document:
https://datatracker.ietf.org/ipr/3616/

The TCPM working group is aware of the IPR disclosure and the chairs have
explicitly informed the working group about the IPR. Also, there has been an
earlier disclosure (https://datatracker.ietf.org/ipr/2726/drafts) on a
predecessor document, which was originally discussed in the MPTCP WG. There
have been no comments or concerns in TCPM regarding the IPR.

The document describes an experimental protocol that is currently mostly of
interest to MPTCP deployments in controlled environments. It is possible that
the TCPM working group would be more concerned about IPR for a standards-track
RFC.

4. Other Points

The document requests a TCP port number and creates IANA registries for
protocol parameters. There has been some discussion on the allocation policy
for the registry ("IETF review" required), but no controversy. The TCPM working
group only seldom deals with new IANA registries and there may not be much
expertise regarding details.
Back