Liaison statement
Response to "LS on New IP, Shaping Future Network"

Dear Colleagues,

The Internet Engineering Task Force (IETF) appreciates the opportunity to
respond to your liaison statement. While we understand the Telecommunication
Standardization Advisory Group (TSAG) meeting at which these comments might
have been considered is past, we request that they be considered in the process
leading up to the World Telecommunication Standardization Assembly (WTSA).

The IETF developed the TCP/IP protocol stack and we continue to maintain and
extend it. We believe the Internet’s success has resulted from its flexible,
modular architecture, with IP providing the fabric that connects an incredible
wealth of heterogeneous networks with an incredible wealth of heterogeneous
applications. We expect the existing protocol stack to continue to evolve to
meet the needs of new networks and applications, just as it has for more than
50 years. We have not seen any evidence of the need for a monolithic “New IP”
designed from the top down.

In reviewing the proposals included with your liaison statement, we find that
there are several statements that are unsupported or incorrect. The first of
these is: “Firstly, due to historical reasons, the current network is designed
for only two kinds of devices: telephones and computers.”

The fundamental design of the IP protocol stack is not limited to telephones
and computers, but encompasses a very broad range of devices, including many
that the proposals consider as future work. Work related to “Internet of
Things” (IoT) devices is, for example, noted as “the development of IoT and the
industrial internet will introduce more types of devices into the future
network.” Yet the integration of IoT devices on the Internet has been taking
place for over a decade. One of the relevant working groups in the IETF,
Constrained RESTful Environments (CORE), just passed its tenth anniversary;
during this period IoT devices have come to number in the billions. Much work
has already been done to integrate and manage these devices on the current
network, e.g., in RFC 8520. A useful overview of IETF work on IoT is available
at <https://www.ietf.org/blog/ietf105-iot-wrapup/>.

The proposals similarly treat the transport requirements associated with the
integration of satellite networks with IP terrestrial networks as a new
challenge. Yet RFC 2488, which describes TCP over satellite channels, was
published in 1999. Nor did the IETF’s work on this stop at that point; the
etosat@ietf.org mailing list has an active community working on QUIC’s
application to satellite communications; QUIC for SATCOM
<https://datatracker.ietf.org/doc/draft-kuhn-quic-4-sat/> is one contribution
to that discussion which touches particularly on the question of a non-TCP
protocol’s integration with satellite communications.

Another set of issues raised by the proposals were for use cases which are
asserted to require extremely low latency. Eliminating needless latency is, of
course, a useful engineering objective that both the IETF and the International
Telecommunication Union (ITU) have worked on extensively. The IETF’s work in
this area dates back to the 1990s and spans the development of such
technologies as Integrated Services (IntServ), Resource ReSerVation Protocol
(RSVP), Multiprotocol Label Switching (MPLS), Differentiated Services
(DiffServ), and Active Queue Management (AQM). Over the last five years we have
seen an intense focus in this area targeting HTTP; Transport Layer Security
(TLS); QUIC; Deterministic Networking (DetNet); and Low Latency, Low Loss,
Scalable Throughput (L4S), among others.

Applications that are regarded as having tight requirements from the network
with respect to properties like jitter, latency, and throughput are being
deployed on the Internet today without requiring the type of tight cross-layer
linkage that the proposals envision. This occurs within the constraints of
existing protocols and designs. These applications -- which include
conferencing, augmented reality, and gaming -- produce market pressure to
improve these characteristics for Internet protocols. Efforts to improve
coordination between network components or layers are ongoing in several areas
in the IETF. We believe that the efforts most likely to improve performance on
these metrics also recognize other constraints on design including business
imperatives, security, and privacy.  We expect those efforts to continue to
meet the needs of newer real-time applications, including holographic
communications, without the need for a new network architecture. We also note
that any real-time systems requiring sub-millisecond latency inevitably have
limited scope because of the constraints of the speed of light.

The proposals also presented several desired aspects of a new set of identifier
systems. One such statement was “Heterogeneous address space should be able to
communicate with each other.” This appears, however, to run counter to a desire
expressed elsewhere in the proposals: “If all technologies use their own
protocols as language to communicate internally, complex “translators” must be
employed for communication between islands.”

Disjoint addressing systems necessarily require independent routing to ensure
reachability in each system. While these may be layered (as SR-MPLS, documented
in RFC 8660, is layered on IP routing), using heterogeneous address spaces
without a common substrate implies complex translation to achieve interchange
among the different domains. Such translation likely increases fragility and
latency while requiring additional network state to achieve interoperability.

We understand this to be contrary to the design goal of interconnectivity
across heterogeneous networks. The IETF believes this design goal, which we
would commonly express as a requirement for interoperability, is critical to
the evolution of IP and the Internet (see RFC 1958 published in 1996).
Maintaining interoperability ensures that these new use cases are addressed in
a way that allows the envisioned systems to participate in the current network,
building on existing network effects and capitalizing on the investments in
infrastructure that have already been made. This is how all users of the
network come to reap the benefits of the “permissionless innovation” that the
Internet facilitates.

Based on the ongoing work at the IETF on real-time systems, on integration
among different terrestrial and satellite networks, and on new transports like
QUIC, the IETF believes that extensions of the current IP stack will allow us
to reach the goals set forth in the proposals you provided. We are happy to see
increased enthusiasm for these efforts, and we invite others to participate and
contribute to the ongoing efforts. To date we have received no formal
submissions for new work in the IETF that would extend or replace IP in line
with the proposals included in your liaison statement, but we are always
available to discuss the development of such submissions.

In recent years, IETF efforts have put an ever-increasing emphasis on
developing implementations and protocol standards in parallel such that the
experience gained with initial implementations and interoperability testing
gets fed back into the design of the standards. For example, the designs of
HTTP/2, TLS 1.3, and QUIC have benefitted immensely from dozens of
implementations that were developed alongside the standards development efforts
and tested at Internet scale. The success of future standardization efforts
will be highly dependent on how well real-world, multi-vendor implementation
experience can be fed back into the standards development process, as opposed
to attempting to anticipate needs and requirements so far into the future that
Internet-scale testing is infeasible.

It is not entirely clear from the proposals whether their intent is to extend
or evolve existing IETF protocols such as IP, or to replace them entirely. The
IETF maintains copyright and change control for the IP specifications in the
interests of global interoperability. If the intent is to extend IETF
protocols, we would like to draw your attention to the previously published
IETF Best Current Practice document “Procedures for Protocol Extensions and
Variations” (RFC 4775, BCP 125) which describes the general procedures to be
followed in extending or modifying IETF specifications.  Requirements for
extensions or modifications to IETF technologies must be discussed with the
IETF before any are worked on in other SDOs, including the ITU-T. We request
that the ITU-T encourage people in the ITU-T community who want to propose
changes or extensions to IETF technologies to bring their requirements or
proposals to the IETF and that the ITU-T not accept such proposals before the
IETF gets a chance to discuss them. The IETF will do the same for requirements
or proposals to extend ITU-T technologies.

In conclusion, we believe the creation of a top-down design effort to replace
the existing IP protocol stack wholesale would be harmful. Doing so would most
assuredly create network islands, damage interconnection, and jeopardize
interoperability. A top-down approach would fail to match the diverse needs of
the continuously evolving application ecosystem. We believe in the continued
modular, flexible evolution of the network and we welcome the opportunity to
work with all interested parties in service of it. We see no evidence that the
challenges described in the proposals cannot be met by continuing to evolve the
existing IP protocol suite.