When the idea of participating in this hackathon came about, the goal was mostly to leverage FD.io’s Vector Packet Processor (VPP) as a platform and show its performance, capabilities, modularity and development simplicity. So we looked across existing IETF technologies and drafts which were not yet implemented in VPP and found out this new ILA technology (draft-herbert-nvo3-ila), which seemed to be a perfectly valid use-case for VPP used as a physical or virtual router.
What’s really fantastic is that the ILA draft author, Tom Herbert, as well as other very motivated people spontaneously volunteered to join the team. We ended up with a team consisting of folks in-between IETF standardization and Linux Foundation open-source software, and developed together from scratch, a full ILA implementation. In two days we went across many phases of standard implementation development, from understanding the draft, coding the first shot, testing it, to finally understanding the technology better and doing more with less code. Then testing again, and interoperating with an existing Linux implementation.
At the end of the second day of the hackathon, the newly created implementation, comprising most of the features specified in the ILA draft, was upstreamed to the main VPP repository. And performance tests of the yet-to-be-optimized code were showing promising results too.
Summarizing, this two-days project really showed how the IETF hackathon can facilitate joint collaboration between open-source and standardization people at very early stages of drafts and implementation development, taking advantage of their complementing experience and knowledge and resulting in better standards and optimized running code.
Pierre Pfister and Maciek Konstantynowicz
The ILA team was: Pierre Pfister, Tom Herbert, Maciek Konstantynowicz, Damjan Marion, Shwetha Bhandari, Bill Cerveny, Ignas Bagdonas, Ole Troan, Wolfgang Beck
I arrived in Berlin today, but there are many volunteers and support vendors who arrived days earlier to prepare for the meeting. It takes a lot of effort to setup the network, for instance. The team reports that the network is up and running, and that they have taken over the hotel network as well.
Some minor routing issues with some destinations were seen earlier on v6, but the team is fixing that. Everything should be running smoothly, but if not, please drop us a note.
We all are grateful for having this team work for us! Thank you!
Interestingly, at this IETF we’re for the first time implementing the BCP-38 (ingress filtering) policy on our routers; Jim Martin and Warren Kumari wrote a script to automate that setup. I talked to Jim a bit about the arrangements, and thought it was a good demonstration of how some good things in the Internet are fundamentally hard, and require some effort. There is no “apply BCP-38” button on most routers But maybe there should be?
The team has also deployed a monitoring mechanism to follow what’s going on in the network. You can see it on the left in the picture below, whereas on the right you see some nice art
I was also positively surprised by the amount of activity already going on in the hotel in other efforts, such as the MAMI network measurement project meeting, ETSI interop, the Cryptec meeting, and probably many things that I didn’t know about. One of the purposes of the IETF meeting is to be a place for all kinds of hallway conversations, testing, and other discussions to take place, alongside with the actual working group meetings.
For the weekend, I’d like to highlight the following activities:
IETF Hackathon: Come build your favourite new tech! The Hackathon runs mainly during Saturday and Sunday, but we’ve also reserved some space in the IETF lounge throughout the week of IETF to help and encourage people to continue to collaborate with their colleagues on various hackathon projects and activities. This is not meant to compete with sessions but rather to provide an opportunity for those without packed agendas to make better use of their otherwise free time. We will see how things go in Berlin, and we welcome your thoughts and suggestions on improving the Hackathon at any time. More information about the Hackathon can be found on the web, and more about the week-long Hackathon experiment here.
IETF Code Sprint is running on Saturday, please join and program the IETF tools that you need. See the Code Sprint web page for sign-up and other information.
Applied Networking Research Workshop (ANRW) runs on Saturday, and focuses on interesting research results. Join the workshop, details
at the workshop page.
Tutorials run on Sunday, and include both newcomer’s orientation to the IETF and discussion of new work in IEEE 802. The orientation is available both in English and German. See the agenda for the sessions.
For next week, the meeting rooms are ready. This is the plenary room:
During nearly every IETF meeting since 1993, an informal gathering of women participants, the Systers, has taken place. We chose the name Systers as an answer to the late Anita Borg’s call for women in computer systems to support and celebrate each other.
In 2013 and 2014, gifts by Comcast, EMC, and Verisign Labs established a lunch fund for the gathering. For most of the participants, the Systers gathering is a chance to catch up with friends across all areas of the IETF, to employ an informal mentoring and information gathering forum, and to encourage each other in a largely male-dominated field.
The Systers IETF list, email@example.com, offers this kind of support before and after the face-to-face meetings. The list is for Systers involved in IETF topics–both technical and specific to women.
Traffic is typically light with some discussions, but mostly for organizing per meeting gatherings. The list is open to any woman interested in the IETF, whether she participates only by mail or also in person.
Women participants, please consider joining us for the Systers lunch at IETF 96. We always hold our lunches on Thursdays. We haven’t set a location yet, so join the firstname.lastname@example.org mailing list so you can RSVP and get location information. To join the list, or if you are interested in learning more about the Systers or contributing to our fund, please contact email@example.com.
In my experience it is important that we talk to each other, all of us, the techies, the operators, the economists, and the policy people. We live in a connected world that is developing very rapidly, and none of us have a full picture of everything. It benefits us to share our views and increase our understanding.
I want to start off with a personal perspective on three areas where mixing people with different backgrounds has been very useful.
My perspective comes from the technical community, and IETF in particular. The Internet Engineering Task Force works on core Internet technology standards. It is an open community, it has no members or membership fees, to get started you just need to join a mailing list. There’s a few thousand active people on our lists, from developers to researchers to operations people, with some policy and regulator folk mixed in as well.
One of the things we learned on so many occasions at the IETF was that you can not fully separate technical questions from other ones. Take economics for example. Technology choices affect deployment incentives, for instance. I find myself wishing for an economist for my developer teams.
And that is perhaps as expected, but technology questions are intertwined with more general policy questions as well. I became the IETF chair three years ago, and thought I’d mostly deal with boring organisational or technical issues. Then Snowden happened, and suddenly we had to figure out how well the Internet protects its users, what the right thing was, and if the IETF had any role in making improvements. We did, of course. But I find that Internet security is another area where shared understanding is useful. I keep wishing for an engineer in every politician’s team…
My third example is the discussion of Internet’s administrative mechanisms, namely the IANA stewardship transition project. When I first thought about IANA, my views were very focused on just one small part of it, the protocol parameter registries. But the overall community had a much broader perspective. I’m happy we decided to deal with the bigger picture, and very happy with wide-spread support and interest for this in the world. The transition would not be possible without it.
But I also wanted to talk about Internet evolution in general. The only constant seems to be change. We need to avoid us established engineers or other players working towards just our own perception of the world, as the younger generations keep redefining what is needed. The changes are not just about delivering a service in a new way, they are more fundamental.
An example: traditional TV business is changing radically. Partially because the underlying technology changes to IP-based distribution. But also because the whole concept is changing from linear TV to different services. This changes not just how the bits are transmitted, but who you interact with, who the players are, and what kinds of business models apply. My kids don’t watch TV channels at all, they follow individuals on youtube. And who knows what they will do in five years.
At the IETF, some of the things that I think have a big impact on Internet include the further evolution of the web, security and privacy work, real-time communication from browsers, virtualisation, software- and data-driven networking, and the Internet of Things.
You may think of the web technology platform as relatively stable while the applications on top of it are evolving rapidly. But I’m seeing a lot of change in the platform as well. Last year, we published HTTP version 2 which was internally a complete redesign. In July, on our next meeting in Berlin, we’ll be discussing something called QUIC (Quick UDP Internet Connection), an ever bigger change impacts the foundations of Web technology, including the traditional split of layers to TCP, transport layer security, and HTTP. We are also working together with W3C on something called WebRTC, putting real-time communications and phone calls to browsers, enabling any website to use the technology that today is available from applications such as Skype. And these changes see very large scale deployments.
Similarly, we’re seeing a big change in how people use security and privacy in the Internet. Through the choices of various web sites, the amount of encrypted traffic in the Internet is rapidly rising. Because it fits their needs.
This is partially related to pervasive surveillance concerns as well. The IETF has always worked on Internet security, and even more so in the last three years. We’ve changed security algorithms that are no longer trusted. We’ve published recommendations on how applications can use security mechanisms. We’ve built technology such as HTTP version 2 that makes the use of security less expensive. We’re working protocols that allow DNS queries to be done in a private fashion.
I also wanted to touch on economic and policy challenges with respect to the evolving Internet.
Take for instance interoperability and the Internet of Things. The Internet Architecture Board of the IETF recently held a workshop on application-level interoperability. While many or most systems today can be a part of the same underlying network, it is still a problem to connect the systems together at an application level. I don’t want to buy a Microsoft house and find out that I can’t use Apple lightbulbs with the light switches.
To take an another example from the Internet of Things area: It is a natural inclination for us to frame the policy issues in the context of our past experiences. But it takes time to apply policy, and by then the actual issues in the Internet may have changed. We’ve talked for a long time about being able to connect everyone on the planet. I personally believe we actually get to do that real soon, but does it stop there? Will we be able to introduce smart farming in fields of Africa? We do not need to connect only the people. It is time to look further into the future.
And to finish, more than these specific changes and challenges, what really matters is the principles. Not just because they are the right thing to do, but because they actually work and allow the kind of parallel, global progress that’we seen in the Internet.
These principles include working in a multistakeholder and open manner. They also include the concept of permissionless innovation, voluntary standards, and the power of code and open source collaboration, rather than top-down design.
(This blog article is based on a talk at the OECD meeting on digital economy in Mexico in June 2016. As a side note, a big part of the OECD meeting and focus of much of the discussion was a Hackathon that they run. I am glad that the participants, regulators and policy makers got a feeling of how Internet innovation advances in practice. But I don’t think any of the politicians participated the actual hacking. At least not in in this meeting yet.)
I wanted to provide a brief update on the the progress of the www.ietf.org website revamp project, which began in earnest last year and is scheduled to move into production by the end of this year.
As the scope of work developed with input from the IETF community specified, we have been working with the selected vendor, Torchbox, to develop a site that reflects the IETF’s position as the premiere Internet standards organization. Beyond updating and improving navigation and the visual design, the revamped site will work better for all classes of devices, including smart phones and tablets. It is also designed to improve accessibility and to work well for visitors using low-bandwidth and high-latency connections.
Of course the revamped website must work well for current IETF participants. But it also aims to serve *potential* IETF contributors by making it easier for them to get started in the IETF, and it aims to ensure that even people who aren’t likely to be contributors can understand what the IETF does and how it works. A goal of the project was to develop a design informed by data, so we interviewed people from each of these groups. We also looked at usage data available from the current website and benchmarked against websites of similar organizations.
Since sharing the initial design and prototype at IETF 93, the project team has been working on fine-tuning the design and transitioning content. The IETF Tools team has also been involved so that the information about RFCs, IETF Areas, and working groups displayed on www.ietf.org is drawn directly from datatracker.ietf.org. This will make it easier to keep the www.ietf.org site current, and provide opportunities to guide people to the ongoing work of the IETF.
Work is still underway to finalize the content and features on the new site, including additional testing with the target audiences to be sure it works for them. The current project schedule calls for an extended “preview” of the new site so the entire IETF community will have a chance to try it out before everything is finalized. I expect to have a further update on the exact timeline in the next few weeks.
Joe Hildebrand, Project Manager
Screenshot of the Revamped IETF Blog
Example of a revamped information page about an IETF Area
An example of the responsive design for an IETF Blog post
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:
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!
In the midst of a day’s discussion about particular issue that troubles us with technology or something else, it can be difficult to focus on topics that have a longer timescale. As you probably remember, I had asked a design team to write a draft about various trends around us that affect the IETF.
We got some feedback on that draft, but the draft stopped short of making specific statements about what the IETF should do. And unless we bring the thoughts to a bit more practical level, the discussion stays abstract and remote.
So, I thought I’d try to state my view about what we should focus on in the future, in the hopes that it will generate discussion. Feel free to suggest alternate views or question these!
I claim that we need to do four major things:
1. Make it easier for people to be involved in the IETF.
2. Be even better positioned to use online collaboration.
3. Focus on linking open standards to code, operationals, and interoperability.
4. Evolve IETF sponsorship models to focus more on our work than meetings.
The first two items are about improved ability to people be involved in IETF work in different ways, and at low cost level. We need open an source developer to come collaborate on a standard for the duration of his or her project, without requiring a multi-year learning project to do it. We need people with too little time on their hands or too little travel funds to be able to participate more fully in the virtual IETF. This requires some practical changes, such as evolving our tools. But it will also require cultural and maybe process changes, if we are to enable, for instance, people with experience but not much IETF experience to be able to drive things more fully.
We have also been searching for our place in the world of many different forms of collaboration. Standards vs. open source, for instance. I think a natural place for the IETF to sit in is in the borderline between code and standard; hence hackathons, interops, and operational experience need to form an even bigger part of our gatherings than they are today.
Finally, as you know the IETF operations are funded from three sources: The Internet Society, meeting fees from our participants, and sponsorships. I’ll note that two thirds of that is tied to meetings, and re-balancing that differently is probably prudent. For instance, the sponsorship part could perhaps move from current meeting host model to other models that are more based on the work that we do. This wouldn’t be a change to who our funders are or how much financing is needed, but rather a change of the format.
But these are just my initial thoughts. Please discuss! The best place for discussing this on the IETF main discussion list, firstname.lastname@example.org.
Today the US Department of Commerce National Telecommunications & Information Administration (NTIA) announced that the Internet community’s proposal to transition the stewardship of the Internet Assigned Numbers Authority (IANA) functions meets the criteria it set out for the process (source).
This is good news and an important milestone. It is also another indication of the strength of the IANA system and the multistakeholder community caring about it, and one more step to ensure the long term health of a free and open Internet.
The transition plan has been developed in the community. One part of the plan, the one dealing with protocol parameters (such as port numbers) came from the IETF and its IANAPLAN working group. NTIA’s assessment of the protocol parameters part can be found here.
The implementation efforts related to the plan are ongoing. As always, the Internet community needs to take care of the IANA system on a continuous basis. And we will — together, in a multistakeholder fashion.
If you have followed the IETF discussion list recently, you’ve probably seen a thread about a planned meeting in Singapore next year. Traditionally, the IETF announces meeting sites as they have been contracted. After announcing Singapore during IETF-95, we heard from our LGBTQ participants that laws in Singapore make their participation (particularly when they travel with their families) a concern.
Obviously, we all at the IETF value and respect the LGBTQ participants and their families, and it was not an intent to make them feel unwelcome at any of our meetings. The IETF needs a meeting that we are happy with.
But what is the situation, and what is the IETF doing about it? It should be recognised that the discussion about this topic has been difficult. To begin with, we have struggled with agreeing on the specific situation on the ground in Singapore. I suppose part of the difficulty is whether one looks at the practical situation or considers the consequences should the risks be realised. Or takes the position that mere existence of a law is discriminatory. There is disagreement where people can reasonably take different views. Bridging those differences is, perhaps, not a reasonable goal.
And past mistakes aside, no decision in this space will be perfect. We knew that no matter what choice is made, there will be groups of people who feel they are unfairly impacted.
That all being said, it is a good thing when a community can discuss its sensitivity to various issues, approach to diversity, expectations on meeting sites, and so on. I’m proud that the IETF can do that, and do that in the open. The situation is not the same in all organisations. Obviously we can improve on this too, and some improvements on crowd-sourcing some of the evaluation of potential meeting sites is already in progress.
Families and companions have generally not factored into the meeting site selection process in any way in the past. However, during this discussion I believe an understanding of the issues related to situations where families sometimes need to travel with a participant has increased. This recognition has been a useful lesson, and can be applied in future.
But perhaps the most important thing is that, long-term, the community needs to be in charge of what they expect from meeting locations, that we all learn more about the various challenges discussed, we are an open organisation for everybody, and that we improve our processes going forward. It is also crucial that the IETF remains an organisation that can do its technical work, and be open to all of our global participants in a fair manner. And obviously be capable of arranging our operations in the real world, in areas that our participants come from.
Our administrative committee is in charge of contracting at the IETF, including making meeting site and hotel decisions. The IAOC has concluded that under the circumstances and having to choose between a number of imperfect options, Singapore is still our destination in 2017. In addition, I have been working with the IESG to determine what we need to do as a community to ensure that we have proper understanding and documentation of community’s requirements for meetings. Our action plan includes the following:
o Charter a working group to specify an RFC for detailed meeting selection criteria.
o Specify another RFC for the official policy regarding geographic meeting distribution. Our current strategy involves rotation through the continents that have most IETF participants.
o Arrange a special session in IETF 96 in Berlin to discuss the role of human rights, visas, and other aspects of international meeting arrangements.
o Commit to a proper, informed process to identify issues that any subgroup (including but not only the LGBTQ community) has with our site selections.
o Commit to sticking better with our policies on geographic distribution, where we’ve failed to meet as often in Asia as we perhaps should have.
o Continue to work further towards enabling even more virtual collaboration options, in and outside meetings.