[Netrqmts] R: Re: IETF 105 Minutes

Alessandro Amirante <alex@meetecho.com> Wed, 31 July 2019 19:29 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 53E011200A4 for <netrqmts@ietfa.amsl.com>; Wed, 31 Jul 2019 12:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EKAA6Xp6wFmG for <netrqmts@ietfa.amsl.com>; Wed, 31 Jul 2019 12:29:19 -0700 (PDT)
Received: from smtpcmd14161.aruba.it (smtpcmd14161.aruba.it [62.149.156.161]) by ietfa.amsl.com (Postfix) with ESMTP id BDEAE12006D for <netrqmts@ietf.org>; Wed, 31 Jul 2019 12:29:18 -0700 (PDT)
Received: from [192.168.1.70] ([93.40.13.11]) by smtpcmd14.ad.aruba.it with bizsmtp id jXVG2000E0EJPEd01XVGVz; Wed, 31 Jul 2019 21:29:17 +0200
Date: Wed, 31 Jul 2019 21:29:14 +0200
Message-ID: <np754afisdg0cv28tlb574hu.1564601354124@email.android.com>
From: Alessandro Amirante <alex@meetecho.com>
To: netrqmts@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
MIME-Version: 1.0
In-Reply-To: <13156.1564597945@localhost>
References: <DF3803B7-C05B-4A31-B873-73A86B1416CE@vigilsec.com> <19915.1564514403@localhost> <20190730202439.zl6gjvzasxofvej2@faui48f.informatik.uni-erlangen.de> <27837.1564524525@localhost> <3fbb96e8-9977-39be-cd92-492b819aa1b9@meetecho.com> <13156.1564597945@localhost>
Content-Type: multipart/alternative; boundary="--_com.sonymobile.email_2082027738139550"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1564601357; bh=2YtVQvNaRjudZ+1FBXLmfnTzQQ1ZDQlWO7bjQhtJyRo=; h=Date:Subject:From:To:MIME-Version:Content-Type; b=K2W+hY7+R9MtzxhJ54V9Z8R0EHzXi7qMeRNzTKJqit9HLV/2nw+b/0qH+HqcXmyfz yZJcxsUX/TdYxZ3fXGuneC6KnRUxpgYBxskyvSJRMT0oAWSAUimOQaTZhrvYFbIUNo i7vyG3SxN2Pkolsfikka8xZ2b1RxjUw47tX2Q1hmbQsNnTXntrr6psT6T1BQ3dYL+9 HMjlCvRymQ0vmPrzK+P2iclNH6qU+rqbw4G+4jolc4V+N10AqM4swaLAUPysG1gG7Q Z/jruVxr7od1mEvKAI6KdeTN5a6NLlCqK9zTyOgAaP3ZLSETwz0HC0vVK4aV+SGE/6 SH+Um9GlC7deg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/jU3aRDHyPsEuyvSCFrKSa_DfzIU>
Subject: [Netrqmts] R: Re: 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 19:29:22 -0000

---- Michael Richardson ha scritto ----

> Alessandro Amirante <alex@meetecho.com> wrote:
>     >> 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.
> 
> Thanks for this update.
> Can you explain the reasons why other conferences/meetings do not do remote
> participation?  Is it economic (too expensive for them), or just logistical
> (it's unidirectional slideware really), or it is because they lack a
> real Internet connection, and so you can't even consider discussing it.

They are conferences: they're not interested in having remote participants contribute with questions or even presentations. My guess is that they want people to show up in person, pay the conference fee...

I'd love to push remote participation to other SDOs, though!

A.

>     > 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.
> 
> I can't estimate what about of incremental work this requirement causes
> for the NOC over what we do *today*.  I suspect it's non-trivial, but
> not complex.
> 
> Clearly, if we had a fully NAT44 network that most other meetings have, that
> we'd be looking at more effort.  Either bringing in real networking, or
> having some cloud component.
> 
> This is, I think, an example of synergies that we get from having a real
> network.  We are lowering the bar for things like Meetecho, but we might
> never consider doing this just for Meetecho.
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [