Minutes IETF105: netrqmts
minutes-105-netrqmts-00

Meeting Minutes IETF Meeting Network Requirements (netrqmts) WG
Title Minutes IETF105: netrqmts
State Active
Other versions plain text
Last updated 2019-07-30

Meeting Minutes
minutes-105-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


*** 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.