From mailman-bounces@core3.amsl.com Fri Feb 1 06:38:18 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6A529435D for ; Fri, 1 Feb 2008 06:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buCEVmX7+XXn for ; Fri, 1 Feb 2008 06:38:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B642A2E16 for ; Fri, 1 Feb 2008 06:13:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: fecframe-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:40 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/fecframe/fecframe-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:39:03 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF97228EAC1 for ; Fri, 1 Feb 2008 06:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GATnqAv0Y9h for ; Fri, 1 Feb 2008 06:39:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298732A31B4 for ; Fri, 1 Feb 2008 06:14:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: fecframe-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:41 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/fecframe/fecframe-archive%40megatron.ietf.org From fecframe-bounces@ietf.org Fri Feb 1 09:42:10 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EFA28C38E; Fri, 1 Feb 2008 09:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.63 X-Spam-Level: * X-Spam-Status: No, score=1.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_NUMERIC_HELO=2.067] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GzFC7fsPBuK; Fri, 1 Feb 2008 09:42:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D75128C2B5; Fri, 1 Feb 2008 09:41:59 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B2C28C3A1; Fri, 1 Feb 2008 09:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcwJBwnMNiLe; Fri, 1 Feb 2008 09:41:55 -0800 (PST) Received: from server107.appriver.com (server107e.exghost.com [69.20.100.17]) by core3.amsl.com (Postfix) with ESMTP id 3AD103A69DE; Fri, 1 Feb 2008 09:40:27 -0800 (PST) Received: by server107.appriver.com (CommuniGate Pro PIPE 5.1.14) with PIPE id 75409465; Fri, 01 Feb 2008 12:41:58 -0500 Received: from [72.32.49.6] (HELO FE2.exchange.rackspace.com) by server107.appriver.com (CommuniGate Pro SMTP 5.1.14) with ESMTP id 75409356; Fri, 01 Feb 2008 12:41:51 -0500 Received: from 34093-EVS4C1.exchange.rackspace.com ([192.168.1.68]) by FE2.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Feb 2008 11:41:53 -0600 Received: from 64.2.18.5 ([64.2.18.5]) by 34093-EVS4C1.exchange.rackspace.com ([192.168.1.58]) via Exchange Front-End Server owa.mailseat.com ([192.168.1.146]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Feb 2008 17:40:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 01 Feb 2008 08:47:13 -0800 From: Mark Watson To: Thomas Wiegand Message-ID: Thread-Topic: [Fecframe] Flexible FEC grouping and associations Thread-Index: Achk8hgkVs6xjNDlEdyecQAX8sJN9g== In-Reply-To: <94564C78-A787-4224-845E-CD6EC9A6B392@hhi.de> Mime-version: 1.0 X-OriginalArrivalTime: 01 Feb 2008 17:41:53.0355 (UTC) FILETIME=[BB6371B0:01C864F9] X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: mark@digitalfountain.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: mark@digitalfountain.com ALLOWED X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.6 X-Note-Reverse-DNS: fe2.exchange.rackspace.com X-Note-WHTLIST: mark@digitalfountain.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 75 76 122 X-Note: Mail Class: ALLOWEDSENDER Cc: mmusic@ietf.org, jo@acm.org, Cornelius.Hellge@hhi.fraunhofer.de, jf.mule@cablelabs.com, fecframe@ietf.org Subject: Re: [Fecframe] Flexible FEC grouping and associations X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Thomas, This is like the example given by Ali, where there are two source flows (#1 and #2) and two repair flows (which I will call #A and #B). #A protects source flow #1 and #B protects source flow #1 and #2. #A and #B may or may not be additive, meaning that they could be combined into a single decoding operation (in your example they can). However, either way, there is no "dependency" between #A and #B in the sense that there is a dependency between #1 and #2. #B is perfectly useful to recover data from #1 and #2 without #A. However #2 is of no use without #1. So the relationship between #A and #B is different in character from that between #1 and #2 which is why we did not want to use the same dependency syntax for both. I don't think it's quite correct to say that this approach can never be worse than traditional FEC. Suppose #A uses an ( n1, k1 ) code, #B is an ( n2, k1+k2 ) code (so #1 has k1 source symbols and #2 has k2 source symbols). One would send n1+n2-k1 symbols (since we do not want to send the k1 source symbols of #1 twice). So, overall we have an ( n1+n2-k1, k1+k2 ) code. For a traditional code, the best possible is that receipt of any k1+k2 symbols from the n1+n2-k1 sent symbols will allow recovery of the source. And of course such codes exist. However the layered code cannot have this property. For example, suppose I receive k1+k2 symbols, k1+1 of which are from #1/#A. Assuming ideal codes, I can recover #1 using just k1 of the symbols from #1/#A. The additional symbol is redundant. Thus I have only k1+k2-1 symbols of real information towards the second code which therefore cannot recover. ...Mark On 1/31/08 11:19 AM, "Thomas Wiegand" wrote: > Mark, > > Layer-based FEC (L-FEC), as we refer to it, is a new method where the > layer-dependencies of a scalable codec are taken into account. > > By a layered codec, I mean a codec consisting of a hierarchy of layers > with one layer being the base layer and each enhancement layer > linearly is building on top of it. > > The concept of L-FEC then attempts to solve the core problem when > protecting a layered codec: You have to make sure that all layers are > available on which the highest layer that you access depends on . > > Let me explain how L-FEC solves this by using an example. > > Let's assume for simplicity that we have two layers each consisting of > 3 information bits. > > Base layer: '001' > Enhancement layer: '110' > > Let's assume the protection is an XOR operation and 2 parity bits are > produced through an XOR operation. > > In a traditional scheme, we would be XORing for the 1. parity bit the > 1. and 2. bit of the 3 bits and for the 2. parity bit the 1. and 3. > bit of the 3 bits of the base layer. To obtain both parity bits of the > enhancement layer we would do the corresponding operation there: for > the 1. parity bit, the 1. and 2. bit of the 3 bits are XORed and for > the 2. parity bit, the 1. and 3. bit of the 3 bits of the enhancement > layer are XORed. > * For the base layer, we get > 1. parity bit: 0 XOR 0 = 0 > 2. parity bit: 0 XOR 1 = 1 > * For the enhancement layer we get > 1. parity bit: 1 XOR 1 = 0 > 2. parity bit: 1 XOR 0 = 1 > If in this case the problem that you correctly referred is occurring > when 3 bits of the base layer are lost. Then the base layer cannot be > decoded and the enhancement layer is useless even if it is correctly > received in its entirety. > > L-FEC solves this as follows: > * For the base layer, we perform the exact same XOR operation as in > traditional FEC: > 1. parity bit: 0 XOR 0 = 0 > 2. parity bit: 0 XOR 1 = 1 > * For the enhancement layer, however, we also include the base layer > into the XOR operation. This is done, for example, by applying the XOR > operation to the 1. and 3. bit of the base layer and the 1. and 2. bit > of the enhancement layer jointly to produce the first parity bit. For > the second parity bit, the example could be to apply the XOR operation > to the 2. bit of the base layer and the 1. and 3. bit of the > enhancement layer. > 1. parity bit: 0 XOR 1 XOR 1 XOR 1 = 1 > 2. parity bit: 0 XOR 1 XOR 0 = 1 > If in this case the problem occurs and 3 bits of the base layer are > lost, then the base layer CAN be decoded since the enhancement layer > parity bits can be used to correct the errors. > > Please note that L-FEC can never be worse than traditional FEC as > described above in terms of error correction capability. The price to > pay is more complexity. > > I hope the example makes clear what we mean by L-FEC. (I have also > attached a JPEG picture that illustrates the example that I have > described above) > > L-FEC has been developed at HHI by Cornelius Hellge, Thomas Schierl > and me. > > Best Regards, > Thomas Wiegand > > ---- > Visit us at > > GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / > Broadcast Mobile Convergence Forum / Booth 2B82 > http://www.mobileworldcongress.com/homepage.htm > > OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415 > http://www.ofcnfoec.org > > > --- > Thomas Wiegand, Dr.-Ing. > Head, Image Communication Group > Image Processing Department > Fraunhofer Inst. for Telecommunications - HHI > Einsteinufer 37, D-10587 Berlin, Germany > Phone: +49 30 31002 617, > Mobile: +49 172 381 3814 > http: iphome.hhi.de/wiegand > --- > > > > On Jan 31, 2008, at 7:14 PM, Mark Watson wrote: > >> Thomas, >> >> What do you actually mean by "layered FEC" ? >> >> Certainly there is a concept of multiple FEC layers which makes >> sense, and >> in fecframe we have discussed this. This is what Ali refers to below >> as >> additivity - where multiple FEC streams can be usefully decoded in >> combination. >> >> However it's a very different concept from layering in the sense of a >> layered video codec. In SVC, you absolutely need the base layer in >> order to >> make sense of the enhancement layer. This is not (cannot!) be true >> for FEC >> "layers" because the whole point of FEC is to deal with losses - the >> possibility of the "base layer" packets being lost must be accepted. >> The >> "enhancement layer" is thus useful on its own. >> >> Put another way, there can be no "dependency" between FEC layers and >> this is >> why we thought it would not be correct to use the layer option in your >> dependency draft for FEC. >> >> In fact FEC "layers" are closer in concept to MDC, but this does not >> capture >> the point that, despite the absence of dependency, there may still >> be a >> notion of preference amongst the layers. >> >> There is of course a notion of dependency between source flows and >> an FEC >> repair flow that protects them. >> >> ...Mark >> >> >> >> >> On 1/31/08 9:42 AM, "Thomas Schierl" wrote: >> >>> Hi Ali, >>> >>> >>> One comment, we think that layered FEC does make sense. There may >>> be future >>> applications, which code the media and the FEC in a layered fashion. >>> >>> You may be right that from the current viewpoint layered FECs may >>> not be of >>> much use. But currently no one is using layered codecs. That may >>> change, >>> since there is now an efficient scalable codec for video. And in >>> that case, >>> your assumption may not hold. >>> >>> So, why not supporting this additional feature? >>> >>> >>> Thomas >>> >>> >>>> -----Original Message----- >>>> From: Ali Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Wednesday, January 30, 2008 10:53 PM >>>> To: mmusic@ietf.org >>>> Cc: jf.mule@cablelabs.com; jo@acm.org; fecframe@ietf.org >>>> Subject: [Fecframe] Flexible FEC grouping and associations >>>> >>>> Hi everyone, >>>> >>>> In Vancouver, we gave a brief introduction on this issue in MMUSIC >>>> and >>>> the chairs asked us to examine the existing drafts/RFCs before going >>>> any >>>> further. >>>> >>>> In yesterday's FECFRAME design team meeting, we discussed this topic >>>> and >>>> concluded that in terms of what we would like to support in >>>> FECFRAME, >>>> existing RFCs/drafts were not helping us much. We examined RFC 3388, >>>> RFC >>>> 4756, and draft-ietf-mmusic-decoding-dependency-00. >>>> >>>> Here is the summary. >>>> >>>> We would like to support the following: >>>> 1- A source flow MAY be protected by multiple FEC schemes >>>> 2- An FEC scheme MAY generate multiple repair flows >>>> 3- Source flows MAY be grouped prior to FEC protection (One or more >>>> repair flows can protect a group of source flows) >>>> >>>> The Grouping/Association Problem: >>>> RFC 3388 states that an "m" line identified by its "mid" attribute >>>> MUST >>>> NOT appear in more than one "a=group" line using the same semantics. >>>> So, >>>> the FEC grouping semantics (RFC 4756) requires us to put every >>>> source >>>> and repair flow in one "group:FEC" line. This is severely limiting >>>> as >>>> it >>>> becomes difficult to associate the source flows with the repair >>>> flows, >>>> and/or group them. >>>> >>>> Does anybody remember what the main reason was for this requirement? >>>> >>>> A very simple example: >>>> Source #1: Base-layer video >>>> Source #2: Enhancement-layer video >>>> FEC Scheme #1: Produces Repair #1 that protects Source #1, and >>>> Repair >>>> #2 >>>> that protects the group of Source #1 and #2 >>>> >>>> RFC 3388 requires us to say >>>> a=group:FEC S1 S2 R1 R2, >>>> >>>> However, this does not say anything about which repair flow(s) is >>>> protecting which source flow(s). A new generalized grouping >>>> attribute >>>> ("a=gengroup") would help this problem by allowing an "m" line to >>>> appear >>>> multiple times in the same grouping semantics. Then, we could write >>>> >>>> a=gengroup:FEC S1 R1 >>>> a=gengroup:FEC S1 S2 R2 >>>> >>>> However, we do need additional mechanisms for: >>>> >>>> The Additivity Problem: >>>> We would like to support additive repair flows (multiple repair >>>> flows >>>> can be decoded jointly to improve decoding rate). Note that we don't >>>> need layered dependency among the repair flows. Source flows might >>>> be >>>> layered encoded, but we don't think layered encoded FEC streams are >>>> much >>>> of use. >>>> >>>> Currently, there is no support for additivity from existing >>>> documents. >>>> decoding-dependency draft offers "mdc" dependency relation, however, >>>> (i) >>>> using the keyword "mdc" is not very suitable for FEC, and (ii) the >>>> draft >>>> is only intended for RTP flows. >>>> >>>> The Prioritization Problem: >>>> We would like to support prioritization of the repair flows. The >>>> sender >>>> can assign different priorities to different repair flows and we >>>> require >>>> the receivers to act accordingly. However, there is no support for >>>> prioritization from existing documents. >>>> >>>> One option is of course to define new stuff specific to our needs in >>>> the >>>> FECFRAME WG, however, we believe it is for everybody's benefit to >>>> coordinate this effort with MMUSIC and address these issues in a >>>> more >>>> general way as they may be required by other frameworks/ >>>> applications. >>>> >>>> We would like to get everybody's opinion on this issue. >>>> >>>> Thanks, >>>> -acbegen >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/fecframe >>> >>> >>> >>> ---- >>> Visit us at >>> >>> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February >>> 2008 / >>> Broadcast Mobile Convergence Forum / Booth 2B82 >>> http://www.mobileworldcongress.com/homepage.htm >>> >>> OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / >>> Booth 411/415 >>> http://www.ofcnfoec.org >>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www1.ietf.org/mailman/listinfo/fecframe >>> >> >> > _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Feb 1 15:51:26 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFB428C5C9; Fri, 1 Feb 2008 15:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noN83t+iGeGe; Fri, 1 Feb 2008 15:51:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407BC28C4EB; Fri, 1 Feb 2008 15:51:20 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFF03A685A; Fri, 1 Feb 2008 15:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zFJ47pF7MmI; Fri, 1 Feb 2008 15:51:10 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 915C528C608; Fri, 1 Feb 2008 15:50:48 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Feb 2008 15:52:24 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m11NqNtT030129; Fri, 1 Feb 2008 15:52:23 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m11Npta5023484; Fri, 1 Feb 2008 23:52:00 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 15:51:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Feb 2008 15:56:17 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406755C1B@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Flexible FEC grouping and associations thread-index: Achk8hgkVs6xjNDlEdyecQAX8sJN9gAOW4+A References: <94564C78-A787-4224-845E-CD6EC9A6B392@hhi.de> From: "Ali Begen (abegen)" To: "Mark Watson" , "Thomas Wiegand" X-OriginalArrivalTime: 01 Feb 2008 23:51:58.0028 (UTC) FILETIME=[6E67A8C0:01C8652D] Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mmusic@ietf.org, jo@acm.org, Cornelius.Hellge@hhi.fraunhofer.de, jf.mule@cablelabs.com, fecframe@ietf.org Subject: Re: [Fecframe] Flexible FEC grouping and associations X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org I agree with Mark's comments. Any dependency between the FEC streams MAY cause a decoding failure even for a successfully received FEC stream just because its ancestor FEC stream is missing. We are all aware that layering offers good network-adaptive transmission for the source flows, but it does not do so for the FEC streams. If one is receiving all source layers, he may choose to receive the FEC for the base layer only, or a single FEC stream that protects all the source layers together, or multiple (preferably additive) independently-decodable FEC streams. There is an interesting paper, which I believe, might be useful from an information theory perspective.. http://research.microsoft.com/~helenw/papers/ChouWP03.pdf If you don't have time to go through the whole paper, you may get the picture from the introduction and conclusion sections. BR, -acbegen > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com] > Sent: Friday, February 01, 2008 8:47 AM > To: Thomas Wiegand > Cc: Thomas Schierl; Ali Begen (abegen); mmusic@ietf.org; > Cornelius.Hellge@hhi.fraunhofer.de; jf.mule@cablelabs.com; > fecframe@ietf.org; jo@acm.org > Subject: Re: [Fecframe] Flexible FEC grouping and associations > > Thomas, > > This is like the example given by Ali, where there are two > source flows (#1 and #2) and two repair flows (which I will > call #A and #B). #A protects source flow #1 and #B protects > source flow #1 and #2. > > #A and #B may or may not be additive, meaning that they could > be combined into a single decoding operation (in your example > they can). However, either way, there is no "dependency" > between #A and #B in the sense that there is a dependency > between #1 and #2. #B is perfectly useful to recover data > from #1 and #2 without #A. However #2 is of no use without #1. > > So the relationship between #A and #B is different in > character from that between #1 and #2 which is why we did not > want to use the same dependency syntax for both. > > I don't think it's quite correct to say that this approach > can never be worse than traditional FEC. Suppose #A uses an ( > n1, k1 ) code, #B is an ( n2, k1+k2 ) code (so #1 has k1 > source symbols and #2 has k2 source symbols). > One would send n1+n2-k1 symbols (since we do not want to send > the k1 source symbols of #1 twice). So, overall we have an ( > n1+n2-k1, k1+k2 ) code. > > For a traditional code, the best possible is that receipt of > any k1+k2 symbols from the n1+n2-k1 sent symbols will allow > recovery of the source. > And of course such codes exist. However the layered code > cannot have this property. For example, suppose I receive > k1+k2 symbols, k1+1 of which are from #1/#A. Assuming ideal > codes, I can recover #1 using just k1 of the symbols from > #1/#A. The additional symbol is redundant. Thus I have only > k1+k2-1 symbols of real information towards the second code which > k1+therefore > cannot recover. > > ...Mark > > On 1/31/08 11:19 AM, "Thomas Wiegand" wrote: > > > Mark, > > > > Layer-based FEC (L-FEC), as we refer to it, is a new method > where the > > layer-dependencies of a scalable codec are taken into account. > > > > By a layered codec, I mean a codec consisting of a > hierarchy of layers > > with one layer being the base layer and each enhancement layer > > linearly is building on top of it. > > > > The concept of L-FEC then attempts to solve the core problem when > > protecting a layered codec: You have to make sure that all > layers are > > available on which the highest layer that you access depends on . > > > > Let me explain how L-FEC solves this by using an example. > > > > Let's assume for simplicity that we have two layers each > consisting of > > 3 information bits. > > > > Base layer: '001' > > Enhancement layer: '110' > > > > Let's assume the protection is an XOR operation and 2 > parity bits are > > produced through an XOR operation. > > > > In a traditional scheme, we would be XORing for the 1. > parity bit the > > 1. and 2. bit of the 3 bits and for the 2. parity bit the 1. and 3. > > bit of the 3 bits of the base layer. To obtain both parity > bits of the > > enhancement layer we would do the corresponding operation > there: for > > the 1. parity bit, the 1. and 2. bit of the 3 bits are > XORed and for > > the 2. parity bit, the 1. and 3. bit of the 3 bits of the > enhancement > > layer are XORed. > > * For the base layer, we get > > 1. parity bit: 0 XOR 0 = 0 > > 2. parity bit: 0 XOR 1 = 1 > > * For the enhancement layer we get > > 1. parity bit: 1 XOR 1 = 0 > > 2. parity bit: 1 XOR 0 = 1 > > If in this case the problem that you correctly referred is > occurring > > when 3 bits of the base layer are lost. Then the base layer > cannot be > > decoded and the enhancement layer is useless even if it is > correctly > > received in its entirety. > > > > L-FEC solves this as follows: > > * For the base layer, we perform the exact same XOR operation as in > > traditional FEC: > > 1. parity bit: 0 XOR 0 = 0 > > 2. parity bit: 0 XOR 1 = 1 > > * For the enhancement layer, however, we also include the > base layer > > into the XOR operation. This is done, for example, by > applying the XOR > > operation to the 1. and 3. bit of the base layer and the 1. > and 2. bit > > of the enhancement layer jointly to produce the first > parity bit. For > > the second parity bit, the example could be to apply the > XOR operation > > to the 2. bit of the base layer and the 1. and 3. bit of the > > enhancement layer. > > 1. parity bit: 0 XOR 1 XOR 1 XOR 1 = 1 2. parity bit: 0 XOR > 1 XOR 0 = > > 1 If in this case the problem occurs and 3 bits of the base > layer are > > lost, then the base layer CAN be decoded since the > enhancement layer > > parity bits can be used to correct the errors. > > > > Please note that L-FEC can never be worse than traditional FEC as > > described above in terms of error correction capability. > The price to > > pay is more complexity. > > > > I hope the example makes clear what we mean by L-FEC. (I have also > > attached a JPEG picture that illustrates the example that I have > > described above) > > > > L-FEC has been developed at HHI by Cornelius Hellge, Thomas Schierl > > and me. > > > > Best Regards, > > Thomas Wiegand > > > > ---- > > Visit us at > > > > GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 > February 2008 > > / Broadcast Mobile Convergence Forum / Booth 2B82 > > http://www.mobileworldcongress.com/homepage.htm > > > > OFC 2008 / San Diego, California, USA / 26 - 28 February > 2008 / Booth > > 411/415 http://www.ofcnfoec.org > > > > > > --- > > Thomas Wiegand, Dr.-Ing. > > Head, Image Communication Group > > Image Processing Department > > Fraunhofer Inst. for Telecommunications - HHI Einsteinufer > 37, D-10587 > > Berlin, Germany > > Phone: +49 30 31002 617, > > Mobile: +49 172 381 3814 > > http: iphome.hhi.de/wiegand > > --- > > > > > > > > On Jan 31, 2008, at 7:14 PM, Mark Watson wrote: > > > >> Thomas, > >> > >> What do you actually mean by "layered FEC" ? > >> > >> Certainly there is a concept of multiple FEC layers which makes > >> sense, and in fecframe we have discussed this. This is what Ali > >> refers to below as additivity - where multiple FEC streams can be > >> usefully decoded in combination. > >> > >> However it's a very different concept from layering in the > sense of a > >> layered video codec. In SVC, you absolutely need the base layer in > >> order to make sense of the enhancement layer. This is not > (cannot!) > >> be true for FEC "layers" because the whole point of FEC is to deal > >> with losses - the possibility of the "base layer" packets > being lost > >> must be accepted. > >> The > >> "enhancement layer" is thus useful on its own. > >> > >> Put another way, there can be no "dependency" between FEC > layers and > >> this is why we thought it would not be correct to use the layer > >> option in your dependency draft for FEC. > >> > >> In fact FEC "layers" are closer in concept to MDC, but > this does not > >> capture the point that, despite the absence of dependency, > there may > >> still be a notion of preference amongst the layers. > >> > >> There is of course a notion of dependency between source > flows and an > >> FEC repair flow that protects them. > >> > >> ...Mark > >> > >> > >> > >> > >> On 1/31/08 9:42 AM, "Thomas Schierl" wrote: > >> > >>> Hi Ali, > >>> > >>> > >>> One comment, we think that layered FEC does make sense. > There may be > >>> future applications, which code the media and the FEC in > a layered > >>> fashion. > >>> > >>> You may be right that from the current viewpoint layered FECs may > >>> not be of much use. But currently no one is using > layered codecs. > >>> That may change, since there is now an efficient scalable > codec for > >>> video. And in that case, your assumption may not hold. > >>> > >>> So, why not supporting this additional feature? > >>> > >>> > >>> Thomas > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ali Begen (abegen) [mailto:abegen@cisco.com] > >>>> Sent: Wednesday, January 30, 2008 10:53 PM > >>>> To: mmusic@ietf.org > >>>> Cc: jf.mule@cablelabs.com; jo@acm.org; fecframe@ietf.org > >>>> Subject: [Fecframe] Flexible FEC grouping and associations > >>>> > >>>> Hi everyone, > >>>> > >>>> In Vancouver, we gave a brief introduction on this issue > in MMUSIC > >>>> and the chairs asked us to examine the existing > drafts/RFCs before > >>>> going any further. > >>>> > >>>> In yesterday's FECFRAME design team meeting, we discussed this > >>>> topic and concluded that in terms of what we would like > to support > >>>> in FECFRAME, existing RFCs/drafts were not helping us much. We > >>>> examined RFC 3388, RFC 4756, and > >>>> draft-ietf-mmusic-decoding-dependency-00. > >>>> > >>>> Here is the summary. > >>>> > >>>> We would like to support the following: > >>>> 1- A source flow MAY be protected by multiple FEC schemes > >>>> 2- An FEC scheme MAY generate multiple repair flows > >>>> 3- Source flows MAY be grouped prior to FEC protection > (One or more > >>>> repair flows can protect a group of source flows) > >>>> > >>>> The Grouping/Association Problem: > >>>> RFC 3388 states that an "m" line identified by its "mid" > attribute > >>>> MUST NOT appear in more than one "a=group" line using the same > >>>> semantics. > >>>> So, > >>>> the FEC grouping semantics (RFC 4756) requires us to put every > >>>> source and repair flow in one "group:FEC" line. This is severely > >>>> limiting as it becomes difficult to associate the source > flows with > >>>> the repair flows, and/or group them. > >>>> > >>>> Does anybody remember what the main reason was for this > requirement? > >>>> > >>>> A very simple example: > >>>> Source #1: Base-layer video > >>>> Source #2: Enhancement-layer video > >>>> FEC Scheme #1: Produces Repair #1 that protects Source #1, and > >>>> Repair > >>>> #2 > >>>> that protects the group of Source #1 and #2 > >>>> > >>>> RFC 3388 requires us to say > >>>> a=group:FEC S1 S2 R1 R2, > >>>> > >>>> However, this does not say anything about which repair > flow(s) is > >>>> protecting which source flow(s). A new generalized grouping > >>>> attribute > >>>> ("a=gengroup") would help this problem by allowing an > "m" line to > >>>> appear multiple times in the same grouping semantics. Then, we > >>>> could write > >>>> > >>>> a=gengroup:FEC S1 R1 > >>>> a=gengroup:FEC S1 S2 R2 > >>>> > >>>> However, we do need additional mechanisms for: > >>>> > >>>> The Additivity Problem: > >>>> We would like to support additive repair flows (multiple repair > >>>> flows can be decoded jointly to improve decoding rate). > Note that > >>>> we don't need layered dependency among the repair flows. Source > >>>> flows might be layered encoded, but we don't think > layered encoded > >>>> FEC streams are much of use. > >>>> > >>>> Currently, there is no support for additivity from existing > >>>> documents. > >>>> decoding-dependency draft offers "mdc" dependency relation, > >>>> however, > >>>> (i) > >>>> using the keyword "mdc" is not very suitable for FEC, > and (ii) the > >>>> draft is only intended for RTP flows. > >>>> > >>>> The Prioritization Problem: > >>>> We would like to support prioritization of the repair flows. The > >>>> sender can assign different priorities to different repair flows > >>>> and we require the receivers to act accordingly. > However, there is > >>>> no support for prioritization from existing documents. > >>>> > >>>> One option is of course to define new stuff specific to > our needs > >>>> in the FECFRAME WG, however, we believe it is for everybody's > >>>> benefit to coordinate this effort with MMUSIC and address these > >>>> issues in a more general way as they may be required by other > >>>> frameworks/ applications. > >>>> > >>>> We would like to get everybody's opinion on this issue. > >>>> > >>>> Thanks, > >>>> -acbegen > >>>> > >>>> _______________________________________________ > >>>> Fecframe mailing list > >>>> Fecframe@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/fecframe > >>> > >>> > >>> > >>> ---- > >>> Visit us at > >>> > >>> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February > >>> 2008 / > >>> Broadcast Mobile Convergence Forum / Booth 2B82 > >>> http://www.mobileworldcongress.com/homepage.htm > >>> > >>> OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / > >>> Booth 411/415 http://www.ofcnfoec.org > >>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe > >>> > >> > >> > > > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sat Feb 2 08:59:35 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D219E3A6A42; Sat, 2 Feb 2008 08:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KXBpRZE4VmH; Sat, 2 Feb 2008 08:59:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429463A6A48; Sat, 2 Feb 2008 08:59:32 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B723C3A69A6; Sat, 2 Feb 2008 08:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqIuYklMs9eg; Sat, 2 Feb 2008 08:59:24 -0800 (PST) Received: from server107.appriver.com (server107e.exghost.com [69.20.100.17]) by core3.amsl.com (Postfix) with ESMTP id C60EE3A683D; Sat, 2 Feb 2008 08:59:20 -0800 (PST) Received: by server107.appriver.com (CommuniGate Pro PIPE 5.1.14) with PIPE id 75810607; Sat, 02 Feb 2008 12:00:52 -0500 Received: from [72.32.49.5] (HELO FE1.exchange.rackspace.com) by server107.appriver.com (CommuniGate Pro SMTP 5.1.14) with ESMTP id 75810597; Sat, 02 Feb 2008 12:00:50 -0500 Received: from 34093-EVS4C1.exchange.rackspace.com ([192.168.1.68]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Feb 2008 11:00:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 2 Feb 2008 10:58:34 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] Flexible FEC grouping and associations Thread-Index: Achlfy2t3HxwxXxsSCW4CphdOu/bmwAPR8EA References: <94564C78-A787-4224-845E-CD6EC9A6B392@hhi.de><04CAD96D4C5A3D48B1919248A8FE0D5406755C1B@xmb-sjc-215.amer.cisco.com> From: "Michael Luby" To: "Thomas Wiegand" , "Ali Begen (abegen)" X-OriginalArrivalTime: 02 Feb 2008 17:00:52.0889 (UTC) FILETIME=[2B3FE090:01C865BD] X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: luby@digitalfountain.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: luby@digitalfountain.com ALLOWED X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.exchange.rackspace.com X-Note-WHTLIST: luby@digitalfountain.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 75 76 122 X-Note: Mail Class: ALLOWEDSENDER Cc: mmusic@ietf.org, jo@acm.org, Cornelius.Hellge@hhi.fraunhofer.de, jf.mule@cablelabs.com, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] Flexible FEC grouping and associations X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org One comment (***) below. -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Thomas Wiegand Sent: Saturday, February 02, 2008 1:37 AM To: Ali Begen (abegen) Cc: mmusic@ietf.org; jo@acm.org; Cornelius.Hellge@hhi.fraunhofer.de; jf.mule@cablelabs.com; Thomas Schierl; fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] Flexible FEC grouping and associations We don't talk about such dependencies between FEC streams. But in a layered codec, the FEC of the enhancement layer should always cover the information bits/packets of the base layer. *** There are advantages and disadvantages of this. I'm not sure this is a "should". Best Regards, Thomas On Feb 2, 2008, at 12:56 AM, Ali Begen (abegen) wrote: > I agree with Mark's comments. Any dependency between the FEC streams > MAY > cause a decoding failure even for a successfully received FEC stream > just because its ancestor FEC stream is missing. > > We are all aware that layering offers good network-adaptive > transmission > for the source flows, but it does not do so for the FEC streams. If > one > is receiving all source layers, he may choose to receive the FEC for > the > base layer only, or a single FEC stream that protects all the source > layers together, or multiple (preferably additive) > independently-decodable FEC streams. > > There is an interesting paper, which I believe, might be useful from > an > information theory perspective.. > http://research.microsoft.com/~helenw/papers/ChouWP03.pdf > > If you don't have time to go through the whole paper, you may get the > picture from the introduction and conclusion sections. > > BR, > -acbegen > > > >> -----Original Message----- >> From: Mark Watson [mailto:mark@digitalfountain.com] >> Sent: Friday, February 01, 2008 8:47 AM >> To: Thomas Wiegand >> Cc: Thomas Schierl; Ali Begen (abegen); mmusic@ietf.org; >> Cornelius.Hellge@hhi.fraunhofer.de; jf.mule@cablelabs.com; >> fecframe@ietf.org; jo@acm.org >> Subject: Re: [Fecframe] Flexible FEC grouping and associations >> >> Thomas, >> >> This is like the example given by Ali, where there are two >> source flows (#1 and #2) and two repair flows (which I will >> call #A and #B). #A protects source flow #1 and #B protects >> source flow #1 and #2. >> >> #A and #B may or may not be additive, meaning that they could >> be combined into a single decoding operation (in your example >> they can). However, either way, there is no "dependency" >> between #A and #B in the sense that there is a dependency >> between #1 and #2. #B is perfectly useful to recover data >> from #1 and #2 without #A. However #2 is of no use without #1. >> >> So the relationship between #A and #B is different in >> character from that between #1 and #2 which is why we did not >> want to use the same dependency syntax for both. >> >> I don't think it's quite correct to say that this approach >> can never be worse than traditional FEC. Suppose #A uses an ( >> n1, k1 ) code, #B is an ( n2, k1+k2 ) code (so #1 has k1 >> source symbols and #2 has k2 source symbols). >> One would send n1+n2-k1 symbols (since we do not want to send >> the k1 source symbols of #1 twice). So, overall we have an ( >> n1+n2-k1, k1+k2 ) code. >> >> For a traditional code, the best possible is that receipt of >> any k1+k2 symbols from the n1+n2-k1 sent symbols will allow >> recovery of the source. >> And of course such codes exist. However the layered code >> cannot have this property. For example, suppose I receive >> k1+k2 symbols, k1+1 of which are from #1/#A. Assuming ideal >> codes, I can recover #1 using just k1 of the symbols from >> #1/#A. The additional symbol is redundant. Thus I have only >> k1+k2-1 symbols of real information towards the second code which >> k1+therefore >> cannot recover. >> >> ...Mark >> >> On 1/31/08 11:19 AM, "Thomas Wiegand" wrote: >> >>> Mark, >>> >>> Layer-based FEC (L-FEC), as we refer to it, is a new method >> where the >>> layer-dependencies of a scalable codec are taken into account. >>> >>> By a layered codec, I mean a codec consisting of a >> hierarchy of layers >>> with one layer being the base layer and each enhancement layer >>> linearly is building on top of it. >>> >>> The concept of L-FEC then attempts to solve the core problem when >>> protecting a layered codec: You have to make sure that all >> layers are >>> available on which the highest layer that you access depends on . >>> >>> Let me explain how L-FEC solves this by using an example. >>> >>> Let's assume for simplicity that we have two layers each >> consisting of >>> 3 information bits. >>> >>> Base layer: '001' >>> Enhancement layer: '110' >>> >>> Let's assume the protection is an XOR operation and 2 >> parity bits are >>> produced through an XOR operation. >>> >>> In a traditional scheme, we would be XORing for the 1. >> parity bit the >>> 1. and 2. bit of the 3 bits and for the 2. parity bit the 1. and 3. >>> bit of the 3 bits of the base layer. To obtain both parity >> bits of the >>> enhancement layer we would do the corresponding operation >> there: for >>> the 1. parity bit, the 1. and 2. bit of the 3 bits are >> XORed and for >>> the 2. parity bit, the 1. and 3. bit of the 3 bits of the >> enhancement >>> layer are XORed. >>> * For the base layer, we get >>> 1. parity bit: 0 XOR 0 = 0 >>> 2. parity bit: 0 XOR 1 = 1 >>> * For the enhancement layer we get >>> 1. parity bit: 1 XOR 1 = 0 >>> 2. parity bit: 1 XOR 0 = 1 >>> If in this case the problem that you correctly referred is >> occurring >>> when 3 bits of the base layer are lost. Then the base layer >> cannot be >>> decoded and the enhancement layer is useless even if it is >> correctly >>> received in its entirety. >>> >>> L-FEC solves this as follows: >>> * For the base layer, we perform the exact same XOR operation as in >>> traditional FEC: >>> 1. parity bit: 0 XOR 0 = 0 >>> 2. parity bit: 0 XOR 1 = 1 >>> * For the enhancement layer, however, we also include the >> base layer >>> into the XOR operation. This is done, for example, by >> applying the XOR >>> operation to the 1. and 3. bit of the base layer and the 1. >> and 2. bit >>> of the enhancement layer jointly to produce the first >> parity bit. For >>> the second parity bit, the example could be to apply the >> XOR operation >>> to the 2. bit of the base layer and the 1. and 3. bit of the >>> enhancement layer. >>> 1. parity bit: 0 XOR 1 XOR 1 XOR 1 = 1 2. parity bit: 0 XOR >> 1 XOR 0 = >>> 1 If in this case the problem occurs and 3 bits of the base >> layer are >>> lost, then the base layer CAN be decoded since the >> enhancement layer >>> parity bits can be used to correct the errors. >>> >>> Please note that L-FEC can never be worse than traditional FEC as >>> described above in terms of error correction capability. >> The price to >>> pay is more complexity. >>> >>> I hope the example makes clear what we mean by L-FEC. (I have also >>> attached a JPEG picture that illustrates the example that I have >>> described above) >>> >>> L-FEC has been developed at HHI by Cornelius Hellge, Thomas Schierl >>> and me. >>> >>> Best Regards, >>> Thomas Wiegand >>> >>> ---- >>> Visit us at >>> >>> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 >> February 2008 >>> / Broadcast Mobile Convergence Forum / Booth 2B82 >>> http://www.mobileworldcongress.com/homepage.htm >>> >>> OFC 2008 / San Diego, California, USA / 26 - 28 February >> 2008 / Booth >>> 411/415 http://www.ofcnfoec.org >>> >>> >>> --- >>> Thomas Wiegand, Dr.-Ing. >>> Head, Image Communication Group >>> Image Processing Department >>> Fraunhofer Inst. for Telecommunications - HHI Einsteinufer >> 37, D-10587 >>> Berlin, Germany >>> Phone: +49 30 31002 617, >>> Mobile: +49 172 381 3814 >>> http: iphome.hhi.de/wiegand >>> --- >>> >>> >>> >>> On Jan 31, 2008, at 7:14 PM, Mark Watson wrote: >>> >>>> Thomas, >>>> >>>> What do you actually mean by "layered FEC" ? >>>> >>>> Certainly there is a concept of multiple FEC layers which makes >>>> sense, and in fecframe we have discussed this. This is what Ali >>>> refers to below as additivity - where multiple FEC streams can be >>>> usefully decoded in combination. >>>> >>>> However it's a very different concept from layering in the >> sense of a >>>> layered video codec. In SVC, you absolutely need the base layer in >>>> order to make sense of the enhancement layer. This is not >> (cannot!) >>>> be true for FEC "layers" because the whole point of FEC is to deal >>>> with losses - the possibility of the "base layer" packets >> being lost >>>> must be accepted. >>>> The >>>> "enhancement layer" is thus useful on its own. >>>> >>>> Put another way, there can be no "dependency" between FEC >> layers and >>>> this is why we thought it would not be correct to use the layer >>>> option in your dependency draft for FEC. >>>> >>>> In fact FEC "layers" are closer in concept to MDC, but >> this does not >>>> capture the point that, despite the absence of dependency, >> there may >>>> still be a notion of preference amongst the layers. >>>> >>>> There is of course a notion of dependency between source >> flows and an >>>> FEC repair flow that protects them. >>>> >>>> ...Mark >>>> >>>> >>>> >>>> >>>> On 1/31/08 9:42 AM, "Thomas Schierl" wrote: >>>> >>>>> Hi Ali, >>>>> >>>>> >>>>> One comment, we think that layered FEC does make sense. >> There may be >>>>> future applications, which code the media and the FEC in >> a layered >>>>> fashion. >>>>> >>>>> You may be right that from the current viewpoint layered FECs may >>>>> not be of much use. But currently no one is using >> layered codecs. >>>>> That may change, since there is now an efficient scalable >> codec for >>>>> video. And in that case, your assumption may not hold. >>>>> >>>>> So, why not supporting this additional feature? >>>>> >>>>> >>>>> Thomas >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ali Begen (abegen) [mailto:abegen@cisco.com] >>>>>> Sent: Wednesday, January 30, 2008 10:53 PM >>>>>> To: mmusic@ietf.org >>>>>> Cc: jf.mule@cablelabs.com; jo@acm.org; fecframe@ietf.org >>>>>> Subject: [Fecframe] Flexible FEC grouping and associations >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> In Vancouver, we gave a brief introduction on this issue >> in MMUSIC >>>>>> and the chairs asked us to examine the existing >> drafts/RFCs before >>>>>> going any further. >>>>>> >>>>>> In yesterday's FECFRAME design team meeting, we discussed this >>>>>> topic and concluded that in terms of what we would like >> to support >>>>>> in FECFRAME, existing RFCs/drafts were not helping us much. We >>>>>> examined RFC 3388, RFC 4756, and >>>>>> draft-ietf-mmusic-decoding-dependency-00. >>>>>> >>>>>> Here is the summary. >>>>>> >>>>>> We would like to support the following: >>>>>> 1- A source flow MAY be protected by multiple FEC schemes >>>>>> 2- An FEC scheme MAY generate multiple repair flows >>>>>> 3- Source flows MAY be grouped prior to FEC protection >> (One or more >>>>>> repair flows can protect a group of source flows) >>>>>> >>>>>> The Grouping/Association Problem: >>>>>> RFC 3388 states that an "m" line identified by its "mid" >> attribute >>>>>> MUST NOT appear in more than one "a=group" line using the same >>>>>> semantics. >>>>>> So, >>>>>> the FEC grouping semantics (RFC 4756) requires us to put every >>>>>> source and repair flow in one "group:FEC" line. This is severely >>>>>> limiting as it becomes difficult to associate the source >> flows with >>>>>> the repair flows, and/or group them. >>>>>> >>>>>> Does anybody remember what the main reason was for this >> requirement? >>>>>> >>>>>> A very simple example: >>>>>> Source #1: Base-layer video >>>>>> Source #2: Enhancement-layer video >>>>>> FEC Scheme #1: Produces Repair #1 that protects Source #1, and >>>>>> Repair >>>>>> #2 >>>>>> that protects the group of Source #1 and #2 >>>>>> >>>>>> RFC 3388 requires us to say >>>>>> a=group:FEC S1 S2 R1 R2, >>>>>> >>>>>> However, this does not say anything about which repair >> flow(s) is >>>>>> protecting which source flow(s). A new generalized grouping >>>>>> attribute >>>>>> ("a=gengroup") would help this problem by allowing an >> "m" line to >>>>>> appear multiple times in the same grouping semantics. Then, we >>>>>> could write >>>>>> >>>>>> a=gengroup:FEC S1 R1 >>>>>> a=gengroup:FEC S1 S2 R2 >>>>>> >>>>>> However, we do need additional mechanisms for: >>>>>> >>>>>> The Additivity Problem: >>>>>> We would like to support additive repair flows (multiple repair >>>>>> flows can be decoded jointly to improve decoding rate). >> Note that >>>>>> we don't need layered dependency among the repair flows. Source >>>>>> flows might be layered encoded, but we don't think >> layered encoded >>>>>> FEC streams are much of use. >>>>>> >>>>>> Currently, there is no support for additivity from existing >>>>>> documents. >>>>>> decoding-dependency draft offers "mdc" dependency relation, >>>>>> however, >>>>>> (i) >>>>>> using the keyword "mdc" is not very suitable for FEC, >> and (ii) the >>>>>> draft is only intended for RTP flows. >>>>>> >>>>>> The Prioritization Problem: >>>>>> We would like to support prioritization of the repair flows. The >>>>>> sender can assign different priorities to different repair flows >>>>>> and we require the receivers to act accordingly. >> However, there is >>>>>> no support for prioritization from existing documents. >>>>>> >>>>>> One option is of course to define new stuff specific to >> our needs >>>>>> in the FECFRAME WG, however, we believe it is for everybody's >>>>>> benefit to coordinate this effort with MMUSIC and address these >>>>>> issues in a more general way as they may be required by other >>>>>> frameworks/ applications. >>>>>> >>>>>> We would like to get everybody's opinion on this issue. >>>>>> >>>>>> Thanks, >>>>>> -acbegen >>>>>> >>>>>> _______________________________________________ >>>>>> Fecframe mailing list >>>>>> Fecframe@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/fecframe >>>>> >>>>> >>>>> >>>>> ---- >>>>> Visit us at >>>>> >>>>> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February >>>>> 2008 / >>>>> Broadcast Mobile Convergence Forum / Booth 2B82 >>>>> http://www.mobileworldcongress.com/homepage.htm >>>>> >>>>> OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / >>>>> Booth 411/415 http://www.ofcnfoec.org >>>>> >>>>> _______________________________________________ >>>>> Fecframe mailing list >>>>> Fecframe@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/fecframe >>>>> >>>> >>>> >>> >> >> >> > ---- Visit us at GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / Broadcast Mobile Convergence Forum / Booth 2B82 http://www.mobileworldcongress.com/homepage.htm OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415 http://www.ofcnfoec.org _______________________________________________ mmusic mailing list mmusic@ietf.org http://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sat Feb 2 11:32:45 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E993A6AA1; Sat, 2 Feb 2008 11:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCdWysMdfhn9; Sat, 2 Feb 2008 11:32:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D413A6A72; Sat, 2 Feb 2008 11:32:43 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C61D3A6A6C; Sat, 2 Feb 2008 11:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTkX51uberMJ; Sat, 2 Feb 2008 11:32:39 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 966C23A6A72; Sat, 2 Feb 2008 11:32:39 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 10269072; Sat, 02 Feb 2008 13:34:15 -0500 In-Reply-To: References: <94564C78-A787-4224-845E-CD6EC9A6B392@hhi.de><04CAD96D4C5A3D48B1919248A8FE0D5406755C1B@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <79B2B799-F5BB-438E-8F32-8D10242E9034@multicasttech.com> From: Marshall Eubanks Date: Sat, 2 Feb 2008 13:34:08 -0500 To: "Michael Luby" X-Mailer: Apple Mail (2.753) Cc: mmusic@ietf.org, Thomas Wiegand , jo@acm.org, Cornelius.Hellge@hhi.fraunhofer.de, jf.mule@cablelabs.com, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] Flexible FEC grouping and associations X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Dear Mike; On Feb 2, 2008, at 11:58 AM, Michael Luby wrote: > One comment (***) below. > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf > Of Thomas Wiegand > Sent: Saturday, February 02, 2008 1:37 AM > To: Ali Begen (abegen) > Cc: mmusic@ietf.org; jo@acm.org; Cornelius.Hellge@hhi.fraunhofer.de; > jf.mule@cablelabs.com; Thomas Schierl; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] Flexible FEC grouping and > associations > > We don't talk about such dependencies between FEC streams. > > But in a layered codec, the FEC of the enhancement layer should always > cover the information bits/packets of the base layer. > > *** There are advantages and disadvantages of this. I'm not sure this > is a "should". I would agree that it should not be a MUST, but is there any reason why not to make it a SHOULD ? From RFC 2119 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (I guess it could be a should and not a SHOULD, if you want.) Regards Marshall > > Best Regards, > Thomas > > > > > On Feb 2, 2008, at 12:56 AM, Ali Begen (abegen) wrote: > >> I agree with Mark's comments. Any dependency between the FEC streams >> MAY >> cause a decoding failure even for a successfully received FEC stream >> just because its ancestor FEC stream is missing. >> >> We are all aware that layering offers good network-adaptive >> transmission >> for the source flows, but it does not do so for the FEC streams. If >> one >> is receiving all source layers, he may choose to receive the FEC for >> the >> base layer only, or a single FEC stream that protects all the source >> layers together, or multiple (preferably additive) >> independently-decodable FEC streams. >> >> There is an interesting paper, which I believe, might be useful from >> an >> information theory perspective.. >> http://research.microsoft.com/~helenw/papers/ChouWP03.pdf >> >> If you don't have time to go through the whole paper, you may get the >> picture from the introduction and conclusion sections. >> >> BR, >> -acbegen >> >> >> >>> -----Original Message----- >>> From: Mark Watson [mailto:mark@digitalfountain.com] >>> Sent: Friday, February 01, 2008 8:47 AM >>> To: Thomas Wiegand >>> Cc: Thomas Schierl; Ali Begen (abegen); mmusic@ietf.org; >>> Cornelius.Hellge@hhi.fraunhofer.de; jf.mule@cablelabs.com; >>> fecframe@ietf.org; jo@acm.org >>> Subject: Re: [Fecframe] Flexible FEC grouping and associations >>> >>> Thomas, >>> >>> This is like the example given by Ali, where there are two >>> source flows (#1 and #2) and two repair flows (which I will >>> call #A and #B). #A protects source flow #1 and #B protects >>> source flow #1 and #2. >>> >>> #A and #B may or may not be additive, meaning that they could >>> be combined into a single decoding operation (in your example >>> they can). However, either way, there is no "dependency" >>> between #A and #B in the sense that there is a dependency >>> between #1 and #2. #B is perfectly useful to recover data >>> from #1 and #2 without #A. However #2 is of no use without #1. >>> >>> So the relationship between #A and #B is different in >>> character from that between #1 and #2 which is why we did not >>> want to use the same dependency syntax for both. >>> >>> I don't think it's quite correct to say that this approach >>> can never be worse than traditional FEC. Suppose #A uses an ( >>> n1, k1 ) code, #B is an ( n2, k1+k2 ) code (so #1 has k1 >>> source symbols and #2 has k2 source symbols). >>> One would send n1+n2-k1 symbols (since we do not want to send >>> the k1 source symbols of #1 twice). So, overall we have an ( >>> n1+n2-k1, k1+k2 ) code. >>> >>> For a traditional code, the best possible is that receipt of >>> any k1+k2 symbols from the n1+n2-k1 sent symbols will allow >>> recovery of the source. >>> And of course such codes exist. However the layered code >>> cannot have this property. For example, suppose I receive >>> k1+k2 symbols, k1+1 of which are from #1/#A. Assuming ideal >>> codes, I can recover #1 using just k1 of the symbols from >>> #1/#A. The additional symbol is redundant. Thus I have only >>> k1+k2-1 symbols of real information towards the second code which >>> k1+therefore >>> cannot recover. >>> >>> ...Mark >>> >>> On 1/31/08 11:19 AM, "Thomas Wiegand" wrote: >>> >>>> Mark, >>>> >>>> Layer-based FEC (L-FEC), as we refer to it, is a new method >>> where the >>>> layer-dependencies of a scalable codec are taken into account. >>>> >>>> By a layered codec, I mean a codec consisting of a >>> hierarchy of layers >>>> with one layer being the base layer and each enhancement layer >>>> linearly is building on top of it. >>>> >>>> The concept of L-FEC then attempts to solve the core problem when >>>> protecting a layered codec: You have to make sure that all >>> layers are >>>> available on which the highest layer that you access depends on . >>>> >>>> Let me explain how L-FEC solves this by using an example. >>>> >>>> Let's assume for simplicity that we have two layers each >>> consisting of >>>> 3 information bits. >>>> >>>> Base layer: '001' >>>> Enhancement layer: '110' >>>> >>>> Let's assume the protection is an XOR operation and 2 >>> parity bits are >>>> produced through an XOR operation. >>>> >>>> In a traditional scheme, we would be XORing for the 1. >>> parity bit the >>>> 1. and 2. bit of the 3 bits and for the 2. parity bit the 1. and 3. >>>> bit of the 3 bits of the base layer. To obtain both parity >>> bits of the >>>> enhancement layer we would do the corresponding operation >>> there: for >>>> the 1. parity bit, the 1. and 2. bit of the 3 bits are >>> XORed and for >>>> the 2. parity bit, the 1. and 3. bit of the 3 bits of the >>> enhancement >>>> layer are XORed. >>>> * For the base layer, we get >>>> 1. parity bit: 0 XOR 0 = 0 >>>> 2. parity bit: 0 XOR 1 = 1 >>>> * For the enhancement layer we get >>>> 1. parity bit: 1 XOR 1 = 0 >>>> 2. parity bit: 1 XOR 0 = 1 >>>> If in this case the problem that you correctly referred is >>> occurring >>>> when 3 bits of the base layer are lost. Then the base layer >>> cannot be >>>> decoded and the enhancement layer is useless even if it is >>> correctly >>>> received in its entirety. >>>> >>>> L-FEC solves this as follows: >>>> * For the base layer, we perform the exact same XOR operation as in >>>> traditional FEC: >>>> 1. parity bit: 0 XOR 0 = 0 >>>> 2. parity bit: 0 XOR 1 = 1 >>>> * For the enhancement layer, however, we also include the >>> base layer >>>> into the XOR operation. This is done, for example, by >>> applying the XOR >>>> operation to the 1. and 3. bit of the base layer and the 1. >>> and 2. bit >>>> of the enhancement layer jointly to produce the first >>> parity bit. For >>>> the second parity bit, the example could be to apply the >>> XOR operation >>>> to the 2. bit of the base layer and the 1. and 3. bit of the >>>> enhancement layer. >>>> 1. parity bit: 0 XOR 1 XOR 1 XOR 1 = 1 2. parity bit: 0 XOR >>> 1 XOR 0 = >>>> 1 If in this case the problem occurs and 3 bits of the base >>> layer are >>>> lost, then the base layer CAN be decoded since the >>> enhancement layer >>>> parity bits can be used to correct the errors. >>>> >>>> Please note that L-FEC can never be worse than traditional FEC as >>>> described above in terms of error correction capability. >>> The price to >>>> pay is more complexity. >>>> >>>> I hope the example makes clear what we mean by L-FEC. (I have also >>>> attached a JPEG picture that illustrates the example that I have >>>> described above) >>>> >>>> L-FEC has been developed at HHI by Cornelius Hellge, Thomas Schierl >>>> and me. >>>> >>>> Best Regards, >>>> Thomas Wiegand >>>> >>>> ---- >>>> Visit us at >>>> >>>> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 >>> February 2008 >>>> / Broadcast Mobile Convergence Forum / Booth 2B82 >>>> http://www.mobileworldcongress.com/homepage.htm >>>> >>>> OFC 2008 / San Diego, California, USA / 26 - 28 February >>> 2008 / Booth >>>> 411/415 http://www.ofcnfoec.org >>>> >>>> >>>> --- >>>> Thomas Wiegand, Dr.-Ing. >>>> Head, Image Communication Group >>>> Image Processing Department >>>> Fraunhofer Inst. for Telecommunications - HHI Einsteinufer >>> 37, D-10587 >>>> Berlin, Germany >>>> Phone: +49 30 31002 617, >>>> Mobile: +49 172 381 3814 >>>> http: iphome.hhi.de/wiegand >>>> --- >>>> >>>> >>>> >>>> On Jan 31, 2008, at 7:14 PM, Mark Watson wrote: >>>> >>>>> Thomas, >>>>> >>>>> What do you actually mean by "layered FEC" ? >>>>> >>>>> Certainly there is a concept of multiple FEC layers which makes >>>>> sense, and in fecframe we have discussed this. This is what Ali >>>>> refers to below as additivity - where multiple FEC streams can be >>>>> usefully decoded in combination. >>>>> >>>>> However it's a very different concept from layering in the >>> sense of a >>>>> layered video codec. In SVC, you absolutely need the base layer in >>>>> order to make sense of the enhancement layer. This is not >>> (cannot!) >>>>> be true for FEC "layers" because the whole point of FEC is to deal >>>>> with losses - the possibility of the "base layer" packets >>> being lost >>>>> must be accepted. >>>>> The >>>>> "enhancement layer" is thus useful on its own. >>>>> >>>>> Put another way, there can be no "dependency" between FEC >>> layers and >>>>> this is why we thought it would not be correct to use the layer >>>>> option in your dependency draft for FEC. >>>>> >>>>> In fact FEC "layers" are closer in concept to MDC, but >>> this does not >>>>> capture the point that, despite the absence of dependency, >>> there may >>>>> still be a notion of preference amongst the layers. >>>>> >>>>> There is of course a notion of dependency between source >>> flows and an >>>>> FEC repair flow that protects them. >>>>> >>>>> ...Mark >>>>> >>>>> >>>>> >>>>> >>>>> On 1/31/08 9:42 AM, "Thomas Schierl" wrote: >>>>> >>>>>> Hi Ali, >>>>>> >>>>>> >>>>>> One comment, we think that layered FEC does make sense. >>> There may be >>>>>> future applications, which code the media and the FEC in >>> a layered >>>>>> fashion. >>>>>> >>>>>> You may be right that from the current viewpoint layered FECs may >>>>>> not be of much use. But currently no one is using >>> layered codecs. >>>>>> That may change, since there is now an efficient scalable >>> codec for >>>>>> video. And in that case, your assumption may not hold. >>>>>> >>>>>> So, why not supporting this additional feature? >>>>>> >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ali Begen (abegen) [mailto:abegen@cisco.com] >>>>>>> Sent: Wednesday, January 30, 2008 10:53 PM >>>>>>> To: mmusic@ietf.org >>>>>>> Cc: jf.mule@cablelabs.com; jo@acm.org; fecframe@ietf.org >>>>>>> Subject: [Fecframe] Flexible FEC grouping and associations >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> In Vancouver, we gave a brief introduction on this issue >>> in MMUSIC >>>>>>> and the chairs asked us to examine the existing >>> drafts/RFCs before >>>>>>> going any further. >>>>>>> >>>>>>> In yesterday's FECFRAME design team meeting, we discussed this >>>>>>> topic and concluded that in terms of what we would like >>> to support >>>>>>> in FECFRAME, existing RFCs/drafts were not helping us much. We >>>>>>> examined RFC 3388, RFC 4756, and >>>>>>> draft-ietf-mmusic-decoding-dependency-00. >>>>>>> >>>>>>> Here is the summary. >>>>>>> >>>>>>> We would like to support the following: >>>>>>> 1- A source flow MAY be protected by multiple FEC schemes >>>>>>> 2- An FEC scheme MAY generate multiple repair flows >>>>>>> 3- Source flows MAY be grouped prior to FEC protection >>> (One or more >>>>>>> repair flows can protect a group of source flows) >>>>>>> >>>>>>> The Grouping/Association Problem: >>>>>>> RFC 3388 states that an "m" line identified by its "mid" >>> attribute >>>>>>> MUST NOT appear in more than one "a=group" line using the same >>>>>>> semantics. >>>>>>> So, >>>>>>> the FEC grouping semantics (RFC 4756) requires us to put every >>>>>>> source and repair flow in one "group:FEC" line. This is severely >>>>>>> limiting as it becomes difficult to associate the source >>> flows with >>>>>>> the repair flows, and/or group them. >>>>>>> >>>>>>> Does anybody remember what the main reason was for this >>> requirement? >>>>>>> >>>>>>> A very simple example: >>>>>>> Source #1: Base-layer video >>>>>>> Source #2: Enhancement-layer video >>>>>>> FEC Scheme #1: Produces Repair #1 that protects Source #1, and >>>>>>> Repair >>>>>>> #2 >>>>>>> that protects the group of Source #1 and #2 >>>>>>> >>>>>>> RFC 3388 requires us to say >>>>>>> a=group:FEC S1 S2 R1 R2, >>>>>>> >>>>>>> However, this does not say anything about which repair >>> flow(s) is >>>>>>> protecting which source flow(s). A new generalized grouping >>>>>>> attribute >>>>>>> ("a=gengroup") would help this problem by allowing an >>> "m" line to >>>>>>> appear multiple times in the same grouping semantics. Then, we >>>>>>> could write >>>>>>> >>>>>>> a=gengroup:FEC S1 R1 >>>>>>> a=gengroup:FEC S1 S2 R2 >>>>>>> >>>>>>> However, we do need additional mechanisms for: >>>>>>> >>>>>>> The Additivity Problem: >>>>>>> We would like to support additive repair flows (multiple repair >>>>>>> flows can be decoded jointly to improve decoding rate). >>> Note that >>>>>>> we don't need layered dependency among the repair flows. Source >>>>>>> flows might be layered encoded, but we don't think >>> layered encoded >>>>>>> FEC streams are much of use. >>>>>>> >>>>>>> Currently, there is no support for additivity from existing >>>>>>> documents. >>>>>>> decoding-dependency draft offers "mdc" dependency relation, >>>>>>> however, >>>>>>> (i) >>>>>>> using the keyword "mdc" is not very suitable for FEC, >>> and (ii) the >>>>>>> draft is only intended for RTP flows. >>>>>>> >>>>>>> The Prioritization Problem: >>>>>>> We would like to support prioritization of the repair flows. The >>>>>>> sender can assign different priorities to different repair flows >>>>>>> and we require the receivers to act accordingly. >>> However, there is >>>>>>> no support for prioritization from existing documents. >>>>>>> >>>>>>> One option is of course to define new stuff specific to >>> our needs >>>>>>> in the FECFRAME WG, however, we believe it is for everybody's >>>>>>> benefit to coordinate this effort with MMUSIC and address these >>>>>>> issues in a more general way as they may be required by other >>>>>>> frameworks/ applications. >>>>>>> >>>>>>> We would like to get everybody's opinion on this issue. >>>>>>> >>>>>>> Thanks, >>>>>>> -acbegen >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Fecframe mailing list >>>>>>> Fecframe@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/fecframe >>>>>> >>>>>> >>>>>> >>>>>> ---- >>>>>> Visit us at >>>>>> >>>>>> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February >>>>>> 2008 / >>>>>> Broadcast Mobile Convergence Forum / Booth 2B82 >>>>>> http://www.mobileworldcongress.com/homepage.htm >>>>>> >>>>>> OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / >>>>>> Booth 411/415 http://www.ofcnfoec.org >>>>>> >>>>>> _______________________________________________ >>>>>> Fecframe mailing list >>>>>> Fecframe@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/fecframe >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > ---- > Visit us at > > GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February > 2008 / > Broadcast Mobile Convergence Forum / Booth 2B82 > http://www.mobileworldcongress.com/homepage.htm > > OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth > 411/415 > http://www.ofcnfoec.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > http://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > http://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Feb 5 16:23:38 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3DA3A6857; Tue, 5 Feb 2008 16:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XucsVjXX9Hka; Tue, 5 Feb 2008 16:23:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8709A3A6848; Tue, 5 Feb 2008 16:23:36 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A373A67DF; Tue, 5 Feb 2008 16:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK3ayqLlbXWg; Tue, 5 Feb 2008 16:23:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0B91F3A6834; Tue, 5 Feb 2008 16:23:34 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2008 16:25:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m160P6UE029090; Tue, 5 Feb 2008 16:25:06 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m160Owfd008505; Wed, 6 Feb 2008 00:25:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 16:24:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Feb 2008 16:24:34 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54067566E8@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flexible FEC grouping and associations thread-index: AchjioB/b7CCcR9xSN6mr6Kes7P62wEyusvw From: "Ali Begen (abegen)" To: X-OriginalArrivalTime: 06 Feb 2008 00:24:35.0897 (UTC) FILETIME=[A709C290:01C86856] Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: jf.mule@cablelabs.com, fecframe@ietf.org, jo@acm.org Subject: [Fecframe] Flexible FEC grouping and associations X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org So far, nobody has commented on the main issue we are facing: the flexible grouping of source and repair flows. Let me restate our problem with a more direct question. Should we define a new grouping attribute that will not have the restrictions RFC 3388/4756 have? This flexibility may even help with the decoding-dependency draft. The current draft allows only layered or mdc dependency in one DDP group. Don't you think this might be restrictive in the future, if it is not already? Any strong feelings for doing or not doing this? Please share your comments. Don't forget to CC fecframe@ietf.org. Thanks, -acbegen -----Original Message----- From: Ali Begen (abegen) Sent: Wednesday, January 30, 2008 1:53 PM To: mmusic@ietf.org Cc: jf.mule@cablelabs.com; jo@acm.org; fecframe@ietf.org Subject: [Fecframe] Flexible FEC grouping and associations Hi everyone, In Vancouver, we gave a brief introduction on this issue in MMUSIC and the chairs asked us to examine the existing drafts/RFCs before going any further. In yesterday's FECFRAME design team meeting, we discussed this topic and concluded that in terms of what we would like to support in FECFRAME, existing RFCs/drafts were not helping us much. We examined RFC 3388, RFC 4756, and draft-ietf-mmusic-decoding-dependency-00. Here is the summary. We would like to support the following: 1- A source flow MAY be protected by multiple FEC schemes 2- An FEC scheme MAY generate multiple repair flows 3- Source flows MAY be grouped prior to FEC protection (One or more repair flows can protect a group of source flows) The Grouping/Association Problem: RFC 3388 states that an "m" line identified by its "mid" attribute MUST NOT appear in more than one "a=group" line using the same semantics. So, the FEC grouping semantics (RFC 4756) requires us to put every source and repair flow in one "group:FEC" line. This is severely limiting as it becomes difficult to associate the source flows with the repair flows, and/or group them. Does anybody remember what the main reason was for this requirement? A very simple example: Source #1: Base-layer video Source #2: Enhancement-layer video FEC Scheme #1: Produces Repair #1 that protects Source #1, and Repair #2 that protects the group of Source #1 and #2 RFC 3388 requires us to say a=group:FEC S1 S2 R1 R2, However, this does not say anything about which repair flow(s) is protecting which source flow(s). A new generalized grouping attribute ("a=gengroup") would help this problem by allowing an "m" line to appear multiple times in the same grouping semantics. Then, we could write a=gengroup:FEC S1 R1 a=gengroup:FEC S1 S2 R2 However, we do need additional mechanisms for: The Additivity Problem: We would like to support additive repair flows (multiple repair flows can be decoded jointly to improve decoding rate). Note that we don't need layered dependency among the repair flows. Source flows might be layered encoded, but we don't think layered encoded FEC streams are much of use. Currently, there is no support for additivity from existing documents. decoding-dependency draft offers "mdc" dependency relation, however, (i) using the keyword "mdc" is not very suitable for FEC, and (ii) the draft is only intended for RTP flows. The Prioritization Problem: We would like to support prioritization of the repair flows. The sender can assign different priorities to different repair flows and we require the receivers to act accordingly. However, there is no support for prioritization from existing documents. One option is of course to define new stuff specific to our needs in the FECFRAME WG, however, we believe it is for everybody's benefit to coordinate this effort with MMUSIC and address these issues in a more general way as they may be required by other frameworks/applications. We would like to get everybody's opinion on this issue. Thanks, -acbegen _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Feb 13 21:00:03 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C3228C8B5; Wed, 13 Feb 2008 21:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNziV-zIDqfi; Wed, 13 Feb 2008 21:00:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A311A3A690A; Wed, 13 Feb 2008 21:00:02 -0800 (PST) X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8FBC03A690A; Wed, 13 Feb 2008 21:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080214050001.8FBC03A690A@core3.amsl.com> Date: Wed, 13 Feb 2008 21:00:01 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-sdp-elements-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : SDP Elements for FEC Framework Author(s) : A. Begen Filename : draft-ietf-fecframe-sdp-elements-00.txt Pages : 20 Date : 2008-02-09 This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fecframe-sdp-elements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fecframe-sdp-elements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-13205825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fecframe-sdp-elements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fecframe-sdp-elements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-13205825.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe --NextPart-- From fecframe-bounces@ietf.org Fri Feb 15 18:39:55 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E339328C18F; Fri, 15 Feb 2008 18:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-2.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA-gsFMjRsZK; Fri, 15 Feb 2008 18:39:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2591B3A6909; Fri, 15 Feb 2008 18:39:55 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24DCB3A6909 for ; Fri, 15 Feb 2008 18:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBX0YFUyMA9u for ; Fri, 15 Feb 2008 18:39:53 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4076C3A68DC for ; Fri, 15 Feb 2008 18:39:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,360,1199692800"; d="scan'208";a="6042979" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2008 18:41:13 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1G2fBOT012559 for ; Fri, 15 Feb 2008 18:41:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1G2fBuN007829 for ; Sat, 16 Feb 2008 02:41:11 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 18:40:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 18:40:42 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406895561@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-begen-mmusic-fec-grouping-issues-00 thread-index: Achvm3oxmnZhRfC1RJexXvjUxIV5VAAqZAzg From: "Ali Begen (abegen)" To: X-OriginalArrivalTime: 16 Feb 2008 02:40:59.0992 (UTC) FILETIME=[5D450D80:01C87045] Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Fecframe] FW: New Version Notification for draft-begen-mmusic-fec-grouping-issues-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hello everyone, A new draft has been submitted. You can find it at: http://tools.ietf.org/id/draft-begen-mmusic-fec-grouping-issues-00.txt I am hoping we will get some time to discuss this draft in the MMUSIC WG in March. Comments are welcome. -acbegen -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Thursday, February 14, 2008 10:23 PM To: Ali Begen (abegen) Subject: New Version Notification for draft-begen-mmusic-fec-grouping-issues-00 A new version of I-D, draft-begen-mmusic-fec-grouping-issues-00.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-begen-mmusic-fec-grouping-issues Revision: 00 Title: FEC Grouping Issues in Session Description Protocol Creation_date: 2008-02-14 WG ID: Independent Submission Number_of_pages: 12 Abstract: The Session Description Protocol (SDP) currently supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the existing specifications have strict requirements that severely limit the use of the new features that are currently under development in the FECFRAME WG. These new features will allow applications to use FEC in a more flexible way but they require changes in the current specifications. This document provides a list of the required changes and discusses potential approaches to make these changes. The IETF Secretariat. _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Feb 18 11:06:59 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1891828C4FF; Mon, 18 Feb 2008 11:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC6JaTT6njAC; Mon, 18 Feb 2008 11:06:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254B13A6D5D; Mon, 18 Feb 2008 11:06:57 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63E13A6D69 for ; Mon, 18 Feb 2008 11:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYB8-8xnLYr5 for ; Mon, 18 Feb 2008 11:06:50 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 641FF28C3A8 for ; Mon, 18 Feb 2008 11:06:22 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2008 14:06:20 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1IJ6J25014028 for ; Mon, 18 Feb 2008 14:06:19 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1IJ5oWl009562 for ; Mon, 18 Feb 2008 19:06:19 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 14:06:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 14:05:29 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B604F1FBA3@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-fecframe-framework-01 -- Review comments Thread-Index: AchyYTpg8YmTKsTlTuar9pqBsRRvbQ== From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 18 Feb 2008 19:06:12.0433 (UTC) FILETIME=[53DB3C10:01C87261] Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Fecframe] draft-ietf-fecframe-framework-01 -- Review comments X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Mark, While working on the signaling draft, I reviewed the framework-01 draft a bit carefully, and got the following (minor) comments for our consideration. I have also provided the suggested replacement text, where applicable. ~~~~~~~~~~ 1) Section 1- Introduction .....It is expected that any complete content delivery protocol specification which makes use of this framework will address these signalling requirement(s). TO .....It is expected that any complete content delivery protocol specification which makes use of this framework will also make use of a signalling protocol to satisfy signalling requirement(s). The signalling protocol is part of the FEC framework. 2) Section 4- Architecture Overview .....The FEC framework does not define how the FEC framework configuration information for the stream is communicated from sender to receiver. This must be defined by any content delivery protocol specification as described in the following section. TO .....The FEC framework defines the usage of any signaling protocol by which FEC framework configuration information for the stream is communicated from sender to receiver. This must be adopted by any content delivery protocol specification making use of the FEC Framework. 3) Section 6- Protocol Overview Change the title to "Building Block Overview", since Protocol doesn't quite convey what protocol it is. 4) Section 2- Terminology 4.1 - Clarify the definition of 'Source Payload ID' and 'Repair Payload ID' a bit more. For example, Repair FEC Payload ID -- A FEC Payload ID to identify the source block and the mapping between the contained repair data and the original source block. Source Payload ID -- A FEC Payload ID to identify the mapping of source packet(s) with a source block. 4.2 - Add definition for "Restoration Window" (based on last meeting) as well as "instance" (which is used heavily in SDP Elements draft). We are freely interchanging stream and flow terms. Need to define them and use them appropriately. Suggest to stick with Flow. 5) Section 6 - Protocol Specification Are 'Source FEC Payload ID' and 'Repair Payload ID' conveyed by sender to receiver using the singaling protocol? Are they the same? Not clear in 6.1, 6.2 and 6.3. 6) Section 6.5 - Why is FEC Framework Instance not a mandatory info The configuration information is to be formulated for each FEC framework instance. Hence, we should mandatorily include the "instance" identifier, if not already. ~~~~~~~~~~~~~~ Cheers, Rajiv _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Feb 18 18:03:33 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8F33A6D82; Mon, 18 Feb 2008 18:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-2.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XlRBPri+yFB; Mon, 18 Feb 2008 18:03:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D313A69AD; Mon, 18 Feb 2008 18:03:32 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EAC3A6CDB for ; Mon, 18 Feb 2008 18:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibD1l2jfq0cL for ; Mon, 18 Feb 2008 18:03:30 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BEC5E3A6BEC for ; Mon, 18 Feb 2008 18:03:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,374,1199692800"; d="scan'208";a="13350498" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2008 18:03:28 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1J23SEX014570 for ; Mon, 18 Feb 2008 18:03:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1J23ONc016076 for ; Tue, 19 Feb 2008 02:03:28 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 18:03:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 18:03:21 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406895B05@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-begen-fecframe-1d2d-parity-scheme-00 thread-index: AchyeKbxwqskihhWSGumDJt3bCB+DAAAow5w From: "Ali Begen (abegen)" To: X-OriginalArrivalTime: 19 Feb 2008 02:03:25.0000 (UTC) FILETIME=[9C6DD480:01C8729B] Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Fecframe] FW: New Version Notification for draft-begen-fecframe-1d2d-parity-scheme-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi everyone, New draft on using partiy codes and their RTP payload format. http://www.tools.ietf.org/id/draft-begen-fecframe-1d2d-parity-scheme-00. txt Comments are welcome. -acbegen -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, February 18, 2008 1:53 PM To: Ali Begen (abegen) Cc: Rajiv Asati (rajiva) Subject: New Version Notification for draft-begen-fecframe-1d2d-parity-scheme-00 A new version of I-D, draft-begen-fecframe-1d2d-parity-scheme-00.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-begen-fecframe-1d2d-parity-scheme Revision: 00 Title: 1-D and 2-D Parity FEC Scheme for FEC Framework Creation_date: 2008-02-18 WG ID: Independent Submission Number_of_pages: 22 Abstract: This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the one-dimensional (1-D) and two-dimensional (2-D) parity codes and its application to reliable delivery of media streams in the context of FEC Framework. The 1-D and 2-D parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The 1-D and 2-D parity codes offer a good protection against random and bursty packet losses at a cost of decent complexity. This document also specifies an RTP payload format for the FEC that is generated by the 1-D and 2-D parity codes from a source media encapsulated in RTP. The FEC defined in this document is not backward compatible with RFC 5109. The IETF Secretariat. _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Feb 25 18:19:26 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2A03A6DC7; Mon, 25 Feb 2008 18:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.813 X-Spam-Level: X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arZNVAJ73S0B; Mon, 25 Feb 2008 18:19:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C533A6DD0; Mon, 25 Feb 2008 18:13:03 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B809D3A6D8F for ; Mon, 25 Feb 2008 18:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lyfAIGtbrev for ; Mon, 25 Feb 2008 18:12:58 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id E192728C8AC for ; Mon, 25 Feb 2008 18:09:11 -0800 (PST) Received: by an-out-0708.google.com with SMTP id d11so423047and.122 for ; Mon, 25 Feb 2008 18:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=U7gQwVVNdUd74910sO5LBTaEdbukJRRANuYzq6wzHxw=; b=K1iTE42IyAHrWOn6JIM5ZnkriDhwp8WNg79v+PUktF2FAiY2NgXtQOey6FPnWcVZvDZ/tor2i6iG7XtPnOBZuAJLZ+IGbOH6csBxoym/xDP5KloiIZNwbCdod8T8OxNRVgPrbtX7IxVOGdGuStObeMfzLA0+fZKoTYQlY8DUp6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=d2EM76i54r4cpPCn3lTVg7ggzrZoZYC18nqoyCNc1lf9Rmc05/ayrfynlKVLVUtAgC0uWGf0+tFrP9yU4dyyBpEamEm7umbMVImoMhQqT2Ee6EKF0xShXFGpF/wg0vcLYSoh24fJx/pI6htN81kW6f+Szt2xUmQTdBk4EwMwAts= Received: by 10.100.47.13 with SMTP id u13mr8519933anu.16.1203991745968; Mon, 25 Feb 2008 18:09:05 -0800 (PST) Received: by 10.100.125.10 with HTTP; Mon, 25 Feb 2008 18:09:05 -0800 (PST) Message-ID: <38c19b540802251809i626e4823we716c35d6074d816@mail.gmail.com> Date: Mon, 25 Feb 2008 18:09:05 -0800 From: "Greg Shepherd" To: fecframe@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Fecframe] Call for FECFrame WG agenda items X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Please send them to Marshal or me. I'll compile the agenda and send it back out. Thanks, Greg _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Feb 26 12:11:16 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B5428C360; Tue, 26 Feb 2008 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25PhRR3lSKNW; Tue, 26 Feb 2008 12:11:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0E628C805; Tue, 26 Feb 2008 12:10:49 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A8928C87A for ; Tue, 26 Feb 2008 12:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAkOp1vrqc+2 for ; Tue, 26 Feb 2008 12:10:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 90B3E28C788 for ; Tue, 26 Feb 2008 12:07:39 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Feb 2008 15:07:33 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QK7X3D006167; Tue, 26 Feb 2008 15:07:33 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QK6sVA000448; Tue, 26 Feb 2008 20:07:33 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 15:07:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:06:45 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B604FE6C2A@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fecframe Digest, Vol 25, Issue 9 Thread-Index: Ach4smqj0eevq5jSSeC7g9FG7+GafwAAFvUg From: "Rajiv Asati (rajiva)" To: "Greg Shepherd" X-OriginalArrivalTime: 26 Feb 2008 20:07:30.0637 (UTC) FILETIME=[378A9FD0:01C878B3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1890; t=1204056453; x=1204920453; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20 |Subject:=20RE=3A=20Fecframe=20Digest,=20Vol=2025,=20Issue= 209 |Sender:=20 |To:=20=22Greg=20Shepherd=22=20; bh=n3yC63kDRj/0wTJUDaoMWG94OWOttMfdkY/yeh/ciQY=; b=Q1XoVsftCHda9pMODu+cc1CnKlGxsM6RLrNHPqqT2vRLgygrFU1uTz85dI Qh3iPT4PgoIiqiGyqlVF1cxzc2maKqANbqBT8+qUnT2cOJm4tOr/XIDSRETe wQ07O6bnCR; Authentication-Results: rtp-dkim-2; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fecframe Digest, Vol 25, Issue 9 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Greg, Marshal I would like to request a timeslot (15mins) to present the 'FECframe Config signaling' draft. http://tools.ietf.org/html/draft-asati-fecframe-config-signaling-00 Cheers, Rajiv > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of > fecframe-request@ietf.org > Sent: Tuesday, February 26, 2008 3:00 PM > To: fecframe@ietf.org > Subject: Fecframe Digest, Vol 25, Issue 9 > > Send Fecframe mailing list submissions to > fecframe@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ietf.org/mailman/listinfo/fecframe > or, via email, send a message with subject or body 'help' to > fecframe-request@ietf.org > > You can reach the person managing the list at > fecframe-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Fecframe digest..." > > > Today's Topics: > > 1. Call for FECFrame WG agenda items (Greg Shepherd) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Feb 2008 18:09:05 -0800 > From: "Greg Shepherd" > Subject: [Fecframe] Call for FECFrame WG agenda items > To: fecframe@ietf.org > Message-ID: > <38c19b540802251809i626e4823we716c35d6074d816@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Please send them to Marshal or me. I'll compile the agenda > and send it back out. > > Thanks, > Greg > > > ------------------------------ > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > http://www.ietf.org/mailman/listinfo/fecframe > > > End of Fecframe Digest, Vol 25, Issue 9 > *************************************** > _______________________________________________ Fecframe mailing list Fecframe@ietf.org http://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Feb 27 09:32:32 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108F73A6EB4; Wed, 27 Feb 2008 09:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzvvxJPROb3G; Wed, 27 Feb 2008 09:32:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D2428C395; Wed, 27 Feb 2008 09:31:43 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4514728C2CC for ; Wed, 27 Feb 2008 09:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0OcfTg0VB3V for ; Wed, 27 Feb 2008 09:31:41 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id EFB833A6821 for ; Wed, 27 Feb 2008 09:27:33 -0800 (PST) Received: by an-out-0708.google.com with SMTP id d11so657596and.122 for ; Wed, 27 Feb 2008 09:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=62Bxc1RtZTcOEO3ocQ3qakfnnQX4LU6ypgoR8Goahtk=; b=IlW5kUmdSWhLp2696pGKRSctLqlpA7SQi+cuzrpXi7zBEi4bJ92rDtpPY6W358Uj2vYUp0gaWOfiWOdYnBexxLz8KgfNDnXuvwgI6hWFrTxkxZKN7UKHOYyag8OngTzEwG21Oec6LuLmwQdkeYxc0m2ZdwjK3u7/Pb6W8EQimxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ocYXe0/VOdr5SaxMozVh0SAq47cWhTKok0OZWXMz5/xFloMa2+A9+FWdC5hw4sRP/S/Etj/XEkjiObzFAwU1MH/+yAZ3sV3ZqXBzU9VmbI6dGorSpZ6c3ZJMpI/+Cv3gHqeurDbgJDIZX3DZwC4TKkIvW4qq4KpvTLqYMOyzwzU= Received: by 10.100.123.4 with SMTP id v4mr12672669anc.4.1204133247025; Wed, 27 Feb 2008 09:27:27 -0800 (PST) Received: by 10.100.125.10 with HTTP; Wed, 27 Feb 2008 09:27:27 -0800 (PST) Message-ID: <38c19b540802270927t30b3d8f4uaae08019ee047c16@mail.gmail.com> Date: Wed, 27 Feb 2008 09:27:27 -0800 From: "Greg Shepherd" To: fecframe@ietf.org In-Reply-To: <38c19b540802251809i626e4823we716c35d6074d816@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <38c19b540802251809i626e4823we716c35d6074d816@mail.gmail.com> Subject: Re: [Fecframe] Call for FECFrame WG agenda items X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Mon, Feb 25, 2008 at 6:09 PM, Greg Shepherd wrote: > Please send them to Marshal or me. I'll compile the agenda and send it back out. > > Thanks, > Greg The FECFrame agenda for Philly is now posted: IETF 71, FECFrame WG Agenda Introduction, Agenda Bashing - 5min Chairs FECFrame Proto Team update - 10 mins Chairs FECFrame Config Signaling - 15mins Rajiv Asati draft-asati-fecframe-config-signaling SDP Elements - 15 mins Ali Begen draft-begen-fecframe-sdp-elements COP3 2D - 15 mins Ali Begen draft-begen-fecframe-1d2d-parity-scheme FEC Grouping issues in SDP - 15mins Ali Begen draft-begen-mmusic-fec-grouping-issues'' Please let me know if there's something missing we need to add. Thanks, Greg _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Feb 27 12:19:59 2008 Return-Path: X-Original-To: ietfarch-fecframe-archive@core3.amsl.com Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123E528C2E5; Wed, 27 Feb 2008 12:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u0rahPZInpu; Wed, 27 Feb 2008 12:19:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D143A6B76; Wed, 27 Feb 2008 12:19:49 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A487B3A6E18 for ; Wed, 27 Feb 2008 12:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpmTLWMhmn+q for ; Wed, 27 Feb 2008 12:19:43 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by core3.amsl.com (Postfix) with ESMTP id 9BCF23A6B76 for ; Wed, 27 Feb 2008 12:19:40 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id i26so2028894wxd.31 for ; Wed, 27 Feb 2008 12:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=oqKKvDGOo85yjQ+J4diqNFjUnL1F/6liJvdy+byUYGM=; b=GnviDdvgufWktlkWgHqN6Y9JR2gdgy9uDxITKKSSgNj5zqhPumuWBQ5DVyCQ7ECIQo7nC9kkiFhLY7pR8BPkqyClUoyJDMqtjnrmyJwk/Yfs6C8WoheW0YE2kxhQbyithuSXY4JWSXsinLuX3PhWoTILx9IxygWbBxWzTCnw110= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=V+vcNSf/MD4hdxDLirAMDo7cJzfwnbwjGUZB/BHplPiS28bU63b2UZR0lyzMHK+JMlx5rQamiEA3gCHOjqAMgRSmxBe6jkWJZA5TanXcySzZY4T7we5l7JLoBxKiEQ4S8XuH9R1859M8aX1XRzLF/z+xEoW1gTOSg+/ByIyZiV8= Received: by 10.100.38.3 with SMTP id l3mr7187711anl.45.1204143573865; Wed, 27 Feb 2008 12:19:33 -0800 (PST) Received: by 10.100.125.10 with HTTP; Wed, 27 Feb 2008 12:19:33 -0800 (PST) Message-ID: <38c19b540802271219l69d6e331nfe87b33a21490761@mail.gmail.com> Date: Wed, 27 Feb 2008 12:19:33 -0800 From: "Greg Shepherd" To: fecframe@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Fecframe] Test X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Sent email earlier today and never saw it.. _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe