From fecframe-bounces@ietf.org Fri Aug 11 15:29:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBchc-000640-TQ; Fri, 11 Aug 2006 15:29:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBchb-00060O-KH for fecframe@ietf.org; Fri, 11 Aug 2006 15:29:51 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBchb-0000LO-8j for fecframe@ietf.org; Fri, 11 Aug 2006 15:29:51 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4872719 for fecframe@ietf.org; Fri, 11 Aug 2006 15:29:51 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: fecframe@ietf.org Message-Id: <51E31C0E-2332-4AEC-AD71-D5F53C8C264B@multicasttech.com> Content-Type: multipart/mixed; boundary=Apple-Mail-4-923731254 From: Marshall Eubanks Date: Fri, 11 Aug 2006 15:29:50 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: [Fecframe] Minutes for IETF 66 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org --Apple-Mail-4-923731254 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Comments, corrections and additions, please. Marshall --Apple-Mail-4-923731254 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=FecFrame_IETF_66.txt Content-Disposition: attachment; filename=FecFrame_IETF_66.txt FEC Framework (fecframe) Working Group TUESDAY, July 11, 2006 at 1520-1720 (Room 519B) Chair(s): Greg Shepherd (GS) Marshall Eubanks (ME) Note taker: Gorry Fairhurst 1. AGENDA Agenda was agreed. 2. 3GPP Overview for Context Mark Watson (MW) Overview of 3GPP Framework which pre-dates the IETF work. This builds on the previous work of RMT (e.g. FEC Payload ID, Object transmission). The FEC scheme defines the mappings, also a mechanism needs to advertise the rules that are used (at both the sender and receiver), e.g. in SDP. The FECpayload ID is placed in the final bytes of a UDP Packet. GS: How do we maintain consistency? - is there some registration required? MW: This is a local mapping (tied to the SDP). Brian Adamson: Is the FEC payload ID included in the UDP length?: MW: The UDP-Length and UDP-checksum covers the whole of the packet. Magnus Westerlund: The UDP-payload is protected using the FEC. So this does not include the IP-level packet information. Brian Adamson: Where do you get the length information? MW: The source packet information tells you the flow-id, length, and implied padding. 3. Active Draft: draft-ietf-fecframe-req-00.txt Mark Watson This I-D offers a starting point for discussion. 3GPP only support UDP transport, but within the IETF we may need to look at others (e.g. DCCP). He guided us through a set of requirements. Al Morton: In the terminology, "application protocol" & "control protocol" are potential causes of confusion. Can we just call this a "control protocol"? MW: Good point. John Schnizlein: Requirement 30 (2nd one) - It seems challenging that we want to allow real-time variation. MW: We can allow variable protection in real-time. Stephan Wenger: The amount of FEC should be a part of the transmission process, not something that is fixed in advance, you can get some feedback. GW: Is the word "dynamic" better than "real-time"? Magnus: Is requirement 110 a sub-requirement for 100 ( Different source data protocols)? MW: We should list specific protocols, and we could relate them to FEC methods. MW: When presented, this was UDP specific. However, when generalized, should it be supported over multiple protocols. Magnus: How do you relate things and maintain the information? ... Stpehen Botzko: What do you mean by the FEC protocol? ... Should this be allowed to be backwards compatible? MW: Right. Stpehen Botzko: Is this a necessary requirement? MW: We can define 2 choices: a tag or another way (with restrictions). Different FEC schemes could have certain properties. GF: Is both multicast and unicast to be supported? MW: Yes, the Charter is for both. GF: So what is the position with congestion control? MW: Yes - this is part of the framework. The original flow should have some congestion control, FEC just adds some overhead and sends it. GF: As long as Congestion Indications (packet losses) still have effect, and are not hidden from CC by the FEC. Vincent Roka (VK): The requirement numbers 30 and 70 are quite challenging. Would it be possible to use Objects instead of Source Blocks? The RMT framework already has dynamic identification of blocks. MW: So you could use a protocol like FLUTE? The key challenge is to have everything dynamic. This is challenging, because it is still using source blocks, you can't change the source block specs from one to another instead of source blocks, you could use "objects", an FTI for object? For that, you need to specify parameters for the amount of data to protect. MW: We have 3 types of info - with the flow, with the blocks, and with the packets - and look at how each of these are communicated. In 3GPP, the info about a repair is communicated in each repair packet. VR: You can also transmit dfti in each packet. MW: - If you are using Asynchronous Layered Coding (ALC) from RMT. Magnus: In most cases we don't use ALC. If we have mixed transport protocols we could get unusual methods. Hopefully this will not happen, you may only use one at a time. MW: We need to relate this to 3GPP work. ME: Are 3GPP2 also thinking about this approach? ?: That's a long story - MW: Not yet, they have been talking for some time. ME: Are you saying that a 3GPP encoding stream, as an IP packet stream, would be legitimate instance of a fecframe stream? MW: Not quite. Stephane Wenger (SW): Should this requirement - interpreted as no intention to design something that is not compatible with 3GPP, if we can design something that is compatible with similar performance/complexity. ME: This could finally lead to something that is non-interoperabe? SW: Yes, 3GPP could invent many variations. MW: If we have a choice, then we should align with 3GPP, but we could also need to look at other things if this doesn't match our needs. Magnus: Instantiations are needed for SDP, etc, for use with IETF methods for multimedia that can be used for certain systems. SW: As an individual, I don't particularly like the idea to structure documents around known IPR constraints. A known IPR constraint is better than an unknown IPR constraints. What is least desirable is an IPR statement that does not carry RAND terms. I'd like to see an IPR statement that is "irrevocable", "free", etc. I prefer the original proposal in the TSVWG draft. MW: The IPR statement at TSV was Free. At the BOF, there were comments. SW: ... 3GPP framework is almost 1.5 years old, and companies have studied the subject matter from the business front. If we nail-down requirements that forces us to use a framework with free IPR, this also reduces safety. Safety lies in common, understood, ground (as in the 1st proposal). ME: Stephane is this a binary choice - one way or the other? SW: That's a meta question. I have no good answer, but it may be binary - there were only two proposal. The use of padding is in the framework, or we don't do this. If the Padding is the best way to go, I'd rather see it in the framework. Magnus: How does it effect the usage of already defined methods in RMT? MW: We can't use these directly, since this is not object transport. We need new schemes, which may re-use with changes. ME: we can't make the final decision now? - We'll take this to the list. It seems like a little early to ask for consensus. GS: We have about a year to arrive at the spec. MW: If the WG meets the milestones they get a keg of beer and a cake! ME: That means we are well-motivated to do good work! 4. Other Issue: SMPTE documents Marshall Eubanks The two new SMPTE documents from the Committee N26 on File Management and Networking Technology : Can they be used by fecframe ? Describes an XOR method based on RTP packets. This can be done by columns or a 2D model (2 interleavings). This is multiplexed on the ports. It is tied to video, and is not suitable. Magnus: This is a method that resembles but modifies RFC 2733. SW: Yes. ME: SMPTE is publishing a work from the pro-mpeg forum and modifies some RFC 2733 headers. It is a very efficient computationally, and suited to high bit rate video - the target is for high rate streams, e.g. 20-30 Mps. It therefore does not need to be efficient on bandwidth. E.g. the 20% of overhead is comparable to 5% of correcting power ME: Or even more. G. Logan: Do the repair packets have different protection to the data packets? Or suffer the same probability of loss as other packets. ME: It is the same. (Interleaving is important, because wire-line loss results in burst loss from router queue overflow.) MW: Interleaving is one technique for recovering burst loss, it is a design choice. This choice of FEC code is not strong for all patterns of packet loss. SW: RFC 2733 contains discussion text on good ways to determine how to process packets. Rajiv Asati: Is the overhead 20%? ME: yes RA: How does this compare? GF: This is just a parity code really. It is the worst for efficiency, but the easiest to implement. ME: Interleaving can also help. MW: Interleaving is not necessarily a solution. The selection of FEC codes is not necessarily related to the goals of the group, we do the framework here, we can use various codes. Magnus: Be aware that AVT also has some work at this meeting on packet FEC, and the authors may be interested in working in this group. Meeting closed. --Apple-Mail-4-923731254 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --Apple-Mail-4-923731254--