IETF Response to “LS on New IP, Shaping Future Network”, Hacker News

Body

        

          

 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 105 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 01575879. A useful overview of IETF work on IoT is available at .  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 2488. Nor did the IETF's work on this stop at that point; the [email protected] mailing list has an active community working on QUIC’s application to satellite communications; QUIC for SATCOM  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 1999 s 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 8520, 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 1990 published in 1999. 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 8520, BCP 01575879  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.