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.
- [vmeet] Experience as a remote attendee Stewart Bryant
- Re: [vmeet] [95attendees] Experience as a remote … HANSEN, TONY L
- Re: [vmeet] Experience as a remote attendee John Leslie
- Re: [vmeet] Experience as a remote attendee Dan York
- Re: [vmeet] Experience as a remote attendee chopps
- Re: [vmeet] Experience as a remote attendee Dave Crocker
- Re: [vmeet] Experience as a remote attendee Simon Pietro Romano
- Re: [vmeet] Experience as a remote attendee John C Klensin
- Re: [vmeet] Experience as a remote attendee Simon Pietro Romano
- Re: [vmeet] Experience as a remote attendee HANSEN, TONY L
- Re: [vmeet] Experience as a remote attendee Martin J. Dürst
- Re: [vmeet] Experience as a remote attendee Simon Pietro Romano
- Re: [vmeet] Experience as a remote attendee Martin J. Dürst
- [vmeet] Hackathon remote attendees - Re: Experien… Dan York