Monthly Archives: January 2015

Like a DART: Moving rapidly from a need to a solution for WebRTC

In less than 9 months–representing just two IETF meeting cycles–the DiffServ Applied to Real-time Transports (DART) working group (WG) moved from a concept to Internet Engineering Steering Group (IESG) approval of the Internet Draft it was chartered to produce.

The DART WG addressed a problem faced by multiple Real-time Applications and Infrastructure (RAI) area working groups, notably RTCWEB and CLUE: What if multiple Real Time Protocol (RTP) streams and related traffic needed to be sent over the same transport protocol flow (e.g., TCP or UDP 5-tuple), but also needed different Quality-of-Service (QoS) treatment based on Differentiated Services (DiffServ)?

This problem spans IETF areas. While DART was chartered in RAI, transport protocol and DiffServ activities are in the Transport (TSV) area. At an informal IETF 89 (London) Sunday afternoon meeting among the Area Directors (ADs) and a number of WG chairs from both areas, it became clear that this problem needed to be solved, and quickly, as WebRTC (RTCWEB WG) intended to use this functionality.

Thus, the arc of the DART WG began in March 2014 as the working group was organized to deal with that problem. After just over 8 months of diligent work, the WG concluded in November 2014 with IESG approval of draft-ietf-dart-dscp-rtp-10 during the IETF 91 meeting in Honolulu. The draft garnered both praise for clarity and “Yes” votes from all four Area Directors across both areas.

Given recent discussions about IETF processes needing to be agile, we–Ben Campbell (DART WG chair) and David Black (draft editor)–thought it would be worth taking a look at what enabled the DART WG to complete its work quickly and successfully.

+ A simple short problem statement

The organizers stated the problem and described the draft to be written in two short paragraphs, which became the WG’s charter. The RAI DISPATCH WG gave the proposed work a prompt community airing before the charter went to the IESG, cementing the understanding that the WG’s primary mission was to document what exists and is known to work, and more importantly, what is known not to work.

+ Gathering experienced personnel

Each of us (the WG’s key leaders), came from one of the two IETF areas involved, RAI (Ben) and TSV (David), with strong cross-area experience (e.g., we’re both General Area Review Team [Gen-ART] reviewers). Separation of roles worked well; Ben didn’t try to write the draft and David didn’t try to run the WG ;-). Both of us were willing to listen to and learn from other participants, plus work hard. And, we learned a lot!

+ Carefully managing (and resisting!) scope creep

When experts find areas of technical friction, their instincts are to fix things. But the DART WG wasn’t chartered to fix anything, so we stuck closely to the task that we *were* chartered to undertake. We met this challenge successfully, but had to manage it carefully at every turn.

+ Changing plans as things change

Even the best-laid plans must change sometimes. For example, the final pair of draft authors was not the original plan–or even the second plan! While in theory having more authors allows more parallel work, in practice it created additional coordination overhead. Also, the draft underwent serious restructuring when it became clear that the initially envisioned draft structure was wrong for the purpose. So, rather than resisting, we took a positive attitude and did what was necessary. We see this as the standards version of “no battle plan survives initial contact with the enemy.”

+ Effective use of face-to-face meetings

Our one-and-only dart WG meeting in Toronto (IETF 90) was devoted to resolution of issues–the audience was expected to have read the draft, and it was not “presented” at that meeting. We prepared for that meeting by assembling a cross-area community and dealing with as many issues as we could on the WG’s mailing list. The result was that the meeting participants–with expertise from at least 6 technical communities (e.g., DiffServ, SCTP, congestion control, NAT traversal, RTP, SDP, and WebRTC)–engaged in a valuable, high-bandwidth discussion of the important issues that could not have happened via email.

While the initial aspiration was to conclude the work before the Toronto meeting (see above point about being willing to change plans!), we believe the result was considerably better than it might have been without such a meeting.

+ Familiarity with IETF processes

We worked to expedite the process throughout the cycle. Sometimes this meant walking the draft through the process, and gently “bothering” people rather than letting things move at the usual speed. The RAI “dispatch” process enabled this focused WG to be formed quickly without the Birds-of-a-Feather (BoF) sessions that often precede WG formation.

In closing, we’d like thank our ADs, especially Martin Stiemerling (TSV) and Richard Barnes (RAI), who were very supportive, Paul Jones (the other draft author), all the participants in the IETF 90 meeting in Toronto and everyone who came to the informal Sunday meeting at IETF 89 in London that started this adventure.

Ben Campbell and David Black

IETF turns 29

ietf1proceedings

The IETF traces its start back to a meeting that took place 29 years ago today, January 16th. Happy birthday, IETF!

Here are the proceedings from that 1st IETF meeting: ietf-1.

Jari Arkko, IETF Chair

Taking a Step towards IANA Transition

Protocol parameters such as port numbers are an integral part of technical specifications that the IETF produces and developers implement. Along with naming and numbering functions, protocol parameters are maintained through IANA. As many of you are aware, in March of 2014, the US government announced their intent to move their role in overseeing the IANA system to the Internet community. For the IETF, this change is largely a recognition of the evolution that has already happened, and our community believes the processes we have built are strong enough to work with or without USG oversight. Over the years, the IANA system has evolved, as we have worked together with IANA and ICANN to specify agreements, processes, tools, and oversight mechanisms.

Last month the IESG approved the IETF response, and after small editorial changes, draft-ietf-ianaplan-icg-response-09.txt was formally approved on January 6. The IAB has signified their support of this document as well. This represents a major milestone, the results are due to hard work of many people, as evidenced by the lengthy Acknowledgments section of that document.

We used our normal processes to develop our response, by having a Birds of a Feather session, forming a working group, adopting a draft, discussing, debating, forming rough consensus within the working group, holding a last call, and then seeing that all issues raised were addressed. All of this was done over a period of nine months, with a total of ten drafts having been produced, a fast pace by any standard; owing to the the widely held community opinion that the existing arrangements between IETF and ICANN have served us well, and should be continued. It also helps that from the IETF perspective, long ago we took full responsibility for our part of IANA, including the oversight. We have evolved solid principles over time. This made preparing a transition document much easier than it perhaps otherwise would have been.

Our work is not yet complete. There are a number of steps still in front of us. They include the following:

  • Both the numbers and names communities need to complete their proposals. We at the IETF will continue engage with them with their work, just as they assisted us with ours.
  • Later, the IANA Transition Coordination Group (ICG) will assemble a complete proposal and gather community feedback on the result. When ready, they will submit the final proposal to the NTIA.
  • The NTIA must then consider and approve the proposal.
  • Finally it must be implemented.

While there will assuredly be some bumps along the road to success, the IETF leadership are committed to ensuring a good outcome for the Internet.

Jari Arkko, IETF Chair and Eliot Lear, IAB