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: [email protected]
<<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
