New Topics at the Berlin Meeting

East_Side_Gallery

I wanted to report what new ideas are going to be discussed at the meeting in Berlin in July.

New work can be introduced to the IETF various ways. The charter of an existing working group can be extended. A topic may be defined clearly enough so that a new working group can be created directly. A Birds-of-a-Feather (BoF) session can held to discuss whether some new work is warranted and what the scope of that new work might be.

Before every meeting, the IESG and IAB discuss what proposals we have received for new work. We then decide in what form and if they should proceed. We just had such a discussion last Friday, and I wanted to report on what we are now expecting in Berlin. It looks like we have a set of very interesting topics:

LEDGER: This proposal relates to the popular topic of using cryptographic ledgers to track assets. Bitcoin does this with currency, but the technology could support other types of applications. However, moving digital assets between accounts operating on different payment networks or ledgers is not possible today in an open, inter-operable way. LEDGER wants to discuss a protocol stack for such transfers. The project was started originally within a W3C community group. That group had produced a number of technical specifications, and they could become Internet Drafts. One initial draft related to this effort is draft-thomas-crypto-conditions.

QUIC: QUIC is a UDP-based transport protocol that provides multiplexed streams over an encrypted transport, originally from Google and with plenty of deployment experience. This BoF proposes a working group to standardize a new transport protocol based on experience with QUIC’s core transport protocol and the mapping of the transport protocol to the facilities of TLS. An early version of a charter for the eventual working group is here. The working group will start its work based on technologies that are already partially deployed in the Internet, and therefore standardising them in a consolidated way provides the basis for larger deployment in future. Obviously, transport services underneath the web have the potential for having a big impact in Internet traffic. Three initial drafts can be found here: ​draft-tsvwg-quic-protocol, draft-tsvwg-quic-loss-recovery, and draft-thomson-quic-tls.

LPWAN: This BoF focuses on low-power wide-area networks. Typical LPWAN networks provide low-rate connectivity to large numbers of battery-powered devices over distances that may span tens of miles. Would these networks benefit from Internet technology, and if so, how? Currently many of these networks are not based on IP. Some initial drafts on this topic include the gap analysis (draft-minaburo-lp-wan-gap-analysis) and the design space (draft-gomez-lpwan-ipv6-analysis).

PLUS: This group’s acronym comes from “Path Layer UDP Substrate”. The group’s goal 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 working group expects to implement a shim layer based on the User Datagram Protocol (UDP). This provides compatibility with existing middleboxes in the Internet as well as ubiquitous support in endpoints, and provides for userspace implementation. Note that this effort follows from the SPUD BoF in Dallas and the SPUD prototyping effort, and preparation for the BoF has taken place on the SPUD list. Some early drafts are here: draft-trammell-spud-req and ​draft-kuehlewind-spud-use-cases.

L4S: This group is working on transport mechanisms for achieving both low latency and low loss, while accommodating scalable throughput. Early tests indicated that L4S can keep average queuing delay under a millisecond for all applications, even when together they add up to a heavy load, while keeping congestion loss minimal and utilisation high. The group will discuss whether improvements of this nature can be achieved in the greater Internet, and if IETF standards are needed. There are a number of early drafts, such as draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem and draft-briscoe-tsvwg-ecn-l4s-id.

ITS: This BoF focuses on Intelligent Transportation Systems. The goal of this group is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks. Draft charter can be found here and here are some initial drafts: ​draft-petrescu-its-cacc-sdo, ​draft-jeong-its-v2i-problem-statement, and ​draft-petrescu-its-problem. One of the questions is if the parties focusing in transportation systems (such as automakers) are interested in joining this effort.

LURK: This working group, Limited Use of Remote Keys (LURK) focuses on using a large-scale CDN to provide access to a web site that employs HTTPS. Ideally, such distribution should be possible without having to copy the private keys associated with the web site to too many places.

IMTG: As you’ve probably read on the IETF discussion list, we’ve had a long debate about our meeting locations next year. The MTGVENUE working group (details below) is being chartered (and will meet in Berlin) to discuss the requirements for our meeting sites. In addition, we’ve added the IMTG session in the agenda to talk about international meeting arrangements from the point of view of human rights, visas, and to get some advice from experts outside the IETF in these topics.

MAPRG: This research group, Measurement and Analysis for Protocols, provides a forum for interchange of measurements and ideas between researchers and protocol engineers. It is a proposed research group (though they have met before).

NMLRG: As with MAPRG, the Network Machine Learning Research Group is still in proposed stage. They will be meeting in Berlin to further discuss the application of machine learning in networking.

There are also other big new topics to discuss, but are being discussed in existing meetings. The two ones that I am aware of are:

DISPATCH: This working group will discuss, among other things, the Glass to Glass Internet Ecosystem (GGIE) topic that looks at video and streamed content from a system perspective. Streamed content delivery could be viewed like a composed flow combining many parts, with playback composed of one or more component streams from one or more addresses to one or more devices over one or more networks. When looking at the system, a number of missing parts in current video streaming solution can be identified. Is there a need to do more IETF work in this space? One initial draft is draft-deen-daigle-ggie.

ICNRG: Information Centric Networking (ICN) has been a popular research topic. Several variants exist, but the basic idea is a new type of Internet architecture based on requesting and receiving data identified by name, rather than sending to and receiving from an address. There is interest in bringing some of this work to a state where it could be more widely used and experimented with. Should the IETF produce RFCs on this topic? The ICN Research Group will be talking about the state of this work, and what parts are ready to progress further.

Finally, we also have several working groups that are in the process of being formed. They are temporarily labeled as BoFs until they become formally approved. These are:

MTGVENUE: This working group will discuss criteria and policies related to the selecting of IETF meeting venues. Two initial drafts are draft-baker-mtgvenue-iaoc-venue-selection and draft-krishnan-ietf-meeting-policy.

BABEL: This working group will document the Babel routing protocol. This protocol is used among other things in home networking environments.

SPASM: This working group’s acronym comes from “Some PKIX and S/MIME”. The group plans to publish some updates to these technologies, in cases where real deployment and real need can be identified. Currently, the group plans to look at ways to include an i18n email address as a subject alternative name (see draft-melnikov-spasm-eai-addresses) and the use of authenticated encryption in S/MIME (see draft-schaad-rfc5751-bis).

SIPBRANDY: This working group’s acronym comes, obviously, from SIP Best-practice Recommendations Against Network Dangers to privacY. The group focuses on end-to-end protection mechanisms for real-time communications environments, in an effort to avoid man-in-the-middle attacks and privacy violations.

Got any thoughts on these or other topics? Join the mailing list and the discussion!

Jari Arkko, IETF Chair

Photo credits Wikimedia.