[12:02:03] --- LOGGING STARTED
[13:19:38] --- uoa has joined
[15:24:39] --- mattz has joined
[15:24:50] * mattz has changed the subject to: fecframe WG
[15:25:26] --- gorryf has joined
[15:28:26] --- yjs has joined
[15:28:58] --- magnus has joined
[15:29:22] <mattz> matt falls on sword and becomes jabber scribe
[15:29:25] <gorryf> Notetaker for FecFrame minutes: gorry@erg.abdn.ac.uk
[15:29:51] <mattz> I will not parrot slides, but will report discussion and things not on slides
[15:29:56] <mattz> if folks want more detail, let me know
[15:30:07] <mattz> I'm also not in best position to relay to mic, but can try to facilitate that.
[15:30:32] <mattz> OK: first up- David Watson on 3GPP overview
[15:30:39] <mattz> side: 3GPP FEC framework
[15:31:31] <mattz> FEC sender
[15:31:35] <mattz> set of udp flows, 3
[15:31:46] <mattz> form a block of data made up of packets from flows
[15:31:53] <mattz> go by 5 sec periods of time, or 50ms periods of time
[15:31:58] <mattz> all packets arrive in time, protect together as a block
[15:32:19] <mattz> now apply code, and send the blob
[15:32:33] <mattz> send flows in close to original flows as possible
[15:32:50] <mattz> OOB: need to communicate to receiver which flows protected, and how repair symbols relate to flows
[15:33:32] <mattz> extra information on flows, which block packet was put into... where in block.
[15:33:37] <mattz> similarly for repair flow
[15:33:52] <mattz> FEC receiver
[15:33:57] <mattz> red crossed data is lost
[15:34:03] <mattz> form block, using tags
[15:34:15] <mattz> decode to fill in gaps
[15:34:51] <mattz> magnus: send them? to app?
[15:34:51] <mattz> yep
[15:35:22] <mattz> Architecture
[15:36:31] --- sakuma.macx has joined
[15:38:32] <mattz> FEC Streaming ... Information
[15:38:36] <mattz> Source Block Construction
[15:39:56] <mattz> shep: how maintain consistency in mapping? registration?
[15:40:03] <mattz> mapping is local to specific instance of framework
[15:40:27] <mattz> local and dynamic thing
[15:40:33] <mattz> Source Packet Tagging
[15:42:06] <mattz> Source Packet Format
[15:42:22] <mattz> FEC payload at end so ROHC still works
[15:42:26] <mattz> Repair Packets
[15:42:44] <mattz> that's it. questions?
[15:43:01] <mattz> brian adamson, nrl.
[15:43:09] --- uoa has left
[15:43:10] <mattz> is FEC Payload ID, part of cksum of udp header?
[15:43:15] <mattz> how know length of payload?
[15:43:31] <mattz> d: think when sent, whole thing is UDP packet, so UDP cksum would include it
[15:43:43] <mattz> when define what payload IDs are. fec scheme, defines how long they are
[15:43:49] <mattz> q: so always last 8 bytes?
[15:43:51] <mattz> or something
[15:44:02] <mattz> magnus: one comment: what protecting in 3GPP is only udp payload
[15:44:08] <mattz> and in some sense belonging to flow
[15:44:13] <mattz> not IP hdr, UDP hdr
[15:44:17] <mattz> just payload and where it belongs
[15:44:22] <mattz> why FEC on payload and add udp headers
[15:44:39] <mattz> works if operating in midpoint
[15:45:05] <mattz> brian: presume FEC encoding, not across UDP payload, but also across other info, like length of payload
[15:45:08] <mattz> so when decode know how long
[15:45:14] <mattz> yes. that's where idea of source packet info
[15:45:23] <mattz> that gets incoded , even if not tagged
[15:45:34] <mattz> gives flowid length, actual packet, possible padding. length tells you where starts
[15:45:56] <mattz> er: "David" is Mark
[15:46:01] <mattz> Mark Watson
[15:46:11] <mattz> Next up, Mark on "FECFRAME Requirements"
[15:46:17] <mattz> from ml sending, and few comments
[15:46:23] <mattz> start some discussion. need review & commnet
[15:46:29] <mattz> it's a starting point for gen discussion.
[15:46:31] <mattz> Terminology
[15:46:43] <mattz> "too much text". you should have read the draft...
[15:46:56] <mattz> basic terminology that I think we need
[15:48:38] <mattz> almorton: didn't read draft, but... application protocol; why not just call it control protocol
[15:48:44] <mattz> app protocol will confuse folks with source protocol
[15:48:58] <mattz> "not bad for someone that hasn't read the draft"
[15:49:11] <mattz> Requiremetns. numbered for your protection
[15:51:06] <mattz> john snitzline?: second requirement 30 is very challenging to me w/o deep analysis
[15:51:19] <mattz> real time variation in redundancy... unless there is a magic bullet,
[15:51:28] <mattz> curious why that big a challenge. while real time?
[15:51:30] <mattz> why real time?
[15:51:41] <mattz> wouldn't say a big challenge for framework to support that. would work in 3GPP
[15:51:50] <mattz> doesn't tell you how to decide how to vary the mt of protection
[15:52:08] <mattz> but as far as framework is concerned, send some # of repair packets per block. could change per block
[15:52:22] <mattz> could be challenging for some FEC codes
[15:52:32] <mattz> ? : main point regarding this requirement
[15:52:33] <gorryf> who?
[15:52:45] <mattz> amount of fec should be part of transmission, not something fixed in advance
[15:52:46] <magnus> stephan wenger
[15:52:50] <mattz> grazie
[15:52:50] <gorryf> Yes.
[15:53:11] <mattz> call this dynamic, rather than real time
[15:53:26] <mattz> or, here, "merci".
[15:53:33] <mattz> SHALL requirements continued
[15:54:10] <mattz> about 110..
[15:54:17] <mattz> magnus: isn't 110 a requirement for 100?
[15:54:43] <mattz> in order to look higher up in stack
[15:54:54] <mattz> sub req to 100 to list protocols to provide that capability
[15:55:00] <mattz> may be something defer to a particular scheme
[15:55:06] <mattz> magnus: another thought.
[15:55:19] <mattz> UDP... hope you have end to end monitoring, cong control
[15:55:37] <mattz> with DCCP... in some cases might have to protect parts of DCCP in worst case
[15:55:56] <mattz> mark: when presented, was UDP specific. when generalized, should it be multiple protos
[15:56:03] <mattz> maybe don't want to because of this kind of thing
[15:56:28] <mattz> ?: [I lost this question]
[15:56:48] <mattz> meant to say, want to define backwards-compatable systems with this framework
[15:56:54] <mattz> ?: at least some specific system
[15:57:01] <mattz> hard to understand when met unless goal is to define one
[15:57:12] <mattz> only get whole system when combine with fec scheme.
[15:57:27] <mattz> this is requirements on framework. to prove need to give example
[15:57:34] <mattz> ?: not 100% convinced it's a necessary requirement
[15:57:36] <mattz> could get in the way
[15:57:44] <mattz> would seem to preclude some tagging schemes
[15:57:52] <mattz> if FEC scheme defines tagging
[15:57:56] <mattz> (1) could define tag, goes at end
[15:58:04] <mattz> (2) here's some other way to define, given some restrictions
[15:58:12] <mattz> like maybe jus tRTP flows, derive some info from tag
[15:58:19] <mattz> different FEC schemes could have certain properties
[15:58:22] <mattz> some backwards compat, some not
[15:58:36] <mattz> maybe multiple schemes using same underlying ECC, but do differnet things
[15:58:48] <mattz> gorryf: did you mention multicast, or all unicast
[15:58:49] <mattz> both
[15:58:53] <mattz> in charter, says both.
[15:58:56] <mattz> so far agnostic
[15:59:09] <mattz> gorry: what's take on cong control. mention for DCCP, but variable rate... what do in that space
[15:59:15] <mattz> one of the things need to address as part of work
[15:59:29] <mattz> first flippant answer: original flow should have some cong control. FEC adds some %.
[15:59:55] <mattz> gorry: as long as FEC isn't fighting against it by hiding whole effect
[16:00:11] <mattz> ?3: requirement 30 and 70 are quite challenging.
[16:00:19] <mattz> would it be possible to use objects instead of source blocks?
[16:00:27] <mattz> already have dynamic identification of blocks
[16:00:36] <mattz> mark: so use proto like flute?
[16:00:42] <mattz> ?3: independent of protocol.
[16:01:00] <mattz> key challenge is to have everything dynamic. challenging because still using source blocks, can't change src block specs from one to another
[16:01:20] <mattz> instead of src blocks, use "objects", an fti? for object. for that specifiy parameters for amt of data to protect
[16:01:25] <mattz> and fti might be different
[16:01:40] <mattz> not sure about requirements/specifications of use case want to address. but can address some of these requirements
[16:01:44] <mattz> by using objects
[16:01:53] <mattz> mark: in sense blocks are objects.
[16:01:56] <mattz> harder for streaming
[16:01:58] <mattz> RMT
[16:02:16] <mattz> if streaming, info about overall flow, info about individ blocks, info about packets
[16:02:28] <mattz> if describe 3 types in framework, and look at options for 3 types of info
[16:02:34] <mattz> one option, repeat for each block
[16:02:46] <mattz> another option, 3 levels of info
[16:03:05] <mattz> don't want to rely on control protocol to communicate info, esp if 50ms blocks
[16:03:13] <mattz> in 3GPP, info about block is duped in packets
[16:03:22] <mattz> if lose all repair packets, don't need info
[16:03:33] <mattz> ?3: but can also transmit dfti in each packet
[16:03:46] <mattz> magnus: but in most cases are not using X [missed it]
[16:03:58] <mattz> [apologies, this is only an interest area, not an expert area for me...]
[16:04:01] <gorryf> ALC
[16:04:21] <gorryf> [Async Layered Coding from RMT]
[16:04:35] <mattz> running everything over DCCP, framework on top of that is not that difficult, just ...
[16:04:37] <mattz> (thanks!)
[16:04:57] <mattz> will be issues, not difficult. bad case: mixed transport protocols
[16:05:07] --- ldondeti has joined
[16:05:09] <mattz> but probably won't happen.
[16:05:32] <mattz> Should Requirementsw, continued
[16:05:42] <mattz> believe 3GPP should drop out as instance
[16:06:06] <mattz> marshall: also 3GPP2?
[16:06:12] <mattz> 3GPP2 doesn't have anything like this yet
[16:07:02] <mattz> marshall: are you saying that any 3GPP encoding stream, as an IP packet stream, would be legit instance of FECFRAME stream?
[16:07:18] <mattz> not quite. not such a thing as a stream. building a framework.
[16:07:41] <mattz> framework should be built in such a way to build an FEC scheme, that when combined with framework == 3GPP protocol.
[16:07:59] <mattz> : shouldn't intentionally design something that is incompatable with 3GPP way of doing things if have choice
[16:08:18] <mattz> stephan wagner. ... is a desirable goal, and support
[16:08:28] <mattz> marshall: but may not interoperate for any given instantiation
[16:08:34] --- nm has joined
[16:08:40] <mattz> stephan: well 3GPP could dream up all kinds of stuff.
[16:08:50] <mattz> wouldn't fit definition. not talking about that
[16:09:03] <mattz> hard to formulate...
[16:09:11] <mattz> marshall: but this is a framework, looser
[16:09:16] <magnus> s/Wanger/Wenger
[16:09:26] <mattz> mark: i agreee with stephan's formulation.
[16:09:37] <mattz> (matt is not a good speller when operating at high speed. feel free to fix!)
[16:09:46] --- gorryf has left: Replaced by new connection
[16:10:22] <mattz> magnus: in the end, this is about instantiations of framework. wg is tasked to develop signalling necessary to describe instances.
[16:10:26] <mattz> at least for ...
[16:10:41] <mattz> might need to provide sample instances, which might be recommended for certain systems
[16:10:44] <mattz> but that's a later question
[16:11:06] <mattz> stephan, from the corner, "5 years from now..."
[16:11:12] <mattz> Architecture Question
[16:11:34] <mattz> how divide framework from schemes
[16:12:00] <mattz> Construction of source block
[16:12:11] <mattz> issue with 3GPP framework... is an IPR statement against that
[16:12:22] <mattz> so suggestion here, is to avoid that from being the case in future draft
[16:12:55] <mattz> Source Block Example: 3GPP framework
[16:12:59] <mattz> Alternative Proposal
[16:13:08] <mattz> padding and symbols to FEC scheme side
[16:13:50] <mattz> shep: would that break SHOULD of have 3GPP fall out
[16:13:51] <mattz> nope
[16:13:53] --- ldondeti has left: Replaced by new connection
[16:14:09] --- ldondeti has joined
[16:14:20] <mattz> could always pad out to longest...
[16:14:41] <mattz> stephan: opinion... not with nokia hat
[16:15:02] <mattz> as individual, would say I don't particularly like the idea to structure documents around known IPR constraints
[16:15:15] <mattz> reason: known constraint is better than unknown constraint
[16:15:31] <mattz> that said, also... what like least, known IPR constraint that doesn't carry RAND terms
[16:15:43] <mattz> don't have to go into more detail here, I hope. situation that hit RMT not long ago
[16:16:05] <mattz> personal wish, see IPR statement, that contains irrevocable or free or non-??? thing
[16:16:18] <mattz> then would strongly prefer original proposal as was in TSVWG draft over this alternative proposal
[16:16:32] <mattz> mark: IPR statement made, said free.
[16:16:45] <mattz> but there were comments at bof, that basic frameworkd didn't have IPR
[16:16:54] <mattz> didn't follow first point, could always be unknown IPR
[16:17:19] <mattz> stephan: again, no hat, IANAL, etc
[16:17:41] <mattz> realistically, the 3GPP framework is now almost 1.5 yrs old.
[16:18:17] <mattz> those of us with serious commercial interest in that stuff, have studied subject matter in sufficient depth to be w/in companies or individuals requirements for certainty on business front, to be sure of what walking in to
[16:18:55] <mattz> if nail down certain requirements for base, that rule out framework doc use of tech that is pretty well known IPR, and venture into territory where doint' know what's going on, chances are unknown will get us
[16:19:08] <mattz> would challenge idea, similarly safe
[16:19:25] <mattz> realistically thinking about probabilty, safer if stay aligned with common understood ground
[16:19:32] <mattz> why my personal preference toward first proposal
[16:20:04] <mattz> marshall: directed to stephan, feel like binary choice?
[16:20:12] <mattz> erlier proposal was one before dallas
[16:20:15] --- ldondeti has left
[16:20:22] <mattz> stephan: that is a meta-question. don't have a good answer to that
[16:20:34] <mattz> my closest to a good answer is that it is a choice. two proposals presented.
[16:20:58] <mattz> first, keep the way padding handled in framework technology, which has known IPR with published IPR statement which doesn't include irrevocable, but otherwise great
[16:21:17] <mattz> versus we don't do that. we remove that part from whole framework discussion, and lead it to codes later on
[16:21:26] <mattz> in those two choices Mark presented, is binary choice
[16:21:51] <mattz> mark: based on some very reviewd statement in IETF
[16:21:56] --- gorryf has joined
[16:22:10] <mattz> stephan: hunch is that if have choice between that statement, and opening up playground completely
[16:22:14] <mattz> rather do that, and do it now
[16:22:30] <mattz> subject to one concern: if we find a better tech choice, then open up things again
[16:22:44] <mattz> but if no better tech choice, rather have better choice in framework than buried in other doc
[16:22:54] <mattz> magnus: would like to talk about it, but not IPR
[16:23:10] <mattz> how affect useage of already defined FEC schemes in RMT to change split
[16:23:28] <mattz> mark: don't think we can re-use RMT schemes in FECFRAME. they have own context
[16:23:39] <mattz> expect to see new FEC scheme docs that are FECFRAME fec schemes
[16:23:45] <mattz> might be one page long, use RMT with bits and pieces
[16:23:54] <mattz> but direct reuse won't work. not glued together in correct way.
[16:24:07] <mattz> mark: I think that this (althernative) proposal has some tech advantages.
[16:24:20] <mattz> people can dfeine things easier.
[16:24:47] <mattz> marshall: must go to list for final decision. but other opinions here now
[16:24:57] <mattz> seems like a little early to ask for consensus
[16:25:13] <mattz> back to mark: Next Steps
[16:26:32] <mattz> Back to chairs...
[16:26:37] <mattz> Shep wants to address timeframe
[16:27:24] <mattz> if milestones, "free keg of beer and a cake"
[16:28:38] <mattz> next up, Marshall
[16:29:30] <mattz> Proposed SNPTE Standard for FEC for Video over IP
[16:29:51] <mattz> Background
[16:30:49] <mattz> SMPTE Proposal
[16:32:05] <mattz> Single FEC Scheme
[16:32:09] <mattz> RTP packets in sequence
[16:32:26] <mattz> XOR guys in column up to get repair packet
[16:32:42] <mattz> "form of interleave"
[16:32:54] <mattz> even allow you to do it in 2D - Dual FEC Burst Error Correction
[16:33:22] <mattz> What is the Dual FEC mode Structure?
[16:33:41] <mattz> Can we support this as is?
[16:34:00] <mattz> magnus: thnk seen something similar in SMPTE before
[16:34:09] <mattz> modified 2753(?)
[16:34:17] <mattz> has a bitmask, limited # of bits
[16:34:31] <mattz> they have several megabits of video, expansion factor every 50 packets
[16:34:37] <mattz> marshall: yep. table in doc
[16:34:52] <mattz> and don't claim to support 2723
[16:35:05] <mattz> mark watson: background. originally by pro-MPEG forum. private, 20 or so companies
[16:35:11] <mattz> completed thier version a year ago
[16:35:15] <mattz> to video census forum
[16:35:20] <mattz> then handed to SMTPE to publish
[16:35:34] <mattz> based on 2723. but changes headers
[16:35:39] <mattz> as FEC, very computationally efficient
[16:36:05] <mattz> what forum was working on it, was video over IP. very high bitrate streams, and requirements for protection over high-quality well-managed IP nets
[16:36:15] <mattz> in terms of bw uses, and ability to corrrect data, very inefficient
[16:36:19] <mattz> 20% overhead at 10x10
[16:36:27] <mattz> and protection for overhead, is something could get with 5%
[16:36:37] <mattz> but have plenty of bandwidth, and high bitrate scheme appropriate
[16:36:50] <mattz> marshall: obviously 3GPP is different. but in multicast world, see these stremes
[16:37:04] <mattz> mark watson: high bit rate is 20-30 mbps
[16:37:08] <mattz> not 1.54Gbps
[16:37:31] <mattz> gargin?: interesting. questions/clarifications. are repair packets... will they have special protection mechanism?
[16:37:43] <mattz> bottleneck will be if repair packets get dropped, scheme falls apart
[16:37:50] <mattz> any special mechanism, or same probability of drop?
[16:38:04] <mattz> marshall: if in table, fec packet got dropped, not different from data packet dropped
[16:38:12] <mattz> g: dual scheme, add
[16:38:22] <mattz> m: dual scheme is just two interleavings on top of each other
[16:38:39] <mattz> probability of dropping a packet... conditional. drop 0, prob of 1 is higher than random
[16:38:48] <mattz> usu dropping because of queue overflow
[16:39:00] <mattz> shep: and network convergence
[16:39:07] <mattz> almorton: that's minutes. how protect from that
[16:39:20] <mattz> mark: what's important for fec scheme, is not interleaving... it's dealing with sequences of packets lost
[16:39:24] <mattz> interleaving is one technique for that.
[16:39:43] <mattz> if lxd is 10x10, then can recover 10 in seq. but of 10 random drops, no hope
[16:39:54] <mattz> want any 10 recovered. information theoretic ideal
[16:40:02] <mattz> in this scheme, lots of 2 packet drops can't recover from
[16:40:17] <mattz> also 3-4 can't recover, even with 20 repair packts
[16:40:33] <mattz> stefan: hennings 2723 (33 ? ) contains lots of text.
[16:40:44] <mattz> good ways to determine packets to select. interleaving, including 2d interleaving
[16:40:47] <mattz> by no means new.
[16:40:59] <magnus> 2733
[16:41:02] <mattz> as current draft in IETF docs, henning's doc is still place to go.
[16:41:03] <mattz> thanks.
[16:41:20] <mattz> ?5: question on overhead alluded to, esp in 2d model
[16:41:36] <gorryf> (Rajiv Asati???)
[16:41:53] <mattz> marshall: on slide 12 data, 7 repair, so 7/19
[16:41:58] <mattz> if 10x10, 14%.
[16:42:07] <mattz> usu repair/orig, so 20%
[16:42:16] <mattz> ?5: how compare with other FEC schemes
[16:42:23] <mattz> most of schems set to whatever you want
[16:42:51] <mattz> mark: as say, most FEC codes, it's a parameter. this code here, can't chose a percentage, have to choose LxD
[16:42:57] <mattz> 3x4, 40-50%. 10x10, 20%
[16:43:06] <mattz> what need to ask how well do those packets correct errors
[16:43:14] <mattz> if 20 FEC packets, in best case correct 20
[16:43:20] <mattz> and look at what patterns can't recover
[16:43:29] <mattz> different codes do differently.
[16:43:40] <mattz> one my company develop, recover 19 or 18 from 20.
[16:44:00] <mattz> gorry: this is just a parity code really. worst, but easiest to do
[16:44:23] <mattz> ?5: naiive q, but isn't that considered along with failure interval? how many packets protect in some time
[16:44:29] <mattz> if more than any fec schema, lose all benefits.
[16:44:36] <mattz> if have to compensate for time, increase overhead
[16:44:48] <mattz> marhsall: yes. that's precisely why do some of these schemes. loss not random
[16:45:10] <mattz> mark: interleaving is not the right word.
[16:45:24] <mattz> interleaving can be bad thing, reduces perf of code wrt random losses
[16:45:35] <mattz> broken big block to small blocks. moves farther away from random
[16:45:42] <mattz> larger blocks, then losses closer to averages
[16:45:47] <mattz> but then need to buffer, and ....
[16:46:00] <mattz> stepping back, interesting.
[16:46:10] <mattz> read up and understand. but don't need to understand for framework.
[16:46:21] <mattz> thse questions are about how to engineer schemes
[16:46:26] <mattz> with that, call it a day...
[16:47:18] <mattz> magnus: make wg aware that supposed to be AVT to do generic FEC. there is going to be one presentation in AVT wrt FEC
[16:47:26] <mattz> hope authors there will bring here.
[16:47:41] <mattz> want to end up with something better than 2733
[16:48:13] <mattz> marshall: we are leaving before then, hook usup
[16:48:21] <mattz> bye!
[16:48:25] --- mattz has left
[16:57:02] --- magnus has left
[17:00:35] --- gorryf has left
[17:02:21] --- yjs has left: Disconnected.
[17:11:56] --- nm has left
[17:23:15] --- sakuma.macx has left
[17:32:33] --- nm has joined
[17:33:00] --- nm has left: Replaced by new connection
[17:33:00] --- nm has joined
[17:33:00] --- nm has left
[17:37:39] --- yjs has joined
[17:37:39] --- yjs has left: Lost connection