Skip to main content
  • IETF 117 Highlights

    IETF 117 is a few weeks behind us and Dhruv Dhody, IAB Member and liaison to the IESG, took the opportunity to report on a few highlights and some impressions.

    • Dhruv DhodyIAB Member and liaison to the IESG
    21 Aug 2023
  • Proposed response to meeting venue consultations and the complex issues raised

    The IETF Administration LLC recently sought feedback from the community on the possibility of holding an IETF Meeting in the cities of Beijing, Istanbul, Kuala Lumpur and Shenzhen, with received feedback including views that were well expressed and well argued but strongly conflicting. The IETF LLC has considered this feedback in-depth and now seeks community feedback on its proposed response.

    • Jay DaleyIETF Executive Director
    21 Aug 2023
  • Submit Birds of a Feather session proposals for IETF 118

    Now's the time to submit Birds of a Feather session (BOFs) ideas for the IETF 118 meeting 4-10 November 2023, with proposals due by 8 September.

      16 Aug 2023
    • Applied Networking Research Workshop 2023 Review

      More than 250 participants gathered online and in person for ANRW 2023, the academic workshop that provides a forum for researchers, vendors, network operators, and the Internet standards community to present and discuss emerging results in applied networking research.

      • Maria ApostolakiANRW Program co-chair
      • Francis YanANRW Program co-chair
      16 Aug 2023
    • IETF 117 post-meeting survey

      IETF 117 San Francisco was held 22-28 July 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

      • Jay DaleyIETF Executive Director
      11 Aug 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