Re: [vmeet] Experience as a remote attendee

John C Klensin <john@jck.com> Sun, 10 April 2016 21:38 UTC

Return-Path: <john@jck.com>
X-Original-To: vmeet@ietfa.amsl.com
Delivered-To: vmeet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7B12D0F0 for <vmeet@ietfa.amsl.com>; Sun, 10 Apr 2016 14:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 2tgq_RxDR2S3 for <vmeet@ietfa.amsl.com>; Sun, 10 Apr 2016 14:38:56 -0700 (PDT)
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 DBA3A12D0B9 for <vmeet@ietf.org>; Sun, 10 Apr 2016 14:38:55 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1apN4H-000FMp-3X; Sun, 10 Apr 2016 17:38:53 -0400
Date: Sun, 10 Apr 2016 17:38:48 -0400
From: John C Klensin <john@jck.com>
To: Simon Pietro Romano <spromano@unina.it>
Message-ID: <3B7CAFC7A3B7A57785E9BA26@JcK-HP8200.jck.com>
In-Reply-To: <2FC2AFBA-5B33-44CE-A618-890B742EE5EC@unina.it>
References: <D51111F6-66B9-4FAF-9B6D-FF9AE7E20D0D@att.com> <5707FBD9.6070506@gmail.com> <20160409020147.GA3997@verdi> <6EC9873F-B427-475B-B187-BE352676C4C9@isoc.org> <2FC2AFBA-5B33-44CE-A618-890B742EE5EC@unina.it>
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@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/vmeet/EfmBkUNY-Sn2Kdy9HuXwoS_YpkY>
Cc: vmeet@ietf.org
Subject: Re: [vmeet] Experience as a remote attendee
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vmeet/>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2016 21:38:57 -0000

Simon,

A thought about one aspect of your note...

--On Sunday, April 10, 2016 22:11 +0200 Simon Pietro Romano
<spromano@unina.it> wrote:

>...
>  In case of remote presentations, each remotee obviously adds
> one further video stream to the pack. If you add to that the
> lower- bandwidth Meetecho traffic (chat, client-server polling
> and the like), plus some background traffic not generated by
> Meetecho, you easily arrive at (or close to) saturation. 
>...

So, suppose one has several "remotees" sending video.  I don't
think we've seen that so far with IETF, where it has tended to
be, at most, one remote presenter at a time, but it could easily
occur if/as we start introducing remote hubs as a serious
participation (as distinct from outreach) mechanism.

While Meetecho has relatively good arrangements (now) for
switching the screen from a focus on slides to a focus on one or
another of the video streams and back [1], if I'm a remote
person who is bandwidth-limited or computer-cycles-limited, I'd
really like to be able to control which video stream(s) are
competing for that bandwidth.  Now, for the general case, I
think that is unrealistic.   But it may be that a pair of
Meetecho feeds, one more or less as present and the other
designed to minimize bandwidth  -- fewer video panes on the
right even you have to scan between them, maybe lower resolution
in those panes compared to the center one, etc. -- would be
worth thinking about.

On a slightly related topic, the way Meetecho appears on my
screen forces me to make a choice between the "Participants"
pane and the Jabber one on the left even when there is a lot of
spare real estate on the right (due to only one video stream
plus monitoring my local camera which is apparently not being
sent back to you anyway).   Possibly some rethinking of those
relationships might be useful.

best,
   john

p.s. As someone who has been doing this for most (but not all)
meetings for a while, let me add my voice to others -- the
meeting over meeting and year over year improvements are nothing
short of fantastic.


[1] Once one figures out how to use it; the "finding out how"
parts remain a bit problematic.