Subject: [vmeet] Experience as a remote attendee

From: Stewart Bryant <[email-masked]>
Date: Fri, 8 Apr 2016 19:43:37 +0100

I attended remotely, connecting into a (one) session on pretty
well every slot. I had one persistent technical problem:

I was using W10 + Chrome Version 49.0.2623.110 m (64-bit)
and found that for every session I had to connect, then disconnect
then reconnect to get the slides.

This was repeatable enough that it must be a bug, although
whether client or server I would not know.

Apart from this the experience was great.

- Stewart

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 8 Apr 2016 18:25:19 +0000

If anyone has comments regarding meetecho, other virtual meeting tooling, and how to make them better, I encourage you to post them on the [email-masked] mailing list.

Tony Hansen

From: 95attendees <[email-masked]<mailto:[email-masked]>> on behalf of Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 8, 2016 at 2:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [95attendees] Experience as a remote attendee

This is the first time I have attended a remote IETF.

Apart from one persistent technical problem* with  Meetecho
I though that the experience was  as good as it gets
for a meeting split between local and remote attendees.

Thanks to all that relayed my comments from jabber to the
room, and thanks to the Meetecho team for their work.

Hope the next one will be F2F again.

- Stewart

*I was using W10 + Chrome Version 49.0.2623.110 m (64-bit)
and found that for every session I had to connect, then disconnect
then reconnect to get the slides.

---

From: John Leslie <[email-masked]>
Date: Fri, 8 Apr 2016 22:01:47 -0400

> then reconnect to get the slides.

   I had the same problem on MacOS 10.10.5 and Chrome 49.0.2623.110:
almost without fail _something_ would freeze during the session.

   I tried Opera with an older version, and it seemed better until
Opera decided to update itself (without me asking, of course).

   It got decidedly worse as the week wore on; so I suspect a memory
problem; but for all I know, that may have been in the cable modem,
not the computer. (Usually, I use DSL for connectivity, and haven't
seen this kind of problem.)

   Clearly, being able to restart a substream will really help.

   Also, a couple of times Meetecho folks gave me a slides-only link
which worked well for the remainder of the session.

   By the end of the week, I was usually selecting the HTML5 audio,
and it lasted through the session. (I have many years' experience
without the slides cycling in real-time, so it no longer bothered me
to lose the slides.)

   Serious debugging _during_ IETF-week really doesn't make sense;
but we ought to do it sometime...

--
John Leslie <[email-masked]>

---

From: Dan York <[email-masked]>
Date: Sun, 10 Apr 2016 09:41:52 +0000

John,

Great feedback. I was in BA this time but have been remote other times. 
Comments inline:

> problem; 

I wonder if there was an increase in usage during the week, either of Meetecho or also of the IETF network.  We may be able to find out from the Meetecho or NOC team.

> and it lasted through the session. 

I have always liked having the option of the audio-only streams for just having that go on in the background.

> but we ought to do it 

I agree... BUT... I wonder if we can actually replicate the necessary conditions outside of during an actual IETF week.  It seems to me the loads on the Meetecho servers and network may only be possible during an event week... But there may be other ways to add load.

Anyway, good comments! Thanks for the report,
Dan

---

From: <[email-masked]>
Date: Sun, 10 Apr 2016 09:27:48 -0400

> I agree... BUT... I wonder if we can actually replicate the necessary conditions outside of during an actual IETF week.  It seems to me the loads on the Meetecho servers and network may only be pos…

Perhaps if there was an announced testing/debugging sessions on Fri or
Sat prior we could get a lot of people to join. Friday would be best b/c
people then could be at work (possibly) replicating what their actual
experience would be the following week, but that might be too early
for the IETF on-site end of things.

Thanks,
Chris.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 10 Apr 2016 06:59:09 -0700

>>                   It
>> seems to me the loads on the Meetecho servers and network may only
>> be possible during an event week... But there may be other ways to
>> add load.
>
> Perhaps if there was an announced testing/debugging sessions on Fri
> or Sat prior we could get a lot of people to join. Friday would be
> best b/c

+1

d/

---

From: Simon Pietro Romano <[email-masked]>
Date: Sun, 10 Apr 2016 22:11:10 +0200

Hello Dan,

I hope I can add some more bits to this discussion. 
I was remote this time and I seized this as an opportunity to live the Meetecho experience  from the other side for once! 
I have been attending a bunch of sessions, both from my university office and from home (overnight sessions in Italy due to the 5-hours time shift). At the university I have a high-bandwidth connection, which allowed me to easily open up to 8 Meetecho virtual rooms in parallel with no issue. At home I connect through WiFi to my home gateway, from which I have an ADSL (Asymmetric DSL, which means I have around 4 Mbit/sec downlink and less than 1 Mbit/sec uplink to the Internet backbone). Such a link allowed me to reliably attend at most a couple of parallel sessions. With more than that, I could experience hiccups from time to time, which is as expected, given the fact that each session involves two video streams (each of which accounts for about 400 Kbit/sec on average), plus an audio stream (let’s say about 150 Kbit/sec or so). 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. I can also confirm that the  internal WiFi connection to the ADSL router concurs in reducing the reliability level of real-time streaming (which by the way occurs to me also when I watch a Netflix movie with my family). A wired connection to the router definitely makes the life of a real-time session much easier.
All in all, I can confirm that attending a single session can be considered, from my personal experience, close to 100% reliable in the above described conditions.

As a final remark, I would like to highlight the fact that the connection from BA to Italy was showing a really weird behavior in terms of network performance as a function of the time of the day. And this is something I have not been able to fully understand (even though I teach an Advanced Computer Networks class since 1998 ;-) ). I am still investigating this, by looking at things like BGP route flapping, time-dependent traffic shaping policies — at the firewall level — on the Italian Research backbone and/or at the ingress router of my University campus network, etc.. 

To give you an idea of what I am talking about, I’ll provide you with some side information:

- we record all Meetecho sessions on-site (i.e., this time, in BA);
- at the end of each slot (lunch break and end of the day) we transfer, via scp (secure copy command) all recorded files to a backend server hosted in Italy;
- the lunch-time transfers happened at an average speed of more than 4MB/sec;
- evening (in BA, which means night time in Italy) transfers happened at less than 50KB/sec, which is astonishingly less than the other figure above;
- a basic “ping” from BA to Italy resulted in around 300 msec estimated round-trip time during day and more than 500 msec at nights.

> I wonder if there was an increase in usage during the week, either of Meetecho or also of the IETF network.  We may be able to find out from the Meetecho or NOC team.

As far as Meetecho is concerned, the load has been quite stable over the week. Monday has, by the way, represented a peak for what concerns remote presentations (more than 25 of them, if I recall correctly).

Hope this helps,

Simon

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 Apr 2016 17:38:48 -0400

Simon,

A thought about one aspect of your note...

--On Sunday, April 10, 2016 22:11 +0200 Simon Pietro Romano
<[email-masked]> 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.

---

From: Simon Pietro Romano <[email-masked]>
Date: Sun, 10 Apr 2016 23:48:37 +0200

Hi John,

both your thoughts are not only wise, but already on the high-priority to-do list for the Meetecho team. We'll keep you and the others updated with respect to these and other improvements to the platform.

Thanks a lot for your feedback,

Simon

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 11 Apr 2016 01:27:02 +0000

There's potential use there at either the code sprint or hackathon. I could see how some either team could definitely include remote participants.

	Tony

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 11 Apr 2016 17:16:53 +0900

Hello Simon,

> - a basic “ping” from BA to Italy resulted in around 300 msec estimated round-trip time during day and more than 500 msec at nights.

You call such daily variations "weird", but aren't they pretty usual? 
People don't use the Internet with the same intensity all day round. 
Depending on the overall usage profile, usage will be higher during 
business hours, or during leisure hours. With video these days 
contributing a lot to overall bandwidth consumption, usage during 
leisure hours can easily get higher than during business hours.

Regards,   Martin.

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 11 Apr 2016 10:21:39 +0200

Hello Martin,

> You call such daily variations "weird", but aren't they pretty usual? People don't use the Internet with the same intensity all day round. Depending on the overall usage profile, usage will be higher during business hours, or during leisure hours. With video these days contributing a lot to overall bandwidth consumption, usage during leisure hours can easily get higher than during business hours.

The problem is how you define leisure hours. Can the 1am to 6 am time interval (Italian time) be considered as a leisure slot? It depends on what one means by the term “leisure”, I guess!

Simon

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 11 Apr 2016 17:33:13 +0900

> The problem is how you define leisure hours. Can the 1am to 6 am time interval (Italian time) be considered as a leisure slot? It depends on what one means by the term “leisure”, I guess!

Some people tend to do weird things at weird hours. But I'd agree that 
after 3am, most people tend to sleep at least a bit. But the same slot 
moved 5h earlier (i.e. Argentine time) would match much better sence for 
my understanding of leasure time.

Regards,   Martin.

---

From: Dan York <[email-masked]>
Date: Mon, 11 Apr 2016 09:11:31 +0000

Tony (and everyone)

> On Apr 10, 2016, at 9:27 PM, HANSEN, TONY L <[email-masked]> wrote:
> 

At the IETF 95 Hackathon in Buenos Aires, several teams DID have remote participants. If I recall correctly there was one team that had 2 people in the room and 3 people in other parts of the world. On the DNS team of which I was a part, we had 2 people back in the US who were part of what we were doing. 

There was communication happening with remote participants, but the real-time communication seemed to be through services like a Google+ Hangout.  There were also private chat rooms set up using a variety of technologies. (We used a jabber server operated by one of the participants. I heard another team using Slack. I know there were other chat rooms.)

There was also a "[email-masked]" chat room for general comments, but that didn't get much use. 

The challenge with potentially using Meetecho is similar to this general jabber group chat - there is typically *one* Meetecho session for a room, but each of the Hackathon teams wants/needs to operate independently. 

The only times the group is really all together is Saturday morning when the projects are first introduced and then Sunday afternoon when the presentations are given and then the awards are announced.  Between those times, everyone is focused on their own activities and working together as part of small teams.  (And at IETF 95, there were about 12 different teams.)

There definitely is a need to bring in remote attendees to the Hackathon, but it needs to be focused on the small, individual teams. And that need currently seems to be being met through various techniques. 

Having said all this... I will ask on the hackathon mailing list what different teams used and get back to this list with that info. 

Dan