Skip to main content
  • Time to update the Network Time Protocol

    The Network Time Protocol (NTP) is a foundational Internet standard that has provided clock synchronization between computer systems since the early 1980s. It was first standardized as RFC 958 in Sept 1984 with several revisions in the following years. Discussions have been ongoing in the NTP working group for a few years now about updating NTPv4 to NTPv5. This update is motivated by lessons learned, ongoing vulnerabilities, and emerging use cases.

    • Karen O'DonoghueNTP Working Group Chair
    • Dieter SieboldNTP Working Group Chair
    30 Sep 2022
  • Report from IAB workshop on Analyzing IETF Data (AID) 2021 published

    The Internet Architecture Board (IAB) has published the official report from the workshop on Analyzing IETF Data (AID) 2021.

      28 Sep 2022
    • Applied Networking Research Prize presentations at IETF 115

      The Internet Research Task Force (IRTF) open session at the IETF 115 meeting will feature presentations on research into domain hijacking, the IETF's organizational culture, and DDoS attack detection and mitigation.

        27 Sep 2022
      • Supporting diversity and inclusion at IETF meetings by providing childcare

        Thanks to the generous support of IETF Diversity & Inclusion sponsors, onsite childcare at an IETF meeting was provided for the first time ever during IETF 114. The successful experience and continued support of sponsors means it will again be offered at the IETF 115 meeting on 5-11 November 2022.

          14 Sep 2022
        • IETF Annual Report 2021

          The IETF Annual Report 2021 provides a summary of Internet Engineering Task Force (IETF), Internet Architecture Board (IAB), Internet Research Task Force (IRTF), and RFC Editor community activities from last year.

            9 Sep 2022

          Filter by topic and date

          Filter by topic and date

          Presenting at my first IETF meeting

          • Lauren Delwiche

          15 Aug 2022

          Walking up to the check-in desk at IETF 114 was a very strange experience for me. You see, only about a month prior, I had walked across the stage to graduate from Thomas Jefferson High School for Science and Technology and I was concerned that I didn’t fit the profile of a standard IETF attendee. However, over the course of the three days that I was there, I came to learn that there is no such thing as a “typical” IETF contributor and ended up having a great newcomers experience.

          Screen Shot 2022-08-10 at 12.26.33

          The lead up

          I first started working with networks when I became a student systems administrator at my school towards the end of my freshman year. I entered an incredible program in which the design, maintenance, and operation of our school’s domain is entrusted to a small group of students with guidance from experienced professionals. In most situations, if a student has the opportunity to work with computers at the high school level, it is only in a very theoretical capacity—search algorithms, object oriented programming and the like. The sysadmins program is unique in that it offers real experience in the day-to-day operation of a domain. In four years, I went from building simple HTML-only websites to setting up a new core router, configuring mail servers and confidently messing with high voltage electrical systems like our UPSs.

          A previous sysadmin, William Zhang, had already partnered with IETF’s MBONED working group and chair Lenny Guiliano to deploy the first Automatic Multicast Tunneling (AMT) relay in our lab and I inherited that setup. I was tasked with maintaining it, but I’ll admit that I had very little idea what that entailed. Lenny came to the lab to help and introduced me to the rest of the MBONED’s work—with a deck of slides that very memorably ended with a plan for world domination.

          However, my contributions to MBONED projects didn’t really start until COVID-19 shut down Virginia public schools in March of my sophomore year. Very suddenly, I went from 7 classes a day, hours of homework and athletic commitments to absolutely nothing. Luckily, Lenny had a solution to my boredom and offered me the chance to build an application that would come to be known as the Multicast Menu.

          The project

          The goal of the project is simple: incentivise the deployment of multicast across the entire Internet by creating technologies that (1) make multicast easy to use and (2) enable devices on unicast-only networks to send and receive multicast content using translators and AMT respectively. Multicasting—especially in our world of live streams and Zoom meetings—offers a unique benefit in that it uses significantly less bandwidth to deliver content to large groups of users. However, multicast delivery isn’t widely used across the Internet yet because multicasting protocols must be enabled on every hop along a packet’s path and in today’s Internet, they just aren’t. By making it easier for users on unicast-only networks to discover and create multicast streams, the hope is to motivate ISPs to enable multicast on their networks.

          During that first COVID spring, I attempted to tackle the ease of use issue and came out with a web application that built on previous work by discovering multicast sources, publishing them and providing a simple way to open them in VLC 4.0. The discovery is done by querying the looking glasses for Internet2 and GÉANT routers and parsing the output into a database. This enables Multicast Menu to keep a relatively fresh list of both the sources and groups that are distributing multicast content. Users are able to quickly connect to these sources using the AMT relay at my high school’s lab and the AMT gateway implementation that is built into VLC 4.0.

          I had to put it aside for a while, but when my senior year started, I returned to this project as a part of my capstone senior research project. This time, the focus was on enabling users to source content from unicast-only networks. A unicast to multicast translator had been set up and the plan was to create mobile apps capable of sending UDP packets into the translator, which would assign them to a group address and stream them onto Internet 2. In the end, I came out with a couple of other solutions that accomplished the same thing. First, I added to the Multicast Menu an option to upload a prerecorded video to be sent to the unicast to multicast translator. Then, I set up a structure that allows for live streaming from mobile phones using the Haivision Play app.

          I learned a lot from implementing these applications and I’m continuing to work with the other members of MBONED to improve what we already have. I’d like to get to a place where devices on unicast-only networks can both send and receive content from mobile phones and the browser.

          ietf-3

          Presenting

          Towards the end of my senior year, Lenny asked if I would be interested in presenting the work that I had done at IETF 114. Since it was in Philadelphia, I could even attend in person. I agreed and started making plans to attend. At some point, those plans shifted from only showing up on the day of my presentation to coming for a few days prior. So, with my hotel booked and a fair bit of anxiety, I drove to Philadelphia and showed up on Tuesday for my Thursday presentation.

          Before I showed up, I was nervous to not only present in front of networking professionals, but to attend working group meetings for three days and try to fit in. All of my work essentially involves the application layer, and - while I have a decent operational grasp of networking from the sysadmins program—my level of understanding was nowhere near that of the professionals around me who were drafting RFCs and debating their merits. However, those around me went out of their way to make me feel welcome. I was included in hallway chats and meals, got to draw out diagrams on bar napkins and people stopped to explain concepts that I wasn’t familiar with. I met people from the systers group and had some great conversations. The atmosphere was incredible.

          When it came time for my presentation, I stood at the front of the room and clicked through my slides before attempting some live demos that, thank goodness, worked the first time. I got some questions about the current capabilities of my applications and some great suggestions on how to improve and what direction to go in next. Dino Farinacci suggested using a LISP overlay to deliver to mobile devices and Erik Herz suggested WebRTC as the basis for browser-based sourcing from unicast-only networks. I also got to hear about the other work happening in MBONED, like Jake Holland and Max Franke’s QUIC for multicast in the browser.

          Wrapping up

          In all, working on this project has been an incredible opportunity and I’m very grateful to those who helped me along the way—especially Lenny and the members of MBONED whose work I’ve gotten to build on. There’s still a lot left to do in this area and I plan to continue where my presentation left off, but the opportunity to start my involvement in the IETF as a high schooler was really quite special.

          Presenting at IETF 114 introduced me to an incredible community of people and again, I’m very grateful to the many people who helped me navigate my first foray into this world. As I go off to the electrical engineering program at Yale University in September, I do so with an increased interest and appreciation for the work that goes into computer networking and a desire to continue to be involved with the exciting work that the IETF does.


          Share this page