Last Modified: 2005-10-03
IETF 64 fecframe BOF Minutes ============================ Chair: Mark Watson (mark@digitalfountain.com) The fecframe BOF was conducted during IETF64 on Wednesday, Nov. 9, from 15:10 to 16:10. Approximately 60 people attended the BOF (tbc). The BOF chair, Mark Watson, reminded the participants of their obligations with respect to IPR, and circulated blue sheets. Stephan Wenger volunteered to take this notes.The agenda was accepted as proposed. Mark presented a slideset covering his vision of a fecframe WG to be. Forward Error Correction in this BOF must be seen as a means to recover lost packets. It's a forward-only means to combat packet losses (erasures), not a link-layer mechanism to correct bit errors. The FEC is calculated on the payloads and necessary header information of the Transport (e.g. UDP, DCCP). The main goal of the WG is not so much to define a specific protocol, but more a "Framework" of mechanisms (and their interaction) which can be used to define protocols with very limited effort. The target applications comprise audio-visual streaming with high quality and other stream-based applications (a stream can be seen as a (more or less constant) flow of packets. Object protection through FEC stays in RMT. The justifications for the use of forward protection mechanisms (e.g. FEC) are manifold, e.g. the unavailability of feedback mechanisms (broadcast, large multicast groups), but also scaling problems in high-loaded unicast streaming servers, too long roundtrip times which makes re-transmision inefficient, or cumbersome, and many more. (James Polk threw in a remark at this point that the notetaker didn't capture.) Mark went on suggesting targets for acceptable end-to-end application layer packet loss rate, e.g. defined in ITU-T Rec. Y.1541. These numbers were comparatively low, 0.1% and lower. A short discussion commenced between Stephan Wenger, Jonathan Rosenberg, and Yakovlew Stein, on the validity of these values and the best ways to combat the losses. Arguments were made in favor and against both source and channel based coding. It was clarified that (perhaps outside niche applications), FEC is primarily useful not for VoIP type low latency, but more for medium latency application like streaming. The discussion was getting out of focus for the BOF, and it was suggested to take it offline. Mark continued with more properties a FEC framework could help achieving. For example, the IETF likes end-to-end solutions, and FEC as proposed (in contrast to link layer enhancements) is such an end-to-end solution. While many see the greatest value of FEC in protecting end-to-end transmissions that involve at least one highly noisy access link, Mark also clarified that reducing the packet loss rate in the backbone, e.g. from 10E-5 to 10E-6 or lower, is also very helpful for the overall performance of the backbone and the Internet. FEC does not solve the congestion loss problem, congestion control principles need to be obeyed. This is done by reducing the rate of both the packet stream and its protection, by comparable amounts. Previous work includes RMT's FEC Building block, protocols for object delivery, FEC schemes, AVT's RTP meta payloads for protection (RFC2733, ULP), 3GPP's MBMS mechanisms (defined in TS26.346) which protect all UDP traffic, and, the framework described in draft-watson-tsvwg-fec-sf-00. This draft is one example of a protocol framework that could result from the WG to be. The objectives of the WG to be can be taken from the BOF description: sketch up a requirements draft, develop a framework, develop a "streaming protocol" in coordination with AVT, MMUSIC, and perhaps other work? The proposed way forward is to form new working group, as other WGs appear not to be appropriate. Deliverables for a WG would be: a living "requirements" draft, a standards track FEC framework, and document on how the FEC framework is used for streaming. With this, Mark opened the floor for an open mike discussion. Jonathon Rosenberg asked to clarify the relationship between fecframe and AVT work. There appears to be overlap, e.g. with respect to ULP, RFC 2733, and perhaps other drafts. Magnus Westerlund replied that ULP (replacement of RFC 2733) will be published soon, the Reed-Solomon UXP, is likely to be replaced by this work, however all of AVT efforts are RTP payload specs and not directly above transport. Ruscoe: Intention: Tweak existing specifications or develop new ones. Mark: Intention is to provide new specifications which will draw heavily on the RMT work and will not overlap. Lorenzo: Answer is based on the decision what to do with ongoing work in RMT, work could end up in either fecframe or in RMT Yacob Stein: It's ok that this work is not in AVT. However, parallel work in media standardization groups on error resilient source coding and joint source/channel optimization is encouraged. Yacob Stein triggered a short discussion on the subject of IPR, asking if there is IPR on the subject. Mark: yes, there is IPR. The FEC schemes (e.g. Raptor) are RAND, other work so far "free". Lorenzo also commented that in RMT the FEC schemes has IPR. Vincent commented that he didn't like the IPR situation and the Digital Fountain IPR reciprocity clause, but would get comments from his company lawyers. Mark confirmed that there is a reciprocity clause on the statement but otherwise a free license. Yacob Stein later commented after reviewing the Digital Fountains IPR statement on draft-watson-tsvwg-fec-sf-00 that it is not a "royalty-free license", but rather a "will not assert" statement. The FEC schemes are however RAND. Mark Watson (speaking for DF) responded that his understanding of the company position was royalty free with reciprocity, and that he would try to address the comments in short order. Rob Rein raised some concerns regarding VoIP. VoIP needs very low delay, but has a fairly high loss tolerance. Mark responded that FEC may not be appropriate for your conversational application. Magnus Westerlund commented that block lengths needs to be 200 ms or more to get any decent efficiency, thus very short blocks on the order of 20 ms is not really usable. Colin Perkins agreed that fecframe is not appropriate for conversational real-time media, but is useful elsewhere. It should be clarified which applications that fecframe will apply to. Colin's suggestion was "long lived flows". Stephan Wenger commented that we shouldn't take to narrow scope either. There are for example cases of joint source and channel coding for video in which FEC is appropriate also in low-delay applications. Magnus responded that yes, as the bit-rate goes up the possibility for low delay applications increases. Yacob Stein responded that he still don't think fecframe would be useful for VoIP telephony and audio. At this point, it was suggested to take further technical discussions offline or later; after all the BOF is there to gauge interest in a subject and not to solve problems. James Polk asked which timeframe of the work in the WG is planned to have? Mark Watson responded that he liked to have a very quick, very focused effort. A comment from the floor was "single digit number of years" which resulted in laughter. Mark sees as a target to have a good requirements document ready at the next meeting. Colin Perkins commented that the requirements discussion should reach its conclusions from appropriate applications. Yacob Stein asked if it rules out usage of retransmission, which Mark Watson confirmed. Magnus Westerlund commented that the requirements phase should start with applications and agree on which we would like to support and from that generate requirements. Jonathan Lennox stated that requirements should focus on streaming. James Polk asked if the work perhaps should be happening elsewhere, e.g. in TSVWG, as the workload is planned to go down there. Allison Mankin responded that although TSVWG may wind down a bit it is not a good idea to have it in TSVWG. This work would benefit from the focus of its own WG and therefore Allison supports the formation of an new WG. Someone asked if the meeting should review the charter proposal? Mark responded that he intended to do details of the charter later. But the base is the charter proposal in the BOF description. Greg Livovitz asked if this is an API problem and not a protocol problem. Allison Mankin (AD): API could be considered by a WG, assuming that there were a WG. Discuss charter. At this point, the BOF description was put on screen and people were given time to read. Allison stated that Magnus Westerlund and Stephan Wenger volunteered as WG chair so to free Mark for an editor position, and suggested a hmm for establishing a WG. The BOF loudly and clearly hmmd for forming a WG. No one hmmd against forming a WG. Mark asked for any other business. No other business where raised, and the meeting was adjourned. ========================================= |