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. Now, coming to one of your comments: > 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: sprom...@unina.it <<Molti mi dicono che lo scoraggiamento è l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet