IETF News

IETF Ornithology: Recent Sightings – November 2016

By: Mat Ford

line break image

Getting new work started in the IETF usually requires a birds-of-a-feather (BoF) meeting to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and the level of interest in and support for the work. In this article, we’ll review the BoFs that took place during IETF 96, including their intentions and outcomes. If you’re inspired to arrange a BoF meeting, please be sure to read RFC 5434, “Considerations for Having a Successful Birds-of-a-Feather (BoF) Session.”

International Meeting Arrangements (imtg)

Description: This meeting was an educational session for experts to share knowledge about human rights, business, and strategies for navigating human rights issues within the IETF’s operations.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-imtg

Outcome: The community received helpful expert input and a constructive discussion occurred. The session was explicitly not to make any recommendations.

Low-Power Wide-Area Networks (lpwan)

Description: A new generation of wireless access technologies has emerged under the generic name of Low-Power Wide-Area (LPWA), with a number of common characteristics that make these technologies unique and disruptive for Internet of Things applications. Typical LPWA Networks use license-exempt bands to provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles. Existing pilot deployments show the huge potential and meet industrial interest, but the loose coupling with the Internet makes the device management and network operation complex and implementation specific. There currently is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability to contribute to the emerging needs of these technologies, in terms of longevity, scalability, or better integration to existing systems and processes. (See article, Working Group Update: 6LO.)

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-lpwan

Outcome: This was a productive meeting that identified several potential work items for a new IETF working group to take on. Since the meeting a proposed Working Group charter has been circulated for review by the community and it is likely that a newly formed working group will meet during IETF 97 in Seoul.

Low-Latency Low-Loss Scalable Throughput (l4s)

Description: L4S provides a mechanism to allow scalable congestion controls, like Data Centre TCP (DCTCP), to coexist on the public Internet with preexisting classic congestion controlled traffic. L4S is made possible by the introduction of new active queue management (AQM) technology that isolates scalable and classic traffic in terms of latency, but behaves as a single queue in terms of bandwidth. The purpose of this non-WG forming BoF was to inform the community about these developments and to gather feedback.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-l4s

Outcome: A good discussion was had and the proponents provided a very impressive technology demonstration as part of their presentation. The work is likely to move forward as multiple, discrete work items in existing Transport Area Working Groups.

Limited Use of Remote Keys (lurk)

Description: HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. Currently, most trust models assume that private keys are associated and owned by the HTTP server and that the server is responsible for both the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of Internet services largely relies on multiple distributed instances of the service. In such architectures, the application expects to authenticate a content provider but is actually authenticating the node delivering the content. Since the first BoF during the IETF 95 meeting in Buenos Aires, mailing list discussion has established that there is interest in dealing with the “offload transport security without giving the Content Delivery Network my private key” use-case.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-lurk

Outcome: Potential approaches to addressing the identified use case were discussed and a number of serious challenges identified. There was no support for forming a Working Group, although some aspects of the work may be pursued in existing working groups (acme).

Intelligent Transportation Systems (its)

Description: The goal of this group is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks. The group is now focussed on specifying mechanisms for transmission of IPv6 datagrams over IEEE 802.11p OCB mode.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-its

Outcome: This was a good discussion and the narrow focus on adapting IP for use over a specific link-layer technology helped the group to make progress. Coordination with the Institute of Electrical and Electronics Engineers (IEEE) was identified as important and the group has since progressed to forming an IETF working group, IP Wireless Access in Vehicular Environments (ipwave), that will meet for the first time during the IETF 97 meeting in Seoul.

Path Layer UDP Substrate (plus)

Description: The goal of this proposed Working Group is to enable the deployment of new, encrypted transport protocols, while providing a transport-independent method to signal flow semantics under transport and application control. The initial approach uses a shim layer based on the User Datagram Protocol (UDP), which provides compatibility with existing middleboxes in the Internet as well as ubiquitous support in endpoints, and provides for userspace implementation. This effort follows on from the spud BoF in Dallas and the spud prototyping effort.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-plus

Outcome: This was a very well-attended and contentious meeting. It was clear that there was insufficient consensus for this work to proceed in its current form. More work is required on the problem statement, analyzing previous work addressing similar problems, and building a larger community of people interested in this approach.

QUIC (quic)

Description: QUIC is a UDP-based transport protocol that provides multiplexed streams over an encrypted transport. This BoF proposed formation of a Working Group to standardize QUIC’s core transport protocol and the mapping of the transport protocol to the facilities of TLS. An additional work item will be to describe how to map the semantics of applications onto the transport. The first mapping will be a description of HTTP/2 semantics using QUIC.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-quic

Outcome: Around 400 people attended this session! This was a very well-organised meeting with clearly defined work and strong consensus that the proposed charter was good. Since the meeting, a new quic IETF Working Group has been formed in the Transport Area.

Ledger (ledger)

Description: Moving digital assets (making payments) between accounts operating on different payment networks or ledgers is not possible in an open, interoperable way. Interledger is a protocol stack for doing this (tranfering digital assets) over the Internet. The project was started within a W3C community group in October 2015 and has produced a number of technical specifications which are candidate Internet-Drafts. It defines a set of formats for representing digital asset transactions and protocols for executing those transactions in a secure and verifiable manner.

The purpose of this BoF was to introduce Interledger and the underlying protocols and to discuss how this work might progress at the IETF.

Proceedings: https://www.ietf.org/proceedings/96/minutes/minutes-96-ledger

Outcome: This was a non-WG forming BoF. It provided an opportunity for information sharing with the community and exploration of the potential for future IETF work. There was no clear consensus about bringing this work into IETF, and discussion is continuing on the mailing list.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *