Re: IETF 107 and Corona Virus? - scaling infra

John C Klensin <john-ietf@jck.com> Sat, 15 February 2020 19:02 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EF712008A for <ietf@ietfa.amsl.com>; Sat, 15 Feb 2020 11:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 o0dcrltkd7fj for <ietf@ietfa.amsl.com>; Sat, 15 Feb 2020 11:02:14 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5259120058 for <ietf@ietf.org>; Sat, 15 Feb 2020 11:02:13 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1j32hf-0003cf-Ha; Sat, 15 Feb 2020 14:02:11 -0500
Date: Sat, 15 Feb 2020 14:02:04 -0500
From: John C Klensin <john-ietf@jck.com>
To: Robert Raszuk <robert@raszuk.net>
cc: ietf@ietf.org
Subject: Re: IETF 107 and Corona Virus? - scaling infra
Message-ID: <5CBB6602066BF4A674D4D092@PSB>
In-Reply-To: <666CACAD-F8D4-43A1-8336-3CC9BBCC4B08@puck.nether.net>
References: <CAOj+MMEMY1gxtj70+5wPOG+XHsk_nX8af4kbXD30_ULDmHMyQg@mail.gmail.com> <666CACAD-F8D4-43A1-8336-3CC9BBCC4B08@puck.nether.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4nb7plnxckYHEsMk0VE8xKgJpLo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Feb 2020 19:02:17 -0000


--On Saturday, Feb 15, 2020, at 10:27 AM, Robert Raszuk
 <robert@raszuk.net> wrote:

> If we only make it as a rule that questions from remote
> participants can be submitted via notepad instead of live
> conference chat window, the scaling properties could be more
> than satisfactory even if 100s of folks join remotely.  

Based on a good deal of active remote participation experience,
I don't know whether this is a good idea or not.  If it were to
be a good idea and a much higher than usual level of remote
participation were anticipated, every WG session (and the
plenary) should be required [1] to have at least two notepad
scribes/readers dedicated to the remote queue and at least two
separate mic lines with one of the latter dedicated to those
scribes.  For the latter, once someone got to the mic, he or she
would exhaust every question or comment that had been logged
while the other took notes, then they would switch off while
people were taken from the in-room queues.  

That would still not be ideal in terms of queue management and
fairness but I note that, in many WG sessions and plenaries in
the past, remote participants have had trouble getting their
questions and perspectives into the room even with low levels of
active [2] remote participation.  For really active remote
participation, I suggest that, in the last couple of years, we
have done responsibly well in some WGs but barely squeaked by in
others and in the plenaries, with the key problems being human
rather than technology ones.

I think it is also relevant to note that one of the problems
with remote participation in the recent past has been that those
who are typing into jabber and having their questions read often
find that, by the time they are through typing in a question or
comment, the jabber scribe notices and heads for the mic line,
then waits to get to the front of the queue, and then reads
whatever was typed in, the topic may have moved on to the point
that the comment is no longer relevant.    I've even had mic
lines cut off while I was typing and before the scribe can get
to the mic.  Assuming the WG Chairs are paying attention to the
indication that there is someone waiting in the Meetecho queue,
it is much better in that regard because, just like standing in
a mic line, one can signal a desire to speak but adjust actual
comments to reflect ensuing conversation.  

>From the standpoint of that real-time input experience (and,
again, assuming Chair are paying attention and cooperating) the
Meetecho speaking queue works better than Jabber input and I
would predict Jabber input would work better than the Etherpad
or equivalent.  The latter might turn out to be lots better for
logging a question or comment for the permanent record than for
active discussion, but, at least IMO, the purpose of real-time
WG sessions is active and real-time discussion, not logging
comments in the hope that someone will look at them eventually.

Noting that Ron asked an essentially technical question about
capacity of the infrastructure and that he has yet to receive a
response (at least on-list) from anyone who actually knows how
the relevant systems work, I suggest that answers and plans
about both his questions and the issues raised above are
important to any decision that might significantly raise levels
of remote participation. 

best,
   john
   (who would probably have been remote from Vancouver even
without the virus)

[1] "Required" as in "if the required level of support is not
present in the room, the WG session is canceled in real time,
everyone present goes out for coffee (or other beverages of
choice), and any work expected to be done in that session either
moves to the mailing list or is delayed for an all-virtual
meeting or IETF 108".    Our usual way of handling remote
participants who don't get to participate is to [maybe]
apologize.  Because, in practice, we seem to be increasingly
making decisions in f2f meetings with ratification on mailings
lists --a process in which someone who was excluded from that
discussion can raise objections on the list but often has no way
to provide input into the discussion before the decision was
made-- there are probably grounds for appeal if the ratification
process assumes the validity of the f2f decision, but, AFAIK,
that hasn't happened yet.  Yet.

[2] In practice, we have three kinds of remote participants.
(1) Those who listen (whom Meetecho identifies as Observers),
(2) Those who sign up as participants but whose presence and
visibility in the actual meeting session might be limited to one
remark or question, and (3) Those who, despite being remote,
expect to actively participate in, and contribute to,
discussions going on in the room. The distinction is
particularly important if some of the remote participants are WG
Co-chairs, presenters, authors of documents, originators or
major contributors to proposals or specifications under
discussion, and so on.   At least in terms of IETF discussions
and decision-making fairly representing all perspectives and
points of view, we need to tune a remote participation system to
that active participant group while not seriously discriminating
against the other two.