IETF
iccrg
iccrg@jabber.ietf.org
Tuesday, 27 March 2012< ^ >
jishac has set the subject to: Internet Congestion Control Research Group
Room Configuration

GMT+0
[01:13:31] thomas.dreibholz joins the room
[01:21:59] thomas.dreibholz leaves the room
[13:00:12] thomas.dreibholz joins the room
[13:08:47] Zahed Sarker joins the room
[13:12:23] thomas.dreibholz leaves the room
[13:12:40] thomas.dreibholz joins the room
[13:13:07] thomas.dreibholz leaves the room
[13:13:19] thomas.dreibholz joins the room
[13:25:25] gorryf joins the room
[13:25:35] Andrew McGregor joins the room
[13:25:44] Scott Brim joins the room
[13:25:56] malc joins the room
[13:26:02] <Scott Brim> :is in
[13:26:17] Lars joins the room
[13:26:35] <Scott Brim> is there anyone here that is not in the room?
[13:26:41] <gorryf> Hi I'm doing the notes - so please make sure you say WHO you are slowly (gorry fairhurst)
[13:27:32] <gorryf> Can people hear the speaker?
[13:27:34] <Zahed Sarker> yes
[13:27:47] <Zahed Sarker> I am attending remotely
[13:27:57] <Zahed Sarker> yap
[13:28:12] <thomas.dreibholz> I am attending remotely, too.
[13:46:53] hta joins the room
[13:52:04] <gorryf> Dirk at Mic:
[13:54:24] jlcJohn joins the room
[13:56:23] Martin Becke joins the room
[13:57:27] Scott Brim leaves the room
[13:57:48] Cullen Jennings joins the room
[13:58:10] <gorryf> Pasi Presenting
[13:58:27] <Martin Becke> I am attending remotely, too.
[14:02:34] wesley.m.eddy joins the room
[14:08:22] <gorryf> Janna at mic:
[14:15:57] hta leaves the room
[14:16:46] <gorryf> * On the Fairness of Transport Protocols in a Multi-Path Environment
Hakim Adhari (based on an upcoming ICC 2012 paper)
[14:19:34] thomas.dreibholz leaves the room
[14:19:45] thomas.dreibholz joins the room
[14:20:19] thomas.dreibholz leaves the room
[14:20:30] thomas.dreibholz joins the room
[14:28:40] <gorryf> Costin:
[14:32:37] <gorryf> Mirja:
[14:34:41] <gorryf> * End-to-End Transmission Control through Inference about the Network
Keith Winstein http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf
[14:43:30] <Zahed Sarker> what is the slide number he is at?
[14:48:13] <gorryf> * TCP Reno over Network Coding
Nadia Boukhatem https://www.usukita.org/papers/5979/TA1_17_Chen_combocoding.pdf
[15:02:53] Cullen Jennings leaves the room
[15:06:21] <Zahed Sarker> What happened? I lost the audio. Anybody else have this problem?
[15:06:41] dtaht joins the room
[15:07:59] hta joins the room
[15:08:17] jesup joins the room
[15:08:25] <thomas.dreibholz> The audio stream seems to be broken. I cannot hear anything.
[15:08:41] <jesup> I can hear it
[15:08:53] <jesup> where are we in the schedule?
[15:09:09] thomas.dreibholz leaves the room
[15:09:46] thomas.dreibholz joins the room
[15:10:22] rscheff joins the room
[15:13:59] thomas.dreibholz leaves the room
[15:14:19] <gorryf> Now: * Research opportunities related to TCP Laminar
Matt Mathis draft-mathis-tcpm-tcp-laminar-00
[15:19:00] Martin Becke leaves the room
[15:19:21] Jonathan Lennox joins the room
[15:21:18] <gorryf> Jana at Mic:
[15:24:07] hta leaves the room
[15:24:57] <gorryf> Topic chair: Harald Alvestrand
[15:25:10] <gorryf> * Introduction: The RTCWEB effort, and the traffic we expect to generate - Harald (10 min)
[15:28:22] <jesup> Mostly people are using stuff minimally documented or not at all
[15:29:00] <dtaht> documentation is ok,code is better.
[15:29:45] <jesup> Classic VoIP knee is 150ms one-way (not RTT)
[15:29:51] <gorryf> * Nice behaviour for RTP-based services - Varun Singh, Colin Perkins (10 min)
[15:29:58] <jesup> gets bad around 200-250ms one-way
[15:38:40] <gorryf> Matt at Mic
[15:39:48] <jesup> people have implemented variations on this ad-hoc
[15:40:10] <gorryf> Bob at Mic
[15:45:00] <gorryf> * A delay based congestion control candidate
Stefan Holmer draft-alvestrand-rtcweb-congetstion-01
[15:47:06] <jesup> Comment for whne there's an opening: Note that this assume no functional AQM (if he AQM drops instead of queuing)
[15:47:13] <jesup> (pointed out to me recently)
[15:48:09] <Zahed Sarker> also only FIFO queues are assumed I guess
[15:49:31] <jesup> Non-fifo is ok, since we're watching actual delay deltas
[15:49:59] <jesup> non-fifo will cause more jitter and take longer (perhaps) to stabilize the filter)
[15:50:58] gettys joins the room
[15:51:06] <jesup> I designed an CC algorithm very similar to this in 2004 that's been in use since then
[15:51:14] tterribe joins the room
[15:51:45] <jesup> gettys: Comment for whne there's an opening: Note that this assume no functional AQM (if he AQM drops instead of queuing) - correct?
[15:52:10] <gettys> jesup: I'm not sure what you are asking...
[15:52:38] <jesup> i.e. if the bottleneck drops instead of queuing ('policing' IIRC)
[15:52:56] <tterribe> gettys: I.e., no RED.
[15:53:13] <gorryf> Do you want something asked at the Mic?
[15:53:14] <jesup> You'll see a higher loss rate whenever you go over, but little change in delay
[15:53:20] <tterribe> And yes, it's on the TODO slide right there.
[15:53:28] <jesup> ok, never mind
[15:53:43] <Zahed Sarker> yap it is in the TODO list
[15:54:09] <gettys> Note: delay based algorithms are not likely to be very useful once we have a working AQM.
[15:54:16] <gettys> By definition, those keep the delays low.
[15:54:40] <jesup> In which case we're happy :)
[15:54:45] <gettys> not entirely.
[15:54:58] <gettys> The problem then is that things like bittorrent begin again to compete with TCP.
[15:55:06] <tterribe> Well, until the algorithm says "just keep increasing the bitrate, it's apparently not a problem"
[15:55:07] <gettys> We still have to deal with that problem.
[15:55:29] <jesup> It will see loss and back off from that
[15:55:33] <gorryf> * Feedback mechanisms that might be useful
Harald Alvestrand draft-alvestrand-rmcat-remb-00
[15:55:53] <gettys> jesup: yes, but if you have 100 flows of BitTorrent, competing against your few other flows, you'll be unhappy.
[15:55:53] <gorryf> Status update from Harald
[15:56:18] <jesup> It has to degrade to loss-based in order to survive competing with high volume TCP
[15:56:30] <gettys> yes, but even that may be insufficient.
[15:56:40] <tterribe> gettys: Isn't that already the situation today?
[15:56:43] <jesup> gettys: you'll be unhappy in any case there
[15:56:51] <gettys> (for bittorrent to stay out of TCP's way).
[15:56:51] <tterribe> I'm not sure why AQM makes that worse.
[15:57:04] Pasi Sarolahti joins the room
[15:57:37] <gettys> tterribe: it means we go from where bittorrent stays out of the way to again competing. So we have to deal with some way to again keep it in the background....
[15:57:58] <gettys> me thinks diffserv and other techniques should get used.
[15:57:58] Cullen Jennings joins the room
[15:58:23] <tterribe> WebRTC fully intends to use diffserv markings.
[15:58:29] <gettys> yup.
[15:58:32] <gettys> it needs to.
[15:58:42] <gettys> We also need to ensure things like bittorrent do so.
[15:58:50] <tterribe> That may be harder.
[15:58:50] <Cullen Jennings> was 12 or 13 people interested in working on this
[15:59:03] <tterribe> There's a lot of random bittorrent clients out there, of varying quality.
[15:59:06] <dtaht> I have some preliminary data showing ledbat competing against tcp, with red enabled.
[15:59:55] <dtaht> we go from ledbat scavanging... to competing with tcp on almost equal terms (except that ledbat is usually hundreds of streams, so it's a major lose)
[16:00:04] <gettys> exactly.
[16:00:15] <dtaht> I have some hope that the new sfqred stuff's head drop will do better things against ledbat...
[16:00:32] <gettys> we'll need a lead bat to apply to ledbat....
[16:00:37] <dtaht> but I suspect the sfq and red portions will more than compensate in the opposite direction
[16:00:59] dtaht would like some grant money directed at dario and the tcp-ledbat folk to further this research
[16:01:58] <jesup> Mic: Defining fairness is a very tough problem - with no really well-agreed on answer. Media adapts more slowly than TCP typically, and really wants to degrade less dramatically if it "steps over the border" (i.e. not aimd)
[16:02:04] <dtaht> http://perso.telecom-paristech.fr/~valenti/pmwiki/pmwiki.php?n=Main.LEDBAT I still need to verify that this is a fully compliant version of the draft in cerowrt.
[16:02:53] <dtaht> who's speaking?
[16:02:58] <gettys> Matt is dead on.
[16:03:02] <gettys> Matt Mathis.
[16:03:14] <dtaht> I enjoyed meeting him at google last week greatly.
[16:03:20] <gettys> I fear that the solution set is null.
[16:03:25] <jesup> Yes: we lose in those cases; and should transition to loss-based if we're forced into the corner
[16:03:38] <gettys> being able to *detect* you are losing is still very important.
[16:03:45] <gettys> Can someone make that point at the mike?
[16:04:03] <gettys> I'd like to be able to point fingers at brokenness, or we can't get it fixed.
[16:04:03] <jesup> gettys: in practice, delay-based algorithms work in most cases. Corners exists
[16:04:16] <gettys> jesup: in today's network, without AQM yes.
[16:04:23] <jesup> mic: ^ gettys' comment
[16:04:26] <gettys> But the problem will come back to haunt us.
[16:06:04] <gettys> detecting where the network is broken is *key* to getting the network fixed, as important as other congestion research....
[16:08:38] wesley.m.eddy leaves the room
[16:12:35] <gettys> Heh... "Kiddo, the Internet is slow today: Quit it!"
[16:12:47] <Zahed Sarker> :-)
[16:12:47] <dtaht> bisst!xcfasd!@#$!!!bzzt = failure
[16:12:50] Cullen Jennings leaves the room
[16:12:52] Andrew McGregor leaves the room
[16:12:53] Lars leaves the room
[16:12:59] tterribe leaves the room
[16:12:59] <dtaht> but it's out of scope.
[16:12:59] <gorryf> Meeting ahs closed
[16:13:01] Pasi Sarolahti leaves the room
[16:13:01] wesley.m.eddy joins the room
[16:13:07] Zahed Sarker leaves the room
[16:13:08] wesley.m.eddy leaves the room
[16:13:38] Jonathan Lennox leaves the room
[16:13:53] dtaht wishes there was an audio tap into the hallway convos
[16:14:05] <gettys> still a research problem....
[16:14:25] <dtaht> not a research problem! send everybody in wired for sound!
[16:14:41] gorryf leaves the room
[16:14:42] Lars joins the room
[16:14:44] <gettys> it's the signal processing to localize the conversations....
[16:14:50] rscheff leaves the room: Computer went to sleep
[16:14:56] Lars leaves the room
[16:15:30] Lars joins the room
[16:15:53] <jesup> dtaht: enough laptops in that room to meld all the soundfields together and spatialize ;-)
[16:16:02] <jesup> just a signal-processing problem
[16:16:14] <dtaht> exactly
[16:16:30] <dtaht> hi lars, long time no see
[16:16:50] Lars leaves the room
[16:21:28] <gettys> jesup: even more fun, you'd have to localize where all the moving laptop/mobile devices are, to localize the sound...
[16:24:22] dtaht leaves the room
[16:47:09] Jonathan Lennox joins the room
[17:02:08] gettys leaves the room
[21:47:20] Andrew McGregor joins the room
[21:52:25] Andrew McGregor leaves the room
[21:56:56] Andrew McGregor joins the room
[21:58:58] Andrew McGregor leaves the room
[21:59:00] Jonathan Lennox leaves the room
[22:03:13] hta joins the room
[22:04:26] Andrew McGregor joins the room
[22:08:04] Andrew McGregor leaves the room: Replaced by new connection
[22:08:56] Andrew McGregor joins the room
[22:14:22] Andrew McGregor leaves the room
[22:19:44] Andrew McGregor joins the room
[22:24:56] Andrew McGregor leaves the room: Replaced by new connection
[22:25:08] Andrew McGregor joins the room
[22:32:13] hta leaves the room
[22:52:36] Pasi Sarolahti joins the room
[22:52:36] jlcJohn leaves the room
[22:52:36] Andrew McGregor leaves the room
[23:05:51] Pasi Sarolahti leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!