Re: [Netrqmts] IETF 105 Minutes

Michael Richardson <> Wed, 31 July 2019 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C31701201C8 for <>; Wed, 31 Jul 2019 11:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fJH3WfNQuPoR for <>; Wed, 31 Jul 2019 11:32:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9936E12019C for <>; Wed, 31 Jul 2019 11:32:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 92176380BE; Wed, 31 Jul 2019 14:31:59 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 17C52205; Wed, 31 Jul 2019 14:32:25 -0400 (EDT)
From: Michael Richardson <>
To: Alessandro Amirante <>,
In-Reply-To: <>
References: <> <19915.1564514403@localhost> <> <27837.1564524525@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 31 Jul 2019 14:32:25 -0400
Message-ID: <13156.1564597945@localhost>
Archived-At: <>
Subject: Re: [Netrqmts] IETF 105 Minutes
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 18:32:29 -0000

Alessandro Amirante <> 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.

    > 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   [
]        |   ruby on rails    [