IETF67 FECFrame Minutes Greg Shepherd, Marshal Eubanks WG chairs. Mark Watson prsenting requirements draft update: draft-fecframe-req-01.txt - Add motivation section - RMT FEC not good enough because: - repeated FEC Object Transmission Information - different recommendations for parameters - formatting of stream data (eg: not transfer file with start and end, but stream - live without necessary start/end, limited delay). - Proposal: - FEC framework peer to RMT FEC building block - FEC scheemes in FEC-F may be different than those in RMT FEC BB Greg asking for example -> FEC Framework for streaming content (low latency) instead of object(file) as RMT specs assume. break data in block, but in stream case one need different procedures. Steve Botzko: Q; only FEC schemes doing erasure correction in scope. Why? Eg: Why not bitlayer correction. A (Mark): Only UDP included as transport means no bit-errors possible but just packet loss. No need for bit-error correction. A (Unidentified1): Only goal of group protection aganst packet loss. A (Unidentified2): Other working groups are trying to provide better protection of UDP data beyond UDP checksum. A (Stefan Wegner/Nokia): Not interested in bit error correction. A (Colin) DCCP and UDP lite allow bit-errors to happen. A (Marshal): What is beyond erasure correction: A (Unidentified1): Bit error correction in packet. Q(Unidentified1): What is an FEC scheme: a) Describing of encoding b) how encoding is adapted to transport (UDP or RTP) today "scheme" meant to imply both. Maybe better to better differentiate between those two tasks. Not sure if document separation necessary for this. A(Mark): Yes, may need to structure documents into these two sections. Want to start out with "just" FEC scheme in drafts so different drafts can include heir own mechanism for both components. But reuse of common components definitely possible/wanted. Q(Toerless): What type of packet loss (low stochastic, big-burst) in scope of requirement A(Mark): All type of losses in scope, applicability of individual proposals for FECs may only work for certain type of losses. Q(Marshal) Ask whether it should be taken to last call. Q(Colin) There seem to be things to do, do last call only after they are done. A(Unidentified2): Do not do working group last call rightnow at all. Q(shep): So we can refine requirements when we learn more through the actual solution drafts ? A(Unidentified): Yes. - May want to do freeze call. Mark Watson presenting framework draft: draft-watson-fecframe-framework-00.txt - Based on original draft based on proposal made a few IETF ago in transport area. WHich was based on work done for 3GPP. - FEC streaming framework between application protos (RTP, RTCP, MIKEY,..) and Transport, Eg: UDP. FEC-framework has as module the FEC Scheme. - Application sitting on top of application protocol has API into controlling FEC streaming framework. - define which flows are to be protected. Define flows to carry protection data. - functionality of FEC streaming framework: - allocate packets to source blocks - construct and send source and repair packets - FEC scheme part: - encoding and decoding of FEC data. - Defines and interprets FEC signaling elements. - Outline whats in the draft (see slide) ... - includes possibility of unmodified sourcepackets to suppot fully backeward compatible FEC scheme. Q(Marschall): MAY ? -A(Mark): Yes. - Congestion control requirements - Comparison to 3GPP: 3GPP fixed length symbol approach FEC-proposal: source blocksare sequence of tuples of flowid, length, data (eg: variable lengths) Q(Marshall): - In flute you could send any type of dsta. Are yo constrained in this scheme or could you send anything that goes on top of transport lyer (eg: UDP). A(Mark): - Yes. No assumption against transport layer protocols Q(Toerless) - Keep original Data completely unmodified ? A(Mark): - If original data is left completely unchanged, FEC scheme needs to be specific to application layer (eg: RTP) - eg: rely on referring to RTP sequence numbers in rpair stream. If original data is modified (tagged), then FEC scheme can be agnostic of application protocol. Q(Toerless) - Separation of original flow from FEC ? A(Mark): - Yes, part of the transport layer definition. Data stream and repair stream: Use different ports and/or use different network layer addresses. Q(steve ?bansberg?): - How to manage transport addresses ? A(Magnus): - Explanation of how this works... didn't understand - ask Magnus (I can't remember what I said. I guess that this has to do with using a session protocol to tell which addresses and ports are used.) A(Mark): - startng point is you have already source packet flow. Doesn't change when FEC is added. Same mechanism to get that transport address assigned may need to be aplied to repair flow as well. A(Marshal): - Should be concerned about non-simple end-to-end, eg: NAT A(Mark): - Rather not. Problem of content delivery protocol, not FEC scheme itself. - Mark continuing to present slides. A(Marshal): - Will need to worry about fragmentation in source flows when adding FEC tag-data. A(Colin): - Aware of mmusic SDP profile negotiation effort. Please inform mmusic of SDP implications of proposed FEC framework - Hum on adoption by working group. Yes hums, no no hums. Hao Qin presenting geneic RTP Payload format draft draft-bsong-fecframe-gfec-00.txt - See slides. Q(Colins): - AVT co-chair: draft was previously presented in AVT. AVT rejected: conclusion that this scheme would not provide any benefits over RTP schemes developed by AVT. AVT told authors to generalize scheme and go to FEC-scheme WG. Q: what generalizations have been done. A(Hao): - Not author of this draft, not present at last IETF. Does notk now. answer. A(Stefan Wegner): - Would prefer not to see this draft again. Stop believing that interleaving solves problems. Assumptions based on current technology wrong in future, also got perfectly working RTP FEC scheme. A(Colins): - This groupis doing things much broader than RTP. RTP grop (AVT) has already rejected it. Something needs to change about this draft to have any IETF progress on it.