Skip to main content
  • New Internet Architecture Board, IETF Trust, IETF LLC and Internet Engineering Task Force Leadership Announced

    Members of the incoming Internet Architecture Board (IAB), the IETF Trust, the IETF Administration LLC (IETF LLC) Board of Directors, and the Internet Engineering Steering Group (IESG)—which provides leadership for the Internet Engineering Task Force (IETF)—have been officially announced, with new members selected by the 2021-2023 IETF Nominating Committee.

      13 Feb 2023
    • Informing the community on third-party correspondence regarding the W3C

      In accordance with our policy of transparency, this blog post is being published in order to keep the community informed about recent correspondence with lawyers acting on behalf of the Movement for an Open Web.

      • Lars EggertIETF Chair
      8 Feb 2023
    • Six Applied Networking Research Prizes Awarded for 2023

      Six network researchers have received Internet Research Task Force Applied Networking Research Prize (ANRP), an award focused on recent results in applied networking research and on interesting new research of potential relevance to the Internet standards community.

      • Grant GrossIETF Blog Reporter
      9 Jan 2023
    • Travel grants allow Ph.D. students to participate at IETF meeting in-person

      Sergio Aguilar Romero and Martine Sophie Lenders, both Ph.D. students in technology fields, attended and participated in the IETF 115 meeting in London with assistance through travel grants from the Internet Research Task Force.

      • Grant GrossIETF Blog Reporter
      7 Jan 2023
    • Impressions from the Internet Architecture Board E-Impact Workshop

      The IAB ran an online workshop in December 2022 to begin to explore and understand the environmental impacts of the Internet. The discussion was active, and it will take time to summarise and produce the workshop report – but the topic is important, so we wanted to share some early impressions of the outcomes.

      • Colin PerkinsIAB Member
      • Jari ArkkoIAB Member
      6 Jan 2023

    Filter by topic and date

    Filter by topic and date

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

    • Ben Campbell
    • David L. Black

    26 Jan 2015

    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.

    Share this page