Last Modified: 2004-10-07
| Done | Submit design-space, building-blocks, and guidelines drafts for publication as Informational RFCs | |
| Done | Initial Drafts for the following building blocks: negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection | |
| Done | Submit Initial Drafts for the two protocol instantiations. | |
| Done | Submit Initial Draft for Congestion Control | |
| Done | Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard | |
| Done | Complete building blocks and protocol instantiations for ALC and submit for publication as Experimental RFC | |
| Done | WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly | |
| Done | Submit WEBRC (congestion control building block) for publication as Experimental | |
| Aug 03 | Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental | |
| Aug 03 | Submit NACK building block and protocol instantiation for publication as Experimental | |
| Dec 03 | Evaluate when and how the RMT Experimental specifications will be submitted for publication as Proposed Standard, and update this charter accordingly |
| RFC | Status | Title |
|---|---|---|
| RFC2887 | I | The Reliable Multicast Design Space for Bulk Data Transfer |
| RFC3048 | I | Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer |
| RFC3269 | I | Author Guidelines for RMT Building Blocks and Protocol Instantiation documents |
| RFC3450 | E | Asynchronous Layered Coding protocol instantiation |
| RFC3451 | E | Layered Coding Transport (LCT) Building Block |
| RFC3452 | E | Forward Error Correction Building Block |
| RFC3453 | I | The use of Forward Error Correction in Reliable Multicast |
| RFC3695 | E | Compact Forward Error Correction (FEC) Schemes |
| RFC3738 | E | Wave and Equation Based Rate Control building block |
| RFC3926 | E | FLUTE - File Delivery over Unidirectional Transport |
|
Reliable Multicast Transport (RMT) WG
61th IETF -- Washington DC Tue, November 9, 2004 Lorenzo Vicisano chairing Many thanks to Mark Pullen and Marshall Eubanks for taking the minutes of the meeting. Agenda ====== Chairs agenda bashing 5 mins Chairs WG Status Update 5 mins Mike Luby "Raptor" FEC ID 15 mins Lorenzo Vicisano FEC BB possible evolution 20 mins Mike Luby FEC BB for streaming ? 15 mins WG Status Update ================ NORM drafts are now finished RFC 3940 and 3941 - will be published TFMCC BB and PGMCC BB are in working group last call The agenda of the working group is officially done, although there are still some hanging FEC items. Need to update the milstones and might have to revise charter to include FEC BB revision to be discussed here. Mike Luby - "Raptor" FEC ID =========================== Raptor codes can generate as many encoding symbols as desired from a source code on the fly. Can decode after receiving a length just a little larger than the length of the original source blocks Lorenzo - Has the draft been submitted ? Mike - It is an individual submission. The code also can be made systematic (i.e., the original source codes are part of the encoding). Encoder : Goes from Source block -> encoding symbols, in two passes. The encoder starts by generating a precoding block from the source block. All of the details are in the draft : draft-luby-rmt-bb-fec-raptor-object-00.txt Pre-encoding : generates LDPC and Half symbols that are concatenated to the source block. Decoder builds up a matrix relating unknown to known symbol values, which can be solved using, e.g., Gaussian elimination. Very efficient code - and can decode if you receiver just a little more than the length of the source block in any order - 10^-3 probability that you cannot decode if you receive 1% more than the source block length. The probability of a decode failure drops to less than 10^-6 for a 2% overhead. Digital Fountain has IPR on all of this and will license this under the RAND ("reasonable and non-discriminatory") license. Lorenzo : The decision on whether to go forward will be made on the mailing list Allison : Is there an open source implementation ? Mark Handley : Are your RAND terms compatible with open source ? Mike Luby : I will have to think about this, but I think so. There is a independent implementation out of Nortel. Lorenzo Vicisano (not acting as chair) : FEC building block changes =================================================================== Shortcomings : There is no good guidance on implementation and some pieces (e.g, the splitting of objects in FLUTE) seem to be missing. Any changes have to be backwards compatible. * Fixes - A set of requirements for a fully specified encoding ID. - The FEC OTI needs to be defined in a more rigorous way. We need to make it clear that the FEC payload may contain multiple objects. - There need to be guidelines on how to write FEC ID's. * Enhancements - Allow for different symbols for encoded and repair symbols for optimization efficiency - Also want to expand the FEC range to allow for more than 256 ID's - Lastly, need some enhancements to allow the use for certain encoding ID's for streaming. Brian Adamson : From the NORM perspective - it would have been nice to have a specification for the splitting of objects into payloads. Colin Perkins on the FEC range : We had a similar problem with RTP - we went from static IDs to dynamically assigned ID's I would reserve part of the range. That's a good idea. Mike Luby - There may be consensus on doing this, but we need people who are willing to work on it. Mike Luby : FEC for streaming. ============================== Extend the FEC BB to RTP streaming. There have been some proprietary FEC applications to streaming. 3GPP SA4 MBMS has adopted FEC for RMT this will likely be part of MBMS release 6 Lorenzo : The charter of RMT is file transfer. However, it is a good practice to re-use the work of a working group if possible. We need to be sure that there is interest Stephan Wenger : Let's discuss it now. Colin Perkins : There is interest in having better FEC schemes While this fits into FEC well, it is not clear it fits into RTP. Previously, RTP used unchanged packets with protection packets for backwards compatibility Allison : The MBMS may have multiple different services. Mike Luby : MBMS == Multi Media Multicast Broadcast Services. This is a 3GPP concept. Allison : Is there a service difference ? Colin : The service is the same, but the implementation may or may not break RTP. Lorenzo : Two service models : FEC transport of RTP or RTP transport with extra repair packets. Stephan Wenger : The easiest thing to do is define streaming as the case where you do not want to wait an unlimited time for a decode. Colin : The crucial difference may be who handles the timing recovery - the RTP or the FEC packets. Stephan Wenger : Part of the confusion is that for the media practice to be protected, we are keeping the media time stamp the same. The only new thing is that the FEC time stamps have the value of when they were protected. When it comes to the media part, this is a straightforward media payload. Colin Perkins : What do you mean by streaming ? As I understand it, the 3GPP is definitely mutating the headers. Colin Perkins : The way we have done this in the past is to keep the RTP header and not insert an additional header. Stephan Wenger : But you can put in a piece of metadata if you want. Colin Perkins : Isn't what you are proposing redundant with the RTP header ? Why isn't it driven off of the RTP sequence numbers ? Mike Luby : Which packets are included in the source block ? Magnus Westerlund : You could have an explicit mapping between RTP sequence numbers and repair packet sequence numbers. Mike L. But this will cause huge inefficiencies. Colin : You have to use a recovery packet that is a long as the largest source packet in the block. Mike : If you use RFC2733 then you have to use the size of the longest packet within a block as the size of the recovery packets. You could be more sophisticated. Colin : I think that this is an interesting thing to do, but we need to work out the details. Mike Luby : So you might want to use something that is specifically designed for streaming. Stephan : The advantage is that with a BB you can just plug in different protection mechanisms. Colin : The elephant hiding in the corner is what is 3GPP doing. Allison : Do other standards bodies do RTP payloads ? Colin : 3GPP and ITU, at least. The was consensus in the room in pursuing the FEC BB resubmission as proposed by lorenzo and Mike. Contributors are sought; please send email to Lorenzo. Will take this item to the mailing list. |