From fecframe-bounces@ietf.org Fri Jan 18 20:18:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG2LY-0000SS-FN; Fri, 18 Jan 2008 20:18:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG2LX-0000SI-KJ for fecframe@ietf.org; Fri, 18 Jan 2008 20:18:07 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JG2LX-0003FU-6N for fecframe@ietf.org; Fri, 18 Jan 2008 20:18:07 -0500 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 10162635 for fecframe@ietf.org; Fri, 18 Jan 2008 20:18:04 -0500 Mime-Version: 1.0 (Apple Message framework v753) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E904D28-9B78-49FF-B9EB-2D4A80EA25F1@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Fri, 18 Jan 2008 20:18:01 -0500 To: fecframe@ietf.org X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Fecframe] Fwd: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Note well. Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: January 18, 2008 12:00:01 AM EST > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF > Meeting in Philadelphia, PA, USA > > > There are two (2) Internet-Draft cutoff dates for the 71st > IETF Meeting in Philadelphia, PA, USA: > > February 18th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for > version -00 WG drafts that replace existing non-WG drafts. Such > drafts > may be submitted until the cutoff date for version -01 and higher > drafts. > As always, all initial submissions with a filename beginning with > "draft-ietf" must be approved by the appropriate WG Chair before they > can be processed or announced. The Secretariat would appreciate > receiving WG Chair approval by Monday, February 11th at 9:00 AM ET > (14:00 UTC/GMT). > > February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version > -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 10th at 9:00 > AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please > do not wait until > the last minute to submit. > > The Secretariat encourages you to submit your Internet-Drafts via the > Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/ > idst/upload.cgi. > If you are unable to do so, then you may still submit your Internet- > Drafts manually by sending them to internet-drafts@ietf.org. If you > are submitting a version -00 WG draft that replaces non-WG draft, then > you must submit it manually as the current IDST cannot handle > replacements. Please be sure to state that one draft replaces another > in the cover note that accompanies your submission. Also, please note > that the IDST will not accept drafts submitted after their respective > cutoff dates. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 71st IETF Meeting can be found at http://www.ietf.org/ > meetings/71-cutoff_dates.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Jan 29 14:38:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJwIL-0004nH-Q3; Tue, 29 Jan 2008 14:38:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJwIH-0004et-5w; Tue, 29 Jan 2008 14:38:53 -0500 Received: from server107e.exghost.com ([69.20.100.17] helo=server107.appriver.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJwIG-00066B-VH; Tue, 29 Jan 2008 14:38:53 -0500 Received: by server107.appriver.com (CommuniGate Pro PIPE 5.1.14) with PIPE id 73278975; Tue, 29 Jan 2008 14:38:44 -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 73270637; Tue, 29 Jan 2008 14:31:23 -0500 Received: from 34093-EVS4C1.exchange.rackspace.com ([192.168.1.68]) by FE2.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jan 2008 13:31:26 -0600 Received: from 128.107.28.158 ([128.107.28.158]) by 34093-EVS4C1.exchange.rackspace.com ([192.168.1.58]) via Exchange Front-End Server owa.mailseat.com ([192.168.1.6]) with Microsoft Exchange Server HTTP-DAV ; Tue, 29 Jan 2008 19:30:33 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 29 Jan 2008 11:30:24 -0800 From: Mark Watson To: , Message-ID: Thread-Topic: Question on draft-ietf-mmusic-decoding-dependency-00 Thread-Index: AchirWTLo1L0GM6gEdyecQAX8sJN9g== Mime-version: 1.0 X-OriginalArrivalTime: 29 Jan 2008 19:31:26.0661 (UTC) FILETIME=[8A251750:01C862AD] 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [Fecframe] Question on draft-ietf-mmusic-decoding-dependency-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1798961506==" Errors-To: fecframe-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1798961506== Content-type: multipart/alternative; boundary="B_3284451024_4900782" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3284451024_4900782 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable All, Within the fecframe working group we are considering the possible use of this draft, or an extension of this syntax, to specify the various relationships which can exist between FEC flows and the source flows they protect. The following question came up in the discussion. The draft states at the end of section 1: =B3The mechanisms defined herein are media transport protocol independent, i.e. applicable beyond the use of RTP [RFC3550]=B2 However, the mechanisms then defined appear to rely on Payload Types, which are specific to RTP, to specify the relationships between flows. That is, the syntax specifies relationships between RTP flows defined by ( UDP Port, Payload Type ) pairs. Either the draft should be generalised to also allow specification of relationships between UDP flows (defined just by the UDP port) or the above sentence should be removed. Should there be an IANA registry for dependency-types ? ...Mark Watson --B_3284451024_4900782 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Question on draft-ietf-mmusic-decoding-dependency-00 All,<= BR>
Within the fecframe working group we are considering the possible use of th= is draft, or an extension of this syntax, to specify the various relationshi= ps which can exist between FEC flows and the source flows they protect.

The following question came up in the discussion. The draft states at the e= nd of section 1:

“The mechanisms defined herein are media transport = protocol independent, i.e. applicable beyond the use of RTP [RFC3550]”=

However, the mechanisms then defined appear to rely on Payload Type= s, which are specific to RTP, to specify the relationships between flows. Th= at is, the syntax specifies relationships between RTP flows defined by ( UDP= Port, Payload Type ) pairs.

Either the draft should be generalised to also allow specification of relat= ionships between UDP flows (defined just by the UDP port) or the above sente= nce should be removed.

Should there be an IANA registry for dependency-types ?

...Mark Watson --B_3284451024_4900782-- --===============1798961506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============1798961506==-- From fecframe-bounces@ietf.org Wed Jan 30 03:31:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK8La-0008GY-LO; Wed, 30 Jan 2008 03:31:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK8LP-0008Fw-By; Wed, 30 Jan 2008 03:30:55 -0500 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK8LK-0002Jy-6q; Wed, 30 Jan 2008 03:30:55 -0500 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 67C5E1D89014; Wed, 30 Jan 2008 09:30:49 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, score=-101.8 required=5.0 tests=AWL,BAYES_00,HTML_70_80, HTML_ATTR_UNIQUE, HTML_MESSAGE, USER_IN_WHITELIST autolearn=no version=3.1.9 Received: from ipam040160 (ipamfw.iphhi.de [212.202.149.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id A03E91D88FA5; Wed, 30 Jan 2008 09:30:48 +0100 (CET) From: "Thomas Schierl" To: "'Mark Watson'" , , References: In-Reply-To: Subject: RE: [Fecframe] Question on draft-ietf-mmusic-decoding-dependency-00 Date: Wed, 30 Jan 2008 09:30:48 +0100 Message-ID: <014401c8631a$6adb5e00$40921a00$@fhg.de> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: de Thread-index: AchirWTLo1L0GM6gEdyecQAX8sJN9gAbMG3w X-alterMIME: Yes X-Spam-Score: -2.2 (--) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937472822==" Errors-To: fecframe-bounces@ietf.org This is a multipart message in MIME format. --===============1937472822== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0145_01C86322.CC9FC600" Content-language: de This is a multipart message in MIME format. ------=_NextPart_000_0145_01C86322.CC9FC600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark, Our original intent was to keep the draft transport independent. However, that has turned out to be difficult. The PT dependency has been put in after long discussions based on a proposal by Magnus, and is now a necessary and integral part of the draft. The sentence cited is a leftover from the earlier days, and should have been removed. We will update the draft accordingly. Attempting to re-generalize the draft would not only lead to delay, but would most likely also run us into the same problems that have forced us to put this transport protocol dependency into the draft in the first place. Therefore, we do not favor such an approach. Best regards, Stephan and Thomas From: Mark Watson [mailto:mark@digitalfountain.com] Sent: Tuesday, January 29, 2008 8:30 PM To: mmusic@ietf.org; fecframe@ietf.org Subject: [Fecframe] Question on draft-ietf-mmusic-decoding-dependency-00 All, Within the fecframe working group we are considering the possible use of this draft, or an extension of this syntax, to specify the various relationships which can exist between FEC flows and the source flows they protect. The following question came up in the discussion. The draft states at the end of section 1: "The mechanisms defined herein are media transport protocol independent, i.e. applicable beyond the use of RTP [RFC3550]" However, the mechanisms then defined appear to rely on Payload Types, which are specific to RTP, to specify the relationships between flows. That is, the syntax specifies relationships between RTP flows defined by ( UDP Port, Payload Type ) pairs. Either the draft should be generalised to also allow specification of relationships between UDP flows (defined just by the UDP port) or the above sentence should be removed. Should there be an IANA registry for dependency-types ? ...Mark Watson ---- 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 ------=_NextPart_000_0145_01C86322.CC9FC600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on draft-ietf-mmusic-decoding-dependency-00

Hi = Mark,

 

Our original intent was to = keep the draft transport independent.  However, that has turned out to be = difficult.  The PT dependency has been put in after long discussions based on a = proposal by Magnus, and is now a necessary and integral part of the = draft.

The sentence cited is a = leftover from the earlier days, and should have been removed.  We will update the = draft accordingly.

Attempting to re-generalize = the draft would not only lead to delay, but would most likely also run us into the = same problems that have forced us to put this transport protocol dependency = into the draft in the first place.  Therefore, we do not favor such an = approach.

 

Best = regards,

Stephan and = Thomas

 

 

From: Mark Watson [mailto:mark@digitalfountain.com]
Sent: Tuesday, January 29, 2008 8:30 PM
To: mmusic@ietf.org; fecframe@ietf.org
Subject: [Fecframe] Question on = draft-ietf-mmusic-decoding-dependency-00

 

All,

Within the fecframe working group we are considering the possible use of = this draft, or an extension of this syntax, to specify the various = relationships which can exist between FEC flows and the source flows they protect.

The following question came up in the discussion. The draft states at = the end of section 1:

“The = mechanisms defined herein are media transport protocol independent, i.e. applicable = beyond the use of RTP [RFC3550]”

However, the mechanisms then defined appear to rely on Payload Types, which are = specific to RTP, to specify the relationships between flows. That is, the syntax = specifies relationships between RTP flows defined by ( UDP Port, Payload Type ) = pairs.

Either the draft should be generalised to also allow specification of relationships between UDP flows (defined just by the UDP port) or the = above sentence should be removed.

Should there be an IANA registry for dependency-types ?

...Mark Watson



----
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


------=_NextPart_000_0145_01C86322.CC9FC600-- --===============1937472822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============1937472822==-- From fecframe-bounces@ietf.org Wed Jan 30 16:53:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKs2-0007ng-Rv; Wed, 30 Jan 2008 16:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKs0-0007gs-Rk; Wed, 30 Jan 2008 16:53:24 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKrz-0003Ui-9d; Wed, 30 Jan 2008 16:53:24 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 30 Jan 2008 13:53:22 -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 m0ULrM7P014115; Wed, 30 Jan 2008 13:53:22 -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 m0ULrAj9029237; Wed, 30 Jan 2008 21:53:15 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); Wed, 30 Jan 2008 13:53:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jan 2008 13:53:09 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54066FE22B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flexible FEC grouping and associations thread-index: AchjioB/b7CCcR9xSN6mr6Kes7P62w== From: "Ali Begen (abegen)" To: X-OriginalArrivalTime: 30 Jan 2008 21:53:13.0011 (UTC) FILETIME=[82BCD830:01C8638A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3150; t=1201730002; x=1202594002; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20(abegen)=22=20 |Subject:=20Flexible=20FEC=20grouping=20and=20associations |Sender:=20; bh=1D2RrUzvFiNC6lWOOTr5MWjIBOzEgjIKNfcTi4uTZJ8=; b=rCjMsKdn9vffPJ5eZWr64KG6Kz3LCPjYmgeNa4U6nLmwIY2PbYH6fvwk8Z kI2ZR3JXt7vo1QrrLGq5VD83ToSrOqAtVyO8W4USEuDcWqQU6WXVIVwLMpyv uJUoxMYzxs; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: jf.mule@cablelabs.com, jo@acm.org, fecframe@ietf.org Subject: [Fecframe] Flexible FEC grouping and associations X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org 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.=20 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=3Dgroup" 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.=20 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=20 RFC 3388 requires us to say a=3Dgroup:FEC S1 S2 R1 R2,=20 However, this does not say anything about which repair flow(s) is protecting which source flow(s). A new generalized grouping attribute ("a=3Dgengroup") would help this problem by allowing an "m" line to = appear multiple times in the same grouping semantics. Then, we could write a=3Dgengroup:FEC S1 R1=20 a=3Dgengroup: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.=20 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 From fecframe-bounces@ietf.org Thu Jan 31 12:42:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKdQj-0005mm-Q6; Thu, 31 Jan 2008 12:42:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKdQi-0005mI-Gg; Thu, 31 Jan 2008 12:42:28 -0500 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKdQg-0003Be-Bn; Thu, 31 Jan 2008 12:42:28 -0500 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 5D9221D88FDB; Thu, 31 Jan 2008 18:42:23 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, score=-102.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.9 Received: from ipam040160 (brln-4db919c1.pool.einsundeins.de [77.185.25.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 9D0DF1D88FB4; Thu, 31 Jan 2008 18:42:11 +0100 (CET) From: "Thomas Schierl" To: "'Ali Begen (abegen)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54066FE22B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54066FE22B@xmb-sjc-215.amer.cisco.com> Subject: RE: [Fecframe] Flexible FEC grouping and associations Date: Thu, 31 Jan 2008 18:42:10 +0100 Message-ID: <033c01c86430$9c4cb620$d4e62260$@fhg.de> X-Mailer: Microsoft Office Outlook 12.0 Content-language: de Thread-index: AchjioB/b7CCcR9xSN6mr6Kes7P62wApSeJA X-alterMIME: Yes X-Spam-Score: -4.0 (----) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Cornelius.Hellge@hhi.fraunhofer.de, jf.mule@cablelabs.com, 'Thomas Wiegand' , fecframe@ietf.org, jo@acm.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org 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 From fecframe-bounces@ietf.org Thu Jan 31 13:15:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKdwU-0002sD-6j; Thu, 31 Jan 2008 13:15:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKdwS-0002rv-Iz; Thu, 31 Jan 2008 13:15:17 -0500 Received: from server107e.exghost.com ([69.20.100.17] helo=server107.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKdwQ-0003zf-DT; Thu, 31 Jan 2008 13:15:16 -0500 Received: by server107.appriver.com (CommuniGate Pro PIPE 5.1.14) with PIPE id 74892244; Thu, 31 Jan 2008 13:15:12 -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 74892211; Thu, 31 Jan 2008 13:15:09 -0500 Received: from 34093-EVS4C1.exchange.rackspace.com ([192.168.1.68]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 12:15:00 -0600 Received: from 76.222.192.62 ([76.222.192.62]) by 34093-EVS4C1.exchange.rackspace.com ([192.168.1.58]) via Exchange Front-End Server owa.mailseat.com ([192.168.1.52]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jan 2008 18:14:19 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 31 Jan 2008 10:14:10 -0800 Subject: Re: [Fecframe] Flexible FEC grouping and associations From: Mark Watson To: Thomas Schierl , "'Ali Begen (abegen)'" , Message-ID: Thread-Topic: [Fecframe] Flexible FEC grouping and associations Thread-Index: AchjioB/b7CCcR9xSN6mr6Kes7P62wApSeJAAAFa0do= In-Reply-To: <033c01c86430$9c4cb620$d4e62260$@fhg.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Jan 2008 18:15:00.0413 (UTC) FILETIME=[315AAED0:01C86435] 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: UNKNOWN->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Cornelius.Hellge@hhi.fraunhofer.de, jf.mule@cablelabs.com, 'Thomas Wiegand' , jo@acm.org, fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org 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 https://www1.ietf.org/mailman/listinfo/fecframe