Re: [Netrqmts] IETF 105 Minutes

[Alessandro Amirante <[e-mail]>]

Il 31/07/19 00:08, Michael Richardson ha scritto:
> 
> Toerless Eckert <[e-mail]> wrote:
>      > On Tue, Jul 30, 2019 at 03:20:03PM -0400, Michael Richardson wrote:
>      >> +5.  I find that the most important thing that the IETF meeting
>      >> (network) does for people, is that it gives them an idea what a real
>      >> end-to-end transparent network *can* be like.  Suddenly things that
>      >> never worked for them work.
> 
>      > As i said in my prior mail to this list (which went without any reply),
>      > most people nowadays wouldn't even know what it means to be directly on
>      > the internet without any firewall, and i really question whether it is
>      > prudent to ONLY have this option and NOT document it very clearly to
> 
> We used to see those people, they were in the terminal room re-installing
> windows 98.   Those days are over.  Firewalls have not prevents 14B a year of
> damage from trojans, and they never will as long as the MIME Security
> Considerations continues to be ignored.
> 
>      > all those users not working at the network level. I also think that
>      > folks who want to test if their applications work well and invested
>      > into ICE/STUN and other firewall traversal mechanisms (like RTCweb and
>      > other app groups), would maybe like to have something more reflective
>      > of relevant end-user access (with firewall).
> 
> A $22 home router fixes that problem.
> 
>      >> If we are going to continue to make such investments, can we somehow
>      >> do so in a useful way?  Can we collaborate with the hotel to make
>      >> changes that persist?  This goes into returning to the same hotels
>      >> regularly, and *is* a mtgvenue discussion, not a netrqmts discussion.
> 
>      > I am already surprised how much the IETF noc team has been able to work
>      > with hotels existing AP and access-LAN infrastructure and make it work
>      > as good as possible. I do not always like the results (like in
>      > montreal), but lets not underestimate the complexity of the job of the
>      > noc doing this.
> 
> I have been a NOC volunteer in decades past, and I've been involved in
> pulling "Long Range Ethernet" into places... at 4m vertical/floor, and 100m
> total for GbE over copper,  the 30th floor of some hotels was a problem.
> (Atlanta...)
> We aren't having to do this anymore.
> 
>      >> I think that we should split up the discussion into perhaps four
>      >> areas.
>      >>
>      >> 1) the L2/WiFi coverage of the meeting rooms for IETF participants
>      >>
>      >> 2) the availability of IPv6 in the guest rooms [I don't mind captive
>      >> portals, *if* they follow our WG's specification...]
>      >>
>      >> 3) the availability and flexibility of the bandwidth in/out of the
>      >> conference hotel(s).
>      >>
>      >> 4) the architectural requirements for good IPv6 and good meetecho
>      >> experience within the venue.
> 
>      > Where would the discussion about what type of security options to
>      > offer/ document fit ?
> 
> I'd put them in /dev/null.
> I think that IETF participants are adults, and don't need this, and
> I don't think the IETF should take on the liability of offering anything that
> probably won't really help anyway.
> 
>      >> I think that the document tries to do this, but I don't get the
>      >> impression the discussion split things up.
>      >>
>      >> One could imagine a situation where the Meetecho network was a
>      >> different network from the Participant network.  I'm not saying that's
>      >> a good plan, but I'm saying that I think that we should think about
>      >> whether we are expending a lot of effort in one area for reasons that
>      >> are relating to another area.
> 
>      > Not sure what other think to be meetecho problems. I only thoght the
>      > video quality from remote participants sucked but didn't get an answer
>      > whether thats because of unavoidable remote participant upstream limits
>      > or application level enforced uper bandwidth/quality limits.
> 
> Meetecho gets wired infrastructure into each meeting room.
> If not for that, if the hotel had decent Access Points, then we might not
> have to wire the meeting rooms at all.  If the hotel had large enough
> capacity Internet, but perhaps too poor (bufferbloated) latency, we might be
> able to get by providing an appropriate network for Meetecho only via other
> means.
> 
> I know that Meetecho is used at other conferences, and I assume that those
> conferences do not bring the same kit that IETF brings, so I wonder what they
> do there, and what problems we are avoiding.

Meetecho is mostly used at other conferences for _streaming_ only, not 
for actual _remote participation_. I.e., no remote audio/video injection 
into the physical room, no virtual queue. RTC servers are not deployed 
on site. A good uplink bandwidth from the conference venue is still 
required.

At IETF, Meetecho deploys remote participation servers at the meeting 
venue mainly for two reasons:
	1. minimize the delay, which is critical to have remote participants 
participate to Q&A or give presentations;
	2. feed them with audio+video from the meeting rooms via LAN, over a 
dedicated vLAN, so to not be affected by packet loss and external 
network conditions.

Alessandro

-- 
Alessandro Amirante, Ph.D.

Meetecho S.r.l.
www.meetecho.com