Re: [Netrqmts] IETF 105 Minutes

Alessandro Amirante <alex@meetecho.com> Wed, 31 July 2019 09:27 UTC

Return-Path: <alex@meetecho.com>
X-Original-To: netrqmts@ietfa.amsl.com
Delivered-To: netrqmts@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7A6120275 for <netrqmts@ietfa.amsl.com>; Wed, 31 Jul 2019 02:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1Mle7MwGfCA for <netrqmts@ietfa.amsl.com>; Wed, 31 Jul 2019 02:27:46 -0700 (PDT)
Received: from smtpcmd04131.aruba.it (smtpcmd04131.aruba.it [62.149.158.131]) by ietfa.amsl.com (Postfix) with ESMTP id E21C412024E for <netrqmts@ietf.org>; Wed, 31 Jul 2019 02:27:45 -0700 (PDT)
Received: from [192.168.1.230] ([93.44.57.15]) by smtpcmd04.ad.aruba.it with bizsmtp id jMTi2001E0KiRsV01MTjl5; Wed, 31 Jul 2019 11:27:44 +0200
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: netrqmts@ietf.org
References: <DF3803B7-C05B-4A31-B873-73A86B1416CE@vigilsec.com> <19915.1564514403@localhost> <20190730202439.zl6gjvzasxofvej2@faui48f.informatik.uni-erlangen.de> <27837.1564524525@localhost>
From: Alessandro Amirante <alex@meetecho.com>
Message-ID: <3fbb96e8-9977-39be-cd92-492b819aa1b9@meetecho.com>
Date: Wed, 31 Jul 2019 11:27:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <27837.1564524525@localhost>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1564565264; bh=9AK/KyUtHgKgBMOpLq10vhFlR5V+0GSbYurjdojdvZk=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=VpELgiEP3p1L7lhK1ih3uwEH1khmz1YvBOYylAjFCKXNLFmwPnxLak/bDvOEfG/7+ EA77GtDTW1UbBYESMMHOs3ZBA8TvKrwOfaq03vibtw+OURSk2tlAVDHMsPWcWpu0xS mBINWwOpMvhi2BnQA7OudDcPeIPN5aIRNr1x2CRjuQW1pPCEF0bxIzlAT9XyzuepIy lb9Ot0tz8K28Vd1rDo2WZ09ko1MJdIhvg+w22/McD8xiEJLkm9dUF0g2hEKHa18j1W VkBP+NpE7ff9AuwBsbl5xlu+h3Ai/IKEeIcPIDW8SSCklFhbABg2tltM9KY3+OO4qm hrt5JSf7Qw+Xg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/6GYJ8pb3Wb869vke5ARcC-9xdxI>
Subject: Re: [Netrqmts] IETF 105 Minutes
X-BeenThere: netrqmts@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <netrqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netrqmts/>
List-Post: <mailto:netrqmts@ietf.org>
List-Help: <mailto:netrqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 09:28:01 -0000

Il 31/07/19 00:08, Michael Richardson ha scritto:
> 
> Toerless Eckert <tte@cs.fau.de> 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