IETF
iccrg
iccrg@jabber.ietf.org
Wednesday, November 12, 2014< ^ >
jishac has set the subject to: Internet Congestion Control Research Group
Room Configuration
Room Occupants

GMT+0
[01:17:05] Randell Jesup joins the room
[01:19:46] John Leslie joins the room
[01:20:29] jlcJohn joins the room
[01:21:02] Randell Jesup leaves the room
[01:21:13] Randell Jesup joins the room
[01:22:25] Meetecho joins the room
[01:22:34] Lars joins the room
[01:24:21] rachel huang joins the room
[01:26:02] <jlcJohn> I _can't_ read it on MeetEcho
[01:26:14] Lorenzo Miniero joins the room
[01:26:25] <Randell Jesup> shared screen is fubar
[01:26:44] <Randell Jesup> Now shows clean "Meetecho"
[01:26:47] <Meetecho> yep working on that
[01:26:55] <Meetecho> there was an issue with the beamer feed
[01:27:16] <jlcJohn> thanks
[01:27:38] Lorenzo Miniero leaves the room
[01:28:46] Matthew Ford joins the room
[01:35:08] Fuyou Miao joins the room
[01:41:18] <Randell Jesup> Note: no slides, just black
[01:41:43] PasiS joins the room
[01:42:54] Fuyou Miao leaves the room
[01:42:59] Lorenzo Miniero joins the room
[01:43:16] <Meetecho> Randell Jesup: feeds looking fine here
[01:43:37] <Meetecho> try rejoining if it doesn't recover
[01:44:47] <Randell Jesup> mic: a few things: SPDY/HTTP2 affects how this works.  Website sharding to make the browser generate a ton of requests to get faster load on good connections.  And anything that pounds the connection at startup will hurt competing interactive applications (i.e. RMCAT/WebRTC)
[01:45:05] Randell Jesup leaves the room
[01:45:06] Lorenzo Miniero leaves the room
[01:45:22] Randell Jesup joins the room
[01:45:55] <Randell Jesup> just left and rejoined.  let's see
[01:49:50] <Randell Jesup> can someone relay my comments from a few minutes ago?
[01:50:49] <Randell Jesup> or provide them to Welzl after the meeting
[01:51:34] <Lars> done
[01:51:55] <Randell Jesup> thanks
[02:00:11] <Randell Jesup> FYI, mic video once in a while s good for a few seconds, then is basically hash/predator-mode.  The slides finally stopped being black, but is entirely hash.  Similar results in Chrome and FF nightly, BTW
[02:09:37] <Meetecho> I guess that a lot of retransmissions are taking place, and since the video is broadcasted there's no way to reduce the bitrate for single participants, have you noticed any unusual feedback in the webrtc debug pages for the feeds?
[02:16:12] PasiS leaves the room
[02:18:03] <Randell Jesup> for one stream (vdeo) looks like ~500 packets lost in ~3-4 minutes from the rate of increase in total lost
[02:18:34] <Randell Jesup> receiving ~100Kbps
[02:19:57] <Randell Jesup> the other vdeo link (mic video?) has many more lost packets (~30K so far since I restrarted 30 min ago)
[02:20:03] <Meetecho> the slides feed is ~200kbps, the speakers feed ~100kbps so both shouldn't be too hard to handle, unless bw is an issue or the network is loosing many packets
[02:20:08] <Randell Jesup> bitrate there 50-75Kbps
[02:20:28] <Randell Jesup> I'm on a 90Mbps up/down link
[02:20:29] <Meetecho> the streaming server handles NACKs on behalf of the broadcaster
[02:20:44] <Meetecho> yep I guessed so, so that's why I'm wondering what may be the issue
[02:21:49] <Randell Jesup> though FiOS/Verizon has a few gateways that are evil for TCP traffic (not really UDP) due to conflict wth Netflix
[02:23:02] <Randell Jesup> I'm receiving ~1/2 the bitrates you say.  Audio is ok (but much more protected against loss distortion)
[02:23:16] <Meetecho> something is likely lost somewhere, we'll have to add some stats on our server to track packets that may not have left the server (should not be the case)
[02:23:46] <Randell Jesup> audio bitrate is ~24Kbps
[02:30:25] <Randell Jesup> The FiOS thing 've never seen affect UDP.  And TCP it's hit-or-miss - if it's slow (10Kbps), stop and restart a few times until it suddenly runs at N Mbps
[02:30:55] <Randell Jesup> And only a few gateways are affected - like Mozilla's ISP's!
[02:32:47] <Meetecho> not sure what the issue might be: you may want to check later (when the session is over, of course!) this link to see if that works for you instead: http://janus.conf.meetecho.com/streamingtest.html
[02:33:05] <Meetecho> there's an opus/vp8 stream that is similar to what we serve here
[02:33:21] <Meetecho> the server is in Italy and not Honolulu though (and I think no TURN server is configured either)
[02:38:23] Meetecho leaves the room
[02:38:24] Meetecho joins the room
[02:41:36] Lars leaves the room: Disconnected: session closed
[02:43:52] rscheff joins the room
[02:46:52] Richard Scheffenegger joins the room
[02:47:30] rscheff leaves the room
[02:47:59] <Randell Jesup> that link s perfect
[02:48:05] Richard Scheffenegger leaves the room
[03:00:10] <Meetecho> Randell Jesup: the server implementation is the same and the feeds are generated pretty much the same way, so it must be some packets that are dropped somewhere between your location and Honolulu
[03:00:49] Matthew Ford leaves the room
[03:12:16] rachel huang leaves the room
[03:18:44] John Leslie leaves the room
[03:21:20] jlcJohn leaves the room
[03:21:27] Meetecho leaves the room
[04:15:22] rscheff joins the room
[04:52:10] rscheff leaves the room
[05:36:57] rscheff joins the room
[11:36:07] rscheff leaves the room
[11:36:10] rscheff joins the room
[13:47:39] rscheff leaves the room
[18:58:32] PasiS joins the room
[18:59:39] rscheff joins the room
[19:00:07] rscheff leaves the room
[19:01:21] PasiS leaves the room