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

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.