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 *** Agenda: 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Objectives of the BoF (Karen) -- how we got here -- draft-odonoghue-netrqmts 3) The network for IETF 105 (Warren) -- sometimes there location related challenges -- sometimes there are community-driven experiments 4) Discussion 5) Wrap Up *** Objectives: Karen: BoF objective: gather community input on the IETF network History lesson about the meeting network and its evolution draft-odonoghue-netrqmts overview *** The Network: Warren: 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 meeting. 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 meetings? 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! *** Discussion: 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 v4/v6/NAT. 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. Alissa: Agree 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 well. 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 ops team. 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 network there. Ted: A more interesting test: You could run an A/B test across the two hotels. 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 experiments. 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 existing one? 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 desk. 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 tolerance. Russ: Agree. Imagine a failure in the middle of a remote plenary presentation. 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 are located. 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 the calls. 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 relevant. 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. What Next? 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 rules. 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.