IETF Meeting Network Recommendations

IETF participants need a highly reliable and responsive network, with sufficient bandwidth to avoid congestion, that enables work to be conducted without interruption or network limitation during an IETF meeting. Such a network enables in-person network attendees to get their work done. It also enables remote participants to have a good experience as well, via remote participation in working group meetings. This document makes suggestions about how to reduce complexity, reduce cost, and increase reliability of the IETF meeting network, which may be helpful in community discussion In the past, approaches to revise network requirements started from the point at which the IETF currently operates. This risks burdening such an exercise with old assumptions and requirements. This analysis, in contrast, is an idealized redesign that asks "if we were building the IETF network from scratch today, what should it look like?".

Highly reliable and performant network with no experiments that may potentially cause disruptions to mission-critical standards development work (e.g., working group sessions).
Support for network experiments shall be supported via a functionally separate Hackathon network.
Redundant upstream connectivity to the internet shall be maintained, to hedge the risk of outage in case of path failure.
Native dual stack shall be supported for all devices on the network - IPv4 and IPv6.
The most-recent IEEE Wi-Fi standard shall be supported, delivering ubiquitous Wi-Fi available in the entire meeting venue.
A public ticketing system shall be used to report issues, as well as track/report status or closure to all network users.
A public network performance dashboard and associated real-time and post-meeting reports shall be maintained, available to all network users.

Network experiments MUST only occur on the Hackathon Network, which is a separate network form the Meeting Network.
The Hackathon Network will run for the entirety of the IETF meeting, not just during the Hackathon.
Participants shall use the public ticketing system (with support for up-voting to support prioritization) to request support for experimental new protocols or other experiments. These requests will thus be decided based on community feedback.

Hotel networks are now sufficiently performant that this is no longer the technical limitation that it was 10 or 20 years ago; it is time to move on.
If there are potential issues with filtering, participants can use a VPN (as most do anyway).
Thus, the IETF meeting network MUST NOT be extended to hotel rooms any longer.
As an alternative, the IETF should contract with the primary hotel to include free Wifi in the room rate and include network performance requirements, such as minimum downstream and upstream bandwidth and maximum latency.
In rare cases of a country-wide firewall issue, where open internet access is not possible from the primary IETF hotel, an alternative may be to have IETF set up an appropriate VPN headend, privacy proxy, or other technical solution in the hotel's network or in the IETF meeting network. Setting up such a VPN or similar service may also save meeting attendees incremental cost or work.

There shall be only one wireless network (Service Set Identifier, SSID) for the Meeting Network: IETF
There shall be only one wireless network (SSID) for Network Experiments (unless a special SSID is required as part of an experiment): IETF-Hackathon
The wireless network shall require authentication, using the most recent widely supported standard (e.g., WPA3 PSK with a fallback to WPA2. This is not intended to be individually-identifying authentication.
If participants wish to experiment, such as doing IPv6-only connectivity, they may be able to do so on their local host (i.e., to achiev IPv6-only, disable IPv4 addressing on the host) or set something up on the hackathon network.

All data concerning the performance of the network should be made available transparently for all participants to see, both during and after the meeting.
The Network Operations Center (NOC) shall provide a real-time or near-real-time dashboard of all key network statistics.
Reporting using IPFIX (NetFlow) that shows the source/destination of network flows.
Bandwidth tracking of peak usage.
Transport protocol tracking (e.g., volume of TCP, UDP, QUIC).
Application protocol tracking (e.g., volume of SMTP, HTTP, etc.).
DSCP mark tracking (e.g., volume by DSCP code point).
ECN tracking (e.g., volume with no ECN, ECT(1), CE).
All aspects of Wi-Fi performance (e.g., by room, specific AP, etc.).

Within 1 week of the shut down of the network a final network performance and incident(s) report shall be sent to the community and posted on the IETF website.

Geo-IP data shall be updated to the next IETF meeting's location within 1 week of the end of the prior IETF meeting, so that Geo-IP databases pick up the change of geography well before the next IETF meeting.

Total meeting network cost in 2024 was roughly $850,000. At 1,000 attendees per meeting and 3 meetings per year, 851,000/3,000 = $283 per participant for each meeting. If this cost was reduced, it could enable a material reduction in meeting registration fees.
Cost can be reduced by reducing complexity (see prior sections).
One potential parallel activity could be to have an *independent* team study these costs and make recommendations on how to reduce them.

Lines of reporting may benefit from greater clarification.
The community may want to consider asking the NOC Lead contractor to regularly report to the IESG and IETF LLC concerning meeting network operations.
Should the IESG establish an community oversight mechanism for the meeting network operations function (e.g., via GEN Area)?

Thank you to the following people for their feedback: Andrew Malis, Toerles Eckert, Eric Rescorla.

This memo includes no requests to or actions for IANA.

N/A

v00: First draft v01: Changes suggested on the admin-discuss mailing list

See list (if applicable) at https://github.com/jlivingood/IETF-Mtg-Network/issues