IETF
irtf
irtf@jabber.ietf.org
Sunday, 29 July 2012< ^ >
Room Configuration

GMT+0
[00:07:24] Lars joins the room
[00:18:58] Mat Ford leaves the room
[00:24:45] xiaoqing.zhu leaves the room
[00:25:01] Adium leaves the room
[00:27:03] <michael.welzl> re: the last question: we need to only decide on what information is stored in the "flow state exchange", and some facts about this information (how long it's valid, ..)
[00:27:45] <michael.welzl> as for who would work on it, i'm an obvious volunteer :-) i'll get a new ph.d. student in september whom i could fully dedicate to this
[00:28:53] Lars leaves the room
[00:32:20] <billvs> count me in for getting folks tro work on FSE, I can probably get somebody to work on it as well
[00:33:28] <billvs> Do we need to have a statement on additive increase and multiplicitive decrease?
[00:33:56] <michael.welzl> what would that statement be?
[00:34:42] <Stefan Holmer> i don't think aimd needs mentioning. some kind of fairness is more interesting in that case.
[00:34:45] <billvs> that it is a good concept........
[00:35:13] <billvs> Stefan - I did not follow
[00:35:33] <michael.welzl> i agree, no to aimd
[00:35:43] <Stefan Holmer> in my opinion aimd is good because it converges to fairness over time
[00:35:43] Mat Ford joins the room
[00:35:54] <michael.welzl> nah it doesn't
[00:36:02] <michael.welzl> it's a rubbish principle :-) imho
[00:36:13] <JohnLeslie> +1
[00:36:17] <Stefan Holmer> yes, i agree
[00:36:18] <michael.welzl> actually mark showed it - a brooooad range in the graph
[00:36:22] <michael.welzl> depending on the rtt
[00:36:39] <michael.welzl> we made a tool to play with it - see: http://heim.ifi.uio.no/~michawe/research/tools/cavt/index.html [http://heim.ifi.uio.no/~michawe/research/tools/cavt/index.html]
[00:36:46] <billvs> so, you recomend additive increase and additive decrease?
[00:36:55] <michael.welzl> select aimd on both sides, choose various rtt, and try to draw a nice picture with it :-)
[00:37:28] <michael.welzl> i don't recommend any such restriction to congestion control. i recommend convergence
[00:37:33] <Stefan Holmer> but what i'm saying is that it's not necessary to mention, because there are probably other, possibly better ways to reach acceptable fairness
[00:38:02] <Stefan Holmer> @michael.welzl i think we're on the same page...
[00:38:12] <billvs> OK, I was jumping to an implementation for avoiding live-lock.
[00:38:30] <billvs> perhaps a statement on fairness and deterministic avoidence of persistent congestion is in order
[00:39:13] <michael.welzl> yes, but then again i think it's too obvious to even mention. but no problem with that
[00:40:16] <billvs> I will play with the tool, but in my experience there is a tendency for naive implementors to over-drive the system --- look at recent DASH studies for rate adaptation algorithms that oscillate due to poor BW estimation alorithms
[00:40:20] <hta> bill, fairness, deterministic avoidance of persistent connection, motherhood, apple pie, and the universal deployment of IPv6!
[00:40:27] <hta> (getting tired)
[00:40:41] <JohnLeslie> +1
[00:41:01] <billvs> The DASH-like deployments systematically over estimate available BW, and they thrash
[00:41:37] <michael.welzl> but what more can we do than point to rfc2914 for that?
[00:41:38] <keithw> I don't think we have any decentralized algorithm (TCP CC or otherwise) that converges to fairness in the presence of different RTTs, even in the long run.
[00:41:58] <michael.welzl> yesssss! i was hoping you'd ask for it ! HA!
[00:42:06] <michael.welzl> (drum roll) ... my ph.d. thesis!
[00:42:07] <EKR > Here's what I was trying to say: this is a system wit h three basic pieces. (1) A set of signals about the state of the network (2) An algorithm for estimating your sending rate based on those signals. (3) What you do to adjust your sending rate. What's unique about media is (a) the traditional signals don't work well because they give you information too late. (b) the implementaitons don't take sending rate adjustments well © changing the sending rate is complicated because you can't just operate the leaking bucket-type thing
[00:43:05] <michael.welzl> a variant of the logistic equation... new rate = old rate * bottleneck capacity estimate ( 2 - traffic estimate)
[00:43:22] <michael.welzl> as simple as that, always converges, fast and smooth. but does need these estimates
[00:43:44] <billvs> so, you need an algorithm that is biased towards a lower rate, rather than a higher rate - I am not in love with aimd, just the algorithm that comes to mind first
[00:44:53] <JohnLeslie> IMHO, searching for infinite bandwidth for real-time media is wrong...
[00:45:39] <JohnLeslie> (Rather, you want to find a stable bandwidth.)
[00:45:42] <hta> .... it's useless ....
[00:46:26] <JohnLeslie> Harald: yes, but it's still what you want...
[00:46:50] <hta> ... the infinite bandwidth is useless; the stable bandwidth may not be ...
[00:47:09] <JohnLeslie> :-)
[00:47:40] <hta> chat always has these interesting inversions of line order...
[00:51:11] <JohnLeslie> When searching for a stable bandwidth, multiplicative decreas is arguably wrong...
[00:52:35] <Stefan Holmer> maybe, depends a bit on your decrease factor
[00:53:04] <JohnLeslie> true...
[00:53:23] <billvs> Actually, when I think about implementation issues, I realize that the possible codec rates are somewhat quantized - based on the video encoder resolutions, I need to think about this a bit
[00:54:13] mreavy leaves the room
[00:54:30] <keithw> Generally, in my experience the coders already have a pretty smooth bit budget for each frame (which may come from the VBV, two-pass encoding, etc.) So I do not really buy that video bitrates are inherently quantized. But in practice, encoders of course do come with presets, moreso if they're hardware coders.
[00:54:56] Ted Hardie leaves the room
[00:55:09] Mat Ford leaves the room
[00:55:23] <Stefan Holmer> also in a multi-way call you may have one stream encoded at a set of rates
[00:55:26] csp leaves the room
[00:55:59] <Stefan Holmer> which are chosen to fit a set of receivers
[00:56:07] michael.welzl leaves the room
[00:56:13] <Stefan Holmer> in that case you might not be able to adapt the rate of the video streams to each link
[00:56:21] Magnus leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/.
[00:56:27] cheshire leaves the room
[00:56:33] <JohnLeslie> aren't different receivers separate congestion domains?
[00:56:36] hta leaves the room
[00:56:39] Cullen Jennings leaves the room
[00:56:43] g.white leaves the room
[00:56:46] marc.blanchet.qc leaves the room
[00:57:11] EKR leaves the room
[00:57:58] Stefan Holmer leaves the room
[00:58:13] jesup leaves the room
[00:58:13] billvs leaves the room
[00:58:26] tuexen leaves the room
[00:59:43] cabo leaves the room
[01:00:31] coopdanger leaves the room
[01:01:36] simon.perreault leaves the room
[01:02:31] spencerdawkins leaves the room
[01:03:50] EKR joins the room
[01:04:37] bob.briscoe leaves the room: Computer went to sleep
[01:07:35] keithw leaves the room
[01:08:43] tterribe leaves the room
[01:21:17] Stefan Holmer joins the room
[01:21:57] spencerdawkins joins the room
[01:23:34] <Stefan Holmer> @JohnLeslie yes, but from a media gateway point of view that likely means that the possible rates are quantized
[01:23:35] dirk.kutscher leaves the room
[01:24:32] <Stefan Holmer> if you're simply relaying streams
[01:29:31] EKR leaves the room
[01:30:19] JohnLeslie leaves the room: Computer went to sleep
[01:33:01] Stefan Holmer leaves the room
[01:36:25] keithw joins the room
[01:38:59] keithw leaves the room
[01:39:53] EKR joins the room
[01:39:54] EKR leaves the room
[01:40:08] EKR joins the room
[01:59:57] hta joins the room
[02:01:35] hta leaves the room
[02:04:19] EKR leaves the room
[02:49:42] mreavy joins the room
[03:51:23] jesup joins the room
[04:44:11] spencerdawkins leaves the room
[04:46:35] spencerdawkins joins the room
[05:29:48] tterribe joins the room
[05:40:41] EKR joins the room
[06:31:02] EKR leaves the room
[08:08:05] Mark Handley leaves the room
[08:09:17] tterribe leaves the room
[08:51:43] cabo joins the room
[08:51:48] cabo leaves the room
[11:36:32] spencerdawkins leaves the room
[11:40:04] spencerdawkins joins the room
[13:03:47] spencerdawkins leaves the room
[13:04:01] spencerdawkins joins the room
[13:49:07] tterribe joins the room
[14:06:11] mreavy leaves the room
[14:06:11] jesup leaves the room
[14:06:11] tterribe leaves the room
[15:01:02] cabo joins the room
[15:31:32] EKR joins the room
[15:44:15] EKR leaves the room
[16:08:17] dirk.kutscher joins the room
[16:11:58] cabo leaves the room
[16:21:04] dirk.kutscher leaves the room: Computer went to sleep
[16:36:47] tterribe joins the room
[17:07:20] spencerdawkins leaves the room
[17:17:25] spencerdawkins joins the room
[18:16:42] Ted Hardie joins the room
[18:50:19] spencerdawkins leaves the room
[19:00:59] spencerdawkins joins the room
[19:26:50] Ted Hardie leaves the room
[20:47:59] mreavy joins the room
[21:56:50] xiaoqing.zhu joins the room
[21:59:19] xiaoqing.zhu leaves the room
[22:24:07] tterribe leaves the room
[22:28:55] xiaoqing.zhu joins the room
[22:29:00] xiaoqing.zhu leaves the room
[22:31:03] mreavy leaves the room
[22:33:49] mreavy joins the room
[23:04:44] spencerdawkins leaves the room
[23:44:27] xiaoqing.zhu joins the room
[23:46:44] spencerdawkins joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!