Face-to-face Internet Engineering Task Force (IETF) meetings returned this past July in Philadelphia, USA, where approximately 1,300 participants registered to attend either in person or remotely.
The event allowed us to feel the warmth of seeing each other’s faces, and we returned to the casual encounters that were impossible during online events. Once again, we were able to share designs and diagrams and talk about different aspects of Internet architecture in groups, sitting around small tables in the hotel lobby or bar, or in the event room.
Technology News. What struck me about the sessions of the Internet Research Task Force (IRTF), a IETF sister group focused on long-term research, was the emphasis on applying machine learning techniques to networking problems. Two Stanford University presentations highlighted research on the use of machine learning to automate Internet traffic management.
(Free access, no subscription required)
The use of these techniques would allow identifying applications that are running on the network, apply a differential treatment, and provide them with bandwidth and other quality-of-service parameters based on their individual characteristics.
In relation to the Internet of Things, I found the Performant TCP for Low-Power Wireless Networks to be very interesting. The authors of this work show that, by implementing a series of optimizations and assuming certain commitments, TCP can be used in families of devices with very limited resources. This opens the door to certain applications that are not mapped over UDP and avoids having to “reinvent” certain TCP functionalities such as the recovery of lost packets in each application protocol.
As for the IETF sessions themselves, I’d like to highlight the work being done by the IPv6 Operations (v6ops) Working Group. This group develops guidelines for the deployment and operation of new and existing IPv6 networks.
The use of these techniques would allow identifying applications that are running on the network, apply a differential treatment, and provide them with bandwidth and other quality-of-service parameters based on their individual characteristics.
In relation to the Internet of Things, I found the Performant TCP for Low-Power Wireless Networks to be very interesting. The authors of this work show that, by implementing a series of optimizations and assuming certain commitments, TCP can be used in families of devices with very limited resources. This opens the door to certain applications that are not mapped over UDP and avoids having to “reinvent” certain TCP functionalities such as the recovery of lost packets in each application protocol.
As for the IETF sessions themselves, I’d like to highlight the work being done by the IPv6 Operations (v6ops) Working Group. This group develops guidelines for the deployment and operation of new and existing IPv6 networks.
One of the drafts presented at the meeting discusses how to properly use Unique Local Addresses (ULA) and the applicability of optional IPv6 headers. ULAs are the IPv6 equivalent of private IPv4 addresses. However, despite the fact that they were specified a long time ago, certain aspects of their operational application remain open to debate. The document titled “Unintended Operational Issues with ULAs” discusses some of the problems that have not yet been solved.
There is renewed interest in better understanding the behavior of optional IPv6 headers. Measurements from a few years back showed an unacceptably high drop rate for packets with optional headers. Now, another group of researchers is repeating these measurements in order to compare the current reality with the previous situation. This project was presented under the name of JAMES. I look forward to seeing the results that are achieved.
Another positive aspect of the IETF sessions turned out to be the work on origin validation (Source Address Validation Using BGP Updates). This is one of the great unresolved issues to prevent packet injection and therefore avoid denial of service attacks. Currently, existing techniques do not cover all cases or are not scalable.
This is why I found BAR-SAV, a document on how to use RPKI to perform origin validation, to be very innovative and promising. The BAR-SAV method consists of using the information contained in ROAs and introducing new messages of the BGP protocol.
The document presented during this past IETF advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). Network operators can use BAR-SAV to design more robust SAV filters and thus improve network resiliency.
In closing, a personal reflection. In my opinion, the Internet will always be a work in progress. Because of its very nature, the Internet needs to be in constant evolution. This is why I found it reassuring to see that, after two long years of physical distancing, the IETF community is still as vibrant as ever and ready to take on the challenges of continuing to build the Internet.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
