[21:39:52] --- scribe has joined
[21:41:12] --- Ted Faber has joined
[21:41:41] <scribe> scribe is Lars Eggert (lars.eggert@netlab.nec.de)
[21:43:12] --- falk has joined
[21:48:26] --- cgn has joined
[21:50:30] --- tomphelan has joined
[21:50:30] --- tomphelan has left
[21:52:17] --- tomphelan has joined
[21:56:41] <scribe> all slides are at http://www.icir.org/kohler/dccp/ietf59
[21:58:01] <scribe> falk: getting started, this is ddcp wg
[21:58:03] <scribe> dccp
[21:58:50] <scribe> agenda is at http://www.ietf.org/ietf/04mar/dccp.txt
[21:59:01] --- jukkamanner has joined
[21:59:09] --- xexd has joined
[21:59:14] <xexd> HORORAY
[21:59:16] <scribe> falk: very energetic thread on tcp vs. realtime since last mtg
[21:59:26] --- cgn has left: Replaced by new connection
[21:59:29] <scribe> major update of user guides
[21:59:40] <scribe> final polish of spec and ccids
[22:00:06] <scribe> falk: status
[22:00:21] <scribe> falk: spe anc ccids stable, addressed known issues
[22:00:29] <scribe> user guide needs more thought, talk more in a sec
[22:00:46] <scribe> more work: handful of ideas need to be written up
[22:00:58] <scribe> pursue, need to make plan to do that
[22:01:16] <scribe> assuming no showstoppers today, go to last call on spec and ccid after we all go home
[22:01:31] <scribe> user guide needs more input + review, need more input
[22:01:35] --- cgn has joined
[22:02:35] <scribe> falk showing schedule
[22:02:44] <scribe> propose wg last call on spec and ccid in march
[22:02:50] <scribe> rev user guide
[22:02:53] <scribe> rev charter
[22:03:06] <scribe> possible new charter items:
[22:03:11] <scribe> faster start after idle
[22:03:19] <scribe> btw, eddie not here today
[22:03:27] <scribe> ccid3-thin
[22:03:27] <xexd> yes i am
[22:03:47] <scribe> hey, aaron said it :-)
[22:04:22] <scribe> tfrc support for apps w/limited sending rate
[22:04:36] <scribe> 8pkt/rtt initial send rate
[22:04:55] <scribe> tfrc-ps, tsvwg item, then ccid
[22:05:10] <scribe> those were the possible new charter items
[22:05:21] <scribe> anybody got opinions if these are good/bad?
[22:05:32] <scribe> also send to mailing list
[22:05:43] <scribe> no feedback in room
[22:05:54] <scribe> issues need to be better understood
[22:06:12] <scribe> step 1: create a draft, write them down, then decide what work needs to be done
[22:06:31] <scribe> falk is done, questions/comments?
[22:06:39] <scribe> next up: mark handley
[22:06:45] <scribe> talkikng about spec changes
[22:07:20] <scribe> handley: eddie not here, will need to get by with him
[22:07:37] <scribe> spec looks more different than it is
[22:07:46] <scribe> lot of effort to present things better
[22:08:08] --- mattz has joined
[22:08:22] <scribe> basically 3 main tech updates: event processing, simplifications discussed in minneaplois
[22:08:31] <scribe> and changes mentioned on wg email list
[22:08:38] <scribe> org changes:
[22:08:54] <scribe> rewrote initial material, reorg text
[22:09:30] <scribe> changed option names, semantics mostly the same
[22:09:36] <scribe> better examples
[22:09:47] <scribe> state transition diagram rewritten
[22:10:01] <scribe> it's not normative, just to give a better picture
[22:10:13] <scribe> handely shows state diagram
[22:10:30] <scribe> real edition: part-open state is new
[22:10:33] <xexd> you're not gonna type it in? ;)
[22:10:43] <scribe> event processing not really pinned down previously
[22:10:52] <scribe> was clear needed to pin down loose ends
[22:11:08] <scribe> eddie made it similar to tcp state
[22:11:22] <scribe> EXPLAINED it similar to the tcpo state diagram
[22:11:59] <scribe> fixed deadlock based on formal model
[22:12:23] <scribe> scribe doesn't know enough about dccp to summarize the change quickly, sorry
[22:12:52] <scribe> handely shows processing pseudo code
[22:13:49] <scribe> state machine was checked by mark and eddie
[22:13:55] <scribe> 2 different approaches, believed to be correct
[22:14:17] <scribe> sequence number validity
[22:14:26] <scribe> rewritten some rules
[22:14:35] <scribe> much cleaner + more likely to be correct
[22:14:52] <scribe> change is related to dccp-sync
[22:15:55] <scribe> added section about seqno-guessing based attacks
[22:16:21] <scribe> suggests extended seqno functionality when window > 100
[22:16:29] <scribe> tcp has same problem
[22:16:36] <scribe> no clean solution for tcp
[22:16:59] <scribe> tcp does not have same option of using ext seqno that dccp has
[22:17:50] <scribe> handley shows rules for seqno validity
[22:17:56] <scribe> as an example
[22:18:11] <scribe> forward compatibility
[22:18:23] <scribe> how to cope with dccp evolving
[22:18:26] <scribe> rethink approach
[22:18:32] <scribe> not many changes to the spec
[22:18:35] <scribe> new section
[22:18:51] <scribe> use feature to negotiate that you can do extension
[22:19:02] <scribe> don't reset odd options
[22:19:18] <scribe> "ignored" option now gone
[22:19:35] <scribe> some existing feature were rewritten to conform to own rules
[22:19:41] <scribe> seqno transistion
[22:19:45] <scribe> check data cksum
[22:20:05] <scribe> reserve some options for experimental use
[22:20:14] <scribe> feature negotiation
[22:20:48] <scribe> state diagram had "failed" state, is not needed
[22:20:50] <scribe> also gone
[22:20:59] <scribe> update on open issues
[22:21:05] <scribe> #ndp removed
[22:21:09] --- galvinjamesm has joined
[22:21:23] <scribe> use "ndp count" option
[22:21:43] <scribe> frees up 3 bits in header -> reserved now -> good for the future
[22:21:46] --- arifumi has joined
[22:21:58] <scribe> add dccp-sync and sync-ack
[22:22:16] <scribe> what if receiver is not keeping up with sender? cong at receive host
[22:22:22] <scribe> option "data dropped"
[22:22:36] <scribe> clarify what sender needs to do
[22:22:45] <scribe> question from audience
[22:22:52] <scribe> most data drop not cong related
[22:23:02] --- galvinjamesm has left
[22:23:08] <scribe> seems wrong to say you should alwas shrink window
[22:23:12] <falk> [Magnus] is questioner
[22:23:12] <scribe> mark:
[22:23:15] <scribe> not doing anything not goog
[22:23:20] <scribe> good
[22:23:33] <scribe> spec now: pretty gentle way,
[22:23:36] <scribe> gently slows down
[22:23:43] <scribe> Q: why valid for corruption?
[22:23:48] <scribe> mark: that's not the point
[22:24:02] <xexd> A: draft explicitly says it doesn't apply to corruption (yet)
[22:24:20] <scribe> sally: believe text says "drop in receive buffer" don't want to send faster if they are alll dropped
[22:24:45] <scribe> (sally is rtalking to fast)
[22:24:57] <xexd> (she often does!)
[22:25:16] <scribe> [mark] mechanism uses network bw at bottleneck
[22:25:32] <scribe> [mark] felt we needed to do something
[22:25:39] <scribe> Q: spec can be clearer
[22:26:12] <falk> [Magnus] spec can identify different behaviors for different drop codes
[22:26:32] <scribe> [sally] corruption may not have anythign to do with corruption
[22:26:32] <xexd> Spec currently says different behaviors for all drop codes
[22:26:42] <xexd> 0, 1 = do nothing to fair rate
[22:26:51] <xexd> 2 [receive buffer drop] = drop rate by 1 p/RTT
[22:26:59] <xexd> 3-7 [others, incl corruption] = treat as ECN mark
[22:27:47] <scribe> scribe can't sum up the discussion way to to lack of dccp context
[22:27:50] <scribe> sorry
[22:27:59] <xexd> scribe is doing an awesome job anyway, thanks!
[22:28:22] <scribe> [handley] there is now reasonable text
[22:28:23] <falk> Let's followup online with magnus & Colin (who had a comment I missed)
[22:28:31] <xexd> ok
[22:28:46] <scribe> aaron, will you speak eddie's comments when needed?
[22:28:53] <scribe> or should i?
[22:28:56] <falk> I will
[22:28:58] <scribe> ok
[22:29:24] <scribe> after debate last time, payload cksum should be stronger
[22:29:28] <scribe> use same as sctp
[22:29:43] <scribe> have option do use strong cksum for all data
[22:29:49] <falk> [Colin Perkins]
[22:29:52] <scribe> Q: understand reasons, concern bw overhead
[22:30:02] <scribe> A: don't have to use
[22:30:09] <scribe> Q: wireles links scarce bw
[22:30:12] <xexd> BANDWIDTH overhead? it's optional, and only 4 bytes
[22:30:20] <xexd> with option overhead, 6 bytes total
[22:30:34] <scribe> [mark] is possibility
[22:30:42] <scribe> [colin] may need 2 cksums
[22:30:50] <scribe> [colin] not sure, is concern
[22:31:13] <xexd> sure -- payload checksum is *not required* though, even if you use low Checksum Coverage
[22:31:15] <scribe> [falk] reading eddies comments
[22:31:29] <falk> eddie: 8bytes w/padding?
[22:31:33] <scribe> [colin] double overhead compared to inet cksum
[22:31:44] <scribe> [colin] may have missed that when reading the spec
[22:31:49] <xexd> yes, 8b w/padding (unless you can fit other stuff in there)
[22:32:05] <scribe> [colin] maybe not a problem, need to be careful
[22:32:07] <xexd> minimum would be 4B extra
[22:32:17] <xexd> understand need to be careful but it's a truly optional option :)
[22:32:19] <scribe> [mark] can't sort out all issues before we get deployment exp
[22:32:28] <scribe> [mark] may revise based on exp
[22:32:38] <falk> [Tom Phelan]
[22:32:43] <scribe> [tom falon]
[22:32:57] <scribe> Q: really looking for diff strengths of protection
[22:33:08] <scribe> Q: stronger was useful thiing to have
[22:33:15] <scribe> [mark] number of ways to use same functionality
[22:33:28] <scribe> [mark] would want to have cheapest cksum for some cases
[22:33:41] <scribe> [mark] would want stronger for others
[22:33:54] <scribe> [mark] is useful if link doesn't do strong crc
[22:33:57] <xexd> the idea behind Payload Checksum is that it is a just-as-storng replacement for the strong checksums that Internet protocols expect links to have
[22:33:59] <scribe> [mark] stronger makes sense
[22:34:22] --- floyd has joined
[22:34:26] <scribe> [tom] if one, should be stronger
[22:34:38] <scribe> [mark] issue brought up by bellovin
[22:34:44] <scribe> [mark] service code wildcard
[22:34:56] <scribe> [mark] what service being used by dccp connection
[22:35:12] <scribe> [mark] turns out wildacrds confuse the issue
[22:35:30] <scribe> [mark] can't think of scenario where wildcards are useful
[22:35:39] <scribe> [mark] security aspects negative
[22:35:44] <scribe> [mark] remove wildacrds now
[22:36:03] <scribe> [falk] what is given up?
[22:36:07] <scribe> [mark] nothing useful
[22:36:25] <scribe> [mark] ability to listen on port w/o specifying service name
[22:36:36] <scribe> [mark] how do you get service code?
[22:36:55] <xexd> Note:
[22:36:56] <scribe> [mark] not much loss of flexibility
[22:37:10] <scribe> [mark] but: service code is easy to get
[22:37:18] <scribe> [mark] not a significant issue
[22:37:35] <xexd> The document allows you to use private service codes, or even service code 0 ("the absence of a meaningful service code")
[22:37:37] <scribe> [falk] if client wants to talk any out of a number of services?
[22:37:39] <xexd> just can't wildcard
[22:37:49] <scribe> [mark] can get out of band
[22:37:59] <scribe> [mark] same as other
[22:38:06] <scribe> [tom phelan]
[22:38:07] <xexd> Also, Steve pointed out that this is not the case in practice!
[22:38:23] <xexd> Always have SERVERS that can talk multiple protocols, client knows what protocol it's talking to
[22:38:24] <scribe> have to chose port number anyway
[22:38:36] <xexd> at most it fails over from one service to another
[22:38:42] <scribe> [mark] doesn't seem to loose us anything
[22:39:02] <scribe> [falk] reading eddies comments
[22:39:14] <scribe> [colin] what does this buy us?
[22:39:30] <scribe> [colin] 1st thing vendors will do is mux on same port
[22:39:41] <scribe> [colin] unclear what this buys us
[22:39:51] <falk> [colin] muxing RTP and RTCP
[22:39:53] <xexd> middleboxes can make decisions based on real service codes
[22:39:54] <scribe> [mark] makes much more implicit the purpose of connection
[22:40:07] <xexd> can never have a situation where middlebox approved a request using service code A
[22:40:13] <scribe> [mark] allows fine detailed description of what is transferred
[22:40:18] <xexd> but the server actually was wildcarded, and providing service EVIL
[22:40:32] <scribe> [mark] port space doesn't dustinguish well-known ports from others
[22:40:34] <scribe> [mark] not enough ports
[22:40:42] <scribe> [mark] for fine-grained registration
[22:40:53] <scribe> [mark] don't want to put large numbers into pkts
[22:41:07] --- memo56 has joined
[22:41:18] <scribe> [colin] understand. seems reasonable. use service code to get through fiewalls?
[22:41:30] <scribe> [mark] code only used during setup
[22:41:40] <falk> [colin] concerned about people lying about service codes to get through firewalls
[22:41:49] <scribe> [colin] service code is obvious hook vs. there isn't one normally
[22:41:57] <scribe> [mark] doesn't seem to
[22:42:13] <scribe> [mark] can't disntinguish ongoing conn beyond that
[22:42:22] <scribe> [colin] can look at service code
[22:42:32] <scribe> [colin] is horrible, but can see people doiong it
[22:42:42] <scribe> [mark] port is not important
[22:42:51] <scribe> [mark] fine to have many things on same server port
[22:43:13] <scribe> [colin] makes firewall implement harder
[22:43:21] <xexd> that's not clear
[22:43:28] <xexd> firewall can decide based on port
[22:43:31] <xexd> if it likes
[22:43:33] <scribe> [mark] easier: can specify rules they want rather than rough estimate of what they want
[22:43:46] <xexd> same security properties as current firewalls (b/c of lack of wildcarding)
[22:43:50] <xexd> or
[22:44:01] <scribe> [colin] doesn't help with security
[22:44:14] <xexd> firewall can additionally use service codes to discriminate
[22:44:26] <xexd> It doesn't add security, colin is right
[22:44:27] <scribe> [colin] what do we gain wrt security, wrt to complicating security due to muxing?
[22:44:30] <scribe> [mark] talk afterwards
[22:44:39] <scribe> presentation resumes
[22:44:42] <xexd> but it lets firewalls allow connections through more flexibility
[22:44:51] <scribe> [mark] all on changes to spec and ccids
[22:44:59] <scribe> [mark] trivial changes since current draft came out
[22:45:07] <scribe> [mark] do minor rounf of edits, then last call
[22:45:08] <falk> [James Kempf]
[22:45:18] <scribe> [?] what about mobility support in dccp?
[22:45:38] <scribe> [kempf] ID/locator separation, looks like many other proposals
[22:46:01] <scribe> [mark] timing is poor, don't know what is going on elsewhere
[22:46:15] <scribe> [mark] hope is mechanism is lightweight, minimum you may need
[22:46:29] <scribe> [mark] doesn't get in the way, can always be deprecated if something better comes along
[22:46:43] <falk> [Magnus Westerlund]
[22:46:52] <scribe> [markus festlan] huges security hole
[22:47:00] <scribe> [magnus] sniffing
[22:47:01] <xexd> ?
[22:47:15] <scribe> [magnus] steal connection
[22:47:19] <xexd> what, mobility?
[22:47:20] <scribe> [mark] use IPsec
[22:47:29] <xexd> also, see probabilities in paper
[22:47:37] <xexd> risk very small for well-chosen 128-bit ids
[22:47:47] <scribe> [falk] objective: be comparable to tcp
[22:47:55] <scribe> [falk] that's what we have
[22:48:00] <xexd> risk is 0 for non-mobility-capable
[22:48:13] <scribe> [magnus] has security holes, can extend dccp,
[22:48:20] <scribe> [mark] hard to do an extension
[22:48:43] <scribe> [falk] reading eddies comments
[22:49:01] <scribe> Q: similar to mobile IP binding update
[22:49:09] <scribe> Q: return routability
[22:49:29] <xexd> "For a server with 10^6 mobility capable conns, and an attakcer that guesses 10^9 random mobility IDs, probability of getting ONE success is 10^-23"
[22:49:35] <scribe> Q: can this be used to DoS an innocent 3rd party?
[22:49:54] <scribe> [mark] is you observe nonce xchange, can do lots of other bad things
[22:50:14] <falk> [Anders Clements?]
[22:50:15] <scribe> [anders clements] any thoughts on how to cross NATs?
[22:50:21] <scribe> [mark] lot of tiome spent
[22:50:31] <scribe> [mark] intended as long-term solution
[22:50:39] <scribe> [anders] tunnel dccp over udp?
[22:50:42] <scribe> [mark] not considered
[22:50:50] <scribe> [anders] crazy idea?
[22:50:52] <scribe> [mark] yes
[22:51:12] <scribe> [colin] is yoou are malicious, do conn to yourself, observe and redirect it
[22:51:23] <scribe> [mark] need to think about that
[22:51:27] <scribe> [mark] not now
[22:51:39] <scribe> [mark] future work
[22:51:54] <scribe> [mark] fast recovery after idle
[22:52:04] <scribe> [mark] tfrc for apps such as audio
[22:52:08] <scribe> [mark] pps constant
[22:52:22] <scribe> change data rate = change conpression
[22:52:29] <scribe> know we need research
[22:53:07] <scribe> may need to breate ccid for that
[22:53:21] <scribe> final open issue prob trickiest
[22:53:35] <scribe> spcs assume cong control rate is rate of data receipt
[22:53:43] <scribe> dccp clocks pkts ouot
[22:53:46] <scribe> other ways to do it
[22:53:54] <scribe> problem is fixed data rate apps
[22:54:05] <scribe> apps that have small # of discrete fixed rates
[22:54:14] <scribe> apps that change codecs
[22:54:26] <scribe> don't fit well with existing cong control mechanisms
[22:54:40] <scribe> transmit at reference rate
[22:54:46] <scribe> factor 2 is OK
[22:54:54] <scribe> use ddcp not as clock but as policer
[22:55:01] <scribe> apps get hints about xmit rate
[22:55:06] <scribe> dccp ends up just policing
[22:55:22] <scribe> pretty sure this works if muxing level is high
[22:55:30] <scribe> not sure if it works if muxing is low
[22:55:44] <scribe> where are the bad cases?
[22:55:55] <scribe> unlikely to be bad for network, but may not support some flows
[22:56:04] <scribe> probably is req for soma apps
[22:56:09] <scribe> put on list of future research
[22:56:18] <scribe> [mark] think that's all
[22:56:22] <scribe> [mark] q?
[22:56:36] <scribe> [magnus?] about seqno
[22:56:48] <scribe> [magnus] how useful to transistion seqno?
[22:56:54] <scribe> [mark] fair amount of debate
[22:57:00] <scribe> [mark] much simpler is stick with one
[22:57:10] <scribe> [mark] problem: flow has no clue about rate
[22:57:21] <scribe> [mark] window grows large
[22:57:30] <scribe> [mark] maybe transistion to diff set of seqno
[22:57:49] --- memo56 has left
[22:57:49] <scribe> [mark] not happy with current mechanism, but no better way
[22:58:25] <scribe> [sally] report on issues from mailing list
[22:58:30] <scribe> [sally] eddie would be doing this
[22:58:36] <scribe> [sally] he's not here
[22:58:40] <xexd> whine, whine, whine :)
[22:58:50] <scribe> [sally] shows quotes
[22:59:02] <scribe> [sally] reading slides
[22:59:14] <scribe> [sally] slide "quotes from the mailing list"
[22:59:28] <scribe> [sally] try to use neutral tone of voice, not working :-)
[22:59:40] <scribe> [sally] 1st our background assumptions
[23:00:03] <scribe> [sally] dccp with best-effort doesn't meet needs of all apps
[23:00:10] <scribe> [sally] neither does best effort
[23:00:18] <scribe> [sally] dccp solves best effort, not qos
[23:00:36] <scribe> [sally] dccp offers better perf to apps in long run
[23:00:53] <scribe> [sally] one issue: why udp flows bothered with fairness?
[23:01:05] <scribe> [sally] rfc2914
[23:01:11] <scribe> [sally] prevent cong collapse
[23:01:15] <scribe> [sally] fair sharing
[23:01:32] <scribe> [sally] bcp of ietf
[23:01:41] <scribe> [sally] ietf doesn't control inet
[23:01:53] <scribe> [sally] ietf controls standards in ietf
[23:02:06] <scribe> [sally] won't standardize protocols if it doesn't conform
[23:02:15] <scribe> [sally] harder issues
[23:02:18] <scribe> [sally] slow start
[23:02:32] <scribe> [sally] cbr doesn't want to slowstart
[23:02:48] <scribe> [sally] this is eddies rephrasing, not direct quotes
[23:03:04] <scribe> [sally] reading the slide
[23:03:14] <scribe> [sally] difficult issue
[23:03:28] <scribe> [sally] ccid3 spec says 4pkts/rtt
[23:03:34] <scribe> [sally] investigate 8
[23:03:50] <scribe> [sally] further investigation, needs a little work
[23:04:00] <scribe> [sally] history: sally did tcp initial window increase
[23:04:10] <scribe> [sally] was a lesson
[23:04:14] <scribe> [sally] much work
[23:04:41] <scribe> [sally] means that dccp will drop 1st few pkts of high-rate flows
[23:04:55] <scribe> [sally] what to do?
[23:05:05] <scribe> [sally] personal view: explicit feedback is needed from routers
[23:05:22] <scribe> [sally] draft-amit-quick-start-02.txt
[23:06:17] <scribe> [sally] issue: limit of at most 2x send rate
[23:06:37] <scribe> [sally] tfrc isn't penalized by tcp
[23:06:56] <scribe> [sally] don't improve chances by xmit faster
[23:07:05] <scribe> [sally] limit is loss rate
[23:07:24] <scribe> [sally] limit remains
[23:07:33] <scribe> [sally] different from what apps would like
[23:07:45] <scribe> [sally] spec now: can't ever send >2x as received
[23:07:57] <scribe> [sally] when can this be safely relaxed?
[23:08:05] <scribe> [sally] investigate
[23:08:16] <scribe> [sally] issue: slowstart after idle
[23:08:31] <scribe> [sally] apps want different thing than dccp offers
[23:08:55] <scribe> [sally] personal view: makes sense to go faster after idle, know more than at first start
[23:09:21] <scribe> [sally] may start at 8pkts/rtt rather than 4
[23:09:27] <scribe> [sally] can 4x rather than 2x
[23:09:40] <scribe> [sally] proposal in spec, not in spec
[23:10:23] <scribe> [sally] last issue: what if cbr app or small number of cbr rates
[23:10:31] <scribe> [sally] or app that can downshift but not up
[23:10:43] <scribe> [sally] can be used with cbr apps
[23:10:55] <scribe> [sally] modulo issues raised
[23:11:41] <scribe> [sally] proposal: dccp send 2x send rate of tfrc eq?
[23:11:46] <scribe> [sally] needs further work
[23:11:55] <scribe> [wolfgang beck]
[23:12:09] <scribe> solution: sip has mechanism to include rsvp
[23:12:25] <scribe> have implemented sip with probing phase
[23:12:32] <scribe> dccp signals reference rate
[23:12:39] <scribe> then go on with signalling
[23:12:44] <scribe> would be solution for initial SS
[23:12:54] <scribe> initial SS as kind of reservation?
[23:13:10] <scribe> [sally] use padded slow start?
[23:13:16] <scribe> [sally] seems viable
[23:13:33] <scribe> ¢falk] can implement w/o sip or rsvp
[23:13:50] <scribe> [mark] can use dccp sync
[23:14:12] <scribe> [sally] maybe problem with SS small pkts, then real data w large pkts
[23:14:19] <scribe> [?]
[23:14:25] <scribe> [magnus]
[23:14:36] <scribe> are there poss padding ack pkt?
[23:14:45] <scribe> [sally] yes
[23:14:53] <scribe> [magnus] pad to app siye
[23:14:58] <scribe> [sally] agree
[23:15:27] --- tomphelan has left: Disconnected.
[23:16:29] <scribe> next: tom phelan
[23:16:51] <scribe> [tom] different from prev one
[23:16:55] <scribe> [tom]user guide
[23:17:02] <scribe> [tom] focuses on apps
[23:17:11] <scribe> [tom] user = app (interpretation)
[23:17:31] <scribe> [tom] what apps are candidate users? which ccid?
[23:17:54] <scribe> [tom] app stories, gaming
[23:18:11] <scribe> [tom] useful features of dccp "stupid dccp tricks"
[23:18:20] <scribe> [tom] security considerations
[23:18:39] <scribe> [tom] personal view on issues in guide:
[23:18:48] <scribe> [tom] may be controversial
[23:18:57] <scribe> [tom] guide assumes fast restart
[23:19:10] <scribe> [tom] training period in strategy 3
[23:19:26] <scribe> [tom] ramp up rate during training period
[23:19:32] --- mjh has joined
[23:19:35] <scribe> [tom] until it resembles intended traffic
[23:19:44] <scribe> [tom] not sure training things work well
[23:20:14] <scribe> ¢falk] fast restart needs more research, may not go in to ccid spec later in new doc
[23:20:27] <scribe> [tom] switch streams
[23:20:30] <falk> s/may not/will not/
[23:20:32] --- xexd has left: Disconnected
[23:20:50] <scribe> [tom] is this practical?
[23:20:57] <scribe> [tom] lots of discussion
[23:21:04] <scribe> [tom] 2 very different opinions
[23:21:05] --- xexd has joined
[23:21:12] <scribe> [tom] see what result will be
[23:21:15] <scribe> [tom] issue: video apps
[23:21:24] <scribe> [tom] rate changes frame-to-frame
[23:21:33] <scribe> [tom] 10x variation frame-to-frame
[23:21:39] <scribe> [tom] difficult
[23:21:49] <scribe> [falk] q: these can be smoothed out?
[23:22:07] <scribe> [tom] need one frame to send it for interactive
[23:22:24] <scribe> [falk] not startup, mean variation
[23:22:58] <scribe> [sally] assumption, tell me if wrong.
[23:23:16] <scribe> user that use rt medie would use best effort + pay extra delay, use delay for smoothing
[23:23:24] <scribe> plp that don't want delay would pay for it
[23:23:27] <scribe> [tom] true
[23:23:35] <scribe> [tom] 10x variation will still mean problem
[23:23:46] <scribe> [magnus] use matrix on video to avoid
[23:24:11] <scribe> [tom] there are things to do with codecs so they adapt well
[23:24:19] <scribe> [tom] today's codecs on dccp may not work well
[23:24:35] <scribe> [mark] 2 types of codecs h261 h263
[23:25:06] <scribe> [mark] send close to cbr in absence of drastic content changes, others have different frame sizes (mpeg4)
[23:25:14] <scribe> latter not intended for interative use
[23:25:26] <scribe> maybe talking about mismatch between codec and app?
[23:25:43] <scribe> [falk] content IS changing
[23:25:59] <scribe> [mark] need to quantize if content changes much
[23:26:15] <scribe> for constant quality need variable rate
[23:26:26] <scribe> [tom] that echoes statement in user guide
[23:26:54] <scribe> [tom] some codecs adapt better than others to dccp
[23:27:08] <scribe> [mark] want interactive, must have codec that spreads out changes
[23:27:21] <scribe> codec produces bit rate that is smoother
[23:27:31] <xexd> it depends how much worse the fast rate is, right?
[23:27:34] <scribe> dccp equally good as long as forward buffering
[23:27:46] <xexd> if the slow rate is 1/2 the fair rate, and the fast rate is 2x the slow rate, all is well
[23:28:01] <scribe> [tom] there are better codec choices than others
[23:28:04] <xexd> if slow rate is 1/4 the fair rate, and fast rate is 4x the slow rate, and we have faster start, all is well
[23:28:18] <scribe> [tom] next suggestion: stream padding
[23:28:35] <scribe> [tom] now says: pad below max rate
[23:28:43] <scribe> [tom] gets around problem to know when to jump up
[23:28:53] <scribe> [tom] penalty for changing rates
[23:29:05] <scribe> [tom] problem when you experiment with changing up
[23:29:13] <scribe> [tom] padding makes better transisiotn
[23:29:13] --- cgn has left: Disconnected
[23:29:30] <scribe> [tom] need simulations within tfrc with self-limiting sources
[23:29:47] <scribe> [tom] games: restart after idle? assume they can blast
[23:30:00] <scribe> [tom] will be difficult to adjust to mindset of SS
[23:30:33] <scribe> [falk] q: sense as to whether game people use rtp or dccp?
[23:30:37] <scribe> [tom] udp
[23:30:40] <scribe> [tom] not rtp
[23:31:00] <scribe> [tom] question: know more apps we can profile? send email
[23:31:11] <scribe> [tom] stupid dccp tricks:
[23:31:16] <scribe> [tom] not certain if works
[23:31:33] <scribe> [tom] pmtud with dccp sync sizes (courtesy of eddie)
[23:31:44] <scribe> [tom] partial reliability
[23:32:00] <scribe> [tom] app level sequencing
[23:32:18] <scribe> slow receiver option
[23:32:23] <scribe> ndp option
[23:32:33] <scribe> assumption that api makes available certain info
[23:32:39] <scribe> but is not explicit about it
[23:32:41] <scribe> [tom] q?
[23:32:49] <scribe> [?]
[23:32:58] <scribe> Q: does dccp work for streamin gmedia?
[23:33:06] <scribe> [tom] reasonably well for 1way media
[23:33:14] <scribe> q: non-interactive?
[23:33:16] <scribe> [tom] yes
[23:33:19] <falk> [Anders Clements]
[23:33:31] <scribe> [tom] for 2way people's minds have to change
[23:33:51] <scribe> [?colin] agree, and guide seems much more useful than earlier version
[23:34:05] <scribe> [falk] need input from gaming. anyone here?
[23:34:19] <scribe> [falk] end of agenda. q?
[23:34:30] <falk> eddie: we're finishing up
[23:34:30] <Ted Faber> Eddie??
[23:34:34] <falk> anything to say?
[23:34:40] <xexd> not really
[23:34:43] <xexd> i had hoped i suppose
[23:34:46] <falk> ok
[23:34:50] <scribe> [mark] check over IDs that go to last call
[23:34:51] <xexd> for feedback on what will happen during wglc
[23:34:59] <xexd> and more feedback on next items on the charter
[23:35:24] <xexd> i intend to rev right after ietf
[23:35:29] <scribe> [colin] any implementation of this version?
[23:35:39] <scribe> [falk] one over the summer
[23:35:40] <xexd> of this exact version no
[23:35:48] <scribe> [falk] unclear how closely impl track spec
[23:35:58] <scribe> [falk] not much input from impl after they starts
[23:36:07] <scribe> [mark] not aware of any that match current spec
[23:36:20] <scribe> [colin] would feel more comfortable if we had impl
[23:36:47] <scribe> [falk] q?
[23:36:48] <xexd> fair comment, but we have had extensive implementations
[23:36:52] <scribe> [falk] go get cookies!
[23:36:53] --- jukkamanner has left: Disconnected
[23:36:56] --- floyd has left
[23:36:56] <xexd> that's why the spec is the way it is!
[23:37:48] --- Ted Faber has left
[23:41:22] --- arifumi has left
[23:42:33] --- mattz has left
[23:42:48] <xexd> want to thank scribe a ton!!!
[23:43:43] --- falk has left: Disconnected
[23:48:09] --- xexd has left
[23:49:54] --- scribe has left: Disconnected