Minutes IETF105: netrqmts
IETF Meeting Network Requirements
||Minutes IETF105: netrqmts
NetRqmts BoF at IETF 105 in Montreal, QC, CA
WEDNESDAY, 24 July 2019 at 13:30
BoF Chairs: Karen O'Donoghue, Russ Housley
Note Taker: Martin Thomson
0) Minute Taker, Jabber Scribe, Bluesheets
1) Agenda Bash
2) Objectives of the BoF (Karen)
-- how we got here
3) The network for IETF 105 (Warren)
-- sometimes there location related challenges
-- sometimes there are community-driven experiments
5) Wrap Up
BoF objective: gather community input on the IETF network
History lesson about the meeting network and its evolution
*** The Network:
overview of the network at this meeting
Discussion on purchase vs. donation of circuits - mostly these are
donated, including bandwidth
Do you exchange note with other orgs? Somewhat with ICANN
Question regarding SSIDs: We could probably dramatically simplify
Suggestion regarding the hotel network: Maybe this desire to replace
the hotel network is grounded in archaic assumptions: There are a
number of issues with the architecture of hotel networks that would
affect use cases or cause configuration issues, such as, limits on
the number of broadcast packets in a given period cause things like
ARP to disappear.
The venue-provided networks are getting better, but they might not be
up to the expectations of IETF participants and the needs of the
Question on how we understand bandwidth requirements, what is causing
1Mbps up for every person? Would we use less if we had a lower cap?
Are our requests for bandwidth constraining where we can hold
What about offsite people? We typically have around 600 people in the
meeting hotel. We use that to calibrate expectations.
IPv6 on the guest room network can be one reason to take over; that
might suggest a need to examine how these protocols that were
designed for wired networks alter for a wireless network.
Bandwidth is very cheap, in the order of $1 per megabit.
Getting bandwidth at all can be a problem (though generally not); once
the bits are there, we generally have far more than we need.
What are you seeing in terms of lag in deployments of hotel networks?
Hotels are upgrading infrastructure. This hotel has better
infrastructure than the last time we wer in this same hotel.
NOC volunteers and contractors got applause for their excellent work!
Terms of engagement:
User requirements only, not network architecture or network design.
Do you need a network? The hum confirmed the need for a meeting network.
Do you believe that venue network (without enhancement) is sufficient?
Jared: Most networks upgrade bandwidth for big meetings; don't take
over the hotel network
Leif: Attendees at conferences can be dissatisfied with networks
that don't take over. Conferences have been doing more, not less,
over time. This might be suboptimizing.
Tim: I often stay beyond the meeting time or arrive before. About
half the time, this is not a good experience. Blame the captive
portal capacity, or maybe a lack of addresses. Attempt to debug,
but it varies.
Cullen: I have limited requirements (web, email). 98% of the time
this is OK. We should ask what specific things would be
problematic for us. I think WebRTC, for instance, works fine with
Alissa: Cullen said it. Need to know what people need to do to get
their work done. Of course the captive portal makes people sad,
but we can deal with that. I want to hear what would be prevented.
Ted: The requirements for the rest of the world have progressed,
where our needs are relatively static. When we went to Stockholm,
they doubled the capacity into the *country* as a result.
Effective remote participation is going to be more important.
We should not focus on global participation, but to consider
whether we can double the remote participation numbers from
where we are now.
Russ: In my WGs remote presenters pre-testing with Meetecho, and
it works great, but it can still fail during sessions. When
debugging, the problem is often not in the hotel.
Ted: Yes. The constraint is often at the participant's end. But we
need to make sure that the meeting network is not the constraint.
Alessandro: The Meetecho team deploys RTC servers.
Glenn: We are conflating meeting room and guest room requirements.
Netflix in the meeting room is probably not a requirement. Web
access is critical.
Russ: Indeed, ADs need to be able to clear DISCUSSes.
Adam: We should go to the hotels and vet ahead of time, and maybe
ask to bypass captive portals during the meeting.
Bob: I don't think that venue networks are sufficient. IPv6 is
something we won't see if we use venue networks. If we don't use
it, we might as well roll this up and stop. I'd be okay with
turning off IPv4, but it's a bit early for other people.
Jen: Bob stole my comment. I use v6-only. Venues don't provide v6.
Jim: This isn't just the bandwidth. The network captive portals and
NATs don't scale to our usage models. So while bandwidth is
available, we can't use all of it because there are boxes
interfering with our ability to do so. We use carrier-grade gear,
not enterprise gear.
Charles: The hackathon benefits from being able to make special
requests. Including wired access, prefix delegation. We need to
accommodate those requests.
David: the network might be for getting work done, but it has other
impacts, like causing networks to change their networks. We should
think about other objectives, like encouraging the use of IPv6.
Jason: This is about the meeting rooms... Maybe we're past the
simplistic question of whether we need a network, but into what to
prioritize in the remaining questions. We know about some of these
things, but not all.
Lars: I'm willing to believe that we have requirements beyond what
venues provide, but I believe that the effort we put in far exceeds
our needs. The fact that we aren't NATted blew some people's
minds. This is a network that doesn't exist anywhere else on the
planet. Does anyone know what ZTP is?
???: To get my job done without a real network, I'd be three levels
deep in SSH tunnels. The question is how much this gets in the way.
Russ: I heard we need IPv6. NATs aren't the worst thing if there is
enough addresses to go around. Captive portals is a real pain.
Do you believe that your needs are representative of a typical attendee?
Martin: I'm here under duress. Self-selection bias might be a
problem with this question.
David: There is no such thing as an average IETF attendee. There are
different categories with different requirements. For example,
IPv6 folks have unique requirements compared to others.
Jared: That we don't have a lot of attendance here we can interpret
as an indication that the network is working well. Maybe this
suggest that improvements are not necessary. Consider whether we
use attendees as a captive audience for experiments. That we had
few hums for special needs, even in this set, is a good sign.
Glenn: The main complaint the IAOC got about meetings was regarding
the quality of the network.
Jim: My recollection is different than this. Usually we had a
correlation between the infrastructure being bad generally and the
network being bad. There are few cases where the network quality
ruled out a venue. Most can be fixed. For example, Prague had
insufficient fiber, we added that to the contract and it worked out
Glenn: I didn't say that it was the primary reason, but it was a
contributing reason in rejecting venues.
Lars: We can overengineer the network. We could provide less and we
would still have less. The network is awesome. We could scale
back a little. Our bar is so high we exclude venues that might be
cheaper. I can run certbot on a laptop and renew a cert. Do I
need that? Not really.
Bob: The venues that were rejected because of existing network
infrastructure, because nothing we would do could fix those places.
Hans: We should scale back, but we could reach a critical threshold
where we don't have a team of volunteers and contractors. Some of
what we see is because we have the spare capacity in the network
Warren: We need to understand what we are overbuilding. Often, once
we have infrastructure in place, the additional services aren't
hard to add.
Lucy: The idea of experiements and interesting problems are
important. I would hate to have to lose that. We can run an
experiment in Singapore. We could try running with the venue
Ted: A more interesting test: You could run an A/B test across the
Cullen: We need to have people bid on which hotel they would choose.
Tim: Maastrict was a problem, but that was 9 years ago. Maybe
things have gotten better in that time. Can we tell if the
network is good before we get there?
Warren: I don't think that it is possible to know. We once told an
overflow hotel that we were coming. That network didn't work well.
The hotel thought that we were attacking their network, but that
is just what IETF network usage looks like. Normally, this is down
to weird network configuration and things like middleboxes.
David: The network here costs $20/day. A sim card costs a lot too.
Karen: There is a difference between us replacing a network and us
negotiating zero-cost access to the network.
Alissa: Question about Warren's story. Did we contract for an
upgrade? (Yes, but they didn't meet expectations). We have
negotiated a contract with the hotel in Singapore, so we should
fulfill that contract. We should not back out of contracts for
Adam: Last week at another hotel I got 3Mbps. My tunnels were going
down every 30 minutes, which is state of the art in my experience.
This is not OK for me.
Jared: Fleabag hotels generally have better Internet access.
Rob: Thought experiment: Could we conduct a meeting with people
tethered to phones?
Clemence: Some times we can tell straight away that a network can't
handle the IETF participants. Here, the radio coverage is good,
but there was a problem in the network that we only found after the
first day. We can't find that from a site visit.
Rich: What does it cost to replace the hotel network vs. using the
Karen: We have started to look, but we wanted to ask what people
wanted before going into details. There are multiple costs
(money, people, in-kind). Maybe this is a matter for the LLC.
Cullen: Can I see the rest of the questions on the slides?
(Then, people responded to whatever question was of most interest.)
Jared: As guest room access improves, my need for the terminal room
with 24 hour access has changed. There might be room for a slider,
where we balance private space and public space network services.
I have seen people making calls in public spaces here, which is
usually better in private rooms.
Karen: We used to provide terminal room for 24 hour access, now it is
only provided in a pinch.
Glenn: Some people find the terminal room useful.
Martin: No security for the terminal room please, but consider it
on a per-venue basis.
Jason: We might need to measure terminal room usage to know.
Russ: This meeting, people are no longer using the terminal room for
printing boarding passes; the printer is now by the registration
Sean: I don't even have a wired ethernet adapter on my laptop any
more. Guest room network access for me doesn't need to be special.
I can cope if it is not 100% reliable. The meeting is about
talking to people. We should definitely look at the guest network;
I do not need privacy/security either.
Glenn: I like Jason's measurement suggestion. This venue is awesome
with plenty of seating availability. In other venues, I have used
the terminal room as a place to sit between meetings, especially if
I am not staying at the event hotel.
Bill: As things have gotten better, I see chairs download materials
in real time. That doesn't work in a network with high outage
Russ: Agree. Imagine a failure in the middle of a remote plenary
Cullen: I rely on that because I often write slides 5 minutes before
a session. We need to separate the hackathon out. Outside of that,
this is more a marketing opportunity than contributing to our main
goal: doing standards. Only the hackathon is special.
Jonathan: I really value having the printers, no matter where they
Nils: I need to use the network for calls in between meeting sessions.
I rely on a good network for that, and I usually go to my room for
Matt: Agree with Nils.
Rob: We had a team of RPKI developers hacking on code at the meeting,
from the terminal room. They did not need the wires, but they
needed a place for that work, which was valuable. Regarding the
privacy protection question: most people don't live on the public
Internet, are we doing a disservice by exposing people to a
deployment environment that is abnormally open?
Bob: It's good to be exposed. Terminal room is not a network
question, but a question of how we provide space for attendees:
quiet spaces, seating, nooks, etc... We should eat our own dog
food. That is part of our culture. We have learned a lot from our
experiments. This is an opportunity to make the IETF even more
Mike: How much does having a good network here enable attendance for
people who are important at their companies.
Warren: Also important to call family. Asks Sean about that with the
cell network? (Sean says the cell is fine video call to home.)
Jason: This is not the dog food that all the other dogs get. This
might be more premium than what all the other dogs get. The
security expectations are changing very quickly. It would be
good to know more about how things are changing.
Jared: I take advantage of having an open network while being here.
Maybe we can put that on a separate SSID. We often connect to
unknown wireless networks all the time anyway. My corporate
network has a bunch of defenses in place. The network here is
excellent and I have had no issues.
Warren: While our devices might be well-managed, there are also
non-IETF people on the guest network.
Karen: We don't have enough input for the NOC or the administration
out of this discussion. Can we use the mailing list in any way?
To develop a survey?
Jared: Should we merge with mtgvenue? (no)
Lucy: I heard that people get a lot of value from the network. Lots
of questions about ietf-hotel. I heard answers to privacy and
security protection questions, that might need staging. When we
make the network, we make rules; when we buy the network, we buy
Clemence: Is v4-only still heresy?
Karen: Let's not use this discussion to settle a NOC-internal debate.
Continure discussion on the mail list and get more clarity on these
topics and collect data.