Monthly Archives: July 2013

A Diverse IETF

I wanted to return to a topic that we have talked about before: increasing diversity at the IETF. The word ‘diversity’ is a catch phrase, but I’m talking about bringing different kinds of people into the IETF who have not traditionally been here. Making IETF inclusive for all participants. I am very proud to report that at this Berlin meeting, we have attendees from a record 73 different countries. It is rare to have an organisation that draws people from so many places. This is something to be proud of.

But this is not enough. We need to go further. And I want to talk about the motivation in more depth. Why do we need to strive for a more inclusive IETF? And what are we doing about it? With this in mind, I worked with Pete Resnick to talk about our goals:

First off, we have room to improve. Geographic diversity is just one tiny aspect of the overall goal. What about vendors and operators? More academics? Gender diversity? Reaching to the areas of the world where there is still relatively little participation? Helping different participants to become editors and leaders? Coping with different discussion cultures? We recently talked to someone who classified the IETF as a “harsh” environment. IETF discussions go very quickly to critique and criticism of proposals, often in unnecessarily dismissing manner. Food for thought for all of us to improve our communication?

Secondly, diverse teams work better. They have more experiences to draw on. They have several problem solving and communication styles. Thirdly, the world competes for talent. The IETF needs to welcome everyone.

So, what are we doing? We can not claim we have made much of an impact yet, but we have started a number of efforts that will hopefully lead to great improvements in the long run. The Internet Society is helping us by increasing their outreach and fellows programs. Our Administrative Committee is planning an upcoming meeting in South America. Our leadership wants to get involved in a number of other forums and local events. We created a design team to understand the diversity problem and suggest solutions to make the IETF more inclusive. Volunteers created a mentor program that helps newcomers get introduced to the IETF. And there is a record 265 newcomers in this meeting.

This is all great, but it is good to keep in mind that we have only started our journey. There is a lot of work ahead. And we are probably missing many things that we should be doing. Please send us feedback!

Jari Arkko, IETF Chair and Pete Resnick, Applications Area Director

P.S. We wanted to thank Kathleen, Suresh, Mary, Adrian, Brian, Alissa, Barbara, and others for interesting discussions in this space.

The Role of Working Groups

A while ago I wrote about the issue of the IETF document process being quite heavy-weight in its final stages. Documents go through a lot of review and changes in their last few months. Some of this is natural as the document gains more exposure.

But often difficult tradeoffs get re-discussed at this stage, late surprises are discovered, and significant document changes occur. And since the documents are within the responsibility the IETF steering group (IESG) during the final stages, this leads to a situation where much of this process is managed by the steering group. But letting the working groups drive their technology and be responsible for changes would be better. A distributed organisation scales better, and the working groups are also equipped to involve the individual participants.

We are now experimenting with three changes to improve this situation. These changes are small, but we are hoping that they will have a positive effect.

  1. Perform some reviews that are now happening at IETF Last Call a bit earlier. This will put the working group in a bigger role in resolving cross-area and general issues.
  2. In the IETF, each document that passes through the approval process has a document shepherd. They are usually the working group chairs. We have started to invite document shepherds on IESG voice calls when there’s a document that is likely to require discussion. This will make it possible for the document shepherd to be involved in all the discussions.
  3. When a document has a number of issues, hand over the process back to the working group, as opposed to the IESG tracking the issues. Among other things, this will ensure that changes are discussed in an open working group list and agreed through consensus.

While these changes do not by themselves decrease the amount of work done in the final stages, we believe that if successful, this experiment will enable working groups to deal with issues before IETF Last Call and IESG review and empower the working groups to be in charge of the documents throughout their life cycle. We are also hoping that document quality will improve and number of issues discussed in the IESG will be lower.

Discussions are ongoing with the IETF working group chairs and review teams about the practical details of this experiment. Review team members may be asked to review a document when the work has finished in the working group but before an IETF Last Call is started. Working group chairs may ask for these reviews, and if they do, they will be managing the discussion with the reviewer and the working group carefully.

The IETF review teams – such as the Security Directorate (SecDIR), Applications Area Directorate (APPSDIR), or the General Area Review Team (Gen-ART) – have gained a significant role in ensuring that the IETF produces high-quality, understandable and implementable RFCs. In order to avoid overloading these teams, the teams may only take on some early reviews. The experiment will be evaluated after six months to determine whether the practice has been useful.

Jari Arkko, IETF Chair

A Different Internet

blog23_phone

This week I’m visiting the ICANN meeting in Durban, South Africa. It has been an opportunity to meet many interesting people and get a glimpse of the issues that other important organisations in the Internet ecosystem deal with. And we need to work together on many topics. For instance, the new WHOIS service is worked on both by the ICANN and the IETF. Also, as the Internet has become so important for everyone, even we – the engineers from IETF – are realising that we need to reach out to more people who are impacted by Internet technology. The engineers responsible for different types of networks, domain name policy specialists, regulators, and so on.

But my visit to Africa prompted me to talk about something else as well: the incredible variation in Internet service. During the previous IETF meeting I had the opportunity to talk to a number of Internet policy experts, and I was struck by what they told me about peering. There is a lot of variation in peering practices around the world. In western countries we are used to highly capable Internet exchange points. But this is not the reality in all parts of the world. For instance, some South American countries struggle with limited local peering, forcing much of the traffic to transit elsewhere. This leads to slower Internet service and higher cost. And ultimately makes it more difficult to create local services.

But networking in Africa is even more interesting. In Durban, the network worked better than if I had been at home. But as I moved to the countryside where I am now writing this article, I get a network with a 20% packet loss and RTT that varies between one and six seconds.

At the ICANN meeting I had an opportunity to talk to a person from Chad about their networking situation. The numbers are interesting: Only 0.4% of population are on Facebook and 1.9% are Internet users. Only 2% of homes are connected to the electricity grid. But yet, 31% have a mobile phone. The implications are: first off, the developing world can jump over technology generations, such as moving directly to wireless. Secondly, the power situation creates new markets, people buy small generators, solar cells, and services to charge their phones. Thirdly, it is clear that Africa is the place with a lot of room for growth.

What can we do to support networking in these conditions? How can we create more access infrastructure for the Internet in developing countries? And, perhaps more importantly, how can we ensure that the Internet is open enough for all the local innovation, business, and content that will be created?

Jari Arkko, IETF Chair

The Web of Things

wifiscalenice

The Internet of Things is about embedding communications technology in all objects that can benefit from it, from cars to buildings, everyday objects and even materials. This is an ongoing revolution in the scope and scale of networking.

A couple of days ago the IESG approved Constrained Application Protocol (CoAP) specification, the base specification for a lightweight variant of HTTP, coming from the CORE working group. This seems like a good opportunity to talk about a collection of techniques that I call the Web of Things. The Web of Things is about the use of the web technology for building communication capabilities for smart objects. I believe this is an important, easily available framework for this purpose.

Along with advances in making smaller microelectronics devices and low-power radio communications, the Web of Things is likely to have a big impact in the Internet of Things revolution. Yet, the Web of Things has progressed largely under the radar, because it is largely existing technology that is finding new uses. But I believe it is important we talk about it and realize its full potential. And that potential is big, similar to widely discussed technologies such as Software Defined Networking (SDN).

The core idea in the Web of Things is to represent the real-world objects as resources and interact with them using Representational State Transfer (ReST) style of communications. In other words, using all the normal tools that we already have for building the various web applications. These tools include:

  • IP itself, running on top of any link technology
  • HTTP and TCP, or CoAP and UDP
  • Data formats such as XML and JSON
  • TLS and DTLS for security, along with the necessary data object security mechanisms
  • Directory and discovery mechanisms such as Core Link Format or Resource Directory
  • Application-specific resource definitions, such as the IPSO template or Smart Energy Profile 2.0

Given these tools, smart objects around us can communicate in an easy manner. In particular, there are tools and large number of people with experience on this technology. The communications protocols are known to work well in all networks. For instance, firewalls are likely to pass web traffic through for other reasons. And the web stack is surprisingly well suited for small devices. The picture at the top of this article shows a high-tech weight scale that I bought couple of years ago. This device uses Wireless LANs and the web protocol stack to communicate with the measurements database. With CoAP and perhaps some header compression at the link layer, these communications can be even more optimised.

More generally, when I look at technology deployment I see a pattern. Technologies that are easily available, free, work well in 90% of the cases, and that can be easily extended are usually the ones that end up being deployed quickly. Technologies that require multiple parties to agree or technologies that are highly optimised but targeted for narrow applications tend to lose. In this case the ability to deploy devices in any network, connect them to servers on the other side of the Internet is compelling for many developers.

The ability for everyone to easily package these new services as part of bigger application systems is also compelling. We often focus far too much on the devices and the communication link to them. For most applications this is just one small part of the overall system. There are other important components, such as databases, user interface servers, smartphone applications, and integration to other systems – such as social network applications. Typically, all these other components are based on web services.

As a result, building Internet of Things applications on the web services stack is easy, requires no permission from anyone, and is likely to be the cornerstone of most applications. The devices around you are probably using the Web of Things already, and there will be even more of them in the future. This is also a topic that several standards organisations around the world are looking at. In addition to the IETF, W3C has a group to look at what new is needed to support this, OMA is doing work on lightweight device management, IPSO and ZigBee have worked on profiles, and so on.

What is it then that remains to be done? I think we at the IETF should focus on building the framework and leave the specific applications, resource definitions, and link layers to others who are in a better position to understand their particular requirements. And as noted, much of the framework is already in place. But I believe there are areas where further work is needed. The world has just begun to map out what standards are needed in order for the resources and data formats to be compatible for specific applications. IPSO and ZigBee work on the application templates is a good start, but more is needed. At the IETF, we only recently started the standardisation of discovery and directory services for these kinds of applications. The resource directory work in CORE WG is an important component of this, but there may be other similar components that provide “middleware” services in the form of ReST interfaces. This work needs to continue.

In conclusion, the Web of Things is a very powerful technology that makes it possible for developers to innovate and develop freely, minimizing the need to wait for other new components in networks, install new infrastructure, or redesign the way we build our applications. This technology is worth speaking about and worth putting into your devices.

Jari Arkko, Chair of the IETF and a “things” hobbyist

Acknowledgments: Many people have worked on this topic. Zach Shelby was an early user of the term, and has worked on many of the underlying technologies, such as CoAP. But the underlying ideas date back to at least 2008 and there have been plenty of people who have worked on it. Others that I should mention include Cullen Jennings, Jan Höller, Carsten Bormann, Ari Keränen, Srdjan Krco, Hannes Tschofenig, and various people in the CORE working group, Internet Architecture Board (IAB), and the IPSO Alliance. This article is based on my presentation at the IOT Week in Helsinki in June 2013, and on the IAB draft on smart object architecture.

Welcome to IETF-87!

berlin_001

In two weeks, we will have the IETF-87 meeting in Berlin!  The previous time IETF was in Germany was in August 1997 in Munich – that was too long ago and it is a pleasure to be back! 
 I’m looking forward to collaborating with many talented and enthusiastic people throughout the meeting week.  And I’m very happy that according to registration statistics we will have a large number of first time attendees with us this time – I wish you all warmly welcome to the IETF!

DENIC is the platinum sponsor for IETF 87. Deutsche Telekom, EURidDyn, ECO, and ADVA Optical Networking are also sponsoring IETF 87.   DENIC has also organized a social event at the German Museum of Technology (Deutsches Technikmuseum). I am looking forward to it.  Deutsche Telekom is sponsoring the network connectivity.  Many thanks to our sponsors; we could not have a quality meeting without your strong support.

Our fourth Bits-N-Bites event will take place on Thursday evening.  It includes exhibitor tables, free food, and free drink.  Attendance optional, but our previous visitors seemed to have fun! The Bits-N-Bites sponsors are A10 Networks, Dyn, Comcast, Nominum, IPSO Alliance, HuaweiICANNInternet Society and others are signing up.  Thanks for making this event possible!

The agenda for the meeting can be found from the meeting page. I am particularly excited about the many new work proposals we have this time. The week includes 12 Birds of a Feather (BoF) meetings:

  • STATUS: Using stacked tunnels for source routing. (Monday)
  • NSC: Chaining network services together. (Monday)
  • IPRBIS: IETF IPR rule updates. (Monday)
  • POSH: Running PKIX over Secure HTTP. (Monday)
  • STIR: Revisiting secure telephone identities. (Tuesday)
  • 6TSCH: Defining IPv6 over IEEE802.15.4e Timeslotted Channel Hopping media. (Tuesday)
  • DMARC: Trust-oriented layer for domain-based message authentication, reporting & conformance. (Tuesday)
  • AQM: Algorithms for active queue management and packet scheduling. (Tuesday)
  • DNSSDEXT: Extensions for DNS Serivice Discovery (DNS-SD). (Wednesday)
  • DICE: DTLS for constrained nodes. (Wednesday)
  • TCMTF: Tunneling compressed, multiplexed traffic flows. (Thursday)
  • 6LO: Extensions for running IPv6 over constrained links. (Thursday)

Be sure to follow the ones that might interest you! Also, on Monday evening in the technical plenary we will hear some experiences from defining the OPUS codec (RFC 6716).

I look forward to your participation this week, and seeing you also at IETF 88 in Vancouver, BC, Canada on November 3rd to 8th, 2013.

Jari Arkko, IETF Chair